From owner-freebsd-current@FreeBSD.ORG Sun Jul 15 04:25:08 2007 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1065316A402 for ; Sun, 15 Jul 2007 04:25:08 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with SMTP id A712013C441 for ; Sun, 15 Jul 2007 04:25:07 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 349 invoked by uid 399); 15 Jul 2007 04:25:07 -0000 Received: from localhost (HELO lap.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTP; 15 Jul 2007 04:25:07 -0000 X-Originating-IP: 127.0.0.1 Message-ID: <4699A1A1.8070603@FreeBSD.org> Date: Sat, 14 Jul 2007 21:25:05 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.4 (X11/20070617) MIME-Version: 1.0 To: Robert Watson References: <20070714181315.V67691@fledge.watson.org> In-Reply-To: <20070714181315.V67691@fledge.watson.org> X-Enigmail-Version: 0.95.1 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: current@FreeBSD.org Subject: Re: HEADS UP: netatm disabling taking place shortly X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Jul 2007 04:25:08 -0000 Robert, This is cool stuff, thanks for your dogged persistence in eliminating GIANT from the network stack! One tiny thing I've noticed doing a buildworld tonight, because of the way that /usr/src/usr.bin/kdump/mkioctls works (starting at line 19) it's necessary to remove /usr/include/netatm _before_ trying to build. You might want to include that in any instructions you send out regarding this change (and maybe in UPDATING). If I've missed where you've said that already, sorry for the noise. Doug -- This .signature sanitized for your protection From owner-freebsd-current@FreeBSD.ORG Sun Jul 15 08:30:53 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 45FB616A401 for ; Sun, 15 Jul 2007 08:30:53 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.185]) by mx1.freebsd.org (Postfix) with ESMTP id 7842813C441 for ; Sun, 15 Jul 2007 08:30:52 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: by mu-out-0910.google.com with SMTP id w9so1075826mue for ; Sun, 15 Jul 2007 01:30:51 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:received:received:date:from:to:cc:subject:message-id:mail-followup-to:mime-version:content-type:content-disposition:user-agent; b=lbxcjPRl5R72yWVBVJxWOZ6e876+ZyYIioVy6vmSBSiDKujqo+d3J4oEeOaR98099z2VHDmZErcaw0YEtXwhpxoq93j9ani682SC4/P/LFUMawj7/njY24afCYbRjvywhwPS2yquUDecsiYlKniawLwyM11kKg278vqd5UdrU24= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:date:from:to:cc:subject:message-id:mail-followup-to:mime-version:content-type:content-disposition:user-agent; b=YKRtPHmAX4zyMdpeNCqBiUgfLYXvULA5jVM+68Eagv28NQPdORJsz+xYYu1/h1M1nUEswDw/ROdbwMn7W9GzKT35v7XpFktdYKZHxLmuYa71hv9U5b9tYJkJ/46bo0yIw/TtsZt5GijxmG0zizmCBRYshWb6pVF1L9r3TaG/EAs= Received: by 10.86.28.5 with SMTP id b5mr2682071fgb.1184488251176; Sun, 15 Jul 2007 01:30:51 -0700 (PDT) Received: from roadrunner.q.local ( [85.180.167.127]) by mx.google.com with ESMTP id 13sm7598898fks.2007.07.15.01.30.50 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 15 Jul 2007 01:30:50 -0700 (PDT) Received: from roadrunner.q.local (localhost [127.0.0.1]) by roadrunner.q.local (8.14.1/8.14.1) with ESMTP id l6F8Ul3C002877; Sun, 15 Jul 2007 10:30:47 +0200 (CEST) (envelope-from uspoerlein@gmail.com) Received: (from q@localhost) by roadrunner.q.local (8.14.1/8.14.1/Submit) id l6F8UkcT002876; Sun, 15 Jul 2007 10:30:46 +0200 (CEST) (envelope-from uspoerlein@gmail.com) Date: Sun, 15 Jul 2007 10:30:46 +0200 From: Ulrich Spoerlein To: current@freebsd.org Message-ID: <20070715083046.GA2819@roadrunner.q.local> Mail-Followup-To: current@freebsd.org, des@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.15 (2007-04-06) Cc: des@freebsd.org Subject: pam.d and ssh-agent no longer working X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Jul 2007 08:30:53 -0000 Hi, on a fairly recent CURRENT, the ssh-agent started by pam.d/login no longer loads the identity. This was working just fine till a few days ago. pam.d/system auth sufficient pam_ssh.so no_warn try_first_pass auth sufficient /usr/local/lib/pam_ldap.so no_warn use_first_pass auth required pam_unix.so no_warn use_first_pass nullok pam.d/login # session session required pam_ssh.so want_agent session include system Upon login with the SSH passphrase (which works!) an agent is running, but no identity is loaded. % pgrep -fl agent 1342 ssh_agent -s 1341 ssh-agent % ssh-add -l The agent has no identities. (1)% I then have to ssh-add(1) and everything is working fine from then on. Are other people seeing this, too? How should I go about debugging this? Cheers, Ulrich Spoerlein -- "The trouble with the dictionary is you have to know how the word is spelled before you can look it up to see how it is spelled." -- Will Cuppy From owner-freebsd-current@FreeBSD.ORG Sun Jul 15 09:37:58 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B443816A401 for ; Sun, 15 Jul 2007 09:37:58 +0000 (UTC) (envelope-from dominique.goncalves@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.226]) by mx1.freebsd.org (Postfix) with ESMTP id 7046D13C442 for ; Sun, 15 Jul 2007 09:37:58 +0000 (UTC) (envelope-from dominique.goncalves@gmail.com) Received: by wx-out-0506.google.com with SMTP id i29so717233wxd for ; Sun, 15 Jul 2007 02:37:57 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Yf5YMQ/F+3uWnMpe6G7bTKwz3BVseQpe+xTC0rvfS9CuAvpfFxfhmbvJIY/s0htPl6a8mfuqiLD+yKO5yAxTAYG7K67jCqghHi1fuGM7Tm+Dmqx1trm4ViWiENZ16K8ViHFoq3jPm5prO5Itj1vz9xchPJELkcydYWYmc1Y1vhU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=iIV8jBRfjiaZnvL35j78tLc+0DQWrlq7S5pmZ9TxAB4zib1d2Sj4Oedq1g63XcfXLQgGTMbOPjhydhvzmpx6aBIm/zJYp2qpBmCOZojM1PxRfAlANCDFiU1FnnDARCoL6es0fBquuMyfoj/ThX+Vw4MXE2QHiWf0sBQkcaVh03E= Received: by 10.90.49.1 with SMTP id w1mr2505329agw.1184492277759; Sun, 15 Jul 2007 02:37:57 -0700 (PDT) Received: by 10.90.78.16 with HTTP; Sun, 15 Jul 2007 02:37:57 -0700 (PDT) Message-ID: <7daacbbe0707150237gc869abdi756d54219edb2577@mail.gmail.com> Date: Sun, 15 Jul 2007 11:37:57 +0200 From: "Dominique Goncalves" To: "Ivan Voras" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070709214216.GA72912@walton.maths.tcd.ie> <20070711132202.GA95487@walton.maths.tcd.ie> <20070712085135.GA5332@walton.maths.tcd.ie> Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: Debugging times X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Jul 2007 09:37:58 -0000 Hi, On 7/13/07, Ivan Voras wrote: > David Malone wrote: > > > Ah - that's interesting. Could you look for the comment in > > src/sys/i386/isa/clock.c that says: > > > > /* Should we set dow = -1 because some clocks don't set it correctly? */ > > > > and add a line afterwards to say: > > > > ct.dow = -1; > > > > and see if that helps? > > Yes, it does! Setting ct.dow to -1 fixes the time in a correct way. It works also for me with qemu 0.9.0. Thanks. > I vote this gets committed as soon as possible :) > > _______________________________________________ > 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" > Regards. -- There's this old saying: "Give a man a fish, feed him for a day. Teach a man to fish, feed him for life." From owner-freebsd-current@FreeBSD.ORG Sun Jul 15 10:40:41 2007 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BF62416A402; Sun, 15 Jul 2007 10:40:41 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 9A1A613C471; Sun, 15 Jul 2007 10:40:41 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id D0263490C6; Sun, 15 Jul 2007 06:40:40 -0400 (EDT) Date: Sun, 15 Jul 2007 11:40:40 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Doug Barton In-Reply-To: <4699A1A1.8070603@FreeBSD.org> Message-ID: <20070715113916.M91807@fledge.watson.org> References: <20070714181315.V67691@fledge.watson.org> <4699A1A1.8070603@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: current@FreeBSD.org Subject: Re: HEADS UP: netatm disabling taking place shortly X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Jul 2007 10:40:41 -0000 On Sat, 14 Jul 2007, Doug Barton wrote: > This is cool stuff, thanks for your dogged persistence in eliminating GIANT > from the network stack! > > One tiny thing I've noticed doing a buildworld tonight, because of the way > that /usr/src/usr.bin/kdump/mkioctls works (starting at line 19) it's > necessary to remove /usr/include/netatm _before_ trying to build. You might > want to include that in any instructions you send out regarding this change > (and maybe in UPDATING). If I've missed where you've said that already, > sorry for the noise. It's odd, actually -- I ran into this a couple of times earlier in preparing the patch, but didn't run into it with later versions after I redid the include things, etc. For example, on a vanilla machine (from a couple of weeks ago) now, I don't see the problem during buildworld. Obviously, a bit more debugging is called for. Could you try removing the tree in /usr/obj and see if that helps? Perhaps things are lasting between build runs... Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Sun Jul 15 10:58:14 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6A0E716A405 for ; Sun, 15 Jul 2007 10:58:14 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.249]) by mx1.freebsd.org (Postfix) with ESMTP id 2ABF113C461 for ; Sun, 15 Jul 2007 10:58:13 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: by an-out-0708.google.com with SMTP id c14so213551anc for ; Sun, 15 Jul 2007 03:58:13 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=dQHTfQ5dS9S7PlE2Io5l2ypPERMhkESER/eQmnRboXJISUiQv6B734wtm9fBLX/rD2goxRB8sAtzoe502QweOW7wkp7ud+JT40ZXcCn+mHxpZGPsJ2pcSWqiSxi4Fn+4lvvqMXZg1Idp7085B7jB5WlVKUllZx4RQs/XlI0K7WU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=fF1OHHe0Vg+crXps0hF+EV6LWGdgS2du62Otj6cerrgOvrCVKzGXu/thfxSbnV3hYN2775zf/pFrXp3WI91b4wt8TQjspktfR/Jv38ji7ZXJgjNd1LVY6XU16ZPlt5nD1KONTjY1bQMuuPUU4n50kjt3az5RQMnhggk26heykvc= Received: by 10.100.168.13 with SMTP id q13mr1770526ane.1184495552544; Sun, 15 Jul 2007 03:32:32 -0700 (PDT) Received: by 10.100.141.14 with HTTP; Sun, 15 Jul 2007 03:32:32 -0700 (PDT) Message-ID: <790a9fff0707150332u2502a491s91f19d4303bf82a6@mail.gmail.com> Date: Sun, 15 Jul 2007 05:32:32 -0500 From: "Scot Hetzel" To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: stopping ndis caused fatal trap 12 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Jul 2007 10:58:14 -0000 hp010# uname -a FreeBSD hp010 7.0-CURRENT FreeBSD 7.0-CURRENT #0: Sat Jul 14 02:20:09 CDT 2007 root@hp010:/usr/src/7x/sys-p4/amd64/compile/GENERIC.debug amd64 I was testing wpa_supplicant at work, and couldn't get it to associate with the network (open, no encryption), and so I had hardcoded the network. When I went home and booted the system, it still had the hardcoded wireless network configured. I then did a netif stop ndis0, made the change to set ndis to "WPA DHCP", then when I used 'netif start ndis0', it didn't obtain an IP. So I performed an 'netif stop ndis0' and received the following panic: #/etc/rc.d/netif stop ndis0 Stopping network: Stopping wpa_supplicant waiting for PIDS: 474Jul 15 01:28:08 hp010 dhclient[1424]: connection closed Jul 15 01:28:08 hp010 dhclient[1424]: exiting Kernel page fault with the following non-sleepable locks held: exclusive sleep mutex HAL preemption lock (HAL lock) r = 0 (0xffffffff80dde3c0) locked @ /usr/src/7x/sys-p4/modules/ndis/../../compat/ndis/subr_hal.c:423 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a witness_warn() at witness_warn+0x24b trap() at trap+0x26e calltrap() at calltrap+0x8 --- trap 0xc, rip = 0xffffffff80d0269a, rsp = 0xffffffffa45036c0, rbp = 0xffffffffa4503820 --- bcmwl564_sys_drv_data_start() at 0xffffffff80d0269a ndis_stop() at ndis_stop+0x9f ndis_init() at ndis_init+0x40 ndis_ioctl() at ndis_ioctl+0x173 ifhwioctl() at ifhwioctl+0x75f ifioctl() at ifioctl+0xb0 soo_ioctl() at soo_ioctl+0x3ad kern_ioctl() at kern_ioctl+0xa3 ioctl() at ioctl+0xf1 syscall() at syscall+0x1ca Xfast_syscall() at Xfast_syscall+0xab --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x8008276fc, rsp = 0x7fffffffe4e8, rbp = 0x1 --- Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0xffffffff816e46c8 fault code = supervisor read data, page not present instruction pointer = 0x8:0xffffffff80d0269a stack pointer = 0x10:0xffffffffa45036c0 frame pointer = 0x10:0xffffffffa4503820 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 1513 (ifconfig) [thread pid 1513 tid 100095] Stopped at 0xffffffff80d0269a: movq 0x16c8(%rdi), %rax ------- >From compat/ndis/subr_hal.c: 409 uint8_t 410 KfRaiseIrql(irql) 411 uint8_t irql; 412 { 413 uint8_t oldirql; 414 415 oldirql = KeGetCurrentIrql(); 416 417 /* I am so going to hell for this. */ 418 if (oldirql > irql) 419 panic("IRQL_NOT_LESS_THAN"); 420 421 if (oldirql != DISPATCH_LEVEL) { 422 sched_pin(); 423 mtx_lock(&disp_lock[curthread->td_oncpu]); 424 } 425 /*printf("RAISE IRQL: %d %d\n", irql, oldirql);*/ 426 427 return(oldirql); 428 } ---- (kgdb) bt #0 doadump () at pcpu.h:194 During symbol reading, Incomplete CFI data; unspecified registers at 0xffffffff804745bc. #1 0xffffffff80474ad6 in boot (howto=0x104) at ../../../kern/kern_shutdown.c:409 #2 0xffffffff80474f57 in panic (fmt=Variable "fmt" is not available. ) at ../../../kern/kern_shutdown.c:563 During symbol reading, unsupported tag: 'DW_TAG_const_type'. #3 0xffffffff801b9837 in db_panic (addr=Variable "addr" is not available. ) at ../../../ddb/db_command.c:433 #4 0xffffffff801ba11c in db_command_loop () at ../../../ddb/db_command.c:401 #5 0xffffffff801bbb5f in db_trap (type=Variable "type" is not available. ) at ../../../ddb/db_main.c:222 #6 0xffffffff8049bd90 in kdb_trap (type=0xc, code=0x0, tf=0xffffffffa4503610) at ../../../kern/subr_kdb.c:502 #7 0xffffffff806e482d in trap_fatal (frame=0xffffffffa4503610, eva=Variable "eva" is not available. ) at ../../../amd64/amd64/trap.c:690 #8 0xffffffff806e54b6 in trap (frame=0xffffffffa4503610) at ../../../amd64/amd64/trap.c:247 #9 0xffffffff806cbc9e in calltrap () at ../../../amd64/amd64/exception.S:169 #10 0xffffffff80d0269a in ?? () #11 0xffffffffa45036f0 in ?? () #12 0xffffffff80dd57d2 in KeAcquireSpinLockAtDpcLevel (lock=0xffffffffa4503770) at /usr/src/7x/sys-p4/modules/ndis/../../compat/ndis/subr_ntoskrnl.c:2374 #13 0xffffffff80df51ef in ndis_stop () #14 0xffffffff80df6790 in ndis_init (xsc=Variable "xsc" is not available. ) at /usr/src/7x/sys-p4/modules/if_ndis/../../dev/if_ndis/if_ndis.c:1928 #15 0xffffffff80df9983 in ndis_ioctl (ifp=0xffffff0001169000, command=Variable "command" is not available. ) at /usr/src/7x/sys-p4/modules/if_ndis/../../dev/if_ndis/if_ndis.c:2848 #16 0xffffffff80506acf in ifhwioctl (cmd=0x80206910, ifp=0xffffff0001169000, data=0xffffff0001f56680 "ndis0", td=Variable "td" is not available. ) at ../../../net/if.c:1590 #17 0xffffffff805086f0 in ifioctl (so=0xffffff0001dbc570, cmd=0x80206910, data=0xffffff0001f56680 "ndis0", td=0xffffff0001dee340) at ../../../net/if.c:1880 #18 0xffffffff804b3dbd in soo_ioctl (fp=Variable "fp" is not available. ) at ../../../kern/sys_socket.c:202 #19 0xffffffff804adf03 in kern_ioctl (td=0xffffff0001dee340, fd=0x3, com=0x80206910, data=0xffffff0001f56680 "ndis0") at file.h:266 #20 0xffffffff804ae161 in ioctl (td=0xffffff0001dee340, uap=0xffffffffa4503be0) at ../../../kern/sys_generic.c:570 #21 0xffffffff806e4d7a in syscall (frame=0xffffffffa4503c70) at ../../../amd64/amd64/trap.c:820 #22 0xffffffff806cbe4b in Xfast_syscall () at ../../../amd64/amd64/exception.S:272 #23 0x00000008008276fc in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) Let me know if there is any more debug info I can provide for this crash. Scot PS: I tried to reproduce the problem, and wasn't able to reproduce it. -- DISCLAIMER: No electrons were mamed while sending this message. Only slightly bruised. From owner-freebsd-current@FreeBSD.ORG Sun Jul 15 11:06:31 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 028FA16A402 for ; Sun, 15 Jul 2007 11:06:31 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from heff.fud.org.nz (203-109-251-39.static.bliink.ihug.co.nz [203.109.251.39]) by mx1.freebsd.org (Postfix) with ESMTP id 8975E13C461 for ; Sun, 15 Jul 2007 11:06:30 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: by heff.fud.org.nz (Postfix, from userid 1001) id 551A51CC58; Sun, 15 Jul 2007 23:06:29 +1200 (NZST) Date: Sun, 15 Jul 2007 23:06:29 +1200 From: Andrew Thompson To: Scot Hetzel Message-ID: <20070715110629.GI95956@heff.fud.org.nz> References: <790a9fff0707150332u2502a491s91f19d4303bf82a6@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <790a9fff0707150332u2502a491s91f19d4303bf82a6@mail.gmail.com> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: freebsd-current@freebsd.org Subject: Re: stopping ndis caused fatal trap 12 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Jul 2007 11:06:31 -0000 On Sun, Jul 15, 2007 at 05:32:32AM -0500, Scot Hetzel wrote: > hp010# uname -a > FreeBSD hp010 7.0-CURRENT FreeBSD 7.0-CURRENT #0: Sat Jul 14 02:20:09 > CDT 2007 root@hp010:/usr/src/7x/sys-p4/amd64/compile/GENERIC.debug > amd64 > > I was testing wpa_supplicant at work, and couldn't get it to associate > with the network (open, no encryption), and so I had hardcoded the > network. When I went home and booted the system, it still had the > hardcoded wireless network configured. I then did a netif stop ndis0, > made the change to set ndis to "WPA DHCP", then when I used 'netif > start ndis0', it didn't obtain an IP. So I performed an 'netif stop > ndis0' and received the following panic: > > #/etc/rc.d/netif stop ndis0 > Stopping network: Stopping wpa_supplicant > waiting for PIDS: 474Jul 15 01:28:08 hp010 dhclient[1424]: connection closed > Jul 15 01:28:08 hp010 dhclient[1424]: exiting > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0xffffffff816e46c8 > fault code = supervisor read data, page not present > instruction pointer = 0x8:0xffffffff80d0269a > stack pointer = 0x10:0xffffffffa45036c0 > frame pointer = 0x10:0xffffffffa4503820 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 1513 (ifconfig) > [thread pid 1513 tid 100095] > Stopped at 0xffffffff80d0269a: movq 0x16c8(%rdi), %rax > > Let me know if there is any more debug info I can provide for this crash. As far as I can tell from recently working on the 80211 part of ndis, the code seems to lack large parts of locking. The code really needs someone to go through and check this, and hopefully maintain it in the long term. So back to the ndis association problem. Did the card find the access point? you can list the scan cache from 'ifconfig ndis0 list scan'. > PS: I tried to reproduce the problem, and wasn't able to reproduce it. Its most likely a race condition, the problem will still be there :) From owner-freebsd-current@FreeBSD.ORG Sun Jul 15 08:38:07 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 61B6016A401 for ; Sun, 15 Jul 2007 08:38:07 +0000 (UTC) (envelope-from braun.sven@googlemail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.171]) by mx1.freebsd.org (Postfix) with ESMTP id E2C5513C441 for ; Sun, 15 Jul 2007 08:38:06 +0000 (UTC) (envelope-from braun.sven@googlemail.com) Received: by ug-out-1314.google.com with SMTP id o4so897864uge for ; Sun, 15 Jul 2007 01:38:05 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=googlemail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=LLOx0zUe51CoyoZHSpncjGVft31YCozHedotOZwCe+dyZMr/m2E//pjEkbdhkZkG7yowYYEPsZhcRSzYiPASj80hLLQlWU8ygrbnnmIwiik+7be6dv11zEZQF8+AETI0dxE/nA/5DrPv70tHXgsGovvSndXBlIQ5VnJ5pfIG9mk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=VxNh4csXc7hgtuYRl4k5rr2l8u5wVy5fv1cpZOXsJdj6oNQXTC9LGpBWX7p1gawSi4mPVThdpmXC2wWQUzIrOfHlV+e83TsizcNDicp026no3DewT/1+uquX+fHrDq5vDDNcRTO818kb0wmlpu2i+O3G2VLc5oYe3m7a2pXIiuQ= Received: by 10.67.88.17 with SMTP id q17mr3393742ugl.1184487037601; Sun, 15 Jul 2007 01:10:37 -0700 (PDT) Received: by 10.66.244.9 with HTTP; Sun, 15 Jul 2007 01:10:37 -0700 (PDT) Message-ID: Date: Sun, 15 Jul 2007 10:10:37 +0200 From: "Sven Braun" To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Mailman-Approved-At: Sun, 15 Jul 2007 11:49:08 +0000 Subject: Problems with ath_hal-20070428 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Jul 2007 08:38:07 -0000 Hello everybody, I downloaded ath_hal-20070428.tgz by Sam Leffler and hoped it will work with my Atheros AR5008 in my Macbook, 2nd generation. I went ahead in the following way: fetch http://people.freebsd.org/~sam/ath_hal-20070428.tgz tar xfz ath_hal-20070428.tgz cd ath_hal-20070428 cp -R *.* /usr/src/sys/contrib/dev/ath/ cd /usr/src make buildkernel and got the following error: rm -f hack.c MAKE=make sh /usr/src/sys/conf/newvers.sh MACBOOK cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror vers.c linking kernel.debug if_ath.o(.text+0x6b98): In function 'ath_getchannels': /usr/src/sys/dev/ath/if_ath.c:5490: undefined reference to 'ath_hal_isgsmsku' *** Error code 1 Stop in /usr/obj/usr/src/sys/MACBOOK. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. I tried to fix the problem, but my C programming skills are unfortunately low, so I ask you: Do you know how to fix the problem? Thanks in advance, Sven Braun From owner-freebsd-current@FreeBSD.ORG Sun Jul 15 15:00:32 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5426C16A400 for ; Sun, 15 Jul 2007 15:00:32 +0000 (UTC) (envelope-from thomas@bledge.tmseck.homedns.org) Received: from smtp4.netcologne.de (smtp4.netcologne.de [194.8.194.137]) by mx1.freebsd.org (Postfix) with ESMTP id 13DC513C4B3 for ; Sun, 15 Jul 2007 15:00:31 +0000 (UTC) (envelope-from thomas@bledge.tmseck.homedns.org) Received: from laurel.tmseck.homedns.org (xdsl-81-173-231-20.netcologne.de [81.173.231.20]) by smtp4.netcologne.de (Postfix) with SMTP id 097B8DA6EA for ; Sun, 15 Jul 2007 16:38:26 +0200 (CEST) Received: (qmail 739 invoked from network); 15 Jul 2007 14:38:26 -0000 Received: from unknown (HELO bledge.tmseck.homedns.org) (192.168.1.4) by 0 with SMTP; 15 Jul 2007 14:38:26 -0000 Received: from bledge.tmseck.homedns.org (localhost [127.0.0.1]) by bledge.tmseck.homedns.org (8.14.1/8.14.1) with ESMTP id l6FEcPko038144; Sun, 15 Jul 2007 16:38:25 +0200 (CEST) (envelope-from thomas@bledge.tmseck.homedns.org) Received: (from thomas@localhost) by bledge.tmseck.homedns.org (8.14.1/8.14.1/Submit) id l6FEcO0D038114; Sun, 15 Jul 2007 16:38:24 +0200 (CEST) (envelope-from thomas) Date: Sun, 15 Jul 2007 16:38:24 +0200 (CEST) Message-Id: <200707151438.l6FEcO0D038114@bledge.tmseck.homedns.org> From: tmseck-lists@netcologne.de (Thomas-Martin Seck) To: freebsd-current@freebsd.org In-Reply-To: <20070715113916.M91807@fledge.watson.org> X-Newsgroups: gmane.os.freebsd.current X-Attribution: tms Subject: Re: HEADS UP: netatm disabling taking place shortly X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Jul 2007 15:00:32 -0000 * Robert Watson [gmane.os.freebsd.current]: > > On Sat, 14 Jul 2007, Doug Barton wrote: > >> This is cool stuff, thanks for your dogged persistence in eliminating GIANT >> from the network stack! >> >> One tiny thing I've noticed doing a buildworld tonight, because of the way >> that /usr/src/usr.bin/kdump/mkioctls works (starting at line 19) it's >> necessary to remove /usr/include/netatm _before_ trying to build. You might >> want to include that in any instructions you send out regarding this change >> (and maybe in UPDATING). If I've missed where you've said that already, >> sorry for the noise. > > It's odd, actually -- I ran into this a couple of times earlier in preparing > the patch, but didn't run into it with later versions after I redid the > include things, etc. For example, on a vanilla machine (from a couple of > weeks ago) now, I don't see the problem during buildworld. Obviously, a bit > more debugging is called for. Could you try removing the tree in /usr/obj and > see if that helps? Perhaps things are lasting between build runs... The error is probably caused by stale includes in /usr/obj/usr/src/tmp/usr/include. This should only happen when one builds with NO_CLEAN defined. From owner-freebsd-current@FreeBSD.ORG Sun Jul 15 15:02:36 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B4EF116A406 for ; Sun, 15 Jul 2007 15:02:36 +0000 (UTC) (envelope-from gabor@zahemszky.hu) Received: from mail.integrity.hu (mail.integrity.hu [195.56.44.40]) by mx1.freebsd.org (Postfix) with SMTP id 510E013C47E for ; Sun, 15 Jul 2007 15:02:35 +0000 (UTC) (envelope-from gabor@zahemszky.hu) Received: (qmail 21388 invoked by uid 89); 15 Jul 2007 16:35:55 +0200 Message-ID: <20070715143555.21387.qmail@mail.integrity.hu> From: "Zahemszky Gabor" To: freebsd-current@freebsd.org Date: Sun, 15 Jul 2007 16:35:55 +0200 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2"; format=flowed Content-Transfer-Encoding: 7bit X-Sender: gabor@zahemszky.hu X-Mailman-Approved-At: Sun, 15 Jul 2007 15:08:23 +0000 Subject: SATA DVD-RW / X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Jul 2007 15:02:36 -0000 Hi! Are there anybody who can suggest a working SATA DVD-RW (+DL, -DL, if it's possible), which works well with FreeBSD? (Current, as my new machine's Marvell-ATA chipset doesn't work under 6-stable.) Thanks, Gabor < Gabor at Zahemszky dot HU > From owner-freebsd-current@FreeBSD.ORG Sun Jul 15 15:43:47 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F207716A400 for ; Sun, 15 Jul 2007 15:43:47 +0000 (UTC) (envelope-from michiel@boland.org) Received: from neerbosch.nijmegen.internl.net (neerbosch.nijmegen.internl.net [217.149.193.38]) by mx1.freebsd.org (Postfix) with ESMTP id 8DF4B13C467 for ; Sun, 15 Jul 2007 15:43:47 +0000 (UTC) (envelope-from michiel@boland.org) Received: from neerbosch.nijmegen.internl.net by neerbosch.nijmegen.internl.net via neerbosch.nijmegen.internl.net [217.149.193.38] with ESMTP for id l6FFhjqC007431 (8.13.4/1.4); Sun, 15 Jul 2007 17:43:45 +0200 (MEST) Received: from localhost by neerbosch.nijmegen.internl.net via mboland@localhost with ESMTP for id l6FFhjcu007427 (8.13.4/2.02); Sun, 15 Jul 2007 17:43:45 +0200 (MEST) X-Authentication-Warning: neerbosch.nijmegen.internl.net: mboland owned process doing -bs Date: Sun, 15 Jul 2007 17:43:45 +0200 (MEST) From: Michiel Boland To: freebsd-current@freebsd.org In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: sshd broken with UsePrivilegeSeparation=yes on sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jul 2007 15:43:48 -0000 It looks like gcc mis-compiles /usr/src/crypto/openssh/monitor_fdpass.c on sparc64. For some reason it optimizes away the assignment of fd on line 132: fd = (*(int *)CMSG_DATA(cmsg)); So I guess that every call to mm_receive_fd will return an undefined value. If I add -O0 to CFLAGS in /usr/src/secure/lib/libssh/Makefile, ssh with UsePrivilegeSeparation=yes works again. So, obviously a gcc bug. I will try to generate a smaller test-case for this. From owner-freebsd-current@FreeBSD.ORG Sun Jul 15 16:00:51 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id ECC0A16A407 for ; Sun, 15 Jul 2007 16:00:51 +0000 (UTC) (envelope-from koolguy317@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.234]) by mx1.freebsd.org (Postfix) with ESMTP id AF17613C4B4 for ; Sun, 15 Jul 2007 16:00:51 +0000 (UTC) (envelope-from koolguy317@gmail.com) Received: by wx-out-0506.google.com with SMTP id i29so764276wxd for ; Sun, 15 Jul 2007 09:00:51 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=NjSUVwzqvlmafdYYT9MinXUuz+fNnsqnHFl3M7Vh3EfBkoxo0Efz4lMoTz9uVomeeTy7DTFcHRe7CxdQ0zYV5YjVYgGiKjDXk/qFCI9tySR2LArU22RPx9xJT6eEYT5RRILQ9iDpvf8KjuWjjtOoTImKYF4N1RIE8SmdyP0Fmjs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=dXsbuWw7YmX+0myLgZuCnSXxWxtHLYqu97nRsnj8qiY0UOpIi17iKGbVlwrmyMirChlXZJ2maVxWw2mxOzCuB2ZeiD0OMlksaxgGpehpcTncQSrm0uqUkbUab/B4kca5+zNXYi7EBCXDhZ5acaF5+DMP2sYx7izQiMG5AC4DEo4= Received: by 10.90.81.14 with SMTP id e14mr2593301agb.1184513639986; Sun, 15 Jul 2007 08:33:59 -0700 (PDT) Received: by 10.90.30.11 with HTTP; Sun, 15 Jul 2007 08:33:59 -0700 (PDT) Message-ID: <88afd9200707150833t26621cbar6286a30b7c1bd371@mail.gmail.com> Date: Sun, 15 Jul 2007 11:33:59 -0400 From: "Kool Guy" To: current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Subject: AMD 64 Status X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jul 2007 16:00:52 -0000 I was just wondering about the status of AMD 64 support, before I spend a lot of time with it. I can't get it to install using the snapshot: AMD64 7.0 200706 with an Athlon 64 X2 processor. The last thing it says before it bites the dust is: Trying to mount root from ufs:/dev/md0 start_init: trying /sbin/init start_init: trying /sbin/oinit start_init: trying /sbin/init.bak start_init: trying /rescue/init start_init: trying /stand/sysinstall The i386 distribution installs and runs OK on the same processor. Are there known issues with installing the AMD64 distribution? Thanks, Larry. From owner-freebsd-current@FreeBSD.ORG Sun Jul 15 16:15:03 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 966F116A400 for ; Sun, 15 Jul 2007 16:15:03 +0000 (UTC) (envelope-from thierry@herbelot.com) Received: from smtp4-g19.free.fr (smtp4-g19.free.fr [212.27.42.30]) by mx1.freebsd.org (Postfix) with ESMTP id 5E3CC13C494 for ; Sun, 15 Jul 2007 16:15:03 +0000 (UTC) (envelope-from thierry@herbelot.com) Received: from herbelot.dyndns.org (bne75-4-82-227-159-103.fbx.proxad.net [82.227.159.103]) by smtp4-g19.free.fr (Postfix) with ESMTP id 542746F374 for ; Sun, 15 Jul 2007 18:15:02 +0200 (CEST) Received: from diversion.herbelot.nom (diversion.herbelot.nom [192.168.2.6]) by herbelot.dyndns.org (8.14.0/8.14.0) with ESMTP id l6FGEt3R009277; Sun, 15 Jul 2007 18:14:58 +0200 (CEST) From: Thierry Herbelot To: freebsd-current@freebsd.org Date: Sun, 15 Jul 2007 18:14:47 +0200 User-Agent: KMail/1.9.7 References: <88afd9200707150833t26621cbar6286a30b7c1bd371@mail.gmail.com> In-Reply-To: <88afd9200707150833t26621cbar6286a30b7c1bd371@mail.gmail.com> X-Warning: Windows can lose your files X-Op-Sys: Le FriBi de la mort qui tue X-Org: TfH&Co X-MailScanner: Found to be clean MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Content-Disposition: inline Message-Id: <200707151814.48606.thierry@herbelot.com> Cc: Kool Guy Subject: Re: AMD 64 Status X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: thierry@herbelot.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, 15 Jul 2007 16:15:03 -0000 Le Sunday 15 July 2007, Kool Guy a écrit : > I was just wondering about the status of AMD 64 support, before I > spend a lot of time with it. I can't get it to install using the > snapshot: AMD64 7.0 200706 with an Athlon 64 X2 processor. The last > thing it says before it bites the dust is: can you install a 6-Stable AMD64 snapshot and then upgrade from source to a -current machine ? TfH From owner-freebsd-current@FreeBSD.ORG Sun Jul 15 16:45:31 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C222116A402 for ; Sun, 15 Jul 2007 16:45:31 +0000 (UTC) (envelope-from koolguy317@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.232]) by mx1.freebsd.org (Postfix) with ESMTP id 8279213C46B for ; Sun, 15 Jul 2007 16:45:31 +0000 (UTC) (envelope-from koolguy317@gmail.com) Received: by wx-out-0506.google.com with SMTP id i29so770464wxd for ; Sun, 15 Jul 2007 09:45:31 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=UPocBBgFd0khrwr/IW1t3Fii0wm1foleifEa8XDrumLoeMSnz79UsWjpCj5QRAoTtBqRu98/7A8ZT/vf9prSSCmQ3pTDIS9WPr+M7NbofTK9/kLa1raJAdXIRcmIrXvvzWoBoWnPGqJus9MnKemCoTrCBiURf/RRIrMZuuKAZHg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=cDT4SRHf1sYvHCv5i8+Q3hCoFQueot+s/AIsyIxsHaeh74FhLwllJ0dbrxmOCBtMZUX+LjXaXiBf+l6jJJamnWwq1Wil3Edv3dyDJ3oMWF44WIQgkOMgMzszNz+PA6KyhenTzf28GPAuXm9R+L3XLQvKY6xZxDm3iLuegtnsmpU= Received: by 10.90.104.14 with SMTP id b14mr2612183agc.1184516450996; Sun, 15 Jul 2007 09:20:50 -0700 (PDT) Received: by 10.90.30.11 with HTTP; Sun, 15 Jul 2007 09:20:50 -0700 (PDT) Message-ID: <88afd9200707150920t8107419i743f88b6d5d9dc34@mail.gmail.com> Date: Sun, 15 Jul 2007 12:20:50 -0400 From: "Kool Guy" To: freebsd-current@freebsd.org In-Reply-To: <200707151814.48606.thierry@herbelot.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <88afd9200707150833t26621cbar6286a30b7c1bd371@mail.gmail.com> <200707151814.48606.thierry@herbelot.com> Subject: Re: AMD 64 Status X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jul 2007 16:45:31 -0000 I'll give it a try. Thanks. On 7/15/07, Thierry Herbelot wrote: > Le Sunday 15 July 2007, Kool Guy a =E9crit : > > I was just wondering about the status of AMD 64 support, before I > > spend a lot of time with it. I can't get it to install using the > > snapshot: AMD64 7.0 200706 with an Athlon 64 X2 processor. The last > > thing it says before it bites the dust is: > > can you install a 6-Stable AMD64 snapshot and then upgrade from source to > a -current machine ? > > TfH > From owner-freebsd-current@FreeBSD.ORG Sun Jul 15 17:17:13 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 27CFA16A406 for ; Sun, 15 Jul 2007 17:17:13 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id D87BF13C4D1 for ; Sun, 15 Jul 2007 17:17:12 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 820D817383; Sun, 15 Jul 2007 17:17:11 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.1/8.14.1) with ESMTP id l6FHHAa5058736; Sun, 15 Jul 2007 17:17:11 GMT (envelope-from phk@critter.freebsd.dk) To: Michiel Boland From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sun, 15 Jul 2007 17:43:45 +0200." Date: Sun, 15 Jul 2007 17:17:10 +0000 Message-ID: <58735.1184519830@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: freebsd-current@freebsd.org Subject: Re: sshd broken with UsePrivilegeSeparation=yes on sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jul 2007 17:17:13 -0000 In message , Mi chiel Boland writes: >It looks like gcc mis-compiles /usr/src/crypto/openssh/monitor_fdpass.c on >sparc64. For some reason it optimizes away the assignment of fd on line >132: > > fd = (*(int *)CMSG_DATA(cmsg)); > >So, obviously a gcc bug. I will try to generate a smaller test-case for >this. I'm not convinced that CMSG_DATA is entirely kosher. FlexeLint (www.gimpel.com) have complained about CMSG_DATA for ages but I have never been able to figure out why it complained. -- 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 Jul 15 17:43:54 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6A98316A400 for ; Sun, 15 Jul 2007 17:43:54 +0000 (UTC) (envelope-from lulf@stud.ntnu.no) Received: from fri.itea.ntnu.no (fri.itea.ntnu.no [129.241.7.60]) by mx1.freebsd.org (Postfix) with ESMTP id 2940813C461 for ; Sun, 15 Jul 2007 17:43:54 +0000 (UTC) (envelope-from lulf@stud.ntnu.no) Received: from localhost (localhost [127.0.0.1]) by fri.itea.ntnu.no (Postfix) with ESMTP id 5BD559BCE for ; Sun, 15 Jul 2007 19:43:53 +0200 (CEST) Received: from gaupe.stud.ntnu.no (gaupe.stud.ntnu.no [129.241.56.184]) by fri.itea.ntnu.no (Postfix) with ESMTP for ; Sun, 15 Jul 2007 19:43:53 +0200 (CEST) Received: by gaupe.stud.ntnu.no (Postfix, from userid 2312) id 95288D0034; Sun, 15 Jul 2007 19:44:00 +0200 (CEST) Date: Sun, 15 Jul 2007 19:44:00 +0200 From: Ulf Lilleengen To: freebsd-current@freebsd.org Message-ID: <20070715174400.GA10062@stud.ntnu.no> References: <200707131834.27131.h.schmalzbauer@omnisec.de> <4697CCEB.9080707@FreeBSD.org> <200707132155.43783.h.schmalzbauer@omnisec.de> <4698E7C4.9080001@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4698E7C4.9080001@FreeBSD.org> User-Agent: Mutt/1.5.9i X-Content-Scanned: with sophos and spamassassin at mailgw.ntnu.no. Subject: Re: kqemu crash (page fault) with -current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jul 2007 17:43:54 -0000 On lør, jul 14, 2007 at 05:12:04 +0200, Attilio Rao wrote: > Harald Schmalzbauer wrote: > >Am Freitag, 13. Juli 2007 schrieb Attilio Rao: > >>Harald Schmalzbauer wrote: > >>>Hello, > >>> > >>>today I tried qemu for the first time and I love it. > >>>Now I'd need some speed and tried kqemu, but it immediately reboots my > >>>machine. > >>>Here is what I could transcribe: > >>Could you please try this patch and see if it helps?: > >>http://people.freebsd.org/~attilio/kqemu.diff > > > >I applied it, rebuilt my kernel and kqemu, but machine crashes immedately > >after running qemu (without disabled kqemu). > >Should I also rebuild qemu itself? I don't think it's needed. > >But CFLAGS+= -DKSE helped! > >I could install various OS, only when I enable -kernel-kqemu most > >installer quit with page fault. > > Hello Harry, > could you please download again the patch and try again? > It seems I missed a bit... > > And, please, compile again qemu any time beacause I'm not sure how much > are exposed to userland "struct thread" and "struct proc", for this problem. > > You should firstly try the canonical case of kernel clean compilation > (so with KSE) and kqemu clean compilation (so without KSE, without the > -DKSE option). > I've tested the patch, and I can confirm that it works with and without KSE now. Also, I didn't have to recompile qemu, just kqemu. -- Ulf Lilleengen From owner-freebsd-current@FreeBSD.ORG Sun Jul 15 18:17:37 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4E54B16A400 for ; Sun, 15 Jul 2007 18:17:37 +0000 (UTC) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (gate.funkthat.com [69.17.45.168]) by mx1.freebsd.org (Postfix) with ESMTP id 27C2113C474 for ; Sun, 15 Jul 2007 18:17:37 +0000 (UTC) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (aunog515ksw3xx2l@localhost.funkthat.com [127.0.0.1]) by hydrogen.funkthat.com (8.13.6/8.13.3) with ESMTP id l6FIHX1R035543; Sun, 15 Jul 2007 11:17:33 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.13.6/8.13.3/Submit) id l6FIHWGX035542; Sun, 15 Jul 2007 11:17:32 -0700 (PDT) (envelope-from jmg) Date: Sun, 15 Jul 2007 11:17:32 -0700 From: John-Mark Gurney To: Michiel Boland Message-ID: <20070715181732.GR1221@funkthat.com> Mail-Followup-To: Michiel Boland , freebsd-current@freebsd.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 5.4-RELEASE-p6 i386 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html Cc: freebsd-current@freebsd.org Subject: Re: sshd broken with UsePrivilegeSeparation=yes on sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: John-Mark Gurney List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jul 2007 18:17:37 -0000 Michiel Boland wrote this message on Sun, Jul 15, 2007 at 17:43 +0200: > It looks like gcc mis-compiles /usr/src/crypto/openssh/monitor_fdpass.c on > sparc64. For some reason it optimizes away the assignment of fd on line > 132: > > fd = (*(int *)CMSG_DATA(cmsg)); > > So I guess that every call to mm_receive_fd will return an undefined > value. > > If I add -O0 to CFLAGS in /usr/src/secure/lib/libssh/Makefile, ssh with > UsePrivilegeSeparation=yes works again. > > So, obviously a gcc bug. I will try to generate a smaller test-case for > this. Could you give us an assembly dump of the two differences? phk thinks there might be an issue w/ the CMSG_DATA macro, and a quick glance makes me question it too... It looks scare on platforms that require aligned accesses... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-current@FreeBSD.ORG Sun Jul 15 18:48:21 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5AD3616A402; Sun, 15 Jul 2007 18:48:21 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from heff.fud.org.nz (203-109-251-39.static.bliink.ihug.co.nz [203.109.251.39]) by mx1.freebsd.org (Postfix) with ESMTP id 8F81113C4AA; Sun, 15 Jul 2007 18:48:20 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: by heff.fud.org.nz (Postfix, from userid 1001) id C1B3D1CC5F; Mon, 16 Jul 2007 06:48:18 +1200 (NZST) Date: Mon, 16 Jul 2007 06:48:18 +1200 From: Andrew Thompson To: Matteo Riondato Message-ID: <20070715184818.GB10968@heff.fud.org.nz> References: <200707120254.l6C2s5Yg041022@repoman.freebsd.org> <20070713230833.GA2642@krapfengeist.dei.unipd.it> <20070715111346.GJ95956@heff.fud.org.nz> <20070715131140.GA1413@krapfengeist.dei.unipd.it> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0F1p//8PRICkK4MW" Content-Disposition: inline In-Reply-To: <20070715131140.GA1413@krapfengeist.dei.unipd.it> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: FreeBSD Current Subject: Re: cvs commit: src/sys/dev/if_ndis if_ndis.c if_ndisvar.h X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jul 2007 18:48:21 -0000 --0F1p//8PRICkK4MW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sun, Jul 15, 2007 at 03:11:40PM +0200, Matteo Riondato wrote: > On Sun, Jul 15, 2007 at 11:13:46PM +1200, Andrew Thompson wrote: > > On Sat, Jul 14, 2007 at 01:08:33AM +0200, Matteo Riondato wrote: > > > On Thu, Jul 12, 2007 at 02:54:05AM +0000, Andrew Thompson wrote: > > > > thompsa 2007-07-12 02:54:05 UTC > > > > > > > > FreeBSD src repository > > > > > > > > Modified files: > > > > sys/dev/if_ndis if_ndis.c if_ndisvar.h > > > > Log: > > > > Improve the net80211 handling within ndis > > > > - use net80211 for scanning and pass the results back to the scan cache > > > > - use ieee80211_init_channels to fill our channel list > > > > - fix up state transitions > > > > - depreciate the old wicontrol ioctls > > > > - add some debugging lines (#define NDIS_DEBUG) > > > > > > I wonder whether this commit can be guilty of my wireless connection > > > (which uses ndis) no longer working. I rebuild my system today and when > > > I rebooted my machine can no longer connect to the network. "ifconfig > > > ndis0 scan" seems not to work any more. > > > I will be pleased to give more debug information, if you tell me what > > > you need. > > > > You can turn on net80211 debugging my setting sysctl > > net.wlan.0.debug=0xffffffff (or use wlandebug). Kick off a scan and see > > if anything is returned. > > kaiser# sysctl net.wlan.0.debug=0xffffffff > net.wlan.0.debug: 0 -> 2147483647 > kaise# ifconfig ndis0 scan > ndis0: ieee80211_start_scan: acrive scan 2147483647, desired mode auto, > append, nopick, once > ndis0 scan set dwell min 20 max 200 > ndis0: scan_restart: no channels to scan Can you please test the attached patch, it also turns on debugging printfs which I would be interested in. Andrew --0F1p//8PRICkK4MW Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="ndis_channels.diff" Index: if_ndis.c =================================================================== RCS file: /home/ncvs/src/sys/dev/if_ndis/if_ndis.c,v retrieving revision 1.123 diff -u -p -r1.123 if_ndis.c --- if_ndis.c 12 Jul 2007 02:54:05 -0000 1.123 +++ if_ndis.c 15 Jul 2007 18:46:29 -0000 @@ -89,6 +89,7 @@ __FBSDID("$FreeBSD: src/sys/dev/if_ndis/ #include #include +#define NDIS_DEBUG #ifdef NDIS_DEBUG #define DPRINTF(x) printf x #else @@ -752,11 +753,16 @@ ndis_attach(dev) setbit(&bands, IEEE80211_MODE_11G); break; default: + DPRINTF(("Unknown nettype %d\n", + ntl->ntl_type[i])); break; } } free(ntl, M_DEVBUF); nonettypes: + /* Default to 11b channel set if the card did not supply any */ + if (bands == 0) + setbit(ic->ic_modecaps, IEEE80211_MODE_11B); len = sizeof(rates); bzero((char *)&rates, len); r = ndis_get_info(sc, OID_802_11_SUPPORTED_RATES, --0F1p//8PRICkK4MW-- From owner-freebsd-current@FreeBSD.ORG Sun Jul 15 20:23:39 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7FF0116A402; Sun, 15 Jul 2007 20:23:39 +0000 (UTC) (envelope-from dwmalone@maths.tcd.ie) Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by mx1.freebsd.org (Postfix) with SMTP id AAB1A13C467; Sun, 15 Jul 2007 20:23:38 +0000 (UTC) (envelope-from dwmalone@maths.tcd.ie) Received: from walton.maths.tcd.ie ([134.226.81.10] helo=walton.maths.tcd.ie) by salmon.maths.tcd.ie with SMTP id ; 15 Jul 2007 21:23:37 +0100 (BST) Date: Sun, 15 Jul 2007 21:23:36 +0100 From: David Malone To: Dominique Goncalves Message-ID: <20070715202336.GA40121@walton.maths.tcd.ie> References: <20070709214216.GA72912@walton.maths.tcd.ie> <20070711132202.GA95487@walton.maths.tcd.ie> <20070712085135.GA5332@walton.maths.tcd.ie> <7daacbbe0707150237gc869abdi756d54219edb2577@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7daacbbe0707150237gc869abdi756d54219edb2577@mail.gmail.com> User-Agent: Mutt/1.5.6i Sender: dwmalone@maths.tcd.ie Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, Ivan Voras Subject: Re: Debugging times X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Jul 2007 20:23:39 -0000 On Sun, Jul 15, 2007 at 11:37:57AM +0200, Dominique Goncalves wrote: > >Yes, it does! Setting ct.dow to -1 fixes the time in a correct way. > It works also for me with qemu 0.9.0. Great - I'll work on getting it merged in. David. From owner-freebsd-current@FreeBSD.ORG Sun Jul 15 20:50:04 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D3D3E16A402 for ; Sun, 15 Jul 2007 20:50:04 +0000 (UTC) (envelope-from michiel@boland.org) Received: from neerbosch.nijmegen.internl.net (neerbosch.nijmegen.internl.net [217.149.193.38]) by mx1.freebsd.org (Postfix) with ESMTP id 328EB13C474 for ; Sun, 15 Jul 2007 20:50:03 +0000 (UTC) (envelope-from michiel@boland.org) Received: from neerbosch.nijmegen.internl.net by neerbosch.nijmegen.internl.net via neerbosch.nijmegen.internl.net [217.149.193.38] with ESMTP id l6FKo1Xc005503 (8.13.4/1.4); Sun, 15 Jul 2007 22:50:01 +0200 (MEST) Received: from localhost by neerbosch.nijmegen.internl.net via mboland@localhost with ESMTP id l6FKo1FI005498 (8.13.4/2.02); Sun, 15 Jul 2007 22:50:01 +0200 (MEST) X-Authentication-Warning: neerbosch.nijmegen.internl.net: mboland owned process doing -bs Date: Sun, 15 Jul 2007 22:50:01 +0200 (MEST) From: Michiel Boland To: John-Mark Gurney In-Reply-To: <20070715181732.GR1221@funkthat.com> Message-ID: References: <20070715181732.GR1221@funkthat.com> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-758783491-1184532601=:29570" Cc: freebsd-current@freebsd.org Subject: Re: sshd broken with UsePrivilegeSeparation=yes on sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jul 2007 20:50:04 -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. ---559023410-758783491-1184532601=:29570 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > Could you give us an assembly dump of the two differences? phk thinks > there might be an issue w/ the CMSG_DATA macro, and a quick glance > makes me question it too... It looks scare on platforms that require > aligned accesses... Ok I have attached the compiled .s files. Hopefully these will not be eaten along the way. Oh and, instead of compiling with O0, the following trick also helps avoid the problem --- monitor_fdpass.c.orig 2007-07-15 22:47:01.000000000 +0200 +++ monitor_fdpass.c 2007-07-15 22:47:05.000000000 +0200 @@ -130,6 +130,7 @@ SCM_RIGHTS, cmsg->cmsg_type); #endif fd = (*(int *)CMSG_DATA(cmsg)); + debug3("%s: fd = %d", __func__, fd); #endif return fd; #else ---559023410-758783491-1184532601=:29570 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=monitor_fdpass_O0.s Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename=monitor_fdpass_O0.s CS5maWxlCSJtb25pdG9yX2ZkcGFzcy5jIg0KCS5zZWN0aW9uCSIuZGVidWdf YWJicmV2Ig0KLkxMZGVidWdfYWJicmV2MDoNCgkuc2VjdGlvbgkiLmRlYnVn X2luZm8iDQouTExkZWJ1Z19pbmZvMDoNCgkuc2VjdGlvbgkiLmRlYnVnX2xp bmUiDQouTExkZWJ1Z19saW5lMDoNCgkuc2VjdGlvbgkiLnRleHQiDQouTEx0 ZXh0MDoNCgkuc2VjdGlvbgkiLnJvZGF0YSINCgkuYWxpZ24gOA0KCS50eXBl CV9fZnVuY19fLjU0MzIsICNvYmplY3QNCgkuc2l6ZQlfX2Z1bmNfXy41NDMy LCAxNQ0KX19mdW5jX18uNTQzMjoNCgkuYXNjaXoJInNzaF9tbV9zZW5kX2Zk Ig0KCS5hbGlnbiA4DQouTExDMDoNCgkuYXNjaXoJIiVzOiBzZW5kbXNnKCVk KTogJXMiDQoJLmFsaWduIDgNCi5MTEMxOg0KCS5hc2NpegkiJXM6IHNlbmRt c2c6IGV4cGVjdGVkIHNlbnQgMSBnb3QgJWxkIg0KCS5zZWN0aW9uCSIudGV4 dCINCgkuYWxpZ24gNA0KLkxMQUREUEMwOg0KCWFkZAklbzcsICVsNywgJWw3 DQoJam1wCSVvNys4DQoJIG5vcA0KCS5hbGlnbiA0DQoJLmFsaWduIDMyDQoJ Lmdsb2JhbCBzc2hfbW1fc2VuZF9mZA0KCS50eXBlCXNzaF9tbV9zZW5kX2Zk LCAjZnVuY3Rpb24NCgkucHJvYwkwMjANCnNzaF9tbV9zZW5kX2ZkOg0KLkxM RkIxMzoNCgkuZmlsZSAxICIvdXNyL3NyYy9zZWN1cmUvbGliL2xpYnNzaC8u Li8uLi8uLi9jcnlwdG8vb3BlbnNzaC9tb25pdG9yX2ZkcGFzcy5jIg0KCS5s b2MgMSA0NSAwDQoJLnJlZ2lzdGVyCSVnMiwgI3NjcmF0Y2gNCgkucmVnaXN0 ZXIJJWczLCAjc2NyYXRjaA0KCXNhdmUJJXNwLCAtMzM2LCAlc3ANCi5MTENG STA6DQoJc2V0aGkJJWhpKF9HTE9CQUxfT0ZGU0VUX1RBQkxFXy04KSwgJWw3 DQoJYWRkCSVsNywgJWxvKF9HTE9CQUxfT0ZGU0VUX1RBQkxFXy00KSwgJWw3 DQoJY2FsbAkuTExBRERQQzANCgkgbm9wDQoJbW92CSVpMCwgJWcxDQoJbW92 CSVpMSwgJWcyDQoJc3QJJWcxLCBbJWZwKzIxNzVdDQoJc3QJJWcyLCBbJWZw KzIxODNdDQoJLmxvYyAxIDQ5IDANCglzdGIJJWcwLCBbJWZwKzE5NTBdDQoJ LmxvYyAxIDU2IDANCglhZGQJJWZwLCAxOTY3LCAlZzENCgltb3YJJWcxLCAl bzANCgltb3YJMCwgJW8xDQoJbW92CTQ4LCAlbzINCgljYWxsCW1lbXNldCwg MA0KCSBub3ANCgkubG9jIDEgNjEgMA0KCWFkZAklZnAsIDE5MTgsICVnMQ0K CXN0eAklZzEsIFslZnArMTk5OV0NCgkubG9jIDEgNjIgMA0KCW1vdgkyMCwg JWcxDQoJc3QJJWcxLCBbJWZwKzIwMDddDQoJLmxvYyAxIDYzIDANCglsZAlb JWZwKzIwMDddLCAlZzENCgljbXAJJWcxLCAxMQ0KCWJsZXUJJWljYywgLkxM Mg0KCSBub3ANCglsZHgJWyVmcCsxOTk5XSwgJWcxDQoJc3R4CSVnMSwgWyVm cCsxODk1XQ0KCWJhLHB0CSV4Y2MsIC5MTDQNCgkgbm9wDQouTEwyOg0KCXN0 eAklZzAsIFslZnArMTg5NV0NCi5MTDQ6DQoJbGR4CVslZnArMTg5NV0sICVn MQ0KCXN0eAklZzEsIFslZnArMjAyM10NCgkubG9jIDEgNjQgMA0KCWxkeAlb JWZwKzIwMjNdLCAlZzINCgltb3YJMjAsICVnMQ0KCXN0CSVnMSwgWyVnMl0N CgkubG9jIDEgNjUgMA0KCWxkeAlbJWZwKzIwMjNdLCAlZzINCglzZXRoaQkl aGkoNjQ1MTIpLCAlZzENCglvcgklZzEsIDEwMjMsICVnMQ0KCXN0CSVnMSwg WyVnMis0XQ0KCS5sb2MgMSA2NiAwDQoJbGR4CVslZnArMjAyM10sICVnMg0K CW1vdgkxLCAlZzENCglzdAklZzEsIFslZzIrOF0NCgkubG9jIDEgNjcgMA0K CWxkeAlbJWZwKzIwMjNdLCAlZzENCglhZGQJJWcxLCAxNiwgJWcxDQoJbW92 CSVnMSwgJWcyDQoJbGQJWyVmcCsyMTgzXSwgJWcxDQoJc3QJJWcxLCBbJWcy XQ0KCS5sb2MgMSA3MCAwDQoJYWRkCSVmcCwgMTk1MCwgJWcxDQoJc3R4CSVn MSwgWyVmcCsxOTUxXQ0KCS5sb2MgMSA3MSAwDQoJbW92CTEsICVnMQ0KCXN0 eAklZzEsIFslZnArMTk1OV0NCgkubG9jIDEgNzIgMA0KCWFkZAklZnAsIDE5 NTEsICVnMQ0KCXN0eAklZzEsIFslZnArMTk4M10NCgkubG9jIDEgNzMgMA0K CW1vdgkxLCAlZzENCglzdAklZzEsIFslZnArMTk5MV0NCgkubG9jIDEgNzUg MA0KCWxkCVslZnArMjE3NV0sICVnMQ0KCXNyYQklZzEsIDAsICVnMQ0KCWFk ZAklZnAsIDE5NjcsICVnMg0KCW1vdgklZzEsICVvMA0KCW1vdgklZzIsICVv MQ0KCW1vdgkwLCAlbzINCgljYWxsCXNlbmRtc2csIDANCgkgbm9wDQoJbW92 CSVvMCwgJWcxDQoJc3R4CSVnMSwgWyVmcCsyMDE1XQ0KCWxkeAlbJWZwKzIw MTVdLCAlZzENCgljbXAJJWcxLCAtMQ0KCWJuZQkleGNjLCAuTEw1DQoJIG5v cA0KCS5sb2MgMSA3NiAwDQoJY2FsbAlfX2Vycm9yLCAwDQoJIG5vcA0KCW1v dgklbzAsICVnMQ0KCWxkCVslZzFdLCAlZzENCglzcmEJJWcxLCAwLCAlZzEN Cgltb3YJJWcxLCAlbzANCgljYWxsCXN0cmVycm9yLCAwDQoJIG5vcA0KCW1v dgklbzAsICVnMw0KCWxkCVslZnArMjE4M10sICVnMQ0KCXNyYQklZzEsIDAs ICVnMg0KCXNldGhpCSVoaSguTExDMCksICVnMQ0KCW9yCSVnMSwgJWxvKC5M TEMwKSwgJWcxDQoJbGR4CVslbDcrJWcxXSwgJWcxDQoJbW92CSVnMSwgJW8w DQoJc2V0aGkJJWhpKF9fZnVuY19fLjU0MzIpLCAlZzENCglvcgklZzEsICVs byhfX2Z1bmNfXy41NDMyKSwgJWcxDQoJbGR4CVslbDcrJWcxXSwgJWcxDQoJ bW92CSVnMSwgJW8xDQoJbW92CSVnMiwgJW8yDQoJbW92CSVnMywgJW8zDQoJ Y2FsbAlzc2hfZmF0YWwsIDANCgkgbm9wDQouTEw1Og0KCS5sb2MgMSA3OCAw DQoJbGR4CVslZnArMjAxNV0sICVnMQ0KCWNtcAklZzEsIDENCgliZQkleGNj LCAuTEw5DQoJIG5vcA0KCS5sb2MgMSA3OSAwDQoJc2V0aGkJJWhpKC5MTEMx KSwgJWcxDQoJb3IJJWcxLCAlbG8oLkxMQzEpLCAlZzENCglsZHgJWyVsNysl ZzFdLCAlZzENCgltb3YJJWcxLCAlbzANCglzZXRoaQklaGkoX19mdW5jX18u NTQzMiksICVnMQ0KCW9yCSVnMSwgJWxvKF9fZnVuY19fLjU0MzIpLCAlZzEN CglsZHgJWyVsNyslZzFdLCAlZzENCgltb3YJJWcxLCAlbzENCglsZHgJWyVm cCsyMDE1XSwgJW8yDQoJY2FsbAlzc2hfZmF0YWwsIDANCgkgbm9wDQouTEw5 Og0KCS5sb2MgMSA4NSAwDQoJcmV0dXJuCSVpNys4DQoJIG5vcA0KLkxMRkUx MzoNCgkuc2l6ZQlzc2hfbW1fc2VuZF9mZCwgLi1zc2hfbW1fc2VuZF9mZA0K CS5zZWN0aW9uCSIucm9kYXRhIg0KCS5hbGlnbiA4DQoJLnR5cGUJX19mdW5j X18uNTQ2MCwgI29iamVjdA0KCS5zaXplCV9fZnVuY19fLjU0NjAsIDE4DQpf X2Z1bmNfXy41NDYwOg0KCS5hc2Npegkic3NoX21tX3JlY2VpdmVfZmQiDQoJ LmFsaWduIDgNCi5MTEMyOg0KCS5hc2NpegkiJXM6IHJlY3Ztc2c6ICVzIg0K CS5hbGlnbiA4DQouTExDMzoNCgkuYXNjaXoJIiVzOiByZWN2bXNnOiBleHBl Y3RlZCByZWNlaXZlZCAxIGdvdCAlbGQiDQoJLmFsaWduIDgNCi5MTEM0Og0K CS5hc2NpegkiJXM6IG5vIG1lc3NhZ2UgaGVhZGVyIg0KCS5hbGlnbiA4DQou TExDNToNCgkuYXNjaXoJIiVzOiBleHBlY3RlZCB0eXBlICVkIGdvdCAlZCIN Cgkuc2VjdGlvbgkiLnRleHQiDQoJLmFsaWduIDQNCgkuYWxpZ24gMzINCgku Z2xvYmFsIHNzaF9tbV9yZWNlaXZlX2ZkDQoJLnR5cGUJc3NoX21tX3JlY2Vp dmVfZmQsICNmdW5jdGlvbg0KCS5wcm9jCTA0DQpzc2hfbW1fcmVjZWl2ZV9m ZDoNCi5MTEZCMTQ6DQoJLmxvYyAxIDg5IDANCglzYXZlCSVzcCwgLTMzNiwg JXNwDQouTExDRkkxOg0KCXNldGhpCSVoaShfR0xPQkFMX09GRlNFVF9UQUJM RV8tOCksICVsNw0KCWFkZAklbDcsICVsbyhfR0xPQkFMX09GRlNFVF9UQUJM RV8tNCksICVsNw0KCWNhbGwJLkxMQUREUEMwDQoJIG5vcA0KCW1vdgklaTAs ICVnMQ0KCXN0CSVnMSwgWyVmcCsyMTc1XQ0KCS5sb2MgMSAxMDEgMA0KCWFk ZAklZnAsIDE5NTksICVnMQ0KCW1vdgklZzEsICVvMA0KCW1vdgkwLCAlbzEN Cgltb3YJNDgsICVvMg0KCWNhbGwJbWVtc2V0LCAwDQoJIG5vcA0KCS5sb2Mg MSAxMDIgMA0KCWFkZAklZnAsIDE5NDIsICVnMQ0KCXN0eAklZzEsIFslZnAr MTk0M10NCgkubG9jIDEgMTAzIDANCgltb3YJMSwgJWcxDQoJc3R4CSVnMSwg WyVmcCsxOTUxXQ0KCS5sb2MgMSAxMDQgMA0KCWFkZAklZnAsIDE5NDMsICVn MQ0KCXN0eAklZzEsIFslZnArMTk3NV0NCgkubG9jIDEgMTA1IDANCgltb3YJ MSwgJWcxDQoJc3QJJWcxLCBbJWZwKzE5ODNdDQoJLmxvYyAxIDExMCAwDQoJ YWRkCSVmcCwgMTkxMCwgJWcxDQoJc3R4CSVnMSwgWyVmcCsxOTkxXQ0KCS5s b2MgMSAxMTEgMA0KCW1vdgkzMiwgJWcxDQoJc3QJJWcxLCBbJWZwKzE5OTld DQoJLmxvYyAxIDExNCAwDQoJbGQJWyVmcCsyMTc1XSwgJWcxDQoJc3JhCSVn MSwgMCwgJWcxDQoJYWRkCSVmcCwgMTk1OSwgJWcyDQoJbW92CSVnMSwgJW8w DQoJbW92CSVnMiwgJW8xDQoJbW92CTAsICVvMg0KCWNhbGwJcmVjdm1zZywg MA0KCSBub3ANCgltb3YJJW8wLCAlZzENCglzdHgJJWcxLCBbJWZwKzIwMDdd DQoJbGR4CVslZnArMjAwN10sICVnMQ0KCWNtcAklZzEsIC0xDQoJYm5lCSV4 Y2MsIC5MTDExDQoJIG5vcA0KCS5sb2MgMSAxMTUgMA0KCWNhbGwJX19lcnJv ciwgMA0KCSBub3ANCgltb3YJJW8wLCAlZzENCglsZAlbJWcxXSwgJWcxDQoJ c3JhCSVnMSwgMCwgJWcxDQoJbW92CSVnMSwgJW8wDQoJY2FsbAlzdHJlcnJv ciwgMA0KCSBub3ANCgltb3YJJW8wLCAlZzINCglzZXRoaQklaGkoLkxMQzIp LCAlZzENCglvcgklZzEsICVsbyguTExDMiksICVnMQ0KCWxkeAlbJWw3KyVn MV0sICVnMQ0KCW1vdgklZzEsICVvMA0KCXNldGhpCSVoaShfX2Z1bmNfXy41 NDYwKSwgJWcxDQoJb3IJJWcxLCAlbG8oX19mdW5jX18uNTQ2MCksICVnMQ0K CWxkeAlbJWw3KyVnMV0sICVnMQ0KCW1vdgklZzEsICVvMQ0KCW1vdgklZzIs ICVvMg0KCWNhbGwJc3NoX2ZhdGFsLCAwDQoJIG5vcA0KLkxMMTE6DQoJLmxv YyAxIDExNiAwDQoJbGR4CVslZnArMjAwN10sICVnMQ0KCWNtcAklZzEsIDEN CgliZQkleGNjLCAuTEwxMw0KCSBub3ANCgkubG9jIDEgMTE3IDANCglzZXRo aQklaGkoLkxMQzMpLCAlZzENCglvcgklZzEsICVsbyguTExDMyksICVnMQ0K CWxkeAlbJWw3KyVnMV0sICVnMQ0KCW1vdgklZzEsICVvMA0KCXNldGhpCSVo aShfX2Z1bmNfXy41NDYwKSwgJWcxDQoJb3IJJWcxLCAlbG8oX19mdW5jX18u NTQ2MCksICVnMQ0KCWxkeAlbJWw3KyVnMV0sICVnMQ0KCW1vdgklZzEsICVv MQ0KCWxkeAlbJWZwKzIwMDddLCAlbzINCgljYWxsCXNzaF9mYXRhbCwgMA0K CSBub3ANCi5MTDEzOg0KCS5sb2MgMSAxMjQgMA0KCWxkCVslZnArMTk5OV0s ICVnMQ0KCWNtcAklZzEsIDExDQoJYmxldQklaWNjLCAuTEwxNQ0KCSBub3AN CglsZHgJWyVmcCsxOTkxXSwgJWcxDQoJc3R4CSVnMSwgWyVmcCsxODk1XQ0K CWJhLHB0CSV4Y2MsIC5MTDE3DQoJIG5vcA0KLkxMMTU6DQoJc3R4CSVnMCwg WyVmcCsxODk1XQ0KLkxMMTc6DQoJbGR4CVslZnArMTg5NV0sICVnMQ0KCXN0 eAklZzEsIFslZnArMjAyM10NCgkubG9jIDEgMTI1IDANCglsZHgJWyVmcCsy MDIzXSwgJWcxDQoJYnJuegklZzEsIC5MTDE4DQoJIG5vcA0KCS5sb2MgMSAx MjYgMA0KCXNldGhpCSVoaSguTExDNCksICVnMQ0KCW9yCSVnMSwgJWxvKC5M TEM0KSwgJWcxDQoJbGR4CVslbDcrJWcxXSwgJWcxDQoJbW92CSVnMSwgJW8w DQoJc2V0aGkJJWhpKF9fZnVuY19fLjU0NjApLCAlZzENCglvcgklZzEsICVs byhfX2Z1bmNfXy41NDYwKSwgJWcxDQoJbGR4CVslbDcrJWcxXSwgJWcxDQoJ bW92CSVnMSwgJW8xDQoJY2FsbAlzc2hfZmF0YWwsIDANCgkgbm9wDQouTEwx ODoNCgkubG9jIDEgMTI4IDANCglsZHgJWyVmcCsyMDIzXSwgJWcxDQoJbGQJ WyVnMSs4XSwgJWcxDQoJY21wCSVnMSwgMQ0KCWJlCSVpY2MsIC5MTDIwDQoJ IG5vcA0KCS5sb2MgMSAxMjkgMA0KCWxkeAlbJWZwKzIwMjNdLCAlZzENCgls ZAlbJWcxKzhdLCAlZzENCglzcmEJJWcxLCAwLCAlZzINCglzZXRoaQklaGko LkxMQzUpLCAlZzENCglvcgklZzEsICVsbyguTExDNSksICVnMQ0KCWxkeAlb JWw3KyVnMV0sICVnMQ0KCW1vdgklZzEsICVvMA0KCXNldGhpCSVoaShfX2Z1 bmNfXy41NDYwKSwgJWcxDQoJb3IJJWcxLCAlbG8oX19mdW5jX18uNTQ2MCks ICVnMQ0KCWxkeAlbJWw3KyVnMV0sICVnMQ0KCW1vdgklZzEsICVvMQ0KCW1v dgkxLCAlbzINCgltb3YJJWcyLCAlbzMNCgljYWxsCXNzaF9mYXRhbCwgMA0K CSBub3ANCi5MTDIwOg0KCS5sb2MgMSAxMzIgMA0KCWxkeAlbJWZwKzIwMjNd LCAlZzENCglhZGQJJWcxLCAxNiwgJWcxDQoJbGQJWyVnMV0sICVnMQ0KCXN0 CSVnMSwgWyVmcCsyMDE5XQ0KCS5sb2MgMSAxMzQgMA0KCWxkCVslZnArMjAx OV0sICVnMQ0KCXNyYQklZzEsIDAsICVnMQ0KCS5sb2MgMSAxMzkgMA0KCW1v dgklZzEsICVpMA0KCXJldHVybgklaTcrOA0KCSBub3ANCi5MTEZFMTQ6DQoJ LnNpemUJc3NoX21tX3JlY2VpdmVfZmQsIC4tc3NoX21tX3JlY2VpdmVfZmQN Cgkuc2VjdGlvbgkiLmRlYnVnX2ZyYW1lIg0KLkxMZnJhbWUwOg0KCS51YXdv cmQJLkxMRUNJRTAtLkxMU0NJRTANCi5MTFNDSUUwOg0KCS51YXdvcmQJMHhm ZmZmZmZmZg0KCS5ieXRlCTB4MQ0KCS5hc2NpegkiIg0KCS51bGViMTI4IDB4 MQ0KCS5zbGViMTI4IC04DQoJLmJ5dGUJMHhmDQoJLmJ5dGUJMHhjDQoJLnVs ZWIxMjggMHhlDQoJLnVsZWIxMjggMHg3ZmYNCgkuYWxpZ24gOA0KLkxMRUNJ RTA6DQouTExTRkRFMDoNCgkudWF3b3JkCS5MTEVGREUwLS5MTEFTRkRFMA0K LkxMQVNGREUwOg0KCS51YXdvcmQJLkxMZnJhbWUwDQoJLnVheHdvcmQJLkxM RkIxMw0KCS51YXh3b3JkCS5MTEZFMTMtLkxMRkIxMw0KCS5ieXRlCTB4NA0K CS51YXdvcmQJLkxMQ0ZJMC0uTExGQjEzDQoJLmJ5dGUJMHhkDQoJLnVsZWIx MjggMHgxZQ0KCS5ieXRlCTB4MmQNCgkuYnl0ZQkweDkNCgkudWxlYjEyOCAw eGYNCgkudWxlYjEyOCAweDFmDQoJLmFsaWduIDgNCi5MTEVGREUwOg0KLkxM U0ZERTI6DQoJLnVhd29yZAkuTExFRkRFMi0uTExBU0ZERTINCi5MTEFTRkRF MjoNCgkudWF3b3JkCS5MTGZyYW1lMA0KCS51YXh3b3JkCS5MTEZCMTQNCgku dWF4d29yZAkuTExGRTE0LS5MTEZCMTQNCgkuYnl0ZQkweDQNCgkudWF3b3Jk CS5MTENGSTEtLkxMRkIxNA0KCS5ieXRlCTB4ZA0KCS51bGViMTI4IDB4MWUN CgkuYnl0ZQkweDJkDQoJLmJ5dGUJMHg5DQoJLnVsZWIxMjggMHhmDQoJLnVs ZWIxMjggMHgxZg0KCS5hbGlnbiA4DQouTExFRkRFMjoNCgkuc2VjdGlvbgki LnRleHQiDQouTExldGV4dDA6DQoJLnNlY3Rpb24JIi5kZWJ1Z19sb2MiDQou TExkZWJ1Z19sb2MwOg0KLkxMTFNUMDoNCgkudWF4d29yZAkuTExGQjEzLS5M THRleHQwDQoJLnVheHdvcmQJLkxMQ0ZJMC0uTEx0ZXh0MA0KCS51YWhhbGYJ MHgzDQoJLmJ5dGUJMHg3ZQ0KCS5zbGViMTI4IDIwNDcNCgkudWF4d29yZAku TExDRkkwLS5MTHRleHQwDQoJLnVheHdvcmQJLkxMRkUxMy0uTEx0ZXh0MA0K CS51YWhhbGYJMHgzDQoJLmJ5dGUJMHg4ZQ0KCS5zbGViMTI4IDIwNDcNCgku dWF4d29yZAkweDANCgkudWF4d29yZAkweDANCi5MTExTVDE6DQoJLnVheHdv cmQJLkxMRkIxNC0uTEx0ZXh0MA0KCS51YXh3b3JkCS5MTENGSTEtLkxMdGV4 dDANCgkudWFoYWxmCTB4Mw0KCS5ieXRlCTB4N2UNCgkuc2xlYjEyOCAyMDQ3 DQoJLnVheHdvcmQJLkxMQ0ZJMS0uTEx0ZXh0MA0KCS51YXh3b3JkCS5MTEZF MTQtLkxMdGV4dDANCgkudWFoYWxmCTB4Mw0KCS5ieXRlCTB4OGUNCgkuc2xl YjEyOCAyMDQ3DQoJLnVheHdvcmQJMHgwDQoJLnVheHdvcmQJMHgwDQoJLmZp bGUgMiAiL3Vzci9pbmNsdWRlL21hY2hpbmUvX3R5cGVzLmgiDQoJLmZpbGUg MyAiL3Vzci9pbmNsdWRlL3N5cy9fdHlwZXMuaCINCgkuZmlsZSA0ICIvdXNy L2luY2x1ZGUvc3lzL3R5cGVzLmgiDQoJLmZpbGUgNSAiL3Vzci9pbmNsdWRl L3N5cy9faW92ZWMuaCINCgkuZmlsZSA2ICIvdXNyL2luY2x1ZGUvc3lzL3Nv Y2tldC5oIg0KCS5zZWN0aW9uCSIuZGVidWdfaW5mbyINCgkudWF3b3JkCTB4 NDk5DQoJLnVhaGFsZgkweDINCgkudWF3b3JkCS5MTGRlYnVnX2FiYnJldjAN CgkuYnl0ZQkweDgNCgkudWxlYjEyOCAweDENCgkuYXNjaXoJIkdOVSBDIDQu Mi4wIDIwMDcwNTE0IFtGcmVlQlNEXSINCgkuYnl0ZQkweDENCgkuYXNjaXoJ Ii91c3Ivc3JjL3NlY3VyZS9saWIvbGlic3NoLy4uLy4uLy4uL2NyeXB0by9v cGVuc3NoL21vbml0b3JfZmRwYXNzLmMiDQoJLnVheHdvcmQJLkxMdGV4dDAN CgkudWF4d29yZAkuTExldGV4dDANCgkudWF3b3JkCS5MTGRlYnVnX2xpbmUw DQoJLnVsZWIxMjggMHgyDQoJLmJ5dGUJMHgxDQoJLmJ5dGUJMHg2DQoJLmFz Y2l6CSJzaWduZWQgY2hhciINCgkudWxlYjEyOCAweDINCgkuYnl0ZQkweDEN CgkuYnl0ZQkweDgNCgkuYXNjaXoJInVuc2lnbmVkIGNoYXIiDQoJLnVsZWIx MjggMHgyDQoJLmJ5dGUJMHgyDQoJLmJ5dGUJMHg1DQoJLmFzY2l6CSJzaG9y dCBpbnQiDQoJLnVsZWIxMjggMHgyDQoJLmJ5dGUJMHgyDQoJLmJ5dGUJMHg3 DQoJLmFzY2l6CSJzaG9ydCB1bnNpZ25lZCBpbnQiDQoJLnVsZWIxMjggMHgy DQoJLmJ5dGUJMHg0DQoJLmJ5dGUJMHg1DQoJLmFzY2l6CSJpbnQiDQoJLnVs ZWIxMjggMHgzDQoJLmFzY2l6CSJfX3VpbnQzMl90Ig0KCS5ieXRlCTB4Mg0K CS5ieXRlCTB4MzINCgkudWF3b3JkCTB4ZTANCgkudWxlYjEyOCAweDINCgku Ynl0ZQkweDQNCgkuYnl0ZQkweDcNCgkuYXNjaXoJInVuc2lnbmVkIGludCIN CgkudWxlYjEyOCAweDMNCgkuYXNjaXoJIl9faW50NjRfdCINCgkuYnl0ZQkw eDINCgkuYnl0ZQkweDMzDQoJLnVhd29yZAkweDEwMQ0KCS51bGViMTI4IDB4 Mg0KCS5ieXRlCTB4OA0KCS5ieXRlCTB4NQ0KCS5hc2NpegkibG9uZyBpbnQi DQoJLnVsZWIxMjggMHgzDQoJLmFzY2l6CSJfX3VpbnQ2NF90Ig0KCS5ieXRl CTB4Mg0KCS5ieXRlCTB4MzQNCgkudWF3b3JkCTB4MTFmDQoJLnVsZWIxMjgg MHgyDQoJLmJ5dGUJMHg4DQoJLmJ5dGUJMHg3DQoJLmFzY2l6CSJsb25nIHVu c2lnbmVkIGludCINCgkudWxlYjEyOCAweDINCgkuYnl0ZQkweDgNCgkuYnl0 ZQkweDQNCgkuYXNjaXoJImRvdWJsZSINCgkudWxlYjEyOCAweDINCgkuYnl0 ZQkweDQNCgkuYnl0ZQkweDQNCgkuYXNjaXoJImZsb2F0Ig0KCS51bGViMTI4 IDB4Mw0KCS5hc2NpegkiX19zaXplX3QiDQoJLmJ5dGUJMHgyDQoJLmJ5dGUJ MHg0Yw0KCS51YXdvcmQJMHgxMGQNCgkudWxlYjEyOCAweDMNCgkuYXNjaXoJ Il9fc3NpemVfdCINCgkuYnl0ZQkweDINCgkuYnl0ZQkweDRkDQoJLnVhd29y ZAkweGYwDQoJLnVsZWIxMjggMHgzDQoJLmFzY2l6CSJfX3NvY2tsZW5fdCIN CgkuYnl0ZQkweDMNCgkuYnl0ZQkweDNhDQoJLnVhd29yZAkweGNlDQoJLnVs ZWIxMjggMHg0DQoJLmJ5dGUJMHg4DQoJLmJ5dGUJMHg3DQoJLnVsZWIxMjgg MHgyDQoJLmJ5dGUJMHgxDQoJLmJ5dGUJMHg2DQoJLmFzY2l6CSJjaGFyIg0K CS51bGViMTI4IDB4NQ0KCS5ieXRlCTB4OA0KCS51bGViMTI4IDB4Mw0KCS5h c2Npegkic2l6ZV90Ig0KCS5ieXRlCTB4NA0KCS5ieXRlCTB4ZTQNCgkudWF3 b3JkCTB4MTQ3DQoJLnVsZWIxMjggMHgzDQoJLmFzY2l6CSJzc2l6ZV90Ig0K CS5ieXRlCTB4NA0KCS5ieXRlCTB4ZTkNCgkudWF3b3JkCTB4MTU3DQoJLnVs ZWIxMjggMHg2DQoJLmFzY2l6CSJpb3ZlYyINCgkuYnl0ZQkweDEwDQoJLmJ5 dGUJMHg1DQoJLmJ5dGUJMHgyYg0KCS51YXdvcmQJMHgxZDkNCgkudWxlYjEy OCAweDcNCgkuYXNjaXoJImlvdl9iYXNlIg0KCS5ieXRlCTB4NQ0KCS5ieXRl CTB4MmMNCgkudWF3b3JkCTB4MTg2DQoJLmJ5dGUJMHgyDQoJLmJ5dGUJMHgy Mw0KCS51bGViMTI4IDB4MA0KCS51bGViMTI4IDB4Nw0KCS5hc2NpegkiaW92 X2xlbiINCgkuYnl0ZQkweDUNCgkuYnl0ZQkweDJkDQoJLnVhd29yZAkweDE4 OA0KCS5ieXRlCTB4Mg0KCS5ieXRlCTB4MjMNCgkudWxlYjEyOCAweDgNCgku Ynl0ZQkweDANCgkudWxlYjEyOCAweDMNCgkuYXNjaXoJInNvY2tsZW5fdCIN CgkuYnl0ZQkweDYNCgkuYnl0ZQkweDQ5DQoJLnVhd29yZAkweDE2OA0KCS51 bGViMTI4IDB4OA0KCS5hc2NpegkibXNnaGRyIg0KCS5ieXRlCTB4MzANCgku Ynl0ZQkweDYNCgkudWFoYWxmCTB4MTdmDQoJLnVhd29yZAkweDI5NQ0KCS51 bGViMTI4IDB4OQ0KCS5hc2NpegkibXNnX25hbWUiDQoJLmJ5dGUJMHg2DQoJ LnVhaGFsZgkweDE4MA0KCS51YXdvcmQJMHgxODYNCgkuYnl0ZQkweDINCgku Ynl0ZQkweDIzDQoJLnVsZWIxMjggMHgwDQoJLnVsZWIxMjggMHg5DQoJLmFz Y2l6CSJtc2dfbmFtZWxlbiINCgkuYnl0ZQkweDYNCgkudWFoYWxmCTB4MTgx DQoJLnVhd29yZAkweDFkOQ0KCS5ieXRlCTB4Mg0KCS5ieXRlCTB4MjMNCgku dWxlYjEyOCAweDgNCgkudWxlYjEyOCAweDkNCgkuYXNjaXoJIm1zZ19pb3Yi DQoJLmJ5dGUJMHg2DQoJLnVhaGFsZgkweDE4Mg0KCS51YXdvcmQJMHgyOTUN CgkuYnl0ZQkweDINCgkuYnl0ZQkweDIzDQoJLnVsZWIxMjggMHgxMA0KCS51 bGViMTI4IDB4OQ0KCS5hc2NpegkibXNnX2lvdmxlbiINCgkuYnl0ZQkweDYN CgkudWFoYWxmCTB4MTgzDQoJLnVhd29yZAkweGM3DQoJLmJ5dGUJMHgyDQoJ LmJ5dGUJMHgyMw0KCS51bGViMTI4IDB4MTgNCgkudWxlYjEyOCAweDkNCgku YXNjaXoJIm1zZ19jb250cm9sIg0KCS5ieXRlCTB4Ng0KCS51YWhhbGYJMHgx ODQNCgkudWF3b3JkCTB4MTg2DQoJLmJ5dGUJMHgyDQoJLmJ5dGUJMHgyMw0K CS51bGViMTI4IDB4MjANCgkudWxlYjEyOCAweDkNCgkuYXNjaXoJIm1zZ19j b250cm9sbGVuIg0KCS5ieXRlCTB4Ng0KCS51YWhhbGYJMHgxODUNCgkudWF3 b3JkCTB4MWQ5DQoJLmJ5dGUJMHgyDQoJLmJ5dGUJMHgyMw0KCS51bGViMTI4 IDB4MjgNCgkudWxlYjEyOCAweDkNCgkuYXNjaXoJIm1zZ19mbGFncyINCgku Ynl0ZQkweDYNCgkudWFoYWxmCTB4MTg2DQoJLnVhd29yZAkweGM3DQoJLmJ5 dGUJMHgyDQoJLmJ5dGUJMHgyMw0KCS51bGViMTI4IDB4MmMNCgkuYnl0ZQkw eDANCgkudWxlYjEyOCAweGENCgkuYnl0ZQkweDgNCgkudWF3b3JkCTB4MWE1 DQoJLnVsZWIxMjggMHg4DQoJLmFzY2l6CSJjbXNnaGRyIg0KCS5ieXRlCTB4 Yw0KCS5ieXRlCTB4Ng0KCS51YWhhbGYJMHgxYTQNCgkudWF3b3JkCTB4MmVj DQoJLnVsZWIxMjggMHg5DQoJLmFzY2l6CSJjbXNnX2xlbiINCgkuYnl0ZQkw eDYNCgkudWFoYWxmCTB4MWE1DQoJLnVhd29yZAkweDFkOQ0KCS5ieXRlCTB4 Mg0KCS5ieXRlCTB4MjMNCgkudWxlYjEyOCAweDANCgkudWxlYjEyOCAweDkN CgkuYXNjaXoJImNtc2dfbGV2ZWwiDQoJLmJ5dGUJMHg2DQoJLnVhaGFsZgkw eDFhNg0KCS51YXdvcmQJMHhjNw0KCS5ieXRlCTB4Mg0KCS5ieXRlCTB4MjMN CgkudWxlYjEyOCAweDQNCgkudWxlYjEyOCAweDkNCgkuYXNjaXoJImNtc2df dHlwZSINCgkuYnl0ZQkweDYNCgkudWFoYWxmCTB4MWE3DQoJLnVhd29yZAkw eGM3DQoJLmJ5dGUJMHgyDQoJLmJ5dGUJMHgyMw0KCS51bGViMTI4IDB4OA0K CS5ieXRlCTB4MA0KCS51bGViMTI4IDB4Yg0KCS5ieXRlCTB4MQ0KCS5hc2Np egkic3NoX21tX3NlbmRfZmQiDQoJLmJ5dGUJMHgxDQoJLmJ5dGUJMHgyZA0K CS5ieXRlCTB4MQ0KCS51YXh3b3JkCS5MTEZCMTMNCgkudWF4d29yZAkuTExG RTEzDQoJLnVhd29yZAkuTExMU1QwDQoJLnVhd29yZAkweDNhMQ0KCS51bGVi MTI4IDB4Yw0KCS5hc2Npegkic29jayINCgkuYnl0ZQkweDENCgkuYnl0ZQkw eDJjDQoJLnVhd29yZAkweGM3DQoJLmJ5dGUJMHgzDQoJLmJ5dGUJMHg5MQ0K CS5zbGViMTI4IDEyOA0KCS51bGViMTI4IDB4Yw0KCS5hc2NpegkiZmQiDQoJ LmJ5dGUJMHgxDQoJLmJ5dGUJMHgyYw0KCS51YXdvcmQJMHhjNw0KCS5ieXRl CTB4Mw0KCS5ieXRlCTB4OTENCgkuc2xlYjEyOCAxMzYNCgkudWxlYjEyOCAw eGQNCgkuYXNjaXoJIm1zZyINCgkuYnl0ZQkweDENCgkuYnl0ZQkweDJmDQoJ LnVhd29yZAkweDFlYQ0KCS5ieXRlCTB4Mw0KCS5ieXRlCTB4OTENCgkuc2xl YjEyOCAtODANCgkudWxlYjEyOCAweGQNCgkuYXNjaXoJInZlYyINCgkuYnl0 ZQkweDENCgkuYnl0ZQkweDMwDQoJLnVhd29yZAkweDFhNQ0KCS5ieXRlCTB4 Mw0KCS5ieXRlCTB4OTENCgkuc2xlYjEyOCAtOTYNCgkudWxlYjEyOCAweGQN CgkuYXNjaXoJImNoIg0KCS5ieXRlCTB4MQ0KCS5ieXRlCTB4MzENCgkudWF3 b3JkCTB4MTdlDQoJLmJ5dGUJMHgzDQoJLmJ5dGUJMHg5MQ0KCS5zbGViMTI4 IC05Nw0KCS51bGViMTI4IDB4ZA0KCS5hc2NpegkibiINCgkuYnl0ZQkweDEN CgkuYnl0ZQkweDMyDQoJLnVhd29yZAkweDE5Ng0KCS5ieXRlCTB4Mg0KCS5i eXRlCTB4OTENCgkuc2xlYjEyOCAtMzINCgkudWxlYjEyOCAweGQNCgkuYXNj aXoJInRtcCINCgkuYnl0ZQkweDENCgkuYnl0ZQkweDM0DQoJLnVhd29yZAkw eDNhMQ0KCS5ieXRlCTB4Mw0KCS5ieXRlCTB4OTENCgkuc2xlYjEyOCAtMTI5 DQoJLnVsZWIxMjggMHhkDQoJLmFzY2l6CSJjbXNnIg0KCS5ieXRlCTB4MQ0K CS5ieXRlCTB4MzUNCgkudWF3b3JkCTB4M2IxDQoJLmJ5dGUJMHgyDQoJLmJ5 dGUJMHg5MQ0KCS5zbGViMTI4IC0yNA0KCS51bGViMTI4IDB4ZQ0KCS51YXdv cmQJLkxMQVNGMA0KCS51YXdvcmQJMHg0OTcNCgkuYnl0ZQkweDENCgkuYnl0 ZQkweDkNCgkuYnl0ZQkweDMNCgkudWF4d29yZAlfX2Z1bmNfXy41NDMyDQoJ LmJ5dGUJMHgwDQoJLnVsZWIxMjggMHhmDQoJLnVhd29yZAkweDE3ZQ0KCS51 YXdvcmQJMHgzYjENCgkudWxlYjEyOCAweDEwDQoJLnVhd29yZAkweDE3Yg0K CS5ieXRlCTB4MWYNCgkuYnl0ZQkweDANCgkudWxlYjEyOCAweGENCgkuYnl0 ZQkweDgNCgkudWF3b3JkCTB4MjliDQoJLnVsZWIxMjggMHgxMQ0KCS5ieXRl CTB4MQ0KCS5hc2Npegkic3NoX21tX3JlY2VpdmVfZmQiDQoJLmJ5dGUJMHgx DQoJLmJ5dGUJMHg1OQ0KCS5ieXRlCTB4MQ0KCS51YXdvcmQJMHhjNw0KCS51 YXh3b3JkCS5MTEZCMTQNCgkudWF4d29yZAkuTExGRTE0DQoJLnVhd29yZAku TExMU1QxDQoJLnVhd29yZAkweDQ3Mg0KCS51bGViMTI4IDB4Yw0KCS5hc2Np egkic29jayINCgkuYnl0ZQkweDENCgkuYnl0ZQkweDU4DQoJLnVhd29yZAkw eGM3DQoJLmJ5dGUJMHgzDQoJLmJ5dGUJMHg5MQ0KCS5zbGViMTI4IDEyOA0K CS51bGViMTI4IDB4ZA0KCS5hc2NpegkibXNnIg0KCS5ieXRlCTB4MQ0KCS5i eXRlCTB4NWINCgkudWF3b3JkCTB4MWVhDQoJLmJ5dGUJMHgzDQoJLmJ5dGUJ MHg5MQ0KCS5zbGViMTI4IC04OA0KCS51bGViMTI4IDB4ZA0KCS5hc2Npegki dmVjIg0KCS5ieXRlCTB4MQ0KCS5ieXRlCTB4NWMNCgkudWF3b3JkCTB4MWE1 DQoJLmJ5dGUJMHgzDQoJLmJ5dGUJMHg5MQ0KCS5zbGViMTI4IC0xMDQNCgku dWxlYjEyOCAweGQNCgkuYXNjaXoJIm4iDQoJLmJ5dGUJMHgxDQoJLmJ5dGUJ MHg1ZA0KCS51YXdvcmQJMHgxOTYNCgkuYnl0ZQkweDINCgkuYnl0ZQkweDkx DQoJLnNsZWIxMjggLTQwDQoJLnVsZWIxMjggMHhkDQoJLmFzY2l6CSJjaCIN CgkuYnl0ZQkweDENCgkuYnl0ZQkweDVlDQoJLnVhd29yZAkweDE3ZQ0KCS5i eXRlCTB4Mw0KCS5ieXRlCTB4OTENCgkuc2xlYjEyOCAtMTA1DQoJLnVsZWIx MjggMHhkDQoJLmFzY2l6CSJmZCINCgkuYnl0ZQkweDENCgkuYnl0ZQkweDVm DQoJLnVhd29yZAkweGM3DQoJLmJ5dGUJMHgyDQoJLmJ5dGUJMHg5MQ0KCS5z bGViMTI4IC0yOA0KCS51bGViMTI4IDB4ZA0KCS5hc2NpegkidG1wIg0KCS5i eXRlCTB4MQ0KCS5ieXRlCTB4NjENCgkudWF3b3JkCTB4M2ExDQoJLmJ5dGUJ MHgzDQoJLmJ5dGUJMHg5MQ0KCS5zbGViMTI4IC0xMzcNCgkudWxlYjEyOCAw eGQNCgkuYXNjaXoJImNtc2ciDQoJLmJ5dGUJMHgxDQoJLmJ5dGUJMHg2Mg0K CS51YXdvcmQJMHgzYjENCgkuYnl0ZQkweDINCgkuYnl0ZQkweDkxDQoJLnNs ZWIxMjggLTI0DQoJLnVsZWIxMjggMHhlDQoJLnVhd29yZAkuTExBU0YwDQoJ LnVhd29yZAkweDQ4Mg0KCS5ieXRlCTB4MQ0KCS5ieXRlCTB4OQ0KCS5ieXRl CTB4Mw0KCS51YXh3b3JkCV9fZnVuY19fLjU0NjANCgkuYnl0ZQkweDANCgku dWxlYjEyOCAweGYNCgkudWF3b3JkCTB4MTdlDQoJLnVhd29yZAkweDQ4Mg0K CS51bGViMTI4IDB4MTANCgkudWF3b3JkCTB4MTdiDQoJLmJ5dGUJMHgxMQ0K CS5ieXRlCTB4MA0KCS51bGViMTI4IDB4MTINCgkudWF3b3JkCTB4NDcyDQoJ LnVsZWIxMjggMHhmDQoJLnVhd29yZAkweDE3ZQ0KCS51YXdvcmQJMHg0OTcN CgkudWxlYjEyOCAweDEwDQoJLnVhd29yZAkweDE3Yg0KCS5ieXRlCTB4ZQ0K CS5ieXRlCTB4MA0KCS51bGViMTI4IDB4MTINCgkudWF3b3JkCTB4NDg3DQoJ LmJ5dGUJMHgwDQoJLnNlY3Rpb24JIi5kZWJ1Z19hYmJyZXYiDQoJLnVsZWIx MjggMHgxDQoJLnVsZWIxMjggMHgxMQ0KCS5ieXRlCTB4MQ0KCS51bGViMTI4 IDB4MjUNCgkudWxlYjEyOCAweDgNCgkudWxlYjEyOCAweDEzDQoJLnVsZWIx MjggMHhiDQoJLnVsZWIxMjggMHgzDQoJLnVsZWIxMjggMHg4DQoJLnVsZWIx MjggMHgxMQ0KCS51bGViMTI4IDB4MQ0KCS51bGViMTI4IDB4MTINCgkudWxl YjEyOCAweDENCgkudWxlYjEyOCAweDEwDQoJLnVsZWIxMjggMHg2DQoJLmJ5 dGUJMHgwDQoJLmJ5dGUJMHgwDQoJLnVsZWIxMjggMHgyDQoJLnVsZWIxMjgg MHgyNA0KCS5ieXRlCTB4MA0KCS51bGViMTI4IDB4Yg0KCS51bGViMTI4IDB4 Yg0KCS51bGViMTI4IDB4M2UNCgkudWxlYjEyOCAweGINCgkudWxlYjEyOCAw eDMNCgkudWxlYjEyOCAweDgNCgkuYnl0ZQkweDANCgkuYnl0ZQkweDANCgku dWxlYjEyOCAweDMNCgkudWxlYjEyOCAweDE2DQoJLmJ5dGUJMHgwDQoJLnVs ZWIxMjggMHgzDQoJLnVsZWIxMjggMHg4DQoJLnVsZWIxMjggMHgzYQ0KCS51 bGViMTI4IDB4Yg0KCS51bGViMTI4IDB4M2INCgkudWxlYjEyOCAweGINCgku dWxlYjEyOCAweDQ5DQoJLnVsZWIxMjggMHgxMw0KCS5ieXRlCTB4MA0KCS5i eXRlCTB4MA0KCS51bGViMTI4IDB4NA0KCS51bGViMTI4IDB4MjQNCgkuYnl0 ZQkweDANCgkudWxlYjEyOCAweGINCgkudWxlYjEyOCAweGINCgkudWxlYjEy OCAweDNlDQoJLnVsZWIxMjggMHhiDQoJLmJ5dGUJMHgwDQoJLmJ5dGUJMHgw DQoJLnVsZWIxMjggMHg1DQoJLnVsZWIxMjggMHhmDQoJLmJ5dGUJMHgwDQoJ LnVsZWIxMjggMHhiDQoJLnVsZWIxMjggMHhiDQoJLmJ5dGUJMHgwDQoJLmJ5 dGUJMHgwDQoJLnVsZWIxMjggMHg2DQoJLnVsZWIxMjggMHgxMw0KCS5ieXRl CTB4MQ0KCS51bGViMTI4IDB4Mw0KCS51bGViMTI4IDB4OA0KCS51bGViMTI4 IDB4Yg0KCS51bGViMTI4IDB4Yg0KCS51bGViMTI4IDB4M2ENCgkudWxlYjEy OCAweGINCgkudWxlYjEyOCAweDNiDQoJLnVsZWIxMjggMHhiDQoJLnVsZWIx MjggMHgxDQoJLnVsZWIxMjggMHgxMw0KCS5ieXRlCTB4MA0KCS5ieXRlCTB4 MA0KCS51bGViMTI4IDB4Nw0KCS51bGViMTI4IDB4ZA0KCS5ieXRlCTB4MA0K CS51bGViMTI4IDB4Mw0KCS51bGViMTI4IDB4OA0KCS51bGViMTI4IDB4M2EN CgkudWxlYjEyOCAweGINCgkudWxlYjEyOCAweDNiDQoJLnVsZWIxMjggMHhi DQoJLnVsZWIxMjggMHg0OQ0KCS51bGViMTI4IDB4MTMNCgkudWxlYjEyOCAw eDM4DQoJLnVsZWIxMjggMHhhDQoJLmJ5dGUJMHgwDQoJLmJ5dGUJMHgwDQoJ LnVsZWIxMjggMHg4DQoJLnVsZWIxMjggMHgxMw0KCS5ieXRlCTB4MQ0KCS51 bGViMTI4IDB4Mw0KCS51bGViMTI4IDB4OA0KCS51bGViMTI4IDB4Yg0KCS51 bGViMTI4IDB4Yg0KCS51bGViMTI4IDB4M2ENCgkudWxlYjEyOCAweGINCgku dWxlYjEyOCAweDNiDQoJLnVsZWIxMjggMHg1DQoJLnVsZWIxMjggMHgxDQoJ LnVsZWIxMjggMHgxMw0KCS5ieXRlCTB4MA0KCS5ieXRlCTB4MA0KCS51bGVi MTI4IDB4OQ0KCS51bGViMTI4IDB4ZA0KCS5ieXRlCTB4MA0KCS51bGViMTI4 IDB4Mw0KCS51bGViMTI4IDB4OA0KCS51bGViMTI4IDB4M2ENCgkudWxlYjEy OCAweGINCgkudWxlYjEyOCAweDNiDQoJLnVsZWIxMjggMHg1DQoJLnVsZWIx MjggMHg0OQ0KCS51bGViMTI4IDB4MTMNCgkudWxlYjEyOCAweDM4DQoJLnVs ZWIxMjggMHhhDQoJLmJ5dGUJMHgwDQoJLmJ5dGUJMHgwDQoJLnVsZWIxMjgg MHhhDQoJLnVsZWIxMjggMHhmDQoJLmJ5dGUJMHgwDQoJLnVsZWIxMjggMHhi DQoJLnVsZWIxMjggMHhiDQoJLnVsZWIxMjggMHg0OQ0KCS51bGViMTI4IDB4 MTMNCgkuYnl0ZQkweDANCgkuYnl0ZQkweDANCgkudWxlYjEyOCAweGINCgku dWxlYjEyOCAweDJlDQoJLmJ5dGUJMHgxDQoJLnVsZWIxMjggMHgzZg0KCS51 bGViMTI4IDB4Yw0KCS51bGViMTI4IDB4Mw0KCS51bGViMTI4IDB4OA0KCS51 bGViMTI4IDB4M2ENCgkudWxlYjEyOCAweGINCgkudWxlYjEyOCAweDNiDQoJ LnVsZWIxMjggMHhiDQoJLnVsZWIxMjggMHgyNw0KCS51bGViMTI4IDB4Yw0K CS51bGViMTI4IDB4MTENCgkudWxlYjEyOCAweDENCgkudWxlYjEyOCAweDEy DQoJLnVsZWIxMjggMHgxDQoJLnVsZWIxMjggMHg0MA0KCS51bGViMTI4IDB4 Ng0KCS51bGViMTI4IDB4MQ0KCS51bGViMTI4IDB4MTMNCgkuYnl0ZQkweDAN CgkuYnl0ZQkweDANCgkudWxlYjEyOCAweGMNCgkudWxlYjEyOCAweDUNCgku Ynl0ZQkweDANCgkudWxlYjEyOCAweDMNCgkudWxlYjEyOCAweDgNCgkudWxl YjEyOCAweDNhDQoJLnVsZWIxMjggMHhiDQoJLnVsZWIxMjggMHgzYg0KCS51 bGViMTI4IDB4Yg0KCS51bGViMTI4IDB4NDkNCgkudWxlYjEyOCAweDEzDQoJ LnVsZWIxMjggMHgyDQoJLnVsZWIxMjggMHhhDQoJLmJ5dGUJMHgwDQoJLmJ5 dGUJMHgwDQoJLnVsZWIxMjggMHhkDQoJLnVsZWIxMjggMHgzNA0KCS5ieXRl CTB4MA0KCS51bGViMTI4IDB4Mw0KCS51bGViMTI4IDB4OA0KCS51bGViMTI4 IDB4M2ENCgkudWxlYjEyOCAweGINCgkudWxlYjEyOCAweDNiDQoJLnVsZWIx MjggMHhiDQoJLnVsZWIxMjggMHg0OQ0KCS51bGViMTI4IDB4MTMNCgkudWxl YjEyOCAweDINCgkudWxlYjEyOCAweGENCgkuYnl0ZQkweDANCgkuYnl0ZQkw eDANCgkudWxlYjEyOCAweGUNCgkudWxlYjEyOCAweDM0DQoJLmJ5dGUJMHgw DQoJLnVsZWIxMjggMHgzDQoJLnVsZWIxMjggMHhlDQoJLnVsZWIxMjggMHg0 OQ0KCS51bGViMTI4IDB4MTMNCgkudWxlYjEyOCAweDM0DQoJLnVsZWIxMjgg MHhjDQoJLnVsZWIxMjggMHgyDQoJLnVsZWIxMjggMHhhDQoJLmJ5dGUJMHgw DQoJLmJ5dGUJMHgwDQoJLnVsZWIxMjggMHhmDQoJLnVsZWIxMjggMHgxDQoJ LmJ5dGUJMHgxDQoJLnVsZWIxMjggMHg0OQ0KCS51bGViMTI4IDB4MTMNCgku dWxlYjEyOCAweDENCgkudWxlYjEyOCAweDEzDQoJLmJ5dGUJMHgwDQoJLmJ5 dGUJMHgwDQoJLnVsZWIxMjggMHgxMA0KCS51bGViMTI4IDB4MjENCgkuYnl0 ZQkweDANCgkudWxlYjEyOCAweDQ5DQoJLnVsZWIxMjggMHgxMw0KCS51bGVi MTI4IDB4MmYNCgkudWxlYjEyOCAweGINCgkuYnl0ZQkweDANCgkuYnl0ZQkw eDANCgkudWxlYjEyOCAweDExDQoJLnVsZWIxMjggMHgyZQ0KCS5ieXRlCTB4 MQ0KCS51bGViMTI4IDB4M2YNCgkudWxlYjEyOCAweGMNCgkudWxlYjEyOCAw eDMNCgkudWxlYjEyOCAweDgNCgkudWxlYjEyOCAweDNhDQoJLnVsZWIxMjgg MHhiDQoJLnVsZWIxMjggMHgzYg0KCS51bGViMTI4IDB4Yg0KCS51bGViMTI4 IDB4MjcNCgkudWxlYjEyOCAweGMNCgkudWxlYjEyOCAweDQ5DQoJLnVsZWIx MjggMHgxMw0KCS51bGViMTI4IDB4MTENCgkudWxlYjEyOCAweDENCgkudWxl YjEyOCAweDEyDQoJLnVsZWIxMjggMHgxDQoJLnVsZWIxMjggMHg0MA0KCS51 bGViMTI4IDB4Ng0KCS51bGViMTI4IDB4MQ0KCS51bGViMTI4IDB4MTMNCgku Ynl0ZQkweDANCgkuYnl0ZQkweDANCgkudWxlYjEyOCAweDEyDQoJLnVsZWIx MjggMHgyNg0KCS5ieXRlCTB4MA0KCS51bGViMTI4IDB4NDkNCgkudWxlYjEy OCAweDEzDQoJLmJ5dGUJMHgwDQoJLmJ5dGUJMHgwDQoJLmJ5dGUJMHgwDQoJ LnNlY3Rpb24JIi5kZWJ1Z19wdWJuYW1lcyINCgkudWF3b3JkCTB4MzcNCgku dWFoYWxmCTB4Mg0KCS51YXdvcmQJLkxMZGVidWdfaW5mbzANCgkudWF3b3Jk CTB4NDlkDQoJLnVhd29yZAkweDJlYw0KCS5hc2Npegkic3NoX21tX3NlbmRf ZmQiDQoJLnVhd29yZAkweDNiNw0KCS5hc2Npegkic3NoX21tX3JlY2VpdmVf ZmQiDQoJLnVhd29yZAkweDANCgkuc2VjdGlvbgkiLmRlYnVnX2FyYW5nZXMi DQoJLnVhd29yZAkweDJjDQoJLnVhaGFsZgkweDINCgkudWF3b3JkCS5MTGRl YnVnX2luZm8wDQoJLmJ5dGUJMHg4DQoJLmJ5dGUJMHgwDQoJLnVhaGFsZgkw eDANCgkudWFoYWxmCTB4MA0KCS51YXh3b3JkCS5MTHRleHQwDQoJLnVheHdv cmQJLkxMZXRleHQwLS5MTHRleHQwDQoJLnVheHdvcmQJMHgwDQoJLnVheHdv cmQJMHgwDQoJLnNlY3Rpb24JIi5kZWJ1Z19zdHIiDQouTExBU0YwOg0KCS5h c2NpegkiX19mdW5jX18iDQoJLmlkZW50CSJHQ0M6IChHTlUpIDQuMi4wIDIw MDcwNTE0IFtGcmVlQlNEXSINCg== ---559023410-758783491-1184532601=:29570 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=monitor_fdpass_O1.s Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename=monitor_fdpass_O1.s CS5maWxlCSJtb25pdG9yX2ZkcGFzcy5jIg0KCS5zZWN0aW9uCSIuZGVidWdf YWJicmV2Ig0KLkxMZGVidWdfYWJicmV2MDoNCgkuc2VjdGlvbgkiLmRlYnVn X2luZm8iDQouTExkZWJ1Z19pbmZvMDoNCgkuc2VjdGlvbgkiLmRlYnVnX2xp bmUiDQouTExkZWJ1Z19saW5lMDoNCgkuc2VjdGlvbgkiLnRleHQiDQouTEx0 ZXh0MDoNCgkuc2VjdGlvbgkucm9kYXRhLnN0cjEuOCwiYU1TIixAcHJvZ2Jp dHMsMQ0KCS5hbGlnbiA4DQouTExDMDoNCgkuYXNjaXoJIiVzOiByZWN2bXNn OiAlcyINCgkuYWxpZ24gOA0KLkxMQzE6DQoJLmFzY2l6CSIlczogcmVjdm1z ZzogZXhwZWN0ZWQgcmVjZWl2ZWQgMSBnb3QgJWxkIg0KCS5hbGlnbiA4DQou TExDMjoNCgkuYXNjaXoJIiVzOiBubyBtZXNzYWdlIGhlYWRlciINCgkuYWxp Z24gOA0KLkxMQzM6DQoJLmFzY2l6CSIlczogZXhwZWN0ZWQgdHlwZSAlZCBn b3QgJWQiDQoJLnNlY3Rpb24JIi50ZXh0Ig0KCS5hbGlnbiA0DQouTExBRERQ QzA6DQoJam1wCSVvNys4DQoJIGFkZAklbzcsICVsNywgJWw3DQoJLmFsaWdu IDQNCgkuYWxpZ24gMzINCgkuZ2xvYmFsIHNzaF9tbV9yZWNlaXZlX2ZkDQoJ LnR5cGUJc3NoX21tX3JlY2VpdmVfZmQsICNmdW5jdGlvbg0KCS5wcm9jCTA0 DQpzc2hfbW1fcmVjZWl2ZV9mZDoNCi5MTEZCMTQ6DQoJLmZpbGUgMSAiL3Vz ci9zcmMvc2VjdXJlL2xpYi9saWJzc2gvLi4vLi4vLi4vY3J5cHRvL29wZW5z c2gvbW9uaXRvcl9mZHBhc3MuYyINCgkubG9jIDEgODkgMA0KCS5yZWdpc3Rl cgklZzIsICNzY3JhdGNoDQouTExWTDA6DQoJc2F2ZQklc3AsIC0zMDQsICVz cA0KLkxMQ0ZJMDoNCglzZXRoaQklaGkoX0dMT0JBTF9PRkZTRVRfVEFCTEVf LTQpLCAlbDcNCgljYWxsCS5MTEFERFBDMA0KCSBhZGQJJWw3LCAlbG8oX0dM T0JBTF9PRkZTRVRfVEFCTEVfKzQpLCAlbDcNCgkubG9jIDEgMTAxIDANCglz dHgJJWcwLCBbJWZwKzE5ODNdDQoJc3R4CSVnMCwgWyVmcCsxOTkxXQ0KCXN0 eAklZzAsIFslZnArMjAwN10NCglzdHgJJWcwLCBbJWZwKzIwMjNdDQoJLmxv YyAxIDEwMiAwDQoJYWRkCSVmcCwgMTk2NiwgJWcxDQoJc3R4CSVnMSwgWyVm cCsxOTY3XQ0KCS5sb2MgMSAxMDMgMA0KCW1vdgkxLCAlZzINCglzdHgJJWcy LCBbJWZwKzE5NzVdDQoJLmxvYyAxIDEwNCAwDQoJYWRkCSVmcCwgMTk2Nywg JWcxDQoJc3R4CSVnMSwgWyVmcCsxOTk5XQ0KCS5sb2MgMSAxMDUgMA0KCXN0 CSVnMiwgWyVmcCsyMDA3XQ0KCS5sb2MgMSAxMTAgMA0KCWFkZAklZnAsIDE5 MzQsICVnMQ0KCXN0eAklZzEsIFslZnArMjAxNV0NCgkubG9jIDEgMTExIDAN Cgltb3YJMzIsICVnMQ0KCXN0CSVnMSwgWyVmcCsyMDIzXQ0KCS5sb2MgMSAx MTQgMA0KCW1vdgklaTAsICVvMA0KCWFkZAklZnAsIDE5ODMsICVvMQ0KCWNh bGwJcmVjdm1zZywgMA0KCSBtb3YJMCwgJW8yDQouTExWTDE6DQoJY21wCSVv MCwgLTENCglibmUscHQJJXhjYywgLkxMMg0KCSBtb3YJJW8wLCAlbzINCi5M TFZMMjoNCgkubG9jIDEgMTE1IDANCgljYWxsCV9fZXJyb3IsIDANCgkgbm9w DQouTExWTDM6DQoJY2FsbAlzdHJlcnJvciwgMA0KCSBsZHN3CVslbzBdLCAl bzANCgltb3YJJW8wLCAlbzINCglzZXRoaQklaGkoLkxMQzApLCAlZzENCglv cgklZzEsICVsbyguTExDMCksICVnMQ0KCWxkeAlbJWw3KyVnMV0sICVvMA0K CXNldGhpCSVoaShfX2Z1bmNfXy41NDM0KSwgJWcxDQoJb3IJJWcxLCAlbG8o X19mdW5jX18uNTQzNCksICVnMQ0KCWNhbGwJc3NoX2ZhdGFsLCAwDQoJIGxk eAlbJWw3KyVnMV0sICVvMQ0KLkxMVkw0Og0KLkxMMjoNCgkubG9jIDEgMTE2 IDANCgljbXAJJW8wLCAxDQoJLmxvYyAxIDEyNCAwDQoJLmxvYyAxIDExNiAw DQoJYmUscHQJJXhjYywgLkxMNA0KCSBsZHV3CVslZnArMjAyM10sICVnMQ0K CS5sb2MgMSAxMTcgMA0KCXNldGhpCSVoaSguTExDMSksICVnMQ0KCW9yCSVn MSwgJWxvKC5MTEMxKSwgJWcxDQoJbGR4CVslbDcrJWcxXSwgJW8wDQouTExW TDU6DQoJc2V0aGkJJWhpKF9fZnVuY19fLjU0MzQpLCAlZzENCglvcgklZzEs ICVsbyhfX2Z1bmNfXy41NDM0KSwgJWcxDQoJY2FsbAlzc2hfZmF0YWwsIDAN CgkgbGR4CVslbDcrJWcxXSwgJW8xDQouTExWTDY6DQouTEw0Og0KCS5sb2Mg MSAxMjQgMA0KCWNtcAklZzEsIDExDQoJYmxldSxwbgklaWNjLCAuTEw2DQoJ IGxkeAlbJWZwKzIwMTVdLCAlZzENCgkubG9jIDEgMTI4IDANCgkubG9jIDEg MTI1IDANCglicm56LGEscHQgJWcxLCAuTEw4DQoJIGxkdXcJWyVnMSs4XSwg JW8zDQouTEw2Og0KCS5sb2MgMSAxMjYgMA0KCXNldGhpCSVoaSguTExDMiks ICVnMQ0KCW9yCSVnMSwgJWxvKC5MTEMyKSwgJWcxDQoJbGR4CVslbDcrJWcx XSwgJW8wDQouTExWTDc6DQoJc2V0aGkJJWhpKF9fZnVuY19fLjU0MzQpLCAl ZzENCglvcgklZzEsICVsbyhfX2Z1bmNfXy41NDM0KSwgJWcxDQoJY2FsbAlz c2hfZmF0YWwsIDANCgkgbGR4CVslbDcrJWcxXSwgJW8xDQouTExWTDg6DQou TEw4Og0KLkxMVkw5Og0KCS5sb2MgMSAxMjggMA0KCWNtcAklbzMsIDENCgku bG9jIDEgMTI5IDANCgkubG9jIDEgMTI4IDANCgliZSxwdAklaWNjLCAuTEw5 DQoJIG1vdgkxLCAlbzINCgkubG9jIDEgMTI5IDANCglzZXRoaQklaGkoLkxM QzMpLCAlZzENCi5MTFZMMTA6DQoJb3IJJWcxLCAlbG8oLkxMQzMpLCAlZzEN CglsZHgJWyVsNyslZzFdLCAlbzANCi5MTFZMMTE6DQoJc2V0aGkJJWhpKF9f ZnVuY19fLjU0MzQpLCAlZzENCglvcgklZzEsICVsbyhfX2Z1bmNfXy41NDM0 KSwgJWcxDQoJbGR4CVslbDcrJWcxXSwgJW8xDQouTExWTDEyOg0KCWNhbGwJ c3NoX2ZhdGFsLCAwDQoJIHNyYQklbzMsIDAsICVvMw0KLkxMVkwxMzoNCi5M TDk6DQouTExWTDE0Og0KCS5sb2MgMSAxMzkgMA0KCXJldHVybgklaTcrOA0K CSBsZHN3CVslZzErMTZdLCAlbzANCi5MTEZFMTQ6DQoJLnNpemUJc3NoX21t X3JlY2VpdmVfZmQsIC4tc3NoX21tX3JlY2VpdmVfZmQNCgkuc2VjdGlvbgku cm9kYXRhLnN0cjEuOA0KCS5hbGlnbiA4DQouTExDNDoNCgkuYXNjaXoJIiVz OiBzZW5kbXNnKCVkKTogJXMiDQoJLmFsaWduIDgNCi5MTEM1Og0KCS5hc2Np egkiJXM6IHNlbmRtc2c6IGV4cGVjdGVkIHNlbnQgMSBnb3QgJWxkIg0KCS5z ZWN0aW9uCSIudGV4dCINCgkuYWxpZ24gNA0KCS5hbGlnbiAzMg0KCS5nbG9i YWwgc3NoX21tX3NlbmRfZmQNCgkudHlwZQlzc2hfbW1fc2VuZF9mZCwgI2Z1 bmN0aW9uDQoJLnByb2MJMDIwDQpzc2hfbW1fc2VuZF9mZDoNCi5MTEZCMTM6 DQoJLmxvYyAxIDQ1IDANCi5MTFZMMTU6DQoJc2F2ZQklc3AsIC0zMDQsICVz cA0KLkxMQ0ZJMToNCglzZXRoaQklaGkoX0dMT0JBTF9PRkZTRVRfVEFCTEVf LTQpLCAlbDcNCgljYWxsCS5MTEFERFBDMA0KCSBhZGQJJWw3LCAlbG8oX0dM T0JBTF9PRkZTRVRfVEFCTEVfKzQpLCAlbDcNCgkubG9jIDEgNDkgMA0KCXN0 YgklZzAsIFslZnArMTk2Nl0NCi5MTFZMMTY6DQoJLmxvYyAxIDU2IDANCglz dHgJJWcwLCBbJWZwKzE5ODNdDQoJc3R4CSVnMCwgWyVmcCsxOTkxXQ0KCXN0 eAklZzAsIFslZnArMjAwN10NCglzdHgJJWcwLCBbJWZwKzIwMjNdDQoJLmxv YyAxIDYxIDANCglhZGQJJWZwLCAxOTM0LCAlZzENCglzdHgJJWcxLCBbJWZw KzIwMTVdDQoJLmxvYyAxIDYyIDANCgltb3YJMjAsICVnMQ0KCXN0CSVnMSwg WyVmcCsyMDIzXQ0KCS5sb2MgMSA2NCAwDQoJc3QJJWcxLCBbJWZwKzE5MzRd DQoJLmxvYyAxIDY1IDANCglzZXRoaQklaGkoNjQ1MTIpLCAlZzENCglvcgkl ZzEsIDEwMjMsICVnMQ0KCXN0CSVnMSwgWyVmcCsxOTM4XQ0KCS5sb2MgMSA2 NiAwDQoJbW92CTEsICVnMQ0KCXN0CSVnMSwgWyVmcCsxOTQyXQ0KCS5sb2Mg MSA2NyAwDQoJc3QJJWkxLCBbJWZwKzE5NTBdDQoJLmxvYyAxIDcwIDANCglh ZGQJJWZwLCAxOTY2LCAlZzENCglzdHgJJWcxLCBbJWZwKzE5NjddDQoJLmxv YyAxIDcxIDANCgltb3YJMSwgJWcyDQoJc3R4CSVnMiwgWyVmcCsxOTc1XQ0K CS5sb2MgMSA3MiAwDQoJYWRkCSVmcCwgMTk2NywgJWcxDQoJc3R4CSVnMSwg WyVmcCsxOTk5XQ0KCS5sb2MgMSA3MyAwDQoJc3QJJWcyLCBbJWZwKzIwMDdd DQoJLmxvYyAxIDc1IDANCgltb3YJJWkwLCAlbzANCglhZGQJJWZwLCAxOTgz LCAlbzENCgljYWxsCXNlbmRtc2csIDANCgkgbW92CTAsICVvMg0KLkxMVkwx NzoNCgljbXAJJW8wLCAtMQ0KCWJuZSxwdAkleGNjLCAuTEwxMw0KCSBtb3YJ JW8wLCAlbzINCi5MTFZMMTg6DQoJLmxvYyAxIDc2IDANCgljYWxsCV9fZXJy b3IsIDANCgkgbm9wDQouTExWTDE5Og0KCWNhbGwJc3RyZXJyb3IsIDANCgkg bGRzdwlbJW8wXSwgJW8wDQoJbW92CSVvMCwgJW8zDQoJc2V0aGkJJWhpKC5M TEM0KSwgJWcxDQoJb3IJJWcxLCAlbG8oLkxMQzQpLCAlZzENCglsZHgJWyVs NyslZzFdLCAlbzANCglzZXRoaQklaGkoX19mdW5jX18uNTQxMyksICVnMQ0K CW9yCSVnMSwgJWxvKF9fZnVuY19fLjU0MTMpLCAlZzENCglsZHgJWyVsNysl ZzFdLCAlbzENCgljYWxsCXNzaF9mYXRhbCwgMA0KCSBtb3YJJWkxLCAlbzIN Ci5MTFZMMjA6DQouTEwxMzoNCgkubG9jIDEgNzggMA0KCWNtcAklbzAsIDEN CgkubG9jIDEgNzkgMA0KCS5sb2MgMSA3OCAwDQoJYmUscHQJJXhjYywgLkxM MTgNCgkgc2V0aGkJJWhpKC5MTEM1KSwgJWcxDQoJLmxvYyAxIDc5IDANCglv cgklZzEsICVsbyguTExDNSksICVnMQ0KCWxkeAlbJWw3KyVnMV0sICVvMA0K LkxMVkwyMToNCglzZXRoaQklaGkoX19mdW5jX18uNTQxMyksICVnMQ0KCW9y CSVnMSwgJWxvKF9fZnVuY19fLjU0MTMpLCAlZzENCgljYWxsCXNzaF9mYXRh bCwgMA0KCSBsZHgJWyVsNyslZzFdLCAlbzENCi5MTFZMMjI6DQouTExWTDIz Og0KLkxMMTg6DQoJcmV0dXJuCSVpNys4DQoJIG5vcA0KLkxMRkUxMzoNCgku c2l6ZQlzc2hfbW1fc2VuZF9mZCwgLi1zc2hfbW1fc2VuZF9mZA0KCS5zZWN0 aW9uCSIucm9kYXRhIg0KCS5hbGlnbiA4DQoJLnR5cGUJX19mdW5jX18uNTQz NCwgI29iamVjdA0KCS5zaXplCV9fZnVuY19fLjU0MzQsIDE4DQpfX2Z1bmNf Xy41NDM0Og0KCS5hc2Npegkic3NoX21tX3JlY2VpdmVfZmQiDQoJLmFsaWdu IDgNCgkudHlwZQlfX2Z1bmNfXy41NDEzLCAjb2JqZWN0DQoJLnNpemUJX19m dW5jX18uNTQxMywgMTUNCl9fZnVuY19fLjU0MTM6DQoJLmFzY2l6CSJzc2hf bW1fc2VuZF9mZCINCgkuc2VjdGlvbgkiLmRlYnVnX2ZyYW1lIg0KLkxMZnJh bWUwOg0KCS51YXdvcmQJLkxMRUNJRTAtLkxMU0NJRTANCi5MTFNDSUUwOg0K CS51YXdvcmQJMHhmZmZmZmZmZg0KCS5ieXRlCTB4MQ0KCS5hc2NpegkiIg0K CS51bGViMTI4IDB4MQ0KCS5zbGViMTI4IC04DQoJLmJ5dGUJMHhmDQoJLmJ5 dGUJMHhjDQoJLnVsZWIxMjggMHhlDQoJLnVsZWIxMjggMHg3ZmYNCgkuYWxp Z24gOA0KLkxMRUNJRTA6DQouTExTRkRFMDoNCgkudWF3b3JkCS5MTEVGREUw LS5MTEFTRkRFMA0KLkxMQVNGREUwOg0KCS51YXdvcmQJLkxMZnJhbWUwDQoJ LnVheHdvcmQJLkxMRkIxNA0KCS51YXh3b3JkCS5MTEZFMTQtLkxMRkIxNA0K CS5ieXRlCTB4NA0KCS51YXdvcmQJLkxMQ0ZJMC0uTExGQjE0DQoJLmJ5dGUJ MHhkDQoJLnVsZWIxMjggMHgxZQ0KCS5ieXRlCTB4MmQNCgkuYnl0ZQkweDkN CgkudWxlYjEyOCAweGYNCgkudWxlYjEyOCAweDFmDQoJLmFsaWduIDgNCi5M TEVGREUwOg0KLkxMU0ZERTI6DQoJLnVhd29yZAkuTExFRkRFMi0uTExBU0ZE RTINCi5MTEFTRkRFMjoNCgkudWF3b3JkCS5MTGZyYW1lMA0KCS51YXh3b3Jk CS5MTEZCMTMNCgkudWF4d29yZAkuTExGRTEzLS5MTEZCMTMNCgkuYnl0ZQkw eDQNCgkudWF3b3JkCS5MTENGSTEtLkxMRkIxMw0KCS5ieXRlCTB4ZA0KCS51 bGViMTI4IDB4MWUNCgkuYnl0ZQkweDJkDQoJLmJ5dGUJMHg5DQoJLnVsZWIx MjggMHhmDQoJLnVsZWIxMjggMHgxZg0KCS5hbGlnbiA4DQouTExFRkRFMjoN Cgkuc2VjdGlvbgkiLnRleHQiDQouTExldGV4dDA6DQoJLnNlY3Rpb24JIi5k ZWJ1Z19sb2MiDQouTExkZWJ1Z19sb2MwOg0KLkxMTFNUMDoNCgkudWF4d29y ZAkuTExGQjE0LS5MTHRleHQwDQoJLnVheHdvcmQJLkxMQ0ZJMC0uTEx0ZXh0 MA0KCS51YWhhbGYJMHgzDQoJLmJ5dGUJMHg3ZQ0KCS5zbGViMTI4IDIwNDcN CgkudWF4d29yZAkuTExDRkkwLS5MTHRleHQwDQoJLnVheHdvcmQJLkxMRkUx NC0uTEx0ZXh0MA0KCS51YWhhbGYJMHgzDQoJLmJ5dGUJMHg4ZQ0KCS5zbGVi MTI4IDIwNDcNCgkudWF4d29yZAkweDANCgkudWF4d29yZAkweDANCi5MTExT VDE6DQoJLnVheHdvcmQJLkxMVkwwLS5MTHRleHQwDQoJLnVheHdvcmQJLkxM VkwxNC0uTEx0ZXh0MA0KCS51YWhhbGYJMHgxDQoJLmJ5dGUJMHg2OA0KCS51 YXh3b3JkCTB4MA0KCS51YXh3b3JkCTB4MA0KLkxMTFNUMjoNCgkudWF4d29y ZAkuTExWTDEtLkxMdGV4dDANCgkudWF4d29yZAkuTExWTDItLkxMdGV4dDAN CgkudWFoYWxmCTB4MQ0KCS5ieXRlCTB4NWENCgkudWF4d29yZAkuTExWTDIt LkxMdGV4dDANCgkudWF4d29yZAkuTExWTDMtLkxMdGV4dDANCgkudWFoYWxm CTB4MQ0KCS5ieXRlCTB4NTgNCgkudWF4d29yZAkuTExWTDQtLkxMdGV4dDAN CgkudWF4d29yZAkuTExWTDUtLkxMdGV4dDANCgkudWFoYWxmCTB4MQ0KCS5i eXRlCTB4NTgNCgkudWF4d29yZAkuTExWTDUtLkxMdGV4dDANCgkudWF4d29y ZAkuTExWTDYtLkxMdGV4dDANCgkudWFoYWxmCTB4MQ0KCS5ieXRlCTB4NWEN CgkudWF4d29yZAkuTExWTDYtLkxMdGV4dDANCgkudWF4d29yZAkuTExWTDct LkxMdGV4dDANCgkudWFoYWxmCTB4MQ0KCS5ieXRlCTB4NTgNCgkudWF4d29y ZAkuTExWTDctLkxMdGV4dDANCgkudWF4d29yZAkuTExWTDgtLkxMdGV4dDAN CgkudWFoYWxmCTB4MQ0KCS5ieXRlCTB4NWENCgkudWF4d29yZAkuTExWTDgt LkxMdGV4dDANCgkudWF4d29yZAkuTExWTDExLS5MTHRleHQwDQoJLnVhaGFs ZgkweDENCgkuYnl0ZQkweDU4DQoJLnVheHdvcmQJLkxMVkwxMS0uTEx0ZXh0 MA0KCS51YXh3b3JkCS5MTFZMMTItLkxMdGV4dDANCgkudWFoYWxmCTB4MQ0K CS5ieXRlCTB4NWENCgkudWF4d29yZAkuTExWTDEzLS5MTHRleHQwDQoJLnVh eHdvcmQJLkxMRkUxNC0uTEx0ZXh0MA0KCS51YWhhbGYJMHgxDQoJLmJ5dGUJ MHg1OA0KCS51YXh3b3JkCTB4MA0KCS51YXh3b3JkCTB4MA0KLkxMTFNUMzoN CgkudWF4d29yZAkuTExWTDktLkxMdGV4dDANCgkudWF4d29yZAkuTExWTDEw LS5MTHRleHQwDQoJLnVhaGFsZgkweDENCgkuYnl0ZQkweDUxDQoJLnVheHdv cmQJLkxMVkwxMy0uTEx0ZXh0MA0KCS51YXh3b3JkCS5MTEZFMTQtLkxMdGV4 dDANCgkudWFoYWxmCTB4MQ0KCS5ieXRlCTB4NTENCgkudWF4d29yZAkweDAN CgkudWF4d29yZAkweDANCi5MTExTVDQ6DQoJLnVheHdvcmQJLkxMRkIxMy0u TEx0ZXh0MA0KCS51YXh3b3JkCS5MTENGSTEtLkxMdGV4dDANCgkudWFoYWxm CTB4Mw0KCS5ieXRlCTB4N2UNCgkuc2xlYjEyOCAyMDQ3DQoJLnVheHdvcmQJ LkxMQ0ZJMS0uTEx0ZXh0MA0KCS51YXh3b3JkCS5MTEZFMTMtLkxMdGV4dDAN CgkudWFoYWxmCTB4Mw0KCS5ieXRlCTB4OGUNCgkuc2xlYjEyOCAyMDQ3DQoJ LnVheHdvcmQJMHgwDQoJLnVheHdvcmQJMHgwDQouTExMU1Q1Og0KCS51YXh3 b3JkCS5MTFZMMTctLkxMdGV4dDANCgkudWF4d29yZAkuTExWTDE4LS5MTHRl eHQwDQoJLnVhaGFsZgkweDENCgkuYnl0ZQkweDVhDQoJLnVheHdvcmQJLkxM VkwxOC0uTEx0ZXh0MA0KCS51YXh3b3JkCS5MTFZMMTktLkxMdGV4dDANCgku dWFoYWxmCTB4MQ0KCS5ieXRlCTB4NTgNCgkudWF4d29yZAkuTExWTDIwLS5M THRleHQwDQoJLnVheHdvcmQJLkxMVkwyMS0uTEx0ZXh0MA0KCS51YWhhbGYJ MHgxDQoJLmJ5dGUJMHg1OA0KCS51YXh3b3JkCS5MTFZMMjEtLkxMdGV4dDAN CgkudWF4d29yZAkuTExWTDIyLS5MTHRleHQwDQoJLnVhaGFsZgkweDENCgku Ynl0ZQkweDVhDQoJLnVheHdvcmQJLkxMVkwyMy0uTEx0ZXh0MA0KCS51YXh3 b3JkCS5MTEZFMTMtLkxMdGV4dDANCgkudWFoYWxmCTB4MQ0KCS5ieXRlCTB4 NTgNCgkudWF4d29yZAkweDANCgkudWF4d29yZAkweDANCgkuZmlsZSAyICIv dXNyL2luY2x1ZGUvbWFjaGluZS9fdHlwZXMuaCINCgkuZmlsZSAzICIvdXNy L2luY2x1ZGUvc3lzL190eXBlcy5oIg0KCS5maWxlIDQgIi91c3IvaW5jbHVk ZS9zeXMvdHlwZXMuaCINCgkuZmlsZSA1ICIvdXNyL2luY2x1ZGUvc3lzL19p b3ZlYy5oIg0KCS5maWxlIDYgIi91c3IvaW5jbHVkZS9zeXMvc29ja2V0Lmgi DQoJLnNlY3Rpb24JIi5kZWJ1Z19pbmZvIg0KCS51YXdvcmQJMHgzNDYNCgku dWFoYWxmCTB4Mg0KCS51YXdvcmQJLkxMZGVidWdfYWJicmV2MA0KCS5ieXRl CTB4OA0KCS51bGViMTI4IDB4MQ0KCS51YXdvcmQJLkxMQVNGMzcNCgkuYnl0 ZQkweDENCgkudWF3b3JkCS5MTEFTRjM4DQoJLnVheHdvcmQJLkxMdGV4dDAN CgkudWF4d29yZAkuTExldGV4dDANCgkudWF3b3JkCS5MTGRlYnVnX2xpbmUw DQoJLnVsZWIxMjggMHgyDQoJLmJ5dGUJMHgxDQoJLmJ5dGUJMHg2DQoJLnVh d29yZAkuTExBU0YwDQoJLnVsZWIxMjggMHgyDQoJLmJ5dGUJMHgxDQoJLmJ5 dGUJMHg4DQoJLnVhd29yZAkuTExBU0YxDQoJLnVsZWIxMjggMHgyDQoJLmJ5 dGUJMHgyDQoJLmJ5dGUJMHg1DQoJLnVhd29yZAkuTExBU0YyDQoJLnVsZWIx MjggMHgyDQoJLmJ5dGUJMHgyDQoJLmJ5dGUJMHg3DQoJLnVhd29yZAkuTExB U0YzDQoJLnVsZWIxMjggMHgzDQoJLmJ5dGUJMHg0DQoJLmJ5dGUJMHg1DQoJ LmFzY2l6CSJpbnQiDQoJLnVsZWIxMjggMHg0DQoJLnVhd29yZAkuTExBU0Y1 DQoJLmJ5dGUJMHgyDQoJLmJ5dGUJMHgzMg0KCS51YXdvcmQJMHg1Nw0KCS51 bGViMTI4IDB4Mg0KCS5ieXRlCTB4NA0KCS5ieXRlCTB4Nw0KCS51YXdvcmQJ LkxMQVNGNA0KCS51bGViMTI4IDB4NA0KCS51YXdvcmQJLkxMQVNGNg0KCS5i eXRlCTB4Mg0KCS5ieXRlCTB4MzMNCgkudWF3b3JkCTB4NjkNCgkudWxlYjEy OCAweDINCgkuYnl0ZQkweDgNCgkuYnl0ZQkweDUNCgkudWF3b3JkCS5MTEFT RjcNCgkudWxlYjEyOCAweDQNCgkudWF3b3JkCS5MTEFTRjgNCgkuYnl0ZQkw eDINCgkuYnl0ZQkweDM0DQoJLnVhd29yZAkweDdiDQoJLnVsZWIxMjggMHgy DQoJLmJ5dGUJMHg4DQoJLmJ5dGUJMHg3DQoJLnVhd29yZAkuTExBU0Y5DQoJ LnVsZWIxMjggMHgyDQoJLmJ5dGUJMHg4DQoJLmJ5dGUJMHg0DQoJLnVhd29y ZAkuTExBU0YxMA0KCS51bGViMTI4IDB4Mg0KCS5ieXRlCTB4NA0KCS5ieXRl CTB4NA0KCS51YXdvcmQJLkxMQVNGMTENCgkudWxlYjEyOCAweDQNCgkudWF3 b3JkCS5MTEFTRjEyDQoJLmJ5dGUJMHgyDQoJLmJ5dGUJMHg0Yw0KCS51YXdv cmQJMHg3MA0KCS51bGViMTI4IDB4NA0KCS51YXdvcmQJLkxMQVNGMTMNCgku Ynl0ZQkweDINCgkuYnl0ZQkweDRkDQoJLnVhd29yZAkweDVlDQoJLnVsZWIx MjggMHg0DQoJLnVhd29yZAkuTExBU0YxNA0KCS5ieXRlCTB4Mw0KCS5ieXRl CTB4M2ENCgkudWF3b3JkCTB4NGMNCgkudWxlYjEyOCAweDUNCgkuYnl0ZQkw eDgNCgkuYnl0ZQkweDcNCgkudWxlYjEyOCAweDINCgkuYnl0ZQkweDENCgku Ynl0ZQkweDYNCgkudWF3b3JkCS5MTEFTRjE1DQoJLnVsZWIxMjggMHg2DQoJ LmJ5dGUJMHg4DQoJLnVsZWIxMjggMHg0DQoJLnVhd29yZAkuTExBU0YxNg0K CS5ieXRlCTB4NA0KCS5ieXRlCTB4ZTQNCgkudWF3b3JkCTB4OTANCgkudWxl YjEyOCAweDQNCgkudWF3b3JkCS5MTEFTRjE3DQoJLmJ5dGUJMHg0DQoJLmJ5 dGUJMHhlOQ0KCS51YXdvcmQJMHg5Yg0KCS51bGViMTI4IDB4Nw0KCS51YXdv cmQJLkxMQVNGMjENCgkuYnl0ZQkweDEwDQoJLmJ5dGUJMHg1DQoJLmJ5dGUJ MHgyYg0KCS51YXdvcmQJMHhmYw0KCS51bGViMTI4IDB4OA0KCS51YXdvcmQJ LkxMQVNGMTgNCgkuYnl0ZQkweDUNCgkuYnl0ZQkweDJjDQoJLnVhd29yZAkw eGJiDQoJLmJ5dGUJMHgyDQoJLmJ5dGUJMHgyMw0KCS51bGViMTI4IDB4MA0K CS51bGViMTI4IDB4OA0KCS51YXdvcmQJLkxMQVNGMTkNCgkuYnl0ZQkweDUN CgkuYnl0ZQkweDJkDQoJLnVhd29yZAkweGJkDQoJLmJ5dGUJMHgyDQoJLmJ5 dGUJMHgyMw0KCS51bGViMTI4IDB4OA0KCS5ieXRlCTB4MA0KCS51bGViMTI4 IDB4NA0KCS51YXdvcmQJLkxMQVNGMjANCgkuYnl0ZQkweDYNCgkuYnl0ZQkw eDQ5DQoJLnVhd29yZAkweGE2DQoJLnVsZWIxMjggMHg5DQoJLnVhd29yZAku TExBU0YyMg0KCS5ieXRlCTB4MzANCgkuYnl0ZQkweDYNCgkudWFoYWxmCTB4 MTdmDQoJLnVhd29yZAkweDE3ZQ0KCS51bGViMTI4IDB4YQ0KCS51YXdvcmQJ LkxMQVNGMjMNCgkuYnl0ZQkweDYNCgkudWFoYWxmCTB4MTgwDQoJLnVhd29y ZAkweGJiDQoJLmJ5dGUJMHgyDQoJLmJ5dGUJMHgyMw0KCS51bGViMTI4IDB4 MA0KCS51bGViMTI4IDB4YQ0KCS51YXdvcmQJLkxMQVNGMjQNCgkuYnl0ZQkw eDYNCgkudWFoYWxmCTB4MTgxDQoJLnVhd29yZAkweGZjDQoJLmJ5dGUJMHgy DQoJLmJ5dGUJMHgyMw0KCS51bGViMTI4IDB4OA0KCS51bGViMTI4IDB4YQ0K CS51YXdvcmQJLkxMQVNGMjUNCgkuYnl0ZQkweDYNCgkudWFoYWxmCTB4MTgy DQoJLnVhd29yZAkweDE3ZQ0KCS5ieXRlCTB4Mg0KCS5ieXRlCTB4MjMNCgku dWxlYjEyOCAweDEwDQoJLnVsZWIxMjggMHhhDQoJLnVhd29yZAkuTExBU0Yy Ng0KCS5ieXRlCTB4Ng0KCS51YWhhbGYJMHgxODMNCgkudWF3b3JkCTB4NDUN CgkuYnl0ZQkweDINCgkuYnl0ZQkweDIzDQoJLnVsZWIxMjggMHgxOA0KCS51 bGViMTI4IDB4YQ0KCS51YXdvcmQJLkxMQVNGMjcNCgkuYnl0ZQkweDYNCgku dWFoYWxmCTB4MTg0DQoJLnVhd29yZAkweGJiDQoJLmJ5dGUJMHgyDQoJLmJ5 dGUJMHgyMw0KCS51bGViMTI4IDB4MjANCgkudWxlYjEyOCAweGENCgkudWF3 b3JkCS5MTEFTRjI4DQoJLmJ5dGUJMHg2DQoJLnVhaGFsZgkweDE4NQ0KCS51 YXdvcmQJMHhmYw0KCS5ieXRlCTB4Mg0KCS5ieXRlCTB4MjMNCgkudWxlYjEy OCAweDI4DQoJLnVsZWIxMjggMHhhDQoJLnVhd29yZAkuTExBU0YyOQ0KCS5i eXRlCTB4Ng0KCS51YWhhbGYJMHgxODYNCgkudWF3b3JkCTB4NDUNCgkuYnl0 ZQkweDINCgkuYnl0ZQkweDIzDQoJLnVsZWIxMjggMHgyYw0KCS5ieXRlCTB4 MA0KCS51bGViMTI4IDB4Yg0KCS5ieXRlCTB4OA0KCS51YXdvcmQJMHhkMw0K CS51bGViMTI4IDB4OQ0KCS51YXdvcmQJLkxMQVNGMzANCgkuYnl0ZQkweGMN CgkuYnl0ZQkweDYNCgkudWFoYWxmCTB4MWE0DQoJLnVhd29yZAkweDFiZg0K CS51bGViMTI4IDB4YQ0KCS51YXdvcmQJLkxMQVNGMzENCgkuYnl0ZQkweDYN CgkudWFoYWxmCTB4MWE1DQoJLnVhd29yZAkweGZjDQoJLmJ5dGUJMHgyDQoJ LmJ5dGUJMHgyMw0KCS51bGViMTI4IDB4MA0KCS51bGViMTI4IDB4YQ0KCS51 YXdvcmQJLkxMQVNGMzINCgkuYnl0ZQkweDYNCgkudWFoYWxmCTB4MWE2DQoJ LnVhd29yZAkweDQ1DQoJLmJ5dGUJMHgyDQoJLmJ5dGUJMHgyMw0KCS51bGVi MTI4IDB4NA0KCS51bGViMTI4IDB4YQ0KCS51YXdvcmQJLkxMQVNGMzMNCgku Ynl0ZQkweDYNCgkudWFoYWxmCTB4MWE3DQoJLnVhd29yZAkweDQ1DQoJLmJ5 dGUJMHgyDQoJLmJ5dGUJMHgyMw0KCS51bGViMTI4IDB4OA0KCS5ieXRlCTB4 MA0KCS51bGViMTI4IDB4Yw0KCS5ieXRlCTB4MQ0KCS51YXdvcmQJLkxMQVNG MzkNCgkuYnl0ZQkweDENCgkuYnl0ZQkweDU5DQoJLmJ5dGUJMHgxDQoJLnVh d29yZAkweDQ1DQoJLnVheHdvcmQJLkxMRkIxNA0KCS51YXh3b3JkCS5MTEZF MTQNCgkudWF3b3JkCS5MTExTVDANCgkudWF3b3JkCTB4MjY4DQoJLnVsZWIx MjggMHhkDQoJLnVhd29yZAkuTExBU0YzNg0KCS5ieXRlCTB4MQ0KCS5ieXRl CTB4NTgNCgkudWF3b3JkCTB4NDUNCgkudWF3b3JkCS5MTExTVDENCgkudWxl YjEyOCAweGUNCgkuYXNjaXoJIm1zZyINCgkuYnl0ZQkweDENCgkuYnl0ZQkw eDViDQoJLnVhd29yZAkweDEwNw0KCS5ieXRlCTB4Mg0KCS5ieXRlCTB4OTEN Cgkuc2xlYjEyOCAtNjQNCgkudWxlYjEyOCAweGUNCgkuYXNjaXoJInZlYyIN CgkuYnl0ZQkweDENCgkuYnl0ZQkweDVjDQoJLnVhd29yZAkweGQzDQoJLmJ5 dGUJMHgzDQoJLmJ5dGUJMHg5MQ0KCS5zbGViMTI4IC04MA0KCS51bGViMTI4 IDB4Zg0KCS5hc2NpegkibiINCgkuYnl0ZQkweDENCgkuYnl0ZQkweDVkDQoJ LnVhd29yZAkweGM4DQoJLnVhd29yZAkuTExMU1QyDQoJLnVsZWIxMjggMHhl DQoJLmFzY2l6CSJjaCINCgkuYnl0ZQkweDENCgkuYnl0ZQkweDVlDQoJLnVh d29yZAkweGI0DQoJLmJ5dGUJMHgzDQoJLmJ5dGUJMHg5MQ0KCS5zbGViMTI4 IC04MQ0KCS51bGViMTI4IDB4MTANCgkuYXNjaXoJImZkIg0KCS5ieXRlCTB4 MQ0KCS5ieXRlCTB4NWYNCgkudWF3b3JkCTB4NDUNCgkudWxlYjEyOCAweGUN CgkuYXNjaXoJInRtcCINCgkuYnl0ZQkweDENCgkuYnl0ZQkweDYxDQoJLnVh d29yZAkweDI2OA0KCS5ieXRlCTB4Mw0KCS5ieXRlCTB4OTENCgkuc2xlYjEy OCAtMTEzDQoJLnVsZWIxMjggMHgxMQ0KCS51YXdvcmQJLkxMQVNGMzQNCgku Ynl0ZQkweDENCgkuYnl0ZQkweDYyDQoJLnVhd29yZAkweDI3OA0KCS51YXdv cmQJLkxMTFNUMw0KCS51bGViMTI4IDB4MTINCgkudWF3b3JkCS5MTEFTRjM1 DQoJLnVhd29yZAkweDM0NA0KCS5ieXRlCTB4MQ0KCS5ieXRlCTB4OQ0KCS5i eXRlCTB4Mw0KCS51YXh3b3JkCV9fZnVuY19fLjU0MzQNCgkuYnl0ZQkweDAN CgkudWxlYjEyOCAweDEzDQoJLnVhd29yZAkweGI0DQoJLnVhd29yZAkweDI3 OA0KCS51bGViMTI4IDB4MTQNCgkudWF3b3JkCTB4YjENCgkuYnl0ZQkweDFm DQoJLmJ5dGUJMHgwDQoJLnVsZWIxMjggMHhiDQoJLmJ5dGUJMHg4DQoJLnVh d29yZAkweDE4NA0KCS51bGViMTI4IDB4MTUNCgkuYnl0ZQkweDENCgkudWF3 b3JkCS5MTEFTRjQwDQoJLmJ5dGUJMHgxDQoJLmJ5dGUJMHgyZA0KCS5ieXRl CTB4MQ0KCS51YXh3b3JkCS5MTEZCMTMNCgkudWF4d29yZAkuTExGRTEzDQoJ LnVhd29yZAkuTExMU1Q0DQoJLnVhd29yZAkweDMxZg0KCS51bGViMTI4IDB4 MTYNCgkudWF3b3JkCS5MTEFTRjM2DQoJLmJ5dGUJMHgxDQoJLmJ5dGUJMHgy Yw0KCS51YXdvcmQJMHg0NQ0KCS5ieXRlCTB4MQ0KCS5ieXRlCTB4NjgNCgku dWxlYjEyOCAweDE3DQoJLmFzY2l6CSJmZCINCgkuYnl0ZQkweDENCgkuYnl0 ZQkweDJjDQoJLnVhd29yZAkweDQ1DQoJLmJ5dGUJMHgxDQoJLmJ5dGUJMHg2 OQ0KCS51bGViMTI4IDB4ZQ0KCS5hc2NpegkibXNnIg0KCS5ieXRlCTB4MQ0K CS5ieXRlCTB4MmYNCgkudWF3b3JkCTB4MTA3DQoJLmJ5dGUJMHgyDQoJLmJ5 dGUJMHg5MQ0KCS5zbGViMTI4IC02NA0KCS51bGViMTI4IDB4ZQ0KCS5hc2Np egkidmVjIg0KCS5ieXRlCTB4MQ0KCS5ieXRlCTB4MzANCgkudWF3b3JkCTB4 ZDMNCgkuYnl0ZQkweDMNCgkuYnl0ZQkweDkxDQoJLnNsZWIxMjggLTgwDQoJ LnVsZWIxMjggMHhlDQoJLmFzY2l6CSJjaCINCgkuYnl0ZQkweDENCgkuYnl0 ZQkweDMxDQoJLnVhd29yZAkweGI0DQoJLmJ5dGUJMHgzDQoJLmJ5dGUJMHg4 ZQ0KCS5zbGViMTI4IDE5NjYNCgkudWxlYjEyOCAweGYNCgkuYXNjaXoJIm4i DQoJLmJ5dGUJMHgxDQoJLmJ5dGUJMHgzMg0KCS51YXdvcmQJMHhjOA0KCS51 YXdvcmQJLkxMTFNUNQ0KCS51bGViMTI4IDB4ZQ0KCS5hc2NpegkidG1wIg0K CS5ieXRlCTB4MQ0KCS5ieXRlCTB4MzQNCgkudWF3b3JkCTB4MjY4DQoJLmJ5 dGUJMHgzDQoJLmJ5dGUJMHg5MQ0KCS5zbGViMTI4IC0xMTMNCgkudWxlYjEy OCAweDE4DQoJLnVhd29yZAkuTExBU0YzNA0KCS5ieXRlCTB4MQ0KCS5ieXRl CTB4MzUNCgkudWF3b3JkCTB4Mjc4DQoJLnVsZWIxMjggMHgxMg0KCS51YXdv cmQJLkxMQVNGMzUNCgkudWF3b3JkCTB4MzJmDQoJLmJ5dGUJMHgxDQoJLmJ5 dGUJMHg5DQoJLmJ5dGUJMHgzDQoJLnVheHdvcmQJX19mdW5jX18uNTQxMw0K CS5ieXRlCTB4MA0KCS51bGViMTI4IDB4MTMNCgkudWF3b3JkCTB4YjQNCgku dWF3b3JkCTB4MzJmDQoJLnVsZWIxMjggMHgxNA0KCS51YXdvcmQJMHhiMQ0K CS5ieXRlCTB4ZQ0KCS5ieXRlCTB4MA0KCS51bGViMTI4IDB4MTkNCgkudWF3 b3JkCTB4MzFmDQoJLnVsZWIxMjggMHgxMw0KCS51YXdvcmQJMHhiNA0KCS51 YXdvcmQJMHgzNDQNCgkudWxlYjEyOCAweDE0DQoJLnVhd29yZAkweGIxDQoJ LmJ5dGUJMHgxMQ0KCS5ieXRlCTB4MA0KCS51bGViMTI4IDB4MTkNCgkudWF3 b3JkCTB4MzM0DQoJLmJ5dGUJMHgwDQoJLnNlY3Rpb24JIi5kZWJ1Z19hYmJy ZXYiDQoJLnVsZWIxMjggMHgxDQoJLnVsZWIxMjggMHgxMQ0KCS5ieXRlCTB4 MQ0KCS51bGViMTI4IDB4MjUNCgkudWxlYjEyOCAweGUNCgkudWxlYjEyOCAw eDEzDQoJLnVsZWIxMjggMHhiDQoJLnVsZWIxMjggMHgzDQoJLnVsZWIxMjgg MHhlDQoJLnVsZWIxMjggMHgxMQ0KCS51bGViMTI4IDB4MQ0KCS51bGViMTI4 IDB4MTINCgkudWxlYjEyOCAweDENCgkudWxlYjEyOCAweDEwDQoJLnVsZWIx MjggMHg2DQoJLmJ5dGUJMHgwDQoJLmJ5dGUJMHgwDQoJLnVsZWIxMjggMHgy DQoJLnVsZWIxMjggMHgyNA0KCS5ieXRlCTB4MA0KCS51bGViMTI4IDB4Yg0K CS51bGViMTI4IDB4Yg0KCS51bGViMTI4IDB4M2UNCgkudWxlYjEyOCAweGIN CgkudWxlYjEyOCAweDMNCgkudWxlYjEyOCAweGUNCgkuYnl0ZQkweDANCgku Ynl0ZQkweDANCgkudWxlYjEyOCAweDMNCgkudWxlYjEyOCAweDI0DQoJLmJ5 dGUJMHgwDQoJLnVsZWIxMjggMHhiDQoJLnVsZWIxMjggMHhiDQoJLnVsZWIx MjggMHgzZQ0KCS51bGViMTI4IDB4Yg0KCS51bGViMTI4IDB4Mw0KCS51bGVi MTI4IDB4OA0KCS5ieXRlCTB4MA0KCS5ieXRlCTB4MA0KCS51bGViMTI4IDB4 NA0KCS51bGViMTI4IDB4MTYNCgkuYnl0ZQkweDANCgkudWxlYjEyOCAweDMN CgkudWxlYjEyOCAweGUNCgkudWxlYjEyOCAweDNhDQoJLnVsZWIxMjggMHhi DQoJLnVsZWIxMjggMHgzYg0KCS51bGViMTI4IDB4Yg0KCS51bGViMTI4IDB4 NDkNCgkudWxlYjEyOCAweDEzDQoJLmJ5dGUJMHgwDQoJLmJ5dGUJMHgwDQoJ LnVsZWIxMjggMHg1DQoJLnVsZWIxMjggMHgyNA0KCS5ieXRlCTB4MA0KCS51 bGViMTI4IDB4Yg0KCS51bGViMTI4IDB4Yg0KCS51bGViMTI4IDB4M2UNCgku dWxlYjEyOCAweGINCgkuYnl0ZQkweDANCgkuYnl0ZQkweDANCgkudWxlYjEy OCAweDYNCgkudWxlYjEyOCAweGYNCgkuYnl0ZQkweDANCgkudWxlYjEyOCAw eGINCgkudWxlYjEyOCAweGINCgkuYnl0ZQkweDANCgkuYnl0ZQkweDANCgku dWxlYjEyOCAweDcNCgkudWxlYjEyOCAweDEzDQoJLmJ5dGUJMHgxDQoJLnVs ZWIxMjggMHgzDQoJLnVsZWIxMjggMHhlDQoJLnVsZWIxMjggMHhiDQoJLnVs ZWIxMjggMHhiDQoJLnVsZWIxMjggMHgzYQ0KCS51bGViMTI4IDB4Yg0KCS51 bGViMTI4IDB4M2INCgkudWxlYjEyOCAweGINCgkudWxlYjEyOCAweDENCgku dWxlYjEyOCAweDEzDQoJLmJ5dGUJMHgwDQoJLmJ5dGUJMHgwDQoJLnVsZWIx MjggMHg4DQoJLnVsZWIxMjggMHhkDQoJLmJ5dGUJMHgwDQoJLnVsZWIxMjgg MHgzDQoJLnVsZWIxMjggMHhlDQoJLnVsZWIxMjggMHgzYQ0KCS51bGViMTI4 IDB4Yg0KCS51bGViMTI4IDB4M2INCgkudWxlYjEyOCAweGINCgkudWxlYjEy OCAweDQ5DQoJLnVsZWIxMjggMHgxMw0KCS51bGViMTI4IDB4MzgNCgkudWxl YjEyOCAweGENCgkuYnl0ZQkweDANCgkuYnl0ZQkweDANCgkudWxlYjEyOCAw eDkNCgkudWxlYjEyOCAweDEzDQoJLmJ5dGUJMHgxDQoJLnVsZWIxMjggMHgz DQoJLnVsZWIxMjggMHhlDQoJLnVsZWIxMjggMHhiDQoJLnVsZWIxMjggMHhi DQoJLnVsZWIxMjggMHgzYQ0KCS51bGViMTI4IDB4Yg0KCS51bGViMTI4IDB4 M2INCgkudWxlYjEyOCAweDUNCgkudWxlYjEyOCAweDENCgkudWxlYjEyOCAw eDEzDQoJLmJ5dGUJMHgwDQoJLmJ5dGUJMHgwDQoJLnVsZWIxMjggMHhhDQoJ LnVsZWIxMjggMHhkDQoJLmJ5dGUJMHgwDQoJLnVsZWIxMjggMHgzDQoJLnVs ZWIxMjggMHhlDQoJLnVsZWIxMjggMHgzYQ0KCS51bGViMTI4IDB4Yg0KCS51 bGViMTI4IDB4M2INCgkudWxlYjEyOCAweDUNCgkudWxlYjEyOCAweDQ5DQoJ LnVsZWIxMjggMHgxMw0KCS51bGViMTI4IDB4MzgNCgkudWxlYjEyOCAweGEN CgkuYnl0ZQkweDANCgkuYnl0ZQkweDANCgkudWxlYjEyOCAweGINCgkudWxl YjEyOCAweGYNCgkuYnl0ZQkweDANCgkudWxlYjEyOCAweGINCgkudWxlYjEy OCAweGINCgkudWxlYjEyOCAweDQ5DQoJLnVsZWIxMjggMHgxMw0KCS5ieXRl CTB4MA0KCS5ieXRlCTB4MA0KCS51bGViMTI4IDB4Yw0KCS51bGViMTI4IDB4 MmUNCgkuYnl0ZQkweDENCgkudWxlYjEyOCAweDNmDQoJLnVsZWIxMjggMHhj DQoJLnVsZWIxMjggMHgzDQoJLnVsZWIxMjggMHhlDQoJLnVsZWIxMjggMHgz YQ0KCS51bGViMTI4IDB4Yg0KCS51bGViMTI4IDB4M2INCgkudWxlYjEyOCAw eGINCgkudWxlYjEyOCAweDI3DQoJLnVsZWIxMjggMHhjDQoJLnVsZWIxMjgg MHg0OQ0KCS51bGViMTI4IDB4MTMNCgkudWxlYjEyOCAweDExDQoJLnVsZWIx MjggMHgxDQoJLnVsZWIxMjggMHgxMg0KCS51bGViMTI4IDB4MQ0KCS51bGVi MTI4IDB4NDANCgkudWxlYjEyOCAweDYNCgkudWxlYjEyOCAweDENCgkudWxl YjEyOCAweDEzDQoJLmJ5dGUJMHgwDQoJLmJ5dGUJMHgwDQoJLnVsZWIxMjgg MHhkDQoJLnVsZWIxMjggMHg1DQoJLmJ5dGUJMHgwDQoJLnVsZWIxMjggMHgz DQoJLnVsZWIxMjggMHhlDQoJLnVsZWIxMjggMHgzYQ0KCS51bGViMTI4IDB4 Yg0KCS51bGViMTI4IDB4M2INCgkudWxlYjEyOCAweGINCgkudWxlYjEyOCAw eDQ5DQoJLnVsZWIxMjggMHgxMw0KCS51bGViMTI4IDB4Mg0KCS51bGViMTI4 IDB4Ng0KCS5ieXRlCTB4MA0KCS5ieXRlCTB4MA0KCS51bGViMTI4IDB4ZQ0K CS51bGViMTI4IDB4MzQNCgkuYnl0ZQkweDANCgkudWxlYjEyOCAweDMNCgku dWxlYjEyOCAweDgNCgkudWxlYjEyOCAweDNhDQoJLnVsZWIxMjggMHhiDQoJ LnVsZWIxMjggMHgzYg0KCS51bGViMTI4IDB4Yg0KCS51bGViMTI4IDB4NDkN CgkudWxlYjEyOCAweDEzDQoJLnVsZWIxMjggMHgyDQoJLnVsZWIxMjggMHhh DQoJLmJ5dGUJMHgwDQoJLmJ5dGUJMHgwDQoJLnVsZWIxMjggMHhmDQoJLnVs ZWIxMjggMHgzNA0KCS5ieXRlCTB4MA0KCS51bGViMTI4IDB4Mw0KCS51bGVi MTI4IDB4OA0KCS51bGViMTI4IDB4M2ENCgkudWxlYjEyOCAweGINCgkudWxl YjEyOCAweDNiDQoJLnVsZWIxMjggMHhiDQoJLnVsZWIxMjggMHg0OQ0KCS51 bGViMTI4IDB4MTMNCgkudWxlYjEyOCAweDINCgkudWxlYjEyOCAweDYNCgku Ynl0ZQkweDANCgkuYnl0ZQkweDANCgkudWxlYjEyOCAweDEwDQoJLnVsZWIx MjggMHgzNA0KCS5ieXRlCTB4MA0KCS51bGViMTI4IDB4Mw0KCS51bGViMTI4 IDB4OA0KCS51bGViMTI4IDB4M2ENCgkudWxlYjEyOCAweGINCgkudWxlYjEy OCAweDNiDQoJLnVsZWIxMjggMHhiDQoJLnVsZWIxMjggMHg0OQ0KCS51bGVi MTI4IDB4MTMNCgkuYnl0ZQkweDANCgkuYnl0ZQkweDANCgkudWxlYjEyOCAw eDExDQoJLnVsZWIxMjggMHgzNA0KCS5ieXRlCTB4MA0KCS51bGViMTI4IDB4 Mw0KCS51bGViMTI4IDB4ZQ0KCS51bGViMTI4IDB4M2ENCgkudWxlYjEyOCAw eGINCgkudWxlYjEyOCAweDNiDQoJLnVsZWIxMjggMHhiDQoJLnVsZWIxMjgg MHg0OQ0KCS51bGViMTI4IDB4MTMNCgkudWxlYjEyOCAweDINCgkudWxlYjEy OCAweDYNCgkuYnl0ZQkweDANCgkuYnl0ZQkweDANCgkudWxlYjEyOCAweDEy DQoJLnVsZWIxMjggMHgzNA0KCS5ieXRlCTB4MA0KCS51bGViMTI4IDB4Mw0K CS51bGViMTI4IDB4ZQ0KCS51bGViMTI4IDB4NDkNCgkudWxlYjEyOCAweDEz DQoJLnVsZWIxMjggMHgzNA0KCS51bGViMTI4IDB4Yw0KCS51bGViMTI4IDB4 Mg0KCS51bGViMTI4IDB4YQ0KCS5ieXRlCTB4MA0KCS5ieXRlCTB4MA0KCS51 bGViMTI4IDB4MTMNCgkudWxlYjEyOCAweDENCgkuYnl0ZQkweDENCgkudWxl YjEyOCAweDQ5DQoJLnVsZWIxMjggMHgxMw0KCS51bGViMTI4IDB4MQ0KCS51 bGViMTI4IDB4MTMNCgkuYnl0ZQkweDANCgkuYnl0ZQkweDANCgkudWxlYjEy OCAweDE0DQoJLnVsZWIxMjggMHgyMQ0KCS5ieXRlCTB4MA0KCS51bGViMTI4 IDB4NDkNCgkudWxlYjEyOCAweDEzDQoJLnVsZWIxMjggMHgyZg0KCS51bGVi MTI4IDB4Yg0KCS5ieXRlCTB4MA0KCS5ieXRlCTB4MA0KCS51bGViMTI4IDB4 MTUNCgkudWxlYjEyOCAweDJlDQoJLmJ5dGUJMHgxDQoJLnVsZWIxMjggMHgz Zg0KCS51bGViMTI4IDB4Yw0KCS51bGViMTI4IDB4Mw0KCS51bGViMTI4IDB4 ZQ0KCS51bGViMTI4IDB4M2ENCgkudWxlYjEyOCAweGINCgkudWxlYjEyOCAw eDNiDQoJLnVsZWIxMjggMHhiDQoJLnVsZWIxMjggMHgyNw0KCS51bGViMTI4 IDB4Yw0KCS51bGViMTI4IDB4MTENCgkudWxlYjEyOCAweDENCgkudWxlYjEy OCAweDEyDQoJLnVsZWIxMjggMHgxDQoJLnVsZWIxMjggMHg0MA0KCS51bGVi MTI4IDB4Ng0KCS51bGViMTI4IDB4MQ0KCS51bGViMTI4IDB4MTMNCgkuYnl0 ZQkweDANCgkuYnl0ZQkweDANCgkudWxlYjEyOCAweDE2DQoJLnVsZWIxMjgg MHg1DQoJLmJ5dGUJMHgwDQoJLnVsZWIxMjggMHgzDQoJLnVsZWIxMjggMHhl DQoJLnVsZWIxMjggMHgzYQ0KCS51bGViMTI4IDB4Yg0KCS51bGViMTI4IDB4 M2INCgkudWxlYjEyOCAweGINCgkudWxlYjEyOCAweDQ5DQoJLnVsZWIxMjgg MHgxMw0KCS51bGViMTI4IDB4Mg0KCS51bGViMTI4IDB4YQ0KCS5ieXRlCTB4 MA0KCS5ieXRlCTB4MA0KCS51bGViMTI4IDB4MTcNCgkudWxlYjEyOCAweDUN CgkuYnl0ZQkweDANCgkudWxlYjEyOCAweDMNCgkudWxlYjEyOCAweDgNCgku dWxlYjEyOCAweDNhDQoJLnVsZWIxMjggMHhiDQoJLnVsZWIxMjggMHgzYg0K CS51bGViMTI4IDB4Yg0KCS51bGViMTI4IDB4NDkNCgkudWxlYjEyOCAweDEz DQoJLnVsZWIxMjggMHgyDQoJLnVsZWIxMjggMHhhDQoJLmJ5dGUJMHgwDQoJ LmJ5dGUJMHgwDQoJLnVsZWIxMjggMHgxOA0KCS51bGViMTI4IDB4MzQNCgku Ynl0ZQkweDANCgkudWxlYjEyOCAweDMNCgkudWxlYjEyOCAweGUNCgkudWxl YjEyOCAweDNhDQoJLnVsZWIxMjggMHhiDQoJLnVsZWIxMjggMHgzYg0KCS51 bGViMTI4IDB4Yg0KCS51bGViMTI4IDB4NDkNCgkudWxlYjEyOCAweDEzDQoJ LmJ5dGUJMHgwDQoJLmJ5dGUJMHgwDQoJLnVsZWIxMjggMHgxOQ0KCS51bGVi MTI4IDB4MjYNCgkuYnl0ZQkweDANCgkudWxlYjEyOCAweDQ5DQoJLnVsZWIx MjggMHgxMw0KCS5ieXRlCTB4MA0KCS5ieXRlCTB4MA0KCS5ieXRlCTB4MA0K CS5zZWN0aW9uCSIuZGVidWdfcHVibmFtZXMiDQoJLnVhd29yZAkweDM3DQoJ LnVhaGFsZgkweDINCgkudWF3b3JkCS5MTGRlYnVnX2luZm8wDQoJLnVhd29y ZAkweDM0YQ0KCS51YXdvcmQJMHgxYmYNCgkuYXNjaXoJInNzaF9tbV9yZWNl aXZlX2ZkIg0KCS51YXdvcmQJMHgyN2UNCgkuYXNjaXoJInNzaF9tbV9zZW5k X2ZkIg0KCS51YXdvcmQJMHgwDQoJLnNlY3Rpb24JIi5kZWJ1Z19hcmFuZ2Vz Ig0KCS51YXdvcmQJMHgyYw0KCS51YWhhbGYJMHgyDQoJLnVhd29yZAkuTExk ZWJ1Z19pbmZvMA0KCS5ieXRlCTB4OA0KCS5ieXRlCTB4MA0KCS51YWhhbGYJ MHgwDQoJLnVhaGFsZgkweDANCgkudWF4d29yZAkuTEx0ZXh0MA0KCS51YXh3 b3JkCS5MTGV0ZXh0MC0uTEx0ZXh0MA0KCS51YXh3b3JkCTB4MA0KCS51YXh3 b3JkCTB4MA0KCS5zZWN0aW9uCS5kZWJ1Z19zdHIsIk1TIixAcHJvZ2JpdHMs MQ0KLkxMQVNGMjg6DQoJLmFzY2l6CSJtc2dfY29udHJvbGxlbiINCi5MTEFT RjMwOg0KCS5hc2NpegkiY21zZ2hkciINCi5MTEFTRjE2Og0KCS5hc2Npegki c2l6ZV90Ig0KLkxMQVNGMjM6DQoJLmFzY2l6CSJtc2dfbmFtZSINCi5MTEFT RjM5Og0KCS5hc2Npegkic3NoX21tX3JlY2VpdmVfZmQiDQouTExBU0YzMzoN CgkuYXNjaXoJImNtc2dfdHlwZSINCi5MTEFTRjE5Og0KCS5hc2NpegkiaW92 X2xlbiINCi5MTEFTRjMyOg0KCS5hc2NpegkiY21zZ19sZXZlbCINCi5MTEFT RjI5Og0KCS5hc2NpegkibXNnX2ZsYWdzIg0KLkxMQVNGNDA6DQoJLmFzY2l6 CSJzc2hfbW1fc2VuZF9mZCINCi5MTEFTRjE3Og0KCS5hc2Npegkic3NpemVf dCINCi5MTEFTRjM1Og0KCS5hc2NpegkiX19mdW5jX18iDQouTExBU0YxMToN CgkuYXNjaXoJImZsb2F0Ig0KLkxMQVNGMjI6DQoJLmFzY2l6CSJtc2doZHIi DQouTExBU0YzNjoNCgkuYXNjaXoJInNvY2siDQouTExBU0YxOg0KCS5hc2Np egkidW5zaWduZWQgY2hhciINCi5MTEFTRjMxOg0KCS5hc2NpegkiY21zZ19s ZW4iDQouTExBU0Y5Og0KCS5hc2NpegkibG9uZyB1bnNpZ25lZCBpbnQiDQou TExBU0YzOg0KCS5hc2Npegkic2hvcnQgdW5zaWduZWQgaW50Ig0KLkxMQVNG Mjc6DQoJLmFzY2l6CSJtc2dfY29udHJvbCINCi5MTEFTRjY6DQoJLmFzY2l6 CSJfX2ludDY0X3QiDQouTExBU0YxMDoNCgkuYXNjaXoJImRvdWJsZSINCi5M TEFTRjIxOg0KCS5hc2NpegkiaW92ZWMiDQouTExBU0Y1Og0KCS5hc2Npegki X191aW50MzJfdCINCi5MTEFTRjE4Og0KCS5hc2NpegkiaW92X2Jhc2UiDQou TExBU0Y0Og0KCS5hc2NpegkidW5zaWduZWQgaW50Ig0KLkxMQVNGMTU6DQoJ LmFzY2l6CSJjaGFyIg0KLkxMQVNGMjU6DQoJLmFzY2l6CSJtc2dfaW92Ig0K LkxMQVNGMTM6DQoJLmFzY2l6CSJfX3NzaXplX3QiDQouTExBU0YyNjoNCgku YXNjaXoJIm1zZ19pb3ZsZW4iDQouTExBU0YzODoNCgkuYXNjaXoJIi91c3Iv c3JjL3NlY3VyZS9saWIvbGlic3NoLy4uLy4uLy4uL2NyeXB0by9vcGVuc3No L21vbml0b3JfZmRwYXNzLmMiDQouTExBU0YzNDoNCgkuYXNjaXoJImNtc2ci DQouTExBU0YyNDoNCgkuYXNjaXoJIm1zZ19uYW1lbGVuIg0KLkxMQVNGMzc6 DQoJLmFzY2l6CSJHTlUgQyA0LjIuMCAyMDA3MDUxNCBbRnJlZUJTRF0iDQou TExBU0YyOg0KCS5hc2Npegkic2hvcnQgaW50Ig0KLkxMQVNGODoNCgkuYXNj aXoJIl9fdWludDY0X3QiDQouTExBU0YxMjoNCgkuYXNjaXoJIl9fc2l6ZV90 Ig0KLkxMQVNGNzoNCgkuYXNjaXoJImxvbmcgaW50Ig0KLkxMQVNGMjA6DQoJ LmFzY2l6CSJzb2NrbGVuX3QiDQouTExBU0YxNDoNCgkuYXNjaXoJIl9fc29j a2xlbl90Ig0KLkxMQVNGMDoNCgkuYXNjaXoJInNpZ25lZCBjaGFyIg0KCS5p ZGVudAkiR0NDOiAoR05VKSA0LjIuMCAyMDA3MDUxNCBbRnJlZUJTRF0iDQo= ---559023410-758783491-1184532601=:29570-- From owner-freebsd-current@FreeBSD.ORG Sun Jul 15 20:56:34 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E240C16A401 for ; Sun, 15 Jul 2007 20:56:34 +0000 (UTC) (envelope-from michiel@boland.org) Received: from neerbosch.nijmegen.internl.net (neerbosch.nijmegen.internl.net [217.149.193.38]) by mx1.freebsd.org (Postfix) with ESMTP id 805AB13C481 for ; Sun, 15 Jul 2007 20:56:34 +0000 (UTC) (envelope-from michiel@boland.org) Received: from neerbosch.nijmegen.internl.net by neerbosch.nijmegen.internl.net via neerbosch.nijmegen.internl.net [217.149.193.38] with ESMTP id l6FKuPA6006170 (8.13.4/1.4); Sun, 15 Jul 2007 22:56:25 +0200 (MEST) Received: from localhost by neerbosch.nijmegen.internl.net via mboland@localhost with ESMTP id l6FKuPHq006167 (8.13.4/2.02); Sun, 15 Jul 2007 22:56:25 +0200 (MEST) X-Authentication-Warning: neerbosch.nijmegen.internl.net: mboland owned process doing -bs Date: Sun, 15 Jul 2007 22:56:25 +0200 (MEST) From: Michiel Boland To: d@delphij.net In-Reply-To: <46973584.9020404@delphij.net> Message-ID: References: <46973584.9020404@delphij.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: immediate reboot with ipnat/ipmon on amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jul 2007 20:56:35 -0000 Hi. Sorry about the delay. > Do you have access to system console to confirm that it does not panic > and just rebooted? Looks like a panic I think... There does indeed seem to be some kind of panic. After attaching serial console, I got this. Memory modified after free 0xffffff00090da480(56) val=3f91400 @ 0xffffff00090da498 panic: Most recently used by temp KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a panic() at panic+0x17c mtrash_ctor() at mtrash_ctor+0x84 uma_zalloc_arg() at uma_zalloc_arg+0x2cd malloc() at malloc+0x8a uifind() at uifind+0xa4 seteuid() at seteuid+0x49 syscall() at syscall+0x1ce Xfast_syscall() at Xfast_syscall+0xab --- syscall (183, FreeBSD ELF64, seteuid), rip = 0x8009b817c, rsp = 0x7fffffffed08, rbp = 0 --- I'm trying to do some real work, thus I had to bin the kernel that crashed. So I don't have any more info at the moment. From owner-freebsd-current@FreeBSD.ORG Sun Jul 15 21:08:09 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3DBCD16A402 for ; Sun, 15 Jul 2007 21:08:09 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [83.98.131.211]) by mx1.freebsd.org (Postfix) with ESMTP id CA1D913C461 for ; Sun, 15 Jul 2007 21:08:08 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 5EEBE1CCE9; Sun, 15 Jul 2007 23:06:10 +0200 (CEST) Date: Sun, 15 Jul 2007 23:06:10 +0200 From: Ed Schouten To: Michiel Boland Message-ID: <20070715210610.GA39075@hoeg.nl> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="xHFwDpU9dbj6ez1V" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.16 (2007-06-09) Cc: FreeBSD Current Subject: Re: sshd broken with UsePrivilegeSeparation=yes on sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jul 2007 21:08:09 -0000 --xHFwDpU9dbj6ez1V Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Michiel Boland wrote: > It looks like gcc mis-compiles /usr/src/crypto/openssh/monitor_fdpass.c o= n=20 > sparc64. For some reason it optimizes away the assignment of fd on line= =20 > 132: > > fd =3D (*(int *)CMSG_DATA(cmsg)); > > So I guess that every call to mm_receive_fd will return an undefined valu= e. > > If I add -O0 to CFLAGS in /usr/src/secure/lib/libssh/Makefile, ssh with= =20 > UsePrivilegeSeparation=3Dyes works again. > > So, obviously a gcc bug. I will try to generate a smaller test-case for= =20 > this. I've attached an email from Steve Kargl, which is about similar breakage in msun some months ago, right after the gcc 4.2 import: ----- Forwarded message from Steve Kargl = ----- > Date: Sun, 27 May 2007 12:39:29 -0700 > From: Steve Kargl > To: Kris Kennaway > Cc: freebsd-current@freebsd.org, Ed Schouten , > Stefan Ehmann > Subject: Re: HEADS-UP: gcc-4.2 import appears to miscompile libm. >=20 > On Sun, May 27, 2007 at 03:28:25PM -0400, Kris Kennaway wrote: > > On Sun, May 27, 2007 at 08:18:40AM -0700, Steve Kargl wrote: > >> On Sun, May 27, 2007 at 10:53:09AM +0200, Stefan Ehmann wrote: > >>> On Sunday 27 May 2007 01:31:16 Steve Kargl wrote: > >>>> On Sat, May 26, 2007 at 07:09:16PM -0400, Wes Morgan wrote: > >>>>> Working from -O towards -O2 based on the info pages, I can "reprodu= ce" > >>>>> the problem with "-O -fstrict-aliasing -fgcse"... However, -O2 with > >>>>> -fno-strict-aliasing by itself seems to work around the issue. At f= irst > >>>>> glance it looks like a possible interaction between several > >>>>> optimizations. > >>>> > >>>> Ths patch fixes the problem. > >>>> > >>>> --- s_frexpf.c.orig Sat May 26 16:26:50 2007 > >>>> +++ s_frexpf.c Sat May 26 16:28:03 2007 > >>>> @@ -39,6 +39,9 @@ > >>>> } > >>>> *eptr +=3D (ix>>23)-126; > >>>> hx =3D (hx&0x807fffff)|0x3f000000; > >>>> +#if 0 > >>>> *(int*)&x =3D hx; > >>>> +#endif > >>>> + SET_FLOAT_WORD(x,hx); > >>>> return x; > >>>> } > >>>=20 > >>> -fno-strict-aliasing is used by default for me (i386). Also, if you u= se -Wall=20 > >>> the compiler outputs a warning. > >>=20 > >> You apparently don't have CFLAGS set in /etc/make.conf. > >>=20 > >>> [root@something /usr/src/lib/msun/src]# cc -O2 -Wall -pipe -c s_frex= pf.c > >>> s_frexpf.c: In function 'frexpf': > >>> s_frexpf.c:42: warning: dereferencing type-punned pointer will break= =20 > >>> strict-aliasing rules > >>=20 > >> Yes, I know. > >>=20 > >> OTOH, the above patch actually fixes the problem, and libm can then > >> be compiled without -fno-strict-aliasing. > >=20 > > OK, so just to confirm, it's not a miscompilation as originally > > suggested, but a code bug? > >=20 >=20 > Yes, it is a code bug. It is my understanding that C (C99?)=20 > considers "*(int*)&x =3D hx;" to be undefined behavior. From > what I've gleaned from the gcc IRC channel, gcc-4.2 now does > a "load and store" instead of a "store and load" (or vice versa). >=20 > Of course, the patch touches libm so be prepared to be brucified. >=20 > --=20 > Steve >=20 ----- End forwarded message ----- I'm not sure whether it is related at all; it looks quite similar, because of the pointer casting + dereferencing. --=20 Ed Schouten WWW: http://g-rave.nl/ --xHFwDpU9dbj6ez1V Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGmoxC52SDGA2eCwURAqRAAJ9mn8C4T5u0FPtCfLTRg7AuKUZ2WACeMyF2 MiDkXwkgR2mAe5D1aKIIBig= =M/pj -----END PGP SIGNATURE----- --xHFwDpU9dbj6ez1V-- From owner-freebsd-current@FreeBSD.ORG Sun Jul 15 21:13:58 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 49BBE16A400 for ; Sun, 15 Jul 2007 21:13:58 +0000 (UTC) (envelope-from mat@FreeBSD.org) Received: from plouf.absolight.net (plouf.absolight.net [193.30.224.136]) by mx1.freebsd.org (Postfix) with ESMTP id 0DC3013C4B2 for ; Sun, 15 Jul 2007 21:13:57 +0000 (UTC) (envelope-from mat@FreeBSD.org) Received: from plouf.absolight.net (localhost [127.0.0.1]) by plouf.absolight.net (Postfix) with ESMTP id 838AD76401C for ; Sun, 15 Jul 2007 22:41:35 +0200 (CEST) Received: from atuin.in.mat.cc (ATuin.in.mat.cc [193.30.224.125]) by plouf.absolight.net (Postfix) with ESMTP id 65B57764018 for ; Sun, 15 Jul 2007 22:41:35 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by atuin.in.mat.cc (Postfix) with ESMTP id 4A91D4F3745 for ; Sun, 15 Jul 2007 22:41:43 +0200 (CEST) Date: Sun, 15 Jul 2007 22:41:39 +0200 From: Mathieu Arnold To: current@freebsd.org Message-ID: In-Reply-To: References: <46982752.3000508@paradise.net.nz> <20070714044036.GB8338@troutmask.apl.washington.edu> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========905475AE6F8564BF4DD0==========" Cc: Subject: Re: anoncvs.FreeBSD.org problems? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jul 2007 21:13:58 -0000 --==========905475AE6F8564BF4DD0========== Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline +-Le 14/07/07 00:41 -0600, Will Andrews a dit : | On 7/13/07, Steve Kargl wrote: |> anoncvs.FreeBSD.org has been broken for about 3 weeks. | | It will be back soon. In the meantime, people can use | anoncvs1.freebsd.org too. Or anoncvs.fr. -- Mathieu Arnold --==========905475AE6F8564BF4DD0========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iD8DBQFGmoaGJqR8av5thQ8RAv8RAKC+Fu4RwLXBZ/rq3tdUMDRk+mOfhwCg0EvZ ONdJXuJ29Dw/uXOEHoZwxtY= =qL5f -----END PGP SIGNATURE----- --==========905475AE6F8564BF4DD0==========-- From owner-freebsd-current@FreeBSD.ORG Sun Jul 15 21:23:21 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C00FD16A404 for ; Sun, 15 Jul 2007 21:23:21 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from vlakno.cz (vlk.vlakno.cz [62.168.28.247]) by mx1.freebsd.org (Postfix) with ESMTP id 7ACD213C491 for ; Sun, 15 Jul 2007 21:23:21 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from localhost (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id C8BA68BFE02 for ; Sun, 15 Jul 2007 23:23:19 +0200 (CEST) X-Virus-Scanned: amavisd-new at vlakno.cz Received: from vlakno.cz ([127.0.0.1]) by localhost (vlk.vlakno.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6f9M2G82D1ZR for ; Sun, 15 Jul 2007 23:23:18 +0200 (CEST) Received: from vlk.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id DA2688BFDE4 for ; Sun, 15 Jul 2007 23:23:18 +0200 (CEST) Received: (from rdivacky@localhost) by vlk.vlakno.cz (8.13.8/8.13.8/Submit) id l6FLNIPj021566 for current@freebsd.org; Sun, 15 Jul 2007 23:23:18 +0200 (CEST) (envelope-from rdivacky) Date: Sun, 15 Jul 2007 23:23:18 +0200 From: Roman Divacky To: current@freebsd.org Message-ID: <20070715212318.GA21485@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: Subject: process stuck in ttybg1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Jul 2007 21:23:21 -0000 hi I stumbled upon this: truss -D mc causes the mc to hang in "ttybg1" state. actually it livelocks receiving signal 22. hope someone can fix that :) thats on Jul 6th -current + kernel from roughly the same date. roman From owner-freebsd-current@FreeBSD.ORG Sun Jul 15 22:36:57 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6033116A403 for ; Sun, 15 Jul 2007 22:36:57 +0000 (UTC) (envelope-from matteo@freebsd.org) Received: from vsmtp4.tin.it (vsmtp4.tin.it [212.216.176.224]) by mx1.freebsd.org (Postfix) with ESMTP id 1B4DE13C48E for ; Sun, 15 Jul 2007 22:36:57 +0000 (UTC) (envelope-from matteo@freebsd.org) Received: from krapfengeist.krapfengeist (87.2.174.50) by vsmtp4.tin.it (7.3.122) id 469A4FF30007C721; Mon, 16 Jul 2007 00:25:21 +0200 Received: from krapfengeist.krapfengeist (rionda@localhost [127.0.0.1]) by krapfengeist.krapfengeist (8.14.1/8.14.1) with ESMTP id l6FMPKtE036989; Mon, 16 Jul 2007 00:25:20 +0200 (CEST) (envelope-from matteo@freebsd.org) Received: (from rionda@localhost) by krapfengeist.krapfengeist (8.14.1/8.14.1/Submit) id l6FMPKhE036988; Mon, 16 Jul 2007 00:25:20 +0200 (CEST) (envelope-from matteo@freebsd.org) X-Authentication-Warning: krapfengeist.krapfengeist: rionda set sender to matteo@freebsd.org using -f Date: Mon, 16 Jul 2007 00:25:20 +0200 From: Matteo Riondato To: Andrew Thompson Message-ID: <20070715222520.GD1413@krapfengeist.dei.unipd.it> References: <200707120254.l6C2s5Yg041022@repoman.freebsd.org> <20070713230833.GA2642@krapfengeist.dei.unipd.it> <20070715111346.GJ95956@heff.fud.org.nz> <20070715131140.GA1413@krapfengeist.dei.unipd.it> <20070715184818.GB10968@heff.fud.org.nz> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="q9KOos5vDmpwPx9o" Content-Disposition: inline In-Reply-To: <20070715184818.GB10968@heff.fud.org.nz> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: FreeBSD Current Subject: Re: cvs commit: src/sys/dev/if_ndis if_ndis.c if_ndisvar.h X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jul 2007 22:36:57 -0000 --q9KOos5vDmpwPx9o Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jul 16, 2007 at 06:48:18AM +1200, Andrew Thompson wrote: > On Sun, Jul 15, 2007 at 03:11:40PM +0200, Matteo Riondato wrote: > > ndis0: scan_restart: no channels to scan > =20 >=20 > Can you please test the attached patch, it also turns on debugging Yes. I'll try and report back ASAP. Thanks. Best regards --=20 Matteo Riondato FreeBSD Committer (http://www.freebsd.org) G.U.F.I. Staff Member (http://www.gufi.org) FreeSBIE Developer (http://www.freesbie.org) --q9KOos5vDmpwPx9o Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFGmp7Q2Mp4pR7Fa+wRAmfFAJ9oyLP/d2W86Fd7NcZPm/JlcRXADQCdEq2K xAU/dKvWXgxQH8vQnnVuegc= =wROF -----END PGP SIGNATURE----- --q9KOos5vDmpwPx9o-- From owner-freebsd-current@FreeBSD.ORG Mon Jul 16 00:17:35 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 87B3616A402 for ; Mon, 16 Jul 2007 00:17:35 +0000 (UTC) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id 6087D13C481 for ; Mon, 16 Jul 2007 00:17:35 +0000 (UTC) (envelope-from sam@errno.com) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id l6G0HXk6056597 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 15 Jul 2007 17:17:34 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <469AB9BD.3060300@errno.com> Date: Sun, 15 Jul 2007 17:20:13 -0700 From: Sam Leffler User-Agent: Thunderbird 2.0.0.0 (X11/20070530) MIME-Version: 1.0 To: Sven Braun References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Problems with ath_hal-20070428 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Jul 2007 00:17:35 -0000 Sven Braun wrote: > Hello everybody, > > I downloaded ath_hal-20070428.tgz by Sam Leffler and hoped it will > work with my Atheros AR5008 in my Macbook, 2nd generation. > > I went ahead in the following way: > > fetch http://people.freebsd.org/~sam/ath_hal-20070428.tgz > tar xfz ath_hal-20070428.tgz > cd ath_hal-20070428 > cp -R *.* /usr/src/sys/contrib/dev/ath/ > cd /usr/src > make buildkernel > > and got the following error: > > rm -f hack.c > MAKE=make sh /usr/src/sys/conf/newvers.sh MACBOOK > cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs > -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline > -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc > -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL > -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common > -finline-limit=8000 --param inline-unit-growth=100 --param > large-function-growth=1000 -mno-align-long-strings > -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 > -mno-sse3 -ffreestanding -Werror vers.c > linking kernel.debug > if_ath.o(.text+0x6b98): In function 'ath_getchannels': > /usr/src/sys/dev/ath/if_ath.c:5490: undefined reference to > 'ath_hal_isgsmsku' > *** Error code 1 > > Stop in /usr/obj/usr/src/sys/MACBOOK. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. > > > > I tried to fix the problem, but my C programming skills are > unfortunately low, so I ask you: > Do you know how to fix the problem? rm -rf /usr/obj/.../compile/MACBOOK and try doing make buildkernel again. if_ath.c needs to get the correct value of HAL_ABI_VERSION from sys/contrib/ah.h or you can get symptoms like this. Sam From owner-freebsd-current@FreeBSD.ORG Mon Jul 16 03:00:53 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6422C16A400; Mon, 16 Jul 2007 03:00:53 +0000 (UTC) (envelope-from christos@zoulas.com) Received: from rebar.astron.com (rebar.astron.com [38.117.134.202]) by mx1.freebsd.org (Postfix) with ESMTP id 26A8B13C4A6; Mon, 16 Jul 2007 03:00:52 +0000 (UTC) (envelope-from christos@zoulas.com) Received: by rebar.astron.com (Postfix, from userid 10080) id 1B43D56407; Sun, 15 Jul 2007 23:00:52 -0400 (EDT) From: christos@zoulas.com (Christos Zoulas) Date: Sun, 15 Jul 2007 23:00:52 -0400 In-Reply-To: <20070714005559.GB6661@kobe.laptop> from Giorgos Keramidas (Jul 14, 3:55am) Organization: Astron Software X-Mailer: Mail User's Shell (7.2.6 beta(4.pl1)+dynamic 20000103) To: Giorgos Keramidas Message-Id: <20070716030052.1B43D56407@rebar.astron.com> X-Mailman-Approved-At: Mon, 16 Jul 2007 03:09:11 +0000 Cc: tcsh-bugs@mx.gw.com, current@freebsd.org Subject: Re: tcsh backtick hang info X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Jul 2007 03:00:53 -0000 On Jul 14, 3:55am, keramida@freebsd.org (Giorgos Keramidas) wrote: -- Subject: Re: tcsh backtick hang info | On 2007-07-12 14:56, Christos Zoulas wrote: | > On Jul 12, 11:48am, dwhite@gumbysoft.com (Doug White) wrote: | > -- Subject: Re: tcsh backtick hang info | > | > | Thanks for the good words, Christos! If you can confirm this will be the | > | official patch then we can apply it to our vendor sources. If there are | > | any other fixes for nasty bugs in 6.15.00 that you're hanging on to it'd | > | be good to get those out and imported as well. | > | > You are welcome! | > This will be the official patch, and yes I have another 9 bug fixes since | > 6.15.00. In general, I don't make 6.15.XX generally available, but the | > severity of some of those problems fixed is high enough to possibly justify | > a 6.16.00 sooner than later. Here's the list of fixes: | > | > 10. kill `foo` got stuck because sigchld was disabled too soon (Mark Peek) | > 9. Avoid null pointer dereference in proc cwd (Kurt Miller) | > 8. eval "foreach a b c" exits (Anthony Menasse) | > 7. Quoting was broken in substitutions (Joe Wells) | > 6. QNX patches via pkgsrc | > 5. cd - twice from a directory that contained a glob pattern, | > expands the glob twice (Mark Santcroos) | > 4. MidnightBsd support (Lucas Holt) | > 3. Fix history substitution core-dump with no history entries | > 2. Merge two character tables that are the same (Martin Kraemer) | > 1. On ancient 7 bit locales, punctuation characters are used to | > denote special characters such as umlaut, adiaresis, etc. | > These characters return true for isalpha/isalnum. Ignore them | > because they break parsing (Martin Kraemer) | | Hi Christos, | | Can we persuade you to include the following local patch I keep for | autologout detection with /dev/pts/XXX ptys in FreeBSD? | | %%% | Fix pty detection logic of tcsh autologout initialization. | | Noticed by: kris | | diff --git a/contrib/tcsh/sh.c b/contrib/tcsh/sh.c | --- a/contrib/tcsh/sh.c | +++ b/contrib/tcsh/sh.c | @@ -457,7 +457,7 @@ main(int argc, char **argv) | if (*cp) { | /* only for login shells or root and we must have a tty */ | if ((cp2 = Strrchr(cp, (Char) '/')) != NULL) { | - cp = cp2 + 1; | + cp2 = cp2 + 1; | } | else | cp2 = cp; | %%% The code is wrong but I think that the fix is not exactly right... The following should work: /* only for login shells or root and we must have a tty */ if ((cp2 = Strrchr(cp, (Char) '/')) != NULL) { cp2 = cp2 + 1; } else cp2 = cp; if (!(((Strncmp(cp2, STRtty, 3) == 0) && Isalpha(cp2[3])) || Strstr(cp, Strslptssl) != NULL)) { if (getenv("DISPLAY") == NULL) { /* NOT on X window shells */ setcopy(STRautologout, STRdefautologout, VAR_READWRITE); } } Thanks for the bug report. wonder how come nobody complained for years! christos From owner-freebsd-current@FreeBSD.ORG Mon Jul 16 03:46:48 2007 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C503116A400 for ; Mon, 16 Jul 2007 03:46:48 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (adsl-75-1-14-242.dsl.scrm01.sbcglobal.net [75.1.14.242]) by mx1.freebsd.org (Postfix) with ESMTP id 738A713C4B2 for ; Mon, 16 Jul 2007 03:46:48 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id l6G396le006568 for ; Sun, 15 Jul 2007 20:09:10 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200707160309.l6G396le006568@gw.catspoiler.org> Date: Sun, 15 Jul 2007 20:09:06 -0700 (PDT) From: Don Lewis To: current@FreeBSD.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: Subject: hang on reboot or shutdown with 7.0-CURRENT i386 on AMD X2 + GeForce 7050 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Jul 2007 03:46:48 -0000 I just did a hardware and software upgrade on one of my machines. I've got the 7.0-CURRENT on it from July 13th, and the hardware is an AMD 64 X2 with the recently released Nvidia GeForce 7050 / nForce 630a. I'm running the i386 version of the kernel so that I can use the Nvidia closed-source video driver. Everything seems to work ok, except that the machine hangs after the "Uptime" message when I run "shutdown -r" or "shutdown -p". Setting either hw.acpi.disable_on_reboot or hw.acpi.handle_reboot to 1 makes no difference. I'm unable to break into DDB and I have to resort to the reset button. Copyright (c) 1992-2007 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.0-CURRENT #202: Fri Jul 13 19:40:56 PDT 2007 dl@scratch.catspoiler.org:/usr/obj/usr/src/sys/GENERICSMB WARNING: WITNESS option enabled, expect reduced performance. ACPI APIC Table: Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 4800+ (2500.02-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x60fb1 Stepping = 1 Features=0x178bfbff Features2=0x2001 AMD Features=0xea500800 AMD Features2=0x11f Cores per package: 2 real memory = 2079260672 (1982 MB) avail memory = 2024882176 (1931 MB) FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ACPI Warning (tbfadt-0505): Optional field "Pm2ControlBlock" has zero address or length: 0 0/1 [20070320] ioapic0: Changing APIC ID to 2 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) acpi0: on motherboard acpi0: [ITHREAD] acpi_hpet0: iomem 0xfeff0000-0xfeff03ff on acpi0 Timecounter "HPET" frequency 25000000 Hz quality 2000 acpi0: Power Button (fixed) acpi0: reservation of feff0000, 100 (3) failed acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 7bdf0000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 cpu0: on acpi0 powernow0: on cpu0 cpu1: on acpi0 powernow1: on cpu1 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: at device 0.0 (no driver attached) isab0: at device 1.0 on pci0 isa0: on isab0 nfsmb0: port 0xfc00-0xfc3f,0x1c00-0x1c3f,0xf400-0xf43f irq 20 at device 1.1 on pci0 smbus0: on nfsmb0 smb0: on smbus0 nfsmb1: on nfsmb0 smbus1: on nfsmb1 smb1: on smbus1 pci0: at device 1.2 (no driver attached) ohci0: mem 0xfe02f000-0xfe02ffff irq 21 at device 2.0 on pci0 ohci0: [GIANT-LOCKED] ohci0: [ITHREAD] usb0: OHCI version 1.0, legacy support usb0: on ohci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 6 ports with 6 removable, self powered ehci0: mem 0xfe02e000-0xfe02e0ff irq 22 at device 2.1 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb1: EHCI version 1.0 usb1: companion controller, 12 ports each: usb0 usb1: on ehci0 usb1: USB revision 2.0 uhub1: on usb1 uhub1: 6 ports with 6 removable, self powered ohci1: mem 0xfe02d000-0xfe02dfff irq 23 at device 4.0 on pci0 ohci1: [GIANT-LOCKED] ohci1: [ITHREAD] usb2: OHCI version 1.0, legacy support usb2: on ohci1 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 6 ports with 6 removable, self powered ehci1: mem 0xfe02c000-0xfe02c0ff irq 20 at device 4.1 on pci0 ehci1: [GIANT-LOCKED] ehci1: [ITHREAD] usb3: EHCI version 1.0 usb3: companion controller, 12 ports each: usb2 usb3: on ehci1 usb3: USB revision 2.0 uhub3: on usb3 uhub3: 6 ports with 6 removable, self powered atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xf000-0xf00f at device 6.0 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] pci0: at device 7.0 (no driver attached) pcib1: at device 8.0 on pci0 pci1: on pcib1 fwohci0: mem 0xfd0ff000-0xfd0ff7ff,0xfd0f8000-0xfd0fbfff irq 19 at device 7.0 on pci1 fwohci0: [FILTER] fwohci0: OHCI version 1.10 (ROM=1) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:50:8d:00:00:99:f0:69 fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 dcons_crom0: on firewire0 dcons_crom0: bus_addr 0x1358000 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:50:8d:99:f0:69 fwe0: Ethernet address: 02:50:8d:99:f0:69 fwip0: on firewire0 fwip0: Firewire address: 00:50:8d:00:00:99:f0:69 @ 0xfffe00000000, S400, maxrec 2048 sbp0: on firewire0 fwohci0: Initiate bus reset fwohci0: BUS reset fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode ahc0: port 0xcc00-0xccff mem 0xfd0fe000-0xfd0fefff irq 17 at device 9.0 on pci1 ahc0: [ITHREAD] aic7892: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs atapci1: port 0x9f0-0x9f7,0xbf0-0xbf3,0x970-0x977,0xb70-0xb73,0xdc00-0xdc0f mem 0xfe026000-0xfe027fff irq 22 at device 9.0 on pci0 atapci1: [ITHREAD] ata2: on atapci1 ata2: [ITHREAD] ata3: on atapci1 ata3: [ITHREAD] nfe0: port 0xd800-0xd807 mem 0xfe02b000-0xfe02bfff,0xfe02a000-0xfe02a0ff,0xfe029000-0xfe02900f irq 23 at device 10.0 on pci0 miibus0: on nfe0 e1000phy0: PHY 1 on miibus0 e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX-FDX, auto nfe0: Ethernet address: 00:50:8d:9f:6d:e3 nfe0: [FILTER] nfe0: [FILTER] nfe0: [FILTER] nfe0: [FILTER] nfe0: [FILTER] nfe0: [FILTER] nfe0: [FILTER] nfe0: [FILTER] pcib2: at device 11.0 on pci0 pci2: on pcib2 pcib3: at device 12.0 on pci0 pci3: on pcib3 pcib4: at device 13.0 on pci0 pci4: on pcib4 pcib5: at device 14.0 on pci0 pci5: on pcib5 pcib6: at device 15.0 on pci0 pci6: on pcib6 pcib7: at device 16.0 on pci0 pci7: on pcib7 pcib8: at device 17.0 on pci0 pci8: on pcib8 vgapci0: mem 0xfb000000-0xfbffffff,0xe0000000-0xefffffff,0xfc000000-0xfcffffff irq 20 at device 18.0 on pci0 acpi_tz0: on acpi0 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FILTER] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model MouseMan+, device ID 0 pmtimer0 on isa0 ppc0: parallel port not found. sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 8250 or not responding sio0: [FILTER] sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounters tick every 1.000 msec firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) acd0: CDROM at ata0-master UDMA33 ad4: 476940MB at ata2-master UDMA33 ad5: 476940MB at ata2-slave UDMA33 Waiting 3 seconds for SCSI devices to settle da0 at ahc0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-3 device da0: 160.000MB/s transfers (80.000MHz DT, offset 63, 16bit) da0: Command Queueing Enabled da0: 35003MB (71687370 512 byte sectors: 255H 63S/T 4462C) SMP: AP CPU #1 Launched! WARNING: WITNESS option enabled, expect reduced performance. GEOM_LABEL: Label for provider da0s3 is ext2fs//. Trying to mount root from ufs:/dev/da0s1a pid 717 (rpc.statd), uid 0: exited on signal 11 Waiting (max 60 seconds) for system process `vnlru' to stop...done Waiting (max 60 seconds) for system process `bufdaemon' to stop...done Waiting (max 60 seconds) for system process `syncer' to stop... Syncing disks, vnodes remaining...2 1 1 1 1 0 0 done All buffers synced. From owner-freebsd-current@FreeBSD.ORG Mon Jul 16 04:12:18 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E441216A403; Mon, 16 Jul 2007 04:12:18 +0000 (UTC) (envelope-from snezhko@indorsoft.ru) Received: from indorsoft.ru (indor.net.tomline.ru [213.183.100.90]) by mx1.freebsd.org (Postfix) with ESMTP id 090D513C481; Mon, 16 Jul 2007 04:12:17 +0000 (UTC) (envelope-from snezhko@indorsoft.ru) Received: from SNEZHKO by indorsoft.ru (MDaemon.PRO.v7.2.2.R) with ESMTP id md50000220503.msg; Mon, 16 Jul 2007 11:12:12 +0700 From: Victor Snezhko To: David Malone References: <20070709214216.GA72912@walton.maths.tcd.ie> <20070711132202.GA95487@walton.maths.tcd.ie> Date: Mon, 16 Jul 2007 11:12:07 +0700 In-Reply-To: <20070711132202.GA95487@walton.maths.tcd.ie> (David Malone's message of "Wed, 11 Jul 2007 14:22:02 +0100") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.3 (windows-nt) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Processed: indor.net.tomline.ru, Mon, 16 Jul 2007 11:12:13 +0700 (not processed: spam filter disabled) X-Return-Path: snezhko@indorsoft.ru Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, Ivan Voras Subject: Re: Debugging times X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Jul 2007 04:12:19 -0000 David Malone writes: >> Yes, I'll test them. >> >> The problem is - the same kernel works when booted off a hard drive, so >> unless the VMWare BIOS is very messed up (it's the first time I see such >> problems) it may not help. Please, scatter debug printf's around so I >> can see what's going on :) > > Try the patch at: > > http://www.maths.tcd.ie/~dwmalone/clock.patch > > It checks the return values of the various clock reading functions > in the kernel and prints an error message if it finds that it can't > set the clock OK. Some machines have a BIOS that doesn't count the > day-of-week correctly, and recently FreeBSD has started treating > this as an error on some platforms. Just a "mee too" - I've been suffering from precisely this problem - on a hardware box, not vmware. I have instrumented clock_ts_to_ct in my kernel to see what happens, and yes, ct.dow is 0 today, on monday, and day_of_week(days) expects 1. I couldn't find on what day of week dow should be 0 anywhere in the specs - on sunday or on monday - so probably there are just bioses that behave differently in this respect. Thanks for clarifying the issue. Also, this was a surprise to an unexperienced me, but I have also found that vfs_mount initializes RTC with the latest timestamp found on local file systems - this explains why kernel "worked" for Ivan on a hard drive. It didn't actually work, but used timestamp which was stored on filesystem during unmount. -- WBR, Victor V. Snezhko E-mail: snezhko@indorsoft.ru From owner-freebsd-current@FreeBSD.ORG Mon Jul 16 05:39:03 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 82C7116A403 for ; Mon, 16 Jul 2007 05:39:03 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with SMTP id 3D85213C4A5 for ; Mon, 16 Jul 2007 05:39:03 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 19886 invoked by uid 399); 16 Jul 2007 05:39:02 -0000 Received: from localhost (HELO lap.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTP; 16 Jul 2007 05:39:02 -0000 X-Originating-IP: 127.0.0.1 Message-ID: <469B0475.8040109@FreeBSD.org> Date: Sun, 15 Jul 2007 22:39:01 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.4 (X11/20070617) MIME-Version: 1.0 To: Thomas-Martin Seck References: <200707151438.l6FEcO0D038114@bledge.tmseck.homedns.org> In-Reply-To: <200707151438.l6FEcO0D038114@bledge.tmseck.homedns.org> X-Enigmail-Version: 0.95.1 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: HEADS UP: netatm disabling taking place shortly X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Jul 2007 05:39:03 -0000 Thomas-Martin Seck wrote: > * Robert Watson [gmane.os.freebsd.current]: > >> On Sat, 14 Jul 2007, Doug Barton wrote: >> >>> This is cool stuff, thanks for your dogged persistence in eliminating GIANT >>> from the network stack! >>> >>> One tiny thing I've noticed doing a buildworld tonight, because of the way >>> that /usr/src/usr.bin/kdump/mkioctls works (starting at line 19) it's >>> necessary to remove /usr/include/netatm _before_ trying to build. You might >>> want to include that in any instructions you send out regarding this change >>> (and maybe in UPDATING). If I've missed where you've said that already, >>> sorry for the noise. >> It's odd, actually -- I ran into this a couple of times earlier in preparing >> the patch, but didn't run into it with later versions after I redid the >> include things, etc. For example, on a vanilla machine (from a couple of >> weeks ago) now, I don't see the problem during buildworld. Obviously, a bit >> more debugging is called for. Could you try removing the tree in /usr/obj and >> see if that helps? Perhaps things are lasting between build runs... > > The error is probably caused by stale includes in > /usr/obj/usr/src/tmp/usr/include. This should only happen when one > builds with NO_CLEAN defined. It depends on how you're trying to build it. If you're building kdump in /usr/src/usr.bin/kdump then you have to remove the includes from /usr/include first. If you're doing it as part of buildworld you either have to not use -DNO_CLEAN (I almost always do use that) or remove them by hand from the directory you mentioned above first. Sorry if I caused any confusion, but I thought it went without saying that the buildworld with the new sources should be run without -DNO_CLEAN. My typical process is to start buildworld with it, then if it fails I build the thing that failed by hand with 'make cleandir && make obj && make depend && make all'. I was fairly surprised when that didn't work in this case. I actually managed to get bit both ways on this one. :) I think it would be useful to mention this explicitly somewhere ... and probably also useful to add the old stuff to the ObsoleteFiles.inc. It can always be deleted from there later if the thing gets locked properly. My fear is that by leaving those includes around there is going to be confusion that could otherwise be easily avoided. Doug -- This .signature sanitized for your protection From owner-freebsd-current@FreeBSD.ORG Mon Jul 16 05:46:27 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B362C16A404 for ; Mon, 16 Jul 2007 05:46:27 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with SMTP id 54C5713C4B7 for ; Mon, 16 Jul 2007 05:46:27 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 26317 invoked by uid 399); 16 Jul 2007 05:46:27 -0000 Received: from localhost (HELO lap.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTP; 16 Jul 2007 05:46:27 -0000 X-Originating-IP: 127.0.0.1 Message-ID: <469B0631.3080707@FreeBSD.org> Date: Sun, 15 Jul 2007 22:46:25 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.4 (X11/20070617) MIME-Version: 1.0 To: Thomas-Martin Seck References: <200707151438.l6FEcO0D038114@bledge.tmseck.homedns.org> <469B0475.8040109@FreeBSD.org> In-Reply-To: <469B0475.8040109@FreeBSD.org> X-Enigmail-Version: 0.95.1 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: HEADS UP: netatm disabling taking place shortly X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Jul 2007 05:46:27 -0000 Doug Barton wrote: > and probably also useful to add the old stuff to the > ObsoleteFiles.inc. Which I see was done in the latest version. :) Doug -- This .signature sanitized for your protection From owner-freebsd-current@FreeBSD.ORG Mon Jul 16 06:37:38 2007 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7F80016A403; Mon, 16 Jul 2007 06:37:38 +0000 (UTC) (envelope-from itetcu@FreeBSD.org) Received: from it.buh.tecnik93.com (it.buh.tecnik93.com [81.196.204.98]) by mx1.freebsd.org (Postfix) with ESMTP id 37F5D13C461; Mon, 16 Jul 2007 06:37:38 +0000 (UTC) (envelope-from itetcu@FreeBSD.org) Received: from it.buh.tecnik93.com (localhost [127.0.0.1]) by it.buh.tecnik93.com (Postfix) with ESMTP id EB2A02C50CB2; Mon, 16 Jul 2007 09:21:37 +0300 (EEST) Date: Mon, 16 Jul 2007 09:21:31 +0300 From: Ion-Mihai Tetcu To: Don Lewis Message-ID: <20070716092131.42143bf3@it.buh.tecnik93.com> In-Reply-To: <200707160309.l6G396le006568@gw.catspoiler.org> References: <200707160309.l6G396le006568@gw.catspoiler.org> X-Mailer: Claws Mail 2.10.0 (GTK+ 2.10.13; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: multipart/signed; boundary=Sig_lugz8zU3x7ygg_QXd+5_jME; protocol="application/pgp-signature"; micalg=PGP-SHA1 Cc: current@FreeBSD.org Subject: Re: hang on reboot or shutdown with 7.0-CURRENT i386 on AMD X2 + GeForce 7050 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Jul 2007 06:37:38 -0000 --Sig_lugz8zU3x7ygg_QXd+5_jME Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Sun, 15 Jul 2007 20:09:06 -0700 (PDT) Don Lewis wrote: > I just did a hardware and software upgrade on one of my machines. > I've got the 7.0-CURRENT on it from July 13th, and the hardware is an > AMD 64 X2 with the recently released Nvidia GeForce 7050 / nForce > 630a. I'm running the i386 version of the kernel so that I can use > the Nvidia closed-source video driver. >=20 > Everything seems to work ok, except that the machine hangs after the > "Uptime" message when I run "shutdown -r" or "shutdown -p". Setting > either hw.acpi.disable_on_reboot or hw.acpi.handle_reboot to 1 makes > no difference. I'm unable to break into DDB and I have to resort to > the reset button. I've seen the same on fairly similar hardware, with a few days (10 Jul I think) sources, but I'm not seeing it with FreeBSD 7.0-CURRENT #0: Thu Jul 12 20:31:29 EEST 2007. Maybe you could try to go back to the same sources I use and see if it makes any difference ? --=20 IOnut - Un^d^dregistered ;) FreeBSD "user" "Intellectual Property" is nowhere near as valuable as "Intellect" --Sig_lugz8zU3x7ygg_QXd+5_jME Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFGmw5xBX6fi0k6KXsRAr4+AJ4r4bzNKNrz+8BVAliCZR1Jy04zSQCbBt3j IjlVj+xn0HyCazhRoecvfMg= =0ZUr -----END PGP SIGNATURE----- --Sig_lugz8zU3x7ygg_QXd+5_jME-- From owner-freebsd-current@FreeBSD.ORG Mon Jul 16 07:01:22 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B120F16A405 for ; Mon, 16 Jul 2007 07:01:22 +0000 (UTC) (envelope-from ganbold@micom.mng.net) Received: from publicd.ub.mng.net (publicd.ub.mng.net [202.179.0.88]) by mx1.freebsd.org (Postfix) with ESMTP id AEC8413C478 for ; Mon, 16 Jul 2007 07:01:21 +0000 (UTC) (envelope-from ganbold@micom.mng.net) Received: from [202.179.0.164] (helo=daemon.micom.mng.net) by publicd.ub.mng.net with esmtpa (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IAKa3-000AZ0-7r for freebsd-current@freebsd.org; Mon, 16 Jul 2007 15:01:15 +0800 Message-ID: <469B17BB.9050305@micom.mng.net> Date: Mon, 16 Jul 2007 15:01:15 +0800 From: Ganbold User-Agent: Thunderbird 2.0.0.0 (X11/20070425) MIME-Version: 1.0 To: "freebsd-current@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: LOR when running google-earth X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Jul 2007 07:01:22 -0000 Hi, I'm having LOR when I try to run google-earth. I have Intel 945GM graphic card. devil# uname -an FreeBSD devil.micom.mng.net 7.0-CURRENT FreeBSD 7.0-CURRENT #1: Tue Jul 10 10:44:42 ULAT 2007 root@devil.micom.mng.net:/usr/obj/usr/src/sys/DEVIL i386 devil# lock order reversal: (sleepable after non-sleepable) 1st 0xc3c06cd8 drm device (drm device) @ /usr/src/sys/modules/drm/drm/../../../dev/drm/drm_drv.c:907 2nd 0xc3e6ea3c user map (user map) @ /usr/src/sys/vm/vm_glue.c:182 KDB: stack backtrace: db_trace_self_wrapper(c08a3fa4,e6450a44,c066992e,c08a6485,c3e6ea3c,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c08a6485,c3e6ea3c,c08be517,c08be517,c08bdfed,...) at kdb_backtrace+0x29 witness_checkorder(c3e6ea3c,9,c08bdfed,b6,c435a000,...) at witness_checkorder+0x6de _sx_xlock(c3e6ea3c,0,c08bdfed,b6,e6450aa8,...) at _sx_xlock+0x7d _vm_map_lock_read(c3e6e9f8,c08bdfed,b6,c435a000,a60,...) at _vm_map_lock_read+0x50 useracc(4ce1ede8,8,1,f5,c09ce1bc,...) at useracc+0x65 i915_cmdbuffer(c3bf3800,8018644b,c43814a0,3,c435a000,...) at i915_cmdbuffer+0x10f drm_ioctl(c3bf3800,8018644b,c43814a0,3,c435a000,...) at drm_ioctl+0x357 giant_ioctl(c3bf3800,8018644b,c43814a0,3,c435a000,...) at giant_ioctl+0x56 devfs_ioctl_f(c4cdd1b0,8018644b,c43814a0,c4356700,c435a000,...) at devfs_ioctl_f+0xc9 kern_ioctl(c435a000,9,8018644b,c43814a0,450c4c,...) at kern_ioctl+0x243 ioctl(c435a000,e6450cfc,e6450c80,c4022e4a,c435a000,...) at ioctl+0x134 linux_ioctl_drm(c435a000,e6450cfc,c4030c45,a2f,c435a000,...) at linux_ioctl_drm+0x2f linux_ioctl(c435a000,e6450cfc,e6450cf8,e6450d1c,c4032dd0,...) at linux_ioctl+0xca syscall(e6450d38) at syscall+0x2b3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (54, Linux ELF, linux_ioctl), eip = 0x49ea95f4, esp = 0xbfbfdf44, ebp = 0xbfbfdf64 --- KDB: enter: witness_checkorder [thread pid 899 tid 100122 ] Stopped at kdb_enter+0x32: leave db> bt Tracing pid 899 tid 100122 td 0xc435a000 kdb_enter(c0861150,c3e6ea3c,c08be517,c08be517,c08bdfed,...) at kdb_enter+0x32 witness_checkorder(c3e6ea3c,9,c08bdfed,b6,c435a000,...) at witness_checkorder+0x6f3 _sx_xlock(c3e6ea3c,0,c08bdfed,b6,e6450aa8,...) at _sx_xlock+0x7d _vm_map_lock_read(c3e6e9f8,c08bdfed,b6,c435a000,a60,...) at _vm_map_lock_read+0x50 useracc(4ce1ede8,8,1,f5,c09ce1bc,...) at useracc+0x65 i915_cmdbuffer(c3bf3800,8018644b,c43814a0,3,c435a000,...) at i915_cmdbuffer+0x10f drm_ioctl(c3bf3800,8018644b,c43814a0,3,c435a000,...) at drm_ioctl+0x357 giant_ioctl(c3bf3800,8018644b,c43814a0,3,c435a000,...) at giant_ioctl+0x56 devfs_ioctl_f(c4cdd1b0,8018644b,c43814a0,c4356700,c435a000,...) at devfs_ioctl_f+0xc9 kern_ioctl(c435a000,9,8018644b,c43814a0,450c4c,...) at kern_ioctl+0x243 ioctl(c435a000,e6450cfc,e6450c80,c4022e4a,c435a000,...) at ioctl+0x134 linux_ioctl_drm(c435a000,e6450cfc,c4030c45,a2f,c435a000,...) at linux_ioctl_drm+0x2f linux_ioctl(c435a000,e6450cfc,e6450cf8,e6450d1c,c4032dd0,...) at linux_ioctl+0xca syscall(e6450d38) at syscall+0x2b3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (54, Linux ELF, linux_ioctl), eip = 0x49ea95f4, esp = 0xbfbfdf44, ebp = 0xbfbfdf64 --- db> c thanks, Ganbold -- He was part of my dream, of course -- but then I was part of his dream too. -- Lewis Carroll From owner-freebsd-current@FreeBSD.ORG Mon Jul 16 07:10:13 2007 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4ED8616A401 for ; Mon, 16 Jul 2007 07:10:13 +0000 (UTC) (envelope-from w0lfie@clear.net.nz) Received: from smtp3.clear.net.nz (smtp3.clear.net.nz [203.97.33.64]) by mx1.freebsd.org (Postfix) with ESMTP id 1EAA813C49D for ; Mon, 16 Jul 2007 07:10:12 +0000 (UTC) (envelope-from w0lfie@clear.net.nz) Received: from clear.net.nz (lb2-srcnat.clear.net.nz [203.97.32.237]) by smtp3.clear.net.nz (CLEAR Net Mail) with SMTP id <0JL900LPRF676300@smtp3.clear.net.nz> for current@FreeBSD.org; Mon, 16 Jul 2007 18:54:08 +1200 (NZST) Date: Mon, 16 Jul 2007 18:54:07 +1200 From: Sam Banks Sender: w0lfie@clear.net.nz To: current@FreeBSD.org Message-id: <469b160f.3c6.2409.12123@clear.net.nz> X-Mailer: CLEAR Net WebMail; webmail.clear.net.nz; user: w0lfie; ip: 121.73.22.121 Priority: normal Cc: Subject: ukbd patch advice X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: w0lfie@clear.net.nz List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2007 07:10:13 -0000 Hey all, I have been having a problem with my particular usb keyboard (0x03 was always being written into the first element of ukbd_data->keycode basically). I have tracked it down to a problem somewhere in between the uhci chipset (same problem with other cuts of uhci chipset), the uhci and/or ukbd drivers and the keyboard. A fix to the problem is to reorder members of the struct ukbd_data. Originally, the members are ordered as modifiers, reserved and keycode[6] (minus a bunch of #define's). If I change this order to reserved, modifiers and keycode[6], my keyboard starts to function as it should (minus lighting up the LED's but that's another email all together :)). With this reordering, it stops other usb keyboards which function with the original code from working. I'm wanting submit a patch for this fix (as other people are experiencing the same problems) but I'm not sure how to do this. I was thinking along the lines of the usb quirks function but it appears outside of a function body, you cannot have the normal if() type statements, only the preprocessor #ifdef types. To me, having a kernel config option for a single keyboard on a single driver seems quite overkill. Does anyone have any suggestions on what I should do or can anyone point me to some code that deals with a similar problem? On a side note, is anyone able to shed any light into why they think the above fix works? I am drawing a bit of a blank to be honest. Is it possible that my fix is only masking the problem? If you need any more info or whatever, yell out. Cheers, Sam. From owner-freebsd-current@FreeBSD.ORG Mon Jul 16 07:52:08 2007 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EEF4A16A401 for ; Mon, 16 Jul 2007 07:52:08 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from heff.fud.org.nz (203-109-251-39.static.bliink.ihug.co.nz [203.109.251.39]) by mx1.freebsd.org (Postfix) with ESMTP id 8C8F013C441 for ; Mon, 16 Jul 2007 07:52:08 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: by heff.fud.org.nz (Postfix, from userid 1001) id D94411CC58; Mon, 16 Jul 2007 19:52:06 +1200 (NZST) Date: Mon, 16 Jul 2007 19:52:06 +1200 From: Andrew Thompson To: Sam Banks Message-ID: <20070716075206.GA18510@heff.fud.org.nz> References: <469b160f.3c6.2409.12123@clear.net.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <469b160f.3c6.2409.12123@clear.net.nz> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: current@FreeBSD.org Subject: Re: ukbd patch advice X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Jul 2007 07:52:09 -0000 On Mon, Jul 16, 2007 at 06:54:07PM +1200, Sam Banks wrote: > Hey all, > > I have been having a problem with my particular usb keyboard > (0x03 was always being written into the first element of > ukbd_data->keycode basically). I have tracked it down to a > problem somewhere in between the uhci chipset (same problem > with other cuts of uhci chipset), the uhci and/or ukbd > drivers and the keyboard. > > A fix to the problem is to reorder members of the struct > ukbd_data. Originally, the members are ordered as modifiers, > reserved and keycode[6] (minus a bunch of #define's). If I > change this order to reserved, modifiers and keycode[6], my > keyboard starts to function as it should (minus lighting up > the LED's but that's another email all together :)). With > this reordering, it stops other usb keyboards which function > with the original code from working. Can you give a diff so people can see the different order. > > I'm wanting submit a patch for this fix (as other people are > experiencing the same problems) but I'm not sure how to do > this. I was thinking along the lines of the usb quirks > function but it appears outside of a function body, you > cannot have the normal if() type statements, only the > preprocessor #ifdef types. To me, having a kernel config > option for a single keyboard on a single driver seems quite > overkill. > > Does anyone have any suggestions on what I should do or can > anyone point me to some code that deals with a similar > problem? > > On a side note, is anyone able to shed any light into why > they think the above fix works? I am drawing a bit of a > blank to be honest. Is it possible that my fix is only > masking the problem? cheers, Andrew From owner-freebsd-current@FreeBSD.ORG Mon Jul 16 08:04:53 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A7AD616A403 for ; Mon, 16 Jul 2007 08:04:53 +0000 (UTC) (envelope-from Thomas.Sparrevohn@btinternet.com) Received: from smtp807.mail.ird.yahoo.com (smtp807.mail.ird.yahoo.com [217.146.188.67]) by mx1.freebsd.org (Postfix) with SMTP id 0545B13C442 for ; Mon, 16 Jul 2007 08:04:52 +0000 (UTC) (envelope-from Thomas.Sparrevohn@btinternet.com) Received: (qmail 10943 invoked from network); 16 Jul 2007 08:04:51 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=btinternet.com; h=Received:X-YMail-OSG:From:To:Subject:Date:User-Agent:Cc:References:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Content-Disposition:Message-Id; b=Gy5ZW1ifOnNMHVp3OdPH9Zll8/LRpY/XfGtF4k8wKlWZd83Ub0L5VoRhc313RApinbQ7HJq9HlzbaRbmsBk7b521umKtRUhP23F98vbnAaTx439KwLii+PvyVbXvNjg6kGSbge93zkl5++l2eI6mACtVEiMxEXTBRcVqGKrzadk= ; Received: from unknown (HELO w2fzz0vc03.aah-go-on.com) (thomas.sparrevohn@btinternet.com@86.136.24.44 with login) by smtp807.mail.ird.yahoo.com with SMTP; 16 Jul 2007 08:04:51 -0000 X-YMail-OSG: EcwQLLUVM1nmfeo90LWhwJw6PdU_FL_sL49JxY9KxWyWJJGP9bX5Gub3MnWx.uPz9pwIGLQ1XA-- From: Thomas Sparrevohn To: freebsd-current@freebsd.org Date: Mon, 16 Jul 2007 09:04:47 +0100 User-Agent: KMail/1.9.7 References: <200707160309.l6G396le006568@gw.catspoiler.org> <20070716092131.42143bf3@it.buh.tecnik93.com> In-Reply-To: <20070716092131.42143bf3@it.buh.tecnik93.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200707160904.47976.Thomas.Sparrevohn@btinternet.com> Cc: Don Lewis , Ion-Mihai Tetcu Subject: Re: hang on reboot or shutdown with 7.0-CURRENT i386 on AMD X2 + GeForce 7050 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Jul 2007 08:04:53 -0000 On Monday 16 July 2007 07:21:31 Ion-Mihai Tetcu wrote: > On Sun, 15 Jul 2007 20:09:06 -0700 (PDT) > Don Lewis wrote: > > > I've seen the same on fairly similar hardware, with a few days (10 Jul > I think) sources, but I'm not seeing it with FreeBSD 7.0-CURRENT #0: > Thu Jul 12 20:31:29 EEST 2007. > Maybe you could try to go back to the same sources I use and see if it > makes any difference ? > > I have had that problem since I got the machine I have now - It seems to be related to systems using Nvidia Nforce newer chipsets 570/590/6xx If I don't load any USB drivers the system shutsdown normally - I tried shutting down after disconnecting all external usb devices and all u* drivers one by one - unfortunately it seems that the minute "device usb" or usb.ko is present the problem reoccurs Regards Thomas From owner-freebsd-current@FreeBSD.ORG Mon Jul 16 08:08:51 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6428616A401; Mon, 16 Jul 2007 08:08:51 +0000 (UTC) (envelope-from ivoras@fer.hr) Received: from pinus.cc.fer.hr (pinus.cc.fer.hr [161.53.73.18]) by mx1.freebsd.org (Postfix) with ESMTP id E5A4413C4A8; Mon, 16 Jul 2007 08:08:50 +0000 (UTC) (envelope-from ivoras@fer.hr) Received: from [161.53.72.113] (lara.cc.fer.hr [161.53.72.113]) by pinus.cc.fer.hr (8.12.2/8.12.2) with ESMTP id l6G8L13f022093; Mon, 16 Jul 2007 10:21:02 +0200 (MEST) Message-ID: <469B2787.9010302@fer.hr> Date: Mon, 16 Jul 2007 10:08:39 +0200 From: Ivan Voras User-Agent: Thunderbird 1.5.0.12 (X11/20060911) MIME-Version: 1.0 To: Victor Snezhko References: <20070709214216.GA72912@walton.maths.tcd.ie> <20070711132202.GA95487@walton.maths.tcd.ie> In-Reply-To: X-Enigmail-Version: 0.94.2.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig36AEAB1499DAB0A2D2865BE7" Cc: David Malone , freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: Debugging times X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Jul 2007 08:08:51 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig36AEAB1499DAB0A2D2865BE7 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Victor Snezhko wrote: > Also, this was a surprise to an unexperienced me, but I have also > found that vfs_mount initializes RTC with the latest timestamp found > on local file systems - this explains why kernel "worked" for Ivan on > a hard drive. It didn't actually work, but used timestamp which was > stored on filesystem during unmount. Wow - this is just astonishing - why would a file system have anything=20 to do with the RTC? --------------enig36AEAB1499DAB0A2D2865BE7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFGmyeNldnAQVacBcgRAgF6AJ9yLcgI2KNUXY0V0QXTxnwdaD6XxACfeFYJ x/CwIdfx3D05eqxE6HiPvyE= =XoDq -----END PGP SIGNATURE----- --------------enig36AEAB1499DAB0A2D2865BE7-- From owner-freebsd-current@FreeBSD.ORG Mon Jul 16 08:11:51 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DCFEE16A403 for ; Mon, 16 Jul 2007 08:11:51 +0000 (UTC) (envelope-from almarrie@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.244]) by mx1.freebsd.org (Postfix) with ESMTP id 9896013C4A5 for ; Mon, 16 Jul 2007 08:11:51 +0000 (UTC) (envelope-from almarrie@gmail.com) Received: by an-out-0708.google.com with SMTP id c14so252041anc for ; Mon, 16 Jul 2007 01:11:50 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=WkXWDjZ2mEWDSwc6Qh+rB3npf9BIBdE2hihpg24w79HsNBcO/GA35KnNdP/nfJc3cmqP6wojL8wz0NIOt9/qgsX22q95Lwq44g+lEZvb+nj+jp/cNsMp6iNUkDyQaYNPhh1gxOQCoN5jVk5E64nlEbcetVMobFrYJpQkUw8y/gk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ShlTyqfrydnRaqWjq0lLOjIElcpombXgRi39ymoXjSmX1/N0Nf7jN/yNiR+mq5qiQux1kvcdWKR1SjamMwvFgCWWZSXVesxYR3p0yiqMyvSnS96v+MhiOnXHGrVQyIUeYubztAbPNwkMQvZ9oOqEi1dQpLGCTP5OaBJ3ycl1kO0= Received: by 10.100.174.16 with SMTP id w16mr2161624ane.1184573510672; Mon, 16 Jul 2007 01:11:50 -0700 (PDT) Received: by 10.100.9.14 with HTTP; Mon, 16 Jul 2007 01:11:50 -0700 (PDT) Message-ID: <499c70c0707160111g31410e07v2b7d20963c9190d@mail.gmail.com> Date: Mon, 16 Jul 2007 11:11:50 +0300 From: "Abdullah Ibn Hamad Al-Marri" To: "Thomas Sparrevohn" In-Reply-To: <200707160904.47976.Thomas.Sparrevohn@btinternet.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200707160309.l6G396le006568@gw.catspoiler.org> <20070716092131.42143bf3@it.buh.tecnik93.com> <200707160904.47976.Thomas.Sparrevohn@btinternet.com> Cc: Don Lewis , freebsd-current@freebsd.org, Ion-Mihai Tetcu Subject: Re: hang on reboot or shutdown with 7.0-CURRENT i386 on AMD X2 + GeForce 7050 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Jul 2007 08:11:51 -0000 On 7/16/07, Thomas Sparrevohn wrote: > On Monday 16 July 2007 07:21:31 Ion-Mihai Tetcu wrote: > > On Sun, 15 Jul 2007 20:09:06 -0700 (PDT) > > Don Lewis wrote: > > > > > > > I've seen the same on fairly similar hardware, with a few days (10 Jul > > I think) sources, but I'm not seeing it with FreeBSD 7.0-CURRENT #0: > > Thu Jul 12 20:31:29 EEST 2007. > > Maybe you could try to go back to the same sources I use and see if it > > makes any difference ? > > > > > > I have had that problem since I got the machine I have now - It seems to be related > to systems using Nvidia Nforce newer chipsets 570/590/6xx > > If I don't load any USB drivers the system shutsdown normally - I tried shutting down after > disconnecting all external usb devices and all u* drivers one by one - unfortunately it seems > that the minute "device usb" or usb.ko is present the problem reoccurs > > > Regards > Thomas I had the same problem, when I removed ehci from my kernel the problem went away, my mobo is ATI which is use in Acer 5102 WLMi and not nvidia. -- Regards, -Abdullah Ibn Hamad Al-Marri Arab Portal http://www.WeArab.Net/ From owner-freebsd-current@FreeBSD.ORG Mon Jul 16 08:59:28 2007 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 917FD16A401 for ; Mon, 16 Jul 2007 08:59:28 +0000 (UTC) (envelope-from bsd@kuehlbox.de) Received: from samael.qmail-ldap.de (mail.kuehlbox.de [62.159.47.22]) by mx1.freebsd.org (Postfix) with ESMTP id EDAA313C461 for ; Mon, 16 Jul 2007 08:59:27 +0000 (UTC) (envelope-from bsd@kuehlbox.de) Received: (qmail 23302 invoked from network); 16 Jul 2007 08:59:25 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlbox.de; b=GnF1PlyYOTZD02Q6Y5of649Cdc7dWmQmtSiOUCSnJBS7acdp0Ab+SJn/utuwv3cWYLMZADw+dTIhMg1f7IalPiHaNVDBUJqpr224P8bKvhDRXJ3nQdUc3ijAnxyiZfPY ; Received: from unknown (HELO [192.168.200.128]) (bsd@kuehlbox.de@[62.159.47.2]) (envelope-sender ) by samael.qmail-ldap.de (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 16 Jul 2007 08:59:25 -0000 Message-ID: <469B3491.2000402@kuehlbox.de> Date: Mon, 16 Jul 2007 11:04:17 +0200 From: Teufel User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: current@FreeBSD.org References: <200707131834.27131.h.schmalzbauer@omnisec.de> <4697CCEB.9080707@FreeBSD.org> <200707132155.43783.h.schmalzbauer@omnisec.de> <4698E7C4.9080001@FreeBSD.org> In-Reply-To: <4698E7C4.9080001@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: kqemu crash (page fault) with -current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2007 08:59:28 -0000 Hi Attilio, well, I am not Harry, but I have downloaded also your patch and compiled it with yesterdays CURRENT CVS, launched a portsnap fetch update and build kqemu + qemu from the ports without any changes to the default system. Loaded kqemu.ko, and started a win2k3 image with qemu -kernel-kqemu. It runs now for about 10 hours. No crashes so far. But I did not try a unpatched kernel.previously. Just wanted to let you know that here is a 7-CURRENT running from yesterday with kqemu in kernel and usermode under SMP. Any tests I should do? Greetings, Stephan Attilio Rao wrote: > > Hello Harry, > could you please download again the patch and try again? > It seems I missed a bit... > > And, please, compile again qemu any time beacause I'm not sure how > much are exposed to userland "struct thread" and "struct proc", for > this problem. > > You should firstly try the canonical case of kernel clean compilation > (so with KSE) and kqemu clean compilation (so without KSE, without the > -DKSE option). > > Let me know, > Thanks. > > Attilio > From owner-freebsd-current@FreeBSD.ORG Mon Jul 16 09:09:46 2007 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CD33216A40A for ; Mon, 16 Jul 2007 09:09:46 +0000 (UTC) (envelope-from w0lfie@clear.net.nz) Received: from smtp5.clear.net.nz (smtp5.clear.net.nz [203.97.33.68]) by mx1.freebsd.org (Postfix) with ESMTP id 993B213C471 for ; Mon, 16 Jul 2007 09:09:46 +0000 (UTC) (envelope-from w0lfie@clear.net.nz) Received: from clear.net.nz (lb2-srcnat.clear.net.nz [203.97.32.237]) by smtp5.clear.net.nz (CLEAR Net Mail) with SMTP id <0JL900CBHLG7HI10@smtp5.clear.net.nz> for current@FreeBSD.org; Mon, 16 Jul 2007 21:09:43 +1200 (NZST) Date: Mon, 16 Jul 2007 21:09:43 +1200 From: Sam Banks Sender: w0lfie@clear.net.nz To: current@FreeBSD.org Message-id: <469b35d7.197.31f0.5575@clear.net.nz> MIME-version: 1.0 X-Mailer: CLEAR Net WebMail; webmail.clear.net.nz; user: w0lfie; ip: 121.73.22.121 Content-type: multipart/mixed; boundary="-=_fep17469b35d7" Priority: normal Cc: Subject: Re: ukbd patch advice X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: w0lfie@clear.net.nz List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2007 09:09:46 -0000 This is a multi-part message in MIME format. ---=_fep17469b35d7 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit As suggested by Andrew Thompson, I have attached the patch for ukbd.c to show the changes I've made. Sam. ----- Original Message Follows ----- > Hey all, > > I have been having a problem with my particular usb > keyboard (0x03 was always being written into the first > element of ukbd_data->keycode basically). I have tracked > it down to a problem somewhere in between the uhci chipset > (same problem with other cuts of uhci chipset), the uhci > and/or ukbd drivers and the keyboard. > > A fix to the problem is to reorder members of the struct > ukbd_data. Originally, the members are ordered as > modifiers, reserved and keycode[6] (minus a bunch of > #define's). If I change this order to reserved, modifiers > and keycode[6], my keyboard starts to function as it > should (minus lighting up the LED's but that's another > email all together :)). With this reordering, it stops > other usb keyboards which function with the original code > from working. > > I'm wanting submit a patch for this fix (as other people > are experiencing the same problems) but I'm not sure how > to do this. I was thinking along the lines of the usb > quirks function but it appears outside of a function body, > you cannot have the normal if() type statements, only the > preprocessor #ifdef types. To me, having a kernel config > option for a single keyboard on a single driver seems > quite overkill. > > Does anyone have any suggestions on what I should do or > can anyone point me to some code that deals with a similar > problem? > > On a side note, is anyone able to shed any light into why > they think the above fix works? I am drawing a bit of a > blank to be honest. Is it possible that my fix is only > masking the problem? > > If you need any more info or whatever, yell out. > > Cheers, > > Sam. > _______________________________________________ > 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" ---=_fep17469b35d7 Content-Type: application/octet-stream; name="ukdb.c.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="ukdb.c.patch" LS0tIHVrYmQuYy5vcmlnCTIwMDctMDctMTYgMjA6NTk6MzQuMDAwMDAwMDAw ICsxMjAwCisrKyB1a2JkLmMJMjAwNy0wNy0xNiAyMTowMjozNy4wMDAwMDAw MDAgKzEyMDAKIC8qCiAgKiBISUQgc3BlYzogaHR0cDovL3d3dy51c2Iub3Jn L2RldmVsb3BlcnMvZGV2Y2xhc3NfZG9jcy9ISUQxXzExLnBkZgpAQCAtOTMs NiArOTMsNyBAQAogI2RlZmluZSBOS0VZQ09ERSA2CiAKIHN0cnVjdCB1a2Jk X2RhdGEgeworICAgIHVfaW50OF90ICAgIHJlc2VydmVkOwogCXVfaW50OF90 CW1vZGlmaWVyczsKICNkZWZpbmUgTU9EX0NPTlRST0xfTAkweDAxCiAjZGVm aW5lIE1PRF9DT05UUk9MX1IJMHgxMApAQCAtMTAyLDcgKzEwMyw2IEBACiAj ZGVmaW5lIE1PRF9BTFRfUgkweDQwCiAjZGVmaW5lIE1PRF9XSU5fTAkweDA4 CiAjZGVmaW5lIE1PRF9XSU5fUgkweDgwCi0JdV9pbnQ4X3QJcmVzZXJ2ZWQ7 CiAJdV9pbnQ4X3QJa2V5Y29kZVtOS0VZQ09ERV07CiB9Owo= ---=_fep17469b35d7-- From owner-freebsd-current@FreeBSD.ORG Mon Jul 16 09:20:45 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 349B016A403; Mon, 16 Jul 2007 09:20:45 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe07.swip.net [212.247.154.193]) by mx1.freebsd.org (Postfix) with ESMTP id 660C213C461; Mon, 16 Jul 2007 09:20:43 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] Received: from [194.248.135.20] (account mc467741@c2i.net HELO laptop.lan) by mailfe07.swip.net (CommuniGate Pro SMTP 5.1.10) with ESMTPA id 548555365; Mon, 16 Jul 2007 11:20:42 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org, w0lfie@clear.net.nz Date: Mon, 16 Jul 2007 11:20:45 +0200 User-Agent: KMail/1.9.5 References: <469b35d7.197.31f0.5575@clear.net.nz> In-Reply-To: <469b35d7.197.31f0.5575@clear.net.nz> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200707161120.45743.hselasky@c2i.net> Cc: current@freebsd.org, freebsd-usb@freebsd.org Subject: Re: ukbd patch advice X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Jul 2007 09:20:45 -0000 Hi, Could you try the HPS USB stack first? http://www.turbocat.net/~hselasky/usb4bsd Download the SVN version. You need FreeBSD 6.2. What processor type are you using ? It might be that the USB interrupt handler uses the wrong buffer size. If it is the same, turn on debugging: sysctl usb.ukdb.debug=15 I know that that the ukdb driver is called without Giant locked in the official USB stack, for example, which might lead to races. --HPS From owner-freebsd-current@FreeBSD.ORG Mon Jul 16 09:20:45 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 349B016A403; Mon, 16 Jul 2007 09:20:45 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe07.swip.net [212.247.154.193]) by mx1.freebsd.org (Postfix) with ESMTP id 660C213C461; Mon, 16 Jul 2007 09:20:43 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] Received: from [194.248.135.20] (account mc467741@c2i.net HELO laptop.lan) by mailfe07.swip.net (CommuniGate Pro SMTP 5.1.10) with ESMTPA id 548555365; Mon, 16 Jul 2007 11:20:42 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org, w0lfie@clear.net.nz Date: Mon, 16 Jul 2007 11:20:45 +0200 User-Agent: KMail/1.9.5 References: <469b35d7.197.31f0.5575@clear.net.nz> In-Reply-To: <469b35d7.197.31f0.5575@clear.net.nz> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200707161120.45743.hselasky@c2i.net> Cc: current@freebsd.org, freebsd-usb@freebsd.org Subject: Re: ukbd patch advice X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Jul 2007 09:20:45 -0000 Hi, Could you try the HPS USB stack first? http://www.turbocat.net/~hselasky/usb4bsd Download the SVN version. You need FreeBSD 6.2. What processor type are you using ? It might be that the USB interrupt handler uses the wrong buffer size. If it is the same, turn on debugging: sysctl usb.ukdb.debug=15 I know that that the ukdb driver is called without Giant locked in the official USB stack, for example, which might lead to races. --HPS From owner-freebsd-current@FreeBSD.ORG Mon Jul 16 09:21:51 2007 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B541B16A404; Mon, 16 Jul 2007 09:21:51 +0000 (UTC) (envelope-from keramida@FreeBSD.org) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.freebsd.org (Postfix) with ESMTP id 2C9D913C4B3; Mon, 16 Jul 2007 09:21:50 +0000 (UTC) (envelope-from keramida@FreeBSD.org) Received: from kobe.laptop (vader.bytemobile.ondsl.gr [83.235.244.135]) (authenticated bits=128) by igloo.linux.gr (8.13.8/8.13.8/Debian-3) with ESMTP id l6G9LSxS015719 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 16 Jul 2007 12:21:34 +0300 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.1/8.14.1) with ESMTP id l6G9LBgu002649; Mon, 16 Jul 2007 12:21:27 +0300 (EEST) (envelope-from keramida@FreeBSD.org) Received: (from keramida@localhost) by kobe.laptop (8.14.1/8.14.1/Submit) id l6G9LAu0002648; Mon, 16 Jul 2007 12:21:10 +0300 (EEST) (envelope-from keramida@FreeBSD.org) Date: Mon, 16 Jul 2007 12:21:10 +0300 From: Giorgos Keramidas To: Christos Zoulas Message-ID: <20070716092109.GB2568@kobe.laptop> References: <20070714005559.GB6661@kobe.laptop> <20070716030052.1B43D56407@rebar.astron.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070716030052.1B43D56407@rebar.astron.com> X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-3.923, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.48, BAYES_00 -2.60) X-Hellug-MailScanner-From: keramida@freebsd.org X-Spam-Status: No Cc: Mark Peek , tcsh-bugs@mx.gw.com, kris@FreeBSD.org, current@FreeBSD.org Subject: Re: tcsh backtick hang info X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Jul 2007 09:21:51 -0000 On 2007-07-15 23:00, Christos Zoulas wrote: > On Jul 14, 3:55am, keramida@freebsd.org (Giorgos Keramidas) wrote: > | Hi Christos, > | > | Can we persuade you to include the following local patch I keep for > | autologout detection with /dev/pts/XXX ptys in FreeBSD? > | > | %%% > | Fix pty detection logic of tcsh autologout initialization. > | > | Noticed by: kris > | > | diff --git a/contrib/tcsh/sh.c b/contrib/tcsh/sh.c > | --- a/contrib/tcsh/sh.c > | +++ b/contrib/tcsh/sh.c > | @@ -457,7 +457,7 @@ main(int argc, char **argv) > | if (*cp) { > | /* only for login shells or root and we must have a tty */ > | if ((cp2 = Strrchr(cp, (Char) '/')) != NULL) { > | - cp = cp2 + 1; > | + cp2 = cp2 + 1; > | } > | else > | cp2 = cp; > | %%% > > The code is wrong but I think that the fix is not exactly right... The > following should work: > > /* only for login shells or root and we must have a tty */ > if ((cp2 = Strrchr(cp, (Char) '/')) != NULL) { > cp2 = cp2 + 1; > } > else > cp2 = cp; > if (!(((Strncmp(cp2, STRtty, 3) == 0) && Isalpha(cp2[3])) || > Strstr(cp, Strslptssl) != NULL)) { > if (getenv("DISPLAY") == NULL) { > /* NOT on X window shells */ > setcopy(STRautologout, STRdefautologout, VAR_READWRITE); Ah! Much better indeed. I'm happy a fix is going to be in upstream tcsh now :-) > Thanks for the bug report. wonder how come nobody complained for > years! This was really brought to my notice by Kris Kennaway, so he's the one we should thank. From owner-freebsd-current@FreeBSD.ORG Mon Jul 16 09:38:15 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EAFA716A400 for ; Mon, 16 Jul 2007 09:38:15 +0000 (UTC) (envelope-from Thomas.Sparrevohn@btinternet.com) Received: from smtp812.mail.ird.yahoo.com (smtp812.mail.ird.yahoo.com [217.146.188.72]) by mx1.freebsd.org (Postfix) with SMTP id 338AF13C4AC for ; Mon, 16 Jul 2007 09:38:14 +0000 (UTC) (envelope-from Thomas.Sparrevohn@btinternet.com) Received: (qmail 75707 invoked from network); 16 Jul 2007 09:38:13 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=btinternet.com; h=Received:X-YMail-OSG:From:To:Subject:Date:User-Agent:Cc:References:In-Reply-To:MIME-Version:Content-Disposition:Content-Type:Content-Transfer-Encoding:Message-Id; b=3sf+WVqk1Y59aoRfnzUfGesk4M5IUrBPn57h+SlmYue9zR4vl7RnYJEOycBNtDttVTKb8ydiRxY3z4gyB/oCtRpsmXeNzZ7HjAWLCO0ZFrsmROSgkOiL4k6w8mLF0sZvjv2O8nLWyp9HaX1Uy8J0kKD0gDQsKEUegfEbF9hPsmE= ; Received: from unknown (HELO w2fzz0vc03.aah-go-on.com) (thomas.sparrevohn@btinternet.com@86.136.24.44 with login) by smtp812.mail.ird.yahoo.com with SMTP; 16 Jul 2007 09:38:13 -0000 X-YMail-OSG: nNn25TIVM1mCdKcEMK_CCDnw4tI2hBwhhEi0dusbHhKZ6mH3LwqDpCtih9YRDBHcRHr0eD6N8Q-- From: Thomas Sparrevohn To: "Abdullah Ibn Hamad Al-Marri" Date: Mon, 16 Jul 2007 10:38:10 +0100 User-Agent: KMail/1.9.7 References: <200707160309.l6G396le006568@gw.catspoiler.org> <200707160904.47976.Thomas.Sparrevohn@btinternet.com> <499c70c0707160111g31410e07v2b7d20963c9190d@mail.gmail.com> In-Reply-To: <499c70c0707160111g31410e07v2b7d20963c9190d@mail.gmail.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <200707161038.11140.Thomas.Sparrevohn@btinternet.com> Cc: Don Lewis , freebsd-current@freebsd.org, Ion-Mihai Tetcu Subject: Re: hang on reboot or shutdown with 7.0-CURRENT i386 on AMD X2 + GeForce 7050 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Jul 2007 09:38:16 -0000 On Monday 16 July 2007 09:11:50 Abdullah Ibn Hamad Al-Marri wrote: > > I had the same problem, when I removed ehci from my kernel the problem > went away, my mobo is ATI which is use in Acer 5102 WLMi and not > nvidia. > I just tried disabling ehci as well - and it worked - the machine rebooted and powered down just fine. So it seems that it has to do with ehci - I try and see if I can pin it down From owner-freebsd-current@FreeBSD.ORG Mon Jul 16 09:57:33 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 289D416A402; Mon, 16 Jul 2007 09:57:33 +0000 (UTC) (envelope-from snezhko@indorsoft.ru) Received: from indorsoft.ru (indor.net.tomline.ru [213.183.100.90]) by mx1.freebsd.org (Postfix) with ESMTP id 39B2713C442; Mon, 16 Jul 2007 09:57:31 +0000 (UTC) (envelope-from snezhko@indorsoft.ru) Received: from SNEZHKO by indorsoft.ru (MDaemon.PRO.v7.2.2.R) with ESMTP id md50000220658.msg; Mon, 16 Jul 2007 16:57:26 +0700 From: Victor Snezhko To: Ivan Voras References: <20070709214216.GA72912@walton.maths.tcd.ie> <20070711132202.GA95487@walton.maths.tcd.ie> <469B2787.9010302@fer.hr> Date: Mon, 16 Jul 2007 16:57:20 +0700 In-Reply-To: <469B2787.9010302@fer.hr> (Ivan Voras's message of "Mon, 16 Jul 2007 10:08:39 +0200") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.3 (windows-nt) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Processed: indor.net.tomline.ru, Mon, 16 Jul 2007 16:57:26 +0700 (not processed: spam filter disabled) X-Return-Path: snezhko@indorsoft.ru Cc: David Malone , freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: Debugging times X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Jul 2007 09:57:33 -0000 Ivan Voras writes: >> Also, this was a surprise to an unexperienced me, but I have also >> found that vfs_mount initializes RTC with the latest timestamp found >> on local file systems - this explains why kernel "worked" for Ivan on >> a hard drive. It didn't actually work, but used timestamp which was >> stored on filesystem during unmount. > > Wow - this is just astonishing - why would a file system have anything > to do with the RTC? Sorry, some sloppy wording on my part. That was system clock, not RTC. The code which makes sure that system clock is initialized to root fs timestamp is in vfs_mount.c since 1.34. Initially it was commented as "sanity check". That might make some sense, although was a surprise to me. -- WBR, Victor V. Snezhko E-mail: snezhko@indorsoft.ru From owner-freebsd-current@FreeBSD.ORG Mon Jul 16 12:11:12 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E5A0F16A405; Mon, 16 Jul 2007 12:11:12 +0000 (UTC) (envelope-from lusa@areca.com.tw) Received: from mail.areca.com.tw (60-248-88-209.HINET-IP.hinet.net [60.248.88.209]) by mx1.freebsd.org (Postfix) with ESMTP id 1F51D13C4C9; Mon, 16 Jul 2007 12:11:10 +0000 (UTC) (envelope-from lusa@areca.com.tw) Received: from lusa2nou13gr9u (unknown [192.168.0.67]) by mail.areca.com.tw (Postfix) with SMTP id 6681C653544; Mon, 16 Jul 2007 19:10:37 +0800 (CST) Message-ID: <001701c7c79a$3a82f360$4300a8c0@lusa2nou13gr9u> From: "Areca lusa" To: "erich" References: Date: Mon, 16 Jul 2007 19:12:41 +0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0014_01C7C7DD.480B52F0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailman-Approved-At: Mon, 16 Jul 2007 12:15:52 +0000 Cc: freebsd-current@freebsd.org Subject: Re: arcmsr crash X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Jul 2007 12:11:13 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0014_01C7C7DD.480B52F0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit Hi Dear ALL: I am areca test team,sorry reply delay,I try this question , run dd if=/dev/zero of=/dev/da1 bs=1024 at FreeBSD-7.0-current version, It is normal.I don't see any error,I have attach file that is freebsd messages.but I used to one CPU,because I have one.Can you use one CPU test again,please? MB:supermicro X7DB8 BIOS:05/29/07 RAID CARD:Arc 1220 F/w:1.43 create two RAID6 volume attach four HDD first volume --FreeBSD 7.0 second volume--is free space If you have any new suggestions that reply. thank you~ Best Regards, Lusa Sue Areca Technology Test Engineer Tel : 886-2-87974060 Ext. 233 Fax : 886-2-87975970 Http://www.areca.com.tw ----- Original Message ----- From: "erich" To: "(廣安科技)蘇莉åµ" Sent: Monday, July 16, 2007 4:36 PM Subject: Fw: arcmsr crash > > ----- Original Message ----- > From: "Matt Reimer" > To: "Scott Long" > Cc: "John Baldwin" ; ; > "erich" > Sent: Saturday, July 14, 2007 4:46 AM > Subject: Re: arcmsr crash > > >> On 7/13/07, Scott Long wrote: >>> John Baldwin wrote: >>> > On Tuesday 05 June 2007 05:22:38 pm Matt Reimer wrote: >>> >> Once a week or so we're seeing a panic with a -current kernel built >>> >> just before the gcc 4.2 import (maybe three weeks ago). The box has a >>> >> Supermicro X7DBE/X7DBE+ motherboard with two Xeon 5160s, 16G RAM, and >>> >> an Areca 1220 controller with eight 500G disks connected. >>> >> >>> >> Does this indicate that the arcmsr driver is at fault: >>> >> >>> >> Tracing command irq16: arcmsr0 pid 26 tid 100018 td >>> >> 0xffffff040fc5b000 >>> >> cpustop_handler() at cpustop_handler+0x35 >>> >> ipi_nmi_handler() at ipi_nmi_handler+0x2e >>> >> trap() at trap+0x365 >>> >> nmi_calltrap() at nmi_calltrap+0x8 >>> >> --- trap 0x13, rip = 0xffffffff8041ab11, rsp = 0xffffffffab59eff0, >>> >> rbp >>> >> = 0xffffffffac0a37d0 --- >>> >> siocnclose() at siocnclose+0x21 >>> >> sio_cnputc() at sio_cnputc+0x89 >>> >> cnputc() at cnputc+0x6a >>> >> putchar() at putchar+0x5f >>> >> kvprintf() at kvprintf+0xd45 >>> >> printf() at printf+0xe1 >>> >> panic() at panic+0x145 >>> >> xpt_done() at xpt_done+0x14a >>> >> arcmsr_interrupt() at arcmsr_interrupt+0x2df >>> >> ithread_loop() at ithread_loop+0x108 >>> >> fork_exit() at fork_exit+0xaa >>> >> fork_trampoline() at fork_trampoline+0xe >>> >> --- trap 0, rip = 0, rsp = 0xffffffffac0a3d30, rbp = 0 --- >>> > >>> > Looks like it has panic'd here: >>> > >>> > switch (done_ccb->ccb_h.path->periph->type) { >>> > case CAM_PERIPH_BIO: >>> > mtx_lock(&cam_bioq_lock); >>> > TAILQ_INSERT_TAIL(&cam_bioq, &done_ccb->ccb_h, >>> > sim_links.tqe); >>> > done_ccb->ccb_h.pinfo.index = CAM_DONEQ_INDEX; >>> > mtx_unlock(&cam_bioq_lock); >>> > swi_sched(cambio_ih, 0); >>> > break; >>> > default: >>> > panic("unknown periph type %d", >>> > done_ccb->ccb_h.path->periph->type); >>> > } >>> > >>> > which should seem to indicate that, yes, it is a driver bug. >>> > >>> >>> The doneq has gotten corrupted somehow. The only real way that this >>> could happen is if xpt_done() was called twice on the same ccb. Whether >>> this is a hardware bug (hardware completing the same command twice) or >>> a driver bug is unknown. I'll try to add some seatbelts to CAM to >>> detect this kind of condition. But yes, it's ultimately something in >>> the arcmsr subsystem that is at fault. >> >> Do you have any suggestions of instrumentation printfs I could add to >> zero in on what part of the driver is at fault? >> >> Matt > ------=_NextPart_000_0014_01C7C7DD.480B52F0 Content-Type: application/octet-stream; name="messages[1]" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="messages[1]" Jul 16 16:22:07 areca-1 newsyslog[521]: logfile first created Jul 16 16:22:07 areca-1 syslogd: kernel boot file is /boot/kernel/kernel Jul 16 16:22:07 areca-1 kernel: Copyright (c) 1992-2007 The FreeBSD = Project. Jul 16 16:22:07 areca-1 kernel: Copyright (c) 1979, 1980, 1983, 1986, = 1988, 1989, 1991, 1992, 1993, 1994 Jul 16 16:22:07 areca-1 kernel: The Regents of the University of = California. All rights reserved. Jul 16 16:22:07 areca-1 kernel: FreeBSD is a registered trademark of The = FreeBSD Foundation. Jul 16 16:22:07 areca-1 kernel: FreeBSD 7.0-CURRENT-200706 #0: Thu Jun = 7 21:38:42 UTC 2007 Jul 16 16:22:07 areca-1 kernel: = root@stiles.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC Jul 16 16:22:07 areca-1 kernel: WARNING: WITNESS option enabled, expect = reduced performance. Jul 16 16:22:07 areca-1 kernel: Timecounter "i8254" frequency 1193182 Hz = quality 0 Jul 16 16:22:07 areca-1 kernel: CPU: Intel(R) Xeon(R) CPU = 5150 @ 2.66GHz (2666.68-MHz K8-class CPU) Jul 16 16:22:07 areca-1 kernel: Origin =3D "GenuineIntel" Id =3D 0x6f6 = Stepping =3D 6 Jul 16 16:22:07 areca-1 kernel: = Features=3D0xbfebfbff Jul 16 16:22:07 areca-1 kernel: = Features2=3D0x4e3bd Jul 16 16:22:07 areca-1 kernel: AMD Features=3D0x20100800 Jul 16 16:22:07 areca-1 kernel: AMD Features2=3D0x1 Jul 16 16:22:07 areca-1 kernel: Cores per package: 2 Jul 16 16:22:07 areca-1 kernel: usable memory =3D 523649024 (499 MB) Jul 16 16:22:07 areca-1 kernel: avail memory =3D 503586816 (480 MB) Jul 16 16:22:07 areca-1 kernel: ACPI APIC Table: Jul 16 16:22:07 areca-1 kernel: FreeBSD/SMP: Multiprocessor System = Detected: 2 CPUs Jul 16 16:22:07 areca-1 kernel: cpu0 (BSP): APIC ID: 0 Jul 16 16:22:07 areca-1 kernel: cpu1 (AP): APIC ID: 1 Jul 16 16:22:07 areca-1 kernel: ioapic0 irqs 0-23 on = motherboard Jul 16 16:22:07 areca-1 kernel: ioapic1 irqs 24-47 on = motherboard Jul 16 16:22:07 areca-1 kernel: kbd1 at kbdmux0 Jul 16 16:22:07 areca-1 kernel: ath_hal: 0.9.20.3 (AR5210, AR5211, = AR5212, RF5111, RF5112, RF2413, RF5413) Jul 16 16:22:07 areca-1 kernel: acpi0: on motherboard Jul 16 16:22:07 areca-1 kernel: acpi0: [ITHREAD] Jul 16 16:22:07 areca-1 kernel: acpi0: Power Button (fixed) Jul 16 16:22:07 areca-1 kernel: Timecounter "ACPI-safe" frequency = 3579545 Hz quality 1000 Jul 16 16:22:07 areca-1 kernel: acpi_timer0: <24-bit timer at = 3.579545MHz> port 0x1008-0x100b on acpi0 Jul 16 16:22:07 areca-1 kernel: cpu0: on acpi0 Jul 16 16:22:07 areca-1 kernel: acpi_throttle0: on = cpu0 Jul 16 16:22:07 areca-1 kernel: cpu1: on acpi0 Jul 16 16:22:07 areca-1 kernel: acpi_throttle1: on = cpu1 Jul 16 16:22:07 areca-1 kernel: acpi_throttle1: failed to attach P_CNT Jul 16 16:22:07 areca-1 kernel: device_attach: acpi_throttle1 attach = returned 6 Jul 16 16:22:07 areca-1 kernel: pcib0: port = 0xcf8-0xcff on acpi0 Jul 16 16:22:07 areca-1 kernel: pci0: on pcib0 Jul 16 16:22:07 areca-1 kernel: pcib1: at device = 2.0 on pci0 Jul 16 16:22:07 areca-1 kernel: pci1: on pcib1 Jul 16 16:22:07 areca-1 kernel: pcib2: irq 16 at = device 0.0 on pci1 Jul 16 16:22:07 areca-1 kernel: pci2: on pcib2 Jul 16 16:22:07 areca-1 kernel: pcib3: irq 16 at = device 0.0 on pci2 Jul 16 16:22:07 areca-1 kernel: pci3: on pcib3 Jul 16 16:22:07 areca-1 kernel: pcib4: at device = 0.0 on pci3 Jul 16 16:22:07 areca-1 kernel: pci4: on pcib4 Jul 16 16:22:07 areca-1 kernel: rl0: port = 0x2000-0x20ff mem 0xd8500000-0xd85000ff irq 16 at device 1.0 on pci4 Jul 16 16:22:07 areca-1 kernel: miibus0: on rl0 Jul 16 16:22:07 areca-1 kernel: rlphy0: PHY 0 on miibus0 Jul 16 16:22:07 areca-1 kernel: rlphy0: 10baseT, 10baseT-FDX, = 100baseTX, 100baseTX-FDX, auto Jul 16 16:22:07 areca-1 kernel: rl0: Ethernet address: 00:40:f4:e9:1c:f3 Jul 16 16:22:07 areca-1 kernel: rl0: [ITHREAD] Jul 16 16:22:07 areca-1 kernel: ahd0: port 0x2800-0x28ff,0x2400-0x24ff mem 0xd8502000-0xd8503fff irq = 16 at device 2.0 on pci4 Jul 16 16:22:07 areca-1 kernel: ahd0: [ITHREAD] Jul 16 16:22:07 areca-1 kernel: aic7902: Ultra320 Wide Channel A, SCSI = Id=3D7, PCI 33 or 66Mhz, 512 SCBs Jul 16 16:22:07 areca-1 kernel: ahd1: port 0x3000-0x30ff,0x2c00-0x2cff mem 0xd8504000-0xd8505fff irq = 17 at device 2.1 on pci4 Jul 16 16:22:07 areca-1 kernel: ahd1: [ITHREAD] Jul 16 16:22:07 areca-1 kernel: aic7902: Ultra320 Wide Channel B, SCSI = Id=3D7, PCI 33 or 66Mhz, 512 SCBs Jul 16 16:22:07 areca-1 kernel: pcib5: at device = 0.2 on pci3 Jul 16 16:22:07 areca-1 kernel: pci5: on pcib5 Jul 16 16:22:07 areca-1 kernel: pcib6: irq 18 at = device 2.0 on pci2 Jul 16 16:22:07 areca-1 kernel: pci6: on pcib6 Jul 16 16:22:07 areca-1 kernel: pci6: at device 0.0 = (no driver attached) Jul 16 16:22:07 areca-1 kernel: pci6: at device 0.1 = (no driver attached) Jul 16 16:22:07 areca-1 kernel: pcib7: at device = 0.3 on pci1 Jul 16 16:22:07 areca-1 kernel: pci7: on pcib7 Jul 16 16:22:07 areca-1 kernel: pcib8: at device = 4.0 on pci0 Jul 16 16:22:07 areca-1 kernel: pci8: on pcib8 Jul 16 16:22:07 areca-1 kernel: pcib9: at device = 6.0 on pci0 Jul 16 16:22:07 areca-1 kernel: pci9: on pcib9 Jul 16 16:22:07 areca-1 kernel: pcib10: at device 0.0 = on pci9 Jul 16 16:22:07 areca-1 kernel: pci10: on pcib10 Jul 16 16:22:07 areca-1 kernel: arcmsr0: mem = 0xd8700000-0xd8700fff,0xd8000000-0xd83fffff irq 16 at device 14.0 on = pci10 Jul 16 16:22:07 areca-1 kernel: ARECA RAID ADAPTER0: Driver Version = 1.20.00.14 2007-2-05=20 Jul 16 16:22:07 areca-1 kernel: ARECA RAID ADAPTER0: FIRMWARE VERSION = V1.43 2007-4-17 =20 Jul 16 16:22:07 areca-1 kernel: arcmsr0: [ITHREAD] Jul 16 16:22:07 areca-1 kernel: pcib11: at device 0.2 = on pci9 Jul 16 16:22:07 areca-1 kernel: pci11: on pcib11 Jul 16 16:22:07 areca-1 kernel: pcib12: irq 17 at = device 28.0 on pci0 Jul 16 16:22:07 areca-1 kernel: pci12: on pcib12 Jul 16 16:22:07 areca-1 kernel: uhci0: = port 0x1800-0x181f irq 17 at device 29.0 on pci0 Jul 16 16:22:07 areca-1 kernel: uhci0: [GIANT-LOCKED] Jul 16 16:22:07 areca-1 kernel: uhci0: [ITHREAD] Jul 16 16:22:07 areca-1 kernel: usb0: on = uhci0 Jul 16 16:22:07 areca-1 kernel: usb0: USB revision 1.0 Jul 16 16:22:07 areca-1 kernel: uhub0: on usb0 Jul 16 16:22:07 areca-1 kernel: uhub0: 2 ports with 2 removable, self = powered Jul 16 16:22:07 areca-1 kernel: uhci1: = port 0x1820-0x183f irq 19 at device 29.1 on pci0 Jul 16 16:22:07 areca-1 kernel: uhci1: [GIANT-LOCKED] Jul 16 16:22:07 areca-1 kernel: uhci1: [ITHREAD] Jul 16 16:22:07 areca-1 kernel: usb1: on = uhci1 Jul 16 16:22:07 areca-1 kernel: usb1: USB revision 1.0 Jul 16 16:22:07 areca-1 kernel: uhub1: on usb1 Jul 16 16:22:07 areca-1 kernel: uhub1: 2 ports with 2 removable, self = powered Jul 16 16:22:07 areca-1 kernel: uhci2: = port 0x1840-0x185f irq 18 at device 29.2 on pci0 Jul 16 16:22:07 areca-1 kernel: uhci2: [GIANT-LOCKED] Jul 16 16:22:07 areca-1 kernel: uhci2: [ITHREAD] Jul 16 16:22:07 areca-1 kernel: usb2: on = uhci2 Jul 16 16:22:07 areca-1 kernel: usb2: USB revision 1.0 Jul 16 16:22:07 areca-1 kernel: uhub2: on usb2 Jul 16 16:22:07 areca-1 kernel: uhub2: 2 ports with 2 removable, self = powered Jul 16 16:22:07 areca-1 kernel: ehci0: mem 0xd8b00000-0xd8b003ff irq 17 at device 29.7 on pci0 Jul 16 16:22:07 areca-1 kernel: ehci0: [GIANT-LOCKED] Jul 16 16:22:07 areca-1 kernel: ehci0: [ITHREAD] Jul 16 16:22:07 areca-1 kernel: usb3: EHCI version 1.0 Jul 16 16:22:07 areca-1 kernel: usb3: companion controllers, 2 ports = each: usb0 usb1 usb2 Jul 16 16:22:07 areca-1 kernel: usb3: on ehci0 Jul 16 16:22:07 areca-1 kernel: usb3: USB revision 2.0 Jul 16 16:22:07 areca-1 kernel: uhub3: on usb3 Jul 16 16:22:07 areca-1 kernel: uhub3: 6 ports with 6 removable, self = powered Jul 16 16:22:07 areca-1 kernel: pcib13: at device = 30.0 on pci0 Jul 16 16:22:07 areca-1 kernel: pci13: on pcib13 Jul 16 16:22:07 areca-1 kernel: vgapci0: port = 0x5000-0x50ff mem 0xd0000000-0xd7ffffff,0xd8800000-0xd880ffff irq 18 at = device 1.0 on pci13 Jul 16 16:22:07 areca-1 kernel: isab0: at device 31.0 = on pci0 Jul 16 16:22:07 areca-1 kernel: isa0: on isab0 Jul 16 16:22:07 areca-1 kernel: atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1860-0x186f at = device 31.1 on pci0 Jul 16 16:22:07 areca-1 kernel: ata0: on atapci0 Jul 16 16:22:07 areca-1 kernel: ata0: [ITHREAD] Jul 16 16:22:07 areca-1 kernel: ata1: on atapci0 Jul 16 16:22:07 areca-1 kernel: ata1: [ITHREAD] Jul 16 16:22:07 areca-1 kernel: pci0: at device 31.3 = (no driver attached) Jul 16 16:22:07 areca-1 kernel: acpi_button0: on acpi0 Jul 16 16:22:07 areca-1 kernel: atkbdc0: = port 0x60,0x64 irq 1 on acpi0 Jul 16 16:22:07 areca-1 kernel: atkbd0: irq 1 on atkbdc0 Jul 16 16:22:07 areca-1 kernel: kbd0 at atkbd0 Jul 16 16:22:07 areca-1 kernel: atkbd0: [GIANT-LOCKED] Jul 16 16:22:07 areca-1 kernel: atkbd0: [ITHREAD] Jul 16 16:22:07 areca-1 kernel: psm0: irq 12 on atkbdc0 Jul 16 16:22:07 areca-1 kernel: psm0: [GIANT-LOCKED] Jul 16 16:22:07 areca-1 kernel: psm0: [ITHREAD] Jul 16 16:22:07 areca-1 kernel: psm0: model IntelliMouse Explorer, = device ID 4 Jul 16 16:22:07 areca-1 kernel: sio0: configured irq 4 not in bitmap of = probed irqs 0 Jul 16 16:22:07 areca-1 kernel: sio0: port may not be enabled Jul 16 16:22:07 areca-1 kernel: sio0: configured irq 4 not in bitmap of = probed irqs 0 Jul 16 16:22:07 areca-1 kernel: sio0: port may not be enabled Jul 16 16:22:07 areca-1 kernel: sio0: <16550A-compatible COM port> port = 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 Jul 16 16:22:07 areca-1 kernel: sio0: type 16550A Jul 16 16:22:07 areca-1 kernel: sio0: [FILTER] Jul 16 16:22:07 areca-1 kernel: sio1: configured irq 3 not in bitmap of = probed irqs 0 Jul 16 16:22:07 areca-1 kernel: sio1: port may not be enabled Jul 16 16:22:07 areca-1 kernel: sio1: configured irq 3 not in bitmap of = probed irqs 0 Jul 16 16:22:07 areca-1 kernel: sio1: port may not be enabled Jul 16 16:22:07 areca-1 kernel: sio1: <16550A-compatible COM port> port = 0x2f8-0x2ff irq 3 on acpi0 Jul 16 16:22:07 areca-1 kernel: sio1: type 16550A Jul 16 16:22:07 areca-1 kernel: sio1: [FILTER] Jul 16 16:22:07 areca-1 kernel: fdc0: port = 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 Jul 16 16:22:07 areca-1 kernel: fdc0: [FILTER] Jul 16 16:22:07 areca-1 kernel: ppc0: port = 0x378-0x37f,0x778-0x77f irq 7 drq 3 on acpi0 Jul 16 16:22:07 areca-1 kernel: ppc0: SMC-like chipset = (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode Jul 16 16:22:07 areca-1 kernel: ppc0: FIFO with 16/16/9 bytes threshold Jul 16 16:22:07 areca-1 kernel: ppbus0: on ppc0 Jul 16 16:22:07 areca-1 kernel: plip0: on = ppbus0 Jul 16 16:22:07 areca-1 kernel: lpt0: on ppbus0 Jul 16 16:22:07 areca-1 kernel: lpt0: Interrupt-driven port Jul 16 16:22:07 areca-1 kernel: ppi0: on ppbus0 Jul 16 16:22:07 areca-1 kernel: ppc0: [GIANT-LOCKED] Jul 16 16:22:07 areca-1 kernel: ppc0: [ITHREAD] Jul 16 16:22:07 areca-1 kernel: orm0: at iomem = 0xc0000-0xcafff,0xcb000-0xcbfff on isa0 Jul 16 16:22:07 areca-1 kernel: sc0: at flags 0x100 on = isa0 Jul 16 16:22:07 areca-1 kernel: sc0: VGA <16 virtual consoles, = flags=3D0x300> Jul 16 16:22:07 areca-1 kernel: vga0: at port = 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Jul 16 16:22:07 areca-1 kernel: Timecounters tick every 1.000 msec Jul 16 16:22:07 areca-1 kernel: Waiting 5 seconds for SCSI devices to = settle Jul 16 16:22:07 areca-1 kernel: acd0: CDROM at = ata0-slave UDMA33 Jul 16 16:22:07 areca-1 kernel: da0 at arcmsr0 bus 0 target 0 lun 0 Jul 16 16:22:07 areca-1 kernel: da0: Fixed = Direct Access SCSI-5 device=20 Jul 16 16:22:07 areca-1 kernel: da0: 166.666MB/s transfers (83.333MHz = DT, offset 32, 16bit) Jul 16 16:22:07 areca-1 kernel: da0: 19073MB (39061504 512 byte sectors: = 255H 63S/T 2431C) Jul 16 16:22:07 areca-1 kernel: da1 at arcmsr0 bus 0 target 0 lun 1 Jul 16 16:22:07 areca-1 kernel: da1: Fixed = Direct Access SCSI-5 device=20 Jul 16 16:22:07 areca-1 kernel: da1: 166.666MB/s transfers (83.333MHz = DT, offset 32, 16bit) Jul 16 16:22:07 areca-1 kernel: da1: 23841MB (48827392 512 byte sectors: = 255H 63S/T 3039C) Jul 16 16:22:07 areca-1 kernel: SMP: AP CPU #1 Launched! Jul 16 16:22:07 areca-1 kernel: Trying to mount root from = ufs:/dev/da0s1a Jul 16 16:22:07 areca-1 savecore: no dumps found Jul 16 16:22:17 areca-1 login: ROOT LOGIN (root) ON ttyv0 Jul 16 16:31:57 areca-1 kernel: pid 729 (dd), uid 0 inumber 71 on /: = filesystem full Jul 16 16:32:58 areca-1 login: ROOT LOGIN (root) ON ttyv1 Jul 16 16:32:59 areca-1 kernel: pid 732 (dd), uid 0 inumber 71 on /: = filesystem full Jul 16 16:58:34 areca-1 reboot: rebooted by root Jul 16 16:58:34 areca-1 syslogd: exiting on signal 15 Jul 16 17:00:34 areca-1 syslogd: kernel boot file is /boot/kernel/kernel Jul 16 17:00:34 areca-1 kernel: Copyright (c) 1992-2007 The FreeBSD = Project. Jul 16 17:00:34 areca-1 kernel: Copyright (c) 1979, 1980, 1983, 1986, = 1988, 1989, 1991, 1992, 1993, 1994 Jul 16 17:00:34 areca-1 kernel: The Regents of the University of = California. All rights reserved. Jul 16 17:00:34 areca-1 kernel: FreeBSD is a registered trademark of The = FreeBSD Foundation. Jul 16 17:00:34 areca-1 kernel: FreeBSD 7.0-CURRENT-200706 #0: Thu Jun = 7 21:38:42 UTC 2007 Jul 16 17:00:34 areca-1 kernel: = root@stiles.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC Jul 16 17:00:34 areca-1 kernel: WARNING: WITNESS option enabled, expect = reduced performance. Jul 16 17:00:34 areca-1 kernel: Timecounter "i8254" frequency 1193182 Hz = quality 0 Jul 16 17:00:34 areca-1 kernel: CPU: Intel(R) Xeon(R) CPU = 5150 @ 2.66GHz (2666.68-MHz K8-class CPU) Jul 16 17:00:34 areca-1 kernel: Origin =3D "GenuineIntel" Id =3D 0x6f6 = Stepping =3D 6 Jul 16 17:00:34 areca-1 kernel: = Features=3D0xbfebfbff Jul 16 17:00:34 areca-1 kernel: = Features2=3D0x4e3bd Jul 16 17:00:34 areca-1 kernel: AMD Features=3D0x20100800 Jul 16 17:00:34 areca-1 kernel: AMD Features2=3D0x1 Jul 16 17:00:34 areca-1 kernel: Cores per package: 2 Jul 16 17:00:34 areca-1 kernel: usable memory =3D 523649024 (499 MB) Jul 16 17:00:34 areca-1 kernel: avail memory =3D 503586816 (480 MB) Jul 16 17:00:34 areca-1 kernel: ACPI APIC Table: Jul 16 17:00:34 areca-1 kernel: FreeBSD/SMP: Multiprocessor System = Detected: 2 CPUs Jul 16 17:00:34 areca-1 kernel: cpu0 (BSP): APIC ID: 0 Jul 16 17:00:34 areca-1 kernel: cpu1 (AP): APIC ID: 1 Jul 16 17:00:34 areca-1 kernel: ioapic0 irqs 0-23 on = motherboard Jul 16 17:00:34 areca-1 kernel: ioapic1 irqs 24-47 on = motherboard Jul 16 17:00:34 areca-1 kernel: kbd1 at kbdmux0 Jul 16 17:00:34 areca-1 kernel: ath_hal: 0.9.20.3 (AR5210, AR5211, = AR5212, RF5111, RF5112, RF2413, RF5413) Jul 16 17:00:34 areca-1 kernel: acpi0: on motherboard Jul 16 17:00:34 areca-1 kernel: acpi0: [ITHREAD] Jul 16 17:00:34 areca-1 kernel: acpi0: Power Button (fixed) Jul 16 17:00:34 areca-1 kernel: Timecounter "ACPI-safe" frequency = 3579545 Hz quality 1000 Jul 16 17:00:34 areca-1 kernel: acpi_timer0: <24-bit timer at = 3.579545MHz> port 0x1008-0x100b on acpi0 Jul 16 17:00:34 areca-1 kernel: cpu0: on acpi0 Jul 16 17:00:34 areca-1 kernel: acpi_throttle0: on = cpu0 Jul 16 17:00:34 areca-1 kernel: cpu1: on acpi0 Jul 16 17:00:34 areca-1 kernel: acpi_throttle1: on = cpu1 Jul 16 17:00:34 areca-1 kernel: acpi_throttle1: failed to attach P_CNT Jul 16 17:00:34 areca-1 kernel: device_attach: acpi_throttle1 attach = returned 6 Jul 16 17:00:34 areca-1 kernel: pcib0: port = 0xcf8-0xcff on acpi0 Jul 16 17:00:34 areca-1 kernel: pci0: on pcib0 Jul 16 17:00:34 areca-1 kernel: pcib1: at device = 2.0 on pci0 Jul 16 17:00:34 areca-1 kernel: pci1: on pcib1 Jul 16 17:00:34 areca-1 kernel: pcib2: irq 16 at = device 0.0 on pci1 Jul 16 17:00:34 areca-1 kernel: pci2: on pcib2 Jul 16 17:00:34 areca-1 kernel: pcib3: irq 16 at = device 0.0 on pci2 Jul 16 17:00:34 areca-1 kernel: pci3: on pcib3 Jul 16 17:00:34 areca-1 kernel: pcib4: at device = 0.0 on pci3 Jul 16 17:00:34 areca-1 kernel: pci4: on pcib4 Jul 16 17:00:34 areca-1 kernel: rl0: port = 0x2000-0x20ff mem 0xd8500000-0xd85000ff irq 16 at device 1.0 on pci4 Jul 16 17:00:34 areca-1 kernel: miibus0: on rl0 Jul 16 17:00:34 areca-1 kernel: rlphy0: PHY 0 on miibus0 Jul 16 17:00:34 areca-1 kernel: rlphy0: 10baseT, 10baseT-FDX, = 100baseTX, 100baseTX-FDX, auto Jul 16 17:00:34 areca-1 kernel: rl0: Ethernet address: 00:40:f4:e9:1c:f3 Jul 16 17:00:34 areca-1 kernel: rl0: [ITHREAD] Jul 16 17:00:34 areca-1 kernel: ahd0: port 0x2800-0x28ff,0x2400-0x24ff mem 0xd8502000-0xd8503fff irq = 16 at device 2.0 on pci4 Jul 16 17:00:34 areca-1 kernel: ahd0: [ITHREAD] Jul 16 17:00:34 areca-1 kernel: aic7902: Ultra320 Wide Channel A, SCSI = Id=3D7, PCI 33 or 66Mhz, 512 SCBs Jul 16 17:00:34 areca-1 kernel: ahd1: port 0x3000-0x30ff,0x2c00-0x2cff mem 0xd8504000-0xd8505fff irq = 17 at device 2.1 on pci4 Jul 16 17:00:34 areca-1 kernel: ahd1: [ITHREAD] Jul 16 17:00:34 areca-1 kernel: aic7902: Ultra320 Wide Channel B, SCSI = Id=3D7, PCI 33 or 66Mhz, 512 SCBs Jul 16 17:00:34 areca-1 kernel: pcib5: at device = 0.2 on pci3 Jul 16 17:00:34 areca-1 kernel: pci5: on pcib5 Jul 16 17:00:34 areca-1 kernel: pcib6: irq 18 at = device 2.0 on pci2 Jul 16 17:00:34 areca-1 kernel: pci6: on pcib6 Jul 16 17:00:34 areca-1 kernel: pci6: at device 0.0 = (no driver attached) Jul 16 17:00:34 areca-1 kernel: pci6: at device 0.1 = (no driver attached) Jul 16 17:00:34 areca-1 kernel: pcib7: at device = 0.3 on pci1 Jul 16 17:00:34 areca-1 kernel: pci7: on pcib7 Jul 16 17:00:34 areca-1 kernel: pcib8: at device = 4.0 on pci0 Jul 16 17:00:34 areca-1 kernel: pci8: on pcib8 Jul 16 17:00:34 areca-1 kernel: pcib9: at device = 6.0 on pci0 Jul 16 17:00:34 areca-1 kernel: pci9: on pcib9 Jul 16 17:00:34 areca-1 kernel: pcib10: at device 0.0 = on pci9 Jul 16 17:00:34 areca-1 kernel: pci10: on pcib10 Jul 16 17:00:34 areca-1 kernel: arcmsr0: mem = 0xd8700000-0xd8700fff,0xd8000000-0xd83fffff irq 16 at device 14.0 on = pci10 Jul 16 17:00:34 areca-1 kernel: ARECA RAID ADAPTER0: Driver Version = 1.20.00.14 2007-2-05=20 Jul 16 17:00:34 areca-1 kernel: ARECA RAID ADAPTER0: FIRMWARE VERSION = V1.43 2007-4-17 =20 Jul 16 17:00:34 areca-1 kernel: arcmsr0: [ITHREAD] Jul 16 17:00:34 areca-1 kernel: pcib11: at device 0.2 = on pci9 Jul 16 17:00:34 areca-1 kernel: pci11: on pcib11 Jul 16 17:00:34 areca-1 kernel: pcib12: irq 17 at = device 28.0 on pci0 Jul 16 17:00:34 areca-1 kernel: pci12: on pcib12 Jul 16 17:00:34 areca-1 kernel: uhci0: = port 0x1800-0x181f irq 17 at device 29.0 on pci0 Jul 16 17:00:34 areca-1 kernel: uhci0: [GIANT-LOCKED] Jul 16 17:00:34 areca-1 kernel: uhci0: [ITHREAD] Jul 16 17:00:34 areca-1 kernel: usb0: on = uhci0 Jul 16 17:00:34 areca-1 kernel: usb0: USB revision 1.0 Jul 16 17:00:34 areca-1 kernel: uhub0: on usb0 Jul 16 17:00:34 areca-1 kernel: uhub0: 2 ports with 2 removable, self = powered Jul 16 17:00:34 areca-1 kernel: uhci1: = port 0x1820-0x183f irq 19 at device 29.1 on pci0 Jul 16 17:00:34 areca-1 kernel: uhci1: [GIANT-LOCKED] Jul 16 17:00:34 areca-1 kernel: uhci1: [ITHREAD] Jul 16 17:00:34 areca-1 kernel: usb1: on = uhci1 Jul 16 17:00:34 areca-1 kernel: usb1: USB revision 1.0 Jul 16 17:00:34 areca-1 kernel: uhub1: on usb1 Jul 16 17:00:34 areca-1 kernel: uhub1: 2 ports with 2 removable, self = powered Jul 16 17:00:34 areca-1 kernel: uhci2: = port 0x1840-0x185f irq 18 at device 29.2 on pci0 Jul 16 17:00:34 areca-1 kernel: uhci2: [GIANT-LOCKED] Jul 16 17:00:34 areca-1 kernel: uhci2: [ITHREAD] Jul 16 17:00:34 areca-1 kernel: usb2: on = uhci2 Jul 16 17:00:34 areca-1 kernel: usb2: USB revision 1.0 Jul 16 17:00:34 areca-1 kernel: uhub2: on usb2 Jul 16 17:00:34 areca-1 kernel: uhub2: 2 ports with 2 removable, self = powered Jul 16 17:00:34 areca-1 kernel: ehci0: mem 0xd8b00000-0xd8b003ff irq 17 at device 29.7 on pci0 Jul 16 17:00:34 areca-1 kernel: ehci0: [GIANT-LOCKED] Jul 16 17:00:34 areca-1 kernel: ehci0: [ITHREAD] Jul 16 17:00:34 areca-1 kernel: usb3: EHCI version 1.0 Jul 16 17:00:34 areca-1 kernel: usb3: companion controllers, 2 ports = each: usb0 usb1 usb2 Jul 16 17:00:34 areca-1 kernel: usb3: on ehci0 Jul 16 17:00:34 areca-1 kernel: usb3: USB revision 2.0 Jul 16 17:00:34 areca-1 kernel: uhub3: on usb3 Jul 16 17:00:34 areca-1 kernel: uhub3: 6 ports with 6 removable, self = powered Jul 16 17:00:34 areca-1 kernel: pcib13: at device = 30.0 on pci0 Jul 16 17:00:34 areca-1 kernel: pci13: on pcib13 Jul 16 17:00:34 areca-1 kernel: vgapci0: port = 0x5000-0x50ff mem 0xd0000000-0xd7ffffff,0xd8800000-0xd880ffff irq 18 at = device 1.0 on pci13 Jul 16 17:00:34 areca-1 kernel: isab0: at device 31.0 = on pci0 Jul 16 17:00:34 areca-1 kernel: isa0: on isab0 Jul 16 17:00:34 areca-1 kernel: atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1860-0x186f at = device 31.1 on pci0 Jul 16 17:00:34 areca-1 kernel: ata0: on atapci0 Jul 16 17:00:34 areca-1 kernel: ata0: [ITHREAD] Jul 16 17:00:34 areca-1 kernel: ata1: on atapci0 Jul 16 17:00:34 areca-1 kernel: ata1: [ITHREAD] Jul 16 17:00:34 areca-1 kernel: pci0: at device 31.3 = (no driver attached) Jul 16 17:00:34 areca-1 kernel: acpi_button0: on acpi0 Jul 16 17:00:34 areca-1 kernel: atkbdc0: = port 0x60,0x64 irq 1 on acpi0 Jul 16 17:00:34 areca-1 kernel: atkbd0: irq 1 on atkbdc0 Jul 16 17:00:34 areca-1 kernel: kbd0 at atkbd0 Jul 16 17:00:34 areca-1 kernel: atkbd0: [GIANT-LOCKED] Jul 16 17:00:34 areca-1 kernel: atkbd0: [ITHREAD] Jul 16 17:00:34 areca-1 kernel: psm0: irq 12 on atkbdc0 Jul 16 17:00:34 areca-1 kernel: psm0: [GIANT-LOCKED] Jul 16 17:00:34 areca-1 kernel: psm0: [ITHREAD] Jul 16 17:00:34 areca-1 kernel: psm0: model IntelliMouse Explorer, = device ID 4 Jul 16 17:00:34 areca-1 kernel: sio0: configured irq 4 not in bitmap of = probed irqs 0 Jul 16 17:00:34 areca-1 kernel: sio0: port may not be enabled Jul 16 17:00:34 areca-1 kernel: sio0: configured irq 4 not in bitmap of = probed irqs 0 Jul 16 17:00:34 areca-1 kernel: sio0: port may not be enabled Jul 16 17:00:34 areca-1 kernel: sio0: <16550A-compatible COM port> port = 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 Jul 16 17:00:34 areca-1 kernel: sio0: type 16550A Jul 16 17:00:34 areca-1 kernel: sio0: [FILTER] Jul 16 17:00:34 areca-1 kernel: sio1: configured irq 3 not in bitmap of = probed irqs 0 Jul 16 17:00:34 areca-1 kernel: sio1: port may not be enabled Jul 16 17:00:34 areca-1 kernel: sio1: configured irq 3 not in bitmap of = probed irqs 0 Jul 16 17:00:34 areca-1 kernel: sio1: port may not be enabled Jul 16 17:00:34 areca-1 kernel: sio1: <16550A-compatible COM port> port = 0x2f8-0x2ff irq 3 on acpi0 Jul 16 17:00:34 areca-1 kernel: sio1: type 16550A Jul 16 17:00:34 areca-1 kernel: sio1: [FILTER] Jul 16 17:00:34 areca-1 kernel: fdc0: port = 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 Jul 16 17:00:34 areca-1 kernel: fdc0: [FILTER] Jul 16 17:00:34 areca-1 kernel: ppc0: port = 0x378-0x37f,0x778-0x77f irq 7 drq 3 on acpi0 Jul 16 17:00:34 areca-1 kernel: ppc0: SMC-like chipset = (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode Jul 16 17:00:34 areca-1 kernel: ppc0: FIFO with 16/16/9 bytes threshold Jul 16 17:00:34 areca-1 kernel: ppbus0: on ppc0 Jul 16 17:00:34 areca-1 kernel: plip0: on = ppbus0 Jul 16 17:00:34 areca-1 kernel: lpt0: on ppbus0 Jul 16 17:00:34 areca-1 kernel: lpt0: Interrupt-driven port Jul 16 17:00:34 areca-1 kernel: ppi0: on ppbus0 Jul 16 17:00:34 areca-1 kernel: ppc0: [GIANT-LOCKED] Jul 16 17:00:34 areca-1 kernel: ppc0: [ITHREAD] Jul 16 17:00:34 areca-1 kernel: orm0: at iomem = 0xc0000-0xcafff,0xcb000-0xcbfff on isa0 Jul 16 17:00:34 areca-1 kernel: sc0: at flags 0x100 on = isa0 Jul 16 17:00:34 areca-1 kernel: sc0: VGA <16 virtual consoles, = flags=3D0x300> Jul 16 17:00:34 areca-1 kernel: vga0: at port = 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Jul 16 17:00:34 areca-1 kernel: Timecounters tick every 1.000 msec Jul 16 17:00:34 areca-1 kernel: Waiting 5 seconds for SCSI devices to = settle Jul 16 17:00:34 areca-1 kernel: acd0: CDROM at = ata0-slave UDMA33 Jul 16 17:00:34 areca-1 kernel: da0 at arcmsr0 bus 0 target 0 lun 0 Jul 16 17:00:34 areca-1 kernel: da0: Fixed = Direct Access SCSI-5 device=20 Jul 16 17:00:34 areca-1 kernel: da0: 166.666MB/s transfers (83.333MHz = DT, offset 32, 16bit) Jul 16 17:00:34 areca-1 kernel: da0: 19073MB (39061504 512 byte sectors: = 255H 63S/T 2431C) Jul 16 17:00:34 areca-1 kernel: da1 at arcmsr0 bus 0 target 0 lun 1 Jul 16 17:00:34 areca-1 kernel: da1: Fixed = Direct Access SCSI-5 device=20 Jul 16 17:00:34 areca-1 kernel: da1: 166.666MB/s transfers (83.333MHz = DT, offset 32, 16bit) Jul 16 17:00:34 areca-1 kernel: da1: 23841MB (48827392 512 byte sectors: = 255H 63S/T 3039C) Jul 16 17:00:34 areca-1 kernel: SMP: AP CPU #1 Launched! Jul 16 17:00:34 areca-1 kernel: Trying to mount root from = ufs:/dev/da0s1a Jul 16 17:00:34 areca-1 savecore: no dumps found Jul 16 17:00:43 areca-1 login: ROOT LOGIN (root) ON ttyv0 Jul 16 17:06:42 areca-1 reboot: rebooted by root Jul 16 17:06:42 areca-1 syslogd: exiting on signal 15 Jul 16 17:08:36 areca-1 syslogd: kernel boot file is /boot/kernel/kernel Jul 16 17:08:36 areca-1 kernel: Copyright (c) 1992-2007 The FreeBSD = Project. Jul 16 17:08:36 areca-1 kernel: Copyright (c) 1979, 1980, 1983, 1986, = 1988, 1989, 1991, 1992, 1993, 1994 Jul 16 17:08:36 areca-1 kernel: The Regents of the University of = California. All rights reserved. Jul 16 17:08:36 areca-1 kernel: FreeBSD is a registered trademark of The = FreeBSD Foundation. Jul 16 17:08:36 areca-1 kernel: FreeBSD 7.0-CURRENT-200706 #0: Thu Jun = 7 21:38:42 UTC 2007 Jul 16 17:08:36 areca-1 kernel: = root@stiles.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC Jul 16 17:08:36 areca-1 kernel: WARNING: WITNESS option enabled, expect = reduced performance. Jul 16 17:08:36 areca-1 kernel: Timecounter "i8254" frequency 1193182 Hz = quality 0 Jul 16 17:08:36 areca-1 kernel: CPU: Intel(R) Xeon(R) CPU = 5150 @ 2.66GHz (2666.68-MHz K8-class CPU) Jul 16 17:08:36 areca-1 kernel: Origin =3D "GenuineIntel" Id =3D 0x6f6 = Stepping =3D 6 Jul 16 17:08:36 areca-1 kernel: = Features=3D0xbfebfbff Jul 16 17:08:36 areca-1 kernel: = Features2=3D0x4e3bd Jul 16 17:08:36 areca-1 kernel: AMD Features=3D0x20100800 Jul 16 17:08:36 areca-1 kernel: AMD Features2=3D0x1 Jul 16 17:08:36 areca-1 kernel: Cores per package: 2 Jul 16 17:08:36 areca-1 kernel: usable memory =3D 523649024 (499 MB) Jul 16 17:08:36 areca-1 kernel: avail memory =3D 503586816 (480 MB) Jul 16 17:08:36 areca-1 kernel: ACPI APIC Table: Jul 16 17:08:36 areca-1 kernel: FreeBSD/SMP: Multiprocessor System = Detected: 2 CPUs Jul 16 17:08:36 areca-1 kernel: cpu0 (BSP): APIC ID: 0 Jul 16 17:08:36 areca-1 kernel: cpu1 (AP): APIC ID: 1 Jul 16 17:08:36 areca-1 kernel: ioapic0 irqs 0-23 on = motherboard Jul 16 17:08:36 areca-1 kernel: ioapic1 irqs 24-47 on = motherboard Jul 16 17:08:36 areca-1 kernel: kbd1 at kbdmux0 Jul 16 17:08:36 areca-1 kernel: ath_hal: 0.9.20.3 (AR5210, AR5211, = AR5212, RF5111, RF5112, RF2413, RF5413) Jul 16 17:08:36 areca-1 kernel: acpi0: on motherboard Jul 16 17:08:36 areca-1 kernel: acpi0: [ITHREAD] Jul 16 17:08:36 areca-1 kernel: acpi0: Power Button (fixed) Jul 16 17:08:36 areca-1 kernel: Timecounter "ACPI-safe" frequency = 3579545 Hz quality 1000 Jul 16 17:08:36 areca-1 kernel: acpi_timer0: <24-bit timer at = 3.579545MHz> port 0x1008-0x100b on acpi0 Jul 16 17:08:36 areca-1 kernel: cpu0: on acpi0 Jul 16 17:08:36 areca-1 kernel: acpi_throttle0: on = cpu0 Jul 16 17:08:36 areca-1 kernel: cpu1: on acpi0 Jul 16 17:08:36 areca-1 kernel: acpi_throttle1: on = cpu1 Jul 16 17:08:36 areca-1 kernel: acpi_throttle1: failed to attach P_CNT Jul 16 17:08:36 areca-1 kernel: device_attach: acpi_throttle1 attach = returned 6 Jul 16 17:08:36 areca-1 kernel: pcib0: port = 0xcf8-0xcff on acpi0 Jul 16 17:08:36 areca-1 kernel: pci0: on pcib0 Jul 16 17:08:36 areca-1 kernel: pcib1: at device = 2.0 on pci0 Jul 16 17:08:36 areca-1 kernel: pci1: on pcib1 Jul 16 17:08:36 areca-1 kernel: pcib2: irq 16 at = device 0.0 on pci1 Jul 16 17:08:36 areca-1 kernel: pci2: on pcib2 Jul 16 17:08:36 areca-1 kernel: pcib3: irq 16 at = device 0.0 on pci2 Jul 16 17:08:36 areca-1 kernel: pci3: on pcib3 Jul 16 17:08:36 areca-1 kernel: pcib4: at device = 0.0 on pci3 Jul 16 17:08:36 areca-1 kernel: pci4: on pcib4 Jul 16 17:08:36 areca-1 kernel: rl0: port = 0x2000-0x20ff mem 0xd8500000-0xd85000ff irq 16 at device 1.0 on pci4 Jul 16 17:08:36 areca-1 kernel: miibus0: on rl0 Jul 16 17:08:36 areca-1 kernel: rlphy0: PHY 0 on miibus0 Jul 16 17:08:36 areca-1 kernel: rlphy0: 10baseT, 10baseT-FDX, = 100baseTX, 100baseTX-FDX, auto Jul 16 17:08:36 areca-1 kernel: rl0: Ethernet address: 00:40:f4:e9:1c:f3 Jul 16 17:08:36 areca-1 kernel: rl0: [ITHREAD] Jul 16 17:08:36 areca-1 kernel: ahd0: port 0x2800-0x28ff,0x2400-0x24ff mem 0xd8502000-0xd8503fff irq = 16 at device 2.0 on pci4 Jul 16 17:08:36 areca-1 kernel: ahd0: [ITHREAD] Jul 16 17:08:36 areca-1 kernel: aic7902: Ultra320 Wide Channel A, SCSI = Id=3D7, PCI 33 or 66Mhz, 512 SCBs Jul 16 17:08:36 areca-1 kernel: ahd1: port 0x3000-0x30ff,0x2c00-0x2cff mem 0xd8504000-0xd8505fff irq = 17 at device 2.1 on pci4 Jul 16 17:08:36 areca-1 kernel: ahd1: [ITHREAD] Jul 16 17:08:36 areca-1 kernel: aic7902: Ultra320 Wide Channel B, SCSI = Id=3D7, PCI 33 or 66Mhz, 512 SCBs Jul 16 17:08:36 areca-1 kernel: pcib5: at device = 0.2 on pci3 Jul 16 17:08:36 areca-1 kernel: pci5: on pcib5 Jul 16 17:08:36 areca-1 kernel: pcib6: irq 18 at = device 2.0 on pci2 Jul 16 17:08:36 areca-1 kernel: pci6: on pcib6 Jul 16 17:08:36 areca-1 kernel: pci6: at device 0.0 = (no driver attached) Jul 16 17:08:36 areca-1 kernel: pci6: at device 0.1 = (no driver attached) Jul 16 17:08:36 areca-1 kernel: pcib7: at device = 0.3 on pci1 Jul 16 17:08:36 areca-1 kernel: pci7: on pcib7 Jul 16 17:08:36 areca-1 kernel: pcib8: at device = 4.0 on pci0 Jul 16 17:08:36 areca-1 kernel: pci8: on pcib8 Jul 16 17:08:36 areca-1 kernel: pcib9: at device = 6.0 on pci0 Jul 16 17:08:36 areca-1 kernel: pci9: on pcib9 Jul 16 17:08:36 areca-1 kernel: pcib10: at device 0.0 = on pci9 Jul 16 17:08:36 areca-1 kernel: pci10: on pcib10 Jul 16 17:08:36 areca-1 kernel: arcmsr0: mem = 0xd8700000-0xd8700fff,0xd8000000-0xd83fffff irq 16 at device 14.0 on = pci10 Jul 16 17:08:36 areca-1 kernel: ARECA RAID ADAPTER0: Driver Version = 1.20.00.14 2007-2-05=20 Jul 16 17:08:36 areca-1 kernel: ARECA RAID ADAPTER0: FIRMWARE VERSION = V1.43 2007-4-17 =20 Jul 16 17:08:36 areca-1 kernel: arcmsr0: [ITHREAD] Jul 16 17:08:36 areca-1 kernel: pcib11: at device 0.2 = on pci9 Jul 16 17:08:36 areca-1 kernel: pci11: on pcib11 Jul 16 17:08:36 areca-1 kernel: pcib12: irq 17 at = device 28.0 on pci0 Jul 16 17:08:36 areca-1 kernel: pci12: on pcib12 Jul 16 17:08:36 areca-1 kernel: uhci0: = port 0x1800-0x181f irq 17 at device 29.0 on pci0 Jul 16 17:08:36 areca-1 kernel: uhci0: [GIANT-LOCKED] Jul 16 17:08:36 areca-1 kernel: uhci0: [ITHREAD] Jul 16 17:08:36 areca-1 kernel: usb0: on = uhci0 Jul 16 17:08:36 areca-1 kernel: usb0: USB revision 1.0 Jul 16 17:08:36 areca-1 kernel: uhub0: on usb0 Jul 16 17:08:36 areca-1 kernel: uhub0: 2 ports with 2 removable, self = powered Jul 16 17:08:36 areca-1 kernel: uhci1: = port 0x1820-0x183f irq 19 at device 29.1 on pci0 Jul 16 17:08:36 areca-1 kernel: uhci1: [GIANT-LOCKED] Jul 16 17:08:36 areca-1 kernel: uhci1: [ITHREAD] Jul 16 17:08:36 areca-1 kernel: usb1: on = uhci1 Jul 16 17:08:36 areca-1 kernel: usb1: USB revision 1.0 Jul 16 17:08:36 areca-1 kernel: uhub1: on usb1 Jul 16 17:08:36 areca-1 kernel: uhub1: 2 ports with 2 removable, self = powered Jul 16 17:08:36 areca-1 kernel: uhci2: = port 0x1840-0x185f irq 18 at device 29.2 on pci0 Jul 16 17:08:36 areca-1 kernel: uhci2: [GIANT-LOCKED] Jul 16 17:08:36 areca-1 kernel: uhci2: [ITHREAD] Jul 16 17:08:36 areca-1 kernel: usb2: on = uhci2 Jul 16 17:08:36 areca-1 kernel: usb2: USB revision 1.0 Jul 16 17:08:36 areca-1 kernel: uhub2: on usb2 Jul 16 17:08:36 areca-1 kernel: uhub2: 2 ports with 2 removable, self = powered Jul 16 17:08:36 areca-1 kernel: ehci0: mem 0xd8b00000-0xd8b003ff irq 17 at device 29.7 on pci0 Jul 16 17:08:36 areca-1 kernel: ehci0: [GIANT-LOCKED] Jul 16 17:08:36 areca-1 kernel: ehci0: [ITHREAD] Jul 16 17:08:36 areca-1 kernel: usb3: EHCI version 1.0 Jul 16 17:08:36 areca-1 kernel: usb3: companion controllers, 2 ports = each: usb0 usb1 usb2 Jul 16 17:08:36 areca-1 kernel: usb3: on ehci0 Jul 16 17:08:36 areca-1 kernel: usb3: USB revision 2.0 Jul 16 17:08:36 areca-1 kernel: uhub3: on usb3 Jul 16 17:08:36 areca-1 kernel: uhub3: 6 ports with 6 removable, self = powered Jul 16 17:08:36 areca-1 kernel: pcib13: at device = 30.0 on pci0 Jul 16 17:08:36 areca-1 kernel: pci13: on pcib13 Jul 16 17:08:36 areca-1 kernel: vgapci0: port = 0x5000-0x50ff mem 0xd0000000-0xd7ffffff,0xd8800000-0xd880ffff irq 18 at = device 1.0 on pci13 Jul 16 17:08:36 areca-1 kernel: isab0: at device 31.0 = on pci0 Jul 16 17:08:36 areca-1 kernel: isa0: on isab0 Jul 16 17:08:36 areca-1 kernel: atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1860-0x186f at = device 31.1 on pci0 Jul 16 17:08:36 areca-1 kernel: ata0: on atapci0 Jul 16 17:08:36 areca-1 kernel: ata0: [ITHREAD] Jul 16 17:08:36 areca-1 kernel: ata1: on atapci0 Jul 16 17:08:36 areca-1 kernel: ata1: [ITHREAD] Jul 16 17:08:36 areca-1 kernel: pci0: at device 31.3 = (no driver attached) Jul 16 17:08:36 areca-1 kernel: acpi_button0: on acpi0 Jul 16 17:08:36 areca-1 kernel: atkbdc0: = port 0x60,0x64 irq 1 on acpi0 Jul 16 17:08:36 areca-1 kernel: atkbd0: irq 1 on atkbdc0 Jul 16 17:08:36 areca-1 kernel: kbd0 at atkbd0 Jul 16 17:08:36 areca-1 kernel: atkbd0: [GIANT-LOCKED] Jul 16 17:08:36 areca-1 kernel: atkbd0: [ITHREAD] Jul 16 17:08:36 areca-1 kernel: psm0: irq 12 on atkbdc0 Jul 16 17:08:36 areca-1 kernel: psm0: [GIANT-LOCKED] Jul 16 17:08:36 areca-1 kernel: psm0: [ITHREAD] Jul 16 17:08:36 areca-1 kernel: psm0: model IntelliMouse Explorer, = device ID 4 Jul 16 17:08:36 areca-1 kernel: sio0: configured irq 4 not in bitmap of = probed irqs 0 Jul 16 17:08:36 areca-1 kernel: sio0: port may not be enabled Jul 16 17:08:36 areca-1 kernel: sio0: configured irq 4 not in bitmap of = probed irqs 0 Jul 16 17:08:36 areca-1 kernel: sio0: port may not be enabled Jul 16 17:08:36 areca-1 kernel: sio0: <16550A-compatible COM port> port = 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 Jul 16 17:08:36 areca-1 kernel: sio0: type 16550A Jul 16 17:08:36 areca-1 kernel: sio0: [FILTER] Jul 16 17:08:36 areca-1 kernel: sio1: configured irq 3 not in bitmap of = probed irqs 0 Jul 16 17:08:36 areca-1 kernel: sio1: port may not be enabled Jul 16 17:08:36 areca-1 kernel: sio1: configured irq 3 not in bitmap of = probed irqs 0 Jul 16 17:08:36 areca-1 kernel: sio1: port may not be enabled Jul 16 17:08:36 areca-1 kernel: sio1: <16550A-compatible COM port> port = 0x2f8-0x2ff irq 3 on acpi0 Jul 16 17:08:36 areca-1 kernel: sio1: type 16550A Jul 16 17:08:36 areca-1 kernel: sio1: [FILTER] Jul 16 17:08:36 areca-1 kernel: fdc0: port = 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 Jul 16 17:08:36 areca-1 kernel: fdc0: [FILTER] Jul 16 17:08:36 areca-1 kernel: ppc0: port = 0x378-0x37f,0x778-0x77f irq 7 drq 3 on acpi0 Jul 16 17:08:36 areca-1 kernel: ppc0: SMC-like chipset = (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode Jul 16 17:08:36 areca-1 kernel: ppc0: FIFO with 16/16/9 bytes threshold Jul 16 17:08:36 areca-1 kernel: ppbus0: on ppc0 Jul 16 17:08:36 areca-1 kernel: plip0: on = ppbus0 Jul 16 17:08:36 areca-1 kernel: lpt0: on ppbus0 Jul 16 17:08:36 areca-1 kernel: lpt0: Interrupt-driven port Jul 16 17:08:36 areca-1 kernel: ppi0: on ppbus0 Jul 16 17:08:36 areca-1 kernel: ppc0: [GIANT-LOCKED] Jul 16 17:08:36 areca-1 kernel: ppc0: [ITHREAD] Jul 16 17:08:36 areca-1 kernel: orm0: at iomem = 0xc0000-0xcafff,0xcb000-0xcbfff on isa0 Jul 16 17:08:36 areca-1 kernel: sc0: at flags 0x100 on = isa0 Jul 16 17:08:36 areca-1 kernel: sc0: VGA <16 virtual consoles, = flags=3D0x300> Jul 16 17:08:36 areca-1 kernel: vga0: at port = 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Jul 16 17:08:36 areca-1 kernel: Timecounters tick every 1.000 msec Jul 16 17:08:36 areca-1 kernel: Waiting 5 seconds for SCSI devices to = settle Jul 16 17:08:36 areca-1 kernel: acd0: CDROM at = ata0-slave UDMA33 Jul 16 17:08:36 areca-1 kernel: da0 at arcmsr0 bus 0 target 0 lun 0 Jul 16 17:08:36 areca-1 kernel: da0: Fixed = Direct Access SCSI-5 device=20 Jul 16 17:08:36 areca-1 kernel: da0: 166.666MB/s transfers (83.333MHz = DT, offset 32, 16bit) Jul 16 17:08:36 areca-1 kernel: da0: 19073MB (39061504 512 byte sectors: = 255H 63S/T 2431C) Jul 16 17:08:36 areca-1 kernel: da1 at arcmsr0 bus 0 target 0 lun 1 Jul 16 17:08:36 areca-1 kernel: da1: Fixed = Direct Access SCSI-5 device=20 Jul 16 17:08:36 areca-1 kernel: da1: 166.666MB/s transfers (83.333MHz = DT, offset 32, 16bit) Jul 16 17:08:36 areca-1 kernel: da1: 23841MB (48827392 512 byte sectors: = 255H 63S/T 3039C) Jul 16 17:08:36 areca-1 kernel: SMP: AP CPU #1 Launched! Jul 16 17:08:36 areca-1 kernel: Trying to mount root from = ufs:/dev/da0s1a Jul 16 17:08:36 areca-1 savecore: no dumps found Jul 16 17:13:50 areca-1 login: ROOT LOGIN (root) ON ttyv0 Jul 16 17:20:17 areca-1 login: ROOT LOGIN (root) ON ttyv1 Jul 16 17:54:16 areca-1 reboot: rebooted by root Jul 16 17:54:16 areca-1 syslogd: exiting on signal 15 Jul 16 17:59:42 areca-1 syslogd: kernel boot file is /boot/kernel/kernel Jul 16 17:59:42 areca-1 kernel: Copyright (c) 1992-2007 The FreeBSD = Project. Jul 16 17:59:42 areca-1 kernel: Copyright (c) 1979, 1980, 1983, 1986, = 1988, 1989, 1991, 1992, 1993, 1994 Jul 16 17:59:42 areca-1 kernel: The Regents of the University of = California. All rights reserved. Jul 16 17:59:42 areca-1 kernel: FreeBSD is a registered trademark of The = FreeBSD Foundation. Jul 16 17:59:42 areca-1 kernel: FreeBSD 7.0-CURRENT-200706 #0: Thu Jun = 7 21:38:42 UTC 2007 Jul 16 17:59:42 areca-1 kernel: = root@stiles.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC Jul 16 17:59:42 areca-1 kernel: WARNING: WITNESS option enabled, expect = reduced performance. Jul 16 17:59:42 areca-1 kernel: Timecounter "i8254" frequency 1193182 Hz = quality 0 Jul 16 17:59:42 areca-1 kernel: CPU: Intel(R) Xeon(R) CPU = 5150 @ 2.66GHz (2666.85-MHz K8-class CPU) Jul 16 17:59:42 areca-1 kernel: Origin =3D "GenuineIntel" Id =3D 0x6f6 = Stepping =3D 6 Jul 16 17:59:42 areca-1 kernel: = Features=3D0xbfebfbff Jul 16 17:59:42 areca-1 kernel: = Features2=3D0x4e3bd Jul 16 17:59:42 areca-1 kernel: AMD Features=3D0x20100800 Jul 16 17:59:42 areca-1 kernel: AMD Features2=3D0x1 Jul 16 17:59:42 areca-1 kernel: Cores per package: 2 Jul 16 17:59:42 areca-1 kernel: usable memory =3D 523649024 (499 MB) Jul 16 17:59:42 areca-1 kernel: avail memory =3D 503586816 (480 MB) Jul 16 17:59:42 areca-1 kernel: ACPI APIC Table: Jul 16 17:59:42 areca-1 kernel: FreeBSD/SMP: Multiprocessor System = Detected: 2 CPUs Jul 16 17:59:42 areca-1 kernel: cpu0 (BSP): APIC ID: 0 Jul 16 17:59:42 areca-1 kernel: cpu1 (AP): APIC ID: 1 Jul 16 17:59:42 areca-1 kernel: ioapic0 irqs 0-23 on = motherboard Jul 16 17:59:42 areca-1 kernel: ioapic1 irqs 24-47 on = motherboard Jul 16 17:59:42 areca-1 kernel: kbd1 at kbdmux0 Jul 16 17:59:42 areca-1 kernel: ath_hal: 0.9.20.3 (AR5210, AR5211, = AR5212, RF5111, RF5112, RF2413, RF5413) Jul 16 17:59:42 areca-1 kernel: acpi0: on motherboard Jul 16 17:59:42 areca-1 kernel: acpi0: [ITHREAD] Jul 16 17:59:42 areca-1 kernel: acpi0: Power Button (fixed) Jul 16 17:59:42 areca-1 kernel: Timecounter "ACPI-safe" frequency = 3579545 Hz quality 1000 Jul 16 17:59:42 areca-1 kernel: acpi_timer0: <24-bit timer at = 3.579545MHz> port 0x1008-0x100b on acpi0 Jul 16 17:59:42 areca-1 kernel: cpu0: on acpi0 Jul 16 17:59:42 areca-1 kernel: acpi_throttle0: on = cpu0 Jul 16 17:59:42 areca-1 kernel: cpu1: on acpi0 Jul 16 17:59:42 areca-1 kernel: acpi_throttle1: on = cpu1 Jul 16 17:59:42 areca-1 kernel: acpi_throttle1: failed to attach P_CNT Jul 16 17:59:42 areca-1 kernel: device_attach: acpi_throttle1 attach = returned 6 Jul 16 17:59:42 areca-1 kernel: pcib0: port = 0xcf8-0xcff on acpi0 Jul 16 17:59:42 areca-1 kernel: pci0: on pcib0 Jul 16 17:59:42 areca-1 kernel: pcib1: at device = 2.0 on pci0 Jul 16 17:59:42 areca-1 kernel: pci1: on pcib1 Jul 16 17:59:42 areca-1 kernel: pcib2: irq 16 at = device 0.0 on pci1 Jul 16 17:59:42 areca-1 kernel: pci2: on pcib2 Jul 16 17:59:42 areca-1 kernel: pcib3: irq 16 at = device 0.0 on pci2 Jul 16 17:59:42 areca-1 kernel: pci3: on pcib3 Jul 16 17:59:42 areca-1 kernel: pcib4: at device = 0.0 on pci3 Jul 16 17:59:42 areca-1 kernel: pci4: on pcib4 Jul 16 17:59:42 areca-1 kernel: rl0: port = 0x2000-0x20ff mem 0xd8500000-0xd85000ff irq 16 at device 1.0 on pci4 Jul 16 17:59:42 areca-1 kernel: miibus0: on rl0 Jul 16 17:59:42 areca-1 kernel: rlphy0: PHY 0 on miibus0 Jul 16 17:59:42 areca-1 kernel: rlphy0: 10baseT, 10baseT-FDX, = 100baseTX, 100baseTX-FDX, auto Jul 16 17:59:42 areca-1 kernel: rl0: Ethernet address: 00:40:f4:e9:1c:f3 Jul 16 17:59:42 areca-1 kernel: rl0: [ITHREAD] Jul 16 17:59:42 areca-1 kernel: ahd0: port 0x2800-0x28ff,0x2400-0x24ff mem 0xd8502000-0xd8503fff irq = 16 at device 2.0 on pci4 Jul 16 17:59:42 areca-1 kernel: ahd0: [ITHREAD] Jul 16 17:59:42 areca-1 kernel: aic7902: Ultra320 Wide Channel A, SCSI = Id=3D7, PCI 33 or 66Mhz, 512 SCBs Jul 16 17:59:42 areca-1 kernel: ahd1: port 0x3000-0x30ff,0x2c00-0x2cff mem 0xd8504000-0xd8505fff irq = 17 at device 2.1 on pci4 Jul 16 17:59:42 areca-1 kernel: ahd1: [ITHREAD] Jul 16 17:59:42 areca-1 kernel: aic7902: Ultra320 Wide Channel B, SCSI = Id=3D7, PCI 33 or 66Mhz, 512 SCBs Jul 16 17:59:42 areca-1 kernel: pcib5: at device = 0.2 on pci3 Jul 16 17:59:42 areca-1 kernel: pci5: on pcib5 Jul 16 17:59:42 areca-1 kernel: pcib6: irq 18 at = device 2.0 on pci2 Jul 16 17:59:42 areca-1 kernel: pci6: on pcib6 Jul 16 17:59:42 areca-1 kernel: pci6: at device 0.0 = (no driver attached) Jul 16 17:59:42 areca-1 kernel: pci6: at device 0.1 = (no driver attached) Jul 16 17:59:42 areca-1 kernel: pcib7: at device = 0.3 on pci1 Jul 16 17:59:42 areca-1 kernel: pci7: on pcib7 Jul 16 17:59:42 areca-1 kernel: pcib8: at device = 4.0 on pci0 Jul 16 17:59:42 areca-1 kernel: pci8: on pcib8 Jul 16 17:59:42 areca-1 kernel: pcib9: at device = 6.0 on pci0 Jul 16 17:59:42 areca-1 kernel: pci9: on pcib9 Jul 16 17:59:42 areca-1 kernel: pcib10: at device 0.0 = on pci9 Jul 16 17:59:42 areca-1 kernel: pci10: on pcib10 Jul 16 17:59:42 areca-1 kernel: arcmsr0: mem = 0xd8700000-0xd8700fff,0xd8000000-0xd83fffff irq 16 at device 14.0 on = pci10 Jul 16 17:59:42 areca-1 kernel: ARECA RAID ADAPTER0: Driver Version = 1.20.00.14 2007-2-05=20 Jul 16 17:59:42 areca-1 kernel: ARECA RAID ADAPTER0: FIRMWARE VERSION = V1.43 2007-4-17 =20 Jul 16 17:59:42 areca-1 kernel: arcmsr0: [ITHREAD] Jul 16 17:59:42 areca-1 kernel: pcib11: at device 0.2 = on pci9 Jul 16 17:59:42 areca-1 kernel: pci11: on pcib11 Jul 16 17:59:42 areca-1 kernel: pcib12: irq 17 at = device 28.0 on pci0 Jul 16 17:59:42 areca-1 kernel: pci12: on pcib12 Jul 16 17:59:42 areca-1 kernel: uhci0: = port 0x1800-0x181f irq 17 at device 29.0 on pci0 Jul 16 17:59:42 areca-1 kernel: uhci0: [GIANT-LOCKED] Jul 16 17:59:42 areca-1 kernel: uhci0: [ITHREAD] Jul 16 17:59:42 areca-1 kernel: usb0: on = uhci0 Jul 16 17:59:42 areca-1 kernel: usb0: USB revision 1.0 Jul 16 17:59:42 areca-1 kernel: uhub0: on usb0 Jul 16 17:59:42 areca-1 kernel: uhub0: 2 ports with 2 removable, self = powered Jul 16 17:59:42 areca-1 kernel: uhci1: = port 0x1820-0x183f irq 19 at device 29.1 on pci0 Jul 16 17:59:42 areca-1 kernel: uhci1: [GIANT-LOCKED] Jul 16 17:59:42 areca-1 kernel: uhci1: [ITHREAD] Jul 16 17:59:42 areca-1 kernel: usb1: on = uhci1 Jul 16 17:59:42 areca-1 kernel: usb1: USB revision 1.0 Jul 16 17:59:42 areca-1 kernel: uhub1: on usb1 Jul 16 17:59:42 areca-1 kernel: uhub1: 2 ports with 2 removable, self = powered Jul 16 17:59:42 areca-1 kernel: uhci2: = port 0x1840-0x185f irq 18 at device 29.2 on pci0 Jul 16 17:59:42 areca-1 kernel: uhci2: [GIANT-LOCKED] Jul 16 17:59:42 areca-1 kernel: uhci2: [ITHREAD] Jul 16 17:59:42 areca-1 kernel: usb2: on = uhci2 Jul 16 17:59:42 areca-1 kernel: usb2: USB revision 1.0 Jul 16 17:59:42 areca-1 kernel: uhub2: on usb2 Jul 16 17:59:42 areca-1 kernel: uhub2: 2 ports with 2 removable, self = powered Jul 16 17:59:42 areca-1 kernel: ehci0: mem 0xd8b00000-0xd8b003ff irq 17 at device 29.7 on pci0 Jul 16 17:59:42 areca-1 kernel: ehci0: [GIANT-LOCKED] Jul 16 17:59:42 areca-1 kernel: ehci0: [ITHREAD] Jul 16 17:59:42 areca-1 kernel: usb3: EHCI version 1.0 Jul 16 17:59:42 areca-1 kernel: usb3: companion controllers, 2 ports = each: usb0 usb1 usb2 Jul 16 17:59:42 areca-1 kernel: usb3: on ehci0 Jul 16 17:59:42 areca-1 kernel: usb3: USB revision 2.0 Jul 16 17:59:42 areca-1 kernel: uhub3: on usb3 Jul 16 17:59:42 areca-1 kernel: uhub3: 6 ports with 6 removable, self = powered Jul 16 17:59:42 areca-1 kernel: pcib13: at device = 30.0 on pci0 Jul 16 17:59:42 areca-1 kernel: pci13: on pcib13 Jul 16 17:59:42 areca-1 kernel: vgapci0: port = 0x5000-0x50ff mem 0xd0000000-0xd7ffffff,0xd8800000-0xd880ffff irq 18 at = device 1.0 on pci13 Jul 16 17:59:42 areca-1 kernel: isab0: at device 31.0 = on pci0 Jul 16 17:59:42 areca-1 kernel: isa0: on isab0 Jul 16 17:59:42 areca-1 kernel: atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1860-0x186f at = device 31.1 on pci0 Jul 16 17:59:42 areca-1 kernel: ata0: on atapci0 Jul 16 17:59:42 areca-1 kernel: ata0: [ITHREAD] Jul 16 17:59:42 areca-1 kernel: ata1: on atapci0 Jul 16 17:59:42 areca-1 kernel: ata1: [ITHREAD] Jul 16 17:59:42 areca-1 kernel: pci0: at device 31.3 = (no driver attached) Jul 16 17:59:42 areca-1 kernel: acpi_button0: on acpi0 Jul 16 17:59:42 areca-1 kernel: atkbdc0: = port 0x60,0x64 irq 1 on acpi0 Jul 16 17:59:42 areca-1 kernel: atkbd0: irq 1 on atkbdc0 Jul 16 17:59:42 areca-1 kernel: kbd0 at atkbd0 Jul 16 17:59:42 areca-1 kernel: atkbd0: [GIANT-LOCKED] Jul 16 17:59:42 areca-1 kernel: atkbd0: [ITHREAD] Jul 16 17:59:42 areca-1 kernel: psm0: irq 12 on atkbdc0 Jul 16 17:59:42 areca-1 kernel: psm0: [GIANT-LOCKED] Jul 16 17:59:42 areca-1 kernel: psm0: [ITHREAD] Jul 16 17:59:42 areca-1 kernel: psm0: model IntelliMouse Explorer, = device ID 4 Jul 16 17:59:42 areca-1 kernel: sio0: configured irq 4 not in bitmap of = probed irqs 0 Jul 16 17:59:42 areca-1 kernel: sio0: port may not be enabled Jul 16 17:59:42 areca-1 kernel: sio0: configured irq 4 not in bitmap of = probed irqs 0 Jul 16 17:59:42 areca-1 kernel: sio0: port may not be enabled Jul 16 17:59:42 areca-1 kernel: sio0: <16550A-compatible COM port> port = 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 Jul 16 17:59:42 areca-1 kernel: sio0: type 16550A Jul 16 17:59:42 areca-1 kernel: sio0: [FILTER] Jul 16 17:59:42 areca-1 kernel: sio1: configured irq 3 not in bitmap of = probed irqs 0 Jul 16 17:59:42 areca-1 kernel: sio1: port may not be enabled Jul 16 17:59:42 areca-1 kernel: sio1: configured irq 3 not in bitmap of = probed irqs 0 Jul 16 17:59:42 areca-1 kernel: sio1: port may not be enabled Jul 16 17:59:42 areca-1 kernel: sio1: <16550A-compatible COM port> port = 0x2f8-0x2ff irq 3 on acpi0 Jul 16 17:59:42 areca-1 kernel: sio1: type 16550A Jul 16 17:59:42 areca-1 kernel: sio1: [FILTER] Jul 16 17:59:42 areca-1 kernel: fdc0: port = 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 Jul 16 17:59:42 areca-1 kernel: fdc0: [FILTER] Jul 16 17:59:42 areca-1 kernel: ppc0: port = 0x378-0x37f,0x778-0x77f irq 7 drq 3 on acpi0 Jul 16 17:59:42 areca-1 kernel: ppc0: SMC-like chipset = (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode Jul 16 17:59:42 areca-1 kernel: ppc0: FIFO with 16/16/9 bytes threshold Jul 16 17:59:42 areca-1 kernel: ppbus0: on ppc0 Jul 16 17:59:42 areca-1 kernel: plip0: on = ppbus0 Jul 16 17:59:42 areca-1 kernel: lpt0: on ppbus0 Jul 16 17:59:42 areca-1 kernel: lpt0: Interrupt-driven port Jul 16 17:59:42 areca-1 kernel: ppi0: on ppbus0 Jul 16 17:59:42 areca-1 kernel: ppc0: [GIANT-LOCKED] Jul 16 17:59:42 areca-1 kernel: ppc0: [ITHREAD] Jul 16 17:59:42 areca-1 kernel: orm0: at iomem = 0xc0000-0xcafff,0xcb000-0xcbfff on isa0 Jul 16 17:59:42 areca-1 kernel: sc0: at flags 0x100 on = isa0 Jul 16 17:59:42 areca-1 kernel: sc0: VGA <16 virtual consoles, = flags=3D0x300> Jul 16 17:59:42 areca-1 kernel: vga0: at port = 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Jul 16 17:59:42 areca-1 kernel: Timecounters tick every 1.000 msec Jul 16 17:59:42 areca-1 kernel: Waiting 5 seconds for SCSI devices to = settle Jul 16 17:59:42 areca-1 kernel: acd0: CDROM at = ata0-slave UDMA33 Jul 16 17:59:42 areca-1 kernel: da0 at arcmsr0 bus 0 target 0 lun 0 Jul 16 17:59:42 areca-1 kernel: da0: Fixed = Direct Access SCSI-5 device=20 Jul 16 17:59:42 areca-1 kernel: da0: 166.666MB/s transfers (83.333MHz = DT, offset 32, 16bit) Jul 16 17:59:42 areca-1 kernel: da0: 19073MB (39061504 512 byte sectors: = 255H 63S/T 2431C) Jul 16 17:59:42 areca-1 kernel: da1 at arcmsr0 bus 0 target 0 lun 1 Jul 16 17:59:42 areca-1 kernel: da1: Fixed = Direct Access SCSI-5 device=20 Jul 16 17:59:42 areca-1 kernel: da1: 166.666MB/s transfers (83.333MHz = DT, offset 32, 16bit) Jul 16 17:59:42 areca-1 kernel: da1: 23841MB (48827392 512 byte sectors: = 255H 63S/T 3039C) Jul 16 17:59:42 areca-1 kernel: SMP: AP CPU #1 Launched! Jul 16 17:59:42 areca-1 kernel: Trying to mount root from = ufs:/dev/da0s1a Jul 16 17:59:42 areca-1 savecore: no dumps found Jul 16 18:02:44 areca-1 login: ROOT LOGIN (root) ON ttyv0 Jul 16 18:04:29 areca-1 login: ROOT LOGIN (root) ON ttyv1 ------=_NextPart_000_0014_01C7C7DD.480B52F0-- From owner-freebsd-current@FreeBSD.ORG Mon Jul 16 12:45:46 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4241216A405; Mon, 16 Jul 2007 12:45:46 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.freebsd.org (Postfix) with ESMTP id 212AD13C4A7; Mon, 16 Jul 2007 12:45:37 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.7b8) with ESMTP id 196926975 for multiple; Mon, 16 Jul 2007 08:36:36 -0400 Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id l6GCSBkH031595; Mon, 16 Jul 2007 08:28:17 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Mon, 16 Jul 2007 07:55:13 -0400 User-Agent: KMail/1.9.6 References: <469B2787.9010302@fer.hr> In-Reply-To: <469B2787.9010302@fer.hr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200707160755.14498.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Mon, 16 Jul 2007 08:28:18 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/3680/Mon Jul 16 01:49:06 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx X-Server: High Performance Mail Server - http://surgemail.com r=1653887525 Cc: David Malone , freebsd-current@freebsd.org, Victor Snezhko , Ivan Voras Subject: Re: Debugging times X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Jul 2007 12:45:46 -0000 On Monday 16 July 2007 04:08:39 am Ivan Voras wrote: > Victor Snezhko wrote: > > > Also, this was a surprise to an unexperienced me, but I have also > > found that vfs_mount initializes RTC with the latest timestamp found > > on local file systems - this explains why kernel "worked" for Ivan on > > a hard drive. It didn't actually work, but used timestamp which was > > stored on filesystem during unmount. > > Wow - this is just astonishing - why would a file system have anything > to do with the RTC? It's more that we use the filesystem's timestamp as a way to validate the timestamp from the RTC and to do a fixup if the RTC appears to be dead. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Jul 16 12:43:44 2007 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 582EC16A40A; Mon, 16 Jul 2007 12:43:44 +0000 (UTC) (envelope-from christos@zoulas.com) Received: from rebar.astron.com (rebar.astron.com [38.117.134.202]) by mx1.freebsd.org (Postfix) with ESMTP id DBE2713C4B4; Mon, 16 Jul 2007 12:43:43 +0000 (UTC) (envelope-from christos@zoulas.com) Received: by rebar.astron.com (Postfix, from userid 10080) id D408656407; Mon, 16 Jul 2007 08:43:42 -0400 (EDT) From: christos@zoulas.com (Christos Zoulas) Date: Mon, 16 Jul 2007 08:43:42 -0400 In-Reply-To: <20070716092109.GB2568@kobe.laptop> from Giorgos Keramidas (Jul 16, 12:21pm) Organization: Astron Software X-Mailer: Mail User's Shell (7.2.6 beta(4.pl1)+dynamic 20000103) To: Giorgos Keramidas Message-Id: <20070716124342.D408656407@rebar.astron.com> X-Mailman-Approved-At: Mon, 16 Jul 2007 12:54:35 +0000 Cc: Mark Peek , tcsh-bugs@mx.gw.com, kris@FreeBSD.org, current@FreeBSD.org Subject: Re: tcsh backtick hang info X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Jul 2007 12:43:44 -0000 On Jul 16, 12:21pm, keramida@FreeBSD.org (Giorgos Keramidas) wrote: -- Subject: Re: tcsh backtick hang info | This was really brought to my notice by Kris Kennaway, so he's the one | we should thank. Ok, I made a note of it. christos From owner-freebsd-current@FreeBSD.ORG Mon Jul 16 13:14:08 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5DFF916A400; Mon, 16 Jul 2007 13:14:08 +0000 (UTC) (envelope-from ivoras@fer.hr) Received: from ls405.t-com.hr (ls405.t-com.hr [195.29.150.135]) by mx1.freebsd.org (Postfix) with ESMTP id 12B5A13C4A3; Mon, 16 Jul 2007 13:14:07 +0000 (UTC) (envelope-from ivoras@fer.hr) Received: from ls248.t-com.hr (ls248.t-com.hr [195.29.150.237]) by ls405.t-com.hr (Postfix) with ESMTP id 3F4F01488B3; Mon, 16 Jul 2007 15:14:06 +0200 (CEST) Received: from ls248.t-com.hr (localhost.localdomain [127.0.0.1]) by ls248.t-com.hr (Qmlai) with ESMTP id 3B4ACD50047; Mon, 16 Jul 2007 15:14:06 +0200 (CEST) Received: from ls248.t-com.hr (localhost.localdomain [127.0.0.1]) by ls248.t-com.hr (Qmlai) with ESMTP id 19A6AD50058; Mon, 16 Jul 2007 15:14:06 +0200 (CEST) X-Envelope-Sender-Info: g5URFa92gX9K/Rg9VFA/rMlfCnTWZGyid8wYf+70zpU6StkSH1j7CT0zJW9WjWDV X-Envelope-Sender: ivoras@fer.hr Received: from [10.0.0.100] (89-172-62-27.adsl.net.t-com.hr [89.172.62.27]) by ls248.t-com.hr (Qmali) with ESMTP id DB79A5E019C; Mon, 16 Jul 2007 15:14:05 +0200 (CEST) Message-ID: <469B6F1C.6020605@fer.hr> Date: Mon, 16 Jul 2007 15:14:04 +0200 From: Ivan Voras User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: John Baldwin References: <469B2787.9010302@fer.hr> <200707160755.14498.jhb@freebsd.org> In-Reply-To: <200707160755.14498.jhb@freebsd.org> X-Enigmail-Version: 0.94.3.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigC9B5182C29B5F923AF200466" Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: Debugging times X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Jul 2007 13:14:08 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC9B5182C29B5F923AF200466 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable John Baldwin wrote: > It's more that we use the filesystem's timestamp as a way to validate t= he=20 > timestamp from the RTC and to do a fixup if the RTC appears to be dead.= Why not use something that doesn't depend on external factors, like kernel build time (AFAIK it's embedded somewhere - at least it's written on boot)? This way people using non-UFS file systems wouldn't get bitten.= --------------enigC9B5182C29B5F923AF200466 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGm28cldnAQVacBcgRApCLAJ9aD4S/KAIuowQ7FijtMYmpeENRNwCdHdYr zCXOTX3v05T2oISvwS4SyhQ= =/lvs -----END PGP SIGNATURE----- --------------enigC9B5182C29B5F923AF200466-- From owner-freebsd-current@FreeBSD.ORG Mon Jul 16 14:15:14 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4D29F16A400 for ; Mon, 16 Jul 2007 14:15:14 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) by mx1.freebsd.org (Postfix) with ESMTP id C518413C4B7 for ; Mon, 16 Jul 2007 14:15:13 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.1/8.14.1) with ESMTP id l6GEF5Tf075597; Mon, 16 Jul 2007 18:15:06 +0400 (MSD) (envelope-from marck@rinet.ru) Date: Mon, 16 Jul 2007 18:15:05 +0400 (MSD) From: Dmitry Morozovsky To: Doug Barton In-Reply-To: <46951CC2.5050602@FreeBSD.org> Message-ID: <20070716181242.S73148@woozle.rinet.ru> References: <20070419133550.GA65054@tirith.brixandersen.dk> <20070419200929.GA70735@tirith.brixandersen.dk> <4693BC3E.1050605@web.am> <200707110115.42139.pieter@degoeje.nl> <469417CB.7010705@FreeBSD.org> <4694AAF1.6050302@web.am> <46951CC2.5050602@FreeBSD.org> X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (woozle.rinet.ru [0.0.0.0]); Mon, 16 Jul 2007 18:15:08 +0400 (MSD) Cc: Pieter de Goeje , Gaspar Chilingarov , freebsd-current@freebsd.org Subject: Re: RFT: bin/106642: [patch] Allow excluding certain files from mergemaster (8) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2007 14:15:14 -0000 On Wed, 11 Jul 2007, Doug Barton wrote: DB> > About pre-script which you suggested, there is another problem -- I MAY DB> > have new scripts in /etc/rc.d, but NEVER change the system's scripts. DB> DB> Simple answer, don't do that. Put your scripts in /usr/local/etc/rc.d DB> instead, and as of 6.1 and newer they will be included in the base DB> rcorder. Therefore there will be no difference in when they are run. DB> There is a default assumption that stuff in /etc/rc.d is the systems, DB> and the systems only. Now that local scripts (including ports) are in DB> the base rcorder, there is no reason not to do it that way. The first exclusion in mind would be scripts that should be running before mounting file systems other than root... Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Mon Jul 16 14:30:11 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B732116A40D for ; Mon, 16 Jul 2007 14:30:11 +0000 (UTC) (envelope-from barnaclewes@gmail.com) Received: from ik-out-1112.google.com (ik-out-1112.google.com [66.249.90.180]) by mx1.freebsd.org (Postfix) with ESMTP id 3708713C4AC for ; Mon, 16 Jul 2007 14:30:08 +0000 (UTC) (envelope-from barnaclewes@gmail.com) Received: by ik-out-1112.google.com with SMTP id c21so651139ika for ; Mon, 16 Jul 2007 07:30:07 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=quRFjnXaS5cN4CP9iFWxxiVD7+M9Zujbpb+oS7RrTiD8/GS7J70KJXjaIGRk7NvwUlRqKVaToO3BqkliHCqEiSMvAsZVkfykdZD/PMxBIjQQEoFlZ3Nh2K40+3NYNeXakb9zhy8dqD2ADwBQWgRizoGoJICViaD/CUiKLgSe44s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ZtaOKJqeKsw92GzAx30YPgj4dsu4oqFUm9j9YIxx+Xj4Fxu/FDlz4im82xeVFwOByKdae44H7wQAGec/jMYpKMdtYZXf0p+VOci7KuYPNJx44IZjku3PWyXUE1IIQz8+W8NbJbSSOIVuhHxKsf0spoKEWSwzLh1nRZBlBjMfmgk= Received: by 10.78.176.20 with SMTP id y20mr1180935hue.1184594548491; Mon, 16 Jul 2007 07:02:28 -0700 (PDT) Received: by 10.78.201.4 with HTTP; Mon, 16 Jul 2007 07:02:28 -0700 (PDT) Message-ID: Date: Mon, 16 Jul 2007 07:02:28 -0700 From: "Wes Peters" To: "Andrey Chernov" , "Sean C. Farley" , "Robert Watson" , freebsd-current , "Michal Mertl" In-Reply-To: <20070713162742.GA16260@nagual.pp.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070704215154.O77978@thor.farley.org> <20070705105922.F98700@thor.farley.org> <20070707130859.GA96605@nagual.pp.ru> <20070707131359.GB96605@nagual.pp.ru> <20070707133102.C14065@thor.farley.org> <20070707191835.GA4368@nagual.pp.ru> <20070707205410.B14065@thor.farley.org> <20070708020940.GA80166@nagual.pp.ru> <20070708171727.GA90490@nagual.pp.ru> <20070713162742.GA16260@nagual.pp.ru> Cc: Subject: Re: Environment handling broken in /bin/sh with changes to {get, set, put}env() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Jul 2007 14:30:11 -0000 On 7/13/07, Andrey Chernov wrote: > On Sun, Jul 08, 2007 at 09:17:27PM +0400, Andrey Chernov wrote: > > Hmm. I just think a bit more and feel worry about that place in the merge > > code: > > > > *equals = '\0'; > > if (setenv(*env, equals + 1, 1) == -1) > > return (-1); > > *equals = '='; > > because it modifies memory which may be treated like const one. > > > > Consider following scenario: getenv() is not thread-safe, but may be > [snip] > > I found another breakage case not covered by your last getenv() fix. > Take this simple program: > > -- a.c ------------------------------------------------------------------- > #include > extern char **environ; > > main () { > > static char *nenv[2]; > > nenv[0] = "PATH=/bin"; > nenv[1] = NULL; > > /* > environ = nenv; > unsetenv("PATH"); or somethig like > which touch '=' char in nenv[0] > */ > > nenv[0][4] = '\0'; > > } > -- a.c ------------------------------------------------------------------- > > Look at assembler code first: > > cc -S a.c > cat a.s > .file "a.c" > .local nenv.1948 > .comm nenv.1948,8,4 > .section .rodata > .LC0: > .string "PATH=/bin" > .text > > [skipped] > > As you may see, compiler puts "PATH=/bin" to the program's .rodata section > which is placed to read only memory. > > If later you'll modify this single "PATH=/bin" (comes from "nenv" now) by > *equals = '\0'; > ... > *equals = '='; > core dump happens, which simulated in my simple a.c example by > nenv[0][4] = '\0'; > > Just run it and got code dump. The default setting for 'writable-string' changed in gcc; strings are now NOT writable by default. While it may seem reasonable, setting the programs environment to non-writable strings by manipulating the environ pointer, then attempting to modify those strings, is bound to fail. Since you've directly set the environment, there isn't much that {set,put}env() could do, unless you want to get clever and have them detect strings in .rodata and work around that. The simplest solution may be a caution in the man page about stuffing read-only strings into the environment. -- Against stupidity the very gods Themselves contend in vain. Friedrich Schiller From owner-freebsd-current@FreeBSD.ORG Mon Jul 16 14:38:15 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DC76116A403 for ; Mon, 16 Jul 2007 14:38:15 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) by mx1.freebsd.org (Postfix) with ESMTP id 6805513C4B5 for ; Mon, 16 Jul 2007 14:38:15 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.1/8.14.1) with ESMTP id l6GEcEZG075962 for ; Mon, 16 Jul 2007 18:38:14 +0400 (MSD) (envelope-from marck@rinet.ru) Date: Mon, 16 Jul 2007 18:38:14 +0400 (MSD) From: Dmitry Morozovsky To: current@freebsd.org Message-ID: <20070716182657.X73148@woozle.rinet.ru> X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (woozle.rinet.ru [0.0.0.0]); Mon, 16 Jul 2007 18:38:14 +0400 (MSD) Cc: Subject: tcsh, su (port make config/make install), unexpected suspension X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Jul 2007 14:38:15 -0000 Dear colleagues, -CURRENT from 15 Jul running `make install' or `make config' in port directory from non-root user with tcsh often (but not always) leads to unexpected su suspension, like: Script started on Mon Jul 16 18:33:11 2007 marck@mck-s420:/usr/ports/sysutils/smartmontools> make config ===> Switching to root credentials to create /var/db/ports/smartmontools Password: ===> Returning to user credentials Suspended (tty output) marck@mck-s420:/usr/ports/sysutils/smartmontools> j [1] + 1079 Suspended (tty output) make config marck@mck-s420:/usr/ports/sysutils/smartmontools> fg make config [config window here] Password: ===> Returning to user credentials marck@mck-s420:/usr/ports/sysutils/smartmontools> j marck@mck-s420:/usr/ports/sysutils/smartmontools> x exit Script done on Mon Jul 16 18:34:17 2007 This seems to be related to broken signal handling in tsch 6.15.00 discussed earlier. Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Mon Jul 16 14:46:29 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1729916A401 for ; Mon, 16 Jul 2007 14:46:29 +0000 (UTC) (envelope-from rpaulo@fnop.net) Received: from core.fnop.net (mx.fnop.net [82.102.11.82]) by mx1.freebsd.org (Postfix) with ESMTP id 8661513C4A8 for ; Mon, 16 Jul 2007 14:46:28 +0000 (UTC) (envelope-from rpaulo@fnop.net) Received: from core.fnop.net (mx.fnop.net [82.102.11.82]) by core.fnop.net (Postfix) with ESMTP id F3240690D63; Mon, 16 Jul 2007 15:40:36 +0100 (WEST) Received: by core.fnop.net (Postfix, from userid 1015) id B419F690E19; Mon, 16 Jul 2007 15:40:36 +0100 (WEST) X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on core.fnop.net X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.7 Received: from epsilon.local (87-196-113-137.net.novis.pt [87.196.113.137]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by core.fnop.net (Postfix) with ESMTP id CF902690D63; Mon, 16 Jul 2007 15:40:34 +0100 (WEST) Message-ID: <469B84AF.7040605@fnop.net> Date: Mon, 16 Jul 2007 15:46:07 +0100 From: Rui Paulo User-Agent: Thunderbird 2.0.0.4 (X11/20070704) MIME-Version: 1.0 To: Dmitry Morozovsky References: <20070716182657.X73148@woozle.rinet.ru> In-Reply-To: <20070716182657.X73148@woozle.rinet.ru> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: current@freebsd.org Subject: Re: tcsh, su (port make config/make install), unexpected suspension X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Jul 2007 14:46:29 -0000 Dmitry Morozovsky wrote: > Dear colleagues, > > -CURRENT from 15 Jul > > running `make install' or `make config' in port directory from non-root user > with tcsh often (but not always) leads to unexpected su suspension, like: > > Script started on Mon Jul 16 18:33:11 2007 > marck@mck-s420:/usr/ports/sysutils/smartmontools> make config > ===> Switching to root credentials to create /var/db/ports/smartmontools > Password: > ===> Returning to user credentials > > Suspended (tty output) > marck@mck-s420:/usr/ports/sysutils/smartmontools> j > [1] + 1079 Suspended (tty output) make config > marck@mck-s420:/usr/ports/sysutils/smartmontools> fg > > make config > > [config window here] > > Password: > ===> Returning to user credentials > marck@mck-s420:/usr/ports/sysutils/smartmontools> j > marck@mck-s420:/usr/ports/sysutils/smartmontools> x > exit > > Script done on Mon Jul 16 18:34:17 2007 > > > This seems to be related to broken signal handling in tsch 6.15.00 discussed > earlier. No. I have the same problem with zsh and the ports infrastructure uses /bin/sh, not tcsh. Regards. -- Rui Paulo From owner-freebsd-current@FreeBSD.ORG Mon Jul 16 14:54:07 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BA21516A403; Mon, 16 Jul 2007 14:54:07 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (nagual.pp.ru [194.87.13.69]) by mx1.freebsd.org (Postfix) with ESMTP id 2E20013C478; Mon, 16 Jul 2007 14:54:06 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.14.1/8.14.1) with ESMTP id l6GEs5Vb083649; Mon, 16 Jul 2007 18:54:05 +0400 (MSD) (envelope-from ache@nagual.pp.ru) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nagual.pp.ru; s=default; t=1184597645; bh=T4nrSA+8VtffzcgrsOGu/7WmP1XbPmgVo+fH6Rf UDH8=; l=419; h=Received:Date:From:To:Cc:Subject:Message-ID: Mail-Followup-To:References:MIME-Version:Content-Type: Content-Disposition:In-Reply-To:User-Agent; b=q/Mg5CsxsX55boHO9lLy nWkpS7brbPgJVlwHkMp1YZhPdI6CRx/IHC1oVcNs+CCMgsfk5EOCYMr+KMf3qd1fW2k wbezJle5jB6yiUG2Ej2yMdyu11vFi69f75msIHeyig3UgWH8/DfKhh9JsvTRjLX/lFE ZMyJhyBncTG6yrj9o= Received: (from ache@localhost) by nagual.pp.ru (8.14.1/8.14.1/Submit) id l6GEs4wp083647; Mon, 16 Jul 2007 18:54:04 +0400 (MSD) (envelope-from ache) Date: Mon, 16 Jul 2007 18:54:03 +0400 From: Andrey Chernov To: Wes Peters Message-ID: <20070716145403.GA83573@nagual.pp.ru> Mail-Followup-To: Andrey Chernov , Wes Peters , "Sean C. Farley" , Robert Watson , freebsd-current , Michal Mertl References: <20070705105922.F98700@thor.farley.org> <20070707130859.GA96605@nagual.pp.ru> <20070707131359.GB96605@nagual.pp.ru> <20070707133102.C14065@thor.farley.org> <20070707191835.GA4368@nagual.pp.ru> <20070707205410.B14065@thor.farley.org> <20070708020940.GA80166@nagual.pp.ru> <20070708171727.GA90490@nagual.pp.ru> <20070713162742.GA16260@nagual.pp.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-current , Robert Watson , "Sean C. Farley" , Michal Mertl Subject: Re: Environment handling broken in /bin/sh with changes to {get,set,put}env() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Jul 2007 14:54:07 -0000 On Mon, Jul 16, 2007 at 07:02:28AM -0700, Wes Peters wrote: > While it may seem reasonable, setting > the programs environment to non-writable strings by manipulating the > environ pointer, then attempting to modify those strings, is bound to > fail. There is no attempts to modify those strings requested by user, that is the problem I point to. Now fixed in the latest Sean patch. -- http://ache.pp.ru/ From owner-freebsd-current@FreeBSD.ORG Mon Jul 16 14:57:26 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7581D16A401 for ; Mon, 16 Jul 2007 14:57:26 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.freebsd.org (Postfix) with ESMTP id 199C013C4B7 for ; Mon, 16 Jul 2007 14:57:25 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.7b8) with ESMTP id 196960642 for multiple; Mon, 16 Jul 2007 11:05:42 -0400 Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id l6GEvML5032514; Mon, 16 Jul 2007 10:57:22 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Mon, 16 Jul 2007 08:45:25 -0400 User-Agent: KMail/1.9.6 References: <46735262.50601@root.org> <4673768D.1050805@root.org> <46741947.3050200@root.org> In-Reply-To: <46741947.3050200@root.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200707160845.26597.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Mon, 16 Jul 2007 10:57:22 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/3681/Mon Jul 16 09:16:18 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx X-Server: High Performance Mail Server - http://surgemail.com r=1653887525 Cc: acpi@freebsd.org, Nate Lawson Subject: Re: smi speedstep patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Jul 2007 14:57:26 -0000 On Saturday 16 June 2007 01:09:27 pm Nate Lawson wrote: > Nate Lawson wrote: > > Nate Lawson wrote: > >> If you have a pentium 3 that works for speedstep, please try this patch. > >> It fixes the PAE case. Compile-tested. > > > > Hmm, I see it's no longer getting the physical address, just virtual. > > So need to fix that part. > > Attached is the updated patch. It uses the low kernel map where P=V and > fixes the callback. I just need someone who is using smi-speedstep > (440bx chipset with pentium 3) to make sure the device still attaches. > Patch should work on 6.x and 7.x. Why do you need a V == P page? -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Jul 16 14:57:33 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A071616A417 for ; Mon, 16 Jul 2007 14:57:33 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.freebsd.org (Postfix) with ESMTP id 0330013C4CC for ; Mon, 16 Jul 2007 14:57:32 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.7b8) with ESMTP id 196960666 for multiple; Mon, 16 Jul 2007 11:05:48 -0400 Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id l6GEvML6032514; Mon, 16 Jul 2007 10:57:25 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Mon, 16 Jul 2007 08:49:06 -0400 User-Agent: KMail/1.9.6 References: <20070616224703.GC63387@obiwan.tataz.chchile.org> <20070618100238.GD46910@heff.fud.org.nz> In-Reply-To: <20070618100238.GD46910@heff.fud.org.nz> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200707160849.07376.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Mon, 16 Jul 2007 10:57:25 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/3681/Mon Jul 16 09:16:18 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx X-Server: High Performance Mail Server - http://surgemail.com r=1653887525 Cc: Jeremie Le Hen , Andrew Thompson Subject: Re: Cannot use iwi(4): "could not load firmware iwi_bss" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Jul 2007 14:57:33 -0000 On Monday 18 June 2007 06:02:38 am Andrew Thompson wrote: > On Sun, Jun 17, 2007 at 12:47:03AM +0200, Jeremie Le Hen wrote: > > Hi, > > > > I'm trying to use iwi(4) on my laptop. > > > > % jarjarbinks:space$ kenv | grep intel > > % legal.intel_iwi.license_ack="1" > > > > I first load iwi_bss and then iwi. Unfortunately I get the following > > messages: > > > > % iwi0: mem 0xc8218000-0xc8218fff irq 11 at device 3.0 on pci6 > > % iwi0: Ethernet address: 00:12:f0:2c:f3:6e > > % iwi0: [ITHREAD] > > % interrupt storm detected on "irq10:"; throttling interrupt source > > % iwi0: timeout waiting for iwi_bss firmware initialization to complete > > % iwi0: could not load boot firmware iwi_bss > > % interrupt storm detected on "irq10:"; throttling interrupt source > > % iwi0: timeout waiting for iwi_bss firmware initialization to complete > > % iwi0: could not load boot firmware iwi_bss > > % interrupt storm detected on "irq10:"; throttling interrupt source > > % iwi0: timeout waiting for iwi_bss firmware initialization to complete > > % iwi0: could not load boot firmware iwi_bss > > % interrupt storm detected on "irq10:"; throttling interrupt source > > % iwi0: timeout waiting for iwi_bss firmware initialization to complete > > % iwi0: could not load boot firmware iwi_bss > > The driver will wait one second for the firmware to load, it is possible > that the interrupt storm is affecting this. You can always increase the > iwi timeout on line 2516 of if_iwi.c and see what happens. Change hz to > hz * 3 perhaps. Looks like iwi's IRQ is wrong (misrouted perhaps). Fixing that will probably fix your issue. Are you using ACPI? (It appears you are not using apic.) -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Jul 16 14:57:36 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 47D6216A406 for ; Mon, 16 Jul 2007 14:57:36 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.freebsd.org (Postfix) with ESMTP id CAA9B13C4A3 for ; Mon, 16 Jul 2007 14:57:35 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.7b8) with ESMTP id 196960681 for multiple; Mon, 16 Jul 2007 11:05:52 -0400 Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id l6GEvML7032514; Mon, 16 Jul 2007 10:57:31 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Mon, 16 Jul 2007 08:50:44 -0400 User-Agent: KMail/1.9.6 References: <20070617024935.GU4602@funkthat.com> <20070617053746.GV4602@funkthat.com> <20070616.235659.-1947354616.imp@bsdimp.com> In-Reply-To: <20070616.235659.-1947354616.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200707160850.46259.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Mon, 16 Jul 2007 10:57:32 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/3681/Mon Jul 16 09:16:18 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx X-Server: High Performance Mail Server - http://surgemail.com r=1653887525 Cc: gurney_j@resnet.uoregon.edu, current@freebsd.org, wsk@gddsn.org.cn, mobile@freebsd.org, simokawa@freebsd.org, "M. Warner Losh" Subject: Re: kernel panic with pccard insert on recent 7.0 CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2007 14:57:36 -0000 On Sunday 17 June 2007 01:56:59 am M. Warner Losh wrote: > In message: <20070617053746.GV4602@funkthat.com> > John-Mark Gurney writes: > : Warner Losh wrote this message on Sat, Jun 16, 2007 at 21:12 -0600: > : > In message: <20070617024935.GU4602@funkthat.com> > : > John-Mark Gurney writes: > : > : Warner Losh wrote this message on Sat, Jun 16, 2007 at 17:33 -0600: > : > : > Also, I'm unclear on the difference between FILTER_STRAY and > : > : > FILTER_HANDLED. > : > : > : > : The interrupt filter is suppose to return one of FILTER_STRAY or > : > : FILTER_HANDLED... If you _HANDLED it return that, otherwise return > : > : _STRAY... If you need to schedule the ithread, return _HANDLED or'd > : > : with _SCHEDULE_THREAD... > : > > : > Will _HANDLED cause all the other handlers to not get called, or just > : > the stray interrupt code from not happening? > : > : It will cause the remaining (not yet called) handlers not to get called... > > I'm not sure that's right, especially for edge triggered devices.\ They shouldn't share interrupts then. Do we support shared interrupts on edge triggered devices? > : intr_event_handle calls intr_filter_loop which will return on the first > : non-_STRAY handler and return it... Which intr_event_handle eoi's... > : > : It looks like this code is designed for level triggered interrupts and > : not edge triggered... > > Yes. I'm pretty sure that's wrong. All ISA and PC Card devices use > edge triggered interrupts. Also, it is inefficient for level > triggered interrupts, since two interrupt sources on the same > interrupt may trigger at about the same time... It works fine since the second device will interrupt again and we will fall through to its routine on the second interrupt. The idea is that simultaneous interrupts are rare enough that it is worth optimizing the common case. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Jul 16 14:57:39 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2CDE216A4AB for ; Mon, 16 Jul 2007 14:57:39 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.freebsd.org (Postfix) with ESMTP id E716B13C4BD for ; Mon, 16 Jul 2007 14:57:38 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.7b8) with ESMTP id 196960693 for multiple; Mon, 16 Jul 2007 11:05:55 -0400 Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id l6GEvML8032514; Mon, 16 Jul 2007 10:57:35 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Mon, 16 Jul 2007 09:08:30 -0400 User-Agent: KMail/1.9.6 References: <20070617213948.GA50404@rot13.obsecurity.org> In-Reply-To: <20070617213948.GA50404@rot13.obsecurity.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200707160908.31093.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Mon, 16 Jul 2007 10:57:35 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/3681/Mon Jul 16 09:16:18 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx X-Server: High Performance Mail Server - http://surgemail.com r=1653887525 Cc: Kris Kennaway Subject: Re: Userland problems from kern.pts.enable=1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2007 14:57:39 -0000 On Sunday 17 June 2007 05:39:48 pm Kris Kennaway wrote: > When the kern.pts.enable sysctl is set to '1', pseudo-ttys are created > with device name /dev/pts/${NUMBER}. With some kernel fixes from kib > this appears to now be stable and the kernel side is ready for a > possible change of default. However, the new device naming confuses > some userland utilities. For example: > > pointyhat# write simon > write: /dev/398: No such file or directory > > simon was logged in on /dev/pts/398. > > killall -t also fails to parse the new device format: > > bento# ps -t pts/187 > PID TT STAT TIME COMMAND > 67734 187 Ss 0:00.04 /bin/csh > 72599 187 R+ 0:00.00 ps -t pts/187 > bento# killall -t pts/187 > killall: stat(/dev/ttypts/187): No such file or directory > > It would also be useful if ps -t recognized a numeric argument as > magic and converted it to add the pts/. It already appears to do the > converse when displaying the TTY, as you can see above. > > There are probably other utilities also affected. Patch for ps (if you didn't get one already): Index: ps.c =================================================================== RCS file: /usr/cvs/src/bin/ps/ps.c,v retrieving revision 1.110 diff -u -r1.110 ps.c --- ps.c 9 Feb 2005 17:37:38 -0000 1.110 +++ ps.c 16 Jul 2007 13:07:01 -0000 @@ -715,10 +715,11 @@ { const char *ttypath; struct stat sb; - char pathbuf[PATH_MAX], pathbuf2[PATH_MAX]; + char pathbuf[PATH_MAX], pathbuf2[PATH_MAX], pathbuf3[PATH_MAX]; ttypath = NULL; pathbuf2[0] = '\0'; + pathbuf3[0] = '\0'; switch (*elem) { case '/': ttypath = elem; @@ -745,21 +746,31 @@ ttypath = NULL; break; } + /* Check to see if /dev/pts/${elem} exists */ + strlcpy(pathbuf3, _PATH_DEV, sizeof(pathbuf2)); + strlcat(pathbuf3, "pts/", sizeof(pathbuf2)); + strlcat(pathbuf3, elem, sizeof(pathbuf2)); + if (stat(pathbuf3, &sb) == 0 && S_ISCHR(sb.st_mode)) { + /* No need to repeat stat() && S_ISCHR() checks */ + ttypath = NULL; + break; + } break; } if (ttypath) { if (stat(ttypath, &sb) == -1) { - if (pathbuf2[0] != '\0') - warn("%s and %s", pathbuf2, ttypath); + if (pathbuf3[0] != '\0') + warn("%s, %s, and %s", pathbuf3, pathbuf2, + ttypath); else warn("%s", ttypath); optfatal = 1; return (0); } if (!S_ISCHR(sb.st_mode)) { - if (pathbuf2[0] != '\0') - warnx("%s and %s: Not a terminal", pathbuf2, - ttypath); + if (pathbuf3[0] != '\0') + warnx("%s, %s, and %s: Not a terminal", + pathbuf3, pathbuf2, ttypath); else warnx("%s: Not a terminal", ttypath); optfatal = 1; -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Jul 16 14:57:46 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E69C816A417 for ; Mon, 16 Jul 2007 14:57:46 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.freebsd.org (Postfix) with ESMTP id 9D38013C4AC for ; Mon, 16 Jul 2007 14:57:46 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.7b8) with ESMTP id 196960699 for multiple; Mon, 16 Jul 2007 11:05:57 -0400 Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id l6GEvML9032514; Mon, 16 Jul 2007 10:57:38 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Mon, 16 Jul 2007 09:17:51 -0400 User-Agent: KMail/1.9.6 References: <20070617225824.GA88370@obiwan.tataz.chchile.org> In-Reply-To: <20070617225824.GA88370@obiwan.tataz.chchile.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200707160917.51941.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Mon, 16 Jul 2007 10:57:38 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/3681/Mon Jul 16 09:16:18 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx X-Server: High Performance Mail Server - http://surgemail.com r=1653887525 Cc: Jeremie Le Hen Subject: Re: RFC for wider rc.conf.d/ for jails X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Jul 2007 14:57:47 -0000 On Sunday 17 June 2007 06:58:25 pm Jeremie Le Hen wrote: > Hi, > > It is only possible to use /etc/rc.conf.d/${name}, where ${name} is the > command name in rc(8) scripts. For instance, one can use use > /etc/rc.conf.d/named thanks to /etc/rc.d/named. However it is not > possible to use /etc/rc.conf.d/foo because command "foo" is not provided > by any rc.d script. > > I would like to extend this behaviour for /etc/rc.d/jail in order to > be able to have one file per jail. It would require to either modify > rc.subr or hack up etc/rc.d/jail to include some additional files. > I am thinking about the following layout: > > % # cat rc.conf.d/jail > % jail_list="mail www" > % # cat rc.conf.d/jail.mail > % [...] # "mail" jail configuration variables. > % # cat rc.conf.d/jail.www > % [...] # "www" jail configuration variables. Maybe instead /etc/jail/mail, etc.? I'd rather not overload /etc/rc.conf.d since it already has a well-defined meaning. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Jul 16 14:57:55 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CC75D16A40F for ; Mon, 16 Jul 2007 14:57:55 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.freebsd.org (Postfix) with ESMTP id 7F8E113C4B6 for ; Mon, 16 Jul 2007 14:57:55 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.7b8) with ESMTP id 196960709 for multiple; Mon, 16 Jul 2007 11:05:59 -0400 Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id l6GEvMLA032514; Mon, 16 Jul 2007 10:57:40 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Mon, 16 Jul 2007 10:32:21 -0400 User-Agent: KMail/1.9.6 References: <20070619191203.GA1167@turion.vk2pj.dyndns.org> In-Reply-To: <20070619191203.GA1167@turion.vk2pj.dyndns.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200707161032.22207.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Mon, 16 Jul 2007 10:57:40 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/3681/Mon Jul 16 09:16:18 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx X-Server: High Performance Mail Server - http://surgemail.com r=1653887525 Cc: Peter Jeremy Subject: Re: Panic in callout_reset() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Jul 2007 14:57:55 -0000 On Tuesday 19 June 2007 03:12:03 pm Peter Jeremy wrote: > Running: FreeBSD 7.0-CURRENT #5: Sat Jun 9 18:29:40 EST 2007 > root@server.vk2pj.dyndns.org:/var/obj/k7/usr/src/sys/server > Panic String: Bad tailq NEXT(0xcce421a8->tqh_last) != NULL > > #0 doadump () at pcpu.h:195 > #1 0xc04524a9 in db_fncall (dummy1=0xc0576aa2, dummy2=0x0, dummy3=0x1, dummy4=0xd3b23a3c "") > at /usr/src/sys/ddb/db_command.c:486 > #2 0xc0452a15 in db_command_loop () at /usr/src/sys/ddb/db_command.c:401 > #3 0xc0454195 in db_trap (type=0x3, code=0x0) at /usr/src/sys/ddb/db_main.c:222 > #4 0xc0576943 in kdb_trap (type=0x3, code=0x0, tf=0xd3b23bd4) at /usr/src/sys/kern/subr_kdb.c:502 > #5 0xc06d4d4b in trap (frame=0xd3b23bd4) at /usr/src/sys/i386/i386/trap.c:620 > #6 0xc06c21db in calltrap () at /usr/src/sys/i386/i386/exception.s:139 > #7 0xc0576aa2 in kdb_enter (msg=0xc0719d31 "panic") at cpufunc.h:60 > #8 0xc0550035 in panic (fmt=0xc06fdb26 "Bad tailq NEXT(%p->tqh_last) != NULL") > at /usr/src/sys/kern/kern_shutdown.c:547 > #9 0xc056180a in callout_reset (c=0xc07ec000, to_ticks=0xa, ftn=0xc063fd30 , arg=0x0) > at /usr/src/sys/kern/kern_timeout.c:477 > #10 0xc063fde4 in nfsrv_timer (arg=0x0) at /usr/src/sys/nfsserver/nfs_srvsock.c:815 > #11 0xc0561f1e in softclock (dummy=0x0) at /usr/src/sys/kern/kern_timeout.c:280 > #12 0xc0534485 in ithread_loop (arg=0xc2926670) at /usr/src/sys/kern/kern_intr.c:1036 > #13 0xc0531a57 in fork_exit (callout=0xc05342d0 , arg=0xc2926670, frame=0xd3b23d38) > at /usr/src/sys/kern/kern_fork.c:787 > #14 0xc06c2250 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:205 > > 'c' in callout_reset looks like: > (kgdb) p *c > $1 = { > c_links = { > sle = { > sle_next = 0xc07e5e08 > }, > tqe = { > tqe_next = 0xc07e5e08, > tqe_prev = 0xcce42158 > } > }, > c_time = 0x3230ae73, > c_arg = 0x0, > c_func = 0xc063fd30 , > c_mtx = 0x0, > c_flags = 0x16 > } > > (kgdb) p *$1.c_links.tqe.tqe_next > $3 = { > c_links = { > sle = { > sle_next = 0x0 > }, > tqe = { > tqe_next = 0x0, > tqe_prev = 0xcce42158 > } > }, > c_time = 0x3230ae69, > c_arg = 0x0, > c_func = 0xc0605f80 , > c_mtx = 0x0, > c_flags = 0x16 > } > (kgdb) p *$1.c_links.tqe.tqe_prev > $5 = (struct callout *) 0xc07e5e08 > > Any suggestions? The panic is because the callout is already on a list. Maybe try moving the NFSD_UNLOCK() in nfsrv_timer() after the callout_reset(). -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Jul 16 14:58:14 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D242116A403; Mon, 16 Jul 2007 14:58:14 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.freebsd.org (Postfix) with ESMTP id 75C2313C4B2; Mon, 16 Jul 2007 14:58:14 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.7b8) with ESMTP id 196960712 for multiple; Mon, 16 Jul 2007 11:06:01 -0400 Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id l6GEvMLB032514; Mon, 16 Jul 2007 10:57:42 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: Ivan Voras Date: Mon, 16 Jul 2007 10:49:27 -0400 User-Agent: KMail/1.9.6 References: <200707160755.14498.jhb@freebsd.org> <469B6F1C.6020605@fer.hr> In-Reply-To: <469B6F1C.6020605@fer.hr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200707161049.27779.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Mon, 16 Jul 2007 10:57:42 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/3681/Mon Jul 16 09:16:18 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx X-Server: High Performance Mail Server - http://surgemail.com r=1653887525 Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: Debugging times X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Jul 2007 14:58:14 -0000 On Monday 16 July 2007 09:14:04 am Ivan Voras wrote: > John Baldwin wrote: > > > It's more that we use the filesystem's timestamp as a way to validate the > > timestamp from the RTC and to do a fixup if the RTC appears to be dead. > > Why not use something that doesn't depend on external factors, like > kernel build time (AFAIK it's embedded somewhere - at least it's written > on boot)? This way people using non-UFS file systems wouldn't get bitten. The kernel build time isn't updated if you leave a machine up for 2 years, but the filesystem mount time is. Also, the kernel build time is not stored in a raw date format, but as part of a string, so you'd have to import strftime(3) into the kernel. The kernel build time is also localized, so you'd have to import the timezone database into the kernel as well. This Would Be Bad (tm). -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Jul 16 15:14:23 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EAD3216A405; Mon, 16 Jul 2007 15:14:23 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.freebsd.org (Postfix) with ESMTP id 7C96613C428; Mon, 16 Jul 2007 15:14:23 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.7b8) with ESMTP id 196960681 for multiple; Mon, 16 Jul 2007 11:05:52 -0400 Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id l6GEvML7032514; Mon, 16 Jul 2007 10:57:31 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Mon, 16 Jul 2007 08:50:44 -0400 User-Agent: KMail/1.9.6 References: <20070617024935.GU4602@funkthat.com> <20070617053746.GV4602@funkthat.com> <20070616.235659.-1947354616.imp@bsdimp.com> In-Reply-To: <20070616.235659.-1947354616.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200707160850.46259.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Mon, 16 Jul 2007 10:57:32 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/3681/Mon Jul 16 09:16:18 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx X-Server: High Performance Mail Server - http://surgemail.com r=1653887525 Cc: gurney_j@resnet.uoregon.edu, current@freebsd.org, wsk@gddsn.org.cn, mobile@freebsd.org, simokawa@freebsd.org, "M. Warner Losh" Subject: Re: kernel panic with pccard insert on recent 7.0 CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2007 15:14:24 -0000 On Sunday 17 June 2007 01:56:59 am M. Warner Losh wrote: > In message: <20070617053746.GV4602@funkthat.com> > John-Mark Gurney writes: > : Warner Losh wrote this message on Sat, Jun 16, 2007 at 21:12 -0600: > : > In message: <20070617024935.GU4602@funkthat.com> > : > John-Mark Gurney writes: > : > : Warner Losh wrote this message on Sat, Jun 16, 2007 at 17:33 -0600: > : > : > Also, I'm unclear on the difference between FILTER_STRAY and > : > : > FILTER_HANDLED. > : > : > : > : The interrupt filter is suppose to return one of FILTER_STRAY or > : > : FILTER_HANDLED... If you _HANDLED it return that, otherwise return > : > : _STRAY... If you need to schedule the ithread, return _HANDLED or'd > : > : with _SCHEDULE_THREAD... > : > > : > Will _HANDLED cause all the other handlers to not get called, or just > : > the stray interrupt code from not happening? > : > : It will cause the remaining (not yet called) handlers not to get called... > > I'm not sure that's right, especially for edge triggered devices.\ They shouldn't share interrupts then. Do we support shared interrupts on edge triggered devices? > : intr_event_handle calls intr_filter_loop which will return on the first > : non-_STRAY handler and return it... Which intr_event_handle eoi's... > : > : It looks like this code is designed for level triggered interrupts and > : not edge triggered... > > Yes. I'm pretty sure that's wrong. All ISA and PC Card devices use > edge triggered interrupts. Also, it is inefficient for level > triggered interrupts, since two interrupt sources on the same > interrupt may trigger at about the same time... It works fine since the second device will interrupt again and we will fall through to its routine on the second interrupt. The idea is that simultaneous interrupts are rare enough that it is worth optimizing the common case. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Jul 16 15:16:31 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D65EE16A401; Mon, 16 Jul 2007 15:16:31 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 8504513C48E; Mon, 16 Jul 2007 15:16:31 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.13.8/8.13.4) with ESMTP id l6GFDDku030652; Mon, 16 Jul 2007 09:13:13 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Mon, 16 Jul 2007 09:13:15 -0600 (MDT) Message-Id: <20070716.091315.-432838580.imp@bsdimp.com> To: jhb@freebsd.org From: "M. Warner Losh" In-Reply-To: <200707160850.46259.jhb@freebsd.org> References: <20070617053746.GV4602@funkthat.com> <20070616.235659.-1947354616.imp@bsdimp.com> <200707160850.46259.jhb@freebsd.org> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Mon, 16 Jul 2007 09:13:14 -0600 (MDT) Cc: gurney_j@resnet.uoregon.edu, current@freebsd.org, wsk@gddsn.org.cn, freebsd-current@freebsd.org, mobile@freebsd.org, simokawa@freebsd.org Subject: Re: kernel panic with pccard insert on recent 7.0 CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2007 15:16:32 -0000 In message: <200707160850.46259.jhb@freebsd.org> John Baldwin writes: : On Sunday 17 June 2007 01:56:59 am M. Warner Losh wrote: : > In message: <20070617053746.GV4602@funkthat.com> : > John-Mark Gurney writes: : > : Warner Losh wrote this message on Sat, Jun 16, 2007 at 21:12 -0600: : > : > In message: <20070617024935.GU4602@funkthat.com> : > : > John-Mark Gurney writes: : > : > : Warner Losh wrote this message on Sat, Jun 16, 2007 at 17:33 -0600: : > : > : > Also, I'm unclear on the difference between FILTER_STRAY and : > : > : > FILTER_HANDLED. : > : > : : > : > : The interrupt filter is suppose to return one of FILTER_STRAY or : > : > : FILTER_HANDLED... If you _HANDLED it return that, otherwise return : > : > : _STRAY... If you need to schedule the ithread, return _HANDLED or'd : > : > : with _SCHEDULE_THREAD... : > : > : > : > Will _HANDLED cause all the other handlers to not get called, or just : > : > the stray interrupt code from not happening? : > : : > : It will cause the remaining (not yet called) handlers not to get called... : > : > I'm not sure that's right, especially for edge triggered devices.\ : : They shouldn't share interrupts then. Do we support shared interrupts on edge : triggered devices? We support sharing interrupts on edge triggered devices. At least it has worked on FreeBSD 2.2.1 through 6.2. We have to continue to support it, and to do that, we can't have HANDLED stop processing. It is a sad fact of life, but we have to continue to support that. As an aside, some ISA hardware cannot support sharing of interrupts, but simple modification of the drivers allows one to share ISA interrupts. My company has been doing this successfully for about 12 years, and using FreeBSD to do it for at least the past 10 years. : > : intr_event_handle calls intr_filter_loop which will return on the first : > : non-_STRAY handler and return it... Which intr_event_handle eoi's... : > : : > : It looks like this code is designed for level triggered interrupts and : > : not edge triggered... : > : > Yes. I'm pretty sure that's wrong. All ISA and PC Card devices use : > edge triggered interrupts. Also, it is inefficient for level : > triggered interrupts, since two interrupt sources on the same : > interrupt may trigger at about the same time... : : It works fine since the second device will interrupt again and we will fall : through to its routine on the second interrupt. The idea is that : simultaneous interrupts are rare enough that it is worth optimizing the : common case. Actually, PC Card devices aren't necessarily edge triggered, but can be either edge triggered or level triggered. They can live in bridges that are either Edge triggered or level triggered depending on the topology of the bus they live on. In any event, the current code is incorrect and needs to be fixed. Warner From owner-freebsd-current@FreeBSD.ORG Mon Jul 16 15:16:32 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D65EE16A401; Mon, 16 Jul 2007 15:16:31 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 8504513C48E; Mon, 16 Jul 2007 15:16:31 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.13.8/8.13.4) with ESMTP id l6GFDDku030652; Mon, 16 Jul 2007 09:13:13 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Mon, 16 Jul 2007 09:13:15 -0600 (MDT) Message-Id: <20070716.091315.-432838580.imp@bsdimp.com> To: jhb@freebsd.org From: "M. Warner Losh" In-Reply-To: <200707160850.46259.jhb@freebsd.org> References: <20070617053746.GV4602@funkthat.com> <20070616.235659.-1947354616.imp@bsdimp.com> <200707160850.46259.jhb@freebsd.org> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Mon, 16 Jul 2007 09:13:14 -0600 (MDT) Cc: gurney_j@resnet.uoregon.edu, current@freebsd.org, wsk@gddsn.org.cn, freebsd-current@freebsd.org, mobile@freebsd.org, simokawa@freebsd.org Subject: Re: kernel panic with pccard insert on recent 7.0 CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2007 15:16:32 -0000 In message: <200707160850.46259.jhb@freebsd.org> John Baldwin writes: : On Sunday 17 June 2007 01:56:59 am M. Warner Losh wrote: : > In message: <20070617053746.GV4602@funkthat.com> : > John-Mark Gurney writes: : > : Warner Losh wrote this message on Sat, Jun 16, 2007 at 21:12 -0600: : > : > In message: <20070617024935.GU4602@funkthat.com> : > : > John-Mark Gurney writes: : > : > : Warner Losh wrote this message on Sat, Jun 16, 2007 at 17:33 -0600: : > : > : > Also, I'm unclear on the difference between FILTER_STRAY and : > : > : > FILTER_HANDLED. : > : > : : > : > : The interrupt filter is suppose to return one of FILTER_STRAY or : > : > : FILTER_HANDLED... If you _HANDLED it return that, otherwise return : > : > : _STRAY... If you need to schedule the ithread, return _HANDLED or'd : > : > : with _SCHEDULE_THREAD... : > : > : > : > Will _HANDLED cause all the other handlers to not get called, or just : > : > the stray interrupt code from not happening? : > : : > : It will cause the remaining (not yet called) handlers not to get called... : > : > I'm not sure that's right, especially for edge triggered devices.\ : : They shouldn't share interrupts then. Do we support shared interrupts on edge : triggered devices? We support sharing interrupts on edge triggered devices. At least it has worked on FreeBSD 2.2.1 through 6.2. We have to continue to support it, and to do that, we can't have HANDLED stop processing. It is a sad fact of life, but we have to continue to support that. As an aside, some ISA hardware cannot support sharing of interrupts, but simple modification of the drivers allows one to share ISA interrupts. My company has been doing this successfully for about 12 years, and using FreeBSD to do it for at least the past 10 years. : > : intr_event_handle calls intr_filter_loop which will return on the first : > : non-_STRAY handler and return it... Which intr_event_handle eoi's... : > : : > : It looks like this code is designed for level triggered interrupts and : > : not edge triggered... : > : > Yes. I'm pretty sure that's wrong. All ISA and PC Card devices use : > edge triggered interrupts. Also, it is inefficient for level : > triggered interrupts, since two interrupt sources on the same : > interrupt may trigger at about the same time... : : It works fine since the second device will interrupt again and we will fall : through to its routine on the second interrupt. The idea is that : simultaneous interrupts are rare enough that it is worth optimizing the : common case. Actually, PC Card devices aren't necessarily edge triggered, but can be either edge triggered or level triggered. They can live in bridges that are either Edge triggered or level triggered depending on the topology of the bus they live on. In any event, the current code is incorrect and needs to be fixed. Warner From owner-freebsd-current@FreeBSD.ORG Mon Jul 16 15:39:09 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AAEDD16A400 for ; Mon, 16 Jul 2007 15:39:09 +0000 (UTC) (envelope-from craig@xfoil.gank.org) Received: from ion.gank.org (ion.gank.org [69.55.238.164]) by mx1.freebsd.org (Postfix) with ESMTP id 958EA13C4BB for ; Mon, 16 Jul 2007 15:39:07 +0000 (UTC) (envelope-from craig@xfoil.gank.org) Received: by ion.gank.org (Postfix, from userid 1001) id 420BA115C2; Mon, 16 Jul 2007 10:39:07 -0500 (CDT) Date: Mon, 16 Jul 2007 10:39:05 -0500 From: Craig Boston To: "Gelsema, P (Patrick) - FreeBSD" Message-ID: <20070716153904.GA22220@nowhere> Mail-Followup-To: Craig Boston , "Gelsema, P (Patrick) - FreeBSD" , freebsd-current@freebsd.org References: <1185.10.202.77.103.1184365805.squirrel@webmail.superhero.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1185.10.202.77.103.1184365805.squirrel@webmail.superhero.nl> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: Console output stops - machine keeps on working X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Jul 2007 15:39:09 -0000 On Sat, Jul 14, 2007 at 12:30:05AM +0200, Gelsema, P (Patrick) - FreeBSD wrote: > I am running FreeBSD 7-Current-200706. Everything seems to be detected > during boot and all goes ok until the moment the message that the fxp0 > link state changed to up. After that moment the console output stops. I > cannot get to other tty;s or get output running again. > > However the machine is responsive and I can log on by SSH remotely and do > everything as if I were at the console. When I login by typing blind at > the console and issue the reboot command or when I press the power off > button on the workstation the console shows output again (not any use as > it is then rebooting or powering off). > > See http://www.superhero.nl/messages.txt for the message output during boot. > > Anyone seen this kind of behaviour? I've been seeing this intermittently on a relatively recent -current. It seems to have started when I added KDB/DDB to the kernel config, but I haven't disabled it yet to see for sure if that's the culprit. Mine is an SMP (dual-core) system if it makes any difference. It stops right after a 'bge0: link up' message. Craig From owner-freebsd-current@FreeBSD.ORG Mon Jul 16 15:46:49 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 320FA16A400; Mon, 16 Jul 2007 15:46:49 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (adsl-75-1-14-242.dsl.scrm01.sbcglobal.net [75.1.14.242]) by mx1.freebsd.org (Postfix) with ESMTP id D76FE13C442; Mon, 16 Jul 2007 15:46:48 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id l6GFT2NR013319; Mon, 16 Jul 2007 08:29:06 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200707161529.l6GFT2NR013319@gw.catspoiler.org> Date: Mon, 16 Jul 2007 08:29:02 -0700 (PDT) From: Don Lewis To: Thomas.Sparrevohn@btinternet.com In-Reply-To: <200707161038.11140.Thomas.Sparrevohn@btinternet.com> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: freebsd-current@FreeBSD.org, itetcu@FreeBSD.org, almarrie@gmail.com Subject: Re: hang on reboot or shutdown with 7.0-CURRENT i386 on AMD X2 + GeForce 7050 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Jul 2007 15:46:49 -0000 On 16 Jul, Thomas Sparrevohn wrote: > On Monday 16 July 2007 09:11:50 Abdullah Ibn Hamad Al-Marri wrote: > >> >> I had the same problem, when I removed ehci from my kernel the >> problem went away, my mobo is ATI which is use in Acer 5102 WLMi and >> not nvidia. >> > I just tried disabling ehci as well - and it worked - the machine > rebooted and powered down just fine. So it seems that it has to do > with ehci - I try and see if I can pin it down Reboot and shutdown also started working on my machine when I disabled ehci. My Pentium-M laptop with an Intel chipset *does not* exhibit this problem with the identical kernel sources. From owner-freebsd-current@FreeBSD.ORG Mon Jul 16 16:09:40 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 63E0D16A412 for ; Mon, 16 Jul 2007 16:09:40 +0000 (UTC) (envelope-from nate@root.org) Received: from root.org (root.org [67.118.192.226]) by mx1.freebsd.org (Postfix) with ESMTP id 26B5B13C4C8 for ; Mon, 16 Jul 2007 16:09:40 +0000 (UTC) (envelope-from nate@root.org) Received: (qmail 55809 invoked from network); 16 Jul 2007 15:43:00 -0000 Received: from ppp-71-139-42-13.dsl.snfc21.pacbell.net (HELO ?10.0.0.15?) (nate-mail@71.139.42.13) by root.org with ESMTPA; 16 Jul 2007 15:43:00 -0000 Message-ID: <469B91FD.6080904@root.org> Date: Mon, 16 Jul 2007 08:42:53 -0700 From: Nate Lawson User-Agent: Thunderbird 2.0.0.4 (X11/20070620) MIME-Version: 1.0 To: John Baldwin References: <46735262.50601@root.org> <4673768D.1050805@root.org> <46741947.3050200@root.org> <200707160845.26597.jhb@freebsd.org> In-Reply-To: <200707160845.26597.jhb@freebsd.org> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: acpi@freebsd.org, freebsd-current@freebsd.org Subject: Re: smi speedstep patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Jul 2007 16:09:40 -0000 John Baldwin wrote: > On Saturday 16 June 2007 01:09:27 pm Nate Lawson wrote: >> Nate Lawson wrote: >>> Nate Lawson wrote: >>>> If you have a pentium 3 that works for speedstep, please try this patch. >>>> It fixes the PAE case. Compile-tested. >>> Hmm, I see it's no longer getting the physical address, just virtual. >>> So need to fix that part. >> Attached is the updated patch. It uses the low kernel map where P=V and >> fixes the callback. I just need someone who is using smi-speedstep >> (440bx chipset with pentium 3) to make sure the device still attaches. >> Patch should work on 6.x and 7.x. > > Why do you need a V == P page? I don't. I was just trying to choose a range where I was guaranteed there would be any mapping at all. Aren't there some physical regions (VGA, ISA hole) that don't have a mapping? Thus, it's best to ask for RAM at 1 MB+ unless the device has special requirements, right? BTW, this is already committed to -current. -Nate From owner-freebsd-current@FreeBSD.ORG Mon Jul 16 17:16:29 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2697A16A400; Mon, 16 Jul 2007 17:16:29 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.freebsd.org (Postfix) with ESMTP id AA0B713C4A5; Mon, 16 Jul 2007 17:16:28 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.7b8) with ESMTP id 196988391 for multiple; Mon, 16 Jul 2007 13:24:32 -0400 Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id l6GHG9DS033531; Mon, 16 Jul 2007 13:16:10 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: "M. Warner Losh" Date: Mon, 16 Jul 2007 12:51:08 -0400 User-Agent: KMail/1.9.6 References: <20070617053746.GV4602@funkthat.com> <200707160850.46259.jhb@freebsd.org> <20070716.091315.-432838580.imp@bsdimp.com> In-Reply-To: <20070716.091315.-432838580.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200707161251.09790.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Mon, 16 Jul 2007 13:16:13 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/3681/Mon Jul 16 09:16:18 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx X-Server: High Performance Mail Server - http://surgemail.com r=1653887525 Cc: gurney_j@resnet.uoregon.edu, current@freebsd.org, wsk@gddsn.org.cn, freebsd-current@freebsd.org, mobile@freebsd.org, simokawa@freebsd.org Subject: Re: kernel panic with pccard insert on recent 7.0 CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2007 17:16:29 -0000 On Monday 16 July 2007 11:13:15 am M. Warner Losh wrote: > In message: <200707160850.46259.jhb@freebsd.org> > John Baldwin writes: > : On Sunday 17 June 2007 01:56:59 am M. Warner Losh wrote: > : > In message: <20070617053746.GV4602@funkthat.com> > : > John-Mark Gurney writes: > : > : Warner Losh wrote this message on Sat, Jun 16, 2007 at 21:12 -0600: > : > : > In message: <20070617024935.GU4602@funkthat.com> > : > : > John-Mark Gurney writes: > : > : > : Warner Losh wrote this message on Sat, Jun 16, 2007 at 17:33 -0600: > : > : > : > Also, I'm unclear on the difference between FILTER_STRAY and > : > : > : > FILTER_HANDLED. > : > : > : > : > : > : The interrupt filter is suppose to return one of FILTER_STRAY or > : > : > : FILTER_HANDLED... If you _HANDLED it return that, otherwise return > : > : > : _STRAY... If you need to schedule the ithread, return _HANDLED or'd > : > : > : with _SCHEDULE_THREAD... > : > : > > : > : > Will _HANDLED cause all the other handlers to not get called, or just > : > : > the stray interrupt code from not happening? > : > : > : > : It will cause the remaining (not yet called) handlers not to get called... > : > > : > I'm not sure that's right, especially for edge triggered devices.\ > : > : They shouldn't share interrupts then. Do we support shared interrupts on edge > : triggered devices? > > We support sharing interrupts on edge triggered devices. At least it > has worked on FreeBSD 2.2.1 through 6.2. We have to continue to > support it, and to do that, we can't have HANDLED stop processing. > > It is a sad fact of life, but we have to continue to support that. > > As an aside, some ISA hardware cannot support sharing of interrupts, > but simple modification of the drivers allows one to share ISA > interrupts. My company has been doing this successfully for about 12 > years, and using FreeBSD to do it for at least the past 10 years. Are there any edge triggered interrupts that aren't hooked up to an edge triggered interrupt pin (like a pin on an 8259A that is set to be edge triggered in the ELCR)? We know if an interrupt source is edge or level and can act appropriately in the low-level code. > : > : intr_event_handle calls intr_filter_loop which will return on the first > : > : non-_STRAY handler and return it... Which intr_event_handle eoi's... > : > : > : > : It looks like this code is designed for level triggered interrupts and > : > : not edge triggered... > : > > : > Yes. I'm pretty sure that's wrong. All ISA and PC Card devices use > : > edge triggered interrupts. Also, it is inefficient for level > : > triggered interrupts, since two interrupt sources on the same > : > interrupt may trigger at about the same time... > : > : It works fine since the second device will interrupt again and we will fall > : through to its routine on the second interrupt. The idea is that > : simultaneous interrupts are rare enough that it is worth optimizing the > : common case. > > Actually, PC Card devices aren't necessarily edge triggered, but can > be either edge triggered or level triggered. They can live in bridges > that are either Edge triggered or level triggered depending on the > topology of the bus they live on. > > In any event, the current code is incorrect and needs to be fixed. It's a perfectly fine optimization for machines where level interrupts are shared and so I'd rather think about this and not just throw it out. So what happens when you stick a pccard in a PCI bridge whose upstream interrupt is a level-triggered PCI interrupt. Is the interrupt that the OS sees edge or level? -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Jul 16 17:16:29 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2697A16A400; Mon, 16 Jul 2007 17:16:29 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.freebsd.org (Postfix) with ESMTP id AA0B713C4A5; Mon, 16 Jul 2007 17:16:28 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.7b8) with ESMTP id 196988391 for multiple; Mon, 16 Jul 2007 13:24:32 -0400 Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id l6GHG9DS033531; Mon, 16 Jul 2007 13:16:10 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: "M. Warner Losh" Date: Mon, 16 Jul 2007 12:51:08 -0400 User-Agent: KMail/1.9.6 References: <20070617053746.GV4602@funkthat.com> <200707160850.46259.jhb@freebsd.org> <20070716.091315.-432838580.imp@bsdimp.com> In-Reply-To: <20070716.091315.-432838580.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200707161251.09790.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Mon, 16 Jul 2007 13:16:13 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/3681/Mon Jul 16 09:16:18 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx X-Server: High Performance Mail Server - http://surgemail.com r=1653887525 Cc: gurney_j@resnet.uoregon.edu, current@freebsd.org, wsk@gddsn.org.cn, freebsd-current@freebsd.org, mobile@freebsd.org, simokawa@freebsd.org Subject: Re: kernel panic with pccard insert on recent 7.0 CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2007 17:16:29 -0000 On Monday 16 July 2007 11:13:15 am M. Warner Losh wrote: > In message: <200707160850.46259.jhb@freebsd.org> > John Baldwin writes: > : On Sunday 17 June 2007 01:56:59 am M. Warner Losh wrote: > : > In message: <20070617053746.GV4602@funkthat.com> > : > John-Mark Gurney writes: > : > : Warner Losh wrote this message on Sat, Jun 16, 2007 at 21:12 -0600: > : > : > In message: <20070617024935.GU4602@funkthat.com> > : > : > John-Mark Gurney writes: > : > : > : Warner Losh wrote this message on Sat, Jun 16, 2007 at 17:33 -0600: > : > : > : > Also, I'm unclear on the difference between FILTER_STRAY and > : > : > : > FILTER_HANDLED. > : > : > : > : > : > : The interrupt filter is suppose to return one of FILTER_STRAY or > : > : > : FILTER_HANDLED... If you _HANDLED it return that, otherwise return > : > : > : _STRAY... If you need to schedule the ithread, return _HANDLED or'd > : > : > : with _SCHEDULE_THREAD... > : > : > > : > : > Will _HANDLED cause all the other handlers to not get called, or just > : > : > the stray interrupt code from not happening? > : > : > : > : It will cause the remaining (not yet called) handlers not to get called... > : > > : > I'm not sure that's right, especially for edge triggered devices.\ > : > : They shouldn't share interrupts then. Do we support shared interrupts on edge > : triggered devices? > > We support sharing interrupts on edge triggered devices. At least it > has worked on FreeBSD 2.2.1 through 6.2. We have to continue to > support it, and to do that, we can't have HANDLED stop processing. > > It is a sad fact of life, but we have to continue to support that. > > As an aside, some ISA hardware cannot support sharing of interrupts, > but simple modification of the drivers allows one to share ISA > interrupts. My company has been doing this successfully for about 12 > years, and using FreeBSD to do it for at least the past 10 years. Are there any edge triggered interrupts that aren't hooked up to an edge triggered interrupt pin (like a pin on an 8259A that is set to be edge triggered in the ELCR)? We know if an interrupt source is edge or level and can act appropriately in the low-level code. > : > : intr_event_handle calls intr_filter_loop which will return on the first > : > : non-_STRAY handler and return it... Which intr_event_handle eoi's... > : > : > : > : It looks like this code is designed for level triggered interrupts and > : > : not edge triggered... > : > > : > Yes. I'm pretty sure that's wrong. All ISA and PC Card devices use > : > edge triggered interrupts. Also, it is inefficient for level > : > triggered interrupts, since two interrupt sources on the same > : > interrupt may trigger at about the same time... > : > : It works fine since the second device will interrupt again and we will fall > : through to its routine on the second interrupt. The idea is that > : simultaneous interrupts are rare enough that it is worth optimizing the > : common case. > > Actually, PC Card devices aren't necessarily edge triggered, but can > be either edge triggered or level triggered. They can live in bridges > that are either Edge triggered or level triggered depending on the > topology of the bus they live on. > > In any event, the current code is incorrect and needs to be fixed. It's a perfectly fine optimization for machines where level interrupts are shared and so I'd rather think about this and not just throw it out. So what happens when you stick a pccard in a PCI bridge whose upstream interrupt is a level-triggered PCI interrupt. Is the interrupt that the OS sees edge or level? -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Jul 16 17:16:44 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 54FC616A49E; Mon, 16 Jul 2007 17:16:44 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.freebsd.org (Postfix) with ESMTP id EFFD313C491; Mon, 16 Jul 2007 17:16:43 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.7b8) with ESMTP id 196988398 for multiple; Mon, 16 Jul 2007 13:24:34 -0400 Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id l6GHG9DT033531; Mon, 16 Jul 2007 13:16:14 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: Nate Lawson Date: Mon, 16 Jul 2007 12:52:46 -0400 User-Agent: KMail/1.9.6 References: <46735262.50601@root.org> <200707160845.26597.jhb@freebsd.org> <469B91FD.6080904@root.org> In-Reply-To: <469B91FD.6080904@root.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200707161252.46540.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Mon, 16 Jul 2007 13:16:15 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/3681/Mon Jul 16 09:16:18 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx X-Server: High Performance Mail Server - http://surgemail.com r=1653887525 Cc: acpi@freebsd.org, freebsd-current@freebsd.org Subject: Re: smi speedstep patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Jul 2007 17:16:44 -0000 On Monday 16 July 2007 11:42:53 am Nate Lawson wrote: > John Baldwin wrote: > > On Saturday 16 June 2007 01:09:27 pm Nate Lawson wrote: > >> Nate Lawson wrote: > >>> Nate Lawson wrote: > >>>> If you have a pentium 3 that works for speedstep, please try this patch. > >>>> It fixes the PAE case. Compile-tested. > >>> Hmm, I see it's no longer getting the physical address, just virtual. > >>> So need to fix that part. > >> Attached is the updated patch. It uses the low kernel map where P=V and > >> fixes the callback. I just need someone who is using smi-speedstep > >> (440bx chipset with pentium 3) to make sure the device still attaches. > >> Patch should work on 6.x and 7.x. > > > > Why do you need a V == P page? > > I don't. I was just trying to choose a range where I was guaranteed > there would be any mapping at all. Aren't there some physical regions > (VGA, ISA hole) that don't have a mapping? Thus, it's best to ask for > RAM at 1 MB+ unless the device has special requirements, right? > > BTW, this is already committed to -current. What do you mean by a range that doesn't have a "mapping"? Do you mean you want bus_dma to give you memory not already in use? Why would it do that? :) Why can't you just allocate any buffer under 4GB? -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Jul 16 17:28:42 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D72FB16A4DA; Mon, 16 Jul 2007 17:28:41 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 2E46A13C4BE; Mon, 16 Jul 2007 17:28:34 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.13.8/8.13.4) with ESMTP id l6GHRaJv031978; Mon, 16 Jul 2007 11:27:36 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Mon, 16 Jul 2007 11:27:40 -0600 (MDT) Message-Id: <20070716.112740.-749248234.imp@bsdimp.com> To: jhb@freebsd.org From: "M. Warner Losh" In-Reply-To: <200707161251.09790.jhb@freebsd.org> References: <200707160850.46259.jhb@freebsd.org> <20070716.091315.-432838580.imp@bsdimp.com> <200707161251.09790.jhb@freebsd.org> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Mon, 16 Jul 2007 11:27:37 -0600 (MDT) Cc: gurney_j@resnet.uoregon.edu, current@freebsd.org, wsk@gddsn.org.cn, freebsd-current@freebsd.org, mobile@freebsd.org, simokawa@freebsd.org Subject: Re: kernel panic with pccard insert on recent 7.0 CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2007 17:28:42 -0000 In message: <200707161251.09790.jhb@freebsd.org> John Baldwin writes: : On Monday 16 July 2007 11:13:15 am M. Warner Losh wrote: : > In message: <200707160850.46259.jhb@freebsd.org> : > John Baldwin writes: : > : On Sunday 17 June 2007 01:56:59 am M. Warner Losh wrote: : > : > In message: <20070617053746.GV4602@funkthat.com> : > : > John-Mark Gurney writes: : > : > : Warner Losh wrote this message on Sat, Jun 16, 2007 at 21:12 -0600: : > : > : > In message: <20070617024935.GU4602@funkthat.com> : > : > : > John-Mark Gurney writes: : > : > : > : Warner Losh wrote this message on Sat, Jun 16, 2007 at : 17:33 -0600: : > : > : > : > Also, I'm unclear on the difference between FILTER_STRAY and : > : > : > : > FILTER_HANDLED. : > : > : > : : > : > : > : The interrupt filter is suppose to return one of FILTER_STRAY or : > : > : > : FILTER_HANDLED... If you _HANDLED it return that, otherwise : return : > : > : > : _STRAY... If you need to schedule the ithread, return _HANDLED : or'd : > : > : > : with _SCHEDULE_THREAD... : > : > : > : > : > : > Will _HANDLED cause all the other handlers to not get called, or : just : > : > : > the stray interrupt code from not happening? : > : > : : > : > : It will cause the remaining (not yet called) handlers not to get : called... : > : > : > : > I'm not sure that's right, especially for edge triggered devices.\ : > : : > : They shouldn't share interrupts then. Do we support shared interrupts on : edge : > : triggered devices? : > : > We support sharing interrupts on edge triggered devices. At least it : > has worked on FreeBSD 2.2.1 through 6.2. We have to continue to : > support it, and to do that, we can't have HANDLED stop processing. : > : > It is a sad fact of life, but we have to continue to support that. : > : > As an aside, some ISA hardware cannot support sharing of interrupts, : > but simple modification of the drivers allows one to share ISA : > interrupts. My company has been doing this successfully for about 12 : > years, and using FreeBSD to do it for at least the past 10 years. : : Are there any edge triggered interrupts that aren't hooked up to an edge : triggered interrupt pin (like a pin on an 8259A that is set to be edge : triggered in the ELCR)? We know if an interrupt source is edge or level and : can act appropriately in the low-level code. I don't think there are any. The only case that leaps to mind is the whole level vs edge stuff in pccard, but I think that reflects the underlying bus architecture for the bridge attachment. So long as we can share edge triggered interrupts, and all the ISRs always get called, then the case I'm worried about goes away. : > : > : intr_event_handle calls intr_filter_loop which will return on the : first : > : > : non-_STRAY handler and return it... Which intr_event_handle eoi's... : > : > : : > : > : It looks like this code is designed for level triggered interrupts and : > : > : not edge triggered... : > : > : > : > Yes. I'm pretty sure that's wrong. All ISA and PC Card devices use : > : > edge triggered interrupts. Also, it is inefficient for level : > : > triggered interrupts, since two interrupt sources on the same : > : > interrupt may trigger at about the same time... : > : : > : It works fine since the second device will interrupt again and we will : fall : > : through to its routine on the second interrupt. The idea is that : > : simultaneous interrupts are rare enough that it is worth optimizing the : > : common case. : > : > Actually, PC Card devices aren't necessarily edge triggered, but can : > be either edge triggered or level triggered. They can live in bridges : > that are either Edge triggered or level triggered depending on the : > topology of the bus they live on. : > : > In any event, the current code is incorrect and needs to be fixed. : : It's a perfectly fine optimization for machines where level interrupts are : shared and so I'd rather think about this and not just throw it out. So what : happens when you stick a pccard in a PCI bridge whose upstream interrupt is a : level-triggered PCI interrupt. Is the interrupt that the OS sees edge or : level? The PC Card code sets the card to do level triggered interrupts if possible. It falls back to a level trigger emulation if it can't. There is a register that clears once it is read to deassert the interrupt, so that should work... It just seems like a pessimization for the case you want to optimize, but it boils down to is it faster to call all the shared interrupt handlers all the time, or is it faster to do a context switch, averaged over all the cases we have to consider. Warner From owner-freebsd-current@FreeBSD.ORG Mon Jul 16 17:28:42 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D72FB16A4DA; Mon, 16 Jul 2007 17:28:41 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 2E46A13C4BE; Mon, 16 Jul 2007 17:28:34 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.13.8/8.13.4) with ESMTP id l6GHRaJv031978; Mon, 16 Jul 2007 11:27:36 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Mon, 16 Jul 2007 11:27:40 -0600 (MDT) Message-Id: <20070716.112740.-749248234.imp@bsdimp.com> To: jhb@freebsd.org From: "M. Warner Losh" In-Reply-To: <200707161251.09790.jhb@freebsd.org> References: <200707160850.46259.jhb@freebsd.org> <20070716.091315.-432838580.imp@bsdimp.com> <200707161251.09790.jhb@freebsd.org> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Mon, 16 Jul 2007 11:27:37 -0600 (MDT) Cc: gurney_j@resnet.uoregon.edu, current@freebsd.org, wsk@gddsn.org.cn, freebsd-current@freebsd.org, mobile@freebsd.org, simokawa@freebsd.org Subject: Re: kernel panic with pccard insert on recent 7.0 CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2007 17:28:42 -0000 In message: <200707161251.09790.jhb@freebsd.org> John Baldwin writes: : On Monday 16 July 2007 11:13:15 am M. Warner Losh wrote: : > In message: <200707160850.46259.jhb@freebsd.org> : > John Baldwin writes: : > : On Sunday 17 June 2007 01:56:59 am M. Warner Losh wrote: : > : > In message: <20070617053746.GV4602@funkthat.com> : > : > John-Mark Gurney writes: : > : > : Warner Losh wrote this message on Sat, Jun 16, 2007 at 21:12 -0600: : > : > : > In message: <20070617024935.GU4602@funkthat.com> : > : > : > John-Mark Gurney writes: : > : > : > : Warner Losh wrote this message on Sat, Jun 16, 2007 at : 17:33 -0600: : > : > : > : > Also, I'm unclear on the difference between FILTER_STRAY and : > : > : > : > FILTER_HANDLED. : > : > : > : : > : > : > : The interrupt filter is suppose to return one of FILTER_STRAY or : > : > : > : FILTER_HANDLED... If you _HANDLED it return that, otherwise : return : > : > : > : _STRAY... If you need to schedule the ithread, return _HANDLED : or'd : > : > : > : with _SCHEDULE_THREAD... : > : > : > : > : > : > Will _HANDLED cause all the other handlers to not get called, or : just : > : > : > the stray interrupt code from not happening? : > : > : : > : > : It will cause the remaining (not yet called) handlers not to get : called... : > : > : > : > I'm not sure that's right, especially for edge triggered devices.\ : > : : > : They shouldn't share interrupts then. Do we support shared interrupts on : edge : > : triggered devices? : > : > We support sharing interrupts on edge triggered devices. At least it : > has worked on FreeBSD 2.2.1 through 6.2. We have to continue to : > support it, and to do that, we can't have HANDLED stop processing. : > : > It is a sad fact of life, but we have to continue to support that. : > : > As an aside, some ISA hardware cannot support sharing of interrupts, : > but simple modification of the drivers allows one to share ISA : > interrupts. My company has been doing this successfully for about 12 : > years, and using FreeBSD to do it for at least the past 10 years. : : Are there any edge triggered interrupts that aren't hooked up to an edge : triggered interrupt pin (like a pin on an 8259A that is set to be edge : triggered in the ELCR)? We know if an interrupt source is edge or level and : can act appropriately in the low-level code. I don't think there are any. The only case that leaps to mind is the whole level vs edge stuff in pccard, but I think that reflects the underlying bus architecture for the bridge attachment. So long as we can share edge triggered interrupts, and all the ISRs always get called, then the case I'm worried about goes away. : > : > : intr_event_handle calls intr_filter_loop which will return on the : first : > : > : non-_STRAY handler and return it... Which intr_event_handle eoi's... : > : > : : > : > : It looks like this code is designed for level triggered interrupts and : > : > : not edge triggered... : > : > : > : > Yes. I'm pretty sure that's wrong. All ISA and PC Card devices use : > : > edge triggered interrupts. Also, it is inefficient for level : > : > triggered interrupts, since two interrupt sources on the same : > : > interrupt may trigger at about the same time... : > : : > : It works fine since the second device will interrupt again and we will : fall : > : through to its routine on the second interrupt. The idea is that : > : simultaneous interrupts are rare enough that it is worth optimizing the : > : common case. : > : > Actually, PC Card devices aren't necessarily edge triggered, but can : > be either edge triggered or level triggered. They can live in bridges : > that are either Edge triggered or level triggered depending on the : > topology of the bus they live on. : > : > In any event, the current code is incorrect and needs to be fixed. : : It's a perfectly fine optimization for machines where level interrupts are : shared and so I'd rather think about this and not just throw it out. So what : happens when you stick a pccard in a PCI bridge whose upstream interrupt is a : level-triggered PCI interrupt. Is the interrupt that the OS sees edge or : level? The PC Card code sets the card to do level triggered interrupts if possible. It falls back to a level trigger emulation if it can't. There is a register that clears once it is read to deassert the interrupt, so that should work... It just seems like a pessimization for the case you want to optimize, but it boils down to is it faster to call all the shared interrupt handlers all the time, or is it faster to do a context switch, averaged over all the cases we have to consider. Warner From owner-freebsd-current@FreeBSD.ORG Mon Jul 16 18:00:38 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3608716A40D; Mon, 16 Jul 2007 18:00:38 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.freebsd.org (Postfix) with ESMTP id B4A3013C4F8; Mon, 16 Jul 2007 18:00:37 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.7b8) with ESMTP id 196996799 for multiple; Mon, 16 Jul 2007 14:08:43 -0400 Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id l6GI0OMW034314; Mon, 16 Jul 2007 14:00:24 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: "M. Warner Losh" Date: Mon, 16 Jul 2007 13:59:43 -0400 User-Agent: KMail/1.9.6 References: <200707160850.46259.jhb@freebsd.org> <200707161251.09790.jhb@freebsd.org> <20070716.112740.-749248234.imp@bsdimp.com> In-Reply-To: <20070716.112740.-749248234.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200707161359.44056.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Mon, 16 Jul 2007 14:00:24 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/3682/Mon Jul 16 12:05:30 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx X-Server: High Performance Mail Server - http://surgemail.com r=1653887525 Cc: gurney_j@resnet.uoregon.edu, current@freebsd.org, wsk@gddsn.org.cn, freebsd-current@freebsd.org, mobile@freebsd.org, simokawa@freebsd.org Subject: Re: kernel panic with pccard insert on recent 7.0 CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2007 18:00:38 -0000 On Monday 16 July 2007 01:27:40 pm M. Warner Losh wrote: > In message: <200707161251.09790.jhb@freebsd.org> > John Baldwin writes: > : On Monday 16 July 2007 11:13:15 am M. Warner Losh wrote: > : > In message: <200707160850.46259.jhb@freebsd.org> > : > John Baldwin writes: > : > : On Sunday 17 June 2007 01:56:59 am M. Warner Losh wrote: > : > : > In message: <20070617053746.GV4602@funkthat.com> > : > : > John-Mark Gurney writes: > : > : > : Warner Losh wrote this message on Sat, Jun 16, 2007 at 21:12 -0600: > : > : > : > In message: <20070617024935.GU4602@funkthat.com> > : > : > : > John-Mark Gurney writes: > : > : > : > : Warner Losh wrote this message on Sat, Jun 16, 2007 at > : 17:33 -0600: > : > : > : > : > Also, I'm unclear on the difference between FILTER_STRAY and > : > : > : > : > FILTER_HANDLED. > : > : > : > : > : > : > : > : The interrupt filter is suppose to return one of FILTER_STRAY or > : > : > : > : FILTER_HANDLED... If you _HANDLED it return that, otherwise > : return > : > : > : > : _STRAY... If you need to schedule the ithread, return _HANDLED > : or'd > : > : > : > : with _SCHEDULE_THREAD... > : > : > : > > : > : > : > Will _HANDLED cause all the other handlers to not get called, or > : just > : > : > : > the stray interrupt code from not happening? > : > : > : > : > : > : It will cause the remaining (not yet called) handlers not to get > : called... > : > : > > : > : > I'm not sure that's right, especially for edge triggered devices.\ > : > : > : > : They shouldn't share interrupts then. Do we support shared interrupts on > : edge > : > : triggered devices? > : > > : > We support sharing interrupts on edge triggered devices. At least it > : > has worked on FreeBSD 2.2.1 through 6.2. We have to continue to > : > support it, and to do that, we can't have HANDLED stop processing. > : > > : > It is a sad fact of life, but we have to continue to support that. > : > > : > As an aside, some ISA hardware cannot support sharing of interrupts, > : > but simple modification of the drivers allows one to share ISA > : > interrupts. My company has been doing this successfully for about 12 > : > years, and using FreeBSD to do it for at least the past 10 years. > : > : Are there any edge triggered interrupts that aren't hooked up to an edge > : triggered interrupt pin (like a pin on an 8259A that is set to be edge > : triggered in the ELCR)? We know if an interrupt source is edge or level and > : can act appropriately in the low-level code. > > I don't think there are any. The only case that leaps to mind is the > whole level vs edge stuff in pccard, but I think that reflects the > underlying bus architecture for the bridge attachment. > > So long as we can share edge triggered interrupts, and all the ISRs > always get called, then the case I'm worried about goes away. > > : > : > : intr_event_handle calls intr_filter_loop which will return on the > : first > : > : > : non-_STRAY handler and return it... Which intr_event_handle eoi's... > : > : > : > : > : > : It looks like this code is designed for level triggered interrupts and > : > : > : not edge triggered... > : > : > > : > : > Yes. I'm pretty sure that's wrong. All ISA and PC Card devices use > : > : > edge triggered interrupts. Also, it is inefficient for level > : > : > triggered interrupts, since two interrupt sources on the same > : > : > interrupt may trigger at about the same time... > : > : > : > : It works fine since the second device will interrupt again and we will > : fall > : > : through to its routine on the second interrupt. The idea is that > : > : simultaneous interrupts are rare enough that it is worth optimizing the > : > : common case. > : > > : > Actually, PC Card devices aren't necessarily edge triggered, but can > : > be either edge triggered or level triggered. They can live in bridges > : > that are either Edge triggered or level triggered depending on the > : > topology of the bus they live on. > : > > : > In any event, the current code is incorrect and needs to be fixed. > : > : It's a perfectly fine optimization for machines where level interrupts are > : shared and so I'd rather think about this and not just throw it out. So what > : happens when you stick a pccard in a PCI bridge whose upstream interrupt is a > : level-triggered PCI interrupt. Is the interrupt that the OS sees edge or > : level? > > The PC Card code sets the card to do level triggered interrupts if > possible. It falls back to a level trigger emulation if it can't. > There is a register that clears once it is read to deassert the > interrupt, so that should work... > > It just seems like a pessimization for the case you want to optimize, > but it boils down to is it faster to call all the shared interrupt > handlers all the time, or is it faster to do a context switch, > averaged over all the cases we have to consider. Huh? Assuming you have two interrupt handlers with filters A and B that share an interrupt and only A has an interrupt to handle the difference is this: 1) Run A's handler, it claims the interrupt, so schedule A's ithread if requested and be done right away. 2) Run A's handler, then run B's handler, then schedule A's ithread if requested. So right away we avoid wasting time running B's handler just so it can return INTR_STRAY. Another thing that 1) let's us do is give A a private ithread but still let the interrupt code only have to schedule (and maybe preempt to) one ithread. (All the handlers w/o filters end up on a separate ithread, but each handler that has both a filter and a threaded handler would have its own thread.) The dedicated ithread doesn't need to enable an interrupt source when its done since it knows the filter has already squashed the interrupt on its own (either handling it or using a device-specific interrupt masking register), and the dedicated ithreads could in theory run concurrently (though with ithreads bound to the CPU they come in on this isn't likely). -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Jul 16 18:00:38 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3608716A40D; Mon, 16 Jul 2007 18:00:38 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.freebsd.org (Postfix) with ESMTP id B4A3013C4F8; Mon, 16 Jul 2007 18:00:37 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.7b8) with ESMTP id 196996799 for multiple; Mon, 16 Jul 2007 14:08:43 -0400 Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id l6GI0OMW034314; Mon, 16 Jul 2007 14:00:24 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: "M. Warner Losh" Date: Mon, 16 Jul 2007 13:59:43 -0400 User-Agent: KMail/1.9.6 References: <200707160850.46259.jhb@freebsd.org> <200707161251.09790.jhb@freebsd.org> <20070716.112740.-749248234.imp@bsdimp.com> In-Reply-To: <20070716.112740.-749248234.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200707161359.44056.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Mon, 16 Jul 2007 14:00:24 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/3682/Mon Jul 16 12:05:30 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx X-Server: High Performance Mail Server - http://surgemail.com r=1653887525 Cc: gurney_j@resnet.uoregon.edu, current@freebsd.org, wsk@gddsn.org.cn, freebsd-current@freebsd.org, mobile@freebsd.org, simokawa@freebsd.org Subject: Re: kernel panic with pccard insert on recent 7.0 CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2007 18:00:38 -0000 On Monday 16 July 2007 01:27:40 pm M. Warner Losh wrote: > In message: <200707161251.09790.jhb@freebsd.org> > John Baldwin writes: > : On Monday 16 July 2007 11:13:15 am M. Warner Losh wrote: > : > In message: <200707160850.46259.jhb@freebsd.org> > : > John Baldwin writes: > : > : On Sunday 17 June 2007 01:56:59 am M. Warner Losh wrote: > : > : > In message: <20070617053746.GV4602@funkthat.com> > : > : > John-Mark Gurney writes: > : > : > : Warner Losh wrote this message on Sat, Jun 16, 2007 at 21:12 -0600: > : > : > : > In message: <20070617024935.GU4602@funkthat.com> > : > : > : > John-Mark Gurney writes: > : > : > : > : Warner Losh wrote this message on Sat, Jun 16, 2007 at > : 17:33 -0600: > : > : > : > : > Also, I'm unclear on the difference between FILTER_STRAY and > : > : > : > : > FILTER_HANDLED. > : > : > : > : > : > : > : > : The interrupt filter is suppose to return one of FILTER_STRAY or > : > : > : > : FILTER_HANDLED... If you _HANDLED it return that, otherwise > : return > : > : > : > : _STRAY... If you need to schedule the ithread, return _HANDLED > : or'd > : > : > : > : with _SCHEDULE_THREAD... > : > : > : > > : > : > : > Will _HANDLED cause all the other handlers to not get called, or > : just > : > : > : > the stray interrupt code from not happening? > : > : > : > : > : > : It will cause the remaining (not yet called) handlers not to get > : called... > : > : > > : > : > I'm not sure that's right, especially for edge triggered devices.\ > : > : > : > : They shouldn't share interrupts then. Do we support shared interrupts on > : edge > : > : triggered devices? > : > > : > We support sharing interrupts on edge triggered devices. At least it > : > has worked on FreeBSD 2.2.1 through 6.2. We have to continue to > : > support it, and to do that, we can't have HANDLED stop processing. > : > > : > It is a sad fact of life, but we have to continue to support that. > : > > : > As an aside, some ISA hardware cannot support sharing of interrupts, > : > but simple modification of the drivers allows one to share ISA > : > interrupts. My company has been doing this successfully for about 12 > : > years, and using FreeBSD to do it for at least the past 10 years. > : > : Are there any edge triggered interrupts that aren't hooked up to an edge > : triggered interrupt pin (like a pin on an 8259A that is set to be edge > : triggered in the ELCR)? We know if an interrupt source is edge or level and > : can act appropriately in the low-level code. > > I don't think there are any. The only case that leaps to mind is the > whole level vs edge stuff in pccard, but I think that reflects the > underlying bus architecture for the bridge attachment. > > So long as we can share edge triggered interrupts, and all the ISRs > always get called, then the case I'm worried about goes away. > > : > : > : intr_event_handle calls intr_filter_loop which will return on the > : first > : > : > : non-_STRAY handler and return it... Which intr_event_handle eoi's... > : > : > : > : > : > : It looks like this code is designed for level triggered interrupts and > : > : > : not edge triggered... > : > : > > : > : > Yes. I'm pretty sure that's wrong. All ISA and PC Card devices use > : > : > edge triggered interrupts. Also, it is inefficient for level > : > : > triggered interrupts, since two interrupt sources on the same > : > : > interrupt may trigger at about the same time... > : > : > : > : It works fine since the second device will interrupt again and we will > : fall > : > : through to its routine on the second interrupt. The idea is that > : > : simultaneous interrupts are rare enough that it is worth optimizing the > : > : common case. > : > > : > Actually, PC Card devices aren't necessarily edge triggered, but can > : > be either edge triggered or level triggered. They can live in bridges > : > that are either Edge triggered or level triggered depending on the > : > topology of the bus they live on. > : > > : > In any event, the current code is incorrect and needs to be fixed. > : > : It's a perfectly fine optimization for machines where level interrupts are > : shared and so I'd rather think about this and not just throw it out. So what > : happens when you stick a pccard in a PCI bridge whose upstream interrupt is a > : level-triggered PCI interrupt. Is the interrupt that the OS sees edge or > : level? > > The PC Card code sets the card to do level triggered interrupts if > possible. It falls back to a level trigger emulation if it can't. > There is a register that clears once it is read to deassert the > interrupt, so that should work... > > It just seems like a pessimization for the case you want to optimize, > but it boils down to is it faster to call all the shared interrupt > handlers all the time, or is it faster to do a context switch, > averaged over all the cases we have to consider. Huh? Assuming you have two interrupt handlers with filters A and B that share an interrupt and only A has an interrupt to handle the difference is this: 1) Run A's handler, it claims the interrupt, so schedule A's ithread if requested and be done right away. 2) Run A's handler, then run B's handler, then schedule A's ithread if requested. So right away we avoid wasting time running B's handler just so it can return INTR_STRAY. Another thing that 1) let's us do is give A a private ithread but still let the interrupt code only have to schedule (and maybe preempt to) one ithread. (All the handlers w/o filters end up on a separate ithread, but each handler that has both a filter and a threaded handler would have its own thread.) The dedicated ithread doesn't need to enable an interrupt source when its done since it knows the filter has already squashed the interrupt on its own (either handling it or using a device-specific interrupt masking register), and the dedicated ithreads could in theory run concurrently (though with ithreads bound to the CPU they come in on this isn't likely). -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Jul 16 18:08:44 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0D98216A403 for ; Mon, 16 Jul 2007 18:08:44 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with SMTP id B514313C478 for ; Mon, 16 Jul 2007 18:08:43 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 2494 invoked by uid 399); 16 Jul 2007 18:08:42 -0000 Received: from localhost (HELO lap.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTP; 16 Jul 2007 18:08:42 -0000 X-Originating-IP: 127.0.0.1 Message-ID: <469BB428.1020200@FreeBSD.org> Date: Mon, 16 Jul 2007 11:08:40 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.4 (X11/20070617) MIME-Version: 1.0 To: Dmitry Morozovsky References: <20070419133550.GA65054@tirith.brixandersen.dk> <20070419200929.GA70735@tirith.brixandersen.dk> <4693BC3E.1050605@web.am> <200707110115.42139.pieter@degoeje.nl> <469417CB.7010705@FreeBSD.org> <4694AAF1.6050302@web.am> <46951CC2.5050602@FreeBSD.org> <20070716181242.S73148@woozle.rinet.ru> In-Reply-To: <20070716181242.S73148@woozle.rinet.ru> X-Enigmail-Version: 0.95.1 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Pieter de Goeje , Gaspar Chilingarov , freebsd-current@freebsd.org Subject: Re: RFT: bin/106642: [patch] Allow excluding certain files from mergemaster (8) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2007 18:08:44 -0000 Dmitry Morozovsky wrote: > On Wed, 11 Jul 2007, Doug Barton wrote: > > DB> > About pre-script which you suggested, there is another problem -- I MAY > DB> > have new scripts in /etc/rc.d, but NEVER change the system's scripts. > DB> > DB> Simple answer, don't do that. Put your scripts in /usr/local/etc/rc.d > DB> instead, and as of 6.1 and newer they will be included in the base > DB> rcorder. Therefore there will be no difference in when they are run. > DB> There is a default assumption that stuff in /etc/rc.d is the systems, > DB> and the systems only. Now that local scripts (including ports) are in > DB> the base rcorder, there is no reason not to do it that way. > > The first exclusion in mind would be scripts that should be running before > mounting file systems other than root... My recommendation in that scenario would be to play with the value of early_late_divider until you got something that worked for you. That's why I made it a variable. :) If there is a particular combination of things that have to happen that early_late_divider won't work for, I'd be interested in hearing that so that we could look at possibly adjusting the code if it's possible. Doug -- This .signature sanitized for your protection From owner-freebsd-current@FreeBSD.ORG Mon Jul 16 18:28:39 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 96E5216A400 for ; Mon, 16 Jul 2007 18:28:39 +0000 (UTC) (envelope-from braun.sven@googlemail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.171]) by mx1.freebsd.org (Postfix) with ESMTP id 2DB9413C4B8 for ; Mon, 16 Jul 2007 18:28:38 +0000 (UTC) (envelope-from braun.sven@googlemail.com) Received: by ug-out-1314.google.com with SMTP id o4so1163565uge for ; Mon, 16 Jul 2007 11:28:38 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=googlemail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Rbl/KaCgsXNSHNqQQz8uuztLPy4DywLlAT1QTanSF4D0UZ5/BYDr0EO+a2vl2v024ujhvq1MRO37BST/ZfT7I7+bxrvVTx5DDLVFZDnwWgqOhRrsEVRpUPCk57DAk8zxHgWaCD6HIjehJVU130jdgCpT/pKbFHvRZKoPuStuPjA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=bOgpJtgbza1i/eLAQWgzsUMG9AUp4PLsLrBCgF9tmu7RZxqp9KGWkwUxgD62sswRRBCnMSzsbnl0kpDVEQioLs6iemdQP/PxWRLYtOKF8RUqzvVYv4kbsolBYR+C/c9WH28VziufS0UqX/aalAe5KBqXA53Hys94pndsMLfyHxA= Received: by 10.67.119.13 with SMTP id w13mr4468341ugm.1184610518006; Mon, 16 Jul 2007 11:28:38 -0700 (PDT) Received: by 10.66.244.9 with HTTP; Mon, 16 Jul 2007 11:28:37 -0700 (PDT) Message-ID: Date: Mon, 16 Jul 2007 20:28:37 +0200 From: "Sven Braun" To: freebsd-current@freebsd.org In-Reply-To: <469AB9BD.3060300@errno.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <469AB9BD.3060300@errno.com> X-Mailman-Approved-At: Mon, 16 Jul 2007 18:50:12 +0000 Subject: Re: Problems with ath_hal-20070428 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Jul 2007 18:28:39 -0000 Hi, > rm -rf /usr/obj/.../compile/MACBOOK thanks, but I solved trough a more simple (or idiot) way - cp -R does NOT copy recursive (to my surprise) and so the public/ directory wasn't copied, and that it was .. I recompiled the kernel, and I my Atheros AR5008 was recognised. It is sometimes buggy, but I don't know how to reproduce the errors.. Sorry and thanks, Sven Braun From owner-freebsd-current@FreeBSD.ORG Mon Jul 16 19:22:22 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5597816A400 for ; Mon, 16 Jul 2007 19:22:22 +0000 (UTC) (envelope-from freebsd@hansmi.ch) Received: from hansmi.home.forkbomb.ch (hansmi.home.forkbomb.ch [213.144.146.165]) by mx1.freebsd.org (Postfix) with ESMTP id CBF7313C494 for ; Mon, 16 Jul 2007 19:22:16 +0000 (UTC) (envelope-from freebsd@hansmi.ch) Received: (qmail 25320 invoked by uid 1000); 16 Jul 2007 19:02:58 -0000 Date: Mon, 16 Jul 2007 21:02:58 +0200 From: Michael Hanselmann To: freebsd-current@freebsd.org Message-ID: <20070716190258.GA25030@hansmi.ch> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="IiVenqGWf+H9Y6IX" Content-Disposition: inline User-Agent: Mutt/1.5.13 (2006-08-11) Cc: tobias.mueller@hostpoint.ch, m.kooijman@student.utwente.nl, elias.wittwer@hostpoint.ch Subject: [PATCH] Implement getgroupmembership(3) for massive performance gain when using LDAP or Winbind X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Jul 2007 19:22:22 -0000 --IiVenqGWf+H9Y6IX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hello I was working with a company which plans to migrate its FreeBSD servers from using /etc/{passwd,group} to LDAP. They will have about 45'000 users and as much groups in the directory. Tests showed that any function retrieving the groups a user is member of, for example getgrouplist(3) or initgroups(3), is very slow. In our case, it was about 7 seconds per invocation. Further investigation showed how inefficient these functions are implemented through getgrouplist(3). FreeBSD's implementation loops through all groups and their members to check whether a user is member of it, in which case it adds the group to a list. In our case, this means retrieving 45'000 search results from the LDAP server. Directory services like LDAP or Winbind allow queries to have filters, enabling us to write a much more efficient implementation. The attached patches (nss-getgroupmembership-try9.diff for FreeBSD 6, nss-getgroupmembership-fbsd7-try3.diff for FreeBSD 7) use an nss module's getgroupmembership(3) function if available. Otherwise it uses a fallback which then uses the old algorithm with some modifications. After applying it, getgrouplist(3) takes only a few milliseconds to retrieve all groups of a user. Another patch, attached as bsdnss.diff, is needed for nss_ldap. It applies to the ports/net/nss_ldap/files/bsdnss.c file and exports the required getgroupmembership function. Most of the code there is from NetBSD. The basic idea of getgroupmembership(3) has been taken from [1] and NetBSD, where it's already implemented. Thanks to Matthijs Kooijman for his preliminary work[2], testing with Winbind and support. A need for this code seems to have been around since some time already; the first reference[3] I've found being in March 2006. What do you think about the code? Is it usable? If not, I'm open to provide fixes. If yes, please apply it. Development of these patches is being sponsored by Hostpoint AG, http://www.hostpoint.ch/. They use currently use FreeBSD 6.2 and would like to see this patch being applied there, too. Greets, Michael [1] http://osdir.com/ml/netbsd.devel.userlevel/2004-12/msg00001.html [2] http://lists.freebsd.org/pipermail/freebsd-current/2006-May/063548.html [3] http://lists.freebsd.org/pipermail/freebsd-current/2006-March/061413.html --IiVenqGWf+H9Y6IX Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="bsdnss.diff" --- bsdnss.c.orig Mon May 14 14:25:05 2007 +++ bsdnss.c Mon May 14 15:01:06 2007 @@ -1,9 +1,11 @@ +#include #include #include #include #include #include #include +#include #include extern enum nss_status _nss_ldap_getgrent_r(struct group *, char *, size_t, @@ -34,12 +36,15 @@ extern enum nss_status _nss_ldap_gethost extern enum nss_status _nss_ldap_gethostbyaddr_r (struct in_addr * addr, int len, int type, struct hostent * result, char *buffer, size_t buflen, int *errnop, int *h_errnop); +extern enum nss_status _nss_ldap_initgroups_dyn(const char *, gid_t, long int *, + long int *, gid_t **, long int, int *); NSS_METHOD_PROTOTYPE(__nss_compat_getgrnam_r); NSS_METHOD_PROTOTYPE(__nss_compat_getgrgid_r); NSS_METHOD_PROTOTYPE(__nss_compat_getgrent_r); NSS_METHOD_PROTOTYPE(__nss_compat_setgrent); NSS_METHOD_PROTOTYPE(__nss_compat_endgrent); +static NSS_METHOD_PROTOTYPE(__freebsd_getgroupmembership); NSS_METHOD_PROTOTYPE(__nss_compat_getpwnam_r); NSS_METHOD_PROTOTYPE(__nss_compat_getpwuid_r); @@ -57,6 +62,7 @@ static ns_mtab methods[] = { { NSDB_GROUP, "getgrent_r", __nss_compat_getgrent_r, _nss_ldap_getgrent_r }, { NSDB_GROUP, "setgrent", __nss_compat_setgrent, _nss_ldap_setgrent }, { NSDB_GROUP, "endgrent", __nss_compat_endgrent, _nss_ldap_endgrent }, +{ NSDB_GROUP, "getgroupmembership", __freebsd_getgroupmembership, NULL }, { NSDB_PASSWD, "getpwnam_r", __nss_compat_getpwnam_r, _nss_ldap_getpwnam_r }, { NSDB_PASSWD, "getpwuid_r", __nss_compat_getpwuid_r, _nss_ldap_getpwuid_r }, @@ -155,4 +161,62 @@ int __nss_compat_gethostbyaddr(void *ret status = __nss_compat_result(status,errnop); h_errno = h_errnop; return (status); +} + +static int +__gr_addgid(gid_t gid, gid_t *groups, int maxgrp, int *groupc) +{ + int ret, dupc; + + /* skip duplicates */ + for (dupc = 0; dupc < MIN(maxgrp, *groupc); dupc++) { + if (groups[dupc] == gid) + return 1; + } + + ret = 1; + if (*groupc < maxgrp) /* add this gid */ + groups[*groupc] = gid; + else + ret = 0; + (*groupc)++; + return ret; +} + +static int +__freebsd_getgroupmembership(void *retval, void *mdata, va_list ap) +{ + int err; + enum nss_status s; + int *result = va_arg(ap, int *); + const char *user = va_arg(ap, const char *); + gid_t group = va_arg(ap, gid_t); + gid_t *groups = va_arg(ap, gid_t *); + int limit = va_arg(ap, int); + int *size = va_arg(ap, int*); + gid_t *tmpgroups; + long int lstart, lsize; + int i; + + tmpgroups = malloc(limit * sizeof(gid_t)); + if (tmpgroups == NULL) + return NS_TRYAGAIN; + + /* insert primary membership */ + __gr_addgid(group, groups, limit, size); + + lstart = 0; + lsize = limit; + s = _nss_ldap_initgroups_dyn(user, group, &lstart, &lsize, + &tmpgroups, 0, &err); + if (s == NSS_STATUS_SUCCESS) { + for (i = 0; i < lstart; i++) + if (! __gr_addgid(tmpgroups[i], groups, limit, size)) + *result = -1; + s = NSS_STATUS_NOTFOUND; + } + + free(tmpgroups); + + return __nss_compat_result(s, 0); } --IiVenqGWf+H9Y6IX Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="nss-getgroupmembership-try9.diff" Index: include/nsswitch.h =================================================================== RCS file: /home/ncvs/src/include/nsswitch.h,v retrieving revision 1.3 diff -u -b -B -u -p -r1.3 nsswitch.h --- include/nsswitch.h 17 Apr 2003 14:14:21 -0000 1.3 +++ include/nsswitch.h 14 May 2007 15:18:30 -0000 @@ -68,6 +68,7 @@ #define NSSRC_DNS "dns" /* DNS; IN for hosts, HS for others */ #define NSSRC_NIS "nis" /* YP/NIS */ #define NSSRC_COMPAT "compat" /* passwd,group in YP compat mode */ +#define NSSRC_ALL "*" /* All sources, used for fallbacks */ /* * currently implemented databases @@ -220,6 +221,24 @@ typedef struct _ns_mod { nss_module_unregister_fn unregister; /* called to unload module */ } ns_mod; +/* + * ns_fbtab `method' function signature. + */ +typedef int (*nss_fbmethod)(const ns_src *source, void *_retval, + void *_mdata, va_list _ap); + +/* + * ns_fbtab - `nsswitch fallback table' + * Contains an entry for each source and the appropriate function to + * call. ns_dtabs are used in the nsdispatch() API in order to allow + * the application to override built-in actions. + */ +typedef struct _ns_fbtab { + const char *src; /* Source this entry implements */ + nss_fbmethod method; /* Method to be called */ + void *mdata; /* Data passed to method */ +} ns_fbtab; + #endif /* _NS_PRIVATE */ @@ -230,6 +249,14 @@ extern int nsdispatch(void *, const ns_d const char *, const ns_src [], ...); #ifdef _NS_PRIVATE +extern int _nsdispatch_with_fb(void *, const ns_dtab [], + const ns_fbtab [], const char *, + const char *, const ns_src [], ...); +extern int _nsdispatch_callmethod(int*, const ns_src *, + const char *, const char *, + const ns_dtab [], const ns_fbtab [], + void *, void *, ...); + extern void _nsdbtaddsrc(ns_dbt *, const ns_src *); extern void _nsdbtput(const ns_dbt *); extern void _nsyyerror(const char *); Index: lib/libc/gen/getgrent.c =================================================================== RCS file: /home/ncvs/src/lib/libc/gen/getgrent.c,v retrieving revision 1.32.8.3 diff -u -b -B -u -p -r1.32.8.3 getgrent.c --- lib/libc/gen/getgrent.c 8 Oct 2006 05:45:57 -0000 1.32.8.3 +++ lib/libc/gen/getgrent.c 14 May 2007 15:18:30 -0000 @@ -46,6 +46,7 @@ __FBSDID("$FreeBSD: src/lib/libc/gen/get #include #endif #include +#define _NS_PRIVATE #include #include #include @@ -54,6 +55,7 @@ __FBSDID("$FreeBSD: src/lib/libc/gen/get #include #include #include +#include #include "un-namespace.h" #include "libc_private.h" #include "nss_tls.h" @@ -1070,6 +1069,188 @@ fin: fseeko(st->fp, pos, SEEK_SET); return (rv); #undef set_lookup_type +} + +static int +__gr_addgid(gid_t gid, gid_t *groups, int maxgrp, int *groupc) +{ + int ret, dupc; + + /* skip duplicates */ + for (dupc = 0; dupc < MIN(maxgrp, *groupc); dupc++) { + if (groups[dupc] == gid) + return 1; + } + + ret = 1; + if (*groupc < maxgrp) + /* add gid */ + groups[*groupc] = gid; + else + ret = 0; + + (*groupc)++; + + return ret; +} + +/* + * Fallback function for sources which don't have the getgroupmembership + * method. It uses the old and inefficient method of looping through all groups + * and their members. + */ +static int +getgroupmembership_fallback(const ns_src *source, + void *rv, void *mdata, va_list ap) +{ + static const ns_dtab dtab_getgrent[] = { + { NSSRC_FILES, files_group, (void *)nss_lt_all }, +#ifdef HESIOD + { NSSRC_DNS, dns_group, (void *)nss_lt_all }, +#endif +#ifdef YP + { NSSRC_NIS, nis_group, (void *)nss_lt_all }, +#endif + { NSSRC_COMPAT, compat_group, (void *)nss_lt_all }, + { NULL, NULL, NULL } + }; + + int *retval = va_arg(ap, int *); + const char *uname = va_arg(ap, const char *); + gid_t group = va_arg(ap, gid_t); + gid_t *groups = va_arg(ap, gid_t *); + int limit = va_arg(ap, int); + int *size = va_arg(ap, int *); + + struct group grp; + struct group *grp_p; + int i; + int lrv; + int lresult; + int lretval; + char *lbuf; + size_t lbufsize; + int ret_errno; + + lbuf = malloc(GRP_STORAGE_INITIAL); + if (lbuf == NULL) { + lrv = NS_UNAVAIL; + goto out; + } + lbufsize = GRP_STORAGE_INITIAL; + + /* Rewind */ + lrv = _nsdispatch_callmethod(&lresult, source, + NSDB_GROUP, "setgrent", + NULL, NULL, + &lretval, NULL, NULL); + + /* + * When installing primary group, duplicate it; + * the first element of groups is the effective gid + * and will be overwritten when a setgid file is executed. + */ + __gr_addgid(group, groups, limit, size); + + + *retval = 0; + + /* + * Scan source to find additional groups. + */ + while (1) { + /* We can't use getgrent() here because it wouldn't be safe for + * multithreaded programs. + */ + do { + ret_errno = 0; + grp_p = NULL; + lrv = _nsdispatch_callmethod(&lresult, source, + NSDB_GROUP, "getgrent_r", + dtab_getgrent, NULL, + &grp_p, (void *)nss_lt_all, &grp, lbuf, lbufsize, &ret_errno); + + if (grp_p == NULL && ret_errno == ERANGE) { + free(lbuf); + + if ((lbufsize << 1) > GRP_STORAGE_MAX) { + lbuf = NULL; + errno = ERANGE; + lrv = NS_UNAVAIL; + goto out; + } + + lbufsize <<= 1; + lbuf = malloc(lbufsize); + if (lbuf == NULL) { + lrv = NS_UNAVAIL; + goto out; + } + } + } while (grp_p == NULL && ret_errno == ERANGE); + + if (ret_errno != 0) { + errno = ret_errno; + lrv = NS_UNAVAIL; + goto out; + } + + if (grp_p == NULL) + break; + + /* Loop through group members */ + for (i = 0; grp.gr_mem[i]; i++) { + if (strcmp(grp.gr_mem[i], uname) == 0) { + if (!__gr_addgid(grp.gr_gid, groups, limit, size)) { + *retval = -1; + } + } + } + } + + /* Close database */ + lrv = _nsdispatch_callmethod(&lresult, source, + NSDB_GROUP, "endgrent", + NULL, NULL, + &lretval, NULL, NULL); + + lrv = NS_NOTFOUND; + +out: + free(lbuf); + + return lrv; +} + +/* + * getgroupmembership is about the same as getgrouplist(3), except it has a + * different interface that supports being dispatched by nss. + */ +int +getgroupmembership(const char *uname, gid_t agroup, gid_t *groups, + int maxgrp, int *groupc) +{ + static const ns_fbtab fallback[] = { + { NSSRC_ALL, getgroupmembership_fallback, NULL }, + { NULL, NULL, NULL } + }; + int rv, rerror, retval; + + assert(uname != NULL); + /* groups may be NULL if just sizing when invoked with maxgrp = 0 */ + assert(groupc != NULL); + + *groupc = 0; + + rv = _nsdispatch_with_fb(&retval, NULL, fallback, + NSDB_GROUP, "getgroupmembership", defaultsrc, + &rerror, uname, agroup, groups, maxgrp, groupc); + + /* too many groups found? */ + if (*groupc > maxgrp) + return -1; + else + return 0; } Index: lib/libc/gen/getgrouplist.c =================================================================== RCS file: /home/ncvs/src/lib/libc/gen/getgrouplist.c,v retrieving revision 1.14 diff -u -b -B -u -p -r1.14 getgrouplist.c --- lib/libc/gen/getgrouplist.c 3 May 2005 16:20:03 -0000 1.14 +++ lib/libc/gen/getgrouplist.c 14 May 2007 15:18:30 -0000 @@ -46,46 +46,12 @@ __FBSDID("$FreeBSD: src/lib/libc/gen/get #include #include +extern int +getgroupmembership(const char *uname, gid_t agroup, gid_t *groups, + int maxgrp, int *groupc); + int getgrouplist(const char *uname, gid_t agroup, gid_t *groups, int *grpcnt) { - const struct group *grp; - int i, maxgroups, ngroups, ret; - - ret = 0; - ngroups = 0; - maxgroups = *grpcnt; - /* - * When installing primary group, duplicate it; - * the first element of groups is the effective gid - * and will be overwritten when a setgid file is executed. - */ - groups[ngroups++] = agroup; - if (maxgroups > 1) - groups[ngroups++] = agroup; - /* - * Scan the group file to find additional groups. - */ - setgrent(); - while ((grp = getgrent()) != NULL) { - for (i = 0; i < ngroups; i++) { - if (grp->gr_gid == groups[i]) - goto skip; - } - for (i = 0; grp->gr_mem[i]; i++) { - if (!strcmp(grp->gr_mem[i], uname)) { - if (ngroups >= maxgroups) { - ret = -1; - break; - } - groups[ngroups++] = grp->gr_gid; - break; - } - } -skip: - ; - } - endgrent(); - *grpcnt = ngroups; - return (ret); + return getgroupmembership(uname, agroup, groups, *grpcnt, grpcnt); } Index: lib/libc/net/nsdispatch.c =================================================================== RCS file: /home/ncvs/src/lib/libc/net/nsdispatch.c,v retrieving revision 1.12 diff -u -b -B -u -p -r1.12 nsdispatch.c --- lib/libc/net/nsdispatch.c 1 Apr 2004 19:12:45 -0000 1.12 +++ lib/libc/net/nsdispatch.c 14 May 2007 15:18:30 -0000 @@ -569,19 +572,108 @@ nss_method_lookup(const char *source, co return (NULL); } +/* + * Looks up a fallback method + */ +static nss_fbmethod +nss_fbmethod_lookup(const char *source, const char *method, + const ns_fbtab fallback[], void **mdata) +{ + int i; + + for (i = 0; fallback[i].src != NULL; i++) + if (strcasecmp(source, fallback[i].src) == 0 || + strcasecmp(NSSRC_ALL, fallback[i].src) == 0) { + *mdata = fallback[i].mdata; + return (fallback[i].method); + } -__weak_reference(_nsdispatch, nsdispatch); + *mdata = NULL; + return NULL; +} + +/* + * Calls a function from an nss source. If the function isn't defined, it uses + * the provided fallback table. For a description of the fallback table, see + * _nsdispatch_with_fbv. + */ +static int +_nsdispatch_callmethodv(int* result, const ns_src *source, + const char *database, const char *method_name, + const ns_dtab disp_tab[], const ns_fbtab fallback[], + void *retval, void *mdata, va_list ap) +{ + nss_method method; + nss_fbmethod fbmethod; + *result = NS_NOTFOUND; + + method = nss_method_lookup(source->name, database, + method_name, disp_tab, &mdata); + + if (method == NULL && fallback != NULL) { + /* Try to get fallback function */ + fbmethod = nss_fbmethod_lookup(source->name, + method_name, fallback, &mdata); + } else { + fbmethod = NULL; + } + + if (method != NULL || fbmethod != NULL) { + if (fbmethod != NULL) { + *result = fbmethod(source, retval, mdata, ap); + } else { + *result = method(retval, mdata, ap); + } + + if (*result & (source->flags)) + return NS_ACTION_RETURN; + } + + return NS_ACTION_CONTINUE; +} + +/* + * Wrapper around _nsdispatch_callmethodv + */ int -_nsdispatch(void *retval, const ns_dtab disp_tab[], const char *database, - const char *method_name, const ns_src defaults[], ...) +_nsdispatch_callmethod(int* result, const ns_src *source, + const char *database, const char *method_name, + const ns_dtab disp_tab[], const ns_fbtab fallback[], + void *retval, void *mdata, ...) { va_list ap; + int rv; + + va_start(ap, mdata); + rv = _nsdispatch_callmethodv(result, source, + database, method_name, + disp_tab, fallback, + retval, mdata, ap); + va_end(ap); + + return rv; +} + +/* + * nsdispatch function with fallback functionality. The fallbacks can be used + * to replace unimplemented functions in sources. + * + * A fallback table can contain any source name or the special entry of + * NSSRC_ALL to match all sources. If used, NSSRC_ALL must be the last entry. + * The fallbcak function is then called for each source which doesn't have an + * implementation of the wanted function. + */ +int +_nsdispatch_with_fbv(void *retval, const ns_dtab disp_tab[], + const ns_fbtab fallback[], const char *database, + const char *method_name, const ns_src defaults[], + va_list ap) +{ const ns_dbt *dbt; const ns_src *srclist; - nss_method method; void *mdata; - int isthreaded, serrno, i, result, srclistsize; + int isthreaded, serrno, i, result, srclistsize, rv; isthreaded = __isthreaded; serrno = errno; @@ -608,15 +702,13 @@ _nsdispatch(void *retval, const ns_dtab while (srclist[srclistsize].name != NULL) srclistsize++; } + for (i = 0; i < srclistsize; i++) { - result = NS_NOTFOUND; - method = nss_method_lookup(srclist[i].name, database, - method_name, disp_tab, &mdata); - if (method != NULL) { - va_start(ap, defaults); - result = method(retval, mdata, ap); - va_end(ap); - if (result & (srclist[i].flags)) + rv = _nsdispatch_callmethodv(&result, &srclist[i], + database, method_name, + disp_tab, fallback, + retval, mdata, ap); + if (rv == NS_ACTION_RETURN) { break; } } @@ -626,3 +718,43 @@ fin: errno = serrno; return (result); } + +/* + * Wrapper around _nsdispatch_with_fbv + */ +int +_nsdispatch_with_fb(void *retval, const ns_dtab disp_tab[], + const ns_fbtab fallback[], const char *database, + const char *method_name, const ns_src defaults[], + ...) +{ + va_list ap; + int rv; + + va_start(ap, defaults); + rv = _nsdispatch_with_fbv(retval, disp_tab, fallback, database, + method_name, defaults, ap); + va_end(ap); + + return rv; +} + +/* + * Original nsdispatch function without fallback functionality. + */ +int +_nsdispatch(void *retval, const ns_dtab disp_tab[], const char *database, + const char *method_name, const ns_src defaults[], ...) +{ + va_list ap; + int rv; + + va_start(ap, defaults); + rv = _nsdispatch_with_fbv(retval, disp_tab, NULL, database, + method_name, defaults, ap); + va_end(ap); + + return rv; +} + +__weak_reference(_nsdispatch, nsdispatch); --IiVenqGWf+H9Y6IX Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="nss-getgroupmembership-fbsd7-try3.diff" Index: include/nsswitch.h =================================================================== RCS file: /home/ncvs/src/include/nsswitch.h,v retrieving revision 1.4 diff -u -b -B -u -p -r1.4 nsswitch.h --- include/nsswitch.h 28 Apr 2006 12:03:34 -0000 1.4 +++ include/nsswitch.h 12 Jun 2007 20:49:25 -0000 @@ -69,6 +69,7 @@ #define NSSRC_NIS "nis" /* YP/NIS */ #define NSSRC_COMPAT "compat" /* passwd,group in YP compat mode */ #define NSSRC_CACHE "cache" /* cache daemon */ +#define NSSRC_ALL "*" /* All sources, used for fallbacks */ /* * currently implemented databases @@ -222,6 +223,24 @@ typedef struct _ns_mod { nss_module_unregister_fn unregister; /* called to unload module */ } ns_mod; +/* + * ns_fbtab `method' function signature. + */ +typedef int (*nss_fbmethod)(const ns_src *source, void *_retval, + void *_mdata, va_list _ap); + +/* + * ns_fbtab - `nsswitch fallback table' + * Contains an entry for each source and the appropriate function to + * call. ns_dtabs are used in the nsdispatch() API in order to allow + * the application to override built-in actions. + */ +typedef struct _ns_fbtab { + const char *src; /* Source this entry implements */ + nss_fbmethod method; /* Method to be called */ + void *mdata; /* Data passed to method */ +} ns_fbtab; + #endif /* _NS_PRIVATE */ @@ -232,6 +251,14 @@ extern int nsdispatch(void *, const ns_d const char *, const ns_src [], ...); #ifdef _NS_PRIVATE +extern int _nsdispatch_with_fb(void *, const ns_dtab [], + const ns_fbtab [], const char *, + const char *, const ns_src [], ...); +extern int _nsdispatch_callmethod(int*, const ns_src *, + const char *, const char *, + const ns_dtab [], const ns_fbtab [], + void *, void *, ...); + extern void _nsdbtaddsrc(ns_dbt *, const ns_src *); extern void _nsdbtput(const ns_dbt *); extern void _nsyyerror(const char *); Index: lib/libc/gen/getgrent.c =================================================================== RCS file: /home/ncvs/src/lib/libc/gen/getgrent.c,v retrieving revision 1.36 diff -u -b -B -u -p -r1.36 getgrent.c --- lib/libc/gen/getgrent.c 18 Sep 2006 09:34:48 -0000 1.36 +++ lib/libc/gen/getgrent.c 12 Jun 2007 20:49:25 -0000 @@ -46,6 +46,7 @@ __FBSDID("$FreeBSD: src/lib/libc/gen/get #include #endif #include +#define _NS_PRIVATE #include #include #include @@ -54,6 +55,7 @@ __FBSDID("$FreeBSD: src/lib/libc/gen/get #include #include #include +#include #include "un-namespace.h" #include "libc_private.h" #include "nss_tls.h" @@ -447,17 +449,13 @@ endgrent(void) } -int -getgrent_r(struct group *grp, char *buffer, size_t bufsize, - struct group **result) -{ #ifdef NS_CACHING - static const nss_cache_info cache_info = NS_MP_CACHE_INFO_INITIALIZER( +static const nss_cache_info getgrent_cache_info = NS_MP_CACHE_INFO_INITIALIZER( group, (void *)nss_lt_all, grp_marshal_func, grp_unmarshal_func); #endif - static const ns_dtab dtab[] = { +static const ns_dtab getgrent_dtab[] = { { NSSRC_FILES, files_group, (void *)nss_lt_all }, #ifdef HESIOD { NSSRC_DNS, dns_group, (void *)nss_lt_all }, @@ -467,16 +465,21 @@ getgrent_r(struct group *grp, char *buff #endif { NSSRC_COMPAT, compat_group, (void *)nss_lt_all }, #ifdef NS_CACHING - NS_CACHE_CB(&cache_info) + NS_CACHE_CB(&getgrent_cache_info) #endif { NULL, NULL, NULL } - }; +}; + +int +getgrent_r(struct group *grp, char *buffer, size_t bufsize, + struct group **result) +{ int rv, ret_errno; ret_errno = 0; *result = NULL; - rv = _nsdispatch(result, dtab, NSDB_GROUP, "getgrent_r", defaultsrc, - grp, buffer, bufsize, &ret_errno); + rv = _nsdispatch(result, getgrent_dtab, NSDB_GROUP, "getgrent_r", + defaultsrc, grp, buffer, bufsize, &ret_errno); if (rv == NS_SUCCESS) return (0); else @@ -1346,6 +1349,175 @@ fin: fseeko(st->fp, pos, SEEK_SET); return (rv); #undef set_lookup_type +} + +static int +__gr_addgid(gid_t gid, gid_t *groups, int maxgrp, int *groupc) +{ + int ret, dupc; + + /* skip duplicates */ + for (dupc = 0; dupc < MIN(maxgrp, *groupc); dupc++) { + if (groups[dupc] == gid) + return 1; + } + + ret = 1; + if (*groupc < maxgrp) + /* add gid */ + groups[*groupc] = gid; + else + ret = 0; + + (*groupc)++; + + return ret; +} + +/* + * Fallback function for sources which don't have the getgroupmembership + * method. It uses the old and inefficient method of looping through all groups + * and their members. + */ +static int +getgroupmembership_fallback(const ns_src *source, + void *rv, void *mdata, va_list ap) +{ + int *retval = va_arg(ap, int *); + const char *uname = va_arg(ap, const char *); + gid_t group = va_arg(ap, gid_t); + gid_t *groups = va_arg(ap, gid_t *); + int limit = va_arg(ap, int); + int *size = va_arg(ap, int *); + + struct group grp; + struct group *grp_p; + int i; + int lrv; + int lresult; + int lretval; + char *lbuf; + size_t lbufsize; + int ret_errno; + + lbuf = malloc(GRP_STORAGE_INITIAL); + if (lbuf == NULL) { + lrv = NS_UNAVAIL; + goto out; + } + lbufsize = GRP_STORAGE_INITIAL; + + /* Rewind */ + lrv = _nsdispatch_callmethod(&lresult, source, + NSDB_GROUP, "setgrent", + NULL, NULL, + &lretval, NULL, NULL); + + /* + * When installing primary group, duplicate it; + * the first element of groups is the effective gid + * and will be overwritten when a setgid file is executed. + */ + __gr_addgid(group, groups, limit, size); + + *retval = 0; + + /* + * Scan source to find additional groups. + */ + while (1) { + /* We can't use getgrent() here because it wouldn't be safe for + * multithreaded programs. + */ + do { + ret_errno = 0; + grp_p = NULL; + lrv = _nsdispatch_callmethod(&lresult, source, + NSDB_GROUP, "getgrent_r", + getgrent_dtab, NULL, + &grp_p, (void *)nss_lt_all, &grp, lbuf, lbufsize, &ret_errno); + + if (grp_p == NULL && ret_errno == ERANGE) { + free(lbuf); + + if ((lbufsize << 1) > GRP_STORAGE_MAX) { + lbuf = NULL; + errno = ERANGE; + lrv = NS_UNAVAIL; + goto out; + } + + lbufsize <<= 1; + lbuf = malloc(lbufsize); + if (lbuf == NULL) { + lrv = NS_UNAVAIL; + goto out; + } + } + } while (grp_p == NULL && ret_errno == ERANGE); + + if (ret_errno != 0) { + errno = ret_errno; + lrv = NS_UNAVAIL; + goto out; + } + + if (grp_p == NULL) + break; + + /* Loop through group members */ + for (i = 0; grp.gr_mem[i]; i++) { + if (strcmp(grp.gr_mem[i], uname) == 0) { + if (!__gr_addgid(grp.gr_gid, groups, limit, size)) { + *retval = -1; + } + } + } + } + + /* Close database */ + lrv = _nsdispatch_callmethod(&lresult, source, + NSDB_GROUP, "endgrent", + NULL, NULL, + &lretval, NULL, NULL); + + lrv = NS_NOTFOUND; + +out: + free(lbuf); + + return lrv; +} + +/* + * getgroupmembership is about the same as getgrouplist(3), except it has a + * different interface that supports being dispatched by nss. + */ +int +getgroupmembership(const char *uname, gid_t agroup, gid_t *groups, + int maxgrp, int *groupc) +{ + static const ns_fbtab fallback[] = { + { NSSRC_ALL, getgroupmembership_fallback, NULL }, + { NULL, NULL, NULL } + }; + int rv, rerror, retval; + + assert(uname != NULL); + /* groups may be NULL if just sizing when invoked with maxgrp = 0 */ + assert(groupc != NULL); + + *groupc = 0; + + rv = _nsdispatch_with_fb(&retval, NULL, fallback, + NSDB_GROUP, "getgroupmembership", defaultsrc, + &rerror, uname, agroup, groups, maxgrp, groupc); + + /* too many groups found? */ + if (*groupc > maxgrp) + return -1; + else + return 0; } Index: lib/libc/gen/getgrouplist.c =================================================================== RCS file: /home/ncvs/src/lib/libc/gen/getgrouplist.c,v retrieving revision 1.15 diff -u -b -B -u -p -r1.15 getgrouplist.c --- lib/libc/gen/getgrouplist.c 9 Jan 2007 00:27:53 -0000 1.15 +++ lib/libc/gen/getgrouplist.c 12 Jun 2007 20:49:25 -0000 @@ -41,47 +41,14 @@ __FBSDID("$FreeBSD: src/lib/libc/gen/get #include #include #include +#include + +extern int +getgroupmembership(const char *uname, gid_t agroup, gid_t *groups, + int maxgrp, int *groupc); int getgrouplist(const char *uname, gid_t agroup, gid_t *groups, int *grpcnt) { - const struct group *grp; - int i, maxgroups, ngroups, ret; - - ret = 0; - ngroups = 0; - maxgroups = *grpcnt; - /* - * When installing primary group, duplicate it; - * the first element of groups is the effective gid - * and will be overwritten when a setgid file is executed. - */ - groups[ngroups++] = agroup; - if (maxgroups > 1) - groups[ngroups++] = agroup; - /* - * Scan the group file to find additional groups. - */ - setgrent(); - while ((grp = getgrent()) != NULL) { - for (i = 0; i < ngroups; i++) { - if (grp->gr_gid == groups[i]) - goto skip; - } - for (i = 0; grp->gr_mem[i]; i++) { - if (!strcmp(grp->gr_mem[i], uname)) { - if (ngroups >= maxgroups) { - ret = -1; - break; - } - groups[ngroups++] = grp->gr_gid; - break; - } - } -skip: - ; - } - endgrent(); - *grpcnt = ngroups; - return (ret); + return getgroupmembership(uname, agroup, groups, *grpcnt, grpcnt); } Index: lib/libc/net/nsdispatch.c =================================================================== RCS file: /home/ncvs/src/lib/libc/net/nsdispatch.c,v retrieving revision 1.14 diff -u -b -B -u -p -r1.14 nsdispatch.c --- lib/libc/net/nsdispatch.c 17 May 2007 03:33:23 -0000 1.14 +++ lib/libc/net/nsdispatch.c 12 Jun 2007 20:49:26 -0000 @@ -590,19 +590,147 @@ nss_method_lookup(const char *source, co return (NULL); } +/* + * Looks up a fallback method + */ +static nss_fbmethod +nss_fbmethod_lookup(const char *source, const char *method, + const ns_fbtab fallback[], void **mdata) +{ + int i; -__weak_reference(_nsdispatch, nsdispatch); + for (i = 0; fallback[i].src != NULL; i++) + if (strcasecmp(source, fallback[i].src) == 0 || + strcasecmp(NSSRC_ALL, fallback[i].src) == 0) { + *mdata = fallback[i].mdata; + return (fallback[i].method); + } + + *mdata = NULL; + return NULL; +} + +/* + * Calls a function from an nss source. If the function isn't defined, it uses + * the provided fallback table. For a description of the fallback table, see + * _nsdispatch_with_fbv. + */ +static int +_nsdispatch_callmethod_with_cache_v(int* result, const ns_src *source, + const char *database, const char *method_name, + const ns_dtab disp_tab[], const ns_fbtab fallback[], +#ifdef NS_CACHING + nss_cache_data *cache_data, nss_cache_data **cache_data_p, + int *cache_flag, +#endif + void *retval, void *mdata, va_list ap) +{ + nss_method method; + nss_fbmethod fbmethod; + + *result = NS_NOTFOUND; + + method = nss_method_lookup(source->name, database, + method_name, disp_tab, &mdata); + + if (method == NULL && fallback != NULL) { + /* Try to get fallback function */ + fbmethod = nss_fbmethod_lookup(source->name, + method_name, fallback, &mdata); + } else { + fbmethod = NULL; + } + + if (method != NULL || fbmethod != NULL) { +#ifdef NS_CACHING + if (cache_data != NULL && cache_data_p != NULL && + cache_flag != NULL && + strcmp(source->name, NSSRC_CACHE) == 0 && + nss_cache_cycle_prevention_func == NULL) { +#ifdef NS_STRICT_LIBC_EID_CHECKING + if (issetugid() != 0) + return NS_ACTION_CONTINUE; +#endif + *cache_flag = 1; + + memset(cache_data, 0, sizeof(nss_cache_data)); + cache_data->info = (nss_cache_info const *)mdata; + *cache_data_p = cache_data; + + if (cache_data->info->id_func != NULL) + *result = __nss_common_cache_read(retval, + *cache_data_p, ap); + else if (cache_data->info->marshal_func != NULL) + *result = __nss_mp_cache_read(retval, + *cache_data_p, ap); + else + *result = __nss_mp_cache_end(retval, + *cache_data_p, ap); + } else { + *cache_flag = 0; +#endif + + if (fbmethod != NULL) { + *result = fbmethod(source, retval, mdata, ap); + } else { + *result = method(retval, mdata, ap); + } +#ifdef NS_CACHING + } +#endif + + if (*result & (source->flags)) + return NS_ACTION_RETURN; + } + + return NS_ACTION_CONTINUE; +} + +/* + * Wrapper around _nsdispatch_callmethod_with_cache_v + */ int -_nsdispatch(void *retval, const ns_dtab disp_tab[], const char *database, - const char *method_name, const ns_src defaults[], ...) +_nsdispatch_callmethod(int* result, const ns_src *source, + const char *database, const char *method_name, + const ns_dtab disp_tab[], const ns_fbtab fallback[], + void *retval, void *mdata, ...) { va_list ap; + int rv; + + va_start(ap, mdata); + rv = _nsdispatch_callmethod_with_cache_v(result, source, + database, method_name, + disp_tab, fallback, +#ifdef NS_CACHING + NULL, NULL, NULL, +#endif + retval, mdata, ap); + va_end(ap); + + return rv; +} + +/* + * nsdispatch function with fallback functionality. The fallbacks can be used + * to replace unimplemented functions in sources. + * + * A fallback table can contain any source name or the special entry of + * NSSRC_ALL to match all sources. If used, NSSRC_ALL must be the last entry. + * The fallbcak function is then called for each source which doesn't have an + * implementation of the wanted function. + */ +int +_nsdispatch_with_fbv(void *retval, const ns_dtab disp_tab[], + const ns_fbtab fallback[], const char *database, + const char *method_name, const ns_src defaults[], + va_list ap) +{ const ns_dbt *dbt; const ns_src *srclist; - nss_method method; void *mdata; - int isthreaded, serrno, i, result, srclistsize; + int isthreaded, serrno, i, result, srclistsize, rv; #ifdef NS_CACHING nss_cache_data cache_data; @@ -640,57 +768,22 @@ _nsdispatch(void *retval, const ns_dtab cache_data_p = NULL; cache_flag = 0; #endif - for (i = 0; i < srclistsize; i++) { - result = NS_NOTFOUND; - method = nss_method_lookup(srclist[i].name, database, - method_name, disp_tab, &mdata); - if (method != NULL) { + for (i = 0; i < srclistsize; i++) { + rv = _nsdispatch_callmethod_with_cache_v(&result, &srclist[i], + database, method_name, + disp_tab, fallback, #ifdef NS_CACHING - if (strcmp(srclist[i].name, NSSRC_CACHE) == 0 && - nss_cache_cycle_prevention_func == NULL) { -#ifdef NS_STRICT_LIBC_EID_CHECKING - if (issetugid() != 0) - continue; + &cache_data, &cache_data_p, &cache_flag, #endif - cache_flag = 1; - - memset(&cache_data, 0, sizeof(nss_cache_data)); - cache_data.info = (nss_cache_info const *)mdata; - cache_data_p = &cache_data; - - va_start(ap, defaults); - if (cache_data.info->id_func != NULL) - result = __nss_common_cache_read(retval, - cache_data_p, ap); - else if (cache_data.info->marshal_func != NULL) - result = __nss_mp_cache_read(retval, - cache_data_p, ap); - else - result = __nss_mp_cache_end(retval, - cache_data_p, ap); - va_end(ap); - } else { - cache_flag = 0; - va_start(ap, defaults); - result = method(retval, mdata, ap); - va_end(ap); - } -#else /* NS_CACHING */ - va_start(ap, defaults); - result = method(retval, mdata, ap); - va_end(ap); -#endif /* NS_CACHING */ - - if (result & (srclist[i].flags)) + retval, mdata, ap); + if (rv == NS_ACTION_RETURN) break; } - } #ifdef NS_CACHING if (cache_data_p != NULL && (result & (NS_NOTFOUND | NS_SUCCESS)) && cache_flag == 0) { - va_start(ap, defaults); if (result == NS_SUCCESS) { if (cache_data.info->id_func != NULL) __nss_common_cache_write(retval, cache_data_p, @@ -705,7 +798,6 @@ _nsdispatch(void *retval, const ns_dtab } else __nss_common_cache_write_negative(cache_data_p); } - va_end(ap); } #endif /* NS_CACHING */ @@ -715,3 +807,43 @@ fin: errno = serrno; return (result); } + +/* + * Wrapper around _nsdispatch_with_fbv + */ +int +_nsdispatch_with_fb(void *retval, const ns_dtab disp_tab[], + const ns_fbtab fallback[], const char *database, + const char *method_name, const ns_src defaults[], + ...) +{ + va_list ap; + int rv; + + va_start(ap, defaults); + rv = _nsdispatch_with_fbv(retval, disp_tab, fallback, database, + method_name, defaults, ap); + va_end(ap); + + return rv; +} + +/* + * Original nsdispatch function without fallback functionality. + */ +int +_nsdispatch(void *retval, const ns_dtab disp_tab[], const char *database, + const char *method_name, const ns_src defaults[], ...) +{ + va_list ap; + int rv; + + va_start(ap, defaults); + rv = _nsdispatch_with_fbv(retval, disp_tab, NULL, database, + method_name, defaults, ap); + va_end(ap); + + return rv; +} + +__weak_reference(_nsdispatch, nsdispatch); --IiVenqGWf+H9Y6IX-- From owner-freebsd-current@FreeBSD.ORG Mon Jul 16 19:36:39 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CE66316A406 for ; Mon, 16 Jul 2007 19:36:39 +0000 (UTC) (envelope-from staale@kristoffersen.ws) Received: from smtp.bluecom.no (smtp.bluecom.no [193.75.75.28]) by mx1.freebsd.org (Postfix) with ESMTP id 93C0513C4C9 for ; Mon, 16 Jul 2007 19:36:39 +0000 (UTC) (envelope-from staale@kristoffersen.ws) Received: from eschew.pusen.org (unknown [193.69.145.10]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.bluecom.no (Postfix) with ESMTP id 4E97D12C2CA for ; Mon, 16 Jul 2007 21:04:36 +0200 (CEST) Received: from chiller by eschew.pusen.org with local (Exim 4.50) id 1IAVs9-0005Hl-Km for current@freebsd.org; Mon, 16 Jul 2007 21:04:41 +0200 Date: Mon, 16 Jul 2007 21:04:41 +0200 From: =?iso-8859-1?Q?St=E5le?= Kristoffersen To: current@freebsd.org Message-ID: <20070716190441.GA19282@eschew.pusen.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.5.13 (2006-08-11) Cc: Subject: Slow networkperformance in current? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2007 19:36:39 -0000 A few months ago I tested my local network speed with iperf and got around 900Mbits/s. But with a newer current I get around 300Mbits/s, (using 100% cpu usage), and to localhost: 162 Mbits/sec. I'm running iperf -s in one terminal and iperf -c localhost on another. FreeBSD 7.0-CURRENT #9: Mon Jul 9 13:18:23 CEST 2007 root@fs:/usr/obj/usr/src/sys/FS i386 Stock kernel, but removed debuging and witness, and using SCHED_ULE. Not knowing where to look I tried to update. Recompiled with updated source and with SCHED_4BSD: FreeBSD 7.0-CURRENT #9: Mon Jul 9 13:18:23 CEST 2007 root@fs:/usr/obj/usr/src/sys/FS i386 Same problem, am I missing something obvious here? This does not look like the correct numbers: [ 4] local 127.0.0.1 port 5001 connected with 127.0.0.1 port 58497 [ 4] 0.0-10.5 sec 172 MBytes 137 Mbits/sec CPU: Intel(R) Pentium(R) D CPU 2.80GHz (2856.02-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf47 Stepping = 7 Features=0xbfebfbff Features2=0x641d AMD Features=0x20100000 AMD Features2=0x1 Cores per package: 2 real memory = 1072562176 (1022 MB) avail memory = 1036025856 (988 MB) FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs -- Ståle Kristoffersen From owner-freebsd-current@FreeBSD.ORG Mon Jul 16 19:48:00 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BBCA816A402 for ; Mon, 16 Jul 2007 19:48:00 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.168]) by mx1.freebsd.org (Postfix) with ESMTP id 4DF8113C4C6 for ; Mon, 16 Jul 2007 19:48:00 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: by ug-out-1314.google.com with SMTP id o4so1181971uge for ; Mon, 16 Jul 2007 12:47:58 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=sMBXOPLDwMMqRvLXz+gD630jO7bZnVqamxXiPsZwotMMe6UP8YNhK0e42mNGM6BSyYvZgTt+SuXzoQWu0LOM/Pn4ebKl0p15GhUf7hDK2Ne0gCVxKYesjbL57H/AunlAuZCH1/+NKuClVT7C5HkxlGhgbRfPouzjNDlJmOqraRI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=C0ngcGOpC3HJe6u6RaQA8EXCI738754MUc1W4GOtLH8/n0tqpOeWq63TZp0xgwGfAcghOqxcXCbOrqBq/CdIwBNQ1VZXqT8ZgkpQu949v35SNDb8V/7HIJpyJJWesJ0J+RVKNVZE6lTyuD8pz8l7fItLeEFMBYhvB/q7amIvH98= Received: by 10.78.193.5 with SMTP id q5mr1269059huf.1184615278737; Mon, 16 Jul 2007 12:47:58 -0700 (PDT) Received: by 10.78.162.18 with HTTP; Mon, 16 Jul 2007 12:47:58 -0700 (PDT) Message-ID: Date: Mon, 16 Jul 2007 12:47:58 -0700 From: "Kip Macy" To: "=?ISO-8859-1?Q?St=E5le_Kristoffersen?=" In-Reply-To: <20070716190441.GA19282@eschew.pusen.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <20070716190441.GA19282@eschew.pusen.org> Cc: current@freebsd.org Subject: Re: Slow networkperformance in current? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2007 19:48:00 -0000 10 GigE cards are doing line rate - over time the cpu usage required to do so is going down. Your experience is probably due to NIC issues. What kind of NIC are you using? And have you changed any configuration or settings? -Kip On 7/16/07, St=E5le Kristoffersen wrote: > A few months ago I tested my local network speed with iperf and got aroun= d > 900Mbits/s. But with a newer current I get around 300Mbits/s, (using 100% > cpu usage), and to localhost: 162 Mbits/sec. > > I'm running iperf -s in one terminal and iperf -c localhost on another. > > FreeBSD 7.0-CURRENT #9: Mon Jul 9 13:18:23 CEST > 2007 root@fs:/usr/obj/usr/src/sys/FS i386 > > Stock kernel, but removed debuging and witness, and using SCHED_ULE. > > Not knowing where to look I tried to update. > Recompiled with updated source and with SCHED_4BSD: > FreeBSD 7.0-CURRENT #9: Mon Jul 9 13:18:23 CEST > 2007 root@fs:/usr/obj/usr/src/sys/FS i386 > > Same problem, am I missing something obvious here? This does not look lik= e > the correct numbers: > [ 4] local 127.0.0.1 port 5001 connected with 127.0.0.1 port 58497 > [ 4] 0.0-10.5 sec 172 MBytes 137 Mbits/sec > > > CPU: Intel(R) Pentium(R) D CPU 2.80GHz (2856.02-MHz 686-class CPU) > Origin =3D "GenuineIntel" Id =3D 0xf47 Stepping =3D 7 > Features=3D0xbfebfbff > Features2=3D0x641d > AMD Features=3D0x20100000 > AMD Features2=3D0x1 > Cores per package: 2 > real memory =3D 1072562176 (1022 MB) > avail memory =3D 1036025856 (988 MB) > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > > -- > St=E5le Kristoffersen > _______________________________________________ > 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 Jul 16 19:48:58 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0EA3416A401 for ; Mon, 16 Jul 2007 19:48:58 +0000 (UTC) (envelope-from stevenschlansker@berkeley.edu) Received: from smtp-out1.berkeley.edu (smtp-out1.Berkeley.EDU [128.32.61.106]) by mx1.freebsd.org (Postfix) with ESMTP id F0E9713C481 for ; Mon, 16 Jul 2007 19:48:57 +0000 (UTC) (envelope-from stevenschlansker@berkeley.edu) Received: from adsl-75-42-136-243.dsl.pltn13.sbcglobal.net ([75.42.136.243] helo=[192.168.42.2]) by fe2.calmail with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (auth plain:stevenschlansker@berkeley.edu) (envelope-from ) id 1IAWYz-0002h9-8e for freebsd-current@freebsd.org; Mon, 16 Jul 2007 12:48:57 -0700 Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <2978EDA9-D393-434C-B734-2DE188631761@berkeley.edu> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: freebsd-current@freebsd.org From: Steven Schlansker Date: Mon, 16 Jul 2007 12:48:46 -0700 X-Mailer: Apple Mail (2.752.3) Subject: Strange performance characteristics with ZFS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Jul 2007 19:48:58 -0000 Hello everyone, I'm experiencing what (to me) seems to be strange performance with ZFS. I have it set up as follows: [steven@universe /universe]$ sudo zpool status pool: universe state: ONLINE scrub: resilver completed with 0 errors on Mon Jul 16 10:33:52 2007 config: NAME STATE READ WRITE CKSUM universe ONLINE 0 0 0 raidz1 ONLINE 0 0 0 ad10 ONLINE 0 0 0 ad6 ONLINE 0 0 0 ad4 ONLINE 0 0 0 raidz1 ONLINE 0 0 0 ad12 ONLINE 0 0 0 ad16 ONLINE 0 0 0 ad14 ONLINE 0 0 0 I share it over NFS to a linux machine. I'm trying to write a very large (30GB) disk image to it over nfs, and it goes in short fits and bursts. It copies a few (mega?)bytes of data (not sure how much exactly), and top shows: 605 root 1 4 0 3616K 1068K - 1:17 5.18% nfsd 603 root 1 4 0 3616K 1068K - 1:33 4.69% nfsd 602 root 1 4 0 3616K 1068K - 1:09 4.35% nfsd 604 root 1 4 0 3616K 1068K - 1:24 3.66% nfsd Then, the copy on the linux box freezes entirely and top shows: 603 root 1 -4 0 3616K 1068K zfs:(& 1:34 4.98% nfsd 605 root 1 -4 0 3616K 1068K zfs 1:17 4.25% nfsd 604 root 1 -4 0 3616K 1068K zfs 1:24 4.05% nfsd 602 root 1 -4 0 3616K 1068K zfs 1:10 3.96% nfsd While the nfsds are stuck in the 'zfs' state, ssh is very unresponsive (few seconds per keystroke) After a few seconds of being hung like this, the copy resumes and the nfsds go back to a blank state. I guess the ssh hanging is the most annoying symptom, as it makes it hard to use the system while copying. It would be nice to speed the transfers up too though. Is this expected behavior? Is there some way I can make it run faster/better? [steven@universe /universe]$ uname -a FreeBSD universe.stevenschlansker.is-a-geek.org 7.0-CURRENT FreeBSD 7.0-CURRENT #1: Thu Jul 12 11:48:11 PDT 2007 root@universe.stevenschlansker.is-a-geek.org:/usr/obj/usr/src/sys/ GENERIC amd64 Thanks, Steven From owner-freebsd-current@FreeBSD.ORG Mon Jul 16 20:16:23 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DB52116A400 for ; Mon, 16 Jul 2007 20:16:23 +0000 (UTC) (envelope-from kometen@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.228]) by mx1.freebsd.org (Postfix) with ESMTP id 9AD9E13C4A7 for ; Mon, 16 Jul 2007 20:16:23 +0000 (UTC) (envelope-from kometen@gmail.com) Received: by wx-out-0506.google.com with SMTP id i29so1055709wxd for ; Mon, 16 Jul 2007 13:16:22 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=oUvQJDnnQ+pgAuFmcgT2Ifb60DH1EF4GtesdhPofwb6OJEj0Snjc8igvEsgRdzY+zW1ZaSKyAQItTpiZNFaaIN2g8fOVzmEJBHjA55oHutGdpM1858jXmYMohzci2IfyD+5chf49fbPzkEcxGRw/9E3anYux6t7eURrjLBUijGY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=pJfM2g7eUwIOfsjkbCdumhfx9JIQWronMkrECocD9/fBPBplmwtt1gqInEy5PLYKMJUGg4TI4RMmXtMef4kaAdgz2i+IhDXCEDqmdRGpNQIqmIgUk8LV2vq0PsXNznmAVzgL5zYS4/OfpN9NW2OcuUIXVWCW3CL10WE+gMF1sQA= Received: by 10.90.93.6 with SMTP id q6mr3743372agb.1184616982673; Mon, 16 Jul 2007 13:16:22 -0700 (PDT) Received: by 10.70.41.4 with HTTP; Mon, 16 Jul 2007 13:16:22 -0700 (PDT) Message-ID: Date: Mon, 16 Jul 2007 22:16:22 +0200 From: "Claus Guttesen" To: "Steven Schlansker" In-Reply-To: <2978EDA9-D393-434C-B734-2DE188631761@berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <2978EDA9-D393-434C-B734-2DE188631761@berkeley.edu> Cc: freebsd-current@freebsd.org Subject: Re: Strange performance characteristics with ZFS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Jul 2007 20:16:23 -0000 > I'm experiencing what (to me) seems to be strange performance with > ZFS. I have it set up as follows: > > [steven@universe /universe]$ sudo zpool status > pool: universe > state: ONLINE > I share it over NFS to a linux machine. I'm trying to write a very > large (30GB) disk image to it over nfs, and it goes in short fits and > bursts. > > It copies a few (mega?)bytes of data (not sure how much exactly), and > top shows: How much ram is installed? -- regards Claus When lenity and cruelty play for a kingdom, the gentlest gamester is the soonest winner. Shakespeare From owner-freebsd-current@FreeBSD.ORG Mon Jul 16 20:17:28 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6165116A40A for ; Mon, 16 Jul 2007 20:17:28 +0000 (UTC) (envelope-from freebsd@superhero.nl) Received: from superman.superhero.nl (superhero.nl [82.95.198.17]) by mx1.freebsd.org (Postfix) with ESMTP id C3A1C13C4B8 for ; Mon, 16 Jul 2007 20:17:27 +0000 (UTC) (envelope-from freebsd@superhero.nl) Received: (qmail 89193 invoked by uid 80); 16 Jul 2007 20:17:29 -0000 Received: from robin.ad.superhero.nl ([10.202.77.103]) (SquirrelMail authenticated user gelsemap) by webmail.superhero.nl with HTTP; Mon, 16 Jul 2007 22:17:29 +0200 (CEST) Message-ID: <3509.10.202.77.103.1184617049.squirrel@webmail.superhero.nl> In-Reply-To: <20070716153904.GA22220@nowhere> References: <1185.10.202.77.103.1184365805.squirrel@webmail.superhero.nl> <20070716153904.GA22220@nowhere> Date: Mon, 16 Jul 2007 22:17:29 +0200 (CEST) From: "Gelsema, P \(Patrick\) - FreeBSD" To: freebsd-current@freebsd.org User-Agent: SquirrelMail/1.4.8 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: Re: Console output stops - machine keeps on working X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Jul 2007 20:17:28 -0000 On Mon, July 16, 2007 17:39, Craig Boston wrote: > On Sat, Jul 14, 2007 at 12:30:05AM +0200, Gelsema, P (Patrick) - FreeBSD > wrote: >> I am running FreeBSD 7-Current-200706. Everything seems to be detected >> during boot and all goes ok until the moment the message that the fxp0 >> link state changed to up. After that moment the console output stops. I >> cannot get to other tty;s or get output running again. >> >> However the machine is responsive and I can log on by SSH remotely and >> do >> everything as if I were at the console. When I login by typing blind at >> the console and issue the reboot command or when I press the power off >> button on the workstation the console shows output again (not any use as >> it is then rebooting or powering off). >> >> See http://www.superhero.nl/messages.txt for the message output during >> boot. >> >> Anyone seen this kind of behaviour? > > I've been seeing this intermittently on a relatively recent -current. > It seems to have started when I added KDB/DDB to the kernel config, but > I haven't disabled it yet to see for sure if that's the culprit. > > Mine is an SMP (dual-core) system if it makes any difference. It stops > right after a 'bge0: link up' message. > > Craig > AMD Athlon X2 (AMD version of DUal Core) on an Asus M2N motherboard. Problem started after installing the latest Bios. I see this problem only when running AMD64 version. With I386 no problems. I installed I386 as AMD64 gave too many problems such as mangled entries and unable to mount / after buildworld and a reboot. It seems that it has to do with memory and the memory hole. Patrick From owner-freebsd-current@FreeBSD.ORG Mon Jul 16 20:50:27 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 783D016A40A for ; Mon, 16 Jul 2007 20:50:27 +0000 (UTC) (envelope-from craig@xfoil.gank.org) Received: from ion.gank.org (ion.gank.org [69.55.238.164]) by mx1.freebsd.org (Postfix) with ESMTP id 5521C13C48D for ; Mon, 16 Jul 2007 20:50:25 +0000 (UTC) (envelope-from craig@xfoil.gank.org) Received: by ion.gank.org (Postfix, from userid 1001) id 9F79211579; Mon, 16 Jul 2007 15:50:24 -0500 (CDT) Date: Mon, 16 Jul 2007 15:50:19 -0500 From: Craig Boston To: "Gelsema, P (Patrick) - FreeBSD" Message-ID: <20070716205019.GB22220@nowhere> Mail-Followup-To: Craig Boston , "Gelsema, P (Patrick) - FreeBSD" , freebsd-current@freebsd.org References: <1185.10.202.77.103.1184365805.squirrel@webmail.superhero.nl> <20070716153904.GA22220@nowhere> <3509.10.202.77.103.1184617049.squirrel@webmail.superhero.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3509.10.202.77.103.1184617049.squirrel@webmail.superhero.nl> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: Console output stops - machine keeps on working X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Jul 2007 20:50:27 -0000 On Mon, Jul 16, 2007 at 10:17:29PM +0200, Gelsema, P (Patrick) - FreeBSD wrote: > AMD Athlon X2 (AMD version of DUal Core) on an Asus M2N motherboard. > Problem started after installing the latest Bios. I see this problem only > when running AMD64 version. With I386 no problems. Hmmm, the one I see it on is an Intel Pentium D system with a Dell-branded motherboard (looks like all or mostly intel chipset), running i386, and there have been no changes to the bios lately. So I think hardware can be ruled out :-) From owner-freebsd-current@FreeBSD.ORG Mon Jul 16 21:34:21 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 43FD116A405 for ; Mon, 16 Jul 2007 21:34:21 +0000 (UTC) (envelope-from staale@kristoffersen.ws) Received: from smtp.bluecom.no (smtp.bluecom.no [193.75.75.28]) by mx1.freebsd.org (Postfix) with ESMTP id 06CC413C4CC for ; Mon, 16 Jul 2007 21:34:20 +0000 (UTC) (envelope-from staale@kristoffersen.ws) Received: from eschew.pusen.org (unknown [193.69.145.10]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.bluecom.no (Postfix) with ESMTP id AB1EC16F524; Mon, 16 Jul 2007 23:34:19 +0200 (CEST) Received: from chiller by eschew.pusen.org with local (Exim 4.50) id 1IAYD3-0007vC-Li; Mon, 16 Jul 2007 23:34:25 +0200 Date: Mon, 16 Jul 2007 23:34:25 +0200 From: =?iso-8859-1?Q?St=E5le?= Kristoffersen To: Kip Macy Message-ID: <20070716213425.GB19282@eschew.pusen.org> References: <20070716190441.GA19282@eschew.pusen.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) Cc: current@freebsd.org Subject: Re: Slow networkperformance in current? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2007 21:34:21 -0000 On 2007-07-16 at 12:47, Kip Macy wrote: > 10 GigE cards are doing line rate - over time the cpu usage required > to do so is going down. Your experience is probably due to NIC issues. > What kind of NIC are you using? And have you changed any configuration > or settings? I was thinking of the NIC, thats why I tried it on localhost (bypassing the NIC(?)). I'm using a re-nick: re0: port 0x7e00-0x7eff mem 0xfd3ff000-0xfd3fffff irq 18 at device 0.0 on pci3 I have not changed anything, except upgrading the world + kernel. No hardware was added, no bios-settings where changed. The only thing I can think of is that I might have changed a sysctl a long time ago that boosted my performance, and that change have been lost after the reboot. -- Ståle Kristoffersen staalebk@ifi.uio.no From owner-freebsd-current@FreeBSD.ORG Mon Jul 16 21:56:04 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 22BC816A401 for ; Mon, 16 Jul 2007 21:56:04 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from mxout4.cac.washington.edu (mxout4.cac.washington.edu [140.142.33.19]) by mx1.freebsd.org (Postfix) with ESMTP id 019F413C4B2 for ; Mon, 16 Jul 2007 21:56:03 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from hymn01.u.washington.edu (hymn01.u.washington.edu [140.142.8.55]) by mxout4.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.06) with ESMTP id l6GLu32L019333 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Jul 2007 14:56:03 -0700 Received: from localhost (localhost [127.0.0.1]) by hymn01.u.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l6GLu2Di015937; Mon, 16 Jul 2007 14:56:02 -0700 X-Auth-Received: from [192.55.52.3] by hymn01.u.washington.edu via HTTP; Mon, 16 Jul 2007 14:56:02 PDT Date: Mon, 16 Jul 2007 14:56:02 -0700 (PDT) From: youshi10@u.washington.edu To: Milos Vyletel In-Reply-To: <20070716132326.GA28016@rulez.sk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-PMX-Version: 5.3.2.304607, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.7.16.143734 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='SUPERLONG_LINE 0.05, NO_REAL_NAME 0, __CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' Cc: current@freebsd.org Subject: Large amounts of memory access operations cause panic under CURRENT (was "Large gap between fwrite and write, and fread and read") X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Jul 2007 21:56:04 -0000 On Mon, 16 Jul 2007, Milos Vyletel wrote: > On Mon, Jul 16, 2007 at 05:06:57AM -0700, Garrett Cooper wrote: >> Hello again Hackers, >> I ran some tests and I noticed a large difference in the cumulative >> sums of fwrite(2) vs write(3) and fread(2) vs read(3) (3-fold >> differences on a real machine). >> Please download >> , take a look at >> README for some results, and read for more details on how you can run >> the tests as well if curious, and feel free to send me the results if >> desired. If you do run the tests, please don't use the /tmp disk at all >> on the machine as it will most likely skew parts of the test, and please >> pay heed to the warning, otherwise the test box may become unusable. >> One thing that has me puzzled though... why is there such a large >> difference? Is it because fread(2) allows object by object instantiation >> (i.e. preallocates objects according to sizeof and returns the number of >> allocated figures), whereas read(3) just reads in raw lengths and >> returns the amount of chars scanned in? Does the same logic apply for >> fwrite(2) and write(3)? >> Thanks, >> -Garrett -- I really need to go to bed earlier.. haha. >> _______________________________________________ > > Hi, > > This is kinda off topic, but with this test and more than hundred thousand (actually about 190000 is enough) iterations I'm able to crash my amd64 machine with kmem_map too small panic. This is 6 days old current with zfs on root. > > So this panic is not only i386 specific thing :\ > > mv Go figure it'd cause panics for other people. I wasn't using zfs at all but it panicked anyhow once (my amd64 VM only, not my i386 test server, surprisingly). I wish I'd gotten the panic but I walked away to get a glass of water, and there wasn't a core dump because the VM shut down completely instead of restarting. Heh. My virtual machine died around 90k on the first trial though. I'll be sure to reduce the amount and see what happens, and I'll put nanosleeps or usleeps between the read and write ops to see if that alleviates the race condition seen, but I'll keep the problem code around for reference later in case I've stimulated some sort of weird bug in FreeBSD, or otherwise. Both my VM and test server run almost no programs though other than samba and rsync, so you'll probably see the panic faster / more frequently than I will if you run a lot more programs resident in memory. Just curious, what scheduler are you using on CURRENT, what processor do you have, and what are your memory specs? Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Mon Jul 16 22:53:08 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4E18F16A40B for ; Mon, 16 Jul 2007 22:53:08 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.175]) by mx1.freebsd.org (Postfix) with ESMTP id C495A13C4A5 for ; Mon, 16 Jul 2007 22:53:07 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: by ug-out-1314.google.com with SMTP id o4so31961uge for ; Mon, 16 Jul 2007 15:53:06 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=bSyIyrEZ+eA/WDYvo92iEaFbmkxy8wJ1OALKC94XPZc+gUVE0O1Vp+ahRbQKKHDiG5lAj2WQrYFd6QgIKI29udgWJVzKFzRj/BWvvzJw7jPAa4DLbgk8hshcMt3erfDWFUOACtjcl7Zp/rpYgbMoMf28YJATnjkCIFoNBwkX4Yw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=fDB44MSPHd/8a5A5tYci/zoSR1CgPTnrCZ1Cf/fbFQz9v9eKHWfSnmZBZ6QTquHCz87xTZwJNWpXs5rWCujn08joEK2StsUGjzMuh3fSmKfMLuIdnWmb/xofCOLwVq1mR6064kfVu0xOGiHYGRfPX14UcgaaC5L6eC+OepkpNCw= Received: by 10.78.123.5 with SMTP id v5mr1292972huc.1184626386559; Mon, 16 Jul 2007 15:53:06 -0700 (PDT) Received: by 10.78.162.18 with HTTP; Mon, 16 Jul 2007 15:53:06 -0700 (PDT) Message-ID: Date: Mon, 16 Jul 2007 15:53:06 -0700 From: "Kip Macy" To: "=?ISO-8859-1?Q?St=E5le_Kristoffersen?=" In-Reply-To: <20070716213425.GB19282@eschew.pusen.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <20070716190441.GA19282@eschew.pusen.org> <20070716213425.GB19282@eschew.pusen.org> Cc: current@freebsd.org Subject: Re: Slow networkperformance in current? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2007 22:53:08 -0000 On 7/16/07, St=E5le Kristoffersen wrote: > On 2007-07-16 at 12:47, Kip Macy wrote: > > 10 GigE cards are doing line rate - over time the cpu usage required > > to do so is going down. Your experience is probably due to NIC issues. > > What kind of NIC are you using? And have you changed any configuration > > or settings? > > I was thinking of the NIC, thats why I tried it on localhost (bypassing t= he > NIC(?)). > I'm using a re-nick: > re0: port 0x7e00-0x7eff mem > 0xfd3ff000-0xfd3fffff irq 18 at device 0.0 on pci3 > > I have not changed anything, except upgrading the world + kernel. No > hardware was added, no bios-settings where changed. The only thing I can > think of is that I might have changed a sysctl a long time ago that boost= ed > my performance, and that change have been lost after the reboot. Please post the config you are using. -Kip From owner-freebsd-current@FreeBSD.ORG Mon Jul 16 23:31:42 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 363D916A401 for ; Mon, 16 Jul 2007 23:31:42 +0000 (UTC) (envelope-from mv@rulez.sk) Received: from mail.rulez.sk (DaEmoN.RuLeZ.sK [84.16.32.226]) by mx1.freebsd.org (Postfix) with ESMTP id EE5CD13C471 for ; Mon, 16 Jul 2007 23:31:41 +0000 (UTC) (envelope-from mv@rulez.sk) Received: from localhost (localhost [127.0.0.1]) by mail.rulez.sk (Postfix) with ESMTP id 102935C36 for ; Tue, 17 Jul 2007 01:13:49 +0200 (CEST) X-Virus-Scanned: by amavisd-new at mail.rulez.sk Received: by mail.rulez.sk (Postfix, from userid 1020) id E984D5C2D; Tue, 17 Jul 2007 01:13:45 +0200 (CEST) Date: Tue, 17 Jul 2007 01:13:45 +0200 From: Milos Vyletel To: current@freebsd.org Message-ID: <20070716231345.GA43427@rulez.sk> References: <20070716132326.GA28016@rulez.sk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i Cc: Subject: Re: Large amounts of memory access operations cause panic under CURRENT (was "Large gap between fwrite and write, and fread and read") X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Jul 2007 23:31:42 -0000 >> Go figure it'd cause panics for other people. >> >> I wasn't using zfs at all but it panicked anyhow once (my amd64 VM only, >> not my i386 test server, surprisingly). I wish I'd gotten the panic but I >> walked away to get a glass of water, and there wasn't a core dump because >> the VM shut down completely instead of restarting. Heh. >> >> My virtual machine died around 90k on the first trial though. I'll be sure >> to reduce the amount and see what happens, and I'll put nanosleeps or >> usleeps between the read and write ops to see if that alleviates the race >> condition seen, but I'll keep the problem code around for reference later >> in case I've stimulated some sort of weird bug in FreeBSD, or otherwise. >> >> Both my VM and test server run almost no programs though other than samba >> and rsync, so you'll probably see the panic faster / more frequently than I >> will if you run a lot more programs resident in memory. >> >> Just curious, what scheduler are you using on CURRENT, what processor do >> you have, and what are your memory specs? >> >> Thanks, >> -Garrett >> > Hi Garrett, > > this is just my desktop where is running only Xorg, fluxbox, few aterms and > firefox. But i can get the panic on console too, shortly after booting. I'm > using SCHED_ULE. > > CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ (2205.01-MHz K8-class > CPU) > Origin = "AuthenticAMD" Id = 0x20f32 Stepping = 2 > Features=0x178bfbff > Features2=0x1 > AMD Features=0xe2500800 > AMD Features2=0x3 > Cores per package: 2 > usable memory = 3211718656 (3062 MB) > avail memory = 3105570816 (2961 MB) > > For the record, it crashes few times before it hit 100k iterations, before i > put > debug printf in your code and increase MAX_ITERATIONS to 1m. And as far as I > can tell, I had pretty much the same results as you've measured. > > mv Sorry for the noise, forgot to CC current@ From owner-freebsd-current@FreeBSD.ORG Mon Jul 16 23:32:57 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DE79B16A404 for ; Mon, 16 Jul 2007 23:32:57 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.181]) by mx1.freebsd.org (Postfix) with ESMTP id B450013C4A6 for ; Mon, 16 Jul 2007 23:32:57 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by wa-out-1112.google.com with SMTP id j37so1943667waf for ; Mon, 16 Jul 2007 16:32:57 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=rvUrJJMIRmxNKPrqaDwzZt8RjJB61UHd9iMEDg6cZ8NhxclkqefanI3CZRKpfncPgQx4gNTlhy+++teqsTWhQEEraZzXd8XPfkjuEqt/nsGB0PZPK5b8fmCvuTBfaqgNVWHt7Yt8cAt2C1PjPU/3Q7gjysqlU0+7K4XH9FoXqM4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=aYjs1O09wiXmJ/NU4+t1KwRotEn1+d0A2LdVcff6xTZcK2lulrMHtw64gHI1O7c4/IO5wtn9nTXFP58CVNYK5ZxBrIRj0BZahkNvK4ojS11qGedDKU0nARylpUBKzV1FeGPA3jM+yNeYh87FI+cYkdpSOutWoElHefW/RBN0XJA= Received: by 10.115.76.1 with SMTP id d1mr4581334wal.1184627258876; Mon, 16 Jul 2007 16:07:38 -0700 (PDT) Received: by 10.114.103.14 with HTTP; Mon, 16 Jul 2007 16:07:38 -0700 (PDT) Message-ID: <2a41acea0707161607o55b90e27ob04beb1ec1856be2@mail.gmail.com> Date: Mon, 16 Jul 2007 16:07:38 -0700 From: "Jack Vogel" To: "Kip Macy" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <20070716190441.GA19282@eschew.pusen.org> <20070716213425.GB19282@eschew.pusen.org> Cc: current@freebsd.org, =?ISO-8859-1?Q?St=E5le_Kristoffersen?= Subject: Re: Slow networkperformance in current? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2007 23:32:58 -0000 On 7/16/07, Kip Macy wrote: > On 7/16/07, St=E5le Kristoffersen wrote: > > On 2007-07-16 at 12:47, Kip Macy wrote: > > > 10 GigE cards are doing line rate - over time the cpu usage required > > > to do so is going down. Your experience is probably due to NIC issues= . > > > What kind of NIC are you using? And have you changed any configuratio= n > > > or settings? > > > > I was thinking of the NIC, thats why I tried it on localhost (bypassing= the > > NIC(?)). > > I'm using a re-nick: > > re0: port 0x7e00-0x7eff mem > > 0xfd3ff000-0xfd3fffff irq 18 at device 0.0 on pci3 > > > > I have not changed anything, except upgrading the world + kernel. No > > hardware was added, no bios-settings where changed. The only thing I ca= n > > think of is that I might have changed a sysctl a long time ago that boo= sted > > my performance, and that change have been lost after the reboot. > > Please post the config you are using. You dont have the WITNESS and INVARIANTS stuff on do you? From owner-freebsd-current@FreeBSD.ORG Mon Jul 16 23:36:15 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 589ED16A4F5 for ; Mon, 16 Jul 2007 23:36:01 +0000 (UTC) (envelope-from staale@kristoffersen.ws) Received: from smtp.bluecom.no (smtp.bluecom.no [193.75.75.28]) by mx1.freebsd.org (Postfix) with ESMTP id 80E5A13C441 for ; Mon, 16 Jul 2007 23:36:01 +0000 (UTC) (envelope-from staale@kristoffersen.ws) Received: from eschew.pusen.org (unknown [193.69.145.10]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.bluecom.no (Postfix) with ESMTP id 12DB716F710; Tue, 17 Jul 2007 01:36:00 +0200 (CEST) Received: from chiller by eschew.pusen.org with local (Exim 4.50) id 1IAa6i-0001gI-79; Tue, 17 Jul 2007 01:36:00 +0200 Date: Tue, 17 Jul 2007 01:36:00 +0200 From: =?iso-8859-1?Q?St=E5le?= Kristoffersen To: Kip Macy Message-ID: <20070716233600.GC19282@eschew.pusen.org> References: <20070716190441.GA19282@eschew.pusen.org> <20070716213425.GB19282@eschew.pusen.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) Cc: current@freebsd.org Subject: Re: Slow networkperformance in current? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2007 23:36:15 -0000 On 2007-07-16 at 15:53, Kip Macy wrote: > Please post the config you are using. lrwxr-xr-x 1 root wheel 2B Apr 12 15:42 /etc/malloc.conf -> aj /etc/sysctl.conf: vfs.vmiodirenable=1 net.inet.tcp.delayed_ack=0 net.inet.ip.forwarding=1 net.inet.tcp.inflight.enable=0 (I have tried commenting out all those lines, no difference. See attached dmesg and kernelconfig. Is there anything else that might be helpfull just let me know. PS, posted the wrong uname -a message in the last mail, here is the correct one: FreeBSD 7.0-CURRENT #10: Mon Jul 16 18:40:28 CEST 2007 root@fs:/usr/obj/usr/src/sys/FS i386 -- Ståle Kristoffersen From owner-freebsd-current@FreeBSD.ORG Mon Jul 16 23:44:14 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E422416A401 for ; Mon, 16 Jul 2007 23:44:14 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.175]) by mx1.freebsd.org (Postfix) with ESMTP id 7689E13C4B5 for ; Mon, 16 Jul 2007 23:44:14 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: by ug-out-1314.google.com with SMTP id o4so38782uge for ; Mon, 16 Jul 2007 16:44:13 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=FKLcUxIMzIEOfjzu++t/ravvkb6mw+k/wCHbJbQw0T8OLU0rjpPUptf4a/VEtIF6wuhBn8QeypLIu8nkiCOrOeVtMAOJQtlVxkN8/mwiPtc86Tj7lSCLLv9c+Uv3HEA2KaAf2DA04UgiLh9BncvDVRAusWGjOxVzmkRDsXaKMLc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=J4XtAH2U/0CowFjl1bNwtw0/qtRqy9sHKmdRR8eC5ZrPHNitdLEtaDiz/el2MYpiUv4Djw+Lbb6NYW96/oHSFIZYIwq3bmYX7kHZZciMmol65hXrbBKv35WrjtXIZYW+FPzbjsd6C82/HuUafaYxFsv5rTeDLCCOnfJu1NaIbrc= Received: by 10.78.204.7 with SMTP id b7mr1302148hug.1184629453295; Mon, 16 Jul 2007 16:44:13 -0700 (PDT) Received: by 10.78.162.18 with HTTP; Mon, 16 Jul 2007 16:44:13 -0700 (PDT) Message-ID: Date: Mon, 16 Jul 2007 16:44:13 -0700 From: "Kip Macy" To: "=?ISO-8859-1?Q?St=E5le_Kristoffersen?=" In-Reply-To: <20070716233600.GC19282@eschew.pusen.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <20070716190441.GA19282@eschew.pusen.org> <20070716213425.GB19282@eschew.pusen.org> <20070716233600.GC19282@eschew.pusen.org> Cc: current@freebsd.org Subject: Re: Slow networkperformance in current? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2007 23:44:15 -0000 I didn't get any attachments. -Kip On 7/16/07, St=E5le Kristoffersen wrote: > On 2007-07-16 at 15:53, Kip Macy wrote: > > Please post the config you are using. > > lrwxr-xr-x 1 root wheel 2B Apr 12 15:42 /etc/malloc.conf -> aj > > /etc/sysctl.conf: > vfs.vmiodirenable=3D1 > net.inet.tcp.delayed_ack=3D0 > net.inet.ip.forwarding=3D1 > net.inet.tcp.inflight.enable=3D0 > > (I have tried commenting out all those lines, no difference. > > See attached dmesg and kernelconfig. > Is there anything else that might be helpfull just let me know. > > PS, posted the wrong uname -a message in the last mail, here is the corre= ct > one: > FreeBSD 7.0-CURRENT #10: Mon Jul 16 18:40:28 CEST 2007 > root@fs:/usr/obj/usr/src/sys/FS i386 > -- > St=E5le Kristoffersen > From owner-freebsd-current@FreeBSD.ORG Mon Jul 16 23:44:56 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2C97416A403 for ; Mon, 16 Jul 2007 23:44:56 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.172]) by mx1.freebsd.org (Postfix) with ESMTP id 6980C13C4A3 for ; Mon, 16 Jul 2007 23:44:55 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: by ug-out-1314.google.com with SMTP id o4so38878uge for ; Mon, 16 Jul 2007 16:44:54 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=hQxlAR/uygflqhX1ZLFHEyAkwKjR5U/aJN75ddVdOhSsCY0cAHM+CfPivg1Umuo902cQJHxMyveeqk9tHHQ31goioUtl3tgmArx4nnkmOJXa/az9WULl5bl7fNG30a0uWlIWsKMhrCH13xYJsorUEo6RBcrjz2C924TB3cNIeVk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Yt1hT17oCfXqZ0aioEUnMpyG+aSdLD9w/tEy/vli212AnhDm+YyA8oWB5BgL0ygxl6NT3iRWNUrPoxtI1NODBlwGyfTZqb49WKZh0gJnK067PPj1//9Sqiju1tFR301lM1Q2sYj+ENGqjUh3ToRHgt4msg1yI+4SaOqlb1ui0As= Received: by 10.78.160.2 with SMTP id i2mr1300874hue.1184629494356; Mon, 16 Jul 2007 16:44:54 -0700 (PDT) Received: by 10.78.162.18 with HTTP; Mon, 16 Jul 2007 16:44:54 -0700 (PDT) Message-ID: Date: Mon, 16 Jul 2007 16:44:54 -0700 From: "Kip Macy" To: "Jack Vogel" In-Reply-To: <2a41acea0707161607o55b90e27ob04beb1ec1856be2@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070716190441.GA19282@eschew.pusen.org> <20070716213425.GB19282@eschew.pusen.org> <2a41acea0707161607o55b90e27ob04beb1ec1856be2@mail.gmail.com> Cc: current@freebsd.org, =?ISO-8859-1?Q?St=E5le_Kristoffersen?= Subject: Re: Slow networkperformance in current? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2007 23:44:56 -0000 > You dont have the WITNESS and INVARIANTS stuff on do you? > He claims he doesn't, I have a small suspicion that they crept back in in the cvsup. From owner-freebsd-current@FreeBSD.ORG Mon Jul 16 23:48:19 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 722C616A401 for ; Mon, 16 Jul 2007 23:48:19 +0000 (UTC) (envelope-from staale@kristoffersen.ws) Received: from smtp.bluecom.no (smtp.bluecom.no [193.75.75.28]) by mx1.freebsd.org (Postfix) with ESMTP id AC0DD13C47E for ; Mon, 16 Jul 2007 23:48:18 +0000 (UTC) (envelope-from staale@kristoffersen.ws) Received: from eschew.pusen.org (unknown [193.69.145.10]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.bluecom.no (Postfix) with ESMTP id 9EB0B12C010; Tue, 17 Jul 2007 01:48:17 +0200 (CEST) Received: from chiller by eschew.pusen.org with local (Exim 4.50) id 1IAaIb-0001sl-RT; Tue, 17 Jul 2007 01:48:17 +0200 Date: Tue, 17 Jul 2007 01:48:17 +0200 From: =?iso-8859-1?Q?St=E5le?= Kristoffersen To: Kip Macy Message-ID: <20070716234817.GD19282@eschew.pusen.org> References: <20070716190441.GA19282@eschew.pusen.org> <20070716213425.GB19282@eschew.pusen.org> <20070716233600.GC19282@eschew.pusen.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="2oS5YaxWCcQjTEyO" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) Cc: current@freebsd.org Subject: Re: Slow networkperformance in current? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2007 23:48:19 -0000 --2oS5YaxWCcQjTEyO Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit On 2007-07-16 at 16:44, Kip Macy wrote: > I didn't get any attachments. Guess it's about time to get some sleep soon... Here they are. -- Ståle Kristoffersen staalebk@ifi.uio.no --2oS5YaxWCcQjTEyO Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="dmesg.boot" Copyright (c) 1992-2007 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.0-CURRENT #10: Mon Jul 16 18:40:28 CEST 2007 root@fs:/usr/obj/usr/src/sys/FS MPTable: Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) D CPU 2.80GHz (2856.02-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf47 Stepping = 7 Features=0xbfebfbff Features2=0x641d AMD Features=0x20100000 AMD Features2=0x1 Cores per package: 2 real memory = 1072562176 (1022 MB) avail memory = 1036025856 (988 MB) FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 4 ioapic0: Assuming intbase of 0 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) cpu0 on motherboard cpu1 on motherboard pcib0: pcibus 0 on motherboard pci0: on pcib0 pcib1: irq 16 at device 1.0 on pci0 pci1: on pcib1 vgapci0: mem 0xf4000000-0xf7ffffff,0xd8000000-0xdfffffff,0xfa000000-0xfaffffff irq 16 at device 0.0 on pci1 pci0: at device 27.0 (no driver attached) pcib2: irq 16 at device 28.0 on pci0 pci2: on pcib2 pcib3: irq 18 at device 28.2 on pci0 pci3: on pcib3 re0: port 0x7e00-0x7eff mem 0xfd3ff000-0xfd3fffff irq 18 at device 0.0 on pci3 miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto re0: Ethernet address: 00:50:8d:95:d8:83 re0: [FILTER] pcib4: irq 19 at device 28.3 on pci0 pci4: on pcib4 atapci0: port 0xcf00-0xcf7f mem 0xfddff000-0xfddff07f,0xfddf8000-0xfddfbfff irq 19 at device 0.0 on pci4 atapci0: [ITHREAD] ata2: on atapci0 ata2: [ITHREAD] ata3: on atapci0 ata3: [ITHREAD] pcib5: irq 16 at device 28.4 on pci0 pci5: on pcib5 re1: port 0xbe00-0xbeff mem 0xfdbff000-0xfdbfffff irq 16 at device 0.0 on pci5 miibus1: on re1 rgephy1: PHY 1 on miibus1 rgephy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto re1: Ethernet address: 00:50:8d:95:d8:84 re1: [FILTER] pcib6: irq 17 at device 28.5 on pci0 pci6: on pcib6 atapci1: port 0xaf00-0xaf07,0xae00-0xae03,0xad00-0xad07,0xac00-0xac03,0xab00-0xab0f mem 0xfd9fe000-0xfd9fffff irq 17 at device 0.0 on pci6 atapci1: [ITHREAD] atapci1: AHCI Version 01.00 controller with 2 ports detected ata4: on atapci1 ata4: [ITHREAD] ata5: on atapci1 ata5: [ITHREAD] ata6: on atapci1 ata6: [ITHREAD] pcib7: at device 30.0 on pci0 pci7: on pcib7 isab0: at device 31.0 on pci0 isa0: on isab0 atapci2: port 0xfa00-0xfa07,0xf900-0xf903,0xf800-0xf807,0xf700-0xf703,0xf600-0xf60f,0xf500-0xf50f irq 19 at device 31.2 on pci0 atapci2: [ITHREAD] ata7: on atapci2 ata7: [ITHREAD] ata8: on atapci2 ata8: [ITHREAD] pci0: at device 31.3 (no driver attached) atapci3: port 0xf300-0xf307,0xf200-0xf203,0xf100-0xf107,0xf000-0xf003,0xef00-0xef0f,0xee00-0xee0f irq 19 at device 31.5 on pci0 atapci3: [ITHREAD] ata9: on atapci3 ata9: [ITHREAD] ata10: on atapci3 ata10: [ITHREAD] pmtimer0 on isa0 orm0: at iomem 0xc0000-0xcefff,0xd0000-0xd27ff,0xef000-0xeffff pnpid ORM0000 on isa0 ata0 at port 0x1f0-0x1f7,0x3f6 irq 14 on isa0 ata0: [ITHREAD] ata1 at port 0x170-0x177,0x376 irq 15 on isa0 ata1: [ITHREAD] atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] ppc0: parallel port not found. sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 8250 or not responding sio0: [FILTER] 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 unknown: can't assign resources (port) unknown: can't assign resources (memory) unknown: can't assign resources (memory) Timecounters tick every 1.000 msec ad8: 305245MB at ata4-master SATA300 ad10: 381554MB at ata5-master SATA150 ad12: 305245MB at ata6-master UDMA100 ad14: 305245MB at ata7-master SATA150 ad15: 305245MB at ata7-slave SATA150 ad16: 305245MB at ata8-master SATA150 ad17: 381554MB at ata8-slave SATA150 SMP: AP CPU #1 Launched! Trying to mount root from ufs:/dev/ad10s1a WARNING: ZFS is considered to be an experimental feature in FreeBSD. ZFS filesystem version 6 ZFS storage pool version 6 --2oS5YaxWCcQjTEyO Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=FS # cpu I686_CPU ident FS # To statically compile in device wiring instead of /boot/device.hints #hints "GENERIC.hints" # Default places to look for devices. #options SCHED_ULE # ULE scheduler options SCHED_4BSD # 4BSD scheduler options PREEMPTION # Enable kernel thread preemption options INET # InterNETworking options INET6 # IPv6 communications protocols options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories options MD_ROOT # MD is a potential root device options NFSCLIENT # Network Filesystem Client options NFSSERVER # Network Filesystem Server options NFS_ROOT # NFS usable as /, requires NFSCLIENT options MSDOSFS # MSDOS Filesystem options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS # Pseudo-filesystem framework options GEOM_PART_GPT # GUID Partition Tables. options GEOM_LABEL # Provides labelization options COMPAT_43TTY # BSD 4.3 TTY compat [KEEP THIS!] options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options COMPAT_FREEBSD5 # Compatible with FreeBSD5 options COMPAT_FREEBSD6 # Compatible with FreeBSD6 options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options KBD_INSTALL_CDEV # install a CDEV entry in /dev options ADAPTIVE_GIANT # Giant mutex is adaptive. options STOP_NMI # Stop CPUS using NMI instead of IPI # To make an SMP kernel, the next two lines are needed options SMP # Symmetric MultiProcessor Kernel device apic # I/O APIC # Bus support. device eisa device pci # Floppy drives device fdc # ATA and ATAPI devices device ata device atadisk # ATA disk drives device ataraid # ATA RAID drives device atapicd # ATAPI CDROM drives device atapifd # ATAPI floppy drives device atapist # ATAPI tape drives options ATA_STATIC_ID # Static device numbering # SCSI Controllers device ahb # EISA AHA1742 family device ahc # AHA2940 and onboard AIC7xxx devices options AHC_REG_PRETTY_PRINT # Print register bitfields in debug # output. Adds ~128k to driver. device ahd # AHA39320/29320 and onboard AIC79xx devices options AHD_REG_PRETTY_PRINT # Print register bitfields in debug # output. Adds ~215k to driver. device amd # AMD 53C974 (Tekram DC-390(T)) device isp # Qlogic family #device ispfw # Firmware for QLogic HBAs- normally a module device mpt # LSI-Logic MPT-Fusion #device ncr # NCR/Symbios Logic device sym # NCR/Symbios Logic (newer chipsets + those of `ncr') device trm # Tekram DC395U/UW/F DC315U adapters device adv # Advansys SCSI adapters device adw # Advansys wide SCSI adapters device aha # Adaptec 154x SCSI adapters device aic # Adaptec 15[012]x SCSI adapters, AIC-6[23]60. device bt # Buslogic/Mylex MultiMaster SCSI adapters device ncv # NCR 53C500 device nsp # Workbit Ninja SCSI-3 device stg # TMC 18C30/18C50 # SCSI peripherals device scbus # SCSI bus (required for SCSI) device ch # SCSI media changers device da # Direct Access (disks) device sa # Sequential Access (tape etc) device cd # CD device pass # Passthrough device (direct SCSI access) device ses # SCSI Environmental Services (and SAF-TE) # RAID controllers interfaced to the SCSI subsystem device amr # AMI MegaRAID device arcmsr # Areca SATA II RAID device asr # DPT SmartRAID V, VI and Adaptec SCSI RAID device ciss # Compaq Smart RAID 5* device dpt # DPT Smartcache III, IV - See NOTES for options device hptmv # Highpoint RocketRAID 182x device rr232x # Highpoint RocketRAID 232x device iir # Intel Integrated RAID device ips # IBM (Adaptec) ServeRAID device mly # Mylex AcceleRAID/eXtremeRAID device twa # 3ware 9000 series PATA/SATA RAID # RAID controllers device aac # Adaptec FSA RAID device aacp # SCSI passthrough for aac (requires CAM) device ida # Compaq Smart RAID device mfi # LSI MegaRAID SAS device mlx # Mylex DAC960 family device pst # Promise Supertrak SX6000 device twe # 3ware ATA RAID # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc # AT keyboard controller device atkbd # AT keyboard device psm # PS/2 mouse device kbdmux # keyboard multiplexer device vga # VGA video card driver device splash # Splash screen and screen saver support # syscons is the default console driver, resembling an SCO console device sc device agp # support several AGP chipsets # Power management support (see NOTES for more options) #device apm # Add suspend/resume support for the i8254. device pmtimer # PCCARD (PCMCIA) support # PCMCIA and cardbus bridge support device cbb # cardbus (yenta) bridge device pccard # PC Card (16-bit) bus device cardbus # CardBus (32-bit) bus # Serial (COM) ports device sio # 8250, 16[45]50 based serial ports device uart # Generic UART driver # Parallel port device ppc device ppbus # Parallel port bus (required) device lpt # Printer device plip # TCP/IP over parallel device ppi # Parallel port interface device #device vpo # Requires scbus and da # If you've got a "dumb" serial or parallel PCI card that is # supported by the puc(4) glue driver, uncomment the following # line to enable it (connects to sio, uart and/or ppc drivers): #device puc # PCI Ethernet NICs. device de # DEC/Intel DC21x4x (``Tulip'') device em # Intel PRO/1000 adapter Gigabit Ethernet Card device ixgb # Intel PRO/10GbE Ethernet Card device le # AMD Am7900 LANCE and Am79C9xx PCnet device txp # 3Com 3cR990 (``Typhoon'') device vx # 3Com 3c590, 3c595 (``Vortex'') # PCI Ethernet NICs that use the common MII bus controller code. # NOTE: Be sure to keep the 'device miibus' line in order to use these NICs! device miibus # MII bus support device bce # Broadcom BCM5706/BCM5708 Gigabit Ethernet device bfe # Broadcom BCM440x 10/100 Ethernet device bge # Broadcom BCM570xx Gigabit Ethernet device dc # DEC/Intel 21143 and various workalikes device fxp # Intel EtherExpress PRO/100B (82557, 82558) device lge # Level 1 LXT1001 gigabit Ethernet device msk # Marvell/SysKonnect Yukon II Gigabit Ethernet device nge # NatSemi DP83820 gigabit Ethernet device nve # nVidia nForce MCP on-board Ethernet Networking device pcn # AMD Am79C97x PCI 10/100 (precedence over 'le') device re # RealTek 8139C+/8169/8169S/8110S device rl # RealTek 8129/8139 device sf # Adaptec AIC-6915 (``Starfire'') device sis # Silicon Integrated Systems SiS 900/SiS 7016 device sk # SysKonnect SK-984x & SK-982x gigabit Ethernet device ste # Sundance ST201 (D-Link DFE-550TX) device stge # Sundance/Tamarack TC9021 gigabit Ethernet device ti # Alteon Networks Tigon I/II gigabit Ethernet device tl # Texas Instruments ThunderLAN device tx # SMC EtherPower II (83c170 ``EPIC'') device vge # VIA VT612x gigabit Ethernet device vr # VIA Rhine, Rhine II device wb # Winbond W89C840F device xl # 3Com 3c90x (``Boomerang'', ``Cyclone'') # ISA Ethernet NICs. pccard NICs included. device cs # Crystal Semiconductor CS89x0 NIC # 'device ed' requires 'device miibus' device ed # NE[12]000, SMC Ultra, 3c503, DS8390 cards device ex # Intel EtherExpress Pro/10 and Pro/10+ device ep # Etherlink III based cards device fe # Fujitsu MB8696x based cards device ie # EtherExpress 8/16, 3C507, StarLAN 10 etc. device sn # SMC's 9000 series of Ethernet chips device xe # Xircom pccard Ethernet # Wireless NIC cards device wlan # 802.11 support device wlan_wep # 802.11 WEP support device wlan_ccmp # 802.11 CCMP support device wlan_tkip # 802.11 TKIP support device an # Aironet 4500/4800 802.11 wireless NICs. device ath # Atheros pci/cardbus NIC's device ath_hal # Atheros HAL (Hardware Access Layer) device ath_rate_sample # SampleRate tx rate control for ath device awi # BayStack 660 and others device ral # Ralink Technology RT2500 wireless NICs. device wi # WaveLAN/Intersil/Symbol 802.11 wireless NICs. #device wl # Older non 802.11 Wavelan wireless NIC. # Pseudo devices. device loop # Network loopback device random # Entropy device device ether # Ethernet support device sl # Kernel SLIP device ppp # Kernel PPP device tun # Packet tunnel. device pty # Pseudo-ttys (telnet etc) device md # Memory "disks" device gif # IPv6 and IPv4 tunneling device faith # IPv6-to-IPv4 relaying (translation) device firmware # firmware assist module # The `bpf' device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! # Note that 'bpf' is required for DHCP. device bpf # Berkeley packet filter # USB support device uhci # UHCI PCI->USB interface device ohci # OHCI PCI->USB interface device ehci # EHCI PCI->USB interface (USB 2.0) device usb # USB Bus (required) #device udbp # USB Double Bulk Pipe devices device ugen # Generic device uhid # "Human Interface Devices" device ukbd # Keyboard device ulpt # Printer device umass # Disks/Mass storage - Requires scbus and da device ums # Mouse device urio # Diamond Rio 500 MP3 player device uscanner # Scanners # USB Ethernet, requires miibus device aue # ADMtek USB Ethernet device axe # ASIX Electronics USB Ethernet device cdce # Generic USB over Ethernet device cue # CATC USB Ethernet device kue # Kawasaki LSI USB Ethernet device rue # RealTek RTL8150 USB Ethernet # FireWire support device firewire # FireWire bus code device sbp # SCSI over FireWire (Requires scbus and da) device fwe # Ethernet over FireWire (non-standard!) --2oS5YaxWCcQjTEyO-- From owner-freebsd-current@FreeBSD.ORG Tue Jul 17 03:35:31 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5034F16A40D for ; Tue, 17 Jul 2007 03:35:31 +0000 (UTC) (envelope-from stevenschlansker@berkeley.edu) Received: from smtp-out1.berkeley.edu (smtp-out1.Berkeley.EDU [128.32.61.106]) by mx1.freebsd.org (Postfix) with ESMTP id 3A72713C4CE for ; Tue, 17 Jul 2007 03:35:31 +0000 (UTC) (envelope-from stevenschlansker@berkeley.edu) Received: from adsl-75-42-136-243.dsl.pltn13.sbcglobal.net ([75.42.136.243] helo=[192.168.42.3]) by fe2.calmail with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (auth plain:stevenschlansker@berkeley.edu) (envelope-from ) id 1IAdqU-0006oL-9Y for freebsd-current@freebsd.org; Mon, 16 Jul 2007 20:35:31 -0700 Message-ID: <469C3900.5020703@berkeley.edu> Date: Mon, 16 Jul 2007 20:35:28 -0700 From: Steven Schlansker User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 CC: freebsd-current@freebsd.org References: <2978EDA9-D393-434C-B734-2DE188631761@berkeley.edu> In-Reply-To: X-Enigmail-Version: 0.94.2.0 OpenPGP: id=40BFF7A7; url=subkeys.pgp.net Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: Strange performance characteristics with ZFS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Jul 2007 03:35:31 -0000 Claus Guttesen wrote: >> I'm experiencing what (to me) seems to be strange performance with >> ZFS. I have it set up as follows: >> >> [steven@universe /universe]$ sudo zpool status >> pool: universe >> state: ONLINE >> I share it over NFS to a linux machine. I'm trying to write a very >> large (30GB) disk image to it over nfs, and it goes in short fits and >> bursts. >> >> It copies a few (mega?)bytes of data (not sure how much exactly), and >> top shows: > > How much ram is installed? > 2.5GB, with an Athlon64 3200+ From owner-freebsd-current@FreeBSD.ORG Tue Jul 17 03:45:15 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 95F8C16A401 for ; Tue, 17 Jul 2007 03:45:15 +0000 (UTC) (envelope-from bdonnell@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.225]) by mx1.freebsd.org (Postfix) with ESMTP id ECD7913C4AA for ; Tue, 17 Jul 2007 03:45:14 +0000 (UTC) (envelope-from bdonnell@gmail.com) Received: by wr-out-0506.google.com with SMTP id i23so711243wra for ; Mon, 16 Jul 2007 20:45:14 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=i7MBbU0+NoStMiMUcsh3AnPb/xeVIkBN5jcJS6HY8PdPPPhYttYbcKDQKksqtzJu+EjFJ8u1WDLeDMjV8Qo6zc/pEezCRm0YJiU1F9SqheKgGAdzexC5OH+Yyy4/vQ2m139oRpbluBwXqnJOGUYE07s/kMvAQpTbHk9ay1Rqyi0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=KPUhBIYgpry6AzM5xBNLXYkFMeoYgaUY1oBvdm8N+TdV+mT7jOKTJ8UNvfV/8e4MpDLPuakjIAegN0GwJ7mTL3JVcyS4+jZbmuXFrOkz2zWx17A36DsRIKN6WSPNGj3J7yJocbY8up0VolXO6HWSnRS3eGHBw5QRiq65K7a/8fA= Received: by 10.142.214.5 with SMTP id m5mr71wfg.1184643911694; Mon, 16 Jul 2007 20:45:11 -0700 (PDT) Received: by 10.142.77.9 with HTTP; Mon, 16 Jul 2007 20:45:11 -0700 (PDT) Message-ID: <1c5c32890707162045u9d56cfeq2f7430ddddd55418@mail.gmail.com> Date: Mon, 16 Jul 2007 23:45:11 -0400 From: "Brian Donnell" To: "Steven Schlansker" In-Reply-To: <469C3900.5020703@berkeley.edu> MIME-Version: 1.0 References: <2978EDA9-D393-434C-B734-2DE188631761@berkeley.edu> <469C3900.5020703@berkeley.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: Re: Strange performance characteristics with ZFS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Jul 2007 03:45:15 -0000 When I was experimenting with ZFS over NFS I had similar experiences. Do me a favor and try something that sounds a little out there. On a shell on the ZFS machine set up a looping script that executes an ls on the directory you're writing the file to once every second and watch your transfer rates. I noticed a marked improvement, but I could never determine if it was ZFS or the client NFS implementation. -- Brian On 7/16/07, Steven Schlansker wrote: > > Claus Guttesen wrote: > >> I'm experiencing what (to me) seems to be strange performance with > >> ZFS. I have it set up as follows: > >> > >> [steven@universe /universe]$ sudo zpool status > >> pool: universe > >> state: ONLINE > >> I share it over NFS to a linux machine. I'm trying to write a very > >> large (30GB) disk image to it over nfs, and it goes in short fits and > >> bursts. > >> > >> It copies a few (mega?)bytes of data (not sure how much exactly), and > >> top shows: > > > > How much ram is installed? > > > > 2.5GB, with an Athlon64 3200+ > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Tue Jul 17 04:43:34 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 40E6B16A406 for ; Tue, 17 Jul 2007 04:43:34 +0000 (UTC) (envelope-from stevenschlansker@berkeley.edu) Received: from smtp-out1.berkeley.edu (smtp-out1.Berkeley.EDU [128.32.61.106]) by mx1.freebsd.org (Postfix) with ESMTP id 2914F13C49D for ; Tue, 17 Jul 2007 04:43:34 +0000 (UTC) (envelope-from stevenschlansker@berkeley.edu) Received: from adsl-75-42-136-243.dsl.pltn13.sbcglobal.net ([75.42.136.243] helo=[192.168.42.3]) by fe6.calmail with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (auth plain:stevenschlansker@berkeley.edu) (envelope-from ) id 1IAeuL-00047v-M2 for freebsd-current@freebsd.org; Mon, 16 Jul 2007 21:43:34 -0700 Message-ID: <469C48F2.7000302@berkeley.edu> Date: Mon, 16 Jul 2007 21:43:30 -0700 From: Steven Schlansker User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 CC: freebsd-current@freebsd.org References: <2978EDA9-D393-434C-B734-2DE188631761@berkeley.edu> <469C3900.5020703@berkeley.edu> <1c5c32890707162045u9d56cfeq2f7430ddddd55418@mail.gmail.com> In-Reply-To: <1c5c32890707162045u9d56cfeq2f7430ddddd55418@mail.gmail.com> X-Enigmail-Version: 0.94.2.0 OpenPGP: id=40BFF7A7; url=subkeys.pgp.net Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: Strange performance characteristics with ZFS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Jul 2007 04:43:34 -0000 That turned out to be a particularly bad idea. As soon as I executed that on the server, the client's cpu pegged! Despite the fact that there is about 5MB/s transfer over the network, the client is no longer making any progress on the copy. The nfsd processes on the bsd server are still happily chugging away serving data in the same fits and bursts as before, but the linux machine receiving the data doesn't seem to be doing anything with it. I restarted the nfsd and mountd processes, I'll let it run for a bit... Aha. It corrupted data. Now I have to start the copy over again :/ This is not good! Anything else I can try? (Hopefully without making the process fail :-p ) Thanks! Brian Donnell wrote: > When I was experimenting with ZFS over NFS I had similar experiences. > Do me a favor and try something that sounds a little out there. On a > shell on the ZFS machine set up a looping script that executes an ls on > the directory you're writing the file to once every second and watch > your transfer rates. I noticed a marked improvement, but I could never > determine if it was ZFS or the client NFS implementation. > > -- Brian > > On 7/16/07, *Steven Schlansker* > wrote: > > Claus Guttesen wrote: > >> I'm experiencing what (to me) seems to be strange performance with > >> ZFS. I have it set up as follows: > >> > >> [steven@universe /universe]$ sudo zpool status > >> pool: universe > >> state: ONLINE > >> I share it over NFS to a linux machine. I'm trying to write a very > >> large (30GB) disk image to it over nfs, and it goes in short fits > and > >> bursts. > >> > >> It copies a few (mega?)bytes of data (not sure how much exactly), and > >> top shows: > > > > How much ram is installed? > > > > 2.5GB, with an Athlon64 3200+ > _______________________________________________ > freebsd-current@freebsd.org > mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org > " > > From owner-freebsd-current@FreeBSD.ORG Tue Jul 17 06:32:32 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 658BF16A403 for ; Tue, 17 Jul 2007 06:32:32 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from webaccess-cl.virtdom.com (webaccess-cl.virtdom.com [216.240.101.25]) by mx1.freebsd.org (Postfix) with ESMTP id 1B2E213C4B6 for ; Tue, 17 Jul 2007 06:32:32 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from [192.168.1.101] (c-71-231-138-78.hsd1.or.comcast.net [71.231.138.78]) (authenticated bits=0) by webaccess-cl.virtdom.com (8.13.6/8.13.6) with ESMTP id l6H6WU7g059506 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO) for ; Tue, 17 Jul 2007 02:32:31 -0400 (EDT) (envelope-from jroberson@chesapeake.net) Date: Mon, 16 Jul 2007 23:35:38 -0700 (PDT) From: Jeff Roberson X-X-Sender: jroberson@10.0.0.1 To: current@freebsd.org Message-ID: <20070716233030.D92541@10.0.0.1> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Subject: ULE/SCHED_SMP diff for 7.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2007 06:32:32 -0000 http://people.freebsd.org/~jeff/ule.diff This patch is scheduled for inclusion in 7.0. I would like anyone who cares to run it to validate that it does not create any stability or performance regression over the existing ULE. This patch replaces ULE with SCHED_SMP, which will now no longer exist as a seperate fork of ULE. Briefly, this is still a very suitable scheduler for uniprocessor machines while providing stronger affinity and other performance improvements for multiprocessor machines. Even "works for me!" type responses are welcome so I know roughly how many people have tested before I commit this close to release. Thanks! Jeff From owner-freebsd-current@FreeBSD.ORG Tue Jul 17 07:18:58 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EC34016A400 for ; Tue, 17 Jul 2007 07:18:58 +0000 (UTC) (envelope-from kometen@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.232]) by mx1.freebsd.org (Postfix) with ESMTP id ADDB813C428 for ; Tue, 17 Jul 2007 07:18:58 +0000 (UTC) (envelope-from kometen@gmail.com) Received: by wx-out-0506.google.com with SMTP id i29so1169020wxd for ; Tue, 17 Jul 2007 00:18:58 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ajxyMsYm6m9yiofdg11jMMPvCdst3v/3bDw2rZr5uWLMhyi/79KY7qXUTTNHbDntw9mp/rCN2xAcxtrJ0TSEkbx48kCo781uqkkscZXhocQ8kd5syAPn7WIvcbFQI+H+6ZYClGlukS1JOzxFTU8ihdMfCOiXxWVBlG1d4kxJPGA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=pph2OQDVREMKhEEvqove0a/g1hEUiO/6SxVb+gybFV7b0KtMAAteMxX4ck433x89uHLSQROdmDv2/4zCyri8atCdKqAGeCUbgoSmv64zUJxCyHuXqzgwX1oXWC/uAi8iDOKnOpSOcUd5+UG6WrmHwroSPZF4fNvB/9N3TjwpkS0= Received: by 10.70.48.15 with SMTP id v15mr263629wxv.1184656331739; Tue, 17 Jul 2007 00:12:11 -0700 (PDT) Received: by 10.70.41.4 with HTTP; Tue, 17 Jul 2007 00:12:11 -0700 (PDT) Message-ID: Date: Tue, 17 Jul 2007 09:12:11 +0200 From: "Claus Guttesen" To: "Steven Schlansker" In-Reply-To: <469C48F2.7000302@berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <2978EDA9-D393-434C-B734-2DE188631761@berkeley.edu> <469C3900.5020703@berkeley.edu> <1c5c32890707162045u9d56cfeq2f7430ddddd55418@mail.gmail.com> <469C48F2.7000302@berkeley.edu> Cc: freebsd-current@freebsd.org Subject: Re: Strange performance characteristics with ZFS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Jul 2007 07:18:59 -0000 > Aha. It corrupted data. Now I have to start the copy over again :/ > > This is not good! Anything else I can try? (Hopefully without making > the process fail :-p ) I've only copied data between freebsd using nfs (and zfs on the server) which worked so apparently server and client introduces some mismacth. Have you tried both tcp and udp? -- regards Claus When lenity and cruelty play for a kingdom, the gentlest gamester is the soonest winner. Shakespeare From owner-freebsd-current@FreeBSD.ORG Tue Jul 17 08:05:10 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B5F6E16A408 for ; Tue, 17 Jul 2007 08:05:10 +0000 (UTC) (envelope-from Johan@double-l.nl) Received: from smtp-vbr4.xs4all.nl (smtp-vbr4.xs4all.nl [194.109.24.24]) by mx1.freebsd.org (Postfix) with ESMTP id 65D7213C471 for ; Tue, 17 Jul 2007 08:05:10 +0000 (UTC) (envelope-from Johan@double-l.nl) Received: from w2003s01.double-l.local (dpm.xs4all.nl [213.84.11.61]) by smtp-vbr4.xs4all.nl (8.13.8/8.13.8) with ESMTP id l6H858UJ081963 for ; Tue, 17 Jul 2007 10:05:09 +0200 (CEST) (envelope-from Johan@double-l.nl) MIME-Version: 1.0 Date: Tue, 17 Jul 2007 10:04:40 +0200 Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <57200BF94E69E54880C9BB1AF714BBCB011176@w2003s01.double-l.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ULE/SCHED_SMP diff for 7.0 Thread-Index: AcfIPK6ENQg6NracQ9CFzC6iGeA38wADHIik References: <20070716233030.D92541@10.0.0.1> From: "Johan Hendriks" To: X-Virus-Scanned: by XS4ALL Virus Scanner Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: RE: ULE/SCHED_SMP diff for 7.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2007 08:05:10 -0000 Sorry for the lame question but how do i apply the patch ? =20 regards =20 ________________________________ Van: owner-freebsd-current@freebsd.org namens Jeff Roberson Verzonden: di 17-7-2007 8:35 Aan: current@freebsd.org Onderwerp: ULE/SCHED_SMP diff for 7.0 http://people.freebsd.org/~jeff/ule.diff This patch is scheduled for inclusion in 7.0. I would like anyone who cares to run it to validate that it does not create any stability or performance regression over the existing ULE. This patch replaces ULE with SCHED_SMP, which will now no longer exist as a seperate fork of = ULE. Briefly, this is still a very suitable scheduler for uniprocessor = machines while providing stronger affinity and other performance improvements for multiprocessor machines. Even "works for me!" type responses are welcome so I know roughly how = many people have tested before I commit this close to release. Thanks! Jeff _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to = "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Tue Jul 17 08:13:50 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F40B116A400 for ; Tue, 17 Jul 2007 08:13:49 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.134]) by mx1.freebsd.org (Postfix) with ESMTP id CFAF013C494 for ; Tue, 17 Jul 2007 08:13:49 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.141] (may be forged)) by mxout1.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.06) with ESMTP id l6H8Diuk022990 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 17 Jul 2007 01:13:44 -0700 X-Auth-Received: from [192.168.10.45] (c-24-10-12-194.hsd1.ca.comcast.net [24.10.12.194]) (authenticated authid=youshi10) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l6H8Dh3K023731 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 17 Jul 2007 01:13:44 -0700 Message-ID: <469C7A36.2020406@u.washington.edu> Date: Tue, 17 Jul 2007 01:13:42 -0700 From: Garrett Cooper User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Johan Hendriks References: <20070716233030.D92541@10.0.0.1> <57200BF94E69E54880C9BB1AF714BBCB011176@w2003s01.double-l.local> In-Reply-To: <57200BF94E69E54880C9BB1AF714BBCB011176@w2003s01.double-l.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 5.3.2.304607, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.7.17.5233 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' Cc: current@freebsd.org Subject: Re: ULE/SCHED_SMP diff for 7.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2007 08:13:50 -0000 Johan Hendriks wrote: > Sorry for the lame question but how do i apply the patch ? > > regards > > > ________________________________ > > Van: owner-freebsd-current@freebsd.org namens Jeff Roberson > Verzonden: di 17-7-2007 8:35 > Aan: current@freebsd.org > Onderwerp: ULE/SCHED_SMP diff for 7.0 > > > > http://people.freebsd.org/~jeff/ule.diff > > This patch is scheduled for inclusion in 7.0. I would like anyone who > cares to run it to validate that it does not create any stability or > performance regression over the existing ULE. This patch replaces ULE > with SCHED_SMP, which will now no longer exist as a seperate fork of ULE. > > Briefly, this is still a very suitable scheduler for uniprocessor machines > while providing stronger affinity and other performance improvements for > multiprocessor machines. > > Even "works for me!" type responses are welcome so I know roughly how many > people have tested before I commit this close to release. > > Thanks! > Jeff > cd /usr/src/sys/ && fetch http://people.freebsd.org/~jeff/ule.diff && patch < ule.diff -Garrett From owner-freebsd-current@FreeBSD.ORG Tue Jul 17 08:17:58 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9C19816A400 for ; Tue, 17 Jul 2007 08:17:58 +0000 (UTC) (envelope-from Johan@double-l.nl) Received: from smtp-vbr4.xs4all.nl (smtp-vbr4.xs4all.nl [194.109.24.24]) by mx1.freebsd.org (Postfix) with ESMTP id 32D3413C48E for ; Tue, 17 Jul 2007 08:17:52 +0000 (UTC) (envelope-from Johan@double-l.nl) Received: from w2003s01.double-l.local (dpm.xs4all.nl [213.84.11.61]) by smtp-vbr4.xs4all.nl (8.13.8/8.13.8) with ESMTP id l6H8HpcP089609; Tue, 17 Jul 2007 10:17:51 +0200 (CEST) (envelope-from Johan@double-l.nl) MIME-Version: 1.0 Date: Tue, 17 Jul 2007 10:18:02 +0200 Content-class: urn:content-classes:message Message-ID: <57200BF94E69E54880C9BB1AF714BBCB011177@w2003s01.double-l.local> X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ULE/SCHED_SMP diff for 7.0 Thread-Index: AcfISoYfw+a51HAGS/SpfU3SuNmEzwAAHiN0 References: <20070716233030.D92541@10.0.0.1><57200BF94E69E54880C9BB1AF714BBCB011176@w2003s01.double-l.local> From: "Johan Hendriks" To: "Vlad GALU" X-Virus-Scanned: by XS4ALL Virus Scanner Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: current@freebsd.org Subject: RE: ULE/SCHED_SMP diff for 7.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2007 08:17:58 -0000 Thanks, i did it from the dir /usr/src =20 =20 regards, Johan Hendriks =20 =20 ________________________________ Van: Vlad GALU [mailto:dudu@dudu.ro] Verzonden: di 17-7-2007 10:13 Aan: Johan Hendriks CC: current@freebsd.org Onderwerp: Re: ULE/SCHED_SMP diff for 7.0 On 7/17/07, Johan Hendriks wrote: > Sorry for the lame question but how do i apply the patch ? > cd /usr/src/sys && patch < /path/to/ule.diff. > regards > > > ________________________________ > > Van: owner-freebsd-current@freebsd.org namens Jeff Roberson > Verzonden: di 17-7-2007 8:35 > Aan: current@freebsd.org > Onderwerp: ULE/SCHED_SMP diff for 7.0 > > > > http://people.freebsd.org/~jeff/ule.diff > > This patch is scheduled for inclusion in 7.0. I would like anyone who > cares to run it to validate that it does not create any stability or > performance regression over the existing ULE. This patch replaces ULE > with SCHED_SMP, which will now no longer exist as a seperate fork of = ULE. > > Briefly, this is still a very suitable scheduler for uniprocessor = machines > while providing stronger affinity and other performance improvements = for > multiprocessor machines. > > Even "works for me!" type responses are welcome so I know roughly how = many > people have tested before I commit this close to release. > > Thanks! > Jeff > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to = "freebsd-current-unsubscribe@freebsd.org" > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to = "freebsd-current-unsubscribe@freebsd.org" > -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. From owner-freebsd-current@FreeBSD.ORG Tue Jul 17 08:19:13 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1B10116A406 for ; Tue, 17 Jul 2007 08:19:13 +0000 (UTC) (envelope-from dudu@dudu.ro) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.172]) by mx1.freebsd.org (Postfix) with ESMTP id A75A813C428 for ; Tue, 17 Jul 2007 08:19:12 +0000 (UTC) (envelope-from dudu@dudu.ro) Received: by ug-out-1314.google.com with SMTP id o4so115873uge for ; Tue, 17 Jul 2007 01:19:11 -0700 (PDT) Received: by 10.82.182.1 with SMTP id e1mr75704buf.1184659986748; Tue, 17 Jul 2007 01:13:06 -0700 (PDT) Received: by 10.82.148.14 with HTTP; Tue, 17 Jul 2007 01:13:06 -0700 (PDT) Message-ID: Date: Tue, 17 Jul 2007 11:13:06 +0300 From: "Vlad GALU" To: "Johan Hendriks" In-Reply-To: <57200BF94E69E54880C9BB1AF714BBCB011176@w2003s01.double-l.local> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070716233030.D92541@10.0.0.1> <57200BF94E69E54880C9BB1AF714BBCB011176@w2003s01.double-l.local> Cc: current@freebsd.org Subject: Re: ULE/SCHED_SMP diff for 7.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2007 08:19:13 -0000 On 7/17/07, Johan Hendriks wrote: > Sorry for the lame question but how do i apply the patch ? > cd /usr/src/sys && patch < /path/to/ule.diff. > regards > > > ________________________________ > > Van: owner-freebsd-current@freebsd.org namens Jeff Roberson > Verzonden: di 17-7-2007 8:35 > Aan: current@freebsd.org > Onderwerp: ULE/SCHED_SMP diff for 7.0 > > > > http://people.freebsd.org/~jeff/ule.diff > > This patch is scheduled for inclusion in 7.0. I would like anyone who > cares to run it to validate that it does not create any stability or > performance regression over the existing ULE. This patch replaces ULE > with SCHED_SMP, which will now no longer exist as a seperate fork of ULE. > > Briefly, this is still a very suitable scheduler for uniprocessor machines > while providing stronger affinity and other performance improvements for > multiprocessor machines. > > Even "works for me!" type responses are welcome so I know roughly how many > people have tested before I commit this close to release. > > Thanks! > Jeff > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. From owner-freebsd-current@FreeBSD.ORG Tue Jul 17 08:29:09 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A721216A400 for ; Tue, 17 Jul 2007 08:29:09 +0000 (UTC) (envelope-from koolguy317@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.234]) by mx1.freebsd.org (Postfix) with ESMTP id 683C013C467 for ; Tue, 17 Jul 2007 08:29:09 +0000 (UTC) (envelope-from koolguy317@gmail.com) Received: by wx-out-0506.google.com with SMTP id i29so1181080wxd for ; Tue, 17 Jul 2007 01:29:08 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=qdFK4gGQtHQBLQufid9XzdcqOe1JWG+r2wmGJVON2YcUzn0K5FcJ2vFNafmHza4ZJWpG1q+8QnSFaGPQJ2ALk6jeCBTzv7rPi5NkXO56E0TLok2c9E5M9xNKQQ2WDMkpIxVNtTbTTYvBaYmhaFU9CE4OAYvlK1GKREaceMdIFbg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=bApWj0uzSYGyXhC9JLHIAa4AnwvrsA18HfkIy1x1CTai4YJrAQHM2DTh4p5aTMNJtau4U9pzreoJiEMxTbtb8ACkCqIttcyF5wxEpnMTSrShByTynAP5iHaxQHyIKS2tviN+RnMJSuAv24v4pHxVQXXQLeZz81MaJ5VZM6Q8bhw= Received: by 10.90.80.8 with SMTP id d8mr93132agb.1184660948535; Tue, 17 Jul 2007 01:29:08 -0700 (PDT) Received: by 10.90.30.11 with HTTP; Tue, 17 Jul 2007 01:29:08 -0700 (PDT) Message-ID: <88afd9200707170129h4ab33176pc8423a4c2f2d6124@mail.gmail.com> Date: Tue, 17 Jul 2007 04:29:08 -0400 From: "Kool Guy" To: freebsd-current@freebsd.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <2978EDA9-D393-434C-B734-2DE188631761@berkeley.edu> <469C3900.5020703@berkeley.edu> <1c5c32890707162045u9d56cfeq2f7430ddddd55418@mail.gmail.com> <469C48F2.7000302@berkeley.edu> Subject: Re: Strange performance characteristics with ZFS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Jul 2007 08:29:09 -0000 On 7/17/07, Claus Guttesen wrote: > > Aha. It corrupted data. Now I have to start the copy over again :/ > > > > This is not good! Anything else I can try? (Hopefully without making > > the process fail :-p ) > > I've only copied data between freebsd using nfs (and zfs on the > server) which worked so apparently server and client introduces some > mismacth. Have you tried both tcp and udp? > -- > regards > Claus > > When lenity and cruelty play for a kingdom, > the gentlest gamester is the soonest winner. > > Shakespeare > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > I've had this same problem. I did notice that I was getting a *TON* of error messages on the console when access ZFS from a remote Linux client over NFS. Eventually, it slowed to a crawl and died. I'm in the process of rebuilding my system so I can't tell you details of the messages, but you may want to tail -f /var/log/messages. Larry. From owner-freebsd-current@FreeBSD.ORG Tue Jul 17 08:34:17 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D1CD716A404 for ; Tue, 17 Jul 2007 08:34:17 +0000 (UTC) (envelope-from dudu@dudu.ro) Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.191]) by mx1.freebsd.org (Postfix) with ESMTP id 6C09013C49D for ; Tue, 17 Jul 2007 08:34:17 +0000 (UTC) (envelope-from dudu@dudu.ro) Received: by mu-out-0910.google.com with SMTP id w9so1699716mue for ; Tue, 17 Jul 2007 01:34:16 -0700 (PDT) Received: by 10.82.174.20 with SMTP id w20mr73509bue.1184659553769; Tue, 17 Jul 2007 01:05:53 -0700 (PDT) Received: by 10.82.148.14 with HTTP; Tue, 17 Jul 2007 01:05:53 -0700 (PDT) Message-ID: Date: Tue, 17 Jul 2007 11:05:53 +0300 From: "Vlad GALU" To: "Jeff Roberson" In-Reply-To: <20070716233030.D92541@10.0.0.1> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070716233030.D92541@10.0.0.1> Cc: current@freebsd.org Subject: Re: ULE/SCHED_SMP diff for 7.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2007 08:34:17 -0000 On 7/17/07, Jeff Roberson wrote: > http://people.freebsd.org/~jeff/ule.diff > > This patch is scheduled for inclusion in 7.0. I would like anyone who > cares to run it to validate that it does not create any stability or > performance regression over the existing ULE. This patch replaces ULE > with SCHED_SMP, which will now no longer exist as a seperate fork of ULE. > > Briefly, this is still a very suitable scheduler for uniprocessor machines > while providing stronger affinity and other performance improvements for > multiprocessor machines. > > Even "works for me!" type responses are welcome so I know roughly how many > people have tested before I commit this close to release. "Works for me!" :) It survived a couple of buildworlds, while I was doing my usual work. This is an UP amd64 machine. > > Thanks! > Jeff > _______________________________________________ > 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" > -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. From owner-freebsd-current@FreeBSD.ORG Tue Jul 17 08:37:46 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C09B916A400 for ; Tue, 17 Jul 2007 08:37:46 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from mxout5.cac.washington.edu (mxout5.cac.washington.edu [140.142.32.135]) by mx1.freebsd.org (Postfix) with ESMTP id 9B76313C4B9 for ; Tue, 17 Jul 2007 08:37:46 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9] (may be forged)) by mxout5.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.06) with ESMTP id l6H8bdZ8023358 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 17 Jul 2007 01:37:40 -0700 X-Auth-Received: from [192.168.10.45] (c-24-10-12-194.hsd1.ca.comcast.net [24.10.12.194]) (authenticated authid=youshi10) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l6H8bdlc007041 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 17 Jul 2007 01:37:39 -0700 Message-ID: <469C7FD2.6080205@u.washington.edu> Date: Tue, 17 Jul 2007 01:37:38 -0700 From: Garrett Cooper User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Johan Hendriks References: <20070716233030.D92541@10.0.0.1><57200BF94E69E54880C9BB1AF714BBCB011176@w2003s01.double-l.local> <57200BF94E69E54880C9BB1AF714BBCB011177@w2003s01.double-l.local> In-Reply-To: <57200BF94E69E54880C9BB1AF714BBCB011177@w2003s01.double-l.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 5.3.2.304607, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.7.17.11733 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' Cc: Vlad GALU , current@freebsd.org Subject: Re: ULE/SCHED_SMP diff for 7.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2007 08:37:46 -0000 Johan Hendriks wrote: > Thanks, > i did it from the dir /usr/src > > regards, > Johan Hendriks > > > > ________________________________ > > Van: Vlad GALU [mailto:dudu@dudu.ro] > Verzonden: di 17-7-2007 10:13 > Aan: Johan Hendriks > CC: current@freebsd.org > Onderwerp: Re: ULE/SCHED_SMP diff for 7.0 > > > > On 7/17/07, Johan Hendriks wrote: > >> Sorry for the lame question but how do i apply the patch ? >> >> > cd /usr/src/sys && patch < /path/to/ule.diff. > > >> regards >> >> >> ________________________________ >> >> Van: owner-freebsd-current@freebsd.org namens Jeff Roberson >> Verzonden: di 17-7-2007 8:35 >> Aan: current@freebsd.org >> Onderwerp: ULE/SCHED_SMP diff for 7.0 >> >> >> >> http://people.freebsd.org/~jeff/ule.diff >> >> This patch is scheduled for inclusion in 7.0. I would like anyone who >> cares to run it to validate that it does not create any stability or >> performance regression over the existing ULE. This patch replaces ULE >> with SCHED_SMP, which will now no longer exist as a seperate fork of ULE. >> >> Briefly, this is still a very suitable scheduler for uniprocessor machines >> while providing stronger affinity and other performance improvements for >> multiprocessor machines. >> >> Even "works for me!" type responses are welcome so I know roughly how many >> people have tested before I commit this close to release. >> >> Thanks! >> Jeff > > -- > If it's there, and you can see it, it's real. > If it's not there, and you can see it, it's virtual. > If it's there, and you can't see it, it's transparent. > If it's not there, and you can't see it, you erased it. > From what I can tell my fat program now passes with flying colors, but I need to run printf's via ssh at high speeds to make sure that my memory allocation methods combined with key generation and encryption are actually stress testing your patches. Will have results in a few. -Garrett From owner-freebsd-current@FreeBSD.ORG Tue Jul 17 08:59:25 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2D8C516A400 for ; Tue, 17 Jul 2007 08:59:25 +0000 (UTC) (envelope-from kometen@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.236]) by mx1.freebsd.org (Postfix) with ESMTP id E5A4413C4A3 for ; Tue, 17 Jul 2007 08:59:24 +0000 (UTC) (envelope-from kometen@gmail.com) Received: by wx-out-0506.google.com with SMTP id i29so1186478wxd for ; Tue, 17 Jul 2007 01:59:24 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Vw6lMfTxNfw5ES/Vs2bgQqDS2uDJUG0hm58tiS+geVncxHobRjgxoo3qMVEKxNZ3Hrt0dcIhO6rfs4nVCZ3GJZxctyVw2PBsUi8sJzIXNWfyarAHPE6ghK5hU2YZLzvZ5HZF8kDAWaVhXRIwb0SE4kG+I6OieYbp4yvjnbui8rg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=kSCZ94Ktj/GbOR4y54Ip3ibx6IC9BiB/ula5TzAVVFzgxiIl8MpsuC7goZktMcVglI2/tBnGCQIBhGR3hgnZLbC6Wl/N8zz7s4wB5xFyEGXitAMjcFPYzxyhWC5dagZLhpZ3+fYMAL0FFvFbgx9fHXyzRQuki3il0RCWqf7zBTY= Received: by 10.70.66.18 with SMTP id o18mr399238wxa.1184662764073; Tue, 17 Jul 2007 01:59:24 -0700 (PDT) Received: by 10.70.41.4 with HTTP; Tue, 17 Jul 2007 01:59:23 -0700 (PDT) Message-ID: Date: Tue, 17 Jul 2007 10:59:23 +0200 From: "Claus Guttesen" To: "Jeff Roberson" In-Reply-To: <20070716233030.D92541@10.0.0.1> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070716233030.D92541@10.0.0.1> Cc: current@freebsd.org Subject: Re: ULE/SCHED_SMP diff for 7.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2007 08:59:25 -0000 > http://people.freebsd.org/~jeff/ule.diff > > This patch is scheduled for inclusion in 7.0. I would like anyone who > cares to run it to validate that it does not create any stability or > performance regression over the existing ULE. This patch replaces ULE > with SCHED_SMP, which will now no longer exist as a seperate fork of ULE. Applied the patch and tried to compile new kernel. However I get: julie/usr/src#>time make -j 3 buildkernel -------------------------------------------------------------- >>> Kernel build for WEBSRV started on Tue Jul 17 10:56:34 CEST 2007 -------------------------------------------------------------- ===> WEBSRV mkdir -p /usr/obj/usr/src/sys -------------------------------------------------------------- >>> stage 1: configuring the kernel -------------------------------------------------------------- cd /usr/src/sys/amd64/conf; PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin config -d /usr/obj/usr/src/sys/WEBSRV /usr/src/sys/amd64/conf/WEBSRV /usr/src/sys/amd64/conf/WEBSRV: unknown option "SCHED_SMP" *** Error code 1 1 error *** Error code 2 1 error make -j 3 buildkernel 0.06s user 0.04s system 101% cpu 0.101 total I have options SCHED_SMP # Newer SMP scheduler in my kernel. Hunk succeeded everytime, src is from last week. -- regards Claus When lenity and cruelty play for a kingdom, the gentlest gamester is the soonest winner. Shakespeare From owner-freebsd-current@FreeBSD.ORG Tue Jul 17 09:08:27 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 16D7416A402 for ; Tue, 17 Jul 2007 09:08:27 +0000 (UTC) (envelope-from leafy7382@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.245]) by mx1.freebsd.org (Postfix) with ESMTP id CFF3C13C494 for ; Tue, 17 Jul 2007 09:08:26 +0000 (UTC) (envelope-from leafy7382@gmail.com) Received: by an-out-0708.google.com with SMTP id c14so339972anc for ; Tue, 17 Jul 2007 02:08:26 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=B4aTOWNvMkRRV1JARwsnQztMqclaioHcv+u9FjHmbg+tiErTvkxfe+nIGciXR6jbQy/TqOEvzoNoiGEr6JnTgOqxxyAwFsWpfWRIcsuKlqBPHFyT8fDCptVyUinN9GCBEYWObFqWEjJidhtSzJ5/IWfKHMjCmfIiWD9CUND9vBk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Gkc1OfQQyyEP7dzGPILN0zNd+LmhfWFREVVFELz7lmEDHgem080uZWCcmcQa31Ki6CxzPaJ6+JGw/jUAQMdW7RrUanSmZCIWGGgVbrAhsrGl+8w+UrbeO/S01ZDXN29qMxhNuNMBY5o5Xa8bChu5SKIXzFyPNXEsEOTwvv+E+ss= Received: by 10.100.120.5 with SMTP id s5mr91619anc.1184663306029; Tue, 17 Jul 2007 02:08:26 -0700 (PDT) Received: by 10.100.137.3 with HTTP; Tue, 17 Jul 2007 02:08:25 -0700 (PDT) Message-ID: Date: Tue, 17 Jul 2007 17:08:25 +0800 From: "Jiawei Ye" To: "Claus Guttesen" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070716233030.D92541@10.0.0.1> Cc: Jeff Roberson , current@freebsd.org Subject: Re: ULE/SCHED_SMP diff for 7.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2007 09:08:27 -0000 On 7/17/07, Claus Guttesen wrote: > > http://people.freebsd.org/~jeff/ule.diff > > > > This patch is scheduled for inclusion in 7.0. I would like anyone who > > cares to run it to validate that it does not create any stability or > > performance regression over the existing ULE. This patch replaces ULE > > with SCHED_SMP, which will now no longer exist as a seperate fork of ULE. > > Applied the patch and tried to compile new kernel. However I get: > > julie/usr/src#>time make -j 3 buildkernel > -------------------------------------------------------------- > >>> Kernel build for WEBSRV started on Tue Jul 17 10:56:34 CEST 2007 > -------------------------------------------------------------- > ===> WEBSRV > mkdir -p /usr/obj/usr/src/sys > -------------------------------------------------------------- > >>> stage 1: configuring the kernel > -------------------------------------------------------------- > cd /usr/src/sys/amd64/conf; > PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin > config -d /usr/obj/usr/src/sys/WEBSRV > /usr/src/sys/amd64/conf/WEBSRV > /usr/src/sys/amd64/conf/WEBSRV: unknown option "SCHED_SMP" > *** Error code 1 > 1 error > *** Error code 2 > 1 error > make -j 3 buildkernel 0.06s user 0.04s system 101% cpu 0.101 total > > I have > > options SCHED_SMP # Newer SMP scheduler > > in my kernel. > > Hunk succeeded everytime, src is from last week. > > -- > regards > Claus > > When lenity and cruelty play for a kingdom, > the gentlest gamester is the soonest winner. > > Shakespeare > _______________________________________________ > 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" > The patch patches SCHED_ULE with SCHED_SMP bits, so you need SCHED_ULE instead of SMP in the kernel. Jiawei -- "If it looks like a duck, walks like a duck, and quacks like a duck, then to the end user it's a duck, and end users have made it pretty clear they want a duck; whether the duck drinks hot chocolate or coffee is irrelevant." From owner-freebsd-current@FreeBSD.ORG Tue Jul 17 09:11:40 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E344F16A400 for ; Tue, 17 Jul 2007 09:11:40 +0000 (UTC) (envelope-from kometen@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.226]) by mx1.freebsd.org (Postfix) with ESMTP id A73EB13C4A3 for ; Tue, 17 Jul 2007 09:11:40 +0000 (UTC) (envelope-from kometen@gmail.com) Received: by wx-out-0506.google.com with SMTP id i29so1188726wxd for ; Tue, 17 Jul 2007 02:11:40 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=AGEV5vNHRY88JfAPjINgmnwHQGp1zkU6GX8tchmEzlvbq25EvqgOBUvtEgbKD+9jnvIuJFCPl8OdiN69SLWqLhnYwyK2Ua/iJhFnQj44C2GMrCpWWJ5KGWtrmqtsACyzxoO+g4B+CIBTZXvzojOhaa5YJEmu21HVp+8+m7c5neU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=BukcmFmBrplVawEpJmIUdCH77E0gV8as7h+l6sBOPV7CbFNzdL/6Qv1AYVlFNa5LsENyP+IC2BbhTOxto7//fwya/edTFYqYC1w+7YabLFYyghq5hKahA2WjRBgJ+BAIu6ktQz8ZOcG02IEe+enJ0vACD+ORjraCMKobaCevSFI= Received: by 10.70.69.2 with SMTP id r2mr410638wxa.1184663499970; Tue, 17 Jul 2007 02:11:39 -0700 (PDT) Received: by 10.70.41.4 with HTTP; Tue, 17 Jul 2007 02:11:39 -0700 (PDT) Message-ID: Date: Tue, 17 Jul 2007 11:11:39 +0200 From: "Claus Guttesen" To: "Jiawei Ye" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070716233030.D92541@10.0.0.1> Cc: Jeff Roberson , current@freebsd.org Subject: Re: ULE/SCHED_SMP diff for 7.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2007 09:11:41 -0000 > > > The patch patches SCHED_ULE with SCHED_SMP bits, so you need SCHED_ULE > instead of SMP in the kernel. > Off-course. Works now. Sorry for the noise. -- regards Claus When lenity and cruelty play for a kingdom, the gentlest gamester is the soonest winner. Shakespeare From owner-freebsd-current@FreeBSD.ORG Tue Jul 17 09:17:07 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B95A416A40F for ; Tue, 17 Jul 2007 09:17:07 +0000 (UTC) (envelope-from ken@tydfam.jp) Received: from ns.tydfam.jp (ns.tydfam.jp [61.197.228.42]) by mx1.freebsd.org (Postfix) with ESMTP id 527C613C4AA for ; Tue, 17 Jul 2007 09:17:06 +0000 (UTC) (envelope-from ken@tydfam.jp) Received: from localhost (tyd3.sub.tydfam.jp [192.168.1.3]) by ns.tydfam.jp (8.14.1/8.14.1) with ESMTP id l6H8iVFk060919; Tue, 17 Jul 2007 17:44:31 +0900 (JST) (envelope-from ken@tydfam.jp) Date: Tue, 17 Jul 2007 17:44:45 +0900 (JST) Message-Id: <20070717.174445.13760098.ken@tydfam.jp> To: jroberson@chesapeake.net From: Ken Yamada In-Reply-To: <20070716233030.D92541@10.0.0.1> References: <20070716233030.D92541@10.0.0.1> X-Mailer: Mew version 5.2 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91/3687/Tue Jul 17 16:42:10 2007 on ns.tydfam.jp X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.2.1 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on ns.tydfam.jp Cc: current@freebsd.org Subject: Re: ULE/SCHED_SMP diff for 7.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2007 09:17:07 -0000 It works for me! It is Opteron (dual core) x 2 and survived make -j 8 buildworld. Are there any performance comparison data with BSD? From owner-freebsd-current@FreeBSD.ORG Tue Jul 17 09:32:14 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C811C16A407 for ; Tue, 17 Jul 2007 09:32:14 +0000 (UTC) (envelope-from ob@gruft.de) Received: from obh.snafu.de (obh.snafu.de [213.73.92.34]) by mx1.freebsd.org (Postfix) with ESMTP id 7873C13C4BF for ; Tue, 17 Jul 2007 09:32:14 +0000 (UTC) (envelope-from ob@gruft.de) Received: from ob by obh.snafu.de with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IAj2b-000JVc-St; Tue, 17 Jul 2007 11:08:21 +0200 Date: Tue, 17 Jul 2007 11:08:21 +0200 From: Oliver Brandmueller To: Claus Guttesen Message-ID: <20070717090821.GZ94063@e-Gitt.NET> References: <20070716233030.D92541@10.0.0.1> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="YrlhzR9YrZtruaFS" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.16 (2007-06-09) Sender: Oliver Brandmueller Cc: Jeff Roberson , current@freebsd.org Subject: Re: ULE/SCHED_SMP diff for 7.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2007 09:32:14 -0000 --YrlhzR9YrZtruaFS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Moin, On Tue, Jul 17, 2007 at 10:59:23AM +0200, Claus Guttesen wrote: >> http://people.freebsd.org/~jeff/ule.diff >>=20 >> This patch is scheduled for inclusion in 7.0. I would like anyone who >> cares to run it to validate that it does not create any stability or >> performance regression over the existing ULE. This patch replaces ULE >> with SCHED_SMP, which will now no longer exist as a seperate fork of ULE. >=20 > Applied the patch and tried to compile new kernel. However I get: [...] > /usr/src/sys/amd64/conf/WEBSRV: unknown option "SCHED_SMP" Well, I understand the sentence from Jeff in a way, that you should use=20 "SCHED_ULE"; while SCHED_SMP is no longer a fork on it's own but now=20 merged (back) into SCHED_ULE for inclusion in the release. - Olli --=20 | Oliver Brandmueller | Offenbacher Str. 1 | Germany D-14197 Berlin | | Fon +49-172-3130856 | Fax +49-172-3145027 | WWW: http://the.addict.de/ | | Ich bin das Internet. Sowahr ich Gott helfe. | | Eine gewerbliche Nutzung aller enthaltenen Adressen ist nicht gestattet! | --YrlhzR9YrZtruaFS Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFGnIcFiqtMdzjafykRAlX7AKDOZaBHd9TWsL5cqf4XxYG3prwhxQCfZrrh ejFTxOODJaDMs4Uvty1zp9c= =7aPk -----END PGP SIGNATURE----- --YrlhzR9YrZtruaFS-- From owner-freebsd-current@FreeBSD.ORG Tue Jul 17 09:40:05 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7165E16A400 for ; Tue, 17 Jul 2007 09:40:05 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from mxout7.cac.washington.edu (mxout7.cac.washington.edu [140.142.32.178]) by mx1.freebsd.org (Postfix) with ESMTP id 4C40313C4A7 for ; Tue, 17 Jul 2007 09:40:05 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.7] (may be forged)) by mxout7.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.06) with ESMTP id l6H9dwHQ024882 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 17 Jul 2007 02:39:58 -0700 X-Auth-Received: from [192.168.10.45] (c-24-10-12-194.hsd1.ca.comcast.net [24.10.12.194]) (authenticated authid=youshi10) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l6H9dvPh030506 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 17 Jul 2007 02:39:57 -0700 Message-ID: <469C8E6C.3060404@u.washington.edu> Date: Tue, 17 Jul 2007 02:39:56 -0700 From: Garrett Cooper User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Claus Guttesen References: <20070716233030.D92541@10.0.0.1> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 5.3.2.304607, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.7.17.22151 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='SUPERLONG_LINE 0.05, __CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_PHRASE_7 0, __USER_AGENT 0' Cc: Jeff Roberson , current@freebsd.org Subject: Re: ULE/SCHED_SMP diff for 7.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2007 09:40:05 -0000 Claus Guttesen wrote: >> http://people.freebsd.org/~jeff/ule.diff >> >> This patch is scheduled for inclusion in 7.0. I would like anyone who >> cares to run it to validate that it does not create any stability or >> performance regression over the existing ULE. This patch replaces ULE >> with SCHED_SMP, which will now no longer exist as a seperate fork of >> ULE. > > Applied the patch and tried to compile new kernel. However I get: > > julie/usr/src#>time make -j 3 buildkernel > -------------------------------------------------------------- >>>> Kernel build for WEBSRV started on Tue Jul 17 10:56:34 CEST 2007 > -------------------------------------------------------------- > ===> WEBSRV > mkdir -p /usr/obj/usr/src/sys > -------------------------------------------------------------- >>>> stage 1: configuring the kernel > -------------------------------------------------------------- > cd /usr/src/sys/amd64/conf; > PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin > > config -d /usr/obj/usr/src/sys/WEBSRV > /usr/src/sys/amd64/conf/WEBSRV > /usr/src/sys/amd64/conf/WEBSRV: unknown option "SCHED_SMP" > *** Error code 1 > 1 error > *** Error code 2 > 1 error > make -j 3 buildkernel 0.06s user 0.04s system 101% cpu 0.101 total > > I have > > options SCHED_SMP # Newer SMP scheduler > > in my kernel. > > Hunk succeeded everytime, src is from last week. > Excellent work Jeff (with note to whoever modified the fs code as well)! My fat program seems to have survived 4 complete iterations of 1 million reads and writes, all without issue, with my printf statements that appeared to have stimulated a race condition at ~90k reads and writes before. I'll let it run overnight to completion (another 46 tries), and let you know how it goes :).. System is a UP amd64 capable VMware host. Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Tue Jul 17 09:54:13 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1E07C16A400 for ; Tue, 17 Jul 2007 09:54:13 +0000 (UTC) (envelope-from ganbold@micom.mng.net) Received: from publicd.ub.mng.net (publicd.ub.mng.net [202.179.0.88]) by mx1.freebsd.org (Postfix) with ESMTP id 28CEA13C4A7 for ; Tue, 17 Jul 2007 09:54:12 +0000 (UTC) (envelope-from ganbold@micom.mng.net) Received: from [202.179.0.164] (helo=daemon.micom.mng.net) by publicd.ub.mng.net with esmtpa (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IAiif-000Orr-3l; Tue, 17 Jul 2007 16:47:45 +0800 Message-ID: <469C8230.2090707@micom.mng.net> Date: Tue, 17 Jul 2007 16:47:44 +0800 From: Ganbold User-Agent: Thunderbird 2.0.0.0 (X11/20070425) MIME-Version: 1.0 To: Jeff Roberson References: <20070716233030.D92541@10.0.0.1> In-Reply-To: <20070716233030.D92541@10.0.0.1> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: ULE/SCHED_SMP diff for 7.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2007 09:54:13 -0000 Jeff Roberson wrote: > http://people.freebsd.org/~jeff/ule.diff > > This patch is scheduled for inclusion in 7.0. I would like anyone who > cares to run it to validate that it does not create any stability or > performance regression over the existing ULE. This patch replaces ULE > with SCHED_SMP, which will now no longer exist as a seperate fork of ULE. > > Briefly, this is still a very suitable scheduler for uniprocessor > machines while providing stronger affinity and other performance > improvements for multiprocessor machines. > > Even "works for me!" type responses are welcome so I know roughly how > many people have tested before I commit this close to release. Works fine here. I didn't test much, just played 2 movies using mplayer, run openoffice, xmms etc. 2 movies play fine in regular gnome, however after running beryl one movie plays fine in first desktop, second movie plays with some latency (not smooth) on second desktop. However both movies play fine if they are in same virtual desktop. I guess this kind of problem is related to beryl/xorg. thanks a lot, Ganbold > > Thanks! > Jeff > _______________________________________________ > 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" > > > -- Jacek, a Polish schoolboy, is told by his teacher that he has been chosen to carry the Polish flag in the May Day parade. "Why me?" whines the boy. "Three years ago I carried the flag when Brezhnev was the Secretary; then I carried the flag when it was Andropov's turn, and again when Chernenko was in the Kremlin. Why is it always me, teacher?" "Because, Jacek, you have such golden hands," the teacher explains. -- being told in Poland, 1987 From owner-freebsd-current@FreeBSD.ORG Tue Jul 17 10:02:23 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 81F7E16A401 for ; Tue, 17 Jul 2007 10:02:23 +0000 (UTC) (envelope-from ganbold@micom.mng.net) Received: from publicd.ub.mng.net (publicd.ub.mng.net [202.179.0.88]) by mx1.freebsd.org (Postfix) with ESMTP id 8428713C46B for ; Tue, 17 Jul 2007 10:02:22 +0000 (UTC) (envelope-from ganbold@micom.mng.net) Received: from [202.179.0.164] (helo=daemon.micom.mng.net) by publicd.ub.mng.net with esmtpa (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IAjsn-000PrX-OC; Tue, 17 Jul 2007 18:02:17 +0800 Message-ID: <469C93A9.1060105@micom.mng.net> Date: Tue, 17 Jul 2007 18:02:17 +0800 From: Ganbold User-Agent: Thunderbird 2.0.0.0 (X11/20070425) MIME-Version: 1.0 To: Jeff Roberson References: <20070716233030.D92541@10.0.0.1> In-Reply-To: <20070716233030.D92541@10.0.0.1> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: ULE/SCHED_SMP diff for 7.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2007 10:02:23 -0000 Jeff Roberson wrote: > http://people.freebsd.org/~jeff/ule.diff > > This patch is scheduled for inclusion in 7.0. I would like anyone who > cares to run it to validate that it does not create any stability or > performance regression over the existing ULE. This patch replaces ULE > with SCHED_SMP, which will now no longer exist as a seperate fork of ULE. > > Briefly, this is still a very suitable scheduler for uniprocessor > machines while providing stronger affinity and other performance > improvements for multiprocessor machines. > > Even "works for me!" type responses are welcome so I know roughly how > many people have tested before I commit this close to release. Forgot to tell that I have machine with: CPU: Genuine Intel(R) CPU T2300 @ 1.66GHz (1664.45-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6e8 Stepping = 8 Features=0xbfe9fbff Features2=0xc1a9 AMD Features=0x100000 Cores per package: 2 real memory = 1063849984 (1014 MB) avail memory = 1031077888 (983 MB) FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs and WITNESS/INVARIANTS enabled kernel. Ganbold > > Thanks! > Jeff > _______________________________________________ > 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" > > > -- Crush! Kill! Destroy! From owner-freebsd-current@FreeBSD.ORG Tue Jul 17 10:12:48 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 844B616A406 for ; Tue, 17 Jul 2007 10:12:48 +0000 (UTC) (envelope-from bdonnell@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.235]) by mx1.freebsd.org (Postfix) with ESMTP id 3A36113C4BE for ; Tue, 17 Jul 2007 10:12:48 +0000 (UTC) (envelope-from bdonnell@gmail.com) Received: by wr-out-0506.google.com with SMTP id i23so750596wra for ; Tue, 17 Jul 2007 03:12:47 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=GTYNqWdRkMioOZgkBqT61FOBaLM5+DCQUPdh81gJRcy43VQFtR2kYvw1vhmG1fwX/I8ZxCpgHYZhfzqgxOgJKiKUZeM65vWxyEdJ0v9M7KKsEAk8kVUD8Cd3g6MIw3ALQRZAIxN3FCzuy6pwHNrghf1UUUrqWFoGSbwO841ImS0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=TetIbMECiO1vX+/r6cc5ZIlfFj3hJNQjT5QGr4OLtizmEBSxgc7jlHZCDfq2O0l1PenqjH4B5KdXaIEH9j2UVMMhYK1MFnyLe+DLPqBE88KgeNrH81q6rqkDF0Z3S2ghI2UaDHuvtCzDFMeZI1yIU9ngHXCMIjIXSy4TQgaMXyk= Received: by 10.143.33.19 with SMTP id l19mr21095wfj.1184667166846; Tue, 17 Jul 2007 03:12:46 -0700 (PDT) Received: by 10.142.77.9 with HTTP; Tue, 17 Jul 2007 03:12:46 -0700 (PDT) Message-ID: <1c5c32890707170312r71f3735at958325a08db0f1c3@mail.gmail.com> Date: Tue, 17 Jul 2007 06:12:46 -0400 From: "Brian Donnell" To: "Steven Schlansker" In-Reply-To: <469C48F2.7000302@berkeley.edu> MIME-Version: 1.0 References: <2978EDA9-D393-434C-B734-2DE188631761@berkeley.edu> <469C3900.5020703@berkeley.edu> <1c5c32890707162045u9d56cfeq2f7430ddddd55418@mail.gmail.com> <469C48F2.7000302@berkeley.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: Re: Strange performance characteristics with ZFS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Jul 2007 10:12:48 -0000 That was my fault, I misread what you had said your configuration was. The problem I ran into was the same as you're seeing with the system waiting on ZFS causing the NFS client to hang and everything becoming unresponsive. The ls script should be running on the ZFS machine and executing ls on the ZFS directory. If you have a smaller file to try with first I'd recommend it. 30GB of corrupt data is just pain. To be honest, I gave up on NFS with ZFS and started using Samba for everything after compiling samba3 without a couple functions (check the ZFS vs Samba debugging results thread from earlier this month) as it actually maxes out a 100Mbit network link for the transfer. That's something I could never get NFS with ZFS to come close to doing. Just to be sure, since you're using nfsd, that means you have the sharenfs option of the zfs pool turned off? -- Brian On 7/17/07, Steven Schlansker wrote: > > That turned out to be a particularly bad idea. As soon as I executed > that on the server, the client's cpu pegged! Despite the fact that > there is about 5MB/s transfer over the network, the client is no longer > making any progress on the copy. The nfsd processes on the bsd server > are still happily chugging away serving data in the same fits and bursts > as before, but the linux machine receiving the data doesn't seem to be > doing anything with it. I restarted the nfsd and mountd processes, > I'll let it run for a bit... > > Aha. It corrupted data. Now I have to start the copy over again :/ > > This is not good! Anything else I can try? (Hopefully without making > the process fail :-p ) > > Thanks! > > Brian Donnell wrote: > > When I was experimenting with ZFS over NFS I had similar experiences. > > Do me a favor and try something that sounds a little out there. On a > > shell on the ZFS machine set up a looping script that executes an ls on > > the directory you're writing the file to once every second and watch > > your transfer rates. I noticed a marked improvement, but I could never > > determine if it was ZFS or the client NFS implementation. > > > > -- Brian > > > > From owner-freebsd-current@FreeBSD.ORG Tue Jul 17 10:18:18 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9F8D516A402 for ; Tue, 17 Jul 2007 10:18:18 +0000 (UTC) (envelope-from kometen@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.224]) by mx1.freebsd.org (Postfix) with ESMTP id 5FD9613C428 for ; Tue, 17 Jul 2007 10:18:18 +0000 (UTC) (envelope-from kometen@gmail.com) Received: by wx-out-0506.google.com with SMTP id i29so1201772wxd for ; Tue, 17 Jul 2007 03:18:17 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=MdWMWa/Qq++nsODjBJd5JI2Oh8SckQmVBF9vjVey9C/KkuATpn98TdJp+M4zkmDvhlYS64s8ZQ7QxXZzPpHvdIWi4awhypkD/FZrx82I+PcG0UZB0UshXNorSBgP9NtApk8yJcPSx7Xjd2VXcjKkI7RyXPbVyCUWK3LM9ABbf0o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=BrFiz/unuIMW7H10mjS+jwepQod1h/Se+uCnbq3raGFyvLkaUq7R8lv0HsMxt1ZDyJn139VsmbqRTqHIaMY3nFDRSK/peOzDhyDbOTUdKQh8izWmRsPFIJ7AubcNTtV9C8bWlf+CcaWBBHXnNOUtyU3YPgSZJUTnMHpNS75V1Bs= Received: by 10.70.73.12 with SMTP id v12mr556938wxa.1184667497368; Tue, 17 Jul 2007 03:18:17 -0700 (PDT) Received: by 10.70.41.4 with HTTP; Tue, 17 Jul 2007 03:18:17 -0700 (PDT) Message-ID: Date: Tue, 17 Jul 2007 12:18:17 +0200 From: "Claus Guttesen" To: "Jeff Roberson" In-Reply-To: <20070716233030.D92541@10.0.0.1> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070716233030.D92541@10.0.0.1> Cc: current@freebsd.org Subject: Re: ULE/SCHED_SMP diff for 7.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2007 10:18:18 -0000 > This patch is scheduled for inclusion in 7.0. I would like anyone who > cares to run it to validate that it does not create any stability or > performance regression over the existing ULE. This patch replaces ULE > with SCHED_SMP, which will now no longer exist as a seperate fork of ULE. Not very scientific nor precise but using 4bsd as scheduler 'make -j 3 buildkernel' completed in 11 min. 58 secs. and ule did the same in 13 min. 26 secs. So ule seems slower. This is on a dual zeon @ 3.2 Ghz (the first 64-bit from Intel, not very fast but hot) and 3 GB ram and 15 RPM scsi-disk with /usr on zfs. -- regards Claus When lenity and cruelty play for a kingdom, the gentlest gamester is the soonest winner. Shakespeare From owner-freebsd-current@FreeBSD.ORG Tue Jul 17 10:31:56 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.ORG Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A086716A400 for ; Tue, 17 Jul 2007 10:31:56 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [83.120.8.8]) by mx1.freebsd.org (Postfix) with ESMTP id 1DDAD13C4B7 for ; Tue, 17 Jul 2007 10:31:55 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (qfmhmd@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.4/8.13.4) with ESMTP id l6HAVmh5088206; Tue, 17 Jul 2007 12:31:53 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.4/8.13.1/Submit) id l6HAVmDZ088205; Tue, 17 Jul 2007 12:31:48 +0200 (CEST) (envelope-from olli) Date: Tue, 17 Jul 2007 12:31:48 +0200 (CEST) Message-Id: <200707171031.l6HAVmDZ088205@lurza.secnetix.de> From: Oliver Fromme To: freebsd-current@FreeBSD.ORG, marck@rinet.ru, dougb@FreeBSD.ORG In-Reply-To: <469BB428.1020200@FreeBSD.org> X-Newsgroups: list.freebsd-current User-Agent: tin/1.8.2-20060425 ("Shillay") (UNIX) (FreeBSD/4.11-STABLE (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Tue, 17 Jul 2007 12:31:54 +0200 (CEST) Cc: Subject: Re: RFT: bin/106642: [patch] Allow excluding certain files from mergemaster (8) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-current@FreeBSD.ORG, marck@rinet.ru, dougb@FreeBSD.ORG List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2007 10:31:56 -0000 Doug Barton wrote: > Dmitry Morozovsky wrote: > > On Wed, 11 Jul 2007, Doug Barton wrote: > > > > DB> > About pre-script which you suggested, there is another problem -- I MAY > > DB> > have new scripts in /etc/rc.d, but NEVER change the system's scripts. > > DB> > > DB> Simple answer, don't do that. Put your scripts in /usr/local/etc/rc.d > > DB> instead, and as of 6.1 and newer they will be included in the base > > DB> rcorder. Therefore there will be no difference in when they are run. > > DB> There is a default assumption that stuff in /etc/rc.d is the systems, > > DB> and the systems only. Now that local scripts (including ports) are in > > DB> the base rcorder, there is no reason not to do it that way. > > > > The first exclusion in mind would be scripts that should be running before > > mounting file systems other than root... > > My recommendation in that scenario would be to play with the value of > early_late_divider until you got something that worked for you. That's > why I made it a variable. :) > > If there is a particular combination of things that have to happen > that early_late_divider won't work for, I'd be interested in hearing > that so that we could look at possibly adjusting the code if it's > possible. On my notebook I have a script /etc/rc.d/net-detect that pings several IP addresses in order to find out in which network environment the notebook is used (at the office, at home with wlan, at home with 100base-t, or no network at all). The script then adjusts several symlinks based on the network environment, i.e. several files in /etc are changed, including rc.conf, ntp.conf, resolv.conf, fstab (!), hosts and others. That script runs as the very first rc script, even before root is mounted r/w (it does fsck -p / + mount -u -o rw /, then changes the symlinks, then mount -u -o ro /). Works perfectly fine for me. The only thing I need to be careful about is to tell mergemaster not to remove that script. Mergemaster's default, unfortunately, is to delete all unknown scripts in /etc/rc.d. Of course I do have a backup copy, so I can easily recover if needed. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "I invented Ctrl-Alt-Delete, but Bill Gates made it famous." -- David Bradley, original IBM PC design team From owner-freebsd-current@FreeBSD.ORG Tue Jul 17 10:34:57 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AD95316A409; Tue, 17 Jul 2007 10:34:57 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) by mx1.freebsd.org (Postfix) with ESMTP id 338A013C4AC; Tue, 17 Jul 2007 10:34:56 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.1/8.14.1) with ESMTP id l6HAYu7C006714; Tue, 17 Jul 2007 14:34:56 +0400 (MSD) (envelope-from marck@rinet.ru) Date: Tue, 17 Jul 2007 14:34:56 +0400 (MSD) From: Dmitry Morozovsky To: freebsd-current@freebsd.org, marck@rinet.ru, dougb@freebsd.org In-Reply-To: <200707171031.l6HAVmDZ088205@lurza.secnetix.de> Message-ID: <20070717143422.F82929@woozle.rinet.ru> References: <200707171031.l6HAVmDZ088205@lurza.secnetix.de> X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (woozle.rinet.ru [0.0.0.0]); Tue, 17 Jul 2007 14:34:56 +0400 (MSD) Cc: Subject: Re: RFT: bin/106642: [patch] Allow excluding certain files from mergemaster (8) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2007 10:34:57 -0000 On Tue, 17 Jul 2007, Oliver Fromme wrote: OF> > My recommendation in that scenario would be to play with the value of OF> > early_late_divider until you got something that worked for you. That's OF> > why I made it a variable. :) OF> > OF> > If there is a particular combination of things that have to happen OF> > that early_late_divider won't work for, I'd be interested in hearing OF> > that so that we could look at possibly adjusting the code if it's OF> > possible. OF> OF> On my notebook I have a script /etc/rc.d/net-detect that OF> pings several IP addresses in order to find out in which OF> network environment the notebook is used (at the office, OF> at home with wlan, at home with 100base-t, or no network OF> at all). The script then adjusts several symlinks based OF> on the network environment, i.e. several files in /etc OF> are changed, including rc.conf, ntp.conf, resolv.conf, OF> fstab (!), hosts and others. OF> OF> That script runs as the very first rc script, even before OF> root is mounted r/w (it does fsck -p / + mount -u -o rw /, OF> then changes the symlinks, then mount -u -o ro /). OF> OF> Works perfectly fine for me. The only thing I need to be OF> careful about is to tell mergemaster not to remove that OF> script. Mergemaster's default, unfortunately, is to delete OF> all unknown scripts in /etc/rc.d. Of course I do have a OF> backup copy, so I can easily recover if needed. Hmm, if it is the very first rc.d script, why don't you name it /etc/rc.early ? Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Tue Jul 17 10:36:54 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0218416A403 for ; Tue, 17 Jul 2007 10:36:54 +0000 (UTC) (envelope-from olivier@aixmarseille.com) Received: from anchor.aixmarseille.com (anchor.aixmarseille.com [81.201.184.34]) by mx1.freebsd.org (Postfix) with ESMTP id C1DAD13C48E for ; Tue, 17 Jul 2007 10:36:53 +0000 (UTC) (envelope-from olivier@aixmarseille.com) Received: from [81.80.156.33] (helo=[192.168.13.13]) by anchor.aixmarseille.com with esmtpsa (TLS-1.0:RSA_ARCFOUR_MD5:16) (Exim 4.50) id 1IAjjf-00077c-1l for current@freebsd.org; Tue, 17 Jul 2007 09:52:51 +0000 From: Olivier Fauchon To: current@freebsd.org Content-Type: text/plain Date: Tue, 17 Jul 2007 11:52:43 +0200 Message-Id: <1184665963.1056.9.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Subject: Xen Status Page X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Jul 2007 10:36:54 -0000 Hi, It's a long time now we hear of Xen for FreeBSD-curent. I guess It's not done yet. - What's the best place to get informations about this project ? - What's the status and TODO ? From owner-freebsd-current@FreeBSD.ORG Tue Jul 17 10:40:54 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2908B16A405 for ; Tue, 17 Jul 2007 10:40:54 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by mx1.freebsd.org (Postfix) with ESMTP id A2D3413C4C6 for ; Tue, 17 Jul 2007 10:40:53 +0000 (UTC) (envelope-from max@love2party.net) Received: from [88.66.32.136] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu7) with ESMTP (Nemesis), id 0ML2xA-1IAkTy2pct-0003c8; Tue, 17 Jul 2007 12:40:43 +0200 From: Max Laier Organization: FreeBSD To: freebsd-current@freebsd.org Date: Tue, 17 Jul 2007 12:42:45 +0200 User-Agent: KMail/1.9.7 References: <1184665963.1056.9.camel@localhost> In-Reply-To: <1184665963.1056.9.camel@localhost> X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1187435.ZOeaU5WyUa"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200707171242.55341.max@love2party.net> X-Provags-ID: V01U2FsdGVkX18/QGR2O7Oo0OcabfStg/1ryM/XrvAKFT2O6Ed 9WgtOHAFU2psai2ECmuBbf68yt+oC0qa362qEt6arU1aWh1bYV +GOOWPM13KHrE0jtD2yYGjBLZqBXKq/ldK/H0Hn/BM= Cc: Olivier Fauchon Subject: Re: Xen Status Page X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Jul 2007 10:40:54 -0000 --nextPart1187435.ZOeaU5WyUa Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Tuesday 17 July 2007, Olivier Fauchon wrote: > It's a long time now we hear of Xen for FreeBSD-curent. There has been a report in the recent status reports collection:=20 http://www.freebsd.org/news/status/report-2007-04-2007-06.html#FreeBSD/xen =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart1187435.ZOeaU5WyUa Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQBGnJ0vXyyEoT62BG0RAtKGAJ9JJDTHbtZg9KDW2A1x9xAqK3XUiQCfbkky CxXjtfPUpos4LPRT4As3Rjc= =RHXD -----END PGP SIGNATURE----- --nextPart1187435.ZOeaU5WyUa-- From owner-freebsd-current@FreeBSD.ORG Tue Jul 17 10:44:29 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.ORG Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AB94E16A410; Tue, 17 Jul 2007 10:44:29 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [83.120.8.8]) by mx1.freebsd.org (Postfix) with ESMTP id 1661D13C4B6; Tue, 17 Jul 2007 10:44:28 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (atmzeb@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.4/8.13.4) with ESMTP id l6HAiMBI089060; Tue, 17 Jul 2007 12:44:27 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.4/8.13.1/Submit) id l6HAiMs1089059; Tue, 17 Jul 2007 12:44:22 +0200 (CEST) (envelope-from olli) Date: Tue, 17 Jul 2007 12:44:22 +0200 (CEST) Message-Id: <200707171044.l6HAiMs1089059@lurza.secnetix.de> From: Oliver Fromme To: freebsd-current@FreeBSD.ORG, marck@rinet.ru, dougb@FreeBSD.ORG In-Reply-To: <20070717143422.F82929@woozle.rinet.ru> X-Newsgroups: list.freebsd-current User-Agent: tin/1.8.2-20060425 ("Shillay") (UNIX) (FreeBSD/4.11-STABLE (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Tue, 17 Jul 2007 12:44:27 +0200 (CEST) Cc: Subject: Re: RFT: bin/106642: [patch] Allow excluding certain files from mergemaster (8) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-current@FreeBSD.ORG, marck@rinet.ru, dougb@FreeBSD.ORG List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2007 10:44:29 -0000 Dmitry Morozovsky wrote: > Oliver Fromme wrote: > OF> On my notebook I have a script /etc/rc.d/net-detect that > OF> pings several IP addresses in order to find out in which > OF> network environment the notebook is used (at the office, > OF> at home with wlan, at home with 100base-t, or no network > OF> at all). The script then adjusts several symlinks based > OF> on the network environment, i.e. several files in /etc > OF> are changed, including rc.conf, ntp.conf, resolv.conf, > OF> fstab (!), hosts and others. > OF> > OF> That script runs as the very first rc script, even before > OF> root is mounted r/w (it does fsck -p / + mount -u -o rw /, > OF> then changes the symlinks, then mount -u -o ro /). > OF> > OF> Works perfectly fine for me. The only thing I need to be > OF> careful about is to tell mergemaster not to remove that > OF> script. Mergemaster's default, unfortunately, is to delete > OF> all unknown scripts in /etc/rc.d. Of course I do have a > OF> backup copy, so I can easily recover if needed. > > Hmm, if it is the very first rc.d script, why don't you name it > /etc/rc.early ? Because /etc/rc.early is _not_ the very first script being run. See: $ rcorder /etc/rc.d/* | sed -n '1,/early/p' /etc/rc.d/dumpon /etc/rc.d/initrandom /etc/rc.d/geli /etc/rc.d/gbde /etc/rc.d/encswap /etc/rc.d/ccd /etc/rc.d/swap1 /etc/rc.d/mdconfig /etc/rc.d/ramdisk /etc/rc.d/early.sh $ Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "I started using PostgreSQL around a month ago, and the feeling is similar to the switch from Linux to FreeBSD in '96 -- 'wow!'." -- Oddbjorn Steffensen From owner-freebsd-current@FreeBSD.ORG Tue Jul 17 10:46:31 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.ORG Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BB3BA16A401; Tue, 17 Jul 2007 10:46:31 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) by mx1.freebsd.org (Postfix) with ESMTP id 07C1D13C4C2; Tue, 17 Jul 2007 10:46:30 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.1/8.14.1) with ESMTP id l6HAkT4v006889; Tue, 17 Jul 2007 14:46:29 +0400 (MSD) (envelope-from marck@rinet.ru) Date: Tue, 17 Jul 2007 14:46:29 +0400 (MSD) From: Dmitry Morozovsky To: freebsd-current@FreeBSD.ORG, marck@rinet.ru, dougb@FreeBSD.ORG In-Reply-To: <200707171044.l6HAiMs1089059@lurza.secnetix.de> Message-ID: <20070717144533.A82929@woozle.rinet.ru> References: <200707171044.l6HAiMs1089059@lurza.secnetix.de> X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (woozle.rinet.ru [0.0.0.0]); Tue, 17 Jul 2007 14:46:29 +0400 (MSD) Cc: Subject: Re: RFT: bin/106642: [patch] Allow excluding certain files from mergemaster (8) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2007 10:46:31 -0000 On Tue, 17 Jul 2007, Oliver Fromme wrote: OF> > Hmm, if it is the very first rc.d script, why don't you name it OF> > /etc/rc.early ? OF> OF> Because /etc/rc.early is _not_ the very first script OF> being run. See: OF> OF> $ rcorder /etc/rc.d/* | sed -n '1,/early/p' OF> /etc/rc.d/dumpon OF> /etc/rc.d/initrandom OF> /etc/rc.d/geli OF> /etc/rc.d/gbde OF> /etc/rc.d/encswap OF> /etc/rc.d/ccd OF> /etc/rc.d/swap1 OF> /etc/rc.d/mdconfig OF> /etc/rc.d/ramdisk OF> /etc/rc.d/early.sh OF> $ Ah well, I see; this looks a bit strange though ;-) Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Tue Jul 17 10:51:37 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.ORG Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C15AB16A404 for ; Tue, 17 Jul 2007 10:51:37 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [83.120.8.8]) by mx1.freebsd.org (Postfix) with ESMTP id 49E0D13C4C4 for ; Tue, 17 Jul 2007 10:51:37 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (inaxyd@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.4/8.13.4) with ESMTP id l6HApMFc089193; Tue, 17 Jul 2007 12:51:31 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.4/8.13.1/Submit) id l6HApMrw089192; Tue, 17 Jul 2007 12:51:22 +0200 (CEST) (envelope-from olli) Date: Tue, 17 Jul 2007 12:51:22 +0200 (CEST) Message-Id: <200707171051.l6HApMrw089192@lurza.secnetix.de> From: Oliver Fromme To: freebsd-current@FreeBSD.ORG, olivier@aixmarseille.com In-Reply-To: <1184665963.1056.9.camel@localhost> X-Newsgroups: list.freebsd-current User-Agent: tin/1.8.2-20060425 ("Shillay") (UNIX) (FreeBSD/4.11-STABLE (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Tue, 17 Jul 2007 12:51:31 +0200 (CEST) Cc: Subject: Re: Xen Status Page X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-current@FreeBSD.ORG, olivier@aixmarseille.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2007 10:51:37 -0000 Olivier Fauchon wrote: > It's a long time now we hear of Xen for FreeBSD-curent. No, not a long time. It was mentioned in the "FreeBSD Status Reports Q2/2007" that Max Laier posted last Tuesday. Please look at it. It answers your questions. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "And believe me, as a C++ programmer, I don't hesitate to question the decisions of language designers. After a decent amount of C++ exposure, Python's flaws seem ridiculously small." -- Ville Vainio From owner-freebsd-current@FreeBSD.ORG Tue Jul 17 11:11:04 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.ORG Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 92DF816A401; Tue, 17 Jul 2007 11:11:04 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [83.120.8.8]) by mx1.freebsd.org (Postfix) with ESMTP id 1808A13C48D; Tue, 17 Jul 2007 11:11:03 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (fwnetw@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.4/8.13.4) with ESMTP id l6HBAvLL089894; Tue, 17 Jul 2007 13:11:02 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.4/8.13.1/Submit) id l6HBAvB7089893; Tue, 17 Jul 2007 13:10:57 +0200 (CEST) (envelope-from olli) Date: Tue, 17 Jul 2007 13:10:57 +0200 (CEST) Message-Id: <200707171110.l6HBAvB7089893@lurza.secnetix.de> From: Oliver Fromme To: freebsd-current@FreeBSD.ORG, marck@rinet.ru, dougb@FreeBSD.ORG In-Reply-To: <20070717144533.A82929@woozle.rinet.ru> X-Newsgroups: list.freebsd-current User-Agent: tin/1.8.2-20060425 ("Shillay") (UNIX) (FreeBSD/4.11-STABLE (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Tue, 17 Jul 2007 13:11:02 +0200 (CEST) Cc: Subject: Re: RFT: bin/106642: [patch] Allow excluding certain files from mergemaster (8) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-current@FreeBSD.ORG, marck@rinet.ru, dougb@FreeBSD.ORG List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2007 11:11:04 -0000 Dmitry Morozovsky wrote: > Oliver Fromme wrote: > > OF> Because /etc/rc.early is _not_ the very first script > OF> being run. See: > OF> > OF> $ rcorder /etc/rc.d/* | sed -n '1,/early/p' > OF> /etc/rc.d/dumpon > OF> /etc/rc.d/initrandom > OF> /etc/rc.d/geli > OF> /etc/rc.d/gbde > OF> /etc/rc.d/encswap > OF> /etc/rc.d/ccd > OF> /etc/rc.d/swap1 > OF> /etc/rc.d/mdconfig > OF> /etc/rc.d/ramdisk > OF> /etc/rc.d/early.sh > OF> $ > > Ah well, I see; this looks a bit strange though ;-) That output is from a RELENG_6 machine. Might look a bit different on -current, though, but early.sh still isn't the first one. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "anyone new to programming should be kept as far from C++ as possible; actually showing the stuff should be considered a criminal offence" -- Jacek Generowicz From owner-freebsd-current@FreeBSD.ORG Tue Jul 17 04:50:50 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A023316A404 for ; Tue, 17 Jul 2007 04:50:50 +0000 (UTC) (envelope-from bounces@nabble.com) Received: from kuber.nabble.com (kuber.nabble.com [216.139.236.158]) by mx1.freebsd.org (Postfix) with ESMTP id 8235D13C4B6 for ; Tue, 17 Jul 2007 04:50:50 +0000 (UTC) (envelope-from bounces@nabble.com) Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1IAf1O-0007sQ-4q for freebsd-current@freebsd.org; Mon, 16 Jul 2007 21:50:50 -0700 Message-ID: <11643019.post@talk.nabble.com> Date: Mon, 16 Jul 2007 21:50:50 -0700 (PDT) From: icaer To: freebsd-current@freebsd.org In-Reply-To: <20070708143134.GB1027@darklight.org.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: jony1116@hotmail.com References: <1183557221.1799.16.camel@genius.i.cz> <20070704143642.GA31254@nagual.pp.ru> <20070704150312.GB31683@nagual.pp.ru> <11488718.post@talk.nabble.com> <20070708143134.GB1027@darklight.org.ru> X-Mailman-Approved-At: Tue, 17 Jul 2007 11:31:44 +0000 Subject: Re: Environment handling broken in /bin/sh with changes to {get,set,put}env() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Jul 2007 04:50:50 -0000 en...I have apply the patch. Thanks a lot. Yuri Pankov-4 wrote: > > On Sun, Jul 08, 2007 at 06:28:47AM -0700, icaer wrote: >> >> Hi, >> How to apply this patch,if I want to correct it? >> rebuild the world?or other method. >> I try to get the new code by cvsup.But it compiled error( >> http://www.nabble.com/buildworld-error-tf4032292.html >> http://www.nabble.com/buildworld-error-tf4032292.html ).So I shouldn't >> correct this problem. >> it's bad news for me,I have focus on this problem for 3 days.... >> >> > > It's unrelated to sh brokenness. Check this link: > http://lists.freebsd.org/pipermail/freebsd-current/2007-July/074620.html > > > Yuri > > > -- View this message in context: http://www.nabble.com/Environment-handling-broken-in--bin-sh-with-changes-to-%7Bget%2Cset%2Cput%7Denv%28%29-tf4024589.html#a11643019 Sent from the freebsd-current mailing list archive at Nabble.com. From owner-freebsd-current@FreeBSD.ORG Tue Jul 17 11:50:05 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C878816A496 for ; Tue, 17 Jul 2007 11:50:05 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from ns.trinitel.com (186.161.36.72.static.reverse.layeredtech.com [72.36.161.186]) by mx1.freebsd.org (Postfix) with ESMTP id 9EFD713C4B7 for ; Tue, 17 Jul 2007 11:50:05 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from proton.local (209-163-168-124.static.twtelecom.net [209.163.168.124]) (authenticated bits=0) by ns.trinitel.com (8.14.1/8.14.1) with ESMTP id l6HBo4eo083922; Tue, 17 Jul 2007 06:50:05 -0500 (CDT) (envelope-from anderson@freebsd.org) Message-ID: <469CACEC.1000103@freebsd.org> Date: Tue, 17 Jul 2007 06:50:04 -0500 From: Eric Anderson User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: Claus Guttesen References: <20070716233030.D92541@10.0.0.1> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on ns.trinitel.com Cc: current@freebsd.org Subject: Re: ULE/SCHED_SMP diff for 7.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2007 11:50:05 -0000 Claus Guttesen wrote: >> This patch is scheduled for inclusion in 7.0. I would like anyone who >> cares to run it to validate that it does not create any stability or >> performance regression over the existing ULE. This patch replaces ULE >> with SCHED_SMP, which will now no longer exist as a seperate fork of ULE. > > Not very scientific nor precise but using 4bsd as scheduler 'make -j 3 > buildkernel' completed in 11 min. 58 secs. and ule did the same in 13 > min. 26 secs. So ule seems slower. This is on a dual zeon @ 3.2 Ghz > (the first 64-bit from Intel, not very fast but hot) and 3 GB ram and > 15 RPM scsi-disk with /usr on zfs. > Ahah! 15 RPM drives, no wonder! :) On a serious note, can you do that same test, with '-j 4' or higher? I think you can easily do two per processor, at least that's what I do on a Core 2 Duo. Eric From owner-freebsd-current@FreeBSD.ORG Tue Jul 17 11:56:22 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.ORG Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7A90916A401; Tue, 17 Jul 2007 11:56:22 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) by mx1.freebsd.org (Postfix) with ESMTP id 032C313C4AA; Tue, 17 Jul 2007 11:56:21 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.1/8.14.1) with ESMTP id l6HBuKa9008083; Tue, 17 Jul 2007 15:56:20 +0400 (MSD) (envelope-from marck@rinet.ru) Date: Tue, 17 Jul 2007 15:56:20 +0400 (MSD) From: Dmitry Morozovsky To: freebsd-current@FreeBSD.ORG, marck@rinet.ru, dougb@FreeBSD.ORG In-Reply-To: <200707171110.l6HBAvB7089893@lurza.secnetix.de> Message-ID: <20070717155357.N82929@woozle.rinet.ru> References: <200707171110.l6HBAvB7089893@lurza.secnetix.de> X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (woozle.rinet.ru [0.0.0.0]); Tue, 17 Jul 2007 15:56:20 +0400 (MSD) Cc: Subject: Re: RFT: bin/106642: [patch] Allow excluding certain files from mergemaster (8) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2007 11:56:22 -0000 On Tue, 17 Jul 2007, Oliver Fromme wrote: OF> > OF> Because /etc/rc.early is _not_ the very first script OF> > OF> being run. See: OF> > OF> OF> > OF> $ rcorder /etc/rc.d/* | sed -n '1,/early/p' OF> > OF> /etc/rc.d/dumpon OF> > OF> /etc/rc.d/initrandom OF> > OF> /etc/rc.d/geli OF> > OF> /etc/rc.d/gbde OF> > OF> /etc/rc.d/encswap OF> > OF> /etc/rc.d/ccd OF> > OF> /etc/rc.d/swap1 OF> > OF> /etc/rc.d/mdconfig OF> > OF> /etc/rc.d/ramdisk OF> > OF> /etc/rc.d/early.sh OF> > OF> $ OF> > OF> > Ah well, I see; this looks a bit strange though ;-) OF> OF> That output is from a RELENG_6 machine. Might look a bit OF> different on -current, though, but early.sh still isn't OF> the first one. On current the order is the same, except for ramdisk deleted and mdconfig moved down a bit to after hostid. Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Tue Jul 17 12:21:41 2007 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 40AED16A401; Tue, 17 Jul 2007 12:21:41 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id EC8B513C471; Tue, 17 Jul 2007 12:21:40 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id E294E48B1F; Tue, 17 Jul 2007 08:21:36 -0400 (EDT) Date: Tue, 17 Jul 2007 13:21:36 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: current@FreeBSD.org, arch@FreeBSD.org Message-ID: <20070717131518.G1177@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Subject: Reminder: NET_NEEDS_GIANT, debug.mpsafenet going away in 7.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2007 12:21:41 -0000 Dear all: This is a reminder e-mail that, in the very near future, Giant compatibility shims for network protocols will be removed. These shimmed allowed Giant to be re-enabeld over the network stack as a result of linking in a service that required Giant (now all removed), or by setting the debug.mpsafenet variable to 1. This means that the following will no longer be present: debug.mpsafenet sysctl debug_mpsafenet global variable NET_NEEDS_GIANT() NET_LOCK_GIANT(), NET_UNLOCK_GIANT(), NET_ASSERT_GIANT() NET_CALLOUT_MPSAFE All instances of NET_{LOCK,UNLOCK,ASSERT}_GIANT() will be removed as they will no be no-ops. The (unused) definition of NET_NEEDS_GIANT() will be removed. The debug.mpsafenet sysctl and debug_mpsafenet global variable will be removed. All instances of NET_CALLOUT_MPSAFE will be converted mechanically to CALLOUT_MPSAFE. The *only* remaining case I am aware of where removing debug.mpsafenet presents an issue is credential-related firewall rules (uid, gid, jail). I'm am currently in an active e-mail discussion with the various firewall maintainers about how to address this issue; as the implementations of these rules violate the global lock order, deadlocks occur if debug.mpsafenet isn't set to 1, which causes Giant to act as a guard lock preventing parallel lock acquisition in the firewall. Hopefully we will have this resolved, in some form, soon. I will remove the above in a series of commits; the only complicated bits are removing the NET_*_GIANT() calls from the socket system call code, where they made things quite a bit more complex than desirable due to additional error handling and unwinding, and in the Cronyx drivers, which interact with debug_mpsafenet in unusual ways (disabling their own locking when Giant is present). Otherwise, this is a fairly low-risk change in practice, since 99% of FreeBSD users have been running without Giant over the network stack since 5.4 (or was it 5.3?). Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Tue Jul 17 12:59:12 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 465D916A400 for ; Tue, 17 Jul 2007 12:59:12 +0000 (UTC) (envelope-from lveax.m@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.239]) by mx1.freebsd.org (Postfix) with ESMTP id 06FF813C4AA for ; Tue, 17 Jul 2007 12:59:11 +0000 (UTC) (envelope-from lveax.m@gmail.com) Received: by wx-out-0506.google.com with SMTP id i29so1238025wxd for ; Tue, 17 Jul 2007 05:59:11 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=nbtkxFa8KEs8IFA5Zc9yL3TXA5YCub5R1+3vSMS0H8T2GyPH/cataNf7Zjai9hqikH2aoR7Nn6oqtSs8zdSpCkBs+H1Y6BwYA++Ss6thpL+Ebi/Qw7mKs4zgngyrf7MJrbJWVtlWJ/iTFlw0lzmP7PhSFBlwmhWEgdpF9tqn0VE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=CGZ7SUyNtNf+X32ili+Dyu34J/cgZtMXRhLqNSQdeJ3OKCMi9kr7vjcV3jFCbKjvnR3Ot5LOa51fqsRkBG4yZX69wzCKrdF4io369HJ87XFY37n5lXwH4EEn1LS/WgS8Sd4CPE+spAon3BLYmOCOFyNxrmIvz+3j7VmKtJdaCp8= Received: by 10.90.99.20 with SMTP id w20mr247393agb.1184675604044; Tue, 17 Jul 2007 05:33:24 -0700 (PDT) Received: by 10.90.86.8 with HTTP; Tue, 17 Jul 2007 05:33:24 -0700 (PDT) Message-ID: <576dcbc20707170533h236e50eer7e81f6cdd04e2c0@mail.gmail.com> Date: Tue, 17 Jul 2007 20:33:24 +0800 From: lveax To: freebsd-current@freebsd.org, olivier@aixmarseille.com In-Reply-To: <200707171051.l6HApMrw089192@lurza.secnetix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1184665963.1056.9.camel@localhost> <200707171051.l6HApMrw089192@lurza.secnetix.de> Cc: Subject: Re: Xen Status Page X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Jul 2007 12:59:12 -0000 On 7/17/07, Oliver Fromme wrote: > Olivier Fauchon wrote: > > It's a long time now we hear of Xen for FreeBSD-curent. > > No, not a long time. It was mentioned in the > "FreeBSD Status Reports Q2/2007" that Max Laier > posted last Tuesday. > > Please look at it. It answers your questions. > it will both support dom0 and domU in freebsd7? i find domU support in this page http://www.yuanjue.net/xen/howto.html From owner-freebsd-current@FreeBSD.ORG Tue Jul 17 13:18:44 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C490716A408 for ; Tue, 17 Jul 2007 13:18:44 +0000 (UTC) (envelope-from kometen@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.227]) by mx1.freebsd.org (Postfix) with ESMTP id 52E1813C481 for ; Tue, 17 Jul 2007 13:18:44 +0000 (UTC) (envelope-from kometen@gmail.com) Received: by wx-out-0506.google.com with SMTP id i29so1242865wxd for ; Tue, 17 Jul 2007 06:18:43 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=W+R3CKUx3ax0ClU7LxVOyUrxzivWFEMvGlhJ91BfOnvyQkdkBck+q0WXtsqMFh5YpI/C7/Nps6UMQL2n+b8j19/7GnWVYXZWzt+2AjJlIODq1nUgSb4bXUwssgoFlqpMtr9fZl2wqKZoG1vOUZ71+FwI7QeZBPNoeCxRBxyF9M0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=OJ4LYuBJfDBE5jOx3MjTZoqsjy2DEHvr80R5lIDRu0blx/kNTObjKid5JPGxtQj3LJN91PrLvkjYhUO39Mf9x6Aq3qgQ/xDBUzs4hno+uTDHrYw89wiZtItl41TfCocimB+2A+9GApOuFKsOXdiW3J64JOdZTW0pOqWNGJlcieM= Received: by 10.70.111.2 with SMTP id j2mr726466wxc.1184678323280; Tue, 17 Jul 2007 06:18:43 -0700 (PDT) Received: by 10.70.41.4 with HTTP; Tue, 17 Jul 2007 06:18:43 -0700 (PDT) Message-ID: Date: Tue, 17 Jul 2007 15:18:43 +0200 From: "Claus Guttesen" To: "Eric Anderson" In-Reply-To: <469CACEC.1000103@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070716233030.D92541@10.0.0.1> <469CACEC.1000103@freebsd.org> Cc: current@freebsd.org Subject: Re: ULE/SCHED_SMP diff for 7.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2007 13:18:44 -0000 > >> This patch is scheduled for inclusion in 7.0. I would like anyone who > >> cares to run it to validate that it does not create any stability or > >> performance regression over the existing ULE. This patch replaces ULE > >> with SCHED_SMP, which will now no longer exist as a seperate fork of ULE. > > > > Not very scientific nor precise but using 4bsd as scheduler 'make -j 3 > > buildkernel' completed in 11 min. 58 secs. and ule did the same in 13 > > min. 26 secs. So ule seems slower. This is on a dual zeon @ 3.2 Ghz > > (the first 64-bit from Intel, not very fast but hot) and 3 GB ram and > > 15 RPM scsi-disk with /usr on zfs. > > > > Ahah! 15 RPM drives, no wonder! :) > > On a serious note, can you do that same test, with '-j 4' or higher? I > think you can easily do two per processor, at least that's what I do on > a Core 2 Duo. Shure: sched_ule: -j 3 buildkernel: 13:23 -j 4 buildkernel: 12:38 -j 5 buildkernel: 12:41 -j 6 buildkernel: 12:47 sched_4bsd: -j 3 buildkernel: 11:43 -j 4 buildkernel: 12:02 So sched_ule seems to handle more processes slightly better than 4bsd albeit it does it slower. ule's sweet spot is -j 4 and 4bsd is -j 3. -- regards Claus When lenity and cruelty play for a kingdom, the gentlest gamester is the soonest winner. Shakespeare From owner-freebsd-current@FreeBSD.ORG Tue Jul 17 13:36:30 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5C3EE16A404 for ; Tue, 17 Jul 2007 13:36:30 +0000 (UTC) (envelope-from kometen@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.229]) by mx1.freebsd.org (Postfix) with ESMTP id 14E8A13C481 for ; Tue, 17 Jul 2007 13:36:29 +0000 (UTC) (envelope-from kometen@gmail.com) Received: by wx-out-0506.google.com with SMTP id i29so1247531wxd for ; Tue, 17 Jul 2007 06:36:29 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=nUIR3uTdxjPLZmv/x/vGWo8N5UEwBE119XBaviq9Qa4Sv7enjvmBA9ijArmpL7xHdFFP/eVg+S0sHsI4MfbzTQFJIxWr0GWrWind57+79Nm2NWksSU7UOPGqIABecu0k+HJexxdc+Pk/JdlkO87vp700zTczQQrOwMRGKILXylU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=f5NnvVRNdYIqq2UyGUWLia325RJQUsLt8YapcHzwXMKniE6pOxVhfxQljBDqFP+6N2i2X4ulm0qBykVDOwhC1FhmmTduLcrp0/U9S8Y3rd+VlpmRgl5+HPjaoR7BzyTUpPNCed8kqp5Z0UmyO38LJ+IlYW+YwpZToLrq9og228s= Received: by 10.70.102.16 with SMTP id z16mr801062wxb.1184679389006; Tue, 17 Jul 2007 06:36:29 -0700 (PDT) Received: by 10.70.41.4 with HTTP; Tue, 17 Jul 2007 06:36:28 -0700 (PDT) Message-ID: Date: Tue, 17 Jul 2007 15:36:28 +0200 From: "Claus Guttesen" To: lveax In-Reply-To: <576dcbc20707170624kb671fe4ia5ddac21af93eccd@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070716233030.D92541@10.0.0.1> <469CACEC.1000103@freebsd.org> <576dcbc20707170624kb671fe4ia5ddac21af93eccd@mail.gmail.com> Cc: current@freebsd.org Subject: Re: ULE/SCHED_SMP diff for 7.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2007 13:36:30 -0000 > > sched_ule: > > > > -j 3 buildkernel: 13:23 > > -j 4 buildkernel: 12:38 > > -j 5 buildkernel: 12:41 > > -j 6 buildkernel: 12:47 > > > > sched_4bsd: > > -j 3 buildkernel: 11:43 > > -j 4 buildkernel: 12:02 > > > > So sched_ule seems to handle more processes slightly better than 4bsd > > albeit it does it slower. ule's sweet spot is -j 4 and 4bsd is -j 3. > > > > 4bsd vs ULE > > -j 3 buildkernel: 11:43 vs -j 3 buildkernel: 13:23 > > -j 4 buildkernel: 12:02 vs -j 4 buildkernel: 12:38 > > > ULE is always slower? In my case yes. -- regards Claus When lenity and cruelty play for a kingdom, the gentlest gamester is the soonest winner. Shakespeare From owner-freebsd-current@FreeBSD.ORG Tue Jul 17 13:49:35 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6F5B416A409 for ; Tue, 17 Jul 2007 13:49:35 +0000 (UTC) (envelope-from lveax.m@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.229]) by mx1.freebsd.org (Postfix) with ESMTP id 2C17713C442 for ; Tue, 17 Jul 2007 13:49:35 +0000 (UTC) (envelope-from lveax.m@gmail.com) Received: by wx-out-0506.google.com with SMTP id i29so1251004wxd for ; Tue, 17 Jul 2007 06:49:34 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=SEMo51rDuBlaqu+xl8e/kODl7c3j9E856hyM/i8QGg5d4HT+yzgT3m0/C7jpyEOsWBzTGwVevU5yjmoFRbU4TKMBxSupcAXbqw3Kvf1i5hKXk6E7JEikxWbKckT4jO9geObBHDpsCxfK6n7P0u/6l5rkDos7jjiqmB1LvG2+da4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=cwFh3wfqJTqXkY61rdqHHsLMb6lgl0GM/rt9p8IKE4859h7+17MJpSdqG2GqcOW/gI6OC/BNgZW2YHy0RkCkdp8qVNMz1rYYmwfKkgrcGedCvOBxQ0RJIxn3iJtVdGk6RLAPF61PjOwj5OdJ4yiOgjz+zLQM0GwObD//A8k3vfk= Received: by 10.90.100.2 with SMTP id x2mr330643agb.1184678692666; Tue, 17 Jul 2007 06:24:52 -0700 (PDT) Received: by 10.90.86.8 with HTTP; Tue, 17 Jul 2007 06:24:52 -0700 (PDT) Message-ID: <576dcbc20707170624kb671fe4ia5ddac21af93eccd@mail.gmail.com> Date: Tue, 17 Jul 2007 21:24:52 +0800 From: lveax To: "Claus Guttesen" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070716233030.D92541@10.0.0.1> <469CACEC.1000103@freebsd.org> Cc: current@freebsd.org Subject: Re: ULE/SCHED_SMP diff for 7.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2007 13:49:35 -0000 > > sched_ule: > > -j 3 buildkernel: 13:23 > -j 4 buildkernel: 12:38 > -j 5 buildkernel: 12:41 > -j 6 buildkernel: 12:47 > > sched_4bsd: > -j 3 buildkernel: 11:43 > -j 4 buildkernel: 12:02 > > So sched_ule seems to handle more processes slightly better than 4bsd > albeit it does it slower. ule's sweet spot is -j 4 and 4bsd is -j 3. > scribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > 4bsd vs ULE -j 3 buildkernel: 11:43 vs -j 3 buildkernel: 13:23 -j 4 buildkernel: 12:02 vs -j 4 buildkernel: 12:38 ULE is always slower? From owner-freebsd-current@FreeBSD.ORG Tue Jul 17 13:30:43 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4BDCB16A402 for ; Tue, 17 Jul 2007 13:30:43 +0000 (UTC) (envelope-from gary.jennejohn@freenet.de) Received: from mout2.freenet.de (mout2.freenet.de [195.4.92.92]) by mx1.freebsd.org (Postfix) with ESMTP id 10B3C13C461 for ; Tue, 17 Jul 2007 13:30:43 +0000 (UTC) (envelope-from gary.jennejohn@freenet.de) Received: from [195.4.92.10] (helo=mx0.freenet.de) by mout2.freenet.de with esmtpa (Exim 4.68-dev) (envelope-from ) id 1IAmvt-00082G-Dd; Tue, 17 Jul 2007 15:17:41 +0200 Received: from ra894.r.pppool.de ([89.54.168.148]:60501 helo=peedub.jennejohn.org) by mx0.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.68-dev #10) id 1IAmvt-00067C-28; Tue, 17 Jul 2007 15:17:41 +0200 Date: Tue, 17 Jul 2007 15:17:39 +0200 From: Gary Jennejohn To: Jeff Roberson Message-Id: <20070717151739.c292d3fe.gary.jennejohn@freenet.de> In-Reply-To: <20070716233030.D92541@10.0.0.1> References: <20070716233030.D92541@10.0.0.1> Organization: DENX Softwre Engineering GmbH X-Mailer: Sylpheed 2.4.3 (GTK+ 2.10.13; amd64-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 17 Jul 2007 14:12:11 +0000 Cc: current@freebsd.org Subject: Re: ULE/SCHED_SMP diff for 7.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gary.jennejohn@freenet.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2007 13:30:43 -0000 On Mon, 16 Jul 2007 23:35:38 -0700 (PDT) Jeff Roberson wrote: > http://people.freebsd.org/~jeff/ule.diff > > This patch is scheduled for inclusion in 7.0. I would like anyone > who cares to run it to validate that it does not create any stability > or performance regression over the existing ULE. This patch replaces > ULE with SCHED_SMP, which will now no longer exist as a seperate fork > of ULE. > > Briefly, this is still a very suitable scheduler for uniprocessor > machines while providing stronger affinity and other performance > improvements for multiprocessor machines. > > Even "works for me!" type responses are welcome so I know roughly how > many people have tested before I commit this close to release. > This is definitely an improvement over the old ULE. With this: CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ and 64-bit FreeBSD-current I did ``make -j4 buildworld'' and saw that CPU0 isn't idle nearly as much as it was with the previous version of ULE. CPU1 was hardly ever idle, but CPU0 was ususally at 5-10%, whereas before it was more like 20%. BTW /usr/obj is on a ZFS share. Can't say whether that has any relevance. --- Gary Jennejohn From owner-freebsd-current@FreeBSD.ORG Tue Jul 17 15:09:18 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.ORG Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 66EDB16A401 for ; Tue, 17 Jul 2007 15:09:18 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with SMTP id 0684C13C428 for ; Tue, 17 Jul 2007 15:09:17 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 5912 invoked by uid 399); 17 Jul 2007 15:09:17 -0000 Received: from localhost (HELO lap.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTP; 17 Jul 2007 15:09:17 -0000 X-Originating-IP: 127.0.0.1 Message-ID: <469CDB9B.8080903@FreeBSD.org> Date: Tue, 17 Jul 2007 08:09:15 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.4 (X11/20070617) MIME-Version: 1.0 To: freebsd-current@FreeBSD.ORG, marck@rinet.ru, dougb@FreeBSD.ORG References: <200707171031.l6HAVmDZ088205@lurza.secnetix.de> In-Reply-To: <200707171031.l6HAVmDZ088205@lurza.secnetix.de> X-Enigmail-Version: 0.95.1 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Re: RFT: bin/106642: [patch] Allow excluding certain files from mergemaster (8) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2007 15:09:18 -0000 Oliver Fromme wrote: > On my notebook I have a script /etc/rc.d/net-detect that > pings several IP addresses in order to find out in which > network environment the notebook is used (at the office, > at home with wlan, at home with 100base-t, or no network > at all). The script then adjusts several symlinks based > on the network environment, i.e. several files in /etc > are changed, including rc.conf, ntp.conf, resolv.conf, > fstab (!), hosts and others. > > That script runs as the very first rc script, Ok, that's something that will probably need to stay a custom hack. I am saving your e-mail though, so in case I ever have time to pursue the multiple location thing I can bug you about it. :) FWIW, I have something similar but I run it as rc.local, which works fine for me, and doesn't require any special attention. If I'm at home, it: 1. mounts my nfs partitions 2. does a dynamic update for my home name server to tell it what it's host and IP address are If I'm away, it: 1. Sets its own hostname based on a lookup of the IP it's been assigned Then it always disables moused for the trackpad if there is a USB mouse attached. To handle the ntp.conf issue I have a dhclient-exit-hooks script that dynamically generates ntp.conf using some defaults, or the value of $new_ntp_servers if that is set. The resolv.conf is handled by dhcp as well, with a "prepend domain-name-servers 127.0.0.1;" being the only exciting thing there. hth, Doug -- This .signature sanitized for your protection From owner-freebsd-current@FreeBSD.ORG Tue Jul 17 15:33:01 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B4FDB16A402 for ; Tue, 17 Jul 2007 15:33:01 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with SMTP id 568FC13C461 for ; Tue, 17 Jul 2007 15:33:01 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 9285 invoked by uid 399); 17 Jul 2007 15:33:01 -0000 Received: from localhost (HELO lap.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTP; 17 Jul 2007 15:33:01 -0000 X-Originating-IP: 127.0.0.1 Message-ID: <469CE12B.5010506@FreeBSD.org> Date: Tue, 17 Jul 2007 08:32:59 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.4 (X11/20070617) MIME-Version: 1.0 To: Jeff Roberson References: <20070716233030.D92541@10.0.0.1> In-Reply-To: <20070716233030.D92541@10.0.0.1> X-Enigmail-Version: 0.95.1 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: ULE/SCHED_SMP diff for 7.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2007 15:33:01 -0000 Jeff Roberson wrote: > http://people.freebsd.org/~jeff/ule.diff > > This patch is scheduled for inclusion in 7.0. I would like anyone who > cares to run it to validate that it does not create any stability or > performance regression over the existing ULE. Not only does it "work for me," but it's a huge improvement in terms of interactivity for my mouse and keyboard. I have a C2D, and using either 4BSD or the old ULE I had gaps where mouse or keyboard activity would stall, then "catch up" all at once. Very annoying. So far I haven't had any of that, which is great. I haven't heavily stressed the system yet, but I did at least leave it running overnight, and 8 hours later it's still up, so that's something. :) Thanks Jeff, Doug -- This .signature sanitized for your protection From owner-freebsd-current@FreeBSD.ORG Tue Jul 17 17:23:08 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2032316A401 for ; Tue, 17 Jul 2007 17:23:08 +0000 (UTC) (envelope-from h.schmalzbauer@omnisec.de) Received: from host.omnisec.de (host.omnisec.de [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id 86FA113C4BB for ; Tue, 17 Jul 2007 17:23:07 +0000 (UTC) (envelope-from h.schmalzbauer@omnisec.de) Received: from [172.21.1.26] (akima-win.flintsbach.schmalzbauer.de [172.21.1.26]) (authenticated bits=0) by host.omnisec.de (8.13.8/8.13.8) with ESMTP id l6HHIU4D092400 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 17 Jul 2007 19:18:34 +0200 (CEST) (envelope-from h.schmalzbauer@omnisec.de) X-Authentication-Warning: smtp.dmz.omnisec.de: Host akima-win.flintsbach.schmalzbauer.de [172.21.1.26] claimed to be [172.21.1.26] Message-ID: <469CF9E5.2080200@omnisec.de> Date: Tue, 17 Jul 2007 19:18:29 +0200 From: Harald Schmalzbauer Organization: OmniSEC User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: current@freebsd.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: ich9 ahci support? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2007 17:23:08 -0000 Hello, does anybody know if there's a difference in accessing ich8 vs. ich9? Is it enough to add ID bits to support it? Thanks, -Harry From owner-freebsd-current@FreeBSD.ORG Tue Jul 17 17:58:27 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EDC0816A404 for ; Tue, 17 Jul 2007 17:58:27 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from mxout4.cac.washington.edu (mxout4.cac.washington.edu [140.142.33.19]) by mx1.freebsd.org (Postfix) with ESMTP id C86CA13C4AC for ; Tue, 17 Jul 2007 17:58:27 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from hymn01.u.washington.edu (hymn01.u.washington.edu [140.142.8.55]) by mxout4.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.06) with ESMTP id l6HHwRuh029715 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Jul 2007 10:58:27 -0700 Received: from localhost (localhost [127.0.0.1]) by hymn01.u.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l6HHwQxf027305; Tue, 17 Jul 2007 10:58:26 -0700 X-Auth-Received: from [192.55.52.10] by hymn01.u.washington.edu via HTTP; Tue, 17 Jul 2007 10:58:26 PDT Date: Tue, 17 Jul 2007 10:58:26 -0700 (PDT) From: youshi10@u.washington.edu To: Claus Guttesen In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-PMX-Version: 5.3.2.304607, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.7.17.103841 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='SUPERLONG_LINE 0.05, NO_REAL_NAME 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' Cc: current@freebsd.org Subject: Re: ULE/SCHED_SMP diff for 7.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2007 17:58:28 -0000 On Tue, 17 Jul 2007, Claus Guttesen wrote: >> > sched_ule: >> > >> > -j 3 buildkernel: 13:23 >> > -j 4 buildkernel: 12:38 >> > -j 5 buildkernel: 12:41 >> > -j 6 buildkernel: 12:47 >> > >> > sched_4bsd: >> > -j 3 buildkernel: 11:43 >> > -j 4 buildkernel: 12:02 >> > >> > So sched_ule seems to handle more processes slightly better than 4bsd >> > albeit it does it slower. ule's sweet spot is -j 4 and 4bsd is -j 3. >> > >> >> 4bsd vs ULE >> >> -j 3 buildkernel: 11:43 vs -j 3 buildkernel: 13:23 >> >> -j 4 buildkernel: 12:02 vs -j 4 buildkernel: 12:38 >> >> >> ULE is always slower? > > In my case yes. > > -- > regards > Claus > > When lenity and cruelty play for a kingdom, > the gentlest gamester is the soonest winner. > > Shakespeare Sorry to say, but last year's Xeons were very lackluster in terms of capability/performance, and there were rumors flying around that the Conroes (desktop chips) fared better than the 1st gen Woodcrest (?) chips :(.. That's changed in the later Xeons though =\.. -Garrett From owner-freebsd-current@FreeBSD.ORG Tue Jul 17 18:21:09 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 23E8B16A403; Tue, 17 Jul 2007 18:21:09 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from mxout7.cac.washington.edu (mxout7.cac.washington.edu [140.142.32.178]) by mx1.freebsd.org (Postfix) with ESMTP id 0381A13C467; Tue, 17 Jul 2007 18:21:08 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from hymn01.u.washington.edu (hymn01.u.washington.edu [140.142.8.55]) by mxout7.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.06) with ESMTP id l6HIL8Fq004537 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Jul 2007 11:21:08 -0700 Received: from localhost (localhost [127.0.0.1]) by hymn01.u.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l6HIL7Ce030430; Tue, 17 Jul 2007 11:21:07 -0700 X-Auth-Received: from [192.55.52.10] by hymn01.u.washington.edu via HTTP; Tue, 17 Jul 2007 11:21:07 PDT Date: Tue, 17 Jul 2007 11:21:07 -0700 (PDT) From: youshi10@u.washington.edu To: Milos Vyletel In-Reply-To: <20070716231345.GA43427@rulez.sk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-PMX-Version: 5.3.2.304607, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.7.17.105933 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='NO_REAL_NAME 0, __C230066_P5 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' Cc: hackers@freebsd.org, current@freebsd.org Subject: Re: Large amounts of memory access operations cause panic under CURRENT (was "Large gap between fwrite and write, and fread and read") X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Jul 2007 18:21:09 -0000 On Tue, 17 Jul 2007, Milos Vyletel wrote: >>> Go figure it'd cause panics for other people. >>> >>> I wasn't using zfs at all but it panicked anyhow once (my amd64 VM only, >>> not my i386 test server, surprisingly). I wish I'd gotten the panic but I >>> walked away to get a glass of water, and there wasn't a core dump because >>> the VM shut down completely instead of restarting. Heh. >>> >>> My virtual machine died around 90k on the first trial though. I'll be sure >>> to reduce the amount and see what happens, and I'll put nanosleeps or >>> usleeps between the read and write ops to see if that alleviates the race >>> condition seen, but I'll keep the problem code around for reference later >>> in case I've stimulated some sort of weird bug in FreeBSD, or otherwise. >>> >>> Both my VM and test server run almost no programs though other than samba >>> and rsync, so you'll probably see the panic faster / more frequently than I >>> will if you run a lot more programs resident in memory. >>> >>> Just curious, what scheduler are you using on CURRENT, what processor do >>> you have, and what are your memory specs? >>> >>> Thanks, >>> -Garrett >>> >> Hi Garrett, >> >> this is just my desktop where is running only Xorg, fluxbox, few aterms and >> firefox. But i can get the panic on console too, shortly after booting. I'm >> using SCHED_ULE. >> >> CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ (2205.01-MHz K8-class >> CPU) >> Origin = "AuthenticAMD" Id = 0x20f32 Stepping = 2 >> Features=0x178bfbff >> Features2=0x1 >> AMD Features=0xe2500800 >> AMD Features2=0x3 >> Cores per package: 2 >> usable memory = 3211718656 (3062 MB) >> avail memory = 3105570816 (2961 MB) >> >> For the record, it crashes few times before it hit 100k iterations, before i >> put >> debug printf in your code and increase MAX_ITERATIONS to 1m. And as far as I >> can tell, I had pretty much the same results as you've measured. >> >> mv > > Sorry for the noise, forgot to CC current@ This seems to be resolved with the latest CURRENT sources and ULE patches. -Garrett From owner-freebsd-current@FreeBSD.ORG Tue Jul 17 18:46:01 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 138BB16A401 for ; Tue, 17 Jul 2007 18:46:01 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from webaccess-cl.virtdom.com (webaccess-cl.virtdom.com [216.240.101.25]) by mx1.freebsd.org (Postfix) with ESMTP id B8BE213C49D for ; Tue, 17 Jul 2007 18:46:00 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from [192.168.1.101] (c-71-231-138-78.hsd1.or.comcast.net [71.231.138.78]) (authenticated bits=0) by webaccess-cl.virtdom.com (8.13.6/8.13.6) with ESMTP id l6HIjwqQ020294 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Tue, 17 Jul 2007 14:45:59 -0400 (EDT) (envelope-from jroberson@chesapeake.net) Date: Tue, 17 Jul 2007 11:49:05 -0700 (PDT) From: Jeff Roberson X-X-Sender: jroberson@10.0.0.1 To: Claus Guttesen In-Reply-To: Message-ID: <20070717114147.J92541@10.0.0.1> References: <20070716233030.D92541@10.0.0.1> <469CACEC.1000103@freebsd.org> <576dcbc20707170624kb671fe4ia5ddac21af93eccd@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: lveax , current@freebsd.org Subject: Re: ULE/SCHED_SMP diff for 7.0, buildkernel & thanks. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Jul 2007 18:46:01 -0000 With regards to buildkernel times; I do not want to sacrafice performance on other benchmarks to improve buildkernel. The problem is that 4BSD is as agressive as possible at scheduling work on idle cores. This behavior that helps one buildworld hurts on other, in my opinion, more important benchmarks. For example: http://people.freebsd.org/~jeff/sysbench.png ULE is 33% faster than SCHED_4BSD at this mysql test. This is a direct result of prefering to idle to make more efficient scheduling decisions. ULE is also faster at various networking benchmarks for similar reasons. I also believe that while the real time may be slower on buildworld the system and user time will be smaller by a degree greater than the delta in real time. This means that while you're building packages you have a little more cpu time leftover to handle other tasks. Furthermore, as the number of cores goes up things start to tip in favor of ULE although this is somewhat because it's harder for even 4BSD to keep them busy due to disk bandwidth. Thanks everyone for testing. Can someone confirm that they have tested with x86 rather than amd64? I will probably commit later today. Thanks, Jeff On Tue, 17 Jul 2007, Claus Guttesen wrote: >> > sched_ule: >> > >> > -j 3 buildkernel: 13:23 >> > -j 4 buildkernel: 12:38 >> > -j 5 buildkernel: 12:41 >> > -j 6 buildkernel: 12:47 >> > >> > sched_4bsd: >> > -j 3 buildkernel: 11:43 >> > -j 4 buildkernel: 12:02 >> > >> > So sched_ule seems to handle more processes slightly better than 4bsd >> > albeit it does it slower. ule's sweet spot is -j 4 and 4bsd is -j 3. >> > >> >> 4bsd vs ULE >> >> -j 3 buildkernel: 11:43 vs -j 3 buildkernel: 13:23 >> >> -j 4 buildkernel: 12:02 vs -j 4 buildkernel: 12:38 >> >> >> ULE is always slower? > > In my case yes. > > -- > regards > Claus > > When lenity and cruelty play for a kingdom, > the gentlest gamester is the soonest winner. > > Shakespeare > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Tue Jul 17 18:55:01 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E28F016A404 for ; Tue, 17 Jul 2007 18:55:01 +0000 (UTC) (envelope-from almarrie@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.244]) by mx1.freebsd.org (Postfix) with ESMTP id 99C9213C4C1 for ; Tue, 17 Jul 2007 18:55:01 +0000 (UTC) (envelope-from almarrie@gmail.com) Received: by an-out-0708.google.com with SMTP id c14so382385anc for ; Tue, 17 Jul 2007 11:55:01 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=rrG0L7+cHsihc8JRnVbAV2YRvg8JwDiM1OG/ntunSI4RQAtnq8SDByR3huiRgERJjAunqJ1RNwN3xhSEkK9bsq1qmGlnetNHPvS4l/j6NIedvJREVRkVP73Zw0bCuvdHvZVyLB8pOJPkIz/xz5jJ5/XkEH1XH+GF025hq3XifN8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ZtIhoSjDzEiMMpm0BfqgVH6TtKhF/QcXZYKwdCq+5qZJ7GnGAET2Hz8F1gAL4Gxl+VX2L6PW8Jc/ExJwS64ZWVseq3fgWALvQexEtNDXLnT+o7tD4QbeGbBSBOvH1yEClxPta2ZtXga4KPIikchiIFjlOUfLk+cQFzSG3fN7Sng= Received: by 10.100.152.9 with SMTP id z9mr392940and.1184698500919; Tue, 17 Jul 2007 11:55:00 -0700 (PDT) Received: by 10.100.9.14 with HTTP; Tue, 17 Jul 2007 11:55:00 -0700 (PDT) Message-ID: <499c70c0707171155w318ece06j88f31bc19de8776b@mail.gmail.com> Date: Tue, 17 Jul 2007 21:55:00 +0300 From: "Abdullah Ibn Hamad Al-Marri" To: "Jeff Roberson" In-Reply-To: <20070717114147.J92541@10.0.0.1> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070716233030.D92541@10.0.0.1> <469CACEC.1000103@freebsd.org> <576dcbc20707170624kb671fe4ia5ddac21af93eccd@mail.gmail.com> <20070717114147.J92541@10.0.0.1> Cc: lveax , current@freebsd.org, Claus Guttesen Subject: Re: ULE/SCHED_SMP diff for 7.0, buildkernel & thanks. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Jul 2007 18:55:02 -0000 On 7/17/07, Jeff Roberson wrote: > With regards to buildkernel times; I do not want to sacrafice performance > on other benchmarks to improve buildkernel. The problem is that 4BSD is > as agressive as possible at scheduling work on idle cores. This behavior > that helps one buildworld hurts on other, in my opinion, more important > benchmarks. > > For example: http://people.freebsd.org/~jeff/sysbench.png > > ULE is 33% faster than SCHED_4BSD at this mysql test. This is a direct > result of prefering to idle to make more efficient scheduling decisions. > ULE is also faster at various networking benchmarks for similar reasons. > > I also believe that while the real time may be slower on buildworld the > system and user time will be smaller by a degree greater than the delta in > real time. This means that while you're building packages you have a > little more cpu time leftover to handle other tasks. Furthermore, as the > number of cores goes up things start to tip in favor of ULE although this > is somewhat because it's harder for even 4BSD to keep them busy due to > disk bandwidth. > > Thanks everyone for testing. Can someone confirm that they have tested > with x86 rather than amd64? I will probably commit later today. > > Thanks, > Jeff Did you compare it to latest Linux fixes? is FreeBSD + ULE + MySQL still faster than linux? -- Regards, -Abdullah Ibn Hamad Al-Marri Arab Portal http://www.WeArab.Net/ From owner-freebsd-current@FreeBSD.ORG Tue Jul 17 18:57:37 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D048E16A409 for ; Tue, 17 Jul 2007 18:57:37 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from mxout5.cac.washington.edu (mxout5.cac.washington.edu [140.142.32.135]) by mx1.freebsd.org (Postfix) with ESMTP id AFC8413C4A8 for ; Tue, 17 Jul 2007 18:57:37 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from hymn01.u.washington.edu (hymn01.u.washington.edu [140.142.8.55]) by mxout5.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.06) with ESMTP id l6HIvUWB029592 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Jul 2007 11:57:30 -0700 Received: from localhost (localhost [127.0.0.1]) by hymn01.u.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l6HIvUVf023132; Tue, 17 Jul 2007 11:57:30 -0700 X-Auth-Received: from [192.55.52.10] by hymn01.u.washington.edu via HTTP; Tue, 17 Jul 2007 11:57:30 PDT Date: Tue, 17 Jul 2007 11:57:30 -0700 (PDT) From: youshi10@u.washington.edu To: Jeff Roberson In-Reply-To: <20070717114147.J92541@10.0.0.1> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-PMX-Version: 5.3.2.304607, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.7.17.113833 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='NO_REAL_NAME 0, __C230066_P2 0, __CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' Cc: lveax , current@freebsd.org, Claus Guttesen Subject: Re: ULE/SCHED_SMP diff for 7.0, buildkernel & thanks. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Jul 2007 18:57:37 -0000 On Tue, 17 Jul 2007, Jeff Roberson wrote: > With regards to buildkernel times; I do not want to sacrafice performance on > other benchmarks to improve buildkernel. The problem is that 4BSD is as > agressive as possible at scheduling work on idle cores. This behavior that > helps one buildworld hurts on other, in my opinion, more important benchmarks. > > For example: http://people.freebsd.org/~jeff/sysbench.png > > ULE is 33% faster than SCHED_4BSD at this mysql test. This is a direct result > of prefering to idle to make more efficient scheduling decisions. ULE is also > faster at various networking benchmarks for similar reasons. > > I also believe that while the real time may be slower on buildworld the system > and user time will be smaller by a degree greater than the delta in real time. > This means that while you're building packages you have a little more cpu time > leftover to handle other tasks. Furthermore, as the number of cores goes up > things start to tip in favor of ULE although this is somewhat because it's > harder for even 4BSD to keep them busy due to disk bandwidth. > > Thanks everyone for testing. Can someone confirm that they have tested with > x86 rather than amd64? I will probably commit later today. > > Thanks, > Jeff > > On Tue, 17 Jul 2007, Claus Guttesen wrote: > >>> > sched_ule: >>> > >>> > -j 3 buildkernel: 13:23 >>> > -j 4 buildkernel: 12:38 >>> > -j 5 buildkernel: 12:41 >>> > -j 6 buildkernel: 12:47 >>> > >>> > sched_4bsd: >>> > -j 3 buildkernel: 11:43 >>> > -j 4 buildkernel: 12:02 >>> > >>> > So sched_ule seems to handle more processes slightly better than 4bsd >>> > albeit it does it slower. ule's sweet spot is -j 4 and 4bsd is -j 3. >>> > >>> >>> 4bsd vs ULE >>> >>> -j 3 buildkernel: 11:43 vs -j 3 buildkernel: 13:23 >>> >>> -j 4 buildkernel: 12:02 vs -j 4 buildkernel: 12:38 >>> >>> >>> ULE is always slower? >> >> In my case yes. >> >> -- >> regards >> Claus >> >> When lenity and cruelty play for a kingdom, >> the gentlest gamester is the soonest winner. >> >> Shakespeare I need to sync my kernel sources on my i386 desktop, but yeah I'll give it a round tonight. -Garrett From owner-freebsd-current@FreeBSD.ORG Tue Jul 17 19:00:38 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D421A16A401 for ; Tue, 17 Jul 2007 19:00:38 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from ik-out-1112.google.com (ik-out-1112.google.com [66.249.90.176]) by mx1.freebsd.org (Postfix) with ESMTP id 60DA213C48E for ; Tue, 17 Jul 2007 19:00:38 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by ik-out-1112.google.com with SMTP id c21so1054689ika for ; Tue, 17 Jul 2007 12:00:37 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=CzASGtIag82jNKnl0Jt2drpfFwpxbvZBS3Ow3j13k8/uXOpxicEexR1UllVsRL1mis+L4rMxF5CYilmsB4t6O13c2VSEdExgGbzGSAJSTaOm+ZlTmvPzeliYaH3p9mCec9qzv20DdNvqoOc22yujTyXKppiBQctmiYMJsAt3qSw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=KfTmY29E1cYC5dl4LOXD70PVmCRNyKiX6cXdH5JhaCDHJpSY7SQkCwURifO69MgGMO0pjfXNcIkaI+ea1VxhFbT+qDOSpPAepmcws9Hgmoqn8zcAsTIomSWUkDc43SsKvJQ4jR2T6zeFr7x5E7VUQ39EKBJ3Ppp5JTgIH+/YmWc= Received: by 10.78.150.7 with SMTP id x7mr210537hud.1184698837009; Tue, 17 Jul 2007 12:00:37 -0700 (PDT) Received: by 10.78.120.9 with HTTP; Tue, 17 Jul 2007 12:00:36 -0700 (PDT) Message-ID: <3bbf2fe10707171200t4f84084bj8a206268215a9570@mail.gmail.com> Date: Tue, 17 Jul 2007 21:00:36 +0200 From: "Attilio Rao" Sender: asmrookie@gmail.com To: "Abdullah Ibn Hamad Al-Marri" In-Reply-To: <499c70c0707171155w318ece06j88f31bc19de8776b@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070716233030.D92541@10.0.0.1> <469CACEC.1000103@freebsd.org> <576dcbc20707170624kb671fe4ia5ddac21af93eccd@mail.gmail.com> <20070717114147.J92541@10.0.0.1> <499c70c0707171155w318ece06j88f31bc19de8776b@mail.gmail.com> X-Google-Sender-Auth: d1932c9af8d03371 Cc: Jeff Roberson , Claus Guttesen , current@freebsd.org, lveax Subject: Re: ULE/SCHED_SMP diff for 7.0, buildkernel & thanks. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Jul 2007 19:00:38 -0000 2007/7/17, Abdullah Ibn Hamad Al-Marri : > On 7/17/07, Jeff Roberson wrote: > > With regards to buildkernel times; I do not want to sacrafice performance > > on other benchmarks to improve buildkernel. The problem is that 4BSD is > > as agressive as possible at scheduling work on idle cores. This behavior > > that helps one buildworld hurts on other, in my opinion, more important > > benchmarks. > > > > For example: http://people.freebsd.org/~jeff/sysbench.png > > > > ULE is 33% faster than SCHED_4BSD at this mysql test. This is a direct > > result of prefering to idle to make more efficient scheduling decisions. > > ULE is also faster at various networking benchmarks for similar reasons. > > > > I also believe that while the real time may be slower on buildworld the > > system and user time will be smaller by a degree greater than the delta in > > real time. This means that while you're building packages you have a > > little more cpu time leftover to handle other tasks. Furthermore, as the > > number of cores goes up things start to tip in favor of ULE although this > > is somewhat because it's harder for even 4BSD to keep them busy due to > > disk bandwidth. > > > > Thanks everyone for testing. Can someone confirm that they have tested > > with x86 rather than amd64? I will probably commit later today. > > > > Thanks, > > Jeff > > Did you compare it to latest Linux fixes? is FreeBSD + ULE + MySQL > still faster than linux? Just look at the link Jeff posted, it seems very well explaining :). Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Tue Jul 17 19:04:41 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D65ED16A408 for ; Tue, 17 Jul 2007 19:04:41 +0000 (UTC) (envelope-from almarrie@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.246]) by mx1.freebsd.org (Postfix) with ESMTP id 881EA13C4B2 for ; Tue, 17 Jul 2007 19:04:41 +0000 (UTC) (envelope-from almarrie@gmail.com) Received: by an-out-0708.google.com with SMTP id c14so383064anc for ; Tue, 17 Jul 2007 12:04:40 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=QBxpfchF1tlYJkw4YaNMKjHwQ6mXq0NDtCwxX1c/Lvjw7J+Oxsx3M4Ro1eHOx1ywF97kyYY1lFsPIv9rDKHhfZguLBLuJ7Idcz4yli83+THKpbSGRI6Ac1BsqkbeVifHbt/o2vpf+KkNE3kzT+T4gUQtwX6LIqTE+x90rnZvRzI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=bLJK3o4ukMDYIKDVzjolOnrjHl96ym8H38Nwiogi+94JqP5tRF4AdOiUEETzUSSZHtOJbN81EWsPBSYEJm+jxAHu6mqDrvmQUmVnnCm5MkDqDEggVJ2pzhAiHUSuKYWA/nDVT6u7Za9UbJWaxdf+XVONRaf2QMSBdByHszFebag= Received: by 10.100.8.18 with SMTP id 18mr392186anh.1184699080645; Tue, 17 Jul 2007 12:04:40 -0700 (PDT) Received: by 10.100.9.14 with HTTP; Tue, 17 Jul 2007 12:04:40 -0700 (PDT) Message-ID: <499c70c0707171204o5140af3bn3e8c5818bac93055@mail.gmail.com> Date: Tue, 17 Jul 2007 22:04:40 +0300 From: "Abdullah Ibn Hamad Al-Marri" To: "Attilio Rao" In-Reply-To: <3bbf2fe10707171200t4f84084bj8a206268215a9570@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070716233030.D92541@10.0.0.1> <469CACEC.1000103@freebsd.org> <576dcbc20707170624kb671fe4ia5ddac21af93eccd@mail.gmail.com> <20070717114147.J92541@10.0.0.1> <499c70c0707171155w318ece06j88f31bc19de8776b@mail.gmail.com> <3bbf2fe10707171200t4f84084bj8a206268215a9570@mail.gmail.com> Cc: Jeff Roberson , Claus Guttesen , current@freebsd.org, lveax Subject: Re: ULE/SCHED_SMP diff for 7.0, buildkernel & thanks. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Jul 2007 19:04:41 -0000 On 7/17/07, Attilio Rao wrote: > 2007/7/17, Abdullah Ibn Hamad Al-Marri : > > On 7/17/07, Jeff Roberson wrote: > > > With regards to buildkernel times; I do not want to sacrafice performance > > > on other benchmarks to improve buildkernel. The problem is that 4BSD is > > > as agressive as possible at scheduling work on idle cores. This behavior > > > that helps one buildworld hurts on other, in my opinion, more important > > > benchmarks. > > > > > > For example: http://people.freebsd.org/~jeff/sysbench.png > > > > > > ULE is 33% faster than SCHED_4BSD at this mysql test. This is a direct > > > result of prefering to idle to make more efficient scheduling decisions. > > > ULE is also faster at various networking benchmarks for similar reasons. > > > > > > I also believe that while the real time may be slower on buildworld the > > > system and user time will be smaller by a degree greater than the delta in > > > real time. This means that while you're building packages you have a > > > little more cpu time leftover to handle other tasks. Furthermore, as the > > > number of cores goes up things start to tip in favor of ULE although this > > > is somewhat because it's harder for even 4BSD to keep them busy due to > > > disk bandwidth. > > > > > > Thanks everyone for testing. Can someone confirm that they have tested > > > with x86 rather than amd64? I will probably commit later today. > > > > > > Thanks, > > > Jeff > > > > Did you compare it to latest Linux fixes? is FreeBSD + ULE + MySQL > > still faster than linux? > > Just look at the link Jeff posted, it seems very well explaining :). > > Attilio heh I love it! When I checked last time, Linux took it over, I'm glad to see FreeBSD is the leader now again! -- Regards, -Abdullah Ibn Hamad Al-Marri Arab Portal http://www.WeArab.Net/ From owner-freebsd-current@FreeBSD.ORG Tue Jul 17 19:21:40 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EF88216A402 for ; Tue, 17 Jul 2007 19:21:40 +0000 (UTC) (envelope-from datahead4@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.236]) by mx1.freebsd.org (Postfix) with ESMTP id ABB2913C4A6 for ; Tue, 17 Jul 2007 19:21:40 +0000 (UTC) (envelope-from datahead4@gmail.com) Received: by nz-out-0506.google.com with SMTP id l8so1129452nzf for ; Tue, 17 Jul 2007 12:21:40 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=SjhhOL3xkpstmXWaclxndaSuSZxVZFqt1xv+sc6MPDjwKtvVdsFBner3uDEZxFJGL1TtZN9ZgptzaubBwesRo2Fqf8r0Vezj1gC2sLEMOyoH65LDdebCH8oVnU3r+D+Ge7tHeE5bCc7OBU14yfA3nIuQSDGsscuT5zWMXhhnBJo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=N+P2Zix6S7i990INZsjjzOxY3TUg7ZAIa02inWmoY8SfDmIMj/1MiWEuBUaz0HnwEFFigm/t/yM+/OoVGLQPx8p++s/dAbgo0NOWhDLB9jwzTTxvH3V7kIt9j9niu2SH8Mjcsh83kpfd9efOraA+U78bWRb3bOj4HWDHf7Yyvlk= Received: by 10.115.77.1 with SMTP id e1mr685018wal.1184698396722; Tue, 17 Jul 2007 11:53:16 -0700 (PDT) Received: by 10.114.205.5 with HTTP; Tue, 17 Jul 2007 11:53:16 -0700 (PDT) Message-ID: Date: Tue, 17 Jul 2007 13:53:16 -0500 From: Matt To: "Jeff Roberson" In-Reply-To: <20070717114147.J92541@10.0.0.1> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070716233030.D92541@10.0.0.1> <469CACEC.1000103@freebsd.org> <576dcbc20707170624kb671fe4ia5ddac21af93eccd@mail.gmail.com> <20070717114147.J92541@10.0.0.1> Cc: lveax , current@freebsd.org, Claus Guttesen Subject: Re: ULE/SCHED_SMP diff for 7.0, buildkernel & thanks. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Jul 2007 19:21:41 -0000 On 7/17/07, Jeff Roberson wrote: > With regards to buildkernel times; I do not want to sacrafice performance > on other benchmarks to improve buildkernel. The problem is that 4BSD is > as agressive as possible at scheduling work on idle cores. This behavior > that helps one buildworld hurts on other, in my opinion, more important > benchmarks. > > For example: http://people.freebsd.org/~jeff/sysbench.png > > ULE is 33% faster than SCHED_4BSD at this mysql test. This is a direct > result of prefering to idle to make more efficient scheduling decisions. > ULE is also faster at various networking benchmarks for similar reasons. > > I also believe that while the real time may be slower on buildworld the > system and user time will be smaller by a degree greater than the delta in > real time. This means that while you're building packages you have a > little more cpu time leftover to handle other tasks. Furthermore, as the > number of cores goes up things start to tip in favor of ULE although this > is somewhat because it's harder for even 4BSD to keep them busy due to > disk bandwidth. > > Thanks everyone for testing. Can someone confirm that they have tested > with x86 rather than amd64? I will probably commit later today. > > Thanks, > Jeff > > On Tue, 17 Jul 2007, Claus Guttesen wrote: > > >> > sched_ule: > >> > > >> > -j 3 buildkernel: 13:23 > >> > -j 4 buildkernel: 12:38 > >> > -j 5 buildkernel: 12:41 > >> > -j 6 buildkernel: 12:47 > >> > > >> > sched_4bsd: > >> > -j 3 buildkernel: 11:43 > >> > -j 4 buildkernel: 12:02 > >> > > >> > So sched_ule seems to handle more processes slightly better than 4bsd > >> > albeit it does it slower. ule's sweet spot is -j 4 and 4bsd is -j 3. > >> > > >> > >> 4bsd vs ULE > >> > >> -j 3 buildkernel: 11:43 vs -j 3 buildkernel: 13:23 > >> > >> -j 4 buildkernel: 12:02 vs -j 4 buildkernel: 12:38 > >> > >> > >> ULE is always slower? > > > > In my case yes. > > > > -- > > regards > > Claus > > > > When lenity and cruelty play for a kingdom, > > the gentlest gamester is the soonest winner. > > > > Shakespeare > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > Patch applied to my i386 CURRENT system with sources checked out today. Everything compiled cleanly and system has been running well since then. From owner-freebsd-current@FreeBSD.ORG Tue Jul 17 19:28:29 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6A1C016A404 for ; Tue, 17 Jul 2007 19:28:29 +0000 (UTC) (envelope-from caelian@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.169]) by mx1.freebsd.org (Postfix) with ESMTP id F171B13C471 for ; Tue, 17 Jul 2007 19:28:28 +0000 (UTC) (envelope-from caelian@gmail.com) Received: by ug-out-1314.google.com with SMTP id o4so228876uge for ; Tue, 17 Jul 2007 12:28:27 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:subject:from:to:cc:in-reply-to:references:content-type:date:message-id:mime-version:x-mailer:content-transfer-encoding; b=mgxLu0iGumbohmuiEoJj1OyIsvW9NDVNUgtKyDX8IGYcLOlnm+5jWqTANUxouzClef1Ru8SSZrwQVy0xG+4h2GDDOBZvGtnhwVOhsDM7gjX3qeAG4oFeiOs1hVwv+PYJEMDVP2Ckdk5cFrbKVVIU5EYUy/CJGlm8mcSLI/X83cc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:subject:from:to:cc:in-reply-to:references:content-type:date:message-id:mime-version:x-mailer:content-transfer-encoding; b=IE3i/ufrxKStN37budo+1G5kEGNFpteEvfGc+KEkdfx68LgYfkCSKatIE2EzcyKloKyRZWfPpi5XRVatg3a5s+Ov21bg2imhiBQTmg7NnyMCbxkysEjcgjUVAXrmn8lGkQ2qet+ZVyERIrqt+oOGNNFFqVGDdNv4n9R/9OJ0kfQ= Received: by 10.86.57.9 with SMTP id f9mr534935fga.1184700507464; Tue, 17 Jul 2007 12:28:27 -0700 (PDT) Received: from ?192.168.0.23? ( [79.204.106.93]) by mx.google.com with ESMTPS id e32sm44918fke.2007.07.17.12.28.26 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 17 Jul 2007 12:28:27 -0700 (PDT) From: Pascal Hofstee To: Robert Watson In-Reply-To: <20070717131518.G1177@fledge.watson.org> References: <20070717131518.G1177@fledge.watson.org> Content-Type: text/plain Date: Tue, 17 Jul 2007 21:28:26 +0200 Message-Id: <1184700506.1086.5.camel@worf> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: arch@FreeBSD.org, current@FreeBSD.org Subject: Re: Reminder: NET_NEEDS_GIANT, debug.mpsafenet going away in 7.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2007 19:28:29 -0000 On Tue, 2007-07-17 at 13:21 +0100, Robert Watson wrote: > Dear all: > > This is a reminder e-mail that, in the very near future, Giant compatibility > shims for network protocols will be removed. These shimmed allowed Giant to > be re-enabeld over the network stack as a result of linking in a service that > required Giant (now all removed), or by setting the debug.mpsafenet variable > to 1. This means that the following will no longer be present: > > debug.mpsafenet sysctl > debug_mpsafenet global variable > NET_NEEDS_GIANT() > NET_LOCK_GIANT(), NET_UNLOCK_GIANT(), NET_ASSERT_GIANT() > NET_CALLOUT_MPSAFE > > All instances of NET_{LOCK,UNLOCK,ASSERT}_GIANT() will be removed as they will > no be no-ops. Ehrm ... i am not 100% sure here but what will this mean for those of us running qemu on 7.x systems ... if i recall correctly qemu requires aio for at least DMA which on 6.x at least still issues below warning when kldloaded: WARNING: Network stack Giant-free, but aio requires Giant. Consider adding 'options NET_WITH_GIANT' or setting debug.mpsafenet=0 Does this removal of debug.mpsafenet mean that aio on CURRENT is now GIANT free .. or does this mean that we'll be seeing problems with qemu on CURRENT ? -- Pascal Hofstee From owner-freebsd-current@FreeBSD.ORG Tue Jul 17 19:30:17 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 339B316A401 for ; Tue, 17 Jul 2007 19:30:17 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with SMTP id CB10513C4C7 for ; Tue, 17 Jul 2007 19:30:16 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 365 invoked by uid 399); 17 Jul 2007 19:30:16 -0000 Received: from localhost (HELO lap.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTP; 17 Jul 2007 19:30:16 -0000 X-Originating-IP: 127.0.0.1 Message-ID: <469D18C6.60309@FreeBSD.org> Date: Tue, 17 Jul 2007 12:30:14 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.4 (X11/20070617) MIME-Version: 1.0 To: Jeff Roberson References: <20070716233030.D92541@10.0.0.1> <469CE12B.5010506@FreeBSD.org> In-Reply-To: <469CE12B.5010506@FreeBSD.org> X-Enigmail-Version: 0.95.1 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: ULE/SCHED_SMP diff for 7.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2007 19:30:17 -0000 Doug Barton wrote: > Jeff Roberson wrote: >> http://people.freebsd.org/~jeff/ule.diff >> >> This patch is scheduled for inclusion in 7.0. I would like anyone who >> cares to run it to validate that it does not create any stability or >> performance regression over the existing ULE. > > Not only does it "work for me," but it's a huge improvement in terms > of interactivity for my mouse and keyboard. I have a C2D, and using > either 4BSD or the old ULE I had gaps where mouse or keyboard activity > would stall, then "catch up" all at once. Very annoying. So far I > haven't had any of that, which is great. > > I haven't heavily stressed the system yet, but I did at least leave it > running overnight, and 8 hours later it's still up, so that's > something. :) Ok, I ran a -j3 buildworld while I was working on other stuff, and everything stayed nice and responsive. No lag for mouse or keyboard, and the buildworld finished in a timely manner. And sorry I forgot to mention above that I'm running my C2D in i386 mode. hth, Doug -- This .signature sanitized for your protection From owner-freebsd-current@FreeBSD.ORG Tue Jul 17 19:41:57 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7117E16A402 for ; Tue, 17 Jul 2007 19:41:57 +0000 (UTC) (envelope-from morganw@chemikals.org) Received: from smtp2.sccoast.net (smtp2.sccoast.net [66.153.203.174]) by mx1.freebsd.org (Postfix) with ESMTP id 4807F13C4BF for ; Tue, 17 Jul 2007 19:41:57 +0000 (UTC) (envelope-from morganw@chemikals.org) Received: from 61.135-pool-xdsl-mi.sccoast.net ([66.153.135.61]:56793 helo=volatile.chemikals.org) by smtp2.sccoast.net with esmtp (Exim 4.60) (envelope-from ) id 1IAsgz-0005I5-Ol; Tue, 17 Jul 2007 15:26:41 -0400 Received: from localhost (morganw@localhost [127.0.0.1]) by volatile.chemikals.org (8.13.8/8.13.8) with ESMTP id l6HJR1Lb021545; Tue, 17 Jul 2007 15:27:01 -0400 (EDT) (envelope-from morganw@chemikals.org) Date: Tue, 17 Jul 2007 15:26:59 -0400 (EDT) From: Wes Morgan To: Jeff Roberson In-Reply-To: <20070717114147.J92541@10.0.0.1> Message-ID: References: <20070716233030.D92541@10.0.0.1> <469CACEC.1000103@freebsd.org> <576dcbc20707170624kb671fe4ia5ddac21af93eccd@mail.gmail.com> <20070717114147.J92541@10.0.0.1> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=us-ascii; format=flowed Cc: current@freebsd.org Subject: Re: ULE/SCHED_SMP diff for 7.0, buildkernel & thanks. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Jul 2007 19:41:57 -0000 On Tue, 17 Jul 2007, Jeff Roberson wrote: > With regards to buildkernel times; I do not want to sacrafice performance on > other benchmarks to improve buildkernel. The problem is that 4BSD is as > agressive as possible at scheduling work on idle cores. This behavior that > helps one buildworld hurts on other, in my opinion, more important > benchmarks. > > For example: http://people.freebsd.org/~jeff/sysbench.png > > ULE is 33% faster than SCHED_4BSD at this mysql test. This is a direct > result of prefering to idle to make more efficient scheduling decisions. ULE > is also faster at various networking benchmarks for similar reasons. > > I also believe that while the real time may be slower on buildworld the > system and user time will be smaller by a degree greater than the delta in > real time. This means that while you're building packages you have a little > more cpu time leftover to handle other tasks. Furthermore, as the number of > cores goes up things start to tip in favor of ULE although this is somewhat > because it's harder for even 4BSD to keep them busy due to disk bandwidth. > > Thanks everyone for testing. Can someone confirm that they have tested with > x86 rather than amd64? I will probably commit later today. Running fine on my core duo x86 so far. Interactivity seems good with a buildworld -j4 going on. From owner-freebsd-current@FreeBSD.ORG Tue Jul 17 19:41:59 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BF15B16A409; Tue, 17 Jul 2007 19:41:59 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from mxout2.cac.washington.edu (mxout2.cac.washington.edu [140.142.33.4]) by mx1.freebsd.org (Postfix) with ESMTP id 9BD8A13C474; Tue, 17 Jul 2007 19:41:59 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from hymn01.u.washington.edu (hymn01.u.washington.edu [140.142.8.55]) by mxout2.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.06) with ESMTP id l6HJfx9I004981 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Jul 2007 12:41:59 -0700 Received: from localhost (localhost [127.0.0.1]) by hymn01.u.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l6HJfw8J022672; Tue, 17 Jul 2007 12:41:58 -0700 X-Auth-Received: from [192.55.52.10] by hymn01.u.washington.edu via HTTP; Tue, 17 Jul 2007 12:41:58 PDT Date: Tue, 17 Jul 2007 12:41:58 -0700 (PDT) From: youshi10@u.washington.edu To: Attilio Rao In-Reply-To: <3bbf2fe10707171200t4f84084bj8a206268215a9570@mail.gmail.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-PMX-Version: 5.3.2.304607, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.7.17.122433 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='NO_REAL_NAME 0, __C230066_P2 0, __CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' Cc: current@freebsd.org Subject: Re: ULE/SCHED_SMP diff for 7.0, buildkernel & thanks. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Jul 2007 19:41:59 -0000 On Tue, 17 Jul 2007, Attilio Rao wrote: > 2007/7/17, Abdullah Ibn Hamad Al-Marri : >> On 7/17/07, Jeff Roberson wrote: >> > With regards to buildkernel times; I do not want to sacrafice performance >> > on other benchmarks to improve buildkernel. The problem is that 4BSD is >> > as agressive as possible at scheduling work on idle cores. This behavior >> > that helps one buildworld hurts on other, in my opinion, more important >> > benchmarks. >> > >> > For example: http://people.freebsd.org/~jeff/sysbench.png >> > >> > ULE is 33% faster than SCHED_4BSD at this mysql test. This is a direct >> > result of prefering to idle to make more efficient scheduling decisions. >> > ULE is also faster at various networking benchmarks for similar reasons. >> > >> > I also believe that while the real time may be slower on buildworld the >> > system and user time will be smaller by a degree greater than the delta in >> > real time. This means that while you're building packages you have a >> > little more cpu time leftover to handle other tasks. Furthermore, as the >> > number of cores goes up things start to tip in favor of ULE although this >> > is somewhat because it's harder for even 4BSD to keep them busy due to >> > disk bandwidth. >> > >> > Thanks everyone for testing. Can someone confirm that they have tested >> > with x86 rather than amd64? I will probably commit later today. >> > >> > Thanks, >> > Jeff >> >> Did you compare it to latest Linux fixes? is FreeBSD + ULE + MySQL >> still faster than linux? > > Just look at the link Jeff posted, it seems very well explaining :). > > Attilio > > > -- > Peace can only be achieved by understanding - A. Einstein Unfortunately those results are still based on 2.6.20, not 2.6.22 (2 minor patch revision difference). I assume that that's for a vanilla Linux kernel? -Garrett From owner-freebsd-current@FreeBSD.ORG Tue Jul 17 19:45:40 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6121816A400 for ; Tue, 17 Jul 2007 19:45:40 +0000 (UTC) (envelope-from caelian@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.174]) by mx1.freebsd.org (Postfix) with ESMTP id E181913C4B7 for ; Tue, 17 Jul 2007 19:45:39 +0000 (UTC) (envelope-from caelian@gmail.com) Received: by ug-out-1314.google.com with SMTP id o4so230540uge for ; Tue, 17 Jul 2007 12:45:38 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:subject:from:to:cc:in-reply-to:references:content-type:date:message-id:mime-version:x-mailer:content-transfer-encoding; b=gldOzDd9IUIiaLk4Wp06CWHUK1l+NEZK29bHJh/ylMZN27HGhJHwSvzFmWs+plvZ/8kPwMVknjU6uXyEr/T9b30Q77moueVbb7N5yNQaPaXsirkN/y6+TKUcJl8wHpA+7GRCJofRe8eUyxEoQHbuEzCNUGeoJRHP+JJq7IsH8So= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:subject:from:to:cc:in-reply-to:references:content-type:date:message-id:mime-version:x-mailer:content-transfer-encoding; b=obtJgVyl1xucKcNgTfvOBS1UzkAIo4c2YSxEOx2bJ3gps9Q16PcjZhQlOQcA0DreF3+f+z5NUI/bb/leAAjwEMRPkbQSSwNXDNPIMyug1lbzwHr4AWx47BiDodixv9ZS4X1MXosrCkfqCDwPwOPWLdRj+zpuR0G8Vn8BZz7igY0= Received: by 10.86.49.13 with SMTP id w13mr544758fgw.1184701538507; Tue, 17 Jul 2007 12:45:38 -0700 (PDT) Received: from ?192.168.0.23? ( [79.204.106.93]) by mx.google.com with ESMTPS id b17sm78312fka.2007.07.17.12.45.36 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 17 Jul 2007 12:45:37 -0700 (PDT) From: Pascal Hofstee To: Jeff Roberson In-Reply-To: <20070717114147.J92541@10.0.0.1> References: <20070716233030.D92541@10.0.0.1> <469CACEC.1000103@freebsd.org> <576dcbc20707170624kb671fe4ia5ddac21af93eccd@mail.gmail.com> <20070717114147.J92541@10.0.0.1> Content-Type: text/plain Date: Tue, 17 Jul 2007 21:45:36 +0200 Message-Id: <1184701536.1078.0.camel@worf> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: lveax , current@freebsd.org, Claus Guttesen Subject: Re: ULE/SCHED_SMP diff for 7.0, buildkernel & thanks. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Jul 2007 19:45:40 -0000 On Tue, 2007-07-17 at 11:49 -0700, Jeff Roberson wrote: > Thanks everyone for testing. Can someone confirm that they have tested > with x86 rather than amd64? I will probably commit later today. Running smoothly so far on an AMD Athlon64 3800+ (UP system running FreeSBD/i386) -- Pascal Hofstee From owner-freebsd-current@FreeBSD.ORG Tue Jul 17 19:59:48 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 53DD416A404; Tue, 17 Jul 2007 19:59:48 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from webaccess-cl.virtdom.com (webaccess-cl.virtdom.com [216.240.101.25]) by mx1.freebsd.org (Postfix) with ESMTP id 1F26413C4A6; Tue, 17 Jul 2007 19:59:48 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from [192.168.1.101] (c-71-231-138-78.hsd1.or.comcast.net [71.231.138.78]) (authenticated bits=0) by webaccess-cl.virtdom.com (8.13.6/8.13.6) with ESMTP id l6HJxjub042137 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Tue, 17 Jul 2007 15:59:46 -0400 (EDT) (envelope-from jroberson@chesapeake.net) Date: Tue, 17 Jul 2007 13:02:52 -0700 (PDT) From: Jeff Roberson X-X-Sender: jroberson@10.0.0.1 To: youshi10@u.washington.edu In-Reply-To: Message-ID: <20070717125133.S92541@10.0.0.1> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Attilio Rao , current@freebsd.org Subject: Re: ULE/SCHED_SMP diff for 7.0, buildkernel & thanks. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Jul 2007 19:59:48 -0000 On Tue, 17 Jul 2007, youshi10@u.washington.edu wrote: > > Unfortunately those results are still based on 2.6.20, not 2.6.22 (2 minor > patch revision difference). > > I assume that that's for a vanilla Linux kernel? Look more closely; The green line is linux-2.6.21 with the new glibc. I sent my kernel config to some linux hackers to look at. We removed some minor debugging code to get these results. I have also tested with 2.6.22 with no real change. Although many other people saw great improvements. I will update to fedora core 7 eventually although I supposedly have the relevant fixes. In my mind I hope that linux addresses their issues and that really isn't my primary concern. My primary concern is that freebsd is now becoming competitive on higher-end server class hardware for a variety of workloads where it was not before. I benchmarked linux just to see where we are at as they are generally considered fast and scalable. The credit for the great improvements we've seen from 6 to 7 should go to the many developers who have put a lot of hard work into locking individual subsystems and the primitives. The scheduler is only able to do better now because there is less contention over all. Thank you, Jeff > > -Garrett > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Tue Jul 17 20:03:21 2007 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 55A0E16A404; Tue, 17 Jul 2007 20:03:21 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 1DE4E13C4B2; Tue, 17 Jul 2007 20:03:21 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id A67F7470CD; Tue, 17 Jul 2007 16:03:20 -0400 (EDT) Date: Tue, 17 Jul 2007 21:03:20 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Pascal Hofstee In-Reply-To: <1184700506.1086.5.camel@worf> Message-ID: <20070717210053.M1177@fledge.watson.org> References: <20070717131518.G1177@fledge.watson.org> <1184700506.1086.5.camel@worf> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@FreeBSD.org, current@FreeBSD.org Subject: Re: Reminder: NET_NEEDS_GIANT, debug.mpsafenet going away in 7.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2007 20:03:21 -0000 On Tue, 17 Jul 2007, Pascal Hofstee wrote: > On Tue, 2007-07-17 at 13:21 +0100, Robert Watson wrote: > >> This is a reminder e-mail that, in the very near future, Giant >> compatibility shims for network protocols will be removed. These shimmed >> allowed Giant to be re-enabeld over the network stack as a result of >> linking in a service that required Giant (now all removed), or by setting >> the debug.mpsafenet variable to 1. This means that the following will no >> longer be present: >> >> debug.mpsafenet sysctl >> debug_mpsafenet global variable >> NET_NEEDS_GIANT() >> NET_LOCK_GIANT(), NET_UNLOCK_GIANT(), NET_ASSERT_GIANT() >> NET_CALLOUT_MPSAFE >> >> All instances of NET_{LOCK,UNLOCK,ASSERT}_GIANT() will be removed as they >> will no be no-ops. > > Ehrm ... i am not 100% sure here but what will this mean for those of us > running qemu on 7.x systems ... if i recall correctly qemu requires aio for > at least DMA which on 6.x at least still issues below warning when > kldloaded: > > WARNING: Network stack Giant-free, but aio requires Giant. > Consider adding 'options NET_WITH_GIANT' or setting > debug.mpsafenet=0 > > Does this removal of debug.mpsafenet mean that aio on CURRENT is now GIANT > free .. or does this mean that we'll be seeing problems with qemu on CURRENT > ? I believe that davidxu did the work in 7.0 to make aio MPSAFE -- you should not get the above warning with 7.x, only 6.x. The warning is generated by NET_NEEDS_GIANT("aio") in vfs_aio.c, and as of last week, there are no NET_NEEDS_GIANT() callers in 7.x (hence removing the infrastructure for it). Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Tue Jul 17 20:05:36 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3EFED16A400 for ; Tue, 17 Jul 2007 20:05:36 +0000 (UTC) (envelope-from Johan@double-l.nl) Received: from smtp-vbr3.xs4all.nl (smtp-vbr3.xs4all.nl [194.109.24.23]) by mx1.freebsd.org (Postfix) with ESMTP id CB0C413C4A5 for ; Tue, 17 Jul 2007 20:05:35 +0000 (UTC) (envelope-from Johan@double-l.nl) Received: from w2003s01.double-l.local (schavemaker.nl [213.84.84.186]) by smtp-vbr3.xs4all.nl (8.13.8/8.13.8) with ESMTP id l6HK5Y7C056025 for ; Tue, 17 Jul 2007 22:05:34 +0200 (CEST) (envelope-from Johan@double-l.nl) MIME-Version: 1.0 Date: Tue, 17 Jul 2007 22:06:53 +0200 Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <57200BF94E69E54880C9BB1AF714BBCB011178@w2003s01.double-l.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ULE/SCHED_SMP diff for 7.0 Thread-Index: AcfIrgUB8/PUdKBfTD2UDJrQnA5rmA== From: "Johan Hendriks" To: X-Virus-Scanned: by XS4ALL Virus Scanner Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: RE: ULE/SCHED_SMP diff for 7.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2007 20:05:36 -0000 On my HP netserver dual PIII it al works fine. =20 FreeBSD 7.0-CURRENT #0: Tue Jul 17 12:40:25 CEST 2007 root@sbsd001.double-l.local:/usr/obj/usr/src/sys/KRNL Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel Pentium III (1000.04-MHz 686-class CPU) Origin =3D "GenuineIntel" Id =3D 0x68a Stepping =3D 10 = Features=3D0x383fbff real memory =3D 536805376 (511 MB) avail memory =3D 511262720 (487 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 3 cpu1 (AP): APIC ID: 0 Don't know if it is relevant but i compiled the system with the updated = gcc 4.2 =20 gcc (GCC) 4.2.1 20070614 prerelease [FreeBSD] =20 regards, Johan Hendriks =20 From owner-freebsd-current@FreeBSD.ORG Tue Jul 17 20:13:12 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 512C616A403 for ; Tue, 17 Jul 2007 20:13:12 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 1B76313C4AA for ; Tue, 17 Jul 2007 20:13:11 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.13.8/8.13.8) with ESMTP id l6HJQgCA089472; Tue, 17 Jul 2007 15:26:42 -0400 (EDT) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.8/8.13.3) with ESMTP id l6HJQewS008525 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Jul 2007 15:26:41 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <200707171926.l6HJQewS008525@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 17 Jul 2007 15:26:20 -0400 To: Jeff Roberson , current@freebsd.org From: Mike Tancsa In-Reply-To: <20070716233030.D92541@10.0.0.1> References: <20070716233030.D92541@10.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Subject: Re: ULE/SCHED_SMP diff for 7.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2007 20:13:12 -0000 At 02:35 AM 7/17/2007, Jeff Roberson wrote: >Even "works for me!" type responses are welcome so I know roughly >how many people have tested before I commit this close to release. "Works for me" although it seems a bit slower than the old ULE on the -j2 buildworld.... But -j4 is as fast. If useful, I could reload the old kernel and run a -j4 to see what times it does. Regular ULE [em-test]# time make -j2 buildworld > /var/log/build.out ; time make -j2 buildkernel > /var/log/build.out.k 3021.917u 342.449s 32:40.21 171.6% 5900+1085k 29135+4887io 2343pf+0w 298.402u 22.080s 3:00.91 177.1% 6247+1037k 1750+1962io 4pf+0w [em-test]# time make -j2 buildworld > /var/log/build.out ; time make -j2 buildkernel > /var/log/build.out.k ; mv /usr/obj/usr /usr/obj/usr.o ; sleep 20 ; time make -j4 buildworld > /var/log/build.out ; time make -j4 buildkernel > /var/log/build.out.k 3022.101u 351.076s 45:16.79 124.1% 5871+1080k 25578+4898io 2264pf+0w 299.681u 22.354s 3:56.01 136.4% 6234+1034k 1600+1853io 0pf+0w 3057.276u 357.860s 31:57.84 178.0% 5889+1081k 2310+5057io 534pf+0w 302.924u 23.387s 2:58.57 182.7% 6231+1034k 127+1846io 0pf+0w [em-test]# CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ (2015.01-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x20fb1 Stepping = 1 Features=0x178bfbff Features2=0x1 AMD Features=0xe2500800 AMD Features2=0x3 Cores per package: 2 real memory = 2147418112 (2047 MB) avail memory = 2096111616 (1999 MB) From owner-freebsd-current@FreeBSD.ORG Tue Jul 17 20:23:53 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 433A516A407 for ; Tue, 17 Jul 2007 20:23:53 +0000 (UTC) (envelope-from bsd@kuehlbox.de) Received: from samael.qmail-ldap.de (mail.kuehlbox.de [62.159.47.22]) by mx1.freebsd.org (Postfix) with ESMTP id 9AF1913C4A7 for ; Tue, 17 Jul 2007 20:23:52 +0000 (UTC) (envelope-from bsd@kuehlbox.de) Received: (qmail 64715 invoked from network); 17 Jul 2007 20:23:50 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlbox.de; b=d5HLQwAjXVW+1N2VquQz2+uAtqA+ICCZI8VGTx6qlF7JRtbWEtRBwB1M3cEHT1YGR+IoiNF1oYRkaEGolJj8mKEapj8T3tmaCQZ4OIxOa7WgjBcq3eEfJI9dLHu+dFIx ; Received: from unknown (HELO [192.168.200.128]) (bsd@kuehlbox.de@[82.135.93.20]) (envelope-sender ) by samael.qmail-ldap.de (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 17 Jul 2007 20:23:50 -0000 Message-ID: <469D2688.7070000@kuehlbox.de> Date: Tue, 17 Jul 2007 22:28:56 +0200 From: Teufel User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Jeff Roberson , current@freebsd.org, attilio@FreeBSD.org References: <20070716233030.D92541@10.0.0.1> In-Reply-To: <20070716233030.D92541@10.0.0.1> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: ULE/SCHED_SMP diff for 7.0 - panic on x86 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Jul 2007 20:23:53 -0000 Hi, cvsuped kernel sources about 20 mins ago and applied Jeff's new ule patch. System boots normaly up, but starting qemu with kqemu (either user or user and kernel space) results immediatly in kernel trap 12 applying Attilio's patch http://people.freebsd.org/~attilio/kqemu.diff fixed the kernel trap, but hangs: spin lock 0xc0bbf780 (shed lock 1) held by 0xc5114880 (tid 100003) too long panic: spin lock held too long cpuid = 0 However, using Attilio's patch with the old ULE works. Greetings, Stephan dmesg about CPU follows: FreeBSD 7.0-CURRENT #27 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz (2404.13-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6f6 Stepping = 6 Features=0xbfebfbff Features2=0xe3bd AMD Features=0x20000000 AMD Features2=0x1 Cores per package: 2 real memory = 2146828288 (2047 MB) avail memory = 2091286528 (1994 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 Jeff Roberson wrote: > http://people.freebsd.org/~jeff/ule.diff > > > > Briefly, this is still a very suitable scheduler for uniprocessor > machines while providing stronger affinity and other performance > improvements for multiprocessor machines. From owner-freebsd-current@FreeBSD.ORG Tue Jul 17 20:29:29 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E07C816A403 for ; Tue, 17 Jul 2007 20:29:29 +0000 (UTC) (envelope-from itetcu@FreeBSD.org) Received: from it.buh.tecnik93.com (it.buh.tecnik93.com [81.196.204.98]) by mx1.freebsd.org (Postfix) with ESMTP id 5CA9113C48D for ; Tue, 17 Jul 2007 20:29:29 +0000 (UTC) (envelope-from itetcu@FreeBSD.org) Received: from it.buh.tecnik93.com (localhost [127.0.0.1]) by it.buh.tecnik93.com (Postfix) with ESMTP id 2190A2C50D06; Tue, 17 Jul 2007 23:14:04 +0300 (EEST) Date: Tue, 17 Jul 2007 23:13:55 +0300 From: Ion-Mihai Tetcu To: "Abdullah Ibn Hamad Al-Marri" Message-ID: <20070717231355.50af7a3a@it.buh.tecnik93.com> In-Reply-To: <499c70c0707160111g31410e07v2b7d20963c9190d@mail.gmail.com> References: <200707160309.l6G396le006568@gw.catspoiler.org> <20070716092131.42143bf3@it.buh.tecnik93.com> <200707160904.47976.Thomas.Sparrevohn@btinternet.com> <499c70c0707160111g31410e07v2b7d20963c9190d@mail.gmail.com> X-Mailer: Claws Mail 2.10.0 (GTK+ 2.10.14; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_TiSfIrnSkfv/gXeaKZDCqBP"; protocol="application/pgp-signature"; micalg=PGP-SHA1 Cc: Thomas Sparrevohn , freebsd-current@freebsd.org, Don Lewis Subject: Re: hang on reboot or shutdown with 7.0-CURRENT i386 on AMD X2 + GeForce 7050 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Jul 2007 20:29:30 -0000 --Sig_TiSfIrnSkfv/gXeaKZDCqBP Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Mon, 16 Jul 2007 11:11:50 +0300 "Abdullah Ibn Hamad Al-Marri" wrote: > On 7/16/07, Thomas Sparrevohn > wrote: > > On Monday 16 July 2007 07:21:31 Ion-Mihai Tetcu wrote: > > > On Sun, 15 Jul 2007 20:09:06 -0700 (PDT) > > > Don Lewis wrote: > > > > > > I've seen the same on fairly similar hardware, with a few days > > > (10 Jul I think) sources, but I'm not seeing it with FreeBSD > > > 7.0-CURRENT #0: Thu Jul 12 20:31:29 EEST 2007. > > > Maybe you could try to go back to the same sources I use and see > > > if it makes any difference ? > >=20 > > I have had that problem since I got the machine I have now - It > > seems to be related to systems using Nvidia Nforce newer chipsets > > 570/590/6xx > > > > If I don't load any USB drivers the system shutsdown normally - I > > tried shutting down after disconnecting all external usb devices > > and all u* drivers one by one - unfortunately it seems that the > > minute "device usb" or usb.ko is present the problem reoccurs >=20 > I had the same problem, when I removed ehci from my kernel the problem > went away, my mobo is ATI which is use in Acer 5102 WLMi and not > nvidia. Hmm, I don't have any usb-related options in kernel as I'm loading them via kld (and I'm fairly certain I didn't have them before either). # kldstat Id Refs Address Size Name 1 29 0xc0400000 43dff8 kernel 2 1 0xc083e000 c3d4 if_nfe.ko 3 2 0xc084b000 1fd10 miibus.ko 4 1 0xc086b000 14e04 snd_hda.ko 5 2 0xc0880000 52a08 sound.ko 6 3 0xc08d3000 265e4 usb.ko 7 1 0xc08fa000 5e44 ugen.ko 8 1 0xc0900000 8734 umass.ko 9 1 0xc0909000 1258c bktr.ko 10 2 0xc091c000 2020 bktr_mem.ko 11 2 0xc091f000 3390 iicbus.ko 12 1 0xc0923000 46c0 iicbb.ko 13 1 0xc0928000 1be0 smbus.ko 14 1 0xc092a000 4f68 atapicam.ko 15 1 0xc092f000 6b174 acpi.ko 16 1 0xc6d9e000 a8000 zfs.ko 17 2 0xc824f000 22000 linux.ko 18 1 0xc82fc000 2000 blank_saver.ko 19 1 0xc8307000 2000 rtc.ko Rebooting works. There's a few seconds delay after syncing disks, but it eventually reboots. The dmesg is here: http://sce-tindy.tecnik93.com/FreeBSD/errors/Asus_M2N32-SLI_Deluxe_Wireless= /dmesg.boot --=20 IOnut - Un^d^dregistered ;) FreeBSD "user" "Intellectual Property" is nowhere near as valuable as "Intellect" --Sig_TiSfIrnSkfv/gXeaKZDCqBP Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFGnSMKBX6fi0k6KXsRAnGKAJ9+vXCiW2n6rAlvLVFayep8JWdUqwCcCCzG FpblJJKjo86FdJHs9c1YpR0= =n3sE -----END PGP SIGNATURE----- --Sig_TiSfIrnSkfv/gXeaKZDCqBP-- From owner-freebsd-current@FreeBSD.ORG Tue Jul 17 20:29:41 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9824A16A403; Tue, 17 Jul 2007 20:29:41 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from webaccess-cl.virtdom.com (webaccess-cl.virtdom.com [216.240.101.25]) by mx1.freebsd.org (Postfix) with ESMTP id 63D9E13C4BA; Tue, 17 Jul 2007 20:29:41 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from [192.168.1.101] (c-71-231-138-78.hsd1.or.comcast.net [71.231.138.78]) (authenticated bits=0) by webaccess-cl.virtdom.com (8.13.6/8.13.6) with ESMTP id l6HKTd4L051251 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Tue, 17 Jul 2007 16:29:40 -0400 (EDT) (envelope-from jroberson@chesapeake.net) Date: Tue, 17 Jul 2007 13:32:45 -0700 (PDT) From: Jeff Roberson X-X-Sender: jroberson@10.0.0.1 To: Teufel In-Reply-To: <469D2688.7070000@kuehlbox.de> Message-ID: <20070717133131.J92541@10.0.0.1> References: <20070716233030.D92541@10.0.0.1> <469D2688.7070000@kuehlbox.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: attilio@freebsd.org, current@freebsd.org Subject: Re: ULE/SCHED_SMP diff for 7.0 - panic on x86 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Jul 2007 20:29:41 -0000 On Tue, 17 Jul 2007, Teufel wrote: > Hi, > > cvsuped kernel sources about 20 mins ago and applied Jeff's new ule patch. > System boots normaly up, but starting qemu with kqemu (either user or user > and kernel space) results immediatly in kernel trap 12 > applying Attilio's patch http://people.freebsd.org/~attilio/kqemu.diff > fixed the kernel trap, but hangs: > > spin lock 0xc0bbf780 (shed lock 1) held by 0xc5114880 (tid 100003) too long > panic: spin lock held too long > cpuid = 0 Can you enable INVARIANTS, WITNESS, KDB and DDB in your kernel? Then get me a trace when this happens and any other consoles prints that look relevant. Thanks, Jeff > > However, using Attilio's patch with the old ULE works. > > Greetings, > > Stephan > > dmesg about CPU follows: > > FreeBSD 7.0-CURRENT #27 > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz (2404.13-MHz 686-class > CPU) > Origin = "GenuineIntel" Id = 0x6f6 Stepping = 6 > Features=0xbfebfbff > Features2=0xe3bd > AMD Features=0x20000000 > AMD Features2=0x1 > Cores per package: 2 > real memory = 2146828288 (2047 MB) > avail memory = 2091286528 (1994 MB) > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 1 > > > > Jeff Roberson wrote: >> http://people.freebsd.org/~jeff/ule.diff >> >> >> >> Briefly, this is still a very suitable scheduler for uniprocessor machines >> while providing stronger affinity and other performance improvements for >> multiprocessor machines. > From owner-freebsd-current@FreeBSD.ORG Tue Jul 17 20:38:21 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2A0B516A400 for ; Tue, 17 Jul 2007 20:38:21 +0000 (UTC) (envelope-from ubm@u-boot-man.de) Received: from mail.upper.net (mail.upper.net [62.75.224.33]) by mx1.freebsd.org (Postfix) with ESMTP id BFA7A13C4A5 for ; Tue, 17 Jul 2007 20:38:20 +0000 (UTC) (envelope-from ubm@u-boot-man.de) Received: from ubm.mine.nu (p57AE4345.dip0.t-ipconnect.de [87.174.67.69]) (authenticated bits=0) by mail.upper.net (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l6HKcF1e016870 for ; Tue, 17 Jul 2007 22:38:16 +0200 Date: Tue, 17 Jul 2007 22:44:37 +0200 From: Marc "UBM" Bocklet To: freebsd-current@freebsd.org Message-Id: <20070717224437.457dd9fa.ubm@u-boot-man.de> In-Reply-To: <20070716233030.D92541@10.0.0.1> References: <20070716233030.D92541@10.0.0.1> X-Mailer: Sylpheed 2.4.0 (GTK+ 2.10.12; i386-portbld-freebsd6.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: ULE/SCHED_SMP diff for 7.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2007 20:38:21 -0000 On Mon, 16 Jul 2007 23:35:38 -0700 (PDT) Jeff Roberson wrote: > http://people.freebsd.org/~jeff/ule.diff > > This patch is scheduled for inclusion in 7.0. I would like anyone > who cares to run it to validate that it does not create any stability > or performance regression over the existing ULE. This patch replaces > ULE with SCHED_SMP, which will now no longer exist as a seperate fork > of ULE. > > Briefly, this is still a very suitable scheduler for uniprocessor > machines while providing stronger affinity and other performance > improvements for multiprocessor machines. > > Even "works for me!" type responses are welcome so I know roughly how > many people have tested before I commit this close to release. FreeBSD blah.blah 7.0-CURRENT FreeBSD 7.0-CURRENT #2: Tue Jul 17 12:31:02 CEST 2007 Seems stable here, just survived a buildworld -j4 + basic load (mysql-server, apache, imapd, fetchmail, procmail, spamassassin) without problems. Interactivity was very good throughout. CPU: AMD Athlon(tm) 64 Processor 3500+ (2210.77-MHz 686-class CPU) It's a uniprocessor system running an i386 kernel. Bye Marc -- "A sudden blow: the great wings beating still Above the staggering girl, her thighs caressed By the dark webs, her nape caught in his bill, He holds her helpless breast upon his breast." W.B. Yeats, Leda and the Swan From owner-freebsd-current@FreeBSD.ORG Tue Jul 17 20:40:14 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3CEB716A408; Tue, 17 Jul 2007 20:40:14 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from webaccess-cl.virtdom.com (webaccess-cl.virtdom.com [216.240.101.25]) by mx1.freebsd.org (Postfix) with ESMTP id E3ED713C4A3; Tue, 17 Jul 2007 20:40:13 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from [192.168.1.101] (c-71-231-138-78.hsd1.or.comcast.net [71.231.138.78]) (authenticated bits=0) by webaccess-cl.virtdom.com (8.13.6/8.13.6) with ESMTP id l6HKeBGw054393 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Tue, 17 Jul 2007 16:40:13 -0400 (EDT) (envelope-from jroberson@chesapeake.net) Date: Tue, 17 Jul 2007 13:43:18 -0700 (PDT) From: Jeff Roberson X-X-Sender: jroberson@10.0.0.1 To: Teufel In-Reply-To: <20070717133131.J92541@10.0.0.1> Message-ID: <20070717134252.D92541@10.0.0.1> References: <20070716233030.D92541@10.0.0.1> <469D2688.7070000@kuehlbox.de> <20070717133131.J92541@10.0.0.1> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: attilio@freebsd.org, current@freebsd.org Subject: Re: ULE/SCHED_SMP diff for 7.0 - panic on x86 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Jul 2007 20:40:14 -0000 On Tue, 17 Jul 2007, Jeff Roberson wrote: > On Tue, 17 Jul 2007, Teufel wrote: > >> Hi, >> >> cvsuped kernel sources about 20 mins ago and applied Jeff's new ule patch. >> System boots normaly up, but starting qemu with kqemu (either user or user >> and kernel space) results immediatly in kernel trap 12 >> applying Attilio's patch http://people.freebsd.org/~attilio/kqemu.diff >> fixed the kernel trap, but hangs: >> >> spin lock 0xc0bbf780 (shed lock 1) held by 0xc5114880 (tid 100003) too long >> panic: spin lock held too long >> cpuid = 0 > Can you enable INVARIANTS, WITNESS, KDB and DDB in your kernel? Then get me > a trace when this happens and any other consoles prints that look relevant. Can you also run ldd on the kqemu binary? I'd like to know if it's linked against libthr or libkse. > > Thanks, > Jeff > >> >> However, using Attilio's patch with the old ULE works. >> >> Greetings, >> >> Stephan >> >> dmesg about CPU follows: >> >> FreeBSD 7.0-CURRENT #27 >> Timecounter "i8254" frequency 1193182 Hz quality 0 >> CPU: Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz (2404.13-MHz 686-class >> CPU) >> Origin = "GenuineIntel" Id = 0x6f6 Stepping = 6 >> Features=0xbfebfbff >> Features2=0xe3bd >> AMD Features=0x20000000 >> AMD Features2=0x1 >> Cores per package: 2 >> real memory = 2146828288 (2047 MB) >> avail memory = 2091286528 (1994 MB) >> ACPI APIC Table: >> FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs >> cpu0 (BSP): APIC ID: 0 >> cpu1 (AP): APIC ID: 1 >> >> >> >> Jeff Roberson wrote: >>> http://people.freebsd.org/~jeff/ule.diff >>> >>> >>> >>> Briefly, this is still a very suitable scheduler for uniprocessor machines >>> while providing stronger affinity and other performance improvements for >>> multiprocessor machines. >> > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Tue Jul 17 20:41:38 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3174C16A406; Tue, 17 Jul 2007 20:41:38 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from ns.trinitel.com (186.161.36.72.static.reverse.layeredtech.com [72.36.161.186]) by mx1.freebsd.org (Postfix) with ESMTP id 00CD313C4BC; Tue, 17 Jul 2007 20:41:37 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from proton.local (209-163-168-124.static.twtelecom.net [209.163.168.124]) (authenticated bits=0) by ns.trinitel.com (8.14.1/8.14.1) with ESMTP id l6HKfUYR059049; Tue, 17 Jul 2007 15:41:30 -0500 (CDT) (envelope-from anderson@freebsd.org) Message-ID: <469D2979.60006@freebsd.org> Date: Tue, 17 Jul 2007 15:41:29 -0500 From: Eric Anderson User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: Jeff Roberson References: <20070716233030.D92541@10.0.0.1> <469D2688.7070000@kuehlbox.de> <20070717133131.J92541@10.0.0.1> <20070717134252.D92541@10.0.0.1> In-Reply-To: <20070717134252.D92541@10.0.0.1> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on ns.trinitel.com Cc: attilio@freebsd.org, current@freebsd.org, Teufel Subject: Re: ULE/SCHED_SMP diff for 7.0 - panic on x86 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Jul 2007 20:41:38 -0000 Jeff Roberson wrote: > On Tue, 17 Jul 2007, Jeff Roberson wrote: > >> On Tue, 17 Jul 2007, Teufel wrote: >> >>> Hi, >>> >>> cvsuped kernel sources about 20 mins ago and applied Jeff's new ule >>> patch. >>> System boots normaly up, but starting qemu with kqemu (either user or >>> user and kernel space) results immediatly in kernel trap 12 >>> applying Attilio's patch >>> http://people.freebsd.org/~attilio/kqemu.diff fixed the kernel trap, >>> but hangs: >>> >>> spin lock 0xc0bbf780 (shed lock 1) held by 0xc5114880 (tid 100003) >>> too long >>> panic: spin lock held too long >>> cpuid = 0 >> Can you enable INVARIANTS, WITNESS, KDB and DDB in your kernel? Then >> get me a trace when this happens and any other consoles prints that >> look relevant. > > Can you also run ldd on the kqemu binary? I'd like to know if it's > linked against libthr or libkse. Note that there was recently a thread in -emulation that sorted this out. Updating the kqemu and qemu ports should help. Eric From owner-freebsd-current@FreeBSD.ORG Tue Jul 17 20:44:09 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E8B9F16A400; Tue, 17 Jul 2007 20:44:09 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from ns.trinitel.com (186.161.36.72.static.reverse.layeredtech.com [72.36.161.186]) by mx1.freebsd.org (Postfix) with ESMTP id B789613C47E; Tue, 17 Jul 2007 20:44:09 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from proton.local (209-163-168-124.static.twtelecom.net [209.163.168.124]) (authenticated bits=0) by ns.trinitel.com (8.14.1/8.14.1) with ESMTP id l6HKi2wD059151; Tue, 17 Jul 2007 15:44:02 -0500 (CDT) (envelope-from anderson@freebsd.org) Message-ID: <469D2A11.6040207@freebsd.org> Date: Tue, 17 Jul 2007 15:44:01 -0500 From: Eric Anderson User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: Jeff Roberson References: <20070716233030.D92541@10.0.0.1> <469D2688.7070000@kuehlbox.de> <20070717133131.J92541@10.0.0.1> <20070717134252.D92541@10.0.0.1> <469D2979.60006@freebsd.org> In-Reply-To: <469D2979.60006@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on ns.trinitel.com Cc: attilio@freebsd.org, current@freebsd.org, Teufel Subject: Re: ULE/SCHED_SMP diff for 7.0 - panic on x86 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Jul 2007 20:44:10 -0000 Eric Anderson wrote: > Jeff Roberson wrote: >> On Tue, 17 Jul 2007, Jeff Roberson wrote: >> >>> On Tue, 17 Jul 2007, Teufel wrote: >>> >>>> Hi, >>>> >>>> cvsuped kernel sources about 20 mins ago and applied Jeff's new ule >>>> patch. >>>> System boots normaly up, but starting qemu with kqemu (either user >>>> or user and kernel space) results immediatly in kernel trap 12 >>>> applying Attilio's patch >>>> http://people.freebsd.org/~attilio/kqemu.diff fixed the kernel trap, >>>> but hangs: >>>> >>>> spin lock 0xc0bbf780 (shed lock 1) held by 0xc5114880 (tid 100003) >>>> too long >>>> panic: spin lock held too long >>>> cpuid = 0 >>> Can you enable INVARIANTS, WITNESS, KDB and DDB in your kernel? Then >>> get me a trace when this happens and any other consoles prints that >>> look relevant. >> >> Can you also run ldd on the kqemu binary? I'd like to know if it's >> linked against libthr or libkse. > > Note that there was recently a thread in -emulation that sorted this > out. Updating the kqemu and qemu ports should help. I should be more clear: /sorted this out/sorted out something similar/ /should help/might help/ Eric From owner-freebsd-current@FreeBSD.ORG Tue Jul 17 21:03:32 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B61D016A402 for ; Tue, 17 Jul 2007 21:03:32 +0000 (UTC) (envelope-from marinosi@diogenis.ceid.upatras.gr) Received: from poseidon.ceid.upatras.gr (poseidon.ceid.upatras.gr [150.140.141.169]) by mx1.freebsd.org (Postfix) with ESMTP id 172BB13C442 for ; Tue, 17 Jul 2007 21:03:31 +0000 (UTC) (envelope-from marinosi@diogenis.ceid.upatras.gr) Received: from mail.ceid.upatras.gr (unknown [10.1.0.143]) by poseidon.ceid.upatras.gr (Postfix) with ESMTP id 30D3DEB46BA for ; Wed, 18 Jul 2007 00:03:30 +0300 (EEST) Received: from localhost (europa.ceid.upatras.gr [127.0.0.1]) by mail.ceid.upatras.gr (Postfix) with ESMTP id DD28D157C58 for ; Wed, 18 Jul 2007 00:03:29 +0300 (EEST) X-Virus-Scanned: amavisd-new at ceid.upatras.gr Received: from mail.ceid.upatras.gr ([127.0.0.1]) by localhost (europa.ceid.upatras.gr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iAKZMkXJ7p8F for ; Wed, 18 Jul 2007 00:03:29 +0300 (EEST) Received: from diogenis.ceid.upatras.gr (unknown [10.1.0.181]) by mail.ceid.upatras.gr (Postfix) with ESMTP id 90341157AE1 for ; Wed, 18 Jul 2007 00:03:29 +0300 (EEST) Received: by diogenis.ceid.upatras.gr (Postfix, from userid 3149) id 2047C8FF41; Wed, 18 Jul 2007 00:03:28 +0300 (EEST) Date: Wed, 18 Jul 2007 00:03:28 +0300 From: Marinos Ilias To: freebsd-current@freebsd.org Message-ID: <20070717210328.GA899@ceid.upatras.gr> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="98e8jtXdkpgskNou" Content-Disposition: inline User-Agent: Mutt/1.4.2.2i Subject: Re: ULE/SCHED_SMP diff for 7.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2007 21:03:32 -0000 --98e8jtXdkpgskNou Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hello list, although I run -CURRENT on a pentium4 , as I have HyperThreading enabled (ok I know about the issues :-P ) I tried Jeff's patch.It works for me :-P It works fine , although I cannot figure out if I can have any improve with my cpu. I attach the results for 4 sysbench tests (for both unpatched and patched ULE) .A little bit weird results for 800 and 1000 threads test.Congratulations Jeff.Nice work! Cheers, Ilias --98e8jtXdkpgskNou Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=ule_patched sysbench v0.4.8: multi-threaded system evaluation benchmark Running the test with following options: Number of threads: 800 Doing thread subsystem performance test Thread yields per test: 1000 Locks used: 8 Threads started! Done. Test execution summary: total time: 115.8402s total number of events: 10000 total time taken by event execution: 89360.0746 per-request statistics: min: 0.0128s avg: 8.9360s max: 92.6393s approx. 95 percentile: 32.3754s Threads fairness: events (avg/stddev): 12.5000/4.36 execution time (avg/stddev): 111.7001/2.50 sysbench v0.4.8: multi-threaded system evaluation benchmark Running the test with following options: Number of threads: 1000 Doing thread subsystem performance test Thread yields per test: 1000 Locks used: 8 Threads started! Done. Test execution summary: total time: 119.3290s total number of events: 10000 total time taken by event execution: 114023.2052 per-request statistics: min: 0.0230s avg: 11.4023s max: 119.0953s approx. 95 percentile: 40.3187s Threads fairness: events (avg/stddev): 10.0000/3.88 execution time (avg/stddev): 114.0232/3.17 sysbench v0.4.8: multi-threaded system evaluation benchmark Running the test with following options: Number of threads: 1000 Doing CPU performance benchmark Threads started! Done. Maximum prime number checked in CPU test: 10000 Test execution summary: total time: 38.5863s total number of events: 10000 total time taken by event execution: 6625.7610 per-request statistics: min: 0.0071s avg: 0.6626s max: 38.3246s approx. 95 percentile: 0.9653s Threads fairness: events (avg/stddev): 10.0000/17.95 execution time (avg/stddev): 6.6258/12.28 sysbench v0.4.8: multi-threaded system evaluation benchmark Running the test with following options: Number of threads: 100 Doing CPU performance benchmark Threads started! Done. Maximum prime number checked in CPU test: 10000 Test execution summary: total time: 38.3250s total number of events: 10000 total time taken by event execution: 3321.8330 per-request statistics: min: 0.0072s avg: 0.3322s max: 25.5190s approx. 95 percentile: 0.9860s Threads fairness: events (avg/stddev): 100.0000/56.36 execution time (avg/stddev): 33.2183/4.89 --98e8jtXdkpgskNou Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=ule_unpatched sysbench v0.4.8: multi-threaded system evaluation benchmark Running the test with following options: Number of threads: 800 Doing thread subsystem performance test Thread yields per test: 1000 Locks used: 8 Threads started! Done. Test execution summary: total time: 118.3846s total number of events: 10000 total time taken by event execution: 91204.1873 per-request statistics: min: 0.0033s avg: 9.1204s max: 103.2080s approx. 95 percentile: 34.6621s Threads fairness: events (avg/stddev): 12.5000/4.79 execution time (avg/stddev): 114.0052/2.56 sysbench v0.4.8: multi-threaded system evaluation benchmark Running the test with following options: Number of threads: 1000 Doing thread subsystem performance test Thread yields per test: 1000 Locks used: 8 Threads started! Done. Test execution summary: total time: 119.2878s total number of events: 10000 total time taken by event execution: 113845.7329 per-request statistics: min: 0.0232s avg: 11.3846s max: 118.5737s approx. 95 percentile: 40.6458s Threads fairness: events (avg/stddev): 10.0000/3.87 execution time (avg/stddev): 113.8457/3.21 sysbench v0.4.8: multi-threaded system evaluation benchmark Running the test with following options: Number of threads: 1000 Doing CPU performance benchmark Threads started! Done. Maximum prime number checked in CPU test: 10000 Test execution summary: total time: 39.7346s total number of events: 10594 total time taken by event execution: 8634.6490 per-request statistics: min: 0.0067s avg: 0.8151s max: 39.3339s approx. 95 percentile: 3.4416s Threads fairness: events (avg/stddev): 10.5940/11.65 execution time (avg/stddev): 8.6346/7.60 sysbench v0.4.8: multi-threaded system evaluation benchmark Running the test with following options: Number of threads: 100 Doing CPU performance benchmark Threads started! Done. Maximum prime number checked in CPU test: 10000 Test execution summary: total time: 37.8735s total number of events: 10000 total time taken by event execution: 3497.9287 per-request statistics: min: 0.0069s avg: 0.3498s max: 15.2557s approx. 95 percentile: 1.0344s Threads fairness: events (avg/stddev): 100.0000/58.32 execution time (avg/stddev): 34.9793/2.34 --98e8jtXdkpgskNou-- From owner-freebsd-current@FreeBSD.ORG Tue Jul 17 21:12:29 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3408416A403 for ; Tue, 17 Jul 2007 21:12:29 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.177]) by mx1.freebsd.org (Postfix) with ESMTP id 0CFF213C4C8 for ; Tue, 17 Jul 2007 21:12:28 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by wa-out-1112.google.com with SMTP id j37so2340235waf for ; Tue, 17 Jul 2007 14:12:28 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=M+mtu0ZRwVrCGzF49bl9vkNwfvP/a8h+CbzzQSDkIMZb99phSDdgblPUaI2IFh6FyNWP8F6vChbdb+HetzyK1VoS3sf0tYtmDldRNiDmGK4xjai01bKJwnk6FOZ4E4+WYQwTuF5179d6VQTprO9lKzcpZH3gREbb/efI52wk0PQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ERsiyrBUEtBwc3tsZrt5Zdhl9oUEQZUEiZW+wQTdnTGotGPBOzoK2Hid0G7EI7EAx3DD/PigQCjVegk4yi1RYqvSk90OBmlsEg5+MTEJRfcGlGufD+4JWK6urIvCbqbbKImH1huvPFRPhY9TrGZh3j8hQNMgYpQMo/KlrLgkFXw= Received: by 10.114.27.20 with SMTP id a20mr802464waa.1184706748178; Tue, 17 Jul 2007 14:12:28 -0700 (PDT) Received: by 10.114.103.14 with HTTP; Tue, 17 Jul 2007 14:12:28 -0700 (PDT) Message-ID: <2a41acea0707171412i64c337d7sce6698f86076a860@mail.gmail.com> Date: Tue, 17 Jul 2007 14:12:28 -0700 From: "Jack Vogel" To: "Harald Schmalzbauer" In-Reply-To: <469CF9E5.2080200@omnisec.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <469CF9E5.2080200@omnisec.de> Cc: current@freebsd.org Subject: Re: ich9 ahci support? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2007 21:12:29 -0000 On 7/17/07, Harald Schmalzbauer wrote: > Hello, > > does anybody know if there's a difference in accessing ich8 vs. ich9? > Is it enough to add ID bits to support it? I believe its just an ID kinda change, for my E1000 driver there are a few other differences, but I assume you are talking chipset. If you google 'x86-ich9' you'll find a Linux patch that seems pretty much device ID changes. I can get more detail if needed but just not right this moment. Jack From owner-freebsd-current@FreeBSD.ORG Tue Jul 17 21:16:52 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4694516A401 for ; Tue, 17 Jul 2007 21:16:52 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) by mx1.freebsd.org (Postfix) with ESMTP id B6E9513C4BA for ; Tue, 17 Jul 2007 21:16:51 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.1/8.14.1) with ESMTP id l6HLGf6v016565; Wed, 18 Jul 2007 01:16:41 +0400 (MSD) (envelope-from marck@rinet.ru) Date: Wed, 18 Jul 2007 01:16:41 +0400 (MSD) From: Dmitry Morozovsky To: Jeff Roberson In-Reply-To: <20070716233030.D92541@10.0.0.1> Message-ID: <20070718011332.A14574@woozle.rinet.ru> References: <20070716233030.D92541@10.0.0.1> X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (woozle.rinet.ru [0.0.0.0]); Wed, 18 Jul 2007 01:16:41 +0400 (MSD) Cc: current@freebsd.org Subject: Re: ULE/SCHED_SMP diff for 7.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2007 21:16:52 -0000 On Mon, 16 Jul 2007, Jeff Roberson wrote: JR> http://people.freebsd.org/~jeff/ule.diff JR> JR> This patch is scheduled for inclusion in 7.0. I would like anyone who cares JR> to run it to validate that it does not create any stability or performance JR> regression over the existing ULE. This patch replaces ULE with SCHED_SMP, JR> which will now no longer exist as a seperate fork of ULE. JR> JR> Briefly, this is still a very suitable scheduler for uniprocessor machines JR> while providing stronger affinity and other performance improvements for JR> multiprocessor machines. JR> JR> Even "works for me!" type responses are welcome so I know roughly how many JR> people have tested before I commit this close to release. Works for me with MSI S420 lapton (core2duo T2400) on fresh -CURRENT/i386 CPU: Genuine Intel(R) CPU T2400 @ 1.83GHz (1833.41-MHz 686-class CPU) However, make -j3 buildworld buildkernel (trimmed GENERIC) time degraded by 7%: marck@mck-s420:/var/tmp> ministat before after x before + after +------------------------------------------------------------------------------+ | x + | | x + | |x x x + + +| ||__MA____| |__A__| | +------------------------------------------------------------------------------+ N Min Max Median Avg Stddev x 5 36.33 36.77 36.45 36.486 0.16637307 + 5 38.87 39.23 39.03 39.042 0.12774976 Difference at 95.0% confidence 2.556 +/- 0.216322 7.00543% +/- 0.59289% (Student's t, pooled s = 0.148324) before = kernel with SCHED_4BSD, after = SCHED_ULE with your patchset. Both are without WITNESS/INVARIANTS. Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Tue Jul 17 21:42:52 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B961516A400; Tue, 17 Jul 2007 21:42:52 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.188]) by mx1.freebsd.org (Postfix) with ESMTP id 44B9713C491; Tue, 17 Jul 2007 21:42:52 +0000 (UTC) (envelope-from max@love2party.net) Received: from [88.66.59.43] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu4) with ESMTP (Nemesis), id 0ML21M-1IAuok46hu-0004TK; Tue, 17 Jul 2007 23:42:51 +0200 From: Max Laier Organization: FreeBSD To: freebsd-arch@freebsd.org Date: Tue, 17 Jul 2007 23:42:14 +0200 User-Agent: KMail/1.9.7 References: <20070717131518.G1177@fledge.watson.org> In-Reply-To: <20070717131518.G1177@fledge.watson.org> X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1196626.J7k12aMeaH"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200707172342.39082.max@love2party.net> X-Provags-ID: V01U2FsdGVkX19wTlp8A33NdffBkuSCqDVAD9+nCn7iRlaGezK eaN4BkrpsX6hiwe8m+8VQDx2f86eCa9Ytt2Wkgxy/oHT2itbKU Pk3iYvWGauWY9V9jxacvY/MrZAJ8dPFw1jm9FBMSpQ= Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org, Robert Watson , freebsd-pf@freebsd.org Subject: Re: Reminder: NET_NEEDS_GIANT, debug.mpsafenet going away in 7.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2007 21:42:52 -0000 --nextPart1196626.J7k12aMeaH Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline [ Excess CC-list ... testers needed!!! ] On Tuesday 17 July 2007, Robert Watson wrote: > Dear all: > > This is a reminder e-mail that, in the very near future, Giant > compatibility shims for network protocols will be removed. <...> > The *only* remaining case I am aware of where removing debug.mpsafenet > presents an issue is credential-related firewall rules (uid, gid, > jail). I'm am currently in an active e-mail discussion with the > various firewall maintainers about how to address this issue; as the > implementations of these rules violate the global lock order, deadlocks > occur if debug.mpsafenet isn't set to 1, which causes Giant to act as a > guard lock preventing parallel lock acquisition in the firewall.=20 > Hopefully we will have this resolved, in some form, soon. What we really need right now, is real understanding of the problem (if=20 there even is any). So we would like to ask everybody who is able to -=20 to stress test user/group rules (in pf) or uid/gid/jail rules (in ipfw)=20 with debug.mpsafenet=3D1 It is normal that (in an WITNESS enabled kernel)= =20 you get a LOR similar to 14-17 and 32 from [1]. Everything different to=20 those should be reported. If you indeed get a deadlock, please let us know and provide as much=20 debugging information as you can. DDB's "ps", "show locks", "show=20 alllocks" would be perfect, but detailed information how to repeat would=20 be a good start to already. Thanks a lot! If you are unable to provoke a deadlock, please let us know= =20 as well. Include a few setup details (ruleset, SMP, special sysctl=20 settings ...) so we can look for patterns. [1] http://sources.zabbadoz.net/freebsd/lor.html =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart1196626.J7k12aMeaH Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQBGnTfPXyyEoT62BG0RAlyQAJ4gRB+txS34yl7wZUd4WEF1fNI32ACfecPR prtWaB/DFI+ykloZIk8nin4= =Mvwf -----END PGP SIGNATURE----- --nextPart1196626.J7k12aMeaH-- From owner-freebsd-current@FreeBSD.ORG Tue Jul 17 21:52:07 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7C4B316A404 for ; Tue, 17 Jul 2007 21:52:07 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outJ.internet-mail-service.net (outJ.internet-mail-service.net [216.240.47.233]) by mx1.freebsd.org (Postfix) with ESMTP id 43D7913C474 for ; Tue, 17 Jul 2007 21:52:07 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Tue, 17 Jul 2007 14:52:06 -0700 Received: from julian-mac.elischer.org (nat.ironport.com [63.251.108.100]) by idiom.com (Postfix) with ESMTP id 45AB8125AE6; Tue, 17 Jul 2007 14:52:06 -0700 (PDT) Message-ID: <469D3A23.5000809@elischer.org> Date: Tue, 17 Jul 2007 14:52:35 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: Max Laier References: <20070717131518.G1177@fledge.watson.org> <200707172342.39082.max@love2party.net> In-Reply-To: <200707172342.39082.max@love2party.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org, Robert Watson , freebsd-pf@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Reminder: NET_NEEDS_GIANT, debug.mpsafenet going away in 7.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2007 21:52:07 -0000 Max Laier wrote: > [ Excess CC-list ... testers needed!!! ] > > On Tuesday 17 July 2007, Robert Watson wrote: >> Dear all: >> >> This is a reminder e-mail that, in the very near future, Giant >> compatibility shims for network protocols will be removed. > > <...> > >> The *only* remaining case I am aware of where removing debug.mpsafenet >> presents an issue is credential-related firewall rules (uid, gid, >> jail). I'm am currently in an active e-mail discussion with the >> various firewall maintainers about how to address this issue; as the >> implementations of these rules violate the global lock order, deadlocks >> occur if debug.mpsafenet isn't set to 1, which causes Giant to act as a >> guard lock preventing parallel lock acquisition in the firewall. >> Hopefully we will have this resolved, in some form, soon. > > What we really need right now, is real understanding of the problem (if > there even is any). So we would like to ask everybody who is able to - > to stress test user/group rules (in pf) or uid/gid/jail rules (in ipfw) > with debug.mpsafenet=1 It is normal that (in an WITNESS enabled kernel) > you get a LOR similar to 14-17 and 32 from [1]. Everything different to > those should be reported. > > If you indeed get a deadlock, please let us know and provide as much > debugging information as you can. DDB's "ps", "show locks", "show > alllocks" would be perfect, but detailed information how to repeat would > be a good start to already. > > Thanks a lot! If you are unable to provoke a deadlock, please let us know > as well. Include a few setup details (ruleset, SMP, special sysctl > settings ...) so we can look for patterns. I've not seen a deadlock, only LOR warnings. > > [1] http://sources.zabbadoz.net/freebsd/lor.html > From owner-freebsd-current@FreeBSD.ORG Tue Jul 17 22:10:04 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AB48D16A401 for ; Tue, 17 Jul 2007 22:10:04 +0000 (UTC) (envelope-from datahead4@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.181]) by mx1.freebsd.org (Postfix) with ESMTP id 7E27013C441 for ; Tue, 17 Jul 2007 22:10:04 +0000 (UTC) (envelope-from datahead4@gmail.com) Received: by wa-out-1112.google.com with SMTP id j37so2366887waf for ; Tue, 17 Jul 2007 15:10:01 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Frl42RLwz35fGOPmnmpbby3ve9zi44EahrtPKnHWORUYpweyLcAdLST//Ra+sdKgmR88nuaHLWXNSfFo78wd9Tz+iPaM8RVaRrzjb5xm/mOrqEHWiZqs8gBm669oe0Yvxba0X1hoL1zcXZbs9eRR2US8S/yKoqfV5NAkA7Czbqk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=AvELgVsoKEM/shl3iD5gPFgxBnI/e4NA8ilZ8TxkKmxiqirbkwL8RgK/trBWNRDD9WSa+mWFaMrJ5qlzkGMfDWTfYqhGLVgwJAEOQ68o1ngvuQyudc/dVQSxn2u9e/duAz68nNUUSS6pOd4MTW6+pXwdTLqK6x0gXCi3NyIajBQ= Received: by 10.115.55.1 with SMTP id h1mr847965wak.1184710201141; Tue, 17 Jul 2007 15:10:01 -0700 (PDT) Received: by 10.114.205.5 with HTTP; Tue, 17 Jul 2007 15:10:00 -0700 (PDT) Message-ID: Date: Tue, 17 Jul 2007 17:10:00 -0500 From: Matt To: "Eric Anderson" In-Reply-To: <469D2979.60006@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070716233030.D92541@10.0.0.1> <469D2688.7070000@kuehlbox.de> <20070717133131.J92541@10.0.0.1> <20070717134252.D92541@10.0.0.1> <469D2979.60006@freebsd.org> Cc: attilio@freebsd.org, Jeff Roberson , current@freebsd.org, Teufel Subject: Re: ULE/SCHED_SMP diff for 7.0 - panic on x86 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Jul 2007 22:10:04 -0000 On 7/17/07, Eric Anderson wrote: > Jeff Roberson wrote: > > On Tue, 17 Jul 2007, Jeff Roberson wrote: > > > >> On Tue, 17 Jul 2007, Teufel wrote: > >> > >>> Hi, > >>> > >>> cvsuped kernel sources about 20 mins ago and applied Jeff's new ule > >>> patch. > >>> System boots normaly up, but starting qemu with kqemu (either user or > >>> user and kernel space) results immediatly in kernel trap 12 > >>> applying Attilio's patch > >>> http://people.freebsd.org/~attilio/kqemu.diff fixed the kernel trap, > >>> but hangs: > >>> > >>> spin lock 0xc0bbf780 (shed lock 1) held by 0xc5114880 (tid 100003) > >>> too long > >>> panic: spin lock held too long > >>> cpuid = 0 > >> Can you enable INVARIANTS, WITNESS, KDB and DDB in your kernel? Then > >> get me a trace when this happens and any other consoles prints that > >> look relevant. > > > > Can you also run ldd on the kqemu binary? I'd like to know if it's > > linked against libthr or libkse. > > Note that there was recently a thread in -emulation that sorted this > out. Updating the kqemu and qemu ports should help. > > Eric > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > I am seeing the same behavior with kqemu panicking the system. An ldd against kqemu.ko doesn't show it linked to any shared libraries, and I have tried all of the combinations shown in the recent thread on the -emulation list (-DKSE in the kqemu port and Attilio's patch). Will let you know if I can get any debug information. My setup has been refusing to let me get any dumps lately (don't know what I messed up to cause that). From owner-freebsd-current@FreeBSD.ORG Tue Jul 17 22:13:33 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C354016A402; Tue, 17 Jul 2007 22:13:33 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from vlakno.cz (vlk.vlakno.cz [62.168.28.247]) by mx1.freebsd.org (Postfix) with ESMTP id 789FA13C461; Tue, 17 Jul 2007 22:13:33 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from localhost (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id D5DDD8BFF62; Wed, 18 Jul 2007 00:13:31 +0200 (CEST) X-Virus-Scanned: amavisd-new at vlakno.cz Received: from vlakno.cz ([127.0.0.1]) by localhost (vlk.vlakno.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sf54fyLrt5MX; Wed, 18 Jul 2007 00:13:30 +0200 (CEST) Received: from vlk.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id BA48E8BFED3; Wed, 18 Jul 2007 00:13:30 +0200 (CEST) Received: (from rdivacky@localhost) by vlk.vlakno.cz (8.13.8/8.13.8/Submit) id l6HMDSOc060184; Wed, 18 Jul 2007 00:13:28 +0200 (CEST) (envelope-from rdivacky) Date: Wed, 18 Jul 2007 00:13:28 +0200 From: Roman Divacky To: Teufel Message-ID: <20070717221327.GA60004@freebsd.org> References: <20070716233030.D92541@10.0.0.1> <469D2688.7070000@kuehlbox.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <469D2688.7070000@kuehlbox.de> User-Agent: Mutt/1.4.2.3i Cc: attilio@freebsd.org, Jeff Roberson , current@freebsd.org Subject: Re: ULE/SCHED_SMP diff for 7.0 - panic on x86 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Jul 2007 22:13:33 -0000 On Tue, Jul 17, 2007 at 10:28:56PM +0200, Teufel wrote: > Hi, > > cvsuped kernel sources about 20 mins ago and applied Jeff's new ule patch. > System boots normaly up, but starting qemu with kqemu (either user or > user and kernel space) results immediatly in kernel trap 12 > applying Attilio's patch > http://people.freebsd.org/~attilio/kqemu.diff fixed the kernel trap, > but hangs: > > spin lock 0xc0bbf780 (shed lock 1) held by 0xc5114880 (tid 100003) too long > panic: spin lock held too long > cpuid = 0 this looks similar to what people are seeing on pointyhat building cluster. its definitely NOT related to kqemu desynced module/kernel. I have told attilio about it. no response yet... From owner-freebsd-current@FreeBSD.ORG Tue Jul 17 22:22:47 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 77E5D16A403 for ; Tue, 17 Jul 2007 22:22:47 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.224]) by mx1.freebsd.org (Postfix) with ESMTP id 3477513C4A3 for ; Tue, 17 Jul 2007 22:22:46 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by wr-out-0506.google.com with SMTP id i23so937996wra for ; Tue, 17 Jul 2007 15:22:46 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=PEcAo6TMZTgHcxZRICsL07n7tcJEh4u0IoJIT/lvLVazGRP8WnM+Wijdiwts+wdsF628NJmMNMxv8WRd/C9Aa2iNaKdXgl2ae4iKINPHYqJ/8qMVpGrPJwFN/XR2IP2KKRqbEiblLT4ZuJ36tAy6qMZu0HaTtj6ClgtZPrZOiFU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=n3lbVxd5mtH83fxcBiVMfttCURFN1cIknRzAe4DTAttetOrz27Bqxso4y0A+1iknGQsnAnz7e9p/Z/FNiQ1Gd7cZcfXG2XKKhwBVhxCoYHG9G5RMiADAuql/n+yUk6FD8rMFGzcruMnvQaDzGW25XyyVm00sa+X2KgCCE7Vnlek= Received: by 10.78.149.15 with SMTP id w15mr255307hud.1184710965098; Tue, 17 Jul 2007 15:22:45 -0700 (PDT) Received: by 10.78.120.9 with HTTP; Tue, 17 Jul 2007 15:22:45 -0700 (PDT) Message-ID: <3bbf2fe10707171522i3ddd07d0x543803f18892db27@mail.gmail.com> Date: Wed, 18 Jul 2007 00:22:45 +0200 From: "Attilio Rao" Sender: asmrookie@gmail.com To: "Roman Divacky" In-Reply-To: <20070717221327.GA60004@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070716233030.D92541@10.0.0.1> <469D2688.7070000@kuehlbox.de> <20070717221327.GA60004@freebsd.org> X-Google-Sender-Auth: 162b1a700836f279 Cc: Jeff Roberson , current@freebsd.org, Teufel Subject: Re: ULE/SCHED_SMP diff for 7.0 - panic on x86 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Jul 2007 22:22:47 -0000 2007/7/18, Roman Divacky : > On Tue, Jul 17, 2007 at 10:28:56PM +0200, Teufel wrote: > > Hi, > > > > cvsuped kernel sources about 20 mins ago and applied Jeff's new ule patch. > > System boots normaly up, but starting qemu with kqemu (either user or > > user and kernel space) results immediatly in kernel trap 12 > > applying Attilio's patch > > http://people.freebsd.org/~attilio/kqemu.diff fixed the kernel trap, > > but hangs: > > > > spin lock 0xc0bbf780 (shed lock 1) held by 0xc5114880 (tid 100003) too long > > panic: spin lock held too long > > cpuid = 0 > > this looks similar to what people are seeing on pointyhat building cluster. > > its definitely NOT related to kqemu desynced module/kernel. I have told attilio > about it. no response yet... After some speech it is sorted out Roman just confused and the bug he reported to me some weeks ago has nothing to do with this issue. I'm confident this is an ABI breakage due to KSE... Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Tue Jul 17 22:23:37 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1F82316A400; Tue, 17 Jul 2007 22:23:37 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from webaccess-cl.virtdom.com (webaccess-cl.virtdom.com [216.240.101.25]) by mx1.freebsd.org (Postfix) with ESMTP id DE41E13C478; Tue, 17 Jul 2007 22:23:36 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from [192.168.1.101] (c-71-231-138-78.hsd1.or.comcast.net [71.231.138.78]) (authenticated bits=0) by webaccess-cl.virtdom.com (8.13.6/8.13.6) with ESMTP id l6HMNY7O078644 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Tue, 17 Jul 2007 18:23:35 -0400 (EDT) (envelope-from jroberson@chesapeake.net) Date: Tue, 17 Jul 2007 15:26:41 -0700 (PDT) From: Jeff Roberson X-X-Sender: jroberson@10.0.0.1 To: Roman Divacky In-Reply-To: <20070717221327.GA60004@freebsd.org> Message-ID: <20070717152545.K92541@10.0.0.1> References: <20070716233030.D92541@10.0.0.1> <469D2688.7070000@kuehlbox.de> <20070717221327.GA60004@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: attilio@freebsd.org, current@freebsd.org, Teufel Subject: Re: ULE/SCHED_SMP diff for 7.0 - panic on x86 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Jul 2007 22:23:37 -0000 On Wed, 18 Jul 2007, Roman Divacky wrote: > On Tue, Jul 17, 2007 at 10:28:56PM +0200, Teufel wrote: >> Hi, >> >> cvsuped kernel sources about 20 mins ago and applied Jeff's new ule patch. >> System boots normaly up, but starting qemu with kqemu (either user or >> user and kernel space) results immediatly in kernel trap 12 >> applying Attilio's patch >> http://people.freebsd.org/~attilio/kqemu.diff fixed the kernel trap, >> but hangs: >> >> spin lock 0xc0bbf780 (shed lock 1) held by 0xc5114880 (tid 100003) too long >> panic: spin lock held too long >> cpuid = 0 > > this looks similar to what people are seeing on pointyhat building cluster. > > its definitely NOT related to kqemu desynced module/kernel. I have told attilio > about it. no response yet... > I see. The kqemu kernel module needs to be updated for 7.0. It locks sched_lock directly. This is no longer legal or valid. It is not holding the correct locks for ULE, only 4BSD. We will have to address this with the module author. Thanks, Jeff From owner-freebsd-current@FreeBSD.ORG Tue Jul 17 22:30:06 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1779916A40E for ; Tue, 17 Jul 2007 22:30:06 +0000 (UTC) (envelope-from yuri@darklight.org.ru) Received: from darklight.org.ru (darklight.org.ru [194.186.18.14]) by mx1.freebsd.org (Postfix) with ESMTP id C170A13C481 for ; Tue, 17 Jul 2007 22:30:04 +0000 (UTC) (envelope-from yuri@darklight.org.ru) Received: from darklight.org.ru (yuri@darklight.org.ru [127.0.0.1]) by darklight.org.ru (8.14.1/8.14.1) with ESMTP id l6HMEmeK003116 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Jul 2007 02:14:54 +0400 (MSD) (envelope-from yuri@darklight.org.ru) Received: (from yuri@localhost) by darklight.org.ru (8.14.1/8.14.1/Submit) id l6HMElBs003115; Wed, 18 Jul 2007 02:14:47 +0400 (MSD) (envelope-from yuri@darklight.org.ru) Date: Wed, 18 Jul 2007 02:14:47 +0400 From: Yuri Pankov To: Jack Vogel Message-ID: <20070717221447.GE1152@darklight.org.ru> References: <469CF9E5.2080200@omnisec.de> <2a41acea0707171412i64c337d7sce6698f86076a860@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="C+ts3FVlLX8+P6JN" Content-Disposition: inline In-Reply-To: <2a41acea0707171412i64c337d7sce6698f86076a860@mail.gmail.com> User-Agent: Mutt/1.5.16 (2007-06-09) X-Greylist: Sender is SPF-compliant, not delayed by milter-greylist-3.0 (darklight.org.ru [127.0.0.1]); Wed, 18 Jul 2007 02:14:55 +0400 (MSD) Cc: current@freebsd.org, Harald Schmalzbauer Subject: Re: ich9 ahci support? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2007 22:30:06 -0000 --C+ts3FVlLX8+P6JN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Jul 17, 2007 at 02:12:28PM -0700, Jack Vogel wrote: > On 7/17/07, Harald Schmalzbauer wrote: >> Hello, >> >> does anybody know if there's a difference in accessing ich8 vs. ich9? >> Is it enough to add ID bits to support it? > > I believe its just an ID kinda change, for my E1000 driver there are a few > other differences, but I assume you are talking chipset. > > If you google 'x86-ich9' you'll find a Linux patch that seems pretty much > device ID changes. I can get more detail if needed but just not right this > moment. > > Jack There's also open PR kern/114473. Yuri --C+ts3FVlLX8+P6JN Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQBGnT9XeoAklVFrLdgRAucEAJ97IkTjFQCv2kpaoXa6wOYg6fYN5QCgpMHp DpsIOlQ2UBfEWtReaml/caY= =zRF0 -----END PGP SIGNATURE----- --C+ts3FVlLX8+P6JN-- From owner-freebsd-current@FreeBSD.ORG Tue Jul 17 22:31:26 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 86C5F16A400 for ; Tue, 17 Jul 2007 22:31:26 +0000 (UTC) (envelope-from markhobden@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.229]) by mx1.freebsd.org (Postfix) with ESMTP id 4625513C48E for ; Tue, 17 Jul 2007 22:31:26 +0000 (UTC) (envelope-from markhobden@gmail.com) Received: by wx-out-0506.google.com with SMTP id i29so1389390wxd for ; Tue, 17 Jul 2007 15:31:25 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=qXakUDl8bYG7GOgQfixTjzajSOn9r05p9H6uv6oF3kB+Astp+CWLwNBtvTHt3vSuk7n2R04q1P0iYn29cMcw1j+XjCKt6egMX+l7tNQiT6GRbGNPkDVQp8vuusPrv8TfmXhumIb75MMTNC8wFgd2vjrbQchWDXr3fQkNgJrWZNA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=eIGyO70yi0xDE6p025eY/Ud6pwufzcztkuKIPVn0Wam3wCRhzDScoDF3V9qzF6nnfX+gQm+AdKuS6WP//1FR3SHBFBYNwB3CjlFjd1etzVFrXq4gdXKvCwzjr/qK/wrJEKKVhNXhixs47GKEiLfP+6PYAmNHHNeCnspqLm00ogA= Received: by 10.70.113.16 with SMTP id l16mr1434461wxc.1184709921004; Tue, 17 Jul 2007 15:05:21 -0700 (PDT) Received: by 10.90.92.20 with HTTP; Tue, 17 Jul 2007 15:05:20 -0700 (PDT) Message-ID: Date: Tue, 17 Jul 2007 23:05:20 +0100 From: "Mark Hobden" To: freebsd-usb@freebsd.org, freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Subject: uhidev(4) update - USB HID driver level for devices with multiple report ids X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Jul 2007 22:31:26 -0000 I have updated the uhidev(4) patch from NetBSD to apply to today's 7-CURRENT. http://www.terinea.co.uk/~mark/patches/uhidev-7-current-p2.diff The following patch is also required for Microsoft wireless keyboard/mice sets and Microsoft wireless notebook mice (but the uhidev patch to be applied first). http://www.terinea.co.uk/~mark/patches/uhidev-add-ms-p2.diff Versions that apply to 6-STABLE are available here: http://www.terinea.co.uk/~mark/patches/uhidev-6-stable-p2.diff http://www.terinea.co.uk/~mark/patches/uhidev-add-ms.diff Please let me know if you find any problems. -- Mark From owner-freebsd-current@FreeBSD.ORG Tue Jul 17 22:54:08 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2687816A401 for ; Tue, 17 Jul 2007 22:54:08 +0000 (UTC) (envelope-from bsd@kuehlbox.de) Received: from samael.qmail-ldap.de (mail.kuehlbox.de [62.159.47.22]) by mx1.freebsd.org (Postfix) with ESMTP id 2DBE313C48D for ; Tue, 17 Jul 2007 22:54:06 +0000 (UTC) (envelope-from bsd@kuehlbox.de) Received: (qmail 87007 invoked from network); 17 Jul 2007 22:54:05 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlbox.de; b=bj5v4lNgaHWgOR2G+6KQ30XYzPNAy7DDAPUBV2SYby9Y+yquEuUGWCnJ0gVmGn/6uysTp+iWlrVLaQOBEY2sJWob2DjiYu2kziUbK3tTKDGnB7oVmmKAjQzxMCTa8RXQ ; Received: from unknown (HELO [192.168.200.128]) (bsd@kuehlbox.de@[82.135.93.20]) (envelope-sender ) by samael.qmail-ldap.de (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 17 Jul 2007 22:54:04 -0000 Message-ID: <469D49C5.7030001@kuehlbox.de> Date: Wed, 18 Jul 2007 00:59:17 +0200 From: Teufel User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Jeff Roberson References: <20070716233030.D92541@10.0.0.1> <469D2688.7070000@kuehlbox.de> <20070717133131.J92541@10.0.0.1> <20070717134252.D92541@10.0.0.1> In-Reply-To: <20070717134252.D92541@10.0.0.1> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: ULE/SCHED_SMP diff for 7.0 - panic on x86 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Jul 2007 22:54:08 -0000 Hi Jeff, just recompiled the kernel with all debug flags (GENERIC default). Now I get a page fault instead of the spin lock timeout. However, it does not produce a dump for dumpon/savecore right now and I don't have serial cable handy. I will get a serial cable tomorrow to grap the db> output (hopefully). Or is there a way to put the screen output into a file? ldd on kqemu.ko doesn't output anything. However, when I recompile kqemu port with CFLAGS+= -DKSE it works then with a patched SHED_ULE (SHED_SMP). But thats not the point. Attilio provided a kqemu.diff that is supposed to let kqemu work without setting -DKSE. With the "old" SHED_ULE this patch worked well and does not crash (kqemu compiled without KSE). Expect the kqemu issue, "it works under x86". Greetings, Stephan Btw, qemu itself is linked as following: /usr/local/bin/qemu: libm.so.5 => /lib/libm.so.5 (0x28153000) libz.so.4 => /lib/libz.so.4 (0x28169000) libSDL.so.11 => /usr/local/lib/libSDL.so.11 (0x2817b000) libutil.so.7 => /lib/libutil.so.7 (0x281e1000) libthr.so.3 => /lib/libthr.so.3 (0x281ee000) libc.so.7 => /lib/libc.so.7 (0x28201000) libiconv.so.3 => /usr/local/lib/libiconv.so.3 (0x28303000) libX11.so.6 => /usr/local/lib/libX11.so.6 (0x283f1000) libXext.so.6 => /usr/local/lib/libXext.so.6 (0x284dd000) libXrandr.so.2 => /usr/local/lib/libXrandr.so.2 (0x284eb000) libXrender.so.1 => /usr/local/lib/libXrender.so.1 (0x284f2000) libvga.so.1 => /usr/local/lib/libvga.so.1 (0x284fa000) libvgl.so.5 => /usr/lib/libvgl.so.5 (0x28550000) libaa.so.1 => /usr/local/lib/libaa.so.1 (0x28558000) libusbhid.so.3 => /usr/lib/libusbhid.so.3 (0x2856f000) libXau.so.6 => /usr/local/lib/libXau.so.6 (0x28573000) libXdmcp.so.6 => /usr/local/lib/libXdmcp.so.6 (0x2857f000) librpcsvc.so.4 => /usr/lib/librpcsvc.so.4 (0x28584000) libncurses.so.7 => /lib/libncurses.so.7 (0x2858d000) Jeff Roberson wrote: >> Can you enable INVARIANTS, WITNESS, KDB and DDB in your kernel? Then >> get me a trace when this happens and any other consoles prints that >> look relevant. > > Can you also run ldd on the kqemu binary? I'd like to know if it's > linked against libthr or libkse. > From owner-freebsd-current@FreeBSD.ORG Wed Jul 18 00:08:56 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E842F16A408 for ; Wed, 18 Jul 2007 00:08:56 +0000 (UTC) (envelope-from davidch@broadcom.com) Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by mx1.freebsd.org (Postfix) with ESMTP id B872313C4AA for ; Wed, 18 Jul 2007 00:08:56 +0000 (UTC) (envelope-from davidch@broadcom.com) Received: from [10.10.64.154] by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.1)); Tue, 17 Jul 2007 16:54:39 -0700 X-Server-Uuid: 20144BB6-FB76-4F11-80B6-E6B2900CA0D7 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 724BC2AF; Tue, 17 Jul 2007 16:54:39 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 5F16A2AE for ; Tue, 17 Jul 2007 16:54:39 -0700 (PDT) Received: from mail-irva-12.broadcom.com (mail-irva-12.broadcom.com [10.10.64.146]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id FMC85759; Tue, 17 Jul 2007 16:54:39 -0700 (PDT) Received: from NT-IRVA-0750.brcm.ad.broadcom.com ( nt-irva-0750.brcm.ad.broadcom.com [10.8.194.64]) by mail-irva-12.broadcom.com (Postfix) with ESMTP id EDBAB69CA3 for ; Tue, 17 Jul 2007 16:54:38 -0700 (PDT) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 17 Jul 2007 16:54:31 -0700 Message-ID: <09BFF2FA5EAB4A45B6655E151BBDD9030483F161@NT-IRVA-0750.brcm.ad.broadcom.com> Thread-Topic: Getting/Forcing Greater than 4KB Buffer Allocations Thread-Index: AcfIzdFja2uG+YhIQwuaf0p7Ahjz3w== From: "David Christensen" To: current@freebsd.org X-WSS-ID: 6A8389353AC25689027-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Getting/Forcing Greater than 4KB Buffer Allocations X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Jul 2007 00:08:57 -0000 I'm investigating a problem with my bce driver which occurs when I ask for a jumbo mbuf cluster (through m_cljget()). When I map the memory for DMA I normally=20 get 3 memory segments (4KB + 4KB + 1KB) on my system, but on another user's=20 system he's seeing 2 memory segments (8KB + 1KB). Is there a configuration option that allows this or some other tuning variable involved? The system is a=20 Xeon dual-core processor and has 8GB of RAM, running an AMD64 version of the kernel. =20 Dave From owner-freebsd-current@FreeBSD.ORG Wed Jul 18 00:14:37 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9B7B616A401 for ; Wed, 18 Jul 2007 00:14:37 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by mx1.freebsd.org (Postfix) with ESMTP id 80DB213C491 for ; Wed, 18 Jul 2007 00:14:37 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from relay5.apple.com (relay5.apple.com [17.128.113.35]) by mail-out3.apple.com (Postfix) with ESMTP id 635D1C00664; Tue, 17 Jul 2007 17:14:37 -0700 (PDT) Received: from relay5.apple.com (unknown [127.0.0.1]) by relay5.apple.com (Symantec Mail Security) with ESMTP id 3F3D729C003; Tue, 17 Jul 2007 17:14:37 -0700 (PDT) X-AuditID: 11807123-a7f42bb000000b34-95-469d5b6d8290 Received: from [17.214.13.96] (cswiger1.apple.com [17.214.13.96]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by relay5.apple.com (Apple SCV relay) with ESMTP id 2B5E830400C; Tue, 17 Jul 2007 17:14:37 -0700 (PDT) In-Reply-To: <09BFF2FA5EAB4A45B6655E151BBDD9030483F161@NT-IRVA-0750.brcm.ad.broadcom.com> References: <09BFF2FA5EAB4A45B6655E151BBDD9030483F161@NT-IRVA-0750.brcm.ad.broadcom.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2E0C9A04-678B-4C44-9D2E-5500F2C08FE7@mac.com> Content-Transfer-Encoding: 7bit From: Chuck Swiger Date: Tue, 17 Jul 2007 17:14:36 -0700 To: David Christensen X-Mailer: Apple Mail (2.752.2) X-Brightmail-Tracker: AAAAAA== Cc: current@freebsd.org Subject: Re: Getting/Forcing Greater than 4KB Buffer Allocations X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Jul 2007 00:14:37 -0000 On Jul 17, 2007, at 4:54 PM, David Christensen wrote: > I'm investigating a problem with my bce driver which occurs when I ask > for a jumbo mbuf cluster (through m_cljget()). When I map the > memory for DMA I > normally get 3 memory segments (4KB + 4KB + 1KB) on my system, but > on another > user's system he's seeing 2 memory segments (8KB + 1KB). Is there a > configurationoption that allows this or some other tuning variable > involved? The > system is a Xeon dual-core processor and has 8GB of RAM, running an > AMD64 version of > the kernel. Hi, Dave-- Is "sysctl hw.pagesize" different on the two systems? It sure looks like the first machine is using a 4KB pagesize, whereas the second machine is using an 8KB pagesize... -- -Chuck From owner-freebsd-current@FreeBSD.ORG Wed Jul 18 00:15:06 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B4FBA16A401 for ; Wed, 18 Jul 2007 00:15:06 +0000 (UTC) (envelope-from h.schmalzbauer@omnisec.de) Received: from host.omnisec.de (host.omnisec.de [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id 16E6913C4BA for ; Wed, 18 Jul 2007 00:15:05 +0000 (UTC) (envelope-from h.schmalzbauer@omnisec.de) Received: from tek.flintsbach.schmalzbauer.de (tek.flintsbach.schmalzbauer.de [172.21.2.3]) by host.omnisec.de (8.13.8/8.13.8) with ESMTP id l6I0ARot096642 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 18 Jul 2007 02:10:33 +0200 (CEST) (envelope-from h.schmalzbauer@omnisec.de) Received: from titan.flintsbach.schmalzbauer.de (titan.flintsbach.schmalzbauer.de [IPv6:fec0::1:0:0:1:1]) by tek.flintsbach.schmalzbauer.de (8.13.8/8.13.8) with ESMTP id l6I0ExoU000164 for ; Wed, 18 Jul 2007 02:14:59 +0200 (CEST) (envelope-from h.schmalzbauer@omnisec.de) Received: by titan.flintsbach.schmalzbauer.de (8.14.1/8.14.1/Submit) id l6I0ARqK001852 for freebsd-current@freebsd.org; Wed, 18 Jul 2007 02:10:27 +0200 (CEST) (envelope-from h.schmalzbauer@omnisec.de) From: Harald Schmalzbauer Organization: OmniSEC To: freebsd-current@freebsd.org User-Agent: KMail/1.9.6 References: <200707131834.27131.h.schmalzbauer@omnisec.de> <200707132155.43783.h.schmalzbauer@omnisec.de> <4698E7C4.9080001@FreeBSD.org> In-Reply-To: <4698E7C4.9080001@FreeBSD.org> MIME-Version: 1.0 Content-Disposition: inline X-Length: 2418 X-UID: 7197 Date: Wed, 18 Jul 2007 02:10:26 +0200 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200707180210.27097.h.schmalzbauer@omnisec.de> Subject: Re: kqemu crash (page fault) with -current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2007 00:15:06 -0000 Am Samstag, 14. Juli 2007 schrieb Attilio Rao: > Harald Schmalzbauer wrote: > > Am Freitag, 13. Juli 2007 schrieb Attilio Rao: > >> Harald Schmalzbauer wrote: > >>> Hello, > >>> > >>> today I tried qemu for the first time and I love it. > >>> Now I'd need some speed and tried kqemu, but it immediately reboots my > >>> machine. > >>> Here is what I could transcribe: > >> > >> Could you please try this patch and see if it helps?: > >> http://people.freebsd.org/~attilio/kqemu.diff > > > > I applied it, rebuilt my kernel and kqemu, but machine crashes immedately > > after running qemu (without disabled kqemu). > > Should I also rebuild qemu itself? I don't think it's needed. > > But CFLAGS+= -DKSE helped! > > I could install various OS, only when I enable -kernel-kqemu most > > installer quit with page fault. > > Hello Harry, > could you please download again the patch and try again? > It seems I missed a bit... Sorry, haven't had any time yet, but now I could do a quick test. Looks good so far, no more panic with a nativ kqemu. > And, please, compile again qemu any time beacause I'm not sure how much > are exposed to userland "struct thread" and "struct proc", for this > problem. I compiled a -current kernel from today (with your new patch), recompiled kqemu and also qemu. But I can't guarantee the kernel module is used. My feeling ist that it's much slower than with my last tests (on that test setup I had always disabled all -current debuging (witness, malloc aj etc)) But it's just a "feeling", no values taken. Lack of time... Thank you very much for your help! best regards, -Harry From owner-freebsd-current@FreeBSD.ORG Wed Jul 18 00:20:30 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9C96A16A409 for ; Wed, 18 Jul 2007 00:20:30 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: from ik-out-1112.google.com (ik-out-1112.google.com [66.249.90.176]) by mx1.freebsd.org (Postfix) with ESMTP id 252E313C4C6 for ; Wed, 18 Jul 2007 00:20:29 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: by ik-out-1112.google.com with SMTP id c21so19693ika for ; Tue, 17 Jul 2007 17:20:28 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ZZ09Dl8K/ixliLRsJKz+z6QXniieBlhb1jiIk+CnApl175YmiE6TEqY8S+N4KzjNmoDaO2DJ42FLnAafZ0HPHaA9G0Lqx+1nieddcqyOBVJrsP3NvH0qRPcbSRD/smgply818Bolp4JlcHjXoCyxoCp+k+UTYuOnMenjQeumn9U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=LGIEbck3eWBCw61Y8KW0j3hVvOmVnsO6GWJGOhTUQinD8chCnSu0T5vpqkLFjtuT8av+5tPOXo1xhFEKFvr0Cgp9MVunXOneyqd7+XcZDnE7DjsnmUGRX6iI3B4Zh79gzMTVCJYbgPGwwnCPKLFW6LUilXrdiQs3Mnq0tqSk030= Received: by 10.78.149.15 with SMTP id w15mr284803hud.1184718028657; Tue, 17 Jul 2007 17:20:28 -0700 (PDT) Received: by 10.78.162.18 with HTTP; Tue, 17 Jul 2007 17:20:27 -0700 (PDT) Message-ID: Date: Tue, 17 Jul 2007 17:20:28 -0700 From: "Kip Macy" To: "David Christensen" In-Reply-To: <09BFF2FA5EAB4A45B6655E151BBDD9030483F161@NT-IRVA-0750.brcm.ad.broadcom.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <09BFF2FA5EAB4A45B6655E151BBDD9030483F161@NT-IRVA-0750.brcm.ad.broadcom.com> Cc: current@freebsd.org Subject: Re: Getting/Forcing Greater than 4KB Buffer Allocations X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Jul 2007 00:20:30 -0000 On 7/17/07, David Christensen wrote: > I'm investigating a problem with my bce driver which occurs when I ask > for a jumbo > mbuf cluster (through m_cljget()). When I map the memory for DMA I > normally > get 3 memory segments (4KB + 4KB + 1KB) on my system, but on another > user's > system he's seeing 2 memory segments (8KB + 1KB). Is there a > configuration > option that allows this or some other tuning variable involved? The > system is a > Xeon dual-core processor and has 8GB of RAM, running an AMD64 version of > the kernel. busdma coalesces the addresses into one segment if they're physically adjacent. Take a look at busdma_machdep.c. -Kip From owner-freebsd-current@FreeBSD.ORG Wed Jul 18 00:22:33 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2B29316A400 for ; Wed, 18 Jul 2007 00:22:33 +0000 (UTC) (envelope-from davidch@broadcom.com) Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by mx1.freebsd.org (Postfix) with ESMTP id 027EC13C49D for ; Wed, 18 Jul 2007 00:22:32 +0000 (UTC) (envelope-from davidch@broadcom.com) Received: from [10.10.64.154] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.1)); Tue, 17 Jul 2007 17:22:21 -0700 X-Server-Uuid: 6B5CFB92-F616-4477-B110-55F967A57302 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id CDEB72AF; Tue, 17 Jul 2007 17:22:21 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id B9CAC2AE; Tue, 17 Jul 2007 17:22:21 -0700 (PDT) Received: from mail-irva-12.broadcom.com (mail-irva-12.broadcom.com [10.10.64.146]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id FMC91037; Tue, 17 Jul 2007 17:22:21 -0700 (PDT) Received: from NT-IRVA-0750.brcm.ad.broadcom.com ( nt-irva-0750.brcm.ad.broadcom.com [10.8.194.64]) by mail-irva-12.broadcom.com (Postfix) with ESMTP id 5747869CA4; Tue, 17 Jul 2007 17:22:21 -0700 (PDT) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 17 Jul 2007 17:22:17 -0700 Message-ID: <09BFF2FA5EAB4A45B6655E151BBDD9030483F17F@NT-IRVA-0750.brcm.ad.broadcom.com> In-Reply-To: <2E0C9A04-678B-4C44-9D2E-5500F2C08FE7@mac.com> Thread-Topic: Getting/Forcing Greater than 4KB Buffer Allocations Thread-Index: AcfI0KmJUoA0MDVZTse/aR62BFIKAwAAJm+A References: <09BFF2FA5EAB4A45B6655E151BBDD9030483F161@NT-IRVA-0750.brcm.ad.broadcom.com> <2E0C9A04-678B-4C44-9D2E-5500F2C08FE7@mac.com> From: "David Christensen" To: "Chuck Swiger" X-WSS-ID: 6A8382B71S86947261-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: current@freebsd.org Subject: RE: Getting/Forcing Greater than 4KB Buffer Allocations X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Jul 2007 00:22:33 -0000 > > I'm investigating a problem with my bce driver which occurs=20 > when I ask > > for a jumbo mbuf cluster (through m_cljget()). When I map the =20 > > memory for DMA I > > normally get 3 memory segments (4KB + 4KB + 1KB) on my system, but =20 > > on another > > user's system he's seeing 2 memory segments (8KB + 1KB). Is there a > > configurationoption that allows this or some other tuning variable =20 > > involved? The > > system is a Xeon dual-core processor and has 8GB of RAM,=20 > running an =20 > > AMD64 version of > > the kernel. >=20 > Hi, Dave-- >=20 > Is "sysctl hw.pagesize" different on the two systems? It sure looks =20 > like the first machine is using a 4KB pagesize, whereas the second =20 > machine is using an 8KB pagesize... >=20 That was one of my first questions but they are identical, 4096 bytes. Dave From owner-freebsd-current@FreeBSD.ORG Wed Jul 18 00:23:46 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DDA1B16A401 for ; Wed, 18 Jul 2007 00:23:46 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.225]) by mx1.freebsd.org (Postfix) with ESMTP id 9358613C471 for ; Wed, 18 Jul 2007 00:23:46 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: by wr-out-0506.google.com with SMTP id 67so13957wri for ; Tue, 17 Jul 2007 17:23:46 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Y8fCwifBHLrQTFO1c4r+fFLpsRkeyjkad0umSRm8EWvaXIcUOJUbMEebGHgkkEkkSrn/6qHz7bwwQ9RzSnrnm1agLSZzWw1/Eh0G/m+tULGwcv0bNT12boouFEod8Ei52FHYxlJ12h/h41cOFR9nKa3s3cthRWcedwWqRw4wXYc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=p0PmpJqat1GasBC2Xc7KnT12XxBNlpgz1Kgz0PBWWlCXuDwUJRnXAmXBgfFohgeP41FJajBOkCYr3glsls86tHB5U7wakv42z6HAsq3JuqQ+rV1BeJuFzsaLJ2OlftZovpC6s/Rx+tU3EcE2zhGLdCyaUYiAWZGsZD1fZO0S1P8= Received: by 10.78.150.7 with SMTP id x7mr286838hud.1184718224912; Tue, 17 Jul 2007 17:23:44 -0700 (PDT) Received: by 10.78.162.18 with HTTP; Tue, 17 Jul 2007 17:23:44 -0700 (PDT) Message-ID: Date: Tue, 17 Jul 2007 17:23:44 -0700 From: "Kip Macy" To: "Chuck Swiger" In-Reply-To: <2E0C9A04-678B-4C44-9D2E-5500F2C08FE7@mac.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <09BFF2FA5EAB4A45B6655E151BBDD9030483F161@NT-IRVA-0750.brcm.ad.broadcom.com> <2E0C9A04-678B-4C44-9D2E-5500F2C08FE7@mac.com> Cc: David Christensen , current@freebsd.org Subject: Re: Getting/Forcing Greater than 4KB Buffer Allocations X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Jul 2007 00:23:46 -0000 > Is "sysctl hw.pagesize" different on the two systems? It sure looks > like the first machine is using a 4KB pagesize, whereas the second > machine is using an 8KB pagesize... There is no such thing as 8k physical pages on ia32 or x86_64. -Kip From owner-freebsd-current@FreeBSD.ORG Wed Jul 18 00:40:20 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8337E16A401 for ; Wed, 18 Jul 2007 00:40:20 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from webaccess-cl.virtdom.com (webaccess-cl.virtdom.com [216.240.101.25]) by mx1.freebsd.org (Postfix) with ESMTP id 4D90C13C48D for ; Wed, 18 Jul 2007 00:40:20 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from [192.168.1.101] (c-71-231-138-78.hsd1.or.comcast.net [71.231.138.78]) (authenticated bits=0) by webaccess-cl.virtdom.com (8.13.6/8.13.6) with ESMTP id l6I0eGNi007409 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Tue, 17 Jul 2007 20:40:17 -0400 (EDT) (envelope-from jroberson@chesapeake.net) Date: Tue, 17 Jul 2007 17:43:23 -0700 (PDT) From: Jeff Roberson X-X-Sender: jroberson@10.0.0.1 To: Kip Macy In-Reply-To: Message-ID: <20070717174210.N92541@10.0.0.1> References: <09BFF2FA5EAB4A45B6655E151BBDD9030483F161@NT-IRVA-0750.brcm.ad.broadcom.com> <2E0C9A04-678B-4C44-9D2E-5500F2C08FE7@mac.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: David Christensen , current@freebsd.org Subject: Re: Getting/Forcing Greater than 4KB Buffer Allocations X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Jul 2007 00:40:20 -0000 On Tue, 17 Jul 2007, Kip Macy wrote: >> Is "sysctl hw.pagesize" different on the two systems? It sure looks >> like the first machine is using a 4KB pagesize, whereas the second >> machine is using an 8KB pagesize... > > There is no such thing as 8k physical pages on ia32 or x86_64. I actually made a patch for Isilon that makes an 8k virtual page size. It helps with issues like this and reduces the size of the page array and the number of entities that the page cache is manging. It is binary compatible with user-space although it introduces some complexity into the VM system. Jeff > > -Kip > _______________________________________________ > 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 Jul 18 00:45:32 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C78E316A403 for ; Wed, 18 Jul 2007 00:45:32 +0000 (UTC) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (gate.funkthat.com [69.17.45.168]) by mx1.freebsd.org (Postfix) with ESMTP id A12C913C48D for ; Wed, 18 Jul 2007 00:45:32 +0000 (UTC) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (830ozgmv7nop099v@localhost.funkthat.com [127.0.0.1]) by hydrogen.funkthat.com (8.13.6/8.13.3) with ESMTP id l6I0jVaM090532; Tue, 17 Jul 2007 17:45:31 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.13.6/8.13.3/Submit) id l6I0jVW9090531; Tue, 17 Jul 2007 17:45:31 -0700 (PDT) (envelope-from jmg) Date: Tue, 17 Jul 2007 17:45:30 -0700 From: John-Mark Gurney To: David Christensen Message-ID: <20070718004530.GV1221@funkthat.com> Mail-Followup-To: David Christensen , current@freebsd.org References: <09BFF2FA5EAB4A45B6655E151BBDD9030483F161@NT-IRVA-0750.brcm.ad.broadcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <09BFF2FA5EAB4A45B6655E151BBDD9030483F161@NT-IRVA-0750.brcm.ad.broadcom.com> User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 5.4-RELEASE-p6 i386 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html Cc: current@freebsd.org Subject: Re: Getting/Forcing Greater than 4KB Buffer Allocations X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: John-Mark Gurney List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2007 00:45:32 -0000 David Christensen wrote this message on Tue, Jul 17, 2007 at 16:54 -0700: > I'm investigating a problem with my bce driver which occurs when I ask > for a jumbo > mbuf cluster (through m_cljget()). When I map the memory for DMA I > normally > get 3 memory segments (4KB + 4KB + 1KB) on my system, but on another > user's > system he's seeing 2 memory segments (8KB + 1KB). Is there a > configuration > option that allows this or some other tuning variable involved? The > system is a > Xeon dual-core processor and has 8GB of RAM, running an AMD64 version of > the kernel. Is this an issue? If it is, you need to fix your bus_dma_tag_create calls to set the segment size and count properly. bus_dma will get you exactly what you ask for, and your driver needs to tell bus_dma what it can and cannot handle. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-current@FreeBSD.ORG Wed Jul 18 00:56:19 2007 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 07FE216A402 for ; Wed, 18 Jul 2007 00:56:19 +0000 (UTC) (envelope-from rpaulo@fnop.net) Received: from core.fnop.net (mx.fnop.net [82.102.11.82]) by mx1.freebsd.org (Postfix) with ESMTP id BCAA813C4BC for ; Wed, 18 Jul 2007 00:56:18 +0000 (UTC) (envelope-from rpaulo@fnop.net) Received: from core.fnop.net (mx.fnop.net [82.102.11.82]) by core.fnop.net (Postfix) with ESMTP id 77D9B690D74 for ; Wed, 18 Jul 2007 01:50:24 +0100 (WEST) Received: by core.fnop.net (Postfix, from userid 1015) id 31D70690D8E; Wed, 18 Jul 2007 01:50:24 +0100 (WEST) X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on core.fnop.net X-Spam-Level: X-Spam-Status: No, score=-0.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO, RCVD_IN_NJABL_DUL autolearn=no version=3.1.7 Received: from epsilon.local (88.210.115.143.rev.optimus.pt [88.210.115.143]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by core.fnop.net (Postfix) with ESMTP id 745A0690D74 for ; Wed, 18 Jul 2007 01:50:21 +0100 (WEST) Message-ID: <469D651C.6080504@fnop.net> Date: Wed, 18 Jul 2007 01:55:56 +0100 From: Rui Paulo User-Agent: Thunderbird 2.0.0.4 (X11/20070704) MIME-Version: 1.0 To: current@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: Subject: less -r broken with long lines X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Jul 2007 00:56:19 -0000 Hi, There's something about how the new less version handles lines greater than the virtual terminal's size. Test case on an xterm/rxvt/screen session: less -r /etc/syslog.conf - you won't see the $FreeBSD$ id tag because of the long line regarding to /var/log/messages. Try resizing your terminal so that this line fits in the right number of columns. You'll see the problem disappear. less -r /etc/rc.firewall - since there are no long lines in the first page, you won't notice the problem Everything works fine if less is used without the -r argument or if less is run from the console. Does this ring any bell to anyone? Regards. -- Rui Paulo From owner-freebsd-current@FreeBSD.ORG Wed Jul 18 01:28:33 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 57B4A16A400 for ; Wed, 18 Jul 2007 01:28:33 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from webaccess-cl.virtdom.com (webaccess-cl.virtdom.com [216.240.101.25]) by mx1.freebsd.org (Postfix) with ESMTP id 2682C13C49D for ; Wed, 18 Jul 2007 01:28:33 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from [192.168.1.101] (c-71-231-138-78.hsd1.or.comcast.net [71.231.138.78]) (authenticated bits=0) by webaccess-cl.virtdom.com (8.13.6/8.13.6) with ESMTP id l6I1SUkk017551 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO) for ; Tue, 17 Jul 2007 21:28:32 -0400 (EDT) (envelope-from jroberson@chesapeake.net) Date: Tue, 17 Jul 2007 18:31:37 -0700 (PDT) From: Jeff Roberson X-X-Sender: jroberson@10.0.0.1 To: current@freebsd.org Message-ID: <20070717182819.L92541@10.0.0.1> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Subject: cvs commit: src/sys/kern sched_ule.c (fwd) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Jul 2007 01:28:33 -0000 Thanks everyone for your help. In summary it sounds like there are two issues. 1) kqemu explicitly uses sched_lock. I'll see if I can contact the author about fixing this. 2) As much as a 6-7% slowdown on buildworld on dual core machines as compared to 4BSD. I'm not sure if I'm going to do anything about this. Once you get to 4 or 8 cores and -j8 or more they even out with ULE having significantly less system time. I don't know if I want to compromise that for slightly better dual core compile times. This is in the tree for 7.0 now though. I'm very excited to see this happen. Thanks again, Jeff ---------- Forwarded message ---------- Date: Tue, 17 Jul 2007 22:53:24 +0000 (UTC) From: Jeff Roberson To: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org Subject: cvs commit: src/sys/kern sched_ule.c jeff 2007-07-17 22:53:24 UTC FreeBSD src repository Modified files: sys/kern sched_ule.c Log: ULE 3.0: Fine grain scheduler locking and affinity improvements. This has been in development for over 6 months as SCHED_SMP. - Implement one spin lock per thread-queue. Threads assigned to a run-queue point to this lock via td_lock. - Improve the facility for assigning threads to CPUs now that sched_lock contention no longer dominates scheduling decisions on larger SMP machines. - Re-write idle time stealing in an attempt to make it less damaging to general performance. This is still disabled by default. See kern.sched.steal_idle. - Call the long-term load balancer from a callout rather than sched_clock() so there are no locks held. This is disabled by default. See kern.sched.balance. - Parameterize many scheduling decisions via sysctls. Try to document these via sysctl descriptions. - General structural and naming cleanups. - Document each function with comments. Tested by: current@ amd64, x86, UP, SMP. Approved by: re Revision Changes Path 1.200 +917 -549 src/sys/kern/sched_ule.c From owner-freebsd-current@FreeBSD.ORG Wed Jul 18 01:30:56 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8DDA816A407 for ; Wed, 18 Jul 2007 01:30:56 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [210.51.165.229]) by mx1.freebsd.org (Postfix) with ESMTP id 4318D13C4BA for ; Wed, 18 Jul 2007 01:30:56 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from localhost (tarsier.geekcn.org [210.51.165.229]) by tarsier.geekcn.org (Postfix) with ESMTP id 5B7CBEB0C87; Wed, 18 Jul 2007 09:30:55 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([210.51.165.229]) by localhost (mail.geekcn.org [210.51.165.229]) (amavisd-new, port 10024) with ESMTP id ahx67l43EEhA; Wed, 18 Jul 2007 09:30:52 +0800 (CST) Received: from LI-Xins-MacBook.local (sina152-194.staff.sina.com.cn [61.135.152.194]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id 98B73EB0B8D; Wed, 18 Jul 2007 09:30:50 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:cc:subject:references:in-reply-to: x-enigmail-version:openpgp:content-type; b=pY/RNeqVf45Z8SA1VdD8hdLa+TE4/BdVFO/fl6tnIVw35zaZPSEiKNPNyGIoJxP3j X8fwIPHPIUkqQ16EHrmYw== Message-ID: <469D6D3A.6070408@delphij.net> Date: Wed, 18 Jul 2007 09:30:34 +0800 From: LI Xin Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: Rui Paulo References: <469D651C.6080504@fnop.net> In-Reply-To: <469D651C.6080504@fnop.net> X-Enigmail-Version: 0.95.2 OpenPGP: url=http://www.delphij.net/delphij.asc Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig47D47AA9BE708676E0CF3256" Cc: current@freebsd.org Subject: Re: less -r broken with long lines X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2007 01:30:56 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig47D47AA9BE708676E0CF3256 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Hi, Rui Paulo wrote: > Hi, > There's something about how the new less version handles lines greater > than the virtual terminal's size. >=20 > Test case on an xterm/rxvt/screen session: >=20 > less -r /etc/syslog.conf - you won't see the $FreeBSD$ id tag because > of the long line regarding to /var/log/messages. Try resizing your > terminal so that this line fits in the right number of columns. You'll > see the problem disappear. >=20 > less -r /etc/rc.firewall - since there are no long lines in the first > page, you won't notice the problem >=20 > Everything works fine if less is used without the -r argument or if les= s > is run from the console. >=20 > Does this ring any bell to anyone? Are you sure that this is not expected behavior? I have tried less v394 on a 6.2-RELEASE box and it seems that the behavior is the same... Cheers, --=20 Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! --------------enig47D47AA9BE708676E0CF3256 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGnW07OfuToMruuMARCkKKAJwI4gcNaS6lfnJdV3kpPHXowLakXwCfZ017 9Yt02WsFQYSA9koh2RQGiDc= =DUxL -----END PGP SIGNATURE----- --------------enig47D47AA9BE708676E0CF3256-- From owner-freebsd-current@FreeBSD.ORG Wed Jul 18 02:18:48 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 30FC116A401 for ; Wed, 18 Jul 2007 02:18:48 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.236]) by mx1.freebsd.org (Postfix) with ESMTP id DD33B13C4B2 for ; Wed, 18 Jul 2007 02:18:47 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by nz-out-0506.google.com with SMTP id l8so30688nzf for ; Tue, 17 Jul 2007 19:18:47 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:received:received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=PlGBKiDxSBYvrcYRJt/khq/2zrbVagfzSbK5mk4xAGg1P503foORBRfwYr/3MsUkK9HU3N52zqq30xqt+W5h2UUp1f/UtAKPkXZJAS2T0qd2antiArCepGUS3Ot4ldSY44HypTBFZgkKKDd98c4DC4hU0GBN9GsKXL1SRYz1TL4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=KX7XrGEam/b8KftpAeVPGlZNtY+E466CrUWwMScIV9xq9B6O7kqgi0arKw01WOoHizgKhT49IhtqkRvZ6aNWllL4iBn2QR/D/omZiKHsUvXQjWwSSe73PQ1vMFjcMOuhq0UA2+EnFtDERsIy/3UStJPQBzWsYugLWRJW19qRYzI= Received: by 10.115.16.1 with SMTP id t1mr983592wai.1184725126203; Tue, 17 Jul 2007 19:18:46 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTPS id l23sm499532waf.2007.07.17.19.18.43 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 17 Jul 2007 19:18:45 -0700 (PDT) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id l6I2IeAV038434 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Jul 2007 11:18:40 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id l6I2IdBH038433; Wed, 18 Jul 2007 11:18:39 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Wed, 18 Jul 2007 11:18:39 +0900 From: Pyun YongHyeon To: David Christensen Message-ID: <20070718021839.GA37935@cdnetworks.co.kr> References: <09BFF2FA5EAB4A45B6655E151BBDD9030483F161@NT-IRVA-0750.brcm.ad.broadcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <09BFF2FA5EAB4A45B6655E151BBDD9030483F161@NT-IRVA-0750.brcm.ad.broadcom.com> User-Agent: Mutt/1.4.2.1i Cc: current@freebsd.org Subject: Re: Getting/Forcing Greater than 4KB Buffer Allocations X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2007 02:18:48 -0000 On Tue, Jul 17, 2007 at 04:54:31PM -0700, David Christensen wrote: > I'm investigating a problem with my bce driver which occurs when I ask > for a jumbo > mbuf cluster (through m_cljget()). When I map the memory for DMA I > normally > get 3 memory segments (4KB + 4KB + 1KB) on my system, but on another > user's > system he's seeing 2 memory segments (8KB + 1KB). Is there a > configuration > option that allows this or some other tuning variable involved? The > system is a > Xeon dual-core processor and has 8GB of RAM, running an AMD64 version of > the kernel. > I've briefly looked over bus_dma usage on bce(4). It seems that you told bus_dma the the dma map could be made up of BCE_MAX_SEGMENTS segments, where a dma segment could be MJUM9BYTES bytes. If you want just two segments you may have to use 2 instead of BCE_MAX_SEGMENTS. If the hardware can support up to BCE_MAX_SEGMENTS dma segments on Rx descriptors you should be prepared to handle that number of dma segments too(e.g. You don't know how may dma segments would be returned by bus_dma, you just know the upper bound as you specified in bus_dma_tag_create()). If the hardware can handle just up to 4KB for a dma segment you should tell bus_dma the restriction of the dma segment. If you have to get a single dma segment that covers MJUM9BYTES bytes due to the limitation of the hardware you may have to use local allocator. -- Regards, Pyun YongHyeon From owner-freebsd-current@FreeBSD.ORG Wed Jul 18 02:39:44 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C9DDC16A400 for ; Wed, 18 Jul 2007 02:39:44 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id DAA6E13C4DD for ; Wed, 18 Jul 2007 02:39:43 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.13.8/8.13.8) with ESMTP id l6I2dhTk026371 for ; Tue, 17 Jul 2007 22:39:43 -0400 (EDT) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.8/8.13.3) with ESMTP id l6I2dgD1010356 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 17 Jul 2007 22:39:42 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <200707180239.l6I2dgD1010356@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 17 Jul 2007 22:39:22 -0400 To: freebsd-current@freebsd.org From: Mike Tancsa Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: chelsio driver and Myricom driver X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2007 02:39:44 -0000 Hi, I am trying to run a recent current with the Chelsio 10GigE card below and it tries to load but has the following complaint. cxgbc0: mem 0xe0201000-0xe0201fff,0xe0800000-0xe0ffffff,0xe0200000-0xe0200fff irq 16 at device 0.0 on pci10 cxgbc0: found wrong FW version (4.0), driver needs version 4.5 cxgbc0: firmware needs to be updated to version 4.5.0 cxgbc0: found wrong TP version (0.0), driver needs version 1.1 cxgbc0: SRAM needs to be updated to version b-1.1.0 cxgb0: on cxgbc0 cxgb0: Ethernet address: 00:07:43:04:01:2c Where do I get the firmware from ? The website only has 4.3 ? Also, how do I update the SRAM. Sorry if these are obvious questions, but I am new to CURRENT with such drivers. I have the driver compiled into the kernel With the Myricom, it seems to work, but it doesnt detect the cx4 media type for some reason. # ifconfig mxge0 mxge0: flags=8843 metric 0 mtu 9000 options=1bb ether 00:60:dd:47:c6:c4 inet 192.168.10.3 netmask 0xffffff00 broadcast 192.168.10.255 media: (autoselect ) status: active The port is up and I can ping across it so it is working. TenGigabitEthernet2/3 is up, line protocol is up (connected) Hardware is C6k 10000Mb 802.3, address is 0018.bab0.2036 (bia 0018.bab0.2036) Description: leopard3 mxge0 MTU 1500 bytes, BW 10000000 Kbit, DLY 10 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation ARPA, loopback not set Full-duplex, 10Gb/s input flow-control is off, output flow-control is on ARP type: ARPA, ARP Timeout 04:00:00 Last input never, output 00:00:55, output hang never Last clearing of "show interface" counters never Input queue: 0/2000/0/0 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: fifo Output queue: 0/40 (size/max) 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec 8 packets input, 588 bytes, 0 no buffer Received 5 broadcasts, 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored 0 input packets with dribble condition detected 403 packets output, 30468 bytes, 0 underruns 0 output errors, 0 collisions, 1 interface resets 0 babbles, 0 late collision, 0 deferred 0 lost carrier, 0 no carrier 0 output buffer failures, 0 output buffers swapped out ---Mike -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike From owner-freebsd-current@FreeBSD.ORG Wed Jul 18 02:40:07 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 40AD316A400 for ; Wed, 18 Jul 2007 02:40:07 +0000 (UTC) (envelope-from taku@tackymt.homeip.net) Received: from basalt.tackymt.homeip.net (124x38x115x218.ap124.ftth.ucom.ne.jp [124.38.115.218]) by mx1.freebsd.org (Postfix) with ESMTP id 0F8C513C4AA for ; Wed, 18 Jul 2007 02:40:07 +0000 (UTC) (envelope-from taku@tackymt.homeip.net) Received: from localhost (localhost [127.0.0.1]) by basalt.tackymt.homeip.net (Postfix) with ESMTP id 2F2D71074A for ; Wed, 18 Jul 2007 11:19:33 +0900 (JST) Received: from basalt.tackymt.homeip.net ([127.0.0.1]) by localhost (basalt.tackymt.homeip.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 38801-04 for ; Wed, 18 Jul 2007 11:19:31 +0900 (JST) Received: from biotite (unknown [IPv6:2001:3e0:577:0:216:cfff:febc:1472]) by basalt.tackymt.homeip.net (Postfix) with ESMTP for ; Wed, 18 Jul 2007 11:19:31 +0900 (JST) Date: Wed, 18 Jul 2007 11:19:29 +0900 From: "YAMAMOTO, Taku" To: freebsd-current@freebsd.org Message-Id: <20070718111929.22bf3eb3.taku@tackymt.homeip.net> Organization: Trans New Technology, Inc. X-Mailer: Sylpheed 2.4.2 (GTK+ 2.10.13; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Multipart=_Wed__18_Jul_2007_11_19_29_+0900_.ymyF06wih.tOSV3" X-Virus-Scanned: amavisd-new at tackymt.homeip.net Subject: critical_exit(), td_owepreempt and SW_PREEMPT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Jul 2007 02:40:07 -0000 This is a multi-part message in MIME format. --Multipart=_Wed__18_Jul_2007_11_19_29_+0900_.ymyF06wih.tOSV3 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Greetings, I had found that critical_exit() calls mi_switch() without SW_PREEMPT when td_owepreempt is set. Should the first argument at that line be SW_INVOL|SW_PREEMPT? -- YAMAMOTO, Taku --Multipart=_Wed__18_Jul_2007_11_19_29_+0900_.ymyF06wih.tOSV3 Content-Type: text/x-diff; name="critical_exit.diff" Content-Disposition: attachment; filename="critical_exit.diff" Content-Transfer-Encoding: 7bit --- sys/kern/kern_switch.c.orig 2007-06-13 04:50:31.000000000 +0900 +++ sys/kern/kern_switch.c 2007-07-18 10:21:09.000000000 +0900 @@ -192,7 +192,7 @@ critical_exit(void) thread_lock(td); td->td_critnest--; SCHED_STAT_INC(switch_owepreempt); - mi_switch(SW_INVOL, NULL); + mi_switch(SW_INVOL|SW_PREEMPT, NULL); thread_unlock(td); } } else --Multipart=_Wed__18_Jul_2007_11_19_29_+0900_.ymyF06wih.tOSV3-- From owner-freebsd-current@FreeBSD.ORG Wed Jul 18 03:39:54 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5648F16A400 for ; Wed, 18 Jul 2007 03:39:54 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from webaccess-cl.virtdom.com (webaccess-cl.virtdom.com [216.240.101.25]) by mx1.freebsd.org (Postfix) with ESMTP id 0C15D13C481 for ; Wed, 18 Jul 2007 03:39:53 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from [192.168.1.101] (c-71-231-138-78.hsd1.or.comcast.net [71.231.138.78]) (authenticated bits=0) by webaccess-cl.virtdom.com (8.13.6/8.13.6) with ESMTP id l6I3dpwe041304 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Tue, 17 Jul 2007 23:39:53 -0400 (EDT) (envelope-from jroberson@chesapeake.net) Date: Tue, 17 Jul 2007 20:43:08 -0700 (PDT) From: Jeff Roberson X-X-Sender: jroberson@10.0.0.1 To: "YAMAMOTO, Taku" In-Reply-To: <20070718111929.22bf3eb3.taku@tackymt.homeip.net> Message-ID: <20070717204222.I561@10.0.0.1> References: <20070718111929.22bf3eb3.taku@tackymt.homeip.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: critical_exit(), td_owepreempt and SW_PREEMPT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Jul 2007 03:39:54 -0000 On Wed, 18 Jul 2007, YAMAMOTO, Taku wrote: > Greetings, > > I had found that critical_exit() calls mi_switch() without SW_PREEMPT > when td_owepreempt is set. > > Should the first argument at that line be SW_INVOL|SW_PREEMPT? Yes, you're right. I'll test later and see how this effects perf. It might be an improvement although in most cases there isn't very much preempting going on. Thanks, Jeff > > > -- > YAMAMOTO, Taku > From owner-freebsd-current@FreeBSD.ORG Wed Jul 18 04:12:06 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C64F516A402 for ; Wed, 18 Jul 2007 04:12:06 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.177]) by mx1.freebsd.org (Postfix) with ESMTP id 976E013C4A6 for ; Wed, 18 Jul 2007 04:12:06 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by wa-out-1112.google.com with SMTP id j37so83693waf for ; Tue, 17 Jul 2007 21:12:06 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:received:received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=rLW3VBIdiTDEgWX3K2jWMSiIRslVnoX3+z0KskX+WHqylWxuxu1JFmtJ1RzAFWfYa8ZfkPl+KmrA2ZEACqUI7ahJiyxrbMcnHnSO2em5UMq88jkCVnoeoZFvjfiaUUNZ20Y1x3QOTN+EhM917v9eUdpoMbp8pKcPybc89sqZakg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=ra0xnfApl5cVP8NZkKdVzrfZGCFlNLnDQE8kLoxinikTmXqXY30PmnNZVDl4ovMx2Reb1wqmStCAqUyrTv+VqYov7XhuxfV6smSJr6yzUNBcp51phqxmw8odjxGDf3PWqxtcG9sluxl1BJUIreMK8gZqJ60/UT5bEDlBupsT7to= Received: by 10.114.170.1 with SMTP id s1mr1090459wae.1184731926195; Tue, 17 Jul 2007 21:12:06 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTPS id v35sm643114wah.2007.07.17.21.12.03 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 17 Jul 2007 21:12:05 -0700 (PDT) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id l6I4C1Mc039038 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Jul 2007 13:12:01 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id l6I4Bx94039037; Wed, 18 Jul 2007 13:11:59 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Wed, 18 Jul 2007 13:11:59 +0900 From: Pyun YongHyeon To: St?le Kristoffersen Message-ID: <20070718041159.GC37935@cdnetworks.co.kr> References: <20070716190441.GA19282@eschew.pusen.org> <20070716213425.GB19282@eschew.pusen.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070716213425.GB19282@eschew.pusen.org> User-Agent: Mutt/1.4.2.1i Cc: Kip Macy , current@freebsd.org Subject: Re: Slow networkperformance in current? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2007 04:12:06 -0000 On Mon, Jul 16, 2007 at 11:34:25PM +0200, St?le Kristoffersen wrote: > On 2007-07-16 at 12:47, Kip Macy wrote: > > 10 GigE cards are doing line rate - over time the cpu usage required > > to do so is going down. Your experience is probably due to NIC issues. > > What kind of NIC are you using? And have you changed any configuration > > or settings? > > I was thinking of the NIC, thats why I tried it on localhost (bypassing the > NIC(?)). > I'm using a re-nick: > re0: port 0x7e00-0x7eff mem > 0xfd3ff000-0xfd3fffff irq 18 at device 0.0 on pci3 > I'm not sure it's directly related with re(4) but try overhauled re(4). http://people.freebsd.org/~yongari/re.HEAD.patch It seems that you also have PCIe based NIC. Try MSI patch for re(4) in addition to above one. > I have not changed anything, except upgrading the world + kernel. No > hardware was added, no bios-settings where changed. The only thing I can > think of is that I might have changed a sysctl a long time ago that boosted > my performance, and that change have been lost after the reboot. > > -- > St?le Kristoffersen > staalebk@ifi.uio.no -- Regards, Pyun YongHyeon From owner-freebsd-current@FreeBSD.ORG Wed Jul 18 04:27:47 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A153116A402 for ; Wed, 18 Jul 2007 04:27:47 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.168]) by mx1.freebsd.org (Postfix) with ESMTP id 2A98313C4AC for ; Wed, 18 Jul 2007 04:27:41 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: by ug-out-1314.google.com with SMTP id o4so269880uge for ; Tue, 17 Jul 2007 21:27:41 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=VH2G44XHB0LTmXjRSAsd7ibAPiH/nZeNd7oDHSwRswXCJ/NJzsAgHS6HKUcqiog9F5kGmUJAJrT69kKRfubvaVc+l3CHdhdawDG4ndKMcAkqSCaK4hqPf7GC3f/gu0kvO/OoYBs6qqpvoKZjNUH3B2JWjcVhnT7iBbD8aZkG24U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=CZBn5eVRBv7oqjuONfS32ndvNSQdl8NKVdPekKWWrecav+NkEeC6y1PeL9SgRJaCRFXTQZp0p60y0z89VOxs7b9umF++M8uBhPyWLKxkYaHrotUfv5YQyUOMrp1HykdfrNp1/WEQxFQARVYaRhlgpLUCDS8wwwInncKTFqNGwio= Received: by 10.78.140.17 with SMTP id n17mr325881hud.1184732860549; Tue, 17 Jul 2007 21:27:40 -0700 (PDT) Received: by 10.78.162.18 with HTTP; Tue, 17 Jul 2007 21:27:40 -0700 (PDT) Message-ID: Date: Tue, 17 Jul 2007 21:27:40 -0700 From: "Kip Macy" To: "Mike Tancsa" , freebsd-current@freebsd.org In-Reply-To: <200707180239.l6I2dgD1010356@lava.sentex.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200707180239.l6I2dgD1010356@lava.sentex.ca> Cc: Subject: Re: chelsio driver and Myricom driver X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2007 04:27:47 -0000 You need to use the module in order to update the firmware. The firmware will be automatically be updated when you up an interface on the card. -Kip On 7/17/07, Mike Tancsa wrote: > Hi, > > I am trying to run a recent current with the Chelsio 10GigE card > below and it tries to load but has the following complaint. > > cxgbc0: mem > 0xe0201000-0xe0201fff,0xe0800000-0xe0ffffff,0xe0200000-0xe0200fff irq > 16 at device 0.0 on pci10 > cxgbc0: found wrong FW version (4.0), driver needs version 4.5 > cxgbc0: firmware needs to be updated to version 4.5.0 > cxgbc0: found wrong TP version (0.0), driver needs version 1.1 > cxgbc0: SRAM needs to be updated to version b-1.1.0 > cxgb0: on cxgbc0 > cxgb0: Ethernet address: 00:07:43:04:01:2c > > Where do I get the firmware from ? The website only has 4.3 ? Also, > how do I update the SRAM. Sorry if these are obvious questions, but > I am new to CURRENT with such drivers. I have the driver compiled > into the kernel > > > With the Myricom, it seems to work, but it doesnt detect the cx4 > media type for some reason. > > # ifconfig mxge0 > mxge0: flags=8843 metric 0 mtu 9000 > > options=1bb > ether 00:60:dd:47:c6:c4 > inet 192.168.10.3 netmask 0xffffff00 broadcast 192.168.10.255 > media: (autoselect ) > status: active > > The port is up and I can ping across it so it is working. > > TenGigabitEthernet2/3 is up, line protocol is up (connected) > Hardware is C6k 10000Mb 802.3, address is 0018.bab0.2036 (bia > 0018.bab0.2036) > Description: leopard3 mxge0 > MTU 1500 bytes, BW 10000000 Kbit, DLY 10 usec, > reliability 255/255, txload 1/255, rxload 1/255 > Encapsulation ARPA, loopback not set > Full-duplex, 10Gb/s > input flow-control is off, output flow-control is on > ARP type: ARPA, ARP Timeout 04:00:00 > Last input never, output 00:00:55, output hang never > Last clearing of "show interface" counters never > Input queue: 0/2000/0/0 (size/max/drops/flushes); Total output drops: 0 > Queueing strategy: fifo > Output queue: 0/40 (size/max) > 5 minute input rate 0 bits/sec, 0 packets/sec > 5 minute output rate 0 bits/sec, 0 packets/sec > 8 packets input, 588 bytes, 0 no buffer > Received 5 broadcasts, 0 runts, 0 giants, 0 throttles > 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored > 0 input packets with dribble condition detected > 403 packets output, 30468 bytes, 0 underruns > 0 output errors, 0 collisions, 1 interface resets > 0 babbles, 0 late collision, 0 deferred > 0 lost carrier, 0 no carrier > 0 output buffer failures, 0 output buffers swapped out > > > ---Mike > > > -------------------------------------------------------------------- > Mike Tancsa, tel +1 519 651 3400 > Sentex Communications, mike@sentex.net > Providing Internet since 1994 www.sentex.net > Cambridge, Ontario Canada www.sentex.net/mike > > _______________________________________________ > 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 Jul 18 04:34:28 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 720D916A403 for ; Wed, 18 Jul 2007 04:34:28 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 35BB013C4B9 for ; Wed, 18 Jul 2007 04:34:28 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.13.8/8.13.8) with ESMTP id l6I4YRVi031960; Wed, 18 Jul 2007 00:34:27 -0400 (EDT) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.8/8.13.3) with ESMTP id l6I4YRcv010892 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Jul 2007 00:34:27 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <200707180434.l6I4YRcv010892@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 18 Jul 2007 00:34:07 -0400 To: "Kip Macy" , freebsd-current@freebsd.org From: Mike Tancsa In-Reply-To: References: <200707180239.l6I2dgD1010356@lava.sentex.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Subject: Re: chelsio driver and Myricom driver X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2007 04:34:28 -0000 At 12:27 AM 7/18/2007, Kip Macy wrote: >You need to use the module in order to update the firmware. The >firmware will be automatically be updated when you up an interface on >the card. Thanks, I just figured that out a few min ago by accident and the card looks happy now! [leopard1]% ifconfig cxgb0: flags=8843 metric 0 mtu 9000 options=1bb ether 00:07:43:04:01:2c inet 192.168.10.1 netmask 0xffffff00 broadcast 192.168.10.255 media: Ethernet 10Gbase-CX4 (autoselect ) status: active [leopard1]% sysctl -a | grep cxg hw.cxgb.singleq: 1 hw.cxgb.ofld_disable: 0 hw.cxgb.msi_allowed: 2 dev.cxgbc.0.%desc: Chelsio T310 RNIC, 1 port dev.cxgbc.0.%driver: cxgbc dev.cxgbc.0.%location: slot=0 function=0 dev.cxgbc.0.%pnpinfo: vendor=0x1425 device=0x0030 subvendor=0x1425 subdevice=0x0001 class=0x020000 dev.cxgbc.0.%parent: pci10 dev.cxgbc.0.firmware_version: 4.5.0 dev.cxgbc.0.intr_coal: 5000 dev.cxgbc.0.enable_debug: 0 dev.cxgbc.0.collapse_free: 0 dev.cxgbc.0.mb_free_vec_free: 0 dev.cxgbc.0.collapse_mbufs: 0 dev.cxgbc.0.txq_overrun: 0 dev.cxgbc.0.bogus_imm: 1 dev.cxgb.0.%desc: Port 0 10GBASE-CX4 dev.cxgb.0.%driver: cxgb dev.cxgb.0.%parent: cxgbc0 [leopard1]% > -Kip > >On 7/17/07, Mike Tancsa wrote: >>Hi, >> >>I am trying to run a recent current with the Chelsio 10GigE card >>below and it tries to load but has the following complaint. >> >>cxgbc0: mem >>0xe0201000-0xe0201fff,0xe0800000-0xe0ffffff,0xe0200000-0xe0200fff irq >>16 at device 0.0 on pci10 >>cxgbc0: found wrong FW version (4.0), driver needs version 4.5 >>cxgbc0: firmware needs to be updated to version 4.5.0 >>cxgbc0: found wrong TP version (0.0), driver needs version 1.1 >>cxgbc0: SRAM needs to be updated to version b-1.1.0 >>cxgb0: on cxgbc0 >>cxgb0: Ethernet address: 00:07:43:04:01:2c >> >>Where do I get the firmware from ? The website only has 4.3 ? Also, >>how do I update the SRAM. Sorry if these are obvious questions, but >>I am new to CURRENT with such drivers. I have the driver compiled >>into the kernel >> >> >>With the Myricom, it seems to work, but it doesnt detect the cx4 >>media type for some reason. >> >># ifconfig mxge0 >>mxge0: flags=8843 metric 0 mtu 9000 >> >>options=1bb >> ether 00:60:dd:47:c6:c4 >> inet 192.168.10.3 netmask 0xffffff00 broadcast 192.168.10.255 >> media: (autoselect ) >> status: active >> >>The port is up and I can ping across it so it is working. >> >>TenGigabitEthernet2/3 is up, line protocol is up (connected) >> Hardware is C6k 10000Mb 802.3, address is 0018.bab0.2036 (bia >>0018.bab0.2036) >> Description: leopard3 mxge0 >> MTU 1500 bytes, BW 10000000 Kbit, DLY 10 usec, >> reliability 255/255, txload 1/255, rxload 1/255 >> Encapsulation ARPA, loopback not set >> Full-duplex, 10Gb/s >> input flow-control is off, output flow-control is on >> ARP type: ARPA, ARP Timeout 04:00:00 >> Last input never, output 00:00:55, output hang never >> Last clearing of "show interface" counters never >> Input queue: 0/2000/0/0 (size/max/drops/flushes); Total output drops: 0 >> Queueing strategy: fifo >> Output queue: 0/40 (size/max) >> 5 minute input rate 0 bits/sec, 0 packets/sec >> 5 minute output rate 0 bits/sec, 0 packets/sec >> 8 packets input, 588 bytes, 0 no buffer >> Received 5 broadcasts, 0 runts, 0 giants, 0 throttles >> 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored >> 0 input packets with dribble condition detected >> 403 packets output, 30468 bytes, 0 underruns >> 0 output errors, 0 collisions, 1 interface resets >> 0 babbles, 0 late collision, 0 deferred >> 0 lost carrier, 0 no carrier >> 0 output buffer failures, 0 output buffers swapped out >> >> >> ---Mike >> >> >>-------------------------------------------------------------------- >>Mike Tancsa, tel +1 519 651 3400 >>Sentex Communications, mike@sentex.net >>Providing Internet since 1994 www.sentex.net >>Cambridge, Ontario Canada www.sentex.net/mike >> >>_______________________________________________ >>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 Jul 18 04:47:09 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4634E16A401 for ; Wed, 18 Jul 2007 04:47:09 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.179]) by mx1.freebsd.org (Postfix) with ESMTP id 1280713C4B2 for ; Wed, 18 Jul 2007 04:47:08 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by wa-out-1112.google.com with SMTP id j37so91513waf for ; Tue, 17 Jul 2007 21:47:08 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:received:received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=uttMNa6+eQLFek+cufo/6mD6bjrrfvTrAhJ1CEn/cZWs3yn65mq6V6BoU132BsCT85v9CceT/SRU9U4AGcG9BOXE9roVGZaVsCw1Gl32pv6b2sNEEl47ZC1mnj9fYe1emRSCM5Nk3L69Nfu8wHVadKKjIjbqsnC8jEu12dyyeZE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=erF/fI9SUAWDdTB8mmf8Mbkxi1OQ7Twlo/n1u4kJg2N/eOYl5S582efxf2O17HR6jHKl8iVDIk2quYWeKHeaAK9we8L58pjV+Wfr+19ikKupDaUj6cRRS4rUOrboIVjoawo31tF/HvHLaRKlgqNuLd9phrttbrjp79t539BP3tE= Received: by 10.115.88.1 with SMTP id q1mr1108105wal.1184734028389; Tue, 17 Jul 2007 21:47:08 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTPS id m24sm674425waf.2007.07.17.21.47.05 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 17 Jul 2007 21:47:07 -0700 (PDT) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id l6I4l0Cw039204 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Jul 2007 13:47:00 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id l6I4l05b039203; Wed, 18 Jul 2007 13:47:00 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Wed, 18 Jul 2007 13:47:00 +0900 From: Pyun YongHyeon To: St?le Kristoffersen Message-ID: <20070718044700.GE37935@cdnetworks.co.kr> References: <20070716190441.GA19282@eschew.pusen.org> <20070716213425.GB19282@eschew.pusen.org> <20070718041159.GC37935@cdnetworks.co.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070718041159.GC37935@cdnetworks.co.kr> User-Agent: Mutt/1.4.2.1i Cc: Kip Macy , current@freebsd.org Subject: Re: Slow networkperformance in current? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2007 04:47:09 -0000 On Wed, Jul 18, 2007 at 01:11:59PM +0900, To St?le Kristoffersen wrote: > On Mon, Jul 16, 2007 at 11:34:25PM +0200, St?le Kristoffersen wrote: > > On 2007-07-16 at 12:47, Kip Macy wrote: > > > 10 GigE cards are doing line rate - over time the cpu usage required > > > to do so is going down. Your experience is probably due to NIC issues. > > > What kind of NIC are you using? And have you changed any configuration > > > or settings? > > > > I was thinking of the NIC, thats why I tried it on localhost (bypassing the > > NIC(?)). > > I'm using a re-nick: > > re0: port 0x7e00-0x7eff mem > > 0xfd3ff000-0xfd3fffff irq 18 at device 0.0 on pci3 > > > > I'm not sure it's directly related with re(4) but try overhauled re(4). > http://people.freebsd.org/~yongari/re.HEAD.patch > It seems that you also have PCIe based NIC. Try MSI patch for re(4) > in addition to above one. > Oops, here is MSI patch. http://people.freebsd.org/~yongari/re.msi.patch -- Regards, Pyun YongHyeon From owner-freebsd-current@FreeBSD.ORG Wed Jul 18 04:56:31 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 92E2C16A401; Wed, 18 Jul 2007 04:56:31 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from mxout2.cac.washington.edu (mxout2.cac.washington.edu [140.142.33.4]) by mx1.freebsd.org (Postfix) with ESMTP id 6FDE413C467; Wed, 18 Jul 2007 04:56:31 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9] (may be forged)) by mxout2.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.06) with ESMTP id l6I4uUdd021464 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 17 Jul 2007 21:56:31 -0700 X-Auth-Received: from [192.168.10.45] (c-24-10-12-194.hsd1.ca.comcast.net [24.10.12.194]) (authenticated authid=youshi10) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l6I4uUBI013176 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 17 Jul 2007 21:56:30 -0700 Message-ID: <469D9D7D.3040600@u.washington.edu> Date: Tue, 17 Jul 2007 21:56:29 -0700 From: Garrett Cooper User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Attilio Rao References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 5.3.2.304607, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.7.17.213534 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__C230066_P2 0, __CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' Cc: current@freebsd.org Subject: Re: ULE/SCHED_SMP diff for 7.0, buildkernel & thanks. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Jul 2007 04:56:31 -0000 youshi10@u.washington.edu wrote: > On Tue, 17 Jul 2007, Attilio Rao wrote: > >> 2007/7/17, Abdullah Ibn Hamad Al-Marri : >>> On 7/17/07, Jeff Roberson wrote: >>> > With regards to buildkernel times; I do not want to sacrafice >>> performance >>> > on other benchmarks to improve buildkernel. The problem is that >>> 4BSD is >>> > as agressive as possible at scheduling work on idle cores. This >>> behavior >>> > that helps one buildworld hurts on other, in my opinion, more >>> important >>> > benchmarks. >>> > >>> > For example: http://people.freebsd.org/~jeff/sysbench.png >>> > >>> > ULE is 33% faster than SCHED_4BSD at this mysql test. This is a >>> direct >>> > result of prefering to idle to make more efficient scheduling >>> decisions. >>> > ULE is also faster at various networking benchmarks for similar >>> reasons. >>> > >>> > I also believe that while the real time may be slower on >>> buildworld the >>> > system and user time will be smaller by a degree greater than the >>> delta in >>> > real time. This means that while you're building packages you have a >>> > little more cpu time leftover to handle other tasks. Furthermore, >>> as the >>> > number of cores goes up things start to tip in favor of ULE >>> although this >>> > is somewhat because it's harder for even 4BSD to keep them busy >>> due to >>> > disk bandwidth. >>> > >>> > Thanks everyone for testing. Can someone confirm that they have >>> tested >>> > with x86 rather than amd64? I will probably commit later today. >>> > >>> > Thanks, >>> > Jeff >>> >>> Did you compare it to latest Linux fixes? is FreeBSD + ULE + MySQL >>> still faster than linux? >> >> Just look at the link Jeff posted, it seems very well explaining :). >> >> Attilio >> >> >> -- >> Peace can only be achieved by understanding - A. Einstein > > Unfortunately those results are still based on 2.6.20, not 2.6.22 (2 > minor patch revision difference). > > I assume that that's for a vanilla Linux kernel? > > -Garrett Scratch my earlier comment about it works just fine. I seem to have broken my VM again, but it took 5+something iterations this round to get it to break. Now I have to restart Windows because of the random instabilities :). -Garrett From owner-freebsd-current@FreeBSD.ORG Wed Jul 18 05:10:53 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9A09516A406 for ; Wed, 18 Jul 2007 05:10:53 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.171]) by mx1.freebsd.org (Postfix) with ESMTP id 3095113C481 for ; Wed, 18 Jul 2007 05:10:52 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: by ug-out-1314.google.com with SMTP id o4so279147uge for ; Tue, 17 Jul 2007 22:10:51 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=OABT42Ja+D3GnnVFex/X9syfUd2c9B0kMOvBJ68otJw2ySibuqHisZis+Afni+Fetyq40d3ttlpi2eZXKnu9t90ScEhBHeL1xZRyzIyampXS4PE//iUS7V4DA4zdyL4bqbENh3e2zQqPwFM4t5Fa+BVaeliUVAxFCW75ZjLAm0o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ViBneCYewr6YVSUycsfqFDA/NAtc+uN3GWOltxwvTP23JQmxI3EQ//1kswvlbssVwv7yb18ZcyfbmmVuK1uhb2PT4FRHqnqXWE86MKHJEzAECSal4+U//Ifh3NTVxKwp8OaYR9h0xOrRU5AFDF0tQZcOBXb0cCgRApiCoKSFqL8= Received: by 10.78.137.7 with SMTP id k7mr328862hud.1184735451659; Tue, 17 Jul 2007 22:10:51 -0700 (PDT) Received: by 10.78.162.18 with HTTP; Tue, 17 Jul 2007 22:10:51 -0700 (PDT) Message-ID: Date: Tue, 17 Jul 2007 22:10:51 -0700 From: "Kip Macy" To: pyunyh@gmail.com In-Reply-To: <20070718021839.GA37935@cdnetworks.co.kr> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <09BFF2FA5EAB4A45B6655E151BBDD9030483F161@NT-IRVA-0750.brcm.ad.broadcom.com> <20070718021839.GA37935@cdnetworks.co.kr> Cc: David Christensen , current@freebsd.org Subject: Re: Getting/Forcing Greater than 4KB Buffer Allocations X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Jul 2007 05:10:53 -0000 On 7/17/07, Pyun YongHyeon wrote: > On Tue, Jul 17, 2007 at 04:54:31PM -0700, David Christensen wrote: > > I'm investigating a problem with my bce driver which occurs when I ask > > for a jumbo > > mbuf cluster (through m_cljget()). When I map the memory for DMA I > > normally > > get 3 memory segments (4KB + 4KB + 1KB) on my system, but on another > > user's > > system he's seeing 2 memory segments (8KB + 1KB). Is there a > > configuration > > option that allows this or some other tuning variable involved? The > > system is a > > Xeon dual-core processor and has 8GB of RAM, running an AMD64 version of > > the kernel. > > > > I've briefly looked over bus_dma usage on bce(4). It seems that you > told bus_dma the the dma map could be made up of BCE_MAX_SEGMENTS > segments, where a dma segment could be MJUM9BYTES bytes. If you want > just two segments you may have to use 2 instead of BCE_MAX_SEGMENTS. > If the hardware can support up to BCE_MAX_SEGMENTS dma segments on Rx > descriptors you should be prepared to handle that number of dma > segments too(e.g. You don't know how may dma segments would be > returned by bus_dma, you just know the upper bound as you specified > in bus_dma_tag_create()). > If the hardware can handle just up to 4KB for a dma segment you > should tell bus_dma the restriction of the dma segment. > If you have to get a single dma segment that covers MJUM9BYTES bytes > due to the limitation of the hardware you may have to use local > allocator. I have a patch to make jumbo frames contiguous that will go into HEAD after 7 branches. -Kip From owner-freebsd-current@FreeBSD.ORG Wed Jul 18 11:42:01 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5BD1016A403 for ; Wed, 18 Jul 2007 11:42:01 +0000 (UTC) (envelope-from james@clarkee.co.uk) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.189]) by mx1.freebsd.org (Postfix) with ESMTP id 3F32113C48E for ; Wed, 18 Jul 2007 11:42:01 +0000 (UTC) (envelope-from james@clarkee.co.uk) Received: by rv-out-0910.google.com with SMTP id f1so2971rvb for ; Wed, 18 Jul 2007 04:42:01 -0700 (PDT) Received: by 10.140.251.1 with SMTP id y1mr386185rvh.1184757332185; Wed, 18 Jul 2007 04:15:32 -0700 (PDT) Received: by 10.140.127.7 with HTTP; Wed, 18 Jul 2007 04:15:32 -0700 (PDT) Message-ID: Date: Wed, 18 Jul 2007 12:15:32 +0100 From: "James Clarke" To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Freebsd 7 - USB Keyboard not working with install X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Jul 2007 11:42:01 -0000 Downloaded Freebsd7 Snapshots: 7.0-CURRENT-200706-amd64-disc1.iso 7.0-CURRENT-200706-i386-disc1.iso Tried installing on Dell Optiplex 745 USB Keyboard not usable by the time it gets to sysinstall. No lights on keyboard. From owner-freebsd-current@FreeBSD.ORG Wed Jul 18 12:44:00 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2F27316A401 for ; Wed, 18 Jul 2007 12:44:00 +0000 (UTC) (envelope-from staale@kristoffersen.ws) Received: from smtp.bluecom.no (smtp.bluecom.no [193.75.75.28]) by mx1.freebsd.org (Postfix) with ESMTP id DC83E13C467 for ; Wed, 18 Jul 2007 12:43:59 +0000 (UTC) (envelope-from staale@kristoffersen.ws) Received: from eschew.pusen.org (unknown [193.69.145.10]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.bluecom.no (Postfix) with ESMTP id 1840E12C1F9; Wed, 18 Jul 2007 14:43:47 +0200 (CEST) Received: from chiller by eschew.pusen.org with local (Exim 4.50) id 1IB8sg-0007Uc-OX; Wed, 18 Jul 2007 14:43:50 +0200 Date: Wed, 18 Jul 2007 14:43:50 +0200 From: =?iso-8859-1?Q?St=E5le?= Kristoffersen To: Pyun YongHyeon Message-ID: <20070718124350.GA25799@eschew.pusen.org> References: <20070716190441.GA19282@eschew.pusen.org> <20070716213425.GB19282@eschew.pusen.org> <20070718041159.GC37935@cdnetworks.co.kr> <20070718044700.GE37935@cdnetworks.co.kr> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20070718044700.GE37935@cdnetworks.co.kr> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: current@freebsd.org Subject: Re: Slow networkperformance in current? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2007 12:44:00 -0000 On 2007-07-18 at 13:47, Pyun YongHyeon wrote: > > I'm not sure it's directly related with re(4) but try overhauled re(4). > > http://people.freebsd.org/~yongari/re.HEAD.patch > > It seems that you also have PCIe based NIC. Try MSI patch for re(4) > > in addition to above one. > Oops, here is MSI patch. > http://people.freebsd.org/~yongari/re.msi.patch For anyone else wanting to test those patches the url was wrong, the correct ones seems to be: http://people.freebsd.org/~yongari/re/re.msi.patch and http://people.freebsd.org/~yongari/re/re.HEAD.patch I applied them, recompiled and rebooted. Not much change. Over the network: [ 3] 0.0-10.0 sec 432 MBytes 362 Mbits/sec and to localhost: [ 3] 0.0-10.1 sec 125 MBytes 104 Mbits/sec -- Ståle Kristoffersen staalebk@ifi.uio.no From owner-freebsd-current@FreeBSD.ORG Wed Jul 18 13:03:41 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C326116A402 for ; Wed, 18 Jul 2007 13:03:41 +0000 (UTC) (envelope-from vanhu@zeninc.net) Received: from smtp.zeninc.net (reverse-25.fdn.fr [80.67.176.25]) by mx1.freebsd.org (Postfix) with ESMTP id 86B9613C48E for ; Wed, 18 Jul 2007 13:03:41 +0000 (UTC) (envelope-from vanhu@zeninc.net) Received: by smtp.zeninc.net (smtpd, from userid 1000) id 917CB3F79; Wed, 18 Jul 2007 15:03:40 +0200 (CEST) Date: Wed, 18 Jul 2007 15:03:40 +0200 From: VANHULLEBUS Yvan To: FreeBSD current mailing list Message-ID: <20070718130340.GB26479@zen.inc> References: <20070713053534.D31116@maildrop.int.zabbadoz.net> <20070713072657.GA13945@zen.inc> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070713072657.GA13945@zen.inc> Cc: Subject: Re: FAST_IPSEC is now IPSEC, please be advised... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Jul 2007 13:03:41 -0000 Hi. On Fri, Jul 13, 2007 at 09:26:57AM +0200, VANHULLEBUS Yvan wrote: [KAME's IPSec removal and ipsec-tools] I just commited on ipsec-tool's HEAD a patch which detects if we only have netipsec/ipsec.h. This patch seems to be ok, but I currently can't upgrade my FreeBSD-HEAD station to test it (well, I could, but I'll lose acces to it if I have any problem....). If someone can test it *very quickly* and confirm it works, I'll include the patch for ipsec-tools 0.7.0 Release (we're already checking that it doesn't break anything on other kernels, including FreeBSD 6.x). Yvan. -- NETASQ http://www.netasq.com From owner-freebsd-current@FreeBSD.ORG Wed Jul 18 13:51:14 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A609E16A406 for ; Wed, 18 Jul 2007 13:51:14 +0000 (UTC) (envelope-from tony@crosswinds.net) Received: from out-mx1.crosswinds.net (out-mx1.crosswinds.net [216.18.117.38]) by mx1.freebsd.org (Postfix) with ESMTP id 8351413C467 for ; Wed, 18 Jul 2007 13:51:14 +0000 (UTC) (envelope-from tony@crosswinds.net) Received: from admin.crosswinds.net (out-mx1.crosswinds.net [216.18.117.38]) by out-mx1.crosswinds.net (Postfix) with ESMTP id 424AC2C349; Wed, 18 Jul 2007 09:33:45 -0400 (EDT) Received: by admin.crosswinds.net (Postfix, from userid 1001) id 31683403D; Wed, 18 Jul 2007 09:33:45 -0400 (EDT) Date: Wed, 18 Jul 2007 09:33:45 -0400 From: Tony Holmes To: freebsd-current@freebsd.org Message-ID: <20070718133345.GA82366@crosswinds.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Cc: Subject: 7.0/6.2, 4GB and AHC X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Jul 2007 13:51:14 -0000 I had a very interesting couple of days trying to figure out why 6.2-STABLE and 7.0-CURRENT, both amd64, were giving me random hangs, panics etc. My system: Asus M2NPV-VM 4GB Ram 2 x Adaptec 19160 controllers 14 x 33GB Seagate 10k rpm scsi in a disk shelf (2 channel) 2 x 80GB Seagate SATA (geom mirror, system disks) I had the system installed with 6.2 and upgraded to 7.0- (for the new nfe driver for the onboard NIC) and added the Adaptecs and disk. I began to play with geom to set them up as a RAID 10 system for a database. Same configuration on FreeBSD, solaris and other systems resulted in blazing fast performance. Set up the disks, fired up a basic bonnie test and... chug chug and eventual random panic. Okay, maybe I messed up the geom config since I was tinkering around. Reboot, wait for sync to finish.... 20 hours later it was done - way too slow. Checked termination, cables, power, etc. All good. Fire up bonnie... first iteration showed approx 8MBps write approx 10MBps read was horrendous. Decided to attempt a fresh reinstall. Load up 6.2R amd64 cd - panic on startup just after SCSI probe delay. Tried once more and same thing. Okay, try 7.0 amd64. Divide by 0 error right after SCSI probe - and that's when the thought struck me - 4GB ram... Pulled out 2GB and viola, 7.0 installed easily. Configured the Raid 10 and got the nice 275MBps read and 150MBps (ballpark) benchmark numbers I was expecting. I know that amd64 supports 4gb+ (I have 2 others with SATA only that are running flawlessly). So I am attempting to determine the cause of the failures. The adaptecs are 32bit with older bios (2.57 and 3.10). They are in the 2 32bit pci slots of the M2NPV motherboard. I would have thought FreeBSD would have knocked a memory hole in the 3.5-4gb range to accomodate the device mappings. Does anyone have any explanations/pointers (I did search and attempt to RTFM with not much luck) about this? -- Tony Holmes Ph: (416) 993-1219 Founder and Senior Systems Architect Crosswinds Internet Communications Inc. From owner-freebsd-current@FreeBSD.ORG Wed Jul 18 14:00:17 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8631E16A401 for ; Wed, 18 Jul 2007 14:00:17 +0000 (UTC) (envelope-from gilham@csl.sri.com) Received: from mailgate-internal1.sri.com (mailgate-internal1.SRI.COM [128.18.84.103]) by mx1.freebsd.org (Postfix) with SMTP id 6C90213C4A8 for ; Wed, 18 Jul 2007 14:00:17 +0000 (UTC) (envelope-from gilham@csl.sri.com) Received: from localhost (HELO mailgate-internal1.SRI.COM) (127.0.0.1) by mailgate-internal1.sri.com with SMTP; 18 Jul 2007 13:33:37 -0000 Received: from mx1.csl.sri.com ([130.107.1.29]) by mailgate-internal1.SRI.COM (SMSSMTP 4.1.11.41) with SMTP id M2007071806333613909 for ; Wed, 18 Jul 2007 06:33:36 -0700 Received: from snapdragon.csl.sri.com (snapdragon.csl.sri.com [130.107.19.20]) by mx1.csl.sri.com (8.13.6/8.12.11) with ESMTP id l6IDXa5Z013505 for ; Wed, 18 Jul 2007 06:33:37 -0700 (PDT) (envelope-from gilham@snapdragon.csl.sri.com) To: current@freebsd.org In-reply-to: <469D651C.6080504@fnop.net> References: <469D651C.6080504@fnop.net> Comments: In-reply-to Rui Paulo message dated "Wed, 18 Jul 2007 01:55:56 +0100." X-Mailer: MH-E 8.0.3; nmh 1.2; GNU Emacs 22.0.93 Date: Wed, 18 Jul 2007 06:33:36 -0700 Message-ID: <40882.1184765616@snapdragon.csl.sri.com> From: Fred Gilham Cc: Subject: Re: less -r broken with long lines X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Jul 2007 14:00:17 -0000 Rui Paulo wrote: > Hi, > There's something about how the new less version handles lines greater > than the virtual terminal's size. > > Test case on an xterm/rxvt/screen session: > > less -r /etc/syslog.conf - you won't see the $FreeBSD$ id tag because > of the long line regarding to /var/log/messages. Try resizing your > terminal so that this line fits in the right number of columns. You'll > see the problem disappear. > > less -r /etc/rc.firewall - since there are no long lines in the first > page, you won't notice the problem > > Everything works fine if less is used without the -r argument or if less > is run from the console. > > Does this ring any bell to anyone? > > Regards. > -- > Rui Paulo This is documented behavior. From the "less" manpage: -r or --raw-control-chars Causes "raw" control characters to be displayed. The default is to display control characters using the caret notation; for example, a control-A (octal 001) is displayed as "^A". Warning: when the -r option is used, less cannot keep track of the actual appearance of the screen (since this depends on how the screen responds to each type of control character). Thus, various dis- play problems may result, such as long lines being split in the wrong place. -- Fred Gilham gilham@csl.sri.com The Net interprets Microsoft products as damage, and routes around them. From owner-freebsd-current@FreeBSD.ORG Wed Jul 18 14:08:25 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9E3AA16A400 for ; Wed, 18 Jul 2007 14:08:25 +0000 (UTC) (envelope-from gelsemap@superhero.nl) Received: from superman.superhero.nl (superhero.nl [82.95.198.17]) by mx1.freebsd.org (Postfix) with ESMTP id D131013C4A5 for ; Wed, 18 Jul 2007 14:08:24 +0000 (UTC) (envelope-from gelsemap@superhero.nl) Received: (qmail 95880 invoked by uid 80); 18 Jul 2007 14:08:26 -0000 Received: from 195.50.100.20 (SquirrelMail authenticated user gelsemap) by www.superhero.nl with HTTP; Wed, 18 Jul 2007 16:08:25 +0200 (CEST) Message-ID: <34830.195.50.100.20.1184767705.squirrel@www.superhero.nl> In-Reply-To: <20070718133345.GA82366@crosswinds.net> References: <20070718133345.GA82366@crosswinds.net> Date: Wed, 18 Jul 2007 16:08:25 +0200 (CEST) From: "Gelsema, P \(Patrick\)" To: "Tony Holmes" User-Agent: SquirrelMail/1.4.8 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: freebsd-current@freebsd.org Subject: Re: 7.0/6.2, 4GB and AHC X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Jul 2007 14:08:25 -0000 On Wed, July 18, 2007 15:33, Tony Holmes wrote: > I had a very interesting couple of days trying to figure out why > 6.2-STABLE > and 7.0-CURRENT, both amd64, were giving me random hangs, panics etc. > > My system: > > Asus M2NPV-VM > 4GB Ram > 2 x Adaptec 19160 controllers > 14 x 33GB Seagate 10k rpm scsi in a disk shelf (2 channel) > 2 x 80GB Seagate SATA (geom mirror, system disks) I've got an ASUS M2N (latest bios) with an Adaptec 39320D SCSI controller. I get similair issues like mangled entries, unable to mount root after reboot. Currently I installed I386 version which solved all of my problems. I haven't removed the 2x1GB module yet, so that's something to check. On my emails (see http://lists.freebsd.org/pipermail/freebsd-current/2007-July/thread.html) I havent had much response yet. If more information is required I am happy to provide. Patrick > > I had the system installed with 6.2 and upgraded to 7.0- (for the new nfe > driver for the onboard NIC) and added the Adaptecs and disk. I began to > play > with geom to set them up as a RAID 10 system for a database. Same > configuration > on FreeBSD, solaris and other systems resulted in blazing fast > performance. > > Set up the disks, fired up a basic bonnie test and... chug chug and > eventual > random panic. Okay, maybe I messed up the geom config since I was > tinkering > around. Reboot, wait for sync to finish.... 20 hours later it was done - > way > too slow. Checked termination, cables, power, etc. All good. > > Fire up bonnie... first iteration showed approx 8MBps write approx 10MBps > read > was horrendous. Decided to attempt a fresh reinstall. > > Load up 6.2R amd64 cd - panic on startup just after SCSI probe delay. > Tried > once more and same thing. Okay, try 7.0 amd64. > > Divide by 0 error right after SCSI probe - and that's when the thought > struck > me - 4GB ram... > > Pulled out 2GB and viola, 7.0 installed easily. Configured the Raid 10 and > got > the nice 275MBps read and 150MBps (ballpark) benchmark numbers I was > expecting. > > I know that amd64 supports 4gb+ (I have 2 others with SATA only that are > running flawlessly). > > So I am attempting to determine the cause of the failures. > > The adaptecs are 32bit with older bios (2.57 and 3.10). They are in the 2 > 32bit pci slots of the M2NPV motherboard. > > I would have thought FreeBSD would have knocked a memory hole in the > 3.5-4gb > range to accomodate the device mappings. > > Does anyone have any explanations/pointers (I did search and attempt to > RTFM > with not much luck) about this? > > -- > Tony Holmes > > Ph: (416) 993-1219 > > Founder and Senior Systems Architect > Crosswinds Internet Communications Inc. > _______________________________________________ > 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 Jul 18 14:36:39 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 84CDC16A59E; Wed, 18 Jul 2007 14:36:39 +0000 (UTC) (envelope-from yoichi@FreeBSD.org) Received: from alcoholic.geiin.org (x006014.ppp.asahi-net.or.jp [122.249.6.14]) by mx1.freebsd.org (Postfix) with ESMTP id 46F1A13C428; Wed, 18 Jul 2007 14:36:39 +0000 (UTC) (envelope-from yoichi@FreeBSD.org) Received: from tequila.local-net.geiin.org (tequila-air.local-net [192.168.1.6]) by alcoholic.geiin.org (Postfix) with ESMTP id 2869E1DEE3; Wed, 18 Jul 2007 23:10:03 +0900 (JST) Date: Wed, 18 Jul 2007 23:10:05 +0900 Message-ID: <87fy3l3irm.wl%yoichi@FreeBSD.org> From: Yoichi Nakayama To: FreeBSD-gnats-submit@FreeBSD.org In-Reply-To: <20061109112035.GA1722@kobe.laptop> References: <200611062349.kA6NnbCG051817@www.freebsd.org> <20061107192218.GB1624@kobe.laptop> <878ximm418.wl%yoichi@FreeBSD.org> <20061109112035.GA1722@kobe.laptop> User-Agent: Wanderlust/2.15.5 (Almost Unreal) EMIKO/1.14.1 (Choanoflagellata) FLIM/1.14.8 (=?ISO-2022-JP?B?GyRCO00+chsoQg==?=) APEL/10.7 Emacs/22.1.50 (i686-pc-linux-gnu) MULE/5.0 (=?ISO-2022-JP?B?GyRCOC1MWhsoQg==?=) Organization: FreeBSD.org X-Face: wLZki+KbGjgKe0,<&3g*rA|R**vj[a8L%[v]ecJh1L(Uqm|LBx; v7Nq7n%?0d.aS]F#[~C\!{m?m,C&#U5}$_pZvBR>5VmX1Ol0`P\M-U8`sUF<5Quj'z&zzW8r|Zl9#W7Wut3duYzpKrP{n+AbarKtJ!i"Al7]P; -?[=iBZa*]r=>C':0~JECx]IH+RXq=/hUX}MB9e]oQKBxsDd/ MIME-Version: 1.0 (generated by EMIKO 1.14.1 - "Choanoflagellata") Content-Type: text/plain; charset=US-ASCII Cc: freebsd-current@freebsd.org Subject: Re: kern/105229: panic in sync_fsync X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Jul 2007 14:36:39 -0000 At Thu, 9 Nov 2006 13:20:35 +0200, Giorgos Keramidas wrote: > > On 2006-11-08 23:00, Yoichi Nakayama wrote: > >At Tue, 7 Nov 2006 21:22:18 +0200, > >Giorgos Keramidas wrote: > >> Hi NAKAYAMA-san :) > >> > >> In general, we handle CURRENT problems in the freebsd-current mailing > >> list, instead of opening problem reports. > > > > I'm sorry for my mistake. > > Nothing to worry about :) > > >> The build from `2006.11.07.05.51.41', as I said seems to work fine. > >> > >> Can you try re-syncing your source tree to see if a newer commit has > >> fixed this in CURRENT? > > > > Thanks for your suggestion. I've already synced it to current > > yesterday (after the time vfs_subr.c Revision 1.691 was committed at > > Nov 7 19:45:05 2006 UTC), and I'm keeping it running. > > > > I'll post a report to freebsd-current list after one week trial. > > I've met the same problem for some number of times after 2-7 days run. > > Cool! Unfortunately, I don't leave my laptop running for so long. > If this is related to staying up several days, I wouldn't notice it > easily :) I reproduce the problem with configuration: - 512MBx2 on two slots - 512MBx1 on one of the slots (tried with both RAMs) and then I tried with Windows XP and get similar result (rebooted after a few weeks). Although no problem occurred with - 512MBx1 on another slot (tried with both RAMs) Finally, I conclude the problem is in one of the memory slot on my motherboard (ASUS N4L-VM DH). Please close this PR. I'm sorry for bothering you. -- Yoichi NAKAYAMA From owner-freebsd-current@FreeBSD.ORG Wed Jul 18 15:32:31 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DF8D916A401 for ; Wed, 18 Jul 2007 15:32:31 +0000 (UTC) (envelope-from tevans.uk@googlemail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.190]) by mx1.freebsd.org (Postfix) with ESMTP id 71C3413C4BF for ; Wed, 18 Jul 2007 15:32:30 +0000 (UTC) (envelope-from tevans.uk@googlemail.com) Received: by nf-out-0910.google.com with SMTP id b2so15479nfb for ; Wed, 18 Jul 2007 08:32:25 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=googlemail.com; s=beta; h=domainkey-signature:received:received:subject:from:to:content-type:date:message-id:mime-version:x-mailer; b=GvOJTkpA5Ko2hOPjz/503VMVrm5/DGoipkcv6KuKDXx7BHljSGCZS3VXuxGMwKhEqXdN2yA6UWCs7gPgnr6BD0c1JBgg9I7+YNZ2nXWbFf+9Zq7yv6tKJ4/ShkAHH/P7USzRgbdIpjYnedvzZutSV5PqqgieRDahcar3J9TRb8I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=beta; h=received:subject:from:to:content-type:date:message-id:mime-version:x-mailer; b=ds3bya0ykynhgMbzgeo7LuGQhI1nKNwr8iyqL7UDU/MBONhkL6DC8UREPNN7n5B7Gab2y/u4EDMLtSYPiueDciZIhXsFYeRkPhMyLcKrDZlJ7qYlt+GPVJ/fb0Vcm8SOUSPxvmlDXqhJA4VoioE4KZ4+fnqs4jQbvQaGTL/VowY= Received: by 10.82.105.13 with SMTP id d13mr2296833buc.1184772744942; Wed, 18 Jul 2007 08:32:24 -0700 (PDT) Received: from ?127.0.0.1? ( [217.206.187.79]) by mx.google.com with ESMTPS id 35sm4795247nfu.2007.07.18.08.32.24 (version=SSLv3 cipher=RC4-MD5); Wed, 18 Jul 2007 08:32:24 -0700 (PDT) From: Tom Evans To: freebsd-current@freebsd.org Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-K3R6Sziup2+t/Pe3bXbV" Date: Wed, 18 Jul 2007 16:32:21 +0100 Message-Id: <1184772741.1313.11.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.10.2 FreeBSD GNOME Team Port Subject: Help! I don't get vmcore dumps anymore.. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Jul 2007 15:32:32 -0000 --=-K3R6Sziup2+t/Pe3bXbV Content-Type: text/plain Content-Transfer-Encoding: quoted-printable I haven't had a panic for quite a while until this morning, and was surprised to see it boot up without savecore(8) grabbing the dump.=20 I have a feeling that I have configured my kernel incorrectly - should I have KDB_UNATTENDED to have dumpon work? Here is dumpdev setting from rc.conf, swapinfo and kernel conf: > $ grep dump /etc/rc.conf=20 dumpdev=3D"/dev/ad4s3b" tom@zoot '15:52:07' '/usr/home/tom' > $ swapinfo Device 1K-blocks Used Avail Capacity /dev/ad4s3b 2097152 186600 1910552 9% tom@zoot '15:52:10' '/usr/home/tom' > $ cat /usr/src/sys/i386/conf/ZOOT=20 include GENERIC ident ZOOT machine i386 nocpu I486_CPU nocpu I586_CPU options SC_PIXEL_MODE options SC_HISTORY_SIZE=3D1000 options VESA options SMP device crypto options GEOM_ELI nooptions INVARIANTS nooptions INVARIANT_SUPPORT nooptions WITNESS nooptions WITNESS_SKIPSCAN options ALT_BREAK_TO_DEBUGGER device atapicam device vt device drm device i915drm options NDISAPI device ndis Thanks Tom --=-K3R6Sziup2+t/Pe3bXbV Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQBGnjKAlcRvFfyds/cRAk+vAKC97hsveEvD2xMd/AcKKEakPF8FeQCZAfW7 z0GwFFGNEORO3LS8+S/yrDw= =CYj4 -----END PGP SIGNATURE----- --=-K3R6Sziup2+t/Pe3bXbV-- From owner-freebsd-current@FreeBSD.ORG Wed Jul 18 16:10:36 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 954A216A404 for ; Wed, 18 Jul 2007 16:10:36 +0000 (UTC) (envelope-from kramer@centtech.com) Received: from mh1.centtech.com (moat3.centtech.com [64.129.166.50]) by mx1.freebsd.org (Postfix) with ESMTP id 6A4D013C4B5 for ; Wed, 18 Jul 2007 16:10:36 +0000 (UTC) (envelope-from kramer@centtech.com) Received: from [127.0.0.1] ([192.168.51.3]) by mh1.centtech.com (8.13.8/8.13.8) with ESMTP id l6IGAZJP089681 for ; Wed, 18 Jul 2007 11:10:35 -0500 (CDT) (envelope-from kramer@centtech.com) Message-ID: <469E3B7C.4020402@centtech.com> Date: Wed, 18 Jul 2007 11:10:36 -0500 From: kevin kramer User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.88.4/3696/Wed Jul 18 07:56:36 2007 on mh1.centtech.com X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=8.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.6 X-Spam-Checker-Version: SpamAssassin 3.1.6 (2006-10-03) on mh1.centtech.com Subject: processes stuck in kqread X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Jul 2007 16:10:36 -0000 I have been having issues for some time on -CURRENT. My latest update was 7/11. I have identified these processes as being stuck in kqread while waiting for them to continue. Processes that I know are a problem: sshd - I can watch a login and the process goes from Select to kqread, takes about 3-4 minutes to get a login prompt top - takes about 2-3 minutes to come up tar - never really even starts to read data in and stays in kqread Processes not affected: scp gstat cvsup make This machine is running AMD64 GENERIC kernel on a Dual-Core Xeons. dmesg.txt and top-trace.txt here, http://users.centtech.com/~kramer/snapshot What do I do to debug this? From owner-freebsd-current@FreeBSD.ORG Wed Jul 18 16:17:24 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7E39216A402 for ; Wed, 18 Jul 2007 16:17:24 +0000 (UTC) (envelope-from dionch@freemail.gr) Received: from smtp.freemail.gr (smtp.freemail.gr [81.171.104.107]) by mx1.freebsd.org (Postfix) with ESMTP id B129A13C491 for ; Wed, 18 Jul 2007 16:17:23 +0000 (UTC) (envelope-from dionch@freemail.gr) Received: from CDION (ppp244-194.dsl.hol.gr [89.210.244.194]) by smtp.freemail.gr (Postfix) with ESMTP id DED49A08498; Wed, 18 Jul 2007 18:57:36 +0300 (EEST) Date: Wed, 18 Jul 2007 18:55:11 +0300 From: Chris Dionissopoulos X-Mailer: The Bat! (v3.80.06) Professional X-Priority: 3 (Normal) Message-ID: <645205041.20070718185511@freemail.gr> To: Jeff Roberson In-Reply-To: <20070716233030.D92541@10.0.0.1> References: <20070716233030.D92541@10.0.0.1> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: ULE/SCHED_SMP diff for 7.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Chris Dionissopoulos List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2007 16:17:24 -0000 Hello Jeff, Tuesday, July 17, 2007, 9:35:38 AM, you wrote: > http://people.freebsd.org/~jeff/ule.diff > This patch is scheduled for inclusion in 7.0. I would like anyone who > cares to run it to validate that it does not create any stability or > performance regression over the existing ULE. This patch replaces ULE > with SCHED_SMP, which will now no longer exist as a seperate fork of ULE. > Briefly, this is still a very suitable scheduler for uniprocessor machines > while providing stronger affinity and other performance improvements for > multiprocessor machines. > Even "works for me!" type responses are welcome so I know roughly how many > people have tested before I commit this close to release. > Thanks! > Jeff > _______________________________________________ > 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" It works for me, but for some reason load averages gone x1000!! last pid: 12626; load averages: 314.40, 282.08, 187.64 up 0+01:16:23 18:49:56 84 processes: 2 running, 82 sleeping CPU states: 11.8% user, 0.0% nice, 1.5% system, 0.4% interrupt, 86.4% idle Mem: 672M Active, 452M Inact, 144M Wired, 776K Cache, 112M Buf, 708M Free Swap: 1024M Total, 1024M Free usually I have load averages 0.15 - 0.5. kernel and world binaries cvsuped 2 hours ago. dmesg: ======= Copyright (c) 1992-2007 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.0-CURRENT #2: Wed Jul 18 17:01:15 EEST 2007 root@mail.debug.gr:/usr/obj/usr/src/sys/DEV7 ACPI APIC Table: Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 CPU 6300 @ 1.86GHz (1876.00-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6f6 Stepping = 6 Features=0xbfebfbff Features2=0xe3bd AMD Features=0x20100000 AMD Features2=0x1 Logical CPUs per core: 2 real memory = 2120540160 (2022 MB) avail memory = 2069549056 (1973 MB) FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 2 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 ichwd module loaded ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 cpu0: on acpi0 est0: on cpu0 p4tcc0: on cpu0 cpu1: on acpi0 est1: on cpu1 p4tcc1: on cpu1 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 vgapci0: port 0x2440-0x2447 mem 0x90200000-0x902fffff,0x80000000-0x8fffffff irq 16 at device 2.0 on pci0 agp0: on vgapci0 agp0: detected 7676k stolen memory agp0: aperture size is 256M drm0: on vgapci0 info: [drm] AGP at 0x80000000 256MB info: [drm] Initialized i915 1.5.0 20060119 pci0: at device 3.0 (no driver attached) em0: port 0x20c0-0x20df mem 0x90300000-0x9031ffff,0x90324000-0x90324fff irq 20 at device 25.0 on pci0 em0: Ethernet address: 00:19:d1:00:67:40 em0: [ITHREAD] uhci0: port 0x20a0-0x20bf irq 16 at device 26.0 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0x2080-0x209f irq 21 at device 26.1 on pci0 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered ehci0: mem 0x90325400-0x903257ff irq 18 at device 26.7 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb2: EHCI version 1.0 usb2: companion controllers, 2 ports each: usb0 usb1 usb2: on ehci0 usb2: USB revision 2.0 uhub2: on usb2 uhub2: 4 ports with 4 removable, self powered pcm0: mem 0x90320000-0x90323fff irq 22 at device 27.0 on pci0 pcm0: [ITHREAD] pcib1: at device 28.0 on pci0 pci1: on pcib1 pcib2: at device 28.1 on pci0 pci2: on pcib2 atapci0: port 0x1018-0x101f,0x1024-0x1027,0x1010-0x1017,0x1020-0x1023,0x1000-0x100f mem 0x90100000-0x901001ff irq 17 at device 0.0 on pci2 atapci0: [ITHREAD] ata2: on atapci0 ata2: [ITHREAD] pcib3: at device 28.2 on pci0 pci3: on pcib3 pcib4: at device 28.3 on pci0 pci4: on pcib4 pcib5: at device 28.4 on pci0 pci5: on pcib5 uhci2: port 0x2060-0x207f irq 23 at device 29.0 on pci0 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb3: on uhci2 usb3: USB revision 1.0 uhub3: on usb3 uhub3: 2 ports with 2 removable, self powered uhci3: port 0x2040-0x205f irq 19 at device 29.1 on pci0 uhci3: [GIANT-LOCKED] uhci3: [ITHREAD] usb4: on uhci3 usb4: USB revision 1.0 uhub4: on usb4 uhub4: 2 ports with 2 removable, self powered uhci4: port 0x2020-0x203f irq 18 at device 29.2 on pci0 uhci4: [GIANT-LOCKED] uhci4: [ITHREAD] usb5: on uhci4 usb5: USB revision 1.0 uhub5: on usb5 uhub5: 2 ports with 2 removable, self powered ehci1: mem 0x90325000-0x903253ff irq 23 at device 29.7 on pci0 ehci1: [GIANT-LOCKED] ehci1: [ITHREAD] usb6: EHCI version 1.0 usb6: companion controllers, 2 ports each: usb3 usb4 usb5 usb6: on ehci1 usb6: USB revision 2.0 uhub6: on usb6 uhub6: 6 ports with 6 removable, self powered pcib6: at device 30.0 on pci0 pci6: on pcib6 fwohci0: mem 0x90004000-0x900047ff,0x90000000-0x90003fff irq 19 at device 3.0 on pci6 fwohci0: [FILTER] fwohci0: OHCI version 1.10 (ROM=0) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:90:27:00:01:b6:70:64 fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:90:27:b6:70:64 fwe0: Ethernet address: 02:90:27:b6:70:64 sbp0: on firewire0 fwohci0: Initiate bus reset fwohci0: BUS reset fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode isab0: at device 31.0 on pci0 isa0: on isab0 atapci1: port 0x2438-0x243f,0x2454-0x2457,0x2430-0x2437,0x2450-0x2453,0x2410-0x241f,0x2400-0x240f irq 19 at device 31.2 on pci0 atapci1: [ITHREAD] ata3: on atapci1 ata3: [ITHREAD] ata4: on atapci1 ata4: [ITHREAD] pci0: at device 31.3 (no driver attached) atapci2: port 0x2428-0x242f,0x244c-0x244f,0x2420-0x2427,0x2448-0x244b,0x20f0-0x20ff,0x20e0-0x20ef irq 19 at device 31.5 on pci0 atapci2: [ITHREAD] ata5: on atapci2 ata5: [ITHREAD] ata6: on atapci2 ata6: [ITHREAD] fdc0: port 0x3f0-0x3f5,0x3f0 irq 6 drq 2 on acpi0 fdc0: [FILTER] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 ppc0: port 0x378-0x37f,0x778-0x77f irq 7 on acpi0 ppc0: Generic chipset (ECP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold ppbus0: on ppc0 ppi0: on ppbus0 plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppc0: [GIANT-LOCKED] ppc0: [ITHREAD] atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model IntelliMouse, device ID 3 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio0: [FILTER] pmtimer0 on isa0 ata0 at port 0x1f0-0x1f7,0x3f6 irq 14 on isa0 ata0: [ITHREAD] ata1 at port 0x170-0x177,0x376 irq 15 on isa0 ata1: [ITHREAD] sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounters tick every 1.000 msec firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) acd0: DVDR at ata2-master UDMA33 ad6: 286188MB at ata3-master SATA150 pcm0: pcm0: SMP: AP CPU #1 Launched! Kernel config: ============= machine i386 cpu I686_CPU ident DEV7 # To statically compile in device wiring instead of /boot/device.hints #hints "GENERIC.hints" # Default places to look for devices. #makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols #options SCHED_4BSD # 4BSD scheduler options SCHED_ULE options PREEMPTION # Enable kernel thread preemption options INET # InterNETworking options INET6 # IPv6 communications protocols options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories options MD_ROOT # MD is a potential root device options NFSCLIENT # Network Filesystem Client options NFSSERVER # Network Filesystem Server options NFS_ROOT # NFS usable as /, requires NFSCLIENT options MSDOSFS # MSDOS Filesystem options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS # Pseudo-filesystem framework options GEOM_PART_GPT # GUID Partition Tables. options GEOM_LABEL # Provides labelization options COMPAT_43TTY # BSD 4.3 TTY compat [KEEP THIS!] options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options COMPAT_FREEBSD5 # Compatible with FreeBSD5 options COMPAT_FREEBSD6 # Compatible with FreeBSD6 options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options KBD_INSTALL_CDEV # install a CDEV entry in /dev options ADAPTIVE_GIANT # Giant mutex is adaptive. options STOP_NMI # Stop CPUS using NMI instead of IPI # Debugging for use in -current #options KDB # Enable kernel debugger support. #options DDB # Support DDB. #options GDB # Support remote GDB. #options INVARIANTS # Enable calls of extra sanity checking #options INVARIANT_SUPPORT # Extra sanity checks of internal structures, required by INVARIANTS #options WITNESS # Enable checks to detect deadlocks and cycles #options WITNESS_SKIPSPIN # Don't run witness on spinlocks for speed # To make an SMP kernel, the next two lines are needed options SMP # Symmetric MultiProcessor Kernel device apic # I/O APIC # Bus support. #device eisa device pci device smbus device smb #device nfsmb # Floppy drives device fdc # ATA and ATAPI devices device ata device atadisk # ATA disk drives device ataraid # ATA RAID drives device atapicd # ATAPI CDROM drives device atapifd # ATAPI floppy drives device atapist # ATAPI tape drives options ATA_STATIC_ID # Static device numbering # SCSI Controllers # SCSI peripherals device scbus # SCSI bus (required for SCSI) device ch # SCSI media changers device da # Direct Access (disks) device sa # Sequential Access (tape etc) device cd # CD device pass # Passthrough device (direct SCSI access) device ses # SCSI Environmental Services (and SAF-TE) # RAID controllers interfaced to the SCSI subsystem # RAID controllers # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc # AT keyboard controller device atkbd # AT keyboard device psm # PS/2 mouse device kbdmux # keyboard multiplexer device vga # VGA video card driver device splash # Splash screen and screen saver support # syscons is the default console driver, resembling an SCO console device sc device agp # support several AGP chipsets device drm device i915drm device ichwd # Power management support (see NOTES for more options) #device apm # Add suspend/resume support for the i8254. device pmtimer # PCCARD (PCMCIA) support # PCMCIA and cardbus bridge support device cbb # cardbus (yenta) bridge device pccard # PC Card (16-bit) bus device cardbus # CardBus (32-bit) bus # Serial (COM) ports device sio # 8250, 16[45]50 based serial ports device uart # Generic UART driver # Parallel port device ppc device ppbus # Parallel port bus (required) device lpt # Printer device plip # TCP/IP over parallel device ppi # Parallel port interface device #device vpo # Requires scbus and da # If you've got a "dumb" serial or parallel PCI card that is # supported by the puc(4) glue driver, uncomment the following # line to enable it (connects to sio, uart and/or ppc drivers): #device puc # PCI Ethernet NICs. #device de # DEC/Intel DC21x4x (``Tulip'') device em # Intel PRO/1000 adapter Gigabit Ethernet Card #device ixgb # Intel PRO/10GbE Ethernet Card #device le # AMD Am7900 LANCE and Am79C9xx PCnet #device txp # 3Com 3cR990 (``Typhoon'') #device vx # 3Com 3c590, 3c595 (``Vortex'') # PCI Ethernet NICs that use the common MII bus controller code. # NOTE: Be sure to keep the 'device miibus' line in order to use these NICs! device miibus # MII bus support #device bce # Broadcom BCM5706/BCM5708 Gigabit Ethernet #device bfe # Broadcom BCM440x 10/100 Ethernet #device bge # Broadcom BCM570xx Gigabit Ethernet #device dc # DEC/Intel 21143 and various workalikes #device fxp # Intel EtherExpress PRO/100B (82557, 82558) #device lge # Level 1 LXT1001 gigabit Ethernet #device msk # Marvell/SysKonnect Yukon II Gigabit Ethernet #device nge # NatSemi DP83820 gigabit Ethernet #device nve # nVidia nForce MCP on-board Ethernet Networking #device pcn # AMD Am79C97x PCI 10/100 (precedence over 'le') device re # RealTek 8139C+/8169/8169S/8110S device rl # RealTek 8129/8139 #device sf # Adaptec AIC-6915 (``Starfire'') #device sis # Silicon Integrated Systems SiS 900/SiS 7016 #device sk # SysKonnect SK-984x & SK-982x gigabit Ethernet #device ste # Sundance ST201 (D-Link DFE-550TX) #device stge # Sundance/Tamarack TC9021 gigabit Ethernet #device ti # Alteon Networks Tigon I/II gigabit Ethernet #device tl # Texas Instruments ThunderLAN #device tx # SMC EtherPower II (83c170 ``EPIC'') #device vge # VIA VT612x gigabit Ethernet #device vr # VIA Rhine, Rhine II #device wb # Winbond W89C840F device xl # 3Com 3c90x (``Boomerang'', ``Cyclone'') # ISA Ethernet NICs. pccard NICs included. device cs # Crystal Semiconductor CS89x0 NIC # 'device ed' requires 'device miibus' #device ed # NE[12]000, SMC Ultra, 3c503, DS8390 cards #device ex # Intel EtherExpress Pro/10 and Pro/10+ #device ep # Etherlink III based cards #device fe # Fujitsu MB8696x based cards #device ie # EtherExpress 8/16, 3C507, StarLAN 10 etc. #device sn # SMC's 9000 series of Ethernet chips #device xe # Xircom pccard Ethernet # Wireless NIC cards device wlan # 802.11 support device wlan_wep # 802.11 WEP support device wlan_ccmp # 802.11 CCMP support device wlan_tkip # 802.11 TKIP support device an # Aironet 4500/4800 802.11 wireless NICs. device ath # Atheros pci/cardbus NIC's device ath_hal # Atheros HAL (Hardware Access Layer) device ath_rate_sample # SampleRate tx rate control for ath device awi # BayStack 660 and others device ral # Ralink Technology RT2500 wireless NICs. device wi # WaveLAN/Intersil/Symbol 802.11 wireless NICs. #device wl # Older non 802.11 Wavelan wireless NIC. # Pseudo devices. device loop # Network loopback device random # Entropy device device ether # Ethernet support device sl # Kernel SLIP device ppp # Kernel PPP device tun # Packet tunnel. device pty # Pseudo-ttys (telnet etc) device md # Memory "disks" device gif # IPv6 and IPv4 tunneling device faith # IPv6-to-IPv4 relaying (translation) device firmware # firmware assist module # The `bpf' device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! # Note that 'bpf' is required for DHCP. device bpf # Berkeley packet filter # USB support device uhci # UHCI PCI->USB interface device ohci # OHCI PCI->USB interface device ehci # EHCI PCI->USB interface (USB 2.0) device usb # USB Bus (required) #device udbp # USB Double Bulk Pipe devices #device ugen # Generic #device uhid # "Human Interface Devices" #device ukbd # Keyboard #device ulpt # Printer device umass # Disks/Mass storage - Requires scbus and da device ums # Mouse #device ural # Ralink Technology RT2500USB wireless NICs #device urio # Diamond Rio 500 MP3 player #device uscanner # Scanners # USB Ethernet, requires miibus #device aue # ADMtek USB Ethernet #device axe # ASIX Electronics USB Ethernet #device cdce # Generic USB over Ethernet #device cue # CATC USB Ethernet #device kue # Kawasaki LSI USB Ethernet #device rue # RealTek RTL8150 USB Ethernet # FireWire support device firewire # FireWire bus code device sbp # SCSI over FireWire (Requires scbus and da) device fwe # Ethernet over FireWire (non-standard!) options DEVICE_POLLING #options IPFIREWALL options IPFIREWALL_DEFAULT_TO_ACCEPT options IPFIREWALL_FORWARD #options IPDIVERT #options DUMMYNET options IPFIREWALL_VERBOSE options IPFIREWALL_VERBOSE_LIMIT options ALTQ options ALTQ_CBQ # Class Bases Queueing options ALTQ_RED # Random Early Drop options ALTQ_RIO # RED In/Out options ALTQ_HFSC # Hierarchical Packet Scheduler options ALTQ_CDNR # Traffic conditioner options ALTQ_PRIQ # Priority Queueing #options ALTQ_NOPCC # Required for SMP build #options ALTQ_DEBUG options NETGRAPH #options NETGRAPH_MPPC_COMPRESSION #options NETGRAPH_MPPC_ENCRYPTION #options IPSEC #options IPSEC_ESP #options IPSEC_DEBUG #options IPSEC_FILTERGIF #options FAST_IPSEC options HZ=1000 device pf device pflog device carp device pfsync device acpi -- Best regards, Chris mailto:dionch@freemail.gr From owner-freebsd-current@FreeBSD.ORG Wed Jul 18 17:18:48 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6635B16A402 for ; Wed, 18 Jul 2007 17:18:48 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by mx1.freebsd.org (Postfix) with ESMTP id 4D27813C4A6 for ; Wed, 18 Jul 2007 17:18:48 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from relay8.apple.com (relay8.apple.com [17.128.113.38]) by mail-out4.apple.com (Postfix) with ESMTP id 35573C58468; Wed, 18 Jul 2007 10:18:48 -0700 (PDT) Received: from relay8.apple.com (unknown [127.0.0.1]) by relay8.apple.com (Symantec Mail Security) with ESMTP id 2055140117; Wed, 18 Jul 2007 10:18:48 -0700 (PDT) X-AuditID: 11807126-a6446bb0000007e3-87-469e4b78d035 Received: from [17.214.13.96] (cswiger1.apple.com [17.214.13.96]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by relay8.apple.com (Apple SCV relay) with ESMTP id 05D43400F3; Wed, 18 Jul 2007 10:18:48 -0700 (PDT) In-Reply-To: References: <09BFF2FA5EAB4A45B6655E151BBDD9030483F161@NT-IRVA-0750.brcm.ad.broadcom.com> <2E0C9A04-678B-4C44-9D2E-5500F2C08FE7@mac.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <8FC96834-0E90-4BD5-A324-9C39E47F3E8B@mac.com> Content-Transfer-Encoding: 7bit From: Chuck Swiger Date: Wed, 18 Jul 2007 10:18:47 -0700 To: Kip Macy X-Mailer: Apple Mail (2.752.2) X-Brightmail-Tracker: AAAAAA== Cc: David Christensen , current@freebsd.org Subject: Re: Getting/Forcing Greater than 4KB Buffer Allocations X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Jul 2007 17:18:48 -0000 On Jul 17, 2007, at 5:23 PM, Kip Macy wrote: >> Is "sysctl hw.pagesize" different on the two systems? It sure looks >> like the first machine is using a 4KB pagesize, whereas the second >> machine is using an 8KB pagesize... > > There is no such thing as 8k physical pages on ia32 or x86_64. True, but m68k, SPARC, maybe PPC have 8K pages, IIRC... :-) -- -Chuck From owner-freebsd-current@FreeBSD.ORG Wed Jul 18 17:26:59 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 254F216A400 for ; Wed, 18 Jul 2007 17:26:59 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.226]) by mx1.freebsd.org (Postfix) with ESMTP id D4CED13C481 for ; Wed, 18 Jul 2007 17:26:58 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: by wr-out-0506.google.com with SMTP id 67so232241wri for ; Wed, 18 Jul 2007 10:26:58 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=od2rJQhcemqU6FvjECGRxUGj/7bBfsTJlffP0l6jlcoFYwZ/OYB68vxOKzPdHGbzhgYboFu2mp+w4zp8gjwpud3n4Nb6pYzyaGWx5enWxP+S0uaKr9UshyQAWRymkKJGUgjPS7yMyNiVzjcltF1OPqV7ZREslrrb57CI6mb05F4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=rup69riTxBEUtTgqC/qMZLH9zRa79n3rvUhIBS3/tKLC3vSQ+VfnCRWQfMXCaV0nu2RvZ8//QT4DlzbQCLXiSGuUIUd4IIiLEkyTtgs6a1l3xTGPFlmqT30eHFBsCeGW7qFVAFqfunNm6ZPAE8i3crNV/T4S+F03PW6ukPHIwXU= Received: by 10.78.97.7 with SMTP id u7mr514239hub.1184779617231; Wed, 18 Jul 2007 10:26:57 -0700 (PDT) Received: by 10.78.162.18 with HTTP; Wed, 18 Jul 2007 10:26:57 -0700 (PDT) Message-ID: Date: Wed, 18 Jul 2007 10:26:57 -0700 From: "Kip Macy" To: "Chuck Swiger" In-Reply-To: <8FC96834-0E90-4BD5-A324-9C39E47F3E8B@mac.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <09BFF2FA5EAB4A45B6655E151BBDD9030483F161@NT-IRVA-0750.brcm.ad.broadcom.com> <2E0C9A04-678B-4C44-9D2E-5500F2C08FE7@mac.com> <8FC96834-0E90-4BD5-A324-9C39E47F3E8B@mac.com> Cc: David Christensen , current@freebsd.org Subject: Re: Getting/Forcing Greater than 4KB Buffer Allocations X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Jul 2007 17:26:59 -0000 > > True, but m68k, SPARC, maybe PPC have 8K pages, IIRC... :-) Are any of those called Xeon? :D From owner-freebsd-current@FreeBSD.ORG Wed Jul 18 18:24:33 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8B15016A417; Wed, 18 Jul 2007 18:24:33 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.179]) by mx1.freebsd.org (Postfix) with ESMTP id 077E613C4C2; Wed, 18 Jul 2007 18:24:32 +0000 (UTC) (envelope-from max@love2party.net) Received: from [88.66.59.43] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu8) with ESMTP (Nemesis), id 0ML31I-1IBEBx3FFg-0003x5; Wed, 18 Jul 2007 20:24:12 +0200 From: Max Laier Organization: FreeBSD To: Scott Bennett Date: Wed, 18 Jul 2007 20:23:54 +0200 User-Agent: KMail/1.9.7 References: <200707181807.l6II7twY010844@mp.cs.niu.edu> In-Reply-To: <200707181807.l6II7twY010844@mp.cs.niu.edu> X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1451727.14gfUS2vFd"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200707182024.01380.max@love2party.net> X-Provags-ID: V01U2FsdGVkX19eEl6lKuqv1UQWwT/FMzwvOz3QKempCkasCpi xbgx61bo0c8LT5Zj2DylW+nXy8093v1JOaWfCN28LX6oMkiDqe rgheioHifripFD2X5i1DAdw2H1h1/lSLffOeOXQSKA= Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org, Robert Watson Subject: Re: Reminder: NET_NEEDS_GIANT, debug.mpsafenet going away in X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Jul 2007 18:24:33 -0000 --nextPart1451727.14gfUS2vFd Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wednesday 18 July 2007, Scott Bennett wrote: > [Cc: list trimmed a bit more --SB] > On Tue, 17 Jul 2007 23:42:14 +0200 Max Laier > > >[ Excess CC-list ... testers needed!!! ] > > > >On Tuesday 17 July 2007, Robert Watson wrote: > > I missed Robert Watson's start of thread, so I'm jumping in here > with a question. > > >> Dear all: > >> > >> This is a reminder e-mail that, in the very near future, Giant > >> compatibility shims for network protocols will be removed. > > How, if at all, will this affect qemu users? qemu exits unless > AIO is present in the kernel (or aio.ko has been kldload-ed). In > FreeBSD 6.2, AIO results in a warning message at boot time that says > AIO is not MPSAFE and that therefore the networking stack will take a > deep performance hit. This has already been answered in the original thread. AIO is mpsafe as=20 of Tue May 9 00:10:11 2006 (vfs_aio.c, rev 1.223). =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart1451727.14gfUS2vFd Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQBGnlrBXyyEoT62BG0RApVWAJ9SH9zZZo717QOuwMq+zd6dELlKWQCfeJwP h+qN45bwng93dAoptkOzJwQ= =PF1h -----END PGP SIGNATURE----- --nextPart1451727.14gfUS2vFd-- From owner-freebsd-current@FreeBSD.ORG Wed Jul 18 18:27:20 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0FF6616A413 for ; Wed, 18 Jul 2007 18:27:20 +0000 (UTC) (envelope-from gallatin@cs.duke.edu) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.freebsd.org (Postfix) with ESMTP id CA4E013C471 for ; Wed, 18 Jul 2007 18:27:19 +0000 (UTC) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.14.0/8.14.0) with ESMTP id l6IIRJKY006846 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Jul 2007 14:27:19 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.12.9p2/8.12.9/Submit) id l6IIQoiU069552; Wed, 18 Jul 2007 14:26:50 -0400 (EDT) (envelope-from gallatin) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18078.23425.710899.251466@grasshopper.cs.duke.edu> Date: Wed, 18 Jul 2007 14:26:50 -0400 (EDT) To: Mike Tancsa In-Reply-To: <200707180239.l6I2dgD1010356@lava.sentex.ca> References: <200707180239.l6I2dgD1010356@lava.sentex.ca> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Cc: freebsd-current@freebsd.org Subject: Re: chelsio driver and Myricom driver X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2007 18:27:20 -0000 Mike Tancsa writes: > With the Myricom, it seems to work, but it doesnt detect the cx4 > media type for some reason. For mxge, I have no easy way to know from the driver if the media is 10G_LR, 10G_SR, or 10G_CX4, just if the link is up or down. When I integrated the driver in the spring of '06, we didn't even have a 10G_CX4 type, so I confess that I took the easy way out and forgot all about it. It is now on my TODO list. Sorry for the confusion! Drew From owner-freebsd-current@FreeBSD.ORG Wed Jul 18 18:30:45 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 58E6916A401 for ; Wed, 18 Jul 2007 18:30:45 +0000 (UTC) (envelope-from davidch@broadcom.com) Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by mx1.freebsd.org (Postfix) with ESMTP id 2FF9A13C471 for ; Wed, 18 Jul 2007 18:30:44 +0000 (UTC) (envelope-from davidch@broadcom.com) Received: from [10.10.64.154] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.1)); Wed, 18 Jul 2007 11:30:36 -0700 X-Server-Uuid: 6B5CFB92-F616-4477-B110-55F967A57302 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 560292AF; Wed, 18 Jul 2007 11:30:36 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 41D3C2AE; Wed, 18 Jul 2007 11:30:36 -0700 (PDT) Received: from mail-irva-12.broadcom.com (mail-irva-12.broadcom.com [10.10.64.146]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id FME57023; Wed, 18 Jul 2007 11:30:35 -0700 (PDT) Received: from NT-IRVA-0750.brcm.ad.broadcom.com ( nt-irva-0750.brcm.ad.broadcom.com [10.8.194.64]) by mail-irva-12.broadcom.com (Postfix) with ESMTP id D667669CA3; Wed, 18 Jul 2007 11:30:35 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 18 Jul 2007 11:30:33 -0700 Message-ID: <09BFF2FA5EAB4A45B6655E151BBDD9030483F40F@NT-IRVA-0750.brcm.ad.broadcom.com> In-Reply-To: <20070718004530.GV1221@funkthat.com> Thread-Topic: Getting/Forcing Greater than 4KB Buffer Allocations Thread-Index: AcfI1Prfzr1DT2RrSKeAG3+Tcp7VdAAlDzeg References: <09BFF2FA5EAB4A45B6655E151BBDD9030483F161@NT-IRVA-0750.brcm.ad.broadcom.com> <20070718004530.GV1221@funkthat.com> From: "David Christensen" To: "John-Mark Gurney" X-WSS-ID: 6A8083C61S87404455-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: current@freebsd.org Subject: RE: Getting/Forcing Greater than 4KB Buffer Allocations X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Jul 2007 18:30:45 -0000 > > I'm investigating a problem with my bce driver which occurs=20 > when I ask > > for a jumbo > > mbuf cluster (through m_cljget()). When I map the memory for DMA I > > normally=20 > > get 3 memory segments (4KB + 4KB + 1KB) on my system, but on another > > user's=20 > > system he's seeing 2 memory segments (8KB + 1KB). Is there a > > configuration > > option that allows this or some other tuning variable involved? The > > system is a=20 > > Xeon dual-core processor and has 8GB of RAM, running an=20 > AMD64 version of > > the kernel. >=20 > Is this an issue? If it is, you need to fix your bus_dma_tag_create > calls to set the segment size and count properly. bus_dma will get > you exactly what you ask for, and your driver needs to tell bus_dma > what it can and cannot handle. >=20 I believe my code can handle this correctly but you never know for sure until you're able to test it. Are you saying that I can tell bus_dma=20 that I can only handle 2 segments and essentially force this scenario? Could I force more segments to test a maximum value too? Dave From owner-freebsd-current@FreeBSD.ORG Wed Jul 18 18:50:15 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0421B16A402 for ; Wed, 18 Jul 2007 18:50:15 +0000 (UTC) (envelope-from davidch@broadcom.com) Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by mx1.freebsd.org (Postfix) with ESMTP id CD7B113C4BB for ; Wed, 18 Jul 2007 18:50:14 +0000 (UTC) (envelope-from davidch@broadcom.com) Received: from [10.10.64.154] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.1)); Wed, 18 Jul 2007 11:50:06 -0700 X-Server-Uuid: A6C4E0AE-A7F0-449F-BAE7-7FA0D737AC76 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id EA3192AF; Wed, 18 Jul 2007 11:50:05 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id D65272AE; Wed, 18 Jul 2007 11:50:05 -0700 (PDT) Received: from mail-irva-12.broadcom.com (mail-irva-12.broadcom.com [10.10.64.146]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id FME60572; Wed, 18 Jul 2007 11:50:02 -0700 (PDT) Received: from NT-IRVA-0750.brcm.ad.broadcom.com ( nt-irva-0750.brcm.ad.broadcom.com [10.8.194.64]) by mail-irva-12.broadcom.com (Postfix) with ESMTP id B0BB769CAB; Wed, 18 Jul 2007 11:50:02 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 18 Jul 2007 11:50:02 -0700 Message-ID: <09BFF2FA5EAB4A45B6655E151BBDD9030483F437@NT-IRVA-0750.brcm.ad.broadcom.com> In-Reply-To: <20070718021839.GA37935@cdnetworks.co.kr> Thread-Topic: Getting/Forcing Greater than 4KB Buffer Allocations Thread-Index: AcfI4iblUTYXTZ6IQHmw4c1o6L2ISQAieC7Q References: <09BFF2FA5EAB4A45B6655E151BBDD9030483F161@NT-IRVA-0750.brcm.ad.broadcom.com> <20070718021839.GA37935@cdnetworks.co.kr> From: "David Christensen" To: pyunyh@gmail.com X-WSS-ID: 6A80BF543DG10316636-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: current@freebsd.org Subject: RE: Getting/Forcing Greater than 4KB Buffer Allocations X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Jul 2007 18:50:15 -0000 > On Tue, Jul 17, 2007 at 04:54:31PM -0700, David Christensen wrote: > > I'm investigating a problem with my bce driver which=20 > occurs when I ask > > for a jumbo > > mbuf cluster (through m_cljget()). When I map the memory for DMA I > > normally=20 > > get 3 memory segments (4KB + 4KB + 1KB) on my system, but=20 > on another > > user's=20 > > system he's seeing 2 memory segments (8KB + 1KB). Is there a > > configuration > > option that allows this or some other tuning variable=20 > involved? The > > system is a=20 > > Xeon dual-core processor and has 8GB of RAM, running an=20 > AMD64 version of > > the kernel. > > =20 >=20 > I've briefly looked over bus_dma usage on bce(4). It seems that you > told bus_dma the the dma map could be made up of BCE_MAX_SEGMENTS > segments, where a dma segment could be MJUM9BYTES bytes. If you want > just two segments you may have to use 2 instead of BCE_MAX_SEGMENTS. > If the hardware can support up to BCE_MAX_SEGMENTS dma segments on Rx > descriptors you should be prepared to handle that number of dma > segments too(e.g. You don't know how may dma segments would be > returned by bus_dma, you just know the upper bound as you specified > in bus_dma_tag_create()). > If the hardware can handle just up to 4KB for a dma segment you > should tell bus_dma the restriction of the dma segment. > If you have to get a single dma segment that covers MJUM9BYTES bytes > due to the limitation of the hardware you may have to use local > allocator. >=20 Thanks Pyun but I'm really just looking for a way to test that I can handle the number of segments I've advertised that I can support. I=20 believe my code is correct but when all I see are allocations of 3=20 segments I just can't prove it. I was hoping that running a utility such as "stress" would help fragment memory and force more variable responses but that hasn't happened yet. Dave From owner-freebsd-current@FreeBSD.ORG Wed Jul 18 19:48:22 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 98F7716A405; Wed, 18 Jul 2007 19:48:22 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 5F27413C49D; Wed, 18 Jul 2007 19:48:22 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id A0FF646B38; Wed, 18 Jul 2007 15:48:21 -0400 (EDT) Date: Wed, 18 Jul 2007 20:48:21 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Scott Bennett In-Reply-To: <200707181807.l6II7twY010844@mp.cs.niu.edu> Message-ID: <20070718204552.G1096@fledge.watson.org> References: <200707181807.l6II7twY010844@mp.cs.niu.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org, Max Laier Subject: Re: Reminder: NET_NEEDS_GIANT, debug.mpsafenet going away in X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Jul 2007 19:48:22 -0000 On Wed, 18 Jul 2007, Scott Bennett wrote: > [Cc: list trimmed a bit more --SB] > On Tue, 17 Jul 2007 23:42:14 +0200 Max Laier > >> [ Excess CC-list ... testers needed!!! ] >> >> On Tuesday 17 July 2007, Robert Watson wrote: > > I missed Robert Watson's start of thread, so I'm jumping in here > with a question. > >>> This is a reminder e-mail that, in the very near future, Giant >>> compatibility shims for network protocols will be removed. > > How, if at all, will this affect qemu users? qemu exits unless AIO is > present in the kernel (or aio.ko has been kldload-ed). In FreeBSD 6.2, AIO > results in a warning message at boot time that says AIO is not MPSAFE and > that therefore the networking stack will take a deep performance hit. Per several earlier e-mails in the thread, AIO is MPSAFE in FreeBSD 7.0 and, as such, unaffected by this change. As a result, I would expect that applications depending on AIO should now perform significantly better (but have done no measurement in this area). Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Wed Jul 18 19:53:35 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 58C1116A400 for ; Wed, 18 Jul 2007 19:53:35 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.188]) by mx1.freebsd.org (Postfix) with ESMTP id DFB3B13C4AC for ; Wed, 18 Jul 2007 19:53:34 +0000 (UTC) (envelope-from max@love2party.net) Received: from [88.66.59.43] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu7) with ESMTP (Nemesis), id 0ML2xA-1IBFaX3gHt-0002gC; Wed, 18 Jul 2007 21:53:34 +0200 From: Max Laier Organization: FreeBSD To: freebsd-current@freebsd.org Date: Wed, 18 Jul 2007 21:55:56 +0200 User-Agent: KMail/1.9.7 References: <20070717182819.L92541@10.0.0.1> In-Reply-To: <20070717182819.L92541@10.0.0.1> X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart17172390.Hft8vRoxWe"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200707182156.03769.max@love2party.net> X-Provags-ID: V01U2FsdGVkX19WxT0nRTu/f0KRxyJpsIWYvnuR3AJulpY3tsM 9hg+ioP/yXfBQu/O9YzoO/O98kziTYvMQW0lYG61HJWH490hU6 ktgOVqXsv91Am6MsSeVl4wxXWWMlPxA9/WOZ6uxdO4= Cc: Jeff Roberson Subject: Re: cvs commit: src/sys/kern sched_ule.c (fwd) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Jul 2007 19:53:35 -0000 --nextPart17172390.Hft8vRoxWe Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wednesday 18 July 2007, Jeff Roberson wrote: > Thanks everyone for your help. In summary it sounds like there are two > issues. > > 1) kqemu explicitly uses sched_lock. I'll see if I can contact the > author about fixing this. > > 2) As much as a 6-7% slowdown on buildworld on dual core machines as > compared to 4BSD. I'm not sure if I'm going to do anything about this. > Once you get to 4 or 8 cores and -j8 or more they even out with ULE > having significantly less system time. I don't know if I want to > compromise that for slightly better dual core compile times. 3) nice(1) trouble? I wrote a quick script to fork off a couple of "yes > /dev/null" to stress= =20 test and it works really really fine. However, if I nice down the script=20 it panics with | spin lock 0xffffffff806e5380 (sched lock 2) held by 0xffffff0001227000 | (tid 100000) too long=20 | panic: spin lock held too long This is almost 100% repeatable after 30-60 seconds, even with only 4 yes=20 instances (where 4 is the # of CPUs). > This is in the tree for 7.0 now though. I'm very excited to see this > happen. > > Thanks again, > Jeff > > ---------- Forwarded message ---------- > Date: Tue, 17 Jul 2007 22:53:24 +0000 (UTC) > From: Jeff Roberson > To: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, > cvs-all@FreeBSD.org Subject: cvs commit: src/sys/kern sched_ule.c > > jeff 2007-07-17 22:53:24 UTC > > FreeBSD src repository > > Modified files: > sys/kern sched_ule.c > Log: > ULE 3.0: Fine grain scheduler locking and affinity improvements.=20 > This has been in development for over 6 months as SCHED_SMP. > - Implement one spin lock per thread-queue. Threads assigned to a > run-queue point to this lock via td_lock. > - Improve the facility for assigning threads to CPUs now that > sched_lock contention no longer dominates scheduling decisions on > larger SMP machines. > - Re-write idle time stealing in an attempt to make it less > damaging to general performance. This is still disabled by default. > See kern.sched.steal_idle. > - Call the long-term load balancer from a callout rather than > sched_clock() so there are no locks held. This is disabled by default. > See kern.sched.balance. > - Parameterize many scheduling decisions via sysctls. Try to > document these via sysctl descriptions. > - General structural and naming cleanups. > - Document each function with comments. > > Tested by: current@ amd64, x86, UP, SMP. > Approved by: re > > Revision Changes Path > 1.200 +917 -549 src/sys/kern/sched_ule.c > _______________________________________________ > 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" =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart17172390.Hft8vRoxWe Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQBGnnBTXyyEoT62BG0RAsaSAJ95EgSyE6wJuBeSCg4Drt3zjdEAbQCfSAmF HKnI6TZFMUcGJMEFqJ3aWJc= =KWc8 -----END PGP SIGNATURE----- --nextPart17172390.Hft8vRoxWe-- From owner-freebsd-current@FreeBSD.ORG Wed Jul 18 19:54:55 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A8AC116A40A for ; Wed, 18 Jul 2007 19:54:55 +0000 (UTC) (envelope-from almarrie@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.240]) by mx1.freebsd.org (Postfix) with ESMTP id 5AE1B13C4A5 for ; Wed, 18 Jul 2007 19:54:55 +0000 (UTC) (envelope-from almarrie@gmail.com) Received: by an-out-0708.google.com with SMTP id c14so76760anc for ; Wed, 18 Jul 2007 12:54:54 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=NZZXHEo0x2HiSC0pYGT+XtOTUzHmM1c60bH6dphn11ShojSkxuvACpX/WnuYKu0wAh4MbfUCRojG243HRQSXdLT9Jgew8sbVF+q+ihNnJzzoofd3mhARb4KlLSEn3+2QWVZYLZJLCxKN7xo9D9/mxAIEGdL8dsehO7uQV7b71Ew= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ANsADj6CEjO5eK3PE8lK+eR4PfHa8F89c0qzeWdhf9hPVfBkZC8lpN0Wc4YuXV1192iz64C7vcTJrse2VsvZAwEpEXMWMkuUecGIZR3kD0HUyF2rlW8wIYcDLDSOIOCDl6jqfcj69Cmmr73v7ZrPNrF69JioDgeJZZ/+Cbzrq4g= Received: by 10.100.13.12 with SMTP id 12mr1144979anm.1184788494299; Wed, 18 Jul 2007 12:54:54 -0700 (PDT) Received: by 10.100.9.14 with HTTP; Wed, 18 Jul 2007 12:54:54 -0700 (PDT) Message-ID: <499c70c0707181254j23c3ca39mcb17f6aa8fbc0de8@mail.gmail.com> Date: Wed, 18 Jul 2007 22:54:54 +0300 From: "Abdullah Ibn Hamad Al-Marri" To: "Jeff Roberson" In-Reply-To: <20070717182819.L92541@10.0.0.1> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070717182819.L92541@10.0.0.1> Cc: current@freebsd.org Subject: Re: cvs commit: src/sys/kern sched_ule.c (fwd) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Jul 2007 19:54:55 -0000 On 7/18/07, Jeff Roberson wrote: > Thanks everyone for your help. In summary it sounds like there are two > issues. > > 1) kqemu explicitly uses sched_lock. I'll see if I can contact the > author about fixing this. > > 2) As much as a 6-7% slowdown on buildworld on dual core machines as > compared to 4BSD. I'm not sure if I'm going to do anything about this. > Once you get to 4 or 8 cores and -j8 or more they even out with ULE having > significantly less system time. I don't know if I want to compromise that > for slightly better dual core compile times. > > This is in the tree for 7.0 now though. I'm very excited to see this > happen. Thank you Jeff, Dr. Robert, jhb, and the rest of you commiters who worked very hard to make this comes true, and we finally got rid of giant lock, and FreeBSD is fast as we we knew it in the 90s. I have UP P4 2.0 GHz i386 and AMD64 powered by Intel C2D E6600 using it and it's so solid since more than 24 hours and no stability of slow performance issues appeared till now :) Both running heavy MySQL server with too many queries make it busy 24/7. -- Regards, -Abdullah Ibn Hamad Al-Marri Arab Portal http://www.WeArab.Net/ From owner-freebsd-current@FreeBSD.ORG Wed Jul 18 20:04:36 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CF6D516A404 for ; Wed, 18 Jul 2007 20:04:36 +0000 (UTC) (envelope-from rpaulo@fnop.net) Received: from core.fnop.net (mx.fnop.net [82.102.11.82]) by mx1.freebsd.org (Postfix) with ESMTP id 4A86113C491 for ; Wed, 18 Jul 2007 20:04:36 +0000 (UTC) (envelope-from rpaulo@fnop.net) Received: from core.fnop.net (mx.fnop.net [82.102.11.82]) by core.fnop.net (Postfix) with ESMTP id 6CA4C690D5D; Wed, 18 Jul 2007 20:58:38 +0100 (WEST) Received: by core.fnop.net (Postfix, from userid 1015) id 2B58F690D8E; Wed, 18 Jul 2007 20:58:38 +0100 (WEST) X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on core.fnop.net X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00, DATE_IN_PAST_03_06,FORGED_RCVD_HELO autolearn=ham version=3.1.7 Received: from epsilon.local (62.169.111.86.rev.optimus.pt [62.169.111.86]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by core.fnop.net (Postfix) with ESMTP id F3384690D5D; Wed, 18 Jul 2007 20:58:35 +0100 (WEST) Message-ID: <469E2F53.9040805@fnop.net> Date: Wed, 18 Jul 2007 16:18:43 +0100 From: Rui Paulo User-Agent: Thunderbird 2.0.0.4 (X11/20070704) MIME-Version: 1.0 To: d@delphij.net References: <469D651C.6080504@fnop.net> <469D6D3A.6070408@delphij.net> In-Reply-To: <469D6D3A.6070408@delphij.net> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: current@freebsd.org Subject: Re: less -r broken with long lines X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Jul 2007 20:04:36 -0000 LI Xin wrote: > Hi, > > Rui Paulo wrote: >> Hi, >> There's something about how the new less version handles lines greater >> than the virtual terminal's size. >> >> Test case on an xterm/rxvt/screen session: >> >> less -r /etc/syslog.conf - you won't see the $FreeBSD$ id tag because >> of the long line regarding to /var/log/messages. Try resizing your >> terminal so that this line fits in the right number of columns. You'll >> see the problem disappear. >> >> less -r /etc/rc.firewall - since there are no long lines in the first >> page, you won't notice the problem >> >> Everything works fine if less is used without the -r argument or if less >> is run from the console. >> >> Does this ring any bell to anyone? > > Are you sure that this is not expected behavior? I have tried less v394 > on a 6.2-RELEASE box and it seems that the behavior is the same... Well, if this is the expected behavior, I never noticed it before. Sorry for the noise. -- Rui Paulo From owner-freebsd-current@FreeBSD.ORG Wed Jul 18 20:09:55 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9A10016A402 for ; Wed, 18 Jul 2007 20:09:55 +0000 (UTC) (envelope-from rpaulo@fnop.net) Received: from core.fnop.net (mx.fnop.net [82.102.11.82]) by mx1.freebsd.org (Postfix) with ESMTP id 2DD0713C48D for ; Wed, 18 Jul 2007 20:09:55 +0000 (UTC) (envelope-from rpaulo@fnop.net) Received: from core.fnop.net (mx.fnop.net [82.102.11.82]) by core.fnop.net (Postfix) with ESMTP id B30A9690D8E; Wed, 18 Jul 2007 21:03:57 +0100 (WEST) Received: by core.fnop.net (Postfix, from userid 1015) id 4DA91690E1A; Wed, 18 Jul 2007 21:03:57 +0100 (WEST) X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on core.fnop.net X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.7 Received: from epsilon.local (62.169.111.86.rev.optimus.pt [62.169.111.86]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by core.fnop.net (Postfix) with ESMTP id 2C3FD690D8E; Wed, 18 Jul 2007 21:03:55 +0100 (WEST) Message-ID: <469E737B.5090609@fnop.net> Date: Wed, 18 Jul 2007 21:09:31 +0100 From: Rui Paulo User-Agent: Thunderbird 2.0.0.4 (X11/20070704) MIME-Version: 1.0 To: Fred Gilham References: <469D651C.6080504@fnop.net> <40882.1184765616@snapdragon.csl.sri.com> In-Reply-To: <40882.1184765616@snapdragon.csl.sri.com> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: current@freebsd.org Subject: Re: less -r broken with long lines X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Jul 2007 20:09:55 -0000 Fred Gilham wrote: > Rui Paulo wrote: > >> Hi, >> There's something about how the new less version handles lines greater >> than the virtual terminal's size. >> >> Test case on an xterm/rxvt/screen session: >> >> less -r /etc/syslog.conf - you won't see the $FreeBSD$ id tag because >> of the long line regarding to /var/log/messages. Try resizing your >> terminal so that this line fits in the right number of columns. You'll >> see the problem disappear. >> >> less -r /etc/rc.firewall - since there are no long lines in the first >> page, you won't notice the problem >> >> Everything works fine if less is used without the -r argument or if less >> is run from the console. >> >> Does this ring any bell to anyone? >> >> Regards. >> -- >> Rui Paulo > > This is documented behavior. From the "less" manpage: > > -r or --raw-control-chars > Causes "raw" control characters to be displayed. The default is > to display control characters using the caret notation; for > example, a control-A (octal 001) is displayed as "^A". Warning: > when the -r option is used, less cannot keep track of the actual > appearance of the screen (since this depends on how the screen > responds to each type of control character). Thus, various dis- > play problems may result, such as long lines being split in the > wrong place. It depends on the interpretation. "various display problems may result" may very well be a reference to the fact that control characters mangle the output. I wasn't expecting long lines to mangle the output. If you less -r a file without control characters, but with a least a line wider than your screen size, you'll notice the problem. But, either way, less has been doing this for ages. I just took a long time to notice it. Regards. -- Rui Paulo From owner-freebsd-current@FreeBSD.ORG Wed Jul 18 20:19:09 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A254D16A400 for ; Wed, 18 Jul 2007 20:19:09 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from webaccess-cl.virtdom.com (webaccess-cl.virtdom.com [216.240.101.25]) by mx1.freebsd.org (Postfix) with ESMTP id 3601113C48D for ; Wed, 18 Jul 2007 20:19:09 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from [192.168.1.101] (c-71-231-138-78.hsd1.or.comcast.net [71.231.138.78]) (authenticated bits=0) by webaccess-cl.virtdom.com (8.13.6/8.13.6) with ESMTP id l6IKJ66N051106 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Wed, 18 Jul 2007 16:19:07 -0400 (EDT) (envelope-from jroberson@chesapeake.net) Date: Wed, 18 Jul 2007 13:22:20 -0700 (PDT) From: Jeff Roberson X-X-Sender: jroberson@10.0.0.1 To: Chris Dionissopoulos In-Reply-To: <645205041.20070718185511@freemail.gr> Message-ID: <20070718131846.Q561@10.0.0.1> References: <20070716233030.D92541@10.0.0.1> <645205041.20070718185511@freemail.gr> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: current@freebsd.org Subject: Re: ULE/SCHED_SMP diff for 7.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2007 20:19:09 -0000 On Wed, 18 Jul 2007, Chris Dionissopoulos wrote: > Hello Jeff, > > > It works for me, but for some reason load averages gone x1000!! Hi, Interestingly this was a problem people had with earlier versions of the patch but you are the first report with this iteration. Can you please test with INVARIANTS, DDB, KDB, and WITNESS in your kernel so you can get a stack trace if anything goes wrong. Thanks, Jeff > > > last pid: 12626; load averages: 314.40, 282.08, 187.64 up 0+01:16:23 18:49:56 > 84 processes: 2 running, 82 sleeping > CPU states: 11.8% user, 0.0% nice, 1.5% system, 0.4% interrupt, 86.4% idle > Mem: 672M Active, 452M Inact, 144M Wired, 776K Cache, 112M Buf, 708M Free > Swap: 1024M Total, 1024M Free > > usually I have load averages 0.15 - 0.5. > > kernel and world binaries cvsuped 2 hours ago. > > > dmesg: > ======= > Copyright (c) 1992-2007 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 7.0-CURRENT #2: Wed Jul 18 17:01:15 EEST 2007 > root@mail.debug.gr:/usr/obj/usr/src/sys/DEV7 > ACPI APIC Table: > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: Intel(R) Core(TM)2 CPU 6300 @ 1.86GHz (1876.00-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0x6f6 Stepping = 6 > Features=0xbfebfbff > Features2=0xe3bd > AMD Features=0x20100000 > AMD Features2=0x1 > Logical CPUs per core: 2 > real memory = 2120540160 (2022 MB) > avail memory = 2069549056 (1973 MB) > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 1 > ioapic0: Changing APIC ID to 2 > ioapic0 irqs 0-23 on motherboard > kbd1 at kbdmux0 > ichwd module loaded > ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) > acpi0: on motherboard > acpi0: [ITHREAD] > acpi0: Power Button (fixed) > Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 > cpu0: on acpi0 > est0: on cpu0 > p4tcc0: on cpu0 > cpu1: on acpi0 > est1: on cpu1 > p4tcc1: on cpu1 > acpi_button0: on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > vgapci0: port 0x2440-0x2447 mem 0x90200000-0x902fffff,0x80000000-0x8fffffff irq 16 at device 2.0 on pci0 > agp0: on vgapci0 > agp0: detected 7676k stolen memory > agp0: aperture size is 256M > drm0: on vgapci0 > info: [drm] AGP at 0x80000000 256MB > info: [drm] Initialized i915 1.5.0 20060119 > pci0: at device 3.0 (no driver attached) > em0: port 0x20c0-0x20df mem 0x90300000-0x9031ffff,0x90324000-0x90324fff irq 20 at device 25.0 on pci0 > em0: Ethernet address: 00:19:d1:00:67:40 > em0: [ITHREAD] > uhci0: port 0x20a0-0x20bf irq 16 at device 26.0 on pci0 > uhci0: [GIANT-LOCKED] > uhci0: [ITHREAD] > usb0: on uhci0 > usb0: USB revision 1.0 > uhub0: on usb0 > uhub0: 2 ports with 2 removable, self powered > uhci1: port 0x2080-0x209f irq 21 at device 26.1 on pci0 > uhci1: [GIANT-LOCKED] > uhci1: [ITHREAD] > usb1: on uhci1 > usb1: USB revision 1.0 > uhub1: on usb1 > uhub1: 2 ports with 2 removable, self powered > ehci0: mem 0x90325400-0x903257ff irq 18 at device 26.7 on pci0 > ehci0: [GIANT-LOCKED] > ehci0: [ITHREAD] > usb2: EHCI version 1.0 > usb2: companion controllers, 2 ports each: usb0 usb1 > usb2: on ehci0 > usb2: USB revision 2.0 > uhub2: on usb2 > uhub2: 4 ports with 4 removable, self powered > pcm0: mem 0x90320000-0x90323fff irq 22 at device 27.0 on pci0 > pcm0: [ITHREAD] > pcib1: at device 28.0 on pci0 > pci1: on pcib1 > pcib2: at device 28.1 on pci0 > pci2: on pcib2 > atapci0: port 0x1018-0x101f,0x1024-0x1027,0x1010-0x1017,0x1020-0x1023,0x1000-0x100f mem 0x90100000-0x901001ff irq 17 at device 0.0 on pci2 > atapci0: [ITHREAD] > ata2: on atapci0 > ata2: [ITHREAD] > pcib3: at device 28.2 on pci0 > pci3: on pcib3 > pcib4: at device 28.3 on pci0 > pci4: on pcib4 > pcib5: at device 28.4 on pci0 > pci5: on pcib5 > uhci2: port 0x2060-0x207f irq 23 at device 29.0 on pci0 > uhci2: [GIANT-LOCKED] > uhci2: [ITHREAD] > usb3: on uhci2 > usb3: USB revision 1.0 > uhub3: on usb3 > uhub3: 2 ports with 2 removable, self powered > uhci3: port 0x2040-0x205f irq 19 at device 29.1 on pci0 > uhci3: [GIANT-LOCKED] > uhci3: [ITHREAD] > usb4: on uhci3 > usb4: USB revision 1.0 > uhub4: on usb4 > uhub4: 2 ports with 2 removable, self powered > uhci4: port 0x2020-0x203f irq 18 at device 29.2 on pci0 > uhci4: [GIANT-LOCKED] > uhci4: [ITHREAD] > usb5: on uhci4 > usb5: USB revision 1.0 > uhub5: on usb5 > uhub5: 2 ports with 2 removable, self powered > ehci1: mem 0x90325000-0x903253ff irq 23 at device 29.7 on pci0 > ehci1: [GIANT-LOCKED] > ehci1: [ITHREAD] > usb6: EHCI version 1.0 > usb6: companion controllers, 2 ports each: usb3 usb4 usb5 > usb6: on ehci1 > usb6: USB revision 2.0 > uhub6: on usb6 > uhub6: 6 ports with 6 removable, self powered > pcib6: at device 30.0 on pci0 > pci6: on pcib6 > fwohci0: mem 0x90004000-0x900047ff,0x90000000-0x90003fff irq 19 at device 3.0 on pci6 > fwohci0: [FILTER] > fwohci0: OHCI version 1.10 (ROM=0) > fwohci0: No. of Isochronous channels is 4. > fwohci0: EUI64 00:90:27:00:01:b6:70:64 > fwohci0: Phy 1394a available S400, 2 ports. > fwohci0: Link S400, max_rec 2048 bytes. > firewire0: on fwohci0 > fwe0: on firewire0 > if_fwe0: Fake Ethernet address: 02:90:27:b6:70:64 > fwe0: Ethernet address: 02:90:27:b6:70:64 > sbp0: on firewire0 > fwohci0: Initiate bus reset > fwohci0: BUS reset > fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode > isab0: at device 31.0 on pci0 > isa0: on isab0 > atapci1: port 0x2438-0x243f,0x2454-0x2457,0x2430-0x2437,0x2450-0x2453,0x2410-0x241f,0x2400-0x240f irq 19 at device 31.2 on pci0 > atapci1: [ITHREAD] > ata3: on atapci1 > ata3: [ITHREAD] > ata4: on atapci1 > ata4: [ITHREAD] > pci0: at device 31.3 (no driver attached) > atapci2: port 0x2428-0x242f,0x244c-0x244f,0x2420-0x2427,0x2448-0x244b,0x20f0-0x20ff,0x20e0-0x20ef irq 19 at device 31.5 on pci0 > atapci2: [ITHREAD] > ata5: on atapci2 > ata5: [ITHREAD] > ata6: on atapci2 > ata6: [ITHREAD] > fdc0: port 0x3f0-0x3f5,0x3f0 irq 6 drq 2 on acpi0 > fdc0: [FILTER] > fd0: <1440-KB 3.5" drive> on fdc0 drive 0 > ppc0: port 0x378-0x37f,0x778-0x77f irq 7 on acpi0 > ppc0: Generic chipset (ECP/PS2/NIBBLE) in COMPATIBLE mode > ppc0: FIFO with 16/16/8 bytes threshold > ppbus0: on ppc0 > ppi0: on ppbus0 > plip0: on ppbus0 > lpt0: on ppbus0 > lpt0: Interrupt-driven port > ppc0: [GIANT-LOCKED] > ppc0: [ITHREAD] > atkbdc0: port 0x60,0x64 irq 1 on acpi0 > atkbd0: irq 1 on atkbdc0 > kbd0 at atkbd0 > atkbd0: [GIANT-LOCKED] > atkbd0: [ITHREAD] > psm0: irq 12 on atkbdc0 > psm0: [GIANT-LOCKED] > psm0: [ITHREAD] > psm0: model IntelliMouse, device ID 3 > sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 > sio0: type 16550A > sio0: [FILTER] > pmtimer0 on isa0 > ata0 at port 0x1f0-0x1f7,0x3f6 irq 14 on isa0 > ata0: [ITHREAD] > ata1 at port 0x170-0x177,0x376 irq 15 on isa0 > ata1: [ITHREAD] > sc0: at flags 0x100 on isa0 > sc0: VGA <16 virtual consoles, flags=0x300> > sio1: configured irq 3 not in bitmap of probed irqs 0 > sio1: port may not be enabled > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > Timecounters tick every 1.000 msec > firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) > firewire0: bus manager 0 (me) > acd0: DVDR at ata2-master UDMA33 > ad6: 286188MB at ata3-master SATA150 > pcm0: > pcm0: > SMP: AP CPU #1 Launched! > > > Kernel config: > ============= > machine i386 > cpu I686_CPU > ident DEV7 > > # To statically compile in device wiring instead of /boot/device.hints > #hints "GENERIC.hints" # Default places to look for devices. > > #makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols > > #options SCHED_4BSD # 4BSD scheduler > options SCHED_ULE > options PREEMPTION # Enable kernel thread preemption > options INET # InterNETworking > options INET6 # IPv6 communications protocols > options FFS # Berkeley Fast Filesystem > options SOFTUPDATES # Enable FFS soft updates support > options UFS_ACL # Support for access control lists > options UFS_DIRHASH # Improve performance on big directories > options MD_ROOT # MD is a potential root device > options NFSCLIENT # Network Filesystem Client > options NFSSERVER # Network Filesystem Server > options NFS_ROOT # NFS usable as /, requires NFSCLIENT > options MSDOSFS # MSDOS Filesystem > options CD9660 # ISO 9660 Filesystem > options PROCFS # Process filesystem (requires PSEUDOFS) > options PSEUDOFS # Pseudo-filesystem framework > options GEOM_PART_GPT # GUID Partition Tables. > options GEOM_LABEL # Provides labelization > options COMPAT_43TTY # BSD 4.3 TTY compat [KEEP THIS!] > options COMPAT_FREEBSD4 # Compatible with FreeBSD4 > options COMPAT_FREEBSD5 # Compatible with FreeBSD5 > options COMPAT_FREEBSD6 # Compatible with FreeBSD6 > options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI > options KTRACE # ktrace(1) support > options SYSVSHM # SYSV-style shared memory > options SYSVMSG # SYSV-style message queues > options SYSVSEM # SYSV-style semaphores > options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions > options KBD_INSTALL_CDEV # install a CDEV entry in /dev > options ADAPTIVE_GIANT # Giant mutex is adaptive. > options STOP_NMI # Stop CPUS using NMI instead of IPI > > # Debugging for use in -current > #options KDB # Enable kernel debugger support. > #options DDB # Support DDB. > #options GDB # Support remote GDB. > #options INVARIANTS # Enable calls of extra sanity checking > #options INVARIANT_SUPPORT # Extra sanity checks of internal structures, required by INVARIANTS > #options WITNESS # Enable checks to detect deadlocks and cycles > #options WITNESS_SKIPSPIN # Don't run witness on spinlocks for speed > > # To make an SMP kernel, the next two lines are needed > options SMP # Symmetric MultiProcessor Kernel > device apic # I/O APIC > > # Bus support. > #device eisa > device pci > device smbus > device smb > #device nfsmb > > # Floppy drives > device fdc > > # ATA and ATAPI devices > device ata > device atadisk # ATA disk drives > device ataraid # ATA RAID drives > device atapicd # ATAPI CDROM drives > device atapifd # ATAPI floppy drives > device atapist # ATAPI tape drives > options ATA_STATIC_ID # Static device numbering > > # SCSI Controllers > # SCSI peripherals > device scbus # SCSI bus (required for SCSI) > device ch # SCSI media changers > device da # Direct Access (disks) > device sa # Sequential Access (tape etc) > device cd # CD > device pass # Passthrough device (direct SCSI access) > device ses # SCSI Environmental Services (and SAF-TE) > > # RAID controllers interfaced to the SCSI subsystem > # RAID controllers > > # atkbdc0 controls both the keyboard and the PS/2 mouse > device atkbdc # AT keyboard controller > device atkbd # AT keyboard > device psm # PS/2 mouse > > device kbdmux # keyboard multiplexer > > device vga # VGA video card driver > > device splash # Splash screen and screen saver support > > # syscons is the default console driver, resembling an SCO console > device sc > > device agp # support several AGP chipsets > device drm > device i915drm > device ichwd > # Power management support (see NOTES for more options) > #device apm > # Add suspend/resume support for the i8254. > device pmtimer > > # PCCARD (PCMCIA) support > # PCMCIA and cardbus bridge support > device cbb # cardbus (yenta) bridge > device pccard # PC Card (16-bit) bus > device cardbus # CardBus (32-bit) bus > > # Serial (COM) ports > device sio # 8250, 16[45]50 based serial ports > device uart # Generic UART driver > > # Parallel port > device ppc > device ppbus # Parallel port bus (required) > device lpt # Printer > device plip # TCP/IP over parallel > device ppi # Parallel port interface device > #device vpo # Requires scbus and da > > # If you've got a "dumb" serial or parallel PCI card that is > # supported by the puc(4) glue driver, uncomment the following > # line to enable it (connects to sio, uart and/or ppc drivers): > #device puc > > # PCI Ethernet NICs. > #device de # DEC/Intel DC21x4x (``Tulip'') > device em # Intel PRO/1000 adapter Gigabit Ethernet Card > #device ixgb # Intel PRO/10GbE Ethernet Card > #device le # AMD Am7900 LANCE and Am79C9xx PCnet > #device txp # 3Com 3cR990 (``Typhoon'') > #device vx # 3Com 3c590, 3c595 (``Vortex'') > > # PCI Ethernet NICs that use the common MII bus controller code. > # NOTE: Be sure to keep the 'device miibus' line in order to use these NICs! > device miibus # MII bus support > #device bce # Broadcom BCM5706/BCM5708 Gigabit Ethernet > #device bfe # Broadcom BCM440x 10/100 Ethernet > #device bge # Broadcom BCM570xx Gigabit Ethernet > #device dc # DEC/Intel 21143 and various workalikes > #device fxp # Intel EtherExpress PRO/100B (82557, 82558) > #device lge # Level 1 LXT1001 gigabit Ethernet > #device msk # Marvell/SysKonnect Yukon II Gigabit Ethernet > #device nge # NatSemi DP83820 gigabit Ethernet > #device nve # nVidia nForce MCP on-board Ethernet Networking > #device pcn # AMD Am79C97x PCI 10/100 (precedence over 'le') > device re # RealTek 8139C+/8169/8169S/8110S > device rl # RealTek 8129/8139 > #device sf # Adaptec AIC-6915 (``Starfire'') > #device sis # Silicon Integrated Systems SiS 900/SiS 7016 > #device sk # SysKonnect SK-984x & SK-982x gigabit Ethernet > #device ste # Sundance ST201 (D-Link DFE-550TX) > #device stge # Sundance/Tamarack TC9021 gigabit Ethernet > #device ti # Alteon Networks Tigon I/II gigabit Ethernet > #device tl # Texas Instruments ThunderLAN > #device tx # SMC EtherPower II (83c170 ``EPIC'') > #device vge # VIA VT612x gigabit Ethernet > #device vr # VIA Rhine, Rhine II > #device wb # Winbond W89C840F > device xl # 3Com 3c90x (``Boomerang'', ``Cyclone'') > > # ISA Ethernet NICs. pccard NICs included. > device cs # Crystal Semiconductor CS89x0 NIC > # 'device ed' requires 'device miibus' > #device ed # NE[12]000, SMC Ultra, 3c503, DS8390 cards > #device ex # Intel EtherExpress Pro/10 and Pro/10+ > #device ep # Etherlink III based cards > #device fe # Fujitsu MB8696x based cards > #device ie # EtherExpress 8/16, 3C507, StarLAN 10 etc. > #device sn # SMC's 9000 series of Ethernet chips > #device xe # Xircom pccard Ethernet > > # Wireless NIC cards > device wlan # 802.11 support > device wlan_wep # 802.11 WEP support > device wlan_ccmp # 802.11 CCMP support > device wlan_tkip # 802.11 TKIP support > device an # Aironet 4500/4800 802.11 wireless NICs. > device ath # Atheros pci/cardbus NIC's > device ath_hal # Atheros HAL (Hardware Access Layer) > device ath_rate_sample # SampleRate tx rate control for ath > device awi # BayStack 660 and others > device ral # Ralink Technology RT2500 wireless NICs. > device wi # WaveLAN/Intersil/Symbol 802.11 wireless NICs. > #device wl # Older non 802.11 Wavelan wireless NIC. > > # Pseudo devices. > device loop # Network loopback > device random # Entropy device > device ether # Ethernet support > device sl # Kernel SLIP > device ppp # Kernel PPP > device tun # Packet tunnel. > device pty # Pseudo-ttys (telnet etc) > device md # Memory "disks" > device gif # IPv6 and IPv4 tunneling > device faith # IPv6-to-IPv4 relaying (translation) > device firmware # firmware assist module > > # The `bpf' device enables the Berkeley Packet Filter. > # Be aware of the administrative consequences of enabling this! > # Note that 'bpf' is required for DHCP. > device bpf # Berkeley packet filter > > # USB support > device uhci # UHCI PCI->USB interface > device ohci # OHCI PCI->USB interface > device ehci # EHCI PCI->USB interface (USB 2.0) > device usb # USB Bus (required) > #device udbp # USB Double Bulk Pipe devices > #device ugen # Generic > #device uhid # "Human Interface Devices" > #device ukbd # Keyboard > #device ulpt # Printer > device umass # Disks/Mass storage - Requires scbus and da > device ums # Mouse > #device ural # Ralink Technology RT2500USB wireless NICs > #device urio # Diamond Rio 500 MP3 player > #device uscanner # Scanners > # USB Ethernet, requires miibus > #device aue # ADMtek USB Ethernet > #device axe # ASIX Electronics USB Ethernet > #device cdce # Generic USB over Ethernet > #device cue # CATC USB Ethernet > #device kue # Kawasaki LSI USB Ethernet > #device rue # RealTek RTL8150 USB Ethernet > > # FireWire support > device firewire # FireWire bus code > device sbp # SCSI over FireWire (Requires scbus and da) > device fwe # Ethernet over FireWire (non-standard!) > > > > options DEVICE_POLLING > > #options IPFIREWALL > options IPFIREWALL_DEFAULT_TO_ACCEPT > options IPFIREWALL_FORWARD > #options IPDIVERT > #options DUMMYNET > options IPFIREWALL_VERBOSE > options IPFIREWALL_VERBOSE_LIMIT > > options ALTQ > options ALTQ_CBQ # Class Bases Queueing > options ALTQ_RED # Random Early Drop > options ALTQ_RIO # RED In/Out > options ALTQ_HFSC # Hierarchical Packet Scheduler > options ALTQ_CDNR # Traffic conditioner > options ALTQ_PRIQ # Priority Queueing > > #options ALTQ_NOPCC # Required for SMP build > #options ALTQ_DEBUG > > > options NETGRAPH > #options NETGRAPH_MPPC_COMPRESSION > #options NETGRAPH_MPPC_ENCRYPTION > #options IPSEC > #options IPSEC_ESP > #options IPSEC_DEBUG > #options IPSEC_FILTERGIF > #options FAST_IPSEC > > options HZ=1000 > > device pf > device pflog > device carp > device pfsync > > device acpi > > > > -- > Best regards, > Chris mailto:dionch@freemail.gr > From owner-freebsd-current@FreeBSD.ORG Wed Jul 18 20:32:29 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 357FA16A405 for ; Wed, 18 Jul 2007 20:32:29 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from webaccess-cl.virtdom.com (webaccess-cl.virtdom.com [216.240.101.25]) by mx1.freebsd.org (Postfix) with ESMTP id 0C37C13C4B5 for ; Wed, 18 Jul 2007 20:32:28 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from [192.168.1.101] (c-71-231-138-78.hsd1.or.comcast.net [71.231.138.78]) (authenticated bits=0) by webaccess-cl.virtdom.com (8.13.6/8.13.6) with ESMTP id l6IKWQ2B054732 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Wed, 18 Jul 2007 16:32:27 -0400 (EDT) (envelope-from jroberson@chesapeake.net) Date: Wed, 18 Jul 2007 13:35:41 -0700 (PDT) From: Jeff Roberson X-X-Sender: jroberson@10.0.0.1 To: Max Laier In-Reply-To: <200707182156.03769.max@love2party.net> Message-ID: <20070718133508.Q561@10.0.0.1> References: <20070717182819.L92541@10.0.0.1> <200707182156.03769.max@love2party.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: cvs commit: src/sys/kern sched_ule.c (fwd) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Jul 2007 20:32:29 -0000 On Wed, 18 Jul 2007, Max Laier wrote: > On Wednesday 18 July 2007, Jeff Roberson wrote: >> Thanks everyone for your help. In summary it sounds like there are two >> issues. >> >> 1) kqemu explicitly uses sched_lock. I'll see if I can contact the >> author about fixing this. >> >> 2) As much as a 6-7% slowdown on buildworld on dual core machines as >> compared to 4BSD. I'm not sure if I'm going to do anything about this. >> Once you get to 4 or 8 cores and -j8 or more they even out with ULE >> having significantly less system time. I don't know if I want to >> compromise that for slightly better dual core compile times. > > 3) nice(1) trouble? > > I wrote a quick script to fork off a couple of "yes > /dev/null" to stress > test and it works really really fine. However, if I nice down the script > it panics with > > | spin lock 0xffffffff806e5380 (sched lock 2) held by 0xffffff0001227000 > | (tid 100000) too long > | panic: spin lock held too long > > This is almost 100% repeatable after 30-60 seconds, even with only 4 yes > instances (where 4 is the # of CPUs). Hey Max, Thanks for the bug report. I'm not able to reproduce this myself. Can you enable some debugging and get me a stack trace? Thanks, Jeff > >> This is in the tree for 7.0 now though. I'm very excited to see this >> happen. >> >> Thanks again, >> Jeff >> >> ---------- Forwarded message ---------- >> Date: Tue, 17 Jul 2007 22:53:24 +0000 (UTC) >> From: Jeff Roberson >> To: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, >> cvs-all@FreeBSD.org Subject: cvs commit: src/sys/kern sched_ule.c >> >> jeff 2007-07-17 22:53:24 UTC >> >> FreeBSD src repository >> >> Modified files: >> sys/kern sched_ule.c >> Log: >> ULE 3.0: Fine grain scheduler locking and affinity improvements. >> This has been in development for over 6 months as SCHED_SMP. >> - Implement one spin lock per thread-queue. Threads assigned to a >> run-queue point to this lock via td_lock. >> - Improve the facility for assigning threads to CPUs now that >> sched_lock contention no longer dominates scheduling decisions on >> larger SMP machines. >> - Re-write idle time stealing in an attempt to make it less >> damaging to general performance. This is still disabled by default. >> See kern.sched.steal_idle. >> - Call the long-term load balancer from a callout rather than >> sched_clock() so there are no locks held. This is disabled by default. >> See kern.sched.balance. >> - Parameterize many scheduling decisions via sysctls. Try to >> document these via sysctl descriptions. >> - General structural and naming cleanups. >> - Document each function with comments. >> >> Tested by: current@ amd64, x86, UP, SMP. >> Approved by: re >> >> Revision Changes Path >> 1.200 +917 -549 src/sys/kern/sched_ule.c >> _______________________________________________ >> 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" > > > > -- > /"\ Best regards, | mlaier@freebsd.org > \ / Max Laier | ICQ #67774661 > X http://pf4freebsd.love2party.net/ | mlaier@EFnet > / \ ASCII Ribbon Campaign | Against HTML Mail and News > From owner-freebsd-current@FreeBSD.ORG Wed Jul 18 19:06:43 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EAAAC16A405; Wed, 18 Jul 2007 19:06:43 +0000 (UTC) (envelope-from bennett@cs.niu.edu) Received: from mp.cs.niu.edu (mp.cs.niu.edu [131.156.68.41]) by mx1.freebsd.org (Postfix) with ESMTP id B78B113C4C3; Wed, 18 Jul 2007 19:06:43 +0000 (UTC) (envelope-from bennett@cs.niu.edu) Received: from mp.cs.niu.edu (bennett@localhost [127.0.0.1]) by mp.cs.niu.edu (8.14.1/8.14.1) with ESMTP id l6II7tu7010845; Wed, 18 Jul 2007 13:07:55 -0500 (CDT) Date: Wed, 18 Jul 2007 13:07:55 -0500 (CDT) From: Scott Bennett Message-Id: <200707181807.l6II7twY010844@mp.cs.niu.edu> To: freebsd-net@freebsd.org, Max Laier X-Mailman-Approved-At: Wed, 18 Jul 2007 20:49:45 +0000 Cc: freebsd-current@freebsd.org, Robert Watson Subject: Re: Reminder: NET_NEEDS_GIANT, debug.mpsafenet going away in X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Jul 2007 19:06:44 -0000 [Cc: list trimmed a bit more --SB] On Tue, 17 Jul 2007 23:42:14 +0200 Max Laier >[ Excess CC-list ... testers needed!!! ] > >On Tuesday 17 July 2007, Robert Watson wrote: I missed Robert Watson's start of thread, so I'm jumping in here with a question. >> Dear all: >> >> This is a reminder e-mail that, in the very near future, Giant >> compatibility shims for network protocols will be removed. > How, if at all, will this affect qemu users? qemu exits unless AIO is present in the kernel (or aio.ko has been kldload-ed). In FreeBSD 6.2, AIO results in a warning message at boot time that says AIO is not MPSAFE and that therefore the networking stack will take a deep performance hit. Scott Bennett, Comm. ASMELG, CFIAG ********************************************************************** * Internet: bennett at cs.niu.edu * *--------------------------------------------------------------------* * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * * -- Gov. John Hancock, New York Journal, 28 January 1790 * ********************************************************************** From owner-freebsd-current@FreeBSD.ORG Wed Jul 18 19:54:48 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DD6CC16A414; Wed, 18 Jul 2007 19:54:48 +0000 (UTC) (envelope-from bennett@cs.niu.edu) Received: from mp.cs.niu.edu (mp.cs.niu.edu [131.156.145.41]) by mx1.freebsd.org (Postfix) with ESMTP id 6A93813C494; Wed, 18 Jul 2007 19:54:41 +0000 (UTC) (envelope-from bennett@cs.niu.edu) Received: from mp.cs.niu.edu (bennett@localhost [127.0.0.1]) by mp.cs.niu.edu (8.14.1/8.14.1) with ESMTP id l6IJsAAY013573; Wed, 18 Jul 2007 14:54:10 -0500 (CDT) Date: Wed, 18 Jul 2007 14:54:10 -0500 (CDT) From: Scott Bennett Message-Id: <200707181954.l6IJsAvN013572@mp.cs.niu.edu> To: rwatson@FreeBSD.org X-Mailman-Approved-At: Wed, 18 Jul 2007 20:49:45 +0000 Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org, max@love2party.net Subject: Re: Reminder: NET_NEEDS_GIANT, debug.mpsafenet going away in X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Jul 2007 19:54:49 -0000 On Wed, 18 Jul 2007 20:48:21 +0100 (BST) Robert Watson wrote: >On Wed, 18 Jul 2007, Scott Bennett wrote: > >> [Cc: list trimmed a bit more --SB] >> On Tue, 17 Jul 2007 23:42:14 +0200 Max Laier >> >>> [ Excess CC-list ... testers needed!!! ] >>> >>> On Tuesday 17 July 2007, Robert Watson wrote: >> >> I missed Robert Watson's start of thread, so I'm jumping in here >> with a question. >> >>>> This is a reminder e-mail that, in the very near future, Giant >>>> compatibility shims for network protocols will be removed. >> >> How, if at all, will this affect qemu users? qemu exits unless AIO is >> present in the kernel (or aio.ko has been kldload-ed). In FreeBSD 6.2, AIO >> results in a warning message at boot time that says AIO is not MPSAFE and >> that therefore the networking stack will take a deep performance hit. > >Per several earlier e-mails in the thread, AIO is MPSAFE in FreeBSD 7.0 and, >as such, unaffected by this change. As a result, I would expect that >applications depending on AIO should now perform significantly better (but >have done no measurement in this area). > Great! Thanks for this news. My apologies for missing the previous messages. Scott Bennett, Comm. ASMELG, CFIAG ********************************************************************** * Internet: bennett at cs.niu.edu * *--------------------------------------------------------------------* * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * * -- Gov. John Hancock, New York Journal, 28 January 1790 * ********************************************************************** From owner-freebsd-current@FreeBSD.ORG Wed Jul 18 21:20:14 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 46C3216A401 for ; Wed, 18 Jul 2007 21:20:14 +0000 (UTC) (envelope-from r.c.ladan@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.172]) by mx1.freebsd.org (Postfix) with ESMTP id 9729613C4A6 for ; Wed, 18 Jul 2007 21:20:13 +0000 (UTC) (envelope-from r.c.ladan@gmail.com) Received: by ug-out-1314.google.com with SMTP id o4so453315uge for ; Wed, 18 Jul 2007 14:20:12 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:x-enigmail-version:content-type; b=YZ6txMK+x2osJX+AV3lD8Olhred8DaiTy7Bq1KGJaF8MuTWpS25fVi2j1SASpWwt0j9pGUdQUhqyovx+zZPnQxBybJAoDAGFMuk7aDDVbu4lyHGoZHyxeNLHezpBOZMRKp0O6C8hRYQVWxW42SQDuu0/ZXXlT7yNqtW5heh9K78= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:x-enigmail-version:content-type; b=GaNmCpw9vxcPlT8QaUwGb/qcOCMgPYM5GbvGM99aPGQYNWN366J4p9Q9KnIV9WAmbThV672Ofq/xyJHEMVX189L8E+ViUI5lcTtyxn4ouGRMYEpMCiDRqZKYvYkXxsz/njPow9Gz+P51oKwDc/Eek0WtMUNEYQYvixo4MPyZvNY= Received: by 10.66.242.19 with SMTP id p19mr613983ugh.1184793612099; Wed, 18 Jul 2007 14:20:12 -0700 (PDT) Received: from 195-241-221-201.dsl.ip.tiscali.nl ( [195.241.221.201]) by mx.google.com with ESMTPS id 31sm6335052nfu.2007.07.18.14.20.09 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 18 Jul 2007 14:20:09 -0700 (PDT) Message-ID: <469E83F8.3090103@gmail.com> Date: Wed, 18 Jul 2007 23:19:52 +0200 From: Rene Ladan User-Agent: Thunderbird 2.0.0.4 (X11/20070616) MIME-Version: 1.0 To: current@freebsd.org References: <20070716233030.D92541@10.0.0.1> In-Reply-To: <20070716233030.D92541@10.0.0.1> X-Enigmail-Version: 0.95.1 Content-Type: multipart/mixed; boundary="------------060106080707080403020903" Cc: Subject: Re: ULE/SCHED_SMP diff for 7.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2007 21:20:14 -0000 This is a multi-part message in MIME format. --------------060106080707080403020903 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Jeff Roberson schreef: > http://people.freebsd.org/~jeff/ule.diff > > This patch is scheduled for inclusion in 7.0. I would like anyone who > cares to run it to validate that it does not create any stability or > performance regression over the existing ULE. This patch replaces ULE > with SCHED_SMP, which will now no longer exist as a seperate fork of ULE. [..] I cvsupped this evening at 19:34 UTC. The new ULE scheduler works fine in single-user mode (it survives "make kernel"), but when I go to multi-user mode I get a "sched_add: trying to run inhibited thread" panic (2 vmcores lost due to fsck :( ) This is on a SMP dualcore Intel T5600 laptop (dmesg + kernelconfig attached) Could it be caused by some user process (pgsql / boinc) ? Well, at least the 4BSD continues to run... Regards, Rene -- GPG fingerprint = E738 5471 D185 7013 0EE0 4FC8 3C1D 6F83 12E1 84F6 (subkeys.pgp.net) "It won't fit on the line." -- me, 2001 --------------060106080707080403020903 Content-Type: text/plain; name="dmesg.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="dmesg.txt" WARNING: WITNESS option enabled, expect reduced performance. ACPI APIC Table: Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 CPU T5600 @ 1.83GHz (1828.77-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6f6 Stepping = 6 Features=0xbfebfbff Features2=0xe3bd AMD Features=0x20100000 AMD Features2=0x1 Cores per package: 2 real memory = 2147287040 (2047 MB) avail memory = 2095534080 (1998 MB) FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: <_ASUS_ Notebook> on motherboard acpi0: [ITHREAD] acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 2000 acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 7ff00000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 acpi_ec0: port 0x62,0x66 on acpi0 cpu0: on acpi0 cpu1: on acpi0 acpi_asus0: Unsupported Asus laptop: A6Je pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 16 at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0xb000-0xb0ff mem 0xc0000000-0xcfffffff,0xfdff0000-0xfdffffff irq 16 at device 0.0 on pci1 acpi_video0: on vgapci0 pcm0: mem 0xfebfc000-0xfebfffff irq 21 at device 27.0 on pci0 pcm0: [ITHREAD] pcib2: irq 20 at device 28.0 on pci0 pci2: on pcib2 re0: port 0xc800-0xc8ff mem 0xfe0ff000-0xfe0fffff irq 16 at device 0.0 on pci2 miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto re0: Ethernet address: 00:18:f3:b7:89:34 re0: [FILTER] pcib3: irq 19 at device 28.3 on pci0 pci3: on pcib3 pci3: at device 0.0 (no driver attached) uhci0: port 0xec00-0xec1f irq 23 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xe880-0xe89f irq 20 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0xe800-0xe81f irq 22 at device 29.2 on pci0 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb2: on uhci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered uhci3: port 0xe480-0xe49f irq 18 at device 29.3 on pci0 uhci3: [GIANT-LOCKED] uhci3: [ITHREAD] usb3: on uhci3 usb3: USB revision 1.0 uhub3: on usb3 uhub3: 2 ports with 2 removable, self powered ehci0: mem 0xfebfbc00-0xfebfbfff irq 23 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb4: EHCI version 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: on ehci0 usb4: USB revision 2.0 uhub4: on usb4 uhub4: 8 ports with 8 removable, self powered ugen0: on uhub4 pcib4: at device 30.0 on pci0 pci4: on pcib4 cbb0: irq 17 at device 1.0 on pci4 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 cbb0: [ITHREAD] fwohci0: mem 0xfeaff800-0xfeafffff irq 18 at device 1.1 on pci4 fwohci0: [FILTER] fwohci0: OHCI version 1.0 (ROM=1) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:e0:18:00:03:76:52:e9 fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 fwohci0: Initiate bus reset fwohci0: BUS reset fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode pci4: at device 1.2 (no driver attached) pci4: at device 1.3 (no driver attached) isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at device 31.2 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] acpi_lid0: on acpi0 acpi_button0: on acpi0 acpi_button1: on acpi0 acpi_tz0: on acpi0 acpi_acad0: on acpi0 battery0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model IntelliMouse, device ID 3 speaker0: port 0x61 on acpi0 acpi_asus0: Unsupported Asus laptop: A6Je pmtimer0 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled 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 ubt0: on uhub2 ubt0: Interface 0 endpoints: interrupt=0x81, bulk-in=0x82, bulk-out=0x2 ubt0: Interface 1 (alt.config 5) endpoints: isoc-in=0x83, isoc-out=0x3; wMaxPacketSize=49; nframes=6, buffer size=294 Timecounters tick every 1.000 msec firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) ad0: 114473MB at ata0-master SATA150 acd0: DVDR at ata1-master UDMA33 pcm0: pcm0: SMP: AP CPU #1 Launched! WARNING: WITNESS option enabled, expect reduced performance. --------------060106080707080403020903 Content-Type: text/plain; name="RENE.current" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="RENE.current" # # GENERIC -- Generic kernel configuration file for FreeBSD/i386 # # For more information on this file, please read the handbook section on # Kernel Configuration Files: # # http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-config.html # # The handbook is also available locally in /usr/share/doc/handbook # if you've installed the doc distribution, otherwise always see the # FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the # latest information. # # An exhaustive list of options and more detailed explanations of the # device lines is also present in the ../../conf/NOTES and NOTES files. # If you are in doubt as to the purpose or necessity of a line, check first # in NOTES. # machine i386 cpu I686_CPU ident RENE # To statically compile in device wiring instead of /boot/device.hints #hints "GENERIC.hints" # Default places to look for devices. makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols # Debugging for use in -current options KDB # Enable kernel debugger support. options DDB # Support DDB. options KDB_TRACE options GDB # Support remote GDB. options INVARIANTS # Enable calls of extra sanity checking options INVARIANT_SUPPORT # Extra sanity checks of internal structures, required by INVARIANTS options WITNESS # Enable checks to detect deadlocks and cycles options WITNESS_SKIPSPIN # Don't run witness on spinlocks for speed #options SCHED_ULE # ULE scheduler only runs BOINC 1/2 time ? --> current! PANICS !! options SCHED_4BSD # works with BOINC as expected, no panic options PREEMPTION # Enable kernel thread preemption options INET # InterNETworking options INET6 # IPv6 communications protocols options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories options MD_ROOT # MD is a potential root device options CD9660 # ISO 9660 Filesystem options COMPAT_43TTY # Compatible with BSD 4.3 [KEEP THIS!] options COMPAT_FREEBSD5 # Compatible with FreeBSD5 options COMPAT_FREEBSD6 # Compatible with FreeBSD6 options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options KBD_INSTALL_CDEV # install a CDEV entry in /dev options AHC_REG_PRETTY_PRINT # Print register bitfields in debug # output. Adds ~128k to driver. options AHD_REG_PRETTY_PRINT # Print register bitfields in debug # output. Adds ~215k to driver. options ADAPTIVE_GIANT # Giant mutex is adaptive. options SMP # Dual core T5600 device apic # I/O APIC options STOP_NMI # stop CPUs with NMI instead of IPI # Bus support. device eisa device pci # ATA and ATAPI devices device ata # as module ? device atadisk # ATA disk drives # as module ? options ATA_STATIC_ID # Static device numbering # SCSI peripherals device scbus # SCSI bus (required for SCSI) device da # Direct Access (disks) device cd # CD device pass # Passthrough device (direct SCSI access) # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc # AT keyboard controller device atkbd # AT keyboard device psm # PS/2 mouse device vga # VGA video card driver device splash # Splash screen and screen saver support # syscons is the default console driver, resembling an SCO console device sc device agp # support several AGP chipsets, required for drm # drm/radeon not supported yet for RV515 (Radeon Mobility X1450) :( device drm device radeondrm # Add suspend/resume support for the i8254. device pmtimer # Pseudo devices. device loop # Network loopback device ether # Ethernet support device pty # Pseudo-ttys (telnet etc) # The `bpf' device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! # Note that 'bpf' is required for DHCP. device bpf # Berkeley packet filter # USB support device uhci # UHCI PCI->USB interface device ohci # OHCI PCI->USB interface device ehci # EHCI PCI->USB interface (USB 2.0) device usb # USB Bus (required) #added options VESA options DEVICE_POLLING device wlan device wlan_wep device wlan_amrr device wlan_scan_sta device wlan_scan_ap --------------060106080707080403020903-- From owner-freebsd-current@FreeBSD.ORG Wed Jul 18 21:24:40 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7102816A400 for ; Wed, 18 Jul 2007 21:24:40 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from webaccess-cl.virtdom.com (webaccess-cl.virtdom.com [216.240.101.25]) by mx1.freebsd.org (Postfix) with ESMTP id 3D72213C4A8 for ; Wed, 18 Jul 2007 21:24:40 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from [192.168.1.101] (c-71-231-138-78.hsd1.or.comcast.net [71.231.138.78]) (authenticated bits=0) by webaccess-cl.virtdom.com (8.13.6/8.13.6) with ESMTP id l6ILOcq2068148 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Wed, 18 Jul 2007 17:24:39 -0400 (EDT) (envelope-from jroberson@chesapeake.net) Date: Wed, 18 Jul 2007 14:27:53 -0700 (PDT) From: Jeff Roberson X-X-Sender: jroberson@10.0.0.1 To: Rene Ladan In-Reply-To: <469E83F8.3090103@gmail.com> Message-ID: <20070718142649.Y561@10.0.0.1> References: <20070716233030.D92541@10.0.0.1> <469E83F8.3090103@gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: current@freebsd.org Subject: Re: ULE/SCHED_SMP diff for 7.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2007 21:24:40 -0000 On Wed, 18 Jul 2007, Rene Ladan wrote: > Jeff Roberson schreef: >> http://people.freebsd.org/~jeff/ule.diff >> >> This patch is scheduled for inclusion in 7.0. I would like anyone who >> cares to run it to validate that it does not create any stability or >> performance regression over the existing ULE. This patch replaces ULE >> with SCHED_SMP, which will now no longer exist as a seperate fork of ULE. > [..] > > I cvsupped this evening at 19:34 UTC. The new ULE scheduler works fine > in single-user mode (it survives "make kernel"), but when I go to > multi-user mode I get a "sched_add: trying to run inhibited thread" > panic (2 vmcores lost due to fsck :( ) Can you get me a backtrace? You can enable KDB and DDB in your kernel along with INVARIANTS. Just type 'tr' and record the function names Thanks, Jeff > > This is on a SMP dualcore Intel T5600 laptop (dmesg + kernelconfig attached) > > Could it be caused by some user process (pgsql / boinc) ? > > Well, at least the 4BSD continues to run... > > Regards, > Rene > -- > GPG fingerprint = E738 5471 D185 7013 0EE0 4FC8 3C1D 6F83 12E1 84F6 > (subkeys.pgp.net) > > "It won't fit on the line." > -- me, 2001 > > From owner-freebsd-current@FreeBSD.ORG Wed Jul 18 21:38:19 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7485716A400 for ; Wed, 18 Jul 2007 21:38:19 +0000 (UTC) (envelope-from nevans@talkpoint.com) Received: from mailbox.talkpoint.com (mailbox.talkpoint.com [204.141.15.162]) by mx1.freebsd.org (Postfix) with ESMTP id 4789813C441 for ; Wed, 18 Jul 2007 21:38:19 +0000 (UTC) (envelope-from nevans@talkpoint.com) Received: from localhost (localhost [127.0.0.1]) by mailbox.talkpoint.com (Postfix) with ESMTP id B641C231C494; Wed, 18 Jul 2007 17:09:48 -0400 (EDT) X-Virus-Scanned: amavisd-new at Received: from mailbox.talkpoint.com ([127.0.0.1]) by localhost (mailbox.talkpoint.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f3k8UBN8SG2a; Wed, 18 Jul 2007 17:09:48 -0400 (EDT) Received: from pleiades.nextvenue.com (pleiades.nextvenue.com [204.141.15.194]) by mailbox.talkpoint.com (Postfix) with ESMTP id 9BDAF231C48A; Wed, 18 Jul 2007 17:09:48 -0400 (EDT) Date: Wed, 18 Jul 2007 17:09:29 -0400 From: Nick Evans To: Jeff Roberson Message-ID: <20070718170929.12305d71@pleiades.nextvenue.com> In-Reply-To: <20070716233030.D92541@10.0.0.1> References: <20070716233030.D92541@10.0.0.1> X-Mailer: Claws Mail 2.8.0 (GTK+ 2.10.9; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: ULE/SCHED_SMP diff for 7.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2007 21:38:19 -0000 On Mon, 16 Jul 2007 23:35:38 -0700 (PDT) Jeff Roberson wrote: > http://people.freebsd.org/~jeff/ule.diff > > This patch is scheduled for inclusion in 7.0. I would like anyone who > cares to run it to validate that it does not create any stability or > performance regression over the existing ULE. This patch replaces ULE > with SCHED_SMP, which will now no longer exist as a seperate fork of ULE. > > Briefly, this is still a very suitable scheduler for uniprocessor machines > while providing stronger affinity and other performance improvements for > multiprocessor machines. > > Even "works for me!" type responses are welcome so I know roughly how many > people have tested before I commit this close to release. > > Thanks! > Jeff > _______________________________________________ > 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" Works here on a quad-core E5310 on i386, except that when I run distributed.net I still sometimes see one full processor completely idle with 4 cruncher processes. This used to happen on on older quad processor Pentium 3 Xeon system when I was testing months ago. Changing kern.sched.steal_idle or kern.sched.balance makes no difference. Nick From owner-freebsd-current@FreeBSD.ORG Wed Jul 18 21:41:53 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2D65016A402 for ; Wed, 18 Jul 2007 21:41:53 +0000 (UTC) (envelope-from pj@smo.de) Received: from ilk.de (mx-out13.ilk.de [194.121.104.13]) by mx1.freebsd.org (Postfix) with ESMTP id 9455513C48D for ; Wed, 18 Jul 2007 21:41:52 +0000 (UTC) (envelope-from pj@smo.de) Received: from bologna.intern.smo.de (pool17.ka.ilk.net [212.86.194.17]) by ilk.de (8.13.4/8.13.4/ilk-relay) with ESMTP id l6IIQlPg012194; Wed, 18 Jul 2007 20:26:49 +0200 Received: from [192.168.153.208] (herdubreid.intern.smo.de [192.168.153.208]) by bologna.intern.smo.de (8.13.4+Sun/8.13.4) with ESMTP id l6IINo6J021999; Wed, 18 Jul 2007 20:23:50 +0200 (CEST) Message-ID: <469E5BEE.1090206@smo.de> Date: Wed, 18 Jul 2007 20:29:02 +0200 From: Philipp Ost User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.13) Gecko/20070525 X-Accept-Language: de, en-us, en MIME-Version: 1.0 To: Jeff Roberson References: <20070716233030.D92541@10.0.0.1> In-Reply-To: <20070716233030.D92541@10.0.0.1> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: ULE/SCHED_SMP diff for 7.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2007 21:41:53 -0000 Jeff Roberson wrote: > Even "works for me!" type responses are welcome so I know roughly how > many people have tested before I commit this close to release. OK, I'm a little late, but nevertheless: It works for me. I'm running -CURRENT on a UP machine: CPU: Pentium II/Pentium II Xeon/Celeron (502.42-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x665 Stepping = 5 Features=0x183f9ff So far I havn't done any "stress testing", but if I encounter any problems I will report them ;-) Thanks for your work! Philipp -- www.familie-ost.info/~pj From owner-freebsd-current@FreeBSD.ORG Wed Jul 18 21:43:42 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CB5BE16A402 for ; Wed, 18 Jul 2007 21:43:42 +0000 (UTC) (envelope-from r.c.ladan@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.171]) by mx1.freebsd.org (Postfix) with ESMTP id 515C613C4B5 for ; Wed, 18 Jul 2007 21:43:41 +0000 (UTC) (envelope-from r.c.ladan@gmail.com) Received: by ug-out-1314.google.com with SMTP id o4so458727uge for ; Wed, 18 Jul 2007 14:43:41 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:x-enigmail-version:content-type; b=ekC8zgI1sS9xNK9AYht9Q9M4XjWSfMzuhFF5aAy94h3Iov/bJzr8XK9ia2WzJPl7AQNHovi1ytb84w+IMYRhJynAz/BJjivUhE22JgN6QiHKXgrxq0pMY68EHB0xlke89A/gJtZPXh2wg71v6c1XVKkGbKhT2sm5nQrQrAxavvs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:x-enigmail-version:content-type; b=UCPDwe6/ldRJmWO0DWuQZK+B8BpiDgIkAtPNtcpuT06SFP5tGo0aBL6cGSsb54yS/N/kGQIcOCW8YwBYulYBRfgnf3MZnd9wzFAyNIjQg1kbsXCZeFSwAnXfzAac5RWRDOXXe8IP7PQNSwEAD4RCdrfhZfKoyNJKIe45Fonu2bk= Received: by 10.66.243.4 with SMTP id q4mr635243ugh.1184795021115; Wed, 18 Jul 2007 14:43:41 -0700 (PDT) Received: from 195-241-221-201.dsl.ip.tiscali.nl ( [195.241.221.201]) by mx.google.com with ESMTPS id e23sm6087673ugd.2007.07.18.14.43.40 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 18 Jul 2007 14:43:40 -0700 (PDT) Message-ID: <469E897B.7080100@gmail.com> Date: Wed, 18 Jul 2007 23:43:23 +0200 From: Rene Ladan User-Agent: Thunderbird 2.0.0.4 (X11/20070616) MIME-Version: 1.0 To: Jeff Roberson , current@freebsd.org References: <20070716233030.D92541@10.0.0.1> <469E83F8.3090103@gmail.com> <20070718142649.Y561@10.0.0.1> In-Reply-To: <20070718142649.Y561@10.0.0.1> X-Enigmail-Version: 0.95.1 Content-Type: multipart/mixed; boundary="------------040306070106010202020401" Cc: Subject: Re: ULE/SCHED_SMP diff for 7.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2007 21:43:42 -0000 This is a multi-part message in MIME format. --------------040306070106010202020401 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Jeff Roberson schreef: > > On Wed, 18 Jul 2007, Rene Ladan wrote: > >> Jeff Roberson schreef: >>> http://people.freebsd.org/~jeff/ule.diff >>> >>> This patch is scheduled for inclusion in 7.0. I would like anyone who >>> cares to run it to validate that it does not create any stability or >>> performance regression over the existing ULE. This patch replaces ULE >>> with SCHED_SMP, which will now no longer exist as a seperate fork of >>> ULE. >> [..] >> >> I cvsupped this evening at 19:34 UTC. The new ULE scheduler works fine >> in single-user mode (it survives "make kernel"), but when I go to >> multi-user mode I get a "sched_add: trying to run inhibited thread" >> panic (2 vmcores lost due to fsck :( ) > > Can you get me a backtrace? You can enable KDB and DDB in your kernel > along with INVARIANTS. Just type 'tr' and record the function names > I found a file #165060 in /var/lost+found . kgdb didn't eat it, but strings could still extract the attached backtrace. In case you want to recompile the kernel, it is compiled with -O1 -pipe -march=prescott -fno-strict-aliasing Regards, Rene -- GPG fingerprint = E738 5471 D185 7013 0EE0 4FC8 3C1D 6F83 12E1 84F6 (subkeys.pgp.net) "It won't fit on the line." -- me, 2001 --------------040306070106010202020401 Content-Type: text/plain; name="vmcore32.strings" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="vmcore32.strings" panic: sched_add: trying to run inhibited thread cpuid = 1 KDB: stack backtrace: db_trace_self_wrapper(c06bc9e9,e799eae0,c0500eb9,c06dbce9,1,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c06dbce9,1,c06bb89d,e799eaec,1,...) at kdb_backtrace+0x29 panic(c06bb89d,1,c06bb74a,892,1,...) at panic+0x10f tdq_add(c0730d40,9,c06bb74a,6d7,c5d94ea4,...) at tdq_add+0x45 sched_switch(c5d94cc0,c5d94000,1,180,17eab51a,...) at sched_switch+0x26e mi_switch(1,0,c06bd5e6,1bd,c5d94cc0,...) at mi_switch+0x209 sleepq_switch(c5d94cc0,0,c06bd5e6,21b,c4d1da3c,...) at sleepq_switch+0xf8 sleepq_wait(c4d1da3c,0,c06d4a5b,3,0,...) at sleepq_wait+0x60 _sx_xlock_hard(c4d1da3c,c5d94cc0,0,c06d66d2,58,...) at _sx_xlock_hard+0x26d _sx_xlock(c4d1da3c,0,c06d66d2,58,81eb000,...) at _sx_xlock+0xb4 _vm_map_lock(c4d1d9f8,c06d66d2,58,54,0,...) at _vm_map_lock+0x51 obreak(c5d94cc0,e799ecfc,4,c06c019f,e799ed38,...) at obreak+0xc5 syscall(e799ed38) at syscall+0x28d Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (17, FreeBSD ELF32, obreak), eip = 0x283235eb, esp = 0xbfbfe50c, ebp = 0xbfbfe538 --- --------------040306070106010202020401-- From owner-freebsd-current@FreeBSD.ORG Wed Jul 18 22:03:37 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EC84716A401 for ; Wed, 18 Jul 2007 22:03:37 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from webaccess-cl.virtdom.com (webaccess-cl.virtdom.com [216.240.101.25]) by mx1.freebsd.org (Postfix) with ESMTP id B872613C4B7 for ; Wed, 18 Jul 2007 22:03:37 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from [192.168.1.101] (c-71-231-138-78.hsd1.or.comcast.net [71.231.138.78]) (authenticated bits=0) by webaccess-cl.virtdom.com (8.13.6/8.13.6) with ESMTP id l6IM3Vwk077449 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Wed, 18 Jul 2007 18:03:32 -0400 (EDT) (envelope-from jroberson@chesapeake.net) Date: Wed, 18 Jul 2007 15:06:46 -0700 (PDT) From: Jeff Roberson X-X-Sender: jroberson@10.0.0.1 To: Rene Ladan In-Reply-To: <469E897B.7080100@gmail.com> Message-ID: <20070718150613.W561@10.0.0.1> References: <20070716233030.D92541@10.0.0.1> <469E83F8.3090103@gmail.com> <20070718142649.Y561@10.0.0.1> <469E897B.7080100@gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: current@freebsd.org Subject: Re: ULE/SCHED_SMP diff for 7.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2007 22:03:38 -0000 On Wed, 18 Jul 2007, Rene Ladan wrote: > Jeff Roberson schreef: >> >> On Wed, 18 Jul 2007, Rene Ladan wrote: >> >>> Jeff Roberson schreef: >>>> http://people.freebsd.org/~jeff/ule.diff >>>> >>>> This patch is scheduled for inclusion in 7.0. I would like anyone who >>>> cares to run it to validate that it does not create any stability or >>>> performance regression over the existing ULE. This patch replaces ULE >>>> with SCHED_SMP, which will now no longer exist as a seperate fork of >>>> ULE. >>> [..] >>> >>> I cvsupped this evening at 19:34 UTC. The new ULE scheduler works fine >>> in single-user mode (it survives "make kernel"), but when I go to >>> multi-user mode I get a "sched_add: trying to run inhibited thread" >>> panic (2 vmcores lost due to fsck :( ) >> >> Can you get me a backtrace? You can enable KDB and DDB in your kernel >> along with INVARIANTS. Just type 'tr' and record the function names >> > > I found a file #165060 in /var/lost+found . kgdb didn't eat it, but strings > could still extract the attached backtrace. In case you want to recompile > the kernel, it is compiled with -O1 -pipe -march=prescott > -fno-strict-aliasing Can you run gdb kernel.debug from your compile directory. Then type: list *(sched_switch+0x26e) I need to know the line number of that call. Thanks, Jeff > > > Regards, > Rene > -- > GPG fingerprint = E738 5471 D185 7013 0EE0 4FC8 3C1D 6F83 12E1 84F6 > (subkeys.pgp.net) > > "It won't fit on the line." > -- me, 2001 > > From owner-freebsd-current@FreeBSD.ORG Wed Jul 18 22:42:27 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E1B6C16A401 for ; Wed, 18 Jul 2007 22:42:27 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.177]) by mx1.freebsd.org (Postfix) with ESMTP id B841E13C4B9 for ; Wed, 18 Jul 2007 22:42:27 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by wa-out-1112.google.com with SMTP id j37so429069waf for ; Wed, 18 Jul 2007 15:42:27 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=fnOEQPee70bvm7bPEf+gcryUnhp3WmsFt6BhpJ8saQHgy4fdVe1Czum0OusOUkEnrtqVZmg34X1a8b1ZQ/5CEqjLipDs6dygTcsdPImGNwtc7g68hpmSiMZl/xKc0xtIxj87jNUQMR2eYePRsXRFQ8jnir7tVfc4VXxxhX3YU3E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=OMM9+yDMcDbJmj/oC+TDc5/YsB56kOgGHGjPw7NaCh7n1j9+9+igtg3BbIhbt45k3fMrrtMAIgVkK9+OK/oH+oZJr5cKKiTjtm+Kr5QODB4FNFDurQvrEEPcDmfGHbUY7MEFmB45XgGGVBQGgN9BatZS3eZQHy6rz1HU4m8ltK8= Received: by 10.115.108.1 with SMTP id k1mr1955280wam.1184798547438; Wed, 18 Jul 2007 15:42:27 -0700 (PDT) Received: by 10.114.103.14 with HTTP; Wed, 18 Jul 2007 15:42:27 -0700 (PDT) Message-ID: <2a41acea0707181542q23d36733o339448ad86f480cb@mail.gmail.com> Date: Wed, 18 Jul 2007 15:42:27 -0700 From: "Jack Vogel" To: freebsd-net , "FreeBSD Current" In-Reply-To: <2a41acea0707181152r4c662b00tf1be7b6b4dce74f1@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <2a41acea0707181152r4c662b00tf1be7b6b4dce74f1@mail.gmail.com> Cc: Subject: 10G and socket alloc failure X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Jul 2007 22:42:28 -0000 While testing out the ixgbe driver we've observed this failure in the stack code, here is the info: The test engineer is using iperf, typically with 16 threads. If the driver is using either legacy or MSI interrupts we will see broken pipes, in dmesg its due to sonewconn() failing in syncache_socket(). Whats interesting is that when I have multiple RX queues configured and using MSI/X this doesnt happen, at least not very often. It does not seem to hurt performance horribly, iperf just spawns another thread, but I was wondering if there is some underlying tuneable I dont know about that would stop this from happening?? And any theory about why it doesnt happen with multiple queues? Jack From owner-freebsd-current@FreeBSD.ORG Wed Jul 18 22:43:42 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A5B9C16A402 for ; Wed, 18 Jul 2007 22:43:42 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from webaccess-cl.virtdom.com (webaccess-cl.virtdom.com [216.240.101.25]) by mx1.freebsd.org (Postfix) with ESMTP id 6481913C4A7 for ; Wed, 18 Jul 2007 22:43:42 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from [192.168.1.101] (c-71-231-138-78.hsd1.or.comcast.net [71.231.138.78]) (authenticated bits=0) by webaccess-cl.virtdom.com (8.13.6/8.13.6) with ESMTP id l6IMhdFM086769 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Wed, 18 Jul 2007 18:43:41 -0400 (EDT) (envelope-from jroberson@chesapeake.net) Date: Wed, 18 Jul 2007 15:46:54 -0700 (PDT) From: Jeff Roberson X-X-Sender: jroberson@10.0.0.1 To: Dmitry Morozovsky In-Reply-To: <20070718011332.A14574@woozle.rinet.ru> Message-ID: <20070718154306.R561@10.0.0.1> References: <20070716233030.D92541@10.0.0.1> <20070718011332.A14574@woozle.rinet.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: current@freebsd.org Subject: Re: ULE/SCHED_SMP diff for 7.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2007 22:43:42 -0000 On Wed, 18 Jul 2007, Dmitry Morozovsky wrote: > On Mon, 16 Jul 2007, Jeff Roberson wrote: > > JR> http://people.freebsd.org/~jeff/ule.diff > JR> > JR> This patch is scheduled for inclusion in 7.0. I would like anyone who cares > JR> to run it to validate that it does not create any stability or performance > JR> regression over the existing ULE. This patch replaces ULE with SCHED_SMP, > JR> which will now no longer exist as a seperate fork of ULE. > JR> > JR> Briefly, this is still a very suitable scheduler for uniprocessor machines > JR> while providing stronger affinity and other performance improvements for > JR> multiprocessor machines. > JR> > JR> Even "works for me!" type responses are welcome so I know roughly how many > JR> people have tested before I commit this close to release. > > Works for me with MSI S420 lapton (core2duo T2400) on fresh -CURRENT/i386 > CPU: Genuine Intel(R) CPU T2400 @ 1.83GHz (1833.41-MHz 686-class CPU) > > However, make -j3 buildworld buildkernel (trimmed GENERIC) time degraded by 7%: > > marck@mck-s420:/var/tmp> ministat before after > x before > + after > +------------------------------------------------------------------------------+ > | x + | > | x + | > |x x x + + +| > ||__MA____| |__A__| | > +------------------------------------------------------------------------------+ > N Min Max Median Avg Stddev > x 5 36.33 36.77 36.45 36.486 0.16637307 > + 5 38.87 39.23 39.03 39.042 0.12774976 > Difference at 95.0% confidence > 2.556 +/- 0.216322 > 7.00543% +/- 0.59289% > (Student's t, pooled s = 0.148324) > > before = kernel with SCHED_4BSD, after = SCHED_ULE with your patchset. Both > are without WITNESS/INVARIANTS. Hi Dmitry, Can you test with http://people.freebsd.org/~jeff/sched_ule.c? I believe this will somewhat improve the situation with buildkernel. I have tested with my own core2duo laptop. The first run after reboot is now about 7% faster than before. Subsequent runs are not improved as much. Only 2-3%. You can also try tuning sysctl kern.sched.steal_thresh down as low as 1 to see how much this may help. Unfortunately lower values tend to really hurt other tests. Thanks, Jeff > > Sincerely, > D.Marck [DM5020, MCK-RIPE, DM3-RIPN] > ------------------------------------------------------------------------ > *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** > ------------------------------------------------------------------------ > _______________________________________________ > 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 Jul 18 22:58:28 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3031516A401 for ; Wed, 18 Jul 2007 22:58:28 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.175]) by mx1.freebsd.org (Postfix) with ESMTP id B679613C4B4 for ; Wed, 18 Jul 2007 22:58:27 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by ug-out-1314.google.com with SMTP id o4so468185uge for ; Wed, 18 Jul 2007 15:58:26 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding:sender; b=F8wQ3G9tIaNmTCJDOfNGJFpf+0kcpZI85IbEO5SN2hgc2aZEWLMe2DkclwQjT20zV9M6AUEFQtApM0xaaoq6PpqC7m2lJcGMxSvYw8twtMn95a8XnDqR5wGKGfkgnKAM6lHrvFE1nRKhdMP9tsmAqsF9sW7UIcjX5pBKyqz033M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding:sender; b=BOT6W1m1sHVXELRKrhzESqDmtIrFUpYA6XZJjXorZ0EXd5viKUsGQD18up41VdQcFQxKtXUAPJNhB8Lx6uMm3v7XIHoCPe8a/H/CwBuzhjwzIA113ujkyxNTwXnT9vKboKdCM94oRU+9RljIEpFeqEc5HUbdL3LHC6yBX4oONys= Received: by 10.66.232.10 with SMTP id e10mr664456ugh.1184799506684; Wed, 18 Jul 2007 15:58:26 -0700 (PDT) Received: from ?151.75.252.155? ( [151.75.252.155]) by mx.google.com with ESMTPS id y7sm6147236ugc.2007.07.18.15.58.25 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 18 Jul 2007 15:58:26 -0700 (PDT) Message-ID: <469E9AE4.6050007@FreeBSD.org> Date: Thu, 19 Jul 2007 00:57:40 +0200 From: Attilio Rao User-Agent: Thunderbird 1.5 (X11/20060526) MIME-Version: 1.0 To: Rene Ladan References: <20070716233030.D92541@10.0.0.1> <469E83F8.3090103@gmail.com> <20070718142649.Y561@10.0.0.1> <469E897B.7080100@gmail.com> In-Reply-To: <469E897B.7080100@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: Attilio Rao Cc: Jeff Roberson , current@freebsd.org Subject: Re: ULE/SCHED_SMP diff for 7.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: attilio@FreeBSD.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2007 22:58:28 -0000 Rene Ladan wrote: > Jeff Roberson schreef: >> On Wed, 18 Jul 2007, Rene Ladan wrote: >> >>> Jeff Roberson schreef: >>>> http://people.freebsd.org/~jeff/ule.diff >>>> >>>> This patch is scheduled for inclusion in 7.0. I would like anyone who >>>> cares to run it to validate that it does not create any stability or >>>> performance regression over the existing ULE. This patch replaces ULE >>>> with SCHED_SMP, which will now no longer exist as a seperate fork of >>>> ULE. >>> [..] >>> >>> I cvsupped this evening at 19:34 UTC. The new ULE scheduler works fine >>> in single-user mode (it survives "make kernel"), but when I go to >>> multi-user mode I get a "sched_add: trying to run inhibited thread" >>> panic (2 vmcores lost due to fsck :( ) >> Can you get me a backtrace? You can enable KDB and DDB in your kernel >> along with INVARIANTS. Just type 'tr' and record the function names >> > > I found a file #165060 in /var/lost+found . kgdb didn't eat it, but strings > could still extract the attached backtrace. In case you want to recompile > the kernel, it is compiled with -O1 -pipe -march=prescott > -fno-strict-aliasing Are you using libkse? I think this problem is linked to other KSE locking issue we are currently experiencing and that I'm trying to fix (a little bit time constrained now). Attilio From owner-freebsd-current@FreeBSD.ORG Wed Jul 18 23:02:06 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8082116A409 for ; Wed, 18 Jul 2007 23:02:06 +0000 (UTC) (envelope-from r.c.ladan@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.174]) by mx1.freebsd.org (Postfix) with ESMTP id 02F9713C48D for ; Wed, 18 Jul 2007 23:02:05 +0000 (UTC) (envelope-from r.c.ladan@gmail.com) Received: by ug-out-1314.google.com with SMTP id o4so468482uge for ; Wed, 18 Jul 2007 16:02:04 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; b=nATfdIJHH59tKJNRa8whVf/E2f03A69UW5/g7xuZpFIhvCD12n2ku9etpQgqpJ0BmwAR3mHNxM/cLsDAY1ipXkbdhoN8bSv0fcBMMUMd1rOKksxO7KVYlf0YPP9vwgU+yME1V6plaCtwV6zWxyECTqzi/DNaC4UF7QiW9KWpQfA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; b=KPNUfdIdb+u465KKF/Pws8txglEOD4By7FxN10ZlewbC5aQAKNf6V6Alj4xafLiSQIIcfUVjt2uqSBRg1c22yZeqyGRVyPRJCy9iFGT51Z2LK919XyDJXZowrnLZ/ahihOdZxEYuA+4tOCpvSdq5Q4jIaxp7nni8Vk7EPQvp4Ns= Received: by 10.67.89.6 with SMTP id r6mr677213ugl.1184799724883; Wed, 18 Jul 2007 16:02:04 -0700 (PDT) Received: from 195-241-221-201.dsl.ip.tiscali.nl ( [195.241.221.201]) by mx.google.com with ESMTPS id s7sm6074153uge.2007.07.18.16.02.04 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 18 Jul 2007 16:02:04 -0700 (PDT) Message-ID: <469E9BDB.7020500@gmail.com> Date: Thu, 19 Jul 2007 01:01:47 +0200 From: Rene Ladan User-Agent: Thunderbird 2.0.0.4 (X11/20070616) MIME-Version: 1.0 To: Jeff Roberson References: <20070716233030.D92541@10.0.0.1> <469E83F8.3090103@gmail.com> <20070718142649.Y561@10.0.0.1> <469E897B.7080100@gmail.com> <20070718150613.W561@10.0.0.1> In-Reply-To: <20070718150613.W561@10.0.0.1> X-Enigmail-Version: 0.95.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: ULE/SCHED_SMP diff for 7.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2007 23:02:06 -0000 Jeff Roberson schreef: > > On Wed, 18 Jul 2007, Rene Ladan wrote: > >> Jeff Roberson schreef: >>> >>> On Wed, 18 Jul 2007, Rene Ladan wrote: >>> >>>> Jeff Roberson schreef: >>>>> http://people.freebsd.org/~jeff/ule.diff >>>>> >>>>> This patch is scheduled for inclusion in 7.0. I would like anyone who >>>>> cares to run it to validate that it does not create any stability or >>>>> performance regression over the existing ULE. This patch replaces ULE >>>>> with SCHED_SMP, which will now no longer exist as a seperate fork of >>>>> ULE. >>>> [..] >>>> >>>> I cvsupped this evening at 19:34 UTC. The new ULE scheduler works fine >>>> in single-user mode (it survives "make kernel"), but when I go to >>>> multi-user mode I get a "sched_add: trying to run inhibited thread" >>>> panic (2 vmcores lost due to fsck :( ) >>> >>> Can you get me a backtrace? You can enable KDB and DDB in your kernel >>> along with INVARIANTS. Just type 'tr' and record the function names >>> >> >> I found a file #165060 in /var/lost+found . kgdb didn't eat it, but >> strings >> could still extract the attached backtrace. In case you want to >> recompile >> the kernel, it is compiled with -O1 -pipe -march=prescott >> -fno-strict-aliasing > > Can you run gdb kernel.debug from your compile directory. Then type: > > list *(sched_switch+0x26e) > > I need to know the line number of that call. Sure: root@195-241-221-201:/usr/obj/usr/src/sys/RENE#gdb kernel.debug (gdb) list *(sched_switch+0x26e) 0xc051c7b0 is in sched_switch (/usr/src/sys/kern/sched_ule.c:1761). 1756 /* XXX This is bogus. What if the thread is locked elsewhere? */ 1757 td->td_lock = TDQ_LOCKPTR(tdq); 1758 td->td_sched->ts_cpu = cpuid; 1759 tdq_add(tdq, td, SRQ_YIELDING); 1760 } 1761 newtd = choosethread(); 1762 /* 1763 * Call the MD code to switch contexts if necessary. 1764 */ 1765 if (td != newtd) { This on an i386. Regards, Rene -- GPG fingerprint = E738 5471 D185 7013 0EE0 4FC8 3C1D 6F83 12E1 84F6 (subkeys.pgp.net) "It won't fit on the line." -- me, 2001 From owner-freebsd-current@FreeBSD.ORG Wed Jul 18 23:07:39 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4EAC216A400 for ; Wed, 18 Jul 2007 23:07:39 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.250]) by mx1.freebsd.org (Postfix) with ESMTP id DF1AF13C48E for ; Wed, 18 Jul 2007 23:07:38 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: by an-out-0708.google.com with SMTP id c14so91048anc for ; Wed, 18 Jul 2007 16:07:38 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=C1ux713dRBSzRHhAKGvqKoGH1hJqfD4k7jTYvHutvaHY5zeUq6ivQVOX0mPZid1hNf+k6Ynuu0zQz2mqhq1oKP2qB+4isfwT2c48z5QJDfrF8fy2OJlXXzrQiQw2+TaBxmwQSWaK0gsKeckcxihMHseWRYXXWSj6Ion6gcaxE34= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=KKqW/GaAN0N9A8iMeGgYLjk/b7XYbB+HWHk4NwhwFM1Zjov95TFHKp/Gx2U/6KqX6dCZnsB0CXCJf7a3ZXQJXrBbquF6eadO8NkTHgH+DpHT9Xr8yUX9byzXeTNonIGxlgE91ntV7+gbRKbaUfP5BnbTDqfYQN1zWo6kWQloK8I= Received: by 10.100.165.9 with SMTP id n9mr1240308ane.1184800057816; Wed, 18 Jul 2007 16:07:37 -0700 (PDT) Received: by 10.100.141.14 with HTTP; Wed, 18 Jul 2007 16:07:37 -0700 (PDT) Message-ID: <790a9fff0707181607n7500b7feo190c58418e047de5@mail.gmail.com> Date: Wed, 18 Jul 2007 18:07:37 -0500 From: "Scot Hetzel" To: "Andrew Thompson" In-Reply-To: <20070715110629.GI95956@heff.fud.org.nz> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_128166_18412533.1184800057710" References: <790a9fff0707150332u2502a491s91f19d4303bf82a6@mail.gmail.com> <20070715110629.GI95956@heff.fud.org.nz> X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: Re: stopping ndis caused fatal trap 12 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Jul 2007 23:07:39 -0000 ------=_Part_128166_18412533.1184800057710 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 7/15/07, Andrew Thompson wrote: > On Sun, Jul 15, 2007 at 05:32:32AM -0500, Scot Hetzel wrote: > > hp010# uname -a > > FreeBSD hp010 7.0-CURRENT FreeBSD 7.0-CURRENT #0: Sat Jul 14 02:20:09 > > CDT 2007 root@hp010:/usr/src/7x/sys-p4/amd64/compile/GENERIC.debug > > amd64 > > > > I was testing wpa_supplicant at work, and couldn't get it to associate > > with the network (open, no encryption), and so I had hardcoded the > > network. When I went home and booted the system, it still had the > > hardcoded wireless network configured. I then did a netif stop ndis0, > > made the change to set ndis to "WPA DHCP", then when I used 'netif > > start ndis0', it didn't obtain an IP. So I performed an 'netif stop > > ndis0' and received the following panic: > > > So back to the ndis association problem. Did the card find the access > point? you can list the scan cache from 'ifconfig ndis0 list scan'. > ifconfig ndis0 scan ; ifconfig ndis0 list scan don't return with any results, but if I run wpa_cli, and do a scan and scan_results it lists the APs. I applied your patch from the previous post and ran the following commands. hp010# sysctl net.wlan.0.debug=0xffffffff net.wlan.0.debug: 0 -> -1 hp010# ifconfig ndis0 scan === see ndis_dmesg2 ==== hp010# ifconfig ndis0 list scan hp010# hp010# uname -a FreeBSD hp010.hetzel.org 7.0-CURRENT FreeBSD 7.0-CURRENT #0: Wed Jul 18 12:25:45 CDT 2007 swhetzel@hp010.hetzel.org:/usr/src/7x/amd64/compile/GENERIC.debug amd64 I was finally able to get connected to both my work and school networks using the following wpa_supplicant.conf file: network={ ssid="Home" scan_ssid=1 key_mgmt=NONE wep_key0=9123456c13800b19d3f8 } network={ ssid="Work" auth_alg=OPEN key_mgmt=NONE } network={ ssid="School" key_mgmt=NONE } #Settings from Windows XP profile for School_WPA #Association -> Network Authentication = WPA #Association -> Data Encryption = TKIP #Authentication -> Enable IEEE 802.1x authentication for this network = checked (grayed out) #Authentication -> EAP type = Protected EAP (PEAP) #Authentication -> Protected EAP Properties -> Validate server certificate = unchecked #Authentication -> Protected EAP Properties -> Authentication Method = Secured password (EAP-MSCHAP v2) #Authentication -> Protected EAP Properties -> Enable Fast Reconnect = checked network={ ssid="School_WPA" proto=WPA key_mgmt=WPA-EAP pairwise=TKIP group=TKIP eap=PEAP identity="me@school" password="password" ca_cert="" # phase1="include_tls_length=1 peapver=1 peaplabel=1" phase2="auth=MSCHAPV2" disabled=1 } But I haven't been able to get it to connect to School_WPA (see ndis_test, ndis_dmesg) when it is enabled. I had searched the net, and found several hints that suggested to try various combinations of peapver=x, peaplabel=y, and include_tls_length=1. But none of them worked. Scot -- DISCLAIMER: No electrons were mamed while sending this message. Only slightly bruised. ------=_Part_128166_18412533.1184800057710 Content-Type: text/x-diff; name=ndis_dmesg2; charset=ANSI_X3.4-1968 Content-Transfer-Encoding: base64 X-Attachment-Id: file2 Content-Disposition: attachment; filename="ndis_dmesg2" bmRpc19uZXdzdGF0ZTogSU5JVCAtPiBJTklUCmZwdWRuYSBpbiBrZXJuZWwgbW9kZSEKZnB1ZG5h IGluIGtlcm5lbCBtb2RlIQpTZXR0aW5nIEJTU0lEIHRvIGZmOmZmOmZmOmZmOmZmOmZmClNldHRp bmcgRVNTSUQgdG8gIiIKbmRpc19uZXdzdGF0ZTogSU5JVCAtPiBTQ0FOCm5kaXNfbmV3c3RhdGU6 IFNDQU4gLT4gSU5JVApmcHVkbmEgaW4ga2VybmVsIG1vZGUhClNldHRpbmcgQlNTSUQgdG8gZmY6 ZmY6ZmY6ZmY6ZmY6ZmYKU2V0dGluZyBFU1NJRCB0byAiIgpuZGlzX25ld3N0YXRlOiBJTklUIC0+ IElOSVQKZnB1ZG5hIGluIGtlcm5lbCBtb2RlIQpTZXR0aW5nIEJTU0lEIHRvIGZmOmZmOmZmOmZm OmZmOmZmClNldHRpbmcgRVNTSUQgdG8gIiIKbmRpczA6IGJzc2lkX2xpc3QgZmFpbGVkCm5kaXNf bmV3c3RhdGU6IElOSVQgLT4gUlVOCm5kaXNfbmV3c3RhdGU6IFJVTiAtPiBJTklUCmZwdWRuYSBp biBrZXJuZWwgbW9kZSEKZnB1ZG5hIGluIGtlcm5lbCBtb2RlIQpTZXR0aW5nIEJTU0lEIHRvIGZm OmZmOmZmOmZmOmZmOmZmClNldHRpbmcgRVNTSUQgdG8gIiIKa3FlbXUgdmVyc2lvbiAweDAwMDEw MzAwCmtxZW11OiBLUUVNVSBpbnN0YWxsZWQsIG1heF9sb2NrZWRfbWVtPTUxNjE1NmtCLgpuZGlz MDogYnNzaWRfbGlzdCBmYWlsZWQKbmRpc19uZXdzdGF0ZTogSU5JVCAtPiBSVU4KbmRpczA6IGxp bmsgc3RhdGUgY2hhbmdlZCB0byBVUApuZGlzMDogaWVlZTgwMjExX3N0YXJ0X3NjYW46IGFjdGl2 ZSBzY2FuLCBkdXJhdGlvbiAyMTQ3NDgzNjQ3LCBkZXNpcmVkIG1vZGUgYXV0bywgYXBwZW5kLCBu b3BpY2ssIG9uY2UKbmRpczA6IHNjYW4gc2V0IDFnLCA2ZywgMTFnLCA3ZywgMTNnLCAyZywgM2cs IDRnLCA1ZywgOGcsIDlnLCAxMGcsIDEyZywgMTRnIGR3ZWxsIG1pbiAyMCBtYXggMjAwCm5kaXMw OiBbMDA6MTQ6YTU6NzI6Njg6NjRdIHN0YSBwb3dlciBzYXZlIG1vZGUgb24KbmRpczA6IFswMDox NDphNTo3Mjo2ODo2NF0gc2VuZCBudWxsIGRhdGEgZnJhbWUgb24gY2hhbm5lbCAxLCBwd3IgbWd0 IGVuYQpsb2NrIG9yZGVyIHJldmVyc2FsOgogMXN0IDB4ZmZmZmZmZmY4MTA0OTAxMCBpZWVlODAy MTFjb20gKDgwMi4xMSBjb20gbG9jaykgQCBuZXQ4MDIxMS9pZWVlODAyMTFfc2Nhbi5jOjM4MQog Mm5kIDB4ZmZmZmZmZmY4MGRlMTNjMCBIQUwgcHJlZW1wdGlvbiBsb2NrIChIQUwgbG9jaykgQCAv dXNyL3NyYy83eC9zeXMtcDQvbW9kdWxlcy9uZGlzLy4uLy4uL2NvbXBhdC9uZGlzL3N1YnJfaGFs LmM6NDIzCktEQjogc3RhY2sgYmFja3RyYWNlOgpkYl90cmFjZV9zZWxmX3dyYXBwZXIoKSBhdCBk Yl90cmFjZV9zZWxmX3dyYXBwZXIrMHgyYQp3aXRuZXNzX2NoZWNrb3JkZXIoKSBhdCB3aXRuZXNz X2NoZWNrb3JkZXIrMHg2NGIKX210eF9sb2NrX2ZsYWdzKCkgYXQgX210eF9sb2NrX2ZsYWdzKzB4 NzUKS2ZSYWlzZUlycWwoKSBhdCBLZlJhaXNlSXJxbCsweDdlCktmQWNxdWlyZVNwaW5Mb2NrKCkg YXQgS2ZBY3F1aXJlU3BpbkxvY2srMHgxZQpuZGlzX3N0YXJ0KCkgYXQgbmRpc19zdGFydCsweDJi CmllZWU4MDIxMV9zZW5kX251bGxkYXRhKCkgYXQgaWVlZTgwMjExX3NlbmRfbnVsbGRhdGErMHgx N2IKc2Nhbl9yZXN0YXJ0KCkgYXQgc2Nhbl9yZXN0YXJ0KzB4YmMKaWVlZTgwMjExX3N0YXJ0X3Nj YW4oKSBhdCBpZWVlODAyMTFfc3RhcnRfc2NhbisweDEwMwppZWVlODAyMTFfaW9jdGwoKSBhdCBp ZWVlODAyMTFfaW9jdGwrMHg3MzgKbmRpc19pb2N0bCgpIGF0IG5kaXNfaW9jdGwrMHgzZjIKaW5f Y29udHJvbCgpIGF0IGluX2NvbnRyb2wrMHg1OTcKaWZpb2N0bCgpIGF0IGlmaW9jdGwrMHhlYQpz b29faW9jdGwoKSBhdCBzb29faW9jdGwrMHgzYWQKa2Vybl9pb2N0bCgpIGF0IGtlcm5faW9jdGwr MHhhMwppb2N0bCgpIGF0IGlvY3RsKzB4ZjEKc3lzY2FsbCgpIGF0IHN5c2NhbGwrMHgxY2EKWGZh c3Rfc3lzY2FsbCgpIGF0IFhmYXN0X3N5c2NhbGwrMHhhYgotLS0gc3lzY2FsbCAoNTQsIEZyZWVC U0QgRUxGNjQsIGlvY3RsKSwgcmlwID0gMHg4MDA4Mjc2ZmMsIHJzcCA9IDB4N2ZmZmZmZmZkN2Y4 LCByYnAgPSAweDQgLS0tCm5kaXMwOiBzY2FuX25leHQ6IGNoYW4gICAxZyAtPiAgIDFnIFthY3Rp dmUsIGR3ZWxsIG1pbiAyMCBtYXggMjAwXQpuZGlzMDogc2Nhbl9uZXh0OiBkb25lLCBbdGlja3Mg NTI2NTE3LCBkd2VsbCBtaW4gMjAgc2NhbmVuZCAyMTQ4MDA4MTY0XQpuZGlzMDogWzAwOjE0OmE1 OjcyOjY4OjY0XSBzdGEgcG93ZXIgc2F2ZSBtb2RlIG9mZgpuZGlzMDogWzAwOjE0OmE1OjcyOjY4 OjY0XSBzZW5kIG51bGwgZGF0YSBmcmFtZSBvbiBjaGFubmVsIDEsIHB3ciBtZ3QgZGlzCm5kaXMw OiBub3RpZnkgc2NhbiBkb25lCg== ------=_Part_128166_18412533.1184800057710 Content-Type: text/plain; name=ndis_test; charset=ANSI_X3.4-1968 Content-Transfer-Encoding: base64 X-Attachment-Id: file3 Content-Disposition: attachment; filename="ndis_test" U2NyaXB0IHN0YXJ0ZWQgb24gV2VkIEp1bCAxOCAxNjo1NTowNiAyMDA3CllvdSBoYXZlIG1haWwu DQpocDAxMCMgaWZjb25maWcgbmRpczANDQpuZGlzMDogZmxhZ3M9ODg0MzxVUCxCUk9BRENBU1Qs UlVOTklORyxTSU1QTEVYLE1VTFRJQ0FTVD4gbWV0cmljIDAgbXR1IDE1MDANCglldGhlciAwMDox NDphNTo3Mjo2ODo2NA0KCWluZXQ2IGZlODA6OjIxNDphNWZmOmZlNzI6Njg2NCVuZGlzMCBwcmVm aXhsZW4gNjQgc2NvcGVpZCAweDEgDQoJbWVkaWE6IElFRUUgODAyLjExIFdpcmVsZXNzIEV0aGVy bmV0IGF1dG9zZWxlY3QNCglzdGF0dXM6IG5vIGNhcnJpZXINCglzc2lkICIiIGNoYW5uZWwgMSAo MjQxMiBNaHogMTFnKQ0KCWF1dGhtb2RlIE9QRU4gcHJpdmFjeSBPRkYgdHhwb3dtYXggMTAwIGJt aXNzIDcgc2NhbnZhbGlkIDYwDQoJcHJvdG1vZGUgQ1RTDQpocDAxMCMgL2V0Yy9yYy5kL25ldGlm IHN0YXJ0IG5kaXMwDQ0KU3RhcnRpbmcgbmRpc19ldmVudHMuDQpTdGFydGluZyB3cGFfc3VwcGxp Y2FudC4NCkluaXRpYWxpemluZyBpbnRlcmZhY2UgJ25kaXMwJyBjb25mICcvZXRjL3dwYV9zdXBw bGljYW50LmNvbmYnIGRyaXZlciAnbmRpcycgY3RybF9pbnRlcmZhY2UgJ04vQScgYnJpZGdlICdO L0EnDQpDb25maWd1cmF0aW9uIGZpbGUgJy9ldGMvd3BhX3N1cHBsaWNhbnQuY29uZicgLT4gJy9l dGMvd3BhX3N1cHBsaWNhbnQuY29uZicNClJlYWRpbmcgY29uZmlndXJhdGlvbiBmaWxlICcvZXRj L3dwYV9zdXBwbGljYW50LmNvbmYnDQpjdHJsX2ludGVyZmFjZT0nL3Zhci9ydW4vd3BhX3N1cHBs aWNhbnQnDQpjdHJsX2ludGVyZmFjZV9ncm91cD0nMCcgKERFUFJFQ0FURUQpDQp1cGRhdGVfY29u ZmlnPTENClByaW9yaXR5IGdyb3VwIDANCiAgIGlkPTAgc3NpZD0nU2Nob29sJw0KICAgaWQ9MSBz c2lkPSdTY2hvb2xfV1BBJw0KSW5pdGlhbGl6aW5nIGludGVyZmFjZSAoMikgJ25kaXMwJw0KRUFQ T0w6IFNVUFBfUEFFIGVudGVyaW5nIHN0YXRlIERJU0NPTk5FQ1RFRA0KRUFQT0w6IEtFWV9SWCBl bnRlcmluZyBzdGF0ZSBOT19LRVlfUkVDRUlWRQ0KRUFQT0w6IFNVUFBfQkUgZW50ZXJpbmcgc3Rh dGUgSU5JVElBTElaRQ0KRUFQOiBFQVAgZW50ZXJpbmcgc3RhdGUgRElTQUJMRUQNCkVBUE9MOiBF eHRlcm5hbCBub3RpZmljYXRpb24gLSBwb3J0RW5hYmxlZD0wDQpFQVBPTDogRXh0ZXJuYWwgbm90 aWZpY2F0aW9uIC0gcG9ydFZhbGlkPTANCk5ESVM6IFBhY2tldC5kbGwgdmVyc2lvbjogRnJlZUJT RCBXaW5QY2FwIGNvbXBhdGliaWxpdHkgc2hpbSB2MS4wDQpORElTOiAxIGFkYXB0ZXIgbmFtZXMg Zm91bmQNCk5ESVM6IDEgYWRhcHRlciBkZXNjcmlwdGlvbnMgZm91bmQNCk5ESVM6IDAgLSBuZGlz MCAtIG5kaXMwDQpORElTOiBBZGFwdGVyIGRlc2NyaXB0aW9uIHByZWZpeCAnbmRpczAnDQpORElT OiBEcml2ZXIgc3VwcG9ydHMgT0lEXzgwMl8xMV9DQVBBQklMSVRZIC0gTm9PZlBNS0lEcyAxNiBO b09mQXV0aEVuY3JQYWlycyAxNA0KTkRJUzogZHJpdmVyIGNhcGFiaWxpdGllczoga2V5X21nbXQg MHgxZiBlbmMgMHhmIGF1dGggMHgzDQpPd24gTUFDIGFkZHJlc3M6IDAwOjE0OmE1OjcyOjY4OjY0 DQp3cGFfZHJpdmVyX25kaXNfc2V0X3dwYTogZW5hYmxlZD0xDQpuZGlzX2dldF9vaWQ6IG9pZD0w eGQwMTAxMDEgbGVuICg2KSBmYWlsZWQNCm5kaXNfZ2V0X29pZDogb2lkPTB4ZDAxMDEwMSBsZW4g KDYpIGZhaWxlZA0KbmRpc19nZXRfb2lkOiBvaWQ9MHhkMDEwMTAxIGxlbiAoNikgZmFpbGVkDQpu ZGlzX2dldF9vaWQ6IG9pZD0weGQwMTAxMDEgbGVuICg2KSBmYWlsZWQNClNldHRpbmcgc2NhbiBy ZXF1ZXN0OiAwIHNlYyAxMDAwMDAgdXNlYw0KVXNpbmcgZXhpc3RpbmcgY29udHJvbCBpbnRlcmZh Y2UgZGlyZWN0b3J5Lg0KY3RybF9pbnRlcmZhY2VfZ3JvdXA9MA0KQWRkZWQgaW50ZXJmYWNlIG5k aXMwDQpEYWVtb25pemUuLg0KREhDUFJFUVVFU1Qgb24gbmRpczAgdG8gMjU1LjI1NS4yNTUuMjU1 IHBvcnQgNjcNCkRIQ1BSRVFVRVNUIG9uIG5kaXMwIHRvIDI1NS4yNTUuMjU1LjI1NSBwb3J0IDY3 DQpESENQRElTQ09WRVIgb24gbmRpczAgdG8gMjU1LjI1NS4yNTUuMjU1IHBvcnQgNjcgaW50ZXJ2 YWwgMw0KREhDUERJU0NPVkVSIG9uIG5kaXMwIHRvIDI1NS4yNTUuMjU1LjI1NSBwb3J0IDY3IGlu dGVydmFsIDYNCkRIQ1BESVNDT1ZFUiBvbiBuZGlzMCB0byAyNTUuMjU1LjI1NS4yNTUgcG9ydCA2 NyBpbnRlcnZhbCAxNA0KREhDUERJU0NPVkVSIG9uIG5kaXMwIHRvIDI1NS4yNTUuMjU1LjI1NSBw b3J0IDY3IGludGVydmFsIDEzDQpESENQRElTQ09WRVIgb24gbmRpczAgdG8gMjU1LjI1NS4yNTUu MjU1IHBvcnQgNjcgaW50ZXJ2YWwgMTINCkRIQ1BESVNDT1ZFUiBvbiBuZGlzMCB0byAyNTUuMjU1 LjI1NS4yNTUgcG9ydCA2NyBpbnRlcnZhbCAxMg0KREhDUERJU0NPVkVSIG9uIG5kaXMwIHRvIDI1 NS4yNTUuMjU1LjI1NSBwb3J0IDY3IGludGVydmFsIDENCk5vIERIQ1BPRkZFUlMgcmVjZWl2ZWQu DQpUcnlpbmcgcmVjb3JkZWQgbGVhc2UgMTAuNjUuMTA4LjgzDQpib3VuZDogcmVuZXdhbCBpbiAz NDM5MTkgc2Vjb25kcy4NCm5kaXMwOiBmbGFncz04ODQzPFVQLEJST0FEQ0FTVCxSVU5OSU5HLFNJ TVBMRVgsTVVMVElDQVNUPiBtZXRyaWMgMCBtdHUgMTUwMA0KCWV0aGVyIDAwOjE0OmE1OjcyOjY4 OjY0DQoJaW5ldDYgZmU4MDo6MjE0OmE1ZmY6ZmU3Mjo2ODY0JW5kaXMwIHByZWZpeGxlbiA2NCBz Y29wZWlkIDB4MSANCgltZWRpYTogSUVFRSA4MDIuMTEgV2lyZWxlc3MgRXRoZXJuZXQgYXV0b3Nl bGVjdA0KCXN0YXR1czogbm8gY2Fycmllcg0KCXNzaWQgIiIgY2hhbm5lbCAxICgyNDEyIE1oeiAx MWcpDQoJYXV0aG1vZGUgT1BFTiBwcml2YWN5IE9GRiB0eHBvd21heCAxMDAgYm1pc3MgNyBzY2Fu dmFsaWQgNjANCglwcm90bW9kZSBDVFMgcm9hbWluZyBNQU5VQUwNCmhwMDEwIyBpZmNvbmZpZyBu ZGlzMCBzY2FuDQ0KaHAwMTAjIGlmY29uZmlnIG5kaXMwIGxpc3Qgc2Nhbg0NCmhwMDEwIyB3cGFf Y2xpDQ0Kd3BhX2NsaSB2MC41LjgNCkNvcHlyaWdodCAoYykgMjAwNC0yMDA3LCBKb3VuaSBNYWxp bmVuIDxqQHcxLmZpPiBhbmQgY29udHJpYnV0b3JzDQoNClRoaXMgcHJvZ3JhbSBpcyBmcmVlIHNv ZnR3YXJlLiBZb3UgY2FuIGRpc3RyaWJ1dGUgaXQgYW5kL29yIG1vZGlmeSBpdA0KdW5kZXIgdGhl IHRlcm1zIG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSB2ZXJzaW9uIDIuDQoNCkFs dGVybmF0aXZlbHksIHRoaXMgc29mdHdhcmUgbWF5IGJlIGRpc3RyaWJ1dGVkIHVuZGVyIHRoZSB0 ZXJtcyBvZiB0aGUNCkJTRCBsaWNlbnNlLiBTZWUgUkVBRE1FIGFuZCBDT1BZSU5HIGZvciBtb3Jl IGRldGFpbHMuDQoNCg0KU2VsZWN0ZWQgaW50ZXJmYWNlICduZGlzMCcNCg0KSW50ZXJhY3RpdmUg bW9kZQ0KDQo+IHN0YXR1cw0KYnNzaWQ9MDA6MGI6MGU6MTk6MzM6NDINCnNzaWQ9U2Nob29sX1dQ QQ0KaWQ9MQ0KcGFpcndpc2VfY2lwaGVyPVRLSVANCmdyb3VwX2NpcGhlcj1US0lQDQprZXlfbWdt dD1XUEEvSUVFRSA4MDIuMVgvRUFQDQp3cGFfc3RhdGU9QVNTT0NJQVRFRA0KU3VwcGxpY2FudCBQ QUUgc3RhdGU9SEVMRA0Kc3VwcFBvcnRTdGF0dXM9VW5hdXRob3JpemVkDQpFQVAgc3RhdGU9RkFJ TFVSRQ0KPiBzY2FuDQpPSw0KPiBzY2FuX3Jlc3VsdHMNCmJzc2lkIC8gZnJlcXVlbmN5IC8gc2ln bmFsIGxldmVsIC8gZmxhZ3MgLyBzc2lkDQowMDowYjowZToxODo0ZTo4MAkyNDM3CS03MAkJU2No b29sDQowMDowYjowZToxODo0ZTo4MgkyNDM3CS03MglbV1BBLUVBUC1US0lQXQlTY2hvb2xfV1BB DQowMDowYjowZToxOTozMzo0MAkyNDM3CS01MwkJU2Nob29sDQowMDowYjowZToxOTozMzo0Mgky NDM3CS01MglbV1BBLUVBUC1US0lQXQlTY2hvb2xfV1BBDQo+IDwyPlRyeWluZyB0byBhc3NvY2lh dGUgd2l0aCAwMDowYjowZToxODo0ZTo4MiAoU1NJRD0nU2Nob29sX1dQQScgZnJlcT0yNDM3IE1I eikNCjwyPkF1dGhlbnRpY2F0aW9uIHdpdGggMDA6MDA6MDA6MDA6MDA6MDAgdGltZWQgb3V0Lg0K PDI+VHJ5aW5nIHRvIGFzc29jaWF0ZSB3aXRoIDAwOjBiOjBlOjE4OjRlOjgyIChTU0lEPSdTY2hv b2xfV1BBJyBmcmVxPTI0MzcgTUh6KQ0KPDI+QXV0aGVudGljYXRpb24gd2l0aCAwMDowMDowMDow MDowMDowMCB0aW1lZCBvdXQuDQo8Mj5UcnlpbmcgdG8gYXNzb2NpYXRlIHdpdGggMDA6MGI6MGU6 MTk6MzM6NDAgKFNTSUQ9J1NjaG9vbCcgZnJlcT0yNDM3IE1IeikNCjwyPkNUUkwtRVZFTlQtRElT Q09OTkVDVEVEIC0gRGlzY29ubmVjdCBldmVudCAtIHJlbW92ZSBrZXlzDQo8Mj5Bc3NvY2lhdGVk IHdpdGggMDA6MGI6MGU6MTk6MzM6NDANCjwyPkNUUkwtRVZFTlQtQ09OTkVDVEVEIC0gQ29ubmVj dGlvbiB0byAwMDowYjowZToxOTozMzo0MCBjb21wbGV0ZWQgKGF1dGgpIFtpZD0wIGlkX3N0cj1d DQo+IGxldmVsIDINCk9LDQo+IHJlYXNzb2NpYXRlDQpPSw0KPiA8Mj5UcnlpbmcgdG8gYXNzb2Np YXRlIHdpdGggMDA6MGI6MGU6MTk6MzM6NDAgKFNTSUQ9J1NjaG9vbCcgZnJlcT0yNDM3IE1IeikN CjwyPkF1dGhlbnRpY2F0aW9uIHdpdGggMDA6MDA6MDA6MDA6MDA6MDAgdGltZWQgb3V0Lg0KPDI+ VHJ5aW5nIHRvIGFzc29jaWF0ZSB3aXRoIDAwOjBiOjBlOjE5OjMzOjQwIChTU0lEPSdTY2hvb2wn IGZyZXE9MjQzNyBNSHopDQo8Mj5BdXRoZW50aWNhdGlvbiB3aXRoIDAwOjAwOjAwOjAwOjAwOjAw IHRpbWVkIG91dC4NCjwyPlRyeWluZyB0byBhc3NvY2lhdGUgd2l0aCAwMDowYjowZToxODo1OTow MiAoU1NJRD0nU2Nob29sX1dQQScgZnJlcT0yNDM3IE1IeikNCjwyPkFzc29jaWF0ZWQgd2l0aCAw MDowYjowZToxOTozMzo0Mg0KPDI+Q1RSTC1FVkVOVC1FQVAtU1RBUlRFRCBFQVAgYXV0aGVudGlj YXRpb24gc3RhcnRlZA0KPDI+RUFQOiBGYWlsZWQgdG8gaW5pdGlhbGl6ZSBFQVAgbWV0aG9kOiB2 ZW5kb3IgMCBtZXRob2QgMjUgKFBFQVApDQo8Mj5DVFJMLUVWRU5ULUVBUC1GQUlMVVJFIEVBUCBh dXRoZW50aWNhdGlvbiBmYWlsZWQNCjwyPkNUUkwtRVZFTlQtRUFQLVNUQVJURUQgRUFQIGF1dGhl bnRpY2F0aW9uIHN0YXJ0ZWQNCjwyPkVBUDogRmFpbGVkIHRvIGluaXRpYWxpemUgRUFQIG1ldGhv ZDogdmVuZG9yIDAgbWV0aG9kIDI1IChQRUFQKQ0KPDI+Q1RSTC1FVkVOVC1FQVAtRkFJTFVSRSBF QVAgYXV0aGVudGljYXRpb24gZmFpbGVkDQo8Mj5BdXRoZW50aWNhdGlvbiB3aXRoIDAwOjBiOjBl OjE5OjMzOjQyIHRpbWVkIG91dC4NCjwyPkNUUkwtRVZFTlQtRElTQ09OTkVDVEVEIC0gRGlzY29u bmVjdCBldmVudCAtIHJlbW92ZSBrZXlzDQo8Mj5UcnlpbmcgdG8gYXNzb2NpYXRlIHdpdGggMDA6 MGI6MGU6MTg6NGU6ODAgKFNTSUQ9J1NjaG9vbCcgZnJlcT0yNDM3IE1IeikNCjwyPkFzc29jaWF0 ZWQgd2l0aCAwMDowYjowZToxOTozMzo0MA0KPDI+Q1RSTC1FVkVOVC1DT05ORUNURUQgLSBDb25u ZWN0aW9uIHRvIDAwOjBiOjBlOjE5OjMzOjQwIGNvbXBsZXRlZCAocmVhdXRoKSBbaWQ9MCBpZF9z dHI9XQ0Kc3RhdHVzDQpic3NpZD0wMDowYjowZToxOTozMzo0MA0Kc3NpZD1TY2hvb2wNCmlkPTAN CnBhaXJ3aXNlX2NpcGhlcj1OT05FDQpncm91cF9jaXBoZXI9Tk9ORQ0Ka2V5X21nbXQ9Tk9ORQ0K d3BhX3N0YXRlPUNPTVBMRVRFRA0KPiBxdWl0DQpocDAxMCMgaWZjb25maWcgbmRpczANDQpuZGlz MDogZmxhZ3M9ODg0MzxVUCxCUk9BRENBU1QsUlVOTklORyxTSU1QTEVYLE1VTFRJQ0FTVD4gbWV0 cmljIDAgbXR1IDE1MDANCglldGhlciAwMDoxNDphNTo3Mjo2ODo2NA0KCWluZXQ2IGZlODA6OjIx NDphNWZmOmZlNzI6Njg2NCVuZGlzMCBwcmVmaXhsZW4gNjQgc2NvcGVpZCAweDEgDQoJbWVkaWE6 IElFRUUgODAyLjExIFdpcmVsZXNzIEV0aGVybmV0IGF1dG9zZWxlY3QNCglzdGF0dXM6IGFzc29j aWF0ZWQNCglzc2lkICIiIGNoYW5uZWwgMSAoMjQxMiBNaHogMTFnKQ0KCWF1dGhtb2RlIE9QRU4g cHJpdmFjeSBPRkYgdHhwb3dtYXggMTAwIGJtaXNzIDcgc2NhbnZhbGlkIDYwDQoJcHJvdG1vZGUg Q1RTIHJvYW1pbmcgTUFOVUFMDQpocDAxMCMgaWZjb25maWcgbmRpczAgaW5ldCAxMC42NS4xMDgu ODMgbmV0bWFzayAweGZmZmZmYzAwDQ0KaHAwMTAjIGlmY29uZmlnIG5kaXMwDQ0KbmRpczA6IGZs YWdzPTg4NDM8VVAsQlJPQURDQVNULFJVTk5JTkcsU0lNUExFWCxNVUxUSUNBU1Q+IG1ldHJpYyAw IG10dSAxNTAwDQoJZXRoZXIgMDA6MTQ6YTU6NzI6Njg6NjQNCglpbmV0NiBmZTgwOjoyMTQ6YTVm ZjpmZTcyOjY4NjQlbmRpczAgcHJlZml4bGVuIDY0IHNjb3BlaWQgMHgxIA0KCWluZXQgMTAuNjUu MTA4LjgzIG5ldG1hc2sgMHhmZmZmZmMwMCBicm9hZGNhc3QgMTAuNjUuMTExLjI1NQ0KCW1lZGlh OiBJRUVFIDgwMi4xMSBXaXJlbGVzcyBFdGhlcm5ldCBhdXRvc2VsZWN0DQoJc3RhdHVzOiBhc3Nv Y2lhdGVkDQoJc3NpZCAiIiBjaGFubmVsIDEgKDI0MTIgTWh6IDExZykNCglhdXRobW9kZSBPUEVO IHByaXZhY3kgT0ZGIHR4cG93bWF4IDEwMCBibWlzcyA3IHNjYW52YWxpZCA2MA0KCXByb3Rtb2Rl IENUUyByb2FtaW5nIE1BTlVBTA0KaHAwMTAjIHBpbmcgMTAuNjUuMTEwLjEKUElORyAxMC42NS4x MTAuMSAoMTAuNjUuMTEwLjEpOiA1NiBkYXRhIGJ5dGVzCjY0IGJ5dGVzIGZyb20gMTAuNjUuMTEw LjE6IGljbXBfc2VxPTAgdHRsPTI1NSB0aW1lPTE2LjI1MCBtcwo2NCBieXRlcyBmcm9tIDEwLjY1 LjExMC4xOiBpY21wX3NlcT0xIHR0bD0yNTUgdGltZT0xMi4wMzggbXMKNjQgYnl0ZXMgZnJvbSAx MC42NS4xMTAuMTogaWNtcF9zZXE9MiB0dGw9MjU1IHRpbWU9Ny42NjMgbXMKCi0tLSAxMC42NS4x MTAuMSBwaW5nIHN0YXRpc3RpY3MgLS0tCjMgcGFja2V0cyB0cmFuc21pdHRlZCwgMyBwYWNrZXRz IHJlY2VpdmVkLCAwLjAlIHBhY2tldCBsb3NzCnJvdW5kLXRyaXAgbWluL2F2Zy9tYXgvc3RkZGV2 ID0gNy42NjMvMTEuOTg0LzE2LjI1MC8zLjUwNiBtcwo= ------=_Part_128166_18412533.1184800057710-- From owner-freebsd-current@FreeBSD.ORG Wed Jul 18 23:14:30 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0C42616A400 for ; Wed, 18 Jul 2007 23:14:30 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from webaccess-cl.virtdom.com (webaccess-cl.virtdom.com [216.240.101.25]) by mx1.freebsd.org (Postfix) with ESMTP id B3BC213C4B9 for ; Wed, 18 Jul 2007 23:14:29 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from [192.168.1.101] (c-71-231-138-78.hsd1.or.comcast.net [71.231.138.78]) (authenticated bits=0) by webaccess-cl.virtdom.com (8.13.6/8.13.6) with ESMTP id l6INERXY093440 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Wed, 18 Jul 2007 19:14:28 -0400 (EDT) (envelope-from jroberson@chesapeake.net) Date: Wed, 18 Jul 2007 16:17:42 -0700 (PDT) From: Jeff Roberson X-X-Sender: jroberson@10.0.0.1 To: Rene Ladan In-Reply-To: <469E9BDB.7020500@gmail.com> Message-ID: <20070718161652.G561@10.0.0.1> References: <20070716233030.D92541@10.0.0.1> <469E83F8.3090103@gmail.com> <20070718142649.Y561@10.0.0.1> <469E897B.7080100@gmail.com> <20070718150613.W561@10.0.0.1> <469E9BDB.7020500@gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: current@freebsd.org Subject: Re: ULE/SCHED_SMP diff for 7.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2007 23:14:30 -0000 On Thu, 19 Jul 2007, Rene Ladan wrote: > Jeff Roberson schreef: >> >> On Wed, 18 Jul 2007, Rene Ladan wrote: >> >>> Jeff Roberson schreef: >>>> >>>> On Wed, 18 Jul 2007, Rene Ladan wrote: >>>> >>>>> Jeff Roberson schreef: >>>>>> http://people.freebsd.org/~jeff/ule.diff >>>>>> >>>>>> This patch is scheduled for inclusion in 7.0. I would like anyone who >>>>>> cares to run it to validate that it does not create any stability or >>>>>> performance regression over the existing ULE. This patch replaces ULE >>>>>> with SCHED_SMP, which will now no longer exist as a seperate fork of >>>>>> ULE. >>>>> [..] >>>>> >>>>> I cvsupped this evening at 19:34 UTC. The new ULE scheduler works fine >>>>> in single-user mode (it survives "make kernel"), but when I go to >>>>> multi-user mode I get a "sched_add: trying to run inhibited thread" >>>>> panic (2 vmcores lost due to fsck :( ) >>>> >>>> Can you get me a backtrace? You can enable KDB and DDB in your kernel >>>> along with INVARIANTS. Just type 'tr' and record the function names >>>> >>> >>> I found a file #165060 in /var/lost+found . kgdb didn't eat it, but >>> strings >>> could still extract the attached backtrace. In case you want to >>> recompile >>> the kernel, it is compiled with -O1 -pipe -march=prescott >>> -fno-strict-aliasing >> >> Can you run gdb kernel.debug from your compile directory. Then type: >> >> list *(sched_switch+0x26e) >> >> I need to know the line number of that call. > Thank you. This is definitely a KSE/ULE problem. Can you try http://people.freebsd.org/~jeff/sched_ule.c? I have made some changes that may fix this. Thanks, Jeff > Sure: > root@195-241-221-201:/usr/obj/usr/src/sys/RENE#gdb kernel.debug > (gdb) list *(sched_switch+0x26e) > 0xc051c7b0 is in sched_switch (/usr/src/sys/kern/sched_ule.c:1761). > 1756 /* XXX This is bogus. What if the thread is locked elsewhere? */ > 1757 td->td_lock = TDQ_LOCKPTR(tdq); > 1758 td->td_sched->ts_cpu = cpuid; > 1759 tdq_add(tdq, td, SRQ_YIELDING); > 1760 } > 1761 newtd = choosethread(); > 1762 /* > 1763 * Call the MD code to switch contexts if necessary. > 1764 */ > 1765 if (td != newtd) { > > This on an i386. > > Regards, > Rene > -- > GPG fingerprint = E738 5471 D185 7013 0EE0 4FC8 3C1D 6F83 12E1 84F6 > (subkeys.pgp.net) > > "It won't fit on the line." > -- me, 2001 > > > _______________________________________________ > 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 Jul 18 23:16:01 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CB68116A403 for ; Wed, 18 Jul 2007 23:16:01 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from heff.fud.org.nz (203-109-251-39.static.bliink.ihug.co.nz [203.109.251.39]) by mx1.freebsd.org (Postfix) with ESMTP id 6438413C47E for ; Wed, 18 Jul 2007 23:16:01 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: by heff.fud.org.nz (Postfix, from userid 1001) id CF3E91CC58; Thu, 19 Jul 2007 11:15:59 +1200 (NZST) Date: Thu, 19 Jul 2007 11:15:59 +1200 From: Andrew Thompson To: Scot Hetzel Message-ID: <20070718231559.GA39517@heff.fud.org.nz> References: <790a9fff0707150332u2502a491s91f19d4303bf82a6@mail.gmail.com> <20070715110629.GI95956@heff.fud.org.nz> <790a9fff0707181607n7500b7feo190c58418e047de5@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <790a9fff0707181607n7500b7feo190c58418e047de5@mail.gmail.com> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: freebsd-current@freebsd.org Subject: Re: stopping ndis caused fatal trap 12 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Jul 2007 23:16:01 -0000 On Wed, Jul 18, 2007 at 06:07:37PM -0500, Scot Hetzel wrote: > On 7/15/07, Andrew Thompson wrote: > >On Sun, Jul 15, 2007 at 05:32:32AM -0500, Scot Hetzel wrote: > >> hp010# uname -a > >> FreeBSD hp010 7.0-CURRENT FreeBSD 7.0-CURRENT #0: Sat Jul 14 02:20:09 > >> CDT 2007 root@hp010:/usr/src/7x/sys-p4/amd64/compile/GENERIC.debug > >> amd64 > >> > >> I was testing wpa_supplicant at work, and couldn't get it to associate > >> with the network (open, no encryption), and so I had hardcoded the > >> network. When I went home and booted the system, it still had the > >> hardcoded wireless network configured. I then did a netif stop ndis0, > >> made the change to set ndis to "WPA DHCP", then when I used 'netif > >> start ndis0', it didn't obtain an IP. So I performed an 'netif stop > >> ndis0' and received the following panic: > >> > >So back to the ndis association problem. Did the card find the access > >point? you can list the scan cache from 'ifconfig ndis0 list scan'. > > > > ifconfig ndis0 scan ; ifconfig ndis0 list scan don't return with any > results, but if I run wpa_cli, and do a scan and scan_results it lists > the APs. > > I applied your patch from the previous post and ran the following commands. > > hp010# sysctl net.wlan.0.debug=0xffffffff > net.wlan.0.debug: 0 -> -1 You must be running amd64 :) Its probably best to install wlandebug from /usr/src/tools and use that. > hp010# ifconfig ndis0 scan > === see ndis_dmesg2 ==== > hp010# ifconfig ndis0 list scan > hp010# I have found various problems that I have started fixing up. wpa_supplicant bypasses most of these which is why its able to run better. I will send you a patch at the end of the week for testing. cheers, Andrew From owner-freebsd-current@FreeBSD.ORG Wed Jul 18 23:22:29 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1D78D16A402 for ; Wed, 18 Jul 2007 23:22:29 +0000 (UTC) (envelope-from r.c.ladan@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.226]) by mx1.freebsd.org (Postfix) with ESMTP id BA27F13C4C6 for ; Wed, 18 Jul 2007 23:22:28 +0000 (UTC) (envelope-from r.c.ladan@gmail.com) Received: by wr-out-0506.google.com with SMTP id i21so349453wra for ; Wed, 18 Jul 2007 16:22:28 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; b=B6ZvhLAUpk3HrDSVBndjUFxX/C/24oJZB85N+B97qA8bo90SywkX2ebtjyeUbG0r4FepmvsBlIP6Vtidl4u8+z3aTtqYNXzbAaj2QX1GNWTcCm4s0C61YJLdfFAU+uQK1iyIdVZCAphOyVtxyl5i850oH175m2lU/pp1uq2dFtA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; b=lSF6uTfqsWDH2yI0/9wuh7HJVZYCBdNUTAoAZtyjnX2CmhrCKwSIN37mo8yZIeXfsfX8ttdrFXO/vOyKJVvMoYbYtWyu4wUhDXeqZwKqwp5OgmT/h6cLRLy4Yo4vB+tAOjfqyW7rV2HTjS3EFvxz1tyzgs6uDMxhFJilyfZFWqE= Received: by 10.67.119.13 with SMTP id w13mr674286ugm.1184800947469; Wed, 18 Jul 2007 16:22:27 -0700 (PDT) Received: from 195-241-221-201.dsl.ip.tiscali.nl ( [195.241.221.201]) by mx.google.com with ESMTPS id f3sm1390366nfh.2007.07.18.16.22.27 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 18 Jul 2007 16:22:27 -0700 (PDT) Message-ID: <469EA0A2.1080901@gmail.com> Date: Thu, 19 Jul 2007 01:22:10 +0200 From: Rene Ladan User-Agent: Thunderbird 2.0.0.4 (X11/20070616) MIME-Version: 1.0 To: attilio@FreeBSD.org References: <20070716233030.D92541@10.0.0.1> <469E83F8.3090103@gmail.com> <20070718142649.Y561@10.0.0.1> <469E897B.7080100@gmail.com> <469E9AE4.6050007@FreeBSD.org> In-Reply-To: <469E9AE4.6050007@FreeBSD.org> X-Enigmail-Version: 0.95.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Jeff Roberson , current@freebsd.org Subject: Re: ULE/SCHED_SMP diff for 7.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2007 23:22:29 -0000 Attilio Rao schreef: > Rene Ladan wrote: >> Jeff Roberson schreef: >>> On Wed, 18 Jul 2007, Rene Ladan wrote: >>> >>>> Jeff Roberson schreef: >>>>> http://people.freebsd.org/~jeff/ule.diff >>>>> >>>>> This patch is scheduled for inclusion in 7.0. I would like anyone who >>>>> cares to run it to validate that it does not create any stability or >>>>> performance regression over the existing ULE. This patch replaces ULE >>>>> with SCHED_SMP, which will now no longer exist as a seperate fork of >>>>> ULE. >>>> [..] >>>> >>>> I cvsupped this evening at 19:34 UTC. The new ULE scheduler works fine >>>> in single-user mode (it survives "make kernel"), but when I go to >>>> multi-user mode I get a "sched_add: trying to run inhibited thread" >>>> panic (2 vmcores lost due to fsck :( ) >>> Can you get me a backtrace? You can enable KDB and DDB in your kernel >>> along with INVARIANTS. Just type 'tr' and record the function names >>> >> >> I found a file #165060 in /var/lost+found . kgdb didn't eat it, but >> strings >> could still extract the attached backtrace. In case you want to >> recompile >> the kernel, it is compiled with -O1 -pipe -march=prescott >> -fno-strict-aliasing > > Are you using libkse? > I think this problem is linked to other KSE locking issue we are > currently experiencing and that I'm trying to fix (a little bit time > constrained now). I guess not since /usr/lib/libpthread.{a|so} -> /usr/lib/libthr.{a|so} libhtr.so.3 actually lives in /lib, libkse.{a|so.3} only lives in /usr/lib grep -ri kse /etc/ didn't find anything suspicious either. Regards, Rene -- GPG fingerprint = E738 5471 D185 7013 0EE0 4FC8 3C1D 6F83 12E1 84F6 (subkeys.pgp.net) "It won't fit on the line." -- me, 2001 From owner-freebsd-current@FreeBSD.ORG Wed Jul 18 23:30:34 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C3F6416A406; Wed, 18 Jul 2007 23:30:34 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from webaccess-cl.virtdom.com (webaccess-cl.virtdom.com [216.240.101.25]) by mx1.freebsd.org (Postfix) with ESMTP id 8D0AA13C4AC; Wed, 18 Jul 2007 23:30:34 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from [192.168.1.101] (c-71-231-138-78.hsd1.or.comcast.net [71.231.138.78]) (authenticated bits=0) by webaccess-cl.virtdom.com (8.13.6/8.13.6) with ESMTP id l6INUWDH097214 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Wed, 18 Jul 2007 19:30:33 -0400 (EDT) (envelope-from jroberson@chesapeake.net) Date: Wed, 18 Jul 2007 16:33:47 -0700 (PDT) From: Jeff Roberson X-X-Sender: jroberson@10.0.0.1 To: Rene Ladan In-Reply-To: <469EA0A2.1080901@gmail.com> Message-ID: <20070718163259.S561@10.0.0.1> References: <20070716233030.D92541@10.0.0.1> <469E83F8.3090103@gmail.com> <20070718142649.Y561@10.0.0.1> <469E897B.7080100@gmail.com> <469E9AE4.6050007@FreeBSD.org> <469EA0A2.1080901@gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: attilio@freebsd.org, current@freebsd.org Subject: Re: ULE/SCHED_SMP diff for 7.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2007 23:30:34 -0000 On Thu, 19 Jul 2007, Rene Ladan wrote: > Attilio Rao schreef: >> Rene Ladan wrote: >>> Jeff Roberson schreef: >>>> On Wed, 18 Jul 2007, Rene Ladan wrote: >>>> >>>>> Jeff Roberson schreef: >>>>>> http://people.freebsd.org/~jeff/ule.diff >>>>>> >>>>>> This patch is scheduled for inclusion in 7.0. I would like anyone who >>>>>> cares to run it to validate that it does not create any stability or >>>>>> performance regression over the existing ULE. This patch replaces ULE >>>>>> with SCHED_SMP, which will now no longer exist as a seperate fork of >>>>>> ULE. >>>>> [..] >>>>> >>>>> I cvsupped this evening at 19:34 UTC. The new ULE scheduler works fine >>>>> in single-user mode (it survives "make kernel"), but when I go to >>>>> multi-user mode I get a "sched_add: trying to run inhibited thread" >>>>> panic (2 vmcores lost due to fsck :( ) >>>> Can you get me a backtrace? You can enable KDB and DDB in your kernel >>>> along with INVARIANTS. Just type 'tr' and record the function names >>>> >>> >>> I found a file #165060 in /var/lost+found . kgdb didn't eat it, but >>> strings >>> could still extract the attached backtrace. In case you want to >>> recompile >>> the kernel, it is compiled with -O1 -pipe -march=prescott >>> -fno-strict-aliasing >> >> Are you using libkse? >> I think this problem is linked to other KSE locking issue we are >> currently experiencing and that I'm trying to fix (a little bit time >> constrained now). > > I guess not since /usr/lib/libpthread.{a|so} -> /usr/lib/libthr.{a|so} > libhtr.so.3 actually lives in /lib, libkse.{a|so.3} only lives in /usr/lib > > grep -ri kse /etc/ didn't find anything suspicious either. Well I'm certain I see the bug now but I believe that path can only be triggered by kse. Perhaps you have some compat based code that is using an old library? Or maybe there is some other place in the kernel that uses this feature. In any event, the scheduler file I posted should fix this. Thanks, Jeff > > Regards, > Rene > -- > GPG fingerprint = E738 5471 D185 7013 0EE0 4FC8 3C1D 6F83 12E1 84F6 (subkeys.pgp.net) > > "It won't fit on the line." > -- me, 2001 > > _______________________________________________ > 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 Jul 19 00:22:26 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7077916A402 for ; Thu, 19 Jul 2007 00:22:26 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.182]) by mx1.freebsd.org (Postfix) with ESMTP id 36D0713C478 for ; Thu, 19 Jul 2007 00:22:26 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by wa-out-1112.google.com with SMTP id j37so455486waf for ; Wed, 18 Jul 2007 17:22:25 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:received:received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=Q9GVhQGEdPH1UUyOeqVpTJCbokpz4Oy2dZvYXViLrZvZa7/Dnf2QzQIbkJdR+lVP/J1jxi1rLEA2EBu6xx9n38W3I//68LMhMVZtOpP25V577HqbOuj5jAx5EVNbY6k4lk9591hWztSNcdp6jJ+go9WQjIXdbOLARRJU6PFHJ9o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=paUhq20ASRqR8U7gzYUJ8iSUthmxf3CN0fTy7HIXriAue5XmUEkcxwO2E5gk0SHFRTJO3zi3zPjsf+pjgxI7MCb2PY2tHvBzfdosSGn+KCPGQh9mjoWLCj+c7tXt6n26bkB3WOEL7FnkaJDaDbM8jb6AvBOvFGNvPZ6D4e4SB+U= Received: by 10.114.177.1 with SMTP id z1mr1122599wae.1184804545872; Wed, 18 Jul 2007 17:22:25 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTPS id l36sm2145765waf.2007.07.18.17.22.23 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 18 Jul 2007 17:22:24 -0700 (PDT) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id l6J0MJWm042601 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Jul 2007 09:22:19 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id l6J0MIr8042600; Thu, 19 Jul 2007 09:22:18 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Thu, 19 Jul 2007 09:22:18 +0900 From: Pyun YongHyeon To: David Christensen Message-ID: <20070719002218.GA42405@cdnetworks.co.kr> References: <09BFF2FA5EAB4A45B6655E151BBDD9030483F161@NT-IRVA-0750.brcm.ad.broadcom.com> <20070718021839.GA37935@cdnetworks.co.kr> <09BFF2FA5EAB4A45B6655E151BBDD9030483F437@NT-IRVA-0750.brcm.ad.broadcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <09BFF2FA5EAB4A45B6655E151BBDD9030483F437@NT-IRVA-0750.brcm.ad.broadcom.com> User-Agent: Mutt/1.4.2.1i Cc: current@freebsd.org Subject: Re: Getting/Forcing Greater than 4KB Buffer Allocations X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2007 00:22:26 -0000 On Wed, Jul 18, 2007 at 11:50:02AM -0700, David Christensen wrote: > > On Tue, Jul 17, 2007 at 04:54:31PM -0700, David Christensen wrote: > > > I'm investigating a problem with my bce driver which > > occurs when I ask > > > for a jumbo > > > mbuf cluster (through m_cljget()). When I map the memory for DMA I > > > normally > > > get 3 memory segments (4KB + 4KB + 1KB) on my system, but > > on another > > > user's > > > system he's seeing 2 memory segments (8KB + 1KB). Is there a > > > configuration > > > option that allows this or some other tuning variable > > involved? The > > > system is a > > > Xeon dual-core processor and has 8GB of RAM, running an > > AMD64 version of > > > the kernel. > > > > > > > I've briefly looked over bus_dma usage on bce(4). It seems that you > > told bus_dma the the dma map could be made up of BCE_MAX_SEGMENTS > > segments, where a dma segment could be MJUM9BYTES bytes. If you want > > just two segments you may have to use 2 instead of BCE_MAX_SEGMENTS. > > If the hardware can support up to BCE_MAX_SEGMENTS dma segments on Rx > > descriptors you should be prepared to handle that number of dma > > segments too(e.g. You don't know how may dma segments would be > > returned by bus_dma, you just know the upper bound as you specified > > in bus_dma_tag_create()). > > If the hardware can handle just up to 4KB for a dma segment you > > should tell bus_dma the restriction of the dma segment. > > If you have to get a single dma segment that covers MJUM9BYTES bytes > > due to the limitation of the hardware you may have to use local > > allocator. > > > > Thanks Pyun but I'm really just looking for a way to test that I can > handle the number of segments I've advertised that I can support. I > believe my code is correct but when all I see are allocations of 3 > segments I just can't prove it. I was hoping that running a utility > such as "stress" would help fragment memory and force more variable > responses but that hasn't happened yet. > It seems you've used the following code to create jumbo dma tag. /* * Create a DMA tag for RX mbufs. */ if (bus_dma_tag_create(sc->parent_tag, 1, BCE_DMA_BOUNDARY, sc->max_bus_addr, BUS_SPACE_MAXADDR, NULL, NULL, MJUM9BYTES, BCE_MAX_SEGMENTS, MJUM9BYTES, ^^^^^^^^^^ 0, NULL, NULL, &sc->rx_mbuf_tag)) { BCE_PRINTF("%s(%d): Could not allocate RX mbuf DMA tag!\n", __FILE__, __LINE__); rc = ENOMEM; goto bce_dma_alloc_exit; } If you want to have > 9 dma segements change maxsegsz(MJUM9BYTES) to 1024. bus_dma honors maxsegsz argument so you wouldn't get a dma segments larger than maxsegsz. With MJUM9BYTES maxsegsz you would get up to 4 dma segments on systems with 4K PAGE_SIZE.(You would have got up to 3 dma segements if you used PAGE_SIZE alignment argument.) > Dave > > -- Regards, Pyun YongHyeon From owner-freebsd-current@FreeBSD.ORG Thu Jul 19 01:59:55 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3DD6716A401 for ; Thu, 19 Jul 2007 01:59:55 +0000 (UTC) (envelope-from leafy7382@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.240]) by mx1.freebsd.org (Postfix) with ESMTP id EDDA613C48D for ; Thu, 19 Jul 2007 01:59:54 +0000 (UTC) (envelope-from leafy7382@gmail.com) Received: by an-out-0708.google.com with SMTP id c14so99616anc for ; Wed, 18 Jul 2007 18:59:54 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=c+k3xHWZA0i5rJRpX1G2fm/da1vb5TjkSyDMvBW6wpBybeFDLdFnQcDyrFlHLEE2Eo8l6ZhYzGSapTYlj1kdJcC15hitmBY8rDGV2wkidnYH5D/fO47Z7UNCGH60ZIkmez+sB+cQnd80Ldar4fdcaK7MFeu8Fgqg4PecEvYIlAQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=m/qVWWQ/mSAl9X96KfC8Xl7fcZLofeeX1/sD37Goa71gHqRvRbyn4NvJRucnZ2C2WKo5TYAtHMvn+9xKVz5LN5HYkT4a1T4Ysx8i4XkTHgqlLFjhzuvCk5qEckcP5z747b3/4z0YpNrh5V+xNfkxN8m1chF2F8PgdPNUeqCKLaM= Received: by 10.100.153.17 with SMTP id a17mr1310966ane.1184810393946; Wed, 18 Jul 2007 18:59:53 -0700 (PDT) Received: by 10.100.137.3 with HTTP; Wed, 18 Jul 2007 18:59:53 -0700 (PDT) Message-ID: Date: Thu, 19 Jul 2007 09:59:53 +0800 From: "Jiawei Ye" To: "Jeff Roberson" In-Reply-To: <20070718163259.S561@10.0.0.1> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070716233030.D92541@10.0.0.1> <469E83F8.3090103@gmail.com> <20070718142649.Y561@10.0.0.1> <469E897B.7080100@gmail.com> <469E9AE4.6050007@FreeBSD.org> <469EA0A2.1080901@gmail.com> <20070718163259.S561@10.0.0.1> Cc: attilio@freebsd.org, current@freebsd.org, Rene Ladan Subject: Re: ULE/SCHED_SMP diff for 7.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2007 01:59:55 -0000 After running the new ULE 3.0 for 2 days, I got this panic when try to install diablo-jdk spin lock 0xc0baa380 (sched lock 1) held by 0xc4b1aaa0 (tid 100189) too long panic: spin lock held too long cpuid = 0 Uptime: 7h52m15s Physical memory: 1003 MB Dumping 213 MB: 198 182 166 150 134 118 102 86 70 54 38 22 6 (kgdb) bt #0 doadump () at pcpu.h:195 #1 0xc074ffe7 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 #2 0xc07502db in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:563 #3 0xc0743c1f in _mtx_lock_spin_failed (m=0x0) at /usr/src/sys/kern/kern_mutex.c:424 #4 0xc0743ca5 in _mtx_lock_spin (m=0xc0baa380, tid=3366110272, opts=0, file=0x0, line=0) at /usr/src/sys/kern/kern_mutex.c:457 #5 0xc076bc84 in sched_add (td=0xc4b1aaa0, flags=0) at /usr/src/sys/kern/sched_ule.c:943 #6 0xc076c046 in sched_wakeup (td=0xc4b1aaa0) at /usr/src/sys/kern/sched_ule.c:1858 #7 0xc0758158 in setrunnable (td=0xc4b1aaa0) at /usr/src/sys/kern/kern_synch.c:505 #8 0xc077f0a9 in sleepq_resume_thread (sq=0xc3ee05e0, td=0xc4b1aaa0, pri=Variable "pri" is not available. ) at /usr/src/sys/kern/subr_sleepqueue.c:658 #9 0xc077fbe3 in sleepq_broadcast (wchan=0xc8b07784, flags=3, pri=-1, queue=0) at /usr/src/sys/kern/subr_sleepqueue.c:753 #10 0xc07576e8 in _sx_xunlock_hard (sx=0xc8b07784, tid=3366110272, file=0x0, line=0) at /usr/src/sys/kern/kern_sx.c:623 #11 0xc0757edf in _sx_xunlock (sx=0xc8b07784, file=0x0, line=0) at sx.h:168 #12 0xc096ec58 in _vm_map_unlock_read (map=0xc8b07740, file=0x0, line=0) at /usr/src/sys/vm/vm_map.c:457 #13 0xc096ec81 in vm_map_lookup_done (map=0xc8b07740, entry=0xc8a20bb0) at /usr/src/sys/vm/vm_map.c:3317 #14 0xc096805a in unlock_and_deallocate (fs=0xe6a97ac4) at /usr/src/sys/vm/vm_fault.c:147 #15 0xc096a234 in vm_fault (map=0xc8b07740, vaddr=135495680, fault_type=2 '\002', fault_flags=8) at /usr/src/sys/vm/vm_fault.c:922 #16 0xc0a1295b in trap_pfault (frame=0xe6a97c24, usermode=0, eva=135499760) at /usr/src/sys/i386/i386/trap.c:761 #17 0xc0a133f9 in trap (frame=0xe6a97c24) at /usr/src/sys/i386/i386/trap.c:462 #18 0xc09f944b in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #19 0xc0a10a51 in suword32 () at /usr/src/sys/i386/i386/support.s:1249 Previous frame inner to this frame (corrupt stack?) Jiawei -- "If it looks like a duck, walks like a duck, and quacks like a duck, then to the end user it's a duck, and end users have made it pretty clear they want a duck; whether the duck drinks hot chocolate or coffee is irrelevant." From owner-freebsd-current@FreeBSD.ORG Thu Jul 19 02:10:37 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5B9F416A400; Thu, 19 Jul 2007 02:10:37 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from webaccess-cl.virtdom.com (webaccess-cl.virtdom.com [216.240.101.25]) by mx1.freebsd.org (Postfix) with ESMTP id DE43713C4A5; Thu, 19 Jul 2007 02:10:36 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from [192.168.1.101] (c-71-231-138-78.hsd1.or.comcast.net [71.231.138.78]) (authenticated bits=0) by webaccess-cl.virtdom.com (8.13.6/8.13.6) with ESMTP id l6J2AYJw029914 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Wed, 18 Jul 2007 22:10:35 -0400 (EDT) (envelope-from jroberson@chesapeake.net) Date: Wed, 18 Jul 2007 19:13:48 -0700 (PDT) From: Jeff Roberson X-X-Sender: jroberson@10.0.0.1 To: Jiawei Ye In-Reply-To: Message-ID: <20070718191306.X561@10.0.0.1> References: <20070716233030.D92541@10.0.0.1> <469E83F8.3090103@gmail.com> <20070718142649.Y561@10.0.0.1> <469E897B.7080100@gmail.com> <469E9AE4.6050007@FreeBSD.org> <469EA0A2.1080901@gmail.com> <20070718163259.S561@10.0.0.1> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: attilio@freebsd.org, current@freebsd.org, Rene Ladan Subject: Re: ULE/SCHED_SMP diff for 7.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2007 02:10:37 -0000 On Thu, 19 Jul 2007, Jiawei Ye wrote: > After running the new ULE 3.0 for 2 days, I got this panic when try to > install diablo-jdk Hi, Can you try the file at http://people.freebsd.org/~jeff/sched_ule.c I fixed a couple of bugs that might impact you. Thanks, Jeff > > spin lock 0xc0baa380 (sched lock 1) held by 0xc4b1aaa0 (tid 100189) too long > panic: spin lock held too long > cpuid = 0 > Uptime: 7h52m15s > Physical memory: 1003 MB > Dumping 213 MB: 198 182 166 150 134 118 102 86 70 54 38 22 6 > > > (kgdb) bt > #0 doadump () at pcpu.h:195 > #1 0xc074ffe7 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 > #2 0xc07502db in panic (fmt=Variable "fmt" is not available. > ) at /usr/src/sys/kern/kern_shutdown.c:563 > #3 0xc0743c1f in _mtx_lock_spin_failed (m=0x0) > at /usr/src/sys/kern/kern_mutex.c:424 > #4 0xc0743ca5 in _mtx_lock_spin (m=0xc0baa380, tid=3366110272, opts=0, > file=0x0, line=0) at /usr/src/sys/kern/kern_mutex.c:457 > #5 0xc076bc84 in sched_add (td=0xc4b1aaa0, flags=0) > at /usr/src/sys/kern/sched_ule.c:943 > #6 0xc076c046 in sched_wakeup (td=0xc4b1aaa0) > at /usr/src/sys/kern/sched_ule.c:1858 > #7 0xc0758158 in setrunnable (td=0xc4b1aaa0) > at /usr/src/sys/kern/kern_synch.c:505 > #8 0xc077f0a9 in sleepq_resume_thread (sq=0xc3ee05e0, td=0xc4b1aaa0, > pri=Variable "pri" is not available. > ) > at /usr/src/sys/kern/subr_sleepqueue.c:658 > #9 0xc077fbe3 in sleepq_broadcast (wchan=0xc8b07784, flags=3, pri=-1, > queue=0) > at /usr/src/sys/kern/subr_sleepqueue.c:753 > #10 0xc07576e8 in _sx_xunlock_hard (sx=0xc8b07784, tid=3366110272, file=0x0, > line=0) at /usr/src/sys/kern/kern_sx.c:623 > #11 0xc0757edf in _sx_xunlock (sx=0xc8b07784, file=0x0, line=0) at sx.h:168 > #12 0xc096ec58 in _vm_map_unlock_read (map=0xc8b07740, file=0x0, line=0) > at /usr/src/sys/vm/vm_map.c:457 > #13 0xc096ec81 in vm_map_lookup_done (map=0xc8b07740, entry=0xc8a20bb0) > at /usr/src/sys/vm/vm_map.c:3317 > #14 0xc096805a in unlock_and_deallocate (fs=0xe6a97ac4) > at /usr/src/sys/vm/vm_fault.c:147 > #15 0xc096a234 in vm_fault (map=0xc8b07740, vaddr=135495680, > fault_type=2 '\002', fault_flags=8) at /usr/src/sys/vm/vm_fault.c:922 > #16 0xc0a1295b in trap_pfault (frame=0xe6a97c24, usermode=0, eva=135499760) > at /usr/src/sys/i386/i386/trap.c:761 > #17 0xc0a133f9 in trap (frame=0xe6a97c24) at > /usr/src/sys/i386/i386/trap.c:462 > #18 0xc09f944b in calltrap () at /usr/src/sys/i386/i386/exception.s:139 > #19 0xc0a10a51 in suword32 () at /usr/src/sys/i386/i386/support.s:1249 > Previous frame inner to this frame (corrupt stack?) > > Jiawei > -- > "If it looks like a duck, walks like a duck, and quacks like a duck, > then to the end user it's a duck, and end users have made it pretty > clear they want a duck; whether the duck drinks hot chocolate or > coffee is irrelevant." > From owner-freebsd-current@FreeBSD.ORG Thu Jul 19 02:32:24 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 244DF16A408 for ; Thu, 19 Jul 2007 02:32:24 +0000 (UTC) (envelope-from tjoerg@yahoo.com) Received: from web63704.mail.re1.yahoo.com (web63704.mail.re1.yahoo.com [69.147.97.89]) by mx1.freebsd.org (Postfix) with SMTP id B7B4C13C4BB for ; Thu, 19 Jul 2007 02:32:23 +0000 (UTC) (envelope-from tjoerg@yahoo.com) Received: (qmail 22682 invoked by uid 60001); 19 Jul 2007 02:05:38 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID; b=I23Tmmae+nMevpr2QDk6JIKhruF3tMjqx6wSE6x6Ght/9ewBA7J+iLfge6ZBq0X9rJEWQLX2kpDAiEMhYaqFwA/IiWgPKFqAFQSdWHNRSq5GEG4hYkoXMeUV5mzEbSZ/UX2VKKFpAwycTMzL+iagX3vI896IwtuNc+dMqbHDplY=; X-YMail-OSG: 1xmo2pwVM1n_.FW1KTnkJyAaBab.sWx36sXaLQHS8hyEeTBMYCKyRT2.2y8N6Iqm0V6h20LppWKz.S8wq7q12UJ.l7suR12NLpdYoUDrj5XOinc6pL2Jn25gB4BMQw-- Received: from [201.78.17.219] by web63704.mail.re1.yahoo.com via HTTP; Wed, 18 Jul 2007 19:05:31 PDT X-Mailer: YahooMailRC/651.41 YahooMailWebService/0.7.41.16 Date: Wed, 18 Jul 2007 19:05:31 -0700 (PDT) From: Joerg t To: freebsd-current MIME-Version: 1.0 Content-Type: text/plain; charset=ascii Message-ID: <561208.21637.qm@web63704.mail.re1.yahoo.com> Subject: Intel PRO/Wireless 4965 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Jul 2007 02:32:24 -0000 there is any ongoing work to add support for the Intel PRO/Wireless 4965 card ? i know, its a controversial subject :) but a need for dumb people like me, who didn't notice that the "thinkpad wifi" was actually an ath card. thanks. ____________________________________________________________________________________ Got a little couch potato? Check out fun summer activities for kids. http://search.yahoo.com/search?fr=oni_on_mail&p=summer+activities+for+kids&cs=bz From owner-freebsd-current@FreeBSD.ORG Thu Jul 19 02:34:33 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 94F6C16A404; Thu, 19 Jul 2007 02:34:33 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 371BC13C491; Thu, 19 Jul 2007 02:34:33 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.13.8/8.13.4) with ESMTP id l6J2Vm51074413; Wed, 18 Jul 2007 20:31:48 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Wed, 18 Jul 2007 20:31:53 -0600 (MDT) Message-Id: <20070718.203153.112852673.imp@bsdimp.com> To: markhobden@gmail.com From: "M. Warner Losh" In-Reply-To: References: X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Wed, 18 Jul 2007 20:31:48 -0600 (MDT) Cc: freebsd-current@freebsd.org, freebsd-usb@freebsd.org Subject: Re: uhidev(4) update - USB HID driver level for devices with multiple report ids X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Jul 2007 02:34:33 -0000 In message: "Mark Hobden" writes: : I have updated the uhidev(4) patch from NetBSD to apply to today's 7-CURRENT. : : http://www.terinea.co.uk/~mark/patches/uhidev-7-current-p2.diff this one seems to be backwards warner From owner-freebsd-current@FreeBSD.ORG Thu Jul 19 03:09:31 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 26BF816A402 for ; Thu, 19 Jul 2007 03:09:31 +0000 (UTC) (envelope-from davidch@broadcom.com) Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by mx1.freebsd.org (Postfix) with ESMTP id 02A2413C478 for ; Thu, 19 Jul 2007 03:09:30 +0000 (UTC) (envelope-from davidch@broadcom.com) Received: from [10.10.64.154] by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.1)); Wed, 18 Jul 2007 20:09:22 -0700 X-Server-Uuid: 20144BB6-FB76-4F11-80B6-E6B2900CA0D7 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id ED9A32AF; Wed, 18 Jul 2007 20:09:21 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id DA06E2AE; Wed, 18 Jul 2007 20:09:21 -0700 (PDT) Received: from mail-irva-12.broadcom.com (mail-irva-12.broadcom.com [10.10.64.146]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id FMF46459; Wed, 18 Jul 2007 20:09:17 -0700 (PDT) Received: from NT-IRVA-0750.brcm.ad.broadcom.com ( nt-irva-0750.brcm.ad.broadcom.com [10.8.194.64]) by mail-irva-12.broadcom.com (Postfix) with ESMTP id 7E14769CA3; Wed, 18 Jul 2007 20:09:17 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 18 Jul 2007 20:09:15 -0700 Message-ID: <09BFF2FA5EAB4A45B6655E151BBDD9030483F5D2@NT-IRVA-0750.brcm.ad.broadcom.com> In-Reply-To: <20070719002218.GA42405@cdnetworks.co.kr> Thread-Topic: Getting/Forcing Greater than 4KB Buffer Allocations Thread-Index: AcfJmulby8HPAC3YS9iSdY35bDx/dQAFmwQQ References: <09BFF2FA5EAB4A45B6655E151BBDD9030483F161@NT-IRVA-0750.brcm.ad.broadcom.com> <20070718021839.GA37935@cdnetworks.co.kr> <09BFF2FA5EAB4A45B6655E151BBDD9030483F437@NT-IRVA-0750.brcm.ad.broadcom.com> <20070719002218.GA42405@cdnetworks.co.kr> From: "David Christensen" To: pyunyh@gmail.com X-WSS-ID: 6A800A683AC26372199-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: current@freebsd.org Subject: RE: Getting/Forcing Greater than 4KB Buffer Allocations X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Jul 2007 03:09:31 -0000 > > Thanks Pyun but I'm really just looking for a way to test=20 > that I can > > handle the number of segments I've advertised that I can=20 > support. I=20 > > believe my code is correct but when all I see are allocations of 3=20 > > segments I just can't prove it. I was hoping that running=20 > a utility > > such as "stress" would help fragment memory and force more variable > > responses but that hasn't happened yet. > >=20 >=20 > It seems you've used the following code to create jumbo dma tag. > /* > * Create a DMA tag for RX mbufs. > */ > if (bus_dma_tag_create(sc->parent_tag, > 1, > BCE_DMA_BOUNDARY, > sc->max_bus_addr, > BUS_SPACE_MAXADDR, > NULL, NULL, > MJUM9BYTES, > BCE_MAX_SEGMENTS, > MJUM9BYTES, > ^^^^^^^^^^ > 0, > NULL, NULL, > &sc->rx_mbuf_tag)) { > BCE_PRINTF("%s(%d): Could not allocate RX=20 > mbuf DMA tag!\n", > __FILE__, __LINE__); > rc =3D ENOMEM; > goto bce_dma_alloc_exit; > } > If you want to have > 9 dma segements change maxsegsz(MJUM9BYTES) to > 1024. bus_dma honors maxsegsz argument so you wouldn't get a dma > segments larger than maxsegsz. With MJUM9BYTES maxsegsz you would get > up to 4 dma segments on systems with 4K PAGE_SIZE.(You would have > got up to 3 dma segements if you used PAGE_SIZE alignment argument.) I don't want more segments, I just want to get a distribution of segments up to the max size I specified. For example, since my BCE_MAX_SEGMENTS=20 size is 8, I want to make sure I get mbufs that are spread over 1, 2, 3, 4, 5, 6, 7, and 8 segments. =20 It turns out if I reduce the amount of memory in the system (from 8GB to 2GB) I will get more mbufs coalesced into 2 segments, rather than the more typical 3 segments, but that's good enough for my testing now. Dave From owner-freebsd-current@FreeBSD.ORG Thu Jul 19 03:22:31 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 36A9B16A403 for ; Thu, 19 Jul 2007 03:22:31 +0000 (UTC) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id 10EFA13C491 for ; Thu, 19 Jul 2007 03:22:30 +0000 (UTC) (envelope-from sam@errno.com) Received: from sam-lefflers-powerbook-g4-15.local ([10.0.0.178]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id l6J3MSa8086342 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Jul 2007 20:22:28 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <469ED8F1.2070409@errno.com> Date: Wed, 18 Jul 2007 20:22:25 -0700 From: Sam Leffler Organization: Errno Consulting User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: Kevin Oberman References: <20070718204740.DA71845045@ptavv.es.net> In-Reply-To: <20070718204740.DA71845045@ptavv.es.net> X-Enigmail-Version: 0.95.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: Problems connecting to public WiFi with latest 80211 code X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Jul 2007 03:22:31 -0000 Kevin Oberman wrote: > I had not seen this problem because I do not use the wpa_supplicant to > connect to open networks when at home, but I am on travel this week and > it has been a real pain. > > System is current as of this afternoon and is running on a ThinkPad T43 > with an Atheros 5212 mini-PCI card. mac+phy revs for card are always important; dmesg|grep ath > > When the system comes up, the wpa_supplicant starts, but the system > never scans except with 'authmode WPA1+WPA2/802.11i privacy ON' and > never tries to associate with an open AP even though I have an entry in > wpa_supplicant.conf for that network. I have to issue a 'ifconfig > wepmode off' to get it to associate. I don't see a log from wpa_supplicant or console debug msgs as obtained with wlandebug. > > Even then, it still won't always associate until I ifconfig the > interface down and up. Once I do this, it seems to associate rather > quickly. > > I suspect that the problem reported on mobile by Matthias Apitz and jhb > may be a part of the problem, but I think the inability to get to > authmode OPEN is different. > > I use the supplicant at home and it works fine, but that is NOT an open > network, so I don't need the interface to run in OPEN mode. > > Any idea what is going on and if it can be fixed or worked around? I can't help w/o the usual info: what os, card info (mac+phy), and how to reproduce (e.g. wpa_supplicant.conf and cmd line). Sam From owner-freebsd-current@FreeBSD.ORG Thu Jul 19 04:20:36 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A15DB16A400 for ; Thu, 19 Jul 2007 04:20:36 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 3F78C13C4B8 for ; Thu, 19 Jul 2007 04:20:36 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from scott-longs-computer.local (c-69-244-251-12.hsd1.fl.comcast.net [69.244.251.12]) (authenticated bits=0) by pooker.samsco.org (8.13.8/8.13.8) with ESMTP id l6J4KLQa058138; Wed, 18 Jul 2007 22:20:26 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <469EE67F.8030504@samsco.org> Date: Thu, 19 Jul 2007 00:20:15 -0400 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.4) Gecko/20070509 SeaMonkey/1.1.2 MIME-Version: 1.0 To: Tony Holmes References: <20070718133345.GA82366@crosswinds.net> In-Reply-To: <20070718133345.GA82366@crosswinds.net> X-Enigmail-Version: 0.95.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (pooker.samsco.org [168.103.85.57]); Wed, 18 Jul 2007 22:20:27 -0600 (MDT) X-Spam-Status: No, score=1.7 required=5.5 tests=RCVD_IN_NJABL_DUL autolearn=no version=3.1.8 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: freebsd-current@freebsd.org Subject: Re: 7.0/6.2, 4GB and AHC X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Jul 2007 04:20:36 -0000 The AHC driver was personally tested with >4GB while it was in active development, but it's certainly possible that bugs have crept in over the years. I'll test it when I get off vacation next week and see what I come up with. Please contact me directly if I forget. Just out of curiosity, try booting with one of your known bad configurations and break into the the loader prompt and do the following: set vm.old_contigmalloc=1 Scott Tony Holmes wrote: > I had a very interesting couple of days trying to figure out why 6.2-STABLE > and 7.0-CURRENT, both amd64, were giving me random hangs, panics etc. > > My system: > > Asus M2NPV-VM > 4GB Ram > 2 x Adaptec 19160 controllers > 14 x 33GB Seagate 10k rpm scsi in a disk shelf (2 channel) > 2 x 80GB Seagate SATA (geom mirror, system disks) > > I had the system installed with 6.2 and upgraded to 7.0- (for the new nfe > driver for the onboard NIC) and added the Adaptecs and disk. I began to play > with geom to set them up as a RAID 10 system for a database. Same configuration > on FreeBSD, solaris and other systems resulted in blazing fast performance. > > Set up the disks, fired up a basic bonnie test and... chug chug and eventual > random panic. Okay, maybe I messed up the geom config since I was tinkering > around. Reboot, wait for sync to finish.... 20 hours later it was done - way > too slow. Checked termination, cables, power, etc. All good. > > Fire up bonnie... first iteration showed approx 8MBps write approx 10MBps read > was horrendous. Decided to attempt a fresh reinstall. > > Load up 6.2R amd64 cd - panic on startup just after SCSI probe delay. Tried > once more and same thing. Okay, try 7.0 amd64. > > Divide by 0 error right after SCSI probe - and that's when the thought struck > me - 4GB ram... > > Pulled out 2GB and viola, 7.0 installed easily. Configured the Raid 10 and got > the nice 275MBps read and 150MBps (ballpark) benchmark numbers I was expecting. > > I know that amd64 supports 4gb+ (I have 2 others with SATA only that are > running flawlessly). > > So I am attempting to determine the cause of the failures. > > The adaptecs are 32bit with older bios (2.57 and 3.10). They are in the 2 > 32bit pci slots of the M2NPV motherboard. > > I would have thought FreeBSD would have knocked a memory hole in the 3.5-4gb > range to accomodate the device mappings. > > Does anyone have any explanations/pointers (I did search and attempt to RTFM > with not much luck) about this? > From owner-freebsd-current@FreeBSD.ORG Thu Jul 19 04:56:52 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0AE8116A402 for ; Thu, 19 Jul 2007 04:56:52 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id A914113C48D for ; Thu, 19 Jul 2007 04:56:51 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from scott-longs-computer.local (c-69-244-251-12.hsd1.fl.comcast.net [69.244.251.12]) (authenticated bits=0) by pooker.samsco.org (8.13.8/8.13.8) with ESMTP id l6J4udrG058383; Wed, 18 Jul 2007 22:56:45 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <469EEF02.7000804@samsco.org> Date: Thu, 19 Jul 2007 00:56:34 -0400 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.4) Gecko/20070509 SeaMonkey/1.1.2 MIME-Version: 1.0 To: David Christensen References: <09BFF2FA5EAB4A45B6655E151BBDD9030483F161@NT-IRVA-0750.brcm.ad.broadcom.com> <20070718021839.GA37935@cdnetworks.co.kr> <09BFF2FA5EAB4A45B6655E151BBDD9030483F437@NT-IRVA-0750.brcm.ad.broadcom.com> <20070719002218.GA42405@cdnetworks.co.kr> <09BFF2FA5EAB4A45B6655E151BBDD9030483F5D2@NT-IRVA-0750.brcm.ad.broadcom.com> In-Reply-To: <09BFF2FA5EAB4A45B6655E151BBDD9030483F5D2@NT-IRVA-0750.brcm.ad.broadcom.com> X-Enigmail-Version: 0.95.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (pooker.samsco.org [168.103.85.57]); Wed, 18 Jul 2007 22:56:46 -0600 (MDT) X-Spam-Status: No, score=1.7 required=5.5 tests=RCVD_IN_NJABL_DUL autolearn=no version=3.1.8 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: pyunyh@gmail.com, current@freebsd.org Subject: Re: Getting/Forcing Greater than 4KB Buffer Allocations X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Jul 2007 04:56:52 -0000 David Christensen wrote: >> > Thanks Pyun but I'm really just looking for a way to test >> that I can >> > handle the number of segments I've advertised that I can >> support. I >> > believe my code is correct but when all I see are allocations of 3 >> > segments I just can't prove it. I was hoping that running >> a utility >> > such as "stress" would help fragment memory and force more variable >> > responses but that hasn't happened yet. >> > >> >> It seems you've used the following code to create jumbo dma tag. >> /* >> * Create a DMA tag for RX mbufs. >> */ >> if (bus_dma_tag_create(sc->parent_tag, >> 1, >> BCE_DMA_BOUNDARY, >> sc->max_bus_addr, >> BUS_SPACE_MAXADDR, >> NULL, NULL, >> MJUM9BYTES, >> BCE_MAX_SEGMENTS, >> MJUM9BYTES, >> ^^^^^^^^^^ >> 0, >> NULL, NULL, >> &sc->rx_mbuf_tag)) { >> BCE_PRINTF("%s(%d): Could not allocate RX >> mbuf DMA tag!\n", >> __FILE__, __LINE__); >> rc = ENOMEM; >> goto bce_dma_alloc_exit; >> } >> If you want to have > 9 dma segements change maxsegsz(MJUM9BYTES) to >> 1024. bus_dma honors maxsegsz argument so you wouldn't get a dma >> segments larger than maxsegsz. With MJUM9BYTES maxsegsz you would get >> up to 4 dma segments on systems with 4K PAGE_SIZE.(You would have >> got up to 3 dma segements if you used PAGE_SIZE alignment argument.) > > I don't want more segments, I just want to get a distribution of > segments > up to the max size I specified. For example, since my BCE_MAX_SEGMENTS > size is 8, I want to make sure I get mbufs that are spread over 1, 2, 3, > 4, 5, 6, 7, and 8 segments. > > It turns out if I reduce the amount of memory in the system (from 8GB to > 2GB) I will get more mbufs coalesced into 2 segments, rather than the > more typical 3 segments, but that's good enough for my testing now. > Dave, I'm trying to catch up on this thread, but I'm utterly confused as to what you're looking for. Let's try talking through a few scenarios here: 1. Your hardware has slots for 3 SG elements, and all three MUST be filled without exception. Therefore, you want segments that are 4k, 4k, and 1k (or some slight variation of that if the buffer is misaligned). To do this, set the maxsegs to 3 and the maxsegsize to 4k. This will ensure that busdma does no coalescing (more on this topic later) and will always give you 3 segments for 9k of contiguous buffers. If the actual buffer winds up being <= 8k, busdma won't guarantee that you'll get 3 segments, and you'll have to fake something up in your driver. If the buffer winds up being an fragmented mbuf chain, it also won't guarantee that you'll get 3 segments either, but that's already handled now via m_defrag(). 2. Your hardware can only handle 4k segments, but is less restrictive on the min/max number of segements. The solution is the same as above. 3. Your hardware has slots for 8 SG elements, and all 8 MUST be filled without exception. There's no easy solution for this, as it's a fairly bizarre situation. I'll only discuss it further if you confirm that it's actually the case here. As for coalescing segments, I'm considering a new busdma back-end that greatly streamlines loads by eliminating cycle-consuming tasks like segment coalescing. The original justification for coalescing was that DMA engines operated faster with fewer segments. That might still be true, but the extra host CPU cycles and cache-line misses probably result in a net loss. I'm also going to axe bounce-buffer support since it bloats the I cache. The target for this new back-end is drivers that support hardware that don't need these services and that are also sensitive to the amount of host CPU cycles being consumed, i.e. modern 1Gb and 10Gb adapters. The question I have is whether this new back-end should be accessible directly through yet another bus_dmamap_load_foo variant that the drivers need to know specifically about, or indirectly and automatically via the existing bus_dmamap_load_foo variants. The tradeoff is further API pollution vs the opportunity for even more efficiency through no indirect function calls and no cache misses from accessing the busdma tag. I don't like API pollution since it makes it harder to maintain code, but the opportunity for the best performance possible is also appealing. Scott From owner-freebsd-current@FreeBSD.ORG Thu Jul 19 07:17:12 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8F03716A401; Thu, 19 Jul 2007 07:17:12 +0000 (UTC) (envelope-from bkoenig@alpha-tierchen.de) Received: from mail.liberty-hosting.de (mail.smartterra.de [195.225.132.203]) by mx1.freebsd.org (Postfix) with ESMTP id 3BA0F13C4AC; Thu, 19 Jul 2007 07:17:12 +0000 (UTC) (envelope-from bkoenig@alpha-tierchen.de) Received: from mail.liberty-hosting.de ([195.225.132.203]) by localhost (liberty-mail [195.225.132.203]) (amavisd-new, port 10024) with ESMTP id 58322-03; Thu, 19 Jul 2007 09:00:50 +0200 (CEST) Received: from home.alpha-tierchen.de (port-212-202-42-202.dynamic.qsc.de [212.202.42.202]) by mail.liberty-hosting.de (Postfix) with ESMTP id F3BC33E9446; Thu, 19 Jul 2007 09:00:49 +0200 (CEST) Received: from webmail.alpha-tierchen.de (localhost [127.0.0.1]) by home.alpha-tierchen.de (Postfix) with ESMTP id 35CC445066; Thu, 19 Jul 2007 08:57:56 +0200 (CEST) Received: from 2001:6f8:101e:0:20e:cff:fe6d:6adb (SquirrelMail authenticated user bkoenig) by webmail.alpha-tierchen.de with HTTP; Thu, 19 Jul 2007 08:57:56 +0200 (CEST) Message-ID: <56567.2001:6f8:101e:0:20e:cff:fe6d:6adb.1184828276.squirrel@webmail.alpha-tierchen.de> In-Reply-To: <20070717131518.G1177@fledge.watson.org> References: <20070717131518.G1177@fledge.watson.org> Date: Thu, 19 Jul 2007 08:57:56 +0200 (CEST) From: =?iso-8859-1?Q?Bj=F6rn_K=F6nig?= To: current@freebsd.org User-Agent: SquirrelMail/1.4.10a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: by amavisd-new at mail.smartterra.de Cc: mlaier@freebsd.org, rwatson@FreeBSD.org Subject: Re: Reminder: NET_NEEDS_GIANT, debug.mpsafenet going away in 7.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2007 07:17:12 -0000 Robert Watson wrote: > > Dear all: > > This is a reminder e-mail that, in the very near future, Giant > compatibility shims for network protocols will be removed. [...] There was an pf-related issue that require to use mpsafenet=0. Is it solved now? >From pf.conf(5): Due to a lock order reversal (LOR) with the socket layer, the use of the group and user filter parameter in conjuction with a Giant-free netstack can result in a deadlock. If you have to use group or user you must set debug.mpsafenet to ``0'' from the loader(8), for the moment. This work- around will still produce the LOR, but Giant will protect from the dead- lock. Unfortunately I have no machine available to test it. Regards Björn From owner-freebsd-current@FreeBSD.ORG Thu Jul 19 07:33:55 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 591EF16A401 for ; Thu, 19 Jul 2007 07:33:55 +0000 (UTC) (envelope-from r.c.ladan@gmail.com) Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.186]) by mx1.freebsd.org (Postfix) with ESMTP id DE35D13C4AC for ; Thu, 19 Jul 2007 07:33:54 +0000 (UTC) (envelope-from r.c.ladan@gmail.com) Received: by mu-out-0910.google.com with SMTP id w9so506465mue for ; Thu, 19 Jul 2007 00:33:53 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=EnT4eq8PKZcpsGfE2odhaHGEpqXr0SFulu0+TxLpJPFwQcNFC5/88OShPSbsWcoqcZ8GYfdNruQksnI28ppHnsmlndLqWh7dGvu+JFtgrb/unDj7iq4pTzERbWN78MeBw9+dyPfZerWLQSqdeOyllYbwuovVSZanhX+3Be/Drow= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=pdB7g9H7vrfMvt75QNBm2tF6iICrYxvBoOH9UgMP/1QmzDzNagA2xkG7A9iC4ze47qEzJS41zR5uJAjcZOLsMaP9ZRFBgNdi8z+gcd1gByUNNS2uWPFZKQW/Tgspz4e03D5DMXQTjJRlpFd29uJ6dJ5OPVmlDGROM7eMreU60/g= Received: by 10.82.152.16 with SMTP id z16mr1664909bud.1184830433695; Thu, 19 Jul 2007 00:33:53 -0700 (PDT) Received: by 10.82.134.8 with HTTP; Thu, 19 Jul 2007 00:33:53 -0700 (PDT) Message-ID: Date: Thu, 19 Jul 2007 09:33:53 +0200 From: "Rene Ladan" To: "Joerg t" In-Reply-To: <561208.21637.qm@web63704.mail.re1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <561208.21637.qm@web63704.mail.re1.yahoo.com> Cc: current@freebsd.org Subject: Re: Intel PRO/Wireless 4965 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Jul 2007 07:33:55 -0000 2007/7/19, Joerg t : > there is any ongoing work to add support > for the Intel PRO/Wireless 4965 card ? > You could try if the Windows driver runs in the NDIS framework, or visit http://intellinuxwireless.org/?p=iwlwifi for a native Linux driver. The Linux driver is in development and would need to be ported to run natively in FreeBSD. Rene -- GPG fingerprint = E738 5471 D185 7013 0EE0 4FC8 3C1D 6F83 12E1 84F6 (subkeys.pgp.net) "It won't fit on the line." -- me, 2001 From owner-freebsd-current@FreeBSD.ORG Thu Jul 19 07:45:22 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2738916A405 for ; Thu, 19 Jul 2007 07:45:22 +0000 (UTC) (envelope-from louisk@cryptomonkeys.com) Received: from abeyance.cryptomonkeys.com (abeyance.cryptomonkeys.com [67.42.3.2]) by mx1.freebsd.org (Postfix) with ESMTP id 9FD0113C46B for ; Thu, 19 Jul 2007 07:45:21 +0000 (UTC) (envelope-from louisk@cryptomonkeys.com) Received: from localhost (h-64-105-36-158.snvacaid.covad.net [64.105.36.158]) (authenticated bits=0) by abeyance.cryptomonkeys.com (8.13.8+Sun/8.13.8) with ESMTP id l6J7Ke8D011970 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Jul 2007 00:20:47 -0700 (PDT) Date: Thu, 19 Jul 2007 00:20:37 -0700 From: Louis Kowolowski To: Jeff Roberson , current@freebsd.org Message-ID: <20070719072028.GA96964@cryptomonkeys.com> References: <20070716233030.D92541@10.0.0.1> <469E5BEE.1090206@smo.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="KsGdsel6WgEHnImy" Content-Disposition: inline In-Reply-To: <469E5BEE.1090206@smo.de> User-Agent: TV Remote 3.2b X-Disclaimer: WARNING: May contain scarcasm! X-Header: "WARNING: POLITICALLY INCORRECT AREA All P.C. Personnel entering these premises will encounter gravely offensive behavior and opinions. (SEC4623. Ministry of political incorrection security act of 1995) RAMPANT INSENSITIVITY AUTHORIZED" X-GPG-Fingerprint: 7A77 80FD 3F4D 995E A807 A218 664D 2BEA 8024 37B6 X-GPG-Key: http://www.cryptomonkeys.com/~louisk/pgp.html Organization: Hopelessly Disorganized Cc: Subject: Re: ULE/SCHED_SMP diff for 7.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2007 07:45:22 -0000 --KsGdsel6WgEHnImy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Jeff Roberson wrote: > Even "works for me!" type responses are welcome so I know roughly how many > people have tested before I commit this close to release. >=20 OK, it's not provable, but so far it doesn't have any little "hangs" like it used to (5-10sec). I've done a full buildworld/kernel with it while working on things in openoffice. Seems to all be happy. Thanks! Copyright (c) 1992-2007 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.0-CURRENT #1: Wed Jul 18 13:03:41 PDT 2007 root@localhost:/usr/obj/usr/src/sys/MONTEZUMA WARNING: WITNESS option enabled, expect reduced performance. Timecounter "i8254" frequency 1193203 Hz quality 0 CPU: Genuine Intel(R) CPU T2600 @ 2.16GHz (2161.31-MHz 686-class= CPU) Origin =3D "GenuineIntel" Id =3D 0x6e8 Stepping =3D 8 Features=3D0xbfe9fbff Features2=3D0xc1a9 AMD Features=3D0x100000 Cores per package: 2 real memory =3D 3219980288 (3070 MB) avail memory =3D 3145490432 (2999 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 Security auditing service present BSM auditing present ACPI Warning (tbfadt-0505): Optional field "Gpe1Block" has zero address or = length: 0 102C/0 [20070320] ioapic0: Changing APIC ID to 1 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 kqemu version 0x00010300 kqemu: KQEMU installed, max_locked_mem=3D1565832kB. ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) cryptosoft0: on motherboard acpi0: on motherboard acpi0: [ITHREAD] acpi_ec0: port 0x62,0x66 on acpi0 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acp= i0 Timecounter "HPET" frequency 14318180 Hz quality 2000 acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, bff00000 (3) failed acpi0: reservation of fec00000, 140000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 cpu0: on acpi0 est0: on cpu0 p4tcc0: on cpu0 cpu1: on acpi0 est1: on cpu1 p4tcc1: on cpu1 acpi_lid0: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 16 at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0x2000-0x20ff mem 0xd0000000-0xdffff= fff,0xee100000-0xee10ffff irq 16 at device 0.0 on pci1 pcm0: mem 0xee400000-0xee40= 3fff irq 17 at device 27.0 on pci0 pcm0: [ITHREAD] pcib2: irq 20 at device 28.0 on pci0 pci2: on pcib2 em0: port 0x3000-0x3= 01f mem 0xee000000-0xee01ffff irq 16 at device 0.0 on pci2 em0: Ethernet address: 00:16:41:58:25:48 em0: [ITHREAD] pcib3: irq 21 at device 28.1 on pci0 pci3: on pcib3 ath0: mem 0xedf00000-0xedf0ffff irq 17 at device 0.0 on pci3 ath0: [ITHREAD] ath0: using obsoleted if_watchdog interface ath0: Ethernet address: 00:16:cf:7b:0d:0d ath0: mac 10.3 phy 6.1 radio 10.2 pcib4: irq 22 at device 28.2 on pci0 pci4: on pcib4 pcib5: irq 23 at device 28.3 on pci0 pci12: on pcib5 uhci0: port 0x1800-0x181f irq 16 at device = 29.0 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0x1820-0x183f irq 17 at device = 29.1 on pci0 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0x1840-0x185f irq 18 at device = 29.2 on pci0 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb2: on uhci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered uhci3: port 0x1860-0x187f irq 19 at device = 29.3 on pci0 uhci3: [GIANT-LOCKED] uhci3: [ITHREAD] usb3: on uhci3 usb3: USB revision 1.0 uhub3: on usb3 uhub3: 2 ports with 2 removable, self powered ehci0: mem 0xee404000-0xee4043f= f irq 19 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb4: EHCI version 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: on ehci0 usb4: USB revision 2.0 uhub4: on usb4 uhub4: 8 ports with 8 removable, self powered pcib6: at device 30.0 on pci0 pci21: on pcib6 cbb0: mem 0xe4300000-0xe4300fff irq 16 at devic= e 0.0 on pci21 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 cbb0: [ITHREAD] isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177= ,0x376,0x1880-0x188f at device 31.1 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] atapci1: port 0x18c8-0x18cf,0x18ac-0x18af,= 0x18c0-0x18c7,0x18a8-0x18ab,0x18b0-0x18bf mem 0xee404400-0xee4047ff irq 16 = at device 31.2 on pci0 atapci1: [ITHREAD] atapci1: AHCI Version 01.10 controller with 4 ports detected ata2: on atapci1 ata2: [ITHREAD] ata3: on atapci1 ata3: port not implemented ata3: [ITHREAD] ata4: on atapci1 ata4: port not implemented ata4: [ITHREAD] ata5: on atapci1 ata5: port not implemented ata5: [ITHREAD] pci0: at device 31.3 (no driver attached) acpi_tz0: on acpi0 acpi_tz1: on acpi0 speaker0: port 0x61 on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model Generic PS/2 mouse, device ID 0 sio0: configured irq 3 not in bitmap of probed irqs 0 sio0: port may not be enabled battery0: on acpi0 acpi_acad0: on acpi0 acpi_ibm0: on acpi0 sio0: configured irq 3 not in bitmap of probed irqs 0 sio0: port may not be enabled pmtimer0 on isa0 orm0: at iomem 0xc0000-0xcffff,0xd0000-0xd0fff,0xd1000-0x= d1fff,0xdc000-0xdffff,0xe0000-0xeffff pnpid ORM0000 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=3D0x300> sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 8250 or not responding sio0: [FILTER] 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 ugen0: on uhub3 NULL mp in getnewvnode() Timecounters tick every 1.000 msec ipfw2 (+ipv6) initialized, divert enabled, rule-based forwarding disabled, = default to deny, logging limited to 10 packets/entry by default acd0: DVDR at ata0-master UDMA33 ad4: 95396MB at ata2-master SATA150 pcm0: pcm0: SMP: AP CPU #1 Launched! WARNING: WITNESS option enabled, expect reduced performance. cd0 at ata0 bus 0 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device=20 cd0: 33.000MB/s transfers Trying to mount root from ufs:/dev/ad4s1a --=20 Louis Kowolowski KE7BAX louisk@cryptomonkeys.com Cryptomonkeys: http://www.cryptomonkeys.com/~louisk Warning: Do not point laser at remaining eye! --KsGdsel6WgEHnImy Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGnxC8Zk0r6oAkN7YRAkQRAJ92IhEKKNaB6EUtZSFV13tXYyEhHwCfXUjc lJ6en8GoOF6LbN3bA5KB9Z8= =vUVb -----END PGP SIGNATURE----- --KsGdsel6WgEHnImy-- From owner-freebsd-current@FreeBSD.ORG Thu Jul 19 08:16:43 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1B52E16A401 for ; Thu, 19 Jul 2007 08:16:43 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) by mx1.freebsd.org (Postfix) with ESMTP id 9669413C442 for ; Thu, 19 Jul 2007 08:16:42 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.1/8.14.1) with ESMTP id l6J8GWxf005597; Thu, 19 Jul 2007 12:16:32 +0400 (MSD) (envelope-from marck@rinet.ru) Date: Thu, 19 Jul 2007 12:16:32 +0400 (MSD) From: Dmitry Morozovsky To: Jeff Roberson In-Reply-To: <20070718154306.R561@10.0.0.1> Message-ID: <20070719121201.P67760@woozle.rinet.ru> References: <20070716233030.D92541@10.0.0.1> <20070718011332.A14574@woozle.rinet.ru> <20070718154306.R561@10.0.0.1> X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (woozle.rinet.ru [0.0.0.0]); Thu, 19 Jul 2007 12:16:32 +0400 (MSD) Cc: current@freebsd.org Subject: Re: ULE/SCHED_SMP diff for 7.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2007 08:16:43 -0000 On Wed, 18 Jul 2007, Jeff Roberson wrote: JR> > Works for me with MSI S420 lapton (core2duo T2400) on fresh -CURRENT/i386 JR> > CPU: Genuine Intel(R) CPU T2400 @ 1.83GHz (1833.41-MHz JR> > 686-class CPU) JR> > JR> > However, make -j3 buildworld buildkernel (trimmed GENERIC) time degraded JR> > by 7%: JR> > JR> > +------------------------------------------------------------------------------+ JR> > N Min Max Median Avg Stddev JR> > x 5 36.33 36.77 36.45 36.486 JR> > + 5 38.87 39.23 39.03 39.042 JR> > Difference at 95.0% confidence JR> > 2.556 +/- 0.216322 JR> > 7.00543% +/- 0.59289% JR> > (Student's t, pooled s = 0.148324) JR> > JR> > before = kernel with SCHED_4BSD, after = SCHED_ULE with your patchset. JR> > Both JR> > are without WITNESS/INVARIANTS. JR> JR> Hi Dmitry, JR> JR> Can you test with http://people.freebsd.org/~jeff/sched_ule.c? I believe JR> this will somewhat improve the situation with buildkernel. I have tested JR> with my own core2duo laptop. The first run after reboot is now about 7% JR> faster than before. Subsequent runs are not improved as much. Only 2-3%. JR> You can also try tuning sysctl kern.sched.steal_thresh down as low as 1 to JR> see how much this may help. Unfortunately lower values tend to really hurt JR> other tests. Well, I'm a bit puzzled: with new sched_ule.c system+user time slightly decreases (within one minute), while real time goes up from 39 to 44 minutes! And most of the time I see 10-50% of idle in top. Any hints? Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Thu Jul 19 08:28:45 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 77ACB16A403 for ; Thu, 19 Jul 2007 08:28:45 +0000 (UTC) (envelope-from markhobden@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.236]) by mx1.freebsd.org (Postfix) with ESMTP id 2ADCF13C4B7 for ; Thu, 19 Jul 2007 08:28:44 +0000 (UTC) (envelope-from markhobden@gmail.com) Received: by wx-out-0506.google.com with SMTP id i29so387666wxd for ; Thu, 19 Jul 2007 01:28:44 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=mYUhdezmrUcEb9IyOzUGqK1S/uEfS/nuf+svBQGRhuYJEuz9lGb00ETYOi9rYwgG7urEBRXFnuGq+ZVBEFDJqW4MHO3CrD/34O6LlbR0cbJZMV1K9PGFRL2HA6B5W/Q4msyWgip9I+ZXhmhMfI93fr5XLaplrwpQ091YF+P2RpQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Y0eaL9aFQtfIjvJB22UmhEr3dO+Izp6V4dWXqAxm9H1aNlW4VNQTOdsTKWe4JKuc8f3wm+K31JInAWyhoP9BBE/jEJo1boy4RKSO2UJ9nmNmA3kWPslMcfjA763M26GwbbVHkFFdivDzcGrb1fsOc6UDqGimuYcaQscyVO14llI= Received: by 10.90.68.15 with SMTP id q15mr2473601aga.1184833724402; Thu, 19 Jul 2007 01:28:44 -0700 (PDT) Received: by 10.90.117.10 with HTTP; Thu, 19 Jul 2007 01:28:44 -0700 (PDT) Message-ID: Date: Thu, 19 Jul 2007 09:28:44 +0100 From: "Mark Hobden" To: "M. Warner Losh" In-Reply-To: <20070718.203153.112852673.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070718.203153.112852673.imp@bsdimp.com> Cc: freebsd-current@freebsd.org, freebsd-usb@freebsd.org Subject: Re: uhidev(4) update - USB HID driver level for devices with multiple report ids X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Jul 2007 08:28:45 -0000 On 19/07/07, M. Warner Losh wrote: > In message: > "Mark Hobden" writes: > : I have updated the uhidev(4) patch from NetBSD to apply to today's 7-CURRENT. > : > : http://www.terinea.co.uk/~mark/patches/uhidev-7-current-p2.diff > > this one seems to be backwards > Sorry Warner, I don't quite get what you mean here. Do you mean that the patch is only wanting to apply with patch -R ?? or does not want to apply in some way? or that I have removed the changes made in ums.c version 1.95. This is the case as the other patch I posted makes them work with the correct report id. I split up the patches to make it a bit clearer how the problem is fixed - I am using a WLNOTEBOOK (0x00b9) mouse right now and they work fine. or have I managed remove functionality somewhere else? Thanks, Mark From owner-freebsd-current@FreeBSD.ORG Thu Jul 19 08:40:06 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7DB2C16A403 for ; Thu, 19 Jul 2007 08:40:06 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id E7EB913C4A7 for ; Thu, 19 Jul 2007 08:40:05 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 86828 invoked from network); 19 Jul 2007 08:09:55 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 19 Jul 2007 08:09:55 -0000 Message-ID: <469F1D32.2040700@freebsd.org> Date: Thu, 19 Jul 2007 10:13:38 +0200 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Jack Vogel References: <2a41acea0707181152r4c662b00tf1be7b6b4dce74f1@mail.gmail.com> <2a41acea0707181542q23d36733o339448ad86f480cb@mail.gmail.com> In-Reply-To: <2a41acea0707181542q23d36733o339448ad86f480cb@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net , FreeBSD Current Subject: Re: 10G and socket alloc failure X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Jul 2007 08:40:06 -0000 Jack Vogel wrote: > While testing out the ixgbe driver we've observed this failure in the stack > code, here is the info: > > The test engineer is using iperf, typically with 16 threads. If the > driver is using > either legacy or MSI interrupts we will see broken pipes, in dmesg its > due to sonewconn() failing in syncache_socket(). > > Whats interesting is that when I have multiple RX queues configured and > using MSI/X this doesnt happen, at least not very often. > > It does not seem to hurt performance horribly, iperf just spawns another > thread, but I was wondering if there is some underlying tuneable I dont > know about that would stop this from happening?? > > And any theory about why it doesnt happen with multiple queues? Do you see any messages in syslog regarding syncache? -- Andre From owner-freebsd-current@FreeBSD.ORG Thu Jul 19 08:46:57 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2B8B616A403 for ; Thu, 19 Jul 2007 08:46:57 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.183]) by mx1.freebsd.org (Postfix) with ESMTP id 01E6B13C4A5 for ; Thu, 19 Jul 2007 08:46:56 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by wa-out-1112.google.com with SMTP id j37so580375waf for ; Thu, 19 Jul 2007 01:46:56 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=XsQUcigE22aJkQDH9MMtQzHxIR9tAJfcc8d2NdobDTbupga6HKpcxE5xZCfpq+co3u4Aq1ODmMydXpBsnmE4EJOmMDd6diQzlOhMuWC3gxhcnIbtUMyEOfrV426kWyAxqbAqOle6ESFqBe4SqIzwT7wOchfOpOe3EOToRy3mzCg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=TXFxWpEKU+/cGczJZFpMxxdfQZLGbtzBOX3rDVQmOb/C4ENXXeiQPCteadUAuIFHILUP3QFofm0Dv/VR0W5pked0vh0F7TfOAYuJroVphCqz6uX6p3CKVFXlI/PPPh6V4qcW/wzMvnxAZF9b97oqpCkFeQr60xnSJsGXUJGt1nk= Received: by 10.114.166.1 with SMTP id o1mr2363352wae.1184834816203; Thu, 19 Jul 2007 01:46:56 -0700 (PDT) Received: by 10.114.103.14 with HTTP; Thu, 19 Jul 2007 01:46:56 -0700 (PDT) Message-ID: <2a41acea0707190146q2fcc5d9cq865e9571cd6104e3@mail.gmail.com> Date: Thu, 19 Jul 2007 01:46:56 -0700 From: "Jack Vogel" To: "Andre Oppermann" In-Reply-To: <469F1D32.2040700@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <2a41acea0707181152r4c662b00tf1be7b6b4dce74f1@mail.gmail.com> <2a41acea0707181542q23d36733o339448ad86f480cb@mail.gmail.com> <469F1D32.2040700@freebsd.org> Cc: freebsd-net , FreeBSD Current Subject: Re: 10G and socket alloc failure X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Jul 2007 08:46:57 -0000 On 7/19/07, Andre Oppermann wrote: > Jack Vogel wrote: > > While testing out the ixgbe driver we've observed this failure in the stack > > code, here is the info: > > > > The test engineer is using iperf, typically with 16 threads. If the > > driver is using > > either legacy or MSI interrupts we will see broken pipes, in dmesg its > > due to sonewconn() failing in syncache_socket(). > > > > Whats interesting is that when I have multiple RX queues configured and > > using MSI/X this doesnt happen, at least not very often. > > > > It does not seem to hurt performance horribly, iperf just spawns another > > thread, but I was wondering if there is some underlying tuneable I dont > > know about that would stop this from happening?? > > > > And any theory about why it doesnt happen with multiple queues? > > Do you see any messages in syslog regarding syncache? Yes, the messages are what are emitted in the code i cited above, I could get the dmesg output if that would provide any more help. I figured the point at which it is failing is pretty specific and someone might know just from that what it was :) Jack From owner-freebsd-current@FreeBSD.ORG Thu Jul 19 08:53:42 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 97EDC16A404 for ; Thu, 19 Jul 2007 08:53:42 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from webaccess-cl.virtdom.com (webaccess-cl.virtdom.com [216.240.101.25]) by mx1.freebsd.org (Postfix) with ESMTP id 630F713C4B3 for ; Thu, 19 Jul 2007 08:53:42 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from [192.168.1.101] (c-71-231-138-78.hsd1.or.comcast.net [71.231.138.78]) (authenticated bits=0) by webaccess-cl.virtdom.com (8.13.6/8.13.6) with ESMTP id l6J8re9A071725 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Thu, 19 Jul 2007 04:53:41 -0400 (EDT) (envelope-from jroberson@chesapeake.net) Date: Thu, 19 Jul 2007 01:56:53 -0700 (PDT) From: Jeff Roberson X-X-Sender: jroberson@10.0.0.1 To: Dmitry Morozovsky In-Reply-To: <20070719121201.P67760@woozle.rinet.ru> Message-ID: <20070719015335.Q561@10.0.0.1> References: <20070716233030.D92541@10.0.0.1> <20070718011332.A14574@woozle.rinet.ru> <20070718154306.R561@10.0.0.1> <20070719121201.P67760@woozle.rinet.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: current@freebsd.org Subject: Re: ULE/SCHED_SMP diff for 7.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2007 08:53:42 -0000 On Thu, 19 Jul 2007, Dmitry Morozovsky wrote: > On Wed, 18 Jul 2007, Jeff Roberson wrote: > > JR> > Works for me with MSI S420 lapton (core2duo T2400) on fresh -CURRENT/i386 > JR> > CPU: Genuine Intel(R) CPU T2400 @ 1.83GHz (1833.41-MHz > JR> > 686-class CPU) > JR> > > JR> > However, make -j3 buildworld buildkernel (trimmed GENERIC) time degraded > JR> > by 7%: > JR> > > JR> > +------------------------------------------------------------------------------+ > JR> > N Min Max Median Avg Stddev > JR> > x 5 36.33 36.77 36.45 36.486 > JR> > + 5 38.87 39.23 39.03 39.042 > JR> > Difference at 95.0% confidence > JR> > 2.556 +/- 0.216322 > JR> > 7.00543% +/- 0.59289% > JR> > (Student's t, pooled s = 0.148324) > JR> > > JR> > before = kernel with SCHED_4BSD, after = SCHED_ULE with your patchset. > JR> > Both > JR> > are without WITNESS/INVARIANTS. > JR> > JR> Hi Dmitry, > JR> > JR> Can you test with http://people.freebsd.org/~jeff/sched_ule.c? I believe > JR> this will somewhat improve the situation with buildkernel. I have tested > JR> with my own core2duo laptop. The first run after reboot is now about 7% > JR> faster than before. Subsequent runs are not improved as much. Only 2-3%. > JR> You can also try tuning sysctl kern.sched.steal_thresh down as low as 1 to > JR> see how much this may help. Unfortunately lower values tend to really hurt > JR> other tests. > > > Well, I'm a bit puzzled: with new sched_ule.c system+user time slightly > decreases (within one minute), while real time goes up from 39 to 44 minutes! > And most of the time I see 10-50% of idle in top. Please try setting sysctl kern.sched.steal_thresh=2 This is the setting I intend to commit. I also was only testing buildkernel which tends to run more processes concurrently as compared to buildworld. Thanks, Jeff > > Any hints? > > Sincerely, > D.Marck [DM5020, MCK-RIPE, DM3-RIPN] > ------------------------------------------------------------------------ > *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** > ------------------------------------------------------------------------ > _______________________________________________ > 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 Jul 19 08:55:07 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E574F16A400 for ; Thu, 19 Jul 2007 08:55:07 +0000 (UTC) (envelope-from yuri@darklight.org.ru) Received: from darklight.org.ru (darklight.org.ru [194.186.18.14]) by mx1.freebsd.org (Postfix) with ESMTP id 7BDFF13C481 for ; Thu, 19 Jul 2007 08:55:05 +0000 (UTC) (envelope-from yuri@darklight.org.ru) Received: from darklight.org.ru (yuri@darklight.org.ru [127.0.0.1]) by darklight.org.ru (8.14.1/8.14.1) with ESMTP id l6J8rrR9052049 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Jul 2007 12:53:58 +0400 (MSD) (envelope-from yuri@darklight.org.ru) Received: (from yuri@localhost) by darklight.org.ru (8.14.1/8.14.1/Submit) id l6J8rqS6052048; Thu, 19 Jul 2007 12:53:52 +0400 (MSD) (envelope-from yuri@darklight.org.ru) Date: Thu, 19 Jul 2007 12:53:52 +0400 From: Yuri Pankov To: Jeff Roberson Message-ID: <20070719085352.GA37441@darklight.org.ru> References: <20070717182819.L92541@10.0.0.1> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="r5Pyd7+fXNt84Ff3" Content-Disposition: inline In-Reply-To: <20070717182819.L92541@10.0.0.1> User-Agent: Mutt/1.5.16 (2007-06-09) X-Greylist: Sender is SPF-compliant, not delayed by milter-greylist-3.0 (darklight.org.ru [127.0.0.1]); Thu, 19 Jul 2007 12:53:59 +0400 (MSD) Cc: current@freebsd.org Subject: Re: cvs commit: src/sys/kern sched_ule.c (fwd) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Jul 2007 08:55:08 -0000 --r5Pyd7+fXNt84Ff3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 17, 2007 at 06:31:37PM -0700, Jeff Roberson wrote: > Thanks everyone for your help. In summary it sounds like there are two= =20 > issues. > > 1) kqemu explicitly uses sched_lock. I'll see if I can contact the auth= or=20 > about fixing this. > > 2) As much as a 6-7% slowdown on buildworld on dual core machines as=20 > compared to 4BSD. I'm not sure if I'm going to do anything about this.= =20 > Once you get to 4 or 8 cores and -j8 or more they even out with ULE havin= g=20 > significantly less system time. I don't know if I want to compromise tha= t=20 > for slightly better dual core compile times. > > This is in the tree for 7.0 now though. I'm very excited to see this=20 > happen. > > Thanks again, > Jeff Hi Jeff, I can't build kernel after this commit, sources updated at Jul, 19, 8am GMT, amd64: cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=3Dc99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=3D8000 --param inline-unit-growth=3D100 --param large-function-growth=3D1000 -fno-omit-frame-pointer -mcmodel=3Dkernel -mno-red-zone -mfpmath=3D387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror /usr/src/sys/kern/sched_ule.c In file included from /usr/src/sys/kern/sched_ule.c:2554: /usr/src/sys/kern/kern_switch.c: In function 'maybe_preempt': /usr/src/sys/kern/kern_switch.c:270: error: 'sched_lock' undeclared (first use in this function) /usr/src/sys/kern/kern_switch.c:270: error: (Each undeclared identifier is reported only once /usr/src/sys/kern/kern_switch.c:270: error: for each function it appears in.) *** Error code 1 config: include GENERIC ident DARKLIGHT nooptions SCHED_4BSD options SCHED_ULE options SHMMAXPGS=3D65536 options SEMMNI=3D40 options SEMMNS=3D240 options SEMUME=3D40 options SEMMNU=3D120 options GEOM_JOURNAL device sound device snd_ich TIA and sorry if this is pilot error, Yuri --r5Pyd7+fXNt84Ff3 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQBGnyageoAklVFrLdgRAq1PAJ476BSabXFFTGX45wc7FkZYszcWPQCfTPc5 ND7Rmto22Hq4A+UPpmAMlrA= =LokT -----END PGP SIGNATURE----- --r5Pyd7+fXNt84Ff3-- From owner-freebsd-current@FreeBSD.ORG Thu Jul 19 08:59:47 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B42C116A406 for ; Thu, 19 Jul 2007 08:59:47 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from webaccess-cl.virtdom.com (webaccess-cl.virtdom.com [216.240.101.25]) by mx1.freebsd.org (Postfix) with ESMTP id 68C2513C4BB for ; Thu, 19 Jul 2007 08:59:47 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from [192.168.1.101] (c-71-231-138-78.hsd1.or.comcast.net [71.231.138.78]) (authenticated bits=0) by webaccess-cl.virtdom.com (8.13.6/8.13.6) with ESMTP id l6J8xVF3072174 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Thu, 19 Jul 2007 04:59:32 -0400 (EDT) (envelope-from jroberson@chesapeake.net) Date: Thu, 19 Jul 2007 02:02:44 -0700 (PDT) From: Jeff Roberson X-X-Sender: jroberson@10.0.0.1 To: Yuri Pankov In-Reply-To: <20070719085352.GA37441@darklight.org.ru> Message-ID: <20070719020201.F561@10.0.0.1> References: <20070717182819.L92541@10.0.0.1> <20070719085352.GA37441@darklight.org.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: current@freebsd.org Subject: Re: cvs commit: src/sys/kern sched_ule.c (fwd) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Jul 2007 08:59:47 -0000 On Thu, 19 Jul 2007, Yuri Pankov wrote: > On Tue, Jul 17, 2007 at 06:31:37PM -0700, Jeff Roberson wrote: >> Thanks everyone for your help. In summary it sounds like there are two >> issues. >> >> 1) kqemu explicitly uses sched_lock. I'll see if I can contact the author >> about fixing this. >> >> 2) As much as a 6-7% slowdown on buildworld on dual core machines as >> compared to 4BSD. I'm not sure if I'm going to do anything about this. >> Once you get to 4 or 8 cores and -j8 or more they even out with ULE having >> significantly less system time. I don't know if I want to compromise that >> for slightly better dual core compile times. >> >> This is in the tree for 7.0 now though. I'm very excited to see this >> happen. >> >> Thanks again, >> Jeff > > Hi Jeff, > > I can't build kernel after this commit, sources updated at Jul, 19, 8am > GMT, amd64: Left a file out of an earlier commit. Sorry! You can delete those asserts or cvsup again. Thanks, Jeff > > cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -g > -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes > -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef > -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/usr/src/sys > -I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS > -include opt_global.h -fno-common -finline-limit=8000 --param > inline-unit-growth=100 --param large-function-growth=1000 > -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 > /usr/src/sys/kern/sched_ule.c > In file included from /usr/src/sys/kern/sched_ule.c:2554: > /usr/src/sys/kern/kern_switch.c: In function 'maybe_preempt': > /usr/src/sys/kern/kern_switch.c:270: error: 'sched_lock' undeclared > (first use in this function) > /usr/src/sys/kern/kern_switch.c:270: error: (Each undeclared identifier > is reported only once > /usr/src/sys/kern/kern_switch.c:270: error: for each function it appears > in.) > *** Error code 1 > > config: > include GENERIC > ident DARKLIGHT > > nooptions SCHED_4BSD > options SCHED_ULE > > options SHMMAXPGS=65536 > options SEMMNI=40 > options SEMMNS=240 > options SEMUME=40 > options SEMMNU=120 > > options GEOM_JOURNAL > > device sound > device snd_ich > > > TIA and sorry if this is pilot error, > Yuri > From owner-freebsd-current@FreeBSD.ORG Thu Jul 19 09:34:16 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7E7CA16A403 for ; Thu, 19 Jul 2007 09:34:16 +0000 (UTC) (envelope-from jmadle@tac-tac.cz) Received: from mail.tac-tac.cz (mail.tac-tac.cz [194.212.102.90]) by mx1.freebsd.org (Postfix) with ESMTP id DE00B13C4B2 for ; Thu, 19 Jul 2007 09:34:15 +0000 (UTC) (envelope-from jmadle@tac-tac.cz) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.tac-tac.cz (Postfix) with ESMTP id 24C05267A5 for ; Thu, 19 Jul 2007 11:34:11 +0200 (CEST) Received: from mail.tac-tac.cz ([127.0.0.1]) by localhost (mail [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30462-06 for ; Thu, 19 Jul 2007 11:34:05 +0200 (CEST) Received: from pcjirka (unknown [1.0.0.10]) by mail.tac-tac.cz (Postfix) with SMTP id 4797F248F6 for ; Thu, 19 Jul 2007 11:34:05 +0200 (CEST) Message-ID: <00b901c7c9e7$f2213780$0a000001@pcjirka> From: "TAC-TAC computer s.r.o." To: Date: Thu, 19 Jul 2007 11:34:03 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tac-tac.cz Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: NETATALK/ MacOs8 problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2007 09:34:16 -0000 Hi, I need some help with some trouble. After upgrading from freebsd 6.2 to current I`m having some problems = with MacOs 8.5.1. on older G3. Reading from BSD server proceeds in a full speed. Problem is that = sending the data on a BSD server is just 4-8 kB/sec - but without any = error in logs.. G4 boxes with MacOs 9 and higher (MacOsX included) haven`t any problems. I tried to change NIC on the server side and on the stations side, but = it didn`t solve my problem. I also tried netatalk 2.0.3-4,1 and 2.0.3-3,1 - no effect. I`m affraid that problem is in a core/netatalk.=20 I would appreciate any help, where and how to search for any solution of = above-mentioned trouble. Thanks a lot in advance! Jiri Madle uname -a FreeBSD hell.tac-tac.cz 7.0-CURRENT FreeBSD 7.0-CURRENT #3: Sun Jul 15 = 13:51:34 CEST 2007 root@hell.tac-tac.cz:/usr/obj/usr/src/sys/TACTAC = amd64 From owner-freebsd-current@FreeBSD.ORG Thu Jul 19 09:50:54 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 13E6B16A400 for ; Thu, 19 Jul 2007 09:50:54 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (c220-239-20-82.belrs4.nsw.optusnet.com.au [220.239.20.82]) by mx1.freebsd.org (Postfix) with ESMTP id 92FB613C4AC for ; Thu, 19 Jul 2007 09:50:53 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by turion.vk2pj.dyndns.org (8.14.1/8.14.1) with ESMTP id l6J9oh7j001792; Thu, 19 Jul 2007 19:50:43 +1000 (EST) (envelope-from peter@turion.vk2pj.dyndns.org) Received: (from peter@localhost) by turion.vk2pj.dyndns.org (8.14.1/8.14.1/Submit) id l6J9oheV001791; Thu, 19 Jul 2007 19:50:43 +1000 (EST) (envelope-from peter) Date: Thu, 19 Jul 2007 19:50:43 +1000 From: Peter Jeremy To: Rui Paulo Message-ID: <20070719095043.GT1141@turion.vk2pj.dyndns.org> References: <469D651C.6080504@fnop.net> <40882.1184765616@snapdragon.csl.sri.com> <469E737B.5090609@fnop.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="9amGYk9869ThD9tj" Content-Disposition: inline In-Reply-To: <469E737B.5090609@fnop.net> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.16 (2007-06-09) Cc: current@freebsd.org Subject: Re: less -r broken with long lines X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Jul 2007 09:50:54 -0000 --9amGYk9869ThD9tj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2007-Jul-18 21:09:31 +0100, Rui Paulo wrote: >It depends on the interpretation. "various display problems may result" >may very well be a reference to the fact that control characters mangle >the output. I wasn't expecting long lines to mangle the output. If you >less -r a file without control characters, but with a least a line wider >than your screen size, you'll notice the problem. I think the behaviour of "less" is reasonable. To correctly work out how many lines of input will fill the screen, "less" needs to identify if/where the terminal will split a string of characters into distinct physical lines. In the face of arbitrary control sequences, it is impossible for "less" to determine this since it cannot know how a particular string will be processed. (It can't rely on termcap/info strings because they are unlikely to document all terminal features). --=20 Peter Jeremy --9amGYk9869ThD9tj Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGnzPz/opHv/APuIcRAknyAJ92Rq9GqmSYc14tACfjZAR2Z8TfVACfUthN MJqEqtHBuBq5Q1GQBxq8CTQ= =3qWS -----END PGP SIGNATURE----- --9amGYk9869ThD9tj-- From owner-freebsd-current@FreeBSD.ORG Thu Jul 19 10:00:21 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D698D16A401 for ; Thu, 19 Jul 2007 10:00:21 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) by mx1.freebsd.org (Postfix) with ESMTP id 5E68C13C481 for ; Thu, 19 Jul 2007 10:00:21 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.1/8.14.1) with ESMTP id l6JA0Brp007938; Thu, 19 Jul 2007 14:00:11 +0400 (MSD) (envelope-from marck@rinet.ru) Date: Thu, 19 Jul 2007 14:00:11 +0400 (MSD) From: Dmitry Morozovsky To: Jeff Roberson In-Reply-To: <20070719015335.Q561@10.0.0.1> Message-ID: <20070719135750.S67760@woozle.rinet.ru> References: <20070716233030.D92541@10.0.0.1> <20070718011332.A14574@woozle.rinet.ru> <20070718154306.R561@10.0.0.1> <20070719121201.P67760@woozle.rinet.ru> <20070719015335.Q561@10.0.0.1> X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (woozle.rinet.ru [0.0.0.0]); Thu, 19 Jul 2007 14:00:11 +0400 (MSD) Cc: current@freebsd.org Subject: Re: ULE/SCHED_SMP diff for 7.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2007 10:00:21 -0000 On Thu, 19 Jul 2007, Jeff Roberson wrote: JR> > JR> > N Min Max Median Avg JR> > JR> > x 5 36.33 36.77 36.45 36.486 JR> > JR> > + 5 38.87 39.23 39.03 39.042 JR> > JR> > Well, I'm a bit puzzled: with new sched_ule.c system+user time slightly JR> > decreases (within one minute), while real time goes up from 39 to 44 JR> > minutes! JR> > And most of the time I see 10-50% of idle in top. JR> JR> Please try setting sysctl kern.sched.steal_thresh=2 This is the setting I JR> intend to commit. I also was only testing buildkernel which tends to run JR> more processes concurrently as compared to buildworld. Much better! buildworld+buildkernel finished in 37:23, which is almost identical to SCHED_4BSD. user+sys is stable around 64 mins. Thanks for your hard work! Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Thu Jul 19 10:21:05 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E64D416A410 for ; Thu, 19 Jul 2007 10:21:05 +0000 (UTC) (envelope-from leafy7382@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.248]) by mx1.freebsd.org (Postfix) with ESMTP id 90AE013C4B2 for ; Thu, 19 Jul 2007 10:21:05 +0000 (UTC) (envelope-from leafy7382@gmail.com) Received: by an-out-0708.google.com with SMTP id c14so123530anc for ; Thu, 19 Jul 2007 03:21:04 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=rmTH2hCONijXfExInbT4+gRKHfqhFYXdcMBgesA5yGg9MgNvb6W8PH+1llLSh6wMHlH15d28QJXATRSMhQI2jVedpU8ixqHq7aUNfrfsjwCdT2Rm3vEZFCtlxaNgB9STk1vqo9CSIO658iSJil+BL94NdpO2x/biFPdaRvxbQPg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=HIar6jZ3ibfvnxBdFwdWBXjGRgr6ti/yPKtyY++BHX09w33xhZuWDGUPR8u4ZwgE+VGnzfXAsazL1PpWhpM15j7WXWkF0Ybsa6e5snUO+D6//YVe+asfgalWxyqXkVaUyyovLHJaR89TIFk650ZvZkmKpACWe2VL36ZZ5N2YPdY= Received: by 10.100.122.8 with SMTP id u8mr1467214anc.1184840464595; Thu, 19 Jul 2007 03:21:04 -0700 (PDT) Received: by 10.100.137.3 with HTTP; Thu, 19 Jul 2007 03:21:04 -0700 (PDT) Message-ID: Date: Thu, 19 Jul 2007 18:21:04 +0800 From: "Jiawei Ye" To: "Jeff Roberson" In-Reply-To: <20070718191306.X561@10.0.0.1> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070716233030.D92541@10.0.0.1> <469E83F8.3090103@gmail.com> <20070718142649.Y561@10.0.0.1> <469E897B.7080100@gmail.com> <469E9AE4.6050007@FreeBSD.org> <469EA0A2.1080901@gmail.com> <20070718163259.S561@10.0.0.1> <20070718191306.X561@10.0.0.1> Cc: current@freebsd.org Subject: Re: ULE/SCHED_SMP diff for 7.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2007 10:21:06 -0000 On 7/19/07, Jeff Roberson wrote: > On Thu, 19 Jul 2007, Jiawei Ye wrote: > > > After running the new ULE 3.0 for 2 days, I got this panic when try to > > install diablo-jdk > > Hi, > > Can you try the file at http://people.freebsd.org/~jeff/sched_ule.c > > I fixed a couple of bugs that might impact you. > > Thanks, > Jeff > So far so good, thanks for the patch. Jiawei -- "If it looks like a duck, walks like a duck, and quacks like a duck, then to the end user it's a duck, and end users have made it pretty clear they want a duck; whether the duck drinks hot chocolate or coffee is irrelevant." From owner-freebsd-current@FreeBSD.ORG Thu Jul 19 11:33:38 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 46BD416A402 for ; Thu, 19 Jul 2007 11:33:38 +0000 (UTC) (envelope-from kereoz@free.fr) Received: from postfix1-g20.free.fr (postfix1-g20.free.fr [212.27.60.42]) by mx1.freebsd.org (Postfix) with ESMTP id BE31213C474 for ; Thu, 19 Jul 2007 11:33:37 +0000 (UTC) (envelope-from kereoz@free.fr) Received: from smtp5-g19.free.fr (smtp5-g19.free.fr [212.27.42.35]) by postfix1-g20.free.fr (Postfix) with ESMTP id A2DFE171B393 for ; Thu, 19 Jul 2007 13:09:19 +0200 (CEST) Received: from [192.168.0.1] (pat35-3-82-245-141-208.fbx.proxad.net [82.245.141.208]) by smtp5-g19.free.fr (Postfix) with ESMTP id 17B2244FC6 for ; Thu, 19 Jul 2007 13:09:17 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <5958B5B4-60DD-4A12-89CF-B2939BA93B71@free.fr> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: current@freebsd.org From: Christophe H Date: Thu, 19 Jul 2007 13:09:16 +0200 X-Mailer: Apple Mail (2.752.3) Cc: Subject: Panic on a Core Duo Macbook pro X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Jul 2007 11:33:38 -0000 Hello, when I try to boot the latest snapshot of 7-current on my Core Duo Macbook pro (r 1.1), I get a panic : AP#1 (PHY#1) failed ! Panic while FreeBSD 6.2-release can boot. Is there a way to give some kernel options at boot to avoid this ? Thanks, Chris From owner-freebsd-current@FreeBSD.ORG Thu Jul 19 11:35:17 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4D7FF16A400 for ; Thu, 19 Jul 2007 11:35:17 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from ns.trinitel.com (186.161.36.72.static.reverse.layeredtech.com [72.36.161.186]) by mx1.freebsd.org (Postfix) with ESMTP id 0C23D13C4A6 for ; Thu, 19 Jul 2007 11:35:16 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from proton.local (209-163-168-124.static.twtelecom.net [209.163.168.124]) (authenticated bits=0) by ns.trinitel.com (8.14.1/8.14.1) with ESMTP id l6JBZES4004469; Thu, 19 Jul 2007 06:35:14 -0500 (CDT) (envelope-from anderson@freebsd.org) Message-ID: <469F4C71.7070500@freebsd.org> Date: Thu, 19 Jul 2007 06:35:13 -0500 From: Eric Anderson User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: Christophe H References: <5958B5B4-60DD-4A12-89CF-B2939BA93B71@free.fr> In-Reply-To: <5958B5B4-60DD-4A12-89CF-B2939BA93B71@free.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on ns.trinitel.com Cc: current@freebsd.org Subject: Re: Panic on a Core Duo Macbook pro X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Jul 2007 11:35:17 -0000 Christophe H wrote: > Hello, > > when I try to boot the latest snapshot of 7-current on my Core Duo > Macbook pro (r 1.1), I get a panic : > AP#1 (PHY#1) failed ! > Panic > > while FreeBSD 6.2-release can boot. > > Is there a way to give some kernel options at boot to avoid this ? Same here with my Macbook Pro. I tried some hints from Rui Paulo, with no success. Was that an i386 snapshot, or AMD64? Eric From owner-freebsd-current@FreeBSD.ORG Thu Jul 19 11:56:30 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 728A916A402 for ; Thu, 19 Jul 2007 11:56:30 +0000 (UTC) (envelope-from tony@crosswinds.net) Received: from out-mx1.crosswinds.net (out-mx1.crosswinds.net [216.18.117.38]) by mx1.freebsd.org (Postfix) with ESMTP id 4F72313C4A5 for ; Thu, 19 Jul 2007 11:56:30 +0000 (UTC) (envelope-from tony@crosswinds.net) Received: from admin.crosswinds.net (out-mx1.crosswinds.net [216.18.117.38]) by out-mx1.crosswinds.net (Postfix) with ESMTP id D9F4B2C250; Thu, 19 Jul 2007 07:56:51 -0400 (EDT) Received: by admin.crosswinds.net (Postfix, from userid 1001) id 882F9403D; Thu, 19 Jul 2007 07:56:51 -0400 (EDT) Date: Thu, 19 Jul 2007 07:56:51 -0400 From: Tony Holmes To: Scott Long Message-ID: <20070719115651.GA74237@crosswinds.net> References: <20070718133345.GA82366@crosswinds.net> <469EE67F.8030504@samsco.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <469EE67F.8030504@samsco.org> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@freebsd.org Subject: Re: 7.0/6.2, 4GB and AHC X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Jul 2007 11:56:30 -0000 On +Jul 19, Scott Long wrote: > The AHC driver was personally tested with >4GB while it was in active > development, but it's certainly possible that bugs have crept in over > the years. I'll test it when I get off vacation next week and see what > I come up with. Please contact me directly if I forget. Just out of > curiosity, try booting with one of your known bad configurations and > break into the the loader prompt and do the following: > > set vm.old_contigmalloc=1 Ah I wish I could but the box has been deployed into production 550 km away with 2GB :) It was very easy to reproduce - 4GB ram, 2 ahc cards with drives and 6.2R amd64 would trigger it. -- Tony Holmes Ph: (416) 993-1219 Founder and Senior Systems Architect Crosswinds Internet Communications Inc. From owner-freebsd-current@FreeBSD.ORG Thu Jul 19 12:20:09 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BB7F016A401 for ; Thu, 19 Jul 2007 12:20:09 +0000 (UTC) (envelope-from ianf@clue.co.za) Received: from munchkin.clue.co.za (munchkin.clue.co.za [66.219.59.160]) by mx1.freebsd.org (Postfix) with ESMTP id 8897C13C4A3 for ; Thu, 19 Jul 2007 12:20:09 +0000 (UTC) (envelope-from ianf@clue.co.za) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=20070313; d=clue.co.za; h=Received:Received:Received:To:cc:From:Subject:In-Reply-To:X-Attribution:Date:Message-Id; b=PSiTsPDK2iAXZ4tJ0VpJhoTASUnIxuV4gbRameBKm+r+xsc35+uTQRtq1k20LSsCHRC3vLNRSxQ/SfeRgYoCY8FbVNUJUzsraRo3l7ybn+bj+Ly/TMzjgniOyyKKb9JNLkGDmHuLB5tLSIZNhWifGa+IS4JPxdZxyIm+uhIhmaV0l96vHApkq67eA3V4L1pJpMDyXH/dAp1LEsQPbu3FEwSoS9kuB4G4WM8XuwpKxQMbiLjlfD6zxZdRK2gjE62Y; Received: from uucp by munchkin.clue.co.za with local (Exim 4.66) (envelope-from ) id 1IBUzI-0007iV-GO; Thu, 19 Jul 2007 12:20:08 +0000 Received: from ianf.clue.co.za ([10.0.0.6] helo=clue.co.za) by urchin.clue.co.za with esmtpa (Exim 4.66) (envelope-from ) id 1IBUyn-0006kN-Bv; Thu, 19 Jul 2007 12:19:37 +0000 Received: from localhost ([127.0.0.1] helo=clue.co.za) by clue.co.za with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IBUym-0001NW-9m; Thu, 19 Jul 2007 14:19:36 +0200 To: Eric Anderson From: Ian FREISLICH In-Reply-To: Message from Eric Anderson of "Thu, 19 Jul 2007 06:35:13 EST." <469F4C71.7070500@freebsd.org> X-Attribution: BOFH Date: Thu, 19 Jul 2007 14:19:36 +0200 Message-Id: Cc: Christophe H , current@freebsd.org Subject: Re: Panic on a Core Duo Macbook pro X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Jul 2007 12:20:09 -0000 Eric Anderson wrote: > Christophe H wrote: > > Hello, > > > > when I try to boot the latest snapshot of 7-current on my Core Duo > > Macbook pro (r 1.1), I get a panic : > > AP#1 (PHY#1) failed ! > > Panic > > > > while FreeBSD 6.2-release can boot. > > > > Is there a way to give some kernel options at boot to avoid this ? > > > Same here with my Macbook Pro. I tried some hints from Rui Paulo, with > no success. Was that an i386 snapshot, or AMD64? Have you tried pressing any key on the keyboard before the boot gets to this point? At the copyright does it for me. Ian -- Ian Freislich From owner-freebsd-current@FreeBSD.ORG Thu Jul 19 13:12:02 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 77A5316A40E for ; Thu, 19 Jul 2007 13:12:02 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from ns.trinitel.com (186.161.36.72.static.reverse.layeredtech.com [72.36.161.186]) by mx1.freebsd.org (Postfix) with ESMTP id 2E23B13C4CB for ; Thu, 19 Jul 2007 13:12:01 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from proton.local (209-163-168-124.static.twtelecom.net [209.163.168.124]) (authenticated bits=0) by ns.trinitel.com (8.14.1/8.14.1) with ESMTP id l6JDBuOD049585; Thu, 19 Jul 2007 08:11:57 -0500 (CDT) (envelope-from anderson@freebsd.org) Message-ID: <469F631A.7060201@freebsd.org> Date: Thu, 19 Jul 2007 08:11:54 -0500 From: Eric Anderson User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: Ian FREISLICH References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on ns.trinitel.com Cc: Christophe H , current@freebsd.org Subject: Re: Panic on a Core Duo Macbook pro X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Jul 2007 13:12:02 -0000 Ian FREISLICH wrote: > Eric Anderson wrote: >> Christophe H wrote: >>> Hello, >>> >>> when I try to boot the latest snapshot of 7-current on my Core Duo >>> Macbook pro (r 1.1), I get a panic : >>> AP#1 (PHY#1) failed ! >>> Panic >>> >>> while FreeBSD 6.2-release can boot. >>> >>> Is there a way to give some kernel options at boot to avoid this ? >> >> Same here with my Macbook Pro. I tried some hints from Rui Paulo, with >> no success. Was that an i386 snapshot, or AMD64? > > Have you tried pressing any key on the keyboard before the boot > gets to this point? At the copyright does it for me. Yes, but I'll give it another try today. Eric From owner-freebsd-current@FreeBSD.ORG Thu Jul 19 14:10:19 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 323A416A40A; Thu, 19 Jul 2007 14:10:19 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id E3E4813C4B3; Thu, 19 Jul 2007 14:10:18 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.13.8/8.13.4) with ESMTP id l6JE7YXl084869; Thu, 19 Jul 2007 08:07:34 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Thu, 19 Jul 2007 08:07:40 -0600 (MDT) Message-Id: <20070719.080740.-861029870.imp@bsdimp.com> To: markhobden@gmail.com From: "M. Warner Losh" In-Reply-To: References: <20070718.203153.112852673.imp@bsdimp.com> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Thu, 19 Jul 2007 08:07:34 -0600 (MDT) Cc: freebsd-current@freebsd.org, freebsd-usb@freebsd.org Subject: Re: uhidev(4) update - USB HID driver level for devices with multiple report ids X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Jul 2007 14:10:19 -0000 In message: "Mark Hobden" writes: : On 19/07/07, M. Warner Losh wrote: : > In message: : > "Mark Hobden" writes: : > : I have updated the uhidev(4) patch from NetBSD to apply to today's 7-CURRENT. : > : : > : http://www.terinea.co.uk/~mark/patches/uhidev-7-current-p2.diff : > : > this one seems to be backwards : > : : Sorry Warner, I don't quite get what you mean here. I thought that you'd run the diff backwards. However, I'm wrong.... : Do you mean that the patch is only wanting to apply with patch -R ?? : or does not want to apply in some way? : : or that I have removed the changes made in ums.c version 1.95. : This is the case as the other patch I posted makes them work with : the correct report id. I split up the patches to make it a bit clearer : how the problem is fixed - I am using a WLNOTEBOOK (0x00b9) mouse : right now and they work fine. : : or have I managed remove functionality somewhere else? I haven't reviewed the patch closely, but it is forward and adds a lot... Warner From owner-freebsd-current@FreeBSD.ORG Thu Jul 19 14:51:40 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E7E3A16A402 for ; Thu, 19 Jul 2007 14:51:40 +0000 (UTC) (envelope-from gallatin@cs.duke.edu) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.freebsd.org (Postfix) with ESMTP id AC72213C441 for ; Thu, 19 Jul 2007 14:51:40 +0000 (UTC) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.14.0/8.14.0) with ESMTP id l6JEpeFT022475 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Jul 2007 10:51:40 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.12.9p2/8.12.9/Submit) id l6JEpB8S078416; Thu, 19 Jul 2007 10:51:11 -0400 (EDT) (envelope-from gallatin) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <18079.31350.366410.316438@grasshopper.cs.duke.edu> Date: Thu, 19 Jul 2007 10:51:11 -0400 (EDT) To: =?iso-8859-1?Q?St=E5le?= Kristoffersen In-Reply-To: <20070716233600.GC19282@eschew.pusen.org> References: <20070716190441.GA19282@eschew.pusen.org> <20070716213425.GB19282@eschew.pusen.org> <20070716233600.GC19282@eschew.pusen.org> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Cc: current@freebsd.org Subject: Re: Slow networkperformance in current? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2007 14:51:41 -0000 St=E5le Kristoffersen writes: > On 2007-07-16 at 15:53, Kip Macy wrote: > > Please post the config you are using. >=20 > lrwxr-xr-x 1 root wheel 2B Apr 12 15:42 /etc/malloc.conf -> aj= >=20 > /etc/sysctl.conf: > vfs.vmiodirenable=3D1 > net.inet.tcp.delayed_ack=3D0 > net.inet.ip.forwarding=3D1 > net.inet.tcp.inflight.enable=3D0 >=20 > (I have tried commenting out all those lines, no difference. You definately want to comment out at least net.inet.tcp.delayed_ack=3D= 0 Try temporarily setting net.inet.tcp.sendbuf_auto=3D0 and net.inet.tcp.recvbuf_auto=3D0 and see if that changes anything. I've seen strange issues with IPv6 and the automatic buffer sizing, perhaps you're somehow running into the same thing with IPv4. Drew From owner-freebsd-current@FreeBSD.ORG Thu Jul 19 15:06:33 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 40EC916A406 for ; Thu, 19 Jul 2007 15:06:33 +0000 (UTC) (envelope-from dmw@unete.cl) Received: from mail04.ifxnetworks.com (mail04.ifxnetworks.com [190.61.128.14]) by mx1.freebsd.org (Postfix) with ESMTP id D02BF13C49D for ; Thu, 19 Jul 2007 15:06:32 +0000 (UTC) (envelope-from dmw@unete.cl) Received: (qmail 13172 invoked from network); 19 Jul 2007 15:06:31 -0000 Received: from unknown (HELO webmail.ifxnw.cl) ([190.61.128.24]) (envelope-sender ) by mail04.ifxnetworks.com (qmail-ldap-1.03) with SMTP for ; 19 Jul 2007 15:06:31 -0000 Received: from 64.117.137.69 (proxying for 161.131.179.196) (SquirrelMail authenticated user dmw@unete.cl) by webmail.ifxnw.cl with HTTP; Thu, 19 Jul 2007 11:06:31 -0400 (CLT) Message-ID: <51257.64.117.137.69.1184857591.squirrel@webmail.ifxnw.cl> Date: Thu, 19 Jul 2007 11:06:31 -0400 (CLT) From: "Daniel Molina Wegener" To: freebsd-current@freebsd.org User-Agent: SquirrelMail/1.4.8 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: getting buildworld and buildkernel done X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dmw@unete.cl List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2007 15:06:33 -0000 Hello, How can I determine when can I get buildworld and buildkernel done, I mean that tinderbox failures are notified, but how are notified success builds over -CURRENT? I think that a success build allows source tree updates and and a better chance to make contributions and modifications over the code with a synchronized tree. Regards, -- .O. | Daniel Molina Wegener | C/C++ Developer ..O | dmw [at] unete [dot] cl | FOSS Coding Adict OOO | BSD & Linux User | Standards Rocks! [Exponential Increasing Hatred Towards Windows...] From owner-freebsd-current@FreeBSD.ORG Thu Jul 19 15:22:28 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2267816A400 for ; Thu, 19 Jul 2007 15:22:28 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [210.51.165.229]) by mx1.freebsd.org (Postfix) with ESMTP id D1E8B13C4A5 for ; Thu, 19 Jul 2007 15:22:27 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from localhost (tarsier.geekcn.org [210.51.165.229]) by tarsier.geekcn.org (Postfix) with ESMTP id 08506EB08D1; Thu, 19 Jul 2007 23:22:27 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([210.51.165.229]) by localhost (mail.geekcn.org [210.51.165.229]) (amavisd-new, port 10024) with ESMTP id JDS3XhobSPVG; Thu, 19 Jul 2007 23:22:23 +0800 (CST) Received: from charlie.delphij.net (unknown [221.216.126.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id A7279EB1709; Thu, 19 Jul 2007 23:22:22 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=uOEgHuj2PrCFU40DBJ2JJIeGhacNx/CaiXgP0bs+7gF3AyZdoZYZDPA2sIPF44LNC djuk1P1IeNFzgZMl/Y1bQ== Message-ID: <469F81AE.9080909@delphij.net> Date: Thu, 19 Jul 2007 23:22:22 +0800 From: Xin LI User-Agent: Thunderbird 2.0.0.4 (X11/20070711) MIME-Version: 1.0 To: dmw@unete.cl References: <51257.64.117.137.69.1184857591.squirrel@webmail.ifxnw.cl> In-Reply-To: <51257.64.117.137.69.1184857591.squirrel@webmail.ifxnw.cl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: getting buildworld and buildkernel done X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Jul 2007 15:22:28 -0000 Daniel Molina Wegener wrote: > Hello, > > How can I determine when can I get buildworld and buildkernel > done, I mean that tinderbox failures are notified, but how are > notified success builds over -CURRENT? > > I think that a success build allows source tree updates and > and a better chance to make contributions and modifications over > the code with a synchronized tree. "No news" is the Good news in the Unix tradition... Cheers, From owner-freebsd-current@FreeBSD.ORG Thu Jul 19 15:38:29 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 61A9C16A4E0 for ; Thu, 19 Jul 2007 15:38:29 +0000 (UTC) (envelope-from dmw@unete.cl) Received: from mail03.ifxnetworks.com (mail03.ifxnetworks.com [190.61.128.13]) by mx1.freebsd.org (Postfix) with ESMTP id EF63D13C48E for ; Thu, 19 Jul 2007 15:38:28 +0000 (UTC) (envelope-from dmw@unete.cl) Received: (qmail 805 invoked from network); 19 Jul 2007 15:38:28 -0000 Received: from unknown (HELO webmail.ifxnw.cl) ([190.61.128.23]) (envelope-sender ) by mail03.ifxnetworks.com (qmail-ldap-1.03) with SMTP for ; 19 Jul 2007 15:38:28 -0000 Received: from 64.117.137.69 (proxying for 161.131.179.196) (SquirrelMail authenticated user dmw@unete.cl) by webmail.ifxnw.cl with HTTP; Thu, 19 Jul 2007 11:38:27 -0400 (CLT) Message-ID: <45165.64.117.137.69.1184859507.squirrel@webmail.ifxnw.cl> In-Reply-To: <59810.195.12.22.194.1184859181.squirrel@mail.helenmarks.co.uk> References: <51257.64.117.137.69.1184857591.squirrel@webmail.ifxnw.cl> <59810.195.12.22.194.1184859181.squirrel@mail.helenmarks.co.uk> Date: Thu, 19 Jul 2007 11:38:27 -0400 (CLT) From: "Daniel Molina Wegener" To: "Dominic Marks" User-Agent: SquirrelMail/1.4.8 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: dmw@unete.cl, freebsd-current@freebsd.org Subject: Re: getting buildworld and buildkernel done X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dmw@unete.cl List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2007 15:38:29 -0000 El Jue, 19 de Julio de 2007, 11:33, Dominic Marks escribió: > Daniel Molina Wegener wrote: >> >> Hello, >> >> How can I determine when can I get buildworld and buildkernel >> done, I mean that tinderbox failures are notified, but how are >> notified success builds over -CURRENT? > > Like this? > > http://tinderbox.des.no/ Yes, thanks... > > Dominic > > Regards, -- .O. | Daniel Molina Wegener | C/C++ Developer ..O | dmw [at] unete [dot] cl | FOSS Coding Adict OOO | BSD & Linux User | Standards Rocks! [Exponential Increasing Hatred Towards Windows...] From owner-freebsd-current@FreeBSD.ORG Thu Jul 19 16:36:33 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 586D216A402 for ; Thu, 19 Jul 2007 16:36:33 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from pne-smtpout1-sn1.fre.skanova.net (pne-smtpout1-sn1.fre.skanova.net [81.228.11.98]) by mx1.freebsd.org (Postfix) with ESMTP id 1D9DA13C491 for ; Thu, 19 Jul 2007 16:36:33 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from [192.168.1.5] (217.211.83.81) by pne-smtpout1-sn1.fre.skanova.net (7.2.076.2) id 46758F19006E2BE0 for current@freebsd.org; Thu, 19 Jul 2007 17:27:28 +0200 Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <5EF8F594-035F-4DCA-AF66-EFD7339D4E91@exscape.org> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: current@freebsd.org From: Thomas Backman Date: Thu, 19 Jul 2007 17:27:25 +0200 X-Mailer: Apple Mail (2.752.3) Cc: Subject: ZFS, chflags and installworld X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Jul 2007 16:36:33 -0000 Hi everybody, I successfully moved everything to ZFS a few weeks ago. Everything seems to work, except I can't run installworld. If I understand things correctly, ZFS doesn't support chflags, but I'm guessing the flags stuck when I copied the files from UFS (using tar)? In any case, installworld gives me plenty of errors like "chflags: (filename): Operation not supported", and the files remain unchanged. kern.securelevel is -1 and has always been. chflags -R noschg doesn't work (plenty of "Operation not supported" errors). Any hints? Thanks, Thomas From owner-freebsd-current@FreeBSD.ORG Thu Jul 19 17:36:03 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E275316A405 for ; Thu, 19 Jul 2007 17:36:03 +0000 (UTC) (envelope-from davidch@broadcom.com) Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by mx1.freebsd.org (Postfix) with ESMTP id BC29C13C4AA for ; Thu, 19 Jul 2007 17:36:03 +0000 (UTC) (envelope-from davidch@broadcom.com) Received: from [10.10.64.154] by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.1)); Thu, 19 Jul 2007 10:35:54 -0700 X-Server-Uuid: 20144BB6-FB76-4F11-80B6-E6B2900CA0D7 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id B4ABB2AF; Thu, 19 Jul 2007 10:35:54 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 9FD052AE; Thu, 19 Jul 2007 10:35:54 -0700 (PDT) Received: from mail-irva-12.broadcom.com (mail-irva-12.broadcom.com [10.10.64.146]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id FMG64704; Thu, 19 Jul 2007 10:35:51 -0700 (PDT) Received: from NT-IRVA-0750.brcm.ad.broadcom.com ( nt-irva-0750.brcm.ad.broadcom.com [10.8.194.64]) by mail-irva-12.broadcom.com (Postfix) with ESMTP id 9E36C69CA6; Thu, 19 Jul 2007 10:35:51 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 19 Jul 2007 10:35:50 -0700 Message-ID: <09BFF2FA5EAB4A45B6655E151BBDD9030483F728@NT-IRVA-0750.brcm.ad.broadcom.com> In-Reply-To: <469EEF02.7000804@samsco.org> Thread-Topic: Getting/Forcing Greater than 4KB Buffer Allocations Thread-Index: AcfJwT2Ak+ZetsmzToitT+ZBnuucHAAZdwog References: <09BFF2FA5EAB4A45B6655E151BBDD9030483F161@NT-IRVA-0750.brcm.ad.broadcom.com> <20070718021839.GA37935@cdnetworks.co.kr> <09BFF2FA5EAB4A45B6655E151BBDD9030483F437@NT-IRVA-0750.brcm.ad.broadcom.com> <20070719002218.GA42405@cdnetworks.co.kr> <09BFF2FA5EAB4A45B6655E151BBDD9030483F5D2@NT-IRVA-0750.brcm.ad.broadcom.com> <469EEF02.7000804@samsco.org> From: "David Christensen" To: "Scott Long" X-WSS-ID: 6A817F703AC26681417-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: pyunyh@gmail.com, current@freebsd.org Subject: RE: Getting/Forcing Greater than 4KB Buffer Allocations X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Jul 2007 17:36:04 -0000 > I'm trying to catch up on this thread, but I'm utterly confused as to > what you're looking for. Let's try talking through a few scenarios > here: My goal is simple. I've modified my driver to support up to 8 segments in an mbuf and I want to verify that it works correctly. It's simple to test when every mbuf has the same number of segments, but I want to make sure my code is robust enough to support cases where one mbuf is made of 3 segments while the next is made of 5 segments. The best case would be to get a distribution of sizes from the min to the max (i.e. 1 to 8). I'm not trying to test for performance, only for proper operation under a worst case load. >=20 > 1. Your hardware has slots for 3 SG elements, and all three MUST be > filled without exception. Therefore, you want segments that=20 > are 4k, 4k, > and 1k (or some slight variation of that if the buffer is misaligned). > To do this, set the maxsegs to 3 and the maxsegsize to 4k. This will > ensure that busdma does no coalescing (more on this topic later) and > will always give you 3 segments for 9k of contiguous buffers. If the > actual buffer winds up being <=3D 8k, busdma won't guarantee that = you'll > get 3 segments, and you'll have to fake something up in your=20 > driver. If > the buffer winds up being an fragmented mbuf chain, it also won't > guarantee that you'll get 3 segments either, but that's=20 > already handled > now via m_defrag(). My hardware supports multiples of 255 buffer descriptors (255, 510, 765, etc.). If all mbufs have 1 segment (common for 1500 MTU) then I can handle multiples of 255 mbufs. If all mbufs have 3 segments, (common for 9000 MTU) then I can handle multiples of 85 mbufs. If the mbufs have varying number of segments (anywhere from 1 to 8) then a varying number of mbufs can be buffered. This last case is the most complicated to handle and I want to make sure my code is robust enough to handle it. I've found that reducing the system=20 memory from 8GB to 2GB has allowed me to see both 2 segment and 3 segment mbufs (the former I assume occurs because of coalescing) but I haven't been able to load the system in such a way to cause any other number of segments to occur. >=20 > 2. Your hardware can only handle 4k segments, but is less=20 > restrictive on > the min/max number of segements. The solution is the same as above. No practical limit on the segment size. Anything between 1 byte and=20 9KB is fine. >=20 > 3. Your hardware has slots for 8 SG elements, and all 8 MUST be filled > without exception. There's no easy solution for this, as=20 > it's a fairly > bizarre situation. I'll only discuss it further if you confirm that > it's actually the case here. The number of SG elements can vary anywhere from 1 to 8. If the first SG element has 2 slots then there's no problem with the second SG element having 8 slots, and then the third having 4 slots. The only=20 difficulty comes in keeping the ring full since the number of slots used won't always match the number of slots available. I think I can handle this correctly but it's difficult to test since all of the=20 SG entries have the same number of slots (which also happens to be=20 evenly divisible by the total number of slots available in the ring). >=20 > As for coalescing segments, I'm considering a new busdma back-end that > greatly streamlines loads by eliminating cycle-consuming tasks like > segment coalescing. The original justification for=20 > coalescing was that > DMA engines operated faster with fewer segments. That might still be > true, but the extra host CPU cycles and cache-line misses probably > result in a net loss. I'm also going to axe bounce-buffer=20 > support since > it bloats the I cache. The target for this new back-end is=20 > drivers that > support hardware that don't need these services and that are also > sensitive to the amount of host CPU cycles being consumed, i.e. modern > 1Gb and 10Gb adapters. The question I have is whether this=20 > new back-end > should be accessible directly through yet another bus_dmamap_load_foo > variant that the drivers need to know specifically about, or=20 > indirectly > and automatically via the existing bus_dmamap_load_foo variants. The > tradeoff is further API pollution vs the opportunity for even more > efficiency through no indirect function calls and no cache misses from > accessing the busdma tag. I don't like API pollution since=20 > it makes it > harder to maintain code, but the opportunity for the best performance > possible is also appealing. Others have reported that single, larger segments provide better=20 performance than multiple, smaller segments. (Kip Macy recently forwarded me a patch to test which shows a performance improvement on the cxgb adatper when this is used.) I haven't done enough=20 performance testing on bce to know if this helps overall, hurts, or has no overall difference. One thing I am interested in is finding a way to allocate receive mbufs such that I can split the header into a single buffer and then place the data into one or more page aligned buffers, similar to what a transmit mbuf looks like. Anyway to support that in the current architecture? Dave From owner-freebsd-current@FreeBSD.ORG Thu Jul 19 18:01:01 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8A98F16A400 for ; Thu, 19 Jul 2007 18:01:01 +0000 (UTC) (envelope-from r.c.ladan@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.168]) by mx1.freebsd.org (Postfix) with ESMTP id 1C68813C48D for ; Thu, 19 Jul 2007 18:01:00 +0000 (UTC) (envelope-from r.c.ladan@gmail.com) Received: by ug-out-1314.google.com with SMTP id o4so641792uge for ; Thu, 19 Jul 2007 11:00:59 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; b=FpP9b1In6OX4MBrA4qmH7M0kV7mOdvPq7IJtnWBMyzwxsx9W08yV0CobRcWj4SVhnkN6jQaRLP7RNWpCJrXkZKwsepziMkJhH7S9kjkc9b9qseU0oQT0Sz5nmhY6aFNaNsPxVlDfR11zAikLH2Voi7MLmSdHIroXug/pEEoyquo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; b=OenPKAPz2yCHmmUeUoZ3HK68OM3z3M2ScBnaNFoVXQaf1i+TWTwpeF/m1IedjmPqaN2IKgPAzWPa1pD5Wm+oyQwPFOb2Ek/KYOvqAPhbu0gCJ57DIfYB3KxqZ6F/bW6JqK8pkSuIV+9ckjHRdvSy+bJ26Q681YAx1f97wshDGFs= Received: by 10.86.99.9 with SMTP id w9mr2104932fgb.1184868059648; Thu, 19 Jul 2007 11:00:59 -0700 (PDT) Received: from 195-241-221-201.dsl.ip.tiscali.nl ( [195.241.221.201]) by mx.google.com with ESMTPS id f6sm11064320nfh.2007.07.19.11.00.55 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 19 Jul 2007 11:00:55 -0700 (PDT) Message-ID: <469FA6C2.4090202@gmail.com> Date: Thu, 19 Jul 2007 20:00:34 +0200 From: Rene Ladan User-Agent: Thunderbird 2.0.0.4 (X11/20070616) MIME-Version: 1.0 To: Jeff Roberson References: <20070716233030.D92541@10.0.0.1> <469E83F8.3090103@gmail.com> <20070718142649.Y561@10.0.0.1> <469E897B.7080100@gmail.com> <20070718150613.W561@10.0.0.1> <469E9BDB.7020500@gmail.com> <20070718161652.G561@10.0.0.1> In-Reply-To: <20070718161652.G561@10.0.0.1> X-Enigmail-Version: 0.95.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: ULE/SCHED_SMP diff for 7.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2007 18:01:01 -0000 Jeff Roberson schreef: > On Thu, 19 Jul 2007, Rene Ladan wrote: > >> Jeff Roberson schreef: >>> >>> On Wed, 18 Jul 2007, Rene Ladan wrote: >>> >>>> Jeff Roberson schreef: >>>>> >>>>> On Wed, 18 Jul 2007, Rene Ladan wrote: >>>>> >>>>>> Jeff Roberson schreef: >>>>>>> http://people.freebsd.org/~jeff/ule.diff >>>>>>> >>>>>>> This patch is scheduled for inclusion in 7.0. I would like >>>>>>> anyone who >>>>>>> cares to run it to validate that it does not create any stability or >>>>>>> performance regression over the existing ULE. This patch >>>>>>> replaces ULE >>>>>>> with SCHED_SMP, which will now no longer exist as a seperate fork of >>>>>>> ULE. >>>>>> [..] >>>>>> >> > > Thank you. > > This is definitely a KSE/ULE problem. Can you try > http://people.freebsd.org/~jeff/sched_ule.c? I have made some changes > that may fix this. cvsuped today at 17:23 UTC and replaced sched_ule.c afterwards. The almost-instant panics are gone. Also, the oddity I reported about ULE/BOINC on this list earlier has been fixed by the new sched_ule.c, I've noticed however that the WCPU field in top sometimes exceeds 100% (this wasn't the case with sched_4bsd). Thanks, Rene -- GPG fingerprint = E738 5471 D185 7013 0EE0 4FC8 3C1D 6F83 12E1 84F6 (subkeys.pgp.net) "It won't fit on the line." -- me, 2001 From owner-freebsd-current@FreeBSD.ORG Thu Jul 19 18:08:27 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5774916A408 for ; Thu, 19 Jul 2007 18:08:27 +0000 (UTC) (envelope-from kometen@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.227]) by mx1.freebsd.org (Postfix) with ESMTP id 09A9F13C4B8 for ; Thu, 19 Jul 2007 18:08:26 +0000 (UTC) (envelope-from kometen@gmail.com) Received: by wx-out-0506.google.com with SMTP id i29so515133wxd for ; Thu, 19 Jul 2007 11:08:26 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=rP4Lu53UzSCM3bTe1478pXeVuaHBcRs7wqQpuMlpMM8tszjOsHmQ9vxAM0FQ3hCl690gD0txfwmQGjT1zQIwuHnED7pkOaQcvmzbspOV0uR61kuSjfqS46uQ4bngoN2GD9ZERYl+BQzHHCAq1c4Cf7AxS99fpmmEB7haqYw4X+A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=brqVqrS3oVGLW+pGFhDcKZOqMAdp4mP8Fo43vwW5Kycqh+WLJgwMmI8shHV0MCDckgSAEh8k6UfEeU4koDQQ8mD5rXy6cg0dYo/BVjU1Zsgv9uUsQ122Mr1nk8U8Ex7BPbbDMiig7QTYmhaLbjkmEs5PNACVZhyMmX0BKisGu70= Received: by 10.70.133.10 with SMTP id g10mr1293822wxd.1184868506548; Thu, 19 Jul 2007 11:08:26 -0700 (PDT) Received: by 10.70.41.4 with HTTP; Thu, 19 Jul 2007 11:08:26 -0700 (PDT) Message-ID: Date: Thu, 19 Jul 2007 20:08:26 +0200 From: "Claus Guttesen" To: "Rene Ladan" In-Reply-To: <469FA6C2.4090202@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070716233030.D92541@10.0.0.1> <469E83F8.3090103@gmail.com> <20070718142649.Y561@10.0.0.1> <469E897B.7080100@gmail.com> <20070718150613.W561@10.0.0.1> <469E9BDB.7020500@gmail.com> <20070718161652.G561@10.0.0.1> <469FA6C2.4090202@gmail.com> Cc: Jeff Roberson , current@freebsd.org Subject: Re: ULE/SCHED_SMP diff for 7.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2007 18:08:27 -0000 > > This is definitely a KSE/ULE problem. Can you try > > http://people.freebsd.org/~jeff/sched_ule.c? I have made some changes > > that may fix this. > > cvsuped today at 17:23 UTC and replaced sched_ule.c afterwards. The almost-instant > panics are gone. Also, the oddity I reported about ULE/BOINC on this list earlier > has been fixed by the new sched_ule.c, I've noticed however that the WCPU field in > top sometimes exceeds 100% (this wasn't the case with sched_4bsd). Aren't they the same? Current as of 19:00 UTC +1 has ver. 1.200 which is the same as the link above. -- regards Claus When lenity and cruelty play for a kingdom, the gentlest gamester is the soonest winner. Shakespeare From owner-freebsd-current@FreeBSD.ORG Thu Jul 19 19:16:52 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4079616A400 for ; Thu, 19 Jul 2007 19:16:52 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from pne-smtpout1-sn2.hy.skanova.net (pne-smtpout1-sn2.hy.skanova.net [81.228.8.83]) by mx1.freebsd.org (Postfix) with ESMTP id 08D8F13C4B2 for ; Thu, 19 Jul 2007 19:16:52 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from [192.168.1.5] (217.211.83.81) by pne-smtpout1-sn2.hy.skanova.net (7.2.075) id 46971B420014C9E4; Thu, 19 Jul 2007 20:07:43 +0200 In-Reply-To: <20070719164215.GA12593@fyrou.net> References: <5EF8F594-035F-4DCA-AF66-EFD7339D4E91@exscape.org> <20070719164215.GA12593@fyrou.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <760CD82D-1548-41E3-8640-E636F2B231E7@exscape.org> Content-Transfer-Encoding: quoted-printable From: Thomas Backman Date: Thu, 19 Jul 2007 20:07:41 +0200 To: Francois Ranchin X-Mailer: Apple Mail (2.752.3) Cc: current@freebsd.org Subject: Re: ZFS, chflags and installworld X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Jul 2007 19:16:52 -0000 Hi again, I'm not so sure that it's useable. For instance (_after_ running installworld): # pwd /usr/obj/usr/src/bin/cat # diff cat /bin/cat Files cat and /bin/cat differ # cp cat /bin # diff cat /bin/cat # Or, in english, the files doesn't seem to be installed by installworld. What I don't understand though, is why installworld receives "Operation not supported" errors while my simple cp (or install(1)) works every time. I have very limited experience using flags, though. Are flags retained when files are copied to a ZFS filesystem, even though ZFS doesn't actually support them? I have no idea how or where flags are actually "stored"... Or if there's a way to remove them. Regards, Thomas On Jul 19, 2007, at 6:42 PM, Francois Ranchin wrote: > According to Thomas Backman : >> In any case, installworld gives me plenty of errors like "chflags: >> (filename): >> Operation not supported", and the files remain unchanged. >> kern.securelevel is -1 and has always been. >> chflags -R noschg doesn't work (plenty of "Operation not supported" >> errors). >> >> Any hints? > > ZFS doesn't support chflags. Don't worry. The installed system is > usefull. > > Regards, > > --=20 > Fran=E7ois Ranchin -+- fyr@fyrou.net From owner-freebsd-current@FreeBSD.ORG Thu Jul 19 19:51:10 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9DB8616A400 for ; Thu, 19 Jul 2007 19:51:10 +0000 (UTC) (envelope-from stevenschlansker@berkeley.edu) Received: from smtp-out1.berkeley.edu (smtp-out1.Berkeley.EDU [128.32.61.106]) by mx1.freebsd.org (Postfix) with ESMTP id 8745F13C48E for ; Thu, 19 Jul 2007 19:51:10 +0000 (UTC) (envelope-from stevenschlansker@berkeley.edu) Received: from adsl-75-41-56-211.dsl.pltn13.sbcglobal.net ([75.41.56.211] helo=[192.168.42.3]) by fe5.calmail with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (auth plain:stevenschlansker@berkeley.edu) (envelope-from ) id 1IBc1l-0003W5-In for freebsd-current@freebsd.org; Thu, 19 Jul 2007 12:51:10 -0700 Message-ID: <469FC0AB.8040706@berkeley.edu> Date: Thu, 19 Jul 2007 12:51:07 -0700 From: Steven Schlansker User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 CC: freebsd-current@freebsd.org References: <2978EDA9-D393-434C-B734-2DE188631761@berkeley.edu> <469C3900.5020703@berkeley.edu> <1c5c32890707162045u9d56cfeq2f7430ddddd55418@mail.gmail.com> <469C48F2.7000302@berkeley.edu> <88afd9200707170129h4ab33176pc8423a4c2f2d6124@mail.gmail.com> In-Reply-To: <88afd9200707170129h4ab33176pc8423a4c2f2d6124@mail.gmail.com> X-Enigmail-Version: 0.94.2.0 OpenPGP: id=40BFF7A7; url=subkeys.pgp.net Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: Strange performance characteristics with ZFS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Jul 2007 19:51:10 -0000 >> > > I've had this same problem. I did notice that I was getting a *TON* of > error messages on the console when access ZFS from a remote Linux > client over NFS. Eventually, it slowed to a crawl and died. I'm in the > process of rebuilding my system so I can't tell you details of the > messages, but you may want to tail -f /var/log/messages. > > Larry. Nothing shows up in the messages. From owner-freebsd-current@FreeBSD.ORG Thu Jul 19 19:51:57 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A3D4716A404 for ; Thu, 19 Jul 2007 19:51:57 +0000 (UTC) (envelope-from stevenschlansker@berkeley.edu) Received: from smtp-out1.berkeley.edu (smtp-out1.Berkeley.EDU [128.32.61.106]) by mx1.freebsd.org (Postfix) with ESMTP id 8DB8B13C4B5 for ; Thu, 19 Jul 2007 19:51:57 +0000 (UTC) (envelope-from stevenschlansker@berkeley.edu) Received: from adsl-75-41-56-211.dsl.pltn13.sbcglobal.net ([75.41.56.211] helo=[192.168.42.3]) by fe6.calmail with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (auth plain:stevenschlansker@berkeley.edu) (envelope-from ) id 1IBc2X-0003AG-K4 for freebsd-current@freebsd.org; Thu, 19 Jul 2007 12:51:57 -0700 Message-ID: <469FC0DB.3040105@berkeley.edu> Date: Thu, 19 Jul 2007 12:51:55 -0700 From: Steven Schlansker User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <2978EDA9-D393-434C-B734-2DE188631761@berkeley.edu> <469C3900.5020703@berkeley.edu> <1c5c32890707162045u9d56cfeq2f7430ddddd55418@mail.gmail.com> <469C48F2.7000302@berkeley.edu> In-Reply-To: X-Enigmail-Version: 0.94.2.0 OpenPGP: id=40BFF7A7; url=subkeys.pgp.net Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: Strange performance characteristics with ZFS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Jul 2007 19:51:57 -0000 Claus Guttesen wrote: >> Aha. It corrupted data. Now I have to start the copy over again :/ >> >> This is not good! Anything else I can try? (Hopefully without making >> the process fail :-p ) > > I've only copied data between freebsd using nfs (and zfs on the > server) which worked so apparently server and client introduces some > mismacth. Have you tried both tcp and udp? Both are about the same. A recent world rebuild on the BSD machine and an update of the Linux machine improved the situation a lot, although it's still not where I like it. Detail forthcoming in the reply to the next email :) From owner-freebsd-current@FreeBSD.ORG Thu Jul 19 19:54:00 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C459116A403 for ; Thu, 19 Jul 2007 19:54:00 +0000 (UTC) (envelope-from stevenschlansker@berkeley.edu) Received: from smtp-out1.berkeley.edu (smtp-out1.Berkeley.EDU [128.32.61.106]) by mx1.freebsd.org (Postfix) with ESMTP id 94EA313C4A3 for ; Thu, 19 Jul 2007 19:54:00 +0000 (UTC) (envelope-from stevenschlansker@berkeley.edu) Received: from adsl-75-41-56-211.dsl.pltn13.sbcglobal.net ([75.41.56.211] helo=[192.168.42.3]) by fe4.calmail with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (auth plain:stevenschlansker@berkeley.edu) (envelope-from ) id 1IBc4W-0006tX-Cu for freebsd-current@freebsd.org; Thu, 19 Jul 2007 12:54:00 -0700 Message-ID: <469FC153.4010903@berkeley.edu> Date: Thu, 19 Jul 2007 12:53:55 -0700 From: Steven Schlansker User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 CC: freebsd-current@freebsd.org References: <2978EDA9-D393-434C-B734-2DE188631761@berkeley.edu> <469C3900.5020703@berkeley.edu> <1c5c32890707162045u9d56cfeq2f7430ddddd55418@mail.gmail.com> <469C48F2.7000302@berkeley.edu> <1c5c32890707170312r71f3735at958325a08db0f1c3@mail.gmail.com> In-Reply-To: <1c5c32890707170312r71f3735at958325a08db0f1c3@mail.gmail.com> X-Enigmail-Version: 0.94.2.0 OpenPGP: id=40BFF7A7; url=subkeys.pgp.net Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: Strange performance characteristics with ZFS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Jul 2007 19:54:00 -0000 Brian Donnell wrote: > That was my fault, I misread what you had said your configuration was. > The problem I ran into was the same as you're seeing with the system > waiting on ZFS causing the NFS client to hang and everything becoming > unresponsive. The ls script should be running on the ZFS machine and > executing ls on the ZFS directory. If you have a smaller file to try > with first I'd recommend it. 30GB of corrupt data is just pain. To be > honest, I gave up on NFS with ZFS and started using Samba for everything > after compiling samba3 without a couple functions (check the ZFS vs > Samba debugging results thread from earlier this month) as it actually > maxes out a 100Mbit network link for the transfer. That's something I > could never get NFS with ZFS to come close to doing. > > Just to be sure, since you're using nfsd, that means you have the > sharenfs option of the zfs pool turned off? > > -- Brian > > No, I have it set up like this: [steven@universe ~]$ sudo zfs get sharenfs NAME PROPERTY VALUE SOURCE universe sharenfs -mapall=steven local universe/backup sharenfs -mapall=steven inherited from universe universe/backup/engineer sharenfs -mapall=steven inherited from universe universe/backup/zoo sharenfs -mapall=steven inherited from universe universe/data sharenfs -mapall=steven inherited from universe universe/incoming sharenfs -mapall=steven inherited from universe universe/kabamba sharenfs -mapall=steven inherited from universe universe/media sharenfs -mapall=steven inherited from universe universe/music sharenfs -mapall=steven inherited from universe universe/platypus sharenfs -maproot=root local So here's the score: Write to ZFS on local machine (dd if=/dev/zero of=file) = 36.2 MB/s This still seems a bit slow, but it's not bad so I'll let it slide :-p dd/netcat across network = 24.8 MB/s Also seems a bit slow, considering it's gigabit. Write to ZFS over nfs (dd again) = 16MB/s It does the whole ping-ponging speed (goes at like 25MB/s for a little bit, drops to 0, back to 25, etc) Any more ideas? Thanks! Steven From owner-freebsd-current@FreeBSD.ORG Thu Jul 19 22:34:24 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D1E2016A404 for ; Thu, 19 Jul 2007 22:34:24 +0000 (UTC) (envelope-from SRS1=050c7b3f6254414c5f5c69b958cc172620b9db89=es.net==050c7b3f6254414c5f5c69b958cc172620b9db89=401=es.net=oberman@es.net) Received: from postal1.es.net (postal1.es.net [IPv6:2001:400:14:3::6]) by mx1.freebsd.org (Postfix) with ESMTP id B1DE613C442 for ; Thu, 19 Jul 2007 22:34:23 +0000 (UTC) (envelope-from SRS1=050c7b3f6254414c5f5c69b958cc172620b9db89=es.net==050c7b3f6254414c5f5c69b958cc172620b9db89=401=es.net=oberman@es.net) Received: from postal1.es.net (postal4.es.net [198.124.252.66]) by postal1.es.net (Postal Node 1) with ESMTP (SSL) id YAJ70444 for Received: from ptavv.es.net (ptavv.es.net [198.128.4.29]) by postal4.es.net (Postal Node 4) with ESMTP (SSL) id YAJ89040; Thu, 19 Jul 2007 12:16:40 -0700 Received: from ptavv.es.net (ptavv.es.net [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id B8A5845045; Thu, 19 Jul 2007 12:16:39 -0700 (PDT) X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Sam Leffler In-Reply-To: Your message of "Wed, 18 Jul 2007 20:22:25 PDT." <469ED8F1.2070409@errno.com> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_1184872599_55998P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Thu, 19 Jul 2007 12:16:39 -0700 From: "Kevin Oberman" Message-Id: <20070719191639.B8A5845045@ptavv.es.net> Cc: current@freebsd.org Subject: Re: Problems connecting to public WiFi with latest 80211 code X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Jul 2007 22:34:25 -0000 --==_Exmh_1184872599_55998P Content-Type: multipart/mixed ; boundary="==_Exmh_1184872580_559980" This is a multipart MIME message. --==_Exmh_1184872580_559980 Content-Type: text/plain; charset=us-ascii > Date: Wed, 18 Jul 2007 20:22:25 -0700 > From: Sam Leffler > > Kevin Oberman wrote: > > I had not seen this problem because I do not use the wpa_supplicant to > > connect to open networks when at home, but I am on travel this week and > > it has been a real pain. > > > > System is current as of this afternoon and is running on a ThinkPad T43 > > with an Atheros 5212 mini-PCI card. > > mac+phy revs for card are always important; dmesg|grep ath > > > > > When the system comes up, the wpa_supplicant starts, but the system > > never scans except with 'authmode WPA1+WPA2/802.11i privacy ON' and > > never tries to associate with an open AP even though I have an entry in > > wpa_supplicant.conf for that network. I have to issue a 'ifconfig > > wepmode off' to get it to associate. > > I don't see a log from wpa_supplicant or console debug msgs as obtained > with wlandebug. > > > > > Even then, it still won't always associate until I ifconfig the > > interface down and up. Once I do this, it seems to associate rather > > quickly. > > > > I suspect that the problem reported on mobile by Matthias Apitz and jhb > > may be a part of the problem, but I think the inability to get to > > authmode OPEN is different. > > > > I use the supplicant at home and it works fine, but that is NOT an open > > network, so I don't need the interface to run in OPEN mode. > > > > Any idea what is going on and if it can be fixed or worked around? > > I can't help w/o the usual info: what os, card info (mac+phy), and how > to reproduce (e.g. wpa_supplicant.conf and cmd line). Sorry, this was a really bad report. Here is the dmesg part: ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) ath0: mem 0xb4000000-0xb400ffff irq 11 at device 2.0 on pci11 ath0: [ITHREAD] ath0: using obsoleted if_watchdog interface ath0: Ethernet address: 00:14:a4:60:f2:e3 ath0: mac 5.9 phy 4.3 radio 3.6 Do the following: Boot up a current kernel WITHOUT 'device ath' kldload if_ath Interface continues to report 'authmode WPA1+WPA2/802.11i privacy ON' and never associates. /etc/rc.d/wpa_supplicant restart ath0 This fixes it all. I didn't realize that restarting wpa_supplicant corrected the problem when I sent the initial message. Because of the way this is working, I failed to get anything from 'wpa_supplicant -d' as any attempt to re-start the supplicant cause things to work. I did run wlandebug and I am attaching the output. The supplicant was restarted at the point where the DHCP client exited. I see the same behavior when I 'boot -s', 'kldload if_ath' and 'exit'. Due to an IRQ issue that I have not had time to try to track down, I can't load it from the loader and I don't want it in my kernel fro a variety of reasons. I might also mention that I am also seeing frequent drops in associations that are working fine, but this has been reported by others and so this is just a "me, too". But is annoying. I lost it twice entering this message. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 --==_Exmh_1184872580_559980 Content-Type: text/plain ; name="ath.wlandebug"; charset=us-ascii Content-Description: ath.wlandebug Content-Disposition: attachment; filename="ath.wlandebug" Jul 19 08:00:00 slan newsyslog[1981]: logfile turned over due to size>100K Jul 19 08:00:49 slan kernel: ath0: link state changed to DOWN Jul 19 08:02:10 slan dhclient[1637]: connection closed Jul 19 08:02:10 slan dhclient[1637]: exiting. Jul 19 08:02:35 slan kernel: ath0: link state changed to UP Jul 19 08:02:35 slan dhclient: New IP Address (ath0): 131.225.96.86 Jul 19 08:02:35 slan dhclient: New Subnet Mask (ath0): 255.255.254.0 Jul 19 08:02:35 slan dhclient: New Broadcast Address (ath0): 131.225.97.255 Jul 19 08:02:35 slan dhclient: New Routers (ath0): 131.225.97.200 Jul 19 08:17:55 slan kernel: ath0: link state changed to DOWN Jul 19 08:18:27 slan dhclient[2083]: connection closed Jul 19 08:18:27 slan dhclient[2083]: exiting. Jul 19 08:18:52 slan kernel: ath0: link state changed to UP Jul 19 08:18:52 slan dhclient: New IP Address (ath0): 131.225.96.86 Jul 19 08:18:52 slan dhclient: New Subnet Mask (ath0): 255.255.254.0 Jul 19 08:18:52 slan dhclient: New Broadcast Address (ath0): 131.225.97.255 Jul 19 08:18:52 slan dhclient: New Routers (ath0): 131.225.97.200 Jul 19 08:28:55 slan seahorse-agent[1104]: left gtk_main Jul 19 08:28:55 slan gconfd (oberman-1012): Listener ID 1879048293 doesn't exist Jul 19 08:28:55 slan gconfd (oberman-1012): Listener ID 1895825510 doesn't exist Jul 19 08:29:03 slan kernel: ath0: link state changed to DOWN Jul 19 08:29:21 slan kernel: ath0: link state changed to UP Jul 19 08:29:27 slan dhclient: New IP Address (ath0): 131.225.96.86 Jul 19 08:29:27 slan dhclient: New Subnet Mask (ath0): 255.255.254.0 Jul 19 08:29:27 slan dhclient: New Broadcast Address (ath0): 131.225.97.255 Jul 19 08:29:27 slan dhclient: New Routers (ath0): 131.225.97.200 Jul 19 08:30:17 slan shutdown: reboot by oberman: Jul 19 08:30:19 slan syslogd: exiting on signal 15 Jul 19 08:31:32 slan syslogd: kernel boot file is /boot/kernel/kernel Jul 19 08:31:32 slan kernel: Copyright (c) 1992-2007 The FreeBSD Project. Jul 19 08:31:32 slan kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 Jul 19 08:31:32 slan kernel: The Regents of the University of California. All rights reserved. Jul 19 08:31:32 slan kernel: FreeBSD is a registered trademark of The FreeBSD Foundation. Jul 19 08:31:32 slan kernel: FreeBSD 7.0-CURRENT #0: Wed Jul 18 12:15:54 PDT 2007 Jul 19 08:31:32 slan kernel: root@slan.es.net:/usr/obj/usr/src/sys/IBM-T43 Jul 19 08:31:32 slan kernel: Timecounter "i8254" frequency 1193182 Hz quality 0 Jul 19 08:31:32 slan kernel: CPU: Intel(R) Pentium(R) M processor 2.00GHz (1995.01-MHz 686-class CPU) Jul 19 08:31:32 slan kernel: Origin = "GenuineIntel" Id = 0x6d8 Stepping = 8 Jul 19 08:31:32 slan kernel: Features=0xafe9fbff Jul 19 08:31:32 slan kernel: Features2=0x180 Jul 19 08:31:32 slan kernel: AMD Features=0x100000 Jul 19 08:31:32 slan kernel: real memory = 1072496640 (1022 MB) Jul 19 08:31:32 slan kernel: avail memory = 1039753216 (991 MB) Jul 19 08:31:32 slan kernel: kbd1 at kbdmux0 Jul 19 08:31:32 slan kernel: ACPI Warning (tbfadt-0505): Optional field "Gpe1Block" has zero address or length: 0 102C/0 [20070320] Jul 19 08:31:32 slan kernel: cryptosoft0: on motherboard Jul 19 08:31:32 slan kernel: acpi0: on motherboard Jul 19 08:31:32 slan kernel: acpi0: [ITHREAD] Jul 19 08:31:32 slan kernel: acpi_ec0: port 0x62,0x66 on acpi0 Jul 19 08:31:32 slan kernel: acpi0: Power Button (fixed) Jul 19 08:31:32 slan kernel: acpi0: reservation of 0, a0000 (3) failed Jul 19 08:31:32 slan kernel: acpi0: reservation of 100000, 3ff00000 (3) failed Jul 19 08:31:32 slan kernel: Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 Jul 19 08:31:32 slan kernel: acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 Jul 19 08:31:32 slan kernel: cpu0: on acpi0 Jul 19 08:31:32 slan kernel: acpi_perf0: on cpu0 Jul 19 08:31:32 slan kernel: acpi_throttle0: on cpu0 Jul 19 08:31:32 slan kernel: acpi_lid0: on acpi0 Jul 19 08:31:32 slan kernel: acpi_button0: on acpi0 Jul 19 08:31:32 slan kernel: pcib0: port 0xcf8-0xcff on acpi0 Jul 19 08:31:32 slan kernel: pci0: on pcib0 Jul 19 08:31:32 slan kernel: pcib1: irq 11 at device 1.0 on pci0 Jul 19 08:31:32 slan kernel: pci1: on pcib1 Jul 19 08:31:32 slan kernel: vgapci0: port 0x3000-0x30ff mem 0xc0000000-0xc7ffffff,0xb0100000-0xb010ffff irq 11 at device 0.0 on pci1 Jul 19 08:31:32 slan kernel: acpi_video0: on vgapci0 Jul 19 08:31:32 slan kernel: pcib2: irq 11 at device 28.0 on pci0 Jul 19 08:31:32 slan kernel: pci2: on pcib2 Jul 19 08:31:32 slan kernel: pci2:0:0: bad VPD cksum, remain 14 Jul 19 08:31:32 slan kernel: bge0: mem 0xb0200000-0xb020ffff irq 11 at device 0.0 on pci2 Jul 19 08:31:32 slan kernel: miibus0: on bge0 Jul 19 08:31:32 slan kernel: brgphy0: PHY 1 on miibus0 Jul 19 08:31:32 slan kernel: brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto Jul 19 08:31:32 slan kernel: bge0: Ethernet address: 00:01:6c:e9:8f:51 Jul 19 08:31:32 slan kernel: bge0: [ITHREAD] Jul 19 08:31:32 slan kernel: pcib3: irq 11 at device 28.2 on pci0 Jul 19 08:31:32 slan kernel: pci3: on pcib3 Jul 19 08:31:32 slan kernel: pci0: at device 29.0 (no driver attached) Jul 19 08:31:32 slan kernel: pci0: at device 29.1 (no driver attached) Jul 19 08:31:32 slan kernel: pci0: at device 29.2 (no driver attached) Jul 19 08:31:32 slan kernel: pci0: at device 29.3 (no driver attached) Jul 19 08:31:32 slan kernel: pci0: at device 29.7 (no driver attached) Jul 19 08:31:32 slan kernel: pcib4: at device 30.0 on pci0 Jul 19 08:31:32 slan kernel: pci11: on pcib4 Jul 19 08:31:32 slan kernel: cbb0: mem 0xb4010000-0xb4010fff irq 11 at device 0.0 on pci11 Jul 19 08:31:32 slan kernel: cardbus0: on cbb0 Jul 19 08:31:32 slan kernel: pccard0: <16-bit PCCard bus> on cbb0 Jul 19 08:31:32 slan kernel: cbb0: [ITHREAD] Jul 19 08:31:32 slan kernel: pci11: at device 2.0 (no driver attached) Jul 19 08:31:32 slan kernel: pcm0: port 0x1c00-0x1cff,0x1880-0x18bf mem 0xb0000800-0xb00009ff,0xb0000400-0xb00004ff irq 11 at device 30.2 on pci0 Jul 19 08:31:32 slan kernel: pcm0: [ITHREAD] Jul 19 08:31:32 slan kernel: pcm0: Jul 19 08:31:32 slan kernel: pci0: at device 30.3 (no driver attached) Jul 19 08:31:32 slan kernel: isab0: at device 31.0 on pci0 Jul 19 08:31:32 slan kernel: isa0: on isab0 Jul 19 08:31:32 slan kernel: atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x18c0-0x18cf at device 31.2 on pci0 Jul 19 08:31:32 slan kernel: ata0: on atapci0 Jul 19 08:31:32 slan kernel: ata0: [ITHREAD] Jul 19 08:31:32 slan kernel: ata1: on atapci0 Jul 19 08:31:32 slan kernel: ata1: [ITHREAD] Jul 19 08:31:32 slan kernel: ichsmb0: port 0x18e0-0x18ff irq 11 at device 31.3 on pci0 Jul 19 08:31:32 slan kernel: ichsmb0: [GIANT-LOCKED] Jul 19 08:31:32 slan kernel: ichsmb0: [ITHREAD] Jul 19 08:31:32 slan kernel: smbus0: on ichsmb0 Jul 19 08:31:32 slan kernel: smb0: on smbus0 Jul 19 08:31:32 slan kernel: acpi_tz0: on acpi0 Jul 19 08:31:32 slan kernel: atkbdc0: port 0x60,0x64 irq 1 on acpi0 Jul 19 08:31:32 slan kernel: atkbd0: irq 1 on atkbdc0 Jul 19 08:31:32 slan kernel: kbd0 at atkbd0 Jul 19 08:31:32 slan kernel: atkbd0: [GIANT-LOCKED] Jul 19 08:31:32 slan kernel: atkbd0: [ITHREAD] Jul 19 08:31:32 slan kernel: psm0: flags 0x2000 irq 12 on atkbdc0 Jul 19 08:31:32 slan kernel: psm0: [GIANT-LOCKED] Jul 19 08:31:32 slan kernel: psm0: [ITHREAD] Jul 19 08:31:32 slan kernel: psm0: model Generic PS/2 mouse, device ID 0 Jul 19 08:31:32 slan kernel: fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 Jul 19 08:31:32 slan kernel: fdc0: [FILTER] Jul 19 08:31:32 slan kernel: sio0: configured irq 4 not in bitmap of probed irqs 0 Jul 19 08:31:32 slan kernel: sio0: port may not be enabled Jul 19 08:31:32 slan kernel: sio0: configured irq 4 not in bitmap of probed irqs 0 Jul 19 08:31:32 slan kernel: sio0: port may not be enabled Jul 19 08:31:32 slan kernel: sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 Jul 19 08:31:32 slan kernel: sio0: type 8250 or not responding Jul 19 08:31:32 slan kernel: sio0: [FILTER] Jul 19 08:31:32 slan kernel: sio1: configured irq 3 not in bitmap of probed irqs 0 Jul 19 08:31:32 slan kernel: sio1: port may not be enabled Jul 19 08:31:32 slan kernel: battery0: on acpi0 Jul 19 08:31:32 slan kernel: acpi_acad0: on acpi0 Jul 19 08:31:32 slan kernel: acpi_ibm0: on acpi0 Jul 19 08:31:32 slan kernel: sio1: configured irq 3 not in bitmap of probed irqs 0 Jul 19 08:31:32 slan kernel: sio1: port may not be enabled Jul 19 08:31:32 slan kernel: pmtimer0 on isa0 Jul 19 08:31:32 slan kernel: orm0: at iomem 0xc0000-0xcffff,0xd1800-0xd27ff,0xdc000-0xdffff,0xe0000-0xeffff pnpid ORM0000 on isa0 Jul 19 08:31:32 slan kernel: sc0: at flags 0x100 on isa0 Jul 19 08:31:32 slan kernel: sc0: VGA <16 virtual consoles, flags=0x300> Jul 19 08:31:32 slan kernel: vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Jul 19 08:31:32 slan kernel: sio1: configured irq 3 not in bitmap of probed irqs 0 Jul 19 08:31:32 slan kernel: sio1: port may not be enabled Jul 19 08:31:32 slan kernel: Timecounter "TSC" frequency 1995010848 Hz quality 800 Jul 19 08:31:32 slan kernel: Timecounters tick every 1.000 msec Jul 19 08:31:32 slan kernel: ipfw2 (+ipv6) initialized, divert loadable, rule-based forwarding disabled, default to accept, logging limited to 100 packets/entry by default Jul 19 08:31:32 slan kernel: ad0: 76319MB at ata0-master UDMA100 Jul 19 08:31:32 slan kernel: ad2: 76319MB at ata1-master UDMA100 Jul 19 08:31:32 slan kernel: GEOM_LABEL: Label for provider ad0s1 is ntfs/SLAN_WIN. Jul 19 08:31:32 slan kernel: GEOM_LABEL: Label for provider ad0s2 is msdosfs/SERVICEV001. Jul 19 08:31:32 slan kernel: GEOM_LABEL: Label for provider ad2s1 is msdosfs/MY MUSIC. Jul 19 08:31:32 slan kernel: Trying to mount root from ufs:/dev/ad0s3a Jul 19 08:31:32 slan root: /etc/rc: WARNING: Dump directory does not exist. Savecore not run. Jul 19 08:31:32 slan lpd[649]: lpd startup: logging=0 net-secure Jul 19 08:31:32 slan lpd[652]: unable to get official name for local machine slan.es.net: hostname nor servname provided, or not known Jul 19 08:31:32 slan ntpd[664]: ntpd 4.2.0-a Tue Jul 17 16:25:43 PDT 2007 (1) Jul 19 08:31:33 slan ntpd[664]: sendto(134.55.10.67): Network is unreachable Jul 19 08:31:34 slan ntpd[664]: sendto(198.128.2.10): Network is unreachable Jul 19 08:31:35 slan ntpd[664]: sendto(198.124.252.90): Network is unreachable Jul 19 08:31:35 slan ntpd[664]: sendto(134.55.10.67): Network is unreachable Jul 19 08:31:36 slan ntpd[664]: sendto(198.128.2.10): Network is unreachable Jul 19 08:31:36 slan ntpd[664]: sendto(134.55.210.42): Network is unreachable Jul 19 08:31:37 slan ntpd[664]: sendto(198.124.252.90): Network is unreachable Jul 19 08:31:37 slan ntpd[664]: sendto(198.129.252.38): Network is unreachable Jul 19 08:31:37 slan ntpd[664]: sendto(134.55.10.67): Network is unreachable Jul 19 08:31:38 slan ntpd[664]: sendto(198.128.2.10): Network is unreachable Jul 19 08:31:38 slan ntpd[664]: sendto(134.55.210.42): Network is unreachable Jul 19 08:31:39 slan ntpd[664]: sendto(198.124.252.90): Network is unreachable Jul 19 08:31:39 slan ntpd[664]: sendto(198.129.252.38): Network is unreachable Jul 19 08:31:39 slan ntpd[664]: sendto(134.55.10.67): Network is unreachable Jul 19 08:31:40 slan ntpd[664]: sendto(198.128.2.10): Network is unreachable Jul 19 08:31:40 slan ntpd[664]: sendto(134.55.210.42): Network is unreachable Jul 19 08:31:41 slan ntpd[664]: sendto(198.124.252.90): Network is unreachable Jul 19 08:31:41 slan ntpd[664]: sendto(198.129.252.38): Network is unreachable Jul 19 08:31:41 slan ntpd[664]: sendto(134.55.10.67): Network is unreachable Jul 19 08:31:42 slan ntpd[664]: sendto(198.128.2.10): Network is unreachable Jul 19 08:31:42 slan ntpd[664]: sendto(134.55.210.42): Network is unreachable Jul 19 08:31:43 slan ntpd[664]: sendto(198.124.252.90): Network is unreachable Jul 19 08:31:43 slan ntpd[664]: sendto(198.129.252.38): Network is unreachable Jul 19 08:31:43 slan ntpd[664]: sendto(134.55.10.67): Network is unreachable Jul 19 08:31:44 slan ntpd[664]: sendto(198.128.2.10): Network is unreachable Jul 19 08:31:44 slan ntpd[664]: sendto(134.55.210.42): Network is unreachable Jul 19 08:31:45 slan ntpd[664]: sendto(198.124.252.90): Network is unreachable Jul 19 08:31:45 slan ntpd[664]: sendto(198.129.252.38): Network is unreachable Jul 19 08:31:45 slan ntpd[664]: sendto(134.55.10.67): Network is unreachable Jul 19 08:31:46 slan ntpd[664]: sendto(198.128.2.10): Network is unreachable Jul 19 08:31:46 slan ntpd[664]: sendto(134.55.210.42): Network is unreachable Jul 19 08:31:47 slan ntpd[664]: sendto(198.124.252.90): Network is unreachable Jul 19 08:31:47 slan ntpd[664]: sendto(198.129.252.38): Network is unreachable Jul 19 08:31:47 slan ntpd[664]: sendto(134.55.10.67): Network is unreachable Jul 19 08:31:48 slan ntpd[664]: sendto(198.128.2.10): Network is unreachable Jul 19 08:31:48 slan ntpd[664]: sendto(134.55.210.42): Network is unreachable Jul 19 08:31:49 slan ntpd[664]: sendto(198.124.252.90): Network is unreachable Jul 19 08:31:49 slan ntpd[664]: sendto(198.129.252.38): Network is unreachable Jul 19 08:31:50 slan ntpd[664]: sendto(134.55.210.42): Network is unreachable Jul 19 08:31:51 slan ntpd[664]: sendto(198.129.252.38): Network is unreachable Jul 19 08:32:15 slan kernel: drm0: on vgapci0 Jul 19 08:32:15 slan kernel: info: [drm] Initialized radeon 1.25.0 20060524 Jul 19 08:32:17 slan kernel: info: [drm] Setting GART location based on new memory map Jul 19 08:32:17 slan kernel: info: [drm] Loading R300 Microcode Jul 19 08:32:17 slan kernel: info: [drm] writeback test succeeded in 1 usecs Jul 19 08:32:17 slan kernel: drm0: [ITHREAD] Jul 19 08:32:37 slan power_profile: changed to 'performance' Jul 19 08:32:37 slan ssh-agent[1006]: error: Unknown message 252 Jul 19 08:32:38 slan seahorse-agent[1100]: DNS-SD initialization failed: Daemon not running Jul 19 08:32:38 slan seahorse-agent[1100]: Failed to send buffer Jul 19 08:32:38 slan seahorse-agent[1100]: Failed to send buffer Jul 19 08:32:50 slan ntpd[664]: sendto(134.55.10.67): Network is unreachable Jul 19 08:32:52 slan ntpd[664]: sendto(198.124.252.90): Network is unreachable Jul 19 08:32:52 slan ntpd[664]: sendto(134.55.10.67): Network is unreachable Jul 19 08:32:53 slan bonobo-activation-server (oberman-1040): Passing command-line arguments in .server files is deprecated: "/usr/local/bin/tomboy --panel-applet" Jul 19 08:32:54 slan ntpd[664]: sendto(198.128.2.10): Network is unreachable Jul 19 08:32:54 slan ntpd[664]: sendto(198.124.252.90): Network is unreachable Jul 19 08:32:54 slan ntpd[664]: sendto(134.55.10.67): Network is unreachable Jul 19 08:32:55 slan ntpd[664]: sendto(198.129.252.38): Network is unreachable Jul 19 08:32:56 slan ntpd[664]: sendto(198.128.2.10): Network is unreachable Jul 19 08:32:56 slan ntpd[664]: sendto(198.124.252.90): Network is unreachable Jul 19 08:32:56 slan ntpd[664]: sendto(134.55.210.42): Network is unreachable Jul 19 08:32:56 slan ntpd[664]: sendto(134.55.10.67): Network is unreachable Jul 19 08:32:57 slan ntpd[664]: sendto(198.129.252.38): Network is unreachable Jul 19 08:32:58 slan ntpd[664]: sendto(198.128.2.10): Network is unreachable Jul 19 08:32:58 slan ntpd[664]: sendto(198.124.252.90): Network is unreachable Jul 19 08:32:58 slan ntpd[664]: sendto(134.55.210.42): Network is unreachable Jul 19 08:32:58 slan ntpd[664]: sendto(134.55.10.67): Network is unreachable Jul 19 08:32:59 slan ntpd[664]: sendto(198.129.252.38): Network is unreachable Jul 19 08:33:00 slan ntpd[664]: sendto(198.128.2.10): Network is unreachable Jul 19 08:33:00 slan ntpd[664]: sendto(198.124.252.90): Network is unreachable Jul 19 08:33:00 slan ntpd[664]: sendto(134.55.210.42): Network is unreachable Jul 19 08:33:00 slan ntpd[664]: sendto(134.55.10.67): Network is unreachable Jul 19 08:33:01 slan ntpd[664]: sendto(198.129.252.38): Network is unreachable Jul 19 08:33:02 slan ntpd[664]: sendto(198.128.2.10): Network is unreachable Jul 19 08:33:02 slan ntpd[664]: sendto(198.124.252.90): Network is unreachable Jul 19 08:33:02 slan ntpd[664]: sendto(134.55.210.42): Network is unreachable Jul 19 08:33:02 slan ntpd[664]: sendto(134.55.10.67): Network is unreachable Jul 19 08:33:03 slan ntpd[664]: sendto(198.129.252.38): Network is unreachable Jul 19 08:33:04 slan ntpd[664]: sendto(198.128.2.10): Network is unreachable Jul 19 08:33:04 slan ntpd[664]: sendto(198.124.252.90): Network is unreachable Jul 19 08:33:04 slan ntpd[664]: sendto(134.55.210.42): Network is unreachable Jul 19 08:33:04 slan ntpd[664]: sendto(134.55.10.67): Network is unreachable Jul 19 08:33:05 slan ntpd[664]: sendto(198.129.252.38): Network is unreachable Jul 19 08:33:06 slan ntpd[664]: sendto(198.128.2.10): Network is unreachable Jul 19 08:33:06 slan ntpd[664]: sendto(198.124.252.90): Network is unreachable Jul 19 08:33:06 slan ntpd[664]: sendto(134.55.210.42): Network is unreachable Jul 19 08:33:07 slan ntpd[664]: sendto(198.129.252.38): Network is unreachable Jul 19 08:33:08 slan ntpd[664]: sendto(198.128.2.10): Network is unreachable Jul 19 08:33:08 slan ntpd[664]: sendto(134.55.210.42): Network is unreachable Jul 19 08:33:09 slan ntpd[664]: sendto(198.129.252.38): Network is unreachable Jul 19 08:33:10 slan ntpd[664]: sendto(134.55.210.42): Network is unreachable Jul 19 08:33:14 slan sudo: oberman : TTY=ttyp0 ; PWD=/usr/home/oberman ; USER=root ; COMMAND=/bin/tcsh Jul 19 08:33:19 slan sudo: oberman : TTY=ttyp1 ; PWD=/usr/home/oberman ; USER=root ; COMMAND=/bin/tcsh Jul 19 08:33:25 slan kernel: ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) Jul 19 08:33:26 slan kernel: ath0: mem 0xb4000000-0xb400ffff irq 11 at device 2.0 on pci11 Jul 19 08:33:26 slan kernel: ath0: [ITHREAD] Jul 19 08:33:26 slan kernel: ath0: using obsoleted if_watchdog interface Jul 19 08:33:26 slan kernel: ath0: Ethernet address: 00:14:a4:60:f2:e3 Jul 19 08:33:26 slan kernel: ath0: mac 5.9 phy 4.3 radio 3.6 Jul 19 08:34:44 slan dhclient: New IP Address (ath0): 131.225.96.86 Jul 19 08:34:44 slan dhclient: New Subnet Mask (ath0): 255.255.254.0 Jul 19 08:34:44 slan dhclient: New Broadcast Address (ath0): 131.225.97.255 Jul 19 08:34:44 slan dhclient: New Routers (ath0): 131.225.97.200 Jul 19 08:34:45 slan dhclient: New Routers (ath0): 131.225.97.200 Jul 19 08:34:48 slan dhclient[1275]: connection closed Jul 19 08:34:48 slan dhclient[1275]: exiting. Jul 19 08:35:12 slan kernel: ath0: link state changed to UP Jul 19 08:35:31 slan dhclient: New IP Address (ath0): 131.225.96.86 Jul 19 08:35:32 slan dhclient: New Subnet Mask (ath0): 255.255.254.0 Jul 19 08:35:32 slan dhclient: New Broadcast Address (ath0): 131.225.97.255 Jul 19 08:35:32 slan dhclient: New Routers (ath0): 131.225.97.200 Jul 19 08:35:41 slan kernel: ath0: link state changed to DOWN Jul 19 08:35:48 slan kernel: ath0: link state changed to UP Jul 19 08:36:02 slan kernel: ath0: link state changed to DOWN Jul 19 08:36:27 slan kernel: ath0: link state changed to UP Jul 19 08:36:29 slan kernel: ath0: link state changed to DOWN Jul 19 08:36:36 slan kernel: ath0: link state changed to UP Jul 19 08:37:00 slan dhclient: New IP Address (ath0): 131.225.96.86 Jul 19 08:37:00 slan dhclient: New Subnet Mask (ath0): 255.255.254.0 Jul 19 08:37:00 slan dhclient: New Broadcast Address (ath0): 131.225.97.255 Jul 19 08:37:00 slan dhclient: New Routers (ath0): 131.225.97.200 Jul 19 08:37:48 slan kernel: ath0: link state changed to DOWN Jul 19 08:38:18 slan dhclient[1404]: connection closed Jul 19 08:38:18 slan dhclient[1404]: exiting. Jul 19 08:38:29 slan kernel: ath0: link state changed to UP Jul 19 08:38:29 slan dhclient: New IP Address (ath0): 131.225.96.86 Jul 19 08:38:29 slan dhclient: New Subnet Mask (ath0): 255.255.254.0 Jul 19 08:38:29 slan dhclient: New Broadcast Address (ath0): 131.225.97.255 Jul 19 08:38:29 slan dhclient: New Routers (ath0): 131.225.97.200 Jul 19 08:40:59 slan kernel: ipfw: limit 100 reached on entry 64000 Jul 19 08:41:47 slan ntpd[664]: time reset +0.735923 s Jul 19 08:41:47 slan ntpd[664]: kernel time sync disabled 2041 Jul 19 08:43:06 slan ntpd[664]: kernel time sync enabled 2001 Jul 19 09:11:56 slan power_profile: changed to 'economy' Jul 19 09:11:56 slan power_profile: changed to 'economy' Jul 19 09:12:36 slan kernel: stray irq7 Jul 19 09:14:16 slan kernel: stray irq7 Jul 19 09:16:22 slan last message repeated 2 times Jul 19 09:21:59 slan power_profile: changed to 'performance' Jul 19 09:21:59 slan power_profile: changed to 'performance' Jul 19 09:23:11 slan kernel: too many stray irq 7's: not logging anymore Jul 19 10:12:25 slan kernel: ath0: device timeout Jul 19 10:51:13 slan kernel: ath0: device timeout Jul 19 11:10:12 slan seahorse-agent[1100]: left gtk_main Jul 19 11:10:12 slan gconfd (oberman-1008): Listener ID 1845493862 doesn't exist Jul 19 11:10:12 slan gconfd (oberman-1008): Listener ID 1862271079 doesn't exist Jul 19 11:10:12 slan gconfd (oberman-1008): Failed to send buffer Jul 19 11:10:12 slan last message repeated 3 times Jul 19 11:10:23 slan shutdown: reboot by oberman: Jul 19 11:10:26 slan syslogd: exiting on signal 15 Jul 19 11:11:27 slan syslogd: kernel boot file is /boot/kernel/kernel Jul 19 11:11:27 slan kernel: Copyright (c) 1992-2007 The FreeBSD Project. Jul 19 11:11:27 slan kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 Jul 19 11:11:27 slan kernel: The Regents of the University of California. All rights reserved. Jul 19 11:11:27 slan kernel: FreeBSD is a registered trademark of The FreeBSD Foundation. Jul 19 11:11:27 slan kernel: FreeBSD 7.0-CURRENT #0: Wed Jul 18 12:15:54 PDT 2007 Jul 19 11:11:27 slan kernel: root@slan.es.net:/usr/obj/usr/src/sys/IBM-T43 Jul 19 11:11:27 slan kernel: Timecounter "i8254" frequency 1193182 Hz quality 0 Jul 19 11:11:27 slan kernel: CPU: Intel(R) Pentium(R) M processor 2.00GHz (1995.01-MHz 686-class CPU) Jul 19 11:11:27 slan kernel: Origin = "GenuineIntel" Id = 0x6d8 Stepping = 8 Jul 19 11:11:27 slan kernel: Features=0xafe9fbff Jul 19 11:11:27 slan kernel: Features2=0x180 Jul 19 11:11:27 slan kernel: AMD Features=0x100000 Jul 19 11:11:27 slan kernel: real memory = 1072496640 (1022 MB) Jul 19 11:11:27 slan kernel: avail memory = 1039753216 (991 MB) Jul 19 11:11:27 slan kernel: kbd1 at kbdmux0 Jul 19 11:11:27 slan kernel: ACPI Warning (tbfadt-0505): Optional field "Gpe1Block" has zero address or length: 0 102C/0 [20070320] Jul 19 11:11:27 slan kernel: cryptosoft0: on motherboard Jul 19 11:11:27 slan kernel: acpi0: on motherboard Jul 19 11:11:27 slan kernel: acpi0: [ITHREAD] Jul 19 11:11:27 slan kernel: acpi_ec0: port 0x62,0x66 on acpi0 Jul 19 11:11:27 slan kernel: acpi0: Power Button (fixed) Jul 19 11:11:27 slan kernel: acpi0: reservation of 0, a0000 (3) failed Jul 19 11:11:27 slan kernel: acpi0: reservation of 100000, 3ff00000 (3) failed Jul 19 11:11:27 slan kernel: Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 Jul 19 11:11:27 slan kernel: acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 Jul 19 11:11:27 slan kernel: cpu0: on acpi0 Jul 19 11:11:27 slan kernel: acpi_perf0: on cpu0 Jul 19 11:11:27 slan kernel: acpi_throttle0: on cpu0 Jul 19 11:11:27 slan kernel: acpi_lid0: on acpi0 Jul 19 11:11:27 slan kernel: acpi_button0: on acpi0 Jul 19 11:11:27 slan kernel: pcib0: port 0xcf8-0xcff on acpi0 Jul 19 11:11:27 slan kernel: pci0: on pcib0 Jul 19 11:11:27 slan kernel: pcib1: irq 11 at device 1.0 on pci0 Jul 19 11:11:27 slan kernel: pci1: on pcib1 Jul 19 11:11:27 slan kernel: vgapci0: port 0x3000-0x30ff mem 0xc0000000-0xc7ffffff,0xb0100000-0xb010ffff irq 11 at device 0.0 on pci1 Jul 19 11:11:27 slan kernel: acpi_video0: on vgapci0 Jul 19 11:11:27 slan kernel: pcib2: irq 11 at device 28.0 on pci0 Jul 19 11:11:27 slan kernel: pci2: on pcib2 Jul 19 11:11:27 slan kernel: pci2:0:0: bad VPD cksum, remain 14 Jul 19 11:11:27 slan kernel: bge0: mem 0xb0200000-0xb020ffff irq 11 at device 0.0 on pci2 Jul 19 11:11:27 slan kernel: miibus0: on bge0 Jul 19 11:11:27 slan kernel: brgphy0: PHY 1 on miibus0 Jul 19 11:11:27 slan kernel: brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto Jul 19 11:11:27 slan kernel: bge0: Ethernet address: 00:01:6c:e9:8f:51 Jul 19 11:11:27 slan kernel: bge0: [ITHREAD] Jul 19 11:11:27 slan kernel: pcib3: irq 11 at device 28.2 on pci0 Jul 19 11:11:27 slan kernel: pci3: on pcib3 Jul 19 11:11:27 slan kernel: pci0: at device 29.0 (no driver attached) Jul 19 11:11:27 slan kernel: pci0: at device 29.1 (no driver attached) Jul 19 11:11:27 slan kernel: pci0: at device 29.2 (no driver attached) Jul 19 11:11:27 slan kernel: pci0: at device 29.3 (no driver attached) Jul 19 11:11:27 slan kernel: pci0: at device 29.7 (no driver attached) Jul 19 11:11:27 slan kernel: pcib4: at device 30.0 on pci0 Jul 19 11:11:27 slan kernel: pci11: on pcib4 Jul 19 11:11:27 slan kernel: cbb0: mem 0xb4010000-0xb4010fff irq 11 at device 0.0 on pci11 Jul 19 11:11:27 slan kernel: cardbus0: on cbb0 Jul 19 11:11:27 slan kernel: pccard0: <16-bit PCCard bus> on cbb0 Jul 19 11:11:27 slan kernel: cbb0: [ITHREAD] Jul 19 11:11:27 slan kernel: pci11: at device 2.0 (no driver attached) Jul 19 11:11:27 slan kernel: pcm0: port 0x1c00-0x1cff,0x1880-0x18bf mem 0xb0000800-0xb00009ff,0xb0000400-0xb00004ff irq 11 at device 30.2 on pci0 Jul 19 11:11:27 slan kernel: pcm0: [ITHREAD] Jul 19 11:11:27 slan kernel: pcm0: Jul 19 11:11:27 slan kernel: pci0: at device 30.3 (no driver attached) Jul 19 11:11:27 slan kernel: isab0: at device 31.0 on pci0 Jul 19 11:11:27 slan kernel: isa0: on isab0 Jul 19 11:11:27 slan kernel: atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x18c0-0x18cf at device 31.2 on pci0 Jul 19 11:11:27 slan kernel: ata0: on atapci0 Jul 19 11:11:27 slan kernel: ata0: [ITHREAD] Jul 19 11:11:27 slan kernel: ata1: on atapci0 Jul 19 11:11:27 slan kernel: ata1: [ITHREAD] Jul 19 11:11:27 slan kernel: ichsmb0: port 0x18e0-0x18ff irq 11 at device 31.3 on pci0 Jul 19 11:11:27 slan kernel: ichsmb0: [GIANT-LOCKED] Jul 19 11:11:27 slan kernel: ichsmb0: [ITHREAD] Jul 19 11:11:27 slan kernel: smbus0: on ichsmb0 Jul 19 11:11:27 slan kernel: smb0: on smbus0 Jul 19 11:11:27 slan kernel: acpi_tz0: on acpi0 Jul 19 11:11:27 slan kernel: atkbdc0: port 0x60,0x64 irq 1 on acpi0 Jul 19 11:11:27 slan kernel: atkbd0: irq 1 on atkbdc0 Jul 19 11:11:27 slan kernel: kbd0 at atkbd0 Jul 19 11:11:27 slan kernel: atkbd0: [GIANT-LOCKED] Jul 19 11:11:27 slan kernel: atkbd0: [ITHREAD] Jul 19 11:11:27 slan kernel: psm0: flags 0x2000 irq 12 on atkbdc0 Jul 19 11:11:27 slan kernel: psm0: [GIANT-LOCKED] Jul 19 11:11:27 slan kernel: psm0: [ITHREAD] Jul 19 11:11:27 slan kernel: psm0: model Generic PS/2 mouse, device ID 0 Jul 19 11:11:27 slan kernel: fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 Jul 19 11:11:27 slan kernel: fdc0: [FILTER] Jul 19 11:11:27 slan kernel: sio0: configured irq 4 not in bitmap of probed irqs 0 Jul 19 11:11:27 slan kernel: sio0: port may not be enabled Jul 19 11:11:27 slan kernel: sio0: configured irq 4 not in bitmap of probed irqs 0 Jul 19 11:11:27 slan kernel: sio0: port may not be enabled Jul 19 11:11:27 slan kernel: sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 Jul 19 11:11:27 slan kernel: sio0: type 8250 or not responding Jul 19 11:11:27 slan kernel: sio0: [FILTER] Jul 19 11:11:27 slan kernel: sio1: configured irq 3 not in bitmap of probed irqs 0 Jul 19 11:11:27 slan kernel: sio1: port may not be enabled Jul 19 11:11:27 slan kernel: battery0: on acpi0 Jul 19 11:11:27 slan kernel: acpi_acad0: on acpi0 Jul 19 11:11:27 slan kernel: acpi_ibm0: on acpi0 Jul 19 11:11:27 slan kernel: sio1: configured irq 3 not in bitmap of probed irqs 0 Jul 19 11:11:27 slan kernel: sio1: port may not be enabled Jul 19 11:11:27 slan kernel: pmtimer0 on isa0 Jul 19 11:11:27 slan kernel: orm0: at iomem 0xc0000-0xcffff,0xd1800-0xd27ff,0xdc000-0xdffff,0xe0000-0xeffff pnpid ORM0000 on isa0 Jul 19 11:11:27 slan kernel: sc0: at flags 0x100 on isa0 Jul 19 11:11:27 slan kernel: sc0: VGA <16 virtual consoles, flags=0x300> Jul 19 11:11:27 slan kernel: vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Jul 19 11:11:27 slan kernel: sio1: configured irq 3 not in bitmap of probed irqs 0 Jul 19 11:11:27 slan kernel: sio1: port may not be enabled Jul 19 11:11:27 slan kernel: Timecounter "TSC" frequency 1995011268 Hz quality 800 Jul 19 11:11:27 slan kernel: Timecounters tick every 1.000 msec Jul 19 11:11:27 slan kernel: ipfw2 (+ipv6) initialized, divert loadable, rule-based forwarding disabled, default to accept, logging limited to 100 packets/entry by default Jul 19 11:11:27 slan kernel: ad0: 76319MB at ata0-master UDMA100 Jul 19 11:11:27 slan kernel: ad2: 76319MB at ata1-master UDMA100 Jul 19 11:11:27 slan kernel: GEOM_LABEL: Label for provider ad0s1 is ntfs/SLAN_WIN. Jul 19 11:11:27 slan kernel: GEOM_LABEL: Label for provider ad0s2 is msdosfs/SERVICEV001. Jul 19 11:11:27 slan kernel: GEOM_LABEL: Label for provider ad2s1 is msdosfs/MY MUSIC. Jul 19 11:11:27 slan kernel: Trying to mount root from ufs:/dev/ad0s3a Jul 19 11:11:27 slan root: /etc/rc: WARNING: Dump directory does not exist. Savecore not run. Jul 19 11:11:27 slan lpd[648]: lpd startup: logging=0 net-secure Jul 19 11:11:27 slan lpd[651]: unable to get official name for local machine slan.es.net: hostname nor servname provided, or not known Jul 19 11:11:27 slan ntpd[663]: ntpd 4.2.0-a Tue Jul 17 16:25:43 PDT 2007 (1) Jul 19 11:11:28 slan ntpd[663]: sendto(134.55.10.67): Network is unreachable Jul 19 11:11:29 slan ntpd[663]: sendto(198.128.2.10): Network is unreachable Jul 19 11:11:30 slan ntpd[663]: sendto(198.124.252.90): Network is unreachable Jul 19 11:11:30 slan ntpd[663]: sendto(134.55.10.67): Network is unreachable Jul 19 11:11:31 slan ntpd[663]: sendto(198.128.2.10): Network is unreachable Jul 19 11:11:31 slan ntpd[663]: sendto(134.55.210.42): Network is unreachable Jul 19 11:11:32 slan ntpd[663]: sendto(198.124.252.90): Network is unreachable Jul 19 11:11:32 slan ntpd[663]: sendto(198.129.252.38): Network is unreachable Jul 19 11:11:32 slan ntpd[663]: sendto(134.55.10.67): Network is unreachable Jul 19 11:11:33 slan ntpd[663]: sendto(198.128.2.10): Network is unreachable Jul 19 11:11:33 slan ntpd[663]: sendto(134.55.210.42): Network is unreachable Jul 19 11:11:34 slan ntpd[663]: sendto(198.124.252.90): Network is unreachable Jul 19 11:11:34 slan ntpd[663]: sendto(198.129.252.38): Network is unreachable Jul 19 11:11:34 slan ntpd[663]: sendto(134.55.10.67): Network is unreachable Jul 19 11:11:35 slan ntpd[663]: sendto(198.128.2.10): Network is unreachable Jul 19 11:11:35 slan ntpd[663]: sendto(134.55.210.42): Network is unreachable Jul 19 11:11:36 slan ntpd[663]: sendto(198.124.252.90): Network is unreachable Jul 19 11:11:36 slan ntpd[663]: sendto(198.129.252.38): Network is unreachable Jul 19 11:11:36 slan ntpd[663]: sendto(134.55.10.67): Network is unreachable Jul 19 11:11:37 slan ntpd[663]: sendto(198.128.2.10): Network is unreachable Jul 19 11:11:37 slan ntpd[663]: sendto(134.55.210.42): Network is unreachable Jul 19 11:11:38 slan ntpd[663]: sendto(198.124.252.90): Network is unreachable Jul 19 11:11:38 slan ntpd[663]: sendto(198.129.252.38): Network is unreachable Jul 19 11:11:38 slan ntpd[663]: sendto(134.55.10.67): Network is unreachable Jul 19 11:11:39 slan ntpd[663]: sendto(198.128.2.10): Network is unreachable Jul 19 11:11:39 slan ntpd[663]: sendto(134.55.210.42): Network is unreachable Jul 19 11:11:40 slan ntpd[663]: sendto(198.124.252.90): Network is unreachable Jul 19 11:11:40 slan ntpd[663]: sendto(198.129.252.38): Network is unreachable Jul 19 11:11:40 slan ntpd[663]: sendto(134.55.10.67): Network is unreachable Jul 19 11:11:41 slan ntpd[663]: sendto(198.128.2.10): Network is unreachable Jul 19 11:11:41 slan ntpd[663]: sendto(134.55.210.42): Network is unreachable Jul 19 11:11:42 slan ntpd[663]: sendto(198.124.252.90): Network is unreachable Jul 19 11:11:42 slan ntpd[663]: sendto(198.129.252.38): Network is unreachable Jul 19 11:11:42 slan ntpd[663]: sendto(134.55.10.67): Network is unreachable Jul 19 11:11:43 slan ntpd[663]: sendto(198.128.2.10): Network is unreachable Jul 19 11:11:43 slan ntpd[663]: sendto(134.55.210.42): Network is unreachable Jul 19 11:11:44 slan ntpd[663]: sendto(198.124.252.90): Network is unreachable Jul 19 11:11:44 slan ntpd[663]: sendto(198.129.252.38): Network is unreachable Jul 19 11:11:45 slan ntpd[663]: sendto(134.55.210.42): Network is unreachable Jul 19 11:11:46 slan ntpd[663]: sendto(198.129.252.38): Network is unreachable Jul 19 11:12:02 slan kernel: drm0: on vgapci0 Jul 19 11:12:02 slan kernel: info: [drm] Initialized radeon 1.25.0 20060524 Jul 19 11:12:04 slan kernel: info: [drm] Setting GART location based on new memory map Jul 19 11:12:04 slan kernel: info: [drm] Loading R300 Microcode Jul 19 11:12:04 slan kernel: info: [drm] writeback test succeeded in 1 usecs Jul 19 11:12:04 slan kernel: drm0: [ITHREAD] Jul 19 11:12:22 slan power_profile: changed to 'performance' Jul 19 11:12:23 slan ssh-agent[1005]: error: Unknown message 252 Jul 19 11:12:23 slan seahorse-agent[1099]: DNS-SD initialization failed: Daemon not running Jul 19 11:12:23 slan seahorse-agent[1099]: Failed to send buffer Jul 19 11:12:23 slan seahorse-agent[1099]: Failed to send buffer Jul 19 11:12:40 slan bonobo-activation-server (oberman-1039): Passing command-line arguments in .server files is deprecated: "/usr/local/bin/tomboy --panel-applet" Jul 19 11:12:43 slan sudo: oberman : TTY=ttyp0 ; PWD=/usr/home/oberman ; USER=root ; COMMAND=/bin/tcsh Jul 19 11:12:47 slan ntpd[663]: sendto(198.128.2.10): Network is unreachable Jul 19 11:12:47 slan ntpd[663]: sendto(134.55.10.67): Network is unreachable Jul 19 11:12:49 slan ntpd[663]: sendto(198.128.2.10): Network is unreachable Jul 19 11:12:49 slan ntpd[663]: sendto(198.124.252.90): Network is unreachable Jul 19 11:12:49 slan ntpd[663]: sendto(134.55.210.42): Network is unreachable Jul 19 11:12:49 slan ntpd[663]: sendto(134.55.10.67): Network is unreachable Jul 19 11:12:51 slan ntpd[663]: sendto(198.128.2.10): Network is unreachable Jul 19 11:12:51 slan ntpd[663]: sendto(198.124.252.90): Network is unreachable Jul 19 11:12:51 slan ntpd[663]: sendto(134.55.210.42): Network is unreachable Jul 19 11:12:51 slan ntpd[663]: sendto(134.55.10.67): Network is unreachable Jul 19 11:12:52 slan sudo: oberman : TTY=ttyp1 ; PWD=/usr/home/oberman ; USER=root ; COMMAND=/bin/tcsh Jul 19 11:12:52 slan ntpd[663]: sendto(198.129.252.38): Network is unreachable Jul 19 11:12:53 slan ntpd[663]: sendto(198.128.2.10): Network is unreachable Jul 19 11:12:53 slan ntpd[663]: sendto(198.124.252.90): Network is unreachable Jul 19 11:12:53 slan ntpd[663]: sendto(134.55.210.42): Network is unreachable Jul 19 11:12:53 slan ntpd[663]: sendto(134.55.10.67): Network is unreachable Jul 19 11:12:54 slan ntpd[663]: sendto(198.129.252.38): Network is unreachable Jul 19 11:12:55 slan ntpd[663]: sendto(198.128.2.10): Network is unreachable Jul 19 11:12:55 slan ntpd[663]: sendto(198.124.252.90): Network is unreachable Jul 19 11:12:55 slan ntpd[663]: sendto(134.55.210.42): Network is unreachable Jul 19 11:12:55 slan ntpd[663]: sendto(134.55.10.67): Network is unreachable Jul 19 11:12:56 slan ntpd[663]: sendto(198.129.252.38): Network is unreachable Jul 19 11:12:57 slan ntpd[663]: sendto(198.128.2.10): Network is unreachable Jul 19 11:12:57 slan ntpd[663]: sendto(198.124.252.90): Network is unreachable Jul 19 11:12:57 slan ntpd[663]: sendto(134.55.210.42): Network is unreachable Jul 19 11:12:57 slan ntpd[663]: sendto(134.55.10.67): Network is unreachable Jul 19 11:12:58 slan ntpd[663]: sendto(198.129.252.38): Network is unreachable Jul 19 11:12:59 slan ntpd[663]: sendto(198.128.2.10): Network is unreachable Jul 19 11:12:59 slan ntpd[663]: sendto(198.124.252.90): Network is unreachable Jul 19 11:12:59 slan ntpd[663]: sendto(134.55.210.42): Network is unreachable Jul 19 11:12:59 slan ntpd[663]: sendto(134.55.10.67): Network is unreachable Jul 19 11:13:00 slan ntpd[663]: sendto(198.129.252.38): Network is unreachable Jul 19 11:13:01 slan ntpd[663]: sendto(198.128.2.10): Network is unreachable Jul 19 11:13:01 slan ntpd[663]: sendto(198.124.252.90): Network is unreachable Jul 19 11:13:01 slan ntpd[663]: sendto(134.55.210.42): Network is unreachable Jul 19 11:13:01 slan ntpd[663]: sendto(134.55.10.67): Network is unreachable Jul 19 11:13:02 slan ntpd[663]: sendto(198.129.252.38): Network is unreachable Jul 19 11:13:03 slan ntpd[663]: sendto(198.124.252.90): Network is unreachable Jul 19 11:13:03 slan ntpd[663]: sendto(134.55.210.42): Network is unreachable Jul 19 11:13:04 slan ntpd[663]: sendto(198.129.252.38): Network is unreachable Jul 19 11:13:06 slan ntpd[663]: sendto(198.129.252.38): Network is unreachable Jul 19 11:14:14 slan kernel: ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) Jul 19 11:14:14 slan kernel: ath0: mem 0xb4000000-0xb400ffff irq 11 at device 2.0 on pci11 Jul 19 11:14:14 slan kernel: ath0: [ITHREAD] Jul 19 11:14:14 slan kernel: ath0: using obsoleted if_watchdog interface Jul 19 11:14:14 slan kernel: ath0: Ethernet address: 00:14:a4:60:f2:e3 Jul 19 11:14:14 slan kernel: ath0: mac 5.9 phy 4.3 radio 3.6 Jul 19 11:14:16 slan kernel: ath0: scan_next: chan 44a -> 48a [passive, dwell min 20 max 200] Jul 19 11:14:16 slan kernel: ath0: scan_next: chan 48a -> 34a [passive, dwell min 20 max 200] Jul 19 11:14:16 slan kernel: ath0: scan_next: chan 34a -> 38a [passive, dwell min 20 max 200] Jul 19 11:14:16 slan kernel: ath0: scan_next: chan 38a -> 42a [passive, dwell min 20 max 200] Jul 19 11:14:17 slan kernel: ath0: scan_next: chan 42a -> 46a [passive, dwell min 20 max 200] Jul 19 11:14:17 slan kernel: ath0: scan_next: chan 46a -> 2g [active, dwell min 20 max 200] Jul 19 11:14:17 slan kernel: ath0: scan_next: chan 2g -> 3g [active, dwell min 20 max 200] Jul 19 11:14:17 slan kernel: [00:1a:e2:10:70:c0] new beacon on chan 3 (bss chan 3) "fgz" Jul 19 11:14:17 slan kernel: [00:1a:e2:10:70:c0] caps 0x1 bintval 99 erp 0x7 Jul 19 11:14:17 slan kernel: ath0: ieee80211_add_scan: chan 3g min dwell met (178316 > 178285) Jul 19 11:14:17 slan kernel: ath0: scan_next: chan 3g -> 4g [active, dwell min 20 max 200] Jul 19 11:14:17 slan kernel: [00:16:46:b8:d4:60] new beacon on chan 4 (bss chan 4) "fgz" Jul 19 11:14:17 slan kernel: [00:16:46:b8:d4:60] caps 0xc01 bintval 99 erp 0x2 Jul 19 11:14:17 slan kernel: ath0: ieee80211_add_scan: chan 4g min dwell met (178437 > 178341) Jul 19 11:14:17 slan kernel: ath0: scan_next: chan 4g -> 5g [active, dwell min 20 max 200] Jul 19 11:14:17 slan kernel: [00:0a:b8:7e:ff:70] new probe_resp on chan 5 (bss chan 5) "fgz" Jul 19 11:14:17 slan kernel: [00:0a:b8:7e:ff:70] caps 0x801 bintval 99 erp 0x7 Jul 19 11:14:17 slan kernel: [00:0a:b8:7e:ff:70] new beacon on chan 5 (bss chan 5) "fgz" Jul 19 11:14:17 slan kernel: [00:0a:b8:7e:ff:70] caps 0x801 bintval 99 erp 0x7 Jul 19 11:14:17 slan kernel: ath0: ieee80211_add_scan: chan 5g min dwell met (178496 > 178462) Jul 19 11:14:17 slan kernel: ath0: scan_next: chan 5g -> 8g [active, dwell min 20 max 200] Jul 19 11:14:17 slan kernel: ath0: scan_next: chan 8g -> 9g [active, dwell min 20 max 200] Jul 19 11:14:17 slan kernel: [00:16:46:b8:b4:c0] new probe_resp on chan 9 (bss chan 9) "fgz" Jul 19 11:14:17 slan kernel: [00:16:46:b8:b4:c0] caps 0x801 bintval 99 erp 0x7 Jul 19 11:14:18 slan kernel: [00:16:46:b8:b4:c0] new beacon on chan 9 (bss chan 9) "fgz" Jul 19 11:14:18 slan kernel: [00:16:46:b8:b4:c0] caps 0x801 bintval 99 erp 0x7 Jul 19 11:14:18 slan kernel: ath0: ieee80211_add_scan: chan 9g min dwell met (178860 > 178725) Jul 19 11:14:18 slan kernel: ath0: scan_next: chan 9g -> 10g [active, dwell min 20 max 200] Jul 19 11:14:18 slan kernel: [00:16:46:b8:c7:e0] new beacon on chan 10 (bss chan 10) "fgz" Jul 19 11:14:18 slan kernel: [00:16:46:b8:c7:e0] caps 0x801 bintval 99 erp 0x7 Jul 19 11:14:18 slan kernel: ath0: ieee80211_add_scan: chan 10g min dwell met (178918 > 178885) Jul 19 11:14:18 slan kernel: ath0: scan_next: chan 10g -> 149a [passive, dwell min 20 max 200] Jul 19 11:14:18 slan kernel: ath0: scan_next: chan 149a -> 153a [passive, dwell min 20 max 200] Jul 19 11:14:18 slan kernel: ath0: scan_next: chan 153a -> 157a [passive, dwell min 20 max 200] Jul 19 11:14:18 slan kernel: ath0: scan_next: chan 157a -> 161a [passive, dwell min 20 max 200] Jul 19 11:14:18 slan kernel: ath0: scan_next: chan 161a -> 165a [passive, dwell min 20 max 200] Jul 19 11:14:19 slan kernel: ath0: scan_next: chan 165a -> 100a [passive, dwell min 20 max 200] Jul 19 11:14:19 slan kernel: ath0: scan_next: chan 100a -> 104a [passive, dwell min 20 max 200] Jul 19 11:14:19 slan kernel: ath0: scan_next: chan 104a -> 108a [passive, dwell min 20 max 200] Jul 19 11:14:19 slan kernel: ath0: scan_next: chan 108a -> 112a [passive, dwell min 20 max 200] Jul 19 11:14:19 slan kernel: ath0: scan_next: chan 112a -> 116a [passive, dwell min 20 max 200] Jul 19 11:14:20 slan kernel: ath0: scan_next: chan 116a -> 120a [passive, dwell min 20 max 200] Jul 19 11:14:20 slan kernel: ath0: scan_next: chan 120a -> 124a [passive, dwell min 20 max 200] Jul 19 11:14:20 slan kernel: ath0: scan_next: chan 124a -> 128a [passive, dwell min 20 max 200] Jul 19 11:14:20 slan kernel: ath0: scan_next: chan 128a -> 132a [passive, dwell min 20 max 200] Jul 19 11:14:21 slan kernel: ath0: scan_next: chan 132a -> 136a [passive, dwell min 20 max 200] Jul 19 11:14:21 slan kernel: ath0: scan_next: chan 136a -> 140a [passive, dwell min 20 max 200] Jul 19 11:14:21 slan kernel: ath0: macaddr bssid chan rssi rate flag wep essid Jul 19 11:14:21 slan kernel: - 00:14:6a:07:b9:00 00:14:6a:07:b9:00 6 41 54M ess no! "fgz" Jul 19 11:14:21 slan kernel: - 00:16:46:b8:d0:80 00:16:46:b8:d0:80 11 21 54M ess no! "fgz" Jul 19 11:14:21 slan kernel: - 00:16:46:b8:bf:10 00:16:46:b8:bf:10 7 4! 54M ess no! "fgz" Jul 19 11:14:21 slan kernel: - 00:1a:e2:10:70:c0 00:1a:e2:10:70:c0 3 8 54M ess no! "fgz" Jul 19 11:14:21 slan kernel: - 00:16:46:b8:d4:60 00:16:46:b8:d4:60 4 1! 54M ess no! "fgz" Jul 19 11:14:21 slan kernel: - 00:0a:b8:7e:ff:70 00:0a:b8:7e:ff:70 5 45 54M ess no! "fgz" Jul 19 11:14:21 slan kernel: - 00:16:46:b8:b4:c0 00:16:46:b8:b4:c0 9 3! 54M ess no! "fgz" Jul 19 11:14:21 slan kernel: - 00:16:46:b8:c7:e0 00:16:46:b8:c7:e0 10 4! 54M ess no! "fgz" Jul 19 11:14:21 slan kernel: ath0: scan_next: done, restart [ticks 182183, dwell min 20 scanend 2147658823] Jul 19 11:14:21 slan kernel: ath0: scan_next: chan 140a -> 1g [active, dwell min 20 max 200] Jul 19 11:14:21 slan kernel: ath0: scan_next: chan 1g -> 6g [active, dwell min 20 max 200] Jul 19 11:14:21 slan kernel: [00:14:6a:07:b9:00] new probe_resp on chan 6 (bss chan 6) "fgz" Jul 19 11:14:21 slan kernel: [00:14:6a:07:b9:00] caps 0x801 bintval 99 erp 0x7 Jul 19 11:14:21 slan kernel: [00:14:6a:07:b9:00] new beacon on chan 6 (bss chan 6) "fgz" Jul 19 11:14:21 slan kernel: [00:14:6a:07:b9:00] caps 0x801 bintval 99 erp 0x7 Jul 19 11:14:21 slan kernel: ath0: ieee80211_add_scan: chan 6g min dwell met (182429 > 182411) Jul 19 11:14:21 slan kernel: ath0: scan_next: chan 6g -> 11g [active, dwell min 20 max 200] Jul 19 11:14:21 slan kernel: [00:16:46:b8:d0:80] new probe_resp on chan 11 (bss chan 11) "fgz" Jul 19 11:14:21 slan kernel: [00:16:46:b8:d0:80] caps 0xc01 bintval 99 erp 0x2 Jul 19 11:14:21 slan kernel: [00:16:46:b8:d0:80] new beacon on chan 11 (bss chan 11) "fgz" Jul 19 11:14:21 slan kernel: [00:16:46:b8:d0:80] caps 0xc01 bintval 99 erp 0x2 Jul 19 11:14:21 slan kernel: [00:16:46:b8:d0:80] new beacon on chan 11 (bss chan 11) "fgz" Jul 19 11:14:21 slan kernel: [00:16:46:b8:d0:80] caps 0xc01 bintval 99 erp 0x2 Jul 19 11:14:21 slan kernel: ath0: ieee80211_add_scan: chan 11g min dwell met (182552 > 182454) Jul 19 11:14:21 slan kernel: ath0: scan_next: chan 11g -> 7g [active, dwell min 20 max 200] Jul 19 11:14:22 slan kernel: ath0: scan_next: chan 7g -> 52a [passive, dwell min 20 max 200] Jul 19 11:14:22 slan kernel: ath0: scan_next: chan 52a -> 56a [passive, dwell min 20 max 200] Jul 19 11:14:22 slan kernel: ath0: scan_next: chan 56a -> 60a [passive, dwell min 20 max 200] Jul 19 11:14:22 slan kernel: ath0: scan_next: chan 60a -> 64a [passive, dwell min 20 max 200] Jul 19 11:14:22 slan kernel: ath0: scan_next: chan 64a -> 36a [passive, dwell min 20 max 200] Jul 19 11:14:23 slan kernel: ath0: scan_next: chan 36a -> 40a [passive, dwell min 20 max 200] Jul 19 11:14:23 slan kernel: ath0: scan_next: chan 40a -> 44a [passive, dwell min 20 max 200] Jul 19 11:14:23 slan kernel: ath0: scan_next: chan 44a -> 48a [passive, dwell min 20 max 200] Jul 19 11:14:23 slan kernel: ath0: scan_next: chan 48a -> 34a [passive, dwell min 20 max 200] Jul 19 11:14:23 slan kernel: ath0: scan_next: chan 34a -> 38a [passive, dwell min 20 max 200] Jul 19 11:14:24 slan kernel: ath0: scan_next: chan 38a -> 42a [passive, dwell min 20 max 200] Jul 19 11:14:24 slan kernel: ath0: scan_next: chan 42a -> 46a [passive, dwell min 20 max 200] Jul 19 11:14:24 slan kernel: ath0: scan_next: chan 46a -> 2g [active, dwell min 20 max 200] Jul 19 11:14:24 slan kernel: ath0: scan_next: chan 2g -> 3g [active, dwell min 20 max 200] Jul 19 11:14:24 slan kernel: ath0: scan_next: chan 3g -> 4g [active, dwell min 20 max 200] Jul 19 11:14:25 slan kernel: ath0: scan_next: chan 4g -> 5g [active, dwell min 20 max 200] Jul 19 11:14:25 slan kernel: [00:0a:b8:7e:ff:70] new probe_resp on chan 5 (bss chan 5) "fgz" Jul 19 11:14:25 slan kernel: [00:0a:b8:7e:ff:70] caps 0x801 bintval 99 erp 0x7 Jul 19 11:14:25 slan kernel: [00:0a:b8:7e:ff:70] new beacon on chan 5 (bss chan 5) "fgz" Jul 19 11:14:25 slan kernel: [00:0a:b8:7e:ff:70] caps 0x801 bintval 99 erp 0x7 Jul 19 11:14:25 slan kernel: ath0: ieee80211_add_scan: chan 5g min dwell met (185898 > 185841) Jul 19 11:14:25 slan kernel: ath0: scan_next: chan 5g -> 8g [active, dwell min 20 max 200] Jul 19 11:14:25 slan kernel: ath0: scan_next: chan 8g -> 9g [active, dwell min 20 max 200] Jul 19 11:14:25 slan kernel: [00:16:46:b8:b4:c0] new beacon on chan 9 (bss chan 9) "fgz" Jul 19 11:14:25 slan kernel: [00:16:46:b8:b4:c0] caps 0x801 bintval 99 erp 0x7 Jul 19 11:14:25 slan kernel: ath0: ieee80211_add_scan: chan 9g min dwell met (186159 > 186127) Jul 19 11:14:25 slan kernel: ath0: scan_next: chan 9g -> 10g [active, dwell min 20 max 200] Jul 19 11:14:25 slan kernel: ath0: scan_next: chan 10g -> 149a [passive, dwell min 20 max 200] Jul 19 11:14:25 slan kernel: ath0: scan_next: chan 149a -> 153a [passive, dwell min 20 max 200] Jul 19 11:14:26 slan kernel: ath0: scan_next: chan 153a -> 157a [passive, dwell min 20 max 200] Jul 19 11:14:26 slan kernel: ath0: scan_next: chan 157a -> 161a [passive, dwell min 20 max 200] Jul 19 11:14:26 slan kernel: ath0: scan_next: chan 161a -> 165a [passive, dwell min 20 max 200] Jul 19 11:14:26 slan kernel: ath0: scan_next: chan 165a -> 100a [passive, dwell min 20 max 200] Jul 19 11:14:26 slan kernel: ath0: scan_next: chan 100a -> 104a [passive, dwell min 20 max 200] Jul 19 11:14:27 slan kernel: ath0: scan_next: chan 104a -> 108a [passive, dwell min 20 max 200] Jul 19 11:14:27 slan kernel: ath0: scan_next: chan 108a -> 112a [passive, dwell min 20 max 200] Jul 19 11:14:27 slan kernel: ath0: scan_next: chan 112a -> 116a [passive, dwell min 20 max 200] Jul 19 11:14:27 slan kernel: ath0: scan_next: chan 116a -> 120a [passive, dwell min 20 max 200] Jul 19 11:14:27 slan kernel: ath0: scan_next: chan 120a -> 124a [passive, dwell min 20 max 200] Jul 19 11:14:28 slan kernel: ath0: scan_next: chan 124a -> 128a [passive, dwell min 20 max 200] Jul 19 11:14:28 slan kernel: ath0: scan_next: chan 128a -> 132a [passive, dwell min 20 max 200] Jul 19 11:14:28 slan kernel: ath0: scan_next: chan 132a -> 136a [passive, dwell min 20 max 200] Jul 19 11:14:28 slan kernel: ath0: scan_next: chan 136a -> 140a [passive, dwell min 20 max 200] Jul 19 11:14:28 slan kernel: ath0: macaddr bssid chan rssi rate flag wep essid Jul 19 11:14:28 slan kernel: - 00:14:6a:07:b9:00 00:14:6a:07:b9:00 6 43 54M ess no! "fgz" Jul 19 11:14:28 slan kernel: - 00:16:46:b8:d0:80 00:16:46:b8:d0:80 11 24 54M ess no! "fgz" Jul 19 11:14:28 slan kernel: - 00:16:46:b8:bf:10 00:16:46:b8:bf:10 7 4! 54M ess no! "fgz" Jul 19 11:14:28 slan kernel: - 00:1a:e2:10:70:c0 00:1a:e2:10:70:c0 3 8 54M ess no! "fgz" Jul 19 11:14:28 slan kernel: - 00:16:46:b8:d4:60 00:16:46:b8:d4:60 4 1! 54M ess no! "fgz" Jul 19 11:14:28 slan kernel: - 00:0a:b8:7e:ff:70 00:0a:b8:7e:ff:70 5 46 54M ess no! "fgz" Jul 19 11:14:28 slan kernel: - 00:16:46:b8:b4:c0 00:16:46:b8:b4:c0 9 4! 54M ess no! "fgz" Jul 19 11:14:28 slan kernel: - 00:16:46:b8:c7:e0 00:16:46:b8:c7:e0 10 4! 54M ess no! "fgz" Jul 19 11:14:28 slan kernel: ath0: scan_next: done, restart [ticks 189629, dwell min 20 scanend 2147658823] Jul 19 11:14:28 slan kernel: ath0: scan_next: chan 140a -> 1g [active, dwell min 20 max 200] Jul 19 11:14:29 slan kernel: ath0: scan_next: chan 1g -> 6g [active, dwell min 20 max 200] Jul 19 11:14:29 slan kernel: [00:14:6a:07:b9:00] new probe_resp on chan 6 (bss chan 6) "fgz" Jul 19 11:14:29 slan kernel: [00:14:6a:07:b9:00] caps 0x801 bintval 99 erp 0x7 Jul 19 11:14:29 slan kernel: [00:14:6a:07:b9:00] new beacon on chan 6 (bss chan 6) "fgz" Jul 19 11:14:29 slan kernel: [00:14:6a:07:b9:00] caps 0x801 bintval 99 erp 0x7 Jul 19 11:14:29 slan kernel: ath0: ieee80211_add_scan: chan 6g min dwell met (189932 > 189857) Jul 19 11:14:29 slan kernel: ath0: scan_next: chan 6g -> 11g [active, dwell min 20 max 200] Jul 19 11:14:29 slan kernel: [00:16:46:b8:d0:80] new probe_resp on chan 11 (bss chan 11) "fgz" Jul 19 11:14:29 slan kernel: [00:16:46:b8:d0:80] caps 0xc01 bintval 99 erp 0x2 Jul 19 11:14:29 slan kernel: [00:16:46:b8:d0:80] new beacon on chan 11 (bss chan 11) "fgz" Jul 19 11:14:29 slan kernel: [00:16:46:b8:d0:80] caps 0xc01 bintval 99 erp 0x2 Jul 19 11:14:29 slan kernel: [00:16:46:b8:d0:80] new beacon on chan 11 (bss chan 11) "fgz" Jul 19 11:14:29 slan kernel: [00:16:46:b8:d0:80] caps 0xc01 bintval 99 erp 0x2 Jul 19 11:14:29 slan kernel: ath0: ieee80211_add_scan: chan 11g min dwell met (190055 > 189957) Jul 19 11:14:29 slan kernel: ath0: scan_next: chan 11g -> 7g [active, dwell min 20 max 200] Jul 19 11:14:29 slan kernel: ath0: scan_next: chan 7g -> 52a [passive, dwell min 20 max 200] Jul 19 11:14:29 slan kernel: ath0: scan_next: chan 52a -> 56a [passive, dwell min 20 max 200] Jul 19 11:14:30 slan kernel: ath0: scan_next: chan 56a -> 60a [passive, dwell min 20 max 200] Jul 19 11:14:30 slan kernel: ath0: scan_next: chan 60a -> 64a [passive, dwell min 20 max 200] Jul 19 11:14:30 slan kernel: ath0: scan_next: chan 64a -> 36a [passive, dwell min 20 max 200] Jul 19 11:14:30 slan kernel: ath0: scan_next: chan 36a -> 40a [passive, dwell min 20 max 200] Jul 19 11:14:30 slan kernel: ath0: scan_next: chan 40a -> 44a [passive, dwell min 20 max 200] Jul 19 11:14:31 slan kernel: ath0: scan_next: chan 44a -> 48a [passive, dwell min 20 max 200] Jul 19 11:14:31 slan kernel: ath0: scan_next: chan 48a -> 34a [passive, dwell min 20 max 200] Jul 19 11:14:31 slan kernel: ath0: scan_next: chan 34a -> 38a [passive, dwell min 20 max 200] Jul 19 11:14:31 slan kernel: ath0: scan_next: chan 38a -> 42a [passive, dwell min 20 max 200] Jul 19 11:14:31 slan kernel: ath0: scan_next: chan 42a -> 46a [passive, dwell min 20 max 200] Jul 19 11:14:32 slan kernel: ath0: scan_next: chan 46a -> 2g [active, dwell min 20 max 200] Jul 19 11:14:32 slan kernel: ath0: scan_next: chan 2g -> 3g [active, dwell min 20 max 200] Jul 19 11:14:32 slan kernel: ath0: scan_next: chan 3g -> 4g [active, dwell min 20 max 200] Jul 19 11:14:32 slan kernel: ath0: scan_next: chan 4g -> 5g [active, dwell min 20 max 200] Jul 19 11:14:32 slan kernel: [00:0a:b8:7e:ff:70] new probe_resp on chan 5 (bss chan 5) "fgz" Jul 19 11:14:32 slan kernel: [00:0a:b8:7e:ff:70] caps 0x801 bintval 99 erp 0x7 Jul 19 11:14:32 slan kernel: [00:0a:b8:7e:ff:70] new beacon on chan 5 (bss chan 5) "fgz" Jul 19 11:14:32 slan kernel: [00:0a:b8:7e:ff:70] caps 0x801 bintval 99 erp 0x7 Jul 19 11:14:32 slan kernel: ath0: ieee80211_add_scan: chan 5g min dwell met (193401 > 193344) Jul 19 11:14:32 slan kernel: ath0: scan_next: chan 5g -> 8g [active, dwell min 20 max 200] Jul 19 11:14:32 slan kernel: ath0: scan_next: chan 8g -> 9g [active, dwell min 20 max 200] Jul 19 11:14:33 slan kernel: ath0: scan_next: chan 9g -> 10g [active, dwell min 20 max 200] Jul 19 11:14:33 slan kernel: ath0: scan_next: chan 10g -> 149a [passive, dwell min 20 max 200] Jul 19 11:14:33 slan kernel: ath0: scan_next: chan 149a -> 153a [passive, dwell min 20 max 200] Jul 19 11:14:33 slan kernel: ath0: scan_next: chan 153a -> 157a [passive, dwell min 20 max 200] Jul 19 11:14:33 slan kernel: ath0: scan_next: chan 157a -> 161a [passive, dwell min 20 max 200] Jul 19 11:14:34 slan kernel: ath0: scan_next: chan 161a -> 165a [passive, dwell min 20 max 200] Jul 19 11:14:34 slan kernel: ath0: scan_next: chan 165a -> 100a [passive, dwell min 20 max 200] Jul 19 11:14:34 slan kernel: ath0: scan_next: chan 100a -> 104a [passive, dwell min 20 max 200] Jul 19 11:14:34 slan kernel: ath0: scan_next: chan 104a -> 108a [passive, dwell min 20 max 200] Jul 19 11:14:34 slan kernel: ath0: scan_next: chan 108a -> 112a [passive, dwell min 20 max 200] Jul 19 11:14:35 slan kernel: ath0: scan_next: chan 112a -> 116a [passive, dwell min 20 max 200] Jul 19 11:14:35 slan kernel: ath0: scan_next: chan 116a -> 120a [passive, dwell min 20 max 200] Jul 19 11:14:35 slan kernel: ath0: scan_next: chan 120a -> 124a [passive, dwell min 20 max 200] Jul 19 11:14:35 slan kernel: ath0: scan_next: chan 124a -> 128a [passive, dwell min 20 max 200] Jul 19 11:14:35 slan kernel: ath0: scan_next: chan 128a -> 132a [passive, dwell min 20 max 200] Jul 19 11:14:36 slan kernel: ath0: scan_next: chan 132a -> 136a [passive, dwell min 20 max 200] Jul 19 11:14:36 slan kernel: ath0: scan_next: chan 136a -> 140a [passive, dwell min 20 max 200] Jul 19 11:14:36 slan kernel: ath0: macaddr bssid chan rssi rate flag wep essid Jul 19 11:14:36 slan kernel: - 00:14:6a:07:b9:00 00:14:6a:07:b9:00 6 45 54M ess no! "fgz" Jul 19 11:14:36 slan kernel: - 00:16:46:b8:d0:80 00:16:46:b8:d0:80 11 26 54M ess no! "fgz" Jul 19 11:14:36 slan kernel: ^ 00:16:46:b8:bf:10 00:16:46:b8:bf:10 7 4! 54M ess no! "fgz" Jul 19 11:14:36 slan kernel: ^ 00:1a:e2:10:70:c0 00:1a:e2:10:70:c0 3 8 54M ess no! "fgz" Jul 19 11:14:36 slan kernel: ^ 00:16:46:b8:d4:60 00:16:46:b8:d4:60 4 1! 54M ess no! "fgz" Jul 19 11:14:36 slan kernel: - 00:0a:b8:7e:ff:70 00:0a:b8:7e:ff:70 5 46 54M ess no! "fgz" Jul 19 11:14:36 slan kernel: - 00:16:46:b8:b4:c0 00:16:46:b8:b4:c0 9 4! 54M ess no! "fgz" Jul 19 11:14:36 slan kernel: ^ 00:16:46:b8:c7:e0 00:16:46:b8:c7:e0 10 4! 54M ess no! "fgz" Jul 19 11:14:36 slan kernel: ath0: scan_next: done, restart [ticks 197278, dwell min 20 scanend 2147658823] Jul 19 11:14:36 slan kernel: ath0: scan_next: chan 140a -> 1g [active, dwell min 20 max 200] Jul 19 11:14:36 slan kernel: ath0: scan_next: chan 1g -> 6g [active, dwell min 20 max 200] Jul 19 11:14:36 slan kernel: [00:14:6a:07:b9:00] new probe_resp on chan 6 (bss chan 6) "fgz" Jul 19 11:14:36 slan kernel: [00:14:6a:07:b9:00] caps 0x801 bintval 99 erp 0x7 Jul 19 11:14:36 slan kernel: [00:14:6a:07:b9:00] new beacon on chan 6 (bss chan 6) "fgz" Jul 19 11:14:36 slan kernel: [00:14:6a:07:b9:00] caps 0x801 bintval 99 erp 0x7 Jul 19 11:14:36 slan kernel: ath0: ieee80211_add_scan: chan 6g min dwell met (197536 > 197506) Jul 19 11:14:36 slan kernel: ath0: scan_next: chan 6g -> 11g [active, dwell min 20 max 200] Jul 19 11:14:36 slan kernel: [00:16:46:b8:d0:80] new probe_resp on chan 11 (bss chan 11) "fgz" Jul 19 11:14:36 slan kernel: [00:16:46:b8:d0:80] caps 0xc01 bintval 99 erp 0x2 Jul 19 11:14:36 slan kernel: [00:16:46:b8:d0:80] new beacon on chan 11 (bss chan 11) "fgz" Jul 19 11:14:36 slan kernel: [00:16:46:b8:d0:80] caps 0xc01 bintval 99 erp 0x2 Jul 19 11:14:36 slan kernel: [00:16:46:b8:d0:80] new beacon on chan 11 (bss chan 11) "fgz" Jul 19 11:14:36 slan kernel: [00:16:46:b8:d0:80] caps 0xc01 bintval 99 erp 0x2 Jul 19 11:14:36 slan kernel: ath0: ieee80211_add_scan: chan 11g min dwell met (197660 > 197561) Jul 19 11:14:36 slan kernel: ath0: scan_next: chan 11g -> 7g [active, dwell min 20 max 200] Jul 19 11:14:37 slan kernel: ath0: scan_next: chan 7g -> 52a [passive, dwell min 20 max 200] Jul 19 11:14:37 slan kernel: ath0: scan_next: chan 52a -> 56a [passive, dwell min 20 max 200] Jul 19 11:14:37 slan kernel: ath0: scan_next: chan 56a -> 60a [passive, dwell min 20 max 200] Jul 19 11:14:37 slan kernel: ath0: scan_next: chan 60a -> 64a [passive, dwell min 20 max 200] Jul 19 11:14:37 slan kernel: ath0: scan_next: chan 64a -> 36a [passive, dwell min 20 max 200] Jul 19 11:14:38 slan kernel: ath0: scan_next: chan 36a -> 40a [passive, dwell min 20 max 200] Jul 19 11:14:38 slan kernel: ath0: scan_next: chan 40a -> 44a [passive, dwell min 20 max 200] Jul 19 11:14:38 slan kernel: ath0: scan_next: chan 44a -> 48a [passive, dwell min 20 max 200] Jul 19 11:14:38 slan kernel: ath0: scan_next: chan 48a -> 34a [passive, dwell min 20 max 200] Jul 19 11:14:38 slan kernel: ath0: scan_next: chan 34a -> 38a [passive, dwell min 20 max 200] Jul 19 11:14:39 slan kernel: ath0: scan_next: chan 38a -> 42a [passive, dwell min 20 max 200] Jul 19 11:14:39 slan kernel: ath0: scan_next: chan 42a -> 46a [passive, dwell min 20 max 200] Jul 19 11:14:39 slan kernel: ath0: scan_next: chan 46a -> 2g [active, dwell min 20 max 200] Jul 19 11:14:39 slan kernel: ath0: scan_next: chan 2g -> 3g [active, dwell min 20 max 200] Jul 19 11:14:39 slan kernel: [00:16:46:b8:bf:50] new beacon on chan 3 (bss chan 3) "fgz" Jul 19 11:14:39 slan kernel: [00:16:46:b8:bf:50] caps 0x801 bintval 99 erp 0x7 Jul 19 11:14:39 slan kernel: ath0: ieee80211_add_scan: chan 3g min dwell met (200547 > 200541) Jul 19 11:14:39 slan kernel: ath0: scan_next: chan 3g -> 4g [active, dwell min 20 max 200] Jul 19 11:14:40 slan kernel: ath0: scan_next: chan 4g -> 5g [active, dwell min 20 max 200] Jul 19 11:14:40 slan kernel: [00:0a:b8:7e:ff:70] new probe_resp on chan 5 (bss chan 5) "fgz" Jul 19 11:14:40 slan kernel: [00:0a:b8:7e:ff:70] caps 0x801 bintval 99 erp 0x7 Jul 19 11:14:40 slan kernel: [00:0a:b8:7e:ff:70] new beacon on chan 5 (bss chan 5) "fgz" Jul 19 11:14:40 slan kernel: [00:0a:b8:7e:ff:70] caps 0x801 bintval 99 erp 0x7 Jul 19 11:14:40 slan kernel: ath0: ieee80211_add_scan: chan 5g min dwell met (200802 > 200776) Jul 19 11:14:40 slan kernel: ath0: scan_next: chan 5g -> 8g [active, dwell min 20 max 200] Jul 19 11:14:40 slan kernel: ath0: scan_next: chan 8g -> 9g [active, dwell min 20 max 200] Jul 19 11:14:40 slan kernel: [00:16:46:b8:b4:c0] new beacon on chan 9 (bss chan 9) "fgz" Jul 19 11:14:40 slan kernel: [00:16:46:b8:b4:c0] caps 0x801 bintval 99 erp 0x7 Jul 19 11:14:40 slan kernel: ath0: ieee80211_add_scan: chan 9g min dwell met (201064 > 201031) Jul 19 11:14:40 slan kernel: ath0: scan_next: chan 9g -> 10g [active, dwell min 20 max 200] Jul 19 11:14:40 slan kernel: ath0: scan_next: chan 10g -> 149a [passive, dwell min 20 max 200] Jul 19 11:14:40 slan kernel: ath0: scan_next: chan 149a -> 153a [passive, dwell min 20 max 200] Jul 19 11:14:40 slan kernel: ath0: scan_next: chan 153a -> 157a [passive, dwell min 20 max 200] Jul 19 11:14:41 slan kernel: ath0: scan_next: chan 157a -> 161a [passive, dwell min 20 max 200] Jul 19 11:14:41 slan kernel: ath0: scan_next: chan 161a -> 165a [passive, dwell min 20 max 200] Jul 19 11:14:41 slan kernel: ath0: scan_next: chan 165a -> 100a [passive, dwell min 20 max 200] Jul 19 11:14:41 slan kernel: ath0: scan_next: chan 100a -> 104a [passive, dwell min 20 max 200] Jul 19 11:14:41 slan kernel: ath0: scan_next: chan 104a -> 108a [passive, dwell min 20 max 200] Jul 19 11:14:42 slan kernel: ath0: scan_next: chan 108a -> 112a [passive, dwell min 20 max 200] Jul 19 11:14:42 slan kernel: ath0: scan_next: chan 112a -> 116a [passive, dwell min 20 max 200] Jul 19 11:14:42 slan kernel: ath0: scan_next: chan 116a -> 120a [passive, dwell min 20 max 200] Jul 19 11:14:42 slan kernel: ath0: scan_next: chan 120a -> 124a [passive, dwell min 20 max 200] Jul 19 11:14:42 slan kernel: ath0: scan_next: chan 124a -> 128a [passive, dwell min 20 max 200] Jul 19 11:14:43 slan kernel: ath0: scan_next: chan 128a -> 132a [passive, dwell min 20 max 200] Jul 19 11:14:43 slan kernel: ath0: scan_next: chan 132a -> 136a [passive, dwell min 20 max 200] Jul 19 11:14:43 slan kernel: ath0: scan_next: chan 136a -> 140a [passive, dwell min 20 max 200] Jul 19 11:14:43 slan kernel: ath0: macaddr bssid chan rssi rate flag wep essid Jul 19 11:14:43 slan kernel: - 00:14:6a:07:b9:00 00:14:6a:07:b9:00 6 47 54M ess no! "fgz" Jul 19 11:14:43 slan kernel: - 00:16:46:b8:d0:80 00:16:46:b8:d0:80 11 27 54M ess no! "fgz" Jul 19 11:14:43 slan kernel: ^ 00:16:46:b8:bf:10 00:16:46:b8:bf:10 7 4! 54M ess no! "fgz" Jul 19 11:14:43 slan kernel: ^ 00:1a:e2:10:70:c0 00:1a:e2:10:70:c0 3 8 54M ess no! "fgz" Jul 19 11:14:43 slan kernel: ^ 00:16:46:b8:d4:60 00:16:46:b8:d4:60 4 1! 54M ess no! "fgz" Jul 19 11:14:43 slan kernel: - 00:0a:b8:7e:ff:70 00:0a:b8:7e:ff:70 5 47 54M ess no! "fgz" Jul 19 11:14:43 slan kernel: - 00:16:46:b8:b4:c0 00:16:46:b8:b4:c0 9 4! 54M ess no! "fgz" Jul 19 11:14:43 slan kernel: ^ 00:16:46:b8:c7:e0 00:16:46:b8:c7:e0 10 4! 54M ess no! "fgz" Jul 19 11:14:43 slan kernel: - 00:16:46:b8:bf:50 00:16:46:b8:bf:50 3 3! 54M ess no! "fgz" Jul 19 11:14:43 slan kernel: ath0: scan_next: done, restart [ticks 204533, dwell min 20 scanend 2147658823] Jul 19 11:14:43 slan kernel: ath0: scan_next: chan 140a -> 1g [active, dwell min 20 max 200] Jul 19 11:14:43 slan kernel: ath0: scan_next: chan 1g -> 6g [active, dwell min 20 max 200] Jul 19 11:14:44 slan kernel: [00:14:6a:07:b9:00] new probe_resp on chan 6 (bss chan 6) "fgz" Jul 19 11:14:44 slan kernel: [00:14:6a:07:b9:00] caps 0x801 bintval 99 erp 0x7 Jul 19 11:14:44 slan kernel: [00:14:6a:07:b9:00] new beacon on chan 6 (bss chan 6) "fgz" Jul 19 11:14:44 slan kernel: [00:14:6a:07:b9:00] caps 0x801 bintval 99 erp 0x7 Jul 19 11:14:44 slan kernel: ath0: ieee80211_add_scan: chan 6g min dwell met (204836 > 204761) Jul 19 11:14:44 slan kernel: ath0: scan_next: chan 6g -> 11g [active, dwell min 20 max 200] Jul 19 11:14:44 slan kernel: [00:16:46:b8:d0:80] new probe_resp on chan 11 (bss chan 11) "fgz" Jul 19 11:14:44 slan kernel: [00:16:46:b8:d0:80] caps 0xc01 bintval 99 erp 0x2 Jul 19 11:14:44 slan kernel: [00:16:46:b8:d0:80] new beacon on chan 11 (bss chan 11) "fgz" Jul 19 11:14:44 slan kernel: [00:16:46:b8:d0:80] caps 0xc01 bintval 99 erp 0x2 Jul 19 11:14:44 slan kernel: [00:16:46:b8:d0:80] new beacon on chan 11 (bss chan 11) "fgz" Jul 19 11:14:44 slan kernel: [00:16:46:b8:d0:80] caps 0xc01 bintval 99 erp 0x2 Jul 19 11:14:44 slan kernel: ath0: ieee80211_add_scan: chan 11g min dwell met (204960 > 204861) Jul 19 11:14:44 slan kernel: ath0: scan_next: chan 11g -> 7g [active, dwell min 20 max 200] Jul 19 11:14:44 slan kernel: ath0: scan_next: chan 7g -> 52a [passive, dwell min 20 max 200] Jul 19 11:14:44 slan kernel: ath0: scan_next: chan 52a -> 56a [passive, dwell min 20 max 200] Jul 19 11:14:44 slan kernel: ath0: scan_next: chan 56a -> 60a [passive, dwell min 20 max 200] Jul 19 11:14:45 slan kernel: ath0: scan_next: chan 60a -> 64a [passive, dwell min 20 max 200] Jul 19 11:14:45 slan kernel: ath0: scan_next: chan 64a -> 36a [passive, dwell min 20 max 200] Jul 19 11:14:45 slan kernel: ath0: scan_next: chan 36a -> 40a [passive, dwell min 20 max 200] Jul 19 11:14:45 slan kernel: ath0: scan_next: chan 40a -> 44a [passive, dwell min 20 max 200] Jul 19 11:14:45 slan kernel: ath0: scan_next: chan 44a -> 48a [passive, dwell min 20 max 200] Jul 19 11:14:46 slan kernel: ath0: scan_next: chan 48a -> 34a [passive, dwell min 20 max 200] Jul 19 11:14:46 slan kernel: ath0: scan_next: chan 34a -> 38a [passive, dwell min 20 max 200] Jul 19 11:14:46 slan kernel: ath0: scan_next: chan 38a -> 42a [passive, dwell min 20 max 200] Jul 19 11:14:46 slan kernel: ath0: scan_next: chan 42a -> 46a [passive, dwell min 20 max 200] Jul 19 11:14:46 slan kernel: ath0: scan_next: chan 46a -> 2g [active, dwell min 20 max 200] Jul 19 11:14:47 slan kernel: ath0: scan_next: chan 2g -> 3g [active, dwell min 20 max 200] Jul 19 11:14:47 slan kernel: ath0: scan_next: chan 3g -> 4g [active, dwell min 20 max 200] Jul 19 11:14:47 slan kernel: ath0: scan_next: chan 4g -> 5g [active, dwell min 20 max 200] Jul 19 11:14:47 slan kernel: [00:0a:b8:7e:ff:70] new probe_resp on chan 5 (bss chan 5) "fgz" Jul 19 11:14:47 slan kernel: [00:0a:b8:7e:ff:70] caps 0x801 bintval 99 erp 0x7 Jul 19 11:14:47 slan kernel: [00:0a:b8:7e:ff:70] new beacon on chan 5 (bss chan 5) "fgz" Jul 19 11:14:47 slan kernel: [00:0a:b8:7e:ff:70] caps 0x801 bintval 99 erp 0x7 Jul 19 11:14:47 slan kernel: ath0: ieee80211_add_scan: chan 5g min dwell met (208305 > 208249) Jul 19 11:14:47 slan kernel: ath0: scan_next: chan 5g -> 8g [active, dwell min 20 max 200] Jul 19 11:14:47 slan kernel: ath0: scan_next: chan 8g -> 9g [active, dwell min 20 max 200] Jul 19 11:14:47 slan kernel: ath0: scan_next: chan 9g -> 10g [active, dwell min 20 max 200] Jul 19 11:14:48 slan kernel: [00:1a:e2:10:6d:70] new beacon on chan 10 (bss chan 10) "fgz" Jul 19 11:14:48 slan kernel: [00:1a:e2:10:6d:70] caps 0x1 bintval 99 erp 0x7 Jul 19 11:14:48 slan kernel: ath0: ieee80211_add_scan: chan 10g min dwell met (208789 > 208738) Jul 19 11:14:48 slan kernel: ath0: scan_next: chan 10g -> 149a [passive, dwell min 20 max 200] Jul 19 11:14:48 slan kernel: ath0: scan_next: chan 149a -> 153a [passive, dwell min 20 max 200] Jul 19 11:14:48 slan kernel: ath0: scan_next: chan 153a -> 157a [passive, dwell min 20 max 200] Jul 19 11:14:48 slan kernel: ath0: scan_next: chan 157a -> 161a [passive, dwell min 20 max 200] Jul 19 11:14:48 slan kernel: ath0: scan_next: chan 161a -> 165a [passive, dwell min 20 max 200] Jul 19 11:14:49 slan kernel: ath0: scan_next: chan 165a -> 100a [passive, dwell min 20 max 200] Jul 19 11:14:49 slan kernel: ath0: scan_next: chan 100a -> 104a [passive, dwell min 20 max 200] Jul 19 11:14:49 slan kernel: ath0: scan_next: chan 104a -> 108a [passive, dwell min 20 max 200] Jul 19 11:14:49 slan kernel: ath0: scan_next: chan 108a -> 112a [passive, dwell min 20 max 200] Jul 19 11:14:49 slan kernel: ath0: scan_next: chan 112a -> 116a [passive, dwell min 20 max 200] Jul 19 11:14:50 slan kernel: ath0: scan_next: chan 116a -> 120a [passive, dwell min 20 max 200] Jul 19 11:14:50 slan kernel: ath0: scan_next: chan 120a -> 124a [passive, dwell min 20 max 200] Jul 19 11:14:50 slan kernel: ath0: scan_next: chan 124a -> 128a [passive, dwell min 20 max 200] Jul 19 11:14:50 slan kernel: ath0: scan_next: chan 128a -> 132a [passive, dwell min 20 max 200] Jul 19 11:14:50 slan kernel: ath0: scan_next: chan 132a -> 136a [passive, dwell min 20 max 200] Jul 19 11:14:51 slan kernel: ath0: scan_next: chan 136a -> 140a [passive, dwell min 20 max 200] Jul 19 11:14:51 slan kernel: ath0: macaddr bssid chan rssi rate flag wep essid Jul 19 11:14:51 slan kernel: - 00:14:6a:07:b9:00 00:14:6a:07:b9:00 6 46 54M ess no! "fgz" Jul 19 11:14:51 slan kernel: - 00:16:46:b8:d0:80 00:16:46:b8:d0:80 11 28 54M ess no! "fgz" Jul 19 11:14:51 slan kernel: ^ 00:16:46:b8:bf:10 00:16:46:b8:bf:10 7 4! 54M ess no! "fgz" Jul 19 11:14:51 slan kernel: ^ 00:1a:e2:10:70:c0 00:1a:e2:10:70:c0 3 8 54M ess no! "fgz" Jul 19 11:14:51 slan kernel: ^ 00:16:46:b8:d4:60 00:16:46:b8:d4:60 4 1! 54M ess no! "fgz" Jul 19 11:14:51 slan kernel: - 00:0a:b8:7e:ff:70 00:0a:b8:7e:ff:70 5 46 54M ess no! "fgz" Jul 19 11:14:51 slan kernel: - 00:16:46:b8:b4:c0 00:16:46:b8:b4:c0 9 4! 54M ess no! "fgz" Jul 19 11:14:51 slan kernel: ^ 00:16:46:b8:c7:e0 00:16:46:b8:c7:e0 10 4! 54M ess no! "fgz" Jul 19 11:14:51 slan kernel: - 00:16:46:b8:bf:50 00:16:46:b8:bf:50 3 3! 54M ess no! "fgz" Jul 19 11:14:51 slan kernel: - 00:1a:e2:10:6d:70 00:1a:e2:10:6d:70 10 16 54M ess no! "fgz" Jul 19 11:14:51 slan kernel: ath0: scan_next: done, restart [ticks 212054, dwell min 20 scanend 2147658823] Jul 19 11:14:51 slan kernel: ath0: scan_next: chan 140a -> 1g [active, dwell min 20 max 200] Jul 19 11:14:51 slan kernel: ath0: scan_next: chan 1g -> 6g [active, dwell min 20 max 200] Jul 19 11:14:51 slan kernel: [00:14:6a:07:b9:00] new probe_resp on chan 6 (bss chan 6) "fgz" Jul 19 11:14:51 slan kernel: [00:14:6a:07:b9:00] caps 0x801 bintval 99 erp 0x7 Jul 19 11:14:51 slan kernel: [00:14:6a:07:b9:00] new beacon on chan 6 (bss chan 6) "fgz" Jul 19 11:14:51 slan kernel: [00:14:6a:07:b9:00] caps 0x801 bintval 99 erp 0x7 Jul 19 11:14:51 slan kernel: ath0: ieee80211_add_scan: chan 6g min dwell met (212339 > 212282) Jul 19 11:14:51 slan kernel: ath0: scan_next: chan 6g -> 11g [active, dwell min 20 max 200] Jul 19 11:14:51 slan kernel: [00:16:46:b8:d0:80] new probe_resp on chan 11 (bss chan 11) "fgz" Jul 19 11:14:51 slan kernel: [00:16:46:b8:d0:80] caps 0xc01 bintval 99 erp 0x2 Jul 19 11:14:51 slan kernel: [00:16:46:b8:d0:80] new beacon on chan 11 (bss chan 11) "fgz" Jul 19 11:14:51 slan kernel: [00:16:46:b8:d0:80] caps 0xc01 bintval 99 erp 0x2 Jul 19 11:14:51 slan kernel: [00:16:46:b8:d0:80] new beacon on chan 11 (bss chan 11) "fgz" Jul 19 11:14:51 slan kernel: [00:16:46:b8:d0:80] caps 0xc01 bintval 99 erp 0x2 Jul 19 11:14:51 slan kernel: ath0: ieee80211_add_scan: chan 11g min dwell met (212463 > 212364) Jul 19 11:14:51 slan kernel: ath0: scan_next: chan 11g -> 7g [active, dwell min 20 max 200] Jul 19 11:14:51 slan kernel: ath0: scan_next: chan 7g -> 52a [passive, dwell min 20 max 200] Jul 19 11:14:52 slan kernel: ath0: scan_next: chan 52a -> 56a [passive, dwell min 20 max 200] Jul 19 11:14:52 slan kernel: ath0: scan_next: chan 56a -> 60a [passive, dwell min 20 max 200] Jul 19 11:14:52 slan kernel: ath0: scan_next: chan 60a -> 64a [passive, dwell min 20 max 200] Jul 19 11:14:52 slan kernel: ath0: scan_next: chan 64a -> 36a [passive, dwell min 20 max 200] Jul 19 11:14:52 slan kernel: ath0: scan_next: chan 36a -> 40a [passive, dwell min 20 max 200] Jul 19 11:14:53 slan kernel: ath0: scan_next: chan 40a -> 44a [passive, dwell min 20 max 200] Jul 19 11:14:53 slan kernel: ath0: scan_next: chan 44a -> 48a [passive, dwell min 20 max 200] Jul 19 11:14:53 slan kernel: ath0: scan_next: chan 48a -> 34a [passive, dwell min 20 max 200] Jul 19 11:14:53 slan kernel: ath0: scan_next: chan 34a -> 38a [passive, dwell min 20 max 200] Jul 19 11:14:53 slan kernel: ath0: scan_next: chan 38a -> 42a [passive, dwell min 20 max 200] Jul 19 11:14:54 slan kernel: ath0: scan_next: chan 42a -> 46a [passive, dwell min 20 max 200] Jul 19 11:14:54 slan kernel: ath0: scan_next: chan 46a -> 2g [active, dwell min 20 max 200] Jul 19 11:14:54 slan kernel: ath0: scan_next: chan 2g -> 3g [active, dwell min 20 max 200] Jul 19 11:14:54 slan kernel: ath0: scan_next: chan 3g -> 4g [active, dwell min 20 max 200] Jul 19 11:14:54 slan kernel: [00:16:46:b8:d4:60] new beacon on chan 4 (bss chan 4) "fgz" Jul 19 11:14:54 slan kernel: [00:16:46:b8:d4:60] caps 0xc01 bintval 99 erp 0x2 Jul 19 11:14:54 slan kernel: ath0: ieee80211_add_scan: chan 4g min dwell met (215648 > 215548) Jul 19 11:14:54 slan kernel: ath0: scan_next: chan 4g -> 5g [active, dwell min 20 max 200] Jul 19 11:14:54 slan kernel: [00:0a:b8:7e:ff:70] new probe_resp on chan 5 (bss chan 5) "fgz" Jul 19 11:14:54 slan kernel: [00:0a:b8:7e:ff:70] caps 0x801 bintval 99 erp 0x7 Jul 19 11:14:54 slan kernel: [00:0a:b8:7e:ff:70] new beacon on chan 5 (bss chan 5) "fgz" Jul 19 11:14:54 slan kernel: [00:0a:b8:7e:ff:70] caps 0x801 bintval 99 erp 0x7 Jul 19 11:14:54 slan kernel: ath0: ieee80211_add_scan: chan 5g min dwell met (215707 > 215673) Jul 19 11:14:54 slan kernel: ath0: scan_next: chan 5g -> 8g [active, dwell min 20 max 200] Jul 19 11:14:55 slan kernel: ath0: scan_next: chan 8g -> 9g [active, dwell min 20 max 200] Jul 19 11:14:55 slan kernel: [00:16:46:b8:b4:c0] new beacon on chan 9 (bss chan 9) "fgz" Jul 19 11:14:55 slan kernel: [00:16:46:b8:b4:c0] caps 0xc01 bintval 99 erp 0x2 Jul 19 11:14:55 slan kernel: ath0: ieee80211_add_scan: chan 9g min dwell met (216071 > 215936) Jul 19 11:14:55 slan kernel: ath0: scan_next: chan 9g -> 10g [active, dwell min 20 max 200] Jul 19 11:14:55 slan kernel: [00:16:46:b8:c7:e0] new beacon on chan 10 (bss chan 10) "fgz" Jul 19 11:14:55 slan kernel: [00:16:46:b8:c7:e0] caps 0x801 bintval 99 erp 0x7 Jul 19 11:14:55 slan kernel: ath0: ieee80211_add_scan: chan 10g min dwell met (216128 > 216096) Jul 19 11:14:55 slan kernel: ath0: scan_next: chan 10g -> 149a [passive, dwell min 20 max 200] Jul 19 11:14:55 slan kernel: ath0: scan_next: chan 149a -> 153a [passive, dwell min 20 max 200] Jul 19 11:14:55 slan kernel: ath0: scan_next: chan 153a -> 157a [passive, dwell min 20 max 200] Jul 19 11:14:55 slan kernel: ath0: scan_next: chan 157a -> 161a [passive, dwell min 20 max 200] Jul 19 11:14:56 slan kernel: ath0: scan_next: chan 161a -> 165a [passive, dwell min 20 max 200] Jul 19 11:14:56 slan kernel: ath0: scan_next: chan 165a -> 100a [passive, dwell min 20 max 200] Jul 19 11:14:56 slan kernel: ath0: scan_next: chan 100a -> 104a [passive, dwell min 20 max 200] Jul 19 11:14:56 slan kernel: ath0: scan_next: chan 104a -> 108a [passive, dwell min 20 max 200] Jul 19 11:14:56 slan kernel: ath0: scan_next: chan 108a -> 112a [passive, dwell min 20 max 200] Jul 19 11:14:57 slan kernel: ath0: scan_next: chan 112a -> 116a [passive, dwell min 20 max 200] Jul 19 11:14:57 slan kernel: ath0: scan_next: chan 116a -> 120a [passive, dwell min 20 max 200] Jul 19 11:14:57 slan kernel: ath0: scan_next: chan 120a -> 124a [passive, dwell min 20 max 200] Jul 19 11:14:57 slan kernel: ath0: scan_next: chan 124a -> 128a [passive, dwell min 20 max 200] Jul 19 11:14:58 slan kernel: ath0: scan_next: chan 128a -> 132a [passive, dwell min 20 max 200] Jul 19 11:14:58 slan kernel: ath0: scan_next: chan 132a -> 136a [passive, dwell min 20 max 200] Jul 19 11:14:58 slan kernel: ath0: scan_next: chan 136a -> 140a [passive, dwell min 20 max 200] Jul 19 11:14:58 slan kernel: ath0: macaddr bssid chan rssi rate flag wep essid Jul 19 11:14:58 slan kernel: - 00:14:6a:07:b9:00 00:14:6a:07:b9:00 6 47 54M ess no! "fgz" Jul 19 11:14:58 slan kernel: - 00:16:46:b8:d0:80 00:16:46:b8:d0:80 11 29 54M ess no! "fgz" Jul 19 11:14:58 slan kernel: ^ 00:16:46:b8:bf:10 00:16:46:b8:bf:10 7 4! 54M ess no! "fgz" Jul 19 11:14:58 slan kernel: ^ 00:1a:e2:10:70:c0 00:1a:e2:10:70:c0 3 8 54M ess no! "fgz" Jul 19 11:14:58 slan kernel: - 00:16:46:b8:d4:60 00:16:46:b8:d4:60 4 1! 54M ess no! "fgz" Jul 19 11:14:58 slan kernel: - 00:0a:b8:7e:ff:70 00:0a:b8:7e:ff:70 5 47 54M ess no! "fgz" Jul 19 11:14:58 slan kernel: - 00:16:46:b8:b4:c0 00:16:46:b8:b4:c0 9 4! 54M ess no! "fgz" Jul 19 11:14:58 slan kernel: - 00:16:46:b8:c7:e0 00:16:46:b8:c7:e0 10 4! 54M ess no! "fgz" Jul 19 11:14:58 slan kernel: ^ 00:16:46:b8:bf:50 00:16:46:b8:bf:50 3 3! 54M ess no! "fgz" Jul 19 11:14:58 slan kernel: - 00:1a:e2:10:6d:70 00:1a:e2:10:6d:70 10 16 54M ess no! "fgz" Jul 19 11:14:58 slan kernel: ath0: scan_next: done, restart [ticks 219393, dwell min 20 scanend 2147658823] Jul 19 11:14:58 slan kernel: ath0: scan_next: chan 140a -> 1g [active, dwell min 20 max 200] Jul 19 11:14:58 slan kernel: [00:1b:2a:ab:c4:00] new beacon on chan 1 (bss chan 1) "fgz" Jul 19 11:14:58 slan kernel: [00:1b:2a:ab:c4:00] caps 0x21 bintval 100 erp 0x7 Jul 19 11:14:58 slan kernel: ath0: ieee80211_add_scan: chan 1g min dwell met (219593 > 219417) Jul 19 11:14:58 slan kernel: ath0: scan_next: chan 1g -> 6g [active, dwell min 20 max 200] Jul 19 11:14:59 slan kernel: [00:14:6a:07:b9:00] new probe_resp on chan 6 (bss chan 6) "fgz" Jul 19 11:14:59 slan kernel: [00:14:6a:07:b9:00] caps 0x801 bintval 99 erp 0x7 Jul 19 11:14:59 slan kernel: [00:14:6a:07:b9:00] new beacon on chan 6 (bss chan 6) "fgz" Jul 19 11:14:59 slan kernel: [00:14:6a:07:b9:00] caps 0x801 bintval 99 erp 0x7 Jul 19 11:14:59 slan kernel: ath0: ieee80211_add_scan: chan 6g min dwell met (219639 > 219618) Jul 19 11:14:59 slan kernel: ath0: scan_next: chan 6g -> 11g [active, dwell min 20 max 200] Jul 19 11:14:59 slan kernel: [00:16:46:b8:d0:80] new probe_resp on chan 11 (bss chan 11) "fgz" Jul 19 11:14:59 slan kernel: [00:16:46:b8:d0:80] caps 0xc01 bintval 99 erp 0x2 Jul 19 11:14:59 slan kernel: [00:16:46:b8:d0:80] new beacon on chan 11 (bss chan 11) "fgz" Jul 19 11:14:59 slan kernel: [00:16:46:b8:d0:80] caps 0xc01 bintval 99 erp 0x2 Jul 19 11:14:59 slan kernel: [00:16:46:b8:d0:80] new beacon on chan 11 (bss chan 11) "fgz" Jul 19 11:14:59 slan kernel: [00:16:46:b8:d0:80] caps 0xc01 bintval 99 erp 0x2 Jul 19 11:14:59 slan kernel: ath0: ieee80211_add_scan: chan 11g min dwell met (219763 > 219664) Jul 19 11:14:59 slan kernel: ath0: scan_next: chan 11g -> 7g [active, dwell min 20 max 200] Jul 19 11:14:59 slan kernel: ath0: scan_next: chan 7g -> 52a [passive, dwell min 20 max 200] Jul 19 11:14:59 slan kernel: ath0: scan_next: chan 52a -> 56a [passive, dwell min 20 max 200] Jul 19 11:14:59 slan kernel: ath0: scan_next: chan 56a -> 60a [passive, dwell min 20 max 200] Jul 19 11:14:59 slan kernel: ath0: scan_next: chan 60a -> 64a [passive, dwell min 20 max 200] Jul 19 11:15:00 slan kernel: ath0: scan_next: chan 64a -> 36a [passive, dwell min 20 max 200] Jul 19 11:15:00 slan kernel: ath0: scan_next: chan 36a -> 40a [passive, dwell min 20 max 200] Jul 19 11:15:00 slan kernel: ath0: scan_next: chan 40a -> 44a [passive, dwell min 20 max 200] Jul 19 11:15:00 slan kernel: ath0: scan_next: chan 44a -> 48a [passive, dwell min 20 max 200] Jul 19 11:15:00 slan kernel: ath0: scan_next: chan 48a -> 34a [passive, dwell min 20 max 200] Jul 19 11:15:01 slan kernel: ath0: scan_next: chan 34a -> 38a [passive, dwell min 20 max 200] Jul 19 11:15:01 slan kernel: ath0: scan_next: chan 38a -> 42a [passive, dwell min 20 max 200] Jul 19 11:15:01 slan kernel: ath0: scan_next: chan 42a -> 46a [passive, dwell min 20 max 200] Jul 19 11:15:01 slan kernel: ath0: scan_next: chan 46a -> 2g [active, dwell min 20 max 200] Jul 19 11:15:01 slan kernel: ath0: scan_next: chan 2g -> 3g [active, dwell min 20 max 200] Jul 19 11:15:02 slan kernel: [00:1a:e2:10:70:c0] new beacon on chan 3 (bss chan 3) "fgz" Jul 19 11:15:02 slan kernel: [00:1a:e2:10:70:c0] caps 0x1 bintval 99 erp 0x7 Jul 19 11:15:02 slan kernel: ath0: ieee80211_add_scan: chan 3g min dwell met (222725 > 222644) Jul 19 11:15:02 slan kernel: ath0: scan_next: chan 3g -> 4g [active, dwell min 20 max 200] Jul 19 11:15:02 slan kernel: ath0: scan_next: chan 4g -> 5g [active, dwell min 20 max 200] Jul 19 11:15:02 slan kernel: [00:0a:b8:7e:ff:70] new probe_resp on chan 5 (bss chan 5) "fgz" Jul 19 11:15:02 slan kernel: [00:0a:b8:7e:ff:70] caps 0x801 bintval 99 erp 0x7 Jul 19 11:15:02 slan kernel: [00:0a:b8:7e:ff:70] new beacon on chan 5 (bss chan 5) "fgz" Jul 19 11:15:02 slan kernel: [00:0a:b8:7e:ff:70] caps 0x801 bintval 99 erp 0x7 Jul 19 11:15:02 slan kernel: ath0: ieee80211_add_scan: chan 5g min dwell met (223007 > 222954) Jul 19 11:15:02 slan kernel: ath0: scan_next: chan 5g -> 8g [active, dwell min 20 max 200] Jul 19 11:15:02 slan kernel: ath0: scan_next: chan 8g -> 9g [active, dwell min 20 max 200] Jul 19 11:15:02 slan kernel: ath0: scan_next: chan 9g -> 10g [active, dwell min 20 max 200] Jul 19 11:15:02 slan kernel: ath0: scan_next: chan 10g -> 149a [passive, dwell min 20 max 200] Jul 19 11:15:03 slan kernel: ath0: scan_next: chan 149a -> 153a [passive, dwell min 20 max 200] Jul 19 11:15:03 slan kernel: ath0: scan_next: chan 153a -> 157a [passive, dwell min 20 max 200] Jul 19 11:15:03 slan kernel: ath0: scan_next: chan 157a -> 161a [passive, dwell min 20 max 200] Jul 19 11:15:03 slan kernel: ath0: scan_next: chan 161a -> 165a [passive, dwell min 20 max 200] Jul 19 11:15:03 slan kernel: ath0: scan_next: chan 165a -> 100a [passive, dwell min 20 max 200] Jul 19 11:15:04 slan kernel: ath0: scan_next: chan 100a -> 104a [passive, dwell min 20 max 200] Jul 19 11:15:04 slan kernel: ath0: scan_next: chan 104a -> 108a [passive, dwell min 20 max 200] Jul 19 11:15:04 slan kernel: ath0: scan_next: chan 108a -> 112a [passive, dwell min 20 max 200] Jul 19 11:15:04 slan kernel: ath0: scan_next: chan 112a -> 116a [passive, dwell min 20 max 200] Jul 19 11:15:04 slan kernel: ath0: scan_next: chan 116a -> 120a [passive, dwell min 20 max 200] Jul 19 11:15:05 slan kernel: ath0: scan_next: chan 120a -> 124a [passive, dwell min 20 max 200] Jul 19 11:15:05 slan kernel: ath0: scan_next: chan 124a -> 128a [passive, dwell min 20 max 200] Jul 19 11:15:05 slan kernel: ath0: scan_next: chan 128a -> 132a [passive, dwell min 20 max 200] Jul 19 11:15:05 slan kernel: ath0: scan_next: chan 132a -> 136a [passive, dwell min 20 max 200] Jul 19 11:15:05 slan kernel: ath0: scan_next: chan 136a -> 140a [passive, dwell min 20 max 200] Jul 19 11:15:06 slan kernel: ath0: macaddr bssid chan rssi rate flag wep essid Jul 19 11:15:06 slan kernel: - 00:14:6a:07:b9:00 00:14:6a:07:b9:00 6 49 54M ess no! "fgz" Jul 19 11:15:06 slan kernel: - 00:16:46:b8:d0:80 00:16:46:b8:d0:80 11 29 54M ess no! "fgz" Jul 19 11:15:06 slan kernel: ^ 00:16:46:b8:bf:10 00:16:46:b8:bf:10 7 4! 54M ess no! "fgz" Jul 19 11:15:06 slan kernel: - 00:1a:e2:10:70:c0 00:1a:e2:10:70:c0 3 8 54M ess no! "fgz" Jul 19 11:15:06 slan kernel: - 00:16:46:b8:d4:60 00:16:46:b8:d4:60 4 1! 54M ess no! "fgz" Jul 19 11:15:06 slan kernel: - 00:0a:b8:7e:ff:70 00:0a:b8:7e:ff:70 5 47 54M ess no! "fgz" Jul 19 11:15:06 slan kernel: - 00:16:46:b8:b4:c0 00:16:46:b8:b4:c0 9 4! 54M ess no! "fgz" Jul 19 11:15:06 slan kernel: - 00:16:46:b8:c7:e0 00:16:46:b8:c7:e0 10 4! 54M ess no! "fgz" Jul 19 11:15:06 slan kernel: ^ 00:16:46:b8:bf:50 00:16:46:b8:bf:50 3 3! 54M ess no! "fgz" Jul 19 11:15:06 slan kernel: ^ 00:1a:e2:10:6d:70 00:1a:e2:10:6d:70 10 16 54M ess no! "fgz" Jul 19 11:15:06 slan kernel: - 00:1b:2a:ab:c4:00 00:1b:2a:ab:c4:00 1 7! 54M ess no! "fgz" Jul 19 11:15:06 slan kernel: ath0: scan_next: done, restart [ticks 226884, dwell min 20 scanend 2147658823] Jul 19 11:15:06 slan kernel: ath0: scan_next: chan 140a -> 1g [active, dwell min 20 max 200] Jul 19 11:15:06 slan kernel: [00:1b:2a:ab:c4:00] new beacon on chan 1 (bss chan 1) "fgz" Jul 19 11:15:06 slan kernel: [00:1b:2a:ab:c4:00] caps 0x21 bintval 100 erp 0x7 Jul 19 11:15:06 slan kernel: ath0: ieee80211_add_scan: chan 1g min dwell met (227069 > 226908) Jul 19 11:15:06 slan kernel: ath0: scan_next: chan 1g -> 6g [active, dwell min 20 max 200] Jul 19 11:15:06 slan kernel: [00:14:6a:07:b9:00] new probe_resp on chan 6 (bss chan 6) "fgz" Jul 19 11:15:06 slan kernel: [00:14:6a:07:b9:00] caps 0x801 bintval 99 erp 0x7 Jul 19 11:15:06 slan kernel: [00:14:6a:07:b9:00] new beacon on chan 6 (bss chan 6) "fgz" Jul 19 11:15:06 slan kernel: [00:14:6a:07:b9:00] caps 0x801 bintval 99 erp 0x7 Jul 19 11:15:06 slan kernel: ath0: ieee80211_add_scan: chan 6g min dwell met (227142 > 227094) Jul 19 11:15:06 slan kernel: ath0: scan_next: chan 6g -> 11g [active, dwell min 20 max 200] Jul 19 11:15:06 slan kernel: [00:16:46:b8:d0:80] new probe_resp on chan 11 (bss chan 11) "fgz" Jul 19 11:15:06 slan kernel: [00:16:46:b8:d0:80] caps 0xc01 bintval 99 erp 0x2 Jul 19 11:15:06 slan kernel: [00:16:46:b8:d0:80] new beacon on chan 11 (bss chan 11) "fgz" Jul 19 11:15:06 slan kernel: [00:16:46:b8:d0:80] caps 0xc01 bintval 99 erp 0x2 Jul 19 11:15:06 slan kernel: [00:0f:f7:48:ac:80] new beacon on chan 11 (bss chan 11) "fgz" Jul 19 11:15:06 slan kernel: [00:0f:f7:48:ac:80] caps 0xc01 bintval 100 erp 0x2 Jul 19 11:15:06 slan kernel: ath0: ieee80211_add_scan: chan 11g min dwell met (227215 > 227167) Jul 19 11:15:06 slan kernel: ath0: scan_next: chan 11g -> 7g [active, dwell min 20 max 200] Jul 19 11:15:06 slan kernel: ath0: scan_next: chan 7g -> 52a [passive, dwell min 20 max 200] Jul 19 11:15:06 slan kernel: ath0: scan_next: chan 52a -> 56a [passive, dwell min 20 max 200] Jul 19 11:15:07 slan kernel: ath0: scan_next: chan 56a -> 60a [passive, dwell min 20 max 200] Jul 19 11:15:07 slan kernel: ath0: scan_next: chan 60a -> 64a [passive, dwell min 20 max 200] Jul 19 11:15:07 slan kernel: ath0: scan_next: chan 64a -> 36a [passive, dwell min 20 max 200] Jul 19 11:15:07 slan kernel: ath0: scan_next: chan 36a -> 40a [passive, dwell min 20 max 200] Jul 19 11:15:07 slan kernel: ath0: scan_next: chan 40a -> 44a [passive, dwell min 20 max 200] Jul 19 11:15:08 slan kernel: ath0: scan_next: chan 44a -> 48a [passive, dwell min 20 max 200] Jul 19 11:15:08 slan kernel: ath0: scan_next: chan 48a -> 34a [passive, dwell min 20 max 200] Jul 19 11:15:08 slan kernel: ath0: scan_next: chan 34a -> 38a [passive, dwell min 20 max 200] Jul 19 11:15:08 slan kernel: ath0: scan_next: chan 38a -> 42a [passive, dwell min 20 max 200] Jul 19 11:15:08 slan kernel: ath0: scan_next: chan 42a -> 46a [passive, dwell min 20 max 200] Jul 19 11:15:09 slan kernel: ath0: scan_next: chan 46a -> 2g [active, dwell min 20 max 200] Jul 19 11:15:09 slan kernel: ath0: scan_next: chan 2g -> 3g [active, dwell min 20 max 200] Jul 19 11:15:09 slan kernel: ath0: scan_next: chan 3g -> 4g [active, dwell min 20 max 200] Jul 19 11:15:09 slan kernel: ath0: scan_next: chan 4g -> 5g [active, dwell min 20 max 200] Jul 19 11:15:09 slan kernel: [00:0a:b8:7e:ff:70] new probe_resp on chan 5 (bss chan 5) "fgz" Jul 19 11:15:09 slan kernel: [00:0a:b8:7e:ff:70] caps 0x801 bintval 99 erp 0x7 Jul 19 11:15:09 slan kernel: [00:0a:b8:7e:ff:70] new beacon on chan 5 (bss chan 5) "fgz" Jul 19 11:15:09 slan kernel: [00:0a:b8:7e:ff:70] caps 0x801 bintval 99 erp 0x7 Jul 19 11:15:09 slan kernel: ath0: ieee80211_add_scan: chan 5g min dwell met (230510 > 230504) Jul 19 11:15:09 slan kernel: ath0: scan_next: chan 5g -> 8g [active, dwell min 20 max 200] Jul 19 11:15:10 slan kernel: ath0: scan_next: chan 8g -> 9g [active, dwell min 20 max 200] Jul 19 11:15:10 slan kernel: [00:16:46:b8:b4:c0] new beacon on chan 9 (bss chan 9) "fgz" Jul 19 11:15:10 slan kernel: [00:16:46:b8:b4:c0] caps 0xc01 bintval 99 erp 0x2 Jul 19 11:15:10 slan kernel: ath0: ieee80211_add_scan: chan 9g min dwell met (230772 > 230739) Jul 19 11:15:10 slan kernel: ath0: scan_next: chan 9g -> 10g [active, dwell min 20 max 200] Jul 19 11:15:10 slan kernel: [00:1a:e2:10:6d:70] new beacon on chan 10 (bss chan 10) "fgz" Jul 19 11:15:10 slan kernel: [00:1a:e2:10:6d:70] caps 0x1 bintval 99 erp 0x7 Jul 19 11:15:10 slan kernel: ath0: scan_next: chan 10g -> 149a [passive, dwell min 20 max 200] Jul 19 11:15:10 slan kernel: ath0: scan_next: chan 149a -> 153a [passive, dwell min 20 max 200] Jul 19 11:15:10 slan kernel: ath0: scan_next: chan 153a -> 157a [passive, dwell min 20 max 200] Jul 19 11:15:10 slan kernel: ath0: scan_next: chan 157a -> 161a [passive, dwell min 20 max 200] Jul 19 11:15:11 slan kernel: ath0: scan_next: chan 161a -> 165a [passive, dwell min 20 max 200] Jul 19 11:15:11 slan kernel: ath0: scan_next: chan 165a -> 100a [passive, dwell min 20 max 200] Jul 19 11:15:11 slan kernel: ath0: scan_next: chan 100a -> 104a [passive, dwell min 20 max 200] Jul 19 11:15:11 slan kernel: ath0: scan_next: chan 104a -> 108a [passive, dwell min 20 max 200] Jul 19 11:15:11 slan kernel: ath0: scan_next: chan 108a -> 112a [passive, dwell min 20 max 200] Jul 19 11:15:12 slan kernel: ath0: scan_next: chan 112a -> 116a [passive, dwell min 20 max 200] Jul 19 11:15:12 slan kernel: ath0: scan_next: chan 116a -> 120a [passive, dwell min 20 max 200] Jul 19 11:15:12 slan kernel: ath0: scan_next: chan 120a -> 124a [passive, dwell min 20 max 200] Jul 19 11:15:12 slan kernel: ath0: scan_next: chan 124a -> 128a [passive, dwell min 20 max 200] Jul 19 11:15:12 slan kernel: ath0: scan_next: chan 128a -> 132a [passive, dwell min 20 max 200] Jul 19 11:15:13 slan kernel: ath0: scan_next: chan 132a -> 136a [passive, dwell min 20 max 200] Jul 19 11:15:13 slan kernel: ath0: scan_next: chan 136a -> 140a [passive, dwell min 20 max 200] Jul 19 11:15:13 slan kernel: ath0: macaddr bssid chan rssi rate flag wep essid Jul 19 11:15:13 slan kernel: - 00:14:6a:07:b9:00 00:14:6a:07:b9:00 6 49 54M ess no! "fgz" Jul 19 11:15:13 slan kernel: - 00:16:46:b8:d0:80 00:16:46:b8:d0:80 11 29 54M ess no! "fgz" Jul 19 11:15:13 slan kernel: ^ 00:16:46:b8:bf:10 00:16:46:b8:bf:10 7 4! 54M ess no! "fgz" Jul 19 11:15:13 slan kernel: - 00:1a:e2:10:70:c0 00:1a:e2:10:70:c0 3 8 54M ess no! "fgz" Jul 19 11:15:13 slan kernel: ^ 00:16:46:b8:d4:60 00:16:46:b8:d4:60 4 1! 54M ess no! "fgz" Jul 19 11:15:13 slan kernel: - 00:0a:b8:7e:ff:70 00:0a:b8:7e:ff:70 5 47 54M ess no! "fgz" Jul 19 11:15:13 slan kernel: - 00:16:46:b8:b4:c0 00:16:46:b8:b4:c0 9 5! 54M ess no! "fgz" Jul 19 11:15:13 slan kernel: ^ 00:16:46:b8:c7:e0 00:16:46:b8:c7:e0 10 4! 54M ess no! "fgz" Jul 19 11:15:13 slan kernel: ^ 00:16:46:b8:bf:50 00:16:46:b8:bf:50 3 3! 54M ess no! "fgz" Jul 19 11:15:13 slan kernel: - 00:1a:e2:10:6d:70 00:1a:e2:10:6d:70 10 16 54M ess no! "fgz" Jul 19 11:15:13 slan kernel: - 00:1b:2a:ab:c4:00 00:1b:2a:ab:c4:00 1 7! 54M ess no! "fgz" Jul 19 11:15:13 slan kernel: - 00:0f:f7:48:ac:80 00:0f:f7:48:ac:80 11 1! 54M ess no! "fgz" Jul 19 11:15:13 slan kernel: ath0: scan_next: done, restart [ticks 234241, dwell min 20 scanend 2147658823] Jul 19 11:15:13 slan kernel: ath0: scan_next: chan 140a -> 1g [active, dwell min 20 max 200] Jul 19 11:15:13 slan kernel: ath0: scan_next: chan 1g -> 6g [active, dwell min 20 max 200] Jul 19 11:15:13 slan kernel: [00:14:6a:07:b9:00] new probe_resp on chan 6 (bss chan 6) "fgz" Jul 19 11:15:13 slan kernel: [00:14:6a:07:b9:00] caps 0x801 bintval 99 erp 0x7 Jul 19 11:15:13 slan kernel: [00:14:6a:07:b9:00] new beacon on chan 6 (bss chan 6) "fgz" Jul 19 11:15:13 slan kernel: [00:14:6a:07:b9:00] caps 0x801 bintval 99 erp 0x7 Jul 19 11:15:13 slan kernel: ath0: ieee80211_add_scan: chan 6g min dwell met (234544 > 234469) Jul 19 11:15:13 slan kernel: ath0: scan_next: chan 6g -> 11g [active, dwell min 20 max 200] Jul 19 11:15:13 slan kernel: [00:16:46:b8:d0:80] new probe_resp on chan 11 (bss chan 11) "fgz" Jul 19 11:15:13 slan kernel: [00:16:46:b8:d0:80] caps 0xc01 bintval 99 erp 0x2 Jul 19 11:15:13 slan kernel: [00:16:46:b8:d0:80] new beacon on chan 11 (bss chan 11) "fgz" Jul 19 11:15:13 slan kernel: [00:16:46:b8:d0:80] caps 0xc01 bintval 99 erp 0x2 Jul 19 11:15:13 slan kernel: [00:16:46:b8:d0:80] new beacon on chan 11 (bss chan 11) "fgz" Jul 19 11:15:13 slan kernel: [00:16:46:b8:d0:80] caps 0xc01 bintval 99 erp 0x2 Jul 19 11:15:13 slan kernel: ath0: ieee80211_add_scan: chan 11g min dwell met (234668 > 234569) Jul 19 11:15:13 slan kernel: ath0: scan_next: chan 11g -> 7g [active, dwell min 20 max 200] Jul 19 11:15:14 slan kernel: ath0: scan_next: chan 7g -> 52a [passive, dwell min 20 max 200] Jul 19 11:15:14 slan kernel: ath0: scan_next: chan 52a -> 56a [passive, dwell min 20 max 200] Jul 19 11:15:14 slan kernel: ath0: scan_next: chan 56a -> 60a [passive, dwell min 20 max 200] Jul 19 11:15:14 slan kernel: ath0: scan_next: chan 60a -> 64a [passive, dwell min 20 max 200] Jul 19 11:15:14 slan kernel: ath0: scan_next: chan 64a -> 36a [passive, dwell min 20 max 200] Jul 19 11:15:15 slan kernel: ath0: scan_next: chan 36a -> 40a [passive, dwell min 20 max 200] Jul 19 11:15:15 slan kernel: ath0: scan_next: chan 40a -> 44a [passive, dwell min 20 max 200] Jul 19 11:15:15 slan kernel: ath0: scan_next: chan 44a -> 48a [passive, dwell min 20 max 200] Jul 19 11:15:15 slan kernel: ath0: scan_next: chan 48a -> 34a [passive, dwell min 20 max 200] Jul 19 11:15:15 slan kernel: ath0: scan_next: chan 34a -> 38a [passive, dwell min 20 max 200] Jul 19 11:15:16 slan kernel: ath0: scan_next: chan 38a -> 42a [passive, dwell min 20 max 200] Jul 19 11:15:16 slan kernel: ath0: scan_next: chan 42a -> 46a [passive, dwell min 20 max 200] Jul 19 11:15:16 slan kernel: ath0: scan_next: chan 46a -> 2g [active, dwell min 20 max 200] Jul 19 11:15:16 slan kernel: ath0: scan_next: chan 2g -> 3g [active, dwell min 20 max 200] Jul 19 11:15:16 slan kernel: ath0: scan_next: chan 3g -> 4g [active, dwell min 20 max 200] Jul 19 11:15:17 slan kernel: ath0: scan_next: chan 4g -> 5g [active, dwell min 20 max 200] Jul 19 11:15:17 slan kernel: [00:0a:b8:7e:ff:70] new probe_resp on chan 5 (bss chan 5) "fgz" Jul 19 11:15:17 slan kernel: [00:0a:b8:7e:ff:70] caps 0x801 bintval 99 erp 0x7 Jul 19 11:15:17 slan kernel: [00:0a:b8:7e:ff:70] new beacon on chan 5 (bss chan 5) "fgz" Jul 19 11:15:17 slan kernel: [00:0a:b8:7e:ff:70] caps 0x801 bintval 99 erp 0x7 Jul 19 11:15:17 slan kernel: ath0: ieee80211_add_scan: chan 5g min dwell met (238013 > 237957) Jul 19 11:15:17 slan kernel: ath0: scan_next: chan 5g -> 8g [active, dwell min 20 max 200] Jul 19 11:15:17 slan kernel: ath0: scan_next: chan 8g -> 9g [active, dwell min 20 max 200] Jul 19 11:15:17 slan kernel: ath0: ieee80211_cancel_scan: cancel active scan Jul 19 11:15:17 slan kernel: ath0: ieee80211_scan_flush Jul 19 11:15:17 slan kernel: ath0: scan_next: done, [ticks 238305, dwell min 20 scanend 2147658823] Jul 19 11:15:17 slan kernel: ath0: notify scan done Jul 19 11:15:17 slan dhclient[1265]: connection closed Jul 19 11:15:17 slan dhclient[1265]: exiting. Jul 19 11:15:17 slan kernel: ath0: ieee80211_start_scan: active scan, duration 2147483647, desired mode auto, append, nopick, once Jul 19 11:15:17 slan kernel: ath0: scan set 1g, 6g, 11g, 7g, 52a, 56a, 60a, 64a, 36a, 40a, 44a, 48a, 34a, 38a, 42a, 46a, 2g, 3g, 4g, 5g, 8g, 9g, 10g, 149a, 153a, 157a, 161a, 165a, 100a, 104a, 108a, 112a, 116a, 120a, 124a, 128a, 132a, 136a, 140a dwell min 20 max 200 Jul 19 11:15:17 slan kernel: ath0: scan_next: chan 9g -> 1g [active, dwell min 20 max 200] Jul 19 11:15:17 slan kernel: ath0: scan_next: chan 1g -> 6g [active, dwell min 20 max 200] Jul 19 11:15:17 slan kernel: [00:14:6a:07:b9:00] new probe_resp on chan 6 (bss chan 6) "fgz" Jul 19 11:15:17 slan kernel: [00:14:6a:07:b9:00] caps 0x801 bintval 99 erp 0x7 Jul 19 11:15:17 slan kernel: [00:14:6a:07:b9:00] new beacon on chan 6 (bss chan 6) "fgz" Jul 19 11:15:17 slan kernel: [00:14:6a:07:b9:00] caps 0x801 bintval 99 erp 0x7 Jul 19 11:15:17 slan kernel: ath0: ieee80211_add_scan: chan 6g min dwell met (238701 > 238664) Jul 19 11:15:17 slan kernel: ath0: scan_next: chan 6g -> 11g [active, dwell min 20 max 200] Jul 19 11:15:17 slan kernel: [00:16:46:b8:d0:80] new probe_resp on chan 11 (bss chan 11) "fgz" Jul 19 11:15:17 slan kernel: [00:16:46:b8:d0:80] caps 0xc01 bintval 99 erp 0x2 Jul 19 11:15:17 slan kernel: [00:16:46:b8:d0:80] new beacon on chan 11 (bss chan 11) "fgz" Jul 19 11:15:17 slan kernel: [00:16:46:b8:d0:80] caps 0xc01 bintval 99 erp 0x2 Jul 19 11:15:18 slan kernel: [00:16:46:b8:d0:80] new beacon on chan 11 (bss chan 11) "fgz" Jul 19 11:15:18 slan kernel: [00:16:46:b8:d0:80] caps 0xc01 bintval 99 erp 0x2 Jul 19 11:15:18 slan kernel: ath0: ieee80211_add_scan: chan 11g min dwell met (238826 > 238726) Jul 19 11:15:18 slan kernel: ath0: scan_next: chan 11g -> 7g [active, dwell min 20 max 200] Jul 19 11:15:18 slan kernel: ath0: scan_next: chan 7g -> 52a [passive, dwell min 20 max 200] Jul 19 11:15:18 slan kernel: ath0: scan_next: chan 52a -> 56a [passive, dwell min 20 max 200] Jul 19 11:15:18 slan kernel: ath0: scan_next: chan 56a -> 60a [passive, dwell min 20 max 200] Jul 19 11:15:18 slan kernel: ath0: scan_next: chan 60a -> 64a [passive, dwell min 20 max 200] Jul 19 11:15:19 slan kernel: ath0: scan_next: chan 64a -> 36a [passive, dwell min 20 max 200] Jul 19 11:15:19 slan kernel: ath0: scan_next: chan 36a -> 40a [passive, dwell min 20 max 200] Jul 19 11:15:19 slan kernel: ath0: scan_next: chan 40a -> 44a [passive, dwell min 20 max 200] Jul 19 11:15:19 slan kernel: ath0: scan_next: chan 44a -> 48a [passive, dwell min 20 max 200] Jul 19 11:15:19 slan kernel: ath0: scan_next: chan 48a -> 34a [passive, dwell min 20 max 200] Jul 19 11:15:20 slan kernel: ath0: scan_next: chan 34a -> 38a [passive, dwell min 20 max 200] Jul 19 11:15:20 slan kernel: ath0: scan_next: chan 38a -> 42a [passive, dwell min 20 max 200] Jul 19 11:15:20 slan kernel: ath0: scan_next: chan 42a -> 46a [passive, dwell min 20 max 200] Jul 19 11:15:20 slan kernel: ath0: scan_next: chan 46a -> 2g [active, dwell min 20 max 200] Jul 19 11:15:20 slan kernel: ath0: scan_next: chan 2g -> 3g [active, dwell min 20 max 200] Jul 19 11:15:21 slan kernel: ath0: scan_next: chan 3g -> 4g [active, dwell min 20 max 200] Jul 19 11:15:21 slan kernel: ath0: scan_next: chan 4g -> 5g [active, dwell min 20 max 200] Jul 19 11:15:21 slan kernel: [00:0a:b8:7e:ff:70] new probe_resp on chan 5 (bss chan 5) "fgz" Jul 19 11:15:21 slan kernel: [00:0a:b8:7e:ff:70] caps 0x801 bintval 99 erp 0x7 Jul 19 11:15:21 slan kernel: [00:0a:b8:7e:ff:70] new beacon on chan 5 (bss chan 5) "fgz" Jul 19 11:15:21 slan kernel: [00:0a:b8:7e:ff:70] caps 0x801 bintval 99 erp 0x7 Jul 19 11:15:21 slan kernel: ath0: ieee80211_add_scan: chan 5g min dwell met (242170 > 242115) Jul 19 11:15:21 slan kernel: ath0: scan_next: chan 5g -> 8g [active, dwell min 20 max 200] Jul 19 11:15:21 slan kernel: ath0: scan_next: chan 8g -> 9g [active, dwell min 20 max 200] Jul 19 11:15:21 slan kernel: ath0: scan_next: chan 9g -> 10g [active, dwell min 20 max 200] Jul 19 11:15:21 slan kernel: [00:1a:e2:10:6d:70] new beacon on chan 10 (bss chan 10) "fgz" Jul 19 11:15:21 slan kernel: [00:1a:e2:10:6d:70] caps 0x1 bintval 99 erp 0x7 Jul 19 11:15:21 slan kernel: ath0: ieee80211_add_scan: chan 10g min dwell met (242654 > 242603) Jul 19 11:15:21 slan kernel: ath0: scan_next: chan 10g -> 149a [passive, dwell min 20 max 200] Jul 19 11:15:22 slan kernel: ath0: scan_next: chan 149a -> 153a [passive, dwell min 20 max 200] Jul 19 11:15:22 slan kernel: ath0: scan_next: chan 153a -> 157a [passive, dwell min 20 max 200] Jul 19 11:15:22 slan kernel: ath0: scan_next: chan 157a -> 161a [passive, dwell min 20 max 200] Jul 19 11:15:22 slan kernel: ath0: scan_next: chan 161a -> 165a [passive, dwell min 20 max 200] Jul 19 11:15:22 slan kernel: ath0: scan_next: chan 165a -> 100a [passive, dwell min 20 max 200] Jul 19 11:15:23 slan kernel: ath0: scan_next: chan 100a -> 104a [passive, dwell min 20 max 200] Jul 19 11:15:23 slan kernel: ath0: scan_next: chan 104a -> 108a [passive, dwell min 20 max 200] Jul 19 11:15:23 slan kernel: ath0: scan_next: chan 108a -> 112a [passive, dwell min 20 max 200] Jul 19 11:15:23 slan kernel: ath0: scan_next: chan 112a -> 116a [passive, dwell min 20 max 200] Jul 19 11:15:23 slan kernel: ath0: scan_next: chan 116a -> 120a [passive, dwell min 20 max 200] Jul 19 11:15:24 slan kernel: ath0: scan_next: chan 120a -> 124a [passive, dwell min 20 max 200] Jul 19 11:15:24 slan kernel: ath0: scan_next: chan 124a -> 128a [passive, dwell min 20 max 200] Jul 19 11:15:24 slan kernel: ath0: scan_next: chan 128a -> 132a [passive, dwell min 20 max 200] Jul 19 11:15:24 slan kernel: ath0: scan_next: chan 132a -> 136a [passive, dwell min 20 max 200] Jul 19 11:15:24 slan kernel: ath0: scan_next: chan 136a -> 140a [passive, dwell min 20 max 200] Jul 19 11:15:25 slan kernel: ath0: scan_next: done, [ticks 245919, dwell min 20 scanend 2147722082] Jul 19 11:15:25 slan kernel: ath0: notify scan done Jul 19 11:15:25 slan kernel: ath0: [00:14:6a:07:b9:00] recv auth frame with algorithm 0 seq 2 Jul 19 11:15:25 slan kernel: ath0: [00:14:6a:07:b9:00] assoc success: long preamble, short slot time, protection Jul 19 11:15:25 slan kernel: ath0: [00:14:6a:07:b9:00] ieee80211_scan_assoc_success Jul 19 11:15:25 slan kernel: ath0: link state changed to UP Jul 19 11:15:25 slan dhclient: New IP Address (ath0): 131.225.96.86 Jul 19 11:15:25 slan dhclient: New Subnet Mask (ath0): 255.255.254.0 Jul 19 11:15:25 slan dhclient: New Broadcast Address (ath0): 131.225.97.255 Jul 19 11:15:25 slan dhclient: New Routers (ath0): 131.225.97.200 Jul 19 11:15:25 slan kernel: ath0: [00:14:6a:07:b9:00] capabilities change: before 0x401, now 0x801 Jul 19 11:16:23 slan kernel: ipfw: limit 100 reached on entry 64000 --==_Exmh_1184872580_559980-- --==_Exmh_1184872599_55998P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) Comment: Exmh version 2.5 06/03/2002 iD8DBQFGn7iXkn3rs5h7N1ERAl0vAJ928jz8NTfhcqCObjqIMUDX7fPlMwCcCgkr g5MVDSuBixm0an7H+Cb+GeU= =uw/5 -----END PGP SIGNATURE----- --==_Exmh_1184872599_55998P-- From owner-freebsd-current@FreeBSD.ORG Thu Jul 19 22:59:17 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8060A16A469 for ; Thu, 19 Jul 2007 22:59:17 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.freebsd.org (Postfix) with ESMTP id 6355713C461 for ; Thu, 19 Jul 2007 22:59:17 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.1/8.14.1) with ESMTP id l6JMxG3L005895 for ; Thu, 19 Jul 2007 15:59:16 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.1/8.14.1/Submit) id l6JMxG2g005894 for freebsd-current@freebsd.org; Thu, 19 Jul 2007 15:59:16 -0700 (PDT) (envelope-from sgk) Date: Thu, 19 Jul 2007 15:59:16 -0700 From: Steve Kargl To: freebsd-current@freebsd.org Message-ID: <20070719225916.GA46703@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Subject: panic: _mtx_lock_sleep ... ahc_lock X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Jul 2007 22:59:17 -0000 While taking the Xorg 7.2 upgrade plunge on my newly installed ULE driven box. I got the following panic. panic: _mtx_lock_sleep: recursed on non-recursive mutex ahc_lock@/usr/src/sys/dev/aic7xxx/aic7xxx_osm.h:203 cpuid = 0 Uptime: 12s panic: _mtx_lock_sleep: recursed on non-recursive mutex ahc_lock@/usr/src/sys/cam/cam_periph.h:182 At this point, the keyboard was locked up so getting a backtrace wasn't possible. The relevant lines from dmesg are ahc0: port 0xb800-0xb8ff mem 0xfeafe000-0xfeafefff irq 16 at device 4.0 on pci3 ahc0: [ITHREAD] aic7880: Ultra Single Channel A, SCSI Id=7, 16/253 SCBs sa0 at ahc0 bus 0 target 5 lun 0 sa0: Removable Sequential Access SCSI-2 device sa0: 5.000MB/s transfers (5.000MHz, offset 15) da0 at ahc0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-3 device da0: 10.000MB/s transfers (10.000MHz, offset 15) da0: Command Queueing Enabled da0: 8761MB (17942584 512 byte sectors: 255H 63S/T 1116C) -- Steve From owner-freebsd-current@FreeBSD.ORG Thu Jul 19 23:17:20 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5356916A41B for ; Thu, 19 Jul 2007 23:17:20 +0000 (UTC) (envelope-from redchin@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.175]) by mx1.freebsd.org (Postfix) with ESMTP id CD10913C481 for ; Thu, 19 Jul 2007 23:17:19 +0000 (UTC) (envelope-from redchin@gmail.com) Received: by ug-out-1314.google.com with SMTP id o4so700562uge for ; Thu, 19 Jul 2007 16:17:18 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=JqK22chjez7cVQEk86Jck0rx1lmfQDw5axNtAytL3Xh/7SJL2/KYOTPoRlinA36/P0mdu0edAWtVdEXmvHjYLPmdjRXk6FV1idDi2rIH3YCKHzU6laa4q2jTr/ALVpE0crQ+pOOhXT25PVuR1e8MRMo5GG2T8Ade7TFUOmDTPc4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=TxXvNpUC44011sL12++Mr38BY3yRhhkDyTgaQC+kVG3C6bPqCWHjLBpO38MseNF/xQhmbqmKkHX2qF6YC5zqThlkcvqDu3v5wGV7VR4p3FTtX8Kca+VnbLtNrACubuDJzMC7FcD8BpaNx63fBrAN8QrOy0XoolVWVw1w2XllRDE= Received: by 10.78.118.5 with SMTP id q5mr871605huc.1184885532761; Thu, 19 Jul 2007 15:52:12 -0700 (PDT) Received: by 10.78.45.18 with HTTP; Thu, 19 Jul 2007 15:52:12 -0700 (PDT) Message-ID: <1d3ed48c0707191552g7f804257ya9f4791ff22ffa36@mail.gmail.com> Date: Thu, 19 Jul 2007 15:52:12 -0700 From: "Kevin Downey" To: "Kevin Oberman" In-Reply-To: <20070719191639.B8A5845045@ptavv.es.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <469ED8F1.2070409@errno.com> <20070719191639.B8A5845045@ptavv.es.net> Cc: current@freebsd.org Subject: Re: Problems connecting to public WiFi with latest 80211 code X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Jul 2007 23:17:20 -0000 On 7/19/07, Kevin Oberman wrote: > > Date: Wed, 18 Jul 2007 20:22:25 -0700 > > From: Sam Leffler > > > > Kevin Oberman wrote: > > > I had not seen this problem because I do not use the wpa_supplicant to > > > connect to open networks when at home, but I am on travel this week and > > > it has been a real pain. > > > > > > System is current as of this afternoon and is running on a ThinkPad T43 > > > with an Atheros 5212 mini-PCI card. > > > > mac+phy revs for card are always important; dmesg|grep ath > > > > > > > > When the system comes up, the wpa_supplicant starts, but the system > > > never scans except with 'authmode WPA1+WPA2/802.11i privacy ON' and > > > never tries to associate with an open AP even though I have an entry in > > > wpa_supplicant.conf for that network. I have to issue a 'ifconfig > > > wepmode off' to get it to associate. > > > > I don't see a log from wpa_supplicant or console debug msgs as obtained > > with wlandebug. > > > > > > > > Even then, it still won't always associate until I ifconfig the > > > interface down and up. Once I do this, it seems to associate rather > > > quickly. > > > > > > I suspect that the problem reported on mobile by Matthias Apitz and jhb > > > may be a part of the problem, but I think the inability to get to > > > authmode OPEN is different. > > > > > > I use the supplicant at home and it works fine, but that is NOT an open > > > network, so I don't need the interface to run in OPEN mode. > > > > > > Any idea what is going on and if it can be fixed or worked around? > > > > I can't help w/o the usual info: what os, card info (mac+phy), and how > > to reproduce (e.g. wpa_supplicant.conf and cmd line). > > Sorry, this was a really bad report. > > Here is the dmesg part: > ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) > ath0: mem 0xb4000000-0xb400ffff irq 11 at device 2.0 on pci11 > ath0: [ITHREAD] > ath0: using obsoleted if_watchdog interface > ath0: Ethernet address: 00:14:a4:60:f2:e3 > ath0: mac 5.9 phy 4.3 radio 3.6 > > Do the following: > Boot up a current kernel WITHOUT 'device ath' > kldload if_ath > Interface continues to report 'authmode WPA1+WPA2/802.11i privacy ON' > and never associates. > /etc/rc.d/wpa_supplicant restart ath0 > > This fixes it all. I didn't realize that restarting wpa_supplicant > corrected the problem when I sent the initial message. > > Because of the way this is working, I failed to get anything from > 'wpa_supplicant -d' as any attempt to re-start the supplicant cause > things to work. > > I did run wlandebug and I am attaching the output. The supplicant was > restarted at the point where the DHCP client exited. > > I see the same behavior when I 'boot -s', 'kldload if_ath' and 'exit'. > > Due to an IRQ issue that I have not had time to try to track down, I > can't load it from the loader and I don't want it in my kernel fro a > variety of reasons. > > I might also mention that I am also seeing frequent drops in > associations that are working fine, but this has been reported by > others and so this is just a "me, too". But is annoying. I lost it > twice entering this message. > -- > R. Kevin Oberman, Network Engineer > ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) ath0: mem 0x90000000-0x9000ffff irq 22 at device 1.0 on pci7 I see similar behavior. I get a "ath0: device timeout" message then I lose my connection. If I bounce the interface with '/etc/rc.d/netif restart ath0' ifconfig shows ath0 with 'authmode WPA1+WPA2/802.11i privacy ON' and it no longer associates with my ap. Sometimes if I bounce it a few times it will "unstick" and go back to "authmode OPEN privacy ON" other times it requires a reboot. I am using wpa_supplicant, but not WPA just WEP. 'ifconfig ath0 authmode open' doesn't change anything when its stuck on "authmode WPA1+WPA2/802.11i" This happens a few times a week. -- i'll unhook my oily pink mini-kimono, you kill him in honolulu From owner-freebsd-current@FreeBSD.ORG Fri Jul 20 00:05:24 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3EEB116A417 for ; Fri, 20 Jul 2007 00:05:24 +0000 (UTC) (envelope-from SRS1=a866e2cdc4db16dbe9046af29cda30229a163259=es.net==a866e2cdc4db16dbe9046af29cda30229a163259=400=es.net=oberman@es.net) Received: from postal1.es.net (postal1.es.net [IPv6:2001:400:14:3::6]) by mx1.freebsd.org (Postfix) with ESMTP id 6E79013C44C for ; Fri, 20 Jul 2007 00:05:21 +0000 (UTC) (envelope-from SRS1=a866e2cdc4db16dbe9046af29cda30229a163259=es.net==a866e2cdc4db16dbe9046af29cda30229a163259=400=es.net=oberman@es.net) Received: from postal1.es.net (postal4.es.net [198.124.252.66]) by postal1.es.net (Postal Node 1) with ESMTP (SSL) id XBN15945 for Received: from ptavv.es.net (ptavv.es.net [198.128.4.29]) by postal4.es.net (Postal Node 4) with ESMTP (SSL) id XBN58042; Wed, 18 Jul 2007 13:47:42 -0700 Received: from ptavv.es.net (ptavv.es.net [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id DA71845045; Wed, 18 Jul 2007 13:47:40 -0700 (PDT) To: sam@errno.com Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_1184791660_74708P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Wed, 18 Jul 2007 13:47:40 -0700 From: "Kevin Oberman" Message-Id: <20070718204740.DA71845045@ptavv.es.net> Cc: current@freebsd.org Subject: Problems connecting to public WiFi with latest 80211 code X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Jul 2007 00:05:24 -0000 --==_Exmh_1184791660_74708P Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I had not seen this problem because I do not use the wpa_supplicant to connect to open networks when at home, but I am on travel this week and it has been a real pain. System is current as of this afternoon and is running on a ThinkPad T43 with an Atheros 5212 mini-PCI card. When the system comes up, the wpa_supplicant starts, but the system never scans except with 'authmode WPA1+WPA2/802.11i privacy ON' and never tries to associate with an open AP even though I have an entry in wpa_supplicant.conf for that network. I have to issue a 'ifconfig wepmode off' to get it to associate. Even then, it still won't always associate until I ifconfig the interface down and up. Once I do this, it seems to associate rather quickly. I suspect that the problem reported on mobile by Matthias Apitz and jhb may be a part of the problem, but I think the inability to get to authmode OPEN is different. I use the supplicant at home and it works fine, but that is NOT an open network, so I don't need the interface to run in OPEN mode. Any idea what is going on and if it can be fixed or worked around? -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 --==_Exmh_1184791660_74708P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) Comment: Exmh version 2.5 06/03/2002 iD8DBQFGnnxskn3rs5h7N1ERAgmRAJ45sZ55rtJOF4oCeSv7EzL0OGFx2QCZAWGO h0wRzK+M0L9Xuf7xQJEgLv4= =/kOb -----END PGP SIGNATURE----- --==_Exmh_1184791660_74708P-- From owner-freebsd-current@FreeBSD.ORG Fri Jul 20 00:10:45 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D465D16A417 for ; Fri, 20 Jul 2007 00:10:45 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from heff.fud.org.nz (203-109-251-39.static.bliink.ihug.co.nz [203.109.251.39]) by mx1.freebsd.org (Postfix) with ESMTP id B2F3F13C48E for ; Fri, 20 Jul 2007 00:10:44 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: by heff.fud.org.nz (Postfix, from userid 1001) id E1DB01CC58; Fri, 20 Jul 2007 12:10:43 +1200 (NZST) Date: Fri, 20 Jul 2007 12:10:43 +1200 From: Andrew Thompson To: Scot Hetzel Message-ID: <20070720001043.GD45010@heff.fud.org.nz> References: <790a9fff0707150332u2502a491s91f19d4303bf82a6@mail.gmail.com> <20070715110629.GI95956@heff.fud.org.nz> <790a9fff0707181607n7500b7feo190c58418e047de5@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="61jdw2sOBCFtR2d/" Content-Disposition: inline In-Reply-To: <790a9fff0707181607n7500b7feo190c58418e047de5@mail.gmail.com> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: freebsd-current@freebsd.org Subject: Re: stopping ndis caused fatal trap 12 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Jul 2007 00:10:45 -0000 --61jdw2sOBCFtR2d/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Jul 18, 2007 at 06:07:37PM -0500, Scot Hetzel wrote: > On 7/15/07, Andrew Thompson wrote: > >On Sun, Jul 15, 2007 at 05:32:32AM -0500, Scot Hetzel wrote: > >> hp010# uname -a > >> FreeBSD hp010 7.0-CURRENT FreeBSD 7.0-CURRENT #0: Sat Jul 14 02:20:09 > >> CDT 2007 root@hp010:/usr/src/7x/sys-p4/amd64/compile/GENERIC.debug > >> amd64 > >> > >> I was testing wpa_supplicant at work, and couldn't get it to associate > >> with the network (open, no encryption), and so I had hardcoded the > >> network. When I went home and booted the system, it still had the > >> hardcoded wireless network configured. I then did a netif stop ndis0, > >> made the change to set ndis to "WPA DHCP", then when I used 'netif > >> start ndis0', it didn't obtain an IP. So I performed an 'netif stop > >> ndis0' and received the following panic: > >> > >So back to the ndis association problem. Did the card find the access > >point? you can list the scan cache from 'ifconfig ndis0 list scan'. > > > > ifconfig ndis0 scan ; ifconfig ndis0 list scan don't return with any > results, but if I run wpa_cli, and do a scan and scan_results it lists > the APs. Can you (and anyone else having ndis assosciate problems) please try these two patches. ndis_scan9.diff applies in sys/dev/if_ndis, and scan_sta1.diff applies in sys/net80211. I have kept them seperate as Sephe is due to commit scan_sta1.diff shortly and may have already done so before you get to test. cheers, Andrew --61jdw2sOBCFtR2d/ Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="ndis_scan9.diff" Index: if_ndis.c =================================================================== RCS file: /home/ncvs/src/sys/dev/if_ndis/if_ndis.c,v retrieving revision 1.123 diff -u -p -r1.123 if_ndis.c --- if_ndis.c 12 Jul 2007 02:54:05 -0000 1.123 +++ if_ndis.c 19 Jul 2007 23:57:59 -0000 @@ -48,9 +48,7 @@ __FBSDID("$FreeBSD: src/sys/dev/if_ndis/ #include #include #include -#if __FreeBSD_version < 502113 #include -#endif #include #include @@ -89,8 +87,12 @@ __FBSDID("$FreeBSD: src/sys/dev/if_ndis/ #include #include +#define NDIS_DEBUG #ifdef NDIS_DEBUG -#define DPRINTF(x) printf x +#define DPRINTF(x) do { if (ndis_debug > 0) printf x; } while (0) +int ndis_debug = 0; +SYSCTL_INT(_debug, OID_AUTO, ndis, CTLFLAG_RW, &ndis_debug, 0, + "if_ndis debug level"); #else #define DPRINTF(x) #endif @@ -752,11 +754,16 @@ ndis_attach(dev) setbit(&bands, IEEE80211_MODE_11G); break; default: + device_printf(dev, "Unknown nettype %d\n", + ntl->ntl_type[i]); break; } } free(ntl, M_DEVBUF); nonettypes: + /* Default to 11b channels if the card did not supply any */ + if (bands == 0) + setbit(&bands, IEEE80211_MODE_11B); len = sizeof(rates); bzero((char *)&rates, len); r = ndis_get_info(sc, OID_802_11_SUPPORTED_RATES, @@ -2739,7 +2746,6 @@ ndis_getstate_80211(sc) if (ic->ic_curchan == NULL) ic->ic_curchan = &ic->ic_channels[0]; ic->ic_bss->ni_chan = ic->ic_curchan; - ic->ic_des_chan = ic->ic_curchan; ic->ic_bsschan = ic->ic_curchan; free(bs, M_TEMP); @@ -3502,12 +3508,37 @@ ndis_scan(void *arg, int npending) { struct ndis_softc *sc = arg; struct ieee80211com *ic = (void *)&sc->ic; + struct ieee80211_scan_state *ss = ic->ic_scan; + ndis_80211_ssid ssid; int error, len; + if (!NDIS_INITIALIZED(sc)) { + DPRINTF(("%s: scan aborted\n", __func__)); + ieee80211_cancel_scan(ic); + return; + } + + if (ss->ss_nssid != 0) { + len = sizeof(ssid); + bzero((char *)&ssid, len); + ssid.ns_ssidlen = ss->ss_ssid[0].len; + bcopy(ss->ss_ssid[0].ssid, ssid.ns_ssid, ssid.ns_ssidlen); + + error = ndis_set_info(sc, OID_802_11_SSID, &ssid, &len); + if (error) + DPRINTF(("%s: set ESSID failed\n", __func__)); + } + len = 0; error = ndis_set_info(sc, OID_802_11_BSSID_LIST_SCAN, NULL, &len); - tsleep(&error, PPAUSE|PCATCH, "ssidscan", hz * 2); + if (error) { + DPRINTF(("%s: scan command failed\n", __func__)); + ieee80211_cancel_scan(ic); + return; + } + + tsleep(&error, PPAUSE|PCATCH, "ssidscan", hz * 3); ndis_scan_results(sc); ieee80211_scan_done(ic); } @@ -3521,7 +3552,7 @@ ndis_scan_results(struct ndis_softc *sc) struct ieee80211_scanparams sp; struct ieee80211_frame wh; int i, j; - int error, len, rssi, noise; + int error, len, rssi, noise, freq, chanflag; static long rstamp; uint8_t ssid[2+IEEE80211_NWID_LEN]; uint8_t rates[2+IEEE80211_RATE_MAXSIZE]; @@ -3535,10 +3566,12 @@ ndis_scan_results(struct ndis_softc *sc) bl = malloc(len, M_DEVBUF, M_NOWAIT | M_ZERO); error = ndis_get_info(sc, OID_802_11_BSSID_LIST, bl, &len); if (error) { + DPRINTF(("%s: failed to read\n", __func__)); free(bl, M_DEVBUF); return;; } + DPRINTF(("%s: %d results\n", __func__, bl->nblx_items)); rstamp++; wb = &bl->nblx_bssid[0]; for (i = 0; i < bl->nblx_items; i++) { @@ -3546,7 +3579,7 @@ ndis_scan_results(struct ndis_softc *sc) memcpy(wh.i_addr2, wb->nwbx_macaddr, sizeof(wh.i_addr2)); memcpy(wh.i_addr3, wb->nwbx_macaddr, sizeof(wh.i_addr3)); - rssi = (wb->nwbx_rssi - noise) / (-32 - noise) * 100; + rssi = 100 * (wb->nwbx_rssi - noise) / (-32 - noise); rssi = max(0, min(rssi, 100)); /* limit 0 <= rssi <= 100 */ if (wb->nwbx_privacy) sp.capinfo |= IEEE80211_CAPINFO_PRIVACY; @@ -3559,6 +3592,21 @@ ndis_scan_results(struct ndis_softc *sc) sp.capinfo |= IEEE80211_CAPINFO_ESS; break; } + switch(wb->nwbx_nettype) { + case NDIS_80211_NETTYPE_11FH: + case NDIS_80211_NETTYPE_11DS: + chanflag = IEEE80211_CHAN_B; + break; + case NDIS_80211_NETTYPE_11OFDM5: + chanflag = IEEE80211_CHAN_A; + break; + case NDIS_80211_NETTYPE_11OFDM24: + chanflag = IEEE80211_CHAN_G; + break; + default: + chanflag = IEEE80211_CHAN_B; + break; + } sp.rates = &rates[0]; for (j = 0; j < IEEE80211_RATE_MAXSIZE; j++) { /* XXX - check units */ @@ -3573,11 +3621,9 @@ ndis_scan_results(struct ndis_softc *sc) wb->nwbx_ssid.ns_ssidlen); sp.ssid[1] = wb->nwbx_ssid.ns_ssidlen; - sp.bchan = ieee80211_mhz2ieee( - wb->nwbx_config.nc_dsconfig / 1000, 0); - sp.curchan = ieee80211_find_channel(ic, - ieee80211_ieee2mhz(sp.bchan, IEEE80211_CHAN_B), - IEEE80211_CHAN_B); + freq = wb->nwbx_config.nc_dsconfig / 1000; + sp.bchan = ieee80211_mhz2ieee( freq, chanflag); + sp.curchan = ieee80211_find_channel(ic, freq, chanflag); if (sp.curchan == NULL) sp.curchan = &ic->ic_channels[0]; @@ -3607,9 +3653,13 @@ ndis_scan_results(struct ndis_softc *sc) } } done: + DPRINTF(("scan: bssid %s chan %dMHz (%d/%d) rssi %d\n", + ether_sprintf(wb->nwbx_macaddr), freq, sp.bchan, chanflag, + rssi)); ieee80211_add_scan(ic, &sp, &wh, 0, rssi, noise, rstamp); wb = (ndis_wlan_bssid_ex *)((char *)wb + wb->nwbx_len); } + free(bl, M_DEVBUF); } static void --61jdw2sOBCFtR2d/ Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="scan_sta1.diff" ==== //depot/projects/wifi/sys/net80211/ieee80211_scan_sta.c#24 - /opt/sam_wifi/sys/net80211/ieee80211_scan_sta.c ==== --- /tmp/tmp.610.42 2007-07-18 19:26:45.000000000 +0800 +++ /opt/sam_wifi/sys/net80211/ieee80211_scan_sta.c 2007-07-18 19:26:15.000000000 +0800 @@ -376,17 +376,23 @@ add_channels(struct ieee80211com *ic, break; c = ieee80211_find_channel(ic, freq[i], modeflags); - if (c == NULL || isexcluded(ic, c)) + if (c != NULL && isexcluded(ic, c)) continue; if (mode == IEEE80211_MODE_AUTO) { /* * XXX special-case 11b/g channels so we select - * the g channel if both are present. + * the g channel if both are present or there + * are only g channels. */ - if (IEEE80211_IS_CHAN_B(c) && - (cg = find11gchannel(ic, i, c->ic_freq)) != NULL) - c = cg; + if (c == NULL || IEEE80211_IS_CHAN_B(c)) { + cg = find11gchannel(ic, i, freq[i]); + if (cg != NULL) + c = cg; + } } + if (c == NULL) + continue; + ss->ss_chans[ss->ss_last++] = c; } #undef N --61jdw2sOBCFtR2d/-- From owner-freebsd-current@FreeBSD.ORG Fri Jul 20 00:26:43 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B3D9E16A417 for ; Fri, 20 Jul 2007 00:26:43 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.239]) by mx1.freebsd.org (Postfix) with ESMTP id 09A0213C481 for ; Fri, 20 Jul 2007 00:26:42 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by nz-out-0506.google.com with SMTP id l8so585959nzf for ; Thu, 19 Jul 2007 17:26:42 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:received:received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=KRbkwSGV4s1wuEfLQ/MbfP5ugAWFFUWokocNV1z1sIyV/QmQ/Vr2l7bLGHFm6zx1dhXdii9Y6QO5ZOQoxq7AyAPomk7jLIaiYnC3gvQgLmoXArD9p/tyHumo2KBiJXkrDtVwgp0YQUpeTcOfAaStYU4HAS5evq9RW89FfcH27aI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=iBwY7Hlb7SR9UMHjy/RrJFGWJj738eP2OLhYr7q3B4ZGKHZcEglXUyW3tStP3aDqyI6hWaTj4rqKvI0qfvIIvD8irrlHMcFmwHmsd7LlpW6yy1i7zQ3bH5MUiswtMTrXMSQmw0JCw8x6duKG7pGaC3Z37KwUXR50udv9SCy4RSk= Received: by 10.115.58.1 with SMTP id l1mr3094885wak.1184891201894; Thu, 19 Jul 2007 17:26:41 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTPS id m5sm3741850wag.2007.07.19.17.26.38 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 19 Jul 2007 17:26:40 -0700 (PDT) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id l6K0QZHT047032 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 Jul 2007 09:26:35 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id l6K0QYjT047031; Fri, 20 Jul 2007 09:26:34 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Fri, 20 Jul 2007 09:26:34 +0900 From: Pyun YongHyeon To: Li-Lun Leland Wang Message-ID: <20070720002634.GD42405@cdnetworks.co.kr> References: <20070713084325.GA47351@Athena.infor.org> <20070713100829.GC17801@cdnetworks.co.kr> <20070714042626.GA22511@cdnetworks.co.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@freebsd.org Subject: Re: threadlock and msk watchdog timeout X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2007 00:26:43 -0000 On Sat, Jul 14, 2007 at 01:53:51AM -0500, Li-Lun Leland Wang wrote: > On 7/13/07, Pyun YongHyeon wrote: > >Ok, try attached patch after adding 'hw.msk.legacy_intr="1"' to > >/boot/loader.conf. If you use msk(4) kernel module use > >kenv(1) to set the tunable. > > The patch seems to be working. The interface hasn't hung once ever > since. Thank you very much for you work. I greatly appreciate it. > Committed to HEAD(if_msk, rev. 1.18). Thanks for testing! > -- llwang -- Regards, Pyun YongHyeon From owner-freebsd-current@FreeBSD.ORG Fri Jul 20 02:09:48 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 53E4316A418 for ; Fri, 20 Jul 2007 02:09:48 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from heff.fud.org.nz (203-109-251-39.static.bliink.ihug.co.nz [203.109.251.39]) by mx1.freebsd.org (Postfix) with ESMTP id F255213C483 for ; Fri, 20 Jul 2007 02:09:47 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: by heff.fud.org.nz (Postfix, from userid 1001) id C83C41CC58; Fri, 20 Jul 2007 14:09:46 +1200 (NZST) Date: Fri, 20 Jul 2007 14:09:46 +1200 From: Andrew Thompson To: FreeBSD Current Message-ID: <20070720020946.GA69737@heff.fud.org.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.13 (2006-08-11) Cc: Subject: USB memory leak X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2007 02:09:48 -0000 Hi, On my up to date current box I am noticing memory leak complaints when unload the usb module. This is from a straight load/unload: [dev7b]# kldload usb uhci0: port 0x1820-0x183f irq 11 at device 31.2 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered [dev7b]# kldunload usb uhub0: detached usb0: detached uhci0: detached Warning: memory type USBdev leaked memory on destroy (5 allocations, 2560 bytes leaked). Warning: memory type USB leaked memory on destroy (13 allocations, 1248 bytes leaked). FreeBSD dev7b.fud.org.nz 7.0-CURRENT FreeBSD 7.0-CURRENT #20: Thu Jul 19 20:42:41 NZST 2007 root@dev7b.fud.org.nz:/usr/obj/usr/src/sys/DEV7B i386 cheers, Andrew From owner-freebsd-current@FreeBSD.ORG Fri Jul 20 02:17:07 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9C32D16A419 for ; Fri, 20 Jul 2007 02:17:07 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from heff.fud.org.nz (203-109-251-39.static.bliink.ihug.co.nz [203.109.251.39]) by mx1.freebsd.org (Postfix) with ESMTP id 38D1413C45B for ; Fri, 20 Jul 2007 02:17:07 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: by heff.fud.org.nz (Postfix, from userid 1001) id 5E4061CC58; Fri, 20 Jul 2007 14:17:06 +1200 (NZST) Date: Fri, 20 Jul 2007 14:17:06 +1200 From: Andrew Thompson To: FreeBSD Current Message-ID: <20070720021706.GB69737@heff.fud.org.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.13 (2006-08-11) Cc: Subject: ndis kthread teardown X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Jul 2007 02:17:07 -0000 Hi, There seems to be a race in the ndis code when stopping the ntoskrnl_workitem threads. It sets a flag, wakes up the thread, and then sleeps on the proc for the wakeup from kthread_exit. I have found that the kthread can exit before ntoskrnl_destroy_workitem_threads() gets to sleep on the proc, this means that it will sleep indefinitely. Here is a patch that fixes it for me, it reuses the kq_exit flag to identify that its already closed. Andrew Index: subr_ntoskrnl.c =================================================================== RCS file: /home/ncvs/src/sys/compat/ndis/subr_ntoskrnl.c,v retrieving revision 1.89 diff -u -p -r1.89 subr_ntoskrnl.c --- subr_ntoskrnl.c 5 Jun 2007 00:00:50 -0000 1.89 +++ subr_ntoskrnl.c 20 Jul 2007 02:05:43 -0000 @@ -2778,6 +2778,7 @@ ntoskrnl_workitem_thread(arg) KeAcquireSpinLock(&kq->kq_lock, &irql); if (kq->kq_exit) { + kq->kq_exit = 0; KeReleaseSpinLock(&kq->kq_lock, irql); break; } @@ -2814,7 +2815,8 @@ ntoskrnl_destroy_workitem_threads(void) kq = wq_queues + i; kq->kq_exit = 1; KeSetEvent(&kq->kq_proc, IO_NO_INCREMENT, FALSE); - tsleep(kq->kq_td->td_proc, PWAIT, "waitiw", 0); + if (kq->kq_exit) + tsleep(kq->kq_td->td_proc, PWAIT, "waitiw", 0); } return; @@ -3842,6 +3844,7 @@ ntoskrnl_dpc_thread(arg) KeAcquireSpinLock(&kq->kq_lock, &irql); if (kq->kq_exit) { + kq->kq_exit = 0; KeReleaseSpinLock(&kq->kq_lock, irql); break; } @@ -3891,7 +3894,8 @@ ntoskrnl_destroy_dpc_threads(void) KeInitializeDpc(&dpc, NULL, NULL); KeSetTargetProcessorDpc(&dpc, i); KeInsertQueueDpc(&dpc, NULL, NULL); - tsleep(kq->kq_td->td_proc, PWAIT, "dpcw", 0); + if (kq->kq_exit) + tsleep(kq->kq_td->td_proc, PWAIT, "dpcw", 0); } return; From owner-freebsd-current@FreeBSD.ORG Fri Jul 20 04:10:30 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0411B16A421 for ; Fri, 20 Jul 2007 04:10:30 +0000 (UTC) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id B577A13C459 for ; Fri, 20 Jul 2007 04:10:28 +0000 (UTC) (envelope-from sam@errno.com) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id l6K4ARmx095466 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Jul 2007 21:10:27 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <46A03676.10407@errno.com> Date: Thu, 19 Jul 2007 21:13:42 -0700 From: Sam Leffler User-Agent: Thunderbird 2.0.0.0 (X11/20070530) MIME-Version: 1.0 To: Kevin Oberman References: <20070719191639.B8A5845045@ptavv.es.net> In-Reply-To: <20070719191639.B8A5845045@ptavv.es.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: Problems connecting to public WiFi with latest 80211 code X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Jul 2007 04:10:30 -0000 Kevin Oberman wrote: >> Date: Wed, 18 Jul 2007 20:22:25 -0700 >> From: Sam Leffler >> >> Kevin Oberman wrote: >>> I had not seen this problem because I do not use the wpa_supplicant to >>> connect to open networks when at home, but I am on travel this week and >>> it has been a real pain. >>> >>> System is current as of this afternoon and is running on a ThinkPad T43 >>> with an Atheros 5212 mini-PCI card. >> mac+phy revs for card are always important; dmesg|grep ath >> >>> When the system comes up, the wpa_supplicant starts, but the system >>> never scans except with 'authmode WPA1+WPA2/802.11i privacy ON' and >>> never tries to associate with an open AP even though I have an entry in >>> wpa_supplicant.conf for that network. I have to issue a 'ifconfig >>> wepmode off' to get it to associate. >> I don't see a log from wpa_supplicant or console debug msgs as obtained >> with wlandebug. >> >>> Even then, it still won't always associate until I ifconfig the >>> interface down and up. Once I do this, it seems to associate rather >>> quickly. >>> >>> I suspect that the problem reported on mobile by Matthias Apitz and jhb >>> may be a part of the problem, but I think the inability to get to >>> authmode OPEN is different. >>> >>> I use the supplicant at home and it works fine, but that is NOT an open >>> network, so I don't need the interface to run in OPEN mode. >>> >>> Any idea what is going on and if it can be fixed or worked around? >> I can't help w/o the usual info: what os, card info (mac+phy), and how >> to reproduce (e.g. wpa_supplicant.conf and cmd line). > > Sorry, this was a really bad report. > > Here is the dmesg part: > ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) > ath0: mem 0xb4000000-0xb400ffff irq 11 at device 2.0 on pci11 > ath0: [ITHREAD] > ath0: using obsoleted if_watchdog interface > ath0: Ethernet address: 00:14:a4:60:f2:e3 > ath0: mac 5.9 phy 4.3 radio 3.6 > > Do the following: > Boot up a current kernel WITHOUT 'device ath' > kldload if_ath > Interface continues to report 'authmode WPA1+WPA2/802.11i privacy ON' > and never associates. > /etc/rc.d/wpa_supplicant restart ath0 > > This fixes it all. I didn't realize that restarting wpa_supplicant > corrected the problem when I sent the initial message. > > Because of the way this is working, I failed to get anything from > 'wpa_supplicant -d' as any attempt to re-start the supplicant cause > things to work. > > I did run wlandebug and I am attaching the output. The supplicant was > restarted at the point where the DHCP client exited. > > I see the same behavior when I 'boot -s', 'kldload if_ath' and 'exit'. > > Due to an IRQ issue that I have not had time to try to track down, I > can't load it from the loader and I don't want it in my kernel fro a > variety of reasons. > > I might also mention that I am also seeing frequent drops in > associations that are working fine, but this has been reported by > others and so this is just a "me, too". But is annoying. I lost it > twice entering this message. > It appears wpa_supplicant is in control of selecting an ap but there's no log from it to indicate why it had troubles. The output of wlandebug scan shows the ap you finally associated to (00:14:6a:07:b9:00) appear in every scan result and with a strong rssi so whatever is going on looks to be in wpa_supplicant. I didn't understand the comment about loading the module not doing anything. If the authmode was switched from OPEN to WPA then wpa_supplicant started and if it started then it should have kicked off a scan. I suspect you need to collect a log from it to get any further. I'd suggest not launching wpa_supplicant on module load. Then run it by hand and capture a log. Sam From owner-freebsd-current@FreeBSD.ORG Fri Jul 20 05:15:11 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 934B116A419 for ; Fri, 20 Jul 2007 05:15:11 +0000 (UTC) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id 4872B13C45D for ; Fri, 20 Jul 2007 05:15:11 +0000 (UTC) (envelope-from sam@errno.com) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id l6K5F8bL095746 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Jul 2007 22:15:09 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <46A0459F.1030808@errno.com> Date: Thu, 19 Jul 2007 22:18:23 -0700 From: Sam Leffler User-Agent: Thunderbird 2.0.0.0 (X11/20070530) MIME-Version: 1.0 To: Kevin Downey References: <469ED8F1.2070409@errno.com> <20070719191639.B8A5845045@ptavv.es.net> <1d3ed48c0707191552g7f804257ya9f4791ff22ffa36@mail.gmail.com> In-Reply-To: <1d3ed48c0707191552g7f804257ya9f4791ff22ffa36@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: Problems connecting to public WiFi with latest 80211 code X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Jul 2007 05:15:11 -0000 Kevin Downey wrote: > On 7/19/07, Kevin Oberman wrote: >> > Date: Wed, 18 Jul 2007 20:22:25 -0700 >> > From: Sam Leffler >> > >> > Kevin Oberman wrote: >> > > I had not seen this problem because I do not use the >> wpa_supplicant to >> > > connect to open networks when at home, but I am on travel this >> week and >> > > it has been a real pain. >> > > >> > > System is current as of this afternoon and is running on a >> ThinkPad T43 >> > > with an Atheros 5212 mini-PCI card. >> > >> > mac+phy revs for card are always important; dmesg|grep ath >> > >> > > >> > > When the system comes up, the wpa_supplicant starts, but the system >> > > never scans except with 'authmode WPA1+WPA2/802.11i privacy ON' and >> > > never tries to associate with an open AP even though I have an >> entry in >> > > wpa_supplicant.conf for that network. I have to issue a 'ifconfig >> > > wepmode off' to get it to associate. >> > >> > I don't see a log from wpa_supplicant or console debug msgs as obtained >> > with wlandebug. >> > >> > > >> > > Even then, it still won't always associate until I ifconfig the >> > > interface down and up. Once I do this, it seems to associate rather >> > > quickly. >> > > >> > > I suspect that the problem reported on mobile by Matthias Apitz >> and jhb >> > > may be a part of the problem, but I think the inability to get to >> > > authmode OPEN is different. >> > > >> > > I use the supplicant at home and it works fine, but that is NOT an >> open >> > > network, so I don't need the interface to run in OPEN mode. >> > > >> > > Any idea what is going on and if it can be fixed or worked around? >> > >> > I can't help w/o the usual info: what os, card info (mac+phy), and how >> > to reproduce (e.g. wpa_supplicant.conf and cmd line). >> >> Sorry, this was a really bad report. >> >> Here is the dmesg part: >> ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, >> RF5413) >> ath0: mem 0xb4000000-0xb400ffff irq 11 at device 2.0 on >> pci11 >> ath0: [ITHREAD] >> ath0: using obsoleted if_watchdog interface >> ath0: Ethernet address: 00:14:a4:60:f2:e3 >> ath0: mac 5.9 phy 4.3 radio 3.6 >> >> Do the following: >> Boot up a current kernel WITHOUT 'device ath' >> kldload if_ath >> Interface continues to report 'authmode WPA1+WPA2/802.11i privacy ON' >> and never associates. >> /etc/rc.d/wpa_supplicant restart ath0 >> >> This fixes it all. I didn't realize that restarting wpa_supplicant >> corrected the problem when I sent the initial message. >> >> Because of the way this is working, I failed to get anything from >> 'wpa_supplicant -d' as any attempt to re-start the supplicant cause >> things to work. >> >> I did run wlandebug and I am attaching the output. The supplicant was >> restarted at the point where the DHCP client exited. >> >> I see the same behavior when I 'boot -s', 'kldload if_ath' and 'exit'. >> >> Due to an IRQ issue that I have not had time to try to track down, I >> can't load it from the loader and I don't want it in my kernel fro a >> variety of reasons. >> >> I might also mention that I am also seeing frequent drops in >> associations that are working fine, but this has been reported by >> others and so this is just a "me, too". But is annoying. I lost it >> twice entering this message. >> -- >> R. Kevin Oberman, Network Engineer >> > ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) > ath0: mem 0x90000000-0x9000ffff irq 22 at device 1.0 on pci7 > > I see similar behavior. I get a "ath0: device timeout" message then I > lose my connection. If I bounce the interface with '/etc/rc.d/netif > restart ath0' ifconfig shows ath0 with 'authmode WPA1+WPA2/802.11i > privacy ON' and it no longer associates with my ap. Sometimes if I > bounce it a few times it will "unstick" and go back to "authmode OPEN > privacy ON" other times it requires a reboot. I am using > wpa_supplicant, but not WPA just WEP. 'ifconfig ath0 authmode open' > doesn't change anything when its stuck on "authmode WPA1+WPA2/802.11i" > > This happens a few times a week. > I cannot help w/o a log. Sam From owner-freebsd-current@FreeBSD.ORG Fri Jul 20 07:23:06 2007 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B968216A41B for ; Fri, 20 Jul 2007 07:23:06 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [IPv6:2001:1b20:1:3::1]) by mx1.freebsd.org (Postfix) with ESMTP id 2B39B13C467 for ; Fri, 20 Jul 2007 07:23:05 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (uxoxqv@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.4/8.13.4) with ESMTP id l6K7MCJM047651; Fri, 20 Jul 2007 09:22:17 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.4/8.13.1/Submit) id l6K7MBBJ047650; Fri, 20 Jul 2007 09:22:11 +0200 (CEST) (envelope-from olli) Date: Fri, 20 Jul 2007 09:22:11 +0200 (CEST) Message-Id: <200707200722.l6K7MBBJ047650@lurza.secnetix.de> From: Oliver Fromme To: freebsd-current@FreeBSD.ORG, serenity@exscape.org, fyr@fyrou.net In-Reply-To: <760CD82D-1548-41E3-8640-E636F2B231E7@exscape.org> X-Newsgroups: list.freebsd-current User-Agent: tin/1.8.2-20060425 ("Shillay") (UNIX) (FreeBSD/4.11-STABLE (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Fri, 20 Jul 2007 09:22:17 +0200 (CEST) Cc: Subject: Re: ZFS, chflags and installworld X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-current@FreeBSD.ORG, serenity@exscape.org, fyr@fyrou.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2007 07:23:06 -0000 (NB: Please don't top-post. It makes threads more difficult to read because the context is backwards. I tried to fix it in the quoted text below.) Thomas Backman wrote: > Francois Ranchin wrote: > > Thomas Backman wrote: > > > In any case, installworld gives me plenty of errors like "chflags: > > > (filename): > > > Operation not supported", and the files remain unchanged. > > > kern.securelevel is -1 and has always been. > > > chflags -R noschg doesn't work (plenty of "Operation not supported" > > > errors). > > > > > > Any hints? > > > > ZFS doesn't support chflags. Don't worry. The installed system is > > usefull. > > I'm not so sure that it's useable. > For instance (_after_ running installworld): > # pwd > /usr/obj/usr/src/bin/cat > # diff cat /bin/cat > Files cat and /bin/cat differ > # cp cat /bin > # diff cat /bin/cat > # That's normal. Files are stripped during install (using the -s option of install(1)). The files under /usr/obj are not stripped, so diff reports a difference. After your cp command, your file in /bin isn't stripped either, so diff reports they're identical. > Or, in english, the files doesn't seem to be installed by installworld. That's the wrong conclusion. I agree with Francois: You don't have to worry, everything is alright. > What I don't understand though, is why installworld receives > "Operation not supported" errors while my simple cp (or install(1)) > works every time. cp(1) or install(1) doesn't try to set any flags, i.e. the files are installed without flags. During install- world, only a few important files are explicitely changed with the chflags(1) command. Those are the ones which generate the warnings. By the way, exactly the same happens when you install on an NFS share which doesn't support chflags either: You get the same warnings, but the installation is fine. > I have very limited experience using flags, though. Seems so. :-) > Are flags retained when files are copied to a ZFS filesystem, even > though ZFS doesn't actually support them? I have no idea how or > where flags are actually "stored"... Or if there's a way to remove > them. The flags are stored in the inode, just like the file permissions (rwxr-xr-x) and other meta data of the file. Similar to the permissions, they are not copied when you copy the file unless you use the -p flag of cp(1). Of course they can only be copied if the destination FS supports them, which is currently only the case for UFS. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "The ITU has offered the IETF formal alignment with its corresponding technology, Penguins, but that won't fly." -- RFC 2549 From owner-freebsd-current@FreeBSD.ORG Fri Jul 20 08:08:51 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EAE8216A419 for ; Fri, 20 Jul 2007 08:08:51 +0000 (UTC) (envelope-from outbox.messages@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.182]) by mx1.freebsd.org (Postfix) with ESMTP id C570113C459 for ; Fri, 20 Jul 2007 08:08:51 +0000 (UTC) (envelope-from outbox.messages@gmail.com) Received: by wa-out-1112.google.com with SMTP id j37so969083waf for ; Fri, 20 Jul 2007 01:08:51 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:reply-to:user-agent:mime-version:to:subject:content-type:content-transfer-encoding:from; b=eMyuS/3g+WJuDA7mnb8+vVNUys/Fs4ujBy57XNEL3je6fURe/4dkujX2YFkpa5rMgKE4ebSvp2hRRMTEIidT4PfTy5ot/5zuD8CuNz8adqgt8CHJ2Curj5cOeEoEi7f79K7WqNf9/I0IpwJsAsECq7MDD9QEM8Iobl445/tuHxE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:reply-to:user-agent:mime-version:to:subject:content-type:content-transfer-encoding:from; b=kRc88H34T9Su7xC9IWfpBjoCUoE+jv0kXB5dO6K7NB/LjeiwLRLa0kDzDdFTDLynu/8Rxv/OvrpVnBTJpxRVSzvtRjF2a7XrI/Hoj2L6rqQrEa/UetJzczJzRNHSLo6RQmhbtbCtqMHTeORb19aFE9EEXnGsEQ8zGQU6zHUROTo= Received: by 10.115.75.1 with SMTP id c1mr199664wal.1184917188742; Fri, 20 Jul 2007 00:39:48 -0700 (PDT) Received: from ?192.168.1.5? ( [71.139.225.101]) by mx.google.com with ESMTPS id j34sm2938506waf.2007.07.20.00.39.47 (version=SSLv3 cipher=RC4-MD5); Fri, 20 Jul 2007 00:39:48 -0700 (PDT) Message-ID: <46A066C6.7000104@mpvweb.com> Date: Fri, 20 Jul 2007 00:39:50 -0700 User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit From: Kevin Baragona Subject: Kernel Panic with ZFS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: kevinmb@mpvweb.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2007 08:08:52 -0000 My kernel just panicked. Here is what it said. panic: kmem_malloc(131072): kmem_map too small: 167264256 total allocated cpuid = 0 KDB: enter: panic [thread pid 37 tid 100042 ] Stopped at kdb_enter+0x32: leave db> :( At the time this happened I was transferring lots of files to this system (personal file server) via the Apple File Protocol -- netatalk. It went fine for a few GB. Then this happened. The reason I'm running current rather than stable is that ZFS is a selling point.(but opensolaris doesn't work for me...) I have a zpool with 2 hard drives and 1 partition of a slice of another disk that is shared with root and swap. Mirroring isn't on. This farily old PC has a Pentium III Tualitin Celeron, and just 512MB of RAM. But the unrecommended minimum is 1 GB for ZFS. So I'm not sure if the problem is... I'm out of RAM. But I watched the memory usage and it didn't go up. Swap wasn't touched at all. Network related? Googling for the error I got got something I believe is unrelated. Or something else. Anyway I'm leaving the machine on in case anyone could use a trace if it helps. Thanks in advance! From owner-freebsd-current@FreeBSD.ORG Fri Jul 20 08:08:53 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3ECFA16A418 for ; Fri, 20 Jul 2007 08:08:53 +0000 (UTC) (envelope-from jhary@unsane.co.uk) Received: from unsane.co.uk (unknown [IPv6:2001:470:1f01:ffff::121]) by mx1.freebsd.org (Postfix) with ESMTP id 9EBC513C46E for ; Fri, 20 Jul 2007 08:08:52 +0000 (UTC) (envelope-from jhary@unsane.co.uk) Received: from prawn.unsane.co.uk (150.117-84-212.staticip.namesco.net [212.84.117.150]) (authenticated bits=0) by unsane.co.uk (8.14.0/8.14.0) with ESMTP id l6K87oMM021991 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 Jul 2007 09:07:52 +0100 (BST) (envelope-from jhary@unsane.co.uk) Message-ID: <46A06D8D.1070604@unsane.co.uk> Date: Fri, 20 Jul 2007 09:08:45 +0100 From: Vince User-Agent: Thunderbird 2.0.0.4 (X11/20070717) MIME-Version: 1.0 To: =?ISO-8859-1?Q?St=E5le_Kristoffersen?= References: <20070716190441.GA19282@eschew.pusen.org> <20070716213425.GB19282@eschew.pusen.org> <20070718041159.GC37935@cdnetworks.co.kr> <20070718044700.GE37935@cdnetworks.co.kr> <20070718124350.GA25799@eschew.pusen.org> In-Reply-To: <20070718124350.GA25799@eschew.pusen.org> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: current@freebsd.org Subject: Re: Slow networkperformance in current? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2007 08:08:53 -0000 Ståle Kristoffersen wrote: > On 2007-07-18 at 13:47, Pyun YongHyeon wrote: >> > I'm not sure it's directly related with re(4) but try overhauled re(4). >> > http://people.freebsd.org/~yongari/re.HEAD.patch >> > It seems that you also have PCIe based NIC. Try MSI patch for re(4) >> > in addition to above one. > >> Oops, here is MSI patch. >> http://people.freebsd.org/~yongari/re.msi.patch > > For anyone else wanting to test those patches the url was wrong, the > correct ones seems to be: > http://people.freebsd.org/~yongari/re/re.msi.patch > and > http://people.freebsd.org/~yongari/re/re.HEAD.patch > > I applied them, recompiled and rebooted. > > Not much change. Over the network: > [ 3] 0.0-10.0 sec 432 MBytes 362 Mbits/sec > and to localhost: > [ 3] 0.0-10.1 sec 125 MBytes 104 Mbits/sec > Silly as it might seem when did you last recompile the iperf port? I was about to post a me too post yesterday, until I updated my system to use the latest sched_ule at which point iperf froze my system completely, recompiling the port fixed the freeze and the <100Mbit/sec on localhost. I think it was compiled against the wrong threading library (been a while since i last recompiled it.) However i am seeing a gradual increase of speed the more i run it, caching of some type i assume. (jhary@prawn)$iperf -s ------------------------------------------------------------ Server listening on TCP port 5001 TCP window size: 64.0 KByte (default) ------------------------------------------------------------ [ 4] local 127.0.0.1 port 5001 connected with 127.0.0.1 port 51930 [ 4] 0.0-10.5 sec 1002 MBytes 798 Mbits/sec [ 5] local 127.0.0.1 port 5001 connected with 127.0.0.1 port 59561 [ 5] 0.0-10.0 sec 1.87 GBytes 1.61 Gbits/sec [ 4] local 127.0.0.1 port 5001 connected with 127.0.0.1 port 55966 [ 4] 0.0-10.1 sec 2.07 GBytes 1.77 Gbits/sec [ 5] local 127.0.0.1 port 5001 connected with 127.0.0.1 port 59935 [ 5] 0.0-10.0 sec 2.07 GBytes 1.78 Gbits/sec [ 4] local 127.0.0.1 port 5001 connected with 127.0.0.1 port 57795 Vince From owner-freebsd-current@FreeBSD.ORG Fri Jul 20 08:11:25 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3782B16A421 for ; Fri, 20 Jul 2007 08:11:25 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [210.51.165.229]) by mx1.freebsd.org (Postfix) with ESMTP id DFB3413C46A for ; Fri, 20 Jul 2007 08:11:24 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from localhost (tarsier.geekcn.org [210.51.165.229]) by tarsier.geekcn.org (Postfix) with ESMTP id 2D5DAEB19AF; Fri, 20 Jul 2007 16:11:24 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([210.51.165.229]) by localhost (mail.geekcn.org [210.51.165.229]) (amavisd-new, port 10024) with ESMTP id jRZ7BUZ0ghh8; Fri, 20 Jul 2007 16:11:21 +0800 (CST) Received: from LI-Xins-MacBook.local (sina152-194.staff.sina.com.cn [61.135.152.194]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id 520C3EB194D; Fri, 20 Jul 2007 16:11:21 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:cc:subject:references:in-reply-to: x-enigmail-version:openpgp:content-type; b=Yx8OlZAjxzRpM4nRVT4Etfuz89EZ0dxCmOUcBk55Rn77AeVkarXB2158gQdo5QonP u4Yena783GXT2SSFr2J5Q== Message-ID: <46A06E18.1000600@delphij.net> Date: Fri, 20 Jul 2007 16:11:04 +0800 From: LI Xin Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: kevinmb@mpvweb.com References: <46A066C6.7000104@mpvweb.com> In-Reply-To: <46A066C6.7000104@mpvweb.com> X-Enigmail-Version: 0.95.2 OpenPGP: url=http://www.delphij.net/delphij.asc Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig8601B6F6B8461830F63E9B13" Cc: freebsd-current@freebsd.org Subject: Re: Kernel Panic with ZFS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2007 08:11:25 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig8601B6F6B8461830F63E9B13 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Kevin Baragona wrote: > My kernel just panicked. Here is what it said. >=20 > panic: kmem_malloc(131072): kmem_map too small: 167264256 total allocat= ed > cpuid =3D 0 > KDB: enter: panic > [thread pid 37 tid 100042 ] > Stopped at kdb_enter+0x32: leave > db> :( This is because that you have ran out of memory. ZFS, especially its ARC is quite memory hungry so you *really* need more memory to make sure that it works smoothly. Cheers, --=20 Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! --------------enig8601B6F6B8461830F63E9B13 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGoG4YOfuToMruuMARCtt0AJ44WgeMpuVXnoySLku97+d8bj8dOQCfaiUm Q120u4+RVgQKgqtsp6okmt8= =jPzO -----END PGP SIGNATURE----- --------------enig8601B6F6B8461830F63E9B13-- From owner-freebsd-current@FreeBSD.ORG Fri Jul 20 08:25:13 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 764BF16A419 for ; Fri, 20 Jul 2007 08:25:13 +0000 (UTC) (envelope-from jhary@unsane.co.uk) Received: from unsane.co.uk (unknown [IPv6:2001:470:1f01:ffff::121]) by mx1.freebsd.org (Postfix) with ESMTP id DE43A13C45E for ; Fri, 20 Jul 2007 08:25:12 +0000 (UTC) (envelope-from jhary@unsane.co.uk) Received: from prawn.unsane.co.uk (150.117-84-212.staticip.namesco.net [212.84.117.150]) (authenticated bits=0) by unsane.co.uk (8.14.0/8.14.0) with ESMTP id l6K8OA77022188 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 Jul 2007 09:24:11 +0100 (BST) (envelope-from jhary@unsane.co.uk) Message-ID: <46A07161.9060107@unsane.co.uk> Date: Fri, 20 Jul 2007 09:25:05 +0100 From: Vince User-Agent: Thunderbird 2.0.0.4 (X11/20070717) MIME-Version: 1.0 To: kevinmb@mpvweb.com References: <46A066C6.7000104@mpvweb.com> In-Reply-To: <46A066C6.7000104@mpvweb.com> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Kernel Panic with ZFS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Jul 2007 08:25:13 -0000 Kevin Baragona wrote: > My kernel just panicked. Here is what it said. > > panic: kmem_malloc(131072): kmem_map too small: 167264256 total allocated > cpuid = 0 > KDB: enter: panic > [thread pid 37 tid 100042 ] > Stopped at kdb_enter+0x32: leave > db> :( > > > At the time this happened I was transferring lots of files to this > system (personal file server) via the Apple File Protocol -- netatalk. > It went fine for a few GB. Then this happened. > > The reason I'm running current rather than stable is that ZFS is a > selling point.(but opensolaris doesn't work for me...) I have a zpool > with 2 hard drives and 1 partition of a slice of another disk that is > shared with root and swap. Mirroring isn't on. > > This farily old PC has a Pentium III Tualitin Celeron, and just 512MB of > RAM. But the unrecommended minimum is 1 GB for ZFS. So I'm not sure if > the problem is... > > I'm out of RAM. But I watched the memory usage and it didn't go up. Swap > wasn't touched at all. > > Network related? Googling for the error I got got something I believe is > unrelated. > Or something else. Anyway I'm leaving the machine on in case anyone > could use a trace if it helps. > Have a look at http://wiki.freebsd.org/ZFSTuningGuide the vm.kmem_size_max given there is 256Meg but set it higher if you have memory to spare. > Thanks in advance! > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Fri Jul 20 09:58:10 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D495A16A41A; Fri, 20 Jul 2007 09:58:10 +0000 (UTC) (envelope-from tataz@tataz.chchile.org) Received: from smtp5-g19.free.fr (smtp5-g19.free.fr [212.27.42.35]) by mx1.freebsd.org (Postfix) with ESMTP id 997C313C459; Fri, 20 Jul 2007 09:58:10 +0000 (UTC) (envelope-from tataz@tataz.chchile.org) Received: from tatooine.tataz.chchile.org (tataz.chchile.org [82.233.239.98]) by smtp5-g19.free.fr (Postfix) with ESMTP id AA43D447F2; Fri, 20 Jul 2007 11:58:09 +0200 (CEST) Received: from obiwan.tataz.chchile.org (unknown [192.168.1.25]) by tatooine.tataz.chchile.org (Postfix) with ESMTP id 565FC9B497; Fri, 20 Jul 2007 09:57:21 +0000 (UTC) Received: by obiwan.tataz.chchile.org (Postfix, from userid 1000) id 396C8405F; Fri, 20 Jul 2007 11:57:21 +0200 (CEST) Date: Fri, 20 Jul 2007 11:57:21 +0200 From: Jeremie Le Hen To: John Baldwin Message-ID: <20070720095721.GE56695@obiwan.tataz.chchile.org> References: <20070616224703.GC63387@obiwan.tataz.chchile.org> <20070618100238.GD46910@heff.fud.org.nz> <200707160849.07376.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200707160849.07376.jhb@freebsd.org> User-Agent: Mutt/1.5.15 (2007-04-06) Cc: freebsd-current@freebsd.org, Andrew Thompson Subject: Re: Cannot use iwi(4): "could not load firmware iwi_bss" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Jul 2007 09:58:10 -0000 Hi, John, On Mon, Jul 16, 2007 at 08:49:06AM -0400, John Baldwin wrote: > On Monday 18 June 2007 06:02:38 am Andrew Thompson wrote: > > The driver will wait one second for the firmware to load, it is possible > > that the interrupt storm is affecting this. You can always increase the > > iwi timeout on line 2516 of if_iwi.c and see what happens. Change hz to > > hz * 3 perhaps. > > Looks like iwi's IRQ is wrong (misrouted perhaps). Fixing that will probably > fix your issue. Are you using ACPI? (It appears you are not using apic.) Thank you for replying :-). I'm indeed not using APIC (ISTR it was designed for SMP, I don't know what benefit I could get from it considering my laptop is UP). I stopped using ACPI a few months ago as it prevented psm(4) from working (albeit it ACPI+SMP doesn't exhibit the problem) (see [1]). What do you advice me to do? Do you need me to do some testing, enabling ACPI or something like that? I'm at work currently, I will only be able to do this in a couple of hour. Regards, [1] http://lists.freebsd.org/pipermail/freebsd-current/2007-February/069360.html -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-current@FreeBSD.ORG Fri Jul 20 10:17:40 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 021DA16A417; Fri, 20 Jul 2007 10:17:40 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id C738C13C458; Fri, 20 Jul 2007 10:17:39 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 85B3248507; Fri, 20 Jul 2007 06:17:39 -0400 (EDT) Date: Fri, 20 Jul 2007 11:17:39 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Max Laier In-Reply-To: <200707172342.39082.max@love2party.net> Message-ID: <20070720111539.U1096@fledge.watson.org> References: <20070717131518.G1177@fledge.watson.org> <200707172342.39082.max@love2party.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org, freebsd-pf@freebsd.org, freebsd-arch@freebsd.org Subject: Attention pf/ipfw users with uid/gid/jail rules (Re: Reminder: NET_NEEDS_GIANT, debug.mpsafenet going away in 7.0) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2007 10:17:40 -0000 On Tue, 17 Jul 2007, Max Laier wrote: > [ Excess CC-list ... testers needed!!! ] > > On Tuesday 17 July 2007, Robert Watson wrote: >> Dear all: >> >> This is a reminder e-mail that, in the very near future, Giant >> compatibility shims for network protocols will be removed. > > <...> > >> The *only* remaining case I am aware of where removing debug.mpsafenet >> presents an issue is credential-related firewall rules (uid, gid, jail). >> I'm am currently in an active e-mail discussion with the various firewall >> maintainers about how to address this issue; as the implementations of >> these rules violate the global lock order, deadlocks occur if >> debug.mpsafenet isn't set to 1, which causes Giant to act as a guard lock >> preventing parallel lock acquisition in the firewall. Hopefully we will >> have this resolved, in some form, soon. > > What we really need right now, is real understanding of the problem (if > there even is any). So we would like to ask everybody who is able to - to > stress test user/group rules (in pf) or uid/gid/jail rules (in ipfw) with > debug.mpsafenet=1 It is normal that (in an WITNESS enabled kernel) you get a > LOR similar to 14-17 and 32 from [1]. Everything different to those should > be reported. So far I have had 0 (zero) reports of problems since this thread began. Could people using uid/gid/jail rules with ipfw or pf on 7.x *please* try running their firewalls without debug.mpsafenet -- ignore the witness warnings and/or disable witness, and let us know if you experience deadlocks. We're reaching the very end of the merge cycle for 7.0, and I would really like to remove the Giant crutches (now effectively unused) from the network stack so it's not part of the ABI/API, the code is simplified and cleaned up, etc. We'll need to figure out the best way to suppress these witness warnings without suppressing too many other things still. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Fri Jul 20 11:05:17 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EB0B616A41A for ; Fri, 20 Jul 2007 11:05:17 +0000 (UTC) (envelope-from vova@sw.ru) Received: from vbook.fbsd.ru (swsoft-mipt-nat.sw.ru [195.214.233.10]) by mx1.freebsd.org (Postfix) with ESMTP id 9EE2013C45D for ; Fri, 20 Jul 2007 11:05:17 +0000 (UTC) (envelope-from vova@sw.ru) Received: from vova by vbook.fbsd.ru with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IBqII-0000hO-N7; Fri, 20 Jul 2007 15:05:10 +0400 From: Vladimir Grebenschikov To: Mark Hobden In-Reply-To: References: Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable Organization: SWsoft Date: Fri, 20 Jul 2007 15:05:09 +0400 Message-Id: <1184929509.1415.10.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 FreeBSD GNOME Team Port Sender: Vladimir Grebenschikov Cc: freebsd-current@freebsd.org, freebsd-usb@freebsd.org Subject: Re: uhidev(4) update - USB HID driver level for devices with multiple report ids X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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: Fri, 20 Jul 2007 11:05:18 -0000 =F7 =D7=D4, 17/07/2007 =D7 23:05 +0100, Mark Hobden =D0=C9=DB=C5=D4: > I have updated the uhidev(4) patch from NetBSD to apply to today's 7-CURR= ENT. >=20 > http://www.terinea.co.uk/~mark/patches/uhidev-7-current-p2.diff >=20 > The following patch is also required for Microsoft wireless keyboard/mice= sets > and Microsoft wireless notebook mice (but the uhidev patch to be applied = first). >=20 > http://www.terinea.co.uk/~mark/patches/uhidev-add-ms-p2.diff Tries your patch under 7-CURRENT,=20 Both USB keyboard and USB mouse (MS) was not attached after boot, but detected successful. Most probably due to not fixed default entry in devd.conf: attach 100 { device-name "ums[0-9]+"; action "/etc/rc.d/moused start $device-name"; }; ... # When a USB keyboard arrives, attach it as the console keyboard. attach 100 { device-name "ukbd0"; action "/etc/rc.d/syscons setkeyboard /dev/ukbd0"; }; detach 100 { device-name "ukbd0"; action "/etc/rc.d/syscons setkeyboard /dev/kbd0"; }; ... # usbdevs -v=20 ... port 6 addr 2: high speed, self powered, config 1, product 0x4486(0x4486),= vendor 0x04b3(0x04b3), rev 0.01 port 1 powered port 2 powered port 3 powered port 4 powered port 5 addr 3: low speed, power 100 mA, config 1, USB KMp(0x6782), BTC(0x= 046e), rev 1.00 port 6 powered port 7 addr 4: low speed, power 100 mA, config 1, Microsoft 5-Button Mous= e with IntelliEye(TM)(0x0047), Microsoft(0x045e), rev 3.00 port 7 powered port 8 powered part of dmesg: uhub5: 7 ports with 7 removable, self powered uhidev0: on uhub5 uhid0 on uhidev0 uhid0: input=3D8, output=3D1, feature=3D0 uhidev1: on uhub5 uhid1 on uhidev1 uhid1: input=3D3, output=3D0, feature=3D0 uhidev2: on uhub5 uhid2 on uhidev2 I just think may be it fix problem with bluetooth wireless MS mouse, see http://archive.netbsd.se/?ml=3Dfreebsd-bluetooth&a=3D2007-06&m=3D4551687 But not, it does not fix it. --=20 Vladimir B. Grebenschikov vova@fbsd.ru From owner-freebsd-current@FreeBSD.ORG Fri Jul 20 11:39:48 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D747A16A419 for ; Fri, 20 Jul 2007 11:39:48 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from ns.trinitel.com (186.161.36.72.static.reverse.layeredtech.com [72.36.161.186]) by mx1.freebsd.org (Postfix) with ESMTP id B136B13C4A5 for ; Fri, 20 Jul 2007 11:39:48 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from proton.local (209-163-168-124.static.twtelecom.net [209.163.168.124]) (authenticated bits=0) by ns.trinitel.com (8.14.1/8.14.1) with ESMTP id l6KBdltI049477; Fri, 20 Jul 2007 06:39:47 -0500 (CDT) (envelope-from anderson@freebsd.org) Message-ID: <46A09F02.9020302@freebsd.org> Date: Fri, 20 Jul 2007 06:39:46 -0500 From: Eric Anderson User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: kevin kramer References: <469E3B7C.4020402@centtech.com> In-Reply-To: <469E3B7C.4020402@centtech.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on ns.trinitel.com Cc: freebsd-current@freebsd.org Subject: Re: processes stuck in kqread X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Jul 2007 11:39:48 -0000 kevin kramer wrote: > I have been having issues for some time on -CURRENT. My latest update > was 7/11. I have identified these processes as being stuck in kqread > while waiting for them to continue. > > Processes that I know are a problem: > sshd - I can watch a login and the process goes from Select to kqread, > takes about 3-4 minutes to get a login prompt > top - takes about 2-3 minutes to come up > tar - never really even starts to read data in and stays in kqread > > Processes not affected: > scp > gstat Can you show a ps -auxl while one or more processes are in this state? Eric From owner-freebsd-current@FreeBSD.ORG Fri Jul 20 11:44:55 2007 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6573A16A475 for ; Fri, 20 Jul 2007 11:44:55 +0000 (UTC) (envelope-from oleg@lath.rinet.ru) Received: from lath.rinet.ru (lath.rinet.ru [195.54.192.90]) by mx1.freebsd.org (Postfix) with ESMTP id DC02A13C4B6 for ; Fri, 20 Jul 2007 11:44:54 +0000 (UTC) (envelope-from oleg@lath.rinet.ru) Received: from lath.rinet.ru (localhost [127.0.0.1]) by lath.rinet.ru (8.14.1/8.14.1) with ESMTP id l6KBEstm001201 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 Jul 2007 15:14:55 +0400 (MSD) (envelope-from oleg@lath.rinet.ru) Received: (from oleg@localhost) by lath.rinet.ru (8.14.1/8.14.1/Submit) id l6K9JtxR030242; Fri, 20 Jul 2007 13:19:55 +0400 (MSD) (envelope-from oleg) Date: Fri, 20 Jul 2007 13:19:55 +0400 From: Oleg Bulyzhin To: Jeff Roberson Message-ID: <20070720091955.GA18593@lath.rinet.ru> References: <20070717182819.L92541@10.0.0.1> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VS++wcV0S1rZb1Fb" Content-Disposition: inline In-Reply-To: <20070717182819.L92541@10.0.0.1> User-Agent: Mutt/1.5.15 (2007-04-06) Cc: current@FreeBSD.org Subject: Re: cvs commit: src/sys/kern sched_ule.c (fwd) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Jul 2007 11:44:55 -0000 --VS++wcV0S1rZb1Fb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello. Issue with sched_ule.c rev. 1.200: very high load average while my workstation (dual core athlon running smp i386 kernel) is idle: last pid: 30188; load averages: 128.02, 127.75, 127.26 up 1+19:15:58 13:1= 4:58 130 processes: 1 running, 129 sleeping CPU states: 0.2% user, 0.0% nice, 0.7% system, 0.0% interrupt, 99.1% id= le It seems it's slowly increasing (~ 124 -> 128 in 3 hours). P.S. it's Jul 18 kernel, i'll try sched_ule.c rev 1.202 maybe it's already fixed. If you need any additional info --=20 Oleg. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D Oleg Bulyzhin -- OBUL-RIPN -- OBUL-RIPE -- oleg@rinet.ru =3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --VS++wcV0S1rZb1Fb Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGoH46ryLc73jOEF8RAkv4AJ9wNrjFf/5oPzkP3RCi1uSeM/kNUgCaA3u7 ZNY92ET2KTdBm6ngwz6xBJU= =WvM+ -----END PGP SIGNATURE----- --VS++wcV0S1rZb1Fb-- From owner-freebsd-current@FreeBSD.ORG Fri Jul 20 12:01:55 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C8D1A16A468 for ; Fri, 20 Jul 2007 12:01:55 +0000 (UTC) (envelope-from jmadle@tac-tac.cz) Received: from mail.tac-tac.cz (mail.tac-tac.cz [194.212.102.90]) by mx1.freebsd.org (Postfix) with ESMTP id B1C3D13C4A8 for ; Fri, 20 Jul 2007 12:01:54 +0000 (UTC) (envelope-from jmadle@tac-tac.cz) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.tac-tac.cz (Postfix) with ESMTP id 4B4EA276F9 for ; Fri, 20 Jul 2007 14:01:49 +0200 (CEST) Received: from mail.tac-tac.cz ([127.0.0.1]) by localhost (mail [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26628-02 for ; Fri, 20 Jul 2007 14:01:40 +0200 (CEST) Received: from pcjirka (unknown [1.0.0.10]) by mail.tac-tac.cz (Postfix) with SMTP id 8025D276F5 for ; Fri, 20 Jul 2007 14:01:40 +0200 (CEST) Message-ID: <013c01c7cac5$ba6a86a0$0a000001@pcjirka> From: "TAC-TAC computer s.r.o." To: Date: Fri, 20 Jul 2007 14:01:38 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-2"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tac-tac.cz Subject: Re: bge/BCM5704 crashes current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2007 12:01:55 -0000 Hi, I have similar same problem with MB SuperMicro H8SSL-R10 - Dual port Broadcom BCM5704C. System hangs during boot/ifconfig. Jiri Madle #uname -a FreeBSD hell.tac-tac.cz 7.0-CURRENT FreeBSD 7.0-CURRENT #3: Sun Jul 15 13:51:34 CEST 2007 root@hell.tac-tac.cz:/usr/obj/usr/src/sys/TACTAC amd64 ############################################################# Danny Braniss danny at cs.huji.ac.il Tue Jul 3 12:54:43 UTC 2007 Previous message: Panic in ipfw Next message: Panic in ipfw Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] Hi, I trying out an IBM X3455 which has 2 Broadcom BCM5704. they work ok under -stable, but -current just reboots without a trace, no panic, no nothing - actually some garbage on the serial port. I tried wit/and without msi. this is what i get under -stable: bge0 at pci2:1:0: class=0x020000 card=0x02a61014 chip=0x164814e4 rev=0x10 hdr=0x00 vendor = 'Broadcom Corporation' device = 'BCM5704 NetXtreme Dual Gigabit Adapter' class = network subclass = ethernet cap 07[40] = PCI-X 64-bit supports 133MHz, 2048 burst read, 1 split transaction cap 01[48] = powerspec 2 supports D0 D3 current D0 cap 03[50] = VPD cap 05[58] = MSI supports 8 messages, 64 bit bge1 at pci2:1:1: class=0x020000 card=0x02a61014 chip=0x164814e4 rev=0x10 hdr=0x00 vendor = 'Broadcom Corporation' device = 'BCM5704 NetXtreme Dual Gigabit Adapter' class = network subclass = ethernet cap 07[40] = PCI-X 64-bit supports 133MHz, 2048 burst read, 1 split transaction cap 01[48] = powerspec 2 supports D0 D3 current D0 cap 03[50] = VPD cap 05[58] = MSI supports 8 messages, 64 bit From owner-freebsd-current@FreeBSD.ORG Fri Jul 20 12:06:15 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 77E8616A41F for ; Fri, 20 Jul 2007 12:06:15 +0000 (UTC) (envelope-from markhobden@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.228]) by mx1.freebsd.org (Postfix) with ESMTP id 367DE13C491 for ; Fri, 20 Jul 2007 12:06:15 +0000 (UTC) (envelope-from markhobden@gmail.com) Received: by wx-out-0506.google.com with SMTP id i29so711528wxd for ; Fri, 20 Jul 2007 05:06:14 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=UruJs0gt4ZSoyyTyzGAG22aMkde/0TZAkSepsflzV98SBvZ8atnxXPX1nm0fP8cMAqMuYkLMnGElSxbQHCJLPYauhw+A/rkUTYe3oqzM9Crq7F6FT2dLs9L7muYIPuehETyFE+vbuAA0gcXy8Ls1zxuPA+ShBwjEdw+XCxfjEnY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=PDZQveQWRMce7DDnVnRoD6q5VJtzVu2UAfjIt3cDpRNQJmRoRi2rWBLjVZl//POTEYbpJpNWjF9/1fn3hwqm0k5JFIfLtNQcVm3dUNU4yTyF0VVxNlVtcxB0rRtfQFbOkU0v/rn112ltQFap3A9wdL+/P93rbb+oP77ZuWQA6PE= Received: by 10.90.79.6 with SMTP id c6mr200721agb.1184933174601; Fri, 20 Jul 2007 05:06:14 -0700 (PDT) Received: by 10.90.117.10 with HTTP; Fri, 20 Jul 2007 05:06:14 -0700 (PDT) Message-ID: Date: Fri, 20 Jul 2007 13:06:14 +0100 From: "Mark Hobden" To: vova@fbsd.ru In-Reply-To: <1184929509.1415.10.camel@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1184929509.1415.10.camel@localhost> Cc: freebsd-current@freebsd.org, freebsd-usb@freebsd.org Subject: Re: uhidev(4) update - USB HID driver level for devices with multiple report ids X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Jul 2007 12:06:15 -0000 On 20/07/07, Vladimir Grebenschikov wrote: > > Tries your patch under 7-CURRENT, > > Both USB keyboard and USB mouse (MS) was not attached after boot, but > detected successful. Most probably due to not fixed default entry in > devd.conf: > attach 100 { > device-name "ums[0-9]+"; > action "/etc/rc.d/moused start $device-name"; > }; > ... > # When a USB keyboard arrives, attach it as the console keyboard. > attach 100 { > device-name "ukbd0"; > action "/etc/rc.d/syscons setkeyboard /dev/ukbd0"; > }; > detach 100 { > device-name "ukbd0"; > action "/etc/rc.d/syscons setkeyboard /dev/kbd0"; > }; > ... > > part of dmesg: > uhub5: 7 ports with 7 removable, self powered > uhidev0: on uhub5 > uhid0 on uhidev0 > uhid0: input=8, output=1, feature=0 > uhidev1: on uhub5 > uhid1 on uhidev1 > uhid1: input=3, output=0, feature=0 > uhidev2: on uhub5 > uhid2 on uhidev2 Hi Vladimir, Thanks for helping test the patch. devd.conf should be is alright how it is, as keyboards are still ukbd devices and mice are still ums devices. The difference with the patch is they now attach to the uhidev driver level. So what we should be seeing something like this for your mouse - uhidev2: on uhub5 ums0 on uhidev0 ums0: 5 buttons and Z dir and a TILT dir. Before I look into trying to work out how to debug this further could you just confirm to me that ukbd and ums are both either in your kernel or kldload'ed. The following command should show you: # kldstat -v | egrep '(ukbd|ums)' Thanks, Mark From owner-freebsd-current@FreeBSD.ORG Fri Jul 20 12:44:05 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 38ACC16A418 for ; Fri, 20 Jul 2007 12:44:05 +0000 (UTC) (envelope-from staalebk@ifi.uio.no) Received: from smtp.bluecom.no (smtp.bluecom.no [193.75.75.28]) by mx1.freebsd.org (Postfix) with ESMTP id D5F8713C48E for ; Fri, 20 Jul 2007 12:44:04 +0000 (UTC) (envelope-from staalebk@ifi.uio.no) Received: from eschew.pusen.org (unknown [193.69.145.10]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.bluecom.no (Postfix) with ESMTP id 0F84016F94D; Fri, 20 Jul 2007 14:24:40 +0200 (CEST) Received: from chiller by eschew.pusen.org with local (Exim 4.50) id 1IBrXH-0007zT-Jl; Fri, 20 Jul 2007 14:24:43 +0200 Date: Fri, 20 Jul 2007 14:24:43 +0200 From: =?iso-8859-1?Q?St=E5le?= Kristoffersen To: Vince Message-ID: <20070720122443.GA29372@eschew.pusen.org> References: <20070716190441.GA19282@eschew.pusen.org> <20070716213425.GB19282@eschew.pusen.org> <20070718041159.GC37935@cdnetworks.co.kr> <20070718044700.GE37935@cdnetworks.co.kr> <20070718124350.GA25799@eschew.pusen.org> <46A06D8D.1070604@unsane.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <46A06D8D.1070604@unsane.co.uk> User-Agent: Mutt/1.5.13 (2006-08-11) X-Mailman-Approved-At: Fri, 20 Jul 2007 12:53:43 +0000 Cc: current@freebsd.org, =?iso-8859-1?Q?St=E5le?= Kristoffersen Subject: Re: Slow networkperformance in current? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2007 12:44:05 -0000 On 2007-07-20 at 09:08, Vince wrote: > Silly as it might seem when did you last recompile the iperf port? I was > about to post a me too post yesterday, until I updated my system to use > the latest sched_ule at which point iperf froze my system completely, > recompiling the port fixed the freeze and the <100Mbit/sec on localhost. > I think it was compiled against the wrong threading library (been a > while since i last recompiled it.) Actually I just spotted this myself, when I recompiled I got in the range of 600Mbits/sec to localhost. However I do noot see the increase you see when running it multiple times. I still think 600Mbits/sec is a bit low. If I run it to a remote host I see the same numbers (around 600Mbits/sec) -- Ståle Kristoffersen staalebk@ifi.uio.no From owner-freebsd-current@FreeBSD.ORG Fri Jul 20 15:10:25 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4BC8C16A41B for ; Fri, 20 Jul 2007 15:10:25 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.228]) by mx1.freebsd.org (Postfix) with ESMTP id 5E02A13C45E for ; Fri, 20 Jul 2007 15:10:24 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by nz-out-0506.google.com with SMTP id l8so728961nzf for ; Fri, 20 Jul 2007 08:10:21 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=qRHx6yMpiVjrdwUit2yYt8SP9rzDMyBOmLHF4I0AMKeb5YMrkgKswpAX6yDCNaXK4SypHawI+yimzzlFN8rzUkxUK/+dWC98fnyg76Ka9V57As4vD2PillhJFUxs8rmVxM4niBFuX2GQUVFgRXq/bQl+8u048IQ5xqSGUw3DTXU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=mQ83u4ghJotklKJG+wBZ06XnxlvMOpOgGFOtNzqG9pWAi1EfMv1puhmoMJ7e/k6C51tUx8MuqwucjNkEvz2nfKEg7h9/OgUBryOgFK6DxuU2PBtBwp4h1FweUlgrZFJ7Q6ASfViexSPwKxbo6wWhorp9gO6QriXVGWLNiB2cK0w= Received: by 10.114.78.1 with SMTP id a1mr550407wab.1184944220743; Fri, 20 Jul 2007 08:10:20 -0700 (PDT) Received: by 10.114.103.14 with HTTP; Fri, 20 Jul 2007 08:10:20 -0700 (PDT) Message-ID: <2a41acea0707200810n21843c76s9b0f4f37ef92722f@mail.gmail.com> Date: Fri, 20 Jul 2007 08:10:20 -0700 From: "Jack Vogel" To: "=?ISO-8859-1?Q?St=E5le_Kristoffersen?=" In-Reply-To: <20070720122443.GA29372@eschew.pusen.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <20070716190441.GA19282@eschew.pusen.org> <20070716213425.GB19282@eschew.pusen.org> <20070718041159.GC37935@cdnetworks.co.kr> <20070718044700.GE37935@cdnetworks.co.kr> <20070718124350.GA25799@eschew.pusen.org> <46A06D8D.1070604@unsane.co.uk> <20070720122443.GA29372@eschew.pusen.org> Cc: Vince , current@freebsd.org, =?ISO-8859-1?Q?St=E5le_Kristoffersen?= Subject: Re: Slow networkperformance in current? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2007 15:10:25 -0000 On 7/20/07, St=E5le Kristoffersen wrote: > On 2007-07-20 at 09:08, Vince wrote: > > Silly as it might seem when did you last recompile the iperf port? I wa= s > > about to post a me too post yesterday, until I updated my system to use > > the latest sched_ule at which point iperf froze my system completely, > > recompiling the port fixed the freeze and the <100Mbit/sec on localhost= . > > I think it was compiled against the wrong threading library (been a > > while since i last recompiled it.) > > Actually I just spotted this myself, when I recompiled I got in the range > of 600Mbits/sec to localhost. However I do noot see the increase you see > when running it multiple times. I still think 600Mbits/sec is a bit low. > > If I run it to a remote host I see the same numbers (around 600Mbits/sec) I am actually quite impressed with the stack right now, with our new Oplin hardware and the ixgbe driver I have 9.8 Gb/s pumping thru it. Of course its all about adequate hardware, configuration, and tuning. Cheers, Jack From owner-freebsd-current@FreeBSD.ORG Fri Jul 20 15:54:36 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 42ACA16A420; Fri, 20 Jul 2007 15:54:36 +0000 (UTC) (envelope-from vova@sw.ru) Received: from vbook.fbsd.ru (swsoft-mipt-nat.sw.ru [195.214.233.10]) by mx1.freebsd.org (Postfix) with ESMTP id A506C13C480; Fri, 20 Jul 2007 15:54:34 +0000 (UTC) (envelope-from vova@sw.ru) Received: from vova by vbook.fbsd.ru with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IBuoJ-0000N5-AT; Fri, 20 Jul 2007 19:54:31 +0400 From: Vladimir Grebenschikov To: Mark Hobden In-Reply-To: References: <1184929509.1415.10.camel@localhost> Content-Type: multipart/mixed; boundary="=-ZdFHW9IuT3ROeLbPzQWB" Organization: SWsoft Date: Fri, 20 Jul 2007 19:54:30 +0400 Message-Id: <1184946870.1356.2.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 FreeBSD GNOME Team Port Sender: Vladimir Grebenschikov Cc: freebsd-current@freebsd.org, freebsd-usb@freebsd.org Subject: Re: uhidev(4) update - USB HID driver level for devices with multiple report ids X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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: Fri, 20 Jul 2007 15:54:36 -0000 --=-ZdFHW9IuT3ROeLbPzQWB Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable =F7 =D0=D4, 20/07/2007 =D7 13:06 +0100, Mark Hobden =D0=C9=DB=C5=D4: > Thanks for helping test the patch. >=20 > devd.conf should be is alright how it is, as keyboards are still ukbd > devices and mice are still ums devices. The difference with the patch > is they now attach to the uhidev driver level. >=20 > So what we should be seeing something like this for your mouse - >=20 > uhidev2: class 0/0, rev 1.10/3.00, addr 4> on uhub5 > ums0 on uhidev0 > ums0: 5 buttons and Z dir and a TILT dir. >=20 > Before I look into trying to work out how to debug this further could > you > just confirm to me that ukbd and ums are both either in your kernel or > kldload'ed. They was failed to load as modules (from loader.conf): (kernel was rebuilt entirely) link_elf: symbol hid_start_parse undefined KLD file ukbd.ko - could not finalize loading link_elf: symbol hid_locate undefined KLD file ums.ko - could not finalize loading see full dmesg -v and usbdevs -d -v in attachment > Mark --=20 Vladimir B. Grebenschikov vova@fbsd.ru --=-ZdFHW9IuT3ROeLbPzQWB Content-Disposition: attachment; filename=dmesg-v Content-Type: text/plain; name=dmesg-v; charset=KOI8-R Content-Transfer-Encoding: base64 Q29weXJpZ2h0IChjKSAxOTkyLTIwMDcgVGhlIEZyZWVCU0QgUHJvamVjdC4NCkNvcHlyaWdodCAo YykgMTk3OSwgMTk4MCwgMTk4MywgMTk4NiwgMTk4OCwgMTk4OSwgMTk5MSwgMTk5MiwgMTk5Mywg MTk5NA0KCVRoZSBSZWdlbnRzIG9mIHRoZSBVbml2ZXJzaXR5IG9mIENhbGlmb3JuaWEuIEFsbCBy aWdodHMgcmVzZXJ2ZWQuDQpGcmVlQlNEIGlzIGEgcmVnaXN0ZXJlZCB0cmFkZW1hcmsgb2YgVGhl IEZyZWVCU0QgRm91bmRhdGlvbi4NCkZyZWVCU0QgNy4wLUNVUlJFTlQgIzMzOiBGcmkgSnVsIDIw IDE1OjI1OjMwIE1TRCAyMDA3DQogICAgcm9vdEB2Ym9vay5mYnNkLnJ1Oi91c3Ivb2JqL3Vzci9z cmMvc3lzL1ZCT09LDQpQcmVsb2FkZWQgZWxmIGtlcm5lbCAiL2Jvb3Qva2VybmVsL2tlcm5lbCIg YXQgMHhjMDlkYjAwMC4NClByZWxvYWRlZCBlbGYgbW9kdWxlICIvYm9vdC9rZXJuZWwvdmVzYS5r byIgYXQgMHhjMDlkYjI0OC4NClByZWxvYWRlZCBlbGYgbW9kdWxlICIvYm9vdC9rZXJuZWwvbXNk b3Nmcy5rbyIgYXQgMHhjMDlkYjJmNC4NClByZWxvYWRlZCBlbGYgbW9kdWxlICIvYm9vdC9rZXJu ZWwvbnRmcy5rbyIgYXQgMHhjMDlkYjNhMC4NClByZWxvYWRlZCBlbGYgbW9kdWxlICIvYm9vdC9r ZXJuZWwvZ2VvbV9sYWJlbC5rbyIgYXQgMHhjMDlkYjQ0Yy4NClByZWxvYWRlZCBlbGYgbW9kdWxl ICIvYm9vdC9rZXJuZWwvbGludXgua28iIGF0IDB4YzA5ZGI0ZmMuDQpQcmVsb2FkZWQgZWxmIG1v ZHVsZSAiL2Jvb3Qva2VybmVsL3N5c3Ztc2cua28iIGF0IDB4YzA5ZGI1YTguDQpQcmVsb2FkZWQg ZWxmIG1vZHVsZSAiL2Jvb3Qva2VybmVsL3N5c3ZzZW0ua28iIGF0IDB4YzA5ZGI2NTQuDQpQcmVs b2FkZWQgZWxmIG1vZHVsZSAiL2Jvb3Qva2VybmVsL3N5c3ZzaG0ua28iIGF0IDB4YzA5ZGI3MDAu DQpQcmVsb2FkZWQgZWxmIG1vZHVsZSAiL2Jvb3Qva2VybmVsL2lmX2VtLmtvIiBhdCAweGMwOWRi N2FjLg0KUHJlbG9hZGVkIGVsZiBtb2R1bGUgIi9ib290L2tlcm5lbC9zbmRfaGRhLmtvIiBhdCAw eGMwOWRiODU4Lg0KUHJlbG9hZGVkIGVsZiBtb2R1bGUgIi9ib290L2tlcm5lbC9zb3VuZC5rbyIg YXQgMHhjMDlkYjkwNC4NClByZWxvYWRlZCBlbGYgbW9kdWxlICIvYm9vdC9rZXJuZWwvdXNiLmtv IiBhdCAweGMwOWRiOWIwLg0KUHJlbG9hZGVkIGVsZiBtb2R1bGUgIi9ib290L2tlcm5lbC91Z2Vu LmtvIiBhdCAweGMwOWRiYTU4Lg0KUHJlbG9hZGVkIGVsZiBtb2R1bGUgIi9ib290L2tlcm5lbC91 a2JkLmtvIiBhdCAweGMwOWRiYjA0Lg0KUHJlbG9hZGVkIGVsZiBtb2R1bGUgIi9ib290L2tlcm5l bC91aGlkLmtvIiBhdCAweGMwOWRiYmIwLg0KUHJlbG9hZGVkIGVsZiBtb2R1bGUgIi9ib290L2tl cm5lbC91bHB0LmtvIiBhdCAweGMwOWRiYzVjLg0KUHJlbG9hZGVkIGVsZiBtb2R1bGUgIi9ib290 L2tlcm5lbC91bXMua28iIGF0IDB4YzA5ZGJkMDguDQpQcmVsb2FkZWQgZWxmIG1vZHVsZSAiL2Jv b3Qva2VybmVsL3VtYXNzLmtvIiBhdCAweGMwOWRiZGIwLg0KUHJlbG9hZGVkIGVsZiBtb2R1bGUg Ii9ib290L2tlcm5lbC9hZ3Aua28iIGF0IDB4YzA5ZGJlNWMuDQpQcmVsb2FkZWQgZWxmIG1vZHVs ZSAiL2Jvb3Qva2VybmVsL2FjcGlfdmlkZW8ua28iIGF0IDB4YzA5ZGJmMDQuDQpQcmVsb2FkZWQg ZWxmIG1vZHVsZSAiL2Jvb3Qva2VybmVsL2NwdWZyZXEua28iIGF0IDB4YzA5ZGJmYjQuDQpQcmVs b2FkZWQgZWxmIG1vZHVsZSAiL2Jvb3Qva2VybmVsL3NtYmZzLmtvIiBhdCAweGMwOWRjMDYwLg0K UHJlbG9hZGVkIGVsZiBtb2R1bGUgIi9ib290L2tlcm5lbC9saWJpY29udi5rbyIgYXQgMHhjMDlk YzEwYy4NClByZWxvYWRlZCBlbGYgbW9kdWxlICIvYm9vdC9rZXJuZWwvbGlibWNoYWluLmtvIiBh dCAweGMwOWRjMWJjLg0KUHJlbG9hZGVkIGVsZiBtb2R1bGUgIi9ib290L2tlcm5lbC9uZ191YnQu a28iIGF0IDB4YzA5ZGMyNmMuDQpQcmVsb2FkZWQgZWxmIG1vZHVsZSAiL2Jvb3Qva2VybmVsL25l dGdyYXBoLmtvIiBhdCAweGMwOWRjMzE4Lg0KUHJlbG9hZGVkIGVsZiBtb2R1bGUgIi9ib290L2tl cm5lbC93bGFuX3hhdXRoLmtvIiBhdCAweGMwOWRjM2M4Lg0KUHJlbG9hZGVkIGVsZiBtb2R1bGUg Ii9ib290L2tlcm5lbC93bGFuLmtvIiBhdCAweGMwOWRjNDc4Lg0KUHJlbG9hZGVkIGVsZiBtb2R1 bGUgIi9ib290L2tlcm5lbC93bGFuX3dlcC5rbyIgYXQgMHhjMDlkYzUyNC4NClByZWxvYWRlZCBl bGYgbW9kdWxlICIvYm9vdC9rZXJuZWwvd2xhbl90a2lwLmtvIiBhdCAweGMwOWRjNWQ0Lg0KUHJl bG9hZGVkIGVsZiBtb2R1bGUgIi9ib290L2tlcm5lbC93bGFuX3NjYW5fc3RhLmtvIiBhdCAweGMw OWRjNjg0Lg0KUHJlbG9hZGVkIGVsZiBtb2R1bGUgIi9ib290L2tlcm5lbC9hY3BpX2libS5rbyIg YXQgMHhjMDlkYzczOC4NClByZWxvYWRlZCBlbGYgbW9kdWxlICIvYm9vdC9rZXJuZWwvYWNwaV9k b2NrLmtvIiBhdCAweGMwOWRjN2U4Lg0KUHJlbG9hZGVkIGVsZiBtb2R1bGUgIi9ib290L2tlcm5l bC9jYmIua28iIGF0IDB4YzA5ZGM4OTguDQpQcmVsb2FkZWQgZWxmIG1vZHVsZSAiL2Jvb3Qva2Vy bmVsL2V4Y2Eua28iIGF0IDB4YzA5ZGM5NDAuDQpQcmVsb2FkZWQgZWxmIG1vZHVsZSAiL2Jvb3Qv a2VybmVsL3BjY2FyZC5rbyIgYXQgMHhjMDlkYzllYy4NClByZWxvYWRlZCBlbGYgbW9kdWxlICIv Ym9vdC9rZXJuZWwvYXRhY2FyZC5rbyIgYXQgMHhjMDlkY2E5OC4NClByZWxvYWRlZCBlbGYgbW9k dWxlICIvYm9vdC9rZXJuZWwvdmtiZC5rbyIgYXQgMHhjMDlkY2I0NC4NClByZWxvYWRlZCBlbGYg bW9kdWxlICIvYm9vdC9rZXJuZWwva2JkbXV4LmtvIiBhdCAweGMwOWRjYmYwLg0KbGlua19lbGY6 IHN5bWJvbCBoaWRfc3RhcnRfcGFyc2UgdW5kZWZpbmVkDQpLTEQgZmlsZSB1a2JkLmtvIC0gY291 bGQgbm90IGZpbmFsaXplIGxvYWRpbmcNCmxpbmtfZWxmOiBzeW1ib2wgaGlkX2xvY2F0ZSB1bmRl ZmluZWQNCktMRCBmaWxlIHVtcy5rbyAtIGNvdWxkIG5vdCBmaW5hbGl6ZSBsb2FkaW5nDQpUYWJs ZSAnRkFDUCcgYXQgMHg3ZmVkMTUwMA0KVGFibGUgJ1NTRFQnIGF0IDB4N2ZlZDE2YjQNClRhYmxl ICdFQ0RUJyBhdCAweDdmZWRlYzA3DQpUYWJsZSAnVENQQScgYXQgMHg3ZmVkZWM1OQ0KVGFibGUg J0FQSUMnIGF0IDB4N2ZlZGVjOGINCk1BRFQ6IEZvdW5kIHRhYmxlIGF0IDB4N2ZlZGVjOGINCk1Q IENvbmZpZ3VyYXRpb24gVGFibGUgdmVyc2lvbiAxLjQgZm91bmQgYXQgMHhjMDA5ZjVhMQ0KQVBJ QzogVXNpbmcgdGhlIE1BRFQgZW51bWVyYXRvci4NCk1BRFQ6IEZvdW5kIENQVSBBUElDIElEIDAg QUNQSSBJRCAwOiBlbmFibGVkDQpTTVA6IEFkZGVkIENQVSAwIChBUCkNCk1BRFQ6IEZvdW5kIENQ VSBBUElDIElEIDEgQUNQSSBJRCAxOiBlbmFibGVkDQpTTVA6IEFkZGVkIENQVSAxIChBUCkNCkFD UEkgQVBJQyBUYWJsZTogPExFTk9WTyBUUC03OSAgID4NCkNhbGlicmF0aW5nIGNsb2NrKHMpIC4u LiBpODI1NCBjbG9jazogMTE5MzIxMSBIeg0KQ0xLX1VTRV9JODI1NF9DQUxJQlJBVElPTiBub3Qg c3BlY2lmaWVkIC0gdXNpbmcgZGVmYXVsdCBmcmVxdWVuY3kNClRpbWVjb3VudGVyICJpODI1NCIg ZnJlcXVlbmN5IDExOTMxODIgSHogcXVhbGl0eSAwDQpDYWxpYnJhdGluZyBUU0MgY2xvY2sgLi4u IFRTQyBjbG9jazogMTk5NTAxMjc4MCBIeg0KQ1BVOiBJbnRlbChSKSBDb3JlKFRNKTIgQ1BVICAg ICAgICAgVDcyMDAgIEAgMi4wMEdIeiAoMTk5NS4wMS1NSHogNjg2LWNsYXNzIENQVSkNCiAgT3Jp Z2luID0gIkdlbnVpbmVJbnRlbCIgIElkID0gMHg2ZjYgIFN0ZXBwaW5nID0gNg0KICBGZWF0dXJl cz0weGJmZWJmYmZmPEZQVSxWTUUsREUsUFNFLFRTQyxNU1IsUEFFLE1DRSxDWDgsQVBJQyxTRVAs TVRSUixQR0UsTUNBLENNT1YsUEFULFBTRTM2LENMRkxVU0gsRFRTLEFDUEksTU1YLEZYU1IsU1NF LFNTRTIsU1MsSFRULFRNLFBCRT4NCiAgRmVhdHVyZXMyPTB4ZTNiZDxTU0UzLFJTVkQyLE1PTixE U19DUEwsVk1YLEVTVCxUTTIsU1NTRTMsQ1gxNix4VFBSLFBEQ00+DQogIEFNRCBGZWF0dXJlcz0w eDIwMTAwMDAwPE5YLExNPg0KICBBTUQgRmVhdHVyZXMyPTB4MTxMQUhGPg0KICBDb3JlcyBwZXIg cGFja2FnZTogMg0KDQpJbnN0cnVjdGlvbiBUTEI6IDQgS0IgUGFnZXMsIDQtd2F5IHNldCBhc3Nv Y2lhdGl2ZSwgMTI4IGVudHJpZXMNCjFzdC1sZXZlbCBpbnN0cnVjdGlvbiBjYWNoZTogMzIgS0Is IDgtd2F5IHNldCBhc3NvY2lhdGl2ZSwgNjQgYnl0ZSBsaW5lIHNpemUNCjFzdC1sZXZlbCBkYXRh IGNhY2hlOiAzMiBLQiwgOC13YXkgc2V0IGFzc29jaWF0aXZlLCA2NCBieXRlIGxpbmUgc2l6ZQ0K TDIgY2FjaGU6IDQwOTYga2J5dGVzLCAxNi13YXkgYXNzb2NpYXRpdmUsIDY0IGJ5dGVzL2xpbmUN CnJlYWwgbWVtb3J5ICA9IDIxNDYyMzg0NjQgKDIwNDYgTUIpDQpQaHlzaWNhbCBtZW1vcnkgY2h1 bmsocyk6DQoweDAwMDAwMDAwMDAwMDEwMDAgLSAweDAwMDAwMDAwMDAwOWRmZmYsIDY0MzA3MiBi eXRlcyAoMTU3IHBhZ2VzKQ0KMHgwMDAwMDAwMDAwMTAwMDAwIC0gMHgwMDAwMDAwMDAwM2ZmZmZm LCAzMTQ1NzI4IGJ5dGVzICg3NjggcGFnZXMpDQoweDAwMDAwMDAwMDBjMjgwMDAgLSAweDAwMDAw MDAwN2RhODRmZmYsIDIwOTU0MzU3NzYgYnl0ZXMgKDUxMTU4MSBwYWdlcykNCmF2YWlsIG1lbW9y eSA9IDIwOTQ3OTY4MDAgKDE5OTcgTUIpDQpJTlRSOiBBZGRpbmcgbG9jYWwgQVBJQyAxIGFzIGEg dGFyZ2V0DQpGcmVlQlNEL1NNUDogTXVsdGlwcm9jZXNzb3IgU3lzdGVtIERldGVjdGVkOiAyIENQ VXMNCiBjcHUwIChCU1ApOiBBUElDIElEOiAgMA0KIGNwdTEgKEFQKTogQVBJQyBJRDogIDENCmJp b3MzMjogRm91bmQgQklPUzMyIFNlcnZpY2UgRGlyZWN0b3J5IGhlYWRlciBhdCAweGMwMGY2Nzkw DQpiaW9zMzI6IEVudHJ5ID0gMHhmZDZiMCAoYzAwZmQ2YjApICBSZXYgPSAwICBMZW4gPSAxDQpw Y2liaW9zOiBQQ0kgQklPUyBlbnRyeSBhdCAweGZkNjQwKzB4MjBiDQpwbnBiaW9zOiBGb3VuZCBQ blAgQklPUyBkYXRhIGF0IDB4YzAwZjY4MjANCnBucGJpb3M6IEVudHJ5ID0gZjAwMDA6YjM3ZSAg UmV2ID0gMS4wDQpPdGhlciBCSU9TIHNpZ25hdHVyZXMgZm91bmQ6DQpBUElDOiBDUFUgMCBoYXMg QUNQSSBJRCAwDQpBUElDOiBDUFUgMSBoYXMgQUNQSSBJRCAxDQpBQ1BJOiBSU0RQIEAgMHgweGY2 N2QwLzB4MDAyNCAodiAgMiBMRU5PVk8pDQpBQ1BJOiBYU0RUIEAgMHgweDdmZWQxM2UwLzB4MDA4 QyAodiAgMSBMRU5PVk8gVFAtNzkgICAgMHgwMDAwMjEzMCAgTFRQIDB4MDAwMDAwMDApDQpBQ1BJ OiBGQUNQIEAgMHgweDdmZWQxNTAwLzB4MDBGNCAodiAgMyBMRU5PVk8gVFAtNzkgICAgMHgwMDAw MjEzMCBMTlZPIDB4MDAwMDAwMDEpDQpBQ1BJIFdhcm5pbmcgKHRiZmFkdC0wNTA1KTogT3B0aW9u YWwgZmllbGQgIkdwZTFCbG9jayIgaGFzIHplcm8gYWRkcmVzcyBvciBsZW5ndGg6ICAgICAgICAw ICAgIDEwMkMvMCBbMjAwNzAzMjBdDQpBQ1BJOiBEU0RUIEAgMHgweDdmZWQxODVlLzB4RDNBOSAo diAgMSBMRU5PVk8gVFAtNzkgICAgMHgwMDAwMjEzMCBNU0ZUIDB4MDEwMDAwMEUpDQpBQ1BJOiBG QUNTIEAgMHgweDdmZWY0MDAwLzB4MDA0MA0KQUNQSTogU1NEVCBAIDB4MHg3ZmVkMTZiNC8weDAx QUEgKHYgIDEgTEVOT1ZPIFRQLTc5ICAgIDB4MDAwMDIxMzAgTVNGVCAweDAxMDAwMDBFKQ0KQUNQ STogRUNEVCBAIDB4MHg3ZmVkZWMwNy8weDAwNTIgKHYgIDEgTEVOT1ZPIFRQLTc5ICAgIDB4MDAw MDIxMzAgTE5WTyAweDAwMDAwMDAxKQ0KQUNQSTogVENQQSBAIDB4MHg3ZmVkZWM1OS8weDAwMzIg KHYgIDIgTEVOT1ZPIFRQLTc5ICAgIDB4MDAwMDIxMzAgTE5WTyAweDAwMDAwMDAxKQ0KQUNQSTog QVBJQyBAIDB4MHg3ZmVkZWM4Yi8weDAwNjggKHYgIDEgTEVOT1ZPIFRQLTc5ICAgIDB4MDAwMDIx MzAgTE5WTyAweDAwMDAwMDAxKQ0KQUNQSTogTUNGRyBAIDB4MHg3ZmVkZWNmMy8weDAwM0MgKHYg IDEgTEVOT1ZPIFRQLTc5ICAgIDB4MDAwMDIxMzAgTE5WTyAweDAwMDAwMDAxKQ0KQUNQSTogSFBF VCBAIDB4MHg3ZmVkZWQyZi8weDAwMzggKHYgIDEgTEVOT1ZPIFRQLTc5ICAgIDB4MDAwMDIxMzAg TE5WTyAweDAwMDAwMDAxKQ0KQUNQSTogU0xJQyBAIDB4MHg3ZmVkZWU2Mi8weDAxNzYgKHYgIDEg TEVOT1ZPIFRQLTc5ICAgIDB4MDAwMDIxMzAgIExUUCAweDAwMDAwMDAwKQ0KQUNQSTogQk9PVCBA IDB4MHg3ZmVkZWZkOC8weDAwMjggKHYgIDEgTEVOT1ZPIFRQLTc5ICAgIDB4MDAwMDIxMzAgIExU UCAweDAwMDAwMDAxKQ0KQUNQSTogU1NEVCBAIDB4MHg3ZmVmMjY5Ny8weDAyNUYgKHYgIDEgTEVO T1ZPIFRQLTc5ICAgIDB4MDAwMDIxMzAgSU5UTCAweDIwMDUwNTEzKQ0KQUNQSTogU1NEVCBAIDB4 MHg3ZmVmMjhmNi8weDAwQTYgKHYgIDEgTEVOT1ZPIFRQLTc5ICAgIDB4MDAwMDIxMzAgSU5UTCAw eDIwMDUwNTEzKQ0KQUNQSTogU1NEVCBAIDB4MHg3ZmVmMjk5Yy8weDA0RjcgKHYgIDEgTEVOT1ZP IFRQLTc5ICAgIDB4MDAwMDIxMzAgSU5UTCAweDIwMDUwNTEzKQ0KQUNQSTogU1NEVCBAIDB4MHg3 ZmVmMmU5My8weDAxRDggKHYgIDEgTEVOT1ZPIFRQLTc5ICAgIDB4MDAwMDIxMzAgSU5UTCAweDIw MDUwNTEzKQ0KTUFEVDogRm91bmQgSU8gQVBJQyBJRCAxLCBJbnRlcnJ1cHQgMCBhdCAweGZlYzAw MDAwDQppb2FwaWMwOiBDaGFuZ2luZyBBUElDIElEIHRvIDENCmlvYXBpYzA6IFJvdXRpbmcgZXh0 ZXJuYWwgODI1OUEncyAtPiBpbnRwaW4gMA0KTUFEVDogSW50ZXJydXB0IG92ZXJyaWRlOiBzb3Vy Y2UgMCwgaXJxIDINCmlvYXBpYzA6IFJvdXRpbmcgSVJRIDAgLT4gaW50cGluIDINCk1BRFQ6IElu dGVycnVwdCBvdmVycmlkZTogc291cmNlIDksIGlycSA5DQppb2FwaWMwOiBpbnRwaW4gOSB0cmln Z2VyOiBsZXZlbA0KbGFwaWMwOiBSb3V0aW5nIE5NSSAtPiBMSU5UMQ0KbGFwaWMwOiBMSU5UMSB0 cmlnZ2VyOiBlZGdlDQpsYXBpYzA6IExJTlQxIHBvbGFyaXR5OiBoaWdoDQpsYXBpYzE6IFJvdXRp bmcgTk1JIC0+IExJTlQxDQpsYXBpYzE6IExJTlQxIHRyaWdnZXI6IGVkZ2UNCmxhcGljMTogTElO VDEgcG9sYXJpdHk6IGhpZ2gNCmlvYXBpYzAgPFZlcnNpb24gMi4wPiBpcnFzIDAtMjMgb24gbW90 aGVyYm9hcmQNCmNwdTAgQlNQOg0KICAgICBJRDogMHgwMDAwMDAwMCAgIFZFUjogMHgwMDA1MDAx NCBMRFI6IDB4MDAwMDAwMDAgREZSOiAweGZmZmZmZmZmDQogIGxpbnQwOiAweDAwMDEwNzAwIGxp bnQxOiAweDAwMDAwNDAwIFRQUjogMHgwMDAwMDAwMCBTVlI6IDB4MDAwMDAxZmYNCiAgdGltZXI6 IDB4MDAwMTAwZWYgdGhlcm06IDB4MDAwMTAwMDAgZXJyOiAweDAwMDEwMDAwIHBjbTogMHgwMDAx MDAwMA0Kd2xhbjogPDgwMi4xMSBMaW5rIExheWVyPg0Kc25kX3VuaXRfaW5pdCgpIHU9MHgwMGZm ODAwMCBbNTEyXSBkPTB4MDAwMDdjMDAgWzMyXSBjPTB4MDAwMDAzZmYgWzEwMjRdDQpmZWVkZXJf cmVnaXN0ZXI6IHNuZF91bml0PS0xIHNuZF9tYXhhdXRvdmNoYW5zPTE2IGxhdGVuY3k9NSBmZWVk ZXJfYnVmZmVyc2l6ZT0xNjM4NCBmZWVkZXJfcmF0ZV9taW49MSBmZWVkZXJfcmF0ZV9tYXg9MjAx NjAwMCBmZWVkZXJfcmF0ZV9yb3VuZD0yNQ0KVkVTQTogaW5mb3JtYXRpb24gYmxvY2sNCjU2IDQ1 IDUzIDQxIDAwIDAzIDUwIDAyIDAwIGMwIDAxIDAwIDAwIDAwIDQ0IDAwIA0KMDAgMDEgMDAgMDEg MGMgMDkgODkgMDEgMDAgYzAgOTQgMDAgMDAgYzAgNzggNTQgDQowMCBjMCAwMCAwMCAwMCAwMCAw MCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCANCjAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAw IDAwIDAwIDAwIDAwIDAwIDAwIDAwIA0KVkVTQTogNzEgbW9kZShzKSBmb3VuZA0KVkVTQTogdjMu MCwgMTYzODRrIG1lbW9yeSwgZmxhZ3M6MHgxLCBtb2RlIHRhYmxlOjB4YzA3Yzg3NDQgKDEwMDAw NDQpDQpWRVNBOiBBVEkgQVRPTUJJT1MNClZFU0E6IChDKSAxOTg4LTIwMDUsIEFUSSBUZWNobm9s b2dpZXMgSW5jLiAgTTY0Q1NQIDAxLjAwDQptZW06IDxtZW1vcnk+DQpQZW50aXVtIFBybyBNVFJS IHN1cHBvcnQgZW5hYmxlZA0KbnVsbDogPG51bGwgZGV2aWNlLCB6ZXJvIGRldmljZT4NCnJhbmRv bTogPGVudHJvcHkgc291cmNlLCBTb2Z0d2FyZSwgWWFycm93Pg0KaW86IDxJL08+DQpuZXRzbWJf ZGV2OiBsb2FkZWQNCmtiZDogbmV3IGFycmF5IHNpemUgNA0Ka2JkMSBhdCBrYmRtdXgwDQpucHgw OiBJTlQgMTYgaW50ZXJmYWNlDQphY3BpMDogPExFTk9WTyBUUC03OT4gb24gbW90aGVyYm9hcmQN CmlvYXBpYzA6IHJvdXRpbmcgaW50cGluIDkgKElTQSBJUlEgOSkgdG8gdmVjdG9yIDQ4DQphY3Bp MDogW01QU0FGRV0NCmFjcGkwOiBbSVRIUkVBRF0NCmFjcGlfZWMwOiA8RW1iZWRkZWQgQ29udHJv bGxlcjogR1BFIDB4MWMsIEVDRFQ+IHBvcnQgMHg2MiwweDY2IG9uIGFjcGkwDQphY3BpX2hwZXQw OiA8SGlnaCBQcmVjaXNpb24gRXZlbnQgVGltZXI+IGlvbWVtIDB4ZmVkMDAwMDAtMHhmZWQwMDNm ZiBvbiBhY3BpMA0KYWNwaV9ocGV0MDogdmVuZDogMHg4MDg2IHJldjogMHgxIG51bTogMSBoejog MTQzMTgxODAgb3B0czogbGVnX3JvdXRlIGNvdW50X3NpemUNClRpbWVjb3VudGVyICJIUEVUIiBm cmVxdWVuY3kgMTQzMTgxODAgSHogcXVhbGl0eSAyMDAwDQpwY2lfb3BlbigxKToJbW9kZSAxIGFk ZHIgcG9ydCAoMHgwY2Y4KSBpcyAweDgwMDBmYTA0DQpwY2lfb3BlbigxYSk6CW1vZGUxcmVzPTB4 ODAwMDAwMDAgKDB4ODAwMDAwMDApDQpwY2lfY2ZnY2hlY2s6CWRldmljZSAwIFtjbGFzcz0wNjAw MDBdIFtoZHI9MDBdIGlzIHRoZXJlIChpZD0yN2EwODA4NikNCnBjaWJpb3M6IEJJT1MgdmVyc2lv biAyLjEwDQpBY3BpT3NEZXJpdmVQY2lJZDogXFxfU0JfLlBDSTAuTUhDUyAtPiBidXMgMCBkZXYg MCBmdW5jIDANCkFjcGlPc0Rlcml2ZVBjaUlkOiBcXF9TQl8uUENJMC5VU0I3LlU3Q1MgLT4gYnVz IDAgZGV2IDI5IGZ1bmMgNw0KYWNwaTA6IFBvd2VyIEJ1dHRvbiAoZml4ZWQpDQphY3BpMDogd2Fr ZXVwIGNvZGUgdmEgMHhkOGM5NTAwMCBwYSAweDEwMDANCkFjcGlPc0Rlcml2ZVBjaUlkOiBcXF9T Ql8uUENJMC5MUENfLkxQQ1MgLT4gYnVzIDAgZGV2IDMxIGZ1bmMgMA0KYWNwaTA6IHJlc2VydmF0 aW9uIG9mIDAsIGEwMDAwICgzKSBmYWlsZWQNCmFjcGkwOiByZXNlcnZhdGlvbiBvZiAxMDAwMDAs IDdmZjAwMDAwICgzKSBmYWlsZWQNCmFjcGkwOiByZXNlcnZhdGlvbiBvZiBmZWMwMDAwMCwgMTQw MDAwICgzKSBmYWlsZWQNCkFDUEkgdGltZXI6IDEvMSAxLzEgMS8xIDEvMSAxLzEgMS8xIDEvMSAx LzEgMS8xIDEvMSAtPiAxMA0KVGltZWNvdW50ZXIgIkFDUEktZmFzdCIgZnJlcXVlbmN5IDM1Nzk1 NDUgSHogcXVhbGl0eSAxMDAwDQphY3BpX3RpbWVyMDogPDI0LWJpdCB0aW1lciBhdCAzLjU3OTU0 NU1Iej4gcG9ydCAweDEwMDgtMHgxMDBiIG9uIGFjcGkwDQpwY2lfbGluazA6ICAgICAgICBJbmRl eCAgSVJRICBSdGQgIFJlZiAgSVJRcw0KICBJbml0aWFsIFByb2JlICAgICAgIDAgICAxMSAgIE4g ICAgIDAgIDMgNCA1IDYgNyA5IDEwIDExDQogIFZhbGlkYXRpb24gICAgICAgICAgMCAgIDExICAg TiAgICAgMCAgMyA0IDUgNiA3IDkgMTAgMTENCiAgQWZ0ZXIgRGlzYWJsZSAgICAgICAwICAyNTUg ICBOICAgICAwICAzIDQgNSA2IDcgOSAxMCAxMQ0KcGNpX2xpbmsxOiAgICAgICAgSW5kZXggIElS USAgUnRkICBSZWYgIElSUXMNCiAgSW5pdGlhbCBQcm9iZSAgICAgICAwICAgMTEgICBOICAgICAw ICAzIDQgNSA2IDcgOSAxMCAxMQ0KICBWYWxpZGF0aW9uICAgICAgICAgIDAgICAxMSAgIE4gICAg IDAgIDMgNCA1IDYgNyA5IDEwIDExDQogIEFmdGVyIERpc2FibGUgICAgICAgMCAgMjU1ICAgTiAg ICAgMCAgMyA0IDUgNiA3IDkgMTAgMTENCnBjaV9saW5rMjogICAgICAgIEluZGV4ICBJUlEgIFJ0 ZCAgUmVmICBJUlFzDQogIEluaXRpYWwgUHJvYmUgICAgICAgMCAgIDExICAgTiAgICAgMCAgMyA0 IDUgNiA3IDkgMTAgMTENCiAgVmFsaWRhdGlvbiAgICAgICAgICAwICAgMTEgICBOICAgICAwICAz IDQgNSA2IDcgOSAxMCAxMQ0KICBBZnRlciBEaXNhYmxlICAgICAgIDAgIDI1NSAgIE4gICAgIDAg IDMgNCA1IDYgNyA5IDEwIDExDQpwY2lfbGluazM6ICAgICAgICBJbmRleCAgSVJRICBSdGQgIFJl ZiAgSVJRcw0KICBJbml0aWFsIFByb2JlICAgICAgIDAgICAxMSAgIE4gICAgIDAgIDMgNCA1IDYg NyA5IDEwIDExDQogIFZhbGlkYXRpb24gICAgICAgICAgMCAgIDExICAgTiAgICAgMCAgMyA0IDUg NiA3IDkgMTAgMTENCiAgQWZ0ZXIgRGlzYWJsZSAgICAgICAwICAyNTUgICBOICAgICAwICAzIDQg NSA2IDcgOSAxMCAxMQ0KcGNpX2xpbms0OiAgICAgICAgSW5kZXggIElSUSAgUnRkICBSZWYgIElS UXMNCiAgSW5pdGlhbCBQcm9iZSAgICAgICAwICAgMTEgICBOICAgICAwICAzIDQgNSA2IDcgOSAx MCAxMQ0KICBWYWxpZGF0aW9uICAgICAgICAgIDAgICAxMSAgIE4gICAgIDAgIDMgNCA1IDYgNyA5 IDEwIDExDQogIEFmdGVyIERpc2FibGUgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMyA0IDUgNiA3 IDkgMTAgMTENCnBjaV9saW5rNTogICAgICAgIEluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzDQog IEluaXRpYWwgUHJvYmUgICAgICAgMCAgIDExICAgTiAgICAgMCAgMyA0IDUgNiA3IDkgMTAgMTEN CiAgVmFsaWRhdGlvbiAgICAgICAgICAwICAgMTEgICBOICAgICAwICAzIDQgNSA2IDcgOSAxMCAx MQ0KICBBZnRlciBEaXNhYmxlICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDMgNCA1IDYgNyA5IDEw IDExDQpwY2lfbGluazY6ICAgICAgICBJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcw0KICBJbml0 aWFsIFByb2JlICAgICAgIDAgICAxMSAgIE4gICAgIDAgIDMgNCA1IDYgNyA5IDEwIDExDQogIFZh bGlkYXRpb24gICAgICAgICAgMCAgIDExICAgTiAgICAgMCAgMyA0IDUgNiA3IDkgMTAgMTENCiAg QWZ0ZXIgRGlzYWJsZSAgICAgICAwICAyNTUgICBOICAgICAwICAzIDQgNSA2IDcgOSAxMCAxMQ0K cGNpX2xpbms3OiAgICAgICAgSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMNCiAgSW5pdGlhbCBQ cm9iZSAgICAgICAwICAgMTEgICBOICAgICAwICAzIDQgNSA2IDcgOSAxMCAxMQ0KICBWYWxpZGF0 aW9uICAgICAgICAgIDAgICAxMSAgIE4gICAgIDAgIDMgNCA1IDYgNyA5IDEwIDExDQogIEFmdGVy IERpc2FibGUgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMyA0IDUgNiA3IDkgMTAgMTENCmNwdTA6 IDxBQ1BJIENQVT4gb24gYWNwaTANCkFDUEk6IFNTRFQgQCAweDB4N2ZlZjFkMzYvMHgwMjgyICh2 ICAxICBQbVJlZiAgQ3B1MElzdCAweDAwMDAwMTAwIElOVEwgMHgyMDA1MDUxMykNCkFDUEk6IFNT RFQgQCAweDB4N2ZlZjIwM2QvMHgwNjVBICh2ICAxICBQbVJlZiAgQ3B1MENzdCAweDAwMDAwMTAw IElOVEwgMHgyMDA1MDUxMykNCmVzdDA6IDxFbmhhbmNlZCBTcGVlZFN0ZXAgRnJlcXVlbmN5IENv bnRyb2w+IG9uIGNwdTANCnA0dGNjMDogPENQVSBGcmVxdWVuY3kgVGhlcm1hbCBDb250cm9sPiBv biBjcHUwDQpjcHUxOiA8QUNQSSBDUFU+IG9uIGFjcGkwDQpBQ1BJOiBTU0RUIEAgMHgweDdmZWYx YzZlLzB4MDBDOCAodiAgMSAgUG1SZWYgIENwdTFJc3QgMHgwMDAwMDEwMCBJTlRMIDB4MjAwNTA1 MTMpDQpBQ1BJOiBTU0RUIEAgMHgweDdmZWYxZmI4LzB4MDA4NSAodiAgMSAgUG1SZWYgIENwdTFD c3QgMHgwMDAwMDEwMCBJTlRMIDB4MjAwNTA1MTMpDQplc3QxOiA8RW5oYW5jZWQgU3BlZWRTdGVw IEZyZXF1ZW5jeSBDb250cm9sPiBvbiBjcHUxDQpwNHRjYzE6IDxDUFUgRnJlcXVlbmN5IFRoZXJt YWwgQ29udHJvbD4gb24gY3B1MQ0KYWNwaV9saWQwOiA8Q29udHJvbCBNZXRob2QgTGlkIFN3aXRj aD4gb24gYWNwaTANCmFjcGlfYnV0dG9uMDogPFNsZWVwIEJ1dHRvbj4gb24gYWNwaTANCnBjaWIw OiA8QUNQSSBIb3N0LVBDSSBicmlkZ2U+IHBvcnQgMHhjZjgtMHhjZmYgb24gYWNwaTANCnBjaTA6 IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIwDQpwY2kwOiBwaHlzaWNhbCBidXM9MA0KZm91bmQtPgl2 ZW5kb3I9MHg4MDg2LCBkZXY9MHgyN2EwLCByZXZpZD0weDAzDQoJYnVzPTAsIHNsb3Q9MCwgZnVu Yz0wDQoJY2xhc3M9MDYtMDAtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MA0KCWNtZHJlZz0weDAx MDYsIHN0YXRyZWc9MHgyMDkwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQ0KCWxhdHRpbWVyPTB4MDAg KDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgwIG5zKQ0KZm91bmQtPgl2 ZW5kb3I9MHg4MDg2LCBkZXY9MHgyN2ExLCByZXZpZD0weDAzDQoJYnVzPTAsIHNsb3Q9MSwgZnVu Yz0wDQoJY2xhc3M9MDYtMDQtMDAsIGhkcnR5cGU9MHgwMSwgbWZkZXY9MA0KCWNtZHJlZz0weDAx MDcsIHN0YXRyZWc9MHgwMDEwLCBjYWNoZWxuc3o9MTYgKGR3b3JkcykNCglsYXR0aW1lcj0weDAw ICgwIG5zKSwgbWluZ250PTB4MWMgKDcwMDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykNCglpbnRw aW49YSwgaXJxPTExDQoJcG93ZXJzcGVjIDIgIHN1cHBvcnRzIEQwIEQzICBjdXJyZW50IEQwDQoJ TVNJIHN1cHBvcnRzIDEgbWVzc2FnZQ0KcGNpYjA6IG1hdGNoZWQgZW50cnkgZm9yIDAuMS5JTlRB DQpwY2liMDogc2xvdCAxIElOVEEgaGFyZHdpcmVkIHRvIElSUSAxNg0KZm91bmQtPgl2ZW5kb3I9 MHg4MDg2LCBkZXY9MHgyN2Q4LCByZXZpZD0weDAyDQoJYnVzPTAsIHNsb3Q9MjcsIGZ1bmM9MA0K CWNsYXNzPTA0LTAzLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTANCgljbWRyZWc9MHgwMTA2LCBz dGF0cmVnPTB4MDAxMCwgY2FjaGVsbnN6PTE2IChkd29yZHMpDQoJbGF0dGltZXI9MHgwMCAoMCBu cyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpDQoJaW50cGluPWIsIGly cT0xMQ0KCXBvd2Vyc3BlYyAyICBzdXBwb3J0cyBEMCBEMyAgY3VycmVudCBEMA0KCU1TSSBzdXBw b3J0cyAxIG1lc3NhZ2UsIDY0IGJpdA0KCW1hcFsxMF06IHR5cGUgTWVtb3J5LCByYW5nZSA2NCwg YmFzZSAweGVlNDAwMDAwLCBzaXplIDE0LCBlbmFibGVkDQpwY2liMDogbWF0Y2hlZCBlbnRyeSBm b3IgMC4yNy5JTlRCDQpwY2liMDogc2xvdCAyNyBJTlRCIGhhcmR3aXJlZCB0byBJUlEgMTcNCmZv dW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4MjdkMCwgcmV2aWQ9MHgwMg0KCWJ1cz0wLCBzbG90 PTI4LCBmdW5jPTANCgljbGFzcz0wNi0wNC0wMCwgaGRydHlwZT0weDAxLCBtZmRldj0xDQoJY21k cmVnPTB4MDEwNywgc3RhdHJlZz0weDAwMTAsIGNhY2hlbG5zej0xNiAoZHdvcmRzKQ0KCWxhdHRp bWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwNCAoMTAwMCBucyksIG1heGxhdD0weDAwICgwIG5z KQ0KCWludHBpbj1hLCBpcnE9MTENCglwb3dlcnNwZWMgMiAgc3VwcG9ydHMgRDAgRDMgIGN1cnJl bnQgRDANCglNU0kgc3VwcG9ydHMgMSBtZXNzYWdlDQpwY2liMDogbWF0Y2hlZCBlbnRyeSBmb3Ig MC4yOC5JTlRBDQpwY2liMDogc2xvdCAyOCBJTlRBIGhhcmR3aXJlZCB0byBJUlEgMjANCmZvdW5k LT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4MjdkMiwgcmV2aWQ9MHgwMg0KCWJ1cz0wLCBzbG90PTI4 LCBmdW5jPTENCgljbGFzcz0wNi0wNC0wMCwgaGRydHlwZT0weDAxLCBtZmRldj0xDQoJY21kcmVn PTB4MDEwNywgc3RhdHJlZz0weDAwMTAsIGNhY2hlbG5zej0xNiAoZHdvcmRzKQ0KCWxhdHRpbWVy PTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwNCAoMTAwMCBucyksIG1heGxhdD0weDAwICgwIG5zKQ0K CWludHBpbj1iLCBpcnE9MTENCglwb3dlcnNwZWMgMiAgc3VwcG9ydHMgRDAgRDMgIGN1cnJlbnQg RDANCglNU0kgc3VwcG9ydHMgMSBtZXNzYWdlDQpwY2liMDogbWF0Y2hlZCBlbnRyeSBmb3IgMC4y OC5JTlRCDQpwY2liMDogc2xvdCAyOCBJTlRCIGhhcmR3aXJlZCB0byBJUlEgMjENCmZvdW5kLT4J dmVuZG9yPTB4ODA4NiwgZGV2PTB4MjdkNCwgcmV2aWQ9MHgwMg0KCWJ1cz0wLCBzbG90PTI4LCBm dW5jPTINCgljbGFzcz0wNi0wNC0wMCwgaGRydHlwZT0weDAxLCBtZmRldj0xDQoJY21kcmVnPTB4 MDEwNywgc3RhdHJlZz0weDAwMTAsIGNhY2hlbG5zej0xNiAoZHdvcmRzKQ0KCWxhdHRpbWVyPTB4 MDAgKDAgbnMpLCBtaW5nbnQ9MHgwNCAoMTAwMCBucyksIG1heGxhdD0weDAwICgwIG5zKQ0KCWlu dHBpbj1jLCBpcnE9MTENCglwb3dlcnNwZWMgMiAgc3VwcG9ydHMgRDAgRDMgIGN1cnJlbnQgRDAN CglNU0kgc3VwcG9ydHMgMSBtZXNzYWdlDQpwY2liMDogbWF0Y2hlZCBlbnRyeSBmb3IgMC4yOC5J TlRDDQpwY2liMDogc2xvdCAyOCBJTlRDIGhhcmR3aXJlZCB0byBJUlEgMjINCmZvdW5kLT4JdmVu ZG9yPTB4ODA4NiwgZGV2PTB4MjdkNiwgcmV2aWQ9MHgwMg0KCWJ1cz0wLCBzbG90PTI4LCBmdW5j PTMNCgljbGFzcz0wNi0wNC0wMCwgaGRydHlwZT0weDAxLCBtZmRldj0xDQoJY21kcmVnPTB4MDEw Nywgc3RhdHJlZz0weDAwMTAsIGNhY2hlbG5zej0xNiAoZHdvcmRzKQ0KCWxhdHRpbWVyPTB4MDAg KDAgbnMpLCBtaW5nbnQ9MHgwNCAoMTAwMCBucyksIG1heGxhdD0weDAwICgwIG5zKQ0KCWludHBp bj1kLCBpcnE9MTENCglwb3dlcnNwZWMgMiAgc3VwcG9ydHMgRDAgRDMgIGN1cnJlbnQgRDANCglN U0kgc3VwcG9ydHMgMSBtZXNzYWdlDQpwY2liMDogbWF0Y2hlZCBlbnRyeSBmb3IgMC4yOC5JTlRE DQpwY2liMDogc2xvdCAyOCBJTlREIGhhcmR3aXJlZCB0byBJUlEgMjMNCmZvdW5kLT4JdmVuZG9y PTB4ODA4NiwgZGV2PTB4MjdjOCwgcmV2aWQ9MHgwMg0KCWJ1cz0wLCBzbG90PTI5LCBmdW5jPTAN CgljbGFzcz0wYy0wMy0wMCwgaGRydHlwZT0weDAwLCBtZmRldj0xDQoJY21kcmVnPTB4MDAwNSwg c3RhdHJlZz0weDAyODAsIGNhY2hlbG5zej0wIChkd29yZHMpDQoJbGF0dGltZXI9MHgwMCAoMCBu cyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpDQoJaW50cGluPWEsIGly cT0xMQ0KCW1hcFsyMF06IHR5cGUgSS9PIFBvcnQsIHJhbmdlIDMyLCBiYXNlIDB4MTgwMCwgc2l6 ZSAgNSwgZW5hYmxlZA0KcGNpYjA6IG1hdGNoZWQgZW50cnkgZm9yIDAuMjkuSU5UQQ0KcGNpYjA6 IHNsb3QgMjkgSU5UQSBoYXJkd2lyZWQgdG8gSVJRIDE2DQpmb3VuZC0+CXZlbmRvcj0weDgwODYs IGRldj0weDI3YzksIHJldmlkPTB4MDINCglidXM9MCwgc2xvdD0yOSwgZnVuYz0xDQoJY2xhc3M9 MGMtMDMtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MA0KCWNtZHJlZz0weDAwMDUsIHN0YXRyZWc9 MHgwMjgwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQ0KCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5n bnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgwIG5zKQ0KCWludHBpbj1iLCBpcnE9MTENCglt YXBbMjBdOiB0eXBlIEkvTyBQb3J0LCByYW5nZSAzMiwgYmFzZSAweDE4MjAsIHNpemUgIDUsIGVu YWJsZWQNCnBjaWIwOiBtYXRjaGVkIGVudHJ5IGZvciAwLjI5LklOVEINCnBjaWIwOiBzbG90IDI5 IElOVEIgaGFyZHdpcmVkIHRvIElSUSAxNw0KZm91bmQtPgl2ZW5kb3I9MHg4MDg2LCBkZXY9MHgy N2NhLCByZXZpZD0weDAyDQoJYnVzPTAsIHNsb3Q9MjksIGZ1bmM9Mg0KCWNsYXNzPTBjLTAzLTAw LCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTANCgljbWRyZWc9MHgwMDA1LCBzdGF0cmVnPTB4MDI4MCwg Y2FjaGVsbnN6PTAgKGR3b3JkcykNCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAg KDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykNCglpbnRwaW49YywgaXJxPTExDQoJbWFwWzIwXTog dHlwZSBJL08gUG9ydCwgcmFuZ2UgMzIsIGJhc2UgMHgxODQwLCBzaXplICA1LCBlbmFibGVkDQpw Y2liMDogbWF0Y2hlZCBlbnRyeSBmb3IgMC4yOS5JTlRDDQpwY2liMDogc2xvdCAyOSBJTlRDIGhh cmR3aXJlZCB0byBJUlEgMTgNCmZvdW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4MjdjYiwgcmV2 aWQ9MHgwMg0KCWJ1cz0wLCBzbG90PTI5LCBmdW5jPTMNCgljbGFzcz0wYy0wMy0wMCwgaGRydHlw ZT0weDAwLCBtZmRldj0wDQoJY21kcmVnPTB4MDAwNSwgc3RhdHJlZz0weDAyODAsIGNhY2hlbG5z ej0wIChkd29yZHMpDQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgwIG5zKSwg bWF4bGF0PTB4MDAgKDAgbnMpDQoJaW50cGluPWQsIGlycT0xMQ0KCW1hcFsyMF06IHR5cGUgSS9P IFBvcnQsIHJhbmdlIDMyLCBiYXNlIDB4MTg2MCwgc2l6ZSAgNSwgZW5hYmxlZA0KcGNpYjA6IG1h dGNoZWQgZW50cnkgZm9yIDAuMjkuSU5URA0KcGNpYjA6IHNsb3QgMjkgSU5URCBoYXJkd2lyZWQg dG8gSVJRIDE5DQpmb3VuZC0+CXZlbmRvcj0weDgwODYsIGRldj0weDI3Y2MsIHJldmlkPTB4MDIN CglidXM9MCwgc2xvdD0yOSwgZnVuYz03DQoJY2xhc3M9MGMtMDMtMjAsIGhkcnR5cGU9MHgwMCwg bWZkZXY9MA0KCWNtZHJlZz0weDAxMDYsIHN0YXRyZWc9MHgwMjkwLCBjYWNoZWxuc3o9MCAoZHdv cmRzKQ0KCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0w eDAwICgwIG5zKQ0KCWludHBpbj1kLCBpcnE9MTENCglwb3dlcnNwZWMgMiAgc3VwcG9ydHMgRDAg RDMgIGN1cnJlbnQgRDANCgltYXBbMTBdOiB0eXBlIE1lbW9yeSwgcmFuZ2UgMzIsIGJhc2UgMHhl ZTQwNDAwMCwgc2l6ZSAxMCwgZW5hYmxlZA0KcGNpYjA6IG1hdGNoZWQgZW50cnkgZm9yIDAuMjku SU5URA0KcGNpYjA6IHNsb3QgMjkgSU5URCBoYXJkd2lyZWQgdG8gSVJRIDE5DQpmb3VuZC0+CXZl bmRvcj0weDgwODYsIGRldj0weDI0NDgsIHJldmlkPTB4ZTINCglidXM9MCwgc2xvdD0zMCwgZnVu Yz0wDQoJY2xhc3M9MDYtMDQtMDEsIGhkcnR5cGU9MHgwMSwgbWZkZXY9MA0KCWNtZHJlZz0weDAw MDUsIHN0YXRyZWc9MHgwMDEwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQ0KCWxhdHRpbWVyPTB4MDAg KDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgwIG5zKQ0KZm91bmQtPgl2 ZW5kb3I9MHg4MDg2LCBkZXY9MHgyN2I5LCByZXZpZD0weDAyDQoJYnVzPTAsIHNsb3Q9MzEsIGZ1 bmM9MA0KCWNsYXNzPTA2LTAxLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTENCgljbWRyZWc9MHgw MDA3LCBzdGF0cmVnPTB4MDIxMCwgY2FjaGVsbnN6PTAgKGR3b3JkcykNCglsYXR0aW1lcj0weDAw ICgwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykNCmZvdW5kLT4J dmVuZG9yPTB4ODA4NiwgZGV2PTB4MjdkZiwgcmV2aWQ9MHgwMg0KCWJ1cz0wLCBzbG90PTMxLCBm dW5jPTENCgljbGFzcz0wMS0wMS04YSwgaGRydHlwZT0weDAwLCBtZmRldj0wDQoJY21kcmVnPTB4 MDAwNSwgc3RhdHJlZz0weDAyODAsIGNhY2hlbG5zej0wIChkd29yZHMpDQoJbGF0dGltZXI9MHgw MCAoMCBucyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpDQoJaW50cGlu PWMsIGlycT0yNTUNCgltYXBbMjBdOiB0eXBlIEkvTyBQb3J0LCByYW5nZSAzMiwgYmFzZSAweDE4 ODAsIHNpemUgIDQsIGVuYWJsZWQNCmZvdW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4MjdjNSwg cmV2aWQ9MHgwMg0KCWJ1cz0wLCBzbG90PTMxLCBmdW5jPTINCgljbGFzcz0wMS0wNi0wMSwgaGRy dHlwZT0weDAwLCBtZmRldj0wDQoJY21kcmVnPTB4MDAwNywgc3RhdHJlZz0weDAyYjAsIGNhY2hl bG5zej0wIChkd29yZHMpDQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgwIG5z KSwgbWF4bGF0PTB4MDAgKDAgbnMpDQoJaW50cGluPWIsIGlycT0xMQ0KCXBvd2Vyc3BlYyAyICBz dXBwb3J0cyBEMCBEMyAgY3VycmVudCBEMA0KCU1TSSBzdXBwb3J0cyAxIG1lc3NhZ2UNCgltYXBb MTBdOiB0eXBlIEkvTyBQb3J0LCByYW5nZSAzMiwgYmFzZSAweDE4YzgsIHNpemUgIDMsIGVuYWJs ZWQNCgltYXBbMTRdOiB0eXBlIEkvTyBQb3J0LCByYW5nZSAzMiwgYmFzZSAweDE4YWMsIHNpemUg IDIsIGVuYWJsZWQNCgltYXBbMThdOiB0eXBlIEkvTyBQb3J0LCByYW5nZSAzMiwgYmFzZSAweDE4 YzAsIHNpemUgIDMsIGVuYWJsZWQNCgltYXBbMWNdOiB0eXBlIEkvTyBQb3J0LCByYW5nZSAzMiwg YmFzZSAweDE4YTgsIHNpemUgIDIsIGVuYWJsZWQNCgltYXBbMjBdOiB0eXBlIEkvTyBQb3J0LCBy YW5nZSAzMiwgYmFzZSAweDE4YjAsIHNpemUgIDQsIGVuYWJsZWQNCgltYXBbMjRdOiB0eXBlIE1l bW9yeSwgcmFuZ2UgMzIsIGJhc2UgMHhlZTQwNDQwMCwgc2l6ZSAxMCwgZW5hYmxlZA0KcGNpYjA6 IG1hdGNoZWQgZW50cnkgZm9yIDAuMzEuSU5UQg0KcGNpYjA6IHNsb3QgMzEgSU5UQiBoYXJkd2ly ZWQgdG8gSVJRIDE2DQpmb3VuZC0+CXZlbmRvcj0weDgwODYsIGRldj0weDI3ZGEsIHJldmlkPTB4 MDINCglidXM9MCwgc2xvdD0zMSwgZnVuYz0zDQoJY2xhc3M9MGMtMDUtMDAsIGhkcnR5cGU9MHgw MCwgbWZkZXY9MA0KCWNtZHJlZz0weDAxMDEsIHN0YXRyZWc9MHgwMjgwLCBjYWNoZWxuc3o9MCAo ZHdvcmRzKQ0KCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxh dD0weDAwICgwIG5zKQ0KCWludHBpbj1hLCBpcnE9MTENCgltYXBbMjBdOiB0eXBlIEkvTyBQb3J0 LCByYW5nZSAzMiwgYmFzZSAweDE4ZTAsIHNpemUgIDUsIGVuYWJsZWQNCnBjaWIwOiBtYXRjaGVk IGVudHJ5IGZvciAwLjMxLklOVEENCnBjaWIwOiBzbG90IDMxIElOVEEgaGFyZHdpcmVkIHRvIElS USAyMw0KcGNpYjE6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBpcnEgMTYgYXQgZGV2aWNlIDEuMCBv biBwY2kwDQpwY2liMTogICBzZWNvbmRhcnkgYnVzICAgICAxDQpwY2liMTogICBzdWJvcmRpbmF0 ZSBidXMgICAxDQpwY2liMTogICBJL08gZGVjb2RlICAgICAgICAweDIwMDAtMHgyZmZmDQpwY2li MTogICBtZW1vcnkgZGVjb2RlICAgICAweGVlMTAwMDAwLTB4ZWUxZmZmZmYNCnBjaWIxOiAgIHBy ZWZldGNoZWQgZGVjb2RlIDB4ZDgwMDAwMDAtMHhkZmZmZmZmZg0KcGNpMTogPEFDUEkgUENJIGJ1 cz4gb24gcGNpYjENCnBjaTE6IHBoeXNpY2FsIGJ1cz0xDQpmb3VuZC0+CXZlbmRvcj0weDEwMDIs IGRldj0weDcxNDUsIHJldmlkPTB4MDANCglidXM9MSwgc2xvdD0wLCBmdW5jPTANCgljbGFzcz0w My0wMC0wMCwgaGRydHlwZT0weDAwLCBtZmRldj0wDQoJY21kcmVnPTB4MDEwMywgc3RhdHJlZz0w eDAwMTAsIGNhY2hlbG5zej0xNiAoZHdvcmRzKQ0KCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5n bnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgwIG5zKQ0KCWludHBpbj1hLCBpcnE9MTENCglw b3dlcnNwZWMgMiAgc3VwcG9ydHMgRDAgRDEgRDIgRDMgIGN1cnJlbnQgRDANCglNU0kgc3VwcG9y dHMgMSBtZXNzYWdlLCA2NCBiaXQNCgltYXBbMTBdOiB0eXBlIFByZWZldGNoYWJsZSBNZW1vcnks IHJhbmdlIDMyLCBiYXNlIDB4ZDgwMDAwMDAsIHNpemUgMjcsIGVuYWJsZWQNCnBjaWIxOiByZXF1 ZXN0ZWQgbWVtb3J5IHJhbmdlIDB4ZDgwMDAwMDAtMHhkZmZmZmZmZjogZ29vZA0KCW1hcFsxNF06 IHR5cGUgSS9PIFBvcnQsIHJhbmdlIDMyLCBiYXNlIDB4MjAwMCwgc2l6ZSAgOCwgZW5hYmxlZA0K cGNpYjE6IHJlcXVlc3RlZCBJL08gcmFuZ2UgMHgyMDAwLTB4MjBmZjogaW4gcmFuZ2UNCgltYXBb MThdOiB0eXBlIE1lbW9yeSwgcmFuZ2UgMzIsIGJhc2UgMHhlZTEwMDAwMCwgc2l6ZSAxNiwgZW5h YmxlZA0KcGNpYjE6IHJlcXVlc3RlZCBtZW1vcnkgcmFuZ2UgMHhlZTEwMDAwMC0weGVlMTBmZmZm OiBnb29kDQpwY2liMTogbWF0Y2hlZCBlbnRyeSBmb3IgMS4wLklOVEENCnBjaWIxOiBzbG90IDAg SU5UQSBoYXJkd2lyZWQgdG8gSVJRIDE2DQp2Z2FwY2kwOiA8VkdBLWNvbXBhdGlibGUgZGlzcGxh eT4gcG9ydCAweDIwMDAtMHgyMGZmIG1lbSAweGQ4MDAwMDAwLTB4ZGZmZmZmZmYsMHhlZTEwMDAw MC0weGVlMTBmZmZmIGlycSAxNiBhdCBkZXZpY2UgMC4wIG9uIHBjaTENCmFjcGlfdmlkZW8wOiA8 QUNQSSB2aWRlbyBleHRlbnNpb24+IG9uIHZnYXBjaTANCmZvdW5kIEludGVybmFsL0ludGVncmF0 ZWQgRGlnaXRhbCBGbGF0IFBhbmVsKDExMCksIGlkeCMwLCBwb3J0IzEsIGhlYWQgIzANCmZvdW5k IFZHQSBDUlQgb3IgVkVTQSBDb21wYXRpYmxlIEFuYWxvZyBNb25pdG9yKDEwMCksIGlkeCMwLCBw b3J0IzAsIGhlYWQgIzANCmZvdW5kIFRWL0hEVFYgb3IgQW5hbG9nLVZpZGVvIE1vbml0b3IoMjEw KSwgaWR4IzAsIHBvcnQjMSwgaGVhZCAjMA0KcGNtMDogPEludGVsIDgyODAxRyBIaWdoIERlZmlu aXRpb24gQXVkaW8gQ29udHJvbGxlcj4gbWVtIDB4ZWU0MDAwMDAtMHhlZTQwM2ZmZiBpcnEgMTcg YXQgZGV2aWNlIDI3LjAgb24gcGNpMA0KcGNtMDogVENTRUw6IDB4MDcgLT4gMHgwMA0KcGNtMDog RE1BIENvaGVyZW5jeTogVW5jYWNoZWFibGUgLyB2ZW5kb3I9MHg4MDg2DQpwY20wOiBSZXNlcnZl ZCAweDQwMDAgYnl0ZXMgZm9yIHJpZCAweDEwIHR5cGUgMyBhdCAweGVlNDAwMDAwDQppb2FwaWMw OiByb3V0aW5nIGludHBpbiAxNyAoUENJIElSUSAxNykgdG8gdmVjdG9yIDQ5DQpwY20wOiBbTVBT QUZFXQ0KcGNtMDogW0lUSFJFQURdDQpwY20wOiBoZGFjX2RtYV9hbGxvYzogc2l6ZT0xMDI0IC0+ IHJvdW5kc3o9MTAyNA0KcGNtMDogaGRhY19kbWFfYWxsb2M6IHNpemU9MjA0OCAtPiByb3VuZHN6 PTIwNDgNCnBjaWIyOiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gaXJxIDIwIGF0IGRldmljZSAyOC4w IG9uIHBjaTANCnBjaWIyOiAgIHNlY29uZGFyeSBidXMgICAgIDINCnBjaWIyOiAgIHN1Ym9yZGlu YXRlIGJ1cyAgIDINCnBjaWIyOiAgIEkvTyBkZWNvZGUgICAgICAgIDB4MzAwMC0weDNmZmYNCnBj aWIyOiAgIG1lbW9yeSBkZWNvZGUgICAgIDB4ZWUwMDAwMDAtMHhlZTBmZmZmZg0KcGNpYjI6ICAg bm8gcHJlZmV0Y2hlZCBkZWNvZGUNCnBjaTI6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIyDQpwY2ky OiBwaHlzaWNhbCBidXM9Mg0KZm91bmQtPgl2ZW5kb3I9MHg4MDg2LCBkZXY9MHgxMDlhLCByZXZp ZD0weDAwDQoJYnVzPTIsIHNsb3Q9MCwgZnVuYz0wDQoJY2xhc3M9MDItMDAtMDAsIGhkcnR5cGU9 MHgwMCwgbWZkZXY9MA0KCWNtZHJlZz0weDAxMDcsIHN0YXRyZWc9MHgwMDEwLCBjYWNoZWxuc3o9 MTYgKGR3b3JkcykNCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBt YXhsYXQ9MHgwMCAoMCBucykNCglpbnRwaW49YSwgaXJxPTExDQoJcG93ZXJzcGVjIDIgIHN1cHBv cnRzIEQwIEQzICBjdXJyZW50IEQwDQoJTVNJIHN1cHBvcnRzIDEgbWVzc2FnZSwgNjQgYml0DQoJ bWFwWzEwXTogdHlwZSBNZW1vcnksIHJhbmdlIDMyLCBiYXNlIDB4ZWUwMDAwMDAsIHNpemUgMTcs IGVuYWJsZWQNCnBjaWIyOiByZXF1ZXN0ZWQgbWVtb3J5IHJhbmdlIDB4ZWUwMDAwMDAtMHhlZTAx ZmZmZjogZ29vZA0KCW1hcFsxOF06IHR5cGUgSS9PIFBvcnQsIHJhbmdlIDMyLCBiYXNlIDB4MzAw MCwgc2l6ZSAgNSwgZW5hYmxlZA0KcGNpYjI6IHJlcXVlc3RlZCBJL08gcmFuZ2UgMHgzMDAwLTB4 MzAxZjogaW4gcmFuZ2UNCnBjaWIyOiBtYXRjaGVkIGVudHJ5IGZvciAyLjAuSU5UQQ0KcGNpYjI6 IHNsb3QgMCBJTlRBIGhhcmR3aXJlZCB0byBJUlEgMTYNCmVtMDogPEludGVsKFIpIFBSTy8xMDAw IE5ldHdvcmsgQ29ubmVjdGlvbiBWZXJzaW9uIC0gNi41LjM+IHBvcnQgMHgzMDAwLTB4MzAxZiBt ZW0gMHhlZTAwMDAwMC0weGVlMDFmZmZmIGlycSAxNiBhdCBkZXZpY2UgMC4wIG9uIHBjaTINCmVt MDogUmVzZXJ2ZWQgMHgyMDAwMCBieXRlcyBmb3IgcmlkIDB4MTAgdHlwZSAzIGF0IDB4ZWUwMDAw MDANCmVtMDogYXR0ZW1wdGluZyB0byBhbGxvY2F0ZSAxIE1TSSB2ZWN0b3JzICgxIHN1cHBvcnRl ZCkNCm1zaTogcm91dGluZyBNU0kgSVJRIDI1NiB0byB2ZWN0b3IgNTANCmVtMDogdXNpbmcgSVJR IDI1NiBmb3IgTVNJDQplbTA6IGJwZiBhdHRhY2hlZA0KZW0wOiBFdGhlcm5ldCBhZGRyZXNzOiAw MDoxNTo1ODo4MjozNjoxYQ0KZW0wOiBbRklMVEVSXQ0KcGNpYjM6IDxBQ1BJIFBDSS1QQ0kgYnJp ZGdlPiBpcnEgMjEgYXQgZGV2aWNlIDI4LjEgb24gcGNpMA0KcGNpYjM6ICAgc2Vjb25kYXJ5IGJ1 cyAgICAgMw0KcGNpYjM6ICAgc3Vib3JkaW5hdGUgYnVzICAgMw0KcGNpYjM6ICAgSS9PIGRlY29k ZSAgICAgICAgMHg0MDAwLTB4NWZmZg0KcGNpYjM6ICAgbWVtb3J5IGRlY29kZSAgICAgMHhlYzAw MDAwMC0weGVkZmZmZmZmDQpwY2liMzogICBwcmVmZXRjaGVkIGRlY29kZSAweGU0MDAwMDAwLTB4 ZTQwZmZmZmYNCnBjaTM6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIzDQpwY2kzOiBwaHlzaWNhbCBi dXM9Mw0KZm91bmQtPgl2ZW5kb3I9MHgxNjhjLCBkZXY9MHgxMDE0LCByZXZpZD0weDAxDQoJYnVz PTMsIHNsb3Q9MCwgZnVuYz0wDQoJY2xhc3M9MDItMDAtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9 MA0KCWNtZHJlZz0weDAxMDcsIHN0YXRyZWc9MHgwMDEwLCBjYWNoZWxuc3o9MTYgKGR3b3JkcykN CglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAo MCBucykNCglpbnRwaW49YSwgaXJxPTExDQoJcG93ZXJzcGVjIDIgIHN1cHBvcnRzIEQwIEQzICBj dXJyZW50IEQwDQoJTVNJIHN1cHBvcnRzIDEgbWVzc2FnZQ0KCU1TSS1YIHN1cHBvcnRzIDEgbWVz c2FnZSBpbiBtYXAgMHgxMA0KCW1hcFsxMF06IHR5cGUgTWVtb3J5LCByYW5nZSA2NCwgYmFzZSAw eGVkZjAwMDAwLCBzaXplIDE2LCBlbmFibGVkDQpwY2liMzogcmVxdWVzdGVkIG1lbW9yeSByYW5n ZSAweGVkZjAwMDAwLTB4ZWRmMGZmZmY6IGdvb2QNCnBjaWIzOiBtYXRjaGVkIGVudHJ5IGZvciAz LjAuSU5UQQ0KcGNpYjM6IHNsb3QgMCBJTlRBIGhhcmR3aXJlZCB0byBJUlEgMTcNCnBjaTM6IDxu ZXR3b3JrLCBldGhlcm5ldD4gYXQgZGV2aWNlIDAuMCAobm8gZHJpdmVyIGF0dGFjaGVkKQ0KcGNp YjQ6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBpcnEgMjIgYXQgZGV2aWNlIDI4LjIgb24gcGNpMA0K cGNpYjQ6ICAgc2Vjb25kYXJ5IGJ1cyAgICAgNA0KcGNpYjQ6ICAgc3Vib3JkaW5hdGUgYnVzICAg MTENCnBjaWI0OiAgIEkvTyBkZWNvZGUgICAgICAgIDB4NjAwMC0weDdmZmYNCnBjaWI0OiAgIG1l bW9yeSBkZWNvZGUgICAgIDB4ZTgwMDAwMDAtMHhlOWZmZmZmZg0KcGNpYjQ6ICAgcHJlZmV0Y2hl ZCBkZWNvZGUgMHhlNDEwMDAwMC0weGU0MWZmZmZmDQpwY2k0OiA8QUNQSSBQQ0kgYnVzPiBvbiBw Y2liNA0KcGNpNDogcGh5c2ljYWwgYnVzPTQNCnBjaWI1OiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4g aXJxIDIzIGF0IGRldmljZSAyOC4zIG9uIHBjaTANCnBjaWI1OiAgIHNlY29uZGFyeSBidXMgICAg IDEyDQpwY2liNTogICBzdWJvcmRpbmF0ZSBidXMgICAxOQ0KcGNpYjU6ICAgSS9PIGRlY29kZSAg ICAgICAgMHg4MDAwLTB4OWZmZg0KcGNpYjU6ICAgbWVtb3J5IGRlY29kZSAgICAgMHhlYTAwMDAw MC0weGViZmZmZmZmDQpwY2liNTogICBwcmVmZXRjaGVkIGRlY29kZSAweGU0MjAwMDAwLTB4ZTQy ZmZmZmYNCnBjaTEyOiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liNQ0KcGNpMTI6IHBoeXNpY2FsIGJ1 cz0xMg0KdWhjaTA6IDxVSENJIChnZW5lcmljKSBVU0IgY29udHJvbGxlcj4gcG9ydCAweDE4MDAt MHgxODFmIGlycSAxNiBhdCBkZXZpY2UgMjkuMCBvbiBwY2kwDQp1aGNpMDogUmVzZXJ2ZWQgMHgy MCBieXRlcyBmb3IgcmlkIDB4MjAgdHlwZSA0IGF0IDB4MTgwMA0KaW9hcGljMDogcm91dGluZyBp bnRwaW4gMTYgKFBDSSBJUlEgMTYpIHRvIHZlY3RvciA1MQ0KdWhjaTA6IFtHSUFOVC1MT0NLRURd DQp1aGNpMDogW0lUSFJFQURdDQp1c2IwOiA8VUhDSSAoZ2VuZXJpYykgVVNCIGNvbnRyb2xsZXI+ IG9uIHVoY2kwDQp1c2IwOiBVU0IgcmV2aXNpb24gMS4wDQp1aHViMDogPEludGVsIFVIQ0kgcm9v dCBodWIsIGNsYXNzIDkvMCwgcmV2IDEuMDAvMS4wMCwgYWRkciAxPiBvbiB1c2IwDQp1aHViMDog MiBwb3J0cyB3aXRoIDIgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQNCnVoY2kxOiA8VUhDSSAoZ2Vu ZXJpYykgVVNCIGNvbnRyb2xsZXI+IHBvcnQgMHgxODIwLTB4MTgzZiBpcnEgMTcgYXQgZGV2aWNl IDI5LjEgb24gcGNpMA0KdWhjaTE6IFJlc2VydmVkIDB4MjAgYnl0ZXMgZm9yIHJpZCAweDIwIHR5 cGUgNCBhdCAweDE4MjANCnVoY2kxOiBbR0lBTlQtTE9DS0VEXQ0KdWhjaTE6IFtJVEhSRUFEXQ0K dXNiMTogPFVIQ0kgKGdlbmVyaWMpIFVTQiBjb250cm9sbGVyPiBvbiB1aGNpMQ0KdXNiMTogVVNC IHJldmlzaW9uIDEuMA0KdWh1YjE6IDxJbnRlbCBVSENJIHJvb3QgaHViLCBjbGFzcyA5LzAsIHJl diAxLjAwLzEuMDAsIGFkZHIgMT4gb24gdXNiMQ0KdWh1YjE6IDIgcG9ydHMgd2l0aCAyIHJlbW92 YWJsZSwgc2VsZiBwb3dlcmVkDQp1aGNpMjogPFVIQ0kgKGdlbmVyaWMpIFVTQiBjb250cm9sbGVy PiBwb3J0IDB4MTg0MC0weDE4NWYgaXJxIDE4IGF0IGRldmljZSAyOS4yIG9uIHBjaTANCnVoY2ky OiBSZXNlcnZlZCAweDIwIGJ5dGVzIGZvciByaWQgMHgyMCB0eXBlIDQgYXQgMHgxODQwDQppb2Fw aWMwOiByb3V0aW5nIGludHBpbiAxOCAoUENJIElSUSAxOCkgdG8gdmVjdG9yIDUyDQp1aGNpMjog W0dJQU5ULUxPQ0tFRF0NCnVoY2kyOiBbSVRIUkVBRF0NCnVzYjI6IDxVSENJIChnZW5lcmljKSBV U0IgY29udHJvbGxlcj4gb24gdWhjaTINCnVzYjI6IFVTQiByZXZpc2lvbiAxLjANCnVodWIyOiA8 SW50ZWwgVUhDSSByb290IGh1YiwgY2xhc3MgOS8wLCByZXYgMS4wMC8xLjAwLCBhZGRyIDE+IG9u IHVzYjINCnVodWIyOiAyIHBvcnRzIHdpdGggMiByZW1vdmFibGUsIHNlbGYgcG93ZXJlZA0KdWhj aTM6IDxVSENJIChnZW5lcmljKSBVU0IgY29udHJvbGxlcj4gcG9ydCAweDE4NjAtMHgxODdmIGly cSAxOSBhdCBkZXZpY2UgMjkuMyBvbiBwY2kwDQp1aGNpMzogUmVzZXJ2ZWQgMHgyMCBieXRlcyBm b3IgcmlkIDB4MjAgdHlwZSA0IGF0IDB4MTg2MA0KaW9hcGljMDogcm91dGluZyBpbnRwaW4gMTkg KFBDSSBJUlEgMTkpIHRvIHZlY3RvciA1Mw0KdWhjaTM6IFtHSUFOVC1MT0NLRURdDQp1aGNpMzog W0lUSFJFQURdDQp1c2IzOiA8VUhDSSAoZ2VuZXJpYykgVVNCIGNvbnRyb2xsZXI+IG9uIHVoY2kz DQp1c2IzOiBVU0IgcmV2aXNpb24gMS4wDQp1aHViMzogPEludGVsIFVIQ0kgcm9vdCBodWIsIGNs YXNzIDkvMCwgcmV2IDEuMDAvMS4wMCwgYWRkciAxPiBvbiB1c2IzDQp1aHViMzogMiBwb3J0cyB3 aXRoIDIgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQNCmVoY2kwOiA8SW50ZWwgODI4MDFHQi9SIChJ Q0g3KSBVU0IgMi4wIGNvbnRyb2xsZXI+IG1lbSAweGVlNDA0MDAwLTB4ZWU0MDQzZmYgaXJxIDE5 IGF0IGRldmljZSAyOS43IG9uIHBjaTANCmVoY2kwOiBSZXNlcnZlZCAweDQwMCBieXRlcyBmb3Ig cmlkIDB4MTAgdHlwZSAzIGF0IDB4ZWU0MDQwMDANCmVoY2kwOiBbR0lBTlQtTE9DS0VEXQ0KZWhj aTA6IFtJVEhSRUFEXQ0KdXNiNDogRUhDSSB2ZXJzaW9uIDEuMA0KdXNiNDogY29tcGFuaW9uIGNv bnRyb2xsZXJzLCAyIHBvcnRzIGVhY2g6IHVzYjAgdXNiMSB1c2IyIHVzYjMNCnVzYjQ6IDxJbnRl bCA4MjgwMUdCL1IgKElDSDcpIFVTQiAyLjAgY29udHJvbGxlcj4gb24gZWhjaTANCnVzYjQ6IFVT QiByZXZpc2lvbiAyLjANCnVodWI0OiA8SW50ZWwgRUhDSSByb290IGh1YiwgY2xhc3MgOS8wLCBy ZXYgMi4wMC8xLjAwLCBhZGRyIDE+IG9uIHVzYjQNCnVodWI0OiA4IHBvcnRzIHdpdGggOCByZW1v dmFibGUsIHNlbGYgcG93ZXJlZA0KdWh1YjU6IDx2ZW5kb3IgMHgwNGIzIHByb2R1Y3QgMHg0NDg2 LCBjbGFzcyA5LzAsIHJldiAyLjAwLzAuMDEsIGFkZHIgMj4gb24gdWh1YjQNCnVodWI1OiBtdWx0 aXBsZSB0cmFuc2FjdGlvbiB0cmFuc2xhdG9ycw0KdWh1YjU6IDcgcG9ydHMgd2l0aCA3IHJlbW92 YWJsZSwgc2VsZiBwb3dlcmVkDQp1aGlkZXYwOiA8QlRDIFVTQiBLTXAsIGNsYXNzIDAvMCwgcmV2 IDEuMDAvMS4wMCwgYWRkciAzPiBvbiB1aHViNQ0KdWhpZDAgb24gdWhpZGV2MA0KdWhpZDA6IGlu cHV0PTgsIG91dHB1dD0xLCBmZWF0dXJlPTANCnVoaWRldjE6IDxCVEMgVVNCIEtNcCwgY2xhc3Mg MC8wLCByZXYgMS4wMC8xLjAwLCBhZGRyIDM+IG9uIHVodWI1DQp1aGlkMSBvbiB1aGlkZXYxDQp1 aGlkMTogaW5wdXQ9Mywgb3V0cHV0PTAsIGZlYXR1cmU9MA0KdWhpZGV2MjogPE1pY3Jvc29mdCBN aWNyb3NvZnQgNS1CdXR0b24gTW91c2Ugd2l0aCBJbnRlbGxpRXllKFRNKSwgY2xhc3MgMC8wLCBy ZXYgMS4xMC8zLjAwLCBhZGRyIDQ+IG9uIHVodWI1DQp1aGlkMiBvbiB1aGlkZXYyDQp1aGlkMjog aW5wdXQ9NCwgb3V0cHV0PTAsIGZlYXR1cmU9MQ0KcGNpYjY6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdl PiBhdCBkZXZpY2UgMzAuMCBvbiBwY2kwDQpwY2liNjogICBzZWNvbmRhcnkgYnVzICAgICAyMQ0K cGNpYjY6ICAgc3Vib3JkaW5hdGUgYnVzICAgMjQNCnBjaWI2OiAgIEkvTyBkZWNvZGUgICAgICAg IDB4YTAwMC0weGRmZmYNCnBjaWI2OiAgIG5vIHByZWZldGNoZWQgZGVjb2RlDQpwY2liNjogICBT dWJ0cmFjdGl2ZWx5IGRlY29kZWQgYnJpZGdlLg0KcGNpMjE6IDxBQ1BJIFBDSSBidXM+IG9uIHBj aWI2DQpwY2kyMTogcGh5c2ljYWwgYnVzPTIxDQpmb3VuZC0+CXZlbmRvcj0weDEwNGMsIGRldj0w eGFjNTYsIHJldmlkPTB4MDANCglidXM9MjEsIHNsb3Q9MCwgZnVuYz0wDQoJY2xhc3M9MDYtMDct MDAsIGhkcnR5cGU9MHgwMiwgbWZkZXY9MA0KCWNtZHJlZz0weDAwMDcsIHN0YXRyZWc9MHgwMjEw LCBjYWNoZWxuc3o9OCAoZHdvcmRzKQ0KCWxhdHRpbWVyPTB4YTggKDUwNDAgbnMpLCBtaW5nbnQ9 MHhjMCAoNDgwMDAgbnMpLCBtYXhsYXQ9MHgwMyAoNzUwIG5zKQ0KCWludHBpbj1hLCBpcnE9MTEN Cglwb3dlcnNwZWMgMiAgc3VwcG9ydHMgRDAgRDEgRDIgRDMgIGN1cnJlbnQgRDANCgltYXBbMTBd OiB0eXBlIE1lbW9yeSwgcmFuZ2UgMzIsIGJhc2UgMHhlNDMwMDAwMCwgc2l6ZSAxMiwgZW5hYmxl ZA0KcGNpYjY6IHJlcXVlc3RlZCBtZW1vcnkgcmFuZ2UgMHhlNDMwMDAwMC0weGU0MzAwZmZmOiBn b29kDQpwY2liNjogbWF0Y2hlZCBlbnRyeSBmb3IgMjEuMC5JTlRBDQpwY2liNjogc2xvdCAwIElO VEEgaGFyZHdpcmVkIHRvIElSUSAxNg0KY2JiMDogPFRJMTUxMCBQQ0ktQ2FyZEJ1cyBCcmlkZ2U+ IG1lbSAweGU0MzAwMDAwLTB4ZTQzMDBmZmYgaXJxIDE2IGF0IGRldmljZSAwLjAgb24gcGNpMjEN CmNiYjA6IFJlc2VydmVkIDB4MTAwMCBieXRlcyBmb3IgcmlkIDB4MTAgdHlwZSAzIGF0IDB4ZTQz MDAwMDANCnBjY2FyZDA6IDwxNi1iaXQgUENDYXJkIGJ1cz4gb24gY2JiMA0KY2JiMDogW01QU0FG RV0NCmNiYjA6IFtJVEhSRUFEXQ0KY2JiMDogUENJIENvbmZpZ3VyYXRpb24gc3BhY2U6DQogIDB4 MDA6IDB4YWM1NjEwNGMgMHgwMjEwMDAwNyAweDA2MDcwMDAwIDB4MDAwMmE4MDggDQogIDB4MTA6 IDB4ZTQzMDAwMDAgMHgwMjAwMDBhMCAweGIwMTgxNjE1IDB4ZmZmZmYwMDAgDQogIDB4MjA6IDB4 MDAwMDAwMDAgMHhmZmZmZjAwMCAweDAwMDAwMDAwIDB4ZmZmZmZmZmMgDQogIDB4MzA6IDB4MDAw MDAwMDAgMHhmZmZmZmZmYyAweDAwMDAwMDAwIDB4MDc0MDAxMTAgDQogIDB4NDA6IDB4MjAxMjE3 YWEgMHgwMDAwMDAwMSAweDAwMDAwMDAwIDB4MDAwMDAwMDAgDQogIDB4NTA6IDB4MDAwMDAwMDAg MHgwMDAwMDAwMCAweDAwMDAwMDAwIDB4MDAwMDAwMDAgDQogIDB4NjA6IDB4MDAwMDAwMDAgMHgw MDAwMDAwMCAweDAwMDAwMDAwIDB4MDAwMDAwMDAgDQogIDB4NzA6IDB4MDAwMDAwMDAgMHgwMDAw MDAwMCAweDAwMDAwMDAwIDB4MDAwMDAwMDAgDQogIDB4ODA6IDB4MDg0NGQwNzAgMHgwMDAwMDAw MCAweDAwMDAwMDAwIDB4MDFkMDEwMDIgDQogIDB4OTA6IDB4NDA2NDAyYzAgMHgwMDAwMDAwMCAw eDAwMDAwMDAwIDB4MDAwMDAwMDAgDQogIDB4YTA6IDB4ZmUxMjAwMDEgMHgwMGMwMDAwMCAweDAw MDAwMDAxIDB4MDAwMDAwMGYgDQogIDB4YjA6IDB4MDAwMDAwMDAgMHgwMDAwMDAwMCAweDAwMDAw MDAwIDB4MDAwMDAwMDAgDQogIDB4YzA6IDB4MDAwMDAwMDAgMHgwMDAwMDAwMCAweDAwMDAwMDAw IDB4MDAwMDAwMDAgDQogIDB4ZDA6IDB4MDAwMDAwMDAgMHgwMDAwMDAwMCAweDAwMDAwMDAwIDB4 MDAwMDAwMDAgDQogIDB4ZTA6IDB4MDAwMDAwMDAgMHgwMDAwMDAwMCAweDAwMDAwMDAwIDB4MDAw MDAwMDAgDQogIDB4ZjA6IDB4MDAwMDAwMDAgMHgwMDAwMDAwMCAweDAwMDAwMDAwIDB4MDAwMDAw MDAgDQppc2FiMDogPFBDSS1JU0EgYnJpZGdlPiBhdCBkZXZpY2UgMzEuMCBvbiBwY2kwDQppc2Ew OiA8SVNBIGJ1cz4gb24gaXNhYjANCmF0YXBjaTA6IDxJbnRlbCBJQ0g3IFVETUExMDAgY29udHJv bGxlcj4gcG9ydCAweDFmMC0weDFmNywweDNmNiwweDE3MC0weDE3NywweDM3NiwweDE4ODAtMHgx ODhmIGF0IGRldmljZSAzMS4xIG9uIHBjaTANCmF0YXBjaTA6IFJlc2VydmVkIDB4MTAgYnl0ZXMg Zm9yIHJpZCAweDIwIHR5cGUgNCBhdCAweDE4ODANCmF0YTA6IDxBVEEgY2hhbm5lbCAwPiBvbiBh dGFwY2kwDQphdGFwY2kwOiBSZXNlcnZlZCAweDggYnl0ZXMgZm9yIHJpZCAweDEwIHR5cGUgNCBh dCAweDFmMA0KYXRhcGNpMDogUmVzZXJ2ZWQgMHgxIGJ5dGVzIGZvciByaWQgMHgxNCB0eXBlIDQg YXQgMHgzZjYNCmF0YTA6IHJlc2V0IHRwMSBtYXNrPTAzIG9zdGF0MD01MCBvc3RhdDE9MDANCmF0 YTA6IHN0YXQwPTB4MDAgZXJyPTB4MDEgbHNiPTB4MTQgbXNiPTB4ZWINCmF0YTA6IHN0YXQxPTB4 MDAgZXJyPTB4MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTA6IHJlc2V0IHRwMiBzdGF0MD0wMCBz dGF0MT0wMCBkZXZpY2VzPTB4NDxBVEFQSV9NQVNURVI+DQppb2FwaWMwOiByb3V0aW5nIGludHBp biAxNCAoSVNBIElSUSAxNCkgdG8gdmVjdG9yIDU0DQphdGEwOiBbTVBTQUZFXQ0KYXRhMDogW0lU SFJFQURdDQphdGExOiA8QVRBIGNoYW5uZWwgMT4gb24gYXRhcGNpMA0KYXRhcGNpMDogUmVzZXJ2 ZWQgMHg4IGJ5dGVzIGZvciByaWQgMHgxOCB0eXBlIDQgYXQgMHgxNzANCmF0YXBjaTA6IFJlc2Vy dmVkIDB4MSBieXRlcyBmb3IgcmlkIDB4MWMgdHlwZSA0IGF0IDB4Mzc2DQphdGExOiByZXNldCB0 cDEgbWFzaz0wMCBvc3RhdDA9ZmYgb3N0YXQxPWZmDQppb2FwaWMwOiByb3V0aW5nIGludHBpbiAx NSAoSVNBIElSUSAxNSkgdG8gdmVjdG9yIDU1DQphdGExOiBbTVBTQUZFXQ0KYXRhMTogW0lUSFJF QURdDQphdGFwY2kxOiA8SW50ZWwgSUNIN00gU0FUQTMwMCBjb250cm9sbGVyPiBwb3J0IDB4MThj OC0weDE4Y2YsMHgxOGFjLTB4MThhZiwweDE4YzAtMHgxOGM3LDB4MThhOC0weDE4YWIsMHgxOGIw LTB4MThiZiBtZW0gMHhlZTQwNDQwMC0weGVlNDA0N2ZmIGlycSAxNiBhdCBkZXZpY2UgMzEuMiBv biBwY2kwDQphdGFwY2kxOiBSZXNlcnZlZCAweDEwIGJ5dGVzIGZvciByaWQgMHgyMCB0eXBlIDQg YXQgMHgxOGIwDQphdGFwY2kxOiBbTVBTQUZFXQ0KYXRhcGNpMTogW0lUSFJFQURdDQphdGFwY2kx OiBSZXNlcnZlZCAweDQwMCBieXRlcyBmb3IgcmlkIDB4MjQgdHlwZSAzIGF0IDB4ZWU0MDQ0MDAN CmF0YXBjaTE6IEFIQ0kgVmVyc2lvbiAwMS4xMCBjb250cm9sbGVyIHdpdGggNCBwb3J0cyBkZXRl Y3RlZA0KYXRhMjogPEFUQSBjaGFubmVsIDA+IG9uIGF0YXBjaTENCmF0YTI6IFNBVEEgY29ubmVj dCB0aW1lPTBtcw0KYXRhMjogW01QU0FGRV0NCmF0YTI6IFtJVEhSRUFEXQ0KYXRhMzogPEFUQSBj aGFubmVsIDE+IG9uIGF0YXBjaTENCmF0YTM6IHBvcnQgbm90IGltcGxlbWVudGVkDQphdGEzOiBb TVBTQUZFXQ0KYXRhMzogW0lUSFJFQURdDQphdGE0OiA8QVRBIGNoYW5uZWwgMj4gb24gYXRhcGNp MQ0KYXRhNDogcG9ydCBub3QgaW1wbGVtZW50ZWQNCmF0YTQ6IFtNUFNBRkVdDQphdGE0OiBbSVRI UkVBRF0NCmF0YTU6IDxBVEEgY2hhbm5lbCAzPiBvbiBhdGFwY2kxDQphdGE1OiBwb3J0IG5vdCBp bXBsZW1lbnRlZA0KYXRhNTogW01QU0FGRV0NCmF0YTU6IFtJVEhSRUFEXQ0KcGNpMDogPHNlcmlh bCBidXMsIFNNQnVzPiBhdCBkZXZpY2UgMzEuMyAobm8gZHJpdmVyIGF0dGFjaGVkKQ0KYWNwaV9k b2NrMDogPEFDUEkgRG9ja2luZyBTdGF0aW9uPiBvbiBhY3BpMA0KYWNwaV9kb2NrMDogX1NUQTog MDAwZiwgX0JETjogNGMwMDRkMjQsIF9VSUQ6IDAwMDANCmFjcGlfdHowOiA8VGhlcm1hbCBab25l PiBvbiBhY3BpMA0KYWNwaV90ejE6IDxUaGVybWFsIFpvbmU+IG9uIGFjcGkwDQpzcGVha2VyMDog PFBDIHNwZWFrZXI+IHBvcnQgMHg2MSBvbiBhY3BpMA0KYXRrYmRjMDogPEtleWJvYXJkIGNvbnRy b2xsZXIgKGk4MDQyKT4gcG9ydCAweDYwLDB4NjQgaXJxIDEgb24gYWNwaTANCmF0a2JkMDogPEFU IEtleWJvYXJkPiBpcnEgMSBvbiBhdGtiZGMwDQphdGtiZDogdGhlIGN1cnJlbnQga2JkIGNvbnRy b2xsZXIgY29tbWFuZCBieXRlIDAwNDcNCmF0a2JkOiBrZXlib2FyZCBJRCAweDU0YWIgKDIpDQpr YmQwIGF0IGF0a2JkMA0Ka2JkMDogYXRrYmQwLCBBVCAxMDEvMTAyICgyKSwgY29uZmlnOjB4MCwg ZmxhZ3M6MHgzZDAwMDANCmlvYXBpYzA6IHJvdXRpbmcgaW50cGluIDEgKElTQSBJUlEgMSkgdG8g dmVjdG9yIDU2DQphdGtiZDA6IFtHSUFOVC1MT0NLRURdDQphdGtiZDA6IFtJVEhSRUFEXQ0KcHNt MDogdW5hYmxlIHRvIGFsbG9jYXRlIElSUQ0KcHNtY3BucDA6IDxQUy8yIG1vdXNlIHBvcnQ+IGly cSAxMiBvbiBhY3BpMA0KcHNtMDogY3VycmVudCBjb21tYW5kIGJ5dGU6MDA0Nw0KcHNtMDogPFBT LzIgTW91c2U+IGlycSAxMiBvbiBhdGtiZGMwDQppb2FwaWMwOiByb3V0aW5nIGludHBpbiAxMiAo SVNBIElSUSAxMikgdG8gdmVjdG9yIDU3DQpwc20wOiBbR0lBTlQtTE9DS0VEXQ0KcHNtMDogW0lU SFJFQURdDQpwc20wOiBtb2RlbCBTeW5hcHRpY3MgVG91Y2hwYWQsIGRldmljZSBJRCAwLTAwLCAz IGJ1dHRvbnMNCnBzbTA6IGNvbmZpZzowMDAwMDAwMCwgZmxhZ3M6MDAwMDAwMDgsIHBhY2tldCBz aXplOjYNCnBzbTA6IHN5bmNtYXNrOmMwLCBzeW5jYml0czowMA0Kc2lvMDogY29uZmlndXJlZCBp cnEgNCBub3QgaW4gYml0bWFwIG9mIHByb2JlZCBpcnFzIDANCnNpbzA6IHBvcnQgbWF5IG5vdCBi ZSBlbmFibGVkDQpzaW8wOiBpcnEgbWFwczogMHg0YTAxIDB4NGEwMSAweDRhMDEgMHg0YTAxDQpz aW8wOiBwcm9iZSBmYWlsZWQgdGVzdChzKTogMCAxIDIgNCA2IDcgOQ0Kc2lvMDogaXJxIG1hcHM6 IDB4NGEwMSAweDRhMDkgMHg0YTAxIDB4NGEwMQ0Kc2lvMDogaXJxIG1hcHM6IDB4NGEwMSAweDRh MDkgMHg0YTAxIDB4NGEwMQ0Kc2lvMDogPEdlbmVyaWMgSVJEQS1jb21wYXRpYmxlIGRldmljZT4g cG9ydCAweDJmOC0weDJmZiBpcnEgMyBkcnEgMyBmbGFncyAweDEwIG9uIGFjcGkwDQpzaW8wOiB0 eXBlIDE2NTUwQQ0KaW9hcGljMDogcm91dGluZyBpbnRwaW4gMyAoSVNBIElSUSAzKSB0byB2ZWN0 b3IgNTgNCnNpbzA6IFtGSUxURVJdDQpiYXR0ZXJ5MDogPEFDUEkgQ29udHJvbCBNZXRob2QgQmF0 dGVyeT4gb24gYWNwaTANCmFjcGlfYWNhZDA6IDxBQyBBZGFwdGVyPiBvbiBhY3BpMA0KYWNwaV9p Ym0wOiA8SUJNIFRoaW5rUGFkIEFDUEkgRXh0cmFzPiBvbiBhY3BpMA0Kc2lvMTogY29uZmlndXJl ZCBpcnEgNCBub3QgaW4gYml0bWFwIG9mIHByb2JlZCBpcnFzIDANCnNpbzE6IHBvcnQgbWF5IG5v dCBiZSBlbmFibGVkDQpzaW8xOiBpcnEgbWFwczogMHg0YTAxIDB4NGEwMSAweDRhMDEgMHg0YTAx DQpzaW8xOiBwcm9iZSBmYWlsZWQgdGVzdChzKTogMCAxIDIgNCA2IDcgOQ0KYXRhOiBhdGEwIGFs cmVhZHkgZXhpc3RzOyBza2lwcGluZyBpdA0KYXRhOiBhdGExIGFscmVhZHkgZXhpc3RzOyBza2lw cGluZyBpdA0KYXRrYmRjOiBhdGtiZGMwIGFscmVhZHkgZXhpc3RzOyBza2lwcGluZyBpdA0Kc2M6 IHNjMCBhbHJlYWR5IGV4aXN0czsgc2tpcHBpbmcgaXQNCnNpbzogc2lvMCBhbHJlYWR5IGV4aXN0 czsgc2tpcHBpbmcgaXQNCnZnYTogdmdhMCBhbHJlYWR5IGV4aXN0czsgc2tpcHBpbmcgaXQNCnBu cF9pZGVudGlmeTogVHJ5aW5nIFJlYWRfUG9ydCBhdCAyMDMNCnBucF9pZGVudGlmeTogVHJ5aW5n IFJlYWRfUG9ydCBhdCAyNDMNCnBucF9pZGVudGlmeTogVHJ5aW5nIFJlYWRfUG9ydCBhdCAyODMN CnBucF9pZGVudGlmeTogVHJ5aW5nIFJlYWRfUG9ydCBhdCAyYzMNCnBucF9pZGVudGlmeTogVHJ5 aW5nIFJlYWRfUG9ydCBhdCAzMDMNCnBucF9pZGVudGlmeTogVHJ5aW5nIFJlYWRfUG9ydCBhdCAz NDMNCnBucF9pZGVudGlmeTogVHJ5aW5nIFJlYWRfUG9ydCBhdCAzODMNCnBucF9pZGVudGlmeTog VHJ5aW5nIFJlYWRfUG9ydCBhdCAzYzMNClBOUCBJZGVudGlmeSBjb21wbGV0ZQ0KaXNhX3Byb2Jl X2NoaWxkcmVuOiBkaXNhYmxpbmcgUG5QIGRldmljZXMNCmlzYV9wcm9iZV9jaGlsZHJlbjogcHJv YmluZyBub24tUG5QIGRldmljZXMNCnBtdGltZXIwIG9uIGlzYTANCm9ybTA6IDxJU0EgT3B0aW9u IFJPTXM+IGF0IGlvbWVtIDB4ZDAwMDAtMHhkMGZmZiwweGQxMDAwLTB4ZDFmZmYsMHhkYzAwMC0w eGRmZmZmLDB4ZTAwMDAtMHhlZmZmZiBwbnBpZCBPUk0wMDAwIG9uIGlzYTANCnNjMDogPFN5c3Rl bSBjb25zb2xlPiBhdCBmbGFncyAweDEwMCBvbiBpc2EwDQpzYzA6IFZHQSA8MTYgdmlydHVhbCBj b25zb2xlcywgZmxhZ3M9MHgzMDA+DQpzYzA6IGZiMCwga2JkMSwgdGVybWluYWwgZW11bGF0b3I6 IHNjIChzeXNjb25zIHRlcm1pbmFsKQ0KYWR2MDogbm90IHByb2JlZCAoZGlzYWJsZWQpDQphaGEw OiBub3QgcHJvYmVkIChkaXNhYmxlZCkNCmFpYzA6IG5vdCBwcm9iZWQgKGRpc2FibGVkKQ0KYnQw OiBub3QgcHJvYmVkIChkaXNhYmxlZCkNCmNzMDogbm90IHByb2JlZCAoZGlzYWJsZWQpDQplZDA6 IG5vdCBwcm9iZWQgKGRpc2FibGVkKQ0KZmRjMCBmYWlsZWQgdG8gcHJvYmUgYXQgcG9ydCAweDNm MCBpcnEgNiBkcnEgMiBvbiBpc2EwDQpmZTA6IG5vdCBwcm9iZWQgKGRpc2FibGVkKQ0KaWUwOiBu b3QgcHJvYmVkIChkaXNhYmxlZCkNCnBjaWMwIGZhaWxlZCB0byBwcm9iZSBhdCBwb3J0IDB4M2Uw IGlvbWVtIDB4ZDAwMDAgb24gaXNhMA0KcGNpYzE6IG5vdCBwcm9iZWQgKGRpc2FibGVkKQ0KcHBj MCBmYWlsZWQgdG8gcHJvYmUgYXQgaXJxIDcgb24gaXNhMA0Kc2lvMTogbm90IHByb2JlZCAoZGlz YWJsZWQpDQpzaW8yOiBub3QgcHJvYmVkIChkaXNhYmxlZCkNCnNpbzM6IG5vdCBwcm9iZWQgKGRp c2FibGVkKQ0Kc24wOiBub3QgcHJvYmVkIChkaXNhYmxlZCkNCnZnYTA6IDxHZW5lcmljIElTQSBW R0E+IGF0IHBvcnQgMHgzYzAtMHgzZGYgaW9tZW0gMHhhMDAwMC0weGJmZmZmIG9uIGlzYTANCnZ0 MDogbm90IHByb2JlZCAoZGlzYWJsZWQpDQppc2FfcHJvYmVfY2hpbGRyZW46IHByb2JpbmcgUG5Q IGRldmljZXMNCnVidDA6IDxCcm9hZGNvbSBDb3JwIEJDTTIwNDVCLCBjbGFzcyAyMjQvMSwgcmV2 IDIuMDAvMS4wMCwgYWRkciAyPiBvbiB1aHViMw0KdWJ0MDogSW50ZXJmYWNlIDAgZW5kcG9pbnRz OiBpbnRlcnJ1cHQ9MHg4MSwgYnVsay1pbj0weDgyLCBidWxrLW91dD0weDINCnVidDA6IEludGVy ZmFjZSAxIChhbHQuY29uZmlnIDQpIGVuZHBvaW50czogaXNvYy1pbj0weDgzLCBpc29jLW91dD0w eDM7IHdNYXhQYWNrZXRTaXplPTY0OyBuZnJhbWVzPTUsIGJ1ZmZlciBzaXplPTMyMA0KdWdlbjA6 IDxTVE1pY3JvZWxlY3Ryb25pY3MgQmlvbWV0cmljIENvcHJvY2Vzc29yLCBjbGFzcyAwLzAsIHJl diAxLjAwLzAuMDEsIGFkZHIgMz4gb24gdWh1YjMNCkRldmljZSBjb25maWd1cmF0aW9uIGZpbmlz aGVkLg0KUmVkdWNpbmcga2Vybi5tYXh2bm9kZXMgMTM0MjkwIC0+IDEwMDAwMA0KcHJvY2ZzIHJl Z2lzdGVyZWQNCmxhcGljOiBEaXZpc29yIDIsIEZyZXF1ZW5jeSA4MzEyNTUzNSBoeg0KVGltZWNv dW50ZXIgIlRTQyIgZnJlcXVlbmN5IDE5OTUwMTI3ODAgSHogcXVhbGl0eSAtMTAwDQpUaW1lY291 bnRlcnMgdGljayBldmVyeSAxLjAwMCBtc2VjDQpMaW51eCBFTEYgZXhlYyBoYW5kbGVyIGluc3Rh bGxlZA0KbG8wOiBicGYgYXR0YWNoZWQNCmlwZncyIGluaXRpYWxpemVkLCBkaXZlcnQgZW5hYmxl ZCwgcnVsZS1iYXNlZCBmb3J3YXJkaW5nIGVuYWJsZWQsIGRlZmF1bHQgdG8gZGVueSwgbG9nZ2lu ZyB1bmxpbWl0ZWQNCkRVTU1ZTkVUIHdpdGggSVB2NiBpbml0aWFsaXplZCAoMDQwODI2KQ0KQWNw aU9zRGVyaXZlUGNpSWQ6IFxcX1NCXy5QQ0kwLkVYUDIuUDJDUyAtPiBidXMgMCBkZXYgMjggZnVu YyAyDQpBY3BpT3NEZXJpdmVQY2lJZDogXFxfU0JfLlBDSTAuRVhQMC5QMENTIC0+IGJ1cyAwIGRl diAyOCBmdW5jIDBiYXR0ZXJ5MDogYmF0dGVyeSBpbml0aWFsaXphdGlvbiBzdGFydA0KYWNwaV9h Y2FkMDogYWNsaW5lIGluaXRpYWxpemF0aW9uIHN0YXJ0DQoNCmFjcGlfYWNhZDA6IE9uIExpbmUN CmFjcGlfYWNhZDA6IGFjbGluZSBpbml0aWFsaXphdGlvbiBkb25lLCB0cmllZCAxIHRpbWVzDQpi YXR0ZXJ5MDogYmF0dGVyeSBpbml0aWFsaXphdGlvbiBkb25lLCB0cmllZCAxIHRpbWVzDQphdGEw LW1hc3RlcjogcGlvPVBJTzQgd2RtYT1XRE1BMiB1ZG1hPVVETUEzMyBjYWJsZT00MCB3aXJlDQph Y2QwOiBzZXR0aW5nIFBJTzQgb24gSUNINyBjaGlwDQphY2QwOiBzZXR0aW5nIFVETUEzMyBvbiBJ Q0g3IGNoaXANCmFjZDA6IDxITC1EVC1TVCBEVkRSQU0gR1NBLTQwODNOLzEuMDg+IERWRFIgZHJp dmUgYXQgYXRhMCBhcyBtYXN0ZXINCmFjZDA6IHJlYWQgNDEzNEtCL3MgKDQxMzRLQi9zKSB3cml0 ZSAyNzU2S0IvcyAoMjc1NktCL3MpLCAyMDQ4S0IgYnVmZmVyLCBVRE1BMzMNCmFjZDA6IFJlYWRz OiBDRFIsIENEUlcsIENEREEgc3RyZWFtLCBEVkRST00sIERWRFIsIERWRFJBTSwgcGFja2V0DQph Y2QwOiBXcml0ZXM6IENEUiwgQ0RSVywgRFZEUiwgRFZEUkFNLCB0ZXN0IHdyaXRlLCBidXJucHJv b2YNCmFjZDA6IEF1ZGlvOiBwbGF5LCAyNTYgdm9sdW1lIGxldmVscw0KYWNkMDogTWVjaGFuaXNt OiBlamVjdGFibGUgdHJheSwgdW5sb2NrZWQNCmFjZDA6IE1lZGl1bTogbm8vYmxhbmsgZGlzYw0K YXRhMi1tYXN0ZXI6IHBpbz1QSU80IHdkbWE9V0RNQTIgdWRtYT1VRE1BMTAwIGNhYmxlPTQwIHdp cmUNCmFkMDogMTE0NDczTUIgPFNlYWdhdGUgU1Q5MTIwODIyQVMgMy5DTEY+IGF0IGF0YTItbWFz dGVyIFNBVEExNTANCmFkMDogMjM0NDQxNjQ4IHNlY3RvcnMgWzIzMjU4MUMvMTZILzYzU10gMTYg c2VjdG9ycy9pbnRlcnJ1cHQgMSBkZXB0aCBxdWV1ZQ0KcGNtMDogSERBX0RFQlVHOiBIREEgQ29u ZmlnOiBvbj0weDAwMDAwMDAwIG9mZj0weDAwMDAwMDAwDQpwY20wOiBIREFfREVCVUc6IFN0YXJ0 aW5nIENPUkIgRW5naW5lLi4uDQpwY20wOiBIREFfREVCVUc6IFN0YXJ0aW5nIFJJUkIgRW5naW5l Li4uDQpwY20wOiBIREFfREVCVUc6IEVuYWJsaW5nIGNvbnRyb2xsZXIgaW50ZXJydXB0Li4uDQpw Y20wOiBIREFfREVCVUc6IFNjYW5uaW5nIEhEQSBjb2RlY3MuLi4NCnBjbTA6IEhEQV9ERUJVRzog UHJvYmluZyBjb2RlYzogMA0KcGNtMDogSERBX0RFQlVHOiAJc3RhcnRub2RlPTEgZW5kbm9kZT0y DQpwY20wOiBIREFfREVCVUc6IAlGb3VuZCBBRkcgbmlkPTEgW3N0YXJ0bm9kZT0xIGVuZG5vZGU9 Ml0NCnBjbTA6IEhEQV9ERUJVRzogUGFyc2luZyBBRkcgbmlkPTEgY2FkPTANCnBjbTA6ICAgICAg ICBWZW5kb3I6IDB4MDAwMDExZDQNCnBjbTA6ICAgICAgICBEZXZpY2U6IDB4MDAwMDE5ODENCnBj bTA6ICAgICAgUmV2aXNpb246IDB4MDAwMDAwMDINCnBjbTA6ICAgICAgU3RlcHBpbmc6IDB4MDAw MDAwMDANCnBjbTA6IFBDSSBTdWJ2ZW5kb3I6IDB4MjAxMDE3YWENCnBjbTA6ICAgICAgICAgTm9k ZXM6IHN0YXJ0PTIgZW5kbm9kZT0zMiB0b3RhbD0zMA0KcGNtMDogICAgIENPUkIgc2l6ZTogMjU2 DQpwY20wOiAgICAgUklSQiBzaXplOiAyNTYNCnBjbTA6ICAgICAgIFN0cmVhbXM6IElTUz00IE9T Uz00IEJTUz0wDQpwY20wOiAgICAgICAgICBHUElPOiAweDQwMDAwMDA0DQpwY20wOiAgICAgICAg ICAgICAgICBOdW1HUElPPTQgTnVtR1BPPTAgTnVtR1BJPTAgR1BJV2FrZT0wIEdQSVVuc29sPTEN CnBjbTA6IGhkYWNfd2lkZ2V0X2Nvbm5lY3Rpb25fcGFyc2U6IEdIT1NUOiBuaWQ9MiBqPTAgZW50 bnVtPTQgaW5kZXg9MCByZXM9MHgwMDAwMDQwMQ0KcGNtMDogSERBX0RFQlVHOiBoZGFjX3dpZGdl dF9jb25uZWN0aW9uX3BhcnNlOiBuaWQ9MiBlbnRyaWVzPTIgZm91bmQ9Mg0KcGNtMDogSERBX0RF QlVHOiBoZGFjX3dpZGdldF9jb25uZWN0aW9uX3BhcnNlOiBuaWQ9NCBlbnRyaWVzPTEgZm91bmQ9 MQ0KcGNtMDogSERBX0RFQlVHOiBoZGFjX3dpZGdldF9jb25uZWN0aW9uX3BhcnNlOiBuaWQ9NSBl bnRyaWVzPTIgZm91bmQ9Mg0KcGNtMDogSERBX0RFQlVHOiBoZGFjX3dpZGdldF9jb25uZWN0aW9u X3BhcnNlOiBuaWQ9NiBlbnRyaWVzPTIgZm91bmQ9Mg0KcGNtMDogSERBX0RFQlVHOiBoZGFjX3dp ZGdldF9jb25uZWN0aW9uX3BhcnNlOiBuaWQ9NyBlbnRyaWVzPTEgZm91bmQ9MQ0KcGNtMDogSERB X0RFQlVHOiBoZGFjX3dpZGdldF9jb25uZWN0aW9uX3BhcnNlOiBuaWQ9OSBlbnRyaWVzPTIgZm91 bmQ9Mg0KcGNtMDogSERBX0RFQlVHOiBoZGFjX3dpZGdldF9jb25uZWN0aW9uX3BhcnNlOiBuaWQ9 MTAgZW50cmllcz0xIGZvdW5kPTENCnBjbTA6IEhEQV9ERUJVRzogaGRhY193aWRnZXRfY29ubmVj dGlvbl9wYXJzZTogbmlkPTExIGVudHJpZXM9NiBmb3VuZD02DQpwY20wOiBIREFfREVCVUc6IGhk YWNfd2lkZ2V0X2Nvbm5lY3Rpb25fcGFyc2U6IG5pZD0xMiBlbnRyaWVzPTIgZm91bmQ9Mg0KcGNt MDogSERBX0RFQlVHOiBoZGFjX3dpZGdldF9jb25uZWN0aW9uX3BhcnNlOiBuaWQ9MTMgZW50cmll cz0yIGZvdW5kPTINCnBjbTA6IEhEQV9ERUJVRzogaGRhY193aWRnZXRfY29ubmVjdGlvbl9wYXJz ZTogbmlkPTE0IGVudHJpZXM9OCBmb3VuZD04DQpwY20wOiBIREFfREVCVUc6IGhkYWNfd2lkZ2V0 X2Nvbm5lY3Rpb25fcGFyc2U6IG5pZD0xNSBlbnRyaWVzPTEgZm91bmQ9MQ0KcGNtMDogSERBX0RF QlVHOiBoZGFjX3dpZGdldF9jb25uZWN0aW9uX3BhcnNlOiBuaWQ9MTcgZW50cmllcz0xIGZvdW5k PTENCnBjbTA6IEhEQV9ERUJVRzogaGRhY193aWRnZXRfY29ubmVjdGlvbl9wYXJzZTogbmlkPTE4 IGVudHJpZXM9MSBmb3VuZD0xDQpwY20wOiBIREFfREVCVUc6IGhkYWNfd2lkZ2V0X2Nvbm5lY3Rp b25fcGFyc2U6IG5pZD0xOSBlbnRyaWVzPTEgZm91bmQ9MQ0KcGNtMDogSERBX0RFQlVHOiBoZGFj X3dpZGdldF9jb25uZWN0aW9uX3BhcnNlOiBuaWQ9MjAgZW50cmllcz02IGZvdW5kPTEzDQpwY20w OiBIREFfREVCVUc6IGhkYWNfd2lkZ2V0X2Nvbm5lY3Rpb25fcGFyc2U6IG5pZD0yMSBlbnRyaWVz PTggZm91bmQ9OA0KcGNtMDogSERBX0RFQlVHOiBoZGFjX3dpZGdldF9jb25uZWN0aW9uX3BhcnNl OiBuaWQ9MjQgZW50cmllcz0yIGZvdW5kPTINCnBjbTA6IEhEQV9ERUJVRzogaGRhY193aWRnZXRf Y29ubmVjdGlvbl9wYXJzZTogbmlkPTI2IGVudHJpZXM9MSBmb3VuZD0xDQpwY20wOiBIREFfREVC VUc6IGhkYWNfd2lkZ2V0X2Nvbm5lY3Rpb25fcGFyc2U6IG5pZD0yNyBlbnRyaWVzPTEgZm91bmQ9 MQ0KcGNtMDogSERBX0RFQlVHOiBoZGFjX3dpZGdldF9jb25uZWN0aW9uX3BhcnNlOiBuaWQ9Mjgg ZW50cmllcz0xIGZvdW5kPTENCnBjbTA6IEhEQV9ERUJVRzogaGRhY193aWRnZXRfY29ubmVjdGlv bl9wYXJzZTogbmlkPTI5IGVudHJpZXM9MSBmb3VuZD0xDQpwY20wOiBIREFfREVCVUc6IGhkYWNf d2lkZ2V0X2Nvbm5lY3Rpb25fcGFyc2U6IG5pZD0zMCBlbnRyaWVzPTEgZm91bmQ9MQ0KcGNtMDog SERBX0RFQlVHOiBoZGFjX3dpZGdldF9jb25uZWN0aW9uX3BhcnNlOiBuaWQ9MzEgZW50cmllcz0x IGZvdW5kPTENCnBjbTA6IEhEQV9ERUJVRzogUGFyc2luZyBDdGxzLi4uDQpwY20wOiBIREFfREVC VUc6IFBhcnNpbmcgdmVuZG9yIHBhdGNoLi4uDQpwY20wOiBIREFfREVCVUc6IEJ1aWxkaW5nIEFG RyB0cmVlLi4uDQpwY20wOiBIREFfREVCVUc6IEhXaVA6IEhEQSBXaWRnZXQgUGFyc2VyIC0gUmV2 aXNpb24gMQ0KcGNtMDogSERBX0RFQlVHOiBIV2lQOiBGb3VuZCAxIERBQyBwYXRoIHVzaW5nIEhE QV9QQVJTRV9NSVhFUiBzdHJhdGVneS4NCnBjbTA6IEhEQV9ERUJVRzogQUZHIGNvbW1pdC4uLg0K cGNtMDogSERBX0RFQlVHOiBDdGxzIGNvbW1pdC4uLg0KcGNtMDogWyAxXSBDdGwgbmlkPTUgQmlu ZCB0byBOT05FDQpwY20wOiBbIDJdIEN0bCBuaWQ9NSBCaW5kIHRvIE5PTkUNCnBjbTA6IFsgM10g Q3RsIG5pZD02IERJU0FCTEVEDQpwY20wOiBbIDRdIEN0bCBuaWQ9NyBESVNBQkxFRA0KcGNtMDog WyA1XSBDdGwgbmlkPTggQmluZCB0byBOT05FDQpwY20wOiBbIDZdIEN0bCBuaWQ9OSBESVNBQkxF RA0KcGNtMDogWyA3XSBDdGwgbmlkPTkgRElTQUJMRUQNCnBjbTA6IFsxMV0gQ3RsIG5pZD0xOSBC aW5kIHRvIE5PTkUNCnBjbTA6IFsxM10gQ3RsIG5pZD0yNCBESVNBQkxFRA0KcGNtMDogWzE0XSBD dGwgbmlkPTI0IERJU0FCTEVEDQpwY20wOiBbMTVdIEN0bCBuaWQ9MjYgQmluZCB0byBOT05FDQpw Y20wOiBbMTZdIEN0bCBuaWQ9MjcgQmluZCB0byBOT05FDQpwY20wOiBbMTddIEN0bCBuaWQ9Mjgg QmluZCB0byBOT05FDQpwY20wOiBbMTldIEN0bCBuaWQ9MzAgQmluZCB0byBOT05FDQpwY20wOiBb MjBdIEN0bCBuaWQ9MzEgQmluZCB0byBOT05FDQpwY20wOiBIREFfREVCVUc6IFBDTURJUl9QTEFZ IHNldHVwLi4uDQpwY20wOiBIREFfREVCVUc6IFBDTURJUl9SRUMgc2V0dXAuLi4NCnBjbTA6IEhE QV9ERUJVRzogT1NTIG1peGVyIGluaXRpYWxpemF0aW9uLi4uDQpwY20wOiBNaXhlciAidm9sIjoN CnBjbTA6IE1peGVyICJwY20iOg0KcGNtMDogTWl4ZXIgInNwZWFrZXIiOg0KcGNtMDogTWl4ZXIg Im1pYyI6DQpwY20wOiBNaXhlciAiY2QiOg0KcGNtMDogTWl4ZXIgInJlYyI6DQpwY20wOiBIREFf REVCVUc6IFJlZ2lzdGVyaW5nIFBDTSBjaGFubmVscy4uLg0KcGNtMDogY2xvbmUgbWFuYWdlcjog ZGVhZGxpbmU9NzUwbXMgZmxhZ3M9MHg4MDAwMDAxZQ0KcGNtMDogaGRhY19kbWFfYWxsb2M6IHNp emU9NDA5NiAtPiByb3VuZHN6PTQwOTYNCnBjbTA6IHNuZGJ1Zl9zZXRtYXAgMTdlODAwMCwgNDAw MDsgMHhlNTVjYTAwMCAtPiAxN2U4MDAwDQpwY20wOiBoZGFjX2RtYV9hbGxvYzogc2l6ZT00MDk2 IC0+IHJvdW5kc3o9NDA5Ng0KcGNtMDogc25kYnVmX3NldG1hcCAxN2ZjMDAwLCA0MDAwOyAweGU1 NWNlMDAwIC0+IDE3ZmMwMDANCnBjbTA6IDxIREEgQ29kZWM6IEFuYWxvZyBEZXZpY2VzIEFEMTk4 MUhEPg0KcGNtMDogPEhEQSBDb2RlYyBJRDogMHgxMWQ0MTk4MT4NCnBjbTA6IDxIREEgRHJpdmVy IFJldmlzaW9uOiAyMDA3MDcxMF8wMDQ3Pg0KcGNtMDogDQpwY20wOiBIREEgY29uZmlnL3F1aXJr czogZm9yY2VzdGVyZW8gaXZyZWY1MCBpdnJlZjgwIGl2cmVmMTAwIGl2cmVmDQpwY20wOiANCnBj bTA6ICstLS0tLS0tLS0tLS0tLS0tLS0tKw0KcGNtMDogfCBEVU1QSU5HIEhEQSBOT0RFUyB8DQpw Y20wOiArLS0tLS0tLS0tLS0tLS0tLS0tLSsNCnBjbTA6IA0KcGNtMDogRGVmYXVsdCBQYXJhbWV0 ZXINCnBjbTA6IC0tLS0tLS0tLS0tLS0tLS0tDQpwY20wOiAgICAgIFN0cmVhbSBjYXA6IDB4MDAw MDAwMDENCnBjbTA6ICAgICAgICAgIEZvcm1hdDogUENNDQpwY20wOiAgICAgICAgIFBDTSBjYXA6 IDB4MDAwZTAwN2YNCnBjbTA6ICAgICAgICBQQ00gc2l6ZTogMTYgMjAgMjQNCnBjbTA6ICAgICAg ICBQQ00gcmF0ZTogOCAxMSAxNiAyMiAzMiA0NCA0OA0KcGNtMDogICAgICAgICAgSU4gYW1wOiAw eDAwMjcwMzAwDQpwY20wOiAgICAgICAgIE9VVCBhbXA6IDB4ODAwNTNmM2QNCnBjbTA6IA0KcGNt MDogICAgICAgICAgICAgbmlkOiAyIFtESUdJVEFMXSBbRElTQUJMRURdDQpwY20wOiAgICAgICAg ICAgIG5hbWU6IGF1ZGlvIG91dHB1dA0KcGNtMDogICAgICB3aWRnZXRfY2FwOiAweDAwMDMwMzEx DQpwY20wOiAgICAgUGFyc2UgZmxhZ3M6IDB4MDAwMDAwMDANCnBjbTA6ICAgICAgIEN0bCBmbGFn czogMHgwMDAwMDAwMA0KcGNtMDogICAgICBTdHJlYW0gY2FwOiAweDAwMDAwMDA1DQpwY20wOiAg ICAgICAgICBGb3JtYXQ6IEFDMyBQQ00NCnBjbTA6ICAgICAgICAgUENNIGNhcDogMHgwMDAyMDA2 MA0KcGNtMDogICAgICAgIFBDTSBzaXplOiAxNg0KcGNtMDogICAgICAgIFBDTSByYXRlOiA0NCA0 OA0KcGNtMDogICAgIGNvbm5lY3Rpb25zOiAyDQpwY20wOiAgICAgICAgICAgfA0KcGNtMDogICAg ICAgICAgICsgPC0gbmlkPTEgW0dIT1NUIV0gW1VOS05PV05dDQpwY20wOiAgICAgICAgICAgfA0K cGNtMDogICAgICAgICAgICsgPC0gbmlkPTQgW2F1ZGlvIGlucHV0XQ0KcGNtMDogDQpwY20wOiAg ICAgICAgICAgICBuaWQ6IDMgW0FOQUxPR10NCnBjbTA6ICAgICAgICAgICAgbmFtZTogYXVkaW8g b3V0cHV0DQpwY20wOiAgICAgIHdpZGdldF9jYXA6IDB4MDAwMDA0NDENCnBjbTA6ICAgICBQYXJz ZSBmbGFnczogMHgwMDAwMDAwMQ0KcGNtMDogICAgICAgQ3RsIGZsYWdzOiAweDAwMDAwMDExDQpw Y20wOiAgICAgIFN0cmVhbSBjYXA6IDB4MDAwMDAwMDENCnBjbTA6ICAgICAgICAgIEZvcm1hdDog UENNDQpwY20wOiAgICAgICAgIFBDTSBjYXA6IDB4MDAwZTAwN2YNCnBjbTA6ICAgICAgICBQQ00g c2l6ZTogMTYgMjAgMjQNCnBjbTA6ICAgICAgICBQQ00gcmF0ZTogOCAxMSAxNiAyMiAzMiA0NCA0 OA0KcGNtMDogICAgIGNvbm5lY3Rpb25zOiAwDQpwY20wOiANCnBjbTA6ICAgICAgICAgICAgIG5p ZDogNCBbQU5BTE9HXQ0KcGNtMDogICAgICAgICAgICBuYW1lOiBhdWRpbyBpbnB1dA0KcGNtMDog ICAgICB3aWRnZXRfY2FwOiAweDAwMTAwNTExDQpwY20wOiAgICAgUGFyc2UgZmxhZ3M6IDB4MDAw MDAwMDINCnBjbTA6ICAgICAgIEN0bCBmbGFnczogMHgwMDAwMDgwMA0KcGNtMDogICAgICBTdHJl YW0gY2FwOiAweDAwMDAwMDAxDQpwY20wOiAgICAgICAgICBGb3JtYXQ6IFBDTQ0KcGNtMDogICAg ICAgICBQQ00gY2FwOiAweDAwMDYwMDdmDQpwY20wOiAgICAgICAgUENNIHNpemU6IDE2IDIwDQpw Y20wOiAgICAgICAgUENNIHJhdGU6IDggMTEgMTYgMjIgMzIgNDQgNDgNCnBjbTA6ICAgICBjb25u ZWN0aW9uczogMQ0KcGNtMDogICAgICAgICAgIHwNCnBjbTA6ICAgICAgICAgICArIDwtIG5pZD0y MSBbYXVkaW8gc2VsZWN0b3JdDQpwY20wOiANCnBjbTA6ICAgICAgICAgICAgIG5pZDogNSBbQU5B TE9HXQ0KcGNtMDogICAgICAgICAgICBuYW1lOiBwaW46IGxpbmUgb3V0IChqYWNrIC8gZml4ZWQp DQpwY20wOiAgICAgIHdpZGdldF9jYXA6IDB4MDA0MDAxODcNCnBjbTA6ICAgICBQYXJzZSBmbGFn czogMHgwMDAwMDAwMQ0KcGNtMDogICAgICAgQ3RsIGZsYWdzOiAweDAwMDAwMDAwDQpwY20wOiAg ICAgICAgIFBpbiBjYXA6IDB4MDAwMTE3M2YNCnBjbTA6ICAgICAgICAgICAgICAgICAgSVNDIFRS UUQgSFAgT1VUIElOIFZSRUZbIDUwIDgwIEdST1VORCBISVogXSBFQVBEIDogVU5TT0wNCnBjbTA6 ICAgICAgUGluIGNvbmZpZzogMHhjMzAxNDExMA0KcGNtMDogICAgIFBpbiBjb250cm9sOiAweDAw MDAwMDQwIE9VVA0KcGNtMDogICAgICAgICAgICBFQVBEOiAweDAwMDAwMDAyDQpwY20wOiAgICAg IE91dHB1dCBhbXA6IDB4ODAwNTNmM2QNCnBjbTA6ICAgICAgICAgICAgICAgICAgbXV0ZT0xIHN0 ZXA9NjMgc2l6ZT01IG9mZnNldD02MQ0KcGNtMDogICAgICAgSW5wdXQgYW1wOiAweDAwMjcwMzAw DQpwY20wOiAgICAgICAgICAgICAgICAgIG11dGU9MCBzdGVwPTMgc2l6ZT0zOSBvZmZzZXQ9MA0K cGNtMDogICAgIGNvbm5lY3Rpb25zOiAyDQpwY20wOiAgICAgICAgICAgfA0KcGNtMDogICAgICAg ICAgICsgPC0gbmlkPTMgW2F1ZGlvIG91dHB1dF0NCnBjbTA6ICAgICAgICAgICB8DQpwY20wOiAg ICAgICAgICAgKyA8LSBuaWQ9MTQgW2F1ZGlvIG1peGVyXSAoc2VsZWN0ZWQpDQpwY20wOiANCnBj bTA6ICAgICAgICAgICAgIG5pZDogNiBbQU5BTE9HXSBbRElTQUJMRURdDQpwY20wOiAgICAgICAg ICAgIG5hbWU6IHBpbjogaGVhZHBob25lcyBvdXQgKG5vbmUpDQpwY20wOiAgICAgIHdpZGdldF9j YXA6IDB4MDA0MDAxODUNCnBjbTA6ICAgICBQYXJzZSBmbGFnczogMHgwMDAwMDAwMA0KcGNtMDog ICAgICAgQ3RsIGZsYWdzOiAweDAwMDAwMDAwDQpwY20wOiAgICAgICAgIFBpbiBjYXA6IDB4MDAw MDAwMWYNCnBjbTA6ICAgICAgICAgICAgICAgICAgSVNDIFRSUUQgSFAgT1VUIDogVU5TT0wNCnBj bTA6ICAgICAgUGluIGNvbmZpZzogMHg0MjIxNDBmMA0KcGNtMDogICAgIFBpbiBjb250cm9sOiAw eDAwMDAwMGMwIEhQIE9VVA0KcGNtMDogICAgICBPdXRwdXQgYW1wOiAweDgwMDUzZjNkDQpwY20w OiAgICAgICAgICAgICAgICAgIG11dGU9MSBzdGVwPTYzIHNpemU9NSBvZmZzZXQ9NjENCnBjbTA6 ICAgICBjb25uZWN0aW9uczogMg0KcGNtMDogICAgICAgICAgIHwNCnBjbTA6ICAgICAgICAgICAr IDwtIG5pZD0zIFthdWRpbyBvdXRwdXRdDQpwY20wOiAgICAgICAgICAgfA0KcGNtMDogICAgICAg ICAgICsgPC0gbmlkPTE0IFthdWRpbyBtaXhlcl0NCnBjbTA6IA0KcGNtMDogICAgICAgICAgICAg bmlkOiA3IFtBTkFMT0ddIFtESVNBQkxFRF0NCnBjbTA6ICAgICAgICAgICAgbmFtZTogcGluOiBz cGVha2VyIChub25lKQ0KcGNtMDogICAgICB3aWRnZXRfY2FwOiAweDAwNDAwMTA0DQpwY20wOiAg ICAgUGFyc2UgZmxhZ3M6IDB4MDAwMDAwMDANCnBjbTA6ICAgICAgIEN0bCBmbGFnczogMHgwMDAw MDAwMA0KcGNtMDogICAgICAgICBQaW4gY2FwOiAweDAwMDAwMDEwDQpwY20wOiAgICAgICAgICAg ICAgICAgIE9VVA0KcGNtMDogICAgICBQaW4gY29uZmlnOiAweDU5MTMxMWYwDQpwY20wOiAgICAg UGluIGNvbnRyb2w6IDB4MDAwMDAwNDAgT1VUDQpwY20wOiAgICAgIE91dHB1dCBhbXA6IDB4ODAw NTNmM2QNCnBjbTA6ICAgICAgICAgICAgICAgICAgbXV0ZT0xIHN0ZXA9NjMgc2l6ZT01IG9mZnNl dD02MQ0KcGNtMDogICAgIGNvbm5lY3Rpb25zOiAxDQpwY20wOiAgICAgICAgICAgfA0KcGNtMDog ICAgICAgICAgICsgPC0gbmlkPTE1IFthdWRpbyBtaXhlcl0NCnBjbTA6IA0KcGNtMDogICAgICAg ICAgICAgbmlkOiA4IFtBTkFMT0ddDQpwY20wOiAgICAgICAgICAgIG5hbWU6IHBpbjogTWljIGlu IChqYWNrIC8gZml4ZWQpDQpwY20wOiAgICAgIHdpZGdldF9jYXA6IDB4MDA0MDAwODMNCnBjbTA6 ICAgICBQYXJzZSBmbGFnczogMHgwMDAwMDAwMg0KcGNtMDogICAgICAgQ3RsIGZsYWdzOiAweDAw MDAwMDgxDQpwY20wOiAgICAgICAgIFBpbiBjYXA6IDB4MDAwMDE3MjcNCnBjbTA6ICAgICAgICAg ICAgICAgICAgSVNDIFRSUUQgSU4gVlJFRlsgNTAgODAgR1JPVU5EIEhJWiBdIDogVU5TT0wNCnBj bTA6ICAgICAgUGluIGNvbmZpZzogMHhjM2ExNTAyZQ0KcGNtMDogICAgIFBpbiBjb250cm9sOiAw eDAwMDAwMDI0IElODQpwY20wOiAgICAgICBJbnB1dCBhbXA6IDB4MDAyNzAzMDANCnBjbTA6ICAg ICAgICAgICAgICAgICAgbXV0ZT0wIHN0ZXA9MyBzaXplPTM5IG9mZnNldD0wDQpwY20wOiAgICAg Y29ubmVjdGlvbnM6IDANCnBjbTA6IA0KcGNtMDogICAgICAgICAgICAgbmlkOiA5IFtBTkFMT0dd IFtESVNBQkxFRF0NCnBjbTA6ICAgICAgICAgICAgbmFtZTogcGluOiBsaW5lIGluIChub25lKQ0K cGNtMDogICAgICB3aWRnZXRfY2FwOiAweDAwNDAwMTg3DQpwY20wOiAgICAgUGFyc2UgZmxhZ3M6 IDB4MDAwMDAwMDANCnBjbTA6ICAgICAgIEN0bCBmbGFnczogMHgwMDAwMDAwMA0KcGNtMDogICAg ICAgICBQaW4gY2FwOiAweDAwMDAxNzM3DQpwY20wOiAgICAgICAgICAgICAgICAgIElTQyBUUlFE IE9VVCBJTiBWUkVGWyA1MCA4MCBHUk9VTkQgSElaIF0gOiBVTlNPTA0KcGNtMDogICAgICBQaW4g Y29uZmlnOiAweDQxODEzMGYwDQpwY20wOiAgICAgUGluIGNvbnRyb2w6IDB4MDAwMDAwNjAgSU4g T1VUDQpwY20wOiAgICAgIE91dHB1dCBhbXA6IDB4ODAwNTNmM2QNCnBjbTA6ICAgICAgICAgICAg ICAgICAgbXV0ZT0xIHN0ZXA9NjMgc2l6ZT01IG9mZnNldD02MQ0KcGNtMDogICAgICAgSW5wdXQg YW1wOiAweDAwMjcwMzAwDQpwY20wOiAgICAgICAgICAgICAgICAgIG11dGU9MCBzdGVwPTMgc2l6 ZT0zOSBvZmZzZXQ9MA0KcGNtMDogICAgIGNvbm5lY3Rpb25zOiAyDQpwY20wOiAgICAgICAgICAg fA0KcGNtMDogICAgICAgICAgICsgPC0gbmlkPTMgW2F1ZGlvIG91dHB1dF0NCnBjbTA6ICAgICAg ICAgICB8DQpwY20wOiAgICAgICAgICAgKyA8LSBuaWQ9MTQgW2F1ZGlvIG1peGVyXQ0KcGNtMDog DQpwY20wOiAgICAgICAgICAgICBuaWQ6IDEwIFtESUdJVEFMXSBbRElTQUJMRURdDQpwY20wOiAg ICAgICAgICAgIG5hbWU6IHBpbjogU1BESUYgb3V0IChqYWNrKQ0KcGNtMDogICAgICB3aWRnZXRf Y2FwOiAweDAwNDAwMzAxDQpwY20wOiAgICAgUGFyc2UgZmxhZ3M6IDB4MDAwMDAwMDANCnBjbTA6 ICAgICAgIEN0bCBmbGFnczogMHgwMDAwMDAwMA0KcGNtMDogICAgICAgICBQaW4gY2FwOiAweDAw MDAwMDEwDQpwY20wOiAgICAgICAgICAgICAgICAgIE9VVA0KcGNtMDogICAgICBQaW4gY29uZmln OiAweDAxNDQxMWYwDQpwY20wOiAgICAgUGluIGNvbnRyb2w6IDB4MDAwMDAwNDAgT1VUDQpwY20w OiAgICAgY29ubmVjdGlvbnM6IDENCnBjbTA6ICAgICAgICAgICB8DQpwY20wOiAgICAgICAgICAg KyA8LSBuaWQ9MiBbYXVkaW8gb3V0cHV0XSBbRElTQUJMRURdDQpwY20wOiANCnBjbTA6ICAgICAg ICAgICAgIG5pZDogMTEgW0FOQUxPR10NCnBjbTA6ICAgICAgICAgICAgbmFtZTogYXVkaW8gc2Vs ZWN0b3INCnBjbTA6ICAgICAgd2lkZ2V0X2NhcDogMHgwMDMwMDEwMQ0KcGNtMDogICAgIFBhcnNl IGZsYWdzOiAweDAwMDAwMDAyDQpwY20wOiAgICAgICBDdGwgZmxhZ3M6IDB4MDAwMDAwMDANCnBj bTA6ICAgICBjb25uZWN0aW9uczogNg0KcGNtMDogICAgICAgICAgIHwNCnBjbTA6ICAgICAgICAg ICArIDwtIG5pZD0zIFthdWRpbyBvdXRwdXRdDQpwY20wOiAgICAgICAgICAgfA0KcGNtMDogICAg ICAgICAgICsgPC0gbmlkPTEyIFthdWRpbyBtaXhlcl0NCnBjbTA6ICAgICAgICAgICB8DQpwY20w OiAgICAgICAgICAgKyA8LSBuaWQ9OSBbcGluOiBsaW5lIGluIChub25lKV0gW0RJU0FCTEVEXQ0K cGNtMDogICAgICAgICAgIHwNCnBjbTA6ICAgICAgICAgICArIDwtIG5pZD0xNCBbYXVkaW8gbWl4 ZXJdIChzZWxlY3RlZCkNCnBjbTA6ICAgICAgICAgICB8DQpwY20wOiAgICAgICAgICAgKyA8LSBu aWQ9NSBbcGluOiBsaW5lIG91dCAoamFjayAvIGZpeGVkKV0NCnBjbTA6ICAgICAgICAgICB8DQpw Y20wOiAgICAgICAgICAgKyA8LSBuaWQ9MjQgW3BpbjogTWljIGluIChub25lKV0gW0RJU0FCTEVE XQ0KcGNtMDogDQpwY20wOiAgICAgICAgICAgICBuaWQ6IDEyIFtBTkFMT0ddDQpwY20wOiAgICAg ICAgICAgIG5hbWU6IGF1ZGlvIG1peGVyDQpwY20wOiAgICAgIHdpZGdldF9jYXA6IDB4MDAyMDAx MDENCnBjbTA6ICAgICBQYXJzZSBmbGFnczogMHgwMDAwMDAwMg0KcGNtMDogICAgICAgQ3RsIGZs YWdzOiAweDAwMDAwMDAwDQpwY20wOiAgICAgY29ubmVjdGlvbnM6IDINCnBjbTA6ICAgICAgICAg ICB8DQpwY20wOiAgICAgICAgICAgKyA8LSBuaWQ9MzAgW2F1ZGlvIHNlbGVjdG9yXQ0KcGNtMDog ICAgICAgICAgIHwNCnBjbTA6ICAgICAgICAgICArIDwtIG5pZD0zMSBbYXVkaW8gc2VsZWN0b3Jd DQpwY20wOiANCnBjbTA6ICAgICAgICAgICAgIG5pZDogMTMgW0FOQUxPR10NCnBjbTA6ICAgICAg ICAgICAgbmFtZTogYXVkaW8gc2VsZWN0b3INCnBjbTA6ICAgICAgd2lkZ2V0X2NhcDogMHgwMDMw MDEwYw0KcGNtMDogICAgIFBhcnNlIGZsYWdzOiAweDAwMDAwMDAwDQpwY20wOiAgICAgICBDdGwg ZmxhZ3M6IDB4MDAwMDAwMjENCnBjbTA6ICAgICAgT3V0cHV0IGFtcDogMHg4MDBiMGYwZg0KcGNt MDogICAgICAgICAgICAgICAgICBtdXRlPTEgc3RlcD0xNSBzaXplPTExIG9mZnNldD0xNQ0KcGNt MDogICAgIGNvbm5lY3Rpb25zOiAyDQpwY20wOiAgICAgICAgICAgfA0KcGNtMDogICAgICAgICAg ICsgPC0gbmlkPTE2IFtiZWVwIHdpZGdldF0gKHNlbGVjdGVkKQ0KcGNtMDogICAgICAgICAgIHwN CnBjbTA6ICAgICAgICAgICArIDwtIG5pZD0yMiBbcGluOiBvdGhlciAobm9uZSldIFtESVNBQkxF RF0NCnBjbTA6IA0KcGNtMDogICAgICAgICAgICAgbmlkOiAxNCBbQU5BTE9HXQ0KcGNtMDogICAg ICAgICAgICBuYW1lOiBhdWRpbyBtaXhlcg0KcGNtMDogICAgICB3aWRnZXRfY2FwOiAweDAwMjAw MTAxDQpwY20wOiAgICAgUGFyc2UgZmxhZ3M6IDB4MDAwMDAwMDMNCnBjbTA6ICAgICAgIEN0bCBm bGFnczogMHgwMDAwMDFiMQ0KcGNtMDogICAgIGNvbm5lY3Rpb25zOiA4DQpwY20wOiAgICAgICAg ICAgfA0KcGNtMDogICAgICAgICAgICsgPC0gbmlkPTEzIFthdWRpbyBzZWxlY3Rvcl0NCnBjbTA6 ICAgICAgICAgICB8DQpwY20wOiAgICAgICAgICAgKyA8LSBuaWQ9MTcgW2F1ZGlvIHNlbGVjdG9y XQ0KcGNtMDogICAgICAgICAgIHwNCnBjbTA6ICAgICAgICAgICArIDwtIG5pZD0xOCBbYXVkaW8g c2VsZWN0b3JdDQpwY20wOiAgICAgICAgICAgfA0KcGNtMDogICAgICAgICAgICsgPC0gbmlkPTE5 IFthdWRpbyBzZWxlY3Rvcl0NCnBjbTA6ICAgICAgICAgICB8DQpwY20wOiAgICAgICAgICAgKyA8 LSBuaWQ9MjYgW2F1ZGlvIHNlbGVjdG9yXQ0KcGNtMDogICAgICAgICAgIHwNCnBjbTA6ICAgICAg ICAgICArIDwtIG5pZD0yNyBbYXVkaW8gc2VsZWN0b3JdDQpwY20wOiAgICAgICAgICAgfA0KcGNt MDogICAgICAgICAgICsgPC0gbmlkPTI4IFthdWRpbyBzZWxlY3Rvcl0NCnBjbTA6ICAgICAgICAg ICB8DQpwY20wOiAgICAgICAgICAgKyA8LSBuaWQ9MjkgW2F1ZGlvIHNlbGVjdG9yXQ0KcGNtMDog DQpwY20wOiAgICAgICAgICAgICBuaWQ6IDE1IFtBTkFMT0ddDQpwY20wOiAgICAgICAgICAgIG5h bWU6IGF1ZGlvIG1peGVyDQpwY20wOiAgICAgIHdpZGdldF9jYXA6IDB4MDAyMDAxMDANCnBjbTA6 ICAgICBQYXJzZSBmbGFnczogMHgwMDAwMDAwMg0KcGNtMDogICAgICAgQ3RsIGZsYWdzOiAweDAw MDAwMDAwDQpwY20wOiAgICAgY29ubmVjdGlvbnM6IDENCnBjbTA6ICAgICAgICAgICB8DQpwY20w OiAgICAgICAgICAgKyA8LSBuaWQ9MTEgW2F1ZGlvIHNlbGVjdG9yXQ0KcGNtMDogDQpwY20wOiAg ICAgICAgICAgICBuaWQ6IDE2IFtBTkFMT0ddDQpwY20wOiAgICAgICAgICAgIG5hbWU6IGJlZXAg d2lkZ2V0DQpwY20wOiAgICAgIHdpZGdldF9jYXA6IDB4MDA3MDAwMDANCnBjbTA6ICAgICBQYXJz ZSBmbGFnczogMHgwMDAwMDAwMA0KcGNtMDogICAgICAgQ3RsIGZsYWdzOiAweDAwMDAwMDIxDQpw Y20wOiAgICAgY29ubmVjdGlvbnM6IDANCnBjbTA6IA0KcGNtMDogICAgICAgICAgICAgbmlkOiAx NyBbQU5BTE9HXQ0KcGNtMDogICAgICAgICAgICBuYW1lOiBhdWRpbyBzZWxlY3Rvcg0KcGNtMDog ICAgICB3aWRnZXRfY2FwOiAweDAwMzAwMTBkDQpwY20wOiAgICAgUGFyc2UgZmxhZ3M6IDB4MDAw MDAwMDENCnBjbTA6ICAgICAgIEN0bCBmbGFnczogMHgwMDAwMDAxMQ0KcGNtMDogICAgICBPdXRw dXQgYW1wOiAweDgwMDUxZjE3DQpwY20wOiAgICAgICAgICAgICAgICAgIG11dGU9MSBzdGVwPTMx IHNpemU9NSBvZmZzZXQ9MjMNCnBjbTA6ICAgICBjb25uZWN0aW9uczogMQ0KcGNtMDogICAgICAg ICAgIHwNCnBjbTA6ICAgICAgICAgICArIDwtIG5pZD0zIFthdWRpbyBvdXRwdXRdDQpwY20wOiAN CnBjbTA6ICAgICAgICAgICAgIG5pZDogMTggW0FOQUxPR10NCnBjbTA6ICAgICAgICAgICAgbmFt ZTogYXVkaW8gc2VsZWN0b3INCnBjbTA6ICAgICAgd2lkZ2V0X2NhcDogMHgwMDMwMDEwZA0KcGNt MDogICAgIFBhcnNlIGZsYWdzOiAweDAwMDAwMDAyDQpwY20wOiAgICAgICBDdGwgZmxhZ3M6IDB4 MDAwMDAwODENCnBjbTA6ICAgICAgT3V0cHV0IGFtcDogMHg4MDA1MWYxNw0KcGNtMDogICAgICAg ICAgICAgICAgICBtdXRlPTEgc3RlcD0zMSBzaXplPTUgb2Zmc2V0PTIzDQpwY20wOiAgICAgY29u bmVjdGlvbnM6IDENCnBjbTA6ICAgICAgICAgICB8DQpwY20wOiAgICAgICAgICAgKyA8LSBuaWQ9 OCBbcGluOiBNaWMgaW4gKGphY2sgLyBmaXhlZCldDQpwY20wOiANCnBjbTA6ICAgICAgICAgICAg IG5pZDogMTkgW0FOQUxPR10NCnBjbTA6ICAgICAgICAgICAgbmFtZTogYXVkaW8gc2VsZWN0b3IN CnBjbTA6ICAgICAgd2lkZ2V0X2NhcDogMHgwMDMwMDEwZA0KcGNtMDogICAgIFBhcnNlIGZsYWdz OiAweDAwMDAwMDAwDQpwY20wOiAgICAgICBDdGwgZmxhZ3M6IDB4MDAwMDAwMDANCnBjbTA6ICAg ICAgT3V0cHV0IGFtcDogMHg4MDA1MWYxNw0KcGNtMDogICAgICAgICAgICAgICAgICBtdXRlPTEg c3RlcD0zMSBzaXplPTUgb2Zmc2V0PTIzDQpwY20wOiAgICAgY29ubmVjdGlvbnM6IDENCnBjbTA6 ICAgICAgICAgICB8DQpwY20wOiAgICAgICAgICAgKyA8LSBuaWQ9OSBbcGluOiBsaW5lIGluIChu b25lKV0gW0RJU0FCTEVEXQ0KcGNtMDogDQpwY20wOiAgICAgICAgICAgICBuaWQ6IDIwIFtBTkFM T0ddDQpwY20wOiAgICAgICAgICAgIG5hbWU6IHBvd2VyIHdpZGdldA0KcGNtMDogICAgICB3aWRn ZXRfY2FwOiAweDAwNTAwNTAwDQpwY20wOiAgICAgUGFyc2UgZmxhZ3M6IDB4MDAwMDAwMDANCnBj bTA6ICAgICAgIEN0bCBmbGFnczogMHgwMDAwMDAwMA0KcGNtMDogICAgIGNvbm5lY3Rpb25zOiAx Mw0KcGNtMDogICAgICAgICAgIHwNCnBjbTA6ICAgICAgICAgICArIDwtIG5pZD0xMyBbYXVkaW8g c2VsZWN0b3JdIChzZWxlY3RlZCkNCnBjbTA6ICAgICAgICAgICB8DQpwY20wOiAgICAgICAgICAg KyA8LSBuaWQ9MTQgW2F1ZGlvIG1peGVyXQ0KcGNtMDogICAgICAgICAgIHwNCnBjbTA6ICAgICAg ICAgICArIDwtIG5pZD0xNSBbYXVkaW8gbWl4ZXJdDQpwY20wOiAgICAgICAgICAgfA0KcGNtMDog ICAgICAgICAgICsgPC0gbmlkPTE2IFtiZWVwIHdpZGdldF0NCnBjbTA6ICAgICAgICAgICB8DQpw Y20wOiAgICAgICAgICAgKyA8LSBuaWQ9MTkgW2F1ZGlvIHNlbGVjdG9yXQ0KcGNtMDogICAgICAg ICAgIHwNCnBjbTA6ICAgICAgICAgICArIDwtIG5pZD0yMCBbcG93ZXIgd2lkZ2V0XQ0KcGNtMDog ICAgICAgICAgIHwNCnBjbTA6ICAgICAgICAgICArIDwtIG5pZD0yMSBbYXVkaW8gc2VsZWN0b3Jd DQpwY20wOiAgICAgICAgICAgfA0KcGNtMDogICAgICAgICAgICsgPC0gbmlkPTIyIFtwaW46IG90 aGVyIChub25lKV0gW0RJU0FCTEVEXQ0KcGNtMDogICAgICAgICAgIHwNCnBjbTA6ICAgICAgICAg ICArIDwtIG5pZD0yMyBbcGluOiBBVVggKG5vbmUpXSBbRElTQUJMRURdDQpwY20wOiAgICAgICAg ICAgfA0KcGNtMDogICAgICAgICAgICsgPC0gbmlkPTI0IFtwaW46IE1pYyBpbiAobm9uZSldIFtE SVNBQkxFRF0NCnBjbTA6ICAgICAgICAgICB8DQpwY20wOiAgICAgICAgICAgKyA8LSBuaWQ9MjUg W3BpbjogQ0QgKGZpeGVkKV0NCnBjbTA6ICAgICAgICAgICB8DQpwY20wOiAgICAgICAgICAgKyA8 LSBuaWQ9MjYgW2F1ZGlvIHNlbGVjdG9yXQ0KcGNtMDogICAgICAgICAgIHwNCnBjbTA6ICAgICAg ICAgICArIDwtIG5pZD0yOSBbYXVkaW8gc2VsZWN0b3JdDQpwY20wOiANCnBjbTA6ICAgICAgICAg ICAgIG5pZDogMjEgW0FOQUxPR10NCnBjbTA6ICAgICAgICAgICAgbmFtZTogYXVkaW8gc2VsZWN0 b3INCnBjbTA6ICAgICAgd2lkZ2V0X2NhcDogMHgwMDMwMDEwZA0KcGNtMDogICAgIFBhcnNlIGZs YWdzOiAweDAwMDAwMDA2DQpwY20wOiAgICAgICBDdGwgZmxhZ3M6IDB4MDAwMDA4MDANCnBjbTA6 ICAgICAgT3V0cHV0IGFtcDogMHg4MDA1MGYwMA0KcGNtMDogICAgICAgICAgICAgICAgICBtdXRl PTEgc3RlcD0xNSBzaXplPTUgb2Zmc2V0PTANCnBjbTA6ICAgICBjb25uZWN0aW9uczogOA0KcGNt MDogICAgICAgICAgIHwNCnBjbTA6ICAgICAgICAgICArIDwtIG5pZD0xMiBbYXVkaW8gbWl4ZXJd IChzZWxlY3RlZCkNCnBjbTA6ICAgICAgICAgICB8DQpwY20wOiAgICAgICAgICAgKyA8LSBuaWQ9 OSBbcGluOiBsaW5lIGluIChub25lKV0gW0RJU0FCTEVEXQ0KcGNtMDogICAgICAgICAgIHwNCnBj bTA6ICAgICAgICAgICArIDwtIG5pZD0xNCBbYXVkaW8gbWl4ZXJdDQpwY20wOiAgICAgICAgICAg fA0KcGNtMDogICAgICAgICAgICsgPC0gbmlkPTE1IFthdWRpbyBtaXhlcl0NCnBjbTA6ICAgICAg ICAgICB8DQpwY20wOiAgICAgICAgICAgKyA8LSBuaWQ9MjUgW3BpbjogQ0QgKGZpeGVkKV0NCnBj bTA6ICAgICAgICAgICB8DQpwY20wOiAgICAgICAgICAgKyA8LSBuaWQ9NSBbcGluOiBsaW5lIG91 dCAoamFjayAvIGZpeGVkKV0NCnBjbTA6ICAgICAgICAgICB8DQpwY20wOiAgICAgICAgICAgKyA8 LSBuaWQ9MjQgW3BpbjogTWljIGluIChub25lKV0gW0RJU0FCTEVEXQ0KcGNtMDogICAgICAgICAg IHwNCnBjbTA6ICAgICAgICAgICArIDwtIG5pZD0yMyBbcGluOiBBVVggKG5vbmUpXSBbRElTQUJM RURdDQpwY20wOiANCnBjbTA6ICAgICAgICAgICAgIG5pZDogMjIgW0FOQUxPR10gW0RJU0FCTEVE XQ0KcGNtMDogICAgICAgICAgICBuYW1lOiBwaW46IG90aGVyIChub25lKQ0KcGNtMDogICAgICB3 aWRnZXRfY2FwOiAweDAwNDAwMDAwDQpwY20wOiAgICAgUGFyc2UgZmxhZ3M6IDB4MDAwMDAwMDAN CnBjbTA6ICAgICAgIEN0bCBmbGFnczogMHgwMDAwMDAwMA0KcGNtMDogICAgICAgICBQaW4gY2Fw OiAweDAwMDAwMDIwDQpwY20wOiAgICAgICAgICAgICAgICAgIElODQpwY20wOiAgICAgIFBpbiBj b25maWc6IDB4NTlmMzExZjANCnBjbTA6ICAgICBQaW4gY29udHJvbDogMHgwMDAwMDAyMCBJTg0K cGNtMDogICAgIGNvbm5lY3Rpb25zOiAwDQpwY20wOiANCnBjbTA6ICAgICAgICAgICAgIG5pZDog MjMgW0FOQUxPR10gW0RJU0FCTEVEXQ0KcGNtMDogICAgICAgICAgICBuYW1lOiBwaW46IEFVWCAo bm9uZSkNCnBjbTA6ICAgICAgd2lkZ2V0X2NhcDogMHgwMDQwMDA4MQ0KcGNtMDogICAgIFBhcnNl IGZsYWdzOiAweDAwMDAwMDAwDQpwY20wOiAgICAgICBDdGwgZmxhZ3M6IDB4MDAwMDAwMDANCnBj bTA6ICAgICAgICAgUGluIGNhcDogMHgwMDAwMDAyNw0KcGNtMDogICAgICAgICAgICAgICAgICBJ U0MgVFJRRCBJTiA6IFVOU09MDQpwY20wOiAgICAgIFBpbiBjb25maWc6IDB4NTk5MzExZjANCnBj bTA6ICAgICBQaW4gY29udHJvbDogMHgwMDAwMDAyMCBJTg0KcGNtMDogICAgIGNvbm5lY3Rpb25z OiAwDQpwY20wOiANCnBjbTA6ICAgICAgICAgICAgIG5pZDogMjQgW0FOQUxPR10gW0RJU0FCTEVE XQ0KcGNtMDogICAgICAgICAgICBuYW1lOiBwaW46IE1pYyBpbiAobm9uZSkNCnBjbTA6ICAgICAg d2lkZ2V0X2NhcDogMHgwMDQwMDE4Nw0KcGNtMDogICAgIFBhcnNlIGZsYWdzOiAweDAwMDAwMDAw DQpwY20wOiAgICAgICBDdGwgZmxhZ3M6IDB4MDAwMDAwMDANCnBjbTA6ICAgICAgICAgUGluIGNh cDogMHgwMDAwMTczNw0KcGNtMDogICAgICAgICAgICAgICAgICBJU0MgVFJRRCBPVVQgSU4gVlJF RlsgNTAgODAgR1JPVU5EIEhJWiBdIDogVU5TT0wNCnBjbTA6ICAgICAgUGluIGNvbmZpZzogMHg0 MWExOTBmMA0KcGNtMDogICAgIFBpbiBjb250cm9sOiAweDAwMDAwMDYwIElOIE9VVA0KcGNtMDog ICAgICBPdXRwdXQgYW1wOiAweDgwMDUzZjNkDQpwY20wOiAgICAgICAgICAgICAgICAgIG11dGU9 MSBzdGVwPTYzIHNpemU9NSBvZmZzZXQ9NjENCnBjbTA6ICAgICAgIElucHV0IGFtcDogMHgwMDI3 MDMwMA0KcGNtMDogICAgICAgICAgICAgICAgICBtdXRlPTAgc3RlcD0zIHNpemU9Mzkgb2Zmc2V0 PTANCnBjbTA6ICAgICBjb25uZWN0aW9uczogMg0KcGNtMDogICAgICAgICAgIHwNCnBjbTA6ICAg ICAgICAgICArIDwtIG5pZD0zIFthdWRpbyBvdXRwdXRdDQpwY20wOiAgICAgICAgICAgfA0KcGNt MDogICAgICAgICAgICsgPC0gbmlkPTE0IFthdWRpbyBtaXhlcl0NCnBjbTA6IA0KcGNtMDogICAg ICAgICAgICAgbmlkOiAyNSBbQU5BTE9HXQ0KcGNtMDogICAgICAgICAgICBuYW1lOiBwaW46IENE IChmaXhlZCkNCnBjbTA6ICAgICAgd2lkZ2V0X2NhcDogMHgwMDQwMDAwMQ0KcGNtMDogICAgIFBh cnNlIGZsYWdzOiAweDAwMDAwMDAyDQpwY20wOiAgICAgICBDdGwgZmxhZ3M6IDB4MDAwMDAxMDEN CnBjbTA6ICAgICAgICAgUGluIGNhcDogMHgwMDAwMDAyMA0KcGNtMDogICAgICAgICAgICAgICAg ICBJTg0KcGNtMDogICAgICBQaW4gY29uZmlnOiAweDk5MzNlMTIwDQpwY20wOiAgICAgUGluIGNv bnRyb2w6IDB4MDAwMDAwMjAgSU4NCnBjbTA6ICAgICBjb25uZWN0aW9uczogMA0KcGNtMDogDQpw Y20wOiAgICAgICAgICAgICBuaWQ6IDI2IFtBTkFMT0ddDQpwY20wOiAgICAgICAgICAgIG5hbWU6 IGF1ZGlvIHNlbGVjdG9yDQpwY20wOiAgICAgIHdpZGdldF9jYXA6IDB4MDAzMDAxMGQNCnBjbTA6 ICAgICBQYXJzZSBmbGFnczogMHgwMDAwMDAwMA0KcGNtMDogICAgICAgQ3RsIGZsYWdzOiAweDAw MDAwMDAwDQpwY20wOiAgICAgIE91dHB1dCBhbXA6IDB4ODAwNTFmMTcNCnBjbTA6ICAgICAgICAg ICAgICAgICAgbXV0ZT0xIHN0ZXA9MzEgc2l6ZT01IG9mZnNldD0yMw0KcGNtMDogICAgIGNvbm5l Y3Rpb25zOiAxDQpwY20wOiAgICAgICAgICAgfA0KcGNtMDogICAgICAgICAgICsgPC0gbmlkPTUg W3BpbjogbGluZSBvdXQgKGphY2sgLyBmaXhlZCldDQpwY20wOiANCnBjbTA6ICAgICAgICAgICAg IG5pZDogMjcgW0FOQUxPR10NCnBjbTA6ICAgICAgICAgICAgbmFtZTogYXVkaW8gc2VsZWN0b3IN CnBjbTA6ICAgICAgd2lkZ2V0X2NhcDogMHgwMDMwMDEwZA0KcGNtMDogICAgIFBhcnNlIGZsYWdz OiAweDAwMDAwMDAwDQpwY20wOiAgICAgICBDdGwgZmxhZ3M6IDB4MDAwMDAwMDANCnBjbTA6ICAg ICAgT3V0cHV0IGFtcDogMHg4MDA1MWYxNw0KcGNtMDogICAgICAgICAgICAgICAgICBtdXRlPTEg c3RlcD0zMSBzaXplPTUgb2Zmc2V0PTIzDQpwY20wOiAgICAgY29ubmVjdGlvbnM6IDENCnBjbTA6 ICAgICAgICAgICB8DQpwY20wOiAgICAgICAgICAgKyA8LSBuaWQ9MjMgW3BpbjogQVVYIChub25l KV0gW0RJU0FCTEVEXQ0KcGNtMDogDQpwY20wOiAgICAgICAgICAgICBuaWQ6IDI4IFtBTkFMT0dd DQpwY20wOiAgICAgICAgICAgIG5hbWU6IGF1ZGlvIHNlbGVjdG9yDQpwY20wOiAgICAgIHdpZGdl dF9jYXA6IDB4MDAzMDAxMGQNCnBjbTA6ICAgICBQYXJzZSBmbGFnczogMHgwMDAwMDAwMA0KcGNt MDogICAgICAgQ3RsIGZsYWdzOiAweDAwMDAwMDAwDQpwY20wOiAgICAgIE91dHB1dCBhbXA6IDB4 ODAwNTFmMTcNCnBjbTA6ICAgICAgICAgICAgICAgICAgbXV0ZT0xIHN0ZXA9MzEgc2l6ZT01IG9m ZnNldD0yMw0KcGNtMDogICAgIGNvbm5lY3Rpb25zOiAxDQpwY20wOiAgICAgICAgICAgfA0KcGNt MDogICAgICAgICAgICsgPC0gbmlkPTI0IFtwaW46IE1pYyBpbiAobm9uZSldIFtESVNBQkxFRF0N CnBjbTA6IA0KcGNtMDogICAgICAgICAgICAgbmlkOiAyOSBbQU5BTE9HXQ0KcGNtMDogICAgICAg ICAgICBuYW1lOiBhdWRpbyBzZWxlY3Rvcg0KcGNtMDogICAgICB3aWRnZXRfY2FwOiAweDAwMzAw MTBkDQpwY20wOiAgICAgUGFyc2UgZmxhZ3M6IDB4MDAwMDAwMDINCnBjbTA6ICAgICAgIEN0bCBm bGFnczogMHgwMDAwMDEwMQ0KcGNtMDogICAgICBPdXRwdXQgYW1wOiAweDgwMDUxZjE3DQpwY20w OiAgICAgICAgICAgICAgICAgIG11dGU9MSBzdGVwPTMxIHNpemU9NSBvZmZzZXQ9MjMNCnBjbTA6 ICAgICBjb25uZWN0aW9uczogMQ0KcGNtMDogICAgICAgICAgIHwNCnBjbTA6ICAgICAgICAgICAr IDwtIG5pZD0yNSBbcGluOiBDRCAoZml4ZWQpXQ0KcGNtMDogDQpwY20wOiAgICAgICAgICAgICBu aWQ6IDMwIFtBTkFMT0ddDQpwY20wOiAgICAgICAgICAgIG5hbWU6IGF1ZGlvIHNlbGVjdG9yDQpw Y20wOiAgICAgIHdpZGdldF9jYXA6IDB4MDAzMDAxMGQNCnBjbTA6ICAgICBQYXJzZSBmbGFnczog MHgwMDAwMDAwMg0KcGNtMDogICAgICAgQ3RsIGZsYWdzOiAweDAwMDAwMDAwDQpwY20wOiAgICAg IE91dHB1dCBhbXA6IDB4ODAwMDAwMDANCnBjbTA6ICAgICAgICAgICAgICAgICAgbXV0ZT0xIHN0 ZXA9MCBzaXplPTAgb2Zmc2V0PTANCnBjbTA6ICAgICBjb25uZWN0aW9uczogMQ0KcGNtMDogICAg ICAgICAgIHwNCnBjbTA6ICAgICAgICAgICArIDwtIG5pZD04IFtwaW46IE1pYyBpbiAoamFjayAv IGZpeGVkKV0NCnBjbTA6IA0KcGNtMDogICAgICAgICAgICAgbmlkOiAzMSBbQU5BTE9HXQ0KcGNt MDogICAgICAgICAgICBuYW1lOiBhdWRpbyBzZWxlY3Rvcg0KcGNtMDogICAgICB3aWRnZXRfY2Fw OiAweDAwMzAwMTBkDQpwY20wOiAgICAgUGFyc2UgZmxhZ3M6IDB4MDAwMDAwMDANCnBjbTA6ICAg ICAgIEN0bCBmbGFnczogMHgwMDAwMDAwMA0KcGNtMDogICAgICBPdXRwdXQgYW1wOiAweDgwMDAw MDAwDQpwY20wOiAgICAgICAgICAgICAgICAgIG11dGU9MSBzdGVwPTAgc2l6ZT0wIG9mZnNldD0w DQpwY20wOiAgICAgY29ubmVjdGlvbnM6IDENCnBjbTA6ICAgICAgICAgICB8DQpwY20wOiAgICAg ICAgICAgKyA8LSBuaWQ9MjQgW3BpbjogTWljIGluIChub25lKV0gW0RJU0FCTEVEXQ0KcGNtMDog DQpwY20wOiArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KcGNtMDogfCBEVU1QSU5HIEhEQSBB TVBMSUZJRVJTIHwNCnBjbTA6ICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQpwY20wOiANCnBj bTA6ICAgMTogbmlkPTUgZGlyPTB4MSBpbmRleD0wIG9zc21hc2s9MHgwMDAwMDAwMCBvc3NkZXY9 MA0KcGNtMDogICAyOiBuaWQ9NSBkaXI9MHgyIGluZGV4PTAgb3NzbWFzaz0weDAwMDAwMDAwIG9z c2Rldj0wDQpwY20wOiAgIDM6IG5pZD02IGRpcj0weDEgaW5kZXg9MCBvc3NtYXNrPTB4MDAwMDAw MDAgb3NzZGV2PTAgW0RJU0FCTEVEXQ0KcGNtMDogICA0OiBuaWQ9NyBkaXI9MHgxIGluZGV4PTAg b3NzbWFzaz0weDAwMDAwMDAwIG9zc2Rldj0wIFtESVNBQkxFRF0NCnBjbTA6ICAgNTogbmlkPTgg ZGlyPTB4MiBpbmRleD0wIG9zc21hc2s9MHgwMDAwMDAwMCBvc3NkZXY9MA0KcGNtMDogICA2OiBu aWQ9OSBkaXI9MHgxIGluZGV4PTAgb3NzbWFzaz0weDAwMDAwMDAwIG9zc2Rldj0wIFtESVNBQkxF RF0NCnBjbTA6ICAgNzogbmlkPTkgZGlyPTB4MiBpbmRleD0wIG9zc21hc2s9MHgwMDAwMDAwMCBv c3NkZXY9MCBbRElTQUJMRURdDQpwY20wOiAgIDg6IG5pZD0xMyBkaXI9MHgxIGluZGV4PTAgb3Nz bWFzaz0weDAwMDAwMDIxIG9zc2Rldj01DQpwY20wOiAgIDk6IG5pZD0xNyBkaXI9MHgxIGluZGV4 PTAgb3NzbWFzaz0weDAwMDAwMDExIG9zc2Rldj00DQpwY20wOiAgMTA6IG5pZD0xOCBkaXI9MHgx IGluZGV4PTAgb3NzbWFzaz0weDAwMDAwMDgxIG9zc2Rldj03DQpwY20wOiAgMTE6IG5pZD0xOSBk aXI9MHgxIGluZGV4PTAgb3NzbWFzaz0weDAwMDAwMDAwIG9zc2Rldj0wDQpwY20wOiAgMTI6IG5p ZD0yMSBkaXI9MHgxIGluZGV4PTAgb3NzbWFzaz0weDAwMDAwODAwIG9zc2Rldj0wDQpwY20wOiAg MTM6IG5pZD0yNCBkaXI9MHgxIGluZGV4PTAgb3NzbWFzaz0weDAwMDAwMDAwIG9zc2Rldj0wIFtE SVNBQkxFRF0NCnBjbTA6ICAxNDogbmlkPTI0IGRpcj0weDIgaW5kZXg9MCBvc3NtYXNrPTB4MDAw MDAwMDAgb3NzZGV2PTAgW0RJU0FCTEVEXQ0KcGNtMDogIDE1OiBuaWQ9MjYgZGlyPTB4MSBpbmRl eD0wIG9zc21hc2s9MHgwMDAwMDAwMCBvc3NkZXY9MA0KcGNtMDogIDE2OiBuaWQ9MjcgZGlyPTB4 MSBpbmRleD0wIG9zc21hc2s9MHgwMDAwMDAwMCBvc3NkZXY9MA0KcGNtMDogIDE3OiBuaWQ9Mjgg ZGlyPTB4MSBpbmRleD0wIG9zc21hc2s9MHgwMDAwMDAwMCBvc3NkZXY9MA0KcGNtMDogIDE4OiBu aWQ9MjkgZGlyPTB4MSBpbmRleD0wIG9zc21hc2s9MHgwMDAwMDEwMSBvc3NkZXY9OA0KcGNtMDog IDE5OiBuaWQ9MzAgZGlyPTB4MSBpbmRleD0wIG9zc21hc2s9MHgwMDAwMDAwMCBvc3NkZXY9MA0K cGNtMDogIDIwOiBuaWQ9MzEgZGlyPTB4MSBpbmRleD0wIG9zc21hc2s9MHgwMDAwMDAwMCBvc3Nk ZXY9MA0KcGNtMDogDQpwY20wOiArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0r DQpwY20wOiB8IERVTVBJTkcgSERBIEFVRElPL1ZPTFVNRSBDT05UUk9MUyB8DQpwY20wOiArLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQpwY20wOiANCnBjbTA6IE1hc3RlciBW b2x1bWUgKE9TUzogdm9sKQ0KcGNtMDogICAgfA0KcGNtMDogICAgKy0gIG5pZDogMTMgaW5kZXg6 ICAwICAgICAgICAgICBtdXRlOiAxIHN0ZXA6ICAxNSBzaXplOiAgMTEgb2ZmOiAgMTUgZGlyPTB4 MSBvc3NtYXNrPTB4MDAwMDAwMjENCnBjbTA6ICAgIHwNCnBjbTA6ICAgICstICBuaWQ6IDE3IGlu ZGV4OiAgMCAgICAgICAgICAgbXV0ZTogMSBzdGVwOiAgMzEgc2l6ZTogICA1IG9mZjogIDIzIGRp cj0weDEgb3NzbWFzaz0weDAwMDAwMDExDQpwY20wOiAgICB8DQpwY20wOiAgICArLSAgbmlkOiAx OCBpbmRleDogIDAgICAgICAgICAgIG11dGU6IDEgc3RlcDogIDMxIHNpemU6ICAgNSBvZmY6ICAy MyBkaXI9MHgxIG9zc21hc2s9MHgwMDAwMDA4MQ0KcGNtMDogICAgfA0KcGNtMDogICAgKy0gIG5p ZDogMjkgaW5kZXg6ICAwICAgICAgICAgICBtdXRlOiAxIHN0ZXA6ICAzMSBzaXplOiAgIDUgb2Zm OiAgMjMgZGlyPTB4MSBvc3NtYXNrPTB4MDAwMDAxMDENCnBjbTA6IA0KcGNtMDogUENNIFZvbHVt ZSAoT1NTOiBwY20pDQpwY20wOiAgICB8DQpwY20wOiAgICArLSAgbmlkOiAxNyBpbmRleDogIDAg ICAgICAgICAgIG11dGU6IDEgc3RlcDogIDMxIHNpemU6ICAgNSBvZmY6ICAyMyBkaXI9MHgxIG9z c21hc2s9MHgwMDAwMDAxMQ0KcGNtMDogDQpwY20wOiBDRCBWb2x1bWUgKE9TUzogY2QpDQpwY20w OiAgICB8DQpwY20wOiAgICArLSAgbmlkOiAyOSBpbmRleDogIDAgICAgICAgICAgIG11dGU6IDEg c3RlcDogIDMxIHNpemU6ICAgNSBvZmY6ICAyMyBkaXI9MHgxIG9zc21hc2s9MHgwMDAwMDEwMQ0K cGNtMDogDQpwY20wOiBNaWNyb3Bob25lIFZvbHVtZSAoT1NTOiBtaWMpDQpwY20wOiAgICB8DQpw Y20wOiAgICArLSAgbmlkOiAxOCBpbmRleDogIDAgICAgICAgICAgIG11dGU6IDEgc3RlcDogIDMx IHNpemU6ICAgNSBvZmY6ICAyMyBkaXI9MHgxIG9zc21hc2s9MHgwMDAwMDA4MQ0KcGNtMDogDQpw Y20wOiBSZWNvcmRpbmcgTGV2ZWwgKE9TUzogcmVjKQ0KcGNtMDogICAgfA0KcGNtMDogICAgKy0g IG5pZDogMjEgaW5kZXg6ICAwICAgICAgICAgICBtdXRlOiAxIHN0ZXA6ICAxNSBzaXplOiAgIDUg b2ZmOiAgIDAgZGlyPTB4MSBvc3NtYXNrPTB4MDAwMDA4MDANCnBjbTA6IA0KcGNtMDogU3BlYWtl ci9CZWVwIChPU1M6IHNwZWFrZXIpDQpwY20wOiAgICB8DQpwY20wOiAgICArLSAgbmlkOiAxMyBp bmRleDogIDAgICAgICAgICAgIG11dGU6IDEgc3RlcDogIDE1IHNpemU6ICAxMSBvZmY6ICAxNSBk aXI9MHgxIG9zc21hc2s9MHgwMDAwMDAyMQ0KcGNtMDogDQpwY20wOiBQbGF5YmFjayBwYXRoOg0K cGNtMDogDQpwY20wOiAgICAgbmlkPTUgW3BpbjogbGluZSBvdXQgKGphY2sgLyBmaXhlZCldDQpw Y20wOiAgICAgICBeDQpwY20wOiAgICAgICB8DQpwY20wOiAgICAgICArLS0tLS08LS0tLS0tKw0K cGNtMDogICAgICAgICAgICAgICAgICAgIF4NCnBjbTA6ICAgICAgICAgICAgICAgICAgICB8DQpw Y20wOiAgICAgICAgICAgICAgICAgIG5pZD0xNCBbYXVkaW8gbWl4ZXJdDQpwY20wOiAgICAgICAg ICAgICAgICAgICAgXg0KcGNtMDogICAgICAgICAgICAgICAgICAgIHwNCnBjbTA6ICAgICAgICAg ICAgICAgICAgbmlkPTE3IFthdWRpbyBzZWxlY3Rvcl0NCnBjbTA6ICAgICAgICAgICAgICAgICAg ICBeDQpwY20wOiAgICAgICAgICAgICAgICAgICAgfA0KcGNtMDogICAgICAgICAgICAgICAgICBu aWQ9MyBbYXVkaW8gb3V0cHV0XQ0KcGNtMDogDQpwY20wOiBSZWNvcmRpbmcgc291cmNlczoNCnBj bTA6IA0KcGNtMDogICAgIG5pZD0yMSBbYXVkaW8gc2VsZWN0b3JdDQpwY20wOiAgICAgICB8DQpw Y20wOiAgICAgICArIDwtIG5pZD0xMiBbYXVkaW8gbWl4ZXJdDQpwY20wOiAgICAgICB8DQpwY20w OiAgICAgICArIDwtIG5pZD0xNCBbYXVkaW8gbWl4ZXJdIFtyZWNzcmM6IHZvbCwgcGNtLCBzcGVh a2VyLCBtaWMsIGNkXQ0KcGNtMDogICAgICAgfA0KcGNtMDogICAgICAgKyA8LSBuaWQ9MTUgW2F1 ZGlvIG1peGVyXQ0KcGNtMDogICAgICAgfA0KcGNtMDogICAgICAgKyA8LSBuaWQ9MjUgW3Bpbjog Q0QgKGZpeGVkKV0gW3JlY3NyYzogdm9sLCBjZF0NCnBjbTA6ICAgICAgIHwNCnBjbTA6ICAgICAg ICsgPC0gbmlkPTUgW3BpbjogbGluZSBvdXQgKGphY2sgLyBmaXhlZCldDQpwY20wOiANCnBjbTA6 ICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCnBjbTA6IHwgRFVNUElO RyBQQ00gUGxheWJhY2svUmVjb3JkIENoYW5uZWxzIHwNCnBjbTA6ICstLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCnBjbTA6IA0KcGNtMDogICAgUENNIFBsYXliYWNrOiAx DQpwY20wOiAgICAgIFN0cmVhbSBjYXA6IDB4MDAwMDAwMDENCnBjbTA6ICAgICAgICAgIEZvcm1h dDogUENNDQpwY20wOiAgICAgICAgIFBDTSBjYXA6IDB4MDAwZTAwN2YNCnBjbTA6ICAgICAgICBQ Q00gc2l6ZTogMTYgMjAgMjQNCnBjbTA6ICAgICAgICBQQ00gcmF0ZTogOCAxMSAxNiAyMiAzMiA0 NCA0OA0KcGNtMDogICAgICAgICAgICAgREFDOiAzDQpwY20wOiANCnBjbTA6ICAgICAgUENNIFJl Y29yZDogMQ0KcGNtMDogICAgICBTdHJlYW0gY2FwOiAweDAwMDAwMDAxDQpwY20wOiAgICAgICAg ICBGb3JtYXQ6IFBDTQ0KcGNtMDogICAgICAgICBQQ00gY2FwOiAweDAwMDYwMDdmDQpwY20wOiAg ICAgICAgUENNIHNpemU6IDE2IDIwDQpwY20wOiAgICAgICAgUENNIHJhdGU6IDggMTEgMTYgMjIg MzIgNDQgNDgNCnBjbTA6ICAgICAgICAgICAgIEFEQzogNA0KU01QOiBBUCBDUFUgIzEgTGF1bmNo ZWQhDQpjcHUxIEFQOg0KICAgICBJRDogMHgwMTAwMDAwMCAgIFZFUjogMHgwMDA1MDAxNCBMRFI6 IDB4MDAwMDAwMDAgREZSOiAweGZmZmZmZmZmDQogIGxpbnQwOiAweDAwMDEwNzAwIGxpbnQxOiAw eDAwMDAwNDAwIFRQUjogMHgwMDAwMDAwMCBTVlI6IDB4MDAwMDAxZmYNCiAgdGltZXI6IDB4MDAw MjAwZWYgdGhlcm06IDB4MDAwMTAyMDAgZXJyOiAweDAwMDEwMDAwIHBjbTogMHgwMDAxMDAwMA0K aW9hcGljMDogQXNzaWduaW5nIElTQSBJUlEgMSB0byBsb2NhbCBBUElDIDANCmlvYXBpYzA6IEFz c2lnbmluZyBJU0EgSVJRIDMgdG8gbG9jYWwgQVBJQyAxDQppb2FwaWMwOiBBc3NpZ25pbmcgSVNB IElSUSA5IHRvIGxvY2FsIEFQSUMgMA0KaW9hcGljMDogQXNzaWduaW5nIElTQSBJUlEgMTIgdG8g bG9jYWwgQVBJQyAxDQppb2FwaWMwOiBBc3NpZ25pbmcgSVNBIElSUSAxNCB0byBsb2NhbCBBUElD IDANCmlvYXBpYzA6IEFzc2lnbmluZyBJU0EgSVJRIDE1IHRvIGxvY2FsIEFQSUMgMQ0KaW9hcGlj MDogQXNzaWduaW5nIFBDSSBJUlEgMTYgdG8gbG9jYWwgQVBJQyAwDQppb2FwaWMwOiBBc3NpZ25p bmcgUENJIElSUSAxNyB0byBsb2NhbCBBUElDIDENCmlvYXBpYzA6IEFzc2lnbmluZyBQQ0kgSVJR IDE4IHRvIGxvY2FsIEFQSUMgMA0KaW9hcGljMDogQXNzaWduaW5nIFBDSSBJUlEgMTkgdG8gbG9j YWwgQVBJQyAxDQptc2k6IEFzc2lnbmluZyBNU0kgSVJRIDI1NiB0byBsb2NhbCBBUElDIDANCkdF T006IG5ldyBkaXNrIGFkMA0KR0VPTV9MQUJFTDogTGFiZWwgZm9yIHByb3ZpZGVyIGFkMHMxIGlz IG50ZnMvV2luZG93cy4NCkdFT01fTEFCRUw6IExhYmVsIGZvciBwcm92aWRlciBhZDBzMyBpcyBt c2Rvc2ZzL0RBVEEuDQpUcnlpbmcgdG8gbW91bnQgcm9vdCBmcm9tIHVmczovZGV2L2FkMHMyYQ0K c3RhcnRfaW5pdDogdHJ5aW5nIC9zYmluL2luaXQNCkdFT01fTEFCRUw6IExhYmVsIG1zZG9zZnMv REFUQSByZW1vdmVkLg0KbGlucHJvY2ZzIHJlZ2lzdGVyZWQNCldBUk5JTkc6IGF0dGVtcHQgdG8g bmV0X2FkZF9kb21haW4oYmx1ZXRvb3RoKSBhZnRlciBkb21haW5maW5hbGl6ZSgpDQpXQVJOSU5H OiBhdHRlbXB0IHRvIG5ldF9hZGRfZG9tYWluKG5ldGdyYXBoKSBhZnRlciBkb21haW5maW5hbGl6 ZSgpDQplbTA6IExpbmsgaXMgdXAgMTAwIE1icHMgRnVsbCBEdXBsZXgNCmVtMDogbGluayBzdGF0 ZSBjaGFuZ2VkIHRvIFVQDQphcnA6IDAwOjAxOjAzOmQ2OjllOjlmIGlzIHVzaW5nIG15IElQIGFk ZHJlc3MgMTkyLjE2OC4xLjExMSENClRDUDogWzE5Mi4xNjguMC4xMDBdOjQ1NDk3IHRvIFsxOTIu MTY4LjEuMTExXToxMzkgdGNwZmxhZ3MgMHgxMTxGSU4sQUNLPjsgc3luY2FjaGVfZXhwYW5kOiBT ZWdtZW50IGZhaWxlZCBTWU5DT09LSUUgYXV0aGVudGljYXRpb24sIHNlZ21lbnQgcmVqZWN0ZWQg KHByb2JhYmx5IHNwb29mZWQpDQpwY20wOiBIREFfREVCVUc6IFBDTURJUl9QTEFZOiBTdHJlYW0g c2V0dXAgbmlkPTMgZm10PTB4MDAwMDAwMTENCi== --=-ZdFHW9IuT3ROeLbPzQWB Content-Disposition: attachment; filename=usbdevs-v-d Content-Type: text/plain; name=usbdevs-v-d; charset=KOI8-R Content-Transfer-Encoding: base64 Q29udHJvbGxlciAvZGV2L3VzYjA6DQphZGRyIDE6IGZ1bGwgc3BlZWQsIHNlbGYgcG93ZXJlZCwg Y29uZmlnIDEsIFVIQ0kgcm9vdCBodWIoMHgwMDAwKSwgSW50ZWwoMHgwMDAwKSwgcmV2IDEuMDAN CiAgdWh1YjANCiBwb3J0IDEgcG93ZXJlZA0KIHBvcnQgMiBwb3dlcmVkDQpDb250cm9sbGVyIC9k ZXYvdXNiMToNCmFkZHIgMTogZnVsbCBzcGVlZCwgc2VsZiBwb3dlcmVkLCBjb25maWcgMSwgVUhD SSByb290IGh1YigweDAwMDApLCBJbnRlbCgweDAwMDApLCByZXYgMS4wMA0KICB1aHViMQ0KIHBv cnQgMSBwb3dlcmVkDQogcG9ydCAyIHBvd2VyZWQNCkNvbnRyb2xsZXIgL2Rldi91c2IyOg0KYWRk ciAxOiBmdWxsIHNwZWVkLCBzZWxmIHBvd2VyZWQsIGNvbmZpZyAxLCBVSENJIHJvb3QgaHViKDB4 MDAwMCksIEludGVsKDB4MDAwMCksIHJldiAxLjAwDQogIHVodWIyDQogcG9ydCAxIHBvd2VyZWQN CiBwb3J0IDIgcG93ZXJlZA0KQ29udHJvbGxlciAvZGV2L3VzYjM6DQphZGRyIDE6IGZ1bGwgc3Bl ZWQsIHNlbGYgcG93ZXJlZCwgY29uZmlnIDEsIFVIQ0kgcm9vdCBodWIoMHgwMDAwKSwgSW50ZWwo MHgwMDAwKSwgcmV2IDEuMDANCiAgdWh1YjMNCiBwb3J0IDEgYWRkciAyOiBmdWxsIHNwZWVkLCBz ZWxmIHBvd2VyZWQsIGNvbmZpZyAxLCBCQ00yMDQ1QigweDIxMTApLCBCcm9hZGNvbSBDb3JwKDB4 MGE1YyksIHJldiAxLjAwDQogICB1YnQwDQogcG9ydCAyIGFkZHIgMzogZnVsbCBzcGVlZCwgcG93 ZXIgMTAwIG1BLCBjb25maWcgMSwgQmlvbWV0cmljIENvcHJvY2Vzc29yKDB4MjAxNiksIFNUTWlj cm9lbGVjdHJvbmljcygweDA0ODMpLCByZXYgMC4wMQ0KICAgdWdlbjANCkNvbnRyb2xsZXIgL2Rl di91c2I0Og0KYWRkciAxOiBoaWdoIHNwZWVkLCBzZWxmIHBvd2VyZWQsIGNvbmZpZyAxLCBFSENJ IHJvb3QgaHViKDB4MDAwMCksIEludGVsKDB4MDAwMCksIHJldiAxLjAwDQogIHVodWI0DQogcG9y dCAxIHBvd2VyZWQNCiBwb3J0IDIgcG93ZXJlZA0KIHBvcnQgMyBwb3dlcmVkDQogcG9ydCA0IHBv d2VyZWQNCiBwb3J0IDUgcG93ZXJlZA0KIHBvcnQgNiBhZGRyIDI6IGhpZ2ggc3BlZWQsIHNlbGYg cG93ZXJlZCwgY29uZmlnIDEsIHByb2R1Y3QgMHg0NDg2KDB4NDQ4NiksIHZlbmRvciAweDA0YjMo MHgwNGIzKSwgcmV2IDAuMDENCiAgIHVodWI1DQogIHBvcnQgMSBwb3dlcmVkDQogIHBvcnQgMiBw b3dlcmVkDQogIHBvcnQgMyBwb3dlcmVkDQogIHBvcnQgNCBwb3dlcmVkDQogIHBvcnQgNSBhZGRy IDM6IGxvdyBzcGVlZCwgcG93ZXIgMTAwIG1BLCBjb25maWcgMSwgVVNCIEtNcCgweDY3ODIpLCBC VEMoMHgwNDZlKSwgcmV2IDEuMDANCiAgICB1aGlkZXYwDQogICAgdWhpZGV2MQ0KICBwb3J0IDYg cG93ZXJlZA0KICBwb3J0IDcgYWRkciA0OiBsb3cgc3BlZWQsIHBvd2VyIDEwMCBtQSwgY29uZmln IDEsIE1pY3Jvc29mdCA1LUJ1dHRvbiBNb3VzZSB3aXRoIEludGVsbGlFeWUoVE0pKDB4MDA0Nyks IE1pY3Jvc29mdCgweDA0NWUpLCByZXYgMy4wMA0KICAgIHVoaWRldjINCiBwb3J0IDcgcG93ZXJl ZA0KIHBvcnQgOCBwb3dlcmVkDQo= --=-ZdFHW9IuT3ROeLbPzQWB-- From owner-freebsd-current@FreeBSD.ORG Fri Jul 20 15:58:36 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B16AB16A41A for ; Fri, 20 Jul 2007 15:58:36 +0000 (UTC) (envelope-from staale@kristoffersen.ws) Received: from smtp.bluecom.no (smtp.bluecom.no [193.75.75.28]) by mx1.freebsd.org (Postfix) with ESMTP id 705F013C467 for ; Fri, 20 Jul 2007 15:58:36 +0000 (UTC) (envelope-from staale@kristoffersen.ws) Received: from eschew.pusen.org (unknown [193.69.145.10]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.bluecom.no (Postfix) with ESMTP id 2B73416F62C; Fri, 20 Jul 2007 17:58:35 +0200 (CEST) Received: from chiller by eschew.pusen.org with local (Exim 4.50) id 1IBusJ-0003HF-Fl; Fri, 20 Jul 2007 17:58:39 +0200 Date: Fri, 20 Jul 2007 17:58:39 +0200 From: =?iso-8859-1?Q?St=E5le?= Kristoffersen To: Andrew Gallatin Message-ID: <20070720155839.GA2241@eschew.pusen.org> References: <20070716190441.GA19282@eschew.pusen.org> <20070716213425.GB19282@eschew.pusen.org> <20070716233600.GC19282@eschew.pusen.org> <18079.31350.366410.316438@grasshopper.cs.duke.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <18079.31350.366410.316438@grasshopper.cs.duke.edu> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: current@freebsd.org Subject: Re: Slow networkperformance in current? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2007 15:58:36 -0000 On 2007-07-19 at 10:51, Andrew Gallatin wrote: > > Ståle Kristoffersen writes: > > On 2007-07-16 at 15:53, Kip Macy wrote: > > > Please post the config you are using. > > > > lrwxr-xr-x 1 root wheel 2B Apr 12 15:42 /etc/malloc.conf -> aj > > > > /etc/sysctl.conf: > > vfs.vmiodirenable=1 > > net.inet.tcp.delayed_ack=0 > > net.inet.ip.forwarding=1 > > net.inet.tcp.inflight.enable=0 > > > > (I have tried commenting out all those lines, no difference. > > You definately want to comment out at least net.inet.tcp.delayed_ack=0 Ok, didn't do much for the speed. > Try temporarily setting net.inet.tcp.sendbuf_auto=0 and > net.inet.tcp.recvbuf_auto=0 and see if that changes anything. > > I've seen strange issues with IPv6 and the automatic buffer sizing, > perhaps you're somehow running into the same thing with IPv4. No change in the speed. -- Ståle Kristoffersen staalebk@ifi.uio.no From owner-freebsd-current@FreeBSD.ORG Fri Jul 20 16:51:23 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B461416A469 for ; Fri, 20 Jul 2007 16:51:23 +0000 (UTC) (envelope-from kereoz@free.fr) Received: from smtp5-g19.free.fr (smtp5-g19.free.fr [212.27.42.35]) by mx1.freebsd.org (Postfix) with ESMTP id 8084313C4A5 for ; Fri, 20 Jul 2007 16:51:23 +0000 (UTC) (envelope-from kereoz@free.fr) Received: from [192.168.0.1] (pat35-3-82-245-141-208.fbx.proxad.net [82.245.141.208]) by smtp5-g19.free.fr (Postfix) with ESMTP id 096C84516A for ; Fri, 20 Jul 2007 18:51:21 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: current@freebsd.org From: Christophe H Date: Fri, 20 Jul 2007 18:51:20 +0200 X-Mailer: Apple Mail (2.752.3) Cc: Subject: Upgrade X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Jul 2007 16:51:23 -0000 Hello, I just installed 7-CURRENT from Nov 2006, and I would like to upgrade it. What is the best way to do this ? Is it possible to do a binary upgrade ? Thanks, Chris From owner-freebsd-current@FreeBSD.ORG Fri Jul 20 16:52:11 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D3ECC16A419 for ; Fri, 20 Jul 2007 16:52:11 +0000 (UTC) (envelope-from kereoz@free.fr) Received: from smtp5-g19.free.fr (smtp5-g19.free.fr [212.27.42.35]) by mx1.freebsd.org (Postfix) with ESMTP id 92C3E13C51A for ; Fri, 20 Jul 2007 16:52:11 +0000 (UTC) (envelope-from kereoz@free.fr) Received: from [192.168.0.1] (pat35-3-82-245-141-208.fbx.proxad.net [82.245.141.208]) by smtp5-g19.free.fr (Postfix) with ESMTP id C132C45108 for ; Fri, 20 Jul 2007 18:52:10 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8E05E588-32AD-4D23-8113-2D3428DBE5BA@free.fr> Content-Transfer-Encoding: 7bit From: Christophe H Date: Fri, 20 Jul 2007 18:52:10 +0200 To: current@freebsd.org X-Mailer: Apple Mail (2.752.3) Cc: Subject: Re: Panic on a Core Duo Macbook pro X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Jul 2007 16:52:11 -0000 > > On Jul 19, 2007, at 2:19 PM, Ian FREISLICH wrote: > >> Eric Anderson wrote: >>> Christophe H wrote: >>>> Hello, >>>> >>>> when I try to boot the latest snapshot of 7-current on my Core Duo >>>> Macbook pro (r 1.1), I get a panic : >>>> AP#1 (PHY#1) failed ! >>>> Panic >>>> >>>> while FreeBSD 6.2-release can boot. >>>> >>>> Is there a way to give some kernel options at boot to avoid this ? >>> >>> >>> Same here with my Macbook Pro. I tried some hints from Rui >>> Paulo, with >>> no success. Was that an i386 snapshot, or AMD64? > > Yes it was an i386 snapshot. > >> >> Have you tried pressing any key on the keyboard before the boot >> gets to this point? At the copyright does it for me. >> >> Ian >> >> -- >> Ian Freislich >> > > When I press keys on the keybord it works, but later I get this : > Panic : going nowhere without my init ! > CPUID=0 > KDB : enter : Panic > [ Thread pid 1 tid 100006 ] > Stopped at kdb_enter + 0x32 : leave > > and I get a shell like this : > db> > > >> _______________________________________________ >> 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 Jul 20 18:07:41 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E5EAA16A419; Fri, 20 Jul 2007 18:07:41 +0000 (UTC) (envelope-from kramer@centtech.com) Received: from mh1.centtech.com (moat3.centtech.com [64.129.166.50]) by mx1.freebsd.org (Postfix) with ESMTP id B74A513C474; Fri, 20 Jul 2007 18:07:41 +0000 (UTC) (envelope-from kramer@centtech.com) Received: from edberg.centtech.com (edberg.centtech.com [10.20.200.80]) by mh1.centtech.com (8.13.8/8.13.8) with ESMTP id l6KI7dH7021196; Fri, 20 Jul 2007 13:07:39 -0500 (CDT) (envelope-from kramer@centtech.com) Message-ID: <46A0F9FB.5050305@centtech.com> Date: Fri, 20 Jul 2007 13:07:55 -0500 From: Kevin Kramer User-Agent: Thunderbird 2.0.0.4 (X11/20070718) MIME-Version: 1.0 To: Eric Anderson References: <469E3B7C.4020402@centtech.com> <46A09F02.9020302@freebsd.org> In-Reply-To: <46A09F02.9020302@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.88.4/3706/Fri Jul 20 09:24:39 2007 on mh1.centtech.com X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=8.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.6 X-Spam-Checker-Version: SpamAssassin 3.1.6 (2006-10-03) on mh1.centtech.com Cc: freebsd-current@freebsd.org Subject: Re: processes stuck in kqread X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: kramer@centtech.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2007 18:07:42 -0000 yes. I've placed 2 different ones in ps.txt on http://users.centtech.com/~kramer/snapshot/ps.txt thanks. Eric Anderson wrote the following on 07/20/07 06:39: > kevin kramer wrote: >> I have been having issues for some time on -CURRENT. My latest update >> was 7/11. I have identified these processes as being stuck in kqread >> while waiting for them to continue. >> >> Processes that I know are a problem: >> sshd - I can watch a login and the process goes from Select to >> kqread, takes about 3-4 minutes to get a login prompt >> top - takes about 2-3 minutes to come up >> tar - never really even starts to read data in and stays in kqread >> >> Processes not affected: >> scp >> gstat > > > Can you show a ps -auxl while one or more processes are in this state? > > > Eric From owner-freebsd-current@FreeBSD.ORG Fri Jul 20 18:21:11 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A72F116A41F for ; Fri, 20 Jul 2007 18:21:11 +0000 (UTC) (envelope-from pj@smo.de) Received: from ilk.de (mx-out13.ilk.de [194.121.104.13]) by mx1.freebsd.org (Postfix) with ESMTP id 28B4913C457 for ; Fri, 20 Jul 2007 18:21:10 +0000 (UTC) (envelope-from pj@smo.de) Received: from bologna.intern.smo.de (pool16.ka.ilk.net [212.86.194.16]) by ilk.de (8.13.4/8.13.4/ilk-relay) with ESMTP id l6KIL7um017568; Fri, 20 Jul 2007 20:21:08 +0200 Received: from [192.168.153.208] (herdubreid.intern.smo.de [192.168.153.208]) by bologna.intern.smo.de (8.13.4+Sun/8.13.4) with ESMTP id l6KII9U5000894; Fri, 20 Jul 2007 20:18:09 +0200 (CEST) Message-ID: <46A0FD9D.507@smo.de> Date: Fri, 20 Jul 2007 20:23:25 +0200 From: Philipp Ost User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.13) Gecko/20070525 X-Accept-Language: de, en-us, en MIME-Version: 1.0 To: Christophe H References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: Upgrade X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Jul 2007 18:21:11 -0000 Christophe H wrote: > I just installed 7-CURRENT from Nov 2006, and I would like to upgrade > it. What is the best way to do this ? cvsup/csup and then rebuild your system. You may want to read /usr/src/UPDATING, section 'COMMON ITEMS' ;-) Philipp -- www.familie-ost.info/~pj From owner-freebsd-current@FreeBSD.ORG Fri Jul 20 18:33:43 2007 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D5DD316A41B for ; Fri, 20 Jul 2007 18:33:43 +0000 (UTC) (envelope-from bsd@kuehlbox.de) Received: from samael.qmail-ldap.de (mail.kuehlbox.de [62.159.47.22]) by mx1.freebsd.org (Postfix) with ESMTP id 3CB4D13C458 for ; Fri, 20 Jul 2007 18:33:42 +0000 (UTC) (envelope-from bsd@kuehlbox.de) Received: (qmail 70572 invoked from network); 20 Jul 2007 18:33:40 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlbox.de; b=EaD2H1NyJztG3lv6Ua2YBNgP+v33p8F3yiGkFhh88+vdpQRLZpqlxGB7pRsgt5j3d/9is+tDYlD499JBG8+80+JRrpDC2J/sQR9H6YAonRRRkKyPY1hqwmwCyKX3A40J ; Received: from unknown (HELO [192.168.200.128]) (bsd@kuehlbox.de@[82.135.93.20]) (envelope-sender ) by samael.qmail-ldap.de (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 20 Jul 2007 18:33:40 -0000 Message-ID: <46A10142.1030807@kuehlbox.de> Date: Fri, 20 Jul 2007 20:38:58 +0200 From: Teufel User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: current@FreeBSD.org References: <20070601105521.D77697@fledge.watson.org> <20070601125901.W92469@fw.reifenberger.com> <20070601.131946.71174943.imp@bsdimp.com> <200706040941.16507.hselasky@c2i.net> In-Reply-To: <200706040941.16507.hselasky@c2i.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: NET_NEEDS_GIANT removal X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Jul 2007 18:33:43 -0000 Hello everyone, is there any issue to replace i4b on -CURRENT with HPS one? I have had compiled these patches now for several years in my productions servers and had never issues with it. With all due respect to the authors, the current i4b looks very outdated. If HPS i4b is already GIANT-free, probably it would be a better idea to review the code and give some advices what needs to be fixed. Isdn in germany is still commonly used. I am currently installing some machines todo pf-stress-tests and could add a couple of isdn devices too if needed. Hans Petter Selasky wrote: > On Friday 01 June 2007 21:19, Warner Losh wrote: > >>>> i4b - ISDN implementation >>>> >>> ... >>> >>> Before deleting we should replace i4b with the one from hps. >>> http://www.selasky.org/hans_petter/isdn4bsd/index.html >>> It was said to be GIANT free last time I asked. >>> >> Who has reviewed this code? Last time I checked, it had all kinds of >> Byzantine construts that made it extremely difficult to penetrate. >> There were very few comments and it implemented state machines as >> computed gotos :-(. The cure would be worse than the disease. >> > > When was last time? > > The code is constantly changing during the years. > > --HPS > From owner-freebsd-current@FreeBSD.ORG Fri Jul 20 18:36:18 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5614716A468 for ; Fri, 20 Jul 2007 18:36:18 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outT.internet-mail-service.net (outT.internet-mail-service.net [216.240.47.243]) by mx1.freebsd.org (Postfix) with ESMTP id 3716013C45B for ; Fri, 20 Jul 2007 18:36:18 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Fri, 20 Jul 2007 11:36:17 -0700 Received: from julian-mac.elischer.org (nat.ironport.com [63.251.108.100]) by idiom.com (Postfix) with ESMTP id 429B2125A23; Fri, 20 Jul 2007 11:36:17 -0700 (PDT) Message-ID: <46A100C2.1030606@elischer.org> Date: Fri, 20 Jul 2007 11:36:50 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: Robert Watson References: <20070717131518.G1177@fledge.watson.org> <200707172342.39082.max@love2party.net> <20070720111539.U1096@fledge.watson.org> In-Reply-To: <20070720111539.U1096@fledge.watson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Max Laier , freebsd-arch@freebsd.org, freebsd-current@freebsd.org, freebsd-pf@freebsd.org, freebsd-net@freebsd.org Subject: Re: Attention pf/ipfw users with uid/gid/jail rules (Re: Reminder: NET_NEEDS_GIANT, debug.mpsafenet going away in 7.0) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2007 18:36:18 -0000 Robert Watson wrote: > > On Tue, 17 Jul 2007, Max Laier wrote: > > So far I have had 0 (zero) reports of problems since this thread began. > Could people using uid/gid/jail rules with ipfw or pf on 7.x *please* > try running their firewalls without debug.mpsafenet -- ignore the > witness warnings and/or disable witness, and let us know if you > experience deadlocks. We're reaching the very end of the merge cycle > for 7.0, and I would really like to remove the Giant crutches (now > effectively unused) from the network stack so it's not part of the > ABI/API, the code is simplified and cleaned up, etc. > does "problem" include a LOR message, or only a deadlock? I've seen plenty of the first, but not the second. From owner-freebsd-current@FreeBSD.ORG Fri Jul 20 18:45:24 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4F18916A41B for ; Fri, 20 Jul 2007 18:45:24 +0000 (UTC) (envelope-from rpaulo@fnop.net) Received: from core.fnop.net (mx.fnop.net [82.102.11.82]) by mx1.freebsd.org (Postfix) with ESMTP id BCFA513C481 for ; Fri, 20 Jul 2007 18:45:23 +0000 (UTC) (envelope-from rpaulo@fnop.net) Received: from core.fnop.net (mx.fnop.net [82.102.11.82]) by core.fnop.net (Postfix) with ESMTP id A4B23690E30; Fri, 20 Jul 2007 19:39:15 +0100 (WEST) Received: by core.fnop.net (Postfix, from userid 1015) id 65A79690E3A; Fri, 20 Jul 2007 19:39:15 +0100 (WEST) X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on core.fnop.net X-Spam-Level: X-Spam-Status: No, score=-0.3 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,RCVD_IN_XBL autolearn=no version=3.1.7 Received: from epsilon.local (62.169.112.101.rev.optimus.pt [62.169.112.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by core.fnop.net (Postfix) with ESMTP id 817E9690E30; Fri, 20 Jul 2007 19:39:14 +0100 (WEST) Message-ID: <46A102B8.1000101@fnop.net> Date: Fri, 20 Jul 2007 19:45:12 +0100 From: Rui Paulo User-Agent: Thunderbird 2.0.0.4 (X11/20070704) MIME-Version: 1.0 To: Christophe H References: <8E05E588-32AD-4D23-8113-2D3428DBE5BA@free.fr> In-Reply-To: <8E05E588-32AD-4D23-8113-2D3428DBE5BA@free.fr> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: current@freebsd.org Subject: Re: Panic on a Core Duo Macbook pro X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Jul 2007 18:45:24 -0000 Christophe H wrote: > >> >> On Jul 19, 2007, at 2:19 PM, Ian FREISLICH wrote: >> >>> Eric Anderson wrote: >>>> Christophe H wrote: >>>>> Hello, >>>>> >>>>> when I try to boot the latest snapshot of 7-current on my Core Duo >>>>> Macbook pro (r 1.1), I get a panic : >>>>> AP#1 (PHY#1) failed ! >>>>> Panic >>>>> >>>>> while FreeBSD 6.2-release can boot. >>>>> >>>>> Is there a way to give some kernel options at boot to avoid this ? >>>> >>>> >>>> Same here with my Macbook Pro. I tried some hints from Rui Paulo, with >>>> no success. Was that an i386 snapshot, or AMD64? >> >> Yes it was an i386 snapshot. >> >>> >>> Have you tried pressing any key on the keyboard before the boot >>> gets to this point? At the copyright does it for me. Try using a 6.2 install cd, not 7.0 snapshot. -- Rui Paulo From owner-freebsd-current@FreeBSD.ORG Fri Jul 20 18:45:46 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B255A16A419 for ; Fri, 20 Jul 2007 18:45:46 +0000 (UTC) (envelope-from staale@kristoffersen.ws) Received: from smtp.bluecom.no (smtp.bluecom.no [193.75.75.28]) by mx1.freebsd.org (Postfix) with ESMTP id 6FCC013C457 for ; Fri, 20 Jul 2007 18:45:46 +0000 (UTC) (envelope-from staale@kristoffersen.ws) Received: from eschew.pusen.org (unknown [193.69.145.10]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.bluecom.no (Postfix) with ESMTP id C72D912C33D; Fri, 20 Jul 2007 20:45:44 +0200 (CEST) Received: from chiller by eschew.pusen.org with local (Exim 4.50) id 1IBxU6-0006DA-20; Fri, 20 Jul 2007 20:45:50 +0200 Date: Fri, 20 Jul 2007 20:45:50 +0200 From: =?iso-8859-1?Q?St=E5le?= Kristoffersen To: Jack Vogel Message-ID: <20070720184550.GA22877@eschew.pusen.org> References: <20070716190441.GA19282@eschew.pusen.org> <20070716213425.GB19282@eschew.pusen.org> <20070718041159.GC37935@cdnetworks.co.kr> <20070718044700.GE37935@cdnetworks.co.kr> <20070718124350.GA25799@eschew.pusen.org> <46A06D8D.1070604@unsane.co.uk> <20070720122443.GA29372@eschew.pusen.org> <2a41acea0707200810n21843c76s9b0f4f37ef92722f@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <2a41acea0707200810n21843c76s9b0f4f37ef92722f@mail.gmail.com> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: Vince , current@freebsd.org Subject: Re: Slow networkperformance in current? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2007 18:45:46 -0000 On 2007-07-20 at 08:10, Jack Vogel wrote: > On 7/20/07, Ståle Kristoffersen wrote: > >On 2007-07-20 at 09:08, Vince wrote: > >> Silly as it might seem when did you last recompile the iperf port? I was > >> about to post a me too post yesterday, until I updated my system to use > >> the latest sched_ule at which point iperf froze my system completely, > >> recompiling the port fixed the freeze and the <100Mbit/sec on localhost. > >> I think it was compiled against the wrong threading library (been a > >> while since i last recompiled it.) > > > >Actually I just spotted this myself, when I recompiled I got in the range > >of 600Mbits/sec to localhost. However I do noot see the increase you see > >when running it multiple times. I still think 600Mbits/sec is a bit low. > > > >If I run it to a remote host I see the same numbers (around 600Mbits/sec) > > I am actually quite impressed with the stack right now, with our new > Oplin hardware and the ixgbe driver I have 9.8 Gb/s pumping thru > it. Of course its all about adequate hardware, configuration, and > tuning. Then it must be something I'm doing wrong. It's not that I'm running such a beast of a machine, but it should manage to fill a gigabitlink (and it did a few months ago!). Can you point out any tuning I might have detuned? -- Ståle Kristoffersen From owner-freebsd-current@FreeBSD.ORG Fri Jul 20 19:03:51 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EC25216A417 for ; Fri, 20 Jul 2007 19:03:51 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.178]) by mx1.freebsd.org (Postfix) with ESMTP id BED4013C46C for ; Fri, 20 Jul 2007 19:03:51 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by wa-out-1112.google.com with SMTP id j37so1156532waf for ; Fri, 20 Jul 2007 12:03:51 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=NPBJUgSevVvwBpF+61lg+LWxywVLU+H144gYKFt0JI0dP24ZiM50QURKIHUKqWbcjkRT6lnyL1yOwgRand2s/2rOJ0tGp1AFKHf1OlaUbffPgjN3qTYU6NFazhS5zGblnt4DBDUTDr5BYec6upz4AbopVtd5xwDOIZdjYo1E4pw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=uKm/Ja0W5PifLwBOb8ERkjZuvw6PDVQmEEp/ujc5SLGWG8kXqgbHNvPqSl9lSPiJNrYjd7yFpyLC8w1ARAxh0xmpATmpBVA1ivyjcCKwRb932wI6BGAQbcx8U28TyPCKuRUEadbmEEwP9/PP/20frc7QFE0H/kwf10nJClcR/8Y= Received: by 10.114.204.7 with SMTP id b7mr733086wag.1184958231513; Fri, 20 Jul 2007 12:03:51 -0700 (PDT) Received: by 10.114.103.14 with HTTP; Fri, 20 Jul 2007 12:03:51 -0700 (PDT) Message-ID: <2a41acea0707201203o28722443v8ab2bc9a8450bb92@mail.gmail.com> Date: Fri, 20 Jul 2007 12:03:51 -0700 From: "Jack Vogel" To: "=?ISO-8859-1?Q?St=E5le_Kristoffersen?=" In-Reply-To: <20070720184550.GA22877@eschew.pusen.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <20070716190441.GA19282@eschew.pusen.org> <20070716213425.GB19282@eschew.pusen.org> <20070718041159.GC37935@cdnetworks.co.kr> <20070718044700.GE37935@cdnetworks.co.kr> <20070718124350.GA25799@eschew.pusen.org> <46A06D8D.1070604@unsane.co.uk> <20070720122443.GA29372@eschew.pusen.org> <2a41acea0707200810n21843c76s9b0f4f37ef92722f@mail.gmail.com> <20070720184550.GA22877@eschew.pusen.org> Cc: Vince , current@freebsd.org Subject: Re: Slow networkperformance in current? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2007 19:03:52 -0000 On 7/20/07, St=E5le Kristoffersen wrote: > On 2007-07-20 at 08:10, Jack Vogel wrote: > > On 7/20/07, St=E5le Kristoffersen wrote: > > >On 2007-07-20 at 09:08, Vince wrote: > > >> Silly as it might seem when did you last recompile the iperf port? I= was > > >> about to post a me too post yesterday, until I updated my system to = use > > >> the latest sched_ule at which point iperf froze my system completely= , > > >> recompiling the port fixed the freeze and the <100Mbit/sec on localh= ost. > > >> I think it was compiled against the wrong threading library (been a > > >> while since i last recompiled it.) > > > > > >Actually I just spotted this myself, when I recompiled I got in the ra= nge > > >of 600Mbits/sec to localhost. However I do noot see the increase you s= ee > > >when running it multiple times. I still think 600Mbits/sec is a bit lo= w. > > > > > >If I run it to a remote host I see the same numbers (around 600Mbits/s= ec) > > > > I am actually quite impressed with the stack right now, with our new > > Oplin hardware and the ixgbe driver I have 9.8 Gb/s pumping thru > > it. Of course its all about adequate hardware, configuration, and > > tuning. > > Then it must be something I'm doing wrong. It's not that I'm running such= a > beast of a machine, but it should manage to fill a gigabitlink (and it di= d > a few months ago!). > > Can you point out any tuning I might have detuned? The stack being capable, as I said, of delivering the goods says nothing of the driver, what NIC is it? Did you ask if anyone else with that hardware is seeing a problem, I came into this thread somewhat late. Jack From owner-freebsd-current@FreeBSD.ORG Fri Jul 20 19:35:05 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 34C9916A417; Fri, 20 Jul 2007 19:35:05 +0000 (UTC) (envelope-from jd@ugcs.caltech.edu) Received: from regurgitate.ugcs.caltech.edu (regurgitate.ugcs.caltech.edu [131.215.176.97]) by mx1.freebsd.org (Postfix) with ESMTP id 0B21413C457; Fri, 20 Jul 2007 19:35:05 +0000 (UTC) (envelope-from jd@ugcs.caltech.edu) Received: by regurgitate.ugcs.caltech.edu (Postfix, from userid 3640) id 04D80E8AC; Fri, 20 Jul 2007 12:12:01 -0700 (PDT) Date: Fri, 20 Jul 2007 12:12:01 -0700 From: Paul Allen To: Julian Elischer Message-ID: <20070720191201.GE5504@regurgitate.ugcs.caltech.edu> References: <20070717131518.G1177@fledge.watson.org> <200707172342.39082.max@love2party.net> <20070720111539.U1096@fledge.watson.org> <46A100C2.1030606@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46A100C2.1030606@elischer.org> Sender: jd@ugcs.caltech.edu Cc: freebsd-net@freebsd.org, freebsd-arch@freebsd.org, freebsd-current@freebsd.org, Robert Watson , freebsd-pf@freebsd.org, Max Laier Subject: Re: Attention pf/ipfw users with uid/gid/jail rules (Re: Reminder: NET_NEEDS_GIANT, debug.mpsafenet going away in 7.0) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2007 19:35:05 -0000 >From Julian Elischer , Fri, Jul 20, 2007 at 11:36:50AM -0700: > Robert Watson wrote: > > > >On Tue, 17 Jul 2007, Max Laier wrote: > > > >So far I have had 0 (zero) reports of problems since this thread began. > >Could people using uid/gid/jail rules with ipfw or pf on 7.x *please* > >try running their firewalls without debug.mpsafenet -- ignore the > >witness warnings and/or disable witness, and let us know if you > >experience deadlocks. We're reaching the very end of the merge cycle > >for 7.0, and I would really like to remove the Giant crutches (now > >effectively unused) from the network stack so it's not part of the > >ABI/API, the code is simplified and cleaned up, etc. Wasn't there a a clear solution to the uid/gid problem involving flip-pages: eliminate the pf lock by forcing reconfigurations to build a parallel data-structure and then perform an atomic operation to exchange the pointers. AFAIK, Max's patch was just an ugly hack and it isn't really suitable for performance reasons. What's the state of MAC for the networking stack? Are we able to restrict particular uid's to listening only on particular ports? From owner-freebsd-current@FreeBSD.ORG Fri Jul 20 20:02:12 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E807516A41A for ; Fri, 20 Jul 2007 20:02:12 +0000 (UTC) (envelope-from staale@kristoffersen.ws) Received: from smtp.bluecom.no (smtp.bluecom.no [193.75.75.28]) by mx1.freebsd.org (Postfix) with ESMTP id A384913C46E for ; Fri, 20 Jul 2007 20:02:12 +0000 (UTC) (envelope-from staale@kristoffersen.ws) Received: from eschew.pusen.org (unknown [193.69.145.10]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.bluecom.no (Postfix) with ESMTP id 4073E12C662; Fri, 20 Jul 2007 22:02:11 +0200 (CEST) Received: from chiller by eschew.pusen.org with local (Exim 4.50) id 1IByg4-0007WD-Q7; Fri, 20 Jul 2007 22:02:16 +0200 Date: Fri, 20 Jul 2007 22:02:16 +0200 From: =?iso-8859-1?Q?St=E5le?= Kristoffersen To: Jack Vogel Message-ID: <20070720200216.GB22877@eschew.pusen.org> References: <20070716213425.GB19282@eschew.pusen.org> <20070718041159.GC37935@cdnetworks.co.kr> <20070718044700.GE37935@cdnetworks.co.kr> <20070718124350.GA25799@eschew.pusen.org> <46A06D8D.1070604@unsane.co.uk> <20070720122443.GA29372@eschew.pusen.org> <2a41acea0707200810n21843c76s9b0f4f37ef92722f@mail.gmail.com> <20070720184550.GA22877@eschew.pusen.org> <2a41acea0707201203o28722443v8ab2bc9a8450bb92@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <2a41acea0707201203o28722443v8ab2bc9a8450bb92@mail.gmail.com> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: Vince , current@freebsd.org Subject: Re: Slow networkperformance in current? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2007 20:02:13 -0000 On 2007-07-20 at 12:03, Jack Vogel wrote: > The stack being capable, as I said, of delivering the goods says nothing > of the driver, what NIC is it? Did you ask if anyone else with that > hardware is seeing a problem, I came into this thread somewhat late. I'm running this nic: re0: port 0x7e00-0x7eff mem 0xfd3ff000-0xfd3fffff irq 18 at device 0.0 on pci3 But I'm guessing it's not the NIC or its drivers fault, because I get the same performance (with 100% CPU) using localhost. -- Ståle Kristoffersen staalebk@ifi.uio.no From owner-freebsd-current@FreeBSD.ORG Fri Jul 20 20:29:24 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 94B0C16A417; Fri, 20 Jul 2007 20:29:24 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id E003013C45A; Fri, 20 Jul 2007 20:29:23 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 9528346B95; Fri, 20 Jul 2007 16:29:22 -0400 (EDT) Date: Fri, 20 Jul 2007 21:29:22 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Paul Allen In-Reply-To: <20070720191201.GE5504@regurgitate.ugcs.caltech.edu> Message-ID: <20070720212206.J83919@fledge.watson.org> References: <20070717131518.G1177@fledge.watson.org> <200707172342.39082.max@love2party.net> <20070720111539.U1096@fledge.watson.org> <46A100C2.1030606@elischer.org> <20070720191201.GE5504@regurgitate.ugcs.caltech.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org, freebsd-arch@freebsd.org, freebsd-current@freebsd.org, Julian Elischer , freebsd-pf@freebsd.org, Max Laier Subject: Re: Attention pf/ipfw users with uid/gid/jail rules (Re: Reminder: NET_NEEDS_GIANT, debug.mpsafenet going away in 7.0) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2007 20:29:24 -0000 On Fri, 20 Jul 2007, Paul Allen wrote: > From Julian Elischer , Fri, Jul 20, 2007 at 11:36:50AM -0700: >> Robert Watson wrote: >>> On Tue, 17 Jul 2007, Max Laier wrote: >>> >>> So far I have had 0 (zero) reports of problems since this thread began. >>> Could people using uid/gid/jail rules with ipfw or pf on 7.x *please* try >>> running their firewalls without debug.mpsafenet -- ignore the witness >>> warnings and/or disable witness, and let us know if you experience >>> deadlocks. We're reaching the very end of the merge cycle for 7.0, and I >>> would really like to remove the Giant crutches (now effectively unused) >>> from the network stack so it's not part of the ABI/API, the code is >>> simplified and cleaned up, etc. > > Wasn't there a a clear solution to the uid/gid problem involving flip-pages: > eliminate the pf lock by forcing reconfigurations to build a parallel > data-structure and then perform an atomic operation to exchange the > pointers. I think there are a few potential solutions and areas for work here, the trick is figuring out the best approach to get 7.0 out the door. I think any long term structural changes to the firewalls should be avoided at this point, and targeted at 7.1 or 8.0. FYI, my feeling is that the current approach taken, using a pcb lookup in the firewall, is not really an appropriate solution to the problem. Among other things, there are (small) race conditions such that the lookup could return one pcb in the input path and use that for the check, but another pcb during TCP-layer delivery. The lock order reversal warning is a symptom of reaching across layers in fairly ugly (and atomicity-unsafe) ways. One idea that I'd been pondering was having the inpcb code in the TCP/UDP/SCTP/etc layers invoke event handlers as bindings/connections are made, making credentials and other information available to firewall packages, which could then cache information under their own locks. > AFAIK, Max's patch was just an ugly hack and it isn't really suitable for > performance reasons. > > What's the state of MAC for the networking stack? Are we able to restrict > particular uid's to listening only on particular ports? See mac_portacl(4), which is a functional but not particularly elegant implementation of this idea. In Mac OS X Leopard, many of the traditional "firewall" sorts of checks are now performed at the socket layer using this sort of approach -- this provides greater application context, allows control of things like binding/listening, not just packet transmission and receipt, and provides access to the data as received at the application layer rather than at the datagram layer, avoiding the need for normalization. The MAC Framework will not be enabled by default in 7.0, but one of my goals for 8.0 is to ship the framework enabled in GENERIC by default. This will require a significant amount of performance optimization to do. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Fri Jul 20 20:33:42 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4A51516A419; Fri, 20 Jul 2007 20:33:42 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id F359A13C467; Fri, 20 Jul 2007 20:33:41 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 902AE48748; Fri, 20 Jul 2007 16:33:40 -0400 (EDT) Date: Fri, 20 Jul 2007 21:33:40 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Julian Elischer In-Reply-To: <46A100C2.1030606@elischer.org> Message-ID: <20070720213241.N83919@fledge.watson.org> References: <20070717131518.G1177@fledge.watson.org> <200707172342.39082.max@love2party.net> <20070720111539.U1096@fledge.watson.org> <46A100C2.1030606@elischer.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Max Laier , freebsd-arch@freebsd.org, freebsd-current@freebsd.org, freebsd-pf@freebsd.org, freebsd-net@freebsd.org Subject: Re: Attention pf/ipfw users with uid/gid/jail rules (Re: Reminder: NET_NEEDS_GIANT, debug.mpsafenet going away in 7.0) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2007 20:33:42 -0000 On Fri, 20 Jul 2007, Julian Elischer wrote: > Robert Watson wrote: >> >> On Tue, 17 Jul 2007, Max Laier wrote: >> >> So far I have had 0 (zero) reports of problems since this thread began. >> Could people using uid/gid/jail rules with ipfw or pf on 7.x *please* try >> running their firewalls without debug.mpsafenet -- ignore the witness >> warnings and/or disable witness, and let us know if you experience >> deadlocks. We're reaching the very end of the merge cycle for 7.0, and I >> would really like to remove the Giant crutches (now effectively unused) >> from the network stack so it's not part of the ABI/API, the code is >> simplified and cleaned up, etc. > > does "problem" include a LOR message, or only a deadlock? I've seen plenty > of the first, but not the second. Deadlocks. The LOR is expected, but actually a false positive with respect to deadlock potential, we now believe. To be specific: there is a cycle, but since the cycling conditions always involve read acquisition, they shouldn't lead to a wait cycle. So what we're looking for here is evidence of something more than the WITNESS warning. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Fri Jul 20 21:51:37 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9F12F16A41A for ; Fri, 20 Jul 2007 21:51:37 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.236]) by mx1.freebsd.org (Postfix) with ESMTP id 6337613C508 for ; Fri, 20 Jul 2007 21:51:36 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by nz-out-0506.google.com with SMTP id l8so814690nzf for ; Fri, 20 Jul 2007 14:51:35 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=f4sQLMV0Be7ypDzDXyVtvLTk+aPUmjhEi/NaJEnLXJB6bhwKaFHPB8EsuKh8S5DCOXwbCrXOuWor5EqO2w8Lp3t3pfzRqGTc+t+PAWlDX9IyyvWy7xRM9DYOMRpz+tSQMYfRzAn1kt81l2W/FY3TjzDEQxh+iAxW8J6Fl/zxG2A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=VG1xcyQlULriJGzGmYThoaj6xshojFbKnymBOgRO0neuEyJDiREYMtUtYUoG0RczpNIdRsOfuO7hXhfkHK9g9eAOMCAP06ElUxlcAfTpf9nBP5TTeJ0gik635aWb3dhyJ1jq+SP6JF/lVSPUL57HmQVfUFm1deV7fBehdvrvlEA= Received: by 10.115.54.1 with SMTP id g1mr861266wak.1184968294619; Fri, 20 Jul 2007 14:51:34 -0700 (PDT) Received: by 10.114.103.14 with HTTP; Fri, 20 Jul 2007 14:51:34 -0700 (PDT) Message-ID: <2a41acea0707201451h47ac79a6n1b0bb4987b692c52@mail.gmail.com> Date: Fri, 20 Jul 2007 14:51:34 -0700 From: "Jack Vogel" To: "=?ISO-8859-1?Q?St=E5le_Kristoffersen?=" In-Reply-To: <20070720200216.GB22877@eschew.pusen.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <20070718041159.GC37935@cdnetworks.co.kr> <20070718044700.GE37935@cdnetworks.co.kr> <20070718124350.GA25799@eschew.pusen.org> <46A06D8D.1070604@unsane.co.uk> <20070720122443.GA29372@eschew.pusen.org> <2a41acea0707200810n21843c76s9b0f4f37ef92722f@mail.gmail.com> <20070720184550.GA22877@eschew.pusen.org> <2a41acea0707201203o28722443v8ab2bc9a8450bb92@mail.gmail.com> <20070720200216.GB22877@eschew.pusen.org> Cc: Vince , current@freebsd.org Subject: Re: Slow networkperformance in current? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2007 21:51:37 -0000 On 7/20/07, St=E5le Kristoffersen wrote: > On 2007-07-20 at 12:03, Jack Vogel wrote: > > The stack being capable, as I said, of delivering the goods says nothin= g > > of the driver, what NIC is it? Did you ask if anyone else with that > > hardware is seeing a problem, I came into this thread somewhat late. > > I'm running this nic: > re0: port 0x7e00-0x7eff mem > 0xfd3ff000-0xfd3fffff irq 18 at device 0.0 on pci3 > > But I'm guessing it's not the NIC or its drivers fault, because I get the > same performance (with 100% CPU) using localhost. Well, I just tried that on one of the machines here in my cube, running iperf across a localhost connection I get 1.25 Gb/s, what do you see? A second slightly older box doing the same thing only gets 977 Mb, I wonder if that's front side bus relative, would make sense. And what do you see? Jack From owner-freebsd-current@FreeBSD.ORG Fri Jul 20 22:10:44 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4F5A016A417 for ; Fri, 20 Jul 2007 22:10:44 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outR.internet-mail-service.net (outR.internet-mail-service.net [216.240.47.241]) by mx1.freebsd.org (Postfix) with ESMTP id 2997313C45A for ; Fri, 20 Jul 2007 22:10:44 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Fri, 20 Jul 2007 15:10:43 -0700 Received: from julian-mac.elischer.org (nat.ironport.com [63.251.108.100]) by idiom.com (Postfix) with ESMTP id CFC5F125ADD; Fri, 20 Jul 2007 15:10:42 -0700 (PDT) Message-ID: <46A132F4.3030703@elischer.org> Date: Fri, 20 Jul 2007 15:11:00 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: Jack Vogel References: <20070718041159.GC37935@cdnetworks.co.kr> <20070718044700.GE37935@cdnetworks.co.kr> <20070718124350.GA25799@eschew.pusen.org> <46A06D8D.1070604@unsane.co.uk> <20070720122443.GA29372@eschew.pusen.org> <2a41acea0707200810n21843c76s9b0f4f37ef92722f@mail.gmail.com> <20070720184550.GA22877@eschew.pusen.org> <2a41acea0707201203o28722443v8ab2bc9a8450bb92@mail.gmail.com> <20070720200216.GB22877@eschew.pusen.org> <2a41acea0707201451h47ac79a6n1b0bb4987b692c52@mail.gmail.com> In-Reply-To: <2a41acea0707201451h47ac79a6n1b0bb4987b692c52@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Vince , current@freebsd.org, =?ISO-8859-1?Q?St=E5le_Kristoffersen?= Subject: Re: Slow networkperformance in current? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2007 22:10:44 -0000 Jack Vogel wrote: > On 7/20/07, Ståle Kristoffersen wrote: >> On 2007-07-20 at 12:03, Jack Vogel wrote: >> > The stack being capable, as I said, of delivering the goods says >> nothing >> > of the driver, what NIC is it? Did you ask if anyone else with that >> > hardware is seeing a problem, I came into this thread somewhat late. >> >> I'm running this nic: >> re0: port 0x7e00-0x7eff mem >> 0xfd3ff000-0xfd3fffff irq 18 at device 0.0 on pci3 >> >> But I'm guessing it's not the NIC or its drivers fault, because I get the >> same performance (with 100% CPU) using localhost. > > Well, I just tried that on one of the machines here in my cube, running > iperf across a localhost connection I get 1.25 Gb/s, what do you see? > A second slightly older box doing the same thing only gets 977 Mb, I > wonder if that's front side bus relative, would make sense. > > And what do you see? Loopback can sometimes be a lot slower than actual traffic due to scheduling considerations. Robert Watson has more information on this. > > Jack > _______________________________________________ > 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 Jul 20 22:51:45 2007 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 15F1A16A419; Fri, 20 Jul 2007 22:51:45 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from mail.ipt.ru (mail.ipt.ru [194.62.233.102]) by mx1.freebsd.org (Postfix) with ESMTP id A72E813C442; Fri, 20 Jul 2007 22:51:44 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from admin.sem.ipt.ru ([192.168.12.1] helo=ipt.ru) by mail.ipt.ru with esmtp (Exim 4.62 (FreeBSD)) (envelope-from ) id 1IC0g4-0006kr-62; Sat, 21 Jul 2007 02:10:24 +0400 Received: from bsam by ipt.ru with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1IC0gD-0002vs-HJ; Sat, 21 Jul 2007 02:10:33 +0400 To: freebsd-current@FreeBSD.org References: <20070720213211.GA7262@saturn.kn-bremen.de> From: Boris Samorodov Date: Sat, 21 Jul 2007 02:10:33 +0400 In-Reply-To: <20070720213211.GA7262@saturn.kn-bremen.de> (Juergen Lock's message of "Fri\, 20 Jul 2007 23\:32\:11 +0200") Message-ID: <08469478@srv.sem.ipt.ru> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.99 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-emulation@FreeBSD.org Subject: Re: kqemu and sched_lock, please test port update X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Jul 2007 22:51:45 -0000 On Fri, 20 Jul 2007 23:32:11 +0200 Juergen Lock wrote: > I just noticed this, and came up with the update below. I still don't > have a -current box so I need you to test this before I commit it... Kqemu with the patch compiles well at amd64-current as of yesterday. Don't have time ATM to check running. Thanks for the patch! WBR -- Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-current@FreeBSD.ORG Fri Jul 20 23:00:29 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 051BD16A418 for ; Fri, 20 Jul 2007 23:00:29 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.182]) by mx1.freebsd.org (Postfix) with ESMTP id C626913C459 for ; Fri, 20 Jul 2007 23:00:28 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by wa-out-1112.google.com with SMTP id j37so1221216waf for ; Fri, 20 Jul 2007 16:00:28 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=n1l7eMd+RtvTLaQlY1NJX84JpCnwlUyte/7FI4NxbIrF9WMApzddzZJW46V/l/C7W43FoNi08bCX2qUWpuOSxPVydErHMsm0+UmLAysPJiYQjPj1dVu0mTkG8UPmRk830fbK+xeD/fLMiY+0BwHtIhiiSc0g7pW9dVEjW1oiPJs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=QzVoFQIpfLVJMG8ibm1VJo4zalTTQVRN47XGS35ZLVI0U2V2hP1j0JG7By1WenV77WdJgUkDMnyZPet5HfV3C7gxC5Y9y0v+NXIV5ozqnFXnteRg3zluAj7YPKkkGmNkzNdIsc44T4OSG0LD+hUaG2HbDFkXZ16hiwFgHfi7ieg= Received: by 10.114.210.2 with SMTP id i2mr926768wag.1184972428269; Fri, 20 Jul 2007 16:00:28 -0700 (PDT) Received: by 10.114.103.14 with HTTP; Fri, 20 Jul 2007 16:00:28 -0700 (PDT) Message-ID: <2a41acea0707201600x3ae07833m1a54b2e5ae3d1b7c@mail.gmail.com> Date: Fri, 20 Jul 2007 16:00:28 -0700 From: "Jack Vogel" To: "Alexandre Biancalana" In-Reply-To: <8e10486b0707201548r18aabeddt9655ed5372a1aaa7@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070716190441.GA19282@eschew.pusen.org> <20070716213425.GB19282@eschew.pusen.org> <20070718041159.GC37935@cdnetworks.co.kr> <20070718044700.GE37935@cdnetworks.co.kr> <20070718124350.GA25799@eschew.pusen.org> <46A06D8D.1070604@unsane.co.uk> <20070720122443.GA29372@eschew.pusen.org> <2a41acea0707200810n21843c76s9b0f4f37ef92722f@mail.gmail.com> <8e10486b0707201548r18aabeddt9655ed5372a1aaa7@mail.gmail.com> Cc: =?ISO-8859-1?Q?St=E5le_Kristoffersen?= , Vince , =?ISO-8859-1?Q?St=E5le_Kristoffersen?= , current@freebsd.org Subject: Re: Slow networkperformance in current? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2007 23:00:29 -0000 On 7/20/07, Alexandre Biancalana wrote: > On 7/20/07, Jack Vogel wrote: > > > > I am actually quite impressed with the stack right now, with our new > > Oplin hardware and the ixgbe driver I have 9.8 Gb/s pumping thru > > it. Of course its all about adequate hardware, configuration, and > > tuning. > > > Can you post the configuration tuning done ? > > Get rid of INVARIANT and WITNESS of course. Use ULE scheduler Use MTU of 9000 Set interrupt storm threshold up to 8000 (default is 1000), if we didnt do this the channel would get throttled. Then we need to make sure MSI/X is enabled, and set the number of RX queues to 8 (this is Oplin specific). The ixgbe driver uses 4K jumbo clusters as long as you set MTU up. I have experimented with Kip's patch for 9K and it helps a bit but mainly it improves cpu utilization. Beyond this doing 10G is very sensitive to things like cpu's, frontside bus, memory, etc, but these are things that I didn't personally set up, I just tell them to give me a kick ass machine :) Jack From owner-freebsd-current@FreeBSD.ORG Fri Jul 20 23:10:05 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0D3A816A418 for ; Fri, 20 Jul 2007 23:10:05 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.180]) by mx1.freebsd.org (Postfix) with ESMTP id D25CD13C467 for ; Fri, 20 Jul 2007 23:10:04 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by wa-out-1112.google.com with SMTP id j37so1223702waf for ; Fri, 20 Jul 2007 16:10:04 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=mMBMPvgytRxirc/VeRyF2Uo1g251/7lGxlkYlpT12IRRe1m6ZAVZIaH9L4P/Gqe3UmmPRdJ0YPSqiJymQMDohHByy0mgIsJoE3JGpBLhpK7PPzgRuKq1YhXE/0TN6MUBtm0TQXvNJkAblxK7agOhctvjoaSMWno+UaE3jJO2WZw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=QshCue9c4oQuGKsuWqo72Az25cv64o6WkNjZwOZye2KQjXAEETRcSs0Mp6YIWpvDZV7rtoGAqOeiSauqxyhwLGu6dracDjbXDUAaMUGypgb2UuYduVZhPGlotsbkQJkzvOM12B/Sor4GSAtprYoOCSlvD7s0Tx2FuZzvU/UnYR4= Received: by 10.115.109.1 with SMTP id l1mr906085wam.1184973004534; Fri, 20 Jul 2007 16:10:04 -0700 (PDT) Received: by 10.114.103.14 with HTTP; Fri, 20 Jul 2007 16:10:04 -0700 (PDT) Message-ID: <2a41acea0707201610o48ed9b20ub3d22a0206982b19@mail.gmail.com> Date: Fri, 20 Jul 2007 16:10:04 -0700 From: "Jack Vogel" To: "Alexandre Biancalana" In-Reply-To: <2a41acea0707201600x3ae07833m1a54b2e5ae3d1b7c@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070716190441.GA19282@eschew.pusen.org> <20070716213425.GB19282@eschew.pusen.org> <20070718041159.GC37935@cdnetworks.co.kr> <20070718044700.GE37935@cdnetworks.co.kr> <20070718124350.GA25799@eschew.pusen.org> <46A06D8D.1070604@unsane.co.uk> <20070720122443.GA29372@eschew.pusen.org> <2a41acea0707200810n21843c76s9b0f4f37ef92722f@mail.gmail.com> <8e10486b0707201548r18aabeddt9655ed5372a1aaa7@mail.gmail.com> <2a41acea0707201600x3ae07833m1a54b2e5ae3d1b7c@mail.gmail.com> Cc: =?ISO-8859-1?Q?St=E5le_Kristoffersen?= , Vince , =?ISO-8859-1?Q?St=E5le_Kristoffersen?= , current@freebsd.org Subject: Re: Slow networkperformance in current? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2007 23:10:05 -0000 On 7/20/07, Jack Vogel wrote: > On 7/20/07, Alexandre Biancalana wrote: > > On 7/20/07, Jack Vogel wrote: > > > > > > I am actually quite impressed with the stack right now, with our new > > > Oplin hardware and the ixgbe driver I have 9.8 Gb/s pumping thru > > > it. Of course its all about adequate hardware, configuration, and > > > tuning. > > > > > > Can you post the configuration tuning done ? > > > > > > Get rid of INVARIANT and WITNESS of course. > Use ULE scheduler > Use MTU of 9000 > Set interrupt storm threshold up to 8000 (default is 1000), if we didnt > do this the channel would get throttled. > > Then we need to make sure MSI/X is enabled, and set the number > of RX queues to 8 (this is Oplin specific). > > The ixgbe driver uses 4K jumbo clusters as long as you set MTU > up. I have experimented with Kip's patch for 9K and it helps a bit > but mainly it improves cpu utilization. > > Beyond this doing 10G is very sensitive to things like cpu's, frontside bus, > memory, etc, but these are things that I didn't personally set up, I just > tell them to give me a kick ass machine :) OH, one other item I forgot, use TSO, I think thats significant help. From owner-freebsd-current@FreeBSD.ORG Fri Jul 20 23:17:06 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 59A9F16A417 for ; Fri, 20 Jul 2007 23:17:06 +0000 (UTC) (envelope-from biancalana@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.231]) by mx1.freebsd.org (Postfix) with ESMTP id 0607013C442 for ; Fri, 20 Jul 2007 23:17:05 +0000 (UTC) (envelope-from biancalana@gmail.com) Received: by wx-out-0506.google.com with SMTP id i29so852216wxd for ; Fri, 20 Jul 2007 16:17:05 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=hktMJsnnHoYisXvGfV12DONfCprhY8xrQqJEpsvEYIrFTSof2Yg8GHk264S0yuSdmQmAdq+ugVEzT/O5Ra9sY3JkAFaP3tdQkXqmuyHYe9aLMYz8+/Bw3RE2sY8OXtwWplfs2cIvVk007ubIYNY46sRWD3AfEw4DSVYmfTLO/0c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=RIT0y9M5OQlVk5MpvmqSpXlBJowczH4mzgAPfDyISAESzEKyj1YPnpFYADSCK8YQCeLScb3Z30M7K9GHgWyWIp4lmYgvyu4DEbmaiNOj8IY5bdyOo4RohHonVBWpYEcFic6EInvyv/kdaE12yK8g8fnFXXwFSNErR4ZD0zdqPK4= Received: by 10.70.66.18 with SMTP id o18mr1600833wxa.1184971684122; Fri, 20 Jul 2007 15:48:04 -0700 (PDT) Received: by 10.70.66.10 with HTTP; Fri, 20 Jul 2007 15:48:04 -0700 (PDT) Message-ID: <8e10486b0707201548r18aabeddt9655ed5372a1aaa7@mail.gmail.com> Date: Fri, 20 Jul 2007 19:48:04 -0300 From: "Alexandre Biancalana" To: "Jack Vogel" In-Reply-To: <2a41acea0707200810n21843c76s9b0f4f37ef92722f@mail.gmail.com> MIME-Version: 1.0 References: <20070716190441.GA19282@eschew.pusen.org> <20070716213425.GB19282@eschew.pusen.org> <20070718041159.GC37935@cdnetworks.co.kr> <20070718044700.GE37935@cdnetworks.co.kr> <20070718124350.GA25799@eschew.pusen.org> <46A06D8D.1070604@unsane.co.uk> <20070720122443.GA29372@eschew.pusen.org> <2a41acea0707200810n21843c76s9b0f4f37ef92722f@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: =?ISO-8859-1?Q?St=E5le_Kristoffersen?= , Vince , =?ISO-8859-1?Q?St=E5le_Kristoffersen?= , current@freebsd.org Subject: Re: Slow networkperformance in current? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2007 23:17:06 -0000 On 7/20/07, Jack Vogel wrote: > > > I am actually quite impressed with the stack right now, with our new > Oplin hardware and the ixgbe driver I have 9.8 Gb/s pumping thru > it. Of course its all about adequate hardware, configuration, and > tuning. Can you post the configuration tuning done ? From owner-freebsd-current@FreeBSD.ORG Fri Jul 20 23:21:50 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 87E0716A417; Fri, 20 Jul 2007 23:21:50 +0000 (UTC) (envelope-from tataz@tataz.chchile.org) Received: from smtp5-g19.free.fr (smtp5-g19.free.fr [212.27.42.35]) by mx1.freebsd.org (Postfix) with ESMTP id 49D4C13C465; Fri, 20 Jul 2007 23:21:50 +0000 (UTC) (envelope-from tataz@tataz.chchile.org) Received: from tatooine.tataz.chchile.org (tataz.chchile.org [82.233.239.98]) by smtp5-g19.free.fr (Postfix) with ESMTP id 1D28244678; Sat, 21 Jul 2007 01:21:49 +0200 (CEST) Received: from obiwan.tataz.chchile.org (unknown [192.168.1.25]) by tatooine.tataz.chchile.org (Postfix) with ESMTP id 611CD9B497; Fri, 20 Jul 2007 23:21:00 +0000 (UTC) Received: by obiwan.tataz.chchile.org (Postfix, from userid 1000) id 45010405B; Sat, 21 Jul 2007 01:21:00 +0200 (CEST) Date: Sat, 21 Jul 2007 01:21:00 +0200 From: Jeremie Le Hen To: John Baldwin Message-ID: <20070720232100.GA35292@obiwan.tataz.chchile.org> References: <20070616224703.GC63387@obiwan.tataz.chchile.org> <20070618100238.GD46910@heff.fud.org.nz> <200707160849.07376.jhb@freebsd.org> <20070720095721.GE56695@obiwan.tataz.chchile.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070720095721.GE56695@obiwan.tataz.chchile.org> User-Agent: Mutt/1.5.15 (2007-04-06) Cc: freebsd-current@freebsd.org, Andrew Thompson Subject: Re: Cannot use iwi(4): "could not load firmware iwi_bss" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Jul 2007 23:21:50 -0000 On Fri, Jul 20, 2007 at 11:57:21AM +0200, Jeremie Le Hen wrote: > Thank you for replying :-). > > I'm indeed not using APIC (ISTR it was designed for SMP, I don't know > what benefit I could get from it considering my laptop is UP). > > I stopped using ACPI a few months ago as it prevented psm(4) from > working (albeit it ACPI+SMP doesn't exhibit the problem) (see [1]). > > What do you advice me to do? Do you need me to do some testing, > enabling ACPI or something like that? I'm at work currently, I will > only be able to do this in a couple of hour. Ok, I've tried with ACPI enabled and I confirm that iwi(4) can successfully load its firmware in this case. Unfortunately psm(4) doesn't work so this is not an option for me. Best regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-current@FreeBSD.ORG Fri Jul 20 22:06:04 2007 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1501316A41A for ; Fri, 20 Jul 2007 22:06:04 +0000 (UTC) (envelope-from nox@saturn.kn-bremen.de) Received: from gwyn.kn-bremen.de (gwyn.kn-bremen.de [212.63.36.242]) by mx1.freebsd.org (Postfix) with ESMTP id C357213C458 for ; Fri, 20 Jul 2007 22:06:03 +0000 (UTC) (envelope-from nox@saturn.kn-bremen.de) Received: by gwyn.kn-bremen.de (Postfix, from userid 10) id 398131FDA54; Fri, 20 Jul 2007 23:33:52 +0200 (CEST) Received: from saturn.kn-bremen.de (nox@localhost [127.0.0.1]) by saturn.kn-bremen.de (8.13.8/8.13.6) with ESMTP id l6KLWB8N007411; Fri, 20 Jul 2007 23:32:11 +0200 (CEST) (envelope-from nox@saturn.kn-bremen.de) Received: (from nox@localhost) by saturn.kn-bremen.de (8.13.8/8.13.6/Submit) id l6KLWBaq007410; Fri, 20 Jul 2007 23:32:11 +0200 (CEST) (envelope-from nox) From: Juergen Lock Date: Fri, 20 Jul 2007 23:32:11 +0200 To: freebsd-current@FreeBSD.org, freebsd-emulation@FreeBSD.org Message-ID: <20070720213211.GA7262@saturn.kn-bremen.de> Mail-Followup-To: freebsd-current@FreeBSD.org, freebsd-emulation@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.16 (2007-06-09) X-Mailman-Approved-At: Fri, 20 Jul 2007 23:41:30 +0000 Cc: Subject: kqemu and sched_lock, please test port update X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Jul 2007 22:06:04 -0000 I just noticed this, and came up with the update below. I still don't have a -current box so I need you to test this before I commit it... Thanx, Juergen Index: Makefile =================================================================== RCS file: /home/pcvs/ports/emulators/kqemu-kmod/Makefile,v retrieving revision 1.19 diff -u -r1.19 Makefile --- Makefile 14 Jul 2007 17:48:56 -0000 1.19 +++ Makefile 20 Jul 2007 21:21:14 -0000 @@ -7,7 +7,7 @@ PORTNAME= kqemu PORTVERSION= 1.3.0.p11 -PORTREVISION= 1 +PORTREVISION= 2 CATEGORIES= emulators kld MASTER_SITES= http://fabrice.bellard.free.fr/qemu/ \ http://qemu.org/ \ Index: files/patch-kqemu-freebsd.c =================================================================== RCS file: /home/pcvs/ports/emulators/kqemu-kmod/files/patch-kqemu-freebsd.c,v retrieving revision 1.5 diff -u -r1.5 patch-kqemu-freebsd.c --- files/patch-kqemu-freebsd.c 6 Feb 2007 20:46:29 -0000 1.5 +++ files/patch-kqemu-freebsd.c 20 Jul 2007 21:17:33 -0000 @@ -1,5 +1,23 @@ Index: kqemu-freebsd.c -@@ -321,6 +321,9 @@ +@@ -208,9 +208,17 @@ + int CDECL kqemu_schedule(void) + { + /* kqemu_log("kqemu_schedule\n"); */ ++#if __FreeBSD_version < 700044 + mtx_lock_spin(&sched_lock); + mi_switch(SW_VOL, NULL); + mtx_unlock_spin(&sched_lock); ++#else ++ /* -current no longer uses sched_lock */ ++ struct thread *td = curthread; ++ thread_lock(td); ++ mi_switch(SW_VOL, NULL); ++ thread_unlock(td); ++#endif + return SIGPENDING(curthread); + } + #endif +@@ -320,6 +328,9 @@ #if __FreeBSD_version >= 500000 dev->si_drv1 = NULL; TAILQ_REMOVE(&kqemuhead, ks, kqemu_ent); @@ -9,4 +27,3 @@ destroy_dev(dev); #endif free(ks, M_KQEMU); - From owner-freebsd-current@FreeBSD.ORG Sat Jul 21 00:55:04 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 48E4C16A420 for ; Sat, 21 Jul 2007 00:55:04 +0000 (UTC) (envelope-from markhobden@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.232]) by mx1.freebsd.org (Postfix) with ESMTP id E9C3113C459 for ; Sat, 21 Jul 2007 00:55:03 +0000 (UTC) (envelope-from markhobden@gmail.com) Received: by wx-out-0506.google.com with SMTP id i29so864948wxd for ; Fri, 20 Jul 2007 17:55:03 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=uby+mbiCUgWEnn38YnNQjxxOU2zY6aGkklX71Yr0pNw7YlMUfy2Q15NMPOGoMxmiCJhKywI9r1aoY5nSDKrw0uRF2nuhJKLbpU3uqZm0dvqFfZn06DMutx8cSF+vJlPkk+WLS+yxJDiJRtDUyheQVr2Y6tl0GWlnvngBpm1m8Ms= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=lUfOLblKcLs7BpsghIHtz6XhPubLyigTDdnKTvD8fsHWM8t4h1FT25t71iLe5DYr9lSqvKUaSAozHt9F4k0vjCfR2AvbliQ7goI0yQ0v+/XHcA9acJXz9kB5jWa8/CJ/oSctliuTNDWqV14THbASG3mcj38saIJRUvsKtGaobQo= Received: by 10.90.93.6 with SMTP id q6mr976777agb.1184979303054; Fri, 20 Jul 2007 17:55:03 -0700 (PDT) Received: by 10.90.117.10 with HTTP; Fri, 20 Jul 2007 17:55:03 -0700 (PDT) Message-ID: Date: Sat, 21 Jul 2007 01:55:03 +0100 From: "Mark Hobden" To: vova@fbsd.ru In-Reply-To: <1184946870.1356.2.camel@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1184929509.1415.10.camel@localhost> <1184946870.1356.2.camel@localhost> Cc: freebsd-current@freebsd.org, freebsd-usb@freebsd.org Subject: Re: uhidev(4) update - USB HID driver level for devices with multiple report ids X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Jul 2007 00:55:04 -0000 On 20/07/07, Vladimir Grebenschikov wrote: > > They was failed to load as modules (from loader.conf): > (kernel was rebuilt entirely) > > link_elf: symbol hid_start_parse undefined > KLD file ukbd.ko - could not finalize loading > link_elf: symbol hid_locate undefined > KLD file ums.ko - could not finalize loading > > see full dmesg -v and usbdevs -d -v in attachment > Hi Vladimir, Thanks for helping me track this down, I had managed to leave out that that ums, ukbd & uhid depend on usb as well as uhidev (this was previously in a macro). This upset trying to kldload the modules. I have uploaded a new patch over the old one. People only need this update though if they do not have 'device usb' in their kernel config file. http://www.terinea.co.uk/~mark/patches/uhidev-7-current-p2.diff Mark From owner-freebsd-current@FreeBSD.ORG Sat Jul 21 03:46:11 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 32DEA16A417 for ; Sat, 21 Jul 2007 03:46:11 +0000 (UTC) (envelope-from lance.myatt@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.171]) by mx1.freebsd.org (Postfix) with ESMTP id AFA6513C45D for ; Sat, 21 Jul 2007 03:46:10 +0000 (UTC) (envelope-from lance.myatt@gmail.com) Received: by ug-out-1314.google.com with SMTP id o4so929006uge for ; Fri, 20 Jul 2007 20:46:09 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=qbuzUeVOloo1FxaECsx9zXO2A64kgVomjOrjJITbRNj8FXzO8CeRK66IPzxLFDyErmT2T1rI9rNM3BAc+EN99SHgm7RacmRpookInjRMG+U0W3yxuJJQstT/27xBgdZNHcboEM7JgXMf1eAvi/VzlvJKUXkjjweJGhMzEX5rDKg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=Z7tD4NWInVDFPbmnZJWCXealgc4ZML4ov7va8917ulvlGknZagfwtOYdT8i/TB07G/Tn7AiwL0b/dZNzt8kY9lp3TFLFIAznIQvK9WWqzdr3NR6gf01Y8fPz+DhtPgy2H2XL7xOrIKKM1vkI8zRpcGaVj7Cyl4FnMIhGSo55R/s= Received: by 10.78.168.1 with SMTP id q1mr244348hue.1184988079811; Fri, 20 Jul 2007 20:21:19 -0700 (PDT) Received: by 10.78.205.14 with HTTP; Fri, 20 Jul 2007 20:21:19 -0700 (PDT) Message-ID: Date: Sat, 21 Jul 2007 13:21:19 +1000 From: "Lance Myatt" To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: buildworld failing for csh X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Jul 2007 03:46:11 -0000 Hi all, I am attempting to upgrade from STABLE to CURRENT for the first time. However, buildworld fails just after the start of Stage 2.3, while building csh. I've tried deleting /usr/obj and deleting/retrieving the whole source tree again. Contents of make.conf: CPUTYPE?=pentium2 NO_PROFILE= Error log: cc -E -O1 -pipe -I. -I/usr/src/bin/csh -I/usr/src/bin/csh/../../contrib/tcsh -D_PATH_TCSHELL='"/bin/csh"' -DHAVE_ICONV -I/usr/obj/usr/src/tmp/legacy/usr/include /usr/src/bin/csh/../../contrib/tcsh/tc.const.c /usr/src/bin/csh/../../contrib/tcsh/sh.char.h /usr/src/bin/csh/config.h /usr/src/bin/csh/../../contrib/tcsh/config_f.h /usr/src/bin/csh/../../contrib/tcsh/sh.types.h sh.err.h -D_h_tc_const | grep 'Char STR' | sed -e 's/Char \([a-zA-Z0-9_]*\)\(.*\)/extern Char \1[];/' | sort >> tc.const.h In file included from /usr/src/bin/csh/config.h:235, from /usr/src/bin/csh/../../contrib/tcsh/sh.h:36, from /usr/src/bin/csh/../../contrib/tcsh/tc.const.c:33: /usr/src/bin/csh/../../contrib/tcsh/config_f.h:63:1: warning: "NLS" redefined In file included from /usr/src/bin/csh/../../contrib/tcsh/sh.h:36, from /usr/src/bin/csh/../../contrib/tcsh/tc.const.c:33: /usr/src/bin/csh/config.h:180:1: warning: this is the location of the previous definition In file included from /usr/src/bin/csh/../../contrib/tcsh/sh.h:366, from /usr/src/bin/csh/../../contrib/tcsh/tc.const.c:33: /usr/include/varargs.h:34:2: #error " is obsolete with this version of GCC." /usr/include/varargs.h:35:2: #error "Change your code to use instead." In file included from /usr/src/bin/csh/config.h:235: /usr/src/bin/csh/../../contrib/tcsh/config_f.h:63:1: warning: "NLS" redefined /usr/src/bin/csh/config.h:180:1: warning: this is the location of the previous definition cc -o gethost -L/usr/obj/usr/src/tmp/legacy/usr/lib -O1 -pipe -I. -I/usr/src/bin/csh -I/usr/src/bin/csh/../../contrib/tcsh -D_PATH_TCSHELL='"/bin/csh"' -DHAVE_ICONV -I/usr/obj/usr/src/tmp/legacy/usr/include /usr/src/bin/csh/../../contrib/tcsh/gethost.c In file included from /usr/src/bin/csh/config.h:235, from /usr/src/bin/csh/../../contrib/tcsh/sh.h:36, from /usr/src/bin/csh/../../contrib/tcsh/gethost.c:33: /usr/src/bin/csh/../../contrib/tcsh/config_f.h:63:1: warning: "NLS" redefined In file included from /usr/src/bin/csh/../../contrib/tcsh/sh.h:36, from /usr/src/bin/csh/../../contrib/tcsh/gethost.c:33: /usr/src/bin/csh/config.h:180:1: warning: this is the location of the previous definition In file included from /usr/src/bin/csh/../../contrib/tcsh/sh.h:366, from /usr/src/bin/csh/../../contrib/tcsh/gethost.c:33: /usr/include/varargs.h:34:2: #error " is obsolete with this version of GCC." /usr/include/varargs.h:35:2: #error "Change your code to use instead." In file included from /usr/src/bin/csh/../../contrib/tcsh/gethost.c:33: /usr/src/bin/csh/../../contrib/tcsh/sh.h:484: error: syntax error before '*' token In file included from /usr/src/bin/csh/../../contrib/tcsh/gethost.c:33: /usr/src/bin/csh/../../contrib/tcsh/sh.h:750: error: syntax error before "parintr" /usr/src/bin/csh/../../contrib/tcsh/sh.h:750: warning: data definition has no type or storage class /usr/src/bin/csh/../../contrib/tcsh/sh.h:751: error: syntax error before "parterm" /usr/src/bin/csh/../../contrib/tcsh/sh.h:751: warning: data definition has no type or storage class In file included from /usr/src/bin/csh/../../contrib/tcsh/tc.h:42, from /usr/src/bin/csh/../../contrib/tcsh/sh.h:1252, from /usr/src/bin/csh/../../contrib/tcsh/gethost.c:33: /usr/src/bin/csh/../../contrib/tcsh/tc.decls.h:90: error: syntax error before "alrmcatch" /usr/src/bin/csh/../../contrib/tcsh/tc.decls.h:90: warning: data definition has no type or storage class In file included from /usr/src/bin/csh/../../contrib/tcsh/sh.h:1304, from /usr/src/bin/csh/../../contrib/tcsh/gethost.c:33: /usr/src/bin/csh/../../contrib/tcsh/sh.decls.h:45: error: syntax error before "pintr" /usr/src/bin/csh/../../contrib/tcsh/sh.decls.h:45: warning: data definition has no type or storage class /usr/src/bin/csh/../../contrib/tcsh/sh.decls.h:314: error: syntax error before "pchild" /usr/src/bin/csh/../../contrib/tcsh/sh.decls.h:314: warning: data definition has no type or storage class *** Error code 1 Stop in /usr/src/bin/csh. *** Error code 1 From owner-freebsd-current@FreeBSD.ORG Sat Jul 21 04:57:22 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9AB6F16A418 for ; Sat, 21 Jul 2007 04:57:22 +0000 (UTC) (envelope-from thierry@herbelot.com) Received: from smtp4-g19.free.fr (smtp4-g19.free.fr [212.27.42.30]) by mx1.freebsd.org (Postfix) with ESMTP id 2D39713C465 for ; Sat, 21 Jul 2007 04:57:21 +0000 (UTC) (envelope-from thierry@herbelot.com) Received: from herbelot.dyndns.org (bne75-4-82-227-159-103.fbx.proxad.net [82.227.159.103]) by smtp4-g19.free.fr (Postfix) with ESMTP id 79CB46E05A for ; Sat, 21 Jul 2007 06:57:20 +0200 (CEST) Received: from diversion.herbelot.nom (diversion.herbelot.nom [192.168.2.6]) by herbelot.dyndns.org (8.14.0/8.14.0) with ESMTP id l6L4vHWm012498 for ; Sat, 21 Jul 2007 06:57:18 +0200 (CEST) From: Thierry Herbelot To: freebsd-current@freebsd.org Date: Sat, 21 Jul 2007 06:57:09 +0200 User-Agent: KMail/1.9.7 X-Warning: Windows can lose your files X-Op-Sys: Le FriBi de la mort qui tue X-Org: TfH&Co X-MailScanner: Found to be clean MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200707210657.11159.thierry@herbelot.com> Subject: panic with ZFS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: thierry@herbelot.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jul 2007 04:57:22 -0000 Hello, with a recent -current -built yesterday), I just got a panic while rebuilding -j4 the world and portupgrading firefox. it was during the "cleandir" phase of make buildworld : ===> gnu/usr.bin/groff/font/devascii (cleandir) ===> sbin/rcorder (cleandir) ===> lib/libpam/modules/pam_tacplus (cleandir) ===> gnu/usr.bin/groff/font/devcp1047 (cleandir) ===> sbin/reboot (cleandir) Read from remote host cur: Operation timed out Connection to cur closed. machine% the machine is pretty much memory limited (only 320 MB of RAM), with two CPUs, running a straight GENERIC kernel, including WITNESS and INVARIANTS. all filesystems except / are stored in a mirrored tank (specifically, src and obj are in two separate zfs filesystems). # ident /boot/kernel/kernel | grep uma_core $FreeBSD: src/sys/vm/uma_core.c,v 1.147 2007/05/31 22:52:14 attilio Exp $ # ident /boot/kernel/kernel | grep uipc_sockbuf $FreeBSD: src/sys/kern/uipc_sockbuf.c,v 1.171 2007/05/31 11:51:22 rwatson Exp $ TfH the panic message is : panic: System call unlink returning with 1 locks held cpuid = 0 KDB: enter: panic [thread pid 42789 tid 100102 ] Stopped at kdb_enter+0x32: leave db> where Tracing pid 42789 tid 100102 td 0xc2ce3200 kdb_enter(c0a92bc5,0,c0ac0a31,d5457c8c,0,...) at kdb_enter+0x32 panic(c0ac0a31,c0a98f5c,1,c0a98f5c,c0b3f030,...) at panic+0x124 syscall(d5457d38) at syscall+0x46e Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (0, FreeBSD ELF32, nosys), eip = 0x28145c23, esp = 0xbfbfe75c, ebp = 0xbfbfe788 --- db> show alllocks Process 42787 (rm) thread 0xc70a0400 (100173) exclusive sleep mutex 16 (UMA zone) r = 0 (0xc1474708) locked @ /tank/files1/src/sys/vm/uma_core.c:2257 Process 22309 (sshd) thread 0xc50b1c00 (100153) exclusive sx so_rcv_sx r = 0 (0xc30753a4) locked @ /tank/files1/src/sys/kern/uipc_sockbuf.c:145 Process 22241 (sshd) thread 0xc36c9c00 (100145) exclusive sx so_rcv_sx r = 0 (0xc6b523a4) locked @ /tank/files1/src/sys/kern/uipc_sockbuf.c:145 Process 22186 (sshd) thread 0xc36c8400 (100125) exclusive sx so_rcv_sx r = 0 (0xc26ddb60) locked @ /tank/files1/src/sys/kern/uipc_sockbuf.c:145 db> ps pid ppid pgrp uid state wmesg wchan cmd 42789 42788 39442 0 R+ CPU 0 rm 42788 42785 39442 0 S+ wait 0xc70662ac sh 42787 42786 39442 0 R+ CPU 1 rm 42786 42784 39442 0 S+ wait 0xc4186558 sh 42785 42739 39442 0 S+ select 0xc0bf42fc make 42784 41484 39442 0 S+ select 0xc0bf42fc make 42779 42589 39442 0 S+ zfs:(&zi 0xc3a44218 make 42767 42765 34732 0 S+ piperd 0xc36e418c as 42766 42765 34732 0 S+ zfs:(&zi 0xc3acbce0 cc1 42765 40226 34732 0 S+ wait 0xc36ca000 cc 42739 42734 39442 0 S+ wait 0xc3bdd2ac sh 42734 42691 39442 0 S+ select 0xc0bf42fc make 42728 0 0 0 SL vgeom:io 0xc4df2d48 [vdev:worker ad2s2d] 42727 0 0 0 SL vgeom:io 0xc3a18108 [vdev:worker ad0s2d] 42691 42685 39442 0 S+ wait 0xc4e67804 sh 42685 41228 39442 0 S+ select 0xc0bf42fc make 42649 42648 39442 0 S+ zfs:(&zi 0xc3b19890 rm 42648 42557 39442 0 S+ wait 0xc3420000 sh 42589 42586 39442 0 S+ wait 0xc36c7ab0 sh 42586 42585 39442 0 S+ select 0xc0bf42fc make 42585 42582 39442 0 S+ wait 0xc2ce0000 sh 42582 40683 39442 0 S+ select 0xc0bf42fc make 42557 42555 39442 0 S+ select 0xc0bf42fc make 42555 42551 39442 0 S+ wait 0xc2872804 sh 42551 42550 39442 0 S+ select 0xc0bf42fc make 42550 42543 39442 0 S+ wait 0xc2673804 sh 42543 42542 39442 0 S+ select 0xc0bf42fc make 42542 40666 39442 0 S+ wait 0xc294c000 sh 41484 41452 39442 0 S+ wait 0xc3c1dab0 sh 41452 41449 39442 0 S+ select 0xc0bf42fc make 41449 40666 39442 0 S+ wait 0xc70c3000 sh 41228 41226 39442 0 S+ wait 0xc4e672ac sh 41226 41002 39442 0 S+ select 0xc0bf42fc make 41002 40997 39442 0 S+ wait 0xc2679558 sh 40997 40996 39442 0 S+ select 0xc0bf42fc make 40996 40666 39442 0 S+ wait 0xc3b6a804 sh 40683 40678 39442 0 S+ wait 0xc54332ac sh 40678 40674 39442 0 S+ select 0xc0bf42fc make 40674 40666 39442 0 S+ wait 0xc3b69558 sh 40666 40665 39442 0 S+ select 0xc0bf42fc make 40665 39551 39442 0 S+ wait 0xc2ce0804 sh 40226 40224 34732 0 S+ wait 0xc36ca558 gmake 40224 40211 34732 0 S+ wait 0xc33d1ab0 sh 40211 39329 34732 0 S+ wait 0xc7066ab0 gmake 39551 39549 39442 0 S+ select 0xc0bf42fc make 39549 39442 39442 0 S+ wait 0xc4181804 sh 39442 22261 39442 0 S+ select 0xc0bf42fc make 39329 39326 34732 0 S+ wait 0xc2cdb2ac sh 39326 39070 34732 0 S+ wait 0xc33d1558 gmake 39070 39069 34732 0 S+ wait 0xc26cd000 gmake 39069 34732 34732 0 S+ wait 0xc2cdc000 sh 34732 34731 34732 0 Ss+ wait 0xc3420558 make 34731 22289 22289 0 S+ select 0xc0bf42fc script 22397 22318 22397 1001 S+ nanslp 0xc0ba76e4 zpool 22318 22312 22318 1001 Ss+ pause 0xc2cdc5b8 csh 22312 22309 22309 1001 S select 0xc0bf42fc sshd 22309 22170 22309 0 Ss sbwait 0xc30753d4 sshd 22289 22280 22289 0 S+ wait 0xc70c3804 initial thread 22280 22279 22280 0 S+ pause 0xc4920864 csh 22279 22244 22279 1001 S+ wait 0xc49202ac su 22261 22260 22261 0 S+ pause 0xc36c730c csh 22260 22245 22260 1001 S+ wait 0xc2cdc804 su 22245 22240 22245 1001 Ss+ pause 0xc36c5b10 csh 22244 22243 22244 1001 Ss+ pause 0xc36c6b10 csh 22243 22241 22241 1001 S select 0xc0bf42fc sshd 22241 22170 22241 0 Ss sbwait 0xc6b523d4 sshd 22240 22186 22186 1001 S select 0xc0bf42fc sshd 22239 1 22239 0 Ss+ ttyin 0xc258f410 getty 22238 1 22238 0 Ss+ ttyin 0xc258d810 getty 22237 1 22237 0 Ss+ ttyin 0xc258b010 getty 22236 1 22236 0 Ss+ ttyin 0xc258b410 getty 22235 1 22235 0 Ss+ ttyin 0xc258b810 getty 22234 1 22234 0 Ss+ ttyin 0xc258bc10 getty 22233 1 22233 0 Ss+ ttyin 0xc258c010 getty 22232 1 22232 0 Ss+ ttyin 0xc258c410 getty 22231 1 22231 0 Ss+ ttyin 0xc258c810 getty 22188 1 22188 0 Ss nanslp 0xc0ba76e4 cron 22186 22170 22186 0 Ss sbwait 0xc26ddb90 sshd 22180 1 22180 25 Ss pause 0xc417c30c sendmail 22176 1 22176 0 Ss select 0xc0bf42fc sendmail 22170 1 22170 0 Ss select 0xc0bf42fc sshd 22152 1 22152 0 Ss select 0xc0bf42fc ntpd 22048 1 22048 0 Ss select 0xc0bf42fc syslogd 21980 1 21980 0 Ss select 0xc0bf42fc devd 21697 1 21697 0 Ss pause 0xc4920b10 adjkerntz 133 0 0 0 SL zfs:(&tx 0xc2ad072c [txg_thread_enter] 132 0 0 0 SL zfs:(&zi 0xc3537ab8 [txg_thread_enter] 131 0 0 0 SL zfs:(&tx 0xc2ad071c [txg_thread_enter] 128 0 0 0 SL zfs:(&tq 0xc27c811c [spa_zio_intr_5] 127 0 0 0 SL zfs:(&tq 0xc27c811c [spa_zio_intr_5] 126 0 0 0 SL zfs:(&tq 0xc27c81e8 [spa_zio_issue_5] 125 0 0 0 SL zfs:(&tq 0xc27c81e8 [spa_zio_issue_5] 124 0 0 0 SL zfs:(&tq 0xc27c82b4 [spa_zio_intr_4] 123 0 0 0 SL zfs:(&tq 0xc27c82b4 [spa_zio_intr_4] 122 0 0 0 SL zfs:(&tq 0xc27c8380 [spa_zio_issue_4] 121 0 0 0 SL zfs:(&tq 0xc27c8380 [spa_zio_issue_4] 120 0 0 0 SL zfs:(&tq 0xc27c844c [spa_zio_intr_3] 119 0 0 0 SL zfs:(&tq 0xc27c844c [spa_zio_intr_3] 118 0 0 0 SL zfs:(&tq 0xc27c8518 [spa_zio_issue_3] 117 0 0 0 SL zfs:(&tq 0xc27c8518 [spa_zio_issue_3] 116 0 0 0 SL zfs:(&tq 0xc27c85e4 [spa_zio_intr_2] 115 0 0 0 SL zfs:(&tq 0xc27c85e4 [spa_zio_intr_2] 114 0 0 0 SL zfs:(&tq 0xc27c86b0 [spa_zio_issue_2] 113 0 0 0 SL zfs:(&tq 0xc27c86b0 [spa_zio_issue_2] 112 0 0 0 SL zfs:(&tq 0xc27c877c [spa_zio_intr_1] 111 0 0 0 SL zfs:(&tq 0xc27c877c [spa_zio_intr_1] 110 0 0 0 SL zfs:(&tq 0xc27c7d10 [spa_zio_issue_1] 109 0 0 0 SL zfs:(&tq 0xc27c7d10 [spa_zio_issue_1] 108 0 0 0 SL zfs:(&tq 0xc27c7ddc [spa_zio_intr_0] 107 0 0 0 SL zfs:(&tq 0xc27c7ddc [spa_zio_intr_0] 106 0 0 0 SL zfs:(&tq 0xc27c7ea8 [spa_zio_issue_0] 105 0 0 0 SL zfs:(&tq 0xc27c7ea8 [spa_zio_issue_0] 77 0 0 0 SL zfs:(&ar 0xc2788dcc [arc_reclaim_thread] 75 0 0 0 SL zfs:(&tq 0xc27c8050 [system_taskq] 74 0 0 0 SL zfs:(&tq 0xc27c8050 [system_taskq] 46 0 0 0 SL - 0xc0ba7514 [schedcpu] 45 0 0 0 SL sdflush 0xc0bfffe4 [softdepflush] 44 0 0 0 SL vlruwt 0xc2676558 [vnlru] 43 0 0 0 SL syncer 0xc0ba750c [syncer] 42 0 0 0 SL psleep 0xc0bf47a4 [bufdaemon] 41 0 0 0 SL pgzero 0xc0c00ab8 [pagezero] 40 0 0 0 SL psleep 0xc0c007d4 [vmdaemon] 39 0 0 0 SL psleep 0xc0c0079c [pagedaemon] 9 0 0 0 SL waiting_ 0xc0bf6508 [sctp_iterator] 38 0 0 0 WL [irq5: pcm0] 37 0 0 0 WL [swi0: sio] 36 0 0 0 WL [irq7: ppc0] 8 0 0 0 SL - 0xc255a63c [fdc0] 35 0 0 0 WL [irq12: psm0] 34 0 0 0 WL [irq1: atkbd0] 33 0 0 0 SL usbevt 0xc2510210 [usb4] 32 0 0 0 WL [irq18: ehci0++] 31 0 0 0 SL usbevt 0xc2548210 [usb3] 30 0 0 0 WL [irq17: ohci2] 29 0 0 0 SL usbevt 0xc254f210 [usb2] 28 0 0 0 WL [irq16: ohci1] 27 0 0 0 SL usbevt 0xc2544210 [usb1] 26 0 0 0 SL usbtsk 0xc0ba4df4 [usbtask-dr] 25 0 0 0 SL usbtsk 0xc0ba4de0 [usbtask-hc] 24 0 0 0 SL usbevt 0xc2525210 [usb0] 23 0 0 0 WL [irq19: dc0 uhci0+] 22 0 0 0 WL [irq15: ata1] 21 0 0 0 WL [irq14: ata0] 20 0 0 0 WL [swi5: +] 19 0 0 0 WL [swi2: cambio] 7 0 0 0 SL ccb_scan 0xc0b75ff4 [xpt_thrd] 6 0 0 0 SL - 0xc2447d00 [kqueue taskq] 18 0 0 0 WL [swi6: task queue] 17 0 0 0 WL [swi6: Giant taskq] 5 0 0 0 SL - 0xc2470080 [thread taskq] 16 0 0 0 SL - 0xc0ba7514 [yarrow] 4 0 0 0 SL - 0xc0ba558c [g_down] 3 0 0 0 SL - 0xc0ba5588 [g_up] 2 0 0 0 SL - 0xc0ba5580 [g_event] 15 0 0 0 WL [swi3: vm] 14 0 0 0 RL [swi4: clock sio] 13 0 0 0 WL [swi1: net] 12 0 0 0 RL [idle: cpu0] 11 0 0 0 RL [idle: cpu1] 1 0 1 0 SLs wait 0xc2449ab0 [init] 10 0 0 0 SL audit_wo 0xc0bffa54 [audit] 0 0 0 0 WLs [swapper] db> From owner-freebsd-current@FreeBSD.ORG Sat Jul 21 05:21:35 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4768C16A417 for ; Sat, 21 Jul 2007 05:21:35 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from heff.fud.org.nz (203-109-251-39.static.bliink.ihug.co.nz [203.109.251.39]) by mx1.freebsd.org (Postfix) with ESMTP id D6C2513C428 for ; Sat, 21 Jul 2007 05:21:34 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: by heff.fud.org.nz (Postfix, from userid 1001) id 33BAC1CC5D; Sat, 21 Jul 2007 17:21:33 +1200 (NZST) Date: Sat, 21 Jul 2007 17:21:33 +1200 From: Andrew Thompson To: Jeremie Le Hen Message-ID: <20070721052133.GB76674@heff.fud.org.nz> References: <20070616224703.GC63387@obiwan.tataz.chchile.org> <20070618100238.GD46910@heff.fud.org.nz> <200707160849.07376.jhb@freebsd.org> <20070720095721.GE56695@obiwan.tataz.chchile.org> <20070720232100.GA35292@obiwan.tataz.chchile.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070720232100.GA35292@obiwan.tataz.chchile.org> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: freebsd-current@freebsd.org Subject: Re: Cannot use iwi(4): "could not load firmware iwi_bss" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Jul 2007 05:21:35 -0000 On Sat, Jul 21, 2007 at 01:21:00AM +0200, Jeremie Le Hen wrote: > On Fri, Jul 20, 2007 at 11:57:21AM +0200, Jeremie Le Hen wrote: > > Thank you for replying :-). > > > > I'm indeed not using APIC (ISTR it was designed for SMP, I don't know > > what benefit I could get from it considering my laptop is UP). > > > > I stopped using ACPI a few months ago as it prevented psm(4) from > > working (albeit it ACPI+SMP doesn't exhibit the problem) (see [1]). > > > > What do you advice me to do? Do you need me to do some testing, > > enabling ACPI or something like that? I'm at work currently, I will > > only be able to do this in a couple of hour. > > Ok, I've tried with ACPI enabled and I confirm that iwi(4) can > successfully load its firmware in this case. Unfortunately psm(4) > doesn't work so this is not an option for me. Thanks for testing this and it at least rules out iwi as the problem, you may want to take this further on the acpi mailing list (or here). cheers, Andrew From owner-freebsd-current@FreeBSD.ORG Sat Jul 21 07:27:18 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 14C2616A419 for ; Sat, 21 Jul 2007 07:27:18 +0000 (UTC) (envelope-from mse_software@charter.net) Received: from que03.charter.net (que03.charter.net [209.225.8.191]) by mx1.freebsd.org (Postfix) with ESMTP id 99D3C13C428 for ; Sat, 21 Jul 2007 07:27:17 +0000 (UTC) (envelope-from mse_software@charter.net) Received: from aa03.charter.net ([10.20.200.155]) by mtao03.charter.net (InterMail vM.7.08.02.00 201-2186-121-20061213) with ESMTP id <20070721065525.CGIU1450.mtao03.charter.net@aa03.charter.net>; Sat, 21 Jul 2007 02:55:25 -0400 Received: from [192.168.10.101] (really [71.92.123.54]) by aa03.charter.net with ESMTP id <20070721065525.GBAV7864.aa03.charter.net@[192.168.10.101]>; Sat, 21 Jul 2007 02:55:25 -0400 From: "Michael S. Eubanks" To: freebsd-current@freebsd.org In-Reply-To: <20070720155839.GA2241@eschew.pusen.org> References: <20070716190441.GA19282@eschew.pusen.org> <20070716213425.GB19282@eschew.pusen.org> <20070716233600.GC19282@eschew.pusen.org> <18079.31350.366410.316438@grasshopper.cs.duke.edu> <20070720155839.GA2241@eschew.pusen.org> Content-Type: text/plain; charset=ISO-8859-1 Date: Fri, 20 Jul 2007 23:55:24 -0700 Message-Id: <1185000924.1082.44.camel@yak.mseubanks.net> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 8bit X-Chzlrs: 0 Cc: =?ISO-8859-1?Q?St=E5le?= Kristoffersen Subject: Re: Slow networkperformance in current? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mse_software@charter.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jul 2007 07:27:18 -0000 On Fri, 2007-07-20 at 17:58 +0200, Ståle Kristoffersen wrote: > On 2007-07-19 at 10:51, Andrew Gallatin wrote: > > > > Ståle Kristoffersen writes: > > > On 2007-07-16 at 15:53, Kip Macy wrote: > > > > Please post the config you are using. > > > > > > lrwxr-xr-x 1 root wheel 2B Apr 12 15:42 /etc/malloc.conf -> aj > > > > > > /etc/sysctl.conf: > > > vfs.vmiodirenable=1 > > > net.inet.tcp.delayed_ack=0 > > > net.inet.ip.forwarding=1 > > > net.inet.tcp.inflight.enable=0 > > > > > > (I have tried commenting out all those lines, no difference. > > > > You definately want to comment out at least net.inet.tcp.delayed_ack=0 > > Ok, didn't do much for the speed. > > > Try temporarily setting net.inet.tcp.sendbuf_auto=0 and > > net.inet.tcp.recvbuf_auto=0 and see if that changes anything. > > > > I've seen strange issues with IPv6 and the automatic buffer sizing, > > perhaps you're somehow running into the same thing with IPv4. > > No change in the speed. > What is the quality of the cabling? Can the cable be shortened or swapped for testing? -Michael S. Eubanks mse_software@charter.net From owner-freebsd-current@FreeBSD.ORG Sat Jul 21 09:22:10 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 44F1316A417 for ; Sat, 21 Jul 2007 09:22:10 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from heff.fud.org.nz (203-109-251-39.static.bliink.ihug.co.nz [203.109.251.39]) by mx1.freebsd.org (Postfix) with ESMTP id 0942813C46A for ; Sat, 21 Jul 2007 09:22:08 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: by heff.fud.org.nz (Postfix, from userid 1001) id B866C1CC58; Sat, 21 Jul 2007 21:22:07 +1200 (NZST) Date: Sat, 21 Jul 2007 21:22:07 +1200 From: Andrew Thompson To: Scot Hetzel Message-ID: <20070721092207.GC76674@heff.fud.org.nz> References: <790a9fff0707150332u2502a491s91f19d4303bf82a6@mail.gmail.com> <20070715110629.GI95956@heff.fud.org.nz> <790a9fff0707181607n7500b7feo190c58418e047de5@mail.gmail.com> <20070720001043.GD45010@heff.fud.org.nz> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="YiEDa0DAkWCtVeE4" Content-Disposition: inline In-Reply-To: <20070720001043.GD45010@heff.fud.org.nz> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: freebsd-current@freebsd.org Subject: Re: stopping ndis caused fatal trap 12 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Jul 2007 09:22:10 -0000 --YiEDa0DAkWCtVeE4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Jul 20, 2007 at 12:10:43PM +1200, Andrew Thompson wrote: > On Wed, Jul 18, 2007 at 06:07:37PM -0500, Scot Hetzel wrote: > > On 7/15/07, Andrew Thompson wrote: > > >On Sun, Jul 15, 2007 at 05:32:32AM -0500, Scot Hetzel wrote: > > >> hp010# uname -a > > >> FreeBSD hp010 7.0-CURRENT FreeBSD 7.0-CURRENT #0: Sat Jul 14 02:20:09 > > >> CDT 2007 root@hp010:/usr/src/7x/sys-p4/amd64/compile/GENERIC.debug > > >> amd64 > > >> > > >> I was testing wpa_supplicant at work, and couldn't get it to associate > > >> with the network (open, no encryption), and so I had hardcoded the > > >> network. When I went home and booted the system, it still had the > > >> hardcoded wireless network configured. I then did a netif stop ndis0, > > >> made the change to set ndis to "WPA DHCP", then when I used 'netif > > >> start ndis0', it didn't obtain an IP. So I performed an 'netif stop > > >> ndis0' and received the following panic: > > >> > > >So back to the ndis association problem. Did the card find the access > > >point? you can list the scan cache from 'ifconfig ndis0 list scan'. > > > > > > > ifconfig ndis0 scan ; ifconfig ndis0 list scan don't return with any > > results, but if I run wpa_cli, and do a scan and scan_results it lists > > the APs. > > Can you (and anyone else having ndis assosciate problems) please try > these two patches. > > ndis_scan9.diff applies in sys/dev/if_ndis, and scan_sta1.diff applies > in sys/net80211. I have kept them seperate as Sephe is due to commit > scan_sta1.diff shortly and may have already done so before you get to > test. Is anyone able to test this? I can not commit it until at least one person with the ndis issues can confirm it works. Sephe has committed his part so only the attached patch is needed. cheers, Andrew --YiEDa0DAkWCtVeE4 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="ndis_scan10.diff" Index: if_ndis.c =================================================================== RCS file: /home/ncvs/src/sys/dev/if_ndis/if_ndis.c,v retrieving revision 1.123 diff -u -p -r1.123 if_ndis.c --- if_ndis.c 12 Jul 2007 02:54:05 -0000 1.123 +++ if_ndis.c 21 Jul 2007 09:15:10 -0000 @@ -48,9 +48,7 @@ __FBSDID("$FreeBSD: src/sys/dev/if_ndis/ #include #include #include -#if __FreeBSD_version < 502113 #include -#endif #include #include @@ -89,8 +87,12 @@ __FBSDID("$FreeBSD: src/sys/dev/if_ndis/ #include #include +#define NDIS_DEBUG #ifdef NDIS_DEBUG -#define DPRINTF(x) printf x +#define DPRINTF(x) do { if (ndis_debug > 0) printf x; } while (0) +int ndis_debug = 0; +SYSCTL_INT(_debug, OID_AUTO, ndis, CTLFLAG_RW, &ndis_debug, 0, + "if_ndis debug level"); #else #define DPRINTF(x) #endif @@ -150,6 +152,8 @@ static int ndis_80211_ioctl_get (struct static int ndis_80211_ioctl_set (struct ifnet *, u_long, caddr_t); static int ndis_newstate (struct ieee80211com *, enum ieee80211_state, int); +static int ndis_nettype_chan (uint32_t); +static int ndis_nettype_mode (uint32_t); static void ndis_scan (void *, int); static void ndis_scan_results (struct ndis_softc *); static void ndis_scan_start (struct ieee80211com *); @@ -487,6 +491,32 @@ ndis_probe_offload(sc) return(0); } +static int +ndis_nettype_chan(uint32_t type) +{ + switch (type) { + case NDIS_80211_NETTYPE_11FH: return (IEEE80211_CHAN_FHSS); + case NDIS_80211_NETTYPE_11DS: return (IEEE80211_CHAN_B); + case NDIS_80211_NETTYPE_11OFDM5: return (IEEE80211_CHAN_A); + case NDIS_80211_NETTYPE_11OFDM24: return (IEEE80211_CHAN_G); + } + DPRINTF(("unknown channel nettype %d\n", type)); + return (IEEE80211_CHAN_B); /* Default to 11B chan */ +} + +static int +ndis_nettype_mode(uint32_t type) +{ + switch (type) { + case NDIS_80211_NETTYPE_11FH: return (IEEE80211_MODE_FH); + case NDIS_80211_NETTYPE_11DS: return (IEEE80211_MODE_11B); + case NDIS_80211_NETTYPE_11OFDM5: return (IEEE80211_MODE_11A); + case NDIS_80211_NETTYPE_11OFDM24: return (IEEE80211_MODE_11G); + } + DPRINTF(("unknown mode nettype %d\n", type)); + return (IEEE80211_MODE_AUTO); +} + /* * Attach the interface. Allocate softc structures, do ifmedia * setup and ethernet/BPF attach. @@ -500,7 +530,7 @@ ndis_attach(dev) driver_object *pdrv; device_object *pdo; struct ifnet *ifp = NULL; - int error = 0, len, bands = 0; + int error = 0, len, mode, bands = 0; int i; sc = device_get_softc(dev); @@ -737,26 +767,21 @@ ndis_attach(dev) } for (i = 0; i < ntl->ntl_items; i++) { - switch (ntl->ntl_type[i]) { - case NDIS_80211_NETTYPE_11FH: - case NDIS_80211_NETTYPE_11DS: - setbit(ic->ic_modecaps, IEEE80211_MODE_11B); - setbit(&bands, IEEE80211_MODE_11B); - break; - case NDIS_80211_NETTYPE_11OFDM5: - setbit(ic->ic_modecaps, IEEE80211_MODE_11A); - setbit(&bands, IEEE80211_MODE_11A); - break; - case NDIS_80211_NETTYPE_11OFDM24: - setbit(ic->ic_modecaps, IEEE80211_MODE_11G); - setbit(&bands, IEEE80211_MODE_11G); - break; - default: - break; - } + mode = ndis_nettype_mode(ntl->ntl_type[i]); + if (mode) { + setbit(ic->ic_modecaps, mode); + setbit(&bands, mode); + } else + device_printf(dev, "Unknown nettype %d\n", + ntl->ntl_type[i]); } free(ntl, M_DEVBUF); nonettypes: + /* Default to 11b channels if the card did not supply any */ + if (bands == 0) { + setbit(ic->ic_modecaps, IEEE80211_MODE_11B); + setbit(&bands, IEEE80211_MODE_11B); + } len = sizeof(rates); bzero((char *)&rates, len); r = ndis_get_info(sc, OID_802_11_SUPPORTED_RATES, @@ -989,6 +1014,8 @@ ndis_detach(dev) } else NDIS_UNLOCK(sc); + taskqueue_drain(sc->ndis_tq, &sc->ndis_scantask); + if (sc->ndis_tickitem != NULL) IoFreeWorkItem(sc->ndis_tickitem); if (sc->ndis_startitem != NULL) @@ -999,6 +1026,7 @@ ndis_detach(dev) IoFreeWorkItem(sc->ndis_inputitem); bus_generic_detach(dev); + ndis_unload_driver(sc); if (sc->ndis_irq) bus_release_resource(dev, SYS_RES_IRQ, 0, sc->ndis_irq); @@ -1032,8 +1060,6 @@ ndis_detach(dev) if (sc->ndis_txpool != NULL) NdisFreePacketPool(sc->ndis_txpool); - ndis_unload_driver(sc); - /* Destroy the PDO for this device. */ if (sc->ndis_iftype == PCIBus) @@ -2652,36 +2678,15 @@ ndis_getstate_80211(sc) if (!NDIS_INITIALIZED(sc)) return; - /* - * If we're associated, retrieve info on the current bssid. - */ - if ((rval = ndis_get_assoc(sc, &bs)) == 0) { - switch(bs->nwbx_nettype) { - case NDIS_80211_NETTYPE_11FH: - case NDIS_80211_NETTYPE_11DS: - ic->ic_curmode = IEEE80211_MODE_11B; - chanflag = IEEE80211_CHAN_B; - break; - case NDIS_80211_NETTYPE_11OFDM5: - ic->ic_curmode = IEEE80211_MODE_11A; - chanflag = IEEE80211_CHAN_A; - break; - case NDIS_80211_NETTYPE_11OFDM24: - ic->ic_curmode = IEEE80211_MODE_11G; - chanflag = IEEE80211_CHAN_G; - break; - default: - device_printf(sc->ndis_dev, - "unknown nettype %d\n", arg); - chanflag = 0; - break; - } - IEEE80211_ADDR_COPY(ic->ic_bss->ni_bssid, bs->nwbx_macaddr); - } else + if ((rval = ndis_get_assoc(sc, &bs)) != 0) return; - /* Get SSID from current association info. */ + /* We're associated, retrieve info on the current bssid. */ + ic->ic_curmode = ndis_nettype_mode(bs->nwbx_nettype); + chanflag = ndis_nettype_chan(bs->nwbx_nettype); + IEEE80211_ADDR_COPY(ic->ic_bss->ni_bssid, bs->nwbx_macaddr); + /* Get SSID from current association info. */ bcopy(bs->nwbx_ssid.ns_ssid, ic->ic_bss->ni_essid, bs->nwbx_ssid.ns_ssidlen); ic->ic_bss->ni_esslen = bs->nwbx_ssid.ns_ssidlen; @@ -2739,7 +2744,6 @@ ndis_getstate_80211(sc) if (ic->ic_curchan == NULL) ic->ic_curchan = &ic->ic_channels[0]; ic->ic_bss->ni_chan = ic->ic_curchan; - ic->ic_des_chan = ic->ic_curchan; ic->ic_bsschan = ic->ic_curchan; free(bs, M_TEMP); @@ -3502,12 +3506,42 @@ ndis_scan(void *arg, int npending) { struct ndis_softc *sc = arg; struct ieee80211com *ic = (void *)&sc->ic; + struct ieee80211_scan_state *ss = ic->ic_scan; + ndis_80211_ssid ssid; int error, len; + if (!NDIS_INITIALIZED(sc)) { + DPRINTF(("%s: scan aborted\n", __func__)); + ieee80211_cancel_scan(ic); + return; + } + + if (ss->ss_nssid != 0) { + /* Perform a directed scan */ + len = sizeof(ssid); + bzero((char *)&ssid, len); + ssid.ns_ssidlen = ss->ss_ssid[0].len; + bcopy(ss->ss_ssid[0].ssid, ssid.ns_ssid, ssid.ns_ssidlen); + + error = ndis_set_info(sc, OID_802_11_SSID, &ssid, &len); + if (error) + DPRINTF(("%s: set ESSID failed\n", __func__)); + } + len = 0; error = ndis_set_info(sc, OID_802_11_BSSID_LIST_SCAN, NULL, &len); - tsleep(&error, PPAUSE|PCATCH, "ssidscan", hz * 2); + if (error) { + DPRINTF(("%s: scan command failed\n", __func__)); + ieee80211_cancel_scan(ic); + return; + } + + tsleep(&error, PPAUSE|PCATCH, "ssidscan", hz * 3); + if (!NDIS_INITIALIZED(sc)) + /* The interface was downed while we were sleeping */ + return; + ndis_scan_results(sc); ieee80211_scan_done(ic); } @@ -3521,7 +3555,7 @@ ndis_scan_results(struct ndis_softc *sc) struct ieee80211_scanparams sp; struct ieee80211_frame wh; int i, j; - int error, len, rssi, noise; + int error, len, rssi, noise, freq, chanflag; static long rstamp; uint8_t ssid[2+IEEE80211_NWID_LEN]; uint8_t rates[2+IEEE80211_RATE_MAXSIZE]; @@ -3535,10 +3569,12 @@ ndis_scan_results(struct ndis_softc *sc) bl = malloc(len, M_DEVBUF, M_NOWAIT | M_ZERO); error = ndis_get_info(sc, OID_802_11_BSSID_LIST, bl, &len); if (error) { + DPRINTF(("%s: failed to read\n", __func__)); free(bl, M_DEVBUF); return;; } + DPRINTF(("%s: %d results\n", __func__, bl->nblx_items)); rstamp++; wb = &bl->nblx_bssid[0]; for (i = 0; i < bl->nblx_items; i++) { @@ -3546,7 +3582,7 @@ ndis_scan_results(struct ndis_softc *sc) memcpy(wh.i_addr2, wb->nwbx_macaddr, sizeof(wh.i_addr2)); memcpy(wh.i_addr3, wb->nwbx_macaddr, sizeof(wh.i_addr3)); - rssi = (wb->nwbx_rssi - noise) / (-32 - noise) * 100; + rssi = 100 * (wb->nwbx_rssi - noise) / (-32 - noise); rssi = max(0, min(rssi, 100)); /* limit 0 <= rssi <= 100 */ if (wb->nwbx_privacy) sp.capinfo |= IEEE80211_CAPINFO_PRIVACY; @@ -3573,11 +3609,10 @@ ndis_scan_results(struct ndis_softc *sc) wb->nwbx_ssid.ns_ssidlen); sp.ssid[1] = wb->nwbx_ssid.ns_ssidlen; - sp.bchan = ieee80211_mhz2ieee( - wb->nwbx_config.nc_dsconfig / 1000, 0); - sp.curchan = ieee80211_find_channel(ic, - ieee80211_ieee2mhz(sp.bchan, IEEE80211_CHAN_B), - IEEE80211_CHAN_B); + chanflag = ndis_nettype_chan(wb->nwbx_nettype); + freq = wb->nwbx_config.nc_dsconfig / 1000; + sp.bchan = ieee80211_mhz2ieee(freq, chanflag); + sp.curchan = ieee80211_find_channel(ic, freq, chanflag); if (sp.curchan == NULL) sp.curchan = &ic->ic_channels[0]; @@ -3607,9 +3642,13 @@ ndis_scan_results(struct ndis_softc *sc) } } done: + DPRINTF(("scan: bssid %s chan %dMHz (%d/%d) rssi %d\n", + ether_sprintf(wb->nwbx_macaddr), freq, sp.bchan, chanflag, + rssi)); ieee80211_add_scan(ic, &sp, &wh, 0, rssi, noise, rstamp); wb = (ndis_wlan_bssid_ex *)((char *)wb + wb->nwbx_len); } + free(bl, M_DEVBUF); } static void --YiEDa0DAkWCtVeE4-- From owner-freebsd-current@FreeBSD.ORG Sat Jul 21 09:55:39 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D6A0816A417; Sat, 21 Jul 2007 09:55:39 +0000 (UTC) (envelope-from vova@sw.ru) Received: from vbook.fbsd.ru (swsoft-mipt-nat.sw.ru [195.214.233.10]) by mx1.freebsd.org (Postfix) with ESMTP id 8ECFB13C4A6; Sat, 21 Jul 2007 09:55:39 +0000 (UTC) (envelope-from vova@sw.ru) Received: from vova by vbook.fbsd.ru with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ICBgT-0000SZ-LV; Sat, 21 Jul 2007 13:55:33 +0400 From: Vladimir Grebenschikov To: Mark Hobden In-Reply-To: References: <1184929509.1415.10.camel@localhost> <1184946870.1356.2.camel@localhost> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable Organization: SWsoft Date: Sat, 21 Jul 2007 13:55:32 +0400 Message-Id: <1185011732.1420.4.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 FreeBSD GNOME Team Port Sender: Vladimir Grebenschikov Cc: freebsd-current@freebsd.org, freebsd-usb@freebsd.org Subject: Re: uhidev(4) update - USB HID driver level for devices with multiple report ids X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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: Sat, 21 Jul 2007 09:55:39 -0000 =F7 =D3=C2, 21/07/2007 =D7 01:55 +0100, Mark Hobden =D0=C9=DB=C5=D4: > Thanks for helping me track this down, I had managed to leave > out that that ums, ukbd & uhid depend on usb as well as uhidev > (this was previously in a macro). This upset trying to kldload the > modules. >=20 > I have uploaded a new patch over the old one. People only need > this update though if they do not have 'device usb' in their kernel > config file. >=20 > http://www.terinea.co.uk/~mark/patches/uhidev-7-current-p2.diff Hm, a bit better, but ... If I boot with connect mice and disconnected keyboard - everything goes right. I can connect keyboard after boot and it works, mice works also. But If I've boot with connected USB keyboard - system panics: Fatal trap 12: page fault while in kernel mode Stopped ar usbd_clear_endpoint_stall_async+0xb: movl 0x3(%ebx), %esi db> tr ehci_waitintr ehci_device_intr_start ehci_device_intr_transfer usbd_start_transfer bus_dmap_load usbd_transfer usbd_open_pipe_intr uhidev_open ukbd_enable_intr ukbd_init ukbd_attach device_attach uhidev_attach device_attach usb_new_device uhub_explore uhub_explore usb_attach ehci_pci_attach device_attach bus_generic_attach ... Sorry, manually retyped back-trace db> panic just refuses to write dump. Side question - what is "right" way to setup dump device for kernel boot ? http://freebsd-man.page2go2.com/man8/loader_8.html loader's dumpdev - looks not working. > Mark --=20 Vladimir B. Grebenschikov vova@fbsd.ru From owner-freebsd-current@FreeBSD.ORG Sat Jul 21 10:19:48 2007 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B925216A419 for ; Sat, 21 Jul 2007 10:19:48 +0000 (UTC) (envelope-from bsd@kuehlbox.de) Received: from samael.qmail-ldap.de (mail.kuehlbox.de [62.159.47.22]) by mx1.freebsd.org (Postfix) with ESMTP id 2033913C45D for ; Sat, 21 Jul 2007 10:19:47 +0000 (UTC) (envelope-from bsd@kuehlbox.de) Received: (qmail 5443 invoked from network); 21 Jul 2007 10:19:46 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlbox.de; b=JoJ3H8QM9ZUYjdcUsOmGLMfRCg99iSV7VvsHOhWChQhhvLoZ21BBo5D5qno0wR+qO6XCNAOLXoavKJ9iw4RpKKM3482k2UP0n4nKwJp7846AsdPJAcXHidW+dszcndW8 ; Received: from unknown (HELO [192.168.200.128]) (bsd@kuehlbox.de@[82.135.93.20]) (envelope-sender ) by samael.qmail-ldap.de (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 21 Jul 2007 10:19:46 -0000 Message-ID: <46A1DF0B.6070705@kuehlbox.de> Date: Sat, 21 Jul 2007 12:25:15 +0200 From: Teufel User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: current@FreeBSD.org References: <20070720213211.GA7262@saturn.kn-bremen.de> In-Reply-To: <20070720213211.GA7262@saturn.kn-bremen.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: kqemu and sched_lock, please test port update X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Jul 2007 10:19:48 -0000 Hi Juergen, just cvsuped the kernel and applied the kqemu-kmod below. Previously, I had immediately the sched lock 1 panic with the ULE 3.0 and this patch seems to fix the problem. The win2k3 image is now running for about 2 hours in kernel and user mode! Thanks! Hope this helps you. x86 kernel. Greetings, Stephan *kqemu status:* QEMU 0.9.0 monitor - type 'help' for more information (qemu) info kqemu kqemu support: enabled for user and kernel code (qemu *CPU:* CPU: Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz (2404.13-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6f6 Stepping = 6 Features=0xbfebfbff Features2=0xe3bd AMD Features=0x20000000 AMD Features2=0x1 Cores per package: 2 real memory = 2146828288 (2047 MB) avail memory = 2091282432 (1994 MB) Juergen Lock wrote: > I just noticed this, and came up with the update below. I still don't > have a -current box so I need you to test this before I commit it... > > Thanx, > Juergen > > Index: Makefile > =================================================================== > RCS file: /home/pcvs/ports/emulators/kqemu-kmod/Makefile,v > retrieving revision 1.19 > diff -u -r1.19 Makefile > --- Makefile 14 Jul 2007 17:48:56 -0000 1.19 > +++ Makefile 20 Jul 2007 21:21:14 -0000 > @@ -7,7 +7,7 @@ > > PORTNAME= kqemu > PORTVERSION= 1.3.0.p11 > -PORTREVISION= 1 > +PORTREVISION= 2 > CATEGORIES= emulators kld > MASTER_SITES= http://fabrice.bellard.free.fr/qemu/ \ > http://qemu.org/ \ > Index: files/patch-kqemu-freebsd.c > =================================================================== > RCS file: /home/pcvs/ports/emulators/kqemu-kmod/files/patch-kqemu-freebsd.c,v > retrieving revision 1.5 > diff -u -r1.5 patch-kqemu-freebsd.c > --- files/patch-kqemu-freebsd.c 6 Feb 2007 20:46:29 -0000 1.5 > +++ files/patch-kqemu-freebsd.c 20 Jul 2007 21:17:33 -0000 > @@ -1,5 +1,23 @@ > Index: kqemu-freebsd.c > -@@ -321,6 +321,9 @@ > +@@ -208,9 +208,17 @@ > + int CDECL kqemu_schedule(void) > + { > + /* kqemu_log("kqemu_schedule\n"); */ > ++#if __FreeBSD_version < 700044 > + mtx_lock_spin(&sched_lock); > + mi_switch(SW_VOL, NULL); > + mtx_unlock_spin(&sched_lock); > ++#else > ++ /* -current no longer uses sched_lock */ > ++ struct thread *td = curthread; > ++ thread_lock(td); > ++ mi_switch(SW_VOL, NULL); > ++ thread_unlock(td); > ++#endif > + return SIGPENDING(curthread); > + } > + #endif > +@@ -320,6 +328,9 @@ > #if __FreeBSD_version >= 500000 > dev->si_drv1 = NULL; > TAILQ_REMOVE(&kqemuhead, ks, kqemu_ent); > @@ -9,4 +27,3 @@ > destroy_dev(dev); > #endif > free(ks, M_KQEMU); > - > _______________________________________________ > 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 Jul 21 10:39:17 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 02D3E16A419 for ; Sat, 21 Jul 2007 10:39:17 +0000 (UTC) (envelope-from yraffah@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.178]) by mx1.freebsd.org (Postfix) with ESMTP id CD59D13C442 for ; Sat, 21 Jul 2007 10:39:16 +0000 (UTC) (envelope-from yraffah@gmail.com) Received: by wa-out-1112.google.com with SMTP id j37so1397193waf for ; Sat, 21 Jul 2007 03:39:15 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=htwKjo9bhUxAtSLpoDl3kMin+5SmbigUXpKgCKAl5cdVlaLkuo6ZX0b/yf5vnTY1ReKQrXOZuIHW0POdM1G9vF7ynS1y1gtaHhTz3lGRSWuXQK4fKcfJ7GcYKOJNbsQ023JZ5Antc8C6ec8on3cFiecrMHcwkbYsJzqFXFGuwdA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=dbH6k3J2wjULchNjH7zMNIKKc8B5bVRh2YXTWjFcdsNCaK1o9neReakficM331qHw3yMD8YbZBBsNEcqyJN2LM+yLOf9APeVO1CjCP3BObdCAH4FqNBbRJa/nM8oYlLXEilBIWojRc3ioGOq2Q/cEGHk9kMI0VcA27Bsm1Ems1s= Received: by 10.114.126.1 with SMTP id y1mr1300634wac.1185012858085; Sat, 21 Jul 2007 03:14:18 -0700 (PDT) Received: by 10.114.66.15 with HTTP; Sat, 21 Jul 2007 03:14:18 -0700 (PDT) Message-ID: Date: Sat, 21 Jul 2007 13:14:18 +0300 From: "Yousef Raffah" To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Is this an Xorg problem? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jul 2007 10:39:17 -0000 Howdy, I'm running on 7.0-CURRENT #1: Sun Jul 15 11:33:57 AST 2007 with the GENERIC kernel. I had removed all my ports in order to have a fresh install. Everything was successfully installed after that, including xorg 7.2. However, when I try to start my X session, the screen flickers as if it was starting then suddenly brakes and shuts down, returning me to my prompt printing the following on the console: mskc0: Uncorrectable PCI Express error Also if I try Xorg -configure to create a new xorg.conf for me, the machine freezes and does not respond to anything when I run it with X -config /root/xorg.conf.new (I don't run X as root, this is just to test the new config file), I can't even ssh nor ping the box! Hard booting is the only way to get it back :( Sorry if it isn't CURRENT related but kindly let me know and I will post it to the xorg mailing list. My appologies. Not sure if I'm supposed to attach the X.org.log file but here is the content of it: X Window System Version 7.2.0 Release Date: 22 January 2007 X Protocol Version 11, Revision 0, Release 7.2 Build Operating System: FreeBSD 7.0-CURRENT i386 Current Operating System: FreeBSD redevil 7.0-CURRENT FreeBSD 7.0-CURRENT #1: Sun Jul 15 11:33:57 AST 200 7 root@redevil:/usr/obj/usr/src/sys/GENERIC i386 Build Date: 19 July 2007 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Module Loader present Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/Xorg.0.log", Time: Sat Jul 21 11:27:09 2007 (==) Using config file: "/etc/X11/xorg.conf" (==) ServerLayout "X.org Configured" (**) |-->Screen "Screen0" (0) (**) | |-->Monitor "Monitor0" (**) | |-->Device "Card0" (**) |-->Input Device "Mouse0" (**) |-->Input Device "Keyboard0" (**) FontPath set to: /usr/local/lib/X11/fonts/misc/, /usr/local/lib/X11/fonts/TTF/, /usr/local/lib/X11/fonts/OTF, /usr/local/lib/X11/fonts/Type1/, /usr/local/lib/X11/fonts/100dpi/, /usr/local/lib/X11/fonts/75dpi/ (**) RgbPath set to "/usr/local/share/X11/rgb" (**) ModulePath set to "/usr/local/lib/xorg/modules" (II) Loader magic: 0x81c9340 (II) Module ABI versions: X.Org ANSI C Emulation: 0.3 X.Org Video Driver: 1.1 X.Org XInput driver : 0.7 X.Org Server Extension : 0.3 X.Org Font Renderer : 0.5 (II) Loader running on freebsd (II) LoadModule: "pcidata" (II) Loading /usr/local/lib/xorg/modules//libpcidata.so (II) Module pcidata: vendor="X.Org Foundation" compiled for 7.2.0, module version = 1.0.0 ABI class: X.Org Video Driver, version 1.1 (--) Using syscons driver with X support (version 2.0) (--) using VT number 9 (II) PCI: Probing config type using method 1 (II) PCI: Config type is 1 (II) PCI: stages = 0x03, oldVal1 = 0x00000000, mode1Res1 = 0x80000000 (II) PCI: PCI scan (all values are in hex) (II) PCI: 00:00:0: chip 8086,2590 card 1179,ff10 rev 03 class 06,00,00 hdr 00 (II) PCI: 00:01:0: chip 8086,2591 card 0000,0000 rev 03 class 06,04,00 hdr 01 (II) PCI: 00:1c:0: chip 8086,2660 card 0000,0000 rev 04 class 06,04,00 hdr 81 (II) PCI: 00:1c:1: chip 8086,2662 card 0000,0000 rev 04 class 06,04,00 hdr 81 (II) PCI: 00:1d:0: chip 8086,2658 card 1179,ff10 rev 04 class 0c,03,00 hdr 80 (II) PCI: 00:1d:1: chip 8086,2659 card 1179,ff10 rev 04 class 0c,03,00 hdr 00 (II) PCI: 00:1d:2: chip 8086,265a card 1179,ff10 rev 04 class 0c,03,00 hdr 00 (II) PCI: 00:1d:3: chip 8086,265b card 1179,ff10 rev 04 class 0c,03,00 hdr 00 (II) PCI: 00:1d:7: chip 8086,265c card 1179,ff10 rev 04 class 0c,03,20 hdr 00 (II) PCI: 00:1e:0: chip 8086,2448 card 0000,0000 rev d4 class 06,04,01 hdr 81 (II) PCI: 00:1e:2: chip 8086,266e card 1179,ff10 rev 04 class 04,01,00 hdr 00 (II) PCI: 00:1e:3: chip 8086,266d card 1179,0001 rev 04 class 07,03,00 hdr 00 (II) PCI: 00:1f:0: chip 8086,2641 card 1179,ff10 rev 04 class 06,01,00 hdr 80 (II) PCI: 00:1f:2: chip 8086,2653 card 1179,ff10 rev 04 class 01,01,80 hdr 00 (II) PCI: 01:00:0: chip 1002,5460 card 1179,ff10 rev 00 class 03,00,00 hdr 00 (II) PCI: 02:00:0: chip 11ab,4362 card 1179,ff10 rev 15 class 02,00,00 hdr 00 (II) PCI: 06:04:0: chip 8086,4220 card 8086,2741 rev 05 class 02,80,00 hdr 00 (II) PCI: 06:06:0: chip 104c,8031 card fffc,ffff rev 00 class 06,07,00 hdr 82 (II) PCI: 06:06:2: chip 104c,8032 card 1179,ff10 rev 00 class 0c,00,10 hdr 80 (II) PCI: 06:06:3: chip 104c,8033 card 1179,ff10 rev 00 class 01,80,00 hdr 80 (II) PCI: 06:06:4: chip 104c,8034 card 1179,ff10 rev 00 class 08,05,00 hdr 80 (II) PCI: End of PCI scan (II) Intel Bridge workaround enabled (II) Host-to-PCI bridge: (II) Bus 0: bridge is at (0:0:0), (0,0,7), BCTRL: 0x0008 (VGA_EN is set) (II) Bus 0 I/O range: [0] -1 0 0x00000000 - 0x0000ffff (0x10000) IX[B] (II) Bus 0 non-prefetchable memory range: [0] -1 0 0x00000000 - 0xffffffff (0x0) MX[B] (II) Bus 0 prefetchable memory range: [0] -1 0 0x00000000 - 0xffffffff (0x0) MX[B] (II) PCI-to-PCI bridge: (II) Bus 1: bridge is at (0:1:0), (0,1,1), BCTRL: 0x000a (VGA_EN is set) (II) Bus 1 I/O range: [0] -1 0 0x0000c000 - 0x0000dfff (0x2000) IX[B] (II) Bus 1 non-prefetchable memory range: [0] -1 0 0xc0000000 - 0xcfffffff (0x10000000) MX[B] (II) Bus 1 prefetchable memory range: [0] -1 0 0x90000000 - 0x9fffffff (0x10000000) MX[B] (II) PCI-to-PCI bridge: (II) Bus 2: bridge is at (0:28:0), (0,2,2), BCTRL: 0x0002 (VGA_EN is cleared) (II) Bus 2 I/O range: [0] -1 0 0x0000a000 - 0x0000bfff (0x2000) IX[B] (II) Bus 2 non-prefetchable memory range: [0] -1 0 0xbc000000 - 0xbfffffff (0x4000000) MX[B] (II) Bus 2 prefetchable memory range: [0] -1 0 0x8c000000 - 0x8fffffff (0x4000000) MX[B] (II) PCI-to-PCI bridge: (II) Bus 3: bridge is at (0:28:1), (0,3,3), BCTRL: 0x0002 (VGA_EN is cleared) (II) Bus 3 I/O range: [0] -1 0 0x00008000 - 0x00009fff (0x2000) IX[B] (II) Bus 3 non-prefetchable memory range: [0] -1 0 0xb8000000 - 0xbbffffff (0x4000000) MX[B] (II) Bus 3 prefetchable memory range: [0] -1 0 0x88000000 - 0x8bffffff (0x4000000) MX[B] (II) Subtractive PCI-to-PCI bridge: (II) Bus 6: bridge is at (0:30:0), (0,6,6), BCTRL: 0x0006 (VGA_EN is cleared) (II) Bus 6 I/O range: [0] -1 0 0x00006000 - 0x000060ff (0x100) IX[B] [1] -1 0 0x00006400 - 0x000064ff (0x100) IX[B] [2] -1 0 0x00006800 - 0x000068ff (0x100) IX[B] [3] -1 0 0x00006c00 - 0x00006cff (0x100) IX[B] [4] -1 0 0x00007000 - 0x000070ff (0x100) IX[B] [5] -1 0 0x00007400 - 0x000074ff (0x100) IX[B] [6] -1 0 0x00007800 - 0x000078ff (0x100) IX[B] [7] -1 0 0x00007c00 - 0x00007cff (0x100) IX[B] (II) Bus 6 non-prefetchable memory range: [0] -1 0 0xb0000000 - 0xb7ffffff (0x8000000) MX[B] (II) Bus 6 prefetchable memory range: [0] -1 0 0x80000000 - 0x87ffffff (0x8000000) MX[B] (II) PCI-to-ISA bridge: (II) Bus -1: bridge is at (0:31:0), (0,-1,-1), BCTRL: 0x0008 (VGA_EN is set) (II) PCI-to-CardBus bridge: (II) Bus 7: bridge is at (6:6:0), (6,7,8), BCTRL: 0x0740 (VGA_EN is cleared) (--) PCI:*(1:0:0) ATI Technologies Inc M22 [Radeon Mobility M300] rev 0, Mem @ 0x90000000/27, 0xc0000000/ 16, I/O @ 0xc000/8 (II) Addressable bus resource ranges are [0] -1 0 0x00000000 - 0xffffffff (0x0) MX[B] [1] -1 0 0x00000000 - 0x0000ffff (0x10000) IX[B] (II) OS-reported resource ranges: [0] -1 0 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B) [1] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [2] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [3] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [4] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [5] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] (II) Active PCI resource ranges: [0] -1 0 0xb000a200 - 0xb000a3ff (0x200) MX[B]E [1] -1 0 0xb000a100 - 0xb000a1ff (0x100) MX[B]E [2] -1 0 0xb000a000 - 0xb000bfff (0x2000) MX[B]E [3] -1 0 0xb0008000 - 0xb000ffff (0x8000) MX[B]E [4] -1 0 0xb0004000 - 0xb0007fff (0x4000) MX[B]E [5] -1 0 0xb0000000 - 0xbfffffff (0x10000000) MX[B]E [6] -1 0 0xb000b000 - 0xb000bfff (0x1000) MX[B]E [7] -1 0 0xbc000000 - 0xbfffffff (0x4000000) MX[B]E [8] -1 0 0xd0000200 - 0xd00003ff (0x200) MX[B]E [9] -1 0 0xd0000000 - 0xdfffffff (0x10000000) MX[B]E [10] -1 0 0xf4000000 - 0xf7ffffff (0x4000000) MX[B]E [11] -1 0 0xc0000000 - 0xc000ffff (0x10000) MX[B](B) [12] -1 0 0x90000000 - 0x97ffffff (0x8000000) MX[B](B) [13] -1 0 0x0000a000 - 0x0000a0ff (0x100) IX[B]E [14] -1 0 0x00001100 - 0x000011ff (0x100) IX[B]E [15] -1 0 0x0000e300 - 0x0000e3ff (0x100) IX[B]E [16] -1 0 0x0000e200 - 0x0000e2ff (0x100) IX[B]E [17] -1 0 0x0000e100 - 0x0000e1ff (0x100) IX[B]E [18] -1 0 0x0000e000 - 0x0000e0ff (0x100) IX[B]E [19] -1 0 0x00001260 - 0x0000127f (0x20) IX[B]E [20] -1 0 0x00001240 - 0x0000127f (0x40) IX[B]E [21] -1 0 0x00001220 - 0x0000123f (0x20) IX[B]E [22] -1 0 0x00001200 - 0x000012ff (0x100) IX[B]E [23] -1 0 0x0000c000 - 0x0000c0ff (0x100) IX[B](B) (II) PCI Memory resource overlap reduced 0xb000a000 from 0xb000bfff to 0xb000a0ff (II) PCI Memory resource overlap reduced 0xb0008000 from 0xb000ffff to 0xb0009fff (II) PCI Memory resource overlap reduced 0xb0000000 from 0xbfffffff to 0xb0003fff (II) PCI Memory resource overlap reduced 0xd0000000 from 0xdfffffff to 0xd00001ff (II) PCI I/O resource overlap reduced 0x00001240 from 0x0000127f to 0x0000125f (II) PCI I/O resource overlap reduced 0x00001200 from 0x000012ff to 0x0000121f (II) Active PCI resource ranges after removing overlaps: [0] -1 0 0xb000a200 - 0xb000a3ff (0x200) MX[B]E [1] -1 0 0xb000a100 - 0xb000a1ff (0x100) MX[B]E [2] -1 0 0xb000a000 - 0xb000a0ff (0x100) MX[B]E [3] -1 0 0xb0008000 - 0xb0009fff (0x2000) MX[B]E [4] -1 0 0xb0004000 - 0xb0007fff (0x4000) MX[B]E [5] -1 0 0xb0000000 - 0xb0003fff (0x4000) MX[B]E [6] -1 0 0xb000b000 - 0xb000bfff (0x1000) MX[B]E [7] -1 0 0xbc000000 - 0xbfffffff (0x4000000) MX[B]E [8] -1 0 0xd0000200 - 0xd00003ff (0x200) MX[B]E [9] -1 0 0xd0000000 - 0xd00001ff (0x200) MX[B]E [10] -1 0 0xf4000000 - 0xf7ffffff (0x4000000) MX[B]E [11] -1 0 0xc0000000 - 0xc000ffff (0x10000) MX[B](B) [12] -1 0 0x90000000 - 0x97ffffff (0x8000000) MX[B](B) [13] -1 0 0x0000a000 - 0x0000a0ff (0x100) IX[B]E [14] -1 0 0x00001100 - 0x000011ff (0x100) IX[B]E [15] -1 0 0x0000e300 - 0x0000e3ff (0x100) IX[B]E [16] -1 0 0x0000e200 - 0x0000e2ff (0x100) IX[B]E [17] -1 0 0x0000e100 - 0x0000e1ff (0x100) IX[B]E [18] -1 0 0x0000e000 - 0x0000e0ff (0x100) IX[B]E [19] -1 0 0x00001260 - 0x0000127f (0x20) IX[B]E [20] -1 0 0x00001240 - 0x0000125f (0x20) IX[B]E [21] -1 0 0x00001220 - 0x0000123f (0x20) IX[B]E [22] -1 0 0x00001200 - 0x0000121f (0x20) IX[B]E [23] -1 0 0x0000c000 - 0x0000c0ff (0x100) IX[B](B) (II) OS-reported resource ranges after removing overlaps with PCI: [0] -1 0 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B) [1] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [2] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [3] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [4] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [5] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] (II) All system resource ranges: [0] -1 0 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B) [1] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [2] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [3] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [4] -1 0 0xb000a200 - 0xb000a3ff (0x200) MX[B]E [5] -1 0 0xb000a100 - 0xb000a1ff (0x100) MX[B]E [6] -1 0 0xb000a000 - 0xb000a0ff (0x100) MX[B]E [7] -1 0 0xb0008000 - 0xb0009fff (0x2000) MX[B]E [8] -1 0 0xb0004000 - 0xb0007fff (0x4000) MX[B]E [9] -1 0 0xb0000000 - 0xb0003fff (0x4000) MX[B]E [10] -1 0 0xb000b000 - 0xb000bfff (0x1000) MX[B]E [11] -1 0 0xbc000000 - 0xbfffffff (0x4000000) MX[B]E [12] -1 0 0xd0000200 - 0xd00003ff (0x200) MX[B]E [13] -1 0 0xd0000000 - 0xd00001ff (0x200) MX[B]E [14] -1 0 0xf4000000 - 0xf7ffffff (0x4000000) MX[B]E [15] -1 0 0xc0000000 - 0xc000ffff (0x10000) MX[B](B) [16] -1 0 0x90000000 - 0x97ffffff (0x8000000) MX[B](B) [17] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [18] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] [19] -1 0 0x0000a000 - 0x0000a0ff (0x100) IX[B]E [20] -1 0 0x00001100 - 0x000011ff (0x100) IX[B]E [21] -1 0 0x0000e300 - 0x0000e3ff (0x100) IX[B]E [22] -1 0 0x0000e200 - 0x0000e2ff (0x100) IX[B]E [23] -1 0 0x0000e100 - 0x0000e1ff (0x100) IX[B]E [24] -1 0 0x0000e000 - 0x0000e0ff (0x100) IX[B]E [25] -1 0 0x00001260 - 0x0000127f (0x20) IX[B]E [26] -1 0 0x00001240 - 0x0000125f (0x20) IX[B]E [27] -1 0 0x00001220 - 0x0000123f (0x20) IX[B]E [28] -1 0 0x00001200 - 0x0000121f (0x20) IX[B]E [29] -1 0 0x0000c000 - 0x0000c0ff (0x100) IX[B](B) (II) LoadModule: "extmod" (II) Loading /usr/local/lib/xorg/modules/extensions//libextmod.so (II) Module extmod: vendor="X.Org Foundation" compiled for 7.2.0, module version = 1.0.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 0.3 (II) Loading extension SHAPE (II) Loading extension MIT-SUNDRY-NONSTANDARD (II) Loading extension BIG-REQUESTS (II) Loading extension SYNC (II) Loading extension MIT-SCREEN-SAVER (II) Loading extension XC-MISC (II) Loading extension XFree86-VidModeExtension (II) Loading extension XFree86-Misc (II) Loading extension XFree86-DGA (II) Loading extension DPMS (II) Loading extension TOG-CUP (II) Loading extension Extended-Visual-Information (II) Loading extension XVideo (II) Loading extension XVideo-MotionCompensation (II) Loading extension X-Resource (II) LoadModule: "record" (II) Loading /usr/local/lib/xorg/modules/extensions//librecord.so (II) Module record: vendor="X.Org Foundation" compiled for 7.2.0, module version = 1.13.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 0.3 (II) Loading extension RECORD (II) LoadModule: "dbe" (II) Loading /usr/local/lib/xorg/modules/extensions//libdbe.so (II) Module dbe: vendor="X.Org Foundation" compiled for 7.2.0, module version = 1.0.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 0.3 (II) Loading extension DOUBLE-BUFFER (II) LoadModule: "glx" (II) Loading /usr/local/lib/xorg/modules/extensions//libglx.so (II) Module glx: vendor="X.Org Foundation" compiled for 7.2.0, module version = 1.0.0 ABI class: X.Org Server Extension, version 0.3 (==) AIGLX disabled (II) Loading extension GLX (II) LoadModule: "xtrap" (II) Loading /usr/local/lib/xorg/modules/extensions//libxtrap.so (II) Module xtrap: vendor="X.Org Foundation" compiled for 7.2.0, module version = 1.0.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 0.3 (II) Loading extension DEC-XTRAP (II) LoadModule: "freetype" (II) Loading /usr/local/lib/xorg/modules//fonts/libfreetype.so (II) Module freetype: vendor="X.Org Foundation & the After X-TT Project" compiled for 7.2.0, module version = 2.1.0 Module class: X.Org Font Renderer ABI class: X.Org Font Renderer, version 0.5 (II) Loading font FreeType (II) LoadModule: "type1" (II) Loading /usr/local/lib/xorg/modules//fonts/libtype1.so (II) Module type1: vendor="X.Org Foundation" compiled for 7.2.0, module version = 1.0.2 Module class: X.Org Font Renderer ABI class: X.Org Font Renderer, version 0.5 (II) Loading font Type1 (II) LoadModule: "ati" (II) Loading /usr/local/lib/xorg/modules/drivers//ati_drv.so (II) Module ati: vendor="X.Org Foundation" compiled for 7.2.0, module version = 6.6.3 Module class: X.Org Video Driver ABI class: X.Org Video Driver, version 1.1 (II) LoadModule: "mouse" (II) Loading /usr/local/lib/xorg/modules/input//mouse_drv.so (II) Module mouse: vendor="X.Org Foundation" compiled for 7.2.0, module version = 1.1.1 Module class: X.Org XInput Driver ABI class: X.Org XInput driver, version 0.7 (II) LoadModule: "kbd" (II) Loading /usr/local/lib/xorg/modules/input//kbd_drv.so (II) Module kbd: vendor="X.Org Foundation" compiled for 7.2.0, module version = 1.1.0 Module class: X.Org XInput Driver ABI class: X.Org XInput driver, version 0.7 (II) ATI: ATI driver (version 6.6.3) for chipsets: ati, ativga (II) R128: Driver for ATI Rage 128 chipsets: ATI Rage 128 Mobility M3 LE (PCI), ATI Rage 128 Mobility M3 LF (AGP), ATI Rage 128 Mobility M4 MF (AGP), ATI Rage 128 Mobility M4 ML (AGP), ATI Rage 128 Pro GL PA (PCI/AGP), ATI Rage 128 Pro GL PB (PCI/AGP), ATI Rage 128 Pro GL PC (PCI/AGP), ATI Rage 128 Pro GL PD (PCI), ATI Rage 128 Pro GL PE (PCI/AGP), ATI Rage 128 Pro GL PF (AGP), ATI Rage 128 Pro VR PG (PCI/AGP), ATI Rage 128 Pro VR PH (PCI/AGP), ATI Rage 128 Pro VR PI (PCI/AGP), ATI Rage 128 Pro VR PJ (PCI/AGP), ATI Rage 128 Pro VR PK (PCI/AGP), ATI Rage 128 Pro VR PL (PCI/AGP), ATI Rage 128 Pro VR PM (PCI/AGP), ATI Rage 128 Pro VR PN (PCI/AGP), ATI Rage 128 Pro VR PO (PCI/AGP), ATI Rage 128 Pro VR PP (PCI), ATI Rage 128 Pro VR PQ (PCI/AGP), ATI Rage 128 Pro VR PR (PCI), ATI Rage 128 Pro VR PS (PCI/AGP), ATI Rage 128 Pro VR PT (PCI/AGP), ATI Rage 128 Pro VR PU (PCI/AGP), ATI Rage 128 Pro VR PV (PCI/AGP), ATI Rage 128 Pro VR PW (PCI/AGP), ATI Rage 128 Pro VR PX (PCI/AGP), ATI Rage 128 GL RE (PCI), ATI Rage 128 GL RF (AGP), ATI Rage 128 RG (AGP), ATI Rage 128 VR RK (PCI), ATI Rage 128 VR RL (AGP), ATI Rage 128 4X SE (PCI/AGP), ATI Rage 128 4X SF (PCI/AGP), ATI Rage 128 4X SG (PCI/AGP), ATI Rage 128 4X SH (PCI/AGP), ATI Rage 128 4X SK (PCI/AGP), ATI Rage 128 4X SL (PCI/AGP), ATI Rage 128 4X SM (AGP), ATI Rage 128 4X SN (PCI/AGP), ATI Rage 128 Pro ULTRA TF (AGP), ATI Rage 128 Pro ULTRA TL (AGP), ATI Rage 128 Pro ULTRA TR (AGP), ATI Rage 128 Pro ULTRA TS (AGP?), ATI Rage 128 Pro ULTRA TT (AGP?), ATI Rage 128 Pro ULTRA TU (AGP?) (II) RADEON: Driver for ATI Radeon chipsets: ATI Radeon QD (AGP), ATI Radeon QE (AGP), ATI Radeon QF (AGP), ATI Radeon QG (AGP), ATI Radeon VE/7000 QY (AGP/PCI), ATI Radeon VE/7000 QZ (AGP/PCI), ATI ES1000 515E (PCI), ATI ES1000 5969 (PCI), ATI Radeon Mobility M7 LW (AGP), ATI Mobility FireGL 7800 M7 LX (AGP), ATI Radeon Mobility M6 LY (AGP), ATI Radeon Mobility M6 LZ (AGP), ATI Radeon IGP320 (A3) 4136, ATI Radeon IGP320M (U1) 4336, ATI Radeon IGP330/340/350 (A4) 4137, ATI Radeon IGP330M/340M/350M (U2) 4337, ATI Radeon 7000 IGP (A4+) 4237, ATI Radeon Mobility 7000 IGP 4437, ATI FireGL 8700/8800 QH (AGP), ATI Radeon 8500 QL (AGP), ATI Radeon 9100 QM (AGP), ATI Radeon 8500 AIW BB (AGP), ATI Radeon 8500 AIW BC (AGP), ATI Radeon 7500 QW (AGP/PCI), ATI Radeon 7500 QX (AGP/PCI), ATI Radeon 9000/PRO If (AGP/PCI), ATI Radeon 9000 Ig (AGP/PCI), ATI FireGL Mobility 9000 (M9) Ld (AGP), ATI Radeon Mobility 9000 (M9) Lf (AGP), ATI Radeon Mobility 9000 (M9) Lg (AGP), ATI Radeon 9100 IGP (A5) 5834, ATI Radeon Mobility 9100 IGP (U3) 5835, ATI Radeon 9100 PRO IGP 7834, ATI Radeon Mobility 9200 IGP 7835, ATI Radeon 9250 5960 (AGP), ATI Radeon 9200 5961 (AGP), ATI Radeon 9200 5962 (AGP), ATI Radeon 9200SE 5964 (AGP), ATI FireMV 2200 (PCI), ATI Radeon Mobility 9200 (M9+) 5C61 (AGP), ATI Radeon Mobility 9200 (M9+) 5C63 (AGP), ATI Radeon 9500 AD (AGP), ATI Radeon 9500 AE (AGP), ATI Radeon 9600TX AF (AGP), ATI FireGL Z1 AG (AGP), ATI Radeon 9700 Pro ND (AGP), ATI Radeon 9700/9500Pro NE (AGP), ATI Radeon 9600TX NF (AGP), ATI FireGL X1 NG (AGP), ATI Radeon 9600 AP (AGP), ATI Radeon 9600SE AQ (AGP), ATI Radeon 9600XT AR (AGP), ATI Radeon 9600 AS (AGP), ATI FireGL T2 AT (AGP), ATI FireGL RV360 AV (AGP), ATI Radeon Mobility 9600/9700 (M10/M11) NP (AGP), ATI Radeon Mobility 9600 (M10) NQ (AGP), ATI Radeon Mobility 9600 (M11) NR (AGP), ATI Radeon Mobility 9600 (M10) NS (AGP), ATI FireGL Mobility T2 (M10) NT (AGP), ATI FireGL Mobility T2e (M11) NV (AGP), ATI Radeon 9650, ATI Radeon 9800SE AH (AGP), ATI Radeon 9800 AI (AGP), ATI Radeon 9800 AJ (AGP), ATI FireGL X2 AK (AGP), ATI Radeon 9800PRO NH (AGP), ATI Radeon 9800 NI (AGP), ATI FireGL X2 NK (AGP), ATI Radeon 9800XT NJ (AGP), ATI Radeon X600 (RV380) 3E50 (PCIE), ATI FireGL V3200 (RV380) 3E54 (PCIE), ATI Radeon Mobility X600 (M24) 3150 (PCIE), ATI Radeon Mobility X300 (M24) 3152 (PCIE), ATI FireGL M24 GL 3154 (PCIE), ATI Radeon X300 (RV370) 5B60 (PCIE), ATI Radeon X600 (RV370) 5B62 (PCIE), ATI Radeon X550 (RV370) 5B63 (PCIE), ATI FireGL V3100 (RV370) 5B64 (PCIE), ATI FireMV 2200 PCIE (RV370) 5B65 (PCIE), ATI Radeon Mobility X300 (M22) 5460 (PCIE), ATI Radeon Mobility X600 SE (M24C) 5462 (PCIE), ATI FireGL M22 GL 5464 (PCIE), ATI Radeon XPRESS 200 5A41 (PCIE), ATI Radeon XPRESS 200M 5A42 (PCIE), ATI Radeon XPRESS 200 5A61 (PCIE), ATI Radeon XPRESS 200M 5A62 (PCIE), ATI Radeon XPRESS 200 5954 (PCIE), ATI Radeon XPRESS 200M 5955 (PCIE), ATI Radeon XPRESS 200 5974 (PCIE), ATI Radeon XPRESS 200M 5975 (PCIE), ATI FireGL V5000 (RV410) (PCIE), ATI Mobility FireGL V5000 (M26) (PCIE), ATI Mobility FireGL V5000 (M26) (PCIE), ATI Mobility Radeon X700 XL (M26) (PCIE), ATI Mobility Radeon X700 (M26) (PCIE), ATI Mobility Radeon X700 (M26) (PCIE), ATI Radeon X700 PRO (RV410) (PCIE), ATI Radeon X700 XT (RV410) (PCIE), ATI Radeon X700 (RV410) (PCIE), ATI Radeon X700 SE (RV410) (PCIE), ATI Radeon X700 SE (RV410) (PCIE), ATI Radeon X800 (R420) JH (AGP), ATI Radeon X800PRO (R420) JI (AGP), ATI Radeon X800SE (R420) JJ (AGP), ATI Radeon X800 (R420) JK (AGP), ATI Radeon X800 (R420) JL (AGP), ATI FireGL X3 (R420) JM (AGP), ATI Radeon Mobility 9800 (M18) JN (AGP), ATI Radeon X800XT (R420) JP (AGP), ATI Radeon X800 SE (R420) (AGP), ATI Radeon AIW X800 VE (R420) JT (AGP), ATI Radeon X800 (R423) UH (PCIE), ATI Radeon X800PRO (R423) UI (PCIE), ATI Radeon X800LE (R423) UJ (PCIE), ATI Radeon X800SE (R423) UK (PCIE), ATI FireGL V5100 (R423) UQ (PCIE), ATI FireGL unknown (R423) UR (PCIE), ATI FireGL unknown (R423) UT (PCIE), ATI Radeon X800XT (R423) 5D57 (PCIE), ATI FireGL V7100 (R423) (PCIE), ATI Mobility FireGL V5100 (M28) (PCIE), ATI Mobility Radeon X800 (M28) (PCIE), ATI Mobility Radeon X800 XT (M28) (PCIE), ATI Radeon X800 (R430) (PCIE), ATI Radeon X800 XL (R430) (PCIE), ATI Radeon X800 SE (R430) (PCIE), ATI Radeon X800 XTP (R430) (PCIE), ATI Radeon X850 5D4C (PCIE), ATI unknown Radeon / FireGL (R480) 5D50 (PCIE), ATI Radeon X850 SE (R480) (PCIE), ATI Radeon X850 PRO (R480) (PCIE), ATI Radeon X850 XT (R480) (PCIE), ATI Radeon X850 XT PE (R480) (PCIE), ATI Radeon X850 PRO (R480) (AGP), ATI Radeon X850 SE (R480) (AGP), ATI Radeon X850 XT (R480) (AGP), ATI Radeon X850 XT PE (R480) (AGP) (II) Primary Device is: PCI 01:00:0 (II) ATI: Candidate "Device" section "Card0". (--) Chipset ATI Radeon Mobility X300 (M22) 5460 (PCIE) found (II) resource ranges after xf86ClaimFixedResources() call: [0] -1 0 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B) [1] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [2] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [3] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [4] -1 0 0xb000a200 - 0xb000a3ff (0x200) MX[B]E [5] -1 0 0xb000a100 - 0xb000a1ff (0x100) MX[B]E [6] -1 0 0xb000a000 - 0xb000a0ff (0x100) MX[B]E [7] -1 0 0xb0008000 - 0xb0009fff (0x2000) MX[B]E [8] -1 0 0xb0004000 - 0xb0007fff (0x4000) MX[B]E [9] -1 0 0xb0000000 - 0xb0003fff (0x4000) MX[B]E [10] -1 0 0xb000b000 - 0xb000bfff (0x1000) MX[B]E [11] -1 0 0xbc000000 - 0xbfffffff (0x4000000) MX[B]E [12] -1 0 0xd0000200 - 0xd00003ff (0x200) MX[B]E [13] -1 0 0xd0000000 - 0xd00001ff (0x200) MX[B]E [14] -1 0 0xf4000000 - 0xf7ffffff (0x4000000) MX[B]E [15] -1 0 0xc0000000 - 0xc000ffff (0x10000) MX[B](B) [16] -1 0 0x90000000 - 0x97ffffff (0x8000000) MX[B](B) [17] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [18] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] [19] -1 0 0x0000a000 - 0x0000a0ff (0x100) IX[B]E [20] -1 0 0x00001100 - 0x000011ff (0x100) IX[B]E [21] -1 0 0x0000e300 - 0x0000e3ff (0x100) IX[B]E [22] -1 0 0x0000e200 - 0x0000e2ff (0x100) IX[B]E [23] -1 0 0x0000e100 - 0x0000e1ff (0x100) IX[B]E [24] -1 0 0x0000e000 - 0x0000e0ff (0x100) IX[B]E [25] -1 0 0x00001260 - 0x0000127f (0x20) IX[B]E [26] -1 0 0x00001240 - 0x0000125f (0x20) IX[B]E [27] -1 0 0x00001220 - 0x0000123f (0x20) IX[B]E [28] -1 0 0x00001200 - 0x0000121f (0x20) IX[B]E [29] -1 0 0x0000c000 - 0x0000c0ff (0x100) IX[B](B) (II) Loading sub module "radeon" (II) LoadModule: "radeon" (II) Loading /usr/local/lib/xorg/modules/drivers//radeon_drv.so (II) Module radeon: vendor="X.Org Foundation" compiled for 7.2.0, module version = 4.2.0 Module class: X.Org Video Driver ABI class: X.Org Video Driver, version 1.1 (II) resource ranges after probing: [0] -1 0 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B) [1] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [2] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [3] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [4] -1 0 0xb000a200 - 0xb000a3ff (0x200) MX[B]E [5] -1 0 0xb000a100 - 0xb000a1ff (0x100) MX[B]E [6] -1 0 0xb000a000 - 0xb000a0ff (0x100) MX[B]E [7] -1 0 0xb0008000 - 0xb0009fff (0x2000) MX[B]E [8] -1 0 0xb0004000 - 0xb0007fff (0x4000) MX[B]E [9] -1 0 0xb0000000 - 0xb0003fff (0x4000) MX[B]E [10] -1 0 0xb000b000 - 0xb000bfff (0x1000) MX[B]E [11] -1 0 0xbc000000 - 0xbfffffff (0x4000000) MX[B]E [12] -1 0 0xd0000200 - 0xd00003ff (0x200) MX[B]E [13] -1 0 0xd0000000 - 0xd00001ff (0x200) MX[B]E [14] -1 0 0xf4000000 - 0xf7ffffff (0x4000000) MX[B]E [15] -1 0 0xc0000000 - 0xc000ffff (0x10000) MX[B](B) [16] -1 0 0x90000000 - 0x97ffffff (0x8000000) MX[B](B) [17] 0 0 0x000a0000 - 0x000affff (0x10000) MS[B] [18] 0 0 0x000b0000 - 0x000b7fff (0x8000) MS[B] [19] 0 0 0x000b8000 - 0x000bffff (0x8000) MS[B] [20] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [21] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] [22] -1 0 0x0000a000 - 0x0000a0ff (0x100) IX[B]E [23] -1 0 0x00001100 - 0x000011ff (0x100) IX[B]E [24] -1 0 0x0000e300 - 0x0000e3ff (0x100) IX[B]E [25] -1 0 0x0000e200 - 0x0000e2ff (0x100) IX[B]E [26] -1 0 0x0000e100 - 0x0000e1ff (0x100) IX[B]E [27] -1 0 0x0000e000 - 0x0000e0ff (0x100) IX[B]E [28] -1 0 0x00001260 - 0x0000127f (0x20) IX[B]E [29] -1 0 0x00001240 - 0x0000125f (0x20) IX[B]E [30] -1 0 0x00001220 - 0x0000123f (0x20) IX[B]E [31] -1 0 0x00001200 - 0x0000121f (0x20) IX[B]E [32] -1 0 0x0000c000 - 0x0000c0ff (0x100) IX[B](B) [33] 0 0 0x000003b0 - 0x000003bb (0xc) IS[B] [34] 0 0 0x000003c0 - 0x000003df (0x20) IS[B] (II) Setting vga for screen 0. (**) RADEON(0): RADEONPreInit (II) RADEON(0): MMIO registers at 0xc0000000: size 64KB (==) RADEON(0): Write-combining range (0xc0000000,0x10000) was already clear (II) RADEON(0): PCI bus 1 card 0 func 0 (==) RADEON(0): Depth 24, (==) framebuffer bpp 32 (II) RADEON(0): Pixel depth = 24 bits stored in 4 bytes (32 bpp pixmaps) (==) RADEON(0): Default visual is TrueColor (II) Loading sub module "vgahw" (II) LoadModule: "vgahw" (II) Loading /usr/local/lib/xorg/modules//libvgahw.so (II) Module vgahw: vendor="X.Org Foundation" compiled for 7.2.0, module version = 0.1.0 ABI class: X.Org Video Driver, version 1.1 (II) RADEON(0): vgaHWGetIOBase: hwp->IOBase is 0x03d0, hwp->PIOOffset is 0x0000 (==) RADEON(0): RGB weight 888 (II) RADEON(0): Using 8 bits per RGB (8 bit DAC) (==) RADEON(0): X server will not keep DPI constant for all screen sizes (II) Loading sub module "int10" (II) LoadModule: "int10" (II) Loading /usr/local/lib/xorg/modules//libint10.so (II) Module int10: vendor="X.Org Foundation" compiled for 7.2.0, module version = 1.0.0 ABI class: X.Org Video Driver, version 1.1 (II) RADEON(0): initializing int10 (==) RADEON(0): Write-combining range (0xa0000,0x20000) was already clear (==) RADEON(0): Write-combining range (0xc0000,0x40000) was already clear (II) RADEON(0): Primary V_BIOS segment is: 0xc000 (==) RADEON(0): Write-combining range (0x0,0x1000) was already clear (--) RADEON(0): Chipset: "ATI Radeon Mobility X300 (M22) 5460 (PCIE)" (ChipID = 0x5460) (--) RADEON(0): Linear framebuffer at 0x90000000 (II) RADEON(0): PCIE card detected (II) RADEON(0): Generation 2 PCI interface, using max accessible memory (II) RADEON(0): Detected total video RAM=131072K, accessible=131072K (PCI BAR=131072K) (--) RADEON(0): Mapped VideoRAM: 131072 kByte (128 bit DDR SDRAM) (II) RADEON(0): Color tiling enabled by default (II) Loading sub module "ddc" (II) LoadModule: "ddc" (II) Loading /usr/local/lib/xorg/modules//libddc.so (II) Module ddc: vendor="X.Org Foundation" compiled for 7.2.0, module version = 1.0.0 ABI class: X.Org Video Driver, version 1.1 (II) Loading sub module "i2c" (II) LoadModule: "i2c" (II) Loading /usr/local/lib/xorg/modules//libi2c.so (II) Module i2c: vendor="X.Org Foundation" compiled for 7.2.0, module version = 1.2.0 ABI class: X.Org Video Driver, version 1.1 (II) RADEON(0): I2C bus "DDC" initialized. (II) RADEON(0): Legacy BIOS detected (II) RADEON(0): Connector0: DDCType-2, DACType-0, TMDSType-0, ConnectorType-3 (II) RADEON(0): Connector1: DDCType-3, DACType-0, TMDSType--1, ConnectorType-2 (II) RADEON(0): I2C device "DDC:ddc2" registered at address 0xA0. (II) RADEON(0): I2C device "DDC:ddc2" removed. (II) RADEON(0): I2C device "DDC:ddc2" registered at address 0xA0. (II) RADEON(0): I2C device "DDC:ddc2" removed. (II) RADEON(0): I2C device "DDC:ddc2" registered at address 0xA0. (II) RADEON(0): I2C device "DDC:ddc2" removed. (II) RADEON(0): DDC Type: 2, Detected Type: 0 (II) RADEON(0): I2C device "DDC:ddc2" registered at address 0xA0. (II) RADEON(0): I2C device "DDC:ddc2" removed. (II) RADEON(0): I2C device "DDC:ddc2" registered at address 0xA0. (II) RADEON(0): I2C device "DDC:ddc2" removed. (II) RADEON(0): I2C device "DDC:ddc2" registered at address 0xA0. (II) RADEON(0): I2C device "DDC:ddc2" removed. (II) RADEON(0): DDC Type: 3, Detected Type: 0 (II) RADEON(0): (II) RADEON(0): Primary: Monitor -- LVDS Connector -- DVI-I DAC Type -- Primary TMDS Type -- Internal DDC Type -- DVI_DDC (II) RADEON(0): Secondary: Monitor -- NONE Connector -- VGA DAC Type -- Primary TMDS Type -- NONE DDC Type -- VGA_DDC (II) RADEON(0): PLL parameters: rf=2700 rd=6 min=20000 max=40000; xclk=22000 (WW) RADEON(0): Failed to detect secondary monitor, MergedFB/Clone mode disabled (==) RADEON(0): Using gamma correction (1.0, 1.0, 1.0) (II) RADEON(0): Validating modes on Primary head --------- (II) RADEON(0): Panel ID string: CPT (II) RADEON(0): Panel Size from BIOS: 1280x800 (II) RADEON(0): BIOS provided dividers will be used. (II) RADEON(0): Total number of valid DDC mode(s) found: 0 (II) RADEON(0): No valid mode specified, force to native mode (II) RADEON(0): Total number of valid FP mode(s) found: 1 (--) RADEON(0): Virtual size is 1280x800 (pitch 1280) (**) RADEON(0): *Mode "1280x800": 71.0 MHz (scaled from 0.0 MHz), 48.8 kHz, 59.5 Hz (II) RADEON(0): Modeline "1280x800" 71.00 1280 1312 1344 1456 800 801 804 820 (**) RADEON(0): Default mode "640x350": 71.0 MHz (scaled from 0.0 MHz), 48.8 kHz, 59.5 Hz (II) RADEON(0): Modeline "640x350" 71.00 640 1312 1344 1456 350 801 804 820 (**) RADEON(0): Default mode "640x400": 71.0 MHz (scaled from 0.0 MHz), 48.8 kHz, 59.5 Hz (II) RADEON(0): Modeline "640x400" 71.00 640 1312 1344 1456 400 801 804 820 (**) RADEON(0): Default mode "720x400": 71.0 MHz (scaled from 0.0 MHz), 48.8 kHz, 59.5 Hz (II) RADEON(0): Modeline "720x400" 71.00 720 1312 1344 1456 400 801 804 820 (**) RADEON(0): Default mode "640x480": 71.0 MHz (scaled from 0.0 MHz), 48.8 kHz, 59.5 Hz (II) RADEON(0): Modeline "640x480" 71.00 640 1312 1344 1456 480 801 804 820 (**) RADEON(0): Default mode "800x600": 71.0 MHz (scaled from 0.0 MHz), 48.8 kHz, 59.5 Hz (II) RADEON(0): Modeline "800x600" 71.00 800 1312 1344 1456 600 801 804 820 (**) RADEON(0): Default mode "1024x768": 71.0 MHz (scaled from 0.0 MHz), 48.8 kHz, 59.5 Hz (II) RADEON(0): Modeline "1024x768" 71.00 1024 1312 1344 1456 768 801 804 820 (**) RADEON(0): Default mode "832x624": 71.0 MHz (scaled from 0.0 MHz), 48.8 kHz, 59.5 Hz (II) RADEON(0): Modeline "832x624" 71.00 832 1312 1344 1456 624 801 804 820 (**) RADEON(0): Default mode "1152x768": 71.0 MHz (scaled from 0.0 MHz), 48.8 kHz, 59.5 Hz (II) RADEON(0): Modeline "1152x768" 71.00 1152 1312 1344 1456 768 801 804 820 (==) RADEON(0): DPI set to (75, 75) (II) Loading sub module "fb" (II) LoadModule: "fb" (II) Loading /usr/local/lib/xorg/modules//libfb.so (II) Module fb: vendor="X.Org Foundation" compiled for 7.2.0, module version = 1.0.0 ABI class: X.Org ANSI C Emulation, version 0.3 (II) Loading sub module "ramdac" (II) LoadModule: "ramdac" (II) Loading /usr/local/lib/xorg/modules//libramdac.so (II) Module ramdac: vendor="X.Org Foundation" compiled for 7.2.0, module version = 0.1.0 ABI class: X.Org Video Driver, version 1.1 (==) RADEON(0): Using XAA acceleration architecture (II) Loading sub module "xaa" (II) LoadModule: "xaa" (II) Loading /usr/local/lib/xorg/modules//libxaa.so (II) Module xaa: vendor="X.Org Foundation" compiled for 7.2.0, module version = 1.2.0 ABI class: X.Org Video Driver, version 1.1 (II) RADEON(0): No MM_TABLE found - assuming CARD is not TV-in capable. (==) RADEON(0): Write-combining range (0x0,0x1000) was already clear (!!) RADEON(0): For information on using the multimedia capabilities of this adapter, please see http://gatos.sf.net. (--) Depth 24 pixmap format is 32 bpp (II) do I need RAC? No, I don't. (II) resource ranges after preInit: [0] 0 0 0xc0000000 - 0xc000ffff (0x10000) MX[B] [1] 0 0 0x90000000 - 0x97ffffff (0x8000000) MX[B] [2] -1 0 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B) [3] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [4] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [5] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [6] -1 0 0xb000a200 - 0xb000a3ff (0x200) MX[B]E [7] -1 0 0xb000a100 - 0xb000a1ff (0x100) MX[B]E [8] -1 0 0xb000a000 - 0xb000a0ff (0x100) MX[B]E [9] -1 0 0xb0008000 - 0xb0009fff (0x2000) MX[B]E [10] -1 0 0xb0004000 - 0xb0007fff (0x4000) MX[B]E [11] -1 0 0xb0000000 - 0xb0003fff (0x4000) MX[B]E [12] -1 0 0xb000b000 - 0xb000bfff (0x1000) MX[B]E [13] -1 0 0xbc000000 - 0xbfffffff (0x4000000) MX[B]E [14] -1 0 0xd0000200 - 0xd00003ff (0x200) MX[B]E [15] -1 0 0xd0000000 - 0xd00001ff (0x200) MX[B]E [16] -1 0 0xf4000000 - 0xf7ffffff (0x4000000) MX[B]E [17] -1 0 0xc0000000 - 0xc000ffff (0x10000) MX[B](B) [18] -1 0 0x90000000 - 0x97ffffff (0x8000000) MX[B](B) [19] 0 0 0x000a0000 - 0x000affff (0x10000) MS[B](OprU) [20] 0 0 0x000b0000 - 0x000b7fff (0x8000) MS[B](OprU) [21] 0 0 0x000b8000 - 0x000bffff (0x8000) MS[B](OprU) [22] 0 0 0x0000c000 - 0x0000c0ff (0x100) IX[B] [23] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [24] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] [25] -1 0 0x0000a000 - 0x0000a0ff (0x100) IX[B]E [26] -1 0 0x00001100 - 0x000011ff (0x100) IX[B]E [27] -1 0 0x0000e300 - 0x0000e3ff (0x100) IX[B]E [28] -1 0 0x0000e200 - 0x0000e2ff (0x100) IX[B]E [29] -1 0 0x0000e100 - 0x0000e1ff (0x100) IX[B]E [30] -1 0 0x0000e000 - 0x0000e0ff (0x100) IX[B]E [31] -1 0 0x00001260 - 0x0000127f (0x20) IX[B]E [32] -1 0 0x00001240 - 0x0000125f (0x20) IX[B]E [33] -1 0 0x00001220 - 0x0000123f (0x20) IX[B]E [34] -1 0 0x00001200 - 0x0000121f (0x20) IX[B]E [35] -1 0 0x0000c000 - 0x0000c0ff (0x100) IX[B](B) [36] 0 0 0x000003b0 - 0x000003bb (0xc) IS[B](OprU) [37] 0 0 0x000003c0 - 0x000003df (0x20) IS[B](OprU) (**) RADEON(0): RADEONScreenInit 90000000 0 (==) RADEON(0): Write-combining range (0xc0000000,0x10000) was already clear (**) RADEON(0): Map: 0x90000000, 0x08000000 (==) RADEON(0): Write-combining range (0x90000000,0x8000000) (**) RADEON(0): RADEONSave (==) RADEON(0): Write-combining range (0xa0000,0x10000) was already clear (**) RADEON(0): RADEONSaveMode(0x286b4130) (**) RADEON(0): Read: 0x00180006 0x0002003f 0x00000000 (**) RADEON(0): Read: rd=6, fd=63, pd=2 (**) RADEON(0): RADEONSaveMode returns 0x286b4130 (II) RADEON(0): Dynamic Clock Scaling Disabled (**) RADEON(0): RADEONInitMemoryMap() : (**) RADEON(0): mem_size : 0x08000000 (**) RADEON(0): MC_FB_LOCATION : 0x97ff9000 (**) RADEON(0): MC_AGP_LOCATION : 0xffffffc0 (**) RADEON(0): RADEONModeInit() 1280x800 71.00 1280 1312 1344 1456 800 801 804 820 (24,32) 1280x800 71.00 1280 1312 1344 1456 800 801 804 820 (24,32) (**) RADEON(0): Pitch = 10485920 bytes (virtualX = 1280, displayWidth = 1280) (II) RADEON(0): BIOS HotKeys Disabled (**) RADEON(0): RADEONInit returns 0x286b4ae0 (**) RADEON(0): RADEONRestoreMode() (**) RADEON(0): RADEONRestoreMode(0x286b4ae0) (**) RADEON(0): RADEONRestoreMemMapRegisters() : (**) RADEON(0): MC_FB_LOCATION : 0x97ff9000 (**) RADEON(0): MC_AGP_LOCATION : 0xffffffc0 (**) RADEON(0): Map Changed ! Applying ... (**) RADEON(0): Map applied, resetting engine ... (**) RADEON(0): Updating display base addresses... (**) RADEON(0): Memory map updated. (**) RADEON(0): Programming CRTC1, offset: 0x00000000 (**) RADEON(0): GRPH_BUFFER_CNTL from 30004c4c to 20167c7c (**) RADEON(0): RADEONSaveScreen(0) (II) RADEON(0): Depth moves disabled by default (**) RADEON(0): Setting up initial surfaces (**) RADEON(0): Initializing fb layer (**) RADEON(0): Setting up accel memmap (II) RADEON(0): Memory manager initialized to (0,0) (1280,8191) (II) RADEON(0): Reserved area from (0,800) to (1280,802) (II) RADEON(0): Largest offscreen area available: 1280 x 7389 (**) RADEON(0): Initializing backing store (==) RADEON(0): Backing store disabled (WW) RADEON(0): Direct rendering disabled (**) RADEON(0): Setting up final surfaces (**) RADEON(0): Initializing Acceleration (II) RADEON(0): Render acceleration unsupported on Radeon 9500/9700 and newer. (II) RADEON(0): Render acceleration disabled (**) RADEON(0): EngineInit (32/32) (**) RADEON(0): Pitch for acceleration = 160 (**) RADEON(0): EngineRestore (32/32) (II) RADEON(0): Using XFree86 Acceleration Architecture (XAA) Screen to screen bit blits Solid filled rectangles 8x8 mono pattern filled rectangles Indirect CPU to Screen color expansion Solid Lines Scanline Image Writes Offscreen Pixmaps Setting up tile and stipple cache: 32 128x128 slots 32 256x256 slots 16 512x512 slots (II) RADEON(0): Acceleration enabled (**) RADEON(0): Initializing DPMS (**) RADEON(0): Initializing Cursor (==) RADEON(0): Silken mouse enabled (II) RADEON(0): Using hardware cursor (scanline 802) (II) RADEON(0): Largest offscreen area available: 1280 x 7385 (**) RADEON(0): Initializing color map (**) RADEON(0): Initializing DGA (**) RADEON(0): Initializing Xv (II) RADEON(0): Detected Radeon Mobility X300, disabling multimedia i2c (II) Loading sub module "theatre_detect" (II) LoadModule: "theatre_detect" (II) Loading /usr/local/lib/xorg/modules/multimedia//theatre_detect_drv.so (II) Module theatre_detect: vendor="X.Org Foundation" compiled for 7.2.0, module version = 1.0.0 ABI class: X.Org Video Driver, version 1.1 (II) RADEON(0): no multimedia table present, disabling Rage Theatre. (**) RADEON(0): RADEONScreenInit finished (==) RandR enabled (II) Initializing built-in extension MIT-SHM (II) Initializing built-in extension XInputExtension (II) Initializing built-in extension XTEST (II) Initializing built-in extension XKEYBOARD (II) Initializing built-in extension XC-APPGROUP (II) Initializing built-in extension XAccessControlExtension (II) Initializing built-in extension SECURITY (II) Initializing built-in extension XINERAMA (II) Initializing built-in extension XFIXES (II) Initializing built-in extension XFree86-Bigfont (II) Initializing built-in extension RENDER (II) Initializing built-in extension RANDR (II) Initializing built-in extension COMPOSITE (II) Initializing built-in extension DAMAGE (II) Initializing built-in extension XEVIE (II) Loading local sub module "GLcore" (II) LoadModule: "GLcore" (II) Loading /usr/local/lib/xorg/modules/extensions//libGLcore.so (II) Module GLcore: vendor="X.Org Foundation" compiled for 7.2.0, module version = 1.0.0 ABI class: X.Org Server Extension, version 0.3 (II) GLX: Initialized MESA-PROXY GL provider for screen 0 (**) Option "Protocol" "auto" (**) Mouse0: Device: "/dev/sysmouse" (**) Mouse0: Protocol: "auto" (**) Option "CorePointer" (**) Mouse0: Core Pointer (**) Option "Device" "/dev/sysmouse" (==) Mouse0: Emulate3Buttons, Emulate3Timeout: 50 (**) Option "ZAxisMapping" "4 5 6 7" (**) Mouse0: ZAxisMapping: buttons 4, 5, 6 and 7 (**) Mouse0: Buttons: 11 (**) Option "CoreKeyboard" (**) Keyboard0: Core Keyboard (**) Option "Protocol" "standard" (**) Keyboard0: Protocol: standard (**) Option "AutoRepeat" "500 30" (**) Option "XkbRules" "xorg" (**) Keyboard0: XkbRules: "xorg" (**) Option "XkbModel" "pc105" (**) Keyboard0: XkbModel: "pc105" (**) Option "XkbLayout" "us" (**) Keyboard0: XkbLayout: "us" (**) Option "CustomKeycodes" "off" (**) Keyboard0: CustomKeycodes disabled (II) XINPUT: Adding extended input device "Keyboard0" (type: KEYBOARD) (II) XINPUT: Adding extended input device "Mouse0" (type: MOUSE) (II) Mouse0: SetupAuto: hw.iftype is 4, hw.model is 0 (II) Mouse0: SetupAuto: protocol is SysMouse (**) RADEON(0): RADEONSaveScreen(2) (**) RADEON(0): RADEONCloseScreen (**) RADEON(0): RADEONDRIStop (**) RADEON(0): RADEONDisplayPowerManagementSet(0,0x0) (**) RADEON(0): RADEONRestore (**) RADEON(0): RADEONRestoreMode() (**) RADEON(0): RADEONRestoreMode(0x286b4130) (**) RADEON(0): RADEONRestoreMemMapRegisters() : (**) RADEON(0): MC_FB_LOCATION : 0x1fff0000 (**) RADEON(0): MC_AGP_LOCATION : 0x27ff2000 (**) RADEON(0): Map Changed ! Applying ... (**) RADEON(0): Map applied, resetting engine ... (**) RADEON(0): Updating display base addresses... (**) RADEON(0): Memory map updated. (**) RADEON(0): Programming CRTC1, offset: 0x00000000 (**) RADEON(0): Wrote: 0x00180006 0x0002003f 0x00000000 (0x0000a700) (**) RADEON(0): Wrote: rd=6, fd=63, pd=2 (==) RADEON(0): Write-combining range (0xa0000,0x10000) was already clear (**) RADEON(0): Disposing accel... (**) RADEON(0): Disposing cusor info (**) RADEON(0): Disposing DGA (**) RADEON(0): Unmapping memory FreeFontPath: FPE "/usr/local/lib/X11/fonts/misc/" refcount is 2, should be 1; fixing. -- ------------------- |Yousef Raffah| -------------------------------- http://yousef.raffah.com | -------------------------------- From owner-freebsd-current@FreeBSD.ORG Sat Jul 21 12:59:19 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2734616A420 for ; Sat, 21 Jul 2007 12:59:19 +0000 (UTC) (envelope-from yraffah@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.183]) by mx1.freebsd.org (Postfix) with ESMTP id 00ECC13C45A for ; Sat, 21 Jul 2007 12:59:18 +0000 (UTC) (envelope-from yraffah@gmail.com) Received: by wa-out-1112.google.com with SMTP id j37so1433373waf for ; Sat, 21 Jul 2007 05:59:18 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=r/BRPFdNZOxm9PbR9Av9PgNBZE+lyZjSeP78F9nGU3Jg0lmG5e+/ppbsrfGcKiucOTGxPkAbBzjXuV2h40p5xNCOpUbZAL0aFNLRqdflwcZoz7BXw0OQ2brj2SFLUrkf/GiXZylDSgOWlVpjqugQaCzvii98x+UPiTIOCHN58R4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=rNeMYMIY0oKdnESzjO1Z8v4PoYsqdJv2zJePIzZWgrDKC1r7mSC467l2AbL6uVUxtXpPOV5+/X2QMovkkTy4Z5lnQS7z54eaRehHUTSJT3+ST1dTNFGfbjPaY81fuZhX0nVnV/+uW0fB7puVE8oUy8W1tiYOMDAaEdqciMmvTb4= Received: by 10.114.61.1 with SMTP id j1mr1383411waa.1185022758170; Sat, 21 Jul 2007 05:59:18 -0700 (PDT) Received: by 10.114.66.15 with HTTP; Sat, 21 Jul 2007 05:59:18 -0700 (PDT) Message-ID: Date: Sat, 21 Jul 2007 15:59:18 +0300 From: "Yousef Raffah" To: "illoai@gmail.com" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: Cc: freebsd-current@freebsd.org Subject: Re: Is this an Xorg problem? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jul 2007 12:59:19 -0000 On 7/21/07, illoai@gmail.com wrote: > On 21/07/07, Yousef Raffah wrote: > > Howdy, > > > > I'm running on 7.0-CURRENT #1: Sun Jul 15 11:33:57 AST 2007 with the > > GENERIC kernel. I had removed all my ports in order to have a fresh > > install. Everything was successfully installed after that, including > > xorg 7.2. However, when I try to start my X session, the screen > > flickers as if it was starting then suddenly brakes and shuts down, > > returning me to my prompt printing the following on the console: > > mskc0: Uncorrectable PCI Express error > > > > Also if I try Xorg -configure to create a new xorg.conf for me, the > > machine freezes and does not respond to anything when I run it with X > > -config /root/xorg.conf.new (I don't run X as root, this is just to > > test the new config file), I can't even ssh nor ping the box! Hard > > booting is the only way to get it back :( > > > > Sorry if it isn't CURRENT related but kindly let me know and I will > > post it to the xorg mailing list. My appologies. > > > > Well, a quick grep -r tells me that the only > references to "mskc" are in: > /usr/src/sys/dev/msk/if_msk.c > I don't know enough to know if this is: > a) harmless > 2) related > msk0 is actually my NIC, this is one of the reasons I'm using CURRENT as it is supporting my NIC and b0rked ACPI on this Toshiba Tecra A4. > As far as Xorg freezing, have you tried editing > your xorg.conf to use something like: > Section "Device" > Identifier "Card1" > Driver "vesa" > EndSection > > and then changing > Section "Screen" > Device "Card0" > to read > Device "Card1" > ? > > If that works (albeit you likely won't get resolution > over 1024x768 and it will be slow) then . . . oh, hell, > I don't know enough to really help, but the results > might be enlightening to someone. > Unfortunately it didn't work and it gave the same output on console :( Thanks for trying... > -- > -- > -- ------------------- |Yousef Raffah| -------------------------------- http://yousef.raffah.com | -------------------------------- From owner-freebsd-current@FreeBSD.ORG Sat Jul 21 13:02:34 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4B04D16A419 for ; Sat, 21 Jul 2007 13:02:34 +0000 (UTC) (envelope-from illoai@gmail.com) Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.191]) by mx1.freebsd.org (Postfix) with ESMTP id CEF0E13C46E for ; Sat, 21 Jul 2007 13:02:33 +0000 (UTC) (envelope-from illoai@gmail.com) Received: by mu-out-0910.google.com with SMTP id w9so1264176mue for ; Sat, 21 Jul 2007 06:02:31 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=iINQRLwznhIK1jX5dMbkFvalVt5zSc5qUqaZwlK4etRRgOZcqdBfKHFC7VdrWAATBwjBKskWbWF0Z2G1nfuOjZabFSyQDN3U3s6dhsGr/6bXn6m4nBx/r9LepzZ0Izrg917fX3ngoJkQXzmPzGjq7zAI3Cu3ZqcP8YCCYQaYbXg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Vsih/1kBnBZUj2bfUXbvyQx6oprDmwjhALKY2ZGNqSaNcUG8vL9V3TGdo1s3jnJHF6gxLUrerZ4tNswub9Cvj5ul9Ip2kEZYYhQj0ci3Ij6dVF2CWXGZpzlRRry6YId/iXSnaVFuT5dSFdIUAhqQZY0fB20hTia8jm4SfaDyARs= Received: by 10.82.183.19 with SMTP id g19mr1134013buf.1185021510144; Sat, 21 Jul 2007 05:38:30 -0700 (PDT) Received: by 10.82.187.6 with HTTP; Sat, 21 Jul 2007 05:38:30 -0700 (PDT) Message-ID: Date: Sat, 21 Jul 2007 07:38:30 -0500 From: "illoai@gmail.com" To: "Yousef Raffah" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: Cc: freebsd-current@freebsd.org Subject: Re: Is this an Xorg problem? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jul 2007 13:02:34 -0000 On 21/07/07, Yousef Raffah wrote: > Howdy, > > I'm running on 7.0-CURRENT #1: Sun Jul 15 11:33:57 AST 2007 with the > GENERIC kernel. I had removed all my ports in order to have a fresh > install. Everything was successfully installed after that, including > xorg 7.2. However, when I try to start my X session, the screen > flickers as if it was starting then suddenly brakes and shuts down, > returning me to my prompt printing the following on the console: > mskc0: Uncorrectable PCI Express error > > Also if I try Xorg -configure to create a new xorg.conf for me, the > machine freezes and does not respond to anything when I run it with X > -config /root/xorg.conf.new (I don't run X as root, this is just to > test the new config file), I can't even ssh nor ping the box! Hard > booting is the only way to get it back :( > > Sorry if it isn't CURRENT related but kindly let me know and I will > post it to the xorg mailing list. My appologies. > Well, a quick grep -r tells me that the only references to "mskc" are in: /usr/src/sys/dev/msk/if_msk.c I don't know enough to know if this is: a) harmless 2) related As far as Xorg freezing, have you tried editing your xorg.conf to use something like: Section "Device" Identifier "Card1" Driver "vesa" EndSection and then changing Section "Screen" Device "Card0" to read Device "Card1" ? If that works (albeit you likely won't get resolution over 1024x768 and it will be slow) then . . . oh, hell, I don't know enough to really help, but the results might be enlightening to someone. -- -- From owner-freebsd-current@FreeBSD.ORG Sat Jul 21 13:25:23 2007 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6600516A41B for ; Sat, 21 Jul 2007 13:25:23 +0000 (UTC) (envelope-from erwin@mail.droso.net) Received: from mail.droso.net (koala.ipv6.droso.net [IPv6:2001:6c8:6:0:206:5bff:fef8:267d]) by mx1.freebsd.org (Postfix) with ESMTP id 27CB813C48D for ; Sat, 21 Jul 2007 13:25:22 +0000 (UTC) (envelope-from erwin@mail.droso.net) Received: by mail.droso.net (Postfix, from userid 1001) id 61A891CC30; Sat, 21 Jul 2007 15:25:21 +0200 (CEST) Date: Sat, 21 Jul 2007 15:25:21 +0200 From: Erwin Lansing To: current@FreeBSD.org Message-ID: <20070721132521.GE37472@droso.net> Mail-Followup-To: current@FreeBSD.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1MXu+reqKPHC6GN9" Content-Disposition: inline X-Operating-System: FreeBSD/i386 6.2-STABLE User-Agent: Mutt/1.5.15 (2007-04-06) Cc: Subject: wpa_supplicant triggered memory modified after free X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Jul 2007 13:25:23 -0000 --1MXu+reqKPHC6GN9 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I got hungry and wanted some more dogfood, so I upgraded my laptop to -CURRENT. Trying to use wpa_suplicant triggers the following panic: Memory modified after free 0xc339c900(124) val=3Dff @ 0xc339c900 panic: Most recently used by gbde Not using WPA is no problem, so I wonder what gbde has to do with it. Backtrace at http://people.freebsd.org/~erwin/wpa.panic -erwin --=20 Erwin Lansing http://droso.org Security is like an onion. (o_ _o) It's made up of several layers \\\_\ /_/// erwin@FreeBSD.org And it makes you cry. <____) (____> erwin@aauug.dk --1MXu+reqKPHC6GN9 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGoglBqy9aWxUlaZARAtiAAJwNK3fYK5hS41fPTHMkfCDaKpbmggCgj136 xuR8uLnl+QtLTmFb4WgOiRc= =YhSN -----END PGP SIGNATURE----- --1MXu+reqKPHC6GN9-- From owner-freebsd-current@FreeBSD.ORG Sat Jul 21 15:49:21 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B1BB416A41A for ; Sat, 21 Jul 2007 15:49:21 +0000 (UTC) (envelope-from lists@avioc.org) Received: from didy.avioc.org (didy.avioc.org [71.32.26.53]) by mx1.freebsd.org (Postfix) with ESMTP id 6150713C461 for ; Sat, 21 Jul 2007 15:49:21 +0000 (UTC) (envelope-from lists@avioc.org) Received: from localhost (mail.internal.avioc.org [192.168.2.252]) by didy.avioc.org (Postfix) with ESMTP id 9DF32EB64E8; Sat, 21 Jul 2007 10:30:56 -0500 (CDT) X-Virus-Scanned: amavisd-new at mail.internal.avioc.org Received: from didy.avioc.org ([192.168.2.252]) by localhost (mail.internal.avioc.org [192.168.2.252]) (amavisd-new, port 10024) with LMTP id IriF5WE3IGjH; Sat, 21 Jul 2007 10:30:52 -0500 (CDT) Received: from mail.avioc.org (httpd.internal.avioc.org [192.168.2.251]) by didy.avioc.org (Postfix) with ESMTP id CD093EB64E6; Sat, 21 Jul 2007 10:30:52 -0500 (CDT) MIME-Version: 1.0 Date: Sat, 21 Jul 2007 10:30:52 -0500 From: To: Pascal Hofstee In-Reply-To: <1183674495.75595.14.camel@worf> References: <1183674495.75595.14.camel@worf> Message-ID: X-Sender: lists@avioc.org User-Agent: RoundCube Webmail/0.1b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Cc: current , "Boris S." , Brian Donnell Subject: Re: ZFS vs Samba Debugging Results ... Need Help. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Jul 2007 15:49:21 -0000 On Fri, 06 Jul 2007 00:28:15 +0200, Pascal Hofstee wrote: > Hi, > > I did some addititional debugging and adding a small workaround to > smbd/vfs.c making the function vfs_readdirname() return ptr->d_name > directly instead of relying on the temporary variable dname gets the > code properly skipping the "." and ".." entries. > Have any other work arounds for this issue been found? - other than deleting the repdir_get* files as noted by Brian? Are there any consequences to removing the files that I don't want to run into? >>From that point on the code enters into a new problem area which can be > observed in the backtrace posted at http://pastebin.ca/604961 > > Joe Marcus Clarke helped me out further with debugging this problem and > we have come to the conclusion that the following assertion in samba's > telldir() implementation located in lib/replace/repdir_getdirentries.c > does not hold true on ZFS directories (marcus mentioned something about > lseek() behaving differently on ZFS than it does on UFS): > > if (d->seekpos & (DIR_BUF_SIZE-1)) { > abort(); > } > > Marcus was so kind to put up a simple test case at > http://www.marcuscom.com/downloads/samba_zfs.c > > Change main() to point to a ZFS directory, and watch it crash. > Then point to a UFS directory, and it works. > The seekpos is printed each time. > > Hopefully this will be enough information to get us to figure out a > workable solution here. > > -- > Pascal Hofstee > > > _______________________________________________ > 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 Jul 21 17:14:44 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BD9CB16A418 for ; Sat, 21 Jul 2007 17:14:44 +0000 (UTC) (envelope-from gallatin@cs.duke.edu) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.freebsd.org (Postfix) with ESMTP id 8769F13C467 for ; Sat, 21 Jul 2007 17:14:44 +0000 (UTC) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.14.0/8.14.0) with ESMTP id l6LHEiJD025282 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 21 Jul 2007 13:14:44 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.12.9p2/8.12.9/Submit) id l6LHEFbI090143; Sat, 21 Jul 2007 13:14:15 -0400 (EDT) (envelope-from gallatin) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18082.16126.915890.401438@grasshopper.cs.duke.edu> Date: Sat, 21 Jul 2007 13:14:15 -0400 (EDT) To: current@freebsd.org X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Cc: Subject: freebsd-current@lists.freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Jul 2007 17:14:44 -0000 [didn't seem to go through first time; apologies if you see this twice] Hi, I'm trying to install FreeBSD/amd64 on a Core2 based iMac using the last snapshot I could find (7.0-CURRENT-200706-amd64-disc1.iso). I've got a blank firewire disk I plan to throw at it. At boot, sysinstall dies with "Probing disks... BARF 170 <33>", which causes a "Going nowhere without my init!" panic. This message points to this code in libdisk: /* APPLE have ty as a string */ if ((*r) && (strcmp(t, "APPLE") && strcmp(t, "GPT"))) { printf("BARF %d <%d>\n", __LINE__, *r); exit (0); } This happens with or without the firewire drive plugged in, so I'm assuming FreeBSD's getting confused by the internal disk. According to the Apple utilities, the disk looks like this: % sudo diskutil list /dev/disk0 /dev/disk0 #: type name size identifier 0: GUID_partition_scheme *232.9 GB disk0 1: EFI 200.0 MB disk0s1 2: Apple_HFS Tiger 51.5 GB disk0s2 3: Apple_HFS Leopard 51.5 GB disk0s3 4: Apple_HFS home 129.2 GB disk0s4 I'm about to plug the firewire disk into another box and install using make installworld DESTDIR=/firewire_disk, but this is the sort of thing that would really, really put off your typical FreeBSD would-be adopter. Is there anything we can do to fix this in the 7.0 timeframe? On a somewhat related note, how well does FreeBSD even work on an iMac? Can we suspend/resume SMP machines yet? Thanks, Drew From owner-freebsd-current@FreeBSD.ORG Sat Jul 21 18:26:02 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 41CA216A419 for ; Sat, 21 Jul 2007 18:26:02 +0000 (UTC) (envelope-from dfr@rabson.org) Received: from itchy.rabson.org (unknown [IPv6:2001:618:400::50b1:e8f2]) by mx1.freebsd.org (Postfix) with ESMTP id C4DA313C45D for ; Sat, 21 Jul 2007 18:26:01 +0000 (UTC) (envelope-from dfr@rabson.org) Received: from herring.rabson.org (herring.rabson.org [80.177.232.250]) by itchy.rabson.org (8.13.3/8.13.3) with ESMTP id l6LIQ0Df068227 for ; Sat, 21 Jul 2007 19:26:00 +0100 (BST) (envelope-from dfr@rabson.org) From: Doug Rabson To: current@freebsd.org Date: Sat, 21 Jul 2007 19:25:59 +0100 User-Agent: KMail/1.9.6 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <200707211925.59698.dfr@rabson.org> X-Virus-Scanned: ClamAV 0.87.1/3715/Sat Jul 21 13:39:12 2007 on itchy.rabson.org X-Virus-Status: Clean Cc: Subject: if_bridge crash X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Jul 2007 18:26:02 -0000 I've been using if_bridge and if_tap to join various qemu virtual machines onto my local network. I use this script to set up the bridge: ifconfig bridge0 create ifconfig tap0 create ifconfig bridge0 addm vr0 addm tap0 up I had forgotten what stupid mac address qemu had made up for its interface and I needed to adjust my dhcpd config so I typed 'ifconfig bridge addr' to list the addresses on the bridge and got an instant panic. Qemu was not running at this point. The kernel address where it crashed was good - it was the userland address which faulted. The crash was in generic_copyout+0x36 called from bridge_ioctl+0x1ae. I took a look at the code and as far as I can make out, trap() got a bit confused and managed to ignore the pcb_onfault marker left by copyout. Its hard to tell exactly what happened since the damn compiler has optimised the crap out of the code there. As far as I can see, the bridge code is calling copyout with a mutex held. Is that allowed? It doesn't sound like it should be allowed but I'm not quite up-to-date on that aspect of the current kernel api. From owner-freebsd-current@FreeBSD.ORG Sat Jul 21 18:39:52 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AB58116A41A for ; Sat, 21 Jul 2007 18:39:52 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.174]) by mx1.freebsd.org (Postfix) with ESMTP id 1F74013C461 for ; Sat, 21 Jul 2007 18:39:51 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by ug-out-1314.google.com with SMTP id o4so1013800uge for ; Sat, 21 Jul 2007 11:39:50 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding:sender; b=YWUvqNRUPf7LisvVuWmT4hpRISqWk9hT2e84VGtf9LpzQjTNVvWYnO9pxPkcMmYHuaWyHZMsITuaiz3tNbZ+PKa+mn/dpbQNHHO6bswn7PF1srwtunKyGezvF9GngPysoU0AWaNwMbhsgjScdhQfvVzxdpNqQUw4zcdro2GwyD0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding:sender; b=oMiNhTVuX9lMXT8+J3geawuFIOn/paft3SB1Ym4as8JM0UvdZXqIm65Pc2LLsUbLWGKz31LeprZvA43LNsmxDlwEFM7o1S0HyrPwIqAw3MiWAqbnsj/u32W3+lLmpn7zkGfrL1naykxImeHpwZZgqu7qRQ7svFso56R1x36Z/3M= Received: by 10.67.28.9 with SMTP id f9mr2894549ugj.1185043190366; Sat, 21 Jul 2007 11:39:50 -0700 (PDT) Received: from ?151.75.233.217? ( [151.75.233.217]) by mx.google.com with ESMTPS id l20sm4478573uga.2007.07.21.11.39.49 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 21 Jul 2007 11:39:50 -0700 (PDT) Message-ID: <46A252C3.5050804@FreeBSD.org> Date: Sat, 21 Jul 2007 20:38:59 +0200 From: Attilio Rao User-Agent: Thunderbird 1.5 (X11/20060526) MIME-Version: 1.0 To: Doug Rabson References: <200707211925.59698.dfr@rabson.org> In-Reply-To: <200707211925.59698.dfr@rabson.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: Attilio Rao Cc: current@freebsd.org Subject: Re: if_bridge crash X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: attilio@FreeBSD.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jul 2007 18:39:52 -0000 Doug Rabson wrote: > I've been using if_bridge and if_tap to join various qemu virtual > machines onto my local network. I use this script to set up the bridge: > > ifconfig bridge0 create > ifconfig tap0 create > ifconfig bridge0 addm vr0 addm tap0 up > > I had forgotten what stupid mac address qemu had made up for its > interface and I needed to adjust my dhcpd config so I typed 'ifconfig > bridge addr' to list the addresses on the bridge and got an instant > panic. Qemu was not running at this point. The kernel address where it > crashed was good - it was the userland address which faulted. > > The crash was in generic_copyout+0x36 called from bridge_ioctl+0x1ae. I > took a look at the code and as far as I can make out, trap() got a bit > confused and managed to ignore the pcb_onfault marker left by copyout. > Its hard to tell exactly what happened since the damn compiler has > optimised the crap out of the code there. > > As far as I can see, the bridge code is calling copyout with a mutex > held. Is that allowed? It doesn't sound like it should be allowed but > I'm not quite up-to-date on that aspect of the current kernel api. Since a copyout() can generate a page fault (which can let the thread sleep) it is not allowed to mantain neither a blockable lock (mutex, rwlock) or a spinlock over a copyout. In the case the lock is a sx or lockmgr it is allowed. Attilio From owner-freebsd-current@FreeBSD.ORG Sat Jul 21 19:36:24 2007 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D578416A418; Sat, 21 Jul 2007 19:36:24 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from mail.ipt.ru (mail.ipt.ru [194.62.233.102]) by mx1.freebsd.org (Postfix) with ESMTP id 8206413C458; Sat, 21 Jul 2007 19:36:24 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from srv.sem.ipt.ru ([192.168.12.1] helo=ipt.ru) by mail.ipt.ru with esmtp (Exim 4.62 (FreeBSD)) (envelope-from ) id 1ICKka-0009Dg-Ov; Sat, 21 Jul 2007 23:36:24 +0400 Received: from bsam by ipt.ru with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1ICKkm-0003k7-VQ; Sat, 21 Jul 2007 23:36:37 +0400 To: freebsd-current@FreeBSD.org References: <20070720213211.GA7262@saturn.kn-bremen.de> <08469478@srv.sem.ipt.ru> From: Boris Samorodov Date: Sat, 21 Jul 2007 23:36:36 +0400 In-Reply-To: <08469478@srv.sem.ipt.ru> (Boris Samorodov's message of "Sat\, 21 Jul 2007 02\:10\:33 +0400") Message-ID: <42375355@srv.sem.ipt.ru> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.99 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-emulation@FreeBSD.org Subject: Re: kqemu and sched_lock, please test port update X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Jul 2007 19:36:24 -0000 On Sat, 21 Jul 2007 02:10:33 +0400 Boris Samorodov wrote: > On Fri, 20 Jul 2007 23:32:11 +0200 Juergen Lock wrote: > > I just noticed this, and came up with the update below. I still don't > > have a -current box so I need you to test this before I commit it... > Kqemu with the patch compiles well at amd64-current as of yesterday. > Don't have time ATM to check running. Thanks for the patch! An attempt to run ended with: ----- Program received signal SIGSYS, Bad system call. 0x0000000800ac8d7c in aio_read () from /lib/libc.so.7 ----- This is amd64-current-ULE3.0. WBR -- Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-current@FreeBSD.ORG Sat Jul 21 20:41:47 2007 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DD76916A41B for ; Sat, 21 Jul 2007 20:41:47 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from mail.ipt.ru (mail.ipt.ru [194.62.233.102]) by mx1.freebsd.org (Postfix) with ESMTP id 93F5613C459 for ; Sat, 21 Jul 2007 20:41:47 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from stat.sem.ipt.ru ([192.168.12.1] helo=ipt.ru) by mail.ipt.ru with esmtp (Exim 4.62 (FreeBSD)) (envelope-from ) id 1ICLlr-0009OL-KW for freebsd-current@FreeBSD.org; Sun, 22 Jul 2007 00:41:47 +0400 Received: from bsam by ipt.ru with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1ICLm4-0003mY-1y for freebsd-current@FreeBSD.org; Sun, 22 Jul 2007 00:42:00 +0400 To: freebsd-current@FreeBSD.org From: Boris Samorodov Date: Sun, 22 Jul 2007 00:42:00 +0400 Message-ID: <88771431@srv.sem.ipt.ru> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.99 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit Cc: Subject: postgresql in a jail: manually starts but not while booting X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Jul 2007 20:41:47 -0000 Hi! I've got a recent amd64-current with postgresql in a jail. The database master process starts from command line but not when the host system is booted (and the jail is auto-started): ----- Jul 22 00:10:17 pg postgres[1134]: [2-1] FATAL: could not create shared memory segment: Function not implemented Jul 22 00:10:17 pg postgres[1134]: [2-2] ðïäòïâîïóôé: Failed system call was shmget(key=5432001, size=39149568, 03600). ----- WBR -- Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-current@FreeBSD.ORG Sat Jul 21 21:08:01 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 80EF416A417; Sat, 21 Jul 2007 21:08:01 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from heff.fud.org.nz (203-109-251-39.static.bliink.ihug.co.nz [203.109.251.39]) by mx1.freebsd.org (Postfix) with ESMTP id 1DCE213C461; Sat, 21 Jul 2007 21:08:01 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: by heff.fud.org.nz (Postfix, from userid 1001) id 781E91CC58; Sun, 22 Jul 2007 09:07:59 +1200 (NZST) Date: Sun, 22 Jul 2007 09:07:59 +1200 From: Andrew Thompson To: Attilio Rao Message-ID: <20070721210759.GA84580@heff.fud.org.nz> References: <200707211925.59698.dfr@rabson.org> <46A252C3.5050804@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46A252C3.5050804@FreeBSD.org> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: current@freebsd.org Subject: Re: if_bridge crash X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Jul 2007 21:08:01 -0000 On Sat, Jul 21, 2007 at 08:38:59PM +0200, Attilio Rao wrote: > Doug Rabson wrote: > >I've been using if_bridge and if_tap to join various qemu virtual > >machines onto my local network. I use this script to set up the bridge: > > > > ifconfig bridge0 create > > ifconfig tap0 create > > ifconfig bridge0 addm vr0 addm tap0 up > > > >I had forgotten what stupid mac address qemu had made up for its > >interface and I needed to adjust my dhcpd config so I typed 'ifconfig > >bridge addr' to list the addresses on the bridge and got an instant > >panic. Qemu was not running at this point. The kernel address where it > >crashed was good - it was the userland address which faulted. > > > >The crash was in generic_copyout+0x36 called from bridge_ioctl+0x1ae. I > >took a look at the code and as far as I can make out, trap() got a bit > >confused and managed to ignore the pcb_onfault marker left by copyout. > >Its hard to tell exactly what happened since the damn compiler has > >optimised the crap out of the code there. > > > >As far as I can see, the bridge code is calling copyout with a mutex > >held. Is that allowed? It doesn't sound like it should be allowed but > >I'm not quite up-to-date on that aspect of the current kernel api. > > Since a copyout() can generate a page fault (which can let the thread > sleep) it is not allowed to mantain neither a blockable lock (mutex, > rwlock) or a spinlock over a copyout. Please test this patch. cheers, Andrew From owner-freebsd-current@FreeBSD.ORG Sat Jul 21 21:08:39 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A15CC16A417; Sat, 21 Jul 2007 21:08:39 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from heff.fud.org.nz (203-109-251-39.static.bliink.ihug.co.nz [203.109.251.39]) by mx1.freebsd.org (Postfix) with ESMTP id CB75413C48E; Sat, 21 Jul 2007 21:08:38 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: by heff.fud.org.nz (Postfix, from userid 1001) id CC7C61CC5D; Sun, 22 Jul 2007 09:08:37 +1200 (NZST) Date: Sun, 22 Jul 2007 09:08:37 +1200 From: Andrew Thompson To: Attilio Rao Message-ID: <20070721210837.GB84580@heff.fud.org.nz> References: <200707211925.59698.dfr@rabson.org> <46A252C3.5050804@FreeBSD.org> <20070721210759.GA84580@heff.fud.org.nz> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="+HP7ph2BbKc20aGI" Content-Disposition: inline In-Reply-To: <20070721210759.GA84580@heff.fud.org.nz> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: current@freebsd.org Subject: Re: if_bridge crash X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Jul 2007 21:08:39 -0000 --+HP7ph2BbKc20aGI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sun, Jul 22, 2007 at 09:07:59AM +1200, Andrew Thompson wrote: > On Sat, Jul 21, 2007 at 08:38:59PM +0200, Attilio Rao wrote: > > Doug Rabson wrote: > > >I've been using if_bridge and if_tap to join various qemu virtual > > >machines onto my local network. I use this script to set up the bridge: > > > > > > ifconfig bridge0 create > > > ifconfig tap0 create > > > ifconfig bridge0 addm vr0 addm tap0 up > > > > > >I had forgotten what stupid mac address qemu had made up for its > > >interface and I needed to adjust my dhcpd config so I typed 'ifconfig > > >bridge addr' to list the addresses on the bridge and got an instant > > >panic. Qemu was not running at this point. The kernel address where it > > >crashed was good - it was the userland address which faulted. > > > > > >The crash was in generic_copyout+0x36 called from bridge_ioctl+0x1ae. I > > >took a look at the code and as far as I can make out, trap() got a bit > > >confused and managed to ignore the pcb_onfault marker left by copyout. > > >Its hard to tell exactly what happened since the damn compiler has > > >optimised the crap out of the code there. > > > > > >As far as I can see, the bridge code is calling copyout with a mutex > > >held. Is that allowed? It doesn't sound like it should be allowed but > > >I'm not quite up-to-date on that aspect of the current kernel api. > > > > Since a copyout() can generate a page fault (which can let the thread > > sleep) it is not allowed to mantain neither a blockable lock (mutex, > > rwlock) or a spinlock over a copyout. > > > Please test this patch. One more time with the file attached. --+HP7ph2BbKc20aGI Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="bridge_lock.diff" Index: if_bridge.c =================================================================== RCS file: /home/ncvs/src/sys/net/if_bridge.c,v retrieving revision 1.100 diff -u -p -r1.100 if_bridge.c --- if_bridge.c 13 Jun 2007 18:58:04 -0000 1.100 +++ if_bridge.c 21 Jul 2007 21:05:55 -0000 @@ -668,8 +668,6 @@ bridge_ioctl(struct ifnet *ifp, u_long c const struct bridge_control *bc; int error = 0; - BRIDGE_LOCK(sc); - switch (cmd) { case SIOCADDMULTI: @@ -714,7 +712,9 @@ bridge_ioctl(struct ifnet *ifp, u_long c break; } + BRIDGE_LOCK(sc); error = (*bc->bc_func)(sc, &args); + BRIDGE_UNLOCK(sc); if (error) break; @@ -730,14 +730,15 @@ bridge_ioctl(struct ifnet *ifp, u_long c * If interface is marked down and it is running, * then stop and disable it. */ + BRIDGE_LOCK(sc); bridge_stop(ifp, 1); + BRIDGE_UNLOCK(sc); } else if ((ifp->if_flags & IFF_UP) && !(ifp->if_drv_flags & IFF_DRV_RUNNING)) { /* * If interface is marked up and it is stopped, then * start it. */ - BRIDGE_UNLOCK(sc); (*ifp->if_init)(sc); } break; @@ -752,14 +753,10 @@ bridge_ioctl(struct ifnet *ifp, u_long c * drop the lock as ether_ioctl() will call bridge_start() and * cause the lock to be recursed. */ - BRIDGE_UNLOCK(sc); error = ether_ioctl(ifp, cmd, data); break; } - if (BRIDGE_LOCKED(sc)) - BRIDGE_UNLOCK(sc); - return (error); } Index: if_bridgevar.h =================================================================== RCS file: /home/ncvs/src/sys/net/if_bridgevar.h,v retrieving revision 1.21 diff -u -p -r1.21 if_bridgevar.h --- if_bridgevar.h 13 Jun 2007 18:58:04 -0000 1.21 +++ if_bridgevar.h 21 Jul 2007 21:06:08 -0000 @@ -272,7 +272,6 @@ struct ifbpstpconf { } while (0) #define BRIDGE_LOCK(_sc) mtx_lock(&(_sc)->sc_mtx) #define BRIDGE_UNLOCK(_sc) mtx_unlock(&(_sc)->sc_mtx) -#define BRIDGE_LOCKED(_sc) mtx_owned(&(_sc)->sc_mtx) #define BRIDGE_LOCK_ASSERT(_sc) mtx_assert(&(_sc)->sc_mtx, MA_OWNED) #define BRIDGE_LOCK2REF(_sc, _err) do { \ mtx_assert(&(_sc)->sc_mtx, MA_OWNED); \ --+HP7ph2BbKc20aGI-- From owner-freebsd-current@FreeBSD.ORG Sat Jul 21 21:37:35 2007 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1C33216A417 for ; Sat, 21 Jul 2007 21:37:35 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id E4AA513C457 for ; Sat, 21 Jul 2007 21:37:34 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 68DD647C8F; Sat, 21 Jul 2007 17:37:34 -0400 (EDT) Date: Sat, 21 Jul 2007 22:37:34 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Boris Samorodov In-Reply-To: <42375355@srv.sem.ipt.ru> Message-ID: <20070721223711.A17778@fledge.watson.org> References: <20070720213211.GA7262@saturn.kn-bremen.de> <08469478@srv.sem.ipt.ru> <42375355@srv.sem.ipt.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-emulation@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: kqemu and sched_lock, please test port update X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Jul 2007 21:37:35 -0000 On Sat, 21 Jul 2007, Boris Samorodov wrote: > On Sat, 21 Jul 2007 02:10:33 +0400 Boris Samorodov wrote: >> On Fri, 20 Jul 2007 23:32:11 +0200 Juergen Lock wrote: > >>> I just noticed this, and came up with the update below. I still don't >>> have a -current box so I need you to test this before I commit it... > >> Kqemu with the patch compiles well at amd64-current as of yesterday. Don't >> have time ATM to check running. Thanks for the patch! > > An attempt to run ended with: > ----- > Program received signal SIGSYS, Bad system call. > 0x0000000800ac8d7c in aio_read () from /lib/libc.so.7 > ----- > > This is amd64-current-ULE3.0. Possibly you need to "kldload aio"? Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Sat Jul 21 21:44:01 2007 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E537916A418; Sat, 21 Jul 2007 21:44:01 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from mail.ipt.ru (mail.ipt.ru [194.62.233.102]) by mx1.freebsd.org (Postfix) with ESMTP id 96ACB13C45A; Sat, 21 Jul 2007 21:44:01 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from doc.sem.ipt.ru ([192.168.12.1] helo=ipt.ru) by mail.ipt.ru with esmtp (Exim 4.62 (FreeBSD)) (envelope-from ) id 1ICMk5-0009Xw-Ge; Sun, 22 Jul 2007 01:44:01 +0400 Received: from bsam by ipt.ru with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1ICMkI-0003pN-2K; Sun, 22 Jul 2007 01:44:14 +0400 To: Robert Watson References: <20070720213211.GA7262@saturn.kn-bremen.de> <08469478@srv.sem.ipt.ru> <42375355@srv.sem.ipt.ru> <20070721223711.A17778@fledge.watson.org> From: Boris Samorodov Date: Sun, 22 Jul 2007 01:44:14 +0400 In-Reply-To: <20070721223711.A17778@fledge.watson.org> (Robert Watson's message of "Sat\, 21 Jul 2007 22\:37\:34 +0100 \(BST\)") Message-ID: <22697697@srv.sem.ipt.ru> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.99 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-emulation@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: kqemu and sched_lock, please test port update X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Jul 2007 21:44:02 -0000 On Sat, 21 Jul 2007 22:37:34 +0100 (BST) Robert Watson wrote: > On Sat, 21 Jul 2007, Boris Samorodov wrote: > > On Sat, 21 Jul 2007 02:10:33 +0400 Boris Samorodov wrote: > >> On Fri, 20 Jul 2007 23:32:11 +0200 Juergen Lock wrote: > > > >>> I just noticed this, and came up with the update below. I still > >>> don't have a -current box so I need you to test this before I > >>> commit it... > > > >> Kqemu with the patch compiles well at amd64-current as of > >> yesterday. Don't have time ATM to check running. Thanks for the > >> patch! > > > > An attempt to run ended with: > > ----- > > Program received signal SIGSYS, Bad system call. > > 0x0000000800ac8d7c in aio_read () from /lib/libc.so.7 > > ----- > > > > This is amd64-current-ULE3.0. > Possibly you need to "kldload aio"? Ops! That was it! (Who deletted loader.conf? Me? Well, really me...) Thanks, Robert and sorry for the noise. WBR -- Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-current@FreeBSD.ORG Sat Jul 21 21:47:42 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 81EBD16A519 for ; Sat, 21 Jul 2007 21:47:42 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.freebsd.org (Postfix) with ESMTP id 45E9913C48E for ; Sat, 21 Jul 2007 21:47:42 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.14.1/8.13.8) id l6LLlfr1038765; Sat, 21 Jul 2007 16:47:41 -0500 (CDT) (envelope-from dan) Date: Sat, 21 Jul 2007 16:47:41 -0500 From: Dan Nelson To: Boris Samorodov Message-ID: <20070721214740.GF2579@dan.emsphone.com> References: <20070720213211.GA7262@saturn.kn-bremen.de> <08469478@srv.sem.ipt.ru> <42375355@srv.sem.ipt.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42375355@srv.sem.ipt.ru> X-OS: FreeBSD 7.0-CURRENT User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-emulation@freebsd.org, freebsd-current@freebsd.org Subject: Re: kqemu and sched_lock, please test port update X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Jul 2007 21:47:42 -0000 In the last episode (Jul 21), Boris Samorodov said: > On Sat, 21 Jul 2007 02:10:33 +0400 Boris Samorodov wrote: > > On Fri, 20 Jul 2007 23:32:11 +0200 Juergen Lock wrote: > > > I just noticed this, and came up with the update below. I still > > > don't have a -current box so I need you to test this before I > > > commit it... > > > Kqemu with the patch compiles well at amd64-current as of > > yesterday. Don't have time ATM to check running. Thanks for the > > patch! > > An attempt to run ended with: > ----- > Program received signal SIGSYS, Bad system call. > 0x0000000800ac8d7c in aio_read () from /lib/libc.so.7 > ----- Looks like you forgot "options VFS_AIO" in your kernel config (or build and load the aio kernel module). -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-current@FreeBSD.ORG Sat Jul 21 21:52:46 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0591216A417; Sat, 21 Jul 2007 21:52:46 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from mail.ipt.ru (mail.ipt.ru [194.62.233.102]) by mx1.freebsd.org (Postfix) with ESMTP id AA99613C48D; Sat, 21 Jul 2007 21:52:45 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from admin.sem.ipt.ru ([192.168.12.1] helo=ipt.ru) by mail.ipt.ru with esmtp (Exim 4.62 (FreeBSD)) (envelope-from ) id 1ICMsX-0009ZC-Fu; Sun, 22 Jul 2007 01:52:45 +0400 Received: from bsam by ipt.ru with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1ICMsk-0003pb-20; Sun, 22 Jul 2007 01:52:58 +0400 To: Dan Nelson References: <20070720213211.GA7262@saturn.kn-bremen.de> <08469478@srv.sem.ipt.ru> <42375355@srv.sem.ipt.ru> <20070721214740.GF2579@dan.emsphone.com> From: Boris Samorodov Date: Sun, 22 Jul 2007 01:52:58 +0400 In-Reply-To: <20070721214740.GF2579@dan.emsphone.com> (Dan Nelson's message of "Sat\, 21 Jul 2007 16\:47\:41 -0500") Message-ID: <56617173@srv.sem.ipt.ru> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.99 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-emulation@freebsd.org, freebsd-current@freebsd.org Subject: Re: kqemu and sched_lock, please test port update X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Jul 2007 21:52:46 -0000 On Sat, 21 Jul 2007 16:47:41 -0500 Dan Nelson wrote: > In the last episode (Jul 21), Boris Samorodov said: > > On Sat, 21 Jul 2007 02:10:33 +0400 Boris Samorodov wrote: > > > On Fri, 20 Jul 2007 23:32:11 +0200 Juergen Lock wrote: > > > > I just noticed this, and came up with the update below. I still > > > > don't have a -current box so I need you to test this before I > > > > commit it... > > > > > Kqemu with the patch compiles well at amd64-current as of > > > yesterday. Don't have time ATM to check running. Thanks for the > > > patch! > > > > An attempt to run ended with: > > ----- > > Program received signal SIGSYS, Bad system call. > > 0x0000000800ac8d7c in aio_read () from /lib/libc.so.7 > > ----- > Looks like you forgot "options VFS_AIO" in your kernel config (or build > and load the aio kernel module). Thanks, Dan. That was it. Robert have just bumped this idea into my silly head... ;-) WBR -- Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-current@FreeBSD.ORG Sat Jul 21 22:18:31 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 08E4416A41B for ; Sat, 21 Jul 2007 22:18:31 +0000 (UTC) (envelope-from timur@com.bat.ru) Received: from mail.bat.ru (dzokonda.xs4all.nl [194.109.164.75]) by mx1.freebsd.org (Postfix) with ESMTP id 6C57313C47E for ; Sat, 21 Jul 2007 22:18:30 +0000 (UTC) (envelope-from timur@com.bat.ru) Received: from timur.home.bat.ru ([192.168.0.4] verified) by mail.bat.ru (CommuniGate Pro SMTP 4.2.7) with ESMTP-TLS id 493425; Sun, 22 Jul 2007 00:20:11 +0200 Received: (from timur@localhost) by timur.home.bat.ru (8.14.1/8.14.1/Submit) id l6LMITOC016925; Sun, 22 Jul 2007 00:18:29 +0200 (CEST) (envelope-from timur) Date: Sun, 22 Jul 2007 00:18:29 +0200 From: "Timur I. Bakeyev" To: Joe Marcus Clarke Message-ID: <20070721221828.GB1874@com.bat.ru> References: <46633B27.50601@dva.dyndns.org> <1c5c32890707031732s195a97c3vd29fb46323f28fae@mail.gmail.com> <46644820.6020609@dva.dyndns.org> <1c5c32890707041057x75712a20vef9800a7ddef7a6a@mail.gmail.com> <1183674495.75595.14.camel@worf> <1c5c32890707051739t6621e2d4ude73ce5d096ea72e@mail.gmail.com> <1183698637.55166.58.camel@shumai.marcuscom.com> <1c5c32890707052219p61c4abd4s7be4dd7c51a8246e@mail.gmail.com> <1183699446.55166.62.camel@shumai.marcuscom.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="M38YqGLZlgb6RLPS" Content-Disposition: inline In-Reply-To: <1183699446.55166.62.camel@shumai.marcuscom.com> User-Agent: mutt-ng/devel-r804 (FreeBSD) X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Pascal Hofstee , current , "Boris S." , Brian Donnell Subject: Re: ZFS vs Samba Debugging Results ... Need Help. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Jul 2007 22:18:31 -0000 --M38YqGLZlgb6RLPS Content-Type: multipart/mixed; boundary="NU0Ex4SbNnrxsi6C" Content-Disposition: inline --NU0Ex4SbNnrxsi6C Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi all! On Fri, Jul 06, 2007 at 01:24:06AM -0400, Joe Marcus Clarke wrote: >=20 > The behavior of telldir/closedir on FreeBSD is the same as when these > replacement functions were written (i.e. the unused telldir() linked > list nodes need to be freed in closedir()). I'm not certain about the > rmdir issue to which the comments also refer. >=20 > Julian's recent post from the Samba people indicates they still think > the code is needed. Here I attach a tarball with the simple test written by Andrew Tridgell (Makefile I drafted myself, original was lost, so blame me if any) which somehow proves, that we do have some problems with the consistency of telldir/seekdir behaviour in FreeBD. So, please run this tests against ZFS and whichever else you want FS and check, does the problem still exists and, maybe - how it can be solved in a better and portable way. =46rom my side I can only confirm it's still a problem on FreeBSD-STABLE on UFS2. With regards, Timur Bakeyev. --NU0Ex4SbNnrxsi6C-- --M38YqGLZlgb6RLPS Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGooY0C/BkEmC6H0cRAgHpAKDQrjMP8/Fp4Nidfloxfrof3PsCcwCfbVBA Bv8kkXMAq5L8VGEWAz0RZ5k= =xC7U -----END PGP SIGNATURE----- --M38YqGLZlgb6RLPS-- From owner-freebsd-current@FreeBSD.ORG Sat Jul 21 22:30:32 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0D9B816A558; Sat, 21 Jul 2007 22:30:28 +0000 (UTC) (envelope-from peter@wemm.org) Received: from overcee.wemm.org (unknown [IPv6:2001:5a8:4:2140:21b:fcff:fe24:feef]) by mx1.freebsd.org (Postfix) with ESMTP id E35CB13C469; Sat, 21 Jul 2007 22:30:17 +0000 (UTC) (envelope-from peter@wemm.org) Received: from overcee.wemm.org (localhost [127.0.0.1]) by overcee.wemm.org (8.14.1/8.14.1) with ESMTP id l6LMUCam000665; Sat, 21 Jul 2007 15:30:17 -0700 (PDT) (envelope-from peter@wemm.org) Received: from localhost (localhost [[UNIX: localhost]]) by overcee.wemm.org (8.14.1/8.14.1/Submit) id l6KItiwK014161; Fri, 20 Jul 2007 11:55:44 -0700 (PDT) (envelope-from peter@wemm.org) X-Authentication-Warning: overcee.wemm.org: peter set sender to peter@wemm.org using -f From: Peter Wemm To: freebsd-current@freebsd.org Date: Fri, 20 Jul 2007 11:55:44 -0700 User-Agent: KMail/1.9.6 References: <20070709234401.S29353@odysseus.silby.com> <20070710132253.GJ1038@void.codelabs.ru> <20070710202028.I34890@odysseus.silby.com> In-Reply-To: <20070710202028.I34890@odysseus.silby.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200707201155.44573.peter@wemm.org> Cc: Andre Oppermann , current@freebsd.org, Mike Silbersack , Robert Watson , net@freebsd.org Subject: Re: FreeBSD 7 TCP syncache fix: request for testers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jul 2007 22:30:32 -0000 On Tuesday 10 July 2007, Mike Silbersack wrote: > On Tue, 10 Jul 2007, Eygene Ryabinkin wrote: > > Can't say that I am pushing much traffic through my box, but after > > applying your patch and rebuilding the kernel I am still seeing the > > messages like > > ----- > > TCP: [209.132.176.NNN]:NNN to [144.206.NNN.NNN]:NNN tcpflags > > 0x19; syncache_expand: Segment failed SYNCOOKIE > > authentication, segment rejected (probably spoofed) TCP: > > [201.90.65.NNN]:NNN to [144.206.NNN.NNN]:NNN; syncache_timer: > > Response timeout ----- > > But what had changed is that the lines with the 'syncache_timer' > > started to appear. There were no such lines prior to the patch, > > only the 'failed SYNCOOKIE' ones. > > The "syncache_timer: Response timeout" message means that the > syncache sent a SYN-ACK response four times, but still didn't receive > a response. This probably means that someone tried using a port > scanner or was going through a faulty firewall. We'll definitely > have to take that log message out before 7.0 is released. > > The fact that you're still getting the syncache_expand message tells > me that there's another bug which I have not yet fixed still present. I get hundreds of these messages within a few hours of boot: [...] TCP: [127.0.0.1]:65491 to [127.0.0.1]:1128 tcpflags 0x10; syncache_expand: Segment failed SYNCOOKIE authentication, segment rejected (probably spoofed) TCP: [127.0.0.1]:64055 to [127.0.0.1]:1128 tcpflags 0x10; syncache_expand: Segment failed SYNCOOKIE authentication, segment rejected (probably spoofed) TCP: [10.0.0.85]:1665 to [10.0.0.3]:139 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected TCP: [127.0.0.1]:60995 to [127.0.0.1]:1128 tcpflags 0x10; syncache_expand: Segment failed SYNCOOKIE authentication, segment rejected (probably spoofed) TCP: [10.0.0.84]:56408 to [10.0.0.3]:22 tcpflags 0x10; syncache_expand: Segment failed SYNCOOKIE authentication, segment rejected (probably spoofed) TCP: [127.0.0.1]:53469 to [127.0.0.1]:1128 tcpflags 0x10; syncache_expand: Segment failed SYNCOOKIE authentication, segment rejected (probably spoofed) TCP: [127.0.0.1]:52446 to [127.0.0.1]:1128 tcpflags 0x10; syncache_expand: Segment failed SYNCOOKIE authentication, segment rejected (probably spoofed) [...] How on earth can localhost be spoofing itself? This is getting quite absurd. :-( Port 1128 is an x10 daemon FWIW. There is just one single client, run from cron every few minutes. There is no congestion on the listen socket. It is an extremely quiet and low volume server. I don't have your patch installed, but am just about to. I mentioned it because you commented that this is a different problem below. > My suspicion is that the "Segment failed SYNCOOKIE authentication" > message is the aftereffect of FreeBSD 7 randomly dropping TCP > connections, and not the problem itself. My theory is that the > connection is silently dropped, without the other endpoint knowing. > That other endpoint then sends an ACK packet, which is then believed > to be a syncookie. Since it is not, it obviously fails the > verification. > > Finding that bug is my next goal. > > > But the patch received only half a day of testing, so I will > > continue the tests and will inform you if some other information > > will be available. Up to date I don't see problems that had > > appeared without the patch, but they tend to show up after a > > midnight ;)) > > > > Thank you! > > Thanks for testing, I look forward to hearing how things work for > you. I'll give your patch a shot and see if it improves things at all. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 From owner-freebsd-current@FreeBSD.ORG Sat Jul 21 22:30:32 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1777F16A560; Sat, 21 Jul 2007 22:30:32 +0000 (UTC) (envelope-from peter@wemm.org) Received: from overcee.wemm.org (unknown [IPv6:2001:5a8:4:2140:21b:fcff:fe24:feef]) by mx1.freebsd.org (Postfix) with ESMTP id BCF7513C457; Sat, 21 Jul 2007 22:30:19 +0000 (UTC) (envelope-from peter@wemm.org) Received: from overcee.wemm.org (localhost [127.0.0.1]) by overcee.wemm.org (8.14.1/8.14.1) with ESMTP id l6LMUCam000665; Sat, 21 Jul 2007 15:30:17 -0700 (PDT) (envelope-from peter@wemm.org) Received: from localhost (localhost [[UNIX: localhost]]) by overcee.wemm.org (8.14.1/8.14.1/Submit) id l6KItiwK014161; Fri, 20 Jul 2007 11:55:44 -0700 (PDT) (envelope-from peter@wemm.org) X-Authentication-Warning: overcee.wemm.org: peter set sender to peter@wemm.org using -f From: Peter Wemm To: freebsd-current@freebsd.org Date: Fri, 20 Jul 2007 11:55:44 -0700 User-Agent: KMail/1.9.6 References: <20070709234401.S29353@odysseus.silby.com> <20070710132253.GJ1038@void.codelabs.ru> <20070710202028.I34890@odysseus.silby.com> In-Reply-To: <20070710202028.I34890@odysseus.silby.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200707201155.44573.peter@wemm.org> Cc: Andre Oppermann , current@freebsd.org, Mike Silbersack , Robert Watson , net@freebsd.org Subject: Re: FreeBSD 7 TCP syncache fix: request for testers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jul 2007 22:30:32 -0000 On Tuesday 10 July 2007, Mike Silbersack wrote: > On Tue, 10 Jul 2007, Eygene Ryabinkin wrote: > > Can't say that I am pushing much traffic through my box, but after > > applying your patch and rebuilding the kernel I am still seeing the > > messages like > > ----- > > TCP: [209.132.176.NNN]:NNN to [144.206.NNN.NNN]:NNN tcpflags > > 0x19; syncache_expand: Segment failed SYNCOOKIE > > authentication, segment rejected (probably spoofed) TCP: > > [201.90.65.NNN]:NNN to [144.206.NNN.NNN]:NNN; syncache_timer: > > Response timeout ----- > > But what had changed is that the lines with the 'syncache_timer' > > started to appear. There were no such lines prior to the patch, > > only the 'failed SYNCOOKIE' ones. > > The "syncache_timer: Response timeout" message means that the > syncache sent a SYN-ACK response four times, but still didn't receive > a response. This probably means that someone tried using a port > scanner or was going through a faulty firewall. We'll definitely > have to take that log message out before 7.0 is released. > > The fact that you're still getting the syncache_expand message tells > me that there's another bug which I have not yet fixed still present. I get hundreds of these messages within a few hours of boot: [...] TCP: [127.0.0.1]:65491 to [127.0.0.1]:1128 tcpflags 0x10; syncache_expand: Segment failed SYNCOOKIE authentication, segment rejected (probably spoofed) TCP: [127.0.0.1]:64055 to [127.0.0.1]:1128 tcpflags 0x10; syncache_expand: Segment failed SYNCOOKIE authentication, segment rejected (probably spoofed) TCP: [10.0.0.85]:1665 to [10.0.0.3]:139 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected TCP: [127.0.0.1]:60995 to [127.0.0.1]:1128 tcpflags 0x10; syncache_expand: Segment failed SYNCOOKIE authentication, segment rejected (probably spoofed) TCP: [10.0.0.84]:56408 to [10.0.0.3]:22 tcpflags 0x10; syncache_expand: Segment failed SYNCOOKIE authentication, segment rejected (probably spoofed) TCP: [127.0.0.1]:53469 to [127.0.0.1]:1128 tcpflags 0x10; syncache_expand: Segment failed SYNCOOKIE authentication, segment rejected (probably spoofed) TCP: [127.0.0.1]:52446 to [127.0.0.1]:1128 tcpflags 0x10; syncache_expand: Segment failed SYNCOOKIE authentication, segment rejected (probably spoofed) [...] How on earth can localhost be spoofing itself? This is getting quite absurd. :-( Port 1128 is an x10 daemon FWIW. There is just one single client, run from cron every few minutes. There is no congestion on the listen socket. It is an extremely quiet and low volume server. I don't have your patch installed, but am just about to. I mentioned it because you commented that this is a different problem below. > My suspicion is that the "Segment failed SYNCOOKIE authentication" > message is the aftereffect of FreeBSD 7 randomly dropping TCP > connections, and not the problem itself. My theory is that the > connection is silently dropped, without the other endpoint knowing. > That other endpoint then sends an ACK packet, which is then believed > to be a syncookie. Since it is not, it obviously fails the > verification. > > Finding that bug is my next goal. > > > But the patch received only half a day of testing, so I will > > continue the tests and will inform you if some other information > > will be available. Up to date I don't see problems that had > > appeared without the patch, but they tend to show up after a > > midnight ;)) > > > > Thank you! > > Thanks for testing, I look forward to hearing how things work for > you. I'll give your patch a shot and see if it improves things at all. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 From owner-freebsd-current@FreeBSD.ORG Sat Jul 21 22:52:16 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A346116A417 for ; Sat, 21 Jul 2007 22:52:16 +0000 (UTC) (envelope-from timur@com.bat.ru) Received: from mail.bat.ru (dzokonda.xs4all.nl [194.109.164.75]) by mx1.freebsd.org (Postfix) with ESMTP id 2E5E513C428 for ; Sat, 21 Jul 2007 22:52:15 +0000 (UTC) (envelope-from timur@com.bat.ru) Received: from timur.home.bat.ru ([192.168.0.4] verified) by mail.bat.ru (CommuniGate Pro SMTP 4.2.7) with ESMTP-TLS id 493464; Sun, 22 Jul 2007 00:53:56 +0200 Received: (from timur@localhost) by timur.home.bat.ru (8.14.1/8.14.1/Submit) id l6LMqEhL017095; Sun, 22 Jul 2007 00:52:14 +0200 (CEST) (envelope-from timur) Date: Sun, 22 Jul 2007 00:52:14 +0200 From: "Timur I. Bakeyev" To: Joe Marcus Clarke Message-ID: <20070721225214.GC1874@com.bat.ru> References: <46633B27.50601@dva.dyndns.org> <1c5c32890707031732s195a97c3vd29fb46323f28fae@mail.gmail.com> <46644820.6020609@dva.dyndns.org> <1c5c32890707041057x75712a20vef9800a7ddef7a6a@mail.gmail.com> <1183674495.75595.14.camel@worf> <1c5c32890707051739t6621e2d4ude73ce5d096ea72e@mail.gmail.com> <1183698637.55166.58.camel@shumai.marcuscom.com> <1c5c32890707052219p61c4abd4s7be4dd7c51a8246e@mail.gmail.com> <1183699446.55166.62.camel@shumai.marcuscom.com> <20070721221828.GB1874@com.bat.ru> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="bi5JUZtvcfApsciF" Content-Disposition: inline In-Reply-To: <20070721221828.GB1874@com.bat.ru> User-Agent: mutt-ng/devel-r804 (FreeBSD) Cc: Brian Donnell , current , "Boris S." , Pascal Hofstee Subject: Re: ZFS vs Samba Debugging Results ... Need Help. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Jul 2007 22:52:16 -0000 --bi5JUZtvcfApsciF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jul 22, 2007 at 12:18:29AM +0200, Timur I. Bakeyev wrote: >=20 > Here I attach a tarball with the simple test written by Andrew Tridgell > (Makefile I drafted myself, original was lost, so blame me if any) which > somehow proves, that we do have some problems with the consistency of > telldir/seekdir behaviour in FreeBD. So, please run this tests against > ZFS and whichever else you want FS and check, does the problem still > exists and, maybe - how it can be solved in a better and portable way. As our ML software strips down attachements - you can find the tarball here: http://unix.bat.ru/FreeBSD/test.tar.gz With best regards, Timur Bakeyev. --bi5JUZtvcfApsciF Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGoo4eC/BkEmC6H0cRAvAYAKDlDuCBvlxytP282KKhvlvavj3cpwCfcDuY LlyNoAqHHREeSyNo31OeyQU= =mWh0 -----END PGP SIGNATURE----- --bi5JUZtvcfApsciF-- From owner-freebsd-current@FreeBSD.ORG Sat Jul 21 22:58:25 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ABD0816A420; Sat, 21 Jul 2007 22:58:25 +0000 (UTC) (envelope-from timur@com.bat.ru) Received: from mail.bat.ru (dzokonda.xs4all.nl [194.109.164.75]) by mx1.freebsd.org (Postfix) with ESMTP id 08EFE13C46A; Sat, 21 Jul 2007 22:58:24 +0000 (UTC) (envelope-from timur@com.bat.ru) Received: from timur.home.bat.ru ([192.168.0.4] verified) by mail.bat.ru (CommuniGate Pro SMTP 4.2.7) with ESMTP-TLS id 493406; Sun, 22 Jul 2007 00:00:06 +0200 Received: (from timur@localhost) by timur.home.bat.ru (8.14.1/8.14.1/Submit) id l6LLwNWs016650; Sat, 21 Jul 2007 23:58:23 +0200 (CEST) (envelope-from timur) Date: Sat, 21 Jul 2007 23:58:23 +0200 From: "Timur I. Bakeyev" To: Joe Marcus Clarke Message-ID: <20070721215822.GA1874@com.bat.ru> References: <46633B27.50601@dva.dyndns.org> <1c5c32890707031732s195a97c3vd29fb46323f28fae@mail.gmail.com> <46644820.6020609@dva.dyndns.org> <1c5c32890707041057x75712a20vef9800a7ddef7a6a@mail.gmail.com> <1183674495.75595.14.camel@worf> <1c5c32890707051739t6621e2d4ude73ce5d096ea72e@mail.gmail.com> <1183698637.55166.58.camel@shumai.marcuscom.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/04w6evG8XlLl3ft" Content-Disposition: inline In-Reply-To: <1183698637.55166.58.camel@shumai.marcuscom.com> User-Agent: mutt-ng/devel-r804 (FreeBSD) Cc: Andrew Tridgell , current , Brian Donnell , "Boris S." , Pascal Hofstee Subject: Re: ZFS vs Samba Debugging Results ... Need Help. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Jul 2007 22:58:25 -0000 --/04w6evG8XlLl3ft Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, guys! You could avoid spending time on debugging this issue, if you'd ask maintainer of the Samba port. Well, somehow it didn't look obvious :)? On Fri, Jul 06, 2007 at 01:10:37AM -0400, Joe Marcus Clarke wrote: > On Thu, 2007-07-05 at 20:39 -0400, Brian Donnell wrote: > >=20 > > And now it works. Just get rid of the offending functions. I've had no > > problems reading or writing files of large and small size in directories > > with only a couple files or a couple hundred. It was so simple it make= s me > > think something is still very wrong. But I'm having no problems now. This is an old standing problem, came as a workaround for some assumptions about the opendir/telldir/seekdir behaviour in the POSIX systems, which made Andrew to write this workaround. Unfortunatelly, it works only on UFS[2] and breaks the things i ZFS, MSDOSFS, ISOFS, UNIONFS, UDF - name them all. I recall an old conversation between PHK and Andrew, when that issue was discussed, together with the workaround, but, seems can't find in in the archives. Anyhow, feel free to add your comments to the: https://bugzilla.samba.org/show_bug.cgi?id=3D4715 There are also similar ports/109160, ports/113158 and few others. Poul, Andrew - can you join this discussion and help us to resort this problem in the best way for the Samba and FreeBSD projects? With best regards, Timur Bakeyev. --/04w6evG8XlLl3ft Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGooF+C/BkEmC6H0cRAnVgAJ9ARFkgLXuUptWtk2UxfjKrTQ1iqgCg0Kia GJvzrPp2kwhahZ5Kebzid6A= =JSK3 -----END PGP SIGNATURE----- --/04w6evG8XlLl3ft-- From owner-freebsd-current@FreeBSD.ORG Sat Jul 21 23:05:43 2007 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D19B216A41F for ; Sat, 21 Jul 2007 23:05:43 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from mail.ipt.ru (mail.ipt.ru [194.62.233.102]) by mx1.freebsd.org (Postfix) with ESMTP id 840AB13C4A5 for ; Sat, 21 Jul 2007 23:05:43 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from stat.sem.ipt.ru ([192.168.12.1] helo=ipt.ru) by mail.ipt.ru with esmtp (Exim 4.62 (FreeBSD)) (envelope-from ) id 1ICO19-0009pO-12 for freebsd-current@FreeBSD.org; Sun, 22 Jul 2007 03:05:43 +0400 Received: from bsam by ipt.ru with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1ICO1L-0003vB-MT for freebsd-current@FreeBSD.org; Sun, 22 Jul 2007 03:05:55 +0400 To: freebsd-current@FreeBSD.org References: <88771431@srv.sem.ipt.ru> From: Boris Samorodov Date: Sun, 22 Jul 2007 03:05:55 +0400 In-Reply-To: <88771431@srv.sem.ipt.ru> (Boris Samorodov's message of "Sun\, 22 Jul 2007 00\:42\:00 +0400") Message-ID: <63817260@srv.sem.ipt.ru> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.99 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit Cc: Subject: Re: postgresql in a jail: manually starts but not while booting X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Jul 2007 23:05:43 -0000 On Sun, 22 Jul 2007 00:42:00 +0400 Boris Samorodov wrote: > I've got a recent amd64-current with postgresql in a jail. The > database master process starts from command line but not when > the host system is booted (and the jail is auto-started): > ----- > Jul 22 00:10:17 pg postgres[1134]: [2-1] FATAL: could not create shared memory segment: Function not implemented > Jul 22 00:10:17 pg postgres[1134]: [2-2] ðïäòïâîïóôé: Failed system call was shmget(key=5432001, size=39149568, 03600). > ----- OK, I found the culprit. Seems that man jail(8) may be polished a little. From man jail(8), section "Starting the Jail": ----- It is possible to have jails started at boot time. Please refer to the ``jail_*'' variables in rc.conf(5) for more information. ----- I propose to add the following note to man jail(8): ----- Note: those variables override sysctl values (both current and from /etc/sysctl.conf). ----- WBR -- Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD committer, http://www.FreeBSD.org The Power To Serve