From owner-freebsd-current@FreeBSD.ORG Sun Jul 22 00:12:45 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 198B916A469 for ; Sun, 22 Jul 2007 00:12:45 +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 7A72013C46C for ; Sun, 22 Jul 2007 00:12:44 +0000 (UTC) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (iwf3ar2rciu244fc@localhost.funkthat.com [127.0.0.1]) by hydrogen.funkthat.com (8.13.6/8.13.3) with ESMTP id l6M0CgaY076966; Sat, 21 Jul 2007 17:12:42 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.13.6/8.13.3/Submit) id l6M0Cffd076965; Sat, 21 Jul 2007 17:12:41 -0700 (PDT) (envelope-from jmg) Date: Sat, 21 Jul 2007 17:12:40 -0700 From: John-Mark Gurney To: Scott Long Message-ID: <20070722001240.GA1221@funkthat.com> Mail-Followup-To: Scott Long , David Christensen , pyunyh@gmail.com, current@freebsd.org 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <469EEF02.7000804@samsco.org> 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: pyunyh@gmail.com, 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 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, 22 Jul 2007 00:12:45 -0000 Scott Long wrote this message on Thu, Jul 19, 2007 at 00:56 -0400: > 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. My vote would be to keep the existing api, and add a flag to the tag to select which backend to use... -- 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 22 00:15: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 B1F2816A419 for ; Sun, 22 Jul 2007 00:15:17 +0000 (UTC) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (gate.funkthat.com [69.17.45.168]) by mx1.freebsd.org (Postfix) with ESMTP id 886AF13C45E for ; Sun, 22 Jul 2007 00:15:17 +0000 (UTC) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (4mcgjwud5vu7ipnn@localhost.funkthat.com [127.0.0.1]) by hydrogen.funkthat.com (8.13.6/8.13.3) with ESMTP id l6M0FFbQ077015; Sat, 21 Jul 2007 17:15:15 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.13.6/8.13.3/Submit) id l6M0FE2Y077014; Sat, 21 Jul 2007 17:15:14 -0700 (PDT) (envelope-from jmg) Date: Sat, 21 Jul 2007 17:15:14 -0700 From: John-Mark Gurney To: kevin kramer Message-ID: <20070722001514.GB1221@funkthat.com> Mail-Followup-To: kevin kramer , freebsd-current@freebsd.org References: <469E3B7C.4020402@centtech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <469E3B7C.4020402@centtech.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: 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: 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, 22 Jul 2007 00:15:17 -0000 kevin kramer wrote this message on Wed, Jul 18, 2007 at 11:10 -0500: > 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? running the process under ktrace would help identify what it is waiting for... Though if it usually hangs for a minute or two in kqread, and then continues, it's probably a DNS lookup issue... -- 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 22 00:19: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 611AF16A419 for ; Sun, 22 Jul 2007 00:19:15 +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 1806C13C442 for ; Sun, 22 Jul 2007 00:19:15 +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 1ICP8z-000A1c-7j for freebsd-current@FreeBSD.org; Sun, 22 Jul 2007 04:19:15 +0400 Received: from bsam by ipt.ru with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1ICP9C-00040f-4E for freebsd-current@FreeBSD.org; Sun, 22 Jul 2007 04:18:06 +0400 To: freebsd-current@FreeBSD.org From: Boris Samorodov Date: Sun, 22 Jul 2007 04:18:06 +0400 Message-ID: <97732929@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: Subject: mount_nullfs inside a jail X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Jul 2007 00:19:15 -0000 Hi! Is it possible to use mount_nullfs inside a jail? With amd64-current: ----- # sysctl security.jail security.jail.jailed: 1 security.jail.mount_allowed: 1 security.jail.chflags_allowed: 1 security.jail.allow_raw_sockets: 0 security.jail.enforce_statfs: 2 security.jail.sysvipc_allowed: 1 security.jail.socket_unixiproute_only: 1 security.jail.set_hostname_allowed: 1 # mount_nullfs /usr/ports /mnt mount_nullfs: Operation not permitted ----- Thanks! 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 Sun Jul 22 00:23:44 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 7CC1816A41A for ; Sun, 22 Jul 2007 00:23:44 +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 1778E13C468 for ; Sun, 22 Jul 2007 00:23:43 +0000 (UTC) (envelope-from dmw@unete.cl) Received: (qmail 7710 invoked from network); 22 Jul 2007 00:23:42 -0000 X-Spam-DCC: : mail03.ifxnetworks.com 104; Body=1 Fuz1=1 Fuz2=1 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on mail03.ifxnetworks.com X-Spam-Level: X-Spam-Status: No, score=0.1 required=7.0 tests=RDNS_NONE autolearn=disabled version=3.2.1 Received: from unknown (HELO quake) (dmw@unete.cl@[200.73.82.118]) (envelope-sender ) by mail03.ifxnetworks.com (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 22 Jul 2007 00:23:42 -0000 From: Daniel Molina Wegener Organization: DMW To: "FreeBSD -CURRENT" Date: Sat, 21 Jul 2007 20:23:03 -0400 User-Agent: KMail/1.9.6 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200707212023.03993.dmw@unete.cl> Subject: Every time I get the sources I can't compile... 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: Sun, 22 Jul 2007 00:23:44 -0000 Hello, Every time I get the sources I can't compile the source tree,=20 buildworld fails or buildkernel fails. =C2=BFIs any way to know=20 which revision is working? I've tried with the GENERIC kernel and fails, custom kernel=20 configurations fails too. =C2=BFAny way to get a working copy of -CURRENT? Regards, =2D-=20 .O. | Daniel Molina Wegener | C/C++ Developer ..O | dmw [at] unete [dot] cl | FOSS Coding Adict OOO | BSD & Linux User | Standards Rocks! From owner-freebsd-current@FreeBSD.ORG Sun Jul 22 00:31: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 9232816A418 for ; Sun, 22 Jul 2007 00:31:05 +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 750E313C481 for ; Sun, 22 Jul 2007 00:31:05 +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 l6M0UiBu004821; Sat, 21 Jul 2007 17:30:44 -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 l6M0Ui51004820; Sat, 21 Jul 2007 17:30:44 -0700 (PDT) (envelope-from sgk) Date: Sat, 21 Jul 2007 17:30:44 -0700 From: Steve Kargl To: Daniel Molina Wegener Message-ID: <20070722003044.GA4770@troutmask.apl.washington.edu> References: <200707212023.03993.dmw@unete.cl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200707212023.03993.dmw@unete.cl> User-Agent: Mutt/1.4.2.3i Cc: FreeBSD -CURRENT Subject: Re: Every time I get the sources I can't compile... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Jul 2007 00:31:05 -0000 On Sat, Jul 21, 2007 at 08:23:03PM -0400, Daniel Molina Wegener wrote: > > Hello, > > Every time I get the sources I can't compile the source tree, > buildworld fails or buildkernel fails. ??Is any way to know > which revision is working? > > I've tried with the GENERIC kernel and fails, custom kernel > configurations fails too. > > ??Any way to get a working copy of -CURRENT? > There's a large amount of missing detail. 1) What architecture? 2) How do you get the source code? 3) Are you setting anything in /etc/make.conf? 4) What is the failure (ie exact error message)? 5) What a minimum description of the hardware? I've rebuilt working -current on i386 and amd64 where the source is retrieved by anoncvs and csup on the different systems in the last two days. -- Steve From owner-freebsd-current@FreeBSD.ORG Sun Jul 22 00:52:04 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 91D2316A420 for ; Sun, 22 Jul 2007 00:52:04 +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 5FAEA13C46E for ; Sun, 22 Jul 2007 00:52:04 +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 l6M0q2hp067255 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO) for ; Sat, 21 Jul 2007 20:52:03 -0400 (EDT) (envelope-from jroberson@chesapeake.net) Date: Sat, 21 Jul 2007 17:55:08 -0700 (PDT) From: Jeff Roberson X-X-Sender: jroberson@10.0.0.1 To: current@freebsd.org Message-ID: <20070721174631.S561@10.0.0.1> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Subject: ULE status, invalid load, buildkernel 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, 22 Jul 2007 00:52:04 -0000 I have a patch available at: http://people.freebsd.org/~jeff/ulehtt.diff This resolves issues in the code that handles HTT enabled processors and also adds some ULE information to bootverbose on SMP systems. Peter Wemm has a seperate patch that fixes a bug where some amd64 cpus were still being misidentified as HTT. Those of you with invalid loads either have Hyper-threading CPUs or misidentified amd cores. You should expect slightly poorer performance as long as your cores are misidentified but the bad loads should be fixed. I also believe that the buildkernel/world times are now significantly improved. If this is not the case for you please send a mail. Any other performance data is appreciated. Thanks, Jeff From owner-freebsd-current@FreeBSD.ORG Sun Jul 22 00:56:04 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 A3BEE16A419; Sun, 22 Jul 2007 00:56:04 +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 DF7DD13C442; Sun, 22 Jul 2007 00:56:03 +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 0977FEB20FC; Sun, 22 Jul 2007 08:56:03 +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 SbzGSdlqJjkQ; Sun, 22 Jul 2007 08:56:01 +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 A9546EB20EF; Sun, 22 Jul 2007 08:56:00 +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; b=lBpg/ADpi0IlEZyijhexQ55pbT6HyB7HD2PsYBFIMJ518JADog+9HSGa285SCI2pN MowRycmbwe8ui/DRKiOPQ== Message-ID: <46A2AB1F.3060507@delphij.net> Date: Sun, 22 Jul 2007 08:55:59 +0800 From: Xin LI User-Agent: Thunderbird 2.0.0.5 (X11/20070721) MIME-Version: 1.0 To: Peter Wemm References: <20070709234401.S29353@odysseus.silby.com> <20070710132253.GJ1038@void.codelabs.ru> <20070710202028.I34890@odysseus.silby.com> <200707201155.44573.peter@wemm.org> In-Reply-To: <200707201155.44573.peter@wemm.org> Content-Type: multipart/mixed; boundary="------------080503060705080206030802" Cc: Andre Oppermann , current@freebsd.org, Mike Silbersack , freebsd-current@freebsd.org, 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: Sun, 22 Jul 2007 00:56:04 -0000 This is a multi-part message in MIME format. --------------080503060705080206030802 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 7bit I was unable to apply Mike's patch so I have manually applied it. Here is a new one that should apply against today's -CURRENT. Cheers, --------------080503060705080206030802 Content-Type: text/x-patch; name="tcp_syncache.c-timerfix.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="tcp_syncache.c-timerfix.patch" Index: tcp_syncache.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/tcp_syncache.c,v retrieving revision 1.123 diff -u -p -r1.123 tcp_syncache.c --- tcp_syncache.c 3 Jul 2007 12:13:43 -0000 1.123 +++ tcp_syncache.c 21 Jul 2007 16:15:07 -0000 @@ -142,7 +142,6 @@ struct syncache_head { struct mtx sch_mtx; TAILQ_HEAD(sch_head, syncache) sch_bucket; struct callout sch_timer; - int sch_nextc; u_int sch_length; u_int sch_oddeven; u_int32_t sch_secbits_odd[SYNCOOKIE_SECRET_SIZE]; @@ -233,16 +232,10 @@ static MALLOC_DEFINE(M_SYNCACHE, "syncac #define ENDPTS6_EQ(a, b) (memcmp(a, b, sizeof(*a)) == 0) -#define SYNCACHE_TIMEOUT(sc, sch, co) do { \ +#define SYNCACHE_TIMEOUT(sc) do { \ (sc)->sc_rxmits++; \ (sc)->sc_rxttime = ticks + \ TCPTV_RTOBASE * tcp_backoff[(sc)->sc_rxmits - 1]; \ - if ((sch)->sch_nextc > (sc)->sc_rxttime) \ - (sch)->sch_nextc = (sc)->sc_rxttime; \ - if (!TAILQ_EMPTY(&(sch)->sch_bucket) && !(co)) \ - callout_reset(&(sch)->sch_timer, \ - (sch)->sch_nextc - ticks, \ - syncache_timer, (void *)(sch)); \ } while (0) #define SCH_LOCK(sch) mtx_lock(&(sch)->sch_mtx) @@ -268,6 +261,7 @@ void syncache_init(void) { int i; + struct syncache_head *sch; tcp_syncache.cache_count = 0; tcp_syncache.hashsize = TCP_SYNCACHE_HASHSIZE; @@ -310,6 +304,17 @@ syncache_init(void) tcp_syncache.zone = uma_zcreate("syncache", sizeof(struct syncache), NULL, NULL, NULL, NULL, UMA_ALIGN_PTR, 0); uma_zone_set_max(tcp_syncache.zone, tcp_syncache.cache_limit); + + /* + * Start the syncache head timers running. They each run ten times + * a second, and are spread out so that they are not all running on + * the same clock tick. + */ + for (i = 0; i < tcp_syncache.hashsize; i++) { + sch = &tcp_syncache.hashbase[i]; + callout_reset(&(sch)->sch_timer, i * (hz / 10), + syncache_timer, (void *)(sch)); + } } /* @@ -339,8 +344,8 @@ syncache_insert(struct syncache *sc, str TAILQ_INSERT_HEAD(&sch->sch_bucket, sc, sc_hash); sch->sch_length++; - /* Reinitialize the bucket row's timer. */ - SYNCACHE_TIMEOUT(sc, sch, 1); + /* Set the retransmit timer for this socket. */ + SYNCACHE_TIMEOUT(sc); SCH_UNLOCK(sch); @@ -390,11 +395,8 @@ syncache_timer(void *xsch) * then the RST will be sent by the time the remote * host does the SYN/ACK->ACK. */ - if (sc->sc_rxttime >= tick) { - if (sc->sc_rxttime < sch->sch_nextc) - sch->sch_nextc = sc->sc_rxttime; + if (sc->sc_rxttime >= tick) continue; - } if (sc->sc_rxmits > tcp_syncache.rexmt_limit) { if ((s = tcp_log_addrs(&sc->sc_inc, NULL, NULL, NULL))) { @@ -409,11 +411,10 @@ syncache_timer(void *xsch) (void) syncache_respond(sc); tcpstat.tcps_sc_retransmitted++; - SYNCACHE_TIMEOUT(sc, sch, 0); + SYNCACHE_TIMEOUT(sc); } - if (!TAILQ_EMPTY(&(sch)->sch_bucket)) - callout_reset(&(sch)->sch_timer, (sch)->sch_nextc - tick, - syncache_timer, (void *)(sch)); + callout_reset(&(sch)->sch_timer, hz / 10, + syncache_timer, (void *)(sch)); } /* @@ -995,7 +996,7 @@ syncache_add(struct in_conninfo *inc, st ("%s: label not initialized", __func__)); #endif if (syncache_respond(sc) == 0) { - SYNCACHE_TIMEOUT(sc, sch, 1); + SYNCACHE_TIMEOUT(sc); tcpstat.tcps_sndacks++; tcpstat.tcps_sndtotal++; } --------------080503060705080206030802-- From owner-freebsd-current@FreeBSD.ORG Sun Jul 22 00:56: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 A3BEE16A419; Sun, 22 Jul 2007 00:56:04 +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 DF7DD13C442; Sun, 22 Jul 2007 00:56:03 +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 0977FEB20FC; Sun, 22 Jul 2007 08:56:03 +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 SbzGSdlqJjkQ; Sun, 22 Jul 2007 08:56:01 +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 A9546EB20EF; Sun, 22 Jul 2007 08:56:00 +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; b=lBpg/ADpi0IlEZyijhexQ55pbT6HyB7HD2PsYBFIMJ518JADog+9HSGa285SCI2pN MowRycmbwe8ui/DRKiOPQ== Message-ID: <46A2AB1F.3060507@delphij.net> Date: Sun, 22 Jul 2007 08:55:59 +0800 From: Xin LI User-Agent: Thunderbird 2.0.0.5 (X11/20070721) MIME-Version: 1.0 To: Peter Wemm References: <20070709234401.S29353@odysseus.silby.com> <20070710132253.GJ1038@void.codelabs.ru> <20070710202028.I34890@odysseus.silby.com> <200707201155.44573.peter@wemm.org> In-Reply-To: <200707201155.44573.peter@wemm.org> Content-Type: multipart/mixed; boundary="------------080503060705080206030802" Cc: Andre Oppermann , current@freebsd.org, Mike Silbersack , freebsd-current@freebsd.org, 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: Sun, 22 Jul 2007 00:56:04 -0000 This is a multi-part message in MIME format. --------------080503060705080206030802 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 7bit I was unable to apply Mike's patch so I have manually applied it. Here is a new one that should apply against today's -CURRENT. Cheers, --------------080503060705080206030802 Content-Type: text/x-patch; name="tcp_syncache.c-timerfix.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="tcp_syncache.c-timerfix.patch" Index: tcp_syncache.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/tcp_syncache.c,v retrieving revision 1.123 diff -u -p -r1.123 tcp_syncache.c --- tcp_syncache.c 3 Jul 2007 12:13:43 -0000 1.123 +++ tcp_syncache.c 21 Jul 2007 16:15:07 -0000 @@ -142,7 +142,6 @@ struct syncache_head { struct mtx sch_mtx; TAILQ_HEAD(sch_head, syncache) sch_bucket; struct callout sch_timer; - int sch_nextc; u_int sch_length; u_int sch_oddeven; u_int32_t sch_secbits_odd[SYNCOOKIE_SECRET_SIZE]; @@ -233,16 +232,10 @@ static MALLOC_DEFINE(M_SYNCACHE, "syncac #define ENDPTS6_EQ(a, b) (memcmp(a, b, sizeof(*a)) == 0) -#define SYNCACHE_TIMEOUT(sc, sch, co) do { \ +#define SYNCACHE_TIMEOUT(sc) do { \ (sc)->sc_rxmits++; \ (sc)->sc_rxttime = ticks + \ TCPTV_RTOBASE * tcp_backoff[(sc)->sc_rxmits - 1]; \ - if ((sch)->sch_nextc > (sc)->sc_rxttime) \ - (sch)->sch_nextc = (sc)->sc_rxttime; \ - if (!TAILQ_EMPTY(&(sch)->sch_bucket) && !(co)) \ - callout_reset(&(sch)->sch_timer, \ - (sch)->sch_nextc - ticks, \ - syncache_timer, (void *)(sch)); \ } while (0) #define SCH_LOCK(sch) mtx_lock(&(sch)->sch_mtx) @@ -268,6 +261,7 @@ void syncache_init(void) { int i; + struct syncache_head *sch; tcp_syncache.cache_count = 0; tcp_syncache.hashsize = TCP_SYNCACHE_HASHSIZE; @@ -310,6 +304,17 @@ syncache_init(void) tcp_syncache.zone = uma_zcreate("syncache", sizeof(struct syncache), NULL, NULL, NULL, NULL, UMA_ALIGN_PTR, 0); uma_zone_set_max(tcp_syncache.zone, tcp_syncache.cache_limit); + + /* + * Start the syncache head timers running. They each run ten times + * a second, and are spread out so that they are not all running on + * the same clock tick. + */ + for (i = 0; i < tcp_syncache.hashsize; i++) { + sch = &tcp_syncache.hashbase[i]; + callout_reset(&(sch)->sch_timer, i * (hz / 10), + syncache_timer, (void *)(sch)); + } } /* @@ -339,8 +344,8 @@ syncache_insert(struct syncache *sc, str TAILQ_INSERT_HEAD(&sch->sch_bucket, sc, sc_hash); sch->sch_length++; - /* Reinitialize the bucket row's timer. */ - SYNCACHE_TIMEOUT(sc, sch, 1); + /* Set the retransmit timer for this socket. */ + SYNCACHE_TIMEOUT(sc); SCH_UNLOCK(sch); @@ -390,11 +395,8 @@ syncache_timer(void *xsch) * then the RST will be sent by the time the remote * host does the SYN/ACK->ACK. */ - if (sc->sc_rxttime >= tick) { - if (sc->sc_rxttime < sch->sch_nextc) - sch->sch_nextc = sc->sc_rxttime; + if (sc->sc_rxttime >= tick) continue; - } if (sc->sc_rxmits > tcp_syncache.rexmt_limit) { if ((s = tcp_log_addrs(&sc->sc_inc, NULL, NULL, NULL))) { @@ -409,11 +411,10 @@ syncache_timer(void *xsch) (void) syncache_respond(sc); tcpstat.tcps_sc_retransmitted++; - SYNCACHE_TIMEOUT(sc, sch, 0); + SYNCACHE_TIMEOUT(sc); } - if (!TAILQ_EMPTY(&(sch)->sch_bucket)) - callout_reset(&(sch)->sch_timer, (sch)->sch_nextc - tick, - syncache_timer, (void *)(sch)); + callout_reset(&(sch)->sch_timer, hz / 10, + syncache_timer, (void *)(sch)); } /* @@ -995,7 +996,7 @@ syncache_add(struct in_conninfo *inc, st ("%s: label not initialized", __func__)); #endif if (syncache_respond(sc) == 0) { - SYNCACHE_TIMEOUT(sc, sch, 1); + SYNCACHE_TIMEOUT(sc); tcpstat.tcps_sndacks++; tcpstat.tcps_sndtotal++; } --------------080503060705080206030802-- From owner-freebsd-current@FreeBSD.ORG Sun Jul 22 01:00: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 983B116A469 for ; Sun, 22 Jul 2007 01:00:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [62.111.66.27]) by mx1.freebsd.org (Postfix) with ESMTP id 1628413C46B for ; Sun, 22 Jul 2007 01:00:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from localhost (amavis.str.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 44BF341C656; Sun, 22 Jul 2007 03:00:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([62.111.66.27]) by localhost (amavis.str.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id oyH8mvavHtMI; Sun, 22 Jul 2007 03:00:05 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id DBD9241C655; Sun, 22 Jul 2007 03:00:05 +0200 (CEST) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 85BE6444885; Sun, 22 Jul 2007 00:55:20 +0000 (UTC) Date: Sun, 22 Jul 2007 00:55:20 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Teufel In-Reply-To: <46A10142.1030807@kuehlbox.de> Message-ID: <20070722004347.P31116@maildrop.int.zabbadoz.net> References: <20070601105521.D77697@fledge.watson.org> <20070601125901.W92469@fw.reifenberger.com> <20070601.131946.71174943.imp@bsdimp.com> <200706040941.16507.hselasky@c2i.net> <46A10142.1030807@kuehlbox.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD current mailing list Subject: Re: NET_NEEDS_GIANT removal X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-isdn@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: Sun, 22 Jul 2007 01:00:07 -0000 On Fri, 20 Jul 2007, Teufel wrote: Hi, > is there any issue to replace i4b on -CURRENT with HPS one? I have had in addition to what Warner said, read this thread.... http://lists.freebsd.org/pipermail/freebsd-isdn/2005-August/thread.html#420 "New ISDN driver" I4B is only mostly disabled in HEAD and should be back with 7.1. Maybe earlier, hopefully not later. It's not (yet) deleted and will not be deleted unless something really bad happens(tm). Either problem was well known for almost two years but noone made things change and that's why we are where we are... -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT Software is harder than hardware so better get it right the first time. From owner-freebsd-current@FreeBSD.ORG Sun Jul 22 01:36:38 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 A8EE916A418 for ; Sun, 22 Jul 2007 01:36: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 8BFB013C458 for ; Sun, 22 Jul 2007 01:36:38 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from neutrino.vnode.org (r74-193-81-203.pfvlcmta01.grtntx.tl.dh.suddenlink.net [74.193.81.203]) (authenticated bits=0) by ns.trinitel.com (8.14.1/8.14.1) with ESMTP id l6M1abs8040941 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO) for ; Sat, 21 Jul 2007 20:36:37 -0500 (CDT) (envelope-from anderson@freebsd.org) Message-ID: <46A2B49F.4030307@freebsd.org> Date: Sat, 21 Jul 2007 20:36:31 -0500 From: Eric Anderson User-Agent: Thunderbird 2.0.0.4 (X11/20070629) MIME-Version: 1.0 To: freebsd-current@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=failed version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on ns.trinitel.com Subject: LOR's, and a panic (ipf NAT related?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Jul 2007 01:36:38 -0000 Today, on a -CURRENT from a few days ago (running ULE 3.0), I got a panic: panic: Trying sleep, but thread marked as sleeping prohibited cpuid = 0 #8 0xc074a474 in panic (fmt=0xc0a979a9 "Trying sleep, but thread marked as sleeping prohibited") at /usr/src/sys/kern/kern_shutdown.c:547 #9 0xc077abd2 in sleepq_add (wchan=0xc0e20980, lock=0x0, wmesg=0xc0e1b709 "ipf IP NAT rwlock", flags=3, queue=0) at /usr/src/sys/kern/subr_sleepqueue.c:289 #10 0xc07519ee in _sx_xlock_hard (sx=0xc0e20980, tid=3306307584, opts=0, file=0xc0e1b65e "/usr/src/sys/modules/ipfilter/../../contrib/ipfilter/netinet/ip_nat.c", line=4384) at /usr/src/sys/kern/kern_sx.c:548 #11 0xc0751d18 in _sx_xlock (sx=0xc0e20980, opts=0, file=0xc0e1b65e "/usr/src/sys/modules/ipfilter/../../contrib/ipfilter/netinet/ip_nat.c", line=4384) at sx.h:153 I also see these (maybe related) LOR's on bootup: lock order reversal: (sleepable after non-sleepable) 1st 0xc0e207f0 ipf nat io mutex (ipf nat io mutex) @ /usr/src/sys/modules/ipfilter/../../contrib/ipfilter/netinet/ip_nat.c:710 2nd 0xc0e20980 ipf IP NAT rwlock (ipf IP NAT rwlock) @ /usr/src/sys/modules/ipfilter/../../contrib/ipfilter/netinet/ip_nat.c:1062 KDB: stack backtrace: db_trace_self_wrapper(c0a96ace,e7a6ddc8,c0782f8e,c0a98fa0,c0e20980,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c0a98fa0,c0e20980,c0e1b709,c0e1b709,c0e1b65e,...) at kdb_backtrace+0x29 witness_checkorder(c0e20980,9,c0e1b65e,426,4,...) at witness_checkorder+0x6de _sx_xlock(c0e20980,0,c0e1b65e,426,0,...) at _sx_xlock+0x7d fr_nat_ioctl(c55d26c0,8034723c,3,0,c561d880,...) at fr_nat_ioctl+0x6ab fr_ioctlswitch(1,c55d26c0,8034723c,3,0,...) at fr_ioctlswitch+0x79 iplioctl(c53b3a00,8034723c,c55d26c0,3,c561d880,...) at iplioctl+0xd8 devfs_ioctl_f(c5643af8,8034723c,c55d26c0,c5740a00,c561d880,...) at devfs_ioctl_f+0xc9 kern_ioctl(c561d880,3,8034723c,c55d26c0,0,...) at kern_ioctl+0x243 ioctl(c561d880,e7a6ecfc,c,c,c0b40130,...) at ioctl+0x134 syscall(e7a6ed38) at syscall+0x2b3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x28167e53, esp = 0xbfbfec9c, ebp = 0xbfbfed08 --- lock order reversal: (sleepable after non-sleepable) 1st 0xc0bfb798 PFil hook read/write mutex (PFil hook read/write mutex) @ /usr/src/sys/net/pfil.c:73 2nd 0xc0e20880 ipf filter load/unload mutex (ipf filter load/unload mutex) @ /usr/src/sys/modules/ipfilter/../../contrib/ipfilter/netinet/fil.c:2419 KDB: stack backtrace: db_trace_self_wrapper(c0a96ace,e3cc299c,c0782f8e,c0a98fa0,c0e20880,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c0a98fa0,c0e20880,c0e1b400,c0e1b400,c0e1c7c1,...) at kdb_backtrace+0x29 witness_checkorder(c0e20880,1,c0e1c7c1,973,c53f1000,...) at witness_checkorder+0x6de _sx_slock(c0e20880,0,c0e1c7c1,973,c5126880,...) at _sx_slock+0x7d fr_check(c57be024,14,c5269400,0,e3cc2ad0,...) at fr_check+0x5a fr_check_wrapper(0,e3cc2ad0,c5269400,1,0,...) at fr_check_wrapper+0x3f pfil_run_hooks(c0bfb780,e3cc2b24,c5269400,1,0,...) at pfil_run_hooks+0x88 ip_input(c5782200,c0652b32,800,c5269400,800,...) at ip_input+0x24d netisr_dispatch(2,c5782200,46a266ac,89ca3,c5269400,...) at netisr_dispatch+0x73 ether_demux(c5269400,c5782200,3,0,3,...) at ether_demux+0x1f1 ether_input(c5269400,c5782200,18,c0780d4e,c5782200,...) at ether_input+0x37f ieee80211_deliver_data(c526a22c,c57df000,c5782200,18,c0aa34ce,...) at ieee80211_deliver_data+0x13e ieee80211_input(c526a22c,c5782200,c57df000,21,ffffffaa,...) at ieee80211_input+0x1159 ath_rx_proc(c526a000,1,c0a97ce7,52,c527bb9c,...) at ath_rx_proc+0x52d taskqueue_run(c527bb80,c527bb9c,0,c0a8b649,0,...) at taskqueue_run+0x10b taskqueue_thread_loop(c526b65c,e3cc2d38,c0a9069e,315,c5223000,...) at taskqueue_thread_loop+0x68 fork_exit(c077c220,c526b65c,e3cc2d38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe3cc2d70, ebp = 0 --- I have a vmcore if anyone wants me to debug further.. Eric From owner-freebsd-current@FreeBSD.ORG Sun Jul 22 01:42: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 7DAA916A418; Sun, 22 Jul 2007 01:42:39 +0000 (UTC) (envelope-from tridge@samba.org) Received: from lists.samba.org (mail.samba.org [66.70.73.150]) by mx1.freebsd.org (Postfix) with ESMTP id 3FD9713C459; Sun, 22 Jul 2007 01:42:39 +0000 (UTC) (envelope-from tridge@samba.org) Received: by lists.samba.org (Postfix, from userid 603) id 74EAB162AD4; Sun, 22 Jul 2007 01:23:11 +0000 (GMT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18082.45557.77020.398761@samba.org> Date: Sun, 22 Jul 2007 11:25:09 +1000 To: "Timur I. Bakeyev" In-Reply-To: <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> <20070721215822.GA1874@com.bat.ru> X-Mailer: VM 7.19 under Emacs 22.0.95.1 From: tridge@samba.org X-Mailman-Approved-At: Sun, 22 Jul 2007 02:05:03 +0000 Cc: 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 Reply-To: tridge@samba.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jul 2007 01:42:39 -0000 Timur, > 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 yes, this is a long standing problem. Basically we need telldir()/seekdir() to actually work, and not consume unlimited amounts of memory. The original problems were: - when you use seekdir() after having deleted a file in the directory, you end up in the wrong place in the directory stream. - on some systems each telldir() allocates some memory, adding it to a linked list. So if you do it a few million times then you lose a lot of memory, and the closedir() takes an extraordinary amount of time as it slowly frees the linked list Here are our current attempts to fix this problem: http://samba.org/ftp/unpacked/samba4/source/lib/replace/repdir_getdents.c http://samba.org/ftp/unpacked/samba4/source/lib/replace/repdir_getdirentries.c and here is some test code that demonstrates the problem: http://samba.org/ftp/unpacked/samba4/source/lib/replace/test/os2_delete.c It's called os2_delete as this is the pattern of calls that OS/2 clients use against Samba when they want to delete all files in a large directory. It is an insane pattern of calls, but it should work, and it does work if seekdir()/telldir() work correctly. I know this is a difficult problem to fix on some filesystems because of the way directories are stored on disk. The thing is, it is even harder to solve in application code where you have absolutely no knowledge of the directory layout, and are trying to second guess everthing. There are many possible "quick fixes" in Samba. Unfortunately they tend to have O(n^2) time or O(dirsize) memory usage, or both. That's no good unfortunately. Cheers, Tridge From owner-freebsd-current@FreeBSD.ORG Sun Jul 22 02:14:49 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 E954B16A419 for ; Sun, 22 Jul 2007 02:14:49 +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 85C7C13C45E for ; Sun, 22 Jul 2007 02:14:49 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from [192.168.254.15] (ydesk.samsco.home [192.168.254.15]) (authenticated bits=0) by pooker.samsco.org (8.13.8/8.13.8) with ESMTP id l6M2Ehcq081909; Sat, 21 Jul 2007 20:14:44 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <46A2BD94.2030603@samsco.org> Date: Sat, 21 Jul 2007 20:14:44 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.7) Gecko/20050416 X-Accept-Language: en-us, en MIME-Version: 1.0 To: John-Mark Gurney 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> <20070722001240.GA1221@funkthat.com> In-Reply-To: <20070722001240.GA1221@funkthat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (pooker.samsco.org [192.168.254.1]); Sat, 21 Jul 2007 20:14:44 -0600 (MDT) X-Spam-Status: No, score=-1.4 required=5.5 tests=ALL_TRUSTED autolearn=failed version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: pyunyh@gmail.com, 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: Sun, 22 Jul 2007 02:14:50 -0000 John-Mark Gurney wrote: > Scott Long wrote this message on Thu, Jul 19, 2007 at 00:56 -0400: > >>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. > > > My vote would be to keep the existing api, and add a flag to the tag > to select which backend to use... > The potential is to avoid cache line misses by disregarding the tag entirely. Drew has a prototype that shows a very good improvement from this. The alternative approach requires tag accesses, but can easily select an appropriate back-end automatically. The tag fields can probably be rearranged so that only a single cache line is needed. If it were possible to give a prefetching hint, it would be a moot point, but I don't think that it is in this case. Scott From owner-freebsd-current@FreeBSD.ORG Sun Jul 22 04:00: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 CAFD116A419 for ; Sun, 22 Jul 2007 04:00:47 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id 2508313C468 for ; Sun, 22 Jul 2007 04:00:47 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost2.sentex.ca (8.14.1/8.13.8) with ESMTP id l6M40bGj009365; Sun, 22 Jul 2007 00:00:38 -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 l6M40bJ9036873 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 22 Jul 2007 00:00:37 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <200707220400.l6M40bJ9036873@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 22 Jul 2007 00:00:24 -0400 To: Jeff Roberson , current@freebsd.org From: Mike Tancsa In-Reply-To: <20070721174631.S561@10.0.0.1> References: <20070721174631.S561@10.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Subject: Re: ULE status, invalid load, buildkernel 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, 22 Jul 2007 04:00:48 -0000 At 08:55 PM 7/21/2007, Jeff Roberson wrote: >I have a patch available at: > >http://people.freebsd.org/~jeff/ulehtt.diff > >I also believe that the buildkernel/world times are now >significantly improved. If this is not the case for you please send >a mail. Any other performance data is appreciated. on 4 cores with ULE in the tree CPU: Dual Core AMD Opteron(tm) Processor 270 HE (1991.73-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x20f12 Stepping = 2 Features=0x178bfbff Features2=0x1 AMD Features=0xe2500800 AMD Features2=0x3 Cores per package: 2 real memory = 1610547200 (1535 MB) avail memory = 1568690176 (1496 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 [cheetah]# time make -j8 buildkernel > /var/log/build.out.k 843.601u 95.442s 8:46.70 178.2% 5612+1002k 8067+6346io 350pf+0w with patch above [cheetah]# time make -j8 buildkernel > /var/log/build.out.k 841.903u 95.183s 8:38.17 180.8% 5608+1002k 9051+6282io 388pf+0w [cheetah]# ---Mike From owner-freebsd-current@FreeBSD.ORG Sun Jul 22 04:26:58 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 426E816A41A for ; Sun, 22 Jul 2007 04:26:58 +0000 (UTC) (envelope-from lveax.m@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.230]) by mx1.freebsd.org (Postfix) with ESMTP id 0471B13C46A for ; Sun, 22 Jul 2007 04:26:57 +0000 (UTC) (envelope-from lveax.m@gmail.com) Received: by wx-out-0506.google.com with SMTP id i29so1049356wxd for ; Sat, 21 Jul 2007 21:26: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=T74r/EvdSG7UOJtoaFr9hqFCshUUqY54Tuq+Far8MBnMy+OrxXBlhvegCYlhKV/gtL8dhxiQTsExIIIMb+JD4qWs17Cos8PwHuurpT43Psez6UhY6hIYAdn+q6gxwX20kgL3r3GBouhfVjfQENvCeSFlIOsJwjO88SsxJ7ueJ4E= 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=apTCciO6UBEuhCBjG4NmCEsPcQ7mGV8/eOEQsKuMMmQrEx8Lb1qEfgPuE8tY27slYSYjKFE+OPvSZh2uO4Wzaa5ke9/lf48nSpquzI9p4CLqa0x5avF2emBzf11qiFkZeWVhxshbK2nP1rxj0PpWhFj+ObR0I9mUH3kRA14hbSw= Received: by 10.90.63.16 with SMTP id l16mr1263949aga.1185078417114; Sat, 21 Jul 2007 21:26:57 -0700 (PDT) Received: by 10.90.86.8 with HTTP; Sat, 21 Jul 2007 21:26:57 -0700 (PDT) Message-ID: <576dcbc20707212126w3864528cvc0428f50572b385a@mail.gmail.com> Date: Sun, 22 Jul 2007 12:26:57 +0800 From: lveax To: "Mike Tancsa" In-Reply-To: <200707220400.l6M40bJ9036873@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: <20070721174631.S561@10.0.0.1> <200707220400.l6M40bJ9036873@lava.sentex.ca> Cc: Jeff Roberson , current@freebsd.org Subject: Re: ULE status, invalid load, buildkernel 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, 22 Jul 2007 04:26:58 -0000 On 7/22/07, Mike Tancsa wrote: > At 08:55 PM 7/21/2007, Jeff Roberson wrote: > >I have a patch available at: > > > >http://people.freebsd.org/~jeff/ulehtt.diff > > > >I also believe that the buildkernel/world times are now > >significantly improved. If this is not the case for you please send > >a mail. Any other performance data is appreciated. > > on 4 cores with ULE in the tree > CPU: Dual Core AMD Opteron(tm) Processor 270 HE (1991.73-MHz 686-class CPU) > Origin = "AuthenticAMD" Id = 0x20f12 Stepping = 2 > Features=0x178bfbff > Features2=0x1 > AMD Features=0xe2500800 > AMD Features2=0x3 > Cores per package: 2 > real memory = 1610547200 (1535 MB) > avail memory = 1568690176 (1496 MB) > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 1 > cpu2 (AP): APIC ID: 2 > cpu3 (AP): APIC ID: 3 > > [cheetah]# time make -j8 buildkernel > /var/log/build.out.k > 843.601u 95.442s 8:46.70 178.2% 5612+1002k 8067+6346io 350pf+0w > with patch above > [cheetah]# time make -j8 buildkernel > > /var/log/build.out.k > 841.903u 95.183s 8:38.17 180.8% 5608+1002k 9051+6282io 388pf+0w > [cheetah]# Could you make a test with 4bsd? From owner-freebsd-current@FreeBSD.ORG Sun Jul 22 04:36: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 8642C16A419 for ; Sun, 22 Jul 2007 04:36:11 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id 3C77413C45B for ; Sun, 22 Jul 2007 04:36:11 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost2.sentex.ca (8.14.1/8.13.8) with ESMTP id l6M4a4CN010636; Sun, 22 Jul 2007 00:36:04 -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 l6M4a3QC037029 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 22 Jul 2007 00:36:03 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <200707220436.l6M4a3QC037029@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 22 Jul 2007 00:35:51 -0400 To: lveax From: Mike Tancsa In-Reply-To: <576dcbc20707212126w3864528cvc0428f50572b385a@mail.gmail.co m> References: <20070721174631.S561@10.0.0.1> <200707220400.l6M40bJ9036873@lava.sentex.ca> <576dcbc20707212126w3864528cvc0428f50572b385a@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Jeff Roberson , current@freebsd.org Subject: Re: ULE status, invalid load, buildkernel 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, 22 Jul 2007 04:36:12 -0000 At 12:26 AM 7/22/2007, lveax wrote: >On 7/22/07, Mike Tancsa wrote: >>At 08:55 PM 7/21/2007, Jeff Roberson wrote: >> >I have a patch available at: >> > >> >http://people.freebsd.org/~jeff/ulehtt.diff >> > >> >I also believe that the buildkernel/world times are now >> >significantly improved. If this is not the case for you please send >> >a mail. Any other performance data is appreciated. >> >>on 4 cores with ULE in the tree >>CPU: Dual Core AMD Opteron(tm) Processor 270 HE (1991.73-MHz 686-class CPU) >> Origin = "AuthenticAMD" Id = 0x20f12 Stepping = 2 >> >>Features=0x178bfbff >> Features2=0x1 >> AMD Features=0xe2500800 >> AMD Features2=0x3 >> Cores per package: 2 >>real memory = 1610547200 (1535 MB) >>avail memory = 1568690176 (1496 MB) >>ACPI APIC Table: >>FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs >> cpu0 (BSP): APIC ID: 0 >> cpu1 (AP): APIC ID: 1 >> cpu2 (AP): APIC ID: 2 >> cpu3 (AP): APIC ID: 3 >> >>[cheetah]# time make -j8 buildkernel > /var/log/build.out.k >>843.601u 95.442s 8:46.70 178.2% 5612+1002k 8067+6346io 350pf+0w >>with patch above >>[cheetah]# time make -j8 buildkernel > >>/var/log/build.out.k >>841.903u 95.183s 8:38.17 180.8% 5608+1002k 9051+6282io 388pf+0w >>[cheetah]# > >Could you make a test with 4bsd? From a couple of days ago using 4BSD make -j4,6,8 848.747u 101.484s 8:09.20 194.2% 5596+977k 7635+6458io 198pf+0w 849.662u 104.233s 7:41.64 206.6% 5605+978k 629+6477io 4pf+0w 852.998u 102.805s 7:48.33 204.0% 5607+978k 686+6392io 2pf+0w also tried with base ULE+patch from this thread time make -j16 buildkernel > /var/log/build.out.k 845.800u 97.501s 8:15.20 190.4% 5606+1001k 643+6350io 2pf+0w ---Mike From owner-freebsd-current@FreeBSD.ORG Sun Jul 22 05:19:49 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 0503F16A417 for ; Sun, 22 Jul 2007 05:19:49 +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 C6A2B13C45D for ; Sun, 22 Jul 2007 05:19: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 l6M5JkJv000393 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Sun, 22 Jul 2007 01:19:47 -0400 (EDT) (envelope-from jroberson@chesapeake.net) Date: Sat, 21 Jul 2007 22:22:52 -0700 (PDT) From: Jeff Roberson X-X-Sender: jroberson@10.0.0.1 To: Mike Tancsa In-Reply-To: <200707220436.l6M4a3QC037029@lava.sentex.ca> Message-ID: <20070721222225.M561@10.0.0.1> References: <20070721174631.S561@10.0.0.1> <200707220400.l6M40bJ9036873@lava.sentex.ca> <576dcbc20707212126w3864528cvc0428f50572b385a@mail.gmail.com> <200707220436.l6M4a3QC037029@lava.sentex.ca> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: lveax , current@freebsd.org Subject: Re: ULE status, invalid load, buildkernel 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, 22 Jul 2007 05:19:49 -0000 On Sun, 22 Jul 2007, Mike Tancsa wrote: > At 12:26 AM 7/22/2007, lveax wrote: >> On 7/22/07, Mike Tancsa wrote: >>> At 08:55 PM 7/21/2007, Jeff Roberson wrote: >>> >I have a patch available at: >>> > >>> >http://people.freebsd.org/~jeff/ulehtt.diff >>> > >>> >I also believe that the buildkernel/world times are now >>> >significantly improved. If this is not the case for you please send >>> >a mail. Any other performance data is appreciated. >>> >>> on 4 cores with ULE in the tree >>> CPU: Dual Core AMD Opteron(tm) Processor 270 HE (1991.73-MHz 686-class >>> CPU) >>> Origin = "AuthenticAMD" Id = 0x20f12 Stepping = 2 >>> >>> Features=0x178bfbff >>> Features2=0x1 >>> AMD Features=0xe2500800 >>> AMD Features2=0x3 >>> Cores per package: 2 >>> real memory = 1610547200 (1535 MB) >>> avail memory = 1568690176 (1496 MB) >>> ACPI APIC Table: >>> FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs >>> cpu0 (BSP): APIC ID: 0 >>> cpu1 (AP): APIC ID: 1 >>> cpu2 (AP): APIC ID: 2 >>> cpu3 (AP): APIC ID: 3 >>> >>> [cheetah]# time make -j8 buildkernel > /var/log/build.out.k >>> 843.601u 95.442s 8:46.70 178.2% 5612+1002k 8067+6346io 350pf+0w >>> with patch above >>> [cheetah]# time make -j8 buildkernel > >>> /var/log/build.out.k >>> 841.903u 95.183s 8:38.17 180.8% 5608+1002k 9051+6282io 388pf+0w >>> [cheetah]# >> >> Could you make a test with 4bsd? > > From a couple of days ago > using 4BSD > make -j4,6,8 > 848.747u 101.484s 8:09.20 194.2% 5596+977k 7635+6458io 198pf+0w > 849.662u 104.233s 7:41.64 206.6% 5605+978k 629+6477io 4pf+0w > 852.998u 102.805s 7:48.33 204.0% 5607+978k 686+6392io 2pf+0w > > also tried with base ULE+patch from this thread > time make -j16 buildkernel > /var/log/build.out.k > 845.800u 97.501s 8:15.20 190.4% 5606+1001k 643+6350io 2pf+0w Can you tell me the output of sysctl kern.sched.topology? Thanks, Jeff > > ---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 Sun Jul 22 06:15:07 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 4F75516A417 for ; Sun, 22 Jul 2007 06:15:07 +0000 (UTC) (envelope-from dmw@unete.cl) Received: from mail01.ifxnetworks.com (mail01.ifxnetworks.com [190.61.128.11]) by mx1.freebsd.org (Postfix) with ESMTP id DF19413C459 for ; Sun, 22 Jul 2007 06:15:06 +0000 (UTC) (envelope-from dmw@unete.cl) Received: (qmail 22534 invoked from network); 22 Jul 2007 06:15:05 -0000 X-Spam-DCC: EATSERVER: mail01.ifxnetworks.com 1166; Body=1 Fuz1=1 Fuz2=1 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on mail01.ifxnetworks.com X-Spam-Level: X-Spam-Status: No, score=0.1 required=7.0 tests=RDNS_NONE autolearn=disabled version=3.2.1 Received: from unknown (HELO quake) (dmw@unete.cl@[200.73.82.54]) (envelope-sender ) by mail01.ifxnetworks.com (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 22 Jul 2007 06:15:05 -0000 From: Daniel Molina Wegener Organization: DMW To: freebsd-current@freebsd.org Date: Sun, 22 Jul 2007 02:14:28 -0400 User-Agent: KMail/1.9.6 References: <200707212023.03993.dmw@unete.cl> <20070722003044.GA4770@troutmask.apl.washington.edu> In-Reply-To: <20070722003044.GA4770@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200707220214.28601.dmw@unete.cl> Cc: Steve Kargl Subject: Re: Every time I get the sources I can't compile... 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: Sun, 22 Jul 2007 06:15:07 -0000 On Saturday 21 July 2007 20:30:44 Steve Kargl wrote: > On Sat, Jul 21, 2007 at 08:23:03PM -0400, Daniel Molina Wegener wrote: > > Hello, > > > > Every time I get the sources I can't compile the source > > tree, buildworld fails or buildkernel fails. ??Is any way > > to know which revision is working? > > > > I've tried with the GENERIC kernel and fails, custom kernel > > configurations fails too. > > > > ??Any way to get a working copy of -CURRENT? > > There's a large amount of missing detail. Ok... > 1) What architecture? i386 > 2) How do you get the source code? anoncvs > 3) Are you setting anything in /etc/make.conf? just prescott at CPUTYPE an -O2 -pipe on CFLAGS > 4) What is the failure (ie exact error message)? I've included streams support in the kernel, and fails to compile. The manual page only includes the streams device, but seems to have broken dependencies. > 5) What a minimum description of the hardware? A normal PC with a prescott processor. > I've rebuilt working -current on i386 and amd64 > where the source is retrieved by anoncvs and > csup on the different systems in the last two days. I've removed the streams device and now works... Regards, -- .O. | Daniel Molina Wegener | C/C++ Developer ..O | dmw [at] unete [dot] cl | FOSS Coding Adict OOO | BSD & Linux User | Standards Rocks! From owner-freebsd-current@FreeBSD.ORG Sun Jul 22 06:16: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 EDC5116A41A for ; Sun, 22 Jul 2007 06:16:40 +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 8A1FA13C468 for ; Sun, 22 Jul 2007 06:16:40 +0000 (UTC) (envelope-from dmw@unete.cl) Received: (qmail 6675 invoked from network); 22 Jul 2007 06:16:39 -0000 X-Spam-DCC: EATSERVER: mail04.ifxnetworks.com 1166; Body=1 Fuz1=1 Fuz2=1 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on mail04.ifxnetworks.com X-Spam-Level: X-Spam-Status: No, score=0.1 required=7.0 tests=RDNS_NONE autolearn=disabled version=3.2.1 Received: from unknown (HELO quake) (dmw@unete.cl@[200.73.82.54]) (envelope-sender ) by mail04.ifxnetworks.com (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 22 Jul 2007 06:16:39 -0000 From: Daniel Molina Wegener Organization: DMW To: stgib@list.ru Date: Sun, 22 Jul 2007 02:16:02 -0400 User-Agent: KMail/1.9.6 References: <200707212023.03993.dmw@unete.cl> <20070722035826.GA1870@io.k.vu> In-Reply-To: <20070722035826.GA1870@io.k.vu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200707220216.02634.dmw@unete.cl> Cc: FreeBSD -CURRENT Subject: Re: Every time I get the sources I can't compile... 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: Sun, 22 Jul 2007 06:16:41 -0000 On Saturday 21 July 2007 23:58:26 stgib@list.ru wrote: > On Sat, Jul 21, 2007 at 08:23:03PM -0400, Daniel Molina Wegener wrote: > > Every time I get the sources I can't compile the source > > tree, buildworld fails or buildkernel fails. Is any way to > > know which revision is working? > > BTW, when the last successful time was? > > > I've tried with the GENERIC kernel and fails, custom kernel > > configurations fails too. > > > > Any way to get a working copy of -CURRENT? > > In case you've messed up your build environment (like I did > sometime ago :D) you can get one from snapshots. Chroot to it > and then try again. Hello, Thanks, the problem was solved. I've removed the streams(4) support from the kernel and worked fine. Seems to have some broken dependencies. Regards, -- .O. | Daniel Molina Wegener | C/C++ Developer ..O | dmw [at] unete [dot] cl | FOSS Coding Adict OOO | BSD & Linux User | Standards Rocks! From owner-freebsd-current@FreeBSD.ORG Sun Jul 22 06:35:29 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 DE99A16A41A for ; Sun, 22 Jul 2007 06:35:29 +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 8714713C45A for ; Sun, 22 Jul 2007 06:35:29 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: by an-out-0708.google.com with SMTP id c14so303942anc for ; Sat, 21 Jul 2007 23:35: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=YfQvWtuNsUnFqg2sAzi5ih+dcIdbZhiM0sCSVmSN8aw5jkImvSgg018DIGaLeZZH7KPdF3YTxt+c7GTlkQ6xhVTy3qXV26xLG6R8t/RI6lQY8yl9WHjsP3bSKAJFkvu+S8QDlXn13gGjDQg229qm/dUgKfMY4yQI0ixj2Nc8AM0= 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=h5XkcdDbfwWDe3RCL7jk4wW5huI8T436QZPQdS2obojwE0j4NnW/MumLSLFL0qN6p/kYhYCMifwY2ZqH25RL1u7rJbG1IUyUW0lodPTVJwsgiNBnrUR4FDpAaxv/KEic5ZMbHQzB9xqUm0DbO5vmGfHLbKic3bG1eQFlQyk2GEk= Received: by 10.100.42.7 with SMTP id p7mr1047845anp.1185086128499; Sat, 21 Jul 2007 23:35:28 -0700 (PDT) Received: by 10.100.141.14 with HTTP; Sat, 21 Jul 2007 23:35:28 -0700 (PDT) Message-ID: <790a9fff0707212335g17b62a7aw548de1202f89d862@mail.gmail.com> Date: Sun, 22 Jul 2007 01:35:28 -0500 From: "Scot Hetzel" To: "Andrew Thompson" In-Reply-To: <20070721092207.GC76674@heff.fud.org.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <790a9fff0707150332u2502a491s91f19d4303bf82a6@mail.gmail.com> <20070715110629.GI95956@heff.fud.org.nz> <790a9fff0707181607n7500b7feo190c58418e047de5@mail.gmail.com> <20070720001043.GD45010@heff.fud.org.nz> <20070721092207.GC76674@heff.fud.org.nz> 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, 22 Jul 2007 06:35:30 -0000 On 7/21/07, Andrew Thompson wrote: > > 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. > With both of those patches applied my system has no problems associating and obtaining an IP address. Before the patches were applied the system would time out on the dhcp requests, and fail to obtain an IP due to it hadn't associated with an AP in time. I was finally able to get connected to the schools WPA network with wpa_supplicant, by removing: ca_certs="" from the configuration: network={ ssid="School_WPA" proto=WPA key_mgmt=WPA-EAP pairwise=TKIP group=TKIP eap=PEAP identity="me@school" password="password" phase1="include_tls_length=1" phase2="auth=MSCHAPV2" } found the problem by using wlandebug scan+assoc+auth, and saw it was failing when it tried to load the certificate file. I also tested the ndis_scan10.diff on my home and work networks and didn't have any problems assocating with the APs. I did notice that 'ifconfig ndis0' on my home network would show the ssid, while the work and school network wouldn't show the connected ssid. 'ifconfig ndis0 scan ; ifconfig ndis0 list scan' still doesn't show the available APs. But they still show up in wpa_cli when using scan_results. I had created the following script for the testing: --- #!/bin/sh set -x newsyslog -F kldload bcmwl564_sys.ko sysctl debug.ndis=1 wlandebug -i ndis0 scan ifconfig ndis0 scan ifconfig ndis0 list scan kldunload bcmwl564_sys.ko --- Script started on Sat Jul 21 14:15:13 2007 + newsyslog -F + kldload bcmwl564_sys.ko + sysctl debug.ndis=1 debug.ndis: 0 -> 1 + wlandebug -i ndis0 scan net.wlan.0.debug: 0x0 => 0x200000 + ifconfig ndis0 scan + ifconfig ndis0 list scan Script done on Sat Jul 21 14:15:25 2007 == /var/log/messages == Jul 21 14:15:13 hp010 newsyslog[1195]: logfile turned over due to -F request Jul 21 14:15:24 hp010 kernel: ichsmb0: port 0x8400-0x840f mem 0xc0003000-0xc00033ff at device 20.0 on pci0 Jul 21 14:15:24 hp010 kernel: ichsmb0: can't map I/O Jul 21 14:15:24 hp010 kernel: device_attach: ichsmb0 attach returned 6 Jul 21 14:15:24 hp010 kernel: ichsmb0: port 0x8400-0x840f mem 0xc0003000-0xc00033ff at device 20.0 on pci0 Jul 21 14:15:24 hp010 kernel: ichsmb0: can't map I/O Jul 21 14:15:24 hp010 kernel: device_attach: ichsmb0 attach returned 6 Jul 21 14:15:24 hp010 kernel: ndis0: mem 0xc0204000-0xc0205fff irq 21 at device 2.0 on pci6 Jul 21 14:15:24 hp010 kernel: ndis0: [ITHREAD] Jul 21 14:15:24 hp010 kernel: ndis0: NDIS API version: 5.1 Jul 21 14:15:24 hp010 kernel: fpudna in kernel mode! Jul 21 14:15:25 hp010 kernel: ndis0: using obsoleted if_watchdog interface Jul 21 14:15:25 hp010 kernel: ndis0: Ethernet address: 00:14:a5:72:68:64 Scot -- DISCLAIMER: No electrons were mamed while sending this message. Only slightly bruised. From owner-freebsd-current@FreeBSD.ORG Sun Jul 22 07:28:08 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 2F2CE16A41B; Sun, 22 Jul 2007 07:28:08 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id EA23713C45B; Sun, 22 Jul 2007 07:28:07 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.13.8/8.13.8) with ESMTP id l6M7S70J093778; Sun, 22 Jul 2007 03:28:07 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.8/8.13.8) with ESMTP id l6M7S7JU082395; Sun, 22 Jul 2007 03:28:07 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id CEE9F73068; Sun, 22 Jul 2007 03:28:06 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070722072806.CEE9F73068@freebsd-current.sentex.ca> Date: Sun, 22 Jul 2007 03:28:06 -0400 (EDT) X-Virus-Scanned: ClamAV version devel-20070102, clamav-milter version devel-111206 on clamscanner5 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jul 2007 07:28:08 -0000 TB --- 2007-07-22 05:20:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-07-22 05:20:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2007-07-22 05:20:00 - cleaning the object tree TB --- 2007-07-22 05:20:40 - checking out the source tree TB --- 2007-07-22 05:20:40 - cd /tinderbox/HEAD/amd64/amd64 TB --- 2007-07-22 05:20:40 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-07-22 05:31:10 - building world (CFLAGS=-O2 -pipe) TB --- 2007-07-22 05:31:10 - cd /src TB --- 2007-07-22 05:31:10 - /usr/bin/make -B buildworld >>> World build started on Sun Jul 22 05:31:12 UTC 2007 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Sun Jul 22 07:17:41 UTC 2007 TB --- 2007-07-22 07:17:41 - generating LINT kernel config TB --- 2007-07-22 07:17:41 - cd /src/sys/amd64/conf TB --- 2007-07-22 07:17:41 - /usr/bin/make -B LINT TB --- 2007-07-22 07:17:41 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-07-22 07:17:41 - cd /src TB --- 2007-07-22 07:17:41 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Jul 22 07:17:42 UTC 2007 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/dev/usb/uplcom.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/dev/usb/urio.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/dev/usb/usb.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/dev/usb/usb_ethersubr.c awk -f /src/sys/tools/makeobjops.awk /src/sys/dev/usb/usb_if.m -c ; cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue usb_if.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/dev/usb/usb_mem.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/dev/usb/usb_quirks.c /src/sys/dev/usb/usb_quirks.c:111: error: 'USB_PRODUCT_METAGEEK_WISPY' undeclared here (not in a function) *** Error code 1 Stop in /obj/amd64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-07-22 07:28:06 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-07-22 07:28:06 - ERROR: failed to build lint kernel TB --- 2007-07-22 07:28:06 - tinderbox aborted TB --- 0.88 user 3.78 system 7685.79 real http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Sun Jul 22 07:59: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 A517316A418; Sun, 22 Jul 2007 07:59:07 +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 E2A2A13C428; Sun, 22 Jul 2007 07:59:06 +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 l6M7x3M2072201; Sun, 22 Jul 2007 08:59:03 +0100 (BST) (envelope-from dfr@rabson.org) From: Doug Rabson To: Andrew Thompson Date: Sun, 22 Jul 2007 08:58:12 +0100 User-Agent: KMail/1.9.6 References: <200707211925.59698.dfr@rabson.org> <20070721210759.GA84580@heff.fud.org.nz> <20070721210837.GB84580@heff.fud.org.nz> (sfid-20070721_22112_DC9AD33D) (sfid-20070721_22112_DC9AD33D) (sfid-20070721_22112_DC9AD33D) (sfid-20070721_22112_DC9AD33D) (sfid-20070721_22112_DC9AD33D) (sfid-20070721_22112_DC9AD33D) (sfid-20070721_22112_DC9AD33D) (sfid-20070721_22112_DC9AD33D) (sfid-20070721_22112_DC9AD33D) (sfid-20070721_22112_DC9AD33D) (sfid-20070721_22112_DC9AD33D) (sfid-20070721_22112_DC9AD33D) (sfid-20070721_22112_DC9AD33D) (sfid-20070721_22112_DC9AD33D) (sfid-20070721_22112_DC9AD33D) (sfid-20070721_22112_DC9AD33D) (sfid-20070721_22112_DC9AD33D) (sfid-20070721_22112_DC9AD33D) (sfid-20070721_22112_DC9AD33D) (sfid-20070721_22112_DC9AD33D) (sfid-20070721_22112_DC9AD33D) (sfid-20070721_22112_DC9AD33D) (sfid-20070721_22112_DC9AD33D) (sfid-20070721_22112_DC9AD33D) (sfid-20070721_22112_DC9AD33D) (sfid-20070721_22112_DC9AD33D) (sfid-20070721_22112_DC9AD33D) (sfid-20070721_22112_D! C9AD33D) (sfid-20070721_22112_DC9AD33D) (sfid-20070721_22112_DC9AD33D) (sfid-20070721_22112_DC9AD33D) (sfid-20070721_22112_DC9AD33D) (sfid-20070721_22112_DC9AD33D) (sfid-20070721_22112_DC9AD33D) (sfid-20070721_22112_DC9AD33D) (sfid-20070721_22112_DC9AD33D) (sfid-20070721_22112_DC9AD33D) (sfid-20070721_22112_DC9AD33D) (sfid-20070721_22112_DC9AD33D) (sfid-20070721_22112_DC9AD33D) (sfid-20070721_22112_DC9AD33D) (sfid-20070721_22112_DC9AD33D) (sfid-20070721_22112_DC9AD33D) (sfid-20070721_22112_DC9AD33D) (sfid-20070721_22112_DC9AD33D) (sfid-20070721_22112_DC9AD33D) (sfid-20070721_22112_DC9AD33D) (sfid-20070721_22112_DC9AD33D) (sfid-20070721_22112_DC9AD33D) (sfid-20070721_22112_DC9AD33D) (sfid-20070721_22112_DC9AD33D) (sfid-20070721_22112_DC9AD33D) (sfid-20070721_22112_DC9AD33D) (sfid-20070721_22112_DC9AD33D) (sfid-20070721_22112_DC9AD33D) (sfid-20070721_22112_DC9AD33D) (sfid-20070721_22112_DC9AD33D) (sfid-20070721_22112_DC9AD33D) (sfid-20070721_22112_DC9AD33D) (sfid-20070721_221! 12_DC9AD33D) (sfid-20070721_22112_DC9AD33D) (sfid-20070721_22112_DC9AD33D) (sfid-20070721_22112_DC9AD33D) (sfid-20070721_22112_DC9AD33D) (sfid-20070721_22112_DC9AD33D) (sfid-20070721_22112_DC9AD33D) (sfid-20070721_22112_DC9AD33D) (sfid-20070721_22112_DC9AD33D) (sfid-20070721_22112_DC9AD33D) (sfid-20070721_22112_DC9AD33D) (sf In-Reply-To: <20070721210837.GB84580@heff.fud.org.nz> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200707220858.12770.dfr@rabson.org> X-Virus-Scanned: ClamAV 0.87.1/3728/Sun Jul 22 06:07:30 2007 on itchy.rabson.org X-Virus-Status: Clean Cc: Attilio Rao , 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: Sun, 22 Jul 2007 07:59:07 -0000 On Saturday 21 July 2007, Andrew Thompson wrote: > 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. I still get a panic but I managed to get more information this time. The original panic was a WITNESS complaint (not sure why that put it into the debugger rather than just logging the LOR). Here is what happens with your patch. I continued from the first call to ddb and that generated the subsequent LOR report. Kernel page fault with the following non-sleepable locks held: exclusive sleep mutex if_bridge r = 0 (0xcc3be00c) locked @ /usr/src/sys/modules/if_bridge/../../net/if_bridge.c:715 KDB: stack backtrace: db_trace_self_wrapper(c082abf1,f6b9c9c0,c05f25fd,c082afb0,f6b9c9d4,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c082afb0,f6b9c9d4,4,1,0,...) at kdb_backtrace+0x29 witness_warn(5,0,c084f993,c08bd4f4,f6b9c9f4,...) at witness_warn+0x1cd trap(f6b9ca60) at trap+0x165 calltrap() at calltrap+0x6 --- trap 0xc, eip = 0xc07d760e, esp = 0xf6b9caa0, ebp = 0xf6b9caec --- generic_copyout(cc3be000,f6b9cb08,cc40ae17,2cb,cc3be00c,...) at generic_copyout+0x36 bridge_ioctl(c57cf400,c01c697b,c6c6a860,c0877704,c0834167,...) at bridge_ioctl+0x1c8 in_control(c882dc60,c01c697b,c6c6a860,c57cf400,cc378e00,...) at in_control+0xda4 ifioctl(c882dc60,c01c697b,c6c6a860,cc378e00,cc378e00,...) at ifioctl+0x323 soo_ioctl(ca21fbd0,c01c697b,c6c6a860,ca3ac400,cc378e00,...) at soo_ioctl+0x3c7 kern_ioctl(cc378e00,3,c01c697b,c6c6a860,1000000,...) at kern_ioctl+0x243 ioctl(cc378e00,f6b9ccfc,c,c082d957,c0871950,...) at ioctl+0x134 syscall(f6b9cd38) at syscall+0x2b3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x2816733f, esp = 0xbfbfe27c, ebp = 0xbfbfe2c8 --- Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x2820a000 fault code = supervisor write, page not present instruction pointer = 0x20:0xc07d760e stack pointer = 0x28:0xf6b9caa0 frame pointer = 0x28:0xf6b9caec code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 1512 (ifconfig) lock order reversal: (sleepable after non-sleepable) 1st 0xcc3be00c if_bridge (if_bridge) @ /usr/src/sys/modules/if_bridge/../../net/if_bridge.c:715 2nd 0xc87953e4 user map (user map) @ vm/vm_map.c:3075 KDB: stack backtrace: db_trace_self_wrapper(c082abf1,f6b9c7cc,c05f347e,c082d065,c87953e4,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c082d065,c87953e4,c0845907,c0845907,c08458a9,...) at kdb_backtrace+0x29 witness_checkorder(c87953e4,9,c08458a0,c03,f6b9c814,...) at witness_checkorder+0x6de _sx_xlock(c87953e4,0,c08458a0,c03,f6b9c834,...) at _sx_xlock+0x7d _vm_map_lock_read(c87953a0,c08458a0,c03,0,c05f1032,...) at _vm_map_lock_read+0x50 vm_map_lookup(f6b9c91c,2820a000,2,f6b9c920,f6b9c910,...) at vm_map_lookup+0x38 vm_fault(c87953a0,2820a000,2,8,2820a000,...) at vm_fault+0x83 trap_pfault(5,0,c084f993,c08bd4f4,f6b9c9f4,...) at trap_pfault+0xf9 trap(f6b9ca60) at trap+0x412 calltrap() at calltrap+0x6 --- trap 0xc, eip = 0xc07d760e, esp = 0xf6b9caa0, ebp = 0xf6b9caec --- generic_copyout(cc3be000,f6b9cb08,cc40ae17,2cb,cc3be00c,...) at generic_copyout+0x36 bridge_ioctl(c57cf400,c01c697b,c6c6a860,c0877704,c0834167,...) at bridge_ioctl+0x1c8 in_control(c882dc60,c01c697b,c6c6a860,c57cf400,cc378e00,...) at in_control+0xda4 ifioctl(c882dc60,c01c697b,c6c6a860,cc378e00,cc378e00,...) at ifioctl+0x323 soo_ioctl(ca21fbd0,c01c697b,c6c6a860,ca3ac400,cc378e00,...) at soo_ioctl+0x3c7 kern_ioctl(cc378e00,3,c01c697b,c6c6a860,1000000,...) at kern_ioctl+0x243 ioctl(cc378e00,f6b9ccfc,c,c082d957,c0871950,...) at ioctl+0x134 syscall(f6b9cd38) at syscall+0x2b3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x2816733f, esp = 0xbfbfe27c, ebp = 0xbfbfe2c8 --- From owner-freebsd-current@FreeBSD.ORG Sun Jul 22 08:13: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 6F0F416A50E for ; Sun, 22 Jul 2007 08:13:23 +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 15CDE13C4A6 for ; Sun, 22 Jul 2007 08:13:23 +0000 (UTC) (envelope-from dionch@freemail.gr) Received: from CDION (ppp232-205.dsl.hol.gr [89.210.232.205]) by smtp.freemail.gr (Postfix) with ESMTP id 76349A0825B; Sun, 22 Jul 2007 11:13:21 +0300 (EEST) Date: Sun, 22 Jul 2007 11:10:25 +0300 From: Chris Dionissopoulos X-Mailer: The Bat! (v3.80.06) Professional X-Priority: 3 (Normal) Message-ID: <1807103749.20070722111025@freemail.gr> To: Jeff Roberson In-Reply-To: <20070721174631.S561@10.0.0.1> References: <20070721174631.S561@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 status, invalid load, buildkernel times. 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: Sun, 22 Jul 2007 08:13:23 -0000 Hello Jeff, Sunday, July 22, 2007, 3:55:08 AM, you wrote: > I have a patch available at: > http://people.freebsd.org/~jeff/ulehtt.diff > This resolves issues in the code that handles HTT enabled processors and > also adds some ULE information to bootverbose on SMP systems. Peter Wemm > has a seperate patch that fixes a bug where some amd64 cpus were still > being misidentified as HTT. Those of you with invalid loads either have > Hyper-threading CPUs or misidentified amd cores. You should expect > slightly poorer performance as long as your cores are misidentified but > the bad loads should be fixed. > I also believe that the buildkernel/world times are now significantly > improved. If this is not the case for you please send a mail. Any other > performance data is appreciated. > Thanks, > Jeff Load numbers seem correct, but, when enabling powerd(8) for power management I get kernel panic! In detail: -without patch, powerd(8) and system working stable (20+ daemons), -with patch applied and disabling powerd(8), system working stable (a couple of hours) -with patch applied and trying to enable powerd(8) produces kernel panic from powerd(8) process. It seems something ugly using scheduling lives in powerd(8). info: ===== 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 #5: Sun Jul 22 09:26:23 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 # sysctl -a | grep topo kern.sched.topology: 1 -- Best regards, Chris mailto:dionch@freemail.gr From owner-freebsd-current@FreeBSD.ORG Sun Jul 22 08:19: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 2135116A418; Sun, 22 Jul 2007 08:19:43 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 74E9213C468; Sun, 22 Jul 2007 08:19:43 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.13.8/8.13.8) with ESMTP id l6M8JhKg094600; Sun, 22 Jul 2007 04:19:43 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.8/8.13.8) with ESMTP id l6M8JgUo017301; Sun, 22 Jul 2007 04:19:42 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id B4BED73068; Sun, 22 Jul 2007 04:19:42 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070722081942.B4BED73068@freebsd-current.sentex.ca> Date: Sun, 22 Jul 2007 04:19:42 -0400 (EDT) X-Virus-Scanned: ClamAV version devel-20070102, clamav-milter version devel-111206 on clamscanner5 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jul 2007 08:19:44 -0000 TB --- 2007-07-22 06:42:41 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-07-22 06:42:41 - starting HEAD tinderbox run for i386/i386 TB --- 2007-07-22 06:42:41 - cleaning the object tree TB --- 2007-07-22 06:43:18 - checking out the source tree TB --- 2007-07-22 06:43:18 - cd /tinderbox/HEAD/i386/i386 TB --- 2007-07-22 06:43:18 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-07-22 06:51:28 - building world (CFLAGS=-O2 -pipe) TB --- 2007-07-22 06:51:28 - cd /src TB --- 2007-07-22 06:51:28 - /usr/bin/make -B buildworld >>> World build started on Sun Jul 22 06:51:30 UTC 2007 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sun Jul 22 08:09:14 UTC 2007 TB --- 2007-07-22 08:09:14 - generating LINT kernel config TB --- 2007-07-22 08:09:14 - cd /src/sys/i386/conf TB --- 2007-07-22 08:09:14 - /usr/bin/make -B LINT TB --- 2007-07-22 08:09:14 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-07-22 08:09:14 - cd /src TB --- 2007-07-22 08:09:14 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Jul 22 08:09:14 UTC 2007 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/dev/usb/uplcom.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/dev/usb/urio.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/dev/usb/usb.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/dev/usb/usb_ethersubr.c awk -f /src/sys/tools/makeobjops.awk /src/sys/dev/usb/usb_if.m -c ; cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue usb_if.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/dev/usb/usb_mem.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/dev/usb/usb_quirks.c /src/sys/dev/usb/usb_quirks.c:111: error: 'USB_PRODUCT_METAGEEK_WISPY' undeclared here (not in a function) *** Error code 1 Stop in /obj/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-07-22 08:19:42 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-07-22 08:19:42 - ERROR: failed to build lint kernel TB --- 2007-07-22 08:19:42 - tinderbox aborted TB --- 0.91 user 2.97 system 5820.52 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Sun Jul 22 08:39: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 8876716A418 for ; Sun, 22 Jul 2007 08:39:53 +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 3E00C13C45D for ; Sun, 22 Jul 2007 08: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 l6M8dof0013399 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Sun, 22 Jul 2007 04:39:52 -0400 (EDT) (envelope-from jroberson@chesapeake.net) Date: Sun, 22 Jul 2007 01:42:56 -0700 (PDT) From: Jeff Roberson X-X-Sender: jroberson@10.0.0.1 To: Chris Dionissopoulos In-Reply-To: <1807103749.20070722111025@freemail.gr> Message-ID: <20070722014208.G561@10.0.0.1> References: <20070721174631.S561@10.0.0.1> <1807103749.20070722111025@freemail.gr> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: current@freebsd.org Subject: Re: ULE status, invalid load, buildkernel 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, 22 Jul 2007 08:39:53 -0000 On Sun, 22 Jul 2007, Chris Dionissopoulos wrote: > Hello Jeff, > > Sunday, July 22, 2007, 3:55:08 AM, you wrote: > >> I have a patch available at: > >> http://people.freebsd.org/~jeff/ulehtt.diff > >> This resolves issues in the code that handles HTT enabled processors and >> also adds some ULE information to bootverbose on SMP systems. Peter Wemm >> has a seperate patch that fixes a bug where some amd64 cpus were still >> being misidentified as HTT. Those of you with invalid loads either have >> Hyper-threading CPUs or misidentified amd cores. You should expect >> slightly poorer performance as long as your cores are misidentified but >> the bad loads should be fixed. > >> I also believe that the buildkernel/world times are now significantly >> improved. If this is not the case for you please send a mail. Any other >> performance data is appreciated. > >> Thanks, >> Jeff > > Load numbers seem correct, but, when enabling powerd(8) for power > management I get kernel panic! In detail: Hi Chris, Can you tell me is there a panic message or is it a trap? Can you run with INVARIANTS and WITNESS without WITNESS_SKIPSPIN? I appreciate the detailed problem matrix. Thanks, Jeff > > -without patch, powerd(8) and system working stable (20+ daemons), > -with patch applied and disabling powerd(8), system working stable (a > couple of hours) > -with patch applied and trying to enable powerd(8) produces kernel panic from > powerd(8) process. > > It seems something ugly using scheduling lives in powerd(8). > > > info: > ===== > 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 #5: Sun Jul 22 09:26:23 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 > > > # sysctl -a | grep topo > kern.sched.topology: 1 > > > > -- > Best regards, > Chris mailto:dionch@freemail.gr > From owner-freebsd-current@FreeBSD.ORG Sun Jul 22 08:58:54 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 3F82116A419; Sun, 22 Jul 2007 08:58:54 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 0660213C469; Sun, 22 Jul 2007 08:58:53 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.13.8/8.13.8) with ESMTP id l6M8wrbX095385; Sun, 22 Jul 2007 04:58:53 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.8/8.13.8) with ESMTP id l6M8wrN9046113; Sun, 22 Jul 2007 04:58:53 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 0D67D73068; Sun, 22 Jul 2007 04:58:52 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070722085853.0D67D73068@freebsd-current.sentex.ca> Date: Sun, 22 Jul 2007 04:58:52 -0400 (EDT) X-Virus-Scanned: ClamAV version devel-20070102, clamav-milter version devel-111206 on clamscanner5 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jul 2007 08:58:54 -0000 TB --- 2007-07-22 07:28:07 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-07-22 07:28:07 - starting HEAD tinderbox run for i386/pc98 TB --- 2007-07-22 07:28:07 - cleaning the object tree TB --- 2007-07-22 07:28:44 - checking out the source tree TB --- 2007-07-22 07:28:44 - cd /tinderbox/HEAD/i386/pc98 TB --- 2007-07-22 07:28:44 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-07-22 07:36:33 - building world (CFLAGS=-O2 -pipe) TB --- 2007-07-22 07:36:33 - cd /src TB --- 2007-07-22 07:36:33 - /usr/bin/make -B buildworld >>> World build started on Sun Jul 22 07:36:35 UTC 2007 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sun Jul 22 08:51:05 UTC 2007 TB --- 2007-07-22 08:51:05 - generating LINT kernel config TB --- 2007-07-22 08:51:05 - cd /src/sys/pc98/conf TB --- 2007-07-22 08:51:05 - /usr/bin/make -B LINT TB --- 2007-07-22 08:51:06 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-07-22 08:51:06 - cd /src TB --- 2007-07-22 08:51:06 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Jul 22 08:51:06 UTC 2007 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -pg -mprofiler-epilogue /src/sys/dev/usb/uplcom.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -pg -mprofiler-epilogue /src/sys/dev/usb/urio.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -pg -mprofiler-epilogue /src/sys/dev/usb/usb.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -pg -mprofiler-epilogue /src/sys/dev/usb/usb_ethersubr.c awk -f /src/sys/tools/makeobjops.awk /src/sys/dev/usb/usb_if.m -c ; cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -pg -mprofiler-epilogue usb_if.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -pg -mprofiler-epilogue /src/sys/dev/usb/usb_mem.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -pg -mprofiler-epilogue /src/sys/dev/usb/usb_quirks.c /src/sys/dev/usb/usb_quirks.c:111: error: 'USB_PRODUCT_METAGEEK_WISPY' undeclared here (not in a function) *** Error code 1 Stop in /obj/pc98/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-07-22 08:58:52 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-07-22 08:58:52 - ERROR: failed to build lint kernel TB --- 2007-07-22 08:58:52 - tinderbox aborted TB --- 0.96 user 2.98 system 5445.54 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Sun Jul 22 08:59:13 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 0831A16A46C for ; Sun, 22 Jul 2007 08:59:13 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id CA06A13C481 for ; Sun, 22 Jul 2007 08:59:12 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost2.sentex.ca (8.14.1/8.13.8) with ESMTP id l6M8x5ca021335; Sun, 22 Jul 2007 04:59:05 -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 l6M8x4ZN038464 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 22 Jul 2007 04:59:04 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <200707220859.l6M8x4ZN038464@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 22 Jul 2007 04:58:52 -0400 To: Jeff Roberson From: Mike Tancsa In-Reply-To: <20070721222225.M561@10.0.0.1> References: <20070721174631.S561@10.0.0.1> <200707220400.l6M40bJ9036873@lava.sentex.ca> <576dcbc20707212126w3864528cvc0428f50572b385a@mail.gmail.com> <200707220436.l6M4a3QC037029@lava.sentex.ca> <20070721222225.M561@10.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: lveax , current@freebsd.org Subject: Re: ULE status, invalid load, buildkernel 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, 22 Jul 2007 08:59:13 -0000 At 01:22 AM 7/22/2007, Jeff Roberson wrote: >> From a couple of days ago >>using 4BSD >>make -j4,6,8 >>848.747u 101.484s 8:09.20 194.2% 5596+977k 7635+6458io 198pf+0w >>849.662u 104.233s 7:41.64 206.6% 5605+978k 629+6477io 4pf+0w >>852.998u 102.805s 7:48.33 204.0% 5607+978k 686+6392io 2pf+0w >> >>also tried with base ULE+patch from this thread >>time make -j16 buildkernel > /var/log/build.out.k >>845.800u 97.501s 8:15.20 190.4% 5606+1001k 643+6350io 2pf+0w > >Can you tell me the output of sysctl kern.sched.topology? Hi, [cheetah]# sysctl -a kern.sched kern.sched.preemption: 1 kern.sched.topology: 0 kern.sched.steal_thresh: 2 kern.sched.steal_idle: 1 kern.sched.steal_htt: 0 kern.sched.balance_secs: 1 kern.sched.balance: 1 kern.sched.tryself: 1 kern.sched.affinity: 3 kern.sched.pick_pri: 1 kern.sched.preempt_thresh: 64 kern.sched.interact: 30 kern.sched.slice: 13 kern.sched.name: ULE [cheetah]# BTW, this box is in the netperf cluster. ---Mike From owner-freebsd-current@FreeBSD.ORG Sun Jul 22 09:04:49 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 8F2BD16A417 for ; Sun, 22 Jul 2007 09:04:49 +0000 (UTC) (envelope-from stgib@list.ru) Received: from mx28.mail.ru (mx28.mail.ru [194.67.23.67]) by mx1.freebsd.org (Postfix) with ESMTP id 4D98313C45D for ; Sun, 22 Jul 2007 09:04:48 +0000 (UTC) (envelope-from stgib@list.ru) Received: from mx27.mail.ru (mx34.mail.ru [194.67.23.200]) by mx28.mail.ru (mPOP.Fallback_MX) with ESMTP id 29D00A5876 for ; Sun, 22 Jul 2007 07:58:29 +0400 (MSD) Received: from [89.178.139.168] (port=61537 helo=localhost) by mx27.mail.ru with asmtp id 1ICSaQ-000PBz-00; Sun, 22 Jul 2007 07:58:26 +0400 Date: Sun, 22 Jul 2007 07:58:26 +0400 From: stgib@list.ru To: Daniel Molina Wegener Message-ID: <20070722035826.GA1870@io.k.vu> References: <200707212023.03993.dmw@unete.cl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200707212023.03993.dmw@unete.cl> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: FreeBSD -CURRENT Subject: Re: Every time I get the sources I can't compile... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Jul 2007 09:04:49 -0000 On Sat, Jul 21, 2007 at 08:23:03PM -0400, Daniel Molina Wegener wrote: > Every time I get the sources I can't compile the source tree, > buildworld fails or buildkernel fails. Is any way to know > which revision is working? BTW, when the last successful time was? > I've tried with the GENERIC kernel and fails, custom kernel > configurations fails too. > > Any way to get a working copy of -CURRENT? In case you've messed up your build environment (like I did sometime ago :D) you can get one from snapshots. Chroot to it and then try again. From owner-freebsd-current@FreeBSD.ORG Sun Jul 22 09:15:50 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 4AB4216A41A for ; Sun, 22 Jul 2007 09:15:50 +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 D88F013C4D0 for ; Sun, 22 Jul 2007 09:15:49 +0000 (UTC) (envelope-from mv@rulez.sk) Received: from localhost (localhost [127.0.0.1]) by mail.rulez.sk (Postfix) with ESMTP id 07DCA5C37; Sun, 22 Jul 2007 11:15:48 +0200 (CEST) X-Virus-Scanned: by amavisd-new at mail.rulez.sk Received: by mail.rulez.sk (Postfix, from userid 1020) id 2E7495C36; Sun, 22 Jul 2007 11:15:45 +0200 (CEST) Date: Sun, 22 Jul 2007 11:15:45 +0200 From: Milos Vyletel To: Jeff Roberson Message-ID: <20070722091545.GA46858@rulez.sk> References: <20070721174631.S561@10.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070721174631.S561@10.0.0.1> User-Agent: Mutt/1.4.2.2i Cc: current@freebsd.org Subject: Re: ULE status, invalid load, buildkernel 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, 22 Jul 2007 09:15:50 -0000 On Sat, Jul 21, 2007 at 05:55:08PM -0700, Jeff Roberson wrote: > I have a patch available at: > > http://people.freebsd.org/~jeff/ulehtt.diff > > This resolves issues in the code that handles HTT enabled processors and > also adds some ULE information to bootverbose on SMP systems. Peter Wemm > has a seperate patch that fixes a bug where some amd64 cpus were still > being misidentified as HTT. Those of you with invalid loads either have > Hyper-threading CPUs or misidentified amd cores. You should expect > slightly poorer performance as long as your cores are misidentified but > the bad loads should be fixed. > > I also believe that the buildkernel/world times are now significantly > improved. If this is not the case for you please send a mail. Any other > performance data is appreciated. > > Thanks, > Jeff Hi, can you please point us to refered Peter Wemm's patch too? I can't find it with google or on ~peter/. Thanks Milos From owner-freebsd-current@FreeBSD.ORG Sun Jul 22 09:59:53 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 957A816A417 for ; Sun, 22 Jul 2007 09:59:53 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from redbull.bpaserver.net (redbullneu.bpaserver.net [213.198.78.217]) by mx1.freebsd.org (Postfix) with ESMTP id 57C5D13C478 for ; Sun, 22 Jul 2007 09:59:53 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (p54A561BA.dip.t-dialin.net [84.165.97.186]) by redbull.bpaserver.net (Postfix) with ESMTP id B28412E117; Sun, 22 Jul 2007 11:59:49 +0200 (CEST) Received: from deskjail (deskjail.Leidinger.net [192.168.1.109]) by outgoing.leidinger.net (Postfix) with ESMTP id 35E235B547D; Sun, 22 Jul 2007 11:57:37 +0200 (CEST) Date: Sun, 22 Jul 2007 12:01:33 +0200 From: Alexander Leidinger To: dmw@unete.cl Message-ID: <20070722120133.3b09804b@deskjail> In-Reply-To: <200707220216.02634.dmw@unete.cl> References: <200707212023.03993.dmw@unete.cl> <20070722035826.GA1870@io.k.vu> <200707220216.02634.dmw@unete.cl> X-Mailer: Claws Mail 2.9.2 (GTK+ 2.10.13; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BPAnet-MailScanner-Information: Please contact the ISP for more information X-BPAnet-MailScanner: Found to be clean X-BPAnet-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-14.9, required 8, BAYES_00 -15.00, DKIM_POLICY_SIGNSOME 0.00, RDNS_DYNAMIC 0.10) X-BPAnet-MailScanner-From: alexander@leidinger.net X-Spam-Status: No Cc: stgib@list.ru, FreeBSD -CURRENT Subject: Re: Every time I get the sources I can't compile... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Jul 2007 09:59:53 -0000 Quoting Daniel Molina Wegener (Sun, 22 Jul 2007 02:16:02 -0400): > I've removed the streams(4) support from the kernel and > worked fine. Seems to have some broken dependencies. If you include the actual error messages into your mails, it would help tracking the problem down or maybe telling you what is wrong... Bye, Alexander. -- LOOK!! Sullen American teens wearing MADRAS shorts and "Flock of Seagulls" HAIRCUTS! http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-current@FreeBSD.ORG Sun Jul 22 10:18: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 9188F16A417; Sun, 22 Jul 2007 10:18:21 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id 0FDE813C458; Sun, 22 Jul 2007 10:18:20 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.14.1/8.13.8) with ESMTP id l6MAIKoq023896; Sun, 22 Jul 2007 06:18:20 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.1/8.14.1) with ESMTP id l6MAIKsf073279; Sun, 22 Jul 2007 06:18:20 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id DE9F173068; Sun, 22 Jul 2007 06:18:19 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070722101819.DE9F173068@freebsd-current.sentex.ca> Date: Sun, 22 Jul 2007 06:18:19 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.91.1, clamav-milter version 0.91.1 on news X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jul 2007 10:18:21 -0000 TB --- 2007-07-22 08:19:42 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-07-22 08:19:42 - starting HEAD tinderbox run for ia64/ia64 TB --- 2007-07-22 08:19:42 - cleaning the object tree TB --- 2007-07-22 08:20:12 - checking out the source tree TB --- 2007-07-22 08:20:12 - cd /tinderbox/HEAD/ia64/ia64 TB --- 2007-07-22 08:20:12 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-07-22 08:27:12 - building world (CFLAGS=-O2 -pipe) TB --- 2007-07-22 08:27:12 - cd /src TB --- 2007-07-22 08:27:12 - /usr/bin/make -B buildworld >>> World build started on Sun Jul 22 08:27:13 UTC 2007 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sun Jul 22 10:07:49 UTC 2007 TB --- 2007-07-22 10:07:49 - generating LINT kernel config TB --- 2007-07-22 10:07:49 - cd /src/sys/ia64/conf TB --- 2007-07-22 10:07:49 - /usr/bin/make -B LINT TB --- 2007-07-22 10:07:49 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-07-22 10:07:49 - cd /src TB --- 2007-07-22 10:07:49 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Jul 22 10:07:49 UTC 2007 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding /src/sys/dev/usb/uplcom.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding /src/sys/dev/usb/urio.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding /src/sys/dev/usb/usb.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding /src/sys/dev/usb/usb_ethersubr.c awk -f /src/sys/tools/makeobjops.awk /src/sys/dev/usb/usb_if.m -c ; cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding usb_if.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding /src/sys/dev/usb/usb_mem.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding /src/sys/dev/usb/usb_quirks.c /src/sys/dev/usb/usb_quirks.c:111: error: 'USB_PRODUCT_METAGEEK_WISPY' undeclared here (not in a function) *** Error code 1 Stop in /obj/ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-07-22 10:18:19 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-07-22 10:18:19 - ERROR: failed to build lint kernel TB --- 2007-07-22 10:18:19 - tinderbox aborted TB --- 0.74 user 2.70 system 7116.76 real http://tinderbox.des.no/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Sun Jul 22 10:30:08 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 E4A4016A417; Sun, 22 Jul 2007 10:30:08 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id A52C813C442; Sun, 22 Jul 2007 10:30:08 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.13.8/8.13.8) with ESMTP id l6MAU8ve097017; Sun, 22 Jul 2007 06:30:08 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.8/8.13.8) with ESMTP id l6MAU7N7010357; Sun, 22 Jul 2007 06:30:07 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id BCF1C73068; Sun, 22 Jul 2007 06:30:07 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070722103007.BCF1C73068@freebsd-current.sentex.ca> Date: Sun, 22 Jul 2007 06:30:07 -0400 (EDT) X-Virus-Scanned: ClamAV version devel-20070102, clamav-milter version devel-111206 on clamscanner5 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jul 2007 10:30:09 -0000 TB --- 2007-07-22 08:58:53 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-07-22 08:58:53 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2007-07-22 08:58:53 - cleaning the object tree TB --- 2007-07-22 08:59:16 - checking out the source tree TB --- 2007-07-22 08:59:16 - cd /tinderbox/HEAD/powerpc/powerpc TB --- 2007-07-22 08:59:16 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-07-22 09:07:08 - building world (CFLAGS=-O2 -pipe) TB --- 2007-07-22 09:07:08 - cd /src TB --- 2007-07-22 09:07:08 - /usr/bin/make -B buildworld >>> World build started on Sun Jul 22 09:07:10 UTC 2007 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sun Jul 22 10:22:23 UTC 2007 TB --- 2007-07-22 10:22:23 - generating LINT kernel config TB --- 2007-07-22 10:22:23 - cd /src/sys/powerpc/conf TB --- 2007-07-22 10:22:23 - /usr/bin/make -B LINT TB --- 2007-07-22 10:22:23 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-07-22 10:22:23 - cd /src TB --- 2007-07-22 10:22:23 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Jul 22 10:22:23 UTC 2007 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding /src/sys/dev/usb/uplcom.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding /src/sys/dev/usb/urio.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding /src/sys/dev/usb/usb.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding /src/sys/dev/usb/usb_ethersubr.c awk -f /src/sys/tools/makeobjops.awk /src/sys/dev/usb/usb_if.m -c ; cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding usb_if.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding /src/sys/dev/usb/usb_mem.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding /src/sys/dev/usb/usb_quirks.c /src/sys/dev/usb/usb_quirks.c:111: error: 'USB_PRODUCT_METAGEEK_WISPY' undeclared here (not in a function) *** Error code 1 Stop in /obj/powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-07-22 10:30:07 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-07-22 10:30:07 - ERROR: failed to build lint kernel TB --- 2007-07-22 10:30:07 - tinderbox aborted TB --- 0.96 user 2.28 system 5474.33 real http://tinderbox.des.no/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Sun Jul 22 10:44: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 2168716A419 for ; Sun, 22 Jul 2007 10:44:06 +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 A231313C468 for ; Sun, 22 Jul 2007 10:44:05 +0000 (UTC) (envelope-from dionch@freemail.gr) Received: from CDION (ppp232-205.dsl.hol.gr [89.210.232.205]) by smtp.freemail.gr (Postfix) with ESMTP id CFC3EA082A3; Sun, 22 Jul 2007 13:44:03 +0300 (EEST) Date: Sun, 22 Jul 2007 13:41:05 +0300 From: Chris Dionissopoulos X-Mailer: The Bat! (v3.80.06) Professional X-Priority: 3 (Normal) Message-ID: <684796249.20070722134105@freemail.gr> To: Jeff Roberson , current@freebsd.org In-Reply-To: <20070722014208.G561@10.0.0.1> References: <20070721174631.S561@10.0.0.1> <1807103749.20070722111025@freemail.gr> <20070722014208.G561@10.0.0.1> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Subject: Re[2]: ULE status, invalid load, buildkernel times. 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: Sun, 22 Jul 2007 10:44:06 -0000 Hello Jeff, Sunday, July 22, 2007, 11:42:56 AM, you wrote: > On Sun, 22 Jul 2007, Chris Dionissopoulos wrote: >> Hello Jeff, >> >> Sunday, July 22, 2007, 3:55:08 AM, you wrote: >> >>> I have a patch available at: >> >>> http://people.freebsd.org/~jeff/ulehtt.diff >> >>> This resolves issues in the code that handles HTT enabled processors and >>> also adds some ULE information to bootverbose on SMP systems. Peter Wemm >>> has a seperate patch that fixes a bug where some amd64 cpus were still >>> being misidentified as HTT. Those of you with invalid loads either have >>> Hyper-threading CPUs or misidentified amd cores. You should expect >>> slightly poorer performance as long as your cores are misidentified but >>> the bad loads should be fixed. >> >>> I also believe that the buildkernel/world times are now significantly >>> improved. If this is not the case for you please send a mail. Any other >>> performance data is appreciated. >> >>> Thanks, >>> Jeff >> >> Load numbers seem correct, but, when enabling powerd(8) for power >> management I get kernel panic! In detail: > Hi Chris, > Can you tell me is there a panic message or is it a trap? Can you run > with INVARIANTS and WITNESS without WITNESS_SKIPSPIN? I appreciate the > detailed problem matrix. > Thanks, > Jeff ok, this panic is created from powerd(8) using "/etc/rc.d/powerd start" command: mail# kgdb kernel.debug /var/crash/vmcore.13 [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd". Unread portion of the kernel message buffer: panic: critical_exit: td_critnest == 0 cpuid = 0 Uptime: 1m34s Physical memory: 2013 MB Dumping 172 MB: 157 141 125 109 93 77 61 45 29 13 #0 doadump () at pcpu.h:195 195 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); (kgdb) bt #0 doadump () at pcpu.h:195 #1 0xc06469fe in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 #2 0xc0646cbb in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:563 #3 0xc0663224 in critical_exit () at kern_switch.c:185 #4 0xc083a2c0 in spinlock_exit () at /usr/src/sys/i386/i386/machdep.c:2348 #5 0xc063a2bd in _mtx_unlock_spin_flags (m=0xc0947000, opts=0, file=0xc08af6a3 "/usr/src/sys/kern/kern_cpu.c", line=303) at /usr/src/sys/kern/kern_mutex.c:246 #6 0xc061ad2a in cf_set_method (dev=0xc4d87e80, level=0xc55813b4, priority=100) at /usr/src/sys/kern/kern_cpu.c:303 #7 0xc06198d7 in cpufreq_curr_sysctl (oidp=0xc4d8b640, arg1=0xc4d8f400, arg2=0, req=0xe54b8ba4) at cpufreq_if.h:32 #8 0xc06504f7 in sysctl_root (oidp=Variable "oidp" is not available. ) at /usr/src/sys/kern/kern_sysctl.c:1306 #9 0xc0650625 in userland_sysctl (td=0xc4ef1660, name=0xe54b8c14, namelen=4, old=0x0, oldlenp=0x0, inkernel=0, new=0xbfbfe7a4, newlen=4, retval=0xe54b8c10, flags=0) at /usr/src/sys/kern/kern_sysctl.c:1401 #10 0xc0650a6c in __sysctl (td=0xc4ef1660, uap=0xe54b8cfc) at /usr/src/sys/kern/kern_sysctl.c:1336 #11 0xc0847673 in syscall (frame=0xe54b8d38) at /usr/src/sys/i386/i386/trap.c:1006 #12 0xc082ec90 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:196 #13 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) list *0xc0663224 0xc0663224 is in critical_exit (kern_switch.c:188). 183 184 td = curthread; 185 KASSERT(td->td_critnest != 0, 186 ("critical_exit: td_critnest == 0")); 187 #ifdef PREEMPTION 188 if (td->td_critnest == 1) { 189 td->td_critnest = 0; 190 if (td->td_owepreempt) { 191 td->td_critnest = 1; 192 thread_lock(td); (kgdb) list *0xc083a2c0 0xc083a2c0 is in spinlock_exit (/usr/src/sys/i386/i386/machdep.c:2349). 2344 { 2345 struct thread *td; 2346 2347 td = curthread; 2348 critical_exit(); 2349 td->td_md.md_spinlock_count--; 2350 if (td->td_md.md_spinlock_count == 0) 2351 intr_restore(td->td_md.md_saved_flags); 2352 } 2353 (kgdb) list *0xc063a2bd 0xc063a2bd is in _mtx_unlock_spin_flags (/usr/src/sys/kern/kern_mutex.c:247). 242 LOCK_LOG_LOCK("UNLOCK", &m->lock_object, opts, m->mtx_recurse, file, 243 line); 244 mtx_assert(m, MA_OWNED); 245 246 _rel_spin_lock(m); 247 } 248 249 /* 250 * The important part of mtx_trylock{,_flags}() 251 * Tries to acquire lock `m.' If this function is called on a mutex that (kgdb) list *0xc061ad2a 0xc061ad2a is in cf_set_method (/usr/src/sys/kern/kern_cpu.c:305). 300 if (cpu_id != pc->pc_cpuid) { 301 thread_lock(curthread); 302 sched_bind(curthread, pc->pc_cpuid); 303 thread_unlock(curthread); 304 } 305 CF_DEBUG("setting abs freq %d on %s (cpu %d)\n", set->freq, 306 device_get_nameunit(set->dev), PCPU_GET(cpuid)); 307 error = CPUFREQ_DRV_SET(set->dev, set); 308 if (cpu_id != pc->pc_cpuid) { 309 thread_lock(curthread); (kgdb) list *0xc06198d7 0xc06198d7 is in cpufreq_curr_sysctl (cpufreq_if.h:32). 27 static __inline int CPUFREQ_SET(device_t dev, const struct cf_level *level, 28 int priority) 29 { 30 kobjop_t _m; 31 KOBJOPLOOKUP(((kobj_t)dev)->ops,cpufreq_set); 32 return ((cpufreq_set_t *) _m)(dev, level, priority); 33 } 34 35 /** @brief Unique descriptor for the CPUFREQ_GET() method */ 36 extern struct kobjop_desc cpufreq_get_desc; (kgdb) But looking more carefully I found that I can reproduce PANIC anytime using command: mail# sysctl dev.cpu.0.freq=1596 -- where 1596 is valid Hz option as shown in: dev.cpu.0.freq: 1862 dev.cpu.0.freq_levels: 1862/89000 1629/77875 1596/63546 1396/55602 1197/47659 997/39716 798/31773 598/23829 399/15886 199/7943 I don't know if it helps much.. -- Best regards, Chris mailto:dionch@freemail.gr From owner-freebsd-current@FreeBSD.ORG Sun Jul 22 11:06:49 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 E852B16A417; Sun, 22 Jul 2007 11:06:49 +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 BEA2213C465; Sun, 22 Jul 2007 11:06:49 +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 l6MB6m6r020104; Sun, 22 Jul 2007 04:06:48 -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 l6MB6lSB020103; Sun, 22 Jul 2007 04:06:47 -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: Sun, 22 Jul 2007 04:06:47 -0700 User-Agent: KMail/1.9.6 References: <20070721174631.S561@10.0.0.1> <20070722091545.GA46858@rulez.sk> In-Reply-To: <20070722091545.GA46858@rulez.sk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200707220406.47833.peter@wemm.org> Cc: Milos Vyletel , Jeff Roberson , current@freebsd.org Subject: Re: ULE status, invalid load, buildkernel 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, 22 Jul 2007 11:06:50 -0000 On Sunday 22 July 2007, Milos Vyletel wrote: > On Sat, Jul 21, 2007 at 05:55:08PM -0700, Jeff Roberson wrote: > > I have a patch available at: > > > > http://people.freebsd.org/~jeff/ulehtt.diff > > > > This resolves issues in the code that handles HTT enabled > > processors and also adds some ULE information to bootverbose on SMP > > systems. Peter Wemm has a seperate patch that fixes a bug where > > some amd64 cpus were still being misidentified as HTT. Those of > > you with invalid loads either have Hyper-threading CPUs or > > misidentified amd cores. You should expect slightly poorer > > performance as long as your cores are misidentified but the bad > > loads should be fixed. > > > > I also believe that the buildkernel/world times are now > > significantly improved. If this is not the case for you please > > send a mail. Any other performance data is appreciated. > > > > Thanks, > > Jeff > > Hi, > > can you please point us to refered Peter Wemm's patch too? I can't > find it with google or on ~peter/. You can extract it from here: http://lists.freebsd.org/pipermail/p4-projects/2007-July/020058.html Sorry I don't have it in a more convenient format.. I'm about to fall asleep on my keyboard. :) Cheers, -Peter -- 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 Sun Jul 22 11:06:49 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 E852B16A417; Sun, 22 Jul 2007 11:06:49 +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 BEA2213C465; Sun, 22 Jul 2007 11:06:49 +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 l6MB6m6r020104; Sun, 22 Jul 2007 04:06:48 -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 l6MB6lSB020103; Sun, 22 Jul 2007 04:06:47 -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: Sun, 22 Jul 2007 04:06:47 -0700 User-Agent: KMail/1.9.6 References: <20070721174631.S561@10.0.0.1> <20070722091545.GA46858@rulez.sk> In-Reply-To: <20070722091545.GA46858@rulez.sk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200707220406.47833.peter@wemm.org> Cc: Milos Vyletel , Jeff Roberson , current@freebsd.org Subject: Re: ULE status, invalid load, buildkernel 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, 22 Jul 2007 11:06:50 -0000 On Sunday 22 July 2007, Milos Vyletel wrote: > On Sat, Jul 21, 2007 at 05:55:08PM -0700, Jeff Roberson wrote: > > I have a patch available at: > > > > http://people.freebsd.org/~jeff/ulehtt.diff > > > > This resolves issues in the code that handles HTT enabled > > processors and also adds some ULE information to bootverbose on SMP > > systems. Peter Wemm has a seperate patch that fixes a bug where > > some amd64 cpus were still being misidentified as HTT. Those of > > you with invalid loads either have Hyper-threading CPUs or > > misidentified amd cores. You should expect slightly poorer > > performance as long as your cores are misidentified but the bad > > loads should be fixed. > > > > I also believe that the buildkernel/world times are now > > significantly improved. If this is not the case for you please > > send a mail. Any other performance data is appreciated. > > > > Thanks, > > Jeff > > Hi, > > can you please point us to refered Peter Wemm's patch too? I can't > find it with google or on ~peter/. You can extract it from here: http://lists.freebsd.org/pipermail/p4-projects/2007-July/020058.html Sorry I don't have it in a more convenient format.. I'm about to fall asleep on my keyboard. :) Cheers, -Peter -- 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 Sun Jul 22 11:48:03 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 135CD16A41B; Sun, 22 Jul 2007 11:48:03 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id CA8F913C468; Sun, 22 Jul 2007 11:48:02 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.14.1/8.13.8) with ESMTP id l6MBm2J4027606; Sun, 22 Jul 2007 07:48:02 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.1/8.14.1) with ESMTP id l6MBm2a0052636; Sun, 22 Jul 2007 07:48:02 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 0212C73068; Sun, 22 Jul 2007 07:48:01 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070722114802.0212C73068@freebsd-current.sentex.ca> Date: Sun, 22 Jul 2007 07:48:01 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.91.1, clamav-milter version 0.91.1 on news X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jul 2007 11:48:03 -0000 TB --- 2007-07-22 10:18:20 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-07-22 10:18:20 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2007-07-22 10:18:20 - cleaning the object tree TB --- 2007-07-22 10:18:44 - checking out the source tree TB --- 2007-07-22 10:18:44 - cd /tinderbox/HEAD/sparc64/sparc64 TB --- 2007-07-22 10:18:44 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-07-22 10:27:10 - building world (CFLAGS=-O2 -pipe) TB --- 2007-07-22 10:27:10 - cd /src TB --- 2007-07-22 10:27:10 - /usr/bin/make -B buildworld >>> World build started on Sun Jul 22 10:27:11 UTC 2007 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sun Jul 22 11:40:33 UTC 2007 TB --- 2007-07-22 11:40:33 - generating LINT kernel config TB --- 2007-07-22 11:40:33 - cd /src/sys/sparc64/conf TB --- 2007-07-22 11:40:33 - /usr/bin/make -B LINT TB --- 2007-07-22 11:40:33 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-07-22 11:40:33 - cd /src TB --- 2007-07-22 11:40:33 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Jul 22 11:40:34 UTC 2007 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/dev/usb/uplcom.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/dev/usb/urio.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/dev/usb/usb.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/dev/usb/usb_ethersubr.c awk -f /src/sys/tools/makeobjops.awk /src/sys/dev/usb/usb_if.m -c ; cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror usb_if.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/dev/usb/usb_mem.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/dev/usb/usb_quirks.c /src/sys/dev/usb/usb_quirks.c:111: error: 'USB_PRODUCT_METAGEEK_WISPY' undeclared here (not in a function) *** Error code 1 Stop in /obj/sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-07-22 11:48:01 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-07-22 11:48:01 - ERROR: failed to build lint kernel TB --- 2007-07-22 11:48:01 - tinderbox aborted TB --- 0.64 user 2.65 system 5381.67 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Sun Jul 22 11:48:50 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 CC96916A418 for ; Sun, 22 Jul 2007 11:48:50 +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 9394713C474 for ; Sun, 22 Jul 2007 11:48:50 +0000 (UTC) (envelope-from mv@rulez.sk) Received: from localhost (localhost [127.0.0.1]) by mail.rulez.sk (Postfix) with ESMTP id 76A205C4F; Sun, 22 Jul 2007 13:48:49 +0200 (CEST) X-Virus-Scanned: by amavisd-new at mail.rulez.sk Received: by mail.rulez.sk (Postfix, from userid 1020) id 65F925C52; Sun, 22 Jul 2007 13:48:46 +0200 (CEST) Date: Sun, 22 Jul 2007 13:48:46 +0200 From: Milos Vyletel To: Peter Wemm Message-ID: <20070722114846.GA97996@rulez.sk> References: <20070721174631.S561@10.0.0.1> <20070722091545.GA46858@rulez.sk> <200707220406.47833.peter@wemm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200707220406.47833.peter@wemm.org> User-Agent: Mutt/1.4.2.2i Cc: current@freebsd.org Subject: Re: ULE status, invalid load, buildkernel 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, 22 Jul 2007 11:48:50 -0000 On Sun, Jul 22, 2007 at 04:06:47AM -0700, Peter Wemm wrote: > On Sunday 22 July 2007, Milos Vyletel wrote: > > On Sat, Jul 21, 2007 at 05:55:08PM -0700, Jeff Roberson wrote: > > > I have a patch available at: > > > > > > http://people.freebsd.org/~jeff/ulehtt.diff > > > > > > This resolves issues in the code that handles HTT enabled > > > processors and also adds some ULE information to bootverbose on SMP > > > systems. Peter Wemm has a seperate patch that fixes a bug where > > > some amd64 cpus were still being misidentified as HTT. Those of > > > you with invalid loads either have Hyper-threading CPUs or > > > misidentified amd cores. You should expect slightly poorer > > > performance as long as your cores are misidentified but the bad > > > loads should be fixed. > > > > > > I also believe that the buildkernel/world times are now > > > significantly improved. If this is not the case for you please > > > send a mail. Any other performance data is appreciated. > > > > > > Thanks, > > > Jeff > > > > Hi, > > > > can you please point us to refered Peter Wemm's patch too? I can't > > find it with google or on ~peter/. > > You can extract it from here: > > http://lists.freebsd.org/pipermail/p4-projects/2007-July/020058.html > > Sorry I don't have it in a more convenient format.. I'm about to fall > asleep on my keyboard. :) > > Cheers, > -Peter > No problem, I've extracted it and made a patch. If someone is intrested, it's on http://rulez.sk/~mv/cpu.patch Thank you Peter From owner-freebsd-current@FreeBSD.ORG Sun Jul 22 11:55:49 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 303C216A417; Sun, 22 Jul 2007 11:55:49 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 0922613C45D; Sun, 22 Jul 2007 11:55:48 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.13.8/8.13.8) with ESMTP id l6MBtmp2098661; Sun, 22 Jul 2007 07:55:48 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.8/8.13.8) with ESMTP id l6MBtm8i075433; Sun, 22 Jul 2007 07:55:48 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 01CE673068; Sun, 22 Jul 2007 07:55:48 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070722115548.01CE673068@freebsd-current.sentex.ca> Date: Sun, 22 Jul 2007 07:55:47 -0400 (EDT) X-Virus-Scanned: ClamAV version devel-20070102, clamav-milter version devel-111206 on clamscanner3 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on sparc64/sun4v X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jul 2007 11:55:49 -0000 TB --- 2007-07-22 10:30:07 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-07-22 10:30:07 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2007-07-22 10:30:07 - cleaning the object tree TB --- 2007-07-22 10:30:28 - checking out the source tree TB --- 2007-07-22 10:30:28 - cd /tinderbox/HEAD/sparc64/sun4v TB --- 2007-07-22 10:30:28 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-07-22 10:37:43 - building world (CFLAGS=-O2 -pipe) TB --- 2007-07-22 10:37:43 - cd /src TB --- 2007-07-22 10:37:43 - /usr/bin/make -B buildworld >>> World build started on Sun Jul 22 10:37:44 UTC 2007 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sun Jul 22 11:49:10 UTC 2007 TB --- 2007-07-22 11:49:10 - generating LINT kernel config TB --- 2007-07-22 11:49:10 - cd /src/sys/sun4v/conf TB --- 2007-07-22 11:49:10 - /usr/bin/make -B LINT TB --- 2007-07-22 11:49:10 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-07-22 11:49:10 - cd /src TB --- 2007-07-22 11:49:10 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Jul 22 11:49:10 UTC 2007 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/dev/usb/uplcom.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/dev/usb/urio.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/dev/usb/usb.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/dev/usb/usb_ethersubr.c awk -f /src/sys/tools/makeobjops.awk /src/sys/dev/usb/usb_if.m -c ; cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror usb_if.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/dev/usb/usb_mem.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/dev/usb/usb_quirks.c /src/sys/dev/usb/usb_quirks.c:111: error: 'USB_PRODUCT_METAGEEK_WISPY' undeclared here (not in a function) *** Error code 1 Stop in /obj/sun4v/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-07-22 11:55:47 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-07-22 11:55:47 - ERROR: failed to build lint kernel TB --- 2007-07-22 11:55:47 - tinderbox aborted TB --- 0.65 user 2.16 system 5140.24 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From owner-freebsd-current@FreeBSD.ORG Sun Jul 22 12:16:35 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 4369516A417 for ; Sun, 22 Jul 2007 12:16:35 +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 0A08613C45E for ; Sun, 22 Jul 2007 12:16:35 +0000 (UTC) (envelope-from mv@rulez.sk) Received: from localhost (localhost [127.0.0.1]) by mail.rulez.sk (Postfix) with ESMTP id 2001B5C37; Sun, 22 Jul 2007 14:16:34 +0200 (CEST) X-Virus-Scanned: by amavisd-new at mail.rulez.sk Received: by mail.rulez.sk (Postfix, from userid 1020) id 13A1D5C33; Sun, 22 Jul 2007 14:16:31 +0200 (CEST) Date: Sun, 22 Jul 2007 14:16:31 +0200 From: Milos Vyletel To: Peter Wemm Message-ID: <20070722121631.GA8336@rulez.sk> References: <20070721174631.S561@10.0.0.1> <20070722091545.GA46858@rulez.sk> <200707220406.47833.peter@wemm.org> <20070722114846.GA97996@rulez.sk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070722114846.GA97996@rulez.sk> User-Agent: Mutt/1.4.2.2i Cc: current@freebsd.org Subject: Re: ULE status, invalid load, buildkernel 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, 22 Jul 2007 12:16:35 -0000 On Sun, Jul 22, 2007 at 01:48:46PM +0200, Milos Vyletel wrote: > On Sun, Jul 22, 2007 at 04:06:47AM -0700, Peter Wemm wrote: > > On Sunday 22 July 2007, Milos Vyletel wrote: > > > On Sat, Jul 21, 2007 at 05:55:08PM -0700, Jeff Roberson wrote: > > > > I have a patch available at: > > > > > > > > http://people.freebsd.org/~jeff/ulehtt.diff > > > > > > > > This resolves issues in the code that handles HTT enabled > > > > processors and also adds some ULE information to bootverbose on SMP > > > > systems. Peter Wemm has a seperate patch that fixes a bug where > > > > some amd64 cpus were still being misidentified as HTT. Those of > > > > you with invalid loads either have Hyper-threading CPUs or > > > > misidentified amd cores. You should expect slightly poorer > > > > performance as long as your cores are misidentified but the bad > > > > loads should be fixed. > > > > > > > > I also believe that the buildkernel/world times are now > > > > significantly improved. If this is not the case for you please > > > > send a mail. Any other performance data is appreciated. > > > > > > > > Thanks, > > > > Jeff > > > > > > Hi, > > > > > > can you please point us to refered Peter Wemm's patch too? I can't > > > find it with google or on ~peter/. > > > > You can extract it from here: > > > > http://lists.freebsd.org/pipermail/p4-projects/2007-July/020058.html > > > > Sorry I don't have it in a more convenient format.. I'm about to fall > > asleep on my keyboard. :) > > > > Cheers, > > -Peter > > > > No problem, > > I've extracted it and made a patch. If someone is intrested, it's on > > http://rulez.sk/~mv/cpu.patch > Well, i've just updated my kernel and it paniced right after identifying cpu. 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 = 3211776000 (3062 MB) avail memory = 3105628160 (2961 MB) kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x310 fault code = supervisor read data, page not present instruction pointer = 0x8:0xffffffff8033953c stack pointer = 0x10:0xffffffff80855c70 frame pointer = 0x10:0xffffffff80855c80 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = resume, IOPL = 0 current process = 0 () this is output from from dmesg. Thanks for suggestions. Milos From owner-freebsd-current@FreeBSD.ORG Sun Jul 22 12:32: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 C7B7C16A418; Sun, 22 Jul 2007 12:32:07 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 8040C13C45B; Sun, 22 Jul 2007 12:32:07 +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 2813946BC4; Sun, 22 Jul 2007 08:32:07 -0400 (EDT) Date: Sun, 22 Jul 2007 13:32:07 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: current@FreeBSD.org Message-ID: <20070722133016.L83919@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: trustedbsd-audit@TrustedBSD.org Subject: HEADS UP: OpenBSM import (cvs commit: src/contrib/openbsm - Imported sources (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: Sun, 22 Jul 2007 12:32:07 -0000 Dear all: This probably doesn't qualify for a full "heads up" as these are really only incremental changes, but I wanted to let you know I've now imported OpenBSM 1.0 alpha 15 into the FreeBSD CVS HEAD. Hopefully this will be the last import before 7.0 (assuming no major bugs are found). I was unable to do a full LINT testbuild on today's kernel as the USB build is currently broken, but yesterday's LINT seemed to go fine. Robert N M Watson Computer Laboratory University of Cambridge ---------- Forwarded message ---------- Date: Sun, 22 Jul 2007 12:18:36 +0000 (UTC) From: Robert Watson To: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org Subject: cvs commit: src/contrib/openbsm - Imported sources rwatson 2007-07-22 12:18:36 UTC FreeBSD src repository src/contrib/openbsm - Imported sources Update of /home/ncvs/src/contrib/openbsm In directory repoman.freebsd.org:/tmp/cvs-serv59591 Log Message: Vendor import TrustedBSD OpenBSM 1.0 alpha 15, with the following change history since the last import: OpenBSM 1.0 alpha 15 - Fix bug when processing in_addr_ex tokens. - Restore the behavior of printing the string/text specified while auditing arg32 tokens. - Synchronized audit event list to Solaris, picking up the *at(2) system call definitions, now required for FreeBSD and Linux. Added additional events for *at(2) system calls not present in Solaris. - Bugs in auditreduce(8) fixed allowing partial date strings to be used in filtering events. Approved by: re (hrs) MFC after: 3 weeks Obtained from: TrustedBSD Project Status: Vendor Tag: TrustedBSD Release Tags: OPENBSM_1_0_ALPHA_15 U src/contrib/openbsm/HISTORY U src/contrib/openbsm/LICENSE U src/contrib/openbsm/Makefile.am U src/contrib/openbsm/Makefile.in U src/contrib/openbsm/README U src/contrib/openbsm/TODO U src/contrib/openbsm/VERSION U src/contrib/openbsm/aclocal.m4 U src/contrib/openbsm/autogen.sh U src/contrib/openbsm/configure U src/contrib/openbsm/configure.ac U src/contrib/openbsm/bin/Makefile.am U src/contrib/openbsm/bin/Makefile.in U src/contrib/openbsm/bin/audit/Makefile.am U src/contrib/openbsm/bin/audit/Makefile.in U src/contrib/openbsm/bin/audit/audit.8 U src/contrib/openbsm/bin/audit/audit.c U src/contrib/openbsm/bin/auditd/Makefile.am U src/contrib/openbsm/bin/auditd/Makefile.in U src/contrib/openbsm/bin/auditd/audit_warn.c U src/contrib/openbsm/bin/auditd/auditd.8 U src/contrib/openbsm/bin/auditd/auditd.c U src/contrib/openbsm/bin/auditd/auditd.h U src/contrib/openbsm/bin/auditfilterd/Makefile.am U src/contrib/openbsm/bin/auditfilterd/Makefile.in U src/contrib/openbsm/bin/auditfilterd/auditfilterd.8 U src/contrib/openbsm/bin/auditfilterd/auditfilterd.c U src/contrib/openbsm/bin/auditfilterd/auditfilterd.h U src/contrib/openbsm/bin/auditfilterd/auditfilterd_conf.c U src/contrib/openbsm/bin/auditreduce/Makefile.am U src/contrib/openbsm/bin/auditreduce/Makefile.in U src/contrib/openbsm/bin/auditreduce/auditreduce.1 U src/contrib/openbsm/bin/auditreduce/auditreduce.c U src/contrib/openbsm/bin/auditreduce/auditreduce.h U src/contrib/openbsm/bin/praudit/Makefile.am U src/contrib/openbsm/bin/praudit/Makefile.in U src/contrib/openbsm/bin/praudit/praudit.1 U src/contrib/openbsm/bin/praudit/praudit.c U src/contrib/openbsm/bsm/Makefile.am U src/contrib/openbsm/bsm/Makefile.in C src/contrib/openbsm/bsm/audit.h U src/contrib/openbsm/bsm/audit_filter.h C src/contrib/openbsm/bsm/audit_internal.h C src/contrib/openbsm/bsm/audit_kevents.h C src/contrib/openbsm/bsm/audit_record.h U src/contrib/openbsm/bsm/audit_uevents.h U src/contrib/openbsm/bsm/libbsm.h U src/contrib/openbsm/compat/clock_gettime.h U src/contrib/openbsm/compat/endian.h U src/contrib/openbsm/compat/queue.h U src/contrib/openbsm/compat/strlcat.h U src/contrib/openbsm/config/config.guess U src/contrib/openbsm/config/config.h.in U src/contrib/openbsm/config/config.sub U src/contrib/openbsm/config/depcomp U src/contrib/openbsm/config/install-sh U src/contrib/openbsm/config/ltmain.sh U src/contrib/openbsm/config/missing U src/contrib/openbsm/etc/audit_class U src/contrib/openbsm/etc/audit_control C src/contrib/openbsm/etc/audit_event U src/contrib/openbsm/etc/audit_filter U src/contrib/openbsm/etc/audit_user U src/contrib/openbsm/etc/audit_warn U src/contrib/openbsm/libbsm/Makefile.am U src/contrib/openbsm/libbsm/Makefile.in U src/contrib/openbsm/libbsm/au_class.3 U src/contrib/openbsm/libbsm/au_control.3 U src/contrib/openbsm/libbsm/au_event.3 U src/contrib/openbsm/libbsm/au_free_token.3 U src/contrib/openbsm/libbsm/au_io.3 U src/contrib/openbsm/libbsm/au_mask.3 U src/contrib/openbsm/libbsm/au_open.3 U src/contrib/openbsm/libbsm/au_token.3 U src/contrib/openbsm/libbsm/au_user.3 U src/contrib/openbsm/libbsm/audit_submit.3 U src/contrib/openbsm/libbsm/bsm_audit.c U src/contrib/openbsm/libbsm/bsm_class.c U src/contrib/openbsm/libbsm/bsm_control.c U src/contrib/openbsm/libbsm/bsm_event.c U src/contrib/openbsm/libbsm/bsm_flags.c U src/contrib/openbsm/libbsm/bsm_io.c U src/contrib/openbsm/libbsm/bsm_mask.c U src/contrib/openbsm/libbsm/bsm_notify.c U src/contrib/openbsm/libbsm/bsm_token.c U src/contrib/openbsm/libbsm/bsm_user.c U src/contrib/openbsm/libbsm/libbsm.3 U src/contrib/openbsm/libbsm/bsm_wrappers.c U src/contrib/openbsm/man/Makefile.am U src/contrib/openbsm/man/Makefile.in U src/contrib/openbsm/man/audit.2 U src/contrib/openbsm/man/audit.log.5 U src/contrib/openbsm/man/audit_class.5 U src/contrib/openbsm/man/audit_control.5 U src/contrib/openbsm/man/audit_event.5 U src/contrib/openbsm/man/audit_user.5 U src/contrib/openbsm/man/audit_warn.5 U src/contrib/openbsm/man/auditctl.2 U src/contrib/openbsm/man/auditon.2 U src/contrib/openbsm/man/getaudit.2 U src/contrib/openbsm/man/getauid.2 U src/contrib/openbsm/man/setaudit.2 U src/contrib/openbsm/man/setauid.2 U src/contrib/openbsm/modules/Makefile.am U src/contrib/openbsm/modules/Makefile.in U src/contrib/openbsm/modules/auditfilter_noop/Makefile.am U src/contrib/openbsm/modules/auditfilter_noop/Makefile.in U src/contrib/openbsm/modules/auditfilter_noop/auditfilter_noop.c U src/contrib/openbsm/test/Makefile.am U src/contrib/openbsm/test/Makefile.in U src/contrib/openbsm/test/bsm/Makefile.am U src/contrib/openbsm/test/bsm/Makefile.in U src/contrib/openbsm/test/bsm/generate.c U src/contrib/openbsm/test/reference/arg32_record U src/contrib/openbsm/test/reference/arg32_token U src/contrib/openbsm/test/reference/data_record U src/contrib/openbsm/test/reference/data_token U src/contrib/openbsm/test/reference/file_record U src/contrib/openbsm/test/reference/file_token U src/contrib/openbsm/test/reference/header32_token U src/contrib/openbsm/test/reference/in_addr_record U src/contrib/openbsm/test/reference/in_addr_token U src/contrib/openbsm/test/reference/ip_record U src/contrib/openbsm/test/reference/ip_token U src/contrib/openbsm/test/reference/ipc_record U src/contrib/openbsm/test/reference/ipc_token U src/contrib/openbsm/test/reference/iport_record U src/contrib/openbsm/test/reference/iport_token U src/contrib/openbsm/test/reference/opaque_record U src/contrib/openbsm/test/reference/opaque_token U src/contrib/openbsm/test/reference/path_record U src/contrib/openbsm/test/reference/path_token U src/contrib/openbsm/test/reference/process32_record U src/contrib/openbsm/test/reference/process32_token U src/contrib/openbsm/test/reference/process64_record U src/contrib/openbsm/test/reference/process32ex_record-IPv4 U src/contrib/openbsm/test/reference/process32ex_record-IPv6 U src/contrib/openbsm/test/reference/process32ex_token-IPv4 U src/contrib/openbsm/test/reference/process32ex_token-IPv6 U src/contrib/openbsm/test/reference/process64_token U src/contrib/openbsm/test/reference/process64ex_record-IPv4 U src/contrib/openbsm/test/reference/process64ex_record-IPv6 U src/contrib/openbsm/test/reference/process64ex_token-IPv4 U src/contrib/openbsm/test/reference/process64ex_token-IPv6 U src/contrib/openbsm/test/reference/return32_record U src/contrib/openbsm/test/reference/return32_token U src/contrib/openbsm/test/reference/seq_record U src/contrib/openbsm/test/reference/seq_token U src/contrib/openbsm/test/reference/subject32_record U src/contrib/openbsm/test/reference/subject32_token U src/contrib/openbsm/test/reference/subject32ex_record U src/contrib/openbsm/test/reference/subject32ex_token-IPv4 U src/contrib/openbsm/test/reference/subject32ex_token-IPv6 U src/contrib/openbsm/test/reference/text_record U src/contrib/openbsm/test/reference/text_token U src/contrib/openbsm/test/reference/trailer_token U src/contrib/openbsm/test/reference/zonename_record U src/contrib/openbsm/test/reference/zonename_token U src/contrib/openbsm/test/samples/execve-long-args.trail U src/contrib/openbsm/tools/Makefile.am U src/contrib/openbsm/tools/Makefile.in U src/contrib/openbsm/tools/audump.c 5 conflicts created by this import. Use the following command to help the merge: cvs checkout -jTrustedBSD:yesterday -jTrustedBSD src/contrib/openbsm From owner-freebsd-current@FreeBSD.ORG Sun Jul 22 13:22: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 319F916A419; Sun, 22 Jul 2007 13:22:05 +0000 (UTC) (envelope-from henrik@brixandersen.dk) Received: from solow.pil.dk (relay.pil.dk [195.41.47.164]) by mx1.freebsd.org (Postfix) with ESMTP id EA03213C45B; Sun, 22 Jul 2007 13:22:04 +0000 (UTC) (envelope-from henrik@brixandersen.dk) Received: from tirith.brixandersen.dk (osgiliath.brixandersen.dk [87.53.223.189]) by solow.pil.dk (Postfix) with ESMTP id 336941CC0DF; Sun, 22 Jul 2007 14:50:33 +0200 (CEST) Received: by tirith.brixandersen.dk (Postfix, from userid 1001) id AA54CB860; Sun, 22 Jul 2007 14:50:32 +0200 (CEST) Date: Sun, 22 Jul 2007 14:50:32 +0200 From: Henrik Brix Andersen To: FreeBSD Tinderbox Message-ID: <20070722125032.GC18229@tirith.brixandersen.dk> References: <20070722081942.B4BED73068@freebsd-current.sentex.ca> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="n/aVsWSeQ4JHkrmm" Content-Disposition: inline In-Reply-To: <20070722081942.B4BED73068@freebsd-current.sentex.ca> X-PGP-Key: http://www.brixandersen.dk/files/HenrikBrixAndersen.asc User-Agent: Mutt/1.5.16 (2007-06-09) Cc: current@freebsd.org, i386@freebsd.org Subject: Re: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jul 2007 13:22:05 -0000 --n/aVsWSeQ4JHkrmm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jul 22, 2007 at 04:19:42AM -0400, FreeBSD Tinderbox wrote: > cc -c -O2 -pipe -fno-strict-aliasing -std=3Dc99 -Wall -Wredundant-decls= -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith= -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostd= inc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_= HEADERS -include opt_global.h -fno-common -finline-limit=3D8000 --param inl= ine-unit-growth=3D100 --param large-function-growth=3D1000 -DGPROF -falign-= functions=3D16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpre= ferred-stack-boundary=3D2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3= -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/dev/usb/usb_quirks= =2Ec > /src/sys/dev/usb/usb_quirks.c:111: error: 'USB_PRODUCT_METAGEEK_WISPY' un= declared here (not in a function) > *** Error code 1 Could somebody please review and commit my patch which is attached to usb/114807? http://www.freebsd.org/cgi/query-pr.cgi?pr=3D114807 Thanks. Regards, Brix --=20 Henrik Brix Andersen --n/aVsWSeQ4JHkrmm Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) Comment: GnuPG signed iD8DBQFGo1KYv+Q4flTiePgRAoWcAJoCd03LcePKQNkgRIS9gLixbRN9KgCeKUs6 DtxFFcUR2TfUlWMiYSr0+d8= =a9U5 -----END PGP SIGNATURE----- --n/aVsWSeQ4JHkrmm-- From owner-freebsd-current@FreeBSD.ORG Sun Jul 22 14:05:35 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 E17A616A417; Sun, 22 Jul 2007 14:05:35 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id 95E0B13C442; Sun, 22 Jul 2007 14:05:35 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.14.1/8.13.8) with ESMTP id l6ME5Z9F032667; Sun, 22 Jul 2007 10:05:35 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.1/8.14.1) with ESMTP id l6ME5YEg019962; Sun, 22 Jul 2007 10:05:34 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 76D4373068; Sun, 22 Jul 2007 10:05:34 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070722140534.76D4373068@freebsd-current.sentex.ca> Date: Sun, 22 Jul 2007 10:05:34 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.91.1, clamav-milter version 0.91.1 on clamscanner4 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jul 2007 14:05:36 -0000 TB --- 2007-07-22 12:00:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-07-22 12:00:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2007-07-22 12:00:00 - cleaning the object tree TB --- 2007-07-22 12:00:34 - checking out the source tree TB --- 2007-07-22 12:00:34 - cd /tinderbox/HEAD/amd64/amd64 TB --- 2007-07-22 12:00:34 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-07-22 12:10:57 - building world (CFLAGS=-O2 -pipe) TB --- 2007-07-22 12:10:57 - cd /src TB --- 2007-07-22 12:10:57 - /usr/bin/make -B buildworld >>> World build started on Sun Jul 22 12:10:58 UTC 2007 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Sun Jul 22 13:56:15 UTC 2007 TB --- 2007-07-22 13:56:15 - generating LINT kernel config TB --- 2007-07-22 13:56:15 - cd /src/sys/amd64/conf TB --- 2007-07-22 13:56:15 - /usr/bin/make -B LINT TB --- 2007-07-22 13:56:15 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-07-22 13:56:15 - cd /src TB --- 2007-07-22 13:56:15 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Jul 22 13:56:15 UTC 2007 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/dev/usb/uplcom.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/dev/usb/urio.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/dev/usb/usb.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/dev/usb/usb_ethersubr.c awk -f /src/sys/tools/makeobjops.awk /src/sys/dev/usb/usb_if.m -c ; cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue usb_if.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/dev/usb/usb_mem.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/dev/usb/usb_quirks.c /src/sys/dev/usb/usb_quirks.c:111: error: 'USB_PRODUCT_METAGEEK_WISPY' undeclared here (not in a function) *** Error code 1 Stop in /obj/amd64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-07-22 14:05:34 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-07-22 14:05:34 - ERROR: failed to build lint kernel TB --- 2007-07-22 14:05:34 - tinderbox aborted TB --- 0.87 user 2.87 system 7533.79 real http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Sun Jul 22 14:20:14 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 6E6D616A41F for ; Sun, 22 Jul 2007 14:20:14 +0000 (UTC) (envelope-from patfbsdc@davenulle.org) Received: from smtp.lamaiziere.net (net.lamaiziere.net [213.186.42.107]) by mx1.freebsd.org (Postfix) with ESMTP id 3D5A713C480 for ; Sun, 22 Jul 2007 14:20:14 +0000 (UTC) (envelope-from patfbsdc@davenulle.org) Received: from roxette (unknown [77.192.6.16]) by smtp.lamaiziere.net (Postfix) with ESMTP id 5B2C3118058C for ; Sun, 22 Jul 2007 15:53:57 +0200 (CEST) Date: Sun, 22 Jul 2007 15:53:56 +0200 From: Patrick Lamaiziere To: freebsd-current@freebsd.org Message-ID: <20070722155356.49797993@roxette> In-Reply-To: <46A2B49F.4030307@freebsd.org> References: <46A2B49F.4030307@freebsd.org> Organization: /dave/nulle X-Mailer: Claws Mail 2.9.2 (GTK+ 2.10.13; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit Subject: Re: LOR's, and a panic (ipf NAT related?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Jul 2007 14:20:14 -0000 Le Sat, 21 Jul 2007 20:36:31 -0500, Eric Anderson a écrit : > Today, on a -CURRENT from a few days ago (running ULE 3.0), I got a > panic: > > panic: Trying sleep, but thread marked as sleeping prohibited > cpuid = 0 > > #8 0xc074a474 in panic (fmt=0xc0a979a9 "Trying sleep, but thread > marked as sleeping prohibited") > at /usr/src/sys/kern/kern_shutdown.c:547 > #9 0xc077abd2 in sleepq_add (wchan=0xc0e20980, lock=0x0, > wmesg=0xc0e1b709 "ipf IP NAT rwlock", flags=3, queue=0) > at /usr/src/sys/kern/subr_sleepqueue.c:289 > #10 0xc07519ee in _sx_xlock_hard (sx=0xc0e20980, tid=3306307584, > opts=0, file=0xc0e1b65e > "/usr/src/sys/modules/ipfilter/../../contrib/ipfilter/netinet/ip_nat.c", > line=4384) > at /usr/src/sys/kern/kern_sx.c:548 > #11 0xc0751d18 in _sx_xlock (sx=0xc0e20980, opts=0, > file=0xc0e1b65e > "/usr/src/sys/modules/ipfilter/../../contrib/ipfilter/netinet/ip_nat.c", > line=4384) at sx.h:153 I've seen this panic this night too. > I also see these (maybe related) LOR's on bootup: Mee too, it occurs when ipl.ko is loaded. [Current from last night, kernel GENERIC/i386] From owner-freebsd-current@FreeBSD.ORG Sun Jul 22 14:32:33 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 34D5116A421 for ; Sun, 22 Jul 2007 14:32:33 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.170]) by mx1.freebsd.org (Postfix) with ESMTP id BC5B513C481 for ; Sun, 22 Jul 2007 14:32:32 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by ug-out-1314.google.com with SMTP id o4so1089111uge for ; Sun, 22 Jul 2007 07:32: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:reply-to:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding:sender; b=MgGQHVvNg0gFEvIAXVa3PENETSm7eP4qPDKSy5PDa6iC9zJPsKDs0P37oY3A+a+IG08oriTOiKvc2JeOALy7OrPIsecb7LRKXcug5wTw+ZvX4sD61NkEi2i015ATda6yjNGbu2x2xS3IykRrAjf8GRyoKAG2PCjjTjB028TLy9I= 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=CxblMoQBuFUssuOkJ40GoV+Hnxj75igop5dpQcsC1/VlB+kaHSTBbTdC0X/E4iOSXymD0I5u4tWBY4g8Av8MnzvWyL2Gw4eHnf+Qn8j3eZayobhpWLoTwMmnu4HQxBAtCYAioNZ6Yk67Ngk18OAR737fNwhKPs5jdqwV5eeIfPY= Received: by 10.67.19.17 with SMTP id w17mr3467831ugi.1185114750981; Sun, 22 Jul 2007 07:32:30 -0700 (PDT) Received: from ?151.75.245.230? ( [151.75.245.230]) by mx.google.com with ESMTPS id d2sm5517022nfc.2007.07.22.07.32.30 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 22 Jul 2007 07:32:30 -0700 (PDT) Message-ID: <46A36A49.2090303@FreeBSD.org> Date: Sun, 22 Jul 2007 16:31:37 +0200 From: Attilio Rao User-Agent: Thunderbird 1.5 (X11/20060526) MIME-Version: 1.0 To: Patrick Lamaiziere References: <46A2B49F.4030307@freebsd.org> <20070722155356.49797993@roxette> In-Reply-To: <20070722155356.49797993@roxette> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit Sender: Attilio Rao Cc: freebsd-current@freebsd.org Subject: Re: LOR's, and a panic (ipf NAT related?) 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: Sun, 22 Jul 2007 14:32:33 -0000 Patrick Lamaiziere wrote: > Le Sat, 21 Jul 2007 20:36:31 -0500, > Eric Anderson a écrit : > >> Today, on a -CURRENT from a few days ago (running ULE 3.0), I got a >> panic: >> >> panic: Trying sleep, but thread marked as sleeping prohibited >> cpuid = 0 >> This one should have been fixed in last ULE3.0 revision, could you please update your src/sys and see if it goes away? About the other LORs, you should see in the bz's page if they are alredy listes, since it seems I remind at least one of them: http://sources.zabbadoz.net/freebsd/lor.html Thanks, Attilio From owner-freebsd-current@FreeBSD.ORG Sun Jul 22 14:55:38 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 F1C2916A41B for ; Sun, 22 Jul 2007 14:55:38 +0000 (UTC) (envelope-from patfbsdc@davenulle.org) Received: from smtp.lamaiziere.net (net.lamaiziere.net [213.186.42.107]) by mx1.freebsd.org (Postfix) with ESMTP id C0B1113C4A6 for ; Sun, 22 Jul 2007 14:55:38 +0000 (UTC) (envelope-from patfbsdc@davenulle.org) Received: from roxette (unknown [77.192.6.16]) by smtp.lamaiziere.net (Postfix) with ESMTP id A40C11180597 for ; Sun, 22 Jul 2007 16:55:37 +0200 (CEST) Date: Sun, 22 Jul 2007 16:55:31 +0200 From: Patrick Lamaiziere To: freebsd-current@freebsd.org Message-ID: <20070722165531.74960057@roxette> In-Reply-To: <46A36A49.2090303@FreeBSD.org> References: <46A2B49F.4030307@freebsd.org> <20070722155356.49797993@roxette> <46A36A49.2090303@FreeBSD.org> Organization: /dave/nulle X-Mailer: Claws Mail 2.9.2 (GTK+ 2.10.13; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit Subject: Re: LOR's, and a panic (ipf NAT related?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Jul 2007 14:55:39 -0000 Le Sun, 22 Jul 2007 16:31:37 +0200, Attilio Rao a écrit : > This one should have been fixed in last ULE3.0 revision, could you > please update your src/sys and see if it goes away? I use the stock GENERIC kernel and the scheduler is SCHED_4BSD. > About the other LORs, you should see in the bz's page if they are > alredy listes, since it seems I remind at least one of them: > http://sources.zabbadoz.net/freebsd/lor.html I've checked the list, this LOR is not listed i think. There is the LOR #50 related to ip_nat.c. But none with (1st) ip_nat.c, (2nd) ip_nat.c and "sleepable after non-sleepable" Thanks, regards. From owner-freebsd-current@FreeBSD.ORG Sun Jul 22 14:56:57 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 6E28416A417; Sun, 22 Jul 2007 14:56:57 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id 3BF6513C458; Sun, 22 Jul 2007 14:56:57 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.14.1/8.13.8) with ESMTP id l6MEuu8s034623; Sun, 22 Jul 2007 10:56:56 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.1/8.14.1) with ESMTP id l6MEuula019558; Sun, 22 Jul 2007 10:56:56 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 5F4B173068; Sun, 22 Jul 2007 10:56:56 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070722145656.5F4B173068@freebsd-current.sentex.ca> Date: Sun, 22 Jul 2007 10:56:56 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.91.1, clamav-milter version 0.91.1 on news X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jul 2007 14:56:57 -0000 TB --- 2007-07-22 13:23:08 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-07-22 13:23:08 - starting HEAD tinderbox run for i386/i386 TB --- 2007-07-22 13:23:08 - cleaning the object tree TB --- 2007-07-22 13:23:31 - checking out the source tree TB --- 2007-07-22 13:23:31 - cd /tinderbox/HEAD/i386/i386 TB --- 2007-07-22 13:23:31 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-07-22 13:31:13 - building world (CFLAGS=-O2 -pipe) TB --- 2007-07-22 13:31:13 - cd /src TB --- 2007-07-22 13:31:13 - /usr/bin/make -B buildworld >>> World build started on Sun Jul 22 13:31:14 UTC 2007 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sun Jul 22 14:46:27 UTC 2007 TB --- 2007-07-22 14:46:27 - generating LINT kernel config TB --- 2007-07-22 14:46:27 - cd /src/sys/i386/conf TB --- 2007-07-22 14:46:27 - /usr/bin/make -B LINT TB --- 2007-07-22 14:46:27 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-07-22 14:46:27 - cd /src TB --- 2007-07-22 14:46:27 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Jul 22 14:46:28 UTC 2007 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/dev/usb/uplcom.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/dev/usb/urio.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/dev/usb/usb.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/dev/usb/usb_ethersubr.c awk -f /src/sys/tools/makeobjops.awk /src/sys/dev/usb/usb_if.m -c ; cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue usb_if.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/dev/usb/usb_mem.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/dev/usb/usb_quirks.c /src/sys/dev/usb/usb_quirks.c:111: error: 'USB_PRODUCT_METAGEEK_WISPY' undeclared here (not in a function) *** Error code 1 Stop in /obj/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-07-22 14:56:55 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-07-22 14:56:55 - ERROR: failed to build lint kernel TB --- 2007-07-22 14:56:55 - tinderbox aborted TB --- 0.56 user 2.08 system 5627.65 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Sun Jul 22 15:35: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 41BAA16A417; Sun, 22 Jul 2007 15:35:44 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id 1029513C480; Sun, 22 Jul 2007 15:35:43 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.14.1/8.13.8) with ESMTP id l6MFZhEQ036367; Sun, 22 Jul 2007 11:35:43 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.1/8.14.1) with ESMTP id l6MFZhWq097732; Sun, 22 Jul 2007 11:35:43 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 336DD73068; Sun, 22 Jul 2007 11:35:43 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070722153543.336DD73068@freebsd-current.sentex.ca> Date: Sun, 22 Jul 2007 11:35:42 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.91.1, clamav-milter version 0.91.1 on clamscanner2 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jul 2007 15:35:44 -0000 TB --- 2007-07-22 14:05:34 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-07-22 14:05:34 - starting HEAD tinderbox run for i386/pc98 TB --- 2007-07-22 14:05:34 - cleaning the object tree TB --- 2007-07-22 14:06:01 - checking out the source tree TB --- 2007-07-22 14:06:01 - cd /tinderbox/HEAD/i386/pc98 TB --- 2007-07-22 14:06:01 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-07-22 14:13:46 - building world (CFLAGS=-O2 -pipe) TB --- 2007-07-22 14:13:46 - cd /src TB --- 2007-07-22 14:13:46 - /usr/bin/make -B buildworld >>> World build started on Sun Jul 22 14:13:47 UTC 2007 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sun Jul 22 15:27:56 UTC 2007 TB --- 2007-07-22 15:27:56 - generating LINT kernel config TB --- 2007-07-22 15:27:56 - cd /src/sys/pc98/conf TB --- 2007-07-22 15:27:56 - /usr/bin/make -B LINT TB --- 2007-07-22 15:27:56 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-07-22 15:27:56 - cd /src TB --- 2007-07-22 15:27:56 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Jul 22 15:27:56 UTC 2007 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -pg -mprofiler-epilogue /src/sys/dev/usb/uplcom.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -pg -mprofiler-epilogue /src/sys/dev/usb/urio.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -pg -mprofiler-epilogue /src/sys/dev/usb/usb.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -pg -mprofiler-epilogue /src/sys/dev/usb/usb_ethersubr.c awk -f /src/sys/tools/makeobjops.awk /src/sys/dev/usb/usb_if.m -c ; cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -pg -mprofiler-epilogue usb_if.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -pg -mprofiler-epilogue /src/sys/dev/usb/usb_mem.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -pg -mprofiler-epilogue /src/sys/dev/usb/usb_quirks.c /src/sys/dev/usb/usb_quirks.c:111: error: 'USB_PRODUCT_METAGEEK_WISPY' undeclared here (not in a function) *** Error code 1 Stop in /obj/pc98/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-07-22 15:35:42 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-07-22 15:35:42 - ERROR: failed to build lint kernel TB --- 2007-07-22 15:35:42 - tinderbox aborted TB --- 0.67 user 2.07 system 5408.34 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Sun Jul 22 15:44:50 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 D8FEE16A421 for ; Sun, 22 Jul 2007 15:44:50 +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 6DE7413C4CC for ; Sun, 22 Jul 2007 15:44:50 +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 CE951690E3D; Sun, 22 Jul 2007 16:38:32 +0100 (WEST) Received: by core.fnop.net (Postfix, from userid 1015) id 75179690E5E; Sun, 22 Jul 2007 16:38:32 +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.0 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.7 Received: from epsilon.local (62.169.100.231.rev.optimus.pt [62.169.100.231]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by core.fnop.net (Postfix) with ESMTP id 1F590690E3D; Sun, 22 Jul 2007 16:38:28 +0100 (WEST) Message-ID: <46A37B6B.2050901@fnop.net> Date: Sun, 22 Jul 2007 16:44:43 +0100 From: Rui Paulo User-Agent: Thunderbird 2.0.0.4 (X11/20070704) MIME-Version: 1.0 To: Andrew Gallatin References: <18082.16126.915890.401438@grasshopper.cs.duke.edu> In-Reply-To: <18082.16126.915890.401438@grasshopper.cs.duke.edu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: current@freebsd.org Subject: Re: 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: Sun, 22 Jul 2007 15:44:50 -0000 Andrew Gallatin wrote: > [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? As a workaround try using a 6.2 CD. > On a somewhat related note, how well does FreeBSD even work on > an iMac? Can we suspend/resume SMP machines yet? No. -- Rui Paulo From owner-freebsd-current@FreeBSD.ORG Sun Jul 22 16:27: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 BADB216A417 for ; Sun, 22 Jul 2007 16:27:52 +0000 (UTC) (envelope-from tom.hurst@clara.net) Received: from spork.qfe3.net (spork.qfe3.net [212.13.207.101]) by mx1.freebsd.org (Postfix) with ESMTP id 82E4D13C458 for ; Sun, 22 Jul 2007 16:27:52 +0000 (UTC) (envelope-from tom.hurst@clara.net) Received: from [81.104.144.87] (helo=voi.aagh.net) by spork.qfe3.net with esmtp (Exim 4.66 (FreeBSD)) (envelope-from ) id 1ICe00-0006ab-I0; Sun, 22 Jul 2007 17:09:36 +0100 Received: from freaky by voi.aagh.net with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ICdzz-0004zc-PA; Sun, 22 Jul 2007 17:09:35 +0100 Date: Sun, 22 Jul 2007 17:09:35 +0100 From: Thomas Hurst To: Chris Dionissopoulos Message-ID: <20070722160935.GA18069@voi.aagh.net> Mail-Followup-To: Chris Dionissopoulos , Jeff Roberson , current@freebsd.org References: <20070721174631.S561@10.0.0.1> <1807103749.20070722111025@freemail.gr> <20070722014208.G561@10.0.0.1> <684796249.20070722134105@freemail.gr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <684796249.20070722134105@freemail.gr> Organization: Not much. User-Agent: Mutt/1.5.15 (2007-04-06) Sender: Thomas Hurst Cc: Jeff Roberson , current@freebsd.org Subject: Re: ULE status, invalid load, buildkernel 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, 22 Jul 2007 16:27:52 -0000 * Chris Dionissopoulos (dionch@freemail.gr) wrote: > But looking more carefully I found that I can reproduce PANIC anytime > using command: > > mail# sysctl dev.cpu.0.freq=1596 > > -- where 1596 is valid Hz option as shown in: > dev.cpu.0.freq: 1862 > dev.cpu.0.freq_levels: 1862/89000 1629/77875 1596/63546 1396/55602 1197/47659 997/39716 798/31773 598/23829 399/15886 199/7943 It looks like you're running acpi_throttle, which I've seen cause problems before. Try adding: hint.acpi_throttle.0.disabled="1" To /boot/device.hints so you're left with just the powernow frequencies (assuming this is an AMD64, going by the 89W max TDP). -- Thomas 'Freaky' Hurst http://hur.st/ From owner-freebsd-current@FreeBSD.ORG Sun Jul 22 16:55: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 4B58116A417; Sun, 22 Jul 2007 16:55:16 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 15ABF13C428; Sun, 22 Jul 2007 16:55:16 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.8/8.13.8) with ESMTP id l6MGtFHn006150; Sun, 22 Jul 2007 12:55:15 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.1/8.14.1) with ESMTP id l6MGtF1C052575; Sun, 22 Jul 2007 12:55:15 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 57F9D73068; Sun, 22 Jul 2007 12:55:15 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070722165515.57F9D73068@freebsd-current.sentex.ca> Date: Sun, 22 Jul 2007 12:55:15 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.91.1, clamav-milter version 0.91.1 on news X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jul 2007 16:55:16 -0000 TB --- 2007-07-22 14:56:56 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-07-22 14:56:56 - starting HEAD tinderbox run for ia64/ia64 TB --- 2007-07-22 14:56:56 - cleaning the object tree TB --- 2007-07-22 14:57:16 - checking out the source tree TB --- 2007-07-22 14:57:16 - cd /tinderbox/HEAD/ia64/ia64 TB --- 2007-07-22 14:57:16 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-07-22 15:04:14 - building world (CFLAGS=-O2 -pipe) TB --- 2007-07-22 15:04:14 - cd /src TB --- 2007-07-22 15:04:14 - /usr/bin/make -B buildworld >>> World build started on Sun Jul 22 15:04:16 UTC 2007 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sun Jul 22 16:44:39 UTC 2007 TB --- 2007-07-22 16:44:39 - generating LINT kernel config TB --- 2007-07-22 16:44:39 - cd /src/sys/ia64/conf TB --- 2007-07-22 16:44:39 - /usr/bin/make -B LINT TB --- 2007-07-22 16:44:39 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-07-22 16:44:39 - cd /src TB --- 2007-07-22 16:44:39 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Jul 22 16:44:39 UTC 2007 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding /src/sys/dev/usb/uplcom.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding /src/sys/dev/usb/urio.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding /src/sys/dev/usb/usb.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding /src/sys/dev/usb/usb_ethersubr.c awk -f /src/sys/tools/makeobjops.awk /src/sys/dev/usb/usb_if.m -c ; cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding usb_if.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding /src/sys/dev/usb/usb_mem.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding /src/sys/dev/usb/usb_quirks.c /src/sys/dev/usb/usb_quirks.c:111: error: 'USB_PRODUCT_METAGEEK_WISPY' undeclared here (not in a function) *** Error code 1 Stop in /obj/ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-07-22 16:55:15 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-07-22 16:55:15 - ERROR: failed to build lint kernel TB --- 2007-07-22 16:55:15 - tinderbox aborted TB --- 0.68 user 1.91 system 7098.66 real http://tinderbox.des.no/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Sun Jul 22 17:07: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 E398416A418; Sun, 22 Jul 2007 17:07:06 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id C1E1B13C461; Sun, 22 Jul 2007 17:07:06 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.14.1/8.13.8) with ESMTP id l6MH76fc039950; Sun, 22 Jul 2007 13:07:06 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.1/8.14.1) with ESMTP id l6MH76hJ077677; Sun, 22 Jul 2007 13:07:06 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 031BC73068; Sun, 22 Jul 2007 13:07:05 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070722170706.031BC73068@freebsd-current.sentex.ca> Date: Sun, 22 Jul 2007 13:07:05 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.91.1, clamav-milter version 0.91.1 on news X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jul 2007 17:07:07 -0000 TB --- 2007-07-22 15:35:43 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-07-22 15:35:43 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2007-07-22 15:35:43 - cleaning the object tree TB --- 2007-07-22 15:35:58 - checking out the source tree TB --- 2007-07-22 15:35:58 - cd /tinderbox/HEAD/powerpc/powerpc TB --- 2007-07-22 15:35:58 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-07-22 15:43:49 - building world (CFLAGS=-O2 -pipe) TB --- 2007-07-22 15:43:49 - cd /src TB --- 2007-07-22 15:43:49 - /usr/bin/make -B buildworld >>> World build started on Sun Jul 22 15:43:50 UTC 2007 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sun Jul 22 16:59:19 UTC 2007 TB --- 2007-07-22 16:59:19 - generating LINT kernel config TB --- 2007-07-22 16:59:19 - cd /src/sys/powerpc/conf TB --- 2007-07-22 16:59:19 - /usr/bin/make -B LINT TB --- 2007-07-22 16:59:19 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-07-22 16:59:19 - cd /src TB --- 2007-07-22 16:59:19 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Jul 22 16:59:19 UTC 2007 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding /src/sys/dev/usb/uplcom.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding /src/sys/dev/usb/urio.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding /src/sys/dev/usb/usb.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding /src/sys/dev/usb/usb_ethersubr.c awk -f /src/sys/tools/makeobjops.awk /src/sys/dev/usb/usb_if.m -c ; cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding usb_if.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding /src/sys/dev/usb/usb_mem.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding /src/sys/dev/usb/usb_quirks.c /src/sys/dev/usb/usb_quirks.c:111: error: 'USB_PRODUCT_METAGEEK_WISPY' undeclared here (not in a function) *** Error code 1 Stop in /obj/powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-07-22 17:07:05 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-07-22 17:07:05 - ERROR: failed to build lint kernel TB --- 2007-07-22 17:07:05 - tinderbox aborted TB --- 0.56 user 1.96 system 5482.61 real http://tinderbox.des.no/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Sun Jul 22 18:02: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 C0D9A16A417 for ; Sun, 22 Jul 2007 18:02:53 +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 54F3413C468 for ; Sun, 22 Jul 2007 18:02:53 +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 l6MI2ntj074920 for ; Sun, 22 Jul 2007 19:02:50 +0100 (BST) (envelope-from dfr@rabson.org) From: Doug Rabson To: current@freebsd.org Date: Sun, 22 Jul 2007 19:02:49 +0100 User-Agent: KMail/1.9.6 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200707221902.49369.dfr@rabson.org> X-Virus-Scanned: ClamAV 0.87.1/3729/Sun Jul 22 17:10:33 2007 on itchy.rabson.org X-Virus-Status: Clean Cc: Subject: Weird thread error which breaks the gtk-sharp build X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Jul 2007 18:02:53 -0000 I was giving my machine a bit of a workout to test some patches and I happened to pick the gnome2 ports build. All was going swimmingly until it fell flat on its face attempting to build gtk-sharp. As it turned out, an error (warning?) message from libthr had turned up in one of the source files that the build generated. I tweaked my sources as below to get around it but I'm not really sure of the right fix: Index: thr_private.h =================================================================== RCS file: /home/ncvs/src/lib/libthr/thread/thr_private.h,v retrieving revision 1.77 diff -u -r1.77 thr_private.h --- thr_private.h 20 Dec 2006 04:43:34 -0000 1.77 +++ thr_private.h 22 Jul 2007 17:54:21 -0000 @@ -72,7 +72,7 @@ /* Output debug messages like this: */ #define stdout_debug(args...) _thread_printf(STDOUT_FILENO, ##args) -#define stderr_debug(args...) _thread_printf(STDOUT_FILENO, ##args) +#define stderr_debug(args...) _thread_printf(STDERR_FILENO, ##args) #ifdef _PTHREADS_INVARIANTS #define THR_ASSERT(cond, msg) do { \ From owner-freebsd-current@FreeBSD.ORG Sun Jul 22 19:11: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 7519716A41B for ; Sun, 22 Jul 2007 19:11:01 +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 20E8613C45D for ; Sun, 22 Jul 2007 19:11:01 +0000 (UTC) (envelope-from markhobden@gmail.com) Received: by wx-out-0506.google.com with SMTP id i29so1141971wxd for ; Sun, 22 Jul 2007 12:11:00 -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=LzA/BhlhpbP4ODkhBYO909qVEorTrOfZSmB6EB16owS+lBM8+cfpnmURqOGcroUr7AMIhnXt8LbZ1A7fFkEo7q13rDWd3RQeINOmRktfue5HUElx00lDQIZUTJDL9BdqlLoteV4/d/Pakv+ENDgRdKeBoOLVIZi4bXqM4cerCDo= 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=ofoZUVSlRQQ5T5f4SPpFa9k4a+3MyiFv4QG4UGytF6ErzkmCNmrr2DqguZ5V/1o6tv/5Fa2/Mp5KZXjHfpQ51wOW/LuhamQsFDTf51adOIIsCsIDdWHzqWDf5b+5c1+pkXUUm5pCrRWOuViymq3Yooy54tsmWLMXthAeJvZPkAs= Received: by 10.90.113.18 with SMTP id l18mr1409348agc.1185131460178; Sun, 22 Jul 2007 12:11:00 -0700 (PDT) Received: by 10.90.117.10 with HTTP; Sun, 22 Jul 2007 12:11:00 -0700 (PDT) Message-ID: Date: Sun, 22 Jul 2007 20:11:00 +0100 From: "Mark Hobden" To: vova@fbsd.ru In-Reply-To: <1185011732.1420.4.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> <1185011732.1420.4.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: Sun, 22 Jul 2007 19:11:01 -0000 On 21/07/07, Vladimir Grebenschikov wrote: > > > > 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 > > 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. Hi Vladimir, Thanks for all the info. I am having trouble reproducing a panic like this here or finding out how it gets down a path like this. I am wondering if this only occurs on EHCI devices. Hopefully later in the week I will be able to borrow some equipment from work to test with here. But do you have a different keyboard that you could try out booting on the UHCI controller? If that works OK it should show me where to look. I'm afraid I don't know about setting dump devices before booting as in the past I have always triggered them by attaching hardware after the system is booted. <:-| The other problem for you would be that because all the usb modules are loaded as modules you need to load them individually into kgdb with their start address as described in the link below: http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug-kld.html Which wouldn't be fun as each time you want to load kgdb you have to do this for usb, uhid and ukbd. I find it easier to just compile them into the kernel. Kind Regards, Mark From owner-freebsd-current@FreeBSD.ORG Sun Jul 22 19:28: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 C305516A418 for ; Sun, 22 Jul 2007 19:28:53 +0000 (UTC) (envelope-from tmclaugh@sdf.lonestar.org) Received: from straycat.dhs.org (c-24-63-86-11.hsd1.ma.comcast.net [24.63.86.11]) by mx1.freebsd.org (Postfix) with ESMTP id 89ACE13C45E for ; Sun, 22 Jul 2007 19:28:53 +0000 (UTC) (envelope-from tmclaugh@sdf.lonestar.org) Received: from [192.168.1.127] (bofh.straycat.dhs.org [192.168.1.127]) by straycat.dhs.org (8.13.8/8.13.8) with ESMTP id l6MJGfZa028863; Sun, 22 Jul 2007 15:16:42 -0400 (EDT) From: Tom McLaughlin To: Doug Rabson In-Reply-To: <200707221902.49369.dfr@rabson.org> References: <200707221902.49369.dfr@rabson.org> Content-Type: text/plain Date: Sun, 22 Jul 2007 15:16:41 -0400 Message-Id: <1185131801.1955.44.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.10.2 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: Weird thread error which breaks the gtk-sharp build X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Jul 2007 19:28:53 -0000 On Sun, 2007-07-22 at 19:02 +0100, Doug Rabson wrote: > I was giving my machine a bit of a workout to test some patches and I > happened to pick the gnome2 ports build. All was going swimmingly until > it fell flat on its face attempting to build gtk-sharp. As it turned > out, an error (warning?) message from libthr had turned up in one of > the source files that the build generated. I tweaked my sources as > below to get around it but I'm not really sure of the right fix: > > Index: thr_private.h > =================================================================== > RCS file: /home/ncvs/src/lib/libthr/thread/thr_private.h,v > retrieving revision 1.77 > diff -u -r1.77 thr_private.h > --- thr_private.h 20 Dec 2006 04:43:34 -0000 1.77 > +++ thr_private.h 22 Jul 2007 17:54:21 -0000 > @@ -72,7 +72,7 @@ > > /* Output debug messages like this: */ > #define stdout_debug(args...) _thread_printf(STDOUT_FILENO, ##args) > -#define stderr_debug(args...) _thread_printf(STDOUT_FILENO, ##args) > +#define stderr_debug(args...) _thread_printf(STDERR_FILENO, ##args) > > #ifdef _PTHREADS_INVARIANTS > #define THR_ASSERT(cond, msg) do { \ This error has been a real pain. I've only been able to generate it in my tinderbox [1]. Building it manually hasn't been a problem for me. In addition, if I ran my tinderbox enough times eventually gtk-sharp and gnome-sharp would build. [1] http://straycat.dhs.org/tb/errors/7-i386-FreeBSD/gtk-sharp-1.0.10_13.log tom -- | tmclaugh at sdf.lonestar.org tmclaugh at FreeBSD.org | | FreeBSD http://www.FreeBSD.org | From owner-freebsd-current@FreeBSD.ORG Sun Jul 22 20:32: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 AB22E16A419 for ; Sun, 22 Jul 2007 20:32:07 +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 7500113C428 for ; Sun, 22 Jul 2007 20:32:07 +0000 (UTC) (envelope-from dionch@freemail.gr) Received: from CDION (ppp232-205.dsl.hol.gr [89.210.232.205]) by smtp.freemail.gr (Postfix) with ESMTP id F10C0A08265; Sun, 22 Jul 2007 23:32:05 +0300 (EEST) Date: Sun, 22 Jul 2007 23:29:25 +0300 From: Chris Dionissopoulos X-Mailer: The Bat! (v3.80.06) Professional X-Priority: 3 (Normal) Message-ID: <751338143.20070722232925@freemail.gr> To: Thomas Hurst In-Reply-To: <20070722160935.GA18069@voi.aagh.net> References: <20070721174631.S561@10.0.0.1> <1807103749.20070722111025@freemail.gr> <20070722014208.G561@10.0.0.1> <684796249.20070722134105@freemail.gr> <20070722160935.GA18069@voi.aagh.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Jeff Roberson , current@freebsd.org Subject: Re[2]: ULE status, invalid load, buildkernel times. 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: Sun, 22 Jul 2007 20:32:07 -0000 Hello Thomas, Sunday, July 22, 2007, 7:09:35 PM, you wrote: > * Chris Dionissopoulos (dionch@freemail.gr) wrote: >> But looking more carefully I found that I can reproduce PANIC anytime >> using command: >> >> mail# sysctl dev.cpu.0.freq=1596 >> >> -- where 1596 is valid Hz option as shown in: >> dev.cpu.0.freq: 1862 >> dev.cpu.0.freq_levels: 1862/89000 1629/77875 1596/63546 1396/55602 1197/47659 997/39716 798/31773 598/23829 399/15886 199/7943 > It looks like you're running acpi_throttle, which I've seen cause > problems before. Try adding: > hint.acpi_throttle.0.disabled="1" > To /boot/device.hints so you're left with just the powernow frequencies > (assuming this is an AMD64, going by the 89W max TDP). Its an Intel c2d-6300 (see prev. messages) using cpufreq(4). Everything works fine (for 6 months or more) with 4BSD or ULE2/3(unpatched) scheduler. AFAIK, the problem Jeff trying to resolve is why a ULE3(+last patch) kernel, produces panics when a process touches cpufreq(4) context. We are definitely talking about Jeff's ULE3 last patch right now and not general. No other circumstance produce panic in my environment (ULE-3 unpatched included). -- Best regards, Chris mailto:dionch@freemail.gr From owner-freebsd-current@FreeBSD.ORG Sun Jul 22 21:27: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 70AAB16A41B for ; Sun, 22 Jul 2007 21:27:50 +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 4536E13C46A for ; Sun, 22 Jul 2007 21:27:50 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from proton.local (r74-193-81-203.pfvlcmta01.grtntx.tl.dh.suddenlink.net [74.193.81.203]) (authenticated bits=0) by ns.trinitel.com (8.14.1/8.14.1) with ESMTP id l6MLRlQ2007932; Sun, 22 Jul 2007 16:27:48 -0500 (CDT) (envelope-from anderson@freebsd.org) Message-ID: <46A3CBCE.3000300@freebsd.org> Date: Sun, 22 Jul 2007 16:27:42 -0500 From: Eric Anderson User-Agent: Thunderbird 2.0.0.5 (Macintosh/20070716) MIME-Version: 1.0 To: freebsd-current@freebsd.org, gurney_j@resnet.uoregon.edu References: <469E3B7C.4020402@centtech.com> <20070722001514.GB1221@funkthat.com> In-Reply-To: <20070722001514.GB1221@funkthat.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: 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: Sun, 22 Jul 2007 21:27:50 -0000 John-Mark Gurney wrote: > kevin kramer wrote this message on Wed, Jul 18, 2007 at 11:10 -0500: >> 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? > > running the process under ktrace would help identify what it is waiting > for... Though if it usually hangs for a minute or two in kqread, and > then continues, it's probably a DNS lookup issue... > You mean like the one he put here: http://users.centtech.com/~kramer/snapshot/top-trace.txt :) A quick snippet: 84667 top 0.006110 RET sendto 56/0x38 84667 top 0.006128 CALL kevent(0x6,0x800c11910,0x1,0x7fffffffdad0,0x1,0x7fffffffdb10) 84667 top 5.008057 GIO fd 6 wrote 32 bytes 0x0000 0500 0000 0000 0000 ffff 0100 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 |................................| 84667 top 5.008073 GIO fd 6 read 0 bytes "" 84667 top 5.008078 RET kevent 0 84667 top 5.008086 CALL gettimeofday(0x7fffffffdb20,0) 84667 top 5.008091 RET gettimeofday 0 84667 top 5.008096 CALL sendto(0x5,0x800c11ac4,0x38,0,0x800c11808,0x10) 84667 top 5.008139 GIO fd 5 wrote 56 bytes 0x0000 4696 2a64 0000 0000 0000 0002 0001 86a0 0000 0002 0000 0003 0000 0000 0000 0000 0000 0000 0000 0000 |F.*d....................................| 0x0028 0001 86a7 0000 0002 0000 0006 0000 0000 |................| 84667 top 5.008155 RET sendto 56/0x38 84667 top 5.008163 CALL kevent(0x6,0x800c11910,0,0x7fffffffdad0,0x1,0x7fffffffdb10) 84667 top 15.007883 GIO fd 6 wrote 0 bytes "" Eric From owner-freebsd-current@FreeBSD.ORG Sun Jul 22 21:36:21 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 1C66016A417 for ; Sun, 22 Jul 2007 21:36:21 +0000 (UTC) (envelope-from dmw@unete.cl) Received: from mail09.ifxnetworks.com (mail09.ifxnetworks.com [190.61.128.19]) by mx1.freebsd.org (Postfix) with ESMTP id A8D2413C457 for ; Sun, 22 Jul 2007 21:36:20 +0000 (UTC) (envelope-from dmw@unete.cl) Received: (qmail 4082 invoked from network); 22 Jul 2007 21:36:19 -0000 X-Spam-DCC: CTc-dcc1: mail09.ifxnetworks.com 1030; Body=1 Fuz1=1 Fuz2=1 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on mail09.ifxnetworks.com X-Spam-Level: X-Spam-Status: No, score=0.1 required=7.0 tests=RDNS_NONE autolearn=disabled version=3.2.1 Received: from unknown (HELO quake) (dmw@unete.cl@[200.73.82.54]) (envelope-sender ) by mail09.ifxnetworks.com (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 22 Jul 2007 21:36:18 -0000 From: Daniel Molina Wegener Organization: DMW To: Alexander Leidinger Date: Sun, 22 Jul 2007 17:35:41 -0400 User-Agent: KMail/1.9.6 References: <200707212023.03993.dmw@unete.cl> <200707220216.02634.dmw@unete.cl> <20070722120133.3b09804b@deskjail> In-Reply-To: <20070722120133.3b09804b@deskjail> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200707221735.41905.dmw@unete.cl> Cc: stgib@list.ru, FreeBSD -CURRENT Subject: Re: Every time I get the sources I can't compile... 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: Sun, 22 Jul 2007 21:36:21 -0000 On Sunday 22 July 2007 06:01:33 Alexander Leidinger wrote: > Quoting Daniel Molina Wegener (Sun, 22 Jul 2007 02:16:02 -0400): > > I've removed the streams(4) support from the kernel and > > worked fine. Seems to have some broken dependencies. > > If you include the actual error messages into your mails, it > would help tracking the problem down or maybe telling you > what is wrong... Ok, this is the error when I include streams(4) support into the kernel configuration -- seems to have some broken dependencies. ----------8<--------------------8<--------------------8<---------- linking kernel.debug streams.o(.text+0x3c3): In function `svr4_soo_close': /usr/src/sys/dev/streams/streams.c:353: undefined reference to `svr4_delete_socket' *** Error code 1 Stop in /usr/obj/usr/src/sys/UNREAL. *** Error code 1 Stop in /usr/src. *** Error code 1 ----------8<--------------------8<--------------------8<---------- Sorry... changing from -CURRENT to -STABLE many times per day makes me forget some things... > > Bye, > Alexander. Regards, -- .O. | Daniel Molina Wegener | C/C++ Developer ..O | dmw [at] unete [dot] cl | FOSS Coding Adict OOO | BSD & Linux User | Standards Rocks! From owner-freebsd-current@FreeBSD.ORG Sun Jul 22 21:38:54 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 C1CAB16A420; Sun, 22 Jul 2007 21:38:54 +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 A8F6513C4A6; Sun, 22 Jul 2007 21:38:50 +0000 (UTC) (envelope-from vova@sw.ru) Received: from vova by vbook.fbsd.ru with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ICj82-0000fZ-Le; Mon, 23 Jul 2007 01:38:14 +0400 From: Vladimir Grebenschikov To: Mark Hobden In-Reply-To: References: <1184929509.1415.10.camel@localhost> <1184946870.1356.2.camel@localhost> <1185011732.1420.4.camel@localhost> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable Organization: SWsoft Date: Mon, 23 Jul 2007 01:38:14 +0400 Message-Id: <1185140294.1540.11.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: Sun, 22 Jul 2007 21:38:54 -0000 =F7 =D7=D3, 22/07/2007 =D7 20:11 +0100, Mark Hobden =D0=C9=DB=C5=D4: > Thanks for all the info. >=20 > I am having trouble reproducing a panic like this here or finding out > how it gets down a path like this. I am wondering if this only occurs > on EHCI devices. Hopefully later in the week I will be able to borrow > some equipment from work to test with here. But do you have a > different > keyboard that you could try out booting on the UHCI controller? If > that > works OK it should show me where to look. I can try to connect same keyboard through USB1 hub, it should be enough to attach it to UHCI instead of EHCI ? =20 > I'm afraid I don't know about setting dump devices before booting as > in the past I have always triggered them by attaching hardware after > the system is booted. <:-| >=20 > The other problem for you would be that because all the usb modules > are loaded as modules you need to load them individually into kgdb > with their start address as described in the link below: >=20 > http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug-kld.h= tml >=20 > Which wouldn't be fun as each time you want to load kgdb you have > to do this for usb, uhid and ukbd. I find it easier to just compile them > into the kernel. Ok, may compile them into kernel, but I still have little trouble with creating kernel dump while boot - before execution of dumpdev. Will try to find some comconsole cable or firewire cable. to do kgdb from remote machine. > Kind Regards, > Mark --=20 Vladimir B. Grebenschikov vova@fbsd.ru From owner-freebsd-current@FreeBSD.ORG Sun Jul 22 21:44: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 8C37916A417 for ; Sun, 22 Jul 2007 21:44:43 +0000 (UTC) (envelope-from dmw@unete.cl) Received: from mail08.ifxnetworks.com (mail08.ifxnetworks.com [190.61.128.18]) by mx1.freebsd.org (Postfix) with ESMTP id 1C44B13C45A for ; Sun, 22 Jul 2007 21:44:42 +0000 (UTC) (envelope-from dmw@unete.cl) Received: (qmail 433 invoked from network); 22 Jul 2007 21:44:41 -0000 X-Spam-DCC: : mail08.ifxnetworks.com 102; Body=1 Fuz1=1 Fuz2=1 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on mail08.ifxnetworks.com X-Spam-Level: X-Spam-Status: No, score=0.1 required=7.0 tests=RDNS_NONE autolearn=disabled version=3.2.1 Received: from unknown (HELO quake) (dmw@unete.cl@[200.73.82.54]) (envelope-sender ) by mail08.ifxnetworks.com (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 22 Jul 2007 21:44:40 -0000 From: Daniel Molina Wegener Organization: DMW To: "FreeBSD -CURRENT" Date: Sun, 22 Jul 2007 17:44:04 -0400 User-Agent: KMail/1.9.6 MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_k+8oGQoNs9nDJvl" Message-Id: <200707221744.04207.dmw@unete.cl> Subject: [patch] added kevent vnode events 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: Sun, 22 Jul 2007 21:44:43 -0000 --Boundary-00=_k+8oGQoNs9nDJvl Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hello, I've added NOTE_OPEN, NOTE_CLOSE and NOTE_READ events into =20 the -CURRENT kevent code. The patch is attached. =C2=BFCan someone take a look and verify if the patch can be included in the =2DCURRENT code? Regards. =2D-=20 .O. | Daniel Molina Wegener | C/C++ Developer ..O | dmw [at] unete [dot] cl | FOSS Coding Adict OOO | BSD & Linux User | Standards Rocks! --Boundary-00=_k+8oGQoNs9nDJvl Content-Type: text/x-diff; charset="utf-8"; name="kevent-new-notes-man.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="kevent-new-notes-man.patch" Index: kqueue.2 =================================================================== RCS file: /home/ncvs/src/lib/libc/sys/kqueue.2,v retrieving revision 1.45 diff -u -r1.45 kqueue.2 --- kqueue.2 20 Nov 2006 22:20:04 -0000 1.45 +++ kqueue.2 22 Jul 2007 21:19:19 -0000 @@ -335,6 +335,12 @@ .Fn unlink system call was called on the file referenced by the descriptor. +.It NOTE_OPEN +An open ocurred on the file referenced by the descriptor. Kernel threads are hiddend and system process too for any user diferent to root. +.It NOTE_CLOSE +A close ocurred on the file referenced by the descriptor. Kernel threads are hiddend and system process too for any user diferent to root. +.It NOTE_READ +A read ocurred on the file referenced by the descriptor. Kernel threads are hiddend and system process too for any user diferent to root. .It NOTE_WRITE A write occurred on the file referenced by the descriptor. .It NOTE_EXTEND --Boundary-00=_k+8oGQoNs9nDJvl Content-Type: text/x-diff; charset="utf-8"; name="kevent-new-notes.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="kevent-new-notes.patch" ? .cscope.db ? .cscope.db.in ? .cscope.db.po Index: kern/vfs_subr.c =================================================================== RCS file: /home/ncvs/src/sys/kern/vfs_subr.c,v retrieving revision 1.705 diff -u -r1.705 vfs_subr.c --- kern/vfs_subr.c 12 Jun 2007 00:11:59 -0000 1.705 +++ kern/vfs_subr.c 22 Jul 2007 21:06:23 -0000 @@ -3637,6 +3637,46 @@ } void +vop_open_post(void *ap, int rc) +{ + struct vop_open_args *a = ap; + if (!rc) { + if ((a->a_td->td_proc->p_flag & P_KTHREAD) == 0) { + if (a->a_cred->cr_ruid == 0 + && a->a_cred->cr_uid == 0) { + VFS_KNOTE_LOCKED(a->a_vp, NOTE_OPEN); + } else { + if ((a->a_td->td_proc->p_flag + & P_KTHREAD + & P_SYSTEM) == 0) { + VFS_KNOTE_LOCKED(a->a_vp, NOTE_OPEN); + } + } + } + } +} + +void +vop_close_post(void *ap, int rc) +{ + struct vop_close_args *a = ap; + if (!rc) { + if ((a->a_td->td_proc->p_flag & P_KTHREAD) == 0) { + if (a->a_cred->cr_ruid == 0 + && a->a_cred->cr_uid == 0) { + VFS_KNOTE_LOCKED(a->a_vp, NOTE_CLOSE); + } else { + if ((a->a_td->td_proc->p_flag + & P_KTHREAD + & P_SYSTEM) == 0) { + VFS_KNOTE_LOCKED(a->a_vp, NOTE_CLOSE); + } + } + } + } +} + +void vop_remove_post(void *ap, int rc) { struct vop_remove_args *a = ap; Index: kern/vnode_if.src =================================================================== RCS file: /home/ncvs/src/sys/kern/vnode_if.src,v retrieving revision 1.87 diff -u -r1.87 vnode_if.src --- kern/vnode_if.src 31 May 2007 11:51:52 -0000 1.87 +++ kern/vnode_if.src 22 Jul 2007 21:06:24 -0000 @@ -124,6 +124,7 @@ %% open vp L L L +%! open post vop_open_post vop_open { IN struct vnode *vp; @@ -135,6 +136,7 @@ %% close vp E E E +%! close post vop_close_post vop_close { IN struct vnode *vp; @@ -176,6 +178,8 @@ %% read vp L L L +%! read pre VOP_READ_PRE +%! read post VOP_READ_POST vop_read { IN struct vnode *vp; Index: sys/event.h =================================================================== RCS file: /home/ncvs/src/sys/sys/event.h,v retrieving revision 1.37 diff -u -r1.37 event.h --- sys/event.h 24 Sep 2006 04:47:47 -0000 1.37 +++ sys/event.h 22 Jul 2007 21:06:31 -0000 @@ -94,6 +94,9 @@ #define NOTE_LINK 0x0010 /* link count changed */ #define NOTE_RENAME 0x0020 /* vnode was renamed */ #define NOTE_REVOKE 0x0040 /* vnode access was revoked */ +#define NOTE_OPEN 0x0080 /* the vnode was opened */ +#define NOTE_CLOSE 0x0100 /* the vnode was closed */ +#define NOTE_READ 0x0200 /* the vnode was readed */ /* * data/hint flags for EVFILT_PROC, shared with userspace Index: sys/vnode.h =================================================================== RCS file: /home/ncvs/src/sys/sys/vnode.h,v retrieving revision 1.326 diff -u -r1.326 vnode.h --- sys/vnode.h 31 May 2007 11:51:52 -0000 1.326 +++ sys/vnode.h 22 Jul 2007 21:06:31 -0000 @@ -49,6 +49,7 @@ #include #include #include +#include /* * The vnode is the focus of all file activity in UNIX. There is a @@ -672,6 +673,8 @@ void vop_lookup_pre(void *a); void vop_mkdir_post(void *a, int rc); void vop_mknod_post(void *a, int rc); +void vop_open_post(void *a, int rc); +void vop_close_post(void *a, int rc); void vop_remove_post(void *a, int rc); void vop_rename_post(void *a, int rc); void vop_rename_pre(void *a); @@ -703,6 +706,39 @@ | (noffset > osize ? NOTE_EXTEND : 0)); \ } +#define VOP_READ_PRE(ap) \ + struct vattr va; \ + struct thread *td; \ + int error, resid, osize, ooffset, noffset; \ + \ + osize = ooffset = noffset = 0; \ + if (!VN_KNLIST_EMPTY((ap)->a_vp)) { \ + error = VOP_GETATTR((ap)->a_vp, &va, (ap)->a_cred, \ + curthread); \ + if (error) \ + return (error); \ + } + +#define VOP_READ_POST(ap, ret) \ + resid = (ap)->a_uio->uio_resid; \ + td = (ap)->a_uio->uio_td; \ + if (resid == 0 && !VN_KNLIST_EMPTY((ap)->a_vp)) { \ + if ((td->td_proc->p_flag & P_KTHREAD) \ + == 0) { \ + if ((ap)->a_cred->cr_ruid == 0 \ + && (ap)->a_cred->cr_uid == 0) { \ + VFS_KNOTE_LOCKED(a->a_vp, NOTE_READ); \ + } else { \ + if ((td->td_proc->p_flag & P_SYSTEM) \ + == 0) { \ + VFS_KNOTE_LOCKED(a->a_vp, \ + NOTE_READ); \ + } \ + } \ + \ + } \ + } + #define VOP_LOCK(vp, flags, td) VOP_LOCK1(vp, flags, td, __FILE__, __LINE__) --Boundary-00=_k+8oGQoNs9nDJvl-- From owner-freebsd-current@FreeBSD.ORG Sun Jul 22 23:48: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 4A0B716A419 for ; Sun, 22 Jul 2007 23:48:16 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outP.internet-mail-service.net (outP.internet-mail-service.net [216.240.47.239]) by mx1.freebsd.org (Postfix) with ESMTP id 30A0513C45E for ; Sun, 22 Jul 2007 23:48:16 +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; Sun, 22 Jul 2007 16:48:15 -0700 Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id 50686125AE3 for ; Sun, 22 Jul 2007 16:48:15 -0700 (PDT) Message-ID: <46A3ECE0.5010304@elischer.org> Date: Sun, 22 Jul 2007 16:48:48 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: readonly source broken? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Jul 2007 23:48:16 -0000 with a readonly /usr/src & /usr/obj (mounted via NFS from the machine where "make buildworld" was run, make installworld has the following error. this seems wrong to me.. ===> gnu/usr.bin/cvs/cvs (install) install -s -o root -g wheel -m 555 cvs /usr/bin install -o root -g wheel -m 444 cvs.1.gz /usr/share/man/man1 install -o root -g wheel -m 444 cvs.5.gz /usr/share/man/man5 ===> gnu/usr.bin/cvs/contrib (install) sed -e 's,@CSH@,/bin/csh,' -e 's,@PERL@,/usr/bin/perl,' /usr/src/gnu/usr.bin/cvs/contrib/../../../../contrib/cvs/contrib/Makefile.in > Makefile cannot create Makefile: Read-only file system *** Error code 2 Stop in /usr/src/gnu/usr.bin/cvs/contrib. *** Error code 1 Stop in /usr/src/gnu/usr.bin/cvs. *** Error code 1 Stop in /usr/src/gnu/usr.bin. *** Error code 1 From owner-freebsd-current@FreeBSD.ORG Sun Jul 22 23:54:14 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 C611416A41A for ; Sun, 22 Jul 2007 23:54:14 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outQ.internet-mail-service.net (outQ.internet-mail-service.net [216.240.47.240]) by mx1.freebsd.org (Postfix) with ESMTP id AB27713C442 for ; Sun, 22 Jul 2007 23:54:14 +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; Sun, 22 Jul 2007 16:54:13 -0700 Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id 7E8EA125A27 for ; Sun, 22 Jul 2007 16:54:13 -0700 (PDT) Message-ID: <46A3EE46.4070908@elischer.org> Date: Sun, 22 Jul 2007 16:54:46 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: FreeBSD Current References: <46A3ECE0.5010304@elischer.org> In-Reply-To: <46A3ECE0.5010304@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: readonly source broken? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Jul 2007 23:54:14 -0000 Julian Elischer wrote: > > with a readonly /usr/src & /usr/obj (mounted via NFS from the machine > where "make buildworld" was run, > make installworld has the following error. > this seems wrong to me.. well it's actually the usr/obj that needs to be read-write, but I am not sure it should be for teh action of "make installworld" as that could be done (as I do) many times remotely to install other machines. > > > ===> gnu/usr.bin/cvs/cvs (install) > install -s -o root -g wheel -m 555 cvs /usr/bin > install -o root -g wheel -m 444 cvs.1.gz /usr/share/man/man1 > install -o root -g wheel -m 444 cvs.5.gz /usr/share/man/man5 > ===> gnu/usr.bin/cvs/contrib (install) > sed -e 's,@CSH@,/bin/csh,' -e 's,@PERL@,/usr/bin/perl,' > /usr/src/gnu/usr.bin/cvs/contrib/../../../../contrib/cvs/contrib/Makefile.in > > Makefile > cannot create Makefile: Read-only file system > *** Error code 2 > > Stop in /usr/src/gnu/usr.bin/cvs/contrib. > *** Error code 1 > > Stop in /usr/src/gnu/usr.bin/cvs. > *** Error code 1 > > Stop in /usr/src/gnu/usr.bin. > *** Error code 1 > _______________________________________________ > 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 23 01:10:59 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 8CFC516A418 for ; Mon, 23 Jul 2007 01:10:59 +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 42D6113C45B for ; Mon, 23 Jul 2007 01:10:59 +0000 (UTC) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (yr10nqiu0zpf8z5t@localhost.funkthat.com [127.0.0.1]) by hydrogen.funkthat.com (8.13.6/8.13.3) with ESMTP id l6N1Awlf002856; Sun, 22 Jul 2007 18:10:58 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.13.6/8.13.3/Submit) id l6N1AwXA002855; Sun, 22 Jul 2007 18:10:58 -0700 (PDT) (envelope-from jmg) Date: Sun, 22 Jul 2007 18:10:58 -0700 From: John-Mark Gurney To: Eric Anderson Message-ID: <20070723011058.GB99491@funkthat.com> Mail-Followup-To: Eric Anderson , freebsd-current@freebsd.org References: <469E3B7C.4020402@centtech.com> <20070722001514.GB1221@funkthat.com> <46A3CBCE.3000300@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46A3CBCE.3000300@freebsd.org> 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: processes stuck in kqread X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: John-Mark Gurney List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2007 01:10:59 -0000 Eric Anderson wrote this message on Sun, Jul 22, 2007 at 16:27 -0500: > John-Mark Gurney wrote: > >kevin kramer wrote this message on Wed, Jul 18, 2007 at 11:10 -0500: > >>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? > > > >running the process under ktrace would help identify what it is waiting > >for... Though if it usually hangs for a minute or two in kqread, and > >then continues, it's probably a DNS lookup issue... > > > > > You mean like the one he put here: > > http://users.centtech.com/~kramer/snapshot/top-trace.txt /me needs to read closer. Thought it might be a yp issue: 84667 top 0.005085 CALL open(0x7fffffffdd00,O_RDONLY,0x1e) 84667 top 0.005091 NAMI "/var/yp/binding/centtech.com.2" 84667 top 0.005105 RET open -1 errno 2 No such file or directory [...] 84667 top 0.005461 CALL socket(PF_INET,SOCK_DGRAM,IPPROTO_UDP) 84667 top 0.005468 RET socket 5 [...] 84667 top 0.005533 CALL bind(0x5,0x7fffffffda10,0x10) 84667 top 0.005542 RET bind 0 [...] 84667 top 0.006028 CALL sendto(0x5,0x800c11ac4,0x38,0,0x800c11808,0x10) > 84667 top 0.006110 RET sendto 56/0x38 > 84667 top 0.006128 CALL > kevent(0x6,0x800c11910,0x1,0x7fffffffdad0,0x1,0x7fffffffdb10) > 84667 top 5.008057 GIO fd 6 wrote 32 bytes > 0x0000 0500 0000 0000 0000 ffff 0100 0000 0000 0000 0000 0000 > 0000 0000 0000 0000 0000 > |................................| > > 84667 top 5.008073 GIO fd 6 read 0 bytes > "" > 84667 top 5.008078 RET kevent 0 > 84667 top 5.008086 CALL gettimeofday(0x7fffffffdb20,0) > 84667 top 5.008091 RET gettimeofday 0 > 84667 top 5.008096 CALL > sendto(0x5,0x800c11ac4,0x38,0,0x800c11808,0x10) > 84667 top 5.008139 GIO fd 5 wrote 56 bytes > 0x0000 4696 2a64 0000 0000 0000 0002 0001 86a0 0000 0002 0000 > 0003 0000 0000 0000 0000 0000 0000 0000 0000 > |F.*d....................................| > 0x0028 0001 86a7 0000 0002 0000 0006 0000 0000 > |................| > > 84667 top 5.008155 RET sendto 56/0x38 > 84667 top 5.008163 CALL > kevent(0x6,0x800c11910,0,0x7fffffffdad0,0x1,0x7fffffffdb10) > 84667 top 15.007883 GIO fd 6 wrote 0 bytes > "" Looks like it's trying to contact the yp server and isn't getting a response... Check your user/host name lookup... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-current@FreeBSD.ORG Mon Jul 23 03:11: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 844F716A418; Mon, 23 Jul 2007 03:11:25 +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 1770413C467; Mon, 23 Jul 2007 03:11:23 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: by heff.fud.org.nz (Postfix, from userid 1001) id 70B661CC58; Mon, 23 Jul 2007 15:11:19 +1200 (NZST) Date: Mon, 23 Jul 2007 15:11:19 +1200 From: Andrew Thompson To: Doug Rabson Message-ID: <20070723031119.GA5541@heff.fud.org.nz> References: <200707211925.59698.dfr@rabson.org> <20070721210759.GA84580@heff.fud.org.nz> <20070721210837.GB84580@heff.fud.org.nz> <200707220858.12770.dfr@rabson.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="/04w6evG8XlLl3ft" Content-Disposition: inline In-Reply-To: <200707220858.12770.dfr@rabson.org> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: Attilio Rao , 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: Mon, 23 Jul 2007 03:11:25 -0000 --/04w6evG8XlLl3ft Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sun, Jul 22, 2007 at 08:58:12AM +0100, Doug Rabson wrote: > On Saturday 21 July 2007, Andrew Thompson wrote: > > 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: > > > > > > > > > >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. > > I still get a panic but I managed to get more information this time. The > original panic was a WITNESS complaint (not sure why that put it into > the debugger rather than just logging the LOR). It seems I didnt check all the places copyout was used, please test this larger patch. cheers, Andrew --/04w6evG8XlLl3ft 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 23 Jul 2007 02:53:22 -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); } @@ -1106,7 +1103,8 @@ bridge_ioctl_gifs(struct bridge_softc *s struct ifbifconf *bifc = arg; struct bridge_iflist *bif; struct ifbreq breq; - int count, len, error = 0; + char *buf, *outbuf; + int count, buflen, len, error = 0; count = 0; LIST_FOREACH(bif, &sc->sc_iflist, bif_next) @@ -1114,13 +1112,18 @@ bridge_ioctl_gifs(struct bridge_softc *s LIST_FOREACH(bif, &sc->sc_spanlist, bif_next) count++; + buflen = sizeof(breq) * count; if (bifc->ifbic_len == 0) { - bifc->ifbic_len = sizeof(breq) * count; + bifc->ifbic_len = buflen; return (0); } + BRIDGE_UNLOCK(sc); + outbuf = malloc(buflen, M_TEMP, M_WAITOK | M_ZERO); + BRIDGE_LOCK(sc); count = 0; - len = bifc->ifbic_len; + buf = outbuf; + len = min(bifc->ifbic_len, buflen); bzero(&breq, sizeof(breq)); LIST_FOREACH(bif, &sc->sc_iflist, bif_next) { if (len < sizeof(breq)) @@ -1132,10 +1135,9 @@ bridge_ioctl_gifs(struct bridge_softc *s error = bridge_ioctl_gifflags(sc, &breq); if (error) break; - error = copyout(&breq, bifc->ifbic_req + count, sizeof(breq)); - if (error) - break; + memcpy(buf, &breq, sizeof(breq)); count++; + buf += sizeof(breq); len -= sizeof(breq); } LIST_FOREACH(bif, &sc->sc_spanlist, bif_next) { @@ -1146,14 +1148,17 @@ bridge_ioctl_gifs(struct bridge_softc *s sizeof(breq.ifbr_ifsname)); breq.ifbr_ifsflags = bif->bif_flags; breq.ifbr_portno = bif->bif_ifp->if_index & 0xfff; - error = copyout(&breq, bifc->ifbic_req + count, sizeof(breq)); - if (error) - break; + memcpy(buf, &breq, sizeof(breq)); count++; + buf += sizeof(breq); len -= sizeof(breq); } + BRIDGE_UNLOCK(sc); bifc->ifbic_len = sizeof(breq) * count; + error = copyout(outbuf, bifc->ifbic_req, bifc->ifbic_len); + BRIDGE_LOCK(sc); + free(outbuf, M_TEMP); return (error); } @@ -1163,12 +1168,24 @@ bridge_ioctl_rts(struct bridge_softc *sc struct ifbaconf *bac = arg; struct bridge_rtnode *brt; struct ifbareq bareq; - int count = 0, error = 0, len; + char *buf, *outbuf; + int count, error = 0, len, buflen; if (bac->ifbac_len == 0) return (0); - len = bac->ifbac_len; + count = 0; + LIST_FOREACH(brt, &sc->sc_rtlist, brt_list) + count++; + buflen = sizeof(bareq) * count; + + BRIDGE_UNLOCK(sc); + outbuf = malloc(buflen, M_TEMP, M_WAITOK | M_ZERO); + BRIDGE_LOCK(sc); + + count = 0; + buf = outbuf; + len = min(bac->ifbac_len, buflen); bzero(&bareq, sizeof(bareq)); LIST_FOREACH(brt, &sc->sc_rtlist, brt_list) { if (len < sizeof(bareq)) @@ -1184,14 +1201,17 @@ bridge_ioctl_rts(struct bridge_softc *sc bareq.ifba_expire = 0; bareq.ifba_flags = brt->brt_flags; - error = copyout(&bareq, bac->ifbac_req + count, sizeof(bareq)); - if (error) - goto out; + memcpy(buf, &bareq, sizeof(bareq)); count++; + buf += sizeof(bareq); len -= sizeof(bareq); } out: + BRIDGE_UNLOCK(sc); bac->ifbac_len = sizeof(bareq) * count; + error = copyout(outbuf, bac->ifbac_req, bac->ifbac_len); + BRIDGE_LOCK(sc); + free(outbuf, M_TEMP); return (error); } @@ -1453,7 +1473,8 @@ bridge_ioctl_gifsstp(struct bridge_softc struct bridge_iflist *bif; struct bstp_port *bp; struct ifbpstpreq bpreq; - int count, len, error = 0; + char *buf, *outbuf; + int count, buflen, len, error = 0; count = 0; LIST_FOREACH(bif, &sc->sc_iflist, bif_next) { @@ -1461,13 +1482,19 @@ bridge_ioctl_gifsstp(struct bridge_softc count++; } + buflen = sizeof(bpreq) * count; if (bifstp->ifbpstp_len == 0) { - bifstp->ifbpstp_len = sizeof(bpreq) * count; + bifstp->ifbpstp_len = buflen; return (0); } + BRIDGE_UNLOCK(sc); + outbuf = malloc(buflen, M_TEMP, M_WAITOK | M_ZERO); + BRIDGE_LOCK(sc); + count = 0; - len = bifstp->ifbpstp_len; + buf = outbuf; + len = min(bifstp->ifbpstp_len, buflen); bzero(&bpreq, sizeof(bpreq)); LIST_FOREACH(bif, &sc->sc_iflist, bif_next) { if (len < sizeof(bpreq)) @@ -1484,16 +1511,17 @@ bridge_ioctl_gifsstp(struct bridge_softc bpreq.ifbp_design_bridge = bp->bp_desg_pv.pv_dbridge_id; bpreq.ifbp_design_root = bp->bp_desg_pv.pv_root_id; - error = copyout(&bpreq, bifstp->ifbpstp_req + count, - sizeof(bpreq)); - if (error != 0) - break; - + memcpy(buf, &bpreq, sizeof(bpreq)); count++; + buf += sizeof(bpreq); len -= sizeof(bpreq); } + BRIDGE_UNLOCK(sc); bifstp->ifbpstp_len = sizeof(bpreq) * count; + error = copyout(outbuf, bifstp->ifbpstp_req, bifstp->ifbpstp_len); + BRIDGE_LOCK(sc); + free(outbuf, M_TEMP); 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); \ --/04w6evG8XlLl3ft-- From owner-freebsd-current@FreeBSD.ORG Mon Jul 23 07:43: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 D788416A417 for ; Mon, 23 Jul 2007 07:43:23 +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 3EF8513C4B0 for ; Mon, 23 Jul 2007 07:43:23 +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 l6N7h9bK001135 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Jul 2007 11:43:10 +0400 (MSD) (envelope-from oleg@lath.rinet.ru) Received: (from oleg@localhost) by lath.rinet.ru (8.14.1/8.14.1/Submit) id l6LIjKlu016763; Sat, 21 Jul 2007 22:45:20 +0400 (MSD) (envelope-from oleg) Date: Sat, 21 Jul 2007 22:45:20 +0400 From: Oleg Bulyzhin To: Jeff Roberson Message-ID: <20070721184520.GA16647@lath.rinet.ru> References: <20070717182819.L92541@10.0.0.1> <20070720091955.GA18593@lath.rinet.ru> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="17pEHd4RhPHOinZp" Content-Disposition: inline In-Reply-To: <20070720091955.GA18593@lath.rinet.ru> 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: Mon, 23 Jul 2007 07:43:23 -0000 --17pEHd4RhPHOinZp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jul 20, 2007 at 01:19:55PM +0400, Oleg Bulyzhin wrote: >=20 > Hello. >=20 > Issue with sched_ule.c rev. 1.200: >=20 > very high load average while my workstation (dual core athlon running > smp i386 kernel) is idle: >=20 > last pid: 30188; load averages: 128.02, 127.75, 127.26 up 1+19:15:58 13= :14:58 > 130 processes: 1 running, 129 sleeping > CPU states: 0.2% user, 0.0% nice, 0.7% system, 0.0% interrupt, 99.1% = idle >=20 > It seems it's slowly increasing (~ 124 -> 128 in 3 hours). >=20 > 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 > --=20 > Oleg. >=20 > =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 >=20 sched_ule.c rev. 1.202 has the same problem: last pid: 16685; load averages: 95.00, 94.85, 94.43 up 1+07:24:38 22:38:= 31 53 processes: 1 running, 52 sleeping CPU states: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% id= le Mem: 84M Active, 664M Inact, 188M Wired, 80K Cache, 112M Buf, 1066M Free Swap: 2048M Total, 2048M Free --=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 --17pEHd4RhPHOinZp Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGolQ/ryLc73jOEF8RAnoaAJ0fS0UDB1fXRtXWVQgZjdRmk6/YlgCfZXV/ T3Hp39Gs5jdmEZpqUDjTg7A= =vHFu -----END PGP SIGNATURE----- --17pEHd4RhPHOinZp-- From owner-freebsd-current@FreeBSD.ORG Mon Jul 23 08:15: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 106AC16A418; Mon, 23 Jul 2007 08:15:19 +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 B7DD913C48D; Mon, 23 Jul 2007 08:15:15 +0000 (UTC) (envelope-from vova@sw.ru) Received: from vova by vbook.fbsd.ru with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ICt4O-0000hA-4t; Mon, 23 Jul 2007 12:15:08 +0400 From: Vladimir Grebenschikov To: Mark Hobden In-Reply-To: <1185140294.1540.11.camel@localhost> References: <1184929509.1415.10.camel@localhost> <1184946870.1356.2.camel@localhost> <1185011732.1420.4.camel@localhost> <1185140294.1540.11.camel@localhost> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable Organization: SWsoft Date: Mon, 23 Jul 2007 12:15:07 +0400 Message-Id: <1185178507.2125.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 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2007 08:15:19 -0000 =F7 =D0=CE, 23/07/2007 =D7 01:38 +0400, Vladimir Grebenschikov =D0=C9=DB=C5= =D4: =20 > > I am having trouble reproducing a panic like this here or finding out > > how it gets down a path like this. I am wondering if this only occurs > > on EHCI devices. Hopefully later in the week I will be able to borrow > > some equipment from work to test with here. But do you have a > > different > > keyboard that you could try out booting on the UHCI controller? If > > that > > works OK it should show me where to look. >=20 > I can try to connect same keyboard through USB1 hub, it should be enough > to attach it to UHCI instead of EHCI ? =20 I've tried - same panic. --=20 Vladimir B. Grebenschikov SWsoft Inc. vova@swsoft.com From owner-freebsd-current@FreeBSD.ORG Mon Jul 23 08:36: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 9E89716A418; Mon, 23 Jul 2007 08:36:13 +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 166BC13C465; Mon, 23 Jul 2007 08:36:12 +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 l6N8JorQ001809 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Jul 2007 12:19:50 +0400 (MSD) (envelope-from oleg@lath.rinet.ru) Received: (from oleg@localhost) by lath.rinet.ru (8.14.1/8.14.1/Submit) id l6N8JnCi001808; Mon, 23 Jul 2007 12:19:49 +0400 (MSD) (envelope-from oleg) Date: Mon, 23 Jul 2007 12:19:49 +0400 From: Oleg Bulyzhin To: Attilio Rao Message-ID: <20070723081949.GA1528@lath.rinet.ru> References: <46A2B49F.4030307@freebsd.org> <20070722155356.49797993@roxette> <46A36A49.2090303@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5mCyUwZo2JvN/JJP" Content-Disposition: inline In-Reply-To: <46A36A49.2090303@FreeBSD.org> User-Agent: Mutt/1.5.15 (2007-04-06) Cc: Patrick Lamaiziere , freebsd-current@freebsd.org Subject: Re: LOR's, and a panic (ipf NAT related?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Jul 2007 08:36:13 -0000 --5mCyUwZo2JvN/JJP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jul 22, 2007 at 04:31:37PM +0200, Attilio Rao wrote: > Patrick Lamaiziere wrote: > > Le Sat, 21 Jul 2007 20:36:31 -0500, > > Eric Anderson a ?crit : > >> Today, on a -CURRENT from a few days ago (running ULE 3.0), I got a > >> panic: > >> > >> panic: Trying sleep, but thread marked as sleeping prohibited > >> cpuid =3D 0 > >> >=20 > This one should have been fixed in last ULE3.0 revision, could you pleas= e=20 > update your src/sys and see if it goes away? >=20 > About the other LORs, you should see in the bz's page if they are alredy= =20 > listes, since it seems I remind at least one of them: > http://sources.zabbadoz.net/freebsd/lor.html >=20 >=20 > Thanks, > Attilio > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.or= g" This panic is not ULE related. It came from wrong sx lock usage inside ipfi= lter. I tried to use recently imported (into -current) ipfilter 4.1.23 and found = it is almost unusable (at least ipnat): it's very unstable (several hangs or deadlocks per day), it does leak memory. I've spent some time on fixing ipfilter's bugs, then sent report to ipfilte= r's author. Unfortunately, i failed to get any feedback. You can get patch here: http://people.freebsd.org/~oleg/patches/ipfilter.r70.diff I would not swear it's 100% correct, but it should make ipfilter much more stable. It does following: - sx locks converted to rwlocks. (this should be done, cause pfil(4) uses rwlocks, which are not sleepable). - fixed memory leak inside nat_getnext() - fixed several improper checks of array's boundary. - added some missing mutex_destroy() calls - ipfilter's attaching/detaching procedure changed a bit in order to fix so= me LORs. --=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 --5mCyUwZo2JvN/JJP Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGpGSkryLc73jOEF8RAqNqAJ9TSnEhRQOzipuk947mfxRY01xiuACfVOZ5 DLsLRoxvKu3v3qaKLolw9l8= =DMlh -----END PGP SIGNATURE----- --5mCyUwZo2JvN/JJP-- From owner-freebsd-current@FreeBSD.ORG Mon Jul 23 09:35:37 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 3B73316A418 for ; Mon, 23 Jul 2007 09:35:37 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from webmail29.mail.yandex.net (webmail29.mail.yandex.net [213.180.200.148]) by mx1.freebsd.org (Postfix) with ESMTP id B40BF13C459 for ; Mon, 23 Jul 2007 09:35:36 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from YAMAIL (webmail29) by mail.yandex.ru id S875084AbXGWJf3 for (+ 1 other); Mon, 23 Jul 2007 13:35:29 +0400 Received: from [83.149.32.58] ([83.149.32.58]) by mail.yandex.ru with HTTP; Mon, 23 Jul 2007 13:35:27 +0400 From: "Andrey V. Elsukov" To: freebsd-current@freebsd.org MIME-Version: 1.0 Message-Id: <180421185183327@webmail29.yandex.ru> Date: Mon, 23 Jul 2007 13:35:27 +0400 X-Mailer: Yamail [ http://yandex.ru ] 5.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain Cc: Pyun YongHyeon Subject: Conflict between nfe(4) and x11/nvidia-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: Mon, 23 Jul 2007 09:35:37 -0000 Hi, All. I have notebook with NVIDIA based network adapter and video. >From dmesg: nvidia0: mem 0xc2000000-0xc2ffffff,0xd0000000-0xdfffffff,0xc1000000-0xc1ffffff irq 5 at device 5.0 on pci0 nvidia0: [GIANT-LOCKED] nvidia0: [ITHREAD] ... nfe0: port 0x30b8-0x30bf mem 0xc0007000-0xc0007fff irq 5 at device 20.0 on pci0 miibus0: on nfe0 rlphy0: PHY 1 on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto nfe0: Ethernet address: 00:90:f5:4f:18:1b nfe0: [FILTER] Some time ago i've used nve(4) and nvidia-driver without problems. But nve(4) is buggy and sometimes have watchdog timeouts. After switching to nfe(4) i can't use x11/nvidia-driver. After some time of running, Xorg process takes 100% of resources and system not responds. But i can power off my system via ACPI. After reboot i have following messages in the /var/log/messages: Jul 20 16:26:51 btr-nb kernel: nfe0: watchdog timeout (missed Tx interrupts) -- recovering Jul 20 16:27:39 btr-nb last message repeated 3 times Jul 20 16:27:58 btr-nb kernel: nfe0: watchdog timeout (missed Tx interrupts) -- recovering Jul 20 16:28:08 btr-nb kernel: acpi_button0: power button pressed nfe(4) without x11/nvidia-driver and x11/nvidia-driver without nfe(4) works stable. But i want use both nfe(4) and x11/nvidia-driver... Can somebody suggest me some tricks? -- WBR, Andrey V. Elsukov From owner-freebsd-current@FreeBSD.ORG Mon Jul 23 09:45:09 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 B64DE16A418 for ; Mon, 23 Jul 2007 09:45:09 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from s200aog13.obsmtp.com (s200aog13.obsmtp.com [207.126.144.127]) by mx1.freebsd.org (Postfix) with SMTP id E24E713C478 for ; Mon, 23 Jul 2007 09:45:06 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from source ([217.206.187.80]) by eu1sys200aob013.postini.com ([207.126.147.11]) with SMTP; Mon, 23 Jul 2007 09:45:04 UTC Received: from [10.0.0.89] (bill.mintel.co.uk [10.0.0.89]) by rodney.mintel.co.uk (Postfix) with ESMTP id AF7E618141B; Mon, 23 Jul 2007 10:12:06 +0100 (BST) Message-ID: <46A47044.9070307@tomjudge.com> Date: Mon, 23 Jul 2007 10:09:24 +0100 From: Tom Judge User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Julian Elischer References: <46A3ECE0.5010304@elischer.org> In-Reply-To: <46A3ECE0.5010304@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current Subject: Re: readonly source broken? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Jul 2007 09:45:09 -0000 Julian Elischer wrote: > > with a readonly /usr/src & /usr/obj (mounted via NFS from the machine > where "make buildworld" was run, > make installworld has the following error. > this seems wrong to me.. > > > ===> gnu/usr.bin/cvs/cvs (install) > install -s -o root -g wheel -m 555 cvs /usr/bin > install -o root -g wheel -m 444 cvs.1.gz /usr/share/man/man1 > install -o root -g wheel -m 444 cvs.5.gz /usr/share/man/man5 > ===> gnu/usr.bin/cvs/contrib (install) > sed -e 's,@CSH@,/bin/csh,' -e 's,@PERL@,/usr/bin/perl,' > /usr/src/gnu/usr.bin/cvs/contrib/../../../../contrib/cvs/contrib/Makefile.in > > Makefile > cannot create Makefile: Read-only file system > *** Error code 2 > > Stop in /usr/src/gnu/usr.bin/cvs/contrib. > *** Error code 1 > > Stop in /usr/src/gnu/usr.bin/cvs. > *** Error code 1 > > Stop in /usr/src/gnu/usr.bin. > *** Error code 1 I do this type of installation quite regularly, it is usually a sign that either the /etc/make.conf is different between the build host and install host. Or that a part of the tree has been cleaned and not rebuilt. Tom From owner-freebsd-current@FreeBSD.ORG Mon Jul 23 10:09: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 6734616A41B for ; Mon, 23 Jul 2007 10:09:42 +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 30A4B13C461 for ; Mon, 23 Jul 2007 10:09:41 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by wa-out-1112.google.com with SMTP id j37so2123771waf for ; Mon, 23 Jul 2007 03:09:41 -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=IkciD8y07VP4/m6feo/i5fjSmrL7tm68q/6yMJH2EFFJz5LxprqdOwv8OHOOpTuy7xguNu/hhdPcB1SofMIXE1CcCUNNBVv+fCRVFJcyCZ3NTFlWpOICWOOz6O2koAYwqvXG6ySH3baqwLljQlnB8/c7+b34XWkBDpXjLr0wO44= 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=Pf+hZKriJ6ui2Fyp02rjlY7VuOp7Wu+z4XEOpvXD5gWEg4zlfNO9+L7e3JLWa8d08Ba1fHClyvk2mGxdWgffGICplFwS3K3jnyodQUomgMabfOh/AqRTOBN5RaYmex0mPbkwqkea09WNPo9tLmBMQCSLaOD+gw+lhA5cwsgXu9Y= Received: by 10.114.166.1 with SMTP id o1mr2829988wae.1185185380949; Mon, 23 Jul 2007 03:09:40 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTPS id n38sm9601619wag.2007.07.23.03.09.38 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 23 Jul 2007 03:09:39 -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 l6NA9ZxM061061 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Jul 2007 19:09: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 l6NA9XnZ061060; Mon, 23 Jul 2007 19:09:33 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Mon, 23 Jul 2007 19:09:33 +0900 From: Pyun YongHyeon To: "Andrey V. Elsukov" Message-ID: <20070723100933.GM58912@cdnetworks.co.kr> References: <180421185183327@webmail29.yandex.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <180421185183327@webmail29.yandex.ru> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@freebsd.org, Pyun YongHyeon Subject: Re: Conflict between nfe(4) and x11/nvidia-driver 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: Mon, 23 Jul 2007 10:09:42 -0000 On Mon, Jul 23, 2007 at 01:35:27PM +0400, Andrey V. Elsukov wrote: > Hi, All. > > I have notebook with NVIDIA based network adapter and video. > >From dmesg: > > nvidia0: mem 0xc2000000-0xc2ffffff,0xd0000000-0xdfffffff,0xc1000000-0xc1ffffff irq 5 at device 5.0 on pci0 > nvidia0: [GIANT-LOCKED] > nvidia0: [ITHREAD] > ... > nfe0: port 0x30b8-0x30bf mem 0xc0007000-0xc0007fff irq 5 at device 20.0 on pci0 > miibus0: on nfe0 > rlphy0: PHY 1 on miibus0 > rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > nfe0: Ethernet address: 00:90:f5:4f:18:1b > nfe0: [FILTER] > > Some time ago i've used nve(4) and nvidia-driver without problems. > But nve(4) is buggy and sometimes have watchdog timeouts. > > After switching to nfe(4) i can't use x11/nvidia-driver. > After some time of running, Xorg process takes 100% of resources and > system not responds. But i can power off my system via ACPI. > After reboot i have following messages in the /var/log/messages: > > Jul 20 16:26:51 btr-nb kernel: nfe0: watchdog timeout (missed Tx interrupts) -- recovering > Jul 20 16:27:39 btr-nb last message repeated 3 times > Jul 20 16:27:58 btr-nb kernel: nfe0: watchdog timeout (missed Tx interrupts) -- recovering > Jul 20 16:28:08 btr-nb kernel: acpi_button0: power button pressed > > nfe(4) without x11/nvidia-driver and x11/nvidia-driver without nfe(4) > works stable. > But i want use both nfe(4) and x11/nvidia-driver... > Can somebody suggest me some tricks? > Show me the output of "vmstat -i". I guess nfe(4) shares interrupt with your video adapter. If this is the case use polling(4) which may fix the issue. -- Regards, Pyun YongHyeon From owner-freebsd-current@FreeBSD.ORG Mon Jul 23 10:37: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 85E1E16A417; Mon, 23 Jul 2007 10:37:02 +0000 (UTC) (envelope-from lists@petri.cc) Received: from moof.catpipe.net (moof.catpipe.net [129.142.64.64]) by mx1.freebsd.org (Postfix) with ESMTP id 3E37213C459; Mon, 23 Jul 2007 10:37:02 +0000 (UTC) (envelope-from lists@petri.cc) Received: from localhost (unknown [129.142.64.64]) by localhost.catpipe.net (Postfix) with ESMTP id 9DC057CB670; Mon, 23 Jul 2007 12:36:43 +0200 (CEST) X-Virus-Scanned: amavisd-new at catpipe.net Received: from moof.catpipe.net ([129.142.64.64]) by localhost (moof.catpipe.net [129.142.64.64]) (amavisd-new, port 10024) with ESMTP id FP6TWSlazeDu; Mon, 23 Jul 2007 12:36:43 +0200 (CEST) Received: from fever.catpipe.net (0x57351859.vgnxx8.adsl-dhcp.tele.dk [87.53.24.89]) (Authenticated sender: relayuser) by moof.catpipe.net (Postfix) with ESMTP id 0F5C57CB61C; Mon, 23 Jul 2007 12:36:41 +0200 (CEST) Message-ID: <46A484CA.8030805@petri.cc> Date: Mon, 23 Jul 2007 12:36:58 +0200 From: "Nicolai Petri (lists)" User-Agent: Thunderbird 2.0.0.0 (X11/20070527) MIME-Version: 1.0 To: Sam Leffler References: <20070619011908.GA53748@heff.fud.org.nz> <20070620042023.GA17424@nowhere> <4678B1E4.7080909@errno.com> <467ED084.4000002@petri.cc> In-Reply-To: <467ED084.4000002@petri.cc> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Craig Boston , FreeBSD Current , Andrew Thompson Subject: Re: wireless X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2007 10:37:02 -0000 Nicolai Petri (lists) wrote: > >>> In short, ipw doesn't seem to work at all for me anymore. It worked >>> okay in 6-stable with an occasional hiccup, but upon upgrading to >>> current it doesn't seem to be doing anything. >>> Sometimes "ifconfig scan" does nothing, sometimes it results in a panic. >> >> I'm not sure how well ipw got tested while the changes were in p4. >> We'll need to test again now that code has been merged to CVS. I'll try >> to look at this weekend if noone else beats me to it. >> >> Sam > > > I'm running -current from following time : Thu Jun 20 > > Best regards, > Nicolai Petri > Are there any news on this matter ? We are now 1 month closer to beta and ipw is still useless. I'm willing to test if anyone have patches but I don't have time to look at code myself. Best regards, Nicolai Petri From owner-freebsd-current@FreeBSD.ORG Mon Jul 23 10:53:26 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 DB15D16A421 for ; Mon, 23 Jul 2007 10:53:26 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.225]) by mx1.freebsd.org (Postfix) with ESMTP id 8F2B913C458 for ; Mon, 23 Jul 2007 10:53:26 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by wx-out-0506.google.com with SMTP id i29so1295889wxd for ; Mon, 23 Jul 2007 03:53: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:reply-to:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding:sender; b=gaYYt0SbvaguQ0e8nmXxJZESPylKHruIVPQB7hJOQzxIC8viqe5cMMGlFBnerjPUKcmATIQ7VlqgXpm/E9Tp2iG9PMKPxxL3urNuBdK+yIjG2Z8SO/34qGLXYQdqPSlHf/PHgxP+NVBTGW8ekdVP1Sv9WLUr5FC2vNVR/iKSdsM= 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=Qqwe5tz0iJwuYzX44DvnF0A+5K2+Mt96DmEQItGLxgYEYsh4SOFrCxCiOhxy8d2h+9Ujw3e5NVBcXbMMjMVbb8f8za1UF1u7XhceRTwR3HHXjc4MGYYkiPvNPEuybtWoQZaei+SLD0y+LqSlU6pz27fP9+BQ226u8ADgAHGt6uI= Received: by 10.78.178.5 with SMTP id a5mr731750huf.1185188004427; Mon, 23 Jul 2007 03:53:24 -0700 (PDT) Received: from ?172.31.5.25? ( [89.97.252.178]) by mx.google.com with ESMTPS id 30sm3183784hue.2007.07.23.03.53.23 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 23 Jul 2007 03:53:23 -0700 (PDT) Message-ID: <46A48870.2080202@FreeBSD.org> Date: Mon, 23 Jul 2007 12:52:32 +0200 From: Attilio Rao User-Agent: Thunderbird 1.5 (X11/20060526) MIME-Version: 1.0 To: Teufel References: <200707131834.27131.h.schmalzbauer@omnisec.de> <4697CCEB.9080707@FreeBSD.org> <200707132155.43783.h.schmalzbauer@omnisec.de> <4698E7C4.9080001@FreeBSD.org> <469B3491.2000402@kuehlbox.de> In-Reply-To: <469B3491.2000402@kuehlbox.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: Attilio Rao Cc: emulation@FreeBSD.org, current@FreeBSD.org Subject: Re: kqemu crash (page fault) with -current 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: Mon, 23 Jul 2007 10:53:26 -0000 Teufel wrote: > 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? Ok, so a fix for this (even if slightly different from what you have tested) has been committed yesterday night. Now kqemu should not care if kernel is compiled or not with KSE and can be compiled cleanly with or without KSE. As an addictional note, I can say I think SMP breakage for kqemu is due to the option SMP not passed as compilation directive since SMP offers another compile time discriminant for the ABI. In particular, if a module is compiled without SMP on a SMP kernel it will use racy synchronization primitives. This means we should force at least modules compilation to always use SMP (I'm not sure if it alredy happens honestly, I just hope so). Thanks, Attilio From owner-freebsd-current@FreeBSD.ORG Mon Jul 23 11:48:35 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 BC64C16A417 for ; Mon, 23 Jul 2007 11:48: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 9D44013C480 for ; Mon, 23 Jul 2007 11:48:22 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: by heff.fud.org.nz (Postfix, from userid 1001) id 788EC1CC58; Mon, 23 Jul 2007 23:48:21 +1200 (NZST) Date: Mon, 23 Jul 2007 23:48:21 +1200 From: Andrew Thompson To: "Nicolai Petri (lists)" Message-ID: <20070723114821.GA6575@heff.fud.org.nz> References: <20070619011908.GA53748@heff.fud.org.nz> <20070620042023.GA17424@nowhere> <4678B1E4.7080909@errno.com> <467ED084.4000002@petri.cc> <46A484CA.8030805@petri.cc> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="BOKacYhQ+x31HxR3" Content-Disposition: inline In-Reply-To: <46A484CA.8030805@petri.cc> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: FreeBSD Current , Craig Boston Subject: Re: wireless X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2007 11:48:35 -0000 --BOKacYhQ+x31HxR3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Jul 23, 2007 at 12:36:58PM +0200, Nicolai Petri (lists) wrote: > Nicolai Petri (lists) wrote: > > > >>>In short, ipw doesn't seem to work at all for me anymore. It worked > >>>okay in 6-stable with an occasional hiccup, but upon upgrading to > >>>current it doesn't seem to be doing anything. > >>>Sometimes "ifconfig scan" does nothing, sometimes it results in a panic. > >> > >>I'm not sure how well ipw got tested while the changes were in p4. > >>We'll need to test again now that code has been merged to CVS. I'll try > >>to look at this weekend if noone else beats me to it. > >> > >> Sam > > > > > >I'm running -current from following time : Thu Jun 20 > > > >Best regards, > >Nicolai Petri > > > Are there any news on this matter ? We are now 1 month closer to beta > and ipw is still useless. I'm willing to test if anyone have patches but > I don't have time to look at code myself. You can test this WIP. cheers, Andrew --BOKacYhQ+x31HxR3 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="ipw_newworld2.diff" Index: if_ipw.c =================================================================== RCS file: /home/ncvs/src/sys/dev/ipw/if_ipw.c,v retrieving revision 1.29 diff -u -p -r1.29 if_ipw.c --- if_ipw.c 5 Jul 2007 15:06:49 -0000 1.29 +++ if_ipw.c 13 Jul 2007 12:42:38 -0000 @@ -1,8 +1,7 @@ -/* $FreeBSD: src/sys/dev/ipw/if_ipw.c,v 1.29 2007/07/05 15:06:49 avatar Exp $ */ - /*- * Copyright (c) 2004-2006 * Damien Bergamini . All rights reserved. + * Copyright (c) 2006 Sam Leffler, Errno Consulting * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions @@ -78,10 +77,11 @@ __FBSDID("$FreeBSD: src/sys/dev/ipw/if_i #include #include +#define IPW_DEBUG #ifdef IPW_DEBUG #define DPRINTF(x) do { if (ipw_debug > 0) printf x; } while (0) #define DPRINTFN(n, x) do { if (ipw_debug >= (n)) printf x; } while (0) -int ipw_debug = 0; +int ipw_debug = 40; SYSCTL_INT(_debug, OID_AUTO, ipw, CTLFLAG_RW, &ipw_debug, 0, "ipw debug level"); #else #define DPRINTF(x) @@ -109,40 +109,66 @@ static void ipw_release(struct ipw_softc static int ipw_media_change(struct ifnet *); static void ipw_media_status(struct ifnet *, struct ifmediareq *); static int ipw_newstate(struct ieee80211com *, enum ieee80211_state, int); -static uint16_t ipw_read_prom_word(struct ipw_softc *, uint8_t); -static void ipw_command_intr(struct ipw_softc *, struct ipw_soft_buf *); -static void ipw_newstate_intr(struct ipw_softc *, struct ipw_soft_buf *); -static void ipw_data_intr(struct ipw_softc *, struct ipw_status *, +static void ipw_rx_cmd_intr(struct ipw_softc *, struct ipw_soft_buf *); +static void ipw_rx_newstate_intr(struct ipw_softc *, struct ipw_soft_buf *); +static void ipw_rx_data_intr(struct ipw_softc *, struct ipw_status *, struct ipw_soft_bd *, struct ipw_soft_buf *); static void ipw_rx_intr(struct ipw_softc *); static void ipw_release_sbd(struct ipw_softc *, struct ipw_soft_bd *); static void ipw_tx_intr(struct ipw_softc *); +static const char *ipw_cmdname(int); static void ipw_intr(void *); static void ipw_dma_map_addr(void *, bus_dma_segment_t *, int, int); -static int ipw_cmd(struct ipw_softc *, uint32_t, void *, uint32_t); +static int ipw_cmd(struct ipw_softc *, uint32_t, const void *, uint32_t); static int ipw_tx_start(struct ifnet *, struct mbuf *, struct ieee80211_node *); +static void ipw_start_locked(struct ifnet *); static void ipw_start(struct ifnet *); -static void ipw_watchdog(struct ifnet *); +static void ipw_watchdog(void *); static int ipw_ioctl(struct ifnet *, u_long, caddr_t); static void ipw_stop_master(struct ipw_softc *); static int ipw_reset(struct ipw_softc *); -static int ipw_load_ucode(struct ipw_softc *, const char *, int); -static int ipw_load_firmware(struct ipw_softc *, const char *, int); +static int ipw_enable(struct ipw_softc *); +static int ipw_disable(struct ipw_softc *); static int ipw_config(struct ipw_softc *); -static void ipw_init_task(void *, int); +static void ipw_restart(void *, int); +static int ipw_scan(struct ipw_softc *); +static void ipw_assoc_lost(void *, int); +static void ipw_assoc(struct ieee80211com *); +static void ipw_disassoc(struct ieee80211com *); +static int ipw_auth_and_assoc(struct ipw_softc *); +static int ipw_disassociate(struct ipw_softc *); +static void ipw_ops(void *, int); static void ipw_init(void *); +static void ipw_init_locked(struct ipw_softc *, int); +static void ipw_stop_locked(struct ipw_softc *); static void ipw_stop(void *); static int ipw_sysctl_stats(SYSCTL_HANDLER_ARGS); +static int ipw_getrfkill(struct ipw_softc *); +static void ipw_radio_on(void *, int); +static void ipw_radio_off(void *, int); static int ipw_sysctl_radio(SYSCTL_HANDLER_ARGS); +static int ipw_get_firmware(struct ipw_softc *); +static void ipw_put_firmware(struct ipw_softc *); +static int ipw_load_ucode(struct ipw_softc *, const struct ipw_fw *); +static int ipw_load_firmware(struct ipw_softc *, const struct ipw_fw *); static uint32_t ipw_read_table1(struct ipw_softc *, uint32_t); static void ipw_write_table1(struct ipw_softc *, uint32_t, uint32_t); +#if 0 static int ipw_read_table2(struct ipw_softc *, uint32_t, void *, uint32_t *); static void ipw_read_mem_1(struct ipw_softc *, bus_size_t, uint8_t *, bus_size_t); +#endif static void ipw_write_mem_1(struct ipw_softc *, bus_size_t, const uint8_t *, bus_size_t); +static uint16_t ipw_read_prom_word(struct ipw_softc *, uint8_t); +static void ipw_sysctlattach(struct ipw_softc *); +static void ipw_scan_start(struct ieee80211com *); +static void ipw_scan_end(struct ieee80211com *); +static void ipw_set_channel(struct ieee80211com *); +static void ipw_scan_curchan(struct ieee80211com *, unsigned long maxdwell); +static void ipw_scan_mindwell(struct ieee80211com *); static int ipw_probe(device_t); static int ipw_attach(device_t); @@ -172,6 +198,7 @@ static driver_t ipw_driver = { static devclass_t ipw_devclass; DRIVER_MODULE(ipw, pci, ipw_driver, ipw_devclass, 0, 0); +DRIVER_MODULE(ipw, cardbus, ipw_driver, ipw_devclass, 0, 0); static int ipw_probe(device_t dev) @@ -205,8 +232,25 @@ ipw_attach(device_t dev) mtx_init(&sc->sc_mtx, device_get_nameunit(dev), MTX_NETWORK_LOCK, MTX_DEF | MTX_RECURSE); + IPW_CMD_LOCK_INIT(sc); - TASK_INIT(&sc->sc_init_task, 0, ipw_init_task, sc); +#if __FreeBSD_version >= 700000 + sc->sc_tq = taskqueue_create("ipw_taskq", M_NOWAIT, + taskqueue_thread_enqueue, &sc->sc_tq); + taskqueue_start_threads(&sc->sc_tq, 1, PI_NET, "%s taskq", + device_get_nameunit(dev)); +#else + sc->sc_tq = taskqueue_create("ipw_taskq", M_NOWAIT, + taskqueue_thread_enqueue, &sc->sc_tq, &sc->sc_tqproc); + taskqueue_start_threads(&sc->sc_tq, 1, PI_NET, "%s taskq", + device_get_nameunit(dev)); +#endif + TASK_INIT(&sc->sc_radiontask, 0, ipw_radio_on, sc); + TASK_INIT(&sc->sc_radiofftask, 0, ipw_radio_off, sc); + TASK_INIT(&sc->sc_assoclosttask,0, ipw_assoc_lost, sc); + TASK_INIT(&sc->sc_restarttask, 0, ipw_restart, sc); + TASK_INIT(&sc->sc_opstask, 0, ipw_ops, sc); + callout_init_mtx(&sc->sc_wdtimer, &sc->sc_mtx, 0); if (pci_get_powerstate(dev) != PCI_POWERSTATE_D0) { device_printf(dev, "chip is in D%d power mode " @@ -260,7 +304,6 @@ ipw_attach(device_t dev) ifp->if_init = ipw_init; ifp->if_ioctl = ipw_ioctl; ifp->if_start = ipw_start; - ifp->if_watchdog = ipw_watchdog; IFQ_SET_MAXLEN(&ifp->if_snd, IFQ_MAXLEN); ifp->if_snd.ifq_drv_maxlen = IFQ_MAXLEN; IFQ_SET_READY(&ifp->if_snd); @@ -271,11 +314,12 @@ ipw_attach(device_t dev) ic->ic_state = IEEE80211_S_INIT; /* set device capabilities */ - ic->ic_caps = - IEEE80211_C_IBSS | /* IBSS mode supported */ - IEEE80211_C_MONITOR | /* monitor mode supported */ - IEEE80211_C_TXPMGT | /* tx power management */ - IEEE80211_C_SHPREAMBLE; /* short preamble supported */ + ic->ic_caps = IEEE80211_C_IBSS /* IBSS mode supported */ + | IEEE80211_C_MONITOR /* monitor mode supported */ + | IEEE80211_C_PMGT /* power save supported */ + | IEEE80211_C_SHPREAMBLE /* short preamble supported */ + | IEEE80211_C_WPA /* 802.11i supported */ + ; /* read MAC address from EEPROM */ val = ipw_read_prom_word(sc, IPW_EEPROM_MAC + 0); @@ -291,6 +335,7 @@ ipw_attach(device_t dev) /* set supported .11b channels (read from EEPROM) */ if ((val = ipw_read_prom_word(sc, IPW_EEPROM_CHANNEL_LIST)) == 0) val = 0x7ff; /* default to channels 1-11 */ + sc->chanmask = val; val <<= 1; for (i = 1; i < 16; i++) { if (val & (1 << i)) { @@ -300,10 +345,11 @@ ipw_attach(device_t dev) c->ic_ieee = i; } } + DPRINTF(("%s: added %d channels\n", __func__, ic->ic_nchans)); /* check support for radio transmitter switch in EEPROM */ if (!(ipw_read_prom_word(sc, IPW_EEPROM_RADIO) & 8)) - sc->flags |= IPW_FLAG_HAS_RADIO_SWITCH; + sc->flags |= IPW_FLAG_HAS_RFSWITCH; ieee80211_ifattach(ic); /* override state transition machine */ @@ -311,8 +357,14 @@ ipw_attach(device_t dev) ic->ic_newstate = ipw_newstate; ieee80211_media_init(ic, ipw_media_change, ipw_media_status); + ic->ic_scan_start = ipw_scan_start; + ic->ic_scan_end = ipw_scan_end; + ic->ic_set_channel = ipw_set_channel; + ic->ic_scan_curchan = ipw_scan_curchan; + ic->ic_scan_mindwell = ipw_scan_mindwell; + bpfattach2(ifp, DLT_IEEE802_11_RADIO, - sizeof (struct ieee80211_frame) + sizeof (sc->sc_txtap), + sizeof (struct ieee80211_frame) + sizeof (sc->sc_txtap), &sc->sc_drvbpf); sc->sc_rxtap_len = sizeof sc->sc_rxtap; @@ -323,25 +375,7 @@ ipw_attach(device_t dev) sc->sc_txtap.wt_ihdr.it_len = htole16(sc->sc_txtap_len); sc->sc_txtap.wt_ihdr.it_present = htole32(IPW_TX_RADIOTAP_PRESENT); - /* - * Add a few sysctl knobs. - */ - sc->dwelltime = 100; - - SYSCTL_ADD_PROC(device_get_sysctl_ctx(dev), - SYSCTL_CHILDREN(device_get_sysctl_tree(dev)), OID_AUTO, "radio", - CTLTYPE_INT | CTLFLAG_RD, sc, 0, ipw_sysctl_radio, "I", - "radio transmitter switch state (0=off, 1=on)"); - - SYSCTL_ADD_PROC(device_get_sysctl_ctx(dev), - SYSCTL_CHILDREN(device_get_sysctl_tree(dev)), OID_AUTO, "stats", - CTLTYPE_OPAQUE | CTLFLAG_RD, sc, 0, ipw_sysctl_stats, "S", - "statistics"); - - SYSCTL_ADD_INT(device_get_sysctl_ctx(dev), - SYSCTL_CHILDREN(device_get_sysctl_tree(dev)), OID_AUTO, "dwell", - CTLFLAG_RW, &sc->dwelltime, 0, - "channel dwell time (ms) for AP/station scanning"); + ipw_sysctlattach(sc); /* * Hook our interrupt after all initialization is complete. @@ -370,6 +404,8 @@ ipw_detach(device_t dev) struct ifnet *ifp = ic->ic_ifp; ipw_stop(sc); + callout_drain(&sc->sc_wdtimer); + ipw_put_firmware(sc); if (ifp != NULL) { bpfdetach(ifp); @@ -389,12 +425,10 @@ ipw_detach(device_t dev) if (ifp != NULL) if_free(ifp); - if (sc->sc_firmware != NULL) { - firmware_put(sc->sc_firmware, FIRMWARE_UNLOAD); - sc->sc_firmware = NULL; - } + taskqueue_free(sc->sc_tq); mtx_destroy(&sc->sc_mtx); + IPW_CMD_LOCK_DESTROY(sc); return 0; } @@ -692,6 +726,7 @@ ipw_shutdown(device_t dev) struct ipw_softc *sc = device_get_softc(dev); ipw_stop(sc); + ipw_put_firmware(sc); /* ??? XXX */ return 0; } @@ -711,18 +746,19 @@ ipw_resume(device_t dev) { struct ipw_softc *sc = device_get_softc(dev); struct ifnet *ifp = sc->sc_ic.ic_ifp; + IPW_LOCK_DECL; - mtx_lock(&sc->sc_mtx); + IPW_LOCK(sc); pci_write_config(dev, 0x41, 0, 1); if (ifp->if_flags & IFF_UP) { - ifp->if_init(ifp->if_softc); + ipw_init_locked(sc, 0); if (ifp->if_drv_flags & IFF_DRV_RUNNING) - ifp->if_start(ifp); + ipw_start_locked(ifp); } - mtx_unlock(&sc->sc_mtx); + IPW_UNLOCK(sc); return 0; } @@ -732,20 +768,30 @@ ipw_media_change(struct ifnet *ifp) { struct ipw_softc *sc = ifp->if_softc; int error; + IPW_LOCK_DECL; - mtx_lock(&sc->sc_mtx); - + IPW_LOCK(sc); error = ieee80211_media_change(ifp); - if (error != ENETRESET) { - mtx_unlock(&sc->sc_mtx); - return error; + if (error == ENETRESET) { + if ((ifp->if_flags & IFF_UP) && + (ifp->if_drv_flags & IFF_DRV_RUNNING)) + ipw_init_locked(sc, 0); + error = 0; } + IPW_UNLOCK(sc); - if ((ifp->if_flags & IFF_UP) && (ifp->if_drv_flags & IFF_DRV_RUNNING)) - ipw_init(sc); - - mtx_unlock(&sc->sc_mtx); + return error; +} +static int +ipw_cvtrate(int ipwrate) +{ + switch (ipwrate) { + case IPW_RATE_DS1: return 2; + case IPW_RATE_DS2: return 4; + case IPW_RATE_DS5: return 11; + case IPW_RATE_DS11: return 22; + } return 0; } @@ -756,20 +802,9 @@ ipw_media_change(struct ifnet *ifp) static void ipw_media_status(struct ifnet *ifp, struct ifmediareq *imr) { -#define N(a) (sizeof (a) / sizeof (a[0])) struct ipw_softc *sc = ifp->if_softc; struct ieee80211com *ic = &sc->sc_ic; - static const struct { - uint32_t val; - int rate; - } rates[] = { - { IPW_RATE_DS1, 2 }, - { IPW_RATE_DS2, 4 }, - { IPW_RATE_DS5, 11 }, - { IPW_RATE_DS11, 22 }, - }; - uint32_t val; - int rate, i; + int rate; imr->ifm_status = IFM_AVALID; imr->ifm_active = IFM_IEEE80211; @@ -777,33 +812,13 @@ ipw_media_status(struct ifnet *ifp, stru imr->ifm_status |= IFM_ACTIVE; /* read current transmission rate from adapter */ - val = ipw_read_table1(sc, IPW_INFO_CURRENT_TX_RATE) & 0xf; - - /* convert ipw rate to 802.11 rate */ - for (i = 0; i < N(rates) && rates[i].val != val; i++); - rate = (i < N(rates)) ? rates[i].rate : 0; - - imr->ifm_active |= IFM_IEEE80211_11B; + rate = ipw_cvtrate(ipw_read_table1(sc, IPW_INFO_CURRENT_TX_RATE) & 0xf); imr->ifm_active |= ieee80211_rate2media(ic, rate, IEEE80211_MODE_11B); - switch (ic->ic_opmode) { - case IEEE80211_M_STA: - break; - case IEEE80211_M_IBSS: + if (ic->ic_opmode == IEEE80211_M_IBSS) imr->ifm_active |= IFM_IEEE80211_IBSS; - break; - - case IEEE80211_M_MONITOR: + else if (ic->ic_opmode == IEEE80211_M_MONITOR) imr->ifm_active |= IFM_IEEE80211_MONITOR; - break; - - case IEEE80211_M_AHDEMO: - case IEEE80211_M_HOSTAP: - case IEEE80211_M_WDS: - /* should not get there */ - break; - } -#undef N } static int @@ -811,99 +826,55 @@ ipw_newstate(struct ieee80211com *ic, en { struct ifnet *ifp = ic->ic_ifp; struct ipw_softc *sc = ifp->if_softc; - uint8_t macaddr[IEEE80211_ADDR_LEN]; - uint32_t len; - switch (nstate) { - case IEEE80211_S_RUN: - DELAY(200); /* firmware needs a short delay here */ - - len = IEEE80211_ADDR_LEN; - ipw_read_table2(sc, IPW_INFO_CURRENT_BSSID, macaddr, &len); - -#if 0 - ni = ieee80211_find_node(&ic->ic_scan, macaddr); - if (ni == NULL) - break; + DPRINTF(("%s: %s -> %s flags 0x%x\n", __func__, + ieee80211_state_name[ic->ic_state], + ieee80211_state_name[nstate], sc->flags)); - ieee80211_ref_node(ni); - ieee80211_sta_join(ic, ni); - ieee80211_node_authorize(ni); + switch (nstate) { + case IEEE80211_S_AUTH: + ipw_assoc(ic); + break; - if (ic->ic_opmode == IEEE80211_M_STA) - ieee80211_notify_node_join(ic, ni, 1); -#endif + case IEEE80211_S_RUN: + if (ic->ic_opmode == IEEE80211_M_IBSS) { + /* + * XXX when joining an ibss network we are called + * with a SCAN -> RUN transition on scan complete. + * Use that to call ipw_auth_and_assoc. On completing + * the join we are then called again with an + * AUTH -> RUN transition and we want to do nothing. + * This is all totally bogus and needs to be redone. + */ + if (ic->ic_state == IEEE80211_S_SCAN) + ipw_assoc(ic); + } + /* XXX way wrong */ + return sc->sc_newstate(ic, nstate, + IEEE80211_FC0_SUBTYPE_ASSOC_RESP); break; - case IEEE80211_S_INIT: - case IEEE80211_S_SCAN: - case IEEE80211_S_AUTH: case IEEE80211_S_ASSOC: break; - } - - ic->ic_state = nstate; - - return 0; -} - -/* - * Read 16 bits at address 'addr' from the serial EEPROM. - */ -static uint16_t -ipw_read_prom_word(struct ipw_softc *sc, uint8_t addr) -{ - uint32_t tmp; - uint16_t val; - int n; - - /* clock C once before the first command */ - IPW_EEPROM_CTL(sc, 0); - IPW_EEPROM_CTL(sc, IPW_EEPROM_S); - IPW_EEPROM_CTL(sc, IPW_EEPROM_S | IPW_EEPROM_C); - IPW_EEPROM_CTL(sc, IPW_EEPROM_S); - - /* write start bit (1) */ - IPW_EEPROM_CTL(sc, IPW_EEPROM_S | IPW_EEPROM_D); - IPW_EEPROM_CTL(sc, IPW_EEPROM_S | IPW_EEPROM_D | IPW_EEPROM_C); - - /* write READ opcode (10) */ - IPW_EEPROM_CTL(sc, IPW_EEPROM_S | IPW_EEPROM_D); - IPW_EEPROM_CTL(sc, IPW_EEPROM_S | IPW_EEPROM_D | IPW_EEPROM_C); - IPW_EEPROM_CTL(sc, IPW_EEPROM_S); - IPW_EEPROM_CTL(sc, IPW_EEPROM_S | IPW_EEPROM_C); - - /* write address A7-A0 */ - for (n = 7; n >= 0; n--) { - IPW_EEPROM_CTL(sc, IPW_EEPROM_S | - (((addr >> n) & 1) << IPW_EEPROM_SHIFT_D)); - IPW_EEPROM_CTL(sc, IPW_EEPROM_S | - (((addr >> n) & 1) << IPW_EEPROM_SHIFT_D) | IPW_EEPROM_C); - } - IPW_EEPROM_CTL(sc, IPW_EEPROM_S); + case IEEE80211_S_INIT: + /* + * NB: don't try to do this if ipw_stop_master has + * shutdown the firmware and disabled interrupts. + */ + if (ic->ic_state == IEEE80211_S_RUN && + (sc->flags & IPW_FLAG_FW_INITED)) + ipw_disassoc(ic); + break; - /* read data Q15-Q0 */ - val = 0; - for (n = 15; n >= 0; n--) { - IPW_EEPROM_CTL(sc, IPW_EEPROM_S | IPW_EEPROM_C); - IPW_EEPROM_CTL(sc, IPW_EEPROM_S); - tmp = MEM_READ_4(sc, IPW_MEM_EEPROM_CTL); - val |= ((tmp & IPW_EEPROM_Q) >> IPW_EEPROM_SHIFT_Q) << n; + default: + break; } - - IPW_EEPROM_CTL(sc, 0); - - /* clear Chip Select and clock C */ - IPW_EEPROM_CTL(sc, IPW_EEPROM_S); - IPW_EEPROM_CTL(sc, 0); - IPW_EEPROM_CTL(sc, IPW_EEPROM_C); - - return le16toh(val); + return sc->sc_newstate(ic, nstate, arg); } static void -ipw_command_intr(struct ipw_softc *sc, struct ipw_soft_buf *sbuf) +ipw_rx_cmd_intr(struct ipw_softc *sc, struct ipw_soft_buf *sbuf) { struct ipw_cmd *cmd; @@ -911,16 +882,18 @@ ipw_command_intr(struct ipw_softc *sc, s cmd = mtod(sbuf->m, struct ipw_cmd *); - DPRINTFN(2, ("cmd ack'ed (%u, %u, %u, %u, %u)\n", le32toh(cmd->type), - le32toh(cmd->subtype), le32toh(cmd->seq), le32toh(cmd->len), - le32toh(cmd->status))); + DPRINTFN(9, ("%s(%s subtype %u seq %u len %u status %u)\n", + __func__, ipw_cmdname(le32toh(cmd->type)), le32toh(cmd->subtype), + le32toh(cmd->seq), le32toh(cmd->len), le32toh(cmd->status))); - wakeup(sc); + sc->flags &= ~IPW_FLAG_BUSY; + wakeup_one(&sc->cmd); } static void -ipw_newstate_intr(struct ipw_softc *sc, struct ipw_soft_buf *sbuf) +ipw_rx_newstate_intr(struct ipw_softc *sc, struct ipw_soft_buf *sbuf) { +#define IEEESTATE(ic) ieee80211_state_name[ic->ic_state] struct ieee80211com *ic = &sc->sc_ic; uint32_t state; @@ -928,44 +901,109 @@ ipw_newstate_intr(struct ipw_softc *sc, state = le32toh(*mtod(sbuf->m, uint32_t *)); - DPRINTFN(2, ("entering state %u\n", state)); - switch (state) { + case IPW_STATE_INITIALIZED: + case IPW_STATE_DISABLED: + break; + case IPW_STATE_ASSOCIATED: - ieee80211_new_state(ic, IEEE80211_S_RUN, -1); + DPRINTFN(2, ("Association succeeded (%s flags 0x%x)\n", + IEEESTATE(ic), sc->flags)); + sc->flags |= IPW_FLAG_ASSOCIATED; + IPW_STATE_END(sc, IPW_FW_ASSOCIATING); + /* XXX suppress state change in case the fw auto-associates */ + if (ic->ic_state != IEEE80211_S_ASSOC) { + DPRINTF(("Unexpected association (state %u)\n", + ic->ic_state)); + } else + ieee80211_new_state(ic, IEEE80211_S_RUN, -1); break; case IPW_STATE_SCANNING: - /* don't leave run state on background scan */ - if (ic->ic_state != IEEE80211_S_RUN) - ieee80211_new_state(ic, IEEE80211_S_SCAN, -1); + DPRINTFN(3, ("Scanning (%s flags 0x%x)\n", + IEEESTATE(ic), sc->flags)); + /* + * NB: Check driver state for association on assoc + * loss as the firmware will immediately start to + * scan and we would treat it as a beacon miss if + * we checked the 802.11 layer state. + */ + if (sc->flags & IPW_FLAG_ASSOCIATED) + ieee80211_beacon_miss(ic); - ic->ic_flags |= IEEE80211_F_SCAN; + sc->sc_state_timer = 3; /* fw is still alive */ break; case IPW_STATE_SCAN_COMPLETE: - ieee80211_notify_scan_done(ic); - ic->ic_flags &= ~IEEE80211_F_SCAN; + DPRINTFN(3, ("Scan complete (%s flags 0x%x)\n", + IEEESTATE(ic), sc->flags)); + /* + * XXX For some reason scan requests generate scan + * started + scan done events before any traffic is + * received (e.g. probe response frames). We work + * around this by marking the HACK flag and skipping + * the first scan complete event. This works ok + * because the adapter scans only 2.4G channels so + * doing an extra pass doesn't take long. + if (sc->flags & IPW_FLAG_HACK) { + sc->flags &= ~IPW_FLAG_HACK; + break; + } + */ + + /* Only update the scan module if we were actaully scanning */ + if (sc->fw_state == IPW_FW_SCANNING) { + sc->flags &= ~IPW_FLAG_SCANNING; + IPW_STATE_END(sc, IPW_FW_SCANNING); + ieee80211_scan_done(ic); + } break; case IPW_STATE_ASSOCIATION_LOST: - ieee80211_new_state(ic, IEEE80211_S_INIT, -1); + DPRINTFN(2, ("Association lost (%s flags 0x%x)\n", + IEEESTATE(ic), sc->flags)); + sc->flags &= ~IPW_FLAG_ASSOCIATED; + taskqueue_enqueue(sc->sc_tq, &sc->sc_assoclosttask); break; - case IPW_STATE_RADIO_DISABLED: - ic->ic_ifp->if_flags &= ~IFF_UP; - ipw_stop(sc); + case IPW_STATE_RADIO_OFF: + DPRINTFN(2, ("Radio off (%s flags 0x%x)\n", + IEEESTATE(ic), sc->flags)); + taskqueue_enqueue(sc->sc_tq, &sc->sc_radiofftask); + break; + default: + DPRINTFN(2, ("%s: state %u %s flags 0x%x\n", + __func__, state, IEEESTATE(ic), sc->flags)); break; } +#undef IEEESTATE +} + +/* + * Set driver state for current channel. + */ +static void +ipw_setcurchan(struct ipw_softc *sc, struct ieee80211_channel *chan) +{ + struct ieee80211com *ic = &sc->sc_ic; + + ic->ic_curchan = chan; + sc->sc_rxtap.wr_chan_freq = sc->sc_txtap.wt_chan_freq = + htole16(ic->ic_curchan->ic_freq); + sc->sc_rxtap.wr_chan_flags = sc->sc_txtap.wt_chan_flags = + htole16(ic->ic_curchan->ic_flags); } /* * XXX: Hack to set the current channel to the value advertised in beacons or * probe responses. Only used during AP detection. + * XXX value comes from DSPARMS ie which is wrong for off-channel rx's */ static void -ipw_fix_channel(struct ieee80211com *ic, struct mbuf *m) +ipw_fix_channel(struct ipw_softc *sc, struct mbuf *m) { + struct ieee80211com *ic = &sc->sc_ic; + struct ieee80211_channel *c; struct ieee80211_frame *wh; uint8_t subtype; uint8_t *frm, *efrm; @@ -986,20 +1024,25 @@ ipw_fix_channel(struct ieee80211com *ic, frm += 12; /* skip tstamp, bintval and capinfo fields */ while (frm < efrm) { - if (*frm == IEEE80211_ELEMID_DSPARMS) + if (*frm == IEEE80211_ELEMID_DSPARMS #if IEEE80211_CHAN_MAX < 255 - if (frm[2] <= IEEE80211_CHAN_MAX) + && frm[2] <= IEEE80211_CHAN_MAX #endif - ic->ic_bsschan = ieee80211_find_channel(ic, + ) { + c = ieee80211_find_channel(ic, ieee80211_ieee2mhz(frm[2], 0), - IEEE80211_MODE_AUTO); + IEEE80211_CHAN_B); + if (c == NULL) + c = &ic->ic_channels[0]; + ipw_setcurchan(sc, c); + } frm += frm[1] + 2; } } static void -ipw_data_intr(struct ipw_softc *sc, struct ipw_status *status, +ipw_rx_data_intr(struct ipw_softc *sc, struct ipw_status *status, struct ipw_soft_bd *sbd, struct ipw_soft_buf *sbuf) { struct ieee80211com *ic = &sc->sc_ic; @@ -1008,15 +1051,25 @@ ipw_data_intr(struct ipw_softc *sc, stru struct ieee80211_frame *wh; struct ieee80211_node *ni; bus_addr_t physaddr; - int error; + int error, framelen; + IPW_LOCK_DECL; + + framelen = le32toh(status->len); + if (framelen < IEEE80211_MIN_LEN || framelen > MCLBYTES) { + /* + * XXX >MCLBYTES is bogus as it means the h/w dma'd + * out of bounds; need to figure out how to limit + * frame size in the firmware + */ + /* XXX stat */ + DPRINTF(("drop rx frame len=%u rssi=%u\n", + framelen, status->rssi)); + return; + } DPRINTFN(5, ("received frame len=%u, rssi=%u\n", le32toh(status->len), status->rssi)); - if (le32toh(status->len) < sizeof (struct ieee80211_frame_min) || - le32toh(status->len) > MCLBYTES) - return; - /* * Try to allocate a new mbuf for this ring element and load it before * processing the current mbuf. If the ring element cannot be loaded, @@ -1062,22 +1115,21 @@ ipw_data_intr(struct ipw_softc *sc, stru m->m_pkthdr.rcvif = ifp; m->m_pkthdr.len = m->m_len = le32toh(status->len); - if (bpf_peers_present(sc->sc_drvbpf)) { + /* XXX */ + if (sc->flags & IPW_FLAG_SCANNING) + ipw_fix_channel(sc, m); + + if (sc->sc_drvbpf != NULL) { struct ipw_rx_radiotap_header *tap = &sc->sc_rxtap; tap->wr_flags = 0; - tap->wr_antsignal = status->rssi; - tap->wr_chan_freq = htole16(ic->ic_curchan->ic_freq); - tap->wr_chan_flags = htole16(ic->ic_curchan->ic_flags); + tap->wr_antsignal = status->rssi + IPW_RSSI_TO_DBM; bpf_mtap2(sc->sc_drvbpf, tap, sc->sc_rxtap_len, m); } - if (ic->ic_state == IEEE80211_S_SCAN) - ipw_fix_channel(ic, m); - wh = mtod(m, struct ieee80211_frame *); - mtx_unlock(&sc->sc_mtx); + IPW_UNLOCK(sc); ni = ieee80211_find_rxnode(ic, (struct ieee80211_frame_min *)wh); /* send the frame to the 802.11 layer */ @@ -1085,7 +1137,7 @@ ipw_data_intr(struct ipw_softc *sc, stru /* node is no longer needed */ ieee80211_free_node(ni); - mtx_lock(&sc->sc_mtx); + IPW_LOCK(sc); bus_dmamap_sync(sc->rbd_dmat, sc->rbd_map, BUS_DMASYNC_PREWRITE); } @@ -1093,6 +1145,7 @@ ipw_data_intr(struct ipw_softc *sc, stru static void ipw_rx_intr(struct ipw_softc *sc) { + struct ieee80211com *ic = &sc->sc_ic; struct ipw_status *status; struct ipw_soft_bd *sbd; struct ipw_soft_buf *sbuf; @@ -1112,31 +1165,33 @@ ipw_rx_intr(struct ipw_softc *sc) switch (le16toh(status->code) & 0xf) { case IPW_STATUS_CODE_COMMAND: - ipw_command_intr(sc, sbuf); + ipw_rx_cmd_intr(sc, sbuf); break; case IPW_STATUS_CODE_NEWSTATE: - ipw_newstate_intr(sc, sbuf); + ipw_rx_newstate_intr(sc, sbuf); break; case IPW_STATUS_CODE_DATA_802_3: case IPW_STATUS_CODE_DATA_802_11: - ipw_data_intr(sc, status, sbd, sbuf); + ipw_rx_data_intr(sc, status, sbd, sbuf); break; case IPW_STATUS_CODE_NOTIFICATION: - DPRINTFN(2, ("received notification\n")); + DPRINTFN(2, ("notification status, len %u flags 0x%x\n", + le32toh(status->len), status->flags)); + if (ic->ic_state == IEEE80211_S_AUTH) { + /* XXX assume auth notification */ + ieee80211_node_authorize(ic->ic_bss); + ieee80211_new_state(ic, IEEE80211_S_ASSOC, -1); + } break; default: - device_printf(sc->sc_dev, "unknown status code %u\n", + device_printf(sc->sc_dev, "unexpected status code %u\n", le16toh(status->code)); + break; } - - /* firmware was killed, stop processing received frames */ - if (!(sc->flags & IPW_FLAG_FW_INITED)) - return; - sbd->bd->flags = 0; } @@ -1174,12 +1229,8 @@ ipw_release_sbd(struct ipw_softc *sc, st bus_dmamap_unload(sc->txbuf_dmat, sbuf->map); SLIST_INSERT_HEAD(&sc->free_sbuf, sbuf, next); - if (sbuf->m->m_flags & M_TXCB) - ieee80211_process_callback(sbuf->ni, sbuf->m, 0/*XXX*/); m_freem(sbuf->m); ieee80211_free_node(sbuf->ni); - - sc->sc_tx_timer = 0; break; } @@ -1211,8 +1262,10 @@ ipw_tx_intr(struct ipw_softc *sc) /* remember what the firmware has processed */ sc->txold = (r == 0) ? IPW_NTBD - 1 : r - 1; + sc->sc_tx_timer = 0; ifp->if_drv_flags &= ~IFF_DRV_OACTIVE; - ipw_start(ifp); + + ipw_start_locked(ifp); } static void @@ -1222,36 +1275,39 @@ ipw_intr(void *arg) uint32_t r; mtx_lock(&sc->sc_mtx); - - if ((r = CSR_READ_4(sc, IPW_CSR_INTR)) == 0 || r == 0xffffffff) { - mtx_unlock(&sc->sc_mtx); - return; - } - - /* disable interrupts */ - CSR_WRITE_4(sc, IPW_CSR_INTR_MASK, 0); - - /* acknowledge all interrupts */ - CSR_WRITE_4(sc, IPW_CSR_INTR, r); - - if (r & (IPW_INTR_FATAL_ERROR | IPW_INTR_PARITY_ERROR)) { - device_printf(sc->sc_dev, "firmware error\n"); - taskqueue_enqueue_fast(taskqueue_fast, &sc->sc_init_task); - r = 0; /* don't process more interrupts */ + r = CSR_READ_4(sc, IPW_CSR_INTR); + if (r != 0 && r != 0xffffffff) { + /* acknowledge all interrupts */ + CSR_WRITE_4(sc, IPW_CSR_INTR, r); + + DPRINTFN(9, ("%s: 0x%x\n", __func__, r)); + + if (r & IPW_INTR_FATAL_ERROR) { + device_printf(sc->sc_dev, "firmware error\n"); + taskqueue_enqueue(sc->sc_tq, &sc->sc_restarttask); + r = 0; /* NB: don't do anything else */ + } + if (r & IPW_INTR_FW_INIT_DONE) { + wakeup_one(sc); + r &= ~IPW_INTR_FW_INIT_DONE; + } + if (r & IPW_INTR_RX_TRANSFER) { + ipw_rx_intr(sc); + r &= ~IPW_INTR_RX_TRANSFER; + } + if (r & IPW_INTR_TX_TRANSFER) { + ipw_tx_intr(sc); + r &= ~IPW_INTR_TX_TRANSFER; + } + if (r & IPW_INTR_PARITY_ERROR) { + /* XXX rate limit */ + device_printf(sc->sc_dev, "parity error\n"); + r &= ~IPW_INTR_PARITY_ERROR; + } + if (r != 0) + device_printf(sc->sc_dev, + "%s: 0x%x unserviced\n", __func__, r); } - - if (r & IPW_INTR_FW_INIT_DONE) - wakeup(sc); - - if (r & IPW_INTR_RX_TRANSFER) - ipw_rx_intr(sc); - - if (r & IPW_INTR_TX_TRANSFER) - ipw_tx_intr(sc); - - /* re-enable interrupts */ - CSR_WRITE_4(sc, IPW_CSR_INTR_MASK, IPW_INTR_MASK); - mtx_unlock(&sc->sc_mtx); } @@ -1266,26 +1322,87 @@ ipw_dma_map_addr(void *arg, bus_dma_segm *(bus_addr_t *)arg = segs[0].ds_addr; } +static const char * +ipw_cmdname(int cmd) +{ +#define N(a) (sizeof(a) / sizeof(a[0])) + static const struct { + int cmd; + const char *name; + } cmds[] = { + { IPW_CMD_ADD_MULTICAST, "ADD_MULTICAST" }, + { IPW_CMD_BROADCAST_SCAN, "BROADCAST_SCAN" }, + { IPW_CMD_DISABLE, "DISABLE" }, + { IPW_CMD_DISABLE_PHY, "DISABLE_PHY" }, + { IPW_CMD_DISASSOCIATE, "DISASSOCIATE" }, + { IPW_CMD_ENABLE, "ENABLE" }, + { IPW_CMD_PREPARE_POWER_DOWN, "PREPARE_POWER_DOWN" }, + { IPW_CMD_SET_BASIC_TX_RATES, "SET_BASIC_TX_RATES" }, + { IPW_CMD_SET_BEACON_INTERVAL, "SET_BEACON_INTERVAL" }, + { IPW_CMD_SET_CHANNEL, "SET_CHANNEL" }, + { IPW_CMD_SET_CONFIGURATION, "SET_CONFIGURATION" }, + { IPW_CMD_SET_DESIRED_BSSID, "SET_DESIRED_BSSID" }, + { IPW_CMD_SET_ESSID, "SET_ESSID" }, + { IPW_CMD_SET_FRAG_THRESHOLD, "SET_FRAG_THRESHOLD" }, + { IPW_CMD_SET_LONG_RETRY, "SET_LONG_RETRY" }, + { IPW_CMD_SET_MAC_ADDRESS, "SET_MAC_ADDRESS" }, + { IPW_CMD_SET_MANDATORY_BSSID, "SET_MANDATORY_BSSID" }, + { IPW_CMD_SET_MODE, "SET_MODE" }, + { IPW_CMD_SET_MSDU_TX_RATES, "SET_MSDU_TX_RATES" }, + { IPW_CMD_SET_POWER_MODE, "SET_POWER_MODE" }, + { IPW_CMD_SET_RTS_THRESHOLD, "SET_RTS_THRESHOLD" }, + { IPW_CMD_SET_SCAN_DWELL_TIME, "SET_SCAN_DWELL_TIME" }, + { IPW_CMD_SET_SCAN_OPTIONS, "SET_SCAN_OPTIONS" }, + { IPW_CMD_SET_SECURITY_INFO, "SET_SECURITY_INFO" }, + { IPW_CMD_SET_SHORT_RETRY, "SET_SHORT_RETRY" }, + { IPW_CMD_SET_TX_POWER_INDEX, "SET_TX_POWER_INDEX" }, + { IPW_CMD_SET_TX_RATES, "SET_TX_RATES" }, + { IPW_CMD_SET_WEP_FLAGS, "SET_WEP_FLAGS" }, + { IPW_CMD_SET_WEP_KEY, "SET_WEP_KEY" }, + { IPW_CMD_SET_WEP_KEY_INDEX, "SET_WEP_KEY_INDEX" }, + { IPW_CMD_SET_WPA_IE, "SET_WPA_IE" }, + + }; + static char buf[12]; + int i; + + for (i = 0; i < N(cmds); i++) + if (cmds[i].cmd == cmd) + return cmds[i].name; + snprintf(buf, sizeof(buf), "%u", cmd); + return buf; +#undef N +} + /* * Send a command to the firmware and wait for the acknowledgement. */ static int -ipw_cmd(struct ipw_softc *sc, uint32_t type, void *data, uint32_t len) +ipw_cmd(struct ipw_softc *sc, uint32_t cmd, const void *data, uint32_t len) { struct ipw_soft_bd *sbd; bus_addr_t physaddr; int error; + if (sc->flags & IPW_FLAG_BUSY) { + device_printf(sc->sc_dev, "%s: %s not sent, busy\n", + __func__, ipw_cmdname(cmd)); + return EAGAIN; + } + sc->flags |= IPW_FLAG_BUSY; + sbd = &sc->stbd_list[sc->txcur]; error = bus_dmamap_load(sc->cmd_dmat, sc->cmd_map, &sc->cmd, sizeof (struct ipw_cmd), ipw_dma_map_addr, &physaddr, 0); if (error != 0) { - device_printf(sc->sc_dev, "could not map command DMA memory\n"); + device_printf(sc->sc_dev, + "%s: %s not sent, could not map memory (error %u)\n", + __func__, ipw_cmdname(cmd), error); return error; } - sc->cmd.type = htole32(type); + sc->cmd.type = htole32(cmd); sc->cmd.subtype = 0; sc->cmd.len = htole32(len); sc->cmd.seq = 0; @@ -1301,7 +1418,8 @@ ipw_cmd(struct ipw_softc *sc, uint32_t t bus_dmamap_sync(sc->cmd_dmat, sc->cmd_map, BUS_DMASYNC_PREWRITE); bus_dmamap_sync(sc->tbd_dmat, sc->tbd_map, BUS_DMASYNC_PREWRITE); - DPRINTFN(2, ("sending command (%u, %u, %u, %u)\n", type, 0, 0, len)); + DPRINTFN(4, ("sending %s(%u, %u, %u, %u)\n", + ipw_cmdname(cmd), cmd, 0, 0, len)); /* kick firmware */ sc->txfree--; @@ -1309,7 +1427,13 @@ ipw_cmd(struct ipw_softc *sc, uint32_t t CSR_WRITE_4(sc, IPW_CSR_TX_WRITE, sc->txcur); /* wait at most one second for command to complete */ - return msleep(sc, &sc->sc_mtx, 0, "ipwcmd", hz); + error = msleep(&sc->cmd, &sc->sc_mtx, 0, "ipwcmd", hz); + if (error != 0) { + device_printf(sc->sc_dev, "%s: %s failed, timeout (error %u)\n", + __func__, ipw_cmdname(cmd), error); + return error; + } + return 0; } static int @@ -1325,11 +1449,15 @@ ipw_tx_start(struct ifnet *ifp, struct m struct mbuf *mnew; bus_dma_segment_t segs[IPW_MAX_NSEG]; bus_addr_t physaddr; - int nsegs, error, i; + int nsegs, error, i, iswep, hdrlen, ismcast; wh = mtod(m0, struct ieee80211_frame *); + /* NB: only data frames use this path */ + iswep = wh->i_fc[1] & IEEE80211_FC1_WEP; + hdrlen = ieee80211_hdrsize(wh); + ismcast = IEEE80211_IS_MULTICAST(wh->i_addr1); - if (wh->i_fc[1] & IEEE80211_FC1_WEP) { + if (iswep) { k = ieee80211_crypto_encap(ic, ni, m0); if (k == NULL) { m_freem(m0); @@ -1340,12 +1468,10 @@ ipw_tx_start(struct ifnet *ifp, struct m wh = mtod(m0, struct ieee80211_frame *); } - if (bpf_peers_present(sc->sc_drvbpf)) { + if (sc->sc_drvbpf != NULL) { struct ipw_tx_radiotap_header *tap = &sc->sc_txtap; tap->wt_flags = 0; - tap->wt_chan_freq = htole16(ic->ic_curchan->ic_freq); - tap->wt_chan_flags = htole16(ic->ic_curchan->ic_flags); bpf_mtap2(sc->sc_drvbpf, tap, sc->sc_txtap_len, m0); } @@ -1356,7 +1482,8 @@ ipw_tx_start(struct ifnet *ifp, struct m shdr->hdr.type = htole32(IPW_HDR_TYPE_SEND); shdr->hdr.subtype = 0; - shdr->hdr.encrypted = (wh->i_fc[1] & IEEE80211_FC1_WEP) ? 1 : 0; + shdr->hdr.encrypted = iswep ? 1 : 0; + /* NB: always do crypto in the host */ shdr->hdr.encrypt = 0; shdr->hdr.keyidx = 0; shdr->hdr.keysz = 0; @@ -1367,8 +1494,7 @@ ipw_tx_start(struct ifnet *ifp, struct m else IEEE80211_ADDR_COPY(shdr->hdr.dst_addr, wh->i_addr1); - /* trim IEEE802.11 header */ - m_adj(m0, sizeof (struct ieee80211_frame)); + m_adj(m0, hdrlen); /* strip IEEE802.11 header */ error = bus_dmamap_load_mbuf_sg(sc->txbuf_dmat, sbuf->map, m0, segs, &nsegs, 0); @@ -1419,7 +1545,7 @@ ipw_tx_start(struct ifnet *ifp, struct m sbd->bd->flags = IPW_BD_FLAG_TX_FRAME_802_3 | IPW_BD_FLAG_TX_NOT_LAST_FRAGMENT; - DPRINTFN(5, ("sending tx hdr (%u, %u, %u, %u, %6D, %6D)\n", + DPRINTFN(5, ("%s: tx hdr (%u, %u, %u, %u, %6D, %6D)\n", __func__, shdr->hdr.type, shdr->hdr.subtype, shdr->hdr.encrypted, shdr->hdr.encrypt, shdr->hdr.src_addr, ":", shdr->hdr.dst_addr, ":")); @@ -1446,7 +1572,8 @@ ipw_tx_start(struct ifnet *ifp, struct m sbd->bd->flags |= IPW_BD_FLAG_TX_NOT_LAST_FRAGMENT; } - DPRINTFN(5, ("sending fragment (%d, %d)\n", i, segs[i].ds_len)); + DPRINTFN(5, ("%s: fragment (%d, %d)\n", __func__, + i, segs[i].ds_len)); sc->txfree--; sc->txcur = (sc->txcur + 1) % IPW_NTBD; @@ -1463,7 +1590,7 @@ ipw_tx_start(struct ifnet *ifp, struct m } static void -ipw_start(struct ifnet *ifp) +ipw_start_locked(struct ifnet *ifp) { struct ipw_softc *sc = ifp->if_softc; struct ieee80211com *ic = &sc->sc_ic; @@ -1471,43 +1598,53 @@ ipw_start(struct ifnet *ifp) struct ether_header *eh; struct ieee80211_node *ni; - mtx_lock(&sc->sc_mtx); - - if (ic->ic_state != IEEE80211_S_RUN) { - mtx_unlock(&sc->sc_mtx); + if (ic->ic_state != IEEE80211_S_RUN) return; - } for (;;) { - IFQ_DRV_DEQUEUE(&ifp->if_snd, m0); - if (m0 == NULL) - break; + IF_DEQUEUE(&ic->ic_mgtq, m0); + if (m0 == NULL) { + IFQ_DRV_DEQUEUE(&ifp->if_snd, m0); + if (m0 == NULL) + break; + + if (sc->txfree < 1 + IPW_MAX_NSEG) { + IFQ_DRV_PREPEND(&ifp->if_snd, m0); + ifp->if_drv_flags |= IFF_DRV_OACTIVE; + break; + } - if (sc->txfree < 1 + IPW_MAX_NSEG) { - IFQ_DRV_PREPEND(&ifp->if_snd, m0); - ifp->if_drv_flags |= IFF_DRV_OACTIVE; - break; - } + if (m0->m_len < sizeof (struct ether_header) && + (m0 = m_pullup(m0, sizeof (struct ether_header))) == NULL) + continue; - if (m0->m_len < sizeof (struct ether_header) && - (m0 = m_pullup(m0, sizeof (struct ether_header))) == NULL) - continue; + eh = mtod(m0, struct ether_header *); + ni = ieee80211_find_txnode(ic, eh->ether_dhost); + if (ni == NULL) { + m_freem(m0); + continue; + } + BPF_MTAP(ifp, m0); - eh = mtod(m0, struct ether_header *); - ni = ieee80211_find_txnode(ic, eh->ether_dhost); - if (ni == NULL) { + m0 = ieee80211_encap(ic, m0, ni); + if (m0 == NULL) { + ieee80211_free_node(ni); + continue; + } + } else { + ni = (struct ieee80211_node *) m0->m_pkthdr.rcvif; + m0->m_pkthdr.rcvif = NULL; + /* XXX no way to send mgt frames(yet), discard */ m_freem(m0); - continue; - } - BPF_MTAP(ifp, m0); - - m0 = ieee80211_encap(ic, m0, ni); - if (m0 == NULL) { ieee80211_free_node(ni); continue; } +#if __FreeBSD_version >= 700017 if (bpf_peers_present(ic->ic_rawbpf)) +#else + if (ic->ic_rawbpf != NULL) +#endif bpf_mtap(ic->ic_rawbpf, m0); if (ipw_tx_start(ifp, m0, ni) != 0) { @@ -1518,34 +1655,58 @@ ipw_start(struct ifnet *ifp) /* start watchdog timer */ sc->sc_tx_timer = 5; - ifp->if_timer = 1; } - - mtx_unlock(&sc->sc_mtx); } static void -ipw_watchdog(struct ifnet *ifp) +ipw_start(struct ifnet *ifp) { struct ipw_softc *sc = ifp->if_softc; + IPW_LOCK_DECL; - mtx_lock(&sc->sc_mtx); + IPW_LOCK(sc); + ipw_start_locked(ifp); + IPW_UNLOCK(sc); +} + +static void +ipw_watchdog(void *arg) +{ + struct ipw_softc *sc = arg; + struct ifnet *ifp = sc->sc_ifp; - ifp->if_timer = 0; + IPW_LOCK_ASSERT(sc); if (sc->sc_tx_timer > 0) { if (--sc->sc_tx_timer == 0) { if_printf(ifp, "device timeout\n"); ifp->if_oerrors++; - taskqueue_enqueue_fast(taskqueue_fast, - &sc->sc_init_task); - mtx_unlock(&sc->sc_mtx); - return; + taskqueue_enqueue(sc->sc_tq, &sc->sc_restarttask); } - ifp->if_timer = 1; } - - mtx_unlock(&sc->sc_mtx); + if (sc->sc_rfkill_timer > 0) { + if (--sc->sc_rfkill_timer == 0) { + /* + * Check for a change in rfkill state. We get an + * interrupt when a radio is disabled but not when + * it is enabled so we must poll for the latter. + */ + if (!ipw_getrfkill(sc)) + taskqueue_enqueue(sc->sc_tq, &sc->sc_radiontask); + else + sc->sc_rfkill_timer = 2; + } + } + if (sc->sc_state_timer > 0) { + if (--sc->sc_state_timer == 0) { + if (sc->flags & IPW_FLAG_SCANNING) { + if_printf(ifp, "scan stuck\n"); + taskqueue_enqueue(sc->sc_tq, &sc->sc_restarttask); + } + } + } + if (ifp->if_drv_flags & IFF_DRV_RUNNING) + callout_reset(&sc->sc_wdtimer, hz, ipw_watchdog, sc); } static int @@ -1554,32 +1715,44 @@ ipw_ioctl(struct ifnet *ifp, u_long cmd, struct ipw_softc *sc = ifp->if_softc; struct ieee80211com *ic = &sc->sc_ic; int error = 0; + IPW_LOCK_DECL; - mtx_lock(&sc->sc_mtx); + IPW_LOCK(sc); switch (cmd) { case SIOCSIFFLAGS: if (ifp->if_flags & IFF_UP) { if (!(ifp->if_drv_flags & IFF_DRV_RUNNING)) - ipw_init(sc); + ipw_init_locked(sc, 0); } else { if (ifp->if_drv_flags & IFF_DRV_RUNNING) - ipw_stop(sc); + ipw_stop_locked(sc); + else { + /* + * If device was stopped due to rfkill then + * marked down we'll have the polling thread + * running; stop it explicitly. + */ + sc->sc_rfkill_timer = 0; + } + ipw_put_firmware(sc); } break; default: error = ieee80211_ioctl(ic, cmd, data); + break; } if (error == ENETRESET) { if ((ifp->if_flags & IFF_UP) && - (ifp->if_drv_flags & IFF_DRV_RUNNING)) - ipw_init(sc); + (ifp->if_drv_flags & IFF_DRV_RUNNING) && + (ic->ic_roaming != IEEE80211_ROAMING_MANUAL)) + ipw_init_locked(sc, 0); error = 0; } - mtx_unlock(&sc->sc_mtx); + IPW_UNLOCK(sc); return error; } @@ -1605,7 +1778,7 @@ ipw_stop_master(struct ipw_softc *sc) tmp = CSR_READ_4(sc, IPW_CSR_RST); CSR_WRITE_4(sc, IPW_CSR_RST, tmp | IPW_RST_PRINCETON_RESET); - sc->flags &= ~IPW_FLAG_FW_INITED; + sc->flags &= ~(IPW_FLAG_FW_INITED | IPW_FLAG_BUSY | IPW_FLAG_ENABLED); } static int @@ -1640,103 +1813,174 @@ ipw_reset(struct ipw_softc *sc) return 0; } -/* - * Upload the microcode to the device. - */ static int -ipw_load_ucode(struct ipw_softc *sc, const char *uc, int size) +ipw_waitfordisable(struct ipw_softc *sc, int waitfor) { - int ntries; + int ms = hz < 1000 ? 1 : hz/10; + int i, error; - MEM_WRITE_4(sc, 0x3000e0, 0x80000000); - CSR_WRITE_4(sc, IPW_CSR_RST, 0); + for (i = 0; i < 100; i++) { + if (ipw_read_table1(sc, IPW_INFO_CARD_DISABLED) == waitfor) + return 0; + error = msleep(sc, &sc->sc_mtx, PCATCH, __func__, ms); + if (error == 0 || error != EWOULDBLOCK) + return 0; + } + DPRINTF(("%s: timeout waiting for %s\n", + __func__, waitfor ? "disable" : "enable")); + return ETIMEDOUT; +} - MEM_WRITE_2(sc, 0x220000, 0x0703); - MEM_WRITE_2(sc, 0x220000, 0x0707); +static int +ipw_enable(struct ipw_softc *sc) +{ + int error; - MEM_WRITE_1(sc, 0x210014, 0x72); - MEM_WRITE_1(sc, 0x210014, 0x72); + if ((sc->flags & IPW_FLAG_ENABLED) == 0) { + DPRINTF(("Enable adapter\n")); + error = ipw_cmd(sc, IPW_CMD_ENABLE, NULL, 0); + if (error != 0) + return error; + error = ipw_waitfordisable(sc, 0); + if (error != 0) + return error; + sc->flags |= IPW_FLAG_ENABLED; + } + return 0; +} - MEM_WRITE_1(sc, 0x210000, 0x40); - MEM_WRITE_1(sc, 0x210000, 0x00); - MEM_WRITE_1(sc, 0x210000, 0x40); +static int +ipw_disable(struct ipw_softc *sc) +{ + int error; - MEM_WRITE_MULTI_1(sc, 0x210010, uc, size); + if (sc->flags & IPW_FLAG_ENABLED) { + DPRINTF(("Disable adapter\n")); + error = ipw_cmd(sc, IPW_CMD_DISABLE, NULL, 0); + if (error != 0) + return error; + error = ipw_waitfordisable(sc, 1); + if (error != 0) + return error; + sc->flags &= ~IPW_FLAG_ENABLED; + } + return 0; +} - MEM_WRITE_1(sc, 0x210000, 0x00); - MEM_WRITE_1(sc, 0x210000, 0x00); - MEM_WRITE_1(sc, 0x210000, 0x80); +static int +ipw_setpowermode(struct ipw_softc *sc) +{ + struct ieee80211com *ic = &sc->sc_ic; + uint32_t data; - MEM_WRITE_2(sc, 0x220000, 0x0703); - MEM_WRITE_2(sc, 0x220000, 0x0707); + if (ic->ic_flags & IEEE80211_F_PMGTON) { + /* XXX set more fine-grained operation */ + data = htole32(IPW_POWER_MODE_AUTO); + } else + data = htole32(IPW_POWER_MODE_CAM); - MEM_WRITE_1(sc, 0x210014, 0x72); - MEM_WRITE_1(sc, 0x210014, 0x72); + DPRINTF(("Setting power mode to %u\n", le32toh(data))); + return ipw_cmd(sc, IPW_CMD_SET_POWER_MODE, &data, sizeof data); +} - MEM_WRITE_1(sc, 0x210000, 0x00); - MEM_WRITE_1(sc, 0x210000, 0x80); +static int +ipw_setwepkeys(struct ipw_softc *sc) +{ + struct ieee80211com *ic = &sc->sc_ic; + struct ipw_wep_key wepkey; + struct ieee80211_key *wk; + int error, i; - for (ntries = 0; ntries < 10; ntries++) { - if (MEM_READ_1(sc, 0x210000) & 1) - break; - DELAY(10); - } - if (ntries == 10) { - device_printf(sc->sc_dev, - "timeout waiting for ucode to initialize\n"); - return EIO; - } + for (i = 0; i < IEEE80211_WEP_NKID; i++) { + wk = &ic->ic_crypto.cs_nw_keys[i]; - MEM_WRITE_4(sc, 0x3000e0, 0); + if (wk->wk_cipher == NULL || + wk->wk_cipher->ic_cipher != IEEE80211_CIPHER_WEP) + continue; + wepkey.idx = i; + wepkey.len = wk->wk_keylen; + memset(wepkey.key, 0, sizeof wepkey.key); + memcpy(wepkey.key, wk->wk_key, wk->wk_keylen); + DPRINTF(("Setting wep key index %u len %u\n", wepkey.idx, + wepkey.len)); + error = ipw_cmd(sc, IPW_CMD_SET_WEP_KEY, &wepkey, + sizeof wepkey); + if (error != 0) + return error; + } return 0; } -/* set of macros to handle unaligned little endian data in firmware image */ -#define GETLE32(p) ((p)[0] | (p)[1] << 8 | (p)[2] << 16 | (p)[3] << 24) -#define GETLE16(p) ((p)[0] | (p)[1] << 8) static int -ipw_load_firmware(struct ipw_softc *sc, const char *fw, int size) +ipw_setwpaie(struct ipw_softc *sc, const void *ie, int ielen) { - const uint8_t *p, *end; - uint32_t tmp, dst; - uint16_t len; - int error; - - p = fw; - end = fw + size; - while (p < end) { - dst = GETLE32(p); p += 4; - len = GETLE16(p); p += 2; - - ipw_write_mem_1(sc, dst, p, len); - p += len; - } - - CSR_WRITE_4(sc, IPW_CSR_IO, IPW_IO_GPIO1_ENABLE | IPW_IO_GPIO3_MASK | - IPW_IO_LED_OFF); + struct ipw_wpa_ie wpaie; - /* enable interrupts */ - CSR_WRITE_4(sc, IPW_CSR_INTR_MASK, IPW_INTR_MASK); + memset(&wpaie, 0, sizeof(wpaie)); + wpaie.ielen = htole32(ielen); + /* XXX verify length */ + memcpy(&wpaie.ie, ie, ielen); + DPRINTF(("Setting wpa ie\n")); + return ipw_cmd(sc, IPW_CMD_SET_WPA_IE, &wpaie, sizeof(wpaie)); +} - /* kick the firmware */ - CSR_WRITE_4(sc, IPW_CSR_RST, 0); +static int +ipw_setbssid(struct ipw_softc *sc, const uint8_t *bssid) +{ + static const uint8_t zerobssid[IEEE80211_ADDR_LEN]; - tmp = CSR_READ_4(sc, IPW_CSR_CTL); - CSR_WRITE_4(sc, IPW_CSR_CTL, tmp | IPW_CTL_ALLOW_STANDBY); + if (bssid == NULL || bcmp(bssid, zerobssid, IEEE80211_ADDR_LEN) == 0) { + DPRINTF(("Setting mandatory BSSID to null\n")); + return ipw_cmd(sc, IPW_CMD_SET_MANDATORY_BSSID, NULL, 0); + } else { + DPRINTF(("Setting mandatory BSSID to %6D\n", bssid, ":")); + return ipw_cmd(sc, IPW_CMD_SET_MANDATORY_BSSID, + bssid, IEEE80211_ADDR_LEN); + } +} - /* wait at most one second for firmware initialization to complete */ - if ((error = msleep(sc, &sc->sc_mtx, 0, "ipwinit", hz)) != 0) { - device_printf(sc->sc_dev, "timeout waiting for firmware " - "initialization to complete\n"); - return error; +static int +ipw_setssid(struct ipw_softc *sc, void *ssid, size_t ssidlen) +{ + if (ssidlen == 0) { + /* + * A bug in the firmware breaks the ``don't associate'' + * bit in the scan options command. To compensate for + * this install a bogus ssid when no ssid is specified + * so the firmware won't try to associate. + */ + DPRINTF(("Setting bogus ESSID to WAR firmware bug\n")); + return ipw_cmd(sc, IPW_CMD_SET_ESSID, + "\x18\x19\x20\x21\x22\x23\x24\x25\x26\x27" + "\x28\x29\x2a\x2b\x2c\x2d\x2e\x2f\x30\x31" + "\x32\x33\x34\x35\x36\x37\x38\x39\x3a\x3b" + "\x3c\x3d", IEEE80211_NWID_LEN); + } else { +#ifdef IPW_DEBUG + if (ipw_debug > 0) { + printf("Setting ESSID to "); + ieee80211_print_essid(ssid, ssidlen); + printf("\n"); + } +#endif + return ipw_cmd(sc, IPW_CMD_SET_ESSID, ssid, ssidlen); } +} - tmp = CSR_READ_4(sc, IPW_CSR_IO); - CSR_WRITE_4(sc, IPW_CSR_IO, tmp | IPW_IO_GPIO1_MASK | - IPW_IO_GPIO3_MASK); +static int +ipw_setchannel(struct ipw_softc *sc, struct ieee80211_channel *chan) +{ + struct ieee80211com *ic = &sc->sc_ic; + uint32_t data; + int error; - return 0; + data = htole32(ieee80211_chan2ieee(ic, chan)); + DPRINTF(("Setting channel to %u\n", le32toh(data))); + error = ipw_cmd(sc, IPW_CMD_SET_CHANNEL, &data, sizeof data); + if (error == 0) + ipw_setcurchan(sc, chan); + return error; } static int @@ -1745,12 +1989,13 @@ ipw_config(struct ipw_softc *sc) struct ieee80211com *ic = &sc->sc_ic; struct ifnet *ifp = ic->ic_ifp; struct ipw_security security; - struct ieee80211_key *k; - struct ipw_wep_key wepkey; - struct ipw_scan_options options; struct ipw_configuration config; uint32_t data; - int error, i; + int error; + + error = ipw_disable(sc); + if (error != 0) + return error; switch (ic->ic_opmode) { case IEEE80211_M_STA: @@ -1771,21 +2016,23 @@ ipw_config(struct ipw_softc *sc) if (error != 0) return error; - if (ic->ic_opmode == IEEE80211_M_IBSS || - ic->ic_opmode == IEEE80211_M_MONITOR) { - data = htole32(ieee80211_chan2ieee(ic, ic->ic_curchan)); - DPRINTF(("Setting channel to %u\n", le32toh(data))); - error = ipw_cmd(sc, IPW_CMD_SET_CHANNEL, &data, sizeof data); + if (ic->ic_opmode == IEEE80211_M_MONITOR) { + error = ipw_setchannel(sc, ic->ic_curchan); if (error != 0) return error; } - if (ic->ic_opmode == IEEE80211_M_MONITOR) { - DPRINTF(("Enabling adapter\n")); - return ipw_cmd(sc, IPW_CMD_ENABLE, NULL, 0); - } + if (ic->ic_opmode == IEEE80211_M_MONITOR) + return ipw_enable(sc); - IEEE80211_ADDR_COPY(ic->ic_myaddr, IF_LLADDR(ifp)); + /* + * Handle any link-level address change. Note that we only + * need to force ic_myaddr; any other addresses are handled + * as a byproduct of the ifnet code marking the interface + * down then up. + * + * XXX should get from lladdr instead of arpcom but that's more work + */ DPRINTF(("Setting MAC address to %6D\n", ic->ic_myaddr, ":")); error = ipw_cmd(sc, IPW_CMD_SET_MAC_ADDRESS, ic->ic_myaddr, IEEE80211_ADDR_LEN); @@ -1798,6 +2045,7 @@ ipw_config(struct ipw_softc *sc) config.flags |= htole32(IPW_CFG_IBSS_AUTO_START); if (ifp->if_flags & IFF_PROMISC) config.flags |= htole32(IPW_CFG_PROMISCUOUS); + /* XXX honor channel list */ config.bss_chan = htole32(0x3fff); /* channels 1-14 */ config.ibss_chan = htole32(0x7ff); /* channels 1-11 */ DPRINTF(("Setting configuration to 0x%x\n", le32toh(config.flags))); @@ -1805,6 +2053,7 @@ ipw_config(struct ipw_softc *sc) if (error != 0) return error; + /* XXX fixed rate? */ data = htole32(0x3); /* 1, 2 */ DPRINTF(("Setting basic tx rates to 0x%x\n", le32toh(data))); error = ipw_cmd(sc, IPW_CMD_SET_BASIC_TX_RATES, &data, sizeof data); @@ -1817,13 +2066,24 @@ ipw_config(struct ipw_softc *sc) if (error != 0) return error; - data = htole32(IPW_POWER_MODE_CAM); - DPRINTF(("Setting power mode to %u\n", le32toh(data))); - error = ipw_cmd(sc, IPW_CMD_SET_POWER_MODE, &data, sizeof data); + /* NB: use the same rate set */ + DPRINTF(("Setting msdu tx rates to 0x%x\n", le32toh(data))); + error = ipw_cmd(sc, IPW_CMD_SET_MSDU_TX_RATES, &data, sizeof data); + if (error != 0) + return error; + + error = ipw_setpowermode(sc); if (error != 0) return error; if (ic->ic_opmode == IEEE80211_M_IBSS) { + data = htole32(ic->ic_bintval); + DPRINTF(("Setting beacon interval to %u\n", le32toh(data))); + error = ipw_cmd(sc, IPW_CMD_SET_BEACON_INTERVAL, &data, + sizeof data); + if (error != 0) + return error; + data = htole32(32); /* default value */ DPRINTF(("Setting tx power index to %u\n", le32toh(data))); error = ipw_cmd(sc, IPW_CMD_SET_TX_POWER_INDEX, &data, @@ -1844,22 +2104,11 @@ ipw_config(struct ipw_softc *sc) if (error != 0) return error; -#ifdef IPW_DEBUG - if (ipw_debug > 0) { - printf("Setting ESSID to "); - ieee80211_print_essid(ic->ic_des_ssid[0].ssid, - ic->ic_des_ssid[0].len); - printf("\n"); - } -#endif - error = ipw_cmd(sc, IPW_CMD_SET_ESSID, ic->ic_des_ssid[0].ssid, - ic->ic_des_ssid[0].len); + error = ipw_setbssid(sc, NULL); if (error != 0) return error; - - /* no mandatory BSSID */ - DPRINTF(("Setting mandatory BSSID to null\n")); - error = ipw_cmd(sc, IPW_CMD_SET_MANDATORY_BSSID, NULL, 0); + + error = ipw_setssid(sc, ic->ic_des_ssid[0].ssid, ic->ic_des_ssid[0].len); if (error != 0) return error; @@ -1877,35 +2126,25 @@ ipw_config(struct ipw_softc *sc) IPW_AUTH_SHARED : IPW_AUTH_OPEN; security.ciphers = htole32(IPW_CIPHER_NONE); DPRINTF(("Setting authmode to %u\n", security.authmode)); - error = ipw_cmd(sc, IPW_CMD_SET_SECURITY_INFORMATION, &security, + error = ipw_cmd(sc, IPW_CMD_SET_SECURITY_INFO, &security, sizeof security); if (error != 0) return error; if (ic->ic_flags & IEEE80211_F_PRIVACY) { - k = ic->ic_crypto.cs_nw_keys; - for (i = 0; i < IEEE80211_WEP_NKID; i++, k++) { - if (k->wk_keylen == 0) - continue; + error = ipw_setwepkeys(sc); + if (error != 0) + return error; - wepkey.idx = i; - wepkey.len = k->wk_keylen; - memset(wepkey.key, 0, sizeof wepkey.key); - memcpy(wepkey.key, k->wk_key, k->wk_keylen); - DPRINTF(("Setting wep key index %u len %u\n", - wepkey.idx, wepkey.len)); - error = ipw_cmd(sc, IPW_CMD_SET_WEP_KEY, &wepkey, - sizeof wepkey); + if (ic->ic_crypto.cs_def_txkey != IEEE80211_KEYIX_NONE) { + data = htole32(ic->ic_crypto.cs_def_txkey); + DPRINTF(("Setting wep tx key index to %u\n", + le32toh(data))); + error = ipw_cmd(sc, IPW_CMD_SET_WEP_KEY_INDEX, &data, + sizeof data); if (error != 0) return error; } - - data = htole32(ic->ic_crypto.cs_def_txkey); - DPRINTF(("Setting wep tx key index to %u\n", le32toh(data))); - error = ipw_cmd(sc, IPW_CMD_SET_WEP_KEY_INDEX, &data, - sizeof data); - if (error != 0) - return error; } data = htole32((ic->ic_flags & IEEE80211_F_PRIVACY) ? IPW_WEPON : 0); @@ -1914,143 +2153,219 @@ ipw_config(struct ipw_softc *sc) if (error != 0) return error; -#if 0 - struct ipw_wpa_ie ie; + return ipw_enable(sc); +} - memset(&ie, 0, sizeof ie); - ie.len = htole32(sizeof (struct ieee80211_ie_wpa)); - DPRINTF(("Setting wpa ie\n")); - error = ipw_cmd(sc, IPW_CMD_SET_WPA_IE, &ie, sizeof ie); +static int +ipw_setscanopts(struct ipw_softc *sc, uint32_t chanmask, uint32_t flags) +{ + struct ipw_scan_options opts; + + DPRINTF(("Scan options: mask 0x%x flags 0x%x\n", chanmask, flags)); + opts.chanmask = htole32(chanmask); + opts.flags = htole32(flags); + return ipw_cmd(sc, IPW_CMD_SET_SCAN_OPTIONS, &opts, sizeof(opts)); +} + +static int +ipw_scan(struct ipw_softc *sc) +{ + uint32_t params; + int error; + + DPRINTF(("%s: flags 0x%x\n", __func__, sc->flags)); + IPW_STATE_BEGIN(sc, IPW_FW_SCANNING); + sc->flags |= IPW_FLAG_SCANNING | IPW_FLAG_HACK; + + /* NB: IPW_SCAN_DO_NOT_ASSOCIATE does not work (we set it anyway) */ + error = ipw_setscanopts(sc, sc->chanmask, IPW_SCAN_DO_NOT_ASSOCIATE); if (error != 0) - return error; -#endif + goto done; + + /* + * Setup null/bogus ssid so firmware doesn't use any previous + * ssid to try and associate. This is because the ``don't + * associate'' option bit is broken (sigh). + */ + error = ipw_setssid(sc, NULL, 0); + if (error != 0) + goto done; - if (ic->ic_opmode == IEEE80211_M_IBSS) { - data = htole32(ic->ic_bintval); - DPRINTF(("Setting beacon interval to %u\n", le32toh(data))); - error = ipw_cmd(sc, IPW_CMD_SET_BEACON_INTERVAL, &data, - sizeof data); + /* + * NB: the adapter may be disabled on association lost; + * if so just re-enable it to kick off scanning. + */ + if (sc->flags & IPW_FLAG_ENABLED) { + params = 0; /* XXX? */ + error = ipw_cmd(sc, IPW_CMD_BROADCAST_SCAN, + ¶ms, sizeof(params)); + } else + error = ipw_enable(sc); +done: + if (error != 0) { + sc->flags &= ~(IPW_FLAG_SCANNING | IPW_FLAG_HACK); + IPW_STATE_END(sc, IPW_FW_SCANNING); + } + return (error); +} + +static void +ipw_assoc_lost(void *arg, int npending) +{ + struct ipw_softc *sc = arg; + struct ieee80211com *ic = &sc->sc_ic; + IPW_LOCK_DECL; + + DPRINTF(("%s: flags 0x%x\n", __func__, sc->flags)); + IPW_LOCK(sc); + (void) ipw_disable(sc); /* XXX stop fw from re-associating */ + if (ic->ic_state == IEEE80211_S_RUN) + ieee80211_new_state(ic, IEEE80211_S_SCAN, -1); + IPW_UNLOCK(sc); +} + +static int +ipw_auth_and_assoc(struct ipw_softc *sc) +{ + struct ieee80211com *ic = &sc->sc_ic; + struct ieee80211_node *ni = ic->ic_bss; + struct ipw_security security; + uint32_t data; + int error; + + IPW_LOCK_ASSERT(sc); + IPW_STATE_BEGIN(sc, IPW_FW_ASSOCIATING); + + error = ipw_disable(sc); + if (error != 0) + goto done; + + memset(&security, 0, sizeof security); + security.authmode = (ni->ni_authmode == IEEE80211_AUTH_SHARED) ? + IPW_AUTH_SHARED : IPW_AUTH_OPEN; + security.ciphers = htole32(IPW_CIPHER_NONE); + DPRINTF(("Setting authmode to %u\n", security.authmode)); + error = ipw_cmd(sc, IPW_CMD_SET_SECURITY_INFO, &security, + sizeof security); + if (error != 0) + goto done; + + if (ic->ic_flags & IEEE80211_F_PRIVACY) { + error = ipw_setwepkeys(sc); if (error != 0) - return error; + goto done; + + if (ic->ic_crypto.cs_def_txkey != IEEE80211_KEYIX_NONE) { + data = htole32(ic->ic_crypto.cs_def_txkey); + DPRINTF(("Setting wep tx key index to %u\n", + le32toh(data))); + error = ipw_cmd(sc, IPW_CMD_SET_WEP_KEY_INDEX, &data, + sizeof data); + if (error != 0) + goto done; + } } - options.flags = 0; - options.channels = htole32(0x3fff); /* scan channels 1-14 */ - DPRINTF(("Setting scan options to 0x%x\n", le32toh(options.flags))); - error = ipw_cmd(sc, IPW_CMD_SET_SCAN_OPTIONS, &options, sizeof options); + error = ipw_setssid(sc, ni->ni_essid, ni->ni_esslen); if (error != 0) - return error; + goto done; + + error = ipw_setbssid(sc, ni->ni_bssid); + if (error != 0) + goto done; + + data = htole32((ic->ic_flags & IEEE80211_F_PRIVACY) ? IPW_WEPON : 0); + DPRINTF(("Setting wep flags to 0x%x\n", le32toh(data))); + error = ipw_cmd(sc, IPW_CMD_SET_WEP_FLAGS, &data, sizeof data); + if (error != 0) + goto done; + + if (ic->ic_opt_ie != NULL) { + error = ipw_setwpaie(sc, ic->ic_opt_ie, ic->ic_opt_ie_len); + if (error != 0) + goto done; + } + + if (ic->ic_opmode == IEEE80211_M_IBSS) { + error = ipw_setchannel(sc, ni->ni_chan); + if (error != 0) + goto done; + } + + /* lock scan to ap's channel and enable associate */ + error = ipw_setscanopts(sc, + 1<<(ieee80211_chan2ieee(ic, ni->ni_chan)-1), 0); +done: + if (error != 0) { + IPW_STATE_END(sc, IPW_FW_ASSOCIATING); + return (error); + } - /* finally, enable adapter (start scanning for an access point) */ - DPRINTF(("Enabling adapter\n")); - return ipw_cmd(sc, IPW_CMD_ENABLE, NULL, 0); + return ipw_enable(sc); /* finally, enable adapter */ } -/* - * Handler for sc_init_task. This is a simple wrapper around ipw_init(). - * It is called on firmware panics or on watchdog timeouts. - */ -static void -ipw_init_task(void *context, int pending) +static int +ipw_disassociate(struct ipw_softc *sc) { - ipw_init(context); + struct ieee80211com *ic = &sc->sc_ic; + const struct ieee80211_node *ni = ic->ic_bss; + + DPRINTF(("Disassociate from %6D\n", ni->ni_bssid, ":")); + /* + * NB: firmware currently ignores bssid parameter, but + * supply it in case this changes (follow linux driver). + */ + return ipw_cmd(sc, IPW_CMD_DISASSOCIATE, + ni->ni_bssid, IEEE80211_ADDR_LEN); } static void ipw_init(void *priv) { struct ipw_softc *sc = priv; + IPW_LOCK_DECL; + + IPW_LOCK(sc); + ipw_init_locked(sc, 0); + IPW_UNLOCK(sc); +} + +static void +ipw_init_locked(struct ipw_softc *sc, int force) +{ struct ieee80211com *ic = &sc->sc_ic; struct ifnet *ifp = ic->ic_ifp; - const struct firmware *fp; - const struct ipw_firmware_hdr *hdr; - const char *imagename, *fw; - int owned; + IPW_LOCK_DECL; - /* - * ipw_init() is exposed through ifp->if_init so it might be called - * without the driver's lock held. Since msleep() doesn't like being - * called on a recursed mutex, we acquire the driver's lock only if - * we're not already holding it. - */ - if (!(owned = mtx_owned(&sc->sc_mtx))) - mtx_lock(&sc->sc_mtx); + DPRINTF(("%s: state %s flags 0x%x\n", __func__, + ieee80211_state_name[ic->ic_state], sc->flags)); - /* - * Avoid re-entrant calls. We need to release the mutex in ipw_init() - * when loading the firmware and we don't want to be called during this - * operation. - */ - if (sc->flags & IPW_FLAG_INIT_LOCKED) { - if (!owned) - mtx_unlock(&sc->sc_mtx); + if (sc->fw_state == IPW_FW_LOADING) return; - } - sc->flags |= IPW_FLAG_INIT_LOCKED; - ipw_stop(sc); + ipw_stop_locked(sc); if (ipw_reset(sc) != 0) { device_printf(sc->sc_dev, "could not reset adapter\n"); - goto fail1; - } - - switch (ic->ic_opmode) { - case IEEE80211_M_STA: - imagename = "ipw_bss"; - break; - case IEEE80211_M_IBSS: - imagename = "ipw_ibss"; - break; - case IEEE80211_M_MONITOR: - imagename = "ipw_monitor"; - break; - default: - imagename = NULL; /* should not get there */ + goto fail; } - /* - * Load firmware image using the firmware(9) subsystem. We need to - * release the driver's lock first. - */ - if (sc->sc_firmware == NULL || strcmp(sc->sc_firmware->name, - imagename) != 0) { - mtx_unlock(&sc->sc_mtx); - if (sc->sc_firmware != NULL) - firmware_put(sc->sc_firmware, FIRMWARE_UNLOAD); - sc->sc_firmware = firmware_get(imagename); - mtx_lock(&sc->sc_mtx); - } + IPW_STATE_BEGIN(sc, IPW_FW_LOADING); - if (sc->sc_firmware == NULL) { - device_printf(sc->sc_dev, - "could not load firmware image '%s'\n", imagename); - goto fail1; + IPW_UNLOCK(sc); + /* NB: cannot hold lock while loading firmware */ + if (!ipw_get_firmware(sc)) { + IPW_LOCK(sc); + goto fail; } + IPW_LOCK(sc); - fp = sc->sc_firmware; - if (fp->datasize < sizeof *hdr) { - device_printf(sc->sc_dev, - "firmware image too short %zu\n", fp->datasize); - goto fail2; + if (ipw_load_ucode(sc, &sc->fw_ucode) != 0) { + device_printf(sc->sc_dev, "could not load microcode\n"); + goto fail; } - hdr = (const struct ipw_firmware_hdr *)fp->data; - - if (fp->datasize < sizeof *hdr + le32toh(hdr->mainsz) + - le32toh(hdr->ucodesz)) { - device_printf(sc->sc_dev, - "firmware image too short %zu\n", fp->datasize); - goto fail2; - } - - fw = (const char *)fp->data + sizeof *hdr + le32toh(hdr->mainsz); - if (ipw_load_ucode(sc, fw, le32toh(hdr->ucodesz)) != 0) { - device_printf(sc->sc_dev, "could not load microcode\n"); - goto fail2; - } - - ipw_stop_master(sc); + ipw_stop_master(sc); /* * Setup tx, rx and status rings. @@ -2072,12 +2387,10 @@ ipw_init(void *priv) CSR_WRITE_4(sc, IPW_CSR_STATUS_BASE, sc->status_phys); - fw = (const char *)fp->data + sizeof *hdr; - if (ipw_load_firmware(sc, fw, le32toh(hdr->mainsz)) != 0) { + if (ipw_load_firmware(sc, &sc->fw_fw) != 0) { device_printf(sc->sc_dev, "could not load firmware\n"); - goto fail2; + goto fail; } - sc->flags |= IPW_FLAG_FW_INITED; /* retrieve information tables base addresses */ @@ -2088,40 +2401,46 @@ ipw_init(void *priv) if (ipw_config(sc) != 0) { device_printf(sc->sc_dev, "device configuration failed\n"); - goto fail1; + goto fail; } + if (ic->ic_opmode != IEEE80211_M_MONITOR) { + /* + * NB: When restarting the adapter clock the state + * machine regardless of the roaming mode; otherwise + * we need to notify user apps so they can manually + * get us going again. + */ + if (ic->ic_roaming != IEEE80211_ROAMING_MANUAL || force) + ieee80211_new_state(ic, IEEE80211_S_SCAN, 0); + } else + ieee80211_new_state(ic, IEEE80211_S_RUN, -1); + + callout_reset(&sc->sc_wdtimer, hz, ipw_watchdog, sc); ifp->if_drv_flags &= ~IFF_DRV_OACTIVE; ifp->if_drv_flags |= IFF_DRV_RUNNING; - sc->flags &=~ IPW_FLAG_INIT_LOCKED; - - if (!owned) - mtx_unlock(&sc->sc_mtx); - + IPW_STATE_END(sc, IPW_FW_LOADING); return; -fail2: firmware_put(fp, FIRMWARE_UNLOAD); - sc->sc_firmware = NULL; -fail1: ifp->if_flags &= ~IFF_UP; - ipw_stop(sc); - sc->flags &=~ IPW_FLAG_INIT_LOCKED; - if (!owned) - mtx_unlock(&sc->sc_mtx); +fail: + ifp->if_flags &= ~IFF_UP; /* XXX */ + IPW_STATE_END(sc, IPW_FW_LOADING); + ipw_stop_locked(sc); + ipw_put_firmware(sc); } static void -ipw_stop(void *priv) +ipw_stop_locked(struct ipw_softc *sc) { - struct ipw_softc *sc = priv; struct ieee80211com *ic = &sc->sc_ic; struct ifnet *ifp = ic->ic_ifp; int i; - mtx_lock(&sc->sc_mtx); - - ieee80211_new_state(ic, IEEE80211_S_INIT, -1); + DPRINTF(("%s: state %s flags 0x%x\n", __func__, + ieee80211_state_name[ic->ic_state], sc->flags)); + callout_stop(&sc->sc_wdtimer); ipw_stop_master(sc); CSR_WRITE_4(sc, IPW_CSR_RST, IPW_RST_SW_RESET); @@ -2132,43 +2451,235 @@ ipw_stop(void *priv) for (i = 0; i < IPW_NTBD; i++) ipw_release_sbd(sc, &sc->stbd_list[i]); - sc->sc_tx_timer = 0; - ifp->if_timer = 0; ifp->if_drv_flags &= ~(IFF_DRV_RUNNING | IFF_DRV_OACTIVE); - mtx_unlock(&sc->sc_mtx); + sc->sc_tx_timer = 0; + sc->sc_rfkill_timer = 0; + sc->sc_state_timer = 0; + sc->flags &= ~(IPW_FLAG_SCANNING | IPW_FLAG_ASSOCIATED); + sc->fw_state = IPW_FW_IDLE; + + ieee80211_new_state(ic, IEEE80211_S_INIT, -1); +} + +static void +ipw_stop(void *priv) +{ + struct ipw_softc *sc = priv; + IPW_LOCK_DECL; + + IPW_LOCK(sc); + ipw_stop_locked(sc); + IPW_UNLOCK(sc); +} + +static void +ipw_restart(void *arg, int pending) +{ + struct ipw_softc *sc = arg; + IPW_LOCK_DECL; + + IPW_LOCK(sc); + ipw_init_locked(sc, 1); /* NB: force state machine */ + IPW_UNLOCK(sc); +} + +static void +ipw_getfw(struct ipw_fw *fw, const char *fwname) +{ + if (fw->fp == NULL) + fw->fp = firmware_get(fwname); } static int -ipw_sysctl_stats(SYSCTL_HANDLER_ARGS) +ipw_get_firmware(struct ipw_softc *sc) { - struct ipw_softc *sc = arg1; - uint32_t i, size, buf[256]; + struct ieee80211com *ic = &sc->sc_ic; + const struct ipw_firmware_hdr *hdr; + const struct firmware *fp; - if (!(sc->flags & IPW_FLAG_FW_INITED)) { - memset(buf, 0, sizeof buf); - return SYSCTL_OUT(req, buf, sizeof buf); + /* invalidate cached firmware on mode change */ + if (sc->fw_mode != ic->ic_opmode) + ipw_put_firmware(sc); + + switch (ic->ic_opmode) { + case IEEE80211_M_STA: + ipw_getfw(&sc->fw_ucode, "ipw_bss"); + break; + case IEEE80211_M_IBSS: + ipw_getfw(&sc->fw_ucode, "ipw_ibss"); + break; + case IEEE80211_M_MONITOR: + ipw_getfw(&sc->fw_ucode, "ipw_monitor"); + break; + default: + break; + } + fp = sc->fw_ucode.fp; + if (fp == NULL) { + device_printf(sc->sc_dev, "could not load firmware\n"); + goto bad; } - CSR_WRITE_4(sc, IPW_CSR_AUTOINC_ADDR, sc->table1_base); + if (fp->datasize < sizeof *hdr) { + device_printf(sc->sc_dev, "firmware image %s too short %zu\n", + fp->name, fp->datasize); + goto bad; + } - size = min(CSR_READ_4(sc, IPW_CSR_AUTOINC_DATA), 256); - for (i = 1; i < size; i++) - buf[i] = MEM_READ_4(sc, CSR_READ_4(sc, IPW_CSR_AUTOINC_DATA)); + hdr = (const struct ipw_firmware_hdr *)fp->data; - return SYSCTL_OUT(req, buf, sizeof buf); + if (fp->datasize < sizeof *hdr + le32toh(hdr->mainsz) + + le32toh(hdr->ucodesz)) { + device_printf(sc->sc_dev, "firmware image %s too short %zu\n", + fp->name, fp->datasize); + goto bad; + } + + sc->fw_fw.fp = fp; /* copy for consistenncy */ + sc->fw_fw.data = (const char *)fp->data + sizeof *hdr; + sc->fw_fw.size = le32toh(hdr->mainsz); + + sc->fw_ucode.data = sc->fw_fw.data + sc->fw_fw.size; + sc->fw_ucode.size = le32toh(hdr->ucodesz); + + sc->fw_mode = ic->ic_opmode; + return 1; +bad: + ipw_put_firmware(sc); + return 0; } +/* + * Release any cached firmware images. + */ +static void +ipw_put_firmware(struct ipw_softc *sc) +{ + struct ipw_fw *fw = &sc->fw_ucode; + + if (fw->fp != NULL) { + firmware_put(fw->fp, FIRMWARE_UNLOAD); + fw->fp = NULL; + } + fw->data = NULL; + fw->size = 0; + + fw = &sc->fw_fw; + fw->fp = NULL; /* NB: no need to put, copy of fw_ucode */ + fw->data = NULL; + fw->size = 0; +} + +/* + * Upload the microcode to the device. + */ static int -ipw_sysctl_radio(SYSCTL_HANDLER_ARGS) +ipw_load_ucode(struct ipw_softc *sc, const struct ipw_fw *fw) { - struct ipw_softc *sc = arg1; - int val; + const char *uc = fw->data; + int size = fw->size; + int ntries; - val = !((sc->flags & IPW_FLAG_HAS_RADIO_SWITCH) && - (CSR_READ_4(sc, IPW_CSR_IO) & IPW_IO_RADIO_DISABLED)); + MEM_WRITE_4(sc, 0x3000e0, 0x80000000); + CSR_WRITE_4(sc, IPW_CSR_RST, 0); - return SYSCTL_OUT(req, &val, sizeof val); + MEM_WRITE_2(sc, 0x220000, 0x0703); + MEM_WRITE_2(sc, 0x220000, 0x0707); + + MEM_WRITE_1(sc, 0x210014, 0x72); + MEM_WRITE_1(sc, 0x210014, 0x72); + + MEM_WRITE_1(sc, 0x210000, 0x40); + MEM_WRITE_1(sc, 0x210000, 0x00); + MEM_WRITE_1(sc, 0x210000, 0x40); + + MEM_WRITE_MULTI_1(sc, 0x210010, uc, size); + + MEM_WRITE_1(sc, 0x210000, 0x00); + MEM_WRITE_1(sc, 0x210000, 0x00); + MEM_WRITE_1(sc, 0x210000, 0x80); + + MEM_WRITE_2(sc, 0x220000, 0x0703); + MEM_WRITE_2(sc, 0x220000, 0x0707); + + MEM_WRITE_1(sc, 0x210014, 0x72); + MEM_WRITE_1(sc, 0x210014, 0x72); + + MEM_WRITE_1(sc, 0x210000, 0x00); + MEM_WRITE_1(sc, 0x210000, 0x80); + + for (ntries = 0; ntries < 10; ntries++) { + if (MEM_READ_1(sc, 0x210000) & 1) + break; + DELAY(10); + } + if (ntries == 10) { + device_printf(sc->sc_dev, + "timeout waiting for %s ucode to initialize\n", + fw->fp->name); + return EIO; + } + + MEM_WRITE_4(sc, 0x3000e0, 0); + + return 0; +} + +/* unalligned little endian access */ +#define LE_READ_2(p) \ + ((u_int16_t) \ + ((((const u_int8_t *)(p))[0] ) | \ + (((const u_int8_t *)(p))[1] << 8))) +#define LE_READ_4(p) \ + ((u_int32_t) \ + ((((const u_int8_t *)(p))[0] ) | \ + (((const u_int8_t *)(p))[1] << 8) | \ + (((const u_int8_t *)(p))[2] << 16) | \ + (((const u_int8_t *)(p))[3] << 24))) + +static int +ipw_load_firmware(struct ipw_softc *sc, const struct ipw_fw *fw) +{ + const uint8_t *p, *end; + uint32_t tmp, dst; + uint16_t len; + int error; + + p = fw->data; + end = fw->data + fw->size; + while (p < end) { + dst = LE_READ_4(p); p += 4; + len = LE_READ_2(p); p += 2; + + ipw_write_mem_1(sc, dst, p, len); + p += len; + } + + CSR_WRITE_4(sc, IPW_CSR_IO, IPW_IO_GPIO1_ENABLE | IPW_IO_GPIO3_MASK | + IPW_IO_LED_OFF); + + /* enable interrupts */ + CSR_WRITE_4(sc, IPW_CSR_INTR_MASK, IPW_INTR_MASK); + + /* kick the firmware */ + CSR_WRITE_4(sc, IPW_CSR_RST, 0); + + tmp = CSR_READ_4(sc, IPW_CSR_CTL); + CSR_WRITE_4(sc, IPW_CSR_CTL, tmp | IPW_CTL_ALLOW_STANDBY); + + /* wait at most one second for firmware initialization to complete */ + if ((error = msleep(sc, &sc->sc_mtx, 0, "ipwinit", hz)) != 0) { + device_printf(sc->sc_dev, "timeout waiting for %s firmware " + "initialization to complete\n", fw->fp->name); + return error; + } + + tmp = CSR_READ_4(sc, IPW_CSR_IO); + CSR_WRITE_4(sc, IPW_CSR_IO, tmp | IPW_IO_GPIO1_MASK | + IPW_IO_GPIO3_MASK); + + return 0; } static uint32_t @@ -2183,6 +2694,7 @@ ipw_write_table1(struct ipw_softc *sc, u MEM_WRITE_4(sc, MEM_READ_4(sc, sc->table1_base + off), info); } +#if 0 static int ipw_read_table2(struct ipw_softc *sc, uint32_t off, void *buf, uint32_t *len) { @@ -2218,6 +2730,7 @@ ipw_read_mem_1(struct ipw_softc *sc, bus *datap = CSR_READ_1(sc, IPW_CSR_INDIRECT_DATA + (offset & 3)); } } +#endif static void ipw_write_mem_1(struct ipw_softc *sc, bus_size_t offset, const uint8_t *datap, @@ -2228,3 +2741,278 @@ ipw_write_mem_1(struct ipw_softc *sc, bu CSR_WRITE_1(sc, IPW_CSR_INDIRECT_DATA + (offset & 3), *datap); } } + +static void +ipw_ops(void *arg, int npending) +{ + struct ipw_softc *sc = arg; + struct ieee80211com *ic = &sc->sc_ic; + IPW_LOCK_DECL; + int cmd; + +again: + IPW_CMD_LOCK(sc); + cmd = sc->sc_cmd[sc->sc_cmd_cur]; + if (cmd == 0) { + /* No more commands to process */ + IPW_CMD_UNLOCK(sc); + return; + } + sc->sc_cmd[sc->sc_cmd_cur] = 0; /* free the slot */ + sc->sc_cmd_cur = (sc->sc_cmd_cur + 1) % IPW_CMD_MAXOPS; + IPW_CMD_UNLOCK(sc); + + IPW_LOCK(sc); + while (sc->fw_state != IPW_FW_IDLE || (sc->flags & IPW_FLAG_BUSY)) { + msleep(sc, &sc->sc_mtx, 0, "ipwcmd", hz/10); + } + + if (!(sc->sc_ifp->if_drv_flags & IFF_DRV_RUNNING)) { + IPW_UNLOCK(sc); + return; + } + + switch (cmd) { + case IPW_ASSOC: + ipw_auth_and_assoc(sc); + break; + case IPW_DISASSOC: + ipw_disassociate(sc); + break; + case IPW_SCAN_START: + if (ipw_scan(sc) != 0) { + /* XXX should not happen */ + ieee80211_new_state(ic, IEEE80211_S_INIT, 0); + } + break; + } + IPW_UNLOCK(sc); + + /* Take another pass */ + goto again; +} + +static int +ipw_queue_cmd(struct ipw_softc *sc, int cmd) +{ + IPW_CMD_LOCK(sc); + if (sc->sc_cmd[sc->sc_cmd_next] != 0) { + IPW_CMD_UNLOCK(sc); + DPRINTF(("%s: command %d dropped\n", __func__, cmd)); + return (EBUSY); + } + + sc->sc_cmd[sc->sc_cmd_next] = cmd; + sc->sc_cmd_next = (sc->sc_cmd_next + 1) % IPW_CMD_MAXOPS; + taskqueue_enqueue(sc->sc_tq, &sc->sc_opstask); + IPW_CMD_UNLOCK(sc); + return (0); +} + +static void +ipw_scan_start(struct ieee80211com *ic) +{ + struct ifnet *ifp = ic->ic_ifp; + struct ipw_softc *sc = ifp->if_softc; + + device_printf(sc->sc_dev, "%s\n", __func__); + ipw_queue_cmd(sc, IPW_SCAN_START); +} + +static void +ipw_set_channel(struct ieee80211com *ic) +{ + struct ifnet *ifp = ic->ic_ifp; + struct ipw_softc *sc = ifp->if_softc; + + device_printf(sc->sc_dev, "%s\n", __func__); +} + +static void +ipw_scan_curchan(struct ieee80211com *ic, unsigned long maxdwell) +{ + struct ifnet *ifp = ic->ic_ifp; + struct ipw_softc *sc = ifp->if_softc; + + device_printf(sc->sc_dev, "%s\n", __func__); +} + +static void +ipw_scan_mindwell(struct ieee80211com *ic) +{ + /* NB: don't try to abort scan; wait for firmware to finish */ +} + +static void +ipw_scan_end(struct ieee80211com *ic) +{ + struct ifnet *ifp = ic->ic_ifp; + struct ipw_softc *sc = ifp->if_softc; + + device_printf(sc->sc_dev, "%s\n", __func__); +} + +static void +ipw_assoc(struct ieee80211com *ic) +{ + struct ifnet *ifp = ic->ic_ifp; + struct ipw_softc *sc = ifp->if_softc; + + /* The firmware will fail if we are already associated */ + if (sc->flags & IPW_FLAG_ASSOCIATED) + ipw_disassoc(ic); + + ipw_queue_cmd(sc, IPW_ASSOC); +} + +static void +ipw_disassoc(struct ieee80211com *ic) +{ + struct ifnet *ifp = ic->ic_ifp; + struct ipw_softc *sc = ifp->if_softc; + + ipw_queue_cmd(sc, IPW_DISASSOC); +} + +/* + * Read 16 bits at address 'addr' from the serial EEPROM. + */ +static uint16_t +ipw_read_prom_word(struct ipw_softc *sc, uint8_t addr) +{ + uint32_t tmp; + uint16_t val; + int n; + + /* clock C once before the first command */ + IPW_EEPROM_CTL(sc, 0); + IPW_EEPROM_CTL(sc, IPW_EEPROM_S); + IPW_EEPROM_CTL(sc, IPW_EEPROM_S | IPW_EEPROM_C); + IPW_EEPROM_CTL(sc, IPW_EEPROM_S); + + /* write start bit (1) */ + IPW_EEPROM_CTL(sc, IPW_EEPROM_S | IPW_EEPROM_D); + IPW_EEPROM_CTL(sc, IPW_EEPROM_S | IPW_EEPROM_D | IPW_EEPROM_C); + + /* write READ opcode (10) */ + IPW_EEPROM_CTL(sc, IPW_EEPROM_S | IPW_EEPROM_D); + IPW_EEPROM_CTL(sc, IPW_EEPROM_S | IPW_EEPROM_D | IPW_EEPROM_C); + IPW_EEPROM_CTL(sc, IPW_EEPROM_S); + IPW_EEPROM_CTL(sc, IPW_EEPROM_S | IPW_EEPROM_C); + + /* write address A7-A0 */ + for (n = 7; n >= 0; n--) { + IPW_EEPROM_CTL(sc, IPW_EEPROM_S | + (((addr >> n) & 1) << IPW_EEPROM_SHIFT_D)); + IPW_EEPROM_CTL(sc, IPW_EEPROM_S | + (((addr >> n) & 1) << IPW_EEPROM_SHIFT_D) | IPW_EEPROM_C); + } + + IPW_EEPROM_CTL(sc, IPW_EEPROM_S); + + /* read data Q15-Q0 */ + val = 0; + for (n = 15; n >= 0; n--) { + IPW_EEPROM_CTL(sc, IPW_EEPROM_S | IPW_EEPROM_C); + IPW_EEPROM_CTL(sc, IPW_EEPROM_S); + tmp = MEM_READ_4(sc, IPW_MEM_EEPROM_CTL); + val |= ((tmp & IPW_EEPROM_Q) >> IPW_EEPROM_SHIFT_Q) << n; + } + + IPW_EEPROM_CTL(sc, 0); + + /* clear Chip Select and clock C */ + IPW_EEPROM_CTL(sc, IPW_EEPROM_S); + IPW_EEPROM_CTL(sc, 0); + IPW_EEPROM_CTL(sc, IPW_EEPROM_C); + + return le16toh(val); +} + +/* + * Return whether or not the radio is enabled in hardware + * (i.e. the rfkill switch is "off"). + */ +static int +ipw_getrfkill(struct ipw_softc *sc) +{ + return (sc->flags & IPW_FLAG_HAS_RFSWITCH) && + (CSR_READ_4(sc, IPW_CSR_IO) & IPW_IO_RADIO_DISABLED) != 0; +} + +static void +ipw_radio_on(void *arg, int pending) +{ + struct ipw_softc *sc = arg; + + device_printf(sc->sc_dev, "radio turned on\n"); + ipw_init(sc); +} + +static void +ipw_radio_off(void *arg, int pending) +{ + struct ipw_softc *sc = arg; + IPW_LOCK_DECL; + + device_printf(sc->sc_dev, "radio turned off\n"); + IPW_LOCK(sc); + ipw_stop_locked(sc); + sc->sc_rfkill_timer = 2; + IPW_UNLOCK(sc); +} + +static int +ipw_sysctl_radio(SYSCTL_HANDLER_ARGS) +{ + struct ipw_softc *sc = arg1; + int val = !ipw_getrfkill(sc); + + return SYSCTL_OUT(req, &val, sizeof val); +} + +static int +ipw_sysctl_stats(SYSCTL_HANDLER_ARGS) +{ + struct ipw_softc *sc = arg1; + uint32_t i, size, buf[256]; + IPW_LOCK_DECL; + + memset(buf, 0, sizeof(buf)); + IPW_LOCK(sc); + if (sc->flags & IPW_FLAG_FW_INITED) { + CSR_WRITE_4(sc, IPW_CSR_AUTOINC_ADDR, sc->table1_base); + + size = min(CSR_READ_4(sc, IPW_CSR_AUTOINC_DATA), 256); + for (i = 1; i < size; i++) + buf[i] = MEM_READ_4(sc, + CSR_READ_4(sc, IPW_CSR_AUTOINC_DATA)); + } + IPW_UNLOCK(sc); + return SYSCTL_OUT(req, buf, sizeof buf); +} + +/* + * Add sysctl knobs. + */ +static void +ipw_sysctlattach(struct ipw_softc *sc) +{ + struct sysctl_ctx_list *ctx = device_get_sysctl_ctx(sc->sc_dev); + struct sysctl_oid *tree = device_get_sysctl_tree(sc->sc_dev); + + SYSCTL_ADD_PROC(ctx, SYSCTL_CHILDREN(tree), OID_AUTO, "radio", + CTLTYPE_INT | CTLFLAG_RD, sc, 0, ipw_sysctl_radio, "I", + "radio transmitter switch state (0=off, 1=on)"); + + SYSCTL_ADD_PROC(ctx, SYSCTL_CHILDREN(tree), OID_AUTO, "stats", + CTLTYPE_OPAQUE | CTLFLAG_RD, sc, 0, ipw_sysctl_stats, "S", + "statistics"); +#if 0 + /* XXX not implemented (yet) */ + sc->dwelltime = 100; + SYSCTL_ADD_INT(ctx, SYSCTL_CHILDREN(tree), OID_AUTO, "dwell", + CTLFLAG_RW, &sc->dwelltime, 0, + "channel dwell time (ms) for AP/station scanning"); +#endif +} Index: if_ipwreg.h =================================================================== RCS file: /home/ncvs/src/sys/dev/ipw/if_ipwreg.h,v retrieving revision 1.2 diff -u -p -r1.2 if_ipwreg.h --- if_ipwreg.h 12 Mar 2006 19:01:00 -0000 1.2 +++ if_ipwreg.h 11 Aug 2006 03:34:45 -0000 @@ -88,11 +88,18 @@ #define IPW_IO_LED_OFF 0x00002000 #define IPW_IO_RADIO_DISABLED 0x00010000 +/* state codes sent by fw on IPW_STATUS_CODE_NEWSTATE interrupt */ +#define IPW_STATE_INITIALIZED 0x0001 +#define IPW_STATE_CC_FOUND 0x0002 /* 802.11d cc received */ #define IPW_STATE_ASSOCIATED 0x0004 #define IPW_STATE_ASSOCIATION_LOST 0x0008 +#define IPW_STATE_ASSOCIATION_CHANGED 0x0010 /* assoc params changed? */ #define IPW_STATE_SCAN_COMPLETE 0x0020 -#define IPW_STATE_RADIO_DISABLED 0x0100 +#define IPW_STATE_PS_ENTER 0x0040 /* entered power-save mode */ +#define IPW_STATE_PS_EXIT 0x0080 /* exited power-save mode */ +#define IPW_STATE_RADIO_OFF 0x0100 /* radio switch toggled */ #define IPW_STATE_DISABLED 0x0200 +#define IPW_STATE_POWER_DOWN 0x0400 /* ??? */ #define IPW_STATE_SCANNING 0x0800 /* table1 offsets */ @@ -136,7 +143,7 @@ struct ipw_bd { /* status */ struct ipw_status { - uint32_t len; + uint32_t len; /* frame size */ uint16_t code; #define IPW_STATUS_CODE_COMMAND 0 #define IPW_STATUS_CODE_NEWSTATE 1 @@ -146,7 +153,9 @@ struct ipw_status { uint8_t flags; #define IPW_STATUS_FLAG_DECRYPTED 0x01 #define IPW_STATUS_FLAG_WEP_ENCRYPTED 0x02 +#define IPW_STATUS_FLAG_CRC_ERROR 0x04 uint8_t rssi; /* received signal strength indicator */ +#define IPW_RSSI_TO_DBM (-98) /* XXX fixed nf to convert dBm */ } __packed; /* data header */ @@ -190,9 +199,14 @@ struct ipw_cmd { #define IPW_CMD_DISABLE 44 #define IPW_CMD_SET_DESIRED_BSSID 45 #define IPW_CMD_SET_SCAN_OPTIONS 46 +#define IPW_CMD_SET_SCAN_DWELL_TIME 47 +#define IPW_CMD_SET_SHORT_RETRY 51 +#define IPW_CMD_SET_LONG_RETRY 52 #define IPW_CMD_PREPARE_POWER_DOWN 58 #define IPW_CMD_DISABLE_PHY 61 -#define IPW_CMD_SET_SECURITY_INFORMATION 67 +#define IPW_CMD_SET_MSDU_TX_RATES 62 +#define IPW_CMD_SET_SECURITY_INFO 67 +#define IPW_CMD_DISASSOCIATE 68 #define IPW_CMD_SET_WPA_IE 69 uint32_t subtype; uint32_t seq; @@ -204,7 +218,7 @@ struct ipw_cmd { /* possible values for command IPW_CMD_SET_POWER_MODE */ #define IPW_POWER_MODE_CAM 0 -#define IPW_POWER_AUTOMATIC 6 +#define IPW_POWER_MODE_AUTO 6 /* possible values for command IPW_CMD_SET_MODE */ #define IPW_MODE_BSS 0 @@ -240,9 +254,10 @@ struct ipw_security { /* structure for command IPW_CMD_SET_SCAN_OPTIONS */ struct ipw_scan_options { uint32_t flags; -#define IPW_SCAN_DO_NOT_ASSOCIATE 0x00000001 +#define IPW_SCAN_DO_NOT_ASSOCIATE 0x00000001 /* XXX broken */ +#define IPW_SCAN_MIXED_CELL 0x00000002 #define IPW_SCAN_PASSIVE 0x00000008 - uint32_t channels; + uint32_t chanmask; } __packed; /* structure for command IPW_CMD_SET_CONFIGURATION */ @@ -264,7 +279,7 @@ struct ipw_wpa_ie { uint16_t capinfo; uint16_t lintval; uint8_t bssid[IEEE80211_ADDR_LEN]; - uint32_t len; + uint32_t ielen; struct ieee80211_ie_wpa ie; } __packed; Index: if_ipwvar.h =================================================================== RCS file: /home/ncvs/src/sys/dev/ipw/if_ipwvar.h,v retrieving revision 1.6 diff -u -p -r1.6 if_ipwvar.h --- if_ipwvar.h 15 Feb 2007 17:21:30 -0000 1.6 +++ if_ipwvar.h 12 Jul 2007 09:24:11 -0000 @@ -1,5 +1,3 @@ -/* $FreeBSD: src/sys/dev/ipw/if_ipwvar.h,v 1.6 2007/02/15 17:21:30 luigi Exp $ */ - /*- * Copyright (c) 2004-2006 * Damien Bergamini . All rights reserved. @@ -25,6 +23,8 @@ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. + * + * $FreeBSD: src/sys/dev/ipw/if_ipwvar.h,v 1.4 2006/03/12 19:01:00 damien Exp $ */ #define IPW_MAX_NSEG 1 @@ -63,7 +63,7 @@ struct ipw_rx_radiotap_header { #define IPW_RX_RADIOTAP_PRESENT \ ((1 << IEEE80211_RADIOTAP_FLAGS) | \ (1 << IEEE80211_RADIOTAP_CHANNEL) | \ - (1 << IEEE80211_RADIOTAP_DB_ANTSIGNAL)) + (1 << IEEE80211_RADIOTAP_DBM_ANTSIGNAL)) struct ipw_tx_radiotap_header { struct ieee80211_radiotap_header wt_ihdr; @@ -76,87 +76,170 @@ struct ipw_tx_radiotap_header { ((1 << IEEE80211_RADIOTAP_FLAGS) | \ (1 << IEEE80211_RADIOTAP_CHANNEL)) -struct ipw_softc { - struct ifnet *sc_ifp; - struct ieee80211com sc_ic; - int (*sc_newstate)(struct ieee80211com *, - enum ieee80211_state, int); - device_t sc_dev; - - struct mtx sc_mtx; - struct task sc_init_task; - - uint32_t flags; -#define IPW_FLAG_FW_INITED (1 << 0) -#define IPW_FLAG_INIT_LOCKED (1 << 1) -#define IPW_FLAG_HAS_RADIO_SWITCH (1 << 2) -#define IPW_FLAG_FW_WARNED (1 << 3) - - int irq_rid; - int mem_rid; - struct resource *irq; - struct resource *mem; - bus_space_tag_t sc_st; - bus_space_handle_t sc_sh; - void *sc_ih; - const struct firmware *sc_firmware; - - int sc_tx_timer; - - bus_dma_tag_t tbd_dmat; - bus_dma_tag_t rbd_dmat; - bus_dma_tag_t status_dmat; - bus_dma_tag_t cmd_dmat; - bus_dma_tag_t hdr_dmat; - bus_dma_tag_t txbuf_dmat; - bus_dma_tag_t rxbuf_dmat; - - bus_dmamap_t tbd_map; - bus_dmamap_t rbd_map; - bus_dmamap_t status_map; - bus_dmamap_t cmd_map; - - bus_addr_t tbd_phys; - bus_addr_t rbd_phys; - bus_addr_t status_phys; - - struct ipw_bd *tbd_list; - struct ipw_bd *rbd_list; - struct ipw_status *status_list; - - struct ipw_cmd cmd; - struct ipw_soft_bd stbd_list[IPW_NTBD]; - struct ipw_soft_buf tx_sbuf_list[IPW_NDATA]; - struct ipw_soft_hdr shdr_list[IPW_NDATA]; - struct ipw_soft_bd srbd_list[IPW_NRBD]; - struct ipw_soft_buf rx_sbuf_list[IPW_NRBD]; - - SLIST_HEAD(, ipw_soft_hdr) free_shdr; - SLIST_HEAD(, ipw_soft_buf) free_sbuf; - - uint32_t table1_base; - uint32_t table2_base; - - uint32_t txcur; - uint32_t txold; - uint32_t rxcur; - int txfree; - - int dwelltime; +struct ipw_fw { + const struct firmware *fp; /* image handle */ + const char *data; /* firmware image data */ + size_t size; /* firmware image size */ +}; - struct bpf_if *sc_drvbpf; +struct ipw_softc { + struct ifnet *sc_ifp; + struct ieee80211com sc_ic; + int (*sc_newstate)(struct ieee80211com *, + enum ieee80211_state, int); + device_t sc_dev; + + struct mtx sc_mtx; + struct mtx sc_cmdlock; + char sc_cmdname[12]; /* e.g. "ipw0_cmd" */ + struct taskqueue *sc_tq; /* private task queue */ +#if __FreeBSD_version < 700000 + struct proc *sc_tqproc; +#endif + struct task sc_opstask; + struct task sc_radiontask; /* radio on processing */ + struct task sc_radiofftask; /* radio off processing */ + struct task sc_assoclosttask;/* assoc lost processing */ + struct task sc_restarttask; /* restart adapter processing */ + struct callout sc_wdtimer; /* watchdog timer */ + + uint32_t flags; +#define IPW_FLAG_FW_INITED 0x00000002 /* firmware initialized */ +#define IPW_FLAG_SCANNING 0x00000004 /* busy scanning */ +#define IPW_FLAG_BUSY 0x00000008 /* busy sending a command */ +#define IPW_FLAG_ASSOCIATED 0x00000010 /* currently associated */ +#define IPW_FLAG_ENABLED 0x00000020 /* adapter enabled */ +#define IPW_FLAG_HAS_RFSWITCH 0x00010000 /* rfkill switch present */ +#define IPW_FLAG_HACK 0x00020000 + uint32_t fw_state; +#define IPW_FW_IDLE 0 +#define IPW_FW_LOADING 1 +#define IPW_FW_ASSOCIATING 2 +#define IPW_FW_DISASSOCIATING 3 +#define IPW_FW_SCANNING 4 + + int irq_rid; + int mem_rid; + struct resource *irq; + struct resource *mem; + bus_space_tag_t sc_st; + bus_space_handle_t sc_sh; + void *sc_ih; + + enum ieee80211_opmode fw_mode; /* mode of current firmware */ + struct ipw_fw fw_ucode; /* cached microcode */ + struct ipw_fw fw_fw; /* cached firmware */ + + bus_dma_tag_t tbd_dmat; + bus_dma_tag_t rbd_dmat; + bus_dma_tag_t status_dmat; + bus_dma_tag_t cmd_dmat; + bus_dma_tag_t hdr_dmat; + bus_dma_tag_t txbuf_dmat; + bus_dma_tag_t rxbuf_dmat; + + bus_dmamap_t tbd_map; + bus_dmamap_t rbd_map; + bus_dmamap_t status_map; + bus_dmamap_t cmd_map; + + bus_addr_t tbd_phys; + bus_addr_t rbd_phys; + bus_addr_t status_phys; + + struct ipw_bd *tbd_list; + struct ipw_bd *rbd_list; + struct ipw_status *status_list; + + struct ipw_cmd cmd; + struct ipw_soft_bd stbd_list[IPW_NTBD]; + struct ipw_soft_buf tx_sbuf_list[IPW_NDATA]; + struct ipw_soft_hdr shdr_list[IPW_NDATA]; + struct ipw_soft_bd srbd_list[IPW_NRBD]; + struct ipw_soft_buf rx_sbuf_list[IPW_NRBD]; + + SLIST_HEAD(, ipw_soft_hdr) free_shdr; + SLIST_HEAD(, ipw_soft_buf) free_sbuf; + + uint32_t table1_base; + uint32_t table2_base; + + uint32_t txcur; + uint32_t txold; + uint32_t rxcur; + int txfree; + + int chanmask; /* supported channels */ + int dwelltime; + + int sc_tx_timer; + int sc_rfkill_timer;/* poll for rfkill change */ + int sc_state_timer; + +#define IPW_SCAN_START (1 << 0) +#define IPW_SET_CHANNEL (1 << 1) +#define IPW_ASSOC (1 << 2) +#define IPW_DISASSOC (1 << 3) +#define IPW_CMD_MAXOPS 10 + int sc_cmd[IPW_CMD_MAXOPS]; + int sc_cmd_cur; /* current queued scan task */ + int sc_cmd_next; /* last queued scan task */ + struct bpf_if *sc_drvbpf; union { struct ipw_rx_radiotap_header th; uint8_t pad[64]; } sc_rxtapu; #define sc_rxtap sc_rxtapu.th - int sc_rxtap_len; + int sc_rxtap_len; union { struct ipw_tx_radiotap_header th; uint8_t pad[64]; } sc_txtapu; #define sc_txtap sc_txtapu.th - int sc_txtap_len; + int sc_txtap_len; }; + +#define IPW_STATE_BEGIN(_sc, _state) do { \ + KASSERT(_sc->fw_state == IPW_FW_IDLE, \ + ("ipw firmware not idle")); \ + _sc->fw_state = _state; \ + _sc->sc_state_timer = 5; \ + DPRINTF(("enter FW state %d\n", _state)); \ +} while (0) + +#define IPW_STATE_END(_sc, _state) do { \ + if (_sc->fw_state == _state) \ + DPRINTF(("exit FW state %d\n", _state)); \ + else \ + DPRINTF(("expected FW state %d, got %d\n", \ + _state, _sc->fw_state)); \ + _sc->fw_state = IPW_FW_IDLE; \ + wakeup(_sc); \ + _sc->sc_state_timer = 0; \ +} while (0) + +/* + * NB.: This models the only instance of async locking in ipw_init_locked + * and must be kept in sync. + */ +#define IPW_LOCK_DECL int __waslocked = 0 +#define IPW_LOCK(sc) do { \ + if (!(__waslocked = mtx_owned(&(sc)->sc_mtx))) \ + mtx_lock(&sc->sc_mtx); \ +} while (0) +#define IPW_UNLOCK(sc) do { \ + if (!__waslocked) \ + mtx_unlock(&sc->sc_mtx); \ +} while (0) +#define IPW_LOCK_ASSERT(sc) mtx_assert(&(sc)->sc_mtx, MA_OWNED) +#define IPW_CMD_LOCK_INIT(sc) do { \ + snprintf((sc)->sc_cmdname, sizeof((sc)->sc_cmdname), "%s_cmd", \ + device_get_nameunit((sc)->sc_dev)); \ + mtx_init(&(sc)->sc_cmdlock, (sc)->sc_cmdname, NULL, MTX_DEF); \ +} while (0) +#define IPW_CMD_LOCK_DESTROY(sc) mtx_destroy(&(sc)->sc_cmdlock) +#define IPW_CMD_LOCK(sc) mtx_lock(&(sc)->sc_cmdlock) +#define IPW_CMD_UNLOCK(sc) mtx_unlock(&(sc)->sc_cmdlock) + --BOKacYhQ+x31HxR3-- From owner-freebsd-current@FreeBSD.ORG Mon Jul 23 12:29:08 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 6E7DA16A41F for ; Mon, 23 Jul 2007 12:29:08 +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 326AB13C46B for ; Mon, 23 Jul 2007 12:29:08 +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 l6NCT06C029547 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Jul 2007 08:29:00 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.12.9p2/8.12.9/Submit) id l6NCSWja092693; Mon, 23 Jul 2007 08:28:32 -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: <18084.40711.665845.826349@grasshopper.cs.duke.edu> Date: Mon, 23 Jul 2007 08:28:32 -0400 (EDT) To: Rui Paulo In-Reply-To: <46A37B6B.2050901@fnop.net> References: <18082.16126.915890.401438@grasshopper.cs.duke.edu> <46A37B6B.2050901@fnop.net> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Cc: current@freebsd.org Subject: Re: 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: Mon, 23 Jul 2007 12:29:08 -0000 Rui Paulo writes: > > 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? > > As a workaround try using a 6.2 CD. > > On a somewhat related note, how well does FreeBSD even work on > > an iMac? Can we suspend/resume SMP machines yet? > > No. Argh. Screwed at every turn. As it turns out, I can't even make my machine boot a "legacy" OS from a firewire disk. Both FreeBSD and Ubuntu lead to a "no bootable device" error when booting directly, and rEFIt also fails (with some interesting comments regarding how apple's firmware does not deal well with booting a legacy OS from firwewire). I ran out of time before I could shuffle MacOSX to the external drive to free up the internal one for FreeBSD. Oh well, back to MacOSX and dealing with X crashing every few weeks. Drew From owner-freebsd-current@FreeBSD.ORG Mon Jul 23 13:06:56 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 6BF7616A41F for ; Mon, 23 Jul 2007 13:06:56 +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 E3BCA13C45B for ; Mon, 23 Jul 2007 13:06:55 +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 l6ND6j1A037251 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Jul 2007 17:06:45 +0400 (MSD) (envelope-from oleg@lath.rinet.ru) Received: (from oleg@localhost) by lath.rinet.ru (8.14.1/8.14.1/Submit) id l6ND6jR8037250; Mon, 23 Jul 2007 17:06:45 +0400 (MSD) (envelope-from oleg) Date: Mon, 23 Jul 2007 17:06:45 +0400 From: Oleg Bulyzhin To: Jeff Roberson Message-ID: <20070723130645.GA37207@lath.rinet.ru> References: <20070721174631.S561@10.0.0.1> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+HP7ph2BbKc20aGI" Content-Disposition: inline In-Reply-To: <20070721174631.S561@10.0.0.1> User-Agent: Mutt/1.5.15 (2007-04-06) Cc: current@freebsd.org Subject: Re: ULE status, invalid load, buildkernel 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, 23 Jul 2007 13:06:56 -0000 --+HP7ph2BbKc20aGI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jul 21, 2007 at 05:55:08PM -0700, Jeff Roberson wrote: > I have a patch available at: >=20 > http://people.freebsd.org/~jeff/ulehtt.diff >=20 JFYI: with this patch my workstation works fine. load average became normal. --=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 --+HP7ph2BbKc20aGI Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGpKfkryLc73jOEF8RAkXKAJ40mqbNw5W7TBDCLu84QyGW4v/KBQCePpaj uByeMnqu4QY0mjPrDkYve5Y= =Q9ps -----END PGP SIGNATURE----- --+HP7ph2BbKc20aGI-- From owner-freebsd-current@FreeBSD.ORG Mon Jul 23 13:43:52 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 4F69516A41A; Mon, 23 Jul 2007 13:43:52 +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 273AB13C4B5; Mon, 23 Jul 2007 13:43:52 +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 l6NDhpND025865; Mon, 23 Jul 2007 08:43:51 -0500 (CDT) (envelope-from kramer@centtech.com) Message-ID: <46A4B0A8.90805@centtech.com> Date: Mon, 23 Jul 2007 08:44:08 -0500 From: Kevin Kramer User-Agent: Thunderbird 2.0.0.4 (X11/20070718) MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <469E3B7C.4020402@centtech.com> <20070722001514.GB1221@funkthat.com> <46A3CBCE.3000300@freebsd.org> <20070723011058.GB99491@funkthat.com> In-Reply-To: <20070723011058.GB99491@funkthat.com> X-Virus-Scanned: ClamAV 0.88.4/3742/Mon Jul 23 06:31:24 2007 on mh1.centtech.com X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=8.0 tests=BAYES_00,HTML_MESSAGE autolearn=ham version=3.1.6 X-Spam-Checker-Version: SpamAssassin 3.1.6 (2006-10-03) on mh1.centtech.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: 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: Mon, 23 Jul 2007 13:43:52 -0000 that was it. I had a nisdomain set in my rc.conf, but no client configuration lines. I've commented it all out and all is well. thanks. _________________________________________________ Kevin Kramer Sr. Systems Administrator Centaur Technology, Inc. Office: 512-418-5725 Cell : 512-470-7671 http://www.centtech.com _________________________________________________ John-Mark Gurney wrote the following on 07/22/07 20:10: > Eric Anderson wrote this message on Sun, Jul 22, 2007 at 16:27 -0500: > >> John-Mark Gurney wrote: >> >>> kevin kramer wrote this message on Wed, Jul 18, 2007 at 11:10 -0500: >>> >>>> 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? >>>> >>> running the process under ktrace would help identify what it is waiting >>> for... Though if it usually hangs for a minute or two in kqread, and >>> then continues, it's probably a DNS lookup issue... >>> >>> >> You mean like the one he put here: >> >> http://users.centtech.com/~kramer/snapshot/top-trace.txt >> > > /me needs to read closer. > > Thought it might be a yp issue: > 84667 top 0.005085 CALL open(0x7fffffffdd00,O_RDONLY,0x1e) > 84667 top 0.005091 NAMI "/var/yp/binding/centtech.com.2" > 84667 top 0.005105 RET open -1 errno 2 No such file or directory > [...] > 84667 top 0.005461 CALL socket(PF_INET,SOCK_DGRAM,IPPROTO_UDP) > 84667 top 0.005468 RET socket 5 > [...] > 84667 top 0.005533 CALL bind(0x5,0x7fffffffda10,0x10) > 84667 top 0.005542 RET bind 0 > [...] > 84667 top 0.006028 CALL sendto(0x5,0x800c11ac4,0x38,0,0x800c11808,0x10) > > >> 84667 top 0.006110 RET sendto 56/0x38 >> 84667 top 0.006128 CALL >> kevent(0x6,0x800c11910,0x1,0x7fffffffdad0,0x1,0x7fffffffdb10) >> 84667 top 5.008057 GIO fd 6 wrote 32 bytes >> 0x0000 0500 0000 0000 0000 ffff 0100 0000 0000 0000 0000 0000 >> 0000 0000 0000 0000 0000 >> |................................| >> >> 84667 top 5.008073 GIO fd 6 read 0 bytes >> "" >> 84667 top 5.008078 RET kevent 0 >> 84667 top 5.008086 CALL gettimeofday(0x7fffffffdb20,0) >> 84667 top 5.008091 RET gettimeofday 0 >> 84667 top 5.008096 CALL >> sendto(0x5,0x800c11ac4,0x38,0,0x800c11808,0x10) >> 84667 top 5.008139 GIO fd 5 wrote 56 bytes >> 0x0000 4696 2a64 0000 0000 0000 0002 0001 86a0 0000 0002 0000 >> 0003 0000 0000 0000 0000 0000 0000 0000 0000 >> |F.*d....................................| >> 0x0028 0001 86a7 0000 0002 0000 0006 0000 0000 >> |................| >> >> 84667 top 5.008155 RET sendto 56/0x38 >> 84667 top 5.008163 CALL >> kevent(0x6,0x800c11910,0,0x7fffffffdad0,0x1,0x7fffffffdb10) >> 84667 top 15.007883 GIO fd 6 wrote 0 bytes >> "" >> > > Looks like it's trying to contact the yp server and isn't getting a > response... Check your user/host name lookup... > > From owner-freebsd-current@FreeBSD.ORG Mon Jul 23 14:02:56 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 79C3816A418 for ; Mon, 23 Jul 2007 14:02:56 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.freebsd.org (Postfix) with ESMTP id 11BA113C45D for ; Mon, 23 Jul 2007 14:02:55 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 078C648811; Mon, 23 Jul 2007 15:34:09 +0200 (CEST) Received: from localhost (154.81.datacomsa.pl [195.34.81.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id B405245B26; Mon, 23 Jul 2007 15:34:02 +0200 (CEST) Date: Mon, 23 Jul 2007 15:33:33 +0200 From: Pawel Jakub Dawidek To: Boris Samorodov Message-ID: <20070723133333.GF5456@garage.freebsd.pl> References: <97732929@srv.sem.ipt.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/Zw+/jwnNHcBRYYu" Content-Disposition: inline In-Reply-To: <97732929@srv.sem.ipt.ru> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-2.6 required=3.0 tests=BAYES_00 autolearn=ham version=3.0.4 Cc: freebsd-current@FreeBSD.org Subject: Re: mount_nullfs inside a jail X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Jul 2007 14:02:56 -0000 --/Zw+/jwnNHcBRYYu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jul 22, 2007 at 04:18:06AM +0400, Boris Samorodov wrote: > Hi! >=20 >=20 > Is it possible to use mount_nullfs inside a jail? >=20 > With amd64-current: > ----- > # sysctl security.jail > security.jail.jailed: 1 > security.jail.mount_allowed: 1 > security.jail.chflags_allowed: 1 > security.jail.allow_raw_sockets: 0 > security.jail.enforce_statfs: 2 > security.jail.sysvipc_allowed: 1 > security.jail.socket_unixiproute_only: 1 > security.jail.set_hostname_allowed: 1 > # mount_nullfs /usr/ports /mnt > mount_nullfs: Operation not permitted > ----- It is not possible. From jail(8): security.jail.mount_allowed This MIB entry determines if a privileged user inside a jail will= be able to mount and unmount file system types marked as jail-friend= ly. The lsvfs(1) command can be used to find file system types availa= ble for mount from within a jail. This functionality is disabled by default, but can be enabled by setting this MIB entry to 1. # lsvfs Filesystem Refs Flags -------------------------------- ----- --------------- zfs 0 jail nullfs 0 loopback As you can see, nullfs doesn't have 'jail' flag. The only jail-friendly file system currently is ZFS. Nullfs is a good candidate for a jail-friendly file system, but is not marked as such yet. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --/Zw+/jwnNHcBRYYu Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFGpK4tForvXbEpPzQRAsV8AKCKuubOZb4vfPsrE7p4FJLvMUwjowCgzr3l DpQTCqLmxHi90ft3rzemxLM= =DHp2 -----END PGP SIGNATURE----- --/Zw+/jwnNHcBRYYu-- From owner-freebsd-current@FreeBSD.ORG Mon Jul 23 14:39:58 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 05C7C16A498 for ; Mon, 23 Jul 2007 14:39:58 +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 C25C313C45A for ; Mon, 23 Jul 2007 14:39:57 +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 l6NEdsj3019195 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Jul 2007 10:39:54 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.12.9p2/8.12.9/Submit) id l6NEdQ0t092801; Mon, 23 Jul 2007 10:39:26 -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: <18084.48565.688142.945366@grasshopper.cs.duke.edu> Date: Mon, 23 Jul 2007 10:39:26 -0400 (EDT) To: Arne Schwabe In-Reply-To: <46A4BC5E.6080006@uni-paderborn.de> References: <18082.16126.915890.401438@grasshopper.cs.duke.edu> <46A37B6B.2050901@fnop.net> <18084.40711.665845.826349@grasshopper.cs.duke.edu> <46A4BC5E.6080006@uni-paderborn.de> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Cc: Rui Paulo , current@freebsd.org Subject: Re: 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: Mon, 23 Jul 2007 14:39:58 -0000 Arne Schwabe writes: > Andrew Gallatin schrieb: > > Rui Paulo writes: > > > > 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? > > > > > > As a workaround try using a 6.2 CD. > > > > > > > > On a somewhat related note, how well does FreeBSD even work on > > > > an iMac? Can we suspend/resume SMP machines yet? > > > > > > No. > > > > Argh. Screwed at every turn. As it turns out, I can't even make my > > machine boot a "legacy" OS from a firewire disk. Both FreeBSD and > > Ubuntu lead to a "no bootable device" error when booting directly, and > > rEFIt also fails (with some interesting comments regarding how apple's > > firmware does not deal well with booting a legacy OS from firwewire). > > I ran out of time before I could shuffle MacOSX to the external drive > > to free up the internal one for FreeBSD. > > > > Oh well, back to MacOSX and dealing with X crashing every few weeks. > > > > > You could resize your hfs+ parition (diskutil) and put a small boot > parition on your internal harddisk. Works fine on my Macbook Pro (but > still not usable, missing GPU support :( ) That's an option, but I was initially reluctant to touch my internal disk. I'm also somewhat upset that the machine can boot BSD or Linux only from an internal drive. If I were to convert it to FreeBSD, then I'd be totally hosed when the internal drive dies (its really buried in an iMac). At any rate before I touch the internal disk, which GPU are you having problems with? This box has a Radeon X1600. I've heard something about ATI building their drivers with linux libs statically linked in. Is that the problem? Is there no X.org driver. Thanks, Drew From owner-freebsd-current@FreeBSD.ORG Mon Jul 23 14:49: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 0963616A421; Mon, 23 Jul 2007 14:49:01 +0000 (UTC) (envelope-from scf@FreeBSD.org) Received: from mail.farley.org (farley.org [67.64.95.201]) by mx1.freebsd.org (Postfix) with ESMTP id C046313C491; Mon, 23 Jul 2007 14:49:00 +0000 (UTC) (envelope-from scf@FreeBSD.org) Received: from thor.farley.org (thor.farley.org [192.168.1.5]) by mail.farley.org (8.14.1/8.14.1) with ESMTP id l6NEmuE4073585; Mon, 23 Jul 2007 09:48:56 -0500 (CDT) (envelope-from scf@FreeBSD.org) Date: Mon, 23 Jul 2007 09:48:56 -0500 (CDT) From: "Sean C. Farley" To: Eric Anderson In-Reply-To: <46982BF7.3010207@freebsd.org> Message-ID: <20070723094249.G9030@thor.farley.org> References: <200707131834.27131.h.schmalzbauer@omnisec.de> <4697CCEB.9080707@FreeBSD.org> <200707132155.43783.h.schmalzbauer@omnisec.de> <20070713172842.K26096@thor.farley.org> <46982BF7.3010207@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.1 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on mail.farley.org Cc: attilio@FreeBSD.org, freebsd-current@FreeBSD.org, Harald Schmalzbauer 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, 23 Jul 2007 14:49:01 -0000 On Fri, 13 Jul 2007, Eric Anderson wrote: > On 07/13/07 17:29, Sean C. Farley wrote: >> On Fri, 13 Jul 2007, Harald Schmalzbauer wrote: >> >>> I could install various OS, only when I enable -kernel-kqemu most >>> installer quit with page fault. >> >> As a side note, I found -kernel-kqemu to be slower for me than >> without it on STABLE. > > Using ubench from ports on -CURRENT, I see these kinds of numbers (for > CPU): > > Without any kqemu: 16000 -> 16800 > With kqemu, kernelmode: 180000 -> 182000 > With kqemu, usermode: 187000 -> 188000 > RAW CPU: 202000 -> 203000 Here is mine on -STABLE. It is amusing how much faster the raw CPU really is when you take these benchmark numbers into account. If I remember correctly from trying to find where QEMU was slow, kqemu user + kernel actually has significantly more context switches than just kqemu user. kqemu user ========== Ubench CPU: 74871 Ubench MEM: 8873 -------------------- Ubench AVG: 41872 kqemu user + kernel =================== Ubench CPU: 67768 Ubench MEM: 6520 -------------------- Ubench AVG: 37144 Raw === Ubench CPU: 44162 Ubench MEM: 42655 -------------------- Ubench AVG: 43408 Sean -- scf@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Mon Jul 23 14:52: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 24A0016A419 for ; Mon, 23 Jul 2007 14:52:01 +0000 (UTC) (envelope-from schwabe@uni-paderborn.de) Received: from mail.blinkt.de (mail.blinkt.de [88.198.169.219]) by mx1.freebsd.org (Postfix) with ESMTP id E06B413C442 for ; Mon, 23 Jul 2007 14:51:58 +0000 (UTC) (envelope-from schwabe@uni-paderborn.de) Received: from dslb-084-062-212-221.pools.arcor-ip.net ([84.62.212.221] helo=styx.local) by mail.blinkt.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1ICzGP-0008pB-EK; Mon, 23 Jul 2007 16:51:57 +0200 Message-ID: <46A4C088.7040903@uni-paderborn.de> Date: Mon, 23 Jul 2007 16:51:52 +0200 From: Arne Schwabe User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; de; rv:1.8.1.5) Gecko/20070716 Thunderbird/2.0.0.5 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Andrew Gallatin References: <18082.16126.915890.401438@grasshopper.cs.duke.edu> <46A37B6B.2050901@fnop.net> <18084.40711.665845.826349@grasshopper.cs.duke.edu> <46A4BC5E.6080006@uni-paderborn.de> <18084.48565.688142.945366@grasshopper.cs.duke.edu> In-Reply-To: <18084.48565.688142.945366@grasshopper.cs.duke.edu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Rui Paulo , current@freebsd.org Subject: Re: 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: Mon, 23 Jul 2007 14:52:01 -0000 > That's an option, but I was initially reluctant to touch > my internal disk. I'm also somewhat upset that the machine > can boot BSD or Linux only from an internal drive. If I were > to convert it to FreeBSD, then I'd be totally hosed when the internal > drive dies (its really buried in an iMac). > > With working EFI support it should be possible. > At any rate before I touch the internal disk, which GPU are you having > problems with? This box has a Radeon X1600. I've heard something > about ATI building their drivers with linux libs statically linked > in. Is that the problem? Is there no X.org driver. > > Ati X1600. Works only in Vesa only for me, which means 1152x768 max resolution on my 1440x900 screen, which is quite suboptimal. Arne From owner-freebsd-current@FreeBSD.ORG Mon Jul 23 14:52: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 9252916A41F for ; Mon, 23 Jul 2007 14:52:01 +0000 (UTC) (envelope-from schwabe@uni-paderborn.de) Received: from mail.blinkt.de (mail.blinkt.de [88.198.169.219]) by mx1.freebsd.org (Postfix) with ESMTP id 5A03113C46E for ; Mon, 23 Jul 2007 14:52:01 +0000 (UTC) (envelope-from schwabe@uni-paderborn.de) Received: from dslb-084-062-212-221.pools.arcor-ip.net ([84.62.212.221] helo=styx.local) by mail.blinkt.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1ICyzE-0008dl-17; Mon, 23 Jul 2007 16:34:12 +0200 Message-ID: <46A4BC5E.6080006@uni-paderborn.de> Date: Mon, 23 Jul 2007 16:34:06 +0200 From: Arne Schwabe User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; de; rv:1.8.1.5) Gecko/20070716 Thunderbird/2.0.0.5 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Andrew Gallatin References: <18082.16126.915890.401438@grasshopper.cs.duke.edu> <46A37B6B.2050901@fnop.net> <18084.40711.665845.826349@grasshopper.cs.duke.edu> In-Reply-To: <18084.40711.665845.826349@grasshopper.cs.duke.edu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Rui Paulo , current@freebsd.org Subject: Re: 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: Mon, 23 Jul 2007 14:52:01 -0000 Andrew Gallatin schrieb: > Rui Paulo writes: > > > 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? > > > > As a workaround try using a 6.2 CD. > > > > > On a somewhat related note, how well does FreeBSD even work on > > > an iMac? Can we suspend/resume SMP machines yet? > > > > No. > > Argh. Screwed at every turn. As it turns out, I can't even make my > machine boot a "legacy" OS from a firewire disk. Both FreeBSD and > Ubuntu lead to a "no bootable device" error when booting directly, and > rEFIt also fails (with some interesting comments regarding how apple's > firmware does not deal well with booting a legacy OS from firwewire). > I ran out of time before I could shuffle MacOSX to the external drive > to free up the internal one for FreeBSD. > > Oh well, back to MacOSX and dealing with X crashing every few weeks. > > You could resize your hfs+ parition (diskutil) and put a small boot parition on your internal harddisk. Works fine on my Macbook Pro (but still not usable, missing GPU support :( ) Arne From owner-freebsd-current@FreeBSD.ORG Mon Jul 23 14:55:45 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 83B4616A418 for ; Mon, 23 Jul 2007 14:55:45 +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 18D1513C46B for ; Mon, 23 Jul 2007 14:55:45 +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 6A60D690E6A; Mon, 23 Jul 2007 15:49:22 +0100 (WEST) Received: by core.fnop.net (Postfix, from userid 1015) id 21F37690E70; Mon, 23 Jul 2007 15:49:22 +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.8 required=5.0 tests=AWL, BAYES_00, FORGED_RCVD_HELO, RCVD_IN_DSBL,RCVD_IN_SORBS_DUL autolearn=no version=3.1.7 Received: from epsilon.local (87-196-25-226.net.novis.pt [87.196.25.226]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by core.fnop.net (Postfix) with ESMTP id 5A168690E6A; Mon, 23 Jul 2007 15:49:20 +0100 (WEST) Message-ID: <46A4B35B.8050605@fnop.net> Date: Mon, 23 Jul 2007 14:55:39 +0100 From: Rui Paulo User-Agent: Thunderbird 2.0.0.4 (X11/20070704) MIME-Version: 1.0 To: Andrew Gallatin References: <18082.16126.915890.401438@grasshopper.cs.duke.edu> <46A37B6B.2050901@fnop.net> <18084.40711.665845.826349@grasshopper.cs.duke.edu> <46A4BC5E.6080006@uni-paderborn.de> <18084.48565.688142.945366@grasshopper.cs.duke.edu> In-Reply-To: <18084.48565.688142.945366@grasshopper.cs.duke.edu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: current@freebsd.org, Arne Schwabe Subject: Re: 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: Mon, 23 Jul 2007 14:55:45 -0000 Andrew Gallatin wrote: > Arne Schwabe writes: > > Andrew Gallatin schrieb: > > > Rui Paulo writes: > > > > > 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? > > > > > > > > As a workaround try using a 6.2 CD. > > > > > > > > > > > On a somewhat related note, how well does FreeBSD even work on > > > > > an iMac? Can we suspend/resume SMP machines yet? > > > > > > > > No. > > > > > > Argh. Screwed at every turn. As it turns out, I can't even make my > > > machine boot a "legacy" OS from a firewire disk. Both FreeBSD and > > > Ubuntu lead to a "no bootable device" error when booting directly, and > > > rEFIt also fails (with some interesting comments regarding how apple's > > > firmware does not deal well with booting a legacy OS from firwewire). > > > I ran out of time before I could shuffle MacOSX to the external drive > > > to free up the internal one for FreeBSD. > > > > > > Oh well, back to MacOSX and dealing with X crashing every few weeks. > > > > > > > > You could resize your hfs+ parition (diskutil) and put a small boot > > parition on your internal harddisk. Works fine on my Macbook Pro (but > > still not usable, missing GPU support :( ) > > That's an option, but I was initially reluctant to touch > my internal disk. I'm also somewhat upset that the machine > can boot BSD or Linux only from an internal drive. If I were > to convert it to FreeBSD, then I'd be totally hosed when the internal > drive dies (its really buried in an iMac). Have you tried booting BSD from Firewire with the help of rEFit? http://refit.sf.net -- Rui Paulo From owner-freebsd-current@FreeBSD.ORG Mon Jul 23 15:22:18 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 54B0216A41A for ; Mon, 23 Jul 2007 15:22:18 +0000 (UTC) (envelope-from eric@anholt.net) Received: from vonnegut.anholt.net (69-30-77-85.dq1sn.easystreet.com [69.30.77.85]) by mx1.freebsd.org (Postfix) with ESMTP id F238C13C45D for ; Mon, 23 Jul 2007 15:22:17 +0000 (UTC) (envelope-from eric@anholt.net) Received: from vonnegut.anholt.net (localhost [127.0.0.1]) by vonnegut.anholt.net (8.14.1/8.14.1) with ESMTP id l6NFAgK3002275; Mon, 23 Jul 2007 16:11:12 +0100 (BST) (envelope-from eric@anholt.net) Received: (from anholt@localhost) by vonnegut.anholt.net (8.14.1/8.14.1/Submit) id l6NF8bq3002267; Mon, 23 Jul 2007 08:08:37 -0700 (PDT) (envelope-from eric@anholt.net) X-Authentication-Warning: vonnegut.anholt.net: anholt set sender to eric@anholt.net using -f From: Eric Anholt To: Arne Schwabe In-Reply-To: <46A4C088.7040903@uni-paderborn.de> References: <18082.16126.915890.401438@grasshopper.cs.duke.edu> <46A37B6B.2050901@fnop.net> <18084.40711.665845.826349@grasshopper.cs.duke.edu> <46A4BC5E.6080006@uni-paderborn.de> <18084.48565.688142.945366@grasshopper.cs.duke.edu> <46A4C088.7040903@uni-paderborn.de> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-uqXCrKa0hD38ZSiFeudS" Date: Mon, 23 Jul 2007 08:08:19 -0700 Message-Id: <1185203299.2146.2.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.10.2 FreeBSD GNOME Team Port Cc: Rui Paulo , Andrew Gallatin , current@freebsd.org Subject: Re: 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: Mon, 23 Jul 2007 15:22:18 -0000 --=-uqXCrKa0hD38ZSiFeudS Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 2007-07-23 at 16:51 +0200, Arne Schwabe wrote: > > That's an option, but I was initially reluctant to touch > > my internal disk. I'm also somewhat upset that the machine > > can boot BSD or Linux only from an internal drive. If I were > > to convert it to FreeBSD, then I'd be totally hosed when the internal > > drive dies (its really buried in an iMac). > > > > =20 > With working EFI support it should be possible. > > At any rate before I touch the internal disk, which GPU are you having > > problems with? This box has a Radeon X1600. I've heard something > > about ATI building their drivers with linux libs statically linked > > in. Is that the problem? Is there no X.org driver. > > > > =20 > Ati X1600. Works only in Vesa only for me, which means 1152x768 max > resolution on my 1440x900 screen, which is quite suboptimal. If you grab the reverse-engineered xf86-video-avivo driver from xorg, that will at least get you native modesetting, even if it doesn't get you hardware acceleration. --=20 Eric Anholt anholt@FreeBSD.org eric@anholt.net eric.anholt@intel.com --=-uqXCrKa0hD38ZSiFeudS 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) iD8DBQBGpMRjHUdvYGzw6vcRAmxPAJ43edcVKp3127kRA//GA4BlVdxa3QCdGjPy RcX8zsWQVT7l9FKWh4BRu5I= =kCgt -----END PGP SIGNATURE----- --=-uqXCrKa0hD38ZSiFeudS-- From owner-freebsd-current@FreeBSD.ORG Mon Jul 23 15:28:47 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 6566116A41F for ; Mon, 23 Jul 2007 15:28:47 +0000 (UTC) (envelope-from schwabe@uni-paderborn.de) Received: from mail.blinkt.de (mail.blinkt.de [88.198.169.219]) by mx1.freebsd.org (Postfix) with ESMTP id 2B8A213C458 for ; Mon, 23 Jul 2007 15:28:47 +0000 (UTC) (envelope-from schwabe@uni-paderborn.de) Received: from dslb-084-062-212-221.pools.arcor-ip.net ([84.62.212.221] helo=styx.local) by mail.blinkt.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1ICzq0-0009GW-Hu; Mon, 23 Jul 2007 17:28:44 +0200 Message-ID: <46A4C927.5080200@uni-paderborn.de> Date: Mon, 23 Jul 2007 17:28:39 +0200 From: Arne Schwabe User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; de; rv:1.8.1.5) Gecko/20070716 Thunderbird/2.0.0.5 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Eric Anholt References: <18082.16126.915890.401438@grasshopper.cs.duke.edu> <46A37B6B.2050901@fnop.net> <18084.40711.665845.826349@grasshopper.cs.duke.edu> <46A4BC5E.6080006@uni-paderborn.de> <18084.48565.688142.945366@grasshopper.cs.duke.edu> <46A4C088.7040903@uni-paderborn.de> <1185203299.2146.2.camel@localhost> In-Reply-To: <1185203299.2146.2.camel@localhost> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: Rui Paulo , Andrew Gallatin , current@freebsd.org Subject: Re: 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: Mon, 23 Jul 2007 15:28:47 -0000 Eric Anholt schrieb: > On Mon, 2007-07-23 at 16:51 +0200, Arne Schwabe wrote: > >>> That's an option, but I was initially reluctant to touch >>> my internal disk. I'm also somewhat upset that the machine >>> can boot BSD or Linux only from an internal drive. If I were >>> to convert it to FreeBSD, then I'd be totally hosed when the internal >>> drive dies (its really buried in an iMac). >>> >>> >>> >> With working EFI support it should be possible. >> >>> At any rate before I touch the internal disk, which GPU are you having >>> problems with? This box has a Radeon X1600. I've heard something >>> about ATI building their drivers with linux libs statically linked >>> in. Is that the problem? Is there no X.org driver. >>> >>> >>> >> Ati X1600. Works only in Vesa only for me, which means 1152x768 max >> resolution on my 1440x900 screen, which is quite suboptimal. >> > > If you grab the reverse-engineered xf86-video-avivo driver from xorg, > that will at least get you native modesetting, even if it doesn't get > you hardware acceleration. > > Ah nice. I will try if time permits, but at the Moment I set up my workspace under OS X. Arne From owner-freebsd-current@FreeBSD.ORG Mon Jul 23 15:30:59 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 2413916A496; Mon, 23 Jul 2007 15:30:59 +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 976B013C458; Mon, 23 Jul 2007 15:30:58 +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 198455275 for multiple; Mon, 23 Jul 2007 11:39:06 -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 l6NFUD3P000170; Mon, 23 Jul 2007 11:30:20 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: Jeremie Le Hen Date: Mon, 23 Jul 2007 11:16:00 -0400 User-Agent: KMail/1.9.6 References: <20070616224703.GC63387@obiwan.tataz.chchile.org> <20070720095721.GE56695@obiwan.tataz.chchile.org> <20070720232100.GA35292@obiwan.tataz.chchile.org> In-Reply-To: <20070720232100.GA35292@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: <200707231116.01384.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, 23 Jul 2007 11:30:20 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/3742/Mon Jul 23 07:31:24 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-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: Mon, 23 Jul 2007 15:30:59 -0000 On Friday 20 July 2007 07:21:00 pm 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. Can you get verbose dmesg's both with and without ACPI? -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Jul 23 15:48: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 AD23B16A41A for ; Mon, 23 Jul 2007 15:48:12 +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 7C09913C469 for ; Mon, 23 Jul 2007 15:48:12 +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 l6NFmAKF003441 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Jul 2007 11:48:10 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.12.9p2/8.12.9/Submit) id l6NFlgRN092860; Mon, 23 Jul 2007 11:47:42 -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: <18084.52660.936317.324746@grasshopper.cs.duke.edu> Date: Mon, 23 Jul 2007 11:47:41 -0400 (EDT) To: Rui Paulo In-Reply-To: <46A4B35B.8050605@fnop.net> References: <18082.16126.915890.401438@grasshopper.cs.duke.edu> <46A37B6B.2050901@fnop.net> <18084.40711.665845.826349@grasshopper.cs.duke.edu> <46A4BC5E.6080006@uni-paderborn.de> <18084.48565.688142.945366@grasshopper.cs.duke.edu> <46A4B35B.8050605@fnop.net> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Cc: current@freebsd.org, Arne Schwabe Subject: Re: 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: Mon, 23 Jul 2007 15:48:12 -0000 Rui Paulo writes: > Andrew Gallatin wrote: > > Arne Schwabe writes: > > > Andrew Gallatin schrieb: > > > > rEFIt also fails (with some interesting comments regarding how apple's > > > > firmware does not deal well with booting a legacy OS from firwewire). > > > > I ran out of time before I could shuffle MacOSX to the external drive > > > > to free up the internal one for FreeBSD. > > > > > > > > Oh well, back to MacOSX and dealing with X crashing every few weeks. > > > > > > > > > > > You could resize your hfs+ parition (diskutil) and put a small boot > > > parition on your internal harddisk. Works fine on my Macbook Pro (but > > > still not usable, missing GPU support :( ) > > > > That's an option, but I was initially reluctant to touch > > my internal disk. I'm also somewhat upset that the machine > > can boot BSD or Linux only from an internal drive. If I were > > to convert it to FreeBSD, then I'd be totally hosed when the internal > > drive dies (its really buried in an iMac). > > Have you tried booting BSD from Firewire with the help of rEFit? > http://refit.sf.net Yes, as I said above "rEFIt also fails.." :( It did mention something about "USB", where this was actually a firewire drive. So perhaps something is getting confused regarding firewire and usb. Drew From owner-freebsd-current@FreeBSD.ORG Mon Jul 23 15:49:00 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 28D8216A41F for ; Mon, 23 Jul 2007 15:49:00 +0000 (UTC) (envelope-from SRS0=04e5b8ba3d21ff0b29a1f80ad9bd42a6d92db068=405=es.net=oberman@es.net) Received: from postal1.es.net (postal2.es.net [IPv6:2001:400:14:3::7]) by mx1.freebsd.org (Postfix) with ESMTP id C024513C4B6 for ; Mon, 23 Jul 2007 15:48:59 +0000 (UTC) (envelope-from SRS0=04e5b8ba3d21ff0b29a1f80ad9bd42a6d92db068=405=es.net=oberman@es.net) Received: from ptavv.es.net (ptavv.es.net [198.128.4.29]) by postal2.es.net (Postal Node 2) with ESMTP (SSL) id CWT64158 for ; Mon, 23 Jul 2007 08:48:58 -0700 Received: from ptavv.es.net (ptavv.es.net [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 5C5F645045 for ; Mon, 23 Jul 2007 08:48:58 -0700 (PDT) To: current@freebsd.org Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_1185205738_51096P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Mon, 23 Jul 2007 08:48:58 -0700 From: "Kevin Oberman" Message-Id: <20070723154858.5C5F645045@ptavv.es.net> Cc: Subject: gcc 4.2.1 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: Mon, 23 Jul 2007 15:49:00 -0000 --==_Exmh_1185205738_51096P Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I'll admit that this is a bit quick (4 or 5 days since release) , but does anyone (probably this means kan@ or re@) on when 4.2.1 might get into current? Aside from fixing the known optimization problem in 4.2.0, I hope it can get as much testing as possible before we get too close to 7-beta. -- 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_1185205738_51096P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) Comment: Exmh version 2.5 06/03/2002 iD8DBQFGpM3qkn3rs5h7N1ERAtl6AJwPMnZCRrKSr3WuCnEaKHJalrTapQCgmvho ZPXsTKf+GrturRgvoum1w+A= =c9Ea -----END PGP SIGNATURE----- --==_Exmh_1185205738_51096P-- From owner-freebsd-current@FreeBSD.ORG Mon Jul 23 16:53:17 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 2B01B16A468 for ; Mon, 23 Jul 2007 16:53:17 +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 E77F113C4B5 for ; Mon, 23 Jul 2007 16:53:16 +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 2168D473E7; Mon, 23 Jul 2007 12:53:15 -0400 (EDT) Date: Mon, 23 Jul 2007 17:53:15 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Kevin Oberman In-Reply-To: <20070723154858.5C5F645045@ptavv.es.net> Message-ID: <20070723175234.Q83919@fledge.watson.org> References: <20070723154858.5C5F645045@ptavv.es.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: current@freebsd.org Subject: Re: gcc 4.2.1 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: Mon, 23 Jul 2007 16:53:17 -0000 On Mon, 23 Jul 2007, Kevin Oberman wrote: > I'll admit that this is a bit quick (4 or 5 days since release) , but does > anyone (probably this means kan@ or re@) on when 4.2.1 might get into > current? Aside from fixing the known optimization problem in 4.2.0, I hope > it can get as much testing as possible before we get too close to 7-beta. Ken has mentioned to me that he plans for 4.2.1 to be in the beta (at least, this is my interpretation of things). I don't know of an ETA, and haven't seen a commit request or advance notice go across re@ as yet. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Mon Jul 23 17:04:33 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 40CF616A417; Mon, 23 Jul 2007 17:04:33 +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 027A413C458; Mon, 23 Jul 2007 17:04:32 +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 31730EB76BA; Tue, 24 Jul 2007 01:04:32 +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 5MzzvgZ5u38N; Tue, 24 Jul 2007 01:04:29 +0800 (CST) Received: from charlie.delphij.net (unknown [61.49.186.182]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id 6EB3CEB2497; Tue, 24 Jul 2007 01:04:29 +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=G46w4eNJ25f5kI8urJt7ovDOOAgnvwX5qs1aLP7FsDypqjFPxGA3148KBePOdAQcV rJOxdc0Viz8/LkTWIktUA== Message-ID: <46A4DF9C.7060204@delphij.net> Date: Tue, 24 Jul 2007 01:04:28 +0800 From: Xin LI User-Agent: Thunderbird 2.0.0.5 (X11/20070721) MIME-Version: 1.0 To: Robert Watson References: <20070723154858.5C5F645045@ptavv.es.net> <20070723175234.Q83919@fledge.watson.org> In-Reply-To: <20070723175234.Q83919@fledge.watson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: gcc 4.2.1 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: Mon, 23 Jul 2007 17:04:33 -0000 Robert Watson wrote: > > On Mon, 23 Jul 2007, Kevin Oberman wrote: > >> I'll admit that this is a bit quick (4 or 5 days since release) , but >> does anyone (probably this means kan@ or re@) on when 4.2.1 might get >> into current? Aside from fixing the known optimization problem in >> 4.2.0, I hope it can get as much testing as possible before we get too >> close to 7-beta. > > Ken has mentioned to me that he plans for 4.2.1 to be in the beta (at > least, this is my interpretation of things). I don't know of an ETA, > and haven't seen a commit request or advance notice go across re@ as yet. The 4.2.1 release was delayed for a short while but it's now out, tagged as revision 126787, just FYI. I think that we really want to import this release because it contains a lot of important bugfixes. If our gcc maintainers are all busy in the near future, I will be volunteering to give it a shot. Cheers, From owner-freebsd-current@FreeBSD.ORG Mon Jul 23 17:11:17 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 7490116A417 for ; Mon, 23 Jul 2007 17:11:17 +0000 (UTC) (envelope-from kabaev@gmail.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 1257313C457 for ; Mon, 23 Jul 2007 17:11:16 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: by nf-out-0910.google.com with SMTP id b2so118007nfb for ; Mon, 23 Jul 2007 10:11: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:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=dlxXXUWiN6WX5TUmEeB/ZB6HwxxyrxKgfinALXf1UXLO1DG7Vcu2Hy5mI1/iniDR2PKdURTHb3lcNhp0BTc98FygB7PgEZoag16sCQe5+OdJ2u+y8BCcdiuRTbehf/NjXuxQK+OGB6H9sWIQX5wkVYjZI+T10w5qJFUnaQ08It4= 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=Qj1qSrvcxP+YSRejsr1lEpWD5GpsQCJStl8TwIPAA84XqdJvX5rBL4f494gzZaxq4Mg5Ctw40DJkXiM1hoKrUKeJUvlRM8vaYp6G5tmi1X82gdVuExhZnJOLYrJcVmSaQs8pVRN+ANt/ap6vTZi0F5tZXM8z1vUV7lk1sM/XBDg= Received: by 10.82.108.9 with SMTP id g9mr2354490buc.1185210675366; Mon, 23 Jul 2007 10:11:15 -0700 (PDT) Received: by 10.82.190.1 with HTTP; Mon, 23 Jul 2007 10:11:15 -0700 (PDT) Message-ID: <8e5ef5f70707231011y4b732080n9c23793d1083f56a@mail.gmail.com> Date: Mon, 23 Jul 2007 13:11:15 -0400 From: "Alexander Kabaev" To: "Xin LI" In-Reply-To: <46A4DF9C.7060204@delphij.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070723154858.5C5F645045@ptavv.es.net> <20070723175234.Q83919@fledge.watson.org> <46A4DF9C.7060204@delphij.net> Cc: Robert Watson , current@freebsd.org Subject: Re: gcc 4.2.1 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: Mon, 23 Jul 2007 17:11:17 -0000 http://people.freebsd.org/~kan/contrib-gcc421.tar.gz This is 4.2.1-release snapshot, currently it should be under test on package cluster. On 7/23/07, Xin LI wrote: > Robert Watson wrote: > > > > On Mon, 23 Jul 2007, Kevin Oberman wrote: > > > >> I'll admit that this is a bit quick (4 or 5 days since release) , but > >> does anyone (probably this means kan@ or re@) on when 4.2.1 might get > >> into current? Aside from fixing the known optimization problem in > >> 4.2.0, I hope it can get as much testing as possible before we get too > >> close to 7-beta. > > > > Ken has mentioned to me that he plans for 4.2.1 to be in the beta (at > > least, this is my interpretation of things). I don't know of an ETA, > > and haven't seen a commit request or advance notice go across re@ as yet. > > The 4.2.1 release was delayed for a short while but it's now out, tagged > as revision 126787, just FYI. I think that we really want to import > this release because it contains a lot of important bugfixes. > > If our gcc maintainers are all busy in the near future, I will be > volunteering to give it a shot. > > Cheers, > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > -- Alexander Kabaev From owner-freebsd-current@FreeBSD.ORG Mon Jul 23 17:35:57 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 9956516A4C7; Mon, 23 Jul 2007 17:35:57 +0000 (UTC) (envelope-from davidt@yadt.co.uk) Received: from outcold.yadt.co.uk (outcold.yadt.co.uk [81.187.204.178]) by mx1.freebsd.org (Postfix) with ESMTP id 477D713C478; Mon, 23 Jul 2007 17:35:57 +0000 (UTC) (envelope-from davidt@yadt.co.uk) Received: from localhost (localhost [127.0.0.1]) by outcold.yadt.co.uk (Postfix) with ESMTP id 5D6851DD437; Mon, 23 Jul 2007 18:25:12 +0100 (BST) X-Virus-Scanned: amavisd-new at yadt.co.uk Received: from outcold.yadt.co.uk ([127.0.0.1]) by localhost (outcold.yadt.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m0fY4W4pDlhn; Mon, 23 Jul 2007 18:25:09 +0100 (BST) Received: by outcold.yadt.co.uk (Postfix, from userid 1001) id 24DF41DD4C9; Mon, 23 Jul 2007 18:25:09 +0100 (BST) Date: Thu, 19 Jul 2007 18:48:47 +0100 From: David Taylor To: "Wojciech A. Koszek" , freebsd-current@freebsd.org Message-ID: <20070719174847.GA5853@outcold.yadt.co.uk> Mail-Followup-To: "Wojciech A. Koszek" , freebsd-current@freebsd.org References: <20070506164247.GA77786@FreeBSD.czest.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <20070506164247.GA77786@FreeBSD.czest.pl> User-Agent: Mutt/1.4.2.3i Resent-From: davidt@yadt.co.uk Resent-Date: Mon, 23 Jul 2007 18:25:09 +0100 Resent-To: wkoszek@FreeBSD.org, freebsd-current@freebsd.org Resent-Message-Id: <20070723172509.24DF41DD4C9@outcold.yadt.co.uk> Cc: Subject: Re: INCLUDE_CONFIG_FILE patches X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Jul 2007 17:35:57 -0000 [Resent 2007-07-24, as it seemed to get lost] On Sun, 06 May 2007, Wojciech A. Koszek wrote: > Hello, > > We talked about improved INCLUDE_CONFIG_FILE work some time ago. I > cleaned it up, and I have prepared a patch for the latest -CURRENT. > > It's here: > > http://people.freebsd.org/~wkoszek/patches/kernconf.patch > > If you have any suggestions, please let me know as I'd really like to > see this patch into the tree before RELENG_7. Hi, I've discovered a small problem with this patch (or at least, whatever version is in RELENG_6 as of 2007-07-18). If your config file contains a trigraph (in my case, I had a comment containing "??)"), gcc will process it as a trigraph and produce a warning, which will break the build with a confusing and unhelpful error message in config.c. This caused no problems before the new INCLUDE_CONFIG_FILE option (as the config file wasn't included in the C source file). Not sure what the best solution is, but some kind of warning that this can happen would perhaps save someone 30 minutes of frustration! Alternatively, some method of escaping any potential trigraphs would be great. -- David Taylor From owner-freebsd-current@FreeBSD.ORG Mon Jul 23 18:12:44 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 56B5416A41F for ; Mon, 23 Jul 2007 18:12:44 +0000 (UTC) (envelope-from sfourman@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 1C7A213C461 for ; Mon, 23 Jul 2007 18:12:44 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: by an-out-0708.google.com with SMTP id c14so389800anc for ; Mon, 23 Jul 2007 11:12: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:references; b=NEz0piUYxAq1GLhAh2bwoZi4f64vCZ7/CfrWMUbK7nZh4gvBnY+f5JkoluMhZwUTpIVrNZG5X/GggZvOujCkJWZgzGIgHc41U6mDIS/W4xat6SEtoZFpZYuWff8eaPwgYr9WCkgk2PAmU7OyD5V3dGO0pA/SLVXm0qo9CclbFYA= 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=R3Y4OAVwAJnk2Mzf5Iff+CWclLN8fnRxczLX5BiAN9dKw07q//o4H6JFwxpYiItCRhmJnbR+DI0/7L16bx6oHsGOx4csR8+jNmIcIaXSVu5J2LAKbL8sLeZ/WxnUUgBEh/7dnxxhzI1L/ne/f6cmBgE8DUux/1ByLNvbCJjO4MU= Received: by 10.100.10.20 with SMTP id 20mr1816566anj.1185214363322; Mon, 23 Jul 2007 11:12:43 -0700 (PDT) Received: by 10.100.144.1 with HTTP; Mon, 23 Jul 2007 11:12:43 -0700 (PDT) Message-ID: <11167f520707231112r2be7e6afq9c8d4a140c321bc6@mail.gmail.com> Date: Mon, 23 Jul 2007 13:12:43 -0500 From: "Sam Fourman Jr." To: "Christian Walther" In-Reply-To: <14989d6e0706270950j61f37425o4ebb11bca00e9d4e@mail.gmail.com> MIME-Version: 1.0 References: <14989d6e0706270950j61f37425o4ebb11bca00e9d4e@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: freebsd-current@freebsd.org Subject: Re: Snapshots on the homepage X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Jul 2007 18:12:44 -0000 When will the July snapshot of CURRENT be available? On 6/27/07, Christian Walther wrote: > > Hi, > > this might be the wrong list, so please point me to the real one if > possible. > I wanted to download a recent snapshot of CURRENT, but the latest > snapshot listed on the Homepage is from april. > This might confuse people who want to give CURRENT a try. > The page http://www.freebsd.org/snapshots/ should either be updated or > the monthly listing replaced with a link pointing to the parent > directory. > > Regards > Christian > _______________________________________________ > 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 23 19:18:41 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 4C9D316A418; Mon, 23 Jul 2007 19:18:41 +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 BADE913C4D9; Mon, 23 Jul 2007 19:18:40 +0000 (UTC) (envelope-from dfr@rabson.org) Received: from [80.177.232.250] (herring.rabson.org [80.177.232.250]) by itchy.rabson.org (8.13.3/8.13.3) with ESMTP id l6NJIdFF083076; Mon, 23 Jul 2007 20:18:39 +0100 (BST) (envelope-from dfr@rabson.org) From: Doug Rabson To: Andrew Thompson In-Reply-To: <20070723031119.GA5541@heff.fud.org.nz> References: <200707211925.59698.dfr@rabson.org> <20070721210759.GA84580@heff.fud.org.nz> <20070721210837.GB84580@heff.fud.org.nz> <200707220858.12770.dfr@rabson.org> <20070723031119.GA5541@heff.fud.org.nz> Content-Type: text/plain Date: Mon, 23 Jul 2007 20:18:39 +0100 Message-Id: <1185218319.49715.0.camel@herring.rabson.org> Mime-Version: 1.0 X-Mailer: Evolution 2.10.2 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.87.1/3743/Mon Jul 23 18:44:24 2007 on itchy.rabson.org X-Virus-Status: Clean Cc: Attilio Rao , 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: Mon, 23 Jul 2007 19:18:41 -0000 On Mon, 2007-07-23 at 15:11 +1200, Andrew Thompson wrote: > On Sun, Jul 22, 2007 at 08:58:12AM +0100, Doug Rabson wrote: > > On Saturday 21 July 2007, Andrew Thompson wrote: > > > 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: > > > > > > > > > > > >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. > > > > I still get a panic but I managed to get more information this time. The > > original panic was a WITNESS complaint (not sure why that put it into > > the debugger rather than just logging the LOR). > > It seems I didnt check all the places copyout was used, please test this > larger patch. > That did the trick, thanks. From owner-freebsd-current@FreeBSD.ORG Mon Jul 23 19:50: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 A603716A41F for ; Mon, 23 Jul 2007 19:50:11 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by mx1.freebsd.org (Postfix) with ESMTP id 8A59313C459 for ; Mon, 23 Jul 2007 19:50:11 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 23 Jul 2007 12:50:11 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAEajpEarR7PD/2dsb2JhbAA X-IronPort-AV: i="4.16,572,1175497200"; d="scan'208"; a="187103926:sNHT24924582" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l6NJoBRV013975 for ; Mon, 23 Jul 2007 12:50:11 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6NJo1AO009990 for ; Mon, 23 Jul 2007 19:50:11 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Jul 2007 12:50:07 -0700 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Jul 2007 12:50:07 -0700 Message-ID: <46A50698.4030104@cisco.com> Date: Mon, 23 Jul 2007 15:50:48 -0400 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.13) Gecko/20070601 X-Accept-Language: en-us, en MIME-Version: 1.0 To: current@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Jul 2007 19:50:07.0278 (UTC) FILETIME=[AB992CE0:01C7CD62] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=659; t=1185220211; x=1186084211; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rrs@cisco.com; z=From:=20Randall=20Stewart=20 |Subject:=20once=20again=20scan=20problems |Sender:=20; bh=oaPO1q23DGQ8dHcIzvi1I35asRZQI8GTCq8+sk6a5as=; b=ht+WUe08R5DX4OBP8ObpTOYifqAOQPDix1/x+YEct+nsgJo0i/HpXnbOXx58gOAYBp67yrgc vy6417AyeRp3ltUHDV0LaypeoziSYXMiqi6QlIGnsAKQnfnottsZBQpU; Authentication-Results: sj-dkim-3; header.From=rrs@cisco.com; dkim=pass (sig from cisco.com/sjdkim3002 verified; ); Cc: Subject: once again scan 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: Mon, 23 Jul 2007 19:50:11 -0000 Hello all: Ok last night I updated to the latest current... did a buildworld/installworld added a new kernel.. And now once again my iwi and ath cards will no longer scan networks.. they just stay locked on channel 1. I do have : wlan_scan_sta_load="YES" legal.intel_iwi.license_ack=1 In my loader.conf... And before I did all this (yesterday PM) I was scanning on both cards (my previous current was from a week or so ago.. and the buildworld was a few weeks ago). Any ideas if maybe I am missing a magic cookie somewhere? Thanks R -- Randall Stewart NSSTG - Cisco Systems Inc. 803-345-0369 803-317-4952 (cell) From owner-freebsd-current@FreeBSD.ORG Mon Jul 23 20:01:14 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 9077616A417; Mon, 23 Jul 2007 20:01:14 +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 5FBC013C457; Mon, 23 Jul 2007 20:01:14 +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 5AC3E449FC; Mon, 23 Jul 2007 22:01:13 +0200 (CEST) Received: from obiwan.tataz.chchile.org (unknown [192.168.1.25]) by tatooine.tataz.chchile.org (Postfix) with ESMTP id BC89F9B497; Mon, 23 Jul 2007 20:00:21 +0000 (UTC) Received: by obiwan.tataz.chchile.org (Postfix, from userid 1000) id AA1E4405D; Mon, 23 Jul 2007 22:00:21 +0200 (CEST) Date: Mon, 23 Jul 2007 22:00:21 +0200 From: Jeremie Le Hen To: John Baldwin Message-ID: <20070723200021.GB96643@obiwan.tataz.chchile.org> References: <20070616224703.GC63387@obiwan.tataz.chchile.org> <20070720095721.GE56695@obiwan.tataz.chchile.org> <20070720232100.GA35292@obiwan.tataz.chchile.org> <200707231116.01384.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200707231116.01384.jhb@freebsd.org> User-Agent: Mutt/1.5.15 (2007-04-06) Cc: freebsd-current@freebsd.org, Jeremie Le Hen 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, 23 Jul 2007 20:01:14 -0000 John, On Mon, Jul 23, 2007 at 11:16:00AM -0400, John Baldwin wrote: > On Friday 20 July 2007 07:21:00 pm Jeremie Le Hen wrote: > > 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. > > Can you get verbose dmesg's both with and without ACPI? I've not attached them as verbose dmesgs are quite huge, you can get them here. With ACPI (psm(4) doesn't work, iwi(4) does): http://tataz.chchile.org/~tataz/tmp/dmesg.with_acpi.gz Without ACPI (hint.acpi.0.disabled="1", psm(4) works, iwi(4) doesn't): http://tataz.chchile.org/~tataz/tmp/dmesg.without_acpi.gz Note that I've manually loaded iwi_bss and if_iwi modules from root prompt. Thank you very much. Best regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-current@FreeBSD.ORG Mon Jul 23 20:12:26 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 7746216A418; Mon, 23 Jul 2007 20:12:26 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 4021413C428; Mon, 23 Jul 2007 20:12:23 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.13.8/8.13.8) with ESMTP id l6NKCNMs028726; Mon, 23 Jul 2007 16:12:23 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.8/8.13.8) with ESMTP id l6NKCNos057269; Mon, 23 Jul 2007 16:12:23 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id E0ADB73068; Mon, 23 Jul 2007 16:12:22 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070723201222.E0ADB73068@freebsd-current.sentex.ca> Date: Mon, 23 Jul 2007 16:12:22 -0400 (EDT) X-Virus-Scanned: ClamAV version devel-20070102, clamav-milter version devel-111206 on clamscanner4 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2007 20:12:26 -0000 TB --- 2007-07-23 18:43:04 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-07-23 18:43:04 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2007-07-23 18:43:04 - cleaning the object tree TB --- 2007-07-23 18:43:30 - checking out the source tree TB --- 2007-07-23 18:43:30 - cd /tinderbox/HEAD/sparc64/sparc64 TB --- 2007-07-23 18:43:30 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-07-23 18:51:35 - building world (CFLAGS=-O2 -pipe) TB --- 2007-07-23 18:51:35 - cd /src TB --- 2007-07-23 18:51:35 - /usr/bin/make -B buildworld >>> World build started on Mon Jul 23 18:51:36 UTC 2007 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Mon Jul 23 20:04:00 UTC 2007 TB --- 2007-07-23 20:04:00 - generating LINT kernel config TB --- 2007-07-23 20:04:00 - cd /src/sys/sparc64/conf TB --- 2007-07-23 20:04:00 - /usr/bin/make -B LINT TB --- 2007-07-23 20:04:00 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-07-23 20:04:00 - cd /src TB --- 2007-07-23 20:04:00 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Jul 23 20:04:00 UTC 2007 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/kern/kern_exit.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/kern/kern_fork.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/kern/kern_idle.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/kern/kern_intr.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/kern/kern_jail.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/kern/kern_kse.c cc1: warnings being treated as errors /src/sys/kern/kern_kse.c:87: warning: 'upcall_free' defined but not used *** Error code 1 Stop in /obj/sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-07-23 20:12:22 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-07-23 20:12:22 - ERROR: failed to build lint kernel TB --- 2007-07-23 20:12:22 - tinderbox aborted TB --- 0.66 user 2.59 system 5357.95 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Mon Jul 23 20:13:28 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 2BC5716A418; Mon, 23 Jul 2007 20:13:28 +0000 (UTC) (envelope-from SRS0=04e5b8ba3d21ff0b29a1f80ad9bd42a6d92db068=405=es.net=oberman@es.net) Received: from postal1.es.net (postoffice2.doegrids.org [IPv6:2001:400:14:3::7]) by mx1.freebsd.org (Postfix) with ESMTP id BC36513C46E; Mon, 23 Jul 2007 20:13:27 +0000 (UTC) (envelope-from SRS0=04e5b8ba3d21ff0b29a1f80ad9bd42a6d92db068=405=es.net=oberman@es.net) Received: from ptavv.es.net (ptavv.es.net [198.128.4.29]) by postal2.es.net (Postal Node 2) with ESMTP (SSL) id CBK02627; Mon, 23 Jul 2007 13:13:27 -0700 Received: from ptavv.es.net (ptavv.es.net [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id C539945045; Mon, 23 Jul 2007 13:13:26 -0700 (PDT) To: Jeremie Le Hen In-Reply-To: Your message of "Mon, 23 Jul 2007 22:00:21 +0200." <20070723200021.GB96643@obiwan.tataz.chchile.org> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_1185221606_51096P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Mon, 23 Jul 2007 13:13:26 -0700 From: "Kevin Oberman" Message-Id: <20070723201326.C539945045@ptavv.es.net> 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: Mon, 23 Jul 2007 20:13:28 -0000 --==_Exmh_1185221606_51096P Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > Date: Mon, 23 Jul 2007 22:00:21 +0200 > From: Jeremie Le Hen > Sender: owner-freebsd-current@freebsd.org > > John, > > On Mon, Jul 23, 2007 at 11:16:00AM -0400, John Baldwin wrote: > > On Friday 20 July 2007 07:21:00 pm Jeremie Le Hen wrote: > > > 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. > > > > Can you get verbose dmesg's both with and without ACPI? > > I've not attached them as verbose dmesgs are quite huge, you can get > them here. > > With ACPI (psm(4) doesn't work, iwi(4) does): > http://tataz.chchile.org/~tataz/tmp/dmesg.with_acpi.gz > > Without ACPI (hint.acpi.0.disabled="1", psm(4) works, iwi(4) doesn't): > http://tataz.chchile.org/~tataz/tmp/dmesg.without_acpi.gz > > Note that I've manually loaded iwi_bss and if_iwi modules from root > prompt. I have a very similar problem when I load drivers at the boot prompt (or did you mean "root"?) If you look at your dmesg (verbose not needed). I suspect that you will se that there is no interrupt assigned to psm. If you are loading them before the probe, try booting with ACPI and boot to single user (boot -s). Hit Enter to get a shell prompt and load the needed modules (kldload). Then exit to move to multi-user. I bet everything works. I found that my system fails to assign an interrupt to psm if I have the module loaded before I probe I/O devices. jhb suggested an approach to fixing this, but I have not gotten around to trying it. -- 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_1185221606_51096P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) Comment: Exmh version 2.5 06/03/2002 iD8DBQFGpQvmkn3rs5h7N1ERAj6NAJ4jSZSqcZs7r4TysxyENm4akxrkAwCfaRYw Akopdt4nt23b9+vjbLqCFGg= =65pk -----END PGP SIGNATURE----- --==_Exmh_1185221606_51096P-- From owner-freebsd-current@FreeBSD.ORG Mon Jul 23 20:14: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 C13DC16A41B for ; Mon, 23 Jul 2007 20:14:01 +0000 (UTC) (envelope-from datahead4@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.231]) by mx1.freebsd.org (Postfix) with ESMTP id 8683D13C469 for ; Mon, 23 Jul 2007 20:14:01 +0000 (UTC) (envelope-from datahead4@gmail.com) Received: by nz-out-0506.google.com with SMTP id l8so1099018nzf for ; Mon, 23 Jul 2007 13:14:00 -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=ZuxEb/516ZB3LNbcaPNj+6fht9EPEOhSwrdGEgrroVa6469wPr601GnzCC1QSV3h0VC0oKsk6NAio1v8/TiDwMjMMI+qniz/Cu0HTF1nmlFK48Sqe+CIk6Q+dmqIp94ajHMTU5qQ46+aahRI07U085XBtg4s0b9CuLWlH9ZWQ/g= 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=spqnUjXi86W0yy5TRxwX3o99Bm56aM7a9X/M8bVd4POvh3LdAqBtGlvsPiV9o5s8EuGvYCQL/8QdneatGoHmFnrPm4jM92JrTkDj6pxC09lTemehyuGjgajY9h/c4HlURbeaSmtfv6zGPBmnFkPIwA8h5vhj/p8ugWXgtIzMpk0= Received: by 10.114.196.1 with SMTP id t1mr3333469waf.1185221639747; Mon, 23 Jul 2007 13:13:59 -0700 (PDT) Received: by 10.114.205.5 with HTTP; Mon, 23 Jul 2007 13:13:59 -0700 (PDT) Message-ID: Date: Mon, 23 Jul 2007 15:13:59 -0500 From: Matt To: "Jeff Roberson" In-Reply-To: <20070721174631.S561@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: <20070721174631.S561@10.0.0.1> Cc: current@freebsd.org Subject: Re: ULE status, invalid load, buildkernel 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, 23 Jul 2007 20:14:01 -0000 On 7/21/07, Jeff Roberson wrote: > I have a patch available at: > > http://people.freebsd.org/~jeff/ulehtt.diff > > This resolves issues in the code that handles HTT enabled processors and > also adds some ULE information to bootverbose on SMP systems. Peter Wemm > has a seperate patch that fixes a bug where some amd64 cpus were still > being misidentified as HTT. Those of you with invalid loads either have > Hyper-threading CPUs or misidentified amd cores. You should expect > slightly poorer performance as long as your cores are misidentified but > the bad loads should be fixed. > > I also believe that the buildkernel/world times are now significantly > improved. If this is not the case for you please send a mail. Any other > performance data is appreciated. > > 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" > -current system with sources update July 22 at approx. 3PM central time with the ulehtt.diff patch applied experienced a panic this afternoon while restarting a local Apache Tomcat server. Backtrace information is shown below. Unclear to me whether or not the patch and the panic are related. Matt (kgdb) mtosto-bsd# kgdb kernel.debug /var/crash/vmcore.1 [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd". Unread portion of the kernel message buffer: panic: kse_wakeup: no owner cpuid = 1 Uptime: 23h29m24s Physical memory: 2030 MB Dumping 288 MB: 273 257 241 225 209 193 177 161 145 129 113 97 81 65 49 33 17 1 #0 doadump () at pcpu.h:195 195 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); (kgdb) bt #0 doadump () at pcpu.h:195 #1 0xc05d57c7 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 #2 0xc05d5abb in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:563 #3 0xc05bc398 in kse_wakeup (td=0xc5f99440, uap=0xe8787cfc) at /usr/src/sys/kern/kern_kse.c:536 #4 0xc0829355 in syscall (frame=0xe8787d38) at /usr/src/sys/i386/i386/trap.c:1006 #5 0xc080f1b0 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:196 #6 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) list *0xc05bc398 0xc05bc398 is in kse_wakeup (/usr/src/sys/kern/kern_kse.c:537). 532 return (ESRCH); 533 } 534 if ((td2 = ku->ku_owner) == NULL) { 535 PROC_SUNLOCK(p); 536 panic("%s: no owner", __func__); 537 } else if (td2->td_kflags & (TDK_KSEREL | TDK_KSERELSIG)) { 538 if (!(td2->td_kflags & TDK_WAKEUP)) { 539 td2->td_kflags |= TDK_WAKEUP; 540 if (td2->td_kflags & TDK_KSEREL) 541 sleepq_remove(td2, &p->p_completed); (kgdb) list *0xc0829355 0xc0829355 is in syscall (/usr/src/sys/i386/i386/trap.c:1006). 1001 STOPEVENT(p, S_SCE, narg); 1002 1003 PTRACESTOP_SC(p, td, S_PT_SCE); 1004 1005 AUDIT_SYSCALL_ENTER(code, td); 1006 error = (*callp->sy_call)(td, args); 1007 AUDIT_SYSCALL_EXIT(error, td); 1008 } 1009 1010 switch (error) { (kgdb) list *0xc080f1b0 0xc080f1b0 is at /usr/src/sys/i386/i386/exception.s:197. 192 pushl %fs 193 SET_KERNEL_SREGS 194 FAKE_MCOUNT(TF_EIP(%esp)) 195 pushl %esp 196 call syscall 197 add $4, %esp 198 MEXITCOUNT 199 jmp doreti 200 201 ENTRY(fork_trampoline) (kgdb) From owner-freebsd-current@FreeBSD.ORG Mon Jul 23 20:14:08 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 BEE4016A4A0 for ; Mon, 23 Jul 2007 20:14:08 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from webmail24.mail.yandex.net (webmail24.mail.yandex.net [213.180.223.151]) by mx1.freebsd.org (Postfix) with ESMTP id 5275413C491 for ; Mon, 23 Jul 2007 20:14:08 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from YAMAIL (webmail24) by mail.yandex.ru id S491925AbXGWUNs for ; Tue, 24 Jul 2007 00:13:48 +0400 Received: from [83.149.32.53] ([83.149.32.53]) by mail.yandex.ru with HTTP; Tue, 24 Jul 2007 00:13:47 +0400 From: "Andrey V. Elsukov" To: unhooked@telus.net, pyunyh@gmail.com, freebsd-current@freebsd.org In-Reply-To: 1550000000186579821 References: <1185196981.00778084.1185183602@10.7.7.3> 1550000000186579821 MIME-Version: 1.0 Message-Id: <6351185221628@webmail24.yandex.ru> Date: Tue, 24 Jul 2007 00:13:48 +0400 X-Mailer: Yamail [ http://yandex.ru ] 5.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain Cc: Subject: Re: Conflict between nfe(4) and x11/nvidia-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: Mon, 23 Jul 2007 20:14:08 -0000 > This sounds like issues I was having with xorg, but it would only happen > when I used an app that used glx. > Switching to http://www.nvidia.com/object/freebsd_100.14.11.html stopped > my crashing. I have installed this driver several days ago, but this don't helps me. > You'll have to comment out the exit statement from nv-freebsd.h and > change some of the Makefiles (see other threads on mailinglist) to get > it to install. Yes, this is easy. > > nvidia0: mem 0xc2000000-0xc2ffffff,0xd0000000-0xdfffffff,0xc1000000-0xc1ffffff irq 5 at device 5.0 on pci0 > > nfe0: port 0x30b8-0x30bf mem 0xc0007000-0xc0007fff irq 5 at device 20.0 on pci0 >Show me the output of "vmstat -i". interrupt total rate irq0: clk 876945 999 irq1: atkbd0 2657 3 irq5: nvidia0 nfe0 48478 55 irq7: atapci1 4653 5 irq8: rtc 112232 127 irq9: cbb0 ath0++ 1282 1 irq11: pcm0 ohci0 3587 4 irq12: psm0 9236 10 irq15: ata1 101 0 Total 1059171 1207 >I guess nfe(4) shares interrupt with your video adapter. Yes, irq5. I've tried change irq for the nfe(4). But seems there is no way to do it easy for CURRENT. divece.hints don't help me. >If this is the case use polling(4) which may fix the issue. Yes, i've tried polling. System seems more stable. But i have this issue again. :( And in /var/log/messages i have no messages from nfe. -- WBR, Andrey V. Elsukov From owner-freebsd-current@FreeBSD.ORG Mon Jul 23 22:19: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 65B9816A41A for ; Mon, 23 Jul 2007 22:19:42 +0000 (UTC) (envelope-from ss.alert@online.no) Received: from mail44.e.nsc.no (mail44.e.nsc.no [193.213.115.44]) by mx1.freebsd.org (Postfix) with ESMTP id 0AE2213C46A for ; Mon, 23 Jul 2007 22:19:41 +0000 (UTC) (envelope-from ss.alert@online.no) Received: from PARALLELS (ti0034a340-0045.bb.online.no [88.90.0.45]) by mail44.nsc.no (8.13.8/8.13.5) with ESMTP id l6NLHruC013178 for ; Mon, 23 Jul 2007 23:17:53 +0200 (MEST) Date: Mon, 23 Jul 2007 23:17:53 +0200 From: Sverre Svenningsen X-Mailer: The Bat! (v3.99.3) Professional Organization: - X-Priority: 3 (Normal) Message-ID: <1736829882.20070723231753@online.no> To: freebsd-current@freebsd.org In-Reply-To: <20070721065204.GA2044@garage.freebsd.pl> References: <20070719102302.R1534@rust.salford.ac.uk> <20070719135510.GE1194@garage.freebsd.pl> <20070719181313.G4923@rust.salford.ac.uk> <20070721065204.GA2044@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: (ZFS) zpool replace weirdness X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Sverre Svenningsen List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2007 22:19:42 -0000 I've been playing around with zfs for a bit, and ran into a problem where i corrupted an entire drive (on purpose) by way of dd if=/dev/urandom of=/dev/ad12 .. as expected, the zpool noticed: su-2.05b# zpool status pool: array1 state: ONLINE status: One or more devices could not be used because the label is missing or invalid. Sufficient replicas exist for the pool to continue functioning in a degraded state. action: Replace the device using 'zpool replace'. see: http://www.sun.com/msg/ZFS-8000-4J scrub: resilver completed with 0 errors on Mon Jul 23 23:05:53 2007 config: NAME STATE READ WRITE CKSUM array1 ONLINE 0 0 0 raidz1 ONLINE 0 0 0 ad10 ONLINE 0 0 0 ad12 UNAVAIL 0 0 0 corrupted data ad14 ONLINE 0 0 0 ad16 ONLINE 0 0 0 raidz1 ONLINE 0 0 0 ad18 ONLINE 0 0 0 ad20 ONLINE 0 0 0 ad22 ONLINE 0 0 0 ad24 ONLINE 0 0 0 errors: No known data errors now i want to resilver that disk, but the problem is this: su-2.05b# zpool replace -f array1 ad12 invalid vdev specification the following errors must be manually repaired: ad12 is in use (r1w1e1) but nothing is using that disk as far as i can tell! has anyone successfully done this? would it be better to use slices instead of whole disks for zfs on freebsd? i want to get some experience with this so that i know what not to do when a disk breaks for real :) -- Best regards, Sverre S mailto:ss.alert@online.no From owner-freebsd-current@FreeBSD.ORG Mon Jul 23 22:21: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 BF1BF16A419; Mon, 23 Jul 2007 22:21: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 897EC13C442; Mon, 23 Jul 2007 22:21:01 +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 l6NMKx8P092197 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Mon, 23 Jul 2007 18:21:00 -0400 (EDT) (envelope-from jroberson@chesapeake.net) Date: Mon, 23 Jul 2007 15:24:01 -0700 (PDT) From: Jeff Roberson X-X-Sender: jroberson@10.0.0.1 To: Matt In-Reply-To: Message-ID: <20070723152212.O561@10.0.0.1> References: <20070721174631.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 Subject: Re: ULE status, invalid load, buildkernel 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, 23 Jul 2007 22:21:01 -0000 On Mon, 23 Jul 2007, Matt wrote: > On 7/21/07, Jeff Roberson wrote: >> I have a patch available at: >> >> http://people.freebsd.org/~jeff/ulehtt.diff >> >> This resolves issues in the code that handles HTT enabled processors and >> also adds some ULE information to bootverbose on SMP systems. Peter Wemm >> has a seperate patch that fixes a bug where some amd64 cpus were still >> being misidentified as HTT. Those of you with invalid loads either have >> Hyper-threading CPUs or misidentified amd cores. You should expect >> slightly poorer performance as long as your cores are misidentified but >> the bad loads should be fixed. >> >> I also believe that the buildkernel/world times are now significantly >> improved. If this is not the case for you please send a mail. Any other >> performance data is appreciated. >> >> 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" >> > > -current system with sources update July 22 at approx. 3PM central > time with the ulehtt.diff patch applied experienced a panic this > afternoon while restarting a local Apache Tomcat server. Backtrace > information is shown below. Unclear to me whether or not the patch > and the panic are related. I suspect that this is unrelated to my patch but I can't say for certain. There have been some kse locking problems that Attilio has a patch for. I believe it went in today. Hopefully he will comment. This does show that you are using libkse which is deprecated. You should switch to libthr as it will perform significantly better for you. Thanks, Jeff > > Matt > > (kgdb) mtosto-bsd# kgdb kernel.debug /var/crash/vmcore.1 > [GDB will not be able to debug user-mode threads: > /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "i386-marcel-freebsd". > > Unread portion of the kernel message buffer: > panic: kse_wakeup: no owner > cpuid = 1 > Uptime: 23h29m24s > Physical memory: 2030 MB > Dumping 288 MB: 273 257 241 225 209 193 177 161 145 129 113 97 81 65 49 33 17 > 1 > > #0 doadump () at pcpu.h:195 > 195 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); > (kgdb) bt > #0 doadump () at pcpu.h:195 > #1 0xc05d57c7 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 > #2 0xc05d5abb in panic (fmt=Variable "fmt" is not available. > ) at /usr/src/sys/kern/kern_shutdown.c:563 > #3 0xc05bc398 in kse_wakeup (td=0xc5f99440, uap=0xe8787cfc) > at /usr/src/sys/kern/kern_kse.c:536 > #4 0xc0829355 in syscall (frame=0xe8787d38) at > /usr/src/sys/i386/i386/trap.c:1006 > #5 0xc080f1b0 in Xint0x80_syscall () at > /usr/src/sys/i386/i386/exception.s:196 > #6 0x00000033 in ?? () > Previous frame inner to this frame (corrupt stack?) > (kgdb) list *0xc05bc398 > 0xc05bc398 is in kse_wakeup (/usr/src/sys/kern/kern_kse.c:537). > 532 return (ESRCH); > 533 } > 534 if ((td2 = ku->ku_owner) == NULL) { > 535 PROC_SUNLOCK(p); > 536 panic("%s: no owner", __func__); > 537 } else if (td2->td_kflags & (TDK_KSEREL | TDK_KSERELSIG)) { > 538 if (!(td2->td_kflags & TDK_WAKEUP)) { > 539 td2->td_kflags |= TDK_WAKEUP; > 540 if (td2->td_kflags & TDK_KSEREL) > 541 sleepq_remove(td2, &p->p_completed); > (kgdb) list *0xc0829355 > 0xc0829355 is in syscall (/usr/src/sys/i386/i386/trap.c:1006). > 1001 STOPEVENT(p, S_SCE, narg); > 1002 > 1003 PTRACESTOP_SC(p, td, S_PT_SCE); > 1004 > 1005 AUDIT_SYSCALL_ENTER(code, td); > 1006 error = (*callp->sy_call)(td, args); > 1007 AUDIT_SYSCALL_EXIT(error, td); > 1008 } > 1009 > 1010 switch (error) { > (kgdb) list *0xc080f1b0 > 0xc080f1b0 is at /usr/src/sys/i386/i386/exception.s:197. > 192 pushl %fs > 193 SET_KERNEL_SREGS > 194 FAKE_MCOUNT(TF_EIP(%esp)) > 195 pushl %esp > 196 call syscall > 197 add $4, %esp > 198 MEXITCOUNT > 199 jmp doreti > 200 > 201 ENTRY(fork_trampoline) > (kgdb) > _______________________________________________ > 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 23 22:27:27 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 6CD2F16A417 for ; Mon, 23 Jul 2007 22:27:27 +0000 (UTC) (envelope-from asmrookie@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 EECE513C46E for ; Mon, 23 Jul 2007 22:27:26 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by ug-out-1314.google.com with SMTP id o4so48118uge for ; Mon, 23 Jul 2007 15:27: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:reply-to:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding:sender; b=NjICRbp8IQg3AlWAqCGaV3MsGUMkU64ooiOIs0Q+QU1K4iP500rnqZXr+NCAYNGiQyB32Yzz9szlyb/Aww2agxy8WeWjKqSr8kq/a7Mnlr5EuVNuRKChmiQRDCETseljgC4LZPT7Ned1KNealnVCC0bsamUKVEWUheZ1xe6xEic= 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=fSjPK8W3LROxCtNVegkzow/PuIAOuttuZbJ4uYLiZ1TA0zmxr/GSdUIRcXDM0Zg+geDThNf3f+wI22g9VoBPJN6FTDfXnYtaTBrGoHSHJdPEkgSfPGzYouz/1Cz7cs+IvrBPGrXpBO+kwTjoWz+tPyEjri0apnw6rCxgfm5FZRk= Received: by 10.66.225.1 with SMTP id x1mr158133ugg.1185229645466; Mon, 23 Jul 2007 15:27:25 -0700 (PDT) Received: from ?151.75.245.150? ( [151.75.245.150]) by mx.google.com with ESMTPS id c14sm7558754nfi.2007.07.23.15.27.24 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 23 Jul 2007 15:27:25 -0700 (PDT) Message-ID: <46A52B19.9060909@FreeBSD.org> Date: Tue, 24 Jul 2007 00:26:33 +0200 From: Attilio Rao User-Agent: Thunderbird 1.5 (X11/20060526) MIME-Version: 1.0 To: Jeff Roberson References: <20070721174631.S561@10.0.0.1> <20070723152212.O561@10.0.0.1> In-Reply-To: <20070723152212.O561@10.0.0.1> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: Attilio Rao Cc: current@freebsd.org, Matt Subject: Re: ULE status, invalid load, buildkernel times. 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: Mon, 23 Jul 2007 22:27:27 -0000 Jeff Roberson wrote: > On Mon, 23 Jul 2007, Matt wrote: > >> On 7/21/07, Jeff Roberson wrote: >>> I have a patch available at: >>> >>> http://people.freebsd.org/~jeff/ulehtt.diff >>> >>> This resolves issues in the code that handles HTT enabled processors and >>> also adds some ULE information to bootverbose on SMP systems. Peter >>> Wemm >>> has a seperate patch that fixes a bug where some amd64 cpus were still >>> being misidentified as HTT. Those of you with invalid loads either have >>> Hyper-threading CPUs or misidentified amd cores. You should expect >>> slightly poorer performance as long as your cores are misidentified but >>> the bad loads should be fixed. >>> >>> I also believe that the buildkernel/world times are now significantly >>> improved. If this is not the case for you please send a mail. Any >>> other >>> performance data is appreciated. >>> >>> 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" >>> >> >> -current system with sources update July 22 at approx. 3PM central >> time with the ulehtt.diff patch applied experienced a panic this >> afternoon while restarting a local Apache Tomcat server. Backtrace >> information is shown below. Unclear to me whether or not the patch >> and the panic are related. > > I suspect that this is unrelated to my patch but I can't say for > certain. There have been some kse locking problems that Attilio has a > patch for. I believe it went in today. Hopefully he will comment. This is exactly the same bug pav@ experienced on amd64 machines some weeks ago. Basically, there is a race with ku_owner accesses which make it unconsistent in SMP / PREEMPTION systems. I committed a fix for that, but since I broke buildkernel too with that commit I would suggest to wait until the fix for a correct kernel building won't be committed (it should be rather soon though) and than to CVSup again sources. Thanks, Attilio From owner-freebsd-current@FreeBSD.ORG Mon Jul 23 22:29: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 DD4BB16A41B for ; Mon, 23 Jul 2007 22:29:34 +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 AC12713C45D for ; Mon, 23 Jul 2007 22:29:34 +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 198528579 for multiple; Mon, 23 Jul 2007 18:38:12 -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 l6NMTLoD002998; Mon, 23 Jul 2007 18:29:21 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org, gary.jennejohn@freenet.de Date: Mon, 23 Jul 2007 18:04:14 -0400 User-Agent: KMail/1.9.6 References: <20070703114248.37a2019b.garyj@jennejohn.org> In-Reply-To: <20070703114248.37a2019b.garyj@jennejohn.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200707231804.14770.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, 23 Jul 2007 18:29:22 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/3745/Mon Jul 23 17:01:34 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: Subject: Re: panic when printing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Jul 2007 22:29:35 -0000 On Tuesday 03 July 2007 05:42:48 am Gary Jennejohn wrote: > I haven't seen this reported before. > > Trying to print to my parallel printer with a -current kernel from July > 2 (amd64) results in a kernel panic. A kernel from June 16 (i386) does > not cause a panic. > > If I boot with the printer turned on then the kernel sees it (PnP) > with no problem. Just printing causes a panic. > > BTW this kernel is using the SMP-scheduler from Jeff Roberson, but > IIRC a different kernel (June 29) w/o that scheduler also panics. > > I can't say whether it's amd64-specific or just due to recent changes to > the sources. I'm rather reluctant to generate a new i386 kernel to check > that, but I could be persuaded to do it. > > Below a typescript of a very limited kgdb session: You got an interrupt after the lpt driver removed its handler. Really the ppbus device should not be so stupid and should have its own interrupt handler that routes interrupts to the "active" child. > root:peedub:crash:bash:1> gdb /boot/kernel/kernel vmcore.1 > [GDB will not be able to debug user-mode > threads: /usr/lib/libthread_db.so: Undefined symbol > "ps_pglobal_lookup"] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free > Software Foundation, Inc. GDB is free software, covered by the GNU > General Public License, and you are welcome to change it and/or > distribute copies of it under certain conditions. Type "show copying" > to see the conditions. There is absolutely no warranty for GDB. Type > "show warranty" for details. This GDB was configured as > "amd64-marcel-freebsd". > > Unread portion of the kernel message buffer: > lpt0: [GIANT-LOCKED] > lpt0: [ITHREAD] > lpt0: [GIANT-LOCKED] > lpt0: [ITHREAD] > lpt0: [GIANT-LOCKED] > lpt0: [ITHREAD] > lpt0: [GIANT-LOCKED] > lpt0: [ITHREAD] > lpt0: [GIANT-LOCKED] > lpt0: [ITHREAD] > lpt0: [GIANT-LOCKED] > lpt0: [ITHREAD] > lpt0: [GIANT-LOCKED] > lpt0: [ITHREAD] > lpt0: [GIANT-LOCKED] > lpt0: [ITHREAD] > lpt0: [GIANT-LOCKED] > lpt0: [ITHREAD] > > > Fatal trap 30: reserved (unknown) fault while in kernel mode > cpuid = 1; apic id = 01 > instruction pointer = 0x8:0xffffffff804ece83 > stack pointer = 0x10:0xffffffffaf97a760 > frame pointer = 0x10:0xffffffffaf97a780 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, IOPL = 0 > current process = 1980 (lpd) > trap number = 30 > panic: reserved (unknown) fault > cpuid = 1 > Uptime: 2h41m43s > Physical memory: 2037 MB > Dumping 977 MB: 961 945 929 913 897 881 865 849 833 817 801 785 769 753 > 737 721 705 689 673 657 641 625 609 593 577 561 545 529 513 497 481 465 > 449 433 417 401 385 369 353 337 321 305 289 273 257 241 225 209 193 177 > 161 145 129 113 97 81 65 49 33 17 1 > > #0 doadump () at pcpu.h:194 > 194 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) bt > #0 doadump () at pcpu.h:194 > #1 0xffffffff802f94db in boot (howto=260) > at /usr/src/sys/kern/kern_shutdown.c:409 > #2 0xffffffff802f97de in panic (fmt=Variable "fmt" is not available. > ) at /usr/src/sys/kern/kern_shutdown.c:563 > #3 0xffffffff804fec9c in trap_fatal (frame=0xffffffffaf97a6b0, eva=0) > at /usr/src/sys/amd64/amd64/trap.c:695 > #4 0xffffffff804ffaa3 in trap (frame=0xffffffffaf97a6b0) > at /usr/src/sys/amd64/amd64/trap.c:498 > #5 0xffffffff804e566e in calltrap () > at /usr/src/sys/amd64/amd64/exception.S:169 > #6 0xffffffff804ece83 in spinlock_exit () at cpufunc.h:391 > #7 0xffffffff804e9291 in ioapic_program_intpin > #(intpin=0xffffff0001043208) > at /usr/src/sys/amd64/amd64/io_apic.c:273 > #8 0xffffffff804e967a in ioapic_disable_intr (isrc=0xffffff0001043208) > at /usr/src/sys/amd64/amd64/io_apic.c:375 > #9 0xffffffff804e843d in intr_remove_handler (cookie=Variable "cookie" > #is not available. > ) > at /usr/src/sys/amd64/amd64/intr_machdep.c:217 > #10 0xffffffff804f23bc in nexus_teardown_intr (dev=Variable "dev" is > #not available. > ) > at /usr/src/sys/amd64/amd64/nexus.c:451 > #11 0xffffffff8031bf8f in bus_generic_teardown_intr > #(dev=0xffffffffabf30000, > child=0xffffff0003285b00, irq=0xffffff0003316480, > cookie=0xffffff001bf44100) at bus_if.h:416 > #12 0xffffffff8022fc9d in ppc_teardown_intr (bus=0xffffff0001216500, > child=0xffffff0003285b00, r=0xffffff0003316480, > ih=0xffffff001bf44100) at bus_if.h:416 > #13 0xffffffff8022e3f4 in ppbus_teardown_intr (bus=0xffffff0003286e00, > child=0xffffff0003285b00, r=Variable "r" is not available. > ) at bus_if.h:416 > #14 0xffffffff8022ef6a in ppb_release_bus (bus=0xffffff0003286e00, > dev=0xffffff0003285b00) at bus_if.h:416 > #15 0xffffffff8022a9a5 in lpt_release_ppbus (dev=0xffffff0003285b00) > at /usr/src/sys/dev/ppbus/lpt.c:227 > #16 0xffffffff8022b796 in lptwrite (dev=Variable "dev" is not available. > ) at /usr/src/sys/dev/ppbus/lpt.c:826 > #17 0xffffffff802c6f61 in giant_write (dev=0xffffff00032fe800, > uio=0xffffffffaf97ab00, ioflag=0) > at /usr/src/sys/kern/kern_conf.c:358 > #18 0xffffffff8028b9f7 in devfs_write_f (fp=0xffffff0003b092d0, > uio=0xffffffffaf97ab00, cred=Variable "cred" is not available. > ) at /usr/src/sys/fs/devfs/devfs_vnops.c:1290 > #19 0xffffffff8033058a in dofilewrite (td=0xffffff00039c5360, fd=6, > fp=0xffffff0003b092d0, auio=0xffffffffaf97ab00, offset=Variable > "offset" is not available. ) at file.h:254 > #20 0xffffffff8033080f in kern_writev (td=0xffffff00039c5360, fd=6, > auio=0xffffffffaf97ab00) at /usr/src/sys/kern/sys_generic.c:373 > #21 0xffffffff8033088b in write (td=0xffffffffabf30000, uap=0x1e) > at /usr/src/sys/kern/sys_generic.c:303 > #22 0xffffffff804ff2d1 in syscall (frame=0xffffffffaf97ac70) > at /usr/src/sys/amd64/amd64/trap.c:820 > #23 0xffffffff804e581b in Xfast_syscall () > at /usr/src/sys/amd64/amd64/exception.S:272 > #24 0x000000080071ccac in ?? () > Previous frame inner to this frame (corrupt stack?) > (kgdb) q > > --- > Gary Jennejohn / garyjATjennejohnDOTorg gjATfreebsdDOTorg > garyjATdenxDOTde > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Jul 23 22:51:22 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 35FFF16A41A; Mon, 23 Jul 2007 22:51:22 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id B02BC13C468; Mon, 23 Jul 2007 22:51:21 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.14.1/8.13.8) with ESMTP id l6NMpKoC010399; Mon, 23 Jul 2007 18:51:20 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.1/8.14.1) with ESMTP id l6NMpKu6041418; Mon, 23 Jul 2007 18:51:20 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 55E3E73068; Mon, 23 Jul 2007 18:51:20 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070723225120.55E3E73068@freebsd-current.sentex.ca> Date: Mon, 23 Jul 2007 18:51:20 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.91.1, clamav-milter version 0.91.1 on news X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2007 22:51:22 -0000 TB --- 2007-07-23 20:45:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-07-23 20:45:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2007-07-23 20:45:00 - cleaning the object tree TB --- 2007-07-23 20:45:40 - checking out the source tree TB --- 2007-07-23 20:45:40 - cd /tinderbox/HEAD/amd64/amd64 TB --- 2007-07-23 20:45:40 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-07-23 20:56:08 - building world (CFLAGS=-O2 -pipe) TB --- 2007-07-23 20:56:08 - cd /src TB --- 2007-07-23 20:56:08 - /usr/bin/make -B buildworld >>> World build started on Mon Jul 23 20:56:09 UTC 2007 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Mon Jul 23 22:40:48 UTC 2007 TB --- 2007-07-23 22:40:48 - generating LINT kernel config TB --- 2007-07-23 22:40:48 - cd /src/sys/amd64/conf TB --- 2007-07-23 22:40:48 - /usr/bin/make -B LINT TB --- 2007-07-23 22:40:48 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-07-23 22:40:48 - cd /src TB --- 2007-07-23 22:40:48 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Jul 23 22:40:48 UTC 2007 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/kern/kern_exit.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/kern/kern_fork.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/kern/kern_idle.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/kern/kern_intr.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/kern/kern_jail.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/kern/kern_kse.c cc1: warnings being treated as errors /src/sys/kern/kern_kse.c:87: warning: 'upcall_free' defined but not used *** Error code 1 Stop in /obj/amd64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-07-23 22:51:19 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-07-23 22:51:19 - ERROR: failed to build lint kernel TB --- 2007-07-23 22:51:19 - tinderbox aborted TB --- 0.95 user 3.66 system 7579.53 real http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Mon Jul 23 23:23: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 74D7316A418 for ; Mon, 23 Jul 2007 23:23:31 +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 A445F13C459 for ; Mon, 23 Jul 2007 23:23:30 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by ik-out-1112.google.com with SMTP id c21so1447209ika for ; Mon, 23 Jul 2007 16:23: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:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=ugEt/yXaYYyew/QzJw/+AjL3rChCBQVklzkEBtoxhZwtZT4+c3+TZqK5DG8/DBsdNHZM5Bmp7/8jqoVYAtzIyijnjWEptnFu1gYshegRe/lUjoooQ784Nv3jZMSrNbbGK/QIQCfp26Ro5OYgo4401HLGb01h+thJSkJv50R8Phs= 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=IVSU1Uemd5FP5KN176uUPUUHsQQbzpo8UVyiQ993uaGnAJfPOzZwZSO2O9UimFbaWqRa2Kcd1l6u499upqKS1XPABFPjO0dUu9Tx0LsZMI5PrK9rngzGP9g5urPn5oeE/oKrAIV4hI75GLPXZaUE/4Smd/22Tx30I1m0jjt4wHw= Received: by 10.78.140.16 with SMTP id n16mr900548hud.1185233009487; Mon, 23 Jul 2007 16:23:29 -0700 (PDT) Received: by 10.78.120.9 with HTTP; Mon, 23 Jul 2007 16:23:29 -0700 (PDT) Message-ID: <3bbf2fe10707231623r1390b1a2r52c2830831621245@mail.gmail.com> Date: Tue, 24 Jul 2007 01:23:29 +0200 From: "Attilio Rao" Sender: asmrookie@gmail.com To: "Jeff Roberson" In-Reply-To: <46A52B19.9060909@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070721174631.S561@10.0.0.1> <20070723152212.O561@10.0.0.1> <46A52B19.9060909@FreeBSD.org> X-Google-Sender-Auth: d4d3e9abdd2af2d2 Cc: current@freebsd.org, Matt Subject: Re: ULE status, invalid load, buildkernel 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, 23 Jul 2007 23:23:31 -0000 2007/7/24, Attilio Rao : > Jeff Roberson wrote: > > > > I suspect that this is unrelated to my patch but I can't say for > > certain. There have been some kse locking problems that Attilio has a > > patch for. I believe it went in today. Hopefully he will comment. > > This is exactly the same bug pav@ experienced on amd64 machines some > weeks ago. > Basically, there is a race with ku_owner accesses which make it > unconsistent in SMP / PREEMPTION systems. > I committed a fix for that, but since I broke buildkernel too with that > commit I would suggest to wait until the fix for a correct kernel > building won't be committed (it should be rather soon though) and than > to CVSup again sources. Ok, this is the good moment for a CVSup. Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Mon Jul 23 23:42: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 E465216A41B; Mon, 23 Jul 2007 23:42:24 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id AB5A713C458; Mon, 23 Jul 2007 23:42:24 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.13.8/8.13.8) with ESMTP id l6NNgOI2048686; Mon, 23 Jul 2007 19:42:24 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.8/8.13.8) with ESMTP id l6NNgNq7051814; Mon, 23 Jul 2007 19:42:23 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id BA64A73068; Mon, 23 Jul 2007 19:42:22 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070723234222.BA64A73068@freebsd-current.sentex.ca> Date: Mon, 23 Jul 2007 19:42:22 -0400 (EDT) X-Virus-Scanned: ClamAV version devel-20070102, clamav-milter version devel-111206 on clamscanner5 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2007 23:42:25 -0000 TB --- 2007-07-23 22:07:33 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-07-23 22:07:33 - starting HEAD tinderbox run for i386/i386 TB --- 2007-07-23 22:07:33 - cleaning the object tree TB --- 2007-07-23 22:08:08 - checking out the source tree TB --- 2007-07-23 22:08:08 - cd /tinderbox/HEAD/i386/i386 TB --- 2007-07-23 22:08:08 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-07-23 22:15:47 - building world (CFLAGS=-O2 -pipe) TB --- 2007-07-23 22:15:47 - cd /src TB --- 2007-07-23 22:15:47 - /usr/bin/make -B buildworld >>> World build started on Mon Jul 23 22:15:48 UTC 2007 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Mon Jul 23 23:30:55 UTC 2007 TB --- 2007-07-23 23:30:55 - generating LINT kernel config TB --- 2007-07-23 23:30:55 - cd /src/sys/i386/conf TB --- 2007-07-23 23:30:55 - /usr/bin/make -B LINT TB --- 2007-07-23 23:30:56 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-07-23 23:30:56 - cd /src TB --- 2007-07-23 23:30:56 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Jul 23 23:30:56 UTC 2007 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/kern/kern_exit.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/kern/kern_fork.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/kern/kern_idle.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/kern/kern_intr.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/kern/kern_jail.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/kern/kern_kse.c cc1: warnings being treated as errors /src/sys/kern/kern_kse.c:87: warning: 'upcall_free' defined but not used *** Error code 1 Stop in /obj/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-07-23 23:42:22 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-07-23 23:42:22 - ERROR: failed to build lint kernel TB --- 2007-07-23 23:42:22 - tinderbox aborted TB --- 0.84 user 3.03 system 5688.48 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Mon Jul 23 23:47: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 ABE5516A419 for ; Mon, 23 Jul 2007 23:47:41 +0000 (UTC) (envelope-from therior@ukr.net) Received: from ffe3.ukr.net (ffe3.ukr.net [195.214.192.14]) by mx1.freebsd.org (Postfix) with ESMTP id 45AE513C48E for ; Mon, 23 Jul 2007 23:47:41 +0000 (UTC) (envelope-from therior@ukr.net) Received: from mail by ffe3.ukr.net with local ID 1ID7KU-00002r-Nl for freebsd-current@freebsd.org; Tue, 24 Jul 2007 02:28:42 +0300 Content-Disposition: inline Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="windows-1251" MIME-Version: 1.0 To: freebsd-current@freebsd.org From: "freebsd kernel panic" X-Life: is great, enjoy it! X-Mailer: freemail.ukr.net mPOP 3.3 X-Originating-Ip: [194.242.59.98] X-Browser: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8.1.4) Gecko/20070715 Firefox/2.0.0.4 Message-Id: Date: Tue, 24 Jul 2007 02:28:42 +0300 Subject: a computer droops from a network map! 3com 3c905c-tx Fast Etherlink Xl X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Jul 2007 23:47:41 -0000 good afternoon! a computer droops from a network map! 3com 3c905c-tx Fast Etherlink Xl a network map is built-in, it is written on a system board, that network "1Gb"! before on freebsd 6.1 6.2 STABLE such was never, but I the world did not collect, only kernel! Tried to be connected to two channel, thought that error from a channel...! 1. I start dhclient, long thinks and does not determine Ipv4, do network configuration and routing I by hands. 2. start of Xorg: Mozilla and Firefox work in the internet - a computer hangs up. 3. mount Samba, copy a file, and after 2-10min. a computer hangs up, there was it 5-10 times. 4. ftp works normally.ok? I did not activate other interface! Tried everything that could, in delivery such is present nowhere, did not find! (it was only from 2000-2003 year) If I understood correctly, an error is in a kernel.(if_xl.c???)? In ravines (log) nothing is present about it! Tried to turn off and include apci... I want to include this network because for it speed to become very rapid what at other network maps! (at home on Adsl2+) ********************************* 3com 3c905c-tx Fast Etherlink Xl Jul 15 22:52:49 dhcppc0 kernel: xl0: <3Com 3c905C-TX Fast Etherlink XL> port 0xa400-0xa47f mem 0xf7000000-0xf700007f irq 23 at device 11.0 on pci2 Jul 15 22:52:49 dhcppc0 kernel: miibus0: on xl0 Jul 15 22:52:49 dhcppc0 kernel: e1000phy0: PHY 24 on miibus0 Jul 15 22:52:49 dhcppc0 kernel: e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto Jul 15 22:52:49 dhcppc0 kernel: xl0: Ethernet address: 00:0d:87:5b:ee:b5 Jul 15 22:52:49 dhcppc0 kernel: xl0: [ITHREAD] #ifconfig ed0: flags=8843 metric 0 mtu 1500 ether 52:54:ab:13:61:56 inet 192.168.1.33 netmask 0xffffff00 broadcast 192.168.1.255 media: Ethernet autoselect (10baseT/UTP) xl0: flags=8802 metric 0 mtu 1500 options=9 ether 00:0d:87:5b:ee:b5 inet 192.168.1.34 netmask 0xffffff00 broadcast 192.168.1.255 media: Ethernet autoselect (100baseTX ) status: active plip0: flags=108810 metric 0 mtu 1500 lo0: flags=8049 metric 0 mtu 16384 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff000000 # uname -a FreeBSD dhcppc0 7.0-CURRENT FreeBSD 7.0-CURRENT #1: Sun Jul 15 21:51:08 EEST 2007 root@dhcppc0:/usr/obj/usr/src/sys/MYKERNEL i386 machine i386 cpu I686_CPU ident MYKERNEL # 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 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 COMPAT_43 # Compatible with BSD 4.3 [KEEP THIS!] options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options COMPAT_FREEBSD5 # Compatible with FreeBSD5 options COMPAT_FREEBSD6 # Compatible with FreeBSD6 options SCSI_DELAY=1000 # 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 AUDIT # Security event auditing options IPFIREWALL options IPDIVERT options IPFIREWALL_DEFAULT_TO_ACCEPT options IPFIREWALL_VERBOSE_LIMIT=5 options IPFIREWALL_FORWARD options IPFIREWALL_VERBOSE options IPSTEALTH options DUMMYNET # Debugging for use in -current 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 COMPAT_LINUX # HARDWARE DEVICE CONFIGURATION #options DEVICE_POLLING # To include support for VGA VESA video modes options VESA # Turn on extra debugging checks and output for VESA support. options VESA_DEBUG device acpi options ACPI_DEBUG #!options ACPI_NO_SEMAPHORES # ACPI Video Extensions (LCD backlight/brightness, video output, etc.) device acpi_video # Bus support. device pci # ATA and ATAPI devices device ata device atapicam device atadisk # ATA disk drives device atapicd # ATAPI CDROM drives # SCSI peripherals device scbus # SCSI bus (required for SCSI) device da # Direct Access (disks) device cd # CD device pass # Passthrough device (direct SCSI access) device vga # VGA video card driver # The following option probably won't work with the LCD displays. options VGA_WIDTH90 # support 90 column modes options VGA_DEBUG 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 sound device snd_ich device logo_saver # Serial (COM) ports device sio # 8250, 16[45]50 based serial ports # 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 xl # 3Com 3c90x (``Boomerang'', ``Cyclone'') # 'device ed' requires 'device miibus' device ed # NE[12]000, SMC Ultra, 3c503, DS8390 cards 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 device bpf # Berkeley packet filter 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 ugen # Generic device uhid # "Human Interface Devices" device ukbd # Keyboard device umass # Disks/Mass storage - Requires scbus and da From owner-freebsd-current@FreeBSD.ORG Mon Jul 23 23:55: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 1787616A417 for ; Mon, 23 Jul 2007 23:55:25 +0000 (UTC) (envelope-from therior@ukr.net) Received: from kitty.ukr.net (kitty.ukr.net [212.42.65.67]) by mx1.freebsd.org (Postfix) with ESMTP id F215A13C45D for ; Mon, 23 Jul 2007 23:55:23 +0000 (UTC) (envelope-from therior@ukr.net) Received: from mail by kitty.ukr.net with local ID 1ID7RK-0008n5-Po for freebsd-current@freebsd.org; Tue, 24 Jul 2007 02:35:46 +0300 MIME-Version: 1.0 To: freebsd-current@freebsd.org From: "freebsd kernel panic" X-Life: is great, enjoy it! X-Mailer: freemail.ukr.net mPOP 3.3 X-Originating-Ip: [194.242.59.98] X-Browser: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8.1.4) Gecko/20070715 Firefox/2.0.0.4 Message-Id: Date: Tue, 24 Jul 2007 02:35:46 +0300 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: 8bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: a computer droops from a network map! 3com 3c905c-tx Fast Etherlink Xl X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Jul 2007 23:55:25 -0000 good afternoon! a computer droops from a network map! 3com 3c905c-tx Fast Etherlink Xl a network map is built-in, it is written on a system board, that network "1Gb"! before on freebsd 6.1 6.2 STABLE such was never, but I the world did not collect, only kernel! Tried to be connected to two channel, thought that error from a channel...! 1. I start dhclient, long thinks and does not determine Ipv4, do network configuration and routing I by hands. 2. start of Xorg: Mozilla and Firefox work in the internet - a computer hangs up. 3. mount Samba, copy a file, and after 2-10min. a computer hangs up, there was it 5-10 times. 4. ftp works normally.ok? I did not activate other interface! Tried everything that could, in delivery such is present nowhere, did not find! (it was only from 2000-2003 year) If I understood correctly, an error is in a kernel.(if_xl.c???)? In ravines (log) nothing is present about it! Tried to turn off and include apci... I want to include this network because for it speed to become very rapid what at other network maps! (at home on Adsl2+) ********************************* 3com 3c905c-tx Fast Etherlink Xl Jul 15 22:52:49 dhcppc0 kernel: xl0: <3Com 3c905C-TX Fast Etherlink XL> port 0xa400-0xa47f mem 0xf7000000-0xf700007f irq 23 at device 11.0 on pci2 Jul 15 22:52:49 dhcppc0 kernel: miibus0: on xl0 Jul 15 22:52:49 dhcppc0 kernel: e1000phy0: PHY 24 on miibus0 Jul 15 22:52:49 dhcppc0 kernel: e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto Jul 15 22:52:49 dhcppc0 kernel: xl0: Ethernet address: 00:0d:87:5b:ee:b5 Jul 15 22:52:49 dhcppc0 kernel: xl0: [ITHREAD] #ifconfig ed0: flags=8843 metric 0 mtu 1500 ether 52:54:ab:13:61:56 inet 192.168.1.33 netmask 0xffffff00 broadcast 192.168.1.255 media: Ethernet autoselect (10baseT/UTP) xl0: flags=8802 metric 0 mtu 1500 options=9 ether 00:0d:87:5b:ee:b5 inet 192.168.1.34 netmask 0xffffff00 broadcast 192.168.1.255 media: Ethernet autoselect (100baseTX ) status: active plip0: flags=108810 metric 0 mtu 1500 lo0: flags=8049 metric 0 mtu 16384 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff000000 # uname -a FreeBSD dhcppc0 7.0-CURRENT FreeBSD 7.0-CURRENT #1: Sun Jul 15 21:51:08 EEST 2007 root@dhcppc0:/usr/obj/usr/src/sys/MYKERNEL i386 machine i386 cpu I686_CPU ident MYKERNEL # 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 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 COMPAT_43 # Compatible with BSD 4.3 [KEEP THIS!] options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options COMPAT_FREEBSD5 # Compatible with FreeBSD5 options COMPAT_FREEBSD6 # Compatible with FreeBSD6 options SCSI_DELAY=1000 # 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 AUDIT # Security event auditing options IPFIREWALL options IPDIVERT options IPFIREWALL_DEFAULT_TO_ACCEPT options IPFIREWALL_VERBOSE_LIMIT=5 options IPFIREWALL_FORWARD options IPFIREWALL_VERBOSE options IPSTEALTH options DUMMYNET # Debugging for use in -current 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 COMPAT_LINUX # HARDWARE DEVICE CONFIGURATION #options DEVICE_POLLING # To include support for VGA VESA video modes options VESA # Turn on extra debugging checks and output for VESA support. options VESA_DEBUG device acpi options ACPI_DEBUG #!options ACPI_NO_SEMAPHORES # ACPI Video Extensions (LCD backlight/brightness, video output, etc.) device acpi_video # Bus support. device pci # ATA and ATAPI devices device ata device atapicam device atadisk # ATA disk drives device atapicd # ATAPI CDROM drives # SCSI peripherals device scbus # SCSI bus (required for SCSI) device da # Direct Access (disks) device cd # CD device pass # Passthrough device (direct SCSI access) device vga # VGA video card driver # The following option probably won't work with the LCD displays. options VGA_WIDTH90 # support 90 column modes options VGA_DEBUG 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 sound device snd_ich device logo_saver # Serial (COM) ports device sio # 8250, 16[45]50 based serial ports # 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 xl # 3Com 3c90x (``Boomerang'', ``Cyclone'') # 'device ed' requires 'device miibus' device ed # NE[12]000, SMC Ultra, 3c503, DS8390 cards 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 device bpf # Berkeley packet filter 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 ugen # Generic device uhid # "Human Interface Devices" device ukbd # Keyboard device umass # Disks/Mass storage - Requires scbus and da From owner-freebsd-current@FreeBSD.ORG Mon Jul 23 23:55:28 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 EC3C516A41A for ; Mon, 23 Jul 2007 23:55:27 +0000 (UTC) (envelope-from therior@ukr.net) Received: from kitty.ukr.net (kitty.ukr.net [212.42.65.67]) by mx1.freebsd.org (Postfix) with ESMTP id 4B34513C46C for ; Mon, 23 Jul 2007 23:55:27 +0000 (UTC) (envelope-from therior@ukr.net) Received: from mail by kitty.ukr.net with local ID 1ID7Qq-0008lB-VI for freebsd-current@freebsd.org; Tue, 24 Jul 2007 02:35:17 +0300 MIME-Version: 1.0 To: freebsd-current@freebsd.org From: "freebsd kernel panic" X-Life: is great, enjoy it! X-Mailer: freemail.ukr.net mPOP 3.3 X-Originating-Ip: [194.242.59.98] X-Browser: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8.1.4) Gecko/20070715 Firefox/2.0.0.4 Message-Id: Date: Tue, 24 Jul 2007 02:35:16 +0300 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: 8bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: a computer droops from a network map! 3com 3c905c-tx Fast Etherlink Xl X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Jul 2007 23:55:28 -0000 good afternoon! a computer droops from a network map! 3com 3c905c-tx Fast Etherlink Xl a network map is built-in, it is written on a system board, that network "1Gb"! before on freebsd 6.1 6.2 STABLE such was never, but I the world did not collect, only kernel! Tried to be connected to two channel, thought that error from a channel...! 1. I start dhclient, long thinks and does not determine Ipv4, do network configuration and routing I by hands. 2. start of Xorg: Mozilla and Firefox work in the internet - a computer hangs up. 3. mount Samba, copy a file, and after 2-10min. a computer hangs up, there was it 5-10 times. 4. ftp works normally.ok? I did not activate other interface! Tried everything that could, in delivery such is present nowhere, did not find! (it was only from 2000-2003 year) If I understood correctly, an error is in a kernel.(if_xl.c???)? In ravines (log) nothing is present about it! Tried to turn off and include apci... I want to include this network because for it speed to become very rapid what at other network maps! (at home on Adsl2+) ********************************* 3com 3c905c-tx Fast Etherlink Xl Jul 15 22:52:49 dhcppc0 kernel: xl0: <3Com 3c905C-TX Fast Etherlink XL> port 0xa400-0xa47f mem 0xf7000000-0xf700007f irq 23 at device 11.0 on pci2 Jul 15 22:52:49 dhcppc0 kernel: miibus0: on xl0 Jul 15 22:52:49 dhcppc0 kernel: e1000phy0: PHY 24 on miibus0 Jul 15 22:52:49 dhcppc0 kernel: e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto Jul 15 22:52:49 dhcppc0 kernel: xl0: Ethernet address: 00:0d:87:5b:ee:b5 Jul 15 22:52:49 dhcppc0 kernel: xl0: [ITHREAD] #ifconfig ed0: flags=8843 metric 0 mtu 1500 ether 52:54:ab:13:61:56 inet 192.168.1.33 netmask 0xffffff00 broadcast 192.168.1.255 media: Ethernet autoselect (10baseT/UTP) xl0: flags=8802 metric 0 mtu 1500 options=9 ether 00:0d:87:5b:ee:b5 inet 192.168.1.34 netmask 0xffffff00 broadcast 192.168.1.255 media: Ethernet autoselect (100baseTX ) status: active plip0: flags=108810 metric 0 mtu 1500 lo0: flags=8049 metric 0 mtu 16384 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff000000 # uname -a FreeBSD dhcppc0 7.0-CURRENT FreeBSD 7.0-CURRENT #1: Sun Jul 15 21:51:08 EEST 2007 root@dhcppc0:/usr/obj/usr/src/sys/MYKERNEL i386 machine i386 cpu I686_CPU ident MYKERNEL # 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 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 COMPAT_43 # Compatible with BSD 4.3 [KEEP THIS!] options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options COMPAT_FREEBSD5 # Compatible with FreeBSD5 options COMPAT_FREEBSD6 # Compatible with FreeBSD6 options SCSI_DELAY=1000 # 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 AUDIT # Security event auditing options IPFIREWALL options IPDIVERT options IPFIREWALL_DEFAULT_TO_ACCEPT options IPFIREWALL_VERBOSE_LIMIT=5 options IPFIREWALL_FORWARD options IPFIREWALL_VERBOSE options IPSTEALTH options DUMMYNET # Debugging for use in -current 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 COMPAT_LINUX # HARDWARE DEVICE CONFIGURATION #options DEVICE_POLLING # To include support for VGA VESA video modes options VESA # Turn on extra debugging checks and output for VESA support. options VESA_DEBUG device acpi options ACPI_DEBUG #!options ACPI_NO_SEMAPHORES # ACPI Video Extensions (LCD backlight/brightness, video output, etc.) device acpi_video # Bus support. device pci # ATA and ATAPI devices device ata device atapicam device atadisk # ATA disk drives device atapicd # ATAPI CDROM drives # SCSI peripherals device scbus # SCSI bus (required for SCSI) device da # Direct Access (disks) device cd # CD device pass # Passthrough device (direct SCSI access) device vga # VGA video card driver # The following option probably won't work with the LCD displays. options VGA_WIDTH90 # support 90 column modes options VGA_DEBUG 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 sound device snd_ich device logo_saver # Serial (COM) ports device sio # 8250, 16[45]50 based serial ports # 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 xl # 3Com 3c90x (``Boomerang'', ``Cyclone'') # 'device ed' requires 'device miibus' device ed # NE[12]000, SMC Ultra, 3c503, DS8390 cards 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 device bpf # Berkeley packet filter 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 ugen # Generic device uhid # "Human Interface Devices" device ukbd # Keyboard device umass # Disks/Mass storage - Requires scbus and da From owner-freebsd-current@FreeBSD.ORG Mon Jul 23 23:47: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 7628C16A529 for ; Mon, 23 Jul 2007 23:47:46 +0000 (UTC) (envelope-from tom@hur.st) Received: from spork.qfe3.net (spork.qfe3.net [212.13.207.101]) by mx1.freebsd.org (Postfix) with ESMTP id 370BC13C4A3 for ; Mon, 23 Jul 2007 23:47:45 +0000 (UTC) (envelope-from tom@hur.st) Received: from [81.104.144.87] (helo=voi.aagh.net) by spork.qfe3.net with esmtp (Exim 4.66 (FreeBSD)) (envelope-from ) id 1ID7I3-000A79-9E; Tue, 24 Jul 2007 00:26:11 +0100 Received: from freaky by voi.aagh.net with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ID7I3-0007c9-4c; Tue, 24 Jul 2007 00:26:11 +0100 Date: Tue, 24 Jul 2007 00:26:11 +0100 From: Thomas Hurst To: Chris Dionissopoulos Message-ID: <20070723232611.GA28890@voi.aagh.net> Mail-Followup-To: Chris Dionissopoulos , Jeff Roberson , current@freebsd.org References: <20070721174631.S561@10.0.0.1> <1807103749.20070722111025@freemail.gr> <20070722014208.G561@10.0.0.1> <684796249.20070722134105@freemail.gr> <20070722160935.GA18069@voi.aagh.net> <751338143.20070722232925@freemail.gr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <751338143.20070722232925@freemail.gr> Organization: Not much. User-Agent: Mutt/1.5.15 (2007-04-06) Sender: Thomas Hurst X-Mailman-Approved-At: Mon, 23 Jul 2007 23:59:38 +0000 Cc: Jeff Roberson , current@freebsd.org Subject: Re: ULE status, invalid load, buildkernel 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, 23 Jul 2007 23:47:46 -0000 * Chris Dionissopoulos (dionch@freemail.gr) wrote: > Its an Intel c2d-6300 (see prev. messages) using cpufreq(4). > Everything works fine (for 6 months or more) with 4BSD or > ULE2/3(unpatched) scheduler. > > AFAIK, the problem Jeff trying to resolve is why a ULE3(+last patch) > kernel, produces panics when a process touches cpufreq(4) context. Yes, I don't mean to say the problem lies specifically in acpi_throttle, just that I've seen "it used to work but doesn't any more" as a result of it, and it may be worth trying. The large number and range of frequencies suggests you have it loaded, since as far as I know neither Cool'n'Quiet nor SpeedStep scale that low on their own. -- Thomas 'Freaky' Hurst http://hur.st/ From owner-freebsd-current@FreeBSD.ORG Tue Jul 24 00:22:12 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 17C4B16A418 for ; Tue, 24 Jul 2007 00:22:12 +0000 (UTC) (envelope-from dmw@unete.cl) Received: from mail06.ifxnetworks.com (mail06.ifxnetworks.com [190.61.128.16]) by mx1.freebsd.org (Postfix) with ESMTP id AA76C13C45A for ; Tue, 24 Jul 2007 00:22:11 +0000 (UTC) (envelope-from dmw@unete.cl) Received: (qmail 472 invoked from network); 24 Jul 2007 00:22:10 -0000 X-Spam-DCC: EATSERVER: mail06.ifxnetworks.com 1166; Body=1 Fuz1=1 Fuz2=1 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on mail06.ifxnetworks.com X-Spam-Level: X-Spam-Status: No, score=0.1 required=7.0 tests=RDNS_NONE autolearn=disabled version=3.2.1 Received: from unknown (HELO quake) (dmw@unete.cl@[200.73.82.7]) (envelope-sender ) by mail06.ifxnetworks.com (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 24 Jul 2007 00:22:10 -0000 From: Daniel Molina Wegener Organization: DMW To: freebsd-current@freebsd.org Date: Mon, 23 Jul 2007 20:21:30 -0400 User-Agent: KMail/1.9.6 References: <200707212023.03993.dmw@unete.cl> In-Reply-To: <200707212023.03993.dmw@unete.cl> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200707232021.31101.dmw@unete.cl> Subject: Re: Every time I get the sources I can't compile... 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: Tue, 24 Jul 2007 00:22:12 -0000 On Saturday 21 July 2007 20:23:03 Daniel Molina Wegener wrote: > Hello, > > Every time I get the sources I can't compile the source tree, > buildworld fails or buildkernel fails. =C2=BFIs any way to know > which revision is working? > > I've tried with the GENERIC kernel and fails, custom kernel > configurations fails too. > > =C2=BFAny way to get a working copy of -CURRENT? > > Regards, Sorry to all, I don't want to be a troll... but the last times trying to compile the kernel was a hell. Regards, =2D-=20 .O. | Daniel Molina Wegener | C/C++ Developer ..O | dmw [at] unete [dot] cl | FOSS Coding Adict OOO | FreeBSD & Linux User | Standards Rocks! From owner-freebsd-current@FreeBSD.ORG Tue Jul 24 00:44: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 1596516A418; Tue, 24 Jul 2007 00:44:20 +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 64C3213C457; Tue, 24 Jul 2007 00:44:19 +0000 (UTC) (envelope-from timur@com.bat.ru) Received: by mail.bat.ru (CommuniGate Pro PIPE 4.2.7) with PIPE id 497451; Tue, 24 Jul 2007 02:46:01 +0200 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 497426; Tue, 24 Jul 2007 02:45:48 +0200 Received: (from timur@localhost) by timur.home.bat.ru (8.14.1/8.14.1/Submit) id l6O0i44X031417; Tue, 24 Jul 2007 02:44:04 +0200 (CEST) (envelope-from timur) Date: Tue, 24 Jul 2007 02:44:04 +0200 From: "Timur I. Bakeyev" To: tridge@samba.org Message-ID: <20070724004404.GE1874@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> <20070721215822.GA1874@com.bat.ru> <18082.45557.77020.398761@samba.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <18082.45557.77020.398761@samba.org> User-Agent: mutt-ng/devel-r804 (FreeBSD) Cc: current , "Timur I. Bakeyev" , 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: Tue, 24 Jul 2007 00:44:20 -0000 Hi, Andrew! On Sun, Jul 22, 2007 at 11:25:09AM +1000, tridge@samba.org wrote: > Timur, > > > 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 > > yes, this is a long standing problem. Basically we need > telldir()/seekdir() to actually work, and not consume unlimited > amounts of memory. Thanks a lot for your perfect explanation! I forgot a lot of details about this problem, as first time faced with it exactly two years ago: -rw-r--r-- 1 root wheel 564 Jul 25 2005 repdir.h Sorry, if it sounded like I was blaming you for the existing problem, I know that the ball is on our side :) > The original problems were: > > - when you use seekdir() after having deleted a file in the > directory, you end up in the wrong place in the directory > stream. > > - on some systems each telldir() allocates some memory, adding it to > a linked list. So if you do it a few million times then you lose a > lot of memory, and the closedir() takes an extraordinary amount of > time as it slowly frees the linked list I think this is a result of using DIRHASH optimisation, we should check, how the things work if it is disabled. > and here is some test code that demonstrates the problem: > > http://samba.org/ftp/unpacked/samba4/source/lib/replace/test/os2_delete.c I managed to find and old copy of the code you've sent me 2 years ago in my /tmp nothing is more persistent than temporary :) > There are many possible "quick fixes" in Samba. Unfortunately they > tend to have O(n^2) time or O(dirsize) memory usage, or both. That's > no good unfortunately. I think, I should create a PR about this problem and let kernel developers to find the possible solution. Still, taking into accound all the above it's strange, that Samba 3.0.24 was able to work with FS other than UFS flawlessly, but now Samba 3.0.25 croaks on just read attempt when accessing FAT FS or ISO9660. Something has changed in the code so a different route is taken. So, this have to be investigated farther. Thanks a lot for your help again! With best regards, Timur. From owner-freebsd-current@FreeBSD.ORG Tue Jul 24 01:40: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 E2C4816A419 for ; Tue, 24 Jul 2007 01:40:24 +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 9123513C45A for ; Tue, 24 Jul 2007 01:40:24 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.samsco.home (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.8/8.13.8) with ESMTP id l6O1eHRE098502; Mon, 23 Jul 2007 19:40:18 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <46A5587F.7030003@samsco.org> Date: Mon, 23 Jul 2007 19:40:15 -0600 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> <469EEF02.7000804@samsco.org> <09BFF2FA5EAB4A45B6655E151BBDD9030483F728@NT-IRVA-0750.brcm.ad.broadcom.com> In-Reply-To: <09BFF2FA5EAB4A45B6655E151BBDD9030483F728@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]); Mon, 23 Jul 2007 19:40:18 -0600 (MDT) X-Spam-Status: No, score=-1.4 required=5.5 tests=ALL_TRUSTED autolearn=failed version=3.1.8 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: Tue, 24 Jul 2007 01:40:25 -0000 David Christensen wrote: >> 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. > >> 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(). > > 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 > 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. There is no way to tell busdma "give me no less than N number of segments" because that is generally not a useful task for bio and mbuf operations (though it is useful for static allocations, and is a feature that is on the TODO list). For the purposes of validation like what you want, you're going to have write either a custom mbuf injector that creates an mbuf chain of a header and N number of clusters that are each allocated separately and only filled partially, or you're going to have to do manual splitting of the segments that busdma gives you. > >> 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. > > No practical limit on the segment size. Anything between 1 byte and > 9KB is fine. > >> 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. > > 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 > 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 > SG entries have the same number of slots (which also happens to be > evenly divisible by the total number of slots available in the ring). > >> 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. > > Others have reported that single, larger segments provide better > 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 > 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? > Useful data points. For the case where the operation is limited by host CPU cycles (as is often the case with 10Gb right now), offloading more of the DMA segmentation work to the chip is desirable, even if the overall outcome isn't completely ideal. For your question about RX mbufs, look at the if_ti driver. It was specifically designed with RX header splitting in mind and specifically handles what you are talking about. If header splitting becomes more interesting again, it might be useful to move some of this out of the drivers and into the mbuf allocator. Scott From owner-freebsd-current@FreeBSD.ORG Tue Jul 24 02:42:45 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 C869516A417; Tue, 24 Jul 2007 02:42:45 +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 B147513C469; Tue, 24 Jul 2007 02:42:45 +0000 (UTC) (envelope-from craig@xfoil.gank.org) Received: by ion.gank.org (Postfix, from userid 1001) id 2082611246; Mon, 23 Jul 2007 21:42:45 -0500 (CDT) Date: Mon, 23 Jul 2007 21:42:43 -0500 From: Craig Boston To: Andrew Thompson Message-ID: <20070724024242.GA69061@nowhere> References: <20070619011908.GA53748@heff.fud.org.nz> <20070620042023.GA17424@nowhere> <4678B1E4.7080909@errno.com> <467ED084.4000002@petri.cc> <46A484CA.8030805@petri.cc> <20070723114821.GA6575@heff.fud.org.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070723114821.GA6575@heff.fud.org.nz> User-Agent: Mutt/1.4.2.2i Cc: FreeBSD Current Subject: Re: wireless X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2007 02:42:45 -0000 On Mon, Jul 23, 2007 at 11:48:21PM +1200, Andrew Thompson wrote: > You can test this WIP. Hi, This patch definitely is a big step in the right direction. The first time I booted with the patch, there were so many debug messages spamming the console it made the machine completely unusable (VESA raster console couldn't keep up, heh). After setting debug.ipw=0 things seem to be working much better. I can manually associate with an open AP just fine. Don't have any in range with WEP to try at the moment. The big news however, which I've been holding my breath about since skimming the patch this morning but didn't want to be too hopeful until I actually tried it, is WPA (TKIP) works! That's something that ipw hasn't supported at all until now, so I'm quite excited about it. The first time when I ran wpa_supplicant by hand it seemed to work for a minute, but lost connectivity while dhclient was requesting a lease. It worked long enough to get a NAK response for an old address, but never saw any response to discover requests after that. Manually setting an address didn't help either. ifconfig still showed Associated but no packets were being received. There was an "ipw0: scan suck" message on the console right about this time but nothing else to indicate a problem. After rebooting and letting it happen automatically with the rc scripts it seems to be stable now. I'm not 100% sure how often TKIP changes the key, but I'm certain this has been up and running long enough for it to have rotate a few times at least. Will have to do some more testing to see if the stuck scan was a fluke or if I can reproduce it. Great work! Craig From owner-freebsd-current@FreeBSD.ORG Tue Jul 24 02:49: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 40DBC16A417 for ; Tue, 24 Jul 2007 02:49:02 +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 C336613C45B for ; Tue, 24 Jul 2007 02:49:01 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: by heff.fud.org.nz (Postfix, from userid 1001) id 5065D1CC58; Tue, 24 Jul 2007 14:49:00 +1200 (NZST) Date: Tue, 24 Jul 2007 14:49:00 +1200 From: Andrew Thompson To: Craig Boston Message-ID: <20070724024900.GB12291@heff.fud.org.nz> References: <20070619011908.GA53748@heff.fud.org.nz> <20070620042023.GA17424@nowhere> <4678B1E4.7080909@errno.com> <467ED084.4000002@petri.cc> <46A484CA.8030805@petri.cc> <20070723114821.GA6575@heff.fud.org.nz> <20070724024242.GA69061@nowhere> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070724024242.GA69061@nowhere> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: FreeBSD Current Subject: Re: wireless X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2007 02:49:02 -0000 On Mon, Jul 23, 2007 at 09:42:43PM -0500, Craig Boston wrote: > On Mon, Jul 23, 2007 at 11:48:21PM +1200, Andrew Thompson wrote: > > You can test this WIP. > > Hi, > > This patch definitely is a big step in the right direction. > > The first time I booted with the patch, there were so many debug > messages spamming the console it made the machine completely unusable > (VESA raster console couldn't keep up, heh). > > After setting debug.ipw=0 things seem to be working much better. I can > manually associate with an open AP just fine. Don't have any in range > with WEP to try at the moment. I diffed it straight from my dev box and forgot that I had bumped up the debugging quite high. You can change ipw_debug near the top of the file back to zero. > The big news however, which I've been holding my breath about since > skimming the patch this morning but didn't want to be too hopeful until > I actually tried it, is WPA (TKIP) works! That's something that ipw > hasn't supported at all until now, so I'm quite excited about it. > > The first time when I ran wpa_supplicant by hand it seemed to work for a > minute, but lost connectivity while dhclient was requesting a lease. It > worked long enough to get a NAK response for an old address, but never > saw any response to discover requests after that. Manually setting an > address didn't help either. ifconfig still showed Associated but no > packets were being received. There was an "ipw0: scan suck" message on > the console right about this time but nothing else to indicate a > problem. > > After rebooting and letting it happen automatically with the rc scripts > it seems to be stable now. I'm not 100% sure how often TKIP changes the > key, but I'm certain this has been up and running long enough for it to > have rotate a few times at least. > > Will have to do some more testing to see if the stuck scan was a fluke > or if I can reproduce it. Thanks for the report. The reason I hadnt sent it out until now was that I am also bumping into these problems on my test system. I have been sorting out some ndis issues lately but will get back to testing ipw this week. cheers, Andrew From owner-freebsd-current@FreeBSD.ORG Tue Jul 24 03:16: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 7075616A417; Tue, 24 Jul 2007 03:16:46 +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 596C713C45A; Tue, 24 Jul 2007 03:16:46 +0000 (UTC) (envelope-from craig@xfoil.gank.org) Received: by ion.gank.org (Postfix, from userid 1001) id DE81411241; Mon, 23 Jul 2007 22:16:45 -0500 (CDT) Date: Mon, 23 Jul 2007 22:16:45 -0500 From: Craig Boston To: Andrew Thompson Message-ID: <20070724031645.GB69061@nowhere> References: <20070619011908.GA53748@heff.fud.org.nz> <20070620042023.GA17424@nowhere> <4678B1E4.7080909@errno.com> <467ED084.4000002@petri.cc> <46A484CA.8030805@petri.cc> <20070723114821.GA6575@heff.fud.org.nz> <20070724024242.GA69061@nowhere> <20070724024900.GB12291@heff.fud.org.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070724024900.GB12291@heff.fud.org.nz> User-Agent: Mutt/1.4.2.2i Cc: FreeBSD Current Subject: Re: wireless X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2007 03:16:46 -0000 On Tue, Jul 24, 2007 at 02:49:00PM +1200, Andrew Thompson wrote: > Thanks for the report. The reason I hadnt sent it out until now was that > I am also bumping into these problems on my test system. I have been > sorting out some ndis issues lately but will get back to testing ipw > this week. Oh, I did forget to mention one thing I had noticed. At bootup, after all the rc scripts had finished, I got this message: ipw0: link state changed to DOWN ipw0: timeout waiting for ipw_bss firmware initialization to complete ipw0: could not load firmware However it seems to be harmless. Everything is working, despite the claim that the firmware couldn't be loaded. Craig From owner-freebsd-current@FreeBSD.ORG Tue Jul 24 03:24:54 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 5E31416A418; Tue, 24 Jul 2007 03:24:54 +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 1654D13C458; Tue, 24 Jul 2007 03:24:54 +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 577AEEB78D0; Tue, 24 Jul 2007 11:24:53 +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 UEmsTaO2n-Ni; Tue, 24 Jul 2007 11:24:50 +0800 (CST) Received: from charlie.delphij.net (unknown [61.49.186.182]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id 7504DEB7829; Tue, 24 Jul 2007 11:24:50 +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=BdQd1O9QlSVV05gNDu7qPPtP+gvfgXzKi3hfKk0rMP+B9eAC0iJxlKct5rr3r4wO1 pwLGqZI7Q+PpXsZoMox7Q== Message-ID: <46A57101.5020805@delphij.net> Date: Tue, 24 Jul 2007 11:24:49 +0800 From: Xin LI User-Agent: Thunderbird 2.0.0.5 (X11/20070721) MIME-Version: 1.0 To: Alexander Kabaev References: <20070723154858.5C5F645045@ptavv.es.net> <20070723175234.Q83919@fledge.watson.org> <46A4DF9C.7060204@delphij.net> <8e5ef5f70707231011y4b732080n9c23793d1083f56a@mail.gmail.com> In-Reply-To: <8e5ef5f70707231011y4b732080n9c23793d1083f56a@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Robert Watson , current@freebsd.org Subject: Re: gcc 4.2.1 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: Tue, 24 Jul 2007 03:24:54 -0000 Alexander Kabaev wrote: > http://people.freebsd.org/~kan/contrib-gcc421.tar.gz > > This is 4.2.1-release snapshot, currently it should be under test on > package cluster. Great! Thanks for the work :-) Cheers, From owner-freebsd-current@FreeBSD.ORG Tue Jul 24 05:42: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 AE04916A419 for ; Tue, 24 Jul 2007 05:42:51 +0000 (UTC) (envelope-from n-butcher=freebsd-current=freebsd.org=sbibybnr@fusiongol.com) Received: from smtp02.dentaku.gol.com (smtp02.dentaku.gol.com [203.216.5.72]) by mx1.freebsd.org (Postfix) with ESMTP id 8165013C428 for ; Tue, 24 Jul 2007 05:42:51 +0000 (UTC) (envelope-from n-butcher=freebsd-current=freebsd.org=sbibybnr@fusiongol.com) Received: from pat.gol.co.jp ([203.216.1.191] helo=[127.0.0.1]) by smtp02.dentaku.gol.com with esmtpa (Dentaku) id 1IDDAY-0005ox-Dx for ; Tue, 24 Jul 2007 14:42:50 +0900 Message-ID: <46A59157.1040204@fusiongol.com> Date: Tue, 24 Jul 2007 14:42:47 +0900 From: Nathan Butcher User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: freebsd-current@freebsd.org X-Enigmail-Version: 0.95.2 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV GOL X-Abuse-Complaints: abuse@gol.com Subject: Re: (ZFS) zpool replace weirdness X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 24 Jul 2007 05:42:51 -0000 >I've been playing around with zfs for a bit, and ran into a problem >where i corrupted an entire drive (on purpose) by way of dd >if=/dev/urandom of=/dev/ad12 .. as expected, the zpool noticed: I managed to do something similar, just not exactly the way you described. For starters, I was unable to dd if=/dev/urandom of=/dev/ad3 because dd prevented writing to the device in the zpool. What I did was to "zpool export" my pool, THEN dd over the top of one of my devices. THEN "zpool import" my pool again. The result was a fantastic error:- pool: z state: ONLINE status: One or more devices could not be used because the label is missing or invalid. Sufficient replicas exist for the pool to continue functioning in a degraded state. action: Replace the device using 'zpool replace'. see: http://www.sun.com/msg/ZFS-8000-4J scrub: resilver completed with 0 errors on Mon Jun 11 22:09:22 2007 config: NAME STATE READ WRITE CKSUM z ONLINE 0 0 0 raidz1 ONLINE 0 0 0 ad1 ONLINE 0 0 0 4239271840293300479 UNAVAIL 0 0 0 was /dev/ad3 da0 ONLINE 0 0 0 da1 ONLINE 0 0 0 errors: No known data errors Now I'm not sure how to recover the zpool. I can't exactly remove this wonderful numerical device without a "ad3 is in use" error. NB: that I'm running this ZFS on a 32-bit virtual machine with FreeBSD i386 and 768MB memory. No idea if the problem replicates on amd64 with over 1GB memory. From owner-freebsd-current@FreeBSD.ORG Tue Jul 24 11:00: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 78BB616A418; Tue, 24 Jul 2007 11:00:51 +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 2C9E713C49D; Tue, 24 Jul 2007 11:00:51 +0000 (UTC) (envelope-from gary.jennejohn@freenet.de) Received: from [195.4.92.19] (helo=mx9.freenet.de) by mout2.freenet.de with esmtpa (Exim 4.68-dev) (envelope-from ) id 1IDFq4-0003l5-Mx; Tue, 24 Jul 2007 10:33:52 +0200 Received: from m9099.m.pppool.de ([89.49.144.153]:62738 helo=peedub.jennejohn.org) by mx9.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.68 #1) id 1IDFq4-0002ta-Ao; Tue, 24 Jul 2007 10:33:52 +0200 Date: Tue, 24 Jul 2007 10:33:50 +0200 From: Gary Jennejohn To: John Baldwin Message-Id: <20070724103350.7f9aac40.gary.jennejohn@freenet.de> In-Reply-To: <200707231804.14770.jhb@freebsd.org> References: <20070703114248.37a2019b.garyj@jennejohn.org> <200707231804.14770.jhb@freebsd.org> 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, 24 Jul 2007 11:23:05 +0000 Cc: freebsd-current@freebsd.org Subject: Re: panic when printing 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, 24 Jul 2007 11:00:51 -0000 On Mon, 23 Jul 2007 18:04:14 -0400 John Baldwin wrote: > On Tuesday 03 July 2007 05:42:48 am Gary Jennejohn wrote: > > I haven't seen this reported before. > > > > Trying to print to my parallel printer with a -current kernel from > > July 2 (amd64) results in a kernel panic. A kernel from June 16 > > (i386) does not cause a panic. > > > > If I boot with the printer turned on then the kernel sees it (PnP) > > with no problem. Just printing causes a panic. > > > > BTW this kernel is using the SMP-scheduler from Jeff Roberson, but > > IIRC a different kernel (June 29) w/o that scheduler also panics. > > > > I can't say whether it's amd64-specific or just due to recent > > changes to the sources. I'm rather reluctant to generate a new i386 > > kernel to check that, but I could be persuaded to do it. > > > > Below a typescript of a very limited kgdb session: > > You got an interrupt after the lpt driver removed its handler. > Really the ppbus device should not be so stupid and should have its > own interrupt handler that routes interrupts to the "active" child. > [snip kgdb output] Exactly. If I disable the interrupt in device.hints I can print wth no problems. I suspect that this problem exists for i386 also. --- Gary Jennejohn From owner-freebsd-current@FreeBSD.ORG Tue Jul 24 12:40:08 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 B799616A418 for ; Tue, 24 Jul 2007 12:40:08 +0000 (UTC) (envelope-from ss.alert@online.no) Received: from mail43.e.nsc.no (mail43.e.nsc.no [193.213.115.43]) by mx1.freebsd.org (Postfix) with ESMTP id 4EB0A13C45A for ; Tue, 24 Jul 2007 12:40:08 +0000 (UTC) (envelope-from ss.alert@online.no) Received: from PARALLELS (ti0034a340-0045.bb.online.no [88.90.0.45]) by mail43.nsc.no (8.13.8/8.13.5) with ESMTP id l6OCe60i017032 for ; Tue, 24 Jul 2007 14:40:06 +0200 (MEST) Date: Tue, 24 Jul 2007 14:40:05 +0200 From: Sverre Svenningsen X-Mailer: The Bat! (v3.99.3) Professional Organization: - X-Priority: 3 (Normal) Message-ID: <1273412671.20070724144005@online.no> To: freebsd-current@freebsd.org In-Reply-To: <468A9842.0@barryp.org> References: <4679CE35.8080907@fusiongol.com> <86wsxibxc2.fsf@dwp.des.no> <4689A7DC.1070604@fusiongol.com> <468A9842.0@barryp.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Subject: Re: Promise SATA300 TX4 card issues X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Sverre Svenningsen List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2007 12:40:08 -0000 Hello Barry, Tuesday, July 3, 2007, 8:41:06 PM, you wrote: > Nathan Butcher wrote: >> Dag-Erling Smørgrav wrote: >>> Nathan Butcher writes: >>>> I've been having problems with my ZFS pool consisting of 4 drives hooked >>>> up to my Prmoise SATA 300TX4 controller. It had been working fine until >>>> to around the 19th of this month, and then I started seeing error >>>> messages whenever I tried to write lots of data to ZFS..... followed by >>>> a nasty lockup with no other debugging information of which to speak of. > I've noticed problems with this card too, running amd64 on a AthlonX2. > I've got a ZFS pool setup, and when scrubbing the pool it comes up with > erratic CKSUM errors (for example, scrub once and get 7 errors, scrub > again immediately and get 53 more). > Previously I had these drives (Seagate Barracuda ES ST3320620NS) plugged > into the motherboard SATA ports of the same machine, (nVidia nForce > MCP51 SATA300 controller) with no issues at all. > Barry > _______________________________________________ > 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" Hi, i want to report this same problem. Platform is a c2d with 1gb ram running i386. I updated my sources and installed a new kernel and world yesterday, July 23rd.(old world and kernel was built on 2nd of June) and now i'm seeing this problem too. Only difference is that i have two of these promise sata300 tx4 cards in my machine. Even trying to create a zfs raidz on disks attached to the controllers will hardlock the computer with no visible kernel panic, so it's hard to tell just what happens. The system disk is on another controller, and testing various zfs things on the onboard controller (intel ich) works fine. What broke the promise ata driver? -- Best regards, Sverre mailto:ss.alert@online.no From owner-freebsd-current@FreeBSD.ORG Tue Jul 24 12:54:28 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 9A53116A418; Tue, 24 Jul 2007 12:54:28 +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 6CF0713C45B; Tue, 24 Jul 2007 12:54:28 +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 E2A182DA94; Tue, 24 Jul 2007 08:54:49 -0400 (EDT) Received: by admin.crosswinds.net (Postfix, from userid 1001) id D2310403D; Tue, 24 Jul 2007 08:54:49 -0400 (EDT) Date: Tue, 24 Jul 2007 08:54:49 -0400 From: Tony Holmes To: Anton Berezin , freebsd-ports@freebsd.org, freebsd-current@freebsd.org Message-ID: <20070724125449.GA93609@crosswinds.net> References: <20070724021826.GA47532@crosswinds.net> <20070724095615.GA68140@heechee.tobez.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070724095615.GA68140@heechee.tobez.org> User-Agent: Mutt/1.4.2.1i Cc: Subject: Re: Perl Dependancies in 7-CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2007 12:54:28 -0000 A bit more background on my ports building adventure. I have one system I am using as a master ports system. It exports the ports tree via nfs. The system I am attempting to build on has the ports tree rw nfs mounted, and rw null mounted into a jail I am attempting to build up (using ezjail to create the jails and the nullfs ports "trick" to mount the base system /usr/ports - an nfs mount - into the jail). The 0 length perl Makefiles affected both the base (nfs mounted) and jailed (null mounted) systems. I went back to the exporting exporting and did a portsnap to bring the system ports tree up to date - still the issue persisted. So I built perl on the ports exporting system and suddenly the nfs mounting system could successfully build and installed. The jail with the nullfs mounted /usr/ports still gets 0 length makefiles. My temporary solution is to nfs mount the /usr/ports into the jail from the base system as well. I am cc'ing this to current for information and more eyes :) -- Tony Holmes Ph: (416) 993-1219 Founder and Senior Systems Architect Crosswinds Internet Communications Inc. From owner-freebsd-current@FreeBSD.ORG Tue Jul 24 14:03: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 DA5B016A41B for ; Tue, 24 Jul 2007 14:03: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 8E15913C457 for ; Tue, 24 Jul 2007 14:03: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 1IDKyz-000J8q-TB; Tue, 24 Jul 2007 18:03:26 +0400 Received: from bsam by ipt.ru with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1IDKzL-0006Gh-6f; Tue, 24 Jul 2007 18:03:47 +0400 To: Pawel Jakub Dawidek References: <97732929@srv.sem.ipt.ru> <20070723133333.GF5456@garage.freebsd.pl> From: Boris Samorodov Date: Tue, 24 Jul 2007 18:03:47 +0400 In-Reply-To: <20070723133333.GF5456@garage.freebsd.pl> (Pawel Jakub Dawidek's message of "Mon\, 23 Jul 2007 15\:33\:33 +0200") Message-ID: <78011660@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-current@FreeBSD.org Subject: Re: mount_nullfs inside a jail X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 24 Jul 2007 14:03:24 -0000 On Mon, 23 Jul 2007 15:33:33 +0200 Pawel Jakub Dawidek wrote: > On Sun, Jul 22, 2007 at 04:18:06AM +0400, Boris Samorodov wrote: > > Is it possible to use mount_nullfs inside a jail? > > > > With amd64-current: > > ----- > > # sysctl security.jail > > security.jail.jailed: 1 > > security.jail.mount_allowed: 1 > > security.jail.chflags_allowed: 1 > > security.jail.allow_raw_sockets: 0 > > security.jail.enforce_statfs: 2 > > security.jail.sysvipc_allowed: 1 > > security.jail.socket_unixiproute_only: 1 > > security.jail.set_hostname_allowed: 1 > > # mount_nullfs /usr/ports /mnt > > mount_nullfs: Operation not permitted > > ----- > It is not possible. From jail(8): > security.jail.mount_allowed > This MIB entry determines if a privileged user inside a jail will be > able to mount and unmount file system types marked as jail-friendly. > The lsvfs(1) command can be used to find file system types available > for mount from within a jail. This functionality is disabled by > default, but can be enabled by setting this MIB entry to 1. > # lsvfs > Filesystem Refs Flags > -------------------------------- ----- --------------- > zfs 0 jail > nullfs 0 loopback Thanks, Pavel. Somehow I failed to do RTFM. > As you can see, nullfs doesn't have 'jail' flag. The only jail-friendly > file system currently is ZFS. Nullfs is a good candidate for a > jail-friendly file system, but is not marked as such yet. Does somebody know if only a flag is missing or not? 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 Tue Jul 24 14:46:33 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 19DE916A419 for ; Tue, 24 Jul 2007 14:46:33 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.freebsd.org (Postfix) with ESMTP id AE56813C45A for ; Tue, 24 Jul 2007 14:46:29 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id B296F487F4; Tue, 24 Jul 2007 16:46:27 +0200 (CEST) Received: from localhost (154.81.datacomsa.pl [195.34.81.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 8E59345683; Tue, 24 Jul 2007 16:46:21 +0200 (CEST) Date: Tue, 24 Jul 2007 16:45:49 +0200 From: Pawel Jakub Dawidek To: Boris Samorodov Message-ID: <20070724144549.GA12473@garage.freebsd.pl> References: <97732929@srv.sem.ipt.ru> <20070723133333.GF5456@garage.freebsd.pl> <78011660@srv.sem.ipt.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="UugvWAfsgieZRqgk" Content-Disposition: inline In-Reply-To: <78011660@srv.sem.ipt.ru> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-2.6 required=3.0 tests=BAYES_00 autolearn=ham version=3.0.4 Cc: freebsd-current@FreeBSD.org Subject: Re: mount_nullfs inside a jail X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 24 Jul 2007 14:46:33 -0000 --UugvWAfsgieZRqgk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 24, 2007 at 06:03:47PM +0400, Boris Samorodov wrote: > On Mon, 23 Jul 2007 15:33:33 +0200 Pawel Jakub Dawidek wrote: > > As you can see, nullfs doesn't have 'jail' flag. The only jail-friendly > > file system currently is ZFS. Nullfs is a good candidate for a > > jail-friendly file system, but is not marked as such yet. >=20 > Does somebody know if only a flag is missing or not? You may try changing the line in /sys/fs/nullfs/null_vfsops.c from: VFS_SET(null_vfsops, nullfs, VFCF_LOOPBACK); to: VFS_SET(null_vfsops, nullfs, VFCF_LOOPBACK | VFCF_JAIL); but I don't think anyone did any security analysis of this yet. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --UugvWAfsgieZRqgk Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFGphCdForvXbEpPzQRAqw1AJ0Q6YoZ+ZKjfBvMTUSmncoCb2l9wACeL6sa VI3bbB7KqIrfICYfl3gfO2M= =+oDv -----END PGP SIGNATURE----- --UugvWAfsgieZRqgk-- From owner-freebsd-current@FreeBSD.ORG Tue Jul 24 15:37: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 0D59F16A41A for ; Tue, 24 Jul 2007 15:37:19 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.freebsd.org (Postfix) with ESMTP id 63C3113C46C for ; Tue, 24 Jul 2007 15:37:18 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id DECE3487FB; Tue, 24 Jul 2007 17:37:16 +0200 (CEST) Received: from localhost (154.81.datacomsa.pl [195.34.81.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 4521245685; Tue, 24 Jul 2007 17:37:11 +0200 (CEST) Date: Tue, 24 Jul 2007 17:36:39 +0200 From: Pawel Jakub Dawidek To: Sverre Svenningsen Message-ID: <20070724153639.GB12473@garage.freebsd.pl> References: <20070719102302.R1534@rust.salford.ac.uk> <20070719135510.GE1194@garage.freebsd.pl> <20070719181313.G4923@rust.salford.ac.uk> <20070721065204.GA2044@garage.freebsd.pl> <1736829882.20070723231753@online.no> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="pvezYHf7grwyp3Bc" Content-Disposition: inline In-Reply-To: <1736829882.20070723231753@online.no> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-2.6 required=3.0 tests=BAYES_00 autolearn=ham version=3.0.4 Cc: freebsd-current@freebsd.org Subject: Re: (ZFS) zpool replace weirdness X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 24 Jul 2007 15:37:19 -0000 --pvezYHf7grwyp3Bc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jul 23, 2007 at 11:17:53PM +0200, Sverre Svenningsen wrote: > I've been playing around with zfs for a bit, and ran into a problem > where i corrupted an entire drive (on purpose) by way of dd > if=3D/dev/urandom of=3D/dev/ad12 .. as expected, the zpool noticed: >=20 > su-2.05b# zpool status > pool: array1 > state: ONLINE > status: One or more devices could not be used because the label is missin= g or > invalid. Sufficient replicas exist for the pool to continue > functioning in a degraded state. > action: Replace the device using 'zpool replace'. > see: http://www.sun.com/msg/ZFS-8000-4J > scrub: resilver completed with 0 errors on Mon Jul 23 23:05:53 2007 > config: >=20 > NAME STATE READ WRITE CKSUM > array1 ONLINE 0 0 0 > raidz1 ONLINE 0 0 0 > ad10 ONLINE 0 0 0 > ad12 UNAVAIL 0 0 0 corrupted data > ad14 ONLINE 0 0 0 > ad16 ONLINE 0 0 0 > raidz1 ONLINE 0 0 0 > ad18 ONLINE 0 0 0 > ad20 ONLINE 0 0 0 > ad22 ONLINE 0 0 0 > ad24 ONLINE 0 0 0 >=20 > errors: No known data errors >=20 >=20 > now i want to resilver that disk, but the problem is this: >=20 > su-2.05b# zpool replace -f array1 ad12 > invalid vdev specification > the following errors must be manually repaired: > ad12 is in use (r1w1e1) >=20 > but nothing is using that disk as far as i can tell! has anyone > successfully done this? It just works here, but the version I'm using is not yet committed, maybe there was a fix in OpenSolaris. You could try removing /boot/zfs/zpool.cache. > would it be better to use slices instead of whole disks for zfs on > freebsd? i want to get some experience with this so that i know > what not to do when a disk breaks for real :) Whole disks are fine. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --pvezYHf7grwyp3Bc Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFGphyHForvXbEpPzQRAlN3AJ4+JrDTEK0eSSpgoJ9W9Y4B+wrMzQCgwqBA O7JWXu8dqM456kKLRVhaX1k= =uMH+ -----END PGP SIGNATURE----- --pvezYHf7grwyp3Bc-- From owner-freebsd-current@FreeBSD.ORG Tue Jul 24 16:17:07 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 4EFD816A418 for ; Tue, 24 Jul 2007 16:17:07 +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 063C213C4B5 for ; Tue, 24 Jul 2007 16:17:06 +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 E4A0FEB2753 for ; Wed, 25 Jul 2007 00:17:05 +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 jw7valTPERLt for ; Wed, 25 Jul 2007 00:17:03 +0800 (CST) Received: from charlie.delphij.net (unknown [61.49.186.182]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id 29E1AEB274C for ; Wed, 25 Jul 2007 00:17:03 +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:subject: content-type:content-transfer-encoding; b=c70J0W1/WwV8utfLRQqVTfbSRs3JifLplU3CZWuuRIpLuftyOevp/WQJ0QeTlwQdy 5AskSPvItx1lMh8kpuH/w== Message-ID: <46A625FB.5050105@delphij.net> Date: Wed, 25 Jul 2007 00:16:59 +0800 From: Xin LI User-Agent: Thunderbird 2.0.0.5 (X11/20070721) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Call for non i386/amd64 testers for tmpfs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 24 Jul 2007 16:17:07 -0000 Hi, I'd like to request that some owners of non-i386/amd64 boxes to test sys/modules/tmpfs and report if it would work correctly on other architectures, so I will be able to determine if it is appropriate to connect it to build on these architectures (and perhaps pick out more bugs :) Thanks for your cooperation! Cheers, From owner-freebsd-current@FreeBSD.ORG Tue Jul 24 16:42: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 1C48716A417 for ; Tue, 24 Jul 2007 16:42:18 +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 055A413C45D for ; Tue, 24 Jul 2007 16:42:17 +0000 (UTC) (envelope-from craig@xfoil.gank.org) Received: by ion.gank.org (Postfix, from userid 1001) id C77F611253; Tue, 24 Jul 2007 11:42:17 -0500 (CDT) Date: Tue, 24 Jul 2007 11:42:16 -0500 From: Craig Boston To: Xin LI Message-ID: <20070724164215.GA3329@nowhere> Mail-Followup-To: Craig Boston , Xin LI , freebsd-current@freebsd.org References: <46A625FB.5050105@delphij.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46A625FB.5050105@delphij.net> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: Call for non i386/amd64 testers for tmpfs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 24 Jul 2007 16:42:18 -0000 On Wed, Jul 25, 2007 at 12:16:59AM +0800, Xin LI wrote: > I'd like to request that some owners of non-i386/amd64 boxes to test > sys/modules/tmpfs and report if it would work correctly on other > architectures, so I will be able to determine if it is appropriate to > connect it to build on these architectures (and perhaps pick out more > bugs :) Hi, funny you should post just now. It's for i386 but I just submitted a PR about tmpfs :-) Details are in kern/114870, but basically there's an overflow problem on 32-bit systems with a large amount of swap. Here's the quick fix that I attached to the PR: === sys/fs/tmpfs/tmpfs_vfsops.c ================================================================== --- sys/fs/tmpfs/tmpfs_vfsops.c (revision 777) +++ sys/fs/tmpfs/tmpfs_vfsops.c (local) @@ -268,7 +268,7 @@ mtx_init(&tmp->allnode_lock, "tmpfs allnode lock", NULL, MTX_DEF); tmp->tm_nodes_max = nodes; tmp->tm_nodes_inuse = 0; - tmp->tm_maxfilesize = get_swpgtotal() * PAGE_SIZE; + tmp->tm_maxfilesize = (u_int64_t)get_swpgtotal() * PAGE_SIZE; LIST_INIT(&tmp->tm_nodes_used); tmp->tm_pages_max = pages; From owner-freebsd-current@FreeBSD.ORG Tue Jul 24 16:50:49 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 E521916A417 for ; Tue, 24 Jul 2007 16:50:49 +0000 (UTC) (envelope-from hugo@barafranca.com) Received: from mail.barafranca.com (mail.barafranca.com [67.19.101.164]) by mx1.freebsd.org (Postfix) with ESMTP id 8DA2513C442 for ; Tue, 24 Jul 2007 16:50:49 +0000 (UTC) (envelope-from hugo@barafranca.com) Received: from localhost (localhost [127.0.0.1]) by mail.barafranca.com (Postfix) with ESMTP id 5348CC3940 for ; Tue, 24 Jul 2007 17:29:35 +0000 (UTC) Received: from mail.barafranca.com ([67.19.101.164]) by localhost (mail.barafranca.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 57157-08 for ; Tue, 24 Jul 2007 17:28:56 +0000 (UTC) Received: from nexus.bsdlan.org (a213-22-26-22.cpe.netcabo.pt [213.22.26.22]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.barafranca.com (Postfix) with ESMTP id 6ED20C3DD0 for ; Tue, 24 Jul 2007 17:28:54 +0000 (UTC) Message-ID: <46A62DC9.7080409@barafranca.com> Date: Tue, 24 Jul 2007 17:50:17 +0100 From: Hugo Silva User-Agent: Thunderbird 2.0.0.0 (X11/20070609) 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: amavisd-new at barafranca.com X-Spam-Status: No, score=0 tagged_above=-1 required=4 tests=[none] X-Spam-Score: 0 X-Spam-Level: Cc: Subject: Spurious RST, segment rejected - possible pattern? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 24 Jul 2007 16:50:50 -0000 Hi all, While conducting some benchmarks against various webserver software, (7-CURRENT client vs 7-CURRENT server), I couldn't help notice that the flood of Spurious RST (which only happens on the server side) seems to follow a specific pattern. #a HTTP Server: 192.168.0.100 (FreeBSD 7.0-CURRENT #3: Tue Jul 24 15:31:44 WEST 2007) #b HTTP Benchmarker: 192.168.0.1 (FreeBSD 7.0-CURRENT #3: Sun Jun 10 12:43:23 WEST 2007) * by "FAILS", I mean the expected result is too low, compared to a session where no "Spurious RST's" happened. OK means no such messages were seen. Here's how it goes: * webserver restarted @ #a * benchmark runs and FAILS @ #b Jul 24 17:31:46 bluebunny kernel: TCP: [192.168.0.1]:60033 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:31:46 bluebunny kernel: TCP: [192.168.0.1]:60034 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:31:47 bluebunny kernel: TCP: [192.168.0.1]:60567 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:31:47 bluebunny kernel: TCP: [192.168.0.1]:60568 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:31:47 bluebunny kernel: TCP: [192.168.0.1]:60569 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:31:49 bluebunny kernel: TCP: [192.168.0.1]:60033 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:31:49 bluebunny kernel: TCP: [192.168.0.1]:60034 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:31:49 bluebunny kernel: TCP: [192.168.0.1]:60033 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:31:49 bluebunny kernel: TCP: [192.168.0.1]:60034 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:31:50 bluebunny kernel: TCP: [192.168.0.1]:60033 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:31:50 bluebunny kernel: TCP: [192.168.0.1]:60034 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:31:50 bluebunny kernel: TCP: [192.168.0.1]:60567 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:31:50 bluebunny kernel: TCP: [192.168.0.1]:60568 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:31:50 bluebunny kernel: TCP: [192.168.0.1]:60569 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:31:50 bluebunny kernel: TCP: [192.168.0.1]:60033 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:31:50 bluebunny kernel: TCP: [192.168.0.1]:60034 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:31:50 bluebunny kernel: TCP: [192.168.0.1]:60567 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:31:50 bluebunny kernel: TCP: [192.168.0.1]:60568 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:31:50 bluebunny kernel: TCP: [192.168.0.1]:60569 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:31:50 bluebunny kernel: TCP: [192.168.0.1]:60033 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:31:50 bluebunny kernel: TCP: [192.168.0.1]:60034 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:31:50 bluebunny kernel: TCP: [192.168.0.1]:60567 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:31:50 bluebunny kernel: TCP: [192.168.0.1]:60568 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:31:50 bluebunny kernel: TCP: [192.168.0.1]:60569 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:31:50 bluebunny kernel: TCP: [192.168.0.1]:60033 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:31:50 bluebunny kernel: TCP: [192.168.0.1]:60034 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:31:50 bluebunny kernel: TCP: [192.168.0.1]:60567 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:31:50 bluebunny kernel: TCP: [192.168.0.1]:60568 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:31:50 bluebunny kernel: TCP: [192.168.0.1]:60569 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:31:50 bluebunny kernel: TCP: [192.168.0.1]:60033 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:31:50 bluebunny kernel: TCP: [192.168.0.1]:60034 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:31:51 bluebunny kernel: TCP: [192.168.0.1]:60567 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:31:51 bluebunny kernel: TCP: [192.168.0.1]:60568 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:31:51 bluebunny kernel: TCP: [192.168.0.1]:60569 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:31:51 bluebunny kernel: TCP: [192.168.0.1]:60567 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:31:51 bluebunny kernel: TCP: [192.168.0.1]:60568 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:31:51 bluebunny kernel: TCP: [192.168.0.1]:60569 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:31:51 bluebunny kernel: TCP: [192.168.0.1]:60033 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:31:51 bluebunny kernel: TCP: [192.168.0.1]:60034 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:31:51 bluebunny kernel: TCP: [192.168.0.1]:60567 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:31:51 bluebunny kernel: TCP: [192.168.0.1]:60568 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:31:51 bluebunny kernel: TCP: [192.168.0.1]:60569 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:31:51 bluebunny kernel: TCP: [192.168.0.1]:60033 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:31:51 bluebunny kernel: TCP: [192.168.0.1]:60034 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:31:51 bluebunny kernel: TCP: [192.168.0.1]:60567 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:31:51 bluebunny kernel: TCP: [192.168.0.1]:60568 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:31:51 bluebunny kernel: TCP: [192.168.0.1]:60569 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:31:52 bluebunny kernel: TCP: [192.168.0.1]:60033 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:31:52 bluebunny kernel: TCP: [192.168.0.1]:60034 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:31:52 bluebunny kernel: TCP: [192.168.0.1]:60567 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:31:52 bluebunny kernel: TCP: [192.168.0.1]:60568 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:31:52 bluebunny kernel: TCP: [192.168.0.1]:60569 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:31:52 bluebunny kernel: TCP: [192.168.0.1]:60567 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:31:52 bluebunny kernel: TCP: [192.168.0.1]:60568 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:31:52 bluebunny kernel: TCP: [192.168.0.1]:60569 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:31:52 bluebunny kernel: TCP: [192.168.0.1]:60033 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:31:52 bluebunny kernel: TCP: [192.168.0.1]:60034 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:31:53 bluebunny kernel: TCP: [192.168.0.1]:60567 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:31:53 bluebunny kernel: TCP: [192.168.0.1]:60568 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:31:53 bluebunny kernel: TCP: [192.168.0.1]:60569 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:31:53 bluebunny kernel: TCP: [192.168.0.1]:60033 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:31:53 bluebunny kernel: TCP: [192.168.0.1]:60034 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:31:54 bluebunny kernel: TCP: [192.168.0.1]:60567 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:31:54 bluebunny kernel: TCP: [192.168.0.1]:60568 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:31:54 bluebunny kernel: TCP: [192.168.0.1]:60569 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected * webserver restarted @ #a * benchmark runs OK @ #b * webserver restarted @ #a * benchmark runs OK @ #b * webserver restarted @ #a * benchmark runs and FAILS @ #b Jul 24 17:36:52 bluebunny kernel: TCP: [192.168.0.1]:60033 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:36:52 bluebunny kernel: TCP: [192.168.0.1]:60034 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:36:53 bluebunny kernel: TCP: [192.168.0.1]:60567 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:36:53 bluebunny kernel: TCP: [192.168.0.1]:60568 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:36:53 bluebunny kernel: TCP: [192.168.0.1]:60569 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:36:55 bluebunny kernel: TCP: [192.168.0.1]:60033 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:36:55 bluebunny kernel: TCP: [192.168.0.1]:60034 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:36:56 bluebunny kernel: TCP: [192.168.0.1]:60033 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:36:56 bluebunny kernel: TCP: [192.168.0.1]:60034 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:36:56 bluebunny kernel: TCP: [192.168.0.1]:60033 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:36:56 bluebunny kernel: TCP: [192.168.0.1]:60034 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:36:56 bluebunny kernel: TCP: [192.168.0.1]:60567 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:36:56 bluebunny kernel: TCP: [192.168.0.1]:60568 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:36:56 bluebunny kernel: TCP: [192.168.0.1]:60569 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:36:56 bluebunny kernel: TCP: [192.168.0.1]:60033 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:36:56 bluebunny kernel: TCP: [192.168.0.1]:60034 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:36:56 bluebunny kernel: TCP: [192.168.0.1]:60567 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:36:56 bluebunny kernel: TCP: [192.168.0.1]:60568 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:36:56 bluebunny kernel: TCP: [192.168.0.1]:60569 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:36:56 bluebunny kernel: TCP: [192.168.0.1]:60033 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:36:56 bluebunny kernel: TCP: [192.168.0.1]:60034 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:36:56 bluebunny kernel: TCP: [192.168.0.1]:60567 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:36:56 bluebunny kernel: TCP: [192.168.0.1]:60568 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:36:56 bluebunny kernel: TCP: [192.168.0.1]:60569 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:36:56 bluebunny kernel: TCP: [192.168.0.1]:60033 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:36:56 bluebunny kernel: TCP: [192.168.0.1]:60034 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:36:57 bluebunny kernel: TCP: [192.168.0.1]:60567 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:36:57 bluebunny kernel: TCP: [192.168.0.1]:60568 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:36:57 bluebunny kernel: TCP: [192.168.0.1]:60569 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:36:57 bluebunny kernel: TCP: [192.168.0.1]:60033 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:36:57 bluebunny kernel: TCP: [192.168.0.1]:60034 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:36:57 bluebunny kernel: TCP: [192.168.0.1]:60567 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:36:57 bluebunny kernel: TCP: [192.168.0.1]:60568 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:36:57 bluebunny kernel: TCP: [192.168.0.1]:60569 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:36:57 bluebunny kernel: TCP: [192.168.0.1]:60033 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:36:57 bluebunny kernel: TCP: [192.168.0.1]:60034 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:36:57 bluebunny kernel: TCP: [192.168.0.1]:60567 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:36:57 bluebunny kernel: TCP: [192.168.0.1]:60568 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:36:57 bluebunny kernel: TCP: [192.168.0.1]:60569 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:36:57 bluebunny kernel: TCP: [192.168.0.1]:60567 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:36:57 bluebunny kernel: TCP: [192.168.0.1]:60568 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:36:57 bluebunny kernel: TCP: [192.168.0.1]:60569 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:36:57 bluebunny kernel: TCP: [192.168.0.1]:60033 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:36:57 bluebunny kernel: TCP: [192.168.0.1]:60034 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:36:58 bluebunny kernel: TCP: [192.168.0.1]:60567 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:36:58 bluebunny kernel: TCP: [192.168.0.1]:60568 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:36:58 bluebunny kernel: TCP: [192.168.0.1]:60569 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:36:58 bluebunny kernel: TCP: [192.168.0.1]:60033 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:36:58 bluebunny kernel: TCP: [192.168.0.1]:60034 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:36:58 bluebunny kernel: TCP: [192.168.0.1]:60567 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:36:58 bluebunny kernel: TCP: [192.168.0.1]:60568 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:36:58 bluebunny kernel: TCP: [192.168.0.1]:60569 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:36:58 bluebunny kernel: TCP: [192.168.0.1]:60567 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:36:58 bluebunny kernel: TCP: [192.168.0.1]:60568 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:36:58 bluebunny kernel: TCP: [192.168.0.1]:60569 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:36:59 bluebunny kernel: TCP: [192.168.0.1]:60033 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:36:59 bluebunny kernel: TCP: [192.168.0.1]:60034 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:36:59 bluebunny kernel: TCP: [192.168.0.1]:60567 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:36:59 bluebunny kernel: TCP: [192.168.0.1]:60568 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:36:59 bluebunny kernel: TCP: [192.168.0.1]:60569 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:36:59 bluebunny kernel: TCP: [192.168.0.1]:60033 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:36:59 bluebunny kernel: TCP: [192.168.0.1]:60034 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:37:00 bluebunny kernel: TCP: [192.168.0.1]:60567 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:37:00 bluebunny kernel: TCP: [192.168.0.1]:60568 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:37:00 bluebunny kernel: TCP: [192.168.0.1]:60569 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected * webserver restarted @ #a * benchmark runs and FAILS @ #b Jul 24 17:37:51 bluebunny kernel: TCP: [192.168.0.1]:60033 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:37:51 bluebunny kernel: TCP: [192.168.0.1]:60034 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:37:52 bluebunny kernel: TCP: [192.168.0.1]:60568 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:37:52 bluebunny kernel: TCP: [192.168.0.1]:60569 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:37:52 bluebunny kernel: TCP: [192.168.0.1]:60567 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:37:54 bluebunny kernel: TCP: [192.168.0.1]:60033 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:37:54 bluebunny kernel: TCP: [192.168.0.1]:60034 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:37:54 bluebunny kernel: TCP: [192.168.0.1]:60033 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:37:54 bluebunny kernel: TCP: [192.168.0.1]:60034 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:37:55 bluebunny kernel: TCP: [192.168.0.1]:60033 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:37:55 bluebunny kernel: TCP: [192.168.0.1]:60034 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:37:55 bluebunny kernel: TCP: [192.168.0.1]:60033 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:37:55 bluebunny kernel: TCP: [192.168.0.1]:60034 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:37:55 bluebunny kernel: TCP: [192.168.0.1]:60567 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:37:55 bluebunny kernel: TCP: [192.168.0.1]:60568 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:37:55 bluebunny kernel: TCP: [192.168.0.1]:60569 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:37:55 bluebunny kernel: TCP: [192.168.0.1]:60033 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:37:55 bluebunny kernel: TCP: [192.168.0.1]:60034 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:37:55 bluebunny kernel: TCP: [192.168.0.1]:60567 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:37:55 bluebunny kernel: TCP: [192.168.0.1]:60568 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:37:55 bluebunny kernel: TCP: [192.168.0.1]:60569 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:37:55 bluebunny kernel: TCP: [192.168.0.1]:60033 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:37:55 bluebunny kernel: TCP: [192.168.0.1]:60034 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:37:55 bluebunny kernel: TCP: [192.168.0.1]:60567 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:37:55 bluebunny kernel: TCP: [192.168.0.1]:60568 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:37:55 bluebunny kernel: TCP: [192.168.0.1]:60569 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:37:56 bluebunny kernel: TCP: [192.168.0.1]:60033 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:37:56 bluebunny kernel: TCP: [192.168.0.1]:60034 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:37:56 bluebunny kernel: TCP: [192.168.0.1]:60567 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:37:56 bluebunny kernel: TCP: [192.168.0.1]:60568 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:37:56 bluebunny kernel: TCP: [192.168.0.1]:60569 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:37:56 bluebunny kernel: TCP: [192.168.0.1]:60033 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:37:56 bluebunny kernel: TCP: [192.168.0.1]:60034 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:37:56 bluebunny kernel: TCP: [192.168.0.1]:60567 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:37:56 bluebunny kernel: TCP: [192.168.0.1]:60568 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:37:56 bluebunny kernel: TCP: [192.168.0.1]:60569 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:37:56 bluebunny kernel: TCP: [192.168.0.1]:60567 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:37:56 bluebunny kernel: TCP: [192.168.0.1]:60568 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:37:56 bluebunny kernel: TCP: [192.168.0.1]:60569 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:37:56 bluebunny kernel: TCP: [192.168.0.1]:60033 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:37:56 bluebunny kernel: TCP: [192.168.0.1]:60034 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:37:56 bluebunny kernel: TCP: [192.168.0.1]:60567 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:37:56 bluebunny kernel: TCP: [192.168.0.1]:60568 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:37:56 bluebunny kernel: TCP: [192.168.0.1]:60569 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:37:57 bluebunny kernel: TCP: [192.168.0.1]:60567 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:37:57 bluebunny kernel: TCP: [192.168.0.1]:60568 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:37:57 bluebunny kernel: TCP: [192.168.0.1]:60569 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:37:57 bluebunny kernel: TCP: [192.168.0.1]:60033 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:37:57 bluebunny kernel: TCP: [192.168.0.1]:60034 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:37:57 bluebunny kernel: TCP: [192.168.0.1]:60567 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:37:57 bluebunny kernel: TCP: [192.168.0.1]:60568 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:37:57 bluebunny kernel: TCP: [192.168.0.1]:60569 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:37:57 bluebunny kernel: TCP: [192.168.0.1]:60567 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:37:57 bluebunny kernel: TCP: [192.168.0.1]:60568 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:37:57 bluebunny kernel: TCP: [192.168.0.1]:60569 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:37:57 bluebunny kernel: TCP: [192.168.0.1]:60033 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:37:57 bluebunny kernel: TCP: [192.168.0.1]:60034 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:37:58 bluebunny kernel: TCP: [192.168.0.1]:60567 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:37:58 bluebunny kernel: TCP: [192.168.0.1]:60568 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:37:58 bluebunny kernel: TCP: [192.168.0.1]:60569 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:37:58 bluebunny kernel: TCP: [192.168.0.1]:60033 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:37:58 bluebunny kernel: TCP: [192.168.0.1]:60034 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:37:59 bluebunny kernel: TCP: [192.168.0.1]:60567 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:37:59 bluebunny kernel: TCP: [192.168.0.1]:60568 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:37:59 bluebunny kernel: TCP: [192.168.0.1]:60569 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected * webserver restarted @ #a * benchmark runs OK @ #b * webserver restarted @ #a * benchmark runs and FAILS @ #b Jul 24 17:39:13 bluebunny kernel: TCP: [192.168.0.1]:60033 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:39:13 bluebunny kernel: TCP: [192.168.0.1]:60034 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:39:14 bluebunny kernel: TCP: [192.168.0.1]:60567 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:39:14 bluebunny kernel: TCP: [192.168.0.1]:60568 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:39:14 bluebunny kernel: TCP: [192.168.0.1]:60569 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:39:16 bluebunny kernel: TCP: [192.168.0.1]:60033 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:39:16 bluebunny kernel: TCP: [192.168.0.1]:60034 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:39:17 bluebunny kernel: TCP: [192.168.0.1]:60033 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:39:17 bluebunny kernel: TCP: [192.168.0.1]:60034 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:39:17 bluebunny kernel: TCP: [192.168.0.1]:60033 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:39:17 bluebunny kernel: TCP: [192.168.0.1]:60034 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:39:17 bluebunny kernel: TCP: [192.168.0.1]:60567 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:39:17 bluebunny kernel: TCP: [192.168.0.1]:60568 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:39:17 bluebunny kernel: TCP: [192.168.0.1]:60569 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:39:17 bluebunny kernel: TCP: [192.168.0.1]:60033 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:39:17 bluebunny kernel: TCP: [192.168.0.1]:60034 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:39:17 bluebunny kernel: TCP: [192.168.0.1]:60567 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:39:17 bluebunny kernel: TCP: [192.168.0.1]:60568 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:39:17 bluebunny kernel: TCP: [192.168.0.1]:60569 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:39:17 bluebunny kernel: TCP: [192.168.0.1]:60033 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:39:17 bluebunny kernel: TCP: [192.168.0.1]:60034 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:39:17 bluebunny kernel: TCP: [192.168.0.1]:60567 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:39:17 bluebunny kernel: TCP: [192.168.0.1]:60568 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:39:17 bluebunny kernel: TCP: [192.168.0.1]:60569 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:39:17 bluebunny kernel: TCP: [192.168.0.1]:60033 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:39:17 bluebunny kernel: TCP: [192.168.0.1]:60034 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:39:18 bluebunny kernel: TCP: [192.168.0.1]:60567 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:39:18 bluebunny kernel: TCP: [192.168.0.1]:60568 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:39:18 bluebunny kernel: TCP: [192.168.0.1]:60569 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:39:18 bluebunny kernel: TCP: [192.168.0.1]:60033 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:39:18 bluebunny kernel: TCP: [192.168.0.1]:60034 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:39:18 bluebunny kernel: TCP: [192.168.0.1]:60567 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:39:18 bluebunny kernel: TCP: [192.168.0.1]:60568 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:39:18 bluebunny kernel: TCP: [192.168.0.1]:60569 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:39:18 bluebunny kernel: TCP: [192.168.0.1]:60033 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:39:18 bluebunny kernel: TCP: [192.168.0.1]:60034 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:39:18 bluebunny kernel: TCP: [192.168.0.1]:60567 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:39:18 bluebunny kernel: TCP: [192.168.0.1]:60568 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:39:18 bluebunny kernel: TCP: [192.168.0.1]:60569 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:39:18 bluebunny kernel: TCP: [192.168.0.1]:60567 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:39:18 bluebunny kernel: TCP: [192.168.0.1]:60568 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:39:18 bluebunny kernel: TCP: [192.168.0.1]:60569 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:39:18 bluebunny kernel: TCP: [192.168.0.1]:60033 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:39:18 bluebunny kernel: TCP: [192.168.0.1]:60034 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:39:19 bluebunny kernel: TCP: [192.168.0.1]:60567 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:39:19 bluebunny kernel: TCP: [192.168.0.1]:60568 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:39:19 bluebunny kernel: TCP: [192.168.0.1]:60569 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:39:19 bluebunny kernel: TCP: [192.168.0.1]:60033 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:39:19 bluebunny kernel: TCP: [192.168.0.1]:60034 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:39:19 bluebunny kernel: TCP: [192.168.0.1]:60567 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:39:19 bluebunny kernel: TCP: [192.168.0.1]:60568 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:39:19 bluebunny kernel: TCP: [192.168.0.1]:60569 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:39:19 bluebunny kernel: TCP: [192.168.0.1]:60567 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:39:19 bluebunny kernel: TCP: [192.168.0.1]:60568 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:39:19 bluebunny kernel: TCP: [192.168.0.1]:60569 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:39:20 bluebunny kernel: TCP: [192.168.0.1]:60033 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:39:20 bluebunny kernel: TCP: [192.168.0.1]:60034 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:39:20 bluebunny kernel: TCP: [192.168.0.1]:60567 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:39:20 bluebunny kernel: TCP: [192.168.0.1]:60568 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:39:20 bluebunny kernel: TCP: [192.168.0.1]:60569 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:39:20 bluebunny kernel: TCP: [192.168.0.1]:60033 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:39:20 bluebunny kernel: TCP: [192.168.0.1]:60034 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:39:21 bluebunny kernel: TCP: [192.168.0.1]:60567 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:39:21 bluebunny kernel: TCP: [192.168.0.1]:60568 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:39:21 bluebunny kernel: TCP: [192.168.0.1]:60569 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected * webserver restarted @ #a * benchmark runs OK @ #b * webserver restarted @ #a * benchmark runs ans FAILS @ #b Jul 24 17:40:43 bluebunny kernel: TCP: [192.168.0.1]:60033 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:40:43 bluebunny kernel: TCP: [192.168.0.1]:60034 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:40:43 bluebunny kernel: TCP: [192.168.0.1]:60567 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:40:43 bluebunny kernel: TCP: [192.168.0.1]:60568 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:40:43 bluebunny kernel: TCP: [192.168.0.1]:60569 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:40:46 bluebunny kernel: TCP: [192.168.0.1]:60033 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:40:46 bluebunny kernel: TCP: [192.168.0.1]:60034 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:40:46 bluebunny kernel: TCP: [192.168.0.1]:60033 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:40:46 bluebunny kernel: TCP: [192.168.0.1]:60034 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:40:46 bluebunny kernel: TCP: [192.168.0.1]:60033 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:40:46 bluebunny kernel: TCP: [192.168.0.1]:60034 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:40:46 bluebunny kernel: TCP: [192.168.0.1]:60567 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:40:46 bluebunny kernel: TCP: [192.168.0.1]:60568 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:40:46 bluebunny kernel: TCP: [192.168.0.1]:60569 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:40:46 bluebunny kernel: TCP: [192.168.0.1]:60033 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:40:46 bluebunny kernel: TCP: [192.168.0.1]:60034 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:40:47 bluebunny kernel: TCP: [192.168.0.1]:60567 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:40:47 bluebunny kernel: TCP: [192.168.0.1]:60568 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:40:47 bluebunny kernel: TCP: [192.168.0.1]:60569 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:40:47 bluebunny kernel: TCP: [192.168.0.1]:60033 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:40:47 bluebunny kernel: TCP: [192.168.0.1]:60034 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:40:47 bluebunny kernel: TCP: [192.168.0.1]:60567 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:40:47 bluebunny kernel: TCP: [192.168.0.1]:60568 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:40:47 bluebunny kernel: TCP: [192.168.0.1]:60569 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:40:47 bluebunny kernel: TCP: [192.168.0.1]:60033 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:40:47 bluebunny kernel: TCP: [192.168.0.1]:60034 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:40:47 bluebunny kernel: TCP: [192.168.0.1]:60567 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:40:47 bluebunny kernel: TCP: [192.168.0.1]:60568 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:40:47 bluebunny kernel: TCP: [192.168.0.1]:60569 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:40:47 bluebunny kernel: TCP: [192.168.0.1]:60033 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:40:47 bluebunny kernel: TCP: [192.168.0.1]:60034 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:40:47 bluebunny kernel: TCP: [192.168.0.1]:60567 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:40:47 bluebunny kernel: TCP: [192.168.0.1]:60568 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:40:47 bluebunny kernel: TCP: [192.168.0.1]:60569 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:40:47 bluebunny kernel: TCP: [192.168.0.1]:60567 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:40:47 bluebunny kernel: TCP: [192.168.0.1]:60568 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:40:47 bluebunny kernel: TCP: [192.168.0.1]:60569 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:40:47 bluebunny kernel: TCP: [192.168.0.1]:60033 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:40:47 bluebunny kernel: TCP: [192.168.0.1]:60034 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:40:48 bluebunny kernel: TCP: [192.168.0.1]:60567 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:40:48 bluebunny kernel: TCP: [192.168.0.1]:60568 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:40:48 bluebunny kernel: TCP: [192.168.0.1]:60569 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:40:48 bluebunny kernel: TCP: [192.168.0.1]:60033 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:40:48 bluebunny kernel: TCP: [192.168.0.1]:60034 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:40:48 bluebunny kernel: TCP: [192.168.0.1]:60567 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:40:48 bluebunny kernel: TCP: [192.168.0.1]:60568 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:40:48 bluebunny kernel: TCP: [192.168.0.1]:60569 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:40:48 bluebunny kernel: TCP: [192.168.0.1]:60033 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:40:48 bluebunny kernel: TCP: [192.168.0.1]:60034 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:40:48 bluebunny kernel: TCP: [192.168.0.1]:60567 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:40:48 bluebunny kernel: TCP: [192.168.0.1]:60568 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:40:48 bluebunny kernel: TCP: [192.168.0.1]:60569 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:40:49 bluebunny kernel: TCP: [192.168.0.1]:60567 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:40:49 bluebunny kernel: TCP: [192.168.0.1]:60568 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:40:49 bluebunny kernel: TCP: [192.168.0.1]:60569 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:40:49 bluebunny kernel: TCP: [192.168.0.1]:60033 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:40:49 bluebunny kernel: TCP: [192.168.0.1]:60034 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:40:50 bluebunny kernel: TCP: [192.168.0.1]:60567 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:40:50 bluebunny kernel: TCP: [192.168.0.1]:60568 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:40:50 bluebunny kernel: TCP: [192.168.0.1]:60569 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:40:50 bluebunny kernel: TCP: [192.168.0.1]:60033 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:40:50 bluebunny kernel: TCP: [192.168.0.1]:60034 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:40:50 bluebunny kernel: TCP: [192.168.0.1]:60567 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:40:50 bluebunny kernel: TCP: [192.168.0.1]:60568 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:40:50 bluebunny kernel: TCP: [192.168.0.1]:60569 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected * webserver restarted @ #a * benchmark runs and FAILS @ #b Jul 24 17:41:29 bluebunny kernel: TCP: [192.168.0.1]:60033 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:41:29 bluebunny kernel: TCP: [192.168.0.1]:60034 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:41:30 bluebunny kernel: TCP: [192.168.0.1]:60567 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:41:30 bluebunny kernel: TCP: [192.168.0.1]:60568 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:41:30 bluebunny kernel: TCP: [192.168.0.1]:60569 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:41:32 bluebunny kernel: TCP: [192.168.0.1]:60033 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:41:32 bluebunny kernel: TCP: [192.168.0.1]:60034 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:41:32 bluebunny kernel: TCP: [192.168.0.1]:60033 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:41:32 bluebunny kernel: TCP: [192.168.0.1]:60034 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:41:33 bluebunny kernel: TCP: [192.168.0.1]:60033 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:41:33 bluebunny kernel: TCP: [192.168.0.1]:60034 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:41:33 bluebunny kernel: TCP: [192.168.0.1]:60567 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:41:33 bluebunny kernel: TCP: [192.168.0.1]:60568 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:41:33 bluebunny kernel: TCP: [192.168.0.1]:60569 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:41:33 bluebunny kernel: TCP: [192.168.0.1]:60033 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:41:33 bluebunny kernel: TCP: [192.168.0.1]:60034 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:41:33 bluebunny kernel: TCP: [192.168.0.1]:60567 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:41:33 bluebunny kernel: TCP: [192.168.0.1]:60568 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:41:33 bluebunny kernel: TCP: [192.168.0.1]:60569 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:41:33 bluebunny kernel: TCP: [192.168.0.1]:60033 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:41:33 bluebunny kernel: TCP: [192.168.0.1]:60034 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:41:33 bluebunny kernel: TCP: [192.168.0.1]:60567 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:41:33 bluebunny kernel: TCP: [192.168.0.1]:60568 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:41:33 bluebunny kernel: TCP: [192.168.0.1]:60569 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:41:33 bluebunny kernel: TCP: [192.168.0.1]:60033 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:41:33 bluebunny kernel: TCP: [192.168.0.1]:60034 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:41:33 bluebunny kernel: TCP: [192.168.0.1]:60567 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:41:33 bluebunny kernel: TCP: [192.168.0.1]:60568 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:41:33 bluebunny kernel: TCP: [192.168.0.1]:60569 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:41:33 bluebunny kernel: TCP: [192.168.0.1]:60033 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:41:33 bluebunny kernel: TCP: [192.168.0.1]:60034 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:41:33 bluebunny kernel: TCP: [192.168.0.1]:60567 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:41:33 bluebunny kernel: TCP: [192.168.0.1]:60568 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:41:33 bluebunny kernel: TCP: [192.168.0.1]:60569 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:41:34 bluebunny kernel: TCP: [192.168.0.1]:60033 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:41:34 bluebunny kernel: TCP: [192.168.0.1]:60034 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:41:34 bluebunny kernel: TCP: [192.168.0.1]:60567 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:41:34 bluebunny kernel: TCP: [192.168.0.1]:60568 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:41:34 bluebunny kernel: TCP: [192.168.0.1]:60569 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:41:34 bluebunny kernel: TCP: [192.168.0.1]:60567 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:41:34 bluebunny kernel: TCP: [192.168.0.1]:60568 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:41:34 bluebunny kernel: TCP: [192.168.0.1]:60569 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:41:34 bluebunny kernel: TCP: [192.168.0.1]:60033 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:41:34 bluebunny kernel: TCP: [192.168.0.1]:60034 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:41:34 bluebunny kernel: TCP: [192.168.0.1]:60567 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:41:34 bluebunny kernel: TCP: [192.168.0.1]:60568 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:41:34 bluebunny kernel: TCP: [192.168.0.1]:60569 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:41:34 bluebunny kernel: TCP: [192.168.0.1]:60033 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:41:34 bluebunny kernel: TCP: [192.168.0.1]:60034 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:41:35 bluebunny kernel: TCP: [192.168.0.1]:60567 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:41:35 bluebunny kernel: TCP: [192.168.0.1]:60568 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:41:35 bluebunny kernel: TCP: [192.168.0.1]:60569 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:41:35 bluebunny kernel: TCP: [192.168.0.1]:60567 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:41:35 bluebunny kernel: TCP: [192.168.0.1]:60568 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:41:35 bluebunny kernel: TCP: [192.168.0.1]:60569 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:41:35 bluebunny kernel: TCP: [192.168.0.1]:60033 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:41:35 bluebunny kernel: TCP: [192.168.0.1]:60034 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:41:36 bluebunny kernel: TCP: [192.168.0.1]:60567 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:41:36 bluebunny kernel: TCP: [192.168.0.1]:60568 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:41:36 bluebunny kernel: TCP: [192.168.0.1]:60569 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:41:36 bluebunny kernel: TCP: [192.168.0.1]:60033 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:41:36 bluebunny kernel: TCP: [192.168.0.1]:60034 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:41:37 bluebunny kernel: TCP: [192.168.0.1]:60567 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:41:37 bluebunny kernel: TCP: [192.168.0.1]:60568 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:41:37 bluebunny kernel: TCP: [192.168.0.1]:60569 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected * webserver restarted @ #a * benchmark runs OK @ #b * webserver restarted @ #a * benchmark runs and FAILS @ #b Jul 24 17:42:51 bluebunny kernel: TCP: [192.168.0.1]:60033 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:42:51 bluebunny kernel: TCP: [192.168.0.1]:60034 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:42:52 bluebunny kernel: TCP: [192.168.0.1]:60567 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:42:52 bluebunny kernel: TCP: [192.168.0.1]:60568 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:42:52 bluebunny kernel: TCP: [192.168.0.1]:60569 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:42:54 bluebunny kernel: TCP: [192.168.0.1]:60033 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:42:54 bluebunny kernel: TCP: [192.168.0.1]:60034 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:42:54 bluebunny kernel: TCP: [192.168.0.1]:60033 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:42:54 bluebunny kernel: TCP: [192.168.0.1]:60034 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:42:55 bluebunny kernel: TCP: [192.168.0.1]:60033 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:42:55 bluebunny kernel: TCP: [192.168.0.1]:60034 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:42:55 bluebunny kernel: TCP: [192.168.0.1]:60567 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:42:55 bluebunny kernel: TCP: [192.168.0.1]:60568 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:42:55 bluebunny kernel: TCP: [192.168.0.1]:60569 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:42:55 bluebunny kernel: TCP: [192.168.0.1]:60033 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:42:55 bluebunny kernel: TCP: [192.168.0.1]:60034 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:42:55 bluebunny kernel: TCP: [192.168.0.1]:60567 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:42:55 bluebunny kernel: TCP: [192.168.0.1]:60568 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:42:55 bluebunny kernel: TCP: [192.168.0.1]:60569 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:42:55 bluebunny kernel: TCP: [192.168.0.1]:60033 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:42:55 bluebunny kernel: TCP: [192.168.0.1]:60034 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:42:55 bluebunny kernel: TCP: [192.168.0.1]:60567 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:42:55 bluebunny kernel: TCP: [192.168.0.1]:60568 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:42:55 bluebunny kernel: TCP: [192.168.0.1]:60569 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:42:55 bluebunny kernel: TCP: [192.168.0.1]:60033 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:42:55 bluebunny kernel: TCP: [192.168.0.1]:60034 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:42:55 bluebunny kernel: TCP: [192.168.0.1]:60567 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:42:55 bluebunny kernel: TCP: [192.168.0.1]:60568 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:42:55 bluebunny kernel: TCP: [192.168.0.1]:60569 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:42:56 bluebunny kernel: TCP: [192.168.0.1]:60033 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:42:56 bluebunny kernel: TCP: [192.168.0.1]:60034 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:42:56 bluebunny kernel: TCP: [192.168.0.1]:60567 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:42:56 bluebunny kernel: TCP: [192.168.0.1]:60568 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:42:56 bluebunny kernel: TCP: [192.168.0.1]:60569 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:42:56 bluebunny kernel: TCP: [192.168.0.1]:60567 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:42:56 bluebunny kernel: TCP: [192.168.0.1]:60568 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:42:56 bluebunny kernel: TCP: [192.168.0.1]:60569 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:42:56 bluebunny kernel: TCP: [192.168.0.1]:60033 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:42:56 bluebunny kernel: TCP: [192.168.0.1]:60034 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:42:56 bluebunny kernel: TCP: [192.168.0.1]:60567 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:42:56 bluebunny kernel: TCP: [192.168.0.1]:60568 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:42:56 bluebunny kernel: TCP: [192.168.0.1]:60569 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:42:56 bluebunny kernel: TCP: [192.168.0.1]:60033 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:42:56 bluebunny kernel: TCP: [192.168.0.1]:60034 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:42:56 bluebunny kernel: TCP: [192.168.0.1]:60567 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:42:56 bluebunny kernel: TCP: [192.168.0.1]:60568 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:42:56 bluebunny kernel: TCP: [192.168.0.1]:60569 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:42:57 bluebunny kernel: TCP: [192.168.0.1]:60033 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:42:57 bluebunny kernel: TCP: [192.168.0.1]:60034 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:42:57 bluebunny kernel: TCP: [192.168.0.1]:60567 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:42:57 bluebunny kernel: TCP: [192.168.0.1]:60568 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:42:57 bluebunny kernel: TCP: [192.168.0.1]:60569 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:42:57 bluebunny kernel: TCP: [192.168.0.1]:60567 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:42:57 bluebunny kernel: TCP: [192.168.0.1]:60568 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:42:57 bluebunny kernel: TCP: [192.168.0.1]:60569 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:42:57 bluebunny kernel: TCP: [192.168.0.1]:60033 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:42:57 bluebunny kernel: TCP: [192.168.0.1]:60034 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:42:58 bluebunny kernel: TCP: [192.168.0.1]:60567 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:42:58 bluebunny kernel: TCP: [192.168.0.1]:60568 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:42:58 bluebunny kernel: TCP: [192.168.0.1]:60569 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:42:58 bluebunny kernel: TCP: [192.168.0.1]:60033 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:42:58 bluebunny kernel: TCP: [192.168.0.1]:60034 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:42:59 bluebunny kernel: TCP: [192.168.0.1]:60567 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:42:59 bluebunny kernel: TCP: [192.168.0.1]:60568 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:42:59 bluebunny kernel: TCP: [192.168.0.1]:60569 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected * webserver restarted @ #a * benchmark runs OK @ #b * webserver restarted @ #a * benchmark runs and FAILS @ #b Jul 24 17:44:24 bluebunny kernel: TCP: [192.168.0.1]:60033 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:44:24 bluebunny kernel: TCP: [192.168.0.1]:60034 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:44:25 bluebunny kernel: TCP: [192.168.0.1]:60567 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:44:25 bluebunny kernel: TCP: [192.168.0.1]:60568 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:44:25 bluebunny kernel: TCP: [192.168.0.1]:60569 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:44:27 bluebunny kernel: TCP: [192.168.0.1]:60033 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:44:27 bluebunny kernel: TCP: [192.168.0.1]:60034 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:44:27 bluebunny kernel: TCP: [192.168.0.1]:60033 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:44:27 bluebunny kernel: TCP: [192.168.0.1]:60034 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:44:28 bluebunny kernel: TCP: [192.168.0.1]:60033 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:44:28 bluebunny kernel: TCP: [192.168.0.1]:60034 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:44:28 bluebunny kernel: TCP: [192.168.0.1]:60567 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:44:28 bluebunny kernel: TCP: [192.168.0.1]:60568 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:44:28 bluebunny kernel: TCP: [192.168.0.1]:60569 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:44:28 bluebunny kernel: TCP: [192.168.0.1]:60033 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:44:28 bluebunny kernel: TCP: [192.168.0.1]:60034 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:44:28 bluebunny kernel: TCP: [192.168.0.1]:60567 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:44:28 bluebunny kernel: TCP: [192.168.0.1]:60568 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:44:28 bluebunny kernel: TCP: [192.168.0.1]:60569 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:44:28 bluebunny kernel: TCP: [192.168.0.1]:60033 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:44:28 bluebunny kernel: TCP: [192.168.0.1]:60034 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:44:28 bluebunny kernel: TCP: [192.168.0.1]:60567 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:44:28 bluebunny kernel: TCP: [192.168.0.1]:60568 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:44:28 bluebunny kernel: TCP: [192.168.0.1]:60569 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:44:28 bluebunny kernel: TCP: [192.168.0.1]:60033 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:44:28 bluebunny kernel: TCP: [192.168.0.1]:60034 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:44:28 bluebunny kernel: TCP: [192.168.0.1]:60567 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:44:28 bluebunny kernel: TCP: [192.168.0.1]:60568 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:44:28 bluebunny kernel: TCP: [192.168.0.1]:60569 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:44:28 bluebunny kernel: TCP: [192.168.0.1]:60033 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:44:28 bluebunny kernel: TCP: [192.168.0.1]:60034 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:44:28 bluebunny kernel: TCP: [192.168.0.1]:60567 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:44:28 bluebunny kernel: TCP: [192.168.0.1]:60568 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:44:28 bluebunny kernel: TCP: [192.168.0.1]:60569 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:44:29 bluebunny kernel: TCP: [192.168.0.1]:60567 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:44:29 bluebunny kernel: TCP: [192.168.0.1]:60568 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:44:29 bluebunny kernel: TCP: [192.168.0.1]:60569 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:44:29 bluebunny kernel: TCP: [192.168.0.1]:60033 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:44:29 bluebunny kernel: TCP: [192.168.0.1]:60034 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:44:29 bluebunny kernel: TCP: [192.168.0.1]:60567 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:44:29 bluebunny kernel: TCP: [192.168.0.1]:60568 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:44:29 bluebunny kernel: TCP: [192.168.0.1]:60569 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:44:29 bluebunny kernel: TCP: [192.168.0.1]:60033 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:44:29 bluebunny kernel: TCP: [192.168.0.1]:60034 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:44:29 bluebunny kernel: TCP: [192.168.0.1]:60567 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:44:29 bluebunny kernel: TCP: [192.168.0.1]:60568 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:44:29 bluebunny kernel: TCP: [192.168.0.1]:60569 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:44:30 bluebunny kernel: TCP: [192.168.0.1]:60033 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:44:30 bluebunny kernel: TCP: [192.168.0.1]:60034 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:44:30 bluebunny kernel: TCP: [192.168.0.1]:60567 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:44:30 bluebunny kernel: TCP: [192.168.0.1]:60568 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:44:30 bluebunny kernel: TCP: [192.168.0.1]:60569 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:44:30 bluebunny kernel: TCP: [192.168.0.1]:60567 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:44:30 bluebunny kernel: TCP: [192.168.0.1]:60568 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:44:30 bluebunny kernel: TCP: [192.168.0.1]:60569 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:44:30 bluebunny kernel: TCP: [192.168.0.1]:60033 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:44:30 bluebunny kernel: TCP: [192.168.0.1]:60034 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:44:31 bluebunny kernel: TCP: [192.168.0.1]:60567 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:44:31 bluebunny kernel: TCP: [192.168.0.1]:60568 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:44:31 bluebunny kernel: TCP: [192.168.0.1]:60569 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:44:31 bluebunny kernel: TCP: [192.168.0.1]:60033 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:44:31 bluebunny kernel: TCP: [192.168.0.1]:60034 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:44:32 bluebunny kernel: TCP: [192.168.0.1]:60567 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:44:32 bluebunny kernel: TCP: [192.168.0.1]:60568 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:44:32 bluebunny kernel: TCP: [192.168.0.1]:60569 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected * webserver restarted @ #a * benchmark runs and FAILS @ #b: Jul 24 17:46:05 bluebunny kernel: TCP: [192.168.0.1]:60033 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:46:05 bluebunny kernel: TCP: [192.168.0.1]:60034 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:46:05 bluebunny kernel: TCP: [192.168.0.1]:60567 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:46:05 bluebunny kernel: TCP: [192.168.0.1]:60568 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:46:05 bluebunny kernel: TCP: [192.168.0.1]:60569 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:46:08 bluebunny kernel: TCP: [192.168.0.1]:60033 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:46:08 bluebunny kernel: TCP: [192.168.0.1]:60034 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:46:08 bluebunny kernel: TCP: [192.168.0.1]:60033 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:46:08 bluebunny kernel: TCP: [192.168.0.1]:60034 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:46:08 bluebunny kernel: TCP: [192.168.0.1]:60033 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:46:08 bluebunny kernel: TCP: [192.168.0.1]:60034 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:46:08 bluebunny kernel: TCP: [192.168.0.1]:60567 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:46:08 bluebunny kernel: TCP: [192.168.0.1]:60568 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:46:08 bluebunny kernel: TCP: [192.168.0.1]:60569 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:46:08 bluebunny kernel: TCP: [192.168.0.1]:60033 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:46:08 bluebunny kernel: TCP: [192.168.0.1]:60034 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:46:08 bluebunny kernel: TCP: [192.168.0.1]:60567 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:46:08 bluebunny kernel: TCP: [192.168.0.1]:60568 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:46:08 bluebunny kernel: TCP: [192.168.0.1]:60569 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:46:08 bluebunny kernel: TCP: [192.168.0.1]:60033 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:46:08 bluebunny kernel: TCP: [192.168.0.1]:60034 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:46:08 bluebunny kernel: TCP: [192.168.0.1]:60567 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:46:08 bluebunny kernel: TCP: [192.168.0.1]:60568 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:46:08 bluebunny kernel: TCP: [192.168.0.1]:60569 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:46:09 bluebunny kernel: TCP: [192.168.0.1]:60033 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:46:09 bluebunny kernel: TCP: [192.168.0.1]:60034 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:46:09 bluebunny kernel: TCP: [192.168.0.1]:60567 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:46:09 bluebunny kernel: TCP: [192.168.0.1]:60568 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:46:09 bluebunny kernel: TCP: [192.168.0.1]:60569 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:46:09 bluebunny kernel: TCP: [192.168.0.1]:60033 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:46:09 bluebunny kernel: TCP: [192.168.0.1]:60034 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:46:09 bluebunny kernel: TCP: [192.168.0.1]:60567 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:46:09 bluebunny kernel: TCP: [192.168.0.1]:60568 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:46:09 bluebunny kernel: TCP: [192.168.0.1]:60569 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:46:09 bluebunny kernel: TCP: [192.168.0.1]:60033 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:46:09 bluebunny kernel: TCP: [192.168.0.1]:60034 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:46:09 bluebunny kernel: TCP: [192.168.0.1]:60567 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:46:09 bluebunny kernel: TCP: [192.168.0.1]:60568 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:46:09 bluebunny kernel: TCP: [192.168.0.1]:60569 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:46:09 bluebunny kernel: TCP: [192.168.0.1]:60567 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:46:09 bluebunny kernel: TCP: [192.168.0.1]:60568 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:46:09 bluebunny kernel: TCP: [192.168.0.1]:60569 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:46:09 bluebunny kernel: TCP: [192.168.0.1]:60033 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:46:09 bluebunny kernel: TCP: [192.168.0.1]:60034 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:46:10 bluebunny kernel: TCP: [192.168.0.1]:60567 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:46:10 bluebunny kernel: TCP: [192.168.0.1]:60568 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:46:10 bluebunny kernel: TCP: [192.168.0.1]:60569 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:46:10 bluebunny kernel: TCP: [192.168.0.1]:60033 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:46:10 bluebunny kernel: TCP: [192.168.0.1]:60034 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:46:10 bluebunny kernel: TCP: [192.168.0.1]:60567 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:46:10 bluebunny kernel: TCP: [192.168.0.1]:60568 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:46:10 bluebunny kernel: TCP: [192.168.0.1]:60569 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:46:10 bluebunny kernel: TCP: [192.168.0.1]:60567 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:46:10 bluebunny kernel: TCP: [192.168.0.1]:60568 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:46:10 bluebunny kernel: TCP: [192.168.0.1]:60569 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:46:11 bluebunny kernel: TCP: [192.168.0.1]:60033 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:46:11 bluebunny kernel: TCP: [192.168.0.1]:60034 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:46:11 bluebunny kernel: TCP: [192.168.0.1]:60567 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:46:11 bluebunny kernel: TCP: [192.168.0.1]:60568 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:46:11 bluebunny kernel: TCP: [192.168.0.1]:60569 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:46:11 bluebunny kernel: TCP: [192.168.0.1]:60033 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:46:11 bluebunny kernel: TCP: [192.168.0.1]:60034 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:46:12 bluebunny kernel: TCP: [192.168.0.1]:60567 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:46:12 bluebunny kernel: TCP: [192.168.0.1]:60568 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected Jul 24 17:46:12 bluebunny kernel: TCP: [192.168.0.1]:60569 to [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected * webserver restarted @ #a * benchmark runs OK @ #b (etc etc) On the client machine, there are no such errors. I only get spurious RST's on my workstation when using ktorrent. Normal browsing/email/downloads via opera never seem to trigger it. Notice the source ports number are always the same on each run, perhaps that's valuable information for someone who deeply understands the code.. if any of the above was helpful, let me know if there's anything else I can do. Best regards, Hugo From owner-freebsd-current@FreeBSD.ORG Tue Jul 24 17:16:58 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 7FAC916A421 for ; Tue, 24 Jul 2007 17:16:58 +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 3884A13C4CB for ; Tue, 24 Jul 2007 17:16:58 +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 79E2DEB279A; Wed, 25 Jul 2007 01:16:57 +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 uSz7FbfFC+Lf; Wed, 25 Jul 2007 01:16:53 +0800 (CST) Received: from charlie.delphij.net (unknown [61.49.186.182]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id A215AEB2797; Wed, 25 Jul 2007 01:16:53 +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:subject: references:in-reply-to:content-type:content-transfer-encoding; b=IKw4pKTJ4Pk2U3HxvBotcSkQ7Ywuz7lEW7CsDEQ4MvjuMUqkte11M60ZozvhtnTm2 IRQA97IDdQ9Yv146odPCQ== Message-ID: <46A63405.8010605@delphij.net> Date: Wed, 25 Jul 2007 01:16:53 +0800 From: Xin LI User-Agent: Thunderbird 2.0.0.5 (X11/20070721) MIME-Version: 1.0 To: Craig Boston , Xin LI , freebsd-current@freebsd.org References: <46A625FB.5050105@delphij.net> <20070724164215.GA3329@nowhere> In-Reply-To: <20070724164215.GA3329@nowhere> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: Call for non i386/amd64 testers for tmpfs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 24 Jul 2007 17:16:58 -0000 Craig Boston wrote: > On Wed, Jul 25, 2007 at 12:16:59AM +0800, Xin LI wrote: >> I'd like to request that some owners of non-i386/amd64 boxes to test >> sys/modules/tmpfs and report if it would work correctly on other >> architectures, so I will be able to determine if it is appropriate to >> connect it to build on these architectures (and perhaps pick out more >> bugs :) > > Hi, funny you should post just now. It's for i386 but I just submitted > a PR about tmpfs :-) > > Details are in kern/114870, but basically there's an overflow problem on > 32-bit systems with a large amount of swap. > > Here's the quick fix that I attached to the PR: Ah... Ok I have checked in a similar patch that applies to the -HEAD code, thanks! Cheers, From owner-freebsd-current@FreeBSD.ORG Tue Jul 24 21:23:20 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 5D72516A417 for ; Tue, 24 Jul 2007 21:23:20 +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 2256413C46B for ; Tue, 24 Jul 2007 21:23:19 +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 93394-09; Tue, 24 Jul 2007 22:58:41 +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 849E93E944B; Tue, 24 Jul 2007 22:58:41 +0200 (CEST) Received: from webmail.alpha-tierchen.de (localhost [127.0.0.1]) by home.alpha-tierchen.de (Postfix) with ESMTP id 1676E45066; Tue, 24 Jul 2007 22:55:53 +0200 (CEST) Received: from 2001:6f8:101e:0:20e:cff:fe6d:6adb (SquirrelMail authenticated user bkoenig) by webmail.alpha-tierchen.de with HTTP; Tue, 24 Jul 2007 22:55:53 +0200 (CEST) Message-ID: <50002.2001:6f8:101e:0:20e:cff:fe6d:6adb.1185310553.squirrel@webmail.alpha-tierchen.de> In-Reply-To: <46A625FB.5050105@delphij.net> References: <46A625FB.5050105@delphij.net> Date: Tue, 24 Jul 2007 22:55:53 +0200 (CEST) From: =?iso-8859-1?Q?Bj=F6rn_K=F6nig?= To: "Xin LI" 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: freebsd-current@freebsd.org Subject: Re: Call for non i386/amd64 testers for tmpfs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 24 Jul 2007 21:23:20 -0000 Xin LI wrote: > I'd like to request that some owners of non-i386/amd64 boxes to test > sys/modules/tmpfs and report if it would work correctly on other > architectures, [...] I built and used the module on arm architecture without problems. The board has 64 MB RAM and 512 MB swap via NFS. I ran the bonnie benchmark on that filesystem with a 256 MB test file successfully. Do you want a certain scenario to be tested? Regards Björn From owner-freebsd-current@FreeBSD.ORG Tue Jul 24 22: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 5E69516A41B for ; Tue, 24 Jul 2007 22:10:30 +0000 (UTC) (envelope-from sem@FreeBSD.org) Received: from mail.ciam.ru (ns.ciam.ru [213.247.195.75]) by mx1.freebsd.org (Postfix) with ESMTP id 25B2F13C4A6 for ; Tue, 24 Jul 2007 22:10:30 +0000 (UTC) (envelope-from sem@FreeBSD.org) Received: from [87.240.16.199] (helo=[192.168.0.2]) by mail.ciam.ru with esmtpa (Exim 4.x) id 1IDS8h-0006vE-O8 for current@freebsd.org; Wed, 25 Jul 2007 01:41:55 +0400 Message-ID: <46A67223.9010604@FreeBSD.org> Date: Wed, 25 Jul 2007 01:41:55 +0400 From: Sergey Matveychuk User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: current@freebsd.org Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Cc: Subject: fresh current hangs on boot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 24 Jul 2007 22:10:30 -0000 freshes CURRENT from Jul 21 hangs on boot in multiuser mode. The last lines: Starting devd. /etc/rc: DEBUG: run_rc_command: doit: /sbin/devd /etc/pccard_ether: DEBUG: run_rccommand: start_precmd: checkauto /etc/pccard_ether: DEBUG: run_rccommand: doit: pccard_ether_start /etc/pccard_ether: DEBUG: run_rccommand: start_precmd: checkauto /etc/pccard_ether: DEBUG: run_rccommand: doit: pccard_ether_start nve0: linkstate changed to DOWN Why two last commands run twice? I have no pccard anyway. The computer boots only after couple resets. Unfortunately I've built kernel w/o debugger. So I can't to get core or backtrace. I'll rebuild it. -- Dixi. Sem. From owner-freebsd-current@FreeBSD.ORG Wed Jul 25 05:11: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 A546D16A418 for ; Wed, 25 Jul 2007 05:11:10 +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 85ADB13C459 for ; Wed, 25 Jul 2007 05:11:10 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by wa-out-1112.google.com with SMTP id j37so95487waf for ; Tue, 24 Jul 2007 22:11:10 -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=S0DNujTGzt9ZtprNriU4ECrLcOGxb7VpdPhwK038fdfAAr3Ihlgl5l/dxmiB8ovYRTJfEQTzUqXkbFHgiSQetWUNEN7PFxj7JNoMY3tPaAX8I5DP83ywcpG68Evfa3qu/Frbm+Y406+Bz4TUDBe9fE6+5jGlm3UVpQ0JYpiyjeQ= 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=DuPDmmDpBD5/mDuZ4rSIxjX0rfeLT8aRKCS9vNFUj/ka3/w5wHFMrPV8vpoFCMFPrJHiEXxWGw7m8KwLn/VktH5o8lpdqAANhAR4hkyOWQYF90QZfBkR7PwjR1hEkq06CKJf0t7QQ+y/TaPtL4d683EmZIvxpKuovx9p2UDb/cc= Received: by 10.114.106.1 with SMTP id e1mr278435wac.1185340270084; Tue, 24 Jul 2007 22:11:10 -0700 (PDT) Received: by 10.114.103.14 with HTTP; Tue, 24 Jul 2007 22:11:09 -0700 (PDT) Message-ID: <2a41acea0707242211k6ebe3b77p6a9341b1b2d40210@mail.gmail.com> Date: Tue, 24 Jul 2007 22:11:10 -0700 From: "Jack Vogel" To: freebsd-net , "FreeBSD Stable List" , "FreeBSD Current" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Subject: Merged em 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, 25 Jul 2007 05:11:10 -0000 The next driver I that I release via Intel channels is going to merge the code for 6 and 7. I was thinking that I could check that into the tip and it would make the most current version buildable on either RELEASE, was wondering if that is looked upon favorably or not? I have code ready to do that if getting it into 7.0 would be desireable. Jack From owner-freebsd-current@FreeBSD.ORG Wed Jul 25 05:40: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 EC5C716A41A for ; Wed, 25 Jul 2007 05:40:24 +0000 (UTC) (envelope-from silby@silby.com) Received: from relay01.pair.com (relay01.pair.com [209.68.5.15]) by mx1.freebsd.org (Postfix) with SMTP id 8898313C474 for ; Wed, 25 Jul 2007 05:40:24 +0000 (UTC) (envelope-from silby@silby.com) Received: (qmail 80843 invoked from network); 25 Jul 2007 05:40:23 -0000 Received: from 209.68.2.70 (HELO localhost) (209.68.2.70) by relay01.pair.com with SMTP; 25 Jul 2007 05:40:23 -0000 X-pair-Authenticated: 209.68.2.70 Date: Wed, 25 Jul 2007 00:40:22 -0500 (CDT) From: Mike Silbersack To: Peter Wemm In-Reply-To: <200707201155.44573.peter@wemm.org> Message-ID: <20070725003706.U79872@odysseus.silby.com> References: <20070709234401.S29353@odysseus.silby.com> <20070710132253.GJ1038@void.codelabs.ru> <20070710202028.I34890@odysseus.silby.com> <200707201155.44573.peter@wemm.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Andre Oppermann , current@freebsd.org, freebsd-current@freebsd.org, 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: Wed, 25 Jul 2007 05:40:25 -0000 On Fri, 20 Jul 2007, Peter Wemm wrote: > 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. :-( Any extra ACK that arrives is probably being processed by the syncookie code is my guess. So, I think that the problem is probably anywhere except in the syncookie code. > I'll give your patch a shot and see if it improves things at all. It won't, not for this case. :( But I'll get it committed ASAP, because it fixes other cases. Unless, that is, things IRL keep interrupting me. Mike "Silby" Silbersack From owner-freebsd-current@FreeBSD.ORG Wed Jul 25 05:45:28 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 2310416A417 for ; Wed, 25 Jul 2007 05:45:28 +0000 (UTC) (envelope-from freebsdworld@gmail.com) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.185]) by mx1.freebsd.org (Postfix) with ESMTP id D854113C45A for ; Wed, 25 Jul 2007 05:45:26 +0000 (UTC) (envelope-from freebsdworld@gmail.com) Received: by fk-out-0910.google.com with SMTP id b27so8849fka for ; Tue, 24 Jul 2007 22:45: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; b=eczq7TwXHWis0Dt385gjnrTen8GUXhayoe/8t87Iimo6v2rg5QVtFQ8Mwsvm0MLd3DEyT3GPaf9WWR54+p6fa+JmRblKa2aabug6KXk5jizgSGez2zjUCF95BLQxZp9hFRUFtq1BT1bDlbufAJ1EhdLDf8yWUoXF2ij4hoSDrow= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=m+W++XceR/IJBfJDnEov9HzGLQHAMUg0Mw5wGSgrR+sU5WpfRbPfUiMl5eGYlx6UxZCUYEExCr0HKDwSkEiRAT44/0vq8mfjU/C7TKtDn/ZMLvKK75GBj5ggb2Rpw5un3QribTBD5xLNJPHavj1ZF3l+8uzhwlpaJp/le81gZAo= Received: by 10.82.136.4 with SMTP id j4mr68372bud.1185340712555; Tue, 24 Jul 2007 22:18:32 -0700 (PDT) Received: by 10.82.170.8 with HTTP; Tue, 24 Jul 2007 22:18:32 -0700 (PDT) Message-ID: <6199c3dc0707242218u5837b270oc17991c97bdc86ef@mail.gmail.com> Date: Wed, 25 Jul 2007 01:18:32 -0400 From: "Benjamin Adams" 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: kernel memory problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2007 05:45:28 -0000 I'm trying to figure out the problem with my computer: 8 out of 10 times on boot when ssh starts loading I get: Jul 25 00:28:40 Desktop kernel: Memory modified after free 0xffffff0053de4800(2048) val=ffffc0de @ 0xffffff0053de4800 Jul 25 00:29:18 Desktop kernel: Memory modified after free 0xffffff0053de2000(2048) val=ffffc0de @ 0xffffff0053de2000 Jul 25 00:29:19 Desktop kernel: Memory modified after free 0xffffff0053de3800(2048) val=ffffc0de @ 0xffffff0053de3800 Jul 25 00:29:20 Desktop kernel: Memory modified after free 0xffffff0053de1000(2048) val=ffffc0de @ 0xffffff0053de1000 Jul 25 00:29:21 Desktop kernel: Memory modified after free 0xffffff0053de2800(2048) val=ffffc0de @ 0xffffff0053de2800 Jul 25 00:29:22 Desktop kernel: Memory modified after free 0xffffff0053de0000(2048) val=ffffc0de @ 0xffffff0053de0000 Jul 25 00:29:23 Desktop kernel: Memory modified after free 0xffffff0053de1800(2048) val=ffffc0de @ 0xffffff0053de1800 (goes on a on until I do a cold boot) computer will also go very very slow sometimes. Is this a bad memory problem or something with the kernel? uname: 7.0-CURRENT-200706 FreeBSD 7.0-CURRENT-200706 #0: Thu Jun 7 21:38:42 UTC 2007 root@stiles.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 FreeBSD amd64 7.0 200706 thanks Ben Adams From owner-freebsd-current@FreeBSD.ORG Wed Jul 25 06:07: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 92D9A16A473 for ; Wed, 25 Jul 2007 06:07:04 +0000 (UTC) (envelope-from silby@silby.com) Received: from relay01.pair.com (relay01.pair.com [209.68.5.15]) by mx1.freebsd.org (Postfix) with SMTP id 2801613C45A for ; Wed, 25 Jul 2007 06:07:04 +0000 (UTC) (envelope-from silby@silby.com) Received: (qmail 80843 invoked from network); 25 Jul 2007 05:40:23 -0000 Received: from 209.68.2.70 (HELO localhost) (209.68.2.70) by relay01.pair.com with SMTP; 25 Jul 2007 05:40:23 -0000 X-pair-Authenticated: 209.68.2.70 Date: Wed, 25 Jul 2007 00:40:22 -0500 (CDT) From: Mike Silbersack To: Peter Wemm In-Reply-To: <200707201155.44573.peter@wemm.org> Message-ID: <20070725003706.U79872@odysseus.silby.com> References: <20070709234401.S29353@odysseus.silby.com> <20070710132253.GJ1038@void.codelabs.ru> <20070710202028.I34890@odysseus.silby.com> <200707201155.44573.peter@wemm.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Andre Oppermann , current@freebsd.org, freebsd-current@freebsd.org, 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: Wed, 25 Jul 2007 06:07:04 -0000 On Fri, 20 Jul 2007, Peter Wemm wrote: > 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. :-( Any extra ACK that arrives is probably being processed by the syncookie code is my guess. So, I think that the problem is probably anywhere except in the syncookie code. > I'll give your patch a shot and see if it improves things at all. It won't, not for this case. :( But I'll get it committed ASAP, because it fixes other cases. Unless, that is, things IRL keep interrupting me. Mike "Silby" Silbersack From owner-freebsd-current@FreeBSD.ORG Wed Jul 25 06:28:27 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 8750B16A418; Wed, 25 Jul 2007 06:28:27 +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 0456A13C45E; Wed, 25 Jul 2007 06:28:26 +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 12CB3EB2884; Wed, 25 Jul 2007 14:28: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 iDcGIDcpmUJR; Wed, 25 Jul 2007 14:28: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 D5FE6EB2879; Wed, 25 Jul 2007 14:28:20 +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=fgKhnwXKoMmtY8yBOCs5VWgB4qG+/TUMf1HDbIySwDyxx1r1hCpzUR9LQKaft/Q31 DW4LMerrHKYoxgmfrcYdg== Message-ID: <46A6ED6F.7090908@delphij.net> Date: Wed, 25 Jul 2007 14:27:59 +0800 From: LI Xin Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.5 (Macintosh/20070716) MIME-Version: 1.0 To: Jack Vogel References: <2a41acea0707242211k6ebe3b77p6a9341b1b2d40210@mail.gmail.com> In-Reply-To: <2a41acea0707242211k6ebe3b77p6a9341b1b2d40210@mail.gmail.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="------------enigCB1FBDE5214C236551365BDF" Cc: freebsd-net , FreeBSD Current , FreeBSD Stable List Subject: Re: Merged em driver 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, 25 Jul 2007 06:28:27 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigCB1FBDE5214C236551365BDF Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Jack Vogel wrote: > The next driver I that I release via Intel channels is going to > merge the code for 6 and 7. I was thinking that I could check that > into the tip and it would make the most current version buildable > on either RELEASE, was wondering if that is looked upon favorably > or not? I have code ready to do that if getting it into 7.0 would be > desireable. I think that if the change is not quite intrusive (e.g. add some ifdef blocks rather than restructuring the code heavily) then it would be desirable to have it hit the tree before we branch RELENG_7. However, if the change would be very late then it would be better to have it delayed and only "backport" important fixes in a case-by-case manner. My $0.02 :-) Cheers, --=20 Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! --------------enigCB1FBDE5214C236551365BDF 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 iD8DBQFGpu1vOfuToMruuMARCrcVAJ4iitqQwbmX6AYI9ka7ZCZmPijZQwCfZyGh YoPZKbwIUaaXP7DmxFaMgOo= =bi+2 -----END PGP SIGNATURE----- --------------enigCB1FBDE5214C236551365BDF-- From owner-freebsd-current@FreeBSD.ORG Wed Jul 25 06:32:44 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 E9FC216A419 for ; Wed, 25 Jul 2007 06:32:44 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from pobox.codelabs.ru (pobox.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id A3C5D13C483 for ; Wed, 25 Jul 2007 06:32:44 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Message-ID:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender:X-Spam-Status:Subject; b=hZlqIP0kmB2+898jOMCK2Afpa+jpb9Q14DoP00Oo3yil01r4kqg97riZ5gDu9uc0/wSwRLhgTVXuSef07jqWirMvmEMlWEn90tkBe9U2A1x/T7UIkIqxJ0mrYc4RL8rJJH38w1vsOzH3bWsfdvyb/mSiMKkAnw4lJML2uo35jlY=; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by pobox.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1IDaQK-000PrC-RF; Wed, 25 Jul 2007 10:32:40 +0400 Date: Wed, 25 Jul 2007 10:32:36 +0400 From: Eygene Ryabinkin To: Hugo Silva Message-ID: <20070725063236.GG1510@void.codelabs.ru> References: <46A62DC9.7080409@barafranca.com> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <46A62DC9.7080409@barafranca.com> Sender: rea-fbsd@codelabs.ru X-Spam-Status: No, score=-3.1 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_00 Cc: freebsd-current@FreeBSD.ORG Subject: Re: Spurious RST, segment rejected - possible pattern? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Jul 2007 06:32:45 -0000 Hugo, good day. Tue, Jul 24, 2007 at 05:50:17PM +0100, Hugo Silva wrote: >While conducting some benchmarks against various webserver software, (7-CURRENT >client vs 7-CURRENT server), I couldn't help notice that the flood of Spurious >RST (which only happens on the server side) seems to follow a specific pattern. <...> > Here's how it goes: > * webserver restarted @ #a > * benchmark runs and FAILS @ #b > Jul 24 17:31:46 bluebunny kernel: TCP: [192.168.0.1]:60033 to > [192.168.0.100]:80 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, > segment rejected <...more RSTs...> This topic was raised in the freebsd-net, http://lists.freebsd.org/pipermail/freebsd-net/2007-July/014804.html http://lists.freebsd.org/pipermail/freebsd-net/2007-July/014808.html and in the freebsd-current, http://lists.freebsd.org/pipermail/freebsd-current/2007-July/074837.html The issue is understood, but it is currently not publicly known how to deal with it. But Andre Oppermann and Robert Watson are aware of it and Andre told us that he will think how to fix it. So, stay tuned for the fix ;)) Thank you. -- Eygene From owner-freebsd-current@FreeBSD.ORG Wed Jul 25 08:03: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 9121916A417 for ; Wed, 25 Jul 2007 08:03:47 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id 29BDE13C459 for ; Wed, 25 Jul 2007 08:03:46 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (ppp121-45-48-57.lns11.adl2.internode.on.net [121.45.48.57]) (authenticated bits=0) by cain.gsoft.com.au (8.13.8/8.13.8) with ESMTP id l6P83eJK040699 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Jul 2007 17:33:44 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-current@freebsd.org Date: Wed, 25 Jul 2007 17:33:05 +0930 User-Agent: KMail/1.9.7 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2137188.eA5HxUGaD4"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200707251733.12658.doconnor@gsoft.com.au> X-Spam-Score: -2.312 () BAYES_00 X-Scanned-By: MIMEDefang 2.58 on 203.31.81.10 Subject: zsh oddities with recent -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, 25 Jul 2007 08:03:47 -0000 --nextPart2137188.eA5HxUGaD4 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline I updated my -current box (laptop) on the 18th and I have 2 strange=20 issues with zsh. 1) I can't unset environmental variables set before the shell started,=20 eg.. [inchoate 17:06] ~ >echo $FOO [inchoate 17:06] ~ >export FOO=3Dbar [inchoate 17:06] ~ >env | grep FOO =46OO=3Dbar [inchoate 17:06] ~ >unset FOO [inchoate 17:06] ~ >env | grep FOO [inchoate 17:06] ~ >export FOO=3Dbar [inchoate 17:06] ~ >exec zsh [inchoate 17:06] ~ >unset FOO [inchoate 17:06] ~ >env | grep FOO =46OO=3Dbar [inchoate 17:06] ~ >echo $FOO I've tried rebuilding zsh but that has had no effect. 2) Various signals (SIGSTATUS & SIGINTR at least) were being sent when I=20 press ctrl-t/c, stty showed they weren't set. Using stty I can set them=20 and it works but it's odd it's changed.. Also I can't seem to reproduce=20 it now that I put the stty commands in my .zshrc, even if I comment=20 them out and log into a different TTY - some global variable not inited=20 in the TTY code(??). =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart2137188.eA5HxUGaD4 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) iD8DBQBGpwPA5ZPcIHs/zowRAh6YAKCSusM/D/eKjJq0/V2ogbPaU7rZEACfe8QL WlxEshmDZLu+zs3us5O32VI= =qQay -----END PGP SIGNATURE----- --nextPart2137188.eA5HxUGaD4-- From owner-freebsd-current@FreeBSD.ORG Wed Jul 25 08:31: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 EAD6416A419; Wed, 25 Jul 2007 08:31:45 +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 B9E1413C481; Wed, 25 Jul 2007 08:31:45 +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 591D649688; Wed, 25 Jul 2007 04:31:45 -0400 (EDT) Date: Wed, 25 Jul 2007 09:31:45 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Mike Silbersack In-Reply-To: <20070725003706.U79872@odysseus.silby.com> Message-ID: <20070725093019.E83919@fledge.watson.org> References: <20070709234401.S29353@odysseus.silby.com> <20070710132253.GJ1038@void.codelabs.ru> <20070710202028.I34890@odysseus.silby.com> <200707201155.44573.peter@wemm.org> <20070725003706.U79872@odysseus.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Andre Oppermann , current@freebsd.org, Peter Wemm , freebsd-current@freebsd.org, 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: Wed, 25 Jul 2007 08:31:46 -0000 On Wed, 25 Jul 2007, Mike Silbersack wrote: > On Fri, 20 Jul 2007, Peter Wemm wrote: > >> 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. :-( > > Any extra ACK that arrives is probably being processed by the syncookie code > is my guess. So, I think that the problem is probably anywhere except in > the syncookie code. > >> I'll give your patch a shot and see if it improves things at all. > > It won't, not for this case. :( > > But I'll get it committed ASAP, because it fixes other cases. Unless, that > is, things IRL keep interrupting me. FYI, I received an informal report a few days ago that the SYN cache was ignoring RSTs, and kept transmitting SYN/ACK's even though a RST had been sent. This was during some local network testing where a host sends SYN packets out to a large number of other hosts, then quickly resets the connections after getting SYN/ACK's. Given that your previous work suggests that the syncache timer never fires at all, I'm not quite sure what to make of this report, but once your patches are in I can ask them to rerun it on one of my hosts and see. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Wed Jul 25 08:31:45 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 EAD6416A419; Wed, 25 Jul 2007 08:31:45 +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 B9E1413C481; Wed, 25 Jul 2007 08:31:45 +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 591D649688; Wed, 25 Jul 2007 04:31:45 -0400 (EDT) Date: Wed, 25 Jul 2007 09:31:45 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Mike Silbersack In-Reply-To: <20070725003706.U79872@odysseus.silby.com> Message-ID: <20070725093019.E83919@fledge.watson.org> References: <20070709234401.S29353@odysseus.silby.com> <20070710132253.GJ1038@void.codelabs.ru> <20070710202028.I34890@odysseus.silby.com> <200707201155.44573.peter@wemm.org> <20070725003706.U79872@odysseus.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Andre Oppermann , current@freebsd.org, Peter Wemm , freebsd-current@freebsd.org, 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: Wed, 25 Jul 2007 08:31:46 -0000 On Wed, 25 Jul 2007, Mike Silbersack wrote: > On Fri, 20 Jul 2007, Peter Wemm wrote: > >> 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. :-( > > Any extra ACK that arrives is probably being processed by the syncookie code > is my guess. So, I think that the problem is probably anywhere except in > the syncookie code. > >> I'll give your patch a shot and see if it improves things at all. > > It won't, not for this case. :( > > But I'll get it committed ASAP, because it fixes other cases. Unless, that > is, things IRL keep interrupting me. FYI, I received an informal report a few days ago that the SYN cache was ignoring RSTs, and kept transmitting SYN/ACK's even though a RST had been sent. This was during some local network testing where a host sends SYN packets out to a large number of other hosts, then quickly resets the connections after getting SYN/ACK's. Given that your previous work suggests that the syncache timer never fires at all, I'm not quite sure what to make of this report, but once your patches are in I can ask them to rerun it on one of my hosts and see. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Wed Jul 25 08:47:59 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 6AE9016A418; Wed, 25 Jul 2007 08:47:59 +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 D745513C467; Wed, 25 Jul 2007 08:47:58 +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 l6P8lucF077165; Wed, 25 Jul 2007 12:47:56 +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=1185353276; bh=9BVzSE1jAnpX2+33nXmWRZyQxp0VEBcU1mNnb9K Wy3Y=; l=1925; 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=VaC5dCmpLSEqD2X7caAD XZ3D+WKLTcrTtns/yrN70SGnvI/04mDAH2e9ormJO1pbpbCRzT25JZqwDmGUT8SYcCX aTo/Z6wdCTtgjgRNM3AK1rpF/fZKzpo4ww2EjFymsA1APa1Kj9Y66CCHMVeuaiSduhz 6keE47qSji5rWo1Xk= Received: (from ache@localhost) by nagual.pp.ru (8.14.1/8.14.1/Submit) id l6P8lugv077164; Wed, 25 Jul 2007 12:47:56 +0400 (MSD) (envelope-from ache) Date: Wed, 25 Jul 2007 12:47:56 +0400 From: Andrey Chernov To: "Daniel O'Connor" , sergei@FreeBSD.org, scf@FreeBSD.org Message-ID: <20070725084755.GA75871@nagual.pp.ru> Mail-Followup-To: Andrey Chernov , Daniel O'Connor , sergei@FreeBSD.org, scf@freebsd.org, freebsd-current@FreeBSD.ORG References: <200707251733.12658.doconnor@gsoft.com.au> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="AhhlLboLdkugWU4S" Content-Disposition: inline In-Reply-To: <200707251733.12658.doconnor@gsoft.com.au> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-current@FreeBSD.org Subject: Re: zsh oddities with recent -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, 25 Jul 2007 08:47:59 -0000 --AhhlLboLdkugWU4S Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 25, 2007 at 05:33:05PM +0930, Daniel O'Connor wrote: > I updated my -current box (laptop) on the 18th and I have 2 strange=20 > issues with zsh. >=20 > 1) I can't unset environmental variables set before the shell started,=20 > eg.. zsh uses system's putenv() but home-rolled delete from environment=20 (instead of unsetenv()). It clearly violates POSIX since it forbids to mix= =20 putenv/setenv/unsetenv with direct environ manipulations: "Conforming applications are required not to modify environ directly, but= =20 to use only the functions described here to manipulate the process=20 environment as an abstract object. Thus, the implementation of the=20 environment access functions has complete control over the data structure= =20 used to represent the environment (subject to the requirement that environ= =20 be maintained as a list of strings with embedded equal signs for=20 applications that wish to scan the environment). This constraint allows=20 the implementation to properly manage the memory it allocates, either by=20 using allocated storage for all variables (copying them on the first=20 invocation of setenv() or unsetenv()), or keeping track of which strings=20 are currently in allocated space and which are not, via a separate table=20 or some other means." Quick fix will be just to disable HAVE_PUTENV config option. It gains=20 nothing in the code but makes troubles. --=20 http://ache.pp.ru/ --AhhlLboLdkugWU4S Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFGpw47Vg5YK5ZEdN0RAgqTAKCDzLpnu6bRVhuPr4FSb9eH9pxVpgCeIWcc Nqq3g83PVR7wmPNnDzPoqdw= =pcfA -----END PGP SIGNATURE----- --AhhlLboLdkugWU4S-- From owner-freebsd-current@FreeBSD.ORG Wed Jul 25 09:02: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 9DEBB16A417; Wed, 25 Jul 2007 09:02:06 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (nagual.pp.ru [194.87.13.69]) by mx1.freebsd.org (Postfix) with ESMTP id 13C6513C46C; Wed, 25 Jul 2007 09:02:05 +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 l6P924mO087479; Wed, 25 Jul 2007 13:02:04 +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=1185354124; bh=4UnuQ/J+elURVj7/YiKMVFHqsghGk6M7wfj+aVU BWGg=; l=2369; h=Received:Date:From:To:Subject:Message-ID: Mail-Followup-To:References:MIME-Version:Content-Type: Content-Disposition:In-Reply-To:User-Agent; b=lODTAukTPK2CTb2cm9vH BrBBNBsuZIpbvmruEHTks/txpJ0vi1mhesDNZoqTB4awgknkVzRbOUmegqU7/3JJ1Oz QwRUeyYLFfX9Z833KFqrQPMefHnVjuhS41E3a0QJCfgLBCWiIWNUA8fok0zrqwoQ7nS 4e2UBp6jNuqRAD11A= Received: (from ache@localhost) by nagual.pp.ru (8.14.1/8.14.1/Submit) id l6P923uv087477; Wed, 25 Jul 2007 13:02:04 +0400 (MSD) (envelope-from ache) Date: Wed, 25 Jul 2007 13:02:03 +0400 From: Andrey Chernov To: "Daniel O'Connor" , sergei@FreeBSD.org, scf@FreeBSD.org, freebsd-current@FreeBSD.org Message-ID: <20070725090203.GA87414@nagual.pp.ru> Mail-Followup-To: Andrey Chernov , Daniel O'Connor , sergei@FreeBSD.org, scf@freebsd.org, freebsd-current@FreeBSD.ORG References: <200707251733.12658.doconnor@gsoft.com.au> <20070725084755.GA75871@nagual.pp.ru> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/04w6evG8XlLl3ft" Content-Disposition: inline In-Reply-To: <20070725084755.GA75871@nagual.pp.ru> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: Subject: Re: zsh oddities with recent -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, 25 Jul 2007 09:02:06 -0000 --/04w6evG8XlLl3ft Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 25, 2007 at 12:47:56PM +0400, Andrey Chernov wrote: > On Wed, Jul 25, 2007 at 05:33:05PM +0930, Daniel O'Connor wrote: > > I updated my -current box (laptop) on the 18th and I have 2 strange=20 > > issues with zsh. > >=20 > > 1) I can't unset environmental variables set before the shell started,= =20 > > eg.. >=20 > zsh uses system's putenv() but home-rolled delete from environment=20 > (instead of unsetenv()). It clearly violates POSIX since it forbids to mi= x=20 > putenv/setenv/unsetenv with direct environ manipulations: >=20 > "Conforming applications are required not to modify environ directly, but= =20 > to use only the functions described here to manipulate the process=20 > environment as an abstract object. Thus, the implementation of the=20 > environment access functions has complete control over the data structure= =20 > used to represent the environment (subject to the requirement that enviro= n=20 > be maintained as a list of strings with embedded equal signs for=20 > applications that wish to scan the environment). This constraint allows= =20 > the implementation to properly manage the memory it allocates, either by= =20 > using allocated storage for all variables (copying them on the first=20 > invocation of setenv() or unsetenv()), or keeping track of which strings= =20 > are currently in allocated space and which are not, via a separate table= =20 > or some other means." >=20 > Quick fix will be just to disable HAVE_PUTENV config option. It gains=20 > nothing in the code but makes troubles. The patch is here: --- configure.bak 2006-02-28 17:44:59.000000000 +0300 +++ configure 2007-07-25 12:59:34.000000000 +0400 @@ -10218,7 +10218,7 @@ setlocale \ uname \ signgam \ - putenv getenv \ + getenv \ brk sbrk \ pathconf sysconf \ tgetent tigetflag tigetnum tigetstr setupterm \ --=20 http://ache.pp.ru/ --/04w6evG8XlLl3ft Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFGpxGLVg5YK5ZEdN0RAv02AJ0cjgCH4QZ9/RrLB6nA/hg6dvQqpACgl1uY 8Ib7gkT3j5GdLt6rNpIuUKE= =mHCl -----END PGP SIGNATURE----- --/04w6evG8XlLl3ft-- From owner-freebsd-current@FreeBSD.ORG Wed Jul 25 09:31: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 2ACBC16A53D; Wed, 25 Jul 2007 09:31:34 +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 C365513C46A; Wed, 25 Jul 2007 09:31:33 +0000 (UTC) (envelope-from matteo@freebsd.org) Received: from rionda.dyndns.org (87.0.188.129) by vsmtp4.tin.it (7.3.122) id 469A4FF300EDC290; Wed, 25 Jul 2007 11:31:32 +0200 Received: from rionda.dyndns.org (rionda@localhost [127.0.0.1]) by rionda.dyndns.org (8.14.1/8.14.1) with ESMTP id l6P9VUCS002000; Wed, 25 Jul 2007 11:31:30 +0200 (CEST) (envelope-from matteo@freebsd.org) Received: (from rionda@localhost) by rionda.dyndns.org (8.14.1/8.14.1/Submit) id l6P9VOOA001998; Wed, 25 Jul 2007 11:31:24 +0200 (CEST) (envelope-from matteo@freebsd.org) X-Authentication-Warning: rionda.dyndns.org: rionda set sender to matteo@freebsd.org using -f Date: Wed, 25 Jul 2007 11:31:23 +0200 From: Matteo Riondato To: Andrew Thompson Message-ID: <20070725093123.GB1704@kaiser.sig11.org> Mail-Followup-To: Matteo Riondato , Andrew Thompson , Scot Hetzel , freebsd-current@freebsd.org References: <790a9fff0707150332u2502a491s91f19d4303bf82a6@mail.gmail.com> <20070715110629.GI95956@heff.fud.org.nz> <790a9fff0707181607n7500b7feo190c58418e047de5@mail.gmail.com> <20070720001043.GD45010@heff.fud.org.nz> <20070721092207.GC76674@heff.fud.org.nz> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="8GpibOaaTibBMecb" Content-Disposition: inline In-Reply-To: <20070721092207.GC76674@heff.fud.org.nz> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: Scot Hetzel , 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, 25 Jul 2007 09:31:34 -0000 --8GpibOaaTibBMecb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jul 21, 2007 at 09:22:07PM +1200, Andrew Thompson wrote: > 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. I tested it and it solved my problem.=20 Thanks for your work. 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) --8GpibOaaTibBMecb Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFGpxhr2Mp4pR7Fa+wRAu/5AJ4lDDXn8oFlSA80hW1mpNMOw0HgawCg1aNS Ggom74BSzlSI3PD9suVa0fg= =Wyaj -----END PGP SIGNATURE----- --8GpibOaaTibBMecb-- From owner-freebsd-current@FreeBSD.ORG Wed Jul 25 10:02:49 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 2AB1A16A41A for ; Wed, 25 Jul 2007 10:02:49 +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 89F7713C45A for ; Wed, 25 Jul 2007 10:02:48 +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 3F37449425 for ; Wed, 25 Jul 2007 06:02:48 -0400 (EDT) Date: Wed, 25 Jul 2007 11:02:48 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: current@FreeBSD.org Message-ID: <20070725110221.C83919@fledge.watson.org> MIME-Version: 1.0 Content-Type: MULTIPART/Mixed; BOUNDARY="0-894572789-1185272265=:83919" Content-ID: <20070725110221.D83919@fledge.watson.org> Cc: Subject: Removing NET_NEEDS_GIANT: first 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: Wed, 25 Jul 2007 10:02:49 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-894572789-1185272265=:83919 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; FORMAT=flowed Content-ID: <20070725110221.W83919@fledge.watson.org> (Resent spelling current@FreeBSD.org correctly) Dear all, Per many discussions over the past few years, we've finally reached the end of the road on non-MPSAFE network protocol components. Recently, Bjoern, George, and I resolved, in various ways, the last few remaining protocol-layer dependencies (IPSEC, i4b, IPX over IP, netatm), and there are now no Giant-dependent protocol components left. This is the result of a lot of hardware work by a great many FreeBSD developers over the past six years, and I really appreciate everyone's hard work to make this possible! Attached is the first of a series of patches to start removing the NET_NEEDS_GIANT and debug.mpsafenet scaffolding. This source code declaration was used by optionally compiled components to declare a strict requirement for Giant, and forced Giant over the entire network stack. debug.mpsafenet could also be set by users in loader.conf in order to similar force Giant over the network stack, and existed for two reasons: to allow Giant to be put back over the network stack for debugging purposes, and to support these recently removed or fixed unsafe components. As such, this patch removes the following: - NET_NEEDS_GIANT() macro - debug.mpsafenet tunable/sysctl and associated debug_mpsafenet variable, as well as functions supporting these. - Use of this variable to control acqusition of Giant in network-related interrupt handlers and various other paths. If also converts the following to no-ops, allowing them to be gradually removed in a series of follow-up patches to minimize risk and disruption: - NET_LOCK_GIANT(), NET_UNLOCK_GIANT() - NET_ASSERT_GIANT() Finally, the following conversion takes place: - NET_CALLOUT_MPSAFE is now an alias for CALLOUT_MPSAFE The patch is attached, and I would appreciate feedback on the patch and any testing. Assuming no serious negative feedback in the next couple of days, I'll request permission to commit from re@. The patches that follow will: - Replace all remaining NET_CALLOUT_MPSAFE instances with CALLOUT_MPSAFE, removing NET_CALLOUT_MPSAFE. - Removing all references to NET_{LOCK,UNLOCK,ASSERT}_GIANT. - Clean up some other weird Giant-related compatibility in the Cronyx drivers. Things this patch doesn't do: - Address the WITNESS lock order warnings generated when credential rules are used with ipfw/pf. These are believed to be annoying but non-harmful, as deadlocks are no longer reported. This view may be revised if evidence to the contrary is presented. - Remove IFF_NEEDSGIANT, a similar set of Giant-acquiring shims used to protect non-MPSAFE device drivers. I had hoped to remove this in 7.0, but I think this will happen instead for 8.0 due to remaining non-MPSAFEty in a few key network device drivers. Patch attached, and also available at this URL: http://www.watson.org/~robert/freebsd/netperf/20070724-no_net_needs_giant_1.diff Robert N M Watson Computer Laboratory University of Cambridge --0-894572789-1185272265=:83919 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME=20070724-no_net_needs_giant_1.diff Content-Transfer-Encoding: BASE64 Content-ID: <20070724111744.B83919@fledge.watson.org> Content-Description: Content-Disposition: ATTACHMENT; FILENAME=20070724-no_net_needs_giant_1.diff SW5kZXg6IGRldi9hdGgvYXRoX3JhdGUvYW1yci9hbXJyLmMNCj09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT0NClJDUyBmaWxlOiAvem9vL2N2c3VwL0ZyZWVCU0Qt Q1ZTL3NyYy9zeXMvZGV2L2F0aC9hdGhfcmF0ZS9hbXJyL2FtcnIuYyx2DQpy ZXRyaWV2aW5nIHJldmlzaW9uIDEuMTMNCmRpZmYgLXUgLXIxLjEzIGFtcnIu Yw0KLS0tIGRldi9hdGgvYXRoX3JhdGUvYW1yci9hbXJyLmMJMTEgSnVuIDIw MDcgMDM6MzY6NTAgLTAwMDAJMS4xMw0KKysrIGRldi9hdGgvYXRoX3JhdGUv YW1yci9hbXJyLmMJMTYgSnVsIDIwMDcgMDc6NDY6NDMgLTAwMDANCkBAIC01 MDQsNyArNTA0LDcgQEANCiAJaWYgKGFzYyA9PSBOVUxMKQ0KIAkJcmV0dXJu IE5VTEw7DQogCWFzYy0+YXJjLmFyY19zcGFjZSA9IHNpemVvZihzdHJ1Y3Qg YW1ycl9ub2RlKTsNCi0JY2FsbG91dF9pbml0KCZhc2MtPnRpbWVyLCBkZWJ1 Z19tcHNhZmVuZXQgPyBDQUxMT1VUX01QU0FGRSA6IDApOw0KKwljYWxsb3V0 X2luaXQoJmFzYy0+dGltZXIsIENBTExPVVRfTVBTQUZFKTsNCiAJYXRoX3Jh dGVfc3lzY3RsYXR0YWNoKHNjKTsNCiANCiAJcmV0dXJuICZhc2MtPmFyYzsN CkluZGV4OiBkZXYvYXRoL2F0aF9yYXRlL29ub2Uvb25vZS5jDQo9PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09DQpSQ1MgZmlsZTogL3pvby9jdnN1cC9GcmVlQlNE LUNWUy9zcmMvc3lzL2Rldi9hdGgvYXRoX3JhdGUvb25vZS9vbm9lLmMsdg0K cmV0cmlldmluZyByZXZpc2lvbiAxLjE0DQpkaWZmIC11IC1yMS4xNCBvbm9l LmMNCi0tLSBkZXYvYXRoL2F0aF9yYXRlL29ub2Uvb25vZS5jCTExIEp1biAy MDA3IDAzOjM2OjUwIC0wMDAwCTEuMTQNCisrKyBkZXYvYXRoL2F0aF9yYXRl L29ub2Uvb25vZS5jCTE2IEp1bCAyMDA3IDA3OjQ2OjU3IC0wMDAwDQpAQCAt NDc4LDcgKzQ3OCw3IEBADQogCWlmIChvc2MgPT0gTlVMTCkNCiAJCXJldHVy biBOVUxMOw0KIAlvc2MtPmFyYy5hcmNfc3BhY2UgPSBzaXplb2Yoc3RydWN0 IG9ub2Vfbm9kZSk7DQotCWNhbGxvdXRfaW5pdCgmb3NjLT50aW1lciwgZGVi dWdfbXBzYWZlbmV0ID8gQ0FMTE9VVF9NUFNBRkUgOiAwKTsNCisJY2FsbG91 dF9pbml0KCZvc2MtPnRpbWVyLCBDQUxMT1VUX01QU0FGRSk7DQogCWF0aF9y YXRlX3N5c2N0bGF0dGFjaChzYyk7DQogDQogCXJldHVybiAmb3NjLT5hcmM7 DQpJbmRleDogZGV2L2NlL2lmX2NlLmMNCj09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT0NClJDUyBmaWxlOiAvem9vL2N2c3VwL0ZyZWVCU0QtQ1ZTL3NyYy9zeXMv ZGV2L2NlL2lmX2NlLmMsdg0KcmV0cmlldmluZyByZXZpc2lvbiAxLjgNCmRp ZmYgLXUgLXIxLjggaWZfY2UuYw0KLS0tIGRldi9jZS9pZl9jZS5jCTI1IE1h ciAyMDA3IDIwOjIxOjMxIC0wMDAwCTEuOA0KKysrIGRldi9jZS9pZl9jZS5j CTE2IEp1bCAyMDA3IDA3OjQ3OjQ1IC0wMDAwDQpAQCAtMjYwNCwxMyArMjYw NCw2IEBADQogI2lmIF9fRnJlZUJTRF92ZXJzaW9uIDwgNTAwMDAwDQogCWRl diA9IG1ha2VkZXYgKENERVZfTUFKT1IsIDApOw0KICNlbmRpZg0KLSNpZiBf X0ZyZWVCU0RfdmVyc2lvbiA+PSA1MDExMTQNCi0JaWYgKCFkZWJ1Z19tcHNh ZmVuZXQgJiYgY2VfbXBzYWZlbmV0KSB7DQotCQlwcmludGYgKCJXT1JOSU5H ISBOZXR3b3JrIHN0YWNrIGlzIG5vdCBNUFNBRkUuICINCi0JCQkiVHVybmlu ZyBvZmYgZGVidWcuY2UubXBzYWZlbmV0LlxuIik7DQotCQljZV9tcHNhZmVu ZXQgPSAwOw0KLQl9DQotI2VuZGlmDQogI2lmIF9fRnJlZUJTRF92ZXJzaW9u ID49IDUwMjEwMw0KIAlpZiAoY2VfbXBzYWZlbmV0KQ0KIAkJY2VfY2RldnN3 LmRfZmxhZ3MgJj0gfkRfTkVFREdJQU5UOw0KSW5kZXg6IGRldi9jcC9pZl9j cC5jDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09DQpSQ1MgZmlsZTogL3pvby9j dnN1cC9GcmVlQlNELUNWUy9zcmMvc3lzL2Rldi9jcC9pZl9jcC5jLHYNCnJl dHJpZXZpbmcgcmV2aXNpb24gMS4zMw0KZGlmZiAtdSAtcjEuMzMgaWZfY3Au Yw0KLS0tIGRldi9jcC9pZl9jcC5jCTIxIE1hciAyMDA3IDAzOjM4OjM1IC0w MDAwCTEuMzMNCisrKyBkZXYvY3AvaWZfY3AuYwkxNiBKdWwgMjAwNyAwNzo0 ODowNyAtMDAwMA0KQEAgLTIyNjUsMTEgKzIyNjUsNiBAQA0KIHsNCiAJc3Rh dGljIGludCBsb2FkX2NvdW50ID0gMDsNCiANCi0JaWYgKCFkZWJ1Z19tcHNh ZmVuZXQgJiYgY3BfbXBzYWZlbmV0KSB7DQotCQlwcmludGYgKCJXT1JOSU5H ISBOZXR3b3JrIHN0YWNrIGlzIG5vdCBNUFNBRkUuICINCi0JCQkiVHVybmlu ZyBvZmYgZGVidWcuY3AubXBzYWZlbmV0LlxuIik7DQotCQljcF9tcHNhZmVu ZXQgPSAwOw0KLQl9DQogCWlmIChjcF9tcHNhZmVuZXQpDQogCQljcF9jZGV2 c3cuZF9mbGFncyAmPSB+RF9ORUVER0lBTlQ7DQogDQpJbmRleDogZGV2L2N0 YXUvaWZfY3QuYw0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KUkNTIGZpbGU6 IC96b28vY3ZzdXAvRnJlZUJTRC1DVlMvc3JjL3N5cy9kZXYvY3RhdS9pZl9j dC5jLHYNCnJldHJpZXZpbmcgcmV2aXNpb24gMS4zMw0KZGlmZiAtdSAtcjEu MzMgaWZfY3QuYw0KLS0tIGRldi9jdGF1L2lmX2N0LmMJMjEgTWFyIDIwMDcg MDM6Mzg6MzUgLTAwMDAJMS4zMw0KKysrIGRldi9jdGF1L2lmX2N0LmMJMTYg SnVsIDIwMDcgMDc6NDg6NTggLTAwMDANCkBAIC0yMjA2LDExICsyMjA2LDYg QEANCiB7DQogCXN0YXRpYyBpbnQgbG9hZF9jb3VudCA9IDA7DQogDQotCWlm ICghZGVidWdfbXBzYWZlbmV0ICYmIGN0X21wc2FmZW5ldCkgew0KLQkJcHJp bnRmICgiV09STklORyEgTmV0d29yayBzdGFjayBpcyBub3QgTVBTQUZFLiAi DQotCQkJIlR1cm5pbmcgb2ZmIGRlYnVnLmN0Lm1wc2FmZW5ldC5cbiIpOw0K LQkJY3RfbXBzYWZlbmV0ID0gMDsNCi0JfQ0KIAlpZiAoY3RfbXBzYWZlbmV0 KQ0KIAkJY3RfY2RldnN3LmRfZmxhZ3MgJj0gfkRfTkVFREdJQU5UOw0KIA0K SW5kZXg6IGRldi9jeC9pZl9jeC5jDQo9PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 DQpSQ1MgZmlsZTogL3pvby9jdnN1cC9GcmVlQlNELUNWUy9zcmMvc3lzL2Rl di9jeC9pZl9jeC5jLHYNCnJldHJpZXZpbmcgcmV2aXNpb24gMS41Ng0KZGlm ZiAtdSAtcjEuNTYgaWZfY3guYw0KLS0tIGRldi9jeC9pZl9jeC5jCTIxIE1h ciAyMDA3IDAzOjM4OjM1IC0wMDAwCTEuNTYNCisrKyBkZXYvY3gvaWZfY3gu YwkxNiBKdWwgMjAwNyAwNzo0OTowOCAtMDAwMA0KQEAgLTI1MjMsMTEgKzI1 MjMsNiBAQA0KIHsNCiAJc3RhdGljIGludCBsb2FkX2NvdW50ID0gMDsNCiAN Ci0JaWYgKCFkZWJ1Z19tcHNhZmVuZXQgJiYgY3hfbXBzYWZlbmV0KSB7DQot CQlwcmludGYgKCJXT1JOSU5HISBOZXR3b3JrIHN0YWNrIGlzIG5vdCBNUFNB RkUuICINCi0JCQkiVHVybmluZyBvZmYgZGVidWcuY3gubXBzYWZlbmV0Llxu Iik7DQotCQljeF9tcHNhZmVuZXQgPSAwOw0KLQl9DQogCWlmIChjeF9tcHNh ZmVuZXQpDQogCQljeF9jZGV2c3cuZF9mbGFncyAmPSB+RF9ORUVER0lBTlQ7 DQogDQpJbmRleDoga2Vybi9zdWJyX2J1cy5jDQo9PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09DQpSQ1MgZmlsZTogL3pvby9jdnN1cC9GcmVlQlNELUNWUy9zcmMv c3lzL2tlcm4vc3Vicl9idXMuYyx2DQpyZXRyaWV2aW5nIHJldmlzaW9uIDEu MjAwDQpkaWZmIC11IC1yMS4yMDAgc3Vicl9idXMuYw0KLS0tIGtlcm4vc3Vi cl9idXMuYwkyMyBNYXkgMjAwNyAxNzoyODoyMSAtMDAwMAkxLjIwMA0KKysr IGtlcm4vc3Vicl9idXMuYwkxNiBKdWwgMjAwNyAwNzo0NjoyNSAtMDAwMA0K QEAgLTM0NjQsOSArMzQ2NCw2IEBADQogCWludCBlcnJvcjsNCiANCiAJaWYg KGRldi0+cGFyZW50ICE9IE5VTEwpIHsNCi0JCWlmICgoZmxhZ3MgJn4gSU5U Ul9FTlRST1BZKSA9PSAoSU5UUl9UWVBFX05FVCB8IElOVFJfTVBTQUZFKSAm Jg0KLQkJICAgICFkZWJ1Z19tcHNhZmVuZXQpDQotCQkJZmxhZ3MgJj0gfklO VFJfTVBTQUZFOw0KIAkJZXJyb3IgPSBCVVNfU0VUVVBfSU5UUihkZXYtPnBh cmVudCwgZGV2LCByLCBmbGFncywNCiAJCSAgICBmaWx0ZXIsIGhhbmRsZXIs IGFyZywgY29va2llcCk7DQogCQlpZiAoZXJyb3IgPT0gMCkgew0KSW5kZXg6 IGtlcm4vdWlwY19kb21haW4uYw0KPT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0K UkNTIGZpbGU6IC96b28vY3ZzdXAvRnJlZUJTRC1DVlMvc3JjL3N5cy9rZXJu L3VpcGNfZG9tYWluLmMsdg0KcmV0cmlldmluZyByZXZpc2lvbiAxLjQ5DQpk aWZmIC11IC1yMS40OSB1aXBjX2RvbWFpbi5jDQotLS0ga2Vybi91aXBjX2Rv bWFpbi5jCTE2IE1heSAyMDA3IDIwOjQxOjA3IC0wMDAwCTEuNDkNCisrKyBr ZXJuL3VpcGNfZG9tYWluLmMJMTYgSnVsIDIwMDcgMDc6NDU6NTYgLTAwMDAN CkBAIC0yMTEsMTMgKzIxMSw4IEBADQogCWlmIChtYXhfbGlua2hkciA8IDE2 KQkJLyogWFhYICovDQogCQltYXhfbGlua2hkciA9IDE2Ow0KIA0KLQlpZiAo ZGVidWdfbXBzYWZlbmV0KSB7DQotCQljYWxsb3V0X2luaXQoJnBmZmFzdF9j YWxsb3V0LCBDQUxMT1VUX01QU0FGRSk7DQotCQljYWxsb3V0X2luaXQoJnBm c2xvd19jYWxsb3V0LCBDQUxMT1VUX01QU0FGRSk7DQotCX0gZWxzZSB7DQot CQljYWxsb3V0X2luaXQoJnBmZmFzdF9jYWxsb3V0LCAwKTsNCi0JCWNhbGxv dXRfaW5pdCgmcGZzbG93X2NhbGxvdXQsIDApOw0KLQl9DQorCWNhbGxvdXRf aW5pdCgmcGZmYXN0X2NhbGxvdXQsIENBTExPVVRfTVBTQUZFKTsNCisJY2Fs bG91dF9pbml0KCZwZnNsb3dfY2FsbG91dCwgQ0FMTE9VVF9NUFNBRkUpOw0K IA0KIAltdHhfbG9jaygmZG9tX210eCk7DQogCUtBU1NFUlQoZG9tYWluX2lu aXRfc3RhdHVzID09IDAsICgiZG9tYWluaW5pdCBjYWxsZWQgdG9vIGxhdGUh IikpOw0KSW5kZXg6IG5ldC9pZi5jDQo9PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 DQpSQ1MgZmlsZTogL3pvby9jdnN1cC9GcmVlQlNELUNWUy9zcmMvc3lzL25l dC9pZi5jLHYNCnJldHJpZXZpbmcgcmV2aXNpb24gMS4yNzINCmRpZmYgLXUg LXIxLjI3MiBpZi5jDQotLS0gbmV0L2lmLmMJMTYgTWF5IDIwMDcgMTk6NTk6 MDEgLTAwMDAJMS4yNzINCisrKyBuZXQvaWYuYwkxNiBKdWwgMjAwNyAwNzo0 MzozMiAtMDAwMA0KQEAgLTI2OTQsOSArMjY5NCw3IEBADQogaWZfc3RhcnQo c3RydWN0IGlmbmV0ICppZnApDQogew0KIA0KLQlORVRfQVNTRVJUX0dJQU5U KCk7DQotDQotCWlmICgoaWZwLT5pZl9mbGFncyAmIElGRl9ORUVEU0dJQU5U KSAhPSAwICYmIGRlYnVnX21wc2FmZW5ldCAhPSAwKSB7DQorCWlmIChpZnAt PmlmX2ZsYWdzICYgSUZGX05FRURTR0lBTlQpIHsNCiAJCWlmIChtdHhfb3du ZWQoJkdpYW50KSkNCiAJCQkoKihpZnApLT5pZl9zdGFydCkoaWZwKTsNCiAJ CWVsc2UNCkBAIC0yNzExLDExICsyNzA5LDYgQEANCiB7DQogCXN0cnVjdCBp Zm5ldCAqaWZwOw0KIA0KLQkvKg0KLQkgKiBUaGlzIGNvZGUgbXVzdCBiZSBl bnRlcmVkIHdpdGggR2lhbnQsIGFuZCBzaG91bGQgbmV2ZXIgcnVuIGlmDQot CSAqIHdlJ3JlIG5vdCBydW5uaW5nIHdpdGggZGVidWcubXBzYWZlbmV0Lg0K LQkgKi8NCi0JS0FTU0VSVChkZWJ1Z19tcHNhZmVuZXQgIT0gMCwgKCJpZl9z dGFydF9kZWZlcnJlZDogZGVidWcubXBzYWZlbmV0IikpOw0KIAlHSUFOVF9S RVFVSVJFRDsNCiANCiAJaWZwID0gY29udGV4dDsNCkluZGV4OiBuZXQvaWZf ZXRoZXJzdWJyLmMNCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NClJDUyBmaWxl OiAvem9vL2N2c3VwL0ZyZWVCU0QtQ1ZTL3NyYy9zeXMvbmV0L2lmX2V0aGVy c3Vici5jLHYNCnJldHJpZXZpbmcgcmV2aXNpb24gMS4yMzQNCmRpZmYgLXUg LXIxLjIzNCBpZl9ldGhlcnN1YnIuYw0KLS0tIG5ldC9pZl9ldGhlcnN1YnIu YwkzIEp1bCAyMDA3IDEyOjQ2OjA2IC0wMDAwCTEuMjM0DQorKysgbmV0L2lm X2V0aGVyc3Vici5jCTE2IEp1bCAyMDA3IDA3OjQ1OjQzIC0wMDAwDQpAQCAt OTIyLDcgKzkyMiw3IEBADQogCQkJYnJlYWs7IA0KIAlpZiAoaSAhPSBpZnAt PmlmX2FkZHJsZW4pDQogCQlpZl9wcmludGYoaWZwLCAiRXRoZXJuZXQgYWRk cmVzczogJTZEXG4iLCBsbGEsICI6Iik7DQotCWlmIChkZWJ1Z19tcHNhZmVu ZXQgJiYgKGlmcC0+aWZfZmxhZ3MgJiBJRkZfTkVFRFNHSUFOVCkgIT0gMCkN CisJaWYgKGlmcC0+aWZfZmxhZ3MgJiBJRkZfTkVFRFNHSUFOVCkNCiAJCWlm X3ByaW50ZihpZnAsICJpZl9zdGFydCBydW5uaW5nIGRlZmVycmVkIGZvciBH aWFudFxuIik7DQogfQ0KIA0KSW5kZXg6IG5ldC9uZXRpc3IuYw0KPT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PQ0KUkNTIGZpbGU6IC96b28vY3ZzdXAvRnJlZUJT RC1DVlMvc3JjL3N5cy9uZXQvbmV0aXNyLmMsdg0KcmV0cmlldmluZyByZXZp c2lvbiAxLjE4DQpkaWZmIC11IC1yMS4xOCBuZXRpc3IuYw0KLS0tIG5ldC9u ZXRpc3IuYwkyOCBOb3YgMjAwNiAxMToxOTozNiAtMDAwMAkxLjE4DQorKysg bmV0L25ldGlzci5jCTE2IEp1bCAyMDA3IDA3OjQwOjU3IC0wMDAwDQpAQCAt NTYsMjQgKzU2LDYgQEANCiAjaW5jbHVkZSA8bmV0L2lmX3Zhci5oPg0KICNp bmNsdWRlIDxuZXQvbmV0aXNyLmg+DQogDQotLyogDQotICogZGVidWdfbXBz YWZlbmV0IGNvbnRyb2xzIG5ldHdvcmsgc3Vic3lzdGVtLXdpZGUgdXNlIG9m IHRoZSBHaWFudCBsb2NrLA0KLSAqIGZyb20gc3lzdGVtIGNhbGxzIGRvd24g dG8gaW50ZXJydXB0IGhhbmRsZXJzLiAgSXQgY2FuIGJlIGNoYW5nZWQgb25s eSB2aWENCi0gKiBhIHR1bmFibGUgYXQgYm9vdCwgbm90IGF0IHJ1bi10aW1l LCBkdWUgdG8gdGhlIGNvbXBsZXhpdHkgb2YgdW53aW5kaW5nLg0KLSAqIFRo ZSBjb21waWxlZCBkZWZhdWx0IGlzIHNldCB2aWEgYSBrZXJuZWwgb3B0aW9u OyByaWdodCBub3csIHRoZSBkZWZhdWx0DQotICogdW5sZXNzIG90aGVyd2lz ZSBzcGVjaWZpZWQgaXMgdG8gcnVuIHRoZSBuZXR3b3JrIHN0YWNrIHdpdGhv dXQgR2lhbnQuDQotICovDQotI2lmZGVmIE5FVF9XSVRIX0dJQU5UDQotaW50 CWRlYnVnX21wc2FmZW5ldCA9IDA7DQotI2Vsc2UNCi1pbnQJZGVidWdfbXBz YWZlbmV0ID0gMTsNCi0jZW5kaWYNCi1pbnQJZGVidWdfbXBzYWZlbmV0X3Rv b2xhdGV0b3R3aWRkbGUgPSAwOw0KLQ0KLVRVTkFCTEVfSU5UKCJkZWJ1Zy5t cHNhZmVuZXQiLCAmZGVidWdfbXBzYWZlbmV0KTsNCi1TWVNDVExfSU5UKF9k ZWJ1ZywgT0lEX0FVVE8sIG1wc2FmZW5ldCwgQ1RMRkxBR19SRCwgJmRlYnVn X21wc2FmZW5ldCwgMCwNCi0gICAgIkVuYWJsZS9kaXNhYmxlIE1QU0FGRSBu ZXR3b3JrIHN1cHBvcnQiKTsNCi0NCiB2b2xhdGlsZSB1bnNpZ25lZCBpbnQJ bmV0aXNyOwkvKiBzY2hlZHVsaW5nIGJpdHMgZm9yIG5ldHdvcmsgKi8NCiAN CiBzdHJ1Y3QgbmV0aXNyIHsNCkBAIC04NCw3OCArNjYsNiBAQA0KIA0KIHN0 YXRpYyB2b2lkICpuZXRfaWg7DQogDQotLyoNCi0gKiBOb3QgYWxsIG5ldHdv cmsgY29kZSBpcyBjdXJyZW50bHkgY2FwYWJsZSBvZiBydW5uaW5nIE1QU0FG RTsgaG93ZXZlciwNCi0gKiBtb3N0IG9mIGl0IGlzLiAgU2luY2UgdGhvc2Ug c2VjdGlvbnMgdGhhdCBhcmUgbm90IGFyZSBnZW5lcmFsbHkgb3B0aW9uYWwN Ci0gKiBjb21wb25lbnRzIG5vdCBzaGlwcGVkIHdpdGggZGVmYXVsdCBrZXJu ZWxzLCB3ZSBwcm92aWRlIGEgYmFzaWMgd2F5IHRvDQotICogZGV0ZXJtaW5l IHdoZXRoZXIgTVBTQUZFIG9wZXJhdGlvbiBpcyBwZXJtaXR0ZWQ6IGJhc2Vk IG9uIGEgZGVmYXVsdCBvZg0KLSAqIHllcywgd2UgcGVybWl0IG5vbi1NUFNB RkUgY29tcG9uZW50cyB0byB1c2UgYSByZWdpc3RyYXRpb24gY2FsbCB0bw0K LSAqIGlkZW50aWZ5IHRoYXQgdGhleSByZXF1aXJlIEdpYW50LiAgSWYgdGhl IHN5c3RlbSBpcyBlYXJseSBpbiB0aGUgYm9vdA0KLSAqIHByb2Nlc3Mgc3Rp bGwsIHRoZW4gd2UgY2hhbmdlIHRoZSBkZWJ1Z19tcHNhZmVuZXQgc2V0dGlu ZyB0byBjaG9vc2UgYQ0KLSAqIG5vbi1NUFNBRkUgZXhlY3V0aW9uIG1vZGUg KGRlZ3JhZGVkKS4gIElmIGl0J3MgdG9vIGxhdGUgZm9yIHRoYXQgKHNpbmNl DQotICogdGhlIHNldHRpbmcgY2Fubm90IGJlIGNoYW5nZWQgYXQgcnVuIHRp bWUpLCB3ZSBnZW5lcmF0ZSBhIGNvbnNvbGUgd2FybmluZw0KLSAqIHRoYXQg dGhlIGNvbmZpZ3VyYXRpb24gbWF5IGJlIHVuc2FmZS4NCi0gKi8NCi1zdGF0 aWMgaW50IG1wc2FmZV93YXJuX2NvdW50Ow0KLQ0KLS8qDQotICogRnVuY3Rp b24gY2FsbCBpbXBsZW1lbnRpbmcgcmVnaXN0cmF0aW9uIG9mIGEgbm9uLU1Q U0FGRSBuZXR3b3JrIGNvbXBvbmVudC4NCi0gKi8NCi12b2lkDQotbmV0X3dh cm5fbm90X21wc2FmZShjb25zdCBjaGFyICpjb21wb25lbnQpDQotew0KLQ0K LQkvKg0KLQkgKiBJZiB3ZSdyZSBydW5uaW5nIHdpdGggR2lhbnQgb3ZlciB0 aGUgbmV0d29yayBzdGFjaywgdGhlcmUgaXMgbm8NCi0JICogcHJvYmxlbS4N Ci0JICovDQotCWlmICghZGVidWdfbXBzYWZlbmV0KQ0KLQkJcmV0dXJuOw0K LQ0KLQkvKg0KLQkgKiBJZiBpdCdzIG5vdCB0b28gbGF0ZSB0byBjaGFuZ2Ug dGhlIE1QU0FGRSBzZXR0aW5nIGZvciB0aGUgbmV0d29yaw0KLQkgKiBzdGFj aywgZG8gc28gbm93LiAgVGhpcyBlZmZlY3RpdmVseSBzdXBwcmVzc2VzIHdh cm5pbmdzIGJ5DQotCSAqIGNvbXBvbmVudHMgcmVnaXN0ZXJpbmcgbGF0ZXIu DQotCSAqLw0KLQlpZiAoIWRlYnVnX21wc2FmZW5ldF90b29sYXRldG90d2lk ZGxlKSB7DQotCQlkZWJ1Z19tcHNhZmVuZXQgPSAwOw0KLQkJcHJpbnRmKCJX QVJOSU5HOiBkZWJ1Zy5tcHNhZmVuZXQgZm9yY2VkIHRvIDAgYXMgJXMgcmVx dWlyZXMgIg0KLQkJICAgICJHaWFudFxuIiwgY29tcG9uZW50KTsNCi0JCXJl dHVybjsNCi0JfQ0KLQ0KLQkvKg0KLQkgKiBXZSBtdXN0IHJ1biB3aXRob3V0 IEdpYW50LCBzbyBnZW5lcmF0ZSBhIGNvbnNvbGUgd2FybmluZyB3aXRoIHNv bWUNCi0JICogaW5mb3JtYXRpb24gd2l0aCB3aGF0IHRvIGRvIGFib3V0IGl0 LiAgVGhlIHN5c3RlbSBtYXkgYmUgb3BlcmF0aW5nDQotCSAqIHVuc2FmZWx5 LCBob3dldmVyLg0KLQkgKi8NCi0JcHJpbnRmKCJXQVJOSU5HOiBOZXR3b3Jr IHN0YWNrIEdpYW50LWZyZWUsIGJ1dCAlcyByZXF1aXJlcyBHaWFudC5cbiIs DQotCSAgICBjb21wb25lbnQpOw0KLQlpZiAobXBzYWZlX3dhcm5fY291bnQg PT0gMCkNCi0JCXByaW50ZigiICAgIENvbnNpZGVyIGFkZGluZyAnb3B0aW9u cyBORVRfV0lUSF9HSUFOVCcgb3IgIg0KLQkJICAgICJzZXR0aW5nIGRlYnVn Lm1wc2FmZW5ldD0wXG4iKTsNCi0JbXBzYWZlX3dhcm5fY291bnQrKzsNCi19 DQotDQotLyoNCi0gKiBUaGlzIHN5c2luaXQgaXMgcnVuIGFmdGVyIGFueSBw cmUtbG9hZGVkIG9yIGNvbXBpbGVkLWluIGNvbXBvbmVudHMgaGF2ZQ0KLSAq IGFubm91bmNlZCB0aGF0IHRoZXkgcmVxdWlyZSBHaWFudCwgYnV0IGJlZm9y ZSBhbnkgbW9kdWxlcyBsb2FkZWQgYXQNCi0gKiBydW4tdGltZS4NCi0gKi8N Ci1zdGF0aWMgdm9pZA0KLW5ldF9tcHNhZmVfdG9vbGF0ZSh2b2lkICphcmcp DQotew0KLQ0KLQlkZWJ1Z19tcHNhZmVuZXRfdG9vbGF0ZXRvdHdpZGRsZSA9 IDE7DQotDQotCWlmICghZGVidWdfbXBzYWZlbmV0KQ0KLQkJcHJpbnRmKCJX QVJOSU5HOiBNUFNBRkUgbmV0d29yayBzdGFjayBkaXNhYmxlZCwgZXhwZWN0 ICINCi0JCSAgICAicmVkdWNlZCBwZXJmb3JtYW5jZS5cbiIpOw0KLX0NCi0N Ci1TWVNJTklUKG5ldF9tcHNhZmVfdG9vbGF0ZSwgU0lfU1VCX1NFVFRJTkdT LCBTSV9PUkRFUl9BTlksIG5ldF9tcHNhZmVfdG9vbGF0ZSwNCi0gICAgTlVM TCk7DQotDQogdm9pZA0KIGxlZ2FjeV9zZXRzb2Z0bmV0KHZvaWQpDQogew0K QEAgLTE3MCw4ICs4MCw2IEBADQogCSAgICAoImJhZCBpc3IgJWQiLCBudW0p KTsNCiAJbmV0aXNyc1tudW1dLm5pX2hhbmRsZXIgPSBoYW5kbGVyOw0KIAlu ZXRpc3JzW251bV0ubmlfcXVldWUgPSBpbnE7DQotCWlmICgoZmxhZ3MgJiBO RVRJU1JfTVBTQUZFKSAmJiAhZGVidWdfbXBzYWZlbmV0KQ0KLQkJZmxhZ3Mg Jj0gfk5FVElTUl9NUFNBRkU7DQogCW5ldGlzcnNbbnVtXS5uaV9mbGFncyA9 IGZsYWdzOw0KIH0NCiANCkluZGV4OiBuZnNzZXJ2ZXIvbmZzX3NydnN1YnMu Yw0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PQ0KUkNTIGZpbGU6IC96b28vY3Zz dXAvRnJlZUJTRC1DVlMvc3JjL3N5cy9uZnNzZXJ2ZXIvbmZzX3NydnN1YnMu Yyx2DQpyZXRyaWV2aW5nIHJldmlzaW9uIDEuMTQ3DQpkaWZmIC11IC1yMS4x NDcgbmZzX3NydnN1YnMuYw0KLS0tIG5mc3NlcnZlci9uZnNfc3J2c3Vicy5j CTIgQXByIDIwMDcgMTM6NTM6MjYgLTAwMDAJMS4xNDcNCisrKyBuZnNzZXJ2 ZXIvbmZzX3NydnN1YnMuYwkxNiBKdWwgMjAwNyAwNzo0NToyMCAtMDAwMA0K QEAgLTU0OSwxMCArNTQ5LDcgQEANCiAJCW5mc3J2X2luaXRjYWNoZSgpOwkv KiBJbml0IHRoZSBzZXJ2ZXIgcmVxdWVzdCBjYWNoZSAqLw0KIAkJTkZTRF9M T0NLKCk7DQogCQluZnNydl9pbml0KDApOwkJLyogSW5pdCBzZXJ2ZXIgZGF0 YSBzdHJ1Y3R1cmVzICovDQotCQlpZiAoZGVidWdfbXBzYWZlbmV0KQ0KLQkJ CWNhbGxvdXRfaW5pdCgmbmZzcnZfY2FsbG91dCwgQ0FMTE9VVF9NUFNBRkUp Ow0KLQkJZWxzZQ0KLQkJCWNhbGxvdXRfaW5pdCgmbmZzcnZfY2FsbG91dCwg MCk7DQorCQljYWxsb3V0X2luaXQoJm5mc3J2X2NhbGxvdXQsIENBTExPVVRf TVBTQUZFKTsNCiAJCU5GU0RfVU5MT0NLKCk7DQogCQluZnNydl90aW1lcigw KTsNCiANCkluZGV4OiBuZnNzZXJ2ZXIvbmZzX3N5c2NhbGxzLmMNCj09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT0NClJDUyBmaWxlOiAvem9vL2N2c3VwL0ZyZWVC U0QtQ1ZTL3NyYy9zeXMvbmZzc2VydmVyL25mc19zeXNjYWxscy5jLHYNCnJl dHJpZXZpbmcgcmV2aXNpb24gMS4xMTQNCmRpZmYgLXUgLXIxLjExNCBuZnNf c3lzY2FsbHMuYw0KLS0tIG5mc3NlcnZlci9uZnNfc3lzY2FsbHMuYwkyMiBB cHIgMjAwNyAxNTozMToyMSAtMDAwMAkxLjExNA0KKysrIG5mc3NlcnZlci9u ZnNfc3lzY2FsbHMuYwkxNiBKdWwgMjAwNyAwNzo0NTowMyAtMDAwMA0KQEAg LTU2MSwxNiArNTYxLDExIEBADQogCQkJbmZzZC0+bmZzZF9zbHAgPSBOVUxM Ow0KIAkJCW5mc3J2X3NscGRlcmVmKHNscCk7DQogCQl9DQotCQlLQVNTRVJU KCEoZGVidWdfbXBzYWZlbmV0ID09IDAgJiYgIW10eF9vd25lZCgmR2lhbnQp KSwNCi0JCSAgICAoIm5mc3N2Y19uZnNkKCk6IGRlYnVnLm1wc2FmZW5ldD0w ICYmICFHaWFudCIpKTsNCi0JCUtBU1NFUlQoIShkZWJ1Z19tcHNhZmVuZXQg PT0gMSAmJiBtdHhfb3duZWQoJkdpYW50KSksDQotCQkgICAgKCJuZnNzdmNf bmZzZCgpOiBkZWJ1Zy5tcHNhZmVuZXQ9MSAmJiBHaWFudCIpKTsNCisJCUtB U1NFUlQoIW10eF9vd25lZCgmR2lhbnQpLA0KKwkJICAgICgibmZzc3ZjX25m c2Q6IEdpYW50IHdoZW4gbG9vcCBlbmRzIikpOw0KIAl9DQogZG9uZToNCi0J S0FTU0VSVCghKGRlYnVnX21wc2FmZW5ldCA9PSAwICYmICFtdHhfb3duZWQo JkdpYW50KSksDQotCSAgICAoIm5mc3N2Y19uZnNkKCk6IGRlYnVnLm1wc2Fm ZW5ldD0wICYmICFHaWFudCIpKTsNCi0JS0FTU0VSVCghKGRlYnVnX21wc2Fm ZW5ldCA9PSAxICYmIG10eF9vd25lZCgmR2lhbnQpKSwNCi0JICAgICgibmZz c3ZjX25mc2QoKTogZGVidWcubXBzYWZlbmV0PTEgJiYgR2lhbnQiKSk7DQor CUtBU1NFUlQoIW10eF9vd25lZCgmR2lhbnQpLCAoIm5mc3N2Y19uZnNkOiBH aWFudCB3aGVuIGRvbmUiKSk7DQogCVRBSUxRX1JFTU9WRSgmbmZzZF9oZWFk LCBuZnNkLCBuZnNkX2NoYWluKTsNCiAJc3BseChzKTsNCiAJZnJlZSgoY2Fk ZHJfdCluZnNkLCBNX05GU0QpOw0KSW5kZXg6IHN5cy9rZXJuZWwuaA0KPT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PQ0KUkNTIGZpbGU6IC96b28vY3ZzdXAvRnJl ZUJTRC1DVlMvc3JjL3N5cy9zeXMva2VybmVsLmgsdg0KcmV0cmlldmluZyBy ZXZpc2lvbiAxLjEzNQ0KZGlmZiAtdSAtcjEuMTM1IGtlcm5lbC5oDQotLS0g c3lzL2tlcm5lbC5oCTkgQXByIDIwMDcgMjI6Mjk6MTMgLTAwMDAJMS4xMzUN CisrKyBzeXMva2VybmVsLmgJMjIgSnVsIDIwMDcgMTc6MzU6MjAgLTAwMDAN CkBAIC0zNDMsMTEgKzM0Myw2IEBADQogI2RlZmluZQlUVU5BQkxFX1NUUl9G RVRDSChwYXRoLCB2YXIsIHNpemUpCQkJXA0KIAlnZXRlbnZfc3RyaW5nKChw YXRoKSwgKHZhciksIChzaXplKSkNCiANCi12b2lkCW5ldF93YXJuX25vdF9t cHNhZmUoY29uc3QgY2hhciAqY29tcG9uZW50KTsNCi0jZGVmaW5lCU5FVF9O RUVEU19HSUFOVChjb21wb25lbnQpCQkJCQlcDQotCVNZU0lOSVQoX19DT05D QVQoX19uZXRfd2Fybl9ub3RfbXBzYWZlXywgX19MSU5FX18pLAkJXA0KLQkg ICAgU0lfU1VCX1NFVFRJTkdTLCBTSV9PUkRFUl9TRUNPTkQsIG5ldF93YXJu X25vdF9tcHNhZmUsIGNvbXBvbmVudCk7DQotDQogc3RydWN0IGludHJfY29u ZmlnX2hvb2sgew0KIAlUQUlMUV9FTlRSWShpbnRyX2NvbmZpZ19ob29rKSBp Y2hfbGlua3M7DQogCXZvaWQJKCppY2hfZnVuYykodm9pZCAqYXJnKTsNCklu ZGV4OiBzeXMvbXV0ZXguaA0KPT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KUkNT IGZpbGU6IC96b28vY3ZzdXAvRnJlZUJTRC1DVlMvc3JjL3N5cy9zeXMvbXV0 ZXguaCx2DQpyZXRyaWV2aW5nIHJldmlzaW9uIDEuOTgNCmRpZmYgLXUgLXIx Ljk4IG11dGV4LmgNCi0tLSBzeXMvbXV0ZXguaAkxOCBKdWwgMjAwNyAyMDo0 NjowNiAtMDAwMAkxLjk4DQorKysgc3lzL211dGV4LmgJMjAgSnVsIDIwMDcg MTE6MTE6MDQgLTAwMDANCkBAIC0zOTcsMzUgKzM5NywxOCBAQA0KIH0gd2hp bGUgKDApDQogDQogLyoNCi0gKiBOZXR3b3JrIE1QU0FGRSB0ZW1wb3Jhcnkg d29ya2Fyb3VuZHMuICBXaGVuIGRlYnVnX21wc2FmZW5ldA0KLSAqIGlzIDEg dGhlIG5ldHdvcmsgaXMgYXNzdW1lZCB0byBvcGVyYXRlIHdpdGhvdXQgR2lh bnQgb24gdGhlDQotICogaW5wdXQgcGF0aCBhbmQgcHJvdG9jb2xzIHRoYXQg cmVxdWlyZSBHaWFudCBtdXN0IGNvbGxlY3QgaXQNCi0gKiBvbiBlbnRyeS4g IFdoZW4gMCBHaWFudCBpcyBncmFiYmVkIGluIHRoZSBuZXR3b3JrIGludGVy ZmFjZQ0KLSAqIElTUidzIGFuZCBpbiB0aGUgbmV0aXNyIHBhdGggYW5kIHRo ZXJlIGlzIG5vIG5lZWQgdG8gZ3JhYg0KLSAqIHRoZSBHaWFudCBsb2NrLiAg Tm90ZSB0aGF0LCB1bmxpa2UgUElDS1VQX0dJQU5UKCkgYW5kDQotICogRFJP UF9HSUFOVCgpLCB0aGVzZSBtYWNyb3MgZGlyZWN0bHkgd3JhcCBtdXRleCBv cGVyYXRpb25zDQotICogd2l0aG91dCBzcGVjaWFsIHJlY3Vyc2lvbiBoYW5k bGluZy4NCi0gKg0KLSAqIFRoaXMgbWVjaGFuaXNtIGlzIGludGVuZGVkIGFz IHRlbXBvcmFyeSB1bnRpbCBldmVyeXRoaW5nIG9mDQotICogaW1wb3J0YW5j ZSBpcyBwcm9wZXJseSBsb2NrZWQuICBOb3RlOiB0aGUgc2VtYW50aWNzIGZv cg0KLSAqIE5FVF97TE9DSyxVTkxPQ0t9X0dJQU5UKCkgYXJlIG5vdCB0aGUg c2FtZSBhcyBEUk9QX0dJQU5UKCkNCi0gKiBhbmQgUElDS1VQX0dJQU5UKCks IGFzIHRoZXkgYXJlIHBsYWluIG11dGV4IG9wZXJhdGlvbnMNCi0gKiB3aXRo b3V0IGEgcmVjdXJzaW9uIGNvdW50ZXIuDQorICogV2l0aCB0aGUgYWR2ZW50 IG9mIGZpbmUtZ3JhaW5lZCBsb2NraW5nLCB0aGUgR2lhbnQgbG9jayBpcyBu byBsb25nZXINCisgKiByZXF1aXJlZCBhcm91bmQgdGhlIG5ldHdvcmsgc3Rh Y2suICBUaGVzZSBtYWNyb3MgZXhpc3QgZm9yIGhpc3RvcmljYWwNCisgKiBy ZWFzb25zLCBhbGxvd2luZyBjb25kaXRpb25hbCBhY3F1aXNpdGlvbiBvZiBH aWFudCBiYXNlZCBvbiBhIGRlYnVnZ2luZw0KKyAqIHNldHRpbmcsIGFuZCB3 aWxsIGJlIHJlbW92ZWQuDQogICovDQotZXh0ZXJuCWludCBkZWJ1Z19tcHNh ZmVuZXQ7CQkvKiBkZWZpbmVkIGluIG5ldC9uZXRpc3IuYyAqLw0KICNkZWZp bmUJTkVUX0xPQ0tfR0lBTlQoKSBkbyB7CQkJCQkJXA0KLQlpZiAoIWRlYnVn X21wc2FmZW5ldCkJCQkJCQlcDQotCQltdHhfbG9jaygmR2lhbnQpOwkJCQkJ XA0KIH0gd2hpbGUgKDApDQogI2RlZmluZQlORVRfVU5MT0NLX0dJQU5UKCkg ZG8gewkJCQkJCVwNCi0JaWYgKCFkZWJ1Z19tcHNhZmVuZXQpCQkJCQkJXA0K LQkJbXR4X3VubG9jaygmR2lhbnQpOwkJCQkJXA0KIH0gd2hpbGUgKDApDQog I2RlZmluZQlORVRfQVNTRVJUX0dJQU5UKCkgZG8gewkJCQkJCVwNCi0JaWYg KCFkZWJ1Z19tcHNhZmVuZXQpCQkJCQkJXA0KLQkJbXR4X2Fzc2VydCgmR2lh bnQsIE1BX09XTkVEKTsJCQkJXA0KIH0gd2hpbGUgKDApDQotI2RlZmluZQlO RVRfQ0FMTE9VVF9NUFNBRkUJKGRlYnVnX21wc2FmZW5ldCA/IENBTExPVVRf TVBTQUZFIDogMCkNCisjZGVmaW5lCU5FVF9DQUxMT1VUX01QU0FGRQlDQUxM T1VUX01QU0FGRQ0KIA0KIHN0cnVjdCBtdHhfYXJncyB7DQogCXN0cnVjdCBt dHgJKm1hX210eDsNCg== --0-894572789-1185272265=:83919-- From owner-freebsd-current@FreeBSD.ORG Wed Jul 25 10:06:41 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 03D0816A419 for ; Wed, 25 Jul 2007 10:06:41 +0000 (UTC) (envelope-from robert@fledge.watson.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id E8F4713C46B for ; Wed, 25 Jul 2007 10:06:39 +0000 (UTC) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id E54DB46F87 for ; Wed, 25 Jul 2007 05:37:05 -0400 (EDT) X-Return-Path: X-Received: from cyrus.watson.org ([unix socket]) by cyrus.watson.org (Cyrus v2.1.18) with LMTP; Tue, 24 Jul 2007 06:17:53 -0400 X-Sieve: CMU Sieve 2.2 X-Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by cyrus.watson.org (Postfix) with ESMTP id 1FCFC478C0 for ; Tue, 24 Jul 2007 06:17:52 -0400 (EDT) X-Received: from hub.freebsd.org (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 3BBFDA616; Tue, 24 Jul 2007 10:17:50 +0000 (UTC) (envelope-from owner-freebsd-arch@freebsd.org) X-Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 1720F16A47A; Tue, 24 Jul 2007 10:17:50 +0000 (UTC) (envelope-from owner-freebsd-arch@freebsd.org) X-Delivered-To: arch@FreeBSD.org X-Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CCD9616A417; Tue, 24 Jul 2007 10:17:46 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) X-Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 223AE13C45A; Tue, 24 Jul 2007 10:17:46 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) X-Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 1018C46E20; Tue, 24 Jul 2007 06:17:45 -0400 (EDT) Date: Tue, 24 Jul 2007 11:17:45 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: current@FreeBSD.og Message-ID: <20070724110908.T83919@fledge.watson.org> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-894572789-1185272265=:83919" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Sender: owner-freebsd-arch@freebsd.org Errors-To: owner-freebsd-arch@freebsd.org ReSent-Date: Wed, 25 Jul 2007 10:37:01 +0100 (BST) ReSent-From: robert ReSent-To: current@FreeBSD.org ReSent-Subject: Removing NET_NEEDS_GIANT: first patch ReSent-Message-ID: <20070725103701.I83919@fledge.watson.org> Cc: arch@FreeBSD.org, bz@FreeBSD.org, gnn@FreeBSD.org Subject: Removing NET_NEEDS_GIANT: first patch X-BeenThere: freebsd-current@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, 25 Jul 2007 10:06:41 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-894572789-1185272265=:83919 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Dear all, Per many discussions over the past few years, we've finally reached the end of the road on non-MPSAFE network protocol components. Recently, Bjoern, George, and I resolved, in various ways, the last few remaining protocol-layer dependencies (IPSEC, i4b, IPX over IP, netatm), and there are now no Giant-dependent protocol components left. This is the result of a lot of hardware work by a great many FreeBSD developers over the past six years, and I really appreciate everyone's hard work to make this possible! Attached is the first of a series of patches to start removing the NET_NEEDS_GIANT and debug.mpsafenet scaffolding. This source code declaration was used by optionally compiled components to declare a strict requirement for Giant, and forced Giant over the entire network stack. debug.mpsafenet could also be set by users in loader.conf in order to similar force Giant over the network stack, and existed for two reasons: to allow Giant to be put back over the network stack for debugging purposes, and to support these recently removed or fixed unsafe components. As such, this patch removes the following: - NET_NEEDS_GIANT() macro - debug.mpsafenet tunable/sysctl and associated debug_mpsafenet variable, as well as functions supporting these. - Use of this variable to control acqusition of Giant in network-related interrupt handlers and various other paths. If also converts the following to no-ops, allowing them to be gradually removed in a series of follow-up patches to minimize risk and disruption: - NET_LOCK_GIANT(), NET_UNLOCK_GIANT() - NET_ASSERT_GIANT() Finally, the following conversion takes place: - NET_CALLOUT_MPSAFE is now an alias for CALLOUT_MPSAFE The patch is attached, and I would appreciate feedback on the patch and any testing. Assuming no serious negative feedback in the next couple of days, I'll request permission to commit from re@. The patches that follow will: - Replace all remaining NET_CALLOUT_MPSAFE instances with CALLOUT_MPSAFE, removing NET_CALLOUT_MPSAFE. - Removing all references to NET_{LOCK,UNLOCK,ASSERT}_GIANT. - Clean up some other weird Giant-related compatibility in the Cronyx drivers. Things this patch doesn't do: - Address the WITNESS lock order warnings generated when credential rules are used with ipfw/pf. These are believed to be annoying but non-harmful, as deadlocks are no longer reported. This view may be revised if evidence to the contrary is presented. - Remove IFF_NEEDSGIANT, a similar set of Giant-acquiring shims used to protect non-MPSAFE device drivers. I had hoped to remove this in 7.0, but I think this will happen instead for 8.0 due to remaining non-MPSAFEty in a few key network device drivers. Patch attached, and also available at this URL: http://www.watson.org/~robert/freebsd/netperf/20070724-no_net_needs_giant_1.diff Robert N M Watson Computer Laboratory University of Cambridge --0-894572789-1185272265=:83919 Content-Type: TEXT/plain; charset=US-ASCII; name=20070724-no_net_needs_giant_1.diff Content-Transfer-Encoding: BASE64 Content-ID: <20070724111744.B83919@fledge.watson.org> Content-Description: Content-Disposition: attachment; filename=20070724-no_net_needs_giant_1.diff SW5kZXg6IGRldi9hdGgvYXRoX3JhdGUvYW1yci9hbXJyLmMNCj09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT0NClJDUyBmaWxlOiAvem9vL2N2c3VwL0ZyZWVCU0Qt Q1ZTL3NyYy9zeXMvZGV2L2F0aC9hdGhfcmF0ZS9hbXJyL2FtcnIuYyx2DQpy ZXRyaWV2aW5nIHJldmlzaW9uIDEuMTMNCmRpZmYgLXUgLXIxLjEzIGFtcnIu Yw0KLS0tIGRldi9hdGgvYXRoX3JhdGUvYW1yci9hbXJyLmMJMTEgSnVuIDIw MDcgMDM6MzY6NTAgLTAwMDAJMS4xMw0KKysrIGRldi9hdGgvYXRoX3JhdGUv YW1yci9hbXJyLmMJMTYgSnVsIDIwMDcgMDc6NDY6NDMgLTAwMDANCkBAIC01 MDQsNyArNTA0LDcgQEANCiAJaWYgKGFzYyA9PSBOVUxMKQ0KIAkJcmV0dXJu IE5VTEw7DQogCWFzYy0+YXJjLmFyY19zcGFjZSA9IHNpemVvZihzdHJ1Y3Qg YW1ycl9ub2RlKTsNCi0JY2FsbG91dF9pbml0KCZhc2MtPnRpbWVyLCBkZWJ1 Z19tcHNhZmVuZXQgPyBDQUxMT1VUX01QU0FGRSA6IDApOw0KKwljYWxsb3V0 X2luaXQoJmFzYy0+dGltZXIsIENBTExPVVRfTVBTQUZFKTsNCiAJYXRoX3Jh dGVfc3lzY3RsYXR0YWNoKHNjKTsNCiANCiAJcmV0dXJuICZhc2MtPmFyYzsN CkluZGV4OiBkZXYvYXRoL2F0aF9yYXRlL29ub2Uvb25vZS5jDQo9PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09DQpSQ1MgZmlsZTogL3pvby9jdnN1cC9GcmVlQlNE LUNWUy9zcmMvc3lzL2Rldi9hdGgvYXRoX3JhdGUvb25vZS9vbm9lLmMsdg0K cmV0cmlldmluZyByZXZpc2lvbiAxLjE0DQpkaWZmIC11IC1yMS4xNCBvbm9l LmMNCi0tLSBkZXYvYXRoL2F0aF9yYXRlL29ub2Uvb25vZS5jCTExIEp1biAy MDA3IDAzOjM2OjUwIC0wMDAwCTEuMTQNCisrKyBkZXYvYXRoL2F0aF9yYXRl L29ub2Uvb25vZS5jCTE2IEp1bCAyMDA3IDA3OjQ2OjU3IC0wMDAwDQpAQCAt NDc4LDcgKzQ3OCw3IEBADQogCWlmIChvc2MgPT0gTlVMTCkNCiAJCXJldHVy biBOVUxMOw0KIAlvc2MtPmFyYy5hcmNfc3BhY2UgPSBzaXplb2Yoc3RydWN0 IG9ub2Vfbm9kZSk7DQotCWNhbGxvdXRfaW5pdCgmb3NjLT50aW1lciwgZGVi dWdfbXBzYWZlbmV0ID8gQ0FMTE9VVF9NUFNBRkUgOiAwKTsNCisJY2FsbG91 dF9pbml0KCZvc2MtPnRpbWVyLCBDQUxMT1VUX01QU0FGRSk7DQogCWF0aF9y YXRlX3N5c2N0bGF0dGFjaChzYyk7DQogDQogCXJldHVybiAmb3NjLT5hcmM7 DQpJbmRleDogZGV2L2NlL2lmX2NlLmMNCj09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT0NClJDUyBmaWxlOiAvem9vL2N2c3VwL0ZyZWVCU0QtQ1ZTL3NyYy9zeXMv ZGV2L2NlL2lmX2NlLmMsdg0KcmV0cmlldmluZyByZXZpc2lvbiAxLjgNCmRp ZmYgLXUgLXIxLjggaWZfY2UuYw0KLS0tIGRldi9jZS9pZl9jZS5jCTI1IE1h ciAyMDA3IDIwOjIxOjMxIC0wMDAwCTEuOA0KKysrIGRldi9jZS9pZl9jZS5j CTE2IEp1bCAyMDA3IDA3OjQ3OjQ1IC0wMDAwDQpAQCAtMjYwNCwxMyArMjYw NCw2IEBADQogI2lmIF9fRnJlZUJTRF92ZXJzaW9uIDwgNTAwMDAwDQogCWRl diA9IG1ha2VkZXYgKENERVZfTUFKT1IsIDApOw0KICNlbmRpZg0KLSNpZiBf X0ZyZWVCU0RfdmVyc2lvbiA+PSA1MDExMTQNCi0JaWYgKCFkZWJ1Z19tcHNh ZmVuZXQgJiYgY2VfbXBzYWZlbmV0KSB7DQotCQlwcmludGYgKCJXT1JOSU5H ISBOZXR3b3JrIHN0YWNrIGlzIG5vdCBNUFNBRkUuICINCi0JCQkiVHVybmlu ZyBvZmYgZGVidWcuY2UubXBzYWZlbmV0LlxuIik7DQotCQljZV9tcHNhZmVu ZXQgPSAwOw0KLQl9DQotI2VuZGlmDQogI2lmIF9fRnJlZUJTRF92ZXJzaW9u ID49IDUwMjEwMw0KIAlpZiAoY2VfbXBzYWZlbmV0KQ0KIAkJY2VfY2RldnN3 LmRfZmxhZ3MgJj0gfkRfTkVFREdJQU5UOw0KSW5kZXg6IGRldi9jcC9pZl9j cC5jDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09DQpSQ1MgZmlsZTogL3pvby9j dnN1cC9GcmVlQlNELUNWUy9zcmMvc3lzL2Rldi9jcC9pZl9jcC5jLHYNCnJl dHJpZXZpbmcgcmV2aXNpb24gMS4zMw0KZGlmZiAtdSAtcjEuMzMgaWZfY3Au Yw0KLS0tIGRldi9jcC9pZl9jcC5jCTIxIE1hciAyMDA3IDAzOjM4OjM1IC0w MDAwCTEuMzMNCisrKyBkZXYvY3AvaWZfY3AuYwkxNiBKdWwgMjAwNyAwNzo0 ODowNyAtMDAwMA0KQEAgLTIyNjUsMTEgKzIyNjUsNiBAQA0KIHsNCiAJc3Rh dGljIGludCBsb2FkX2NvdW50ID0gMDsNCiANCi0JaWYgKCFkZWJ1Z19tcHNh ZmVuZXQgJiYgY3BfbXBzYWZlbmV0KSB7DQotCQlwcmludGYgKCJXT1JOSU5H ISBOZXR3b3JrIHN0YWNrIGlzIG5vdCBNUFNBRkUuICINCi0JCQkiVHVybmlu ZyBvZmYgZGVidWcuY3AubXBzYWZlbmV0LlxuIik7DQotCQljcF9tcHNhZmVu ZXQgPSAwOw0KLQl9DQogCWlmIChjcF9tcHNhZmVuZXQpDQogCQljcF9jZGV2 c3cuZF9mbGFncyAmPSB+RF9ORUVER0lBTlQ7DQogDQpJbmRleDogZGV2L2N0 YXUvaWZfY3QuYw0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KUkNTIGZpbGU6 IC96b28vY3ZzdXAvRnJlZUJTRC1DVlMvc3JjL3N5cy9kZXYvY3RhdS9pZl9j dC5jLHYNCnJldHJpZXZpbmcgcmV2aXNpb24gMS4zMw0KZGlmZiAtdSAtcjEu MzMgaWZfY3QuYw0KLS0tIGRldi9jdGF1L2lmX2N0LmMJMjEgTWFyIDIwMDcg MDM6Mzg6MzUgLTAwMDAJMS4zMw0KKysrIGRldi9jdGF1L2lmX2N0LmMJMTYg SnVsIDIwMDcgMDc6NDg6NTggLTAwMDANCkBAIC0yMjA2LDExICsyMjA2LDYg QEANCiB7DQogCXN0YXRpYyBpbnQgbG9hZF9jb3VudCA9IDA7DQogDQotCWlm ICghZGVidWdfbXBzYWZlbmV0ICYmIGN0X21wc2FmZW5ldCkgew0KLQkJcHJp bnRmICgiV09STklORyEgTmV0d29yayBzdGFjayBpcyBub3QgTVBTQUZFLiAi DQotCQkJIlR1cm5pbmcgb2ZmIGRlYnVnLmN0Lm1wc2FmZW5ldC5cbiIpOw0K LQkJY3RfbXBzYWZlbmV0ID0gMDsNCi0JfQ0KIAlpZiAoY3RfbXBzYWZlbmV0 KQ0KIAkJY3RfY2RldnN3LmRfZmxhZ3MgJj0gfkRfTkVFREdJQU5UOw0KIA0K SW5kZXg6IGRldi9jeC9pZl9jeC5jDQo9PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 DQpSQ1MgZmlsZTogL3pvby9jdnN1cC9GcmVlQlNELUNWUy9zcmMvc3lzL2Rl di9jeC9pZl9jeC5jLHYNCnJldHJpZXZpbmcgcmV2aXNpb24gMS41Ng0KZGlm ZiAtdSAtcjEuNTYgaWZfY3guYw0KLS0tIGRldi9jeC9pZl9jeC5jCTIxIE1h ciAyMDA3IDAzOjM4OjM1IC0wMDAwCTEuNTYNCisrKyBkZXYvY3gvaWZfY3gu YwkxNiBKdWwgMjAwNyAwNzo0OTowOCAtMDAwMA0KQEAgLTI1MjMsMTEgKzI1 MjMsNiBAQA0KIHsNCiAJc3RhdGljIGludCBsb2FkX2NvdW50ID0gMDsNCiAN Ci0JaWYgKCFkZWJ1Z19tcHNhZmVuZXQgJiYgY3hfbXBzYWZlbmV0KSB7DQot CQlwcmludGYgKCJXT1JOSU5HISBOZXR3b3JrIHN0YWNrIGlzIG5vdCBNUFNB RkUuICINCi0JCQkiVHVybmluZyBvZmYgZGVidWcuY3gubXBzYWZlbmV0Llxu Iik7DQotCQljeF9tcHNhZmVuZXQgPSAwOw0KLQl9DQogCWlmIChjeF9tcHNh ZmVuZXQpDQogCQljeF9jZGV2c3cuZF9mbGFncyAmPSB+RF9ORUVER0lBTlQ7 DQogDQpJbmRleDoga2Vybi9zdWJyX2J1cy5jDQo9PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09DQpSQ1MgZmlsZTogL3pvby9jdnN1cC9GcmVlQlNELUNWUy9zcmMv c3lzL2tlcm4vc3Vicl9idXMuYyx2DQpyZXRyaWV2aW5nIHJldmlzaW9uIDEu MjAwDQpkaWZmIC11IC1yMS4yMDAgc3Vicl9idXMuYw0KLS0tIGtlcm4vc3Vi cl9idXMuYwkyMyBNYXkgMjAwNyAxNzoyODoyMSAtMDAwMAkxLjIwMA0KKysr IGtlcm4vc3Vicl9idXMuYwkxNiBKdWwgMjAwNyAwNzo0NjoyNSAtMDAwMA0K QEAgLTM0NjQsOSArMzQ2NCw2IEBADQogCWludCBlcnJvcjsNCiANCiAJaWYg KGRldi0+cGFyZW50ICE9IE5VTEwpIHsNCi0JCWlmICgoZmxhZ3MgJn4gSU5U Ul9FTlRST1BZKSA9PSAoSU5UUl9UWVBFX05FVCB8IElOVFJfTVBTQUZFKSAm Jg0KLQkJICAgICFkZWJ1Z19tcHNhZmVuZXQpDQotCQkJZmxhZ3MgJj0gfklO VFJfTVBTQUZFOw0KIAkJZXJyb3IgPSBCVVNfU0VUVVBfSU5UUihkZXYtPnBh cmVudCwgZGV2LCByLCBmbGFncywNCiAJCSAgICBmaWx0ZXIsIGhhbmRsZXIs IGFyZywgY29va2llcCk7DQogCQlpZiAoZXJyb3IgPT0gMCkgew0KSW5kZXg6 IGtlcm4vdWlwY19kb21haW4uYw0KPT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0K UkNTIGZpbGU6IC96b28vY3ZzdXAvRnJlZUJTRC1DVlMvc3JjL3N5cy9rZXJu L3VpcGNfZG9tYWluLmMsdg0KcmV0cmlldmluZyByZXZpc2lvbiAxLjQ5DQpk aWZmIC11IC1yMS40OSB1aXBjX2RvbWFpbi5jDQotLS0ga2Vybi91aXBjX2Rv bWFpbi5jCTE2IE1heSAyMDA3IDIwOjQxOjA3IC0wMDAwCTEuNDkNCisrKyBr ZXJuL3VpcGNfZG9tYWluLmMJMTYgSnVsIDIwMDcgMDc6NDU6NTYgLTAwMDAN CkBAIC0yMTEsMTMgKzIxMSw4IEBADQogCWlmIChtYXhfbGlua2hkciA8IDE2 KQkJLyogWFhYICovDQogCQltYXhfbGlua2hkciA9IDE2Ow0KIA0KLQlpZiAo ZGVidWdfbXBzYWZlbmV0KSB7DQotCQljYWxsb3V0X2luaXQoJnBmZmFzdF9j YWxsb3V0LCBDQUxMT1VUX01QU0FGRSk7DQotCQljYWxsb3V0X2luaXQoJnBm c2xvd19jYWxsb3V0LCBDQUxMT1VUX01QU0FGRSk7DQotCX0gZWxzZSB7DQot CQljYWxsb3V0X2luaXQoJnBmZmFzdF9jYWxsb3V0LCAwKTsNCi0JCWNhbGxv dXRfaW5pdCgmcGZzbG93X2NhbGxvdXQsIDApOw0KLQl9DQorCWNhbGxvdXRf aW5pdCgmcGZmYXN0X2NhbGxvdXQsIENBTExPVVRfTVBTQUZFKTsNCisJY2Fs bG91dF9pbml0KCZwZnNsb3dfY2FsbG91dCwgQ0FMTE9VVF9NUFNBRkUpOw0K IA0KIAltdHhfbG9jaygmZG9tX210eCk7DQogCUtBU1NFUlQoZG9tYWluX2lu aXRfc3RhdHVzID09IDAsICgiZG9tYWluaW5pdCBjYWxsZWQgdG9vIGxhdGUh IikpOw0KSW5kZXg6IG5ldC9pZi5jDQo9PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 DQpSQ1MgZmlsZTogL3pvby9jdnN1cC9GcmVlQlNELUNWUy9zcmMvc3lzL25l dC9pZi5jLHYNCnJldHJpZXZpbmcgcmV2aXNpb24gMS4yNzINCmRpZmYgLXUg LXIxLjI3MiBpZi5jDQotLS0gbmV0L2lmLmMJMTYgTWF5IDIwMDcgMTk6NTk6 MDEgLTAwMDAJMS4yNzINCisrKyBuZXQvaWYuYwkxNiBKdWwgMjAwNyAwNzo0 MzozMiAtMDAwMA0KQEAgLTI2OTQsOSArMjY5NCw3IEBADQogaWZfc3RhcnQo c3RydWN0IGlmbmV0ICppZnApDQogew0KIA0KLQlORVRfQVNTRVJUX0dJQU5U KCk7DQotDQotCWlmICgoaWZwLT5pZl9mbGFncyAmIElGRl9ORUVEU0dJQU5U KSAhPSAwICYmIGRlYnVnX21wc2FmZW5ldCAhPSAwKSB7DQorCWlmIChpZnAt PmlmX2ZsYWdzICYgSUZGX05FRURTR0lBTlQpIHsNCiAJCWlmIChtdHhfb3du ZWQoJkdpYW50KSkNCiAJCQkoKihpZnApLT5pZl9zdGFydCkoaWZwKTsNCiAJ CWVsc2UNCkBAIC0yNzExLDExICsyNzA5LDYgQEANCiB7DQogCXN0cnVjdCBp Zm5ldCAqaWZwOw0KIA0KLQkvKg0KLQkgKiBUaGlzIGNvZGUgbXVzdCBiZSBl bnRlcmVkIHdpdGggR2lhbnQsIGFuZCBzaG91bGQgbmV2ZXIgcnVuIGlmDQot CSAqIHdlJ3JlIG5vdCBydW5uaW5nIHdpdGggZGVidWcubXBzYWZlbmV0Lg0K LQkgKi8NCi0JS0FTU0VSVChkZWJ1Z19tcHNhZmVuZXQgIT0gMCwgKCJpZl9z dGFydF9kZWZlcnJlZDogZGVidWcubXBzYWZlbmV0IikpOw0KIAlHSUFOVF9S RVFVSVJFRDsNCiANCiAJaWZwID0gY29udGV4dDsNCkluZGV4OiBuZXQvaWZf ZXRoZXJzdWJyLmMNCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NClJDUyBmaWxl OiAvem9vL2N2c3VwL0ZyZWVCU0QtQ1ZTL3NyYy9zeXMvbmV0L2lmX2V0aGVy c3Vici5jLHYNCnJldHJpZXZpbmcgcmV2aXNpb24gMS4yMzQNCmRpZmYgLXUg LXIxLjIzNCBpZl9ldGhlcnN1YnIuYw0KLS0tIG5ldC9pZl9ldGhlcnN1YnIu YwkzIEp1bCAyMDA3IDEyOjQ2OjA2IC0wMDAwCTEuMjM0DQorKysgbmV0L2lm X2V0aGVyc3Vici5jCTE2IEp1bCAyMDA3IDA3OjQ1OjQzIC0wMDAwDQpAQCAt OTIyLDcgKzkyMiw3IEBADQogCQkJYnJlYWs7IA0KIAlpZiAoaSAhPSBpZnAt PmlmX2FkZHJsZW4pDQogCQlpZl9wcmludGYoaWZwLCAiRXRoZXJuZXQgYWRk cmVzczogJTZEXG4iLCBsbGEsICI6Iik7DQotCWlmIChkZWJ1Z19tcHNhZmVu ZXQgJiYgKGlmcC0+aWZfZmxhZ3MgJiBJRkZfTkVFRFNHSUFOVCkgIT0gMCkN CisJaWYgKGlmcC0+aWZfZmxhZ3MgJiBJRkZfTkVFRFNHSUFOVCkNCiAJCWlm X3ByaW50ZihpZnAsICJpZl9zdGFydCBydW5uaW5nIGRlZmVycmVkIGZvciBH aWFudFxuIik7DQogfQ0KIA0KSW5kZXg6IG5ldC9uZXRpc3IuYw0KPT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PQ0KUkNTIGZpbGU6IC96b28vY3ZzdXAvRnJlZUJT RC1DVlMvc3JjL3N5cy9uZXQvbmV0aXNyLmMsdg0KcmV0cmlldmluZyByZXZp c2lvbiAxLjE4DQpkaWZmIC11IC1yMS4xOCBuZXRpc3IuYw0KLS0tIG5ldC9u ZXRpc3IuYwkyOCBOb3YgMjAwNiAxMToxOTozNiAtMDAwMAkxLjE4DQorKysg bmV0L25ldGlzci5jCTE2IEp1bCAyMDA3IDA3OjQwOjU3IC0wMDAwDQpAQCAt NTYsMjQgKzU2LDYgQEANCiAjaW5jbHVkZSA8bmV0L2lmX3Zhci5oPg0KICNp bmNsdWRlIDxuZXQvbmV0aXNyLmg+DQogDQotLyogDQotICogZGVidWdfbXBz YWZlbmV0IGNvbnRyb2xzIG5ldHdvcmsgc3Vic3lzdGVtLXdpZGUgdXNlIG9m IHRoZSBHaWFudCBsb2NrLA0KLSAqIGZyb20gc3lzdGVtIGNhbGxzIGRvd24g dG8gaW50ZXJydXB0IGhhbmRsZXJzLiAgSXQgY2FuIGJlIGNoYW5nZWQgb25s eSB2aWENCi0gKiBhIHR1bmFibGUgYXQgYm9vdCwgbm90IGF0IHJ1bi10aW1l LCBkdWUgdG8gdGhlIGNvbXBsZXhpdHkgb2YgdW53aW5kaW5nLg0KLSAqIFRo ZSBjb21waWxlZCBkZWZhdWx0IGlzIHNldCB2aWEgYSBrZXJuZWwgb3B0aW9u OyByaWdodCBub3csIHRoZSBkZWZhdWx0DQotICogdW5sZXNzIG90aGVyd2lz ZSBzcGVjaWZpZWQgaXMgdG8gcnVuIHRoZSBuZXR3b3JrIHN0YWNrIHdpdGhv dXQgR2lhbnQuDQotICovDQotI2lmZGVmIE5FVF9XSVRIX0dJQU5UDQotaW50 CWRlYnVnX21wc2FmZW5ldCA9IDA7DQotI2Vsc2UNCi1pbnQJZGVidWdfbXBz YWZlbmV0ID0gMTsNCi0jZW5kaWYNCi1pbnQJZGVidWdfbXBzYWZlbmV0X3Rv b2xhdGV0b3R3aWRkbGUgPSAwOw0KLQ0KLVRVTkFCTEVfSU5UKCJkZWJ1Zy5t cHNhZmVuZXQiLCAmZGVidWdfbXBzYWZlbmV0KTsNCi1TWVNDVExfSU5UKF9k ZWJ1ZywgT0lEX0FVVE8sIG1wc2FmZW5ldCwgQ1RMRkxBR19SRCwgJmRlYnVn X21wc2FmZW5ldCwgMCwNCi0gICAgIkVuYWJsZS9kaXNhYmxlIE1QU0FGRSBu ZXR3b3JrIHN1cHBvcnQiKTsNCi0NCiB2b2xhdGlsZSB1bnNpZ25lZCBpbnQJ bmV0aXNyOwkvKiBzY2hlZHVsaW5nIGJpdHMgZm9yIG5ldHdvcmsgKi8NCiAN CiBzdHJ1Y3QgbmV0aXNyIHsNCkBAIC04NCw3OCArNjYsNiBAQA0KIA0KIHN0 YXRpYyB2b2lkICpuZXRfaWg7DQogDQotLyoNCi0gKiBOb3QgYWxsIG5ldHdv cmsgY29kZSBpcyBjdXJyZW50bHkgY2FwYWJsZSBvZiBydW5uaW5nIE1QU0FG RTsgaG93ZXZlciwNCi0gKiBtb3N0IG9mIGl0IGlzLiAgU2luY2UgdGhvc2Ug c2VjdGlvbnMgdGhhdCBhcmUgbm90IGFyZSBnZW5lcmFsbHkgb3B0aW9uYWwN Ci0gKiBjb21wb25lbnRzIG5vdCBzaGlwcGVkIHdpdGggZGVmYXVsdCBrZXJu ZWxzLCB3ZSBwcm92aWRlIGEgYmFzaWMgd2F5IHRvDQotICogZGV0ZXJtaW5l IHdoZXRoZXIgTVBTQUZFIG9wZXJhdGlvbiBpcyBwZXJtaXR0ZWQ6IGJhc2Vk IG9uIGEgZGVmYXVsdCBvZg0KLSAqIHllcywgd2UgcGVybWl0IG5vbi1NUFNB RkUgY29tcG9uZW50cyB0byB1c2UgYSByZWdpc3RyYXRpb24gY2FsbCB0bw0K LSAqIGlkZW50aWZ5IHRoYXQgdGhleSByZXF1aXJlIEdpYW50LiAgSWYgdGhl IHN5c3RlbSBpcyBlYXJseSBpbiB0aGUgYm9vdA0KLSAqIHByb2Nlc3Mgc3Rp bGwsIHRoZW4gd2UgY2hhbmdlIHRoZSBkZWJ1Z19tcHNhZmVuZXQgc2V0dGlu ZyB0byBjaG9vc2UgYQ0KLSAqIG5vbi1NUFNBRkUgZXhlY3V0aW9uIG1vZGUg KGRlZ3JhZGVkKS4gIElmIGl0J3MgdG9vIGxhdGUgZm9yIHRoYXQgKHNpbmNl DQotICogdGhlIHNldHRpbmcgY2Fubm90IGJlIGNoYW5nZWQgYXQgcnVuIHRp bWUpLCB3ZSBnZW5lcmF0ZSBhIGNvbnNvbGUgd2FybmluZw0KLSAqIHRoYXQg dGhlIGNvbmZpZ3VyYXRpb24gbWF5IGJlIHVuc2FmZS4NCi0gKi8NCi1zdGF0 aWMgaW50IG1wc2FmZV93YXJuX2NvdW50Ow0KLQ0KLS8qDQotICogRnVuY3Rp b24gY2FsbCBpbXBsZW1lbnRpbmcgcmVnaXN0cmF0aW9uIG9mIGEgbm9uLU1Q U0FGRSBuZXR3b3JrIGNvbXBvbmVudC4NCi0gKi8NCi12b2lkDQotbmV0X3dh cm5fbm90X21wc2FmZShjb25zdCBjaGFyICpjb21wb25lbnQpDQotew0KLQ0K LQkvKg0KLQkgKiBJZiB3ZSdyZSBydW5uaW5nIHdpdGggR2lhbnQgb3ZlciB0 aGUgbmV0d29yayBzdGFjaywgdGhlcmUgaXMgbm8NCi0JICogcHJvYmxlbS4N Ci0JICovDQotCWlmICghZGVidWdfbXBzYWZlbmV0KQ0KLQkJcmV0dXJuOw0K LQ0KLQkvKg0KLQkgKiBJZiBpdCdzIG5vdCB0b28gbGF0ZSB0byBjaGFuZ2Ug dGhlIE1QU0FGRSBzZXR0aW5nIGZvciB0aGUgbmV0d29yaw0KLQkgKiBzdGFj aywgZG8gc28gbm93LiAgVGhpcyBlZmZlY3RpdmVseSBzdXBwcmVzc2VzIHdh cm5pbmdzIGJ5DQotCSAqIGNvbXBvbmVudHMgcmVnaXN0ZXJpbmcgbGF0ZXIu DQotCSAqLw0KLQlpZiAoIWRlYnVnX21wc2FmZW5ldF90b29sYXRldG90d2lk ZGxlKSB7DQotCQlkZWJ1Z19tcHNhZmVuZXQgPSAwOw0KLQkJcHJpbnRmKCJX QVJOSU5HOiBkZWJ1Zy5tcHNhZmVuZXQgZm9yY2VkIHRvIDAgYXMgJXMgcmVx dWlyZXMgIg0KLQkJICAgICJHaWFudFxuIiwgY29tcG9uZW50KTsNCi0JCXJl dHVybjsNCi0JfQ0KLQ0KLQkvKg0KLQkgKiBXZSBtdXN0IHJ1biB3aXRob3V0 IEdpYW50LCBzbyBnZW5lcmF0ZSBhIGNvbnNvbGUgd2FybmluZyB3aXRoIHNv bWUNCi0JICogaW5mb3JtYXRpb24gd2l0aCB3aGF0IHRvIGRvIGFib3V0IGl0 LiAgVGhlIHN5c3RlbSBtYXkgYmUgb3BlcmF0aW5nDQotCSAqIHVuc2FmZWx5 LCBob3dldmVyLg0KLQkgKi8NCi0JcHJpbnRmKCJXQVJOSU5HOiBOZXR3b3Jr IHN0YWNrIEdpYW50LWZyZWUsIGJ1dCAlcyByZXF1aXJlcyBHaWFudC5cbiIs DQotCSAgICBjb21wb25lbnQpOw0KLQlpZiAobXBzYWZlX3dhcm5fY291bnQg PT0gMCkNCi0JCXByaW50ZigiICAgIENvbnNpZGVyIGFkZGluZyAnb3B0aW9u cyBORVRfV0lUSF9HSUFOVCcgb3IgIg0KLQkJICAgICJzZXR0aW5nIGRlYnVn Lm1wc2FmZW5ldD0wXG4iKTsNCi0JbXBzYWZlX3dhcm5fY291bnQrKzsNCi19 DQotDQotLyoNCi0gKiBUaGlzIHN5c2luaXQgaXMgcnVuIGFmdGVyIGFueSBw cmUtbG9hZGVkIG9yIGNvbXBpbGVkLWluIGNvbXBvbmVudHMgaGF2ZQ0KLSAq IGFubm91bmNlZCB0aGF0IHRoZXkgcmVxdWlyZSBHaWFudCwgYnV0IGJlZm9y ZSBhbnkgbW9kdWxlcyBsb2FkZWQgYXQNCi0gKiBydW4tdGltZS4NCi0gKi8N Ci1zdGF0aWMgdm9pZA0KLW5ldF9tcHNhZmVfdG9vbGF0ZSh2b2lkICphcmcp DQotew0KLQ0KLQlkZWJ1Z19tcHNhZmVuZXRfdG9vbGF0ZXRvdHdpZGRsZSA9 IDE7DQotDQotCWlmICghZGVidWdfbXBzYWZlbmV0KQ0KLQkJcHJpbnRmKCJX QVJOSU5HOiBNUFNBRkUgbmV0d29yayBzdGFjayBkaXNhYmxlZCwgZXhwZWN0 ICINCi0JCSAgICAicmVkdWNlZCBwZXJmb3JtYW5jZS5cbiIpOw0KLX0NCi0N Ci1TWVNJTklUKG5ldF9tcHNhZmVfdG9vbGF0ZSwgU0lfU1VCX1NFVFRJTkdT LCBTSV9PUkRFUl9BTlksIG5ldF9tcHNhZmVfdG9vbGF0ZSwNCi0gICAgTlVM TCk7DQotDQogdm9pZA0KIGxlZ2FjeV9zZXRzb2Z0bmV0KHZvaWQpDQogew0K QEAgLTE3MCw4ICs4MCw2IEBADQogCSAgICAoImJhZCBpc3IgJWQiLCBudW0p KTsNCiAJbmV0aXNyc1tudW1dLm5pX2hhbmRsZXIgPSBoYW5kbGVyOw0KIAlu ZXRpc3JzW251bV0ubmlfcXVldWUgPSBpbnE7DQotCWlmICgoZmxhZ3MgJiBO RVRJU1JfTVBTQUZFKSAmJiAhZGVidWdfbXBzYWZlbmV0KQ0KLQkJZmxhZ3Mg Jj0gfk5FVElTUl9NUFNBRkU7DQogCW5ldGlzcnNbbnVtXS5uaV9mbGFncyA9 IGZsYWdzOw0KIH0NCiANCkluZGV4OiBuZnNzZXJ2ZXIvbmZzX3NydnN1YnMu Yw0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PQ0KUkNTIGZpbGU6IC96b28vY3Zz dXAvRnJlZUJTRC1DVlMvc3JjL3N5cy9uZnNzZXJ2ZXIvbmZzX3NydnN1YnMu Yyx2DQpyZXRyaWV2aW5nIHJldmlzaW9uIDEuMTQ3DQpkaWZmIC11IC1yMS4x NDcgbmZzX3NydnN1YnMuYw0KLS0tIG5mc3NlcnZlci9uZnNfc3J2c3Vicy5j CTIgQXByIDIwMDcgMTM6NTM6MjYgLTAwMDAJMS4xNDcNCisrKyBuZnNzZXJ2 ZXIvbmZzX3NydnN1YnMuYwkxNiBKdWwgMjAwNyAwNzo0NToyMCAtMDAwMA0K QEAgLTU0OSwxMCArNTQ5LDcgQEANCiAJCW5mc3J2X2luaXRjYWNoZSgpOwkv KiBJbml0IHRoZSBzZXJ2ZXIgcmVxdWVzdCBjYWNoZSAqLw0KIAkJTkZTRF9M T0NLKCk7DQogCQluZnNydl9pbml0KDApOwkJLyogSW5pdCBzZXJ2ZXIgZGF0 YSBzdHJ1Y3R1cmVzICovDQotCQlpZiAoZGVidWdfbXBzYWZlbmV0KQ0KLQkJ CWNhbGxvdXRfaW5pdCgmbmZzcnZfY2FsbG91dCwgQ0FMTE9VVF9NUFNBRkUp Ow0KLQkJZWxzZQ0KLQkJCWNhbGxvdXRfaW5pdCgmbmZzcnZfY2FsbG91dCwg MCk7DQorCQljYWxsb3V0X2luaXQoJm5mc3J2X2NhbGxvdXQsIENBTExPVVRf TVBTQUZFKTsNCiAJCU5GU0RfVU5MT0NLKCk7DQogCQluZnNydl90aW1lcigw KTsNCiANCkluZGV4OiBuZnNzZXJ2ZXIvbmZzX3N5c2NhbGxzLmMNCj09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT0NClJDUyBmaWxlOiAvem9vL2N2c3VwL0ZyZWVC U0QtQ1ZTL3NyYy9zeXMvbmZzc2VydmVyL25mc19zeXNjYWxscy5jLHYNCnJl dHJpZXZpbmcgcmV2aXNpb24gMS4xMTQNCmRpZmYgLXUgLXIxLjExNCBuZnNf c3lzY2FsbHMuYw0KLS0tIG5mc3NlcnZlci9uZnNfc3lzY2FsbHMuYwkyMiBB cHIgMjAwNyAxNTozMToyMSAtMDAwMAkxLjExNA0KKysrIG5mc3NlcnZlci9u ZnNfc3lzY2FsbHMuYwkxNiBKdWwgMjAwNyAwNzo0NTowMyAtMDAwMA0KQEAg LTU2MSwxNiArNTYxLDExIEBADQogCQkJbmZzZC0+bmZzZF9zbHAgPSBOVUxM Ow0KIAkJCW5mc3J2X3NscGRlcmVmKHNscCk7DQogCQl9DQotCQlLQVNTRVJU KCEoZGVidWdfbXBzYWZlbmV0ID09IDAgJiYgIW10eF9vd25lZCgmR2lhbnQp KSwNCi0JCSAgICAoIm5mc3N2Y19uZnNkKCk6IGRlYnVnLm1wc2FmZW5ldD0w ICYmICFHaWFudCIpKTsNCi0JCUtBU1NFUlQoIShkZWJ1Z19tcHNhZmVuZXQg PT0gMSAmJiBtdHhfb3duZWQoJkdpYW50KSksDQotCQkgICAgKCJuZnNzdmNf bmZzZCgpOiBkZWJ1Zy5tcHNhZmVuZXQ9MSAmJiBHaWFudCIpKTsNCisJCUtB U1NFUlQoIW10eF9vd25lZCgmR2lhbnQpLA0KKwkJICAgICgibmZzc3ZjX25m c2Q6IEdpYW50IHdoZW4gbG9vcCBlbmRzIikpOw0KIAl9DQogZG9uZToNCi0J S0FTU0VSVCghKGRlYnVnX21wc2FmZW5ldCA9PSAwICYmICFtdHhfb3duZWQo JkdpYW50KSksDQotCSAgICAoIm5mc3N2Y19uZnNkKCk6IGRlYnVnLm1wc2Fm ZW5ldD0wICYmICFHaWFudCIpKTsNCi0JS0FTU0VSVCghKGRlYnVnX21wc2Fm ZW5ldCA9PSAxICYmIG10eF9vd25lZCgmR2lhbnQpKSwNCi0JICAgICgibmZz c3ZjX25mc2QoKTogZGVidWcubXBzYWZlbmV0PTEgJiYgR2lhbnQiKSk7DQor CUtBU1NFUlQoIW10eF9vd25lZCgmR2lhbnQpLCAoIm5mc3N2Y19uZnNkOiBH aWFudCB3aGVuIGRvbmUiKSk7DQogCVRBSUxRX1JFTU9WRSgmbmZzZF9oZWFk LCBuZnNkLCBuZnNkX2NoYWluKTsNCiAJc3BseChzKTsNCiAJZnJlZSgoY2Fk ZHJfdCluZnNkLCBNX05GU0QpOw0KSW5kZXg6IHN5cy9rZXJuZWwuaA0KPT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PQ0KUkNTIGZpbGU6IC96b28vY3ZzdXAvRnJl ZUJTRC1DVlMvc3JjL3N5cy9zeXMva2VybmVsLmgsdg0KcmV0cmlldmluZyBy ZXZpc2lvbiAxLjEzNQ0KZGlmZiAtdSAtcjEuMTM1IGtlcm5lbC5oDQotLS0g c3lzL2tlcm5lbC5oCTkgQXByIDIwMDcgMjI6Mjk6MTMgLTAwMDAJMS4xMzUN CisrKyBzeXMva2VybmVsLmgJMjIgSnVsIDIwMDcgMTc6MzU6MjAgLTAwMDAN CkBAIC0zNDMsMTEgKzM0Myw2IEBADQogI2RlZmluZQlUVU5BQkxFX1NUUl9G RVRDSChwYXRoLCB2YXIsIHNpemUpCQkJXA0KIAlnZXRlbnZfc3RyaW5nKChw YXRoKSwgKHZhciksIChzaXplKSkNCiANCi12b2lkCW5ldF93YXJuX25vdF9t cHNhZmUoY29uc3QgY2hhciAqY29tcG9uZW50KTsNCi0jZGVmaW5lCU5FVF9O RUVEU19HSUFOVChjb21wb25lbnQpCQkJCQlcDQotCVNZU0lOSVQoX19DT05D QVQoX19uZXRfd2Fybl9ub3RfbXBzYWZlXywgX19MSU5FX18pLAkJXA0KLQkg ICAgU0lfU1VCX1NFVFRJTkdTLCBTSV9PUkRFUl9TRUNPTkQsIG5ldF93YXJu X25vdF9tcHNhZmUsIGNvbXBvbmVudCk7DQotDQogc3RydWN0IGludHJfY29u ZmlnX2hvb2sgew0KIAlUQUlMUV9FTlRSWShpbnRyX2NvbmZpZ19ob29rKSBp Y2hfbGlua3M7DQogCXZvaWQJKCppY2hfZnVuYykodm9pZCAqYXJnKTsNCklu ZGV4OiBzeXMvbXV0ZXguaA0KPT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KUkNT IGZpbGU6IC96b28vY3ZzdXAvRnJlZUJTRC1DVlMvc3JjL3N5cy9zeXMvbXV0 ZXguaCx2DQpyZXRyaWV2aW5nIHJldmlzaW9uIDEuOTgNCmRpZmYgLXUgLXIx Ljk4IG11dGV4LmgNCi0tLSBzeXMvbXV0ZXguaAkxOCBKdWwgMjAwNyAyMDo0 NjowNiAtMDAwMAkxLjk4DQorKysgc3lzL211dGV4LmgJMjAgSnVsIDIwMDcg MTE6MTE6MDQgLTAwMDANCkBAIC0zOTcsMzUgKzM5NywxOCBAQA0KIH0gd2hp bGUgKDApDQogDQogLyoNCi0gKiBOZXR3b3JrIE1QU0FGRSB0ZW1wb3Jhcnkg d29ya2Fyb3VuZHMuICBXaGVuIGRlYnVnX21wc2FmZW5ldA0KLSAqIGlzIDEg dGhlIG5ldHdvcmsgaXMgYXNzdW1lZCB0byBvcGVyYXRlIHdpdGhvdXQgR2lh bnQgb24gdGhlDQotICogaW5wdXQgcGF0aCBhbmQgcHJvdG9jb2xzIHRoYXQg cmVxdWlyZSBHaWFudCBtdXN0IGNvbGxlY3QgaXQNCi0gKiBvbiBlbnRyeS4g IFdoZW4gMCBHaWFudCBpcyBncmFiYmVkIGluIHRoZSBuZXR3b3JrIGludGVy ZmFjZQ0KLSAqIElTUidzIGFuZCBpbiB0aGUgbmV0aXNyIHBhdGggYW5kIHRo ZXJlIGlzIG5vIG5lZWQgdG8gZ3JhYg0KLSAqIHRoZSBHaWFudCBsb2NrLiAg Tm90ZSB0aGF0LCB1bmxpa2UgUElDS1VQX0dJQU5UKCkgYW5kDQotICogRFJP UF9HSUFOVCgpLCB0aGVzZSBtYWNyb3MgZGlyZWN0bHkgd3JhcCBtdXRleCBv cGVyYXRpb25zDQotICogd2l0aG91dCBzcGVjaWFsIHJlY3Vyc2lvbiBoYW5k bGluZy4NCi0gKg0KLSAqIFRoaXMgbWVjaGFuaXNtIGlzIGludGVuZGVkIGFz IHRlbXBvcmFyeSB1bnRpbCBldmVyeXRoaW5nIG9mDQotICogaW1wb3J0YW5j ZSBpcyBwcm9wZXJseSBsb2NrZWQuICBOb3RlOiB0aGUgc2VtYW50aWNzIGZv cg0KLSAqIE5FVF97TE9DSyxVTkxPQ0t9X0dJQU5UKCkgYXJlIG5vdCB0aGUg c2FtZSBhcyBEUk9QX0dJQU5UKCkNCi0gKiBhbmQgUElDS1VQX0dJQU5UKCks IGFzIHRoZXkgYXJlIHBsYWluIG11dGV4IG9wZXJhdGlvbnMNCi0gKiB3aXRo b3V0IGEgcmVjdXJzaW9uIGNvdW50ZXIuDQorICogV2l0aCB0aGUgYWR2ZW50 IG9mIGZpbmUtZ3JhaW5lZCBsb2NraW5nLCB0aGUgR2lhbnQgbG9jayBpcyBu byBsb25nZXINCisgKiByZXF1aXJlZCBhcm91bmQgdGhlIG5ldHdvcmsgc3Rh Y2suICBUaGVzZSBtYWNyb3MgZXhpc3QgZm9yIGhpc3RvcmljYWwNCisgKiBy ZWFzb25zLCBhbGxvd2luZyBjb25kaXRpb25hbCBhY3F1aXNpdGlvbiBvZiBH aWFudCBiYXNlZCBvbiBhIGRlYnVnZ2luZw0KKyAqIHNldHRpbmcsIGFuZCB3 aWxsIGJlIHJlbW92ZWQuDQogICovDQotZXh0ZXJuCWludCBkZWJ1Z19tcHNh ZmVuZXQ7CQkvKiBkZWZpbmVkIGluIG5ldC9uZXRpc3IuYyAqLw0KICNkZWZp bmUJTkVUX0xPQ0tfR0lBTlQoKSBkbyB7CQkJCQkJXA0KLQlpZiAoIWRlYnVn X21wc2FmZW5ldCkJCQkJCQlcDQotCQltdHhfbG9jaygmR2lhbnQpOwkJCQkJ XA0KIH0gd2hpbGUgKDApDQogI2RlZmluZQlORVRfVU5MT0NLX0dJQU5UKCkg ZG8gewkJCQkJCVwNCi0JaWYgKCFkZWJ1Z19tcHNhZmVuZXQpCQkJCQkJXA0K LQkJbXR4X3VubG9jaygmR2lhbnQpOwkJCQkJXA0KIH0gd2hpbGUgKDApDQog I2RlZmluZQlORVRfQVNTRVJUX0dJQU5UKCkgZG8gewkJCQkJCVwNCi0JaWYg KCFkZWJ1Z19tcHNhZmVuZXQpCQkJCQkJXA0KLQkJbXR4X2Fzc2VydCgmR2lh bnQsIE1BX09XTkVEKTsJCQkJXA0KIH0gd2hpbGUgKDApDQotI2RlZmluZQlO RVRfQ0FMTE9VVF9NUFNBRkUJKGRlYnVnX21wc2FmZW5ldCA/IENBTExPVVRf TVBTQUZFIDogMCkNCisjZGVmaW5lCU5FVF9DQUxMT1VUX01QU0FGRQlDQUxM T1VUX01QU0FGRQ0KIA0KIHN0cnVjdCBtdHhfYXJncyB7DQogCXN0cnVjdCBt dHgJKm1hX210eDsNCg== --0-894572789-1185272265=:83919 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ freebsd-arch@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-arch To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" --0-894572789-1185272265=:83919-- From owner-freebsd-current@FreeBSD.ORG Wed Jul 25 10:46: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 D1AD816A41A for ; Wed, 25 Jul 2007 10:46:51 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id 5CD9213C45D for ; Wed, 25 Jul 2007 10:46:50 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (ppp121-45-48-57.lns11.adl2.internode.on.net [121.45.48.57]) (authenticated bits=0) by cain.gsoft.com.au (8.13.8/8.13.8) with ESMTP id l6PAklZY043506 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Jul 2007 20:16:49 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: Andrey Chernov Date: Wed, 25 Jul 2007 20:16:10 +0930 User-Agent: KMail/1.9.7 References: <200707251733.12658.doconnor@gsoft.com.au> <20070725084755.GA75871@nagual.pp.ru> <20070725090203.GA87414@nagual.pp.ru> In-Reply-To: <20070725090203.GA87414@nagual.pp.ru> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1704525.q3cJ7WgmPW"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200707252016.20807.doconnor@gsoft.com.au> X-Spam-Score: -2.312 () BAYES_00 X-Scanned-By: MIMEDefang 2.58 on 203.31.81.10 Cc: freebsd-current@freebsd.org, sergei@freebsd.org, scf@freebsd.org Subject: Re: zsh oddities with recent -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, 25 Jul 2007 10:46:51 -0000 --nextPart1704525.q3cJ7WgmPW Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wed, 25 Jul 2007, Andrey Chernov wrote: > On Wed, Jul 25, 2007 at 12:47:56PM +0400, Andrey Chernov wrote: > > On Wed, Jul 25, 2007 at 05:33:05PM +0930, Daniel O'Connor wrote: > > > I updated my -current box (laptop) on the 18th and I have 2 > > > strange issues with zsh. > > > > > > 1) I can't unset environmental variables set before the shell > > > started, eg.. > > > > zsh uses system's putenv() but home-rolled delete from environment > > (instead of unsetenv()). It clearly violates POSIX since it forbids > > to mix putenv/setenv/unsetenv with direct environ manipulations: =2E.. > > Quick fix will be just to disable HAVE_PUTENV config option. It > > gains nothing in the code but makes troubles. That works around it nicely, thanks. =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart1704525.q3cJ7WgmPW 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) iD8DBQBGpyn85ZPcIHs/zowRAlAcAJ9NcaCVB1Diud5C3IDBg0KOxtUGsQCaAk9k bv4Y0Yz5iiAKjMQg/EuVGyo= =BiKX -----END PGP SIGNATURE----- --nextPart1704525.q3cJ7WgmPW-- From owner-freebsd-current@FreeBSD.ORG Wed Jul 25 11:24:45 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 E82AD16A41A for ; Wed, 25 Jul 2007 11:24:45 +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 5332413C45B for ; Wed, 25 Jul 2007 11:24:44 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 13001 invoked from network); 25 Jul 2007 11:20:08 -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 ; 25 Jul 2007 11:20:08 -0000 Message-ID: <46A7330F.6000204@freebsd.org> Date: Wed, 25 Jul 2007 13:25:03 +0200 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Robert Watson References: <20070709234401.S29353@odysseus.silby.com> <20070710132253.GJ1038@void.codelabs.ru> <20070710202028.I34890@odysseus.silby.com> <200707201155.44573.peter@wemm.org> <20070725003706.U79872@odysseus.silby.com> <20070725093019.E83919@fledge.watson.org> In-Reply-To: <20070725093019.E83919@fledge.watson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org, Peter Wemm , Mike Silbersack , freebsd-current@freebsd.org, 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: Wed, 25 Jul 2007 11:24:46 -0000 Robert Watson wrote: > On Wed, 25 Jul 2007, Mike Silbersack wrote: > >> On Fri, 20 Jul 2007, Peter Wemm wrote: >> >>> 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. :-( >> >> Any extra ACK that arrives is probably being processed by the >> syncookie code is my guess. So, I think that the problem is probably >> anywhere except in the syncookie code. I guess it is a late ACK for a connection that is being shut down. Once the tcpcb of the connection is gone any further segments will hit the syncache and cause such an error message. The real problem seems to be in the connection shutdown sequence that either somehow prematurely completes or emits spurious packets after completion. >>> I'll give your patch a shot and see if it improves things at all. >> >> It won't, not for this case. :( >> >> But I'll get it committed ASAP, because it fixes other cases. Unless, >> that is, things IRL keep interrupting me. > > FYI, I received an informal report a few days ago that the SYN cache was > ignoring RSTs, and kept transmitting SYN/ACK's even though a RST had > been sent. This was during some local network testing where a host > sends SYN packets out to a large number of other hosts, then quickly > resets the connections after getting SYN/ACK's. Given that your > previous work suggests that the syncache timer never fires at all, I'm > not quite sure what to make of this report, but once your patches are in > I can ask them to rerun it on one of my hosts and see. Not all RST lead to the termination of the syncache entry. It'd be helpful to know which log messages the local network test generated. There are two possibilities: "Our SYN|ACK was rejected, connection attempt aborted by remote endpoint", or "Spurious RST, segment rejected". Only the former causes the termination of the syncache entry. I fear the distinction between these two cases is over- engineered and they should be collapsed together. -- Andre From owner-freebsd-current@FreeBSD.ORG Wed Jul 25 11:24: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 2328716A421 for ; Wed, 25 Jul 2007 11:24:47 +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 5390213C465 for ; Wed, 25 Jul 2007 11:24:44 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 13001 invoked from network); 25 Jul 2007 11:20:08 -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 ; 25 Jul 2007 11:20:08 -0000 Message-ID: <46A7330F.6000204@freebsd.org> Date: Wed, 25 Jul 2007 13:25:03 +0200 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Robert Watson References: <20070709234401.S29353@odysseus.silby.com> <20070710132253.GJ1038@void.codelabs.ru> <20070710202028.I34890@odysseus.silby.com> <200707201155.44573.peter@wemm.org> <20070725003706.U79872@odysseus.silby.com> <20070725093019.E83919@fledge.watson.org> In-Reply-To: <20070725093019.E83919@fledge.watson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org, Peter Wemm , Mike Silbersack , freebsd-current@freebsd.org, 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: Wed, 25 Jul 2007 11:24:47 -0000 Robert Watson wrote: > On Wed, 25 Jul 2007, Mike Silbersack wrote: > >> On Fri, 20 Jul 2007, Peter Wemm wrote: >> >>> 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. :-( >> >> Any extra ACK that arrives is probably being processed by the >> syncookie code is my guess. So, I think that the problem is probably >> anywhere except in the syncookie code. I guess it is a late ACK for a connection that is being shut down. Once the tcpcb of the connection is gone any further segments will hit the syncache and cause such an error message. The real problem seems to be in the connection shutdown sequence that either somehow prematurely completes or emits spurious packets after completion. >>> I'll give your patch a shot and see if it improves things at all. >> >> It won't, not for this case. :( >> >> But I'll get it committed ASAP, because it fixes other cases. Unless, >> that is, things IRL keep interrupting me. > > FYI, I received an informal report a few days ago that the SYN cache was > ignoring RSTs, and kept transmitting SYN/ACK's even though a RST had > been sent. This was during some local network testing where a host > sends SYN packets out to a large number of other hosts, then quickly > resets the connections after getting SYN/ACK's. Given that your > previous work suggests that the syncache timer never fires at all, I'm > not quite sure what to make of this report, but once your patches are in > I can ask them to rerun it on one of my hosts and see. Not all RST lead to the termination of the syncache entry. It'd be helpful to know which log messages the local network test generated. There are two possibilities: "Our SYN|ACK was rejected, connection attempt aborted by remote endpoint", or "Spurious RST, segment rejected". Only the former causes the termination of the syncache entry. I fear the distinction between these two cases is over- engineered and they should be collapsed together. -- Andre From owner-freebsd-current@FreeBSD.ORG Wed Jul 25 11:14: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 B531E16A41A for ; Wed, 25 Jul 2007 11:14:24 +0000 (UTC) (envelope-from Susan.Lan@zyxel.com.tw) Received: from zyfb01-66.zyxel.com.tw (zyfb01-66.zyxel.com.tw [59.124.183.66]) by mx1.freebsd.org (Postfix) with ESMTP id 5AFBD13C459 for ; Wed, 25 Jul 2007 11:14:24 +0000 (UTC) (envelope-from Susan.Lan@zyxel.com.tw) Received: from zytwbe01.zyxel.com ([172.23.5.10]) by zyfb01-66.zyxel.com.tw with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Jul 2007 19:02:20 +0800 Received: from zytwfe01.ZyXEL.com ([172.23.5.5]) by zytwbe01.zyxel.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Jul 2007 19:02:20 +0800 Received: from [172.23.17.155] ([172.23.17.155]) by zytwfe01.ZyXEL.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Jul 2007 19:02:20 +0800 Message-ID: <46A72DBC.1080400@zyxel.com.tw> Date: Wed, 25 Jul 2007 19:02:20 +0800 From: blue User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Jul 2007 11:02:20.0086 (UTC) FILETIME=[454EA560:01C7CEAB] X-Mailman-Approved-At: Wed, 25 Jul 2007 11:34:38 +0000 Subject: Error while upgrading FreeBSD-Release6.1 to 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, 25 Jul 2007 11:14:24 -0000 Dear all: I have a problem while upgrading FreeBSD-6.1 to CURRENT. First of all, I encountered config version mismatch. So I re-buildworld, and that error disappeared. However, gcc version for FreeBSD-6.1 seems old since CURRENT needs version 4.x. So I went to ports tree and install latest gcc4.2. But after buildkernel, there was still error message: cc1: error: unrecognized command line option "-mno-align-long-strings" cc1: error: unrecognized command line option "-fformat-extensions" I don't know what else I could do. Please help me out. Thanks. blue From owner-freebsd-current@FreeBSD.ORG Wed Jul 25 12:30: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 47A6A16A418 for ; Wed, 25 Jul 2007 12:30:36 +0000 (UTC) (envelope-from luca@lavabit.com) Received: from karen.lavabit.com (karen.lavabit.com [72.249.41.33]) by mx1.freebsd.org (Postfix) with ESMTP id 2379313C469 for ; Wed, 25 Jul 2007 12:30:35 +0000 (UTC) (envelope-from luca@lavabit.com) Received: from dispatchd.nerdshack.com (julie.lavabit.com [72.249.41.31]) by karen.lavabit.com (Postfix) with SMTP id 22902C86ED for ; Wed, 25 Jul 2007 07:09:57 -0500 (CDT) Received: from linux.site (jastpc1.epfl.ch [128.179.67.50]) by mail.nerdshack.com with ESMTP Wed, 25 Jul 2007 07:09:57 -0500 Date: Wed, 25 Jul 2007 14:04:52 +0200 From: luca To: freebsd-current@freebsd.org Message-ID: <20070725140452.261d8046@linux.site> In-Reply-To: <46A72DBC.1080400@zyxel.com.tw> References: <46A72DBC.1080400@zyxel.com.tw> X-Mailer: Sylpheed-Claws 1.0.3 (GTK+ 1.2.10; i686-suse-linux) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: Error while upgrading FreeBSD-Release6.1 to 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, 25 Jul 2007 12:30:36 -0000 When you install a new version of gcc from ports, the gcc command still point to the version used to build the release. What's the output of "gcc -v" ? To build with the newvest gcc, you have something like gcc42. Hope it helps luca On Wed, 25 Jul 2007 19:02:20 +0800 blue wrote: > Dear all: > > I have a problem while upgrading FreeBSD-6.1 to CURRENT. First of all, I > encountered config version mismatch. So I re-buildworld, and that error > disappeared. However, gcc version for FreeBSD-6.1 seems old since > CURRENT needs version 4.x. So I went to ports tree and install latest > gcc4.2. But after buildkernel, there was still error message: cc1: > error: unrecognized command line option "-mno-align-long-strings" > cc1: error: unrecognized command > line option "-fformat-extensions" > > I don't know what else I could do. Please help me out. > > Thanks. > > blue > _______________________________________________ > 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 25 12:44:14 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 BE8F716A420 for ; Wed, 25 Jul 2007 12:44:14 +0000 (UTC) (envelope-from nicolas@boiteameuh.org) Received: from postfix1-g20.free.fr (postfix1-g20.free.fr [212.27.60.42]) by mx1.freebsd.org (Postfix) with ESMTP id 6535113C468 for ; Wed, 25 Jul 2007 12:44:14 +0000 (UTC) (envelope-from nicolas@boiteameuh.org) Received: from smtp4-g19.free.fr (smtp4-g19.free.fr [212.27.42.30]) by postfix1-g20.free.fr (Postfix) with ESMTP id 9344517D2F64 for ; Wed, 25 Jul 2007 14:19:51 +0200 (CEST) Received: from smtp4-g19.free.fr (localhost.localdomain [127.0.0.1]) by smtp4-g19.free.fr (Postfix) with ESMTP id 9DEFC66C60 for ; Wed, 25 Jul 2007 14:19:50 +0200 (CEST) Received: from popple.boiteameuh.org (popple.boiteameuh.org [82.232.215.170]) by smtp4-g19.free.fr (Postfix) with ESMTP id 8027B6EDCE for ; Wed, 25 Jul 2007 14:19:50 +0200 (CEST) Received: by popple.boiteameuh.org (Postfix, from userid 1000) id 5DA624EC19; Wed, 25 Jul 2007 14:17:42 +0200 (CEST) Date: Wed, 25 Jul 2007 14:17:42 +0200 To: freebsd-current@freebsd.org Message-ID: <20070725121741.GE28450@boiteameuh.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="//IivP0gvsAy3Can" Content-Disposition: inline User-Agent: Mutt/1.5.13 (2006-08-11) From: nicolas@boiteameuh.org (Nicolas Haller) Subject: Interrupt storm on atapci1+ X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Jul 2007 12:44:14 -0000 --//IivP0gvsAy3Can Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi all, I currently running a FreeBSD-CURRENT on a Intel Core 2 Duo and I seem I have a interrupt storm which take approximately 90% of a CPU. This is the vmstat -i nicolas@marcellus:~%vmstat -i interrupt total rate irq1: atkbd0 2508 0 irq17: mskc0 133918 6 irq19: fwohci0+ 8288 0 irq22: atapci1+ 1174121373 61321 irq23: uhci3 ehci1 1 0 cpu0: timer 38250554 1997 cpu1: timer 38240647 1997 Total 1250757289 65323 I give you my kernel conf. I don't really know what informations can be useful so feel free to ask anything you need. Cheers, --=20 Nicolas Haller --//IivP0gvsAy3Can Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGpz9lVrtqUQ7Ko4gRAl3oAKClAc8MQxf+OJzLAaU9Y+rgH3OWVQCdHaEz tR4eGeSjJGCpelZoDUMsjAQ= =wBGY -----END PGP SIGNATURE----- --//IivP0gvsAy3Can-- From owner-freebsd-current@FreeBSD.ORG Wed Jul 25 12:50: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 C8C0216A41A for ; Wed, 25 Jul 2007 12:50:01 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by mx1.freebsd.org (Postfix) with ESMTP id 99BE513C459 for ; Wed, 25 Jul 2007 12:50:01 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 25 Jul 2007 05:50:01 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAJrjpkarR7MV/2dsb2JhbAA X-IronPort-AV: i="4.16,580,1175497200"; d="scan'208"; a="506838700:sNHT30695428" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l6PCo1oh029257; Wed, 25 Jul 2007 05:50:01 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l6PCo06C008429; Wed, 25 Jul 2007 12:50:00 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Jul 2007 05:49:59 -0700 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Jul 2007 05:49:59 -0700 Message-ID: <46A7471E.6050507@cisco.com> Date: Wed, 25 Jul 2007 08:50:38 -0400 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.13) Gecko/20070601 X-Accept-Language: en-us, en MIME-Version: 1.0 To: blue References: <46A72DBC.1080400@zyxel.com.tw> In-Reply-To: <46A72DBC.1080400@zyxel.com.tw> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Jul 2007 12:49:59.0621 (UTC) FILETIME=[4F7D7750:01C7CEBA] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1204; t=1185367801; x=1186231801; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rrs@cisco.com; z=From:=20Randall=20Stewart=20 |Subject:=20Re=3A=20Error=20while=20upgrading=20FreeBSD-Release6.1=20to=2 0CURRENT |Sender:=20; bh=7snGHUZA12wePZaJ2CCY1GQhWnck0ni9xQBJKXyCx2c=; b=VdjxIlVwI1NC76EZgLCzUgyYDraC8B6P/q0KNN+2hWPoqf4kAWgjErFffLM0szzQofeWnWyU QyiNOcpCBD+ch1eUm/MCaIP0A9JCNG5veloOlfDgOSSkZJdqRiGxgqRnBE3Np50Lc9A8Bffy4N klXFM5m5n/15LfSLCrPNR8rF4=; Authentication-Results: sj-dkim-1; header.From=rrs@cisco.com; dkim=pass (sig from cisco.com/sjdkim1004 verified; ); Cc: freebsd-current@freebsd.org Subject: Re: Error while upgrading FreeBSD-Release6.1 to 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, 25 Jul 2007 12:50:01 -0000 blue wrote: > Dear all: > > I have a problem while upgrading FreeBSD-6.1 to CURRENT. First of all, I > encountered config version mismatch. So I re-buildworld, and that error > disappeared. However, gcc version for FreeBSD-6.1 seems old since > CURRENT needs version 4.x. So I went to ports tree and install latest > gcc4.2. But after buildkernel, there was still error message: cc1: > error: unrecognized command line option "-mno-align-long-strings" > cc1: error: unrecognized command line > option "-fformat-extensions" > > I don't know what else I could do. Please help me out. > > Thanks. > > blue > _______________________________________________ > 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" > Hmm... I hit a similar problem a while back and what I did is mv the original gcc to old.gcc and then setup links from gcc and cc to -> gcc.42 (or whatever the name was for it) That worked for me. R -- Randall Stewart NSSTG - Cisco Systems Inc. 803-345-0369 803-317-4952 (cell) From owner-freebsd-current@FreeBSD.ORG Wed Jul 25 13:06:56 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 BA93416A41F for ; Wed, 25 Jul 2007 13:06:56 +0000 (UTC) (envelope-from kabaev@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 6BC4013C469 for ; Wed, 25 Jul 2007 13:06:56 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: by wx-out-0506.google.com with SMTP id i29so146375wxd for ; Wed, 25 Jul 2007 06:06:55 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer:mime-version:content-type; b=MLqzXuhI7dZmpjSpS7gViVCu3jJ2Le24s5lcmFtijCCPASx7ftDCr8mgS3WYanxx0W4g5E9W+kzHZ3ksOysE3qwudP4sWrIEP0jv50K7qGtJOXYKEieH20KoTcv/ArFQ6CBDPDkjAY5Kxabs2qU7+XhV0ULQmLEVqtggVOWwOQA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer:mime-version:content-type; b=oFedIkvAscWR/X85PTlMsWaIGzbxkqc3o0Z5vBPTwE25na7RP8dUy9Kr0KR0ReQtrg4HQxy6qs6SUgbqYxjkgYy9sVCvlBUjd6cvHcvd492ExZPVspd9QrfdQ25Xa7I9SVK6fNDxo4NFaW8BLM1YLhMx/vb+aof6BIZ06crYyK0= Received: by 10.90.93.6 with SMTP id q6mr360883agb.1185368815176; Wed, 25 Jul 2007 06:06:55 -0700 (PDT) Received: from kan.dnsalias.net ( [24.34.98.206]) by mx.google.com with ESMTPS id 1sm934251agb.2007.07.25.06.06.53 (version=SSLv3 cipher=OTHER); Wed, 25 Jul 2007 06:06:54 -0700 (PDT) Date: Wed, 25 Jul 2007 09:06:49 -0400 From: Alexander Kabaev To: blue Message-ID: <20070725090649.7e213cff@kan.dnsalias.net> In-Reply-To: <46A72DBC.1080400@zyxel.com.tw> References: <46A72DBC.1080400@zyxel.com.tw> X-Mailer: Claws Mail 2.9.1 (GTK+ 2.10.12; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_s1BDv=O7SdJ5KrH3rKOYYOL"; protocol="application/pgp-signature"; micalg=PGP-SHA1 Cc: freebsd-current@freebsd.org Subject: Re: Error while upgrading FreeBSD-Release6.1 to 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, 25 Jul 2007 13:06:56 -0000 --Sig_s1BDv=O7SdJ5KrH3rKOYYOL Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Wed, 25 Jul 2007 19:02:20 +0800 blue wrote: > Dear all: >=20 > I have a problem while upgrading FreeBSD-6.1 to CURRENT. First of > all, I encountered config version mismatch. So I re-buildworld, and > that error disappeared. However, gcc version for FreeBSD-6.1 seems > old since CURRENT needs version 4.x. So I went to ports tree and > install latest gcc4.2. But after buildkernel, there was still error > message: cc1: error: unrecognized command line option > "-mno-align-long-strings" cc1: error: unrecognized command=20 > line option "-fformat-extensions" >=20 > I don't know what else I could do. Please help me out. >=20 Please follow documented procedure for upgrades, especially when going from one major release to another. This involved using 'make buildworld; make buildkernel; make installkernel; make reboot; make installworld'. What you did was circumventing the rules and you were rightfully bitten by your own actions. --=20 Alexander Kabaev --Sig_s1BDv=O7SdJ5KrH3rKOYYOL Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGp0rpQ6z1jMm+XZYRAgqOAJwPBkqG/nAr5HQfZr2Av3rtJTAyuwCeJaNN UyQA7uiJf0/5asD/gtJqGIw= =/qcL -----END PGP SIGNATURE----- --Sig_s1BDv=O7SdJ5KrH3rKOYYOL-- From owner-freebsd-current@FreeBSD.ORG Wed Jul 25 14:46: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 A338A16A419; Wed, 25 Jul 2007 14:46:13 +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 4FDC813C45A; Wed, 25 Jul 2007 14:46:13 +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 1IDi7z-000NNG-0P; Wed, 25 Jul 2007 18:46:15 +0400 Received: from bsam by ipt.ru with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1IDi86-0009GJ-L2; Wed, 25 Jul 2007 18:46:22 +0400 To: Pawel Jakub Dawidek References: <97732929@srv.sem.ipt.ru> <20070723133333.GF5456@garage.freebsd.pl> <78011660@srv.sem.ipt.ru> <20070724144549.GA12473@garage.freebsd.pl> From: Boris Samorodov Date: Wed, 25 Jul 2007 18:46:22 +0400 In-Reply-To: <20070724144549.GA12473@garage.freebsd.pl> (Pawel Jakub Dawidek's message of "Tue\, 24 Jul 2007 16\:45\:49 +0200") Message-ID: <08401633@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-current@FreeBSD.org Subject: Re: mount_nullfs inside a jail X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Jul 2007 14:46:13 -0000 On Tue, 24 Jul 2007 16:45:49 +0200 Pawel Jakub Dawidek wrote: > On Tue, Jul 24, 2007 at 06:03:47PM +0400, Boris Samorodov wrote: > > On Mon, 23 Jul 2007 15:33:33 +0200 Pawel Jakub Dawidek wrote: > > > As you can see, nullfs doesn't have 'jail' flag. The only jail-friendly > > > file system currently is ZFS. Nullfs is a good candidate for a > > > jail-friendly file system, but is not marked as such yet. > > > > Does somebody know if only a flag is missing or not? > You may try changing the line in /sys/fs/nullfs/null_vfsops.c from: > VFS_SET(null_vfsops, nullfs, VFCF_LOOPBACK); > to: > VFS_SET(null_vfsops, nullfs, VFCF_LOOPBACK | VFCF_JAIL); This didn't help: ----- btest# sysctl security.jail security.jail.jailed: 1 security.jail.mount_allowed: 1 security.jail.chflags_allowed: 1 security.jail.allow_raw_sockets: 0 security.jail.enforce_statfs: 2 security.jail.sysvipc_allowed: 1 security.jail.socket_unixiproute_only: 1 security.jail.set_hostname_allowed: 1 btest# lsvfs Filesystem Refs Flags -------------------------------- ----- --------------- ufs 6 nfs 0 network procfs 0 synthetic devfs 3 synthetic ntfs 0 msdosfs 0 nfs4 0 network nullfs 1 loopback, jail cd9660 0 read-only btest# df Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/da0s1d 945804208 22136782 848003090 3% / btest# mount /usr/ports/distfiles /mnt mount: /usr/ports/distfiles : Operation not permitted ----- Thanks for the suggestion though. > but I don't think anyone did any security analysis of this yet. 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 Wed Jul 25 14:51: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 96C1D16A41B for ; Wed, 25 Jul 2007 14:51:18 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.freebsd.org (Postfix) with ESMTP id 5C03D13C4B5 for ; Wed, 25 Jul 2007 14:51:16 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 619EA487FC; Wed, 25 Jul 2007 16:51:14 +0200 (CEST) Received: from localhost (154.81.datacomsa.pl [195.34.81.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 92E80487F8; Wed, 25 Jul 2007 16:51:07 +0200 (CEST) Date: Wed, 25 Jul 2007 16:50:31 +0200 From: Pawel Jakub Dawidek To: Boris Samorodov Message-ID: <20070725145031.GJ12473@garage.freebsd.pl> References: <97732929@srv.sem.ipt.ru> <20070723133333.GF5456@garage.freebsd.pl> <78011660@srv.sem.ipt.ru> <20070724144549.GA12473@garage.freebsd.pl> <08401633@srv.sem.ipt.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gTY1JhLGodeuSBqf" Content-Disposition: inline In-Reply-To: <08401633@srv.sem.ipt.ru> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-2.6 required=3.0 tests=BAYES_00 autolearn=ham version=3.0.4 Cc: freebsd-current@FreeBSD.org Subject: Re: mount_nullfs inside a jail X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Jul 2007 14:51:18 -0000 --gTY1JhLGodeuSBqf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 25, 2007 at 06:46:22PM +0400, Boris Samorodov wrote: > On Tue, 24 Jul 2007 16:45:49 +0200 Pawel Jakub Dawidek wrote: > > On Tue, Jul 24, 2007 at 06:03:47PM +0400, Boris Samorodov wrote: > > > On Mon, 23 Jul 2007 15:33:33 +0200 Pawel Jakub Dawidek wrote: >=20 > > > > As you can see, nullfs doesn't have 'jail' flag. The only jail-frie= ndly > > > > file system currently is ZFS. Nullfs is a good candidate for a > > > > jail-friendly file system, but is not marked as such yet. > > >=20 > > > Does somebody know if only a flag is missing or not? >=20 > > You may try changing the line in /sys/fs/nullfs/null_vfsops.c from: >=20 > > VFS_SET(null_vfsops, nullfs, VFCF_LOOPBACK); >=20 > > to: >=20 > > VFS_SET(null_vfsops, nullfs, VFCF_LOOPBACK | VFCF_JAIL); >=20 > This didn't help: > ----- > btest# sysctl security.jail > security.jail.jailed: 1 > security.jail.mount_allowed: 1 > security.jail.chflags_allowed: 1 > security.jail.allow_raw_sockets: 0 > security.jail.enforce_statfs: 2 > security.jail.sysvipc_allowed: 1 > security.jail.socket_unixiproute_only: 1 > security.jail.set_hostname_allowed: 1 > btest# lsvfs > Filesystem Refs Flags > -------------------------------- ----- --------------- > ufs 6=20 > nfs 0 network > procfs 0 synthetic > devfs 3 synthetic > ntfs 0=20 > msdosfs 0=20 > nfs4 0 network > nullfs 1 loopback, jail > cd9660 0 read-only > btest# df > Filesystem 1K-blocks Used Avail Capacity Mounted on > /dev/da0s1d 945804208 22136782 848003090 3% / > btest# mount /usr/ports/distfiles /mnt > mount: /usr/ports/distfiles : Operation not permitted mount_nullfs? --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --gTY1JhLGodeuSBqf Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFGp2M3ForvXbEpPzQRAhjIAJ9bG8lWJsPo30YX0V/M2tsCFpk+FwCdFRIg nWRvstsLGGnqDAinr0G73Tk= =8XJO -----END PGP SIGNATURE----- --gTY1JhLGodeuSBqf-- From owner-freebsd-current@FreeBSD.ORG Wed Jul 25 15:03:31 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 7FB5716A417; Wed, 25 Jul 2007 15:03:31 +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 16BBA13C494; Wed, 25 Jul 2007 15:03:30 +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 1IDiOg-000NQn-1U; Wed, 25 Jul 2007 19:03:30 +0400 Received: from bsam by ipt.ru with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1IDiOn-0009l1-NG; Wed, 25 Jul 2007 19:03:37 +0400 To: Pawel Jakub Dawidek References: <97732929@srv.sem.ipt.ru> <20070723133333.GF5456@garage.freebsd.pl> <78011660@srv.sem.ipt.ru> <20070724144549.GA12473@garage.freebsd.pl> <08401633@srv.sem.ipt.ru> <20070725145031.GJ12473@garage.freebsd.pl> From: Boris Samorodov Date: Wed, 25 Jul 2007 19:03:37 +0400 In-Reply-To: <20070725145031.GJ12473@garage.freebsd.pl> (Pawel Jakub Dawidek's message of "Wed\, 25 Jul 2007 16\:50\:31 +0200") Message-ID: <76240598@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-current@FreeBSD.org Subject: Re: mount_nullfs inside a jail X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Jul 2007 15:03:31 -0000 On Wed, 25 Jul 2007 16:50:31 +0200 Pawel Jakub Dawidek wrote: > On Wed, Jul 25, 2007 at 06:46:22PM +0400, Boris Samorodov wrote: > > On Tue, 24 Jul 2007 16:45:49 +0200 Pawel Jakub Dawidek wrote: > > > On Tue, Jul 24, 2007 at 06:03:47PM +0400, Boris Samorodov wrote: > > > > On Mon, 23 Jul 2007 15:33:33 +0200 Pawel Jakub Dawidek wrote: > > > > > > > As you can see, nullfs doesn't have 'jail' flag. The only jail-friendly > > > > > file system currently is ZFS. Nullfs is a good candidate for a > > > > > jail-friendly file system, but is not marked as such yet. > > > > > > > > Does somebody know if only a flag is missing or not? > > > > > You may try changing the line in /sys/fs/nullfs/null_vfsops.c from: > > > > > VFS_SET(null_vfsops, nullfs, VFCF_LOOPBACK); > > > > > to: > > > > > VFS_SET(null_vfsops, nullfs, VFCF_LOOPBACK | VFCF_JAIL); > > > > This didn't help: > > ----- > > btest# sysctl security.jail > > security.jail.jailed: 1 > > security.jail.mount_allowed: 1 > > security.jail.chflags_allowed: 1 > > security.jail.allow_raw_sockets: 0 > > security.jail.enforce_statfs: 2 > > security.jail.sysvipc_allowed: 1 > > security.jail.socket_unixiproute_only: 1 > > security.jail.set_hostname_allowed: 1 > > btest# lsvfs > > Filesystem Refs Flags > > -------------------------------- ----- --------------- > > ufs 6 > > nfs 0 network > > procfs 0 synthetic > > devfs 3 synthetic > > ntfs 0 > > msdosfs 0 > > nfs4 0 network > > nullfs 1 loopback, jail > > cd9660 0 read-only > > btest# df > > Filesystem 1K-blocks Used Avail Capacity Mounted on > > /dev/da0s1d 945804208 22136782 848003090 3% / > > btest# mount /usr/ports/distfiles /mnt > > mount: /usr/ports/distfiles : Operation not permitted > mount_nullfs? Ops!!! (i need some coffee) My bad... Mounting works good but: ----- btest# umount /mnt umount: unmount of [restricted] failed: Invalid argument ----- 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 Wed Jul 25 15:06:18 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 0CD7B16A474 for ; Wed, 25 Jul 2007 15:06:18 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by mx1.freebsd.org (Postfix) with ESMTP id 948E813C483 for ; Wed, 25 Jul 2007 15:06:17 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 23EDCAD4A for ; Wed, 25 Jul 2007 11:06:15 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Wed, 25 Jul 2007 11:06:16 -0400 X-Sasl-enc: E0c7qwXtQRnpNbuar3N3erZkjyrNUb09kD4bGv2BU2fv 1185375975 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id 4E8A54239 for ; Wed, 25 Jul 2007 11:06:15 -0400 (EDT) Message-ID: <46A766E3.1080605@incunabulum.net> Date: Wed, 25 Jul 2007 16:06:11 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Call for testers: NetBSD IGMPv2 merge X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Jul 2007 15:06:18 -0000 Hi, I have mostly merged NetBSD's IGMPv2 implementation with a few refinements. This work is being funded by a secret santa. :-) This code is easier to read (and thus maintain), and fixes a minor memory leak in the IPv4 stack. It is also a jumping off point for the IGMPv3 work. KAME patch sets up to date have been against NetBSD, though I don't intend to use their patches directly. Patch against -CURRENT, URL: http://people.freebsd.org/~bms/dump/igmp-netbsd-sync.patch I have not merged the change which suppresses host membership reports for the link-local multicast scope space 224.0.0.0/8, my concern is that this breaks IGMP snooping switches on immediately attached layer 2 networks, even though this range is not globally routable. (*) Testing and review much appreciated. If enough people are willing to soak test this code before 7.0 point release is branched then it might justify going in in time for 7.0. Regards, BMS (*) That is not a typo - 224.0.0.0/8 *not* the whole Class D range 224.0.0.0/4. From owner-freebsd-current@FreeBSD.ORG Wed Jul 25 15:13: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 72B8D16A417 for ; Wed, 25 Jul 2007 15:13:18 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.freebsd.org (Postfix) with ESMTP id DCE7613C458 for ; Wed, 25 Jul 2007 15:13:17 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 49DE8487FB; Wed, 25 Jul 2007 17:13:15 +0200 (CEST) Received: from localhost (154.81.datacomsa.pl [195.34.81.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id BACA8456AB; Wed, 25 Jul 2007 17:13:10 +0200 (CEST) Date: Wed, 25 Jul 2007 17:12:35 +0200 From: Pawel Jakub Dawidek To: Boris Samorodov Message-ID: <20070725151235.GK12473@garage.freebsd.pl> References: <97732929@srv.sem.ipt.ru> <20070723133333.GF5456@garage.freebsd.pl> <78011660@srv.sem.ipt.ru> <20070724144549.GA12473@garage.freebsd.pl> <08401633@srv.sem.ipt.ru> <20070725145031.GJ12473@garage.freebsd.pl> <76240598@srv.sem.ipt.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6J7GEvtanOfV9oXA" Content-Disposition: inline In-Reply-To: <76240598@srv.sem.ipt.ru> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-2.6 required=3.0 tests=BAYES_00 autolearn=ham version=3.0.4 Cc: freebsd-current@FreeBSD.org Subject: Re: mount_nullfs inside a jail X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Jul 2007 15:13:18 -0000 --6J7GEvtanOfV9oXA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 25, 2007 at 07:03:37PM +0400, Boris Samorodov wrote: > > > This didn't help: > > > ----- > > > btest# sysctl security.jail > > > security.jail.jailed: 1 > > > security.jail.mount_allowed: 1 > > > security.jail.chflags_allowed: 1 > > > security.jail.allow_raw_sockets: 0 > > > security.jail.enforce_statfs: 2 > > > security.jail.sysvipc_allowed: 1 > > > security.jail.socket_unixiproute_only: 1 > > > security.jail.set_hostname_allowed: 1 > > > btest# lsvfs > > > Filesystem Refs Flags > > > -------------------------------- ----- --------------- > > > ufs 6=20 > > > nfs 0 network > > > procfs 0 synthetic > > > devfs 3 synthetic > > > ntfs 0=20 > > > msdosfs 0=20 > > > nfs4 0 network > > > nullfs 1 loopback, jail > > > cd9660 0 read-only > > > btest# df > > > Filesystem 1K-blocks Used Avail Capacity Mounted on > > > /dev/da0s1d 945804208 22136782 848003090 3% / > > > btest# mount /usr/ports/distfiles /mnt > > > mount: /usr/ports/distfiles : Operation not permitted >=20 > > mount_nullfs? >=20 > Ops!!! (i need some coffee) My bad... Mounting works good but: > ----- > btest# umount /mnt > umount: unmount of [restricted] failed: Invalid argument > ----- I overlooked. You need to set security.jail.enforce_statfs to 0. See if that helps. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --6J7GEvtanOfV9oXA Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFGp2hjForvXbEpPzQRAolwAJ98UiDihtfvDNH19+b8x7DWmBQ90gCgkbXM FHVlLoOqFaNIgpHq42DfGUo= =vN8F -----END PGP SIGNATURE----- --6J7GEvtanOfV9oXA-- From owner-freebsd-current@FreeBSD.ORG Wed Jul 25 15:17: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 7362A16A41B; Wed, 25 Jul 2007 15:17:46 +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 E5BAB13C458; Wed, 25 Jul 2007 15:17:45 +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 l6PFHirU029395; Wed, 25 Jul 2007 19:17:44 +0400 (MSD) (envelope-from marck@rinet.ru) Date: Wed, 25 Jul 2007 19:17:44 +0400 (MSD) From: Dmitry Morozovsky To: Pawel Jakub Dawidek Message-ID: <20070725190506.T18411@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]); Wed, 25 Jul 2007 19:17:44 +0400 (MSD) Cc: current@FreeBSD.org Subject: ZFS on root: slave mountpoints mount failed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Jul 2007 15:17:46 -0000 Hi there, I'm start to play with ZFS-on-root on my notebook according to wiki and found strange error I created zfs and changed ist mount point to legacy as instructed. Then I create pool/usr, pool/usr/ports and so on, and then change mount point of pool/usr to /usr. So far so good. But, after reboot, pool/usr is not mounted, and I can see no simple way to mount it automatically (yes, `zfs mount -a' seems to work, but it looks like ugly hack). Any hints? BTW, on UFS:/boot one can not symlink '.' to boot as there is regular file named boot (boot1+boot2 concatenated), so I suppose wiki page should be fixed (or at least clarified) Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Wed Jul 25 15:26: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 7F23D16A419 for ; Wed, 25 Jul 2007 15:26:18 +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 22EBA13C4A7 for ; Wed, 25 Jul 2007 15:26:18 +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 439F5EB7BC1; Wed, 25 Jul 2007 23:26:17 +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 MXHW+tX4DqPo; Wed, 25 Jul 2007 23:26:15 +0800 (CST) Received: from charlie.delphij.net (unknown [61.49.186.182]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id 190B8EB7BB9; Wed, 25 Jul 2007 23:26:15 +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=tSVc1/RiECMVCalgd8eCYlBeTlAw9n6iQbTcnj85Eq16Q36xRCt40PQm0iMN6fNRj mWF3Htf9sOikXBFiQNnqQ== Message-ID: <46A76B96.4080507@delphij.net> Date: Wed, 25 Jul 2007 23:26:14 +0800 From: Xin LI User-Agent: Thunderbird 2.0.0.5 (X11/20070721) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Bj=F6rn_K=F6nig?= References: <46A625FB.5050105@delphij.net> <50002.2001:6f8:101e:0:20e:cff:fe6d:6adb.1185310553.squirrel@webmail.alpha-tierchen.de> In-Reply-To: <50002.2001:6f8:101e:0:20e:cff:fe6d:6adb.1185310553.squirrel@webmail.alpha-tierchen.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-current@freebsd.org Subject: Re: Call for non i386/amd64 testers for tmpfs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Jul 2007 15:26:18 -0000 Björn König wrote: > Xin LI wrote: > >> I'd like to request that some owners of non-i386/amd64 boxes to test >> sys/modules/tmpfs and report if it would work correctly on other >> architectures, [...] > > I built and used the module on arm architecture without problems. The > board has 64 MB RAM and 512 MB swap via NFS. I ran the bonnie benchmark on > that filesystem with a 256 MB test file successfully. Thanks! > Do you want a certain scenario to be tested? More comprehensive testing would be appreciated, but I think I have a good reason enabling the module build on arm :-) Cheers, From owner-freebsd-current@FreeBSD.ORG Wed Jul 25 15:27: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 CF97716A418 for ; Wed, 25 Jul 2007 15:27:43 +0000 (UTC) (envelope-from scf@FreeBSD.org) Received: from mail.farley.org (farley.org [67.64.95.201]) by mx1.freebsd.org (Postfix) with ESMTP id 8AAB713C469 for ; Wed, 25 Jul 2007 15:27:43 +0000 (UTC) (envelope-from scf@FreeBSD.org) Received: from thor.farley.org (thor.farley.org [192.168.1.5]) by mail.farley.org (8.14.1/8.14.1) with ESMTP id l6PFRbfS030304; Wed, 25 Jul 2007 10:27:37 -0500 (CDT) (envelope-from scf@FreeBSD.org) Date: Wed, 25 Jul 2007 10:27:37 -0500 (CDT) From: "Sean C. Farley" To: Andrey Chernov In-Reply-To: <20070725084755.GA75871@nagual.pp.ru> Message-ID: <20070725102203.D20275@thor.farley.org> References: <200707251733.12658.doconnor@gsoft.com.au> <20070725084755.GA75871@nagual.pp.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.1 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on mail.farley.org Cc: freebsd-current@FreeBSD.org, sergei@FreeBSD.org Subject: Re: zsh oddities with recent -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, 25 Jul 2007 15:27:43 -0000 On Wed, 25 Jul 2007, Andrey Chernov wrote: > On Wed, Jul 25, 2007 at 05:33:05PM +0930, Daniel O'Connor wrote: >> I updated my -current box (laptop) on the 18th and I have 2 strange >> issues with zsh. >> >> 1) I can't unset environmental variables set before the shell >> started, eg.. > > zsh uses system's putenv() but home-rolled delete from environment > (instead of unsetenv()). It clearly violates POSIX since it forbids to > mix putenv/setenv/unsetenv with direct environ manipulations: > > "Conforming applications are required not to modify environ directly, > but to use only the functions described here to manipulate the process > environment as an abstract object. Thus, the implementation of the > environment access functions has complete control over the data > structure used to represent the environment (subject to the > requirement that environ be maintained as a list of strings with > embedded equal signs for applications that wish to scan the > environment). This constraint allows the implementation to properly > manage the memory it allocates, either by using allocated storage for > all variables (copying them on the first invocation of setenv() or > unsetenv()), or keeping track of which strings are currently in > allocated space and which are not, via a separate table or some other > means." > > Quick fix will be just to disable HAVE_PUTENV config option. It gains > nothing in the code but makes troubles. I reported the bug to the zsh development list. As of v4.3.4 of zsh, the issue is still there. Sean -- scf@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Wed Jul 25 16:03:07 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 DDF7716A41A; Wed, 25 Jul 2007 16:03:07 +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 8E89C13C469; Wed, 25 Jul 2007 16:03:07 +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 1IDjKP-000NcO-DR; Wed, 25 Jul 2007 20:03:09 +0400 Received: from bsam by ipt.ru with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1IDjKX-000BSm-7S; Wed, 25 Jul 2007 20:03:17 +0400 To: Pawel Jakub Dawidek References: <97732929@srv.sem.ipt.ru> <20070723133333.GF5456@garage.freebsd.pl> <78011660@srv.sem.ipt.ru> <20070724144549.GA12473@garage.freebsd.pl> <08401633@srv.sem.ipt.ru> <20070725145031.GJ12473@garage.freebsd.pl> <76240598@srv.sem.ipt.ru> <20070725151235.GK12473@garage.freebsd.pl> From: Boris Samorodov Date: Wed, 25 Jul 2007 20:03:17 +0400 In-Reply-To: <20070725151235.GK12473@garage.freebsd.pl> (Pawel Jakub Dawidek's message of "Wed\, 25 Jul 2007 17\:12\:35 +0200") Message-ID: <10167018@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-current@FreeBSD.org Subject: Re: mount_nullfs inside a jail X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Jul 2007 16:03:08 -0000 On Wed, 25 Jul 2007 17:12:35 +0200 Pawel Jakub Dawidek wrote: > On Wed, Jul 25, 2007 at 07:03:37PM +0400, Boris Samorodov wrote: > > > > This didn't help: > > > > ----- > > > > btest# sysctl security.jail > > > > security.jail.jailed: 1 > > > > security.jail.mount_allowed: 1 > > > > security.jail.chflags_allowed: 1 > > > > security.jail.allow_raw_sockets: 0 > > > > security.jail.enforce_statfs: 2 > > > > security.jail.sysvipc_allowed: 1 > > > > security.jail.socket_unixiproute_only: 1 > > > > security.jail.set_hostname_allowed: 1 > > > > btest# lsvfs > > > > Filesystem Refs Flags > > > > -------------------------------- ----- --------------- > > > > ufs 6 > > > > nfs 0 network > > > > procfs 0 synthetic > > > > devfs 3 synthetic > > > > ntfs 0 > > > > msdosfs 0 > > > > nfs4 0 network > > > > nullfs 1 loopback, jail > > > > cd9660 0 read-only > > > > btest# df > > > > Filesystem 1K-blocks Used Avail Capacity Mounted on > > > > /dev/da0s1d 945804208 22136782 848003090 3% / > > > > btest# mount /usr/ports/distfiles /mnt > > > > mount: /usr/ports/distfiles : Operation not permitted > > > > > mount_nullfs? > > > > Ops!!! (i need some coffee) My bad... Mounting works good but: > > ----- > > btest# umount /mnt > > umount: unmount of [restricted] failed: Invalid argument > > ----- > I overlooked. You need to set security.jail.enforce_statfs to 0. See if > that helps. Yep, that helps. But now "df" now shows a host file system, which is a little bit confusing. ;-) Well, but I guess there should be a consensus somewhere between features and wishes... Pawel, thanks for your help. 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 Wed Jul 25 16: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 542A216A419; Wed, 25 Jul 2007 16:10:30 +0000 (UTC) (envelope-from bp@barryp.org) Received: from eden.barryp.org (host-42-60-230-24.midco.net [24.230.60.42]) by mx1.freebsd.org (Postfix) with ESMTP id 29F9013C461; Wed, 25 Jul 2007 16:10:30 +0000 (UTC) (envelope-from bp@barryp.org) Received: from geo.med.und.nodak.edu ([134.129.166.11]) by eden.barryp.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1IDiqz-0002J5-NW; Wed, 25 Jul 2007 10:32:45 -0500 Message-ID: <46A76CF6.8030304@barryp.org> Date: Wed, 25 Jul 2007 10:32:06 -0500 From: Barry Pederson User-Agent: Thunderbird 1.5.0.12 (X11/20070509) MIME-Version: 1.0 To: Dmitry Morozovsky References: <20070725190506.T18411@woozle.rinet.ru> In-Reply-To: <20070725190506.T18411@woozle.rinet.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Pawel Jakub Dawidek , current@FreeBSD.org Subject: Re: ZFS on root: slave mountpoints mount failed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Jul 2007 16:10:30 -0000 Dmitry Morozovsky wrote: > Hi there, > > I'm start to play with ZFS-on-root on my notebook according to wiki and found > strange error > > I created zfs and changed ist mount point to legacy as instructed. Then I > create pool/usr, pool/usr/ports and so on, and then change mount point of > pool/usr to /usr. So far so good. > > But, after reboot, pool/usr is not mounted, and I can see no simple way to > mount it automatically (yes, `zfs mount -a' seems to work, but it looks like > ugly hack). > > Any hints? You have zfs_enable="YES" in your /etc/rc.conf ? Barry From owner-freebsd-current@FreeBSD.ORG Wed Jul 25 16:26:27 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 5DBDF16A417; Wed, 25 Jul 2007 16:26:27 +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 D176A13C467; Wed, 25 Jul 2007 16:26:26 +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 l6PGQ0br030791; Wed, 25 Jul 2007 20:26:00 +0400 (MSD) (envelope-from marck@rinet.ru) Date: Wed, 25 Jul 2007 20:26:00 +0400 (MSD) From: Dmitry Morozovsky To: Barry Pederson In-Reply-To: <46A76CF6.8030304@barryp.org> Message-ID: <20070725201514.H18411@woozle.rinet.ru> References: <20070725190506.T18411@woozle.rinet.ru> <46A76CF6.8030304@barryp.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]); Wed, 25 Jul 2007 20:26:01 +0400 (MSD) Cc: Pawel Jakub Dawidek , current@FreeBSD.org Subject: Re: ZFS on root: slave mountpoints mount failed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Jul 2007 16:26:27 -0000 On Wed, 25 Jul 2007, Barry Pederson wrote: BP> > I'm start to play with ZFS-on-root on my notebook according to wiki and BP> > found strange error BP> > BP> > I created zfs and changed ist mount point to legacy as instructed. Then I BP> > create pool/usr, pool/usr/ports and so on, and then change mount point of BP> > pool/usr to /usr. So far so good. BP> > But, after reboot, pool/usr is not mounted, and I can see no simple way to BP> > mount it automatically (yes, `zfs mount -a' seems to work, but it looks BP> > like ugly hack). BP> > BP> > Any hints? BP> BP> You have BP> BP> zfs_enable="YES" BP> BP> in your /etc/rc.conf ? Ouch! I did, but tere was a typo in this line, which I overlooked. Thanks, and sorry for the noise! The only thing which seems not documented is need for zfs set org.freebsd:swap=on pool/swap once zvol is created Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Wed Jul 25 17:08: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 80BA516A418 for ; Wed, 25 Jul 2007 17:08:37 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.freebsd.org (Postfix) with ESMTP id 1F4C813C45E for ; Wed, 25 Jul 2007 17:08:36 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id B5026487F3; Wed, 25 Jul 2007 19:08:35 +0200 (CEST) Received: from localhost (154.81.datacomsa.pl [195.34.81.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 606AB45685; Wed, 25 Jul 2007 19:08:30 +0200 (CEST) Date: Wed, 25 Jul 2007 19:07:53 +0200 From: Pawel Jakub Dawidek To: Dmitry Morozovsky Message-ID: <20070725170753.GM12473@garage.freebsd.pl> References: <20070725190506.T18411@woozle.rinet.ru> <46A76CF6.8030304@barryp.org> <20070725201514.H18411@woozle.rinet.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qDymnuGqqhW10CwH" Content-Disposition: inline In-Reply-To: <20070725201514.H18411@woozle.rinet.ru> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-2.6 required=3.0 tests=BAYES_00 autolearn=ham version=3.0.4 Cc: current@FreeBSD.org Subject: Re: ZFS on root: slave mountpoints mount failed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Jul 2007 17:08:37 -0000 --qDymnuGqqhW10CwH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 25, 2007 at 08:26:00PM +0400, Dmitry Morozovsky wrote: > On Wed, 25 Jul 2007, Barry Pederson wrote: >=20 > BP> > I'm start to play with ZFS-on-root on my notebook according to wiki= and > BP> > found strange error > BP> >=20 > BP> > I created zfs and changed ist mount point to legacy as instructed. = Then I > BP> > create pool/usr, pool/usr/ports and so on, and then change mount po= int of > BP> > pool/usr to /usr. So far so good.=20 > BP> > But, after reboot, pool/usr is not mounted, and I can see no simple= way to > BP> > mount it automatically (yes, `zfs mount -a' seems to work, but it l= ooks > BP> > like ugly hack). > BP> >=20 > BP> > Any hints? > BP>=20 > BP> You have > BP>=20 > BP> zfs_enable=3D"YES" > BP>=20 > BP> in your /etc/rc.conf ? >=20 > Ouch! I did, but tere was a typo in this line, which I overlooked. >=20 > Thanks, and sorry for the noise! >=20 > The only thing which seems not documented is need for=20 > zfs set org.freebsd:swap=3Don pool/swap > once zvol is created You can do it as usual via /etc/fstab, but yet, we do need to document ZFS on FreeBSD in our handbook. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --qDymnuGqqhW10CwH Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFGp4NpForvXbEpPzQRAlpKAJ99Y0mKgbNQDbt4RoIktAQCHdFT1QCeJRd+ oIta+HqKYxgCHu7dlCZxvuA= =zWvC -----END PGP SIGNATURE----- --qDymnuGqqhW10CwH-- From owner-freebsd-current@FreeBSD.ORG Wed Jul 25 17:11:59 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 6142916A46C; Wed, 25 Jul 2007 17:11:59 +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 D7E9713C467; Wed, 25 Jul 2007 17:11:58 +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 l6PHBvho031683; Wed, 25 Jul 2007 21:11:57 +0400 (MSD) (envelope-from marck@rinet.ru) Date: Wed, 25 Jul 2007 21:11:57 +0400 (MSD) From: Dmitry Morozovsky To: Pawel Jakub Dawidek In-Reply-To: <20070725170753.GM12473@garage.freebsd.pl> Message-ID: <20070725211102.V18411@woozle.rinet.ru> References: <20070725190506.T18411@woozle.rinet.ru> <46A76CF6.8030304@barryp.org> <20070725201514.H18411@woozle.rinet.ru> <20070725170753.GM12473@garage.freebsd.pl> 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, 25 Jul 2007 21:11:57 +0400 (MSD) Cc: current@freebsd.org Subject: Re: ZFS on root: slave mountpoints mount failed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Jul 2007 17:11:59 -0000 On Wed, 25 Jul 2007, Pawel Jakub Dawidek wrote: PJD> > The only thing which seems not documented is need for PJD> > zfs set org.freebsd:swap=on pool/swap PJD> > once zvol is created PJD> PJD> You can do it as usual via /etc/fstab, but yet, we do need to document PJD> ZFS on FreeBSD in our handbook. Nope, I tried this, and swapon tried to run before zfs and failed. Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Wed Jul 25 17:14: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 AE36316A468 for ; Wed, 25 Jul 2007 17:14:52 +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 2225C13C467 for ; Wed, 25 Jul 2007 17:14:51 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 16375 invoked from network); 25 Jul 2007 17:10:12 -0000 Received: from dotat.atdotat.at (HELO [62.48.0.47]) ([62.48.0.47]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 25 Jul 2007 17:10:12 -0000 Message-ID: <46A7850A.3070408@freebsd.org> Date: Wed, 25 Jul 2007 19:14:50 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b) Gecko/20050217 MIME-Version: 1.0 To: "Bruce M. Simpson" References: <46A766E3.1080605@incunabulum.net> In-Reply-To: <46A766E3.1080605@incunabulum.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: Call for testers: NetBSD IGMPv2 merge X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Jul 2007 17:14:52 -0000 Bruce M. Simpson wrote: > Hi, > > I have mostly merged NetBSD's IGMPv2 implementation with a few refinements. > This work is being funded by a secret santa. :-) > > This code is easier to read (and thus maintain), and fixes a minor > memory leak in the IPv4 stack. It is also a jumping off point for the > IGMPv3 work. KAME patch sets up to date have been against NetBSD, though > I don't intend to use their patches directly. > > Patch against -CURRENT, URL: > http://people.freebsd.org/~bms/dump/igmp-netbsd-sync.patch > > I have not merged the change which suppresses host membership reports > for the link-local multicast scope space 224.0.0.0/8, my concern is that > this breaks IGMP snooping switches on immediately attached layer 2 > networks, even though this range is not globally routable. (*) > > Testing and review much appreciated. If enough people are willing to > soak test this code before 7.0 point release is branched then it might > justify going in in time for 7.0. Looks good. Not tested though. -- Andre From owner-freebsd-current@FreeBSD.ORG Wed Jul 25 17:29: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 06ABC16A468 for ; Wed, 25 Jul 2007 17:29: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 9671513C461 for ; Wed, 25 Jul 2007 17:29:17 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 4549 invoked by uid 399); 25 Jul 2007 17:29:16 -0000 Received: from localhost (HELO lap.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTP; 25 Jul 2007 17:29:16 -0000 X-Originating-IP: 127.0.0.1 Message-ID: <46A7886A.5000600@FreeBSD.org> Date: Wed, 25 Jul 2007 10:29:14 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.5 (X11/20070723) MIME-Version: 1.0 To: Nicolas Haller References: <20070725121741.GE28450@boiteameuh.org> In-Reply-To: <20070725121741.GE28450@boiteameuh.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: Interrupt storm on atapci1+ X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-current@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, 25 Jul 2007 17:29:18 -0000 Nicolas Haller wrote: > Hi all, > > I currently running a FreeBSD-CURRENT on a Intel Core 2 Duo and I seem I > have a interrupt storm which take approximately 90% of a CPU. > > This is the vmstat -i > nicolas@marcellus:~%vmstat -i > interrupt total rate > irq1: atkbd0 2508 0 > irq17: mskc0 133918 6 > irq19: fwohci0+ 8288 0 > irq22: atapci1+ 1174121373 61321 > irq23: uhci3 ehci1 1 0 > cpu0: timer 38250554 1997 > cpu1: timer 38240647 1997 > Total 1250757289 65323 > > I give you my kernel conf. > > I don't really know what informations can be useful so feel free to ask > anything you need. Make and model of the system would be a good start, along with the output of 'grep -i irq /var/run/dmesg.boot' Doug -- This .signature sanitized for your protection From owner-freebsd-current@FreeBSD.ORG Wed Jul 25 18:28: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 7B58816A419 for ; Wed, 25 Jul 2007 18:28:19 +0000 (UTC) (envelope-from amoran@forsythia.net) Received: from celebrian.forsythia.net (celebrian.forsythia.net [64.142.54.200]) by mx1.freebsd.org (Postfix) with ESMTP id 410FF13C45D for ; Wed, 25 Jul 2007 18:28:19 +0000 (UTC) (envelope-from amoran@forsythia.net) Received: from [17.218.13.103] ([17.218.13.103]) (authenticated bits=0) by celebrian.forsythia.net (8.13.8/8.13.8) with ESMTP id l6PI1NtR073785 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 25 Jul 2007 11:01:23 -0700 (PDT) (envelope-from amoran@forsythia.net) 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: freebsd-current@freebsd.org From: Andrew Moran Date: Wed, 25 Jul 2007 11:00:50 -0700 X-Mailer: Apple Mail (2.752.3) Subject: FreeBSD on intel Mac X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Jul 2007 18:28:19 -0000 Is it the case that I can install and boot freebsd on an intel mac (uses EFI, not BIOS) currently (without using Boot Camp), or do I have to wait until FreeBSD 7 for this functionality? --Andy From owner-freebsd-current@FreeBSD.ORG Wed Jul 25 20:07: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 7648A16A417 for ; Wed, 25 Jul 2007 20:07:20 +0000 (UTC) (envelope-from flo@kasimir.com) Received: from config.solomo.org (kasimir.com [85.214.51.166]) by mx1.freebsd.org (Postfix) with ESMTP id DE8DF13C45E for ; Wed, 25 Jul 2007 20:07:19 +0000 (UTC) (envelope-from flo@kasimir.com) Received: (qmail 59484 invoked from network); 25 Jul 2007 21:40:38 +0200 Received: from i5387a4c3.versanet.de (HELO nibbler-osx.local) (83.135.164.195) by kasimir.com with SMTP; 25 Jul 2007 21:40:37 +0200 Message-ID: <46A7A734.3040108@kasimir.com> Date: Wed, 25 Jul 2007 21:40:36 +0200 From: "Florian C. Smeets" User-Agent: Thunderbird 2.0.0.6pre (Macintosh/20070724) MIME-Version: 1.0 To: current@freebsd.org X-Enigmail-Version: 0.95.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: page fault in g_event (probably zfs related?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Jul 2007 20:07:20 -0000 Hi, i had a working zpool which consisted of only 1 drive (ad6), then i added another drive (da1) to it and the zpool increased in size as expected. Every thing worked fine until i had to reboot the system. Now every time after the da1 disk is probed i get this: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x3f80 fault code = supervisor read, page not present instruction pointer = 0x20:0xc073bfe4 stack pointer = 0x28:0xd17aab60 frame pointer = 0x28:0xd17aac58 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 2 (g_event) [thread pid 2 tid 100012 ] Stopped at bcmp+0x14: repe cmpsl (%esi),%es:(%edi) db> where Tracing pid 2 tid 100012 td 0xc27f1aa0 bcmp(c2e28e00,c2acc280,c07b5138,0,c296acd8,...) at bcmp+0x14 g_part_taste(c07b5040,c296ac80,0,c2af2900,0,...) at g_part_taste+0x1e3 g_new_provider_event(c296ac80,0,0,0,ffffffff,...) at g_new_provider_event+0x64 g_run_events(c07f1d00,0,4c,c077c981,64,...) at g_run_events+0x2b5 g_event_procbody(0,d17aad38,0,0,0,...) at g_event_procbody+0x6b fork_exit(c0542a30,0,d17aad38) at fork_exit+0x99 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xd17aad70, ebp = 0 --- ad6 is an ATA drive connected to an internal ATA Controller: ad6: 239372MB at ata3-master UDMA66 da1 is an SATA drive in an external USB enclosure: umass0: on uhub0 da1 at umass-sim0 bus 0 target 0 lun 0 da1: Fixed Direct Access SCSI-2 device da1: 1.000MB/s transfers da1: 114473MB (234441648 512 byte sectors: 255H 63S/T 14593C) The system is a 2 CPU SMP system running -CURRENT as of yesterday. I'll leave the system in this state in case anyone would like to have additional information from the debugger. Cheers, Flo From owner-freebsd-current@FreeBSD.ORG Wed Jul 25 20: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 B96C616A418 for ; Wed, 25 Jul 2007 20:08:01 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from sippysoft.com (gk.360sip.com [72.236.70.226]) by mx1.freebsd.org (Postfix) with ESMTP id 7467813C442 for ; Wed, 25 Jul 2007 20:08:01 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from [192.168.0.61] ([204.244.149.125]) (authenticated bits=0) by sippysoft.com (8.13.8/8.13.8) with ESMTP id l6PJaBMM064049 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 25 Jul 2007 12:36:12 -0700 (PDT) (envelope-from sobomax@FreeBSD.org) Message-ID: <46A7A620.5000604@FreeBSD.org> Date: Wed, 25 Jul 2007 12:36:00 -0700 From: Maxim Sobolev Organization: Sippy Software, Inc. User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: "current@freebsd.org" Content-Type: text/plain; charset=KOI8-U; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: installworld breaks my FreeBSD/powerpc system!!! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2007 20:08:01 -0000 It seems that installworld from yesterday sources severely corrupted my 7-CURRENT FreeBSD/ppc installation. :( I believe this is caused by the recent libc changes that go together with dynamic linker changes, but since dynamic linker is installed *after* libc in installworld process, one who does source upgrade ends up with broken system containing old dynamic linker, while new libc after installworld explodes! :((( To add insult to injury, the su is not present in /rescue and sudo is dynamically linked as well, so that the only way to recover is to go to the console and boot into single user.... -Maxim -------------------------------------------------------------- >>> Installing everything -------------------------------------------------------------- cd /usr/src; /usr/obj/usr/src/make.powerpc/make -f Makefile.inc1 install ===> share/info (install) ===> lib (install) ===> lib/csu/powerpc (install) install -o root -g wheel -m 444 crt1.o crti.o crtn.o gcrt1.o /usr/lib ===> lib/libc (install) install -C -o root -g wheel -m 444 libc.a /usr/lib install -C -o root -g wheel -m 444 libc_p.a /usr/lib install -s -o root -g wheel -m 444 -fschg -S libc.so.7 /lib BFD: /lib/stpHZVgV: warning: allocated section `.hash' not in segment BFD: /lib/stpHZVgV: warning: allocated section `.dynsym' not in segment BFD: /lib/stpHZVgV: warning: allocated section `.dynstr' not in segment BFD: /lib/stpHZVgV: warning: allocated section `.gnu.version' not in segment BFD: /lib/stpHZVgV: warning: allocated section `.gnu.version_d' not in segment BFD: /lib/stpHZVgV: warning: allocated section `.rela.dyn' not in segment BFD: /lib/stpHZVgV: warning: allocated section `.rela.plt' not in segment BFD: /lib/stpHZVgV: warning: allocated section `.init' not in segment BFD: /lib/stpHZVgV: warning: allocated section `.text' not in segment BFD: /lib/stpHZVgV: warning: allocated section `.fini' not in segment BFD: /lib/stpHZVgV: warning: allocated section `.rodata' not in segment BFD: /lib/stpHZVgV: warning: allocated section `.data' not in segment BFD: /lib/stpHZVgV: warning: allocated section `.tbss' not in segment BFD: /lib/stpHZVgV: warning: allocated section `.eh_frame' not in segment BFD: /lib/stpHZVgV: warning: allocated section `.dynamic' not in segment BFD: /lib/stpHZVgV: warning: allocated section `.ctors' not in segment BFD: /lib/stpHZVgV: warning: allocated section `.dtors' not in segment BFD: /lib/stpHZVgV: warning: allocated section `.jcr' not in segment BFD: /lib/stpHZVgV: warning: allocated section `.got' not in segment BFD: /lib/stpHZVgV: warning: allocated section `.sdata2' not in segment BFD: /lib/stpHZVgV: warning: allocated section `.sdata' not in segment BFD: /lib/stpHZVgV: warning: allocated section `.sbss' not in segment BFD: /lib/stpHZVgV: warning: allocated section `.plt' not in segment BFD: /lib/stpHZVgV: warning: allocated section `.bss' not in segment ln -fs /lib/libc.so.7 /usr/lib/libc.so /libexec/ld-elf.so.1: /lib/libc.so.7: object is not dynamically-linked *** Error code 1 Stop in /usr/src/lib/libc. *** Error code 1 Stop in /usr/src/lib. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. [sobomax@sobomac /usr/src]$ ls -l /lib/libc.so.7 /libexec/ld-elf.so.1: /lib/libc.so.7: object is not dynamically-linked [sobomax@sobomac /usr/src]$ uname -a /libexec/ld-elf.so.1: /lib/libc.so.7: object is not dynamically-linked From owner-freebsd-current@FreeBSD.ORG Wed Jul 25 19:31: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 4783816A418 for ; Wed, 25 Jul 2007 19:31:40 +0000 (UTC) (envelope-from hartzell@alerce.com) Received: from merlin.alerce.com (merlin.alerce.com [64.62.142.94]) by mx1.freebsd.org (Postfix) with ESMTP id 2D86813C474 for ; Wed, 25 Jul 2007 19:31:39 +0000 (UTC) (envelope-from hartzell@alerce.com) Received: from merlin.alerce.com (localhost [127.0.0.1]) by merlin.alerce.com (Postfix) with ESMTP id DFD5833C62; Wed, 25 Jul 2007 12:11:11 -0700 (PDT) Received: from postfix.alerce.com (w092.z064001164.sjc-ca.dsl.cnc.net [64.1.164.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "satchel.alerce.com", Issuer "alerce.com" (verified OK)) by merlin.alerce.com (Postfix) with ESMTP id 57CC933C5D; Wed, 25 Jul 2007 12:11:11 -0700 (PDT) Received: by postfix.alerce.com (Postfix, from userid 501) id DCA3F112550; Wed, 25 Jul 2007 12:11:06 -0700 (PDT) From: George Hartzell MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18087.41034.817186.693348@almost.alerce.com> Date: Wed, 25 Jul 2007 12:11:06 -0700 To: Andrew Moran In-Reply-To: References: X-Mailer: VM 7.19 under Emacs 22.1.1 X-Virus-Scanned: ClamAV using ClamSMTP X-Mailman-Approved-At: Wed, 25 Jul 2007 20:10:26 +0000 Cc: freebsd-current@freebsd.org Subject: Re: FreeBSD on intel Mac X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hartzell@alerce.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, 25 Jul 2007 19:31:40 -0000 Andrew Moran writes: > > Is it the case that I can install and boot freebsd on an intel mac > (uses EFI, not BIOS) currently (without using Boot Camp), or do I > have to wait until FreeBSD 7 for this functionality? Boot Camp seems to be a marketing term, I still haven't figured out what various people mean when they use the term. Is it the assistant? The windows driver CD? Here's what I did to run FreeBSD on a mac pro. I started with a default Mac OS X installation from my distribution DVD onto a virgin disk 500MB disk. Then I downloaded bootcamp and ran the boot camp assistant. I let it resize the mac partition (I made it as small as possible) and then gave it a freebsd -stable amd64 CD to install from. After running through the install, you'll end up booted back into the minimal mac os x installation. Then I downloaded and installed refit into the root and ran it's enable shell script. Now, if I hold down the option key as the machine powers up, I'm offered the choice of booting my "real" os x install on a different disk or refit (oddly, it asks me about booting windows, I've never tried it). When I choose refit, it gives me a couple of things to boot from, including either of the mac installs or my freebsd system. I think that if I run refit's enable-always shell script, I can avoid the option key trick and possibly just boot into freebsd by default, but I haven't explored that option. g. From owner-freebsd-current@FreeBSD.ORG Wed Jul 25 20:08: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 56A2516A419 for ; Wed, 25 Jul 2007 20:08:02 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from sippysoft.com (gk.360sip.com [72.236.70.226]) by mx1.freebsd.org (Postfix) with ESMTP id 1135D13C459 for ; Wed, 25 Jul 2007 20:08:01 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from [192.168.0.61] ([204.244.149.125]) (authenticated bits=0) by sippysoft.com (8.13.8/8.13.8) with ESMTP id l6PJZY4O064020 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 25 Jul 2007 12:35:35 -0700 (PDT) (envelope-from sobomax@sippysoft.com) Message-ID: <46A7A5FB.90203@sippysoft.com> Date: Wed, 25 Jul 2007 12:35:23 -0700 From: Maxim Sobolev Organization: Sippy Software User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: "current@freebsd.org" Content-Type: text/plain; charset=KOI8-U; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 25 Jul 2007 20:10:26 +0000 Cc: Subject: installworld breaks my FreeBSD/powerpc system!!! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2007 20:08:02 -0000 It seems that installworld from yesterday sources severely corrupted my 7-CURRENT FreeBSD/ppc installation. :( I believe this is caused by the recent libc changes that go together with dynamic linker changes, but since dynamic linker is installed *after* libc in installworld process, one who does source upgrade ends up with broken system containing old dynamic linker, while new libc after installworld explodes! :((( To add insult to injury, the su is not present in /rescue and sudo is dynamically linked as well, so that the only way to recover is to go to the console and boot into single user.... -Maxim -------------------------------------------------------------- >>> Installing everything -------------------------------------------------------------- cd /usr/src; /usr/obj/usr/src/make.powerpc/make -f Makefile.inc1 install ===> share/info (install) ===> lib (install) ===> lib/csu/powerpc (install) install -o root -g wheel -m 444 crt1.o crti.o crtn.o gcrt1.o /usr/lib ===> lib/libc (install) install -C -o root -g wheel -m 444 libc.a /usr/lib install -C -o root -g wheel -m 444 libc_p.a /usr/lib install -s -o root -g wheel -m 444 -fschg -S libc.so.7 /lib BFD: /lib/stpHZVgV: warning: allocated section `.hash' not in segment BFD: /lib/stpHZVgV: warning: allocated section `.dynsym' not in segment BFD: /lib/stpHZVgV: warning: allocated section `.dynstr' not in segment BFD: /lib/stpHZVgV: warning: allocated section `.gnu.version' not in segment BFD: /lib/stpHZVgV: warning: allocated section `.gnu.version_d' not in segment BFD: /lib/stpHZVgV: warning: allocated section `.rela.dyn' not in segment BFD: /lib/stpHZVgV: warning: allocated section `.rela.plt' not in segment BFD: /lib/stpHZVgV: warning: allocated section `.init' not in segment BFD: /lib/stpHZVgV: warning: allocated section `.text' not in segment BFD: /lib/stpHZVgV: warning: allocated section `.fini' not in segment BFD: /lib/stpHZVgV: warning: allocated section `.rodata' not in segment BFD: /lib/stpHZVgV: warning: allocated section `.data' not in segment BFD: /lib/stpHZVgV: warning: allocated section `.tbss' not in segment BFD: /lib/stpHZVgV: warning: allocated section `.eh_frame' not in segment BFD: /lib/stpHZVgV: warning: allocated section `.dynamic' not in segment BFD: /lib/stpHZVgV: warning: allocated section `.ctors' not in segment BFD: /lib/stpHZVgV: warning: allocated section `.dtors' not in segment BFD: /lib/stpHZVgV: warning: allocated section `.jcr' not in segment BFD: /lib/stpHZVgV: warning: allocated section `.got' not in segment BFD: /lib/stpHZVgV: warning: allocated section `.sdata2' not in segment BFD: /lib/stpHZVgV: warning: allocated section `.sdata' not in segment BFD: /lib/stpHZVgV: warning: allocated section `.sbss' not in segment BFD: /lib/stpHZVgV: warning: allocated section `.plt' not in segment BFD: /lib/stpHZVgV: warning: allocated section `.bss' not in segment ln -fs /lib/libc.so.7 /usr/lib/libc.so /libexec/ld-elf.so.1: /lib/libc.so.7: object is not dynamically-linked *** Error code 1 Stop in /usr/src/lib/libc. *** Error code 1 Stop in /usr/src/lib. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. [sobomax@sobomac /usr/src]$ ls -l /lib/libc.so.7 /libexec/ld-elf.so.1: /lib/libc.so.7: object is not dynamically-linked [sobomax@sobomac /usr/src]$ uname -a /libexec/ld-elf.so.1: /lib/libc.so.7: object is not dynamically-linked From owner-freebsd-current@FreeBSD.ORG Wed Jul 25 20:37: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 41D6216A420 for ; Wed, 25 Jul 2007 20:37:22 +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 2477113C46B for ; Wed, 25 Jul 2007 20:37:22 +0000 (UTC) (envelope-from stevenschlansker@berkeley.edu) Received: from h-74-1-188-242.snfccasy.covad.net ([74.1.188.242] helo=[192.168.1.88]) by fe4.calmail with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (auth plain:stevenschlansker@berkeley.edu) (envelope-from ) id 1IDnbl-0007X8-G6 for freebsd-current@freebsd.org; Wed, 25 Jul 2007 13:37:22 -0700 Message-ID: <46A7B47F.3050300@berkeley.edu> Date: Wed, 25 Jul 2007 13:37:19 -0700 From: Steven Schlansker User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Are SATA port multipliers supported 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, 25 Jul 2007 20:37:22 -0000 Hello everyone, I am considering buying a SiI 3132 SATA card along with a 5-1 port multiplier. I'm trying to see if FreeBSD supports such a configuration, but the only reference found to port multipliers and FreeBSD was some poor, lonely man asking about a "porn multiplier" crashing his system on startup. :-p The thread trailed off quickly, without resolution. So my question is: Are port multipliers supported in CURRENT? Are there any caveats? I don't see anything in UPDATING, the handbook, or our friend Google. I want to check that it is supported before I drop $80 on it :) Thanks a bunch! Steven From owner-freebsd-current@FreeBSD.ORG Wed Jul 25 20:44:02 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 4E04D16A419 for ; Wed, 25 Jul 2007 20:44:02 +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 F1CAB13C458 for ; Wed, 25 Jul 2007 20:44:01 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.samsco.home (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.8/8.13.8) with ESMTP id l6PKhuKt014447; Wed, 25 Jul 2007 14:43:57 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <46A7B607.2070207@samsco.org> Date: Wed, 25 Jul 2007 14:43:51 -0600 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: Steven Schlansker References: <46A7B47F.3050300@berkeley.edu> In-Reply-To: <46A7B47F.3050300@berkeley.edu> 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, 25 Jul 2007 14:43:57 -0600 (MDT) X-Spam-Status: No, score=-1.4 required=5.5 tests=ALL_TRUSTED autolearn=failed version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: freebsd-current@freebsd.org Subject: Re: Are SATA port multipliers supported 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, 25 Jul 2007 20:44:02 -0000 Steven Schlansker wrote: > Hello everyone, > I am considering buying a SiI 3132 SATA card along with a 5-1 port > multiplier. I'm trying to see if FreeBSD supports such a configuration, > but the only reference found to port multipliers and FreeBSD was some > poor, lonely man asking about a "porn multiplier" crashing his system on > startup. :-p > The thread trailed off quickly, without resolution. > > So my question is: Are port multipliers supported in CURRENT? Are > there any caveats? I don't see anything in UPDATING, the handbook, or > our friend Google. I want to check that it is supported before I drop > $80 on it :) Thanks a bunch! > Steven They are only supported at the moment by controllers that are intelligent enough to hide the details of how they work from the OS. The SiI family probably doesn't fall into this category. I'm working on this as part of a larger SATA/SAS/SCSI/FC overhaul, but it'll be a few months before there are any results. Scott From owner-freebsd-current@FreeBSD.ORG Wed Jul 25 20: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 5902A16A418 for ; Wed, 25 Jul 2007 20:52:16 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.174]) by mx1.freebsd.org (Postfix) with ESMTP id 3C6F213C45A for ; Wed, 25 Jul 2007 20:52:16 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from mac.com (smtpin05-en2 [10.13.10.150]) by smtpout.mac.com (Xserve/smtpout04/MantshX 4.0) with ESMTP id l6PKOIrV006356; Wed, 25 Jul 2007 13:24:18 -0700 (PDT) Received: from [172.24.104.85] (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by mac.com (Xserve/smtpin05/MantshX 4.0) with ESMTP id l6PKOGBT004558 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 25 Jul 2007 13:24:16 -0700 (PDT) In-Reply-To: <46A7A5FB.90203@sippysoft.com> References: <46A7A5FB.90203@sippysoft.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5865861B-E29E-451C-B07B-B52028549F50@mac.com> Content-Transfer-Encoding: 7bit From: Marcel Moolenaar Date: Wed, 25 Jul 2007 13:23:25 -0700 To: Maxim Sobolev X-Mailer: Apple Mail (2.752.3) X-Brightmail-Tracker: AAAAAA== X-Brightmail-scanned: yes Cc: "current@freebsd.org" Subject: Re: installworld breaks my FreeBSD/powerpc system!!! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2007 20:52:16 -0000 On Jul 25, 2007, at 12:35 PM, Maxim Sobolev wrote: > It seems that installworld from yesterday sources severely > corrupted my 7-CURRENT FreeBSD/ppc installation. :( > > I believe this is caused by the recent libc changes that go > together with dynamic linker changes, but since dynamic linker is > installed *after* libc in installworld process, one who does source > upgrade ends up with broken system containing old dynamic linker, > while new libc after installworld explodes! :((( I think it's a mmap(2) problem, rather than a libc/ld-elf problem. I suspect that the peter@'s change to not align arguments is causing the problem. It's difficult to analyze because I don't trust the output of truss and ktrace anymore in this case: the file offset argument is garbage according to those tools. The file offset is garbage on all platforms, not just PowerPC :-/ Other signs of mmap problems: dhclient complaining about a corrupted lease file and rpc.statd complaining about an invalid database file... Unfortunately, I don't have the time to look into it right now. FYI, -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Wed Jul 25 20:52:35 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 5458916A417; Wed, 25 Jul 2007 20:52:35 +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 B3BC813C4A5; Wed, 25 Jul 2007 20:52:34 +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 l6PKqX5a034878; Thu, 26 Jul 2007 00:52:33 +0400 (MSD) (envelope-from marck@rinet.ru) Date: Thu, 26 Jul 2007 00:52:33 +0400 (MSD) From: Dmitry Morozovsky To: Pawel Jakub Dawidek Message-ID: <20070725234322.G33266@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]); Thu, 26 Jul 2007 00:52:33 +0400 (MSD) Cc: current@FreeBSD.org Subject: ZFS on a notebook/512M settings X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Jul 2007 20:52:35 -0000 Hi there colleagues, I want to join the 'eating our own dogfood' company using ZFS on my notebook. However, it is armed with only 512M of RAM. What are tunings which would possibly keep it from panicing? For now, I've got in /boot/loader.conf: vfs.zfs.prefetch_disable="1" vfs.zfs.zil_disable="1" should I tune vm.* and/or other loader tunables? Thanks in advance... Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Wed Jul 25 20:50:56 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 B671716A418 for ; Wed, 25 Jul 2007 20:50:56 +0000 (UTC) (envelope-from braun.sven@googlemail.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 453EC13C458 for ; Wed, 25 Jul 2007 20:50:56 +0000 (UTC) (envelope-from braun.sven@googlemail.com) Received: by ug-out-1314.google.com with SMTP id o4so464507uge for ; Wed, 25 Jul 2007 13:50:55 -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=R9Kge7AVKEWlm8Ou3YzSmuM3Epc69hZrJ/C3DrQlx+IvV/J1Y6OoGmitM95x4raMXWuXkm8nnxlN8s2jclyLHvvdxzqJrDW1qKH56gPBRiujszbFMTXMxcfYunE1gZc34xKUMi7+xwnnxyoEdtYWesp4/y6uGrEwAGjk1INhX30= 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=P4xSgDHWJm+F+Kti/0dUjaY3l5tUyQxSfHuxMLLSGIQezLpQKi7hoOf6AwETX+JFMNsAQ86ax3MKq3xsShnfwNq5JLt46DSWhT+1PTtwtn4qOiyi0JjqDeRM8CwjR6llxzHtzR88d8nUisnVZKipZ7ywBKjDwLhgu/h3kbQ88z4= Received: by 10.67.21.11 with SMTP id y11mr1644131ugi.1185396654857; Wed, 25 Jul 2007 13:50:54 -0700 (PDT) Received: by 10.66.252.19 with HTTP; Wed, 25 Jul 2007 13:50:54 -0700 (PDT) Message-ID: Date: Wed, 25 Jul 2007 22:50:54 +0200 From: "Sven Braun" To: freebsd-current@freebsd.org In-Reply-To: <18087.41034.817186.693348@almost.alerce.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <18087.41034.817186.693348@almost.alerce.com> X-Mailman-Approved-At: Wed, 25 Jul 2007 21:09:17 +0000 Subject: Re: FreeBSD on intel Mac X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Jul 2007 20:50:56 -0000 > > Is it the case that I can install and boot freebsd on an intel mac > > (uses EFI, not BIOS) currently (without using Boot Camp), or do I > > have to wait until FreeBSD 7 for this functionality? Yes and no. On my MacBook I am currently running Current, otherwise I had to use a closed-source network driver for my network card. This is not a real problem, but I think it is nicer. And some other features like WiFi will be possible. If you wan't to install only FreeBSD with rEFIt, you have to: Boot from the Mac OS X Install Disc 1, seletc Disk Utility and Partition the following way: MBR-Table 512 MB JHFS+ whatyouneedforyourbasesystem GB UFS andprobablythe/usr/home GB UFS you reboot into a freebsd installation, select custom -> partition -> and change the types of your non-jhfs+ partitions to 165 and you don't want to touch the mbr! reboot over again into yout freebsd installation, select custom -> label and create your labels and install it the normal way. you reboot into mac os x and copy refit from a usbstick onto the jhfs+ refit partition, with the in the enable-always.sh "bless -..." command you set it bootable and enjoy your freebsd with refit. if you want to keep os x, deal this way: > Now, if I hold down the option key as the machine powers up, I'm > offered the choice of booting my "real" os x install on a different > disk or refit (oddly, it asks me about booting windows, I've never > tried it). When I choose refit, it gives me a couple of things to > boot from, including either of the mac installs or my freebsd system. > > I think that if I run refit's enable-always shell script, I can avoid > the option key trick and possibly just boot into freebsd by default, > but I haven't explored that option. This will only work, when you install refit recent. -- Sven Braun From owner-freebsd-current@FreeBSD.ORG Wed Jul 25 21:30: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 B07DB16A41A for ; Wed, 25 Jul 2007 21:30:11 +0000 (UTC) (envelope-from christian@kuhtz.com) Received: from roland.lunarservers.com (roland.lunarservers.com [74.50.1.185]) by mx1.freebsd.org (Postfix) with ESMTP id 8E5DC13C465 for ; Wed, 25 Jul 2007 21:30:11 +0000 (UTC) (envelope-from christian@kuhtz.com) Received: from [216.40.191.4] (helo=[192.168.0.250]) by roland.lunarservers.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.66) (envelope-from ) id 1IDnEz-0004rb-V7; Wed, 25 Jul 2007 13:13:50 -0700 In-Reply-To: <18087.41034.817186.693348@almost.alerce.com> References: <18087.41034.817186.693348@almost.alerce.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Christian Kuhtz Date: Wed, 25 Jul 2007 16:13:40 -0400 To: hartzell@alerce.com X-Mailer: Apple Mail (2.752.3) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - roland.lunarservers.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - kuhtz.com X-Source: X-Source-Args: X-Source-Dir: Cc: freebsd-current@freebsd.org, Andrew Moran Subject: Re: FreeBSD on intel Mac X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Jul 2007 21:30:11 -0000 On Jul 25, 2007, at 3:11 PM, George Hartzell wrote: > Andrew Moran writes: >> >> Is it the case that I can install and boot freebsd on an intel mac >> (uses EFI, not BIOS) currently (without using Boot Camp), or do I >> have to wait until FreeBSD 7 for this functionality? > > Boot Camp seems to be a marketing term, I still haven't figured out > what various people mean when they use the term. Is it the assistant? > The windows driver CD? The entire package of partitioning assistant, boot loader activation and drivers? What else would it be? Best regards, Christian From owner-freebsd-current@FreeBSD.ORG Wed Jul 25 21:35:38 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 052F516A418 for ; Wed, 25 Jul 2007 21:35:38 +0000 (UTC) (envelope-from lydianconcepts@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 C2DE013C467 for ; Wed, 25 Jul 2007 21:35:32 +0000 (UTC) (envelope-from lydianconcepts@gmail.com) Received: by wa-out-1112.google.com with SMTP id k17so55555waf for ; Wed, 25 Jul 2007 14:35: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=QfZA4YfU/e0QV1t3RxQym29AH9cpRJ/QxY73Xc9ZRMQvfNqP55k0g3HtBoK4oUVhq5J5m0TC9HiRvBeF8XUqR7XfQLID+2RBKonxJ6ls7SiG3VDxdbhfcmg5zzc0Imfj2IdDxst9ap2MGILGiihTBSDahfQy7Hrm+J9yz3P0z20= 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=K10KmRc/AL7s4Dc3sdFverQKkTsZoyvUt/eWWIY2hs/0rGob6tt4rMGYOz6DcyogG+V0zf+a8XPwzsAJ4Wen7CwatbdjkKVWaqqaT0skyzWi2U4avJ7NbXxGLyXzsl6VQB/V7AqtOvBHv6zAUyV3go+nNDAjGU7nWQzqdk7izXY= Received: by 10.115.32.1 with SMTP id k1mr1056031waj.1185399331522; Wed, 25 Jul 2007 14:35:31 -0700 (PDT) Received: by 10.114.125.14 with HTTP; Wed, 25 Jul 2007 14:35:31 -0700 (PDT) Message-ID: <7579f7fb0707251435j319fa0b0m678268d6738a35ef@mail.gmail.com> Date: Wed, 25 Jul 2007 14:35:31 -0700 From: "Matthew Jacob" To: "Ed Schouten" In-Reply-To: <20070705131908.GJ37187@hoeg.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070705123543.GI37187@hoeg.nl> <20070705125528.GH87424@bunrab.catwhisker.org> <20070705131908.GJ37187@hoeg.nl> Cc: FreeBSD Current Subject: Re: New world - about 2 days old - SSH broken? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Jul 2007 21:35:38 -0000 /me2 on this pretty standard buildworlds- but logging in as root seems to work. Dunno why not for me either. From owner-freebsd-current@FreeBSD.ORG Wed Jul 25 21:56: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 1A61116A417 for ; Wed, 25 Jul 2007 21:56:12 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from sippysoft.com (gk.360sip.com [72.236.70.226]) by mx1.freebsd.org (Postfix) with ESMTP id D3F1913C45B for ; Wed, 25 Jul 2007 21:56:11 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from [192.168.0.61] ([204.244.149.125]) (authenticated bits=0) by sippysoft.com (8.13.8/8.13.8) with ESMTP id l6PLu7pf068180 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Jul 2007 14:56:10 -0700 (PDT) (envelope-from sobomax@FreeBSD.org) Message-ID: <46A7C6E8.8040200@FreeBSD.org> Date: Wed, 25 Jul 2007 14:55:52 -0700 From: Maxim Sobolev Organization: Sippy Software, Inc. User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Marcel Moolenaar References: <46A7A5FB.90203@sippysoft.com> <5865861B-E29E-451C-B07B-B52028549F50@mac.com> In-Reply-To: <5865861B-E29E-451C-B07B-B52028549F50@mac.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "current@freebsd.org" , peter@FreeBSD.org Subject: Re: installworld breaks my FreeBSD/powerpc system!!! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2007 21:56:12 -0000 Marcel Moolenaar wrote: > > On Jul 25, 2007, at 12:35 PM, Maxim Sobolev wrote: > >> It seems that installworld from yesterday sources severely corrupted >> my 7-CURRENT FreeBSD/ppc installation. :( >> >> I believe this is caused by the recent libc changes that go together >> with dynamic linker changes, but since dynamic linker is installed >> *after* libc in installworld process, one who does source upgrade ends >> up with broken system containing old dynamic linker, while new libc >> after installworld explodes! :((( > > I think it's a mmap(2) problem, rather than a libc/ld-elf problem. I > suspect > that the peter@'s change to not align arguments is causing the problem. > It's > difficult to analyze because I don't trust the output of truss and ktrace > anymore in this case: the file offset argument is garbage according to > those > tools. The file offset is garbage on all platforms, not just PowerPC :-/ > > Other signs of mmap problems: dhclient complaining about a corrupted lease > file and rpc.statd complaining about an invalid database file... > > Unfortunately, I don't have the time to look into it right now. Yes, looks like you are right. I've booted into single-user and copied both libc.so.7 and ld-elf.so.1 by hand and everything works now. I think that the problem happens when install(8) invokes strip(1) to get rid of debug symbols and strip(1) uses mmap(), which messes up the library. This has to be resolved ASAP. -Maxim From owner-freebsd-current@FreeBSD.ORG Wed Jul 25 22:20: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 EFB1116A419 for ; Wed, 25 Jul 2007 22:20:37 +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 BA01613C465 for ; Wed, 25 Jul 2007 22:20:37 +0000 (UTC) (envelope-from craig@xfoil.gank.org) Received: by ion.gank.org (Postfix, from userid 1001) id 7301411253; Wed, 25 Jul 2007 17:20:37 -0500 (CDT) Date: Wed, 25 Jul 2007 17:20:35 -0500 From: Craig Boston To: Dmitry Morozovsky Message-ID: <20070725222035.GA50522@nowhere> Mail-Followup-To: Craig Boston , Dmitry Morozovsky , Pawel Jakub Dawidek , current@FreeBSD.org References: <20070725234322.G33266@woozle.rinet.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070725234322.G33266@woozle.rinet.ru> User-Agent: Mutt/1.4.2.3i Cc: Pawel Jakub Dawidek , current@FreeBSD.org Subject: Re: ZFS on a notebook/512M settings X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Jul 2007 22:20:38 -0000 On Thu, Jul 26, 2007 at 12:52:33AM +0400, Dmitry Morozovsky wrote: > I want to join the 'eating our own dogfood' company using ZFS on my notebook. > However, it is armed with only 512M of RAM. What are tunings which would > possibly keep it from panicing? For now, I've got in /boot/loader.conf: I'm using /boot/loader.conf: vm.kmem_size="268435456" vfs.zfs.prefetch_disable="1" /etc/sysctl.conf: kern.maxvnodes=22500 on my home fileserver with 512MB of RAM without incident. It does a lot of small file access -- cvsup's RELENG_4, RELENG_6, and HEAD sources nightly and imports them into subversion. You could probably bump up maxvnodes a little without it panicing. I started conservatively and performance has been acceptable so I haven't taken the time to tune it fully. I've seen recommendations on the BSD lists to use zil_disable to avoid low-memory deadlocks (which I've not yet encountered). I've also seen dire warnings on the OpenSolaris lists about possible data corruption if you disable the ZIL, so I'm unsure about that one. For now I'm erring on the side of caution and leaving it enabled until it causes me problems. Craig From owner-freebsd-current@FreeBSD.ORG Wed Jul 25 22:38: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 E4C8A16A419 for ; Wed, 25 Jul 2007 22:38:01 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from sippysoft.com (gk.360sip.com [72.236.70.226]) by mx1.freebsd.org (Postfix) with ESMTP id AD5DB13C469 for ; Wed, 25 Jul 2007 22:38:01 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from [192.168.0.61] ([204.244.149.125]) (authenticated bits=0) by sippysoft.com (8.13.8/8.13.8) with ESMTP id l6PMMs5Y068934 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Jul 2007 15:22:56 -0700 (PDT) (envelope-from sobomax@FreeBSD.org) Message-ID: <46A7CD32.40605@FreeBSD.org> Date: Wed, 25 Jul 2007 15:22:42 -0700 From: Maxim Sobolev Organization: Sippy Software, Inc. User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Xin LI References: <46A625FB.5050105@delphij.net> In-Reply-To: <46A625FB.5050105@delphij.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: Call for non i386/amd64 testers for tmpfs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Jul 2007 22:38:02 -0000 Regression test (t_mount) fails on PowerPC-based Mac: + echo Root directory attributes are set correctly... Root directory attributes are set correctly... + test_mount -o uid=1000,gid=100,mode=755 + mkdir /usr/src/tools/regression/tmpfs/tmp + [ 2 -gt 0 ] + mount -t tmpfs -o uid=1000,gid=100,mode=755 tmpfs /usr/src/tools/regression/tmpfs/tmp + cd /usr/src/tools/regression/tmpfs/tmp + stat -s /usr/src/tools/regression/tmpfs/tmp + eval st_dev=134283018 st_ino=2 st_mode=040000 st_nlink=2 st_uid=1000 st_gid=100 st_rdev=4294967295 st_size=0 st_atime=1185399883 st_mtime=1185399883 st_ctime=1185399883 st_birthtime=1185399883 st_blksize=4096 st_blocks=0 st_flags=0 + st_dev=134283018 st_ino=2 st_mode=040000 st_nlink=2 st_uid=1000 st_gid=100 st_rdev=4294967295 st_size=0 st_atime=1185399883 st_mtime=1185399883 st_ctime=1185399883 st_birthtime=1185399883 st_blksize=4096 st_blocks=0 st_flags=0 + [ 1000 = 1000 ] + [ 100 = 100 ] + [ 040000 = 040755 ] + die Other tests complete just fine. I needed to hack t_vnd to avoid placing BSD label on md(4) disk image since BSD labels are not portable across different platforms so that GEOM_LABEL doesn't pick it up properly. -Maxim Xin LI wrote: > Hi, > > I'd like to request that some owners of non-i386/amd64 boxes to test > sys/modules/tmpfs and report if it would work correctly on other > architectures, so I will be able to determine if it is appropriate to > connect it to build on these architectures (and perhaps pick out more > bugs :) > > Thanks for your cooperation! > > Cheers, > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > From owner-freebsd-current@FreeBSD.ORG Wed Jul 25 23:35:14 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 F0FE916A417; Wed, 25 Jul 2007 23:35:14 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from sippysoft.com (gk.360sip.com [72.236.70.226]) by mx1.freebsd.org (Postfix) with ESMTP id AC91C13C459; Wed, 25 Jul 2007 23:35:14 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from [192.168.0.61] ([204.244.149.125]) (authenticated bits=0) by sippysoft.com (8.13.8/8.13.8) with ESMTP id l6PNZASo071020 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Jul 2007 16:35:12 -0700 (PDT) (envelope-from sobomax@FreeBSD.org) Message-ID: <46A7DE23.4060200@FreeBSD.org> Date: Wed, 25 Jul 2007 16:34:59 -0700 From: Maxim Sobolev Organization: Sippy Software, Inc. User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: "current@freebsd.org" References: <46A7A5FB.90203@sippysoft.com> <5865861B-E29E-451C-B07B-B52028549F50@mac.com> <46A7C6E8.8040200@FreeBSD.org> In-Reply-To: <46A7C6E8.8040200@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Marcel Moolenaar , peter@FreeBSD.org Subject: Re: installworld breaks my FreeBSD/powerpc system!!! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2007 23:35:15 -0000 Maxim Sobolev wrote: > Marcel Moolenaar wrote: >> >> On Jul 25, 2007, at 12:35 PM, Maxim Sobolev wrote: >> >>> It seems that installworld from yesterday sources severely corrupted >>> my 7-CURRENT FreeBSD/ppc installation. :( >>> >>> I believe this is caused by the recent libc changes that go together >>> with dynamic linker changes, but since dynamic linker is installed >>> *after* libc in installworld process, one who does source upgrade >>> ends up with broken system containing old dynamic linker, while new >>> libc after installworld explodes! :((( >> >> I think it's a mmap(2) problem, rather than a libc/ld-elf problem. I >> suspect >> that the peter@'s change to not align arguments is causing the >> problem. It's >> difficult to analyze because I don't trust the output of truss and ktrace >> anymore in this case: the file offset argument is garbage according to >> those >> tools. The file offset is garbage on all platforms, not just PowerPC :-/ >> >> Other signs of mmap problems: dhclient complaining about a corrupted >> lease >> file and rpc.statd complaining about an invalid database file... >> >> Unfortunately, I don't have the time to look into it right now. > > Yes, looks like you are right. I've booted into single-user and copied > both libc.so.7 and ld-elf.so.1 by hand and everything works now. I think > that the problem happens when install(8) invokes strip(1) to get rid of > debug symbols and strip(1) uses mmap(), which messes up the library. > > This has to be resolved ASAP. Yes, indeed, apparently the new kernel doesn't work with old libc on PowerPC and consequently statically linked bootstrap binaries from /usr/obj produce incorrect results: [sobomax@sobomac /tmp]$ ktrace /usr/obj/usr/src/tmp/usr/bin/strip libc.so.7 BFD: stUwcDGK: warning: allocated section `.hash' not in segment BFD: stUwcDGK: warning: allocated section `.dynsym' not in segment BFD: stUwcDGK: warning: allocated section `.dynstr' not in segment BFD: stUwcDGK: warning: allocated section `.gnu.version' not in segment BFD: stUwcDGK: warning: allocated section `.gnu.version_d' not in segment BFD: stUwcDGK: warning: allocated section `.rela.dyn' not in segment BFD: stUwcDGK: warning: allocated section `.rela.plt' not in segment BFD: stUwcDGK: warning: allocated section `.init' not in segment BFD: stUwcDGK: warning: allocated section `.text' not in segment BFD: stUwcDGK: warning: allocated section `.fini' not in segment BFD: stUwcDGK: warning: allocated section `.rodata' not in segment BFD: stUwcDGK: warning: allocated section `.data' not in segment BFD: stUwcDGK: warning: allocated section `.tbss' not in segment BFD: stUwcDGK: warning: allocated section `.eh_frame' not in segment BFD: stUwcDGK: warning: allocated section `.dynamic' not in segment BFD: stUwcDGK: warning: allocated section `.ctors' not in segment BFD: stUwcDGK: warning: allocated section `.dtors' not in segment BFD: stUwcDGK: warning: allocated section `.jcr' not in segment BFD: stUwcDGK: warning: allocated section `.got' not in segment BFD: stUwcDGK: warning: allocated section `.sdata2' not in segment BFD: stUwcDGK: warning: allocated section `.sdata' not in segment BFD: stUwcDGK: warning: allocated section `.sbss' not in segment BFD: stUwcDGK: warning: allocated section `.plt' not in segment BFD: stUwcDGK: warning: allocated section `.bss' not in segment /usr/obj/usr/src/tmp/usr/bin/strip: unable to copy file 'libc.so.7' reason: Permission denied [sobomax@sobomac /tmp]$ kdump | grep freebsd6_mmap 746 strip CALL freebsd6_mmap(0,0x200000,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,0xffffffff,0,0,0) 746 strip RET freebsd6_mmap 562896896/0x218d2000 che_read\0_savefpr_17\0__collate_err\0__sys_sctp_peeloff\0_reclaim_telldir\0_sseek\0__xprt_unregister_unlocked\0freebsd6_mmap\0\ authsvc_lock\0__bt_dleaf\0_savefpr_19\0__sys_freebsd6_mmap\0__rpc_taddr2uaddr_af\0freebsd4_fstatfs\0__pow5mult_D2A\0_sctp_gener\ r\0__fputwc\0_freebsd6_mmap\0_sigintr\0__cached_mp_write\0_endnetdnsent\0__rec_ret\0_sctp_generic_sendmsg\0__vfwprintf\0_nsyy_c\ 746 strip CALL freebsd6_mmap(0,0x200000,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,0xffffffff,0,0,0) 746 strip RET freebsd6_mmap 564133888/0x21a00000 New libc seems to be OK: [sobomax@sobomac /tmp]$ strip libc.so.7 strip: unable to copy file 'libc.so.7' reason: Permission denied [sobomax@sobomac /tmp]$ kdump | grep -w mmap 749 strip CALL mmap(0,0x8000,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,0xffffffff,0,0,0) 749 strip RET mmap 562847744/0x218c6000 749 strip CALL mmap(0,0x127000,PROT_READ|PROT_EXEC,MAP_PRIVATE|MAP_NOCORE,0x3,0x7fffd860,0,0) 749 strip RET mmap 562941952/0x218dd000 749 strip CALL mmap(0x219e5000,0x7000,PROT_READ|PROT_WRITE|PROT_EXEC,MAP_PRIVATE|MAP_FIXED,0x3,0x218d8c4c,0,0xf8000) 749 strip RET mmap 564023296/0x219e5000 749 strip CALL mmap(0x219ec000,0x18000,PROT_READ|PROT_WRITE|PROT_EXEC,MAP_PRIVATE|MAP_FIXED|MAP_ANON,0xffffffff,0x218d8c4c,0,0) 749 strip RET mmap 564051968/0x219ec000 749 strip CALL mmap(0,0x328,PROT_READ|PROT_WRITE,MAP_ANON,0xffffffff,0x1000,0,0) 749 strip RET mmap 562880512/0x218ce000 749 strip CALL mmap(0,0x51c8,PROT_READ|PROT_WRITE,MAP_ANON,0xffffffff,0xffffffc4,0,0) 749 strip RET mmap 562880512/0x218ce000 749 strip CALL mmap(0,0x200000,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,0xffffffff,0,0,0) 749 strip RET mmap 564150272/0x21a04000 749 strip CALL mmap(0,0x200000,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,0xffffffff,0xfffffffe,0,0) 749 strip RET mmap 566231040/0x21c00000 Please investigate and fix -Maxim From owner-freebsd-current@FreeBSD.ORG Wed Jul 25 23:57: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 2930816A41A for ; Wed, 25 Jul 2007 23:57:17 +0000 (UTC) (envelope-from william88@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 020EC13C4DD for ; Wed, 25 Jul 2007 23:57:16 +0000 (UTC) (envelope-from william88@gmail.com) Received: by wa-out-1112.google.com with SMTP id k17so90418waf for ; Wed, 25 Jul 2007 16:57: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:mime-version:content-type; b=TFwRk+voltvwQXG8b1aqh7AzUoe6la83KrM5S+IXZ7Hm6Tb87Bm5GvBOnxGhkrJCxELFW/T2UovWogYGHOizDlfx9fqKr5TQOHIhMAOP1e4/4w/XRpE9KLVTTqO/WehShf618H9/t5kpM3Ykkj/W5DdMg12cINBRrnqJHrA+kZs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=qSi91fa+k45+waNuTVn5NJNz9fpZZyeGJTU1GhferpZMno9K8m8+mMnrUSHak0GVZhkx45dTwUv51XCGLXBJIyTFhhkPQBKj/C0m3Lr/9li3B43sdTSUuiO/SMyDbbC9Q1v2TmcMctti48hJ5CxZiJ7OclZ3e8BRVWfexVKms3Y= Received: by 10.114.157.1 with SMTP id f1mr1146937wae.1185406351186; Wed, 25 Jul 2007 16:32:31 -0700 (PDT) Received: by 10.115.106.9 with HTTP; Wed, 25 Jul 2007 16:32:31 -0700 (PDT) Message-ID: <632825b40707251632w6a9451a3s10ece43057821c5c@mail.gmail.com> Date: Wed, 25 Jul 2007 20:32:31 -0300 From: "William Grzybowski" 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: snd_emu10k1 mixer X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Jul 2007 23:57:17 -0000 Hi, I upgraded my desktop computer from 6.2-stable to 7.0-current yesterday. I'm experiencing a little problema with the sound driver snd_emu10k1, it loads and plays fine, but i can't control the volume/pcm/line/mic using aumix/xmixer or any other program to control the hardware mixer. -- William Grzybowski ------------------------------------------ Jabber: william88 at gmail dot com Msn: william.grz at hotmail dot com Curitiba/PR From owner-freebsd-current@FreeBSD.ORG Thu Jul 26 00:51:59 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 4E45116A418 for ; Thu, 26 Jul 2007 00:51:59 +0000 (UTC) (envelope-from n-butcher=freebsd-current=freebsd.org=sbibybnr@fusiongol.com) Received: from smtp02.dentaku.gol.com (smtp02.dentaku.gol.com [203.216.5.72]) by mx1.freebsd.org (Postfix) with ESMTP id 2378413C442 for ; Thu, 26 Jul 2007 00:51:59 +0000 (UTC) (envelope-from n-butcher=freebsd-current=freebsd.org=sbibybnr@fusiongol.com) Received: from pat.gol.co.jp ([203.216.1.191] helo=[127.0.0.1]) by smtp02.dentaku.gol.com with esmtpa (Dentaku) id 1IDra9-0002Uv-Tt for ; Thu, 26 Jul 2007 09:51:58 +0900 Message-ID: <46A7F02C.9000502@fusiongol.com> Date: Thu, 26 Jul 2007 09:51:56 +0900 From: Nathan Butcher User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: freebsd-current@freebsd.org X-Enigmail-Version: 0.95.2 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV GOL X-Abuse-Complaints: abuse@gol.com Subject: Re: Promise SATA300 TX4 card issues X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Jul 2007 00:51:59 -0000 >I've got a ZFS pool setup, and when scrubbing the pool it comes up with > erratic CKSUM errors (for example, scrub once and get 7 errors, scrub > again immediately and get 53 more). I did a buildworld and buildkernel just yesterday with the latest CURRENT sources and I can confirm that I'm seeing the same problem. What is interesting is that didn't notice any hard system lockups. My system is amd64 with 2GB of RAM, four 500GB drives connected to my Promise SATA300 TX4 card in a raidz1 pool. For testing purposes, I have created a volume in my zpool, which houses a UFS file system created and accessed via GELI. I then use samba to copy data to and from the volume on another machine. While writing data to my volume, I am getting erratic CKSUM errors being "discovered" coming from my ZFS raidz1 (a look at zpool status after the write confirms this), and scrubbing the zpool just seems to discover more CKSUM errors. "zpool status" is telling me to replace some of my disks. This never happened before. I revert my kernel back to the old 200706 snapshot kernel and now the CKSUM errors are all gone. A fsck on my GELI UFS volume now produces no errors, and a scrub on my ZFS volume no longer produces CKSUM errors. The data I wrote to the volume is intact - so no data corruption as far as I can tell. It would be great if these issues could be solved for this card, as it is one of the cheapest 4-port SATA expansion cards out there for creating a zpool with. *SIGH* In the meantime I am going to have to stick with the 200706 snapshot kernel and userland, which is stable with this card. From owner-freebsd-current@FreeBSD.ORG Thu Jul 26 00:59: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 2CAFF16A418; Thu, 26 Jul 2007 00:59:24 +0000 (UTC) (envelope-from grehan@freebsd.org) Received: from dommail.onthenet.com.au (dommail.OntheNet.com.au [203.13.70.57]) by mx1.freebsd.org (Postfix) with ESMTP id 8373413C428; Thu, 26 Jul 2007 00:59:23 +0000 (UTC) (envelope-from grehan@freebsd.org) Received: from [192.168.0.13] (dsl-63-249-90-35.cruzio.com [63.249.90.35]) by dommail.onthenet.com.au (MOS 3.7.5a-GA) with ESMTP id CYW24255 (AUTH peterg@ptree32.com.au); Thu, 26 Jul 2007 10:46:22 +1000 (EST) Message-ID: <46A7EF19.9000106@freebsd.org> Date: Wed, 25 Jul 2007 17:47:21 -0700 From: Peter Grehan User-Agent: Thunderbird 1.5.0.12 (Macintosh/20070509) MIME-Version: 1.0 To: Maxim Sobolev , Marcel Moolenaar Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@FreeBSD.org, peter@FreeBSD.org, cognet@freebsd.org Subject: Re: installworld breaks my FreeBSD/powerpc system!!! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: grehan@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2007 00:59:24 -0000 >> > I think it's a mmap(2) problem, rather than a libc/ld-elf problem. I >> > suspect >> > that the peter@'s change to not align arguments is causing the problem. Yes and no :) ppc is 32-bit/big-endian which doesn't sit too nice for 64-bit syscall returns and FreeBSD's td_retval[0|1] scheme. There is some special-case code in powerpc/trap.c that obscurely catches these cases and swaps the retvals to match the ppc calling convention. With mmap (and others) moving from the indirect _syscall() to a direct call, that code fragment needs to be updated and the backward-compat cases handled. I'll see if I can knock up something and test it. arm/be will have the same issue, Olivier cc'd. later, Peter. From owner-freebsd-current@FreeBSD.ORG Thu Jul 26 04:01: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 AD24816A419 for ; Thu, 26 Jul 2007 04:01:15 +0000 (UTC) (envelope-from mistry.7@osu.edu) Received: from mail.united-ware.com (am-productions.biz [69.61.164.22]) by mx1.freebsd.org (Postfix) with ESMTP id 00A4E13C46B for ; Thu, 26 Jul 2007 04:01:14 +0000 (UTC) (envelope-from mistry.7@osu.edu) Received: from [192.168.1.100] (cpe-71-72-80-132.columbus.res.rr.com [71.72.80.132]) (authenticated bits=0) by mail.united-ware.com (8.13.8/8.13.8) with ESMTP id l6Q47JEA079580 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 26 Jul 2007 00:07:26 -0400 (EDT) (envelope-from mistry.7@osu.edu) From: Anish Mistry To: freebsd-current@freebsd.org User-Agent: KMail/1.9.6 MIME-Version: 1.0 Date: Wed, 25 Jul 2007 23:35:19 -0400 Content-Type: multipart/signed; boundary="nextPart4469424.iBpaAq9gCy"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200707252335.19924.mistry.7@osu.edu> X-Virus-Scanned: ClamAV 0.90.3/3770/Wed Jul 25 21:52:36 2007 on mail.united-ware.com X-Virus-Status: Clean X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Can't create TCP connections to certain IP addresses X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Jul 2007 04:01:15 -0000 --nextPart4469424.iBpaAq9gCy Content-Type: multipart/mixed; boundary="Boundary-01=_3ZBqGtVAoBwfDxw" Content-Transfer-Encoding: 7bit Content-Disposition: inline --Boundary-01=_3ZBqGtVAoBwfDxw Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline This has been happening for a while, I just don't remember when it=20 started (it's been happening for at least a couple of months now),=20 but I know everything was working in April. I'm trying to debug a=20 strange problem I'm having with my -CURRENT system. I can not=20 connect to certain IP addresses. I can connect to=20 am-productions.biz, but not slashdot.org, etc. When the connection=20 can't be made I see the state as SYN_SENT (via netstat). This isn't=20 a DNS issue since I can resolve and ping the sites that I can't=20 connect to. I've tried other on other networks just in case it was a problem with=20 my network, but the same thing happens there too. This is using an=20 rl NIC in my laptop. Using the ath wireless leads to the same=20 results as the rl. Connecting to the cvsup server that I'm using does work, so I can=20 update easily. I've attached various information. If there is some more information=20 I need to provide let me know. I know I probably should have reported this a while ago, but I kept=20 thinking there was something wrong with my config that I couldn't=20 figure out. tcpdump.txt contains a failed connection. tcpdump-good.txt contains=20 a succeeded connection. Thanks, =2D-=20 Anish Mistry --Boundary-01=_3ZBqGtVAoBwfDxw Content-Type: text/plain; charset="us-ascii"; name="sysctl-tcp.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="sysctl-tcp.txt" net.inet.tcp.rfc1323: 1 net.inet.tcp.mssdflt: 512 net.inet.tcp.keepidle: 7200000 net.inet.tcp.keepintvl: 75000 net.inet.tcp.sendspace: 32768 net.inet.tcp.recvspace: 65536 net.inet.tcp.keepinit: 75000 net.inet.tcp.delacktime: 100 net.inet.tcp.v6mssdflt: 1024 net.inet.tcp.hostcache.purge: 0 net.inet.tcp.hostcache.prune: 300 net.inet.tcp.hostcache.expire: 3600 net.inet.tcp.hostcache.count: 0 net.inet.tcp.hostcache.bucketlimit: 30 net.inet.tcp.hostcache.hashsize: 512 net.inet.tcp.hostcache.cachelimit: 15360 net.inet.tcp.recvbuf_max: 262144 net.inet.tcp.recvbuf_inc: 16384 net.inet.tcp.recvbuf_auto: 1 net.inet.tcp.insecure_rst: 0 net.inet.tcp.rfc3390: 1 net.inet.tcp.rfc3042: 1 net.inet.tcp.drop_synfin: 0 net.inet.tcp.delayed_ack: 1 net.inet.tcp.blackhole: 0 net.inet.tcp.log_in_vain: 0 net.inet.tcp.sendbuf_max: 262144 net.inet.tcp.sendbuf_inc: 8192 net.inet.tcp.sendbuf_auto: 1 net.inet.tcp.tso: 1 net.inet.tcp.newreno: 1 net.inet.tcp.local_slowstart_flightsize: 4 net.inet.tcp.slowstart_flightsize: 1 net.inet.tcp.path_mtu_discovery: 1 net.inet.tcp.reass.overflows: 0 net.inet.tcp.reass.maxqlen: 48 net.inet.tcp.reass.cursegments: 0 net.inet.tcp.reass.maxsegments: 532 net.inet.tcp.sack.globalholes: 0 net.inet.tcp.sack.globalmaxholes: 65536 net.inet.tcp.sack.maxholes: 128 net.inet.tcp.sack.enable: 1 net.inet.tcp.inflight.stab: 20 net.inet.tcp.inflight.max: 1073725440 net.inet.tcp.inflight.min: 6144 net.inet.tcp.inflight.rttthresh: 10 net.inet.tcp.inflight.debug: 0 net.inet.tcp.inflight.enable: 1 net.inet.tcp.isn_reseed_interval: 0 net.inet.tcp.icmp_may_rst: 1 net.inet.tcp.pcbcount: 6 net.inet.tcp.do_tcpdrain: 1 net.inet.tcp.tcbhashsize: 512 net.inet.tcp.minmss: 216 net.inet.tcp.syncache.rst_on_sock_fail: 1 net.inet.tcp.syncache.rexmtlimit: 3 net.inet.tcp.syncache.hashsize: 512 net.inet.tcp.syncache.count: 0 net.inet.tcp.syncache.cachelimit: 15360 net.inet.tcp.syncache.bucketlimit: 30 net.inet.tcp.syncookies_only: 0 net.inet.tcp.syncookies: 1 net.inet.tcp.timer_race: 0 net.inet.tcp.finwait2_timeout: 60000 net.inet.tcp.fast_finwait2_recycle: 0 net.inet.tcp.always_keepalive: 1 net.inet.tcp.rexmit_slop: 200 net.inet.tcp.rexmit_min: 30 net.inet.tcp.msl: 30000 net.inet.tcp.nolocaltimewait: 0 net.inet.tcp.maxtcptw: 5000 --Boundary-01=_3ZBqGtVAoBwfDxw Content-Type: text/plain; charset="us-ascii"; name="LITTLEGUY" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="LITTLEGUY" # # 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= =2Dconfig.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.=20 # If you are in doubt as to the purpose or necessity of a line, check first= =20 # in NOTES. # # $FreeBSD: src/sys/i386/conf/GENERIC,v 1.369.2.1 2002/12/18 08:11:24 scott= l Exp $ machine i386 cpu I586_CPU ident LITTLEGUY maxusers 0 #To statically compile in device wiring instead of /boot/device.hints #hints "GENERIC.hints" #Default places to look for devices. #makeoptions DEBUG=3D-g #Build kernel with gdb(1) debug symbols #options DDB, KDB, KDB_UNATTENDED options PREEMPTION #options FULL_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 UFS_GJOURNAL 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 root device, requires NFSCLIENT options MSDOSFS #MSDOS Filesystem options NTFS # NT Filesystem options CD9660 #ISO 9660 Filesystem options PROCFS #Process filesystem (requires PSEUDOFS) options PSEUDOFS #Pseudo-filesystem framework options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] options COMPAT_FREEBSD4 #Compatible with FreeBSD4 #options SCSI_DELAY=3D15000 #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 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 CPU_ENABLE_LONGRUN # Debugging for use in -current #options INVARIANTS #Enable calls of extra sanity checking #options INVARIANT_SUPPORT #Extra sanity checks of internal structures, re= quired by INVARIANTS #options WITNESS_KDB #options WITNESS_SKIPSPIN #options WITNESS #Enable checks to detect deadlocks and cycles # To make an SMP kernel, the next two are needed #options SMP # Symmetric MultiProcessor Kernel #options APIC_IO # Symmetric (APIC) I/O device isa device pci # Floppy drives #device fdc # ATA and ATAPI devices device ata device atadisk # ATA disk drives device atapicd # ATAPI CDROM drives #device atapifd # ATAPI floppy drives #device atapist # ATAPI tape drives #options ATA_STATIC_ID #Static device numbering # SCSI peripherals device scbus # SCSI bus (required) device da # Direct Access (disks) #device atapicam device cd device pass # 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 #options VESA #device splash # Splash screen and screen saver support # syscons is the default console driver, resembling an SCO console device sc #options SC_PIXEL_MODE # Enable this for the pcvt (VT220 compatible) console driver #device vt #options XSERVER # support for X server on a vt console #options FAT_CURSOR # start with block cursor #device agp # support several AGP chipsets # Floating point support - do not disable. device npx # remove KSE and use only libthr #nooption KSE #options SCHED_4BSD options SCHED_ULE # Add suspend/resume support for the i8254. device pmtimer # PCCARD (PCMCIA) support # Pcmcia and cardbus bridge support #device cbb # cardbus (yenta) bridge #device pcic # ExCA ISA and PCI bridges #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 # 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 rl # RealTek 8129/8139 # Wireless NIC cards #device an # Aironet 4500/4800 802.11 wireless NICs.=20 #device awi # BayStack 660 and others #device wi # WaveLAN/Intersil/Symbol 802.11 wireless NICs. #device wl # Older non 802.11 Wavelan wireless NIC. # Pseudo devices - the number indicates how many units to allocate. device random # Entropy device device loop # Network loopback device mem # Memory and kernel memory devices device io # I/O device #device null # Null and zero devices 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) # sound #device pcm # firewire (IEEE 1394) #device firewire # system management bus #device iicbus #device iicbb #device ic #device iic #device iicsmb #device smbus #device smb #device alpm # The `bpf' device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! device bpf # Berkeley packet filter # USB support options USB_DEBUG # USB debugging #device uhci # UHCI PCI->USB interface #device ohci # OHCI PCI->USB interface #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 --Boundary-01=_3ZBqGtVAoBwfDxw Content-Type: text/plain; charset="us-ascii"; name="sysctl.conf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="sysctl.conf" # $FreeBSD: src/etc/sysctl.conf,v 1.8 2003/03/13 18:43:50 mux Exp $ # # This file is read when going to multi-user and its contents piped thru # ``sysctl'' to adjust kernel values. ``man 5 sysctl.conf'' for details. # # Uncomment this to prevent users from seeing information about processes that # are being run under another UID. #security.bsd.see_other_uids=0 vfs.usermount=1 #vfs.read_max=32 hw.acpi.lid_switch_state=S3 hw.acpi.standby_state=S3 hw.acpi.sleep_button_state=S3 #hw.acpi.sleep_delay=10 hw.acpi.handle_reboot=1 # allows max usage only when needed, otherwise it stays at min freq #hw.crusoe.performance_longrun=2 #hw.crusoe.economy_longrun=2 hw.acpi.cpu.cx_lowest=C3 # reduce swap paging #vm.defer_swapspace_pageouts=1 # other tuning from "man tuning" #kern.ipc.shm_use_phys=1 # usb debugging #hw.usb.debug=2 #hw.usb.ums.debug=11 #hw.usb.umass.debug=11 kern.module_path=/boot/kernel;/boot/modules #hw.pccard.cis_debug=9 #hw.pccard.debug=9 #kern.ipc.shmall=131072 #kern.ipc.shmmax=64000000 --Boundary-01=_3ZBqGtVAoBwfDxw Content-Type: text/plain; charset="us-ascii"; name="tcpdump-good.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="tcpdump-good.txt" 23:15:18.079517 IP 192.168.1.195.63432 > m0n0wall.am-productions.biz.domain: 62498+ A? am-productions.biz. (36) 23:15:18.146047 IP m0n0wall.am-productions.biz.domain > 192.168.1.195.63432: 62498 1/6/7 A am-productions.biz (291) 23:15:18.148280 IP 192.168.1.195.49311 > m0n0wall.am-productions.biz.domain: 62499+ AAAA? am-productions.biz. (36) 23:15:18.213682 IP m0n0wall.am-productions.biz.domain > 192.168.1.195.49311: 62499 0/1/0 (93) 23:15:18.219015 IP 192.168.1.195.57135 > am-productions.biz.http: S 3142395275:3142395275(0) win 65535 23:15:18.243065 IP am-productions.biz.http > 192.168.1.195.57135: S 2533443809:2533443809(0) ack 3142395276 win 65535 23:15:18.243653 IP 192.168.1.195.57135 > am-productions.biz.http: . ack 1 win 260 23:15:18.666481 IP 192.168.1.195.49969 > m0n0wall.am-productions.biz.domain: 49318+ PTR? 1.1.168.192.in-addr.arpa. (42) 23:15:18.667539 IP m0n0wall.am-productions.biz.domain > 192.168.1.195.49969: 49318* 1/0/0 PTR[|domain] 23:15:18.670548 IP 192.168.1.195.54422 > m0n0wall.am-productions.biz.domain: 49319+ PTR? 195.1.168.192.in-addr.arpa. (44) 23:15:18.798275 IP m0n0wall.am-productions.biz.domain > 192.168.1.195.54422: 49319 NXDomain* 0/1/0 (112) 23:15:18.803615 IP 192.168.1.195.59285 > m0n0wall.am-productions.biz.domain: 49320+ PTR? 22.164.61.69.in-addr.arpa. (43) 23:15:18.804783 IP m0n0wall.am-productions.biz.domain > 192.168.1.195.59285: 49320 1/0/0 (75) 23:15:29.174352 IP 192.168.1.195.57135 > am-productions.biz.http: F 1:1(0) ack 1 win 260 23:15:29.199277 IP am-productions.biz.http > 192.168.1.195.57135: . ack 2 win 33304 23:15:29.201176 IP am-productions.biz.http > 192.168.1.195.57135: F 1:1(0) ack 2 win 33304 23:15:29.201535 IP 192.168.1.195.57135 > am-productions.biz.http: . ack 2 win 260 --Boundary-01=_3ZBqGtVAoBwfDxw Content-Type: text/plain; charset="us-ascii"; name="tcpdump.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="tcpdump.txt" 23:07:23.166861 arp who-has 192.168.1.100 tell 192.168.1.195 23:07:23.167036 arp reply 192.168.1.100 is-at 00:0b:6a:cb:be:8d (oui Unknown) 23:07:23.167126 IP 192.168.1.195.58799 > 192.168.1.100.ssh: S 2275413703:2275413703(0) win 65535 23:07:23.247656 IP 192.168.1.195.49713 > m0n0wall.am-productions.biz.domain: 6495+ PTR? 100.1.168.192.in-addr.arpa. (44) 23:07:23.269748 IP m0n0wall.am-productions.biz.domain > 192.168.1.195.49713: 6495 NXDomain* 0/1/0 (112) 23:07:23.274694 IP 192.168.1.195.60722 > m0n0wall.am-productions.biz.domain: 6496+ PTR? 195.1.168.192.in-addr.arpa. (44) 23:07:23.409341 IP m0n0wall.am-productions.biz.domain > 192.168.1.195.60722: 6496 NXDomain* 0/1/0 (112) 23:07:24.405455 IP 192.168.1.195.50305 > m0n0wall.am-productions.biz.domain: 6497+ PTR? 1.1.168.192.in-addr.arpa. (42) 23:07:24.406815 IP m0n0wall.am-productions.biz.domain > 192.168.1.195.50305: 6497* 1/0/0 PTR[|domain] 23:07:26.162424 IP 192.168.1.195.58799 > 192.168.1.100.ssh: S 2275413703:2275413703(0) win 65535 23:07:29.362386 IP 192.168.1.195.58799 > 192.168.1.100.ssh: S 2275413703:2275413703(0) win 65535 23:07:32.562415 IP 192.168.1.195.58799 > 192.168.1.100.ssh: S 2275413703:2275413703(0) win 65535 23:07:35.762501 IP 192.168.1.195.58799 > 192.168.1.100.ssh: S 2275413703:2275413703(0) win 65535 23:07:38.962548 IP 192.168.1.195.58799 > 192.168.1.100.ssh: S 2275413703:2275413703(0) win 65535 23:07:45.162732 IP 192.168.1.195.58799 > 192.168.1.100.ssh: S 2275413703:2275413703(0) win 65535 23:07:57.362939 IP 192.168.1.195.58799 > 192.168.1.100.ssh: S 2275413703:2275413703(0) win 65535 23:07:59.742344 IP 192.168.1.190.netbios-dgm > 192.168.1.255.netbios-dgm: NBT UDP PACKET(138) 23:08:00.405311 IP 192.168.1.195.58875 > m0n0wall.am-productions.biz.domain: 6498+ PTR? 255.1.168.192.in-addr.arpa. (44) 23:08:00.429433 IP m0n0wall.am-productions.biz.domain > 192.168.1.195.58875: 6498 NXDomain* 0/1/0 (112) 23:08:00.435831 IP 192.168.1.195.55362 > m0n0wall.am-productions.biz.domain: 6499+ PTR? 190.1.168.192.in-addr.arpa. (44) 23:08:00.557832 IP m0n0wall.am-productions.biz.domain > 192.168.1.195.55362: 6499 NXDomain* 0/1/0 (112) 23:08:21.563277 IP 192.168.1.195.58799 > 192.168.1.100.ssh: S 2275413703:2275413703(0) win 65535 23:08:38.001109 arp who-has 192.168.1.100 tell m0n0wall.am-productions.biz --Boundary-01=_3ZBqGtVAoBwfDxw-- --nextPart4469424.iBpaAq9gCy Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQBGqBZ3xqA5ziudZT0RAh17AJ0ebTw/NjS3qiPnmnjV+IXwNe0MvgCgoCCM 5Y9bv2qRw6Ry1k49n1pnlYU= =W0we -----END PGP SIGNATURE----- --nextPart4469424.iBpaAq9gCy-- From owner-freebsd-current@FreeBSD.ORG Thu Jul 26 07:05:12 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 204FD16A417 for ; Thu, 26 Jul 2007 07:05:12 +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 DFFFD13C458 for ; Thu, 26 Jul 2007 07:05:11 +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=qepOO/P+Du5U5CL1qNtHpOegE6ViOHwJSrJFSkPXNs1qKy3DVT327K68g9d08sTROsShghC6Rz7+aLScggUf/dZs6sZL3V3av4+aivO7YZZ8UI989PD48EyBZfqllqLsJVBZ1AwNjY9Xg/bfOCFg6YmamxHVLHkxEh2UsyrmgT/EMVhxRdKrQ+6QJTM7/G2WryY8bR151PreZItNrFOOcY4ILYjoLzGFtHZN4w+Q1NwsnJU3twsDcyTR+i6cb3GE; Received: from uucp by munchkin.clue.co.za with local (Exim 4.66) (envelope-from ) id 1IDxPI-00088q-TB; Thu, 26 Jul 2007 07:05: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 1IDxOt-0002jt-Lb; Thu, 26 Jul 2007 07:04:43 +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 1IDxOs-0006hs-Rf; Thu, 26 Jul 2007 09:04:42 +0200 To: Christian Kuhtz From: Ian FREISLICH In-Reply-To: Message from Christian Kuhtz of "Wed, 25 Jul 2007 16:13:40 -0400." X-Attribution: BOFH Date: Thu, 26 Jul 2007 09:04:42 +0200 Message-Id: Cc: Andrew Moran , freebsd-current@freebsd.org, hartzell@alerce.com Subject: Re: FreeBSD on intel Mac X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Jul 2007 07:05:12 -0000 Christian Kuhtz wrote: > > On Jul 25, 2007, at 3:11 PM, George Hartzell wrote: > > > Andrew Moran writes: > >> > >> Is it the case that I can install and boot freebsd on an intel mac > >> (uses EFI, not BIOS) currently (without using Boot Camp), or do I > >> have to wait until FreeBSD 7 for this functionality? > > > > Boot Camp seems to be a marketing term, I still haven't figured out > > what various people mean when they use the term. Is it the assistant? > > The windows driver CD? > > The entire package of partitioning assistant, boot loader activation > and drivers? What else would it be? If you want to keep MacOs on your intel mac, then you need something like boot camp or refit. I didn't want MacOs on my MacBook so I just did a staight forward installation of FreeBSD using the whole disk. No Geom. No hoops. No looking back. Ian -- Ian Freislich From owner-freebsd-current@FreeBSD.ORG Thu Jul 26 07:25:27 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 656E216A417 for ; Thu, 26 Jul 2007 07:25:27 +0000 (UTC) (envelope-from lordbyte@esperanza.rebooten.de) Received: from esperanza.rebooten.de (esperanza.rebooten.de [83.136.81.141]) by mx1.freebsd.org (Postfix) with ESMTP id 023F413C428 for ; Thu, 26 Jul 2007 07:25:26 +0000 (UTC) (envelope-from lordbyte@esperanza.rebooten.de) Received: from esperanza.rebooten.de (esperanza.rebooten.de [83.136.81.141]) by esperanza.rebooten.de (8.13.8/8.13.8) with ESMTP id l6Q75pAg071443; Thu, 26 Jul 2007 09:05:51 +0200 (CEST) (envelope-from lordbyte@esperanza.rebooten.de) Received: (from lordbyte@localhost) by esperanza.rebooten.de (8.13.8/8.13.8/Submit) id l6Q75pX6071442; Thu, 26 Jul 2007 09:05:51 +0200 (CEST) (envelope-from lordbyte) Date: Thu, 26 Jul 2007 09:05:51 +0200 From: Markus Boelter To: George Hartzell Message-ID: <20070726070551.GO21011@rebooten.de> References: <18087.41034.817186.693348@almost.alerce.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <18087.41034.817186.693348@almost.alerce.com> User-Agent: Mutt/1.4.2.2i X-Original-Status: RO Cc: freebsd-current@freebsd.org Subject: Re: FreeBSD on intel Mac X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Jul 2007 07:25:27 -0000 Hi! > Boot Camp seems to be a marketing term, I still haven't figured out > what various people mean when they use the term. Is it the assistant? > The windows driver CD? As far as I know, Boot Camp places also some code as EFI payload (hopefully this is the right term) that implements some BIOS calls and BIOS interrupts that software like Windows uses during its boot process. Vven WinXP still uses some of the 16 Bit BIOS calls during startup. Of course is Boot Camp also a set of drivers for various hardware for the Macs and also the assistent. Cheers! Markus -- Markus Boelter From owner-freebsd-current@FreeBSD.ORG Thu Jul 26 07:37: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 86D6516A41F; Thu, 26 Jul 2007 07:37:32 +0000 (UTC) (envelope-from lists@petri.cc) Received: from moof.catpipe.net (moof.catpipe.net [129.142.64.64]) by mx1.freebsd.org (Postfix) with ESMTP id 3515A13C428; Thu, 26 Jul 2007 07:37:32 +0000 (UTC) (envelope-from lists@petri.cc) Received: from localhost (unknown [129.142.64.64]) by localhost.catpipe.net (Postfix) with ESMTP id 15DB67CBC07; Thu, 26 Jul 2007 09:37:08 +0200 (CEST) X-Virus-Scanned: amavisd-new at catpipe.net Received: from moof.catpipe.net ([129.142.64.64]) by localhost (moof.catpipe.net [129.142.64.64]) (amavisd-new, port 10024) with ESMTP id NA5kCYYFPIhR; Thu, 26 Jul 2007 09:37:07 +0200 (CEST) Received: from fever.catpipe.net (0x573c56ae.nivaanqu1.broadband.tele.dk [87.60.86.174]) (Authenticated sender: relayuser) by moof.catpipe.net (Postfix) with ESMTP id F36C67CBAAB; Thu, 26 Jul 2007 09:37:06 +0200 (CEST) Message-ID: <46A84F36.8080309@petri.cc> Date: Thu, 26 Jul 2007 09:37:26 +0200 From: "Nicolai Petri (lists)" User-Agent: Thunderbird 2.0.0.0 (X11/20070527) MIME-Version: 1.0 To: Andrew Thompson References: <20070619011908.GA53748@heff.fud.org.nz> <20070620042023.GA17424@nowhere> <4678B1E4.7080909@errno.com> <467ED084.4000002@petri.cc> <46A484CA.8030805@petri.cc> <20070723114821.GA6575@heff.fud.org.nz> In-Reply-To: <20070723114821.GA6575@heff.fud.org.nz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current , Craig Boston Subject: ipw status (was: wireless) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2007 07:37:32 -0000 Andrew Thompson wrote: >> Are there any news on this matter ? We are now 1 month closer to beta >> and ipw is still useless. I'm willing to test if anyone have patches but >> I don't have time to look at code myself. > > You can test this WIP. > > cheers, > Andrew Hi Andrew This is definately a step in the right direction.. This mail is sent over my ipw card which haven't been used for a month :) My initial tests shows 2 things : 1) Firmware fails to load automatically 2) After a random period of a couple of minutes and more I get disconnected and a ifconfig ipw0 down up fixes it. I'm running 802.11b on an open accesspoint with no encryption. cheers, Nicolai From owner-freebsd-current@FreeBSD.ORG Thu Jul 26 08:12: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 4D9B416A421 for ; Thu, 26 Jul 2007 08:12:39 +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 DFDBF13C461 for ; Thu, 26 Jul 2007 08:12:33 +0000 (UTC) (envelope-from tataz@tataz.chchile.org) Received: from smtp5-g19.free.fr (localhost.localdomain [127.0.0.1]) by smtp5-g19.free.fr (Postfix) with ESMTP id 3713B7D9E; Thu, 26 Jul 2007 10:12:32 +0200 (CEST) Received: from tatooine.tataz.chchile.org (tataz.chchile.org [82.233.239.98]) by smtp5-g19.free.fr (Postfix) with ESMTP id 181806183; Thu, 26 Jul 2007 10:12:31 +0200 (CEST) Received: from obiwan.tataz.chchile.org (unknown [192.168.1.25]) by tatooine.tataz.chchile.org (Postfix) with ESMTP id 585699B497; Thu, 26 Jul 2007 08:13:25 +0000 (UTC) Received: by obiwan.tataz.chchile.org (Postfix, from userid 1000) id 2F0F5405B; Thu, 26 Jul 2007 10:13:25 +0200 (CEST) Date: Thu, 26 Jul 2007 10:13:25 +0200 From: Jeremie Le Hen To: Rene Ladan Message-ID: <20070726081324.GA2503@obiwan.tataz.chchile.org> References: <8cdf6c720707070710k2b7e030v37683e460d983bf9@mail.gmail.com> <20070708111105.C9997@fledge.watson.org> <20070708132545.5604cbe9.ubm@u-boot-man.de> <4690CFAA.30004@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4690CFAA.30004@gmail.com> User-Agent: Mutt/1.5.15 (2007-04-06) Cc: freebsd-current@freebsd.org, Marc UBM Bocklet Subject: Re: status of 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, 26 Jul 2007 08:12:39 -0000 Hi Marc, On Sun, Jul 08, 2007 at 01:51:06PM +0200, Rene Ladan wrote: > Marc UBM Bocklet schreef: > > > > > > I'd like to do some testing, but I'm a little bit afraid of the upgrade > > procedure 6.2-stable to -current. Is it possible to do a simple upgrade > > if I follow the guidelines in UPGRADE or are there any hidden caveats? > > (like "you've to recompile all installed ports", etc. :-)) > > > [...don't try this on a production box...] > > Just following the procedure and the changelog entries in > /usr/src/UPDATING should do the job. It's probably best to cvsup into a > new directory and clean /usr/obj before beginning the update. That's > how I updated from RELENG_6 to HEAD back in November 2006. > > Since we have a misc/compat6x port and a COMPAT_FREEBSD6 kernel > configuaration option, it shouldn't be necessary to rebuild all your > ports. I'd like to add that whenever I performed an upgrade between two FreeBSD major branch I found easier to use sysutils/etcmerge than mergemaster(8) to upgrade /etc, as the former is far more automated and prevents a lot of work due to the huge number of changes to merge. Important note (also explained in the "ROUGH DESCRIPTION OF USE" part of etcmerge manpage): 1) Make sure your current /etc is up-to-date (IOW run mergemaster(8)) WRT your current RELENG_6 source tree; 2) Follow etcmerge manpage to get /var/db/etc corresponding to the _stock_ /etc directory from your source tree. Best regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-current@FreeBSD.ORG Thu Jul 26 08:47: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 BA2EC16A417 for ; Thu, 26 Jul 2007 08:47:15 +0000 (UTC) (envelope-from sfourman@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 7535413C45A for ; Thu, 26 Jul 2007 08:47:15 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: by an-out-0708.google.com with SMTP id c14so115898anc for ; Thu, 26 Jul 2007 01:47: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=dhJPQcpVTUHfYvo97xY2goOYOVUQISRV/AzkpdvM4GO36kvH2QidgD3/9lbv2gsg2gWkJq2rnz5W/2Lhy12gCOdA6r61Ginp8Z4lLPqKeA+S5eBOPI2WYcqfBbq9S1UlCxVgwfbHuqtwSuxeC/eljNzDmOYujXzez1yPtVYIDk0= 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=gfTW80EjzN7ta6ZkWqfOkbY74AGsNaORfl9o5wuEkH8jL82Jagy46Y1xDwSHWKF+syzGqDkE/PZGaIMOUigHHz781tejk9bq8OgPRHrJW42q9HIM4dLHXQGQAB0uN/l4ok1uvRoojehOf+d7/3HveS2P0EeEvDm1PugfLgzrqjU= Received: by 10.100.105.18 with SMTP id d18mr995195anc.1185439634751; Thu, 26 Jul 2007 01:47:14 -0700 (PDT) Received: by 10.100.144.1 with HTTP; Thu, 26 Jul 2007 01:47:14 -0700 (PDT) Message-ID: <11167f520707260147l2978b521h761c01a27da6cea7@mail.gmail.com> Date: Thu, 26 Jul 2007 03:47:14 -0500 From: "Sam Fourman Jr." To: "Robert Watson" In-Reply-To: <20070708111105.C9997@fledge.watson.org> MIME-Version: 1.0 References: <8cdf6c720707070710k2b7e030v37683e460d983bf9@mail.gmail.com> <20070708111105.C9997@fledge.watson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Paul Eskello , freebsd-current@freebsd.org Subject: Re: status of 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, 26 Jul 2007 08:47:15 -0000 On 7/8/07, Robert Watson wrote: > > > On Sat, 7 Jul 2007, Paul Eskello wrote: > > > I was wondering when to expect 7.0 release ? Did I miss the schedule. > Any > > showstoppers ? when to expect RC1 ? > > > > Just curious. > > > > Have a great weekend. > > Ken may respond in a more detailed form, but the current stage is that we > are > waiting for the feature set to finally settle and some known outstanding > issues to resolve themselves, at which point we'll cut a first beta in the > next 2-4 weeks. As a precursor to that, monthly snapshots will likely get > built and released in the next couple of days. Hopefully testing and > feedback > from that will allow us to nail down a more specific schedule for the > release > itself. does anyone know if the july snapshots for 7.0 are going to get built? maybe i am looking in the worng spot but I didn't see them yet At this point, the imperative for developers is to wrap up any remaining > outstanding features and work on testing and bug fixing. Likewise users > :-). > We often find that even early adoption sites only really start testing > during > the RC cycle, and that's far too late to make larger changes that may be > required to address some sorts of stability issues. Getting people doing > testing the whole way through the cycle makes a big difference in the > effectiveness of the test cycle. > > There are some really great features in 7.0, and it's wonderful to be at > the > polishing and testing stage finally :-). > > Robert N M Watson > Computer Laboratory > University of Cambridge > _______________________________________________ > 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 26 09:44:00 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 A1A5C16A41A for ; Thu, 26 Jul 2007 09:44:00 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 20A5713C4B6 for ; Thu, 26 Jul 2007 09:44:00 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id ABF5F208C; Thu, 26 Jul 2007 11:43:56 +0200 (CEST) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: 0.0/3.0 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on tim.des.no Received: from ds4.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id 859E12089; Thu, 26 Jul 2007 11:43:56 +0200 (CEST) Received: by ds4.des.no (Postfix, from userid 1001) id 6574E84440; Thu, 26 Jul 2007 11:43:56 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Nathan Butcher References: <46A7F02C.9000502@fusiongol.com> Date: Thu, 26 Jul 2007 11:43:56 +0200 In-Reply-To: <46A7F02C.9000502@fusiongol.com> (Nathan Butcher's message of "Thu\, 26 Jul 2007 09\:51\:56 +0900") Message-ID: <86644733fn.fsf@ds4.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: Promise SATA300 TX4 card issues X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Jul 2007 09:44:00 -0000 Nathan Butcher writes: > My system is amd64 with 2GB of RAM, four 500GB drives connected to my > Promise SATA300 TX4 card in a raidz1 pool. For testing purposes, I have > created a volume in my zpool, which houses a UFS file system created and > accessed via GELI. I then use samba to copy data to and from the volume > on another machine. > > While writing data to my volume, I am getting erratic CKSUM errors being > "discovered" coming from my ZFS raidz1 (a look at zpool status after the > write confirms this), and scrubbing the zpool just seems to discover > more CKSUM errors. "zpool status" is telling me to replace some of my > disks. This never happened before. There is a known problem with Promise controllers and ZFS, probably related to ATA_FLUSHCACHE. The only known solution is to switch to a non-Promise controller - Intel ICH works fine. The ata maintainer is aware of the issue but doesn't seem interested in fixing it. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Thu Jul 26 10:56: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 63A4316A421 for ; Thu, 26 Jul 2007 10:56:34 +0000 (UTC) (envelope-from nicolas@boiteameuh.org) Received: from smtp4-g19.free.fr (smtp4-g19.free.fr [212.27.42.30]) by mx1.freebsd.org (Postfix) with ESMTP id F29A313C4A3 for ; Thu, 26 Jul 2007 10:56:33 +0000 (UTC) (envelope-from nicolas@boiteameuh.org) Received: from smtp4-g19.free.fr (localhost.localdomain [127.0.0.1]) by smtp4-g19.free.fr (Postfix) with ESMTP id 2871F6F23F for ; Thu, 26 Jul 2007 12:56:33 +0200 (CEST) Received: from popple.boiteameuh.org (popple.boiteameuh.org [82.232.215.170]) by smtp4-g19.free.fr (Postfix) with ESMTP id F0EA86F2D6 for ; Thu, 26 Jul 2007 12:56:32 +0200 (CEST) Received: by popple.boiteameuh.org (Postfix, from userid 1000) id AB26A4EC19; Thu, 26 Jul 2007 12:54:13 +0200 (CEST) Date: Thu, 26 Jul 2007 12:54:13 +0200 To: freebsd-current@freebsd.org Message-ID: <20070726105412.GB24333@boiteameuh.org> References: <20070725121741.GE28450@boiteameuh.org> <46A7886A.5000600@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZfOjI3PrQbgiZnxM" Content-Disposition: inline In-Reply-To: <46A7886A.5000600@FreeBSD.org> User-Agent: Mutt/1.5.13 (2006-08-11) From: nicolas@boiteameuh.org (Nicolas Haller) Subject: Re: Interrupt storm on atapci1+ X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Jul 2007 10:56:34 -0000 --ZfOjI3PrQbgiZnxM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 25, 2007 at 10:29:14AM -0700, Doug Barton wrote: > Nicolas Haller wrote: > > Hi all, > >=20 > > I currently running a FreeBSD-CURRENT on a Intel Core 2 Duo and I seem I > > have a interrupt storm which take approximately 90% of a CPU. > >=20 > > This is the vmstat -i > > nicolas@marcellus:~%vmstat -i > > interrupt total rate > > irq1: atkbd0 2508 0 > > irq17: mskc0 133918 6 > > irq19: fwohci0+ 8288 0 > > irq22: atapci1+ 1174121373 61321 > > irq23: uhci3 ehci1 1 0 > > cpu0: timer 38250554 1997 > > cpu1: timer 38240647 1997 > > Total 1250757289 65323 > >=20 > > I give you my kernel conf. > >=20 > > I don't really know what informations can be useful so feel free to ask > > anything you need. > Make and model of the system would be a good start, along with the > output of 'grep -i irq /var/run/dmesg.boot' The motherboard is an Asus P5K-E on a custom kernel=20 FreeBSD 7.0-CURRENT #0: Mon Jul 23 13:46:17 CEST 2007 The grep output: ioapic0 irqs 0-23 on motherboard pcib1: irq 16 at device 1.0 on pci0 vgapci0: port 0xcc00-0xcc7f mem 0xfd000000-0xfdfff= fff,0xd0000000-0xdfffffff,0xfa000000-0xfbffffff irq 16 at device 0.0 on pci1 uhci0: port 0xb800-0xb81f irq 16 at device = 26.0 on pci0 uhci1: port 0xb880-0xb89f irq 21 at device = 26.1 on pci0 uhci2: port 0xbc00-0xbc1f irq 18 at device = 26.2 on pci0 ehci0: mem 0xf9fffc00-0xf9ffffff irq 18= at device 26.7 on pci0 pcib2: irq 17 at device 28.0 on pci0 pcib3: irq 17 at device 28.4 on pci0 atapci0: port 0xec00-0xec07,0xe880-0xe8= 83,0xe800-0xe807,0xe480-0xe483,0xe400-0xe40f mem 0xfeafe000-0xfeafffff irq = 16 at device 0.0 on pci3 pcib4: irq 16 at device 28.5 on pci0 mskc0: port 0xd800-0xd8ff mem 0xfe= 9fc000-0xfe9fffff irq 17 at device 0.0 on pci2 uhci3: port 0xb080-0xb09f irq 23 at device = 29.0 on pci0 uhci4: port 0xb400-0xb41f irq 19 at device = 29.1 on pci0 uhci5: port 0xb480-0xb49f irq 18 at device = 29.2 on pci0 ehci1: mem 0xf9fff800-0xf9fffbff irq 23= at device 29.7 on pci0 fwohci0: mem 0xfebff000-0xfebfffff irq 19 at device 3.0 = on pci5 atapci1: port 0xa000-0xa007,0x9c00-0x9c03,0x9880-0= x9887,0x9800-0x9803,0x9480-0x948f,0x9400-0x940f irq 22 at device 31.2 on pc= i0 atapci2: port 0xb000-0xb007,0xac00-0xac03,0xa880-0= xa887,0xa800-0xa803,0xa480-0xa48f,0xa400-0xa40f irq 22 at device 31.5 on pc= i0 sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acp= i0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 ata0 at port 0x1f0-0x1f7,0x3f6 irq 14 on isa0 ata1 at port 0x170-0x177,0x376 irq 15 on isa0 sio1: configured irq 3 not in bitmap of probed irqs 0 I also give you my kernel conf I have forget to attach. Cheers, --=20 Nicolas Haller --ZfOjI3PrQbgiZnxM Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGqH1UVrtqUQ7Ko4gRAo7kAJ9uxKxh4NRgWG7Vas18ignqvGog0ACfcHIM TraOyGiKw6tyt407zpx4Ts8= =aHxz -----END PGP SIGNATURE----- --ZfOjI3PrQbgiZnxM-- From owner-freebsd-current@FreeBSD.ORG Thu Jul 26 10:06:00 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 BA80316A420 for ; Thu, 26 Jul 2007 10:06:00 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from redbull.bpaserver.net (redbullneu.bpaserver.net [213.198.78.217]) by mx1.freebsd.org (Postfix) with ESMTP id 7434713C467 for ; Thu, 26 Jul 2007 10:06:00 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (p54A54BE4.dip.t-dialin.net [84.165.75.228]) by redbull.bpaserver.net (Postfix) with ESMTP id 3DACB2E173; Thu, 26 Jul 2007 12:05:46 +0200 (CEST) Received: from webmail.leidinger.net (webmail.Leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id 8BCB35B6125; Thu, 26 Jul 2007 12:03:32 +0200 (CEST) Received: (from www@localhost) by webmail.leidinger.net (8.13.8/8.13.8/Submit) id l6QA3WvU036728; Thu, 26 Jul 2007 12:03:32 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from pslux.cec.eu.int (pslux.cec.eu.int [158.169.9.14]) by webmail.leidinger.net (Horde MIME library) with HTTP; Thu, 26 Jul 2007 12:03:32 +0200 Message-ID: <20070726120332.zu87z36f5wggo0o4@webmail.leidinger.net> X-Priority: 3 (Normal) Date: Thu, 26 Jul 2007 12:03:32 +0200 From: Alexander Leidinger To: William Grzybowski References: <632825b40707251632w6a9451a3s10ece43057821c5c@mail.gmail.com> In-Reply-To: <632825b40707251632w6a9451a3s10ece43057821c5c@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.1.4) / FreeBSD-7.0 X-BPAnet-MailScanner-Information: Please contact the ISP for more information X-BPAnet-MailScanner: Found to be clean X-BPAnet-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-14.823, required 8, BAYES_00 -15.00, DKIM_POLICY_SIGNSOME 0.00, RDNS_DYNAMIC 0.10, TW_SN 0.08) X-BPAnet-MailScanner-From: alexander@leidinger.net X-Spam-Status: No X-Mailman-Approved-At: Thu, 26 Jul 2007 11:15:40 +0000 Cc: freebsd-current@freebsd.org Subject: Re: snd_emu10k1 mixer X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Jul 2007 10:06:00 -0000 Quoting William Grzybowski (from Wed, 25 Jul 2007 20:32:31 -0300): > Hi, > > I upgraded my desktop computer from 6.2-stable to 7.0-current yesterday. > I'm experiencing a little problema with the sound driver snd_emu10k1, it > loads and plays fine, but i can't control the volume/pcm/line/mic using > aumix/xmixer or any other program to control the hardware mixer. Try emu10kx instead of emu10k1. Bye, Alexander. -- You do not have mail. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-current@FreeBSD.ORG Thu Jul 26 11:27: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 C1A8216A41F for ; Thu, 26 Jul 2007 11:27:29 +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 8FCB613C468 for ; Thu, 26 Jul 2007 11:27:27 +0000 (UTC) (envelope-from vova@sw.ru) Received: from vova by vbook.fbsd.ru with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IE1V7-0000lK-D3; Thu, 26 Jul 2007 15:27:25 +0400 From: Vladimir Grebenschikov To: arch@freebsd.org Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: SWsoft Date: Thu, 26 Jul 2007 15:27:24 +0400 Message-Id: <1185449244.1466.18.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 FreeBSD GNOME Team Port Sender: Vladimir Grebenschikov Cc: current Subject: setting dumpdev while boot on 7-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, 26 Jul 2007 11:27:30 -0000 Hi I am trying to figure out how to setup dumpdev while kernel build or from loader. Looks like it is impossible to use old (very old) way with flags. dumpdev loader variable described here: http://freebsd-man.page2go2.com/man8/loader_8.html is not work and event not present any more in laoder.8: ---------------------------- revision 1.70 date: 2004/09/30 15:27:37; author: ru; state: Exp; lines: +0 -7 Setting dump device from loader(8) has not been supported since 2002. ---------------------------- Any hints how it should work ? -- Vladimir B. Grebenschikov SWsoft Inc. vova@swsoft.com From owner-freebsd-current@FreeBSD.ORG Thu Jul 26 13:43: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 C4D9016A421 for ; Thu, 26 Jul 2007 13:43:30 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.freebsd.org (Postfix) with ESMTP id 2BA3513C4CB for ; Thu, 26 Jul 2007 13:43:27 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id D195D456AB; Thu, 26 Jul 2007 15:43:23 +0200 (CEST) Received: from localhost (154.81.datacomsa.pl [195.34.81.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id D2D5845696; Thu, 26 Jul 2007 15:43:13 +0200 (CEST) Date: Thu, 26 Jul 2007 15:42:31 +0200 From: Pawel Jakub Dawidek To: Craig Boston , Dmitry Morozovsky , current@FreeBSD.org Message-ID: <20070726134231.GO12473@garage.freebsd.pl> References: <20070725234322.G33266@woozle.rinet.ru> <20070725222035.GA50522@nowhere> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="FxlYARId5dseejUu" Content-Disposition: inline In-Reply-To: <20070725222035.GA50522@nowhere> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-2.6 required=3.0 tests=BAYES_00 autolearn=ham version=3.0.4 Cc: Subject: Re: ZFS on a notebook/512M settings X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Jul 2007 13:43:30 -0000 --FxlYARId5dseejUu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 25, 2007 at 05:20:35PM -0500, Craig Boston wrote: > I've seen recommendations on the BSD lists to use zil_disable to avoid > low-memory deadlocks (which I've not yet encountered). I've also seen > dire warnings on the OpenSolaris lists about possible data corruption if > you disable the ZIL, so I'm unsure about that one. For now I'm erring > on the side of caution and leaving it enabled until it causes me > problems. Let me explain what disabling ZIL really means. Once ZIL is disabled, fsync(2) is a no-op, ie. calling fsync(2) on a descriptor doesn't mean your data would be safely stored on disk at the time function returns. There is no data corruption for local use, only this fsync(2) problem. "Data corruption" can happen from NFS client point of view, when your ZFS file system is exported over NFS and your NFS server crashes. You can read more details here: http://blogs.sun.com/roch/entry/nfs_and_zfs_a_fine --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --FxlYARId5dseejUu Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFGqKTHForvXbEpPzQRApp4AJ9SpyiQrxBuB31crhB87BMV/XaVIQCfRz+p sgn2MdNnCU4gn+UGZJx+I5Q= =OMNg -----END PGP SIGNATURE----- --FxlYARId5dseejUu-- From owner-freebsd-current@FreeBSD.ORG Thu Jul 26 13:47: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 C862E16A418 for ; Thu, 26 Jul 2007 13:47:39 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id 1A5DB13C4B3 for ; Thu, 26 Jul 2007 13:47:38 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (ppp121-45-48-57.lns11.adl2.internode.on.net [121.45.48.57]) (authenticated bits=0) by cain.gsoft.com.au (8.13.8/8.13.8) with ESMTP id l6QDlWbX088822 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Jul 2007 23:17:34 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-current@freebsd.org Date: Thu, 26 Jul 2007 23:17:28 +0930 User-Agent: KMail/1.9.7 References: <8cdf6c720707070710k2b7e030v37683e460d983bf9@mail.gmail.com> <4690CFAA.30004@gmail.com> <20070726081324.GA2503@obiwan.tataz.chchile.org> In-Reply-To: <20070726081324.GA2503@obiwan.tataz.chchile.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2523710.tt8Rfb7lKx"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200707262317.29530.doconnor@gsoft.com.au> X-Spam-Score: -2.312 () BAYES_00 X-Scanned-By: MIMEDefang 2.58 on 203.31.81.10 Cc: Marc UBM Bocklet , Jeremie Le Hen , Rene Ladan Subject: Re: status of 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, 26 Jul 2007 13:47:39 -0000 --nextPart2523710.tt8Rfb7lKx Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thu, 26 Jul 2007, Jeremie Le Hen wrote: > > configuaration option, it shouldn't be necessary to rebuild all > > your ports. > > I'd like to add that whenever I performed an upgrade between two > FreeBSD major branch I found easier to use sysutils/etcmerge than > mergemaster(8) to upgrade /etc, as the former is far more automated > and prevents a lot of work due to the huge number of changes to > merge. > > Important note (also explained in the "ROUGH DESCRIPTION OF USE" part > of etcmerge manpage): > 1) Make sure your current /etc is up-to-date (IOW run mergemaster(8)) > WRT your current RELENG_6 source tree; > 2) Follow etcmerge manpage to get /var/db/etc corresponding to the > _stock_ /etc directory from your source tree. etcmerge is nice, although I have found it does try to merge the .db=20 files which result in bogus conflicts (just delete the .db files and=20 rebuild the alias, password and/or terminal cap. DB). It's also nice because it doesn't touch your /etc until after everything=20 is merged. =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart2523710.tt8Rfb7lKx 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) iD8DBQBGqKXx5ZPcIHs/zowRAgEyAJ9eL7RGe25Fg/ej/lGav1GILVVGwgCgo39m 6tgPPvH5Zm0aeg4gre1cb64= =Q92l -----END PGP SIGNATURE----- --nextPart2523710.tt8Rfb7lKx-- From owner-freebsd-current@FreeBSD.ORG Thu Jul 26 13:58: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 117B416A479; Thu, 26 Jul 2007 13:58:05 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 0BA3013C4EE; Thu, 26 Jul 2007 13:57:58 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from rot26.obsecurity.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id 4000D1A3C1A; Thu, 26 Jul 2007 06:57:58 -0700 (PDT) Received: by rot26.obsecurity.org (Postfix, from userid 1001) id EFB66BA04; Thu, 26 Jul 2007 09:57:57 -0400 (EDT) Date: Thu, 26 Jul 2007 09:57:57 -0400 From: Kris Kennaway To: Vladimir Grebenschikov Message-ID: <20070726135757.GA50761@rot26.obsecurity.org> References: <1185449244.1466.18.camel@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1185449244.1466.18.camel@localhost> User-Agent: Mutt/1.4.2.3i Cc: arch@freebsd.org, current Subject: Re: setting dumpdev while boot on 7-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, 26 Jul 2007 13:58:05 -0000 On Thu, Jul 26, 2007 at 03:27:24PM +0400, Vladimir Grebenschikov wrote: > Hi > > I am trying to figure out how to setup dumpdev while kernel build or > from loader. > > Looks like it is impossible to use old (very old) way with flags. > > dumpdev loader variable described here: > http://freebsd-man.page2go2.com/man8/loader_8.html > > is not work and event not present any more in laoder.8: > ---------------------------- > revision 1.70 > date: 2004/09/30 15:27:37; author: ru; state: Exp; lines: +0 -7 > Setting dump device from loader(8) has not been supported since 2002. > ---------------------------- > > Any hints how it should work ? Unfortunately it has not been supported since (apparently) 2002. Kris From owner-freebsd-current@FreeBSD.ORG Thu Jul 26 14:01:14 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 1FAE416A417; Thu, 26 Jul 2007 14:01:14 +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 0689313C45D; Thu, 26 Jul 2007 14:01:13 +0000 (UTC) (envelope-from craig@xfoil.gank.org) Received: by ion.gank.org (Postfix, from userid 1001) id C20431125D; Thu, 26 Jul 2007 09:01:13 -0500 (CDT) Date: Thu, 26 Jul 2007 09:01:13 -0500 From: Craig Boston To: Pawel Jakub Dawidek Message-ID: <20070726140113.GA49713@nowhere> References: <20070725234322.G33266@woozle.rinet.ru> <20070725222035.GA50522@nowhere> <20070726134231.GO12473@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070726134231.GO12473@garage.freebsd.pl> User-Agent: Mutt/1.4.2.2i Cc: Dmitry Morozovsky , current@FreeBSD.org Subject: Re: ZFS on a notebook/512M settings X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Jul 2007 14:01:14 -0000 On Thu, Jul 26, 2007 at 03:42:31PM +0200, Pawel Jakub Dawidek wrote: > Let me explain what disabling ZIL really means. Once ZIL is disabled, > fsync(2) is a no-op, ie. calling fsync(2) on a descriptor doesn't mean > your data would be safely stored on disk at the time function returns. > There is no data corruption for local use, only this fsync(2) problem. > > "Data corruption" can happen from NFS client point of view, when your > ZFS file system is exported over NFS and your NFS server crashes. Does this increase the window after an fsync is performed that a crash or power loss will lose recent changes? That's what I got from reading the descriptions of ZIL, perhaps "corruption" was a poor choice of words. Craig From owner-freebsd-current@FreeBSD.ORG Thu Jul 26 14:09: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 ECD2E16A417 for ; Thu, 26 Jul 2007 14:09:13 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id 4AD6013C4A3 for ; Thu, 26 Jul 2007 14:09:13 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (ppp121-45-48-57.lns11.adl2.internode.on.net [121.45.48.57]) (authenticated bits=0) by cain.gsoft.com.au (8.13.8/8.13.8) with ESMTP id l6QE99lO089272 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Jul 2007 23:39:11 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-current@freebsd.org Date: Thu, 26 Jul 2007 23:39:06 +0930 User-Agent: KMail/1.9.7 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3992904.11IkSNUcHl"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200707262339.07171.doconnor@gsoft.com.au> X-Spam-Score: -2.312 () BAYES_00 X-Scanned-By: MIMEDefang 2.58 on 203.31.81.10 Subject: Can't build -current on a 6.2 box X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Jul 2007 14:09:14 -0000 --nextPart3992904.11IkSNUcHl Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline I have a box here I want to use to play around with -current but I can't build it. I had built an earlier -current on it (pre GCC 4.2) but that one didn't see my disks so I am trying again, alas now I am getting.. cc -O1 -pipe -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=3D\"/usr/obj/usr/src/tmp/usr= \" -I/usr/obj /usr/src/tmp/usr/src/gnu/usr.bin/cc/cc_int/../cc_tools -I/usr/src/gnu/usr.b= in/cc/cc_in t/../cc_tools -I/usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc -I/u= sr/src/gnu/ usr.bin/cc/cc_int/../../../../contrib/gcc/config -I/usr/src/gnu/usr.bin/cc/= cc_int/../. =2E/../../contrib/gcclibs/include -I/usr/src/gnu/usr.bin/cc/cc_int/../../..= /../contrib/g cclibs/libcpp/include -I/usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/= gcclibs/lib decnumber -I/usr/obj/usr/src/tmp/legacy/usr/include -c /usr/src/gnu/usr.bi= n/cc/cc_int /../../../../contrib/gcc/modulo-sched.c cc -O1 -pipe -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=3D\"/usr/obj/usr/src/tmp/usr= \" -I/usr/obj /usr/src/tmp/usr/src/gnu/usr.bin/cc/cc_int/../cc_tools -I/usr/src/gnu/usr.b= in/cc/cc_in t/../cc_tools -I/usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc -I/u= sr/src/gnu/ usr.bin/cc/cc_int/../../../../contrib/gcc/config -I/usr/src/gnu/usr.bin/cc/= cc_int/../. =2E/../../contrib/gcclibs/include -I/usr/src/gnu/usr.bin/cc/cc_int/../../..= /../contrib/g cclibs/libcpp/include -I/usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/= gcclibs/lib decnumber -I/usr/obj/usr/src/tmp/legacy/usr/include -c /usr/src/gnu/usr.bi= n/cc/cc_int /../../../../contrib/gcc/optabs.c cc1: out of memory allocating 97582896 bytes *** Error code 1 # uname -a =46reeBSD 6.2-RELEASE FreeBSD 6.2-RELEASE #0: Fri Jan 12 11:05:30 UTC=20 2007 root@dessler.cse.buffalo.edu:/usr/obj/usr/src/sys/SMP i386 # gcc -v Using built-in specs. Configured with: FreeBSD/i386 system compiler Thread model: posix gcc version 3.4.6 [FreeBSD] 20060305 This system has 2GB of RAM and 2GB of swap. The full log is at http://www.dons.net.au/~darius/buildworld.log.gz MD5 (buildworld.log.gz) =3D 1e7c45f61fdadb7533a97e98f4216322 I don't have any non-default malloc options and make.conf only has a=20 WRKDIRPREFIX setting in it. =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart3992904.11IkSNUcHl 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) iD8DBQBGqKsD5ZPcIHs/zowRAt9kAKCDpay5rRVRm6PVbGVNyAlthEq+1QCeLSAs umEbbWBXeR5NIa9B+9KeDAs= =dnRZ -----END PGP SIGNATURE----- --nextPart3992904.11IkSNUcHl-- From owner-freebsd-current@FreeBSD.ORG Thu Jul 26 15:29: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 AECAA16A417 for ; Thu, 26 Jul 2007 15:29:32 +0000 (UTC) (envelope-from lists@billsf.net) Received: from billsf.net (billsf.net [213.130.164.21]) by mx1.freebsd.org (Postfix) with ESMTP id 77AB913C465 for ; Thu, 26 Jul 2007 15:29:31 +0000 (UTC) (envelope-from lists@billsf.net) Received: by billsf.net (Postfix, from userid 1004) id 738622900D6; Thu, 26 Jul 2007 13:52:06 +0200 (CEST) Date: Thu, 26 Jul 2007 13:52:06 +0200 From: FreeBSD Mailing Lists To: freebsd-current@freebsd.org Message-ID: <20070726115206.GA61702@curacao.billsf.net> 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: Thu, 26 Jul 2007 15:35:05 +0000 Subject: emu10kx and related Creative drivers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Jul 2007 15:29:32 -0000 Anybody have the X-Fi series from Creative working? I've got the Open source OSS drivers and have removed a few coding errors that work in Stable but bomb in Current. Still it whacks my SMP machine before it can dump core. Please note that the CS4382 is a fine chip and as usual Creative re-arranges the commands on their bridge. To get a feel for their tricks, I put a AD1980 (also a very fine chip) in an old Ensonic card. The PCM and the Vol work, but the bridge is cryptic. Fortunately this one is cracked. (They used a custom 'pin-for-pin' soundchip with a different command set. The Cirrus Logic is freely documented, so it won't be long. I don't understand. The more platforms the better -- always! In the meantime, I soldered up a tiny USB soundcard with a C-Media CM108. These are good -- better than 'CD quality' for about five bucks. At 50 its nice to know I can solder that small stuff. It works with FreeBSD, Mac, but not Linux. Its said to work with Windows, but probably not with the standard values of components. (Windows compatibility is largely a hardware issue.) Watch out about the CM106. It is very flaky. At 3x1x0.5cm, it may be the smallest soundcard? Get data and samples from . This chip is programmable by its pins or a small eeprom. If I can't fix this crazy driver, I may give the X-Fi to a gamer and get a envy24ht, the "audiophile" having four studio quality A/Ds (and four outs). The sound is very good on FreeBSD -- at the top. BillSF From owner-freebsd-current@FreeBSD.ORG Thu Jul 26 16:33: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 1D37E16A5A8; Thu, 26 Jul 2007 16:33:55 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 0DB1A13C45D; Thu, 26 Jul 2007 16:33:55 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from rot26.obsecurity.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id 1695E1A4D81; Thu, 26 Jul 2007 09:33:54 -0700 (PDT) Received: by rot26.obsecurity.org (Postfix, from userid 1001) id 70F8CBAEA; Thu, 26 Jul 2007 12:33:54 -0400 (EDT) Date: Thu, 26 Jul 2007 12:33:54 -0400 From: Kris Kennaway To: current@FreeBSD.org, pho@FreeBSD.org Message-ID: <20070726163354.GA54953@rot26.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/9DWx/yDrRhgMJTb" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: Subject: Minor miracle X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Jul 2007 16:33:55 -0000 --/9DWx/yDrRhgMJTb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Before I went on holidays a month ago I accidentally left stress2 running on this dual p4+htt system. haessal# uname -a FreeBSD haessal.kr.freebsd.org 7.0-CURRENT FreeBSD 7.0-CURRENT #: Fri Jun 15 10:51:54 KST 2007 kris@haessal.kr.freebsd.org:/usr/src/sys/i386/compile/HAESSAL i386 haessal# uptime 1:22AM up 38 days, 8:30, 3 users, load averages: 281.90, 477.87, 845.29 It survived ;) Kris --/9DWx/yDrRhgMJTb Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFGqMzxWry0BWjoQKURAmq4AKCoHWcrW+7ICW0ksVaLsfSz7Xp5zwCg0tD2 sUqxjo3KwpU/DrlIdcFh7aE= =P40z -----END PGP SIGNATURE----- --/9DWx/yDrRhgMJTb-- From owner-freebsd-current@FreeBSD.ORG Thu Jul 26 17:35: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 3EBB716A417 for ; Thu, 26 Jul 2007 17:35:16 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.236]) by mx1.freebsd.org (Postfix) with ESMTP id 8D2F813C45A for ; Thu, 26 Jul 2007 17:35:15 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: by wr-out-0506.google.com with SMTP id i23so367888wra for ; Thu, 26 Jul 2007 10:35:14 -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:subject:message-id:mail-followup-to:mime-version:content-type:content-disposition:user-agent; b=RxsOAqSXEuPPKuF+XvQPj/004zczK1b0Sv+YdUOFOul000UcNTOsny1NRBUtqPUO9rUvSj3/HwPBPMGCQioPuat3RWH4V35o51qgPAjJy+MYVVWyUNozM2cKHT5Wy5iMQohz9/ted4ttUaG0njOdcEf98YCnGM/xDqAkCvqclRU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:date:from:to:subject:message-id:mail-followup-to:mime-version:content-type:content-disposition:user-agent; b=mk9wrQTjqApzH+EXshEfAMtKsmYgq+yGkUbUc+VNEGg6SoAc7dUKBU/KeDLAuhXQMm5+GZKs7BZyf8/l1Sn6UYqzB1WcxetMdqIJs9Xk8304+Gc0IpFle/driKjVi54VCZnsKvVm4zwCl6ZxIIObRQGaFtwgJ81ipL4+6pIZ4CY= Received: by 10.78.170.17 with SMTP id s17mr490186hue.1185471308086; Thu, 26 Jul 2007 10:35:08 -0700 (PDT) Received: from roadrunner.q.local ( [85.180.183.129]) by mx.google.com with ESMTPS id q1sm1944233uge.2007.07.26.10.35.07 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 26 Jul 2007 10:35:07 -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 l6QHZ6ph004209 for ; Thu, 26 Jul 2007 19:35:06 +0200 (CEST) (envelope-from uspoerlein@gmail.com) Received: (from q@localhost) by roadrunner.q.local (8.14.1/8.14.1/Submit) id l6QHZ6To004208 for current@freebsd.org; Thu, 26 Jul 2007 19:35:06 +0200 (CEST) (envelope-from uspoerlein@gmail.com) Date: Thu, 26 Jul 2007 19:35:06 +0200 From: Ulrich Spoerlein To: current@freebsd.org Message-ID: <20070726173506.GE1857@roadrunner.q.local> Mail-Followup-To: current@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: Subject: net/twinkle stuck in _umtx_op syscall X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Jul 2007 17:35:16 -0000 Gentlemen, I had trouble running twinkle back on 6-STABLE but now on -CURRENT it's similar. A ktrace of the session reveals the following 4019 twinkle 0.000273 CALL gettimeofday(0xbf2f7cec,0) 4019 twinkle 0.000009 RET gettimeofday 0 4019 twinkle 0.000518 CALL sigprocmask(SIG_BLOCK,0,0x29e09508) 4019 twinkle 0.000009 RET sigprocmask 0 4019 twinkle 0.000067 CALL ioctl(0x8,FIONREAD,0xbf2f7bb8) 4019 twinkle 0.000017 RET ioctl 0 4019 twinkle 0.000015 CALL ioctl(0x8,FIONREAD,0xbf2f7ba8) 4019 twinkle 0.000015 RET ioctl 0 4019 twinkle 0.000143 CALL ioctl(0x8,FIONREAD,0xbf2f7b38) 4019 twinkle 0.000016 RET ioctl 0 4019 twinkle 0.000007 CALL ioctl(0x8,FIONREAD,0xbf2f7b28) 4019 twinkle 0.000005 RET ioctl 0 4019 twinkle 0.000006 CALL ioctl(0x8,FIONREAD,0xbf2f7b28) 4019 twinkle 0.000014 RET ioctl 0 4019 twinkle 0.000011 CALL ioctl(0x8,FIONREAD,0xbf2f7b18) 4019 twinkle 0.000006 RET ioctl 0 4019 twinkle 0.000014 CALL _umtx_op(0x2a2e7e80,0x5,0,0,0) 4019 twinkle 0.001670 RET _umtx_op 0 4019 twinkle 0.000013 CALL getitimer(0,0xbf6fbf4c) 4019 twinkle 0.000005 RET getitimer 0 4019 twinkle 0.000023 CALL _umtx_op(0x29e1985c,0x2,0,0,0) 4019 twinkle 4.361916 RET _umtx_op -1 errno 4 Interrupted system call 4019 twinkle 0.000044 PSIG SIGKILL SIG_DFL It can only be killed -9 and will otherwise stick in _umtx_op() forever. Any clue from the threading guys on what tricks I should try? My libmap.conf is emtpy, twinkle is linked against the following binaries: /usr/local/bin/twinkle: libsndfile.so.1 => /usr/local/lib/libsndfile.so.1 (0x283a0000) libccext2-1.5.so.0 => /usr/local/lib/libccext2-1.5.so.0 (0x283ff000) libgnutls.so.15 => /usr/local/lib/libgnutls.so.15 (0x28441000) libgcrypt.so.13 => /usr/local/lib/libgcrypt.so.13 (0x284bb000) libz.so.4 => /lib/libz.so.4 (0x2850a000) libccrtp1-1.5.so.0 => /usr/local/lib/libccrtp1-1.5.so.0 (0x2851c000) libccgnu2-1.5.so.0 => /usr/local/lib/libccgnu2-1.5.so.0 (0x28542000) librt.so.1 => /usr/lib/librt.so.1 (0x28594000) libkdecore.so.6 => /usr/local/lib/libkdecore.so.6 (0x28599000) libkdeui.so.6 => /usr/local/lib/libkdeui.so.6 (0x287d3000) libkabc.so.3 => /usr/local/lib/libkabc.so.3 (0x28aaa000) libspeex.so.1 => /usr/local/lib/libspeex.so.1 (0x28b5d000) libilbc.so.0 => /usr/local/lib/libilbc.so.0 (0x28b7d000) libzrtpcpp-0.9.so.0 => /usr/local/lib/libzrtpcpp-0.9.so.0 (0x28b8c000) libboost_regex.so => /usr/local/lib/libboost_regex.so (0x28bab000) libqt-mt.so.3 => /usr/local/lib/libqt-mt.so.3 (0x28c39000) libXext.so.6 => /usr/local/lib/libXext.so.6 (0x2930b000) libX11.so.6 => /usr/local/lib/libX11.so.6 (0x29319000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x29405000) libm.so.5 => /lib/libm.so.5 (0x294ed000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x29503000) libthr.so.3 => /lib/libthr.so.3 (0x2950e000) libc.so.7 => /lib/libc.so.7 (0x29521000) libFLAC.so.7 => /usr/local/lib/libFLAC.so.7 (0x29623000) libgpg-error.so.0 => /usr/local/lib/libgpg-error.so.0 (0x29656000) libintl.so.8 => /usr/local/lib/libintl.so.8 (0x2965a000) libiconv.so.3 => /usr/local/lib/libiconv.so.3 (0x29663000) libDCOP.so.6 => /usr/local/lib/libDCOP.so.6 (0x29751000) libutil.so.7 => /lib/libutil.so.7 (0x29783000) libart_lgpl_2.so.5 => /usr/local/lib/libart_lgpl_2.so.5 (0x29790000) libidn.so.16 => /usr/local/lib/libidn.so.16 (0x297a6000) libkdefx.so.6 => /usr/local/lib/libkdefx.so.6 (0x297d7000) libjpeg.so.9 => /usr/local/lib/libjpeg.so.9 (0x297ff000) libvcard.so.0 => /usr/local/lib/libvcard.so.0 (0x2981e000) libkio.so.6 => /usr/local/lib/libkio.so.6 (0x29842000) libkresources.so.3 => /usr/local/lib/libkresources.so.3 (0x29b82000) libmng.so.1 => /usr/local/lib/libmng.so.1 (0x29ba4000) libpng.so.5 => /usr/local/lib/libpng.so.5 (0x29c05000) libXi.so.6 => /usr/local/lib/libXi.so.6 (0x29c2a000) libXrender.so.1 => /usr/local/lib/libXrender.so.1 (0x29c32000) libXrandr.so.2 => /usr/local/lib/libXrandr.so.2 (0x29c3a000) libXcursor.so.1 => /usr/local/lib/libXcursor.so.1 (0x29c41000) libXinerama.so.1 => /usr/local/lib/libXinerama.so.1 (0x29c4a000) libXft.so.2 => /usr/local/lib/libXft.so.2 (0x29c4d000) libfreetype.so.9 => /usr/local/lib/libfreetype.so.9 (0x29c5f000) libfontconfig.so.1 => /usr/local/lib/libfontconfig.so.1 (0x29cc9000) libSM.so.6 => /usr/local/lib/libSM.so.6 (0x29cf3000) libICE.so.6 => /usr/local/lib/libICE.so.6 (0x29cfc000) libXau.so.6 => /usr/local/lib/libXau.so.6 (0x29d13000) libXdmcp.so.6 => /usr/local/lib/libXdmcp.so.6 (0x29d16000) librpcsvc.so.4 => /usr/lib/librpcsvc.so.4 (0x29d1b000) libkdesu.so.6 => /usr/local/lib/libkdesu.so.6 (0x29d24000) libkwalletclient.so.1 => /usr/local/lib/libkwalletclient.so.1 (0x29d3c000) libfam.so.0 => /usr/local/lib/libfam.so.0 (0x29d4d000) liblcms.so.1 => /usr/local/lib/liblcms.so.1 (0x29d55000) libXfixes.so.3 => /usr/local/lib/libXfixes.so.3 (0x29d84000) libexpat.so.6 => /usr/local/lib/libexpat.so.6 (0x29d89000) Cheers, Ulrich Spoerlein -- "It is better to remain silent and be thought a fool, than to speak, and remove all doubt." From owner-freebsd-current@FreeBSD.ORG Thu Jul 26 18:15:15 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 DECB716A41A for ; Thu, 26 Jul 2007 18:15:15 +0000 (UTC) (envelope-from pho@holm.cc) Received: from relay03.pair.com (relay03.pair.com [209.68.5.17]) by mx1.freebsd.org (Postfix) with SMTP id 7781713C46B for ; Thu, 26 Jul 2007 18:15:15 +0000 (UTC) (envelope-from pho@holm.cc) Received: (qmail 61646 invoked from network); 26 Jul 2007 17:48:34 -0000 Received: from 83.95.197.164 (HELO peter.osted.lan) (83.95.197.164) by relay03.pair.com with SMTP; 26 Jul 2007 17:48:34 -0000 X-pair-Authenticated: 83.95.197.164 Received: from peter.osted.lan (localhost.osted.lan [127.0.0.1]) by peter.osted.lan (8.13.6/8.13.6) with ESMTP id l6QHmX1d093658; Thu, 26 Jul 2007 19:48:33 +0200 (CEST) (envelope-from pho@peter.osted.lan) Received: (from pho@localhost) by peter.osted.lan (8.13.6/8.13.6/Submit) id l6QHmX7G093657; Thu, 26 Jul 2007 19:48:33 +0200 (CEST) (envelope-from pho) Date: Thu, 26 Jul 2007 19:48:33 +0200 From: Peter Holm To: Kris Kennaway Message-ID: <20070726174833.GA93543@peter.osted.lan> References: <20070726163354.GA54953@rot26.obsecurity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070726163354.GA54953@rot26.obsecurity.org> User-Agent: Mutt/1.4.2.1i Cc: current@FreeBSD.org Subject: Re: Minor miracle X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Jul 2007 18:15:16 -0000 On Thu, Jul 26, 2007 at 12:33:54PM -0400, Kris Kennaway wrote: > Before I went on holidays a month ago I accidentally left stress2 > running on this dual p4+htt system. > > haessal# uname -a > FreeBSD haessal.kr.freebsd.org 7.0-CURRENT FreeBSD 7.0-CURRENT #: Fri Jun 15 10:51:54 KST 2007 kris@haessal.kr.freebsd.org:/usr/src/sys/i386/compile/HAESSAL i386 > haessal# uptime > 1:22AM up 38 days, 8:30, 3 users, load averages: 281.90, 477.87, 845.29 > > It survived ;) > > Kris That's a record :-) -- Peter Holm From owner-freebsd-current@FreeBSD.ORG Thu Jul 26 18:58:49 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 6B0F916A419 for ; Thu, 26 Jul 2007 18:58:49 +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 33C1D13C45A for ; Thu, 26 Jul 2007 18:58:49 +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 l6QIwkkF014195 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Jul 2007 14:58:46 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.12.9p2/8.12.9/Submit) id l6QIwIxL014253; Thu, 26 Jul 2007 14:58:18 -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: <18088.61153.369771.398961@grasshopper.cs.duke.edu> Date: Thu, 26 Jul 2007 14:58:18 -0400 (EDT) To: Andrew Moran In-Reply-To: References: X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Cc: freebsd-current@freebsd.org Subject: Re: FreeBSD on intel Mac X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Jul 2007 18:58:49 -0000 Andrew Moran writes: > > Is it the case that I can install and boot freebsd on an intel mac > (uses EFI, not BIOS) currently (without using Boot Camp), or do I > have to wait until FreeBSD 7 for this functionality? There are various gotachs with Intel Macs: When you have an Apple GPT partitioned disk, you may need to install from 6.x. This is because libdisk causes sysinstall to exit (leading to "going nowhere without my init") when libdisk crashes with "BARF ...." You can't install a non-EFI native OS on an external firewire drive and be able to boot it (at least on my iMac). I tried various partition styles (pure MBR, plus MBR + GPT), booting by selecting "windows" from the alt-key menu, booting via rEFIt, Ubuntu Fiesty in addition to FreeBSD, etc. That's about 8 or 12 hours of my life I'll never get back :( Is anybody working on an EFI loader? Drew From owner-freebsd-current@FreeBSD.ORG Thu Jul 26 18:43: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 4C89416A41A; Thu, 26 Jul 2007 18:43:36 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (mail.soaustin.net [207.200.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 31AE213C428; Thu, 26 Jul 2007 18:43:36 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: by mail.soaustin.net (Postfix, from userid 502) id ACBAD35D; Thu, 26 Jul 2007 13:43:32 -0500 (CDT) Date: Thu, 26 Jul 2007 13:43:32 -0500 To: "Sam Fourman Jr." Message-ID: <20070726184332.GD13587@soaustin.net> References: <8cdf6c720707070710k2b7e030v37683e460d983bf9@mail.gmail.com> <20070708111105.C9997@fledge.watson.org> <11167f520707260147l2978b521h761c01a27da6cea7@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <11167f520707260147l2978b521h761c01a27da6cea7@mail.gmail.com> User-Agent: Mutt/1.5.9i From: linimon@lonesome.com (Mark Linimon) X-Mailman-Approved-At: Thu, 26 Jul 2007 18:58:55 +0000 Cc: Paul Eskello , freebsd-current@freebsd.org, Robert Watson Subject: Re: status of 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, 26 Jul 2007 18:43:36 -0000 On Thu, Jul 26, 2007 at 03:47:14AM -0500, Sam Fourman Jr. wrote: > does anyone know if the july snapshots for 7.0 are going to get built? > maybe i am looking in the wrong spot but I didn't see them yet The last I heard, they were being held off a bit to let the various changes that are going into -current settle down a bit. mcl From owner-freebsd-current@FreeBSD.ORG Thu Jul 26 18:50: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 EE15F16A418 for ; Thu, 26 Jul 2007 18:50:34 +0000 (UTC) (envelope-from matheusber@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 C881413C461 for ; Thu, 26 Jul 2007 18:50:34 +0000 (UTC) (envelope-from matheusber@gmail.com) Received: by wa-out-1112.google.com with SMTP id k17so411520waf for ; Thu, 26 Jul 2007 11:50: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:mime-version:content-type:content-transfer-encoding:content-disposition; b=GtQRR5pRO1m+ANNeHsJ3sFb3WPqIJchUVSG8JobVspHn8sCJOuiWRCTDLSWcbZlQ8nr64eRn4JnFW/gzMMzsirpp62fymHbUVE4qc/28EtR0PzF/g1NnU63QeJi17ZZfNmdaCXfLsidRCgOKkE2N2fi7YfSoDeB7uaQCs09tyGk= 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=GGFmrfA91elaGMda1wkxbLYToG8m0I1cWj0EWuZzU/aC0qHm+4WDmqVBNK4UAlcRDYHsZWLUvJXgzlcRoJ0KdCxFQHLOch5ZHayvZ2FYgqCxsvb+peYKsmNJm9D7Z5HiPGS10fbs9AzyfSkwqjr82ve4y/g9wZZ/u2n7GK+GdNw= Received: by 10.114.124.1 with SMTP id w1mr2057944wac.1185474125630; Thu, 26 Jul 2007 11:22:05 -0700 (PDT) Received: by 10.115.78.4 with HTTP; Thu, 26 Jul 2007 11:22:05 -0700 (PDT) Message-ID: <4956a5e50707261122r54856ec2w6b8eaea663a01c16@mail.gmail.com> Date: Thu, 26 Jul 2007 15:22:05 -0300 From: Nenhum_de_Nos 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-Mailman-Approved-At: Thu, 26 Jul 2007 18:59:16 +0000 Subject: tcp messages I've never seen now in Current and atheros interrupt storm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Jul 2007 18:50:35 -0000 This is a Storage server (my own home) and apart from this there is a MLdonkey client running. It runs: FreeBSD lamneth 7.0-CURRENT FreeBSD 7.0-CURRENT #2: Fri Jul 20 02:04:15 BRT 2007 root@lamneth:/usr/obj/usr/src/sys/Lamneth_7 i386 and my /var/log/messages is filled with: Jul 26 12:18:38 lamneth kernel: TCP: [201.63.35.2]:3605 to [192.168.254.10]:10010; syncache_socket: Socket create failed due to limits or memory shortage Jul 26 12:18:38 lamneth kernel: TCP: [201.63.35.2]:3605 to [192.168.254.10]:10010 tcpflags 0x18; tcp_input: Listen socket: Socket allocation failed due to limits or memory shortage, sending RST Jul 26 12:20:07 lamneth kernel: TCP: [201.39.120.62]:1744 to [192.168.254.10]:10010; syncache_socket: Socket create failed due to limits or memory shortage Jul 26 12:20:07 lamneth kernel: TCP: [201.39.120.62]:1744 to [192.168.254.10]:10010 tcpflags 0x10; tcp_input: Listen socket: Socket allocation failed due to limits or memory shortage, sending RST Jul 26 12:20:07 lamneth kernel: TCP: [201.39.120.62]:1744 to [192.168.254.10]:10010; syncache_socket: Socket create failed due to limits or memory shortage Jul 26 12:20:07 lamneth kernel: TCP: [201.39.120.62]:1744 to [192.168.254.10]:10010 tcpflags 0x18; tcp_input: Listen socket: Socket allocation failed due to limits or memory shortage, sending RST Jul 26 12:20:07 lamneth kernel: TCP: [60.44.1.249]:2113 to [192.168.254.10]:10010; syncache_socket: Socket create failed due to limits or memory shortage Jul 26 12:20:07 lamneth kernel: TCP: [60.44.1.249]:2113 to [192.168.254.10]:10010 tcpflags 0x10; tcp_input: Listen socket: Socket allocation failed due to limits or memory shortage, sending RST Jul 26 12:20:07 lamneth kernel: TCP: [60.44.1.249]:2113 to [192.168.254.10]:10010; syncache_socket: Socket create failed due to limits or memory shortage Jul 26 12:20:07 lamneth kernel: TCP: [60.44.1.249]:2113 to [192.168.254.10]:10010 tcpflags 0x18; tcp_input: Listen socket: Socket allocation failed due to limits or memory shortage, sending RST Jul 26 12:20:08 lamneth kernel: TCP: [200.175.83.109]:50797 to [192.168.254.10]:10010; syncache_socket: Socket create failed due to limits or memory shortage Jul 26 12:20:08 lamneth kernel: TCP: [200.175.83.109]:50797 to [192.168.254.10]:10010 tcpflags 0x10; tcp_input: Listen socket: Socket allocation failed due to limits or memory shortage, sending RST Jul 26 12:20:08 lamneth kernel: TCP: [200.175.83.109]:50797 to [192.168.254.10]:10010; syncache_socket: Socket create failed due to limits or memory shortage Jul 26 12:20:08 lamneth kernel: TCP: [200.175.83.109]:50797 to [192.168.254.10]:10010 tcpflags 0x18; tcp_input: Listen socket: Socket allocation failed due to limits or memory shortage, sending RST Jul 26 12:20:08 lamneth kernel: TCP: [201.39.120.62]:1758 to [192.168.254.10]:10010; syncache_socket: Socket create failed due to limits or memory shortage Jul 26 12:20:08 lamneth kernel: TCP: [201.39.120.62]:1758 to [192.168.254.10]:10010 tcpflags 0x10; tcp_input: Listen socket: Socket allocation failed due to limits or memory shortage, sending RST Jul 26 12:20:08 lamneth kernel: TCP: [201.39.120.62]:1758 to [192.168.254.10]:10010; syncache_socket: Socket create failed due to limits or memory shortage Jul 26 12:20:08 lamneth kernel: TCP: [201.39.120.62]:1758 to [192.168.254.10]:10010 tcpflags 0x18; tcp_input: Listen socket: Socket allocation failed due to limits or memory shortage, sending RST Jul 26 12:20:08 lamneth kernel: TCP: [201.39.120.62]:1760 to [192.168.254.10]:10010; syncache_socket: Socket create failed due to limits or memory shortage Jul 26 12:20:08 lamneth kernel: TCP: [201.39.120.62]:1760 to [192.168.254.10]:10010 tcpflags 0x10; tcp_input: Listen socket: Socket allocation failed due to limits or memory shortage, sending RST Jul 26 12:20:08 lamneth kernel: TCP: [201.39.120.62]:1760 to [192.168.254.10]:10010; syncache_socket: Socket create failed due to limits or memory shortage Jul 26 12:20:08 lamneth kernel: TCP: [201.39.120.62]:1760 to [192.168.254.10]:10010 tcpflags 0x18; tcp_input: Listen socket: Socket allocation failed due to limits or memory shortage, sending RST Jul 26 12:20:08 lamneth kernel: TCP: [201.39.120.62]:1762 to [192.168.254.10]:10010; syncache_socket: Socket create failed due to limits or memory shortage Jul 26 12:20:08 lamneth kernel: TCP: [201.39.120.62]:1762 to [192.168.254.10]:10010 tcpflags 0x10; tcp_input: Listen socket: Socket allocation failed due to limits or memory shortage, sending RST Jul 26 12:20:08 lamneth kernel: TCP: [201.39.120.62]:1762 to [192.168.254.10]:10010; syncache_socket: Socket create failed due to limits or memory shortage Jul 26 12:20:08 lamneth kernel: TCP: [201.39.120.62]:1762 to [192.168.254.10]:10010 tcpflags 0x18; tcp_input: Listen socket: Socket allocation failed due to limits or memory shortage, sending RST Jul 26 12:20:09 lamneth kernel: TCP: [87.18.103.17]:1606 to [192.168.254.10]:10010; syncache_socket: Socket create failed due to limits or memory shortage Jul 26 12:20:09 lamneth kernel: TCP: [87.18.103.17]:1606 to [192.168.254.10]:10010 tcpflags 0x10; tcp_input: Listen socket: Socket allocation failed due to limits or memory shortage, sending RST Jul 26 12:20:09 lamneth kernel: TCP: [87.18.103.17]:1606 to [192.168.254.10]:10010; syncache_socket: Socket create failed due to limits or memory shortage Jul 26 12:20:09 lamneth kernel: TCP: [87.18.103.17]:1606 to [192.168.254.10]:10010 tcpflags 0x18; tcp_input: Listen socket: Socket allocation failed due to limits or memory shortage, sending RST Jul 26 12:20:09 lamneth kernel: TCP: [88.8.22.46]:2830 to [192.168.254.10]:10010; syncache_socket: Socket create failed due to limits or memory shortage Jul 26 12:20:09 lamneth kernel: TCP: [88.8.22.46]:2830 to [192.168.254.10]:10010 tcpflags 0x18; tcp_input: Listen socket: Socket allocation failed due to limits or memory shortage, sending RST Jul 26 12:20:10 lamneth kernel: TCP: [60.29.8.98]:32191 to [192.168.254.10]:10010 tcpflags 0x11; syncache_expand: Segment failed SYNCOOKIE authentication, segment rejected (probably spoofed) I've never seen these messages, as before this machine was running 6.2-R (vanilla, neve updated) 10010 is edonkey tcp port and also, this is an hostapd based AP for my home, but bridging never works and always when ath0 is enabled, there is an interrupt storm. I cant show here, as my logs are filled with these tcp messages ... the message on google just returned the .c code file, so, if anyone has a clue ... thanks matheus -- We will call you cygnus, The God of balance you shall be From owner-freebsd-current@FreeBSD.ORG Thu Jul 26 19:07: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 793F716A41A for ; Thu, 26 Jul 2007 19:07:16 +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 CE76513C45B for ; Thu, 26 Jul 2007 19:07:15 +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 l6QJ7F51055352 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 26 Jul 2007 12:07:15 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <46A8F1DE.2000205@errno.com> Date: Thu, 26 Jul 2007 12:11:26 -0700 From: Sam Leffler User-Agent: Thunderbird 2.0.0.0 (X11/20070530) MIME-Version: 1.0 To: current@freebsd.org References: <20070726173506.GE1857@roadrunner.q.local> In-Reply-To: <20070726173506.GE1857@roadrunner.q.local> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: net/twinkle stuck in _umtx_op syscall X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Jul 2007 19:07:16 -0000 Ulrich Spoerlein wrote: > Gentlemen, > > I had trouble running twinkle back on 6-STABLE but now on -CURRENT it's > similar. A ktrace of the session reveals the following > > 4019 twinkle 0.000273 CALL gettimeofday(0xbf2f7cec,0) > 4019 twinkle 0.000009 RET gettimeofday 0 > 4019 twinkle 0.000518 CALL sigprocmask(SIG_BLOCK,0,0x29e09508) > 4019 twinkle 0.000009 RET sigprocmask 0 > 4019 twinkle 0.000067 CALL ioctl(0x8,FIONREAD,0xbf2f7bb8) > 4019 twinkle 0.000017 RET ioctl 0 > 4019 twinkle 0.000015 CALL ioctl(0x8,FIONREAD,0xbf2f7ba8) > 4019 twinkle 0.000015 RET ioctl 0 > 4019 twinkle 0.000143 CALL ioctl(0x8,FIONREAD,0xbf2f7b38) > 4019 twinkle 0.000016 RET ioctl 0 > 4019 twinkle 0.000007 CALL ioctl(0x8,FIONREAD,0xbf2f7b28) > 4019 twinkle 0.000005 RET ioctl 0 > 4019 twinkle 0.000006 CALL ioctl(0x8,FIONREAD,0xbf2f7b28) > 4019 twinkle 0.000014 RET ioctl 0 > 4019 twinkle 0.000011 CALL ioctl(0x8,FIONREAD,0xbf2f7b18) > 4019 twinkle 0.000006 RET ioctl 0 > 4019 twinkle 0.000014 CALL _umtx_op(0x2a2e7e80,0x5,0,0,0) > 4019 twinkle 0.001670 RET _umtx_op 0 > 4019 twinkle 0.000013 CALL getitimer(0,0xbf6fbf4c) > 4019 twinkle 0.000005 RET getitimer 0 > 4019 twinkle 0.000023 CALL _umtx_op(0x29e1985c,0x2,0,0,0) > 4019 twinkle 4.361916 RET _umtx_op -1 errno 4 Interrupted system call > 4019 twinkle 0.000044 PSIG SIGKILL SIG_DFL > > It can only be killed -9 and will otherwise stick in _umtx_op() forever. > Any clue from the threading guys on what tricks I should try? > > My libmap.conf is emtpy, twinkle is linked against the following > binaries: > > /usr/local/bin/twinkle: > libsndfile.so.1 => /usr/local/lib/libsndfile.so.1 (0x283a0000) > libccext2-1.5.so.0 => /usr/local/lib/libccext2-1.5.so.0 (0x283ff000) > libgnutls.so.15 => /usr/local/lib/libgnutls.so.15 (0x28441000) > libgcrypt.so.13 => /usr/local/lib/libgcrypt.so.13 (0x284bb000) > libz.so.4 => /lib/libz.so.4 (0x2850a000) > libccrtp1-1.5.so.0 => /usr/local/lib/libccrtp1-1.5.so.0 (0x2851c000) > libccgnu2-1.5.so.0 => /usr/local/lib/libccgnu2-1.5.so.0 (0x28542000) > librt.so.1 => /usr/lib/librt.so.1 (0x28594000) > libkdecore.so.6 => /usr/local/lib/libkdecore.so.6 (0x28599000) > libkdeui.so.6 => /usr/local/lib/libkdeui.so.6 (0x287d3000) > libkabc.so.3 => /usr/local/lib/libkabc.so.3 (0x28aaa000) > libspeex.so.1 => /usr/local/lib/libspeex.so.1 (0x28b5d000) > libilbc.so.0 => /usr/local/lib/libilbc.so.0 (0x28b7d000) > libzrtpcpp-0.9.so.0 => /usr/local/lib/libzrtpcpp-0.9.so.0 (0x28b8c000) > libboost_regex.so => /usr/local/lib/libboost_regex.so (0x28bab000) > libqt-mt.so.3 => /usr/local/lib/libqt-mt.so.3 (0x28c39000) > libXext.so.6 => /usr/local/lib/libXext.so.6 (0x2930b000) > libX11.so.6 => /usr/local/lib/libX11.so.6 (0x29319000) > libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x29405000) > libm.so.5 => /lib/libm.so.5 (0x294ed000) > libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x29503000) > libthr.so.3 => /lib/libthr.so.3 (0x2950e000) > libc.so.7 => /lib/libc.so.7 (0x29521000) > libFLAC.so.7 => /usr/local/lib/libFLAC.so.7 (0x29623000) > libgpg-error.so.0 => /usr/local/lib/libgpg-error.so.0 (0x29656000) > libintl.so.8 => /usr/local/lib/libintl.so.8 (0x2965a000) > libiconv.so.3 => /usr/local/lib/libiconv.so.3 (0x29663000) > libDCOP.so.6 => /usr/local/lib/libDCOP.so.6 (0x29751000) > libutil.so.7 => /lib/libutil.so.7 (0x29783000) > libart_lgpl_2.so.5 => /usr/local/lib/libart_lgpl_2.so.5 (0x29790000) > libidn.so.16 => /usr/local/lib/libidn.so.16 (0x297a6000) > libkdefx.so.6 => /usr/local/lib/libkdefx.so.6 (0x297d7000) > libjpeg.so.9 => /usr/local/lib/libjpeg.so.9 (0x297ff000) > libvcard.so.0 => /usr/local/lib/libvcard.so.0 (0x2981e000) > libkio.so.6 => /usr/local/lib/libkio.so.6 (0x29842000) > libkresources.so.3 => /usr/local/lib/libkresources.so.3 (0x29b82000) > libmng.so.1 => /usr/local/lib/libmng.so.1 (0x29ba4000) > libpng.so.5 => /usr/local/lib/libpng.so.5 (0x29c05000) > libXi.so.6 => /usr/local/lib/libXi.so.6 (0x29c2a000) > libXrender.so.1 => /usr/local/lib/libXrender.so.1 (0x29c32000) > libXrandr.so.2 => /usr/local/lib/libXrandr.so.2 (0x29c3a000) > libXcursor.so.1 => /usr/local/lib/libXcursor.so.1 (0x29c41000) > libXinerama.so.1 => /usr/local/lib/libXinerama.so.1 (0x29c4a000) > libXft.so.2 => /usr/local/lib/libXft.so.2 (0x29c4d000) > libfreetype.so.9 => /usr/local/lib/libfreetype.so.9 (0x29c5f000) > libfontconfig.so.1 => /usr/local/lib/libfontconfig.so.1 (0x29cc9000) > libSM.so.6 => /usr/local/lib/libSM.so.6 (0x29cf3000) > libICE.so.6 => /usr/local/lib/libICE.so.6 (0x29cfc000) > libXau.so.6 => /usr/local/lib/libXau.so.6 (0x29d13000) > libXdmcp.so.6 => /usr/local/lib/libXdmcp.so.6 (0x29d16000) > librpcsvc.so.4 => /usr/lib/librpcsvc.so.4 (0x29d1b000) > libkdesu.so.6 => /usr/local/lib/libkdesu.so.6 (0x29d24000) > libkwalletclient.so.1 => /usr/local/lib/libkwalletclient.so.1 (0x29d3c000) > libfam.so.0 => /usr/local/lib/libfam.so.0 (0x29d4d000) > liblcms.so.1 => /usr/local/lib/liblcms.so.1 (0x29d55000) > libXfixes.so.3 => /usr/local/lib/libXfixes.so.3 (0x29d84000) > libexpat.so.6 => /usr/local/lib/libexpat.so.6 (0x29d89000) I may be seeing similar issues with thunderbird on UP i386 w/ HEAD. Periodically thunderbird will take 100% of cpu for something like 30-60 seconds (maybe longer). When I ktrace the process consuming the cpu I see very similar traces (umtx_op returning errors). This is HEAD as of Jun 2. I need to update the machine but haven't seen any commits that seemed relevant. Been too busy to pursue the problem but would gladly help someone trying to track this down. Sam From owner-freebsd-current@FreeBSD.ORG Thu Jul 26 19:25:38 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 5937216A418 for ; Thu, 26 Jul 2007 19:25:38 +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 39C3613C46B for ; Thu, 26 Jul 2007 19:25:38 +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 l6QJOYWK078503; Thu, 26 Jul 2007 12:24:34 -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 l6QJOYSk078501; Thu, 26 Jul 2007 12:24:34 -0700 (PDT) (envelope-from sgk) Date: Thu, 26 Jul 2007 12:24:34 -0700 From: Steve Kargl To: Nenhum_de_Nos Message-ID: <20070726192434.GA78398@troutmask.apl.washington.edu> References: <4956a5e50707261122r54856ec2w6b8eaea663a01c16@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4956a5e50707261122r54856ec2w6b8eaea663a01c16@mail.gmail.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: tcp messages I've never seen now in Current and atheros interrupt storm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Jul 2007 19:25:38 -0000 On Thu, Jul 26, 2007 at 03:22:05PM -0300, Nenhum_de_Nos wrote: (snip) > Jul 26 12:20:10 lamneth kernel: TCP: [60.29.8.98]:32191 to > [192.168.254.10]:10010 tcpflags 0x11; syncache_expand: > Segment failed SYNCOOKIE authentication, segment rejected (probably > spoofed) (snip) > the message on google just returned the .c code file, so, if anyone > has a clue ... These messages are well known to anyone running a recent -current. Someone once stated that the messages are mostly benign diagnostics. Why the message isn't hidden behind bootverbose, a sysctl tunable, or rate limited it is a mystery. troutmask:kargl[225] grep RST messages | wc -l 483 troutmask:kargl[226] foreach i (messages*bz2) foreach? zcat $i | grep RST| wc -l foreach? end 553 588 525 357 449 -- Steve From owner-freebsd-current@FreeBSD.ORG Thu Jul 26 19:53:08 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 7815A16A469 for ; Thu, 26 Jul 2007 19:53:08 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id 12DA313C4B7 for ; Thu, 26 Jul 2007 19:53:07 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (ppp121-45-48-57.lns11.adl2.internode.on.net [121.45.48.57]) (authenticated bits=0) by cain.gsoft.com.au (8.13.8/8.13.8) with ESMTP id l6QJr5qx098185 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 27 Jul 2007 05:23:06 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-current@freebsd.org Date: Fri, 27 Jul 2007 05:22:48 +0930 User-Agent: KMail/1.9.7 References: <200707262339.07171.doconnor@gsoft.com.au> In-Reply-To: <200707262339.07171.doconnor@gsoft.com.au> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3776872.qK56o0C9LL"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200707270522.56047.doconnor@gsoft.com.au> X-Spam-Score: -2.312 () BAYES_00 X-Scanned-By: MIMEDefang 2.58 on 203.31.81.10 Subject: Re: Can't build -current on a 6.2 box X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Jul 2007 19:53:08 -0000 --nextPart3776872.qK56o0C9LL Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thu, 26 Jul 2007, Daniel O'Connor wrote: > # uname -a > FreeBSD 6.2-RELEASE FreeBSD 6.2-RELEASE #0: Fri Jan 12 11:05:30 UTC > 2007 root@dessler.cse.buffalo.edu:/usr/obj/usr/src/sys/SMP i386 > # gcc -v > Using built-in specs. > Configured with: FreeBSD/i386 system compiler > Thread model: posix > gcc version 3.4.6 [FreeBSD] 20060305 > > This system has 2GB of RAM and 2GB of swap. Running unlimit -h allowed me to buildworld OK. =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart3776872.qK56o0C9LL 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) iD8DBQBGqPuX5ZPcIHs/zowRAnf6AJ9JYdMwnAf+Bi3e9if1//x1JcXWIQCbBVIn g1Wk3w8aJmnHvbMu7FYKk6o= =YB0r -----END PGP SIGNATURE----- --nextPart3776872.qK56o0C9LL-- From owner-freebsd-current@FreeBSD.ORG Thu Jul 26 20:13:59 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 E786116A417; Thu, 26 Jul 2007 20:13:59 +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 90A8113C461; Thu, 26 Jul 2007 20:13:59 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: by heff.fud.org.nz (Postfix, from userid 1001) id 0E1881CC58; Fri, 27 Jul 2007 08:13:58 +1200 (NZST) Date: Fri, 27 Jul 2007 08:13:58 +1200 From: Andrew Thompson To: Matteo Riondato , Scot Hetzel , freebsd-current@freebsd.org Message-ID: <20070726201358.GA30216@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> <20070721092207.GC76674@heff.fud.org.nz> <20070725093123.GB1704@kaiser.sig11.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070725093123.GB1704@kaiser.sig11.org> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: 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: Thu, 26 Jul 2007 20:14:00 -0000 On Wed, Jul 25, 2007 at 11:31:23AM +0200, Matteo Riondato wrote: > On Sat, Jul 21, 2007 at 09:22:07PM +1200, Andrew Thompson wrote: > > 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. > > I tested it and it solved my problem. > Thanks for your work. Committed. Thanks for your testing. Andrew From owner-freebsd-current@FreeBSD.ORG Thu Jul 26 20:14: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 B05A616A421 for ; Thu, 26 Jul 2007 20:14:43 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 7033813C4B6 for ; Thu, 26 Jul 2007 20:14:43 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 08F532089; Thu, 26 Jul 2007 22:14:40 +0200 (CEST) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: 0.0/3.0 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on tim.des.no Received: from ds4.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id 74B8B2085; Thu, 26 Jul 2007 22:14:39 +0200 (CEST) Received: by ds4.des.no (Postfix, from userid 1001) id 43CA48444E; Thu, 26 Jul 2007 22:14:39 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Mike Tancsa References: <46337B06.9080102@ybb.ne.jp> <46338C0F.9000608@ybb.ne.jp> <4633932A.8080602@ybb.ne.jp> <86tzuxni1b.fsf@dwp.des.no> <200707061723.l66HNYSe037055@lava.sentex.ca> Date: Thu, 26 Jul 2007 22:14:39 +0200 In-Reply-To: <200707061723.l66HNYSe037055@lava.sentex.ca> (Mike Tancsa's message of "Fri\, 06 Jul 2007 13\:22\:55 -0400") Message-ID: <86ir86hqhc.fsf@ds4.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Takeharu KATO , freebsd-current@freebsd.org Subject: Re: ichwd for ICH8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Jul 2007 20:14:43 -0000 Mike Tancsa writes: > Any chance to commit this to the tree ? It works really well with a > number of newer chipsets out there, that the old ichwd does not work > with. Turns out my new ICH8 motherboard has the WDT disabled in hardware, so I can't test this myself. Please test the following patch: http://people.freebsd.org/~des/software/ichwd-20070726.diff DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Thu Jul 26 20:36:02 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 3F38816A419 for ; Thu, 26 Jul 2007 20:36:02 +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 02B7213C4D3 for ; Thu, 26 Jul 2007 20:36:01 +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 l6QKZvfe010512; Thu, 26 Jul 2007 16:35:57 -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 l6QKZtnd067391 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Jul 2007 16:35:56 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <200707262035.l6QKZtnd067391@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 26 Jul 2007 16:35:51 -0400 To: Dag-Erling =?iso-8859-1?Q?Sm=C3=B8rgrav?= From: Mike Tancsa In-Reply-To: <86ir86hqhc.fsf@ds4.des.no> References: <46337B06.9080102@ybb.ne.jp> <46338C0F.9000608@ybb.ne.jp> <4633932A.8080602@ybb.ne.jp> <86tzuxni1b.fsf@dwp.des.no> <200707061723.l66HNYSe037055@lava.sentex.ca> <86ir86hqhc.fsf@ds4.des.no> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Cc: Takeharu KATO , freebsd-current@freebsd.org Subject: Re: ichwd for ICH8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Jul 2007 20:36:02 -0000 At 04:14 PM 7/26/2007, Dag-Erling Sm=C3=B8rgrav wrote: >Mike Tancsa writes: > > Any chance to commit this to the tree ? It works really well with a > > number of newer chipsets out there, that the old ichwd does not work > > with. > >Turns out my new ICH8 motherboard has the WDT disabled in hardware, so I >can't test this myself. Please test the following patch: > > http://people.freebsd.org/~des/software/ichwd-20070726.diff Thanks! On RELENG_6, 0[image62]# patch < ichwd-20070726.diff Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |Index: sys/dev/ichwd/ichwd.c |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D |RCS file: /home/ncvs/src/sys/dev/ichwd/ichwd.c,v |retrieving revision 1.9 |diff -u -r1.9 ichwd.c |--- sys/dev/ichwd/ichwd.c 27 Mar 2007 21:03:36 -0000 1.9 |+++ sys/dev/ichwd/ichwd.c 26 Jul 2007 20:03:46 -0000 -------------------------- Patching file sys/dev/ichwd/ichwd.c using Plan A... Hunk #1 succeeded at 51. Hunk #2 succeeded at 73. Hunk #3 succeeded at 104. Hunk #4 succeeded at 115. Hunk #5 succeeded at 154. Hunk #6 succeeded at 165. Hunk #7 succeeded at 259. Hunk #8 succeeded at 289. Hunk #9 succeeded at 332. Hunk #10 succeeded at 376. Hunk #11 succeeded at 421. Hunk #12 succeeded at 432. Hunk #13 succeeded at 455. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |Index: sys/dev/ichwd/ichwd.h |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D |RCS file: /home/ncvs/src/sys/dev/ichwd/ichwd.h,v |retrieving revision 1.3 |diff -u -r1.3 ichwd.h |--- sys/dev/ichwd/ichwd.h 17 Feb 2006 18:46:18 -0000 1.3 |+++ sys/dev/ichwd/ichwd.h 26 Jul 2007 16:20:22 -0000 -------------------------- Patching file sys/dev/ichwd/ichwd.h using Plan A... Hunk #1 succeeded at 32. Hunk #2 succeeded at 55. Hunk #3 succeeded at 76. Hunk #4 succeeded at 99. Hunk #5 succeeded at 130. done 0[image62]# But I get 0[image62]# make Warning: Object directory not changed from original= /usr/src/sys/modules/ichwd cc -O2 -pipe -fno-strict-aliasing -Werror=20 -D_KERNEL -DKLD_MODULE -nostdinc -I- -I. -I@=20 -I@/contrib/altq -I@/../include=20 -finline-limit=3D8000=20 -fno-common -mno-align-long-strings=20 -mpreferred-stack-boundary=3D2 -mno-mmx -mno-3dnow=20 -mno-sse -mno-sse2 -ffreestanding -Wall=20 -Wredundant-decls -Wnested-externs=20 -Wstrict-prototypes -Wmissing-prototypes=20 -Wpointer-arith -Winline=20 -Wcast-qual -fformat-extensions -std=3Dc99 -c=20 /usr/src/sys/modules/ichwd/../../dev/ichwd/ichwd.c /usr/src/sys/modules/ichwd/../../dev/ichwd/ichwd.c:=20 In function `ichwd_clear_noreboot': /usr/src/sys/modules/ichwd/../../dev/ichwd/ichwd.c:228:=20 warning: implicit declaration of function `device__printf' /usr/src/sys/modules/ichwd/../../dev/ichwd/ichwd.c:228:=20 warning: nested extern declaration of `device__printf' *** Error code 1 Stop in /usr/src/sys/modules/ichwd. 1[image62]# If I change device__printf to device_printf it=20 compiles and I can load it, but it doesnt work 0[image62]# kldload ./ichwd.ko 0[image62]# dmesg | tail -10 da0 at twa0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-5 device da0: 100.000MB/s transfers da0: 76283MB (156227584 512 byte sectors: 255H 63S/T 9724C) Trying to mount root from ufs:/dev/ad4s1a ichwd module loaded ichwd0: on isa0 ichwd0: unable to reserve GCS registers device_attach: ichwd0 attach returned 6 ppc0: parallel port not found. 0[image62]# 0[image62]# watchdogd -t 20 70[image62]# ps -aux | grep dog root 1731 0.0 0.0 1632 1032 p0 S+ 4:21PM 0:00.00 grep dog 0[image62]# Same error on current ichwd module loaded ichwd0: on isa0 ichwd0: ICH WDT present but disabled in BIOS or hardware device_attach: ichwd0 attach returned 6 ppc0: parallel port not found. leopard3# uname -a FreeBSD leopard3.netperf.freebsd.org 7.0-CURRENT=20 FreeBSD 7.0-CURRENT #20: Mon Jul 23 11:58:00 EDT=20 2007=20 rwatson@zoo.freebsd.org:/zoo/usr.obj/rwatson/current/src/sys/GENERIC i386 leopard3# Using the patch as is in http://lists.freebsd.org/pipermail/freebsd-bugs/2007-April/023828.html 0[image62]# dmesg | tail -10 ichwd module loaded ichwd0: on isa0 ichwd0: unable to reserve GCS registers device_attach: ichwd0 attach returned 6 ppc0: parallel port not found. ichwd module unloaded ichwd module loaded ichwd0: at port 0x430-0x437,0x460-0x469 on isa0 ichwd0: Intel ICH7 watchdog timer (TCO version 2) ppc0: parallel port not found. 0[image62]# watchdogd -t 20 0[image62]# killall -9 watchdogd 0[image62]# 0[image62]# pwd /usr/src/sys/modules/ichwd 0[image62]# The box reboots in ~ 20 seconds On CURRENT leopard3# dmesg | tail -10 ichwd module loaded ichwd0: on isa0 ichwd0: ICH WDT present but disabled in BIOS or hardware device_attach: ichwd0 attach returned 6 ppc0: parallel port not found. ichwd module unloaded ichwd module loaded ichwd0: at port 0x1080-0x1087,0x1088-0x1091 on= isa0 ichwd0: Intel ICH7 watchdog timer (TCO version 2) ppc0: parallel port not found. leopard3# watchdogd -t 20 leopard3# But it doesnt kill it. I will have to check that=20 boxes BIOS to see if its disabled, which is likely ---Mike >DES >-- >Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Thu Jul 26 22:30: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 7820B16A418 for ; Thu, 26 Jul 2007 22:30:51 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 3683913C457 for ; Thu, 26 Jul 2007 22:30:51 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id B1A6D2089; Fri, 27 Jul 2007 00:30:47 +0200 (CEST) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: 0.0/3.0 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on tim.des.no Received: from ds4.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id 2A43E2085; Fri, 27 Jul 2007 00:30:47 +0200 (CEST) Received: by ds4.des.no (Postfix, from userid 1001) id 11AEB84450; Fri, 27 Jul 2007 00:30:47 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Mike Tancsa References: <46337B06.9080102@ybb.ne.jp> <46338C0F.9000608@ybb.ne.jp> <4633932A.8080602@ybb.ne.jp> <86tzuxni1b.fsf@dwp.des.no> <200707061723.l66HNYSe037055@lava.sentex.ca> <86ir86hqhc.fsf@ds4.des.no> <200707262035.l6QKZtnd067391@lava.sentex.ca> Date: Fri, 27 Jul 2007 00:30:46 +0200 In-Reply-To: <200707262035.l6QKZtnd067391@lava.sentex.ca> (Mike Tancsa's message of "Thu\, 26 Jul 2007 16\:35\:51 -0400") Message-ID: <86abtihk6h.fsf@ds4.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Takeharu KATO , freebsd-current@freebsd.org Subject: Re: ichwd for ICH8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Jul 2007 22:30:51 -0000 Mike Tancsa writes: > Thanks! On RELENG_6, The patch is for CURRENT. > /usr/src/sys/modules/ichwd/../../dev/ichwd/ichwd.c: In function ichwd_cle= ar_noreboot': > /usr/src/sys/modules/ichwd/../../dev/ichwd/ichwd.c:228: warning: implicit= declaration of function `device__printf' > /usr/src/sys/modules/ichwd/../../dev/ichwd/ichwd.c:228: warning: nested e= xtern declaration of `device__printf' > *** Error code 1 Typo... > ichwd module loaded > ichwd0: on isa0 > ichwd0: unable to reserve GCS registers > device_attach: ichwd0 attach returned 6 in ichwd_identify(), the ICH version test is wrong, it should be - if (id_p->version =3D=3D 2) { + if (id_p->version >=3D 6) { > Same error on current > > ichwd module loaded > ichwd0: on isa0 > ichwd0: ICH WDT present but disabled in BIOS or hardware > device_attach: ichwd0 attach returned 6 Not the same error, but probably caused by the same mistake in ichwd_identify() DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Thu Jul 26 23:38: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 0BEAC16A420 for ; Thu, 26 Jul 2007 23:38:25 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id CBEED13C4B3 for ; Thu, 26 Jul 2007 23:38:24 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost2.sentex.ca (8.14.1/8.13.8) with ESMTP id l6QNcME8052957; Thu, 26 Jul 2007 19:38:22 -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 l6QNcL1T068284 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Jul 2007 19:38:21 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <200707262338.l6QNcL1T068284@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 26 Jul 2007 19:38:16 -0400 To: Dag-Erling =?iso-8859-1?Q?Sm=C3=B8rgrav?= From: Mike Tancsa In-Reply-To: <86abtihk6h.fsf@ds4.des.no> References: <46337B06.9080102@ybb.ne.jp> <46338C0F.9000608@ybb.ne.jp> <4633932A.8080602@ybb.ne.jp> <86tzuxni1b.fsf@dwp.des.no> <200707061723.l66HNYSe037055@lava.sentex.ca> <86ir86hqhc.fsf@ds4.des.no> <200707262035.l6QKZtnd067391@lava.sentex.ca> <86abtihk6h.fsf@ds4.des.no> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Cc: Takeharu KATO , freebsd-current@freebsd.org Subject: Re: ichwd for ICH8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Jul 2007 23:38:25 -0000 At 06:30 PM 7/26/2007, Dag-Erling Sm=C3=B8rgrav wrote: > > ichwd module loaded > > ichwd0: on isa0 > > ichwd0: unable to reserve GCS registers > > device_attach: ichwd0 attach returned 6 > >in ichwd_identify(), the ICH version test is wrong, it should be > >- if (id_p->version =3D=3D 2) { >+ if (id_p->version >=3D 6) { OK, I tried it on current, but it sees the ichwd=20 as ich5, where as its 7 according to the other version leopard3# dmesg | grep ich ichwd module loaded ichwd0: on isa0 ichwd0: ICH WDT present but disabled in BIOS or hardware device_attach: ichwd0 attach returned 6 ichwd module unloaded ichwd module loaded ichwd0: at port 0x1080-0x1087,0x1088-0x1091 on= isa0 ichwd0: Intel ICH7 watchdog timer (TCO version 2) ichwd0: detached ichwd module unloaded ichwd module loaded ichwd0: at port 0x1080-0x1087,0x1088-0x1091 on= isa0 leopard3# =20 From owner-freebsd-current@FreeBSD.ORG Fri Jul 27 00:13: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 4FD1E16A417 for ; Fri, 27 Jul 2007 00:13:42 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 07FB513C459 for ; Fri, 27 Jul 2007 00:13:41 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 1884E2089; Fri, 27 Jul 2007 02:13:38 +0200 (CEST) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: 0.0/3.0 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on tim.des.no Received: from ds4.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id 847E62085; Fri, 27 Jul 2007 02:13:37 +0200 (CEST) Received: by ds4.des.no (Postfix, from userid 1001) id 4CB3184437; Fri, 27 Jul 2007 02:13:37 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Mike Tancsa References: <46337B06.9080102@ybb.ne.jp> <46338C0F.9000608@ybb.ne.jp> <4633932A.8080602@ybb.ne.jp> <86tzuxni1b.fsf@dwp.des.no> <200707061723.l66HNYSe037055@lava.sentex.ca> <86ir86hqhc.fsf@ds4.des.no> <200707262035.l6QKZtnd067391@lava.sentex.ca> <86abtihk6h.fsf@ds4.des.no> <200707262338.l6QNcL1T068284@lava.sentex.ca> Date: Fri, 27 Jul 2007 02:13:37 +0200 In-Reply-To: <200707262338.l6QNcL1T068284@lava.sentex.ca> (Mike Tancsa's message of "Thu\, 26 Jul 2007 19\:38\:16 -0400") Message-ID: <86hcnq900e.fsf@ds4.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Takeharu KATO , freebsd-current@freebsd.org Subject: Re: ichwd for ICH8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Jul 2007 00:13:42 -0000 Mike Tancsa writes: > OK, I tried it on current, but it sees the ichwd as ich5, where as its > 7 according to the other version No, the unpatched driver in -CURRENT has that bug (misidentifies ICH7 as ICH5) but the patched driver would identify it correctly and additionally print a line about the TCO version. You must have loaded the wrong module. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Fri Jul 27 00:38: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 A312816A417 for ; Fri, 27 Jul 2007 00:38:25 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id 420FD13C428 for ; Fri, 27 Jul 2007 00:38:25 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost2.sentex.ca (8.14.1/8.13.8) with ESMTP id l6R0cM2w054792; Thu, 26 Jul 2007 20:38:22 -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 l6R0cLNV068524 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Jul 2007 20:38:21 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <200707270038.l6R0cLNV068524@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 26 Jul 2007 20:38:16 -0400 To: Dag-Erling =?iso-8859-1?Q?Sm=C3=B8rgrav?= From: Mike Tancsa In-Reply-To: <86hcnq900e.fsf@ds4.des.no> References: <46337B06.9080102@ybb.ne.jp> <46338C0F.9000608@ybb.ne.jp> <4633932A.8080602@ybb.ne.jp> <86tzuxni1b.fsf@dwp.des.no> <200707061723.l66HNYSe037055@lava.sentex.ca> <86ir86hqhc.fsf@ds4.des.no> <200707262035.l6QKZtnd067391@lava.sentex.ca> <86abtihk6h.fsf@ds4.des.no> <200707262338.l6QNcL1T068284@lava.sentex.ca> <86hcnq900e.fsf@ds4.des.no> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Cc: Takeharu KATO , freebsd-current@freebsd.org Subject: Re: ichwd for ICH8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Jul 2007 00:38:25 -0000 At 08:13 PM 7/26/2007, Dag-Erling Sm=C3=B8rgrav wrote: >Mike Tancsa writes: > > OK, I tried it on current, but it sees the ichwd as ich5, where as its > > 7 according to the other version > >No, the unpatched driver in -CURRENT has that bug (misidentifies ICH7 as >ICH5) but the patched driver would identify it correctly and >additionally print a line about the TCO version. You must have loaded >the wrong module. Sorry, you are right. I can load it now on the=20 current box I have running, but it doesnt reboot=20 it, probably because of the BIOS setting. ichwd module loaded ichwd0: at port 0x1080-0x1087,0x1088-0x1091 on= isa0 ichwd0: Intel ICH7 watchdog timer (ICH7 or equivalent) ppc0: parallel port not found. Also, it works on RELENG_6 ichwd module loaded ichwd0: on isa0 ichwd0: Intel ICH7 watchdog timer (ICH7 or equivalent) ppc0: parallel port not found. I also tried the patched version on an older box=20 and it looks good too (running releng_6). Its an ICH5 Intel 865 MB ichwd module loaded ichwd0: on isa0 ppc0: parallel port not found. From owner-freebsd-current@FreeBSD.ORG Fri Jul 27 00:40:08 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 9D9E716A41B for ; Fri, 27 Jul 2007 00:40:08 +0000 (UTC) (envelope-from maksim.yevmenkin@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 34EB013C4D0 for ; Fri, 27 Jul 2007 00:40:07 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by ug-out-1314.google.com with SMTP id o4so693858uge for ; Thu, 26 Jul 2007 17:40: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:mime-version:content-type:content-transfer-encoding:content-disposition; b=P1Q3GiZY5PypgGH8wixCq52KjwS735xeuvUsXPgcBkAcvxw2vh5w8j1sJuF60k2hjUTe7PN2leLnO6Yg1xEEobYQDV7AFKqSw6GEqlYipySgeqMMmsgSN4t2jxWWoqTyZt4XY8tuFLTXIVsfueqgQFMiN6p7+a7ti3LcOYMnNL4= 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=n3yEaLNCZPXncfDRUNXOrsCzbWU0b2Kw+8Bql9OJ6HfmBVyAPxMxorQ/kLd/Vs4UBOt3t2/vGaC7dQAQ2wGzI9jPd5bN0qsLPgshqu2XRXeP7DPmItwUJChNP2UQZkvTgT+3herFSy0OH8giDKLy3TyAKqaBUBO3EmhtP5mSJHM= Received: by 10.86.60.7 with SMTP id i7mr1579369fga.1185495102852; Thu, 26 Jul 2007 17:11:42 -0700 (PDT) Received: by 10.86.31.8 with HTTP; Thu, 26 Jul 2007 17:11:42 -0700 (PDT) Message-ID: Date: Thu, 26 Jul 2007 17:11:42 -0700 From: "Maksim Yevmenkin" To: "Julian Elischer" , freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Subject: nmdm(4) does not call .l_close X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Jul 2007 00:40:08 -0000 Dear All, it seems to me that nmdm(4) is not calling .l_close (i.e. does not close whatever line discipline might be installed onto /dev/nmdmXX). the problem is easy to reproduce - just open /dev/nmdm0A and install, say, ng_tty(4) line discipline onto it. after that, simply close the /dev/nmdm0A. in theory, the ng_tty(4) node should disappear when device is closed, but it does not. the following patch fixes things for me === beetle% diff -u nmdm.c.orig nmdm.c --- nmdm.c.orig 2006-11-21 16:59:40.000000000 -0800 +++ nmdm.c 2007-07-26 17:01:47.000000000 -0700 @@ -402,7 +402,7 @@ nmdmclose(struct cdev *dev, int flag, int mode, struct thread *td) { - return (tty_close(dev->si_tty)); + return (ttyclose(dev, flag, mode, td)); } static void === please review and let me know if this is ok to commit. please ignore tabs-to-spaces conversion. its just cut-and-paste from the screen. thanks, max p.s. i also think ng_tty(4) should use NG_NODE_REVIVE() is its not dying. From owner-freebsd-current@FreeBSD.ORG Fri Jul 27 00:50: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 34F8E16A41A for ; Fri, 27 Jul 2007 00:50:21 +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 F406113C4CC for ; Fri, 27 Jul 2007 00:50:20 +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 l6R0oKxI014498; Thu, 26 Jul 2007 17:50:20 -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 l6R0oKx5014497; Thu, 26 Jul 2007 17:50:20 -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: Milos Vyletel Date: Thu, 26 Jul 2007 17:50:19 -0700 User-Agent: KMail/1.9.6 References: <20070721174631.S561@10.0.0.1> <20070722114846.GA97996@rulez.sk> <20070722121631.GA8336@rulez.sk> In-Reply-To: <20070722121631.GA8336@rulez.sk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200707261750.19994.peter@wemm.org> Cc: current@freebsd.org Subject: Re: ULE status, invalid load, buildkernel 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: Fri, 27 Jul 2007 00:50:21 -0000 On Sunday 22 July 2007, Milos Vyletel wrote: > On Sun, Jul 22, 2007 at 01:48:46PM +0200, Milos Vyletel wrote: [...] > > No problem, > > > > I've extracted it and made a patch. If someone is intrested, it's > > on > > > > http://rulez.sk/~mv/cpu.patch > > Well, i've just updated my kernel and it paniced right after > identifying cpu. > > CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ (2205.01-MHz > K8-class CPU) Origin = "AuthenticAMD" Id = 0x20f32 Stepping = 2 > > Features=0x178bfbffPGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT> > Features2=0x1 > AMD Features=0xe2500800 > AMD Features2=0x3 > Cores per package: 2 > usable memory = 3211776000 (3062 MB) > avail memory = 3105628160 (2961 MB) > kernel trap 12 with interrupts disabled > > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x310 > fault code = supervisor read data, page not present > instruction pointer = 0x8:0xffffffff8033953c > stack pointer = 0x10:0xffffffff80855c70 > frame pointer = 0x10:0xffffffff80855c80 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = resume, IOPL = 0 > current process = 0 () > > this is output from from dmesg. > > Thanks for suggestions. > Milos Unfortunately this isn't much help. What would be useful would be to get a backtrace. If you're not running GENERIC, a copy of your kernel config would be useful. Any other patches? To get a backtrace, add these to your kernel config: options KDB options DDB #options KDB_TRACE #options KDB_UNATTENDED The last two options would help automate it for you, but beware. KDB_TRACE shows a trace during the panic. The problem is that ddb is activated before the machine actually panics, so you'd be dropped into ddb before the trace got printed. Give a 'trace' command at the 'db>' prompt. KDB_UNATTENDED prevents it dropping into ddb, and simply prints the trace and gets on with the panic. It might be a bit harder to get a record of what happened. -- 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 Fri Jul 27 00:50:56 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 EB7EC16A41B for ; Fri, 27 Jul 2007 00:50:56 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outY.internet-mail-service.net (outY.internet-mail-service.net [216.240.47.248]) by mx1.freebsd.org (Postfix) with ESMTP id D502613C48E for ; Fri, 27 Jul 2007 00:50:56 +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; Thu, 26 Jul 2007 17:50:56 -0700 Received: from julian-mac.elischer.org (nat.ironport.com [63.251.108.100]) by idiom.com (Postfix) with ESMTP id EEE55125ADD; Thu, 26 Jul 2007 17:50:55 -0700 (PDT) Message-ID: <46A94194.5010207@elischer.org> Date: Thu, 26 Jul 2007 17:51:32 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.5 (Macintosh/20070716) MIME-Version: 1.0 To: Maksim Yevmenkin 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: nmdm(4) does not call .l_close X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Jul 2007 00:50:57 -0000 Maksim Yevmenkin wrote: > Dear All, > > it seems to me that nmdm(4) is not calling .l_close (i.e. does not > close whatever line discipline might be installed onto /dev/nmdmXX). > the problem is easy to reproduce - just open /dev/nmdm0A and install, > say, ng_tty(4) line discipline onto it. after that, simply close the > /dev/nmdm0A. in theory, the ng_tty(4) node should disappear when > device is closed, but it does not. when I originally wrote this I copied what the pty code was doing. This has all been redone since then however. I'm guessing it should do whatever the pty code is now doing :-) . > > the following patch fixes things for me > > === > > beetle% diff -u nmdm.c.orig nmdm.c > --- nmdm.c.orig 2006-11-21 16:59:40.000000000 -0800 > +++ nmdm.c 2007-07-26 17:01:47.000000000 -0700 > @@ -402,7 +402,7 @@ > nmdmclose(struct cdev *dev, int flag, int mode, struct thread *td) > { > > - return (tty_close(dev->si_tty)); > + return (ttyclose(dev, flag, mode, td)); sounds believable.. but I don't really know offhand. does it work with other disciplines? > } > > static void > > === > > please review and let me know if this is ok to commit. please ignore > tabs-to-spaces conversion. its just cut-and-paste from the screen. > > thanks, > max > > p.s. i also think ng_tty(4) should use NG_NODE_REVIVE() is its not dying. > _______________________________________________ > 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 27 01:06: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 AD20416A41B for ; Fri, 27 Jul 2007 01:06:21 +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 6747C13C45A for ; Fri, 27 Jul 2007 01:06:21 +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 l6R16Kht015038; Thu, 26 Jul 2007 18:06:20 -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 l6R16KCU015037; Thu, 26 Jul 2007 18:06:20 -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: Milos Vyletel Date: Thu, 26 Jul 2007 18:06:20 -0700 User-Agent: KMail/1.9.6 References: <20070721174631.S561@10.0.0.1> <20070722114846.GA97996@rulez.sk> <20070722121631.GA8336@rulez.sk> In-Reply-To: <20070722121631.GA8336@rulez.sk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200707261806.20554.peter@wemm.org> Cc: current@freebsd.org Subject: Re: ULE status, invalid load, buildkernel 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: Fri, 27 Jul 2007 01:06:21 -0000 On Sunday 22 July 2007, Milos Vyletel wrote: > On Sun, Jul 22, 2007 at 01:48:46PM +0200, Milos Vyletel wrote: > > On Sun, Jul 22, 2007 at 04:06:47AM -0700, Peter Wemm wrote: [..] > > > You can extract it from here: > > > > > > http://lists.freebsd.org/pipermail/p4-projects/2007-July/020058.h > > >tml > > > > > > Sorry I don't have it in a more convenient format.. I'm about to > > > fall asleep on my keyboard. :) > > > > > > Cheers, > > > -Peter > > > > No problem, > > > > I've extracted it and made a patch. If someone is intrested, it's > > on > > > > http://rulez.sk/~mv/cpu.patch > > Well, i've just updated my kernel and it paniced right after > identifying cpu. > > CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ (2205.01-MHz > K8-class CPU) Origin = "AuthenticAMD" Id = 0x20f32 Stepping = 2 > > Features=0x178bfbffPGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT> > Features2=0x1 > AMD Features=0xe2500800 > AMD Features2=0x3 > Cores per package: 2 > usable memory = 3211776000 (3062 MB) > avail memory = 3105628160 (2961 MB) > kernel trap 12 with interrupts disabled > > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x310 > fault code = supervisor read data, page not present > instruction pointer = 0x8:0xffffffff8033953c > stack pointer = 0x10:0xffffffff80855c70 > frame pointer = 0x10:0xffffffff80855c80 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = resume, IOPL = 0 > current process = 0 () The other option is to find the kernel.debug for this crash, and do this: kgdb kernel.debug gdb> l *0xffffffff8033953c This will tell us the file and line number that the crash happened in. There is no need to reboot for this unless you no longer have a crashing kernel. -- 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 Fri Jul 27 02:41:08 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 3A33616A417; Fri, 27 Jul 2007 02:41:08 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 25ACE13C459; Fri, 27 Jul 2007 02:41:08 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from rot26.obsecurity.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id 440EB1A3C1A; Thu, 26 Jul 2007 19:41:05 -0700 (PDT) Received: by rot26.obsecurity.org (Postfix, from userid 1001) id E5DDABBB1; Thu, 26 Jul 2007 22:41:07 -0400 (EDT) Date: Thu, 26 Jul 2007 22:41:07 -0400 From: Kris Kennaway To: Julian Elischer Message-ID: <20070727024107.GA69300@rot26.obsecurity.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 Content-Disposition: inline In-Reply-To: <46A100C2.1030606@elischer.org> User-Agent: Mutt/1.4.2.3i 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, 27 Jul 2007 02:41:08 -0000 On Fri, Jul 20, 2007 at 11:36:50AM -0700, 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. Various users have reported definite deadlocks relating to uid/gid firewall rules in the past. Kris From owner-freebsd-current@FreeBSD.ORG Fri Jul 27 04:10:59 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 0E74016A417 for ; Fri, 27 Jul 2007 04:10:59 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) Received: from mail.ambrisko.com (mail.ambrisko.com [64.174.51.43]) by mx1.freebsd.org (Postfix) with ESMTP id DECDE13C458 for ; Fri, 27 Jul 2007 04:10:58 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) Received: from server2.ambrisko.com (HELO www.ambrisko.com) ([192.168.1.2]) by ironport2.ambrisko.com with ESMTP; 26 Jul 2007 21:05:55 -0700 Received: from ambrisko.com (localhost [127.0.0.1]) by www.ambrisko.com (8.14.1/8.12.11) with ESMTP id l6R4Ck1X049031; Thu, 26 Jul 2007 21:12:46 -0700 (PDT) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.14.1/8.13.1/Submit) id l6R4CjQg049026; Thu, 26 Jul 2007 21:12:45 -0700 (PDT) (envelope-from ambrisko) From: Doug Ambrisko Message-Id: <200707270412.l6R4CjQg049026@ambrisko.com> In-Reply-To: <200707270038.l6R0cLNV068524@lava.sentex.ca> To: Mike Tancsa Date: Thu, 26 Jul 2007 21:12:45 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL94b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Cc: Takeharu KATO , =?ISO-8859-1?Q?Dag-Erling_Sm=C3=B8rgrav?= , freebsd-current@freebsd.org Subject: Re: ichwd for ICH8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Jul 2007 04:10:59 -0000 Mike Tancsa writes: | At 08:13 PM 7/26/2007, Dag-Erling Sm??rgrav wrote: | >Mike Tancsa writes: | > > OK, I tried it on current, but it sees the ichwd as ich5, where as its | > > 7 according to the other version | > | >No, the unpatched driver in -CURRENT has that bug (misidentifies ICH7 as | >ICH5) but the patched driver would identify it correctly and | >additionally print a line about the TCO version. You must have loaded | >the wrong module. | | Sorry, you are right. I can load it now on the | current box I have running, but it doesnt reboot | it, probably because of the BIOS setting. Atleast with older ICH chips the TCO reset can be disabled in hardware with a pull-up or pull-down resistor (I forget which) on one of the PC speaker lines. They did this on a Tyan MB but I was able to remove the resistor. The thing that was strange is they didn't know why they put the resistor on the board to disable it. Doug A. From owner-freebsd-current@FreeBSD.ORG Fri Jul 27 07:48:38 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 71B1A16A41A for ; Fri, 27 Jul 2007 07:48:38 +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 39AFB13C45E for ; Fri, 27 Jul 2007 07:48:38 +0000 (UTC) (envelope-from mv@rulez.sk) Received: from localhost (localhost [127.0.0.1]) by mail.rulez.sk (Postfix) with ESMTP id 2E5795C39; Fri, 27 Jul 2007 09:48:36 +0200 (CEST) X-Virus-Scanned: by amavisd-new at mail.rulez.sk Received: by mail.rulez.sk (Postfix, from userid 1020) id 448B35C34; Fri, 27 Jul 2007 09:48:32 +0200 (CEST) Date: Fri, 27 Jul 2007 09:48:32 +0200 From: Milos Vyletel To: Peter Wemm Message-ID: <20070727074832.GA69608@rulez.sk> References: <20070721174631.S561@10.0.0.1> <20070722114846.GA97996@rulez.sk> <20070722121631.GA8336@rulez.sk> <200707261806.20554.peter@wemm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200707261806.20554.peter@wemm.org> User-Agent: Mutt/1.4.2.2i Cc: current@freebsd.org Subject: Re: ULE status, invalid load, buildkernel 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: Fri, 27 Jul 2007 07:48:38 -0000 On Thu, Jul 26, 2007 at 06:06:20PM -0700, Peter Wemm wrote: > The other option is to find the kernel.debug for this crash, and do > this: > kgdb kernel.debug > gdb> l *0xffffffff8033953c > This will tell us the file and line number that the crash happened in. > There is no need to reboot for this unless you no longer have a > crashing kernel. I've played with this a little while, and after turning INVARIANTS on, it paniced in lapic_ipi_raw() on the KASSERT(lapic != NULL, ("%s called too early", __func__)); so I assume, that this function was called before lapic_init(), where lapic is initialized, which is wrong. It was clean current kernel with no other patches, now I don't have local access to that machine so I can test it in few days. btw. how can one get trace in text form, I mean syslog stop after panic and all I got logged is that it paniced. Anything I type in db> is lost. I know that this can be done by remote gdb, but unfortunatelly this isn't possible. Thanks From owner-freebsd-current@FreeBSD.ORG Fri Jul 27 09: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 4DD0516A417 for ; Fri, 27 Jul 2007 09:05:43 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 10C8F13C457 for ; Fri, 27 Jul 2007 09:05:37 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 5F2AA2089; Fri, 27 Jul 2007 11:05:33 +0200 (CEST) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: 0.0/3.0 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on tim.des.no Received: from ds4.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id 4CB642085; Fri, 27 Jul 2007 11:05:33 +0200 (CEST) Received: by ds4.des.no (Postfix, from userid 1001) id 327368444E; Fri, 27 Jul 2007 11:05:33 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Doug Ambrisko References: <200707270412.l6R4CjQg049026@ambrisko.com> Date: Fri, 27 Jul 2007 11:05:33 +0200 In-Reply-To: <200707270412.l6R4CjQg049026@ambrisko.com> (Doug Ambrisko's message of "Thu\, 26 Jul 2007 21\:12\:45 -0700 \(PDT\)") Message-ID: <86abti2p42.fsf@ds4.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Takeharu KATO , freebsd-current@freebsd.org, Mike Tancsa Subject: Re: ichwd for ICH8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Jul 2007 09:05:43 -0000 Doug Ambrisko writes: > Atleast with older ICH chips the TCO reset can be disabled in hardware > with a pull-up or pull-down resistor (I forget which) on one of the > PC speaker lines. Yes, but the driver detects that and refuses to attach. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Fri Jul 27 09:07: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 DF8AA16A41F for ; Fri, 27 Jul 2007 09:07:15 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 9F0FA13C469 for ; Fri, 27 Jul 2007 09:07:15 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 58495208C; Fri, 27 Jul 2007 11:07:12 +0200 (CEST) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: 0.0/3.0 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on tim.des.no Received: from ds4.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id 4B1542089; Fri, 27 Jul 2007 11:07:12 +0200 (CEST) Received: by ds4.des.no (Postfix, from userid 1001) id 31DF88444E; Fri, 27 Jul 2007 11:07:12 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Mike Tancsa References: <46337B06.9080102@ybb.ne.jp> <46338C0F.9000608@ybb.ne.jp> <4633932A.8080602@ybb.ne.jp> <86tzuxni1b.fsf@dwp.des.no> <200707061723.l66HNYSe037055@lava.sentex.ca> <86ir86hqhc.fsf@ds4.des.no> <200707262035.l6QKZtnd067391@lava.sentex.ca> <86abtihk6h.fsf@ds4.des.no> <200707262338.l6QNcL1T068284@lava.sentex.ca> <86hcnq900e.fsf@ds4.des.no> <200707270038.l6R0cLNV068524@lava.sentex.ca> Date: Fri, 27 Jul 2007 11:07:12 +0200 In-Reply-To: <200707270038.l6R0cLNV068524@lava.sentex.ca> (Mike Tancsa's message of "Thu\, 26 Jul 2007 20\:38\:16 -0400") Message-ID: <8664462p1b.fsf@ds4.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Takeharu KATO , freebsd-current@freebsd.org Subject: Re: ichwd for ICH8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Jul 2007 09:07:16 -0000 Mike Tancsa writes: > Sorry, you are right. I can load it now on the current box I have > running, but it doesnt reboot it, probably because of the BIOS > setting. > [...] > Also, it works on RELENG_6 Does it reboot? > I also tried the patched version on an older box and it looks good too > (running releng_6). Its an ICH5 Intel 865 MB Does it reboot? DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Fri Jul 27 10:09: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 82BCC16A41A for ; Fri, 27 Jul 2007 10:09:52 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.230]) by mx1.freebsd.org (Postfix) with ESMTP id 3EBB113C45D for ; Fri, 27 Jul 2007 10:09:52 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by wx-out-0506.google.com with SMTP id i29so632640wxd for ; Fri, 27 Jul 2007 03:09: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:reply-to:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding:sender; b=jtGg/bEFZu5WUdxwKTMBO7ugwvd/ttre46QxpTQJceFr1UxntR6wxWCTVHX5iid5kVfyookzjLgNDPX0fYWiIxgKQ2lCVg8pRgITB1zaHa3RgKs/Hqd7zfk6NMw4YrMfvYvGvUC5Vp0UhcALe1GDJ/pheEnqDVHc+haB5vlaUjo= 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=A1RgE1acsCC6xqvMG6tfpDkPOx10ioQlhx6uswVCFFR+Fi26J+CFKXECDgqyFKzLGbQkLrWJDdYzHuEuvmYY3CPSWyMVccqG1W7RGvdoSGX6KHjuSzG81SoWLS43qNCYQtK1gzl/veiVLZFkwn3s6pteod/KW61LSakFf4qCRvw= Received: by 10.78.201.10 with SMTP id y10mr713673huf.1185530990404; Fri, 27 Jul 2007 03:09:50 -0700 (PDT) Received: from ?172.31.5.25? ( [89.97.252.178]) by mx.google.com with ESMTPS id 37sm1426490hua.2007.07.27.03.09.49 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 27 Jul 2007 03:09:50 -0700 (PDT) Message-ID: <46A9C437.1080504@FreeBSD.org> Date: Fri, 27 Jul 2007 12:08:55 +0200 From: Attilio Rao User-Agent: Thunderbird 1.5 (X11/20060526) MIME-Version: 1.0 To: Peter Wemm References: <20070721174631.S561@10.0.0.1> <20070722114846.GA97996@rulez.sk> <20070722121631.GA8336@rulez.sk> <200707261750.19994.peter@wemm.org> In-Reply-To: <200707261750.19994.peter@wemm.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: Attilio Rao Cc: Milos Vyletel , current@freebsd.org Subject: Re: ULE status, invalid load, buildkernel times. 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: Fri, 27 Jul 2007 10:09:52 -0000 Peter Wemm wrote: > On Sunday 22 July 2007, Milos Vyletel wrote: >> On Sun, Jul 22, 2007 at 01:48:46PM +0200, Milos Vyletel wrote: > [...] >>> No problem, >>> >>> I've extracted it and made a patch. If someone is intrested, it's >>> on >>> >>> http://rulez.sk/~mv/cpu.patch >> Well, i've just updated my kernel and it paniced right after >> identifying cpu. >> >> CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ (2205.01-MHz >> K8-class CPU) Origin = "AuthenticAMD" Id = 0x20f32 Stepping = 2 >> >> Features=0x178bfbff> PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT> >> Features2=0x1 >> AMD Features=0xe2500800 >> AMD Features2=0x3 >> Cores per package: 2 >> usable memory = 3211776000 (3062 MB) >> avail memory = 3105628160 (2961 MB) >> kernel trap 12 with interrupts disabled >> >> >> Fatal trap 12: page fault while in kernel mode >> cpuid = 0; apic id = 00 >> fault virtual address = 0x310 >> fault code = supervisor read data, page not present >> instruction pointer = 0x8:0xffffffff8033953c >> stack pointer = 0x10:0xffffffff80855c70 >> frame pointer = 0x10:0xffffffff80855c80 >> code segment = base 0x0, limit 0xfffff, type 0x1b >> = DPL 0, pres 1, long 1, def32 0, gran 1 >> processor eflags = resume, IOPL = 0 >> current process = 0 () >> >> this is output from from dmesg. >> >> Thanks for suggestions. >> Milos > > Unfortunately this isn't much help. What would be useful would be to > get a backtrace. If you're not running GENERIC, a copy of your kernel > config would be useful. Any other patches? The patch is not going to work as the slot for SI_ORDER_SECOND was alredy held by kern/subr_smp.c::mp_start() function. Could you please try this comprehensive patch? It has a fix for the mp_start / lapic_init confusion and some tricks with CNXT-ID bit which should exactly identify HTT: http://people.freebsd.org/~attilio/machdep_lapic.diff I have still to stress test it, so please use caution. I will update soon if I will have more information (a 'work for me' / 'don't work for me' would be very appreciated though). Thanks, Attilio From owner-freebsd-current@FreeBSD.ORG Fri Jul 27 10:18: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 D50B816A418 for ; Fri, 27 Jul 2007 10:18:23 +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 4A25113C480 for ; Fri, 27 Jul 2007 10:18:23 +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 l6RAILAv048366; Fri, 27 Jul 2007 14:18:21 +0400 (MSD) (envelope-from marck@rinet.ru) Date: Fri, 27 Jul 2007 14:18:21 +0400 (MSD) From: Dmitry Morozovsky To: emax@FreeBSD.org, current@FreeBSD.org Message-ID: <20070727141421.H42349@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]); Fri, 27 Jul 2007 14:18:21 +0400 (MSD) Cc: Subject: possible showstopper: kbdmux hangs -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, 27 Jul 2007 10:18:23 -0000 Hi there, on some of my mobos -current hangs early (when starning init) if kbdmux is included in kernel (both on i386 and amd64); this seems to be some race, as hangs are not 100% reproducible. What info should I provide to debug? I'm using only PS2 keyboards, and have no other format keyboards handy; however, I can obtain USB keyb if needed. Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Fri Jul 27 10:27: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 222FC16A41A for ; Fri, 27 Jul 2007 10:27:46 +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 A268813C4B3 for ; Fri, 27 Jul 2007 10:27:45 +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 l6RARiZH048585; Fri, 27 Jul 2007 14:27:44 +0400 (MSD) (envelope-from marck@rinet.ru) Date: Fri, 27 Jul 2007 14:27:44 +0400 (MSD) From: Dmitry Morozovsky To: emax@freebsd.org, current@freebsd.org In-Reply-To: <20070727141421.H42349@woozle.rinet.ru> Message-ID: <20070727142646.D42349@woozle.rinet.ru> References: <20070727141421.H42349@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]); Fri, 27 Jul 2007 14:27:44 +0400 (MSD) Cc: Subject: Re: possible showstopper: kbdmux hangs -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, 27 Jul 2007 10:27:46 -0000 On Fri, 27 Jul 2007, Dmitry Morozovsky wrote: DM> on some of my mobos -current hangs early (when starning init) if kbdmux is DM> included in kernel (both on i386 and amd64); this seems to be some race, as DM> hangs are not 100% reproducible. What info should I provide to debug? DM> DM> I'm using only PS2 keyboards, and have no other format keyboards handy; DM> however, I can obtain USB keyb if needed. Possibly worth noting: PS2 keyboard is usually plugged in via KVMs - this may be the source of problems. Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Fri Jul 27 10:37: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 226EA16A41B for ; Fri, 27 Jul 2007 10:37:43 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id DFDA013C457 for ; Fri, 27 Jul 2007 10:37:42 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost2.sentex.ca (8.14.1/8.13.8) with ESMTP id l6RAbe6g071365; Fri, 27 Jul 2007 06:37:40 -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 l6RAbc2Q071412 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Jul 2007 06:37:38 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <200707271037.l6RAbc2Q071412@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 27 Jul 2007 06:37:35 -0400 To: Dag-Erling =?iso-8859-1?Q?Sm=C3=B8rgrav?= From: Mike Tancsa In-Reply-To: <8664462p1b.fsf@ds4.des.no> References: <46337B06.9080102@ybb.ne.jp> <46338C0F.9000608@ybb.ne.jp> <4633932A.8080602@ybb.ne.jp> <86tzuxni1b.fsf@dwp.des.no> <200707061723.l66HNYSe037055@lava.sentex.ca> <86ir86hqhc.fsf@ds4.des.no> <200707262035.l6QKZtnd067391@lava.sentex.ca> <86abtihk6h.fsf@ds4.des.no> <200707262338.l6QNcL1T068284@lava.sentex.ca> <86hcnq900e.fsf@ds4.des.no> <200707270038.l6R0cLNV068524@lava.sentex.ca> <8664462p1b.fsf@ds4.des.no> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Cc: Takeharu KATO , freebsd-current@freebsd.org Subject: Re: ichwd for ICH8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Jul 2007 10:37:43 -0000 At 05:07 AM 7/27/2007, Dag-Erling Sm=C3=B8rgrav wrote: >Mike Tancsa writes: > > Sorry, you are right. I can load it now on the current box I have > > running, but it doesnt reboot it, probably because of the BIOS > > setting. > > [...] > > Also, it works on RELENG_6 > >Does it reboot? Yes it does > > I also tried the patched version on an older box and it looks good too > > (running releng_6). Its an ICH5 Intel 865 MB > >Does it reboot? Yes. I tried again to run it on one of the boxes in=20 zoo.freebsd.org. I enabled the watchdog in the=20 BIOS and I know it kicks in. On this motherboard,=20 if you enable the watchdog in the BIOS, the box=20 will reboot in 4min after posting no matter what,=20 unless the watchdog is properly loaded and=20 set. However, neither your version nor the one=20 in the PR works. It kld loads in both cases, and=20 I can startup watchdogd, but the box will reboot in 4min no matter what I do isab0@pci0:31:0: class=3D0x060100=20 card=3D0x918015d9 chip=3D0x27b88086 rev=3D0x01 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '82801GB/GR (ICH7 Family) LPC Interface Controller' class =3D bridge subclass =3D PCI-ISA cap 09[e0] =3D vendor (length 12) Intel cap 1 version 0 features: Quick Resume, 4 PCI-e x1 slots leopard3# kldload /tmp/ichwd.ko ichwd module loaded ichwd0: on isa0 ichwd0: Intel ICH7 watchdog timer (ICH7 or equivalent) ppc0: parallel port not found. leopard3# and same with the version from the PR. leopard3# kldload /tmp/ichwd.ko ichwd module loaded ichwd0: on isa0 ichwd0: Intel ICH7 watchdog timer (TCO version 2) ppc0: parallel port not found. leopard3# watchdogd -t 20 leopard3# But if I startup watchdogd (it seems to be=20 running), the box ends up being rebooted in 4=20 min. If I kill -9 watchdogd, it still reboots in 4min, and not any quicker. But my other ich7 box works as expected (kldloads=20 and box reboots after doing a kill -9 on watchdogd) isab0@pci0:31:0: class=3D0x060100=20 card=3D0x348f8086 chip=3D0x27b88086 rev=3D0x01 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '82801GB/GR (ICH7 Family) LPC Interface Controller' class =3D bridge subclass =3D PCI-ISA cap 09[e0] =3D vendor (length 12) Intel cap 1 version 0 features: Quick Resume, 4 PCI-e x1 slots ---Mike=20 From owner-freebsd-current@FreeBSD.ORG Fri Jul 27 12:43:13 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 2E7E016A417 for ; Fri, 27 Jul 2007 12:43:13 +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 21FD513C474 for ; Fri, 27 Jul 2007 12:43:12 +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 033CE46F2D for ; Fri, 27 Jul 2007 08:40:29 -0400 (EDT) Date: Fri, 27 Jul 2007 13:40:28 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: current@FreeBSD.org Message-ID: <20070727130024.C46637@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Subject: HEADS UP: debug.mpsafenet removed (cvs commit: src/sys/dev/ath/ath_rate/amrr amrr.c src/sys/dev/ath/ath_rate/onoe onoe.c src/sys/dev/ce if_ce.c src/sys/dev/cp if_cp.c src/sys/dev/ctau if_ct.c src/sys/dev/cx if_cx.c src/sys/kern subr_bus.c uipc_domain.c src/sys/net if.c if_ethersubr.c netisr.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, 27 Jul 2007 12:43:13 -0000 This is the first of two e-mails relating to the removal of Giant-compatibility code from the network protocol stack. Please read both. Per intermittent e-mails and notifications over the last three years, I have now removed the NET_NEEDS_GIANT() and debug.mpsafenet machinery from the 7-CURRENT kernel. This is, in principle, largely a no-op, as no NET_NEEDS_GIANT() components remain in the kernel, and all remaining components are intended to be MPSAFE, and the vast majority of users have been running without Giant over the network stack since about FreeBSD 5.3. However, bumps inevitably happen, so please let me know: - *If* you are using credential-based rules in your ipfw or pf firewall configuration, this may trigger WITNESS lock order reversal warnings. We plan to suppress these warnings before the release, so the warnings alone should not present a problem. However, if you experience deadlocks as a result, drop e-mail to current@ as soon as possible so that they can be diagnosed and fixed. - *If* you have been running with debug.mpsafenet because it suppressed some other warning you have, to date, neglected to e-mail current@ about, or not reminded us about frequently, *and* it now recurs as a result of debug.mpsafenet going away, please send e-mail to current@ as soon as possible. A series of follow-up commits to remove various straggling references and compatibility pieces will now occur, including converting all NET_CALLOUT_MPSAFE references to CALLOUT_MPSAFE, and removing calls to NET_*_GIANT() at various points in the protocol and driver code. Non-MPSAFE device drivers flagged with IFF_NEEDSGIANT should remain unaffected, as the code to acquire Giant before entering from the network stack will remain in place, and those drivers will not be passing the MPSAFE flag into the interrupt registration code. Thanks, Robert N M Watson Computer Laboratory University of Cambridge ---------- Forwarded message ---------- Date: Fri, 27 Jul 2007 11:59:57 +0000 (UTC) From: Robert Watson To: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org Subject: cvs commit: src/sys/dev/ath/ath_rate/amrr amrr.c src/sys/dev/ath/ath_rate/onoe onoe.c src/sys/dev/ce if_ce.c src/sys/dev/cp if_cp.c src/sys/dev/ctau if_ct.c src/sys/dev/cx if_cx.c src/sys/kern subr_bus.c uipc_domain.c src/sys/net if.c if_ethersubr.c netisr.c ... rwatson 2007-07-27 11:59:57 UTC FreeBSD src repository Modified files: sys/dev/ath/ath_rate/amrr amrr.c sys/dev/ath/ath_rate/onoe onoe.c sys/dev/ce if_ce.c sys/dev/cp if_cp.c sys/dev/ctau if_ct.c sys/dev/cx if_cx.c sys/kern subr_bus.c uipc_domain.c sys/net if.c if_ethersubr.c netisr.c sys/nfsserver nfs_srvsubs.c nfs_syscalls.c sys/sys kernel.h mutex.h Log: First in a series of changes to remove the now-unused Giant compatibility framework for non-MPSAFE network protocols: - Remove debug_mpsafenet variable, sysctl, and tunable. - Remove NET_NEEDS_GIANT() and associate SYSINITSs used by it to force debug.mpsafenet=0 if non-MPSAFE protocols are compiled into the kernel. - Remove logic to automatically flag interrupt handlers as non-MPSAFE if debug.mpsafenet is set for an INTR_TYPE_NET handler. - Remove logic to automatically flag netisr handlers as non-MPSAFE if debug.mpsafenet is set. - Remove references in a few subsystems, including NFS and Cronyx drivers, which keyed off debug_mpsafenet to determine various aspects of their own locking behavior. - Convert NET_LOCK_GIANT(), NET_UNLOCK_GIANT(), and NET_ASSERT_GIANT into no-op's, as their entire behavior was determined by the value in debug_mpsafenet. - Alias NET_CALLOUT_MPSAFE to CALLOUT_MPSAFE. Many remaining references to NET_.*_GIANT() and NET_CALLOUT_MPSAFE are still present in subsystems, and will be removed in followup commits. Reviewed by: bz, jhb Approved by: re (kensmith) Revision Changes Path 1.14 +1 -1 src/sys/dev/ath/ath_rate/amrr/amrr.c 1.15 +1 -1 src/sys/dev/ath/ath_rate/onoe/onoe.c 1.9 +0 -7 src/sys/dev/ce/if_ce.c 1.34 +0 -5 src/sys/dev/cp/if_cp.c 1.34 +0 -5 src/sys/dev/ctau/if_ct.c 1.57 +0 -5 src/sys/dev/cx/if_cx.c 1.201 +0 -3 src/sys/kern/subr_bus.c 1.50 +2 -7 src/sys/kern/uipc_domain.c 1.273 +1 -8 src/sys/net/if.c 1.235 +1 -1 src/sys/net/if_ethersubr.c 1.19 +0 -92 src/sys/net/netisr.c 1.148 +1 -4 src/sys/nfsserver/nfs_srvsubs.c 1.115 +2 -8 src/sys/nfsserver/nfs_syscalls.c 1.136 +0 -5 src/sys/sys/kernel.h 1.99 +5 -22 src/sys/sys/mutex.h From owner-freebsd-current@FreeBSD.ORG Fri Jul 27 12:46:54 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 20C6916A417 for ; Fri, 27 Jul 2007 12:46:54 +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 BC01813C467 for ; Fri, 27 Jul 2007 12:46:53 +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 2D4D749D44 for ; Fri, 27 Jul 2007 08:46:52 -0400 (EDT) Date: Fri, 27 Jul 2007 13:46:52 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: current@FreeBSD.org Message-ID: <20070727134047.O46637@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Subject: Thanks for all the work on the MPSAFE network stack project X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Jul 2007 12:46:54 -0000 Dear all, Thanks again to everyone involved in this multi-year project to make our network stack fully parallel. It has been a huge project, and the number of people who've worked on it is sufficiently long as to be not easily captured. I would like to acknowledge everyone involved, and apologize for missed names. The following FreeBSD developers and other individuals have all made significant contributions to this work, and deserve many thanks: John Baldwin, John Birrell, Antoine Brodin, Jake Burkholder, Alan Cox, Brooks Davis, Pawel Dawidek, Matthew Dillon, Tor Egge, Julian Elischer, Ruslan Ermilov, Bruce Evans, Don Lewis, Brian Feldman, Andrew Gallatin, John-Mark Gurney, Paul Holes, Peter Holm, Jeffrey Hsu, Kris Kennaway, Maxim Konovalov, Joseph Koshy, Wojciech Koszek, Roman Kurakin, Max Laier, Nate Lawson, Sam Leffler, Jonathan Lemon, Warner Losh, Don Lewis, Qing Li, Scott Long, Warner Losh, Kip Macy, Rick Macklem, Ed Maste, Bosko Milekic, Marcel Moolenaar, George Neville-Neil, Andre Oppermann, Chuck Paterson, Bill Paul, Alfred Perlstein, Paolo Pisati, Attilio Rao, Luigi Rizzo, Jeff Roberson, Paul Saab, Hidetoshi Shimokawa, Mike Silberback, Bruce Simpson, Gleb Smirnoff, Dag-Erling Smorgrav, Mohan Srinivasan, Randall Stewart, Marius Strobl, Mike Tancsa, Seigo Tanimura, JINMEI Tatuya, Andrew Thompson, Hajimu UMEMOTO, Stephan Uphoff, Peter Wemm, David Xu, Jennifer Yang, Maksim Yevmenkin, Pyun YongHyeon, and Bjoern Zeeb. The support of many FreeBSD-consuming companies and organizations was instrumental in making this work happen, especially with regard to sponsoring development, providing testing resources, hardware, etc: BSDI, who contributed prototype reference source code for parts of a finer-grained implementation of the BSD kernel, and specifically, network stack, as well as their early development support for the SMPng Project as a whole. The FreeBSD Foundation, who provided sponsorship to fund portions of the development, as well as test hardware, as well as sponsoring conferences, developer summits, and developer travel in order to bring together developers working on the project. All FreeBSD Foundation sponsors deserve our thanks for helping to make this possible -- you can find the names of some of these sponsors on the FreeBSD Foundation web site, and get your own name added there by making a donation yourself :-). In addition, I'd like to thank Sentex Data Communications and the Internet Software Consortium for their support in providing test environments for this work. Isilon Systems also provided sponsorship for the MPSAFE VFS work, which overlapped with this work in several areas including the NFS server. Yahoo! has provided significant testing support, as well as supporting several developers who worked on this project. Hardware has been donated by many companies, but especially by Cisco, iXsystems, HP, FreeBSD Systems, Myricom, AMD, Neterion, Chelsio, Intel, and IronPort Systems (now also a Cisco company). Finally, I want to thank all the members of the FreeBSD community for their diligence in reporting and tracking bugs, tolerance of occasional minor (and major) instability, and supportive words for this project over many yeras. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Fri Jul 27 13:15: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 4D57C16A417; Fri, 27 Jul 2007 13:15:23 +0000 (UTC) (envelope-from werner@btr0x22.rz.uni-bayreuth.de) Received: from btr0xn-tx.rz.uni-bayreuth.de (btr0xn.rz.uni-bayreuth.de [132.180.8.26]) by mx1.freebsd.org (Postfix) with ESMTP id E831613C442; Fri, 27 Jul 2007 13:15:22 +0000 (UTC) (envelope-from werner@btr0x22.rz.uni-bayreuth.de) Received: from localhost (localhost [127.0.0.1]) by btr0xn-tx.rz.uni-bayreuth.de (8.13.1/8.13.1) with ESMTP id l6RC16f4029637; Fri, 27 Jul 2007 14:01:06 +0200 (MEST) Received: from btr0xn-rx.rz.uni-bayreuth.de ([127.0.0.1]) by localhost (mailhub-out.uni-bayreuth.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29266-06; Fri, 27 Jul 2007 14:00:54 +0200 (MEST) Received: from btruxe.rz.uni-bayreuth.de (btruxe [132.180.14.135]) by btr0xn-rx.rz.uni-bayreuth.de (8.13.1/8.13.1) with ESMTP id l6RC0kgJ029621; Fri, 27 Jul 2007 14:00:46 +0200 (MEST) Message-ID: <46A9DE6E.5000202@btr0x22.rz.uni-bayreuth.de> Date: Fri, 27 Jul 2007 14:00:46 +0200 From: Werner Griessl Organization: UNI Bayreuth RZ User-Agent: Thunderbird 2.0.0.5 (X11/20070721) MIME-Version: 1.0 To: Dmitry Morozovsky References: <20070727141421.H42349@woozle.rinet.ru> <20070727142646.D42349@woozle.rinet.ru> In-Reply-To: <20070727142646.D42349@woozle.rinet.ru> Content-Type: multipart/mixed; boundary="------------000306030306060003060708" X-Virus-Scanned: amavisd-new at uni-bayreuth.de Cc: emax@freebsd.org, current@freebsd.org Subject: Re: possible showstopper: kbdmux hangs -current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: werner@btr0x22.rz.uni-bayreuth.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2007 13:15:23 -0000 This is a multi-part message in MIME format. --------------000306030306060003060708 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dmitry Morozovsky wrote: > On Fri, 27 Jul 2007, Dmitry Morozovsky wrote: > > DM> on some of my mobos -current hangs early (when starning init) if kbdmux is > DM> included in kernel (both on i386 and amd64); this seems to be some race, as > DM> hangs are not 100% reproducible. What info should I provide to debug? > DM> > DM> I'm using only PS2 keyboards, and have no other format keyboards handy; > DM> however, I can obtain USB keyb if needed. > > Possibly worth noting: PS2 keyboard is usually plugged in via KVMs - this may > be the source of problems. > > > 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" > Unfortunately not, Have the same problem here with an ASUS-mobo (Athlon X2) with 7-current-amd64 and i386 with PS2 and USB-Keyboard. Every combination of amd64,i386,ps2,usb hangs. The machine ist completely responsible over the network, but hangs on the console. Only cntl-alt-del is working (reboots after a few seconds). Sometimes (1 of 10 boots) the machine comes to the console-prompt. Attached is a dmesg with 6.2-Stable for this machine. There are no problems with 6.2-Stable. Werner --------------000306030306060003060708 Content-Type: text/plain; name="dmesg-6.2.werner1" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="dmesg-6.2.werner1" 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 6.2-STABLE #0: Fri Jul 27 12:24:48 CEST 2007 root@werner1.test.privat.priv:/usr/src/sys/i386/compile/SMP-WERNER1 ACPI APIC Table: Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ (2210.07-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x20f32 Stepping = 2 Features=0x178bfbff Features2=0x1 AMD Features=0xe2500800 AMD Features2=0x3 Cores per package: 2 real memory = 1073414144 (1023 MB) avail memory = 1032798208 (984 MB) FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0 irqs 0-23 on motherboard bktr_mem: memory holder loaded kbd1 at kbdmux0 ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x508-0x50b on acpi0 cpu0: on acpi0 acpi_throttle0: on cpu0 cpu1: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: at device 0.0 (no driver attached) pci0: at device 0.1 (no driver attached) pci0: at device 0.2 (no driver attached) pci0: at device 0.3 (no driver attached) pci0: at device 0.4 (no driver attached) pci0: at device 0.5 (no driver attached) pci0: at device 0.6 (no driver attached) pci0: at device 0.7 (no driver attached) pcib1: at device 2.0 on pci0 pci1: on pcib1 pcib2: at device 3.0 on pci0 pci2: on pcib2 mskc0: port 0xe800-0xe8ff mem 0xd7ffc000-0xd7ffffff irq 16 at device 0.0 on pci2 msk0: on mskc0 msk0: Ethernet address: 00:1a:92:2e:8c:51 miibus0: on msk0 e1000phy0: on miibus0 e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX-FDX, auto mskc0: [FAST] pcib3: at device 4.0 on pci0 pci3: on pcib3 nvidia0: mem 0xd8000000-0xdbffffff,0xc8000000-0xcfffffff,0xde000000-0xdeffffff irq 16 at device 0.0 on pci3 nvidia0: [GIANT-LOCKED] pci0: at device 9.0 (no driver attached) isab0: at device 10.0 on pci0 isa0: on isab0 nfsmb0: port 0xdc00-0xdc1f,0x600-0x63f,0x700-0x73f irq 20 at device 10.1 on pci0 smbus0: on nfsmb0 nfsmb1: on nfsmb0 smbus1: on nfsmb1 ohci0: mem 0xd7efe000-0xd7efefff irq 21 at device 11.0 on pci0 ohci0: [GIANT-LOCKED] usb0: OHCI version 1.0, legacy support usb0: SMM does not respond, resetting usb0: on ohci0 usb0: USB revision 1.0 uhub0: nVidia OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 10 ports with 10 removable, self powered ehci0: mem 0xd7effc00-0xd7effcff irq 22 at device 11.1 on pci0 ehci0: [GIANT-LOCKED] usb1: EHCI version 1.0 usb1: companion controller, 4 ports each: usb0 usb1: on ehci0 usb1: USB revision 2.0 uhub1: nVidia EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub1: 10 ports with 10 removable, self powered umass0: ENE UB6220, rev 2.00/1.00, addr 2 pcm0: port 0xd400-0xd4ff,0xd000-0xd0ff mem 0xd7efd000-0xd7efdfff irq 23 at device 13.0 on pci0 pcm0: atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at device 15.0 on pci0 ata0: on atapci0 ata1: on atapci0 atapci1: port 0xcc00-0xcc07,0xc880-0xc883,0xc800-0xc807,0xc480-0xc483,0xc400-0xc40f mem 0xd7efc000-0xd7efcfff irq 20 at device 16.0 on pci0 ata2: on atapci1 ata3: on atapci1 atapci2: port 0xc080-0xc087,0xc000-0xc003,0xbc00-0xbc07,0xb880-0xb883,0xb800-0xb80f mem 0xd7efb000-0xd7efbfff irq 21 at device 17.0 on pci0 ata4: on atapci2 ata5: on atapci2 pcib4: at device 18.0 on pci0 pci4: on pcib4 ath0: mem 0xdfff0000-0xdfffffff irq 16 at device 6.0 on pci4 ath0: Ethernet address: 00:40:f4:a1:07:2a ath0: mac 7.9 phy 4.5 radio 5.6 bktr0: mem 0xd6ffe000-0xd6ffefff irq 17 at device 7.0 on pci4 bktr0: [GIANT-LOCKED] bktr0: Hauppauge Model 61344 D221 bktr0: Detected a MSP3415D-B3 at 0x80 bktr0: Hauppauge WinCast/TV, Philips FR1216 PAL FM tuner, msp3400c stereo, remote control. pci4: at device 7.1 (no driver attached) fwohci0: mem 0xdffef800-0xdffeffff,0xdffe8000-0xdffebfff irq 16 at device 11.0 on pci4 fwohci0: OHCI version 1.10 (ROM=1) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:11:d8:00:01:19:95:48 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:11:d8:19:95:48 fwe0: Ethernet address: 02:11:d8:19:95:48 fwe0: if_start running deferred for Giant sbp0: on firewire0 fwohci0: Initiate bus reset fwohci0: BUS reset fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) nve0: port 0xb480-0xb487 mem 0xd7efa000-0xd7efafff irq 22 at device 19.0 on pci0 nve0: Ethernet address 00:1a:92:2e:9b:75 miibus1: on nve0 e1000phy1: on miibus1 e1000phy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX-FDX, auto nve0: Ethernet address: 00:1a:92:2e:9b:75 pcib5: at device 22.0 on pci0 pci5: on pcib5 pcib6: at device 23.0 on pci0 pci6: on pcib6 acpi_button0: on acpi0 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FAST] ppc0: port 0x378-0x37f,0x778-0x77f irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/16 bytes threshold ppbus0: on ppc0 plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A pmtimer0 on isa0 orm0: at iomem 0xc0000-0xcefff on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ukbd0: Device USB Device, rev 1.10/1.03, addr 2, iclass 3/1 kbd2 at ukbd0 ums0: Device USB Device, rev 1.10/1.03, addr 2, iclass 3/1 ums0: 3 buttons and Z dir. Timecounters tick every 1.000 msec ad0: 78167MB at ata0-master UDMA133 acd0: DVDR at ata1-master UDMA33 ad4: 286188MB at ata2-master SATA150 SMP: AP CPU #1 Launched! da0 at umass-sim0 bus 0 target 0 lun 0 da0: Removable Direct Access SCSI-0 device da0: 40.000MB/s transfers da0: Attempt to query device size failed: NOT READY, Medium not present da1 at umass-sim0 bus 0 target 0 lun 1 da1: Removable Direct Access SCSI-0 device da1: 40.000MB/s transfers da1: Attempt to query device size failed: NOT READY, Medium not present da2 at umass-sim0 bus 0 target 0 lun 2 da2: Removable Direct Access SCSI-0 device da2: 40.000MB/s transfers da2: Attempt to query device size failed: NOT READY, Medium not present da3 at umass-sim0 bus 0 target 0 lun 3 da3: Removable Direct Access SCSI-0 device da3: 40.000MB/s transfers da3: Attempt to query device size failed: NOT READY, Medium not present Trying to mount root from ufs:/dev/ad4s1a mskc0: Uncorrectable PCI Express error ipfw2 (+ipv6) initialized, divert loadable, rule-based forwarding disabled, default to deny, logging disabled msk0: link state changed to UP mskc0: Uncorrectable PCI Express error --------------000306030306060003060708-- From owner-freebsd-current@FreeBSD.ORG Fri Jul 27 13:23: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 B781C16A417; Fri, 27 Jul 2007 13:23:11 +0000 (UTC) (envelope-from tobez@tobez.org) Received: from heechee.tobez.org (heechee.tobez.org [194.255.56.42]) by mx1.freebsd.org (Postfix) with ESMTP id 6EFDA13C428; Fri, 27 Jul 2007 13:23:11 +0000 (UTC) (envelope-from tobez@tobez.org) Received: by heechee.tobez.org (Postfix, from userid 1001) id 9D7DB12543D; Fri, 27 Jul 2007 15:06:13 +0200 (CEST) Date: Fri, 27 Jul 2007 15:06:13 +0200 From: Anton Berezin To: Robert Watson Message-ID: <20070727130613.GE41151@heechee.tobez.org> Mail-Followup-To: Anton Berezin , Robert Watson , current@FreeBSD.org References: <20070727134047.O46637@fledge.watson.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070727134047.O46637@fledge.watson.org> User-Agent: Mutt/1.4.2.3i X-Powered-By: FreeBSD http://www.freebsd.org/ Cc: current@FreeBSD.org Subject: Re: Thanks for all the work on the MPSAFE network stack project X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Jul 2007 13:23:11 -0000 On Fri, Jul 27, 2007 at 01:46:52PM +0100, Robert Watson wrote: > Thanks again to everyone involved in this multi-year project to make our > network stack fully parallel. It has been a huge project, and the number > of people who've worked on it is sufficiently long as to be not easily > captured. I would like to acknowledge everyone involved, and apologize for > missed names. The following FreeBSD developers and other individuals have > all made significant contributions to this work, and deserve many thanks: > John Baldwin, John Birrell, Antoine Brodin, Jake Burkholder, Alan Cox, > Brooks Davis, Pawel Dawidek, Matthew Dillon, Tor Egge, Julian Elischer, > Ruslan Ermilov, Bruce Evans, Don Lewis, Brian Feldman, Andrew Gallatin, > John-Mark Gurney, Paul Holes, Peter Holm, Jeffrey Hsu, Kris Kennaway, Maxim > Konovalov, Joseph Koshy, Wojciech Koszek, Roman Kurakin, Max Laier, Nate > Lawson, Sam Leffler, Jonathan Lemon, Warner Losh, Don Lewis, Qing Li, Scott > Long, Warner Losh, Kip Macy, Rick Macklem, Ed Maste, Bosko Milekic, Marcel > Moolenaar, George Neville-Neil, Andre Oppermann, Chuck Paterson, Bill Paul, > Alfred Perlstein, Paolo Pisati, Attilio Rao, Luigi Rizzo, Jeff Roberson, > Paul Saab, Hidetoshi Shimokawa, Mike Silberback, Bruce Simpson, Gleb > Smirnoff, Dag-Erling Smorgrav, Mohan Srinivasan, Randall Stewart, Marius > Strobl, Mike Tancsa, Seigo Tanimura, JINMEI Tatuya, Andrew Thompson, Hajimu > UMEMOTO, Stephan Uphoff, Peter Wemm, David Xu, Jennifer Yang, Maksim > Yevmenkin, Pyun YongHyeon, and Bjoern Zeeb. So, Don Lewis and Warner Losh get twice the thanks? :-) Seriously though, thank you all guys for your hard work! \Anton. -- We're going for 'working' here. 'clean' is for people with skills... -- Flemming Jacobsen From owner-freebsd-current@FreeBSD.ORG Fri Jul 27 13:26:54 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 8F1AF16A41F for ; Fri, 27 Jul 2007 13:26:54 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 7BCF513C46C for ; Fri, 27 Jul 2007 13:26:54 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from rot26.obsecurity.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id B9F1A1A4D82; Fri, 27 Jul 2007 06:26:49 -0700 (PDT) Received: by rot26.obsecurity.org (Postfix, from userid 1001) id EF924BB74; Fri, 27 Jul 2007 09:26:40 -0400 (EDT) Date: Fri, 27 Jul 2007 09:26:40 -0400 From: Kris Kennaway To: Milos Vyletel Message-ID: <20070727132640.GA6877@rot26.obsecurity.org> References: <20070721174631.S561@10.0.0.1> <20070722114846.GA97996@rulez.sk> <20070722121631.GA8336@rulez.sk> <200707261806.20554.peter@wemm.org> <20070727074832.GA69608@rulez.sk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070727074832.GA69608@rulez.sk> User-Agent: Mutt/1.4.2.3i Cc: current@freebsd.org, Peter Wemm Subject: Re: ULE status, invalid load, buildkernel 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: Fri, 27 Jul 2007 13:26:54 -0000 On Fri, Jul 27, 2007 at 09:48:32AM +0200, Milos Vyletel wrote: > On Thu, Jul 26, 2007 at 06:06:20PM -0700, Peter Wemm wrote: > > The other option is to find the kernel.debug for this crash, and do > > this: > > kgdb kernel.debug > > gdb> l *0xffffffff8033953c > > This will tell us the file and line number that the crash happened in. > > There is no need to reboot for this unless you no longer have a > > crashing kernel. > > I've played with this a little while, and after turning INVARIANTS on, it > paniced in lapic_ipi_raw() on the > KASSERT(lapic != NULL, ("%s called too early", __func__)); > > so I assume, that this function was called before lapic_init(), where lapic is initialized, which is wrong. > > It was clean current kernel with no other patches, now I don't have local > access to that machine so I can test it in few days. > > btw. how can one get trace in text form, I mean syslog stop after panic and all > I got logged is that it paniced. Anything I type in db> is lost. I know that > this can be done by remote gdb, but unfortunatelly this isn't possible. If you trigger a dump (call doadump) then some amount of the DDB session will usually be saved with the dump and displayed by kgdb. Kris From owner-freebsd-current@FreeBSD.ORG Fri Jul 27 13:31: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 7BDFC16A418 for ; Fri, 27 Jul 2007 13:31:23 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 0C93713C4B5 for ; Fri, 27 Jul 2007 13:31: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 BF8DD494A7; Fri, 27 Jul 2007 09:31:21 -0400 (EDT) Date: Fri, 27 Jul 2007 14:31:21 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Anton Berezin In-Reply-To: <20070727130613.GE41151@heechee.tobez.org> Message-ID: <20070727143039.G46637@fledge.watson.org> References: <20070727134047.O46637@fledge.watson.org> <20070727130613.GE41151@heechee.tobez.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: current@FreeBSD.org Subject: Re: Thanks for all the work on the MPSAFE network stack project X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Jul 2007 13:31:23 -0000 On Fri, 27 Jul 2007, Anton Berezin wrote: > On Fri, Jul 27, 2007 at 01:46:52PM +0100, Robert Watson wrote: > >> Thanks again to everyone involved in this multi-year project to make our >> network stack fully parallel. It has been a huge project, and the number >> of people who've worked on it is sufficiently long as to be not easily >> captured. I would like to acknowledge everyone involved, and apologize for >> missed names. The following FreeBSD developers and other individuals have >> all made significant contributions to this work, and deserve many thanks: > >> John Baldwin, John Birrell, Antoine Brodin, Jake Burkholder, Alan Cox, >> Brooks Davis, Pawel Dawidek, Matthew Dillon, Tor Egge, Julian Elischer, >> Ruslan Ermilov, Bruce Evans, Don Lewis, Brian Feldman, Andrew Gallatin, >> John-Mark Gurney, Paul Holes, Peter Holm, Jeffrey Hsu, Kris Kennaway, Maxim >> Konovalov, Joseph Koshy, Wojciech Koszek, Roman Kurakin, Max Laier, Nate >> Lawson, Sam Leffler, Jonathan Lemon, Warner Losh, Don Lewis, Qing Li, Scott >> Long, Warner Losh, Kip Macy, Rick Macklem, Ed Maste, Bosko Milekic, Marcel >> Moolenaar, George Neville-Neil, Andre Oppermann, Chuck Paterson, Bill Paul, >> Alfred Perlstein, Paolo Pisati, Attilio Rao, Luigi Rizzo, Jeff Roberson, >> Paul Saab, Hidetoshi Shimokawa, Mike Silberback, Bruce Simpson, Gleb >> Smirnoff, Dag-Erling Smorgrav, Mohan Srinivasan, Randall Stewart, Marius >> Strobl, Mike Tancsa, Seigo Tanimura, JINMEI Tatuya, Andrew Thompson, Hajimu >> UMEMOTO, Stephan Uphoff, Peter Wemm, David Xu, Jennifer Yang, Maksim >> Yevmenkin, Pyun YongHyeon, and Bjoern Zeeb. > > So, Don Lewis and Warner Losh get twice the thanks? :-) > > Seriously though, thank you all guys for your hard work! Christian Peron and Alexander Motin also got left out, so there is some balance in the universe :-). Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Fri Jul 27 13:33:38 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 AECDC16A417 for ; Fri, 27 Jul 2007 13:33:38 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id 8A82113C45E for ; Fri, 27 Jul 2007 13:33:38 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost2.sentex.ca (8.14.1/8.13.8) with ESMTP id l6RDXVjr079731; Fri, 27 Jul 2007 09:33:31 -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 l6RDXUmR072174 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Jul 2007 09:33:30 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <200707271333.l6RDXUmR072174@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 27 Jul 2007 09:33:26 -0400 To: Jeff Roberson , current@freebsd.org From: Mike Tancsa In-Reply-To: <7.1.0.9.0.20070717152301.27a24478@sentex.net> References: <20070716233030.D92541@10.0.0.1> <7.1.0.9.0.20070717152301.27a24478@sentex.net> 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: Fri, 27 Jul 2007 13:33:38 -0000 At 03:26 PM 7/17/2007, Mike Tancsa wrote: >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. Had some newer boxes I was testing on the bench before putting them in the perf cluster. Same hardware, CURRENT from yesterday time make -j2 buildworld > /var/log/build.out time make -j4 buildworld > /var/log/build.out time make -j8 buildworld > /var/log/build.out time make -j10 buildworld > /var/log/build.out time make -j14 buildworld > /var/log/build.out time make -j16 buildworld > /var/log/build.out time make -j18 buildworld > /var/log/build.out time make -j24 buildworld > /var/log/build.out 0[hydra1]# sysctl -a kern.sched kern.sched.runq_fuzz: 1 kern.sched.preemption: 1 kern.sched.ipiwakeup.htt2: 0 kern.sched.ipiwakeup.onecpu: 0 kern.sched.ipiwakeup.useloop: 0 kern.sched.ipiwakeup.usemask: 1 kern.sched.ipiwakeup.delivered: 36221638 kern.sched.ipiwakeup.requested: 36221461 kern.sched.ipiwakeup.enabled: 1 kern.sched.quantum: 100000 kern.sched.name: 4BSD 0[hydra1]# 2787.488u 451.970s 29:55.01 180.4% 5765+1063k 20950+181419io 1935pf+0w 2829.800u 593.261s 17:26.51 327.0% 5703+1055k 1747+181416io 536pf+0w 2914.180u 831.262s 12:14.97 509.6% 5650+1048k 1547+181416io 534pf+0w 2943.049u 864.558s 12:29.44 508.0% -5630+1048k 1549+181449io 534pf+0w 2951.000u 908.972s 12:42.39 506.2% -5481+1048k 1544+181439io 534pf+0w 2952.665u 931.201s 12:39.08 511.6% -5413+1047k 1541+181397io 534pf+0w 2961.467u 937.847s 12:49.09 507.0% -5371+1047k 1543+181423io 534pf+0w 2961.957u 983.947s 12:58.20 507.0% -5238+1047k 1542+181435io 534pf+0w vs ULE 0[hydra2]# sysctl kern.sched kern.sched.preemption: 1 kern.sched.topology: 0 kern.sched.steal_thresh: 2 kern.sched.steal_idle: 1 kern.sched.steal_htt: 0 kern.sched.balance_secs: 1 kern.sched.balance: 1 kern.sched.tryself: 1 kern.sched.affinity: 3 kern.sched.pick_pri: 1 kern.sched.preempt_thresh: 64 kern.sched.interact: 30 kern.sched.slice: 13 kern.sched.name: ULE 0[hydra2]# 2780.017u 425.475s 28:40.12 186.3% 5806+1068k 21162+4934io 1929pf+0w 2820.171u 521.349s 16:18.90 341.3% 5772+1064k 1693+4968io 534pf+0w 2866.390u 676.119s 12:19.83 478.8% 5714+1057k 1648+4970io 534pf+0w 2883.521u 709.969s 12:29.52 479.4% 5701+1055k 1647+5006io 534pf+0w 2911.001u 801.767s 12:55.74 478.6% 5680+1053k 1650+4974io 534pf+0w 2926.022u 863.136s 13:17.31 475.2% -5656+1052k 1643+5013io 534pf+0w 2937.156u 923.333s 13:28.78 477.3% -5448+1051k 1640+5048io 534pf+0w 2969.080u 1096.393s 13:50.15 489.7% -4885+1051k 1642+5126io 534pf+0w CPU: Intel(R) Xeon(R) CPU E5320 @ 1.86GHz (1866.74-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6f7 Stepping = 7 Features=0xbfebfbff Features2=0x4e3bd AMD Features=0x20100000 AMD Features2=0x1 Cores per package: 4 real memory = 3489005568 (3327 MB) avail memory = 3409797120 (3251 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 cpu4 (AP): APIC ID: 4 cpu5 (AP): APIC ID: 5 cpu6 (AP): APIC ID: 6 cpu7 (AP): APIC ID: 7 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-47 on motherboard ---Mike From owner-freebsd-current@FreeBSD.ORG Fri Jul 27 13:33:47 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 2838416A4DC for ; Fri, 27 Jul 2007 13:33:47 +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 DDAEC13C457 for ; Fri, 27 Jul 2007 13:33:46 +0000 (UTC) (envelope-from mv@rulez.sk) Received: from localhost (localhost [127.0.0.1]) by mail.rulez.sk (Postfix) with ESMTP id D71CB5C37; Fri, 27 Jul 2007 15:33:45 +0200 (CEST) X-Virus-Scanned: by amavisd-new at mail.rulez.sk Received: by mail.rulez.sk (Postfix, from userid 1020) id D8FB75C33; Fri, 27 Jul 2007 15:33:42 +0200 (CEST) Date: Fri, 27 Jul 2007 15:33:42 +0200 From: Milos Vyletel To: Kris Kennaway Message-ID: <20070727133342.GA12179@rulez.sk> References: <20070721174631.S561@10.0.0.1> <20070722114846.GA97996@rulez.sk> <20070722121631.GA8336@rulez.sk> <200707261806.20554.peter@wemm.org> <20070727074832.GA69608@rulez.sk> <20070727132640.GA6877@rot26.obsecurity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070727132640.GA6877@rot26.obsecurity.org> User-Agent: Mutt/1.4.2.2i Cc: current@freebsd.org Subject: Re: ULE status, invalid load, buildkernel 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: Fri, 27 Jul 2007 13:33:47 -0000 On Fri, Jul 27, 2007 at 09:26:40AM -0400, Kris Kennaway wrote: > On Fri, Jul 27, 2007 at 09:48:32AM +0200, Milos Vyletel wrote: > > On Thu, Jul 26, 2007 at 06:06:20PM -0700, Peter Wemm wrote: > > > The other option is to find the kernel.debug for this crash, and do > > > this: > > > kgdb kernel.debug > > > gdb> l *0xffffffff8033953c > > > This will tell us the file and line number that the crash happened in. > > > There is no need to reboot for this unless you no longer have a > > > crashing kernel. > > > > I've played with this a little while, and after turning INVARIANTS on, it > > paniced in lapic_ipi_raw() on the > > KASSERT(lapic != NULL, ("%s called too early", __func__)); > > > > so I assume, that this function was called before lapic_init(), where lapic is initialized, which is wrong. > > > > It was clean current kernel with no other patches, now I don't have local > > access to that machine so I can test it in few days. > > > > btw. how can one get trace in text form, I mean syslog stop after panic and all > > I got logged is that it paniced. Anything I type in db> is lost. I know that > > this can be done by remote gdb, but unfortunatelly this isn't possible. > > If you trigger a dump (call doadump) then some amount of the DDB > session will usually be saved with the dump and displayed by kgdb. > Yes, I forgot about that. I have zfs swap partition and I can't configure my dumpdev. Have anyone succesfully acomplish this? mv From owner-freebsd-current@FreeBSD.ORG Fri Jul 27 13:47: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 E1E9616A419 for ; Fri, 27 Jul 2007 13:47:55 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.173]) by mx1.freebsd.org (Postfix) with ESMTP id 369AB13C457 for ; Fri, 27 Jul 2007 13:47:54 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by ug-out-1314.google.com with SMTP id o4so791281uge for ; Fri, 27 Jul 2007 06:47: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:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=hDhqzMve5QNfgm2fF/19JKtyIfF9xJ1uCGPQnNbEs0/7CK7KMsO69YxRT2mM1yqT6gwY2wnXvxkSpbzu5mRJY3+qiH+h6jIWJzJqSNm8V/U6TKyWFM4t3XePaOBDalhtCgz1XLL7j8IP1fGw+m00nmyagGjOwYgJ/pKr+B54hhM= 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=i7/urD58TgW9UOX48RoY8M2f0yC9Ik0zq4dOzinpvZwbnHolfcE6DKL0U0wAFyFVyheUTFYrWrEiuCcnKh98+2T4hsUr/b46FHtM8Yvvdy0yunoMBacQl9uwtlWGII2fJvrazislXjSC4wBS1i14HC1fsOZj8eAZ6jsx9Ffh3fU= Received: by 10.78.200.20 with SMTP id x20mr753619huf.1185544073243; Fri, 27 Jul 2007 06:47:53 -0700 (PDT) Received: by 10.78.97.18 with HTTP; Fri, 27 Jul 2007 06:47:53 -0700 (PDT) Message-ID: <3bbf2fe10707270647k434116a2tad4a54a0d71567e5@mail.gmail.com> Date: Fri, 27 Jul 2007 15:47:53 +0200 From: "Attilio Rao" Sender: asmrookie@gmail.com To: "Peter Wemm" In-Reply-To: <46A9C437.1080504@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070721174631.S561@10.0.0.1> <20070722114846.GA97996@rulez.sk> <20070722121631.GA8336@rulez.sk> <200707261750.19994.peter@wemm.org> <46A9C437.1080504@FreeBSD.org> X-Google-Sender-Auth: cfe9b4dac49e34a4 Cc: Milos Vyletel , current@freebsd.org Subject: Re: ULE status, invalid load, buildkernel 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: Fri, 27 Jul 2007 13:47:56 -0000 2007/7/27, Attilio Rao : > Peter Wemm wrote: > > On Sunday 22 July 2007, Milos Vyletel wrote: > >> On Sun, Jul 22, 2007 at 01:48:46PM +0200, Milos Vyletel wrote: > > [...] > >>> No problem, > >>> > >>> I've extracted it and made a patch. If someone is intrested, it's > >>> on > >>> > >>> http://rulez.sk/~mv/cpu.patch > >> Well, i've just updated my kernel and it paniced right after > >> identifying cpu. > >> > >> CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ (2205.01-MHz > >> K8-class CPU) Origin = "AuthenticAMD" Id = 0x20f32 Stepping = 2 > >> > >> Features=0x178bfbff >> PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT> > >> Features2=0x1 > >> AMD Features=0xe2500800 > >> AMD Features2=0x3 > >> Cores per package: 2 > >> usable memory = 3211776000 (3062 MB) > >> avail memory = 3105628160 (2961 MB) > >> kernel trap 12 with interrupts disabled > >> > >> > >> Fatal trap 12: page fault while in kernel mode > >> cpuid = 0; apic id = 00 > >> fault virtual address = 0x310 > >> fault code = supervisor read data, page not present > >> instruction pointer = 0x8:0xffffffff8033953c > >> stack pointer = 0x10:0xffffffff80855c70 > >> frame pointer = 0x10:0xffffffff80855c80 > >> code segment = base 0x0, limit 0xfffff, type 0x1b > >> = DPL 0, pres 1, long 1, def32 0, gran 1 > >> processor eflags = resume, IOPL = 0 > >> current process = 0 () > >> > >> this is output from from dmesg. > >> > >> Thanks for suggestions. > >> Milos > > > > Unfortunately this isn't much help. What would be useful would be to > > get a backtrace. If you're not running GENERIC, a copy of your kernel > > config would be useful. Any other patches? > > The patch is not going to work as the slot for SI_ORDER_SECOND was > alredy held by kern/subr_smp.c::mp_start() function. > > Could you please try this comprehensive patch? > It has a fix for the mp_start / lapic_init confusion and some tricks > with CNXT-ID bit which should exactly identify HTT: > http://people.freebsd.org/~attilio/machdep_lapic.diff > > I have still to stress test it, so please use caution. I will update > soon if I will have more information (a 'work for me' / 'don't work for > me' would be very appreciated though). For what can I see it works for me and for 2 users which alredy tested it (which were experiencing problems recently). Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Fri Jul 27 13:48:41 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 7139016A419; Fri, 27 Jul 2007 13:48:41 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 5A83D13C458; Fri, 27 Jul 2007 13:48:41 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from rot26.obsecurity.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id 90E1F1A4D7C; Fri, 27 Jul 2007 06:48:36 -0700 (PDT) Received: by rot26.obsecurity.org (Postfix, from userid 1001) id B9EB9BB74; Fri, 27 Jul 2007 09:48:40 -0400 (EDT) Date: Fri, 27 Jul 2007 09:48:40 -0400 From: Kris Kennaway To: Attilio Rao Message-ID: <20070727134840.GA7305@rot26.obsecurity.org> References: <20070721174631.S561@10.0.0.1> <20070722114846.GA97996@rulez.sk> <20070722121631.GA8336@rulez.sk> <200707261750.19994.peter@wemm.org> <46A9C437.1080504@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="opJtzjQTFsWo+cga" Content-Disposition: inline In-Reply-To: <46A9C437.1080504@FreeBSD.org> User-Agent: Mutt/1.4.2.3i Cc: Milos Vyletel , current@freebsd.org, Peter Wemm Subject: Re: ULE status, invalid load, buildkernel 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: Fri, 27 Jul 2007 13:48:41 -0000 --opJtzjQTFsWo+cga Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jul 27, 2007 at 12:08:55PM +0200, Attilio Rao wrote: > The patch is not going to work as the slot for SI_ORDER_SECOND was=20 > alredy held by kern/subr_smp.c::mp_start() function. >=20 > Could you please try this comprehensive patch? > It has a fix for the mp_start / lapic_init confusion and some tricks=20 > with CNXT-ID bit which should exactly identify HTT: > http://people.freebsd.org/~attilio/machdep_lapic.diff >=20 > I have still to stress test it, so please use caution. I will update=20 > soon if I will have more information (a 'work for me' / 'don't work for= =20 > me' would be very appreciated though). This works for me on three systems: A real HTT system (kern.sched.topology is correctly set to 1) A dual core amd64 system (previously mis-probed as HTT, now correctly not) A quad core intel system (not previously mis-probed as HTT, but broken with Peter's patch). Kris --opJtzjQTFsWo+cga Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFGqfe4Wry0BWjoQKURAj+dAKC87LSt6to+/M4H0LNDemoXLL8J5gCg45me 2KRL/XEi7aKNdFWmwmVBK3c= =DPuL -----END PGP SIGNATURE----- --opJtzjQTFsWo+cga-- From owner-freebsd-current@FreeBSD.ORG Fri Jul 27 14:06:40 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 4EDBF16A418 for ; Fri, 27 Jul 2007 14:06:40 +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 0E88613C46E for ; Fri, 27 Jul 2007 14:06:40 +0000 (UTC) (envelope-from mv@rulez.sk) Received: from localhost (localhost [127.0.0.1]) by mail.rulez.sk (Postfix) with ESMTP id 5A9BC5C3F; Fri, 27 Jul 2007 16:06:39 +0200 (CEST) X-Virus-Scanned: by amavisd-new at mail.rulez.sk Received: by mail.rulez.sk (Postfix, from userid 1020) id 5A0C55C34; Fri, 27 Jul 2007 16:06:36 +0200 (CEST) Date: Fri, 27 Jul 2007 16:06:36 +0200 From: Milos Vyletel To: Attilio Rao Message-ID: <20070727140636.GA69135@rulez.sk> References: <20070721174631.S561@10.0.0.1> <20070722114846.GA97996@rulez.sk> <20070722121631.GA8336@rulez.sk> <200707261750.19994.peter@wemm.org> <46A9C437.1080504@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46A9C437.1080504@FreeBSD.org> User-Agent: Mutt/1.4.2.2i Cc: current@freebsd.org Subject: Re: ULE status, invalid load, buildkernel 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: Fri, 27 Jul 2007 14:06:40 -0000 On Fri, Jul 27, 2007 at 12:08:55PM +0200, Attilio Rao wrote: > The patch is not going to work as the slot for SI_ORDER_SECOND was > alredy held by kern/subr_smp.c::mp_start() function. > > Could you please try this comprehensive patch? > It has a fix for the mp_start / lapic_init confusion and some tricks > with CNXT-ID bit which should exactly identify HTT: > http://people.freebsd.org/~attilio/machdep_lapic.diff > > I have still to stress test it, so please use caution. I will update > soon if I will have more information (a 'work for me' / 'don't work for > me' would be very appreciated though). > kernel with your patch booted fine and my Athlon X2 was corretly identified, thanks mv From owner-freebsd-current@FreeBSD.ORG Fri Jul 27 14:28: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 E5ADF16A496; Fri, 27 Jul 2007 14:28:46 +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 8830613C48D; Fri, 27 Jul 2007 14:28:46 +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 4BD1149603; Fri, 27 Jul 2007 10:28:45 -0400 (EDT) Date: Fri, 27 Jul 2007 15:28:45 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: current@FreeBSD.org In-Reply-To: <20070725110221.C83919@fledge.watson.org> Message-ID: <20070727152647.T46637@fledge.watson.org> References: <20070725110221.C83919@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: kris@FreeBSD.org, csjp@FreeBSD.org Subject: Re: Removing NET_NEEDS_GIANT: first 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: Fri, 27 Jul 2007 14:28:47 -0000 On Wed, 25 Jul 2007, Robert Watson wrote: > Things this patch doesn't do: > > - Address the WITNESS lock order warnings generated when credential rules > are > used with ipfw/pf. These are believed to be annoying but non-harmful, as > deadlocks are no longer reported. This view may be revised if evidence to > the contrary is presented. Kris managed to find a report that one of the post-6.0 hangs involved DIVERT sockets, and sure enough, there is a call to ip_output() without an inpcb pointer, which could cause problems. The attached patch may fix this and another recursion-ish issue involving directly invoking ip_input() rather than indirectly via the netisr. If users of IPDIVERT could give this patch a try and make sure breaks, it could be this resolves the reported issues. Regardless of whether it fixes things, it should probably be committed anyway. Robert N M Watson Computer Laboratory University of Cambridge Index: ip_divert.c =================================================================== RCS file: /data/fbsd-cvs/ncvs/src/sys/netinet/ip_divert.c,v retrieving revision 1.128 diff -u -r1.128 ip_divert.c --- ip_divert.c 11 May 2007 10:20:50 -0000 1.128 +++ ip_divert.c 27 Jul 2007 14:25:09 -0000 @@ -61,6 +61,7 @@ #include #include +#include #include #include @@ -378,7 +379,7 @@ ((so->so_options & SO_DONTROUTE) ? IP_ROUTETOIF : 0) | IP_ALLOWBROADCAST | IP_RAWOUTPUT, - inp->inp_moptions, NULL); + inp->inp_moptions, inp); } INP_UNLOCK(inp); INP_INFO_WUNLOCK(&divcbinfo); @@ -407,7 +408,7 @@ SOCK_UNLOCK(so); #endif /* Send packet to input processing */ - ip_input(m); + netisr_queue(NETISR_IP, m); } return error; From owner-freebsd-current@FreeBSD.ORG Fri Jul 27 14:53: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 B952A16A418 for ; Fri, 27 Jul 2007 14:53:06 +0000 (UTC) (envelope-from qpadla@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 4193F13C4F5 for ; Fri, 27 Jul 2007 14:53:06 +0000 (UTC) (envelope-from qpadla@gmail.com) Received: by ug-out-1314.google.com with SMTP id o4so802880uge for ; Fri, 27 Jul 2007 07:53:05 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:from:to:subject:date:user-agent:mime-version:content-type:content-transfer-encoding:message-id; b=BHI7umunxNjp6AoP50zP40FwUyNsHcoTuLMGmPKrxmhuvtgGIa+BbBUQGUxwaVxSlA5l+uF0wen9mbTTOKP5sSDKcE8kMQU3c18/zBX1lEwQQRzcLQiTkEjfA3or/HSDvXqUb0b7HG5aFZjdkVyfvGVLDXnNpaUt5swomFJjDkw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:from:to:subject:date:user-agent:mime-version:content-type:content-transfer-encoding:message-id; b=UNOEMlTCjrM4cvnPlU/Qtkr625F9K7Ca3YamHp846WsZm9ub43bVqLPtjNju4H5EbTXmMR+lvMNvW9FWvS/qavlnDF83FjG4JHw5c3P2P6QXjrCEqHkAa/IC8AFV2qDhl6nWhNz9jxP/ebsdD7wHw0y2p+eVQFzbie6PO/nRveo= Received: by 10.86.73.17 with SMTP id v17mr2024436fga.1185546359497; Fri, 27 Jul 2007 07:25:59 -0700 (PDT) Received: from 77-109-34-163.dynamic.peoplenet.ua ( [77.109.34.163]) by mx.google.com with ESMTPS id k9sm841225nfh.2007.07.27.07.25.56 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 27 Jul 2007 07:25:57 -0700 (PDT) From: Nikolay Pavlov To: freebsd-current@freebsd.org Date: Fri, 27 Jul 2007 17:25:49 +0300 User-Agent: KMail/1.9.7 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3168633.KlXZWp1Ncd"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200707271725.59268.qpadla@gmail.com> Subject: ULE on UP system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2007 14:53:06 -0000 --nextPart3168633.KlXZWp1Ncd Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hello all. I want to share a simple benchmark results with ULE and recent=20 CURRENT (26.07) on plain UP system (Dell Inspiron 1300, Celeron M and 1GB=20 RAM) GENERIC-UP-4BSD: /usr/bin/time make buildkernel -j3 1177,43s user 289,52s system 92% cpu=20 26:30,77 total GENERIC-UP-ULE: /usr/bin/time make buildkernel -j3 1191,46s user 295,36s system 91% cpu=20 27:10,66 total GENERIC-SMP-4BSD: /usr/bin/time make buildkernel -j3 1175,74s user 324,88s system 93% cpu=20 26:52,64 total GENERIC-SMP-ULE: /usr/bin/time make buildkernel -j3 1183,45s user 327,63s system 92% cpu=20 27:07,54 total Good to know that plain UP system is not bitten by new technology :) Thanks for all.=20 =2D-=20 =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 =2D Best regards, Nikolay Pavlov. <<<----------------------------- =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 --nextPart3168633.KlXZWp1Ncd Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBGqgB3/2R6KvEYGaIRAureAKDbepPKQmtLnXN2zYZ2OKPBEg+SZQCfU13F Mibgpu8QhXShlVYLTAEp19s= =xCzr -----END PGP SIGNATURE----- --nextPart3168633.KlXZWp1Ncd-- From owner-freebsd-current@FreeBSD.ORG Fri Jul 27 16:01:04 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 ED8E516A47B for ; Fri, 27 Jul 2007 16:01:04 +0000 (UTC) (envelope-from rink@thunderstone.rink.nu) Received: from mx1.rink.nu (thunderstone.rink.nu [80.112.228.34]) by mx1.freebsd.org (Postfix) with ESMTP id A805613C480 for ; Fri, 27 Jul 2007 16:01:04 +0000 (UTC) (envelope-from rink@thunderstone.rink.nu) Received: from localhost (localhost [127.0.0.1]) by mx1.rink.nu (Postfix) with ESMTP id BA59C6D458 for ; Fri, 27 Jul 2007 17:41:33 +0200 (CEST) X-Virus-Scanned: amavisd-new at rink.nu Received: from mx1.rink.nu ([127.0.0.1]) by localhost (thunderstone.rink.nu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VLHdJRIdVw20 for ; Fri, 27 Jul 2007 17:41:29 +0200 (CEST) Received: from thunderstone.rink.nu (localhost [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.rink.nu (Postfix) with ESMTP id EED046D457 for ; Fri, 27 Jul 2007 17:41:28 +0200 (CEST) Received: (from rink@localhost) by thunderstone.rink.nu (8.13.8/8.13.8/Submit) id l6RFfSZr003642 for current@FreeBSD.org; Fri, 27 Jul 2007 17:41:28 +0200 (CEST) (envelope-from rink) Date: Fri, 27 Jul 2007 17:41:28 +0200 From: Rink Springer To: current@FreeBSD.org Message-ID: <20070727154128.GA3093@rink.nu> 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: Extremely high interrupt count / load on recent 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, 27 Jul 2007 16:01:05 -0000 Hi everyone, Since my last csup, I'm encountering very high interrupt counts (and thus, a high associated interrupt load) on my workstation. vmstat -i reports: interrupt total rate irq1: atkbd0 26087 1 irq14: ata0 58 0 irq16: emu10kx0 1051388503 78968 irq17: nvidia0+ 1189799 89 irq20: ohci0 16596 1 irq21: ehci0 1 0 irq22: atapci1 1387849 104 irq23: atapci2 905538 68 irq24: arcmsr0 176404 13 irq27: isp0 85 0 irq28: bge0 37642180 2827 cpu0: timer 26627670 1999 cpu1: timer 26595670 1997 Total 1145956440 86071 The problem is, when I remove the snd_emu10kx driver (I load it as a module in loader(8)), then irq28: bge0 starts to exhibit the same pattern, generating thousands of interrupts. My kernel is GENERIC + ULE - WITNESS, but the problem also occured using plain GENERIC. dmesg is available at http://rink.nu/tmp/dmesg-pitchfork.txt Can anyone help me track this down? Regards, -- Rink P.W. Springer - http://rink.nu "root is always right" -- the kernel From owner-freebsd-current@FreeBSD.ORG Fri Jul 27 16:28:27 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 1258C16A41A for ; Fri, 27 Jul 2007 16:28:27 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) Received: from mail.ambrisko.com (mail.ambrisko.com [64.174.51.43]) by mx1.freebsd.org (Postfix) with ESMTP id DA5A313C459 for ; Fri, 27 Jul 2007 16:28:26 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) Received: from server2.ambrisko.com (HELO www.ambrisko.com) ([192.168.1.2]) by ironport2.ambrisko.com with ESMTP; 27 Jul 2007 09:23:23 -0700 Received: from ambrisko.com (localhost [127.0.0.1]) by www.ambrisko.com (8.14.1/8.12.11) with ESMTP id l6RGUJra088705; Fri, 27 Jul 2007 09:30:19 -0700 (PDT) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.14.1/8.13.1/Submit) id l6RGUIZd088700; Fri, 27 Jul 2007 09:30:18 -0700 (PDT) (envelope-from ambrisko) From: Doug Ambrisko Message-Id: <200707271630.l6RGUIZd088700@ambrisko.com> In-Reply-To: <86abti2p42.fsf@ds4.des.no> To: =?UTF-8?Q?Dag-Erling_Sm=C3=B8rgrav?= Date: Fri, 27 Jul 2007 09:30:18 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL94b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Cc: Takeharu KATO , freebsd-current@freebsd.org, Mike Tancsa Subject: Re: ichwd for ICH8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Jul 2007 16:28:27 -0000 Dag-Erling Sm\xc3\xb8rgrav writes: | Doug Ambrisko writes: | > Atleast with older ICH chips the TCO reset can be disabled in hardware | > with a pull-up or pull-down resistor (I forget which) on one of the | > PC speaker lines. | | Yes, but the driver detects that and refuses to attach. Okay, that doesn't mean that you can't try to remove the pull-up resistor or use a stronger pull-down resistor on the speaker output pins. Hopefully the MB has a speaker header. Grounding the output of the speaker might work in a pinch. It needs to be done during power on and probably reset. Doug A. From owner-freebsd-current@FreeBSD.ORG Fri Jul 27 17:18: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 D5BB416A417 for ; Fri, 27 Jul 2007 17:18:36 +0000 (UTC) (envelope-from maksim.yevmenkin@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 60AAC13C4B0 for ; Fri, 27 Jul 2007 17:18:36 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by ug-out-1314.google.com with SMTP id o4so826670uge for ; Fri, 27 Jul 2007 10:18: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=YNe3zBDMtqoBMCpL0V/RJDz3kYbhbTtDUMbuK+A5WRETkgSbxgX7VnzM2m/HEeVfwo0IFYWlUMZd80cfbUN27wK9hXMh31y48xresbuSepmNKHSpdxivm0biYFETo/0qa7N1G1mr46RZyyJlNPyWVRHJtCB8npREduSOOfBKXug= 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=WeVbPurNVO4l0y5c8ZzfxAN5e2VHqeliLBN4Soei8Js5XMuBDmvddYk27gwVo1Z8m5jehEa4B8zDLCRgY1tgJBRmme2lIujdV2o52hpEttpvxyiAUwWjFGk45gbcMgyiWsABnomRJXnBXPtPey7QQxTciP6+buiOouJuBDR6ESY= Received: by 10.86.100.7 with SMTP id x7mr2128170fgb.1185556715055; Fri, 27 Jul 2007 10:18:35 -0700 (PDT) Received: by 10.86.31.8 with HTTP; Fri, 27 Jul 2007 10:18:35 -0700 (PDT) Message-ID: Date: Fri, 27 Jul 2007 10:18:35 -0700 From: "Maksim Yevmenkin" To: "Dmitry Morozovsky" In-Reply-To: <20070727141421.H42349@woozle.rinet.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070727141421.H42349@woozle.rinet.ru> Cc: current@freebsd.org Subject: Re: possible showstopper: kbdmux hangs -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, 27 Jul 2007 17:18:36 -0000 On 7/27/07, Dmitry Morozovsky wrote: > Hi there, > > on some of my mobos -current hangs early (when starning init) if kbdmux is > included in kernel (both on i386 and amd64); this seems to be some race, as > hangs are not 100% reproducible. What info should I provide to debug? the usual suspects are 1) while (KBDMUX_CHECK_CHAR(kbd)) { ... } loop in kbdmux_kbd_event(). could you please try to put some debug printf's into it and make sure it does not stuck there. 2) callout. kbdmux callout initialized as non mp-safe to make sure giant is held. 3) task queue. kbdmux(4) uses taskqueue_swi_giant. you might want to try uncomment section at line 81 in kbdmux.c. this should add private lock for kbdmux(4). not sure it will work though - many things has changed since i tried it. > I'm using only PS2 keyboards, and have no other format keyboards handy; > however, I can obtain USB keyb if needed. are you using ps/2 mouse? if so, try to disconnect it and see if this helps. as you said, you could try to use usb keyboard instead of ps/2. thanks, max From owner-freebsd-current@FreeBSD.ORG Fri Jul 27 17:38: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 B75DD16A41F for ; Fri, 27 Jul 2007 17:38:01 +0000 (UTC) (envelope-from csjp@sub.vaned.net) Received: from sub.vaned.net (sub.vaned.net [205.200.235.40]) by mx1.freebsd.org (Postfix) with ESMTP id 8173F13C4A6 for ; Fri, 27 Jul 2007 17:38:01 +0000 (UTC) (envelope-from csjp@sub.vaned.net) Received: by sub.vaned.net (Postfix, from userid 1001) id A8C165C36; Fri, 27 Jul 2007 12:20:53 -0500 (CDT) Date: Fri, 27 Jul 2007 12:20:53 -0500 From: "Christian S.J. Peron" To: Christian Peron Message-ID: <20070727172053.GA49562@sub> References: <12A5576E06117043AB644E4A998703B7C1F877@Exc01.seccuris.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <12A5576E06117043AB644E4A998703B7C1F877@Exc01.seccuris.local> User-Agent: Mutt/1.4.2.2i Cc: current@freebsd.org Subject: Re: Removing NET_NEEDS_GIANT: first 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: Fri, 27 Jul 2007 17:38:01 -0000 Robert, Just thought of a couple things: [..] > > Index: ip_divert.c > =================================================================== > RCS file: /data/fbsd-cvs/ncvs/src/sys/netinet/ip_divert.c,v > retrieving revision 1.128 > diff -u -r1.128 ip_divert.c > --- ip_divert.c 11 May 2007 10:20:50 -0000 1.128 > +++ ip_divert.c 27 Jul 2007 14:25:09 -0000 > @@ -61,6 +61,7 @@ > #include > > #include > +#include > #include > > #include > @@ -378,7 +379,7 @@ > ((so->so_options & SO_DONTROUTE) ? > IP_ROUTETOIF : 0) | > IP_ALLOWBROADCAST | IP_RAWOUTPUT, > - inp->inp_moptions, NULL); > + inp->inp_moptions, inp); Here we are passing the inp associated with the divert socket. I am not sure how accurate this is, since it's quite possible that the packet could belong to another TCP/UDP socket owned by a completely different user and socket for that matter. This will result in the firewalls attributing the packet to the user of whoever created the divert socket (probably root), instead of attributing the packet to the subject who created the original TCP/UDP socket. -- Christian S.J. Peron csjp@FreeBSD.ORG FreeBSD Committer From owner-freebsd-current@FreeBSD.ORG Fri Jul 27 17:50: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 BC81416A46B for ; Fri, 27 Jul 2007 17:50:25 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 5AC8C13C491 for ; Fri, 27 Jul 2007 17:50:25 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id B7857208D; Fri, 27 Jul 2007 19:50:21 +0200 (CEST) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: 0.0/3.0 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on tim.des.no Received: from ds4.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id 985E8208C; Fri, 27 Jul 2007 19:50:21 +0200 (CEST) Received: by ds4.des.no (Postfix, from userid 1001) id 7FF0084461; Fri, 27 Jul 2007 19:50:21 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Doug Ambrisko References: <200707271630.l6RGUIZd088700@ambrisko.com> Date: Fri, 27 Jul 2007 19:50:21 +0200 In-Reply-To: <200707271630.l6RGUIZd088700@ambrisko.com> (Doug Ambrisko's message of "Fri\, 27 Jul 2007 09\:30\:18 -0700 \(PDT\)") Message-ID: <861wet3fdu.fsf@ds4.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Takeharu KATO , freebsd-current@freebsd.org, Mike Tancsa Subject: Re: ichwd for ICH8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Jul 2007 17:50:25 -0000 Doug Ambrisko writes: > Dag-Erling Sm\xc3\xb8rgrav writes: > | Doug Ambrisko writes: > | > Atleast with older ICH chips the TCO reset can be disabled in hardware > | > with a pull-up or pull-down resistor (I forget which) on one of the > | > PC speaker lines. > | Yes, but the driver detects that and refuses to attach. > Okay, that doesn't mean that you can't try to remove the pull-up > resistor or use a stronger pull-down resistor on the speaker > output pins. Hopefully the MB has a speaker header. Grounding the > output of the speaker might work in a pinch. It needs to be > done during power on and probably reset. What for? If the SPKR line is high during reset, the watchdog timer is disabled and the NO_REBOOT bit is immutable. The driver detects that and refuses to attach. This is not the case on Mike's hardware. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Fri Jul 27 17:51:34 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 623CE16A41B; Fri, 27 Jul 2007 17:51:34 +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 2EC2813C4E5; Fri, 27 Jul 2007 17:51: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 92F2E49AB6; Fri, 27 Jul 2007 13:51:33 -0400 (EDT) Date: Fri, 27 Jul 2007 18:51:33 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: "Christian S.J. Peron" In-Reply-To: <20070727172053.GA49562@sub> Message-ID: <20070727184958.K72112@fledge.watson.org> References: <12A5576E06117043AB644E4A998703B7C1F877@Exc01.seccuris.local> <20070727172053.GA49562@sub> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: current@freebsd.org Subject: Re: Removing NET_NEEDS_GIANT: first 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: Fri, 27 Jul 2007 17:51:34 -0000 On Fri, 27 Jul 2007, Christian S.J. Peron wrote: >> Index: ip_divert.c >> =================================================================== >> RCS file: /data/fbsd-cvs/ncvs/src/sys/netinet/ip_divert.c,v >> retrieving revision 1.128 >> diff -u -r1.128 ip_divert.c >> --- ip_divert.c 11 May 2007 10:20:50 -0000 1.128 >> +++ ip_divert.c 27 Jul 2007 14:25:09 -0000 >> @@ -61,6 +61,7 @@ >> #include >> >> #include >> +#include >> #include >> >> #include >> @@ -378,7 +379,7 @@ >> ((so->so_options & SO_DONTROUTE) ? >> IP_ROUTETOIF : 0) | >> IP_ALLOWBROADCAST | IP_RAWOUTPUT, >> - inp->inp_moptions, NULL); >> + inp->inp_moptions, inp); > > Here we are passing the inp associated with the divert socket. I am not > sure how accurate this is, since it's quite possible that the packet could > belong to another TCP/UDP socket owned by a completely different user and > socket for that matter. > > This will result in the firewalls attributing the packet to the user of > whoever created the divert socket (probably root), instead of attributing > the packet to the subject who created the original TCP/UDP socket. Hmm, you are, of course, entirely right. This would fix the locking problem but lead to incorrect results in processing. The right fix here may be to arrange to drop all the locks, which means doing an m_dup of the options, before calling ip_output(), which would allow ip_output() to acquire whatever locks it needs. I wonder if we have some similar issues with raw ICMP sockets? Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Fri Jul 27 18:02: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 6429116A41F; Fri, 27 Jul 2007 18:02:02 +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 EB59813C48D; Fri, 27 Jul 2007 18:02:01 +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 l6RI0qpS038056; Fri, 27 Jul 2007 12:00:52 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Fri, 27 Jul 2007 12:00:54 -0600 (MDT) Message-Id: <20070727.120054.-233668205.imp@bsdimp.com> To: rwatson@freebsd.org From: "M. Warner Losh" In-Reply-To: <20070727143039.G46637@fledge.watson.org> References: <20070727134047.O46637@fledge.watson.org> <20070727130613.GE41151@heechee.tobez.org> <20070727143039.G46637@fledge.watson.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]); Fri, 27 Jul 2007 12:00:53 -0600 (MDT) Cc: current@freebsd.org Subject: Re: Thanks for all the work on the MPSAFE network stack project X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Jul 2007 18:02:02 -0000 In message: <20070727143039.G46637@fledge.watson.org> Robert Watson writes: : On Fri, 27 Jul 2007, Anton Berezin wrote: : : > On Fri, Jul 27, 2007 at 01:46:52PM +0100, Robert Watson wrote: : > : >> Thanks again to everyone involved in this multi-year project to make our : >> network stack fully parallel. It has been a huge project, and the number : >> of people who've worked on it is sufficiently long as to be not easily : >> captured. I would like to acknowledge everyone involved, and apologize for : >> missed names. The following FreeBSD developers and other individuals have : >> all made significant contributions to this work, and deserve many thanks: : > : >> John Baldwin, John Birrell, Antoine Brodin, Jake Burkholder, Alan Cox, : >> Brooks Davis, Pawel Dawidek, Matthew Dillon, Tor Egge, Julian Elischer, : >> Ruslan Ermilov, Bruce Evans, Don Lewis, Brian Feldman, Andrew Gallatin, : >> John-Mark Gurney, Paul Holes, Peter Holm, Jeffrey Hsu, Kris Kennaway, Maxim : >> Konovalov, Joseph Koshy, Wojciech Koszek, Roman Kurakin, Max Laier, Nate : >> Lawson, Sam Leffler, Jonathan Lemon, Warner Losh, Don Lewis, Qing Li, Scott : >> Long, Warner Losh, Kip Macy, Rick Macklem, Ed Maste, Bosko Milekic, Marcel : >> Moolenaar, George Neville-Neil, Andre Oppermann, Chuck Paterson, Bill Paul, : >> Alfred Perlstein, Paolo Pisati, Attilio Rao, Luigi Rizzo, Jeff Roberson, : >> Paul Saab, Hidetoshi Shimokawa, Mike Silberback, Bruce Simpson, Gleb : >> Smirnoff, Dag-Erling Smorgrav, Mohan Srinivasan, Randall Stewart, Marius : >> Strobl, Mike Tancsa, Seigo Tanimura, JINMEI Tatuya, Andrew Thompson, Hajimu : >> UMEMOTO, Stephan Uphoff, Peter Wemm, David Xu, Jennifer Yang, Maksim : >> Yevmenkin, Pyun YongHyeon, and Bjoern Zeeb. : > : > So, Don Lewis and Warner Losh get twice the thanks? :-) : > : > Seriously though, thank you all guys for your hard work! : : Christian Peron and Alexander Motin also got left out, so there is some : balance in the universe :-). And I think Matt Dodd may be missing too, he locked the ep driver, and maybe others. I also think that Mitsuru Iwasaki-san did some early locking work that I committed on his behalf way back when (but the specific drivers escape my memory and my grep foo isn't up to discovering the answer). I also think that Takanori Watanabe-san and Nate Lawson fixed some ACPI related locking issues that were exposed by some network driver that I was locking, but since I lost all email from 2001-2005, I can't go back into my archives to check. And I think that some chap by the name of Robert Watson did a little work, but maybe his modesty prevents him from thanking himself. Warner From owner-freebsd-current@FreeBSD.ORG Fri Jul 27 18:10:26 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 2281B16A41F for ; Fri, 27 Jul 2007 18:10:26 +0000 (UTC) (envelope-from iaccounts@ibctech.ca) Received: from pearl.ibctech.ca (pearl.ibctech.ca [208.70.104.210]) by mx1.freebsd.org (Postfix) with ESMTP id B0AD813C45A for ; Fri, 27 Jul 2007 18:10:25 +0000 (UTC) (envelope-from iaccounts@ibctech.ca) Received: (qmail 61884 invoked by uid 1002); 27 Jul 2007 17:43:45 -0000 Received: from iaccounts@ibctech.ca by pearl.ibctech.ca by uid 89 with qmail-scanner-1.22 (spamassassin: 2.64. Clear:RC:1(208.70.104.100):. Processed in 6.28211 secs); 27 Jul 2007 17:43:45 -0000 Received: from unknown (HELO ?192.168.30.110?) (steve@ibctech.ca@208.70.104.100) by pearl.ibctech.ca with (DHE-RSA-AES256-SHA encrypted) SMTP; 27 Jul 2007 17:43:38 -0000 Message-ID: <46AA2ED3.6050702@ibctech.ca> Date: Fri, 27 Jul 2007 13:43:47 -0400 From: Steve Bertrand User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: freebsd-current@freebsd.org X-Enigmail-Version: 0.95.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: IP header question X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2007 18:10:26 -0000 First of all, sorry for being off topic here, but I know there are many people in this list that know the network stack inside and out. I have (hopefully) a couple very easy questions: When the term 'header stripping' is used as a packet is passed up the stack, what really happens? I don't understand how if a layers header is 'stripped off' as it goes up, it will know where to be sent to as it goes back down. Does 'stripping' mean simply reading it on the way up (but not discarding)? If so, when does the src/dst info for layer-3 and layer-2 get reversed, on the way up, or the way back down? If not, how does each layer know what destination information to insert into the headers for the trip back to the source? Thanks very much for any insight. Steve From owner-freebsd-current@FreeBSD.ORG Fri Jul 27 19:02: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 B542116A419 for ; Fri, 27 Jul 2007 19:02:29 +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 5F20013C461 for ; Fri, 27 Jul 2007 19:02:29 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.samsco.home (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.8/8.13.8) with ESMTP id l6RJ2PxJ031825; Fri, 27 Jul 2007 13:02:25 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <46AA4138.6090509@samsco.org> Date: Fri, 27 Jul 2007 13:02:16 -0600 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: Rink Springer References: <20070727154128.GA3093@rink.nu> In-Reply-To: <20070727154128.GA3093@rink.nu> 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]); Fri, 27 Jul 2007 13:02:25 -0600 (MDT) X-Spam-Status: No, score=-1.4 required=5.5 tests=ALL_TRUSTED autolearn=failed version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: current@freebsd.org Subject: Re: Extremely high interrupt count / load on recent 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, 27 Jul 2007 19:02:29 -0000 Can you try removing drivers one at time until it goes away? Also, what kind of machine is this? Scott Rink Springer wrote: > Hi everyone, > > Since my last csup, I'm encountering very high interrupt counts (and > thus, a high associated interrupt load) on my workstation. > > vmstat -i reports: > > interrupt total rate > irq1: atkbd0 26087 1 > irq14: ata0 58 0 > irq16: emu10kx0 1051388503 78968 > irq17: nvidia0+ 1189799 89 > irq20: ohci0 16596 1 > irq21: ehci0 1 0 > irq22: atapci1 1387849 104 > irq23: atapci2 905538 68 > irq24: arcmsr0 176404 13 > irq27: isp0 85 0 > irq28: bge0 37642180 2827 > cpu0: timer 26627670 1999 > cpu1: timer 26595670 1997 > Total 1145956440 86071 > > The problem is, when I remove the snd_emu10kx driver (I load it as a > module in loader(8)), then irq28: bge0 starts to exhibit the same > pattern, generating thousands of interrupts. > > My kernel is GENERIC + ULE - WITNESS, but the problem also > occured using plain GENERIC. dmesg is available at > http://rink.nu/tmp/dmesg-pitchfork.txt > > Can anyone help me track this down? > > Regards, > From owner-freebsd-current@FreeBSD.ORG Fri Jul 27 19:04:57 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 E399816A41F for ; Fri, 27 Jul 2007 19:04:57 +0000 (UTC) (envelope-from maksim.yevmenkin@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 6CA7C13C459 for ; Fri, 27 Jul 2007 19:04:56 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by ug-out-1314.google.com with SMTP id o4so843028uge for ; Fri, 27 Jul 2007 12:04: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=qv3Y2eyrdBxNxtXh5B6YdzLPL7cRhDnHUHJx5OhdSg//6WCCkpsPi0QoVpqM4JEWdBrUJDJ5ef3aNY2sEWAHSBYzJtFOrywpuy6o500/kO7f+Z8ef3GvUtgB1p4f6W/so/4Pqw23iz1Vs4CtvOd7nuwFCpmxj4+gM7hlXprYcjg= 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=k/u8bS4A+3Yn51LfIMmPEhDnR5fYsM56NJ2idKqV0eYSSVVDokWogUD/i873leS0xjCWi7Rt8zdhMnBStBo41mjnLgpUwkKM7AIEe7K8jkXc2k2NRxwWQj6+qB2v+EI6QPkZh6Ke/S7ETtEpsyNkUmDM6mtMrFk+fovoE/1IFBQ= Received: by 10.86.60.7 with SMTP id i7mr2167583fga.1185563096022; Fri, 27 Jul 2007 12:04:56 -0700 (PDT) Received: by 10.86.31.8 with HTTP; Fri, 27 Jul 2007 12:04:56 -0700 (PDT) Message-ID: Date: Fri, 27 Jul 2007 12:04:56 -0700 From: "Maksim Yevmenkin" To: "Julian Elischer" In-Reply-To: <46A94194.5010207@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <46A94194.5010207@elischer.org> Cc: freebsd-current@freebsd.org Subject: Re: nmdm(4) does not call .l_close X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Jul 2007 19:04:58 -0000 On 7/26/07, Julian Elischer wrote: > Maksim Yevmenkin wrote: > > Dear All, > > > > it seems to me that nmdm(4) is not calling .l_close (i.e. does not > > close whatever line discipline might be installed onto /dev/nmdmXX). > > the problem is easy to reproduce - just open /dev/nmdm0A and install, > > say, ng_tty(4) line discipline onto it. after that, simply close the > > /dev/nmdm0A. in theory, the ng_tty(4) node should disappear when > > device is closed, but it does not. > > when I originally wrote this I copied what the pty code was doing. > This has all been redone since then however. > I'm guessing it should do whatever the pty code is now doing :-) . it looks like pty close calls ttyld_close() before calling tty_close(). so at the very least, imo, nmdm close should call ttyld_close() before tty_close(). ttyclose(), infact, calls ttyld_close() and tt_close(), so it seemed like the right thing to do :) > > the following patch fixes things for me > > > > === > > > > beetle% diff -u nmdm.c.orig nmdm.c > > --- nmdm.c.orig 2006-11-21 16:59:40.000000000 -0800 > > +++ nmdm.c 2007-07-26 17:01:47.000000000 -0700 > > @@ -402,7 +402,7 @@ > > nmdmclose(struct cdev *dev, int flag, int mode, struct thread *td) > > { > > > > - return (tty_close(dev->si_tty)); > > + return (ttyclose(dev, flag, mode, td)); > > sounds believable.. > but I don't really know offhand. nor do i :) hence my question. can someone, with more tty fu, please look at it? > does it work with other disciplines? it does with ng_h4(4). since i cannot make my bluetooth xircom pccard work, i decided to use my old trick - emulate bluetooth device. so i'm testing my patches to make ng_h4(4) mp-safe by installing h4 line discipline onto /dev/nmdm and feeding h4 packets to it. i have not tried other disciplines yet, i.e. ppp and slip, thanks, max From owner-freebsd-current@FreeBSD.ORG Fri Jul 27 19:15: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 E15AC16A418; Fri, 27 Jul 2007 19:15:36 +0000 (UTC) (envelope-from rink@thunderstone.rink.nu) Received: from mx1.rink.nu (thunderstone.rink.nu [80.112.228.34]) by mx1.freebsd.org (Postfix) with ESMTP id 943C213C467; Fri, 27 Jul 2007 19:15:36 +0000 (UTC) (envelope-from rink@thunderstone.rink.nu) Received: from localhost (localhost [127.0.0.1]) by mx1.rink.nu (Postfix) with ESMTP id D8B426D458; Fri, 27 Jul 2007 21:15:34 +0200 (CEST) X-Virus-Scanned: amavisd-new at rink.nu Received: from mx1.rink.nu ([127.0.0.1]) by localhost (thunderstone.rink.nu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LQZ3ZvBxCZhl; Fri, 27 Jul 2007 21:15:30 +0200 (CEST) Received: from thunderstone.rink.nu (localhost [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.rink.nu (Postfix) with ESMTP id 16F3E6D457; Fri, 27 Jul 2007 21:15:30 +0200 (CEST) Received: (from rink@localhost) by thunderstone.rink.nu (8.13.8/8.13.8/Submit) id l6RJFTZr019562; Fri, 27 Jul 2007 21:15:29 +0200 (CEST) (envelope-from rink) Date: Fri, 27 Jul 2007 21:15:29 +0200 From: Rink Springer To: Scott Long Message-ID: <20070727191529.GB3093@rink.nu> References: <20070727154128.GA3093@rink.nu> <46AA4138.6090509@samsco.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46AA4138.6090509@samsco.org> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: Rink Springer , current@freebsd.org Subject: Re: Extremely high interrupt count / load on recent 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, 27 Jul 2007 19:15:37 -0000 On Fri, Jul 27, 2007 at 01:02:16PM -0600, Scott Long wrote: > Can you try removing drivers one at time until it goes away? Also, I'll give this a try later. It's faily easy to reproduce - just use the machine for longer than 1 hour and it'll waste 50% time on interrupts... > what kind of machine is this? This is a 2x Opteron 846 on a Tyan K8SE motherboard, running i386. 2GB RAM. Anything else you need to know? FWIW, the dmesg is available at http://rink.nu/tmp/dmesg-pitchfork.txt Regards, -- Rink P.W. Springer - http://rink.nu "root is always right" -- the kernel > > Scott > > > Rink Springer wrote: > > Hi everyone, > > > > Since my last csup, I'm encountering very high interrupt counts (and > > thus, a high associated interrupt load) on my workstation. > > > > vmstat -i reports: > > > > interrupt total rate > > irq1: atkbd0 26087 1 > > irq14: ata0 58 0 > > irq16: emu10kx0 1051388503 78968 > > irq17: nvidia0+ 1189799 89 > > irq20: ohci0 16596 1 > > irq21: ehci0 1 0 > > irq22: atapci1 1387849 104 > > irq23: atapci2 905538 68 > > irq24: arcmsr0 176404 13 > > irq27: isp0 85 0 > > irq28: bge0 37642180 2827 > > cpu0: timer 26627670 1999 > > cpu1: timer 26595670 1997 > > Total 1145956440 86071 > > > > The problem is, when I remove the snd_emu10kx driver (I load it as a > > module in loader(8)), then irq28: bge0 starts to exhibit the same > > pattern, generating thousands of interrupts. > > > > My kernel is GENERIC + ULE - WITNESS, but the problem also > > occured using plain GENERIC. dmesg is available at > > http://rink.nu/tmp/dmesg-pitchfork.txt > > > > Can anyone help me track this down? > > > > Regards, > > > > _______________________________________________ > 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 27 20:08:28 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 B0ABB16A41A for ; Fri, 27 Jul 2007 20:08:28 +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 634CE13C459 for ; Fri, 27 Jul 2007 20:08:28 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.14.1/8.14.1) id l6RK8Q1b076088; Fri, 27 Jul 2007 15:08:26 -0500 (CDT) (envelope-from dan) Date: Fri, 27 Jul 2007 15:08:26 -0500 From: Dan Nelson To: Thierry Herbelot Message-ID: <20070727200826.GA53337@dan.emsphone.com> References: <200707210657.11159.thierry@herbelot.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200707210657.11159.thierry@herbelot.com> X-OS: FreeBSD 7.0-CURRENT User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-current@freebsd.org Subject: Re: ZFS panic: System call unlink returning with 1 locks held X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Jul 2007 20:08:28 -0000 In the last episode (Jul 21), Thierry Herbelot said: > with a recent -current -built yesterday), I just got a panic while > rebuilding -j4 the world and portupgrading firefox. > > the machine is pretty much memory limited (only 320 MB of RAM), with > two CPUs, running a straight GENERIC kernel, including WITNESS and > INVARIANTS. [..] > 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 I've been seeing this, as late as on a Jul 24 kernel. Happened once during the cleandir stage of a buildworld, and few more times when the system was relatively idle (although it is an mrtg server so lots of files are constantly created and rm'd). My system is i386 with 1GB of RAM, has a ZFS root, and is SMP. I've also gotten a similar "System call rename returning with 1 locks held" panic. Is there any way to find out what lock is being held? I've got a couple crashdumps. (kgdb) (kgdb) #0 doadump () at pcpu.h:195 #1 0xc05e4032 in boot (howto=260) at ../../../kern/kern_shutdown.c:409 #2 0xc05e43b9 in panic (fmt=0xc0845a19 "System call %s returning with %d locks held") at ../../../kern/kern_shutdown.c:563 #3 0xc07c203b in syscall (frame=0xe76dfd38) at ../../../i386/i386/trap.c:1060 #4 0xc07a6a00 in Xint0x80_syscall () at ../../../i386/i386/exception.s:196 -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-current@FreeBSD.ORG Fri Jul 27 20:56: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 0F43516A41B for ; Fri, 27 Jul 2007 20:56:35 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id E25DB13C45A for ; Fri, 27 Jul 2007 20:56:34 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from rot26.obsecurity.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id CDF271A4D7C; Fri, 27 Jul 2007 13:56:28 -0700 (PDT) Received: by rot26.obsecurity.org (Postfix, from userid 1001) id 517F8BE43; Fri, 27 Jul 2007 16:56:34 -0400 (EDT) Date: Fri, 27 Jul 2007 16:56:34 -0400 From: Kris Kennaway To: Dan Nelson Message-ID: <20070727205634.GA49495@rot26.obsecurity.org> References: <200707210657.11159.thierry@herbelot.com> <20070727200826.GA53337@dan.emsphone.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gKMricLos+KVdGMg" Content-Disposition: inline In-Reply-To: <20070727200826.GA53337@dan.emsphone.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org, Thierry Herbelot Subject: Re: ZFS panic: System call unlink returning with 1 locks held X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Jul 2007 20:56:35 -0000 --gKMricLos+KVdGMg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jul 27, 2007 at 03:08:26PM -0500, Dan Nelson wrote: > In the last episode (Jul 21), Thierry Herbelot said: > > with a recent -current -built yesterday), I just got a panic while=20 > > rebuilding -j4 the world and portupgrading firefox. > > > > the machine is pretty much memory limited (only 320 MB of RAM), with > > two CPUs, running a straight GENERIC kernel, including WITNESS and > > INVARIANTS. > [..] > > the panic message is : > >=20 > > panic: System call unlink returning with 1 locks held > > cpuid =3D 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 >=20 > I've been seeing this, as late as on a Jul 24 kernel. Happened once > during the cleandir stage of a buildworld, and few more times when the > system was relatively idle (although it is an mrtg server so lots of > files are constantly created and rm'd). My system is i386 with 1GB of > RAM, has a ZFS root, and is SMP. I've also gotten a similar "System > call rename returning with 1 locks held" panic. Is there any way to > find out what lock is being held? I've got a couple crashdumps. It appears to be a leak in the lock counters somewhere, perhaps related to recursively acquired rwlocks (e.g. double increment, single free). I eventually disabled the check because even adding extensive extra debugging there was no evidence of an actual lock being leaked anywhere. Kris --gKMricLos+KVdGMg Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFGqlwCWry0BWjoQKURAiIJAKDyT8VaNjZoENsFfDDmB5knSDnJzQCePQG0 xdep0ohnwV9NGZ13eqX3OlU= =kjz7 -----END PGP SIGNATURE----- --gKMricLos+KVdGMg-- From owner-freebsd-current@FreeBSD.ORG Fri Jul 27 23:14: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 ACBAF16A418 for ; Fri, 27 Jul 2007 23:14:34 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.181]) by mx1.freebsd.org (Postfix) with ESMTP id 6183C13C491 for ; Fri, 27 Jul 2007 23:14:34 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by py-out-1112.google.com with SMTP id a73so1940339pye for ; Fri, 27 Jul 2007 16:14:33 -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=Y9plWmNTXQcZCjyl/uQDWXnmQjc6+t7cMn2v89No7eh5nqZUmcpvc5VS9CK7S0JgmdiXFdhR+yX/LC42PgsE3JBHQ2VmXI5zeMwBN+be/BWs8bu1WpmH1gGzC20fNahD/Z/rNnmxKrZA6zhg/h84hjn94qs3kPeAlIOZ2PgDCaM= 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=t69H7IrklRoXppAopBx4ABuRv/1m470QM1/KSFB1WVss5T544LR/vH+U2KfatjNM9MbpX6ddi2hOVjXt8NO5KTJaRUDUbMy4pO0op7k8EhjJYV92mTp1KZ4jcbz5c9c9PiKaHLI26YyajCO7atU7J6UqfHqHqLeue0QharbzEJs= Received: by 10.65.59.11 with SMTP id m11mr5867046qbk.1185578073664; Fri, 27 Jul 2007 16:14:33 -0700 (PDT) Received: by 10.65.234.10 with HTTP; Fri, 27 Jul 2007 16:14:33 -0700 (PDT) Message-ID: Date: Fri, 27 Jul 2007 16:14:33 -0700 From: "Maksim Yevmenkin" To: "Julian Elischer" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <46A94194.5010207@elischer.org> Cc: freebsd-current@freebsd.org Subject: Re: nmdm(4) does not call .l_close X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Jul 2007 23:14:34 -0000 On 7/27/07, Maksim Yevmenkin wrote: > On 7/26/07, Julian Elischer wrote: > > Maksim Yevmenkin wrote: > > > Dear All, > > > > > > it seems to me that nmdm(4) is not calling .l_close (i.e. does not > > > close whatever line discipline might be installed onto /dev/nmdmXX). > > > the problem is easy to reproduce - just open /dev/nmdm0A and install, > > > say, ng_tty(4) line discipline onto it. after that, simply close the > > > /dev/nmdm0A. in theory, the ng_tty(4) node should disappear when > > > device is closed, but it does not. > > [...] > i have not tried other disciplines yet, i.e. ppp and slip, ok, i changed the patch to === diff -u nmdm.c.orig nmdm.c --- nmdm.c.orig 2006-11-21 16:59:40.000000000 -0800 +++ nmdm.c 2007-07-27 15:57:50.000000000 -0700 @@ -401,8 +401,13 @@ static int nmdmclose(struct cdev *dev, int flag, int mode, struct thread *td) { + struct tty *tp = dev->si_tty; + int error; - return (tty_close(dev->si_tty)); + error = ttyld_close(tp, flag); + (void) tty_close(tp); + + return (error); } static void === and tried it with h4, ppp and slip line disciplines. it seems to work. since nmdmopen() calls ttyld_open(), nmdmclose(), imo, should call ttyld_close(). any comments? thanks, max From owner-freebsd-current@FreeBSD.ORG Sat Jul 28 03:28: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 C14FC16A417 for ; Sat, 28 Jul 2007 03:28:10 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outF.internet-mail-service.net (outF.internet-mail-service.net [216.240.47.229]) by mx1.freebsd.org (Postfix) with ESMTP id 7239A13C428 for ; Sat, 28 Jul 2007 03:28:10 +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, 27 Jul 2007 20:28:09 -0700 Received: from julian-mac.elischer.org (nat.ironport.com [63.251.108.100]) by idiom.com (Postfix) with ESMTP id 681ED125A2A; Fri, 27 Jul 2007 20:28:09 -0700 (PDT) Message-ID: <46AAB7EF.4020601@elischer.org> Date: Fri, 27 Jul 2007 20:28:47 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.5 (Macintosh/20070716) MIME-Version: 1.0 To: Maksim Yevmenkin References: <46A94194.5010207@elischer.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: nmdm(4) does not call .l_close X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Jul 2007 03:28:10 -0000 Maksim Yevmenkin wrote: > On 7/27/07, Maksim Yevmenkin wrote: >> On 7/26/07, Julian Elischer wrote: >>> Maksim Yevmenkin wrote: >>>> Dear All, >>>> >>>> it seems to me that nmdm(4) is not calling .l_close (i.e. does not >>>> close whatever line discipline might be installed onto /dev/nmdmXX). >>>> the problem is easy to reproduce - just open /dev/nmdm0A and install, >>>> say, ng_tty(4) line discipline onto it. after that, simply close the >>>> /dev/nmdm0A. in theory, the ng_tty(4) node should disappear when >>>> device is closed, but it does not. > > [...] > >> i have not tried other disciplines yet, i.e. ppp and slip, > > ok, i changed the patch to > > === > > diff -u nmdm.c.orig nmdm.c > --- nmdm.c.orig 2006-11-21 16:59:40.000000000 -0800 > +++ nmdm.c 2007-07-27 15:57:50.000000000 -0700 > @@ -401,8 +401,13 @@ > static int > nmdmclose(struct cdev *dev, int flag, int mode, struct thread *td) > { > + struct tty *tp = dev->si_tty; > + int error; > > - return (tty_close(dev->si_tty)); > + error = ttyld_close(tp, flag); > + (void) tty_close(tp); > + > + return (error); > } looks fine to me > > static void > > === > > and tried it with h4, ppp and slip line disciplines. it seems to work. > since nmdmopen() calls ttyld_open(), nmdmclose(), imo, should call > ttyld_close(). > > any comments? > > thanks, > max From owner-freebsd-current@FreeBSD.ORG Sat Jul 28 06:33: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 79C9316A41A for ; Sat, 28 Jul 2007 06:33:24 +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 2482513C45D for ; Sat, 28 Jul 2007 06:33:24 +0000 (UTC) (envelope-from thierry@herbelot.com) Received: from smtp4-g19.free.fr (localhost.localdomain [127.0.0.1]) by smtp4-g19.free.fr (Postfix) with ESMTP id C4A996E03F for ; Sat, 28 Jul 2007 08:33:22 +0200 (CEST) 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 9357E5CF2 for ; Sat, 28 Jul 2007 08:33:22 +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 l6S6VfhJ029097; Sat, 28 Jul 2007 08:31:42 +0200 (CEST) From: Thierry Herbelot To: freebsd-current@freebsd.org Date: Sat, 28 Jul 2007 08:31:32 +0200 User-Agent: KMail/1.9.7 References: <200707210657.11159.thierry@herbelot.com> <20070727200826.GA53337@dan.emsphone.com> <20070727205634.GA49495@rot26.obsecurity.org> In-Reply-To: <20070727205634.GA49495@rot26.obsecurity.org> 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-15" Content-Transfer-Encoding: 8bit Content-Disposition: inline Message-Id: <200707280831.34518.thierry@herbelot.com> Cc: Dan Nelson , Kris Kennaway Subject: Re: ZFS panic: System call unlink returning with 1 locks held 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, 28 Jul 2007 06:33:24 -0000 Le Friday 27 July 2007, Kris Kennaway a écrit : > On Fri, Jul 27, 2007 at 03:08:26PM -0500, Dan Nelson wrote: > > In the last episode (Jul 21), Thierry Herbelot said: > > > with a recent -current -built yesterday), I just got a panic while > > > rebuilding -j4 the world and portupgrading firefox. > > > > > > the machine is pretty much memory limited (only 320 MB of RAM), with > > > two CPUs, running a straight GENERIC kernel, including WITNESS and > > > INVARIANTS. > > > > [..] > > > > > 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 > > > > I've been seeing this, as late as on a Jul 24 kernel. Happened once > > during the cleandir stage of a buildworld, and few more times when the > > system was relatively idle (although it is an mrtg server so lots of > > files are constantly created and rm'd). My system is i386 with 1GB of > > RAM, has a ZFS root, and is SMP. I've also gotten a similar "System > > call rename returning with 1 locks held" panic. Is there any way to > > find out what lock is being held? I've got a couple crashdumps. > > It appears to be a leak in the lock counters somewhere, perhaps > related to recursively acquired rwlocks (e.g. double increment, single > free). I eventually disabled the check because even adding extensive > extra debugging there was no evidence of an actual lock being leaked > anywhere. > > Kris Hello, I saw the same panic once or twice since the first report (same trace, different phases of make buildworld). I had vfs.zfs.zil_disable="1" in /boot/loader.conf, which I just removed. we'll see if the stability improves. TfH -- From owner-freebsd-current@FreeBSD.ORG Sat Jul 28 10:34:49 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 4F62B16A46B for ; Sat, 28 Jul 2007 10:34:49 +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 2302513C458 for ; Sat, 28 Jul 2007 10:34:48 +0000 (UTC) (envelope-from vova@sw.ru) Received: from vova by vbook.fbsd.ru with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IEjd5-000DPp-Os; Sat, 28 Jul 2007 14:34:35 +0400 From: Vladimir Grebenschikov To: Doug Ambrisko In-Reply-To: <200707131907.l6DJ7Fu1090309@ambrisko.com> References: <200707131907.l6DJ7Fu1090309@ambrisko.com> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable Organization: SWsoft Date: Sat, 28 Jul 2007 14:34:35 +0400 Message-Id: <1185618875.1461.8.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 FreeBSD GNOME Team Port Sender: Vladimir Grebenschikov Cc: Matthew Jacob , freebsd-current@freebsd.org, Max Laier Subject: Re: Can't build RELENG_6 from HEAD? 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, 28 Jul 2007 10:34:49 -0000 =F7 =D0=D4, 13/07/2007 =D7 12:07 -0700, Doug Ambrisko =D0=C9=DB=C5=D4: > Matthew Jacob writes: > | gcc 4.X will barf all over RELENG_6 code. Better start thinking about > | a jailed build. >=20 > And if you do script something like: "Chicken and egg" problem To make chroot area you need to build appropriate source tree (RELENG_6). But it is not build-able due to gcc 4.x. (of course I known that everybody can unpack 6.x from binary distribution, but it is another story) probably something like CC=3Dgcc34 will help ? --=20 Vladimir B. Grebenschikov vova@fbsd.ru From owner-freebsd-current@FreeBSD.ORG Sat Jul 28 11:55:20 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 C1B6216A418 for ; Sat, 28 Jul 2007 11:55:20 +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 9648813C45A for ; Sat, 28 Jul 2007 11:55:20 +0000 (UTC) (envelope-from vova@sw.ru) Received: from vova by vbook.fbsd.ru with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IEkt9-000McA-SD; Sat, 28 Jul 2007 15:55:15 +0400 From: Vladimir Grebenschikov To: Doug Ambrisko In-Reply-To: <1185618875.1461.8.camel@localhost> References: <200707131907.l6DJ7Fu1090309@ambrisko.com> <1185618875.1461.8.camel@localhost> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable Organization: SWsoft Date: Sat, 28 Jul 2007 15:55:15 +0400 Message-Id: <1185623715.1461.19.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 FreeBSD GNOME Team Port Sender: Vladimir Grebenschikov Cc: Matthew Jacob , freebsd-current@freebsd.org, Max Laier Subject: Re: Can't build RELENG_6 from HEAD? 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, 28 Jul 2007 11:55:20 -0000 =F7 =D3=C2, 28/07/2007 =D7 14:34 +0400, Vladimir Grebenschikov =D0=C9=DB=C5= =D4: > =F7 =D0=D4, 13/07/2007 =D7 12:07 -0700, Doug Ambrisko =D0=C9=DB=C5=D4: > > Matthew Jacob writes: > > | gcc 4.X will barf all over RELENG_6 code. Better start thinking about > > | a jailed build. > >=20 > > And if you do script something like: >=20 > "Chicken and egg" problem >=20 > To make chroot area you need to build appropriate source tree > (RELENG_6). > But it is not build-able due to gcc 4.x. > (of course I known that everybody can unpack 6.x from binary > distribution, but it is another story) >=20 > probably something like CC=3Dgcc34 will help ? Hmm, does not works also: $ make toolchain CC=3D/usr/X11R6/bin/gcc34 ... =3D=3D=3D> lib/libcrypt (obj,depend,all,install) /usr/X11R6/bin/gcc34 -O2 -fno-strict-aliasing -pipe -I/usr/src/releng6/src= /lib/libcrypt/../libmd -I/usr/src/releng6/src/lib/libcrypt/../libutil -I/us= r/src/releng6/src/lib/libcrypt -DHAS_DES -DHAS_BLOWFISH -Dauth_getval=3D__a= uth_getval -Dproperty_find=3D__property_find -Dproperties_read=3D__properti= es_read -Dproperties_free=3D__properties_free -DMD4Init=3D__MD4Init -DMD4Fi= nal=3D__MD4Final -DMD4Update=3D__MD4Update -DMD4Pad=3D__MD4Pad -DMD5Init=3D= __MD5Init -DMD5Final=3D__MD5Final -DMD5Update=3D__MD5Update -DMD5Pad=3D__MD= 5Pad -c /usr/src/releng6/src/lib/libcrypt/../libmd/md5c.c /usr/src/releng6/src/lib/libcrypt/../libmd/md5c.c: In function `__MD5Update= ': /usr/src/releng6/src/lib/libcrypt/../libmd/md5c.c:154: error: argument "inp= ut" doesn't match prototype /usr/include/sys/md5.h:46: error: prototype declaration *** Error code 1 And looks like it just incorrectly includes system /usr/include/sys/md5.h i= nstead of tree-based sys/sys/md5.h and not only here ... --=20 Vladimir B. Grebenschikov vova@fbsd.ru From owner-freebsd-current@FreeBSD.ORG Sat Jul 28 13:36: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 2937E16A41B for ; Sat, 28 Jul 2007 13:36:24 +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 9F84D13C4D3 for ; Sat, 28 Jul 2007 13:36:23 +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 l6SDaLpu085297; Sat, 28 Jul 2007 17:36:21 +0400 (MSD) (envelope-from marck@rinet.ru) Date: Sat, 28 Jul 2007 17:36:21 +0400 (MSD) From: Dmitry Morozovsky To: Maksim Yevmenkin In-Reply-To: Message-ID: <20070728173355.O42349@woozle.rinet.ru> References: <20070727141421.H42349@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]); Sat, 28 Jul 2007 17:36:22 +0400 (MSD) Cc: current@freebsd.org Subject: Re: possible showstopper: kbdmux hangs -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: Sat, 28 Jul 2007 13:36:24 -0000 On Fri, 27 Jul 2007, Maksim Yevmenkin wrote: MY> On 7/27/07, Dmitry Morozovsky wrote: MY> > Hi there, MY> > MY> > on some of my mobos -current hangs early (when starning init) if kbdmux is MY> > included in kernel (both on i386 and amd64); this seems to be some race, as MY> > hangs are not 100% reproducible. What info should I provide to debug? MY> MY> the usual suspects are MY> MY> 1) while (KBDMUX_CHECK_CHAR(kbd)) { ... } loop in kbdmux_kbd_event(). MY> could you please try to put some debug printf's into it and make sure MY> it does not stuck there. errrm. Added two printfs with ppsratecheck - and, as usual, 'specialist presense effect' is in place: no single hang since, both on stock GENERIC and my own stripped down kernel so far (approx 20 reboots). Will try further. MY> MY> 2) callout. kbdmux callout initialized as non mp-safe to make sure MY> giant is held. MY> MY> 3) task queue. kbdmux(4) uses taskqueue_swi_giant. MY> MY> you might want to try uncomment section at line 81 in kbdmux.c. this MY> should add private lock for kbdmux(4). not sure it will work though - MY> many things has changed since i tried it. MY> MY> > I'm using only PS2 keyboards, and have no other format keyboards handy; MY> > however, I can obtain USB keyb if needed. MY> MY> are you using ps/2 mouse? if so, try to disconnect it and see if this helps. No, there is no mouse attached. Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Sat Jul 28 14:48: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 B272A16A417 for ; Sat, 28 Jul 2007 14:48:01 +0000 (UTC) (envelope-from eischen@vigrid.com) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id 91F0B13C46A for ; Sat, 28 Jul 2007 14:48:01 +0000 (UTC) (envelope-from eischen@vigrid.com) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.1/8.14.1/NETPLEX) with ESMTP id l6SEJ4AP004602 for ; Sat, 28 Jul 2007 10:19:04 -0400 (EDT) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-3.0 (mail.netplex.net [204.213.176.10]); Sat, 28 Jul 2007 10:19:04 -0400 (EDT) Date: Sat, 28 Jul 2007 10:19:04 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: current@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Subject: TERM={xterm-r5,xterm-r6} behaving badly with man(1) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: deischen@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, 28 Jul 2007 14:48:01 -0000 Sometime in the last few months, something changed (broke IMHO) when using TERM=xterm-r5 or TERM=xterm-r6. I've been setting TERM=xterm-r5 when logging in to my BSD boxes remotely from my Solaris boxes, so that man(1) works. But after updating my relatively old (May?) -current box, xterm-r5 and xterm-r6 no longer do the right thing when using man. With TERM set to either one of those, man(1) will clear the screen after it is done, leaving no trace of the man page behind. I've always hated HP/UX and Linux for this behavior, and our default TERM=xterm does not exhibit this behavior. To see this: $ TERM=xterm-r5 $ export TERM $ man man Anyone know how this got broke? -- DE From owner-freebsd-current@FreeBSD.ORG Sat Jul 28 14:49:26 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 D8B5F16A421; Sat, 28 Jul 2007 14:49:26 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id C713913C4F4; Sat, 28 Jul 2007 14:49:26 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.8/8.13.8) with ESMTP id l6SEnQlO052720; Sat, 28 Jul 2007 10:49:26 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.1/8.14.1) with ESMTP id l6SEnQns072320; Sat, 28 Jul 2007 10:49:26 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 0066B73068; Sat, 28 Jul 2007 10:49:25 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070728144926.0066B73068@freebsd-current.sentex.ca> Date: Sat, 28 Jul 2007 10:49:25 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.91.1, clamav-milter version 0.91.1 on news X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jul 2007 14:49:27 -0000 TB --- 2007-07-28 13:07:45 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-07-28 13:07:45 - starting HEAD tinderbox run for i386/i386 TB --- 2007-07-28 13:07:45 - cleaning the object tree TB --- 2007-07-28 13:08:17 - checking out the source tree TB --- 2007-07-28 13:08:17 - cd /tinderbox/HEAD/i386/i386 TB --- 2007-07-28 13:08:17 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-07-28 13:15:50 - building world (CFLAGS=-O2 -pipe) TB --- 2007-07-28 13:15:50 - cd /src TB --- 2007-07-28 13:15:50 - /usr/bin/make -B buildworld >>> World build started on Sat Jul 28 13:15:51 UTC 2007 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat Jul 28 14:30:39 UTC 2007 TB --- 2007-07-28 14:30:39 - generating LINT kernel config TB --- 2007-07-28 14:30:39 - cd /src/sys/i386/conf TB --- 2007-07-28 14:30:39 - /usr/bin/make -B LINT TB --- 2007-07-28 14:30:39 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-07-28 14:30:39 - cd /src TB --- 2007-07-28 14:30:39 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Jul 28 14:30:40 UTC 2007 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] :> hack.c cc -shared -nostdlib hack.c -o hack.So rm -f hack.c MAKE=/usr/bin/make sh /src/sys/conf/newvers.sh LINT cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue vers.c linking kernel tcp_input.o(.data+0x0): multiple definition of `tcpstates' tcp_debug.o(.data+0x80): first defined here *** Error code 1 Stop in /obj/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-07-28 14:49:25 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-07-28 14:49:25 - ERROR: failed to build lint kernel TB --- 2007-07-28 14:49:25 - tinderbox aborted TB --- 0.88 user 2.98 system 6100.67 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Sat Jul 28 15:44:00 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 7139716A419 for ; Sat, 28 Jul 2007 15:44:00 +0000 (UTC) (envelope-from dickey@saltmine.radix.net) Received: from saltmine.radix.net (saltmine.radix.net [207.192.128.40]) by mx1.freebsd.org (Postfix) with ESMTP id 4531513C457 for ; Sat, 28 Jul 2007 15:43:59 +0000 (UTC) (envelope-from dickey@saltmine.radix.net) Received: from saltmine.radix.net (localhost [127.0.0.1]) by saltmine.radix.net (8.12.2/8.12.2) with ESMTP id l6SFRelj004953 for ; Sat, 28 Jul 2007 11:27:40 -0400 (EDT) Received: (from dickey@localhost) by saltmine.radix.net (8.12.2/8.12.2/Submit) id l6SFReZR004952 for current@freebsd.org; Sat, 28 Jul 2007 11:27:40 -0400 (EDT) Date: Sat, 28 Jul 2007 11:27:39 -0400 From: Thomas Dickey To: current@freebsd.org Message-ID: <20070728152739.GA29867@saltmine.radix.net> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="82I3+IH0IqGh5yIs" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.27i Cc: Subject: Re: TERM={xterm-r5,xterm-r6} behaving badly with man(1) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jul 2007 15:44:00 -0000 --82I3+IH0IqGh5yIs Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jul 28, 2007 at 10:19:04AM -0400, Daniel Eischen wrote: > Sometime in the last few months, something changed... > using TERM=3Dxterm-r5 or TERM=3Dxterm-r6. I've been setting TERM=3Dxterm= -r5 I see that termcap source (whether derived from ncurses or xterm) has for quite a while defined ti/te capabilities, while terminfo source (still from ncurses or xterm) has not. --=20 Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net --82I3+IH0IqGh5yIs Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (SunOS) Comment: For info see http://www.gnupg.org iD8DBQFGq2BptIqByHxlDocRAprTAJ9Qm2wlmNCm3hD6iPOj1BfQkF6EnACfUyrp Ks3UPsqKsnyEqRMcyEFKSKs= =0z13 -----END PGP SIGNATURE----- --82I3+IH0IqGh5yIs-- From owner-freebsd-current@FreeBSD.ORG Sat Jul 28 16:05: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 3E0B316A417; Sat, 28 Jul 2007 16:05:23 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 205A613C457; Sat, 28 Jul 2007 16:05:22 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.8/8.13.8) with ESMTP id l6SG5M0p055854; Sat, 28 Jul 2007 12:05:22 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.1/8.14.1) with ESMTP id l6SG5M5P062413; Sat, 28 Jul 2007 12:05:22 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id E7D8773068; Sat, 28 Jul 2007 12:05:21 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070728160521.E7D8773068@freebsd-current.sentex.ca> Date: Sat, 28 Jul 2007 12:05:21 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.91.1, clamav-milter version 0.91.1 on clamscanner4 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jul 2007 16:05:23 -0000 TB --- 2007-07-28 14:27:48 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-07-28 14:27:48 - starting HEAD tinderbox run for i386/pc98 TB --- 2007-07-28 14:27:48 - cleaning the object tree TB --- 2007-07-28 14:28:18 - checking out the source tree TB --- 2007-07-28 14:28:18 - cd /tinderbox/HEAD/i386/pc98 TB --- 2007-07-28 14:28:18 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-07-28 14:36:04 - building world (CFLAGS=-O2 -pipe) TB --- 2007-07-28 14:36:04 - cd /src TB --- 2007-07-28 14:36:04 - /usr/bin/make -B buildworld >>> World build started on Sat Jul 28 14:36:05 UTC 2007 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat Jul 28 15:51:05 UTC 2007 TB --- 2007-07-28 15:51:05 - generating LINT kernel config TB --- 2007-07-28 15:51:05 - cd /src/sys/pc98/conf TB --- 2007-07-28 15:51:05 - /usr/bin/make -B LINT TB --- 2007-07-28 15:51:05 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-07-28 15:51:05 - cd /src TB --- 2007-07-28 15:51:05 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Jul 28 15:51:05 UTC 2007 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] :> hack.c cc -shared -nostdlib hack.c -o hack.So rm -f hack.c MAKE=/usr/bin/make sh /src/sys/conf/newvers.sh LINT cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -pg -mprofiler-epilogue vers.c linking kernel tcp_input.o(.data+0x0): multiple definition of `tcpstates' tcp_debug.o(.data+0x80): first defined here *** Error code 1 Stop in /obj/pc98/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-07-28 16:05:21 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-07-28 16:05:21 - ERROR: failed to build lint kernel TB --- 2007-07-28 16:05:21 - tinderbox aborted TB --- 0.96 user 2.76 system 5853.13 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Sat Jul 28 16:49: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 3997D16A419 for ; Sat, 28 Jul 2007 16:49:24 +0000 (UTC) (envelope-from peter.schuller@infidyne.com) Received: from proxy3.bredband.net (proxy3.bredband.net [195.54.101.73]) by mx1.freebsd.org (Postfix) with ESMTP id F0CF813C45D for ; Sat, 28 Jul 2007 16:49:23 +0000 (UTC) (envelope-from peter.schuller@infidyne.com) Received: from prometheus.scode.org (85.229.22.84) by proxy3.bredband.net (7.3.127) id 46A8FA4C00088783 for current@freebsd.org; Sat, 28 Jul 2007 18:28:28 +0200 Received: from localhost (localhost [127.0.0.1]) by prometheus.scode.org (Postfix) with ESMTP id C321D1CC8E for ; Sat, 28 Jul 2007 20:28:37 +0200 (CEST) From: Peter Schuller To: current@freebsd.org Date: Sat, 28 Jul 2007 20:28:36 +0200 User-Agent: KMail/1.9.7 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200707282028.37102.peter.schuller@infidyne.com> Cc: Subject: (ZFS?): panic: lockmgr: locking against myself X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Jul 2007 16:49:24 -0000 Hello, I have a machine with root on ZFS and /boot on gmirror. Version is 7-CURRENT from about a week ago or so (can't check since system won't boot). After a certain sequence of events that I will describe below, I now get this on boot (typed manually, so there may be some mistakes): Trying to mount root from zfs:tank/root panic: lockmgr: locking against myself cpuid = 0 KBD: enter: panic [thread pid 1 tid 100002 ] Stopped at kbd_enter+0x31: leave db>bt kbd_enter() at kbd_enter+0x31 panic() at panic+0x173 _lockmgr() at _lockmgr+0x085a VOP_LOCK1_APV() at VOP_LOCK1_APV+0x46 _vn_lock() at _vn_lock+0x83 vrele() at vrele+0xf5 mountcheckdirs() at mountcheckdirs+0x1e8 vfs_donmount() at vfs_donmount+0x111c kernel_mount() at kernel_mount+0x88 kernel_vmount() at kernel_vmoun+0xcb vfs_mountroot_try() at vfs_mountroot_try+0x10c vfs_mountroot() at vfs_mountroot+0x324 start_init() at start_init+0x4d fork_exit() at fork_exit+0x11f fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xfffffffffac357d30, rbp = 0 --- This is on a Dell 2950, with two SATA drives exposed as individual non-redundant volumes through the PERC 5/i controller (mfi driver). The sequence of events were: (1) Boot the system. (2) Yank one of the drives live; watch errors flash by, zfs detecting the corruption of one of the drives. (3) Reboot with the drive missing, confirming booting still works (I am *pretty* sure I did this). (4) Shutdown, insert drive again, enable it in RAID controller config, and boot. (5) Gmirror refuses to use the swapped drive because it is "broken" (not sure why this happened; I was assuming it would detect it as out of date and rebuild). I manually forget and re-insert the drive. (6) Meanwhile, ZFS has resilvered and is reporting some checksum mismatches. I scrub the pool and heal some more checksum mismatches (corruption/bitflips on hotswap is consistent with some other experience with a Marvell controller and attempted hotswapping). Second scrub completes without errors. (7) All is fine. I shut the machine down physically, remove one drive, and try to boot for the purpose of testing this particular failure mode. (8) I now get the above panic on trying to mount root. (9) Shutdown, re-insert drive again per above, and try to boot. Still the same panic. Both drives are now being detected in the gmirror though. -- / Peter Schuller PGP userID: 0xE9758B7D or 'Peter Schuller ' Key retrieval: Send an E-Mail to getpgpkey@scode.org E-Mail: peter.schuller@infidyne.com Web: http://www.scode.org From owner-freebsd-current@FreeBSD.ORG Sat Jul 28 16:56: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 E0B4416A419; Sat, 28 Jul 2007 16:56:13 +0000 (UTC) (envelope-from conrads@serene.no-ip.org) Received: from eastrmpop109.cox.net (eastrmpop109.cox.net [68.230.240.51]) by mx1.freebsd.org (Postfix) with ESMTP id 6CC0B13C459; Sat, 28 Jul 2007 16:56:13 +0000 (UTC) (envelope-from conrads@serene.no-ip.org) Received: from eastrmimpo02.cox.net ([68.1.16.120]) by eastrmmtao104.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20070728162538.KZRF6835.eastrmmtao104.cox.net@eastrmimpo02.cox.net>; Sat, 28 Jul 2007 12:25:38 -0400 Received: from serene.no-ip.org ([72.200.17.85]) by eastrmimpo02.cox.net with bizsmtp id V4Rd1X0091q7YRk0000000; Sat, 28 Jul 2007 12:25:37 -0400 Received: from serene.no-ip.org (conrads@localhost [127.0.0.1]) by serene.no-ip.org (8.14.1/8.14.1) with ESMTP id l6SGPZKx044985; Sat, 28 Jul 2007 11:25:36 -0500 (CDT) (envelope-from conrads@serene.no-ip.org) Received: (from conrads@localhost) by serene.no-ip.org (8.14.1/8.14.1/Submit) id l6SGPY0f044974; Sat, 28 Jul 2007 11:25:34 -0500 (CDT) (envelope-from conrads) X-Mailer: XFMail 1.5.5 on FreeBSD X-Priority: 3 (Normal) Date: Sat, 28 Jul 2007 11:25:32 -0500 (CDT) Message-ID: <20070523223002.GA63205@cox.net> Mail-Followup-To: "Conrad J. Sabatier" , Roman Divacky , freebsd-current@FreeBSD.org References: <200705221703.l4MH3bHG057767@serene.no-ip.org> <20070523144743.GA48764@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070523144743.GA48764@freebsd.org> User-Agent: Mutt/1.5.15 (2007-04-06) Sender: conrads@ip72-200-30-62.no.no.cox.net From: "Conrad J. Sabatier" To: Roman Divacky Cc: freebsd-current@freebsd.org Subject: Re: dhclient fxp0 broken in -current for several days now X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Jul 2007 16:56:14 -0000 On Wed, May 23, 2007 at 04:47:43PM +0200, Roman Divacky wrote: > On Tue, May 22, 2007 at 12:03:32PM -0500, Conrad J. Sabatier wrote: > > I *think* this started around last Friday or Saturday (May 19 or 20). > > Suddenly, dhclient is no longer obtaining an IP address from my ISP > > (Cox), nor is it falling back to the prior saved lease. > > I see exactly the same thing, starting roughly on the same day... Well, in my case, either a subsequent CVS update fixed it, or very likely, it was due to my use of -O3 optimization with gcc 4.2. I just recompiled dhclient a little while ago using -O2 instead, and it's working fine again now. I do tend to believe it was an optimization bug. Sorry for any possible false alarms, folks. :-) -- Conrad J. Sabatier From owner-freebsd-current@FreeBSD.ORG Sat Jul 28 16:56:42 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 1517916A41A; Sat, 28 Jul 2007 16:56:42 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id CDF8513C457; Sat, 28 Jul 2007 16:56:41 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.14.1/8.13.8) with ESMTP id l6SGuf1U069911; Sat, 28 Jul 2007 12:56:41 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.1/8.14.1) with ESMTP id l6SGue1E068113; Sat, 28 Jul 2007 12:56:40 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id BA75D73068; Sat, 28 Jul 2007 12:56:40 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070728165640.BA75D73068@freebsd-current.sentex.ca> Date: Sat, 28 Jul 2007 12:56:40 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.91.1, clamav-milter version 0.91.1 on clamscanner1 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jul 2007 16:56:42 -0000 TB --- 2007-07-28 14:49:26 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-07-28 14:49:26 - starting HEAD tinderbox run for ia64/ia64 TB --- 2007-07-28 14:49:26 - cleaning the object tree TB --- 2007-07-28 14:49:58 - checking out the source tree TB --- 2007-07-28 14:49:58 - cd /tinderbox/HEAD/ia64/ia64 TB --- 2007-07-28 14:49:58 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-07-28 14:57:06 - building world (CFLAGS=-O2 -pipe) TB --- 2007-07-28 14:57:06 - cd /src TB --- 2007-07-28 14:57:06 - /usr/bin/make -B buildworld >>> World build started on Sat Jul 28 14:57:08 UTC 2007 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat Jul 28 16:37:00 UTC 2007 TB --- 2007-07-28 16:37:00 - generating LINT kernel config TB --- 2007-07-28 16:37:00 - cd /src/sys/ia64/conf TB --- 2007-07-28 16:37:00 - /usr/bin/make -B LINT TB --- 2007-07-28 16:37:00 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-07-28 16:37:00 - cd /src TB --- 2007-07-28 16:37:00 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Jul 28 16:37:01 UTC 2007 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] :> hack.c cc -shared -nostdlib hack.c -o hack.So rm -f hack.c MAKE=/usr/bin/make sh /src/sys/conf/newvers.sh LINT cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding vers.c linking kernel tcp_input.o(.data.rel.local+0x0): multiple definition of `tcpstates' tcp_debug.o(.data.rel.local+0xc8): first defined here *** Error code 1 Stop in /obj/ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-07-28 16:56:40 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-07-28 16:56:40 - ERROR: failed to build lint kernel TB --- 2007-07-28 16:56:40 - tinderbox aborted TB --- 0.88 user 2.74 system 7634.27 real http://tinderbox.des.no/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Sat Jul 28 16:58:38 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 7743316A41B for ; Sat, 28 Jul 2007 16:58:38 +0000 (UTC) (envelope-from peter.schuller@infidyne.com) Received: from proxy1.bredband.net (proxy1.bredband.net [195.54.101.71]) by mx1.freebsd.org (Postfix) with ESMTP id 389E313C4B6 for ; Sat, 28 Jul 2007 16:58:38 +0000 (UTC) (envelope-from peter.schuller@infidyne.com) Received: from prometheus.scode.org (85.229.22.84) by proxy1.bredband.net (7.3.127) id 46A848D6000C7DF0; Sat, 28 Jul 2007 18:58:36 +0200 Received: from localhost (localhost [127.0.0.1]) by prometheus.scode.org (Postfix) with ESMTP id 21A4A1CC8E; Sat, 28 Jul 2007 20:58:46 +0200 (CEST) From: Peter Schuller To: freebsd-current@freebsd.org Date: Sat, 28 Jul 2007 20:58:45 +0200 User-Agent: KMail/1.9.7 References: <200707282028.37102.peter.schuller@infidyne.com> In-Reply-To: <200707282028.37102.peter.schuller@infidyne.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200707282058.45554.peter.schuller@infidyne.com> Cc: current@freebsd.org Subject: Re: (ZFS?): panic: lockmgr: locking against myself X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Jul 2007 16:58:38 -0000 After several failed boot attempts, I burned and booted a 7.0 snapshot iso and tried to mount setting the appropriate zfs.root.mountfrom value. It failed (installer booted as usual). After this I tried booting normally again, and now the system came up. I saw there was a suspicious looking commit made to vfs_mount.c involving the use of a different lock. I'm hoping this was related, so for now I will update to a newer CURRENT and see if I can ever reproduce the problem. -- / Peter Schuller PGP userID: 0xE9758B7D or 'Peter Schuller ' Key retrieval: Send an E-Mail to getpgpkey@scode.org E-Mail: peter.schuller@infidyne.com Web: http://www.scode.org From owner-freebsd-current@FreeBSD.ORG Sat Jul 28 17:19: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 B512816A418 for ; Sat, 28 Jul 2007 17:19:32 +0000 (UTC) (envelope-from peter.schuller@infidyne.com) Received: from proxy1.bredband.net (proxy1.bredband.net [195.54.101.71]) by mx1.freebsd.org (Postfix) with ESMTP id 7669A13C459 for ; Sat, 28 Jul 2007 17:19:32 +0000 (UTC) (envelope-from peter.schuller@infidyne.com) Received: from prometheus.scode.org (85.229.22.84) by proxy1.bredband.net (7.3.127) id 46A848D6000C7DF0; Sat, 28 Jul 2007 18:58:36 +0200 Received: from localhost (localhost [127.0.0.1]) by prometheus.scode.org (Postfix) with ESMTP id 21A4A1CC8E; Sat, 28 Jul 2007 20:58:46 +0200 (CEST) From: Peter Schuller To: freebsd-current@freebsd.org Date: Sat, 28 Jul 2007 20:58:45 +0200 User-Agent: KMail/1.9.7 References: <200707282028.37102.peter.schuller@infidyne.com> In-Reply-To: <200707282028.37102.peter.schuller@infidyne.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200707282058.45554.peter.schuller@infidyne.com> Cc: current@freebsd.org Subject: Re: (ZFS?): panic: lockmgr: locking against myself X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Jul 2007 17:19:32 -0000 After several failed boot attempts, I burned and booted a 7.0 snapshot iso and tried to mount setting the appropriate zfs.root.mountfrom value. It failed (installer booted as usual). After this I tried booting normally again, and now the system came up. I saw there was a suspicious looking commit made to vfs_mount.c involving the use of a different lock. I'm hoping this was related, so for now I will update to a newer CURRENT and see if I can ever reproduce the problem. -- / Peter Schuller PGP userID: 0xE9758B7D or 'Peter Schuller ' Key retrieval: Send an E-Mail to getpgpkey@scode.org E-Mail: peter.schuller@infidyne.com Web: http://www.scode.org From owner-freebsd-current@FreeBSD.ORG Sat Jul 28 17:41:22 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 1760316A41A; Sat, 28 Jul 2007 17:41:22 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id C7C2C13C45D; Sat, 28 Jul 2007 17:41:21 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.13.8/8.13.8) with ESMTP id l6SHfLfR059687; Sat, 28 Jul 2007 13:41:21 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.1/8.14.1) with ESMTP id l6SHfLGL090640; Sat, 28 Jul 2007 13:41:21 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id E6C8673068; Sat, 28 Jul 2007 13:41:20 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070728174120.E6C8673068@freebsd-current.sentex.ca> Date: Sat, 28 Jul 2007 13:41:20 -0400 (EDT) X-Virus-Scanned: ClamAV version devel-20070102, clamav-milter version devel-111206 on clamscanner3 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jul 2007 17:41:22 -0000 TB --- 2007-07-28 16:05:22 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-07-28 16:05:22 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2007-07-28 16:05:22 - cleaning the object tree TB --- 2007-07-28 16:05:46 - checking out the source tree TB --- 2007-07-28 16:05:46 - cd /tinderbox/HEAD/powerpc/powerpc TB --- 2007-07-28 16:05:46 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-07-28 16:12:44 - building world (CFLAGS=-O2 -pipe) TB --- 2007-07-28 16:12:44 - cd /src TB --- 2007-07-28 16:12:44 - /usr/bin/make -B buildworld >>> World build started on Sat Jul 28 16:12:45 UTC 2007 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat Jul 28 17:28:14 UTC 2007 TB --- 2007-07-28 17:28:14 - generating LINT kernel config TB --- 2007-07-28 17:28:14 - cd /src/sys/powerpc/conf TB --- 2007-07-28 17:28:14 - /usr/bin/make -B LINT TB --- 2007-07-28 17:28:14 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-07-28 17:28:14 - cd /src TB --- 2007-07-28 17:28:14 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Jul 28 17:28:14 UTC 2007 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] :> hack.c cc -shared -nostdlib hack.c -o hack.So rm -f hack.c MAKE=/usr/bin/make sh /src/sys/conf/newvers.sh LINT cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding vers.c linking kernel tcp_input.o(.data+0x4): multiple definition of `tcpstates' tcp_debug.o(.data+0x64): first defined here *** Error code 1 Stop in /obj/powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-07-28 17:41:20 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-07-28 17:41:20 - ERROR: failed to build lint kernel TB --- 2007-07-28 17:41:20 - tinderbox aborted TB --- 0.84 user 2.37 system 5758.51 real http://tinderbox.des.no/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Sat Jul 28 17:55: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 44EE216A419 for ; Sat, 28 Jul 2007 17:55:16 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.freebsd.org (Postfix) with ESMTP id D663813C428 for ; Sat, 28 Jul 2007 17:55:15 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 6DDE2487FF; Sat, 28 Jul 2007 19:55:13 +0200 (CEST) Received: from localhost (154.81.datacomsa.pl [195.34.81.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 35DDD45696; Sat, 28 Jul 2007 19:55:06 +0200 (CEST) Date: Sat, 28 Jul 2007 19:54:26 +0200 From: Pawel Jakub Dawidek To: Peter Schuller Message-ID: <20070728175426.GF1092@garage.freebsd.pl> References: <200707282028.37102.peter.schuller@infidyne.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="NY6JkbSqL3W9mApi" Content-Disposition: inline In-Reply-To: <200707282028.37102.peter.schuller@infidyne.com> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-2.6 required=3.0 tests=BAYES_00 autolearn=ham version=3.0.4 Cc: current@freebsd.org Subject: Re: (ZFS?): panic: lockmgr: locking against myself X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Jul 2007 17:55:16 -0000 --NY6JkbSqL3W9mApi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jul 28, 2007 at 08:28:36PM +0200, Peter Schuller wrote: > Hello, >=20 > I have a machine with root on ZFS and /boot on gmirror. Version is 7-CURR= ENT=20 > from about a week ago or so (can't check since system won't boot). After = a=20 > certain sequence of events that I will describe below, I now get this on = boot=20 > (typed manually, so there may be some mistakes): >=20 > Trying to mount root from zfs:tank/root > panic: lockmgr: locking against myself > cpuid =3D 0 > KBD: enter: panic > [thread pid 1 tid 100002 ] > Stopped at kbd_enter+0x31: leave > db>bt > kbd_enter() at kbd_enter+0x31 > panic() at panic+0x173 > _lockmgr() at _lockmgr+0x085a > VOP_LOCK1_APV() at VOP_LOCK1_APV+0x46 > _vn_lock() at _vn_lock+0x83 > vrele() at vrele+0xf5 > mountcheckdirs() at mountcheckdirs+0x1e8 > vfs_donmount() at vfs_donmount+0x111c > kernel_mount() at kernel_mount+0x88 > kernel_vmount() at kernel_vmoun+0xcb > vfs_mountroot_try() at vfs_mountroot_try+0x10c > vfs_mountroot() at vfs_mountroot+0x324 > start_init() at start_init+0x4d > fork_exit() at fork_exit+0x11f > fork_trampoline() at fork_trampoline+0xe > --- trap 0, rip =3D 0, rsp =3D 0xfffffffffac357d30, rbp =3D 0 --- Could you paste the output of: db> show vnode 0x Where is the first argument to vrele() function above. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --NY6JkbSqL3W9mApi Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFGq4LSForvXbEpPzQRAhMGAJ0bdy6oheOSerwrsl4Rjjjo4rehGQCfcO82 /Y4dcldy0zzJ0dj3n30k3Vg= =Io6A -----END PGP SIGNATURE----- --NY6JkbSqL3W9mApi-- From owner-freebsd-current@FreeBSD.ORG Sat Jul 28 18:06: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 B063216A501 for ; Sat, 28 Jul 2007 18:06:19 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 97A7913C48E for ; Sat, 28 Jul 2007 18:06:19 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from rot26.obsecurity.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id A907A1A4D7C; Sat, 28 Jul 2007 11:06:09 -0700 (PDT) Received: by rot26.obsecurity.org (Postfix, from userid 1001) id E401BBEC3; Sat, 28 Jul 2007 14:06:18 -0400 (EDT) Date: Sat, 28 Jul 2007 14:06:18 -0400 From: Kris Kennaway To: Thierry Herbelot Message-ID: <20070728180618.GA66481@rot26.obsecurity.org> References: <200707210657.11159.thierry@herbelot.com> <20070727200826.GA53337@dan.emsphone.com> <20070727205634.GA49495@rot26.obsecurity.org> <200707280831.34518.thierry@herbelot.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200707280831.34518.thierry@herbelot.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org, Dan Nelson , Kris Kennaway Subject: Re: ZFS panic: System call unlink returning with 1 locks held X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Jul 2007 18:06:19 -0000 On Sat, Jul 28, 2007 at 08:31:32AM +0200, Thierry Herbelot wrote: > Le Friday 27 July 2007, Kris Kennaway a ?crit : > > On Fri, Jul 27, 2007 at 03:08:26PM -0500, Dan Nelson wrote: > > > In the last episode (Jul 21), Thierry Herbelot said: > > > > with a recent -current -built yesterday), I just got a panic while > > > > rebuilding -j4 the world and portupgrading firefox. > > > > > > > > the machine is pretty much memory limited (only 320 MB of RAM), with > > > > two CPUs, running a straight GENERIC kernel, including WITNESS and > > > > INVARIANTS. > > > > > > [..] > > > > > > > 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 > > > > > > I've been seeing this, as late as on a Jul 24 kernel. Happened once > > > during the cleandir stage of a buildworld, and few more times when the > > > system was relatively idle (although it is an mrtg server so lots of > > > files are constantly created and rm'd). My system is i386 with 1GB of > > > RAM, has a ZFS root, and is SMP. I've also gotten a similar "System > > > call rename returning with 1 locks held" panic. Is there any way to > > > find out what lock is being held? I've got a couple crashdumps. > > > > It appears to be a leak in the lock counters somewhere, perhaps > > related to recursively acquired rwlocks (e.g. double increment, single > > free). I eventually disabled the check because even adding extensive > > extra debugging there was no evidence of an actual lock being leaked > > anywhere. > > > > Kris > > Hello, > > I saw the same panic once or twice since the first report (same trace, > different phases of make buildworld). > > I had vfs.zfs.zil_disable="1" in /boot/loader.conf, which I just removed. > we'll see if the stability improves. AFAIK, disabling zil remains necessary to avoid low memory deadlocks. Just remove the test or turn off INVARIANTS to disable it. Kris From owner-freebsd-current@FreeBSD.ORG Sat Jul 28 18:08:21 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 4E73716A418; Sat, 28 Jul 2007 18:08:21 +0000 (UTC) (envelope-from peter.schuller@infidyne.com) Received: from proxy3.bredband.net (proxy3.bredband.net [195.54.101.73]) by mx1.freebsd.org (Postfix) with ESMTP id DE09113C481; Sat, 28 Jul 2007 18:08:20 +0000 (UTC) (envelope-from peter.schuller@infidyne.com) Received: from prometheus.scode.org (85.229.22.84) by proxy3.bredband.net (7.3.127) id 46A8FA4C0008B12A; Sat, 28 Jul 2007 20:08:19 +0200 Received: from localhost (localhost [127.0.0.1]) by prometheus.scode.org (Postfix) with ESMTP id DBE401CC8E; Sat, 28 Jul 2007 22:08:28 +0200 (CEST) From: Peter Schuller To: freebsd-current@freebsd.org Date: Sat, 28 Jul 2007 22:08:27 +0200 User-Agent: KMail/1.9.7 References: <200707282028.37102.peter.schuller@infidyne.com> <20070728175426.GF1092@garage.freebsd.pl> In-Reply-To: <20070728175426.GF1092@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200707282208.28222.peter.schuller@infidyne.com> Cc: Pawel Jakub Dawidek , current@freebsd.org Subject: Re: (ZFS?): panic: lockmgr: locking against myself X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Jul 2007 18:08:21 -0000 > Could you paste the output of: > > db> show vnode 0x > > Where is the first argument to vrele() function above. Will do if I can trigger it again. I will be doing some more testing later tonight or tomorrow. -- / Peter Schuller PGP userID: 0xE9758B7D or 'Peter Schuller ' Key retrieval: Send an E-Mail to getpgpkey@scode.org E-Mail: peter.schuller@infidyne.com Web: http://www.scode.org From owner-freebsd-current@FreeBSD.ORG Sat Jul 28 18:08: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 4E73716A418; Sat, 28 Jul 2007 18:08:21 +0000 (UTC) (envelope-from peter.schuller@infidyne.com) Received: from proxy3.bredband.net (proxy3.bredband.net [195.54.101.73]) by mx1.freebsd.org (Postfix) with ESMTP id DE09113C481; Sat, 28 Jul 2007 18:08:20 +0000 (UTC) (envelope-from peter.schuller@infidyne.com) Received: from prometheus.scode.org (85.229.22.84) by proxy3.bredband.net (7.3.127) id 46A8FA4C0008B12A; Sat, 28 Jul 2007 20:08:19 +0200 Received: from localhost (localhost [127.0.0.1]) by prometheus.scode.org (Postfix) with ESMTP id DBE401CC8E; Sat, 28 Jul 2007 22:08:28 +0200 (CEST) From: Peter Schuller To: freebsd-current@freebsd.org Date: Sat, 28 Jul 2007 22:08:27 +0200 User-Agent: KMail/1.9.7 References: <200707282028.37102.peter.schuller@infidyne.com> <20070728175426.GF1092@garage.freebsd.pl> In-Reply-To: <20070728175426.GF1092@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200707282208.28222.peter.schuller@infidyne.com> Cc: Pawel Jakub Dawidek , current@freebsd.org Subject: Re: (ZFS?): panic: lockmgr: locking against myself X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Jul 2007 18:08:21 -0000 > Could you paste the output of: > > db> show vnode 0x > > Where is the first argument to vrele() function above. Will do if I can trigger it again. I will be doing some more testing later tonight or tomorrow. -- / Peter Schuller PGP userID: 0xE9758B7D or 'Peter Schuller ' Key retrieval: Send an E-Mail to getpgpkey@scode.org E-Mail: peter.schuller@infidyne.com Web: http://www.scode.org From owner-freebsd-current@FreeBSD.ORG Sat Jul 28 18:30: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 8F83B16A417; Sat, 28 Jul 2007 18:30:05 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id 499F113C428; Sat, 28 Jul 2007 18:30:05 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.14.1/8.13.8) with ESMTP id l6SIU43q074002; Sat, 28 Jul 2007 14:30:04 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.1/8.14.1) with ESMTP id l6SIU4Ss037833; Sat, 28 Jul 2007 14:30:04 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 43D2173068; Sat, 28 Jul 2007 14:30:04 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070728183004.43D2173068@freebsd-current.sentex.ca> Date: Sat, 28 Jul 2007 14:30:04 -0400 (EDT) X-Virus-Scanned: ClamAV version devel-20070102, clamav-milter version devel-111206 on clamscanner3 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jul 2007 18:30:05 -0000 TB --- 2007-07-28 16:56:40 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-07-28 16:56:40 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2007-07-28 16:56:40 - cleaning the object tree TB --- 2007-07-28 16:57:04 - checking out the source tree TB --- 2007-07-28 16:57:04 - cd /tinderbox/HEAD/sparc64/sparc64 TB --- 2007-07-28 16:57:04 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-07-28 17:04:22 - building world (CFLAGS=-O2 -pipe) TB --- 2007-07-28 17:04:22 - cd /src TB --- 2007-07-28 17:04:22 - /usr/bin/make -B buildworld >>> World build started on Sat Jul 28 17:04:23 UTC 2007 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat Jul 28 18:16:12 UTC 2007 TB --- 2007-07-28 18:16:12 - generating LINT kernel config TB --- 2007-07-28 18:16:12 - cd /src/sys/sparc64/conf TB --- 2007-07-28 18:16:12 - /usr/bin/make -B LINT TB --- 2007-07-28 18:16:12 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-07-28 18:16:12 - cd /src TB --- 2007-07-28 18:16:12 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Jul 28 18:16:12 UTC 2007 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] :> hack.c cc -shared -nostdlib hack.c -o hack.So rm -f hack.c MAKE=/usr/bin/make sh /src/sys/conf/newvers.sh LINT cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror vers.c linking kernel tcp_input.o(.data+0x0): multiple definition of `tcpstates' tcp_debug.o(.data+0xc8): first defined here *** Error code 1 Stop in /obj/sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-07-28 18:30:03 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-07-28 18:30:03 - ERROR: failed to build lint kernel TB --- 2007-07-28 18:30:03 - tinderbox aborted TB --- 0.76 user 2.48 system 5603.13 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Sat Jul 28 18:41:54 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 7C62116A418 for ; Sat, 28 Jul 2007 18:41:54 +0000 (UTC) (envelope-from admin@lissyara.su) Received: from smtp.qwerty.ru (smtp.qwerty.ru [87.240.2.134]) by mx1.freebsd.org (Postfix) with ESMTP id 2ABD213C45B for ; Sat, 28 Jul 2007 18:41:54 +0000 (UTC) (envelope-from admin@lissyara.su) Received: from ussr.lissyara.int.otradno.ru (unknown [10.21.64.215]) by smtp.qwerty.ru (Spam Firewall) with ESMTP id 2BEF31BD6AE7 for ; Sat, 28 Jul 2007 22:41:50 +0400 (MSD) Message-ID: <46AB8DEE.6040008@lissyara.su> Date: Sat, 28 Jul 2007 22:41:50 +0400 From: Alex Keda User-Agent: Thunderbird 2.0.0.5 (X11/20070721) MIME-Version: 1.0 To: freebsd-current@FreeBSD.org Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 8bit Cc: Subject: kernel panic on ssh connect X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Jul 2007 18:41:54 -0000 I update today and when connect to my machine ssh I have kernel panic ================ panic: syncache_add: unexpected tcp flag cpuid = 0 KDB: enter: panic [thread pid 32 tid 100037] stopped at kdb_enter+0x31: leave =============== after input bt: =============== tracing pid 32 tid 100037 td 0ÞÁÁÁÁÁÁ0001303680 kdb_enter() at kdb_enter+0x31 panic() at panic+0x173 syncache_add() at syncache_add+0x8ae tcp_input() at tcp_input+0x98a ip_input() at ip_input+0xc0 ether_demux() at ether_demux+0x1d9 ether_input() at ether_input+0x1d6 ieee80211_input() at ieee80211_input+0x6f8 ath_rx_proc() at ath_rx_proc+0x3cc taskqueue_run() at taskqueue_run+0x94 taskqueue_thread_loop() at taskqueue_thread_loop+0x53 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0Â rsp = 0xffffffffa872ad30, rbp = 0 --- =============== uname -a FreeBSD acer.lissyara.int.otradno.ru 7.0-CURRENT FreeBSD 7.0-CURRENT #0: Sat Jul 28 21:46:52 MSD 2007 root@acer.lissyara.int.otradno.ru:/usr/obj/usr/src/sys/main-color-console amd64 =============== from another mashine: telnet acer 21 --> kernel panic telnet acer 22 --> kernel panic ping acer --> no kernel panic - 1000 ping correct and success From owner-freebsd-current@FreeBSD.ORG Sat Jul 28 18:55:27 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 4E84416A419 for ; Sat, 28 Jul 2007 18:55:27 +0000 (UTC) (envelope-from admin@lissyara.su) Received: from smtp.qwerty.ru (smtp.qwerty.ru [87.240.2.134]) by mx1.freebsd.org (Postfix) with ESMTP id EE53213C45E for ; Sat, 28 Jul 2007 18:55:26 +0000 (UTC) (envelope-from admin@lissyara.su) Received: from ussr.lissyara.int.otradno.ru (unknown [10.21.64.215]) by smtp.qwerty.ru (Spam Firewall) with ESMTP id D07E61BD7BA0 for ; Sat, 28 Jul 2007 22:55:25 +0400 (MSD) Message-ID: <46AB911D.7040104@lissyara.su> Date: Sat, 28 Jul 2007 22:55:25 +0400 From: Alex Keda User-Agent: Thunderbird 2.0.0.5 (X11/20070721) MIME-Version: 1.0 To: freebsd-current@FreeBSD.org References: <46AB8DEE.6040008@lissyara.su> In-Reply-To: <46AB8DEE.6040008@lissyara.su> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 8bit Cc: Subject: Re: kernel panic on ssh connect X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Jul 2007 18:55:27 -0000 Alex Keda ÐÉÛÅÔ: > I update today and when connect to my machine ssh I have kernel panic > ================ > panic: syncache_add: unexpected tcp flag > cpuid = 0 > KDB: enter: panic > [thread pid 32 tid 100037] > stopped at kdb_enter+0x31: leave > =============== > after input bt: > =============== > tracing pid 32 tid 100037 td 0ÞÁÁÁÁÁÁ0001303680 > kdb_enter() at kdb_enter+0x31 > panic() at panic+0x173 > syncache_add() at syncache_add+0x8ae > tcp_input() at tcp_input+0x98a > ip_input() at ip_input+0xc0 > ether_demux() at ether_demux+0x1d9 > ether_input() at ether_input+0x1d6 > ieee80211_input() at ieee80211_input+0x6f8 > ath_rx_proc() at ath_rx_proc+0x3cc > taskqueue_run() at taskqueue_run+0x94 > taskqueue_thread_loop() at taskqueue_thread_loop+0x53 > fork_exit() at fork_exit+0x12a > fork_trampoline() at fork_trampoline+0xe > --- trap 0, rip = 0Â rsp = 0xffffffffa872ad30, rbp = 0 --- > =============== > uname -a > FreeBSD acer.lissyara.int.otradno.ru 7.0-CURRENT FreeBSD 7.0-CURRENT > #0: Sat Jul 28 21:46:52 MSD 2007 > root@acer.lissyara.int.otradno.ru:/usr/obj/usr/src/sys/main-color-console > amd64 > > =============== > from another mashine: > telnet acer 21 --> kernel panic > telnet acer 22 --> kernel panic > ping acer --> no kernel panic - 1000 ping correct and success P.S. Connect from this host to another - successful and no kernel panic From owner-freebsd-current@FreeBSD.ORG Sat Jul 28 19:10: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 D8E9316A49E; Sat, 28 Jul 2007 19:10:31 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 8B4B913C478; Sat, 28 Jul 2007 19:10:31 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.8/8.13.8) with ESMTP id l6SJAVBx062925; Sat, 28 Jul 2007 15:10:31 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.1/8.14.1) with ESMTP id l6SJAV22068042; Sat, 28 Jul 2007 15:10:31 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id E691073068; Sat, 28 Jul 2007 15:10:30 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070728191030.E691073068@freebsd-current.sentex.ca> Date: Sat, 28 Jul 2007 15:10:30 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.91.1, clamav-milter version 0.91.1 on news X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on sparc64/sun4v X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jul 2007 19:10:32 -0000 TB --- 2007-07-28 17:41:21 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-07-28 17:41:21 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2007-07-28 17:41:21 - cleaning the object tree TB --- 2007-07-28 17:41:39 - checking out the source tree TB --- 2007-07-28 17:41:39 - cd /tinderbox/HEAD/sparc64/sun4v TB --- 2007-07-28 17:41:39 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-07-28 17:49:13 - building world (CFLAGS=-O2 -pipe) TB --- 2007-07-28 17:49:13 - cd /src TB --- 2007-07-28 17:49:13 - /usr/bin/make -B buildworld >>> World build started on Sat Jul 28 17:49:14 UTC 2007 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat Jul 28 18:57:51 UTC 2007 TB --- 2007-07-28 18:57:51 - generating LINT kernel config TB --- 2007-07-28 18:57:51 - cd /src/sys/sun4v/conf TB --- 2007-07-28 18:57:51 - /usr/bin/make -B LINT TB --- 2007-07-28 18:57:52 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-07-28 18:57:52 - cd /src TB --- 2007-07-28 18:57:52 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Jul 28 18:57:52 UTC 2007 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] :> hack.c cc -shared -nostdlib hack.c -o hack.So rm -f hack.c MAKE=/usr/bin/make sh /src/sys/conf/newvers.sh LINT cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror vers.c linking kernel tcp_input.o(.data+0x0): multiple definition of `tcpstates' tcp_debug.o(.data+0xc8): first defined here *** Error code 1 Stop in /obj/sun4v/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-07-28 19:10:30 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-07-28 19:10:30 - ERROR: failed to build lint kernel TB --- 2007-07-28 19:10:30 - tinderbox aborted TB --- 0.59 user 2.24 system 5349.66 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From owner-freebsd-current@FreeBSD.ORG Sat Jul 28 20:16:22 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 5119C16A419 for ; Sat, 28 Jul 2007 20:16:22 +0000 (UTC) (envelope-from silby@silby.com) Received: from relay03.pair.com (relay03.pair.com [209.68.5.17]) by mx1.freebsd.org (Postfix) with SMTP id 0F74113C465 for ; Sat, 28 Jul 2007 20:16:21 +0000 (UTC) (envelope-from silby@silby.com) Received: (qmail 22635 invoked from network); 28 Jul 2007 20:16:20 -0000 Received: from 209.68.2.70 (HELO localhost) (209.68.2.70) by relay03.pair.com with SMTP; 28 Jul 2007 20:16:20 -0000 X-pair-Authenticated: 209.68.2.70 Date: Sat, 28 Jul 2007 15:16:20 -0500 (CDT) From: Mike Silbersack To: Alex Keda Message-ID: <20070728151437.R3202@odysseus.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: current@freebsd.org Subject: Fixed: kernel panic on ssh connect X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Jul 2007 20:16:22 -0000 Rev 1.127 of tcp_syncache.c (which I just committed) should fix this: panic: syncache_add: unexpected tcp flag cpuid = 0 KDB: enter: panic [thread pid 32 tid 100037] stopped at kdb_enter+0x31: leave Please csup and see if that does the trick for you. Thanks, Mike "Silby" Silbersack From owner-freebsd-current@FreeBSD.ORG Sat Jul 28 21:26: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 4578416A418; Sat, 28 Jul 2007 21:26:39 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id E3EA813C46C; Sat, 28 Jul 2007 21:26:38 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.14.1/8.13.8) with ESMTP id l6SLQc3j079740; Sat, 28 Jul 2007 17:26:38 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.1/8.14.1) with ESMTP id l6SLQc8J002045; Sat, 28 Jul 2007 17:26:38 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id D8A3373068; Sat, 28 Jul 2007 17:26:37 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070728212637.D8A3373068@freebsd-current.sentex.ca> Date: Sat, 28 Jul 2007 17:26:37 -0400 (EDT) X-Virus-Scanned: ClamAV version devel-20070102, clamav-milter version devel-111206 on clamscanner5 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jul 2007 21:26:39 -0000 TB --- 2007-07-28 19:15:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-07-28 19:15:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2007-07-28 19:15:00 - cleaning the object tree TB --- 2007-07-28 19:15:42 - checking out the source tree TB --- 2007-07-28 19:15:42 - cd /tinderbox/HEAD/amd64/amd64 TB --- 2007-07-28 19:15:42 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-07-28 19:25:40 - building world (CFLAGS=-O2 -pipe) TB --- 2007-07-28 19:25:40 - cd /src TB --- 2007-07-28 19:25:40 - /usr/bin/make -B buildworld >>> World build started on Sat Jul 28 19:25:42 UTC 2007 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Sat Jul 28 21:11:04 UTC 2007 TB --- 2007-07-28 21:11:04 - generating LINT kernel config TB --- 2007-07-28 21:11:04 - cd /src/sys/amd64/conf TB --- 2007-07-28 21:11:04 - /usr/bin/make -B LINT TB --- 2007-07-28 21:11:04 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-07-28 21:11:04 - cd /src TB --- 2007-07-28 21:11:04 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Jul 28 21:11:04 UTC 2007 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] :> hack.c cc -shared -nostdlib hack.c -o hack.So rm -f hack.c MAKE=/usr/bin/make sh /src/sys/conf/newvers.sh LINT cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue vers.c linking kernel tcp_input.o(.data+0x0): multiple definition of `tcpstates' tcp_debug.o(.data+0xe0): first defined here *** Error code 1 Stop in /obj/amd64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-07-28 21:26:37 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-07-28 21:26:37 - ERROR: failed to build lint kernel TB --- 2007-07-28 21:26:37 - tinderbox aborted TB --- 1.01 user 3.64 system 7896.95 real http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Sat Jul 28 21:38:37 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 9DBF816A41B for ; Sat, 28 Jul 2007 21:38:37 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.174]) by mx1.freebsd.org (Postfix) with ESMTP id 199FE13C48D for ; Sat, 28 Jul 2007 21:38:36 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: by ug-out-1314.google.com with SMTP id o4so980684uge for ; Sat, 28 Jul 2007 14:38:36 -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=buZXsffvTT+N75af6rnNiBJFbYQt0BgmXdLvajSSut/FKXrf1bQAgBSftVnVj0+VYkXqQFOxX3iIFrs4T9aWoO+I7G0R+dKNwh8yl/WnNndyFcYPJH7Hih1KY5ZKuwQaSKU2zSjZiMvxh8TiRZckbFB5T6h5kZTA9YDmZX1OG1o= 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=WUusm7Cun81/Z+bGX6uN3adN79cuIBs/IdefdnpBzy9UDMt2n5b+mqIl2bXrlJWUb99qffadRqRCO4aqTOzs7n/kq3uOYBcs1s/TLprOTw5iEI8INrFy+uxf2Z/RWdCBOfhsTm0kLExSl40ocr8u5NBoN9dPHU7w4/DQoxm27RU= Received: by 10.78.123.5 with SMTP id v5mr1089688huc.1185658715953; Sat, 28 Jul 2007 14:38:35 -0700 (PDT) Received: by 10.78.162.18 with HTTP; Sat, 28 Jul 2007 14:38:35 -0700 (PDT) Message-ID: Date: Sat, 28 Jul 2007 14:38:35 -0700 From: "Kip Macy" To: "FreeBSD Current" , "FreeBSD Stable List" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: Cc: Subject: Fwd: call for ALTQ users X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Jul 2007 21:38:37 -0000 Expanding the net a bit. ---------- Forwarded message ---------- From: Kip Macy Date: Jul 28, 2007 2:03 PM Subject: call for ALTQ users To: freebsd-net I'm looking at extending ifnet to support multiple tx queues. It appears that this will inevitably interact with ALTQ. I don't know anyone using ALTQ so I need users to raise their hands to eventually test prospective changes. Thanks. -Kip From owner-freebsd-current@FreeBSD.ORG Sat Jul 28 21:54: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 DDE6A16A419; Sat, 28 Jul 2007 21:54:21 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 817B513C45A; Sat, 28 Jul 2007 21:54:21 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 213F92089; Sat, 28 Jul 2007 23:36:30 +0200 (CEST) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: 0.0/3.0 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on tim.des.no Received: from ds4.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id A13ED2085; Sat, 28 Jul 2007 23:36:29 +0200 (CEST) Received: by ds4.des.no (Postfix, from userid 1001) id 8A32A84445; Sat, 28 Jul 2007 23:36:29 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: deischen@freebsd.org References: Date: Sat, 28 Jul 2007 23:36:29 +0200 In-Reply-To: (Daniel Eischen's message of "Sat\, 28 Jul 2007 10\:19\:04 -0400 \(EDT\)") Message-ID: <86vec4dxcy.fsf@ds4.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: current@freebsd.org Subject: Re: TERM={xterm-r5,xterm-r6} behaving badly with man(1) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jul 2007 21:54:22 -0000 Daniel Eischen writes: > Sometime in the last few months, something changed (broke IMHO) when > using TERM=3Dxterm-r5 or TERM=3Dxterm-r6. I've been setting TERM=3Dxterm= -r5 > when logging in to my BSD boxes remotely from my Solaris boxes, so that > man(1) works. But after updating my relatively old (May?) -current > box, xterm-r5 and xterm-r6 no longer do the right thing when using > man. With TERM set to either one of those, man(1) will clear the > screen after it is done, leaving no trace of the man page behind. This is the *correct* behaviour. The termcap entry is supposed to reflect the capabilities of the terminal, not your personal preferences. If you don't like it, you can override it using the TERMCAP environment variable. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Sat Jul 28 22:16:49 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 4A3D716A417; Sat, 28 Jul 2007 22:16:49 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id E34DC13C4DA; Sat, 28 Jul 2007 22:16:48 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.14.1/8.13.8) with ESMTP id l6SMGmLM081360; Sat, 28 Jul 2007 18:16:48 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.1/8.14.1) with ESMTP id l6SMGm4G065873; Sat, 28 Jul 2007 18:16:48 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 442F473068; Sat, 28 Jul 2007 18:16:48 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070728221648.442F473068@freebsd-current.sentex.ca> Date: Sat, 28 Jul 2007 18:16:48 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.91.1, clamav-milter version 0.91.1 on clamscanner1 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jul 2007 22:16:49 -0000 TB --- 2007-07-28 20:37:41 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-07-28 20:37:41 - starting HEAD tinderbox run for i386/i386 TB --- 2007-07-28 20:37:41 - cleaning the object tree TB --- 2007-07-28 20:38:06 - checking out the source tree TB --- 2007-07-28 20:38:06 - cd /tinderbox/HEAD/i386/i386 TB --- 2007-07-28 20:38:06 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-07-28 20:45:45 - building world (CFLAGS=-O2 -pipe) TB --- 2007-07-28 20:45:45 - cd /src TB --- 2007-07-28 20:45:45 - /usr/bin/make -B buildworld >>> World build started on Sat Jul 28 20:45:46 UTC 2007 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat Jul 28 21:59:50 UTC 2007 TB --- 2007-07-28 21:59:50 - generating LINT kernel config TB --- 2007-07-28 21:59:50 - cd /src/sys/i386/conf TB --- 2007-07-28 21:59:50 - /usr/bin/make -B LINT TB --- 2007-07-28 21:59:51 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-07-28 21:59:51 - cd /src TB --- 2007-07-28 21:59:51 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Jul 28 21:59:51 UTC 2007 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] :> hack.c cc -shared -nostdlib hack.c -o hack.So rm -f hack.c MAKE=/usr/bin/make sh /src/sys/conf/newvers.sh LINT cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue vers.c linking kernel tcp_input.o(.data+0x0): multiple definition of `tcpstates' tcp_debug.o(.data+0x80): first defined here *** Error code 1 Stop in /obj/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-07-28 22:16:47 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-07-28 22:16:47 - ERROR: failed to build lint kernel TB --- 2007-07-28 22:16:47 - tinderbox aborted TB --- 0.77 user 1.95 system 5946.65 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Sat Jul 28 23:01:47 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 C7C8816A417; Sat, 28 Jul 2007 23:01:47 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 7F72A13C468; Sat, 28 Jul 2007 23:01:47 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.13.8/8.13.8) with ESMTP id l6SN1lt2070458; Sat, 28 Jul 2007 19:01:47 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.1/8.14.1) with ESMTP id l6SN1kWs084856; Sat, 28 Jul 2007 19:01:46 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id B86A973068; Sat, 28 Jul 2007 19:01:46 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070728230146.B86A973068@freebsd-current.sentex.ca> Date: Sat, 28 Jul 2007 19:01:46 -0400 (EDT) X-Virus-Scanned: ClamAV version devel-20070102, clamav-milter version devel-111206 on clamscanner1 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jul 2007 23:01:47 -0000 TB --- 2007-07-28 21:26:37 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-07-28 21:26:37 - starting HEAD tinderbox run for i386/pc98 TB --- 2007-07-28 21:26:37 - cleaning the object tree TB --- 2007-07-28 21:26:57 - checking out the source tree TB --- 2007-07-28 21:26:57 - cd /tinderbox/HEAD/i386/pc98 TB --- 2007-07-28 21:26:57 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-07-28 21:33:35 - building world (CFLAGS=-O2 -pipe) TB --- 2007-07-28 21:33:35 - cd /src TB --- 2007-07-28 21:33:35 - /usr/bin/make -B buildworld >>> World build started on Sat Jul 28 21:33:36 UTC 2007 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat Jul 28 22:47:18 UTC 2007 TB --- 2007-07-28 22:47:18 - generating LINT kernel config TB --- 2007-07-28 22:47:18 - cd /src/sys/pc98/conf TB --- 2007-07-28 22:47:18 - /usr/bin/make -B LINT TB --- 2007-07-28 22:47:18 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-07-28 22:47:18 - cd /src TB --- 2007-07-28 22:47:18 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Jul 28 22:47:19 UTC 2007 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] :> hack.c cc -shared -nostdlib hack.c -o hack.So rm -f hack.c MAKE=/usr/bin/make sh /src/sys/conf/newvers.sh LINT cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -pg -mprofiler-epilogue vers.c linking kernel tcp_input.o(.data+0x0): multiple definition of `tcpstates' tcp_debug.o(.data+0x80): first defined here *** Error code 1 Stop in /obj/pc98/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-07-28 23:01:46 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-07-28 23:01:46 - ERROR: failed to build lint kernel TB --- 2007-07-28 23:01:46 - tinderbox aborted TB --- 0.61 user 2.15 system 5708.47 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Sat Jul 28 23:53:38 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 64E2E16A419 for ; Sat, 28 Jul 2007 23:53:38 +0000 (UTC) (envelope-from kip.macy@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 C9CD313C491 for ; Sat, 28 Jul 2007 23:53:37 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: by ug-out-1314.google.com with SMTP id o4so991816uge for ; Sat, 28 Jul 2007 16:53:36 -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=ByYClX0OPBbEvebjNfk3iU2tSVX6d9IKodlP0uEbAHGV+/fgsYvenWskGrZ91gnSQTrzedtlIOn+MoBpcIpWeAAmz0Lp1l2g6l/55sIGDbYRTc47TLR3c2yo1h1midi5y8HCPDOA4PpoKHbEB1Ksq5Z79mTyzjh30AUnGFOY0cM= 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=axXfte1ftrjA8jjkq704eU5OQTN0pVtdXEC5ReXXDLuP/bY6aMRtVcYVQeMwMHqLRfgWuNiTx+ax6eqCASaW9236TI0aHYkIgEnYCUhjgFHr7ZSaIXC99KgN6cAUAQKPq8Z9A8CziTXlqx2uJ4JSFK7ZbGK9WHsB9oXmLwB01dU= Received: by 10.78.132.2 with SMTP id f2mr1114189hud.1185666816445; Sat, 28 Jul 2007 16:53:36 -0700 (PDT) Received: by 10.78.162.18 with HTTP; Sat, 28 Jul 2007 16:53:36 -0700 (PDT) Message-ID: Date: Sat, 28 Jul 2007 16:53:36 -0700 From: "Kip Macy" To: "Alexey Karagodov" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: Cc: FreeBSD Current , FreeBSD Stable List Subject: Re: call for ALTQ users X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Jul 2007 23:53:38 -0000 On 7/28/07, Alexey Karagodov wrote: > how can i help you? I'd like to understand how ALTQ is being used currently. Are there users using it on high bandwidth interfaces? As currently implemented it would force serialization, increased locking overhead, and potentially loss of locality on cards that support multiple queues (i.e. most 10GigE cards). -Kip > > 2007/7/29, Kip Macy : > > > > Expanding the net a bit. > > > > ---------- Forwarded message ---------- > > From: Kip Macy > > Date: Jul 28, 2007 2:03 PM > > Subject: call for ALTQ users > > To: freebsd-net > > > > > > I'm looking at extending ifnet to support multiple tx queues. It > > appears that this will inevitably interact with ALTQ. I don't know > > anyone using ALTQ so I need users to raise their hands to eventually > > test prospective changes. > > > > Thanks. > > > > -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" > > > >