From owner-freebsd-current@FreeBSD.ORG Sun Jan 30 02:32:41 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 055B716A4CE; Sun, 30 Jan 2005 02:32:41 +0000 (GMT) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 448F143D41; Sun, 30 Jan 2005 02:32:40 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.13.1/8.13.1) with ESMTP id j0U2WQFc064192; Sat, 29 Jan 2005 21:32:26 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.1/8.13.1) with ESMTP id j0U2WqwB033058; Sat, 29 Jan 2005 21:32:52 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id B131F7306E; Sat, 29 Jan 2005 21:32:26 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050130023226.B131F7306E@freebsd-current.sentex.ca> Date: Sat, 29 Jan 2005 21:32:26 -0500 (EST) X-Virus-Scanned: ClamAV 0.80/625/Fri Dec 10 12:41:57 2004 clamav-milter version 0.80j on clamscanner3 X-Virus-Scanned: ClamAV 0.80/690/Fri Jan 28 07:09:45 2005 clamav-milter version 0.80j on clamscanner4 X-Virus-Status: Clean X-Virus-Status: Clean Subject: [current tinderbox] failure on alpha/alpha X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jan 2005 02:32:41 -0000 TB --- 2005-01-30 01:15:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-01-30 01:15:00 - starting CURRENT tinderbox run for alpha/alpha TB --- 2005-01-30 01:15:00 - checking out the source tree TB --- 2005-01-30 01:15:00 - cd /home/tinderbox/CURRENT/alpha/alpha TB --- 2005-01-30 01:15:00 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-01-30 01:21:13 - building world (CFLAGS=-O2 -pipe) TB --- 2005-01-30 01:21:13 - cd /home/tinderbox/CURRENT/alpha/alpha/src TB --- 2005-01-30 01:21:13 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything TB --- 2005-01-30 02:28:29 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-01-30 02:28:29 - cd /home/tinderbox/CURRENT/alpha/alpha/src TB --- 2005-01-30 02:28:29 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sun Jan 30 02:28:30 UTC 2005 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/tinderbox/CURRENT/alpha/alpha/src/sys -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/altq -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/pf -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /tinderbox/CURRENT/alpha/alpha/src/sys/isofs/cd9660/cd9660_vnops.c awk -f /tinderbox/CURRENT/alpha/alpha/src/sys/tools/makeobjops.awk /tinderbox/CURRENT/alpha/alpha/src/sys/kern/bus_if.m -c ; cc -c -O2 -pipe -fno-strict-aliasing -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/tinderbox/CURRENT/alpha/alpha/src/sys -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/altq -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/pf -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werr or bus_if.c awk -f /tinderbox/CURRENT/alpha/alpha/src/sys/tools/makeobjops.awk /tinderbox/CURRENT/alpha/alpha/src/sys/kern/device_if.m -c ; cc -c -O2 -pipe -fno-strict-aliasing -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/tinderbox/CURRENT/alpha/alpha/src/sys -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/altq -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/pf -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -W error device_if.c cc -c -O2 -pipe -fno-strict-aliasing -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/tinderbox/CURRENT/alpha/alpha/src/sys -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/altq -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/pf -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /tinderbox/CURRENT/alpha/alpha/src/sys/kern/imgact_elf.c cc -c -O2 -pipe -fno-strict-aliasing -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/tinderbox/CURRENT/alpha/alpha/src/sys -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/altq -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/pf -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /tinderbox/CURRENT/alpha/alpha/src/sys/kern/imgact_shell.c /tinderbox/CURRENT/alpha/alpha/src/sys/kern/imgact_shell.c: In function `exec_shell_imgact': /tinderbox/CURRENT/alpha/alpha/src/sys/kern/imgact_shell.c:166: warning: passing arg 4 of `copystr' from incompatible pointer type /tinderbox/CURRENT/alpha/alpha/src/sys/kern/imgact_shell.c:170: warning: passing arg 4 of `copystr' from incompatible pointer type *** Error code 1 Stop in /tinderbox/CURRENT/alpha/alpha/obj/alpha/tinderbox/CURRENT/alpha/alpha/src/sys/GENERIC. *** Error code 1 Stop in /tinderbox/CURRENT/alpha/alpha/src. *** Error code 1 Stop in /tinderbox/CURRENT/alpha/alpha/src. TB --- 2005-01-30 02:32:26 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-01-30 02:32:26 - ERROR: failed to build generic kernel TB --- 2005-01-30 02:32:26 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Sun Jan 30 02:52:19 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2A5A716A4CE; Sun, 30 Jan 2005 02:52:19 +0000 (GMT) Received: from obsecurity.dyndns.org (CPE0050040655c8-CM00111ae02aac.cpe.net.cable.rogers.com [69.199.47.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id E123D43D41; Sun, 30 Jan 2005 02:52:18 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 28537514FE; Sat, 29 Jan 2005 18:52:18 -0800 (PST) Date: Sat, 29 Jan 2005 18:52:18 -0800 From: Kris Kennaway To: current@freeBSD.org Message-ID: <20050130025217.GA32612@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GvXjxJ+pjyke8COw" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i cc: alc@FreeBSD.org Subject: do_execve() finding vmspace_destroyed set under load X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jan 2005 02:52:19 -0000 --GvXjxJ+pjyke8COw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I'm seeing the following code in do_execve() frequently being triggered when scripts are executed on my SMP machine under load: if (imgp->vmspace_destroyed) { /* sorry, no more process anymore. exit gracefully */ #ifdef MAC mac_execve_exit(imgp); if (interplabel != NULL) mac_vnode_label_free(interplabel); #endif exit1(td, W_EXITCODE(0, SIGABRT)); /* NOT REACHED */ error = 0; } Needless to say, the scripts get pretty unhappy when they're summarily aborted. What is the cause of this? Kris --GvXjxJ+pjyke8COw Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFB/EvhWry0BWjoQKURAnuwAJwPTBZIh6mS+ceCrG6OsXTUvW/hsQCcC/mQ m359/nsPUZkt8i1hZqZ1AKQ= =eapH -----END PGP SIGNATURE----- --GvXjxJ+pjyke8COw-- From owner-freebsd-current@FreeBSD.ORG Sun Jan 30 03:04:19 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0280116A4CE for ; Sun, 30 Jan 2005 03:04:19 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 42AE243D31 for ; Sun, 30 Jan 2005 03:04:18 +0000 (GMT) (envelope-from scottl@freebsd.org) Received: from [192.168.254.12] (g4.samsco.home [192.168.254.12]) (authenticated bits=0) by pooker.samsco.org (8.12.11/8.12.10) with ESMTP id j0U37Q9Q019566; Sat, 29 Jan 2005 20:07:26 -0700 (MST) (envelope-from scottl@freebsd.org) Message-ID: <41FC4EA2.40603@freebsd.org> Date: Sat, 29 Jan 2005 20:04:02 -0700 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7) Gecko/20040514 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Doug White References: <20050128100151.GA43728@fit.vutbr.cz> <20050129121051.X85926@carver.gumbysoft.com> In-Reply-To: <20050129121051.X85926@carver.gumbysoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=3.8 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pooker.samsco.org cc: Petr Lampa cc: freebsd-current@freebsd.org cc: vkashyap@amcc.com Subject: Re: bus_dmamap_create() breakage (alias 3Ware driver problems) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jan 2005 03:04:19 -0000 Doug White wrote: > Hello Petr, > > Thanks for the analysis on this. > > On Fri, 28 Jan 2005, Petr Lampa wrote: > > >>I have got similar problems with the new 3Ware driver like others, >>but on the second controller. After some debugging and playing with >>bus_dma_tag_create() etc. arguments (new driver is using 3 busdma_tags >>instead 1 in old driver), I have located source of failure >>in bus_dmamap_create(). Here is the trouble spot: >> >>$FreeBSD: src/sys/i386/i386/busdma_machdep.c,v 1.59.2.3 2004/12/04 05: >>55:10 scottl Exp $ >> >>bus_dmamap_create(bus_dma_tag_t dmat, int flags, bus_dmamap_t *mapp) >>{ >>... >> maxpages = MIN(MAX_BPAGES, Maxmem - atop(dmat->lowaddr)); >> if ((dmat->flags & BUS_DMA_MIN_ALLOC_COMP) == 0 >> || (dmat->map_count > 0 && total_bpages < maxpages)) { >> int pages; >> ... >> pages = MAX(atop(dmat->maxsize), 1); >> >>At this location maxpages=512, total_bpages=513, dmat->maxsize=131072, pages=32 >> >> pages = MIN(maxpages - total_bpages, pages); >> >>Here pages=-1! > > > Ooh, thats not so good. > > Could you bundle up your changes into a patch? Its a lot easier to follow > and compare your changes, as well as test :) Also, can you please submit > a PR with the patch so it doesn't get lost? scottl is out for the weekend > but I'll bring this to his attention when he returns. > > Thanks! > There is a fundamental problem with how busdma counts and pre-allocates bounce pages, and it's leading to some interesting problems like this (which is why I never merged the 4GB+ fixes to RELENG_5_3). Basically, I think that too many bounce pages are being allocated for fixing up alignment constraints. I need a few hours to sit in front of a white-board and think it all through again. However, someone want to help, either by fixing the underlying problems or by tying up these edge cases, I'd be happy to discuss it some more. Scott From owner-freebsd-current@FreeBSD.ORG Sun Jan 30 03:26:25 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 69FEC16A4CF for ; Sun, 30 Jan 2005 03:26:25 +0000 (GMT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id ED43C43D1D for ; Sun, 30 Jan 2005 03:26:24 +0000 (GMT) (envelope-from minimarmot@gmail.com) Received: by wproxy.gmail.com with SMTP id 58so50627wri for ; Sat, 29 Jan 2005 19:26:24 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type; b=gG0hZPEJcNydoMylR6ebISoSkyOa+BcRCwbVSZHo0xUVXgucc7JA+Mqx8R0k7ZxTv7h2vMj/aA/T1NZYYIt7rQXuq4x2T0xV5nggMbkyIod16PGxofj2EzGduZOmMSGSpPQjeyNrnCmXRuJOlOcN27Cat/qZSFKdqZWjuQu+mM8= Received: by 10.54.48.16 with SMTP id v16mr161533wrv; Sat, 29 Jan 2005 19:26:24 -0800 (PST) Received: by 10.54.44.56 with HTTP; Sat, 29 Jan 2005 19:26:24 -0800 (PST) Message-ID: <47d0403c05012919264bfdecd1@mail.gmail.com> Date: Sat, 29 Jan 2005 21:26:24 -0600 From: Ben Kaduk To: freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_998_135011.1107055584251" Subject: panic (trap 12 page fault) in bfe driver X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Ben Kaduk List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jan 2005 03:26:25 -0000 ------=_Part_998_135011.1107055584251 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline prolepsis# uname -a FreeBSD prolepsis.mooo.com 5.3-STABLE FreeBSD 5.3-STABLE #0: Wed Dec 15 23:44:53 CST 2004 root@prolepsis.mooo.com:/usr/obj/usr/src/sys/GENERIC i386 On my laptop, issuing a simple: # ifconfig bfe0 down # ifconfig bfe0 up causes the following panic (hand transcribed): Fatal trap 12: page fault while in kernel mode fault virtual address = 0xb fault code = supervisor read, page not present instruction pointer = 0x8:0xc0832b46 stack pointer = 0x10:0xf0811abc frame pointer = 0x10:0xf0811ad0 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 = 10990 (ifconfig) trap number = 12 panic: page fault Uptime: 2d21h46m17s last logged console messages: Jan 29 15:37:33 prolepsis dhclient: send_packet: Network is down Jan 29 15:37:36 prolepsis last message repeated 2 times Jan 29 15:37:40 prolepsis login: ROOT LOGIN (root) on ttyv1 Jan 29 15:37:43 prolepsis dhclient: send_packet: Network is down I had issued the 'ifconfig bfe0 down' then unplugged the ethernet cable, moved to a different jack, and plugged the cable in; the root login was me logging in to issue the 'ifconfig bfe0 up' command. It appears that there had been some local trouble on the local network, as the send_packet messages were also present on my other machine; the network trouble seemed to affect the dhcp server, because upon reboot dhclient did not seem to be able to find a server, assigning a 10.0.0.1 address (instead of the 130.126.xx.xx that should have shown up), prompting me to issue another sequence of 'ifconfig bfe0 down' and 'ifconfig bfe0 up' which resulted in the same panic. Is this panic caused by external troubles, or should I provide further information? I am currently building a debug kernel (GENERIC + DDB, KDB) -- are there any other options that I should include? The dmesg of a verbose boot is attached. Thanks Benjamin Kaduk ------=_Part_998_135011.1107055584251 Content-Type: application/octet-stream; name="dmesg.boot.verbose" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="dmesg.boot.verbose" Q29weXJpZ2h0IChjKSAxOTkyLTIwMDQgVGhlIEZyZWVCU0QgUHJvamVjdC4KQ29weXJpZ2h0IChj KSAxOTc5LCAxOTgwLCAxOTgzLCAxOTg2LCAxOTg4LCAxOTg5LCAxOTkxLCAxOTkyLCAxOTkzLCAx OTk0CglUaGUgUmVnZW50cyBvZiB0aGUgVW5pdmVyc2l0eSBvZiBDYWxpZm9ybmlhLiBBbGwgcmln aHRzIHJlc2VydmVkLgpGcmVlQlNEIDUuMy1TVEFCTEUgIzA6IFdlZCBEZWMgMTUgMjM6NDQ6NTMg Q1NUIDIwMDQKICAgIHJvb3RAcHJvbGVwc2lzLm1vb28uY29tOi91c3Ivb2JqL3Vzci9zcmMvc3lz L0dFTkVSSUMKUHJlbG9hZGVkIGVsZiBrZXJuZWwgIi9ib290L2tlcm5lbC9rZXJuZWwiIGF0IDB4 YzBmOGIwMDAuClByZWxvYWRlZCBlbGYgbW9kdWxlICIvYm9vdC9rZXJuZWwvbGludXgua28iIGF0 IDB4YzBmOGIxZDguClByZWxvYWRlZCBlbGYgbW9kdWxlICIvYm9vdC9tb2R1bGVzL252aWRpYS5r byIgYXQgMHhjMGY4YjI4NC4KUHJlbG9hZGVkIGVsZiBtb2R1bGUgIi9ib290L2tlcm5lbC9hY3Bp LmtvIiBhdCAweGMwZjhiMzMwLgpDYWxpYnJhdGluZyBjbG9jayhzKSAuLi4gaTgyNTQgY2xvY2s6 IDExOTMxNjcgSHoKQ0xLX1VTRV9JODI1NF9DQUxJQlJBVElPTiBub3Qgc3BlY2lmaWVkIC0gdXNp bmcgZGVmYXVsdCBmcmVxdWVuY3kKVGltZWNvdW50ZXIgImk4MjU0IiBmcmVxdWVuY3kgMTE5MzE4 MiBIeiBxdWFsaXR5IDAKQ2FsaWJyYXRpbmcgVFNDIGNsb2NrIC4uLiBUU0MgY2xvY2s6IDI0OTI2 NTI2NTIgSHoKQ1BVOiBNb2JpbGUgSW50ZWwoUikgUGVudGl1bShSKSA0IC0gTSBDUFUgMi41MEdI eiAoMjQ5Mi42NS1NSHogNjg2LWNsYXNzIENQVSkKICBPcmlnaW4gPSAiR2VudWluZUludGVsIiAg SWQgPSAweGYyOSAgU3RlcHBpbmcgPSA5CiAgRmVhdHVyZXM9MHhiZmViZjlmZjxGUFUsVk1FLERF LFBTRSxUU0MsTVNSLFBBRSxNQ0UsQ1g4LFNFUCxNVFJSLFBHRSxNQ0EsQ01PVixQQVQsUFNFMzYs Q0xGTFVTSCxEVFMsQUNQSSxNTVgsRlhTUixTU0UsU1NFMixTUyxIVFQsVE0sUEJFPgpyZWFsIG1l bW9yeSAgPSAxMDczNDA1OTUyICgxMDIzIE1CKQpQaHlzaWNhbCBtZW1vcnkgY2h1bmsocyk6CjB4 MDAwMDAwMDAwMDAwMTAwMCAtIDB4MDAwMDAwMDAwMDA5ZWZmZiwgNjQ3MTY4IGJ5dGVzICgxNTgg cGFnZXMpCjB4MDAwMDAwMDAwMDEwMDAwMCAtIDB4MDAwMDAwMDAwMDNmZmZmZiwgMzE0NTcyOCBi eXRlcyAoNzY4IHBhZ2VzKQoweDAwMDAwMDAwMDEwMjYwMDAgLSAweDAwMDAwMDAwM2VkN2VmZmYs IDEwMzc0MDYyMDggYnl0ZXMgKDI1MzI3MyBwYWdlcykKYXZhaWwgbWVtb3J5ID0gMTAzNjY1MjU0 NCAoOTg4IE1CKQpiaW9zMzI6IEZvdW5kIEJJT1MzMiBTZXJ2aWNlIERpcmVjdG9yeSBoZWFkZXIg YXQgMHhjMDBmZmU4MApiaW9zMzI6IEVudHJ5ID0gMHhmZmU5MCAoYzAwZmZlOTApICBSZXYgPSAw ICBMZW4gPSAxCnBjaWJpb3M6IFBDSSBCSU9TIGVudHJ5IGF0IDB4ZjAwMDArMHhjOTZlCnBucGJp b3M6IEZvdW5kIFBuUCBCSU9TIGRhdGEgYXQgMHhjMDBmZTJkMApwbnBiaW9zOiBFbnRyeSA9IGYw MDAwOmUyZjQgIFJldiA9IDEuMApwbnBiaW9zOiBFdmVudCBmbGFnIGF0IDRiNApPdGhlciBCSU9T IHNpZ25hdHVyZXMgZm91bmQ6CndsYW46IDw4MDIuMTEgTGluayBMYXllcj4KcmFuZG9tOiA8ZW50 cm9weSBzb3VyY2UsIFNvZnR3YXJlLCBZYXJyb3c+CmlvOiA8SS9PPgptZW06IDxtZW1vcnk+ClBl bnRpdW0gUHJvIE1UUlIgc3VwcG9ydCBlbmFibGVkCm51bGw6IDxudWxsIGRldmljZSwgemVybyBk ZXZpY2U+Cm5weDA6IFtGQVNUXQpucHgwOiA8bWF0aCBwcm9jZXNzb3I+IG9uIG1vdGhlcmJvYXJk Cm5weDA6IElOVCAxNiBpbnRlcmZhY2UKYWNwaTA6IDxERUxMIENQaSBSICA+IG9uIG1vdGhlcmJv YXJkCmFjcGkwOiBbTVBTQUZFXQpwY2lfb3BlbigxKToJbW9kZSAxIGFkZHIgcG9ydCAoMHgwY2Y4 KSBpcyAweDgwMDBlYWM0CnBjaV9vcGVuKDFhKToJbW9kZTFyZXM9MHg4MDAwMDAwMCAoMHg4MDAw MDAwMCkKcGNpX2NmZ2NoZWNrOglkZXZpY2UgMCBbY2xhc3M9MDYwMDAwXSBbaGRyPTAwXSBpcyB0 aGVyZSAoaWQ9MWEzMDgwODYpCnBjaWJpb3M6IEJJT1MgdmVyc2lvbiAyLjEwCkZvdW5kICRQSVIg dGFibGUsIDkgZW50cmllcyBhdCAweGMwMGZjNTgwClBDSS1Pbmx5IEludGVycnVwdHM6IG5vbmUK TG9jYXRpb24gIEJ1cyBEZXZpY2UgUGluICBMaW5rICBJUlFzCmVtYmVkZGVkICAgIDAgICAyOSAg ICBBICAgMHg2MCAgMyA0IDUgNiA3IDkgMTAgMTEgMTIgMTQgMTUKZW1iZWRkZWQgICAgMCAgIDI5 ICAgIEIgICAweDYzICAzIDQgNSA2IDcgOSAxMCAxMSAxMiAxNCAxNQplbWJlZGRlZCAgICAwICAg MjkgICAgQyAgIDB4NjIgIDMgNCA1IDYgNyA5IDEwIDExIDEyIDE0IDE1CmVtYmVkZGVkICAgIDAg ICAyOSAgICBEICAgMHg2YiAgMyA0IDUgNiA3IDkgMTAgMTEgMTIgMTQgMTUKZW1iZWRkZWQgICAg MCAgIDMwICAgIEEgICAweDYwICAzIDQgNSA2IDcgOSAxMCAxMSAxMiAxNCAxNQplbWJlZGRlZCAg ICAwICAgMzAgICAgQiAgIDB4NjEgIDMgNCA1IDYgNyA5IDEwIDExIDEyIDE0IDE1CmVtYmVkZGVk ICAgIDAgICAzMCAgICBDICAgMHg2MiAgMyA0IDUgNiA3IDkgMTAgMTEgMTIgMTQgMTUKZW1iZWRk ZWQgICAgMCAgIDMwICAgIEQgICAweDYzICAzIDQgNSA2IDcgOSAxMCAxMSAxMiAxNCAxNQplbWJl ZGRlZCAgICAwICAgMzEgICAgQSAgIDB4NjIgIDMgNCA1IDYgNyA5IDEwIDExIDEyIDE0IDE1CmVt YmVkZGVkICAgIDAgICAzMSAgICBCICAgMHg2MSAgMyA0IDUgNiA3IDkgMTAgMTEgMTIgMTQgMTUK ZW1iZWRkZWQgICAgMSAgICAwICAgIEEgICAweDYwICAzIDQgNSA2IDcgOSAxMCAxMSAxMiAxNCAx NQplbWJlZGRlZCAgICAyICAgIDAgICAgQSAgIDB4NjIgIDMgNCA1IDYgNyA5IDEwIDExIDEyIDE0 IDE1CmVtYmVkZGVkICAgIDIgICAgMSAgICBBICAgMHg2MyAgMyA0IDUgNiA3IDkgMTAgMTEgMTIg MTQgMTUKZW1iZWRkZWQgICAgMiAgICAxICAgIEIgICAweDYzICBub25lCmVtYmVkZGVkICAgIDIg ICAgMyAgICBBICAgMHg2MSAgMyA0IDUgNiA3IDkgMTAgMTEgMTIgMTQgMTUKZW1iZWRkZWQgICAg MiAgICAzICAgIEIgICAweDYzICAzIDQgNSA2IDcgOSAxMCAxMSAxMiAxNCAxNQplbWJlZGRlZCAg ICA4ICAgIDAgICAgQSAgIDB4NjEgIDMgNCA1IDYgNyA5IDEwIDExIDEyIDE0IDE1CmVtYmVkZGVk ICAgIDggICAgMCAgICBCICAgMHg2MyAgMyA0IDUgNiA3IDkgMTAgMTEgMTIgMTQgMTUKZW1iZWRk ZWQgICAgOCAgICAxICAgIEEgICAweDYxICAzIDQgNSA2IDcgOSAxMCAxMSAxMiAxNCAxNQplbWJl ZGRlZCAgICA4ICAgIDEgICAgQiAgIDB4NjMgIDMgNCA1IDYgNyA5IDEwIDExIDEyIDE0IDE1CmFj cGlfYnVzX251bWJlcjogcm9vdCBidXMgaGFzIG5vIF9CQk4sIGFzc3VtaW5nIDAKQWNwaU9zRGVy aXZlUGNpSWQ6IGJ1cyAwIGRldiAzMSBmdW5jIDAKYWNwaV9idXNfbnVtYmVyOiByb290IGJ1cyBo YXMgbm8gX0JCTiwgYXNzdW1pbmcgMApBY3BpT3NEZXJpdmVQY2lJZDogYnVzIDAgZGV2IDMxIGZ1 bmMgMAphdHBpYzogUHJvZ3JhbW1pbmcgSVJROSBhcyBsZXZlbC9sb3cKQUNQSSB0aW1lcjogMS8x IDEvMSAxLzEgMS8xIDEvMSAxLzEgMS8xIDEvMSAxLzEgMS8xIC0+IDEwClRpbWVjb3VudGVyICJB Q1BJLWZhc3QiIGZyZXF1ZW5jeSAzNTc5NTQ1IEh6IHF1YWxpdHkgMTAwMAphY3BpX3RpbWVyMDog PDI0LWJpdCB0aW1lciBhdCAzLjU3OTU0NU1Iej4gcG9ydCAweDgwOC0weDgwYiBvbiBhY3BpMApj cHUwOiA8QUNQSSBDUFUgKDQgQ3ggc3RhdGVzKT4gb24gYWNwaTAKYWNwaV90ejA6IDxUaGVybWFs IFpvbmU+IG9uIGFjcGkwCmFjcGlfYWNhZDA6IDxBQyBBZGFwdGVyPiBvbiBhY3BpMAphY3BpX2Nt YmF0MDogPENvbnRyb2wgTWV0aG9kIEJhdHRlcnk+IG9uIGFjcGkwCmFjcGlfY21iYXQxOiA8Q29u dHJvbCBNZXRob2QgQmF0dGVyeT4gb24gYWNwaTAKYWNwaV9saWQwOiA8Q29udHJvbCBNZXRob2Qg TGlkIFN3aXRjaD4gb24gYWNwaTAKYWNwaV9idXR0b24wOiA8UG93ZXIgQnV0dG9uPiBvbiBhY3Bp MAphY3BpX2J1dHRvbjE6IDxTbGVlcCBCdXR0b24+IG9uIGFjcGkwCnBjaWIwOiA8QUNQSSBIb3N0 LVBDSSBicmlkZ2U+IHBvcnQgMHhjZjgtMHhjZmYgb24gYWNwaTAKQUNQSSBsaW5rIFxcX1NCXy5Q Q0kwLkxOS0IgaGFzIGludmFsaWQgaW5pdGlhbCBpcnEgMTEsIGlnbm9yaW5nCkFDUEkgUENJIGxp bmsgaW5pdGlhbCBjb25maWd1cmF0aW9uOgpcXF9TQl8uUENJMC5MTktBIGlycSAgMDogWyA5IDEw IDExXSAxMSsgbG93LGxldmVsLHNoYXJhYmxlIDAuMzEuMApcXF9TQl8uUENJMC5MTktCIGlycSAg MDogWyA1ICA3XSAgMCsgbG93LGxldmVsLHNoYXJhYmxlIDAuMzEuMQpcXF9TQl8uUENJMC5MTktD IGlycSAgMDogWyA5IDEwIDExXSAxMSsgbG93LGxldmVsLHNoYXJhYmxlIDAuMzEuMgpcXF9TQl8u UENJMC5MTktEIGlycSAgMDogWyA1ICA3ICA5IDEwIDExXSAxMSsgbG93LGxldmVsLHNoYXJhYmxl IDAuMzEuMwpcXF9TQl8uUENJMC5MTktBIGlycSAgMDogWyA5IDEwIDExXSAxMSsgbG93LGxldmVs LHNoYXJhYmxlIDAuMjkuMApcXF9TQl8uUENJMC5MTktEIGlycSAgMDogWyA1ICA3ICA5IDEwIDEx XSAxMSsgbG93LGxldmVsLHNoYXJhYmxlIDAuMjkuMQpcXF9TQl8uUENJMC5MTktDIGlycSAgMDog WyA5IDEwIDExXSAxMSsgbG93LGxldmVsLHNoYXJhYmxlIDAuMjkuMgpcXF9TQl8uUENJMC5MTktI IGlycSAgMDogWyAzICA0ICA1ICA2ICA3ICA5IDEwIDExIDEyIDE0IDE1XSAxMSsgbG93LGxldmVs LHNoYXJhYmxlIDAuMjkuMwpcXF9TQl8uUENJMC5MTktBIGlycSAgMDogWyA5IDEwIDExXSAxMSsg bG93LGxldmVsLHNoYXJhYmxlIDAuMS4wClxcX1NCXy5QQ0kwLkxOS0IgaXJxICAwOiBbIDUgIDdd ICAwKyBsb3csbGV2ZWwsc2hhcmFibGUgMC4xLjEKcGNpMDogPEFDUEkgUENJIGJ1cz4gb24gcGNp YjAKcGNpMDogcGh5c2ljYWwgYnVzPTAKCW1hcFsxMF06IHR5cGUgMywgcmFuZ2UgMzIsIGJhc2Ug ZTgwMDAwMDAsIHNpemUgMjcsIGVuYWJsZWQKZm91bmQtPgl2ZW5kb3I9MHg4MDg2LCBkZXY9MHgx YTMwLCByZXZpZD0weDA0CglidXM9MCwgc2xvdD0wLCBmdW5jPTAKCWNsYXNzPTA2LTAwLTAwLCBo ZHJ0eXBlPTB4MDAsIG1mZGV2PTAKCWNtZHJlZz0weDAxMDYsIHN0YXRyZWc9MHgyMDkwLCBjYWNo ZWxuc3o9MCAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgwIG5z KSwgbWF4bGF0PTB4MDAgKDAgbnMpCmZvdW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4MWEzMSwg cmV2aWQ9MHgwNAoJYnVzPTAsIHNsb3Q9MSwgZnVuYz0wCgljbGFzcz0wNi0wNC0wMCwgaGRydHlw ZT0weDAxLCBtZmRldj0wCgljbWRyZWc9MHgwMTA3LCBzdGF0cmVnPTB4MDBhMCwgY2FjaGVsbnN6 PTAgKGR3b3JkcykKCWxhdHRpbWVyPTB4MjAgKDk2MCBucyksIG1pbmdudD0weDBjICgzMDAwIG5z KSwgbWF4bGF0PTB4MDAgKDAgbnMpCgltYXBbMjBdOiB0eXBlIDQsIHJhbmdlIDMyLCBiYXNlIDAw MDBiZjgwLCBzaXplICA1LCBlbmFibGVkCnBjaWIwOiBtYXRjaGVkIGVudHJ5IGZvciAwLjI5LklO VEEgKHNyYyBcXF9TQl8uUENJMC5MTktBKQpwY2liMDogcG9zc2libGUgaW50ZXJydXB0czogIDkg MTAgMTEKQUNQSSBQQ0kgbGluayBhcmJpdHJhdGVkIHNldHRpbmdzOgpcXF9TQl8uUENJMC5MTktI IChyZWZlcmVuY2VzIDEsIHByaW9yaXR5IDExNDExKToKCWludGVycnVwdHM6CSAgICAxMSAgICAx MCAgICAgNSAgICAgOSAgICAxMiAgICAgNiAgICAgNCAgICAgMyAgICAgNyAgICAxNSAgICAxNAoJ cGVuYWx0eToJICAgIDgwICAgIDgwICAgMTAwICAgMTYwICA1MDEwICA1MDEwICA1MDEwICA1MDEw ICA1MDUwIDUwMDEwIDUwMDEwClxcX1NCXy5QQ0kwLkxOS0IgKHJlZmVyZW5jZXMgMiwgcHJpb3Jp dHkgNTE1MCk6CglpbnRlcnJ1cHRzOgkgICAgIDUgICAgIDcKCXBlbmFsdHk6CSAgIDEwMCAgNTA1 MApcXF9TQl8uUENJMC5MTktEIChyZWZlcmVuY2VzIDIsIHByaW9yaXR5IDIxODgpOgoJaW50ZXJy dXB0czoJICAgIDExICAgIDEwICAgICA1ICAgICA5ICAgICA3CglwZW5hbHR5OgkgICAgODAgICAg ODAgICAxMDAgICAxNjAgIDUwNTAKXFxfU0JfLlBDSTAuTE5LQSAocmVmZXJlbmNlcyAzLCBwcmlv cml0eSAzMjApOgoJaW50ZXJydXB0czoJICAgIDExICAgIDEwICAgICA5CglwZW5hbHR5OgkgICAg ODAgICAgODAgICAxNjAKXFxfU0JfLlBDSTAuTE5LQyAocmVmZXJlbmNlcyAyLCBwcmlvcml0eSAy MTMpOgoJaW50ZXJydXB0czoJICAgIDExICAgIDEwICAgICA5CglwZW5hbHR5OgkgICAgODAgICAg ODAgICAxNjAKcGNpYjA6IHNsb3QgMjkgSU5UQSByb3V0ZWQgdG8gaXJxIDExIHZpYSBcXF9TQl8u UENJMC5MTktBCmZvdW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4MjRjMiwgcmV2aWQ9MHgwMwoJ YnVzPTAsIHNsb3Q9MjksIGZ1bmM9MAoJY2xhc3M9MGMtMDMtMDAsIGhkcnR5cGU9MHgwMCwgbWZk ZXY9MQoJY21kcmVnPTB4MDAwNSwgc3RhdHJlZz0weDAyODAsIGNhY2hlbG5zej0wIChkd29yZHMp CglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAo MCBucykKCWludHBpbj1hLCBpcnE9MTEKCW1hcFsyMF06IHR5cGUgNCwgcmFuZ2UgMzIsIGJhc2Ug MDAwMGJmNDAsIHNpemUgIDUsIGVuYWJsZWQKcGNpYjA6IG1hdGNoZWQgZW50cnkgZm9yIDAuMjku SU5UQiAoc3JjIFxcX1NCXy5QQ0kwLkxOS0QpCnBjaWIwOiBwb3NzaWJsZSBpbnRlcnJ1cHRzOiAg NSAgNyAgOSAxMCAxMQpBQ1BJIFBDSSBsaW5rIGFyYml0cmF0ZWQgc2V0dGluZ3M6ClxcX1NCXy5Q Q0kwLkxOS0ggKHJlZmVyZW5jZXMgMSwgcHJpb3JpdHkgMTE0NTgpOgoJaW50ZXJydXB0czoJICAg ICA1ICAgIDEwICAgIDExICAgICA5ICAgIDEyICAgICA2ICAgICA0ICAgICAzICAgICA3ICAgIDE1 ICAgIDE0CglwZW5hbHR5OgkgICAxNTAgICAxNjAgICAxOTAgICAzMjAgIDUwMjAgIDUwMjAgIDUw MjAgIDUwMjAgIDUxMDAgNTAwMjAgNTAwMjAKXFxfU0JfLlBDSTAuTE5LQiAocmVmZXJlbmNlcyAy LCBwcmlvcml0eSA1MjUwKToKCWludGVycnVwdHM6CSAgICAgNSAgICAgNwoJcGVuYWx0eToJICAg MTUwICA1MTAwClxcX1NCXy5QQ0kwLkxOS0QgKHJlZmVyZW5jZXMgMiwgcHJpb3JpdHkgMjM2OCk6 CglpbnRlcnJ1cHRzOgkgICAgIDUgICAgMTAgICAgMTEgICAgIDkgICAgIDcKCXBlbmFsdHk6CSAg IDE1MCAgIDE2MCAgIDE5MCAgIDMyMCAgNTEwMApcXF9TQl8uUENJMC5MTktDIChyZWZlcmVuY2Vz IDIsIHByaW9yaXR5IDQ0Nik6CglpbnRlcnJ1cHRzOgkgICAgMTAgICAgMTEgICAgIDkKCXBlbmFs dHk6CSAgIDE2MCAgIDE5MCAgIDMyMApwY2liMDogc2xvdCAyOSBJTlRCIHJvdXRlZCB0byBpcnEg MTEgdmlhIFxcX1NCXy5QQ0kwLkxOS0QKZm91bmQtPgl2ZW5kb3I9MHg4MDg2LCBkZXY9MHgyNGM0 LCByZXZpZD0weDAzCglidXM9MCwgc2xvdD0yOSwgZnVuYz0xCgljbGFzcz0wYy0wMy0wMCwgaGRy dHlwZT0weDAwLCBtZmRldj0wCgljbWRyZWc9MHgwMDA1LCBzdGF0cmVnPTB4MDI4MCwgY2FjaGVs bnN6PTAgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyks IG1heGxhdD0weDAwICgwIG5zKQoJaW50cGluPWIsIGlycT0xMQoJbWFwWzIwXTogdHlwZSA0LCBy YW5nZSAzMiwgYmFzZSAwMDAwYmYyMCwgc2l6ZSAgNSwgZW5hYmxlZApwY2liMDogbWF0Y2hlZCBl bnRyeSBmb3IgMC4yOS5JTlRDIChzcmMgXFxfU0JfLlBDSTAuTE5LQykKcGNpYjA6IHBvc3NpYmxl IGludGVycnVwdHM6ICA5IDEwIDExCkFDUEkgUENJIGxpbmsgYXJiaXRyYXRlZCBzZXR0aW5nczoK XFxfU0JfLlBDSTAuTE5LSCAocmVmZXJlbmNlcyAxLCBwcmlvcml0eSAxMTUwMyk6CglpbnRlcnJ1 cHRzOgkgICAgIDUgICAgMTAgICAgMTEgICAgIDkgICAgMTIgICAgIDYgICAgIDQgICAgIDMgICAg IDcgICAgMTUgICAgMTQKCXBlbmFsdHk6CSAgIDIwMCAgIDI0MCAgIDI5MCAgIDQ4MCAgNTAzMCAg NTAzMCAgNTAzMCAgNTAzMCAgNTE1MCA1MDAzMCA1MDAzMApcXF9TQl8uUENJMC5MTktCIChyZWZl cmVuY2VzIDIsIHByaW9yaXR5IDUzNTApOgoJaW50ZXJydXB0czoJICAgICA1ICAgICA3CglwZW5h bHR5OgkgICAyMDAgIDUxNTAKXFxfU0JfLlBDSTAuTE5LQyAocmVmZXJlbmNlcyAyLCBwcmlvcml0 eSA2NzMpOgoJaW50ZXJydXB0czoJICAgIDEwICAgIDExICAgICA5CglwZW5hbHR5OgkgICAyNDAg ICAyOTAgICA0ODAKcGNpYjA6IHNsb3QgMjkgSU5UQyByb3V0ZWQgdG8gaXJxIDExIHZpYSBcXF9T Ql8uUENJMC5MTktDCmZvdW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4MjRjNywgcmV2aWQ9MHgw MwoJYnVzPTAsIHNsb3Q9MjksIGZ1bmM9MgoJY2xhc3M9MGMtMDMtMDAsIGhkcnR5cGU9MHgwMCwg bWZkZXY9MAoJY21kcmVnPTB4MDAwNSwgc3RhdHJlZz0weDAyODAsIGNhY2hlbG5zej0wIChkd29y ZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgw MCAoMCBucykKCWludHBpbj1jLCBpcnE9MTEKCW1hcFsxMF06IHR5cGUgMSwgcmFuZ2UgMzIsIGJh c2UgZjRmZmZjMDAsIHNpemUgMTAsIGVuYWJsZWQKcGNpYjA6IG1hdGNoZWQgZW50cnkgZm9yIDAu MjkuSU5URCAoc3JjIFxcX1NCXy5QQ0kwLkxOS0gpCnBjaWIwOiBwb3NzaWJsZSBpbnRlcnJ1cHRz OiAgMyAgNCAgNSAgNiAgNyAgOSAxMCAxMSAxMiAxNCAxNQpBQ1BJIFBDSSBsaW5rIGFyYml0cmF0 ZWQgc2V0dGluZ3M6ClxcX1NCXy5QQ0kwLkxOS0ggKHJlZmVyZW5jZXMgMSwgcHJpb3JpdHkgMTE1 NDkpOgoJaW50ZXJydXB0czoJICAgICA1ICAgIDEwICAgIDExICAgICA5ICAgIDEyICAgICA2ICAg ICA0ICAgICAzICAgICA3ICAgIDE1ICAgIDE0CglwZW5hbHR5OgkgICAyNTAgICAzMjAgICAzOTAg ICA2NDAgIDUwNDAgIDUwNDAgIDUwNDAgIDUwNDAgIDUyMDAgNTAwNDAgNTAwNDAKXFxfU0JfLlBD STAuTE5LQiAocmVmZXJlbmNlcyAyLCBwcmlvcml0eSA1NDUwKToKCWludGVycnVwdHM6CSAgICAg NSAgICAgNwoJcGVuYWx0eToJICAgMjUwICA1MjAwCnBjaWIwOiBzbG90IDI5IElOVEQgcm91dGVk IHRvIGlycSAxMSB2aWEgXFxfU0JfLlBDSTAuTE5LSApmb3VuZC0+CXZlbmRvcj0weDgwODYsIGRl dj0weDI0Y2QsIHJldmlkPTB4MDMKCWJ1cz0wLCBzbG90PTI5LCBmdW5jPTcKCWNsYXNzPTBjLTAz LTIwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTAKCWNtZHJlZz0weDAxMDYsIHN0YXRyZWc9MHgwMjkw LCBjYWNoZWxuc3o9MCAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAw ICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCglpbnRwaW49ZCwgaXJxPTExCglwb3dlcnNwZWMg MiAgc3VwcG9ydHMgRDAgRDMgIGN1cnJlbnQgRDAKZm91bmQtPgl2ZW5kb3I9MHg4MDg2LCBkZXY9 MHgyNDQ4LCByZXZpZD0weDgzCglidXM9MCwgc2xvdD0zMCwgZnVuYz0wCgljbGFzcz0wNi0wNC0w MCwgaGRydHlwZT0weDAxLCBtZmRldj0wCgljbWRyZWc9MHgwMTA3LCBzdGF0cmVnPTB4ODA4MCwg Y2FjaGVsbnN6PTAgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwNCAo MTAwMCBucyksIG1heGxhdD0weDAwICgwIG5zKQpmb3VuZC0+CXZlbmRvcj0weDgwODYsIGRldj0w eDI0Y2MsIHJldmlkPTB4MDMKCWJ1cz0wLCBzbG90PTMxLCBmdW5jPTAKCWNsYXNzPTA2LTAxLTAw LCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTEKCWNtZHJlZz0weDAxMGYsIHN0YXRyZWc9MHgwMjgwLCBj YWNoZWxuc3o9MCAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgw IG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCgltYXBbMjBdOiB0eXBlIDQsIHJhbmdlIDMyLCBiYXNl IDAwMDBiZmEwLCBzaXplICA0LCBlbmFibGVkCmZvdW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4 MjRjYSwgcmV2aWQ9MHgwMwoJYnVzPTAsIHNsb3Q9MzEsIGZ1bmM9MQoJY2xhc3M9MDEtMDEtOGEs IGhkcnR5cGU9MHgwMCwgbWZkZXY9MAoJY21kcmVnPTB4MDAwNSwgc3RhdHJlZz0weDAyODAsIGNh Y2hlbG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAg bnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCWludHBpbj1hLCBpcnE9MjU1CgltYXBbMTBdOiB0eXBl IDQsIHJhbmdlIDMyLCBiYXNlIDAwMDBiODAwLCBzaXplICA4LCBlbmFibGVkCgltYXBbMTRdOiB0 eXBlIDQsIHJhbmdlIDMyLCBiYXNlIDAwMDBiYzQwLCBzaXplICA2LCBlbmFibGVkCgltYXBbMThd OiB0eXBlIDEsIHJhbmdlIDMyLCBiYXNlIGY0ZmZmODAwLCBzaXplICA5LCBlbmFibGVkCgltYXBb MWNdOiB0eXBlIDEsIHJhbmdlIDMyLCBiYXNlIGY0ZmZmNDAwLCBzaXplICA4LCBlbmFibGVkCnBj aWIwOiBtYXRjaGVkIGVudHJ5IGZvciAwLjMxLklOVEIgKHNyYyBcXF9TQl8uUENJMC5MTktCKQpw Y2liMDogcG9zc2libGUgaW50ZXJydXB0czogIDUgIDcKQUNQSSBQQ0kgbGluayBhcmJpdHJhdGVk IHNldHRpbmdzOgpcXF9TQl8uUENJMC5MTktCIChyZWZlcmVuY2VzIDIsIHByaW9yaXR5IDU1NTAp OgoJaW50ZXJydXB0czoJICAgICA1ICAgICA3CglwZW5hbHR5OgkgICAzMDAgIDUyNTAKYXRwaWM6 IFByb2dyYW1taW5nIElSUTUgYXMgbGV2ZWwvbG93CnBjaWIwOiBzbG90IDMxIElOVEIgcm91dGVk IHRvIGlycSA1IHZpYSBcXF9TQl8uUENJMC5MTktCCmZvdW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2 PTB4MjRjNSwgcmV2aWQ9MHgwMwoJYnVzPTAsIHNsb3Q9MzEsIGZ1bmM9NQoJY2xhc3M9MDQtMDEt MDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MAoJY21kcmVnPTB4MDAwNywgc3RhdHJlZz0weDAyOTAs IGNhY2hlbG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAg KDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCWludHBpbj1iLCBpcnE9NQoJcG93ZXJzcGVjIDIg IHN1cHBvcnRzIEQwIEQzICBjdXJyZW50IEQwCgltYXBbMTBdOiB0eXBlIDQsIHJhbmdlIDMyLCBi YXNlIDAwMDBiNDAwLCBzaXplICA4LCBlbmFibGVkCgltYXBbMTRdOiB0eXBlIDQsIHJhbmdlIDMy LCBiYXNlIDAwMDBiMDgwLCBzaXplICA3LCBlbmFibGVkCnBjaWIwOiBtYXRjaGVkIGVudHJ5IGZv ciAwLjMxLklOVEIgKHNyYyBcXF9TQl8uUENJMC5MTktCKQpwY2liMDogc2xvdCAzMSBJTlRCIGlz IGFscmVhZHkgcm91dGVkIHRvIGlycSA1CmZvdW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4MjRj NiwgcmV2aWQ9MHgwMwoJYnVzPTAsIHNsb3Q9MzEsIGZ1bmM9NgoJY2xhc3M9MDctMDMtMDAsIGhk cnR5cGU9MHgwMCwgbWZkZXY9MAoJY21kcmVnPTB4MDAwNSwgc3RhdHJlZz0weDAyOTAsIGNhY2hl bG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMp LCBtYXhsYXQ9MHgwMCAoMCBucykKCWludHBpbj1iLCBpcnE9NQoJcG93ZXJzcGVjIDIgIHN1cHBv cnRzIEQwIEQzICBjdXJyZW50IEQwCmFncDA6IDxJbnRlbCA4Mjg0NSBob3N0IHRvIEFHUCBicmlk Z2U+IG1lbSAweGU4MDAwMDAwLTB4ZWZmZmZmZmYgYXQgZGV2aWNlIDAuMCBvbiBwY2kwCmFncDA6 IFJlc2VydmVkIDB4ODAwMDAwMCBieXRlcyBmb3IgcmlkIDB4MTAgdHlwZSAzIGF0IDB4ZTgwMDAw MDAKYWdwMDogYWxsb2NhdGluZyBHQVRUIGZvciBhcGVydHVyZSBvZiBzaXplIDEyOE0KcGNpYjE6 IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgMS4wIG9uIHBjaTAKcGNpYjE6ICAgc2Vj b25kYXJ5IGJ1cyAgICAgMQpwY2liMTogICBzdWJvcmRpbmF0ZSBidXMgICAxCnBjaWIxOiAgIEkv TyBkZWNvZGUgICAgICAgIDB4YzAwMC0weGNmZmYKcGNpYjE6ICAgbWVtb3J5IGRlY29kZSAgICAg MHhmYzAwMDAwMC0weGZkZmZmZmZmCnBjaWIxOiAgIHByZWZldGNoZWQgZGVjb2RlIDB4ZjAwMDAw MDAtMHhmM2ZmZmZmZgpBQ1BJIFBDSSBsaW5rIGluaXRpYWwgY29uZmlndXJhdGlvbjoKXFxfU0Jf LlBDSTAuTE5LQSBpcnEqMTE6IFsgOSAxMCAxMV0gMTErIGxvdyxsZXZlbCxzaGFyYWJsZSAxLjAu MApwY2kxOiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liMQpwY2kxOiBwaHlzaWNhbCBidXM9MQoJbWFw WzEwXTogdHlwZSAxLCByYW5nZSAzMiwgYmFzZSBmYzAwMDAwMCwgc2l6ZSAyNCwgZW5hYmxlZApw Y2liMTogZGV2aWNlIChudWxsKSByZXF1ZXN0ZWQgZGVjb2RlZCBtZW1vcnkgcmFuZ2UgMHhmYzAw MDAwMC0weGZjZmZmZmZmCgltYXBbMTRdOiB0eXBlIDMsIHJhbmdlIDMyLCBiYXNlIGYwMDAwMDAw LCBzaXplIDI2LCBlbmFibGVkCnBjaWIxOiBkZXZpY2UgKG51bGwpIHJlcXVlc3RlZCBkZWNvZGVk IG1lbW9yeSByYW5nZSAweGYwMDAwMDAwLTB4ZjNmZmZmZmYKcGNpYjE6IG1hdGNoZWQgZW50cnkg Zm9yIDEuMC5JTlRBIChzcmMgXFxfU0JfLlBDSTAuTE5LQSkKcGNpYjE6IHNsb3QgMCBJTlRBIGlz IGFscmVhZHkgcm91dGVkIHRvIGlycSAxMQpmb3VuZC0+CXZlbmRvcj0weDEwZGUsIGRldj0weDAy ODYsIHJldmlkPTB4YTEKCWJ1cz0xLCBzbG90PTAsIGZ1bmM9MAoJY2xhc3M9MDMtMDAtMDAsIGhk cnR5cGU9MHgwMCwgbWZkZXY9MAoJY21kcmVnPTB4MDAyNywgc3RhdHJlZz0weDAyYjAsIGNhY2hl bG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0weDIwICg5NjAgbnMpLCBtaW5nbnQ9MHgwNSAoMTI1 MCBucyksIG1heGxhdD0weDAxICgyNTAgbnMpCglpbnRwaW49YSwgaXJxPTExCglwb3dlcnNwZWMg MiAgc3VwcG9ydHMgRDAgRDMgIGN1cnJlbnQgRDAKbnZpZGlhMDogPEdlRm9yY2U0IDQyMDAgR28+ IG1lbSAweGYwMDAwMDAwLTB4ZjNmZmZmZmYsMHhmYzAwMDAwMC0weGZjZmZmZmZmIGlycSAxMSBh dCBkZXZpY2UgMC4wIG9uIHBjaTEKbnZpZGlhMDogUmVzZXJ2ZWQgMHgxMDAwMDAwIGJ5dGVzIGZv ciByaWQgMHgxMCB0eXBlIDMgYXQgMHhmYzAwMDAwMApudmlkaWEwOiBSZXNlcnZlZCAweDQwMDAw MDAgYnl0ZXMgZm9yIHJpZCAweDE0IHR5cGUgMyBhdCAweGYwMDAwMDAwCm52aWRpYTA6IFtHSUFO VC1MT0NLRURdCnVoY2kwOiA8SW50ZWwgODI4MDFEQiAoSUNINCkgVVNCIGNvbnRyb2xsZXIgVVNC LUE+IHBvcnQgMHhiZjgwLTB4YmY5ZiBpcnEgMTEgYXQgZGV2aWNlIDI5LjAgb24gcGNpMAp1aGNp MDogUmVzZXJ2ZWQgMHgyMCBieXRlcyBmb3IgcmlkIDB4MjAgdHlwZSA0IGF0IDB4YmY4MAp1aGNp MDogW0dJQU5ULUxPQ0tFRF0KdXNiMDogPEludGVsIDgyODAxREIgKElDSDQpIFVTQiBjb250cm9s bGVyIFVTQi1BPiBvbiB1aGNpMAp1c2IwOiBVU0IgcmV2aXNpb24gMS4wCnVodWIwOiBJbnRlbCBV SENJIHJvb3QgaHViLCBjbGFzcyA5LzAsIHJldiAxLjAwLzEuMDAsIGFkZHIgMQp1aHViMDogMiBw b3J0cyB3aXRoIDIgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQKdW1zMDogTG9naXRlY2ggT3B0aWNh bCBVU0IgTW91c2UsIHJldiAyLjAwLzMuNDAsIGFkZHIgMiwgaWNsYXNzIDMvMQp1bXMwOiAzIGJ1 dHRvbnMgYW5kIFogZGlyLgp1aGNpMTogPEludGVsIDgyODAxREIgKElDSDQpIFVTQiBjb250cm9s bGVyIFVTQi1CPiBwb3J0IDB4YmY0MC0weGJmNWYgaXJxIDExIGF0IGRldmljZSAyOS4xIG9uIHBj aTAKdWhjaTE6IFJlc2VydmVkIDB4MjAgYnl0ZXMgZm9yIHJpZCAweDIwIHR5cGUgNCBhdCAweGJm NDAKdWhjaTE6IFtHSUFOVC1MT0NLRURdCnVzYjE6IDxJbnRlbCA4MjgwMURCIChJQ0g0KSBVU0Ig Y29udHJvbGxlciBVU0ItQj4gb24gdWhjaTEKdXNiMTogVVNCIHJldmlzaW9uIDEuMAp1aHViMTog SW50ZWwgVUhDSSByb290IGh1YiwgY2xhc3MgOS8wLCByZXYgMS4wMC8xLjAwLCBhZGRyIDEKdWh1 YjE6IDIgcG9ydHMgd2l0aCAyIHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkCnVoY2kyOiA8SW50ZWwg ODI4MDFEQiAoSUNINCkgVVNCIGNvbnRyb2xsZXIgVVNCLUM+IHBvcnQgMHhiZjIwLTB4YmYzZiBp cnEgMTEgYXQgZGV2aWNlIDI5LjIgb24gcGNpMAp1aGNpMjogUmVzZXJ2ZWQgMHgyMCBieXRlcyBm b3IgcmlkIDB4MjAgdHlwZSA0IGF0IDB4YmYyMAp1aGNpMjogW0dJQU5ULUxPQ0tFRF0KdXNiMjog PEludGVsIDgyODAxREIgKElDSDQpIFVTQiBjb250cm9sbGVyIFVTQi1DPiBvbiB1aGNpMgp1c2Iy OiBVU0IgcmV2aXNpb24gMS4wCnVodWIyOiBJbnRlbCBVSENJIHJvb3QgaHViLCBjbGFzcyA5LzAs IHJldiAxLjAwLzEuMDAsIGFkZHIgMQp1aHViMjogMiBwb3J0cyB3aXRoIDIgcmVtb3ZhYmxlLCBz ZWxmIHBvd2VyZWQKcGNpMDogPHNlcmlhbCBidXMsIFVTQj4gYXQgZGV2aWNlIDI5LjcgKG5vIGRy aXZlciBhdHRhY2hlZCkKcGNpYjI6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgMzAu MCBvbiBwY2kwCnBjaWIyOiAgIHNlY29uZGFyeSBidXMgICAgIDIKcGNpYjI6ICAgc3Vib3JkaW5h dGUgYnVzICAgMgpwY2liMjogICBJL08gZGVjb2RlICAgICAgICAweGQwMDAtMHhlZmZmCnBjaWIy OiAgIG1lbW9yeSBkZWNvZGUgICAgIDB4ZjYwMDAwMDAtMHhmYmZmZmZmZgpwY2liMjogICBwcmVm ZXRjaGVkIGRlY29kZSAweGZmZjAwMDAwLTB4ZmZmZmYKcGNpYjI6ICAgU3VidHJhY3RpdmVseSBk ZWNvZGVkIGJyaWRnZS4KQUNQSSBQQ0kgbGluayBpbml0aWFsIGNvbmZpZ3VyYXRpb246ClxcX1NC Xy5QQ0kwLkxOS0QgaXJxKjExOiBbIDUgIDcgIDkgMTAgMTFdIDExKyBsb3csbGV2ZWwsc2hhcmFi bGUgMi4xLjAKXFxfU0JfLlBDSTAuTE5LRCBpcnEqMTE6IFsgNSAgNyAgOSAxMCAxMV0gMTErIGxv dyxsZXZlbCxzaGFyYWJsZSAyLjEuMQpcXF9TQl8uUENJMC5MTktCIGlycSogNTogWyA1ICA3XSAg MCsgbG93LGxldmVsLHNoYXJhYmxlIDIuMy4wClxcX1NCXy5QQ0kwLkxOS0QgaXJxKjExOiBbIDUg IDcgIDkgMTAgMTFdIDExKyBsb3csbGV2ZWwsc2hhcmFibGUgMi4zLjEKXFxfU0JfLlBDSTAuTE5L QyBpcnEqMTE6IFsgOSAxMCAxMV0gMTErIGxvdyxsZXZlbCxzaGFyYWJsZSAyLjAuMApcXF9TQl8u UENJMC5MTktCIGlycSogNTogWyA1ICA3XSAgMCsgbG93LGxldmVsLHNoYXJhYmxlIDIuOC4wClxc X1NCXy5QQ0kwLkxOS0IgaXJxKiA1OiBbIDUgIDddICAwKyBsb3csbGV2ZWwsc2hhcmFibGUgMi44 LjEKcGNpMjogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjIKcGNpMjogcGh5c2ljYWwgYnVzPTIKCW1h cFsxMF06IHR5cGUgMSwgcmFuZ2UgMzIsIGJhc2UgZmFmZmUwMDAsIHNpemUgMTMsIGVuYWJsZWQK cGNpYjI6IGRldmljZSAobnVsbCkgcmVxdWVzdGVkIGRlY29kZWQgbWVtb3J5IHJhbmdlIDB4ZmFm ZmUwMDAtMHhmYWZmZmZmZgpwY2liMjogbWF0Y2hlZCBlbnRyeSBmb3IgMi4wLklOVEEgKHNyYyBc XF9TQl8uUENJMC5MTktDKQpwY2liMjogc2xvdCAwIElOVEEgaXMgYWxyZWFkeSByb3V0ZWQgdG8g aXJxIDExCmZvdW5kLT4JdmVuZG9yPTB4MTRlNCwgZGV2PTB4NDQwMSwgcmV2aWQ9MHgwMQoJYnVz PTIsIHNsb3Q9MCwgZnVuYz0wCgljbGFzcz0wMi0wMC0wMCwgaGRydHlwZT0weDAwLCBtZmRldj0w CgljbWRyZWc9MHgwMTA2LCBzdGF0cmVnPTB4MDAxMCwgY2FjaGVsbnN6PTAgKGR3b3JkcykKCWxh dHRpbWVyPTB4MjAgKDk2MCBucyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAg bnMpCglpbnRwaW49YSwgaXJxPTExCglwb3dlcnNwZWMgMiAgc3VwcG9ydHMgRDAgRDEgRDIgRDMg IGN1cnJlbnQgRDAKCW1hcFsxMF06IHR5cGUgMSwgcmFuZ2UgMzIsIGJhc2UgMDAwMDAwMDAsIHNp emUgMTIsIG1lbW9yeSBkaXNhYmxlZApmb3VuZC0+CXZlbmRvcj0weDEwNGMsIGRldj0weGFjNDQs IHJldmlkPTB4MDIKCWJ1cz0yLCBzbG90PTEsIGZ1bmM9MAoJY2xhc3M9MDYtMDctMDAsIGhkcnR5 cGU9MHgwMiwgbWZkZXY9MQoJY21kcmVnPTB4MDAwMCwgc3RhdHJlZz0weDAyMTAsIGNhY2hlbG5z ej04IChkd29yZHMpCglsYXR0aW1lcj0weDIwICg5NjAgbnMpLCBtaW5nbnQ9MHg0MCAoMTYwMDAg bnMpLCBtYXhsYXQ9MHgwNyAoMTc1MCBucykKCWludHBpbj1hLCBpcnE9MjU1Cglwb3dlcnNwZWMg MiAgc3VwcG9ydHMgRDAgRDEgRDIgRDMgIGN1cnJlbnQgRDAKCW1hcFsxMF06IHR5cGUgMSwgcmFu Z2UgMzIsIGJhc2UgZmFmZmQ4MDAsIHNpemUgMTEsIGVuYWJsZWQKcGNpYjI6IGRldmljZSAobnVs bCkgcmVxdWVzdGVkIGRlY29kZWQgbWVtb3J5IHJhbmdlIDB4ZmFmZmQ4MDAtMHhmYWZmZGZmZgoJ bWFwWzE0XTogdHlwZSAxLCByYW5nZSAzMiwgYmFzZSBmYWZmODAwMCwgc2l6ZSAxNCwgZW5hYmxl ZApwY2liMjogZGV2aWNlIChudWxsKSByZXF1ZXN0ZWQgZGVjb2RlZCBtZW1vcnkgcmFuZ2UgMHhm YWZmODAwMC0weGZhZmZiZmZmCnBjaWIyOiBtYXRjaGVkIGVudHJ5IGZvciAyLjEuSU5UQSAoc3Jj IFxcX1NCXy5QQ0kwLkxOS0QpCnBjaWIyOiBzbG90IDEgSU5UQSBpcyBhbHJlYWR5IHJvdXRlZCB0 byBpcnEgMTEKZm91bmQtPgl2ZW5kb3I9MHgxMDRjLCBkZXY9MHg4MDI5LCByZXZpZD0weDAwCgli dXM9Miwgc2xvdD0xLCBmdW5jPTEKCWNsYXNzPTBjLTAwLTEwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2 PTEKCWNtZHJlZz0weDAxMTYsIHN0YXRyZWc9MHgwMjEwLCBjYWNoZWxuc3o9OCAoZHdvcmRzKQoJ bGF0dGltZXI9MHgyMCAoOTYwIG5zKSwgbWluZ250PTB4MDIgKDUwMCBucyksIG1heGxhdD0weDA0 ICgxMDAwIG5zKQoJaW50cGluPWEsIGlycT0xMQoJcG93ZXJzcGVjIDIgIHN1cHBvcnRzIEQwIEQx IEQyIEQzICBjdXJyZW50IEQwCgltYXBbMTBdOiB0eXBlIDEsIHJhbmdlIDMyLCBiYXNlIGZhZmY2 MDAwLCBzaXplIDEzLCBlbmFibGVkCnBjaWIyOiBkZXZpY2UgKG51bGwpIHJlcXVlc3RlZCBkZWNv ZGVkIG1lbW9yeSByYW5nZSAweGZhZmY2MDAwLTB4ZmFmZjdmZmYKcGNpYjI6IG1hdGNoZWQgZW50 cnkgZm9yIDIuMy5JTlRBIChzcmMgXFxfU0JfLlBDSTAuTE5LQikKcGNpYjI6IHNsb3QgMyBJTlRB IGlzIGFscmVhZHkgcm91dGVkIHRvIGlycSA1CmZvdW5kLT4JdmVuZG9yPTB4MTRlNCwgZGV2PTB4 NDMyNCwgcmV2aWQ9MHgwMgoJYnVzPTIsIHNsb3Q9MywgZnVuYz0wCgljbGFzcz0wMi04MC0wMCwg aGRydHlwZT0weDAwLCBtZmRldj0wCgljbWRyZWc9MHgwMTA2LCBzdGF0cmVnPTB4MDAxMCwgY2Fj aGVsbnN6PTAgKGR3b3JkcykKCWxhdHRpbWVyPTB4MjAgKDk2MCBucyksIG1pbmdudD0weDAwICgw IG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCglpbnRwaW49YSwgaXJxPTUKCXBvd2Vyc3BlYyAyICBz dXBwb3J0cyBEMCBEMSBEMiBEMyAgY3VycmVudCBEMApiZmUwOiA8QnJvYWRjb20gQkNNNDQwMSBG YXN0IEV0aGVybmV0PiBtZW0gMHhmYWZmZTAwMC0weGZhZmZmZmZmIGlycSAxMSBhdCBkZXZpY2Ug MC4wIG9uIHBjaTIKYmZlMDogUmVzZXJ2ZWQgMHgyMDAwIGJ5dGVzIGZvciByaWQgMHgxMCB0eXBl IDMgYXQgMHhmYWZmZTAwMAptaWlidXMwOiA8TUlJIGJ1cz4gb24gYmZlMApibXRwaHkwOiA8QkNN NDQwMSAxMC8xMDBiYXNlVFggUEhZPiBvbiBtaWlidXMwCmJtdHBoeTA6ICAxMGJhc2VULCAxMGJh c2VULUZEWCwgMTAwYmFzZVRYLCAxMDBiYXNlVFgtRkRYLCBhdXRvCmJmZTA6IGJwZiBhdHRhY2hl ZApiZmUwOiBFdGhlcm5ldCBhZGRyZXNzOiAwMDowYjpkYjo5OTplODpjNwpiZmUwOiBbR0lBTlQt TE9DS0VEXQpjYmIwOiA8VEk0NTEwIFBDSS1DYXJkQnVzIEJyaWRnZT4gYXQgZGV2aWNlIDEuMCBv biBwY2kyCnBjaWIyOiBkZXZpY2UgY2JiMCByZXF1ZXN0ZWQgZGVjb2RlZCBtZW1vcnkgcmFuZ2Ug MHhmNjAwMDAwMC0weGZiZmZmZmZmCmNiYjA6IExhenkgYWxsb2NhdGlvbiBvZiAweDEwMDAgYnl0 ZXMgcmlkIDB4MTAgdHlwZSAzIGF0IDB4ZjYwMDAwMDAKY2FyZGJ1czA6IDxDYXJkQnVzIGJ1cz4g b24gY2JiMApwY2NhcmQwOiA8MTYtYml0IFBDQ2FyZCBidXM+IG9uIGNiYjAKcGNpYjI6IG1hdGNo ZWQgZW50cnkgZm9yIDIuMS5JTlRBIChzcmMgXFxfU0JfLlBDSTAuTE5LRCkKcGNpYjI6IHNsb3Qg MSBJTlRBIGlzIGFscmVhZHkgcm91dGVkIHRvIGlycSAxMQpjYmIwOiBbTVBTQUZFXQpjYmIwOiBQ Q0kgQ29uZmlndXJhdGlvbiBzcGFjZToKICAweDAwOiAweGFjNDQxMDRjIDB4MDIxMDAwMDcgMHgw NjA3MDAwMiAweDAwODIyMDA4IAogIDB4MTA6IDB4ZjYwMDAwMDAgMHgwMjAwMDBhMCAweDIwMDQw MzAyIDB4ZmZmZmYwMDAgCiAgMHgyMDogMHgwMDAwMDAwMCAweGZmZmZmMDAwIDB4MDAwMDAwMDAg MHhmZmZmZmZmYyAKICAweDMwOiAweDAwMDAwMDAwIDB4ZmZmZmZmZmMgMHgwMDAwMDAwMCAweDA3 NDAwMTBiIAogIDB4NDA6IDB4MDEzZTEwMjggMHgwMDAwMDAwMSAweDAwMDAwMDAwIDB4MDAwMDAw MDAgCiAgMHg1MDogMHgwMDAwMDAwMCAweDAwMDAwMDAwIDB4MDAwMDAwMDAgMHgwMDAwMDAwMCAK ICAweDYwOiAweDAwMDAwMDAwIDB4MDAwMDAwMDAgMHgwMDAwMDAwMCAweDAwMDAwMDAwIAogIDB4 NzA6IDB4MDAwMDAwMDAgMHgwMDAwMDAwMCAweDAwMDAwMDAwIDB4MDAwMDAwMDAgCiAgMHg4MDog MHgyODQwNTA2MSAweDAwMDAwMDAwIDB4MDAxZjAwMDAgMHgwMTJjMTIwMiAKICAweDkwOiAweDYw NjQ4MmMwIDB4MDAwMDAwMDAgMHgwMDAwMDAwMCAweDAwMDAwMDAwIAogIDB4YTA6IDB4ZmUxMjAw MDEgMHgwMGMwMDAwMCAweDAwMDAwMDAwIDB4MDAwMDAwMDAgCiAgMHhiMDogMHgwMDAwMDAwMCAw eDAwMDAwMDAwIDB4MDAwMDAwMDAgMHgwMDAwMDAwMCAKICAweGMwOiAweDAwMDAwMDAwIDB4MDAw MDAwMDAgMHgwMDAwMDAwMCAweDAwMDAwMDAwIAogIDB4ZDA6IDB4MDAwMDAwMDAgMHgwMDAwMDAw MCAweDAwMDAwMDAwIDB4MDAwMDAwMDAgCiAgMHhlMDogMHgwMDAwMDAwMCAweDAwMDAwMDAwIDB4 MDAwMDAwMDAgMHgwMDAwMDAwMCAKICAweGYwOiAweDAwMDAwMDAwIDB4MDAwMDAwMDAgMHgwMDAw MDAwMCAweDAwMDAwMDAwIApmd29oY2kwOiB2ZW5kb3I9MTA0YywgZGV2PTgwMjkKZndvaGNpMDog PDEzOTQgT3BlbiBIb3N0IENvbnRyb2xsZXIgSW50ZXJmYWNlPiBtZW0gMHhmYWZmODAwMC0weGZh ZmZiZmZmLDB4ZmFmZmQ4MDAtMHhmYWZmZGZmZiBpcnEgMTEgYXQgZGV2aWNlIDEuMSBvbiBwY2ky CmZ3b2hjaTA6IFJlc2VydmVkIDB4ODAwIGJ5dGVzIGZvciByaWQgMHgxMCB0eXBlIDMgYXQgMHhm YWZmZDgwMApmd29oY2kwOiBbTVBTQUZFXQpmd29oY2kwOiBPSENJIHZlcnNpb24gMS4xMCAoUk9N PTApCmZ3b2hjaTA6IE5vLiBvZiBJc29jaHJvbm91cyBjaGFubmVscyBpcyA0Lgpmd29oY2kwOiBF VUk2NCA0Njo0ZjpjMDowMDoxZDoyZjoxYzo2MQpmd29oY2kwOiBQaHkgMTM5NGEgYXZhaWxhYmxl IFM0MDAsIDIgcG9ydHMuCmZ3b2hjaTA6IExpbmsgUzQwMCwgbWF4X3JlYyAyMDQ4IGJ5dGVzLgpm aXJld2lyZTA6IDxJRUVFMTM5NChGaXJlV2lyZSkgYnVzPiBvbiBmd29oY2kwCmZ3ZTA6IDxFdGhl cm5ldCBvdmVyIEZpcmVXaXJlPiBvbiBmaXJld2lyZTAKaWZfZndlMDogRmFrZSBFdGhlcm5ldCBh ZGRyZXNzOiA0Njo0ZjpjMDoyZjoxYzo2MQpmd2UwOiBicGYgYXR0YWNoZWQKZndlMDogRXRoZXJu ZXQgYWRkcmVzczogNDY6NGY6YzA6MmY6MWM6NjEKZndlMDogaWZfc3RhcnQgcnVubmluZyBkZWZl cnJlZCBmb3IgR2lhbnQKc2JwMDogPFNCUC0yL1NDU0kgb3ZlciBGaXJlV2lyZT4gb24gZmlyZXdp cmUwCmZ3b2hjaTA6IEluaXRpYXRlIGJ1cyByZXNldApmd29oY2kwOiBub2RlX2lkPTB4YzgwMGZm YzAsIGdlbj0xLCBDWUNMRU1BU1RFUiBtb2RlCmZpcmV3aXJlMDogMSBub2RlcywgbWF4aG9wIDw9 IDAsIGNhYmxlIElSTSA9IDAgKG1lKQpmaXJld2lyZTA6IGJ1cyBtYW5hZ2VyIDAgKG1lKQpwY2ky OiA8bmV0d29yaz4gYXQgZGV2aWNlIDMuMCAobm8gZHJpdmVyIGF0dGFjaGVkKQppc2FiMDogPFBD SS1JU0EgYnJpZGdlPiBhdCBkZXZpY2UgMzEuMCBvbiBwY2kwCmlzYTA6IDxJU0EgYnVzPiBvbiBp c2FiMAphdGFwY2kwOiA8SW50ZWwgSUNINCBVRE1BMTAwIGNvbnRyb2xsZXI+IHBvcnQgMHhiZmEw LTB4YmZhZiwweDM3NiwweDE3MC0weDE3NywweDNmNiwweDFmMC0weDFmNyBhdCBkZXZpY2UgMzEu MSBvbiBwY2kwCmF0YXBjaTA6IFJlc2VydmVkIDB4MTAgYnl0ZXMgZm9yIHJpZCAweDIwIHR5cGUg NCBhdCAweGJmYTAKYXRhMDogY2hhbm5lbCAjMCBvbiBhdGFwY2kwCmF0YXBjaTA6IFJlc2VydmVk IDB4OCBieXRlcyBmb3IgcmlkIDB4MTAgdHlwZSA0IGF0IDB4MWYwCmF0YXBjaTA6IFJlc2VydmVk IDB4MSBieXRlcyBmb3IgcmlkIDB4MTQgdHlwZSA0IGF0IDB4M2Y2CmF0YTA6IHJlc2V0IHRwMSBt YXNrPTAzIG9zdGF0MD01MCBvc3RhdDE9MDAKYXRhMC1tYXN0ZXI6IHN0YXQ9MHg1MCBlcnI9MHgw MSBsc2I9MHgwMCBtc2I9MHgwMAphdGEwLXNsYXZlOiAgc3RhdD0weDAwIGVycj0weDAxIGxzYj0w eDAwIG1zYj0weDAwCmF0YTA6IHJlc2V0IHRwMiBzdGF0MD01MCBzdGF0MT0wMCBkZXZpY2VzPTB4 MTxBVEFfTUFTVEVSPgphdGEwOiBbTVBTQUZFXQphdGExOiBjaGFubmVsICMxIG9uIGF0YXBjaTAK YXRhcGNpMDogUmVzZXJ2ZWQgMHg4IGJ5dGVzIGZvciByaWQgMHgxOCB0eXBlIDQgYXQgMHgxNzAK YXRhcGNpMDogUmVzZXJ2ZWQgMHgxIGJ5dGVzIGZvciByaWQgMHgxYyB0eXBlIDQgYXQgMHgzNzYK YXRhMTogcmVzZXQgdHAxIG1hc2s9MDMgb3N0YXQwPTUwIG9zdGF0MT0wMAphdGExLW1hc3Rlcjog c3RhdD0weDAwIGVycj0weDAxIGxzYj0weDE0IG1zYj0weGViCmF0YTEtc2xhdmU6ICBzdGF0PTB4 MDAgZXJyPTB4MDEgbHNiPTB4MTQgbXNiPTB4ZWIKYXRhMTogcmVzZXQgdHAyIHN0YXQwPTAwIHN0 YXQxPTAwIGRldmljZXM9MHhjPEFUQVBJX1NMQVZFLEFUQVBJX01BU1RFUj4KYXRhMTogW01QU0FG RV0KcGNpMDogPG11bHRpbWVkaWEsIGF1ZGlvPiBhdCBkZXZpY2UgMzEuNSAobm8gZHJpdmVyIGF0 dGFjaGVkKQpwY2kwOiA8c2ltcGxlIGNvbW1zPiBhdCBkZXZpY2UgMzEuNiAobm8gZHJpdmVyIGF0 dGFjaGVkKQpwc21jcG5wMDogPFBTLzIgbW91c2UgcG9ydD4gaXJxIDEyIG9uIGFjcGkwCmF0a2Jk YzA6IDxLZXlib2FyZCBjb250cm9sbGVyIChpODA0Mik+IHBvcnQgMHg2NCwweDYwIGlycSAxIG9u IGFjcGkwCmF0a2JkMDogPEFUIEtleWJvYXJkPiBpcnEgMSBvbiBhdGtiZGMwCmF0a2JkOiB0aGUg Y3VycmVudCBrYmQgY29udHJvbGxlciBjb21tYW5kIGJ5dGUgMDA2NQphdGtiZDoga2V5Ym9hcmQg SUQgMHg0MWFiICgyKQprYmQwIGF0IGF0a2JkMAprYmQwOiBhdGtiZDAsIEFUIDEwMS8xMDIgKDIp LCBjb25maWc6MHgwLCBmbGFnczoweDNkMDAwMAphdGtiZDA6IFtHSUFOVC1MT0NLRURdCnBzbTA6 IGN1cnJlbnQgY29tbWFuZCBieXRlOjAwNjUKcHNtMDogPFBTLzIgTW91c2U+IGlycSAxMiBvbiBh dGtiZGMwCnBzbTA6IFtHSUFOVC1MT0NLRURdCnBzbTA6IG1vZGVsIEdsaWRlUG9pbnQsIGRldmlj ZSBJRCAwLTAwLCAyIGJ1dHRvbnMKcHNtMDogY29uZmlnOjAwMDAwMDAwLCBmbGFnczowMDAwMDAw OCwgcGFja2V0IHNpemU6Mwpwc20wOiBzeW5jbWFzazpjMCwgc3luY2JpdHM6MDAKc2lvMDogaXJx IG1hcHM6IDB4YTAxIDB4YTA5IDB4YTAxIDB4YTAxCnNpbzA6IDwxNjU1MEEtY29tcGF0aWJsZSBD T00gcG9ydD4gcG9ydCAweDJmOC0weDJmZiBpcnEgMyBmbGFncyAweDEwIG9uIGFjcGkwCnNpbzA6 IHR5cGUgMTY1NTBBCnBwYzA6IHVzaW5nIGV4dGVuZGVkIEkvTyBwb3J0IHJhbmdlCnBwYzA6IEVD UCBTUFAgRUNQK0VQUCBTUFAKcHBjMDogPEVDUCBwYXJhbGxlbCBwcmludGVyIHBvcnQ+IHBvcnQg MHg3NzgtMHg3N2IsMHgzNzgtMHgzN2YgaXJxIDcgZHJxIDEgb24gYWNwaTAKcHBjMDogU01DLWxp a2UgY2hpcHNldCAoRUNQL0VQUC9QUzIvTklCQkxFKSBpbiBDT01QQVRJQkxFIG1vZGUKcHBjMDog RklGTyB3aXRoIDE2LzE2LzggYnl0ZXMgdGhyZXNob2xkCnBwYnVzMDogPFBhcmFsbGVsIHBvcnQg YnVzPiBvbiBwcGMwCnBsaXAwOiA8UExJUCBuZXR3b3JrIGludGVyZmFjZT4gb24gcHBidXMwCnBs aXAwOiBicGYgYXR0YWNoZWQKbHB0MDogPFByaW50ZXI+IG9uIHBwYnVzMApscHQwOiBJbnRlcnJ1 cHQtZHJpdmVuIHBvcnQKcHBpMDogPFBhcmFsbGVsIEkvTz4gb24gcHBidXMwCnVua25vd246IG5v dCBwcm9iZWQgKGRpc2FibGVkKQp1bmtub3duOiBub3QgcHJvYmVkIChkaXNhYmxlZCkKdW5rbm93 bjogbm90IHByb2JlZCAoZGlzYWJsZWQpCnVua25vd246IG5vdCBwcm9iZWQgKGRpc2FibGVkKQph dGE6IGF0YTAgYWxyZWFkeSBleGlzdHM7IHNraXBwaW5nIGl0CmF0YTogYXRhMSBhbHJlYWR5IGV4 aXN0czsgc2tpcHBpbmcgaXQKYXRrYmRjOiBhdGtiZGMwIGFscmVhZHkgZXhpc3RzOyBza2lwcGlu ZyBpdApwcGM6IHBwYzAgYWxyZWFkeSBleGlzdHM7IHNraXBwaW5nIGl0CnNpbzogc2lvMCBhbHJl YWR5IGV4aXN0czsgc2tpcHBpbmcgaXQKVHJ5aW5nIFJlYWRfUG9ydCBhdCAyMDMKVHJ5aW5nIFJl YWRfUG9ydCBhdCAyNDMKVHJ5aW5nIFJlYWRfUG9ydCBhdCAyODMKVHJ5aW5nIFJlYWRfUG9ydCBh dCAyYzMKVHJ5aW5nIFJlYWRfUG9ydCBhdCAzMDMKVHJ5aW5nIFJlYWRfUG9ydCBhdCAzNDMKVHJ5 aW5nIFJlYWRfUG9ydCBhdCAzODMKVHJ5aW5nIFJlYWRfUG9ydCBhdCAzYzMKZXhfaXNhX2lkZW50 aWZ5KCkKdW5rbm93bjogc3RhdHVzIHJlZyB0ZXN0IGZhaWxlZCBmZgp1bmtub3duOiBzdGF0dXMg cmVnIHRlc3QgZmFpbGVkIGZmCnVua25vd246IHN0YXR1cyByZWcgdGVzdCBmYWlsZWQgZmYKdW5r bm93bjogc3RhdHVzIHJlZyB0ZXN0IGZhaWxlZCBmZgp1bmtub3duOiBzdGF0dXMgcmVnIHRlc3Qg ZmFpbGVkIGZmCnVua25vd246IHN0YXR1cyByZWcgdGVzdCBmYWlsZWQgZmYKYWhjX2lzYV9wcm9i ZSAxMTogaW9wb3J0IDB4YmMwMCBhbGxvYyBmYWlsZWQKc2M6IHNjMCBhbHJlYWR5IGV4aXN0czsg c2tpcHBpbmcgaXQKdmdhOiB2Z2EwIGFscmVhZHkgZXhpc3RzOyBza2lwcGluZyBpdAppc2FfcHJv YmVfY2hpbGRyZW46IGRpc2FibGluZyBQblAgZGV2aWNlcwppc2FfcHJvYmVfY2hpbGRyZW46IHBy b2Jpbmcgbm9uLVBuUCBkZXZpY2VzCm9ybTA6IDxJU0EgT3B0aW9uIFJPTXM+IGF0IGlvbWVtIDB4 Y2Y4MDAtMHhjZmZmZiwweGMwMDAwLTB4Y2Y3ZmYgb24gaXNhMApwbXRpbWVyMCBvbiBpc2EwCmFk djA6IG5vdCBwcm9iZWQgKGRpc2FibGVkKQphaGEwOiBub3QgcHJvYmVkIChkaXNhYmxlZCkKYWlj MDogbm90IHByb2JlZCAoZGlzYWJsZWQpCmJ0MDogbm90IHByb2JlZCAoZGlzYWJsZWQpCmNzMDog bm90IHByb2JlZCAoZGlzYWJsZWQpCmVkMDogbm90IHByb2JlZCAoZGlzYWJsZWQpCmZkYzAgZmFp bGVkIHRvIHByb2JlIGF0IHBvcnQgMHgzZjAtMHgzZjUgaXJxIDYgZHJxIDIgb24gaXNhMApmZTA6 IG5vdCBwcm9iZWQgKGRpc2FibGVkKQppZTA6IG5vdCBwcm9iZWQgKGRpc2FibGVkKQpsbmMwOiBu b3QgcHJvYmVkIChkaXNhYmxlZCkKcGNpYzAgZmFpbGVkIHRvIHByb2JlIGF0IHBvcnQgMHgzZTAg aW9tZW0gMHhkMDAwMCBvbiBpc2EwCnBjaWMxOiBub3QgcHJvYmVkIChkaXNhYmxlZCkKc2MwOiA8 U3lzdGVtIGNvbnNvbGU+IGF0IGZsYWdzIDB4MTAwIG9uIGlzYTAKc2MwOiBWR0EgPDE2IHZpcnR1 YWwgY29uc29sZXMsIGZsYWdzPTB4MzAwPgpzYzA6IGZiMCwga2JkMCwgdGVybWluYWwgZW11bGF0 b3I6IHNjIChzeXNjb25zIHRlcm1pbmFsKQpzaW8xIGZhaWxlZCB0byBwcm9iZSBhdCBwb3J0IDB4 MmY4IGlycSAzIG9uIGlzYTAKc2lvMjogbm90IHByb2JlZCAoZGlzYWJsZWQpCnNpbzM6IG5vdCBw cm9iZWQgKGRpc2FibGVkKQpzbjA6IG5vdCBwcm9iZWQgKGRpc2FibGVkKQp2Z2EwOiA8R2VuZXJp YyBJU0EgVkdBPiBhdCBwb3J0IDB4M2MwLTB4M2RmIGlvbWVtIDB4YTAwMDAtMHhiZmZmZiBvbiBp c2EwCmZiMDogdmdhMCwgdmdhLCB0eXBlOlZHQSAoNSksIGZsYWdzOjB4NzAwN2YKZmIwOiBwb3J0 OjB4M2MwLTB4M2RmLCBjcnRjOjB4M2Q0LCBtZW06MHhhMDAwMCAweDIwMDAwCmZiMDogaW5pdCBt b2RlOjI0LCBiaW9zIG1vZGU6MywgY3VycmVudCBtb2RlOjI0CmZiMDogd2luZG93OjB4YzAwYjgw MDAgc2l6ZTozMmsgZ3JhbjozMmssIGJ1ZjowIHNpemU6MzJrClZHQSBwYXJhbWV0ZXJzIHVwb24g cG93ZXItdXAKNTAgMTggMTAgMDAgMDAgMDAgMDMgMDAgMDIgNjcgNWYgNGYgNTAgODIgNTQgODAg CmJmIDFmIDAwIDRmIDBkIDBlIDAwIDAwIDA3IDgwIDljIDhlIDhmIDI4IDFmIDk2IApiOSBhMyBm ZiAwMCAwMSAwMiAwMyAwNCAwNSAxNCAwNyAzOCAzOSAzYSAzYiAzYyAKM2QgM2UgM2YgMGMgMDAg MGYgMDggMDAgMDAgMDAgMDAgMDAgMTAgMGUgMDAgZmYgClZHQSBwYXJhbWV0ZXJzIGluIEJJT1Mg Zm9yIG1vZGUgMjQKNTAgMTggMTAgMDAgMTAgMDAgMDMgMDAgMDIgNjcgNWYgNGYgNTAgODIgNTQg ODAgCmJmIDFmIDAwIDRmIDBkIDBlIDAwIDAwIDAwIDAwIDljIDhlIDhmIDI4IDFmIDk2IApiOSBh MyBmZiAwMCAwMSAwMiAwMyAwNCAwNSAxNCAwNyAzOCAzOSAzYSAzYiAzYyAKM2QgM2UgM2YgMGMg MDAgMGYgMDggMDAgMDAgMDAgMDAgMDAgMTAgMGUgMDAgZmYgCkVHQS9WR0EgcGFyYW1ldGVycyB0 byBiZSB1c2VkIGZvciBtb2RlIDI0CjUwIDE4IDEwIDAwIDEwIDAwIDAzIDAwIDAyIDY3IDVmIDRm IDUwIDgyIDU0IDgwIApiZiAxZiAwMCA0ZiAwZCAwZSAwMCAwMCAwMCAwMCA5YyA4ZSA4ZiAyOCAx ZiA5NiAKYjkgYTMgZmYgMDAgMDEgMDIgMDMgMDQgMDUgMTQgMDcgMzggMzkgM2EgM2IgM2MgCjNk IDNlIDNmIDBjIDAwIDBmIDA4IDAwIDAwIDAwIDAwIDAwIDEwIDBlIDAwIGZmIAp2dDA6IG5vdCBw cm9iZWQgKGRpc2FibGVkKQppc2FfcHJvYmVfY2hpbGRyZW46IHByb2JpbmcgUG5QIGRldmljZXMK RGV2aWNlIGNvbmZpZ3VyYXRpb24gZmluaXNoZWQuCnByb2NmcyByZWdpc3RlcmVkClRpbWVjb3Vu dGVyICJUU0MiIGZyZXF1ZW5jeSAyNDkyNjUyNjUyIEh6IHF1YWxpdHkgODAwClRpbWVjb3VudGVy cyB0aWNrIGV2ZXJ5IDEwLjAwMCBtc2VjCkxpbnV4IEVMRiBleGVjIGhhbmRsZXIgaW5zdGFsbGVk CmxvMDogYnBmIGF0dGFjaGVkCmNwdTA6IHNldCBzcGVlZCB0byAxMDAuMCUKYWNwaV9jcHU6IHRo cm90dGxpbmcgZW5hYmxlZCwgOCBzdGVwcyAoMTAwJSB0byAxMi41JSksIGN1cnJlbnRseSAxMDAu MCUKYWNwaV9hY2FkMDogYWNsaW5lIGluaXRpYWxpemF0aW9uIHN0YXJ0CmFjcGlfYWNhZDA6IE9u IExpbmUKYWNwaV9hY2FkMDogYWNsaW5lIGluaXRpYWxpemF0aW9uIGRvbmUsIHRyaWVkIDEgdGlt ZXMKYWNwaV9jbWJhdDA6IGJhdHRlcnkgaW5pdGlhbGl6YXRpb24gc3RhcnQKYWNwaV9jbWJhdDA6 IGJhdHRlcnkgaW5pdGlhbGl6YXRpb24gZG9uZSwgdHJpZWQgMSB0aW1lcwphY3BpX2NtYmF0MTog YmF0dGVyeSBpbml0aWFsaXphdGlvbiBzdGFydApjcHUwOiBQZXJmb3JtYW5jZSBzdGF0ZXMgY2hh bmdlZAphdGEwLW1hc3RlcjogcGlvPTB4MGMgd2RtYT0weDIyIHVkbWE9MHg0NSBjYWJsZT04MHBp bgphdGEwLW1hc3Rlcjogc2V0dGluZyBQSU80IG9uIEludGVsIElDSDQgY2hpcAphdGEwLW1hc3Rl cjogc2V0dGluZyBVRE1BMTAwIG9uIEludGVsIElDSDQgY2hpcAphZDA6IDxJQzI1TjA4MEFUTVIw NC0wL01PNE9BRDBBPiBBVEEtNiBkaXNrIGF0IGF0YTAtbWFzdGVyCmFkMDogNzYzMTlNQiAoMTU2 MzAxNDg4IHNlY3RvcnMpLCAxNTUwNjEgQywgMTYgSCwgNjMgUywgNTEyIEIKYWQwOiAxNiBzZWNz L2ludCwgMSBkZXB0aCBxdWV1ZSwgVURNQTEwMApHRU9NOiBuZXcgZGlzayBhZDAKYXI6IEZyZWVC U0QgY2hlY2sxIGZhaWxlZApbMF0gZjowMCB0eXA6NyBzKENIUyk6MC8xLzEgZShDSFMpOjEwMjMv MjU0LzYzIHM6NjMgbDoxMDIzOTgyNDcKWzFdIGY6ODAgdHlwOjE2NSBzKENIUyk6MTAyMy8yNTUv NjMgZShDSFMpOjEwMjMvMjU0LzYzIHM6MTAyMzk4MzEwIGw6MTg0MjY1NTUKWzJdIGY6ODAgdHlw OjE2NSBzKENIUyk6MTAyMy8yNTUvNjMgZShDSFMpOjEwMjMvMjU0LzYzIHM6MTIwODI0ODY1IGw6 MTIyNzM2NjAKWzNdIGY6MDAgdHlwOjUgcyhDSFMpOjEwMjMvMjU1LzYzIGUoQ0hTKToxMDIzLzI1 NC82MyBzOjEzMzA5ODUyNSBsOjIzMTk3ODYwCkdFT006IENvbmZpZ3VyZSBhZDBzMSwgc3RhcnQg MzIyNTYgbGVuZ3RoIDUyNDI3OTAyNDY0IGVuZCA1MjQyNzkzNDcxOQpHRU9NOiBDb25maWd1cmUg YWQwczIsIHN0YXJ0IDUyNDI3OTM0NzIwIGxlbmd0aCA5NDM0Mzk2MTYwIGVuZCA2MTg2MjMzMDg3 OQpHRU9NOiBDb25maWd1cmUgYWQwczMsIHN0YXJ0IDYxODYyMzMwODgwIGxlbmd0aCA2Mjg0MTEz OTIwIGVuZCA2ODE0NjQ0NDc5OQpHRU9NOiBDb25maWd1cmUgYWQwczQsIHN0YXJ0IDY4MTQ2NDQ0 ODAwIGxlbmd0aCAxMTg3NzMwNDMyMCBlbmQgODAwMjM3NDkxMTkKR0VPTTogQ29uZmlndXJlIGFk MHMyYSwgc3RhcnQgMCBsZW5ndGggMjY4NDM1NDU2IGVuZCAyNjg0MzU0NTUKR0VPTTogQ29uZmln dXJlIGFkMHMyYiwgc3RhcnQgMjY4NDM1NDU2IGxlbmd0aCAyMTIwNDk5MjAwIGVuZCAyMzg4OTM0 NjU1CkdFT006IENvbmZpZ3VyZSBhZDBzMmMsIHN0YXJ0IDAgbGVuZ3RoIDk0MzQzOTYxNjAgZW5k IDk0MzQzOTYxNTkKR0VPTTogQ29uZmlndXJlIGFkMHMyZCwgc3RhcnQgMjM4ODkzNDY1NiBsZW5n dGggMjY4NDM1NDU2IGVuZCAyNjU3MzcwMTExCkdFT006IENvbmZpZ3VyZSBhZDBzMmUsIHN0YXJ0 IDI2NTczNzAxMTIgbGVuZ3RoIDI2ODQzNTQ1NiBlbmQgMjkyNTgwNTU2NwpHRU9NOiBDb25maWd1 cmUgYWQwczJmLCBzdGFydCAyOTI1ODA1NTY4IGxlbmd0aCA2NTA4NTkwNTkyIGVuZCA5NDM0Mzk2 MTU5CkdFT006IENvbmZpZ3VyZSBhZDBzM2EsIHN0YXJ0IDAgbGVuZ3RoIDI2ODQzNTQ1NiBlbmQg MjY4NDM1NDU1CkdFT006IENvbmZpZ3VyZSBhZDBzM2MsIHN0YXJ0IDAgbGVuZ3RoIDYyODQxMTM5 MjAgZW5kIDYyODQxMTM5MTkKR0VPTTogQ29uZmlndXJlIGFkMHMzZCwgc3RhcnQgMjY4NDM1NDU2 IGxlbmd0aCAyNjg0MzU0NTYgZW5kIDUzNjg3MDkxMQpHRU9NOiBDb25maWd1cmUgYWQwczNlLCBz dGFydCA1MzY4NzA5MTIgbGVuZ3RoIDI2ODQzNTQ1NiBlbmQgODA1MzA2MzY3CkdFT006IENvbmZp Z3VyZSBhZDBzM2YsIHN0YXJ0IDgwNTMwNjM2OCBsZW5ndGggNTQ3ODgwNzU1MiBlbmQgNjI4NDEx MzkxOQpNQlJFWFQgU2xpY2UgNSBvbiBhZDBzNDoKWzBdIGY6MDAgdHlwOjEzMSBzKENIUyk6MTAy My8yNTQvNjMgZShDSFMpOjEwMjMvMjU0LzYzIHM6NjMgbDo4MDI2MgpbMV0gZjowMCB0eXA6NSBz KENIUyk6MTAyMy8yNTQvNjMgZShDSFMpOjEwMjMvMjU0LzYzIHM6ODAzMjUgbDoxMDEyMDk1CkdF T006IENvbmZpZ3VyZSBhZDBzNSwgc3RhcnQgMzIyNTYgbGVuZ3RoIDQxMDk0MTQ0IGVuZCA0MTEy NjM5OQpNQlJFWFQgU2xpY2UgNiBvbiBhZDBzNDoKWzBdIGY6MDAgdHlwOjEzMSBzKENIUyk6MTAy My8yNTQvNjMgZShDSFMpOjEwMjMvMjU0LzYzIHM6NjMgbDoxMDEyMDMyClsxXSBmOjAwIHR5cDo1 IHMoQ0hTKToxMDIzLzI1NC82MyBlKENIUyk6MTAyMy8yNTQvNjMgczoxMDkyNDIwIGw6MjIxMDU0 NDAKR0VPTTogQ29uZmlndXJlIGFkMHM2LCBzdGFydCA0MTE1ODY1NiBsZW5ndGggNTE4MTYwMzg0 IGVuZCA1NTkzMTkwMzkKTUJSRVhUIFNsaWNlIDcgb24gYWQwczQ6ClswXSBmOjAwIHR5cDoxMzEg cyhDSFMpOjEwMjMvMjU0LzYzIGUoQ0hTKToxMDIzLzI1NC82MyBzOjYzIGw6MjIxMDUzNzcKWzFd IGY6MDAgdHlwOjAgcyhDSFMpOjAvMC8wIGUoQ0hTKTowLzAvMCBzOjAgbDowCkdFT006IENvbmZp Z3VyZSBhZDBzNywgc3RhcnQgNTU5MzUxMjk2IGxlbmd0aCAxMTMxNzk1MzAyNCBlbmQgMTE4Nzcz MDQzMTkKYXRhMTogcmVpbml0aW5nIGNoYW5uZWwgLi4KYXRhMTogcmVzZXQgdHAxIG1hc2s9MDMg b3N0YXQwPTAwIG9zdGF0MT0wMAphdGExLW1hc3Rlcjogc3RhdD0weDAwIGVycj0weDAxIGxzYj0w eDE0IG1zYj0weGViCmF0YTEtc2xhdmU6ICBzdGF0PTB4MDAgZXJyPTB4MDEgbHNiPTB4MTQgbXNi PTB4ZWIKYXRhMTogcmVzZXQgdHAyIHN0YXQwPTAwIHN0YXQxPTAwIGRldmljZXM9MHhjPEFUQVBJ X1NMQVZFLEFUQVBJX01BU1RFUj4KYXRhMTogcmVzZXR0aW5nIGRvbmUgLi4KYXRhMTogcmVpbml0 aW5nIGNoYW5uZWwgLi4KYXRhMS1zbGF2ZTogRkFJTFVSRSAtIEFUQVBJX0lERU5USUZZIHRpbWVk IG91dAphdGExOiByZWluaXRpbmcgY2hhbm5lbCAuLgphdGExLXNsYXZlOiBGQUlMVVJFIC0gQVRB UElfSURFTlRJRlkgdGltZWQgb3V0CmF0YTEtbWFzdGVyOiBwaW89MHgwYyB3ZG1hPTB4MjIgdWRt YT0weDQyIGNhYmxlPTQwcGluCmF0YTEtbWFzdGVyOiBzZXR0aW5nIFBJTzQgb24gSW50ZWwgSUNI NCBjaGlwCmF0YTEtbWFzdGVyOiBzZXR0aW5nIFVETUEzMyBvbiBJbnRlbCBJQ0g0IGNoaXAKYXRh MTogZGV2aWNlIGNvbmZpZyBkb25lIC4uCmF0YTEtc2xhdmU6IEZBSUxVUkUgLSBBVEFQSV9JREVO VElGWSB0aW1lZCBvdXQKYXRhMS1tYXN0ZXI6IHBpbz0weDBjIHdkbWE9MHgyMiB1ZG1hPTB4NDIg Y2FibGU9NDBwaW4KYXRhMS1tYXN0ZXI6IHNldHRpbmcgUElPNCBvbiBJbnRlbCBJQ0g0IGNoaXAK YXRhMS1tYXN0ZXI6IHNldHRpbmcgVURNQTMzIG9uIEludGVsIElDSDQgY2hpcAphY2QwOiA8TUFU U0hJVEEgQ0QtUlcvRFZELVJPTSBVSkRBNzQwLzEuMDM+IENEUlcgZHJpdmUgYXQgYXRhMSBhcyBt YXN0ZXIKYWNkMDogcmVhZCA0MTM0S0IvcyAoNDEzNEtCL3MpIHdyaXRlIDQxMzRLQi9zICg0MTM0 S0IvcyksIDIwNDhLQiBidWZmZXIsIFVETUEzMwphY2QwOiBSZWFkczogQ0RSLCBDRFJXLCBDRERB IHN0cmVhbSwgRFZEUk9NLCBEVkRSLCBEVkRSQU0sIHBhY2tldAphY2QwOiBXcml0ZXM6IENEUiwg Q0RSVywgdGVzdCB3cml0ZSwgYnVybnByb29mCmFjZDA6IEF1ZGlvOiBwbGF5LCAyNTYgdm9sdW1l IGxldmVscwphY2QwOiBNZWNoYW5pc206IGVqZWN0YWJsZSB0cmF5LCB1bmxvY2tlZAphY2QwOiBN ZWRpdW06IG5vL2JsYW5rIGRpc2MKKHByb2JlMDpzYnAwOjA6MDowKTogZXJyb3IgMjIKKHByb2Jl MDpzYnAwOjA6MDowKTogVW5yZXRyeWFibGUgRXJyb3IKKHByb2JlMTpzYnAwOjA6MTowKTogZXJy b3IgMjIKKHByb2JlMTpzYnAwOjA6MTowKTogVW5yZXRyeWFibGUgRXJyb3IKKHByb2JlMjpzYnAw OjA6MjowKTogZXJyb3IgMjIKKHByb2JlMjpzYnAwOjA6MjowKTogVW5yZXRyeWFibGUgRXJyb3IK KHByb2JlMzpzYnAwOjA6MzowKTogZXJyb3IgMjIKKHByb2JlMzpzYnAwOjA6MzowKTogVW5yZXRy eWFibGUgRXJyb3IKKHByb2JlNDpzYnAwOjA6NDowKTogZXJyb3IgMjIKKHByb2JlNDpzYnAwOjA6 NDowKTogVW5yZXRyeWFibGUgRXJyb3IKKHByb2JlNTpzYnAwOjA6NTowKTogZXJyb3IgMjIKKHBy b2JlNTpzYnAwOjA6NTowKTogVW5yZXRyeWFibGUgRXJyb3IKKHByb2JlNjpzYnAwOjA6NjowKTog ZXJyb3IgMjIKKHByb2JlNjpzYnAwOjA6NjowKTogVW5yZXRyeWFibGUgRXJyb3IKTW91bnRpbmcg cm9vdCBmcm9tIHVmczovZGV2L2FkMHMzYQpXQVJOSU5HOiAvIHdhcyBub3QgcHJvcGVybHkgZGlz bW91bnRlZApzdGFydF9pbml0OiB0cnlpbmcgL3NiaW4vaW5pdApQcmUtc2VlZGluZyBQUk5HOgog a2lja3N0YXJ0Ci4KTG9hZGluZyBjb25maWd1cmF0aW9uIGZpbGVzLgpFbnRyb3B5IGhhcnZlc3Rp bmc6CiBpbnRlcnJ1cHRzCiBldGhlcm5ldAogcG9pbnRfdG9fcG9pbnQKIGtpY2tzdGFydAouCnN3 YXBvbjogYWRkaW5nIC9kZXYvYWQwczJiIGFzIHN3YXAgZGV2aWNlClN0YXJ0aW5nIGZpbGUgc3lz dGVtIGNoZWNrczoKL2Rldi9hZDBzM2E6IDE2MzUgZmlsZXMsIDMwODIwIHVzZWQsIDk4MDk5IGZy ZWUgKDY5OSBmcmFncywgMTIxNzUgYmxvY2tzLCAwLjUlIGZyYWdtZW50YXRpb24pCi9kZXYvYWQw czNlOiBERUZFUiBGT1IgQkFDS0dST1VORCBDSEVDS0lORwovZGV2L2FkMHMzZjogREVGRVIgRk9S IEJBQ0tHUk9VTkQgQ0hFQ0tJTkcKL2Rldi9hZDBzM2Q6IERFRkVSIEZPUiBCQUNLR1JPVU5EIENI RUNLSU5HCldBUk5JTkc6IC90bXAgd2FzIG5vdCBwcm9wZXJseSBkaXNtb3VudGVkCldBUk5JTkc6 IC91c3Igd2FzIG5vdCBwcm9wZXJseSBkaXNtb3VudGVkCldBUk5JTkc6IC92YXIgd2FzIG5vdCBw cm9wZXJseSBkaXNtb3VudGVkClNldHRpbmcgaG9zdG5hbWU6IHByb2xlcHNpcy5tb29vLmNvbS4K bG8wOiBmbGFncz04MDQ5PFVQLExPT1BCQUNLLFJVTk5JTkcsTVVMVElDQVNUPiBtdHUgMTYzODQK CWluZXQgMTI3LjAuMC4xIG5ldG1hc2sgMHhmZjAwMDAwMCAKCWluZXQ2IDo6MSBwcmVmaXhsZW4g MTI4IAoJaW5ldDYgZmU4MDo6MSVsbzAgcHJlZml4bGVuIDY0IHNjb3BlaWQgMHg0IApTdGFydGlu ZyBkaGNsaWVudC4KYmZlMDogZmxhZ3M9ODg0MzxVUCxCUk9BRENBU1QsUlVOTklORyxTSU1QTEVY LE1VTFRJQ0FTVD4gbXR1IDE1MDAKCW9wdGlvbnM9ODxWTEFOX01UVT4KCWluZXQ2IGZlODA6OjIw YjpkYmZmOmZlOTk6ZThjNyViZmUwIHByZWZpeGxlbiA2NCBzY29wZWlkIDB4MSAKCWluZXQgMTAu MC4xLjE3IG5ldG1hc2sgMHhmZmZmZmYwMCBicm9hZGNhc3QgMjU1LjI1NS4yNTUuMjU1CglldGhl ciAwMDowYjpkYjo5OTplODpjNwoJbWVkaWE6IEV0aGVybmV0IGF1dG9zZWxlY3QgKDEwMGJhc2VU WCA8ZnVsbC1kdXBsZXg+KQoJc3RhdHVzOiBhY3RpdmUKQWRkaXRpb25hbCByb3V0aW5nIG9wdGlv bnM6Ci4KYWRkIG5ldCA6OmZmZmY6MC4wLjAuMDogZ2F0ZXdheSA6OjEKYWRkIG5ldCA6OjAuMC4w LjA6IGdhdGV3YXkgOjoxCm5ldC5pbmV0Ni5pcDYuZm9yd2FyZGluZzogCjAKIC0+IAowCgpuZXQu aW5ldDYuaXA2LmFjY2VwdF9ydGFkdjogCjAKIC0+IAoxCgphZGQgbmV0IGZlODA6OjogZ2F0ZXdh eSA6OjEKYWRkIG5ldCBmZjAyOjo6IGdhdGV3YXkgOjoxCklQdjQgbWFwcGVkIElQdjYgYWRkcmVz cyBzdXBwb3J0PU5PClN0YXJ0aW5nIGRldmQuCmh3LmFjcGkuY3B1LmN4X2xvd2VzdDogCkMxCiAt PiAKQzQKCmh3LmFjcGkuY3B1LnRocm90dGxlX3N0YXRlOiAKOAogLT4gCjgKCk1vdW50aW5nIE5G UyBmaWxlIHN5c3RlbXM6Ci4KU3RhcnRpbmcgc3lzbG9nZC4KSmFuIDI5IDE2OjQ5OjA3IHByb2xl cHNpcyBzeXNsb2dkOiBrZXJuZWwgYm9vdCBmaWxlIGlzIC9ib290L2tlcm5lbC9rZXJuZWwKRUxG IGxkY29uZmlnIHBhdGg6IC9saWIgL3Vzci9saWIgL3Vzci9saWIvY29tcGF0IC91c3IvWDExUjYv bGliIC91c3IvbG9jYWwvbGliCmEub3V0IGxkY29uZmlnIHBhdGg6IC91c3IvbGliL2FvdXQgL3Vz ci9saWIvY29tcGF0L2FvdXQgL3Vzci9YMTFSNi9saWIvYW91dApTdGFydGluZyB1c2JkLgpTdGFy dGluZyBsb2NhbCBkYWVtb25zOgouClVwZGF0aW5nIG1vdGQKLgpDb25maWd1cmluZyBzeXNjb25z OgogYmxhbmt0aW1lCiBzY3JlZW5zYXZlcgpzcGxhc2g6IGltYWdlIGRlY29kZXIgZm91bmQ6IGJs YW5rX3NhdmVyCi4KU3RhcnRpbmcgc3NoZC4KYWNwaV9jbWJhdDE6IGJhdHRlcnkgaW5pdGlhbGl6 YXRpb24gZmFpbGVkLCBnaXZpbmcgdXAKSW5pdGlhbCBpMzg2IGluaXRpYWxpemF0aW9uOgouCkFk ZGl0aW9uYWwgQUJJIHN1cHBvcnQ6CiBsaW51eAouClN0YXJ0aW5nIGNyb24uCkxvY2FsIHBhY2th Z2UgaW5pdGlhbGl6YXRpb246Ci4KQWRkaXRpb25hbCBUQ1Agb3B0aW9uczoKLgpTdGFydGluZyBi YWNrZ3JvdW5kIGZpbGUgc3lzdGVtIGNoZWNrcyBpbiA2MCBzZWNvbmRzLgoKU2F0IEphbiAyOSAx Njo1Mjo0MCBDU1QgMjAwNQpKYW4gMjkgMTY6NTY6MTIgcHJvbGVwc2lzIGxvZ2luOiBST09UIExP R0lOIChyb290KSBPTiB0dHl2MQo= ------=_Part_998_135011.1107055584251-- From owner-freebsd-current@FreeBSD.ORG Sun Jan 30 03:52:03 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1235216A4D0; Sun, 30 Jan 2005 03:52:03 +0000 (GMT) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5C38143D39; Sun, 30 Jan 2005 03:52:02 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.13.1/8.13.1) with ESMTP id j0U3pmrw067667; Sat, 29 Jan 2005 22:51:48 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.1/8.13.1) with ESMTP id j0U3poZf081839; Sat, 29 Jan 2005 22:51:50 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id CEA027306E; Sat, 29 Jan 2005 22:51:48 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050130035148.CEA027306E@freebsd-current.sentex.ca> Date: Sat, 29 Jan 2005 22:51:48 -0500 (EST) X-Virus-Scanned: ClamAV 0.80/625/Fri Dec 10 12:41:57 2004 clamav-milter version 0.80j on clamscanner3 X-Virus-Scanned: ClamAV 0.80/690/Fri Jan 28 07:09:45 2005 clamav-milter version 0.80j on clamscanner2 X-Virus-Status: Clean X-Virus-Status: Clean Subject: [current tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jan 2005 03:52:03 -0000 TB --- 2005-01-30 02:32:26 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-01-30 02:32:26 - starting CURRENT tinderbox run for amd64/amd64 TB --- 2005-01-30 02:32:26 - checking out the source tree TB --- 2005-01-30 02:32:26 - cd /home/tinderbox/CURRENT/amd64/amd64 TB --- 2005-01-30 02:32:26 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-01-30 02:38:06 - building world (CFLAGS=-O2 -pipe) TB --- 2005-01-30 02:38:06 - cd /home/tinderbox/CURRENT/amd64/amd64/src TB --- 2005-01-30 02:38:06 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything TB --- 2005-01-30 03:45:44 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-01-30 03:45:44 - cd /home/tinderbox/CURRENT/amd64/amd64/src TB --- 2005-01-30 03:45:44 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sun Jan 30 03:45:45 UTC 2005 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/tinderbox/CURRENT/amd64/amd64/src/sys -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/altq -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/pf -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror /tinderbox/CURRENT/amd64/amd64 /src/sys/isofs/cd9660/cd9660_vnops.c awk -f /tinderbox/CURRENT/amd64/amd64/src/sys/tools/makeobjops.awk /tinderbox/CURRENT/amd64/amd64/src/sys/kern/bus_if.m -c ; cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/tinderbox/CURRENT/amd64/amd64/src/sys -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/altq -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/pf -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno -sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror bus_if.c awk -f /tinderbox/CURRENT/amd64/amd64/src/sys/tools/makeobjops.awk /tinderbox/CURRENT/amd64/amd64/src/sys/kern/device_if.m -c ; cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/tinderbox/CURRENT/amd64/amd64/src/sys -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/altq -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/pf -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse - mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror device_if.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/tinderbox/CURRENT/amd64/amd64/src/sys -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/altq -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/pf -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror /tinderbox/CURRENT/amd64/amd64 /src/sys/kern/imgact_elf.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/tinderbox/CURRENT/amd64/amd64/src/sys -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/altq -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/pf -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror /tinderbox/CURRENT/amd64/amd64 /src/sys/kern/imgact_shell.c /tinderbox/CURRENT/amd64/amd64/src/sys/kern/imgact_shell.c: In function `exec_shell_imgact': /tinderbox/CURRENT/amd64/amd64/src/sys/kern/imgact_shell.c:166: warning: passing arg 4 of `copystr' from incompatible pointer type /tinderbox/CURRENT/amd64/amd64/src/sys/kern/imgact_shell.c:170: warning: passing arg 4 of `copystr' from incompatible pointer type *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/obj/amd64/tinderbox/CURRENT/amd64/amd64/src/sys/GENERIC. *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/src. *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/src. TB --- 2005-01-30 03:51:48 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-01-30 03:51:48 - ERROR: failed to build generic kernel TB --- 2005-01-30 03:51:48 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Sun Jan 30 04:42:37 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D9F0A16A4D0 for ; Sun, 30 Jan 2005 04:42:37 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id B625243D3F for ; Sun, 30 Jan 2005 04:42:37 +0000 (GMT) (envelope-from julian@FreeBSD.org) Received: from freefall.freebsd.org (julian@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.1/8.13.1) with ESMTP id j0U4gbl5077190 for ; Sun, 30 Jan 2005 04:42:37 GMT (envelope-from julian@freefall.freebsd.org) Received: (from julian@localhost) by freefall.freebsd.org (8.13.1/8.13.1/Submit) id j0U4gbWT077189 for current; Sun, 30 Jan 2005 04:42:37 GMT (envelope-from julian) Date: Sun, 30 Jan 2005 04:42:37 GMT From: Julian Elischer Message-Id: <200501300442.j0U4gbWT077189@freefall.freebsd.org> To: current@FreeBSD.org Subject: painted myself into a corner.. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jan 2005 04:42:38 -0000 Ok, so hearing good things about the x.org server and having seen it work elsewhere, I upgraded my laptop from XFree86 to x.org today.. all went fine.. Except running it I just get a black screen. no errors.. The Server thinks it's doing just fine.. ok, so I go to my wife's ibook and surf around a bit and discover that this is known.. Dell Inspiron 7500 and x.org have this problem. There is talk of a workaround in linux.. setting a kernel argument to vga=753 or someothing similar, and there is one posting that talks about a similar workaround for FreeBSD existing, but I have not been able to find the workaround itself. Apparently this has been solved somewhere as well, but I can't find any specific reference to what the fix is/was. If anyone has a hint as to what the problem is (apparently some IBM laptops have the same problem (they use the same Rage mobility-M chip). Looking forward to having X again... If anyone has a dell 7500 working with x,org, I'd love to get a copy of your ati driver or a description of how you solved it.. T.I.A. Julian From owner-freebsd-current@FreeBSD.ORG Sun Jan 30 05:54:46 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 90E2C16A4CE; Sun, 30 Jan 2005 05:54:46 +0000 (GMT) Received: from ion.gank.org (ion.gank.org [69.55.238.164]) by mx1.FreeBSD.org (Postfix) with ESMTP id 586D943D41; Sun, 30 Jan 2005 05:54:46 +0000 (GMT) (envelope-from craig@xfoil.gank.org) Received: from aldaris.auir.gank.org (arbiter.gank.org [64.81.113.221]) by ion.gank.org (mail) with ESMTP id F3C602A90D; Sat, 29 Jan 2005 23:54:45 -0600 (CST) From: Craig Boston To: freebsd-current@freebsd.org Date: Sat, 29 Jan 2005 23:54:42 -0600 User-Agent: KMail/1.7.2 References: <200501300442.j0U4gbWT077189@freefall.freebsd.org> In-Reply-To: <200501300442.j0U4gbWT077189@freefall.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200501292354.42410.craig@xfoil.gank.org> Subject: Re: painted myself into a corner.. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jan 2005 05:54:46 -0000 On Saturday 29 January 2005 10:42 pm, Julian Elischer wrote: > If anyone has a hint as to what the problem is (apparently some IBM > laptops have the same problem (they use the same Rage mobility-M chip). Hmmm, ATI Rage... I don't know if it'll fix the problem or not, but have you looked at the GATOS driver (http://gatos.sourceforge.net/)? The binaries work fine on FreeBSD and I always use it on my laptop in order to get XVideo support. Craig From owner-freebsd-current@FreeBSD.ORG Sun Jan 30 07:10:04 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9384616A4CE for ; Sun, 30 Jan 2005 07:10:04 +0000 (GMT) Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2ECE243D1F for ; Sun, 30 Jan 2005 07:10:04 +0000 (GMT) (envelope-from rsh.lists@comcast.net) Received: from [192.168.1.11] (tardiss.ne.client2.attbi.com[66.30.82.93]) by comcast.net (sccrmhc11) with ESMTP id <2005013007100301100ceq88e>; Sun, 30 Jan 2005 07:10:03 +0000 Message-ID: <41FC8837.8010701@comcast.net> Date: Sun, 30 Jan 2005 02:09:43 -0500 From: Sean User-Agent: Mozilla Thunderbird 1.0 (X11/20050121) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Takeharu KATO References: <41F7102A.9050305@comcast.net> <20050126034803.GA9700@xor.obsecurity.org> <41F8064C.7030600@comcast.net> <41FA5687.1020601@ybb.ne.jp> In-Reply-To: <41FA5687.1020601@ybb.ne.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: current@freebsd.org cc: Kris Kennaway Subject: Re: buildworld error (amd64) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: rsh.lists@comcast.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jan 2005 07:10:04 -0000 Takeharu KATO wrote: > Sean wrote: > >> Kris Kennaway wrote: >> >>> Kris >> >> >> >> Thanks Kris, >> >> I have already tried that several times. >> > I've met the same problem a few days ago. > I try make buildworld and installworld today, it work fine. > For your information, I down-loaded the tree in 2005/01/28. > > > Finally worked for me as well. From owner-freebsd-current@FreeBSD.ORG Sun Jan 30 07:54:32 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AAD7A16A4CF; Sun, 30 Jan 2005 07:54:32 +0000 (GMT) Received: from dglawrence.com (dsl-230-156.ipns.com [209.210.230.156]) by mx1.FreeBSD.org (Postfix) with ESMTP id 130B243D49; Sun, 30 Jan 2005 07:54:30 +0000 (GMT) (envelope-from dg@dglawrence.com) Received: from opteron.dglawrence.com (localhost [127.0.0.1]) by dglawrence.com (8.13.1/8.13.1) with ESMTP id j0U7sRWm087400; Sat, 29 Jan 2005 23:54:27 -0800 (PST) (envelope-from dg@dglawrence.com) Received: (from dg@localhost) by opteron.dglawrence.com (8.13.1/8.13.1/Submit) id j0U7sMkJ087399; Sat, 29 Jan 2005 23:54:22 -0800 (PST) (envelope-from dg@dglawrence.com) Date: Sat, 29 Jan 2005 23:54:22 -0800 From: "David G. Lawrence" To: Kris Kennaway Message-ID: <20050130075422.GL48777@opteron.dglawrence.com> References: <20050130025217.GA32612@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050130025217.GA32612@xor.obsecurity.org> cc: alc@freeBSD.org cc: current@freeBSD.org Subject: Re: do_execve() finding vmspace_destroyed set under load X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jan 2005 07:54:32 -0000 > I'm seeing the following code in do_execve() frequently being > triggered when scripts are executed on my SMP machine under load: > > if (imgp->vmspace_destroyed) { > /* sorry, no more process anymore. exit gracefully */ > #ifdef MAC > mac_execve_exit(imgp); > if (interplabel != NULL) > mac_vnode_label_free(interplabel); > #endif > exit1(td, W_EXITCODE(0, SIGABRT)); > /* NOT REACHED */ > error = 0; > } > > Needless to say, the scripts get pretty unhappy when they're summarily > aborted. What is the cause of this? There are many reasons why an exec can fail - you'd need to collect more info to be able to say specifically. Speaking generally, the above code happens because something failed after the process's address space had been cleared, so there is no process executable image to return to. The only thing to do in that case is to kill off the process. If you're only seeing the problem under load, it is probably indicating that your running out of a kernel VM pool of some kind. -DG David G. Lawrence President Download Technologies, Inc. - http://www.downloadtech.com - (866) 399 8500 TeraSolutions, Inc. - http://www.terasolutions.com - (888) 346 7175 The FreeBSD Project - http://www.freebsd.org Pave the road of life with opportunities. From owner-freebsd-current@FreeBSD.ORG Sun Jan 30 09:35:28 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E65AB16A4CE; Sun, 30 Jan 2005 09:35:28 +0000 (GMT) Received: from obsecurity.dyndns.org (CPE0050040655c8-CM00111ae02aac.cpe.net.cable.rogers.com [69.199.47.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id AADB643D48; Sun, 30 Jan 2005 09:35:28 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id D216A51A01; Sun, 30 Jan 2005 01:35:27 -0800 (PST) Date: Sun, 30 Jan 2005 01:35:27 -0800 From: Kris Kennaway To: "David G. Lawrence" Message-ID: <20050130093527.GA89923@xor.obsecurity.org> References: <20050130025217.GA32612@xor.obsecurity.org> <20050130075422.GL48777@opteron.dglawrence.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6c2NcOVqGQ03X4Wi" Content-Disposition: inline In-Reply-To: <20050130075422.GL48777@opteron.dglawrence.com> User-Agent: Mutt/1.4.2.1i cc: alc@freeBSD.org cc: current@freeBSD.org cc: Kris Kennaway Subject: Re: do_execve() finding vmspace_destroyed set under load X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jan 2005 09:35:29 -0000 --6c2NcOVqGQ03X4Wi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jan 29, 2005 at 11:54:22PM -0800, David G. Lawrence wrote: > > I'm seeing the following code in do_execve() frequently being > > triggered when scripts are executed on my SMP machine under load: > >=20 > > if (imgp->vmspace_destroyed) { > > /* sorry, no more process anymore. exit gracefully */ > > #ifdef MAC > > mac_execve_exit(imgp); > > if (interplabel !=3D NULL) > > mac_vnode_label_free(interplabel); > > #endif > > exit1(td, W_EXITCODE(0, SIGABRT)); > > /* NOT REACHED */ > > error =3D 0; > > } > >=20 > > Needless to say, the scripts get pretty unhappy when they're summarily > > aborted. What is the cause of this? >=20 > There are many reasons why an exec can fail - you'd need to collect > more info to be able to say specifically. Speaking generally, the above > code happens because something failed after the process's address space > had been cleared, so there is no process executable image to return > to. The only thing to do in that case is to kill off the process. If > you're only seeing the problem under load, it is probably indicating > that your running out of a kernel VM pool of some kind. Any suggestions on what to look at to try and debug this further? Kris --6c2NcOVqGQ03X4Wi Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFB/KpfWry0BWjoQKURApj/AJ45sA/eM9CwH98NmhbzNc1I3X0MTgCcDZwJ rNP6NFcHtFA7FcMJPk7CNsc= =xeHI -----END PGP SIGNATURE----- --6c2NcOVqGQ03X4Wi-- From owner-freebsd-current@FreeBSD.ORG Sun Jan 30 09:46:19 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E7B9916A4CE for ; Sun, 30 Jan 2005 09:46:19 +0000 (GMT) Received: from relay03.pair.com (relay03.pair.com [209.68.5.17]) by mx1.FreeBSD.org (Postfix) with SMTP id 38C3C43D2F for ; Sun, 30 Jan 2005 09:46:19 +0000 (GMT) (envelope-from pho@holm.cc) Received: (qmail 1033 invoked from network); 30 Jan 2005 09:46:17 -0000 Received: from unknown (HELO peter.osted.lan) (unknown) by unknown with SMTP; 30 Jan 2005 09:46:17 -0000 X-pair-Authenticated: 80.164.63.199 Received: from peter.osted.lan (localhost.osted.lan [127.0.0.1]) by peter.osted.lan (8.13.1/8.13.1) with ESMTP id j0U9kH7T076129; Sun, 30 Jan 2005 10:46:17 +0100 (CET) (envelope-from pho@peter.osted.lan) Received: (from pho@localhost) by peter.osted.lan (8.13.1/8.13.1/Submit) id j0U9kG0h076128; Sun, 30 Jan 2005 10:46:16 +0100 (CET) (envelope-from pho) Date: Sun, 30 Jan 2005 10:46:16 +0100 From: Peter Holm To: current@freebsd.org Message-ID: <20050130094616.GA76093@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: jroberson@chesapeake.net Subject: Panic: Memory modified after free X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jan 2005 09:46:20 -0000 With GENERIC HEAD from Jan 28 20:19 UTC + mpsafe_vfs = 1 I got: Memory modified after free 0xc1d7c100(124) val=c23fa000 @ 0xc1d7c164 panic(c083d005,c083b16e,c083cfd6,c1d7c100,7c) at panic+0xef mtrash_ctor(c1d7c100,80,0,402) at mtrash_ctor+0x4d uma_zalloc_arg(c10526e0,0,402) at uma_zalloc_arg+0x14c malloc(68,c08bcd60,402,c094f0c0,0) at malloc+0xae inodedep_lookup(c167a000,193a1,1,cf261be0,c094f0c0) at inodedep_lookup+0xa7 softdep_change_linkcnt(c213b578,c6bc54f0,c65f3f88,c213b578,c1c39270) at softdep_change_linkcnt+0x31 ufs_dirremove(c17d83a8,c213b578,100800c,0,cf261c48) at ufs_dirremove+0x12d ufs_remove(cf261c4c) at ufs_remove+0x4b VOP_REMOVE_AP(cf261c4c) at VOP_REMOVE_AP+0x62 kern_unlink(c1add2e0,bfbfe940,0,cf261d40,c07bd6c3) at kern_unlink+0x167 unlink(c1add2e0,cf261d14,1,28,292) at unlink+0x12 syscall(2804002f,bfbf002f,bfbf002f,2804f6c0,bfbfeb14) at syscall+0x213 More info at http://www.holm.cc/stress/log/cons112.html -- Peter Holm From owner-freebsd-current@FreeBSD.ORG Sun Jan 30 10:14:04 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2C0E816A4E9; Sun, 30 Jan 2005 10:14:04 +0000 (GMT) Received: from dglawrence.com (dsl-230-156.ipns.com [209.210.230.156]) by mx1.FreeBSD.org (Postfix) with ESMTP id 93F7D43D2D; Sun, 30 Jan 2005 10:14:03 +0000 (GMT) (envelope-from dg@dglawrence.com) Received: from opteron.dglawrence.com (localhost [127.0.0.1]) by dglawrence.com (8.13.1/8.13.1) with ESMTP id j0UAE3dk087982; Sun, 30 Jan 2005 02:14:03 -0800 (PST) (envelope-from dg@dglawrence.com) Received: (from dg@localhost) by opteron.dglawrence.com (8.13.1/8.13.1/Submit) id j0UAE3aD087981; Sun, 30 Jan 2005 02:14:03 -0800 (PST) (envelope-from dg@dglawrence.com) Date: Sun, 30 Jan 2005 02:14:03 -0800 From: "David G. Lawrence" To: Kris Kennaway Message-ID: <20050130101403.GM48777@opteron.dglawrence.com> References: <20050130025217.GA32612@xor.obsecurity.org> <20050130075422.GL48777@opteron.dglawrence.com> <20050130093527.GA89923@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050130093527.GA89923@xor.obsecurity.org> cc: alc@freeBSD.org cc: current@freeBSD.org Subject: Re: do_execve() finding vmspace_destroyed set under load X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jan 2005 10:14:04 -0000 > > > Needless to say, the scripts get pretty unhappy when they're summarily > > > aborted. What is the cause of this? > > > > There are many reasons why an exec can fail - you'd need to collect > > more info to be able to say specifically. Speaking generally, the above > > code happens because something failed after the process's address space > > had been cleared, so there is no process executable image to return > > to. The only thing to do in that case is to kill off the process. If > > you're only seeing the problem under load, it is probably indicating > > that your running out of a kernel VM pool of some kind. > > Any suggestions on what to look at to try and debug this further? The first thing to do is to add some kernel printf's to do_execve() in each of the 'if (error)' cases to determine where the error is occuring. It's probably not worth putting them in cases prior to the 'loop through the list of image activators', since the vmspace isn't destroyed until then. Once you've done that, the cause of the problem should become obvious. -DG David G. Lawrence President Download Technologies, Inc. - http://www.downloadtech.com - (866) 399 8500 TeraSolutions, Inc. - http://www.terasolutions.com - (888) 346 7175 The FreeBSD Project - http://www.freebsd.org Pave the road of life with opportunities. From owner-freebsd-current@FreeBSD.ORG Sun Jan 30 10:42:42 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DF82C16A4CF for ; Sun, 30 Jan 2005 10:42:42 +0000 (GMT) Received: from ms003msg.fastwebnet.it (ms003msg.fastwebnet.it [213.140.2.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0638F43D2D for ; Sun, 30 Jan 2005 10:42:42 +0000 (GMT) (envelope-from filippo@portatile.fastwebnet.it) Received: from portatile (1.255.90.62) by ms003msg.fastwebnet.it (7.2.052.2) id 41FB568A000270A5 for freebsd-current@freebsd.org; Sun, 30 Jan 2005 11:42:40 +0100 Received: from portatile.fastwebnet.it (localhost [127.0.0.1]) by portatile (Postfix) with ESMTP id DEE8AB876 for ; Sun, 30 Jan 2005 11:42:40 +0100 (CET) Received: (from filippo@localhost) by portatile.fastwebnet.it (8.13.1/8.13.1/Submit) id j0UAgeCD050869 for freebsd-current@freebsd.org; Sun, 30 Jan 2005 11:42:40 +0100 (CET) (envelope-from filippo) Date: Sun, 30 Jan 2005 11:42:39 +0100 From: Filippo Forti To: freebsd-current@freebsd.org Message-ID: <20050130104239.GA50813@portatile.fastwebnet.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6i Subject: ACPI errors X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: filippo.forti@fastwebnet.it List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jan 2005 10:42:43 -0000 Hi, I've started getting this error randomly since about 15 days ago. I've cvsupped yesterday but the error still comes up sometimes. The system is a Dell Inspiron 5100. Sleeping on "acsem" with the following non-sleepable locks held: exclusive sleep mutex acpica subsystem lock r = 0 (0xc235c9c0) locked @ /usr/src/sys/modules/acpi/acpi/../../../dev/acpica/Osd/O sdSynch.c:360 KDB: stack backtrace: kdb_backtrace(c09dbe14,e32beb84,1,1,1) at kdb_backtrace+0x2f witness_warn(5,c235cb40,c08cb115,c0baf5ca,c065b845) at witness_warn+0x1bb msleep(c235cb40,c235cb40,100,c0baf5ca,0) at msleep+0x58 AcpiOsWaitSemaphore(c235cb40,1,ffff,8,15) at AcpiOsWaitSemaphore+0x1fb AcpiUtAcquireMutex(7,1,0,0,0) at AcpiUtAcquireMutex+0x8f AcpiDisableGpe(0,1c,1,c227a7d1,c239f180) at AcpiDisableGpe+0x23 EcGpeHandler(c239f180,1,0,8,102f) at EcGpeHandler+0x3f AcpiEvGpeDispatch(c2380f50,1c,c227a7dd,27fa10,4) at AcpiEvGpeDispatch+0xc4 AcpiEvGpeDetect(c230bc20,0,c230bc20,e32bed14,c064f39e) at AcpiEvGpeDetect+0x12f AcpiEvSciXruptHandler(c230bc20,0,c08c8452,256,c0990c60) at AcpiEvSciXruptHandler+0x2a ithread_loop(c2279880,e32bed48,c08c8251,30e,c2279880) at ithread_loop+0x157 fork_exit(c064f247,c2279880,e32bed48) at fork_exit+0xc7 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xe32bed7c, ebp = 0 --- I'm running with a modified DSDT (downloaded from acpi.sf.net) which I used on linux and FreeBSD since the beginning. Is this normal/not dangerous? Thanks in advance Regards Filippo From owner-freebsd-current@FreeBSD.ORG Sun Jan 30 10:57:34 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4065116A4CE; Sun, 30 Jan 2005 10:57:34 +0000 (GMT) Received: from obsecurity.dyndns.org (CPE0050040655c8-CM00111ae02aac.cpe.net.cable.rogers.com [69.199.47.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 04A8E43D46; Sun, 30 Jan 2005 10:57:34 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 5D05151456; Sun, 30 Jan 2005 02:57:33 -0800 (PST) Date: Sun, 30 Jan 2005 02:57:33 -0800 From: Kris Kennaway To: "David G. Lawrence" Message-ID: <20050130105733.GA71626@xor.obsecurity.org> References: <20050130025217.GA32612@xor.obsecurity.org> <20050130075422.GL48777@opteron.dglawrence.com> <20050130093527.GA89923@xor.obsecurity.org> <20050130101403.GM48777@opteron.dglawrence.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="pWyiEgJYm5f9v55/" Content-Disposition: inline In-Reply-To: <20050130101403.GM48777@opteron.dglawrence.com> User-Agent: Mutt/1.4.2.1i cc: alc@freeBSD.org cc: current@freeBSD.org cc: Kris Kennaway Subject: Re: do_execve() finding vmspace_destroyed set under load X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jan 2005 10:57:34 -0000 --pWyiEgJYm5f9v55/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jan 30, 2005 at 02:14:03AM -0800, David G. Lawrence wrote: > > > > Needless to say, the scripts get pretty unhappy when they're summar= ily > > > > aborted. What is the cause of this? > > >=20 > > > There are many reasons why an exec can fail - you'd need to collect > > > more info to be able to say specifically. Speaking generally, the abo= ve > > > code happens because something failed after the process's address spa= ce > > > had been cleared, so there is no process executable image to return > > > to. The only thing to do in that case is to kill off the process. If > > > you're only seeing the problem under load, it is probably indicating > > > that your running out of a kernel VM pool of some kind. > >=20 > > Any suggestions on what to look at to try and debug this further? >=20 > The first thing to do is to add some kernel printf's to do_execve() > in each of the 'if (error)' cases to determine where the error is occurin= g. > It's probably not worth putting them in cases prior to the 'loop through > the list of image activators', since the vmspace isn't destroyed until > then. > Once you've done that, the cause of the problem should become obvious. Thanks. Kris --pWyiEgJYm5f9v55/ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFB/L2dWry0BWjoQKURAnocAKCG6pt85Dkw7P+MmqfFUH58vY06ggCeL4l+ Krf83DF9TAEByLI+9mwFryk= =Ji9V -----END PGP SIGNATURE----- --pWyiEgJYm5f9v55/-- From owner-freebsd-current@FreeBSD.ORG Sun Jan 30 11:04:04 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1FA7316A4CE for ; Sun, 30 Jan 2005 11:04:04 +0000 (GMT) Received: from critter.freebsd.dk (f170.freebsd.dk [212.242.86.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3336743D1F for ; Sun, 30 Jan 2005 11:04:03 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.1/8.13.1) with ESMTP id j0UB42m5065106 for ; Sun, 30 Jan 2005 12:04:02 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: current@freebsd.org From: Poul-Henning Kamp Date: Sun, 30 Jan 2005 12:04:02 +0100 Message-ID: <65105.1107083042@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Subject: tcp_isn_tick() / dummynet() callout madness ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jan 2005 11:04:04 -0000 Soekris NET4501 Current kernel WITNESS Single user mode 10:55AM up 17 mins, 1 user, load averages: 0.20, 0.15, 0.09 Sun Jan 30 10:56:05 UTC 2005 Callout accounting: count 1061761 time 67.148 func 0xc05573e0 dummynet() count 1061762 time 56.688 func 0xc056c128 tcp_isn_tick() count 10646 time 0.877 func 0xc04e193c count 10609 time 0.778 func 0xc04e193c count 10609 time 0.759 func 0xc04e193c count 10650 time 0.751 func 0xc0455408 count 10608 time 0.751 func 0xc04e193c count 5326 time 0.324 func 0xc04f4fe0 count 10651 time 0.323 func 0xc04d3f00 We spend roughly 5% of the real time in those two callout functions, probably in locking ? -- 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 Sun Jan 30 11:37:49 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B3DF816A4CE; Sun, 30 Jan 2005 11:37:49 +0000 (GMT) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6F81F43D39; Sun, 30 Jan 2005 11:37:49 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with SMTP id AD43046B37; Sun, 30 Jan 2005 06:37:46 -0500 (EST) Date: Sun, 30 Jan 2005 11:37:10 +0000 (GMT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Poul-Henning Kamp In-Reply-To: <65105.1107083042@critter.freebsd.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: silby@FreeBSD.org cc: current@freebsd.org cc: cperciva@FreeBSD.org Subject: Re: tcp_isn_tick() / dummynet() callout madness ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jan 2005 11:37:49 -0000 On Sun, 30 Jan 2005, Poul-Henning Kamp wrote: > count 1061761 time 67.148 func 0xc05573e0 dummynet() > count 1061762 time 56.688 func 0xc056c128 tcp_isn_tick() I think the problem here isn't so much the level of work done in tcp_isn_tick, it's that it runs every tick. I do profiling of our callouts about once every 10-12 months, but haven't re-run it since before the HZ change from 100 to 1000. I'm not surprised that we're seeing increased cost for some of the previously less significant callouts given that change. Although I haven't looked through the dummynet code, it wouldn't surprise me if the same conclusion can be drawn. If you're running a UP kernel, the mutex operations should be pretty cheap, so it's more likely the general overhead of running this code ... a lot. Note that the remainder run 1/100th as often, presumably because they do hz/10 or hz/100 or the like. I've talked to both Colin Percival and Mike Silby about the problem -- since the callout_reset() is one of the more expensive parts of this code, Colin has been looking at some locking optimizations to lower the cost. I attempted to convince Mike that if we thought the ISN sequencing was "sufficiently secure" with HZ of 100, then we should be able to still run it at hz/100 now instead of 1000 times per second, but he seems resistant. I'll CC him so he's forced to reconsider :-). Something to consider for dummynet is a similar change to the one made to the NFS code: the NFS code used to fire a callout at a high rate to manage retransmits and work queues. It was modified to only do this when actually active. If dummynet isn't active on your box, or is not working hard, it can probably afford to run the timer less frequently, noting that the goal of increasing the timer rate is to smooth the bursting in rate limiting (which can result in loss if queues fill unnecessarily as a result of bursting), and to improve the accuracy of introduced latency. Robert N M Watson > count 10646 time 0.877 func 0xc04e193c > count 10609 time 0.778 func 0xc04e193c > count 10609 time 0.759 func 0xc04e193c > count 10650 time 0.751 func 0xc0455408 > count 10608 time 0.751 func 0xc04e193c > count 5326 time 0.324 func 0xc04f4fe0 > count 10651 time 0.323 func 0xc04d3f00 > > We spend roughly 5% of the real time in those two callout functions, > probably in locking ? > > -- > 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. > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Sun Jan 30 13:00:34 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C8DB216A4D0; Sun, 30 Jan 2005 13:00:34 +0000 (GMT) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0996743D5F; Sun, 30 Jan 2005 13:00:25 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.13.1/8.13.1) with ESMTP id j0UD0B1t092374; Sun, 30 Jan 2005 08:00:11 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.1/8.13.1) with ESMTP id j0UD0gjU025983; Sun, 30 Jan 2005 08:00:42 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id A9B0D7306E; Sun, 30 Jan 2005 08:00:11 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050130130011.A9B0D7306E@freebsd-current.sentex.ca> Date: Sun, 30 Jan 2005 08:00:11 -0500 (EST) X-Virus-Scanned: ClamAV 0.80/625/Fri Dec 10 12:41:57 2004 clamav-milter version 0.80j on clamscanner3 X-Virus-Scanned: ClamAV 0.80/690/Fri Jan 28 07:09:45 2005 clamav-milter version 0.80j on avscan2 X-Virus-Status: Clean X-Virus-Status: Clean Subject: [current tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jan 2005 13:00:35 -0000 TB --- 2005-01-30 11:41:07 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-01-30 11:41:07 - starting CURRENT tinderbox run for sparc64/sparc64 TB --- 2005-01-30 11:41:07 - checking out the source tree TB --- 2005-01-30 11:41:07 - cd /home/tinderbox/CURRENT/sparc64/sparc64 TB --- 2005-01-30 11:41:07 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-01-30 11:46:41 - building world (CFLAGS=-O2 -pipe) TB --- 2005-01-30 11:46:41 - cd /home/tinderbox/CURRENT/sparc64/sparc64/src TB --- 2005-01-30 11:46:41 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything TB --- 2005-01-30 12:53:26 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-01-30 12:53:26 - cd /home/tinderbox/CURRENT/sparc64/sparc64/src TB --- 2005-01-30 12:53:26 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sun Jan 30 12:53:26 UTC 2005 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /tinderbox/CURRENT/sparc64/sparc64/src/sys/modules/digi/digi/../../../dev/digi/digi.c:265: warning: redundant redeclaration of 'outb' /tinderbox/CURRENT/sparc64/sparc64/src/sys/modules/digi/digi/../../../dev/digi/digi.c:265: warning: previous implicit declaration of 'outb' was here /tinderbox/CURRENT/sparc64/sparc64/src/sys/modules/digi/digi/../../../dev/digi/digi.c:350: warning: nested extern declaration of `inb' /tinderbox/CURRENT/sparc64/sparc64/src/sys/modules/digi/digi/../../../dev/digi/digi.c:294: warning: redundant redeclaration of 'inb' /tinderbox/CURRENT/sparc64/sparc64/src/sys/modules/digi/digi/../../../dev/digi/digi.c:294: warning: previous implicit declaration of 'inb' was here /tinderbox/CURRENT/sparc64/sparc64/src/sys/modules/digi/digi/../../../dev/digi/digi.c:399: warning: nested extern declaration of `outb' /tinderbox/CURRENT/sparc64/sparc64/src/sys/modules/digi/digi/../../../dev/digi/digi.c:265: warning: redundant redeclaration of 'outb' /tinderbox/CURRENT/sparc64/sparc64/src/sys/modules/digi/digi/../../../dev/digi/digi.c:265: warning: previous implicit declaration of 'outb' was here *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src/sys/modules/digi/digi. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src/sys/modules/digi. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src/sys/modules. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/tinderbox/CURRENT/sparc64/sparc64/src/sys/GENERIC. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src. TB --- 2005-01-30 13:00:11 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-01-30 13:00:11 - ERROR: failed to build generic kernel TB --- 2005-01-30 13:00:11 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Sun Jan 30 14:18:30 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6A76616A4CE; Sun, 30 Jan 2005 14:18:30 +0000 (GMT) Received: from mail.chesapeake.net (chesapeake.net [208.142.252.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0317B43D41; Sun, 30 Jan 2005 14:18:30 +0000 (GMT) (envelope-from jroberson@chesapeake.net) Received: from mail.chesapeake.net (localhost [127.0.0.1]) by mail.chesapeake.net (8.12.10/8.12.10) with ESMTP id j0UEIA8v093215; Sun, 30 Jan 2005 09:18:10 -0500 (EST) (envelope-from jroberson@chesapeake.net) Received: from localhost (jroberson@localhost)j0UEIAAD093202; Sun, 30 Jan 2005 09:18:10 -0500 (EST) (envelope-from jroberson@chesapeake.net) X-Authentication-Warning: mail.chesapeake.net: jroberson owned process doing -bs Date: Sun, 30 Jan 2005 09:18:09 -0500 (EST) From: Jeff Roberson To: Kris Kennaway In-Reply-To: <20050130105733.GA71626@xor.obsecurity.org> Message-ID: <20050130091732.S18864@mail.chesapeake.net> References: <20050130025217.GA32612@xor.obsecurity.org> <20050130093527.GA89923@xor.obsecurity.org> <20050130105733.GA71626@xor.obsecurity.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: alc@freebsd.org cc: "David G. Lawrence" cc: current@freebsd.org Subject: Re: do_execve() finding vmspace_destroyed set under load X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jan 2005 14:18:30 -0000 On Sun, 30 Jan 2005, Kris Kennaway wrote: > On Sun, Jan 30, 2005 at 02:14:03AM -0800, David G. Lawrence wrote: > > > > > Needless to say, the scripts get pretty unhappy when they're summarily > > > > > aborted. What is the cause of this? > > > > > > > > There are many reasons why an exec can fail - you'd need to collect > > > > more info to be able to say specifically. Speaking generally, the above > > > > code happens because something failed after the process's address space > > > > had been cleared, so there is no process executable image to return > > > > to. The only thing to do in that case is to kill off the process. If > > > > you're only seeing the problem under load, it is probably indicating > > > > that your running out of a kernel VM pool of some kind. > > > > > > Any suggestions on what to look at to try and debug this further? > > > > The first thing to do is to add some kernel printf's to do_execve() > > in each of the 'if (error)' cases to determine where the error is occuring. > > It's probably not worth putting them in cases prior to the 'loop through > > the list of image activators', since the vmspace isn't destroyed until > > then. > > Once you've done that, the cause of the problem should become obvious. > > Thanks. Whatever the problem ends up being we should probably make sure there is some kind of reporting in this case. We can't expect normal users to diagnose resource shortages in this way. > > Kris > From owner-freebsd-current@FreeBSD.ORG Sun Jan 30 14:32:15 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 44D8216A4CE; Sun, 30 Jan 2005 14:32:15 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id BD32243D2D; Sun, 30 Jan 2005 14:32:14 +0000 (GMT) (envelope-from scottl@freebsd.org) Received: from pooker.samsco.org (scottl@localhost [127.0.0.1]) by pooker.samsco.org (8.12.11/8.12.10) with ESMTP id j0UEZcs0022243; Sun, 30 Jan 2005 07:35:38 -0700 (MST) (envelope-from scottl@freebsd.org) Received: from localhost (scottl@localhost)j0UEZbhc022240; Sun, 30 Jan 2005 07:35:37 -0700 (MST) (envelope-from scottl@freebsd.org) X-Authentication-Warning: pooker.samsco.org: scottl owned process doing -bs Date: Sun, 30 Jan 2005 07:35:37 -0700 (MST) From: Scott Long Sender: scottl@pooker.samsco.org To: FreeBSD Tinderbox In-Reply-To: <20050130130011.A9B0D7306E@freebsd-current.sentex.ca> Message-ID: <20050130073248.W20417@pooker.samsco.org> References: <20050130130011.A9B0D7306E@freebsd-current.sentex.ca> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=0.0 required=3.8 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pooker.samsco.org cc: current@freebsd.org cc: sparc64@freebsd.org Subject: Re: [current tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jan 2005 14:32:15 -0000 Why on earth is the digi driver bein compiled on sparc64? Scott On Sun, 30 Jan 2005, FreeBSD Tinderbox wrote: > TB --- 2005-01-30 11:41:07 - tinderbox 2.3 running on freebsd-current.sentex.ca > TB --- 2005-01-30 11:41:07 - starting CURRENT tinderbox run for sparc64/sparc64 > TB --- 2005-01-30 11:41:07 - checking out the source tree > TB --- 2005-01-30 11:41:07 - cd /home/tinderbox/CURRENT/sparc64/sparc64 > TB --- 2005-01-30 11:41:07 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src > TB --- 2005-01-30 11:46:41 - building world (CFLAGS=-O2 -pipe) > TB --- 2005-01-30 11:46:41 - cd /home/tinderbox/CURRENT/sparc64/sparc64/src > TB --- 2005-01-30 11:46:41 - /usr/bin/make -B buildworld > >>> Rebuilding the temporary build tree > >>> stage 1.1: legacy release compatibility shims > >>> stage 1.2: bootstrap tools > >>> stage 2.1: cleaning up the object tree > >>> stage 2.2: rebuilding the object tree > >>> stage 2.3: build tools > >>> stage 3: cross tools > >>> stage 4.1: building includes > >>> stage 4.2: building libraries > >>> stage 4.3: make dependencies > >>> stage 4.4: building everything > TB --- 2005-01-30 12:53:26 - building generic kernel (COPTFLAGS=-O2 -pipe) > TB --- 2005-01-30 12:53:26 - cd /home/tinderbox/CURRENT/sparc64/sparc64/src > TB --- 2005-01-30 12:53:26 - /usr/bin/make buildkernel KERNCONF=GENERIC > >>> Kernel build for GENERIC started on Sun Jan 30 12:53:26 UTC 2005 > >>> stage 1: configuring the kernel > >>> stage 2.1: cleaning up the object tree > >>> stage 2.2: rebuilding the object tree > >>> stage 2.3: build tools > >>> stage 3.1: making dependencies > >>> stage 3.2: building everything > [...] > /tinderbox/CURRENT/sparc64/sparc64/src/sys/modules/digi/digi/../../../dev/digi/digi.c:265: warning: redundant redeclaration of 'outb' > /tinderbox/CURRENT/sparc64/sparc64/src/sys/modules/digi/digi/../../../dev/digi/digi.c:265: warning: previous implicit declaration of 'outb' was here > /tinderbox/CURRENT/sparc64/sparc64/src/sys/modules/digi/digi/../../../dev/digi/digi.c:350: warning: nested extern declaration of `inb' > /tinderbox/CURRENT/sparc64/sparc64/src/sys/modules/digi/digi/../../../dev/digi/digi.c:294: warning: redundant redeclaration of 'inb' > /tinderbox/CURRENT/sparc64/sparc64/src/sys/modules/digi/digi/../../../dev/digi/digi.c:294: warning: previous implicit declaration of 'inb' was here > /tinderbox/CURRENT/sparc64/sparc64/src/sys/modules/digi/digi/../../../dev/digi/digi.c:399: warning: nested extern declaration of `outb' > /tinderbox/CURRENT/sparc64/sparc64/src/sys/modules/digi/digi/../../../dev/digi/digi.c:265: warning: redundant redeclaration of 'outb' > /tinderbox/CURRENT/sparc64/sparc64/src/sys/modules/digi/digi/../../../dev/digi/digi.c:265: warning: previous implicit declaration of 'outb' was here > *** Error code 1 > > Stop in /tinderbox/CURRENT/sparc64/sparc64/src/sys/modules/digi/digi. > *** Error code 1 > > Stop in /tinderbox/CURRENT/sparc64/sparc64/src/sys/modules/digi. > *** Error code 1 > > Stop in /tinderbox/CURRENT/sparc64/sparc64/src/sys/modules. > *** Error code 1 > > Stop in /tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/tinderbox/CURRENT/sparc64/sparc64/src/sys/GENERIC. > *** Error code 1 > > Stop in /tinderbox/CURRENT/sparc64/sparc64/src. > *** Error code 1 > > Stop in /tinderbox/CURRENT/sparc64/sparc64/src. > TB --- 2005-01-30 13:00:11 - WARNING: /usr/bin/make returned exit code 1 > TB --- 2005-01-30 13:00:11 - ERROR: failed to build generic kernel > TB --- 2005-01-30 13:00:11 - tinderbox aborted > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Sun Jan 30 15:01:16 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5FB7F16A4CE for ; Sun, 30 Jan 2005 15:01:16 +0000 (GMT) Received: from castle.jp.FreeBSD.org (castle.jp.FreeBSD.org [210.226.20.15]) by mx1.FreeBSD.org (Postfix) with ESMTP id B78C143D54 for ; Sun, 30 Jan 2005 15:01:15 +0000 (GMT) (envelope-from akiyama@jp.FreeBSD.org) Received: from localhost (castle.jp.FreeBSD.org [2001:218:422:1::15]) j0UF0i892706; Mon, 31 Jan 2005 00:00:47 +0900 (JST) (envelope-from akiyama@jp.FreeBSD.org) Date: Mon, 31 Jan 2005 00:00:30 +0900 From: Shunsuke Akiyama To: Sean McNeil In-Reply-To: <1106842398.1142.0.camel@server.mcneil.com> References: <1106727949.8449.3.camel@server.mcneil.com> <20050126233022O.akiyama@jp.FreeBSD.org> <1106842398.1142.0.camel@server.mcneil.com> User-Agent: Wanderlust/2.12.0 (Your Wildest Dreams) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/21.3 (i386--freebsd) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20050131000030W.akiyama@jp.FreeBSD.org> X-Dispatcher: imput version 20040704(IM147) Lines: 88 cc: current@freebsd.org Subject: Re: panic 01/25/04 kernel in uhci uplcom X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jan 2005 15:01:16 -0000 At Thu, 27 Jan 2005 08:13:18 -0800, Sean McNeil wrote: > > On Wed, 2005-01-26 at 23:30 +0900, Shunsuke Akiyama wrote: > > At Wed, 26 Jan 2005 00:25:49 -0800, > > Sean McNeil wrote: > > > > > I got a panic on a recent kernel: > > > > > > FreeBSD server.mcneil.com 6.0-CURRENT FreeBSD 6.0-CURRENT #2: Fri Jan 7 > > > 18:21:53 PST 2005 root@server.mcneil.com:/usr/obj/usr/src/sys/AMD64 > > > amd64 > > > > > > Jan 25 23:50:39 server syslogd: kernel boot file > > > is /boot/kernel.old/kernel > > > Jan 25 23:50:39 server kernel: panic: uhci_abort_xfer: not in process > > > context > > > Jan 25 23:50:39 server kernel: Uptime: 1m39s > > > Jan 25 23:50:39 server kernel: interrupt total > > > Jan 25 23:50:39 server kernel: irq1: atkbd0 2 > > > Jan 25 23:50:39 server kernel: irq0: clk 323813 > > > Jan 25 23:50:39 server kernel: irq4: sio0 5 > > > Jan 25 23:50:39 server kernel: irq8: rtc 20738 > > > Jan 25 23:50:39 server kernel: irq14: ata0 722 > > > Jan 25 23:50:39 server kernel: irq15: ata1 186 > > > Jan 25 23:50:39 server kernel: irq16: re0 62 > > > Jan 25 23:50:39 server kernel: irq17: fwohci0 1 > > > Jan 25 23:50:39 server kernel: irq19: dc0 2 > > > Jan 25 23:50:39 server kernel: irq20: atapci0 6006 > > > Jan 25 23:50:39 server kernel: irq21: uhci0 uhci1+ 136 > > > Jan 25 23:50:39 server kernel: Total 351673 > > > Jan 25 23:50:39 server kernel: KDB: stack backtrace: > > > Jan 25 23:50:39 server kernel: hardclock() at hardclock+0x1eb > > > Jan 25 23:50:39 server kernel: intr_execute_handlers() at > > > intr_execute_handlers+0x102 > > > Jan 25 23:50:39 server kernel: lapic_handle_intr() at lapic_handle_intr > > > +0x21 > > > Jan 25 23:50:39 server kernel: Xapic_isr1() at Xapic_isr1+0x7d > > > Jan 25 23:50:39 server kernel: --- interrupt, rip = 0xffffffff802eb1e1, > > > rsp = 0xffffffffb19187e0, rbp = 0xffffffffb1918810 --- > > > Jan 25 23:50:39 server kernel: cv_wait() at cv_wait+0x1 > > > Jan 25 23:50:39 server kernel: ata_queue_request() at ata_queue_request > > > +0x1e8 > > > Jan 25 23:50:39 server kernel: ata_controlcmd() at ata_controlcmd+0x8b > > > Jan 25 23:50:39 server kernel: ata_shutdown() at ata_shutdown+0xb8 > > > Jan 25 23:50:39 server kernel: boot() at boot+0x25c > > > Jan 25 23:50:39 server kernel: panic() at panic+0x167 > > > Jan 25 23:50:39 server kernel: uhci_abort_xfer() at uhci_abort_xfer+0x68 > > > Jan 25 23:50:39 server kernel: usbd_abort_pipe() at usbd_abort_pipe+0x27 > > > Jan 25 23:50:39 server kernel: ucomstopread() at ucomstopread+0x27 > > > Jan 25 23:50:39 server kernel: ucomstop() at ucomstop+0x2f > > > Jan 25 23:50:39 server kernel: ttyflush() at ttyflush+0x34 > > > Jan 25 23:50:39 server kernel: ttymodem() at ttymodem+0x9e > > > Jan 25 23:50:39 server kernel: ucom_status_change() at > > > ucom_status_change+0x93 > > > Jan 25 23:50:39 server kernel: uplcom_intr() at uplcom_intr+0x94 > > > Jan 25 23:50:39 server kernel: usb_transfer_complete() at > > > usb_transfer_complete+0x201 > > > Jan 25 23:50:39 server kernel: uhci_softintr() at uhci_softintr+0x100 > > > Jan 25 23:50:39 server kernel: uhci_intr1() at uhci_intr1+0xd5 > > > Jan 25 23:50:39 server kernel: ithread_loop() at ithread_loop+0xd3 > > > Jan 25 23:50:39 server kernel: fork_exit() at fork_exit+0x8f > > > Jan 25 23:50:39 server kernel: fork_trampoline() at fork_trampoline+0xe > > > Jan 25 23:50:39 server kernel: --- trap 0, rip = 0, rsp = > > > 0xffffffffb1918d00, rbp = 0 --- > > > > Oh, usbd_abort_pipe() and underlaying uhci_abort_xfer() should be > > called from non interrupt context only. uhci_abort_xfer() checks this > > condition and make a panic. > > > > This is not a problem only for uplcom(4). Both umodem(4) and > > uvscom(4) potentially have a same problem. > > > > Please try attached patch and let me know the result. > > This patch eliminated my panic. > > Thanks, > Sean Thank you for reporting. I'll commit these changes. Regards, -- Shunsuke Akiyama akiyama@jp.FreeBSD.org akiyama@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Sun Jan 30 15:14:34 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4192316A4CE; Sun, 30 Jan 2005 15:14:34 +0000 (GMT) Received: from mailout08.sul.t-online.com (mailout08.sul.t-online.com [194.25.134.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id 678C343D41; Sun, 30 Jan 2005 15:14:33 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from fwd06.aul.t-online.de by mailout08.sul.t-online.com with smtp id 1CvGlT-0007Mr-00; Sun, 30 Jan 2005 16:13:27 +0100 Received: from Andro-Beta.Leidinger.net (TEvtdgZHQeCXSAp+zf-kyt2LkASTtrq9YETWfuKY7Z--woZ8X8+oZA@[217.83.23.129]) by fmrl06.sul.t-online.com with esmtp id 1CvGlN-1naHSa0; Sun, 30 Jan 2005 16:13:21 +0100 Received: from Magellan.Leidinger.net (Magellan.Leidinger.net [192.168.1.1]) j0UFD3Sh069567; Sun, 30 Jan 2005 16:13:04 +0100 (CET) (envelope-from Alexander@Leidinger.net) Date: Sun, 30 Jan 2005 16:13:23 +0100 From: Alexander Leidinger To: Robert Watson Message-ID: <20050130161323.5e25414e@Magellan.Leidinger.net> In-Reply-To: References: <20050125.095019.71141844.imp@harmony.village.org> X-Mailer: Sylpheed-Claws 1.0.0 (GTK+ 1.2.10; i386-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-ID: TEvtdgZHQeCXSAp+zf-kyt2LkASTtrq9YETWfuKY7Z--woZ8X8+oZA@t-dialin.net X-TOI-MSGID: c3f53cbd-9563-4a7c-9f20-76fa9d22f035 cc: Warner Losh cc: current@freebsd.org cc: pete@altadena.net cc: imp@bsdimp.com Subject: Re: Devd event from GEOM? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jan 2005 15:14:34 -0000 On Tue, 25 Jan 2005 17:01:27 +0000 (GMT) Robert Watson wrote: > A simple auto-mounter simply watches for every storage device that arrives > via GEOM, checks to see if it's leaf class, and if it is, tastes for a > file system header, auto-detecting some of the simple and common types, > such as FAT, UFS, UFS2, cd9660. It can then use whatever logic it > pleases, probably partly from a config file, to decide where to mount it, > what security parameters to use, etc. Here-in lies the key: because devd > says "a storage device, /dev/ad0s1a arrived", it knows it can just go > ahead and taste, not worrying about rewinding the tape, reading from > kernel memory, etc. The auto-mounter specifically wants to hear only > about GEOMs. While you are talking about it and tossing out ideas... do you also think about what to do when the hardware in question is supposed to go away? Let's take a CD for example, when it arrives the auto-mounter mounts it. Fine, but the CD is locked then. What do we do when we want to remove the CD? Or another example, an USB stick. The hardware isn't locked, but when we just remove it, we're calling for a kernel panic. So we can't talk about a "simple" auto-mounter (device appears -> mount it). And as long as we don't talk about a "not-so-simple" auto-mounter (one which knows about how to interact with non-root users -- perhaps in a safe manner, whatever this means ATM) we don't need to talk about such arrival events, since we need user interaction to remove the devices anyway (when you need to umount the device by hand, it's not that much more effort to mount it in the first place). Bye, Alexander. -- Reboot America. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 From owner-freebsd-current@FreeBSD.ORG Sun Jan 30 15:22:40 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8E3B316A4CE; Sun, 30 Jan 2005 15:22:40 +0000 (GMT) Received: from critter.freebsd.dk (f170.freebsd.dk [212.242.86.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id D56F743D2F; Sun, 30 Jan 2005 15:22:39 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.1/8.13.1) with ESMTP id j0UFKZDX069176; Sun, 30 Jan 2005 16:20:35 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Alexander Leidinger From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sun, 30 Jan 2005 16:13:23 +0100." <20050130161323.5e25414e@Magellan.Leidinger.net> Date: Sun, 30 Jan 2005 16:20:35 +0100 Message-ID: <69175.1107098435@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: Warner Losh cc: Robert Watson cc: current@freebsd.org cc: pete@altadena.net cc: imp@bsdimp.com Subject: Re: Devd event from GEOM? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jan 2005 15:22:40 -0000 In message <20050130161323.5e25414e@Magellan.Leidinger.net>, Alexander Leidinger writes: >Let's take a CD for example, when it arrives the auto-mounter mounts it. >Fine, but the CD is locked then. What do we do when we want to remove >the CD? Or another example, an USB stick. The hardware isn't locked, but >when we just remove it, we're calling for a kernel panic. Now that local-storage filesystems are GEOM users, we can actually get the "orphan" event from GEOM communicated to the filesystem which can then take proper evasive action. No filesystem has implemented this yet. -- 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 Sun Jan 30 15:34:22 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7E60516A4CE for ; Sun, 30 Jan 2005 15:34:22 +0000 (GMT) Received: from mailout01.sul.t-online.com (mailout01.sul.t-online.com [194.25.134.80]) by mx1.FreeBSD.org (Postfix) with ESMTP id 05E4B43D1D for ; Sun, 30 Jan 2005 15:34:20 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from fwd08.aul.t-online.de by mailout01.sul.t-online.com with smtp id 1CvH5e-0003xn-05; Sun, 30 Jan 2005 16:34:18 +0100 Received: from Andro-Beta.Leidinger.net (rXmlh6ZCQeBUyTbCcX2s0DgjiPhPJ8CLswLMjBR-2Hf+t8SHd-AWg0@[217.83.23.129]) by fmrl08.sul.t-online.com with esmtp id 1CvH5Y-0yKaHo0; Sun, 30 Jan 2005 16:34:12 +0100 Received: from Magellan.Leidinger.net (Magellan.Leidinger.net [192.168.1.1]) j0UFY0cl072412; Sun, 30 Jan 2005 16:34:00 +0100 (CET) (envelope-from Alexander@Leidinger.net) Date: Sun, 30 Jan 2005 16:34:20 +0100 From: Alexander Leidinger To: Max Laier Message-ID: <20050130163420.1574603b@Magellan.Leidinger.net> In-Reply-To: <200501291827.27506.max@love2party.net> References: <20050129161022.0de822fe@Magellan.Leidinger.net> <200501291827.27506.max@love2party.net> X-Mailer: Sylpheed-Claws 1.0.0 (GTK+ 1.2.10; i386-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-ID: rXmlh6ZCQeBUyTbCcX2s0DgjiPhPJ8CLswLMjBR-2Hf+t8SHd-AWg0@t-dialin.net X-TOI-MSGID: f5d53d2c-954f-4670-b8b7-33d6eeacc286 cc: freebsd-current@freebsd.org Subject: Re: We have a lot of duplicated code in the kernel X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jan 2005 15:34:22 -0000 On Sat, 29 Jan 2005 18:27:17 +0100 Max Laier wrote: > Could you regenerate the list w/o the MD code, as a first step? This might > turn up a couple of "easy to fix" cases of shared code. Following is how I filter out the unwanted parts. Any ideas how to filter out the MD parts without losing the possibility to determine duplicated code for a specific architecture? Simian itself doesn't offers a good exclude feature. ---snip--- awk <"${log}.bak" ' BEGIN { found=0 last="" } { if(0 != match($0, "(twa_fwimg|trlld.m|if_patm_rtables)")) { next; } if(0 != index($0, "Found")) { found = 1; last = $0; } else if(0 != index($0, "Processed")) { found = 0; print $0; } else { if(1 == found) { found = 0; print last; } print $0; } }' >"${log}" ---snip--- ATM I just can suggest to read over the MD parts. Bye, Alexander. -- Where do you think you're going today? http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 From owner-freebsd-current@FreeBSD.ORG Sun Jan 30 15:36:00 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1D50816A4CE for ; Sun, 30 Jan 2005 15:36:00 +0000 (GMT) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id D8A4843D48 for ; Sun, 30 Jan 2005 15:35:59 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with SMTP id 6E85846B2D; Sun, 30 Jan 2005 10:35:59 -0500 (EST) Date: Sun, 30 Jan 2005 15:35:22 +0000 (GMT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Alexander Leidinger In-Reply-To: <20050130161323.5e25414e@Magellan.Leidinger.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Warner Losh cc: current@freebsd.org cc: pete@altadena.net cc: imp@bsdimp.com Subject: Re: Devd event from GEOM? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jan 2005 15:36:00 -0000 On Sun, 30 Jan 2005, Alexander Leidinger wrote: > While you are talking about it and tossing out ideas... do you also > think about what to do when the hardware in question is supposed to go > away? > > Let's take a CD for example, when it arrives the auto-mounter mounts it. > Fine, but the CD is locked then. What do we do when we want to remove > the CD? Or another example, an USB stick. The hardware isn't locked, but > when we just remove it, we're calling for a kernel panic. One of the "big missing events" we need to do desktop automounting easily and correctly is the "eject request" event. automounted needs to learn that the user has requested an eject of the CD, and that it should go out an unmount the file system, and then issue the software eject and/or allow the user to be notified. Note that there are at least two interesting sources of eject requests: hardware that has a soft eject mechanism, and software that indicates the user intent to perform a hard eject. Examples would be the eject button on your CDROM drive, and the little XP applet that allows you to tell the OS you're done with your USB keychain. It strikes me that devd and its event mechanism are good places for those events to end up, but how they get passed around in the kernel is an interesting question. Where do we find soft eject buttons today, and how do they relate to the hardware they effect? On a CDROM drive, presumably we get an ATAPI event of some sort (or maybe we poll for it?) so there's a clear relationship between the device that will perform the eject and the event source. In this scenario, you could imagine GEOM providing an event mechanism to notify for eject requests so GEOM classes could act on that request, and/or pass it on. But for stuff like removable PCI hardware, etc, I don't know what the hardware capabilities are, or the requirements. This all relates closely to the quiesce behavior in newbus, so the kernel mechanisms that represent this stuff may differ a lot, even if we want to make it look somewhat the same to the user. Note that one of the quite neat things about XP's eject tool is that it appears to do a decent job of identifying the implications of a user-requested eject: it shows you the bus the device is on, the device itself, that it provides a storage service, and what file system is mounted on it when it says "are you sure". That level of inter-layer integration, even if only a veneer on top, is desirable (and also hard). Robert N M Watson From owner-freebsd-current@FreeBSD.ORG Sun Jan 30 15:37:41 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F1FB716A4CE for ; Sun, 30 Jan 2005 15:37:40 +0000 (GMT) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id B555B43D54 for ; Sun, 30 Jan 2005 15:37:40 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with SMTP id 59F0246B32; Sun, 30 Jan 2005 10:37:40 -0500 (EST) Date: Sun, 30 Jan 2005 15:37:03 +0000 (GMT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Poul-Henning Kamp In-Reply-To: <69175.1107098435@critter.freebsd.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Alexander Leidinger cc: imp@bsdimp.com cc: current@freebsd.org cc: pete@altadena.net cc: Warner Losh Subject: Re: Devd event from GEOM? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jan 2005 15:37:41 -0000 On Sun, 30 Jan 2005, Poul-Henning Kamp wrote: > In message <20050130161323.5e25414e@Magellan.Leidinger.net>, Alexander Leidinger writes: > > >Let's take a CD for example, when it arrives the auto-mounter mounts it. > >Fine, but the CD is locked then. What do we do when we want to remove > >the CD? Or another example, an USB stick. The hardware isn't locked, but > >when we just remove it, we're calling for a kernel panic. > > Now that local-storage filesystems are GEOM users, we can actually get > the "orphan" event from GEOM communicated to the filesystem which can > then take proper evasive action. No filesystem has implemented this yet. I think tolerance of hard removal faults will always be a tricky issue -- we can clearly handle it better than we do today. The user losing data is fine: if you don't want to lose data, you have to arrange for a clean unmount. However, today's panic is a bit extreme. The good news is that soft eject is a lot easier to handle, as it's more of a question of signalling and management than hard technical issues in how to tear down state at a bad moment in the kernel. Robert N M Watson From owner-freebsd-current@FreeBSD.ORG Sun Jan 30 16:35:57 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 142E416A4CE for ; Sun, 30 Jan 2005 16:35:57 +0000 (GMT) Received: from av3-2-sn4.m-sp.skanova.net (av3-2-sn4.m-sp.skanova.net [81.228.10.113]) by mx1.FreeBSD.org (Postfix) with ESMTP id 548D743D45 for ; Sun, 30 Jan 2005 16:35:56 +0000 (GMT) (envelope-from lothrandil@n00b.apagnu.se) Received: by av3-2-sn4.m-sp.skanova.net (Postfix, from userid 502) id 8874837E44; Sun, 30 Jan 2005 17:35:55 +0100 (CET) Received: from smtp2-2-sn4.m-sp.skanova.net (smtp2-2-sn4.m-sp.skanova.net [81.228.10.182]) by av3-2-sn4.m-sp.skanova.net (Postfix) with ESMTP id 7970E37E43 for ; Sun, 30 Jan 2005 17:35:55 +0100 (CET) Received: from [217.208.32.115] (h115n2fls31o926.telia.com [217.208.32.115]) by smtp2-2-sn4.m-sp.skanova.net (Postfix) with ESMTP id 4B82537E43 for ; Sun, 30 Jan 2005 17:35:55 +0100 (CET) Message-ID: <41FD0CE3.8070406@n00b.apagnu.se> Date: Sun, 30 Jan 2005 17:35:47 +0100 From: Niclas Zeising User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: current@freebsd.org Content-Type: multipart/mixed; boundary="------------030805010204010903060103" Subject: [PATCH] Kernel module compile faliure in mcd X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jan 2005 16:35:57 -0000 This is a multi-part message in MIME format. --------------030805010204010903060103 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Don't know if this should be filed as a pr, but as the fix is trivial and just need to be committed (I belive) i send it here. Please correct me if i should file a PR. In rev 1.145 of src/sys/dev/mcd/mcd.c there is a typo which makes the kernel build fail. On line 1432 there is a return(0) missing an ending ';'. Patch included. Cheers! //Niclas -- --------------030805010204010903060103 Content-Type: text/plain; name="mcd.c.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="mcd.c.diff" --- mcd.c.orig 2005-01-30 17:20:14.000000000 +0100 +++ mcd.c 2005-01-30 17:34:30.000000000 +0100 @@ -1429,7 +1429,7 @@ if (nocopyout == 0) return copyout(&data, sch->data, min(sizeof(struct cd_sub_channel_info), sch->data_len)); bcopy(&data, sch->data, min(sizeof(struct cd_sub_channel_info), sch->data_len)); - return (0) + return (0); } static int --------------030805010204010903060103-- From owner-freebsd-current@FreeBSD.ORG Sun Jan 30 16:42:48 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 71B2916A4CE for ; Sun, 30 Jan 2005 16:42:48 +0000 (GMT) Received: from mp2.macomnet.net (mp2.macomnet.net [195.128.64.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7A8DA43D31 for ; Sun, 30 Jan 2005 16:42:47 +0000 (GMT) (envelope-from maxim@macomnet.ru) Received-SPF: pass (mp2.macomnet.net: domain of maxim@macomnet.ru designates 127.0.0.1 as permitted sender) receiver=mp2.macomnet.net; client_ip=127.0.0.1; envelope-from=maxim@macomnet.ru; Received: from localhost (localhost [127.0.0.1]) by mp2.macomnet.net (8.12.11/8.12.11) with ESMTP id j0UGgjkq083616; Sun, 30 Jan 2005 19:42:45 +0300 (MSK) (envelope-from maxim@macomnet.ru) Date: Sun, 30 Jan 2005 19:42:45 +0300 (MSK) From: Maxim Konovalov To: Niclas Zeising In-Reply-To: <41FD0CE3.8070406@n00b.apagnu.se> Message-ID: <20050130194232.X83593@mp2.macomnet.net> References: <41FD0CE3.8070406@n00b.apagnu.se> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SpamTest-Info: Profile: Formal (202/050128) X-SpamTest-Info: Profile: Detect Hard (4/030526) X-SpamTest-Info: Profile: SysLog X-SpamTest-Info: Profile: Marking - Keywords (2/030321) X-SpamTest-Status: Not detected X-SpamTest-Version: SMTP-Filter Version 2.0.0 [0124], SpamtestISP/Release cc: current@freebsd.org Subject: Re: [PATCH] Kernel module compile faliure in mcd X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jan 2005 16:42:48 -0000 On Sun, 30 Jan 2005, 17:35+0100, Niclas Zeising wrote: > Don't know if this should be filed as a pr, but as the fix is > trivial and just need to be committed (I belive) i send it here. > Please correct me if i should file a PR. > > In rev 1.145 of src/sys/dev/mcd/mcd.c there is a typo which makes > the kernel build fail. On line 1432 there is a return(0) missing an > ending ';'. Patch included. Cheers! //Niclas Fixed, thanks! -- Maxim Konovalov From owner-freebsd-current@FreeBSD.ORG Sun Jan 30 17:25:28 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4116D16A4CE for ; Sun, 30 Jan 2005 17:25:28 +0000 (GMT) Received: from mail.ccl.ru (mail.ccl.ru [195.222.130.78]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3C9AF43D1F for ; Sun, 30 Jan 2005 17:25:27 +0000 (GMT) (envelope-from andrey@hm.perm.ru) Received: from homeuser123.ccl.ru (homeuser123.ccl.ru [195.222.154.123]) by mail.ccl.ru (8.13.1/8.13.1) with ESMTP id j0UHPMDw038217 for ; Sun, 30 Jan 2005 22:25:23 +0500 (YEKT) Date: Sun, 30 Jan 2005 22:26:09 +0500 From: Àíäðåé Õëåáóòèí X-Mailer: The Bat! (v3.0) Professional X-Priority: 3 (Normal) Message-ID: <1018913216.20050130222609@hm.perm.ru> To: Marc van Kempen In-Reply-To: <41FC0801.3090102@bowtie.nl> References: <41FC0801.3090102@bowtie.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: usb lpt crashes FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Andrew Khlebutin List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jan 2005 17:25:28 -0000 Hello, Marc van Kempen wrote: MvK> I regularly get crashes when printing to my laserprinter, connected to a MvK> usb port. This is on FreeBSD 5.3-STABLE from 18-01-2005. I've the same problem on me 5.3-R & 5.3-Stable boxes. uhci0: port 0xd000-0xd01f irq 11 at device 17.2 on pci0 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered ulpt0: HewLett Packard HP LaserJet 1200, rev 1.10/1.00, addr 2, iclass 7/1 ulpt0: using bi-directional mode uhci1: port 0xd400-0xd41f irq 11 at device 17.3 on pci0 uhci1: [GIANT-LOCKED] usb1: on uhci1 usb1: USB revision 1.0 uhub1: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered -- Andrew From owner-freebsd-current@FreeBSD.ORG Sun Jan 30 18:17:40 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E248E16A4CE for ; Sun, 30 Jan 2005 18:17:40 +0000 (GMT) Received: from tx6.mail.ox.ac.uk (tx6.mail.ox.ac.uk [163.1.2.171]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5CBA943D54 for ; Sun, 30 Jan 2005 18:17:40 +0000 (GMT) (envelope-from cperciva@freebsd.org) Received: from scan6.mail.ox.ac.uk ([163.1.2.179] helo=localhost) by tx6.mail.ox.ac.uk with esmtp (Exim 4.42) id 1CvJdj-0005Pz-Ly for current@freebsd.org; Sun, 30 Jan 2005 18:17:39 +0000 Received: from rx6.mail.ox.ac.uk ([163.1.2.170]) by localhost (scan6.mail.ox.ac.uk [163.1.2.179]) (amavisd-new, port 25) with ESMTP id 20376-09 for ; Sun, 30 Jan 2005 18:17:39 +0000 (GMT) Received: from smtp2.herald.ox.ac.uk ([163.1.0.235]) by rx6.mail.ox.ac.uk with esmtp (Exim 4.42) id 1CvJdi-0005Pc-MQ; Sun, 30 Jan 2005 18:17:38 +0000 Received: from dhcp1151.wadham.ox.ac.uk ([163.1.161.151]) by smtp2.herald.ox.ac.uk with esmtp (Exim 3.35 #1) id 1CvJdi-0002IV-3n; Sun, 30 Jan 2005 18:17:38 +0000 Message-ID: <41FD24C2.5070700@freebsd.org> Date: Sun, 30 Jan 2005 18:17:38 +0000 From: Colin Percival User-Agent: Mozilla Thunderbird 1.0 (X11/20050113) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Watson References: In-Reply-To: X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: Poul-Henning Kamp cc: silby@freebsd.org cc: current@freebsd.org Subject: Re: tcp_isn_tick() / dummynet() callout madness ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jan 2005 18:17:41 -0000 Robert Watson wrote: > since the callout_reset() is one of the more > expensive parts of this code, Colin has been looking at some locking > optimizations to lower the cost. To elaborate somewhat: I think I can avoid the spinlock cost when callouts reset themselves (which is the case here). However, while this will reduce the time spent in the callouts themselves, it's really only a 50% solution -- softclock locks and unlocks the callout spin lock each time it launches a callout. If we're spending 5% of our cpu time in these two callouts, then they're actually responsible for using 10% of our cpu time; I think I can cut that in half, but in the end we can't avoid the cost of a mtx_lock_spin / mtx_unlock_spin pair (in softclock) for each callout. Colin Percival From owner-freebsd-current@FreeBSD.ORG Sun Jan 30 18:59:58 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9153816A4CE; Sun, 30 Jan 2005 18:59:58 +0000 (GMT) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6029B43D1D; Sun, 30 Jan 2005 18:59:58 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with SMTP id B846646B0D; Sun, 30 Jan 2005 13:59:57 -0500 (EST) Date: Sun, 30 Jan 2005 18:59:20 +0000 (GMT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Colin Percival In-Reply-To: <41FD24C2.5070700@freebsd.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Poul-Henning Kamp cc: silby@freebsd.org cc: current@freebsd.org Subject: Re: tcp_isn_tick() / dummynet() callout madness ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jan 2005 18:59:58 -0000 On Sun, 30 Jan 2005, Colin Percival wrote: > Robert Watson wrote: > > since the callout_reset() is one of the more > > expensive parts of this code, Colin has been looking at some locking > > optimizations to lower the cost. > > To elaborate somewhat: I think I can avoid the spinlock cost when > callouts reset themselves (which is the case here). However, while this > will reduce the time spent in the callouts themselves, it's really only > a 50% solution -- softclock locks and unlocks the callout spin lock each > time it launches a callout. If we're spending 5% of our cpu time in > these two callouts, then they're actually responsible for using 10% of > our cpu time; I think I can cut that in half, but in the end we can't > avoid the cost of a mtx_lock_spin / mtx_unlock_spin pair (in softclock) > for each callout. On some further iteration, it transpired that Poul-Henning's configuration included WITNESS, and without that things look a bit more reasonable. We should still run the callout less often, if we can, and I think the optimization is useful. Robert N M Watson From owner-freebsd-current@FreeBSD.ORG Sun Jan 30 20:00:30 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0133016A4CE for ; Sun, 30 Jan 2005 20:00:30 +0000 (GMT) Received: from omoikane.mb.skyweb.ca (omoikane.mb.skyweb.ca [64.42.246.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6B25143D1F for ; Sun, 30 Jan 2005 20:00:29 +0000 (GMT) (envelope-from mark@skyweb.ca) Received: by omoikane.mb.skyweb.ca (Postfix, from userid 1001) id C879961DBE; Sun, 30 Jan 2005 14:00:31 -0600 (CST) From: Mark Johnston To: current@freebsd.org, freebsd-cvs-summary@lists.enderunix.org Date: Sun, 30 Jan 2005 14:00:31 -0600 User-Agent: KMail/1.6.1 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200501301400.31130.mjohnston@skyweb.ca> Subject: cvs-src summary for January 18-24 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jan 2005 20:00:30 -0000 FreeBSD cvs-src summary for 2005-01-18 to 2005-01-24 ++++++++++++++++++++++++++++++++++++++++++++++++++++ This is a regular weekly summary of FreeBSD's cutting-edge development. It is intended to help the FreeBSD community keep up with the fast-paced work going on in FreeBSD-CURRENT by distilling the deluge of data from the CVS mailing list into a (hopefully) easy-to-read newsletter. You can get old summaries, and an HTML version of this one, at http://www.xl0.org/FreeBSD/. An RSS feed is available from http://excel.xl0.org/cgi-bin/rss.py. If you would like to receive the summary without subscribing to current@, send a blank message to freebsd-cvs-summary-subscribe@lists.enderunix.org; thanks to Omer Faruk Sen and EnderUNIX for hosting this list. Please send any comments to Mark Johnston (mark at xl0.org). ============ New Features ============ MemGuard memory-use bug finder added ------------------------------------ Bosko Milekic (bmilekic) added MemGuard, a new memory allocator that can detect when a program uses memory after releasing it with the free function. Instructions for turning it on are in his post, linked below. The MemGuard code is partly based on some old patches from Ian Dowse (iedowse). http://www.freebsd.org/cgi/mid.cgi?200501211809.j0LI9Hh3092619 MAC access control support for System V message queues, semaphores, and shared memory ------------------------------------------------------------------------------------- Robert Watson (rwatson) committed changes from Dandekar Hrishikesh to add support for the MAC[1] framework to System V message queues, semaphores and shared memory. This will allow the regular mandatory access control implementation to restrict access to these SysV features. This code was obtained from the TrustedBSD project, and sponsored by DARPA, SPAWAR, and McAfee Research. [1] http://www.freebsd.org/cgi/man.cgi?query=mac&apropos=0&sektion=3&manpath=FreeBSD+6.0-current&format=html Submitted by: Dandekar Hrishikesh http://www.freebsd.org/cgi/mid.cgi?200501221851.j0MIphhC083805 http://www.freebsd.org/cgi/mid.cgi?200501221904.j0MJ4Hcd084188 http://www.freebsd.org/cgi/mid.cgi?200501221910.j0MJAPrM084462 Significant multi-processor filesystem work done ------------------------------------------------ Jeff Roberson (jeff) made many commits to work towards making the virtual filesystem code MPSAFE (Safe for use without the Giant system lock with multiple processors). He also added locking to the default UFS filesystem. This work was sponsored by Isilon Systems, Inc. =============== Notable Changes =============== Major man page sweep -------------------- Ruslan Ermilov (ru) did a major sweep of the system manual pages, rearranging the sections to make them all consistent. =============== Other Bug Fixes =============== Shunsuke Akiyama (akiyama) committed a fix from Rudolf Cejka for a bug in the USB serial support. The bug caused USB serial devices to stop working when the tcflush function was used, making it impossible to do remote debugging over one. Submitted by: Rudolf Cejka PR: 65769 (http://www.freebsd.org/cgi/query-pr.cgi?pr=65769) http://www.freebsd.org/cgi/mid.cgi?200501191518.j0JFI0K3059405 Alan Cox (alc) committed a patch submitted by Mark W. Krentel to prevent a panic if a program makes an invalid request to the /dev/kmem kernel memory access device. This could only be done by root or by a setgid program in the kmem group. Submitted by: Mark W. Krentel Reported by: kris http://www.freebsd.org/cgi/mid.cgi?200501221921.j0MJLTta085275 From owner-freebsd-current@FreeBSD.ORG Sun Jan 30 20:56:50 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 508) id C370416A4CF; Sun, 30 Jan 2005 20:56:50 +0000 (GMT) To: current@FreeBSD.org, julian@FreeBSD.org In-Reply-To: <200501300442.j0U4gbWT077189@freefall.freebsd.org> Message-Id: <20050130205650.C370416A4CF@hub.freebsd.org> Date: Sun, 30 Jan 2005 20:56:50 +0000 (GMT) From: julian@FreeBSD.ORG (Julian Elischer) cc: x11@freebsd.org Subject: Inspiron 7500 vs x.org server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jan 2005 20:56:50 -0000 Adding more to this.. x.org has this as bug 1109 It was erroneously linked as a duplicate of 1881 which has been fixed, however that was a bug in the radeon driver and this is the ati driver. If anyone knows what the Linux "vga=793" or (whatever it is) kernel option does and whether there is somethign equivalent for freeBSD that would be interesting. > Ok, so hearing good things about the x.org server > and having seen it work elsewhere, I upgraded my laptop > from XFree86 to x.org today.. > all went fine.. > Except running it I just get a black screen. > no errors.. The Server thinks it's doing just fine.. > > ok, so I go to my wife's ibook and surf around a bit and discover > that this is known.. Dell Inspiron 7500 and x.org > have this problem. > > There is talk of a workaround in linux.. setting a kernel argument to > vga=753 or someothing similar, and there is one posting that talks about > a similar workaround for FreeBSD existing, but I have not been > able to find the workaround itself. Apparently this has been solved > somewhere as well, but I can't find any specific reference to what the fix > is/was. > > If anyone has a hint as to what the problem is (apparently some IBM > laptops have the same problem (they use the same Rage mobility-M chip). > > Looking forward to having X again... > > If anyone has a dell 7500 working with x,org, I'd love to get a copy > of your ati driver or a description of how you solved it.. > > T.I.A. > > Julian > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Sun Jan 30 20:59:25 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5DA8316A4CF; Sun, 30 Jan 2005 20:59:25 +0000 (GMT) Received: from makeworld.com (makeworld.com [198.92.228.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id BF9FB43D2F; Sun, 30 Jan 2005 20:59:24 +0000 (GMT) (envelope-from racerx@makeworld.com) Received: from localhost (localhost.com [127.0.0.1]) by makeworld.com (Postfix) with ESMTP id 242AC6128; Sun, 30 Jan 2005 14:59:24 -0600 (CST) Received: from makeworld.com ([127.0.0.1]) by localhost (makeworld.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 85206-08; Sun, 30 Jan 2005 14:59:21 -0600 (CST) Received: from [198.92.228.34] (racerx.makeworld.com [198.92.228.34]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by makeworld.com (Postfix) with ESMTP id 62F4F6110; Sun, 30 Jan 2005 14:59:21 -0600 (CST) Message-ID: <41FD4AED.6080200@makeworld.com> Date: Sun, 30 Jan 2005 15:00:29 -0600 From: Chris User-Agent: Mozilla Thunderbird 1.0 (X11/20050101) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julian Elischer References: <20050130205650.C370416A4CF@hub.freebsd.org> In-Reply-To: <20050130205650.C370416A4CF@hub.freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by ClamAV 0.75.1/amavisd-new-2.2.1 (20041222) at makeworld.com - Isn't it ironic cc: x11@freebsd.org cc: current@FreeBSD.org Subject: Re: Inspiron 7500 vs x.org server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jan 2005 20:59:25 -0000 Julian Elischer wrote: > Adding more to this.. x.org has this as bug 1109 > It was erroneously linked as a duplicate of 1881 which has > been fixed, however that was a bug in the radeon driver and this > is the ati driver. > > If anyone knows what the Linux "vga=793" or (whatever it is) > kernel option does and whether there is somethign equivalent for freeBSD > that would be interesting. > > > >>Ok, so hearing good things about the x.org server >>and having seen it work elsewhere, I upgraded my laptop >>from XFree86 to x.org today.. >>all went fine.. >>Except running it I just get a black screen. >>no errors.. The Server thinks it's doing just fine.. >> >>ok, so I go to my wife's ibook and surf around a bit and discover >>that this is known.. Dell Inspiron 7500 and x.org >>have this problem. >> >>There is talk of a workaround in linux.. setting a kernel argument to >>vga=753 or someothing similar, and there is one posting that talks about >>a similar workaround for FreeBSD existing, but I have not been >>able to find the workaround itself. Apparently this has been solved >>somewhere as well, but I can't find any specific reference to what the fix >>is/was. >> >>If anyone has a hint as to what the problem is (apparently some IBM >>laptops have the same problem (they use the same Rage mobility-M chip). >> >>Looking forward to having X again... >> >>If anyone has a dell 7500 working with x,org, I'd love to get a copy >>of your ati driver or a description of how you solved it.. >> >>T.I.A. >> >>Julian I never had an issue running Xorg with my 7500 *shrug* -- Best regards, Chris Real programmers drink too much coffee so that they will always seem tense and overworked. From owner-freebsd-current@FreeBSD.ORG Sun Jan 30 21:05:28 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 508) id 3AC6A16A4CF; Sun, 30 Jan 2005 21:05:28 +0000 (GMT) To: craig@xfoil.gank.org, freebsd-current@freebsd.org In-Reply-To: <200501292354.42410.craig@xfoil.gank.org> Message-Id: <20050130210528.3AC6A16A4CF@hub.freebsd.org> Date: Sun, 30 Jan 2005 21:05:28 +0000 (GMT) From: julian@FreeBSD.ORG (Julian Elischer) Subject: Re: painted myself into a corner.. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jan 2005 21:05:28 -0000 > On Saturday 29 January 2005 10:42 pm, Julian Elischer wrote: > > If anyone has a hint as to what the problem is (apparently some IBM > > laptops have the same problem (they use the same Rage mobility-M chip). > > Hmmm, ATI Rage... I don't know if it'll fix the problem or not, but have you > looked at the GATOS driver (http://gatos.sourceforge.net/)? > > The binaries work fine on FreeBSD and I always use it on my laptop in > order to get XVideo support. > Craig what kind of laptop do you have? what version of X is installed? As I don't have X at the moment it's not all that easy to go surf the site.. (hmm note to self.. load lynx next today) From owner-freebsd-current@FreeBSD.ORG Sun Jan 30 21:16:57 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4575F16A4CE for ; Sun, 30 Jan 2005 21:16:57 +0000 (GMT) Received: from bache.ece.cmu.edu (BACHE.ECE.CMU.EDU [128.2.129.23]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0611A43D1F for ; Sun, 30 Jan 2005 21:16:57 +0000 (GMT) (envelope-from allbery@ece.cmu.edu) Received: from [10.9.204.128] (dsl093-061-215.pit1.dsl.speakeasy.net [66.93.61.215]) by bache.ece.cmu.edu (Postfix) with ESMTP id 0734881 for ; Sun, 30 Jan 2005 16:16:55 -0500 (EST) From: "Brandon S. Allbery KF8NH" To: freebsd-current@freebsd.org Date: Sun, 30 Jan 2005 16:16:46 -0500 User-Agent: KMail/1.7.2 References: <20050130205650.C370416A4CF@hub.freebsd.org> In-Reply-To: <20050130205650.C370416A4CF@hub.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200501301616.47663.allbery@ece.cmu.edu> Subject: Re: Inspiron 7500 vs x.org server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jan 2005 21:16:57 -0000 On Sunday 20 Shvat 5765 15:56, Julian Elischer wrote: > If anyone knows what the Linux "vga=793" or (whatever it is) > kernel option does and whether there is somethign equivalent for freeBSD > that would be interesting. It's a VESA mode + 0x100, expressed in decimal. 793 = 0x319 = 1280x1024x15bit. If you can determine the actual video mode needed, it might be possible to use vidcontrol to set it before running the server. -- brandon s. allbery [linux,solaris,freebsd,perl] allbery@kf8nh.com system administrator [WAY too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon univ. KF8NH From owner-freebsd-current@FreeBSD.ORG Sun Jan 30 21:18:40 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 116DE16A4CE; Sun, 30 Jan 2005 21:18:40 +0000 (GMT) Received: from tensor.xs4all.nl (tensor.xs4all.nl [194.109.160.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id 91E0B43D46; Sun, 30 Jan 2005 21:18:39 +0000 (GMT) (envelope-from dimitry@andric.com) Received: from kilgore.dim (kilgore.dim [192.168.0.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.xs4all.nl (Postfix) with ESMTP id D31FF2284E; Sun, 30 Jan 2005 22:18:37 +0100 (CET) Date: Sun, 30 Jan 2005 22:18:28 +0100 From: Dimitry Andric X-Priority: 3 (Normal) Message-ID: <12249353.20050130221828@andric.com> To: julian@FreeBSD.ORG (Julian Elischer) In-Reply-To: <20050130205650.C370416A4CF@hub.freebsd.org> References: <200501300442.j0U4gbWT077189@freefall.freebsd.org> <20050130205650.C370416A4CF@hub.freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha1"; boundary="----------281D1D225476FA9" cc: x11@freebsd.org cc: current@FreeBSD.org Subject: Re: Inspiron 7500 vs x.org server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jan 2005 21:18:40 -0000 ------------281D1D225476FA9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit On 2005-01-30 at 21:56:50 Julian Elischer wrote: > If anyone knows what the Linux "vga=793" or (whatever it is) > kernel option does and whether there is somethign equivalent for freeBSD > that would be interesting. It sets VESA video mode 0x0219 (= 793-256 = 0x319-0x100), of which I'm unsure what it is on your system. :) You can probably set this through vesa.ko, but I'm not sure how, there seems to be no documentation... (vesa(4) is about the X.org vesa driver, afaics.) ------------281D1D225476FA9 Content-Type: application/pgp-signature -----BEGIN PGP MESSAGE----- Version: GnuPG v1.4.0 (MingW32) iD8DBQFB/U8ksF6jCi4glqMRAsjyAKDtWf4mt9tVL5onQ8mLgtJdQ+Qa6ACaAhif b2OWB/qdgJHQ8kYrikXsJMM= =KCHZ -----END PGP MESSAGE----- ------------281D1D225476FA9-- From owner-freebsd-current@FreeBSD.ORG Sun Jan 30 21:19:03 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 08A8716A4CE; Sun, 30 Jan 2005 21:19:03 +0000 (GMT) Received: from leguin.anholt.net (69-30-77-85.dq1sn.easystreet.com [69.30.77.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 71D6C43D48; Sun, 30 Jan 2005 21:19:02 +0000 (GMT) (envelope-from eta@lclark.edu) Received: from leguin.anholt.net (localhost [127.0.0.1]) by leguin.anholt.net (8.13.1/8.13.1) with ESMTP id j0ULJ26k001318; Sun, 30 Jan 2005 13:19:03 -0800 (PST) (envelope-from eta@lclark.edu) Received: (from anholt@localhost) by leguin.anholt.net (8.13.1/8.13.1/Submit) id j0ULJ2wd001317; Sun, 30 Jan 2005 13:19:02 -0800 (PST) (envelope-from eta@lclark.edu) X-Authentication-Warning: leguin.anholt.net: anholt set sender to eta@lclark.edu using -f From: Eric Anholt To: Julian Elischer In-Reply-To: <20050130205650.C370416A4CF@hub.freebsd.org> References: <20050130205650.C370416A4CF@hub.freebsd.org> Content-Type: multipart/mixed; boundary="=-hrD0wS1TBru356BqLxVW" Date: Sun, 30 Jan 2005 13:19:01 -0800 Message-Id: <1107119941.849.5.camel@leguin> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 FreeBSD GNOME Team Port cc: x11@freebsd.org cc: current@freebsd.org Subject: Re: Inspiron 7500 vs x.org server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jan 2005 21:19:03 -0000 --=-hrD0wS1TBru356BqLxVW Content-Type: text/plain Content-Transfer-Encoding: 7bit On Sun, 2005-01-30 at 20:56 +0000, Julian Elischer wrote: > Adding more to this.. x.org has this as bug 1109 > It was erroneously linked as a duplicate of 1881 which has > been fixed, however that was a bug in the radeon driver and this > is the ati driver. The ati driver is just a little wrapper that loads radeon, r128, or atimisc as appropriate. If you could verify that 1881's fix helps you, I'll dump it into the xorg-server port (or I might anyway whenever I commit to xorg-server next). A patch to xorg-server is attached. -- Eric Anholt eta@lclark.edu http://people.freebsd.org/~anholt/ anholt@FreeBSD.org --=-hrD0wS1TBru356BqLxVW Content-Disposition: attachment; filename=xorg-server-julian.diff Content-Type: text/x-patch; name=xorg-server-julian.diff; charset=ISO-8859-1 Content-Transfer-Encoding: base64 SW5kZXg6IGZpbGVzL3BhdGNoLXJhZGVvbl9kcml2ZXIuYw0KPT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KUkNTIGZpbGU6 IC9ob21lL25jdnMvcG9ydHMveDExLXNlcnZlcnMveG9yZy1zZXJ2ZXIvZmlsZXMvcGF0Y2gtcmFk ZW9uX2RyaXZlci5jLHYNCnJldHJpZXZpbmcgcmV2aXNpb24gMS4xDQpkaWZmIC11IC1yMS4xIHBh dGNoLXJhZGVvbl9kcml2ZXIuYw0KLS0tIGZpbGVzL3BhdGNoLXJhZGVvbl9kcml2ZXIuYwkxMyBK YW4gMjAwNSAyMjo1MjoyMyAtMDAwMAkxLjENCisrKyBmaWxlcy9wYXRjaC1yYWRlb25fZHJpdmVy LmMJMzAgSmFuIDIwMDUgMjE6MTc6MzMgLTAwMDANCkBAIC0xLDUgKzEsMTQgQEANCiAtLS0gcHJv Z3JhbXMvWHNlcnZlci9ody94ZnJlZTg2L2RyaXZlcnMvYXRpL3JhZGVvbl9kcml2ZXIuYy5vcmln CVR1ZSBBdWcgMjQgMTc6MzA6NDEgMjAwNA0KLSsrKyBwcm9ncmFtcy9Yc2VydmVyL2h3L3hmcmVl ODYvZHJpdmVycy9hdGkvcmFkZW9uX2RyaXZlci5jCVRodSBKYW4gMTMgMTQ6MzQ6MTcgMjAwNQ0K KysrKyBwcm9ncmFtcy9Yc2VydmVyL2h3L3hmcmVlODYvZHJpdmVycy9hdGkvcmFkZW9uX2RyaXZl ci5jCVN1biBKYW4gMzAgMTM6MTc6MTIgMjAwNQ0KK0BAIC0xMzExLDcgKzEzMTEsNyBAQA0KKyAJ aW5mby0+UGFuZWxZUmVzID0gKElOUkVHKFJBREVPTl9DUlRDX1ZfVE9UQUxfRElTUCk+PjE2KSAr IDE7DQorICAgICB9DQorICAgICBpZiAoZnBfaG9yel9zdHJldGNoICYgUkFERU9OX0hPUlpfU1RS RVRDSF9FTkFCTEUpIHsNCistCWluZm8tPlBhbmVsWFJlcyA9ICgoZnBfdmVydF9zdHJldGNoPj4x NikgKyAxKSAqIDg7DQorKwlpbmZvLT5QYW5lbFhSZXMgPSAoKGZwX2hvcnpfc3RyZXRjaD4+MTYp ICsgMSkgKiA4Ow0KKyAgICAgfSBlbHNlIHsNCisgCWluZm8tPlBhbmVsWFJlcyA9ICgoSU5SRUco UkFERU9OX0NSVENfSF9UT1RBTF9ESVNQKT4+MTYpICsgMSkgKiA4Ow0KKyAgICAgfQ0KIEBAIC00 NDcxLDEwICs0NDcxLDEyIEBADQogIA0KICAgICAgUkFERU9OU2F2ZShwU2Nybik7DQpJbmRleDog c2NyaXB0cy9jb25maWd1cmUNCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NClJDUyBmaWxlOiAvaG9tZS9uY3ZzL3BvcnRz L3gxMS1zZXJ2ZXJzL3hvcmctc2VydmVyL3NjcmlwdHMvY29uZmlndXJlLHYNCnJldHJpZXZpbmcg cmV2aXNpb24gMS42DQpkaWZmIC11IC1yMS42IGNvbmZpZ3VyZQ0KLS0tIHNjcmlwdHMvY29uZmln dXJlCTEzIEphbiAyMDA1IDIyOjUyOjI0IC0wMDAwCTEuNg0KKysrIHNjcmlwdHMvY29uZmlndXJl CTE3IEphbiAyMDA1IDAzOjQ3OjU3IC0wMDAwDQpAQCAtMjQsNyArMjQsNiBAQA0KIGVjaG8gIiNk ZWZpbmUgVXNlSW5zdGFsbGVkUHJvZ3JhbXMgWUVTIgkJPj4gJExPQ0FMREVGDQogZWNobyAiI2Rl ZmluZSBTdGFuZGFyZEluY2x1ZGVzIC1JJHtQUkVGSVh9L2luY2x1ZGUiID4+ICRMT0NBTERFRg0K IGVjaG8gIiNkZWZpbmUgQnVpbGRYRnJlZTg2Q29uZmlnVG9vbHMgWUVTIgk+PiAkTE9DQUxERUYN Ci1lY2hvICIjZGVmaW5lIEJ1aWxkWEZyZWU4NkNvbmZpZ1Rvb2xzIFlFUyIJPj4gJExPQ0FMREVG DQogZWNobyAiI2RlZmluZSBEcml2ZXJNYW5EaXIgXCQoTUFOU09VUkNFUEFUSCk0Igk+PiAkTE9D QUxERUYNCiBlY2hvICIjZGVmaW5lIERyaXZlck1hblN1ZmZpeCA0eCIJCT4+ICRMT0NBTERFRg0K IGVjaG8gIiNkZWZpbmUgTWlzY01hbkRpciBcJChNQU5TT1VSQ0VQQVRIKTciCT4+ICRMT0NBTERF Rg0K --=-hrD0wS1TBru356BqLxVW-- From owner-freebsd-current@FreeBSD.ORG Sun Jan 30 21:42:07 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A75A616A4CE for ; Sun, 30 Jan 2005 21:42:07 +0000 (GMT) Received: from smtp807.mail.ukl.yahoo.com (smtp807.mail.ukl.yahoo.com [217.12.12.197]) by mx1.FreeBSD.org (Postfix) with SMTP id CEF7D43D2D for ; Sun, 30 Jan 2005 21:42:06 +0000 (GMT) (envelope-from Thomas.Sparrevohn@btinternet.com) Received: from unknown (HELO w2fzz0vc01.aah-go-on.com) (thomas.sparrevohn@hg1.btinternet.com@81.129.52.171 with plain) by smtp807.mail.ukl.yahoo.com with SMTP; 30 Jan 2005 21:42:05 -0000 From: Thomas Sparrevohn To: freebsd-current@freebsd.org Date: Sun, 30 Jan 2005 21:41:44 +0000 User-Agent: KMail/1.7.2 References: <20050130205650.C370416A4CF@hub.freebsd.org> <1107119941.849.5.camel@leguin> In-Reply-To: <1107119941.849.5.camel@leguin> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200501302141.45312.Thomas.Sparrevohn@btinternet.com> Subject: Re: Inspiron 7500 vs x.org server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Thomas.Sparrevohn@btinternet.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, 30 Jan 2005 21:42:07 -0000 On Sunday 30 January 2005 21:19, Eric Anholt wrote: > On Sun, 2005-01-30 at 20:56 +0000, Julian Elischer wrote: > > Adding more to this.. x.org has this as bug 1109 > > It was erroneously linked as a duplicate of 1881 which has > > been fixed, however that was a bug in the radeon driver and this > > is the ati driver. > > The ati driver is just a little wrapper that loads radeon, r128, or > atimisc as appropriate. If you could verify that 1881's fix helps you, > I'll dump it into the xorg-server port (or I might anyway whenever I > commit to xorg-server next). A patch to xorg-server is attached. Maybe it will fx the same kind of problems on the C640 - It selects wierd resolutions as well From owner-freebsd-current@FreeBSD.ORG Sun Jan 30 22:12:47 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4370716A4CE for ; Sun, 30 Jan 2005 22:12:47 +0000 (GMT) Received: from webhost1.tasman.net (webhost1.tasman.net [202.49.92.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id C244E43D4C for ; Sun, 30 Jan 2005 22:12:46 +0000 (GMT) (envelope-from marcos@ThePacific.Net) Received: from [203.86.192.98] (helo=[172.16.20.10]) by webhost1.tasman.net with esmtpa (Exim 4.43 (FreeBSD)) id 1CvNJ7-0003we-0E for freebsd-current@freebsd.org; Mon, 31 Jan 2005 11:12:37 +1300 Message-ID: <41FE11FA.3060705@ThePacific.Net> Date: Mon, 31 Jan 2005 11:09:46 +0000 From: "Marcos Biscaysaqu - ThePacific.net" User-Agent: Mozilla Thunderbird 0.7.3 (X11/20040910) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus-Scanner: Clean mail though you should still use an Antivirus X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - webhost1.tasman.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [26 6] X-AntiAbuse: Sender Address Domain - ThePacific.Net X-Source: X-Source-Args: X-Source-Dir: Subject: Etherleak in ath0 and wi0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jan 2005 22:12:47 -0000 Hi there. Im testing my BSD box with nesus and looks like I have got a hole called "Etherleak" on my Atheros wirless card, seem to be like the card acept or transmint packages smaller than 64 bytes on icmp and could leak info, it is any opcion in the kernel to fix this, I could block icmp traffic but that is not a real solution. cheers Marcos Biscaysaqu Thepacific.net From owner-freebsd-current@FreeBSD.ORG Sun Jan 30 22:21:22 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 55A4C16A4CE; Sun, 30 Jan 2005 22:21:22 +0000 (GMT) Received: from ion.gank.org (ion.gank.org [69.55.238.164]) by mx1.FreeBSD.org (Postfix) with ESMTP id E850843D49; Sun, 30 Jan 2005 22:21:21 +0000 (GMT) (envelope-from craig@xfoil.gank.org) Received: by ion.gank.org (mail, from userid 1001) id B03C82D144; Sun, 30 Jan 2005 16:21:21 -0600 (CST) Date: Sun, 30 Jan 2005 16:21:21 -0600 From: Craig Boston To: Julian Elischer Message-ID: <20050130222121.GA36863@nowhere> References: <200501292354.42410.craig@xfoil.gank.org> <20050130210528.3AC6A16A4CF@hub.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050130210528.3AC6A16A4CF@hub.freebsd.org> User-Agent: Mutt/1.4.2.1i cc: current@freebsd.org Subject: Re: painted myself into a corner.. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jan 2005 22:21:22 -0000 On Sun, Jan 30, 2005 at 09:05:28PM +0000, Julian Elischer wrote: > what kind of laptop do you have? > what version of X is installer? It's an older model -- Compaq m700 (scourge of ACPI implementations everywhere ;) I'm running x.org 6.8.1 from ports. The video chip is: none2@pci1:0:0: class=0x030000 card=0xb1110e11 chip=0x4c4d1002 rev=0x64 hdr=0x00 vendor = 'ATI Technologies Inc.' device = '01541014 Rage P/M Mobility AGP 2x' class = display subclass = VGA > As I don't have X at the moment it's not all that easy to go surf the > site.. (hmm note to self.. load lynx next today) lol, isn't that the truth. I've found that elinks works fairly well also, especially for pages with frames and tables that lynx doesn't render well. Though, as I'm reading through the page this afternoon it looks like that driver may have already been merged into the main X.org tree between 6.7 and 6.8 :( Maybe that's what broke it on your Dell... Craig From owner-freebsd-current@FreeBSD.ORG Sun Jan 30 22:51:05 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 508) id 7330716A4CF; Sun, 30 Jan 2005 22:51:05 +0000 (GMT) To: eta@lclark.edu, julian@freebsd.org In-Reply-To: <1107119941.849.5.camel@leguin> Message-Id: <20050130225105.7330716A4CF@hub.freebsd.org> Date: Sun, 30 Jan 2005 22:51:05 +0000 (GMT) From: julian@FreeBSD.ORG (Julian Elischer) cc: x11@freebsd.org cc: current@freebsd.org Subject: Re: Inspiron 7500 vs x.org server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jan 2005 22:51:05 -0000 I tried the fix of changing vert to horz as mentionned in 1881 in the radeon driver but that didn't seem to fix anything. In particular I have the following code in radeon_driver.c now: static void RADEONGetPanelInfoFromReg (ScrnInfoPtr pScrn) { RADEONInfoPtr info = RADEONPTR(pScrn); unsigned char *RADEONMMIO = info->MMIO; CARD32 fp_vert_stretch = INREG(RADEON_FP_VERT_STRETCH); CARD32 fp_horz_stretch = INREG(RADEON_FP_HORZ_STRETCH); info->PanelPwrDly = 200; if (fp_vert_stretch & RADEON_VERT_STRETCH_ENABLE) { info->PanelYRes = (fp_vert_stretch>>12) + 1; } else { info->PanelYRes = (INREG(RADEON_CRTC_V_TOTAL_DISP)>>16) + 1; } if (fp_horz_stretch & RADEON_HORZ_STRETCH_ENABLE) { info->PanelXRes = ((fp_horz_stretch>>16) + 1) * 8; } else { info->PanelXRes = ((INREG(RADEON_CRTC_H_TOTAL_DISP)>>16) + 1) * 8; } if ((info->PanelXRes < 640) || (info->PanelYRes < 480)) { info->PanelXRes = 640; info->PanelYRes = 480; } xf86DrvMsg(pScrn->scrnIndex, X_WARNING, "Panel size %dx%d is derived, this may not be correct.\n" "If not, use PanelSize option to overwrite this setting\n", info->PanelXRes, info->PanelYRes); } Can you put that file somewhere I can download it? I don't have mime at teh moment.. I'm reading mail on hub.freebsd.org using 'mail' :-) (I edited the file by had and then cd'd to /usr/ports/x11-servers/xorg-servers and typed "make ; make install" it did a lot of stuff and installed it but the problem persists. > From eta@lclark.edu Sun Jan 30 21:19:03 2005 > Delivered-To: julian@freebsd.org > X-Authentication-Warning: leguin.anholt.net: anholt set sender to eta@lclark.edu using -f > Subject: Re: Inspiron 7500 vs x.org server > From: Eric Anholt > To: Julian Elischer > Cc: current@freebsd.org, x11@freebsd.org > In-Reply-To: <20050130205650.C370416A4CF@hub.freebsd.org> > References: <20050130205650.C370416A4CF@hub.freebsd.org> > Content-Type: multipart/mixed; boundary="=-hrD0wS1TBru356BqLxVW" > Date: Sun, 30 Jan 2005 13:19:01 -0800 > Mime-Version: 1.0 > X-Mailer: Evolution 2.0.2 FreeBSD GNOME Team Port > > > --=-hrD0wS1TBru356BqLxVW > Content-Type: text/plain > Content-Transfer-Encoding: 7bit > > On Sun, 2005-01-30 at 20:56 +0000, Julian Elischer wrote: > > Adding more to this.. x.org has this as bug 1109 > > It was erroneously linked as a duplicate of 1881 which has > > been fixed, however that was a bug in the radeon driver and this > > is the ati driver. > > The ati driver is just a little wrapper that loads radeon, r128, or > atimisc as appropriate. If you could verify that 1881's fix helps you, > I'll dump it into the xorg-server port (or I might anyway whenever I > commit to xorg-server next). A patch to xorg-server is attached. > > -- > Eric Anholt eta@lclark.edu > http://people.freebsd.org/~anholt/ anholt@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Sun Jan 30 22:53:12 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D6E0416A4CE; Sun, 30 Jan 2005 22:53:12 +0000 (GMT) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id AA78843D2D; Sun, 30 Jan 2005 22:53:12 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with SMTP id 3050246B0A; Sun, 30 Jan 2005 17:53:12 -0500 (EST) Date: Sun, 30 Jan 2005 22:52:34 +0000 (GMT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Mike Silbersack In-Reply-To: <20050130151427.U59844@odysseus.silby.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Poul-Henning Kamp cc: current@freebsd.org cc: Colin Percival Subject: Re: tcp_isn_tick() / dummynet() callout madness ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jan 2005 22:53:13 -0000 On Sun, 30 Jan 2005, Mike Silbersack wrote: > change to the callout API? Just a few places in the kernel account for > most of the use of callouts, so even if a rewrite of those would be > necessary, it should pay off. Well, part of the problem is that many callouts always re-register, and right now they're forced to pay a penalty for it. I almost wonder if we shouldn't add a new flag or method to swap the costs: register a recurring callout every (x) ticks, and you pay a cost to unregister it if the flag is set, and the callout is otherwise automatically rescheduled. Robert N M Watson From owner-freebsd-current@FreeBSD.ORG Mon Jan 31 00:37:27 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 673BB16A4CF; Mon, 31 Jan 2005 00:37:27 +0000 (GMT) Received: from digger1.defence.gov.au (digger1.defence.gov.au [203.5.217.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9E11443D2F; Mon, 31 Jan 2005 00:37:25 +0000 (GMT) (envelope-from wilkinsa@squash.dsto.defence.gov.au) Received: from ednmsw503.dsto.defence.gov.au (ednmsw503.dsto.defence.gov.au [131.185.2.150]) by digger1.defence.gov.au with ESMTP id j0V0aAhP024830; Mon, 31 Jan 2005 11:06:10 +1030 (CST) Received: from muttley.dsto.defence.gov.au (unverified) by ednmsw503.dsto.defence.gov.au (Content Technologies SMTPRS 4.3.10) with ESMTP id ; Mon, 31 Jan 2005 11:07:12 +1030 Received: from ednex501.dsto.defence.gov.au (ednex501.dsto.defence.gov.au [131.185.2.81]) by muttley.dsto.defence.gov.au (8.11.3/8.11.3) with ESMTP id j0V0VmQ09595; Mon, 31 Jan 2005 11:01:48 +1030 (CST) Received: from squash.dsto.defence.gov.au ([131.185.40.212]) by ednex501.dsto.defence.gov.au with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id YK387T05; Mon, 31 Jan 2005 11:01:07 +1030 Received: from squash.dsto.defence.gov.au (localhost [127.0.0.1]) by squash.dsto.defence.gov.au (8.12.11/8.12.11) with ESMTP id j0V0XTx5021441 ; Mon, 31 Jan 2005 11:03:29 +1030 (CST) (envelope-from wilkinsa@squash.dsto.defence.gov.au) Received: (from wilkinsa@localhost) by squash.dsto.defence.gov.au (8.12.11/8.12.11/Submit) id j0V0XTa2021440; Mon, 31 Jan 2005 11:03:29 +1030 (CST) (envelope-from wilkinsa) Date: Mon, 31 Jan 2005 11:03:29 +1030 From: "Wilkinson, Alex" To: Robert Watson Message-ID: <20050131003328.GA21227@squash.dsto.defence.gov.au> Mail-Followup-To: Robert Watson , "Wilkinson, Alex" , freebsd-current@FreeBSD.org, matthew.thyer@dsto.defence.gov.au References: <20050128043403.GA11316@squash.dsto.defence.gov.au> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i cc: matthew.thyer@dsto.defence.gov.au cc: freebsd-current@freebsd.org cc: "Wilkinson, Alex" Subject: Re: [RELENG_5 panic] top(1) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2005 00:37:27 -0000 0n Fri, Jan 28, 2005 at 10:02:18AM +0000, Robert Watson wrote: > >On Fri, 28 Jan 2005, Wilkinson, Alex wrote: > >> Fatal trap 12: page fault while in kernel mode >> fault virtual address = 0x24 >> fault code = supervisor read, page not present >> instruction pointer = 0x8:0xc05238d9 >> stack pointer = 0x10:0xe8745b2c >> frame pointer = 0x10:0xe8745b60 >> code segment = base 0x0, limit 0xfffff, type 0x1b >> = DPL 0, pres 1, def32 1, gran 1 >> processor eflags = resume, IOPL = 0 >> current process = 1575 (top) >> [thread pid 1575 tid 100176 ] >> Stopped at turnstile_wait+0x269: movl 0x24(%eax),%eax >> >> db> tr >> Tracing pid 1575 tid 100176 td 0xc32ef960 >> turnstile_wait(c2964640,c32ec77c,c32ef640,c2964640,c30e1a00) at >> turnstile_wait+0 >> x269 >> _mtx_lock_sleep(c32ec77c,c32ef960,0,0,0) at _mtx_lock_sleep+0x81 >> sysctl_kern_proc(c06d1860,0,0,e8745c04,e8745c04) at >> sysctl_kern_proc+0x3ab > >If you have a kernel with debugging symbols, could you convert >sysctl_kern_proc+0x3ab to a line number? Thanks! # kgdb kernel.debug /export/bad_kernels/20050128/vmcore.3 [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd". doadump () at pcpu.h:159 (kgdb) l *sysctl_kern_proc+0x3ab 0xc04f7963 is in sysctl_kern_proc (/usr/src/sys/kern/kern_proc.c:965). 960 if (p->p_state == PRS_NEW) { 961 mtx_unlock_spin(&sched_lock); 962 continue; 963 } 964 mtx_unlock_spin(&sched_lock); 965 PROC_LOCK(p); 966 /* 967 * Show a user only appropriate processes. 968 */ 969 if (p_cansee(curthread, p)) { (kgdb) From owner-freebsd-current@FreeBSD.ORG Mon Jan 31 01:35:58 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 508) id 40AB516A4CF; Mon, 31 Jan 2005 01:35:58 +0000 (GMT) To: allbery@ece.cmu.edu, freebsd-current@freebsd.org In-Reply-To: <200501301616.47663.allbery@ece.cmu.edu> Message-Id: <20050131013558.40AB516A4CF@hub.freebsd.org> Date: Mon, 31 Jan 2005 01:35:58 +0000 (GMT) From: julian@FreeBSD.ORG (Julian Elischer) Subject: Re: Inspiron 7500 vs x.org server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2005 01:35:58 -0000 > On Sunday 20 Shvat 5765 15:56, Julian Elischer wrote: > > If anyone knows what the Linux "vga=793" or (whatever it is) > > kernel option does and whether there is somethign equivalent for freeBSD > > that would be interesting. > It's a VESA mode + 0x100, expressed in decimal. 793 = 0x319 = > 1280x1024x15bit. > If you can determine the actual video mode needed, it might be possible to use > vidcontrol to set it before running the server. The actual mode is 792.. what is that? > -- > brandon s. allbery [linux,solaris,freebsd,perl] allbery@kf8nh.com > system administrator [WAY too many hats] allbery@ece.cmu.edu > electrical and computer engineering, carnegie mellon univ. KF8NH > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Mon Jan 31 01:40:41 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F20C516A4CE for ; Mon, 31 Jan 2005 01:40:40 +0000 (GMT) Received: from obsecurity.dyndns.org (CPE0050040655c8-CM00111ae02aac.cpe.net.cable.rogers.com [69.199.47.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6780643D31 for ; Mon, 31 Jan 2005 01:40:40 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 4F92A51456; Sun, 30 Jan 2005 17:40:39 -0800 (PST) Date: Sun, 30 Jan 2005 17:40:39 -0800 From: Kris Kennaway To: Jeff Roberson , current@freeBSD.org Message-ID: <20050131014039.GA94625@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qDbXVdCdHGoSgWSk" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: panic: vclean: cannot relock. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2005 01:40:41 -0000 --qDbXVdCdHGoSgWSk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline After updating with your fix from yesterday: panic: vclean: cannot relock. cpuid = 2 KDB: enter: panic [thread pid 48038 tid 100358 ] Stopped at kdb_enter+0x30: leave db> where Tracing pid 48038 tid 100358 td 0xcef90b80 kdb_enter(c06f4a48,2,c06fd644,ee547b14,cef90b80) at kdb_enter+0x30 panic(c06fd644,12,cef90b80,c06fd21d,904) at panic+0x13e vgonel(cc10ec30,cef90b80,c06fd21d,839,81b) at vgonel+0x1e4 vflush(c375cc00,1,2,cef90b80,0) at vflush+0x36d nullfs_unmount(c375cc00,8080000,cef90b80,cef90b80,c06ee579) at nullfs_unmount+0x36 dounmount(c375cc00,8080000,cef90b80,37b,218ffdb) at dounmount+0x2b7 unmount(cef90b80,ee547d14,c070fb7b,3ad,2) at unmount+0x271 syscall(2f,2f,2f,804a619,bfbfe74a) at syscall+0x271 Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (22, FreeBSD ELF32, unmount), eip = 0x280c5ad3, esp = 0xbfbfe4dc, ebp = 0xbfbfe598 --- db> show lockedvnods Locked vnodes (null) 0xcdb2e4e0: tag ufs, type VDIR usecount 6, writecount 0, refcount 2 mountedhere 0 flags () v_object 0xcde25bdc lock type ufs: EXCL (count 1) by thread 0xc3514b80 (pid 48047) ino 1130617, on dev da0s1e (235, 8) (null) 0xc3c03750: tag ufs, type VDIR usecount 0, writecount 0, refcount 1 mountedhere 0 flags () v_object 0 lock type ufs: EXCL (count 1) by thread 0xc3514b80 (pid 48047) ino 1083598, on dev da0s1e (235, 8) (null) 0xc9e27c30: tag ufs, type VDIR usecount 6, writecount 0, refcount 2 mountedhere 0 flags () v_object 0 lock type ufs: EXCL (count 1) by thread 0xc3cd5730 (pid 48044) ino 662978, on dev da0s1e (235, 8) (null) 0xccd20c30: tag ufs, type VNON usecount 1, writecount 0, refcount 0 mountedhere 0 flags () v_object 0 lock type ufs: EXCL (count 1) by thread 0xc3cd5730 (pid 48044) ino 768818, on dev da0s1e (235, 8) (null) 0xcd06f270: tag null, type VDIR usecount 1, writecount 0, refcount 0 mountedhere 0 flags (VV_ROOT) v_object 0 lock type ufs: EXCL (count 1) by thread 0xc3cd5730 (pid 48044) vp=0xcd06f270, lowervp=0xc9e27c30 (null) 0xcbc263a8: tag null, type VDIR usecount 1, writecount 0, refcount 0 mountedhere 0 flags (VV_ROOT) v_object 0 lock type ufs: EXCL (count 1) by thread 0xc3514b80 (pid 48047) vp=0xcbc263a8, lowervp=0xcdb2e4e0 (null) 0xcd306d68: tag null, type VDIR usecount 2, writecount 0, refcount 0 mountedhere 0 flags (VV_ROOT) v_object 0 lock type ufs: EXCL (count 1) by thread 0xc3cd5730 (pid 48044) vp=0xcd306d68, lowervp=0xc9e27c30 (null) 0xcc14ad68: tag null, type VDIR usecount 1, writecount 0, refcount 0 mountedhere 0 flags (VV_ROOT) v_object 0 lock type ufs: EXCL (count 1) by thread 0xc3514b80 (pid 48047) vp=0xcc14ad68, lowervp=0xcdb2e4e0 (null) 0xc45ca138: tag null, type VDIR usecount 1, writecount 0, refcount 0 mountedhere 0 flags (VV_ROOT) v_object 0 lock type ufs: EXCL (count 1) by thread 0xc3cd5730 (pid 48044) vp=0xc45ca138, lowervp=0xc9e27c30 (null) 0xcc10ec30: tag null, type VDIR usecount 2, writecount 0, refcount 0 mountedhere 0 flags (VV_ROOT|VI_XLOCK) v_object 0 lock type ufs: EXCL (count 1) by thread 0xc3514b80 (pid 48047) vp=0xcc10ec30, lowervp=0xcdb2e4e0 db> --qDbXVdCdHGoSgWSk Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFB/YyWWry0BWjoQKURAnKRAJ0YRBMzsYdmNq0UwfxYfKMjMDYynwCeOM51 RvMvCKFEsb1fdlnSjcmicQw= =kDB7 -----END PGP SIGNATURE----- --qDbXVdCdHGoSgWSk-- From owner-freebsd-current@FreeBSD.ORG Mon Jan 31 01:46:29 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 56ED116A4CE; Mon, 31 Jan 2005 01:46:29 +0000 (GMT) Received: from bache.ece.cmu.edu (BACHE.ECE.CMU.EDU [128.2.129.23]) by mx1.FreeBSD.org (Postfix) with ESMTP id 22BE743D1F; Mon, 31 Jan 2005 01:46:29 +0000 (GMT) (envelope-from allbery@ece.cmu.edu) Received: from [10.9.204.128] (dsl093-061-215.pit1.dsl.speakeasy.net [66.93.61.215]) by bache.ece.cmu.edu (Postfix) with ESMTP id 410E481; Sun, 30 Jan 2005 20:46:28 -0500 (EST) From: "Brandon S. Allbery KF8NH" To: freebsd-current@freebsd.org Date: Sun, 30 Jan 2005 20:46:25 -0500 User-Agent: KMail/1.7.2 References: <20050131013558.40AB516A4CF@hub.freebsd.org> In-Reply-To: <20050131013558.40AB516A4CF@hub.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200501302046.26724.allbery@ece.cmu.edu> Subject: Re: Inspiron 7500 vs x.org server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2005 01:46:29 -0000 On Sunday 20 Shvat 5765 20:35, Julian Elischer wrote: > > It's a VESA mode + 0x100, expressed in decimal. 793 = 0x319 = > > 1280x1024x15bit. > > > > If you can determine the actual video mode needed, it might be possible > > to use vidcontrol to set it before running the server. > > The actual mode is 792.. what is that? http://rampex.ihep.su/Linux/linux_howto/html/tutorials/mini/Vesafb-5.html (blame google; I'm sure there are closer links...) 792 is VESA 1024x768x24bit. -- brandon s. allbery [linux,solaris,freebsd,perl] allbery@kf8nh.com system administrator [WAY too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon univ. KF8NH From owner-freebsd-current@FreeBSD.ORG Mon Jan 31 01:50:02 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 508) id 0D3D116A4CF; Mon, 31 Jan 2005 01:50:02 +0000 (GMT) To: julian@FreeBSD.ORG, matthias.andree@gmx.de In-Reply-To: Message-Id: <20050131015002.0D3D116A4CF@hub.freebsd.org> Date: Mon, 31 Jan 2005 01:50:02 +0000 (GMT) From: julian@FreeBSD.ORG (Julian Elischer) cc: x11@freebsd.org cc: current@FreeBSD.org Subject: Re: Inspiron 7500 vs x.org server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2005 01:50:02 -0000 julian@FreeBSD.ORG (Julian Elischer) writes: > Adding more to this.. x.org has this as bug 1109 > It was erroneously linked as a duplicate of 1881 which has > been fixed, however that was a bug in the radeon driver and this > is the ati driver. > > If anyone knows what the Linux "vga=793" or (whatever it is) It sets a VESA graphic mode and tells the kernel to use the VESA frame buffer as a console; 793 is VESA mode 0x119 i. e. 1280x1024 in 32768 colors. Perhaps the driver doesn't know how to program proper graphic modes on your card and needs to use the BIOS. Similar nonsense as on Intel 830M and newer (up to and including 915G so far) -- Matthias Andree so if the mode is 792, is there a way to work around it? From owner-freebsd-current@FreeBSD.ORG Mon Jan 31 01:52:09 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CFF1216A4CE for ; Mon, 31 Jan 2005 01:52:09 +0000 (GMT) Received: from pimout3-ext.prodigy.net (pimout3-ext.prodigy.net [207.115.63.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0B70D43D49 for ; Mon, 31 Jan 2005 01:52:09 +0000 (GMT) (envelope-from julian@elischer.org) Received: from [192.168.1.102] (adsl-216-100-134-143.dsl.snfc21.pacbell.net [216.100.134.143])j0V1q5oC054602; Sun, 30 Jan 2005 20:52:07 -0500 Date: Sun, 30 Jan 2005 17:52:04 -0800 (PST) From: Julian Elischer X-X-Sender: julian@localhost To: "Brandon S. Allbery KF8NH" In-Reply-To: <200501302046.26724.allbery@ece.cmu.edu> Message-ID: <20050130175036.Q3903@localhost> References: <20050131013558.40AB516A4CF@hub.freebsd.org> <200501302046.26724.allbery@ece.cmu.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: freebsd-current@freebsd.org cc: x11@freebsd.org Subject: Re: Inspiron 7500 vs x.org server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2005 01:52:10 -0000 On Sun, 30 Jan 2005, Brandon S. Allbery KF8NH wrote: > On Sunday 20 Shvat 5765 20:35, Julian Elischer wrote: >>> It's a VESA mode + 0x100, expressed in decimal. 793 = 0x319 = >>> 1280x1024x15bit. >>> >>> If you can determine the actual video mode needed, it might be possible >>> to use vidcontrol to set it before running the server. >> >> The actual mode is 792.. what is that? > > http://rampex.ihep.su/Linux/linux_howto/html/tutorials/mini/Vesafb-5.html > (blame google; I'm sure there are closer links...) > > 792 is VESA 1024x768x24bit. > this is odd because the display is 1400 x 1050 From owner-freebsd-current@FreeBSD.ORG Mon Jan 31 06:34:50 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 98CC516A4CE; Mon, 31 Jan 2005 06:34:50 +0000 (GMT) Received: from critter.freebsd.dk (f170.freebsd.dk [212.242.86.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id C8B4B43D4C; Mon, 31 Jan 2005 06:34:49 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.1/8.13.1) with ESMTP id j0V6Ym3h084538; Mon, 31 Jan 2005 07:34:48 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Mike Silbersack From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sun, 30 Jan 2005 19:19:47 CST." <20050130191410.R62670@odysseus.silby.com> Date: Mon, 31 Jan 2005 07:34:48 +0100 Message-ID: <84537.1107153288@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: Robert Watson cc: current@FreeBSD.org cc: Colin Percival Subject: Re: tcp_isn_tick() / dummynet() callout madness ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2005 06:34:50 -0000 In message <20050130191410.R62670@odysseus.silby.com>, Mike Silbersack writes: One of the things I would like to see is for the callout api to gain a mutex pointer. If the pointer is not null, a mtx_trylock() is atempted, if it fails a taskq is used to execute this callout, otherwise the function is used as usual. -- 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 Mon Jan 31 06:49:48 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5AEBD16A4CE; Mon, 31 Jan 2005 06:49:48 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9B89743D1D; Mon, 31 Jan 2005 06:49:45 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.19] (ibook-nai.samsco.home [192.168.254.19]) (authenticated bits=0) by pooker.samsco.org (8.12.11/8.12.10) with ESMTP id j0V6rD4i031257; Sun, 30 Jan 2005 23:53:13 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <41FDD507.2040409@samsco.org> Date: Sun, 30 Jan 2005 23:49:43 -0700 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.5) Gecko/20041217 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Poul-Henning Kamp References: <84537.1107153288@critter.freebsd.dk> In-Reply-To: <84537.1107153288@critter.freebsd.dk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=3.8 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pooker.samsco.org cc: Mike Silbersack cc: Robert Watson cc: current@freebsd.org cc: Colin Percival Subject: Re: tcp_isn_tick() / dummynet() callout madness ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2005 06:49:48 -0000 Poul-Henning Kamp wrote: > In message <20050130191410.R62670@odysseus.silby.com>, Mike Silbersack writes: > > One of the things I would like to see is for the callout api to gain > a mutex pointer. > > If the pointer is not null, a mtx_trylock() is atempted, if it fails > a taskq is used to execute this callout, otherwise the function is used > as usual. > Taskqueues really are very non-deterministic and a poor choice for periodic events. They really are only suitable for events that are uncommon and don't require any sense whatsoever of urgency. While the callout API doesn't have any real-time guarantees, there is an assumption that assigned callouts will be generated with a reasonable amount of accuracy and consistency, and not be held up by a task that has an indefinite run time. Either a new dedicated kthread-based task needs to be created for what you propose, or the simplier approach can be taken of just deferring callouts that fail the trylock test to the end of the list. Scott From owner-freebsd-current@FreeBSD.ORG Mon Jan 31 07:01:00 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A9C0D16A4CE; Mon, 31 Jan 2005 07:01:00 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 261BD43D54; Mon, 31 Jan 2005 07:01:00 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.13.1/8.13.1) with ESMTP id j0V6xcXM082397; Sun, 30 Jan 2005 23:59:38 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Mon, 31 Jan 2005 00:01:15 -0700 (MST) Message-Id: <20050131.000115.04191271.imp@bsdimp.com> To: scottl@FreeBSD.org From: "M. Warner Losh" In-Reply-To: <20050130073248.W20417@pooker.samsco.org> References: <20050130130011.A9B0D7306E@freebsd-current.sentex.ca> <20050130073248.W20417@pooker.samsco.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: sparc64@FreeBSD.org cc: tinderbox@FreeBSD.org cc: current@FreeBSD.org Subject: Re: [current tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2005 07:01:00 -0000 In message: <20050130073248.W20417@pooker.samsco.org> Scott Long writes: : Why on earth is the digi driver bein compiled on sparc64? Most likely historical inertia... No body noticed until that module build got more facist. Warner From owner-freebsd-current@FreeBSD.ORG Mon Jan 31 07:56:46 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DB4B616A4CE; Mon, 31 Jan 2005 07:56:46 +0000 (GMT) Received: from critter.freebsd.dk (f170.freebsd.dk [212.242.86.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id 042D943D1F; Mon, 31 Jan 2005 07:56:46 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.1/8.13.1) with ESMTP id j0V7uiRR085972; Mon, 31 Jan 2005 08:56:44 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Mike Silbersack From: "Poul-Henning Kamp" In-Reply-To: Your message of "Mon, 31 Jan 2005 01:16:12 CST." <20050131011241.F64157@odysseus.silby.com> Date: Mon, 31 Jan 2005 08:56:44 +0100 Message-ID: <85971.1107158204@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: Robert Watson cc: current@FreeBSD.org cc: Colin Percival Subject: Re: tcp_isn_tick() / dummynet() callout madness ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2005 07:56:47 -0000 In message <20050131011241.F64157@odysseus.silby.com>, Mike Silbersack writes: >That sounds neat, but I'm not sure it's a good idea. In the case of tcp >timers, there are multiple locks that are relevant, if I'm not mistaken. >I also have this feeling that when mutex contention really matters, under >serious load, it wouldn't be a good idea to indefinitely delay some >callouts. It is a good idea, if nothing else because it prevents us from stalling softclock on a mutex we cannot get (for a long time). >I'd propose a simpler approach: Two callout wheels. A "fast" callout >wheel for short callouts (like tcp_isn_tick), and a "slow" callout wheel, >for things like tcp timers which we should handle quickly, but won't care >too much if they get delayed. That is a worse idea because it almost doubles the overhead. >Scott, in your reply to this you mention the importance of callouts firing >on time - do we have such important callouts? Thinking from a system >resource perspective, are there callouts that free memory, garbage >collect, etc? It would make sense to give those priority over less >critical timers which might block. Yes, timeout firing precision is important. -- 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 Mon Jan 31 07:57:29 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6523016A4CE; Mon, 31 Jan 2005 07:57:29 +0000 (GMT) Received: from critter.freebsd.dk (f170.freebsd.dk [212.242.86.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id B561743D4C; Mon, 31 Jan 2005 07:57:28 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.1/8.13.1) with ESMTP id j0V7vR3W085989; Mon, 31 Jan 2005 08:57:27 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Scott Long From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sun, 30 Jan 2005 23:49:43 MST." <41FDD507.2040409@samsco.org> Date: Mon, 31 Jan 2005 08:57:27 +0100 Message-ID: <85988.1107158247@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: Mike Silbersack cc: Robert Watson cc: current@freebsd.org cc: Colin Percival Subject: Re: tcp_isn_tick() / dummynet() callout madness ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2005 07:57:29 -0000 In message <41FDD507.2040409@samsco.org>, Scott Long writes: >Taskqueues really are very non-deterministic and a poor choice for >periodic events. They really are only suitable for events that are >uncommon and don't require any sense whatsoever of urgency. While the >callout API doesn't have any real-time guarantees, there is an >assumption that assigned callouts will be generated with a reasonable >amount of accuracy and consistency, and not be held up by a task that >has an indefinite run time. Either a new dedicated kthread-based task >needs to be created for what you propose, or the simplier approach can >be taken of just deferring callouts that fail the trylock test to the >end of the list. Either of those would work for me. -- 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 Mon Jan 31 09:37:40 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1F66D16A4CE; Mon, 31 Jan 2005 09:37:40 +0000 (GMT) Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by mx1.FreeBSD.org (Postfix) with SMTP id 9C17A43D1D; Mon, 31 Jan 2005 09:37:38 +0000 (GMT) (envelope-from dwmalone@maths.tcd.ie) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 31 Jan 2005 09:37:38 +0000 (GMT) Date: Mon, 31 Jan 2005 09:37:37 +0000 From: David Malone To: Poul-Henning Kamp Message-ID: <20050131093737.GA84934@walton.maths.tcd.ie> References: <20050130191410.R62670@odysseus.silby.com> <84537.1107153288@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <84537.1107153288@critter.freebsd.dk> User-Agent: Mutt/1.5.6i Sender: dwmalone@maths.tcd.ie cc: Mike Silbersack cc: Robert Watson cc: current@FreeBSD.org cc: Colin Percival Subject: Re: tcp_isn_tick() / dummynet() callout madness ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2005 09:37:40 -0000 On Mon, Jan 31, 2005 at 07:34:48AM +0100, Poul-Henning Kamp wrote: > One of the things I would like to see is for the callout api to gain > a mutex pointer. Is something like Ian's patches what you had in mind? http://lists.freebsd.org/pipermail/freebsd-arch/2004-November/003191.html David. From owner-freebsd-current@FreeBSD.ORG Mon Jan 31 10:12:18 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2BD6216A4CE; Mon, 31 Jan 2005 10:12:18 +0000 (GMT) Received: from vbook.fbsd.ru (asplinux.ru [195.133.213.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7FF3243D3F; Mon, 31 Jan 2005 10:12:17 +0000 (GMT) (envelope-from vova@vbook.fbsd.ru) Received: from vova by vbook.fbsd.ru with local (Exim 4.43 (FreeBSD)) id 1CvYXU-0000Jf-QE; Mon, 31 Jan 2005 13:12:12 +0300 From: Vladimir Grebenschikov To: Kris Kennaway In-Reply-To: <20050130025217.GA32612@xor.obsecurity.org> References: <20050130025217.GA32612@xor.obsecurity.org> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable Organization: SWsoft Date: Mon, 31 Jan 2005 13:12:12 +0300 Message-Id: <1107166332.1055.1.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 FreeBSD GNOME Team Port Sender: Vladimir Grebenschikov cc: alc@FreeBSD.org cc: "current@freebsd.org" Subject: Re: do_execve() finding vmspace_destroyed set under load X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: vova@fbsd.ru List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2005 10:12:18 -0000 =F7 =D3=C2, 29/01/2005 =D7 18:52 -0800, Kris Kennaway =D0=C9=DB=C5=D4:=20 > I'm seeing the following code in do_execve() frequently being > triggered when scripts are executed on my SMP machine under load: Probably related, I have 100% panic on exec of single linux static binary, it happens in do_execve sorry, no console here, just retype: Fatal trap 12: page fault in kernel mode current process =3D 1638 (tcsh) db> trace exec_map_first_page(...) at exec_map_first_page+0x32 do_execve(...) at do_execve+0x2df kern_execve(...) at kern_execve+0x124 execve(...)=20 ... (tcsh is parent process) No problems with other linux or native binaries. > if (imgp->vmspace_destroyed) { > /* sorry, no more process anymore. exit gracefully */ > #ifdef MAC > mac_execve_exit(imgp); > if (interplabel !=3D NULL) > mac_vnode_label_free(interplabel); > #endif > exit1(td, W_EXITCODE(0, SIGABRT)); > /* NOT REACHED */ > error =3D 0; > } >=20 > Needless to say, the scripts get pretty unhappy when they're summarily > aborted. What is the cause of this? >=20 > Kris --=20 Vladimir B. Grebenchikov vova@fbsd.ru From owner-freebsd-current@FreeBSD.ORG Mon Jan 31 10:21:52 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 905F816A4CE for ; Mon, 31 Jan 2005 10:21:52 +0000 (GMT) Received: from critter.freebsd.dk (f170.freebsd.dk [212.242.86.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id C666B43D39 for ; Mon, 31 Jan 2005 10:21:51 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.1/8.13.1) with ESMTP id j0VALoCe088176 for ; Mon, 31 Jan 2005 11:21:50 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: current@freebsd.org From: Poul-Henning Kamp Date: Mon, 31 Jan 2005 11:21:50 +0100 Message-ID: <88175.1107166910@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Subject: network performance, a low-level measurement X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2005 10:21:52 -0000 In case anybody can use this for anything: Setup: o Soekris NET4501 (133Mhz AMD Elan CPU) o -Current o stripped down kernel. o no SMP, no WITNESS, no DIAGNOSTIC o unshared interrupt line o if_sis driver modified to FAST intr which just schedules the existing sis_intr on taskqueue_fast o single-user mode o A back-to-back cable to another machine. o A single default sized ping packet Time [uSec] Where ----------------------------------------------------------------------- 000.000 HW-intr start 011.600 HW-intr stop 067.200 Enter sis_intr_task() 074.000 Enter sis_rxeof() 134.800 Enter ifp->if_input() 552.800 Enter sis_startl() 595.600 Exit sis_startl() 753.200 Return from ifp->if_input() 758.000 Exit sis_rxeof() 761.200 Enter sis_txeof() 796.400 Exit sis_txeof() 800.200 Exit sis_intr_task() ----------------------------------------------------------------------- Driver Other [uSec] [uSec] ------------------------------------------------------- HW-intr duration: 11.600 Taskqueue_fast Latency: 55.600 sis_rxeof() duration: 65.500 ifp->if_input() duration: 575.700 sis_startl() duration: 42.800 sis_txeof() duration: 35.200 sis_intr_task duration: 13.800 ------------------------------------------------------- Total 168.900 631.300 ======================================================= Summary: 21% of the time spent in the driver. -- 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 Mon Jan 31 10:22:43 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F19FB16A4CE; Mon, 31 Jan 2005 10:22:42 +0000 (GMT) Received: from critter.freebsd.dk (f170.freebsd.dk [212.242.86.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id 407F443D1F; Mon, 31 Jan 2005 10:22:42 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.1/8.13.1) with ESMTP id j0VAMe8O088233; Mon, 31 Jan 2005 11:22:40 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: vova@fbsd.ru From: "Poul-Henning Kamp" In-Reply-To: Your message of "Mon, 31 Jan 2005 13:12:12 +0300." <1107166332.1055.1.camel@localhost> Date: Mon, 31 Jan 2005 11:22:40 +0100 Message-ID: <88232.1107166960@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: alc@freebsd.org cc: "current@freebsd.org" cc: Kris Kennaway Subject: Re: do_execve() finding vmspace_destroyed set under load X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2005 10:22:43 -0000 In message <1107166332.1055.1.camel@localhost>, Vladimir Grebenschikov writes: >÷ ÓÂ, 29/01/2005 × 18:52 -0800, Kris Kennaway ÐÉÛÅÔ: >> I'm seeing the following code in do_execve() frequently being >> triggered when scripts are executed on my SMP machine under load: > >Probably related, I have 100% panic on exec of single linux static >binary, it happens in do_execve What kind of filesystem is the binary located ? -- 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 Mon Jan 31 10:59:33 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EDB1D16A4CE; Mon, 31 Jan 2005 10:59:33 +0000 (GMT) Received: from vbook.fbsd.ru (asplinux.ru [195.133.213.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 514A243D1D; Mon, 31 Jan 2005 10:59:33 +0000 (GMT) (envelope-from vova@vbook.fbsd.ru) Received: from vova by vbook.fbsd.ru with local (Exim 4.43 (FreeBSD)) id 1CvZHD-0000Ri-TD; Mon, 31 Jan 2005 13:59:27 +0300 From: Vladimir Grebenschikov To: Poul-Henning Kamp In-Reply-To: <88232.1107166960@critter.freebsd.dk> References: <88232.1107166960@critter.freebsd.dk> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable Organization: SWsoft Date: Mon, 31 Jan 2005 13:59:27 +0300 Message-Id: <1107169167.1651.3.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 FreeBSD GNOME Team Port Sender: Vladimir Grebenschikov cc: alc@freebsd.org cc: "current@freebsd.org" cc: Kris Kennaway Subject: Re: do_execve() finding vmspace_destroyed set under load X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: vova@fbsd.ru List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2005 10:59:34 -0000 =F7 =D0=CE, 31/01/2005 =D7 11:22 +0100, Poul-Henning Kamp =D0=C9=DB=C5=D4: > In message <1107166332.1055.1.camel@localhost>, Vladimir Grebenschikov wr= ites: > >=F7 =D3=C2, 29/01/2005 =D7 18:52 -0800, Kris Kennaway =D0=C9=DB=C5=D4:=20 > >> I'm seeing the following code in do_execve() frequently being > >> triggered when scripts are executed on my SMP machine under load: > > > >Probably related, I have 100% panic on exec of single linux static > >binary, it happens in do_execve >=20 > What kind of filesystem is the binary located ? msdosfs Should I try to copy binary to=20 Old kerel is ok -r-xr-xr-x 1 root wheel 3310239 Jan 17 11:53 /boot/kernel.old/kernel new kernel has this bug -r-xr-xr-x 1 root wheel 3334632 Jan 27 12:51 /boot/kernel/kernel --=20 Vladimir B. Grebenchikov vova@fbsd.ru From owner-freebsd-current@FreeBSD.ORG Mon Jan 31 11:34:44 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 68C3516A4CE for ; Mon, 31 Jan 2005 11:34:44 +0000 (GMT) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id E3C4143D31 for ; Mon, 31 Jan 2005 11:34:43 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with SMTP id 2E73446B06; Mon, 31 Jan 2005 06:34:43 -0500 (EST) Date: Mon, 31 Jan 2005 11:34:03 +0000 (GMT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Poul-Henning Kamp In-Reply-To: <88175.1107166910@critter.freebsd.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: current@freebsd.org Subject: Re: network performance, a low-level measurement X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2005 11:34:44 -0000 On Mon, 31 Jan 2005, Poul-Henning Kamp wrote: > In case anybody can use this for anything: Looks useful to me :-). > Setup: > o Soekris NET4501 (133Mhz AMD Elan CPU) > o -Current > o stripped down kernel. > o no SMP, no WITNESS, no DIAGNOSTIC What about INVARIANTS? That causes an extra mutex grab and release on each allocation and free, so INVARIANTS should be disabled in any performance-sensitive or timing-sensitive measurements. > o unshared interrupt line > o if_sis driver modified to FAST intr which just schedules > the existing sis_intr on taskqueue_fast > o single-user mode > o A back-to-back cable to another machine. > o A single default sized ping packet > > > Time [uSec] Where > ----------------------------------------------------------------------- > 000.000 HW-intr start > 011.600 HW-intr stop So this is the time window from the edge of the interrupt being raised, to it being lowered as a result of ACK'ing the hardware, or what exactly? Do you have any timing related to when the low level interrupt code enters, the fast handler starts running, when it stops running, and when the low level code returns (followed shortly by preemption)? > 067.200 Enter sis_intr_task() > 074.000 Enter sis_rxeof() > 134.800 Enter ifp->if_input() > 552.800 Enter sis_startl() Is net.isr.enable=1 or net.isr.enable=0? Why are we entering sis_start() here if net.isr.enable=0 and the system is otherwise idle? > 595.600 Exit sis_startl() > 753.200 Return from ifp->if_input() > 758.000 Exit sis_rxeof() > 761.200 Enter sis_txeof() > 796.400 Exit sis_txeof() > 800.200 Exit sis_intr_task() > ----------------------------------------------------------------------- > > > Driver Other > [uSec] [uSec] > ------------------------------------------------------- > HW-intr duration: 11.600 > Taskqueue_fast Latency: 55.600 > sis_rxeof() duration: 65.500 > ifp->if_input() duration: 575.700 > sis_startl() duration: 42.800 > sis_txeof() duration: 35.200 > sis_intr_task duration: 13.800 > ------------------------------------------------------- > Total 168.900 631.300 > ======================================================= > > Summary: 21% of the time spent in the driver. > > -- > 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. > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Mon Jan 31 11:48:52 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BEA2216A4CE for ; Mon, 31 Jan 2005 11:48:52 +0000 (GMT) Received: from imail4.gazeta.pl (imail4.gazeta.pl [193.42.231.135]) by mx1.FreeBSD.org (Postfix) with ESMTP id 96F4943D1F for ; Mon, 31 Jan 2005 11:48:51 +0000 (GMT) (envelope-from z.jaskiewicz@gazeta.pl) Received: from poczta.gazeta.pl (unverified [172.20.25.75]) by (imail4.gazeta.pl) with ESMTP id 15276791 for ; Mon, 31 Jan 2005 12:48:47 +0200 Received: from ew11 (unverified [172.20.26.241]) by av.gazeta.pl (av.gazeta.pl) with ESMTP id 2328968 for ; Mon, 31 Jan 2005 12:34:03 +0100 Message-ID: <1107172127668.ew11.z.jaskiewicz@gazeta.pl> Date: Mon, 31 Jan 2005 12:48:47 +0100 (CET) From: To: freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: 8bit X-mailer: (c)Agora mailer (v3.00) Organization: Portal Agory S.A. X-IP: 62.29.133.84, olsztyn2.ols.vectranet.pl X-Complaints-To: abuse@gazeta.pl X-URL: http://www.gazeta.pl Subject: searching Host Controller X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2005 11:48:52 -0000 I need Intel 82821DB/DBM USB2 Enhanced Host Controller. Please help me z.jaskiewicz@gazeta.pl From owner-freebsd-current@FreeBSD.ORG Mon Jan 31 12:01:23 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 65A6616A4CE for ; Mon, 31 Jan 2005 12:01:23 +0000 (GMT) Received: from hetzner.co.za (lfw.hetzner.co.za [196.7.18.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 97B5E43D2F for ; Mon, 31 Jan 2005 12:01:22 +0000 (GMT) (envelope-from ianf@hetzner.co.za) Received: from localhost ([127.0.0.1]) by hetzner.co.za with esmtp (Exim 3.36 #1) id 1CvaF6-000CXI-00 for current@freebsd.org; Mon, 31 Jan 2005 14:01:20 +0200 To: current@freebsd.org From: Ian FREISLICH X-Attribution: BOFH Date: Mon, 31 Jan 2005 14:01:20 +0200 Sender: ianf@hetzner.co.za Message-Id: Subject: sys/1386/i386/mptable.c rev 1.239 breaks boot. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2005 12:01:23 -0000 Hi I have a dual pII machine that doesn't boot with 1.239 of sys/1386/i386/mptable.c. It boots with this patch backed out. Does anyone have any ideas beyond backing out this patch? revision 1.239 date: 2005/01/18 20:27:24; author: jhb; state: Exp; lines: +7 -1 If a valid ELCR was found, consult it for the trigger mode of ISA interrupts that have a trigger mode of conforming. This fixes problems on some older machines that still route PCI devices via ISA interrupts when using an I/O APIC. This seems to be a case of breaking, rather than fixing older machines. It's highly reproduceable. I mailed the author of this commit over a week ago, but have not had a response yet :(. This is definitely a show-stopper, for me at least. Ian -- Ian Freislich From owner-freebsd-current@FreeBSD.ORG Mon Jan 31 12:03:57 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4A1DF16A4CE for ; Mon, 31 Jan 2005 12:03:57 +0000 (GMT) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 02B0F43D1D for ; Mon, 31 Jan 2005 12:03:57 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with SMTP id 6978F46B3D; Mon, 31 Jan 2005 07:03:56 -0500 (EST) Date: Mon, 31 Jan 2005 12:03:17 +0000 (GMT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Ian FREISLICH In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: current@freebsd.org Subject: Re: sys/1386/i386/mptable.c rev 1.239 breaks boot. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2005 12:03:57 -0000 On Mon, 31 Jan 2005, Ian FREISLICH wrote: > This seems to be a case of breaking, rather than fixing older machines. > It's highly reproduceable. I mailed the author of this commit over a > week ago, but have not had a response yet :(. This is definitely a > show-stopper, for me at least. No useful technical information to add here, but John has been having a DNS/mail outage for the last week, so may not yet have received your e-mail. I believe his DNS is back online again, so hopefully he'll be catching up on e-mail again this week. Robert N M Watson From owner-freebsd-current@FreeBSD.ORG Mon Jan 31 12:35:17 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 929A216A4CE; Mon, 31 Jan 2005 12:35:17 +0000 (GMT) Received: from critter.freebsd.dk (f170.freebsd.dk [212.242.86.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id B35BE43D31; Mon, 31 Jan 2005 12:35:16 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.1/8.13.1) with ESMTP id j0VCZFM9090359; Mon, 31 Jan 2005 13:35:15 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Robert Watson From: "Poul-Henning Kamp" In-Reply-To: Your message of "Mon, 31 Jan 2005 11:34:03 GMT." Date: Mon, 31 Jan 2005 13:35:15 +0100 Message-ID: <90358.1107174915@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: current@FreeBSD.org Subject: Re: network performance, a low-level measurement X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2005 12:35:17 -0000 In message , Robert Watson writes: >What about INVARIANTS? That causes an extra mutex grab and release on >each allocation and free, so INVARIANTS should be disabled in any >performance-sensitive or timing-sensitive measurements. new test starting in a moment. >> o unshared interrupt line >> o if_sis driver modified to FAST intr which just schedules >> the existing sis_intr on taskqueue_fast >> o single-user mode >> o A back-to-back cable to another machine. >> o A single default sized ping packet >> >> >> Time [uSec] Where >> ----------------------------------------------------------------------- >> 000.000 HW-intr start >> 011.600 HW-intr stop > >So this is the time window from the edge of the interrupt being raised, to >it being lowered as a result of ACK'ing the hardware, or what exactly? yes, this is the measured width of the signal on the physical interrupt wire running from the chip. >it being lowered as a result of ACK'ing the hardware, or what exactly? Do >you have any timing related to when the low level interrupt code enters, >the fast handler starts running, when it stops running, and when the low >level code returns (followed shortly by preemption)? Hmm, I can do that I think. >> 067.200 Enter sis_intr_task() >> 074.000 Enter sis_rxeof() >> 134.800 Enter ifp->if_input() >> 552.800 Enter sis_startl() > >Is net.isr.enable=1 or net.isr.enable=0? Whatever the default is. >Why are we entering sis_start() >here if net.isr.enable=0 and the system is otherwise idle? sis_start is called to return the ICMP ECHO reply packet obviously :-) -- 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 Sun Jan 30 21:15:42 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A102316A4CE; Sun, 30 Jan 2005 21:15:42 +0000 (GMT) Received: from mail.dt.e-technik.uni-dortmund.de (mail.dt.e-technik.Uni-Dortmund.DE [129.217.163.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id F155943D31; Sun, 30 Jan 2005 21:15:41 +0000 (GMT) (envelope-from matthias.andree@gmx.de) Received: from localhost (localhost [127.0.0.1])436EF44234; Sun, 30 Jan 2005 22:15:41 +0100 (CET) Received: from mail.dt.e-technik.uni-dortmund.de ([127.0.0.1]) by localhost (krusty [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 13371-03; Sun, 30 Jan 2005 22:15:40 +0100 (CET) Received: from m2a2.dyndns.org (p548544A4.dip.t-dialin.net [84.133.68.164]) 640D644232; Sun, 30 Jan 2005 22:15:40 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by merlin.emma.line.org (Postfix) with ESMTP id 94CE878D69; Sun, 30 Jan 2005 22:15:39 +0100 (CET) Received: from merlin.emma.line.org ([127.0.0.1]) by localhost (m2a2.dyndns.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 21225-05-2; Sun, 30 Jan 2005 22:15:38 +0100 (CET) Received: by merlin.emma.line.org (Postfix, from userid 500) id BC72C78D6A; Sun, 30 Jan 2005 22:15:38 +0100 (CET) From: Matthias Andree To: julian@FreeBSD.ORG (Julian Elischer) In-Reply-To: <20050130205650.C370416A4CF@hub.freebsd.org> (Julian Elischer's message of "Sun, 30 Jan 2005 20:56:50 +0000 (GMT)") References: <20050130205650.C370416A4CF@hub.freebsd.org> Date: Sun, 30 Jan 2005 22:15:38 +0100 Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: by amavisd-new at dt.e-technik.uni-dortmund.de X-Mailman-Approved-At: Mon, 31 Jan 2005 12:45:39 +0000 cc: x11@freebsd.org cc: current@FreeBSD.org Subject: Re: Inspiron 7500 vs x.org server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jan 2005 21:15:42 -0000 julian@FreeBSD.ORG (Julian Elischer) writes: > Adding more to this.. x.org has this as bug 1109 > It was erroneously linked as a duplicate of 1881 which has > been fixed, however that was a bug in the radeon driver and this > is the ati driver. > > If anyone knows what the Linux "vga=793" or (whatever it is) It sets a VESA graphic mode and tells the kernel to use the VESA frame buffer as a console; 793 is VESA mode 0x119 i. e. 1280x1024 in 32768 colors. Perhaps the driver doesn't know how to program proper graphic modes on your card and needs to use the BIOS. Similar nonsense as on Intel 830M and newer (up to and including 915G so far) -- Matthias Andree From owner-freebsd-current@FreeBSD.ORG Sun Jan 30 21:50:14 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 426FE16A4CE for ; Sun, 30 Jan 2005 21:50:14 +0000 (GMT) Received: from imo-m27.mx.aol.com (imo-m27.mx.aol.com [64.12.137.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id AA7DB43D2D for ; Sun, 30 Jan 2005 21:50:11 +0000 (GMT) (envelope-from Dazgreen5@aol.com) Received: from Dazgreen5@aol.com by imo-m27.mx.aol.com (mail_out_v37_r3.8.) id n.8d.1f937784 (3699) for ; Sun, 30 Jan 2005 16:50:04 -0500 (EST) From: Dazgreen5@aol.com Message-ID: <8d.1f937784.2f2eb08c@aol.com> Date: Sun, 30 Jan 2005 16:50:04 EST To: freebsd-current@freebsd.org MIME-Version: 1.0 X-Mailer: 9.0 SE for Windows sub 5003 X-Mailman-Approved-At: Mon, 31 Jan 2005 12:45:39 +0000 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: Silicon Image SiI 3112 Serial ATA controller support? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jan 2005 21:50:14 -0000 Hello, I wonder if you could help I have an asus a7n8x deluxe and have been trying to install windows onto a serial drive with no success it keeps asking for drives i down loaded them but still no joy would tou know any way i can do this. Regards darren From owner-freebsd-current@FreeBSD.ORG Mon Jan 31 11:39:20 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C66F816A4E6; Mon, 31 Jan 2005 11:39:19 +0000 (GMT) Received: from ni-mail2.dna.utvinternet.net (ni-mail2.dna.utvinternet.net [194.46.8.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8C1B843D54; Mon, 31 Jan 2005 11:39:18 +0000 (GMT) (envelope-from fergus@cobbled.net) Received: from eyore.cobbled.net (unverified [195.218.107.14]) by ni-mail2.dna.utvinternet.net ; Mon, 31 Jan 2005 11:39:15 +0000 Received: from eyore.public.cobbled.net (localhost [127.0.0.1]) by eyore.cobbled.net (8.12.10/8.12.10) with ESMTP id j0VBbGYC002007; Mon, 31 Jan 2005 11:37:16 GMT (envelope-from fergus@eyore.public.cobbled.net) Received: (from fergus@localhost)j0VBbFEE002006; Mon, 31 Jan 2005 11:37:15 GMT (envelope-from fergus) Date: Mon, 31 Jan 2005 11:37:15 +0000 From: fergus To: Julian Elischer Message-ID: <20050131113715.GA1827@eyore.cobbled.net> Mail-Followup-To: Julian Elischer , current@freebsd.org References: <200501300442.j0U4gbWT077189@freefall.freebsd.org> <20050130205650.C370416A4CF@hub.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050130205650.C370416A4CF@hub.freebsd.org> X-Mailman-Approved-At: Mon, 31 Jan 2005 12:45:39 +0000 cc: current@freebsd.org Subject: Re: Inspiron 7500 vs x.org server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2005 11:39:20 -0000 On 30.01-20:56, Julian Elischer wrote: [ ... ] > If anyone knows what the Linux "vga=793" or (whatever it is) > kernel option does and whether there is somethign equivalent for freeBSD > that would be interesting. i expect this is setting the framebuffer mode on the xserver and then using the framebuffer device in X - rather than the native X driver. you should try the framebuffer device or the VESA device. p.s: i'm afraid i've not had much success with framebuffers in BSD but vesa driver has worked for me a few times -- : fergus cameron : [ .] cobbled : : ^^^^^^@cobbled.net : [ ~][ ] .net : From owner-freebsd-current@FreeBSD.ORG Sun Jan 30 21:06:13 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 39ED116A4D1 for ; Sun, 30 Jan 2005 21:06:13 +0000 (GMT) Received: from relay02.pair.com (relay02.pair.com [209.68.5.16]) by mx1.FreeBSD.org (Postfix) with SMTP id 5FF4443D45 for ; Sun, 30 Jan 2005 21:06:12 +0000 (GMT) (envelope-from silby@silby.com) Received: (qmail 67487 invoked from network); 30 Jan 2005 21:06:11 -0000 Received: from unknown (HELO localhost) (unknown) by unknown with SMTP; 30 Jan 2005 21:06:11 -0000 X-pair-Authenticated: 209.68.2.70 Date: Sun, 30 Jan 2005 15:06:10 -0600 (CST) From: Mike Silbersack To: Robert Watson In-Reply-To: Message-ID: <20050130150328.K59844@odysseus.silby.com> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Mon, 31 Jan 2005 12:46:43 +0000 cc: Poul-Henning Kamp cc: current@freebsd.org cc: cperciva@FreeBSD.org Subject: Re: tcp_isn_tick() / dummynet() callout madness ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jan 2005 21:06:13 -0000 On Sun, 30 Jan 2005, Robert Watson wrote: > Note that the remainder run 1/100th as often, presumably because they do > hz/10 or hz/100 or the like. I've talked to both Colin Percival and Mike > Silby about the problem -- since the callout_reset() is one of the more > expensive parts of this code, Colin has been looking at some locking > optimizations to lower the cost. I attempted to convince Mike that if we > thought the ISN sequencing was "sufficiently secure" with HZ of 100, then > we should be able to still run it at hz/100 now instead of 1000 times per > second, but he seems resistant. I'll CC him so he's forced to reconsider > :-). You're right, reducing tcp_isn_tick to 100 hz won't really hurt anything. However, I'd still like an efficient way to run sometime once per tick. Is there a better place to hook in instead of callouts? Mike "Silby" Silbersack From owner-freebsd-current@FreeBSD.ORG Sun Jan 30 21:23:37 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 13C1516A4D0 for ; Sun, 30 Jan 2005 21:23:37 +0000 (GMT) Received: from relay02.pair.com (relay02.pair.com [209.68.5.16]) by mx1.FreeBSD.org (Postfix) with SMTP id 615A243D4C for ; Sun, 30 Jan 2005 21:23:36 +0000 (GMT) (envelope-from silby@silby.com) Received: (qmail 70142 invoked from network); 30 Jan 2005 21:23:35 -0000 Received: from unknown (HELO localhost) (unknown) by unknown with SMTP; 30 Jan 2005 21:23:35 -0000 X-pair-Authenticated: 209.68.2.70 Date: Sun, 30 Jan 2005 15:23:34 -0600 (CST) From: Mike Silbersack To: Colin Percival In-Reply-To: <41FD24C2.5070700@freebsd.org> Message-ID: <20050130151427.U59844@odysseus.silby.com> References: <41FD24C2.5070700@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Mon, 31 Jan 2005 12:46:43 +0000 cc: Poul-Henning Kamp cc: Robert Watson cc: current@freebsd.org Subject: Re: tcp_isn_tick() / dummynet() callout madness ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jan 2005 21:23:37 -0000 On Sun, 30 Jan 2005, Colin Percival wrote: > Robert Watson wrote: >> since the callout_reset() is one of the more >> expensive parts of this code, Colin has been looking at some locking >> optimizations to lower the cost. > > To elaborate somewhat: I think I can avoid the spinlock cost when > callouts reset themselves (which is the case here). However, while > this will reduce the time spent in the callouts themselves, it's > really only a 50% solution -- softclock locks and unlocks the callout > spin lock each time it launches a callout. If we're spending 5% of > our cpu time in these two callouts, then they're actually responsible > for using 10% of our cpu time; I think I can cut that in half, but in > the end we can't avoid the cost of a mtx_lock_spin / mtx_unlock_spin > pair (in softclock) for each callout. > > Colin Percival Is there any way to get around that cost with some relatively simple change to the callout API? Just a few places in the kernel account for most of the use of callouts, so even if a rewrite of those would be necessary, it should pay off. Or, potentially crazy idea here; instead of incurring the cost of a spinlock to remove a callout entry from a bucket, could you do some atomic operation to mark that entry as done, and then only remove those entries once and a while? I guess if spinlocks weren't so expensive, this wouldn't be a big deal... why do they need to be spinlocks? :) Mike "Silby" Silbersack From owner-freebsd-current@FreeBSD.ORG Mon Jan 31 01:19:50 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CFDD316A4CE for ; Mon, 31 Jan 2005 01:19:50 +0000 (GMT) Received: from relay01.pair.com (relay01.pair.com [209.68.5.15]) by mx1.FreeBSD.org (Postfix) with SMTP id 2BD6043D1F for ; Mon, 31 Jan 2005 01:19:50 +0000 (GMT) (envelope-from silby@silby.com) Received: (qmail 97851 invoked from network); 31 Jan 2005 01:19:48 -0000 Received: from unknown (HELO localhost) (unknown) by unknown with SMTP; 31 Jan 2005 01:19:48 -0000 X-pair-Authenticated: 209.68.2.70 Date: Sun, 30 Jan 2005 19:19:47 -0600 (CST) From: Mike Silbersack To: Robert Watson In-Reply-To: Message-ID: <20050130191410.R62670@odysseus.silby.com> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Mon, 31 Jan 2005 12:46:43 +0000 cc: Poul-Henning Kamp cc: current@freebsd.org cc: Colin Percival Subject: Re: tcp_isn_tick() / dummynet() callout madness ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2005 01:19:51 -0000 On Sun, 30 Jan 2005, Robert Watson wrote: > On Sun, 30 Jan 2005, Mike Silbersack wrote: > >> change to the callout API? Just a few places in the kernel account for >> most of the use of callouts, so even if a rewrite of those would be >> necessary, it should pay off. > > Well, part of the problem is that many callouts always re-register, and > right now they're forced to pay a penalty for it. I almost wonder if we > shouldn't add a new flag or method to swap the costs: register a recurring > callout every (x) ticks, and you pay a cost to unregister it if the flag > is set, and the callout is otherwise automatically rescheduled. > > Robert N M Watson That sounds worthwhile. For things like tcp_isn_tick, it'd be perfect. For the per-socket TCP timers, here's what I've been pondering for a while. Right now, we use seperate callouts for retransmit, 2msl, keepalive, delayed ack, etc. If we made the code just a little bit smarter (and that would be easy with some quick macros), we could bring each socket down to a single callout. That callout, whenever triggered, would look through the per-socket data and see which of the different timers was the one that just fired, and run it. Since the keepalive callout is almost never fired, but always rescheduled, that'd be a big win. This could be used with your auto-reschedule idea; perhaps the way auto-reschedule would work is that each callout has a next callout time set. So, suppose that we have a delayed ack timeout happening in 50ms, and a potential retransmit timeout happening in 4 seconds. We'd set the per-socket callout for 50ms, with a next time of 4 seconds. When the callout fires, it'll be rescheduled for 3.95 seconds from now, and if that's wrong, we'll just have to incur the cost of rescheduling it. But, in the case of the next time being correct, that would be much more efficient. Mike "Silby" Silbersack From owner-freebsd-current@FreeBSD.ORG Mon Jan 31 01:29:05 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 07C8D16A4CF for ; Mon, 31 Jan 2005 01:29:05 +0000 (GMT) Received: from relay02.pair.com (relay02.pair.com [209.68.5.16]) by mx1.FreeBSD.org (Postfix) with SMTP id 4A81C43D3F for ; Mon, 31 Jan 2005 01:29:04 +0000 (GMT) (envelope-from silby@silby.com) Received: (qmail 33005 invoked from network); 31 Jan 2005 01:29:02 -0000 Received: from unknown (HELO localhost) (unknown) by unknown with SMTP; 31 Jan 2005 01:29:02 -0000 X-pair-Authenticated: 209.68.2.70 Date: Sun, 30 Jan 2005 19:29:02 -0600 (CST) From: Mike Silbersack To: Robert Watson In-Reply-To: <20050130191410.R62670@odysseus.silby.com> Message-ID: <20050130192525.T62670@odysseus.silby.com> References: <20050130191410.R62670@odysseus.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Mon, 31 Jan 2005 12:46:43 +0000 cc: Poul-Henning Kamp cc: current@freebsd.org cc: Colin Percival Subject: Re: tcp_isn_tick() / dummynet() callout madness ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2005 01:29:05 -0000 On Sun, 30 Jan 2005, Mike Silbersack wrote: > This could be used with your auto-reschedule idea; perhaps the way > auto-reschedule would work is that each callout has a next callout time set. > So, suppose that we have a delayed ack timeout happening in 50ms, and a > potential retransmit timeout happening in 4 seconds. We'd set the per-socket > callout for 50ms, with a next time of 4 seconds. When the callout fires, > it'll be rescheduled for 3.95 seconds from now, and if that's wrong, we'll > just have to incur the cost of rescheduling it. Ok, thinking about it just a little more, the "next" field would have to be stored in the callout structure, and it would have to be unsychronized. We'd have to assume that it would ONLY be updated by a callout handler, which is why sychronization would be safe. Example: tcp_isn_tick_callout fires + tcp_isn_tick_callout rescheduled to fire at "next" time tcp_isn_tick routine is executed + tcp_isn_tick_callout.next is set for whatever time it should fire after the next firing Does that make sense? It allows for routines to schedule themselves on a fixed schedule or on a mildly variable schedule. If they guessed wrong on what "next" should be, then they'd just use callout_reset to change the scheduling, and incur the cost they do right now for every reschedule. Mike "Silby" Silbersack From owner-freebsd-current@FreeBSD.ORG Mon Jan 31 07:16:15 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 686DD16A4CF for ; Mon, 31 Jan 2005 07:16:15 +0000 (GMT) Received: from relay.pair.com (relay00.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 8F0BF43D46 for ; Mon, 31 Jan 2005 07:16:14 +0000 (GMT) (envelope-from silby@silby.com) Received: (qmail 23868 invoked from network); 31 Jan 2005 07:16:13 -0000 Received: from unknown (HELO localhost) (unknown) by unknown with SMTP; 31 Jan 2005 07:16:13 -0000 X-pair-Authenticated: 209.68.2.70 Date: Mon, 31 Jan 2005 01:16:12 -0600 (CST) From: Mike Silbersack To: Poul-Henning Kamp In-Reply-To: <84537.1107153288@critter.freebsd.dk> Message-ID: <20050131011241.F64157@odysseus.silby.com> References: <84537.1107153288@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Mon, 31 Jan 2005 12:46:43 +0000 cc: Robert Watson cc: current@FreeBSD.org cc: Colin Percival Subject: Re: tcp_isn_tick() / dummynet() callout madness ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2005 07:16:15 -0000 On Mon, 31 Jan 2005, Poul-Henning Kamp wrote: > In message <20050130191410.R62670@odysseus.silby.com>, Mike Silbersack writes: > > One of the things I would like to see is for the callout api to gain > a mutex pointer. > > If the pointer is not null, a mtx_trylock() is atempted, if it fails > a taskq is used to execute this callout, otherwise the function is used > as usual. > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 That sounds neat, but I'm not sure it's a good idea. In the case of tcp timers, there are multiple locks that are relevant, if I'm not mistaken. I also have this feeling that when mutex contention really matters, under serious load, it wouldn't be a good idea to indefinitely delay some callouts. I'd propose a simpler approach: Two callout wheels. A "fast" callout wheel for short callouts (like tcp_isn_tick), and a "slow" callout wheel, for things like tcp timers which we should handle quickly, but won't care too much if they get delayed. Scott, in your reply to this you mention the importance of callouts firing on time - do we have such important callouts? Thinking from a system resource perspective, are there callouts that free memory, garbage collect, etc? It would make sense to give those priority over less critical timers which might block. Mike "Silby" Silbersack From owner-freebsd-current@FreeBSD.ORG Mon Jan 31 13:02:32 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 81C2916A4CE; Mon, 31 Jan 2005 13:02:32 +0000 (GMT) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 039DA43D3F; Mon, 31 Jan 2005 13:02:32 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with SMTP id 4257A46B0F; Mon, 31 Jan 2005 08:02:31 -0500 (EST) Date: Mon, 31 Jan 2005 13:01:51 +0000 (GMT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Poul-Henning Kamp In-Reply-To: <90358.1107174915@critter.freebsd.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: scottl@FreeBSD.org cc: current@FreeBSD.org cc: jhb@FreeBSD.org Subject: Re: network performance, a low-level measurement X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2005 13:02:32 -0000 (The upshot is at the bottom, if you don't care about the diagnosis, skip to the last paragraph) On Mon, 31 Jan 2005, Poul-Henning Kamp wrote: > > >Why are we entering sis_start() > >here if net.isr.enable=0 and the system is otherwise idle? > > sis_start is called to return the ICMP ECHO reply packet obviously :-) On an unmodified system, here's the normal (approximate) series of events to get the ping processed: Low level interrupt handler fires Device driver ithread is scheduled Device driver ithread preempts Device driver ithread runs Device driver does inbound packet processing Device driver pulls packet out of hardware (so to speak) Device driver passes packet to link layer (ether_input) Link layer demuxes packet to netinet netisr q Link layer schedules netisr Link layer returns Device driver does outbound packet processing Device driver ithread finishes Context switch to netisr Netisr runs ip_input() ip_input() converts ICMP echo request to ICMP echo response ip_output() enqueues ICMP echo response to device driver ifnet queue ip_output() calls if_start if_start calls device driver start Device driver queues packet to harder Device driver starts hardware The primary difference between this sequence and your sequence, modulo s/ithread/taskqueue/ is that the if_start call happens before the task queue (ithread) finishes its run. This can happen in one of three cases: (1) you have net.isr.enable set to 1, so the link layer direct dispatches to the network layer, invoking ip_input() directly and resulting in the eventual call to if_start(), (2), you have an SMP system and the netisr runs on the second CPU in parallel and manages to send before the first processor has unwound, or (3) the netisr preempts the task queue due to having a lower priority as an ithread, causing it to run to completion before returning to the task queue thread to complete its run. Given that it's a Soekris, and hence not SMP, I'm assuming that (3) is the answer, since you're not using (1). So you're getting an extra two context switches in there as a result of what is effectively priority inversion, as the hardware driver is running at a priority that gives precedence to the netisr (ithread). This is probably undesirable, since net.isr.enable=1 is a much cheaper way to accomplish the same thing (avoiding the context switches, etc). Presumably the preemption occurs because SWI_TQ/SWI_TQ_FAST are greater than SWI_NET. Generally, we give hardware ithreads precedence over the netisr. Do we need a new SWI priority for task queue threads supporting device drivers -- i.e., acting in the role of an ithread? Robert N M Watson From owner-freebsd-current@FreeBSD.ORG Mon Jan 31 13:06:22 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9E73616A4CE; Mon, 31 Jan 2005 13:06:22 +0000 (GMT) Received: from mp2.macomnet.net (mp2.macomnet.net [195.128.64.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id A00CA43D49; Mon, 31 Jan 2005 13:06:21 +0000 (GMT) (envelope-from maxim@macomnet.ru) Received-SPF: pass (mp2.macomnet.net: domain of maxim@macomnet.ru designates 127.0.0.1 as permitted sender) receiver=mp2.macomnet.net; client_ip=127.0.0.1; envelope-from=maxim@macomnet.ru; Received: from localhost (localhost [127.0.0.1]) by mp2.macomnet.net (8.12.11/8.12.11) with ESMTP id j0VD6Kwe006909; Mon, 31 Jan 2005 16:06:20 +0300 (MSK) (envelope-from maxim@macomnet.ru) Date: Mon, 31 Jan 2005 16:06:20 +0300 (MSK) From: Maxim Konovalov To: Robert Watson In-Reply-To: Message-ID: <20050131160414.S6885@mp2.macomnet.net> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SpamTest-Info: Profile: Formal (206/050130) X-SpamTest-Info: Profile: Detect Hard (4/030526) X-SpamTest-Info: Profile: SysLog X-SpamTest-Info: Profile: Marking - Keywords (2/030321) X-SpamTest-Status: Not detected X-SpamTest-Version: SMTP-Filter Version 2.0.0 [0124], SpamtestISP/Release cc: current@freebsd.org Subject: Re: OpenBSD's tcpdrop(8) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2005 13:06:22 -0000 On Sun, 23 Jan 2005, 17:33-0000, Robert Watson wrote: > > On Sun, 23 Jan 2005, Maxim Konovalov wrote: > > > I've ported OpenBSD's tcpdrop(8) and a relevant kernel part. > > >From the man page, http://tinyurl.com/4lvo9 > > > > The tcpdrop command drops the TCP connection specified by the local > > address laddr, port lport and the foreign address faddr, port fport. > > > > There are patches for HEAD and RELENG_4: > > > > http://people.freebsd.org/~maxim/diff/tcpdrop.diff > > http://people.freebsd.org/~maxim/diff/tcpdrop.diff-4 > > > > Two questions: do we want to have it in the base system? Does the diff > > look OK (I didn't test IPv6 part)? > > The locking in the 6.x version looked reasonable, although you need to > check to see if the (tp) returned by tcp_drop() is NULL or not and then > conditionally unlock the inpcb if it's non-NULL -- otherwise you might > unlock a free'd inpcb. There doesn't seem to be much validation of the > tcp_ident_mapping structure, such as validation that the address lengths, > etc, are correct? I've updated the diff for HEAD. How does it look now? TIA! -- Maxim Konovalov From owner-freebsd-current@FreeBSD.ORG Mon Jan 31 13:14:46 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0A1AC16A4CE for ; Mon, 31 Jan 2005 13:14:46 +0000 (GMT) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id D76B643D3F for ; Mon, 31 Jan 2005 13:14:45 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with SMTP id 4B98B46B0A; Mon, 31 Jan 2005 08:14:45 -0500 (EST) Date: Mon, 31 Jan 2005 13:14:05 +0000 (GMT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Maxim Konovalov In-Reply-To: <20050131160414.S6885@mp2.macomnet.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: current@freebsd.org Subject: Re: OpenBSD's tcpdrop(8) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2005 13:14:46 -0000 On Mon, 31 Jan 2005, Maxim Konovalov wrote: > > The locking in the 6.x version looked reasonable, although you need to > > check to see if the (tp) returned by tcp_drop() is NULL or not and then > > conditionally unlock the inpcb if it's non-NULL -- otherwise you might > > unlock a free'd inpcb. There doesn't seem to be much validation of the > > tcp_ident_mapping structure, such as validation that the address lengths, > > etc, are correct? > > I've updated the diff for HEAD. How does it look now? TIA! The locking needs slightly more tweaking -- note that you still need to unlock (inp) if (tp = intotcpcb(inp)) returns NULL, and right now that won't happen. The "check tp for NULL" unlock case should only occur if you call tcp_drop(). Perhaps something like this: INP_LOCK(inp); if ((tp = intotcpcb(inp)) && ((inp->inp_socket->so_options & SO_ACCEPTCONN) == 0)) { tp = tcp_drop(tp, ECONNABORTED); if (tp != NULL) INP_UNLOCK(inp); } else INP_UNLOCK(inp); Robert N M Watson From owner-freebsd-current@FreeBSD.ORG Mon Jan 31 13:42:55 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F126E16A4CF; Mon, 31 Jan 2005 13:42:55 +0000 (GMT) Received: from mp2.macomnet.net (mp2.macomnet.net [195.128.64.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 25F5443D46; Mon, 31 Jan 2005 13:42:55 +0000 (GMT) (envelope-from maxim@macomnet.ru) Received-SPF: pass (mp2.macomnet.net: domain of maxim@macomnet.ru designates 127.0.0.1 as permitted sender) receiver=mp2.macomnet.net; client_ip=127.0.0.1; envelope-from=maxim@macomnet.ru; Received: from localhost (localhost [127.0.0.1]) by mp2.macomnet.net (8.12.11/8.12.11) with ESMTP id j0VDgopi007633; Mon, 31 Jan 2005 16:42:50 +0300 (MSK) (envelope-from maxim@macomnet.ru) Date: Mon, 31 Jan 2005 16:42:50 +0300 (MSK) From: Maxim Konovalov To: Robert Watson In-Reply-To: Message-ID: <20050131164220.H7162@mp2.macomnet.net> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SpamTest-Info: Profile: Formal (206/050130) X-SpamTest-Info: Profile: Detect Hard (4/030526) X-SpamTest-Info: Profile: SysLog X-SpamTest-Info: Profile: Marking - Keywords (2/030321) X-SpamTest-Status: Not detected X-SpamTest-Version: SMTP-Filter Version 2.0.0 [0124], SpamtestISP/Release cc: current@FreeBSD.org Subject: Re: OpenBSD's tcpdrop(8) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2005 13:42:56 -0000 On Mon, 31 Jan 2005, 13:14-0000, Robert Watson wrote: > > On Mon, 31 Jan 2005, Maxim Konovalov wrote: > > > > The locking in the 6.x version looked reasonable, although you need to > > > check to see if the (tp) returned by tcp_drop() is NULL or not and then > > > conditionally unlock the inpcb if it's non-NULL -- otherwise you might > > > unlock a free'd inpcb. There doesn't seem to be much validation of the > > > tcp_ident_mapping structure, such as validation that the address lengths, > > > etc, are correct? > > > > I've updated the diff for HEAD. How does it look now? TIA! > > The locking needs slightly more tweaking -- note that you still need to > unlock (inp) if (tp = intotcpcb(inp)) returns NULL, and right now that > won't happen. The "check tp for NULL" unlock case should only occur if > you call tcp_drop(). Perhaps something like this: > > INP_LOCK(inp); > if ((tp = intotcpcb(inp)) && > ((inp->inp_socket->so_options & SO_ACCEPTCONN) == 0)) { > tp = tcp_drop(tp, ECONNABORTED); > if (tp != NULL) > INP_UNLOCK(inp); > } else > INP_UNLOCK(inp); I see, updated. Thanks! -- Maxim Konovalov From owner-freebsd-current@FreeBSD.ORG Mon Jan 31 14:04:12 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6493216A4CF for ; Mon, 31 Jan 2005 14:04:12 +0000 (GMT) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 39E8643D58 for ; Mon, 31 Jan 2005 14:04:12 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with SMTP id 6517746B43 for ; Mon, 31 Jan 2005 09:04:11 -0500 (EST) Date: Mon, 31 Jan 2005 14:03:31 +0000 (GMT) From: Robert Watson X-Sender: robert@fledge.watson.org To: current@FreeBSD.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Jan 31 09:00:33 www ftpd[26164]: Internal: maskurg() while no transfer X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2005 14:04:12 -0000 Since updating to -CURRENT last night on a web server, I've seen several of the following messages: Jan 31 08:57:59 www ftpd[26164]: Internal: maskurg() while no transfer Jan 31 08:58:36 www last message repeated 7 times Jan 31 09:00:33 www ftpd[26164]: Internal: maskurg() while no transfer Does anyone own these? :-) Robert N M Watson From owner-freebsd-current@FreeBSD.ORG Mon Jan 31 14:07:27 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 11C5616A4CE; Mon, 31 Jan 2005 14:07:27 +0000 (GMT) Received: from mp2.macomnet.net (mp2.macomnet.net [195.128.64.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1AF6B43D2D; Mon, 31 Jan 2005 14:07:26 +0000 (GMT) (envelope-from maxim@macomnet.ru) Received-SPF: pass (mp2.macomnet.net: domain of maxim@macomnet.ru designates 127.0.0.1 as permitted sender) receiver=mp2.macomnet.net; client_ip=127.0.0.1; envelope-from=maxim@macomnet.ru; Received: from localhost (localhost [127.0.0.1]) by mp2.macomnet.net (8.12.11/8.12.11) with ESMTP id j0VE7OuL008233; Mon, 31 Jan 2005 17:07:24 +0300 (MSK) (envelope-from maxim@macomnet.ru) Date: Mon, 31 Jan 2005 17:07:24 +0300 (MSK) From: Maxim Konovalov To: Robert Watson In-Reply-To: Message-ID: <20050131170707.I8152@mp2.macomnet.net> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SpamTest-Info: Profile: Formal (206/050130) X-SpamTest-Info: Profile: Detect Hard (4/030526) X-SpamTest-Info: Profile: SysLog X-SpamTest-Info: Profile: Marking - Keywords (2/030321) X-SpamTest-Status: Not detected X-SpamTest-Version: SMTP-Filter Version 2.0.0 [0124], SpamtestISP/Release cc: current@freebsd.org Subject: Re: Jan 31 09:00:33 www ftpd[26164]: Internal: maskurg() while no transfer X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2005 14:07:27 -0000 On Mon, 31 Jan 2005, 14:03-0000, Robert Watson wrote: > > Since updating to -CURRENT last night on a web server, I've seen several > of the following messages: > > Jan 31 08:57:59 www ftpd[26164]: Internal: maskurg() while no transfer > Jan 31 08:58:36 www last message repeated 7 times > Jan 31 09:00:33 www ftpd[26164]: Internal: maskurg() while no transfer > > Does anyone own these? :-) rev. 1.202 ftpd.c -- Maxim Konovalov From owner-freebsd-current@FreeBSD.ORG Mon Jan 31 15:38:11 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1DD3416A4CE for ; Mon, 31 Jan 2005 15:38:11 +0000 (GMT) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id E536643D4C for ; Mon, 31 Jan 2005 15:38:10 +0000 (GMT) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) j0VFbuNj064987; Mon, 31 Jan 2005 07:37:56 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost)j0VFbuhf064986; Mon, 31 Jan 2005 07:37:56 -0800 (PST) (envelope-from sgk) Date: Mon, 31 Jan 2005 07:37:56 -0800 From: Steve Kargl To: Dazgreen5@aol.com Message-ID: <20050131153756.GA64943@troutmask.apl.washington.edu> References: <8d.1f937784.2f2eb08c@aol.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8d.1f937784.2f2eb08c@aol.com> User-Agent: Mutt/1.4.2.1i cc: freebsd-current@freebsd.org Subject: Re: Silicon Image SiI 3112 Serial ATA controller support? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2005 15:38:11 -0000 On Sun, Jan 30, 2005 at 04:50:04PM -0500, Dazgreen5@aol.com wrote: > Hello, > I wonder if you could help I have an asus a7n8x deluxe and have > been trying to install windows onto a serial drive with no success it keeps > asking for drives i down loaded them but still no joy would tou know any way i > can do this. > > Regards darren This is a mailing list for FreeBSD current. You can find numerous newsgroup dealing with windows. As to your controller, Soren has named the SiI 3112 as one of the worst pieces of silicon every made and advises people to dump it. -- Steve From owner-freebsd-current@FreeBSD.ORG Mon Jan 31 18:13:15 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9552B16A4CF for ; Mon, 31 Jan 2005 18:13:15 +0000 (GMT) Received: from mail.chesapeake.net (chesapeake.net [208.142.252.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0468B43D62 for ; Mon, 31 Jan 2005 18:13:15 +0000 (GMT) (envelope-from jroberson@chesapeake.net) Received: from mail.chesapeake.net (localhost [127.0.0.1]) by mail.chesapeake.net (8.12.10/8.12.10) with ESMTP id j0VIDC8v092995; Mon, 31 Jan 2005 13:13:12 -0500 (EST) (envelope-from jroberson@chesapeake.net) Received: from localhost (jroberson@localhost)j0VIDB3x092985; Mon, 31 Jan 2005 13:13:12 -0500 (EST) (envelope-from jroberson@chesapeake.net) X-Authentication-Warning: mail.chesapeake.net: jroberson owned process doing -bs Date: Mon, 31 Jan 2005 13:13:10 -0500 (EST) From: Jeff Roberson To: Kris Kennaway In-Reply-To: <20050131014039.GA94625@xor.obsecurity.org> Message-ID: <20050131130912.Y18864@mail.chesapeake.net> References: <20050131014039.GA94625@xor.obsecurity.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: current@freeBSD.org Subject: Re: panic: vclean: cannot relock. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2005 18:13:15 -0000 On Sun, 30 Jan 2005, Kris Kennaway wrote: > After updating with your fix from yesterday: > Are you running with smpvfs = 1 or 0? Can you enable KTR_LOCK in your kernel and give me KTR output if this reoccurs? Cheers, jeff > panic: vclean: cannot relock. > cpuid = 2 > KDB: enter: panic > [thread pid 48038 tid 100358 ] > Stopped at kdb_enter+0x30: leave > db> where > Tracing pid 48038 tid 100358 td 0xcef90b80 > kdb_enter(c06f4a48,2,c06fd644,ee547b14,cef90b80) at kdb_enter+0x30 > panic(c06fd644,12,cef90b80,c06fd21d,904) at panic+0x13e > vgonel(cc10ec30,cef90b80,c06fd21d,839,81b) at vgonel+0x1e4 > vflush(c375cc00,1,2,cef90b80,0) at vflush+0x36d > nullfs_unmount(c375cc00,8080000,cef90b80,cef90b80,c06ee579) at nullfs_unmount+0x36 > dounmount(c375cc00,8080000,cef90b80,37b,218ffdb) at dounmount+0x2b7 > unmount(cef90b80,ee547d14,c070fb7b,3ad,2) at unmount+0x271 > syscall(2f,2f,2f,804a619,bfbfe74a) at syscall+0x271 > Xint0x80_syscall() at Xint0x80_syscall+0x1f > --- syscall (22, FreeBSD ELF32, unmount), eip = 0x280c5ad3, esp = 0xbfbfe4dc, ebp = 0xbfbfe598 --- > db> show lockedvnods > Locked vnodes > (null) > 0xcdb2e4e0: tag ufs, type VDIR > usecount 6, writecount 0, refcount 2 mountedhere 0 > flags () > v_object 0xcde25bdc > lock type ufs: EXCL (count 1) by thread 0xc3514b80 (pid 48047) > ino 1130617, on dev da0s1e (235, 8) > (null) > 0xc3c03750: tag ufs, type VDIR > usecount 0, writecount 0, refcount 1 mountedhere 0 > flags () > v_object 0 > lock type ufs: EXCL (count 1) by thread 0xc3514b80 (pid 48047) > ino 1083598, on dev da0s1e (235, 8) > (null) > 0xc9e27c30: tag ufs, type VDIR > usecount 6, writecount 0, refcount 2 mountedhere 0 > flags () > v_object 0 > lock type ufs: EXCL (count 1) by thread 0xc3cd5730 (pid 48044) > ino 662978, on dev da0s1e (235, 8) > (null) > 0xccd20c30: tag ufs, type VNON > usecount 1, writecount 0, refcount 0 mountedhere 0 > flags () > v_object 0 > lock type ufs: EXCL (count 1) by thread 0xc3cd5730 (pid 48044) > ino 768818, on dev da0s1e (235, 8) > (null) > 0xcd06f270: tag null, type VDIR > usecount 1, writecount 0, refcount 0 mountedhere 0 > flags (VV_ROOT) > v_object 0 > lock type ufs: EXCL (count 1) by thread 0xc3cd5730 (pid 48044) > vp=0xcd06f270, lowervp=0xc9e27c30 > (null) > 0xcbc263a8: tag null, type VDIR > usecount 1, writecount 0, refcount 0 mountedhere 0 > flags (VV_ROOT) > v_object 0 > lock type ufs: EXCL (count 1) by thread 0xc3514b80 (pid 48047) > vp=0xcbc263a8, lowervp=0xcdb2e4e0 > (null) > 0xcd306d68: tag null, type VDIR > usecount 2, writecount 0, refcount 0 mountedhere 0 > flags (VV_ROOT) > v_object 0 > lock type ufs: EXCL (count 1) by thread 0xc3cd5730 (pid 48044) > vp=0xcd306d68, lowervp=0xc9e27c30 > (null) > 0xcc14ad68: tag null, type VDIR > usecount 1, writecount 0, refcount 0 mountedhere 0 > flags (VV_ROOT) > v_object 0 > lock type ufs: EXCL (count 1) by thread 0xc3514b80 (pid 48047) > vp=0xcc14ad68, lowervp=0xcdb2e4e0 > (null) > 0xc45ca138: tag null, type VDIR > usecount 1, writecount 0, refcount 0 mountedhere 0 > flags (VV_ROOT) > v_object 0 > lock type ufs: EXCL (count 1) by thread 0xc3cd5730 (pid 48044) > vp=0xc45ca138, lowervp=0xc9e27c30 > (null) > 0xcc10ec30: tag null, type VDIR > usecount 2, writecount 0, refcount 0 mountedhere 0 > flags (VV_ROOT|VI_XLOCK) > v_object 0 > lock type ufs: EXCL (count 1) by thread 0xc3514b80 (pid 48047) > vp=0xcc10ec30, lowervp=0xcdb2e4e0 > db> From owner-freebsd-current@FreeBSD.ORG Mon Jan 31 18:29:36 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EEC7616A4CE for ; Mon, 31 Jan 2005 18:29:36 +0000 (GMT) Received: from obsecurity.dyndns.org (CPE0050040655c8-CM00111ae02aac.cpe.net.cable.rogers.com [69.199.47.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id AC5E843D2F for ; Mon, 31 Jan 2005 18:29:36 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id B50E05145E; Mon, 31 Jan 2005 10:29:35 -0800 (PST) Date: Mon, 31 Jan 2005 10:29:35 -0800 From: Kris Kennaway To: Jeff Roberson Message-ID: <20050131182935.GA81326@xor.obsecurity.org> References: <20050131014039.GA94625@xor.obsecurity.org> <20050131130912.Y18864@mail.chesapeake.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="W/nzBZO5zC0uMSeA" Content-Disposition: inline In-Reply-To: <20050131130912.Y18864@mail.chesapeake.net> User-Agent: Mutt/1.4.2.1i cc: current@freeBSD.org cc: Kris Kennaway Subject: Re: panic: vclean: cannot relock. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2005 18:29:37 -0000 --W/nzBZO5zC0uMSeA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jan 31, 2005 at 01:13:10PM -0500, Jeff Roberson wrote: > On Sun, 30 Jan 2005, Kris Kennaway wrote: >=20 > > After updating with your fix from yesterday: > > >=20 > Are you running with smpvfs =3D 1 or 0? 1 > Can you enable KTR_LOCK in your kernel and give me KTR output if > this reoccurs? OK Kris --W/nzBZO5zC0uMSeA Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFB/nkPWry0BWjoQKURAp6aAKCDX2FJAKmDXoe7aRGauoaLhTiRigCfZW8i gLALnhqycHZn52MEHLuDIDo= =Jluo -----END PGP SIGNATURE----- --W/nzBZO5zC0uMSeA-- From owner-freebsd-current@FreeBSD.ORG Mon Jan 31 18:39:17 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B338816A4CF; Mon, 31 Jan 2005 18:39:17 +0000 (GMT) Received: from post.its.mcw.edu (post.its.mcw.edu [141.106.32.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id B723A43D60; Mon, 31 Jan 2005 18:39:15 +0000 (GMT) (envelope-from sidabraj@nsgcorp.net) Received: from [141.106.202.124] (net-202-124.dhcp.mcw.edu [141.106.202.124]) by post.its.mcw.edu (8.11.6+Sun/8.11.4) with ESMTP id j0VIdET17621; Mon, 31 Jan 2005 12:39:14 -0600 (CST) Message-ID: <41FE7A08.3060104@nsgcorp.net> Date: Mon, 31 Jan 2005 12:33:44 -0600 From: Jason Sidabras User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: current@freebsd.org, multimedia@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: PVR-350 TvOut X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2005 18:39:17 -0000 I would llike to first start off by thanking the developers of a great and (as of all FreeBSD drivers) easy to use and install driver for the PVR-350 for the record i am using the driver found here: http://www.freshports.org/multimedia/pvr250 with instructions: http://ivtv.writeme.ch/tiki-pagehistory.php?page=HowTo&diff=26 (seems down now) I have done some googling and searching of the mailing lists but I have fail to find any current (post early 2004) information of the state of the PVR-350 decoder and video out. Using ivtv (in linux) i used to send a frame buffer to the s-video and display off of that. This went through the decoder. So, my question is: Is there any howto's or perhaps patches in -CURRENT that would allow for the decoder and video out to work with my PVR-350? Once again thanks for all of the wonderful development. Video In works great! Jason From owner-freebsd-current@FreeBSD.ORG Mon Jan 31 19:09:30 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DB8F316A4CE for ; Mon, 31 Jan 2005 19:09:30 +0000 (GMT) Received: from ms005msg.fastwebnet.it (ms005msg.fastwebnet.it [213.140.2.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0508C43D41 for ; Mon, 31 Jan 2005 19:09:30 +0000 (GMT) (envelope-from filippo@portatile.fastwebnet.it) Received: from portatile (1.255.90.62) by ms005msg.fastwebnet.it (7.2.052.2) id 41FAA642000736C8 for freebsd-current@freebsd.org; Mon, 31 Jan 2005 20:09:28 +0100 Received: from portatile.fastwebnet.it (localhost [127.0.0.1]) by portatile (Postfix) with ESMTP id 076DFB839 for ; Mon, 31 Jan 2005 20:09:27 +0100 (CET) Received: (from filippo@localhost) by portatile.fastwebnet.it (8.13.1/8.13.1/Submit) id j0VJ9RpX002387 for freebsd-current@freebsd.org; Mon, 31 Jan 2005 20:09:27 +0100 (CET) (envelope-from filippo) Date: Mon, 31 Jan 2005 20:09:27 +0100 From: Filippo Forti To: freebsd-current@freebsd.org Message-ID: <20050131190927.GA2202@portatile.fastwebnet.it> References: <20050131013558.40AB516A4CF@hub.freebsd.org> <200501302046.26724.allbery@ece.cmu.edu> <20050130175036.Q3903@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050130175036.Q3903@localhost> User-Agent: Mutt/1.5.6i Subject: Re: Inspiron 7500 vs x.org server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: filippo.forti@fastwebnet.it List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2005 19:09:31 -0000 On Sun, Jan 30, 2005 at 05:52:04PM -0800, Julian Elischer wrote: > > > On Sun, 30 Jan 2005, Brandon S. Allbery KF8NH wrote: > > >On Sunday 20 Shvat 5765 20:35, Julian Elischer wrote: > >>>It's a VESA mode + 0x100, expressed in decimal. 793 = 0x319 = > >>>1280x1024x15bit. > >>> > >>>If you can determine the actual video mode needed, it might be possible > >>>to use vidcontrol to set it before running the server. > >> > >>The actual mode is 792.. what is that? > > > >http://rampex.ihep.su/Linux/linux_howto/html/tutorials/mini/Vesafb-5.html > >(blame google; I'm sure there are closer links...) > > > >792 is VESA 1024x768x24bit. > > > > this is odd because the display is 1400 x 1050 Video mode 1400 x 1050 should be supported 321 1400x1050x15 322 1400x1050x16 323 1400x1050x24 Filippo > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Mon Jan 31 20:04:02 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 76E5216A4CE for ; Mon, 31 Jan 2005 20:04:02 +0000 (GMT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 563DC43D49 for ; Mon, 31 Jan 2005 20:04:02 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id 4303972DD4; Mon, 31 Jan 2005 12:04:02 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id 3E33E72DCB; Mon, 31 Jan 2005 12:04:02 -0800 (PST) Date: Mon, 31 Jan 2005 12:04:02 -0800 (PST) From: Doug White To: Filippo Forti In-Reply-To: <20050130104239.GA50813@portatile.fastwebnet.it> Message-ID: <20050131120336.B8759@carver.gumbysoft.com> References: <20050130104239.GA50813@portatile.fastwebnet.it> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@freebsd.org Subject: Re: ACPI errors X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2005 20:04:02 -0000 On Sun, 30 Jan 2005, Filippo Forti wrote: > Hi, > I've started getting this error randomly since about 15 days ago. > I've cvsupped yesterday but the error still comes up sometimes. > The system is a Dell Inspiron 5100. This would be worthy to post to freebsd-acpi@freebsd.org. Do you regularly run with WITNESS on purpose? > > > Sleeping on "acsem" with the following non-sleepable > locks held: > exclusive sleep mutex acpica subsystem lock r = 0 (0xc235c9c0) locked @ > /usr/src/sys/modules/acpi/acpi/../../../dev/acpica/Osd/O > sdSynch.c:360 > KDB: stack backtrace: > kdb_backtrace(c09dbe14,e32beb84,1,1,1) at kdb_backtrace+0x2f > witness_warn(5,c235cb40,c08cb115,c0baf5ca,c065b845) at > witness_warn+0x1bb > msleep(c235cb40,c235cb40,100,c0baf5ca,0) at msleep+0x58 > AcpiOsWaitSemaphore(c235cb40,1,ffff,8,15) at AcpiOsWaitSemaphore+0x1fb > AcpiUtAcquireMutex(7,1,0,0,0) at AcpiUtAcquireMutex+0x8f > AcpiDisableGpe(0,1c,1,c227a7d1,c239f180) at AcpiDisableGpe+0x23 > EcGpeHandler(c239f180,1,0,8,102f) at EcGpeHandler+0x3f > AcpiEvGpeDispatch(c2380f50,1c,c227a7dd,27fa10,4) at > AcpiEvGpeDispatch+0xc4 > AcpiEvGpeDetect(c230bc20,0,c230bc20,e32bed14,c064f39e) at > AcpiEvGpeDetect+0x12f > AcpiEvSciXruptHandler(c230bc20,0,c08c8452,256,c0990c60) at > AcpiEvSciXruptHandler+0x2a > ithread_loop(c2279880,e32bed48,c08c8251,30e,c2279880) at > ithread_loop+0x157 > fork_exit(c064f247,c2279880,e32bed48) at fork_exit+0xc7 > fork_trampoline() at fork_trampoline+0x8 > --- trap 0x1, eip = 0, esp = 0xe32bed7c, ebp = 0 --- > > I'm running with a modified DSDT (downloaded from acpi.sf.net) which I used on > linux and FreeBSD since the beginning. > Is this normal/not dangerous? > > Thanks in advance > > Regards > Filippo > _______________________________________________ > 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" > -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Mon Jan 31 20:07:02 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E2B5A16A4CE; Mon, 31 Jan 2005 20:07:02 +0000 (GMT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id CB37043D45; Mon, 31 Jan 2005 20:07:02 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id B39CC72DD4; Mon, 31 Jan 2005 12:07:02 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id B1B8172DCB; Mon, 31 Jan 2005 12:07:02 -0800 (PST) Date: Mon, 31 Jan 2005 12:07:02 -0800 (PST) From: Doug White To: "M. Warner Losh" In-Reply-To: <20050131.000115.04191271.imp@bsdimp.com> Message-ID: <20050131120605.C8759@carver.gumbysoft.com> References: <20050130130011.A9B0D7306E@freebsd-current.sentex.ca> <20050131.000115.04191271.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: current@FreeBSD.org cc: scottl@FreeBSD.org cc: tinderbox@FreeBSD.org cc: sparc64@FreeBSD.org Subject: Re: [current tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2005 20:07:03 -0000 On Mon, 31 Jan 2005, M. Warner Losh wrote: > In message: <20050130073248.W20417@pooker.samsco.org> > Scott Long writes: > : Why on earth is the digi driver bein compiled on sparc64? > > Most likely historical inertia... No body noticed until that module > build got more facist. The digi driver in HEAD is completely inoperative anyway, so removing it from the kernel config wouldn't hurt anyone, for the time being. (There's a PR with a fixed driver I'm trying to find time to test...) -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Mon Jan 31 20:13:57 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5C27A16A4CE for ; Mon, 31 Jan 2005 20:13:57 +0000 (GMT) Received: from hex.databits.net (hex.databits.net [216.118.117.77]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2A2E743D3F for ; Mon, 31 Jan 2005 20:13:57 +0000 (GMT) (envelope-from will@csociety.org) Received: by hex.databits.net (Postfix, from userid 1001) id 8D81257AF4; Mon, 31 Jan 2005 14:13:56 -0600 (CST) Date: Mon, 31 Jan 2005 14:13:56 -0600 From: Will Andrews To: freebsd-current@freebsd.org Message-ID: <20050131201356.GK73953@hex.databits.net> Mail-Followup-To: freebsd-current@freebsd.org References: <8d.1f937784.2f2eb08c@aol.com> <20050131153756.GA64943@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="i57Ucs80xkCVE1Ce" Content-Disposition: inline In-Reply-To: <20050131153756.GA64943@troutmask.apl.washington.edu> User-Agent: Mutt/1.5.6i Subject: Re: Silicon Image SiI 3112 Serial ATA controller support? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2005 20:13:57 -0000 --i57Ucs80xkCVE1Ce Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jan 31, 2005 at 07:37:56AM -0800, Steve Kargl wrote: > This is a mailing list for FreeBSD current. You can find=20 > numerous newsgroup dealing with windows. As to your=20 > controller, Soren has named the SiI 3112 as one of the worst > pieces of silicon every made and advises people to dump it. Yeah. It's too bad Linux supports it fine, FreeBSD used to, and almost every board that comes with SATA uses it. :( Regards, --=20 wca --i57Ucs80xkCVE1Ce Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFB/pGEF47idPgWcsURAsmmAKCKjsB/egT0puisOwKzkHEsQopihACfZ79A qyhX9loEPkQPQQp5MXvQXTc= =Pj0j -----END PGP SIGNATURE----- --i57Ucs80xkCVE1Ce-- From owner-freebsd-current@FreeBSD.ORG Mon Jan 31 21:31:11 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 56EB216A4CE for ; Mon, 31 Jan 2005 21:31:11 +0000 (GMT) Received: from elrond.anembo.nu.org (dsl-202-173-130-73.nsw.westnet.com.au [202.173.130.73]) by mx1.FreeBSD.org (Postfix) with ESMTP id AAE5A43D4C for ; Mon, 31 Jan 2005 21:31:09 +0000 (GMT) (envelope-from freebsd@nu.org) Received: from elrond.anembo.nu.org (localhost [127.0.0.1]) by elrond.anembo.nu.org (8.13.1/8.13.1) with ESMTP id j0VLV7sD006462 for ; Tue, 1 Feb 2005 08:31:07 +1100 (EST) (envelope-from freebsd@nu.org) Received: (from cjsv@localhost) by elrond.anembo.nu.org (8.13.1/8.13.1/Submit) id j0VLV6Jt006461 for freebsd-current@freebsd.org; Tue, 1 Feb 2005 08:31:06 +1100 (EST) (envelope-from freebsd@nu.org) X-Authentication-Warning: elrond.anembo.nu.org: cjsv set sender to freebsd@nu.org using -f Date: Tue, 1 Feb 2005 08:31:06 +1100 From: Christopher JS Vance To: freebsd-current@freebsd.org Message-ID: <20050131213106.GD5834@nu.org> References: <8d.1f937784.2f2eb08c@aol.com> <20050131153756.GA64943@troutmask.apl.washington.edu> <20050131201356.GK73953@hex.databits.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20050131201356.GK73953@hex.databits.net> Subject: Re: Silicon Image SiI 3112 Serial ATA controller support? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2005 21:31:11 -0000 On Mon, Jan 31, 2005 at 02:13:56PM -0600, Will Andrews wrote: >On Mon, Jan 31, 2005 at 07:37:56AM -0800, Steve Kargl wrote: >> This is a mailing list for FreeBSD current. You can find >> numerous newsgroup dealing with windows. As to your >> controller, Soren has named the SiI 3112 as one of the worst >> pieces of silicon every made and advises people to dump it. > >Yeah. It's too bad Linux supports it fine, FreeBSD used to, and >almost every board that comes with SATA uses it. :( Using the same driver, the SiI 3512 couldn't stay up on my FreeBSD 5 machine long enough even to finish fsck'ing the previous crash - I had to change OS to a different *BSD, and even that falls over from time to time. -- Christopher Vance From owner-freebsd-current@FreeBSD.ORG Mon Jan 31 22:19:15 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AFAE216A595 for ; Mon, 31 Jan 2005 22:19:15 +0000 (GMT) Received: from smtp1.linkline.com (smtp1.linkline.com [66.59.235.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 686D043D2F for ; Mon, 31 Jan 2005 22:19:15 +0000 (GMT) (envelope-from sclements@linkline.com) Received: from [127.0.0.1] (host-66-59-225-129.lcinet.net [66.59.225.129]) by smtp1.linkline.com (Postfix) with ESMTP id 8C86B9CD76; Mon, 31 Jan 2005 14:19:12 -0800 (PST) Message-ID: <41FEAEE2.8080609@linkline.com> Date: Mon, 31 Jan 2005 14:19:14 -0800 From: Samuel Clements User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Will Andrews References: <8d.1f937784.2f2eb08c@aol.com> <20050131153756.GA64943@troutmask.apl.washington.edu> <20050131201356.GK73953@hex.databits.net> In-Reply-To: <20050131201356.GK73953@hex.databits.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org Subject: Re: Silicon Image SiI 3112 Serial ATA controller support? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2005 22:19:15 -0000 > Yeah. It's too bad Linux supports it fine, FreeBSD used to, and > almost every board that comes with SATA uses it. :( > > Regards, Actually, If I recall correctly, the ICH5 is the most popular (volume wise) controller being shipped today. This combined with the numbers from the Promise & 3ware controllers easily give you a substantial number of good controllers to choose from... -Sam From owner-freebsd-current@FreeBSD.ORG Mon Jan 31 22:31:19 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E508316A4CE; Mon, 31 Jan 2005 22:31:19 +0000 (GMT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id CABF143D2F; Mon, 31 Jan 2005 22:31:19 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id BCB6672DD4; Mon, 31 Jan 2005 14:31:19 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id BABB972DCB; Mon, 31 Jan 2005 14:31:19 -0800 (PST) Date: Mon, 31 Jan 2005 14:31:19 -0800 (PST) From: Doug White To: "M. Warner Losh" In-Reply-To: <20050131120605.C8759@carver.gumbysoft.com> Message-ID: <20050131143055.M10254@carver.gumbysoft.com> References: <20050130130011.A9B0D7306E@freebsd-current.sentex.ca> <20050131120605.C8759@carver.gumbysoft.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: sparc64@FreeBSD.org cc: scottl@FreeBSD.org cc: current@FreeBSD.org cc: tinderbox@FreeBSD.org Subject: Re: [current tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2005 22:31:20 -0000 On Mon, 31 Jan 2005, Doug White wrote: > On Mon, 31 Jan 2005, M. Warner Losh wrote: > > > In message: <20050130073248.W20417@pooker.samsco.org> > > Scott Long writes: > > : Why on earth is the digi driver bein compiled on sparc64? > > > > Most likely historical inertia... No body noticed until that module > > build got more facist. > > The digi driver in HEAD is completely inoperative anyway, so removing it > from the kernel config wouldn't hurt anyone, for the time being. Sorry, s/HEAD/RELENG_5/. I'll go back in my corner now. -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Mon Jan 31 22:48:53 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D718216A4CE for ; Mon, 31 Jan 2005 22:48:53 +0000 (GMT) Received: from hex.databits.net (hex.databits.net [216.118.117.77]) by mx1.FreeBSD.org (Postfix) with ESMTP id 775AA43D55 for ; Mon, 31 Jan 2005 22:48:52 +0000 (GMT) (envelope-from will@csociety.org) Received: by hex.databits.net (Postfix, from userid 1001) id E40D457AE9; Mon, 31 Jan 2005 16:48:49 -0600 (CST) Date: Mon, 31 Jan 2005 16:48:49 -0600 From: Will Andrews To: Samuel Clements Message-ID: <20050131224849.GO73953@hex.databits.net> Mail-Followup-To: Samuel Clements , freebsd-current@freebsd.org References: <8d.1f937784.2f2eb08c@aol.com> <20050131153756.GA64943@troutmask.apl.washington.edu> <20050131201356.GK73953@hex.databits.net> <41FEAEE2.8080609@linkline.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7jjDTNL5GSSsPbWk" Content-Disposition: inline In-Reply-To: <41FEAEE2.8080609@linkline.com> User-Agent: Mutt/1.5.6i cc: freebsd-current@freebsd.org Subject: Re: Silicon Image SiI 3112 Serial ATA controller support? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2005 22:48:54 -0000 --7jjDTNL5GSSsPbWk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jan 31, 2005 at 02:19:14PM -0800, Samuel Clements wrote: > Actually, If I recall correctly, the ICH5 is the most popular (volume=20 > wise) controller being shipped today. This combined with the numbers=20 > from the Promise & 3ware controllers easily give you a substantial=20 > number of good controllers to choose from... OK, I'm just looking at AMD boards. ICH5 obviously doesn't go on any of those. Unfortunately only a few high-end opteron boards ship with something other than SiI3112. :( Regards, --=20 wca --7jjDTNL5GSSsPbWk Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFB/rXRF47idPgWcsURAkKHAJ49SO6DxCYqGqAwWwxdx8JvlZIFGwCeNFD9 KrvS3jNug5LOR2F17lUha10= =7gpj -----END PGP SIGNATURE----- --7jjDTNL5GSSsPbWk-- From owner-freebsd-current@FreeBSD.ORG Mon Jan 31 23:17:34 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 93CFF16A4D0 for ; Mon, 31 Jan 2005 23:17:34 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id E2F3E43D5C for ; Mon, 31 Jan 2005 23:17:31 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id j0VNJdv7009749; Mon, 31 Jan 2005 15:19:39 -0800 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j0VNJdSh009748; Mon, 31 Jan 2005 15:19:39 -0800 Date: Mon, 31 Jan 2005 15:19:39 -0800 From: Brooks Davis To: Samuel Clements , freebsd-current@freebsd.org Message-ID: <20050131231939.GB12221@odin.ac.hmc.edu> References: <8d.1f937784.2f2eb08c@aol.com> <20050131153756.GA64943@troutmask.apl.washington.edu> <20050131201356.GK73953@hex.databits.net> <41FEAEE2.8080609@linkline.com> <20050131224849.GO73953@hex.databits.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="aM3YZ0Iwxop3KEKx" Content-Disposition: inline In-Reply-To: <20050131224849.GO73953@hex.databits.net> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu Subject: Re: Silicon Image SiI 3112 Serial ATA controller support? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2005 23:17:34 -0000 --aM3YZ0Iwxop3KEKx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jan 31, 2005 at 04:48:49PM -0600, Will Andrews wrote: > On Mon, Jan 31, 2005 at 02:19:14PM -0800, Samuel Clements wrote: > > Actually, If I recall correctly, the ICH5 is the most popular (volume= =20 > > wise) controller being shipped today. This combined with the numbers=20 > > from the Promise & 3ware controllers easily give you a substantial=20 > > number of good controllers to choose from... >=20 > OK, I'm just looking at AMD boards. ICH5 obviously doesn't go on > any of those. Unfortunately only a few high-end opteron boards > ship with something other than SiI3112. :( The DFI K8M800-MLVF (socket 754) I picked up for $76 avoids this issue as well as the nforce2 suckage. It's cheap and doens't have gigabit or 64-bit PCI, but even with the bottom of the line 2800+ it's giving the dual 2.4GHz Xeon a run for it's money. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --aM3YZ0Iwxop3KEKx Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFB/r0LXY6L6fI4GtQRAhTPAKCPXOqXTVhzceOChNYPjv+/TwvWUACg2s9I pGS1nEnocD74sfVb6h243mY= =IWfa -----END PGP SIGNATURE----- --aM3YZ0Iwxop3KEKx-- From owner-freebsd-current@FreeBSD.ORG Tue Feb 1 03:14:17 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1226C16A4CE for ; Tue, 1 Feb 2005 03:14:17 +0000 (GMT) Received: from node15.coopprint.com (node15.cooperativeprinting.com [208.4.77.15]) by mx1.FreeBSD.org (Postfix) with SMTP id 48D5E43D55 for ; Tue, 1 Feb 2005 03:14:16 +0000 (GMT) (envelope-from ryans@gamersimpact.com) Received: (qmail 11238 invoked by uid 0); 1 Feb 2005 03:11:55 -0000 Received: from unknown (HELO ?192.168.0.5?) (63.231.157.250) by node15.coopprint.com with SMTP; 1 Feb 2005 03:11:55 -0000 Message-ID: <41FEF40A.70006@gamersimpact.com> Date: Mon, 31 Jan 2005 21:14:18 -0600 From: Ryan Sommers User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: current@freebsd.org References: <63285.65.27.85.163.1107049410.squirrel@65.27.85.163> <41FC561C.3080505@errno.com> In-Reply-To: <41FC561C.3080505@errno.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: WEP Encryption Changes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2005 03:14:17 -0000 I recently (Jan 17) updated my laptop to the latest current. The last update was in November. After the latest update my WEP wireless stopped working. After playing with it. It appears something is amiss in the Tx key for me. I'm able to see broadcast packets coming over the wap just fine. They don't appear to be corrupt. However, nothing from the laptop gets to the wap. I'm wondering if Sam's update of sys/net80211 back in December might be the culprit. One thing I did notice was the new deftxkey option in ifconfig. I attempted to set this to 1 (to use the first and only key), didn't help. What all would I need to roll back to reverse these changes? Just sys/net80211 or would I need to hit sys/dev/wi also? Are there any better tools besides another wireless card (only have one unfortunately) to debug the frames? tcpdump seems to only get me so far. For the record this is a Lucent embedded WaveLAN (Dell Trumobile 1150) firmware 8.10.1. -- Ryan Sommers ryans@gamersimpact.com From owner-freebsd-current@FreeBSD.ORG Tue Feb 1 04:09:23 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E6EB916A4CE for ; Tue, 1 Feb 2005 04:09:23 +0000 (GMT) Received: from smtp1.server.rpi.edu (smtp1.server.rpi.edu [128.113.2.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 680C743D31 for ; Tue, 1 Feb 2005 04:09:23 +0000 (GMT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp1.server.rpi.edu (8.13.0/8.13.0) with ESMTP id j1149JkP004358; Mon, 31 Jan 2005 23:09:20 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <20041002233542.GL714@nexus.dglawrence.com> References: <200410020349.i923nG8v021675@northstar.hetzel.org> <20041002052856.GE17792@nexus.dglawrence.com> <20041002233542.GL714@nexus.dglawrence.com> Date: Mon, 31 Jan 2005 23:09:19 -0500 To: "David G. Lawrence" From: Garance A Drosihn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-CanItPRO-Stream: default X-RPI-SA-Score: undef - spam-scanning disabled X-Scanned-By: CanIt (www . canit . ca) cc: freebsd-current@freebsd.org Subject: Re: Bug in #! processing (long reply) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2005 04:09:24 -0000 Way back on Oct 02, 2004, David G. Lawrence wrote: >Garance wrote: > > In fact, it seems to be the '--' which is causing the rest of the >> line to be ignored, not the '#'. >> >> The PR is correct in that this feature is documented by perl books, >> but the right way to support the feature is to change /bin/sh and >> not the command interpreter. The PR includes a followup reply from >> Ahmon Dancy with some additional proof that >> the change to the command interpreter was the wrong way to fix this. >> >> Since this perl feature is documented in many places (including the >> famous "Camel" book from O'Reilly), we can not just drop the support >> in the command interpreter. But if we first fix /bin/sh then I >> believe we can drop it. > > Err, your terminology is a bit off (/bin/sh is the "command >interpreter"); what we're talking about is the behavior of the >execve() system call in the kernel, specifically the imgact_shell >image activation module. When the system sees that a file needs to >be interpreted by something (e.g. sh, perl, python, or some other >language interpreter) it parses the interpreter line specified at >the top of the file (#!/bin/sh) and sets up to invoke that with >the original file as the argument. > > ...but I see what you're saying and I agree with the thought. >The interpreter should decide if the # is a comment, not the kernel. Since the above message, the execve() system call was fixed, but we never changed the behavior of /bin/sh to match. I recently noticed that some of my scripts broke due to this combination, and today one of my friends also mentioned that some of their scripts were broken after they upgraded to the latest 5.3-stable. I remember someone saying that they were going to fix /bin/sh, but I don't remember who, and it looks like I didn't save that email. So I wrote up the following update, and hope to commit it sometime soon. It seems to work fine, but I want to test it a bit after doing some buildworlds on three different platforms. Index: options.c =================================================================== RCS file: /home/ncvs/src/bin/sh/options.c,v retrieving revision 1.21 diff -u -r1.21 options.c --- options.c 6 Apr 2004 20:06:51 -0000 1.21 +++ options.c 1 Feb 2005 01:53:52 -0000 @@ -67,6 +67,7 @@ char *optptr; /* used by nextopt */ char *minusc; /* argument to -c option */ +STATIC int found_eoo; /* found '-' or '--' in the option list */ STATIC void options(int); @@ -82,6 +83,7 @@ void procargs(int argc, char **argv) { + char *ap; int i; argptr = argv; @@ -91,6 +93,23 @@ optlist[i].val = 2; privileged = (getuid() != geteuid() || getgid() != getegid()); options(1); + /* + * If an end-of-options marker ('-' or '--') is followed by an arg + * of '#', then skip over all args after the marker. Some scripting + * languages (e.g.: perl) document that /bin/sh will implement this + * behavior, and they recommend that users take advantage of it to + * solve certain issues that can come up when writing a perl script. + * Yes, this feature is in /bin/sh to help users write perl scripts. + */ + if (found_eoo) { + ap = *argptr; + if (ap != NULL && ap[0] == '#' && ap[1] == '\0') { + while (*argptr != NULL) + argptr++; + /* We need to keep the final argument */ + argptr--; + } + } if (*argptr == NULL && minusc == NULL) sflag = 1; if (iflag == 2 && sflag == 1 && isatty(0) && isatty(1)) @@ -142,6 +161,7 @@ int val; int c; + found_eoo = 0; if (cmdline) minusc = NULL; while ((p = *argptr) != NULL) { @@ -149,6 +169,7 @@ if ((c = *p++) == '-') { val = 1; if (p[0] == '\0' || (p[0] == '-' && p[1] == '\0')) { + found_eoo = 1; if (!cmdline) { /* "-" means turn off -x and -v */ if (p[0] == '\0') -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu From owner-freebsd-current@FreeBSD.ORG Tue Feb 1 05:13:50 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 39C0716A4D8 for ; Tue, 1 Feb 2005 05:13:50 +0000 (GMT) Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0115643D31 for ; Tue, 1 Feb 2005 05:13:50 +0000 (GMT) (envelope-from vladimir@math.uic.edu) Received: from cat.math.uic.edu (c-24-12-126-199.client.comcast.net[24.12.126.199]) by comcast.net (rwcrmhc13) with SMTP id <20050201051349015009h6vge>; Tue, 1 Feb 2005 05:13:49 +0000 Received: (qmail 53246 invoked by uid 31415); 1 Feb 2005 05:13:40 -0000 Date: Mon, 31 Jan 2005 23:13:40 -0600 From: Vladimir Egorin To: Ryan Sommers Message-ID: <20050201051340.GA53226@math.uic.edu> References: <63285.65.27.85.163.1107049410.squirrel@65.27.85.163> <41FC561C.3080505@errno.com> <41FEF40A.70006@gamersimpact.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41FEF40A.70006@gamersimpact.com> User-Agent: Mutt/1.5.6i cc: current@freebsd.org Subject: Re: WEP Encryption Changes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2005 05:13:50 -0000 On Mon, Jan 31, 2005 at 09:14:18PM -0600, Ryan Sommers wrote: > I recently (Jan 17) updated my laptop to the latest current. The last > update was in November. After the latest update my WEP wireless stopped > working. After playing with it. It appears something is amiss in the Tx > key for me. I'm able to see broadcast packets coming over the wap just > fine. They don't appear to be corrupt. However, nothing from the laptop > gets to the wap. I'm wondering if Sam's update of sys/net80211 back in > December might be the culprit. > > One thing I did notice was the new deftxkey option in ifconfig. I > attempted to set this to 1 (to use the first and only key), didn't help. > > What all would I need to roll back to reverse these changes? Just > sys/net80211 or would I need to hit sys/dev/wi also? > > Are there any better tools besides another wireless card (only have one > unfortunately) to debug the frames? tcpdump seems to only get me so far. > > For the record this is a Lucent embedded WaveLAN (Dell Trumobile 1150) > firmware 8.10.1. > > -- > Ryan Sommers > ryans@gamersimpact.com Would this help? : 20041219: Auto-loading of ancillary wlan modules such as wlan_wep has been temporarily disabled; you need to statically configure the modules you need into your kernel or explicitly load them prior to use. Specifically, if you intend to use WEP encryption with an 802.11 device load/configure wlan_wep; if you want to use WPA with the ath driver load/configure wlan_tkip, wlan_ccmp, and wlan_xauth as required. -- Vladimir From owner-freebsd-current@FreeBSD.ORG Tue Feb 1 06:58:22 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ED42A16A4CE for ; Tue, 1 Feb 2005 06:58:22 +0000 (GMT) Received: from ylpvm43.prodigy.net (ylpvm43-ext.prodigy.net [207.115.57.74]) by mx1.FreeBSD.org (Postfix) with ESMTP id 28B4C43D48 for ; Tue, 1 Feb 2005 06:58:20 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.5.51] (adsl-64-171-186-233.dsl.snfc21.pacbell.net [64.171.186.233])j116wU2Y016123 for ; Tue, 1 Feb 2005 01:58:31 -0500 Message-ID: <41FF280F.1050102@root.org> Date: Mon, 31 Jan 2005 22:56:15 -0800 From: Nate Lawson User-Agent: Mozilla Thunderbird 1.0RC1 (X11/20041205) X-Accept-Language: en-us, en MIME-Version: 1.0 To: FreeBSD Current Content-Type: multipart/mixed; boundary="------------000405090204000606090607" Subject: patch: please test buildkernel X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2005 06:58:23 -0000 This is a multi-part message in MIME format. --------------000405090204000606090607 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit The attached patch adds a new interface. It works on i386 but I need compile testing on amd64, ia64, and one other arch (sparc, powerpc, etc.) Thanks! -- Nate --------------000405090204000606090607 Content-Type: text/plain; name="cpu_est_clockrate.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="cpu_est_clockrate.diff" Index: sys/cpu.h =================================================================== RCS file: sys/cpu.h diff -N sys/cpu.h --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ sys/cpu.h 1 Feb 2005 06:53:21 -0000 @@ -0,0 +1,121 @@ +/*- + * Copyright (c) 2005 Nate Lawson (SDG) + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + * + * $FreeBSD$ + */ + +#ifndef _SYS_CPU_H_ +#define _SYS_CPU_H_ + +/* + * CPU device support. + */ + +#define CPU_IVAR_PCPU 1 + +static __inline struct pcpu *cpu_get_pcpu(device_t dev) +{ + uintptr_t v = 0; + BUS_READ_IVAR(device_get_parent(dev), dev, CPU_IVAR_PCPU, &v); + return ((struct pcpu *)v); +} + +/* + * CPU frequency control interface. + */ + +/* Each driver's CPU frequency setting is exported in this format. */ +struct cf_setting { + int freq; /* Processor clock in Mhz or percent (in 100ths.) */ + int volts; /* Voltage in mV. */ + int power; /* Power consumed in mW. */ + int lat; /* Transition latency in us. */ + device_t dev; /* Driver providing this setting. */ +}; + +/* Maximum number of settings a given driver can have. */ +#define MAX_SETTINGS 16 + +/* A combination of settings is a level. */ +struct cf_level { + struct cf_setting total_set; + struct cf_setting abs_set; + struct cf_setting rel_set[MAX_SETTINGS]; + int rel_count; + TAILQ_ENTRY(cf_level) link; +}; + +TAILQ_HEAD(cf_level_lst, cf_level); + +/* Drivers should set all unknown values to this. */ +#define CPUFREQ_VAL_UNKNOWN (-1) + +/* + * Every driver offers a type of CPU control. Absolute levels are mutually + * exclusive while relative levels modify the current absolute level. There + * may be multiple absolute and relative drivers available on a given + * system. + * + * For example, consider a system with two absolute drivers that provide + * frequency settings of 100, 200 and 300, 400 and a relative driver that + * provides settings of 50%, 100%. The cpufreq core would export frequency + * levels of 50, 100, 150, 200, 300, 400. + */ +#define CPUFREQ_TYPE_RELATIVE (1<<0) +#define CPUFREQ_TYPE_ABSOLUTE (1<<1) + +/* + * When setting a level, the caller indicates the priority of this request. + * Priorities determine, among other things, whether a level can be + * overridden by other callers. For example, if the user sets a level but + * the system thermal driver needs to override it for emergency cooling, + * the driver would use a higher priority. Once the event has passed, the + * driver would call cpufreq to resume any previous level. + */ +#define CPUFREQ_PRIO_HIGHEST 1000000 +#define CPUFREQ_PRIO_KERN 1000 +#define CPUFREQ_PRIO_USER 100 +#define CPUFREQ_PRIO_LOWEST 0 + +/* + * Register and unregister a driver with the cpufreq core. Once a driver + * is registered, it must support calls to its CPUFREQ_GET, CPUFREQ_GET_LEVEL, + * and CPUFREQ_SET methods. It must also unregister before returning from + * its DEVICE_DETACH method. + */ +int cpufreq_register(device_t dev); +int cpufreq_unregister(device_t dev); + +/* Allow values to be +/- a bit since sometimes we have to estimate. */ +#define CPUFREQ_CMP(x, y) (abs((x) - (y)) < 25) + +/* + * Machine-dependent functions. + */ + +/* Estimate the current clock rate for the given CPU id. */ +int cpu_est_clockrate(int cpu_id, uint64_t *rate); + +#endif /* !_SYS_CPU_H_ */ Index: i386/i386/machdep.c =================================================================== RCS file: /home/ncvs/src/sys/i386/i386/machdep.c,v retrieving revision 1.603 diff -u -r1.603 machdep.c --- i386/i386/machdep.c 27 Nov 2004 06:51:35 -0000 1.603 +++ i386/i386/machdep.c 1 Feb 2005 06:33:20 -0000 @@ -56,8 +56,12 @@ #include #include -#include -#include +#include +#include +#include +#include +#include +#include #include #include #include @@ -66,21 +70,18 @@ #include #include #include +#include #include #include #include -#include -#include #include -#include -#include #include -#include +#include #include +#include +#include #include #include -#include -#include #include #include @@ -104,6 +105,7 @@ #include +#include #include #include #include @@ -1022,6 +1024,46 @@ { } +/* Get current clock frequency for the given cpu id. */ +int +cpu_est_clockrate(int cpu_id, uint64_t *rate) +{ + uint64_t tsc1, tsc2; + + if (pcpu_find(cpu_id) == NULL || rate == NULL) + return (EINVAL); + if (!tsc_present) + return (EOPNOTSUPP); + + /* If we're booting, trust the rate calibrated moments ago. */ + if (cold) { + *rate = tsc_freq; + return (0); + } + +#ifdef SMP + /* Schedule ourselves on the indicated cpu. */ + mtx_lock_spin(&sched_lock); + sched_bind(curthread, cpu_id); + mtx_unlock_spin(&sched_lock); +#endif + + /* Calibrate by measuring a short delay. */ + tsc1 = rdtsc(); + DELAY(1000); + tsc2 = rdtsc(); + +#ifdef SMP + mtx_lock_spin(&sched_lock); + sched_unbind(curthread); + mtx_unlock_spin(&sched_lock); +#endif + + tsc_freq = (tsc2 - tsc1) * 1000; + *rate = tsc_freq; + return (0); +} + /* * Shutdown the CPU as much as possible */ Index: amd64/amd64/machdep.c =================================================================== RCS file: /home/ncvs/src/sys/amd64/amd64/machdep.c,v retrieving revision 1.625 diff -u -r1.625 machdep.c --- amd64/amd64/machdep.c 29 Nov 2004 23:27:07 -0000 1.625 +++ amd64/amd64/machdep.c 1 Feb 2005 06:44:09 -0000 @@ -56,8 +56,12 @@ #include #include -#include -#include +#include +#include +#include +#include +#include +#include #include #include #include @@ -69,19 +73,17 @@ #include #include #include -#include -#include #include -#include #include #include +#include #include #include +#include #include #include -#include -#include +#include #include #include @@ -450,6 +452,44 @@ { } +/* Get current clock frequency for the given cpu id. */ +int +cpu_est_clockrate(int cpu_id, uint64_t *rate) +{ + uint64_t tsc1, tsc2; + + if (pcpu_find(cpu_id) == NULL || rate == NULL) + return (EINVAL); + + /* If we're booting, trust the rate calibrated moments ago. */ + if (cold) { + *rate = tsc_freq; + return (0); + } + +#ifdef SMP + /* Schedule ourselves on the indicated cpu. */ + mtx_lock_spin(&sched_lock); + sched_bind(curthread, cpu_id); + mtx_unlock_spin(&sched_lock); +#endif + + /* Calibrate by measuring a short delay. */ + tsc1 = rdtsc(); + DELAY(1000); + tsc2 = rdtsc(); + +#ifdef SMP + mtx_lock_spin(&sched_lock); + sched_unbind(curthread); + mtx_unlock_spin(&sched_lock); +#endif + + tsc_freq = (tsc2 - tsc1) * 1000; + *rate = tsc_freq; + return (0); +} + /* * Shutdown the CPU as much as possible */ Index: ia64/ia64/machdep.c =================================================================== RCS file: /home/ncvs/src/sys/ia64/ia64/machdep.c,v retrieving revision 1.193 diff -u -r1.193 machdep.c --- ia64/ia64/machdep.c 8 Dec 2004 05:46:54 -0000 1.193 +++ ia64/ia64/machdep.c 1 Feb 2005 06:47:52 -0000 @@ -35,6 +35,7 @@ #include #include +#include #include #include #include @@ -287,6 +288,17 @@ efi_reset_system(); } +/* Get current clock frequency for the given cpu id. */ +int +cpu_est_clockrate(int cpu_id, uint64_t *rate) +{ + + if (pcpu_find(cpu_id) == NULL || rate == NULL) + return (EINVAL); + *rate = processor_frequency; + return (0); +} + void cpu_halt() { Index: alpha/alpha/machdep.c =================================================================== RCS file: /home/ncvs/src/sys/alpha/alpha/machdep.c,v retrieving revision 1.228 diff -u -r1.228 machdep.c --- alpha/alpha/machdep.c 5 Jan 2005 20:05:49 -0000 1.228 +++ alpha/alpha/machdep.c 1 Feb 2005 06:50:03 -0000 @@ -98,6 +98,7 @@ #include #include +#include #include #include #include @@ -1718,6 +1719,14 @@ { } +/* Get current clock frequency for the given cpu id. */ +int +cpu_est_clockrate(int cpu_id, uint64_t *rate) +{ + + return (ENXIO); +} + /* * Shutdown the CPU as much as possible */ Index: arm/arm/machdep.c =================================================================== RCS file: /home/ncvs/src/sys/arm/arm/machdep.c,v retrieving revision 1.9 diff -u -r1.9 machdep.c --- arm/arm/machdep.c 10 Jan 2005 22:43:16 -0000 1.9 +++ arm/arm/machdep.c 1 Feb 2005 06:50:41 -0000 @@ -48,6 +48,7 @@ #include #include +#include #include #include #include @@ -236,6 +237,14 @@ SYSINIT(cpu, SI_SUB_CPU, SI_ORDER_FIRST, cpu_startup, NULL) +/* Get current clock frequency for the given cpu id. */ +int +cpu_est_clockrate(int cpu_id, uint64_t *rate) +{ + + return (ENXIO); +} + void cpu_idle(void) { Index: powerpc/powerpc/machdep.c =================================================================== RCS file: /home/ncvs/src/sys/powerpc/powerpc/machdep.c,v retrieving revision 1.79 diff -u -r1.79 machdep.c --- powerpc/powerpc/machdep.c 7 Jan 2005 02:29:20 -0000 1.79 +++ powerpc/powerpc/machdep.c 1 Feb 2005 06:51:03 -0000 @@ -64,6 +64,7 @@ #include #include +#include #include #include #include @@ -700,6 +701,14 @@ { } +/* Get current clock frequency for the given cpu id. */ +int +cpu_est_clockrate(int cpu_id, uint64_t *rate) +{ + + return (ENXIO); +} + /* * Shutdown the CPU as much as possible. */ Index: sparc64/sparc64/machdep.c =================================================================== RCS file: /home/ncvs/src/sys/sparc64/sparc64/machdep.c,v retrieving revision 1.117 diff -u -r1.117 machdep.c --- sparc64/sparc64/machdep.c 27 Nov 2004 06:51:38 -0000 1.117 +++ sparc64/sparc64/machdep.c 1 Feb 2005 06:51:39 -0000 @@ -44,6 +44,7 @@ #include #include #include +#include #include #include #include @@ -669,6 +670,14 @@ openfirmware_exit(args); } +/* Get current clock frequency for the given cpu id. */ +int +cpu_est_clockrate(int cpu_id, uint64_t *rate) +{ + + return (ENXIO); +} + /* * Duplicate OF_exit() with a different firmware call function that restores * the trap table, otherwise a RED state exception is triggered in at least --------------000405090204000606090607-- From owner-freebsd-current@FreeBSD.ORG Tue Feb 1 07:15:07 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3C69116A4CF for ; Tue, 1 Feb 2005 07:15:07 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 86F4743D2D for ; Tue, 1 Feb 2005 07:15:05 +0000 (GMT) (envelope-from joseph.koshy@gmail.com) Received: by rproxy.gmail.com with SMTP id a36so941634rnf for ; Mon, 31 Jan 2005 23:15:02 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=B5nUpZr5i+nNHRs8TsgDWnL0320y1jW3Ls1wHoxm2xLcekotbUpceTYBHQBwvK1CvrZcvE7OmkH8zXo70WhK066VNd5kJvRTiConX1/LSu045Tc7DXZjVA0I5v+xu/2bAGB6XTTvBd8PRV9kIAfSxdgoCYFpSG9+J63iy0MB//o= Received: by 10.39.3.48 with SMTP id f48mr221682rni; Mon, 31 Jan 2005 23:15:01 -0800 (PST) Received: by 10.38.209.12 with HTTP; Mon, 31 Jan 2005 23:15:01 -0800 (PST) Message-ID: <84dead720501312315319a5647@mail.gmail.com> Date: Tue, 1 Feb 2005 07:15:01 +0000 From: Joseph Koshy To: Nate Lawson In-Reply-To: <41FF280F.1050102@root.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <41FF280F.1050102@root.org> cc: FreeBSD Current Subject: Re: patch: please test buildkernel X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Joseph Koshy List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2005 07:15:07 -0000 > +#ifdef SMP > + /* Schedule ourselves on the indicated cpu. */ > + mtx_lock_spin(&sched_lock); > + sched_bind(curthread, cpu_id); > + mtx_unlock_spin(&sched_lock); > +#endif ... > +#ifdef SMP > + mtx_lock_spin(&sched_lock); > + sched_unbind(curthread); > + mtx_unlock_spin(&sched_lock); > +#endif This will break if 'curthread' is already bound. I ended up solving this problem with a new interface 'sched_is_bound()': http://perforce.freebsd.org/changeView.cgi?CH=63367 The cleaner alternative would probably have 'sched_bind()' return the previous CPU binding state. -- FreeBSD Volunteer, http://people.freebsd.org/~jkoshy From owner-freebsd-current@FreeBSD.ORG Tue Feb 1 07:27:16 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ADDB716A4CE for ; Tue, 1 Feb 2005 07:27:16 +0000 (GMT) Received: from spider.deepcore.dk (cpe.atm2-0-53484.0x50a6c9a6.abnxx9.customer.tele.dk [80.166.201.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id F399843D58 for ; Tue, 1 Feb 2005 07:27:15 +0000 (GMT) (envelope-from sos@DeepCore.dk) Received: from [194.192.25.143] (laptop.deepcore.dk [194.192.25.143]) by spider.deepcore.dk (8.12.11/8.12.10) with ESMTP id j117R9ka025772; Tue, 1 Feb 2005 08:27:11 +0100 (CET) (envelope-from sos@DeepCore.dk) Message-ID: <41FF2F40.8040904@DeepCore.dk> Date: Tue, 01 Feb 2005 08:26:56 +0100 From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= User-Agent: Mozilla Thunderbird 1.0 (X11/20050116) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Will Andrews References: <8d.1f937784.2f2eb08c@aol.com> <20050131153756.GA64943@troutmask.apl.washington.edu> <20050131201356.GK73953@hex.databits.net> <41FEAEE2.8080609@linkline.com> <20050131224849.GO73953@hex.databits.net> In-Reply-To: <20050131224849.GO73953@hex.databits.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-mail-scanned: by DeepCore Virus & Spam killer v1.6 cc: freebsd-current@freebsd.org cc: Samuel Clements Subject: Re: Silicon Image SiI 3112 Serial ATA controller support? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2005 07:27:16 -0000 Will Andrews wrote: > On Mon, Jan 31, 2005 at 02:19:14PM -0800, Samuel Clements wrote: >=20 >>Actually, If I recall correctly, the ICH5 is the most popular (volume=20 >>wise) controller being shipped today. This combined with the numbers=20 >>from the Promise & 3ware controllers easily give you a substantial=20 >>number of good controllers to choose from... >=20 >=20 > OK, I'm just looking at AMD boards. ICH5 obviously doesn't go on > any of those. Unfortunately only a few high-end opteron boards > ship with something other than SiI3112. :( As they say, you get what you pay for :) --=20 -S=F8ren From owner-freebsd-current@FreeBSD.ORG Tue Feb 1 08:59:21 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3C4F216A500 for ; Tue, 1 Feb 2005 08:59:21 +0000 (GMT) Received: from mailout03.sul.t-online.com (mailout03.sul.t-online.com [194.25.134.81]) by mx1.FreeBSD.org (Postfix) with ESMTP id ABBB543D48 for ; Tue, 1 Feb 2005 08:59:20 +0000 (GMT) (envelope-from mike@reifenberger.com) Received: from fwd00.aul.t-online.de by mailout03.sul.t-online.com with smtp id 1CvtsU-0007U3-02; Tue, 01 Feb 2005 09:59:18 +0100 Received: from fw.reifenberger.com (r3BwN8ZdQeQQoMJf1vMICajtXm7FBHDctkfWybMjkrJXB5RsWicXQr@[62.158.174.238]) by fmrl00.sul.t-online.com with esmtp id 1Cvtrl-0zkqzA0; Tue, 1 Feb 2005 09:58:33 +0100 Received: from localhost (mike@localhost)j118wWa3015704; Tue, 1 Feb 2005 09:58:32 +0100 (CET) (envelope-from mike@reifenberger.com) X-Authentication-Warning: fw.reifenberger.com: mike owned process doing -bs Date: Tue, 1 Feb 2005 09:58:31 +0100 (CET) From: Michael Reifenberger To: Nate Lawson In-Reply-To: <41FF280F.1050102@root.org> Message-ID: <20050201095803.W15584@fw.reifenberger.com> References: <41FF280F.1050102@root.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-ID: r3BwN8ZdQeQQoMJf1vMICajtXm7FBHDctkfWybMjkrJXB5RsWicXQr@t-dialin.net X-TOI-MSGID: bba50c13-5953-4cd2-b5b2-d3b634c71d7f cc: FreeBSD Current Subject: Re: patch: please test buildkernel X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2005 08:59:21 -0000 On Mon, 31 Jan 2005, Nate Lawson wrote: > Date: Mon, 31 Jan 2005 22:56:15 -0800 > From: Nate Lawson > To: FreeBSD Current > Subject: patch: please test buildkernel > > The attached patch adds a new interface. It works on i386 but I need compile > testing on amd64, ia64, and one other arch (sparc, powerpc, etc.) > compiles on amd64. Bye/2 --- Michael Reifenberger, Business Development Manager SAP-Basis, Plaut Consulting Comp: Michael.Reifenberger@plaut.de | Priv: Michael@Reifenberger.com http://www.plaut.de | http://www.Reifenberger.com From owner-freebsd-current@FreeBSD.ORG Tue Feb 1 10:59:14 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 21F0A16A4CF for ; Tue, 1 Feb 2005 10:59:14 +0000 (GMT) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id C15DA43D45 for ; Tue, 1 Feb 2005 10:59:13 +0000 (GMT) (envelope-from qing.li@bluecoat.com) Received: from bcs-mail.bluecoat.com (bcs-mail.bluecoat.com [216.52.23.69]) by whisker.bluecoat.com (8.13.0/8.13.0) with ESMTP id j11AxCSi002377 for ; Tue, 1 Feb 2005 02:59:13 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 1 Feb 2005 02:58:59 -0800 Message-ID: <00CDF9AA240E204FA6E923BD35BC643608503A1A@bcs-mail.internal.cacheflow.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: question on lock error Thread-Index: AcUITQaZ6NKgi//8R1qec6qaylFkhQ== From: "Li, Qing" To: X-Scanned-By: MIMEDefang 2.49 on 216.52.23.28 Subject: question on lock error X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2005 10:59:14 -0000 In my file if_llatbl.c, the entry and exit of function sysctl_dumparp is=20 guarded with IFNET_RLOCK() <<---- line 128 ... IFNET_RUNLOCK() dump_llcache is also my code. The modified "arp" and "ndp" commands will trigger the following messages, however, the output of the new L2/L3 cache table is correct. But later on a=20 userland application will get EPERM error. I think this is related to the=20 lock error. Could someone who is knowledgeable in the locking scheme give me a=20 pointer here, please ? TIA -- Qing Feb 1 10:02:19 heavygear kernel: --- syscall (202, FreeBSD ELF32, __sysctl), eip =3D 0x280b8ba3, esp =3D 0xbfbfe9bc, ebp =3D 0xbfbfe9f8 = --- Feb 1 10:02:19 heavygear kernel: sysctl_old_user() with the following non-sleepable locks held: Feb 1 10:02:19 heavygear kernel: exclusive sleep mutex ifnet r =3D 0 (0xc094bba0) locked @ /usr/src/sys/net/if_llatbl.c:128 Feb 1 10:02:19 heavygear kernel: KDB: stack backtrace: Feb 1 10:02:19 heavygear kernel: kdb_backtrace(1,1,1,b0,e4b7bc04) at kdb_backtrace+0x29 Feb 1 10:02:19 heavygear kernel: witness_warn(5,0,c0834d13) at witness_warn+0x19a Feb 1 10:02:19 heavygear kernel: sysctl_old_user(e4b7bc04,e4b7b9ec,b0,b0,e4b7b9ec) at sysctl_old_user+0x3d Feb 1 10:02:19 heavygear kernel: dump_llcache(c1fd842c,1c,c1fffd28,e4b7bc04,0) at dump_llcache+0x19e Feb 1 10:02:19 heavygear kernel: sysctl_dumparp(1c,e4b7bc04,1c0000bc,0,2) at sysctl_dumparp+0x5e Feb 1 10:02:19 heavygear kernel: sysctl_rtsock(c08a20c0,e4b7bc8c,4,e4b7bc04,c08a20c0) at sysctl_rtsock+0x10a Feb 1 10:02:19 heavygear kernel: sysctl_root(0,e4b7bc84,6,e4b7bc04,c247e450) at sysctl_root+0x11b Feb 1 10:02:19 heavygear kernel: userland_sysctl(c247e450,e4b7bc84,6,804f000,bfbfea7c) at userland_sysctl+0xf4 Feb 1 10:02:19 heavygear kernel: __sysctl(c247e450,e4b7bd14,6,1,10296) at __sysctl+0x77 Feb 1 10:02:19 heavygear kernel: syscall(2f,2f,2f,6,bfbfea7c) at syscall+0x213 Feb 1 10:02:19 heavygear kernel: Xint0x80_syscall() at Xint0x80_syscall+0x1f From owner-freebsd-current@FreeBSD.ORG Tue Feb 1 12:10:27 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8733116A4CE; Tue, 1 Feb 2005 12:10:27 +0000 (GMT) Received: from mir.ics.es.osaka-u.ac.jp (mir.ics.es.osaka-u.ac.jp [133.1.12.154]) by mx1.FreeBSD.org (Postfix) with ESMTP id D189C43D58; Tue, 1 Feb 2005 12:10:24 +0000 (GMT) (envelope-from k-sasaki@ist.osaka-u.ac.jp) Received: from pinklady2 ([192.168.144.174])j11CAIPq013314; Tue, 1 Feb 2005 21:10:23 +0900 (JST) (envelope-from k-sasaki@ist.osaka-u.ac.jp) Message-Id: <200502011210.j11CAIPq013314@mir.ics.es.osaka-u.ac.jp> From: "Kei Sasaki" To: , Date: Tue, 1 Feb 2005 21:10:29 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcUIVwUrRGyx+8VFSOeQg2eVKY8zDQ== Subject: Call for comments: CoxR, a CVS/mail-lists/BTS searching system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2005 12:10:27 -0000 Dear Sirs/Madams I am a second-year master's student at the Osaka University, Japan. My major is computer science and my interests lie in the development process of open source software, interests that I pursue being part of the local research group on software process. My research group is suggesting an approach for exploiting the informations implicitly contained in history archives like, for example, project's CVS, mailing lists archives, Bug Trucking System and so on. The result of our research is the information system named "CoxR" we developed and that can be found the detail about it at : http://sel.ics.es.osaka-u.ac.jp/~k-sasaki/coxr.html I would like to have your impressions on the above mentioned information system as an open source expert. CoxR can be found at http://scorpion.ics.es.osaka-u.ac.jp/cgi-bin/CodeSearch/coxr.html Thanks in advance for your time. Best regards, Sasaki Kei ------------------------- SASAKI Kei Graduate School of Information Science and Technology, Osaka University, Japan email-address : k-sasaki@ist.osaka-u.ac.jp From owner-freebsd-current@FreeBSD.ORG Mon Jan 31 13:36:10 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C48B016A4CE for ; Mon, 31 Jan 2005 13:36:10 +0000 (GMT) Received: from mail.dt.e-technik.uni-dortmund.de (krusty.dt.e-technik.Uni-Dortmund.DE [129.217.163.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3565643D1F for ; Mon, 31 Jan 2005 13:36:10 +0000 (GMT) (envelope-from matthias.andree@gmx.de) Received: from localhost (localhost [127.0.0.1])3FCEB44232; Mon, 31 Jan 2005 14:36:09 +0100 (CET) Received: from mail.dt.e-technik.uni-dortmund.de ([127.0.0.1]) by localhost (krusty [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 25122-01; Mon, 31 Jan 2005 14:36:04 +0100 (CET) Received: from m2a2.dyndns.org (pD9FFB976.dip.t-dialin.net [217.255.185.118]) 3B17F44234; Mon, 31 Jan 2005 14:36:04 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by merlin.emma.line.org (Postfix) with ESMTP id 310CB77D5B; Mon, 31 Jan 2005 14:36:03 +0100 (CET) Received: from merlin.emma.line.org ([127.0.0.1]) by localhost (m2a2.dyndns.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 17684-04-2; Mon, 31 Jan 2005 14:36:02 +0100 (CET) Received: by merlin.emma.line.org (Postfix, from userid 500) id 301B877D5C; Mon, 31 Jan 2005 14:36:02 +0100 (CET) From: Matthias Andree To: Dazgreen5@aol.com In-Reply-To: <8d.1f937784.2f2eb08c@aol.com> (Dazgreen5@aol.com's message of "Sun, 30 Jan 2005 16:50:04 EST") References: <8d.1f937784.2f2eb08c@aol.com> Date: Mon, 31 Jan 2005 14:36:02 +0100 Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: by amavisd-new at dt.e-technik.uni-dortmund.de X-Mailman-Approved-At: Tue, 01 Feb 2005 13:03:24 +0000 cc: freebsd-current@freebsd.org Subject: Re: Silicon Image SiI 3112 Serial ATA controller support? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2005 13:36:10 -0000 Dazgreen5@aol.com writes: > I wonder if you could help I have an asus a7n8x deluxe and have > been trying to install windows onto a serial drive with no success it keeps > asking for drives i down loaded them but still no joy would tou know any way i > can do this. Darren, you've hit the wrong forum, Windows installation is off-topic on FreeBSD lists. Please ask the vendor (either Asus or Microsoft; I'd think I'd suggest trying the first one first) for support. Other than that, FreeBSD has a SiI 3112 driver, but the hardware isn't to well-reputed and the common recommendation is to get something else as PCI card; for details on the hardware capabilities, Jeff Garzik's Linux oriented pages at can shed some light on this issue. Ignore the "libata driver status" lines, they apply to Linux exclusively. Jeff's site mentions that 3112 and 3114 have no command queueing support. BTW, I found answers to questions 1 to 7 at particularly elucidating. -- Matthias Andree From owner-freebsd-current@FreeBSD.ORG Mon Jan 31 23:26:57 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0E2EC16A4CF for ; Mon, 31 Jan 2005 23:26:57 +0000 (GMT) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [128.30.28.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id 75BDF43D2F for ; Mon, 31 Jan 2005 23:26:56 +0000 (GMT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: from khavrinen.lcs.mit.edu (localhost [IPv6:::1]) by khavrinen.lcs.mit.edu (8.12.9/8.12.9) with ESMTP id j0VNQsaa075721 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK CN=khavrinen.lcs.mit.edu issuer=SSL+20Client+20CA); Mon, 31 Jan 2005 18:26:54 -0500 (EST) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.12.9/8.12.9/Submit) id j0VNQsEo075718; Mon, 31 Jan 2005 18:26:54 -0500 (EST) (envelope-from wollman) Date: Mon, 31 Jan 2005 18:26:54 -0500 (EST) From: Garrett Wollman Message-Id: <200501312326.j0VNQsEo075718@khavrinen.lcs.mit.edu> To: Brooks Davis In-Reply-To: <20050131231939.GB12221@odin.ac.hmc.edu> References: <8d.1f937784.2f2eb08c@aol.com> <20050131153756.GA64943@troutmask.apl.washington.edu> <20050131201356.GK73953@hex.databits.net> <41FEAEE2.8080609@linkline.com> <20050131224849.GO73953@hex.databits.net> <20050131231939.GB12221@odin.ac.hmc.edu> X-Spam-Score: -18.8 () HTML_10_20,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES X-Scanned-By: MIMEDefang 2.37 X-Mailman-Approved-At: Tue, 01 Feb 2005 13:03:24 +0000 cc: freebsd-current@FreeBSD.ORG Subject: Re: Silicon Image SiI 3112 Serial ATA controller support? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2005 23:26:57 -0000 < said: > The DFI K8M800-MLVF (socket 754) I picked up for $76 avoids this issue > as well as the nforce2 suckage. It's cheap and doens't have gigabit or > 64-bit PCI, but even with the bottom of the line 2800+ it's giving the > dual 2.4GHz Xeon a run for it's money. The ASUS A8V "Deluxe" that I have in my new machine is quite nice and comes with Promise onboard. (With the fixes to the sk driver I might even be able to make that work; right now I've got an Intel card in.) dmesg follows. This was a semi-custom system built for my by PC's for Everyone; the only issue I've had with it was a well-known incompatibility between Matrox video cards and the AMI BIOS, which is why I've got an NVIDIA in there now. (At home I have an AthlonXP in the A7V8X with which I have also been pleased.) -GAWollman ------------------------------------------------------------------------ Copyright (c) 1992-2005 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.3-STABLE #2: Thu Jan 27 16:21:39 EST 2005 wollman@wollman-random-testing.csail.mit.edu:/usr/src/sys/amd64/compile/KHAVRINEN WARNING: WITNESS 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: AMD Athlon(tm) 64 FX-53 Processor (2403.08-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0xf7a Stepping = 10 Features=0x78bfbff AMD Features=0xe0500800 real memory = 1073414144 (1023 MB) avail memory = 1026375680 (978 MB) MADT: Forcing active-low polarity and level trigger for SCI ioapic0 irqs 0-23 on motherboard acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 cpu0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 agp0: mem 0xe8000000-0xefffffff at device 0.0 on pci0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: at device 0.0 (no driver attached) fwohci0: port 0x9400-0x947f mem 0xfa500000-0xfa5007ff irq 16 at device 7.0 on pci0 fwohci0: [GIANT-LOCKED] fwohci0: OHCI version 1.0 (ROM=1) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:e0:18:00:00:9c:01:26 fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 fwip0: on firewire0 fwip0: Firewire address: 00:e0:18:00:00:9c:01:26 @ 0xfffe00000000, S400, maxrec 2048 sbp0: on firewire0 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) atapci0: port 0x9800-0x987f,0xa000-0xa00f,0xa400-0xa43f mem 0xfa600000-0xfa61ffff,0xfa700000-0xfa700fff irq 18 at device 8.0 on pci0 atapci0: failed: rid 0x20 is memory, requested 4 ata2: channel #0 on atapci0 ata3: channel #1 on atapci0 ata4: channel #2 on atapci0 skc0: port 0xa800-0xa8ff mem 0xfa900000-0xfa903fff irq 17 at device 10.0 on pci0 skc0: Yukon Gigabit Ethernet 10/100/1000Base-T Adapter sk0: on skc0 sk0: Ethernet address: 00:11:2f:88:03:24 miibus0: on sk0 e1000phy0: on miibus0 e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX-FDX, auto skc0: [GIANT-LOCKED] em0: port 0xb000-0xb03f mem 0xfab00000-0xfab1ffff,0xfac00000-0xfac1ffff irq 17 at device 12.0 on pci0 em0: [GIANT-LOCKED] em0: Ethernet address: 00:07:e9:3e:df:99 em0: Speed:N/A Duplex:N/A atapci1: port 0xb400-0xb4ff,0xb800-0xb80f,0xc000-0xc003,0xc400-0xc407,0xc800-0xc803,0xd000-0xd007 irq 20 at device 15.0 on pci0 ata5: channel #0 on atapci1 ata6: channel #1 on atapci1 atapci2: port 0xfc00-0xfc0f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 15.1 on pci0 ata0: channel #0 on atapci2 ata1: channel #1 on atapci2 uhci0: port 0xd400-0xd41f irq 21 at device 16.0 on pci0 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xd800-0xd81f irq 21 at device 16.1 on pci0 uhci1: [GIANT-LOCKED] usb1: on uhci1 usb1: USB revision 1.0 uhub1: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0xe000-0xe01f irq 21 at device 16.2 on pci0 uhci2: [GIANT-LOCKED] usb2: on uhci2 usb2: USB revision 1.0 uhub2: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered uhci3: port 0xe400-0xe41f irq 21 at device 16.3 on pci0 uhci3: [GIANT-LOCKED] usb3: on uhci3 usb3: USB revision 1.0 uhub3: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub3: 2 ports with 2 removable, self powered pci0: at device 16.4 (no driver attached) isab0: at device 17.0 on pci0 isa0: on isab0 pcm0: port 0xe800-0xe8ff irq 22 at device 17.5 on pci0 pcm0: [GIANT-LOCKED] pcm0: acpi_button0: on acpi0 acpi_button1: on acpi0 atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model IntelliMouse, device ID 3 fdc0: port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on acpi0 fdc0: [FAST] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A orm0: at iomem 0xcf800-0xd0fff on isa0 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 Timecounter "TSC" frequency 2403083526 Hz quality 800 Timecounters tick every 1.000 msec IPsec: Initialized Security Association Processing. acd0: DVDROM at ata0-master UDMA33 acd1: DVDR at ata0-slave UDMA33 ad4: 152627MB [310101/16/63] at ata2-master SATA150 ad6: 152627MB [310101/16/63] at ata3-master SATA150 ar0: 152587MB [19452/255/63] status: READY subdisks: disk0 READY on ad4 at ata2-master disk1 READY on ad6 at ata3-master Mounting root from ufs:/dev/ar0s1a em0: Link is up 1000 Mbps Full Duplex nnpfs: cdev: 128, syscall: 339 ------------------------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Tue Feb 1 11:46:18 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 200B416A4CE for ; Tue, 1 Feb 2005 11:46:18 +0000 (GMT) Received: from smtp.atlantis.dp.ua (smtp.atlantis.dp.ua [193.108.46.231]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6F64F43D64 for ; Tue, 1 Feb 2005 11:46:16 +0000 (GMT) (envelope-from dmitry@atlantis.dp.ua) Received: from smtp.atlantis.dp.ua (smtp.atlantis.dp.ua [193.108.46.231]) by smtp.atlantis.dp.ua (8.12.6p2/8.12.6) with ESMTP id j11Bk7Zq067880 for ; Tue, 1 Feb 2005 13:46:07 +0200 (EET) (envelope-from dmitry@atlantis.dp.ua) Date: Tue, 1 Feb 2005 13:46:07 +0200 (EET) From: Dmitry Pryanishnikov To: freebsd-current@freebsd.org In-Reply-To: <41FF6934.9040300@atlantis.dp.ua> Message-ID: <20050201133646.E59974@atlantis.atlantis.dp.ua> References: <41FF6934.9040300@atlantis.dp.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Tue, 01 Feb 2005 13:03:24 +0000 Subject: What about ITE8212F (Was: Re: Silicon Image SiI 3112 Serial ATA) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2005 11:46:18 -0000 Hello! > Date: Tue, 01 Feb 2005 08:26:56 +0100 > From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= >>=20 >> OK, I'm just looking at AMD boards. ICH5 obviously doesn't go on >> any of those. Unfortunately only a few high-end opteron boards >> ship with something other than SiI3112. :( > > As they say, you get what you pay for :) > What's your opinion about ITE8212F-based ATA controllers? When code that supports those controllers should reach RELENG_5? There are no Promise cards available in our area, but I can buy ITE8212F ones. My primary usage will be just plain ATA channels (I don't plan to use RAID functionality yet). Sincerely, Dmitry -- Atlantis ISP, System Administrator e-mail: dmitry@atlantis.dp.ua nic-hdl: LYNX-RIPE From owner-freebsd-current@FreeBSD.ORG Tue Feb 1 14:34:58 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6452316A4CE for ; Tue, 1 Feb 2005 14:34:58 +0000 (GMT) Received: from node15.coopprint.com (node15.cooperativeprinting.com [208.4.77.15]) by mx1.FreeBSD.org (Postfix) with SMTP id BEEF343D31 for ; Tue, 1 Feb 2005 14:34:57 +0000 (GMT) (envelope-from ryans@gamersimpact.com) Received: (qmail 30887 invoked by uid 0); 1 Feb 2005 14:32:35 -0000 Received: from unknown (HELO ?192.168.0.5?) (63.231.157.250) by node15.coopprint.com with SMTP; 1 Feb 2005 14:32:35 -0000 Message-ID: <41FF9395.8030100@gamersimpact.com> Date: Tue, 01 Feb 2005 08:35:01 -0600 From: Ryan Sommers User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vladimir Egorin References: <63285.65.27.85.163.1107049410.squirrel@65.27.85.163> <41FC561C.3080505@errno.com> <41FEF40A.70006@gamersimpact.com> <20050201051340.GA53226@math.uic.edu> In-Reply-To: <20050201051340.GA53226@math.uic.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: current@freebsd.org Subject: Re: WEP Encryption Changes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2005 14:34:58 -0000 Vladimir Egorin wrote: > Would this help? : Unfortunately no. I've already taken care of loading the wep module. -- Ryan Sommers ryans@gamersimpact.com From owner-freebsd-current@FreeBSD.ORG Tue Feb 1 15:35:53 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 68FB316A4CE for ; Tue, 1 Feb 2005 15:35:53 +0000 (GMT) Received: from peedub.jennejohn.org (J9eee.j.pppool.de [85.74.158.238]) by mx1.FreeBSD.org (Postfix) with ESMTP id 819BF43D1D for ; Tue, 1 Feb 2005 15:35:52 +0000 (GMT) (envelope-from garyj@jennejohn.org) Received: from jennejohn.org (localhost [127.0.0.1]) by peedub.jennejohn.org (8.13.1/8.11.6) with ESMTP id j11FZo1p004745; Tue, 1 Feb 2005 16:35:50 +0100 (CET) (envelope-from garyj@jennejohn.org) Message-Id: <200502011535.j11FZo1p004745@peedub.jennejohn.org> X-Mailer: exmh version 2.7.0 06/18/2004 with nmh-1.0.4 To: Garrett Wollman In-Reply-To: Message from Garrett Wollman <200501312326.j0VNQsEo075718@khavrinen.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 01 Feb 2005 16:35:50 +0100 From: Gary Jennejohn cc: freebsd-current@FreeBSD.ORG Subject: Re: Silicon Image SiI 3112 Serial ATA controller support? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2005 15:35:53 -0000 Garrett Wollman writes: > The ASUS A8V "Deluxe" that I have in my new machine is quite nice and > comes with Promise onboard. (With the fixes to the sk driver I might > even be able to make that work; right now I've got an Intel card in.) > I have one of these boards and sk0 works just fine now in 32 and 64 bit modes with -current. --- Gary Jennejohn / garyj[at]jennejohn.org gj[at]freebsd.org garyj[at]denx.de From owner-freebsd-current@FreeBSD.ORG Tue Feb 1 15:56:01 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 87EEC16A4F9 for ; Tue, 1 Feb 2005 15:56:01 +0000 (GMT) Received: from mailserver.sandvine.com (sandvine.com [199.243.201.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id CCC4B43D2D for ; Tue, 1 Feb 2005 15:55:58 +0000 (GMT) (envelope-from emaste@phaedrus.sandvine.ca) Received: from labgw1.phaedrus.sandvine.com ([192.168.3.10]) by mailserver.sandvine.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 1 Feb 2005 10:55:57 -0500 Received: by labgw1.phaedrus.sandvine.com (Postfix, from userid 12627) id D41BC83C78; Tue, 1 Feb 2005 10:55:57 -0500 (EST) Date: Tue, 1 Feb 2005 10:55:57 -0500 From: Ed Maste To: current@freebsd.org Message-ID: <20050201155557.GH41895@sandvine.com> Mail-Followup-To: Ed Maste , 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-OriginalArrivalTime: 01 Feb 2005 15:55:58.0051 (UTC) FILETIME=[8500C330:01C50876] Subject: KDB/DDB deubgger_on_panic sysctl X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2005 15:56:01 -0000 About 1/2 year ago there was a thread about the debug.debugger_on_panic sysctl. The report was that it no longer functioned the same way (i.e. dropped into the debugger instead of panic, when set to zero), and the replies suggested it still worked as designed. We see the same behaviour of entering the debugger. The original thread was at http://lists.freebsd.org/pipermail/freebsd-current/2004-July/031446.html It appears that on RELENG_4 with DDB, the sysctl's behaviour was more like debugger_on_panic_or_trap. i386/i386/trap.c used to check debugger_on_panic before calling kdb_trap (for DDB). In RELENG_4, i386/i386/trap.c had, in trap_fatal(): http://fxr.watson.org/fxr/source/i386/i386/trap.c?v=RELENG4#L964 964 #ifdef KDB 965 if (kdb_trap(&psl)) 966 return; 967 #endif 968 #ifdef DDB 969 if ((debugger_on_panic || db_active) && kdb_trap(type, 0, frame)) 970 return; 971 #endif 972 printf("trap number = %d\n", type); 973 if (type <= MAX_TRAP_MSG) 974 panic("%s", trap_msg[type]); 975 else 976 panic("unknown/reserved trap"); The following patch somewhat restores the previous functionality $ diff -u3 trap.c.orig trap.c --- trap.c.orig Tue Feb 1 10:21:50 2005 +++ trap.c Tue Feb 1 10:26:01 2005 @@ -753,6 +753,7 @@ return((rv == KERN_PROTECTION_FAILURE) ? SIGBUS : SIGSEGV); } +extern int debugger_on_panic; static void trap_fatal(frame, eva) struct trapframe *frame; @@ -820,7 +821,7 @@ } #ifdef KDB - if (kdb_trap(type, 0, frame)) + if (debugger_on_panic && kdb_trap(type, 0, frame)) return; #endif printf("trap number = %d\n", type); If debugger_on_panic=0 and the debugger is entered for other reasons (e.g. key sequence), I suppose there's an issue with something in the debugger causing a trap and then leading to a panic. In RELENG_4 there was a db_active global for this case, but it seems to be gone. I'm not sure of the proper way to fix that, but my concern is mainly that remote units don't sit at a debugger prompt. Ed Maste Sandvine Inc. From owner-freebsd-current@FreeBSD.ORG Tue Feb 1 16:53:35 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 280A716A4CE for ; Tue, 1 Feb 2005 16:53:35 +0000 (GMT) Received: from ylpvm15.prodigy.net (ylpvm15-ext.prodigy.net [207.115.57.46]) by mx1.FreeBSD.org (Postfix) with ESMTP id CECF643D45 for ; Tue, 1 Feb 2005 16:53:34 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.0.34] (adsl-67-119-74-222.dsl.sntc01.pacbell.net [67.119.74.222])j11GnFbs025225; Tue, 1 Feb 2005 11:49:15 -0500 Message-ID: <41FFB40A.2000507@root.org> Date: Tue, 01 Feb 2005 08:53:30 -0800 From: Nate Lawson User-Agent: Mozilla Thunderbird 1.0RC1 (X11/20041205) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joseph Koshy References: <41FF280F.1050102@root.org> <84dead720501312315319a5647@mail.gmail.com> In-Reply-To: <84dead720501312315319a5647@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: FreeBSD Current Subject: Re: patch: please test buildkernel X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2005 16:53:35 -0000 Joseph Koshy wrote: >>+#ifdef SMP >>+ /* Schedule ourselves on the indicated cpu. */ >>+ mtx_lock_spin(&sched_lock); >>+ sched_bind(curthread, cpu_id); >>+ mtx_unlock_spin(&sched_lock); >>+#endif > > ... > >>+#ifdef SMP >>+ mtx_lock_spin(&sched_lock); >>+ sched_unbind(curthread); >>+ mtx_unlock_spin(&sched_lock); >>+#endif > > > This will break if 'curthread' is already bound. > > I ended up solving this problem with a new interface 'sched_is_bound()': > > http://perforce.freebsd.org/changeView.cgi?CH=63367 > > The cleaner alternative would probably have 'sched_bind()' return the > previous CPU binding state. Not a problem for me since no code in the kernel calls this interface after sched_bind(). I agree this is a general problem that should be solved but I think it's fine to bring in cpufreq without solving it first. -- Nate From owner-freebsd-current@FreeBSD.ORG Tue Feb 1 16:58:40 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1EC1D16A4CE; Tue, 1 Feb 2005 16:58:40 +0000 (GMT) Received: from ylpvm01.prodigy.net (ylpvm01-ext.prodigy.net [207.115.57.32]) by mx1.FreeBSD.org (Postfix) with ESMTP id AA76043D2D; Tue, 1 Feb 2005 16:58:39 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.0.34] (adsl-67-119-74-222.dsl.sntc01.pacbell.net [67.119.74.222])j11GwbvE028897; Tue, 1 Feb 2005 11:58:38 -0500 Message-ID: <41FFB53B.3020907@root.org> Date: Tue, 01 Feb 2005 08:58:35 -0800 From: Nate Lawson User-Agent: Mozilla Thunderbird 1.0RC1 (X11/20041205) X-Accept-Language: en-us, en MIME-Version: 1.0 To: current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: acpi@freebsd.org Subject: New cpufreq framework and drivers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2005 16:58:40 -0000 cpufreq is a framework for individual drivers to provide cpu power management and an interface for the user and other parts of the kernel to access that framework. Hardware drivers are of two types, absolute and relative. SpeedStep, Powernow, etc. are absolute drivers in that they set the cpu's base frequency. ACPI throttling, Longrun, etc. are relative drivers that reduce the processor's clock to a fraction of its current base (i.e., they have an additive effect.) The first release version of cpufreq only supports absolute drivers but the interface and framework have been tested with relative drivers. Existing relative drivers will continue to work with their current interfaces. Below is the first patch of cpufreq for wider testing. It has the framework, cpu pseudodriver updates, and two hardware drivers -- ACPI performance states and SpeedStep-ICH. It has had a lot of testing on supported hardware but needs wider testing before importing. Other hardware drivers can be quickly ported to this interface, and I'm happy to assist their maintainers. http://www.root.org/~nate/freebsd/cpufreq.diff -- Nate From owner-freebsd-current@FreeBSD.ORG Tue Feb 1 17:04:30 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AE59516A4CE for ; Tue, 1 Feb 2005 17:04:30 +0000 (GMT) Received: from critter.freebsd.dk (f170.freebsd.dk [212.242.86.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id E590F43D5C for ; Tue, 1 Feb 2005 17:04:29 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.1/8.13.1) with ESMTP id j11H4SU2017947 for ; Tue, 1 Feb 2005 18:04:28 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: current@freebsd.org From: "Poul-Henning Kamp" In-Reply-To: Your message of "Tue, 01 Feb 2005 16:59:23 GMT." <200502011659.j11GxNWw066589@repoman.freebsd.org> Date: Tue, 01 Feb 2005 18:04:28 +0100 Message-ID: <17946.1107277468@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Subject: IEEE488 in FreeBSD, a cautionary warning... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2005 17:04:30 -0000 Before you get your hopes too far up because of the commit below, let me make it clear that while my ambitions in the IEEE488 area are unchecked, the amount of time I have to spend on it is very limited. Depending how things goes, this may develop over time to support the classing 488.1 "ibfoo()" API and maybe even the 488.2 API, but do not hold your breath for it. If somebody wants to get their fingers dirty on this, they are more than welcome. Linux has a pretty comprehensive thing at (http://linux-gpib.sourceforge.net/) from where much can be gleaned. Poul-Henning In message <200502011659.j11GxNWw066589@repoman.freebsd.org>, Poul-Henning Kamp writes: >phk 2005-02-01 16:59:23 UTC > > FreeBSD src repository > > Modified files: > sys/conf NOTES files > Added files: > sys/dev/ieee488 pcii.c > Log: > Add a IEEE488 driver for PCIIA compatible cards. > > This driver implements "unaddressed listen only mode", which is what > printers and plotters commonly do on GP-IB busses. > > This means that you can capture print/plot like output from your > instruments by configuring them as necessary (good luck!) and > > cat -u /dev/gpib0l > /tmp/somefile > > Since there is no way to know when no more output is comming you > will have to ctrl-C the cat process when it is done (that is why > the -u is important). > > Revision Changes Path > 1.1297 +9 -0 src/sys/conf/NOTES > 1.986 +1 -0 src/sys/conf/files > 1.1 +419 -0 src/sys/dev/ieee488/pcii.c (new) > -- 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 Feb 1 17:08:15 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9A0D016A4CE; Tue, 1 Feb 2005 17:08:15 +0000 (GMT) Received: from ylpvm01.prodigy.net (ylpvm01-ext.prodigy.net [207.115.57.32]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3530D43D1D; Tue, 1 Feb 2005 17:08:15 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.0.34] (adsl-67-119-74-222.dsl.sntc01.pacbell.net [67.119.74.222])j11H8DvE010808; Tue, 1 Feb 2005 12:08:13 -0500 Message-ID: <41FFB77B.10305@root.org> Date: Tue, 01 Feb 2005 09:08:11 -0800 From: Nate Lawson User-Agent: Mozilla Thunderbird 1.0RC1 (X11/20041205) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nate Lawson References: <41FFB53B.3020907@root.org> In-Reply-To: <41FFB53B.3020907@root.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: acpi@freebsd.org cc: current@freebsd.org Subject: Re: New cpufreq framework and drivers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2005 17:08:15 -0000 Nate Lawson wrote: > Below is the first patch of cpufreq for wider testing. It has the > framework, cpu pseudodriver updates, and two hardware drivers -- ACPI > performance states and SpeedStep-ICH. It has had a lot of testing on > supported hardware but needs wider testing before importing. Other > hardware drivers can be quickly ported to this interface, and I'm happy > to assist their maintainers. > > http://www.root.org/~nate/freebsd/cpufreq.diff Sorry, I'm so familiar with the interface that I forgot to mention how to use it. To test, build a new kernel and modules. Load one or both of acpi_perf.ko and cpufreq.ko at boot time. Type "sysctl dev.cpu" to see the new freq and freq_levels output. If you're a driver maintainer, see sys/cpu.h and speedstep_ich.c or acpi_perf.c for an example how to provide the driver interface. -- Nate From owner-freebsd-current@FreeBSD.ORG Tue Feb 1 18:20:28 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3266116A4CE for ; Tue, 1 Feb 2005 18:20:28 +0000 (GMT) Received: from pimout3-ext.prodigy.net (pimout3-ext.prodigy.net [207.115.63.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id CD31343D1D for ; Tue, 1 Feb 2005 18:20:27 +0000 (GMT) (envelope-from julian@elischer.org) Received: from [192.168.1.102] (adsl-216-100-134-143.dsl.snfc21.pacbell.net [216.100.134.143])j11IKPoC277694 for ; Tue, 1 Feb 2005 13:20:26 -0500 Date: Tue, 1 Feb 2005 10:20:24 -0800 (PST) From: Julian Elischer X-X-Sender: julian@localhost To: current@freebsd.org Message-ID: <20050201101113.J572@localhost> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: cynchronised sleep capbilty.. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2005 18:20:28 -0000 I often find myself wanting to write shell scripts that do: while : do {report some statistic} sleep 10 done now this is of course only approximate as the delay will not be exactly 10 seconds and it will gradually creep.. This doesn't matter too much except that I now need to do the same on 50 machines and I need the data to line up. The machiens all have ntp running so their clocks are all alligned (enough) so what I really need is: while: do report results sleep -until_next 10 done I have inplemented something like this with a crude shell function that sleeps up to 9 seconds to get to thenext N+9 second, and then loops with sleep 0.1 up to 10 times until the second ticks over, but that is a hack and inneficient to say the least.. firstly: does anyone know a better way to do this? secondly: is it worth implementing some "do ths every N seconds" facility somewhere? e.g. sleep -u 10 # sleep until next 10 second boundary. thirdly: is it worth making sleep a shell builtin? running sleep(1) every time is a lot of work for what we need. julian From owner-freebsd-current@FreeBSD.ORG Tue Feb 1 18:36:09 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4961916A4CE for ; Tue, 1 Feb 2005 18:36:09 +0000 (GMT) Received: from mail28.syd.optusnet.com.au (mail28.syd.optusnet.com.au [211.29.133.169]) by mx1.FreeBSD.org (Postfix) with ESMTP id 799D343D41 for ; Tue, 1 Feb 2005 18:36:06 +0000 (GMT) (envelope-from akm@theinternet.com.au) Received: from theinternet.com.au (c211-30-103-113.carlnfd1.nsw.optusnet.com.au [211.30.103.113]) j11IZrHb018893 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 2 Feb 2005 05:35:53 +1100 Received: from theinternet.com.au (localhost [127.0.0.1]) by theinternet.com.au (8.12.11/8.12.11) with ESMTP id j11IZrTW058768; Wed, 2 Feb 2005 05:35:53 +1100 (EST) (envelope-from akm@theinternet.com.au) Received: (from akm@localhost) by theinternet.com.au (8.12.11/8.12.11/Submit) id j11IZrTM058767; Wed, 2 Feb 2005 05:35:53 +1100 (EST) (envelope-from akm) Date: Wed, 2 Feb 2005 05:35:52 +1100 From: Andrew Milton To: Julian Elischer Message-ID: <20050201183552.GA48100@camelot.theinternet.com.au> References: <20050201101113.J572@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050201101113.J572@localhost> User-Agent: Mutt/1.5.6i cc: current@freebsd.org Subject: Re: cynchronised sleep capbilty.. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2005 18:36:09 -0000 +-------[ Julian Elischer ]---------------------- | | This doesn't matter too much except that I now need to do | the same on 50 machines and I need the data to line up. [snip] | firstly: does anyone know a better way to do this? look at clusterit.. http://www.garbled.net/clusterit.html it has as one of it's features; Barrier sync for shell scripting. This is a new idea. The barrier mechanism consists of a daemon run on a host, and a client which can be used to barrier sync with. Not sure if it's suitable for what you want. -- Andrew Milton akm@theinternet.com.au From owner-freebsd-current@FreeBSD.ORG Tue Feb 1 18:41:57 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 68E0E16A4CE for ; Tue, 1 Feb 2005 18:41:57 +0000 (GMT) Received: from pimout4-ext.prodigy.net (pimout4-ext.prodigy.net [207.115.63.98]) by mx1.FreeBSD.org (Postfix) with ESMTP id D478343D2F for ; Tue, 1 Feb 2005 18:41:56 +0000 (GMT) (envelope-from julian@elischer.org) Received: from [192.168.1.102] (adsl-216-100-134-143.dsl.snfc21.pacbell.net [216.100.134.143])j11Ifqu2037212; Tue, 1 Feb 2005 13:41:54 -0500 Date: Tue, 1 Feb 2005 10:41:51 -0800 (PST) From: Julian Elischer X-X-Sender: julian@localhost To: Andrew Milton In-Reply-To: <20050201183552.GA48100@camelot.theinternet.com.au> Message-ID: <20050201103824.X572@localhost> References: <20050201101113.J572@localhost> <20050201183552.GA48100@camelot.theinternet.com.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: current@freebsd.org Subject: Re: cynchronised sleep capbilty.. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2005 18:41:57 -0000 On Wed, 2 Feb 2005, Andrew Milton wrote: > +-------[ Julian Elischer ]---------------------- > | > > > | This doesn't matter too much except that I now need to do > | the same on 50 machines and I need the data to line up. > > [snip] > > | firstly: does anyone know a better way to do this? > > look at clusterit.. > > http://www.garbled.net/clusterit.html > > it has as one of it's features; > > Barrier sync for shell scripting. > This is a new idea. The barrier mechanism consists of a daemon run on a > host, and a client which can be used to barrier sync with. > > Not sure if it's suitable for what you want. "sorta" but a bit heavyweight for what I'm looking for.. also doesn't give the simple accurate X second period I'm looking for for simple shellscripts without adding the server daemon. a good find though.. I may have some other uses for it :-) julian > > From owner-freebsd-current@FreeBSD.ORG Tue Feb 1 19:03:03 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BA48916A4CE; Tue, 1 Feb 2005 19:03:03 +0000 (GMT) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7451943D1D; Tue, 1 Feb 2005 19:03:03 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.0.34] (adsl-67-119-74-222.dsl.sntc01.pacbell.net [67.119.74.222]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id j11J21Wk028287 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 1 Feb 2005 11:02:28 -0800 Message-ID: <41FFD21D.1080906@root.org> Date: Tue, 01 Feb 2005 11:01:49 -0800 From: Nate Lawson User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Anderson References: <41FFB53B.3020907@root.org> <41FFB77B.10305@root.org> <41FFCBF3.7070505@centtech.com> In-Reply-To: <41FFCBF3.7070505@centtech.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: acpi@freebsd.org cc: current@freebsd.org Subject: Re: New cpufreq framework and drivers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2005 19:03:03 -0000 Eric Anderson wrote: > Nate Lawson wrote: > >> Nate Lawson wrote: >> >>> Below is the first patch of cpufreq for wider testing. It has the >>> framework, cpu pseudodriver updates, and two hardware drivers -- ACPI >>> performance states and SpeedStep-ICH. It has had a lot of testing on >>> supported hardware but needs wider testing before importing. Other >>> hardware drivers can be quickly ported to this interface, and I'm >>> happy to assist their maintainers. >>> >>> http://www.root.org/~nate/freebsd/cpufreq.diff >> >> >> >> Sorry, I'm so familiar with the interface that I forgot to mention how >> to use it. To test, build a new kernel and modules. Load one or both >> of acpi_perf.ko and cpufreq.ko at boot time. Type "sysctl dev.cpu" to >> see the new freq and freq_levels output. If you're a driver >> maintainer, see sys/cpu.h and speedstep_ich.c or acpi_perf.c for an >> example how to provide the driver interface. >> > > Will this only work on -current, or also 5.3-stable? It should work on -stable, modulo any diff fuzz. -- Nate From owner-freebsd-current@FreeBSD.ORG Tue Feb 1 19:03:31 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5EB0E16A4CE for ; Tue, 1 Feb 2005 19:03:31 +0000 (GMT) Received: from mail11.syd.optusnet.com.au (mail11.syd.optusnet.com.au [211.29.132.192]) by mx1.FreeBSD.org (Postfix) with ESMTP id C01C843D1F for ; Tue, 1 Feb 2005 19:03:30 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (c211-30-75-229.belrs2.nsw.optusnet.com.au [211.30.75.229]) j11J3JVQ024550 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 2 Feb 2005 06:03:19 +1100 Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1])j11J3J7l046684; Wed, 2 Feb 2005 06:03:19 +1100 (EST) (envelope-from pjeremy@cirb503493.alcatel.com.au) Received: (from pjeremy@localhost)j11J3J5A046683; Wed, 2 Feb 2005 06:03:19 +1100 (EST) (envelope-from pjeremy) Date: Wed, 2 Feb 2005 06:03:18 +1100 From: Peter Jeremy To: Julian Elischer Message-ID: <20050201190318.GE45608@cirb503493.alcatel.com.au> References: <20050201101113.J572@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050201101113.J572@localhost> User-Agent: Mutt/1.4.2i cc: current@freebsd.org Subject: Re: cynchronised sleep capbilty.. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2005 19:03:31 -0000 On Tue, 2005-Feb-01 10:20:24 -0800, Julian Elischer wrote: >while: >do > report results > sleep -until_next 10 >done How about: 1) Re-write the loop in C, perl or equivalent using setitimer(). You can system() out to collect the results. 2) Write a small C program that uses setitimer() and signals its parent whenever the timer triggers. Run it in the background and just pause within the sh loop. -- Peter Jeremy From owner-freebsd-current@FreeBSD.ORG Tue Feb 1 19:35:38 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 80C7416A4CE for ; Tue, 1 Feb 2005 19:35:38 +0000 (GMT) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 499F443D1F for ; Tue, 1 Feb 2005 19:35:38 +0000 (GMT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) j11JZa0e095485; Tue, 1 Feb 2005 11:35:37 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.9p2/8.12.9/Submit) id j11JZaR6095484; Tue, 1 Feb 2005 11:35:36 -0800 (PST) (envelope-from dillon) Date: Tue, 1 Feb 2005 11:35:36 -0800 (PST) From: Matthew Dillon Message-Id: <200502011935.j11JZaR6095484@apollo.backplane.com> To: Julian Elischer References: <20050201101113.J572@localhost> cc: current@freebsd.org Subject: Re: cynchronised sleep capbilty.. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2005 19:35:38 -0000 :I often find myself wanting to write shell scripts that do: : :... : :while: :do : report results : sleep -until_next 10 :done : : :I have inplemented something like this with a crude :shell function that sleeps up to 9 seconds to get to I think integrating such an option into /bin/sleep is an excellent idea. I have had need for such a feature myself on occassion. :thirdly: is it worth making sleep a shell builtin? :running sleep(1) every time is a lot of work for what :we need. : :julian I don't think this is necessary. -Matt From owner-freebsd-current@FreeBSD.ORG Tue Feb 1 20:12:12 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B212216A4CE for ; Tue, 1 Feb 2005 20:12:12 +0000 (GMT) Received: from spider.deepcore.dk (cpe.atm2-0-53484.0x50a6c9a6.abnxx9.customer.tele.dk [80.166.201.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0018043D60 for ; Tue, 1 Feb 2005 20:12:11 +0000 (GMT) (envelope-from sos@DeepCore.dk) Received: from [194.192.25.143] (laptop.deepcore.dk [194.192.25.143]) by spider.deepcore.dk (8.12.11/8.12.10) with ESMTP id j11KC4dF032694; Tue, 1 Feb 2005 21:12:07 +0100 (CET) (envelope-from sos@DeepCore.dk) Message-ID: <41FFE288.3090804@DeepCore.dk> Date: Tue, 01 Feb 2005 21:11:52 +0100 From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= User-Agent: Mozilla Thunderbird 1.0 (X11/20050116) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dmitry Pryanishnikov References: <41FF6934.9040300@atlantis.dp.ua> <20050201133646.E59974@atlantis.atlantis.dp.ua> In-Reply-To: <20050201133646.E59974@atlantis.atlantis.dp.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-mail-scanned: by DeepCore Virus & Spam killer v1.6 cc: freebsd-current@freebsd.org Subject: Re: What about ITE8212F (Was: Re: Silicon Image SiI 3112 Serial ATA) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2005 20:12:12 -0000 Dmitry Pryanishnikov wrote: >=20 > Hello! >=20 >> Date: Tue, 01 Feb 2005 08:26:56 +0100 >> From: =3D?ISO-8859-1?Q?S=3DF8ren_Schmidt?=3D >> >>> =3D20 >>> OK, I'm just looking at AMD boards. ICH5 obviously doesn't go on >>> any of those. Unfortunately only a few high-end opteron boards >>> ship with something other than SiI3112. :( >> >> >> As they say, you get what you pay for :) >> >=20 > What's your opinion about ITE8212F-based ATA controllers? When code=20 > that supports those controllers should reach RELENG_5? There are no=20 > Promise cards > available in our area, but I can buy ITE8212F ones. My primary usage=20 > will be > just plain ATA channels (I don't plan to use RAID functionality yet). Well, I dont have too much experience with it since I just got the HW=20 about a month ago but its worked flawlessly since in daily use in my WS. If you want 5.x support just grap the ATA driver form -current minus the = atapi*.? stuff and its will do the trick. -S=F8ren From owner-freebsd-current@FreeBSD.ORG Tue Feb 1 20:23:22 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8EEB516A4CE for ; Tue, 1 Feb 2005 20:23:22 +0000 (GMT) Received: from zircon.seattle.wa.us (dsl231-043-165.sea1.dsl.speakeasy.net [216.231.43.165]) by mx1.FreeBSD.org (Postfix) with SMTP id 18CF743D39 for ; Tue, 1 Feb 2005 20:23:20 +0000 (GMT) (envelope-from joe@zircon.seattle.wa.us) Received: (qmail 60985 invoked from network); 1 Feb 2005 20:25:16 -0000 Received: from localhost (HELO localhost.zircon.seattle.wa.us) (127.0.0.1) by localhost with SMTP; 1 Feb 2005 20:25:16 -0000 From: Joe Kelsey To: Matthew Dillon In-Reply-To: <200502011935.j11JZaR6095484@apollo.backplane.com> References: <20050201101113.J572@localhost> <200502011935.j11JZaR6095484@apollo.backplane.com> Content-Type: text/plain Date: Tue, 01 Feb 2005 12:25:16 -0800 Message-Id: <1107289516.664.22.camel@zircon.zircon.seattle.wa.us> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit cc: Julian Elischer cc: current@freebsd.org Subject: Re: cynchronised sleep capbilty.. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2005 20:23:22 -0000 On Tue, 2005-02-01 at 11:35 -0800, Matthew Dillon wrote: > :I often find myself wanting to write shell scripts that do: > : > :... > : > :while: > :do > : report results > : sleep -until_next 10 > :done > : > : > :I have inplemented something like this with a crude > :shell function that sleeps up to 9 seconds to get to > > I think integrating such an option into /bin/sleep is an excellent idea. > I have had need for such a feature myself on occassion. Note that ksh93 has an external command interface which allows the addition of user-defined discipline functions and builtin commands which could allow for these sort of options. > :thirdly: is it worth making sleep a shell builtin? > :running sleep(1) every time is a lot of work for what > :we need. > : > :julian > > I don't think this is necessary. sleep is a ksh93 builtin command. ksh93 also now has a new license the OSI Common Public License, instead of the old ATT-specific license. Also, Glenn Fowler and David Korn seem very open to ideas such as this. /Joe From owner-freebsd-current@FreeBSD.ORG Tue Feb 1 21:20:34 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6AEB216A4CE for ; Tue, 1 Feb 2005 21:20:34 +0000 (GMT) Received: from pimout1-ext.prodigy.net (pimout1-ext.prodigy.net [207.115.63.77]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0883543D2D for ; Tue, 1 Feb 2005 21:20:34 +0000 (GMT) (envelope-from julian@elischer.org) Received: from [192.168.1.102] (adsl-216-100-134-143.dsl.snfc21.pacbell.net [216.100.134.143])j11LKGGS282548; Tue, 1 Feb 2005 16:20:21 -0500 Date: Tue, 1 Feb 2005 13:20:15 -0800 (PST) From: Julian Elischer X-X-Sender: julian@localhost To: Peter Jeremy In-Reply-To: <20050201190318.GE45608@cirb503493.alcatel.com.au> Message-ID: <20050201130340.D92335@localhost> References: <20050201101113.J572@localhost> <20050201190318.GE45608@cirb503493.alcatel.com.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: current@freebsd.org Subject: Re: cynchronised sleep capbilty.. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2005 21:20:34 -0000 On Wed, 2 Feb 2005, Peter Jeremy wrote: > On Tue, 2005-Feb-01 10:20:24 -0800, Julian Elischer wrote: > >while: > >do > > report results > > sleep -until_next 10 > >done > > How about: > 1) Re-write the loop in C, perl or equivalent using setitimer(). You > can system() out to collect the results. > 2) Write a small C program that uses setitimer() and signals > its parent whenever the timer triggers. Run it in the background > and just pause within the sh loop. > > this is what I ended up doing.. # like sleep 10 except that it phase locks to teh 10 second boundary # so that multiple machines are talking about the same sample period. sync10 () { local SEC NEWSEC set `date +"%S"` SEC=$1 case $SEC in ?[012345678]) sleep $((9 - ($SEC % 10))) ;; ?9) ;; esac set `date +"%S"` NEWSEC=$1 while : do # check for overshoot of up to 7 seconds case $NEWSEC in ?[01234567]) return ;; esac sleep 0.1 set `date +"%S"` NEWSEC=$1 done } yeah, gross, but it works and there are tons of spare cycles on these machines :-) -- +------------------------------------+ ______ _ __ | __--_|\ Julian Elischer | \ U \/ / hard at work in | / \ julian@elischer.org +------>x USA \ a very strange | ( OZ ) \___ ___ | country ! +- X_.---._/ presently in San Francisco \_/ \\ v From owner-freebsd-current@FreeBSD.ORG Tue Feb 1 22:44:39 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 23A9616A4CE for ; Tue, 1 Feb 2005 22:44:39 +0000 (GMT) Received: from dmz2.unixjunkie.com (adsl-65-70-175-249.dsl.rcsntx.swbell.net [65.70.175.249]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1259C43D2F for ; Tue, 1 Feb 2005 22:44:38 +0000 (GMT) (envelope-from strgout@unixjunkie.com) Received: from mail.unixjunkie.com (strgout@mail [10.253.254.36]) by dmz2.unixjunkie.com (8.12.8p2/8.12.8) with ESMTP id j11MqGU1045630 for ; Tue, 1 Feb 2005 16:52:16 -0600 (CST) (envelope-from strgout@mail.unixjunkie.com) Received: from mail.unixjunkie.com (strgout@mail [10.253.254.36]) by mail.unixjunkie.com (8.12.8p2/8.12.8) with ESMTP id j11MqFRf045626 for ; Tue, 1 Feb 2005 16:52:15 -0600 (CST) (envelope-from strgout@mail.unixjunkie.com) Received: (from strgout@localhost) by mail.unixjunkie.com (8.12.8p2/8.12.8/Submit) id j11MqFas045625 for freebsd-current@freebsd.org; Tue, 1 Feb 2005 16:52:15 -0600 (CST) (envelope-from strgout) Date: Tue, 1 Feb 2005 16:52:15 -0600 From: John To: freebsd-current@freebsd.org Message-ID: <20050201225215.GA45587@mail.unixjunkie.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: netgraph related crash X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2005 22:44:39 -0000 I was playing around with a 6.0 box i setup (current as of yesterday) and i seem to have triggered a panic. The box panics when i run the following script. It seems to die right when ng_ether is loaded. One thing i noticed is if i boot into single user mode then load the module it may not panic. I think it has something to do with the bge nics not being up. Both bge nics are plugged into 100mbit taps. /usr/local/etc/rc.d/000.ifconfig.ngeth0.sh kldload ng_ether ngctl mkpeer . eiface hook ether ngctl mkpeer ngeth0: one2many lower one ngctl msg bge0: setautosrc 0 ngctl msg bge1: setautosrc 0 ngctl msg ngeth0: setautosrc 0 ngctl connect bge0: ngeth0:lower lower many0 ngctl connect bge1: ngeth0:lower lower many1 ifconfig ngeth0 -arp up btw if anyone wants access to the kernel and dump file let me know where i can send it and i'll upload it, otherwise i'll be more then happy to proxy any commands. gdb6 output ... root@elara# gdb6 -k /usr/obj/usr/src/sys/GENERIC/kernel.debug /var/crash/vmcore .0 GNU gdb 20040810 [GDB v6.x for FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-portbld-freebsd6.0"... panic: from debugger panic messages: --- Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 06 fault virtual address = 0x88 fault code = supervisor read, page not present instruction pointer = 0x8:0xc294c527 stack pointer = 0x10:0xe4d6ec74 frame pointer = 0x10:0xe4d6ec80 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 = 40 (irq29: bge1) panic: from debugger cpuid = 0 Uptime: 23s Dumping 1023 MB 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 3 52 368 384 400 416 432 448 464 480 496 512 528 544 560 576 592 608 624 640 656 6 72 688 704 720 736 752 768 784 800 816 832 848 864 880 896 912 928 944 960 976 9 92 1008 --- #0 doadump () at pcpu.h:159 159 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); doadump () at pcpu.h:159 159 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); (kgdb) where #0 doadump () at pcpu.h:159 #1 0xc06126ac in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:398 #2 0xc06129c1 in panic (fmt=0xc07f0061 "from debugger") at /usr/src/sys/kern/kern_shutdown.c:554 #3 0xc0465ad1 in db_panic (addr=-1030437593, have_addr=0, count=-1, modif=0xe4d6ea98 "") at /usr/src/sys/ddb/db_command.c:435 #4 0xc0465a68 in db_command (last_cmdp=0xc08cb264, cmd_table=0x0, aux_cmd_tablep=0xc084a7c0, aux_cmd_tablep_end=0xc084a7dc) at /usr/src/sys/ddb/db_command.c:349 #5 0xc0465b30 in db_command_loop () at /usr/src/sys/ddb/db_command.c:455 #6 0xc04676b5 in db_trap (type=12, code=0) at /usr/src/sys/ddb/db_main.c:221 #7 0xc062a644 in kdb_trap (type=12, code=0, tf=0xe4d6ec34) at /usr/src/sys/kern/subr_kdb.c:421 #8 0xc07bba65 in trap_fatal (frame=0xe4d6ec34, eva=136) at /usr/src/sys/i386/i386/trap.c:801 #9 0xc07bb7c3 in trap_pfault (frame=0xe4d6ec34, usermode=0, eva=136) at /usr/src/sys/i386/i386/trap.c:724 #10 0xc07bb409 in trap (frame= {tf_fs = -1067253736, tf_es = -1064435696, tf_ds = 16, tf_edi = -103552204 8, tf_esi = -1035522048, tf_ebp = -455676800, tf_isp = -455676832, tf_ebx = 0, t f_edx = -1031742976, tf_ecx = 1394, tf_eax = -1035522048, tf_trapno = 12, tf_err = 0, tf_eip = -1030437593, tf_cs = 8, tf_eflags = 66182, tf_esp = -1031600128, tf_ss = -1035522048}) at /usr/src/sys/i386/i386/trap.c:414 #11 0xc07a99aa in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #12 0xc0630018 in sleepq_signal (wchan=0xc2473000, flags=-455676764, pri=-1035521448) at /usr/src/sys/kern/subr_sleepqueue.c:696 #13 0xc06784ce in ether_input (ifp=0xc2473000, m=0xc280da00) at /usr/src/sys/net/if_ethersubr.c:564 #14 0xc04e0bab in bge_rxeof (sc=0xc2473000) at /usr/src/sys/dev/bge/if_bge.c:2813 #15 0xc04e0ee0 in bge_intr (xsc=0xc2473000) at /usr/src/sys/dev/bge/if_bge.c:2975 #16 0xc0600a6c in ithread_loop (arg=0xc229be80) at /usr/src/sys/kern/kern_intr.c:546 #17 0xc05ffe98 in fork_exit (callout=0xc060094c , arg=0xc229be80, frame=0xe4d6ed48) at /usr/src/sys/kern/kern_fork.c:790 #18 0xc07a9a0c in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:208 (kgdb) From owner-freebsd-current@FreeBSD.ORG Wed Feb 2 00:06:15 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0F44516A4CE for ; Wed, 2 Feb 2005 00:06:15 +0000 (GMT) Received: from obsecurity.dyndns.org (CPE0050040655c8-CM00111ae02aac.cpe.net.cable.rogers.com [69.199.47.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id C04B743D2F for ; Wed, 2 Feb 2005 00:06:14 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id D770751471; Tue, 1 Feb 2005 16:06:13 -0800 (PST) Date: Tue, 1 Feb 2005 16:06:13 -0800 From: Kris Kennaway To: Peter Holm Message-ID: <20050202000613.GA9758@xor.obsecurity.org> References: <20050130094616.GA76093@peter.osted.lan> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="17pEHd4RhPHOinZp" Content-Disposition: inline In-Reply-To: <20050130094616.GA76093@peter.osted.lan> User-Agent: Mutt/1.4.2.1i cc: jroberson@chesapeake.net cc: current@freebsd.org Subject: Re: Panic: Memory modified after free X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2005 00:06:15 -0000 --17pEHd4RhPHOinZp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jan 30, 2005 at 10:46:16AM +0100, Peter Holm wrote: > With GENERIC HEAD from Jan 28 20:19 UTC + mpsafe_vfs =3D 1 I got: >=20 > Memory modified after free 0xc1d7c100(124) val=3Dc23fa000 @ 0xc1d7c164 >=20 > panic(c083d005,c083b16e,c083cfd6,c1d7c100,7c) at panic+0xef > mtrash_ctor(c1d7c100,80,0,402) at mtrash_ctor+0x4d > uma_zalloc_arg(c10526e0,0,402) at uma_zalloc_arg+0x14c > malloc(68,c08bcd60,402,c094f0c0,0) at malloc+0xae > inodedep_lookup(c167a000,193a1,1,cf261be0,c094f0c0) at inodedep_lookup+0x= a7 > softdep_change_linkcnt(c213b578,c6bc54f0,c65f3f88,c213b578,c1c39270) at s= oftdep_change_linkcnt+0x31 > ufs_dirremove(c17d83a8,c213b578,100800c,0,cf261c48) at ufs_dirremove+0x12d > ufs_remove(cf261c4c) at ufs_remove+0x4b > VOP_REMOVE_AP(cf261c4c) at VOP_REMOVE_AP+0x62 > kern_unlink(c1add2e0,bfbfe940,0,cf261d40,c07bd6c3) at kern_unlink+0x167 > unlink(c1add2e0,cf261d14,1,28,292) at unlink+0x12 > syscall(2804002f,bfbf002f,bfbf002f,2804f6c0,bfbfeb14) at syscall+0x213 >=20 > More info at http://www.holm.cc/stress/log/cons112.html > panic: Most recently used by inodedep You can try to use DEBUG_MEMGUARD with M_INODEDEP to find this. I'll add that to my SMP package machines to see if I can trigger it too. Kris --17pEHd4RhPHOinZp Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCABl1Wry0BWjoQKURAo86AJwOi4YsNsThOjZL64aJBRcXtW1oJQCbBkXn caMc1rriaJ31QGoInhYyIqE= =hZUh -----END PGP SIGNATURE----- --17pEHd4RhPHOinZp-- From owner-freebsd-current@FreeBSD.ORG Wed Feb 2 00:12:31 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4646916A4CE; Wed, 2 Feb 2005 00:12:31 +0000 (GMT) Received: from obsecurity.dyndns.org (CPE0050040655c8-CM00111ae02aac.cpe.net.cable.rogers.com [69.199.47.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 050D443D49; Wed, 2 Feb 2005 00:12:31 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 32139519EC; Tue, 1 Feb 2005 16:12:30 -0800 (PST) Date: Tue, 1 Feb 2005 16:12:30 -0800 From: Kris Kennaway To: Kris Kennaway Message-ID: <20050202001230.GA21847@xor.obsecurity.org> References: <20050130094616.GA76093@peter.osted.lan> <20050202000613.GA9758@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5vNYLRcllDrimb99" Content-Disposition: inline In-Reply-To: <20050202000613.GA9758@xor.obsecurity.org> User-Agent: Mutt/1.4.2.1i cc: current@freebsd.org cc: bmilekic@FreeBSD.org cc: jroberson@chesapeake.net Subject: Re: Panic: Memory modified after free X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2005 00:12:31 -0000 --5vNYLRcllDrimb99 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Feb 01, 2005 at 04:06:13PM -0800, Kris Kennaway wrote: > On Sun, Jan 30, 2005 at 10:46:16AM +0100, Peter Holm wrote: > > With GENERIC HEAD from Jan 28 20:19 UTC + mpsafe_vfs =3D 1 I got: > >=20 > > Memory modified after free 0xc1d7c100(124) val=3Dc23fa000 @ 0xc1d7c164 > >=20 > > panic(c083d005,c083b16e,c083cfd6,c1d7c100,7c) at panic+0xef > > mtrash_ctor(c1d7c100,80,0,402) at mtrash_ctor+0x4d > > uma_zalloc_arg(c10526e0,0,402) at uma_zalloc_arg+0x14c > > malloc(68,c08bcd60,402,c094f0c0,0) at malloc+0xae > > inodedep_lookup(c167a000,193a1,1,cf261be0,c094f0c0) at inodedep_lookup+= 0xa7 > > softdep_change_linkcnt(c213b578,c6bc54f0,c65f3f88,c213b578,c1c39270) at= softdep_change_linkcnt+0x31 > > ufs_dirremove(c17d83a8,c213b578,100800c,0,cf261c48) at ufs_dirremove+0x= 12d > > ufs_remove(cf261c4c) at ufs_remove+0x4b > > VOP_REMOVE_AP(cf261c4c) at VOP_REMOVE_AP+0x62 > > kern_unlink(c1add2e0,bfbfe940,0,cf261d40,c07bd6c3) at kern_unlink+0x167 > > unlink(c1add2e0,cf261d14,1,28,292) at unlink+0x12 > > syscall(2804002f,bfbf002f,bfbf002f,2804f6c0,bfbfeb14) at syscall+0x213 > >=20 > > More info at http://www.holm.cc/stress/log/cons112.html >=20 > > panic: Most recently used by inodedep >=20 > You can try to use DEBUG_MEMGUARD with M_INODEDEP to find this. I'll > add that to my SMP package machines to see if I can trigger it too. Well, that didn't work: panic: MEMGUARD: Cannot handle objects > PAGE_SIZE CC'ing Bosko, the memguard author. Kris --5vNYLRcllDrimb99 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCABrtWry0BWjoQKURAvPZAJ4gNR5IUTv3w9O7XShoI2+w9y5EHgCgn0cZ fyrB4nC2A3uaOxtHs2YfJrI= =SL4U -----END PGP SIGNATURE----- --5vNYLRcllDrimb99-- From owner-freebsd-current@FreeBSD.ORG Wed Feb 2 01:12:04 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E7D0F16A4CE; Wed, 2 Feb 2005 01:12:04 +0000 (GMT) Received: from stephanie.unixdaemons.com (stephanie.unixdaemons.com [67.18.111.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 643A743D2D; Wed, 2 Feb 2005 01:12:04 +0000 (GMT) (envelope-from bmilekic@technokratis.com) Received: from stephanie.unixdaemons.com (bmilekic@localhost.unixdaemons.com [127.0.0.1])j121Bvrx056411; Tue, 1 Feb 2005 20:11:57 -0500 (EST) Received: (from bmilekic@localhost) by stephanie.unixdaemons.com (8.13.2/8.12.1/Submit) id j121Bvvp056410; Tue, 1 Feb 2005 20:11:57 -0500 (EST) (envelope-from bmilekic@technokratis.com) X-Authentication-Warning: stephanie.unixdaemons.com: bmilekic set sender to bmilekic@technokratis.com using -f Date: Tue, 1 Feb 2005 20:11:57 -0500 From: Bosko Milekic To: Kris Kennaway Message-ID: <20050202011157.GA55803@technokratis.com> References: <20050130094616.GA76093@peter.osted.lan> <20050202000613.GA9758@xor.obsecurity.org> <20050202001230.GA21847@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="NMuMz9nt05w80d4+" Content-Disposition: inline In-Reply-To: <20050202001230.GA21847@xor.obsecurity.org> User-Agent: Mutt/1.4.2.1i cc: jroberson@chesapeake.net cc: current@freebsd.org cc: bmilekic@freebsd.org Subject: Re: Panic: Memory modified after free X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2005 01:12:05 -0000 --NMuMz9nt05w80d4+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I made the attached patch for scottl to allow for > PAGE_SIZE allocations, please feel free to try it as I don't think he has had a chance to yet. -Bosko On Tue, Feb 01, 2005 at 04:12:30PM -0800, Kris Kennaway wrote: > On Tue, Feb 01, 2005 at 04:06:13PM -0800, Kris Kennaway wrote: > > On Sun, Jan 30, 2005 at 10:46:16AM +0100, Peter Holm wrote: > > > With GENERIC HEAD from Jan 28 20:19 UTC + mpsafe_vfs = 1 I got: > > > > > > Memory modified after free 0xc1d7c100(124) val=c23fa000 @ 0xc1d7c164 > > > > > > panic(c083d005,c083b16e,c083cfd6,c1d7c100,7c) at panic+0xef > > > mtrash_ctor(c1d7c100,80,0,402) at mtrash_ctor+0x4d > > > uma_zalloc_arg(c10526e0,0,402) at uma_zalloc_arg+0x14c > > > malloc(68,c08bcd60,402,c094f0c0,0) at malloc+0xae > > > inodedep_lookup(c167a000,193a1,1,cf261be0,c094f0c0) at inodedep_lookup+0xa7 > > > softdep_change_linkcnt(c213b578,c6bc54f0,c65f3f88,c213b578,c1c39270) at softdep_change_linkcnt+0x31 > > > ufs_dirremove(c17d83a8,c213b578,100800c,0,cf261c48) at ufs_dirremove+0x12d > > > ufs_remove(cf261c4c) at ufs_remove+0x4b > > > VOP_REMOVE_AP(cf261c4c) at VOP_REMOVE_AP+0x62 > > > kern_unlink(c1add2e0,bfbfe940,0,cf261d40,c07bd6c3) at kern_unlink+0x167 > > > unlink(c1add2e0,cf261d14,1,28,292) at unlink+0x12 > > > syscall(2804002f,bfbf002f,bfbf002f,2804f6c0,bfbfeb14) at syscall+0x213 > > > > > > More info at http://www.holm.cc/stress/log/cons112.html > > > > > panic: Most recently used by inodedep > > > > You can try to use DEBUG_MEMGUARD with M_INODEDEP to find this. I'll > > add that to my SMP package machines to see if I can trigger it too. > > Well, that didn't work: > > panic: MEMGUARD: Cannot handle objects > PAGE_SIZE > > CC'ing Bosko, the memguard author. > > Kris > > -- Bosko Milekic bmilekic@technokratis.com bmilekic@FreeBSD.org --NMuMz9nt05w80d4+ Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="mg_scottl.diff" Index: src/sys/vm/memguard.c =================================================================== RCS file: /home/ncvs/src/sys/vm/memguard.c,v retrieving revision 1.1 diff -u -r1.1 memguard.c --- src/sys/vm/memguard.c 21 Jan 2005 18:09:17 -0000 1.1 +++ src/sys/vm/memguard.c 21 Jan 2005 21:21:38 -0000 @@ -52,6 +52,13 @@ #include /* + * The maximum number of pages allowed per allocation. If you're using + * MemGuard to override very large items (> MAX_PAGES_PER_ITEM in size), + * you need to increase MAX_PAGES_PER_ITEM. + */ +#define MAX_PAGES_PER_ITEM 10 + +/* * Global MemGuard data. */ static vm_map_t memguard_map; @@ -61,13 +68,20 @@ STAILQ_ENTRY(memguard_entry) entries; void *ptr; }; -static STAILQ_HEAD(memguard_fifo, memguard_entry) memguard_fifo_pool; +static struct memguard_fifo { + struct memguard_entry *stqh_first; + struct memguard_entry **stqh_last; + int index; +} memguard_fifo_pool[MAX_PAGES_PER_ITEM]; /* * Local prototypes. */ -static void memguard_guard(void *addr); -static void memguard_unguard(void *addr); +static void memguard_guard(void *addr, int numpgs); +static void memguard_unguard(void *addr, int numpgs); +static struct memguard_fifo *vtomgfifo(vm_offset_t va); +static void vsetmgfifo(vm_offset_t va, struct memguard_fifo *mgfifo); +static void vclrmgfifo(vm_offset_t va); /* * Local macros. MemGuard data is global, so replace these with whatever @@ -89,6 +103,7 @@ memguard_init(vm_map_t parent_map, unsigned long size) { char *base, *limit; + int i; /* size must be multiple of PAGE_SIZE */ size /= PAGE_SIZE; @@ -103,7 +118,10 @@ MEMGUARD_CRIT_SECTION_INIT; MEMGUARD_CRIT_SECTION_ENTER; - STAILQ_INIT(&memguard_fifo_pool); + for (i = 0; i < MAX_PAGES_PER_ITEM; i++) { + STAILQ_INIT(&memguard_fifo_pool[i]); + memguard_fifo_pool[i].index = i; + } MEMGUARD_CRIT_SECTION_EXIT; printf("MEMGUARD DEBUGGING ALLOCATOR INITIALIZED:\n"); @@ -121,10 +139,11 @@ { void *obj = NULL; struct memguard_entry *e = NULL; + int i; - /* XXX: MemGuard does not handle > PAGE_SIZE objects. */ - if (size > PAGE_SIZE) - panic("MEMGUARD: Cannot handle objects > PAGE_SIZE"); + i = size / PAGE_SIZE; + if (i >= MAX_PAGES_PER_ITEM) + panic("MEMGUARD: You must increase MAX_PAGES_PER_ITEM"); /* * If we haven't exhausted the memguard_map yet, allocate from @@ -137,16 +156,17 @@ */ MEMGUARD_CRIT_SECTION_ENTER; if (memguard_mapused >= memguard_mapsize) { - e = STAILQ_FIRST(&memguard_fifo_pool); + e = STAILQ_FIRST(&memguard_fifo_pool[i]); if (e != NULL) { - STAILQ_REMOVE(&memguard_fifo_pool, e, + STAILQ_REMOVE(&memguard_fifo_pool[i], e, memguard_entry, entries); MEMGUARD_CRIT_SECTION_EXIT; obj = e->ptr; free(e, M_TEMP); - memguard_unguard(obj); + memguard_unguard(obj, i+1); if (flags & M_ZERO) - bzero(obj, PAGE_SIZE); + bzero(obj, PAGE_SIZE * (i+1)); + vsetmgfifo((vm_offset_t)obj, &memguard_fifo_pool[i]); return obj; } MEMGUARD_CRIT_SECTION_EXIT; @@ -155,18 +175,19 @@ "memguard_map too small"); return NULL; } else - memguard_mapused += PAGE_SIZE; + memguard_mapused += (PAGE_SIZE * (i+1)); MEMGUARD_CRIT_SECTION_EXIT; if (obj == NULL) - obj = (void *)kmem_malloc(memguard_map, PAGE_SIZE, flags); + obj = (void *)kmem_malloc(memguard_map, PAGE_SIZE * (i+1), flags); if (obj != NULL) { - memguard_unguard(obj); + memguard_unguard(obj, i+1); + vsetmgfifo((vm_offset_t)obj, &memguard_fifo_pool[i]); if (flags & M_ZERO) - bzero(obj, PAGE_SIZE); + bzero(obj, PAGE_SIZE * (i+1)); } else { MEMGUARD_CRIT_SECTION_ENTER; - memguard_mapused -= PAGE_SIZE; + memguard_mapused -= (PAGE_SIZE * (i+1)); MEMGUARD_CRIT_SECTION_EXIT; } return obj; @@ -179,20 +200,25 @@ memguard_free(void *addr) { struct memguard_entry *e; + struct memguard_fifo *mgfifo; + int idx; - memguard_guard(addr); + mgfifo = vtomgfifo((vm_offset_t)addr); + idx = mgfifo->index; + memguard_guard(addr, idx + 1); + vclrmgfifo((vm_offset_t)addr); e = malloc(sizeof(struct memguard_entry), M_TEMP, M_NOWAIT); if (e == NULL) { MEMGUARD_CRIT_SECTION_ENTER; - memguard_mapused -= PAGE_SIZE; + memguard_mapused -= (PAGE_SIZE * (idx+1)); MEMGUARD_CRIT_SECTION_EXIT; kmem_free(memguard_map, (vm_offset_t)round_page( - (unsigned long)addr), PAGE_SIZE); + (unsigned long)addr), PAGE_SIZE * (idx+1)); return; } e->ptr = (void *)round_page((unsigned long)addr); MEMGUARD_CRIT_SECTION_ENTER; - STAILQ_INSERT_TAIL(&memguard_fifo_pool, e, entries); + STAILQ_INSERT_TAIL(mgfifo, e, entries); MEMGUARD_CRIT_SECTION_EXIT; } @@ -201,11 +227,12 @@ * future writes to it fail). */ static void -memguard_guard(void *addr) +memguard_guard(void *addr, int numpgs) { void *a = (void *)round_page((unsigned long)addr); (void)vm_map_protect(memguard_map, (vm_offset_t)a, - (vm_offset_t)((unsigned long)a + PAGE_SIZE), VM_PROT_READ, 0); + (vm_offset_t)((unsigned long)a + (PAGE_SIZE * numpgs)), + VM_PROT_READ, 0); } /* @@ -213,10 +240,63 @@ * allow full data access). */ static void -memguard_unguard(void *addr) +memguard_unguard(void *addr, int numpgs) { void *a = (void *)round_page((unsigned long)addr); (void)vm_map_protect(memguard_map, (vm_offset_t)a, - (vm_offset_t)((unsigned long)a + PAGE_SIZE), + (vm_offset_t)((unsigned long)a + (PAGE_SIZE * numpgs)), VM_PROT_READ | VM_PROT_WRITE, 0); } + +/* + * vtomgfifo() converts a virtual address of the first page allocated for + * an item to a memguard_fifo_pool reference for the corresponding item's + * size. + * + * vsetmgfifo() sets a reference in an underlying page for the specified + * virtual address to an appropriate memguard_fifo_pool. + * + * These routines are very similar to those defined by UMA in uma_int.h + */ +static struct memguard_fifo * +vtomgfifo(vm_offset_t va) +{ + vm_page_t p; + struct memguard_fifo *mgfifo; + + p = PHYS_TO_VM_PAGE(pmap_kextract(va)); + mgfifo = (struct memguard_fifo *)p->object; + + /* + * We use PG_SLAB, just like UMA does, even though we stash + * a reference to a memguard_fifo, and not a slab. + */ + if ((p->flags & PG_SLAB) == 0) + panic("MEMGUARD: Expected memguard_fifo reference to be set!"); + return mgfifo; +} + +static void +vsetmgfifo(vm_offset_t va, struct memguard_fifo *mgfifo) +{ + vm_page_t p; + + p = PHYS_TO_VM_PAGE(pmap_kextract(va)); + p->object = (vm_object_t)mgfifo; + /* + * We use PG_SLAB, just like UMA does, even though we stash + * a reference to a memguard_fifo, and not a slab. + */ + p->flags |= PG_SLAB; +} + +static void +vclrmgfifo(vm_offset_t va) +{ + vm_page_t p; + + p = PHYS_TO_VM_PAGE(pmap_kextract(va)); + p->object = NULL; + p->flags &= ~PG_SLAB; +} + --NMuMz9nt05w80d4+-- From owner-freebsd-current@FreeBSD.ORG Wed Feb 2 02:30:34 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E3CE016A4CE; Wed, 2 Feb 2005 02:30:34 +0000 (GMT) Received: from obsecurity.dyndns.org (CPE0050040655c8-CM00111ae02aac.cpe.net.cable.rogers.com [69.199.47.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9C7E043D53; Wed, 2 Feb 2005 02:30:34 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 526545129C; Tue, 1 Feb 2005 18:30:33 -0800 (PST) Date: Tue, 1 Feb 2005 18:30:33 -0800 From: Kris Kennaway To: Bosko Milekic Message-ID: <20050202023033.GA53440@xor.obsecurity.org> References: <20050130094616.GA76093@peter.osted.lan> <20050202000613.GA9758@xor.obsecurity.org> <20050202001230.GA21847@xor.obsecurity.org> <20050202011157.GA55803@technokratis.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="bp/iNruPH9dso1Pn" Content-Disposition: inline In-Reply-To: <20050202011157.GA55803@technokratis.com> User-Agent: Mutt/1.4.2.1i cc: bmilekic@freebsd.org cc: jroberson@chesapeake.net cc: current@freebsd.org cc: Kris Kennaway Subject: Re: Panic: Memory modified after free X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2005 02:30:35 -0000 --bp/iNruPH9dso1Pn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Feb 01, 2005 at 08:11:57PM -0500, Bosko Milekic wrote: >=20 > I made the attached patch for scottl to allow for > PAGE_SIZE > allocations, please feel free to try it as I don't think he has had a > chance to yet. I had to apply part of the patch by hand, and increase MAX_PAGES_PER_ITEM to 128 to deal with M_INODEDEP allocations (well, it was asking for at least 64 pages worth, so this may have been a factor of 2 overkill). I don't know if this is correct - it seems like a lot of memory to be allocating since all of the allocations I could see seem to be for only a single copy of struct inodedep, which is nowhere near that big. Anyway, it panicked shortly after starting to exercise the FS, with: login: panic: mutex not owned at ../../../vm/vm_page.c:301 cpuid =3D 1 KDB: enter: panic [thread pid 717 tid 100147 ] Stopped at kdb_enter+0x30: leave db> tr Tracing pid 717 tid 100147 td 0xc7f27a10 kdb_enter(c06fbf7a,1,c06fb4a2,eeca0968,c7f27a10) at kdb_enter+0x30 panic(c06fb4a2,c82cb120,c071204f,12d,c46bae28) at panic+0x13e _mtx_assert(c07c4ac0,1,c071204f,12d,ffffffe2) at _mtx_assert+0x7c vm_page_busy(c46bae28,0,c0710c9d,155,eeca0a2c) at vm_page_busy+0x2d vm_fault(c1059000,c566a000,2,0,c7f27a10) at vm_fault+0x6c3 trap_pfault(eeca0b04,0,c566a008,eeca0af4,c566a008) at trap_pfault+0x166 trap(c0510018,c07c0010,10,c81c0800,c563638c) at trap+0x34c calltrap() at calltrap+0x5 --- trap 0xc, eip =3D 0xc063af4a, esp =3D 0xeeca0b44, ebp =3D 0xeeca0b60 --- inodedep_lookup(c81c0800,180803,1,eeca0b78,0) at inodedep_lookup+0x143 softdep_change_linkcnt(c8c99000,e0ccd600,4600,eeca0b9c,eeca0ba0) at softdep= _change_linkcnt+0x4f ufs_dirremove(c8b0b4e0,c8c99000,100800c,0,0) at ufs_dirremove+0x153 ufs_remove(eeca0c2c,c071c05e,2ac,c071c662,c8b0b4e0) at ufs_remove+0x60 VOP_REMOVE_AP(eeca0c2c,eeca0c28,2,c06fdcb8,c81b7400) at VOP_REMOVE_AP+0x78 kern_unlink(c7f27a10,80636a8,0,eeca0d40,c06b9eb6) at kern_unlink+0x186 unlink(c7f27a10,eeca0d14,3a6,c07184c4,c7f27a10) at unlink+0x22 syscall(2f,804002f,bfbf002f,1,804d000) at syscall+0x2c4 Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (10, FreeBSD ELF32, unlink), eip =3D 0x280c5b63, esp =3D 0xbfbf= ec2c, ebp =3D 0xbfbfec58 --- I don't know if this is a memguard bug or a FreeBSD bug. Kris --bp/iNruPH9dso1Pn Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCADtIWry0BWjoQKURApKBAKC/0WvUyHstkf16EG1RqHRMIcf36ACfX0zw 5uUlgngEkNLjqnSM2wekUos= =0N9O -----END PGP SIGNATURE----- --bp/iNruPH9dso1Pn-- From owner-freebsd-current@FreeBSD.ORG Wed Feb 2 03:11:09 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 95B4E16A4CE; Wed, 2 Feb 2005 03:11:09 +0000 (GMT) Received: from obsecurity.dyndns.org (CPE0050040655c8-CM00111ae02aac.cpe.net.cable.rogers.com [69.199.47.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id ECC6543D2F; Wed, 2 Feb 2005 03:11:08 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id A86675129C; Tue, 1 Feb 2005 19:11:07 -0800 (PST) Date: Tue, 1 Feb 2005 19:11:07 -0800 From: Kris Kennaway To: Kris Kennaway Message-ID: <20050202031107.GA67234@xor.obsecurity.org> References: <20050130094616.GA76093@peter.osted.lan> <20050202000613.GA9758@xor.obsecurity.org> <20050202001230.GA21847@xor.obsecurity.org> <20050202011157.GA55803@technokratis.com> <20050202023033.GA53440@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="17pEHd4RhPHOinZp" Content-Disposition: inline In-Reply-To: <20050202023033.GA53440@xor.obsecurity.org> User-Agent: Mutt/1.4.2.1i cc: bmilekic@freebsd.org cc: jroberson@chesapeake.net cc: Bosko Milekic cc: current@freebsd.org Subject: Re: Panic: Memory modified after free X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2005 03:11:09 -0000 --17pEHd4RhPHOinZp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Feb 01, 2005 at 06:30:33PM -0800, Kris Kennaway wrote: > On Tue, Feb 01, 2005 at 08:11:57PM -0500, Bosko Milekic wrote: > >=20 > > I made the attached patch for scottl to allow for > PAGE_SIZE > > allocations, please feel free to try it as I don't think he has had a > > chance to yet. >=20 > I had to apply part of the patch by hand, and increase > MAX_PAGES_PER_ITEM to 128 to deal with M_INODEDEP allocations (well, > it was asking for at least 64 pages worth, so this may have been a > factor of 2 overkill). I don't know if this is correct - it seems > like a lot of memory to be allocating since all of the allocations I > could see seem to be for only a single copy of struct inodedep, which > is nowhere near that big. >=20 > Anyway, it panicked shortly after starting to exercise the FS, with: >=20 > login: panic: mutex not owned at ../../../vm/vm_page.c:301 > cpuid =3D 1 > KDB: enter: panic > [thread pid 717 tid 100147 ] > Stopped at kdb_enter+0x30: leave > db> tr > Tracing pid 717 tid 100147 td 0xc7f27a10 > kdb_enter(c06fbf7a,1,c06fb4a2,eeca0968,c7f27a10) at kdb_enter+0x30 > panic(c06fb4a2,c82cb120,c071204f,12d,c46bae28) at panic+0x13e =46rom another copy of the same panic: panic(c06fb4a2,c81a9c10,c071204f,12d,c46b8a28) at panic+0x13e > 0xc81a9c00: c81a9c10 c5acb000 deadc0de c073a160 > 0xc81a9c10: 0 c62df000 deadc0de c073c560 > 0xc81a9c20: c82cc110 c5acf000 deadc0de c073a160 > 0xc81a9c30: deadc0de deadc0de deadc0de c073c560 > 0xc81a9c40: deadc0de deadc0de deadc0de c073a160 It looks like the vm object has been freed? Kris > _mtx_assert(c07c4ac0,1,c071204f,12d,ffffffe2) at _mtx_assert+0x7c > vm_page_busy(c46bae28,0,c0710c9d,155,eeca0a2c) at vm_page_busy+0x2d > vm_fault(c1059000,c566a000,2,0,c7f27a10) at vm_fault+0x6c3 > trap_pfault(eeca0b04,0,c566a008,eeca0af4,c566a008) at trap_pfault+0x166 > trap(c0510018,c07c0010,10,c81c0800,c563638c) at trap+0x34c > calltrap() at calltrap+0x5 > --- trap 0xc, eip =3D 0xc063af4a, esp =3D 0xeeca0b44, ebp =3D 0xeeca0b60 = --- > inodedep_lookup(c81c0800,180803,1,eeca0b78,0) at inodedep_lookup+0x143 > softdep_change_linkcnt(c8c99000,e0ccd600,4600,eeca0b9c,eeca0ba0) at softd= ep_change_linkcnt+0x4f > ufs_dirremove(c8b0b4e0,c8c99000,100800c,0,0) at ufs_dirremove+0x153 > ufs_remove(eeca0c2c,c071c05e,2ac,c071c662,c8b0b4e0) at ufs_remove+0x60 > VOP_REMOVE_AP(eeca0c2c,eeca0c28,2,c06fdcb8,c81b7400) at VOP_REMOVE_AP+0x78 > kern_unlink(c7f27a10,80636a8,0,eeca0d40,c06b9eb6) at kern_unlink+0x186 > unlink(c7f27a10,eeca0d14,3a6,c07184c4,c7f27a10) at unlink+0x22 > syscall(2f,804002f,bfbf002f,1,804d000) at syscall+0x2c4 > Xint0x80_syscall() at Xint0x80_syscall+0x1f > --- syscall (10, FreeBSD ELF32, unlink), eip =3D 0x280c5b63, esp =3D 0xbf= bfec2c, ebp =3D 0xbfbfec58 --- >=20 > I don't know if this is a memguard bug or a FreeBSD bug. >=20 > Kris --17pEHd4RhPHOinZp Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCAETLWry0BWjoQKURAjqIAKCVGyo7QriPvIUrj3a/OOK+y3j/jgCfdDaz 2vEVW/lm91ET9bAAD5l+ZCU= =oVBE -----END PGP SIGNATURE----- --17pEHd4RhPHOinZp-- From owner-freebsd-current@FreeBSD.ORG Wed Feb 2 06:03:16 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9392916A4CE for ; Wed, 2 Feb 2005 06:03:16 +0000 (GMT) Received: from imail2.gazeta.pl (host-193-42-231-144.gazeta.pl [193.42.231.144]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6215C43D1F for ; Wed, 2 Feb 2005 06:03:15 +0000 (GMT) (envelope-from z.jaskiewicz@gazeta.pl) Received: from poczta.gazeta.pl (unverified [194.149.231.60]) by (imail2.gazeta.pl) with ESMTP id 13607843 for ; Wed, 02 Feb 2005 07:03:10 +0300 Received: from Bolek (unverified [62.29.144.151]) by mailis01.gazeta.pl (mailis01.gazeta.pl) with ESMTP id 2332752 for ; Wed, 02 Feb 2005 07:03:09 +0100 Message-ID: <000001c508ec$ea0dbc80$97901d3e@ols.vectranet.pl> From: =?iso-8859-2?Q?Ja=B6kiewicz_Zbigniew?= To: Date: Mon, 31 Jan 2005 12:40:17 +0100 MIME-Version: 1.0 X-Unsent: 1 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-IP-stats: Incoming Outgoing Last 0, First 68, in=2905666, out=319, spam=0 Known=true X-External-IP: 194.149.231.60 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: searching Host Controller X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2005 06:03:16 -0000 I need Intel 82801DB/DBM USB2 Enhanced Host Controller - 24CD. Please help me From owner-freebsd-current@FreeBSD.ORG Wed Feb 2 08:31:35 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B148816A4CE for ; Wed, 2 Feb 2005 08:31:35 +0000 (GMT) Received: from av5-2-sn3.vrr.skanova.net (av5-2-sn3.vrr.skanova.net [81.228.9.114]) by mx1.FreeBSD.org (Postfix) with ESMTP id B267E43D41 for ; Wed, 2 Feb 2005 08:31:34 +0000 (GMT) (envelope-from lothrandil@n00b.apagnu.se) Received: by av5-2-sn3.vrr.skanova.net (Postfix, from userid 502) id 89D2337E55; Wed, 2 Feb 2005 09:31:33 +0100 (CET) Received: from smtp1-2-sn3.vrr.skanova.net (smtp1-2-sn3.vrr.skanova.net [81.228.9.178]) by av5-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 751AC37E42 for ; Wed, 2 Feb 2005 09:31:33 +0100 (CET) Received: from [217.208.32.55] (h55n2fls31o926.telia.com [217.208.32.55]) by smtp1-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 42B2C38026 for ; Wed, 2 Feb 2005 09:31:30 +0100 (CET) Message-ID: <42008FDC.6050400@n00b.apagnu.se> Date: Wed, 02 Feb 2005 09:31:24 +0100 From: Niclas Zeising User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: unmount of /dev failed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2005 08:31:35 -0000 Hi! I am using current as of yesterday (20050201) morning CET (around 0800 i think). When I shutdown or reboot my system (shutdown -[h,r] now) it runs through the shut down sequence as usual, but right before it is rebooting or the message about the shutdown complete comes up, when unmouning dev, it complains about "unmount of /dev failed (BUSY)" before shutting down as usual. Is this a bug, and if so, common or known? Or am I just being stupid somewhere and all is my fault? Just let me know if I need to provide more information. Cheers! //Niclas -- From owner-freebsd-current@FreeBSD.ORG Wed Feb 2 08:49:58 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AB97D16A4CE for ; Wed, 2 Feb 2005 08:49:58 +0000 (GMT) Received: from neo.redjade.org (neo.redjade.org [219.254.21.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id DF5DD43D48 for ; Wed, 2 Feb 2005 08:49:56 +0000 (GMT) (envelope-from ssw@neo.redjade.org) Received: from neo.redjade.org (localhost [127.0.0.1]) by neo.redjade.org (8.13.1/8.13.1) with ESMTP id j128ns39021566; Wed, 2 Feb 2005 17:49:54 +0900 (KST) (envelope-from ssw@neo.redjade.org) Received: (from ssw@localhost) by neo.redjade.org (8.13.1/8.13.1/Submit) id j128niFs021565; Wed, 2 Feb 2005 17:49:44 +0900 (KST) (envelope-from ssw) Date: Wed, 2 Feb 2005 17:49:44 +0900 From: Sangwoo Shim To: Niclas Zeising Message-ID: <20050202084944.GB9999@neo.redjade.org> References: <42008FDC.6050400@n00b.apagnu.se> Mime-Version: 1.0 Content-Type: text/plain; charset=euc-kr Content-Disposition: inline In-Reply-To: <42008FDC.6050400@n00b.apagnu.se> User-Agent: Mutt/1.5.4i cc: freebsd-current@freebsd.org Subject: Re: unmount of /dev failed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2005 08:49:58 -0000 On Wed, Feb 02, 2005 at 09:31:24AM +0100, Niclas Zeising wrote: > Hi! > I am using current as of yesterday (20050201) morning CET (around 0800 i > think). When I shutdown or reboot my system (shutdown -[h,r] now) it > runs through the shut down sequence as usual, but right before it is > rebooting or the message about the shutdown complete comes up, when > unmouning dev, it complains about "unmount of /dev failed (BUSY)" before > shutting down as usual. > Is this a bug, and if so, common or known? Or am I just being stupid > somewhere and all is my fault? Just let me know if I need to provide > more information. > Cheers! > //Niclas > -- I also saw this symptom with the exactly same message. ssw:~ $ uname -a FreeBSD ssw.dyndns.org 6.0-CURRENT FreeBSD 6.0-CURRENT #0: Mon Jan 31 22:25:56 KST 2005 root@ssw.dyndns.org:/usr/obj/usr/src/sys/SSW-SMP i386 - Sangwoo Shim From owner-freebsd-current@FreeBSD.ORG Wed Feb 2 08:54:51 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 74C0516A4CE for ; Wed, 2 Feb 2005 08:54:51 +0000 (GMT) Received: from obsecurity.dyndns.org (CPE0050040655c8-CM00111ae02aac.cpe.net.cable.rogers.com [69.199.47.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3F7A243D48 for ; Wed, 2 Feb 2005 08:54:51 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id A0F125129C; Wed, 2 Feb 2005 00:54:50 -0800 (PST) Date: Wed, 2 Feb 2005 00:54:50 -0800 From: Kris Kennaway To: Niclas Zeising Message-ID: <20050202085450.GA49185@xor.obsecurity.org> References: <42008FDC.6050400@n00b.apagnu.se> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HlL+5n6rz5pIUxbD" Content-Disposition: inline In-Reply-To: <42008FDC.6050400@n00b.apagnu.se> User-Agent: Mutt/1.4.2.1i cc: freebsd-current@freebsd.org Subject: Re: unmount of /dev failed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2005 08:54:51 -0000 --HlL+5n6rz5pIUxbD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 02, 2005 at 09:31:24AM +0100, Niclas Zeising wrote: > Hi! > I am using current as of yesterday (20050201) morning CET (around 0800 i= =20 > think). When I shutdown or reboot my system (shutdown -[h,r] now) it=20 > runs through the shut down sequence as usual, but right before it is=20 > rebooting or the message about the shutdown complete comes up, when=20 > unmouning dev, it complains about "unmount of /dev failed (BUSY)" before= =20 > shutting down as usual. > Is this a bug, and if so, common or known? Or am I just being stupid=20 > somewhere and all is my fault? Just let me know if I need to provide=20 > more information. AFAIK it's harmless. Kris --HlL+5n6rz5pIUxbD Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCAJVaWry0BWjoQKURAqLtAKDusFhZlwPf1mpOr6LvMW7Qg6+HSACgk1o9 1zWxNCKvZQAZIieeiQ7KuFU= =/4f4 -----END PGP SIGNATURE----- --HlL+5n6rz5pIUxbD-- From owner-freebsd-current@FreeBSD.ORG Wed Feb 2 10:13:10 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B607516A4CE for ; Wed, 2 Feb 2005 10:13:10 +0000 (GMT) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 83F9643D2D for ; Wed, 2 Feb 2005 10:13:10 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with SMTP id DA4DF46B2D; Wed, 2 Feb 2005 05:13:09 -0500 (EST) Date: Wed, 2 Feb 2005 10:12:25 +0000 (GMT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Niclas Zeising In-Reply-To: <42008FDC.6050400@n00b.apagnu.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@freebsd.org Subject: Re: unmount of /dev failed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2005 10:13:10 -0000 On Wed, 2 Feb 2005, Niclas Zeising wrote: > I am using current as of yesterday (20050201) morning CET (around 0800 i > think). When I shutdown or reboot my system (shutdown -[h,r] now) it > runs through the shut down sequence as usual, but right before it is > rebooting or the message about the shutdown complete comes up, when > unmouning dev, it complains about "unmount of /dev failed (BUSY)" before > shutting down as usual. Is this a bug, and if so, common or known? Or > am I just being stupid somewhere and all is my fault? Just let me know > if I need to provide more information. I'm guessing this started occuring because phk changed devfs not to permit forceable unmount due to some nasty issues involved (devfs_vfsops.c:1.41). And, for some reason, we presumably have a lingering reference to devfs -- perhaps the root file system mounted from a devfs vnode, another feature introduced recently? It's probably non-harmful, but probably also should be fixed by properly unwinding and unmounting devfs at the right moment in the shutdown to reflect changes in the boot order. Robert N M Watson From owner-freebsd-current@FreeBSD.ORG Wed Feb 2 10:15:01 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 609AD16A4CE for ; Wed, 2 Feb 2005 10:15:01 +0000 (GMT) Received: from alpha.siliconlandmark.com (alpha.siliconlandmark.com [209.69.98.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id E4B7543D1D for ; Wed, 2 Feb 2005 10:15:00 +0000 (GMT) (envelope-from andy@siliconlandmark.com) Received: from alpha.siliconlandmark.com (andy@localhost [127.0.0.1]) j12AEjaH015845; Wed, 2 Feb 2005 05:14:45 -0500 (EST) (envelope-from andy@siliconlandmark.com) Received: from localhost (andy@localhost)j12AEiNa015842; Wed, 2 Feb 2005 05:14:45 -0500 (EST) (envelope-from andy@siliconlandmark.com) X-Authentication-Warning: alpha.siliconlandmark.com: andy owned process doing -bs Date: Wed, 2 Feb 2005 05:14:44 -0500 (EST) From: Andre Guibert de Bruet To: =?ISO-8859-1?Q?S=F8ren_Schmidt?= In-Reply-To: <41FFE288.3090804@DeepCore.dk> Message-ID: <20050202051347.O15724@alpha.siliconlandmark.com> References: <41FF6934.9040300@atlantis.dp.ua> <20050201133646.E59974@atlantis.atlantis.dp.ua> <41FFE288.3090804@DeepCore.dk> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1846045309-1107339284=:15724" X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean cc: freebsd-current@freebsd.org Subject: Re: What about ITE8212F (Was: Re: Silicon Image SiI 3112 Serial ATA) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2005 10:15:01 -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-1846045309-1107339284=:15724 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Tue, 1 Feb 2005, S=F8ren Schmidt wrote: > Well, I dont have too much experience with it since I just got the HW abo= ut a=20 > month ago but its worked flawlessly since in daily use in my WS. > If you want 5.x support just grap the ATA driver form -current minus the= =20 > atapi*.? stuff and its will do the trick. Are there any plans on having this MFC'ed? Andy | Andre Guibert de Bruet | Enterprise Software Consultant > | Silicon Landmark, LLC. | http://siliconlandmark.com/ > --0-1846045309-1107339284=:15724-- From owner-freebsd-current@FreeBSD.ORG Wed Feb 2 10:44:35 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6BD2F16A4CF for ; Wed, 2 Feb 2005 10:44:35 +0000 (GMT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id C370F43D39 for ; Wed, 2 Feb 2005 10:44:34 +0000 (GMT) (envelope-from peadar.edwards@gmail.com) Received: by wproxy.gmail.com with SMTP id 58so16647wri for ; Wed, 02 Feb 2005 02:44:31 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=AAEXdMycgavzk0oyfL/VseN3wDVW+/X7V8hKzu98H4k5NN5x4BvFSDt4B4/Ys9bMEQ3m/aeLdlwbAODeCC+lP4JPnLvza+pjsLkVW5DuHJt8nDB0gX1CPEvx3UjmbvShfpFGgR36oHF0iSqIZ93Zbius1+ltI0AWCHT/Dnc2uSg= Received: by 10.54.48.14 with SMTP id v14mr49116wrv; Wed, 02 Feb 2005 02:44:31 -0800 (PST) Received: by 10.54.57.20 with HTTP; Wed, 2 Feb 2005 02:44:31 -0800 (PST) Message-ID: <34cb7c8405020202446192b3bb@mail.gmail.com> Date: Wed, 2 Feb 2005 10:44:31 +0000 From: Peter Edwards To: Julian Elischer In-Reply-To: <20050201130340.D92335@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20050201101113.J572@localhost> <20050201190318.GE45608@cirb503493.alcatel.com.au> <20050201130340.D92335@localhost> cc: Peter Jeremy cc: current@freebsd.org Subject: Re: cynchronised sleep capbilty.. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Peter Edwards List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2005 10:44:35 -0000 On Tue, 1 Feb 2005 13:20:15 -0800 (PST), Julian Elischer wrote: > > > On Wed, 2 Feb 2005, Peter Jeremy wrote: > > > On Tue, 2005-Feb-01 10:20:24 -0800, Julian Elischer wrote: > > >while: > > >do > > > report results > > > sleep -until_next 10 > > >done > > > > How about: > > 1) Re-write the loop in C, perl or equivalent using setitimer(). You > > can system() out to collect the results. > > 2) Write a small C program that uses setitimer() and signals > > its parent whenever the timer triggers. Run it in the background > > and just pause within the sh loop. > > > > > > this is what I ended up doing.. > > # like sleep 10 except that it phase locks to teh 10 second boundary > # so that multiple machines are talking about the same sample period. I do something similar in C that requires no long-term drift, but it's a little more general: Use an absolute time for sleeps, rather than relative to "now". e.g.: time_t wakeup = time(0); while (!done) { // avoid multiple firings if "dostuff()" takes longer than interval while (wakeup < time(0)) wakeup += interval; sleepUntil(wakeup); dostuff(); } Where sleepUntil can be implemented either as a sleep relative to wakeupTime - now, or use a pthreads function like pthread_cond_timedwait(), for example. The shell code would probably be equally simple From owner-freebsd-current@FreeBSD.ORG Wed Feb 2 11:02:13 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E51E716A4CE; Wed, 2 Feb 2005 11:02:13 +0000 (GMT) Received: from critter.freebsd.dk (f170.freebsd.dk [212.242.86.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id 35C3343D45; Wed, 2 Feb 2005 11:02:13 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.1/8.13.1) with ESMTP id j12B2Bp6034030; Wed, 2 Feb 2005 12:02:11 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Robert Watson From: "Poul-Henning Kamp" In-Reply-To: Your message of "Wed, 02 Feb 2005 10:12:25 GMT." Date: Wed, 02 Feb 2005 12:02:11 +0100 Message-ID: <34029.1107342131@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: freebsd-current@freebsd.org cc: Niclas Zeising Subject: Re: unmount of /dev failed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2005 11:02:14 -0000 In message , Robert Watson writes: >On Wed, 2 Feb 2005, Niclas Zeising wrote: > >> I am using current as of yesterday (20050201) morning CET (around 0800 i >> think). When I shutdown or reboot my system (shutdown -[h,r] now) it >> runs through the shut down sequence as usual, but right before it is >> rebooting or the message about the shutdown complete comes up, when >> unmouning dev, it complains about "unmount of /dev failed (BUSY)" before >> shutting down as usual. Is this a bug, and if so, common or known? Or >> am I just being stupid somewhere and all is my fault? Just let me know >> if I need to provide more information. > >I'm guessing this started occuring because phk changed devfs not to permit >forceable unmount due to some nasty issues involved (devfs_vfsops.c:1.41). >And, for some reason, we presumably have a lingering reference to devfs -- >perhaps the root file system mounted from a devfs vnode, another feature >introduced recently? It's probably non-harmful, but probably also should >be fixed by properly unwinding and unmounting devfs at the right moment in >the shutdown to reflect changes in the boot order. It's on my list, but since it doesn't hurt the on-disk filesystems it is not a high priority. -- 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 Feb 1 18:35:37 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8AD7216A4CE; Tue, 1 Feb 2005 18:35:37 +0000 (GMT) Received: from mh2.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 90B3D43D2D; Tue, 1 Feb 2005 18:35:36 +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 j11IZZhN064867; Tue, 1 Feb 2005 12:35:35 -0600 (CST) (envelope-from anderson@centtech.com) Message-ID: <41FFCBF3.7070505@centtech.com> Date: Tue, 01 Feb 2005 12:35:31 -0600 From: Eric Anderson User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.3) Gecko/20041110 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nate Lawson References: <41FFB53B.3020907@root.org> <41FFB77B.10305@root.org> In-Reply-To: <41FFB77B.10305@root.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.80/585/Thu Nov 11 06:22:42 2004 clamav-milter version 0.80j on mh2.centtech.com X-Virus-Status: Clean X-Mailman-Approved-At: Wed, 02 Feb 2005 13:23:09 +0000 cc: acpi@freebsd.org cc: current@freebsd.org Subject: Re: New cpufreq framework and drivers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2005 18:35:37 -0000 Nate Lawson wrote: > Nate Lawson wrote: > >> Below is the first patch of cpufreq for wider testing. It has the >> framework, cpu pseudodriver updates, and two hardware drivers -- ACPI >> performance states and SpeedStep-ICH. It has had a lot of testing on >> supported hardware but needs wider testing before importing. Other >> hardware drivers can be quickly ported to this interface, and I'm >> happy to assist their maintainers. >> >> http://www.root.org/~nate/freebsd/cpufreq.diff > > > Sorry, I'm so familiar with the interface that I forgot to mention how > to use it. To test, build a new kernel and modules. Load one or both > of acpi_perf.ko and cpufreq.ko at boot time. Type "sysctl dev.cpu" to > see the new freq and freq_levels output. If you're a driver maintainer, > see sys/cpu.h and speedstep_ich.c or acpi_perf.c for an example how to > provide the driver interface. > Will this only work on -current, or also 5.3-stable? Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology I have seen the future and it is just like the present, only longer. ------------------------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Tue Feb 1 19:13:35 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B428816A4CE for ; Tue, 1 Feb 2005 19:13:35 +0000 (GMT) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [128.30.28.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1263B43D49 for ; Tue, 1 Feb 2005 19:13:35 +0000 (GMT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: from khavrinen.lcs.mit.edu (localhost [IPv6:::1]) by khavrinen.lcs.mit.edu (8.12.9/8.12.9) with ESMTP id j11JDXaa084865 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK CN=khavrinen.lcs.mit.edu issuer=SSL+20Client+20CA); Tue, 1 Feb 2005 14:13:33 -0500 (EST) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.12.9/8.12.9/Submit) id j11JDXsf084862; Tue, 1 Feb 2005 14:13:33 -0500 (EST) (envelope-from wollman) Date: Tue, 1 Feb 2005 14:13:33 -0500 (EST) From: Garrett Wollman Message-Id: <200502011913.j11JDXsf084862@khavrinen.lcs.mit.edu> To: Peter Jeremy In-Reply-To: <20050201190318.GE45608@cirb503493.alcatel.com.au> References: <20050201101113.J572@localhost> <20050201190318.GE45608@cirb503493.alcatel.com.au> X-Spam-Score: -19.8 () IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES X-Scanned-By: MIMEDefang 2.37 X-Mailman-Approved-At: Wed, 02 Feb 2005 13:23:09 +0000 cc: current@FreeBSD.ORG Subject: Re: cynchronised sleep capbilty.. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2005 19:13:35 -0000 < said: > 2) Write a small C program that uses setitimer() and signals > its parent whenever the timer triggers. Run it in the background > and just pause within the sh loop. SIGCHLD is good enough. while :; do sleep 10 & do_something wait done -GAWollman From owner-freebsd-current@FreeBSD.ORG Wed Feb 2 13:59:27 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 96A2516A4CE for ; Wed, 2 Feb 2005 13:59:27 +0000 (GMT) Received: from lurza.secnetix.de (lurza.secnetix.de [83.120.8.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id A92DA43D2F for ; Wed, 2 Feb 2005 13:59:26 +0000 (GMT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (yjgxwf@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.1/8.13.1) with ESMTP id j12DxOMH091659 for ; Wed, 2 Feb 2005 14:59:24 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.1/8.13.1/Submit) id j12DxO1X091658; Wed, 2 Feb 2005 14:59:24 +0100 (CET) (envelope-from olli) Date: Wed, 2 Feb 2005 14:59:24 +0100 (CET) Message-Id: <200502021359.j12DxO1X091658@lurza.secnetix.de> From: Oliver Fromme To: freebsd-current@FreeBSD.ORG In-Reply-To: <20050201101113.J572@localhost> X-Newsgroups: list.freebsd-current User-Agent: tin/1.5.4-20000523 ("1959") (UNIX) (FreeBSD/4.11-RELEASE (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Wed, 02 Feb 2005 15:00:57 +0000 Subject: Re: cynchronised sleep capbilty.. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2005 13:59:27 -0000 Julian Elischer wrote: > I often find myself wanting to write shell scripts that do: > > while : > do > {report some statistic} > sleep 10 > done > > > now this is of course only approximate as the delay will not be > exactly 10 seconds and it will gradually creep.. > > This doesn't matter too much except that I now need to do > the same on 50 machines and I need the data to line up. If a precision of 1 s is enough (i.e. the data will line up with a distance of no more than 1 s), the following will work fine: INTERVAL=10 # in seconds! while :; do NOW=`date +%s` sleep $(( ($NOW / $INTERVAL + 1 ) * $INTERVAL - $NOW )) report_results done It calls date(1) and sleep(1) once per 10 seconds, so the overhead is low. The following script snippet abuses sysctl kern.cp_time for subsecond precision (stathz is usually 128, so the precision is about 0.0078s). It calls sysctl(8), bc(1) and sleep(1) once per 10 seconds, so the overhead is still low. This one executes report_results exactly every 10 seconds, _but_ it's not synchronized when executed on multiple machines. To get both sub-second precision and synchronization to clocks across machines, an extension to sleep(1) would be required, as you suggested. I think it would also be nice to be able to get milliseconds from date(1), although that might be difficult to implement, because the strftime(3) interface isn't able to provide such information. Best regards Oliver INTERVAL=10 # in seconds! STATHZ=`sysctl -n kern.clockrate` STATHZ=${STATHZ%?} STATHZ=$(( ${STATHZ##*=} * `sysctl -n hw.ncpu` )) MOD=$(( $INTERVAL * $STATHZ )) StatCounter() { set -- `sysctl -n kern.cp_time` echo $(( $1 + $2 + $3 + $4 + $5 )) } while :; do TICKS=$(( $MOD - `StatCounter` % $MOD )) sleep `echo "scale=6; $TICKS / $STATHZ" | bc` report_results done -- Oliver Fromme, secnetix GmbH & Co KG, Oettingenstr. 2, 80538 München Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "In My Egoistical Opinion, most people's C programs should be indented six feet downward and covered with dirt." -- Blair P. Houghton From owner-freebsd-current@FreeBSD.ORG Wed Feb 2 16:01:08 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0501E16A4CE for ; Wed, 2 Feb 2005 16:01:08 +0000 (GMT) Received: from relay.pair.com (relay00.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 58CB643D53 for ; Wed, 2 Feb 2005 16:01:07 +0000 (GMT) (envelope-from pho@holm.cc) Received: (qmail 35213 invoked from network); 2 Feb 2005 16:01:03 -0000 Received: from unknown (HELO peter.osted.lan) (unknown) by unknown with SMTP; 2 Feb 2005 16:01:03 -0000 X-pair-Authenticated: 80.164.63.199 Received: from peter.osted.lan (localhost.osted.lan [127.0.0.1]) by peter.osted.lan (8.13.1/8.13.1) with ESMTP id j12G0pJE096083; Wed, 2 Feb 2005 17:00:52 +0100 (CET) (envelope-from pho@peter.osted.lan) Received: (from pho@localhost) by peter.osted.lan (8.13.1/8.13.1/Submit) id j12G0gNo096082; Wed, 2 Feb 2005 17:00:42 +0100 (CET) (envelope-from pho) Date: Wed, 2 Feb 2005 17:00:41 +0100 From: Peter Holm To: current@freebsd.org Message-ID: <20050202160041.GA96053@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: jroberson@chesapeake.net Subject: panic: vm_fault: fault on nofault entry X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2005 16:01:08 -0000 With GENERIC HEAD from Jan 28 20:19 UTC + mpsafe_vfs = 1 I got: panic: vm_fault: fault on nofault entry, addr: c87eb000 panic(c083d31c,c87eb000,cf0d99ec,c060b129,c0941990) at panic+0xef vm_fault(c1059000,c87eb000,1,0,c189fa10) at vm_fault+0x1e1 trap_pfault(cf0d9b10,0,c87eb000) at trap_pfault+0x13b trap(4b0018,10,10,bfbfdb78,c87eb000) at trap+0x335 calltrap() at calltrap+0x5 --- trap 0xc, eip = 0xc07bb4ec, esp = 0xcf0d9b50, ebp = 0xcf0d9b84 --- slow_copyout(c87eb000,1000,cf0d9c88,7f0000,7f) at slow_copyout+0x4 ffs_read(cf0d9c14) at ffs_read+0x394 VOP_READ_AP(cf0d9c14) at VOP_READ_AP+0x62 vn_read(c2077a18,cf0d9c88,c1cc8e80,0,c189fa10) at vn_read+0x1ab dofileread(c189fa10,c2077a18,0,bfbfdb78,1000) at dofileread+0xad read(c189fa10,cf0d9d14,3,7,287) at read+0x3b syscall(bfbf002f,2f,bfbf002f,bfbfdb78,400) at syscall+0x213 Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (3, FreeBSD ELF32, read), eip = 0x280b6cf3, esp = 0xbfbfdb3c, ebp = 0xbfbfeb90 --- Details at http://www.holm.cc/stress/log/cons113.html -- Peter Holm From owner-freebsd-current@FreeBSD.ORG Wed Feb 2 16:54:12 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E723B16A4CF for ; Wed, 2 Feb 2005 16:54:12 +0000 (GMT) Received: from darkness.comp.waw.pl (darkness.comp.waw.pl [195.117.238.136]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7FD0443D54 for ; Wed, 2 Feb 2005 16:54:11 +0000 (GMT) (envelope-from pjd@darkness.comp.waw.pl) Received: by darkness.comp.waw.pl (Postfix, from userid 1009) id EBDB2AEA5E; Wed, 2 Feb 2005 17:54:00 +0100 (CET) Date: Wed, 2 Feb 2005 17:54:00 +0100 From: Pawel Jakub Dawidek To: Garance A Drosihn Message-ID: <20050202165400.GS1546@darkness.comp.waw.pl> References: <200410020349.i923nG8v021675@northstar.hetzel.org> <20041002052856.GE17792@nexus.dglawrence.com> <20041002233542.GL714@nexus.dglawrence.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tRcR9GoWqjXrt11v" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 5.2.1-RC2 i386 cc: freebsd-current@freebsd.org cc: "David G. Lawrence" Subject: Re: Bug in #! processing (long reply) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2005 16:54:13 -0000 --tRcR9GoWqjXrt11v Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jan 31, 2005 at 11:09:19PM -0500, Garance A Drosihn wrote: +> Since the above message, the execve() system call was fixed, but we +> never changed the behavior of /bin/sh to match. I recently noticed +> that some of my scripts broke due to this combination, and today one +> of my friends also mentioned that some of their scripts were broken +> after they upgraded to the latest 5.3-stable. +>=20 +> I remember someone saying that they were going to fix /bin/sh, but I +> don't remember who, and it looks like I didn't save that email. [...] I think it was me... Sorry for that, I totally forgot. =2E..and thank you! --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --tRcR9GoWqjXrt11v Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFCAQWoForvXbEpPzQRAuEpAJwIekE31OLto5hx4vrKtSX0TWl6JwCghArm 9yefMtzRnXRDQeyTgG7RaKY= =tBOO -----END PGP SIGNATURE----- --tRcR9GoWqjXrt11v-- From owner-freebsd-current@FreeBSD.ORG Wed Feb 2 17:44:23 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1A2DA16A4CE for ; Wed, 2 Feb 2005 17:44:23 +0000 (GMT) Received: from pimout1-ext.prodigy.net (pimout1-ext.prodigy.net [207.115.63.77]) by mx1.FreeBSD.org (Postfix) with ESMTP id 72C9243D48 for ; Wed, 2 Feb 2005 17:44:22 +0000 (GMT) (envelope-from julian@elischer.org) Received: from jules (adsl-216-100-134-143.dsl.snfc21.pacbell.net [216.100.134.143])j12Hi5GS066976; Wed, 2 Feb 2005 12:44:10 -0500 Date: Wed, 2 Feb 2005 09:44:05 -0800 (PST) From: Julian Elischer X-X-Sender: julian@localhost To: Garrett Wollman In-Reply-To: <200502011913.j11JDXsf084862@khavrinen.lcs.mit.edu> Message-ID: <20050202094256.K88344@localhost> References: <20050201101113.J572@localhost> <20050201190318.GE45608@cirb503493.alcatel.com.au> <200502011913.j11JDXsf084862@khavrinen.lcs.mit.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Peter Jeremy cc: current@freebsd.org Subject: Re: cynchronised sleep capbilty.. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2005 17:44:23 -0000 very clever! however it doesn't phaselock to teh time and still drifts. I need to trigger on (for example) 10 second boundaries across 50 synchronised machines.. (so thatthe machines agree about the sampling period.) -- +------------------------------------+ ______ _ __ | __--_|\ Julian Elischer | \ U \/ / hard at work in | / \ julian@elischer.org +------>x USA \ a very strange | ( OZ ) \___ ___ | country ! +- X_.---._/ presently in San Francisco \_/ \\ v On Tue, 1 Feb 2005, Garrett Wollman wrote: > < said: > > > 2) Write a small C program that uses setitimer() and signals > > its parent whenever the timer triggers. Run it in the background > > and just pause within the sh loop. > > SIGCHLD is good enough. > > while :; do > sleep 10 & > do_something > wait > done > > -GAWollman > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Wed Feb 2 19:17:26 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2340E16A4CE for ; Wed, 2 Feb 2005 19:17:26 +0000 (GMT) Received: from tx1.mail.ox.ac.uk (tx1.mail.ox.ac.uk [129.67.1.167]) by mx1.FreeBSD.org (Postfix) with ESMTP id C7E5643D41 for ; Wed, 2 Feb 2005 19:17:25 +0000 (GMT) (envelope-from cperciva@freebsd.org) Received: from scan1.mail.ox.ac.uk ([129.67.1.166] helo=localhost) by tx1.mail.ox.ac.uk with esmtp (Exim 4.42) id 1CwQ0C-0003QZ-69 for current@freebsd.org; Wed, 02 Feb 2005 19:17:24 +0000 Received: from rx1.mail.ox.ac.uk ([129.67.1.165]) by localhost (scan1.mail.ox.ac.uk [129.67.1.166]) (amavisd-new, port 25) with ESMTP id 13168-01 for ; Wed, 2 Feb 2005 19:17:24 +0000 (GMT) Received: from smtp1.herald.ox.ac.uk ([163.1.0.247]) by rx1.mail.ox.ac.uk with esmtp (Exim 4.42) id 1CwQ01-0003Ef-50; Wed, 02 Feb 2005 19:17:13 +0000 Received: from dhcp1151.wadham.ox.ac.uk ([163.1.161.151]) by smtp1.herald.ox.ac.uk with esmtp (Exim 3.35 #1) id 1CwQ01-00058x-3z; Wed, 02 Feb 2005 19:17:13 +0000 Message-ID: <42012739.9080501@freebsd.org> Date: Wed, 02 Feb 2005 19:17:13 +0000 From: Colin Percival User-Agent: Mozilla Thunderbird 1.0 (X11/20050113) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nate Lawson References: <41FFB53B.3020907@root.org> In-Reply-To: <41FFB53B.3020907@root.org> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: acpi@freebsd.org cc: current@freebsd.org Subject: Re: New cpufreq framework and drivers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2005 19:17:26 -0000 Nate Lawson wrote: > Hardware drivers are of two types, absolute > and relative. SpeedStep, Powernow, etc. are absolute drivers in that > they set the cpu's base frequency. ACPI throttling, Longrun, etc. are > relative drivers that reduce the processor's clock to a fraction of its > current base (i.e., they have an additive effect.) If my first glance at the patch is correct, this would have my laptop (a 1.4GHz Pentium M) reporting the availability of the frequencies 600MHz, 800MHz, etc. from enhanced speedstep, along with the frequencies 300MHz, 400MHz, 500MHz, and 700MHz obtained via 50% clock throttling. While this in itself is entirely valid, a clock speed of 700MHz obtained by running the processor at 1400MHz with a 50% "duty cycle" would draw more power than a clock speed of 800MHz obtained by running the processor at 800MHz with a lower voltage; is there any mechanism to inform userland daemons of such oddities? I would hate to see a daemon lowering the clock speed from 800MHz to 700MHz in an attempt to save power... Colin Percival From owner-freebsd-current@FreeBSD.ORG Wed Feb 2 19:18:51 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E470416A4CE for ; Wed, 2 Feb 2005 19:18:51 +0000 (GMT) Received: from critter.freebsd.dk (f170.freebsd.dk [212.242.86.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3451743D41 for ; Wed, 2 Feb 2005 19:18:51 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.1/8.13.1) with ESMTP id j12JId4L001521; Wed, 2 Feb 2005 20:18:39 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Julian Elischer From: "Poul-Henning Kamp" In-Reply-To: Your message of "Wed, 02 Feb 2005 09:44:05 PST." <20050202094256.K88344@localhost> Date: Wed, 02 Feb 2005 20:18:39 +0100 Message-ID: <1520.1107371919@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: Peter Jeremy cc: current@freebsd.org cc: Garrett Wollman Subject: Re: cynchronised sleep capbilty.. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2005 19:18:52 -0000 In message <20050202094256.K88344@localhost>, Julian Elischer writes: >very clever! > >however it doesn't phaselock to teh time and still drifts. >I need to trigger on (for example) 10 second boundaries across 50 >synchronised machines.. >(so thatthe machines agree about the sampling period.) You'll find code that does it the right way in here: http://phk.freebsd.dk/NTPns/ -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Wed Feb 2 20:03:54 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3263D16A4CE; Wed, 2 Feb 2005 20:03:54 +0000 (GMT) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id CEB1643D55; Wed, 2 Feb 2005 20:03:51 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.0.34] (adsl-67-119-74-222.dsl.sntc01.pacbell.net [67.119.74.222]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id j12K3oWk031180 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 2 Feb 2005 12:03:51 -0800 Message-ID: <42013223.4080704@root.org> Date: Wed, 02 Feb 2005 12:03:47 -0800 From: Nate Lawson User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Colin Percival References: <41FFB53B.3020907@root.org> <42012739.9080501@freebsd.org> In-Reply-To: <42012739.9080501@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: acpi@freebsd.org cc: current@freebsd.org Subject: Re: New cpufreq framework and drivers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2005 20:03:54 -0000 Colin Percival wrote: > Nate Lawson wrote: > >> Hardware drivers are of two types, absolute >> and relative. SpeedStep, Powernow, etc. are absolute drivers in that >> they set the cpu's base frequency. ACPI throttling, Longrun, etc. are >> relative drivers that reduce the processor's clock to a fraction of >> its current base (i.e., they have an additive effect.) > > > If my first glance at the patch is correct, this would have my laptop (a > 1.4GHz > Pentium M) reporting the availability of the frequencies 600MHz, 800MHz, > etc. > from enhanced speedstep, along with the frequencies 300MHz, 400MHz, > 500MHz, and > 700MHz obtained via 50% clock throttling. That is correct. The code to support relative drivers was removed before posting to give the basic framework more testing before I commit it shortly. The relative support will go in soon after that code is committed. There are a lot of nuances that you'll see when I post the relative states patch. For instance, if a state has the same frequency of another state, the one with the lower power consumption is preferred. > While this in itself is entirely valid, a clock speed of 700MHz obtained by > running the processor at 1400MHz with a 50% "duty cycle" would draw more > power > than a clock speed of 800MHz obtained by running the processor at 800MHz > with > a lower voltage; is there any mechanism to inform userland daemons of such > oddities? I would hate to see a daemon lowering the clock speed from > 800MHz > to 700MHz in an attempt to save power... If you look at the kernel interface (sys/sys/cpu.h, struct cf_setting), you'll see that frequency, power, latency, and other values are available. The user sysctl interface exports frequency/power values as follows: dev.cpu.0.freq=733 dev.cpu.0.freq_levels=1000/18200 733/15100 That is Mhz and mW, respectively. With synthetic states (ones derived from a base absolute frequency and a modifying relative frequency), the cpufreq framework builds a power estimate. For example, a level comprised of 1400 Mhz at 20000 mW and a 50% relative setting would have an exported power of 10000 mW since relative drivers give a linear reduction in power consumption. Your absolute setting of 800 Mhz would likely have a lower power level and so any daemon should take that into consideration. -- Nate From owner-freebsd-current@FreeBSD.ORG Wed Feb 2 20:19:54 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B4B0916A4CF for ; Wed, 2 Feb 2005 20:19:54 +0000 (GMT) Received: from tx0.mail.ox.ac.uk (tx0.mail.ox.ac.uk [129.67.1.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 54CD643D4C for ; Wed, 2 Feb 2005 20:19:54 +0000 (GMT) (envelope-from cperciva@freebsd.org) Received: from scan0.mail.ox.ac.uk ([129.67.1.162] helo=localhost) by tx0.mail.ox.ac.uk with esmtp (Exim 4.42) id 1CwQyf-00031V-1x for current@freebsd.org; Wed, 02 Feb 2005 20:19:53 +0000 Received: from rx0.mail.ox.ac.uk ([129.67.1.161]) by localhost (scan0.mail.ox.ac.uk [129.67.1.162]) (amavisd-new, port 25) with ESMTP id 11442-07 for ; Wed, 2 Feb 2005 20:19:53 +0000 (GMT) Received: from smtp2.herald.ox.ac.uk ([163.1.0.235]) by rx0.mail.ox.ac.uk with esmtp (Exim 4.42) id 1CwQye-00031I-09; Wed, 02 Feb 2005 20:19:52 +0000 Received: from dhcp1151.wadham.ox.ac.uk ([163.1.161.151]) by smtp2.herald.ox.ac.uk with esmtp (Exim 3.35 #1) id 1CwQyd-00011k-3n; Wed, 02 Feb 2005 20:19:52 +0000 Message-ID: <420135E7.9070302@freebsd.org> Date: Wed, 02 Feb 2005 20:19:51 +0000 From: Colin Percival User-Agent: Mozilla Thunderbird 1.0 (X11/20050113) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nate Lawson References: <41FFB53B.3020907@root.org> <42012739.9080501@freebsd.org> <42013223.4080704@root.org> In-Reply-To: <42013223.4080704@root.org> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: acpi@freebsd.org cc: current@freebsd.org Subject: Re: New cpufreq framework and drivers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2005 20:19:54 -0000 Nate Lawson wrote: > If you look at the kernel interface (sys/sys/cpu.h, struct cf_setting), > you'll see that frequency, power, latency, and other values are > available. Ah, I didn't read that far. Thanks, that answers my question. Colin Percival From owner-freebsd-current@FreeBSD.ORG Wed Feb 2 20:35:13 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B69CE16A4CE for ; Wed, 2 Feb 2005 20:35:13 +0000 (GMT) Received: from relay.pair.com (relay00.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 11DA443D55 for ; Wed, 2 Feb 2005 20:35:13 +0000 (GMT) (envelope-from pho@holm.cc) Received: (qmail 64998 invoked from network); 2 Feb 2005 20:35:12 -0000 Received: from unknown (HELO peter.osted.lan) (unknown) by unknown with SMTP; 2 Feb 2005 20:35:12 -0000 X-pair-Authenticated: 80.164.63.199 Received: from peter.osted.lan (localhost.osted.lan [127.0.0.1]) by peter.osted.lan (8.13.1/8.13.1) with ESMTP id j12KZAYa098097; Wed, 2 Feb 2005 21:35:10 +0100 (CET) (envelope-from pho@peter.osted.lan) Received: (from pho@localhost) by peter.osted.lan (8.13.1/8.13.1/Submit) id j12KZ8LG098096; Wed, 2 Feb 2005 21:35:08 +0100 (CET) (envelope-from pho) Date: Wed, 2 Feb 2005 21:35:06 +0100 From: Peter Holm To: Kris Kennaway Message-ID: <20050202203506.GA98012@peter.osted.lan> References: <20050130094616.GA76093@peter.osted.lan> <20050202000613.GA9758@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050202000613.GA9758@xor.obsecurity.org> User-Agent: Mutt/1.4.2.1i cc: current@freebsd.org cc: jroberson@chesapeake.net Subject: Re: Panic: Memory modified after free X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2005 20:35:13 -0000 On Tue, Feb 01, 2005 at 04:06:13PM -0800, Kris Kennaway wrote: > On Sun, Jan 30, 2005 at 10:46:16AM +0100, Peter Holm wrote: > > With GENERIC HEAD from Jan 28 20:19 UTC + mpsafe_vfs = 1 I got: > > > > Memory modified after free 0xc1d7c100(124) val=c23fa000 @ 0xc1d7c164 > > > > panic(c083d005,c083b16e,c083cfd6,c1d7c100,7c) at panic+0xef > > mtrash_ctor(c1d7c100,80,0,402) at mtrash_ctor+0x4d > > uma_zalloc_arg(c10526e0,0,402) at uma_zalloc_arg+0x14c > > malloc(68,c08bcd60,402,c094f0c0,0) at malloc+0xae > > inodedep_lookup(c167a000,193a1,1,cf261be0,c094f0c0) at inodedep_lookup+0xa7 > > softdep_change_linkcnt(c213b578,c6bc54f0,c65f3f88,c213b578,c1c39270) at softdep_change_linkcnt+0x31 > > ufs_dirremove(c17d83a8,c213b578,100800c,0,cf261c48) at ufs_dirremove+0x12d > > ufs_remove(cf261c4c) at ufs_remove+0x4b > > VOP_REMOVE_AP(cf261c4c) at VOP_REMOVE_AP+0x62 > > kern_unlink(c1add2e0,bfbfe940,0,cf261d40,c07bd6c3) at kern_unlink+0x167 > > unlink(c1add2e0,cf261d14,1,28,292) at unlink+0x12 > > syscall(2804002f,bfbf002f,bfbf002f,2804f6c0,bfbfeb14) at syscall+0x213 > > > > More info at http://www.holm.cc/stress/log/cons112.html > > > panic: Most recently used by inodedep > > You can try to use DEBUG_MEMGUARD with M_INODEDEP to find this. I'll > add that to my SMP package machines to see if I can trigger it too. > I have only seen this panic once, but maybe it will shake out some other problems. I'll give it a try, real soon. - Peter > Kris > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.0 (FreeBSD) > > iD8DBQFCABl1Wry0BWjoQKURAo86AJwOi4YsNsThOjZL64aJBRcXtW1oJQCbBkXn > caMc1rriaJ31QGoInhYyIqE= > =hZUh > -----END PGP SIGNATURE----- -- Peter Holm From owner-freebsd-current@FreeBSD.ORG Wed Feb 2 20:38:31 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D84B816A4CE; Wed, 2 Feb 2005 20:38:31 +0000 (GMT) Received: from poup.poupinou.org (poup.poupinou.org [195.101.94.96]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6405043D58; Wed, 2 Feb 2005 20:38:31 +0000 (GMT) (envelope-from ducrot@poupinou.org) Received: from ducrot by poup.poupinou.org with local (Exim) id 1CwRGB-0003Km-00; Wed, 02 Feb 2005 21:37:59 +0100 Date: Wed, 2 Feb 2005 21:37:58 +0100 To: Nate Lawson Message-ID: <20050202203758.GY1145@poupinou.org> References: <41FFB53B.3020907@root.org> <42012739.9080501@freebsd.org> <42013223.4080704@root.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42013223.4080704@root.org> User-Agent: Mutt/1.5.6+20040907i From: Bruno Ducrot cc: acpi@freebsd.org cc: current@freebsd.org cc: Colin Percival Subject: Re: New cpufreq framework and drivers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2005 20:38:32 -0000 On Wed, Feb 02, 2005 at 12:03:47PM -0800, Nate Lawson wrote: > Colin Percival wrote: > >Nate Lawson wrote: > > > >>Hardware drivers are of two types, absolute > >>and relative. SpeedStep, Powernow, etc. are absolute drivers in that > >>they set the cpu's base frequency. ACPI throttling, Longrun, etc. are > >>relative drivers that reduce the processor's clock to a fraction of > >>its current base (i.e., they have an additive effect.) > > > > > >If my first glance at the patch is correct, this would have my laptop (a > >1.4GHz > >Pentium M) reporting the availability of the frequencies 600MHz, 800MHz, > >etc. > >from enhanced speedstep, along with the frequencies 300MHz, 400MHz, > >500MHz, and > >700MHz obtained via 50% clock throttling. > > That is correct. The code to support relative drivers was removed > before posting to give the basic framework more testing before I commit > it shortly. The relative support will go in soon after that code is > committed. > But longrun is relative though and can scale voltage. (And the point that longrun can control frequency itself is imho irrelevant). -- Bruno Ducrot -- Which is worse: ignorance or apathy? -- Don't know. Don't care. From owner-freebsd-current@FreeBSD.ORG Wed Feb 2 20:58:46 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3C5ED16A4CE for ; Wed, 2 Feb 2005 20:58:46 +0000 (GMT) Received: from hanoi.cronyx.ru (hanoi.cronyx.ru [144.206.181.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 75EB043D1F for ; Wed, 2 Feb 2005 20:58:45 +0000 (GMT) (envelope-from rik@cronyx.ru) Received: (from root@localhost) by hanoi.cronyx.ru (8.13.0/vak/3.0) id j12KthvB020388 for current@freebsd.org.checked; Wed, 2 Feb 2005 23:55:43 +0300 (MSK) (envelope-from rik@cronyx.ru) Received: from cronyx.ru (localhost.cronyx.ru [127.0.0.1]) by hanoi.cronyx.ru (8.13.0/vak/3.0) with ESMTP id j12KsUnr020262; Wed, 2 Feb 2005 23:54:30 +0300 (MSK) (envelope-from rik@cronyx.ru) Message-ID: <42013BC8.5040204@cronyx.ru> Date: Wed, 02 Feb 2005 23:44:56 +0300 From: Roman Kurakin User-Agent: Mozilla/5.0 (X11; U; Linux i686; ru-RU; rv:1.2.1) Gecko/20030426 X-Accept-Language: ru-ru, en MIME-Version: 1.0 To: Alexander Leidinger References: <20050129161022.0de822fe@Magellan.Leidinger.net> In-Reply-To: <20050129161022.0de822fe@Magellan.Leidinger.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: current@freebsd.org Subject: Re: We have a lot of duplicated code in the kernel X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2005 20:58:46 -0000 Alexander Leidinger: >Hi, > >http://www.leidinger.net/FreeBSD/simian-20-sys-20050129.log (253k) >contains a log of duplicated code in /sys (-current as of today). The >file starts with files with 20 consecutive lines of duplicated code and >ends with two files which share 1108 lines of code. > >If I let the program detect 6 consecutive lines of duplicated code, it >is also able to detect possible code reuse in the same file, but it also >prints a lot of "noise" then. > >I've filtered the list for some false positives (twa_fwimg, trlld?m, >if_patm_rtables), if someone else notices some more files please tell me >about them and I add them to the filter. > For example if_ct.c and if_cp.c. They have to have the same code since they written by the same authors, and both devices have almost the same architecture. If I remove or would use the same prefix for DDK of both adapters, I am sure, code would have more than 50% of the same code. ;-) It seems that if_cx.c is not there since it is able to work in async mode. rik > >Bye, >Alexander. > > > From owner-freebsd-current@FreeBSD.ORG Wed Feb 2 21:29:45 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A543716A4CE; Wed, 2 Feb 2005 21:29:45 +0000 (GMT) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4A3B743D1D; Wed, 2 Feb 2005 21:29:45 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.0.34] (adsl-67-119-74-222.dsl.sntc01.pacbell.net [67.119.74.222]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id j12LThWk000339 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 2 Feb 2005 13:29:44 -0800 Message-ID: <42014644.9080603@root.org> Date: Wed, 02 Feb 2005 13:29:40 -0800 From: Nate Lawson User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bruno Ducrot References: <41FFB53B.3020907@root.org> <42012739.9080501@freebsd.org> <42013223.4080704@root.org> <20050202203758.GY1145@poupinou.org> In-Reply-To: <20050202203758.GY1145@poupinou.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: acpi@freebsd.org cc: current@freebsd.org cc: Colin Percival Subject: Re: New cpufreq framework and drivers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2005 21:29:45 -0000 Bruno Ducrot wrote: > On Wed, Feb 02, 2005 at 12:03:47PM -0800, Nate Lawson wrote: > >>Colin Percival wrote: >> >>>Nate Lawson wrote: >>> >>> >>>>Hardware drivers are of two types, absolute >>>>and relative. SpeedStep, Powernow, etc. are absolute drivers in that >>>>they set the cpu's base frequency. ACPI throttling, Longrun, etc. are >>>>relative drivers that reduce the processor's clock to a fraction of >>>>its current base (i.e., they have an additive effect.) >>> >>> >>>If my first glance at the patch is correct, this would have my laptop (a >>>1.4GHz >>>Pentium M) reporting the availability of the frequencies 600MHz, 800MHz, >>>etc. >> >>>from enhanced speedstep, along with the frequencies 300MHz, 400MHz, >> >>>500MHz, and >>>700MHz obtained via 50% clock throttling. >> >>That is correct. The code to support relative drivers was removed >>before posting to give the basic framework more testing before I commit >>it shortly. The relative support will go in soon after that code is >>committed. >> > > But longrun is relative though and can scale voltage. > (And the point that longrun can control frequency itself is imho irrelevant). If you look at struct cf_setting, the "freq" field is either the absolute freq in Mhz (i.e. 700 = 700 Mhz) or a relative percentage (i.e. 50 = 50% clock reduction). The way you tell the difference is that the CPUFREQ_DRV_SETTINGS() method returns a "type", which is either absolute or relative. All the other fields are valid for both types so your driver would set the "volt" field of cf_setting to whatever Longrun says.) If your driver somehow knew the power consumed for that setting, it could supply that info too. Otherwise, set CPUFREQ_VAL_UNKNOWN for each value not known by the driver. (BTW, I'm moving relative units to hundredths of a percent, i.e. 8055 = 80.55%) -- Nate From owner-freebsd-current@FreeBSD.ORG Wed Feb 2 22:32:55 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5C7FF16A4CE; Wed, 2 Feb 2005 22:32:55 +0000 (GMT) Received: from postal2.es.net (postal2.es.net [198.128.3.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id BB8C543D45; Wed, 2 Feb 2005 22:32:54 +0000 (GMT) (envelope-from oberman@es.net) Received: from ptavv.es.net ([198.128.4.29]) by postal2.es.net (Postal Node 2) with ESMTP (SSL) id IBA74465; Wed, 02 Feb 2005 14:32:53 -0800 Received: from ptavv (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 46EF25D08; Wed, 2 Feb 2005 14:32:53 -0800 (PST) X-Mailer: exmh version 2.7.0 06/18/2004 with nmh-1.0.4 To: Nate Lawson In-reply-to: Your message of "Tue, 01 Feb 2005 11:01:49 PST." <41FFD21D.1080906@root.org> Mime-Version: 1.0 Content-Type: multipart/mixed ; boundary="==_Exmh_-302709550" Date: Wed, 02 Feb 2005 14:32:53 -0800 From: "Kevin Oberman" Message-Id: <20050202223253.46EF25D08@ptavv.es.net> cc: acpi@freebsd.org cc: Eric Anderson cc: current@freebsd.org Subject: Re: New cpufreq framework and drivers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2005 22:32:55 -0000 This is a multipart MIME message. --==_Exmh_-302709550 Content-Type: text/plain; charset=us-ascii > Date: Tue, 01 Feb 2005 11:01:49 -0800 > From: Nate Lawson > Sender: owner-freebsd-acpi@freebsd.org > > Eric Anderson wrote: > > Nate Lawson wrote: > > > >> Nate Lawson wrote: > >> > >>> Below is the first patch of cpufreq for wider testing. It has the > >>> framework, cpu pseudodriver updates, and two hardware drivers -- ACPI > >>> performance states and SpeedStep-ICH. It has had a lot of testing on > >>> supported hardware but needs wider testing before importing. Other > >>> hardware drivers can be quickly ported to this interface, and I'm > >>> happy to assist their maintainers. > >>> > >>> http://www.root.org/~nate/freebsd/cpufreq.diff > >> > >> > >> > >> Sorry, I'm so familiar with the interface that I forgot to mention how > >> to use it. To test, build a new kernel and modules. Load one or both > >> of acpi_perf.ko and cpufreq.ko at boot time. Type "sysctl dev.cpu" to > >> see the new freq and freq_levels output. If you're a driver > >> maintainer, see sys/cpu.h and speedstep_ich.c or acpi_perf.c for an > >> example how to provide the driver interface. > >> > > > > Will this only work on -current, or also 5.3-stable? > > It should work on -stable, modulo any diff fuzz. > > -- > Nate > _______________________________________________ > freebsd-acpi@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-acpi > To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@freebsd.org" > A bit more that fuzz, I'm afraid, but nothing that should take more than a little effort, but it's not very difficult. I am attaching diffs against -stable. Since it's your code, I did not feel like I should be sending them to others. I'll leave it up to you as to whether to post them. (And, it's possible that I messed something up, too, although I did test it.) It requires -stable as of 12/8/2005 or newer. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 --==_Exmh_-302709550 Content-Type: text/plain ; name="cpufreq5.diff"; charset=us-ascii Content-Description: cpufreq5.diff Content-Disposition: attachment; filename="cpufreq5.diff" Index: sys/cpu.h =================================================================== RCS file: sys/cpu.h diff -N sys/cpu.h --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ sys/cpu.h 1 Feb 2005 16:54:24 -0000 @@ -0,0 +1,121 @@ +/*- + * Copyright (c) 2005 Nate Lawson (SDG) + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + * + * $FreeBSD$ + */ + +#ifndef _SYS_CPU_H_ +#define _SYS_CPU_H_ + +/* + * CPU device support. + */ + +#define CPU_IVAR_PCPU 1 + +static __inline struct pcpu *cpu_get_pcpu(device_t dev) +{ + uintptr_t v = 0; + BUS_READ_IVAR(device_get_parent(dev), dev, CPU_IVAR_PCPU, &v); + return ((struct pcpu *)v); +} + +/* + * CPU frequency control interface. + */ + +/* Each driver's CPU frequency setting is exported in this format. */ +struct cf_setting { + int freq; /* Processor clock in Mhz or percent (in 100ths.) */ + int volts; /* Voltage in mV. */ + int power; /* Power consumed in mW. */ + int lat; /* Transition latency in us. */ + device_t dev; /* Driver providing this setting. */ +}; + +/* Maximum number of settings a given driver can have. */ +#define MAX_SETTINGS 24 + +/* A combination of settings is a level. */ +struct cf_level { + struct cf_setting total_set; + struct cf_setting abs_set; + struct cf_setting rel_set[MAX_SETTINGS]; + int rel_count; + TAILQ_ENTRY(cf_level) link; +}; + +TAILQ_HEAD(cf_level_lst, cf_level); + +/* Drivers should set all unknown values to this. */ +#define CPUFREQ_VAL_UNKNOWN (-1) + +/* + * Every driver offers a type of CPU control. Absolute levels are mutually + * exclusive while relative levels modify the current absolute level. There + * may be multiple absolute and relative drivers available on a given + * system. + * + * For example, consider a system with two absolute drivers that provide + * frequency settings of 100, 200 and 300, 400 and a relative driver that + * provides settings of 50%, 100%. The cpufreq core would export frequency + * levels of 50, 100, 150, 200, 300, 400. + */ +#define CPUFREQ_TYPE_RELATIVE (1<<0) +#define CPUFREQ_TYPE_ABSOLUTE (1<<1) + +/* + * When setting a level, the caller indicates the priority of this request. + * Priorities determine, among other things, whether a level can be + * overridden by other callers. For example, if the user sets a level but + * the system thermal driver needs to override it for emergency cooling, + * the driver would use a higher priority. Once the event has passed, the + * driver would call cpufreq to resume any previous level. + */ +#define CPUFREQ_PRIO_HIGHEST 1000000 +#define CPUFREQ_PRIO_KERN 1000 +#define CPUFREQ_PRIO_USER 100 +#define CPUFREQ_PRIO_LOWEST 0 + +/* + * Register and unregister a driver with the cpufreq core. Once a driver + * is registered, it must support calls to its CPUFREQ_GET, CPUFREQ_GET_LEVEL, + * and CPUFREQ_SET methods. It must also unregister before returning from + * its DEVICE_DETACH method. + */ +int cpufreq_register(device_t dev); +int cpufreq_unregister(device_t dev); + +/* Allow values to be +/- a bit since sometimes we have to estimate. */ +#define CPUFREQ_CMP(x, y) (abs((x) - (y)) < 25) + +/* + * Machine-dependent functions. + */ + +/* Estimate the current clock rate for the given CPU id. */ +int cpu_est_clockrate(int cpu_id, uint64_t *rate); + +#endif /* !_SYS_CPU_H_ */ Index: alpha/alpha/machdep.c Index: alpha/alpha/machdep.c =================================================================== RCS file: /home/ncvs/src/sys/alpha/alpha/machdep.c,v --- alpha/alpha/machdep.c.orig Wed Feb 2 11:45:02 2005 +++ alpha/alpha/machdep.c Wed Feb 2 12:40:01 2005 @@ -98,6 +98,7 @@ #include #include +#include #include #include #include @@ -1720,6 +1721,14 @@ void cpu_boot(int howto) { +} + +/* Get current clock frequency for the given cpu id. */ +int +cpu_est_clockrate(int cpu_id, uint64_t *rate) +{ + + return (ENXIO); } /* Index: amd64/amd64/machdep.c =================================================================== RCS file: /home/ncvs/src/sys/amd64/amd64/machdep.c,v --- amd64/amd64/machdep.c.orig Wed Feb 2 11:45:02 2005 +++ amd64/amd64/machdep.c Wed Feb 2 12:40:01 2005 @@ -56,8 +56,12 @@ #include #include -#include -#include +#include +#include +#include +#include +#include +#include #include #include #include @@ -446,6 +450,44 @@ void cpu_boot(int howto) { +} + +/* Get current clock frequency for the given cpu id. */ +int +cpu_est_clockrate(int cpu_id, uint64_t *rate) +{ + uint64_t tsc1, tsc2; + + if (pcpu_find(cpu_id) == NULL || rate == NULL) + return (EINVAL); + + /* If we're booting, trust the rate calibrated moments ago. */ + if (cold) { + *rate = tsc_freq; + return (0); + } + +#ifdef SMP + /* Schedule ourselves on the indicated cpu. */ + mtx_lock_spin(&sched_lock); + sched_bind(curthread, cpu_id); + mtx_unlock_spin(&sched_lock); +#endif + + /* Calibrate by measuring a short delay. */ + tsc1 = rdtsc(); + DELAY(1000); + tsc2 = rdtsc(); + +#ifdef SMP + mtx_lock_spin(&sched_lock); + sched_unbind(curthread); + mtx_unlock_spin(&sched_lock); +#endif + + tsc_freq = (tsc2 - tsc1) * 1000; + *rate = tsc_freq; + return (0); } /* Index: i386/i386/machdep.c =================================================================== RCS file: /home/ncvs/src/sys/i386/i386/machdep.c,v --- i386/i386/machdep.c.orig Wed Feb 2 11:45:02 2005 +++ i386/i386/machdep.c Wed Feb 2 12:40:01 2005 @@ -56,8 +56,12 @@ #include #include -#include -#include +#include +#include +#include +#include +#include +#include #include #include #include @@ -66,21 +70,18 @@ #include #include #include +#include #include #include #include -#include -#include #include -#include -#include #include -#include +#include #include +#include +#include #include #include -#include -#include #include #include @@ -105,6 +106,7 @@ #include +#include #include #include #include @@ -1020,6 +1022,46 @@ void cpu_boot(int howto) { +} + +/* Get current clock frequency for the given cpu id. */ +int +cpu_est_clockrate(int cpu_id, uint64_t *rate) +{ + uint64_t tsc1, tsc2; + + if (pcpu_find(cpu_id) == NULL || rate == NULL) + return (EINVAL); + if (!tsc_present) + return (EOPNOTSUPP); + + /* If we're booting, trust the rate calibrated moments ago. */ + if (cold) { + *rate = tsc_freq; + return (0); + } + +#ifdef SMP + /* Schedule ourselves on the indicated cpu. */ + mtx_lock_spin(&sched_lock); + sched_bind(curthread, cpu_id); + mtx_unlock_spin(&sched_lock); +#endif + + /* Calibrate by measuring a short delay. */ + tsc1 = rdtsc(); + DELAY(1000); + tsc2 = rdtsc(); + +#ifdef SMP + mtx_lock_spin(&sched_lock); + sched_unbind(curthread); + mtx_unlock_spin(&sched_lock); +#endif + + tsc_freq = (tsc2 - tsc1) * 1000; + *rate = tsc_freq; + return (0); } /* Index: i386/i386/legacy.c =================================================================== RCS file: /home/ncvs/src/sys/i386/i386/legacy.c,v --- i386/i386/legacy.c.orig Wed Feb 2 12:36:23 2005 +++ i386/i386/legacy.c Wed Feb 2 12:40:02 2005 @@ -38,6 +38,7 @@ #include #include #include +#include #include #include #include @@ -137,32 +138,25 @@ { device_t child; int i; - struct pcpu *pc; + /* First, attach the CPU pseudo-driver. */ + for (i = 0; i <= mp_maxid; i++) + if (!CPU_ABSENT(i)) { + child = BUS_ADD_CHILD(dev, 0, "cpu", i); + if (child == NULL) + panic("legacy_attach cpu"); + device_probe_and_attach(child); + } + +#ifndef PC98 /* - * First, let our child driver's identify any child devices that + * Second, let our child driver's identify any child devices that * they can find. Once that is done attach any devices that we * found. */ bus_generic_probe(dev); bus_generic_attach(dev); - /* Attach CPU pseudo-driver. */ - if (!devclass_get_device(devclass_find("cpu"), 0)) { - for (i = 0; i <= mp_maxid; i++) - if (!CPU_ABSENT(i)) { - pc = pcpu_find(i); - KASSERT(pc != NULL, ("pcpu_find failed")); - child = BUS_ADD_CHILD(dev, 0, "cpu", i); - if (child == NULL) - panic("legacy_attach cpu"); - device_probe_and_attach(child); - pc->pc_device = child; - device_set_ivars(child, pc); - } - } - -#ifndef PC98 /* * If we didn't see EISA or ISA on a pci bridge, create some * connection points now so they show up "on motherboard". @@ -265,6 +259,14 @@ */ static int cpu_read_ivar(device_t dev, device_t child, int index, uintptr_t *result); +static device_t cpu_add_child(device_t bus, int order, const char *name, + int unit); +static struct resource_list *cpu_get_rlist(device_t dev, device_t child); + +struct cpu_device { + struct resource_list cd_rl; + struct pcpu *cd_pcpu; +}; static device_method_t cpu_methods[] = { /* Device interface */ @@ -276,10 +278,15 @@ DEVMETHOD(device_resume, bus_generic_resume), /* Bus interface */ + DEVMETHOD(bus_add_child, cpu_add_child), DEVMETHOD(bus_read_ivar, cpu_read_ivar), DEVMETHOD(bus_print_child, bus_generic_print_child), - DEVMETHOD(bus_alloc_resource, bus_generic_alloc_resource), - DEVMETHOD(bus_release_resource, bus_generic_release_resource), + DEVMETHOD(bus_get_resource_list, cpu_get_rlist), + DEVMETHOD(bus_get_resource, bus_generic_rl_get_resource), + DEVMETHOD(bus_set_resource, bus_generic_rl_set_resource), + DEVMETHOD(bus_alloc_resource, bus_generic_rl_alloc_resource), + DEVMETHOD(bus_release_resource, bus_generic_rl_release_resource), + DEVMETHOD(bus_driver_added, bus_generic_driver_added), DEVMETHOD(bus_activate_resource, bus_generic_activate_resource), DEVMETHOD(bus_deactivate_resource, bus_generic_deactivate_resource), DEVMETHOD(bus_setup_intr, bus_generic_setup_intr), @@ -293,19 +300,50 @@ cpu_methods, 1, /* no softc */ }; -static devclass_t cpu_devclass; +devclass_t cpu_devclass; DRIVER_MODULE(cpu, legacy, cpu_driver, cpu_devclass, 0, 0); +static device_t +cpu_add_child(device_t bus, int order, const char *name, int unit) +{ + struct cpu_device *cd; + device_t child; + struct pcpu *pc; + + if ((cd = malloc(sizeof(*cd), M_DEVBUF, M_NOWAIT | M_ZERO)) == NULL) + return (NULL); + + resource_list_init(&cd->cd_rl); + pc = pcpu_find(unit); + KASSERT(pc != NULL, ("pcpu_find failed")); + cd->cd_pcpu = pc; + + child = device_add_child_ordered(bus, order, name, unit); + if (child != NULL) { + pc->pc_device = child; + device_set_ivars(child, cd); + } else + free(cd, M_DEVBUF); + return (child); +} + +static struct resource_list * +cpu_get_rlist(device_t dev, device_t child) +{ + struct cpu_device *cpdev; + + cpdev = device_get_ivars(child); + return (&cpdev->cd_rl); +} + static int cpu_read_ivar(device_t dev, device_t child, int index, uintptr_t *result) { - struct pcpu *pc; + struct cpu_device *cpdev; - if (index != 0) - return (ENOENT); - pc = device_get_ivars(child); - if (pc == NULL) + if (index != CPU_IVAR_PCPU) return (ENOENT); - *result = (uintptr_t)pc; + cpdev = device_get_ivars(dev); + *result = (uintptr_t)cpdev->cd_pcpu; return (0); } Index: ia64/ia64/machdep.c =================================================================== RCS file: /home/ncvs/src/sys/ia64/ia64/machdep.c,v --- ia64/ia64/machdep.c.orig Wed Feb 2 11:45:03 2005 +++ ia64/ia64/machdep.c Wed Feb 2 12:40:02 2005 @@ -34,6 +34,7 @@ #include #include +#include #include #include #include @@ -283,6 +284,17 @@ { ia64_efi_runtime->ResetSystem(EfiResetWarm, EFI_SUCCESS, 0, 0); +} + +/* Get current clock frequency for the given cpu id. */ +int +cpu_est_clockrate(int cpu_id, uint64_t *rate) +{ + + if (pcpu_find(cpu_id) == NULL || rate == NULL) + return (EINVAL); + *rate = processor_frequency; + return (0); } void Index: sparc64/sparc64/machdep.c =================================================================== RCS file: /home/ncvs/src/sys/sparc64/sparc64/machdep.c,v --- sparc64/sparc64/machdep.c.orig Sat Nov 20 19:47:34 2004 +++ sparc64/sparc64/machdep.c Wed Feb 2 12:40:02 2005 @@ -44,6 +44,7 @@ #include #include #include +#include #include #include #include @@ -671,6 +672,14 @@ cpu_mp_shutdown(); #endif openfirmware_exit(args); +} + +/* Get current clock frequency for the given cpu id. */ +int +cpu_est_clockrate(int cpu_id, uint64_t *rate) +{ + + return (ENXIO); } /* Index: dev/acpica/acpi_cpu.c =================================================================== RCS file: /home/ncvs/src/sys/dev/acpica/acpi_cpu.c,v --- dev/acpica/acpi_cpu.c.orig Sat Nov 20 19:47:24 2004 +++ dev/acpica/acpi_cpu.c Wed Feb 2 12:40:02 2005 @@ -1,5 +1,5 @@ /*- - * Copyright (c) 2003 Nate Lawson (SDG) + * Copyright (c) 2003-2005 Nate Lawson (SDG) * Copyright (c) 2001 Michael Smith * All rights reserved. * @@ -71,7 +71,8 @@ struct acpi_cpu_softc { device_t cpu_dev; ACPI_HANDLE cpu_handle; - uint32_t acpi_id; /* ACPI processor id */ + struct pcpu *cpu_pcpu; + uint32_t cpu_acpi_id; /* ACPI processor id */ uint32_t cpu_p_blk; /* ACPI P_BLK location */ uint32_t cpu_p_blk_len; /* P_BLK length (must be 6). */ struct resource *cpu_p_cnt; /* Throttling control register */ @@ -80,6 +81,10 @@ int cpu_prev_sleep;/* Last idle sleep duration. */ }; +struct acpi_cpu_device { + struct resource_list ad_rl; +}; + #define CPU_GET_REG(reg, width) \ (bus_space_read_ ## width(rman_get_bustag((reg)), \ rman_get_bushandle((reg)), 0)) @@ -127,6 +132,8 @@ static u_int cpu_cx_stats[MAX_CX_STATES];/* Cx usage history. */ /* Values for sysctl. */ +static struct sysctl_ctx_list acpi_cpu_sysctl_ctx; +static struct sysctl_oid *acpi_cpu_sysctl_tree; static uint32_t cpu_throttle_state; static uint32_t cpu_throttle_max; static int cpu_cx_lowest; @@ -137,13 +144,15 @@ static struct acpi_cpu_softc **cpu_softc; ACPI_SERIAL_DECL(cpu, "ACPI CPU"); -static struct sysctl_ctx_list acpi_cpu_sysctl_ctx; -static struct sysctl_oid *acpi_cpu_sysctl_tree; - static int acpi_cpu_probe(device_t dev); static int acpi_cpu_attach(device_t dev); static int acpi_pcpu_get_id(uint32_t idx, uint32_t *acpi_id, - uint32_t *cpu_id); + uint32_t *cpu_id); +static struct resource_list *acpi_cpu_get_rlist(device_t dev, device_t child); +static device_t acpi_cpu_add_child(device_t dev, int order, const char *name, + int unit); +static int acpi_cpu_read_ivar(device_t dev, device_t child, int index, + uintptr_t *result); static int acpi_cpu_shutdown(device_t dev); static int acpi_cpu_throttle_probe(struct acpi_cpu_softc *sc); static int acpi_cpu_cx_probe(struct acpi_cpu_softc *sc); @@ -163,7 +172,24 @@ /* Device interface */ DEVMETHOD(device_probe, acpi_cpu_probe), DEVMETHOD(device_attach, acpi_cpu_attach), + DEVMETHOD(device_detach, bus_generic_detach), DEVMETHOD(device_shutdown, acpi_cpu_shutdown), + DEVMETHOD(device_suspend, bus_generic_suspend), + DEVMETHOD(device_resume, bus_generic_resume), + + /* Bus interface */ + DEVMETHOD(bus_add_child, acpi_cpu_add_child), + DEVMETHOD(bus_read_ivar, acpi_cpu_read_ivar), + DEVMETHOD(bus_get_resource_list, acpi_cpu_get_rlist), + DEVMETHOD(bus_get_resource, bus_generic_rl_get_resource), + DEVMETHOD(bus_set_resource, bus_generic_rl_set_resource), + DEVMETHOD(bus_alloc_resource, bus_generic_rl_alloc_resource), + DEVMETHOD(bus_release_resource, bus_generic_rl_release_resource), + DEVMETHOD(bus_driver_added, bus_generic_driver_added), + DEVMETHOD(bus_activate_resource, bus_generic_activate_resource), + DEVMETHOD(bus_deactivate_resource, bus_generic_deactivate_resource), + DEVMETHOD(bus_setup_intr, bus_generic_setup_intr), + DEVMETHOD(bus_teardown_intr, bus_generic_teardown_intr), {0, 0} }; @@ -174,8 +200,8 @@ sizeof(struct acpi_cpu_softc), }; -static devclass_t acpi_cpu_devclass; -DRIVER_MODULE(cpu, acpi, acpi_cpu_driver, acpi_cpu_devclass, 0, 0); +extern devclass_t cpu_devclass; +DRIVER_MODULE(cpu, acpi, acpi_cpu_driver, cpu_devclass, 0, 0); MODULE_DEPEND(cpu, acpi, 1, 1, 1); static int @@ -265,17 +291,22 @@ { ACPI_BUFFER buf; ACPI_OBJECT *obj; + struct pcpu *pcpu_data; struct acpi_cpu_softc *sc; struct acpi_softc *acpi_sc; ACPI_STATUS status; - int thr_ret, cx_ret; + int cx_ret, cpu_id, thr_ret; ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__); sc = device_get_softc(dev); sc->cpu_dev = dev; sc->cpu_handle = acpi_get_handle(dev); - cpu_softc[acpi_get_magic(dev)] = sc; + cpu_id = acpi_get_magic(dev); + cpu_softc[cpu_id] = sc; + pcpu_data = pcpu_find(cpu_id); + pcpu_data->pc_device = dev; + sc->cpu_pcpu = pcpu_data; buf.Pointer = NULL; buf.Length = ACPI_ALLOCATE_BUFFER; @@ -288,7 +319,7 @@ obj = (ACPI_OBJECT *)buf.Pointer; sc->cpu_p_blk = obj->Processor.PblkAddress; sc->cpu_p_blk_len = obj->Processor.PblkLength; - sc->acpi_id = obj->Processor.ProcId; + sc->cpu_acpi_id = obj->Processor.ProcId; AcpiOsFree(obj); ACPI_DEBUG_PRINT((ACPI_DB_INFO, "acpi_cpu%d: P_BLK at %#x/%d\n", device_get_unit(dev), sc->cpu_p_blk, sc->cpu_p_blk_len)); @@ -296,8 +327,8 @@ acpi_sc = acpi_device_get_parent_softc(dev); sysctl_ctx_init(&acpi_cpu_sysctl_ctx); acpi_cpu_sysctl_tree = SYSCTL_ADD_NODE(&acpi_cpu_sysctl_ctx, - SYSCTL_CHILDREN(acpi_sc->acpi_sysctl_tree), - OID_AUTO, "cpu", CTLFLAG_RD, 0, ""); + SYSCTL_CHILDREN(acpi_sc->acpi_sysctl_tree), OID_AUTO, "cpu", + CTLFLAG_RD, 0, ""); /* * Probe for throttling and Cx state support. @@ -314,7 +345,11 @@ sysctl_ctx_free(&acpi_cpu_sysctl_ctx); } - return_VALUE (0); + /* Call identify and then probe/attach for cpu child drivers. */ + bus_generic_probe(dev); + bus_generic_attach(dev); + + return (0); } /* @@ -353,11 +388,61 @@ return (ESRCH); } +static struct resource_list * +acpi_cpu_get_rlist(device_t dev, device_t child) +{ + struct acpi_cpu_device *ad; + + ad = device_get_ivars(child); + if (ad == NULL) + return (NULL); + return (&ad->ad_rl); +} + +static device_t +acpi_cpu_add_child(device_t dev, int order, const char *name, int unit) +{ + struct acpi_cpu_device *ad; + device_t child; + + if ((ad = malloc(sizeof(*ad), M_TEMP, M_NOWAIT | M_ZERO)) == NULL) + return (NULL); + + resource_list_init(&ad->ad_rl); + + child = device_add_child_ordered(dev, order, name, unit); + if (child != NULL) + device_set_ivars(child, ad); + return (child); +} + +static int +acpi_cpu_read_ivar(device_t dev, device_t child, int index, uintptr_t *result) +{ + struct acpi_cpu_softc *sc; + + sc = device_get_softc(dev); + switch (index) { + case ACPI_IVAR_HANDLE: + *result = (uintptr_t)sc->cpu_handle; + break; + case CPU_IVAR_PCPU: + *result = (uintptr_t)sc->cpu_pcpu; + break; + default: + return (ENOENT); + } + return (0); +} + static int acpi_cpu_shutdown(device_t dev) { ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__); + /* Allow children to shutdown first. */ + bus_generic_shutdown(dev); + /* Disable any entry to the idle function. */ cpu_cx_count = 0; @@ -668,7 +753,7 @@ int count, i; /* Get set of CPU devices */ - devclass_get_devices(acpi_cpu_devclass, &cpu_devices, &cpu_ndevices); + devclass_get_devices(cpu_devclass, &cpu_devices, &cpu_ndevices); /* Check for quirks via the first CPU device. */ sc = device_get_softc(cpu_devices[0]); Index: dev/acpica/acpi_perf.c =================================================================== RCS file: dev/acpica/acpi_perf.c diff -N dev/acpica/acpi_perf.c --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ dev/acpica/acpi_perf.c 1 Feb 2005 16:32:55 -0000 @@ -0,0 +1,420 @@ +/*- + * Copyright (c) 2003-2005 Nate Lawson (SDG) + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ + +#include +__FBSDID("$FreeBSD$"); + +#include "opt_acpi.h" +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include + +#include "acpi.h" +#include + +#include "cpufreq_if.h" + +/* + * Support for ACPI processor performance states (Px) according to + * section x of the ACPI specification. + */ + +struct acpi_px { + uint32_t core_freq; + uint32_t power; + uint32_t trans_lat; + uint32_t bm_lat; + uint32_t ctrl_val; + uint32_t sts_val; +}; + +#define MAX_PX_STATES 16 + +struct acpi_perf_softc { + device_t dev; + ACPI_HANDLE handle; + struct resource *perf_ctrl; /* Set new performance state. */ + struct resource *perf_status; /* Check that transition succeeded. */ + struct acpi_px *px_states; /* ACPI perf states. */ + uint32_t px_count; /* Total number of perf states. */ + uint32_t px_max_avail; /* Lowest index state available. */ + int px_curr_state; /* Active state index. */ + int px_rid; +}; + +#define PX_GET_REG(reg) \ + (bus_space_read_4(rman_get_bustag((reg)), \ + rman_get_bushandle((reg)), 0)) +#define PX_SET_REG(reg, val) \ + (bus_space_write_4(rman_get_bustag((reg)), \ + rman_get_bushandle((reg)), 0, (val))) + +static void acpi_perf_identify(driver_t *driver, device_t parent); +static int acpi_perf_probe(device_t dev); +static int acpi_perf_attach(device_t dev); +static int acpi_perf_detach(device_t dev); +static int acpi_perf_evaluate(device_t dev); +static int acpi_px_to_set(device_t dev, struct acpi_px *px, + struct cf_setting *set); +static void acpi_px_available(struct acpi_perf_softc *sc); +static void acpi_px_notify(ACPI_HANDLE h, UINT32 notify, void *context); +static int acpi_px_settings(device_t dev, struct cf_setting *sets, + int *count, int *type); +static int acpi_px_set(device_t dev, const struct cf_setting *set); +static int acpi_px_get(device_t dev, struct cf_setting *set); + +static device_method_t acpi_perf_methods[] = { + /* Device interface */ + DEVMETHOD(device_identify, acpi_perf_identify), + DEVMETHOD(device_probe, acpi_perf_probe), + DEVMETHOD(device_attach, acpi_perf_attach), + DEVMETHOD(device_detach, acpi_perf_detach), + + /* cpufreq interface */ + DEVMETHOD(cpufreq_drv_set, acpi_px_set), + DEVMETHOD(cpufreq_drv_get, acpi_px_get), + DEVMETHOD(cpufreq_drv_settings, acpi_px_settings), + {0, 0} +}; + +static driver_t acpi_perf_driver = { + "acpi_perf", + acpi_perf_methods, + sizeof(struct acpi_perf_softc), +}; + +static devclass_t acpi_perf_devclass; +DRIVER_MODULE(acpi_perf, cpu, acpi_perf_driver, acpi_perf_devclass, 0, 0); +MODULE_DEPEND(acpi_perf, acpi, 1, 1, 1); + +MALLOC_DEFINE(M_ACPIPERF, "acpi_perf", "ACPI Performance states"); + +static void +acpi_perf_identify(driver_t *driver, device_t parent) +{ + device_t child; + ACPI_HANDLE handle; + + /* Make sure we're not being doubly invoked. */ + if (device_find_child(parent, "acpi_perf", 0) != NULL) + return; + + /* Get the handle for the Processor object and check for perf states. */ + handle = acpi_get_handle(parent); + if (handle == NULL) + return; + if (ACPI_FAILURE(AcpiEvaluateObject(handle, "_PSS", NULL, NULL))) + return; + if ((child = BUS_ADD_CHILD(parent, 0, "acpi_perf", 0)) == NULL) + device_printf(parent, "acpi_perf: add child failed\n"); +} + +static int +acpi_perf_probe(device_t dev) +{ + + device_set_desc(dev, "ACPI CPU Frequency Control"); + return (-10); +} + +static int +acpi_perf_attach(device_t dev) +{ + struct acpi_perf_softc *sc; + + sc = device_get_softc(dev); + sc->dev = dev; + sc->handle = acpi_get_handle(dev); + sc->px_max_avail = 0; + sc->px_curr_state = CPUFREQ_VAL_UNKNOWN; + if (acpi_perf_evaluate(dev) != 0) + return (ENXIO); + cpufreq_register(dev); + + return (0); +} + +static int +acpi_perf_detach(device_t dev) +{ + /* TODO: teardown registers, remove notify handler. */ + return (ENXIO); +} + +/* Probe and setup any valid performance states (Px). */ +static int +acpi_perf_evaluate(device_t dev) +{ + struct acpi_perf_softc *sc; + ACPI_BUFFER buf; + ACPI_OBJECT *pkg, *res; + ACPI_STATUS status; + int i, j; + uint32_t *p; + + /* Get the control values and parameters for each state. */ + sc = device_get_softc(dev); + buf.Pointer = NULL; + buf.Length = ACPI_ALLOCATE_BUFFER; + status = AcpiEvaluateObject(sc->handle, "_PSS", NULL, &buf); + if (ACPI_FAILURE(status)) + return (ENXIO); + + pkg = (ACPI_OBJECT *)buf.Pointer; + if (!ACPI_PKG_VALID(pkg, 1)) { + device_printf(dev, "invalid top level _PSS package\n"); + return (ENXIO); + } + sc->px_count = pkg->Package.Count; + + sc->px_states = malloc(sc->px_count * sizeof(struct acpi_px), + M_ACPIPERF, M_WAITOK | M_ZERO); + if (sc->px_states == NULL) + return (ENOMEM); + + /* + * Each state is a package of {CoreFreq, Power, TransitionLatency, + * BusMasterLatency, ControlVal, StatusVal}, sorted from highest + * performance to lowest. + */ + for (i = 0; i < sc->px_count; i++) { + res = &pkg->Package.Elements[i]; + if (!ACPI_PKG_VALID(res, 6)) { + device_printf(dev, "invalid _PSS package\n"); + continue; + } + p = &sc->px_states[i].core_freq; + for (j = 0; j < 6; j++, p++) + acpi_PkgInt32(res, j, p); + } + AcpiOsFree(buf.Pointer); + + /* Get the control and status registers (one of each). */ + buf.Pointer = NULL; + buf.Length = ACPI_ALLOCATE_BUFFER; + status = AcpiEvaluateObject(sc->handle, "_PCT", NULL, &buf); + if (ACPI_FAILURE(status)) { + free(sc->px_states, M_ACPIPERF); + return (ENXIO); + } + + /* Check the package of two registers, each a Buffer in GAS format. */ + pkg = (ACPI_OBJECT *)buf.Pointer; + if (!ACPI_PKG_VALID(pkg, 2)) { + device_printf(dev, "invalid perf register package\n"); + return (ENXIO); + } + + acpi_PkgGas(sc->dev, pkg, 0, &sc->px_rid, &sc->perf_ctrl); + if (sc->perf_ctrl == NULL) { + device_printf(dev, "failed to attach PERF_CTL register\n"); + return (ENXIO); + } + sc->px_rid++; + + acpi_PkgGas(sc->dev, pkg, 1, &sc->px_rid, &sc->perf_status); + if (sc->perf_status == NULL) { + device_printf(dev, "failed to attach PERF_STATUS register\n"); + return (ENXIO); + } + sc->px_rid++; + AcpiOsFree(buf.Pointer); + + /* Get our current limit and register for notifies. */ + acpi_px_available(sc); + AcpiInstallNotifyHandler(sc->handle, ACPI_DEVICE_NOTIFY, + acpi_px_notify, sc); + + return (0); +} + +static void +acpi_px_notify(ACPI_HANDLE h, UINT32 notify, void *context) +{ + struct acpi_perf_softc *sc; + + sc = context; + acpi_px_available(sc); + + /* TODO: Implement notification when frequency changes. */ +} + +/* + * Find the highest currently-supported performance state. + * This can be called at runtime (e.g., due to a docking event) at + * the request of a Notify on the processor object. + */ +static void +acpi_px_available(struct acpi_perf_softc *sc) +{ + ACPI_STATUS status; + struct cf_setting set; + + status = acpi_GetInteger(sc->handle, "_PPC", &sc->px_max_avail); + + /* If the old state is too high, set current state to the new max. */ + if (ACPI_SUCCESS(status)) { + if (sc->px_curr_state != CPUFREQ_VAL_UNKNOWN && + sc->px_curr_state > sc->px_max_avail) { + acpi_px_to_set(sc->dev, + &sc->px_states[sc->px_max_avail], &set); + acpi_px_set(sc->dev, &set); + } + } else + sc->px_max_avail = 0; +} + +static int +acpi_px_to_set(device_t dev, struct acpi_px *px, struct cf_setting *set) +{ + + if (px == NULL || set == NULL) + return (EINVAL); + + set->freq = px->core_freq; + set->power = px->power; + /* XXX Include BM latency too? */ + set->lat = px->trans_lat; + set->volts = CPUFREQ_VAL_UNKNOWN; + set->dev = dev; + + return (0); +} + +static int +acpi_px_settings(device_t dev, struct cf_setting *sets, int *count, int *type) +{ + struct acpi_perf_softc *sc; + int x, y; + + sc = device_get_softc(dev); + if (sets == NULL || count == NULL) + return (EINVAL); + if (*count < sc->px_count - sc->px_max_avail) + return (ENOMEM); + + /* Return a list of settings that are currently valid. */ + y = 0; + for (x = sc->px_max_avail; x < sc->px_count; x++, y++) + acpi_px_to_set(dev, &sc->px_states[x], &sets[y]); + *count = sc->px_count - sc->px_max_avail; + *type = CPUFREQ_TYPE_ABSOLUTE; + + return (0); +} + +static int +acpi_px_set(device_t dev, const struct cf_setting *set) +{ + struct acpi_perf_softc *sc; + int i, status, sts_val, tries; + + if (set == NULL) + return (EINVAL); + sc = device_get_softc(dev); + + /* Look up appropriate state, based on frequency. */ + for (i = sc->px_max_avail; i < sc->px_count; i++) { + if (CPUFREQ_CMP(set->freq, sc->px_states[i].core_freq)) + break; + } + if (i == sc->px_count) + return (EINVAL); + + /* Write the appropriate value to the register. */ + PX_SET_REG(sc->perf_ctrl, sc->px_states[i].ctrl_val); + + /* Try for up to 1 ms to verify the desired state was selected. */ + sts_val = sc->px_states[i].sts_val; + for (tries = 0; tries < 100; tries++) { + status = PX_GET_REG(sc->perf_status); + if (status == sts_val) + break; + DELAY(10); + } + if (tries == 100) { + device_printf(dev, "Px transition to %d failed\n", + sc->px_states[i].core_freq); + return (ENXIO); + } + sc->px_curr_state = i; + + return (0); +} + +static int +acpi_px_get(device_t dev, struct cf_setting *set) +{ + struct acpi_perf_softc *sc; + uint64_t rate; + int i; + struct pcpu *pc; + + if (set == NULL) + return (EINVAL); + sc = device_get_softc(dev); + + /* If we've set the rate before, use the cached value. */ + if (sc->px_curr_state != CPUFREQ_VAL_UNKNOWN) { + acpi_px_to_set(dev, &sc->px_states[sc->px_curr_state], set); + return (0); + } + + /* Otherwise, estimate and try to match against our settings. */ + pc = cpu_get_pcpu(dev); + if (pc == NULL) + return (ENXIO); + cpu_est_clockrate(pc->pc_cpuid, &rate); + rate /= 1000000; + for (i = 0; i < sc->px_count; i++) { + if (CPUFREQ_CMP(sc->px_states[i].core_freq, rate)) { + sc->px_curr_state = i; + acpi_px_to_set(dev, &sc->px_states[i], set); + break; + } + } + + /* No match, give up. */ + if (i == sc->px_count) { + sc->px_curr_state = CPUFREQ_VAL_UNKNOWN; + set->freq = CPUFREQ_VAL_UNKNOWN; + } + + return (0); +} Index: kern/cpufreq_if.m =================================================================== RCS file: kern/cpufreq_if.m diff -N kern/cpufreq_if.m --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ kern/cpufreq_if.m 1 Feb 2005 05:49:04 -0000 @@ -0,0 +1,92 @@ +# +# Copyright (c) 2004 Nate Lawson +# All rights reserved. +# +# Redistribution and use in source and binary forms, with or without +# modification, are permitted provided that the following conditions +# are met: +# 1. Redistributions of source code must retain the above copyright +# notice, this list of conditions and the following disclaimer. +# 2. Redistributions in binary form must reproduce the above copyright +# notice, this list of conditions and the following disclaimer in the +# documentation and/or other materials provided with the distribution. +# +# THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND +# ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE +# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE +# ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE +# FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL +# DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS +# OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) +# HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT +# LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY +# OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF +# SUCH DAMAGE. +# +# $FreeBSD$ +# + +#include + +INTERFACE cpufreq; + +HEADER { + struct cf_level; + struct cf_setting; +}; + +# cpufreq interface methods + +# +# Set the current CPU frequency level. +# +METHOD int set { + device_t dev; + const struct cf_level *level; + int priority; +}; + +# +# Get the current active level. +# +METHOD int get { + device_t dev; + struct cf_level *level; +}; + +# +# Get the current possible levels, based on all drivers. +# +METHOD int levels { + device_t dev; + struct cf_level *levels; + int *count; +}; + +# Individual frequency driver methods + +# +# Set an individual driver's setting. +# +METHOD int drv_set { + device_t dev; + const struct cf_setting *set; +}; + +# +# Get an individual driver's setting. +# +METHOD int drv_get { + device_t dev; + struct cf_setting *set; +}; + +# +# Get the settings supported by a driver. +# +METHOD int drv_settings { + device_t dev; + struct cf_setting *sets; + int *count; + int *type; +}; Index: kern/kern_cpu.c =================================================================== RCS file: kern/kern_cpu.c diff -N kern/kern_cpu.c --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ kern/kern_cpu.c 1 Feb 2005 07:15:16 -0000 @@ -0,0 +1,533 @@ +/*- + * Copyright (c) 2004-2005 Nate Lawson (SDG) + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ + +#include +__FBSDID("$FreeBSD$"); + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include "cpufreq_if.h" + +/* + * Common CPU frequency glue code. Drivers for specific hardware can + * attach this interface to allow users to get/set the CPU frequency. + */ + +/* + * Number of levels we can handle. Levels are synthesized from settings + * so for N settings there may be N^2 levels. + */ +#define CF_MAX_LEVELS 32 + +struct cpufreq_softc { + struct cf_level curr_level; + int priority; + struct cf_level_lst all_levels; + device_t dev; + struct sysctl_ctx_list sysctl_ctx; +}; + +struct cf_setting_array { + struct cf_setting sets[MAX_SETTINGS]; + int count; + TAILQ_ENTRY(cf_setting_array) link; +}; + +TAILQ_HEAD(cf_setting_lst, cf_setting_array); + +static int cpufreq_attach(device_t dev); +static int cpufreq_detach(device_t dev); +static void cpufreq_evaluate(void *arg); +static int cf_set_method(device_t dev, const struct cf_level *level, + int priority); +static int cf_get_method(device_t dev, struct cf_level *level); +static int cf_levels_method(device_t dev, struct cf_level *levels, + int *count); +static int cpufreq_insert_abs(struct cf_level_lst *list, + struct cf_setting *sets, int count); +static int cpufreq_curr_sysctl(SYSCTL_HANDLER_ARGS); +static int cpufreq_levels_sysctl(SYSCTL_HANDLER_ARGS); + +static device_method_t cpufreq_methods[] = { + DEVMETHOD(device_probe, bus_generic_probe), + DEVMETHOD(device_attach, cpufreq_attach), + DEVMETHOD(device_detach, cpufreq_detach), + + DEVMETHOD(cpufreq_set, cf_set_method), + DEVMETHOD(cpufreq_get, cf_get_method), + DEVMETHOD(cpufreq_levels, cf_levels_method), + {0, 0} +}; +static driver_t cpufreq_driver = { + "cpufreq", cpufreq_methods, sizeof(struct cpufreq_softc) +}; +static devclass_t cpufreq_dc; +DRIVER_MODULE(cpufreq, cpu, cpufreq_driver, cpufreq_dc, 0, 0); + +static eventhandler_tag cf_ev_tag; + +static int +cpufreq_attach(device_t dev) +{ + struct cpufreq_softc *sc; + device_t parent; + int numdevs; + + sc = device_get_softc(dev); + parent = device_get_parent(dev); + sc->dev = dev; + sysctl_ctx_init(&sc->sysctl_ctx); + TAILQ_INIT(&sc->all_levels); + sc->curr_level.total_set.freq = CPUFREQ_VAL_UNKNOWN; + + /* + * Only initialize one set of sysctls for all CPUs. In the future, + * if multiple CPUs can have different settings, we can move these + * sysctls to be under every CPU instead of just the first one. + */ + numdevs = devclass_get_count(cpufreq_dc); + if (numdevs > 1) + return (0); + + SYSCTL_ADD_PROC(&sc->sysctl_ctx, + SYSCTL_CHILDREN(device_get_sysctl_tree(parent)), + OID_AUTO, "freq", CTLTYPE_INT | CTLFLAG_RW, sc, 0, + cpufreq_curr_sysctl, "I", "Current CPU frequency"); + SYSCTL_ADD_PROC(&sc->sysctl_ctx, + SYSCTL_CHILDREN(device_get_sysctl_tree(parent)), + OID_AUTO, "freq_levels", CTLTYPE_STRING | CTLFLAG_RD, sc, 0, + cpufreq_levels_sysctl, "A", "CPU frequency levels"); + cf_ev_tag = EVENTHANDLER_REGISTER(cpufreq_changed, cpufreq_evaluate, + NULL, EVENTHANDLER_PRI_ANY); + + return (0); +} + +static int +cpufreq_detach(device_t dev) +{ + struct cpufreq_softc *sc; + int numdevs; + + sc = device_get_softc(dev); + sysctl_ctx_free(&sc->sysctl_ctx); + + /* Only clean up these resources when the last device is detaching. */ + numdevs = devclass_get_count(cpufreq_dc); + if (numdevs == 1) + EVENTHANDLER_DEREGISTER(cpufreq_changed, cf_ev_tag); + + return (0); +} + +static void +cpufreq_evaluate(void *arg) +{ + /* TODO: Re-evaluate when notified of changes to drivers. */ +} + +static int +cf_set_method(device_t dev, const struct cf_level *level, int priority) +{ + struct cpufreq_softc *sc; + const struct cf_setting *set; + int error; + + sc = device_get_softc(dev); + + /* If already at this level, just return. */ + if (CPUFREQ_CMP(sc->curr_level.total_set.freq, level->total_set.freq)) + return (0); + + /* First, set the absolute frequency via its driver. */ + set = &level->abs_set; + if (set->dev) { + if (!device_is_attached(set->dev)) { + error = ENXIO; + goto out; + } + error = CPUFREQ_DRV_SET(set->dev, set); + if (error) { + goto out; + } + } + + /* TODO: Next, set any/all relative frequencies via their drivers. */ + + /* Record the current level. */ + sc->curr_level = *level; + sc->priority = priority; + error = 0; + +out: + if (error) + device_printf(set->dev, "set freq failed, err %d\n", error); + return (error); +} + +static int +cf_get_method(device_t dev, struct cf_level *level) +{ + struct cpufreq_softc *sc; + struct cf_level *levels; + struct cf_setting *curr_set, set; + struct pcpu *pc; + device_t *devs; + int count, error, i, numdevs; + uint64_t rate; + + sc = device_get_softc(dev); + curr_set = &sc->curr_level.total_set; + levels = NULL; + + /* If we already know the current frequency, we're done. */ + if (curr_set->freq != CPUFREQ_VAL_UNKNOWN) + goto out; + + /* + * We need to figure out the current level. Loop through every + * driver, getting the current setting. Then, attempt to get a best + * match of settings against each level. + */ + count = CF_MAX_LEVELS; + levels = malloc(count * sizeof(*levels), M_TEMP, M_NOWAIT); + if (levels == NULL) + return (ENOMEM); + error = CPUFREQ_LEVELS(sc->dev, levels, &count); + if (error) + goto out; + error = device_get_children(device_get_parent(dev), &devs, &numdevs); + if (error) + goto out; + for (i = 0; i < numdevs && curr_set->freq == CPUFREQ_VAL_UNKNOWN; i++) { + if (!device_is_attached(devs[i])) + continue; + error = CPUFREQ_DRV_GET(devs[i], &set); + if (error) + continue; + for (i = 0; i < count; i++) { + if (CPUFREQ_CMP(set.freq, levels[i].abs_set.freq)) { + sc->curr_level = levels[i]; + break; + } + } + } + free(devs, M_TEMP); + if (curr_set->freq != CPUFREQ_VAL_UNKNOWN) + goto out; + + /* + * We couldn't find an exact match, so attempt to estimate and then + * match against a level. + */ + pc = cpu_get_pcpu(dev); + if (pc == NULL) { + error = ENXIO; + goto out; + } + cpu_est_clockrate(pc->pc_cpuid, &rate); + rate /= 1000000; + for (i = 0; i < count; i++) { + if (CPUFREQ_CMP(rate, levels[i].total_set.freq)) { + sc->curr_level = levels[i]; + break; + } + } + +out: + if (levels) + free(levels, M_TEMP); + *level = sc->curr_level; + return (0); +} + +static int +cf_levels_method(device_t dev, struct cf_level *levels, int *count) +{ + TAILQ_HEAD(cf_setting_lst,cf_setting_array) rel_sets; + struct cpufreq_softc *sc; + struct cf_level *lev; + struct cf_setting *sets; + struct pcpu *pc; + device_t *devs; + int error, i, numdevs, numlevels, set_count, type; + uint64_t rate; + + if (levels == NULL || count == NULL) + return (EINVAL); + + TAILQ_INIT(&rel_sets); + sc = device_get_softc(dev); + error = device_get_children(device_get_parent(dev), &devs, &numdevs); + if (error) + return (error); + sets = malloc(MAX_SETTINGS * sizeof(*sets), M_TEMP, M_NOWAIT); + if (sets == NULL) { + free(devs, M_TEMP); + return (ENOMEM); + } + + /* Clear all previous levels. */ + while ((lev = TAILQ_FIRST(&sc->all_levels)) != NULL) { + TAILQ_REMOVE(&sc->all_levels, lev, link); + free(lev, M_TEMP); + } + + /* Get settings from all cpufreq drivers. */ + numlevels = 0; + for (i = 0; i < numdevs; i++) { + if (!device_is_attached(devs[i])) + continue; + set_count = MAX_SETTINGS; + error = CPUFREQ_DRV_SETTINGS(devs[i], sets, &set_count, &type); + if (error || set_count == 0) + continue; + error = cpufreq_insert_abs(&sc->all_levels, sets, set_count); + if (error) + goto out; + numlevels += set_count; + } + + /* If the caller doesn't have enough space, return the actual count. */ + if (numlevels > *count) { + *count = numlevels; + error = E2BIG; + goto out; + } + + /* If there are no absolute levels, create a fake one at 100%. */ + if (TAILQ_EMPTY(&sc->all_levels)) { + bzero(&sets[0], sizeof(*sets)); + pc = cpu_get_pcpu(dev); + if (pc == NULL) { + error = ENXIO; + goto out; + } + cpu_est_clockrate(pc->pc_cpuid, &rate); + sets[0].freq = rate / 1000000; + error = cpufreq_insert_abs(&sc->all_levels, sets, 1); + if (error) + goto out; + } + + /* TODO: Create a combined list of absolute + relative levels. */ + i = 0; + TAILQ_FOREACH(lev, &sc->all_levels, link) { + /* For now, just assume total freq equals absolute freq. */ + lev->total_set = lev->abs_set; + lev->total_set.dev = NULL; + levels[i] = *lev; + i++; + } + *count = i; + error = 0; + +out: + free(devs, M_TEMP); + free(sets, M_TEMP); + return (error); +} + +/* + * Create levels for an array of absolute settings and insert them in + * sorted order in the specified list. + */ +static int +cpufreq_insert_abs(struct cf_level_lst *list, struct cf_setting *sets, + int count) +{ + struct cf_level *level, *search; + int i; + + for (i = 0; i < count; i++) { + level = malloc(sizeof(*level), M_TEMP, M_NOWAIT); + if (level == NULL) + return (ENOMEM); + level->abs_set = sets[i]; + + if (TAILQ_EMPTY(list)) { + TAILQ_INSERT_HEAD(list, level, link); + continue; + } + + TAILQ_FOREACH_REVERSE(search, list, cf_level_lst, link) { + if (sets[i].freq <= search->abs_set.freq) { + TAILQ_INSERT_AFTER(list, search, level, link); + break; + } + } + } + return (0); +} + +static int +cpufreq_curr_sysctl(SYSCTL_HANDLER_ARGS) +{ + struct cpufreq_softc *sc; + struct cf_level *levels; + int count, error, freq, i; + + sc = oidp->oid_arg1; + count = CF_MAX_LEVELS; + levels = malloc(count * sizeof(*levels), M_TEMP, M_NOWAIT); + if (levels == NULL) + return (ENOMEM); + + error = CPUFREQ_GET(sc->dev, &levels[0]); + if (error) + goto out; + freq = levels[0].total_set.freq; + error = sysctl_handle_int(oidp, &freq, 0, req); + if (error != 0 || req->newptr == NULL) + goto out; + + error = CPUFREQ_LEVELS(sc->dev, levels, &count); + if (error) + goto out; + for (i = 0; i < count; i++) { + if (CPUFREQ_CMP(levels[i].total_set.freq, freq)) { + error = CPUFREQ_SET(sc->dev, &levels[i], + CPUFREQ_PRIO_USER); + break; + } + } + if (i == count) + error = EINVAL; + +out: + if (levels) + free(levels, M_TEMP); + return (error); +} + +static int +cpufreq_levels_sysctl(SYSCTL_HANDLER_ARGS) +{ + struct cpufreq_softc *sc; + struct cf_level *levels; + struct cf_setting *set; + struct sbuf sb; + int count, error, i; + + sc = oidp->oid_arg1; + sbuf_new(&sb, NULL, 128, SBUF_AUTOEXTEND); + + /* Get settings from the device and generate the output string. */ + count = CF_MAX_LEVELS; + levels = malloc(count * sizeof(*levels), M_TEMP, M_NOWAIT); + if (levels == NULL) + return (ENOMEM); + error = CPUFREQ_LEVELS(sc->dev, levels, &count); + if (error) + goto out; + if (count) { + for (i = 0; i < count; i++) { + set = &levels[i].total_set; + sbuf_printf(&sb, "%d/%d ", set->freq, set->power); + } + } else + sbuf_cpy(&sb, "0"); + sbuf_trim(&sb); + sbuf_finish(&sb); + error = sysctl_handle_string(oidp, sbuf_data(&sb), sbuf_len(&sb), req); + +out: + free(levels, M_TEMP); + sbuf_delete(&sb); + return (error); +} + +int +cpufreq_register(device_t dev) +{ + device_t cf_dev, cpu_dev; + + /* + * Only add one cpufreq device (on cpu0) for all control. Once + * independent multi-cpu control appears, we can assign one cpufreq + * device per cpu. + */ + cf_dev = devclass_get_device(cpufreq_dc, 0); + if (cf_dev) { + device_printf(dev, + "warning: only one cpufreq device at a time supported\n"); + return (0); + } + + /* Add the child device and sysctls. */ + cpu_dev = devclass_get_device(devclass_find("cpu"), 0); + cf_dev = BUS_ADD_CHILD(cpu_dev, 0, "cpufreq", 0); + if (cf_dev == NULL) + return (ENOMEM); + device_quiet(cf_dev); + + return (device_probe_and_attach(cf_dev)); +} + +int +cpufreq_unregister(device_t dev) +{ + device_t cf_dev, *devs; + int cfcount, count, devcount, error, i, type; + struct cf_setting set; + + /* + * If this is the last cpufreq child device, remove the control + * device as well. We identify cpufreq children by calling a method + * they support. + */ + error = device_get_children(device_get_parent(dev), &devs, &devcount); + if (error) + return (error); + cf_dev = devclass_get_device(cpufreq_dc, 0); + KASSERT(cf_dev != NULL, ("unregister with no cpufreq dev")); + cfcount = 0; + for (i = 0; i < devcount; i++) { + if (!device_is_attached(devs[i])) + continue; + count = 1; + if (CPUFREQ_DRV_SETTINGS(devs[i], &set, &count, &type) == 0) + cfcount++; + } + if (cfcount <= 1) { + device_delete_child(device_get_parent(cf_dev), cf_dev); + } + free(devs, M_TEMP); + + return (0); +} Index: dev/cpufreq/speedstep_ich.c =================================================================== RCS file: dev/cpufreq/speedstep_ich.c diff -N dev/cpufreq/speedstep_ich.c --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ dev/cpufreq/speedstep_ich.c 1 Feb 2005 16:24:21 -0000 @@ -0,0 +1,372 @@ +/*- + * Copyright (c) 2004-2005 Nate Lawson (SDG) + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ + +#include +__FBSDID("$FreeBSD$"); + +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include + +#include "cpufreq_if.h" + +/* + * The SpeedStep ICH feature is a chipset-initiated voltage and frequency + * transition available on the ICH2M, 3M, and 4M. It is different from + * the newer Pentium-M SpeedStep feature. It offers only two levels of + * frequency/voltage. Often, the BIOS will select one of the levels via + * SMM code during the power-on process (i.e., choose a lower level if the + * system is off AC power.) + */ + +struct ichss_softc { + device_t dev; + int bm_rid; /* Bus-mastering control (PM2REG). */ + struct resource *bm_reg; + int ctrl_rid; /* Control/status register. */ + struct resource *ctrl_reg; + struct cf_setting sets[2]; /* Only two settings. */ +}; + +/* Supported PCI IDs. */ +#define PCI_VENDOR_INTEL 0x8086 +#define PCI_DEV_82801BA 0x244c /* ICH2M */ +#define PCI_DEV_82801CA 0x248c /* ICH3M */ +#define PCI_DEV_82801DB 0x24cc /* ICH4M */ +#define PCI_DEV_82815BA 0x1130 /* Unsupported/buggy part */ + +/* PCI config registers for finding PMBASE and enabling SpeedStep. */ +#define ICHSS_PMBASE_OFFSET 0x40 +#define ICHSS_PMCFG_OFFSET 0xa0 + +/* Values and masks. */ +#define ICHSS_ENABLE (1<<3) /* Enable SpeedStep control. */ +#define ICHSS_IO_REG 0x1 /* Access register via I/O space. */ +#define ICHSS_PMBASE_MASK 0xff80 /* PMBASE address bits. */ +#define ICHSS_CTRL_BIT 0x1 /* 0 is high speed, 1 is low. */ +#define ICHSS_BM_DISABLE 0x1 + +/* Offsets from PMBASE for various registers. */ +#define ICHSS_BM_OFFSET 0x20 +#define ICHSS_CTRL_OFFSET 0x50 + +#define ICH_GET_REG(reg) \ + (bus_space_read_1(rman_get_bustag((reg)), \ + rman_get_bushandle((reg)), 0)) +#define ICH_SET_REG(reg, val) \ + (bus_space_write_1(rman_get_bustag((reg)), \ + rman_get_bushandle((reg)), 0, (val))) + +static int ichss_pci_probe(device_t dev); +static int ichss_probe(device_t dev); +static int ichss_attach(device_t dev); +static int ichss_detach(device_t dev); +static int ichss_settings(device_t dev, struct cf_setting *sets, + int *count, int *type); +static int ichss_set(device_t dev, const struct cf_setting *set); +static int ichss_get(device_t dev, struct cf_setting *set); + +static device_method_t ichss_methods[] = { + /* Device interface */ + DEVMETHOD(device_probe, ichss_probe), + DEVMETHOD(device_attach, ichss_attach), + DEVMETHOD(device_detach, ichss_detach), + + /* cpufreq interface */ + DEVMETHOD(cpufreq_drv_set, ichss_set), + DEVMETHOD(cpufreq_drv_get, ichss_get), + DEVMETHOD(cpufreq_drv_settings, ichss_settings), + {0, 0} +}; +static driver_t ichss_driver = { + "ichss", ichss_methods, sizeof(struct ichss_softc) +}; +static devclass_t ichss_devclass; +DRIVER_MODULE(ichss, cpu, ichss_driver, ichss_devclass, 0, 0); + +static device_method_t ichss_pci_methods[] = { + DEVMETHOD(device_probe, ichss_pci_probe), + {0, 0} +}; +static driver_t ichss_pci_driver = { + "ichss_pci", ichss_pci_methods, 0 +}; +static devclass_t ichss_pci_devclass; +DRIVER_MODULE(ichss_pci, pci, ichss_pci_driver, ichss_pci_devclass, 0, 0); + +#if 0 +#define DPRINT(x...) printf(x) +#else +#define DPRINT(x...) +#endif + +/* + * We detect the chipset by looking for its LPC bus ID during the PCI + * scan and reading its config registers during the probe. However, + * we add the ichss child under the cpu device since even though the + * chipset provides the control, it really affects the cpu only. + * + * XXX This approach does not work if the module is loaded after boot. + */ +static int +ichss_pci_probe(device_t dev) +{ + device_t child, parent; + uint32_t pmbase; + uint16_t ss_en; + + /* + * TODO: add a quirk to disable if we see the 82815_MC along + * with the 82801BA and revision < 5. + */ + if (pci_get_vendor(dev) != PCI_VENDOR_INTEL || + (pci_get_device(dev) != PCI_DEV_82801BA && + pci_get_device(dev) != PCI_DEV_82801CA && + pci_get_device(dev) != PCI_DEV_82801DB)) + return (ENXIO); + + /* Only one CPU is supported for this hardware. */ + if (devclass_get_device(ichss_devclass, 0)) + return (ENXIO); + + /* Add a child under the CPU parent. */ + parent = devclass_get_device(devclass_find("cpu"), 0); + KASSERT(parent != NULL, ("cpu parent is NULL")); + child = BUS_ADD_CHILD(parent, 0, "ichss", 0); + if (child == NULL) { + device_printf(parent, "add SpeedStep child failed\n"); + return (ENXIO); + } + + /* Find the PMBASE register from our PCI config header. */ + pmbase = pci_read_config(dev, ICHSS_PMBASE_OFFSET, sizeof(pmbase)); + if ((pmbase & ICHSS_IO_REG) == 0) { + printf("ichss: invalid PMBASE memory type\n"); + return (ENXIO); + } + pmbase &= ICHSS_PMBASE_MASK; + if (pmbase == 0) { + printf("ichss: invalid zero PMBASE address\n"); + return (ENXIO); + } + DPRINT("ichss: PMBASE is %#x\n", pmbase); + + /* Add the bus master arbitration and control registers. */ + bus_set_resource(child, SYS_RES_IOPORT, 0, pmbase + ICHSS_BM_OFFSET, + 1); + bus_set_resource(child, SYS_RES_IOPORT, 1, pmbase + ICHSS_CTRL_OFFSET, + 1); + + /* Activate SpeedStep control if not already enabled. */ + ss_en = pci_read_config(dev, ICHSS_PMCFG_OFFSET, sizeof(ss_en)); + if ((ss_en & ICHSS_ENABLE) == 0) { + printf("ichss: enabling SpeedStep support\n"); + pci_write_config(dev, ICHSS_PMCFG_OFFSET, + ss_en | ICHSS_ENABLE, sizeof(ss_en)); + } + + /* Attach the new CPU child now. */ + device_probe_and_attach(child); + + return (ENXIO); +} + +static int +ichss_probe(device_t dev) +{ + device_t perf_dev; + + /* If the ACPI perf driver has attached, let it manage things. */ + perf_dev = devclass_get_device(devclass_find("acpi_perf"), 0); + if (perf_dev && device_is_attached(perf_dev)) + return (ENXIO); + + device_set_desc(dev, "SpeedStep ICH"); + return (-1000); +} + +static int +ichss_attach(device_t dev) +{ + struct ichss_softc *sc; + + sc = device_get_softc(dev); + sc->dev = dev; + + sc->bm_rid = 0; + sc->bm_reg = bus_alloc_resource_any(dev, SYS_RES_IOPORT, &sc->bm_rid, + RF_ACTIVE); + if (sc->bm_reg == NULL) { + device_printf(dev, "failed to alloc BM arb register\n"); + return (ENXIO); + } + sc->ctrl_rid = 1; + sc->ctrl_reg = bus_alloc_resource_any(dev, SYS_RES_IOPORT, + &sc->ctrl_rid, RF_ACTIVE); + if (sc->ctrl_reg == NULL) { + device_printf(dev, "failed to alloc control register\n"); + bus_release_resource(dev, SYS_RES_IOPORT, sc->bm_rid, + sc->bm_reg); + return (ENXIO); + } + + /* Setup some defaults for our exported settings. */ + sc->sets[0].freq = CPUFREQ_VAL_UNKNOWN; + sc->sets[0].volts = CPUFREQ_VAL_UNKNOWN; + sc->sets[0].power = CPUFREQ_VAL_UNKNOWN; + sc->sets[0].lat = 1000; + sc->sets[0].dev = dev; + sc->sets[1] = sc->sets[0]; + cpufreq_register(dev); + + return (0); +} + +static int +ichss_detach(device_t dev) +{ + /* TODO: teardown BM and CTRL registers. */ + return (ENXIO); +} + +static int +ichss_settings(device_t dev, struct cf_setting *sets, int *count, int *type) +{ + struct ichss_softc *sc; + struct cf_setting set; + int first, i; + + if (sets == NULL || count == NULL) + return (EINVAL); + if (*count < 2) { + *count = 2; + return (E2BIG); + } + sc = device_get_softc(dev); + + /* + * Estimate frequencies for both levels, temporarily switching to + * the other one if we haven't calibrated it yet. + */ + ichss_get(dev, &set); + for (i = 0; i < 2; i++) { + if (sc->sets[i].freq == CPUFREQ_VAL_UNKNOWN) { + first = (i == 0) ? 1 : 0; + ichss_set(dev, &sc->sets[i]); + ichss_set(dev, &sc->sets[first]); + } + } + + bcopy(sc->sets, sets, sizeof(sc->sets)); + *count = 2; + *type = CPUFREQ_TYPE_ABSOLUTE; + + return (0); +} + +static int +ichss_set(device_t dev, const struct cf_setting *set) +{ + struct ichss_softc *sc; + uint8_t bmval, new_val, old_val, req_val; + uint64_t rate; + + /* Look up appropriate bit value based on frequency. */ + sc = device_get_softc(dev); + if (CPUFREQ_CMP(set->freq, sc->sets[0].freq)) + req_val = 0; + else if (CPUFREQ_CMP(set->freq, sc->sets[1].freq)) + req_val = ICHSS_CTRL_BIT; + else + return (EINVAL); + DPRINT("ichss: requested setting %d\n", req_val); + + /* Disable interrupts and get the other register contents. */ + disable_intr(); + old_val = ICH_GET_REG(sc->ctrl_reg) & ~ICHSS_CTRL_BIT; + + /* + * Disable bus master arbitration, write the new value to the control + * register, and then re-enable bus master arbitration. + */ + bmval = ICH_GET_REG(sc->bm_reg) | ICHSS_BM_DISABLE; + ICH_SET_REG(sc->bm_reg, bmval); + ICH_SET_REG(sc->ctrl_reg, old_val | req_val); + ICH_SET_REG(sc->bm_reg, bmval & ~ICHSS_BM_DISABLE); + + /* Get the new value and re-enable interrupts. */ + new_val = ICH_GET_REG(sc->ctrl_reg); + enable_intr(); + + /* Check if the desired state was indeed selected. */ + if (req_val != (new_val & ICHSS_CTRL_BIT)) { + device_printf(sc->dev, "transition to %d failed\n", req_val); + return (ENXIO); + } + + /* Re-initialize our cycle counter if we don't know this new state. */ + if (sc->sets[req_val].freq == CPUFREQ_VAL_UNKNOWN) { + cpu_est_clockrate(0, &rate); + sc->sets[req_val].freq = rate / 1000000; + DPRINT("ichss: set calibrated new rate of %d\n", + sc->sets[req_val].freq); + } + + return (0); +} + +static int +ichss_get(device_t dev, struct cf_setting *set) +{ + struct ichss_softc *sc; + uint64_t rate; + uint8_t state; + + sc = device_get_softc(dev); + state = ICH_GET_REG(sc->ctrl_reg) & ICHSS_CTRL_BIT; + + /* If we haven't changed settings yet, estimate the current value. */ + if (sc->sets[state].freq == CPUFREQ_VAL_UNKNOWN) { + cpu_est_clockrate(0, &rate); + sc->sets[state].freq = rate / 1000000; + DPRINT("ichss: get calibrated new rate of %d\n", + sc->sets[state].freq); + } + *set = sc->sets[state]; + + return (0); +} Index: modules/Makefile =================================================================== RCS file: /home/ncvs/src/sys/modules/Makefile,v --- modules/Makefile.orig Tue Jan 4 09:36:38 2005 +++ modules/Makefile Wed Feb 2 12:40:02 2005 @@ -1,4 +1,4 @@ -# $FreeBSD: src/sys/modules/Makefile,v 1.393.2.6 2004/12/30 00:48:36 obrien Exp $ +# $FreeBSD: src/sys/modules/Makefile,v 1.400 2004/09/10 20:57:45 wpaul Exp $ # pcic -- currently broken and being worked on out of tree. # oldcard -- specialized use for debugging only. @@ -48,6 +48,7 @@ coda5 \ ${_coff} \ ${_cp} \ + cpufreq \ ${_crypto} \ ${_cryptodev} \ ${_ctau} \ Index: modules/acpi/Makefile =================================================================== RCS file: /home/ncvs/src/sys/modules/acpi/Makefile,v --- modules/acpi/Makefile.orig Wed Jul 21 10:28:16 2004 +++ modules/acpi/Makefile Wed Feb 2 12:46:29 2005 @@ -1,5 +1,6 @@ # $FreeBSD: src/sys/modules/acpi/Makefile,v 1.40 2004/07/21 14:47:54 nyan Exp $ -SUBDIR= acpi acpi_asus acpi_panasonic acpi_toshiba acpi_video +SUBDIR= acpi acpi_asus acpi_panasonic acpi_perf \ + acpi_toshiba acpi_video .include Index: modules/acpi/acpi_perf/Makefile =================================================================== RCS file: modules/acpi/acpi_perf/Makefile diff -N modules/acpi/acpi_perf/Makefile --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ modules/acpi/acpi_perf/Makefile 31 Jan 2005 06:00:37 -0000 @@ -0,0 +1,11 @@ +# $FreeBSD$ + +.PATH: ${.CURDIR}/../../../dev/acpica +CFLAGS+= -I${.CURDIR}/../../../contrib/dev/acpica + +KMOD= acpi_perf +WARNS?= 2 +SRCS= acpi_perf.c +SRCS+= acpi_if.h bus_if.h cpufreq_if.h device_if.h opt_acpi.h + +.include Index: conf/files =================================================================== RCS file: /home/ncvs/src/sys/conf/files,v --- conf/files.orig Thu Jan 27 10:06:48 2005 +++ conf/files Wed Feb 2 12:50:43 2005 @@ -1,4 +1,4 @@ -# $FreeBSD: src/sys/conf/files,v 1.943.2.6 2005/01/25 16:26:25 rik Exp $ +# $FreeBSD: src/sys/conf/files,v 1.953 2004/09/16 20:35:27 glebius Exp $ # # The long compile-with and dependency lines are required because of # limitations in config: backslash-newline doesn't work in strings, and @@ -58,6 +58,7 @@ kern/device_if.m standard kern/bus_if.m standard kern/clock_if.m optional genclock +kern/cpufreq_if.m standard kern/linker_if.m standard cam/cam.c optional scbus cam/cam_periph.c optional scbus @@ -1075,6 +1076,7 @@ kern/kern_condvar.c standard kern/kern_conf.c standard kern/kern_context.c standard +kern/kern_cpu.c standard kern/kern_descrip.c standard kern/kern_poll.c optional device_polling kern/kern_environment.c standard Index: conf/kmod.mk =================================================================== RCS file: /home/ncvs/src/sys/conf/kmod.mk,v --- conf/kmod.mk.orig Sat Aug 14 16:53:04 2004 +++ conf/kmod.mk Wed Feb 2 13:09:26 2005 @@ -290,7 +290,7 @@ .endfor .endif -MFILES?= kern/bus_if.m kern/device_if.m dev/iicbus/iicbb_if.m \ +MFILES?= kern/bus_if.m cpufreq_if.m kern/device_if.m dev/iicbus/iicbb_if.m \ dev/iicbus/iicbus_if.m isa/isa_if.m \ libkern/iconv_converter_if.m \ dev/acpica/acpi_if.m dev/eisa/eisa_if.m dev/mii/miibus_if.m \ --==_Exmh_-302709550-- From owner-freebsd-current@FreeBSD.ORG Thu Feb 3 03:28:01 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5183716A4CE for ; Thu, 3 Feb 2005 03:28:01 +0000 (GMT) Received: from www.mmlab.cse.yzu.edu.tw (www.mmlab.cse.yzu.edu.tw [140.138.150.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id AEADE43D2F for ; Thu, 3 Feb 2005 03:28:00 +0000 (GMT) (envelope-from avatar@mmlab.cse.yzu.edu.tw) Received: by www.mmlab.cse.yzu.edu.tw (qmail, from userid 1000) id AE2D04EFCDE; Thu, 3 Feb 2005 11:27:54 +0800 (CST) Received: from localhost (localhost [127.0.0.1]) by www.mmlab.cse.yzu.edu.tw (qmail) with ESMTP id A90304EFCDC; Thu, 3 Feb 2005 11:27:54 +0800 (CST) Date: Thu, 3 Feb 2005 11:27:54 +0800 (CST) From: Tai-hwa Liang To: Sam Leffler In-Reply-To: <41F2FED8.606@errno.com> Message-ID: <05020311245211.96098@www.mmlab.cse.yzu.edu.tw> References: <41F1E26E.8030200@errno.com> <41F2FED8.606@errno.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: Bryan Bunch cc: freebsd-current@freebsd.org Subject: Re: WPA with ath X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2005 03:28:01 -0000 On Sat, 22 Jan 2005, Sam Leffler wrote: > Bryan Bunch wrote: >> I'm trying to connect to a Linksys WRT54G. I have tested the card on >> the computer when booting up in XP and it connects fine via WPA. I >> also tested the card in CURRENT with WPA disabled and the card >> connected fine. > > There's nothing useful in the log you included. You can get the reason code > sent by the ap by enabling association debugging in the 802.11 layer. I > usually do this with the 80211debug program found in > /usr/src/tools/tools/ath. Something like > > 80211debug +assoc+auth > > should suffice. Messages go to the console. > > I've seen postings in various forums that this AP has issues with certain > firmware revs; you might check if your firmware is up to date. > > Past the above a packet trace is needed. Hi Bunch, According to WPA for 802.11i, section 2.2.2: The only unencrypted data packets allowed are unicast 802.1X data packets and unencrypted 802.1X data packets are only allowed when there is no Pairwise key between the station and AP otherwise unencrypted data packets must be discarded. I guess that's why your station being deauthenticated right after seeing "Group rekeying completed with..." since WPA requires station sending group EAPOL key in encrypted form once the pairwise key is available and installed. In my testing environment, -CURRENT if_ath + wpa_supplicant 0.3.0 always being kicked out by Buffalo AirStation G54 AP(firmware 2.20) after station completed the group key handshake; however, the same station/software configuration works flawlessly(read: only one 4-way handshake + 2 way group key exchange) with another Orinoco AP(which allows station to reply the last EAPOL successful message in plaintext). The attached patch works on my box. Would you please give it a try? -- Cheers, Tai-hwa Liang --- /sys/net80211/ieee80211_output.c.old Tue Jan 25 09:22:56 2005 +++ /sys/net80211/ieee80211_output.c Thu Feb 3 10:07:55 2005 @@ -563,7 +563,7 @@ */ if (eh.ether_type != htons(ETHERTYPE_PAE) || ((ic->ic_flags & IEEE80211_F_WPA) && - !KEY_UNDEFINED(ni->ni_ucastkey))) { + !KEY_UNDEFINED(*key))) { wh->i_fc[1] |= IEEE80211_FC1_WEP; /* XXX do fragmentation */ if (!ieee80211_crypto_enmic(ic, key, m)) { From owner-freebsd-current@FreeBSD.ORG Thu Feb 3 04:05:51 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A808416A4CE for ; Thu, 3 Feb 2005 04:05:51 +0000 (GMT) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4998A43D4C for ; Thu, 3 Feb 2005 04:05:51 +0000 (GMT) (envelope-from sam@errno.com) Received: from [66.127.85.91] (sam@[66.127.85.91]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.6) with ESMTP id j1345oWi064214 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Feb 2005 20:05:50 -0800 (PST) (envelope-from sam@errno.com) Message-ID: <4201A342.9010201@errno.com> Date: Wed, 02 Feb 2005 20:06:26 -0800 From: Sam Leffler User-Agent: Mozilla Thunderbird 1.0RC1 (X11/20041208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tai-hwa Liang References: <41F1E26E.8030200@errno.com> <41F2FED8.606@errno.com> <05020311245211.96098@www.mmlab.cse.yzu.edu.tw> In-Reply-To: <05020311245211.96098@www.mmlab.cse.yzu.edu.tw> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: Bryan Bunch cc: freebsd-current@freebsd.org Subject: Re: WPA with ath X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2005 04:05:51 -0000 Tai-hwa Liang wrote: > On Sat, 22 Jan 2005, Sam Leffler wrote: > >> Bryan Bunch wrote: >> >>> I'm trying to connect to a Linksys WRT54G. I have tested the card on >>> the computer when booting up in XP and it connects fine via WPA. I >>> also tested the card in CURRENT with WPA disabled and the card >>> connected fine. >> >> >> There's nothing useful in the log you included. You can get the >> reason code sent by the ap by enabling association debugging in the >> 802.11 layer. I usually do this with the 80211debug program found in >> /usr/src/tools/tools/ath. Something like >> >> 80211debug +assoc+auth >> >> should suffice. Messages go to the console. >> >> I've seen postings in various forums that this AP has issues with >> certain firmware revs; you might check if your firmware is up to date. >> >> Past the above a packet trace is needed. > > > Hi Bunch, > > According to WPA for 802.11i, section 2.2.2: > > The only unencrypted data packets allowed are unicast 802.1X > data packets and unencrypted 802.1X data packets are only > allowed when there is no Pairwise key between the station > and AP otherwise unencrypted data packets must be discarded. > > I guess that's why your station being deauthenticated right after > seeing "Group rekeying completed with..." since WPA requires station > sending group EAPOL key in encrypted form once the pairwise key is > available and installed. > > In my testing environment, -CURRENT if_ath + wpa_supplicant 0.3.0 > always being kicked out by Buffalo AirStation G54 AP(firmware 2.20) > after station completed the group key handshake; however, the same > station/software configuration works flawlessly(read: only one 4-way > handshake + 2 way group key exchange) with another Orinoco AP(which > allows station to reply the last EAPOL successful message in plaintext). > > The attached patch works on my box. Would you please give it a try? > Yes, that makes sense. wpa_supplicant sets up the unicast key in the shared key area and not in the per-node unicast key slot so we're checking the wrong place for a key. Thank you. Sam From owner-freebsd-current@FreeBSD.ORG Thu Feb 3 08:13:01 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A607B16A4CF for ; Thu, 3 Feb 2005 08:13:01 +0000 (GMT) Received: from mx3.imp.ch (mx3.imp.ch [157.161.9.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2076843D5D for ; Thu, 3 Feb 2005 08:13:00 +0000 (GMT) (envelope-from mb@imp.ch) Received: from mx3.imp.ch (localhost [127.0.0.1]) by mx3.imp.ch (8.12.11/8.12.11/Submit) with ESMTP id j138CsCe072622 for ; Thu, 3 Feb 2005 09:12:55 +0100 (CET) (envelope-from mb@imp.ch) Received: (from clamav@localhost) by mx3.imp.ch (8.12.11/8.12.11/Submit) id j138CsLq072619 for ; Thu, 3 Feb 2005 09:12:54 +0100 (CET) (envelope-from mb@imp.ch) Received: from cvs.imp.ch (cvs.imp.ch [157.161.4.9]) id j138CrS7065638; Thu, 03 Feb 2005 09:12:54 +0100 (CET) Date: Thu, 3 Feb 2005 09:12:53 +0100 (CET) From: Martin Blapp To: freebsd-current@freebsd.org Message-ID: <20050203090924.G55976@cvs.imp.ch> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: getline() very very slow on localhost on 5.X X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2005 08:13:01 -0000 Hi all, Can someone confirm that this is still a problem on 6.X ? Something is really broken here ... Martin FreeBSD 5.x connecting to localhost time perl5.6.1 -MIO::Socket -e '$s = new IO::Socket::INET("localhost:110"); $s->print("user USER\r\n"); $s->getline(); $s->print("pass PASS\r\n"); $s->getline(); $s->print("LIST\r\n"); for ($i = 1; $i < 2000; ++$i) { $j=1 + $i%500;$s->print("top $j 0\r\n"); } $s->print("quit\r\n"); while (defined($_ = $s->getline())) { print $_; }' > xxx real 2m9.509s user 0m0.559s sys 0m0.184s FreeBSD 5.x connecting to the external IP of the server time perl -MIO::Socket -e '$s = new IO::Socket::INET("server:110"); $s->print("user USER\r\n"); > $s->getline(); $s->print("pass PASS\r\n"); $s->getline(); $s->print("LIST\r\n"); for ($i = 1; $i > < 2000; ++$i) { $j=1 + $i%500;$s->print("top $j 0\r\n"); } $s->print("quit\r\n"); while (defined($_ > = $s->getline())) { print $_; }' > xxx real 0m6.932s user 0m0.553s sys 0m0.187s 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 Feb 3 09:39:25 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CDB5F16A4CE for ; Thu, 3 Feb 2005 09:39:25 +0000 (GMT) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 90E1F43D55 for ; Thu, 3 Feb 2005 09:39:25 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with SMTP id C861C46B24; Thu, 3 Feb 2005 04:39:24 -0500 (EST) Date: Thu, 3 Feb 2005 09:38:37 +0000 (GMT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Martin Blapp In-Reply-To: <20050203090924.G55976@cvs.imp.ch> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@freebsd.org Subject: Re: getline() very very slow on localhost on 5.X X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2005 09:39:25 -0000 On Thu, 3 Feb 2005, Martin Blapp wrote: > Can someone confirm that this is still a problem on 6.X ? Something is > really broken here ... Could you: (1) Try connecting to 127.0.0.1 instead of localhost? (2) If the problem persists, try writing a C based client to do the same thing? (3) Use tcpdump on lo0 to create a packet trace? What leads you to conclude that getline() is the problem, as opposed to the pop server, etc? Robert N M Watson > > Martin > > FreeBSD 5.x connecting to localhost > > time perl5.6.1 -MIO::Socket -e '$s = new IO::Socket::INET("localhost:110"); > $s->print("user USER\r\n"); > $s->getline(); $s->print("pass PASS\r\n"); $s->getline(); $s->print("LIST\r\n"); > for ($i = 1; $i > < 2000; ++$i) { $j=1 + $i%500;$s->print("top $j 0\r\n"); } > $s->print("quit\r\n"); while (defined($_ > = $s->getline())) { print $_; }' > xxx > > real 2m9.509s > user 0m0.559s > sys 0m0.184s > > FreeBSD 5.x connecting to the external IP of the server > > time perl -MIO::Socket -e '$s = new IO::Socket::INET("server:110"); > $s->print("user USER\r\n"); > > $s->getline(); $s->print("pass PASS\r\n"); $s->getline(); > $s->print("LIST\r\n"); > for ($i = 1; $i > > < 2000; ++$i) { $j=1 + $i%500;$s->print("top $j 0\r\n"); } > $s->print("quit\r\n"); while (defined($_ > > = $s->getline())) { print $_; }' > xxx > > real 0m6.932s > user 0m0.553s > sys 0m0.187s > > 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 > ------------------------------------------------------------------ > _______________________________________________ > 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 Feb 3 09:43:57 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4503916A4CE for ; Thu, 3 Feb 2005 09:43:57 +0000 (GMT) Received: from ppp162-47.static.internode.on.net (ppp162-47.static.internode.on.net [150.101.162.47]) by mx1.FreeBSD.org (Postfix) with ESMTP id B5B7843D1D for ; Thu, 3 Feb 2005 09:43:56 +0000 (GMT) (envelope-from emikulic@dmr.ath.cx) Received: by ppp162-47.static.internode.on.net (Poofix, from userid 1001) id 63A5F613B; Thu, 3 Feb 2005 20:43:55 +1100 (EST) Date: Thu, 3 Feb 2005 20:43:55 +1100 From: Emil Mikulic To: freebsd-current@freebsd.org Message-ID: <20050203094355.GA4767@dmr.ath.cx> Mail-Followup-To: Emil Mikulic , freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-PGP-ID: 1024D/344A699F X-PGP-Fingerprint: EE97 2C84 6D07 E76C F075 C0BA ED2A 9319 344A 699F X-Written-On: dmr.ath.cx (FreeBSD 6.0-CURRENT i386) User-Agent: Mutt/1.5.6i Subject: Can't see OpenBSD's slices X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2005 09:43:57 -0000 ad1 is a hard-drive taken from an OpenBSD machine that had / and swap and /tmp and /var and /usr on it (at least). The machine it's now in is running FreeBSD 6-CURRENT and it only sees one slice: $ ls /dev/ad1* /dev/ad1 /dev/ad1s4 I can mount this without any issues and it turns out to be the old root filesystem. Is there any way to get at the other filesystems on that disk? --Emil From owner-freebsd-current@FreeBSD.ORG Thu Feb 3 09:58:36 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0D10C16A4CE for ; Thu, 3 Feb 2005 09:58:36 +0000 (GMT) Received: from mailout10.sul.t-online.com (mailout10.sul.t-online.com [194.25.134.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id ACF4643D31 for ; Thu, 3 Feb 2005 09:58:35 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from fwd00.aul.t-online.de by mailout10.sul.t-online.com with smtp id 1Cwdkw-0005xb-03; Thu, 03 Feb 2005 10:58:34 +0100 Received: from Andro-Beta.Leidinger.net (VaxJHqZU8eVzz6imhIfcNmR+uqtD6nWnTYVckIO+t5eXbysuwt68U0@[84.128.192.121]) by fmrl00.sul.t-online.com with esmtp id 1Cwdkj-07BkHI0; Thu, 3 Feb 2005 10:58:21 +0100 Received: from localhost (localhost [127.0.0.1])j139w4I2036893; Thu, 3 Feb 2005 10:58:05 +0100 (CET) (envelope-from Alexander@Leidinger.net) Received: from 141.113.101.32 ([141.113.101.32]) by netchild.homeip.net (Horde) with HTTP for ; Thu, 3 Feb 2005 10:58:03 +0100 Message-ID: <20050203105803.31hpqdb7y80gwgkc@netchild.homeip.net> X-Priority: 3 (Normal) Date: Thu, 3 Feb 2005 10:58:03 +0100 From: Alexander Leidinger To: Roman Kurakin References: <20050129161022.0de822fe@Magellan.Leidinger.net> <42013BC8.5040204@cronyx.ru> In-Reply-To: <42013BC8.5040204@cronyx.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.0.1) / FreeBSD-4.11 X-ID: VaxJHqZU8eVzz6imhIfcNmR+uqtD6nWnTYVckIO+t5eXbysuwt68U0@t-dialin.net X-TOI-MSGID: 897fc2d2-da0c-4094-9c36-2d77320c0454 cc: current@freebsd.org Subject: Re: We have a lot of duplicated code in the kernel X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2005 09:58:36 -0000 Roman Kurakin wrote: >> I've filtered the list for some false positives (twa_fwimg, trlld?m, >> if_patm_rtables), if someone else notices some more files please tell me >> about them and I add them to the filter. >> > For example if_ct.c and if_cp.c. They have to have the same code since > they written by the same authors, and both devices have almost the same > architecture. If I remove or would use the same prefix for DDK of both > adapters, I am sure, code would have more than 50% of the same code. ;-) And we can't put the common code into another file which either gets included (in case of macros), or linked (in case of functions) to the files in question? Bye, Alexander. -- http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 Your object is to save the world, while still leading a pleasant life. From owner-freebsd-current@FreeBSD.ORG Thu Feb 3 10:12:45 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4BFE416A4CE; Thu, 3 Feb 2005 10:12:45 +0000 (GMT) Received: from itchy.rabson.org (mailgate.nlsystems.com [80.177.232.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2247043D45; Thu, 3 Feb 2005 10:12:44 +0000 (GMT) (envelope-from dfr@nlsystems.com) Received: from ns0.nlsystems.com (ns0.nlsystems.com [80.177.232.243]) by itchy.rabson.org (8.12.11/8.12.11) with ESMTP id j13ACSAJ024275; Thu, 3 Feb 2005 10:12:28 GMT (envelope-from dfr@nlsystems.com) From: Doug Rabson To: freebsd-current@freebsd.org Date: Thu, 3 Feb 2005 10:12:21 +0000 User-Agent: KMail/1.7.1 References: <20050201101113.J572@localhost> <200502011913.j11JDXsf084862@khavrinen.lcs.mit.edu> <20050202094256.K88344@localhost> In-Reply-To: <20050202094256.K88344@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200502031012.22602.dfr@nlsystems.com> X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.64 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on itchy.rabson.org X-Virus-Scanned: clamd / ClamAV version 0.75.1, clamav-milter version 0.75c on itchy.rabson.org X-Virus-Status: Clean cc: current@freebsd.org cc: Peter Jeremy cc: Julian Elischer cc: Garrett Wollman Subject: Re: cynchronised sleep capbilty.. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2005 10:12:45 -0000 On Wednesday 02 February 2005 17:44, Julian Elischer wrote: > very clever! > > however it doesn't phaselock to teh time and still drifts. > I need to trigger on (for example) 10 second boundaries across 50 > synchronised machines.. > (so thatthe machines agree about the sampling period.) How about a cron job which writes characters into a fifo every ten secconds. The script can wait for the next ten second mark by reading a single char from the other end of the fifo. From owner-freebsd-current@FreeBSD.ORG Thu Feb 3 10:12:45 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4BFE416A4CE; Thu, 3 Feb 2005 10:12:45 +0000 (GMT) Received: from itchy.rabson.org (mailgate.nlsystems.com [80.177.232.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2247043D45; Thu, 3 Feb 2005 10:12:44 +0000 (GMT) (envelope-from dfr@nlsystems.com) Received: from ns0.nlsystems.com (ns0.nlsystems.com [80.177.232.243]) by itchy.rabson.org (8.12.11/8.12.11) with ESMTP id j13ACSAJ024275; Thu, 3 Feb 2005 10:12:28 GMT (envelope-from dfr@nlsystems.com) From: Doug Rabson To: freebsd-current@freebsd.org Date: Thu, 3 Feb 2005 10:12:21 +0000 User-Agent: KMail/1.7.1 References: <20050201101113.J572@localhost> <200502011913.j11JDXsf084862@khavrinen.lcs.mit.edu> <20050202094256.K88344@localhost> In-Reply-To: <20050202094256.K88344@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200502031012.22602.dfr@nlsystems.com> X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.64 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on itchy.rabson.org X-Virus-Scanned: clamd / ClamAV version 0.75.1, clamav-milter version 0.75c on itchy.rabson.org X-Virus-Status: Clean cc: current@freebsd.org cc: Peter Jeremy cc: Julian Elischer cc: Garrett Wollman Subject: Re: cynchronised sleep capbilty.. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2005 10:12:45 -0000 On Wednesday 02 February 2005 17:44, Julian Elischer wrote: > very clever! > > however it doesn't phaselock to teh time and still drifts. > I need to trigger on (for example) 10 second boundaries across 50 > synchronised machines.. > (so thatthe machines agree about the sampling period.) How about a cron job which writes characters into a fifo every ten secconds. The script can wait for the next ten second mark by reading a single char from the other end of the fifo. From owner-freebsd-current@FreeBSD.ORG Thu Feb 3 10:17:45 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7047D16A4CE; Thu, 3 Feb 2005 10:17:45 +0000 (GMT) Received: from pimout1-ext.prodigy.net (pimout1-ext.prodigy.net [207.115.63.77]) by mx1.FreeBSD.org (Postfix) with ESMTP id C8B0043D3F; Thu, 3 Feb 2005 10:17:44 +0000 (GMT) (envelope-from julian@elischer.org) Received: from jules (adsl-216-100-134-143.dsl.snfc21.pacbell.net [216.100.134.143])j13AHZGS119594; Thu, 3 Feb 2005 05:17:42 -0500 Date: Thu, 3 Feb 2005 02:17:35 -0800 (PST) From: Julian Elischer X-X-Sender: julian@localhost To: Doug Rabson In-Reply-To: <200502031012.22602.dfr@nlsystems.com> Message-ID: <20050203021603.L583@localhost> References: <20050201101113.J572@localhost> <200502011913.j11JDXsf084862@khavrinen.lcs.mit.edu> <200502031012.22602.dfr@nlsystems.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Peter Jeremy cc: freebsd-current@freebsd.org cc: current@freebsd.org cc: Garrett Wollman Subject: Re: cynchronised sleep capbilty.. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2005 10:17:45 -0000 On Thu, 3 Feb 2005, Doug Rabson wrote: > On Wednesday 02 February 2005 17:44, Julian Elischer wrote: > > very clever! > > > > however it doesn't phaselock to teh time and still drifts. > > I need to trigger on (for example) 10 second boundaries across 50 > > synchronised machines.. > > (so thatthe machines agree about the sampling period.) > > How about a cron job which writes characters into a fifo every ten > secconds. The script can wait for the next ten second mark by reading a > single char from the other end of the fifo. how does a cron job run evey 10 seconds? also this woudl seem something that is a bit beyond a simple shell script in terms of trouble you would go to. > _______________________________________________ > 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" > -- +------------------------------------+ ______ _ __ | __--_|\ Julian Elischer | \ U \/ / hard at work in | / \ julian@elischer.org +------>x USA \ a very strange | ( OZ ) \___ ___ | country ! +- X_.---._/ presently in San Francisco \_/ \\ v From owner-freebsd-current@FreeBSD.ORG Thu Feb 3 10:17:45 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7047D16A4CE; Thu, 3 Feb 2005 10:17:45 +0000 (GMT) Received: from pimout1-ext.prodigy.net (pimout1-ext.prodigy.net [207.115.63.77]) by mx1.FreeBSD.org (Postfix) with ESMTP id C8B0043D3F; Thu, 3 Feb 2005 10:17:44 +0000 (GMT) (envelope-from julian@elischer.org) Received: from jules (adsl-216-100-134-143.dsl.snfc21.pacbell.net [216.100.134.143])j13AHZGS119594; Thu, 3 Feb 2005 05:17:42 -0500 Date: Thu, 3 Feb 2005 02:17:35 -0800 (PST) From: Julian Elischer X-X-Sender: julian@localhost To: Doug Rabson In-Reply-To: <200502031012.22602.dfr@nlsystems.com> Message-ID: <20050203021603.L583@localhost> References: <20050201101113.J572@localhost> <200502011913.j11JDXsf084862@khavrinen.lcs.mit.edu> <200502031012.22602.dfr@nlsystems.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Peter Jeremy cc: freebsd-current@freebsd.org cc: current@freebsd.org cc: Garrett Wollman Subject: Re: cynchronised sleep capbilty.. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2005 10:17:45 -0000 On Thu, 3 Feb 2005, Doug Rabson wrote: > On Wednesday 02 February 2005 17:44, Julian Elischer wrote: > > very clever! > > > > however it doesn't phaselock to teh time and still drifts. > > I need to trigger on (for example) 10 second boundaries across 50 > > synchronised machines.. > > (so thatthe machines agree about the sampling period.) > > How about a cron job which writes characters into a fifo every ten > secconds. The script can wait for the next ten second mark by reading a > single char from the other end of the fifo. how does a cron job run evey 10 seconds? also this woudl seem something that is a bit beyond a simple shell script in terms of trouble you would go to. > _______________________________________________ > 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" > -- +------------------------------------+ ______ _ __ | __--_|\ Julian Elischer | \ U \/ / hard at work in | / \ julian@elischer.org +------>x USA \ a very strange | ( OZ ) \___ ___ | country ! +- X_.---._/ presently in San Francisco \_/ \\ v From owner-freebsd-current@FreeBSD.ORG Thu Feb 3 12:19:22 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6AD0616A4CE; Thu, 3 Feb 2005 12:19:22 +0000 (GMT) Received: from mx3.imp.ch (mx3.imp.ch [157.161.9.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id D830443D4C; Thu, 3 Feb 2005 12:19:20 +0000 (GMT) (envelope-from mb@imp.ch) Received: from mx3.imp.ch (localhost [127.0.0.1]) by mx3.imp.ch (8.12.11/8.12.11/Submit) with ESMTP id j13CJFXr086242; Thu, 3 Feb 2005 13:19:15 +0100 (CET) (envelope-from mb@imp.ch) Received: (from clamav@localhost) by mx3.imp.ch (8.12.11/8.12.11/Submit) id j13CJEOE086204; Thu, 3 Feb 2005 13:19:14 +0100 (CET) (envelope-from mb@imp.ch) Received: from cvs.imp.ch (cvs.imp.ch [157.161.4.9]) id j13CJ8S7093136; Thu, 03 Feb 2005 13:19:10 +0100 (CET) Date: Thu, 3 Feb 2005 13:19:08 +0100 (CET) From: Martin Blapp To: Robert Watson , Chris Lightfoot In-Reply-To: Message-ID: <20050203123816.A55976@cvs.imp.ch> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@freebsd.org Subject: Re: getline() very very slow on localhost on 5.X X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2005 12:19:22 -0000 Hi, I've tested now a lot more and used the old qpopper server to compare the results. You are correct, it doesn't happen here with this application. But I found out something very strange with the tpop3d (the newer popserver which shows the problems) qpopper: -------- Case A (Using IP on the first NIC em0) real 0m1.083s user 0m0.198s sys 0m0.038 Case C (Using 127.0.0.1 on lo0) real 0m0.929s user 0m0.205s sys 0m0.025s Now to tpop3d: -------------- I tested one case more. I see the pop3 server sending a lot slower in case B+C. It doesn't matter if I use an IP alias or the real IP - I can even add some additional IP's which do not have any hostname, the result is the same. It doesn't matter if I access Case A or Case B externally or internally. The order of configured IP's within tpop3d.conf doesn't matter too. Btw, disable or enable PF did not have any effect. > (1) Try connecting to 127.0.0.1 instead of localhost? Case A (Using IP on the first NIC em0) real 0m2.971s user 0m0.248s sys 0m0.064s Case B (Using IP on the second NIC em1) real 0m32.697s user 0m0.247s sys 0m0.024s Case C (Using 127.0.0.1 on lo0) time perl test.pl >xxx real 0m32.164s user 0m0.218s sys 0m0.044s > (2) If the problem persists, try writing a C based client to do the same > thing? We see the same behaviour with normal mail clients. > (3) Use tcpdump on lo0 to create a packet trace? Thats part of the trace on em1 which has the same problems: [...] 12:57:37.443544 IP mx2i.53848 > mx1i.pop3: . ack 106497 win 34048 12:57:37.444256 IP mx1i.pop3 > mx2i.53848: P 106497:114689(8192) ack 0 win 34048 12:57:37.543486 IP mx2i.53848 > mx1i.pop3: . ack 114689 win 34048 12:57:37.545426 IP mx1i.pop3 > mx2i.53848: P 114689:122881(8192) ack 0 win 34048 12:57:37.644410 IP mx2i.53848 > mx1i.pop3: . ack 122881 win 34048 12:57:37.645402 IP mx1i.pop3 > mx2i.53848: P 122881:131073(8192) ack 0 win 34048 12:57:37.743474 IP mx2i.53848 > mx1i.pop3: . ack 131073 win 34048 12:57:37.744181 IP mx1i.pop3 > mx2i.53848: P 131073:139265(8192) ack 0 win 34048 12:57:37.843553 IP mx2i.53848 > mx1i.pop3: . ack 139265 win 34048 12:57:37.844312 IP mx1i.pop3 > mx2i.53848: P 139265:147457(8192) ack 0 win 34048 12:57:37.943493 IP mx2i.53848 > mx1i.pop3: . ack 147457 win 34048 12:57:37.944268 IP mx1i.pop3 > mx2i.53848: P 147457:155649(8192) ack 0 win 34048 12:57:38.043582 IP mx2i.53848 > mx1i.pop3: . ack 155649 win 34048 12:57:38.045378 IP mx1i.pop3 > mx2i.53848: P 155649:163841(8192) ack 0 win 34048 12:57:38.143490 IP mx2i.53848 > mx1i.pop3: . ack 163841 win 34048 12:57:38.145353 IP mx1i.pop3 > mx2i.53848: P 163841:172033(8192) ack 0 win 34048 12:57:38.243562 IP mx2i.53848 > mx1i.pop3: . ack 172033 win 34048 12:57:38.244337 IP mx1i.pop3 > mx2i.53848: P 172033:180225(8192) ack 0 win 34048 12:57:38.343490 IP mx2i.53848 > mx1i.pop3: . ack 180225 win 34048 12:57:38.344244 IP mx1i.pop3 > mx2i.53848: P 180225:188417(8192) ack 0 win 34048 12:57:38.443551 IP mx2i.53848 > mx1i.pop3: . ack 188417 win 34048 12:57:38.444288 IP mx1i.pop3 > mx2i.53848: P 188417:196609(8192) ack 0 win 34048 12:57:38.543633 IP mx2i.53848 > mx1i.pop3: . ack 196609 win 34048 12:57:38.544416 IP mx1i.pop3 > mx2i.53848: P 196609:204801(8192) ack 0 win 34048 12:57:38.643569 IP mx2i.53848 > mx1i.pop3: . ack 204801 win 34048 12:57:38.644348 IP mx1i.pop3 > mx2i.53848: P 204801:212993(8192) ack 0 win 34048 12:57:38.743507 IP mx2i.53848 > mx1i.pop3: . ack 212993 win 34048 12:57:38.744292 IP mx1i.pop3 > mx2i.53848: P 212993:221185(8192) ack 0 win 34048 12:57:38.843849 IP mx2i.53848 > mx1i.pop3: . ack 221185 win 34048 12:57:38.844659 IP mx1i.pop3 > mx2i.53848: P 221185:229377(8192) ack 0 win 34048 12:57:38.943517 IP mx2i.53848 > mx1i.pop3: . ack 229377 win 34048 12:57:38.945711 IP mx1i.pop3 > mx2i.53848: P 229377:237569(8192) ack 0 win 34048 12:57:39.043582 IP mx2i.53848 > mx1i.pop3: . ack 237569 win 34048 12:57:39.044412 IP mx1i.pop3 > mx2i.53848: P 237569:245761(8192) ack 0 win 34048 [..] If needed, I can provide a dump of all connections. Martin From owner-freebsd-current@FreeBSD.ORG Thu Feb 3 11:18:20 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 209D016A4CE; Thu, 3 Feb 2005 11:18:20 +0000 (GMT) Received: from mail.qubesoft.com (gate.qubesoft.com [217.169.36.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4EB8943D2D; Thu, 3 Feb 2005 11:18:19 +0000 (GMT) (envelope-from dfr@qubesoft.com) Received: from [192.168.1.254] (dhcp254.qubesoft.com [192.168.1.254]) by mail.qubesoft.com (8.13.1/8.13.1) with ESMTP id j13BHRvO031666; Thu, 3 Feb 2005 11:18:14 GMT (envelope-from dfr@qubesoft.com) In-Reply-To: <20050203021603.L583@localhost> References: <20050201101113.J572@localhost> <200502011913.j11JDXsf084862@khavrinen.lcs.mit.edu> <20050202094256.K88344@localhost> <200502031012.22602.dfr@nlsystems.com> <20050203021603.L583@localhost> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Doug Rabson Date: Thu, 3 Feb 2005 11:18:13 +0000 To: Julian Elischer X-Mailer: Apple Mail (2.619.2) X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.0.1 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on mail.qubesoft.com X-Mailman-Approved-At: Thu, 03 Feb 2005 12:53:32 +0000 cc: Peter Jeremy cc: freebsd-current@freebsd.org cc: current@freebsd.org cc: Garrett Wollman Subject: Re: cynchronised sleep capbilty.. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2005 11:18:20 -0000 On 3 Feb 2005, at 10:17, Julian Elischer wrote: > On Thu, 3 Feb 2005, Doug Rabson wrote: > >> On Wednesday 02 February 2005 17:44, Julian Elischer wrote: >>> very clever! >>> >>> however it doesn't phaselock to teh time and still drifts. >>> I need to trigger on (for example) 10 second boundaries across 50 >>> synchronised machines.. >>> (so thatthe machines agree about the sampling period.) >> >> How about a cron job which writes characters into a fifo every ten >> secconds. The script can wait for the next ten second mark by reading >> a >> single char from the other end of the fifo. > > how does a cron job run evey 10 seconds? > also this woudl seem something that is a bit beyond > a simple shell script in terms of trouble you would go to. A very good point - I forgot that cron only goes down to minute resolution :-) > From owner-freebsd-current@FreeBSD.ORG Thu Feb 3 11:18:20 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 209D016A4CE; Thu, 3 Feb 2005 11:18:20 +0000 (GMT) Received: from mail.qubesoft.com (gate.qubesoft.com [217.169.36.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4EB8943D2D; Thu, 3 Feb 2005 11:18:19 +0000 (GMT) (envelope-from dfr@qubesoft.com) Received: from [192.168.1.254] (dhcp254.qubesoft.com [192.168.1.254]) by mail.qubesoft.com (8.13.1/8.13.1) with ESMTP id j13BHRvO031666; Thu, 3 Feb 2005 11:18:14 GMT (envelope-from dfr@qubesoft.com) In-Reply-To: <20050203021603.L583@localhost> References: <20050201101113.J572@localhost> <200502011913.j11JDXsf084862@khavrinen.lcs.mit.edu> <20050202094256.K88344@localhost> <200502031012.22602.dfr@nlsystems.com> <20050203021603.L583@localhost> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Doug Rabson Date: Thu, 3 Feb 2005 11:18:13 +0000 To: Julian Elischer X-Mailer: Apple Mail (2.619.2) X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.0.1 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on mail.qubesoft.com X-Mailman-Approved-At: Thu, 03 Feb 2005 12:53:32 +0000 cc: Peter Jeremy cc: freebsd-current@freebsd.org cc: current@freebsd.org cc: Garrett Wollman Subject: Re: cynchronised sleep capbilty.. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2005 11:18:20 -0000 On 3 Feb 2005, at 10:17, Julian Elischer wrote: > On Thu, 3 Feb 2005, Doug Rabson wrote: > >> On Wednesday 02 February 2005 17:44, Julian Elischer wrote: >>> very clever! >>> >>> however it doesn't phaselock to teh time and still drifts. >>> I need to trigger on (for example) 10 second boundaries across 50 >>> synchronised machines.. >>> (so thatthe machines agree about the sampling period.) >> >> How about a cron job which writes characters into a fifo every ten >> secconds. The script can wait for the next ten second mark by reading >> a >> single char from the other end of the fifo. > > how does a cron job run evey 10 seconds? > also this woudl seem something that is a bit beyond > a simple shell script in terms of trouble you would go to. A very good point - I forgot that cron only goes down to minute resolution :-) > From owner-freebsd-current@FreeBSD.ORG Thu Feb 3 13:56:46 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5A23816A4CE for ; Thu, 3 Feb 2005 13:56:46 +0000 (GMT) Received: from out004.verizon.net (out004pub.verizon.net [206.46.170.142]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5591D43D55 for ; Thu, 3 Feb 2005 13:56:45 +0000 (GMT) (envelope-from Alex.Kovalenko@verizon.net) Received: from RabbitsDen ([70.21.161.195]) by out004.verizon.net (InterMail vM.5.01.06.06 201-253-122-130-106-20030910) with ESMTP id <20050203135644.OAFM15146.out004.verizon.net@RabbitsDen>; Thu, 3 Feb 2005 07:56:44 -0600 From: "Alexandre \"Sunny\" Kovalenko" To: Ryan Sommers In-Reply-To: <41FEF40A.70006@gamersimpact.com> References: <63285.65.27.85.163.1107049410.squirrel@65.27.85.163> <41FC561C.3080505@errno.com> <41FEF40A.70006@gamersimpact.com> Content-Type: text/plain; charset=iso-8859-5 Date: Wed, 02 Feb 2005 18:38:45 -0500 Message-Id: <1107387525.979.7.camel@RabbitsDen> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 8bit X-Authentication-Info: Submitted using SMTP AUTH at out004.verizon.net from [70.21.161.195] at Thu, 3 Feb 2005 07:56:43 -0600 cc: current@freebsd.org Subject: Re: WEP Encryption Changes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2005 13:56:46 -0000 On Mon, 2005-01-31 at 21:14 -0600, Ryan Sommers wrote: > I recently (Jan 17) updated my laptop to the latest current. The last > update was in November. After the latest update my WEP wireless stopped > working. After playing with it. It appears something is amiss in the Tx > key for me. I'm able to see broadcast packets coming over the wap just > fine. They don't appear to be corrupt. However, nothing from the laptop > gets to the wap. I'm wondering if Sam's update of sys/net80211 back in > December might be the culprit. > > One thing I did notice was the new deftxkey option in ifconfig. I > attempted to set this to 1 (to use the first and only key), didn't help. > > What all would I need to roll back to reverse these changes? Just > sys/net80211 or would I need to hit sys/dev/wi also? > > Are there any better tools besides another wireless card (only have one > unfortunately) to debug the frames? tcpdump seems to only get me so far. > > For the record this is a Lucent embedded WaveLAN (Dell Trumobile 1150) > firmware 8.10.1. > I remember having to add 'weptxkey 1' to the ifconfig line when these changes went in. As far as tools -- I was using /usr/src/tools/tools/ath/80211debug but, since I had Atheros card then, I could not vouch for its applicability in your case. -- Alexandre "Sunny" Kovalenko (¾ÛÕÚáÐÝÔà ºÞÒÐÛÕÝÚÞ) From owner-freebsd-current@FreeBSD.ORG Thu Feb 3 14:25:47 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1276016A4CE for ; Thu, 3 Feb 2005 14:25:47 +0000 (GMT) Received: from dagobah.rfc1149.org (dagobah.rfc1149.org [217.160.170.141]) by mx1.FreeBSD.org (Postfix) with ESMTP id F12E643D5D for ; Thu, 3 Feb 2005 14:25:45 +0000 (GMT) (envelope-from arne@rfc2549.org) Received: from dsl-213-023-197-254.arcor-ip.net ([213.23.197.254] helo=kamino.rfc1149.org) by dagobah.rfc1149.org with esmtps (TLSv1:AES256-SHA:256) (Exim 4.43 (FreeBSD)) id 1Cwhv9-0008mi-VT; Thu, 03 Feb 2005 15:25:30 +0100 Received: by kamino.rfc1149.org (Postfix, from userid 1001) id E36594089; Thu, 3 Feb 2005 15:25:21 +0100 (CET) To: Tai-hwa Liang In-Reply-To: <05020311245211.96098@www.mmlab.cse.yzu.edu.tw> (Tai-hwa Liang's message of "Thu, 3 Feb 2005 11:27:54 +0800 (CST)") References: <05020311245211.96098@www.mmlab.cse.yzu.edu.tw> From: Arne Schwabe Date: Thu, 03 Feb 2005 15:25:21 +0100 Message-ID: <86u0otlnzi.fsf@kamino.rfc1149.org> User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-RFC-Spam-Score: -0.5 (/) cc: Sam Leffler cc: Bryan Bunch cc: freebsd-current@freebsd.org Subject: Re: WPA with ath X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2005 14:25:47 -0000 Tai-hwa Liang writes: > I guess that's why your station being deauthenticated right after > seeing "Group rekeying completed with..." since WPA requires station > sending group EAPOL key in encrypted form once the pairwise key is > available and installed. > > In my testing environment, -CURRENT if_ath + wpa_supplicant 0.3.0 > always being kicked out by Buffalo AirStation G54 AP(firmware 2.20) > after station completed the group key handshake; however, the same > station/software configuration works flawlessly(read: only one 4-way > handshake + 2 way group key exchange) with another Orinoco AP(which > allows station to reply the last EAPOL successful message in plaintext). > > The attached patch works on my box. Would you please give it a try? With this patch WPA works for me. (did not work before) Arne -- compiling millions of tiny c-programs...done checking for a working configure script... not found From owner-freebsd-current@FreeBSD.ORG Thu Feb 3 14:36:02 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6BB1C16A4CE for ; Thu, 3 Feb 2005 14:36:02 +0000 (GMT) Received: from smtp.des.no (flood.des.no [217.116.83.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9244143D45 for ; Thu, 3 Feb 2005 14:36:01 +0000 (GMT) (envelope-from des@des.no) Received: by smtp.des.no (Pony Express, from userid 666) id 6DF21530D; Thu, 3 Feb 2005 15:35:59 +0100 (CET) Received: from dwp.des.no (des.no [80.203.228.37]) by smtp.des.no (Pony Express) with ESMTP id 098DB5308; Thu, 3 Feb 2005 15:35:25 +0100 (CET) Received: by dwp.des.no (Postfix, from userid 2602) id 9A561B869; Thu, 3 Feb 2005 15:35:25 +0100 (CET) To: Samuel Clements References: <8d.1f937784.2f2eb08c@aol.com> <20050131153756.GA64943@troutmask.apl.washington.edu> <20050131201356.GK73953@hex.databits.net> <41FEAEE2.8080609@linkline.com> <20050131224849.GO73953@hex.databits.net> From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) Date: Thu, 03 Feb 2005 15:35:25 +0100 In-Reply-To: <20050131224849.GO73953@hex.databits.net> (Will Andrews's message of "Mon, 31 Jan 2005 16:48:49 -0600") Message-ID: User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on flood.des.no X-Spam-Level: X-Spam-Status: No, score=0.1 required=5.0 tests=AWL,FORGED_RCVD_HELO autolearn=disabled version=3.0.1 cc: freebsd-current@freebsd.org Subject: Re: Silicon Image SiI 3112 Serial ATA controller support? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2005 14:36:02 -0000 Will Andrews writes: > OK, I'm just looking at AMD boards. ICH5 obviously doesn't go on > any of those. ISTR that AMD's own south bridges have ICH-compatible ATA controllers. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Thu Feb 3 16:57:05 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C4E0616A4CE; Thu, 3 Feb 2005 16:57:05 +0000 (GMT) Received: from ylpvm29.prodigy.net (ylpvm29-ext.prodigy.net [207.115.57.60]) by mx1.FreeBSD.org (Postfix) with ESMTP id A8DFF43D45; Thu, 3 Feb 2005 16:57:04 +0000 (GMT) (envelope-from mbsd@pacbell.net) Received: from sotec.home (adsl-64-168-27-117.dsl.snfc21.pacbell.net [64.168.27.117])j13Gumh3026015; Thu, 3 Feb 2005 11:56:49 -0500 Date: Thu, 3 Feb 2005 08:57:00 -0800 (PST) From: =?ISO-8859-1?Q?Mikko_Ty=F6l=E4j=E4rvi?= X-X-Sender: mikko@sotec.home To: Martin Blapp In-Reply-To: <20050203123816.A55976@cvs.imp.ch> Message-ID: <20050203085004.G21031@sotec.home> References: <20050203123816.A55976@cvs.imp.ch> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: freebsd-current@freebsd.org cc: Robert Watson cc: Chris Lightfoot Subject: Re: getline() very very slow on localhost on 5.X X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2005 16:57:05 -0000 Hi Martin, Judging by the tcpdump, I'd say tpop3d needs to setockopt(TCP_NODELAY). On Thu, 3 Feb 2005, Martin Blapp wrote: [...] > 12:57:37.443544 IP mx2i.53848 > mx1i.pop3: . ack 106497 win 34048 > 12:57:37.444256 IP mx1i.pop3 > mx2i.53848: P 106497:114689(8192) ack 0 win 34048 Pop server sends data. > 12:57:37.543486 IP mx2i.53848 > mx1i.pop3: . ack 114689 win 34048 100ms later - delayed ack from client. > 12:57:37.545426 IP mx1i.pop3 > mx2i.53848: P 114689:122881(8192) ack 0 win 34048 Pop server imediately sends some more data. > 12:57:37.644410 IP mx2i.53848 > mx1i.pop3: . ack 122881 win 34048 Another 100ms laterm another lone delayed ack from client. > 12:57:37.645402 IP mx1i.pop3 > mx2i.53848: P 122881:131073(8192) ack 0 win 34048 Etc... > 12:57:37.743474 IP mx2i.53848 > mx1i.pop3: . ack 131073 win 34048 > 12:57:37.744181 IP mx1i.pop3 > mx2i.53848: P 131073:139265(8192) ack 0 win 34048 > 12:57:37.843553 IP mx2i.53848 > mx1i.pop3: . ack 139265 win 34048 > 12:57:37.844312 IP mx1i.pop3 > mx2i.53848: P 139265:147457(8192) ack 0 win 34048 [...] Presumably FreeBSD doesn't do delayed acks and/or the Nagle algorithm on the loopback interface. $.02, /Mikko From owner-freebsd-current@FreeBSD.ORG Thu Feb 3 18:07:58 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A54D616A4CE; Thu, 3 Feb 2005 18:07:58 +0000 (GMT) Received: from obsecurity.dyndns.org (CPE0050040655c8-CM00111ae02aac.cpe.net.cable.rogers.com [69.199.47.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id CAD1B43D46; Thu, 3 Feb 2005 18:07:57 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 01C4452546; Thu, 3 Feb 2005 10:07:56 -0800 (PST) Date: Thu, 3 Feb 2005 10:07:56 -0800 From: Kris Kennaway To: Mohan Srinivasan Message-ID: <20050203180756.GA2103@xor.obsecurity.org> References: <20041225070022.GA93123@xor.obsecurity.org> <20041225173524.33634.qmail@web80606.mail.yahoo.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="y0ulUmNC+osPPQO6" Content-Disposition: inline In-Reply-To: <20041225173524.33634.qmail@web80606.mail.yahoo.com> User-Agent: Mutt/1.4.2.1i cc: ps@FreeBSD.org cc: current@FreeBSD.org cc: mohans cc: Kris Kennaway Subject: Re: Processes stuck in nfsreq X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2005 18:07:58 -0000 --y0ulUmNC+osPPQO6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Dec 25, 2004 at 09:35:24AM -0800, Mohan Srinivasan wrote: > Hi, >=20 > If the box is still in that state, can you force a core ? >=20 > The trace below shows the process blocked on nfs_request()->msleep. > If the process shows up as waiting on "nfsreq", it would be msleep'ing > from nfs_reply(), not from nfs_request(). There's only one msleep() > call in nfs_request() (nfs_socket.c:1125), but that is for "nqnfstry". > The msleep("nfsreq") only happens from nfs_reply() (unless nfs_reply()=20 > has gotten inlined). OK, I now have working online kgdb. Here's the trace from one stuck cvs process: #0 sched_switch (td=3D0xc3add2e0, newtd=3D0xc81c2a10, flags=3D1) at /usr/s= rc/sys/kern/sched_4bsd.c:964 #1 0xc0517246 in mi_switch (flags=3D1, newtd=3D0x0) at /usr/src/sys/kern/k= ern_synch.c:356 #2 0xc0534624 in sleepq_switch (wchan=3D0x0) at /usr/src/sys/kern/subr_sle= epqueue.c:431 #3 0xc05348f2 in sleepq_wait_sig (wchan=3D0x0) at /usr/src/sys/kern/subr_s= leepqueue.c:556 #4 0xc0516db6 in msleep (ident=3D0xc57ff500, mtx=3D0xc07a1040, priority=3D= 339, wmesg=3D0xc0700e35 "nfsreq", timo=3D0) at /usr/src/sys/kern/kern_synch.c:225 #5 0xc05f186a in nfs_reply (rep=3D0xc57ff500) at /usr/src/sys/nfsclient/nf= s_socket.c:600 #6 0xc05f2583 in nfs_request (vp=3D0xc8b3eac8, mrest=3D0xc3917200, procnum= =3D4, td=3D0xc3add2e0, cred=3D0xc512c380, mrp=3D0xee1a397c, mdp=3D0xee1a3980, dposp=3D0xee1a39= 84) at /usr/src/sys/nfsclient/nfs_socket.c:1043 #7 0xc05f7681 in nfs3_access_otw (vp=3D0xc8b3eac8, wmode=3D-300271216, td= =3D0xc3add2e0, cred=3D0xc512c380) at /usr/src/sys/nfsclient/nfs_vnops.c:264 #8 0xc05f7f34 in nfs_getattr (ap=3D0xee1a3a88) at /usr/src/sys/nfsclient/n= fs_vnops.c:592 #9 0xc06ce1a0 in VOP_GETATTR_AP (a=3D0x0) at vnode_if.c:484 #10 0xc05f89dc in nfs_lookup (ap=3D0x0) at vnode_if.h:275 #11 0xc06cdca0 in VOP_LOOKUP_AP (a=3D0x0) at vnode_if.c:89 #12 0xc0570489 in lookup (ndp=3D0xee1a3c28) at vnode_if.h:54 #13 0xc056fdb8 in namei (ndp=3D0xee1a3c28) at /usr/src/sys/kern/vfs_lookup.= c:189 #14 0xc057e102 in stat (td=3D0xc3add2e0, uap=3D0xee1a3d14) at /usr/src/sys/= kern/vfs_syscalls.c:2088 #15 0xc06b32d0 in syscall (frame=3D {tf_fs =3D 47, tf_es =3D 674955311, tf_ds =3D -1078001617, tf_edi =3D= 3, tf_esi =3D 3, tf_ebp =3D -1077943176, tf_isp =3D -300270220, tf_ebx =3D= 674917772, tf_edx =3D 135074816, tf_ecx =3D 2, tf_eax =3D 188, tf_trapno = =3D 12, tf_err =3D 2, tf_eip =3D 674368127, tf_cs =3D 31, tf_eflags =3D 514= , tf_esp =3D -1077943860, tf_ss =3D 47}) at /usr/src/sys/i386/i386/trap.c:951 #16 0xc069dfcf in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s= :200 #17 0x0000002f in ?? () (kgdb) frame 6 #6 0xc05f2583 in nfs_request (vp=3D0xc8b3eac8, mrest=3D0xc3917200, procnum= =3D4, td=3D0xc3add2e0, cred=3D0xc512c380, mrp=3D0xee1a397c, mdp=3D0xee1a3980, dposp=3D0xee1a39= 84) at /usr/src/sys/nfsclient/nfs_socket.c:1043 1043 error =3D nfs_reply(rep); (kgdb) print rep $3 =3D (struct nfsreq *) 0xc57ff500 (kgdb) print *rep $4 =3D {r_chain =3D {tqe_next =3D 0xc7b23200, tqe_prev =3D 0xc07a0ff0}, r_m= req =3D 0xc37d8700, r_mrep =3D 0x0, r_md =3D 0x0, r_dpos =3D 0xdeadc0de "", r_nmp =3D 0xc39d0000, r_vp =3D 0x= c8b3eac8, r_xid =3D 2829996295, r_flags =3D 1, r_retry =3D 10, r_rexmit =3D 0, r_timer =3D -559038242, r_= procnum =3D 4, r_rtt =3D -1, r_lastmsg =3D 4245, r_td =3D 0xc3add2e0} (kgdb) The deadc0de is interesting. Let me know if there's more debugging info I can get for you. Kris --y0ulUmNC+osPPQO6 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCAmh8Wry0BWjoQKURAqcTAKDK9bL7eJ9jSpBw3nJaCch2U3YGbgCdHDda E2sJMBNGanAlPJfxoa5XJGQ= =NAbl -----END PGP SIGNATURE----- --y0ulUmNC+osPPQO6-- From owner-freebsd-current@FreeBSD.ORG Thu Feb 3 18:29:17 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 78F5A16A4CE for ; Thu, 3 Feb 2005 18:29:17 +0000 (GMT) Received: from web80603.mail.yahoo.com (web80603.mail.yahoo.com [66.218.79.92]) by mx1.FreeBSD.org (Postfix) with SMTP id 37FD443D48 for ; Thu, 3 Feb 2005 18:29:17 +0000 (GMT) (envelope-from mohan_srinivasan@yahoo.com) Message-ID: <20050203182917.40592.qmail@web80603.mail.yahoo.com> Received: from [64.172.45.63] by web80603.mail.yahoo.com via HTTP; Thu, 03 Feb 2005 10:29:16 PST Date: Thu, 3 Feb 2005 10:29:16 -0800 (PST) From: Mohan Srinivasan To: Kris Kennaway In-Reply-To: <20050203180756.GA2103@xor.obsecurity.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii cc: ps@FreeBSD.org cc: current@FreeBSD.org cc: mohans cc: Kris Kennaway Subject: Re: Processes stuck in nfsreq X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2005 18:29:17 -0000 Hi, In the info you have below, the NFS request was not sent (R_SENT is not set). We didn't send out the request because possibly nm_cwnd didn't allow us to send the request. If nfs_request() could not send the request, then typically, the request would be retransmitted from nfs_timer(). If nm_cwnd is full, then there must be a lot of outstanding requests that haven't been replied to yet (on this mount), which is the fundamental issue. Can you force a core dump and send me a pointer to it ? Also, after you force a core, can you also try a quick workaround - someone else also reported NFS client hangs and said that things were fine after they set mpsafenet to 0. It would be good to see if there's a correlation there. mohan --- Kris Kennaway wrote: > On Sat, Dec 25, 2004 at 09:35:24AM -0800, Mohan Srinivasan wrote: > > Hi, > > > > If the box is still in that state, can you force a core ? > > > > The trace below shows the process blocked on nfs_request()->msleep. > > If the process shows up as waiting on "nfsreq", it would be msleep'ing > > from nfs_reply(), not from nfs_request(). There's only one msleep() > > call in nfs_request() (nfs_socket.c:1125), but that is for "nqnfstry". > > The msleep("nfsreq") only happens from nfs_reply() (unless nfs_reply() > > has gotten inlined). > > OK, I now have working online kgdb. Here's the trace from one stuck > cvs process: > > #0 sched_switch (td=0xc3add2e0, newtd=0xc81c2a10, flags=1) at > /usr/src/sys/kern/sched_4bsd.c:964 > #1 0xc0517246 in mi_switch (flags=1, newtd=0x0) at /usr/src/sys/kern/kern_synch.c:356 > #2 0xc0534624 in sleepq_switch (wchan=0x0) at /usr/src/sys/kern/subr_sleepqueue.c:431 > #3 0xc05348f2 in sleepq_wait_sig (wchan=0x0) at /usr/src/sys/kern/subr_sleepqueue.c:556 > #4 0xc0516db6 in msleep (ident=0xc57ff500, mtx=0xc07a1040, priority=339, wmesg=0xc0700e35 > "nfsreq", > timo=0) at /usr/src/sys/kern/kern_synch.c:225 > #5 0xc05f186a in nfs_reply (rep=0xc57ff500) at /usr/src/sys/nfsclient/nfs_socket.c:600 > #6 0xc05f2583 in nfs_request (vp=0xc8b3eac8, mrest=0xc3917200, procnum=4, td=0xc3add2e0, > cred=0xc512c380, mrp=0xee1a397c, mdp=0xee1a3980, dposp=0xee1a3984) > at /usr/src/sys/nfsclient/nfs_socket.c:1043 > #7 0xc05f7681 in nfs3_access_otw (vp=0xc8b3eac8, wmode=-300271216, td=0xc3add2e0, > cred=0xc512c380) > at /usr/src/sys/nfsclient/nfs_vnops.c:264 > #8 0xc05f7f34 in nfs_getattr (ap=0xee1a3a88) at /usr/src/sys/nfsclient/nfs_vnops.c:592 > #9 0xc06ce1a0 in VOP_GETATTR_AP (a=0x0) at vnode_if.c:484 > #10 0xc05f89dc in nfs_lookup (ap=0x0) at vnode_if.h:275 > #11 0xc06cdca0 in VOP_LOOKUP_AP (a=0x0) at vnode_if.c:89 > #12 0xc0570489 in lookup (ndp=0xee1a3c28) at vnode_if.h:54 > #13 0xc056fdb8 in namei (ndp=0xee1a3c28) at /usr/src/sys/kern/vfs_lookup.c:189 > #14 0xc057e102 in stat (td=0xc3add2e0, uap=0xee1a3d14) at /usr/src/sys/kern/vfs_syscalls.c:2088 > #15 0xc06b32d0 in syscall (frame= > {tf_fs = 47, tf_es = 674955311, tf_ds = -1078001617, tf_edi = 3, tf_esi = 3, tf_ebp = > -1077943176, tf_isp = -300270220, tf_ebx = 674917772, tf_edx = 135074816, tf_ecx = 2, tf_eax = > 188, tf_trapno = 12, tf_err = 2, tf_eip = 674368127, tf_cs = 31, tf_eflags = 514, tf_esp = > -1077943860, tf_ss = 47}) > at /usr/src/sys/i386/i386/trap.c:951 > #16 0xc069dfcf in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:200 > #17 0x0000002f in ?? () > (kgdb) frame 6 > #6 0xc05f2583 in nfs_request (vp=0xc8b3eac8, mrest=0xc3917200, procnum=4, td=0xc3add2e0, > cred=0xc512c380, mrp=0xee1a397c, mdp=0xee1a3980, dposp=0xee1a3984) > at /usr/src/sys/nfsclient/nfs_socket.c:1043 > 1043 error = nfs_reply(rep); > (kgdb) print rep > $3 = (struct nfsreq *) 0xc57ff500 > (kgdb) print *rep > $4 = {r_chain = {tqe_next = 0xc7b23200, tqe_prev = 0xc07a0ff0}, r_mreq = 0xc37d8700, r_mrep = > 0x0, > r_md = 0x0, r_dpos = 0xdeadc0de "", r_nmp = 0xc39d0000, r_vp = 0xc8b3eac8, r_xid = 2829996295, > r_flags = 1, r_retry = 10, r_rexmit = 0, r_timer = -559038242, r_procnum = 4, r_rtt = -1, > r_lastmsg = 4245, r_td = 0xc3add2e0} > (kgdb) > > The deadc0de is interesting. Let me know if there's more debugging > info I can get for you. > > Kris > > ATTACHMENT part 2 application/pgp-signature From owner-freebsd-current@FreeBSD.ORG Thu Feb 3 19:30:17 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 01F8616A4D5 for ; Thu, 3 Feb 2005 19:30:17 +0000 (GMT) Received: from mail.mcneil.com (mcneil.com [24.199.45.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 77B9C43D2F for ; Thu, 3 Feb 2005 19:30:14 +0000 (GMT) (envelope-from sean@mcneil.com) Received: from localhost (localhost.mcneil.com [127.0.0.1]) by mail.mcneil.com (Postfix) with ESMTP id 39FD2F311B for ; Thu, 3 Feb 2005 11:30:14 -0800 (PST) Received: from mail.mcneil.com ([127.0.0.1]) by localhost (server.mcneil.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 51988-07 for ; Thu, 3 Feb 2005 11:30:07 -0800 (PST) Received: from mcneil.com (mcneil.com [24.199.45.54]) by mail.mcneil.com (Postfix) with ESMTP id A9A4DF3117 for ; Thu, 3 Feb 2005 11:30:07 -0800 (PST) From: Sean McNeil To: current@freebsd.org Content-Type: text/plain Date: Thu, 03 Feb 2005 11:30:07 -0800 Message-Id: <1107459007.73969.11.camel@server.mcneil.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at mcneil.com Subject: fixing libpthread shutdown X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2005 19:30:17 -0000 Isn't anyone interested in fixing this? I've reported it several times with no response. I'd assist in any way I can: My system is an amd64: FreeBSD server.mcneil.com 6.0-CURRENT FreeBSD 6.0-CURRENT #14: Mon Jan 31 17:25:40 PST 2005 root@server.mcneil.com:/usr/obj/usr/src/sys/AMD64 amd64 This happens with 2 daemons that I know about: slapd named It can be easily reproduced: /etc/rc.d/named stop What happens? It never exits. The process pretty much shuts down but it just sits there doing nothing. Let me know if there is anything I can do to help fix this. Cheers, Sean From owner-freebsd-current@FreeBSD.ORG Thu Feb 3 20:46:47 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2747916A4CE for ; Thu, 3 Feb 2005 20:46:47 +0000 (GMT) Received: from spider.deepcore.dk (cpe.atm2-0-53484.0x50a6c9a6.abnxx9.customer.tele.dk [80.166.201.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id 689D643D2F for ; Thu, 3 Feb 2005 20:46:46 +0000 (GMT) (envelope-from sos@DeepCore.dk) Received: from [194.192.25.143] (laptop.deepcore.dk [194.192.25.143]) by spider.deepcore.dk (8.12.11/8.12.10) with ESMTP id j13KkZf2002994; Thu, 3 Feb 2005 21:46:37 +0100 (CET) (envelope-from sos@DeepCore.dk) Message-ID: <42028D9C.90109@DeepCore.dk> Date: Thu, 03 Feb 2005 21:46:20 +0100 From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= User-Agent: Mozilla Thunderbird 1.0 (X11/20050116) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= References: <8d.1f937784.2f2eb08c@aol.com> <20050131153756.GA64943@troutmask.apl.washington.edu> <20050131201356.GK73953@hex.databits.net> <41FEAEE2.8080609@linkline.com> <20050131224849.GO73953@hex.databits.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-mail-scanned: by DeepCore Virus & Spam killer v1.6 cc: freebsd-current@freebsd.org cc: Samuel Clements Subject: Re: Silicon Image SiI 3112 Serial ATA controller support? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2005 20:46:47 -0000 Dag-Erling Sm=F8rgrav wrote: > Will Andrews writes: >=20 >>OK, I'm just looking at AMD boards. ICH5 obviously doesn't go on >>any of those. >=20 >=20 > ISTR that AMD's own south bridges have ICH-compatible ATA controllers. Nope AMD's ATA controllers are VIA clones and in close family with=20 nVidia as well (the diffs are minor between all 3 types). --=20 -S=F8ren From owner-freebsd-current@FreeBSD.ORG Thu Feb 3 20:53:17 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EF41516A4CE; Thu, 3 Feb 2005 20:53:16 +0000 (GMT) Received: from spider.deepcore.dk (cpe.atm2-0-53484.0x50a6c9a6.abnxx9.customer.tele.dk [80.166.201.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2C1EF43D41; Thu, 3 Feb 2005 20:53:16 +0000 (GMT) (envelope-from sos@DeepCore.dk) Received: from [194.192.25.143] (laptop.deepcore.dk [194.192.25.143]) by spider.deepcore.dk (8.12.11/8.12.10) with ESMTP id j13KrBR0003036; Thu, 3 Feb 2005 21:53:13 +0100 (CET) (envelope-from sos@DeepCore.dk) Message-ID: <42028F29.1030801@DeepCore.dk> Date: Thu, 03 Feb 2005 21:52:57 +0100 From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= User-Agent: Mozilla Thunderbird 1.0 (X11/20050116) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'FreeBSD Current'" , "freebsd-stable@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-mail-scanned: by DeepCore Virus & Spam killer v1.6 Subject: ATA mkIII first official patches - please test! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2005 20:53:17 -0000 ATA-mkIII first official snapshot. This is the much rumoured ATA update that I've been working on for some t= ime. It contains a number of new things, and lacks a few features of the old c= ode. New items include: o ATA is now fully newbus'd and split into modules. This means that on a modern system you just load "atapci and ata= " to get the base support, and then one or more of the device subdrivers "atadisk atapicd atapifd atapist ataraid". All can be loaded/unloaded anytime, but for obvious reasons you dont want to unload atadisk when you have mounted filesystems. o The device identify part of the probe has been rewritten to fix the problems with odd devices the old had, and to try to remove so of the long delays some HW could provoke. o SATA devices can be hot inserted/removed and devices will be crea= ted/ removed in /dev accordingly. NOTE only supported on controllers = that has this feature: Promise and Silicon Image for now. o ATA RAID support has been rewritten and and now supports these metadata formats: "Adaptec HostRAID" "Highpoint V2 RocketRAID" "Highpoint V3 RocketRAID" "Intel MatrixRAID" "Integrated Technology Express" "LSILogic V2 MegaRAID" "LSILogic V3 MegaRAID" "Promise FastTrak" "Silicon Image Medley" o The reinit code has been worked over to be much more robust. o The timeout code has been overhauled for races. o Lots of fixes for bugs found while doing the modulerization and reviewing the old code. Missing features form current ATA: o atapi-cd no longer has support for ATAPI changers. Todays its much cheaper and alot faster to copy those CD images to disk and serve them from there. Besides they dont seem to be made anymore, maybe for that exact reason. o ATA RAID can only read metadata not write them. This means that arrays can be picked up from the BIOS, but they cannot be create= d from FreeBSD. This is being worked on for the final release as i= s RAID5 support for Promise/Highpoing/SiI controllers. o The atapi-cam author has been informed and has had early access to this work but so far atapicam is not supported with these changes. However I do have my own atacam that puts both ATA and = ATAPI devices under CAM, but its really just academic at this point. And then there all the things that I've happily forgotten about :) The snapshot is available as a patch for RELENG_5 and for CURRENT, and a common tarfile of the new ATA code. http://people.freebsd.org/~sos/ata-mk3j.diff-releng5.gz http://people.freebsd.org/~sos/ata-mk3j.diff-current.gz http://people.freebsd.org/~sos/ata-mk3j.tar.gz Both patches and the tarfile is relative to /usr/src. You might want to remove the contents of sys/dev/ata/ before unpacking the tarfile. No changes are needed to your config file, unless you want ATA as modules= =2E As usual, even if it works on all the HW I have here in the lab, thats by= far not the same as it works on YOUR system. So use glowes and safety sho= es and if it breaks I dont want the pieces, but would like to hear the nifty= details on how exactly it got that way :) Enjoy! --=20 -S=F8ren From owner-freebsd-current@FreeBSD.ORG Thu Feb 3 21:06:37 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7935616A4CE for ; Thu, 3 Feb 2005 21:06:37 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8468B43D2F for ; Thu, 3 Feb 2005 21:06:36 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id 59CEB7A444 for ; Thu, 3 Feb 2005 13:06:36 -0800 (PST) Message-ID: <4202925C.10401@elischer.org> Date: Thu, 03 Feb 2005 13:06:36 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030516 X-Accept-Language: en, hu MIME-Version: 1.0 To: FreeBSD Current Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Freebsd 5.3 & 6.x :Dell Inspiron 7500 vs (XF86-4.4.x & x.org) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2005 21:06:37 -0000 Maybe someone here can answer this question for me? I have no idea what it means. ---begin forwarded snippet ----- [...] >> (==) ATI(0): Write-combining range (0xfd000000,0x800000) >> (==) ATI(0): Write-combining range (0xfc000000,0x1000) was already clear >> (II) ATI(0): MMIO write caching enabled. >> (--) ATI(0): 8192 kB of SGRAM (1:1) detected (using 8191 kB). >> (WW) ATI(0): Cannot shadow an accelerated frame buffer. >> (II) ATI(0): Engine XCLK 124.453 MHz; Refresh rate code 12. >> (--) ATI(0): Internal programmable clock generator detected. >> (--) ATI(0): Reference clock 29.500 MHz. >> (II) ATI(0): Maximum clock: 230.00 MHz > > What's the mode on server entry? The one set up by the Mobility BIOS, or something else? For example, does FreeBSD have something akin to Linux's broken atyfb? ---- end forwarded snippet ----- From owner-freebsd-current@FreeBSD.ORG Thu Feb 3 21:27:11 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E7ED616A4CE for ; Thu, 3 Feb 2005 21:27:11 +0000 (GMT) Received: from mail28.sea5.speakeasy.net (mail28.sea5.speakeasy.net [69.17.117.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9FB2C43D49 for ; Thu, 3 Feb 2005 21:27:11 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 3946 invoked from network); 3 Feb 2005 21:27:11 -0000 Received: from server.baldwin.cx ([216.27.160.63]) (envelope-sender )AES256-SHA encrypted SMTP for ; 3 Feb 2005 21:27:11 -0000 Received: from [10.50.40.202] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id j13LQs9H056817; Thu, 3 Feb 2005 16:26:56 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-current@FreeBSD.org Date: Thu, 3 Feb 2005 12:47:21 -0500 User-Agent: KMail/1.6.2 References: <79659.1106645826@critter.freebsd.dk> In-Reply-To: <79659.1106645826@critter.freebsd.dk> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200502031247.22241.jhb@FreeBSD.org> X-Spam-Status: No, score=-102.8 required=4.2 tests=ALL_TRUSTED, USER_IN_WHITELIST autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx cc: Poul-Henning Kamp cc: Jeremie Le Hen Subject: Re: cvs commit: src/sys/dev/md md.c X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2005 21:27:12 -0000 On Tuesday 25 January 2005 04:37 am, Poul-Henning Kamp wrote: > In message <20050124134546.GB59685@obiwan.tataz.chchile.org>, Jeremie Le Hen writes: > >While talking about WITNESS, I checked my kernel config and remembered > >that FULL_PREEMPTION is on. The panic disappeared when I turned off > >the latter : I managed to create up to about 16 md(4) devices. I know > >this should not be enabled for users, but I'm interested in "exposing > >race conditions" as said in the comment. > > Well, you clearly did :-) > > I suggest you send a summary of what you have found to jhb@freebsd.org, > he's working on the FULL_PREEMPTION stuff. FULL_PREEMPTION just preempts more often is all. It's still probably a locking bug of some sort. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Thu Feb 3 21:27:18 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A324616A509 for ; Thu, 3 Feb 2005 21:27:18 +0000 (GMT) Received: from mail26.sea5.speakeasy.net (mail26.sea5.speakeasy.net [69.17.117.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id CB9EF43D41 for ; Thu, 3 Feb 2005 21:27:17 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 4452 invoked from network); 3 Feb 2005 21:27:17 -0000 Received: from server.baldwin.cx ([216.27.160.63]) (envelope-sender )AES256-SHA encrypted SMTP for ; 3 Feb 2005 21:27:16 -0000 Received: from [10.50.40.202] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id j13LQs9I056817; Thu, 3 Feb 2005 16:27:08 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-current@FreeBSD.org Date: Thu, 3 Feb 2005 13:04:41 -0500 User-Agent: KMail/1.6.2 References: <57062.211.96.21.195.1106558752.squirrel@webmail.catholic.org> In-Reply-To: <57062.211.96.21.195.1106558752.squirrel@webmail.catholic.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200502031304.41476.jhb@FreeBSD.org> X-Spam-Status: No, score=-102.8 required=4.2 tests=ALL_TRUSTED, USER_IN_WHITELIST autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx cc: wsk Subject: Re: Rocketport uPCI ioaddr mapping failed under FreeBSD-5.3&CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2005 21:27:18 -0000 On Monday 24 January 2005 04:25 am, wsk wrote: > hi,folks: > > after installed RocketPort uPCI card into my box;it > dumps the follow eror msgs: > > rp0: port 0xde00-0xdeff,0xdd80-0xddff mem > 0xfcedff80-0xfcedffff > irq 19 at device 10.0 on pci2 > rp0: failed: rid 0x10 is memory, requested 4 > rp0: ioaddr mapping failed for RocketPort(PCI). > device_attach: rp0 attach returned 6 Looks like you need to change the driver to map its io addresses from a different BAR for this chip ID since BAR 0 is memory, not I/O. I'm not sure this driver will work with this card, btw, but you can try changing this line in the attach function of sys/dev/rp/rp_pci.c: ctlp->io_rid[0] = 0x10; to use either '0x14' or '0x18' rather than '0x10' and see if it works. > and pciconfig the rp0: > rp0@pci2:10:0: class=0x078000 card=0x080511fe chip=0x080511fe rev=0x01 > hdr=0x00 > vendor = 'Comtrol Corp' > class = simple comms > > and downloaded the 1800255A file and follwed the README from > www.comtrol.com. During the buildkernel, I got errors: > > cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs > -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline > -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I../../.. > -I../../../contrib/dev/acpica -I../../../contrib/altq > -I../../../contrib/ipfilter -I../../../contrib/pf > -I../../../contrib/dev/ath -I../../../contrib/dev/ath/freebsd > -I../../../contrib/ngatm -D_KERNEL -include opt_global.h -fno-common > -finline-limit=8000 --param inline-unit-growth=100 --param > large-function-growth=1000 -mno-align-long-strings > -mpreferred-stack-boundary=2 -ffreestanding -Werror ../../../dev/rp/rp.c > ../../../dev/rp/rp.c: In function `rp_do_receive': > ../../../dev/rp/rp.c:772: error: request for member `l_rint' in something > not a structure or union > ../../../dev/rp/rp.c:820: error: request for member `l_rint' in something > not a structure or union > ../../../dev/rp/rp.c: In function `rp_handle_port': > ../../../dev/rp/rp.c:850: error: request for member `l_modem' in something > not a structure or union > ../../../dev/rp/rp.c:854: error: request for member `l_modem' in something > not a structure or union > ../../../dev/rp/rp.c:855: error: request for member `l_modem' in something > not a structure or union > ../../../dev/rp/rp.c: In function `rp_do_poll': > ../../../dev/rp/rp.c:903: error: request for member `l_start' in something > not a structure or union > ../../../dev/rp/rp.c: In function `rp_attachcommon': > ../../../dev/rp/rp.c:982: warning: assignment makes integer from pointer > without a cast > ../../../dev/rp/rp.c:985: warning: assignment makes integer from pointer > without a cast > ../../../dev/rp/rp.c:988: warning: assignment makes integer from pointer > without a cast > ../../../dev/rp/rp.c:991: warning: assignment makes integer from pointer > without a cast > ../../../dev/rp/rp.c:994: warning: assignment makes integer from pointer > without a cast > ../../../dev/rp/rp.c:997: warning: assignment makes integer from pointer > without a cast > ../../../dev/rp/rp.c: In function `rp_releaseresource': > ../../../dev/rp/rp.c:1077: warning: passing arg 1 of `destroy_dev' makes > pointer from integer without a cast > ../../../dev/rp/rp.c: In function `rpopen': > ../../../dev/rp/rp.c:1088: error: argument "dev" doesn't match prototype > ../../../dev/rp/rp.c:672: error: prototype declaration > ../../../dev/rp/rp.c:1096: warning: passing arg 1 of `minor' makes pointer > from integer without a cast > ../../../dev/rp/rp.c:1097: warning: passing arg 1 of `minor' makes pointer > from integer without a cast > ../../../dev/rp/rp.c:1102: warning: passing arg 1 of `minor' makes pointer > from integer without a cast > ../../../dev/rp/rp.c:1108: error: invalid type argument of `->' > ../../../dev/rp/rp.c:1120: warning: passing arg 1 of `minor' makes pointer > from integer without a cast > ../../../dev/rp/rp.c:1145: warning: assignment makes pointer from integer > without a cast > ../../../dev/rp/rp.c:1150: warning: passing arg 1 of `minor' makes pointer > from integer without a cast > ../../../dev/rp/rp.c:1200: warning: passing arg 1 of `minor' makes pointer > from integer without a cast > ../../../dev/rp/rp.c:1201: warning: passing arg 1 of `minor' makes pointer > from integer without a cast > ../../../dev/rp/rp.c:1202: error: request for member `l_modem' in > something not a structure or union > ../../../dev/rp/rp.c:1212: warning: passing arg 1 of `minor' makes pointer > from integer without a cast > ../../../dev/rp/rp.c:1221: error: request for member `l_open' in something > not a structure or union > ../../../dev/rp/rp.c:1224: warning: passing arg 1 of `minor' makes pointer > from integer without a cast > ../../../dev/rp/rp.c: In function `rpclose': > ../../../dev/rp/rp.c:1246: error: argument "dev" doesn't match prototype > ../../../dev/rp/rp.c:673: error: prototype declaration > ../../../dev/rp/rp.c:1252: warning: passing arg 1 of `minor' makes pointer > from integer without a cast > ../../../dev/rp/rp.c:1253: warning: passing arg 1 of `minor' makes pointer > from integer without a cast > ../../../dev/rp/rp.c:1257: warning: passing arg 1 of `minor' makes pointer > from integer without a cast > ../../../dev/rp/rp.c:1264: error: request for member `l_close' in > something not a structure or union > ../../../dev/rp/rp.c:1271: warning: implicit declaration of function > `ttyclose' > ../../../dev/rp/rp.c:1271: warning: nested extern declaration of `ttyclose' > ../../../dev/rp/rp.c: In function `rpread': > ../../../dev/rp/rp.c:1321: error: argument "dev" doesn't match prototype > ../../../dev/rp/rp.c:676: error: prototype declaration > ../../../dev/rp/rp.c:1326: warning: passing arg 1 of `minor' makes pointer > from integer without a cast > ../../../dev/rp/rp.c:1327: warning: passing arg 1 of `minor' makes pointer > from integer without a cast > ../../../dev/rp/rp.c:1331: warning: passing arg 1 of `minor' makes pointer > from integer without a cast > ../../../dev/rp/rp.c:1335: error: request for member `l_read' in something > not a structure or union > ../../../dev/rp/rp.c: In function `rpwrite': > ../../../dev/rp/rp.c:1345: error: argument "dev" doesn't match prototype > ../../../dev/rp/rp.c:674: error: prototype declaration > ../../../dev/rp/rp.c:1351: warning: passing arg 1 of `minor' makes pointer > from integer without a cast > ../../../dev/rp/rp.c:1352: warning: passing arg 1 of `minor' makes pointer > from integer without a cast > ../../../dev/rp/rp.c:1356: warning: passing arg 1 of `minor' makes pointer > from integer without a cast > ../../../dev/rp/rp.c:1367: error: request for member `l_write' in > something not a structure or union > ../../../dev/rp/rp.c: In function `rpioctl': > ../../../dev/rp/rp.c:1388: error: argument "dev" doesn't match prototype > ../../../dev/rp/rp.c:675: error: prototype declaration > ../../../dev/rp/rp.c:1403: warning: passing arg 1 of `minor' makes pointer > from integer without a cast > ../../../dev/rp/rp.c:1404: warning: passing arg 1 of `minor' makes pointer > from integer without a cast > ../../../dev/rp/rp.c:1410: warning: passing arg 1 of `minor' makes pointer > from integer without a cast > ../../../dev/rp/rp.c:1413: warning: passing arg 1 of `minor' makes pointer > from integer without a cast > ../../../dev/rp/rp.c:1415: warning: passing arg 1 of `minor' makes pointer > from integer without a cast > ../../../dev/rp/rp.c:1418: warning: passing arg 1 of `minor' makes pointer > from integer without a cast > ../../../dev/rp/rp.c:1460: warning: passing arg 1 of `minor' makes pointer > from integer without a cast > ../../../dev/rp/rp.c:1482: error: request for member `l_ioctl' in > something not a structure or union > ../../../dev/rp/rp.c: In function `rp_disc_optim': > ../../../dev/rp/rp.c:1763: error: request for member `l_rint' in something > not a structure or union > ../../../dev/rp/rp.c: At top level: > ../../../dev/rp/rp.c:2364: error: syntax error before "rp_pci_mod" > ../../../dev/rp/rp.c:2364: warning: type defaults to `int' in declaration > of `rp_pci_mod' > ../../../dev/rp/rp.c:2364: warning: initialization makes integer from > pointer without a cast > ../../../dev/rp/rp.c:2364: warning: excess elements in scalar initializer > ../../../dev/rp/rp.c:2364: warning: (near initialization for `rp_pci_mod') > ../../../dev/rp/rp.c:2364: warning: excess elements in scalar initializer > ../../../dev/rp/rp.c:2364: warning: (near initialization for `rp_pci_mod') > ../../../dev/rp/rp.c:2364: warning: data definition has no type or storage > class../../../dev/rp/rp.c:2364: warning: type defaults to `int' in > declaration of `DECLARE_MODULE' > ../../../dev/rp/rp.c:2364: warning: parameter names (without types) in > function declaration > ../../../dev/rp/rp.c:2364: warning: data definition has no type or storage > class../../../dev/rp/rp.c:2809: error: syntax error before "rp_isa_mod" > ../../../dev/rp/rp.c:2809: warning: type defaults to `int' in declaration > of `rp_isa_mod' > ../../../dev/rp/rp.c:2809: warning: initialization makes integer from > pointer without a cast > ../../../dev/rp/rp.c:2809: warning: excess elements in scalar initializer > ../../../dev/rp/rp.c:2809: warning: (near initialization for `rp_isa_mod') > ../../../dev/rp/rp.c:2809: warning: excess elements in scalar initializer > ../../../dev/rp/rp.c:2809: warning: (near initialization for `rp_isa_mod') > ../../../dev/rp/rp.c:2809: warning: data definition has no type or storage > class../../../dev/rp/rp.c:2809: warning: type defaults to `int' in > declaration of `DECLARE_MODULE' > ../../../dev/rp/rp.c:2809: warning: parameter names (without types) in > function declaration > ../../../dev/rp/rp.c:2809: warning: redundant redeclaration of > 'DECLARE_MODULE' > ../../../dev/rp/rp.c:2364: warning: previous declaration of > 'DECLARE_MODULE' was here > ../../../dev/rp/rp.c:2809: warning: data definition has no type or storage > class*** Error code 1 > > Stop in /usr/src/sys/i386/compile/WSK. > > thinks in any Re with appresiates! > > > > > ----------------------------------------- > This email was sent using FREE Catholic Online Webmail! > http://webmail.catholic.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" -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Thu Feb 3 21:27:21 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E986B16A4F3 for ; Thu, 3 Feb 2005 21:27:21 +0000 (GMT) Received: from mail23.sea5.speakeasy.net (mail23.sea5.speakeasy.net [69.17.117.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8521B43D2D for ; Thu, 3 Feb 2005 21:27:21 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 19773 invoked from network); 3 Feb 2005 21:27:21 -0000 Received: from server.baldwin.cx ([216.27.160.63]) (envelope-sender )AES256-SHA encrypted SMTP for ; 3 Feb 2005 21:27:20 -0000 Received: from [10.50.40.202] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id j13LQs9J056817; Thu, 3 Feb 2005 16:27:16 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-current@FreeBSD.org Date: Thu, 3 Feb 2005 13:30:57 -0500 User-Agent: KMail/1.6.2 References: In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200502031330.57265.jhb@FreeBSD.org> X-Spam-Status: No, score=-102.8 required=4.2 tests=ALL_TRUSTED, USER_IN_WHITELIST autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx cc: Ian FREISLICH cc: current@FreeBSD.org Subject: Re: sys/1386/i386/mptable.c rev 1.239 breaks boot. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2005 21:27:22 -0000 On Monday 31 January 2005 07:01 am, Ian FREISLICH wrote: > Hi > > I have a dual pII machine that doesn't boot with 1.239 of > sys/1386/i386/mptable.c. It boots with this patch backed out. > Does anyone have any ideas beyond backing out this patch? > > revision 1.239 > date: 2005/01/18 20:27:24; author: jhb; state: Exp; lines: +7 -1 > If a valid ELCR was found, consult it for the trigger mode of ISA > interrupts that have a trigger mode of conforming. This fixes problems on > some older machines that still route PCI devices via ISA interrupts when > using an I/O APIC. > > This seems to be a case of breaking, rather than fixing older > machines. It's highly reproduceable. I mailed the author of this > commit over a week ago, but have not had a response yet :(. This > is definitely a show-stopper, for me at least. It did fix other boxes. :( Can you provide a verbose dmesg? -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Thu Feb 3 21:27:22 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EEDBE16A4F4 for ; Thu, 3 Feb 2005 21:27:21 +0000 (GMT) Received: from mail23.sea5.speakeasy.net (mail23.sea5.speakeasy.net [69.17.117.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8585A43D3F for ; Thu, 3 Feb 2005 21:27:21 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 19773 invoked from network); 3 Feb 2005 21:27:21 -0000 Received: from server.baldwin.cx ([216.27.160.63]) (envelope-sender )AES256-SHA encrypted SMTP for ; 3 Feb 2005 21:27:20 -0000 Received: from [10.50.40.202] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id j13LQs9J056817; Thu, 3 Feb 2005 16:27:16 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-current@FreeBSD.org Date: Thu, 3 Feb 2005 13:30:57 -0500 User-Agent: KMail/1.6.2 References: In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200502031330.57265.jhb@FreeBSD.org> X-Spam-Status: No, score=-102.8 required=4.2 tests=ALL_TRUSTED, USER_IN_WHITELIST autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx cc: Ian FREISLICH cc: current@FreeBSD.org Subject: Re: sys/1386/i386/mptable.c rev 1.239 breaks boot. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2005 21:27:22 -0000 On Monday 31 January 2005 07:01 am, Ian FREISLICH wrote: > Hi > > I have a dual pII machine that doesn't boot with 1.239 of > sys/1386/i386/mptable.c. It boots with this patch backed out. > Does anyone have any ideas beyond backing out this patch? > > revision 1.239 > date: 2005/01/18 20:27:24; author: jhb; state: Exp; lines: +7 -1 > If a valid ELCR was found, consult it for the trigger mode of ISA > interrupts that have a trigger mode of conforming. This fixes problems on > some older machines that still route PCI devices via ISA interrupts when > using an I/O APIC. > > This seems to be a case of breaking, rather than fixing older > machines. It's highly reproduceable. I mailed the author of this > commit over a week ago, but have not had a response yet :(. This > is definitely a show-stopper, for me at least. It did fix other boxes. :( Can you provide a verbose dmesg? -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Thu Feb 3 21:49:36 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3D15416A4CE; Thu, 3 Feb 2005 21:49:36 +0000 (GMT) Received: from mx3.imp.ch (mx3.imp.ch [157.161.9.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id DF95B43D31; Thu, 3 Feb 2005 21:49:34 +0000 (GMT) (envelope-from mb@imp.ch) Received: from mx3.imp.ch (localhost [127.0.0.1]) by mx3.imp.ch (8.12.11/8.12.11/Submit) with ESMTP id j13LnTQT048062; Thu, 3 Feb 2005 22:49:29 +0100 (CET) (envelope-from mb@imp.ch) Received: (from clamav@localhost) by mx3.imp.ch (8.12.11/8.12.11/Submit) id j13LnRiW048045; Thu, 3 Feb 2005 22:49:27 +0100 (CET) (envelope-from mb@imp.ch) Received: from cvs.imp.ch (cvs.imp.ch [157.161.4.9]) id j13LnOS7045062; Thu, 03 Feb 2005 22:49:27 +0100 (CET) Date: Thu, 3 Feb 2005 22:49:24 +0100 (CET) From: Martin Blapp To: Chris Lightfoot In-Reply-To: Message-ID: <20050203224809.K55976@cvs.imp.ch> References: <20050203123816.A55976@cvs.imp.ch> <20050203085004.G21031@sotec.home> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@freebsd.org cc: Robert Watson Subject: Re: getline() very very slow on localhost on 5.X X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2005 21:49:36 -0000 Hi, > > Judging by the tcpdump, I'd say tpop3d needs to setockopt(TCP_NODELAY). Yes, this solved the problem. Thanks everbody for the pointers :-) > > yep -- you could try that. In the CVS version the output > is better buffered, so this problem shouldn't arise. I'm currently testing the CVS version and we will use this one for going production. Martin From owner-freebsd-current@FreeBSD.ORG Thu Feb 3 23:07:32 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3284216A4CE for ; Thu, 3 Feb 2005 23:07:32 +0000 (GMT) Received: from av3-2-sn3.vrr.skanova.net (av3-2-sn3.vrr.skanova.net [81.228.9.110]) by mx1.FreeBSD.org (Postfix) with ESMTP id BB46443D55 for ; Thu, 3 Feb 2005 23:07:31 +0000 (GMT) (envelope-from daniel_k_eriksson@telia.com) Received: by av3-2-sn3.vrr.skanova.net (Postfix, from userid 502) id 9174837E62; Fri, 4 Feb 2005 00:07:30 +0100 (CET) Received: from smtp1-1-sn3.vrr.skanova.net (smtp1-1-sn3.vrr.skanova.net [81.228.9.177]) by av3-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 80B2937E57; Fri, 4 Feb 2005 00:07:30 +0100 (CET) Received: from sentinel (h205n1fls11o822.telia.com [213.64.66.205]) by smtp1-1-sn3.vrr.skanova.net (Postfix) with ESMTP id 59D1538011; Fri, 4 Feb 2005 00:07:30 +0100 (CET) From: "Daniel Eriksson" To: "'Mohan Srinivasan'" , "'Kris Kennaway'" Date: Fri, 4 Feb 2005 00:07:23 +0100 Organization: Home Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <20050203182917.40592.qmail@web80603.mail.yahoo.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Thread-Index: AcUKLyRg2HbgDit7RMSyBQm/lkcvLQAFG5Eg cc: current@freebsd.org Subject: RE: Processes stuck in nfsreq X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2005 23:07:32 -0000 Mohan Srinivasan wrote: > Also, after you force a core, can you also try a quick > workaround - someone > else also reported NFS client hangs and said that things were fine > after they set mpsafenet to 0. It would be good to see if there's a > correlation there. That would be me. Unfortunately I've been busy with other things so I haven't had time to switch back to mpsafenet=1 and get you a dump. Since switching to mpsafenet=0 I haven't had a single NFS lock-up, so there seems to be a correlation. I have observed another strange thing lately. It seems like I keep getting file corruption when transferring large files (10-75MB each) over NFS with net.isr.enable=1. This is on an SMP client and a UP server, both running very recent 6-CURRENT kernels hooked up using a crossover cable (if_em on client, if_vr on server). The failure rate seems to be around 1 in 150 files or something like that, and the error shows up as a file that is a few hundred bytes shorter than the original (always resulting in a filesize on an 8kB boundary). I only switched off net.isr yesterday, so I still don't know for sure if it has cured the problem, but I've moved well over 1000 files since then without any corruption issues. Again, the amount of details I can provide is very limited. Sorry about that! /Daniel Eriksson From owner-freebsd-current@FreeBSD.ORG Thu Feb 3 23:17:04 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 19C0A16A4CE for ; Thu, 3 Feb 2005 23:17:04 +0000 (GMT) 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 0483143D39 for ; Thu, 3 Feb 2005 23:17:00 +0000 (GMT) (envelope-from chris@unixpages.org) Received: from r220-1 (r220-1.rz.RWTH-Aachen.DE [134.130.3.31]) by ms-dienst.rz.rwth-aachen.de (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTP id <0IBC00DXKZCAUS@ms-dienst.rz.rwth-aachen.de> for freebsd-current@freebsd.org; Fri, 04 Feb 2005 00:16:58 +0100 (MET) Received: from relay.rwth-aachen.de ([134.130.3.1]) by r220-1 (MailMonitor for SMTP v1.2.2 ) ; Fri, 04 Feb 2005 00:16:57 +0100 (MET) Received: from haakonia.hitnet.rwth-aachen.de (haakonia.hitnet.RWTH-Aachen.DE [137.226.181.92])j13NGvL6014748; Fri, 04 Feb 2005 00:16:57 +0100 (MET) Received: from gondor.middleearth (gondor.middleearth [192.168.1.42]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))(Postfix) with ESMTP id 1718A28450; Fri, 04 Feb 2005 00:16:52 +0100 (CET) Received: by gondor.middleearth (Postfix, from userid 1001) id 6533A2285B; Fri, 04 Feb 2005 00:16:51 +0100 (CET) Date: Fri, 04 Feb 2005 00:16:51 +0100 From: Christian Brueffer In-reply-to: <42028F29.1030801@DeepCore.dk> To: =?iso-8859-1?Q?S=F8ren?= Schmidt Message-id: <20050203231650.GB59930@unixpages.org> MIME-version: 1.0 Content-type: multipart/signed; boundary=FkmkrVfFsRoUs1wW; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-disposition: inline User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 6.0-CURRENT X-PGP-Key: http://people.FreeBSD.org/~brueffer/brueffer.key.asc X-PGP-Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D References: <42028F29.1030801@DeepCore.dk> cc: 'FreeBSD Current' Subject: Re: ATA mkIII first official patches - please test! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2005 23:17:04 -0000 --FkmkrVfFsRoUs1wW Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Feb 03, 2005 at 09:52:57PM +0100, S=F8ren Schmidt wrote: >=20 > As usual, even if it works on all the HW I have here in the lab, thats by > far not the same as it works on YOUR system. So use glowes and safety sho= es > and if it breaks I dont want the pieces, but would like to hear the nifty > details on how exactly it got that way :) >=20 It works great on my Thinkpad, finally no device timeouts and delays on bootup anymore (and no need to remove lines from ata-queue.c to prevent a panic on CURRENT). Nice work :-) - 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 --FkmkrVfFsRoUs1wW Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCArDibHYXjKDtmC0RAoymAKCy1BGlf2z6cInowJzPaEJi0npKzQCgllrA lhS1EvFdRR3FBzw9It02W8w= =dKn9 -----END PGP SIGNATURE----- --FkmkrVfFsRoUs1wW-- From owner-freebsd-current@FreeBSD.ORG Fri Feb 4 00:11:07 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4571A16A4CF; Fri, 4 Feb 2005 00:11:07 +0000 (GMT) Received: from obsecurity.dyndns.org (CPE0050040655c8-CM00111ae02aac.cpe.net.cable.rogers.com [69.199.47.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 06CCF43D46; Fri, 4 Feb 2005 00:11:07 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id AECF85146E; Thu, 3 Feb 2005 16:11:05 -0800 (PST) Date: Thu, 3 Feb 2005 16:11:05 -0800 From: Kris Kennaway To: Mohan Srinivasan Message-ID: <20050204001105.GA3760@xor.obsecurity.org> References: <20050203180756.GA2103@xor.obsecurity.org> <20050203182917.40592.qmail@web80603.mail.yahoo.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Dxnq1zWXvFF0Q93v" Content-Disposition: inline In-Reply-To: <20050203182917.40592.qmail@web80603.mail.yahoo.com> User-Agent: Mutt/1.4.2.1i cc: ps@FreeBSD.org cc: current@FreeBSD.org cc: mohans cc: Kris Kennaway Subject: Re: Processes stuck in nfsreq X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2005 00:11:07 -0000 --Dxnq1zWXvFF0Q93v Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Feb 03, 2005 at 10:29:16AM -0800, Mohan Srinivasan wrote: > Hi, >=20 > In the info you have below, the NFS request was not sent (R_SENT > is not set). We didn't send out the request because possibly nm_cwnd=20 > didn't allow us to send the request. If nfs_request() could not send=20 > the request, then typically, the request would be retransmitted from=20 > nfs_timer().=20 >=20 > If nm_cwnd is full, then there must be a lot of outstanding requests=20 > that haven't been replied to yet (on this mount), which is the fundamental > issue. FYI, this is truly hung and not just backlogged - it hasn't proceeded any further since last night. > Can you force a core dump and send me a pointer to it ? Unfortunately not, because twed dumping is still broken. The only way I was able to obtain this information is because kan has patches that fix kgdb enough to use it on the running kernel. > Also, after you force a core, can you also try a quick workaround - someo= ne > else also reported NFS client hangs and said that things were fine > after they set mpsafenet to 0. It would be good to see if there's a > correlation there. I can try that. Kris --Dxnq1zWXvFF0Q93v Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCAr2ZWry0BWjoQKURAqV3AJ4wOuupBoGVf75mVJeSMDHb1tqHCACg7Tlq xxU355GFq1yiU7zH/SI3HZM= =Yazc -----END PGP SIGNATURE----- --Dxnq1zWXvFF0Q93v-- From owner-freebsd-current@FreeBSD.ORG Fri Feb 4 00:58:47 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C05E216A4CE; Fri, 4 Feb 2005 00:58:47 +0000 (GMT) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9B19543D39; Fri, 4 Feb 2005 00:58:47 +0000 (GMT) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) j140wgkc059647; Thu, 3 Feb 2005 16:58:42 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost)j140wgOt059646; Thu, 3 Feb 2005 16:58:42 -0800 (PST) (envelope-from sgk) Date: Thu, 3 Feb 2005 16:58:42 -0800 From: Steve Kargl To: S?ren Schmidt Message-ID: <20050204005841.GA59607@troutmask.apl.washington.edu> References: <42028F29.1030801@DeepCore.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42028F29.1030801@DeepCore.dk> User-Agent: Mutt/1.4.2.1i cc: 'FreeBSD Current' cc: "freebsd-stable@freebsd.org" Subject: Re: ATA mkIII first official patches - please test! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2005 00:58:47 -0000 On Thu, Feb 03, 2005 at 09:52:57PM +0100, S?ren Schmidt wrote: > > As usual, even if it works on all the HW I have here in the lab, thats by > far not the same as it works on YOUR system. So use glowes and safety shoes > and if it breaks I dont want the pieces, but would like to hear the nifty > details on how exactly it got that way :) > THANK YOU! This is the first time since 7 Dec 04 that I've been able to boot a current -CURRENT on my Dell Inspiron 4150 laptop. -- Steve From owner-freebsd-current@FreeBSD.ORG Fri Feb 4 01:07:16 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from green.homeunix.org (freefall.freebsd.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 4394116A4CE; Fri, 4 Feb 2005 01:07:16 +0000 (GMT) Received: from green.homeunix.org (green@localhost [127.0.0.1]) by green.homeunix.org (8.13.1/8.13.1) with ESMTP id j1417FVb032494; Thu, 3 Feb 2005 20:07:15 -0500 (EST) (envelope-from green@green.homeunix.org) Received: (from green@localhost) by green.homeunix.org (8.13.1/8.13.1/Submit) id j1417BFi032493; Thu, 3 Feb 2005 20:07:11 -0500 (EST) (envelope-from green) Date: Thu, 3 Feb 2005 20:07:10 -0500 From: Brian Fundakowski Feldman To: Sean McNeil Message-ID: <20050204010710.GG91982@green.homeunix.org> References: <1107459007.73969.11.camel@server.mcneil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1107459007.73969.11.camel@server.mcneil.com> User-Agent: Mutt/1.5.6i cc: current@freebsd.org Subject: Re: fixing libpthread shutdown X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2005 01:07:16 -0000 On Thu, Feb 03, 2005 at 11:30:07AM -0800, Sean McNeil wrote: > Isn't anyone interested in fixing this? I've reported it several times > with no response. I'd assist in any way I can: > > My system is an amd64: > > FreeBSD server.mcneil.com 6.0-CURRENT FreeBSD 6.0-CURRENT #14: Mon Jan 31 17:25:40 PST 2005 root@server.mcneil.com:/usr/obj/usr/src/sys/AMD64 amd64 > > This happens with 2 daemons that I know about: > > slapd > named > > It can be easily reproduced: > > /etc/rc.d/named stop > > What happens? It never exits. The process pretty much shuts down but > it just sits there doing nothing. > > Let me know if there is anything I can do to help fix this. SIGINFO thread dumps and gdb backtraces would be a good way to start searching out the cause of the hangs. What have you tried? -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\ From owner-freebsd-current@FreeBSD.ORG Fri Feb 4 02:38:11 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4D24716A4CE for ; Fri, 4 Feb 2005 02:38:11 +0000 (GMT) Received: from obsecurity.dyndns.org (CPE0050040655c8-CM00111ae02aac.cpe.net.cable.rogers.com [69.199.47.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 19C0143D49 for ; Fri, 4 Feb 2005 02:38:11 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 296CC512AF; Thu, 3 Feb 2005 18:38:10 -0800 (PST) Date: Thu, 3 Feb 2005 18:38:10 -0800 From: Kris Kennaway To: Jeff Roberson , current@freeBSD.org Message-ID: <20050204023809.GA39071@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="x+6KMIRAuhnl3hBn" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: panic: splay lookup failed in remove X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2005 02:38:11 -0000 --x+6KMIRAuhnl3hBn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I ran 4 fsx instances in parallel on a dual-cpu machine with mpsafevfs=1 and up-to-date sources, and it panicked after a few seconds with: panic: splay lookup failed in remove cpuid = 1 KDB: enter: panic [thread pid 3 tid 100121 ] Stopped at kdb_enter+0x30: leave db> tr Tracing pid 3 tid 100121 td 0xc570c170 kdb_enter(c06fb771,1,c0704ec6,eec1eac4,c570c170) at kdb_enter+0x30 panic(c0704ec6,0,22,de81406c,c5a5a9f4) at panic+0x13e buf_vlist_remove(de71cab4,0,c0704cf2,572,de71cab4) at buf_vlist_remove+0x94 brelvp(de71cab4,0,4e6,c0703728,de71cab4) at brelvp+0xbe brelse(de71cab4,c0703392,c72,c0703c55,de71cab4) at brelse+0x1ed bufdone(de71cab4,0,c0703392,3c6) at bufdone+0x59c vfs_backgroundwritedone(de71cab4,0,c0703392,c84,de71cab4) at vfs_backgroundwritedone+0x13f bufdone(de71cab4,bdb,0,cc12b18c,cc12b18c) at bufdone+0x1c7 g_vfs_done(cc12b18c,0,c0703392,bdb) at g_vfs_done+0xa2 biodone(cc12b18c,c06f63e0,1e8,c06f67c1,cc12b18c) at biodone+0x72 g_io_schedule_up(c570c170,0,c06f68ac,5d,0) at g_io_schedule_up+0x1a2 g_up_procbody(0,eec1ed48,c06f8a14,30e,c570c170) at g_up_procbody+0x93 fork_exit(c04edba8,0,eec1ed48) at fork_exit+0x11b fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xeec1ed7c, ebp = 0 --- Kris --x+6KMIRAuhnl3hBn Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCAuARWry0BWjoQKURAspTAJ9uA0wwA0jedJ3aKNVSF2B5pyIw8wCggO0f nLdoFELRjCPslb6yAeIR+rU= =StQb -----END PGP SIGNATURE----- --x+6KMIRAuhnl3hBn-- From owner-freebsd-current@FreeBSD.ORG Fri Feb 4 02:41:19 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5E8E016A4CE for ; Fri, 4 Feb 2005 02:41:19 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id D22F643D1D for ; Fri, 4 Feb 2005 02:41:18 +0000 (GMT) (envelope-from caelian@gmail.com) Received: by rproxy.gmail.com with SMTP id z35so347771rne for ; Thu, 03 Feb 2005 18:41:18 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=mYtR3KAf3tIO4OxG24T6C0QEKL2eCyjLPCcXQgiF9W2YjMsv1ABKuu7O5FTzaMhdG4R+w2E0kEgS0Q1fTaAcVddnlBNfaPXCVhnMwVcAwhlKQBhMMRVQESeyH/h62I2qDh2Q+xtv/PxH+ZIOJaivL0fJ3yUgXjoIpP/OEkw7WTA= Received: by 10.38.11.60 with SMTP id 60mr73045rnk; Thu, 03 Feb 2005 18:40:43 -0800 (PST) Received: by 10.38.89.69 with HTTP; Thu, 3 Feb 2005 18:40:43 -0800 (PST) Message-ID: Date: Thu, 3 Feb 2005 18:40:43 -0800 From: Pascal Hofstee To: =?ISO-8859-1?Q?S=F8ren_Schmidt?= In-Reply-To: <42028F29.1030801@DeepCore.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable References: <42028F29.1030801@DeepCore.dk> cc: FreeBSD Current cc: "freebsd-stable@freebsd.org" Subject: Re: ATA mkIII first official patches - please test! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Pascal Hofstee List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2005 02:41:19 -0000 On Thu, 03 Feb 2005 21:52:57 +0100, S=F8ren Schmidt wrote= : > ATA-mkIII first official snapshot. Using it without any problems on a few days old 6.0-CURRENT (P2 400 MHz) I decided to take the plunge and go for the kernel-module-approach. The only thing i was curious about is if there is any way to build the kernel-module using ATA_STATIC_ID .. (as i used to do in my normal kernel-configs) Beyond that, it works like a charm :) --=20 Pascal Hofstee From owner-freebsd-current@FreeBSD.ORG Fri Feb 4 02:59:53 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9FC8D16A4CE for ; Fri, 4 Feb 2005 02:59:53 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.200]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1468F43D1F for ; Fri, 4 Feb 2005 02:59:53 +0000 (GMT) (envelope-from caelian@gmail.com) Received: by rproxy.gmail.com with SMTP id z35so349395rne for ; Thu, 03 Feb 2005 18:59:49 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=mYjLobzkxglyZQmFTJkWAEH1MekfRQ7WWGg+376XQEPUAqglHxlhSBctoE+sNR9h1F354T4jc+AHCuSYP4hKpmEV+rP6IzNsGPwN7NB7B7jH+msp27yjSfL9wc1jTYG1F/zhtK24YqkZ7n8baAjsSuAVZZ7y2sp+VS6KoZgWUPs= Received: by 10.38.208.40 with SMTP id f40mr198806rng; Thu, 03 Feb 2005 18:58:20 -0800 (PST) Received: by 10.38.89.69 with HTTP; Thu, 3 Feb 2005 18:58:20 -0800 (PST) Message-ID: Date: Thu, 3 Feb 2005 18:58:20 -0800 From: Pascal Hofstee To: =?ISO-8859-1?Q?S=F8ren_Schmidt?= In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <42028F29.1030801@DeepCore.dk> cc: FreeBSD Current cc: "freebsd-stable@freebsd.org" Subject: Re: ATA mkIII first official patches - please test! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Pascal Hofstee List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2005 02:59:53 -0000 On Thu, 3 Feb 2005 18:40:43 -0800, Pascal Hofstee wrote: > The only thing i was curious about is if there is any way to build the > kernel-module using ATA_STATIC_ID .. (as i used to do in my normal > kernel-configs) Ok .. I whacked myself with the proverbial clue-stick .. and simply put the ATA_STATIC_ID line back into my kernel-config. Even though i chose not to build ata-support not into the actual kernel the opt_ata.h file is of course still used in building the actual kernel-modules. Excuse the line noise :) -- Pascal Hofstee From owner-freebsd-current@FreeBSD.ORG Fri Feb 4 04:22:10 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 50AE216A4CE for ; Fri, 4 Feb 2005 04:22:10 +0000 (GMT) Received: from goethe4.elib.com (goethe4.elib.com [209.176.65.241]) by mx1.FreeBSD.org (Postfix) with SMTP id 8835243D54 for ; Fri, 4 Feb 2005 04:22:09 +0000 (GMT) (envelope-from jds@elib.com) Received: (qmail 47885 invoked from network); 4 Feb 2005 04:21:52 -0000 Received: from unknown (HELO ?10.0.1.20?) (209.176.65.4) by goethe4.elib.com with SMTP; 4 Feb 2005 04:21:52 -0000 Received: from 127.0.0.1 (AVG SMTP 7.0.300 [265.8.4]); Thu, 03 Feb 2005 23:21:52 -0500 Message-ID: <002001c50a71$0d7857e0$1401000a@c4.com> From: "James D. Stewart" To: =?iso-8859-1?Q?S=F8ren_Schmidt?= References: <42028F29.1030801@DeepCore.dk> Date: Thu, 3 Feb 2005 23:21:52 -0500 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=iso-8859-1 cc: freebsd-current@freebsd.org Subject: Re: ATA mkIII first official patches - please test! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2005 04:22:10 -0000 ----- Original Message ----- Sent: Thursday, February 03, 2005 3:52 PM Subject: ATA mkIII first official patches - please test! > ATA-mkIII first official snapshot. With RELENG_5, the following errors occur (if you need more info, ask off-list): $ make kernel KERNCONF=NFS2 . . (lots deleted( . cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extens ions -std=c99 -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/contrib/dev/ acpica -I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/ipfilter -I/usr/sr c/sys/contrib/pf -I/usr/src/sys/contrib/dev/ath -I/usr/src/sys/contrib/dev/a th/freebsd -I/usr/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param arge-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundar y=2 -ffreestanding -Werror /usr/src/sys/dev/ata/ata-card.c /usr/src/sys/dev/ata/ata-card.c:56: error: `PCMCIA_PRODUCT_IODATA3_CBIDE2' undeclared here (not in a function) /usr/src/sys/dev/ata/ata-card.c:56: error: initializer element is not constant /usr/src/sys/dev/ata/ata-card.c:56: error: (near initialization for `ata_pccard_products[2].pp_product') /usr/src/sys/dev/ata/ata-card.c:56: error: `PCMCIA_CIS_IODATA3_CBIDE2' undeclared here (not in a function) /usr/src/sys/dev/ata/ata-card.c:56: error: initializer element is not constant /usr/src/sys/dev/ata/ata-card.c:56: error: (near initialization for `ata_pccard_products[2].pp_cis') /usr/src/sys/dev/ata/ata-card.c:56: error: initializer element is not constant /usr/src/sys/dev/ata/ata-card.c:56: error: (near initialization for `ata_pccard_products[2]') /usr/src/sys/dev/ata/ata-card.c:57: error: initializer element is not constant /usr/src/sys/dev/ata/ata-card.c:57: error: (near initialization for `ata_pccard_products[3].pp_cis') /usr/src/sys/dev/ata/ata-card.c:57: error: initializer element is not constant /usr/src/sys/dev/ata/ata-card.c:57: error: (near initialization for `ata_pccard_products[3]') /usr/src/sys/dev/ata/ata-card.c:58: error: initializer element is not constant /usr/src/sys/dev/ata/ata-card.c:58: error: (near initialization for `ata_pccard_products[4].pp_cis') /usr/src/sys/dev/ata/ata-card.c:58: error: initializer element is not constant /usr/src/sys/dev/ata/ata-card.c:58: error: (near initialization for `ata_pccard_products[4]') /usr/src/sys/dev/ata/ata-card.c:59: error: initializer element is not constant /usr/src/sys/dev/ata/ata-card.c:59: error: (near initialization for `ata_pccard_products[5].pp_cis') /usr/src/sys/dev/ata/ata-card.c:59: error: initializer element is not constant /usr/src/sys/dev/ata/ata-card.c:59: error: (near initialization for `ata_pccard_products[5]') /usr/src/sys/dev/ata/ata-card.c:60: error: initializer element is not constant /usr/src/sys/dev/ata/ata-card.c:60: error: (near initialization for `ata_pccard_products[6].pp_cis') /usr/src/sys/dev/ata/ata-card.c:60: error: initializer element is not constant /usr/src/sys/dev/ata/ata-card.c:60: error: (near initialization for `ata_pccard_products[6]') /usr/src/sys/dev/ata/ata-card.c:61: error: initializer element is not constant /usr/src/sys/dev/ata/ata-card.c:61: error: (near initialization for `ata_pccard_products[7]') *** Error code 1 Stop in /usr/obj/usr/src/sys/NFS2. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. The sys/dev/ata directory contents was removed prior to the tar file being dumped, then the patch was applied, all from the /usr/src directory. -- Jim Stewart e.Librarian The e.Lib, Inc. -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.300 / Virus Database: 265.8.4 - Release Date: 2/1/05 From owner-freebsd-current@FreeBSD.ORG Fri Feb 4 04:57:04 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A8B7F16A4CF for ; Fri, 4 Feb 2005 04:57:04 +0000 (GMT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 573E343D45 for ; Fri, 4 Feb 2005 04:57:04 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id 46FA572DD4; Thu, 3 Feb 2005 20:57:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id 424CF72DCB; Thu, 3 Feb 2005 20:57:04 -0800 (PST) Date: Thu, 3 Feb 2005 20:57:04 -0800 (PST) From: Doug White To: Emil Mikulic In-Reply-To: <20050203094355.GA4767@dmr.ath.cx> Message-ID: <20050203205144.C47315@carver.gumbysoft.com> References: <20050203094355.GA4767@dmr.ath.cx> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@freebsd.org Subject: Re: Can't see OpenBSD's slices X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2005 04:57:04 -0000 On Thu, 3 Feb 2005, Emil Mikulic wrote: > ad1 is a hard-drive taken from an OpenBSD machine that had / and swap > and /tmp and /var and /usr on it (at least). The machine it's now in is > running FreeBSD 6-CURRENT and it only sees one slice: > > $ ls /dev/ad1* > /dev/ad1 /dev/ad1s4 > > I can mount this without any issues and it turns out to be the old root > filesystem. Is there any way to get at the other filesystems on that > disk? I assume the OpenBSD machine was i386 and not sparc. Well you rattled off 5 partitions so its not MBR-based. We probably doesn't understand OpenBSD disklabels. If we don't understand the disklabel then we can't find the filesystems. Do you have a partition map from OpenBSD to compare with? -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Fri Feb 4 05:21:00 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4CAE516A4CE for ; Fri, 4 Feb 2005 05:21:00 +0000 (GMT) Received: from node15.coopprint.com (node15.cooperativeprinting.com [208.4.77.15]) by mx1.FreeBSD.org (Postfix) with SMTP id 9D33043D39 for ; Fri, 4 Feb 2005 05:20:59 +0000 (GMT) (envelope-from ryans@gamersimpact.com) Received: (qmail 50973 invoked by uid 0); 4 Feb 2005 05:20:55 -0000 Received: from unknown (HELO ?192.168.0.5?) (63.231.157.250) by node15.coopprint.com with SMTP; 4 Feb 2005 05:20:55 -0000 Message-ID: <42030649.7020806@gamersimpact.com> Date: Thu, 03 Feb 2005 23:21:13 -0600 From: Ryan Sommers User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: current@freebsd.org Content-Type: multipart/mixed; boundary="------------020408000003040401010505" Subject: [PATCH] /etc/defaults/rc.conf -- Static Routing Explanation X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2005 05:21:00 -0000 This is a multi-part message in MIME format. --------------020408000003040401010505 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit The following patch makes it a little more clear how to use the static routing tunable in rc.conf. If I don't hear from anyone, I'll submit a pr for it. -- Ryan Sommers ryans@gamersimpact.com --------------020408000003040401010505 Content-Type: text/plain; name="defaults.rc.conf.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="defaults.rc.conf.diff" --- /etc/defaults/rc.conf Fri Oct 8 09:25:02 2004 +++ rc.conf Wed Feb 2 17:33:55 2005 @@ -241,7 +241,9 @@ ### Network routing options: ### defaultrouter="NO" # Set to default gateway (or NO). -static_routes="" # Set to static route list (or leave empty). +static_routes="" # Set to static route list seperated by spaces (or leave empty). (See following example.) +#static_routes="subnet1" +#route_subnet1="192.168.0.128/25 192.168.0.100" natm_static_routes="" # Set to static route list for NATM (or leave empty). gateway_enable="NO" # Set to YES if this host will be a gateway. router_enable="NO" # Set to YES to enable a routing daemon. --------------020408000003040401010505-- From owner-freebsd-current@FreeBSD.ORG Fri Feb 4 06:07:31 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6F46416A4CE; Fri, 4 Feb 2005 06:07:31 +0000 (GMT) Received: from ylpvm15.prodigy.net (ylpvm15-ext.prodigy.net [207.115.57.46]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0E83343D46; Fri, 4 Feb 2005 06:07:31 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.5.51] (adsl-64-171-186-233.dsl.snfc21.pacbell.net [64.171.186.233])j1463Cbs010934; Fri, 4 Feb 2005 01:03:13 -0500 Message-ID: <420310FA.1060307@root.org> Date: Thu, 03 Feb 2005 22:06:50 -0800 From: Nate Lawson User-Agent: Mozilla Thunderbird 1.0RC1 (X11/20041205) X-Accept-Language: en-us, en MIME-Version: 1.0 To: current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: acpi@freebsd.org Subject: cpufreq committed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2005 06:07:31 -0000 Please cvsup and test. All you need is a rebuilt kernel and the device or module for cpufreq and/or acpi_perf. Then sysctl dev.cpu to see your options. Man pages, updates for relative drivers, etc. should be coming shortly. Thanks for any feedback, -- Nate From owner-freebsd-current@FreeBSD.ORG Fri Feb 4 06:37:13 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C16AB16A4CE for ; Fri, 4 Feb 2005 06:37:13 +0000 (GMT) Received: from av1-1-sn3.vrr.skanova.net (av1-1-sn3.vrr.skanova.net [81.228.9.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4A76F43D31 for ; Fri, 4 Feb 2005 06:37:13 +0000 (GMT) (envelope-from daniel_k_eriksson@telia.com) Received: by av1-1-sn3.vrr.skanova.net (Postfix, from userid 502) id 1B44837E48; Fri, 4 Feb 2005 07:37:12 +0100 (CET) Received: from smtp1-1-sn3.vrr.skanova.net (smtp1-1-sn3.vrr.skanova.net [81.228.9.177]) by av1-1-sn3.vrr.skanova.net (Postfix) with ESMTP id 0994537E45; Fri, 4 Feb 2005 07:37:12 +0100 (CET) Received: from sentinel (h205n1fls11o822.telia.com [213.64.66.205]) by smtp1-1-sn3.vrr.skanova.net (Postfix) with ESMTP id D98783800D; Fri, 4 Feb 2005 07:37:11 +0100 (CET) From: "Daniel Eriksson" To: "'Mohan Srinivasan'" , "'Kris Kennaway'" Date: Fri, 4 Feb 2005 07:37:05 +0100 Organization: Home Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcUKLyRg2HbgDit7RMSyBQm/lkcvLQAFG5EgAA/5FyA= In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 cc: current@freebsd.org Subject: RE: Processes stuck in nfsreq X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2005 06:37:13 -0000 I wrote: > I only switched off net.isr yesterday, so I still don't > know for sure if it has cured the problem, but I've moved > well over 1000 files since then without any corruption > issues. During the night a number of files being moved from the client to the server have ended up corrupted (shorter than original, with a size evenly dividable by 8192), so turning net.isr off wasn't the solution. /Daniel Eriksson From owner-freebsd-current@FreeBSD.ORG Fri Feb 4 06:58:51 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 18D0416A4CE for ; Fri, 4 Feb 2005 06:58:51 +0000 (GMT) Received: from publicd.ub.mng.net (publicd.ub.mng.net [202.179.0.88]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3A7CE43D55 for ; Fri, 4 Feb 2005 06:58:49 +0000 (GMT) (envelope-from ganbold@micom.mng.net) Received: from [202.179.0.164] (helo=ganbold.micom.mng.net) by publicd.ub.mng.net with esmtpa (Exim 4.43 (FreeBSD)) id 1CwxWV-0007gl-IS for freebsd-current@freebsd.org; Fri, 04 Feb 2005 15:04:59 +0800 Message-Id: <6.2.0.14.2.20050204145224.03142560@202.179.0.80> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Fri, 04 Feb 2005 14:56:33 +0800 To: freebsd-current@freebsd.org From: Ganbold Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: OT: FreeBSD mail server is listed at dnsbl.sorbs.net X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2005 06:58:51 -0000 Hi list, I could not get emails from freebsd mailing list for last 1-2 days. Following message is from our mail server log: 2005-02-04 13:00:43 H=(mx2.freebsd.org) [216.136.204.119] F= rejected RCPT : rejected because 216.136.204.119 is in a black list at dnsbl.sorbs.net It seems like freebsd mail server is listed at dnsbl.sorbs.net. When will freebsd mail server removed from the list? thanks, Ganbold From owner-freebsd-current@FreeBSD.ORG Fri Feb 4 07:13:36 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9BF1A16A4CE for ; Fri, 4 Feb 2005 07:13:36 +0000 (GMT) Received: from obsecurity.dyndns.org (CPE0050040655c8-CM00111ae02aac.cpe.net.cable.rogers.com [69.199.47.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 68BBD43D2D for ; Fri, 4 Feb 2005 07:13:36 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 74EF5512F2; Thu, 3 Feb 2005 23:13:33 -0800 (PST) Date: Thu, 3 Feb 2005 23:13:33 -0800 From: Kris Kennaway To: Ganbold Message-ID: <20050204071333.GA17819@xor.obsecurity.org> References: <6.2.0.14.2.20050204145224.03142560@202.179.0.80> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="oyUTqETQ0mS9luUI" Content-Disposition: inline In-Reply-To: <6.2.0.14.2.20050204145224.03142560@202.179.0.80> User-Agent: Mutt/1.4.2.1i cc: freebsd-current@freebsd.org Subject: Re: OT: FreeBSD mail server is listed at dnsbl.sorbs.net X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2005 07:13:36 -0000 --oyUTqETQ0mS9luUI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Feb 04, 2005 at 02:56:33PM +0800, Ganbold wrote: > Hi list, >=20 > I could not get emails from freebsd mailing list for last 1-2 days. >=20 > Following message is from our mail server log: >=20 > 2005-02-04 13:00:43 H=3D(mx2.freebsd.org) [216.136.204.119]=20 > F=3D rejected RCPT=20 > : rejected because 216.136.204.119 is in a black= =20 > list at dnsbl.sorbs.net >=20 > It seems like freebsd mail server is listed at dnsbl.sorbs.net. > When will freebsd mail server removed from the list? AFAIK that's not up to us, nor was it legitimate that the server be added in the first place. Kris --oyUTqETQ0mS9luUI Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCAyCdWry0BWjoQKURAuyvAKDW3NATRXd+Zu+jBK+6AYDp1TTVOwCg2kCt Pq64EhwsJ24/Z7xQSYCNBGI= =5wZb -----END PGP SIGNATURE----- --oyUTqETQ0mS9luUI-- From owner-freebsd-current@FreeBSD.ORG Fri Feb 4 07:15:03 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 199CE16A4CE; Fri, 4 Feb 2005 07:15:03 +0000 (GMT) Received: from obsecurity.dyndns.org (CPE0050040655c8-CM00111ae02aac.cpe.net.cable.rogers.com [69.199.47.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id CB89E43D41; Fri, 4 Feb 2005 07:15:02 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 3B36E512F2; Thu, 3 Feb 2005 23:15:02 -0800 (PST) Date: Thu, 3 Feb 2005 23:15:02 -0800 From: Kris Kennaway To: Mohan Srinivasan Message-ID: <20050204071502.GA17866@xor.obsecurity.org> References: <20050203180756.GA2103@xor.obsecurity.org> <20050203182917.40592.qmail@web80603.mail.yahoo.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GvXjxJ+pjyke8COw" Content-Disposition: inline In-Reply-To: <20050203182917.40592.qmail@web80603.mail.yahoo.com> User-Agent: Mutt/1.4.2.1i cc: ps@FreeBSD.org cc: current@FreeBSD.org cc: mohans cc: Kris Kennaway Subject: Re: Processes stuck in nfsreq X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2005 07:15:03 -0000 --GvXjxJ+pjyke8COw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Feb 03, 2005 at 10:29:16AM -0800, Mohan Srinivasan wrote: > Hi, >=20 > In the info you have below, the NFS request was not sent (R_SENT > is not set). We didn't send out the request because possibly nm_cwnd=20 > didn't allow us to send the request. If nfs_request() could not send=20 > the request, then typically, the request would be retransmitted from=20 > nfs_timer().=20 >=20 > If nm_cwnd is full, then there must be a lot of outstanding requests=20 > that haven't been replied to yet (on this mount), which is the fundamental > issue. >=20 > Can you force a core dump and send me a pointer to it ? >=20 > Also, after you force a core, can you also try a quick workaround - someo= ne > else also reported NFS client hangs and said that things were fine > after they set mpsafenet to 0. It would be good to see if there's a > correlation there. FYI, it looks like turning off mpsafenet indeed masks the bug. Kris --GvXjxJ+pjyke8COw Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCAyD1Wry0BWjoQKURAtL7AKCap5L4ngEpA8IG5HutQ18XVQO1zwCeIEs0 YMToeFVs1ewH88DzU5hKxT8= =ZyRw -----END PGP SIGNATURE----- --GvXjxJ+pjyke8COw-- From owner-freebsd-current@FreeBSD.ORG Fri Feb 4 07:26:12 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C5BF116A4CE for ; Fri, 4 Feb 2005 07:26:12 +0000 (GMT) Received: from publicd.ub.mng.net (publicd.ub.mng.net [202.179.0.88]) by mx1.FreeBSD.org (Postfix) with ESMTP id D69F643D45 for ; Fri, 4 Feb 2005 07:26:11 +0000 (GMT) (envelope-from ganbold@micom.mng.net) Received: from [202.179.0.164] (helo=ganbold.micom.mng.net) by publicd.ub.mng.net with esmtpa (Exim 4.43 (FreeBSD)) id 1Cwxx1-0007vW-O6 for freebsd-current@freebsd.org; Fri, 04 Feb 2005 15:32:23 +0800 Message-Id: <6.2.0.14.2.20050204152155.03145030@202.179.0.80> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Fri, 04 Feb 2005 15:23:57 +0800 To: freebsd-current@freebsd.org From: Ganbold Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: FreeBSD mail server is listed at dnsbl.sorbs.net X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2005 07:26:12 -0000 Sorry for my previous email, I didn't know whom I should contact. Ganbold From owner-freebsd-current@FreeBSD.ORG Fri Feb 4 07:34:35 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 708F016A4CE for ; Fri, 4 Feb 2005 07:34:35 +0000 (GMT) Received: from ppp162-47.static.internode.on.net (ppp162-47.static.internode.on.net [150.101.162.47]) by mx1.FreeBSD.org (Postfix) with ESMTP id DF1B243D1D for ; Fri, 4 Feb 2005 07:34:34 +0000 (GMT) (envelope-from emikulic@dmr.ath.cx) Received: by ppp162-47.static.internode.on.net (Poofix, from userid 1001) id D96EE613C; Fri, 4 Feb 2005 18:34:33 +1100 (EST) Date: Fri, 4 Feb 2005 18:34:33 +1100 From: Emil Mikulic To: Doug White Message-ID: <20050204073433.GA72959@dmr.ath.cx> Mail-Followup-To: Emil Mikulic , Doug White , freebsd-current@freebsd.org References: <20050203094355.GA4767@dmr.ath.cx> <20050203205144.C47315@carver.gumbysoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050203205144.C47315@carver.gumbysoft.com> X-PGP-ID: 1024D/344A699F X-PGP-Fingerprint: EE97 2C84 6D07 E76C F075 C0BA ED2A 9319 344A 699F X-Written-On: dmr.ath.cx (FreeBSD 6.0-CURRENT i386) User-Agent: Mutt/1.5.6i cc: freebsd-current@freebsd.org Subject: Re: Can't see OpenBSD's slices X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2005 07:34:35 -0000 On Thu, Feb 03, 2005 at 08:57:04PM -0800, Doug White wrote: > On Thu, 3 Feb 2005, Emil Mikulic wrote: > > ad1 is a hard-drive taken from an OpenBSD machine that had / and swap > > and /tmp and /var and /usr on it (at least). The machine it's now in is > > running FreeBSD 6-CURRENT and it only sees one slice... > > I assume the OpenBSD machine was i386 and not sparc. Yes, i386. Actually, the disk is still in the same machine, just the primary master now has a FreeBSD install on it. > Well you rattled off 5 partitions so its not MBR-based. > Do you have a partition map from OpenBSD to compare with? Under OpenBSD it was all one partition with a bunch of slices (or labels or whatever) in it. # fdisk -t /dev/ad1 [...] Media sector size is 512 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: The data for partition 2 is: The data for partition 3 is: The data for partition 4 is: sysid 166 (0xa6),(OpenBSD) start 63, size 12594897 (6149 Meg), flag 80 (active) beg: cyl 0/ head 1/ sector 1; end: cyl 783/ head 254/ sector 63 What do you mean by partition map? --Emil From owner-freebsd-current@FreeBSD.ORG Fri Feb 4 08:34:01 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 52D5816A4CE for ; Fri, 4 Feb 2005 08:34:01 +0000 (GMT) Received: from stealth.sorbs.net (stealth.sorbs.net [203.101.254.254]) by mx1.FreeBSD.org (Postfix) with ESMTP id 981EE43D1F for ; Fri, 4 Feb 2005 08:34:00 +0000 (GMT) (envelope-from matthew@uq.edu.au) Received: from goliath.sorbs.net (goliath.sorbs.net [203.15.51.42]) by stealth.sorbs.net (Postfix) with ESMTP id 8653CDF95F for ; Fri, 4 Feb 2005 18:33:26 +1000 (EST) Received: from twister.isux.com (unknown [192.168.1.5]) by goliath.sorbs.net (Postfix) with ESMTP id 8FED12C5C9 for ; Fri, 4 Feb 2005 18:33:56 +1000 (EST) Received: from [10.200.254.98] (stealthd.wireless.isux.com [10.200.254.98]) by twister.isux.com (iPlanet Messaging Server 5.2 HotFix 1.07 (built Nov 25 2002)) with ESMTPA id <0IBD00FZIOWOKO@twister.isux.com> for freebsd-current@freebsd.org; Fri, 04 Feb 2005 18:29:15 +1000 (EST) Date: Fri, 04 Feb 2005 18:33:03 +1000 From: Matthew Sullivan In-reply-to: <6.2.0.14.2.20050204145224.03142560@202.179.0.80> To: freebsd-current@freebsd.org Message-id: <4203333F.50003@uq.edu.au> MIME-version: 1.0 Content-type: multipart/signed; boundary=------------ms020104050308070208040108; micalg=sha1; protocol="application/x-pkcs7-signature" X-Accept-Language: en User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040618 References: <6.2.0.14.2.20050204145224.03142560@202.179.0.80> Subject: Re: OT: FreeBSD mail server is listed at dnsbl.sorbs.net X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2005 08:34:01 -0000 This is a cryptographically signed message in MIME format. --------------ms020104050308070208040108 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Ganbold wrote: > It seems like freebsd mail server is listed at dnsbl.sorbs.net. > When will freebsd mail server removed from the list? It was listed by mistake and has already been removed. Regards, -- Matthew Sullivan Specialist Systems Programmer Information Technology Services The University of Queensland --------------ms020104050308070208040108 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIG7DCC A3IwggJaoAMCAQICASowDQYJKoZIhvcNAQEEBQAwgaMxCzAJBgNVBAYTAkFVMRMwEQYDVQQI EwpRdWVlbnNsYW5kMREwDwYDVQQHEwhCcmlzYmFuZTElMCMGA1UEChMcVGhlIFVuaXZlcnNp dHkgb2YgUXVlZW5zbGFuZDEoMCYGA1UECxMfSW5mb3JtYXRpb24gVGVjaG5vbG9neSBTZXJ2 aWNlczEbMBkGA1UEAxMSQ2VydGlmaWNhdGUgU2VydmVyMB4XDTA0MDEyMTIzMzYyMVoXDTA2 MDEyMTIzMzYyMVowgbIxCzAJBgNVBAYTAkFVMSUwIwYDVQQKExxUaGUgVW5pdmVyc2l0eSBv ZiBRdWVlbnNsYW5kMScwJQYDVQQLEx5JbmZvcm1hdGlvbiBUZWNub2xvZ3kgU2VydmljZXMx FjAUBgoJkiaJk/IsZAEBEwZjY21hdHQxGTAXBgNVBAMTEE1hdHRoZXcgU3VsbGl2YW4xIDAe BgkqhkiG9w0BCQEWEW1hdHRoZXdAdXEuZWR1LmF1MFwwDQYJKoZIhvcNAQEBBQADSwAwSAJB AJsUfrw/QUqKIzDverWc2F4GFFRZmIeO+bAl+7BM6x/9frMzOtygx4QGb4oQwtOE8Sda1aIs v+yJF3Di9EuUyvMCAwEAAaNoMGYwDgYDVR0PAQH/BAQDAgXgMBEGCWCGSAGG+EIBAQQEAwIF oDAfBgNVHSMEGDAWgBQmqtoyueiWTYZBinvsnzeOWLtUuzAgBgNVHREEGTAXgRVtYXR0aGV3 QGl0cy51cS5lZHUuYXUwDQYJKoZIhvcNAQEEBQADggEBAF2gZrkqZsZlHd4K/+yBN6qrpD61 hctDf7/Eg4jk6DMknEs6nvHMFUMZ4SXvkqPLnHBygTARKAs7qBSLd7mUUBOOQEgk6ovQVY6S 1CDSt3P9O6wjG0K1igtk8v6u7lkQ8p2STXqrOePVINdaucUgBO/IpeUtt9ATl1qvPTWyM/fz oUZsIKeYjNQVEQsuimrZjdbIAFxdl1fggSngUv64wBn8wCssGrPZIZA2lpBBEW1wejoWrDOH IIr+SspGd0i8MovDTMRSvgTERLki17FU/ANilcrSXiODKeIvpXhnQqVScnsoMSZmBmN2QIoG SnBjNK5mYxx5E3v20VOwtP1hVdEwggNyMIICWqADAgECAgEqMA0GCSqGSIb3DQEBBAUAMIGj MQswCQYDVQQGEwJBVTETMBEGA1UECBMKUXVlZW5zbGFuZDERMA8GA1UEBxMIQnJpc2JhbmUx JTAjBgNVBAoTHFRoZSBVbml2ZXJzaXR5IG9mIFF1ZWVuc2xhbmQxKDAmBgNVBAsTH0luZm9y bWF0aW9uIFRlY2hub2xvZ3kgU2VydmljZXMxGzAZBgNVBAMTEkNlcnRpZmljYXRlIFNlcnZl cjAeFw0wNDAxMjEyMzM2MjFaFw0wNjAxMjEyMzM2MjFaMIGyMQswCQYDVQQGEwJBVTElMCMG A1UEChMcVGhlIFVuaXZlcnNpdHkgb2YgUXVlZW5zbGFuZDEnMCUGA1UECxMeSW5mb3JtYXRp b24gVGVjbm9sb2d5IFNlcnZpY2VzMRYwFAYKCZImiZPyLGQBARMGY2NtYXR0MRkwFwYDVQQD ExBNYXR0aGV3IFN1bGxpdmFuMSAwHgYJKoZIhvcNAQkBFhFtYXR0aGV3QHVxLmVkdS5hdTBc MA0GCSqGSIb3DQEBAQUAA0sAMEgCQQCbFH68P0FKiiMw73q1nNheBhRUWZiHjvmwJfuwTOsf /X6zMzrcoMeEBm+KEMLThPEnWtWiLL/siRdw4vRLlMrzAgMBAAGjaDBmMA4GA1UdDwEB/wQE AwIF4DARBglghkgBhvhCAQEEBAMCBaAwHwYDVR0jBBgwFoAUJqraMrnolk2GQYp77J83jli7 VLswIAYDVR0RBBkwF4EVbWF0dGhld0BpdHMudXEuZWR1LmF1MA0GCSqGSIb3DQEBBAUAA4IB AQBdoGa5KmbGZR3eCv/sgTeqq6Q+tYXLQ3+/xIOI5OgzJJxLOp7xzBVDGeEl75Kjy5xwcoEw ESgLO6gUi3e5lFATjkBIJOqL0FWOktQg0rdz/TusIxtCtYoLZPL+ru5ZEPKdkk16qznj1SDX WrnFIATvyKXlLbfQE5darz01sjP386FGbCCnmIzUFRELLopq2Y3WyABcXZdX4IEp4FL+uMAZ /MArLBqz2SGQNpaQQRFtcHo6FqwzhyCK/krKRndIvDKLw0zEUr4ExES5ItexVPwDYpXK0l4j gyniL6V4Z0KlUnJ7KDEmZgZjdkCKBkpwYzSuZmMceRN79tFTsLT9YVXRMYIDQDCCAzwCAQEw gakwgaMxCzAJBgNVBAYTAkFVMRMwEQYDVQQIEwpRdWVlbnNsYW5kMREwDwYDVQQHEwhCcmlz YmFuZTElMCMGA1UEChMcVGhlIFVuaXZlcnNpdHkgb2YgUXVlZW5zbGFuZDEoMCYGA1UECxMf SW5mb3JtYXRpb24gVGVjaG5vbG9neSBTZXJ2aWNlczEbMBkGA1UEAxMSQ2VydGlmaWNhdGUg U2VydmVyAgEqMAkGBSsOAwIaBQCgggItMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTA1MDIwNDA4MzMwM1owIwYJKoZIhvcNAQkEMRYEFIkFGx/fzIYoSLC3 A9/N1uh6RPESMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG6BgkrBgEEAYI3EAQx gawwgakwgaMxCzAJBgNVBAYTAkFVMRMwEQYDVQQIEwpRdWVlbnNsYW5kMREwDwYDVQQHEwhC cmlzYmFuZTElMCMGA1UEChMcVGhlIFVuaXZlcnNpdHkgb2YgUXVlZW5zbGFuZDEoMCYGA1UE CxMfSW5mb3JtYXRpb24gVGVjaG5vbG9neSBTZXJ2aWNlczEbMBkGA1UEAxMSQ2VydGlmaWNh dGUgU2VydmVyAgEqMIG8BgsqhkiG9w0BCRACCzGBrKCBqTCBozELMAkGA1UEBhMCQVUxEzAR BgNVBAgTClF1ZWVuc2xhbmQxETAPBgNVBAcTCEJyaXNiYW5lMSUwIwYDVQQKExxUaGUgVW5p dmVyc2l0eSBvZiBRdWVlbnNsYW5kMSgwJgYDVQQLEx9JbmZvcm1hdGlvbiBUZWNobm9sb2d5 IFNlcnZpY2VzMRswGQYDVQQDExJDZXJ0aWZpY2F0ZSBTZXJ2ZXICASowDQYJKoZIhvcNAQEB BQAEQDd7mWiTwiPwALxpbpoEbVLZy0lX5Zunm4km553PjY5JvQ/zg6fKANKIanT/EW+Kvqoh VFOdr8tX1eZCB0xpuFMAAAAAAAA= --------------ms020104050308070208040108-- From owner-freebsd-current@FreeBSD.ORG Fri Feb 4 08:43:09 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 50A6F16A4CE for ; Fri, 4 Feb 2005 08:43:09 +0000 (GMT) Received: from spider.deepcore.dk (cpe.atm2-0-53484.0x50a6c9a6.abnxx9.customer.tele.dk [80.166.201.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7C71D43D49 for ; Fri, 4 Feb 2005 08:43:08 +0000 (GMT) (envelope-from sos@DeepCore.dk) Received: from [172.18.2.1] (axiell-gw1.novi.dk [130.225.63.24]) by spider.deepcore.dk (8.12.11/8.12.10) with ESMTP id j148h2AU012340; Fri, 4 Feb 2005 09:43:04 +0100 (CET) (envelope-from sos@DeepCore.dk) Message-ID: <42033587.10506@DeepCore.dk> Date: Fri, 04 Feb 2005 09:42:47 +0100 From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= User-Agent: Mozilla Thunderbird 1.0 (X11/20050116) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "James D. Stewart" References: <42028F29.1030801@DeepCore.dk> <002001c50a71$0d7857e0$1401000a@c4.com> In-Reply-To: <002001c50a71$0d7857e0$1401000a@c4.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-mail-scanned: by DeepCore Virus & Spam killer v1.6 cc: freebsd-current@freebsd.org Subject: Re: ATA mkIII first official patches - please test! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2005 08:43:09 -0000 James D. Stewart wrote: > ----- Original Message -----=20 > Sent: Thursday, February 03, 2005 3:52 PM > Subject: ATA mkIII first official patches - please test! >=20 >=20 >=20 >>ATA-mkIII first official snapshot. >=20 >=20 > With RELENG_5, the following errors occur (if you need more info, ask > off-list): You need to update your sources the pccard stuff was MFC'd recently. --=20 -S=F8ren From owner-freebsd-current@FreeBSD.ORG Fri Feb 4 08:56:15 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A4CA816A4CE for ; Fri, 4 Feb 2005 08:56:15 +0000 (GMT) Received: from mp2.macomnet.net (mp2.macomnet.net [195.128.64.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id BE26F43D4C for ; Fri, 4 Feb 2005 08:56:14 +0000 (GMT) (envelope-from maxim@FreeBSD.org) Received-SPF: pass (mp2.macomnet.net: domain of maxim@FreeBSD.org designates 127.0.0.1 as permitted sender) receiver=mp2.macomnet.net; client_ip=127.0.0.1; envelope-from=maxim@FreeBSD.org; Received: from localhost (localhost [127.0.0.1]) by mp2.macomnet.net (8.12.11/8.12.11) with ESMTP id j148uB6W021909; Fri, 4 Feb 2005 11:56:13 +0300 (MSK) (envelope-from maxim@FreeBSD.org) Date: Fri, 4 Feb 2005 11:56:11 +0300 (MSK) From: Maxim Konovalov To: Ryan Sommers In-Reply-To: <42030649.7020806@gamersimpact.com> Message-ID: <20050204115544.H20546@mp2.macomnet.net> References: <42030649.7020806@gamersimpact.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SpamTest-Info: Profile: Formal (208/050203) X-SpamTest-Info: Profile: Detect Hard (4/030526) X-SpamTest-Info: Profile: SysLog X-SpamTest-Info: Profile: Marking - Keywords (2/030321) X-SpamTest-Status: Not detected X-SpamTest-Version: SMTP-Filter Version 2.0.0 [0124], SpamtestISP/Release cc: current@FreeBSD.org Subject: Re: [PATCH] /etc/defaults/rc.conf -- Static Routing Explanation X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2005 08:56:15 -0000 On Thu, 3 Feb 2005, 23:21-0600, Ryan Sommers wrote: > The following patch makes it a little more clear how to use the > static routing tunable in rc.conf. > > If I don't hear from anyone, I'll submit a pr for it. There is a good example in rc.conf(5) already. -- Maxim Konovalov From owner-freebsd-current@FreeBSD.ORG Fri Feb 4 09:18:52 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3C52A16A4CE; Fri, 4 Feb 2005 09:18:52 +0000 (GMT) Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 56DC243D2F; Fri, 4 Feb 2005 09:18:51 +0000 (GMT) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de (cicely5.cicely.de [10.1.1.7]) (authenticated bits=0)j149IkwA083030 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Fri, 4 Feb 2005 10:18:48 +0100 (CET) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (cicely12.cicely.de [IPv6:3ffe:400:8d0:301::12]) by cicely5.cicely.de (8.12.10/8.12.10) with ESMTP id j149HiU3035794 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 Feb 2005 10:17:45 +0100 (CET) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.12.11/8.12.11) with ESMTP id j149HitT058199; Fri, 4 Feb 2005 10:17:44 +0100 (CET) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.12.11/8.12.11/Submit) id j149Hitk058198; Fri, 4 Feb 2005 10:17:44 +0100 (CET) (envelope-from ticso) Date: Fri, 4 Feb 2005 10:17:43 +0100 From: Bernd Walter To: Maxim Konovalov Message-ID: <20050204091743.GK51800@cicely12.cicely.de> References: <42030649.7020806@gamersimpact.com> <20050204115544.H20546@mp2.macomnet.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050204115544.H20546@mp2.macomnet.net> X-Operating-System: FreeBSD cicely12.cicely.de 5.2-CURRENT alpha User-Agent: Mutt/1.5.6i X-Spam-Status: No, hits=-4.9 required=3.0 tests=BAYES_00 autolearn=ham version=2.64 X-Spam-Report: * -4.9 BAYES_00 BODY: Bayesian spam probability is 0 to 1% * [score: 0.0000] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on cicely12.cicely.de cc: Ryan Sommers cc: current@freebsd.org Subject: Re: [PATCH] /etc/defaults/rc.conf -- Static Routing Explanation X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: ticso@cicely.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2005 09:18:52 -0000 On Fri, Feb 04, 2005 at 11:56:11AM +0300, Maxim Konovalov wrote: > On Thu, 3 Feb 2005, 23:21-0600, Ryan Sommers wrote: > > > The following patch makes it a little more clear how to use the > > static routing tunable in rc.conf. > > > > If I don't hear from anyone, I'll submit a pr for it. > > There is a good example in rc.conf(5) already. And comment lines are not defaults. -- B.Walter BWCT http://www.bwct.de bernd@bwct.de info@bwct.de From owner-freebsd-current@FreeBSD.ORG Fri Feb 4 09:38:44 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5DC4916A4CE; Fri, 4 Feb 2005 09:38:44 +0000 (GMT) Received: from hetzner.co.za (lfw.hetzner.co.za [196.7.18.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id B97F843D60; Fri, 4 Feb 2005 09:38:40 +0000 (GMT) (envelope-from ianf@hetzner.co.za) Received: from localhost ([127.0.0.1]) by hetzner.co.za with esmtp (Exim 3.36 #1) id 1CwzvC-00014A-00; Fri, 04 Feb 2005 11:38:38 +0200 To: John Baldwin From: Ian FREISLICH In-reply-to: Your message of "Thu, 03 Feb 2005 13:30:57 EST." <200502031330.57265.jhb@FreeBSD.org> X-Attribution: BOFH Date: Fri, 04 Feb 2005 11:38:38 +0200 Sender: ianf@hetzner.co.za Message-Id: cc: current@freebsd.org Subject: Re: sys/1386/i386/mptable.c rev 1.239 breaks boot. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2005 09:38:44 -0000 John Baldwin wrote: > On Monday 31 January 2005 07:01 am, Ian FREISLICH wrote: > > Hi > > > > I have a dual pII machine that doesn't boot with 1.239 of > > sys/1386/i386/mptable.c. It boots with this patch backed out. > > Does anyone have any ideas beyond backing out this patch? > > > > revision 1.239 > > date: 2005/01/18 20:27:24; author: jhb; state: Exp; lines: +7 -1 > > If a valid ELCR was found, consult it for the trigger mode of ISA > > interrupts that have a trigger mode of conforming. This fixes problems on > > some older machines that still route PCI devices via ISA interrupts when > > using an I/O APIC. > > > > This seems to be a case of breaking, rather than fixing older > > machines. It's highly reproduceable. I mailed the author of this > > commit over a week ago, but have not had a response yet :(. This > > is definitely a show-stopper, for me at least. > > It did fix other boxes. :( Can you provide a verbose dmesg? I've included both a working and broken kernel verbose boot. -- Ian Freislich <---------- Start Working verbose boot log ----------> /boot/kernel/acpi.ko text=0x3f230 data=0x1ea4+0x110c syms=[0x4+0x7320+0x4+0x9889] GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb SMAP type=01 base=0000000000000000 len=000000000009fc00 SMAP type=01 base=000000000009fc00 len=0000000000000400 SMAP type=02 base=00000000000f0000 len=0000000000010000 SMAP type=02 base=00000000fec00000 len=0000000000001000 SMAP type=02 base=00000000fee00000 len=0000000000001000 SMAP type=02 base=00000000ffff0000 len=0000000000010000 SMAP type=01 base=0000000000100000 len=000000000bef0000 SMAP type=03 base=000000000bff3000 len=000000000000d000 SMAP type=04 base=000000000bff0000 len=0000000000003000 Copyright (c) 1992-2005 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 6.0-CURRENT #70: Mon Jan 31 12:48:12 SAST 2005 ianf@brane-dead.freislich.nom.za:/web-cache/obj/usr/src/sys/BRANE-DEAD Preloaded elf kernel "/boot/kernel/kernel" at 0xc0760000. Preloaded elf module "/boot/kernel/apm.ko" at 0xc07601a0. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc0760248. MP Configuration Table version 1.1 found at 0xc00f1400 Table 'FACP' at 0xbff3040 MADT: No MADT table found APIC: Using the MPTable enumerator. SMP: Added CPU 0 (BSP) SMP: Added CPU 1 (AP) MPTable: Calibrating clock(s) ... i8254 clock: 1193982 Hz Timecounter "i8254" frequency 1193982 Hz quality 0 Calibrating TSC clock ... TSC clock: 267452840 Hz CPU: Pentium II/Pentium II Xeon/Celeron (267.45-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x634 Stepping = 4 Features=0x80fbff real memory = 201261056 (191 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009efff, 647168 bytes (158 pages) 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) 0x0000000000828000 - 0x000000000bc5ffff, 188973056 bytes (46136 pages) avail memory = 191537152 (182 MB) APIC ID: physical 0, logical 0:0 APIC ID: physical 1, logical 0:1 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 bios32: Found BIOS32 Service Directory header at 0xc00faec0 bios32: Entry = 0xfb340 (c00fb340) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf0000+0xb370 pnpbios: Found PnP BIOS data at 0xc00fbf10 pnpbios: Entry = f0000:bf38 Rev = 1.0 Other BIOS signatures found: ioapic0: Assuming intbase of 0 ioapic0: Routing external 8259A's -> intpin 0 ioapic0: intpin 0 -> ExtINT (edge, high) ioapic0: intpin 1 -> ISA IRQ 1 (edge, high) ioapic0: intpin 2 -> ISA IRQ 2 (edge, high) ioapic0: intpin 3 -> ISA IRQ 3 (edge, high) ioapic0: intpin 4 -> ISA IRQ 4 (edge, high) ioapic0: intpin 5 -> ISA IRQ 5 (edge, high) ioapic0: intpin 6 -> ISA IRQ 6 (edge, high) ioapic0: intpin 7 -> ISA IRQ 7 (edge, high) ioapic0: intpin 8 -> ISA IRQ 8 (edge, high) ioapic0: intpin 9 -> ISA IRQ 9 (edge, high) ioapic0: intpin 10 -> ISA IRQ 10 (edge, high) ioapic0: intpin 11 -> ISA IRQ 11 (edge, high) ioapic0: intpin 12 -> ISA IRQ 12 (edge, high) ioapic0: intpin 13 -> ISA IRQ 13 (edge, high) ioapic0: intpin 14 -> ISA IRQ 14 (edge, high) ioapic0: intpin 15 -> ISA IRQ 15 (edge, high) ioapic0: intpin 16 -> PCI IRQ 16 (level, low) ioapic0: intpin 17 -> PCI IRQ 17 (level, low) ioapic0: intpin 18 -> PCI IRQ 18 (level, low) ioapic0: intpin 19 -> PCI IRQ 19 (level, low) ioapic0: intpin 20 -> PCI IRQ 20 (level, low) ioapic0: intpin 21 -> PCI IRQ 21 (level, low) ioapic0: intpin 22 -> PCI IRQ 22 (level, low) ioapic0: intpin 23 -> PCI IRQ 23 (level, low) ioapic0: intpin 1 bus ISA ioapic0: intpin 1 trigger: edge ioapic0: intpin 1 polarity: high ioapic0: intpin 2 bus ISA ioapic0: Routing IRQ 0 -> intpin 2 ioapic0: intpin 2 trigger: edge ioapic0: intpin 2 polarity: high ioapic0: intpin 3 bus ISA ioapic0: intpin 3 trigger: edge ioapic0: intpin 3 polarity: high ioapic0: intpin 4 bus ISA ioapic0: intpin 4 trigger: edge ioapic0: intpin 4 polarity: high ioapic0: intpin 5 bus ISA ioapic0: intpin 5 trigger: edge ioapic0: intpin 5 polarity: high ioapic0: intpin 6 bus ISA ioapic0: intpin 6 trigger: edge ioapic0: intpin 6 polarity: high ioapic0: intpin 7 bus ISA ioapic0: intpin 7 trigger: edge ioapic0: intpin 7 polarity: high ioapic0: intpin 8 bus ISA ioapic0: intpin 8 trigger: edge ioapic0: intpin 8 polarity: high ioapic0: intpin 9 bus ISA ioapic0: intpin 9 trigger: edge ioapic0: intpin 9 polarity: high ioapic0: intpin 10 bus ISA ioapic0: intpin 10 trigger: edge ioapic0: intpin 10 polarity: high ioapic0: intpin 11 bus ISA ioapic0: intpin 11 trigger: edge ioapic0: intpin 11 polarity: high ioapic0: intpin 12 bus ISA ioapic0: intpin 12 trigger: edge ioapic0: intpin 12 polarity: high ioapic0: intpin 13 bus ISA ioapic0: intpin 13 trigger: edge ioapic0: intpin 13 polarity: high ioapic0: intpin 14 bus ISA ioapic0: intpin 14 trigger: edge ioapic0: intpin 14 polarity: high ioapic0: intpin 15 bus ISA ioapic0: intpin 15 trigger: edge ioapic0: intpin 15 polarity: high ioapic0: intpin 19 bus PCI ioapic0: intpin 19 trigger: level ioapic0: intpin 19 polarity: low ioapic0: intpin 16 bus PCI ioapic0: intpin 16 trigger: level ioapic0: intpin 16 polarity: low ioapic0: intpin 16 bus PCI ioapic0: intpin 16 trigger: level ioapic0: intpin 16 polarity: low ioapic0: Routing SMI -> intpin 23 lapic: Routing ExtINT -> LINT0 lapic: Routing NMI -> LINT1 ioapic0 irqs 0-23 on motherboard cpu0 BSP: ID: 0x00000000 VER: 0x00040011 LDR: 0x01000000 DFR: 0x0fffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x00010000 therm: 0x00000000 err: 0x00010000 pcm: 0x00010000 null: io: random: mem: Pentium Pro MTRR support enabled ACPI disabled by blacklist. Contact your BIOS vendor. npx0: [FAST] npx0: on motherboard npx0: INT 16 interface pci_open(1): mode 1 addr port (0x0cf8) is 0x8000005c pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=71808086) pcibios: BIOS version 2.10 Found $PIR table, 8 entries at 0xc00fdc60 PCI-Only Interrupts: 10 11 Location Bus Device Pin Link IRQs slot 1 0 8 A 0x60 3 4 5 7 9 10 11 12 14 15 slot 1 0 8 B 0x61 3 4 5 7 9 10 11 12 14 15 slot 1 0 8 C 0x62 3 4 5 7 9 10 11 12 14 15 slot 1 0 8 D 0x63 3 4 5 7 9 10 11 12 14 15 slot 2 0 9 A 0x61 3 4 5 7 9 10 11 12 14 15 slot 2 0 9 B 0x62 3 4 5 7 9 10 11 12 14 15 slot 2 0 9 C 0x63 3 4 5 7 9 10 11 12 14 15 slot 2 0 9 D 0x60 3 4 5 7 9 10 11 12 14 15 slot 3 0 10 A 0x62 3 4 5 7 9 10 11 12 14 15 slot 3 0 10 B 0x63 3 4 5 7 9 10 11 12 14 15 slot 3 0 10 C 0x60 3 4 5 7 9 10 11 12 14 15 slot 3 0 10 D 0x61 3 4 5 7 9 10 11 12 14 15 slot 4 0 11 A 0x63 3 4 5 7 9 10 11 12 14 15 slot 4 0 11 B 0x60 3 4 5 7 9 10 11 12 14 15 slot 4 0 11 C 0x61 3 4 5 7 9 10 11 12 14 15 slot 4 0 11 D 0x62 3 4 5 7 9 10 11 12 14 15 embedded 0 12 A 0x60 3 4 5 7 9 10 11 12 14 15 embedded 0 12 B 0x61 3 4 5 7 9 10 11 12 14 15 embedded 0 12 C 0x62 3 4 5 7 9 10 11 12 14 15 embedded 0 12 D 0x63 3 4 5 7 9 10 11 12 14 15 embedded 0 7 A 0x60 3 4 5 7 9 10 11 12 14 15 embedded 0 7 B 0x61 3 4 5 7 9 10 11 12 14 15 embedded 0 7 D 0x63 3 4 5 7 9 10 11 12 14 15 embedded 0 1 A 0x60 3 4 5 7 9 10 11 12 14 15 embedded 0 1 B 0x61 3 4 5 7 9 10 11 12 14 15 embedded 0 1 C 0x62 3 4 5 7 9 10 11 12 14 15 embedded 0 1 D 0x63 3 4 5 7 9 10 11 12 14 15 pcib0: pcibus 0 on motherboard pci0: on pcib0 pci0: physical bus=0 map[10]: type 3, range 32, base e0000000, size 26, enabled found-> vendor=0x8086, dev=0x7180, revid=0x03 bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x2290, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x7181, revid=0x03 bus=0, slot=1, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x02a0, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x7110, revid=0x01 bus=0, slot=7, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x000f, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[20]: type 4, range 32, base 0000f000, size 4, enabled found-> vendor=0x8086, dev=0x7111, revid=0x01 bus=0, slot=7, func=1 class=01-01-80, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[20]: type 4, range 32, base 0000e000, size 5, enabled pcib0: unable to route slot 7 INTD found-> vendor=0x8086, dev=0x7112, revid=0x01 bus=0, slot=7, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=d, irq=11 map[90]: type 4, range 32, base 00005000, size 4, enabled found-> vendor=0x8086, dev=0x7113, revid=0x01 bus=0, slot=7, func=3 class=06-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0003, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[10]: type 4, range 32, base 0000e400, size 6, enabled pcib0: slot 8 INTA routed to irq 16 found-> vendor=0x10b7, dev=0x9050, revid=0x00 bus=0, slot=8, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0200, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x03 (750 ns), maxlat=0x08 (2000 ns) intpin=a, irq=16 map[10]: type 4, range 32, base 0000e800, size 8, enabled map[14]: type 1, range 32, base e6000000, size 12, enabled pcib0: slot 12 INTA routed to irq 16 found-> vendor=0x9004, dev=0x8078, revid=0x00 bus=0, slot=12, func=0 class=01-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0280, cachelnsz=8 (dwords) lattimer=0x40 (1920 ns), mingnt=0x08 (2000 ns), maxlat=0x08 (2000 ns) intpin=a, irq=16 agp0: mem 0xe0000000-0xe3ffffff at device 0.0 on pci0 agp0: Reserved 0x4000000 bytes for rid 0x10 type 3 at 0xe0000000 agp0: allocating GATT for aperture of size 64M pcib1: at device 1.0 on pci0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0xd000-0xdfff pcib1: memory decode 0xfff00000-0xfffff pcib1: prefetched decode 0xfff00000-0xfffff pci1: on pcib1 pci1: physical bus=1 isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0xf000-0xf00f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 7.1 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xf000 ata0: channel #0 on atapci0 atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 atapci0: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 ata0: reset tp1 mask=03 ostat0=50 ostat1=00 ata0-master: stat=0x50 err=0x01 lsb=0x00 msb=0x00 ata0-slave: stat=0x00 err=0x01 lsb=0x00 msb=0x00 ata0: reset tp2 stat0=50 stat1=00 devices=0x1 ata0: [MPSAFE] ata1: channel #1 on atapci0 atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170 atapci0: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376 ata1: reset tp1 mask=03 ostat0=01 ostat1=01 ata1-master: stat=0x03 err=0x03 lsb=0x03 msb=0x03 ata1-master: stat=0x01 err=0x01 lsb=0x01 msb=0x01 ata1-slave: stat=0x00 err=0x00 lsb=0x00 msb=0x00 ata1: reset tp2 stat0=01 stat1=00 devices=0x0 ata1: [MPSAFE] uhci0: port 0xe000-0xe01f irq 11 at device 7.2 on pci0 uhci0: Reserved 0x20 bytes for rid 0x20 type 4 at 0xe000 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 intpm0: port 0x5000-0x500f irq 9 at device 7.3 on pci0 intpm0: Reserved 0x10 bytes for rid 0x90 type 4 at 0x5000 intpm0: I/O mapped 5000 intpm0: intr IRQ 9 enabled revision 0 intpm0: [GIANT-LOCKED] intsmb0: on intpm0 smbus0: on intsmb0 smb0: on smbus0 intpm0: PM I/O mapped 4000 xl0: <3Com 3c905-TX Fast Etherlink XL> port 0xe400-0xe43f irq 16 at device 8.0 on pci0 xl0: Reserved 0x40 bytes for rid 0x10 type 4 at 0xe400 xl0: using port I/O xl0: media options word: e040 xl0: found MII/AUTO miibus0: on xl0 nsphy0: on miibus0 nsphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto xl0: bpf attached xl0: Ethernet address: 00:60:08:0b:2e:c8 xl0: [MPSAFE] ahc0: port 0xe800-0xe8ff mem 0xe6000000-0xe6000fff irq 16 at device 12.0 on pci0 ahc0: Defaulting to MEMIO on ahc0: Reserved 0x1000 bytes for rid 0x14 type 3 at 0xe6000000 ahc0: Reading SEEPROM...checksum error ahc0: No SEEPROM available. ahc0: Using left over BIOS settings ahc0: Downloading Sequencer Program... 449 instructions downloaded ahc0: Features 0x10005, Bugs 0x25, Flags 0x481460 ahc0: [GIANT-LOCKED] aic7880: Ultra Wide Channel A, SCSI Id=7, 16/253 SCBs cpu0 on motherboard cpu1 on motherboard pnpbios: 14 devices, largest 98 bytes PNP0200: adding dma mask 0x10 PNP0200: adding io range 0-0xf, size=0x10, align=0 PNP0200: adding io range 0x81-0x83, size=0x3, align=0 PNP0200: adding io range 0x87-0x87, size=0x1, align=0 PNP0200: adding io range 0x89-0x8b, size=0x3, align=0 PNP0200: adding io range 0x8f-0x91, size=0x3, align=0 PNP0200: adding io range 0xc0-0xdf, size=0x20, align=0 pnpbios: handle 1 device ID PNP0200 (0002d041) PNP0100: adding irq mask 0x1 PNP0100: adding io range 0x40-0x43, size=0x4, align=0 pnpbios: handle 2 device ID PNP0100 (0001d041) PNP0b00: adding irq mask 0x100 PNP0b00: adding io range 0x70-0x71, size=0x2, align=0 pnpbios: handle 3 device ID PNP0b00 (000bd041) PNP0303: adding irq mask 0x2 PNP0303: adding io range 0x60-0x60, size=0x1, align=0 PNP0303: adding io range 0x64-0x64, size=0x1, align=0 pnpbios: handle 4 device ID PNP0303 (0303d041) PNP0800: adding io range 0x61-0x61, size=0x1, align=0 pnpbios: handle 5 device ID PNP0800 (0008d041) PNP0c04: adding irq mask 0x2000 PNP0c04: adding io range 0xf0-0xff, size=0x10, align=0 pnpbios: handle 6 device ID PNP0c04 (040cd041) PNP0c01: adding fixed memory32 range 0-0x9ffff, size=0xa0000 PNP0c01: adding fixed memory32 range 0xfffe0000-0xffffffff, size=0x20000 PNP0c01: adding fixed memory32 range 0xfec00000-0xfec0ffff, size=0x10000 PNP0c01: adding fixed memory32 range 0xfee00000-0xfee0ffff, size=0x10000 PNP0c01: adding fixed memory32 range 0x100000-0xbffffff, size=0xbf00000 pnpbios: handle 7 device ID PNP0c01 (010cd041) PNP0c02: adding fixed memory32 range 0xf0000-0xf3fff, size=0x4000 PNP0c02: adding fixed memory32 range 0xf4000-0xf7fff, size=0x4000 PNP0c02: adding fixed memory32 range 0xf8000-0xfffff, size=0x8000 PNP0c02: adding fixed memory32 range 0xcc800-0xcffff, size=0x3800 pnpbios: handle 8 device ID PNP0c02 (020cd041) PNP0a03: adding io range 0x4d0-0x4d1, size=0x2, align=0 PNP0a03: adding io range 0xcf8-0xcff, size=0x8, align=0 PNP0a03: adding io range 0x480-0x48f, size=0x10, align=0 PNP0a03: adding io range 0x4000-0x403f, size=0x40, align=0 PNP0a03: adding io range 0x5000-0x501f, size=0x20, align=0 pnpbios: handle 9 device ID PNP0a03 (030ad041) PNP0501: adding irq mask 0x10 PNP0501: adding io range 0x3f8-0x3ff, size=0x8, align=0 pnpbios: handle 10 device ID PNP0501 (0105d041) PNP0700: adding dma mask 0x4 PNP0700: adding io range 0x3f2-0x3f5, size=0x4, align=0 PNP0700: adding irq mask 0x40 pnpbios: handle 11 device ID PNP0700 (0007d041) PNP0401: adding dma mask 0x8 PNP0401: adding irq mask 0x80 PNP0401: adding io range 0x378-0x37f, size=0x8, align=0 PNP0401: adding io range 0x778-0x77b, size=0x4, align=0 pnpbios: handle 12 device ID PNP0401 (0104d041) PNP0501: adding irq mask 0x8 PNP0501: adding io range 0x2f8-0x2ff, size=0x8, align=0 pnpbios: handle 13 device ID PNP0501 (0105d041) ata: ata0 already exists; skipping it ata: ata1 already exists; skipping it vga: vga0 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 isa_probe_children: disabling PnP devices isa_probe_children: probing non-PnP devices orm0: at iomem 0xc8000-0xcc7ff on isa0 vga0: failed to probe on isa0 adv0: not probed (disabled) aha0: not probed (disabled) aic0: not probed (disabled) atkbdc0: at port 0x64,0x60 on isa0 kbdc: DIAGNOSE status:0055 kbdc: TEST_KBD_PORT status:0000 kbdc: DIAGNOSE status:0055 kbdc: TEST_KBD_PORT status:0000 atkbd0: irq 1 on atkbdc0 kbdc: DIAGNOSE status:0055 kbdc: TEST_KBD_PORT status:0000 kbdc: DIAGNOSE status:0055 kbdc: TEST_KBD_PORT status:0000 kbdc: DIAGNOSE status:0055 kbdc: TEST_KBD_PORT status:0000 kbdc: DIAGNOSE status:0055 kbdc: TEST_KBD_PORT status:0000 kbd0 at atkbd0 kbd0: atkbd0, generic (0), config:0x0, flags:0x1f0000 atkbd0: [GIANT-LOCKED] psm0: current command byte:0067 kbdc: TEST_AUX_PORT status:0000 kbdc: RESET_AUX return code:00fe kbdc: RESET_AUX return code:00fe kbdc: RESET_AUX return code:00fe kbdc: DIAGNOSE status:0055 kbdc: TEST_KBD_PORT status:0000 psm0: failed to reset the aux device. bt0: not probed (disabled) cs0: not probed (disabled) ed0: not probed (disabled) fdc0: ic_type 90 part_id 80 fdc0: at port 0x3f0-0x3f5 irq 6 drq 2 on isa0 fdc0: ic_type 90 part_id 80 fdc0: [MPSAFE] fdc0: [FAST] fe0: not probed (disabled) ie0: not probed (disabled) lnc0: not probed (disabled) ppc0: parallel port found at 0x378 ppc0: using extended I/O port range ppc0: ECP SPP ECP+EPP SPP ppc0: at port 0x378-0x37f irq 7 on isa0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/16 bytes threshold ppbus0: on ppc0 plip0: on ppbus0 plip0: bpf attached lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 sc0: not probed (disabled) sio0: irq maps: 0x6081 0x6091 0x6081 0x6081 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A, console sio1: irq maps: 0x6081 0x6089 0x6081 0x6081 sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A sio2: not probed (disabled) sio3: not probed (disabled) sn0: not probed (disabled) vt0: not probed (disabled) isa_probe_children: probing PnP devices unknown: can't assign resources (port) unknown: at port 0x60 on isa0 unknown: failed to probe at port 0x61 on isa0 unknown: can't assign resources (memory) unknown: at iomem 0-0x9ffff on isa0 unknown: can't assign resources (port) unknown: at port 0x4d0-0x4d1 on isa0 unknown: can't assign resources (port) unknown: at port 0x3f8-0x3ff on isa0 unknown: can't assign resources (port) unknown: at port 0x3f2-0x3f5 on isa0 unknown: can't assign resources (port) unknown: at port 0x378-0x37f on isa0 unknown: can't assign resources (port) unknown: at port 0x2f8-0x2ff on isa0 Device configuration finished. Timecounter "TSC" frequency 267452840 Hz quality -100 Timecounters tick every 1.000 msec ipfw2 initialized, divert loadable, rule-based forwarding enabled, default to deny, logging unlimited lo0: bpf attached fdc0: output ready timeout fdc0: output ready timeout fdc0: output ready timeout fdc0: output ready timeout fdc0: output ready timeout fdc0: output ready timeout fdc0: output ready timeout ata0-master: pio=0x0c wdma=0x22 udma=0x44 cable=80pin ata0-master: setting PIO4 on Intel PIIX4 chip ata0-master: setting UDMA33 on Intel PIIX4 chip aGEOM: new disk ad0: ATA-4 disk at ata0-master ad0: 9787MB (20044080 sectors), 19885 C, 16 H, 63 S, 512 B ad0: 16 secs/int, 1 depth queue, UDMA33 Waiting 7 seconds for SCSI devices to settle (noperiph:ahc0:0:-1:-1): SCSI bus reset delivered. 0 SCBs aborted. d0 fdc0: output ready timeout fdc0: input ready timeout fdc0: input ready timeout fdc0: output ready timeout fdc0: input ready timeout fdc0: input ready timeout fdc0: output ready timeout fdc0: input ready timeout fdc0: input ready timeout fdc0: output ready timeout fdc0: input ready timeout fdc0: input ready timeout ahc0: Selection Timeout on A:6. 0 SCBs aborted ahc0: Selection Timeout on A:8. 0 SCBs aborted ahc0: Selection Timeout on A:3. 0 SCBs aborted ahc0: Selection Timeout on A:5. 0 SCBs aborted ahc0: Selection Timeout on A:9. 0 SCBs aborted ahc0: Selection Timeout on A:10. 0 SCBs aborted ahc0: Selection Timeout on A:11. 0 SCBs aborted ahc0: Selection Timeout on A:12. 0 SCBs aborted ahc0: Selection Timeout on A:13. 0 SCBs aborted ahc0: Selection Timeout on A:14. 0 SCBs aborted ahc0: Selection Timeout on A:15. 0 SCBs aborted (probe0:ahc0:0:0:0): Retrying Command (probe1:ahc0:0:1:0): Retrying Command (probe2:ahc0:0:2:0): Retrying Command (probe4:ahc0:0:4:0): error 22 (probe4:ahc0:0:4:0): Unretryable Error (ahc0:A:0:0): Sending WDTR 1 (ahc0:A:0:0): Received WDTR 1 filtered to 1 ahc0: target 0 using 16bit transfers (ahc0:A:0:0): Sending SDTR period c, offset 8 (ahc0:A:0:0): Received SDTR period c, offset 8 Filtered to period c, offset 8 ahc0: target 0 synchronous at 20.0MHz, offset = 0x8 (ahc0:A:1:0): Sending WDTR 1 (ahc0:A:1:0): Received WDTR 1 filtered to 1 ahc0: target 1 using 16bit transfers (ahc0:A:1:0): Sending SDTR period c, offset 8 (ahc0:A:1:0): Received SDTR period c, offset 8 Filtered to period c, offset 8 ahc0: target 1 synchronous at 20.0MHz, offset = 0x8 (ahc0:A:2:0): Sending WDTR 1 (ahc0:A:2:0): Received WDTR 1 filtered to 1 ahc0: target 2 using 16bit transfers (ahc0:A:2:0): Sending SDTR period c, offset 8 (ahc0:A:2:0): Received SDTR period c, offset 8 Filtered to period c, offset 8 ahc0: target 2 synchronous at 20.0MHz, offset = 0x8 pass0 at ahc0 bus 0 target 0 lun 0 pass0: Fixed Direct Access SCSI-2 device pass0: Serial Number LL288836000019231UNZ pass0: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing Enabled pass1 at ahc0 bus 0 target 1 lun 0 pass1: Fixed Direct Access SCSI-2 device pass1: Serial Number LL276239000019231SZS pass1: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing Enabled pass2 at ahc0 bus 0 target 2 lun 0 pass2: Fixed Direct Access SCSI-2 device pass2: Serial Number LL294251000019231T2W pass2: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing Enabled pass3 at ahc0 bus 0 target 4 lun 0 pass3: Removable CD-ROM SCSI-2 device pass3: 3.300MB/s transfers GE(cd0:ahc0:0:4:0): error 6 (cd0:ahc0:0:4:0): Unretryable Error cd0 at ahc0 bus 0 target 4 lun 0 cd0: Removable CD-ROM SCSI-2 device cd0: 3.300MB/s transfers cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed da2 at ahc0 bus 0 target 2 lun 0 da2: Fixed Direct Access SCSI-2 device da2: Serial Number LL294251000019231T2W da2: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing Enabled da2: 4340MB (8888924 512 byte sectors: 64H 32S/T 4340C) da1 at ahc0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-2 device da1: Serial Number LL276239000019231SZS da1: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing Enabled da1: 4340MB (8888924 512 byte sectors: 64H 32S/T 4340C) da0 at ahc0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: Serial Number LL288836000019231UNZ da0: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing Enabled da0: 4340MB (8888924 512 byte sectors: 64H 32S/T 4340C) OM: new disk cd0 GEOM: new disk da0 GEOM: new disk da1 GEOM: new disk da2 SMP: AP CPU #1 Launched! cpu1 AP: ID: 0x01000000 VER: 0x00040011 LDR: 0x02000000 DFR: 0x0fffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x00010000 therm: 0x00000000 err: 0x00010000 pcm: 0x00010000 ioapic0: routing intpin 1 (ISA IRQ 1) to cluster 0 ioapic0: routing intpin 3 (ISA IRQ 3) to cluster 0 ioapic0: routing intpin 4 (ISA IRQ 4) to cluster 0 ioapic0: routing intpin 6 (ISA IRQ 6) to cluster 0 ioapic0: routing intpin 7 (ISA IRQ 7) to cluster 0 ioapic0: routing intpin 8 (ISA IRQ 8) to cluster 0 ioapic0: routing intpin 9 (ISA IRQ 9) to cluster 0 ioapic0: routing intpin 11 (ISA IRQ 11) to cluster 0 ioapic0: routing intpin 13 (ISA IRQ 13) to cluster 0 ioapic0: routing intpin 14 (ISA IRQ 14) to cluster 0 ioapic0: routing intpin 15 (ISA IRQ 15) to cluster 0 ioapic0: routing intpin 16 (PCI IRQ 16) to cluster 0 (cd0:ahc0:0:4:0): error 6 (cd0:ahc0:0:4:0): Unretryable Error (cd0:ahc0:0:4:0): error 6 (cd0:ahc0:0:4:0): Unretryable Error (cd0:ahc0:0:4:0): error 6 (cd0:ahc0:0:4:0): Unretryable Error (cd0:ahc0:0:4:0): error 6 (cd0:ahc0:0:4:0): Unretryable Error <---------- End Working verbose boot log ----------> <---------- Start Broken verbose boot log ----------> /boot/kernel/acpi.ko text=0x3f230 data=0x1ea4+0x110c syms=[0x4+0x7320+0x4+0x9889 ] GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb SMAP type=01 base=0000000000000000 len=000000000009fc00 SMAP type=01 base=000000000009fc00 len=0000000000000400 SMAP type=02 base=00000000000f0000 len=0000000000010000 SMAP type=02 base=00000000fec00000 len=0000000000001000 SMAP type=02 base=00000000fee00000 len=0000000000001000 SMAP type=02 base=00000000ffff0000 len=0000000000010000 SMAP type=01 base=0000000000100000 len=000000000bef0000 SMAP type=03 base=000000000bff3000 len=000000000000d000 SMAP type=04 base=000000000bff0000 len=0000000000003000 Copyright (c) 1992-2005 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 6.0-CURRENT #72: Fri Feb 4 10:31:32 SAST 2005 ianf@brane-dead.freislich.nom.za:/web-cache/obj/usr/src/sys/BRANE-DEAD Preloaded elf kernel "/boot/kernel/kernel" at 0xc0760000. Preloaded elf module "/boot/kernel/apm.ko" at 0xc0760194. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc076023c. MP Configuration Table version 1.1 found at 0xc00f1400 Table 'FACP' at 0xbff3040 MADT: No MADT table found APIC: Using the MPTable enumerator. SMP: Added CPU 0 (BSP) SMP: Added CPU 1 (AP) MPTable: Calibrating clock(s) ... i8254 clock: 1193981 Hz Timecounter "i8254" frequency 1193981 Hz quality 0 Calibrating TSC clock ... TSC clock: 267453100 Hz CPU: Pentium II/Pentium II Xeon/Celeron (267.45-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x634 Stepping = 4 Features=0x80fbff real memory = 201261056 (191 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009efff, 647168 bytes (158 pages) 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) 0x0000000000828000 - 0x000000000bc5ffff, 188973056 bytes (46136 pages) avail memory = 191537152 (182 MB) APIC ID: physical 0, logical 0:0 APIC ID: physical 1, logical 0:1 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 bios32: Found BIOS32 Service Directory header at 0xc00faec0 bios32: Entry = 0xfb340 (c00fb340) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf0000+0xb370 pnpbios: Found PnP BIOS data at 0xc00fbf10 pnpbios: Entry = f0000:bf38 Rev = 1.0 Other BIOS signatures found: ioapic0: Assuming intbase of 0 ioapic0: Routing external 8259A's -> intpin 0 ioapic0: intpin 0 -> ExtINT (edge, high) ioapic0: intpin 1 -> ISA IRQ 1 (edge, high) ioapic0: intpin 2 -> ISA IRQ 2 (edge, high) ioapic0: intpin 3 -> ISA IRQ 3 (edge, high) ioapic0: intpin 4 -> ISA IRQ 4 (edge, high) ioapic0: intpin 5 -> ISA IRQ 5 (edge, high) ioapic0: intpin 6 -> ISA IRQ 6 (edge, high) ioapic0: intpin 7 -> ISA IRQ 7 (edge, high) ioapic0: intpin 8 -> ISA IRQ 8 (edge, high) ioapic0: intpin 9 -> ISA IRQ 9 (edge, high) ioapic0: intpin 10 -> ISA IRQ 10 (edge, high) ioapic0: intpin 11 -> ISA IRQ 11 (edge, high) ioapic0: intpin 12 -> ISA IRQ 12 (edge, high) ioapic0: intpin 13 -> ISA IRQ 13 (edge, high) ioapic0: intpin 14 -> ISA IRQ 14 (edge, high) ioapic0: intpin 15 -> ISA IRQ 15 (edge, high) ioapic0: intpin 16 -> PCI IRQ 16 (level, low) ioapic0: intpin 17 -> PCI IRQ 17 (level, low) ioapic0: intpin 18 -> PCI IRQ 18 (level, low) ioapic0: intpin 19 -> PCI IRQ 19 (level, low) ioapic0: intpin 20 -> PCI IRQ 20 (level, low) ioapic0: intpin 21 -> PCI IRQ 21 (level, low) ioapic0: intpin 22 -> PCI IRQ 22 (level, low) ioapic0: intpin 23 -> PCI IRQ 23 (level, low) ioapic0: intpin 1 bus ISA ioapic0: intpin 1 trigger: edge ioapic0: intpin 1 polarity: high ioapic0: intpin 2 bus ISA ioapic0: Routing IRQ 0 -> intpin 2 ioapic0: intpin 2 trigger: edge ioapic0: intpin 2 polarity: high ioapic0: intpin 3 bus ISA ioapic0: intpin 3 trigger: edge ioapic0: intpin 3 polarity: high ioapic0: intpin 4 bus ISA ioapic0: intpin 4 trigger: edge ioapic0: intpin 4 polarity: high ioapic0: intpin 5 bus ISA ioapic0: intpin 5 trigger: edge ioapic0: intpin 5 polarity: high ioapic0: intpin 6 bus ISA ioapic0: intpin 6 trigger: edge ioapic0: intpin 6 polarity: high ioapic0: intpin 7 bus ISA ioapic0: intpin 7 trigger: edge ioapic0: intpin 7 polarity: high ioapic0: intpin 8 bus ISA ioapic0: intpin 8 trigger: edge ioapic0: intpin 8 polarity: high ioapic0: intpin 9 bus ISA ioapic0: intpin 9 trigger: edge ioapic0: intpin 9 polarity: high ioapic0: intpin 10 bus ISA ioapic0: intpin 10 trigger: level ioapic0: intpin 10 polarity: high ioapic0: intpin 11 bus ISA ioapic0: intpin 11 trigger: level ioapic0: intpin 11 polarity: high ioapic0: intpin 12 bus ISA ioapic0: intpin 12 trigger: edge ioapic0: intpin 12 polarity: high ioapic0: intpin 13 bus ISA ioapic0: intpin 13 trigger: edge ioapic0: intpin 13 polarity: high ioapic0: intpin 14 bus ISA ioapic0: intpin 14 trigger: edge ioapic0: intpin 14 polarity: high ioapic0: intpin 15 bus ISA ioapic0: intpin 15 trigger: edge ioapic0: intpin 15 polarity: high ioapic0: intpin 19 bus PCI ioapic0: intpin 19 trigger: level ioapic0: intpin 19 polarity: low ioapic0: intpin 16 bus PCI ioapic0: intpin 16 trigger: level ioapic0: intpin 16 polarity: low ioapic0: intpin 16 bus PCI ioapic0: intpin 16 trigger: level ioapic0: intpin 16 polarity: low ioapic0: Routing SMI -> intpin 23 lapic: Routing ExtINT -> LINT0 lapic: Routing NMI -> LINT1 ioapic0 irqs 0-23 on motherboard cpu0 BSP: ID: 0x00000000 VER: 0x00040011 LDR: 0x01000000 DFR: 0x0fffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x00010000 therm: 0x00000000 err: 0x00010000 pcm: 0x00010000 null: io: random: mem: Pentium Pro MTRR support enabled ACPI disabled by blacklist. Contact your BIOS vendor. npx0: [FAST] npx0: on motherboard npx0: INT 16 interface pci_open(1): mode 1 addr port (0x0cf8) is 0x8000005c pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=71808086) pcibios: BIOS version 2.10 Found $PIR table, 8 entries at 0xc00fdc60 PCI-Only Interrupts: 10 11 Location Bus Device Pin Link IRQs slot 1 0 8 A 0x60 3 4 5 7 9 10 11 12 14 15 slot 1 0 8 B 0x61 3 4 5 7 9 10 11 12 14 15 slot 1 0 8 C 0x62 3 4 5 7 9 10 11 12 14 15 slot 1 0 8 D 0x63 3 4 5 7 9 10 11 12 14 15 slot 2 0 9 A 0x61 3 4 5 7 9 10 11 12 14 15 slot 2 0 9 B 0x62 3 4 5 7 9 10 11 12 14 15 slot 2 0 9 C 0x63 3 4 5 7 9 10 11 12 14 15 slot 2 0 9 D 0x60 3 4 5 7 9 10 11 12 14 15 slot 3 0 10 A 0x62 3 4 5 7 9 10 11 12 14 15 slot 3 0 10 B 0x63 3 4 5 7 9 10 11 12 14 15 slot 3 0 10 C 0x60 3 4 5 7 9 10 11 12 14 15 slot 3 0 10 D 0x61 3 4 5 7 9 10 11 12 14 15 slot 4 0 11 A 0x63 3 4 5 7 9 10 11 12 14 15 slot 4 0 11 B 0x60 3 4 5 7 9 10 11 12 14 15 slot 4 0 11 C 0x61 3 4 5 7 9 10 11 12 14 15 slot 4 0 11 D 0x62 3 4 5 7 9 10 11 12 14 15 embedded 0 12 A 0x60 3 4 5 7 9 10 11 12 14 15 embedded 0 12 B 0x61 3 4 5 7 9 10 11 12 14 15 embedded 0 12 C 0x62 3 4 5 7 9 10 11 12 14 15 embedded 0 12 D 0x63 3 4 5 7 9 10 11 12 14 15 embedded 0 7 A 0x60 3 4 5 7 9 10 11 12 14 15 embedded 0 7 B 0x61 3 4 5 7 9 10 11 12 14 15 embedded 0 7 D 0x63 3 4 5 7 9 10 11 12 14 15 embedded 0 1 A 0x60 3 4 5 7 9 10 11 12 14 15 embedded 0 1 B 0x61 3 4 5 7 9 10 11 12 14 15 embedded 0 1 C 0x62 3 4 5 7 9 10 11 12 14 15 embedded 0 1 D 0x63 3 4 5 7 9 10 11 12 14 15 pcib0: pcibus 0 on motherboard pci0: on pcib0 pci0: physical bus=0 map[10]: type 3, range 32, base e0000000, size 26, enabled found-> vendor=0x8086, dev=0x7180, revid=0x03 bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x2290, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x7181, revid=0x03 bus=0, slot=1, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x02a0, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x7110, revid=0x01 bus=0, slot=7, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x000f, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[20]: type 4, range 32, base 0000f000, size 4, enabled found-> vendor=0x8086, dev=0x7111, revid=0x01 bus=0, slot=7, func=1 class=01-01-80, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[20]: type 4, range 32, base 0000e000, size 5, enabled pcib0: unable to route slot 7 INTD found-> vendor=0x8086, dev=0x7112, revid=0x01 bus=0, slot=7, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=d, irq=11 map[90]: type 4, range 32, base 00005000, size 4, enabled found-> vendor=0x8086, dev=0x7113, revid=0x01 bus=0, slot=7, func=3 class=06-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0003, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[10]: type 4, range 32, base 0000e400, size 6, enabled pcib0: slot 8 INTA routed to irq 16 found-> vendor=0x10b7, dev=0x9050, revid=0x00 bus=0, slot=8, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0200, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x03 (750 ns), maxlat=0x08 (2000 ns) intpin=a, irq=16 map[10]: type 4, range 32, base 0000e800, size 8, enabled map[14]: type 1, range 32, base e6000000, size 12, enabled pcib0: slot 12 INTA routed to irq 16 found-> vendor=0x9004, dev=0x8078, revid=0x00 bus=0, slot=12, func=0 class=01-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0280, cachelnsz=8 (dwords) lattimer=0x40 (1920 ns), mingnt=0x08 (2000 ns), maxlat=0x08 (2000 ns) intpin=a, irq=16 agp0: mem 0xe0000000-0xe3ffffff at d evice 0.0 on pci0 agp0: Reserved 0x4000000 bytes for rid 0x10 type 3 at 0xe0000000 agp0: allocating GATT for aperture of size 64M pcib1: at device 1.0 on pci0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0xd000-0xdfff pcib1: memory decode 0xfff00000-0xfffff pcib1: prefetched decode 0xfff00000-0xfffff pci1: on pcib1 pci1: physical bus=1 isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0xf000-0xf00f,0x376,0x170-0x177,0x 3f6,0x1f0-0x1f7 at device 7.1 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xf000 ata0: channel #0 on atapci0 atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 atapci0: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 ata0: reset tp1 mask=03 ostat0=50 ostat1=00 ata0-master: stat=0x50 err=0x01 lsb=0x00 msb=0x00 ata0-slave: stat=0x00 err=0x01 lsb=0x00 msb=0x00 ata0: reset tp2 stat0=50 stat1=00 devices=0x1 ata0: [MPSAFE] ata1: channel #1 on atapci0 atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170 atapci0: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376 ata1: reset tp1 mask=03 ostat0=00 ostat1=00 ata1-master: stat=0x02 err=0x02 lsb=0x02 msb=0x02 ata1-master: stat=0x00 err=0x00 lsb=0x00 msb=0x00 ata1-slave: stat=0x03 err=0x03 lsb=0x03 msb=0x03 ata1-slave: stat=0x01 err=0x01 lsb=0x01 msb=0x01 ata1: reset tp2 stat0=00 stat1=01 devices=0x0 ata1: [MPSAFE] uhci0: port 0xe000-0xe01f irq 11 at de vice 7.2 on pci0 uhci0: Reserved 0x20 bytes for rid 0x20 type 4 at 0xe000 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 intpm0: port 0x5000-0x500f irq 9 at device 7.3 on pci0 intpm0: Reserved 0x10 bytes for rid 0x90 type 4 at 0x5000 intpm0: I/O mapped 5000 intpm0: intr IRQ 9 enabled revision 0 intpm0: [GIANT-LOCKED] intsmb0: on intpm0 smbus0: on intsmb0 smb0: on smbus0 intpm0: PM I/O mapped 4000 xl0: <3Com 3c905-TX Fast Etherlink XL> port 0xe400-0xe43f irq 16 at device 8.0 o n pci0 xl0: Reserved 0x40 bytes for rid 0x10 type 4 at 0xe400 xl0: using port I/O xl0: media options word: e040 xl0: found MII/AUTO miibus0: on xl0 nsphy0: on miibus0 nsphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto xl0: bpf attached xl0: Ethernet address: 00:60:08:0b:2e:c8 xl0: [MPSAFE] ahc0: port 0xe800-0xe8ff mem 0xe6000000-0xe 6000fff irq 16 at device 12.0 on pci0 ahc0: Defaulting to MEMIO on ahc0: Reserved 0x1000 bytes for rid 0x14 type 3 at 0xe6000000 ahc0: Reading SEEPROM...checksum error ahc0: No SEEPROM available. ahc0: Using left over BIOS settings ahc0: Downloading Sequencer Program... 449 instructions downloaded ahc0: Features 0x10005, Bugs 0x25, Flags 0x481460 ahc0: [GIANT-LOCKED] aic7880: Ultra Wide Channel A, SCSI Id=7, 16/253 SCBs cpu0 on motherboard cpu1 on motherboard pnpbios: 14 devices, largest 98 bytes PNP0200: adding dma mask 0x10 PNP0200: adding io range 0-0xf, size=0x10, align=0 PNP0200: adding io range 0x81-0x83, size=0x3, align=0 PNP0200: adding io range 0x87-0x87, size=0x1, align=0 PNP0200: adding io range 0x89-0x8b, size=0x3, align=0 PNP0200: adding io range 0x8f-0x91, size=0x3, align=0 PNP0200: adding io range 0xc0-0xdf, size=0x20, align=0 pnpbios: handle 1 device ID PNP0200 (0002d041) PNP0100: adding irq mask 0x1 PNP0100: adding io range 0x40-0x43, size=0x4, align=0 pnpbios: handle 2 device ID PNP0100 (0001d041) PNP0b00: adding irq mask 0x100 PNP0b00: adding io range 0x70-0x71, size=0x2, align=0 pnpbios: handle 3 device ID PNP0b00 (000bd041) PNP0303: adding irq mask 0x2 PNP0303: adding io range 0x60-0x60, size=0x1, align=0 PNP0303: adding io range 0x64-0x64, size=0x1, align=0 pnpbios: handle 4 device ID PNP0303 (0303d041) PNP0800: adding io range 0x61-0x61, size=0x1, align=0 pnpbios: handle 5 device ID PNP0800 (0008d041) PNP0c04: adding irq mask 0x2000 PNP0c04: adding io range 0xf0-0xff, size=0x10, align=0 pnpbios: handle 6 device ID PNP0c04 (040cd041) PNP0c01: adding fixed memory32 range 0-0x9ffff, size=0xa0000 PNP0c01: adding fixed memory32 range 0xfffe0000-0xffffffff, size=0x20000 PNP0c01: adding fixed memory32 range 0xfec00000-0xfec0ffff, size=0x10000 PNP0c01: adding fixed memory32 range 0xfee00000-0xfee0ffff, size=0x10000 PNP0c01: adding fixed memory32 range 0x100000-0xbffffff, size=0xbf00000 pnpbios: handle 7 device ID PNP0c01 (010cd041) PNP0c02: adding fixed memory32 range 0xf0000-0xf3fff, size=0x4000 PNP0c02: adding fixed memory32 range 0xf4000-0xf7fff, size=0x4000 PNP0c02: adding fixed memory32 range 0xf8000-0xfffff, size=0x8000 PNP0c02: adding fixed memory32 range 0xcc800-0xcffff, size=0x3800 pnpbios: handle 8 device ID PNP0c02 (020cd041) PNP0a03: adding io range 0x4d0-0x4d1, size=0x2, align=0 PNP0a03: adding io range 0xcf8-0xcff, size=0x8, align=0 PNP0a03: adding io range 0x480-0x48f, size=0x10, align=0 PNP0a03: adding io range 0x4000-0x403f, size=0x40, align=0 PNP0a03: adding io range 0x5000-0x501f, size=0x20, align=0 pnpbios: handle 9 device ID PNP0a03 (030ad041) PNP0501: adding irq mask 0x10 PNP0501: adding io range 0x3f8-0x3ff, size=0x8, align=0 pnpbios: handle 10 device ID PNP0501 (0105d041) PNP0700: adding dma mask 0x4 PNP0700: adding io range 0x3f2-0x3f5, size=0x4, align=0 PNP0700: adding irq mask 0x40 pnpbios: handle 11 device ID PNP0700 (0007d041) PNP0401: adding dma mask 0x8 PNP0401: adding irq mask 0x80 PNP0401: adding io range 0x378-0x37f, size=0x8, align=0 PNP0401: adding io range 0x778-0x77b, size=0x4, align=0 pnpbios: handle 12 device ID PNP0401 (0104d041) PNP0501: adding irq mask 0x8 PNP0501: adding io range 0x2f8-0x2ff, size=0x8, align=0 pnpbios: handle 13 device ID PNP0501 (0105d041) ata: ata0 already exists; skipping it ata: ata1 already exists; skipping it vga: vga0 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 isa_probe_children: disabling PnP devices isa_probe_children: probing non-PnP devices orm0: at iomem 0xc8000-0xcc7ff on isa0 vga0: failed to probe on isa0 adv0: not probed (disabled) aha0: not probed (disabled) aic0: not probed (disabled) atkbdc0: at port 0x64,0x60 on isa0 kbdc: DIAGNOSE status:0055 kbdc: TEST_KBD_PORT status:0000 kbdc: DIAGNOSE status:0055 kbdc: TEST_KBD_PORT status:0000 atkbd0: irq 1 on atkbdc0 kbdc: DIAGNOSE status:0055 kbdc: TEST_KBD_PORT status:0000 kbdc: DIAGNOSE status:0055 kbdc: TEST_KBD_PORT status:0000 kbdc: DIAGNOSE status:0055 kbdc: TEST_KBD_PORT status:0000 kbdc: DIAGNOSE status:0055 kbdc: TEST_KBD_PORT status:0000 kbd0 at atkbd0 kbd0: atkbd0, generic (0), config:0x0, flags:0x1f0000 atkbd0: [GIANT-LOCKED] psm0: current command byte:0067 kbdc: TEST_AUX_PORT status:0000 kbdc: RESET_AUX return code:00fe kbdc: RESET_AUX return code:00fe kbdc: RESET_AUX return code:00fe kbdc: DIAGNOSE status:0055 kbdc: TEST_KBD_PORT status:0000 psm0: failed to reset the aux device. bt0: not probed (disabled) cs0: not probed (disabled) ed0: not probed (disabled) fdc0: ic_type 90 part_id 80 fdc0: at port 0x3f0-0x3f5 irq 6 drq 2 on isa0 fdc0: ic_type 90 part_id 80 fdc0: [MPSAFE] fdc0: [FAST] fe0: not probed (disabled) ie0: not probed (disabled) lnc0: not probed (disabled) ppc0: parallel port found at 0x378 ppc0: using extended I/O port range ppc0: ECP SPP ECP+EPP SPP ppc0: at port 0x378-0x37f irq 7 on isa0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/16 bytes threshold ppbus0: on ppc0 plip0: on ppbus0 plip0: bpf attached lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 sc0: not probed (disabled) sio0: irq maps: 0x6081 0x6091 0x6081 0x6081 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A, console sio1: irq maps: 0x6081 0x6089 0x6081 0x6081 sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A sio2: not probed (disabled) sio3: not probed (disabled) sn0: not probed (disabled) vt0: not probed (disabled) isa_probe_children: probing PnP devices unknown: can't assign resources (port) unknown: at port 0x60 on isa0 unknown: failed to probe at port 0x61 on isa0 unknown: can't assign resources (memory) unknown: at iomem 0-0x9ffff on isa0 unknown: can't assign resources (port) unknown: at port 0x4d0-0x4d1 on isa0 unknown: can't assign resources (port) unknown: at port 0x3f8-0x3ff on isa0 unknown: can't assign resources (port) unknown: at port 0x3f2-0x3f5 on isa0 unknown: can't assign resources (port) unknown: at port 0x378-0x37f on isa0 unknown: can't assign resources (port) unknown: at port 0x2f8-0x2ff on isa0 Device configuration finished. Timecounter "TSC" frequency 267453100 Hz quality -100 Timecounters tick every 1.000 msec lo0: bpf attached ipfw2 initialized, divert loadable, rule-based forwarding enabled, default to deny, logging unlimited <---------- End Broken verbose boot log ----------> From owner-freebsd-current@FreeBSD.ORG Fri Feb 4 10:45:46 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C2A0916A4CE for ; Fri, 4 Feb 2005 10:45:46 +0000 (GMT) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8545C43D48 for ; Fri, 4 Feb 2005 10:45:46 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with SMTP id 05FE746B28; Fri, 4 Feb 2005 05:45:46 -0500 (EST) Date: Fri, 4 Feb 2005 10:44:56 +0000 (GMT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Daniel Eriksson In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: current@freebsd.org cc: 'Mohan Srinivasan' cc: 'Kris Kennaway' Subject: RE: Processes stuck in nfsreq X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2005 10:45:46 -0000 On Fri, 4 Feb 2005, Daniel Eriksson wrote: > I wrote: > > > I only switched off net.isr yesterday, so I still don't > > know for sure if it has cured the problem, but I've moved > > well over 1000 files since then without any corruption > > issues. > > During the night a number of files being moved from the client to the > server have ended up corrupted (shorter than original, with a size > evenly dividable by 8192), so turning net.isr off wasn't the solution. Was the corruption of the same sort in both cases? While I wouldn't preclude a bug relating to increased parallelism in the socket/network stack code, page-aligned and neatly rounded sizes, etc, are suggestive of an NFS-side problem. BTW, have you tried watching the protocol stats with netstat -s to see if you're seeing corrupted packets at the lower layers in processing? It looks like the NFS client may not keep stats for all of its packet parsing problem spots, unfortunately, so that makes it a bit harder to figure out if/where problems are occuring in NFS packet handling. Robert N M Watson From owner-freebsd-current@FreeBSD.ORG Fri Feb 4 11:20:40 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7E82816A4CE; Fri, 4 Feb 2005 11:20:40 +0000 (GMT) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0FA5843D5F; Fri, 4 Feb 2005 11:20:40 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.1/8.13.1) with ESMTP id j14BKdUG050514; Fri, 4 Feb 2005 06:20:39 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.1/8.13.1) with ESMTP id j14BM4ZR004433; Fri, 4 Feb 2005 06:22:04 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 58C457306E; Fri, 4 Feb 2005 06:20:39 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050204112039.58C457306E@freebsd-current.sentex.ca> Date: Fri, 4 Feb 2005 06:20:39 -0500 (EST) X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on clamscanner4 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on clamscanner2 X-Virus-Status: Clean X-Virus-Status: Clean Subject: [current tinderbox] failure on alpha/alpha X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2005 11:20:40 -0000 TB --- 2005-02-04 10:00:01 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-02-04 10:00:01 - starting CURRENT tinderbox run for alpha/alpha TB --- 2005-02-04 10:00:01 - checking out the source tree TB --- 2005-02-04 10:00:01 - cd /home/tinderbox/CURRENT/alpha/alpha TB --- 2005-02-04 10:00:01 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-02-04 10:05:36 - building world (CFLAGS=-O2 -pipe) TB --- 2005-02-04 10:05:36 - cd /home/tinderbox/CURRENT/alpha/alpha/src TB --- 2005-02-04 10:05:36 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything TB --- 2005-02-04 11:12:52 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-02-04 11:12:52 - cd /home/tinderbox/CURRENT/alpha/alpha/src TB --- 2005-02-04 11:12:52 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Fri Feb 4 11:12:53 UTC 2005 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] objcopy --strip-debug coda5.ko.debug coda5.ko ===> cpufreq (all) cc -O2 -fno-strict-aliasing -pipe -mcpu=ev4 -mtune=ev5 -mieee -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I- -include /tinderbox/CURRENT/alpha/alpha/obj/alpha/tinderbox/CURRENT/alpha/alpha/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -I@/../include -finline-limit=15000 -fno-common -g -I/tinderbox/CURRENT/alpha/alpha/obj/alpha/tinderbox/CURRENT/alpha/alpha/src/sys/GENERIC -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /tinderbox/CURRENT/alpha/alpha/src/sys/modules/cpufreq/../../dev/cpufreq/ichss.c /tinderbox/CURRENT/alpha/alpha/src/sys/modules/cpufreq/../../dev/cpufreq/ichss.c: In function `ichss_set': /tinderbox/CURRENT/alpha/alpha/src/sys/modules/cpufreq/../../dev/cpufreq/ichss.c:319: warning: implicit declaration of function `disable_intr' /tinderbox/CURRENT/alpha/alpha/src/sys/modules/cpufreq/../../dev/cpufreq/ichss.c:319: warning: nested extern declaration of `disable_intr' /tinderbox/CURRENT/alpha/alpha/src/sys/modules/cpufreq/../../dev/cpufreq/ichss.c:333: warning: implicit declaration of function `enable_intr' /tinderbox/CURRENT/alpha/alpha/src/sys/modules/cpufreq/../../dev/cpufreq/ichss.c:333: warning: nested extern declaration of `enable_intr' *** Error code 1 Stop in /tinderbox/CURRENT/alpha/alpha/src/sys/modules/cpufreq. *** Error code 1 Stop in /tinderbox/CURRENT/alpha/alpha/src/sys/modules. *** Error code 1 Stop in /tinderbox/CURRENT/alpha/alpha/obj/alpha/tinderbox/CURRENT/alpha/alpha/src/sys/GENERIC. *** Error code 1 Stop in /tinderbox/CURRENT/alpha/alpha/src. *** Error code 1 Stop in /tinderbox/CURRENT/alpha/alpha/src. TB --- 2005-02-04 11:20:39 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-02-04 11:20:39 - ERROR: failed to build generic kernel TB --- 2005-02-04 11:20:39 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Thu Feb 3 17:01:35 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CCFF816A4CF; Thu, 3 Feb 2005 17:01:35 +0000 (GMT) Received: from sphinx.mythic-beasts.com (sphinx.mythic-beasts.com [212.69.37.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0F02943D55; Thu, 3 Feb 2005 17:01:35 +0000 (GMT) (envelope-from chris@sphinx.mythic-beasts.com) Received: from chris by sphinx.mythic-beasts.com with local (Exim 4.34) id 1CwkMF-000844-EX; Thu, 03 Feb 2005 17:01:31 +0000 Date: Thu, 3 Feb 2005 17:01:31 +0000 From: Chris Lightfoot To: Martin Blapp Message-ID: References: <20050203123816.A55976@cvs.imp.ch> <20050203085004.G21031@sotec.home> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20050203085004.G21031@sotec.home> User-Agent: Mutt/1.4i X-Mail-Author: me X-Face: "kUA_=&I|(by86eXgYc|U}5`O%M(P#,)y`g7N}Boz4b^JTFYHPz:s%idl@t$\Vv$3OL6:>GEGwFHrV$/bfnL=6uO/ggqZfet:&D3 Q=9c X-Face-Plug: http://www.mythic-beasts.com/tools-toys/xface/ X-Sigs-Plug: vote on my signature quotes at http://ex-parrot.com/~chris/scripts/amisigornot Sender: Chris Lightfoot X-Mailman-Approved-At: Fri, 04 Feb 2005 12:56:26 +0000 cc: freebsd-current@freebsd.org cc: Robert Watson Subject: Re: getline() very very slow on localhost on 5.X X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2005 17:01:35 -0000 On Thu, Feb 03, 2005 at 08:57:00AM -0800, Mikko Työläjärvi wrote: > Judging by the tcpdump, I'd say tpop3d needs to setockopt(TCP_NODELAY). yep -- you could try that. In the CVS version the output is better buffered, so this problem shouldn't arise. -- On the internet, nobody knows you're a dog. (from The Far Side) From owner-freebsd-current@FreeBSD.ORG Fri Feb 4 14:48:59 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1A53F16A4CF for ; Fri, 4 Feb 2005 14:48:59 +0000 (GMT) Received: from node15.coopprint.com (node15.cooperativeprinting.com [208.4.77.15]) by mx1.FreeBSD.org (Postfix) with SMTP id 5E66C43D54 for ; Fri, 4 Feb 2005 14:48:57 +0000 (GMT) (envelope-from ryans@gamersimpact.com) Received: (qmail 66766 invoked by uid 0); 4 Feb 2005 14:48:49 -0000 Received: from unknown (HELO ?192.168.0.5?) (63.231.157.250) by node15.coopprint.com with SMTP; 4 Feb 2005 14:48:49 -0000 Message-ID: <42038B63.4060803@gamersimpact.com> Date: Fri, 04 Feb 2005 08:49:07 -0600 From: Ryan Sommers User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ticso@cicely.de References: <42030649.7020806@gamersimpact.com> <20050204115544.H20546@mp2.macomnet.net> <20050204091743.GK51800@cicely12.cicely.de> In-Reply-To: <20050204091743.GK51800@cicely12.cicely.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: Maxim Konovalov cc: current@freebsd.org Subject: Re: [PATCH] /etc/defaults/rc.conf -- Static Routing Explanation X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2005 14:48:59 -0000 Maxim Konovalov wrote: > > There is a good example in rc.conf(5) already. > We have examples in both rc.conf(5) (as shown below) and defaults/rc.conf then. To keep a form of congruence why not put all the examples in one place, either the manpage or the file? As someone that's used FreeBSD since 4.0-RELEASE I had to do a less /etc/rc.d/routing to figure out how to use the tunables. It was my fault that I didn't do a man rc.conf, however, never in my using FreeBSD and rc.conf have I needed to look at this manpage. Nor have I ever seen there was one. Might I also suggest a reference in defaults/rc.conf to the manpage? Bernd Walter wrote: > > And comment lines are not defaults. > Then I guess the following lines need to all be removed: #cloned_interfaces="gif0 gif1 gif2 gif3" # Pre-cloning GENERIC config. #ifconfig_lo0_alias0="inet 127.0.0.254 netmask 0xffffffff" # Sample alias entry. #ifconfig_ed0_ipx="ipx 0x00010010" # Sample IPX address family entry. #sppp_interfaces="isp0" # example: sppp over ISDN #spppconfig_isp0="authproto=chap myauthname=foo myauthsecret='top secret' hisauthname=some-gw hisauthsecret='another secret'" #gif_interfaces="gif0 gif1" # Examples typically for a router. #gifconfig_gif0="10.1.1.1 10.1.2.1" # Examples typically for a router. #gifconfig_gif1="10.1.1.2 10.1.2.2" # Examples typically for a router. #syslogd_flags="-ss" # Syslogd flags to not bind an inet socket #atm_netif_hea0="atm 1" # Network interfaces for physical interface. #atm_sigmgr_hea0="uni31" # Signalling manager for physical interface. #atm_prefix_hea0="ILMI" # NSAP prefix (UNI interfaces only) (or ILMI). #atm_macaddr_hea0="NO" # Override physical MAC address (or NO). #atm_arpserver_atm0="0x47.0005.80.999999.9999.9999.9999.999999999999.00" # ATMARP server address (or local). #atm_scsparp_atm0="NO" # Run SCSP/ATMARP on network interface (or NO). #ipv6_defaultrouter="2002:c058:6301::" # Use this for 6to4 (RFC 3068) #ipv6_static_routes="xxx" # An example to set fec0:0000:0000:0006::/64 #ipv6_route_xxx="fec0:0000:0000:0006:: -prefixlen 64 ::1" #ipv6_router_flags="-l" # Example for route6d with only IPv6 site local #ipv6_router_flags="-q" # If you want to run a routing daemon on an end #ipv6_network_interfaces="ed0 ep0" # Examples for router #ipv6_prefix_ed0="fec0:0000:0000:0001 fec0:0000:0000:0002" # Examples for rtr. #ipv6_prefix_ep0="fec0:0000:0000:0003 fec0:0000:0000:0004" # Examples for rtr. #ipv6_ifconfig_ed0="fec0:0:0:5::1 prefixlen 64" # Sample manual assign entry #ipv6_ifconfig_ed0_alias0="fec0:0:0:5::2 prefixlen 64" # Sample alias entry. #jail_example_rootdir="/usr/jail/default" # Jail's root directory #jail_example_hostname="default.domain.com" # Jail's hostname #jail_example_ip="192.168.0.10" # Jail's IP number #jail_example_exec="/bin/sh /etc/rc" # command to execute in jail #jail_example_devfs_enable="NO" # mount devfs in the jail #jail_example_fdescfs_enable="NO" # mount fdescfs in the jail #jail_example_procfs_enable="NO" # mount procfs in jail #jail_example_devfs_ruleset="ruleset_name" # devfs ruleset to apply to jail -- Ryan Sommers ryans@gamersimpact.com From owner-freebsd-current@FreeBSD.ORG Fri Feb 4 15:31:40 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BEFA916A4CE for ; Fri, 4 Feb 2005 15:31:40 +0000 (GMT) Received: from www.mmlab.cse.yzu.edu.tw (www.mmlab.cse.yzu.edu.tw [140.138.150.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id 60C7843D31 for ; Fri, 4 Feb 2005 15:31:40 +0000 (GMT) (envelope-from avatar@mmlab.cse.yzu.edu.tw) Received: by www.mmlab.cse.yzu.edu.tw (qmail, from userid 1000) id 6C5E64EFE09; Fri, 4 Feb 2005 23:31:39 +0800 (CST) Received: from localhost (localhost [127.0.0.1]) by www.mmlab.cse.yzu.edu.tw (qmail) with ESMTP id 6442F4EFD9E; Fri, 4 Feb 2005 23:31:39 +0800 (CST) Date: Fri, 4 Feb 2005 23:31:39 +0800 (CST) From: Tai-hwa Liang To: "Alexandre \"Sunny\" Kovalenko" In-Reply-To: <1107387525.979.7.camel@RabbitsDen> Message-ID: <0502042321154.16397@www.mmlab.cse.yzu.edu.tw> References: <63285.65.27.85.163.1107049410.squirrel@65.27.85.163> <41FC561C.3080505@errno.com> <41FEF40A.70006@gamersimpact.com> <1107387525.979.7.camel@RabbitsDen> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: Ryan Sommers cc: current@freebsd.org Subject: Re: WEP Encryption Changes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2005 15:31:40 -0000 On Wed, 2 Feb 2005, Alexandre "Sunny" Kovalenko wrote: > On Mon, 2005-01-31 at 21:14 -0600, Ryan Sommers wrote: >> I recently (Jan 17) updated my laptop to the latest current. The last >> update was in November. After the latest update my WEP wireless stopped >> working. After playing with it. It appears something is amiss in the Tx >> key for me. I'm able to see broadcast packets coming over the wap just >> fine. They don't appear to be corrupt. However, nothing from the laptop >> gets to the wap. I'm wondering if Sam's update of sys/net80211 back in >> December might be the culprit. >> >> One thing I did notice was the new deftxkey option in ifconfig. I >> attempted to set this to 1 (to use the first and only key), didn't help. >> >> What all would I need to roll back to reverse these changes? Just >> sys/net80211 or would I need to hit sys/dev/wi also? >> >> Are there any better tools besides another wireless card (only have one >> unfortunately) to debug the frames? tcpdump seems to only get me so far. >> >> For the record this is a Lucent embedded WaveLAN (Dell Trumobile 1150) >> firmware 8.10.1. >> > I remember having to add 'weptxkey 1' to the ifconfig line when these > changes went in. > > As far as tools -- I was using /usr/src/tools/tools/ath/80211debug but, > since I had Atheros card then, I could not vouch for its applicability > in your case. I can have my if_wi(Thinkpad R40 builtin Actiontec, firmware 1.1.1/1.7.2) associated with a WEP enabled BSS with following command(assume that key 3 is the default key configured on the AP): ifconfig wi0 ssid my_ssid wepmode on wepkey 3:12345 deftxkey 3 up It's a -CURRENT cvsup'ed on Jan-28-2005. Setting the default TX key with "deftxkey" did the trick for me. -- Cheers, Tai-hwa Liang From owner-freebsd-current@FreeBSD.ORG Fri Feb 4 16:12:37 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CF63616A4CE for ; Fri, 4 Feb 2005 16:12:37 +0000 (GMT) Received: from mailserv1.neuroflux.com (ns2.neuroflux.com [204.228.228.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 456D943D31 for ; Fri, 4 Feb 2005 16:12:37 +0000 (GMT) (envelope-from ryans@gamersimpact.com) Received: (qmail 74605 invoked by uid 89); 4 Feb 2005 16:09:49 -0000 Received: from unknown (HELO www2.neuroflux.com) (127.0.0.1) by localhost with SMTP; 4 Feb 2005 16:09:49 -0000 Received: from 208.4.77.203 (SquirrelMail authenticated user ryans@gamersimpact.com); by www2.neuroflux.com with HTTP; Fri, 4 Feb 2005 09:09:49 -0700 (MST) Message-ID: <64317.208.4.77.203.1107533389.squirrel@208.4.77.203> In-Reply-To: <0502042321154.16397@www.mmlab.cse.yzu.edu.tw> References: <63285.65.27.85.163.1107049410.squirrel@65.27.85.163> <41FC561C.3080505@errno.com> <41FEF40A.70006@gamersimpact.com> <1107387525.979.7.camel@RabbitsDen> <0502042321154.16397@www.mmlab.cse.yzu.edu.tw> Date: Fri, 4 Feb 2005 09:09:49 -0700 (MST) From: "Ryan Sommers" To: "Tai-hwa Liang" User-Agent: SquirrelMail/1.4.3a X-Mailer: SquirrelMail/1.4.3a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal cc: current@freebsd.org cc: "Alexandre \"Sunny\" Kovalenko" Subject: Re: WEP Encryption Changes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2005 16:12:37 -0000 Tai-hwa Liang said: > On Wed, 2 Feb 2005, Alexandre "Sunny" Kovalenko wrote: >> On Mon, 2005-01-31 at 21:14 -0600, Ryan Sommers wrote: >> I remember having to add 'weptxkey 1' to the ifconfig line when these >> changes went in. >> > It's a -CURRENT cvsup'ed on Jan-28-2005. Setting the default TX key > with "deftxkey" did the trick for me. Setting weptxkey worked. Setting the default didn't or at least it didn't the number of times I tried setting it. One thing I find odd is that the wepkey isn't automatically set as the Tx key as well. Are there any implementations that by default don't use the same key for Rx and Tx? Either way, I've added this to my list of things to look at. I don't imagine it being all that difficult to set the Tx key to the first entered WEP key. -- Ryan Sommers ryans@gamersimpact.com From owner-freebsd-current@FreeBSD.ORG Fri Feb 4 16:37:17 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2AFF216A4CE for ; Fri, 4 Feb 2005 16:37:17 +0000 (GMT) Received: from mail.chesapeake.net (chesapeake.net [208.142.252.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id AA72043D2F for ; Fri, 4 Feb 2005 16:37:16 +0000 (GMT) (envelope-from jroberson@chesapeake.net) Received: from mail.chesapeake.net (localhost [127.0.0.1]) by mail.chesapeake.net (8.12.10/8.12.10) with ESMTP id j14GbFc5002779; Fri, 4 Feb 2005 11:37:15 -0500 (EST) (envelope-from jroberson@chesapeake.net) Received: from localhost (jroberson@localhost)j14GbF4T002762; Fri, 4 Feb 2005 11:37:15 -0500 (EST) (envelope-from jroberson@chesapeake.net) X-Authentication-Warning: mail.chesapeake.net: jroberson owned process doing -bs Date: Fri, 4 Feb 2005 11:37:14 -0500 (EST) From: Jeff Roberson To: Kris Kennaway In-Reply-To: <20050204023809.GA39071@xor.obsecurity.org> Message-ID: <20050204113653.K18864@mail.chesapeake.net> References: <20050204023809.GA39071@xor.obsecurity.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: current@freebsd.org Subject: Re: panic: splay lookup failed in remove X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2005 16:37:17 -0000 On Thu, 3 Feb 2005, Kris Kennaway wrote: > I ran 4 fsx instances in parallel on a dual-cpu machine with > mpsafevfs=1 and up-to-date sources, and it panicked after a few > seconds with: Please mail me KTR output for KTR_LOCK & KTR_BUF or just KTR_LOCK if that's all you have. > > panic: splay lookup failed in remove > cpuid = 1 > KDB: enter: panic > [thread pid 3 tid 100121 ] > Stopped at kdb_enter+0x30: leave > db> tr > Tracing pid 3 tid 100121 td 0xc570c170 > kdb_enter(c06fb771,1,c0704ec6,eec1eac4,c570c170) at kdb_enter+0x30 > panic(c0704ec6,0,22,de81406c,c5a5a9f4) at panic+0x13e > buf_vlist_remove(de71cab4,0,c0704cf2,572,de71cab4) at buf_vlist_remove+0x94 > brelvp(de71cab4,0,4e6,c0703728,de71cab4) at brelvp+0xbe > brelse(de71cab4,c0703392,c72,c0703c55,de71cab4) at brelse+0x1ed > bufdone(de71cab4,0,c0703392,3c6) at bufdone+0x59c > vfs_backgroundwritedone(de71cab4,0,c0703392,c84,de71cab4) at vfs_backgroundwritedone+0x13f > bufdone(de71cab4,bdb,0,cc12b18c,cc12b18c) at bufdone+0x1c7 > g_vfs_done(cc12b18c,0,c0703392,bdb) at g_vfs_done+0xa2 > biodone(cc12b18c,c06f63e0,1e8,c06f67c1,cc12b18c) at biodone+0x72 > g_io_schedule_up(c570c170,0,c06f68ac,5d,0) at g_io_schedule_up+0x1a2 > g_up_procbody(0,eec1ed48,c06f8a14,30e,c570c170) at g_up_procbody+0x93 > fork_exit(c04edba8,0,eec1ed48) at fork_exit+0x11b > fork_trampoline() at fork_trampoline+0x8 > --- trap 0x1, eip = 0, esp = 0xeec1ed7c, ebp = 0 --- > > Kris From owner-freebsd-current@FreeBSD.ORG Fri Feb 4 16:38:45 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8F14416A4CE for ; Fri, 4 Feb 2005 16:38:45 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id B7A0943D3F for ; Fri, 4 Feb 2005 16:38:44 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.13.1/8.13.1) with ESMTP id j14Gb1f9021871; Fri, 4 Feb 2005 09:37:01 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Fri, 04 Feb 2005 09:38:49 -0700 (MST) Message-Id: <20050204.093849.06223657.imp@bsdimp.com> To: jds@elib.com From: "M. Warner Losh" In-Reply-To: <002001c50a71$0d7857e0$1401000a@c4.com> References: <42028F29.1030801@DeepCore.dk> <002001c50a71$0d7857e0$1401000a@c4.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 cc: freebsd-current@freebsd.org cc: sos@DeepCore.dk Subject: Re: ATA mkIII first official patches - please test! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2005 16:38:45 -0000 In message: <002001c50a71$0d7857e0$1401000a@c4.com> "James D. Stewart" writes: : > ATA-mkIII first official snapshot. : : With RELENG_5, the following errors occur (if you need more info, ask : off-list): This is due to changes in the names of some of the pc card devices based on cleanup I'm doing in current. I thought I'd merged all of this to releng_5 in the last couple of days, however.. Warner From owner-freebsd-current@FreeBSD.ORG Fri Feb 4 17:09:08 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4FD9816A4CE for ; Fri, 4 Feb 2005 17:09:08 +0000 (GMT) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id F311143D5C for ; Fri, 4 Feb 2005 17:09:07 +0000 (GMT) (envelope-from sam@errno.com) Received: from [66.127.85.91] (sam@[66.127.85.91]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.6) with ESMTP id j14H95Wi074552 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 Feb 2005 09:09:06 -0800 (PST) (envelope-from sam@errno.com) Message-ID: <4203AC57.5000708@errno.com> Date: Fri, 04 Feb 2005 09:09:43 -0800 From: Sam Leffler User-Agent: Mozilla Thunderbird 1.0RC1 (X11/20041208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ryan Sommers References: <63285.65.27.85.163.1107049410.squirrel@65.27.85.163> <41FC561C.3080505@errno.com> <41FEF40A.70006@gamersimpact.com> <1107387525.979.7.camel@RabbitsDen> <0502042321154.16397@www.mmlab.cse.yzu.edu.tw> <64317.208.4.77.203.1107533389.squirrel@208.4.77.203> In-Reply-To: <64317.208.4.77.203.1107533389.squirrel@208.4.77.203> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: Tai-hwa Liang cc: current@freebsd.org cc: "Alexandre \"Sunny\" Kovalenko" Subject: Re: WEP Encryption Changes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2005 17:09:08 -0000 Ryan Sommers wrote: > Tai-hwa Liang said: > >>On Wed, 2 Feb 2005, Alexandre "Sunny" Kovalenko wrote: >> >>>On Mon, 2005-01-31 at 21:14 -0600, Ryan Sommers wrote: >>>I remember having to add 'weptxkey 1' to the ifconfig line when these >>>changes went in. >>> >> >> It's a -CURRENT cvsup'ed on Jan-28-2005. Setting the default TX key >>with "deftxkey" did the trick for me. > > > Setting weptxkey worked. Setting the default didn't or at least it didn't > the number of times I tried setting it. I don't know what "the default" is. If you do ifconfig wi0 txkey - or ifconfig wi0 txkey undef then it resets the tx key state to be undefined; as it is when a device first comes up. In this state there is no default tx key to apply to outbound frames. Note that this is a change in behaviour from before my changes to support WPA. I found that having the default tx key set by default is error prone. Unfortunately I missed adding this to UPDATING and have yet to update the various manual pages because some of this code is still a bit fluid. I will add it to my TODO list. > > One thing I find odd is that the wepkey isn't automatically set as the Tx > key as well. Are there any implementations that by default don't use the > same key for Rx and Tx? Having implicit side effects for operations like setting a key can be a pain. ifconfig has the netbsd nwkey shorthand that you may find useful. > > Either way, I've added this to my list of things to look at. I don't > imagine it being all that difficult to set the Tx key to the first entered > WEP key. > Try nwkey. Sam From owner-freebsd-current@FreeBSD.ORG Fri Feb 4 17:23:00 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B15FC16A4CE for ; Fri, 4 Feb 2005 17:23:00 +0000 (GMT) Received: from web80605.mail.yahoo.com (web80605.mail.yahoo.com [66.218.79.94]) by mx1.FreeBSD.org (Postfix) with SMTP id 6EF5643D48 for ; Fri, 4 Feb 2005 17:23:00 +0000 (GMT) (envelope-from mohan_srinivasan@yahoo.com) Message-ID: <20050204172300.66172.qmail@web80605.mail.yahoo.com> Received: from [64.172.45.63] by web80605.mail.yahoo.com via HTTP; Fri, 04 Feb 2005 09:23:00 PST Date: Fri, 4 Feb 2005 09:23:00 -0800 (PST) From: Mohan Srinivasan To: Kris Kennaway In-Reply-To: <20050204071502.GA17866@xor.obsecurity.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii cc: ps@FreeBSD.org cc: current@FreeBSD.org Subject: Re: Processes stuck in nfsreq X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2005 17:23:00 -0000 Since we don't have a core, is it possible for me to get access to your kgdb client and the target host ? I was unable to reproduce this on my setup last time I tried (when you reported the issue first). (I've been sick this week, but I can look at this first thing Monday). mohan --- Kris Kennaway wrote: > On Thu, Feb 03, 2005 at 10:29:16AM -0800, Mohan Srinivasan wrote: > > Hi, > > > > In the info you have below, the NFS request was not sent (R_SENT > > is not set). We didn't send out the request because possibly nm_cwnd > > didn't allow us to send the request. If nfs_request() could not send > > the request, then typically, the request would be retransmitted from > > nfs_timer(). > > > > If nm_cwnd is full, then there must be a lot of outstanding requests > > that haven't been replied to yet (on this mount), which is the fundamental > > issue. > > > > Can you force a core dump and send me a pointer to it ? > > > > Also, after you force a core, can you also try a quick workaround - someone > > else also reported NFS client hangs and said that things were fine > > after they set mpsafenet to 0. It would be good to see if there's a > > correlation there. > > FYI, it looks like turning off mpsafenet indeed masks the bug. > > Kris > > ATTACHMENT part 2 application/pgp-signature From owner-freebsd-current@FreeBSD.ORG Fri Feb 4 17:29:40 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 892A416A4CE for ; Fri, 4 Feb 2005 17:29:40 +0000 (GMT) Received: from web80603.mail.yahoo.com (web80603.mail.yahoo.com [66.218.79.92]) by mx1.FreeBSD.org (Postfix) with SMTP id 44FAD43D45 for ; Fri, 4 Feb 2005 17:29:38 +0000 (GMT) (envelope-from mohan_srinivasan@yahoo.com) Message-ID: <20050204172938.45361.qmail@web80603.mail.yahoo.com> Received: from [64.172.45.63] by web80603.mail.yahoo.com via HTTP; Fri, 04 Feb 2005 09:29:38 PST Date: Fri, 4 Feb 2005 09:29:38 -0800 (PST) From: Mohan Srinivasan To: Daniel Eriksson , 'Kris Kennaway' In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii cc: current@freebsd.org Subject: RE: Processes stuck in nfsreq X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2005 17:29:40 -0000 The files truncated on an 8K boundary definitely smells like a NFS client problem. Given that the file is truncated on the server, it looks like the write(s) after the 8K boundary were not sent to the server and the client just discarded the dirty buffers ! Do you have any data as to when the breakage occurred ? I'll try to reproduce the issue (on my setup) next week. mohan --- Daniel Eriksson wrote: > I wrote: > > > I only switched off net.isr yesterday, so I still don't > > know for sure if it has cured the problem, but I've moved > > well over 1000 files since then without any corruption > > issues. > > During the night a number of files being moved from the client to the server > have ended up corrupted (shorter than original, with a size evenly dividable > by 8192), so turning net.isr off wasn't the solution. > > /Daniel Eriksson > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Fri Feb 4 18:29:57 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2CC1F16A4CE for ; Fri, 4 Feb 2005 18:29:57 +0000 (GMT) Received: from mailserv1.neuroflux.com (ns2.neuroflux.com [204.228.228.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id B0D4143D53 for ; Fri, 4 Feb 2005 18:29:56 +0000 (GMT) (envelope-from ryans@gamersimpact.com) Received: (qmail 86774 invoked by uid 89); 4 Feb 2005 18:27:09 -0000 Received: from unknown (HELO www2.neuroflux.com) (127.0.0.1) by localhost with SMTP; 4 Feb 2005 18:27:09 -0000 Received: from 208.4.77.203 (SquirrelMail authenticated user ryans@gamersimpact.com); by www2.neuroflux.com with HTTP; Fri, 4 Feb 2005 11:27:09 -0700 (MST) Message-ID: <52857.208.4.77.203.1107541629.squirrel@208.4.77.203> In-Reply-To: <4203AC57.5000708@errno.com> References: <63285.65.27.85.163.1107049410.squirrel@65.27.85.163> <41FC561C.3080505@errno.com> <41FEF40A.70006@gamersimpact.com> <1107387525.979.7.camel@RabbitsDen> <0502042321154.16397@www.mmlab.cse.yzu.edu.tw> <64317.208.4.77.203.1107533389.squirrel@208.4.77.203> <4203AC57.5000708@errno.com> Date: Fri, 4 Feb 2005 11:27:09 -0700 (MST) From: "Ryan Sommers" To: "Sam Leffler" User-Agent: SquirrelMail/1.4.3a X-Mailer: SquirrelMail/1.4.3a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal cc: current@freebsd.org Subject: Re: WEP Encryption Changes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2005 18:29:57 -0000 Sam Leffler said: > Ryan Sommers wrote: >> Tai-hwa Liang said: >> Setting weptxkey worked. Setting the default didn't or at least it >> didn't >> the number of times I tried setting it. > > I don't know what "the default" is. If you do > Sorry, should have been more specific. By default I meant the deftxkey opt wi0: flags=8843 mtu 1500 inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255 ether 00:02:2d:84:22:18 media: IEEE 802.11 Wireless Ethernet autoselect (DS/2Mbps) status: no carrier ssid RightHere stationname "FreeBSD WaveLAN/IEEE node" authmode OPEN privacy OFF _deftxkey 1_ txpowmax 100 (root@lilshadow)~: What is odd is the ifconfig options using 'deftxkey' looks the same as using 'weptxkey'. However, from my attempts to use deftxkey it doesn't have the same underlying effect on the encrption. I tried a few times to use this option to set my Tx key but it never seemed to work. Then when I tried using weptxkey it worked the first time. Now, that isn't to say they don't have the same outcome. My wireless card seems to have a few quirks that pop up every now and then, especially if you do a lot of settings changing, and deftxkey not working might have been one of those times. > error prone. Unfortunately I missed adding this to UPDATING and have > yet to update the various manual pages because some of this code is > still a bit fluid. I will add it to my TODO list. > >> It's not really a big deal, I just couldn't figure out why my wireless stopped working after an update. If you'd like, give me a list of the manpages that need updating and I'll see what I can get done this weekend, I'll have some extra time between doing builds for a new mailserver. I just found it somewhat counter-intuitive that doing: ifconfig wi0 ssid RightHere wepkey 0x1234567890 wepmode on didn't get wireless up and working like it did before. Having to add a 'weptxkey 1' seems redundant if I only enter a single key. But that's just my opinion. > Try nwkey. I'll have a look at it, thanks! -- Ryan Sommers ryans@gamersimpact.com From owner-freebsd-current@FreeBSD.ORG Fri Feb 4 20:44:10 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D4D1B16A4CE for ; Fri, 4 Feb 2005 20:44:10 +0000 (GMT) Received: from jail1-fbsd4.consiagnet.it (jail1-fbsd4.consiagnet.it [83.149.128.151]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7CA4D43D31 for ; Fri, 4 Feb 2005 20:44:10 +0000 (GMT) (envelope-from rionda@gufi.org) Received: from localhost.localdomain (host248-112.pool8250.interbusiness.it [82.50.112.248]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by jail1-fbsd4.consiagnet.it (Postfix) with ESMTP id B427857C1 for ; Fri, 4 Feb 2005 21:48:06 +0100 (CET) From: Matteo Riondato To: freebsd-current@freebsd.org Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-1ul5ayzWg/4trIir/z9q" Date: Fri, 04 Feb 2005 21:44:07 +0100 Message-Id: <1107549847.15645.10.camel@kaiser.sig11.org> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 FreeBSD GNOME Team Port Subject: Little mistake in UPDATING X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2005 20:44:10 -0000 --=-1ul5ayzWg/4trIir/z9q Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi folks! Line 11 of /usr/src/UPDATING says: [[ The UPDATING file will be trimmed to 20040814 on or about Oct 1, 2004 ]] I think this is a mistake, it should be "Oct 1, 2005"=20 Best Regards --=20 Rionda aka Matteo Riondato GUFI Staff Member (http://www.gufi.org) FreeSBIE Developer (http://www.freesbie.org) BSD-FAQ-it Main Developer (http://utenti.gufi.org/~rionda) Sent from: kaiser.sig11.org running FreeBSD-6.0-CURRENT --=-1ul5ayzWg/4trIir/z9q Content-Type: application/pgp-signature; name=signature.asc Content-Description: Questa parte del messaggio =?ISO-8859-1?Q?=E8?= firmata -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQBCA96X2Mp4pR7Fa+wRAi6iAJ4mVh9bXwexqazNkdO8xjSZiDgIuQCg1FEB nUKesVJb6SQ7RsNZonh/7qQ= =ymkP -----END PGP SIGNATURE----- --=-1ul5ayzWg/4trIir/z9q-- From owner-freebsd-current@FreeBSD.ORG Fri Feb 4 20:55:56 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4D06B16A4CE; Fri, 4 Feb 2005 20:55:56 +0000 (GMT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6FDBE43D4C; Fri, 4 Feb 2005 20:55:55 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from localhost (rocky.ip.net.ua [82.193.96.2]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id j14Kts4a045803; Fri, 4 Feb 2005 22:55:54 +0200 (EET) (envelope-from ru@ip.net.ua) Received: from tigra.ip.net.ua ([82.193.96.10]) by localhost (rocky.ipnet [82.193.96.2]) (amavisd-new, port 10024) with LMTP id 13365-14; Fri, 4 Feb 2005 22:55:53 +0200 (EET) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id j14Ktrw0045800 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 Feb 2005 22:55:53 +0200 (EET) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.1/8.13.1) id j14KtrGT054207; Fri, 4 Feb 2005 22:55:53 +0200 (EET) (envelope-from ru) Date: Fri, 4 Feb 2005 22:55:52 +0200 From: Ruslan Ermilov To: Ryan Sommers Message-ID: <20050204205552.GE71363@ip.net.ua> References: <42030649.7020806@gamersimpact.com> <20050204115544.H20546@mp2.macomnet.net> <20050204091743.GK51800@cicely12.cicely.de> <42038B63.4060803@gamersimpact.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="XuV1QlJbYrcVoo+x" Content-Disposition: inline In-Reply-To: <42038B63.4060803@gamersimpact.com> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new at ip.net.ua cc: Maxim Konovalov cc: current@FreeBSD.org Subject: Re: [PATCH] /etc/defaults/rc.conf -- Static Routing Explanation X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2005 20:55:56 -0000 --XuV1QlJbYrcVoo+x Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Feb 04, 2005 at 08:49:07AM -0600, Ryan Sommers wrote: > Maxim Konovalov wrote: > > > > There is a good example in rc.conf(5) already. > > >=20 > We have examples in both rc.conf(5) (as shown below) and=20 > defaults/rc.conf then. To keep a form of congruence why not put all the= =20 > examples in one place, either the manpage or the file? >=20 > As someone that's used FreeBSD since 4.0-RELEASE I had to do a less=20 > /etc/rc.d/routing to figure out how to use the tunables. It was my fault= =20 > that I didn't do a man rc.conf, however, never in my using FreeBSD and=20 > rc.conf have I needed to look at this manpage. Nor have I ever seen=20 > there was one. Might I also suggest a reference in defaults/rc.conf to=20 > the manpage? >=20 Too late: src/etc/defaults/rc.conf,v 1.236. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --XuV1QlJbYrcVoo+x Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFCA+FYqRfpzJluFF4RAjMGAJ9tUGwNp9e2Q7Wo3d3vuV3twso9fQCdEBlO /Cw7v2OjQ3KLU9sWqIeR1mo= =GvkK -----END PGP SIGNATURE----- --XuV1QlJbYrcVoo+x-- From owner-freebsd-current@FreeBSD.ORG Fri Feb 4 20:58:20 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 17B0116A4CE; Fri, 4 Feb 2005 20:58:20 +0000 (GMT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 37C2143D4C; Fri, 4 Feb 2005 20:58:19 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from localhost (rocky.ip.net.ua [82.193.96.2]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id j14KwG6V046044; Fri, 4 Feb 2005 22:58:16 +0200 (EET) (envelope-from ru@ip.net.ua) Received: from tigra.ip.net.ua ([82.193.96.10]) by localhost (rocky.ipnet [82.193.96.2]) (amavisd-new, port 10024) with LMTP id 13365-20; Fri, 4 Feb 2005 22:58:16 +0200 (EET) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id j14KwGQe046041 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 Feb 2005 22:58:16 +0200 (EET) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.1/8.13.1) id j14KwFPQ058734; Fri, 4 Feb 2005 22:58:16 +0200 (EET) (envelope-from ru) Date: Fri, 4 Feb 2005 22:58:15 +0200 From: Ruslan Ermilov To: Matteo Riondato , Warner Losh Message-ID: <20050204205815.GF71363@ip.net.ua> References: <1107549847.15645.10.camel@kaiser.sig11.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7mxbaLlpDEyR1+x6" Content-Disposition: inline In-Reply-To: <1107549847.15645.10.camel@kaiser.sig11.org> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new at ip.net.ua cc: current@FreeBSD.org Subject: Re: Little mistake in UPDATING X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2005 20:58:20 -0000 --7mxbaLlpDEyR1+x6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Feb 04, 2005 at 09:44:07PM +0100, Matteo Riondato wrote: > Hi folks! > Line 11 of /usr/src/UPDATING says: > [[ The UPDATING file will be trimmed to 20040814 on or about Oct 1, > 2004 ]] >=20 > I think this is a mistake, it should be >=20 > "Oct 1, 2005"=20 >=20 The plan was to trim it in 2004, but this never actually happened. Perhaps Warner forgot to do it, or plans have changed. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --7mxbaLlpDEyR1+x6 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFCA+HnqRfpzJluFF4RAtsZAJ41RPrX2b389+kEop965Kt229LxlwCZAZy+ XRUL6qEysj6P2NXVP6Bt60Q= =OA0N -----END PGP SIGNATURE----- --7mxbaLlpDEyR1+x6-- From owner-freebsd-current@FreeBSD.ORG Fri Feb 4 21:26:45 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2E44916A4CE; Fri, 4 Feb 2005 21:26:45 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id B1D8843D54; Fri, 4 Feb 2005 21:26:44 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [IPv6:::1]) by harmony.village.org (8.13.1/8.13.1) with ESMTP id j14LO86b046114; Fri, 4 Feb 2005 14:24:08 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Fri, 04 Feb 2005 14:24:08 -0700 (MST) Message-Id: <20050204.142408.41676620.imp@bsdimp.com> To: ru@freebsd.org From: Warner Losh In-Reply-To: <20050204205815.GF71363@ip.net.ua> References: <1107549847.15645.10.camel@kaiser.sig11.org> <20050204205815.GF71363@ip.net.ua> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: rionda@gufi.org cc: current@freebsd.org Subject: Re: Little mistake in UPDATING X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2005 21:26:45 -0000 From: Ruslan Ermilov Subject: Re: Little mistake in UPDATING Date: Fri, 4 Feb 2005 22:58:15 +0200 > On Fri, Feb 04, 2005 at 09:44:07PM +0100, Matteo Riondato wrote: > > Hi folks! > > Line 11 of /usr/src/UPDATING says: > > [[ The UPDATING file will be trimmed to 20040814 on or about Oct 1, > > 2004 ]] > > > > I think this is a mistake, it should be > > > > "Oct 1, 2005" > > > The plan was to trim it in 2004, but this never actually happened. > Perhaps Warner forgot to do it, or plans have changed. Nah, I just forgot to do it, since the branch date for RELENG_5 changed. I've taken care of this in current by trimming to the RELENG_5 branch date. Thanks for noticing. Warner From owner-freebsd-current@FreeBSD.ORG Fri Feb 4 21:40:30 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6F44916A4CE; Fri, 4 Feb 2005 21:40:30 +0000 (GMT) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id D8C5F43D64; Fri, 4 Feb 2005 21:40:29 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.13.1/8.13.1) with ESMTP id j14LeTvh099502; Fri, 4 Feb 2005 16:40:29 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.1/8.13.1) with ESMTP id j14LeeOa037584; Fri, 4 Feb 2005 16:40:40 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 371DC7306E; Fri, 4 Feb 2005 16:40:29 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050204214029.371DC7306E@freebsd-current.sentex.ca> Date: Fri, 4 Feb 2005 16:40:29 -0500 (EST) X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on clamscanner1 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on clamscanner1 X-Virus-Status: Clean X-Virus-Status: Clean Subject: [current tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2005 21:40:30 -0000 TB --- 2005-02-04 20:23:16 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-02-04 20:23:16 - starting CURRENT tinderbox run for sparc64/sparc64 TB --- 2005-02-04 20:23:16 - checking out the source tree TB --- 2005-02-04 20:23:16 - cd /home/tinderbox/CURRENT/sparc64/sparc64 TB --- 2005-02-04 20:23:16 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-02-04 20:28:44 - building world (CFLAGS=-O2 -pipe) TB --- 2005-02-04 20:28:44 - cd /home/tinderbox/CURRENT/sparc64/sparc64/src TB --- 2005-02-04 20:28:44 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything TB --- 2005-02-04 21:34:56 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-02-04 21:34:56 - cd /home/tinderbox/CURRENT/sparc64/sparc64/src TB --- 2005-02-04 21:34:56 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Fri Feb 4 21:34:56 UTC 2005 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/tinderbox/CURRENT/sparc64/sparc64/src/sys -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/altq -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/pf -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcmodel=medlow -msoft-float -ffreestanding -Werror /tinderbox/CURRENT/sparc64/sparc64/src/sys/sparc64/sparc64/iommu.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/tinderbox/CURRENT/sparc64/sparc64/src/sys -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/altq -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/pf -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcmodel=medlow -msoft-float -ffreestanding -Werror /tinderbox/CURRENT/sparc64/sparc64/src/sys/sparc64/sparc64/machdep.c /tinderbox/CURRENT/sparc64/sparc64/src/sys/sparc64/sparc64/machdep.c: In function `utrap_alloc': /tinderbox/CURRENT/sparc64/sparc64/src/sys/sparc64/sparc64/machdep.c:853: error: `M_SUBPROC' undeclared (first use in this function) /tinderbox/CURRENT/sparc64/sparc64/src/sys/sparc64/sparc64/machdep.c:853: error: (Each undeclared identifier is reported only once /tinderbox/CURRENT/sparc64/sparc64/src/sys/sparc64/sparc64/machdep.c:853: error: for each function it appears in.) /tinderbox/CURRENT/sparc64/sparc64/src/sys/sparc64/sparc64/machdep.c: In function `utrap_free': /tinderbox/CURRENT/sparc64/sparc64/src/sys/sparc64/sparc64/machdep.c:870: error: `M_SUBPROC' undeclared (first use in this function) *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/tinderbox/CURRENT/sparc64/sparc64/src/sys/GENERIC. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src. TB --- 2005-02-04 21:40:29 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-02-04 21:40:29 - ERROR: failed to build generic kernel TB --- 2005-02-04 21:40:29 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Fri Feb 4 21:44:00 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2545116A4CE for ; Fri, 4 Feb 2005 21:44:00 +0000 (GMT) Received: from ares.wolfpond.org (ns1.wolfpond.org [62.212.96.219]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1537A43D66 for ; Fri, 4 Feb 2005 21:43:58 +0000 (GMT) (envelope-from ftigeot@wolfpond.org) Received: from aoi.wolfpond.org (aoi.wolfpond.org [IPv6:2001:7a8:24db:1:20c:76ff:feb4:27e1]) by ares.wolfpond.org (8.13.1/8.13.1) with ESMTP id j14LhtDp073257 for ; Fri, 4 Feb 2005 22:43:55 +0100 (CET) (envelope-from ftigeot@aoi.wolfpond.org) Received: from aoi.wolfpond.org (localhost [127.0.0.1]) by aoi.wolfpond.org (8.13.1/8.13.1) with ESMTP id j14Li6AF085353 for ; Fri, 4 Feb 2005 22:44:06 +0100 (CET) (envelope-from ftigeot@aoi.wolfpond.org) Received: (from ftigeot@localhost) by aoi.wolfpond.org (8.13.1/8.13.1/Submit) id j14Li6xZ085342 for current@freebsd.org; Fri, 4 Feb 2005 22:44:06 +0100 (CET) (envelope-from ftigeot) Date: Fri, 4 Feb 2005 22:44:06 +0100 From: Francois Tigeot To: current@freebsd.org Message-ID: <20050204214405.GA54283@aoi.wolfpond.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: Tftp slowness X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2005 21:44:00 -0000 Trying to understand the relative slowness of FreeBSD tftp client and server compared to other implementations, I found this PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=67550 Basically, it adds support for the missing tftp blocksize option. It would be nice if the patch in the PR could be commited; it has been open since june 2004... (just hoping) -- Francois Tigeot From owner-freebsd-current@FreeBSD.ORG Fri Feb 4 22:12:43 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 90B7116A4CE for ; Fri, 4 Feb 2005 22:12:43 +0000 (GMT) Received: from mail28.sea5.speakeasy.net (mail28.sea5.speakeasy.net [69.17.117.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2D0FA43D1F for ; Fri, 4 Feb 2005 22:12:43 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 9329 invoked from network); 4 Feb 2005 22:12:42 -0000 Received: from server.baldwin.cx ([216.27.160.63]) (envelope-sender )AES256-SHA encrypted SMTP for ; 4 Feb 2005 22:12:41 -0000 Received: from [10.50.40.202] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id j14MCGNO065270; Fri, 4 Feb 2005 17:12:37 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: Ian FREISLICH Date: Fri, 4 Feb 2005 16:24:10 -0500 User-Agent: KMail/1.6.2 References: In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200502041624.10668.jhb@FreeBSD.org> X-Spam-Status: No, score=-102.8 required=4.2 tests=ALL_TRUSTED, USER_IN_WHITELIST autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx cc: current@FreeBSD.org Subject: Re: sys/1386/i386/mptable.c rev 1.239 breaks boot. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2005 22:12:43 -0000 On Friday 04 February 2005 04:38 am, Ian FREISLICH wrote: > John Baldwin wrote: > > On Monday 31 January 2005 07:01 am, Ian FREISLICH wrote: > > > Hi > > > > > > I have a dual pII machine that doesn't boot with 1.239 of > > > sys/1386/i386/mptable.c. It boots with this patch backed out. > > > Does anyone have any ideas beyond backing out this patch? > > > > > > revision 1.239 > > > date: 2005/01/18 20:27:24; author: jhb; state: Exp; lines: +7 -1 > > > If a valid ELCR was found, consult it for the trigger mode of ISA > > > interrupts that have a trigger mode of conforming. This fixes problems > > > on some older machines that still route PCI devices via ISA interrupts > > > when using an I/O APIC. > > > > > > This seems to be a case of breaking, rather than fixing older > > > machines. It's highly reproduceable. I mailed the author of this > > > commit over a week ago, but have not had a response yet :(. This > > > is definitely a show-stopper, for me at least. > > > > It did fix other boxes. :( Can you provide a verbose dmesg? > > I've included both a working and broken kernel verbose boot. Ok, short answer is you have a busted MP Table as it is incomplete. You can try disabling USB as a hack for one to test if that fixes your problem. I would be interested in seeing your mptable output. > pcib0: unable to route slot 7 INTD > found-> vendor=0x8086, dev=0x7112, revid=0x01 > bus=0, slot=7, func=2 > class=0c-03-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) > lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=d, irq=11 > map[90]: type 4, range 32, base 00005000, size 4, enabled This is your USB controller and is what has the problem FWIW. Note the message from pcib0 about being unable to route an interrupt. Let me know if just disabling USB is enough to fix the problem for now. If it is we can go from there. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Fri Feb 4 22:45:23 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5564716A4CE for ; Fri, 4 Feb 2005 22:45:23 +0000 (GMT) Received: from sasami.jurai.net (sasami.jurai.net [69.17.104.113]) by mx1.FreeBSD.org (Postfix) with ESMTP id B4CFA43D55 for ; Fri, 4 Feb 2005 22:45:22 +0000 (GMT) (envelope-from mdodd@FreeBSD.ORG) Received: from sasami.jurai.net (winter@sasami.jurai.net [69.17.104.113]) by sasami.jurai.net (8.13.1/8.13.1) with ESMTP id j14MjJ2a008523; Fri, 4 Feb 2005 17:45:21 -0500 (EST) (envelope-from mdodd@FreeBSD.ORG) Date: Fri, 4 Feb 2005 17:45:19 -0500 (EST) From: "Matthew N. Dodd" X-X-Sender: winter@sasami.jurai.net To: Francois Tigeot In-Reply-To: <20050204214405.GA54283@aoi.wolfpond.org> Message-ID: <20050204174008.J78005@sasami.jurai.net> References: <20050204214405.GA54283@aoi.wolfpond.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.5.6 (sasami.jurai.net [69.17.104.113]); Fri, 04 Feb 2005 17:45:22 -0500 (EST) cc: current@FreeBSD.ORG Subject: Re: Tftp slowness X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2005 22:45:23 -0000 On Fri, 4 Feb 2005, Francois Tigeot wrote: > Trying to understand the relative slowness of FreeBSD tftp client and > server compared to other implementations, I found this PR: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=67550 > > Basically, it adds support for the missing tftp blocksize option. > > It would be nice if the patch in the PR could be commited; it has been > open since june 2004... I'll take a look at this as I might have the missing bits that are needed for the client. -- 10 40 80 C0 00 FF FF FF FF C0 00 00 00 00 10 AA AA 03 00 00 00 08 00 From owner-freebsd-current@FreeBSD.ORG Fri Feb 4 23:42:08 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EE07616A4CF for ; Fri, 4 Feb 2005 23:42:08 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id C77EA43D1F for ; Fri, 4 Feb 2005 23:42:08 +0000 (GMT) (envelope-from davidxu@freebsd.org) Received: from [127.0.0.1] (davidxu@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.1/8.13.1) with ESMTP id j14Ng7lL044958 for ; Fri, 4 Feb 2005 23:42:08 GMT (envelope-from davidxu@freebsd.org) Message-ID: <4204084A.9070006@freebsd.org> Date: Sat, 05 Feb 2005 07:42:02 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20041226 X-Accept-Language: en-us, en MIME-Version: 1.0 To: current@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: any chance to make Nforce 3 work better X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2005 23:42:09 -0000 I got a Nforce3 ultra board, EPOX EP9NDA3, I can only boot it with acpi turned off in kernel, otherwise, kernel prints: calcru: runtime went backwards from 425709 usec to 39765 usec for pid 11 (idle) then system is dead. is there any chance to make it work better ? although I know Nforce is suckage. David Xu From owner-freebsd-current@FreeBSD.ORG Sat Feb 5 00:05:02 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7CCAD16A4CE; Sat, 5 Feb 2005 00:05:02 +0000 (GMT) Received: from ran.psg.com (ip192.186.dsl-acs2.seawa0.iinet.com [209.20.186.192]) by mx1.FreeBSD.org (Postfix) with ESMTP id 134C943D4C; Sat, 5 Feb 2005 00:05:00 +0000 (GMT) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=ran.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CxDRZ-000N3F-24; Fri, 04 Feb 2005 16:04:57 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16900.3496.453074.606495@ran.psg.com> Date: Fri, 4 Feb 2005 16:04:56 -0800 To: =?ISO-8859-1?Q?S=F8ren_Schmidt?= References: <42028F29.1030801@DeepCore.dk> cc: 'FreeBSD Current' cc: "freebsd-stable@freebsd.org" Subject: Re: ATA mkIII first official patches - please test! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Feb 2005 00:05:02 -0000 makes my tp41 running current boot without crashing. i demand a refund! :-) randy From owner-freebsd-current@FreeBSD.ORG Sat Feb 5 00:06:56 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E012716A4CE; Sat, 5 Feb 2005 00:06:56 +0000 (GMT) Received: from anuket.mj.niksun.com (gwnew.niksun.com [65.115.46.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2AC7643D41; Sat, 5 Feb 2005 00:06:54 +0000 (GMT) (envelope-from jkim@niksun.com) Received: from [10.70.0.244] (daemon.mj.niksun.com [10.70.0.244]) by anuket.mj.niksun.com (8.13.1/8.12.11) with ESMTP id j1506rQ4054184; Fri, 4 Feb 2005 19:06:53 -0500 (EST) (envelope-from jkim@niksun.com) From: Jung-uk Kim Organization: Niksun, Inc. To: freebsd-current@freebsd.org Date: Fri, 4 Feb 2005 19:06:48 -0500 User-Agent: KMail/1.6.2 References: <4204084A.9070006@freebsd.org> In-Reply-To: <4204084A.9070006@freebsd.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200502041906.49069.jkim@niksun.com> X-Virus-Scanned: clamd / ClamAV version 0.75.1, clamav-milter version 0.75c on anuket.mj.niksun.com X-Virus-Status: Clean cc: David Xu cc: current@freebsd.org Subject: Re: any chance to make Nforce 3 work better X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Feb 2005 00:06:57 -0000 On Friday 04 February 2005 06:42 pm, David Xu wrote: > I got a Nforce3 ultra board, EPOX EP9NDA3, I can only > boot it with acpi turned off in kernel, otherwise, kernel > prints: > calcru: runtime went backwards from 425709 usec to 39765 > usec for pid 11 (idle) > then system is dead. > is there any chance to make it work better ? although I > know Nforce is suckage. Try the following patches: http://docs.freebsd.org/cgi/mid.cgi?200501192214.27401.jkim http://docs.freebsd.org/cgi/mid.cgi?200501261149.11530.jkim jhb is working on this issue: http://docs.freebsd.org/cgi/mid.cgi?200501311738.04377.jhb Jung-uk Kim From owner-freebsd-current@FreeBSD.ORG Sat Feb 5 00:06:56 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E012716A4CE; Sat, 5 Feb 2005 00:06:56 +0000 (GMT) Received: from anuket.mj.niksun.com (gwnew.niksun.com [65.115.46.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2AC7643D41; Sat, 5 Feb 2005 00:06:54 +0000 (GMT) (envelope-from jkim@niksun.com) Received: from [10.70.0.244] (daemon.mj.niksun.com [10.70.0.244]) by anuket.mj.niksun.com (8.13.1/8.12.11) with ESMTP id j1506rQ4054184; Fri, 4 Feb 2005 19:06:53 -0500 (EST) (envelope-from jkim@niksun.com) From: Jung-uk Kim Organization: Niksun, Inc. To: freebsd-current@freebsd.org Date: Fri, 4 Feb 2005 19:06:48 -0500 User-Agent: KMail/1.6.2 References: <4204084A.9070006@freebsd.org> In-Reply-To: <4204084A.9070006@freebsd.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200502041906.49069.jkim@niksun.com> X-Virus-Scanned: clamd / ClamAV version 0.75.1, clamav-milter version 0.75c on anuket.mj.niksun.com X-Virus-Status: Clean cc: David Xu cc: current@freebsd.org Subject: Re: any chance to make Nforce 3 work better X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Feb 2005 00:06:57 -0000 On Friday 04 February 2005 06:42 pm, David Xu wrote: > I got a Nforce3 ultra board, EPOX EP9NDA3, I can only > boot it with acpi turned off in kernel, otherwise, kernel > prints: > calcru: runtime went backwards from 425709 usec to 39765 > usec for pid 11 (idle) > then system is dead. > is there any chance to make it work better ? although I > know Nforce is suckage. Try the following patches: http://docs.freebsd.org/cgi/mid.cgi?200501192214.27401.jkim http://docs.freebsd.org/cgi/mid.cgi?200501261149.11530.jkim jhb is working on this issue: http://docs.freebsd.org/cgi/mid.cgi?200501311738.04377.jhb Jung-uk Kim From owner-freebsd-current@FreeBSD.ORG Sat Feb 5 00:15:13 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 15BAE16A4CE; Sat, 5 Feb 2005 00:15:13 +0000 (GMT) Received: from postal2.es.net (postal2.es.net [198.128.3.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id BAE8B43D2D; Sat, 5 Feb 2005 00:15:12 +0000 (GMT) (envelope-from oberman@es.net) Received: from ptavv.es.net ([198.128.4.29]) by postal2.es.net (Postal Node 2) with ESMTP (SSL) id IBA74465; Fri, 04 Feb 2005 16:15:12 -0800 Received: from ptavv (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id CE6215D07; Fri, 4 Feb 2005 16:15:11 -0800 (PST) To: Randy Bush In-reply-to: Your message of "Fri, 04 Feb 2005 16:04:56 PST." <16900.3496.453074.606495@ran.psg.com> Date: Fri, 04 Feb 2005 16:15:11 -0800 From: "Kevin Oberman" Message-Id: <20050205001511.CE6215D07@ptavv.es.net> cc: 'FreeBSD Current' cc: "freebsd-stable@freebsd.org" cc: =?ISO-8859-1?Q?S=F8ren_Schmidt?= Subject: Re: ATA mkIII first official patches - please test! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Feb 2005 00:15:13 -0000 > From: Randy Bush > Date: Fri, 4 Feb 2005 16:04:56 -0800 > Sender: owner-freebsd-stable@freebsd.org > > makes my tp41 running current boot without crashing. i > demand a refund! :-) Randy, We have refunded your money so often that we're running out of empty pockets to get the funds from. :-) Seriously, my T30 seems happier, too, although time will tell since it was not nearly as unhappy as yours was. (It only barked and locked up occasionally and never crashed on boot.) -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 From owner-freebsd-current@FreeBSD.ORG Sat Feb 5 00:21:47 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5467416A4CE for ; Sat, 5 Feb 2005 00:21:47 +0000 (GMT) Received: from out009.verizon.net (out009pub.verizon.net [206.46.170.131]) by mx1.FreeBSD.org (Postfix) with ESMTP id A9EB243D31 for ; Sat, 5 Feb 2005 00:21:46 +0000 (GMT) (envelope-from Alex.Kovalenko@verizon.net) Received: from RabbitsDen ([70.21.161.195]) by out009.verizon.net (InterMail vM.5.01.06.06 201-253-122-130-106-20030910) with ESMTP id <20050205002146.PYOI4172.out009.verizon.net@RabbitsDen>; Fri, 4 Feb 2005 18:21:46 -0600 From: "Alexandre \"Sunny\" Kovalenko" To: Ryan Sommers In-Reply-To: <52857.208.4.77.203.1107541629.squirrel@208.4.77.203> References: <63285.65.27.85.163.1107049410.squirrel@65.27.85.163> <41FC561C.3080505@errno.com> <41FEF40A.70006@gamersimpact.com> <1107387525.979.7.camel@RabbitsDen> <0502042321154.16397@www.mmlab.cse.yzu.edu.tw> <64317.208.4.77.203.1107533389.squirrel@208.4.77.203> <4203AC57.5000708@errno.com> <52857.208.4.77.203.1107541629.squirrel@208.4.77.203> Content-Type: text/plain; charset=iso-8859-5 Date: Fri, 04 Feb 2005 19:20:27 -0500 Message-Id: <1107562827.1170.7.camel@RabbitsDen> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 8bit X-Authentication-Info: Submitted using SMTP AUTH at out009.verizon.net from [70.21.161.195] at Fri, 4 Feb 2005 18:21:45 -0600 cc: Sam Leffler cc: current@freebsd.org Subject: Re: WEP Encryption Changes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Feb 2005 00:21:47 -0000 On Fri, 2005-02-04 at 11:27 -0700, Ryan Sommers wrote: > What is odd is the ifconfig options using 'deftxkey' looks the same as > using 'weptxkey'. However, from my attempts to use deftxkey it doesn't > have the same underlying effect on the encrption. I tried a few times to > use this option to set my Tx key but it never seemed to work. Then when I > tried using weptxkey it worked the first time. Now, that isn't to say they > don't have the same outcome. My wireless card seems to have a few quirks > that pop up every now and then, especially if you do a lot of settings > changing, and deftxkey not working might have been one of those times. FWIW -- at the time I have encountered this (mid-to-late December?), I have played with Prism 2 cards (wi), 2 different Broadcom cards (ndis) and one Atheros 5212 (ath). For all four of them adding 'weptxkey 1' to ifconfig got me connected and adding 'deftxkey 1' did not. I do not have most of these cards any more, but with my Prism 2 card(wi) and yesterday's -current I get connected whether I use weptxkey or deftxkey. -- Alexandre "Sunny" Kovalenko (¾ÛÕÚáÐÝÔà ºÞÒÐÛÕÝÚÞ) From owner-freebsd-current@FreeBSD.ORG Sat Feb 5 00:36:43 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1994316A4F5 for ; Sat, 5 Feb 2005 00:36:43 +0000 (GMT) Received: from ran.psg.com (ip192.186.dsl-acs2.seawa0.iinet.com [209.20.186.192]) by mx1.FreeBSD.org (Postfix) with ESMTP id D0AB143D1D for ; Sat, 5 Feb 2005 00:36:42 +0000 (GMT) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=ran.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CxDwI-000O8E-70; Fri, 04 Feb 2005 16:36:42 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16900.5401.603876.256329@ran.psg.com> Date: Fri, 4 Feb 2005 16:36:41 -0800 To: "Kevin Oberman" References: <16900.3496.453074.606495@ran.psg.com> <20050205001511.CE6215D07@ptavv.es.net> cc: 'FreeBSD Current' cc: =?ISO-8859-1?Q?S=F8ren_Schmidt?= Subject: Re: ATA mkIII first official patches - please test! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Feb 2005 00:36:43 -0000 [ stable removed, as i am not ] > Seriously, my T30 seems happier, too, although time will tell > since it was not nearly as unhappy as yours was. so far o no crash on boot o boots without those looooong pauses (well, still long pause while it farbles usb) o built kernel and world using new kernel so i am doing some buildworlds, a portupgrde (gotta love when perl cranks a version), and some makes to see how it stands up randy From owner-freebsd-current@FreeBSD.ORG Sat Feb 5 00:43:15 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7182016A4CE for ; Sat, 5 Feb 2005 00:43:15 +0000 (GMT) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0F51643D3F for ; Sat, 5 Feb 2005 00:43:15 +0000 (GMT) (envelope-from sam@errno.com) Received: from [66.127.85.91] (sam@[66.127.85.91]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.6) with ESMTP id j150hDWi076799 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 Feb 2005 16:43:14 -0800 (PST) (envelope-from sam@errno.com) Message-ID: <420416C6.1030803@errno.com> Date: Fri, 04 Feb 2005 16:43:50 -0800 From: Sam Leffler User-Agent: Mozilla Thunderbird 1.0RC1 (X11/20041208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Alexandre \"Sunny\" Kovalenko" References: <63285.65.27.85.163.1107049410.squirrel@65.27.85.163> <41FC561C.3080505@errno.com> <41FEF40A.70006@gamersimpact.com> <1107387525.979.7.camel@RabbitsDen> <0502042321154.16397@www.mmlab.cse.yzu.edu.tw> <64317.208.4.77.203.1107533389.squirrel@208.4.77.203> <4203AC57.5000708@errno.com> <52857.208.4.77.203.1107541629.squirrel@208.4.77.203> <1107562827.1170.7.camel@RabbitsDen> In-Reply-To: <1107562827.1170.7.camel@RabbitsDen> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: Ryan Sommers cc: current@freebsd.org Subject: Re: WEP Encryption Changes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Feb 2005 00:43:15 -0000 Alexandre "Sunny" Kovalenko wrote: > On Fri, 2005-02-04 at 11:27 -0700, Ryan Sommers wrote: > > >>What is odd is the ifconfig options using 'deftxkey' looks the same as >>using 'weptxkey'. However, from my attempts to use deftxkey it doesn't >>have the same underlying effect on the encrption. I tried a few times to >>use this option to set my Tx key but it never seemed to work. Then when I >>tried using weptxkey it worked the first time. Now, that isn't to say they >>don't have the same outcome. My wireless card seems to have a few quirks >>that pop up every now and then, especially if you do a lot of settings >>changing, and deftxkey not working might have been one of those times. > > > FWIW -- at the time I have encountered this (mid-to-late December?), I > have played with Prism 2 cards (wi), 2 different Broadcom cards (ndis) > and one Atheros 5212 (ath). For all four of them adding 'weptxkey 1' to > ifconfig got me connected and adding 'deftxkey 1' did not. > > I do not have most of these cards any more, but with my Prism 2 card(wi) > and yesterday's -current I get connected whether I use weptxkey or > deftxkey. > From sbin/ifconfig/ifieee80211.c: DEF_CMD_ARG("deftxkey", set80211weptxkey), DEF_CMD_ARG("weptxkey", set80211weptxkey), i.e. deftxkey and weptxkey execute identical code. Sam From owner-freebsd-current@FreeBSD.ORG Sat Feb 5 01:28:01 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F2A2F16A4CE for ; Sat, 5 Feb 2005 01:28:00 +0000 (GMT) Received: from mail.chesapeake.net (chesapeake.net [208.142.252.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 61F9343D39 for ; Sat, 5 Feb 2005 01:28:00 +0000 (GMT) (envelope-from jroberson@chesapeake.net) Received: from mail.chesapeake.net (localhost [127.0.0.1]) by mail.chesapeake.net (8.12.10/8.12.10) with ESMTP id j151Rxc5010563 for ; Fri, 4 Feb 2005 20:27:59 -0500 (EST) (envelope-from jroberson@chesapeake.net) Received: from localhost (jroberson@localhost)j151RwXT010554 for ; Fri, 4 Feb 2005 20:27:59 -0500 (EST) (envelope-from jroberson@chesapeake.net) X-Authentication-Warning: mail.chesapeake.net: jroberson owned process doing -bs Date: Fri, 4 Feb 2005 20:27:58 -0500 (EST) From: Jeff Roberson To: current@freebsd.org Message-ID: <20050204202725.G18864@mail.chesapeake.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: VFS panics (cvs commit: src/sys/kern vfs_bio.c) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Feb 2005 01:28:01 -0000 This should fix the buf_vlist_remove panic and may fix the dangling deps panic. ---------- Forwarded message ---------- Date: Sat, 5 Feb 2005 01:26:14 +0000 (UTC) From: Jeff Roberson To: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org Subject: cvs commit: src/sys/kern vfs_bio.c jeff 2005-02-05 01:26:14 UTC FreeBSD src repository Modified files: sys/kern vfs_bio.c Log: - Don't release BKGRDINPROG until after we've bufdone'd the copy. Sponsored by: Isilon Systems, Inc. Revision Changes Path 1.476 +15 -14 src/sys/kern/vfs_bio.c From owner-freebsd-current@FreeBSD.ORG Sat Feb 5 01:55:42 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3C1E116A4CE for ; Sat, 5 Feb 2005 01:55:42 +0000 (GMT) Received: from out004.verizon.net (out004pub.verizon.net [206.46.170.142]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9CD9543D39 for ; Sat, 5 Feb 2005 01:55:41 +0000 (GMT) (envelope-from Alex.Kovalenko@verizon.net) Received: from RabbitsDen ([70.21.161.195]) by out004.verizon.net (InterMail vM.5.01.06.06 201-253-122-130-106-20030910) with ESMTP id <20050205015540.JVLJ15146.out004.verizon.net@RabbitsDen>; Fri, 4 Feb 2005 19:55:40 -0600 From: "Alexandre \"Sunny\" Kovalenko" To: Sam Leffler In-Reply-To: <420416C6.1030803@errno.com> References: <63285.65.27.85.163.1107049410.squirrel@65.27.85.163> <41FC561C.3080505@errno.com> <41FEF40A.70006@gamersimpact.com> <1107387525.979.7.camel@RabbitsDen> <0502042321154.16397@www.mmlab.cse.yzu.edu.tw> <64317.208.4.77.203.1107533389.squirrel@208.4.77.203> <4203AC57.5000708@errno.com> <52857.208.4.77.203.1107541629.squirrel@208.4.77.203> <1107562827.1170.7.camel@RabbitsDen> <420416C6.1030803@errno.com> Content-Type: text/plain; charset=iso-8859-5 Date: Fri, 04 Feb 2005 20:54:22 -0500 Message-Id: <1107568462.963.4.camel@RabbitsDen> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 8bit X-Authentication-Info: Submitted using SMTP AUTH at out004.verizon.net from [70.21.161.195] at Fri, 4 Feb 2005 19:55:40 -0600 cc: current@freebsd.org Subject: Re: WEP Encryption Changes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Feb 2005 01:55:42 -0000 On Fri, 2005-02-04 at 16:43 -0800, Sam Leffler wrote: > Alexandre "Sunny" Kovalenko wrote: > > On Fri, 2005-02-04 at 11:27 -0700, Ryan Sommers wrote: > > > > > >>What is odd is the ifconfig options using 'deftxkey' looks the same as > >>using 'weptxkey'. However, from my attempts to use deftxkey it doesn't > >>have the same underlying effect on the encrption. I tried a few times to > >>use this option to set my Tx key but it never seemed to work. Then when I > >>tried using weptxkey it worked the first time. Now, that isn't to say they > >>don't have the same outcome. My wireless card seems to have a few quirks > >>that pop up every now and then, especially if you do a lot of settings > >>changing, and deftxkey not working might have been one of those times. > > > > > > FWIW -- at the time I have encountered this (mid-to-late December?), I > > have played with Prism 2 cards (wi), 2 different Broadcom cards (ndis) > > and one Atheros 5212 (ath). For all four of them adding 'weptxkey 1' to > > ifconfig got me connected and adding 'deftxkey 1' did not. > > > > I do not have most of these cards any more, but with my Prism 2 card(wi) > > and yesterday's -current I get connected whether I use weptxkey or > > deftxkey. > > > > From sbin/ifconfig/ifieee80211.c: > > DEF_CMD_ARG("deftxkey", set80211weptxkey), > DEF_CMD_ARG("weptxkey", set80211weptxkey), > > i.e. deftxkey and weptxkey execute identical code. > > Sam > Thank you very much for clarification. Was not the case back in December though: Revision 1.14 / (download) - annotate - [select for diffs], Fri Dec 31 19:39:25 2004 UTC (5 weeks ago) by sam Branch: MAIN Changes since 1.13: +11 -1 lines Diff to previous 1.13 (colored) o accept deftxkey as a synonym for weptxkey since that is what is printed for status (allows cut&paste) o accept undef for the deftxkey/weptxkey so you can reset state Requested by:phk -- Alexandre "Sunny" Kovalenko (¾ÛÕÚáÐÝÔà ºÞÒÐÛÕÝÚÞ) From owner-freebsd-current@FreeBSD.ORG Sat Feb 5 02:19:08 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4DA8916A4CE for ; Sat, 5 Feb 2005 02:19:08 +0000 (GMT) Received: from obsecurity.dyndns.org (CPE0050040655c8-CM00111ae02aac.cpe.net.cable.rogers.com [69.199.47.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1389C43D48 for ; Sat, 5 Feb 2005 02:19:08 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 40B42512C9; Fri, 4 Feb 2005 18:19:03 -0800 (PST) Date: Fri, 4 Feb 2005 18:19:03 -0800 From: Kris Kennaway To: Jeff Roberson Message-ID: <20050205021903.GA75708@xor.obsecurity.org> References: <20050204202725.G18864@mail.chesapeake.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="CE+1k2dSO48ffgeK" Content-Disposition: inline In-Reply-To: <20050204202725.G18864@mail.chesapeake.net> User-Agent: Mutt/1.4.2.1i cc: current@freebsd.org Subject: Re: VFS panics (cvs commit: src/sys/kern vfs_bio.c) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Feb 2005 02:19:08 -0000 --CE+1k2dSO48ffgeK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Feb 04, 2005 at 08:27:58PM -0500, Jeff Roberson wrote: > This should fix the buf_vlist_remove panic and may fix the dangling deps > panic. I started 2 fsx processes and they immediately deadlocked: db> wh 645 Tracing pid 645 tid 100195 td 0xc5aea730 sched_switch(c5aea730,0,1,c06fd89e,c5aea730) at sched_switch+0x2fe mi_switch(1,0,c070029f,1ab,c051d45b) at mi_switch+0x41e sleepq_switch(c5dc1334,0,c5aea730,600,f11cead0) at sleepq_switch+0x135 sleepq_wait(c5dc1334,0,c06fd720,da,c5aea730) at sleepq_wait+0x42 msleep(c5dc1334,c0769c24,50,c0704446,0) at msleep+0x420 acquire(f11ceb58,1010040,600,ee,c5dc1334) at acquire+0xf3 debuglockmgr(c5dc1334,1030002,c5dc1270,c5aea730,c0705c42,c0706a4e,c00) at debuglockmgr+0x49f ufs_lock(f11cebcc,c0706b7d,333,c0711ed1,c07064e3) at ufs_lock+0x66 VOP_LOCK_AP(f11cebcc,0,c0706b7d,333,c5dc1270) at VOP_LOCK_AP+0x78 debug_vn_lock(c5dc1270,20002,c5aea730,c0706a4e,c00) at debug_vn_lock+0x110 ftruncate(c5aea730,f11ced14,3a6,c0719253,c5aea730) at ftruncate+0x150 syscall(2f,2f,2f,bfbfe478,40000) at syscall+0x2c4 Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (198, FreeBSD ELF32, nosys), eip = 0x280c6e43, esp = 0xbfbfe37c, ebp = 0xbfbfe3a8 --- db> wh 644 Tracing pid 644 tid 100213 td 0xc5af1450 sched_switch(c5af1450,0,1,c06fd89e,c5af1450) at sched_switch+0x2fe mi_switch(1,0,c070029f,1ab,c051d45b) at mi_switch+0x41e sleepq_switch(c4640d28,0,c5af1450,0,f12287bc) at sleepq_switch+0x135 sleepq_wait(c4640d28,0,c06fd720,da,c5af1450) at sleepq_wait+0x42 msleep(c4640d28,c07c5da0,244,c0712c27,0) at msleep+0x420 vm_page_sleep_if_busy(c4640d28,1,c0712c27,6e4,c465fc70) at vm_page_sleep_if_busy+0xc6 vm_object_page_remove(c5db5738,2c,0,32,0) at vm_object_page_remove+0x12d vnode_pager_setsize(c5dc1270,2c000,0,c0579dee,de724dcc) at vnode_pager_setsize+0xec ffs_write(f1228940,c06fc0a5,12b,c0711ed1,c0712dca) at ffs_write+0x2f1 VOP_WRITE_AP(f1228940,0,c0713894,469,86b) at VOP_WRITE_AP+0x78 vnode_pager_generic_putpages(c5dc1270,f1228ab0,8000,5,f1228a50) at vnode_pager_generic_putpages+0x215 vop_stdputpages(f12289fc,39d,12b,c0711ed1,c071158e) at vop_stdputpages+0x30 VOP_PUTPAGES_AP(f12289fc,f12289f8,1,419,c585e000) at VOP_PUTPAGES_AP+0x84 vnode_pager_putpages(c5db5738,f1228ab0,8,5,f1228a50) at vnode_pager_putpages+0xb0 vm_pageout_flush(f1228ab0,8,5,364,c0769c24) at vm_pageout_flush+0x16d vm_object_page_collect_flush(c5db5738,c46b2f98,586,5,10) at vm_object_page_collect_flush+0x2fc vm_object_page_clean(c5db5738,2a,0,32,0) at vm_object_page_clean+0x1b4 vm_object_sync(c5db5738,2a000,0,8000,1) at vm_object_sync+0x1ff vm_map_sync(c5dbd834,2815b000,28163000,1,0) at vm_map_sync+0x29b msync(c5af1450,f1228d14,3a6,c0719253,c5af1450) at msync+0x7f syscall(2f,2f,2f,75b6,2a2b5) at syscall+0x2c4 Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (65, FreeBSD ELF32, msync), eip = 0x280c76a3, esp = 0xbfbfe38c, ebp = 0xbfbfe3e8 --- db> Kris --CE+1k2dSO48ffgeK Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCBC0WWry0BWjoQKURAsLnAJ9wKHhTjowH4gWNzeLYcUsUaIlI4ACgyZyg pI9XdrXpDbq95YIRXYty2G0= =mxfp -----END PGP SIGNATURE----- --CE+1k2dSO48ffgeK-- From owner-freebsd-current@FreeBSD.ORG Sat Feb 5 02:24:22 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 15D8516A4CE; Sat, 5 Feb 2005 02:24:22 +0000 (GMT) Received: from out002.verizon.net (out002pub.verizon.net [206.46.170.141]) by mx1.FreeBSD.org (Postfix) with ESMTP id 691BD43D49; Sat, 5 Feb 2005 02:24:21 +0000 (GMT) (envelope-from Alex.Kovalenko@verizon.net) Received: from RabbitsDen ([70.21.161.195]) by out002.verizon.net (InterMail vM.5.01.06.06 201-253-122-130-106-20030910) with ESMTP id <20050205022420.QPOU26937.out002.verizon.net@RabbitsDen>; Fri, 4 Feb 2005 20:24:20 -0600 From: "Alexandre \"Sunny\" Kovalenko" To: =?ISO-8859-1?Q?S=F8ren?= Schmidt In-Reply-To: <42028F29.1030801@DeepCore.dk> References: <42028F29.1030801@DeepCore.dk> Content-Type: multipart/mixed; boundary="=-I7tfFkhafq8rB0O5xyfS" Date: Fri, 04 Feb 2005 21:23:01 -0500 Message-Id: <1107570181.963.11.camel@RabbitsDen> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 FreeBSD GNOME Team Port X-Authentication-Info: Submitted using SMTP AUTH at out002.verizon.net from [70.21.161.195] at Fri, 4 Feb 2005 20:24:19 -0600 X-Content-Filtered-By: Mailman/MimeDel 2.1.1 cc: 'FreeBSD Current' cc: "freebsd-stable@freebsd.org" Subject: Re: ATA mkIII first official patches - please test! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Feb 2005 02:24:22 -0000 --=-I7tfFkhafq8rB0O5xyfS Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On Thu, 2005-02-03 at 21:52 +0100, Søren Schmidt wrote: > ATA-mkIII first official snapshot. > > This is the much rumoured ATA update that I've been working on for some time. > > It contains a number of new things, and lacks a few features of the old code. > > New items include: > > o ATA is now fully newbus'd and split into modules. > This means that on a modern system you just load "atapci and ata" > to get the base support, and then one or more of the device > subdrivers "atadisk atapicd atapifd atapist ataraid". > All can be loaded/unloaded anytime, but for obvious reasons you > dont want to unload atadisk when you have mounted filesystems. > > o The device identify part of the probe has been rewritten to fix > the problems with odd devices the old had, and to try to remove > so of the long delays some HW could provoke. > > o SATA devices can be hot inserted/removed and devices will be created/ > removed in /dev accordingly. NOTE only supported on controllers that > has this feature: Promise and Silicon Image for now. > > o ATA RAID support has been rewritten and and now supports these > metadata formats: > "Adaptec HostRAID" > "Highpoint V2 RocketRAID" > "Highpoint V3 RocketRAID" > "Intel MatrixRAID" > "Integrated Technology Express" > "LSILogic V2 MegaRAID" > "LSILogic V3 MegaRAID" > "Promise FastTrak" > "Silicon Image Medley" > > o The reinit code has been worked over to be much more robust. > > o The timeout code has been overhauled for races. > > o Lots of fixes for bugs found while doing the modulerization and > reviewing the old code. > > > Missing features form current ATA: > > o atapi-cd no longer has support for ATAPI changers. Todays its > much cheaper and alot faster to copy those CD images to disk > and serve them from there. Besides they dont seem to be made > anymore, maybe for that exact reason. > > o ATA RAID can only read metadata not write them. This means that > arrays can be picked up from the BIOS, but they cannot be created > from FreeBSD. This is being worked on for the final release as is > RAID5 support for Promise/Highpoing/SiI controllers. > > o The atapi-cam author has been informed and has had early access > to this work but so far atapicam is not supported with these > changes. However I do have my own atacam that puts both ATA and ATAPI > devices under CAM, but its really just academic at this point. > > And then there all the things that I've happily forgotten about :) > > The snapshot is available as a patch for RELENG_5 and for CURRENT, and > a common tarfile of the new ATA code. > > http://people.freebsd.org/~sos/ata-mk3j.diff-releng5.gz > http://people.freebsd.org/~sos/ata-mk3j.diff-current.gz > http://people.freebsd.org/~sos/ata-mk3j.tar.gz > > Both patches and the tarfile is relative to /usr/src. > You might want to remove the contents of sys/dev/ata/ before unpacking > the tarfile. > > No changes are needed to your config file, unless you want ATA as modules. > > As usual, even if it works on all the HW I have here in the lab, thats by > far not the same as it works on YOUR system. So use glowes and safety shoes > and if it breaks I dont want the pieces, but would like to hear the nifty > details on how exactly it got that way :) > > Enjoy! > Works beautifully here (AVERATEC 3150H with VIA 8235). Timeouts on non-existing slaves are gone for good. Patch for -current (as of yesterday) failed to compile afterward (log attached), but removing sys/dev/ata/* and untaring archive worked just fine. -- Alexandre "Sunny" Kovalenko (ОлекÑандр Коваленко) --=-I7tfFkhafq8rB0O5xyfS-- From owner-freebsd-current@FreeBSD.ORG Sat Feb 5 02:40:17 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 19E4E16A4CE for ; Sat, 5 Feb 2005 02:40:17 +0000 (GMT) Received: from obsecurity.dyndns.org (CPE0050040655c8-CM00111ae02aac.cpe.net.cable.rogers.com [69.199.47.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 83DFF43D1F for ; Sat, 5 Feb 2005 02:40:16 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 8E5E7512C9; Fri, 4 Feb 2005 18:40:15 -0800 (PST) Date: Fri, 4 Feb 2005 18:40:15 -0800 From: Kris Kennaway To: Kris Kennaway Message-ID: <20050205024015.GA75881@xor.obsecurity.org> References: <20050204202725.G18864@mail.chesapeake.net> <20050205021903.GA75708@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gBBFr7Ir9EOA20Yy" Content-Disposition: inline In-Reply-To: <20050205021903.GA75708@xor.obsecurity.org> User-Agent: Mutt/1.4.2.1i cc: Jeff Roberson cc: current@freebsd.org Subject: Re: VFS panics (cvs commit: src/sys/kern vfs_bio.c) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Feb 2005 02:40:17 -0000 --gBBFr7Ir9EOA20Yy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Feb 04, 2005 at 06:19:03PM -0800, Kris Kennaway wrote: > On Fri, Feb 04, 2005 at 08:27:58PM -0500, Jeff Roberson wrote: > > This should fix the buf_vlist_remove panic and may fix the dangling deps > > panic. >=20 > I started 2 fsx processes and they immediately deadlocked: I think this was running both fsx instances with the same target file. (null) 0xc5dc1270: tag ufs, type VREG usecount 3, writecount 2, refcount 0 mountedhere 0 flags () v_object 0xc5db5738 lock type ufs: EXCL (count 1) by thread 0xc5af1450 (pid 644) with 1 pe= nding ino 2166788, on dev da0s1e (235, 8) Looks like process 644 went to sleep holding a lock. Kris > db> wh 645 > Tracing pid 645 tid 100195 td 0xc5aea730 > sched_switch(c5aea730,0,1,c06fd89e,c5aea730) at sched_switch+0x2fe > mi_switch(1,0,c070029f,1ab,c051d45b) at mi_switch+0x41e > sleepq_switch(c5dc1334,0,c5aea730,600,f11cead0) at sleepq_switch+0x135 > sleepq_wait(c5dc1334,0,c06fd720,da,c5aea730) at sleepq_wait+0x42 > msleep(c5dc1334,c0769c24,50,c0704446,0) at msleep+0x420 > acquire(f11ceb58,1010040,600,ee,c5dc1334) at acquire+0xf3 > debuglockmgr(c5dc1334,1030002,c5dc1270,c5aea730,c0705c42,c0706a4e,c00) at= debuglockmgr+0x49f > ufs_lock(f11cebcc,c0706b7d,333,c0711ed1,c07064e3) at ufs_lock+0x66 > VOP_LOCK_AP(f11cebcc,0,c0706b7d,333,c5dc1270) at VOP_LOCK_AP+0x78 > debug_vn_lock(c5dc1270,20002,c5aea730,c0706a4e,c00) at debug_vn_lock+0x110 > ftruncate(c5aea730,f11ced14,3a6,c0719253,c5aea730) at ftruncate+0x150 > syscall(2f,2f,2f,bfbfe478,40000) at syscall+0x2c4 > Xint0x80_syscall() at Xint0x80_syscall+0x1f > --- syscall (198, FreeBSD ELF32, nosys), eip =3D 0x280c6e43, esp =3D 0xbf= bfe37c, ebp =3D 0xbfbfe3a8 --- > db> wh 644 > Tracing pid 644 tid 100213 td 0xc5af1450 > sched_switch(c5af1450,0,1,c06fd89e,c5af1450) at sched_switch+0x2fe > mi_switch(1,0,c070029f,1ab,c051d45b) at mi_switch+0x41e > sleepq_switch(c4640d28,0,c5af1450,0,f12287bc) at sleepq_switch+0x135 > sleepq_wait(c4640d28,0,c06fd720,da,c5af1450) at sleepq_wait+0x42 > msleep(c4640d28,c07c5da0,244,c0712c27,0) at msleep+0x420 > vm_page_sleep_if_busy(c4640d28,1,c0712c27,6e4,c465fc70) at vm_page_sleep_= if_busy+0xc6 > vm_object_page_remove(c5db5738,2c,0,32,0) at vm_object_page_remove+0x12d > vnode_pager_setsize(c5dc1270,2c000,0,c0579dee,de724dcc) at vnode_pager_se= tsize+0xec > ffs_write(f1228940,c06fc0a5,12b,c0711ed1,c0712dca) at ffs_write+0x2f1 > VOP_WRITE_AP(f1228940,0,c0713894,469,86b) at VOP_WRITE_AP+0x78 > vnode_pager_generic_putpages(c5dc1270,f1228ab0,8000,5,f1228a50) at vnode_= pager_generic_putpages+0x215 > vop_stdputpages(f12289fc,39d,12b,c0711ed1,c071158e) at vop_stdputpages+0x= 30 > VOP_PUTPAGES_AP(f12289fc,f12289f8,1,419,c585e000) at VOP_PUTPAGES_AP+0x84 > vnode_pager_putpages(c5db5738,f1228ab0,8,5,f1228a50) at vnode_pager_putpa= ges+0xb0 > vm_pageout_flush(f1228ab0,8,5,364,c0769c24) at vm_pageout_flush+0x16d > vm_object_page_collect_flush(c5db5738,c46b2f98,586,5,10) at vm_object_pag= e_collect_flush+0x2fc > vm_object_page_clean(c5db5738,2a,0,32,0) at vm_object_page_clean+0x1b4 > vm_object_sync(c5db5738,2a000,0,8000,1) at vm_object_sync+0x1ff > vm_map_sync(c5dbd834,2815b000,28163000,1,0) at vm_map_sync+0x29b > msync(c5af1450,f1228d14,3a6,c0719253,c5af1450) at msync+0x7f > syscall(2f,2f,2f,75b6,2a2b5) at syscall+0x2c4 > Xint0x80_syscall() at Xint0x80_syscall+0x1f > --- syscall (65, FreeBSD ELF32, msync), eip =3D 0x280c76a3, esp =3D 0xbfb= fe38c, ebp =3D 0xbfbfe3e8 --- > db> >=20 > Kris --gBBFr7Ir9EOA20Yy Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCBDIPWry0BWjoQKURAm4wAJ0S8x/2LzsYa225Vhd9giM88fuR+wCg50Bs /JfkuPKz3mZ18GD3Rt+NUGU= =q0W9 -----END PGP SIGNATURE----- --gBBFr7Ir9EOA20Yy-- From owner-freebsd-current@FreeBSD.ORG Sat Feb 5 06:50:36 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 04BA816A4CE; Sat, 5 Feb 2005 06:50:36 +0000 (GMT) Received: from hetzner.co.za (lfw.hetzner.co.za [196.7.18.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8C42243D49; Sat, 5 Feb 2005 06:50:34 +0000 (GMT) (envelope-from ianf@hetzner.co.za) Received: from localhost ([127.0.0.1]) by hetzner.co.za with esmtp (Exim 3.36 #1) id 1CxJm5-0005bi-00; Sat, 05 Feb 2005 08:50:33 +0200 To: John Baldwin From: Ian FREISLICH In-reply-to: Your message of "Fri, 04 Feb 2005 16:24:10 EST." <200502041624.10668.jhb@FreeBSD.org> X-Attribution: BOFH Date: Sat, 05 Feb 2005 08:50:33 +0200 Sender: ianf@hetzner.co.za Message-Id: cc: current@FreeBSD.org Subject: Re: sys/1386/i386/mptable.c rev 1.239 breaks boot. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Feb 2005 06:50:36 -0000 John Baldwin wrote: > On Friday 04 February 2005 04:38 am, Ian FREISLICH wrote: > > John Baldwin wrote: > > > On Monday 31 January 2005 07:01 am, Ian FREISLICH wrote: > > > > Hi > > > > > > > > I have a dual pII machine that doesn't boot with 1.239 of > > > > sys/1386/i386/mptable.c. It boots with this patch backed out. > > > > Does anyone have any ideas beyond backing out this patch? > > > > > > > > revision 1.239 > > > > date: 2005/01/18 20:27:24; author: jhb; state: Exp; lines: +7 -1 > > > > If a valid ELCR was found, consult it for the trigger mode of ISA > > > > interrupts that have a trigger mode of conforming. This fixes problems > > > > on some older machines that still route PCI devices via ISA interrupts > > > > when using an I/O APIC. > > > > > > > > This seems to be a case of breaking, rather than fixing older > > > > machines. It's highly reproduceable. I mailed the author of this > > > > commit over a week ago, but have not had a response yet :(. This > > > > is definitely a show-stopper, for me at least. > > > > > > It did fix other boxes. :( Can you provide a verbose dmesg? > > > > I've included both a working and broken kernel verbose boot. > > Ok, short answer is you have a busted MP Table as it is incomplete. You can > try disabling USB as a hack for one to test if that fixes your problem. I > would be interested in seeing your mptable output. That is unsurprising, since so much else about this motherboard seems broken (ACPI doesn't work either). =============================================================================== MPTable, version 2.0.15 ------------------------------------------------------------------------------- MP Floating Pointer Structure: location: BIOS physical address: 0x000f5560 signature: '_MP_' length: 16 bytes version: 1.1 checksum: 0x80 mode: Virtual Wire ------------------------------------------------------------------------------- MP Config Table Header: physical address: 0x000f1400 signature: 'PCMP' base table length: 292 version: 1.1 checksum: 0x9a OEM ID: 'OEM00000' Product ID: 'PROD00000000' OEM table pointer: 0x00000000 OEM table size: 0 entry count: 28 local APIC address: 0xfee00000 extended table length: 0 extended table checksum: 0 ------------------------------------------------------------------------------- MP Config Base Table Entries: -- Processors: APIC ID Version State Family Model Step Flags 0 0x11 BSP, usable 6 3 4 0xfbff 1 0x11 AP, usable 6 3 3 0xfbff -- Bus: Bus ID Type 0 PCI 1 PCI 2 ISA -- I/O APICs: APIC ID Version State Address 2 0x11 usable 0xfec00000 -- I/O Ints: Type Polarity Trigger Bus ID IRQ APIC ID PIN# ExtINT conforms conforms 2 0 2 0 INT conforms conforms 2 1 2 1 INT conforms conforms 2 0 2 2 INT conforms conforms 2 3 2 3 INT conforms conforms 2 4 2 4 INT conforms conforms 2 5 2 5 INT conforms conforms 2 6 2 6 INT conforms conforms 2 7 2 7 INT active-hi edge 2 8 2 8 INT conforms conforms 2 9 2 9 INT conforms conforms 2 10 2 10 INT conforms conforms 2 11 2 11 INT conforms conforms 2 12 2 12 INT conforms conforms 2 13 2 13 INT conforms conforms 2 14 2 14 INT conforms conforms 2 15 2 15 INT active-lo level 0 7:A 2 19 INT active-lo level 0 8:A 2 16 INT active-lo level 0 12:A 2 16 SMI active-lo edge 2 0 2 23 -- Local Ints: Type Polarity Trigger Bus ID IRQ APIC ID PIN# ExtINT conforms conforms 0 0:A 255 0 NMI conforms conforms 0 0:A 255 1 =============================================================================== > > pcib0: unable to route slot 7 INTD > > found-> vendor=0x8086, dev=0x7112, revid=0x01 > > bus=0, slot=7, func=2 > > class=0c-03-00, hdrtype=0x00, mfdev=0 > > cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) > > lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > intpin=d, irq=11 > > map[90]: type 4, range 32, base 00005000, size 4, enabled > > This is your USB controller and is what has the problem FWIW. Note the > message from pcib0 about being unable to route an interrupt. Let me know if > just disabling USB is enough to fix the problem for now. If it is we can go > from there. That would also explain why I've never been able to get USB to work, but that's something for later. Disabling (removing from my kernel config) lets everything work again. I had left it there in the hopes that i would get fixed in time - it would be nice to connect up my USB printer. Ian -- Ian Freislich From owner-freebsd-current@FreeBSD.ORG Sat Feb 5 07:19:31 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1716516A4CE; Sat, 5 Feb 2005 07:19:31 +0000 (GMT) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9EEBE43D39; Sat, 5 Feb 2005 07:19:30 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.13.1/8.13.1) with ESMTP id j157JUDC009233; Sat, 5 Feb 2005 02:19:30 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.1/8.13.1) with ESMTP id j157L3es077528; Sat, 5 Feb 2005 02:21:04 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id EC81E7306E; Sat, 5 Feb 2005 02:19:29 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050205071929.EC81E7306E@freebsd-current.sentex.ca> Date: Sat, 5 Feb 2005 02:19:29 -0500 (EST) X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on smarthost2.sentex.ca X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on clamscanner2 X-Virus-Status: Clean X-Virus-Status: Clean Subject: [current tinderbox] failure on alpha/alpha X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Feb 2005 07:19:31 -0000 TB --- 2005-02-05 05:30:01 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-02-05 05:30:01 - starting CURRENT tinderbox run for alpha/alpha TB --- 2005-02-05 05:30:01 - checking out the source tree TB --- 2005-02-05 05:30:01 - cd /home/tinderbox/CURRENT/alpha/alpha TB --- 2005-02-05 05:30:01 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-02-05 05:45:13 - building world (CFLAGS=-O2 -pipe) TB --- 2005-02-05 05:45:13 - cd /home/tinderbox/CURRENT/alpha/alpha/src TB --- 2005-02-05 05:45:13 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything TB --- 2005-02-05 07:11:45 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-02-05 07:11:45 - cd /home/tinderbox/CURRENT/alpha/alpha/src TB --- 2005-02-05 07:11:45 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sat Feb 5 07:11:45 UTC 2005 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] objcopy --strip-debug coda5.ko.debug coda5.ko ===> cpufreq (all) cc -O2 -fno-strict-aliasing -pipe -mcpu=ev4 -mtune=ev5 -mieee -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I- -include /tinderbox/CURRENT/alpha/alpha/obj/alpha/tinderbox/CURRENT/alpha/alpha/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -I@/../include -finline-limit=15000 -fno-common -g -I/tinderbox/CURRENT/alpha/alpha/obj/alpha/tinderbox/CURRENT/alpha/alpha/src/sys/GENERIC -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /tinderbox/CURRENT/alpha/alpha/src/sys/modules/cpufreq/../../dev/cpufreq/ichss.c /tinderbox/CURRENT/alpha/alpha/src/sys/modules/cpufreq/../../dev/cpufreq/ichss.c: In function `ichss_set': /tinderbox/CURRENT/alpha/alpha/src/sys/modules/cpufreq/../../dev/cpufreq/ichss.c:320: warning: implicit declaration of function `disable_intr' /tinderbox/CURRENT/alpha/alpha/src/sys/modules/cpufreq/../../dev/cpufreq/ichss.c:320: warning: nested extern declaration of `disable_intr' /tinderbox/CURRENT/alpha/alpha/src/sys/modules/cpufreq/../../dev/cpufreq/ichss.c:334: warning: implicit declaration of function `enable_intr' /tinderbox/CURRENT/alpha/alpha/src/sys/modules/cpufreq/../../dev/cpufreq/ichss.c:334: warning: nested extern declaration of `enable_intr' *** Error code 1 Stop in /tinderbox/CURRENT/alpha/alpha/src/sys/modules/cpufreq. *** Error code 1 Stop in /tinderbox/CURRENT/alpha/alpha/src/sys/modules. *** Error code 1 Stop in /tinderbox/CURRENT/alpha/alpha/obj/alpha/tinderbox/CURRENT/alpha/alpha/src/sys/GENERIC. *** Error code 1 Stop in /tinderbox/CURRENT/alpha/alpha/src. *** Error code 1 Stop in /tinderbox/CURRENT/alpha/alpha/src. TB --- 2005-02-05 07:19:29 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-02-05 07:19:29 - ERROR: failed to build generic kernel TB --- 2005-02-05 07:19:29 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Sat Feb 5 07:29:14 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 509FC16A4CE; Sat, 5 Feb 2005 07:29:14 +0000 (GMT) Received: from mp2.macomnet.net (mp2.macomnet.net [195.128.64.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7613843D2F; Sat, 5 Feb 2005 07:29:11 +0000 (GMT) (envelope-from maxim@macomnet.ru) Received-SPF: pass (mp2.macomnet.net: domain of maxim@macomnet.ru designates 127.0.0.1 as permitted sender) receiver=mp2.macomnet.net; client_ip=127.0.0.1; envelope-from=maxim@macomnet.ru; Received: from localhost (localhost [127.0.0.1]) by mp2.macomnet.net (8.12.11/8.12.11) with ESMTP id j157T9vU045828; Sat, 5 Feb 2005 10:29:09 +0300 (MSK) (envelope-from maxim@macomnet.ru) Date: Sat, 5 Feb 2005 10:29:09 +0300 (MSK) From: Maxim Konovalov To: "Matthew N. Dodd" In-Reply-To: <20050204174008.J78005@sasami.jurai.net> Message-ID: <20050205102722.B45783@mp2.macomnet.net> References: <20050204214405.GA54283@aoi.wolfpond.org> <20050204174008.J78005@sasami.jurai.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SpamTest-Info: Profile: Formal (208/050203) X-SpamTest-Info: Profile: Detect Hard (4/030526) X-SpamTest-Info: Profile: SysLog X-SpamTest-Info: Profile: Marking - Keywords (2/030321) X-SpamTest-Status: Not detected X-SpamTest-Version: SMTP-Filter Version 2.0.0 [0124], SpamtestISP/Release cc: current@freebsd.org Subject: Re: Tftp slowness X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Feb 2005 07:29:14 -0000 On Fri, 4 Feb 2005, 17:45-0500, Matthew N. Dodd wrote: > On Fri, 4 Feb 2005, Francois Tigeot wrote: > > Trying to understand the relative slowness of FreeBSD tftp client and > > server compared to other implementations, I found this PR: > > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=67550 > > > > Basically, it adds support for the missing tftp blocksize option. > > > > It would be nice if the patch in the PR could be commited; it has been > > open since june 2004... > > I'll take a look at this as I might have the missing bits that are > needed for the client. Btw, NetBSD's tftp* support TFTP Option Extension (rfc 2347) for the 'blksize' option (rfc 2348) and the 'timeout' and 'tsize' options. -- Maxim Konovalov From owner-freebsd-current@FreeBSD.ORG Sat Feb 5 11:17:04 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7FACE16A4CE for ; Sat, 5 Feb 2005 11:17:04 +0000 (GMT) Received: from smtp1.powertech.no (smtp1.powertech.no [195.159.0.145]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4C56943D1F for ; Sat, 5 Feb 2005 11:17:03 +0000 (GMT) (envelope-from frode@nordahl.net) Received: from [192.168.1.34] (unknown [195.159.232.31]) by smtp1.powertech.no (Postfix) with ESMTP id 9637781EB; Sat, 5 Feb 2005 12:17:01 +0100 (CET) In-Reply-To: <42028F29.1030801@DeepCore.dk> References: <42028F29.1030801@DeepCore.dk> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <0cd37ec888636578f9bc4f5b85ce20af@nordahl.net> Content-Transfer-Encoding: quoted-printable From: Frode Nordahl Date: Sat, 5 Feb 2005 12:16:59 +0100 To: =?ISO-8859-1?Q?S=F8ren_Schmidt?= X-Mailer: Apple Mail (2.619.2) cc: 'FreeBSD Current' Subject: Re: ATA mkIII first official patches - please test! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Feb 2005 11:17:04 -0000 On Feb 3, 2005, at 21:52, S=F8ren Schmidt wrote: > ATA-mkIII first official snapshot. Yes! Just in time! Thanks, S=F8ren :-) Using kernel from RELENG_5, supped yesterday. Tried to install on in a box with a Promise TX 2200 card, the bootup=20 took forever, but the install worked fine when it finished. Maby related to the third "phantom" PATA bus on that board? :-) I'm installing from network (PXE) and for some reason I don't get any=20 kernel messages on the console when doing that, so I don't know when or=20= where it 'hangs'. I forgot to copy in my modified kernel after the install, so I never=20 got it booting after that, but I'll redo as soon as possible and get=20 back with more details about this. > o ATA RAID support has been rewritten and and now supports these > metadata formats: > "Adaptec HostRAID" > "Highpoint V2 RocketRAID" > "Highpoint V3 RocketRAID" > "Intel MatrixRAID" > "Integrated Technology Express" > "LSILogic V2 MegaRAID" > "LSILogic V3 MegaRAID" > "Promise FastTrak" > "Silicon Image Medley" This works with my Intel S875WP1-E with Intel ICH5 / Adaptec HostRAID=20 onboard! (The product specs says Promise controller, but that is only when you=20 buy the 4-ch SATA version) However, if I create a RAID1 array in "Quick Mode", installation failes=20= with write errors ("disk full"). The Adaptec management BIOS warns=20 about creating arrays in Quick Mode, so this may be a problem of=20 theirs. Anyway, is there any way to detect that an array is created in this=20 way, and handle it, or warn about it? The warning message from the BIOS says "You may need to repair the=20 array once OS is installed" or similar, so the array probably should be=20= marked DEGRADED, and be rebuilded once the installation is finished. I can no longer use my swap partition as dump device: # dumpon /dev/ar0s1b dumpon: ioctl(DIOCSKERNELDUMP): Operation not supported by device But I'm not certain that it has ever been allowed? :-) Maybe it won't work to have dump device on RAID, since the kernel won't=20= be able to keep the RAID in shape when it's dumping core? I have not done any extensive testing yet. I'll get these boxes=20 installed and set up various tests to see how it performs. I'll also do=20= some hotswap testing on the TX2200. > Enjoy! I most certainly will! Thanks. Regards, Frode Nordahl > --=20 > > -S=F8ren > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > 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 Sat Feb 5 11:38:03 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5C41516A4CE for ; Sat, 5 Feb 2005 11:38:03 +0000 (GMT) Received: from spider.deepcore.dk (cpe.atm2-0-53484.0x50a6c9a6.abnxx9.customer.tele.dk [80.166.201.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id 79B2543D5E for ; Sat, 5 Feb 2005 11:38:02 +0000 (GMT) (envelope-from sos@DeepCore.dk) Received: from [194.192.25.143] (laptop.deepcore.dk [194.192.25.143]) by spider.deepcore.dk (8.12.11/8.12.10) with ESMTP id j15Bbwr9033861; Sat, 5 Feb 2005 12:38:00 +0100 (CET) (envelope-from sos@DeepCore.dk) Message-ID: <4204B006.9060604@DeepCore.dk> Date: Sat, 05 Feb 2005 12:37:42 +0100 From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= User-Agent: Mozilla Thunderbird 1.0 (X11/20050116) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Frode Nordahl References: <42028F29.1030801@DeepCore.dk> <0cd37ec888636578f9bc4f5b85ce20af@nordahl.net> In-Reply-To: <0cd37ec888636578f9bc4f5b85ce20af@nordahl.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-mail-scanned: by DeepCore Virus & Spam killer v1.6 cc: 'FreeBSD Current' Subject: Re: ATA mkIII first official patches - please test! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Feb 2005 11:38:03 -0000 Frode Nordahl wrote: > On Feb 3, 2005, at 21:52, S=F8ren Schmidt wrote: >=20 >> ATA-mkIII first official snapshot. >=20 > Yes! Just in time! Thanks, S=F8ren :-) >=20 > Using kernel from RELENG_5, supped yesterday. >=20 > Tried to install on in a box with a Promise TX 2200 card, the bootup=20 > took forever, but the install worked fine when it finished. >=20 > Maby related to the third "phantom" PATA bus on that board? :-) Well its doesn't stall on the one I've got here (thanks btw! :) ).. Could you get the output from a verbose boot with it somehow ? >> o ATA RAID support has been rewritten and and now supports these= >> metadata formats: >> "Adaptec HostRAID" >> "Highpoint V2 RocketRAID" >> "Highpoint V3 RocketRAID" >> "Intel MatrixRAID" >> "Integrated Technology Express" >> "LSILogic V2 MegaRAID" >> "LSILogic V3 MegaRAID" >> "Promise FastTrak" >> "Silicon Image Medley" >=20 >=20 > This works with my Intel S875WP1-E with Intel ICH5 / Adaptec HostRAID=20 > onboard! Good :) > However, if I create a RAID1 array in "Quick Mode", installation failes= =20 > with write errors ("disk full"). The Adaptec management BIOS warns abou= t=20 > creating arrays in Quick Mode, so this may be a problem of theirs. >=20 > Anyway, is there any way to detect that an array is created in this way= ,=20 > and handle it, or warn about it? Hmm, it just means that it doesn't copy data so both disks are=20 identical, for our purpose thats of no importance. Maybe I did mess up=20 the size reporting somehow, I'll check... > I can no longer use my swap partition as dump device: >=20 > # dumpon /dev/ar0s1b > dumpon: ioctl(DIOCSKERNELDUMP): Operation not supported by device >=20 > But I'm not certain that it has ever been allowed? :-) It was allowed, but I havn't gotten to reimplement dump in ataraid yet. --=20 -S=F8ren From owner-freebsd-current@FreeBSD.ORG Sat Feb 5 11:40:10 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F16B216A4D5; Sat, 5 Feb 2005 11:40:10 +0000 (GMT) Received: from spider.deepcore.dk (cpe.atm2-0-53484.0x50a6c9a6.abnxx9.customer.tele.dk [80.166.201.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3D05B43D46; Sat, 5 Feb 2005 11:40:10 +0000 (GMT) (envelope-from sos@DeepCore.dk) Received: from [194.192.25.143] (laptop.deepcore.dk [194.192.25.143]) by spider.deepcore.dk (8.12.11/8.12.10) with ESMTP id j15BdxEV033895; Sat, 5 Feb 2005 12:40:01 +0100 (CET) (envelope-from sos@DeepCore.dk) Message-ID: <4204B07F.5080605@DeepCore.dk> Date: Sat, 05 Feb 2005 12:39:43 +0100 From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= User-Agent: Mozilla Thunderbird 1.0 (X11/20050116) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Stuyts References: <42028F29.1030801@DeepCore.dk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-mail-scanned: by DeepCore Virus & Spam killer v1.6 cc: 'FreeBSD Current' cc: "freebsd-stable@freebsd.org" Subject: Re: ATA mkIII first official patches - please test! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Feb 2005 11:40:11 -0000 Ben Stuyts wrote: >=20 > On 3 Feb 2005, at 21:52, S=F8ren Schmidt wrote: >=20 >> o ATA RAID can only read metadata not write them. This means tha= t >> arrays can be picked up from the BIOS, but they cannot be crea= ted >> from FreeBSD. This is being worked on for the final release as= is >> RAID5 support for Promise/Highpoing/SiI controllers. >=20 >=20 > Will RAID mirrors built using atacontrol on standard ata controllers=20 > still work? Specifically in my case on 5.3-stable: Not as is, but its easily added, uncomment line 597 in ata-raid.c and it = will be picked up as before... -S=F8ren From owner-freebsd-current@FreeBSD.ORG Fri Feb 4 14:28:38 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7F5AD16A4CE; Fri, 4 Feb 2005 14:28:38 +0000 (GMT) Received: from altus-escon.com (altesco.xs4all.nl [213.84.124.55]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1BBE443D1D; Fri, 4 Feb 2005 14:28:37 +0000 (GMT) (envelope-from ben@altesco.nl) Received: from [193.78.231.14] (benjoam.altus-escon.com [193.78.231.14]) by altus-escon.com (8.13.1/8.13.1) with ESMTP id j14ESRql092131; Fri, 4 Feb 2005 15:28:27 +0100 (CET) (envelope-from ben@altesco.nl) In-Reply-To: <42028F29.1030801@DeepCore.dk> References: <42028F29.1030801@DeepCore.dk> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Ben Stuyts Date: Fri, 4 Feb 2005 15:28:21 +0100 To: =?ISO-8859-1?Q?S=F8ren_Schmidt?= X-Mailer: Apple Mail (2.619.2) X-Virus-Scanned: ClamAV 0.80/591/Thu Nov 18 16:38:04 2004 clamav-milter version 0.80j on earth.altus-escon.com X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on earth.altus-escon.com X-Mailman-Approved-At: Sat, 05 Feb 2005 12:53:59 +0000 cc: 'FreeBSD Current' cc: "freebsd-stable@freebsd.org" Subject: Re: ATA mkIII first official patches - please test! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2005 14:28:38 -0000 On 3 Feb 2005, at 21:52, S=F8ren Schmidt wrote: > o ATA RAID can only read metadata not write them. This means = that > arrays can be picked up from the BIOS, but they cannot be=20 > created > from FreeBSD. This is being worked on for the final release as=20= > is > RAID5 support for Promise/Highpoing/SiI controllers. Will RAID mirrors built using atacontrol on standard ata controllers=20 still work? Specifically in my case on 5.3-stable: atapci0: port=20 0xf000-0xf00f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 31.1 on=20 pci0 ata0: channel #0 on atapci0 ata1: channel #1 on atapci0 ad0: 117246MB [238216/16/63] at ata0-master=20 UDMA100 ad2: 117246MB [238216/16/63] at ata1-master=20 UDMA100 and: [aurora:~]138: sudo atacontrol status 0 ar0: ATA RAID1 subdisks: ad0 ad2 status: READY Thanks, Ben From owner-freebsd-current@FreeBSD.ORG Sat Feb 5 02:13:26 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 57FC516A4CE; Sat, 5 Feb 2005 02:13:26 +0000 (GMT) Received: from mailhost.catholic.org (mailhost.catholic.org [66.122.14.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id 114F843D46; Sat, 5 Feb 2005 02:13:26 +0000 (GMT) (envelope-from wsk@catholic.org) Received: from webmail.catholic.org (webmail.catholic.org [66.122.14.27]) j152Ec7O007942; Fri, 4 Feb 2005 18:14:38 -0800 Received: from 211.96.21.195 (SquirrelMail authenticated user wsk) by webmail.catholic.org with HTTP; Sat, 5 Feb 2005 02:13:25 -0000 (GMT) Message-ID: <60355.211.96.21.195.1107569605.squirrel@webmail.catholic.org> In-Reply-To: <200502031304.41476.jhb@FreeBSD.org> References: <57062.211.96.21.195.1106558752.squirrel@webmail.catholic.org> <200502031304.41476.jhb@FreeBSD.org> Date: Sat, 5 Feb 2005 02:13:25 -0000 (GMT) From: "wsk" To: "John Baldwin" User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal X-Mailman-Approved-At: Sat, 05 Feb 2005 12:53:59 +0000 cc: current@FreeBSD.org Subject: Re: Rocketport uPCI ioaddr mapping failed under FreeBSD-5.3&CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Feb 2005 02:13:26 -0000 > On Monday 24 January 2005 04:25 am, wsk wrote: >> hi,folks: >> >> after installed RocketPort uPCI card into my box;it >> dumps the follow eror msgs: >> >> rp0: port 0xde00-0xdeff,0xdd80-0xddff mem >> 0xfcedff80-0xfcedffff >> irq 19 at device 10.0 on pci2 >> rp0: failed: rid 0x10 is memory, requested 4 >> rp0: ioaddr mapping failed for RocketPort(PCI). >> device_attach: rp0 attach returned 6 > > Looks like you need to change the driver to map its io addresses from a > different BAR for this chip ID since BAR 0 is memory, not I/O. I'm not > sure > this driver will work with this card, btw, but you can try changing this > line > in the attach function of sys/dev/rp/rp_pci.c: > > ctlp->io_rid[0] = 0x10; > > to use either '0x14' or '0x18' rather than '0x10' and see if it works. > >> and pciconfig the rp0: >> rp0@pci2:10:0: class=0x078000 card=0x080511fe chip=0x080511fe rev=0x01 >> hdr=0x00 >> vendor = 'Comtrol Corp' >> class = simple comms yep.It seems work excellent !and thank u very much ----------------------------------------- This email was sent using FREE Catholic Online Webmail! http://webmail.catholic.org/ From owner-freebsd-current@FreeBSD.ORG Sat Feb 5 09:01:16 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CE95C16A4CF; Sat, 5 Feb 2005 09:01:16 +0000 (GMT) Received: from mailhost.catholic.org (mailhost.catholic.org [66.122.14.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6072843D54; Sat, 5 Feb 2005 09:01:16 +0000 (GMT) (envelope-from wsk@catholic.org) Received: from webmail.catholic.org (webmail.catholic.org [66.122.14.27]) j1592Utv023929; Sat, 5 Feb 2005 01:02:30 -0800 Received: from 211.96.21.195 (SquirrelMail authenticated user wsk) by webmail.catholic.org with HTTP; Sat, 5 Feb 2005 09:01:16 -0000 (GMT) Message-ID: <64443.211.96.21.195.1107594076.squirrel@webmail.catholic.org> In-Reply-To: <200502031304.41476.jhb@FreeBSD.org> References: <57062.211.96.21.195.1106558752.squirrel@webmail.catholic.org> <200502031304.41476.jhb@FreeBSD.org> Date: Sat, 5 Feb 2005 09:01:16 -0000 (GMT) From: "wsk" To: "John Baldwin" User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal X-Mailman-Approved-At: Sat, 05 Feb 2005 12:53:59 +0000 cc: current@FreeBSD.org Subject: Re: Rocketport uPCI ioaddr mapping failed under FreeBSD-5.3&CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Feb 2005 09:01:17 -0000 > On Monday 24 January 2005 04:25 am, wsk wrote: >> hi,folks: >> >> after installed RocketPort uPCI card into my box;it >> dumps the follow eror msgs: >> >> rp0: port 0xde00-0xdeff,0xdd80-0xddff mem >> 0xfcedff80-0xfcedffff >> irq 19 at device 10.0 on pci2 >> rp0: failed: rid 0x10 is memory, requested 4 >> rp0: ioaddr mapping failed for RocketPort(PCI). >> device_attach: rp0 attach returned 6 > > Looks like you need to change the driver to map its io addresses from a > different BAR for this chip ID since BAR 0 is memory, not I/O. I'm not > sure > this driver will work with this card, btw, but you can try changing this > line > in the attach function of sys/dev/rp/rp_pci.c: > > ctlp->io_rid[0] = 0x10; > > to use either '0x14' or '0x18' rather than '0x10' and see if it >works. It must use '0x18' . or the driver can't map the ports: here'is my boot mesgs by set '0x14' Feb 5 16:21:20 wsk kernel: rp0: port 0xde00-0xdeff,0xdd80-0xddff mem 0xfcedff80-0xfcedffff irq 19 at device 10.0 on pci2 Feb 5 16:21:20 wsk kernel: RocketPort0 (Version 3.02) 0 ports. and after set '0x18'. the boot mesgs: Feb 5 16:47:59 wsk kernel: rp0: port 0xde00-0xdeff,0xdd80-0xddff mem 0xfcedff80-0xfcedffff irq 19 at device 10.0 on pci2 Feb 5 16:47:59 wsk kernel: RocketPort0 (Version 3.02) 8 ports. and thanks again ----------------------------------------- This email was sent using FREE Catholic Online Webmail! http://webmail.catholic.org/ From owner-freebsd-current@FreeBSD.ORG Sat Feb 5 13:54:38 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 569B816A4CE for ; Sat, 5 Feb 2005 13:54:38 +0000 (GMT) Received: from mail.latnet.lv (mail.latnet.lv [159.148.108.13]) by mx1.FreeBSD.org (Postfix) with SMTP id DD0EF43D1D for ; Sat, 5 Feb 2005 13:54:34 +0000 (GMT) (envelope-from kaspars@os.lv) Received: (qmail 6959 invoked by uid 103); 5 Feb 2005 13:54:33 -0000 Received: from 159.148.155.3 by esbens (envelope-from , uid 64011) with qmail-scanner-1.23st (spamassassin: 2.64. perlscan: 1.23st. Clear:RC:1(159.148.155.3):. Processed in 0.026362 secs); 05 Feb 2005 13:54:33 -0000 Received: from unknown (HELO os.lv) (159.148.155.3) by mail.latnet.lv with SMTP; 5 Feb 2005 13:54:33 -0000 Received: from 192.168.1.21 ([192.168.1.21]) by os.lv (WinRoute Pro 4.1) with SMTP; Sat, 5 Feb 2005 15:57:02 +0200 Message-ID: <4204D02B.6080804@os.lv> Date: Sat, 05 Feb 2005 15:54:51 +0200 From: Kaspars User-Agent: Mozilla Thunderbird 0.9 (X11/20041127) X-Accept-Language: en-us, en MIME-Version: 1.0 To: FreeBSD Current Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Promise raid X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Feb 2005 13:54:38 -0000 Hi, I have server INTEL s875wp1-e server motherboard with cuurent FreeBSD 5.3-RELEASE-p5. I have started to make file sever with samba and have some problems with feikraid controller. Maybe somebody can say what means in dmesg: ... atapci0: port 0xb000-0xb07f,0xb400-0xb40f,0xbc00-0xbc3f mem 0xfeaa0000-0xfeabffff,0xfeafe000-0xfeafefff irq 17 at device 7.0 on pci3 atapci0: failed: rid 0x20 is memory, requested 4 ... acpi_cpu: throttling enabled, 8 steps (100% to 12.5%), currently 100.0% ata2-master: FAILURE - ATA_IDENTIFY timed out ad4: 238418MB [484406/16/63] at ata2-master SATA150 ad8: 238475MB [484521/16/63] at ata4-master SATA150 ad12: 238475MB [484521/16/63] at ata6-master SATA150 ad14: 238418MB [484406/16/63] at ata7-master SATA150 Mounting root from ufs:/dev/ad12s1a Is it bad? I have only sata disks, two of them trought with normal sata controller, two trought feikraid. How I don`t like this raid and disain of this motherboard... :( Casper From owner-freebsd-current@FreeBSD.ORG Sat Feb 5 14:08:24 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 69F6316A4CE; Sat, 5 Feb 2005 14:08:24 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 507AD43D46; Sat, 5 Feb 2005 14:08:24 +0000 (GMT) (envelope-from davidxu@freebsd.org) Received: from [127.0.0.1] (davidxu@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.1/8.13.1) with ESMTP id j15E8JGN082293; Sat, 5 Feb 2005 14:08:22 GMT (envelope-from davidxu@freebsd.org) Message-ID: <4204D351.3050005@freebsd.org> Date: Sat, 05 Feb 2005 22:08:17 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20041226 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jung-uk Kim References: <4204084A.9070006@freebsd.org> <200502041906.49069.jkim@niksun.com> In-Reply-To: <200502041906.49069.jkim@niksun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org cc: current@freebsd.org Subject: Re: any chance to make Nforce 3 work better X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Feb 2005 14:08:24 -0000 Jung-uk Kim wrote: >On Friday 04 February 2005 06:42 pm, David Xu wrote: > > >>I got a Nforce3 ultra board, EPOX EP9NDA3, I can only >>boot it with acpi turned off in kernel, otherwise, kernel >>prints: >>calcru: runtime went backwards from 425709 usec to 39765 >>usec for pid 11 (idle) >>then system is dead. >>is there any chance to make it work better ? although I >>know Nforce is suckage. >> >> > >Try the following patches: > >http://docs.freebsd.org/cgi/mid.cgi?200501192214.27401.jkim >http://docs.freebsd.org/cgi/mid.cgi?200501261149.11530.jkim > > > I have tried, now the machine is usable, but onboard ALC850 sound card no longer works: pcm0:play:0: play interrupt timeout, channel dead >jhb is working on this issue: > >http://docs.freebsd.org/cgi/mid.cgi?200501311738.04377.jhb > >Jung-uk Kim >_______________________________________________ >freebsd-current@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-current >To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > > > From owner-freebsd-current@FreeBSD.ORG Sat Feb 5 14:08:24 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 69F6316A4CE; Sat, 5 Feb 2005 14:08:24 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 507AD43D46; Sat, 5 Feb 2005 14:08:24 +0000 (GMT) (envelope-from davidxu@freebsd.org) Received: from [127.0.0.1] (davidxu@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.1/8.13.1) with ESMTP id j15E8JGN082293; Sat, 5 Feb 2005 14:08:22 GMT (envelope-from davidxu@freebsd.org) Message-ID: <4204D351.3050005@freebsd.org> Date: Sat, 05 Feb 2005 22:08:17 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20041226 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jung-uk Kim References: <4204084A.9070006@freebsd.org> <200502041906.49069.jkim@niksun.com> In-Reply-To: <200502041906.49069.jkim@niksun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org cc: current@freebsd.org Subject: Re: any chance to make Nforce 3 work better X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Feb 2005 14:08:24 -0000 Jung-uk Kim wrote: >On Friday 04 February 2005 06:42 pm, David Xu wrote: > > >>I got a Nforce3 ultra board, EPOX EP9NDA3, I can only >>boot it with acpi turned off in kernel, otherwise, kernel >>prints: >>calcru: runtime went backwards from 425709 usec to 39765 >>usec for pid 11 (idle) >>then system is dead. >>is there any chance to make it work better ? although I >>know Nforce is suckage. >> >> > >Try the following patches: > >http://docs.freebsd.org/cgi/mid.cgi?200501192214.27401.jkim >http://docs.freebsd.org/cgi/mid.cgi?200501261149.11530.jkim > > > I have tried, now the machine is usable, but onboard ALC850 sound card no longer works: pcm0:play:0: play interrupt timeout, channel dead >jhb is working on this issue: > >http://docs.freebsd.org/cgi/mid.cgi?200501311738.04377.jhb > >Jung-uk Kim >_______________________________________________ >freebsd-current@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-current >To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > > > From owner-freebsd-current@FreeBSD.ORG Sat Feb 5 15:53:12 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 309B516A4CE for ; Sat, 5 Feb 2005 15:53:12 +0000 (GMT) Received: from smtp1.powertech.no (smtp1.powertech.no [195.159.0.145]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7B3C843D2F for ; Sat, 5 Feb 2005 15:53:11 +0000 (GMT) (envelope-from frode@nordahl.net) Received: from [192.168.1.34] (unknown [195.159.232.31]) by smtp1.powertech.no (Postfix) with ESMTP id 24AF57E56; Sat, 5 Feb 2005 16:53:10 +0100 (CET) In-Reply-To: <4204B006.9060604@DeepCore.dk> References: <42028F29.1030801@DeepCore.dk> <0cd37ec888636578f9bc4f5b85ce20af@nordahl.net> <4204B006.9060604@DeepCore.dk> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <14f889a6248ec02e7cb5279b6046d961@nordahl.net> Content-Transfer-Encoding: quoted-printable From: Frode Nordahl Date: Sat, 5 Feb 2005 16:53:08 +0100 To: =?ISO-8859-1?Q?S=F8ren_Schmidt?= X-Mailer: Apple Mail (2.619.2) cc: 'FreeBSD Current' Subject: Re: ATA mkIII first official patches - please test! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Feb 2005 15:53:12 -0000 On Feb 5, 2005, at 12:37, S=F8ren Schmidt wrote: >>> o ATA RAID support has been rewritten and and now supports=20 >>> these >>> metadata formats: >>> "Adaptec HostRAID" >>> "Highpoint V2 RocketRAID" >>> "Highpoint V3 RocketRAID" >>> "Intel MatrixRAID" >>> "Integrated Technology Express" >>> "LSILogic V2 MegaRAID" >>> "LSILogic V3 MegaRAID" >>> "Promise FastTrak" >>> "Silicon Image Medley" >> This works with my Intel S875WP1-E with Intel ICH5 / Adaptec HostRAID=20= >> onboard! > > Good :) I have been abusing a installation with this controller for the last 5=20= hours without incident! I'll let it run 'till monday. Running the following on /dev/ar0 which is a RAID1 on top of two 80G=20 Maxtors (Maxtor 6Y080M0 YAR511W0): in /var/tmp (20G) 5 simultaneous runs, extract and remove a copy of=20 /usr/src (the tar is read from a seperate PATA disk) while true; do for i in 0 1 2 3 4; do mv ./$i/usr ./$i/usr.bak rm -rf ./$i/usr.bak & tar -C ./$i -xf /1/src.tar & done wait done in /usr/home (50G) write a 4G file over and over again, read a 4G file=20= over and over again while true; do dd if=3D/dev/zero of=3Dwrite bs=3D1m count=3D4k & dd if=3Dread of=3D/dev/null bs=3D1m & wait done Maybe I'll throw in some bonnie processes as well just for fun :-) Regards, Frode > --=20 > > -S=F8ren > > From owner-freebsd-current@FreeBSD.ORG Sat Feb 5 16:26:34 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B3F7D16A4CE for ; Sat, 5 Feb 2005 16:26:34 +0000 (GMT) Received: from mp2.macomnet.net (mp2.macomnet.net [195.128.64.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id A154B43D45 for ; Sat, 5 Feb 2005 16:26:31 +0000 (GMT) (envelope-from maxim@macomnet.ru) Received-SPF: pass (mp2.macomnet.net: domain of maxim@macomnet.ru designates 127.0.0.1 as permitted sender) receiver=mp2.macomnet.net; client_ip=127.0.0.1; envelope-from=maxim@macomnet.ru; Received: from localhost (localhost [127.0.0.1]) by mp2.macomnet.net (8.12.11/8.12.11) with ESMTP id j15GQLKc054427; Sat, 5 Feb 2005 19:26:21 +0300 (MSK) (envelope-from maxim@macomnet.ru) Date: Sat, 5 Feb 2005 19:26:21 +0300 (MSK) From: Maxim Konovalov To: =?ISO-8859-1?Q?S=F8ren_Schmidt?= In-Reply-To: <42028F29.1030801@DeepCore.dk> Message-ID: <20050205192139.P54165@mp2.macomnet.net> References: <42028F29.1030801@DeepCore.dk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SpamTest-Info: Profile: Formal (208/050203) X-SpamTest-Info: Profile: Detect Hard (4/030526) X-SpamTest-Info: Profile: SysLog X-SpamTest-Info: Profile: Marking - Keywords (2/030321) X-SpamTest-Status: Not detected X-SpamTest-Version: SMTP-Filter Version 2.0.0 [0124], SpamtestISP/Release cc: 'FreeBSD Current' Subject: Re: ATA mkIII first official patches - please test! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Feb 2005 16:26:34 -0000 On Thu, 3 Feb 2005, 21:52+0100, S?ren Schmidt wrote: > ATA-mkIII first official snapshot. On my Sony VAIO PCG-505BX ioctl(CDIOEJECT) (cdcontrol eject) returns EOPNOTSUPP. Kernel config and dmesg: http://maxim.int.ru/stuff/SONNIE http://maxim.int.ru/stuff/SONNIE.boot -- Maxim Konovalov From owner-freebsd-current@FreeBSD.ORG Sat Feb 5 17:55:12 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BF22D16A4CF; Sat, 5 Feb 2005 17:55:12 +0000 (GMT) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4B1C743D5C; Sat, 5 Feb 2005 17:55:12 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.13.1/8.13.1) with ESMTP id j15HtBLH034158; Sat, 5 Feb 2005 12:55:11 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.1/8.13.1) with ESMTP id j15HuojU003026; Sat, 5 Feb 2005 12:56:50 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id B8B087306E; Sat, 5 Feb 2005 12:55:11 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050205175511.B8B087306E@freebsd-current.sentex.ca> Date: Sat, 5 Feb 2005 12:55:11 -0500 (EST) X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on smarthost2.sentex.ca X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on clamscanner2 X-Virus-Status: Clean X-Virus-Status: Clean Subject: [current tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Feb 2005 17:55:13 -0000 TB --- 2005-02-05 16:37:11 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-02-05 16:37:11 - starting CURRENT tinderbox run for sparc64/sparc64 TB --- 2005-02-05 16:37:11 - checking out the source tree TB --- 2005-02-05 16:37:11 - cd /home/tinderbox/CURRENT/sparc64/sparc64 TB --- 2005-02-05 16:37:11 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-02-05 16:42:55 - building world (CFLAGS=-O2 -pipe) TB --- 2005-02-05 16:42:55 - cd /home/tinderbox/CURRENT/sparc64/sparc64/src TB --- 2005-02-05 16:42:55 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything TB --- 2005-02-05 17:49:26 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-02-05 17:49:26 - cd /home/tinderbox/CURRENT/sparc64/sparc64/src TB --- 2005-02-05 17:49:26 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sat Feb 5 17:49:26 UTC 2005 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/tinderbox/CURRENT/sparc64/sparc64/src/sys -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/altq -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/pf -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcmodel=medlow -msoft-float -ffreestanding -Werror /tinderbox/CURRENT/sparc64/sparc64/src/sys/sparc64/sparc64/iommu.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/tinderbox/CURRENT/sparc64/sparc64/src/sys -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/altq -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/pf -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcmodel=medlow -msoft-float -ffreestanding -Werror /tinderbox/CURRENT/sparc64/sparc64/src/sys/sparc64/sparc64/machdep.c /tinderbox/CURRENT/sparc64/sparc64/src/sys/sparc64/sparc64/machdep.c: In function `utrap_alloc': /tinderbox/CURRENT/sparc64/sparc64/src/sys/sparc64/sparc64/machdep.c:853: error: `M_SUBPROC' undeclared (first use in this function) /tinderbox/CURRENT/sparc64/sparc64/src/sys/sparc64/sparc64/machdep.c:853: error: (Each undeclared identifier is reported only once /tinderbox/CURRENT/sparc64/sparc64/src/sys/sparc64/sparc64/machdep.c:853: error: for each function it appears in.) /tinderbox/CURRENT/sparc64/sparc64/src/sys/sparc64/sparc64/machdep.c: In function `utrap_free': /tinderbox/CURRENT/sparc64/sparc64/src/sys/sparc64/sparc64/machdep.c:870: error: `M_SUBPROC' undeclared (first use in this function) *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/tinderbox/CURRENT/sparc64/sparc64/src/sys/GENERIC. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src. TB --- 2005-02-05 17:55:11 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-02-05 17:55:11 - ERROR: failed to build generic kernel TB --- 2005-02-05 17:55:11 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Sat Feb 5 20:06:53 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3EB8816A531 for ; Sat, 5 Feb 2005 20:06:53 +0000 (GMT) Received: from spider.deepcore.dk (cpe.atm2-0-53484.0x50a6c9a6.abnxx9.customer.tele.dk [80.166.201.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7C43043D1D for ; Sat, 5 Feb 2005 20:06:52 +0000 (GMT) (envelope-from sos@DeepCore.dk) Received: from [194.192.25.143] (laptop.deepcore.dk [194.192.25.143]) by spider.deepcore.dk (8.12.11/8.12.10) with ESMTP id j15K6iX8041847; Sat, 5 Feb 2005 21:06:47 +0100 (CET) (envelope-from sos@DeepCore.dk) Message-ID: <42052747.7000102@DeepCore.dk> Date: Sat, 05 Feb 2005 21:06:31 +0100 From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= User-Agent: Mozilla Thunderbird 1.0 (X11/20050116) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Maxim Konovalov References: <42028F29.1030801@DeepCore.dk> <20050205192139.P54165@mp2.macomnet.net> In-Reply-To: <20050205192139.P54165@mp2.macomnet.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-mail-scanned: by DeepCore Virus & Spam killer v1.6 cc: 'FreeBSD Current' Subject: Re: ATA mkIII first official patches - please test! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Feb 2005 20:06:53 -0000 Maxim Konovalov wrote: > On Thu, 3 Feb 2005, 21:52+0100, S?ren Schmidt wrote: >=20 >=20 >>ATA-mkIII first official snapshot. >=20 >=20 > On my Sony VAIO PCG-505BX ioctl(CDIOEJECT) (cdcontrol eject) returns > EOPNOTSUPP. Thanks! I accidentally removed a line in atapi-cd.c, please try below=20 patch it should fic the problem. --- atapi-cd.c 2005/02/03 15:23:35 1.15 +++ atapi-cd.c 2005/02/05 19:59:54 @@ -134,6 +134,7 @@ cdp->block_size =3D 2048; device_set_ivars(dev, cdp); ATA_SETMODE(GRANDPARENT(dev), dev); + acd_get_cap(dev); g_post_event(acd_geom_attach, dev, M_WAITOK, NULL); /* announce we are here */ --=20 -S=F8ren From owner-freebsd-current@FreeBSD.ORG Sat Feb 5 20:32:51 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2759E16A4CE for ; Sat, 5 Feb 2005 20:32:51 +0000 (GMT) Received: from mp2.macomnet.net (mp2.macomnet.net [195.128.64.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id EC89543D39 for ; Sat, 5 Feb 2005 20:32:49 +0000 (GMT) (envelope-from maxim@macomnet.ru) Received-SPF: pass (mp2.macomnet.net: domain of maxim@macomnet.ru designates 127.0.0.1 as permitted sender) receiver=mp2.macomnet.net; client_ip=127.0.0.1; envelope-from=maxim@macomnet.ru; Received: from localhost (localhost [127.0.0.1]) by mp2.macomnet.net (8.12.11/8.12.11) with ESMTP id j15KWguc057885; Sat, 5 Feb 2005 23:32:42 +0300 (MSK) (envelope-from maxim@macomnet.ru) Date: Sat, 5 Feb 2005 23:32:42 +0300 (MSK) From: Maxim Konovalov To: =?ISO-8859-1?Q?S=F8ren_Schmidt?= In-Reply-To: <42052747.7000102@DeepCore.dk> Message-ID: <20050205233053.I57868@mp2.macomnet.net> References: <42028F29.1030801@DeepCore.dk> <20050205192139.P54165@mp2.macomnet.net> <42052747.7000102@DeepCore.dk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SpamTest-Info: Profile: Formal (208/050203) X-SpamTest-Info: Profile: Detect Hard (4/030526) X-SpamTest-Info: Profile: SysLog X-SpamTest-Info: Profile: Marking - Keywords (2/030321) X-SpamTest-Status: Not detected X-SpamTest-Version: SMTP-Filter Version 2.0.0 [0124], SpamtestISP/Release cc: 'FreeBSD Current' Subject: Re: ATA mkIII first official patches - please test! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Feb 2005 20:32:51 -0000 On Sat, 5 Feb 2005, 21:06+0100, S?ren Schmidt wrote: > Maxim Konovalov wrote: > > On Thu, 3 Feb 2005, 21:52+0100, S?ren Schmidt wrote: > > > > > > > ATA-mkIII first official snapshot. > > > > > > On my Sony VAIO PCG-505BX ioctl(CDIOEJECT) (cdcontrol eject) returns > > EOPNOTSUPP. > > Thanks! I accidentally removed a line in atapi-cd.c, please try > below patch it should fic the problem. > > --- atapi-cd.c 2005/02/03 15:23:35 1.15 > +++ atapi-cd.c 2005/02/05 19:59:54 > @@ -134,6 +134,7 @@ > cdp->block_size = 2048; > device_set_ivars(dev, cdp); > ATA_SETMODE(GRANDPARENT(dev), dev); > + acd_get_cap(dev); > g_post_event(acd_geom_attach, dev, M_WAITOK, NULL); > > /* announce we are here */ # make unload load && cdcontrol eject && echo 'It works, thanks' /sbin/kldunload -v atapicd.ko Unloading atapicd.ko, id=25 /sbin/kldload -v /usr/src/sys/modules/ata/atapicd/atapicd.ko Loaded /usr/src/sys/modules/ata/atapicd/atapicd.ko, id=25 It works, thanks -- Maxim Konovalov From owner-freebsd-current@FreeBSD.ORG Sat Feb 5 20:40:53 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 56A8816A4CE for ; Sat, 5 Feb 2005 20:40:53 +0000 (GMT) Received: from spider.deepcore.dk (cpe.atm2-0-53484.0x50a6c9a6.abnxx9.customer.tele.dk [80.166.201.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id 70C7C43D41 for ; Sat, 5 Feb 2005 20:40:52 +0000 (GMT) (envelope-from sos@DeepCore.dk) Received: from [194.192.25.143] (laptop.deepcore.dk [194.192.25.143]) by spider.deepcore.dk (8.12.11/8.12.10) with ESMTP id j15Kej7h042367; Sat, 5 Feb 2005 21:40:47 +0100 (CET) (envelope-from sos@DeepCore.dk) Message-ID: <42052F40.8070104@DeepCore.dk> Date: Sat, 05 Feb 2005 21:40:32 +0100 From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= User-Agent: Mozilla Thunderbird 1.0 (X11/20050116) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Maxim Konovalov References: <42028F29.1030801@DeepCore.dk> <20050205192139.P54165@mp2.macomnet.net> <42052747.7000102@DeepCore.dk> <20050205233053.I57868@mp2.macomnet.net> In-Reply-To: <20050205233053.I57868@mp2.macomnet.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-mail-scanned: by DeepCore Virus & Spam killer v1.6 cc: 'FreeBSD Current' Subject: Re: ATA mkIII first official patches - please test! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Feb 2005 20:40:53 -0000 Maxim Konovalov wrote: > # make unload load && cdcontrol eject && echo 'It works, thanks' > /sbin/kldunload -v atapicd.ko > Unloading atapicd.ko, id=3D25 > /sbin/kldload -v /usr/src/sys/modules/ata/atapicd/atapicd.ko > Loaded /usr/src/sys/modules/ata/atapicd/atapicd.ko, id=3D25 > It works, thanks He :) modules is a nice feature :) --=20 -S=F8ren From owner-freebsd-current@FreeBSD.ORG Sat Feb 5 20:52:28 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BD58716A4CE for ; Sat, 5 Feb 2005 20:52:28 +0000 (GMT) Received: from smtp1.powertech.no (smtp1.powertech.no [195.159.0.145]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0FD2343D1F for ; Sat, 5 Feb 2005 20:52:28 +0000 (GMT) (envelope-from frode@nordahl.net) Received: from [192.168.1.34] (unknown [195.159.232.31]) by smtp1.powertech.no (Postfix) with ESMTP id CEB38818A; Sat, 5 Feb 2005 21:52:26 +0100 (CET) In-Reply-To: <42028F29.1030801@DeepCore.dk> References: <42028F29.1030801@DeepCore.dk> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <107e33f70745912acda0e41e7148a31b@nordahl.net> Content-Transfer-Encoding: quoted-printable From: Frode Nordahl Date: Sat, 5 Feb 2005 21:52:25 +0100 To: =?ISO-8859-1?Q?S=F8ren_Schmidt?= X-Mailer: Apple Mail (2.619.2) cc: 'FreeBSD Current' Subject: Re: ATA mkIII first official patches - please test! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Feb 2005 20:52:28 -0000 On Feb 3, 2005, at 21:52, S=F8ren Schmidt wrote: > ATA-mkIII first official snapshot. # atacontrol status ar0 atacontrol: ioctl(ATARAIDSTATUS): Inappropriate ioctl for device # atacontrol rebuild ar0 atacontrol: ioctl(ATARAIDREBUILD): Inappropriate ioctl for device I tried to copy in sys/sys/ata.h to /usr/include/sys/ and rebuild=20 atacontrol as well. Regards, Frode Nordahl > --=20 > > -S=F8ren > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > 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 Sat Feb 5 21:00:08 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 886CB16A4CF for ; Sat, 5 Feb 2005 21:00:08 +0000 (GMT) Received: from ran.psg.com (ip192.186.dsl-acs2.seawa0.iinet.com [209.20.186.192]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5A0DE43D2D for ; Sat, 5 Feb 2005 21:00:08 +0000 (GMT) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=ran.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CxX2D-000Mub-Tg for freebsd-current@freebsd.org; Sat, 05 Feb 2005 13:00:06 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16901.13269.509134.918380@ran.psg.com> Date: Sat, 5 Feb 2005 13:00:05 -0800 To: FreeBSD Current Subject: logitec usb wireless mouse X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Feb 2005 21:00:08 -0000 anyone have the logitech wireless mouse working and can send a clue? the keyboard is fine. the mouse does the logitec connect thing; but moving/clicking it does nothing. randy From owner-freebsd-current@FreeBSD.ORG Sat Feb 5 21:18:31 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1E36816A4CE for ; Sat, 5 Feb 2005 21:18:31 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.198]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3E77443D1F for ; Sat, 5 Feb 2005 21:18:29 +0000 (GMT) (envelope-from gert.cuykens@gmail.com) Received: by rproxy.gmail.com with SMTP id f1so566136rne for ; Sat, 05 Feb 2005 13:18:28 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=m+DYDJmnEU8FQeDV9lk+ogUR6QLWNb2AuRVKhnCBXvz5mZYgRhAgGhDWlulTa1YCME6eYZZMQRERcl+/bggY2RzkoL3uvvO7qKkaNZ7zMBQGPUUoaqrj2kl9SwGqHJgqt4aByVd4pytG65UPKCKYt7N6KCR4xsTmhQoVM3oP4Aw= Received: by 10.38.71.66 with SMTP id t66mr74375rna; Sat, 05 Feb 2005 13:18:28 -0800 (PST) Received: by 10.38.74.23 with HTTP; Sat, 5 Feb 2005 13:18:27 -0800 (PST) Message-ID: Date: Sat, 5 Feb 2005 22:18:27 +0100 From: Gert Cuykens To: Randy Bush In-Reply-To: <16901.13269.509134.918380@ran.psg.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <16901.13269.509134.918380@ran.psg.com> cc: FreeBSD Current Subject: Re: logitec usb wireless mouse X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Gert Cuykens List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Feb 2005 21:18:31 -0000 On Sat, 5 Feb 2005 13:00:05 -0800, Randy Bush wrote: > anyone have the logitech wireless mouse working and can send > a clue? the keyboard is fine. the mouse does the logitec > connect thing; but moving/clicking it does nothing. > > randy > step one ################ # /etc/rc.conf # ################ usbd_enable="YES" ifconfig_rl0="DHCP" saver="blank" blanktime="300" moused_enable="NO" hostname="I" sshd_enable="YES" step two ################ # xorg.conf # ################ Section "InputDevice" Identifier "Mouse0" Driver "mouse" Option "Protocol" "auto" Option "Device" "/dev/sysmouse" Option "ZAxisMapping" "4 5" Option "Buttons" "5" EndSection Then again its just me : ) From owner-freebsd-current@FreeBSD.ORG Sat Feb 5 21:31:52 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 425BE16A4CE for ; Sat, 5 Feb 2005 21:31:52 +0000 (GMT) Received: from spider.deepcore.dk (cpe.atm2-0-53484.0x50a6c9a6.abnxx9.customer.tele.dk [80.166.201.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id 80DFB43D2D for ; Sat, 5 Feb 2005 21:31:51 +0000 (GMT) (envelope-from sos@DeepCore.dk) Received: from [194.192.25.143] (laptop.deepcore.dk [194.192.25.143]) by spider.deepcore.dk (8.12.11/8.12.10) with ESMTP id j15LVixR043233; Sat, 5 Feb 2005 22:31:46 +0100 (CET) (envelope-from sos@DeepCore.dk) Message-ID: <42053B33.5020500@DeepCore.dk> Date: Sat, 05 Feb 2005 22:31:31 +0100 From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= User-Agent: Mozilla Thunderbird 1.0 (X11/20050116) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Frode Nordahl References: <42028F29.1030801@DeepCore.dk> <107e33f70745912acda0e41e7148a31b@nordahl.net> In-Reply-To: <107e33f70745912acda0e41e7148a31b@nordahl.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-mail-scanned: by DeepCore Virus & Spam killer v1.6 cc: 'FreeBSD Current' Subject: Re: ATA mkIII first official patches - please test! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Feb 2005 21:31:52 -0000 Frode Nordahl wrote: > On Feb 3, 2005, at 21:52, S=F8ren Schmidt wrote: >=20 >> ATA-mkIII first official snapshot. >=20 >=20 > # atacontrol status ar0 > atacontrol: ioctl(ATARAIDSTATUS): Inappropriate ioctl for device >=20 > # atacontrol rebuild ar0 > atacontrol: ioctl(ATARAIDREBUILD): Inappropriate ioctl for device >=20 > I tried to copy in sys/sys/ata.h to /usr/include/sys/ and rebuild=20 > atacontrol as well. Those ioctl's are not supported yet. As stated ataraid can only read the = metadata so far, not write them. I didn't implement the status ioctl as=20 its part of the interface to write metadata (ie create arrays), and I=20 havn't made up my mind yet on that... --=20 -S=F8ren From owner-freebsd-current@FreeBSD.ORG Sat Feb 5 22:11:48 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E045116A4CE for ; Sat, 5 Feb 2005 22:11:48 +0000 (GMT) Received: from ran.psg.com (ip192.186.dsl-acs2.seawa0.iinet.com [209.20.186.192]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9B44143D46 for ; Sat, 5 Feb 2005 22:11:46 +0000 (GMT) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=ran.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CxY9Z-000Oka-0l; Sat, 05 Feb 2005 14:11:45 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16901.17568.508077.730828@ran.psg.com> Date: Sat, 5 Feb 2005 14:11:44 -0800 To: Gert Cuykens References: <16901.13269.509134.918380@ran.psg.com> cc: FreeBSD Current Subject: Re: logitec usb wireless mouse X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Feb 2005 22:11:49 -0000 > usbd_enable="YES" yep. and the keyboard would not have worked without that > ifconfig_rl0="DHCP" > saver="blank" > blanktime="300" not relevant, i hope > moused_enable="NO" hmmm. i use moused all the time, as i switch back and forth from touchpad to usb. > Section "InputDevice" > Identifier "Mouse0" > Driver "mouse" > Option "Protocol" "auto" > Option "Device" "/dev/sysmouse" > Option "ZAxisMapping" "4 5" > Option "Buttons" "5" > EndSection ahhhh. usbd is running moused for you. i hacked /etc/usbd.conf to have device "Mouse" devname "ums[0-9]+" attach "/usr/bin/killall moused; /usr/sbin/moused -p /dev/ums0 -t auto; /usr/sbin/vidcontrol -m on" detach "/usr/bin/killall moused; /usr/sbin/moused -p /dev/psm0 -t auto; /usr/sbin/vidcontrol -m on" device "Logitech Cordless Keyboard" devname "ukbd0" attach "/usr/sbin/kbdcontrol -k /dev/kbd1 < /dev/console" detach "/usr/sbin/kbdcontrol -k /dev/kbd0 < /dev/console" this switches back and forth between the built-in keyboard and the usb keyboard brilliantly. but the mouse has a will of its own. so then i have Section "InputDevice" Identifier "Mouse0" Driver "mouse" Option "Protocol" "auto" Option "Device" "/dev/sysmouse" EndSection again, the keyboard works, and usbdevs shows me port 2 addr 2: low speed, power 98 mA, config 1, \ USB Receiver(0xc50b), Logitech(0x046d), rev 21.00 and syslog shows ukbd0: Logitech USB Receiver, rev 1.10/21.00, addr 2, iclass 3/1 kbd1 at ukbd0 ums0: Logitech USB Receiver, rev 1.10/21.00, addr 2, iclass 3/1 ums0: 7 buttons and Z dir. and, when i plug the usb in, i see root 41884 0.0 0.1 1348 748 ?? Ss 2:07PM 0:00.00 /usr/sbin/moused -p /dev/ums0 -t auto randy, still confused From owner-freebsd-current@FreeBSD.ORG Sat Feb 5 22:22:48 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 04B8B16A4CE for ; Sat, 5 Feb 2005 22:22:48 +0000 (GMT) Received: from ran.psg.com (ip192.186.dsl-acs2.seawa0.iinet.com [209.20.186.192]) by mx1.FreeBSD.org (Postfix) with ESMTP id CBE6143D3F for ; Sat, 5 Feb 2005 22:22:47 +0000 (GMT) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=ran.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CxYKF-000P1U-Bu for freebsd-current@freebsd.org; Sat, 05 Feb 2005 14:22:47 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16901.18230.857308.262240@ran.psg.com> Date: Sat, 5 Feb 2005 14:22:46 -0800 To: FreeBSD Current References: <16901.13269.509134.918380@ran.psg.com> <16901.17655.58926.944428@ran.psg.com> Subject: Re: logitec usb wireless mouse X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Feb 2005 22:22:48 -0000 oh, and the same logitec hardware works fine when moved from my freebsd thinkpad t41 to a winxp thinkpad t40p. so the mouse has life in it, is bound to the wireless controller, ... randy From owner-freebsd-current@FreeBSD.ORG Sat Feb 5 22:27:05 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7528116A4CE for ; Sat, 5 Feb 2005 22:27:05 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id BBEDD43D46 for ; Sat, 5 Feb 2005 22:27:02 +0000 (GMT) (envelope-from gert.cuykens@gmail.com) Received: by rproxy.gmail.com with SMTP id f1so570428rne for ; Sat, 05 Feb 2005 14:26:58 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=cGiiwk26QBuaYBaGRf6ezgGe6WEsqw/rdA0HWoduGau9x+RFF5aWtewFssmC9v6ItN9DviIBJBDV+BdNURmRrN4k2/wu/97pk5xZloxXsYrzIoD8db0AUva+u3fLIyIMQl7/j287t7qcBWCeMo90d7s3JdBhY2Gk6A49VMEBSVU= Received: by 10.38.10.21 with SMTP id 21mr314036rnj; Sat, 05 Feb 2005 14:26:58 -0800 (PST) Received: by 10.38.74.23 with HTTP; Sat, 5 Feb 2005 14:26:58 -0800 (PST) Message-ID: Date: Sat, 5 Feb 2005 23:26:58 +0100 From: Gert Cuykens To: Randy Bush In-Reply-To: <16901.17568.508077.730828@ran.psg.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <16901.13269.509134.918380@ran.psg.com> <16901.17568.508077.730828@ran.psg.com> cc: FreeBSD Current Subject: Re: logitec usb wireless mouse X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Gert Cuykens List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Feb 2005 22:27:05 -0000 On Sat, 5 Feb 2005 14:11:44 -0800, Randy Bush wrote: > device "Mouse" > devname "ums[0-9]+" > attach "/usr/bin/killall moused; /usr/sbin/moused -p /dev/ums0 -t auto; /usr/sbin/vidcontrol -m on" > detach "/usr/bin/killall moused; /usr/sbin/moused -p /dev/psm0 -t auto; /usr/sbin/vidcontrol -m on" > device "Logitech Cordless Keyboard" > devname "ukbd0" > attach "/usr/sbin/kbdcontrol -k /dev/kbd1 < /dev/console" > detach "/usr/sbin/kbdcontrol -k /dev/kbd0 < /dev/console" > is this bad ? device "Mouse" devname "ums[0-9]+" attach "/usr/sbin/moused -p /dev/${DEVNAME} -I /var/run/moused.${DEVNAME}.pid; /usr/sbin/vidcontrol -m on" From owner-freebsd-current@FreeBSD.ORG Sat Feb 5 22:28:19 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C6A4316A4CE for ; Sat, 5 Feb 2005 22:28:19 +0000 (GMT) Received: from zircon.seattle.wa.us (dsl231-043-165.sea1.dsl.speakeasy.net [216.231.43.165]) by mx1.FreeBSD.org (Postfix) with SMTP id 4F5EF43D3F for ; Sat, 5 Feb 2005 22:28:19 +0000 (GMT) (envelope-from joe@zircon.seattle.wa.us) Received: (qmail 869 invoked from network); 5 Feb 2005 22:30:22 -0000 Received: from localhost (HELO localhost.zircon.seattle.wa.us) (127.0.0.1) by localhost with SMTP; 5 Feb 2005 22:30:22 -0000 From: Joe Kelsey To: Randy Bush In-Reply-To: <16901.17568.508077.730828@ran.psg.com> References: <16901.13269.509134.918380@ran.psg.com> <16901.17568.508077.730828@ran.psg.com> Content-Type: text/plain Date: Sat, 05 Feb 2005 14:30:22 -0800 Message-Id: <1107642622.669.6.camel@zircon.zircon.seattle.wa.us> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit cc: FreeBSD Current cc: Gert Cuykens Subject: Re: logitec usb wireless mouse X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Feb 2005 22:28:19 -0000 On Sat, 2005-02-05 at 14:11 -0800, Randy Bush wrote: > > moused_enable="NO" > > hmmm. i use moused all the time, as i switch back and forth from > touchpad to usb. You can have as many moused processes running at once as you want. > ahhhh. usbd is running moused for you. i hacked /etc/usbd.conf to > have > > device "Mouse" > devname "ums[0-9]+" > attach "/usr/bin/killall moused; /usr/sbin/moused -p /dev/ums0 -t auto; /usr/sbin/vidcontrol -m on" > detach "/usr/bin/killall moused; /usr/sbin/moused -p /dev/psm0 -t auto; /usr/sbin/vidcontrol -m on" > device "Logitech Cordless Keyboard" > devname "ukbd0" > attach "/usr/sbin/kbdcontrol -k /dev/kbd1 < /dev/console" > detach "/usr/sbin/kbdcontrol -k /dev/kbd0 < /dev/console" > > this switches back and forth between the built-in keyboard and the > usb keyboard brilliantly. but the mouse has a will of its own. This is really ridiculous. Leave all of the moused processes running at the same time. You can then use whichever mouse you want and /dev/sysmouse will multiplex them together. You can even use them all at the same time if you want. There is never any need to kill one moused, simply leave them all running. /dev/sysmouse multiplexes! I have done this when I first plugged in my usb mouse. I left my ps2 mouse plugged in and alternated mice until the usb mouse worked reliably. Eventually, I changed rc.conf to disable the ps2 mouse and eventually unplugged it. The only reason to hack usbd.conf is if you want to add arguments to moused, like I have for setting up left-handed buttons. /Joe From owner-freebsd-current@FreeBSD.ORG Sat Feb 5 22:40:10 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CD2EB16A4CE for ; Sat, 5 Feb 2005 22:40:10 +0000 (GMT) Received: from ran.psg.com (ip192.186.dsl-acs2.seawa0.iinet.com [209.20.186.192]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8354C43D2D for ; Sat, 5 Feb 2005 22:40:10 +0000 (GMT) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=ran.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CxYb4-000PU6-3x; Sat, 05 Feb 2005 14:40:10 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16901.19273.602314.354267@ran.psg.com> Date: Sat, 5 Feb 2005 14:40:09 -0800 To: Joe Kelsey References: <16901.13269.509134.918380@ran.psg.com> <16901.17568.508077.730828@ran.psg.com> <1107642622.669.6.camel@zircon.zircon.seattle.wa.us> cc: FreeBSD Current Subject: Re: logitec usb wireless mouse X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Feb 2005 22:40:10 -0000 >> device "Mouse" >> devname "ums[0-9]+" >> attach "/usr/bin/killall moused; /usr/sbin/moused -p /dev/ums0 -t auto; /usr/sbin/vidcontrol -m on" >> detach "/usr/bin/killall moused; /usr/sbin/moused -p /dev/psm0 -t auto; /usr/sbin/vidcontrol -m on" >> device "Logitech Cordless Keyboard" >> devname "ukbd0" >> attach "/usr/sbin/kbdcontrol -k /dev/kbd1 < /dev/console" >> detach "/usr/sbin/kbdcontrol -k /dev/kbd0 < /dev/console" > > Leave all of the moused processes running at the same time. You can > then use whichever mouse you want and /dev/sysmouse will multiplex them > together. if i leave the normal usbd.conf, with just device "Logitech Cordless Mouse" devname "ums[0-9]+" attach "/usr/sbin/moused -p /dev/${DEVNAME} -I /var/run/moused.${DEVNAME}.pid ; /usr/sbin/vidcontrol -m on" the usb mouse still does not work. root 41928 0.0 0.1 1348 748 ?? Ss 2:10PM 0:00.00 /usr/sbin/moused -p /dev/psm0 -t auto root 42064 0.0 0.1 1348 744 ?? Ss 2:37PM 0:00.00 /usr/sbin/moused -3 -p /dev/ums0 -t auto -I /var/run/moused.ums0.pi the keyboard does randy From owner-freebsd-current@FreeBSD.ORG Sat Feb 5 23:37:35 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B020E16A4CE; Sat, 5 Feb 2005 23:37:35 +0000 (GMT) Received: from obsecurity.dyndns.org (CPE0050040655c8-CM00111ae02aac.cpe.net.cable.rogers.com [69.199.47.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6624543D39; Sat, 5 Feb 2005 23:37:35 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 7106551240; Sat, 5 Feb 2005 15:37:34 -0800 (PST) Date: Sat, 5 Feb 2005 15:37:34 -0800 From: Kris Kennaway To: Kris Kennaway Message-ID: <20050205233734.GA96752@xor.obsecurity.org> References: <20050130094616.GA76093@peter.osted.lan> <20050202000613.GA9758@xor.obsecurity.org> <20050202001230.GA21847@xor.obsecurity.org> <20050202011157.GA55803@technokratis.com> <20050202023033.GA53440@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="SUOF0GtieIMvvwua" Content-Disposition: inline In-Reply-To: <20050202023033.GA53440@xor.obsecurity.org> User-Agent: Mutt/1.4.2.1i cc: bmilekic@freebsd.org cc: jroberson@chesapeake.net cc: Bosko Milekic cc: current@freebsd.org Subject: use-after-free in inodedep_lookup() (Re: Panic: Memory modified after free) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Feb 2005 23:37:35 -0000 --SUOF0GtieIMvvwua Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Feb 01, 2005 at 06:30:33PM -0800, Kris Kennaway wrote: > Anyway, it panicked shortly after starting to exercise the FS, with: >=20 > login: panic: mutex not owned at ../../../vm/vm_page.c:301 > cpuid =3D 1 > KDB: enter: panic > [thread pid 717 tid 100147 ] > Stopped at kdb_enter+0x30: leave > db> tr > Tracing pid 717 tid 100147 td 0xc7f27a10 > kdb_enter(c06fbf7a,1,c06fb4a2,eeca0968,c7f27a10) at kdb_enter+0x30 > panic(c06fb4a2,c82cb120,c071204f,12d,c46bae28) at panic+0x13e > _mtx_assert(c07c4ac0,1,c071204f,12d,ffffffe2) at _mtx_assert+0x7c > vm_page_busy(c46bae28,0,c0710c9d,155,eeca0a2c) at vm_page_busy+0x2d > vm_fault(c1059000,c566a000,2,0,c7f27a10) at vm_fault+0x6c3 > trap_pfault(eeca0b04,0,c566a008,eeca0af4,c566a008) at trap_pfault+0x166 > trap(c0510018,c07c0010,10,c81c0800,c563638c) at trap+0x34c > calltrap() at calltrap+0x5 > --- trap 0xc, eip =3D 0xc063af4a, esp =3D 0xeeca0b44, ebp =3D 0xeeca0b60 = --- > inodedep_lookup(c81c0800,180803,1,eeca0b78,0) at inodedep_lookup+0x143 (kgdb) list *(inodedep_lookup+0x143) 0xc063c362 is in inodedep_lookup (../../../ufs/ffs/ffs_softdep.c:887). 882 if (inodedep_find(inodedephd, fs, inum, inodedeppp)) { 883 FREE(inodedep, M_INODEDEP); 884 return (1); 885 } 886 num_inodedep +=3D 1; 887 inodedep->id_list.wk_type =3D D_INODEDEP; 888 inodedep->id_fs =3D fs; 889 inodedep->id_ino =3D inum; 890 inodedep->id_state =3D ALLCOMPLETE; 891 inodedep->id_nlinkdelta =3D 0; This looks like a use-after-free of the inodedep. Kris > softdep_change_linkcnt(c8c99000,e0ccd600,4600,eeca0b9c,eeca0ba0) at softd= ep_change_linkcnt+0x4f > ufs_dirremove(c8b0b4e0,c8c99000,100800c,0,0) at ufs_dirremove+0x153 > ufs_remove(eeca0c2c,c071c05e,2ac,c071c662,c8b0b4e0) at ufs_remove+0x60 > VOP_REMOVE_AP(eeca0c2c,eeca0c28,2,c06fdcb8,c81b7400) at VOP_REMOVE_AP+0x78 > kern_unlink(c7f27a10,80636a8,0,eeca0d40,c06b9eb6) at kern_unlink+0x186 > unlink(c7f27a10,eeca0d14,3a6,c07184c4,c7f27a10) at unlink+0x22 > syscall(2f,804002f,bfbf002f,1,804d000) at syscall+0x2c4 > Xint0x80_syscall() at Xint0x80_syscall+0x1f > --- syscall (10, FreeBSD ELF32, unlink), eip =3D 0x280c5b63, esp =3D 0xbf= bfec2c, ebp =3D 0xbfbfec58 --- >=20 > I don't know if this is a memguard bug or a FreeBSD bug. >=20 > Kris --SUOF0GtieIMvvwua Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCBVi+Wry0BWjoQKURAkDaAKC95/7P9sioNeiLo6TtXhWl2esrmwCg2oAd Czl8HcwtOeESr2U+a0usoXI= =IJVV -----END PGP SIGNATURE----- --SUOF0GtieIMvvwua-- From owner-freebsd-current@FreeBSD.ORG Sat Feb 5 23:44:23 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3C25316A4CE for ; Sat, 5 Feb 2005 23:44:23 +0000 (GMT) Received: from stephanie.unixdaemons.com (stephanie.unixdaemons.com [67.18.111.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id BFE3843D2D for ; Sat, 5 Feb 2005 23:44:22 +0000 (GMT) (envelope-from bmilekic@technokratis.com) Received: from stephanie.unixdaemons.com (bmilekic@localhost.unixdaemons.com [127.0.0.1])j15NiIPw084500; Sat, 5 Feb 2005 18:44:18 -0500 (EST) Received: (from bmilekic@localhost) by stephanie.unixdaemons.com (8.13.3/8.12.1/Submit) id j15NiIeV084499; Sat, 5 Feb 2005 18:44:18 -0500 (EST) (envelope-from bmilekic@technokratis.com) X-Authentication-Warning: stephanie.unixdaemons.com: bmilekic set sender to bmilekic@technokratis.com using -f Date: Sat, 5 Feb 2005 18:44:18 -0500 From: Bosko Milekic To: Kris Kennaway Message-ID: <20050205234418.GA83746@technokratis.com> References: <20050130094616.GA76093@peter.osted.lan> <20050202000613.GA9758@xor.obsecurity.org> <20050202001230.GA21847@xor.obsecurity.org> <20050202011157.GA55803@technokratis.com> <20050202023033.GA53440@xor.obsecurity.org> <20050205233734.GA96752@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050205233734.GA96752@xor.obsecurity.org> User-Agent: Mutt/1.4.2.1i cc: jroberson@chesapeake.net cc: current@freebsd.org Subject: Re: use-after-free in inodedep_lookup() (Re: Panic: Memory modified after free) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Feb 2005 23:44:23 -0000 On Sat, Feb 05, 2005 at 03:37:34PM -0800, Kris Kennaway wrote: > On Tue, Feb 01, 2005 at 06:30:33PM -0800, Kris Kennaway wrote: > > > Anyway, it panicked shortly after starting to exercise the FS, with: > > > > login: panic: mutex not owned at ../../../vm/vm_page.c:301 > > cpuid = 1 > > KDB: enter: panic > > [thread pid 717 tid 100147 ] > > Stopped at kdb_enter+0x30: leave > > db> tr > > Tracing pid 717 tid 100147 td 0xc7f27a10 > > kdb_enter(c06fbf7a,1,c06fb4a2,eeca0968,c7f27a10) at kdb_enter+0x30 > > panic(c06fb4a2,c82cb120,c071204f,12d,c46bae28) at panic+0x13e > > _mtx_assert(c07c4ac0,1,c071204f,12d,ffffffe2) at _mtx_assert+0x7c > > vm_page_busy(c46bae28,0,c0710c9d,155,eeca0a2c) at vm_page_busy+0x2d > > vm_fault(c1059000,c566a000,2,0,c7f27a10) at vm_fault+0x6c3 > > trap_pfault(eeca0b04,0,c566a008,eeca0af4,c566a008) at trap_pfault+0x166 > > trap(c0510018,c07c0010,10,c81c0800,c563638c) at trap+0x34c > > calltrap() at calltrap+0x5 > > --- trap 0xc, eip = 0xc063af4a, esp = 0xeeca0b44, ebp = 0xeeca0b60 --- > > inodedep_lookup(c81c0800,180803,1,eeca0b78,0) at inodedep_lookup+0x143 > > (kgdb) list *(inodedep_lookup+0x143) > 0xc063c362 is in inodedep_lookup (../../../ufs/ffs/ffs_softdep.c:887). > 882 if (inodedep_find(inodedephd, fs, inum, inodedeppp)) { > 883 FREE(inodedep, M_INODEDEP); > 884 return (1); > 885 } > 886 num_inodedep += 1; > 887 inodedep->id_list.wk_type = D_INODEDEP; > 888 inodedep->id_fs = fs; > 889 inodedep->id_ino = inum; > 890 inodedep->id_state = ALLCOMPLETE; > 891 inodedep->id_nlinkdelta = 0; > > This looks like a use-after-free of the inodedep. > > Kris To elaborate a bit: the inodedep deref on line 887 triggers a fault because MemGuard has protected the page but the fault handling code panics while attempting to assert that the underlying object's mutex is owned. The assertion is triggered as the mutex is not owned presumably because the object has been freed (it might be cached somewhere which explains why the deref of it did not trigger a second fault). > > softdep_change_linkcnt(c8c99000,e0ccd600,4600,eeca0b9c,eeca0ba0) at softdep_change_linkcnt+0x4f > > ufs_dirremove(c8b0b4e0,c8c99000,100800c,0,0) at ufs_dirremove+0x153 > > ufs_remove(eeca0c2c,c071c05e,2ac,c071c662,c8b0b4e0) at ufs_remove+0x60 > > VOP_REMOVE_AP(eeca0c2c,eeca0c28,2,c06fdcb8,c81b7400) at VOP_REMOVE_AP+0x78 > > kern_unlink(c7f27a10,80636a8,0,eeca0d40,c06b9eb6) at kern_unlink+0x186 > > unlink(c7f27a10,eeca0d14,3a6,c07184c4,c7f27a10) at unlink+0x22 > > syscall(2f,804002f,bfbf002f,1,804d000) at syscall+0x2c4 > > Xint0x80_syscall() at Xint0x80_syscall+0x1f > > --- syscall (10, FreeBSD ELF32, unlink), eip = 0x280c5b63, esp = 0xbfbfec2c, ebp = 0xbfbfec58 --- > > > > I don't know if this is a memguard bug or a FreeBSD bug. > > > > Kris -- Bosko Milekic bmilekic@technokratis.com bmilekic@FreeBSD.org