From owner-freebsd-current@FreeBSD.ORG Sun Mar 11 00:01:57 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2CE6616A402 for ; Sun, 11 Mar 2007 00:01:57 +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 86E2613C428 for ; Sun, 11 Mar 2007 00:01:50 +0000 (UTC) (envelope-from tataz@tataz.chchile.org) Received: from tatooine.tataz.chchile.org (tataz.chchile.org [82.233.239.98]) by smtp5-g19.free.fr (Postfix) with ESMTP id A1ECE7D7C for ; Sun, 11 Mar 2007 01:01:49 +0100 (CET) Received: from obiwan.tataz.chchile.org (unknown [192.168.1.25]) by tatooine.tataz.chchile.org (Postfix) with ESMTP id 2197A9CA60 for ; Sun, 11 Mar 2007 00:01:49 +0000 (UTC) Received: by obiwan.tataz.chchile.org (Postfix, from userid 1000) id 02B6D4063; Sun, 11 Mar 2007 01:01:48 +0100 (CET) Date: Sun, 11 Mar 2007 01:01:48 +0100 From: Jeremie Le Hen To: freebsd-current@FreeBSD.org Message-ID: <20070311000148.GF2887@obiwan.tataz.chchile.org> 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: Cannot burn DVD with IDE recorder X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Mar 2007 00:01:57 -0000 Hi! AFAIK, I had formerly been able to write CD (with a -CURRENT as of late october or november IIRC). I've upgraded my kernel since then: FreeBSD 7.0-CURRENT #26: Sat Mar 3 23:46:16 UTC 2007 Unfortunately, I cannot write a DVD. % $ mkisofs -J -R DVD1/ | sudo burncd -f /dev/acd0 -v -e -s 2 data - fixate % adding type 0x08 file - size 64 KB 0 blocks % burncd: ioctl(CDRIOCNEXTWRITEABLEADDR): Input/output error Kernel output: % $ dmesg | grep ^acd % acd0: DVDR at ata0-slave UDMA33 % acd0: FAILURE - READ_TRACK_INFO ILLEGAL REQUEST asc=0x24 ascq=0x00 % $ sudo atacontrol list % ATA channel 0: % Master: ad0 ATA/ATAPI revision 6 % Slave: acd0 ATA/ATAPI revision 6 % ATA channel 1: % Master: no device present % Slave: no device present Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-current@FreeBSD.ORG Sun Mar 11 00:36:44 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1647416A402 for ; Sun, 11 Mar 2007 00:36:44 +0000 (UTC) (envelope-from grog@lemis.com) Received: from ext-gw.lemis.com (ext-gw.lemis.com [150.101.14.10]) by mx1.freebsd.org (Postfix) with ESMTP id B2FD513C4DA for ; Sun, 11 Mar 2007 00:36:43 +0000 (UTC) (envelope-from grog@lemis.com) Received: from wantadilla.lemis.com (wantadilla.lemis.com [192.109.197.135]) by ext-gw.lemis.com (Postfix) with ESMTP id D8F67133D96; Sun, 11 Mar 2007 10:46:31 +1030 (CST) Received: by wantadilla.lemis.com (Postfix, from userid 1004) id C78ED1A9CC0; Sun, 11 Mar 2007 10:46:31 +1030 (CST) Date: Sun, 11 Mar 2007 10:46:31 +1030 From: Greg 'groggy' Lehey To: Jeremie Le Hen Message-ID: <20070311001631.GO1189@wantadilla.lemis.com> References: <20070311000148.GF2887@obiwan.tataz.chchile.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="rQ7Ovc9/RBrrr0/1" Content-Disposition: inline In-Reply-To: <20070311000148.GF2887@obiwan.tataz.chchile.org> User-Agent: Mutt/1.4.2.1i Organization: The FreeBSD Project Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 VoIP: sip:0871270137@sip.internode.on.net WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 9A1B 8202 BCCE B846 F92F 09AC 22E6 F290 507A 4223 Cc: freebsd-current@FreeBSD.org Subject: Re: Cannot burn DVD with IDE recorder X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Mar 2007 00:36:44 -0000 --rQ7Ovc9/RBrrr0/1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sunday, 11 March 2007 at 1:01:48 +0100, Jeremie Le Hen wrote: > Hi! > > AFAIK, I had formerly been able to write CD (with a -CURRENT as of > late october or november IIRC). I've upgraded my kernel since then: > > FreeBSD 7.0-CURRENT #26: Sat Mar 3 23:46:16 UTC 2007 > > Unfortunately, I cannot write a DVD. Not the answer you're looking for, but I've always used atapicam for this. Haven't tried it on -CURRENT recently, though. Greg -- See complete headers for address and phone numbers. --rQ7Ovc9/RBrrr0/1 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (FreeBSD) iD8DBQFF80pfIubykFB6QiMRAioPAJ9zWkn8rrhwmi+OpTzcsE9MCfFzjgCgg8S0 tfpcHW0CzwKPoVGQi46e0Qo= =2SrK -----END PGP SIGNATURE----- --rQ7Ovc9/RBrrr0/1-- From owner-freebsd-current@FreeBSD.ORG Sun Mar 11 04:40:34 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 77A7316A403 for ; Sun, 11 Mar 2007 04:40:34 +0000 (UTC) (envelope-from tillman@seekingfire.com) Received: from mail.seekingfire.com (thoth.seekingfire.com [24.89.83.9]) by mx1.freebsd.org (Postfix) with ESMTP id 2E2B613C441 for ; Sun, 11 Mar 2007 04:40:34 +0000 (UTC) (envelope-from tillman@seekingfire.com) Received: by mail.seekingfire.com (Postfix, from userid 500) id C80CD39850; Sat, 10 Mar 2007 22:40:33 -0600 (CST) Date: Sat, 10 Mar 2007 22:40:33 -0600 From: Tillman Hodgson To: freebsd-current@freebsd.org Message-ID: <20070311044033.GB1256@seekingfire.com> References: <20070308125927.GA1265@seekingfire.com> <20070308204041.GA55240@xor.obsecurity.org> <20070310153206.GF1230@seekingfire.com> <3bbf2fe10703100749h14e9b075wb6d730ed7c9189f8@mail.gmail.com> <20070310161423.GA1256@seekingfire.com> <20070310193946.GA96514@xor.obsecurity.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070310193946.GA96514@xor.obsecurity.org> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . X-GPG-Key-ID: 828AFC7B X-GPG-Fingerprint: 5584 14BA C9EB 1524 0E68 F543 0F0A 7FBC 828A FC7B X-GPG-Key: http://www.seekingfire.com/personal/gpg_key.asc X-Urban-Legend: There is lots of hidden information in headers X-Tillman-rules: yes he does User-Agent: Mutt/1.5.14 (2007-02-12) Subject: Re: Experiencing hangs on SMP box with no console messages given for clues. Details inside. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Mar 2007 04:40:34 -0000 On Sat, Mar 10, 2007 at 02:39:47PM -0500, Kris Kennaway wrote: > On Sat, Mar 10, 2007 at 10:14:23AM -0600, Tillman Hodgson wrote: > > > If I'm understanding what I'm reading, this isn't all that helpful > > because it's just saying that I broke into the kernel debugger and then > > issued a manual panic (which is true, that's how I got the core). Is > > there a way to obtain information on what was happening before I broke > > into the debugger? > > Well you really needed to investigate some things in DDB before > rebooting, e.g. the lock states. I thought this was described in the > developers handbook - did you look for it? Kris, I greatly respect your work and I'm glad to have you involved in the thread. I'm familiar with your email style and while I could be reading you wrong I'm detecting curtness and a bit of hostility in your posts to this thread. I sincerely apologize for being inexperienced at this. I'm a fast learner and I've been involved with FreeBSD for a some time, but that obviously can't compensate for my lack of knowledge in this area. In response to your question, I've already posted to this thread the documents that I looked for and was following and the Developers Handbook wasn't among them. I'll read over it now, of course. Please keep in mind that it has been 56 hours between when I first posted and this post from you. If I'm inexperienced and followed the wrong documentation, great -- someone with kernel debugging experience could point that out to me and I can get to work getting the information the developers need. I don't think it's reasonable to expect someone to leave a machine in the debugger for 56 hours before even getting a pointer to the correct docs though, especially when the problem re-occurs somewhat regularly. Now that I have the documentation that you'd like me to follow (I assume it's section 11.5 and especially 11.9 of the Developers Handbook), it's easiest to simply wait for it to hang again. Shouldn't take more than a day or two to get the info requested in 11.9. I suggest that the doc team be brought into the loop so that the FAQ 5.8 and 18.14 can be updated to point to the correct documentation. This should make it easier for other folks who are looking for the same information, especially since those FAQ entries are both official documentation and one of the top Google hits. -T -- If the world was without any natural evil and suffering we wouldn't have the opportunity, or nearly as much opportunity, to show courage, patience and sympathy. -- Richard Swinburne, _The Philosophers' Magazine_ From owner-freebsd-current@FreeBSD.ORG Sun Mar 11 04:43:01 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DC28F16A404 for ; Sun, 11 Mar 2007 04:43:01 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outA.internet-mail-service.net (outA.internet-mail-service.net [216.240.47.224]) by mx1.freebsd.org (Postfix) with ESMTP id BF1B613C4A8 for ; Sun, 11 Mar 2007 04:43:01 +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; Sat, 10 Mar 2007 20:16:23 -0800 Received: from [192.168.2.5] (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id BB629125ADD for ; Sat, 10 Mar 2007 20:43:00 -0800 (PST) Message-ID: <45F388D4.2080900@elischer.org> Date: Sat, 10 Mar 2007 20:43:00 -0800 From: Julian Elischer User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: netstat wierdness? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Mar 2007 04:43:02 -0000 just did make buildworld buildkernel installkernel installworld mergemaster reboot.. netstat now doesn't seem to be able to show open tcp sessions: I'm ssh'd into this machien so ther eIS at least one tcp session. root@trafmon1:netstat Active UNIX domain sockets Address Type Recv-Q Send-Q Inode Conn Refs Nextref Addr 0 #0 131073 0 c6420ae0 0 0 0 0 #0 131073 0 c6505d98 0 0 0 0 #0 2 0 0 c6536410 0 c65371a0 0 #0 2 0 0 c6536410 0 c65350d0 0 #0 2 0 0 c6536410 0 c6513c30 0 #0 2 0 0 c6536410 0 c65375b0 0 #0 2 0 0 c6536410 0 0 0 #0 2 0 c641f828 0 0 0 0 #0 2 0 c641f984 0 0 0 0 #0 2 0 c6429984 0 c65131a0 0 0 #0 2 0 c642b000 0 0 0 root@trafmon1:netstat -ptcp -aA root@trafmon1: this is on 2 different machines anyone else seeing this? From owner-freebsd-current@FreeBSD.ORG Sun Mar 11 04:47:22 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6AFB616A402 for ; Sun, 11 Mar 2007 04:47:22 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outM.internet-mail-service.net (outM.internet-mail-service.net [216.240.47.236]) by mx1.freebsd.org (Postfix) with ESMTP id 4DF2513C48D for ; Sun, 11 Mar 2007 04:47:22 +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; Sat, 10 Mar 2007 20:20:43 -0800 Received: from [192.168.2.5] (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id BB764125AF7; Sat, 10 Mar 2007 20:47:20 -0800 (PST) Message-ID: <45F389D8.4050505@elischer.org> Date: Sat, 10 Mar 2007 20:47:20 -0800 From: Julian Elischer User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: Julian Elischer References: <45F388D4.2080900@elischer.org> In-Reply-To: <45F388D4.2080900@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current Subject: Re: netstat wierdness? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Mar 2007 04:47:22 -0000 Julian Elischer wrote: > just did make buildworld buildkernel installkernel installworld mergemaster > reboot.. > > netstat now doesn't seem to be able to show open tcp sessions: > > I'm ssh'd into this machien so ther eIS at least one tcp session. > > > root@trafmon1:netstat > Active UNIX domain sockets > Address Type Recv-Q Send-Q Inode Conn Refs Nextref Addr > 0 #0 131073 0 c6420ae0 0 0 0 0 > #0 131073 0 c6505d98 0 0 0 0 > #0 2 0 0 c6536410 0 c65371a0 > 0 #0 2 0 0 c6536410 0 c65350d0 > 0 #0 2 0 0 c6536410 0 c6513c30 > 0 #0 2 0 0 c6536410 0 c65375b0 > 0 #0 2 0 0 c6536410 0 0 > 0 #0 2 0 c641f828 0 0 0 0 > #0 2 0 c641f984 0 0 0 0 > #0 2 0 c6429984 0 c65131a0 0 0 > #0 2 0 c642b000 0 0 0 > root@trafmon1:netstat -ptcp -aA > root@trafmon1: > > this is on 2 different machines > > anyone else seeing this? sockstat now also shows: root@trafmon1:sockstat sockstat: struct xtcpcb size mismatch sockstat: struct xinpcb size mismatch sockstat: struct xunpcb size mismatch sockstat: struct xunpcb size mismatch I'm going to completely zap /usr/obj and start from scratch but thought I'd ask if others are seeing this? > > > _______________________________________________ > 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 Mar 11 05:04:36 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AB8A516A400 for ; Sun, 11 Mar 2007 05:04:36 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.189]) by mx1.freebsd.org (Postfix) with ESMTP id 3921513C441 for ; Sun, 11 Mar 2007 05:04:36 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by nf-out-0910.google.com with SMTP id k27so1470685nfc for ; Sat, 10 Mar 2007 21:04:35 -0800 (PST) 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=Ai9Q0dQDWI/KQyXEKNXy/KDu9R6dWTmfY7fUEnukJ7liJ9Q+K14cgcNEWT30yopApewLmFRFLKU5LfJTnQF+N0x8w+UVeZOSoXHns/Fq0XQKg+ZCBdNw75N6K7N4+U/P8qfw5FM9uBdWMQ2+mI+r5FMqhYKl0cGek4Jda0qXOoQ= 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=lt3JV0QFgwfQnp8nP/oIdQjhUm9W4HWJo5bim2Muofb/qf6YvY7g8TVPK4ecdb1NA2uNkcycvkvZamLX3Kt7Irt6kkcPbtaLVWkfw/JpnALX02qYa8HZSxA+y+z6xUZSMQiqMtWfqwL9mcCUOOr58FCWjC1ko7upNeAPx82yPOI= Received: by 10.114.201.1 with SMTP id y1mr700431waf.1173589474319; Sat, 10 Mar 2007 21:04:34 -0800 (PST) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTP id n22sm13096966pof.2007.03.10.21.04.32; Sat, 10 Mar 2007 21:04:33 -0800 (PST) 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 l2B56R3w080224 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 11 Mar 2007 14:06:27 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id l2B56RNe080223; Sun, 11 Mar 2007 14:06:27 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Sun, 11 Mar 2007 14:06:27 +0900 From: Pyun YongHyeon To: "Mr. Darren" Message-ID: <20070311050627.GC79728@cdnetworks.co.kr> References: <20070310074734.GC70613@cdnetworks.co.kr> <917080.87242.qm@web34701.mail.mud.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <917080.87242.qm@web34701.mail.mud.yahoo.com> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@freebsd.org Subject: Re: yongari nfe problems 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: Sun, 11 Mar 2007 05:04:36 -0000 On Sat, Mar 10, 2007 at 07:13:12AM -0800, Mr. Darren wrote: > > --- Pyun YongHyeon wrote: > > > On Fri, Mar 09, 2007 at 10:21:45PM -0800, Mr. Darren > > wrote: > > > > > > --- Pyun YongHyeon wrote: > > > > > > > On Fri, Mar 09, 2007 at 08:08:56PM +0900, To > > Mr. > > > > Darren wrote: > > > > > On Thu, Mar 08, 2007 at 04:33:36PM -0800, > > Mr. > > > > Darren wrote: > > > > > > I tried the following overhauled nfe > > drivers > > > > after no > > > > > > success in getting nfe to work with my > > > > hardware. > > > > > > > > > > > http://people.freebsd.org/~yongari/nfe/if_nfe.c > > > > > > > > > > > > > > > > > > > > > > > > > http://people.freebsd.org/~yongari/nfe/if_nfereg.h > > > > > > > > > > > > > > > > > > > > > > > > > http://people.freebsd.org/~yongari/nfe/if_nfevar.h > > > > > > > > > > > > It still doesn't work, but I have a new > > set of > > > > errors. > > > > > > > > > > > > nfe0: > Adapter> > > > > port > > > > > > 0xb000-0xb007 mem > > > > > > > > > > > > > > > > 0xfe02a000-0xfe02afff,0xfe029000-0xfe0290ff,0xfe028000-0xfe02800f > > > > > > irq 10 at device 16.0 on pci0 > > > > > > nfe0: Ethernet address: 00:15:f2:f4:af:5e > > > > > > miibus1: on nfe0 > > > > > > nfe0: [ITHREAD] > > > > > > nfe1: > Adapter> > > > > port > > > > > > 0xac00-0xac07 mem > > > > > > > > > > > > > > > > 0xfe027000-0xfe027fff,0xfe026000-0xfe0260ff,0xfe025000-0xfe02500f > > > > > > irq 11 at device 17.0 on pci0 > > > > > > nfe1: Ethernet address: 00:15:f2:f4:af:5f > > > > > > miibus2: on nfe1 > > > > > > nfe1: [ITHREAD] > > > > > > nfe0: link state changed to DOWN > > > > > > nfe0: link state changed to UP > > > > > > nfe0: watchdog timeout (missed Tx > > interrupts) > > > > -- > > > > > > recovering > > > > > > nfe0: watchdog timeout (missed Tx > > interrupts) > > > > -- > > > > > > recovering > > > > > > > > > > > > > > > > According to Shigeaki Tagashira'page nForce > > 590 > > > > is supported by > > > > > nfe(4). ATM I have no idea why it shows > > watchdog > > > > timeout errors. > > > > > Btw, I don't see what PHY driver was > > attached in > > > > your message. > > > > > (You can check it with dmesg(8) and normally > > it > > > > would pick up > > > > > e1000phy(4).) > > > > > > > > > > > > > Oops, I think I've posted wrong version. > > > > Please re-fetch and try again. > > > > > > > > > > > > > > > > the missing tx interrupts were made while > > > > trying > > > > > > /sbin/dhclient nfe0 > > > > > > > > > > > > My motherboard is the ASUS crosshair > > NVIDIA > > > > nForce 590 > > > > > > FreeBSD DARREN 7.0-CURRENT FreeBSD > > 7.0-CURRENT > > > > #12: > > > > > > Thu Mar 8 16:57:38 UTC 2007 > > > > > > root@DARREN:/usr/obj/usr/src/sys/DARREN > > amd64 > > > > > > the cvsup this kernel was compiled with > > is > > > > less than 1 > > > > > > week old. > > > > > > > > > > > > -Darren > > > > > -- > > > > > Regards, > > > > > Pyun YongHyeon > > > > > > > > -- > > > > Regards, > > > > Pyun YongHyeon > > > > > > > > > > > > > e1000phy0: PHY 1 on > > > miibus1 > > > e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, > > > 100baseTX-FDX, 1000baseTX-FDX, auto > > > e1000phy1: PHY 1 on > > > miibus2 > > > e1000phy1: 10baseT, 10baseT-FDX, 100baseTX, > > > 100baseTX-FDX, 1000baseTX-FDX, auto > > > > > > same problem with the new driver downloaded from > > > http://people.freebsd.org/~yongari/nfe/ . again, > > > while /sbin/dhclient nfe0 while in communication > > to my > > > router. > > > > > > nfe0: link state changed to DOWN > > > nfe0: link state changed to UP > > > nfe0: watchdog timeout (missed Tx interrupts) -- > > > recovering > > > nfe0: watchdog timeout (missed Tx interrupts) -- > > > recovering > > > nfe0: watchdog timeout (missed Tx interrupts) -- > > > recovering > > > nfe0: watchdog timeout (missed Tx interrupts) -- > > > recovering > > > nfe0: watchdog timeout (missed Tx interrupts) -- > > > recovering > > > > > > > Before starting dhclient(8) would you run 'ifconfig > > up nfe0' and > > check media status? Does it reports correct media > > speed/duplex > > settings? > > > > -- > > Regards, > > Pyun YongHyeon > > _______________________________________________ > > 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" > > > ran ifconfig nfe0 up, the media is correct. > media: Ethernet autoselect (100baseTX > ) > attempted /sbin/dhclient nfe0 with the same results as > before. > Did stock nfe(4) work on MCP55? (I'm not interested in how nve(4) works on MCP55.) I'm afraid MCP55 requires different programming. Searching archives for Linux forcedeth driver also reveals issues on MCP55 which is exactly the same issue I think. I'll let you know if I find a clue but it's hard to fix due to lack of MCP55 hardware and documentation. -- Regards, Pyun YongHyeon From owner-freebsd-current@FreeBSD.ORG Sun Mar 11 06:26:39 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F031716A400 for ; Sun, 11 Mar 2007 06:26:38 +0000 (UTC) (envelope-from tillman@seekingfire.com) Received: from mail.seekingfire.com (thoth.seekingfire.com [24.89.83.9]) by mx1.freebsd.org (Postfix) with ESMTP id BF9EE13C491 for ; Sun, 11 Mar 2007 06:26:37 +0000 (UTC) (envelope-from tillman@seekingfire.com) Received: by mail.seekingfire.com (Postfix, from userid 500) id 1B9263982C; Sun, 11 Mar 2007 00:26:38 -0600 (CST) Date: Sun, 11 Mar 2007 00:26:37 -0600 From: Tillman Hodgson To: freebsd-current@freebsd.org Message-ID: <20070311062637.GA1256@seekingfire.com> References: <20070308125927.GA1265@seekingfire.com> <20070308204041.GA55240@xor.obsecurity.org> <20070310153206.GF1230@seekingfire.com> <3bbf2fe10703100749h14e9b075wb6d730ed7c9189f8@mail.gmail.com> <20070310161423.GA1256@seekingfire.com> <20070310193946.GA96514@xor.obsecurity.org> <20070311044033.GB1256@seekingfire.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070311044033.GB1256@seekingfire.com> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . X-GPG-Key-ID: 828AFC7B X-GPG-Fingerprint: 5584 14BA C9EB 1524 0E68 F543 0F0A 7FBC 828A FC7B X-GPG-Key: http://www.seekingfire.com/personal/gpg_key.asc X-Urban-Legend: There is lots of hidden information in headers X-Tillman-rules: yes he does User-Agent: Mutt/1.5.14 (2007-02-12) Subject: Re: Experiencing hangs on SMP box with no console messages given for clues. Details inside. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Mar 2007 06:26:39 -0000 On Sat, Mar 10, 2007 at 10:40:33PM -0600, Tillman Hodgson wrote: > Shouldn't take more than a day or two to get the info requested in > 11.9. As it turns out, a few hours. After capturing the information below I ran `panic`. While booting, the following lock messages came up -- I thought it might be related so I'll post it here: ... Starting spamd. lock order reversal: 1st 0xc44d8c44 pf task mtx (pf task mtx) @ /usr/src/sys/modules/pf/../../contrib/pf/net/pf.c:6414 2nd 0xc0a9df6c tcp (tcp) @ /usr/src/sys/modules/pf/../../contrib/pf/net/pf.c:2760 KDB: stack backtrace: db_trace_self_wrapper(c094da94) at db_trace_self_wrapper+0x25 kdb_backtrace(0,ffffffff,c0a5d7d8,c0a5f330,c09f6c04,...) at kdb_backtrace+0x29 witness_checkorder(c0a9df6c,9,c44d5e24,ac8) at witness_checkorder+0x586 _mtx_lock_flags(c0a9df6c,0,c44d5e24,ac8,c0a9df6c,...) at _mtx_lock_flags+0x84 pf_socket_lookup(e466da84,e466da88,1,e466db40,0,...) at pf_socket_lookup+0x1d3 pf_test_tcp(e466daf0,e466dae8,1,c4505d00,c4467700,...) at pf_test_tcp+0x11e6 pf_test(1,c4098800,e466dbdc,0,0,...) at pf_test+0xae3 pf_check_in(0,e466dbdc,c4098800,1,0) at pf_check_in+0x37 pfil_run_hooks(c0a9db40,e466dc2c,c4098800,1,0) at pfil_run_hooks+0x7f ip_input(c4467700) at ip_input+0x232 netisr_dispatch(2,c4467700,0,c4098800,c44a0800,...) at netisr_dispatch+0x58 ether_demux(c4098800,c4467700,c4037000,c44a1002,e466dca0,...) at ether_demux+0x28a ether_input(c4098800,c4467700,c4037014,0,c092325d,...) at ether_input+0x202 fxp_intr_body(c4037000,c4098800,40,ffffffff) at fxp_intr_body+0x1a0 fxp_intr(c4037000) at fxp_intr+0x95 ithread_execute_handlers(c40a0240,c3f46900) at ithread_execute_handlers+0x11e ithread_loop(c40433a0,e466dd38) at ithread_loop+0x67 fork_exit(c06adf00,c40433a0,e466dd38) at fork_exit+0xac fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe466dd70, ebp = 0 --- Starting courier_authdaemond. ... And here's the section 11.9 information from the debugger (via serial console cut 'n paste): telnet> send brk KDB: enter: Line break on console [thread pid 11 tid 100005 ] Stopped at kdb_enter+0x2b: nop db> where Tracing pid 11 tid 100005 td 0xc3eff6c0 kdb_enter(c093cb3b) at kdb_enter+0x2b siointr1(c40b4000,c0abdfac,0,c096e56b,56e,...) at siointr1+0xce siointr(c40b4000) at siointr+0x21 intr_execute_handlers(c3ef4cc8,e2986c94,4,e2986cd4,c08ab2c4,...) at intr_execute_handlers+0xe1 lapic_handle_intr(36,e2986c94) at lapic_handle_intr+0x2f Xapic_isr1() at Xapic_isr1+0x34 --- interrupt, eip = 0xc0c000b5, esp = 0xe2986cd4, ebp = 0xe2986cd4 --- acpi_cpu_c1(c0a4ea90,c06d85a8,e2986cf4,c06d85a8,c06d85a8,...) at acpi_cpu_c1+0x5 acpi_cpu_idle(e2986d04,c06d85d1,e2986d24,c06acf40,0,...) at acpi_cpu_idle+0x162 cpu_idle(e2986d24,c06acf40,0,e2986d38,c3efeb40,...) at cpu_idle+0x28 sched_idletd(0,e2986d38) at sched_idletd+0x29 fork_exit(c06d85a8,0,e2986d38) at fork_exit+0xac fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe2986d70, ebp = 0 --- db> ps pid ppid pgrp uid state wmesg wchan cmd 10970 10969 10969 22 S select 0xc0a9be5c sshd 10969 1133 10969 0 Ss sbwait 0xc46c99b0 sshd 10967 1133 10967 0 LEs *pf task 0xc46c7700 sshd 10904 1090 1090 0 S select 0xc0a9be5c local 10903 1090 1090 125 S select 0xc0a9be5c cleanup 10902 1090 1090 125 S select 0xc0a9be5c proxymap 10814 0 0 0 SL - 0xc0aa366c [nfsiod 19] 10813 0 0 0 SL - 0xc0aa3668 [nfsiod 18] 10812 0 0 0 SL - 0xc0aa3664 [nfsiod 17] 10811 0 0 0 SL - 0xc0aa3660 [nfsiod 16] 10810 0 0 0 SL - 0xc0aa365c [nfsiod 15] 10809 0 0 0 SL - 0xc0aa3658 [nfsiod 14] 10808 0 0 0 SL - 0xc0aa3654 [nfsiod 13] 10807 0 0 0 SL - 0xc0aa3650 [nfsiod 12] 10806 0 0 0 SL - 0xc0aa364c [nfsiod 11] 10805 0 0 0 SL - 0xc0aa3648 [nfsiod 10] 10804 0 0 0 SL - 0xc0aa3644 [nfsiod 9] 10803 0 0 0 SL - 0xc0aa3640 [nfsiod 8] 10802 0 0 0 SL - 0xc0aa363c [nfsiod 7] 10801 0 0 0 SL - 0xc0aa3638 [nfsiod 6] 10800 0 0 0 SL - 0xc0aa3634 [nfsiod 5] 10799 0 0 0 SL - 0xc0aa3630 [nfsiod 4] 10798 0 0 0 SL - 0xc0aa362c [nfsiod 3] 10797 0 0 0 SL - 0xc0aa3628 [nfsiod 2] 10796 0 0 0 SL - 0xc0aa3624 [nfsiod 1] 10791 0 0 0 SL - 0xc0aa3620 [nfsiod 0] 10787 1090 1090 125 S select 0xc0a9be5c trivial-rewrite 10393 1090 1090 125 S select 0xc0a9be5c pickup 9973 1090 1090 125 S select 0xc0a9be5c smtpd 9907 1025 1025 0 S select 0xc0a9be5c perl5.8.8 8792 1090 1090 125 S select 0xc0a9be5c anvil 1538 1537 1538 0 Ss+ ttyin 0xc401bc10 bash 1537 1296 1537 0 S+ select 0xc0a9be5c script 1374 1257 1374 500 S+ select 0xc0a9be5c irssi 1296 1295 1296 0 S+ wait 0xc4341900 bash 1295 1270 1295 0 Ss+ wait 0xc4858000 login 1276 1254 1276 500 Ss+ ttyin 0xc40d7810 bash 1270 1174 1270 0 Ss select 0xc0a9be5c telnetd 1269 1254 1269 500 Ss+ ttyin 0xc40ba410 bash 1267 1254 1267 500 Ss+ ttyin 0xc40ba810 bash 1266 1254 1266 500 Ss+ ttyin 0xc4027810 bash 1264 1254 1264 500 Ss+ ttyin 0xc4027410 bash 1260 1254 1260 500 Ss+ ttyin 0xc40c4410 bash 1259 1254 1259 500 Ss+ select 0xc0a9be5c telnet 1258 1254 1258 500 Ss+ select 0xc0a9be5c telnet 1257 1254 1257 500 Ss+ wait 0xc484e000 bash 1256 1254 1256 500 Ss+ select 0xc0a9be5c mutt 1254 1 1254 500 Ss select 0xc0a9be5c screen 1205 1025 1025 0 S select 0xc0a9be5c perl5.8.8 1198 1 1198 0 Ss+ ttyin 0xc409ac10 getty 1197 1 1197 0 Ss+ ttyin 0xc40cc810 getty 1196 1 1196 0 Ss+ ttyin 0xc40c5010 getty 1195 1 1195 0 Ss+ ttyin 0xc40c3810 getty 1194 1 1194 0 Ss+ ttyin 0xc40bb410 getty 1193 1 1193 0 Ss+ ttyin 0xc40c4010 getty 1174 1 1174 0 Ss select 0xc0a9be5c inetd 1141 1 1141 0 Ss nanslp 0xc0a4f2a4 cron 1133 1 1133 0 Ss select 0xc0a9be5c sshd 1119 1118 1119 0 S+ select 0xc0a9be5c couriertcpd 1118 1 1118 0 S+ piperd 0xc46ad318 courierlogger 1107 1106 1107 0 S+ select 0xc0a9be5c couriertcpd 1106 1 1106 0 S+ piperd 0xc46ad7bc courierlogger 1102 1090 1090 125 S select 0xc0a9be5c qmgr 1090 1 1090 0 Ss select 0xc0a9be5c master 1044 1033 1032 0 S+ select 0xc0a9be5c authdaemond 1043 1033 1032 0 S+ select 0xc0a9be5c authdaemond 1042 1033 1032 0 S+ select 0xc0a9be5c authdaemond 1041 1033 1032 0 S+ select 0xc0a9be5c authdaemond 1040 1033 1032 0 S+ select 0xc0a9be5c authdaemond 1033 1032 1032 0 S+ select 0xc0a9be5c authdaemond 1032 1 1032 0 S+ piperd 0xc4298948 courierlogger 1025 1 1025 0 Ss select 0xc0a9be5c perl5.8.8 1018 1 1018 1001 Ss select 0xc0a9be5c dhcpd 924 1 924 1 Ss sbwait 0xc45b89b0 rwhod 911 1 911 0 Ss select 0xc0a9be5c ntpd 895 1 895 0 Ss select 0xc0a9be5c lpd 874 866 866 0 S nfslockd 0xc0aa3848 rpc.lockd 866 1 866 0 Ss select 0xc0a9be5c rpc.lockd 861 1 861 0 Ss select 0xc0a9be5c rpc.statd 827 1 827 0 Ss select 0xc0a9be5c rpcbind 817 1 817 53 Ss select 0xc0a9be5c named 754 1 754 0 Ss select 0xc0a9be5c syslogd 729 1 729 0 Ss select 0xc0a9be5c watchquagga 724 1 724 0 Ss select 0xc0a9be5c ospfd 718 1 718 0 Ss select 0xc0a9be5c zebra 658 1 658 0 Ss select 0xc0a9be5c devd 436 431 431 64 S bpf 0xc4496e00 pflogd 431 1 431 0 Ss sbwait 0xc433a1e8 pflogd 165 1 165 0 Ss pause 0xc40a06e4 adjkerntz 41 0 0 0 SL - 0xe46c8cfc [schedcpu] 40 0 0 0 SL sdflush 0xc0aa8a84 [softdepflush] 39 0 0 0 SL vlruwt 0xc4249000 [vnlru] 38 0 0 0 SL syncer 0xc0a4f06c [syncer] 37 0 0 0 SL psleep 0xc0a9c2e8 [bufdaemon] 36 0 0 0 SL pgzero 0xc0ab13d0 [pagezero] 35 0 0 0 SL psleep 0xc0aa9300 [vmdaemon] 34 0 0 0 SL psleep 0xc0aa92c0 [pagedaemon] 33 0 0 0 WL [irq7: ppc0] 32 0 0 0 WL [irq1: atkbd0] 31 0 0 0 WL [swi0: sio] 30 0 0 0 SL - 0xc4041200 [em0 taskq] 29 0 0 0 LL *tcp 0xc4045b80 [irq18: fxp1 em0] 28 0 0 0 WL [irq17: fxp0] 27 0 0 0 SL usbevt 0xc402a210 [usb1] 26 0 0 0 SL usbtsk 0xc0a4c854 [usbtask-dr] 25 0 0 0 SL usbtsk 0xc0a4c840 [usbtask-hc] 24 0 0 0 SL usbevt 0xc3ffb210 [usb0] 23 0 0 0 WL [irq12: uhci0 uhci1] 22 0 0 0 WL [irq15: ata1] 21 0 0 0 WL [irq14: ata0] 20 0 0 0 WL [irq9: acpi0] 9 0 0 0 SL - 0xc3f78680 [kqueue taskq] 19 0 0 0 WL [swi2: cambio] 8 0 0 0 SL - 0xc3f78800 [acpi_task_2] 7 0 0 0 SL - 0xc3f78800 [acpi_task_1] 6 0 0 0 SL - 0xc3f78800 [acpi_task_0] 18 0 0 0 WL [swi5: +] 5 0 0 0 SL - 0xc3f78980 [thread taskq] 17 0 0 0 WL [swi6: Giant taskq] 16 0 0 0 WL [swi6: task queue] 15 0 0 0 SL - 0xc0a391e0 [yarrow] 4 0 0 0 SL - 0xc0a4d01c [g_down] 3 0 0 0 SL - 0xc0a4d018 [g_up] 2 0 0 0 SL - 0xc0a4d010 [g_event] 14 0 0 0 WL [swi1: net] 13 0 0 0 WL [swi3: vm] 12 0 0 0 LL *tcp 0xc4045b80 [swi4: clock sio] 11 0 0 0 RL CPU 0 [idle: cpu0] 10 0 0 0 RL CPU 1 [idle: cpu1] 1 0 1 0 SLs wait 0xc3f01000 [init] 0 0 0 0 WLs [swapper] 10968 10967 10967 22 Z sshd db> show pcpu cpuid = 0 curthread = 0xc3eff6c0: pid 11 "idle: cpu0" curpcb = 0xe2986d90 fpcurthread = none idlethread = 0xc3eff6c0: pid 11 "idle: cpu0" APIC ID = 0 currentldt = 0x50 spin locks held: db> show allpcpu Current CPU: 0 cpuid = 0 curthread = 0xc3eff6c0: pid 11 "idle: cpu0" curpcb = 0xe2986d90 fpcurthread = none idlethread = 0xc3eff6c0: pid 11 "idle: cpu0" APIC ID = 0 currentldt = 0x50 spin locks held: cpuid = 1 curthread = 0xc3eff510: pid 10 "idle: cpu1" curpcb = 0xe2983d90 fpcurthread = none idlethread = 0xc3eff510: pid 10 "idle: cpu1" APIC ID = 1 currentldt = 0x50 spin locks held: db> show locks db> show alllocks Process 10967 (sshd) thread 0xc45dabd0 (100110) shared rw PFil hook read/write mutex r = 0 (0xc0a9db58) locked @ /usr/src/sys/net/pfil.c:73 exclusive sleep mutex inp (tcpinp) r = 0 (0xc4587528) locked @ /usr/src/sys/netinet/tcp_usrreq.c:577 exclusive sleep mutex tcp r = 0 (0xc0a9df6c) locked @ /usr/src/sys/netinet/tcp_usrreq.c:574 Process 29 (irq18: fxp1 em0) thread 0xc409ca20 (100036) exclusive sleep mutex pf task mtx r = 0 (0xc4469c44) locked @ /usr/src/sys/modules/pf/../../contrib/pf/net/pf.c:6414 shared rw PFil hook read/write mutex r = 0 (0xc0a9db58) locked @ /usr/src/sys/net/pfil.c:73 db> show lockedvnods Locked vnodes db> alltrace Tracing command sshd pid 10970 tid 100134 td 0xc4852d80 sched_switch(c4852d80,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 sleepq_switch(c0a9be5c) at sleepq_switch+0xc9 sleepq_wait_sig(c0a9be5c,246,c0a4ea90,c095006f,308,...) at sleepq_wait_sig+0x1d cv_wait_sig(c0a9be5c,c0a9be44) at cv_wait_sig+0x18b kern_select(c4852d80,4,28401148,0,0,...) at kern_select+0x4bf select(c4852d80,e69fbd00) at select+0x44 syscall(e69fbd38) at syscall+0x256 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (93, FreeBSD ELF32, select), eip = 0x283841bf, esp = 0xbfbfc0dc, ebp = 0xbfbfe138 --- Tracing command sshd pid 10969 tid 100156 td 0xc4857d80 sched_switch(c4857d80,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 sleepq_switch(c46c99b0) at sleepq_switch+0xc9 sleepq_wait_sig(c46c99b0) at sleepq_wait_sig+0x1d msleep(c46c99b0,c46c9988,158,c0953043,0,...) at msleep+0x296 sbwait(c46c9964,2,c094ccee,91,c4857d80,...) at sbwait+0x48 soreceive_generic(c46c9914,0,e6a16c60,0,0,...) at soreceive_generic+0x2da soreceive(c46c9914,0,e6a16c60,0,0,0) at soreceive+0x39 soo_read(c4291c60,e6a16c60,c45d6d00,0,c4857d80) at soo_read+0x3d dofileread(c4857d80,6,c4291c60,e6a16c60,ffffffff,...) at dofileread+0x85 kern_readv(c4857d80,6,e6a16c60,bfbfe0e8,4,...) at kern_readv+0x36 read(c4857d80,e6a16d00) at read+0x45 syscall(e6a16d38) at syscall+0x256 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (3, FreeBSD ELF32, read), eip = 0x2838423f, esp = 0xbfbfe08c, ebp = 0xbfbfe0b8 --- Tracing command sshd pid 10967 tid 100110 td 0xc45dabd0 sched_switch(c45dabd0,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 turnstile_wait(c4469c44,c409ca20,0,c4469c44,2,c094a0d3,166) at turnstile_wait+0x3ea _mtx_lock_sleep(c4469c44,c45dabd0,0,c4466e24,190e) at _mtx_lock_sleep+0x145 _mtx_lock_flags(c4469c44,0,c4466e24,190e,c4469c44,...) at _mtx_lock_flags+0xab pf_test(2,c4098800,e698c958,0,c4587498,...) at pf_test+0x77 pf_check_out(0,e698c958,c4098800,2,c4587498) at pf_check_out+0x3d pfil_run_hooks(c0a9db40,e698c9d4,c4098800,2,c4587498,...) at pfil_run_hooks+0x7f ip_output(c4766800,0,e698c9a0,0,0,c4587498) at ip_output+0x69b tcp_output(c53311dc) at tcp_output+0x11d6 tcp_disconnect(c53311dc) at tcp_disconnect+0xf8 tcp_usr_disconnect(c5382298,e698cadc,c070788e,c5382298,c46afc60,...) at tcp_usr_disconnect+0x6c sodisconnect(c5382298) at sodisconnect+0x26 soclose(c5382298) at soclose+0x3e soo_close(c46afc60,c45dabd0) at soo_close+0x4b fdrop_locked(c46afc60,c45dabd0,c3ee1718,0,c09475f6,...) at fdrop_locked+0xb0 fdrop(c46afc60,c45dabd0,6b9,c0a55714,0,...) at fdrop+0x24 closef(c46afc60,c45dabd0) at closef+0x367 fdfree(c45dabd0) at fdfree+0x4a3 exit1(c45dabd0,ff00,e698cd2c,c08c154a,c45dabd0,...) at exit1+0x3cc exit1(c45dabd0,e698cd00) at exit1 syscall(e698cd38) at syscall+0x256 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (1, FreeBSD ELF32, sys_exit), eip = 0x28319173, esp = 0xbfbfe0ac, ebp = 0xbfbfe0c8 --- Tracing command local pid 10904 tid 100183 td 0xc69ab360 sched_switch(c69ab360,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 sleepq_switch(c0a9be5c) at sleepq_switch+0xc9 sleepq_timedwait_sig(c0a9be5c,c0a9be5c,86d7,e6ab8ae4,246,...) at sleepq_timedwait_sig+0x1e cv_timedwait_sig(c0a9be5c,c0a9be44,86d7) at cv_timedwait_sig+0x194 kern_select(c69ab360,7,bfbfecf0,bfbfec70,bfbfebf0,...) at kern_select+0x4a9 select(c69ab360,e6ab8d00) at select+0x44 syscall(e6ab8d38) at syscall+0x256 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (93, FreeBSD ELF32, select), eip = 0x2818e1bf, esp = 0xbfbfebbc, ebp = 0xbfbfed88 --- Tracing command cleanup pid 10903 tid 100143 td 0xc45da360 sched_switch(c45da360,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 sleepq_switch(c0a9be5c) at sleepq_switch+0xc9 sleepq_timedwait_sig(c0a9be5c,c0a9be5c,7302,e697dae4,246,...) at sleepq_timedwait_sig+0x1e cv_timedwait_sig(c0a9be5c,c0a9be44,7302) at cv_timedwait_sig+0x194 kern_select(c45da360,c,bfbfece0,bfbfec60,bfbfebe0,...) at kern_select+0x4a9 select(c45da360,e697dd00) at select+0x44 syscall(e697dd38) at syscall+0x256 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (93, FreeBSD ELF32, select), eip = 0x281931bf, esp = 0xbfbfebac, ebp = 0xbfbfed78 --- racing command proxymap pid 10902 tid 100154 td 0xc49051b0 sched_switch(c49051b0,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 sleepq_switch(c0a9be5c) at sleepq_switch+0xc9 sleepq_wait_sig(c0a9be5c,246,c0a4ea90,c095006f,308,...) at sleepq_wait_sig+0x1d cv_wait_sig(c0a9be5c,c0a9be44) at cv_wait_sig+0x18b kern_select(c49051b0,9,bfbfed10,bfbfec90,bfbfec10,...) at kern_select+0x4bf select(c49051b0,e6a3ad00) at select+0x44 syscall(e6a3ad38) at syscall+0x256 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (93, FreeBSD ELF32, select), eip = 0x2817a1bf, esp = 0xbfbfebdc, ebp = 0xbfbfeda8 --- Tracing command nfsiod 19 pid 10814 tid 100108 td 0xc45db000 sched_switch(c45db000,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 sleepq_switch(c0aa366c) at sleepq_switch+0xc9 sleepq_timedwait_sig(c0aa366c) at sleepq_timedwait_sig+0x1e msleep(c0aa366c,c0aa3608,15c,c0943377,1d4c0,...) at msleep+0x26c nfssvc_iod(c0aa300c,e6992d38) at nfssvc_iod+0xa5 fork_exit(c07b3e84,c0aa300c,e6992d38) at fork_exit+0xac fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe6992d70, ebp = 0 --- Tracing command nfsiod 18 pid 10813 tid 100132 td 0xc48571b0 sched_switch(c48571b0,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 sleepq_switch(c0aa3668) at sleepq_switch+0xc9 sleepq_timedwait_sig(c0aa3668) at sleepq_timedwait_sig+0x1e msleep(c0aa3668,c0aa3608,15c,c0943377,1d4c0,...) at msleep+0x26c nfssvc_iod(c0aa3008,e6a01d38) at nfssvc_iod+0xa5 fork_exit(c07b3e84,c0aa3008,e6a01d38) at fork_exit+0xac fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe6a01d70, ebp = 0 --- Tracing command nfsiod 17 pid 10812 tid 100142 td 0xc45da510 sched_switch(c45da510,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 sleepq_switch(c0aa3664) at sleepq_switch+0xc9 sleepq_timedwait_sig(c0aa3664) at sleepq_timedwait_sig+0x1e msleep(c0aa3664,c0aa3608,15c,c0943377,1d4c0,...) at msleep+0x26c nfssvc_iod(c0aa3004,e6980d38) at nfssvc_iod+0xa5 fork_exit(c07b3e84,c0aa3004,e6980d38) at fork_exit+0xac fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe6980d70, ebp = 0 --- Tracing command nfsiod 16 pid 10811 tid 100131 td 0xc45dba20 sched_switch(c45dba20,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 sleepq_switch(c0aa3660) at sleepq_switch+0xc9 sleepq_timedwait_sig(c0aa3660) at sleepq_timedwait_sig+0x1e msleep(c0aa3660,c0aa3608,15c,c0943377,1d4c0,...) at msleep+0x26c nfssvc_iod(c0aa3000,e69a4d38) at nfssvc_iod+0xa5 fork_exit(c07b3e84,c0aa3000,e69a4d38) at fork_exit+0xac fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe69a4d70, ebp = 0 --- Tracing command nfsiod 15 pid 10810 tid 100163 td 0xc4852000 sched_switch(c4852000,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 sleepq_switch(c0aa365c) at sleepq_switch+0xc9 sleepq_timedwait_sig(c0aa365c) at sleepq_timedwait_sig+0x1e msleep(c0aa365c,c0aa3608,15c,c0943377,1d4c0,...) at msleep+0x26c nfssvc_iod(c0aa2ffc,e69e3d38) at nfssvc_iod+0xa5 fork_exit(c07b3e84,c0aa2ffc,e69e3d38) at fork_exit+0xac fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe69e3d70, ebp = 0 --- Tracing command nfsiod 14 pid 10809 tid 100166 td 0xc47c3a20 sched_switch(c47c3a20,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 sleepq_switch(c0aa3658) at sleepq_switch+0xc9 sleepq_timedwait_sig(c0aa3658) at sleepq_timedwait_sig+0x1e msleep(c0aa3658,c0aa3608,15c,c0943377,1d4c0,...) at msleep+0x26c nfssvc_iod(c0aa2ff8,e69dad38) at nfssvc_iod+0xa5 fork_exit(c07b3e84,c0aa2ff8,e69dad38) at fork_exit+0xac fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe69dad70, ebp = 0 --- Tracing command nfsiod 13 pid 10808 tid 100152 td 0xc4905510 sched_switch(c4905510,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 sleepq_switch(c0aa3654) at sleepq_switch+0xc9 sleepq_timedwait_sig(c0aa3654) at sleepq_timedwait_sig+0x1e msleep(c0aa3654,c0aa3608,15c,c0943377,1d4c0,...) at msleep+0x26c nfssvc_iod(c0aa2ff4,e6a40d38) at nfssvc_iod+0xa5 fork_exit(c07b3e84,c0aa2ff4,e6a40d38) at fork_exit+0xac fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe6a40d70, ebp = 0 --- Tracing command nfsiod 12 pid 10807 tid 100202 td 0xc69aa870 sched_switch(c69aa870,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 sleepq_switch(c0aa3650) at sleepq_switch+0xc9 sleepq_timedwait_sig(c0aa3650) at sleepq_timedwait_sig+0x1e msleep(c0aa3650,c0aa3608,15c,c0943377,1d4c0,...) at msleep+0x26c nfssvc_iod(c0aa2ff0,e6aa6d38) at nfssvc_iod+0xa5 fork_exit(c07b3e84,c0aa2ff0,e6aa6d38) at fork_exit+0xac fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe6aa6d70, ebp = 0 --- Tracing command nfsiod 11 pid 10806 tid 100196 td 0xc6a331b0 sched_switch(c6a331b0,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 sleepq_switch(c0aa364c) at sleepq_switch+0xc9 sleepq_timedwait_sig(c0aa364c) at sleepq_timedwait_sig+0x1e msleep(c0aa364c,c0aa3608,15c,c0943377,1d4c0,...) at msleep+0x26c nfssvc_iod(c0aa2fec,e6b09d38) at nfssvc_iod+0xa5 fork_exit(c07b3e84,c0aa2fec,e6b09d38) at fork_exit+0xac fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe6b09d70, ebp = 0 --- Tracing command nfsiod 10 pid 10805 tid 100129 td 0xc45dbd80 sched_switch(c45dbd80,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 sleepq_switch(c0aa3648) at sleepq_switch+0xc9 sleepq_timedwait_sig(c0aa3648) at sleepq_timedwait_sig+0x1e msleep(c0aa3648,c0aa3608,15c,c0943377,1d4c0,...) at msleep+0x26c nfssvc_iod(c0aa2fe8,e69aad38) at nfssvc_iod+0xa5 fork_exit(c07b3e84,c0aa2fe8,e69aad38) at fork_exit+0xac fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe69aad70, ebp = 0 --- Tracing command nfsiod 9 pid 10804 tid 100117 td 0xc47c3360 sched_switch(c47c3360,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 sleepq_switch(c0aa3644) at sleepq_switch+0xc9 sleepq_timedwait_sig(c0aa3644) at sleepq_timedwait_sig+0x1e msleep(c0aa3644,c0aa3608,15c,c0943377,1d4c0,...) at msleep+0x26c nfssvc_iod(c0aa2fe4,e69ced38) at nfssvc_iod+0xa5 fork_exit(c07b3e84,c0aa2fe4,e69ced38) at fork_exit+0xac fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe69ced70, ebp = 0 --- Tracing command nfsiod 8 pid 10803 tid 100150 td 0xc4905870 sched_switch(c4905870,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 sleepq_switch(c0aa3640) at sleepq_switch+0xc9 sleepq_timedwait_sig(c0aa3640) at sleepq_timedwait_sig+0x1e msleep(c0aa3640,c0aa3608,15c,c0943377,1d4c0,...) at msleep+0x26c nfssvc_iod(c0aa2fe0,e6a46d38) at nfssvc_iod+0xa5 fork_exit(c07b3e84,c0aa2fe0,e6a46d38) at fork_exit+0xac fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe6a46d70, ebp = 0 --- Tracing command nfsiod 7 pid 10802 tid 100200 td 0xc6a32a20 sched_switch(c6a32a20,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 sleepq_switch(c0aa363c) at sleepq_switch+0xc9 sleepq_timedwait_sig(c0aa363c) at sleepq_timedwait_sig+0x1e msleep(c0aa363c,c0aa3608,15c,c0943377,1d4c0,...) at msleep+0x26c nfssvc_iod(c0aa2fdc,e6afdd38) at nfssvc_iod+0xa5 fork_exit(c07b3e84,c0aa2fdc,e6afdd38) at fork_exit+0xac fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe6afdd70, ebp = 0 --- Tracing command nfsiod 6 pid 10801 tid 100061 td 0xc4342a20 sched_switch(c4342a20,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 sleepq_switch(c0aa3638) at sleepq_switch+0xc9 sleepq_timedwait_sig(c0aa3638) at sleepq_timedwait_sig+0x1e msleep(c0aa3638,c0aa3608,15c,c0943377,1d4c0,...) at msleep+0x26c nfssvc_iod(c0aa2fd8,e68d5d38) at nfssvc_iod+0xa5 fork_exit(c07b3e84,c0aa2fd8,e68d5d38) at fork_exit+0xac fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe68d5d70, ebp = 0 --- Tracing command nfsiod 5 pid 10800 tid 100176 td 0xc52fbd80 sched_switch(c52fbd80,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 sleepq_switch(c0aa3634) at sleepq_switch+0xc9 sleepq_timedwait_sig(c0aa3634) at sleepq_timedwait_sig+0x1e msleep(c0aa3634,c0aa3608,15c,c0943377,1d4c0,...) at msleep+0x26c nfssvc_iod(c0aa2fd4,e6a79d38) at nfssvc_iod+0xa5 fork_exit(c07b3e84,c0aa2fd4,e6a79d38) at fork_exit+0xac fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe6a79d70, ebp = 0 --- Tracing command nfsiod 4 pid 10799 tid 100148 td 0xc4905bd0 sched_switch(c4905bd0,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 sleepq_switch(c0aa3630) at sleepq_switch+0xc9 sleepq_timedwait_sig(c0aa3630) at sleepq_timedwait_sig+0x1e msleep(c0aa3630,c0aa3608,15c,c0943377,1d4c0,...) at msleep+0x26c nfssvc_iod(c0aa2fd0,e6a4cd38) at nfssvc_iod+0xa5 fork_exit(c07b3e84,c0aa2fd0,e6a4cd38) at fork_exit+0xac fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe6a4cd70, ebp = 0 --- Tracing command nfsiod 3 pid 10798 tid 100174 td 0xc52fc1b0 sched_switch(c52fc1b0,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 sleepq_switch(c0aa362c) at sleepq_switch+0xc9 sleepq_timedwait_sig(c0aa362c) at sleepq_timedwait_sig+0x1e msleep(c0aa362c,c0aa3608,15c,c0943377,1d4c0,...) at msleep+0x26c nfssvc_iod(c0aa2fcc,e6a7fd38) at nfssvc_iod+0xa5 fork_exit(c07b3e84,c0aa2fcc,e6a7fd38) at fork_exit+0xac fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe6a7fd70, ebp = 0 --- Tracing command nfsiod 2 pid 1077 tid 100130 td 0xc45dbbd0 sched_switch(c45dbbd0,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 sleepq_switch(c0aa3628) at sleepq_switch+0xc9 sleepq_timedwait_sig(c0aa3628) at sleepq_timedwait_sig+0x1e msleep(c0aa3628,c0aa3608,15c,c0943377,1d4c0,...) at msleep+0x26c nfssvc_iod(c0aa2fc8,e69a7d38) at nfssvc_iod+0xa5 fork_exit(c07b3e84,c0aa2fc8,e69a7d38) at fork_exit+0xac fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe69a7d70, ebp = 0 --- Tracing command nfsiod 1 pid 10796 tid 100179 td 0xc4857510 sched_switch(c4857510,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 sleepq_switch(c0aa3624) at sleepq_switch+0xc9 sleepq_timedwait_sig(c0aa3624) at sleepq_timedwait_sig+0x1e msleep(c0aa3624,c0aa3608,15c,c0943377,1d4c0,...) at msleep+0x26c nfssvc_iod(c0aa2fc4,e6a07d38) at nfssvc_iod+0xa5 fork_exit(c07b3e84,c0aa2fc4,e6a07d38) at fork_exit+0xac fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe6a07d70, ebp = 0 --- Tracing command nfsiod 0 pid 10791 tid 100178 td 0xc52fba20 sched_switch(c52fba20,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 sleepq_switch(c0aa3620) at sleepq_switch+0xc9 sleepq_timedwait_sig(c0aa3620) at sleepq_timedwait_sig+0x1e msleep(c0aa3620,c0aa3608,15c,c0943377,1d4c0,...) at msleep+0x26c nfssvc_iod(c0aa2fc0,e6a73d38) at nfssvc_iod+0xa5 fork_exit(c07b3e84,c0aa2fc0,e6a73d38) at fork_exit+0xac fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe6a73d70, ebp = 0 --- Tracing command trivial-rewrite pid 10787 tid 100186 td 0xc69aad80 sched_switch(c69aad80,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 sleepq_switch(c0a9be5c) at sleepq_switch+0xc9 sleepq_timedwait_sig(c0a9be5c,c0a9be5c,2711,e6aafae4,246,...) at sleepq_timedwait_sig+0x1e cv_timedwait_sig(c0a9be5c,c0a9be44,2711) at cv_timedwait_sig+0x194 kern_select(c69aad80,b,bfbfed00,bfbfec80,bfbfec00,...) at kern_select+0x4a9 select(c69aad80,e6aafd00) at select+0x44 syscall(e6aafd38) at syscall+0x256 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (93, FreeBSD ELF32, select), eip = 0x2817e1bf, esp = 0xbfbfebcc, ebp = 0xbfbfed98 --- Tracing command pickup pid 10393 tid 100109 td 0xc45dad80 sched_switch(c45dad80,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 sleepq_switch(c0a9be5c) at sleepq_switch+0xc9 sleepq_timedwait_sig(c0a9be5c,c0a9be5c,10994,e698fae4,246,...) at sleepq_timedwait_sig+0x1e cv_timedwait_sig(c0a9be5c,c0a9be44,10994) at cv_timedwait_sig+0x194 kern_select(c45dad80,7,bfbfe900,bfbfe880,bfbfe800,...) at kern_select+0x4a9 select(c45dad80,e698fd00) at select+0x44 syscall(e698fd38) at syscall+0x256 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (93, FreeBSD ELF32, select), eip = 0x2817d1bf, esp = 0xbfbfe7cc, ebp = 0xbfbfe998 --- Tracing command smtpd pid 9973 tid 100173 td 0xc52fc360 sched_switch(c52fc360,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 sleepq_switch(c0a9be5c) at sleepq_switch+0xc9 sleepq_timedwait_sig(c0a9be5c,c0a9be5c,7135,e6a82ae4,246,...) at sleepq_timedwait_sig+0x1e cv_timedwait_sig(c0a9be5c,c0a9be44,7135) at cv_timedwait_sig+0x194 kern_select(c52fc360,e,bfbfecf0,bfbfec70,bfbfebf0,...) at kern_select+0x4a9 select(c52fc360,e6a82d00) at select+0x44 syscall(e6a82d38) at syscall+0x256 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (93, FreeBSD ELF32, select), eip = 0x2819f1bf, esp = 0xbfbfebbc, ebp = 0xbfbfed88 --- Tracing command perl5.8.8 pid 9907 tid 100199 td 0xc6a32bd0 sched_switch(c6a32bd0,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 sleepq_switch(c0a9be5c) at sleepq_switch+0xc9 sleepq_timedwait_sig(c0a9be5c,c0a9be5c,35d3e,e6b00ae4,246,...) at sleepq_timedwait_sig+0x1e cv_timedwait_sig(c0a9be5c,c0a9be44,35d3e) at cv_timedwait_sig+0x194 kern_select(c6a32bd0,10,9861c34,0,0,...) at kern_select+0x4a9 select(c6a32bd0,e6b00d00) at select+0x44 syscall(e6b00d38) at syscall+0x256 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (93, FreeBSD ELF32, select), eip = 0x282821bf, esp = 0xbfbfecbc, ebp = 0xbfbfed48 --- Tracing command anvil pid 8792 tid 100054 td 0xc409da20 sched_switch(c409da20,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 sleepq_switch(c0a9be5c) at sleepq_switch+0xc9 sleepq_timedwait_sig(c0a9be5c,c0a9be5c,c60b,e4688ae4,246,...) at sleepq_timedwait_sig+0x1e cv_timedwait_sig(c0a9be5c,c0a9be44,c60b) at cv_timedwait_sig+0x194 kern_select(c409da20,a,bfbfed00,bfbfec80,bfbfec00,...) at kern_select+0x4a9 select(c409da20,e4688d00) at select+0x44 syscall(e4688d38) at syscall+0x256 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (93, FreeBSD ELF32, select), eip = 0x2817c1bf, esp = 0xbfbfebcc, ebp = 0xbfbfed98 --- Tracing command bash pid 1538 tid 100153 td 0xc4905360 sched_switch(c4905360,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 sleepq_switch(c401bc10) at sleepq_switch+0xc9 sleepq_wait_sig(c401bc10) at sleepq_wait_sig+0x1d msleep(c401bc10,0,159,c0951c65,0) at msleep+0x296 ttysleep(c401bc00,c401bc10,159,c0951c65,0,...) at ttysleep+0x21 ttread(c401bc00,e6a3dc60,0) at ttread+0x48f ptsread(c46b5100,e6a3dc60,0,c0a4eaa8,0,...) at ptsread+0x2d giant_read(c46b5100,e6a3dc60,0) at giant_read+0x2d devfs_read_f(c46a3900,e6a3dc60,c490d100,0,c4905360) at devfs_read_f+0x62 dofileread(c4905360,0,c46a3900,e6a3dc60,ffffffff,...) at dofileread+0x85 kern_readv(c4905360,0,e6a3dc60,bfbfe83f,1,...) at kern_readv+0x36 read(c4905360,e6a3dd00) at read+0x45 syscall(e6a3dd38) at syscall+0x256 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (3, FreeBSD ELF32, read), eip = 0x2821223f, esp = 0xbfbfe81c, ebp = 0xbfbfe848 --- Tracing command script pid 1537 tid 100161 td 0xc4852360 sched_switch(c4852360,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 sleepq_switch(c0a9be5c) at sleepq_switch+0xc9 sleepq_timedwait_sig(c0a9be5c,c0a9be5c,6b1f,e69e9ae4,246,...) at sleepq_timedwait_sig+0x1e cv_timedwait_sig(c0a9be5c,c0a9be44,6b1f) at cv_timedwait_sig+0x194 kern_select(c4852360,5,bfbfe470,0,0,...) at kern_select+0x4a9 select(c4852360,e69e9d00) at select+0x44 syscall(e69e9d38) at syscall+0x256 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (93, FreeBSD ELF32, select), eip = 0x281551bf, esp = 0xbfbfe40c, ebp = 0xbfbfed68 --- Tracing command irssi pid 1374 tid 100141 td 0xc45da6c0 sched_switch(c45da6c0,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 sleepq_switch(c0a9be5c) at sleepq_switch+0xc9 sleepq_timedwait_sig(c0a9be5c,c0a9be5c,5c,e6983b28,246,...) at sleepq_timedwait_sig+0x1e cv_timedwait_sig(c0a9be5c,c0a9be44,5c) at cv_timedwait_sig+0x194 poll(c45da6c0,e6983d00) at poll+0x3a3 syscall(e6983d38) at syscall+0x256 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (209, FreeBSD ELF32, poll), eip = 0x285dcadf, esp = 0xbfbfe43c, ebp = 0xbfbfe488 --- Tracing command bash pid 1296 tid 100060 td 0xc4342bd0 sched_switch(c4342bd0,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 sleepq_switch(c4341900) at sleepq_switch+0xc9 sleepq_wait_sig(c4341900) at sleepq_wait_sig+0x1d msleep(c4341900,c4341960,15c,c095061f,0) at msleep+0x296 kern_wait(c4342bd0,ffffffff,e68d8c28,6,0) at kern_wait+0x7c3 wait4(c4342bd0,e68d8d00) at wait4+0x2a syscall(e68d8d38) at syscall+0x256 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (7, FreeBSD ELF32, wait4), eip = 0x2819eb1b, esp = 0xbfbfe94c, ebp = 0xbfbfe968 --- Tracing command login pid 1295 tid 100133 td 0xc4857000 sched_switch(c4857000,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 sleepq_switch(c4858000) at sleepq_switch+0xc9 sleepq_wait_sig(c4858000) at sleepq_wait_sig+0x1d msleep(c4858000,c4858060,15c,c095061f,0) at msleep+0x296 kern_wait(c4857000,510,e69fec28,0,0) at kern_wait+0x7c3 wait4(c4857000,e69fed00) at wait4+0x2a syscall(e69fed38) at syscall+0x256 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (7, FreeBSD ELF32, wait4), eip = 0x280fab1b, esp = 0xbfbfed4c, ebp = 0xbfbfed68 --- Tracing command bash pid 1276 tid 100074 td 0xc44eca20 sched_switch(c44eca20,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 sleepq_switch(c40d7810) at sleepq_switch+0xc9 sleepq_wait_sig(c40d7810) at sleepq_wait_sig+0x1d msleep(c40d7810,0,159,c0951c65,0) at msleep+0x296 ttysleep(c40d7800,c40d7810,159,c0951c65,0,...) at ttysleep+0x21 ttread(c40d7800,e6929c60,0) at ttread+0x48f ptsread(c4871800,e6929c60,0,c0a4eaa8,0,...) at ptsread+0x2d giant_read(c4871800,e6929c60,0) at giant_read+0x2d devfs_read_f(c4897828,e6929c60,c48e1700,0,c44eca20) at devfs_read_f+0x62 dofileread(c44eca20,0,c4897828,e6929c60,ffffffff,...) at dofileread+0x85 kern_readv(c44eca20,0,e6929c60,bfbfe13f,1,...) at kern_readv+0x36 read(c44eca20,e6929d00) at read+0x45 syscall(e6929d38) at syscall+0x256 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (3, FreeBSD ELF32, read), eip = 0x2821223f, esp = 0xbfbfe11c, ebp = 0xbfbfe148 --- Tracing command telnetd pid 1270 tid 100123 td 0xc47c2870 sched_switch(c47c2870,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 sleepq_switch(c0a9be5c) at sleepq_switch+0xc9 sleepq_wait_sig(c0a9be5c,246,c0a4ea90,c095006f,308,...) at sleepq_wait_sig+0x1d cv_wait_sig(c0a9be5c,c0a9be44) at cv_wait_sig+0x18b kern_select(c47c2870,10,bfbfdc10,bfbfdb90,bfbfdb10,...) at kern_select+0x4bf select(c47c2870,e69bcd00) at select+0x44 syscall(e69bcd38) at syscall+0x256 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (93, FreeBSD ELF32, select), eip = 0x282581bf, esp = 0xbfbfdabc, ebp = 0xbfbfe5a8 --- Tracing command bash pid 1269 tid 100079 td 0xc44ec1b0 sched_switch(c44ec1b0,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 sleepq_switch(c40ba410) at sleepq_switch+0xc9 sleepq_wait_sig(c40ba410) at sleepq_wait_sig+0x1d msleep(c40ba410,0,159,c0951c65,0) at msleep+0x296 ttysleep(c40ba400,c40ba410,159,c0951c65,0,...) at ttysleep+0x21 ttread(c40ba400,e691ac60,0) at ttread+0x48f ptsread(c486f100,e691ac60,0,c0a4eaa8,0,...) at ptsread+0x2d giant_read(c486f100,e691ac60,0) at giant_read+0x2d devfs_read_f(c4897318,e691ac60,c48e4280,0,c44ec1b0) at devfs_read_f+0x62 dofileread(c44ec1b0,0,c4897318,e691ac60,ffffffff,...) at dofileread+0x85 kern_readv(c44ec1b0,0,e691ac60,bfbfe13f,1,...) at kern_readv+0x36 read(c44ec1b0,e691ad00) at read+0x45 syscall(e691ad38) at syscall+0x256 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (3, FreeBSD ELF32, read), eip = 0x2821223f, esp = 0xbfbfe11c, ebp = 0xbfbfe148 --- Tracing command bash pid 1267 tid 100128 td 0xc47c2000 sched_switch(c47c2000,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 sleepq_switch(c40ba810) at sleepq_switch+0xc9 sleepq_wait_sig(c40ba810) at sleepq_wait_sig+0x1d msleep(c40ba810,0,159,c0951c65,0) at msleep+0x296 ttysleep(c40ba800,c40ba810,159,c0951c65,0,...) at ttysleep+0x21 ttread(c40ba800,e69adc60,0) at ttread+0x48f ptsread(c486f000,e69adc60,0,c0a4eaa8,0,...) at ptsread+0x2d giant_read(c486f000,e69adc60,0) at giant_read+0x2d devfs_read_f(c47e2318,e69adc60,c48de600,0,c47c2000) at devfs_read_f+0x62 dofileread(c47c2000,0,c47e2318,e69adc60,ffffffff,...) at dofileread+0x85 kern_readv(c47c2000,0,e69adc60,bfbfe13f,1,...) at kern_readv+0x36 read(c47c2000,e69add00) at read+0x45 syscall(e69add38) at syscall+0x256 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (3, FreeBSD ELF32, read), eip = 0x2821223f, esp = 0xbfbfe11c, ebp = 0xbfbfe148 --- Tracing command bash pid 1266 tid 100094 td 0xc4596000 sched_switch(c4596000,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 sleepq_switch(c4027810) at sleepq_switch+0xc9 sleepq_wait_sig(c4027810) at sleepq_wait_sig+0x1d msleep(c4027810,0,159,c0951c65,0) at msleep+0x296 ttysleep(c4027800,c4027810,159,c0951c65,0,...) at ttysleep+0x21 ttread(c4027800,e694dc60,0) at ttread+0x48f ptsread(c486f400,e694dc60,0,c0a4eaa8,0,...) at ptsread+0x2d giant_read(c486f400,e694dc60,0) at giant_read+0x2d devfs_read_f(c46a39d8,e694dc60,c48d4300,0,c4596000) at devfs_read_f+0x62 dofileread(c4596000,0,c46a39d8,e694dc60,ffffffff,...) at dofileread+0x85 kern_readv(c4596000,0,e694dc60,bfbfe13f,1,...) at kern_readv+0x36 read(c4596000,e694dd00) at read+0x45 syscall(e694dd38) at syscall+0x256 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (3, FreeBSD ELF32, read), eip = 0x2821223f, esp = 0xbfbfe11c, ebp = 0xbfbfe148 --- Tracing command bash pid 1264 tid 100070 td 0xc4248a20 sched_switch(c4248a20,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 sleepq_switch(c4027410) at sleepq_switch+0xc9 sleepq_wait_sig(c4027410) at sleepq_wait_sig+0x1d msleep(c4027410,0,159,c0951c65,0) at msleep+0x296 ttysleep(c4027400,c4027410,159,c0951c65,0,...) at ttysleep+0x21 ttread(c4027400,e46cec60,0) at ttread+0x48f ptsread(c486f700,e46cec60,0,c0a4eaa8,0,...) at ptsread+0x2d giant_read(c486f700,e46cec60,0) at giant_read+0x2d devfs_read_f(c46b94c8,e46cec60,c48c7100,0,c4248a20) at devfs_read_f+0x62 dofileread(c4248a20,0,c46b94c8,e46cec60,ffffffff,...) at dofileread+0x85 kern_readv(c4248a20,0,e46cec60,bfbfe13f,1,...) at kern_readv+0x36 read(c4248a20,e46ced00) at read+0x45 syscall(e46ced38) at syscall+0x256 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (3, FreeBSD ELF32, read), eip = 0x2821223f, esp = 0xbfbfe11c, ebp = 0xbfbfe148 --- Tracing command bash pid 1260 tid 100135 td 0xc4852bd0 sched_switch(c4852bd0,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 sleepq_switch(c40c4410) at sleepq_switch+0xc9 sleepq_wait_sig(c40c4410) at sleepq_wait_sig+0x1d msleep(c40c4410,0,159,c0951c65,0) at msleep+0x296 ttysleep(c40c4400,c40c4410,159,c0951c65,0,...) at ttysleep+0x21 ttread(c40c4400,e69f8c60,0) at ttread+0x48f ptsread(c4870700,e69f8c60,0,c0a4eaa8,0,...) at ptsread+0x2d giant_read(c4870700,e69f8c60,0) at giant_read+0x2d devfs_read_f(c4897990,e69f8c60,c47e0c00,0,c4852bd0) at devfs_read_f+0x62 dofileread(c4852bd0,0,c4897990,e69f8c60,ffffffff,...) at dofileread+0x85 kern_readv(c4852bd0,0,e69f8c60,bfbfe13f,1,...) at kern_readv+0x36 read(c4852bd0,e69f8d00) at read+0x45 syscall(e69f8d38) at syscall+0x256 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (3, FreeBSD ELF32, read), eip = 0x2821223f, esp = 0xbfbfe11c, ebp = 0xbfbfe148 --- Tracing command telnet pid 1259 tid 100124 td 0xc47c26c0 sched_switch(c47c26c0,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 sleepq_switch(c0a9be5c) at sleepq_switch+0xc9 sleepq_wait_sig(c0a9be5c,246,c0a4ea90,c095006f,308,...) at sleepq_wait_sig+0x1d cv_wait_sig(c0a9be5c,c0a9be44) at cv_wait_sig+0x18b kern_select(c47c26c0,10,8071d60,8071de0,8071e60,...) at kern_select+0x4bf select(c47c26c0,e69b9d00) at select+0x44 syscall(e69b9d38) at syscall+0x256 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (93, FreeBSD ELF32, select), eip = 0x282531bf, esp = 0xbfbfe48c, ebp = 0xbfbfe4c8 --- Tracing command telnet pid 1258 tid 100125 td 0xc47c2510 sched_switch(c47c2510,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 sleepq_switch(c0a9be5c) at sleepq_switch+0xc9 sleepq_wait_sig(c0a9be5c,246,c0a4ea90,c095006f,308,...) at sleepq_wait_sig+0x1d cv_wait_sig(c0a9be5c,c0a9be44) at cv_wait_sig+0x18b kern_select(c47c2510,10,8071d60,8071de0,8071e60,...) at kern_select+0x4bf select(c47c2510,e69b6d00) at select+0x44 syscall(e69b6d38) at syscall+0x256 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (93, FreeBSD ELF32, select), eip = 0x282531bf, esp = 0xbfbfe48c, ebp = 0xbfbfe4c8 --- Tracing command bash pid 1257 tid 100126 td 0xc47c2360 sched_switch(c47c2360,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 sleepq_switch(c484e000) at sleepq_switch+0xc9 sleepq_wait_sig(c484e000) at sleepq_wait_sig+0x1d msleep(c484e000,c484e060,15c,c095061f,0) at msleep+0x296 kern_wait(c47c2360,ffffffff,e69b3c28,6,0) at kern_wait+0x7c3 wait4(c47c2360,e69b3d00) at wait4+0x2a syscall(e69b3d38) at syscall+0x256 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (7, FreeBSD ELF32, wait4), eip = 0x2819eb1b, esp = 0xbfbfe1dc, ebp = 0xbfbfe1f8 --- Tracing command mutt pid 1256 tid 100127 td 0xc47c21b0 sched_switch(c47c21b0,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 sleepq_switch(c0a9be5c) at sleepq_switch+0xc9 sleepq_timedwait_sig(c0a9be5c,c0a9be5c,59368,e69b0ae4,246,...) at sleepq_timedwait_sig+0x1e cv_timedwait_sig(c0a9be5c,c0a9be44,59368) at cv_timedwait_sig+0x194 kern_select(c47c21b0,4,28159ca0,0,0,...) at kern_select+0x4a9 select(c47c21b0,e69b0d00) at select+0x44 syscall(e69b0d38) at syscall+0x256 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (93, FreeBSD ELF32, select), eip = 0x2854c1bf, esp = 0xbfbfd27c, ebp = 0xbfbfd2b8 --- Tracing command screen pid 1254 tid 100052 td 0xc409dd80 sched_switch(c409dd80,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 sleepq_switch(c0a9be5c) at sleepq_switch+0xc9 sleepq_wait_sig(c0a9be5c,246,c0a4ea90,c095006f,308,...) at sleepq_wait_sig+0x1d cv_wait_sig(c0a9be5c,c0a9be44) at cv_wait_sig+0x18b kern_select(c409dd80,14,bfbfe250,bfbfe1d0,0,...) at kern_select+0x4bf select(c409dd80,e468ed00) at select+0x44 syscall(e468ed38) at syscall+0x256 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (93, FreeBSD ELF32, select), eip = 0x281f01bf, esp = 0xbfbfe19c, ebp = 0xbfbfe2e8 --- Tracing command perl5.8.8 pid 1205 tid 100086 td 0xc4343510 sched_switch(c4343510,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 sleepq_switch(c0a9be5c) at sleepq_switch+0xc9 sleepq_timedwait_sig(c0a9be5c,c0a9be5c,3943b,e68e7ae4,246,...) at sleepq_timedwait_sig+0x1e cv_timedwait_sig(c0a9be5c,c0a9be44,3943b) at cv_timedwait_sig+0x194 kern_select(c4343510,10,9a07a90,0,0,...) at kern_select+0x4a9 select(c4343510,e68e7d00) at select+0x44 syscall(e68e7d38) at syscall+0x256 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (93, FreeBSD ELF32, select), eip = 0x282821bf, esp = 0xbfbfecbc, ebp = 0xbfbfed48 --- Tracing command getty pid 1198 tid 100105 td 0xc45db510 sched_switch(c45db510,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 sleepq_switch(c409ac10) at sleepq_switch+0xc9 sleepq_wait_sig(c409ac10) at sleepq_wait_sig+0x1d msleep(c409ac10,0,159,c0951c65,0) at msleep+0x296 ttysleep(c409ac00,c409ac10,159,c0951c65,0,...) at ttysleep+0x21 ttread(c409ac00,e699bc60,0) at ttread+0x48f ttyread(c40a1900,e699bc60,0,c0a4eaa8,0,...) at ttyread+0x2f giant_read(c40a1900,e699bc60,0) at giant_read+0x2d devfs_read_f(c46a3e58,e699bc60,c3efca80,0,c45db510) at devfs_read_f+0x62 dofileread(c45db510,0,c46a3e58,e699bc60,ffffffff,...) at dofileread+0x85 kern_readv(c45db510,0,e699bc60,bfbfee3f,1,...) at kern_readv+0x36 read(c45db510,e699bd00) at read+0x45 syscall(e699bd38) at syscall+0x256 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (3, FreeBSD ELF32, read), eip = 0x2815723f, esp = 0xbfbfee1c, ebp = 0xbfbfee48 --- Tracing command getty pid 1197 tid 100104 td 0xc45db6c0 sched_switch(c45db6c0,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 sleepq_switch(c40cc810) at sleepq_switch+0xc9 sleepq_wait_sig(c40cc810) at sleepq_wait_sig+0x1d msleep(c40cc810,0,159,c0951c65,0) at msleep+0x296 ttysleep(c40cc800,c40cc810,159,c0951c65,0,...) at ttysleep+0x21 ttread(c40cc800,e699ec60,0) at ttread+0x48f ttyread(c40bed00,e699ec60,0,e699ebb8,c069ba39,...) at ttyread+0x2f scread(c40bed00,e699ec60,0,c0a4eaa8,0,...) at scread+0x22 giant_read(c40bed00,e699ec60,0) at giant_read+0x2d devfs_read_f(c46b9318,e699ec60,c3efca80,0,c45db6c0) at devfs_read_f+0x62 dofileread(c45db6c0,0,c46b9318,e699ec60,ffffffff,...) at dofileread+0x85 kern_readv(c45db6c0,0,e699ec60,bfbfee3f,1,...) at kern_readv+0x36 read(c45db6c0,e699ed00) at read+0x45 syscall(e699ed38) at syscall+0x256 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (3, FreeBSD ELF32, read), eip = 0x2815723f, esp = 0xbfbfee1c, ebp = 0xbfbfee48 --- Tracing command getty pid 1196 tid 100055 td 0xc409d870 sched_switch(c409d870,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 sleepq_switch(c40c5010) at sleepq_switch+0xc9 sleepq_wait_sig(c40c5010) at sleepq_wait_sig+0x1d msleep(c40c5010,0,159,c0951c65,0) at msleep+0x296 ttysleep(c40c5000,c40c5010,159,c0951c65,0,...) at ttysleep+0x21 ttread(c40c5000,e4685c60,0) at ttread+0x48f ttyread(c40bec00,e4685c60,0,e4685bb8,c069ba39,...) at ttyread+0x2f scread(c40bec00,e4685c60,0,c0a4eaa8,0,...) at scread+0x22 giant_read(c40bec00,e4685c60,0) at giant_read+0x2d devfs_read_f(c46a3d80,e4685c60,c3efca80,0,c409d870) at devfs_read_f+0x62 dofileread(c409d870,0,c46a3d80,e4685c60,ffffffff,...) at dofileread+0x85 kern_readv(c409d870,0,e4685c60,bfbfee3f,1,...) at kern_readv+0x36 read(c409d870,e4685d00) at read+0x45 syscall(e4685d38) at syscall+0x256 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (3, FreeBSD ELF32, read), eip = 0x2815723f, esp = 0xbfbfee1c, ebp = 0xbfbfee48 --- Tracing command getty pid 1195 tid 100046 td 0xc4248870 sched_switch(c4248870,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 sleepq_switch(c40c3810) at sleepq_switch+0xc9 sleepq_wait_sig(c40c3810) at sleepq_wait_sig+0x1d msleep(c40c3810,0,159,c0951c65,0) at msleep+0x296 ttysleep(c40c3800,c40c3810,159,c0951c65,0,...) at ttysleep+0x21 ttread(c40c3800,e46cbc60,0) at ttread+0x48f ttyread(c40beb00,e46cbc60,0,e46cbbb8,c069ba39,...) at ttyread+0x2f scread(c40beb00,e46cbc60,0,c0a4eaa8,0,...) at scread+0x22 giant_read(c40beb00,e46cbc60,0) at giant_read+0x2d devfs_read_f(c4292090,e46cbc60,c3efca80,0,c4248870) at devfs_read_f+0x62 dofileread(c4248870,0,c4292090,e46cbc60,ffffffff,...) at dofileread+0x85 kern_readv(c4248870,0,e46cbc60,bfbfee3f,1,...) at kern_readv+0x36 read(c4248870,e46cbd00) at read+0x45 syscall(e46cbd38) at syscall+0x256 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (3, FreeBSD ELF32, read), eip = 0x2815723f, esp = 0xbfbfee1c, ebp = 0xbfbfee48 --- Tracing command getty pid 1194 tid 100082 td 0xc4343bd0 sched_switch(c4343bd0,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 sleepq_switch(c40bb410) at sleepq_switch+0xc9 sleepq_wait_sig(c40bb410) at sleepq_wait_sig+0x1d msleep(c40bb410,0,159,c0951c65,0) at msleep+0x296 ttysleep(c40bb400,c40bb410,159,c0951c65,0,...) at ttysleep+0x21 ttread(c40bb400,e68f3c60,0) at ttread+0x48f ttyread(c40bea00,e68f3c60,0,e68f3bb8,c069ba39,...) at ttyread+0x2f scread(c40bea00,e68f3c60,0,c0a4eaa8,0,...) at scread+0x22 giant_read(c40bea00,e68f3c60,0) at giant_read+0x2d devfs_read_f(c46a3ab0,e68f3c60,c3efca80,0,c4343bd0) at devfs_read_f+0x62 dofileread(c4343bd0,0,c46a3ab0,e68f3c60,ffffffff,...) at dofileread+0x85 kern_readv(c4343bd0,0,e68f3c60,bfbfee3f,1,...) at kern_readv+0x36 read(c4343bd0,e68f3d00) at read+0x45 syscall(e68f3d38) at syscall+0x256 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (3, FreeBSD ELF32, read), eip = 0x2815723f, esp = 0xbfbfee1c, ebp = 0xbfbfee48 --- Tracing command getty pid 1193 tid 100073 td 0xc44ecbd0 sched_switch(c44ecbd0,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 sleepq_switch(c40c4010) at sleepq_switch+0xc9 sleepq_wait_sig(c40c4010) at sleepq_wait_sig+0x1d msleep(c40c4010,0,159,c0951c65,0) at msleep+0x296 ttysleep(c40c4000,c40c4010,159,c0951c65,0,...) at ttysleep+0x21 ttread(c40c4000,e692cc60,0) at ttread+0x48f ttyread(c40be900,e692cc60,0,e692cbb8,c069ba39,...) at ttyread+0x2f scread(c40be900,e692cc60,0,c0a4eaa8,0,...) at scread+0x22 giant_read(c40be900,e692cc60,0) at giant_read+0x2d devfs_read_f(c46a32d0,e692cc60,c3efca80,0,c44ecbd0) at devfs_read_f+0x62 dofileread(c44ecbd0,0,c46a32d0,e692cc60,ffffffff,...) at dofileread+0x85 kern_readv(c44ecbd0,0,e692cc60,bfbfee3f,1,...) at kern_readv+0x36 read(c44ecbd0,e692cd00) at read+0x45 syscall(e692cd38) at syscall+0x256 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (3, FreeBSD ELF32, read), eip = 0x2815723f, esp = 0xbfbfee1c, ebp = 0xbfbfee48 --- Tracing command inetd pid 1174 tid 100085 td 0xc43436c0 sched_switch(c43436c0,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 sleepq_switch(c0a9be5c) at sleepq_switch+0xc9 sleepq_wait_sig(c0a9be5c,246,c0a4ea90,c095006f,308,...) at sleepq_wait_sig+0x1d cv_wait_sig(c0a9be5c,c0a9be44) at cv_wait_sig+0x18b kern_select(c43436c0,9,bfbfe8b0,0,0,...) at kern_select+0x4bf select(c43436c0,e68ead00) at select+0x44 syscall(e68ead38) at syscall+0x256 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (93, FreeBSD ELF32, select), eip = 0x281691bf, esp = 0xbfbfdb8c, ebp = 0xbfbfee78 --- Tracing command cron pid 1141 tid 100064 td 0xc4342510 sched_switch(c4342510,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 sleepq_switch(c0a4f2a4) at sleepq_switch+0xc9 sleepq_timedwait_sig(c0a4f2a4) at sleepq_timedwait_sig+0x1e msleep(c0a4f2a4,0,15c,c094c10d,ea61,...) at msleep+0x26c kern_nanosleep(c4342510,e68ccc70,e68ccc68) at kern_nanosleep+0xab nanosleep(c4342510,e68ccd00) at nanosleep+0x4f syscall(e68ccd38) at syscall+0x256 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (240, FreeBSD ELF32, nanosleep), eip = 0x2813fc3b, esp = 0xbfbfecec, ebp = 0xbfbfed18 --- Tracing command sshd pid 1133 tid 100095 td 0xc44eed80 sched_switch(c44eed80,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 sleepq_switch(c0a9be5c) at sleepq_switch+0xc9 sleepq_wait_sig(c0a9be5c,246,c0a4ea90,c095006f,308,...) at sleepq_wait_sig+0x1d cv_wait_sig(c0a9be5c,c0a9be44) at cv_wait_sig+0x18b kern_select(c44eed80,a,284c1144,0,0,...) at kern_select+0x4bf select(c44eed80,e694ad00) at select+0x44 syscall(e694ad38) at syscall+0x256 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (93, FreeBSD ELF32, select), eip = 0x283841bf, esp = 0xbfbfe18c, ebp = 0xbfbfee98 --- Tracing command couriertcpd pid 1119 tid 100066 td 0xc43421b0 sched_switch(c43421b0,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 sleepq_switch(c0a9be5c) at sleepq_switch+0xc9 sleepq_wait_sig(c0a9be5c,246,c0a4ea90,c095006f,308,...) at sleepq_wait_sig+0x1d cv_wait_sig(c0a9be5c,c0a9be44) at cv_wait_sig+0x18b kern_select(c43421b0,6,bfbfe630,0,0,...) at kern_select+0x4bf select(c43421b0,e68c6d00) at select+0x44 syscall(e68c6d38) at syscall+0x256 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (93, FreeBSD ELF32, select), eip = 0x281521bf, esp = 0xbfbfe4ac, ebp = 0xbfbfe6c8 --- Tracing command courierlogger pid 1118 tid 100059 td 0xc4342d80 sched_switch(c4342d80,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 sleepq_switch(c46ad318) at sleepq_switch+0xc9 sleepq_wait_sig(c46ad318) at sleepq_wait_sig+0x1d msleep(c46ad318,c46ad488,14c,c09502df,0) at msleep+0x296 pipe_read(c46a3bd0,e68dbc60,c3efca80,0,c4342d80) at pipe_read+0x377 dofileread(c4342d80,0,c46a3bd0,e68dbc60,ffffffff,...) at dofileread+0x85 kern_readv(c4342d80,0,e68dbc60,28201000,1000,...) at kern_readv+0x36 read(c4342d80,e68dbd00) at read+0x45 syscall(e68dbd38) at syscall+0x256 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (3, FreeBSD ELF32, read), eip = 0x2814a23f, esp = 0xbfbfe32c, ebp = 0xbfbfe348 --- Tracing command couriertcpd pid 1107 tid 100088 td 0xc4596a20 sched_switch(c4596a20,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 sleepq_switch(c0a9be5c) at sleepq_switch+0xc9 sleepq_wait_sig(c0a9be5c,246,c0a4ea90,c095006f,308,...) at sleepq_wait_sig+0x1d cv_wait_sig(c0a9be5c,c0a9be44) at cv_wait_sig+0x18b kern_select(c4596a20,6,bfbfe9e0,0,0,...) at kern_select+0x4bf select(c4596a20,e695fd00) at select+0x44 syscall(e695fd38) at syscall+0x256 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (93, FreeBSD ELF32, select), eip = 0x281521bf, esp = 0xbfbfe85c, ebp = 0xbfbfea78 --- Tracing command courierlogger pid 1106 tid 100106 td 0xc45db360 sched_switch(c45db360,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 sleepq_switch(c46ad7bc) at sleepq_switch+0xc9 sleepq_wait_sig(c46ad7bc) at sleepq_wait_sig+0x1d msleep(c46ad7bc,c46ad92c,14c,c09502df,0) at msleep+0x296 pipe_read(c46a3558,e6998c60,c3efca80,0,c45db360) at pipe_read+0x377 dofileread(c45db360,0,c46a3558,e6998c60,ffffffff,...) at dofileread+0x85 kern_readv(c45db360,0,e6998c60,28201000,1000,...) at kern_readv+0x36 read(c45db360,e6998d00) at read+0x45 syscall(e6998d38) at syscall+0x256 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (3, FreeBSD ELF32, read), eip = 0x2814a23f, esp = 0xbfbfe6ec, ebp = 0xbfbfe708 --- Tracing command qmgr pid 1102 tid 100080 td 0xc44ec000 sched_switch(c44ec000,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 sleepq_switch(c0a9be5c) at sleepq_switch+0xc9 sleepq_timedwait_sig(c0a9be5c,c0a9be5c,734f,e6917ae4,246,...) at sleepq_timedwait_sig+0x1e cv_timedwait_sig(c0a9be5c,c0a9be44,734f) at cv_timedwait_sig+0x194 kern_select(c44ec000,14,bfbfe8d0,bfbfe850,bfbfe7d0,...) at kern_select+0x4a9 select(c44ec000,e6917d00) at select+0x44 syscall(e6917d38) at syscall+0x256 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (93, FreeBSD ELF32, select), eip = 0x281881bf, esp = 0xbfbfe79c, ebp = 0xbfbfe968 --- Tracing command master pid 1090 tid 100041 td 0xc409c1b0 sched_switch(c409c1b0,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 sleepq_switch(c0a9be5c) at sleepq_switch+0xc9 sleepq_timedwait_sig(c0a9be5c,c0a9be5c,6d4d,e465eae4,246,...) at sleepq_timedwait_sig+0x1e cv_timedwait_sig(c0a9be5c,c0a9be44,6d4d) at cv_timedwait_sig+0x194 kern_select(c409c1b0,63,bfbfeb60,bfbfeae0,bfbfea60,...) at kern_select+0x4a9 select(c409c1b0,e465ed00) at select+0x44 syscall(e465ed38) at syscall+0x256 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (93, FreeBSD ELF32, select), eip = 0x281771bf, esp = 0xbfbfea2c, ebp = 0xbfbfebf8 --- Tracing command authdaemond pid 1044 tid 100099 td 0xc44ee6c0 sched_switch(c44ee6c0,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 sleepq_switch(c0a9be5c) at sleepq_switch+0xc9 sleepq_timedwait_sig(c0a9be5c,c0a9be5c,2af99,e693eae4,246,...) at sleepq_timedwait_sig+0x1e cv_timedwait_sig(c0a9be5c,c0a9be44,2af99) at cv_timedwait_sig+0x194 kern_select(c44ee6c0,6,bfbfec10,0,0,...) at kern_select+0x4a9 select(c44ee6c0,e693ed00) at select+0x44 syscall(e693ed38) at syscall+0x256 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (93, FreeBSD ELF32, select), eip = 0x2815f1bf, esp = 0xbfbfe37c, ebp = 0xbfbfed28 --- Tracing command authdaemond pid 1043 tid 100102 td 0xc44ee1b0 sched_switch(c44ee1b0,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 sleepq_switch(c0a9be5c) at sleepq_switch+0xc9 sleepq_timedwait_sig(c0a9be5c,c0a9be5c,493e1,e6935ae4,246,...) at sleepq_timedwait_sig+0x1e cv_timedwait_sig(c0a9be5c,c0a9be44,493e1) at cv_timedwait_sig+0x194 kern_select(c44ee1b0,6,bfbfec10,0,0,...) at kern_select+0x4a9 select(c44ee1b0,e6935d00) at select+0x44 syscall(e6935d38) at syscall+0x256 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (93, FreeBSD ELF32, select), eip = 0x2815f1bf, esp = 0xbfbfe37c, ebp = 0xbfbfed28 --- Tracing command authdaemond pid 1042 tid 100077 td 0xc44ec510 sched_switch(c44ec510,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 sleepq_switch(c0a9be5c) at sleepq_switch+0xc9 sleepq_timedwait_sig(c0a9be5c,c0a9be5c,493e1,e6920ae4,246,...) at sleepq_timedwait_sig+0x1e cv_timedwait_sig(c0a9be5c,c0a9be44,493e1) at cv_timedwait_sig+0x194 kern_select(c44ec510,6,bfbfec10,0,0,...) at kern_select+0x4a9 select(c44ec510,e6920d00) at select+0x44 syscall(e6920d38) at syscall+0x256 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (93, FreeBSD ELF32, select), eip = 0x2815f1bf, esp = 0xbfbfe37c, ebp = 0xbfbfed28 --- Tracing command authdaemond pid 1041 tid 100092 td 0xc4596360 sched_switch(c4596360,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 sleepq_switch(c0a9be5c) at sleepq_switch+0xc9 sleepq_timedwait_sig(c0a9be5c,c0a9be5c,3a1ca,e6953ae4,246,...) at sleepq_timedwait_sig+0x1e cv_timedwait_sig(c0a9be5c,c0a9be44,3a1ca) at cv_timedwait_sig+0x194 kern_select(c4596360,6,bfbfec10,0,0,...) at kern_select+0x4a9 select(c4596360,e6953d00) at select+0x44 syscall(e6953d38) at syscall+0x256 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (93, FreeBSD ELF32, select), eip = 0x2815f1bf, esp = 0xbfbfe37c, ebp = 0xbfbfed28 --- Tracing command authdaemond pid 1040 tid 100093 td 0xc45961b0 sched_switch(c45961b0,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 sleepq_switch(c0a9be5c) at sleepq_switch+0xc9 sleepq_timedwait_sig(c0a9be5c,c0a9be5c,2af86,e6950ae4,246,...) at sleepq_timedwait_sig+0x1e cv_timedwait_sig(c0a9be5c,c0a9be44,2af86) at cv_timedwait_sig+0x194 kern_select(c45961b0,6,bfbfec10,0,0,...) at kern_select+0x4a9 select(c45961b0,e6950d00) at select+0x44 syscall(e6950d38) at syscall+0x256 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (93, FreeBSD ELF32, select), eip = 0x2815f1bf, esp = 0xbfbfe37c, ebp = 0xbfbfed28 --- Tracing command authdaemond pid 1033 tid 100096 td 0xc44eebd0 sched_switch(c44eebd0,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 sleepq_switch(c0a9be5c) at sleepq_switch+0xc9 sleepq_timedwait_sig(c0a9be5c,c0a9be5c,21269,e6947ae4,246,...) at sleepq_timedwait_sig+0x1e cv_timedwait_sig(c0a9be5c,c0a9be44,21269) at cv_timedwait_sig+0x194 kern_select(c44eebd0,6,bfbfec10,0,0,...) at kern_select+0x4a9 select(c44eebd0,e6947d00) at select+0x44 syscall(e6947d38) at syscall+0x256 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (93, FreeBSD ELF32, select), eip = 0x2815f1bf, esp = 0xbfbfe37c, ebp = 0xbfbfed28 --- Tracing command courierlogger pid 1032 tid 100097 td 0xc44eea20 sched_switch(c44eea20,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 sleepq_switch(c4298948) at sleepq_switch+0xc9 sleepq_wait_sig(c4298948) at sleepq_wait_sig+0x1d msleep(c4298948,c4298ab8,14c,c09502df,0) at msleep+0x296 pipe_read(c430d900,e6944c60,c3efca80,0,c44eea20) at pipe_read+0x377 dofileread(c44eea20,0,c430d900,e6944c60,ffffffff,...) at dofileread+0x85 kern_readv(c44eea20,0,e6944c60,28201000,1000,...) at kern_readv+0x36 read(c44eea20,e6944d00) at read+0x45 syscall(e6944d38) at syscall+0x256 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (3, FreeBSD ELF32, read), eip = 0x2814a23f, esp = 0xbfbfe9ac, ebp = 0xbfbfe9c8 --- Tracing command perl5.8.8 pid 1025 tid 100103 td 0xc45db870 sched_switch(c45db870,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 sleepq_switch(c0a9be5c) at sleepq_switch+0xc9 sleepq_timedwait_sig(c0a9be5c,c0a9be5c,7d1,e69a1ae4,246,...) at sleepq_timedwait_sig+0x1e cv_timedwait_sig(c0a9be5c,c0a9be44,7d1) at cv_timedwait_sig+0x194 kern_select(c45db870,10,96c14f0,0,96c1440,...) at kern_select+0x4a9 select(c45db870,e69a1d00) at select+0x44 syscall(e69a1d38) at syscall+0x256 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (93, FreeBSD ELF32, select), eip = 0x282821bf, esp = 0xbfbfecbc, ebp = 0xbfbfed48 --- Tracing command dhcpd pid 1018 tid 100107 td 0xc45db1b0 sched_switch(c45db1b0,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 sleepq_switch(c0a9be5c) at sleepq_switch+0xc9 sleepq_timedwait_sig(c0a9be5c,c0a9be5c,2749f3,e6995ae4,246,...) at sleepq_timedwait_sig+0x1e cv_timedwait_sig(c0a9be5c,c0a9be44,2749f3) at cv_timedwait_sig+0x194 kern_select(c45db1b0,8,bfbfec30,bfbfebb0,bfbfeb30,...) at kern_select+0x4a9 select(c45db1b0,e6995d00) at select+0x44 syscall(e6995d38) at syscall+0x256 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (93, FreeBSD ELF32, select), eip = 0x281b11bf, esp = 0xbfbfeacc, ebp = 0xbfbfecc8 --- Tracing command rwhod pid 924 tid 100081 td 0xc4343d80 sched_switch(c4343d80,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 sleepq_switch(c45b89b0) at sleepq_switch+0xc9 sleepq_wait_sig(c45b89b0) at sleepq_wait_sig+0x1d msleep(c45b89b0,c45b8988,158,c0953043,0,...) at msleep+0x296 sbwait(c45b8964,c0a9bc4c,e68f6b70,c06ed422,c0a9bc48,...) at sbwait+0x48 soreceive_generic(c45b8914,e68f6be0,e68f6bec,0,0,...) at soreceive_generic+0x2da soreceive(c45b8914,e68f6be0,e68f6bec,0,0,e68f6c74) at soreceive+0x39 kern_recvit(c4343d80,4,e68f6c5c,0,0) at kern_recvit+0x188 recvit(c4343d80,4,e68f6c5c,bfbfe980) at recvit+0x1b recvfrom(c4343d80,e68f6d00) at recvfrom+0x6c syscall(e68f6d38) at syscall+0x256 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (29, FreeBSD ELF32, recvfrom), eip = 0x28107cbb, esp = 0xbfbfe92c, ebp = 0xbfbfee98 --- Tracing command ntpd pid 911 tid 100084 td 0xc4343870 sched_switch(c4343870,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 sleepq_switch(c0a9be5c) at sleepq_switch+0xc9 sleepq_wait_sig(c0a9be5c,246,c0a4ea90,c095006f,308,...) at sleepq_wait_sig+0x1d cv_wait_sig(c0a9be5c,c0a9be44) at cv_wait_sig+0x18b kern_select(c4343870,b,bfbfed70,0,0,...) at kern_select+0x4bf select(c4343870,e68edd00) at select+0x44 syscall(e68edd38) at syscall+0x256 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (93, FreeBSD ELF32, select), eip = 0x282c81bf, esp = 0xbfbfed2c, ebp = 0xbfbfee08 --- Tracing command lpd pid 895 tid 100042 td 0xc409c000 sched_switch(c409c000,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 sleepq_switch(c0a9be5c) at sleepq_switch+0xc9 sleepq_wait_sig(c0a9be5c,246,c0a4ea90,c095006f,308,...) at sleepq_wait_sig+0x1d cv_wait_sig(c0a9be5c,c0a9be44) at cv_wait_sig+0x18b kern_select(c409c000,14,bfbfead0,0,0,...) at kern_select+0x4bf select(c409c000,e465bd00) at select+0x44 syscall(e465bd38) at syscall+0x256 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (93, FreeBSD ELF32, select), eip = 0x281561bf, esp = 0xbfbfe0ec, ebp = 0xbfbfee98 --- Tracing command rpc.lockd pid 874 tid 100065 td 0xc4342360 sched_switch(c4342360,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 sleepq_switch(c0aa3848) at sleepq_switch+0xc9 sleepq_wait_sig(c0aa3848) at sleepq_wait_sig+0x1d msleep(c0aa3848,c0aa382c,158,c0962239,0) at msleep+0x296 nfslock_read(c3f58400,e68c9c60,4) at nfslock_read+0x5f devfs_read_f(c4291af8,e68c9c60,c4599700,0,c4342360) at devfs_read_f+0x62 dofileread(c4342360,8,c4291af8,e68c9c60,ffffffff,...) at dofileread+0x85 kern_readv(c4342360,8,e68c9c60,bfbfec70,194,...) at kern_readv+0x36 read(c4342360,e68c9d00) at read+0x45 syscall(e68c9d38) at syscall+0x256 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (3, FreeBSD ELF32, read), eip = 0x2816423f, esp = 0xbfbfec3c, ebp = 0xbfbfee18 --- Tracing command rpc.lockd pid 866 tid 100076 td 0xc44ec6c0 sched_switch(c44ec6c0,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 sleepq_switch(c0a9be5c) at sleepq_switch+0xc9 sleepq_timedwait_sig(c0a9be5c,c0a9be5c,403c,e6923ae4,246,...) at sleepq_timedwait_sig+0x1e cv_timedwait_sig(c0a9be5c,c0a9be44,403c) at cv_timedwait_sig+0x194 kern_select(c44ec6c0,7,bfbfed80,0,0,...) at kern_select+0x4a9 select(c44ec6c0,e6923d00) at select+0x44 syscall(e6923d38) at syscall+0x256 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (93, FreeBSD ELF32, select), eip = 0x281641bf, esp = 0xbfbfecbc, ebp = 0xbfbfee18 --- Tracing command rpc.statd pid 861 tid 100089 td 0xc4596870 sched_switch(c4596870,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 sleepq_switch(c0a9be5c) at sleepq_switch+0xc9 sleepq_timedwait_sig(c0a9be5c,c0a9be5c,403c,e695cae4,246,...) at sleepq_timedwait_sig+0x1e cv_timedwait_sig(c0a9be5c,c0a9be44,403c) at cv_timedwait_sig+0x194 kern_select(c4596870,8,bfbfed90,0,0,...) at kern_select+0x4a9 select(c4596870,e695cd00) at select+0x44 syscall(e695cd38) at syscall+0x256 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (93, FreeBSD ELF32, select), eip = 0x281521bf, esp = 0xbfbfeccc, ebp = 0xbfbfee28 --- Tracing command rpcbind pid 827 tid 100069 td 0xc4248bd0 sched_switch(c4248bd0,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 sleepq_switch(c0a9be5c) at sleepq_switch+0xc9 sleepq_timedwait_sig(c0a9be5c,c0a9be5c,403c,e46d1b28,246,...) at sleepq_timedwait_sig+0x1e cv_timedwait_sig(c0a9be5c,c0a9be44,403c) at cv_timedwait_sig+0x194 poll(c4248bd0,e46d1d00) at poll+0x3a3 syscall(e46d1d38) at syscall+0x256 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (209, FreeBSD ELF32, poll), eip = 0x28113adf, esp = 0xbfbfcc6c, ebp = 0xbfbfee38 --- Tracing command named pid 817 tid 100072 td 0xc44ecd80 sched_switch(c44ecd80,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 sleepq_switch(c0a9be5c) at sleepq_switch+0xc9 sleepq_timedwait_sig(c0a9be5c,c0a9be5c,1e0b,e692fae4,246,...) at sleepq_timedwait_sig+0x1e cv_timedwait_sig(c0a9be5c,c0a9be44,1e0b) at cv_timedwait_sig+0x194 kern_select(c44ecd80,26,bfbfed60,bfbfece0,0,...) at kern_select+0x4a9 select(c44ecd80,e692fd00) at select+0x44 syscall(e692fd38) at syscall+0x256 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (93, FreeBSD ELF32, select), eip = 0x2839c1bf, esp = 0xbfbfec9c, ebp = 0xbfbfedf8 --- Tracing command syslogd pid 754 tid 100057 td 0xc43431b0 sched_switch(c43431b0,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 sleepq_switch(c0a9be5c) at sleepq_switch+0xc9 sleepq_wait_sig(c0a9be5c,246,c0a4ea90,c095006f,308,...) at sleepq_wait_sig+0x1d cv_wait_sig(c0a9be5c,c0a9be44) at cv_wait_sig+0x18b kern_select(c43431b0,b,28208144,0,0,...) at kern_select+0x4bf select(c43431b0,e68e1d00) at select+0x44 syscall(e68e1d38) at syscall+0x256 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (93, FreeBSD ELF32, select), eip = 0x2815b1bf, esp = 0xbfbfd9fc, ebp = 0xbfbfee48 --- Tracing command watchquagga pid 729 tid 100050 td 0xc42481b0 sched_switch(c42481b0,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 sleepq_switch(c0a9be5c) at sleepq_switch+0xc9 sleepq_timedwait_sig(c0a9be5c,c0a9be5c,117e,e46bfae4,246,...) at sleepq_timedwait_sig+0x1e cv_timedwait_sig(c0a9be5c,c0a9be44,117e) at cv_timedwait_sig+0x194 kern_select(c42481b0,14,bfbfecb0,bfbfec30,bfbfebb0,...) at kern_select+0x4a9 select(c42481b0,e46bfd00) at select+0x44 syscall(e46bfd38) at syscall+0x256 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (93, FreeBSD ELF32, select), eip = 0x281c31bf, esp = 0xbfbfeb4c, ebp = 0xbfbfed48 --- Tracing command ospfd pid 724 tid 100051 td 0xc4248000 sched_switch(c4248000,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 sleepq_switch(c0a9be5c) at sleepq_switch+0xc9 sleepq_timedwait_sig(c0a9be5c,c0a9be5c,73,e46bcae4,246,...) at sleepq_timedwait_sig+0x1e cv_timedwait_sig(c0a9be5c,c0a9be44,73) at cv_timedwait_sig+0x194 kern_select(c4248000,14,bfbfed10,bfbfec90,bfbfec10,...) at kern_select+0x4a9 select(c4248000,e46bcd00) at select+0x44 syscall(e46bcd38) at syscall+0x256 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (93, FreeBSD ELF32, select), eip = 0x282201bf, esp = 0xbfbfebac, ebp = 0xbfbfeda8 --- Tracing command zebra pid 718 tid 100056 td 0xc4343360 sched_switch(c4343360,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 sleepq_switch(c0a9be5c) at sleepq_switch+0xc9 sleepq_wait_sig(c0a9be5c,246,c0a4ea90,c095006f,308,...) at sleepq_wait_sig+0x1d cv_wait_sig(c0a9be5c,c0a9be44) at cv_wait_sig+0x18b kern_select(c4343360,14,bfbfed10,bfbfec90,bfbfec10,...) at kern_select+0x4bf select(c4343360,e68e4d00) at select+0x44 syscall(e68e4d38) at syscall+0x256 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (93, FreeBSD ELF32, select), eip = 0x281d91bf, esp = 0xbfbfebac, ebp = 0xbfbfeda8 --- Tracing command devd pid 658 tid 100043 td 0xc4007d80 sched_switch(c4007d80,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 sleepq_switch(c0a9be5c) at sleepq_switch+0xc9 sleepq_wait_sig(c0a9be5c,246,c0a4ea90,c095006f,308,...) at sleepq_wait_sig+0x1d cv_wait_sig(c0a9be5c,c0a9be44) at cv_wait_sig+0x18b kern_select(c4007d80,5,bfbfe9f0,0,0,...) at kern_select+0x4bf select(c4007d80,e4406d00) at select+0x44 syscall(e4406d38) at syscall+0x256 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (93, FreeBSD ELF32, select), eip = 0x807a2bf, esp = 0xbfbfe98c, ebp = 0xbfbfee98 --- Tracing command pflogd pid 436 tid 100039 td 0xc409c510 sched_switch(c409c510,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 sleepq_switch(c4496e00) at sleepq_switch+0xc9 sleepq_timedwait_sig(c4496e00) at sleepq_timedwait_sig+0x1e msleep(c4496e00,c4496e74,11a,c09569e8,1f4) at msleep+0x26c bpfread(c4497000,e4664c60,0,c0a4eaa8,0,...) at bpfread+0x13a giant_read(c4497000,e4664c60,0) at giant_read+0x2d devfs_read_f(c4291630,e4664c60,c40d2380,0,c409c510) at devfs_read_f+0x62 dofileread(c409c510,3,c4291630,e4664c60,ffffffff,...) at dofileread+0x85 kern_readv(c409c510,3,e4664c60,28208000,8000,...) at kern_readv+0x36 read(c409c510,e4664d00) at read+0x45 syscall(e4664d38) at syscall+0x256 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (3, FreeBSD ELF32, read), eip = 0x2817c23f, esp = 0xbfbfed9c, ebp = 0xbfbfedf8 --- Tracing command pflogd pid 431 tid 100044 td 0xc4007bd0 sched_switch(c4007bd0,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 sleepq_switch(c433a1e8) at sleepq_switch+0xc9 sleepq_wait_sig(c433a1e8) at sleepq_wait_sig+0x1d msleep(c433a1e8,c433a1c0,158,c0953043,0,...) at msleep+0x296 sbwait(c433a19c,2,c094ccee,91,c4007bd0,...) at sbwait+0x48 soreceive_generic(c433a14c,0,e4403c60,0,0,...) at soreceive_generic+0x2da soreceive(c433a14c,0,e4403c60,0,0,0) at soreceive+0x39 soo_read(c4292d38,e4403c60,c3efca80,0,c4007bd0) at soo_read+0x3d dofileread(c4007bd0,4,c4292d38,e4403c60,ffffffff,...) at dofileread+0x85 kern_readv(c4007bd0,4,e4403c60,bfbfee08,4,...) at kern_readv+0x36 read(c4007bd0,e4403d00) at read+0x45 syscall(e4403d38) at syscall+0x256 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (3, FreeBSD ELF32, read), eip = 0x2817c23f, esp = 0xbfbfedec, ebp = 0xbfbfee28 --- Tracing command adjkerntz pid 165 tid 100038 td 0xc409c6c0 sched_switch(c409c6c0,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 sleepq_switch(c40a06e4) at sleepq_switch+0xc9 sleepq_wait_sig(c40a06e4) at sleepq_wait_sig+0x1d msleep(c40a06e4,c40a0720,168,c090f176,0) at msleep+0x296 kern_sigsuspend(c409c6c0,0,0,0,0,...) at kern_sigsuspend+0xa3 sigsuspend(c409c6c0,e4667d00) at sigsuspend+0x33 syscall(e4667d38) at syscall+0x256 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (341, FreeBSD ELF32, sigsuspend), eip = 0x280c144f, esp = 0xbfbfedac, ebp = 0xbfbfee88 --- Tracing command schedcpu pid 41 tid 100047 td 0xc42486c0 sched_switch(c42486c0,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 sleepq_switch(e46c8cfc,c0a4ea90,0,c094e4e3,243,...) at sleepq_switch+0xc9 sleepq_timedwait(e46c8cfc) at sleepq_timedwait+0x4a msleep(e46c8cfc,0,0,c0943377,3e8) at msleep+0x281 schedcpu_thread(0,e46c8d38) at schedcpu_thread+0x26 fork_exit(c06d7768,0,e46c8d38) at fork_exit+0xac fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe46c8d70, ebp = 0 --- Tracing command softdepflush pid 40 tid 100048 td 0xc4248510 sched_switch(c4248510,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 sleepq_switch(c0aa8a84,c0a4ea90,0,c094e4e3,243,...) at sleepq_switch+0xc9 sleepq_timedwait(c0aa8a84) at sleepq_timedwait+0x4a msleep(c0aa8a84,c0aa8a5c,44,c09650a2,3e8) at msleep+0x281 softdep_flush(0,e46c5d38) at softdep_flush+0x1f3 fork_exit(c07fda40,0,e46c5d38) at fork_exit+0xac fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe46c5d70, ebp = 0 --- Tracing command vnlru pid 39 tid 100049 td 0xc4248360 sched_switch(c4248360,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 sleepq_switch(c4249000,c0a4ea90,0,c094e4e3,243,...) at sleepq_switch+0xc9 sleepq_timedwait(c4249000) at sleepq_timedwait+0x4a msleep(c4249000,c0a9c5b8,250,c0955f23,3e8,c0a9c618) at msleep+0x281 vnlru_proc(0,e46c2d38) at vnlru_proc+0xdf fork_exit(c07222a0,0,e46c2d38) at fork_exit+0xac fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe46c2d70, ebp = 0 --- Tracing command syncer pid 38 tid 100027 td 0xc3f02d80 sched_switch(c3f02d80,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 sleepq_switch(c0a4f06c,c0a4ea90,0,c094e4e3,21e,...) at sleepq_switch+0xc9 sleepq_wait(c0a4f06c,0,c0955e55,641,c0955e55,...) at sleepq_wait+0x46 msleep(c0a4f06c,c0a9c5e4,68,c0956220,0) at msleep+0x2a5 sched_sync(0,e29c8d38) at sched_sync+0x2fe fork_exit(c0723f28,0,e29c8d38) at fork_exit+0xac fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe29c8d70, ebp = 0 --- Tracing command bufdaemon pid 37 tid 100028 td 0xc3f02bd0 sched_switch(c3f02bd0,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 sleepq_switch(c0a9c2e8,c0a4ea90,0,c094e4e3,243,...) at sleepq_switch+0xc9 sleepq_timedwait(c0a9c2e8) at sleepq_timedwait+0x4a msleep(c0a9c2e8,c0a9c2ec,44,c0954698,3e8) at msleep+0x281 buf_daemon(0,e29c5d38) at buf_daemon+0x198 fork_exit(c0713ac4,0,e29c5d38) at fork_exit+0xac fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe29c5d70, ebp = 0 --- Tracing command pagezero pid 36 tid 100029 td 0xc3f02a20 sched_switch(c3f02a20,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 sleepq_switch(c0ab13d0,c0a4ea90,0,c094e4e3,243,...) at sleepq_switch+0xc9 sleepq_timedwait(c0ab13d0) at sleepq_timedwait+0x4a msleep(c0ab13d0,c0aa9284,0,c096a141,493e0) at msleep+0x281 vm_pagezero(0,e29c2d38) at vm_pagezero+0x6b fork_exit(c0830814,0,e29c2d38) at fork_exit+0xac fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe29c2d70, ebp = 0 --- Tracing command vmdaemon pid 35 tid 100030 td 0xc3f02870 sched_switch(c3f02870,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 sleepq_switch(c0aa9300,c0a4ea90,0,c094e4e3,21e,...) at sleepq_switch+0xc9 sleepq_wait(c0aa9300,0,c06b996c,c0a4eaa8,c0969cf8,...) at sleepq_wait+0x46 msleep(c0aa9300,0,68,c0954698,0) at msleep+0x2a5 vm_daemon(0,e29bfd38) at vm_daemon+0x36 fork_exit(c082f44c,0,e29bfd38) at fork_exit+0xac fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe29bfd70, ebp = 0 --- Tracing command pagedaemon pid 34 tid 100031 td 0xc3f026c0 sched_switch(c3f026c0,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 sleepq_switch(c0aa92c0,c0a4ea90,0,c094e4e3,243,...) at sleepq_switch+0xc9 sleepq_timedwait(c0aa92c0) at sleepq_timedwait+0x4a msleep(c0aa92c0,c0aa9284,44,c0954698,1388) at msleep+0x281 vm_pageout(0,e29bcd38) at vm_pageout+0x268 fork_exit(c082f0d4,0,e29bcd38) at fork_exit+0xac fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe29bcd70, ebp = 0 --- Tracing command irq7: ppc0 pid 33 tid 100032 td 0xc3f02510 fork_trampoline() at fork_trampoline Tracing command irq1: atkbd0 pid 32 tid 100033 td 0xc409d000 fork_trampoline() at fork_trampoline Tracing command swi0: sio pid 31 tid 100034 td 0xc409cd80 sched_switch(c409cd80,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 ithread_loop(c40b6200,e4673d38) at ithread_loop+0xda fork_exit(c06adf00,c40b6200,e4673d38) at fork_exit+0xac fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe4673d70, ebp = 0 --- Tracing command em0 taskq pid 30 tid 100035 td 0xc409cbd0 sched_switch(c409cbd0,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 sleepq_switch(c4041200,c0a4ea90,0,c094e4e3,21e,...) at sleepq_switch+0xc9 sleepq_wait(c4041200,c3ff2204,c3ff2204,e4670cec,c06e8952,...) at sleepq_wait+0x46 msleep_spin(c4041200,c404121c,c0943377,0) at msleep_spin+0x1a1 taskqueue_thread_loop(c3ff2214,e4670d38) at taskqueue_thread_loop+0x61 fork_exit(c06e8c4c,c3ff2214,e4670d38) at fork_exit+0xac fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe4670d70, ebp = 0 --- Tracing command irq18: fxp1 em0 pid 29 tid 100036 td 0xc409ca20 sched_switch(c409ca20,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 turnstile_wait(c0a9df6c,c45dabd0,0,c0a9df6c,2,c094a0d3,166) at turnstile_wait+0x3ea _mtx_lock_sleep(c0a9df6c,c409ca20,0,c4466e24,ac8) at _mtx_lock_sleep+0x145 _mtx_lock_flags(c0a9df6c,0,c4466e24,ac8,c0a9df6c,...) at _mtx_lock_flags+0xab pf_socket_lookup(e466da84,e466da88,1,e466db40,0,...) at pf_socket_lookup+0x1d3 pf_test_tcp(e466daf0,e466dae8,1,c4295100,c4349e00,...) at pf_test_tcp+0x11e6 pf_test(1,c4098800,e466dbdc,0,0,...) at pf_test+0xae3 pf_check_in(0,e466dbdc,c4098800,1,0) at pf_check_in+0x37 pfil_run_hooks(c0a9db40,e466dc2c,c4098800,1,0) at pfil_run_hooks+0x7f ip_input(c4349e00) at ip_input+0x232 netisr_dispatch(2,c4349e00,0,c4098800,c43d0800,...) at netisr_dispatch+0x58 ether_demux(c4098800,c4349e00,c4037000,c43da002,e466dca0,...) at ether_demux+0x28a ether_input(c4098800,c4349e00,c4037014,0,c092325d,...) at ether_input+0x202 fxp_intr_body(c4037000,c4098800,40,ffffffff) at fxp_intr_body+0x1a0 fxp_intr(c4037000) at fxp_intr+0x95 ithread_execute_handlers(c40a0240,c3f46900) at ithread_execute_handlers+0x11e ithread_loop(c40433a0,e466dd38) at ithread_loop+0x67 fork_exit(c06adf00,c40433a0,e466dd38) at fork_exit+0xac fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe466dd70, ebp = 0 --- Tracing command irq17: fxp0 pid 28 tid 100037 td 0xc409c870 fork_trampoline() at fork_trampoline Tracing command usb1 pid 27 tid 100017 td 0xc3f006c0 sched_switch(c3f006c0,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 sleepq_switch(c402a210,c0a4ea90,0,c094e4e3,243,...) at sleepq_switch+0xc9 sleepq_timedwait(c402a210) at sleepq_timedwait+0x4a msleep(c402a210,0,5c,c09402e9,ea60,c4020940) at msleep+0x281 usb_event_thread(c4020940,e29a1d38) at usb_event_thread+0x94 fork_exit(c0658948,c4020940,e29a1d38) at fork_exit+0xac fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe29a1d70, ebp = 0 --- Tracing command usbtask-dr pid 26 tid 100018 td 0xc3f00510 sched_switch(c3f00510,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 sleepq_switch(c0a4c854,c0a4ea90,0,c094e4e3,21e,...) at sleepq_switch+0xc9 sleepq_wait(c0a4c854,0,c06b996c,c0a4eaa8,c09402c7,...) at sleepq_wait+0x46 msleep(c0a4c854,0,5c,c09402f0,0,...) at msleep+0x2a5 usb_task_thread(c0a4c854,e299ed38) at usb_task_thread+0x47 fork_exit(c06589fc,c0a4c854,e299ed38) at fork_exit+0xac fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe299ed70, ebp = 0 --- Tracing command usbtask-hc pid 25 tid 100019 td 0xc3f00360 sched_switch(c3f00360,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 sleepq_switch(c0a4c840,c0a4ea90,0,c094e4e3,21e,...) at sleepq_switch+0xc9 sleepq_wait(c0a4c840,0,c06b996c,c0a4eaa8,c09402c7,...) at sleepq_wait+0x46 msleep(c0a4c840,0,5c,c09402f0,0,...) at msleep+0x2a5 usb_task_thread(c0a4c840,e299bd38) at usb_task_thread+0x47 fork_exit(c06589fc,c0a4c840,e299bd38) at fork_exit+0xac fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe299bd70, ebp = 0 --- Tracing command usb0 pid 24 tid 100020 td 0xc3f001b0 sched_switch(c3f001b0,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 sleepq_switch(c3ffb210,c0a4ea90,0,c094e4e3,243,...) at sleepq_switch+0xc9 sleepq_timedwait(c3ffb210) at sleepq_timedwait+0x4a msleep(c3ffb210,0,5c,c09402e9,ea60,c4023440) at msleep+0x281 usb_event_thread(c4023440,e2998d38) at usb_event_thread+0x94 fork_exit(c0658948,c4023440,e2998d38) at fork_exit+0xac fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe2998d70, ebp = 0 --- Tracing command irq12: uhci0 uhci1 pid 23 tid 100021 td 0xc4007870 fork_trampoline() at fork_trampoline Tracing command irq15: ata1 pid 22 tid 100022 td 0xc40076c0 sched_switch(c40076c0,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 ithread_loop(c4022800,e43fad38) at ithread_loop+0xda fork_exit(c06adf00,c4022800,e43fad38) at fork_exit+0xac fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe43fad70, ebp = 0 --- Tracing command irq14: ata0 pid 21 tid 100023 td 0xc4007510 sched_switch(c4007510,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 ithread_loop(c40226b0,e43f7d38) at ithread_loop+0xda fork_exit(c06adf00,c40226b0,e43f7d38) at fork_exit+0xac fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe43f7d70, ebp = 0 --- Tracing command irq9: acpi0 pid 20 tid 100024 td 0xc4007360 fork_trampoline() at fork_trampoline Tracing command kqueue taskq pid 9 tid 100025 td 0xc40071b0 sched_switch(c40071b0,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 sleepq_switch(c3f78680,c0a4ea90,0,c094e4e3,21e,...) at sleepq_switch+0xc9 sleepq_wait(c3f78680,0,c094eb1b,49,8,...) at sleepq_wait+0x46 msleep(c3f78680,c3f7869c,0,c0943377,0) at msleep+0x2a5 taskqueue_thread_loop(c0a4d7dc,e43f1d38) at taskqueue_thread_loop+0x78 fork_exit(c06e8c4c,c0a4d7dc,e43f1d38) at fork_exit+0xac fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe43f1d70, ebp = 0 --- Tracing command swi2: cambio pid 19 tid 100026 td 0xc4007000 fork_trampoline() at fork_trampoline Tracing command acpi_task_2 pid 8 tid 100008 td 0xc3eff1b0 sched_switch(c3eff1b0,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 sleepq_switch(c3f78800,c0a4ea90,0,c094e4e3,21e,...) at sleepq_switch+0xc9 sleepq_wait(c3f78800,0,c094eb1b,49,8,...) at sleepq_wait+0x46 msleep(c3f78800,c3f7881c,0,c0943377,0) at msleep+0x2a5 taskqueue_thread_loop(c0c0e214,e297dd38) at taskqueue_thread_loop+0x78 fork_exit(c06e8c4c,c0c0e214,e297dd38) at fork_exit+0xac fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe297dd70, ebp = 0 --- Tracing command acpi_task_1 pid 7 tid 100009 td 0xc3eff000 sched_switch(c3eff000,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 sleepq_switch(c3f78800,c0a4ea90,0,c094e4e3,21e,...) at sleepq_switch+0xc9 sleepq_wait(c3f78800,0,c094eb1b,49,8,...) at sleepq_wait+0x46 msleep(c3f78800,c3f7881c,0,c0943377,0) at msleep+0x2a5 taskqueue_thread_loop(c0c0e214,e297ad38) at taskqueue_thread_loop+0x78 fork_exit(c06e8c4c,c0c0e214,e297ad38) at fork_exit+0xac fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe297ad70, ebp = 0 --- Tracing command acpi_task_0 pid 6 tid 100010 td 0xc3f02360 sched_switch(c3f02360,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 sleepq_switch(c3f78800,c0a4ea90,0,c094e4e3,21e,...) at sleepq_switch+0xc9 sleepq_wait(c3f78800,0,c094eb1b,49,c3f415e0,...) at sleepq_wait+0x46 msleep(c3f78800,c3f7881c,0,c0943377,0) at msleep+0x2a5 taskqueue_thread_loop(c0c0e214,e29b6d38) at taskqueue_thread_loop+0x78 fork_exit(c06e8c4c,c0c0e214,e29b6d38) at fork_exit+0xac fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe29b6d70, ebp = 0 --- Tracing command swi5: + pid 18 tid 100011 td 0xc3f021b0 sched_switch(c3f021b0,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 ithread_loop(c3f854d0,e29b3d38) at ithread_loop+0xda fork_exit(c06adf00,c3f854d0,e29b3d38) at fork_exit+0xac fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe29b3d70, ebp = 0 --- Tracing command thread taskq pid 5 tid 100012 td 0xc3f02000 sched_switch(c3f02000,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 sleepq_switch(c3f78980,c0a4ea90,0,c094e4e3,21e,...) at sleepq_switch+0xc9 sleepq_wait(c3f78980,0,c094eb1b,49,8,...) at sleepq_wait+0x46 msleep(c3f78980,c3f7899c,0,c0943377,0) at msleep+0x2a5 taskqueue_thread_loop(c0a54870,e29b0d38) at taskqueue_thread_loop+0x78 fork_exit(c06e8c4c,c0a54870,e29b0d38) at fork_exit+0xac fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe29b0d70, ebp = 0 --- Tracing command swi6: Giant taskq pid 17 tid 100013 td 0xc3f00d80 fork_trampoline() at fork_trampoline Tracing command swi6: task queue pid 16 tid 100014 td 0xc3f00bd0 sched_switch(c3f00bd0,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 ithread_loop(c3f85500,e29aad38) at ithread_loop+0xda fork_exit(c06adf00,c3f85500,e29aad38) at fork_exit+0xac fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe29aad70, ebp = 0 --- Tracing command yarrow pid 15 tid 100015 td 0xc3f00a20 sched_switch(c3f00a20,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 sleepq_switch(c0a391e0,c0a4ea90,0,c094e4e3,243,...) at sleepq_switch+0xc9 sleepq_timedwait(c0a391e0) at sleepq_timedwait+0x4a msleep(c0a391e0,0,0,c0943377,64) at msleep+0x281 random_kthread(0,e29a7d38) at random_kthread+0x180 fork_exit(c05f560c,0,e29a7d38) at fork_exit+0xac fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe29a7d70, ebp = 0 --- Tracing command g_down pid 4 tid 100016 td 0xc3f00870 sched_switch(c3f00870,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 sleepq_switch(c0a4d01c,c0a4ea90,0,c094e4e3,243,...) at sleepq_switch+0xc9 sleepq_timedwait(c0a4d01c) at sleepq_timedwait+0x4a msleep(c0a4d01c,c0a4cf08,24c,c0943377,64) at msleep+0x281 g_io_schedule_down(c3f00870) at g_io_schedule_down+0x56 g_down_procbody(0,e29a4d38) at g_down_procbody+0x5a fork_exit(c06853cc,0,e29a4d38) at fork_exit+0xac fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe29a4d70, ebp = 0 --- Tracing command g_up pid 3 tid 100000 td 0xc3f00000 sched_switch(c3f00000,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 sleepq_switch(c0a4d018,c0a4ea90,0,c094e4e3,243,...) at sleepq_switch+0xc9 sleepq_timedwait(c0a4d018) at sleepq_timedwait+0x4a msleep(c0a4d018,c0a4cf48,24c,c0943377,64) at msleep+0x281 g_io_schedule_up(c3f00000) at g_io_schedule_up+0x127 g_up_procbody(0,e2995d38) at g_up_procbody+0x5a fork_exit(c068536c,0,e2995d38) at fork_exit+0xac fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe2995d70, ebp = 0 --- Tracing command g_event pid 2 tid 100001 td 0xc3effd80 sched_switch(c3effd80,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 sleepq_switch(c0a4d010,c0a4ea90,0,c094e4e3,243,...) at sleepq_switch+0xc9 sleepq_timedwait(c0a4d010) at sleepq_timedwait+0x4a msleep(c0a4d010,0,4c,c0943377,64) at msleep+0x281 g_event_procbody(0,e2992d38) at g_event_procbody+0x9e fork_exit(c068542c,0,e2992d38) at fork_exit+0xac fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe2992d70, ebp = 0 --- Tracing command swi1: net pid 14 tid 100002 td 0xc3effbd0 sched_switch(c3effbd0,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 ithread_loop(c3ec48e0,e298fd38) at ithread_loop+0xda fork_exit(c06adf00,c3ec48e0,e298fd38) at fork_exit+0xac fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe298fd70, ebp = 0 --- Tracing command swi3: vm pid 13 tid 100003 td 0xc3effa20 fork_trampoline() at fork_trampoline Tracing command swi4: clock sio pid 12 tid 100004 td 0xc3eff870 sched_switch(c3eff870,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 turnstile_wait(c0a9df6c,c45dabd0,0,c0a9df6c,2,c094a0d3,166) at turnstile_wait+0x3ea _mtx_lock_sleep(c0a9df6c,c3eff870,0,c095d7ff,73) at _mtx_lock_sleep+0x145 _mtx_lock_flags(c0a9df6c,0,c095d7ff,73,e2989c98,...) at _mtx_lock_flags+0xab tcp_slowtimo(0,16,e2989ccc,c06cf537,0,...) at tcp_slowtimo+0x27 pfslowtimo(0) at pfslowtimo+0x45 softclock(0) at softclock+0x22f ithread_execute_handlers(c3efe900,c3f46600) at ithread_execute_handlers+0x11e ithread_loop(c3ec4900,e2989d38) at ithread_loop+0x67 fork_exit(c06adf00,c3ec4900,e2989d38) at fork_exit+0xac fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe2989d70, ebp = 0 --- Tracing command idle: cpu0 pid 11 tid 100005 td 0xc3eff6c0 kdb_enter(c093cb3b) at kdb_enter+0x2b siointr1(c40b4000,c0abdfac,0,c096e56b,56e,...) at siointr1+0xce siointr(c40b4000) at siointr+0x21 intr_execute_handlers(c3ef4cc8,e2986c94,4,e2986cd4,c08ab2c4,...) at intr_execute_handlers+0xe1 lapic_handle_intr(36,e2986c94) at lapic_handle_intr+0x2f Xapic_isr1() at Xapic_isr1+0x34 --- interrupt, eip = 0xc0c000b5, esp = 0xe2986cd4, ebp = 0xe2986cd4 --- acpi_cpu_c1(c0a4ea90,c06d85a8,e2986cf4,c06d85a8,c06d85a8,...) at acpi_cpu_c1+0x5 acpi_cpu_idle(e2986d04,c06d85d1,e2986d24,c06acf40,0,...) at acpi_cpu_idle+0x162 cpu_idle(e2986d24,c06acf40,0,e2986d38,c3efeb40,...) at cpu_idle+0x28 sched_idletd(0,e2986d38) at sched_idletd+0x29 fork_exit(c06d85a8,0,e2986d38) at fork_exit+0xac fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe2986d70, ebp = 0 --- Tracing command idle: cpu1 pid 10 tid 100006 td 0xc3eff510 cpustop_handler(e2983c88,c08c07d3,e2983c20,c06b9bed,c3f46900,...) at cpustop_handler+0x31 ipi_nmi_handler(e2983c20,c06b9bed,c3f46900,0,0,...) at ipi_nmi_handler+0x28 trap(e2983c94) at trap+0x3f calltrap() at calltrap+0x6 --- trap 0x13, eip = 0xc0c000b5, esp = 0xe2983cd4, ebp = 0xe2983cd4 --- acpi_cpu_c1(c0a4ea90,c06d85a8,e2983cf4,c06d85a8,c06d85a8,...) at acpi_cpu_c1+0x5 acpi_cpu_idle(e2983d04,c06d85d1,e2983d24,c06acf40,0,...) at acpi_cpu_idle+0x162 cpu_idle(e2983d24,c06acf40,0,e2983d38,c3efed80,...) at cpu_idle+0x28 sched_idletd(0,e2983d38) at sched_idletd+0x29 fork_exit(c06d85a8,0,e2983d38) at fork_exit+0xac fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe2983d70, ebp = 0 --- Tracing command init pid 1 tid 100007 td 0xc3eff360 sched_switch(c3eff360,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 sleepq_switch(c3f01000) at sleepq_switch+0xc9 sleepq_wait_sig(c3f01000) at sleepq_wait_sig+0x1d msleep(c3f01000,c3f01060,15c,c095061f,0) at msleep+0x296 kern_wait(c3eff360,ffffffff,e2980c28,0,0) at kern_wait+0x7c3 wait4(c3eff360,e2980d00) at wait4+0x2a syscall(e2980d38) at syscall+0x256 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (7, FreeBSD ELF32, wait4), eip = 0x80531f7, esp = 0xbfbfe92c, ebp = 0xbfbfe948 --- Tracing command swapper pid 0 tid 0 td 0xc0a4d320 sched_switch(c0a4d320,0,1) at sched_switch+0xff mi_switch(1,0) at mi_switch+0x280 scheduler(0,101ec00,101e000,0,c0452345,...) at scheduler+0x195 mi_startup() at mi_startup+0x96 begin() at begin+0x2c db> panic panic: from debugger cpuid = 0 Uptime: 13h55m37s Physical memory: 1011 MB Dumping 152 MB: 137 121 105 89 73 57 41 25 9 Dump complete Automatic reboot in 15 seconds - press a key on the console to abort From owner-freebsd-current@FreeBSD.ORG Sun Mar 11 06:53:27 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AB87B16A400 for ; Sun, 11 Mar 2007 06:53:27 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from mrout3.yahoo.com (mrout3.yahoo.com [216.145.54.173]) by mx1.freebsd.org (Postfix) with ESMTP id 97B5613C49D for ; Sun, 11 Mar 2007 06:53:27 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from minion.local.neville-neil.com (proxy8.corp.yahoo.com [216.145.48.13]) by mrout3.yahoo.com (8.13.6/8.13.6/y.out) with ESMTP id l2B5gwSe069128; Sat, 10 Mar 2007 21:42:59 -0800 (PST) Date: Sun, 11 Mar 2007 14:42:50 +0900 Message-ID: From: gnn@freebsd.org To: Julian Elischer In-Reply-To: <45EE0D92.9090702@elischer.org> References: <45EE0D92.9090702@elischer.org> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.7 Emacs/22.0.93 (i386-apple-darwin8.8.2) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: FreeBSD Current Subject: Re: remote gdb (serial) for kernel.. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Mar 2007 06:53:27 -0000 At Tue, 06 Mar 2007 16:55:46 -0800, julian wrote: > > Anyone been doing this recently? > Yes, on VMWare and Parallels only at the moment. > should I use gdb or kgdb? kgdb > neither seems to work right.. > if you have had success in doing this recently, could you let me know > what your settings have been? In my kernel config file: options KDB # Enable kernel debugger support. options DDB # Support DDB. options GDB # Support remote GDB. In /boot/loader.conf: hint.sio.1.flags=0x90 boot_gdb=1 This is on CURRENT. devbox ? sudo kgdb -r /dev/cuad1 kernel [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". Switching to remote protocol Not perfect all the time but "works for me." Best, George From owner-freebsd-current@FreeBSD.ORG Sun Mar 11 08:09:54 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8B48716A4C0 for ; Sun, 11 Mar 2007 08:09:54 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Received: from tmailer.gwdg.de (tmailer.gwdg.de [134.76.10.23]) by mx1.freebsd.org (Postfix) with ESMTP id 20A1813C461 for ; Sun, 11 Mar 2007 08:09:54 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Received: from [87.139.104.184] (helo=[192.168.2.20]) by mailer.gwdg.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1HQJ7n-00014n-0w; Sun, 11 Mar 2007 09:09:51 +0100 Message-ID: <45F3B94B.3030104@gwdg.de> Date: Sun, 11 Mar 2007 09:09:47 +0100 From: Rainer Hurling User-Agent: Thunderbird 1.5.0.10 (X11/20070306) MIME-Version: 1.0 To: pyunyh@gmail.com References: <20070310074734.GC70613@cdnetworks.co.kr> <917080.87242.qm@web34701.mail.mud.yahoo.com> <20070311050627.GC79728@cdnetworks.co.kr> In-Reply-To: <20070311050627.GC79728@cdnetworks.co.kr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated: Id:rhurlin X-Spam-Level: - X-Virus-Scanned: (clean) by exiscan+sophie Cc: darren780@yahoo.com, freebsd-current@freebsd.org Subject: Re: yongari nfe problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Mar 2007 08:09:54 -0000 Pyun YongHyeon schrieb: > [... SNIP ...] > > Did stock nfe(4) work on MCP55? > (I'm not interested in how nve(4) works on MCP55.) > I'm afraid MCP55 requires different programming. Searching archives > for Linux forcedeth driver also reveals issues on MCP55 which is > exactly the same issue I think. > I'll let you know if I find a clue but it's hard to fix due to lack > of MCP55 hardware and documentation. Yes, nfe(4) works on MCP55, but with some strange behaviour, see below. I am working with FreeBSD 7.0-CURRENT from 03/07/2007 on MSI K9N Neo. 'dmesg | grep nfe' gives me: nfe0: port 0xb000-0xb007 mem 0xfbef7000-0xfbef7fff,0xfbefa800-0xfbefa8ff,0xfbefa400-0xfbefa40f irq 21 at device 8.0 on pci0 miibus0: on nfe0 ukphy0: PHY 1 on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto nfe0: using obsoleted if_watchdog interface nfe0: Ethernet address: xx:xx:xx:xx:xx:xx nfe0: [ITHREAD] It seems that there is a problem with watchdog. Perhaps the choosen media interface ukphy0 is not correct? In the context with watchdog I observe an interesting behaviour of nfe0: After running WindowsXP on my board, I am not able to use the interface any more. Booting FreeBSD always gives me messages like this: ----- nfe0: link state changed to DOWN /etc/rc.d/dhclient: WARNING: $background_dhclient_nfe0 is not set properly - see rc.conf(5). nfe0: no link ....nfe0: link state changed to UP got link DHCPREQUEST on nfe0 to 255.255.255.255 port 67 nfe0: watchdog timeout nfe0: link state changed to DOWN nfe0: link state changed to UP DHCPREQUEST on nfe0 to 255.255.255.255 port 67 nfe0: watchdog timeout nfe0: link state changed to DOWN nfe0: link state changed to UP DHCPDISCOVER on nfe0 to 255.255.255.255 port 67 interval 5 nfe0: watchdog timeout nfe0: link state changed to DOWN DHCPDISCOVER on nfe0 to 255.255.255.255 port 67 interval 9 nfe0: link state changed to UP nfe0: watchdog timeout nfe0: link state changed to DOWN nfe0: link state changed to UP DHCPDISCOVER on nfe0 to 255.255.255.255 port 67 interval 14 nfe0: watchdog timeout nfe0: link state changed to DOWN nfe0: link state changed to UP DHCPDISCOVER on nfe0 to 255.255.255.255 port 67 interval 18 nfe0: watchdog timeout nfe0: link state changed to DOWN nfe0: link state changed to UP DHCPDISCOVER on nfe0 to 255.255.255.255 port 67 interval 9 nfe0: watchdog timeout nfe0: link state changed to DOWN nfe0: link state changed to UP DHCPDISCOVER on nfe0 to 255.255.255.255 port 67 interval 6 nfe0: watchdog timeout nfe0: link state changed to DOWN No DHCPOFFERS received. Trying recorded lease xxx.xxx.xxx.xxx nfe0: link state changed to UP bound: renewal in 429590 seconds. lo0: flags=8049 metric 0 mtu 16384 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff000000 nfe0: flags=8843 metric 0 mtu 1500 options=2b ether xx:xx:xx:xx:xx:xx media: Ethernet autoselect (100baseTX ) status: active ----- When booting 'cold' (means full power down) FreeBSD is able to use nfe(4) in the correct way. Also booting FreeBSD again after running FreeBSD gives me no errors. Obviously WindowsXP does not clear up all registers in MCP55 after leaving? Rainer Hurling From owner-freebsd-current@FreeBSD.ORG Sun Mar 11 10:54:21 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 57DD216A400 for ; Sun, 11 Mar 2007 10:54:21 +0000 (UTC) (envelope-from andy.lavr@reactor-xg.kiev.ua) Received: from mail.reactor-xg.kiev.ua (reactor-xg.kiev.ua [82.144.204.150]) by mx1.freebsd.org (Postfix) with ESMTP id C80EA13C48E for ; Sun, 11 Mar 2007 10:54:20 +0000 (UTC) (envelope-from andy.lavr@reactor-xg.kiev.ua) Received: from mail.reactor-xg.kiev.ua (mail.reactor-xg.kiev.ua [82.144.204.150]) by mail.reactor-xg.kiev.ua (Reactor-XG Mailer System) with ESMTP id l2BASEBR033046 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 11 Mar 2007 12:28:16 +0200 (EET) (envelope-from andy.lavr@reactor-xg.kiev.ua) From: "Andrei V. Lavreniyuk" Organization: Technica-03, Inc. To: freebsd-current@freebsd.org Date: Sun, 11 Mar 2007 12:28:08 +0200 User-Agent: KMail/1.9.5 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200703111228.09163.andy.lavr@reactor-xg.kiev.ua> X-Virus-Scanned: ClamAV 0.90/2801/Sat Mar 10 21:14:47 2007 on mail.reactor-xg.kiev.ua X-Virus-Status: Clean X-Mailman-Approved-At: Sun, 11 Mar 2007 11:17:46 +0000 Subject: Error make kernel (src update 11.03.2007) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Mar 2007 10:54:21 -0000 Hi! FreeBSD 7.0-CURRENT #0: Tue Feb 13 16:04:50 EET 2007 Error make kernel (src update 11.03.2007) ===> wlan (all) cc -O2 -fno-strict-aliasing -pipe -march=nocona -Werror -D_KERNEL -DKLD_MODULE -std=c99 -nostdinc -I- -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/MAIL/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -fno-omit-frame-pointer -I/usr/obj/usr/src/sys/MAIL -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -c /usr/src/sys/modules/wlan/../../net80211/ieee80211.c cc -O2 -fno-strict-aliasing -pipe -march=nocona -Werror -D_KERNEL -DKLD_MODULE -std=c99 -nostdinc -I- -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/MAIL/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -fno-omit-frame-pointer -I/usr/obj/usr/src/sys/MAIL -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -c /usr/src/sys/modules/wlan/../../net80211/ieee80211_crypto.c cc -O2 -fno-strict-aliasing -pipe -march=nocona -Werror -D_KERNEL -DKLD_MODULE -std=c99 -nostdinc -I- -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/MAIL/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -fno-omit-frame-pointer -I/usr/obj/usr/src/sys/MAIL -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -c /usr/src/sys/modules/wlan/../../net80211/ieee80211_crypto_none.c cc -O2 -fno-strict-aliasing -pipe -march=nocona -Werror -D_KERNEL -DKLD_MODULE -std=c99 -nostdinc -I- -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/MAIL/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -fno-omit-frame-pointer -I/usr/obj/usr/src/sys/MAIL -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -c /usr/src/sys/modules/wlan/../../net80211/ieee80211_freebsd.c cc -O2 -fno-strict-aliasing -pipe -march=nocona -Werror -D_KERNEL -DKLD_MODULE -std=c99 -nostdinc -I- -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/MAIL/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -fno-omit-frame-pointer -I/usr/obj/usr/src/sys/MAIL -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -c /usr/src/sys/modules/wlan/../../net80211/ieee80211_input.c /usr/src/sys/modules/wlan/../../net80211/ieee80211_input.c: In function `ieee80211_input': /usr/src/sys/modules/wlan/../../net80211/ieee80211_input.c:264: error: `IEEE80211_NONQOS_TID' undeclared (first use in this function) /usr/src/sys/modules/wlan/../../net80211/ieee80211_input.c:264: error: (Each undeclared identifier is reported only once /usr/src/sys/modules/wlan/../../net80211/ieee80211_input.c:264: error: for each function it appears in.) *** Error code 1 Stop in /usr/src/sys/modules/wlan. *** Error code 1 Stop in /usr/src/sys/modules. *** Error code 1 Stop in /usr/obj/usr/src/sys/MAIL. *** Error code 1 Stop in /usr/src. *** Error code 1 Best regards, Andrei V. Lavreniyuk From owner-freebsd-current@FreeBSD.ORG Sun Mar 11 11:56:14 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 78FC816A402 for ; Sun, 11 Mar 2007 11:56:14 +0000 (UTC) (envelope-from bamston@reactor-xg.kiev.ua) Received: from mail.reactor-xg.kiev.ua (reactor-xg.kiev.ua [82.144.204.150]) by mx1.freebsd.org (Postfix) with ESMTP id E1CF113C47E for ; Sun, 11 Mar 2007 11:56:13 +0000 (UTC) (envelope-from bamston@reactor-xg.kiev.ua) Received: from mail.reactor-xg.kiev.ua (mail.reactor-xg.kiev.ua [82.144.204.150]) by mail.reactor-xg.kiev.ua (Reactor-XG Mailer System) with ESMTP id l2BBI7HM075611 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 11 Mar 2007 13:18:07 +0200 (EET) (envelope-from bamston@reactor-xg.kiev.ua) From: "Andrei V. Lavreniyuk" Organization: Technica-03, Inc. To: freebsd-current@freebsd.org Date: Sun, 11 Mar 2007 13:18:01 +0200 User-Agent: KMail/1.9.5 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200703111318.01708.bamston@reactor-xg.kiev.ua> X-Virus-Scanned: ClamAV 0.90/2801/Sat Mar 10 21:14:47 2007 on mail.reactor-xg.kiev.ua X-Virus-Status: Clean Subject: Error make kernel (src update 11.03.2007) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Mar 2007 11:56:14 -0000 Hi! =46reeBSD 7.0-CURRENT #0: Tue Feb 13 16:04:50 EET 2007 Error make kernel (src update 11.03.2007) =3D=3D=3D> wlan (all) cc -O2 -fno-strict-aliasing -pipe -march=3Dnocona -Werror -D_KERNEL -DKLD_M= ODULE -std=3Dc99 -nostdinc -I- =A0 -DHAVE_KERNEL_OPTION_HEADERS -include /u= sr/obj/usr/src/sys/MAIL/opt_global.h -I. -I@ -I@/contrib/altq -finline-limi= t=3D8000 --param=20 inline-unit-growth=3D100 --param=20 large-function-growth=3D1000 -fno-common -g -fno-omit-frame-pointer -I/usr/= obj/usr/src/sys/MAIL -mcmodel=3Dkernel -mno-red-zone =A0-mfpmath=3D387 -mno= =2Dsse -mno-sse2 -mno-mmx -mno-3dnow =A0-msoft-float -fno-asynchronous-unwi= nd-tables -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-= prototypes =A0-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual =A0= =2DWundef -fformat-extensions -c /usr/src/sys/modules/wlan/../../net80211/i= eee80211.c cc -O2 -fno-strict-aliasing -pipe -march=3Dnocona -Werror -D_KERNEL -DKLD_M= ODULE -std=3Dc99 -nostdinc -I- =A0 -DHAVE_KERNEL_OPTION_HEADERS -include /u= sr/obj/usr/src/sys/MAIL/opt_global.h -I. -I@ -I@/contrib/altq -finline-limi= t=3D8000 --param=20 inline-unit-growth=3D100 --param=20 large-function-growth=3D1000 -fno-common -g -fno-omit-frame-pointer -I/usr/= obj/usr/src/sys/MAIL -mcmodel=3Dkernel -mno-red-zone =A0-mfpmath=3D387 -mno= =2Dsse -mno-sse2 -mno-mmx -mno-3dnow =A0-msoft-float -fno-asynchronous-unwi= nd-tables -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-= prototypes =A0-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual =A0= =2DWundef -fformat-extensions -c /usr/src/sys/modules/wlan/../../net80211/i= eee80211_crypto.c cc -O2 -fno-strict-aliasing -pipe -march=3Dnocona -Werror -D_KERNEL -DKLD_M= ODULE -std=3Dc99 -nostdinc -I- =A0 -DHAVE_KERNEL_OPTION_HEADERS -include /u= sr/obj/usr/src/sys/MAIL/opt_global.h -I. -I@ -I@/contrib/altq -finline-limi= t=3D8000 --param=20 inline-unit-growth=3D100 --param=20 large-function-growth=3D1000 -fno-common -g -fno-omit-frame-pointer -I/usr/= obj/usr/src/sys/MAIL -mcmodel=3Dkernel -mno-red-zone =A0-mfpmath=3D387 -mno= =2Dsse -mno-sse2 -mno-mmx -mno-3dnow =A0-msoft-float -fno-asynchronous-unwi= nd-tables -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-= prototypes =A0-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual =A0= =2DWundef -fformat-extensions -c /usr/src/sys/modules/wlan/../../net80211/i= eee80211_crypto_none.c cc -O2 -fno-strict-aliasing -pipe -march=3Dnocona -Werror -D_KERNEL -DKLD_M= ODULE -std=3Dc99 -nostdinc -I- =A0 -DHAVE_KERNEL_OPTION_HEADERS -include /u= sr/obj/usr/src/sys/MAIL/opt_global.h -I. -I@ -I@/contrib/altq -finline-limi= t=3D8000 --param=20 inline-unit-growth=3D100 --param=20 large-function-growth=3D1000 -fno-common -g -fno-omit-frame-pointer -I/usr/= obj/usr/src/sys/MAIL -mcmodel=3Dkernel -mno-red-zone =A0-mfpmath=3D387 -mno= =2Dsse -mno-sse2 -mno-mmx -mno-3dnow =A0-msoft-float -fno-asynchronous-unwi= nd-tables -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-= prototypes =A0-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual =A0= =2DWundef -fformat-extensions -c /usr/src/sys/modules/wlan/../../net80211/i= eee80211_freebsd.c cc -O2 -fno-strict-aliasing -pipe -march=3Dnocona -Werror -D_KERNEL -DKLD_M= ODULE -std=3Dc99 -nostdinc -I- =A0 -DHAVE_KERNEL_OPTION_HEADERS -include /u= sr/obj/usr/src/sys/MAIL/opt_global.h -I. -I@ -I@/contrib/altq -finline-limi= t=3D8000 --param=20 inline-unit-growth=3D100 --param=20 large-function-growth=3D1000 -fno-common -g -fno-omit-frame-pointer -I/usr/= obj/usr/src/sys/MAIL -mcmodel=3Dkernel -mno-red-zone =A0-mfpmath=3D387 -mno= =2Dsse -mno-sse2 -mno-mmx -mno-3dnow =A0-msoft-float -fno-asynchronous-unwi= nd-tables -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-= prototypes =A0-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual =A0= =2DWundef -fformat-extensions -c /usr/src/sys/modules/wlan/../../net80211/i= eee80211_input.c /usr/src/sys/modules/wlan/../../net80211/ieee80211_input.c: In function=20 `ieee80211_input': /usr/src/sys/modules/wlan/../../net80211/ieee80211_input.c:264: error:=20 `IEEE80211_NONQOS_TID' undeclared (first use in this function) /usr/src/sys/modules/wlan/../../net80211/ieee80211_input.c:264: error: (Eac= h=20 undeclared identifier is reported only once /usr/src/sys/modules/wlan/../../net80211/ieee80211_input.c:264: error: for= =20 each function it appears in.) *** Error code 1 Stop in /usr/src/sys/modules/wlan. *** Error code 1 Stop in /usr/src/sys/modules. *** Error code 1 Stop in /usr/obj/usr/src/sys/MAIL. *** Error code 1 Stop in /usr/src. *** Error code 1 Best regards, Andrei V. Lavreniyuk From owner-freebsd-current@FreeBSD.ORG Sun Mar 11 15:17:13 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9E4D216A400 for ; Sun, 11 Mar 2007 15:17:13 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (palm.hoeg.nl [83.98.131.212]) by mx1.freebsd.org (Postfix) with ESMTP id 800CB13C44B for ; Sun, 11 Mar 2007 15:17:11 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 4EEC51CC53; Sun, 11 Mar 2007 16:17:49 +0100 (CET) Date: Sun, 11 Mar 2007 16:17:49 +0100 From: Ed Schouten To: Rainer Hurling Message-ID: <20070311151749.GG7449@hoeg.nl> References: <20070310074734.GC70613@cdnetworks.co.kr> <917080.87242.qm@web34701.mail.mud.yahoo.com> <20070311050627.GC79728@cdnetworks.co.kr> <45F3B94B.3030104@gwdg.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="H4SyuGOnfnj3aJqJ" Content-Disposition: inline In-Reply-To: <45F3B94B.3030104@gwdg.de> User-Agent: Mutt/1.5.14 (2007-02-12) Cc: pyunyh@gmail.com, darren780@yahoo.com, FreeBSD Current Subject: Re: yongari nfe problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Mar 2007 15:17:13 -0000 --H4SyuGOnfnj3aJqJ Content-Type: multipart/mixed; boundary="EgVrEAR5UttbsTXg" Content-Disposition: inline --EgVrEAR5UttbsTXg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Rainer Hurling wrote: > I am working with FreeBSD 7.0-CURRENT from 03/07/2007 on MSI K9N Neo.=20 > 'dmesg | grep nfe' gives me: >=20 > nfe0: port 0xb000-0xb007 mem > 0xfbef7000-0xfbef7fff,0xfbefa800-0xfbefa8ff,0xfbefa400-0xfbefa40f irq 21 > at device 8.0 on pci0 > miibus0: on nfe0 > ukphy0: PHY 1 on miibus0 > ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT,=20 > 1000baseT-FDX, auto > nfe0: using obsoleted if_watchdog interface > nfe0: Ethernet address: xx:xx:xx:xx:xx:xx > nfe0: [ITHREAD] >=20 > It seems that there is a problem with watchdog. Perhaps the choosen=20 > media interface ukphy0 is not correct? Rainer, maybe your motherboard has an ICS18xx physical interface. Could you try the following kernel patch? It adds a driver from NetBSD, icsphy(4). Thanks! Yours, --=20 Ed Schouten WWW: http://g-rave.nl/ --EgVrEAR5UttbsTXg Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="freebsd-icsphy.diff" Content-Transfer-Encoding: quoted-printable --- src/sys/conf/files Sat Feb 3 18:04:35 2007 +++ src/sys/conf/files Tue Feb 6 19:16:49 2007 @@ -726,6 +726,8 @@ # XXX only xl cards? dev/mii/exphy.c optional miibus | exphy dev/mii/gentbi.c optional miibus | gentbi +# XXX only nfe cards? +dev/mii/icsphy.c optional miibus | icsphy # XXX only fxp cards? dev/mii/inphy.c optional miibus | inphy dev/mii/ip1000phy.c optional miibus | ip1000phy --- src/sys/dev/mii/icsphy.c Thu Jan 1 01:00:00 1970 +++ src/sys/dev/mii/icsphy.c Tue Feb 6 21:11:37 2007 @@ -0,0 +1,305 @@ +/* $NetBSD: icsphy.c,v 1.41 2006/11/16 21:24:07 christos Exp $ */ + +/*- + * Copyright (c) 1998, 1999, 2000 The NetBSD Foundation, Inc. + * All rights reserved. + * + * This code is derived from software contributed to The NetBSD Foundation + * by Jason R. Thorpe of the Numerical Aerospace Simulation Facility, + * NASA Ames Research Center. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * 3. All advertising materials mentioning features or use of this software + * must display the following acknowledgement: + * This product includes software developed by the NetBSD + * Foundation, Inc. and its contributors. + * 4. Neither the name of The NetBSD Foundation nor the names of its + * contributors may be used to endorse or promote products derived + * from this software without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE NETBSD FOUNDATION, INC. AND CONTRIBUTO= RS + * ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIM= ITED + * TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICU= LAR + * PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE FOUNDATION OR CONTRIBUTO= RS + * BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR + * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF + * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS + * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN + * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) + * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF = THE + * POSSIBILITY OF SUCH DAMAGE. + */ + +/* + * Copyright (c) 1997 Manuel Bouyer. All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * 3. All advertising materials mentioning features or use of this software + * must display the following acknowledgement: + * This product includes software developed by Manuel Bouyer. + * 4. The name of the author may not be used to endorse or promote products + * derived from this software without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR + * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTI= ES + * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. + * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, + * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT + * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF US= E, + * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY + * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF + * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + */ + +/* + * driver for Integrated Circuit Systems' ICS1889-1893 ethernet 10/100 PHY + * datasheet from www.icst.com + */ + +#include +#include +#include +#include +#include +#include + +#include +#include + +#include +#include +#include "miidevs.h" + +#include + +#include "miibus_if.h" + +static int icsphy_probe(device_t dev); +static int icsphy_attach(device_t dev); + +struct icsphy_softc { + struct mii_softc mii_sc; + int mii_model; +}; + +static device_method_t icsphy_methods[] =3D { + /* device interface */ + DEVMETHOD(device_probe, icsphy_probe), + DEVMETHOD(device_attach, icsphy_attach), + DEVMETHOD(device_detach, mii_phy_detach), + DEVMETHOD(device_shutdown, bus_generic_shutdown), + { 0, 0 } +}; + +static devclass_t icsphy_devclass; + +static driver_t icsphy_driver =3D { + "icsphy", + icsphy_methods, + sizeof(struct icsphy_softc) +}; + +DRIVER_MODULE(icsphy, miibus, icsphy_driver, icsphy_devclass, 0, 0); + +static int icsphy_service(struct mii_softc *, struct mii_data *, int); +static void icsphy_status(struct mii_softc *); +static void icsphy_reset(struct mii_softc *); + +static const struct mii_phydesc icsphys[] =3D { + MII_PHY_DESC(xxICS, 1889), + MII_PHY_DESC(xxICS, 1890), + MII_PHY_DESC(xxICS, 1892), + MII_PHY_DESC(xxICS, 1893), + MII_PHY_END +}; + +static int +icsphy_probe(device_t dev) +{ + + return (mii_phy_dev_probe(dev, icsphys, BUS_PROBE_DEFAULT)); +} + +static int +icsphy_attach(device_t dev) +{ + struct icsphy_softc *isc; + struct mii_softc *sc; + struct mii_attach_args *ma; + struct mii_data *mii; + + isc =3D device_get_softc(dev); + sc =3D &isc->mii_sc; + ma =3D device_get_ivars(dev); + sc->mii_dev =3D device_get_parent(dev); + mii =3D device_get_softc(sc->mii_dev); + LIST_INSERT_HEAD(&mii->mii_phys, sc, mii_list); + + sc->mii_inst =3D mii->mii_instance; + sc->mii_phy =3D ma->mii_phyno; + sc->mii_service =3D icsphy_service; + sc->mii_pdata =3D mii; + mii->mii_instance++; + + sc->mii_flags |=3D MIIF_NOISOLATE; + + ifmedia_add(&mii->mii_media, + IFM_MAKEWORD(IFM_ETHER, IFM_100_TX, IFM_LOOP, sc->mii_inst), + MII_MEDIA_100_TX, NULL); + + isc->mii_model =3D MII_MODEL(ma->mii_id2); + icsphy_reset(sc); + + sc->mii_capabilities =3D PHY_READ(sc, MII_BMSR) & ma->mii_capmask; + device_printf(dev, " "); + mii_phy_add_media(sc); + printf("\n"); + + MIIBUS_MEDIAINIT(sc->mii_dev); + + return (0); +} + +static int +icsphy_service(struct mii_softc *sc, struct mii_data *mii, int cmd) +{ + struct ifmedia_entry *ife =3D mii->mii_media.ifm_cur; + int reg; + + switch (cmd) { + case MII_POLLSTAT: + /* + * If we're not polling our PHY instance, just return. + */ + if (IFM_INST(ife->ifm_media) !=3D sc->mii_inst) + return (0); + break; + + case MII_MEDIACHG: + /* + * If the media indicates a different PHY instance, + * isolate ourselves. + */ + if (IFM_INST(ife->ifm_media) !=3D sc->mii_inst) { + reg =3D PHY_READ(sc, MII_BMCR); + PHY_WRITE(sc, MII_BMCR, reg | BMCR_ISO); + return (0); + } + + /* + * If the interface is not up, don't do anything. + */ + if ((mii->mii_ifp->if_flags & IFF_UP) =3D=3D 0) + break; + + mii_phy_setmedia(sc); + break; + + case MII_TICK: + /* + * If we're not currently selected, just return. + */ + if (IFM_INST(ife->ifm_media) !=3D sc->mii_inst) + return (0); + + if (mii_phy_tick(sc) =3D=3D EJUSTRETURN) + return (0); + break; + } + + /* Update the media status. */ + icsphy_status(sc); + + /* Callback if something changed. */ + mii_phy_update(sc, cmd); + return (0); +} + +static void +icsphy_status(struct mii_softc *sc) +{ + struct mii_data *mii =3D sc->mii_pdata; + struct ifmedia_entry *ife =3D mii->mii_media.ifm_cur; + int bmcr, qpr; + + mii->mii_media_status =3D IFM_AVALID; + mii->mii_media_active =3D IFM_ETHER; + + /* + * Don't get link from the BMSR. It's available in the QPR, + * and we have to read it twice to unlatch it anyhow. This + * gives us fewer register reads. + */ + qpr =3D PHY_READ(sc, MII_ICSPHY_QPR); /* unlatch */ + qpr =3D PHY_READ(sc, MII_ICSPHY_QPR); /* real value */ + + if (qpr & QPR_LINK) + mii->mii_media_status |=3D IFM_ACTIVE; + + bmcr =3D PHY_READ(sc, MII_BMCR); + if (bmcr & BMCR_ISO) { + mii->mii_media_active |=3D IFM_NONE; + mii->mii_media_status =3D 0; + return; + } + + if (bmcr & BMCR_LOOP) + mii->mii_media_active |=3D IFM_LOOP; + + if (bmcr & BMCR_AUTOEN) { + if ((qpr & QPR_ACOMP) =3D=3D 0) { + /* Erg, still trying, I guess... */ + mii->mii_media_active |=3D IFM_NONE; + return; + } + if (qpr & QPR_SPEED) + mii->mii_media_active |=3D IFM_100_TX; + else + mii->mii_media_active |=3D IFM_10_T; + if (qpr & QPR_FDX) + mii->mii_media_active |=3D IFM_FDX; + } else + mii->mii_media_active =3D ife->ifm_media; +} + +static void +icsphy_reset(struct mii_softc *sc) +{ + struct icsphy_softc *isc =3D (struct icsphy_softc *)sc; + + mii_phy_reset(sc); + /* set powerdown feature */ + switch (isc->mii_model) { + case MII_MODEL_xxICS_1890: + case MII_MODEL_xxICS_1893: + PHY_WRITE(sc, MII_ICSPHY_ECR2, ECR2_100AUTOPWRDN); + break; + case MII_MODEL_xxICS_1892: + PHY_WRITE(sc, MII_ICSPHY_ECR2, + ECR2_10AUTOPWRDN|ECR2_100AUTOPWRDN); + break; + default: + /* 1889 have no ECR2 */ + break; + } + /* + * There is no description that the reset do auto-negotiation in the + * data sheet. + */ + PHY_WRITE(sc, MII_BMCR, BMCR_S100|BMCR_STARTNEG|BMCR_FDX); +} --- src/sys/dev/mii/icsphyreg.h Thu Jan 1 01:00:00 1970 +++ src/sys/dev/mii/icsphyreg.h Wed Jul 2 00:46:08 2003 @@ -0,0 +1,134 @@ +/* $NetBSD: icsphyreg.h,v 1.2 2003/07/01 22:46:08 msaitoh Exp $ */ + +/*- + * Copyright (c) 1998 The NetBSD Foundation, Inc. + * All rights reserved. + * + * This code is derived from software contributed to The NetBSD Foundation + * by Jason R. Thorpe of the Numerical Aerospace Simulation Facility, + * NASA Ames Research Center. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * 3. All advertising materials mentioning features or use of this software + * must display the following acknowledgement: + * This product includes software developed by the NetBSD + * Foundation, Inc. and its contributors. + * 4. Neither the name of The NetBSD Foundation nor the names of its + * contributors may be used to endorse or promote products derived + * from this software without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE NETBSD FOUNDATION, INC. AND CONTRIBUTO= RS + * ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIM= ITED + * TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICU= LAR + * PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE FOUNDATION OR CONTRIBUTO= RS + * BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR + * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF + * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS + * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN + * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) + * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF = THE + * POSSIBILITY OF SUCH DAMAGE. + */ + +#ifndef _DEV_MII_ICSPHYREG_H_ +#define _DEV_MII_ICSPHYREG_H_ + +/* + * ICS1890 registers. + * http://www.icst.com/pdf/18??.pdf + */ + +/* HEX 1889 1890 1892 1893 + *-------------------------------------------------------------- + * 0 Control * * * * + * 1 Status * * * * + * 2 PHY Identifier * * * * + * 3 PHY Identifier * * * * + * 4 Auto-Neg. Advertisement * * * + * 5 Auto-Neg. Link Parent Adv * * * + * 6 Auto-Neg. Expansion * * * + * 7 Auto-Neg. Next Page Tx * * + * 8 ANg Nxt Page Lnk Parnt Abl * * + * 10 Extended Control * * * * + * 11 Quick Poll Status * * * * + * 12 10Base-T Operation * * * + * 13 Extended Control2 * * * + */ + +#define MII_ICSPHY_ECR 0x10 /* Extended Control Register */ +#define ECR_OVR 0x8000 /* disable command reg overwrites */ +#define ECR_PHYADDR_MASK 0x07c0 /* PHY address mask */ +#define ECR_CTEST 0x0020 /* Stream Cipher Test Mode */ +#define ECR_IECT 0x0004 /* Invalid Error Code Test */ +#define ECR_SSD 0x0001 /* Stream Cipher Disable */ + +#define MII_ICSPHY_QPR 0x11 /* Quick Poll Register */ +#define QPR_SPEED 0x8000 /* 100Mbps */ +#define QPR_FDX 0x4000 /* Full dupled */ +#define QPR_ANB2 0x2000 /* Autoneg monitor bit 2 */ +#define QPR_ANB1 0x1000 /* Autoneg monitor bit 1 */ +#define QPR_ANB0 0x0800 /* Autoneg monitor bit 0 */ +#define QPR_RXERR 0x0400 /* Receive signal lost */ +#define QPR_PLLERR 0x0200 /* PLL error */ +#define QPR_FCARR 0x0100 /* False carrier detected */ +#define QPR_INVALSYM 0x0080 /* Invalid Symbol Detected */ +#define QPR_HALT 0x0040 /* Halt Symbol Detected */ +#define QPR_PREEM 0x0020 /* Two Idle Symbols together */ +#define QPR_ACOMP 0x0010 /* Autonegotiation complete */ +#define QPR_SDETECT 0x0008 /* signal detect */ +#define QPR_JABBER 0x0004 /* Jabber detected */ +#define QPR_RFAULT 0x0002 /* Remote Fault */ +#define QPR_LINK 0x0001 /* Link */ + +#define MII_ICSPHY_TTR 0x12 /* 10baseT Operations Register */ +#define TTR_RJABBER 0x8000 /* Remote Jabber */ +#define TTR_POLARITY 0x4000 /* Polarity Reversed */ +#define TTR_NOJABBER 0x0020 /* Disable Jabber Check */ +#define TTR_LOOP 0x0010 /* Loopback mode */ +#define TTR_NOAPOLARITY 0x0008 /* Disable auto polarity correction */ +#define TTR_NOSQE 0x0004 /* Disable SQE check */ +#define TTR_NOLINK 0x0002 /* Disable Link check */ +#define TTR_NOSQUELCH 0x0001 /* Disable squelch */ + + +/* + * Extended Control Register 2 + * + * HEX 1889 1890 1892 1893 + *------------------------------------------------------------------- + * 8000 Node/Repeater Mode * * * + * 4000 Hardware/Software Mode * * * + * 2000 Link Partner Support Remote Flt * + * 2000 Remote Fault * * + * 1000 + * 0800 + * 0400 Xmitted Remote Fault status * + * 0200 + * 0100 + * 0080 Tri-state Enable * + * 0040 + * 0020 + * 0010 A-N Powerup Remote Flt * + * 0008 + * 0004 + * 0002 Automatic 10Base-T Power Down * + * 0001 Automatic 100Base-TX Power Down * * * + */ + +#define MII_ICSPHY_ECR2 0x13 /* Extended Control Register 2 */ +#define ECR2_REPEATER 0x8000 /* Repeater Mode */ +#define ECR2_HWSW 0x4000 /* hw/sw config priority */ +#define ECR2_LPRF 0x2000 /* link partner supports rem fault */ +#define ECR2_FORCERF 0x0400 /* Force transmit of rem fault */ +#define ECR2_RFPUP 0x0010 /* A-N Powerup Remote fault */ +#define ECR2_10AUTOPWRDN 0x0002 /* Automatic 10baseT power down */ +#define ECR2_100AUTOPWRDN 0x0001 /* Automatic 100baseTX power down */ + +#endif /* _DEV_MII_ICSPHYREG_H_ */ --- src/sys/dev/mii/miidevs Sat Feb 3 18:04:39 2007 +++ src/sys/dev/mii/miidevs Tue Feb 6 19:31:03 2007 @@ -142,7 +142,10 @@ model xxDAVICOM DM9101 0x0000 DM9101 10/100 media interface =20 /* Integrated Circuit Systems PHYs */ +model xxICS 1889 0x0001 ICS1889 10/100 media interface model xxICS 1890 0x0002 ICS1890 10/100 media interface +model xxICS 1892 0x0003 ICS1892 10/100 media interface +model xxICS 1893 0x0004 ICS1893 10/100 media interface =20 /* IC Plus Corp. PHYs */ model ICPLUS IP1000A 0x0008 IC Plus 10/100/1000 media interface --- src/sys/modules/mii/Makefile Tue Jul 25 02:20:11 2006 +++ src/sys/modules/mii/Makefile Tue Feb 6 19:19:59 2007 @@ -5,7 +5,7 @@ KMOD=3D miibus SRCS=3D mii.c mii_physubr.c ukphy.c ukphy_subr.c bus_if.h pci_if.h SRCS+=3D miibus_if.h miidevs.h device_if.h miibus_if.c e1000phy.c exphy.c = nsphy.c -SRCS+=3D mlphy.c tlphy.c rlphy.c amphy.c inphy.c tdkphy.c +SRCS+=3D mlphy.c tlphy.c rlphy.c amphy.c icsphy.c inphy.c tdkphy.c SRCS+=3D bmtphy.c brgphy.c xmphy.c pnaphy.c lxtphy.c qsphy.c acphy.c nsgph= y.c SRCS+=3D rgephy.c ruephy.c ciphy.c gentbi.c ip1000phy.c =20 --EgVrEAR5UttbsTXg-- --H4SyuGOnfnj3aJqJ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFF9B2d52SDGA2eCwURAnb7AJ45hUVFrjQhpwyLu91lbVXg4BHR5wCfd6zs DlusUN7JTqevOJnT4+2SeIA= =kQgf -----END PGP SIGNATURE----- --H4SyuGOnfnj3aJqJ-- From owner-freebsd-current@FreeBSD.ORG Sun Mar 11 15:23:04 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AE79816A400 for ; Sun, 11 Mar 2007 15:23:04 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (palm.hoeg.nl [83.98.131.212]) by mx1.freebsd.org (Postfix) with ESMTP id 78A1D13C45E for ; Sun, 11 Mar 2007 15:23:04 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 97F471CC50; Sun, 11 Mar 2007 16:23:42 +0100 (CET) Date: Sun, 11 Mar 2007 16:23:42 +0100 From: Ed Schouten To: Rainer Hurling Message-ID: <20070311152342.GH7449@hoeg.nl> References: <20070310074734.GC70613@cdnetworks.co.kr> <917080.87242.qm@web34701.mail.mud.yahoo.com> <20070311050627.GC79728@cdnetworks.co.kr> <45F3B94B.3030104@gwdg.de> <20070311151749.GG7449@hoeg.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HB4mHL4PVvkpZAgW" Content-Disposition: inline In-Reply-To: <20070311151749.GG7449@hoeg.nl> User-Agent: Mutt/1.5.14 (2007-02-12) Cc: pyunyh@gmail.com, darren780@yahoo.com, FreeBSD Current Subject: Re: yongari nfe problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Mar 2007 15:23:04 -0000 --HB4mHL4PVvkpZAgW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Ed Schouten wrote: > * Rainer Hurling wrote: > > ukphy0: PHY 1 on miibus0 > > ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT,=20 > > 1000baseT-FDX, auto >=20 > Rainer, maybe your motherboard has an ICS18xx physical interface. Could > you try the following kernel patch? It adds a driver from NetBSD, > icsphy(4). Thanks! Errr - never mind. Your system has a 1Gbit interface. icsphy(4) is only for 10/100Mbit. Test results for systems with an ICS PHY are welcome, though ;-) --=20 Ed Schouten WWW: http://g-rave.nl/ --HB4mHL4PVvkpZAgW Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFF9B7+52SDGA2eCwURAg6PAJ96WJiO74fo1g3NeQGdXCRo2RQl3QCeI2Fe GvCrxCnfDJyMnw0kKGQyFtM= =4uyG -----END PGP SIGNATURE----- --HB4mHL4PVvkpZAgW-- From owner-freebsd-current@FreeBSD.ORG Sun Mar 11 18:59:12 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2E5E116A402 for ; Sun, 11 Mar 2007 18:59:12 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outA.internet-mail-service.net (outA.internet-mail-service.net [216.240.47.224]) by mx1.freebsd.org (Postfix) with ESMTP id 1CD5013C465 for ; Sun, 11 Mar 2007 18:59:12 +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, 11 Mar 2007 11:32:25 -0700 Received: from [192.168.2.5] (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id AD542125B99; Sun, 11 Mar 2007 11:58:58 -0700 (PDT) Message-ID: <45F45172.8070601@elischer.org> Date: Sun, 11 Mar 2007 11:58:58 -0700 From: Julian Elischer User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: Julian Elischer References: <45F388D4.2080900@elischer.org> In-Reply-To: <45F388D4.2080900@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current Subject: Re: netstat wierdness? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Mar 2007 18:59:12 -0000 Julian Elischer wrote: > just did make buildworld buildkernel installkernel installworld mergemaster > reboot.. > > netstat now doesn't seem to be able to show open tcp sessions: > > I'm ssh'd into this machien so ther eIS at least one tcp session. > > > root@trafmon1:netstat > Active UNIX domain sockets > Address Type Recv-Q Send-Q Inode Conn Refs Nextref Addr > 0 #0 131073 0 c6420ae0 0 0 0 0 > #0 131073 0 c6505d98 0 0 0 0 > #0 2 0 0 c6536410 0 c65371a0 > 0 #0 2 0 0 c6536410 0 c65350d0 > 0 #0 2 0 0 c6536410 0 c6513c30 > 0 #0 2 0 0 c6536410 0 c65375b0 > 0 #0 2 0 0 c6536410 0 0 > 0 #0 2 0 c641f828 0 0 0 0 > #0 2 0 c641f984 0 0 0 0 > #0 2 0 c6429984 0 c65131a0 0 0 > #0 2 0 c642b000 0 0 0 > root@trafmon1:netstat -ptcp -aA > root@trafmon1: > > this is on 2 different machines > > anyone else seeing this? > answering myself.. comes from having options LOCK_PROFILING in my kernel. adding the same to /etc/make.conf and recompiling netstat and libkvm helped. (not sure if both are needed) > > _______________________________________________ > 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 Mar 11 20:07:17 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D939216A404 for ; Sun, 11 Mar 2007 20:07:17 +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 A925413C455 for ; Sun, 11 Mar 2007 20:07:17 +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 51AE37DA4; Sun, 11 Mar 2007 21:07:16 +0100 (CET) Received: from obiwan.tataz.chchile.org (unknown [192.168.1.25]) by tatooine.tataz.chchile.org (Postfix) with ESMTP id 369EA9BF12; Sun, 11 Mar 2007 20:07:15 +0000 (UTC) Received: by obiwan.tataz.chchile.org (Postfix, from userid 1000) id 2C60F4065; Sun, 11 Mar 2007 21:07:15 +0100 (CET) Date: Sun, 11 Mar 2007 21:07:15 +0100 From: Jeremie Le Hen To: Greg 'groggy' Lehey Message-ID: <20070311200715.GI2887@obiwan.tataz.chchile.org> References: <20070311000148.GF2887@obiwan.tataz.chchile.org> <20070311001631.GO1189@wantadilla.lemis.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070311001631.GO1189@wantadilla.lemis.com> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: freebsd-current@FreeBSD.org Subject: Re: Cannot burn DVD with IDE recorder X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Mar 2007 20:07:17 -0000 Greg, On Sun, Mar 11, 2007 at 10:46:31AM +1030, Greg 'groggy' Lehey wrote: > On Sunday, 11 March 2007 at 1:01:48 +0100, Jeremie Le Hen wrote: > > AFAIK, I had formerly been able to write CD (with a -CURRENT as of > > late october or november IIRC). I've upgraded my kernel since then: > > > > FreeBSD 7.0-CURRENT #26: Sat Mar 3 23:46:16 UTC 2007 > > > > Unfortunately, I cannot write a DVD. > > Not the answer you're looking for, but I've always used atapicam for > this. Haven't tried it on -CURRENT recently, though. Better than nothing :). Would you explain a bit further please ? Thank you. Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-current@FreeBSD.ORG Sun Mar 11 20:15:42 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8D9B516A404 for ; Sun, 11 Mar 2007 20:15:42 +0000 (UTC) (envelope-from dunstan@freebsd.czest.pl) Received: from freebsd.czest.pl (freebsd.czest.pl [80.48.250.4]) by mx1.freebsd.org (Postfix) with ESMTP id ED5A913C46E for ; Sun, 11 Mar 2007 20:15:41 +0000 (UTC) (envelope-from dunstan@freebsd.czest.pl) Received: from freebsd.czest.pl (freebsd.czest.pl [80.48.250.4]) by freebsd.czest.pl (8.13.4/8.12.9) with ESMTP id l2BKEQPZ007515; Sun, 11 Mar 2007 20:14:27 GMT (envelope-from dunstan@freebsd.czest.pl) Received: (from dunstan@localhost) by freebsd.czest.pl (8.13.4/8.12.9/Submit) id l2BKEPKi007514; Sun, 11 Mar 2007 20:14:25 GMT (envelope-from dunstan) Date: Sun, 11 Mar 2007 20:14:23 +0000 From: "Wojciech A. Koszek" To: Julian Elischer Message-ID: <20070311201423.GA7486@FreeBSD.czest.pl> References: <45F388D4.2080900@elischer.org> <45F45172.8070601@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline In-Reply-To: <45F45172.8070601@elischer.org> User-Agent: Mutt/1.4.2.1i X-Greylist: Sender DNS name whitelisted, not delayed by milter-greylist-2.0.2 (freebsd.czest.pl [80.48.250.4]); Sun, 11 Mar 2007 20:14:27 +0000 (UTC) Cc: FreeBSD Current Subject: Re: netstat wierdness? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Mar 2007 20:15:42 -0000 On Sun, Mar 11, 2007 at 11:58:58AM -0700, Julian Elischer wrote: > Julian Elischer wrote: > >just did make buildworld buildkernel installkernel installworld mergemaster > >reboot.. > > > >netstat now doesn't seem to be able to show open tcp sessions: > > > >I'm ssh'd into this machien so ther eIS at least one tcp session. > > > > > >root@trafmon1:netstat > >Active UNIX domain sockets > >Address Type Recv-Q Send-Q Inode Conn Refs Nextref Addr > > 0 #0 131073 0 c6420ae0 0 0 0 0 > >#0 131073 0 c6505d98 0 0 0 0 > >#0 2 0 0 c6536410 0 c65371a0 > > 0 #0 2 0 0 c6536410 0 c65350d0 > > 0 #0 2 0 0 c6536410 0 c6513c30 > > 0 #0 2 0 0 c6536410 0 c65375b0 > > 0 #0 2 0 0 c6536410 0 0 > > 0 #0 2 0 c641f828 0 0 0 0 > >#0 2 0 c641f984 0 0 0 0 > >#0 2 0 c6429984 0 c65131a0 0 0 > >#0 2 0 c642b000 0 0 0 > >root@trafmon1:netstat -ptcp -aA > >root@trafmon1: > > > >this is on 2 different machines > > > >anyone else seeing this? > > > > answering myself.. > comes from having options LOCK_PROFILING in my kernel. > adding the same to /etc/make.conf and recompiling netstat and libkvm helped. > (not sure if both are needed) Having netstat(1) recompiled should be enough. -- Wojciech A. Koszek wkoszek@FreeBSD.org http://FreeBSD.czest.pl/dunstan/ From owner-freebsd-current@FreeBSD.ORG Sun Mar 11 20:51:22 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8D45216A403 for ; Sun, 11 Mar 2007 20:51:22 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from kientzle.com (h-66-166-149-50.snvacaid.covad.net [66.166.149.50]) by mx1.freebsd.org (Postfix) with ESMTP id 6CDB213C46A for ; Sun, 11 Mar 2007 20:51:22 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from [10.0.0.222] (p54.kientzle.com [66.166.149.54]) by kientzle.com (8.12.9/8.12.9) with ESMTP id l2BKC124095620 for ; Sun, 11 Mar 2007 12:12:01 -0800 (PST) (envelope-from kientzle@freebsd.org) Message-ID: <45F46291.4090209@freebsd.org> Date: Sun, 11 Mar 2007 13:12:01 -0700 From: Tim Kientzle User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20060422 X-Accept-Language: en-us, en MIME-Version: 1.0 To: current@freebsd.org References: <200703111036.l2BAaha6031394@repoman.freebsd.org> In-Reply-To: <200703111036.l2BAaha6031394@repoman.freebsd.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: cvs commit: src/usr.bin/tar Makefile bsdtar.c bsdtar.h bsdtar_platform.h config_freebsd.h getdate.y matching.c read.c tree.c util.c write.c src/usr.bin/tar/test config.sh test-acl.sh test-basic.sh test-deep-dir.sh test-flags.sh test-nodump.sh ... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Mar 2007 20:51:22 -0000 > kientzle 2007-03-11 10:36:43 UTC > FreeBSD src repository > bsdtar 2.0.23: > * read.c now relies on security checks in libarchive instead > of trying to do its own... Bsdtar should now be considerably faster than before. I put a lot of effort over the last few months into streamlining the code in libarchive to recreate objects on disk. I'd appreciate any feedback on the performance of this latest bsdtar when restoring archives. I'm particularly interested in performance compared to GNU tar for uncompressed archives with and without the "-P" option (which disables the security checks). Cheers, Tim Kientzle From owner-freebsd-current@FreeBSD.ORG Sun Mar 11 22:03:47 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3E29816A404 for ; Sun, 11 Mar 2007 22:03:47 +0000 (UTC) (envelope-from SRS0=c2cc9a3d6eb37ce18e8206dff96b5f92f456eb70=271=es.net=oberman@es.net) Received: from postal1.es.net (postal1.es.net [198.128.3.205]) by mx1.freebsd.org (Postfix) with ESMTP id EBB6513C44B for ; Sun, 11 Mar 2007 22:03:46 +0000 (UTC) (envelope-from SRS0=c2cc9a3d6eb37ce18e8206dff96b5f92f456eb70=271=es.net=oberman@es.net) Received: from ptavv.es.net (ptavv.es.net [198.128.4.29]) by postal1.es.net (Postal Node 1) with ESMTP (SSL) id QZK56825; Sun, 11 Mar 2007 14:51:25 -0800 Received: from ptavv.es.net (ptavv.es.net [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id CBC0945053; Sun, 11 Mar 2007 14:51:28 -0700 (PDT) To: Jeremie Le Hen In-Reply-To: Your message of "Sun, 11 Mar 2007 21:07:15 BST." <20070311200715.GI2887@obiwan.tataz.chchile.org> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_1173649888_26399P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Sun, 11 Mar 2007 14:51:28 -0700 From: "Kevin Oberman" Message-Id: <20070311215128.CBC0945053@ptavv.es.net> Cc: Greg 'groggy' Lehey , freebsd-current@FreeBSD.org Subject: Re: Cannot burn DVD with IDE recorder X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Mar 2007 22:03:47 -0000 --==_Exmh_1173649888_26399P Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > Date: Sun, 11 Mar 2007 21:07:15 +0100 > From: Jeremie Le Hen > Sender: owner-freebsd-current@freebsd.org > > Greg, > > On Sun, Mar 11, 2007 at 10:46:31AM +1030, Greg 'groggy' Lehey wrote: > > On Sunday, 11 March 2007 at 1:01:48 +0100, Jeremie Le Hen wrote: > > > AFAIK, I had formerly been able to write CD (with a -CURRENT as of > > > late october or november IIRC). I've upgraded my kernel since then: > > > > > > FreeBSD 7.0-CURRENT #26: Sat Mar 3 23:46:16 UTC 2007 > > > > > > Unfortunately, I cannot write a DVD. > > > > Not the answer you're looking for, but I've always used atapicam for > > this. Haven't tried it on -CURRENT recently, though. > > Better than nothing :). Would you explain a bit further please ? Build a kernel with 'device atapicam' or load the atapicam kernel module. (I have never tried the module, but it is there.) After this, you will have a device cdX for every acdX. It is a SCSI device and will work with all of the SCSI CD and DVD ports like cdrtools (cdrecord) and dvd+rw-tools. camcontrol(8) will also work on the cd devices. Note that scbus and cam must also be in the kernel if you build the kernel with atapicam. -- 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_1173649888_26399P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) Comment: Exmh version 2.5 06/03/2002 iD8DBQFF9Hngkn3rs5h7N1ERAsvrAKCjYH0acZxxjUFjMFGkXYK75OKk7gCfUqU/ aXFg7XMGT6C5IFsS8zEmSIg= =Z0+K -----END PGP SIGNATURE----- --==_Exmh_1173649888_26399P-- From owner-freebsd-current@FreeBSD.ORG Sun Mar 11 22:22:34 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6FE3A16A401 for ; Sun, 11 Mar 2007 22:22:34 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from kientzle.com (h-66-166-149-50.snvacaid.covad.net [66.166.149.50]) by mx1.freebsd.org (Postfix) with ESMTP id 5294113C448 for ; Sun, 11 Mar 2007 22:22:34 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from [10.0.0.222] (p54.kientzle.com [66.166.149.54]) by kientzle.com (8.12.9/8.12.9) with ESMTP id l2BMMQ24096128 for ; Sun, 11 Mar 2007 14:22:30 -0800 (PST) (envelope-from kientzle@freebsd.org) Message-ID: <45F48122.7030309@freebsd.org> Date: Sun, 11 Mar 2007 15:22:26 -0700 From: Tim Kientzle User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20060422 X-Accept-Language: en-us, en MIME-Version: 1.0 To: current@freebsd.org References: <200703111036.l2BAaha6031394@repoman.freebsd.org> <45F46291.4090209@freebsd.org> In-Reply-To: <45F46291.4090209@freebsd.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Bsdtar performance X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Mar 2007 22:22:34 -0000 Tim Kientzle wrote: >> kientzle 2007-03-11 10:36:43 UTC >> FreeBSD src repository >> bsdtar 2.0.23: >> * read.c now relies on security checks in libarchive instead >> of trying to do its own... > > Bsdtar should now be considerably faster than before. > I put a lot of effort over the last few months into > streamlining the code in libarchive to recreate objects > on disk. Here are some initial test results for bsdtar 2.0.22. This test extracts an uncompressed ustar version of "base.tgz" from a 5.3 distribution CD to a blank 300MB malloc-backed disk on a single-processor i386 system with 1G physical RAM. bsdtar -xPf: 1.53 seconds gtar-1.13.25: 1.57 seconds gtar-1.15.1: 1.58 seconds bsdtar -xf: 1.59 seconds gtar-1.16.1: 1.61 seconds star: 1.82 seconds I used /usr/bin/time -xf ~/base.ustar and ran each program at least 10 times, discarded the outliers and averaged the rest. (The user time varied quite a bit, interestingly enough.) Obviously, these results should vary dramatically depending on the hardware ane the archive being tested (mix of dirs, small files, large files, etc), so I'm very eager to see results from other people (especially any where bsdtar performs poorly). Tim Kientzle P.S. to create a ustar version of the 5.3 distribution, use bsdtar as a format-conversion filter: cat base.?? | bsdtar -cf ~/base.ustar --format=ustar @- From owner-freebsd-current@FreeBSD.ORG Sun Mar 11 22:31:59 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D2D3316A401 for ; Sun, 11 Mar 2007 22:31:59 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from kientzle.com (h-66-166-149-50.snvacaid.covad.net [66.166.149.50]) by mx1.freebsd.org (Postfix) with ESMTP id A18BC13C448 for ; Sun, 11 Mar 2007 22:31:59 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from [10.0.0.222] (p54.kientzle.com [66.166.149.54]) by kientzle.com (8.12.9/8.12.9) with ESMTP id l2BMVx24096161 for ; Sun, 11 Mar 2007 14:31:59 -0800 (PST) (envelope-from kientzle@freebsd.org) Message-ID: <45F4835F.2060907@freebsd.org> Date: Sun, 11 Mar 2007 15:31:59 -0700 From: Tim Kientzle User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20060422 X-Accept-Language: en-us, en MIME-Version: 1.0 To: current@freebsd.org References: <200703111036.l2BAaha6031394@repoman.freebsd.org> <45F46291.4090209@freebsd.org> <45F48122.7030309@freebsd.org> In-Reply-To: <45F48122.7030309@freebsd.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: Bsdtar performance X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Mar 2007 22:31:59 -0000 I left out some important numbers, which I've filled in below. > Here are some initial test results for bsdtar 2.0.22. > > bsdtar -xPf: 1.53 seconds > gtar-1.13.25: 1.57 seconds > gtar-1.15.1: 1.58 seconds > bsdtar -xf: 1.59 seconds > gtar-1.16.1: 1.61 seconds bsdtar-1.2.53 -xPf: 1.61 seconds bsdtar-1.2.53 -xf: 1.76 seconds > star: 1.82 seconds Cheers, Tim Kientzle From owner-freebsd-current@FreeBSD.ORG Sun Mar 11 23:04:48 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C9A5816A403 for ; Sun, 11 Mar 2007 23:04:48 +0000 (UTC) (envelope-from grog@lemis.com) Received: from ext-gw.lemis.com (ext-gw.lemis.com [150.101.14.10]) by mx1.freebsd.org (Postfix) with ESMTP id 6C31913C45A for ; Sun, 11 Mar 2007 23:04:48 +0000 (UTC) (envelope-from grog@lemis.com) Received: from wantadilla.lemis.com (wantadilla.lemis.com [192.109.197.135]) by ext-gw.lemis.com (Postfix) with ESMTP id D6360133DB8; Mon, 12 Mar 2007 09:34:44 +1030 (CST) Received: by wantadilla.lemis.com (Postfix, from userid 1004) id D1DD91A9C91; Mon, 12 Mar 2007 09:34:44 +1030 (CST) Date: Mon, 12 Mar 2007 09:34:44 +1030 From: Greg 'groggy' Lehey To: Kevin Oberman Message-ID: <20070311230444.GA97046@wantadilla.lemis.com> References: <20070311200715.GI2887@obiwan.tataz.chchile.org> <20070311215128.CBC0945053@ptavv.es.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="9amGYk9869ThD9tj" Content-Disposition: inline In-Reply-To: <20070311215128.CBC0945053@ptavv.es.net> User-Agent: Mutt/1.4.2.1i Organization: The FreeBSD Project Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 VoIP: sip:0871270137@sip.internode.on.net WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 9A1B 8202 BCCE B846 F92F 09AC 22E6 F290 507A 4223 Cc: freebsd-current@FreeBSD.org, Jeremie Le Hen Subject: Re: Cannot burn DVD with IDE recorder X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Mar 2007 23:04:48 -0000 --9amGYk9869ThD9tj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sunday, 11 March 2007 at 14:51:28 -0700, Kevin Oberman wrote: >> Date: Sun, 11 Mar 2007 21:07:15 +0100 >> From: Jeremie Le Hen >> Sender: owner-freebsd-current@freebsd.org >> >> Greg, >> >> On Sun, Mar 11, 2007 at 10:46:31AM +1030, Greg 'groggy' Lehey wrote: >>> On Sunday, 11 March 2007 at 1:01:48 +0100, Jeremie Le Hen wrote: >>>> AFAIK, I had formerly been able to write CD (with a -CURRENT as of >>>> late october or november IIRC). I've upgraded my kernel since then: >>>> >>>> FreeBSD 7.0-CURRENT #26: Sat Mar 3 23:46:16 UTC 2007 >>>> >>>> Unfortunately, I cannot write a DVD. >>> >>> Not the answer you're looking for, but I've always used atapicam for >>> this. Haven't tried it on -CURRENT recently, though. >> >> Better than nothing :). Would you explain a bit further please ? > > Build a kernel with 'device atapicam' or load the atapicam kernel > module. (I have never tried the module, but it is there.) Yes, and that's what I use. Greg -- See complete headers for address and phone numbers. --9amGYk9869ThD9tj Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (FreeBSD) iD8DBQFF9IsMIubykFB6QiMRAlNBAJ9VmXRoyY8+im1bTivb3lKM/NWOtACeM96L Mg+nk/Xlx2RYleq17drY2Wc= =gHVb -----END PGP SIGNATURE----- --9amGYk9869ThD9tj-- From owner-freebsd-current@FreeBSD.ORG Sun Mar 11 23:53:38 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CE97A16A401; Sun, 11 Mar 2007 23:53:38 +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 7FD9113C469; Sun, 11 Mar 2007 23:53:38 +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.6/8.13.6) with ESMTP id l2BNrbGJ059139; Sun, 11 Mar 2007 19:53:37 -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 l2BNrbJt077642; Sun, 11 Mar 2007 19:53:37 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 2615773039; Sun, 11 Mar 2007 18:53:37 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070311235337.2615773039@freebsd-current.sentex.ca> Date: Sun, 11 Mar 2007 18:53:37 -0500 (EST) X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on clamscanner2 X-Virus-Scanned: ClamAV version devel-20070102, clamav-milter version devel-111206 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: Sun, 11 Mar 2007 23:53:38 -0000 TB --- 2007-03-11 23:14:06 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-03-11 23:14:06 - starting HEAD tinderbox run for i386/pc98 TB --- 2007-03-11 23:14:06 - cleaning the object tree TB --- 2007-03-11 23:14:39 - checking out the source tree TB --- 2007-03-11 23:14:39 - cd /tinderbox/HEAD/i386/pc98 TB --- 2007-03-11 23:14:39 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-03-11 23:22:53 - building world (CFLAGS=-O2 -pipe) TB --- 2007-03-11 23:22:53 - cd /src TB --- 2007-03-11 23:22:53 - /usr/bin/make -B buildworld >>> World build started on Sun Mar 11 23:22:54 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 [...] cc -O2 -pipe -I. -I/src/bin/csh -I/src/bin/csh/../../contrib/tcsh -D_PATH_TCSHELL='"/bin/csh"' -DHAVE_ICONV -c /src/bin/csh/../../contrib/tcsh/sh.exp.c cc -O2 -pipe -I. -I/src/bin/csh -I/src/bin/csh/../../contrib/tcsh -D_PATH_TCSHELL='"/bin/csh"' -DHAVE_ICONV -c /src/bin/csh/../../contrib/tcsh/sh.file.c cc -O2 -pipe -I. -I/src/bin/csh -I/src/bin/csh/../../contrib/tcsh -D_PATH_TCSHELL='"/bin/csh"' -DHAVE_ICONV -c /src/bin/csh/../../contrib/tcsh/sh.func.c /src/bin/csh/../../contrib/tcsh/sh.func.c: In function `iconv_catgets': /src/bin/csh/../../contrib/tcsh/sh.func.c:2371: error: syntax error before "char" /src/bin/csh/../../contrib/tcsh/sh.func.c:2377: error: `src' undeclared (first use in this function) /src/bin/csh/../../contrib/tcsh/sh.func.c:2377: error: (Each undeclared identifier is reported only once /src/bin/csh/../../contrib/tcsh/sh.func.c:2377: error: for each function it appears in.) *** Error code 1 Stop in /src/bin/csh. *** Error code 1 Stop in /src/bin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-03-11 23:53:36 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-03-11 23:53:36 - ERROR: failed to build world TB --- 2007-03-11 23:53:36 - tinderbox aborted TB --- 0.77 user 2.78 system 2370.68 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Mon Mar 12 00:10:28 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5B34216A401; Mon, 12 Mar 2007 00:10:28 +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 40C8413C45D; Mon, 12 Mar 2007 00:10:28 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id D4EDC1A4D80; Sun, 11 Mar 2007 17:10:27 -0700 (PDT) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 09C11512B3; Sun, 11 Mar 2007 20:10:27 -0400 (EDT) Date: Sun, 11 Mar 2007 20:10:26 -0400 From: Kris Kennaway To: Tim Kientzle Message-ID: <20070312001026.GA20000@xor.obsecurity.org> References: <200703111036.l2BAaha6031394@repoman.freebsd.org> <45F46291.4090209@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gKMricLos+KVdGMg" Content-Disposition: inline In-Reply-To: <45F46291.4090209@freebsd.org> User-Agent: Mutt/1.4.2.2i Cc: current@freebsd.org Subject: BSDtar performance vs GNUtar (Re: cvs commit: src/usr.bin/tar Makefile bsdtar.c bsdtar.h bsdtar_platform.h config_freebsd.h getdate.y matching.c read.c tree.c util.c write.c src/usr.bin/tar/test config.sh test-acl.sh test-basic.sh test-deep-dir.sh test-flags.sh test-nodump.sh ...) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Mar 2007 00:10:28 -0000 --gKMricLos+KVdGMg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Mar 11, 2007 at 01:12:01PM -0700, Tim Kientzle wrote: > >kientzle 2007-03-11 10:36:43 UTC > > FreeBSD src repository > > bsdtar 2.0.23: > > * read.c now relies on security checks in libarchive instead > > of trying to do its own... >=20 > Bsdtar should now be considerably faster than before. > I put a lot of effort over the last few months into > streamlining the code in libarchive to recreate objects > on disk. >=20 > I'd appreciate any feedback on the performance of this latest > bsdtar when restoring archives. I'm particularly interested in > performance compared to GNU tar for uncompressed archives > with and without the "-P" option (which disables the security > checks). This is extracting a ~1GB copy of the ports tree (also containing some other cruft like distfiles and some work directories), to an async swap backed md, which was destroyed and recreated in between runs. The first archive was created with bsdtar (tar cvf ports.tar ports) which made gtar bitch a bit about unknown options (SCHILY.*) when extracting it. This did not seem to affect peformance though, as I confirmed by using gtar to recreate the archive itself and then timing that. Extracting with -P: x gtar-real + bsdtar-real +------------------------------------------------------------+ | + | | + + + x x | |+ + + ++ + x x x x x x x x| | |_____AM___| |________A_________| | +------------------------------------------------------------+ N Min Max Median Avg Stddev x 10 23.85 28.92 25.7 25.816 1.4355115 + 10 20.41 23.14 22.535 22.409 0.79712609 Difference at 95.0% confidence -3.407 +/- 1.09092 -13.1972% +/- 4.22577% (Student's t, pooled s =3D 1.16106) i.e. bsdtar has gone from being about 40% slower than gtar to ~13% faster than it (system time is also proportionally lower on bsdtar). Extracting without -P does not show a statistically significant difference with gtar, but bsdtar is slightly slower: x bsdtar-real-P + bsdtar-real-noP +------------------------------------------------------------+ | x + + | |x x x xxx xx + + +| | |_____________A_M__________| |__AM__| | +------------------------------------------------------------+ N Min Max Median Avg Stddev x 10 20.41 23.14 22.535 22.409 0.79712609 + 5 23.47 23.92 23.68 23.65 0.18854708 Difference at 95.0% confidence 1.241 +/- 0.794373 5.53795% +/- 3.54488% (Student's t, pooled s =3D 0.671444) It is still clearly faster than gtar (though not by as much): x gtar-real-noP + bsdtar-real-P +------------------------------------------------------------+ |+ | |+ ++x + x xx x| ||____A___| |__________________A___M______________| | +------------------------------------------------------------+ N Min Max Median Avg Stddev x 5 23.75 25.93 25.18 24.996 0.79245189 + 5 23.47 23.92 23.68 23.65 0.18854708 Difference at 95.0% confidence -1.346 +/- 0.840049 -5.38486% +/- 3.36073% (Student's t, pooled s =3D 0.57599) Excellent work! Kris --gKMricLos+KVdGMg Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFF9JpyWry0BWjoQKURAj+sAKCKwt05OADkdCMWs1M/v+1r6hrAiQCg8TN8 MCd3dj5mzoQPy7c2WLkQSv8= =yFZJ -----END PGP SIGNATURE----- --gKMricLos+KVdGMg-- From owner-freebsd-current@FreeBSD.ORG Mon Mar 12 00:42:29 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 651D516A400 for ; Mon, 12 Mar 2007 00:42:29 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from kientzle.com (h-66-166-149-50.snvacaid.covad.net [66.166.149.50]) by mx1.freebsd.org (Postfix) with ESMTP id 4532E13C455 for ; Mon, 12 Mar 2007 00:42:29 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from [10.0.0.222] (p54.kientzle.com [66.166.149.54]) by kientzle.com (8.12.9/8.12.9) with ESMTP id l2C0gS24096698; Sun, 11 Mar 2007 16:42:28 -0800 (PST) (envelope-from kientzle@freebsd.org) Message-ID: <45F4A1F4.4060703@freebsd.org> Date: Sun, 11 Mar 2007 17:42:28 -0700 From: Tim Kientzle User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20060422 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kris Kennaway References: <200703111036.l2BAaha6031394@repoman.freebsd.org> <45F46291.4090209@freebsd.org> <20070312001026.GA20000@xor.obsecurity.org> In-Reply-To: <20070312001026.GA20000@xor.obsecurity.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: BSDtar performance vs GNUtar (Re: cvs commit: src/usr.bin/tar Makefile bsdtar.c bsdtar.h bsdtar_platform.h config_freebsd.h getdate.y matching.c read.c tree.c util.c write.c src/usr.bin/tar/test config.sh test-acl.sh test-basic.sh test-deep-dir.sh test-flags.sh test-nodump.sh ...) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Mar 2007 00:42:29 -0000 >>Bsdtar should now be considerably faster than before. >>I'd appreciate any feedback ... > > The first archive was created with bsdtar (tar cvf ports.tar ports) > which made gtar bitch a bit .... Which version of gtar were you using? In my testing, there's a small but definite slowdown from gtar 1.13 to 1.15 to 1.16. > ... gtar bitch a bit about unknown options (SCHILY.*) ... bsdtar should probably warn about unknown options as well; I'll have to look into that. (It's a little tricky because libarchive is set up to only return one error for any one operation. I might have to generalize that.) Now that gtar is following standards, I wonder if they'll adopt some of the extensions developed by other people? (Such as Joerg Schilling's solid work on integrating file flags and ACL support into pax format.) Tim Kientzle From owner-freebsd-current@FreeBSD.ORG Mon Mar 12 01:05:33 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C2A3F16A403; Mon, 12 Mar 2007 01:05:33 +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 B154F13C45B; Mon, 12 Mar 2007 01:05:33 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id 8E8081A4D83; Sun, 11 Mar 2007 18:05:33 -0700 (PDT) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id C0FE551401; Sun, 11 Mar 2007 21:05:32 -0400 (EDT) Date: Sun, 11 Mar 2007 21:05:32 -0400 From: Kris Kennaway To: Tim Kientzle Message-ID: <20070312010532.GA21000@xor.obsecurity.org> References: <200703111036.l2BAaha6031394@repoman.freebsd.org> <45F46291.4090209@freebsd.org> <20070312001026.GA20000@xor.obsecurity.org> <45F4A1F4.4060703@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="W/nzBZO5zC0uMSeA" Content-Disposition: inline In-Reply-To: <45F4A1F4.4060703@freebsd.org> User-Agent: Mutt/1.4.2.2i Cc: current@freebsd.org, Kris Kennaway Subject: Re: BSDtar performance vs GNUtar (Re: cvs commit: src/usr.bin/tar Makefile bsdtar.c bsdtar.h bsdtar_platform.h config_freebsd.h getdate.y matching.c read.c tree.c util.c write.c src/usr.bin/tar/test config.sh test-acl.sh test-basic.sh test-deep-dir.sh test-flags.sh test-nodump.sh ...) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Mar 2007 01:05:33 -0000 --W/nzBZO5zC0uMSeA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Mar 11, 2007 at 05:42:28PM -0700, Tim Kientzle wrote: > >>Bsdtar should now be considerably faster than before. > >>I'd appreciate any feedback ... > > > >The first archive was created with bsdtar (tar cvf ports.tar ports) > >which made gtar bitch a bit .... >=20 > Which version of gtar were you using? >=20 > In my testing, there's a small but definite slowdown > from gtar 1.13 to 1.15 to 1.16. 1.16.1, latest from ports. > >... gtar bitch a bit about unknown options (SCHILY.*) ... >=20 > bsdtar should probably warn about unknown options as well; > I'll have to look into that. (It's a little tricky because > libarchive is set up to only return one error for any > one operation. I might have to generalize that.) This was an archive created by bsdtar, so they shouldn't have been unknown to it :) > Now that gtar is following standards, I wonder if > they'll adopt some of the extensions developed > by other people? (Such as Joerg Schilling's solid > work on integrating file flags and ACL support into > pax format.) That would be nice. Kris --W/nzBZO5zC0uMSeA Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFF9KdcWry0BWjoQKURAkMOAJ4p4L+m+XOln2hhk3EpfP6nIfzRmgCgm1IC ClfmnCPyKSLJj89uATtUlqs= =wYog -----END PGP SIGNATURE----- --W/nzBZO5zC0uMSeA-- From owner-freebsd-current@FreeBSD.ORG Mon Mar 12 01:20:59 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 04A6D16A401 for ; Mon, 12 Mar 2007 01:20:59 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from kientzle.com (h-66-166-149-50.snvacaid.covad.net [66.166.149.50]) by mx1.freebsd.org (Postfix) with ESMTP id D760713C45E for ; Mon, 12 Mar 2007 01:20:58 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from [10.0.0.222] (p54.kientzle.com [66.166.149.54]) by kientzle.com (8.12.9/8.12.9) with ESMTP id l2C1Kw24096872; Sun, 11 Mar 2007 17:20:58 -0800 (PST) (envelope-from kientzle@freebsd.org) Message-ID: <45F4AAFA.1020908@freebsd.org> Date: Sun, 11 Mar 2007 18:20:58 -0700 From: Tim Kientzle User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20060422 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kris Kennaway References: <200703111036.l2BAaha6031394@repoman.freebsd.org> <45F46291.4090209@freebsd.org> <20070312001026.GA20000@xor.obsecurity.org> <45F4A1F4.4060703@freebsd.org> <20070312010532.GA21000@xor.obsecurity.org> In-Reply-To: <20070312010532.GA21000@xor.obsecurity.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: BSDtar performance vs GNUtar (Re: cvs commit: src/usr.bin/tar Makefile bsdtar.c bsdtar.h bsdtar_platform.h config_freebsd.h getdate.y matching.c read.c tree.c util.c write.c src/usr.bin/tar/test config.sh test-acl.sh test-basic.sh test-deep-dir.sh test-flags.sh test-nodump.sh ...) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Mar 2007 01:20:59 -0000 >>>... gtar bitch a bit about unknown options (SCHILY.*) ... >> >>bsdtar should probably warn about unknown options as well; >>I'll have to look into that. > > This was an archive created by bsdtar, so they shouldn't have been > unknown to it :) Yes, but the GNU tar folks, in particular, have introduced a bunch of new options just in the last year, so bsdtar is increasingly likely to see options it doesn't know. For example, I should add support for the new GNU tar sparse file format soon. Tim From owner-freebsd-current@FreeBSD.ORG Mon Mar 12 04:49:15 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 763B316A406 for ; Mon, 12 Mar 2007 04:49:15 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.240]) by mx1.freebsd.org (Postfix) with ESMTP id 2D4FE13C45A for ; Mon, 12 Mar 2007 04:49:15 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by an-out-0708.google.com with SMTP id c24so1183699ana for ; Sun, 11 Mar 2007 21:49: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:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=m3cBCXnJu24eAD1G1ARSWd12cEhR/vhZhbpLbniQn+/h7FHv6Fg3J09A0o/mC0vq3I/RKW80kAP/I+Jrlags/tIwi4YOW/vhPR0tmzLo3PojVnapH1/igzyyYohpy+CXAyLBqUzriQ1KOFbRZwG7mWdOB82OecZ/pq7onFTiQt8= 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=OgTs7/AbXA+s/4UnLT2/K7OuPpuNKNprEpOhy6EX9rXiuYnUSAPzK0E10QiyBbsFs2ow2+naZlFrcrmWOTBGTN+CdzXjRzGbvlVu/Mv2wZhPaXsFul3QjWdJB018VxdkB5tXshkkGe8v+hvxVfJVT8nGl0UMIPqK+nLlQUswW14= Received: by 10.35.38.17 with SMTP id q17mr2576645pyj.1173674954324; Sun, 11 Mar 2007 21:49:14 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTP id 5sm27501172nzk.2007.03.11.21.49.11; Sun, 11 Mar 2007 21:49:13 -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 l2C4pJFI084477 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 Mar 2007 13:51:19 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id l2C4pGDR084476; Mon, 12 Mar 2007 13:51:16 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Mon, 12 Mar 2007 13:51:16 +0900 From: Pyun YongHyeon To: Rainer Hurling Message-ID: <20070312045116.GA83433@cdnetworks.co.kr> References: <20070310074734.GC70613@cdnetworks.co.kr> <917080.87242.qm@web34701.mail.mud.yahoo.com> <20070311050627.GC79728@cdnetworks.co.kr> <45F3B94B.3030104@gwdg.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45F3B94B.3030104@gwdg.de> User-Agent: Mutt/1.4.2.1i Cc: darren780@yahoo.com, freebsd-current@freebsd.org Subject: Re: yongari nfe problems 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, 12 Mar 2007 04:49:15 -0000 On Sun, Mar 11, 2007 at 09:09:47AM +0100, Rainer Hurling wrote: > Pyun YongHyeon schrieb: > >[... SNIP ...] > > > >Did stock nfe(4) work on MCP55? > >(I'm not interested in how nve(4) works on MCP55.) > >I'm afraid MCP55 requires different programming. Searching archives > >for Linux forcedeth driver also reveals issues on MCP55 which is > >exactly the same issue I think. > >I'll let you know if I find a clue but it's hard to fix due to lack > >of MCP55 hardware and documentation. > > > Yes, nfe(4) works on MCP55, but with some strange behaviour, see below. > > I am working with FreeBSD 7.0-CURRENT from 03/07/2007 on MSI K9N Neo. > 'dmesg | grep nfe' gives me: > > nfe0: port 0xb000-0xb007 mem > 0xfbef7000-0xfbef7fff,0xfbefa800-0xfbefa8ff,0xfbefa400-0xfbefa40f irq 21 > at device 8.0 on pci0 > miibus0: on nfe0 > ukphy0: PHY 1 on miibus0 > ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, > 1000baseT-FDX, auto > nfe0: using obsoleted if_watchdog interface > nfe0: Ethernet address: xx:xx:xx:xx:xx:xx > nfe0: [ITHREAD] > > It seems that there is a problem with watchdog. Perhaps the choosen > media interface ukphy0 is not correct? > Normally nVidia GigEs use Marvell PHY which is served by e1000phy(4) so I guess power saving mode had ukphy attach the PHY. Booting/loading module with bootverbose mode will show up OUI/model/rev of the PHY. Please let me know the OUI/model/rev output of ukphy(4). > In the context with watchdog I observe an interesting behaviour of nfe0: > After running WindowsXP on my board, I am not able to use the interface > any more. Booting FreeBSD always gives me messages like this: > > ----- > nfe0: link state changed to DOWN > /etc/rc.d/dhclient: WARNING: $background_dhclient_nfe0 is not set > properly - > see > rc.conf(5). > nfe0: no link ....nfe0: link state changed to UP > got link > DHCPREQUEST on nfe0 to 255.255.255.255 port 67 > nfe0: watchdog timeout > nfe0: link state changed to DOWN > nfe0: link state changed to UP > DHCPREQUEST on nfe0 to 255.255.255.255 port 67 > nfe0: watchdog timeout > nfe0: link state changed to DOWN > nfe0: link state changed to UP > DHCPDISCOVER on nfe0 to 255.255.255.255 port 67 interval 5 > nfe0: watchdog timeout > nfe0: link state changed to DOWN > DHCPDISCOVER on nfe0 to 255.255.255.255 port 67 interval 9 > nfe0: link state changed to UP > nfe0: watchdog timeout > nfe0: link state changed to DOWN > nfe0: link state changed to UP > DHCPDISCOVER on nfe0 to 255.255.255.255 port 67 interval 14 > nfe0: watchdog timeout > nfe0: link state changed to DOWN > nfe0: link state changed to UP > DHCPDISCOVER on nfe0 to 255.255.255.255 port 67 interval 18 > nfe0: watchdog timeout > nfe0: link state changed to DOWN > nfe0: link state changed to UP > DHCPDISCOVER on nfe0 to 255.255.255.255 port 67 interval 9 > nfe0: watchdog timeout > nfe0: link state changed to DOWN > nfe0: link state changed to UP > DHCPDISCOVER on nfe0 to 255.255.255.255 port 67 interval 6 > nfe0: watchdog timeout > nfe0: link state changed to DOWN > No DHCPOFFERS received. > Trying recorded lease xxx.xxx.xxx.xxx > nfe0: link state changed to UP > bound: renewal in 429590 seconds. > lo0: flags=8049 metric 0 mtu 16384 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 > inet6 ::1 prefixlen 128 > inet 127.0.0.1 netmask 0xff000000 > nfe0: flags=8843 metric 0 mtu 1500 > options=2b > ether xx:xx:xx:xx:xx:xx > media: Ethernet autoselect (100baseTX ) > status: active > ----- > > When booting 'cold' (means full power down) FreeBSD is able to use > nfe(4) in the correct way. Also booting FreeBSD again after running > FreeBSD gives me no errors. Obviously WindowsXP does not clear up all > registers in MCP55 after leaving? > I think Windows put the NIC/PHY in sleep/power saving mode and nfe(4) will need a way to take PHY/NIC out of power down mode. Try a WIP version at the following URL. http://people.freebsd.org/~yongari/nfe/WIP/if_nfe.c http://people.freebsd.org/~yongari/nfe/WIP/if_nfereg.h http://people.freebsd.org/~yongari/nfe/WIP/if_nfevar.h Note, it's just guess work from the Linux driver and I just tested compilation. Due to lack of time/MCP55 hardware it's not easy for me to fix. > Rainer Hurling -- Regards, Pyun YongHyeon From owner-freebsd-current@FreeBSD.ORG Mon Mar 12 09:57:11 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7FEC616A400 for ; Mon, 12 Mar 2007 09:57:11 +0000 (UTC) (envelope-from fullermd@over-yonder.net) Received: from optimus.centralmiss.com (ns.centralmiss.com [206.156.254.79]) by mx1.freebsd.org (Postfix) with ESMTP id 59B7813C457 for ; Mon, 12 Mar 2007 09:57:11 +0000 (UTC) (envelope-from fullermd@over-yonder.net) Received: from draco.over-yonder.net (adsl-072-148-013-213.sip.jan.bellsouth.net [72.148.13.213]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by optimus.centralmiss.com (Postfix) with ESMTP id A3296287C9 for ; Mon, 12 Mar 2007 04:57:10 -0500 (CDT) Received: by draco.over-yonder.net (Postfix, from userid 100) id 2A2BC61C41; Mon, 12 Mar 2007 04:57:10 -0500 (CDT) Date: Mon, 12 Mar 2007 04:57:10 -0500 From: "Matthew D. Fuller" To: freebsd-current@freebsd.org Message-ID: <20070312095710.GI22586@over-yonder.net> References: <20070211050825.GA70508@over-yonder.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070211050825.GA70508@over-yonder.net> X-Editor: vi X-OS: FreeBSD User-Agent: Mutt/1.5.14-fullermd.3 (2007-02-12) Subject: Re: softdep_waitidle: Failed to flush worklist [...] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Mar 2007 09:57:11 -0000 On Sat, Feb 10, 2007 at 11:08:25PM -0600 I heard the voice of Matthew D. Fuller, and lo! it spake thus: > > This is trivially reproducible, and rather scary. And still happening with Friday's -CURRENT. -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. From owner-freebsd-current@FreeBSD.ORG Mon Mar 12 10:17:08 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 711EE16A401 for ; Mon, 12 Mar 2007 10:17:08 +0000 (UTC) (envelope-from fullermd@over-yonder.net) Received: from optimus.centralmiss.com (ns.centralmiss.com [206.156.254.79]) by mx1.freebsd.org (Postfix) with ESMTP id 4CFBE13C44C for ; Mon, 12 Mar 2007 10:17:08 +0000 (UTC) (envelope-from fullermd@over-yonder.net) Received: from draco.over-yonder.net (adsl-072-148-013-213.sip.jan.bellsouth.net [72.148.13.213]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by optimus.centralmiss.com (Postfix) with ESMTP id C6C3028828 for ; Mon, 12 Mar 2007 05:17:07 -0500 (CDT) Received: by draco.over-yonder.net (Postfix, from userid 100) id 3D00561C41; Mon, 12 Mar 2007 05:17:07 -0500 (CDT) Date: Mon, 12 Mar 2007 05:17:07 -0500 From: "Matthew D. Fuller" To: freebsd-current@freebsd.org Message-ID: <20070312101707.GJ22586@over-yonder.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Editor: vi X-OS: FreeBSD User-Agent: Mutt/1.5.14-fullermd.3 (2007-02-12) Subject: ATA kablooie X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Mar 2007 10:17:08 -0000 I have a box that until Friday night was running a Nov '05 -CURRENT solidly. After an upgrade, it started spewing out kernel: ad4: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=38617823 style warnings at the slightest provocation. A "find / -xdev -print | xargs cat >> /dev/null" could bring it about in a second or two; not uncommonly, the arduous effort of spawning off 'sh' for single-user mode was enough to put it over the cliff. The system runs an ataraid RAID-1 across ad4 and ad6; which got the first errors was pretty luck of the draw on any given boot. They're on a Promise TX2200 card: atapci0: port 0xc000-0xc07f,0xc400-0xc4ff mem 0xeb420000-0xeb420fff,0xeb400000-0xeb41ffff irq 15 at device 13.0 on pci0 The card/drives were tried in 3 very different motherboards, all of which failed identically. BIOSen were scoured for "make PCI edgy" options, which were all turned off (though none exhibited a "enable bus master" option, as one seemingly-related mail thread ended with). I tried using the loader variable to force the drives to PIO mode to jam the brakes on, but it didn't seem to work at all (maybe it doesn't affect SATA?). I tried splitting the RAID so it only dealt with one drive; made no difference. The -CURRENT build was from identical sources to those currently sitting on this machine, so I can supply $Id$'s if it'll help. Sadly, the system needed to be running, so it's not available for further experimentation. It ran flawlessly with that Nov '05 -CURRENT, and is now running flawlessly on RELENG_6. -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. From owner-freebsd-current@FreeBSD.ORG Mon Mar 12 12:36:35 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3C14B16A400 for ; Mon, 12 Mar 2007 12:36:35 +0000 (UTC) (envelope-from ivoras@fer.hr) Received: from pinus.cc.fer.hr (pinus.cc.fer.hr [161.53.73.18]) by mx1.freebsd.org (Postfix) with ESMTP id 8FA5213C455 for ; Mon, 12 Mar 2007 12:36:29 +0000 (UTC) (envelope-from ivoras@fer.hr) Received: from [161.53.72.113] (lara.cc.fer.hr [161.53.72.113]) by pinus.cc.fer.hr (8.12.2/8.12.2) with ESMTP id l2CChhxw017935; Mon, 12 Mar 2007 13:43:44 +0100 (MET) Message-ID: <45F5494B.9040104@fer.hr> Date: Mon, 12 Mar 2007 13:36:27 +0100 From: Ivan Voras User-Agent: Thunderbird 1.5.0.9 (X11/20060911) MIME-Version: 1.0 To: mjacob@freebsd.org References: <45F18183.7050405@FreeBSD.org> <45F182F2.10604@fer.hr> <70e8236f0703091240q65d45300u836121454d799c64@mail.gmail.com> <45F1C77C.8010103@fer.hr> <70e8236f0703091413o473db67fr451e3be49c44b025@mail.gmail.com> <20070309142918.V61513@ns1.feral.com> <45F1E27A.7090302@fer.hr> <20070309150157.L61706@ns1.feral.com> <45F1EB35.6020303@fer.hr> <20070309151901.L61859@ns1.feral.com> <45F1F08E.5030902@fer.hr> <20070309173523.P62771@ns1.feral.com> In-Reply-To: <20070309173523.P62771@ns1.feral.com> Content-Type: multipart/mixed; boundary="------------000009040606010703070803" Cc: freebsd-current@freebsd.org Subject: Re: MFC request: QLogic 24xx FibreChannel controller X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Mar 2007 12:36:35 -0000 This is a multi-part message in MIME format. --------------000009040606010703070803 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit mjacob@freebsd.org wrote: >>> hint.isp.0.debug=0x105 >>> >>> set and send me the boot output, would you? Here's the entire dmesg. It looks like there are now 4 (!?) devices pointing to the same FC "drive"? --------------000009040606010703070803 Content-Type: text/plain; name="dmesg.txt" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="dmesg.txt" Q29weXJpZ2h0IChjKSAxOTkyLTIwMDcgVGhlIEZyZWVCU0QgUHJvamVjdC4KQ29weXJpZ2h0 IChjKSAxOTc5LCAxOTgwLCAxOTgzLCAxOTg2LCAxOTg4LCAxOTg5LCAxOTkxLCAxOTkyLCAx OTkzLCAxOTk0CglUaGUgUmVnZW50cyBvZiB0aGUgVW5pdmVyc2l0eSBvZiBDYWxpZm9ybmlh LiBBbGwgcmlnaHRzIHJlc2VydmVkLgpGcmVlQlNEIGlzIGEgcmVnaXN0ZXJlZCB0cmFkZW1h cmsgb2YgVGhlIEZyZWVCU0QgRm91bmRhdGlvbi4KRnJlZUJTRCA2LjItU1RBQkxFICM0OiBG cmkgTWFyICA5IDE3OjEwOjMyIENFVCAyMDA3CiAgICBpdm9yYXNAcXVhZC5jYy5mZXIuaHI6 L3Vzci9vYmovdXNyL3NyYy9zeXMvUEFFU01QClRpbWVjb3VudGVyICJpODI1NCIgZnJlcXVl bmN5IDExOTMxODIgSHogcXVhbGl0eSAwCkNQVTogRHVhbC1Db3JlIEFNRCBPcHRlcm9uKHRt KSBQcm9jZXNzb3IgMjIxNiBIRSAoMjQwMC4xMC1NSHogNjg2LWNsYXNzIENQVSkKICBPcmln aW4gPSAiQXV0aGVudGljQU1EIiAgSWQgPSAweDQwZjEyICBTdGVwcGluZyA9IDIKICBGZWF0 dXJlcz0weDE3OGJmYmZmPEZQVSxWTUUsREUsUFNFLFRTQyxNU1IsUEFFLE1DRSxDWDgsQVBJ QyxTRVAsTVRSUixQR0UsTUNBLENNT1YsUEFULFBTRTM2LENMRkxVU0gsTU1YLEZYU1IsU1NF LFNTRTIsSFRUPgogIEZlYXR1cmVzMj0weDIwMDE8U1NFMyxDWDE2PgogIEFNRCBGZWF0dXJl cz0weGVhNTAwODAwPFNZU0NBTEwsTlgsTU1YKyxGRlhTUixSRFRTQ1AsTE0sM0ROb3crLDNE Tm93PgogIEFNRCBGZWF0dXJlczI9MHgxZjxMQUhGLENNUCw8YjI+LDxiMz4sQ1I4PgogIENv cmVzIHBlciBwYWNrYWdlOiAyCnJlYWwgbWVtb3J5ICA9IDQ4MTUwNjA5OTIgKDQ1OTIgTUIp CmF2YWlsIG1lbW9yeSA9IDQxOTEwNTU4NzIgKDM5OTYgTUIpCkFDUEkgQVBJQyBUYWJsZTog PElCTSAgICBTRVJMRVdJUz4KRnJlZUJTRC9TTVA6IE11bHRpcHJvY2Vzc29yIFN5c3RlbSBE ZXRlY3RlZDogNCBDUFVzCiBjcHUwIChCU1ApOiBBUElDIElEOiAgMAogY3B1MSAoQVApOiBB UElDIElEOiAgMQogY3B1MiAoQVApOiBBUElDIElEOiAgMgogY3B1MyAoQVApOiBBUElDIElE OiAgMwppb2FwaWMxIDxWZXJzaW9uIDEuMT4gaXJxcyAxNi0zMSBvbiBtb3RoZXJib2FyZApp b2FwaWMwIDxWZXJzaW9uIDEuMT4gaXJxcyAwLTE1IG9uIG1vdGhlcmJvYXJkCmtiZDEgYXQg a2JkbXV4MAphY3BpMDogPElCTSBTRVJMRVdJUz4gb24gbW90aGVyYm9hcmQKYWNwaV9idXNf bnVtYmVyOiBjYW4ndCBnZXQgX0FEUgphY3BpX2J1c19udW1iZXI6IGNhbid0IGdldCBfQURS CmFjcGlfYnVzX251bWJlcjogY2FuJ3QgZ2V0IF9BRFIKYWNwaV9idXNfbnVtYmVyOiBjYW4n dCBnZXQgX0FEUgphY3BpX2J1c19udW1iZXI6IGNhbid0IGdldCBfQURSCmFjcGlfYnVzX251 bWJlcjogY2FuJ3QgZ2V0IF9BRFIKYWNwaTA6IFBvd2VyIEJ1dHRvbiAoZml4ZWQpCmFjcGlf YnVzX251bWJlcjogY2FuJ3QgZ2V0IF9BRFIKYWNwaV9idXNfbnVtYmVyOiBjYW4ndCBnZXQg X0FEUgp1bmtub3duOiBJL08gcmFuZ2Ugbm90IHN1cHBvcnRlZAp1bmtub3duOiBJL08gcmFu Z2Ugbm90IHN1cHBvcnRlZAp1bmtub3duOiBJL08gcmFuZ2Ugbm90IHN1cHBvcnRlZAp1bmtu b3duOiBJL08gcmFuZ2Ugbm90IHN1cHBvcnRlZApUaW1lY291bnRlciAiQUNQSS1zYWZlIiBm cmVxdWVuY3kgMzU3OTU0NSBIeiBxdWFsaXR5IDEwMDAKYWNwaV90aW1lcjA6IDwzMi1iaXQg dGltZXIgYXQgMy41Nzk1NDVNSHo+IHBvcnQgMHg0ODgtMHg0OGIgb24gYWNwaTAKY3B1MDog PEFDUEkgQ1BVPiBvbiBhY3BpMAphY3BpX3Rocm90dGxlMDogPEFDUEkgQ1BVIFRocm90dGxp bmc+IG9uIGNwdTAKY3B1MTogPEFDUEkgQ1BVPiBvbiBhY3BpMAphY3BpX3Rocm90dGxlMTog PEFDUEkgQ1BVIFRocm90dGxpbmc+IG9uIGNwdTEKYWNwaV90aHJvdHRsZTE6IGZhaWxlZCB0 byBhdHRhY2ggUF9DTlQKZGV2aWNlX2F0dGFjaDogYWNwaV90aHJvdHRsZTEgYXR0YWNoIHJl dHVybmVkIDYKY3B1MjogPEFDUEkgQ1BVPiBvbiBhY3BpMAphY3BpX3Rocm90dGxlMjogPEFD UEkgQ1BVIFRocm90dGxpbmc+IG9uIGNwdTIKYWNwaV90aHJvdHRsZTI6IGZhaWxlZCB0byBh dHRhY2ggUF9DTlQKZGV2aWNlX2F0dGFjaDogYWNwaV90aHJvdHRsZTIgYXR0YWNoIHJldHVy bmVkIDYKY3B1MzogPEFDUEkgQ1BVPiBvbiBhY3BpMAphY3BpX3Rocm90dGxlMzogPEFDUEkg Q1BVIFRocm90dGxpbmc+IG9uIGNwdTMKYWNwaV90aHJvdHRsZTM6IGZhaWxlZCB0byBhdHRh Y2ggUF9DTlQKZGV2aWNlX2F0dGFjaDogYWNwaV90aHJvdHRsZTMgYXR0YWNoIHJldHVybmVk IDYKcGNpYjA6IDxBQ1BJIEhvc3QtUENJIGJyaWRnZT4gb24gYWNwaTAKcGNpMDogPEFDUEkg UENJIGJ1cz4gb24gcGNpYjAKcGNpYjE6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZp Y2UgMS4wIG9uIHBjaTAKcGNpMTogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjEKcGNpYjI6IDxB Q1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgMTMuMCBvbiBwY2kxCnBjaTI6IDxBQ1BJ IFBDSSBidXM+IG9uIHBjaWIyCmJjZTA6IDxCcm9hZGNvbSBOZXRYdHJlbWUgSUkgQkNNNTcw NiAxMDAwQmFzZS1TWCAoQTIpLCB2MC45LjY+IG1lbSAweGVhMDAwMDAwLTB4ZWJmZmZmZmYg aXJxIDE3IGF0IGRldmljZSA0LjAgb24gcGNpMgpiY2UwOiBBU0lDIElEIDB4NTcwNjAwMjE7 IFJldmlzaW9uIChBMik7IFBDSS1YIDY0LWJpdCAxMzNNSHoKbWlpYnVzMDogPE1JSSBidXM+ IG9uIGJjZTAKZ2VudGJpMDogPEdlbmVyaWMgdGVuLWJpdCBpbnRlcmZhY2U+IG9uIG1paWJ1 czAKZ2VudGJpMDogIDEwMDBiYXNlU1gsIDEwMDBiYXNlU1gtRkRYLCBhdXRvCmJjZTA6IEV0 aGVybmV0IGFkZHJlc3M6IDAwOjE0OjVlOjZkOjJkOjc0CmJjZTE6IDxCcm9hZGNvbSBOZXRY dHJlbWUgSUkgQkNNNTcwNiAxMDAwQmFzZS1TWCAoQTIpLCB2MC45LjY+IG1lbSAweGVjMDAw MDAwLTB4ZWRmZmZmZmYgaXJxIDE4IGF0IGRldmljZSA1LjAgb24gcGNpMgpiY2UxOiBBU0lD IElEIDB4NTcwNjAwMjE7IFJldmlzaW9uIChBMik7IFBDSS1YIDY0LWJpdCAxMzNNSHoKbWlp YnVzMTogPE1JSSBidXM+IG9uIGJjZTEKZ2VudGJpMTogPEdlbmVyaWMgdGVuLWJpdCBpbnRl cmZhY2U+IG9uIG1paWJ1czEKZ2VudGJpMTogIDEwMDBiYXNlU1gsIDEwMDBiYXNlU1gtRkRY LCBhdXRvCmJjZTE6IEV0aGVybmV0IGFkZHJlc3M6IDAwOjE0OjVlOmIzOjJhOjM4CmlzYWIw OiA8UENJLUlTQSBicmlkZ2U+IGF0IGRldmljZSAyLjIgb24gcGNpMAppc2EwOiA8SVNBIGJ1 cz4gb24gaXNhYjAKb2hjaTA6IDxPSENJIChnZW5lcmljKSBVU0IgY29udHJvbGxlcj4gcG9y dCAweDMwMDAtMHgzMGZmIG1lbSAweGY5ZmZmMDAwLTB4ZjlmZmZmZmYgaXJxIDMgYXQgZGV2 aWNlIDMuMCBvbiBwY2kwCm9oY2kwOiBbR0lBTlQtTE9DS0VEXQp1c2IwOiBPSENJIHZlcnNp b24gMS4wLCBsZWdhY3kgc3VwcG9ydAp1c2IwOiBTTU0gZG9lcyBub3QgcmVzcG9uZCwgcmVz ZXR0aW5nCnVzYjA6IDxPSENJIChnZW5lcmljKSBVU0IgY29udHJvbGxlcj4gb24gb2hjaTAK dXNiMDogVVNCIHJldmlzaW9uIDEuMAp1aHViMDogKDB4MTE2NikgT0hDSSByb290IGh1Yiwg Y2xhc3MgOS8wLCByZXYgMS4wMC8xLjAwLCBhZGRyIDEKdWh1YjA6IDIgcG9ydHMgd2l0aCAy IHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkCm9oY2kxOiA8T0hDSSAoZ2VuZXJpYykgVVNCIGNv bnRyb2xsZXI+IHBvcnQgMHgzMTAwLTB4MzFmZiBtZW0gMHhmOWZmZTAwMC0weGY5ZmZlZmZm IGlycSAzIGF0IGRldmljZSAzLjEgb24gcGNpMApvaGNpMTogW0dJQU5ULUxPQ0tFRF0KdXNi MTogT0hDSSB2ZXJzaW9uIDEuMCwgbGVnYWN5IHN1cHBvcnQKdXNiMTogPE9IQ0kgKGdlbmVy aWMpIFVTQiBjb250cm9sbGVyPiBvbiBvaGNpMQp1c2IxOiBVU0IgcmV2aXNpb24gMS4wCnVo dWIxOiAoMHgxMTY2KSBPSENJIHJvb3QgaHViLCBjbGFzcyA5LzAsIHJldiAxLjAwLzEuMDAs IGFkZHIgMQp1aHViMTogMiBwb3J0cyB3aXRoIDIgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQK ZWhjaTA6IDxFSENJIChnZW5lcmljKSBVU0IgMi4wIGNvbnRyb2xsZXI+IHBvcnQgMHgzMjAw LTB4MzJmZiBtZW0gMHhmOWZmZDAwMC0weGY5ZmZkZmZmIGlycSAzIGF0IGRldmljZSAzLjIg b24gcGNpMAplaGNpMDogW0dJQU5ULUxPQ0tFRF0KdXNiMjogRUhDSSB2ZXJzaW9uIDEuMAp1 c2IyOiBjb21wYW5pb24gY29udHJvbGxlcnMsIDIgcG9ydHMgZWFjaDogdXNiMCB1c2IxCnVz YjI6IDxFSENJIChnZW5lcmljKSBVU0IgMi4wIGNvbnRyb2xsZXI+IG9uIGVoY2kwCnVzYjI6 IFVTQiByZXZpc2lvbiAyLjAKdWh1YjI6ICgweDExNjYpIEVIQ0kgcm9vdCBodWIsIGNsYXNz IDkvMCwgcmV2IDIuMDAvMS4wMCwgYWRkciAxCnVodWIyOiA0IHBvcnRzIHdpdGggNCByZW1v dmFibGUsIHNlbGYgcG93ZXJlZAp1aHViMzogdmVuZG9yIDB4MDRiNCBwcm9kdWN0IDB4NjU2 MCwgY2xhc3MgOS8wLCByZXYgMi4wMC8wLjA3LCBhZGRyIDIKdWh1YjM6IG11bHRpcGxlIHRy YW5zYWN0aW9uIHRyYW5zbGF0b3JzCnVodWIzOiAyIHBvcnRzIHdpdGggMiByZW1vdmFibGUs IHNlbGYgcG93ZXJlZApwY2kwOiA8ZGlzcGxheSwgVkdBPiBhdCBkZXZpY2UgNS4wIChubyBk cml2ZXIgYXR0YWNoZWQpCnBjaWIzOiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gYXQgZGV2aWNl IDYuMCBvbiBwY2kwCnBjaTM6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIzCm1wdDA6IDxMU0lM b2dpYyBTQVMvU0FUQSBBZGFwdGVyPiBwb3J0IDB4NDAwMC0weDQwZmYgbWVtIDB4ZTgwMTAw MDAtMHhlODAxM2ZmZiwweGU4MDAwMDAwLTB4ZTgwMGZmZmYgaXJxIDE5IGF0IGRldmljZSA0 LjAgb24gcGNpMwptcHQwOiBbR0lBTlQtTE9DS0VEXQptcHQwOiBNUEkgVmVyc2lvbj0xLjUu MTIuMAptcHQwOiBtcHRfY2FtX2V2ZW50OiAweDE2Cm1wdDA6IFVuaGFuZGxlZCBFdmVudCBO b3RpZnkgRnJhbWUuIEV2ZW50IDB4MTYgKEFDSyBub3QgcmVxdWlyZWQpLgptcHQwOiBtcHRf Y2FtX2V2ZW50OiAweDEyCm1wdDA6IFVuaGFuZGxlZCBFdmVudCBOb3RpZnkgRnJhbWUuIEV2 ZW50IDB4MTIgKEFDSyBub3QgcmVxdWlyZWQpLgptcHQwOiBtcHRfY2FtX2V2ZW50OiAweDE2 Cm1wdDA6IFVuaGFuZGxlZCBFdmVudCBOb3RpZnkgRnJhbWUuIEV2ZW50IDB4MTYgKEFDSyBu b3QgcmVxdWlyZWQpLgppc3AwOiA8UWxvZ2ljIElTUCAyNDIyIFBDSSBGQy1BTCBBZGFwdGVy PiBwb3J0IDB4NDEwMC0weDQxZmYgbWVtIDB4ZTgwMTQwMDAtMHhlODAxNGZmZiBpcnEgMjAg YXQgZGV2aWNlIDUuMCBvbiBwY2kzCmlzcDA6IFtHSUFOVC1MT0NLRURdCmlzcDA6IEJvYXJk IFR5cGUgMjQyMiwgQ2hpcCBSZXZpc2lvbiAweDIsIGxvYWRlZCBGL1cgUmV2aXNpb24gNC4w LjIwCmlzcDA6IDJLIExvZ2lucyBTdXBwb3J0ZWQKaXNwMDogTGFzdCBGL1cgcmV2aXNpb24g d2FzIDQuMC4xMwppc3AwOiA0MDk2IG1heCBJL08gY29tbWFuZCBsaW1pdCBzZXQKaXNwMDog bGluZSAxMTk2OiBtYXJrcG9ydGRiCmlzcDA6IFN0YXJ0aW5nIEluaXRpYWwgTG9vcCBEb3du IFRpbWVyCmlzcDE6IDxRbG9naWMgSVNQIDI0MjIgUENJIEZDLUFMIEFkYXB0ZXI+IHBvcnQg MHg0MjAwLTB4NDJmZiBtZW0gMHhlODAxNTAwMC0weGU4MDE1ZmZmIGlycSAyMSBhdCBkZXZp Y2UgNS4xIG9uIHBjaTMKaXNwMTogW0dJQU5ULUxPQ0tFRF0KaXNwMTogQm9hcmQgVHlwZSAy NDIyLCBDaGlwIFJldmlzaW9uIDB4MiwgbG9hZGVkIEYvVyBSZXZpc2lvbiA0LjAuMjAKaXNw MTogMksgTG9naW5zIFN1cHBvcnRlZAppc3AxOiA0MDk2IG1heCBJL08gY29tbWFuZCBsaW1p dCBzZXQKaXNwMTogbGluZSAxMTk2OiBtYXJrcG9ydGRiCmlzcDE6IFN0YXJ0aW5nIEluaXRp YWwgTG9vcCBEb3duIFRpbWVyCnBjaWI0OiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gYXQgZGV2 aWNlIDcuMCBvbiBwY2kwCnBjaTQ6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWI0CnBjaWI1OiA8 QUNQSSBQQ0ktUENJIGJyaWRnZT4gYXQgZGV2aWNlIDguMCBvbiBwY2kwCnBjaTU6IDxBQ1BJ IFBDSSBidXM+IG9uIHBjaWI1CnBjaWI2OiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gYXQgZGV2 aWNlIDkuMCBvbiBwY2kwCnBjaTY6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWI2CnBjaWI3OiA8 QUNQSSBQQ0ktUENJIGJyaWRnZT4gYXQgZGV2aWNlIDEwLjAgb24gcGNpMApwY2k3OiA8QUNQ SSBQQ0kgYnVzPiBvbiBwY2liNwpwY2liODogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGF0IGRl dmljZSAxMS4wIG9uIHBjaTAKcGNpODogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjgKc2lvMDog PDE2NTUwQS1jb21wYXRpYmxlIENPTSBwb3J0PiBwb3J0IDB4M2Y4LTB4M2ZmIGlycSA0IGZs YWdzIDB4MTAgb24gYWNwaTAKc2lvMDogdHlwZSAxNjU1MEEKcG10aW1lcjAgb24gaXNhMApv cm0wOiA8SVNBIE9wdGlvbiBST00+IGF0IGlvbWVtIDB4YzAwMDAtMHhjYWZmZiBvbiBpc2Ew CmF0YTAgYXQgcG9ydCAweDFmMC0weDFmNywweDNmNiBpcnEgMTQgb24gaXNhMAphdGExIGF0 IHBvcnQgMHgxNzAtMHgxNzcsMHgzNzYgaXJxIDE1IG9uIGlzYTAKYXRrYmRjMDogPEtleWJv YXJkIGNvbnRyb2xsZXIgKGk4MDQyKT4gYXQgcG9ydCAweDYwLDB4NjQgb24gaXNhMAphdGti ZDA6IDxBVCBLZXlib2FyZD4gaXJxIDEgb24gYXRrYmRjMAprYmQwIGF0IGF0a2JkMAphdGti ZDA6IFtHSUFOVC1MT0NLRURdCnBwYzA6IHBhcmFsbGVsIHBvcnQgbm90IGZvdW5kLgpzYzA6 IDxTeXN0ZW0gY29uc29sZT4gYXQgZmxhZ3MgMHgxMDAgb24gaXNhMApzYzA6IFZHQSA8MTYg dmlydHVhbCBjb25zb2xlcywgZmxhZ3M9MHgzMDA+CnNpbzE6IGNvbmZpZ3VyZWQgaXJxIDMg bm90IGluIGJpdG1hcCBvZiBwcm9iZWQgaXJxcyAwCnNpbzE6IHBvcnQgbWF5IG5vdCBiZSBl bmFibGVkCnZnYTA6IDxHZW5lcmljIElTQSBWR0E+IGF0IHBvcnQgMHgzYzAtMHgzZGYgaW9t ZW0gMHhhMDAwMC0weGJmZmZmIG9uIGlzYTAKVGltZWNvdW50ZXJzIHRpY2sgZXZlcnkgMi4w MDAgbXNlYwppc3AxOiBsaW5lIDUyNzQ6IG1hcmtwb3J0ZGIKaXNwMTogbGluZSA1MzYzOiBt YXJrcG9ydGRiCmlzcDE6IFN0b3BwaW5nIExvb3AgRG93biBUaW1lcgppc3AxOiBsaW5lIDUz MTA6IG1hcmtwb3J0ZGIKaXNwMTogbGluZSA1MzQ4OiBtYXJrcG9ydGRiCmlzcDE6IGxpbmUg NTM0ODogbWFya3BvcnRkYgppc3AxOiBsaW5lIDUzNDg6IG1hcmtwb3J0ZGIKaXNwMDogaXNw X2t0aHJlYWQ6IGNoZWNraW5nIEZDIHN0YXRlCmlzcDA6IEZDIExpbmsgVGVzdCBFbnRyeQpp c3AwOiBsaW5lIDI0NTA6IG1hcmtwb3J0ZGIKaXNwMTogaXNwX2t0aHJlYWQ6IGNoZWNraW5n IEZDIHN0YXRlCmlzcDE6IEZDIExpbmsgVGVzdCBFbnRyeQppc3AxOiBsaW5lIDI0NTA6IG1h cmtwb3J0ZGIKaXNwMDogRmlybXdhcmUgU3RhdGUgPENvbmZpZyBXYWl0LT5Mb3NzIE9mIFN5 bmM+CmlzcDE6IEZpcm13YXJlIFN0YXRlIDxDb25maWcgV2FpdC0+UmVhZHk+CmlzcDE6IFJl Z2lzdGVyIEZDNCBUeXBlIGFjY2VwdGVkCmlzcDE6IEhCQSBQb3J0SUQgMHg4MjA1MDAgTi1Q b3J0IEhhbmRsZSAwLCBDb25uZWN0aW9uIFRvcG9sb2d5ICdGIFBvcnQnCmlzcDE6IEhCQSBX V05OIDB4MjAwMDAwZTA4YmJhNmQzOSBIQkEgV1dQTiAweDIxMDEwMGUwOGJiYTZkMzkKaXNw MTogRkMgTGluayBUZXN0IENvbXBsZXRlCmlzcDE6IEZDIFNjYW4gRmFicmljCmlzcDE6IGdv dCA5IHBvcnRzIGJhY2sgZnJvbSBuYW1lIHNlcnZlcgppc3AxOiBDaGVja2luZyBGYWJyaWMg UG9ydCAweDgyMDAwMAppc3AxOiBGYWJyaWMgUG9ydCAweDgyMDAwMCBpcyBOZXcgRW50cnkK aXNwMTogQ2hlY2tpbmcgRmFicmljIFBvcnQgMHg4MjAxMDAKaXNwMTogRmFicmljIFBvcnQg MHg4MjAxMDAgaXMgTmV3IEVudHJ5CmlzcDE6IENoZWNraW5nIEZhYnJpYyBQb3J0IDB4ODIw MjAwCmlzcDE6IEZhYnJpYyBQb3J0IDB4ODIwMjAwIGlzIE5ldyBFbnRyeQppc3AxOiBDaGVj a2luZyBGYWJyaWMgUG9ydCAweDgyMDMwMAppc3AxOiBGYWJyaWMgUG9ydCAweDgyMDMwMCBp cyBOZXcgRW50cnkKaXNwMTogQ2hlY2tpbmcgRmFicmljIFBvcnQgMHg4MjA0MDAKaXNwMTog RmFicmljIFBvcnQgMHg4MjA0MDAgaXMgTmV3IEVudHJ5CmlzcDE6IHNraXAgb3Vyc2VsdmVz IEAgUG9ydElEIDB4ODIwNTAwCmlzcDE6IENoZWNraW5nIEZhYnJpYyBQb3J0IDB4ODIwNjAw CmlzcDE6IEZhYnJpYyBQb3J0IDB4ODIwNjAwIGlzIE5ldyBFbnRyeQppc3AxOiBDaGVja2lu ZyBGYWJyaWMgUG9ydCAweDgyMDcwMAppc3AxOiBGYWJyaWMgUG9ydCAweDgyMDcwMCBpcyBO ZXcgRW50cnkKaXNwMTogQ2hlY2tpbmcgRmFicmljIFBvcnQgMHg4MjBmMDAKaXNwMTogRmFi cmljIFBvcnQgMHg4MjBmMDAgaXMgTmV3IEVudHJ5CmlzcDE6IEZDIFNjYW4gRmFicmljIERv bmUKaXNwMTogU3luY2hyb25pemluZyBQREJzCmlzcDE6IFBvcnRJRCAweDgyMDAwMCBoYW5k bGUgMHgxIHJvbGUgVGFyZ2V0IGFycml2ZWQgYXQgdGd0IDAKICAgICAgV1dOTiAweDIwMDQw MGEwYjgyMTUxOTMgV1dQTiAweDIwMDUwMGEwYjgyMTUxOTQKaXNwMTogUG9ydElEIDB4ODIw MTAwIGhhbmRsZSAweDIgcm9sZSBJbml0aWF0b3IgYXJyaXZlZAogICAgICBXV05OIDB4MjAw MTAwZTA4YmE1MDc3MCBXV1BOIDB4MjEwMTAwZTA4YmE1MDc3MAppc3AxOiBQb3J0SUQgMHg4 MjAyMDAgaGFuZGxlIDB4MyByb2xlIEluaXRpYXRvciBhcnJpdmVkCiAgICAgIFdXTk4gMHgy MDAxMDBlMDhiYTU2ODcxIFdXUE4gMHgyMTAxMDBlMDhiYTU2ODcxCmlzcDE6IFBvcnRJRCAw eDgyMDMwMCBoYW5kbGUgMHg0IHJvbGUgSW5pdGlhdG9yIGFycml2ZWQKICAgICAgV1dOTiAw eDIwMDEwMGUwOGJhNWRiNmUgV1dQTiAweDIxMDEwMGUwOGJhNWRiNmUKaXNwMTogUG9ydElE IDB4ODIwNDAwIGhhbmRsZSAweDUgcm9sZSBJbml0aWF0b3IgYXJyaXZlZAogICAgICBXV05O IDB4MjAwMTAwZTA4YmFiNjc2NCBXV1BOIDB4MjEwMTAwZTA4YmFiNjc2NAppc3AxOiBQb3J0 SUQgMHg4MjA2MDAgaGFuZGxlIDB4NiByb2xlIEluaXRpYXRvciBhcnJpdmVkCiAgICAgIFdX Tk4gMHgyMDAxMDBlMDhiYmFhNTNhIFdXUE4gMHgyMTAxMDBlMDhiYmFhNTNhCmlzcDE6IFBv cnRJRCAweDgyMDcwMCBoYW5kbGUgMHg3IHJvbGUgSW5pdGlhdG9yIGFycml2ZWQKICAgICAg V1dOTiAweDIwMDEwMGUwOGJhNTNlNmYgV1dQTiAweDIxMDEwMGUwOGJhNTNlNmYKaXNwMTog UG9ydElEIDB4ODIwZjAwIGhhbmRsZSAweDggcm9sZSBUYXJnZXQgYXJyaXZlZCBhdCB0Z3Qg MQogICAgICBXV05OIDB4MjAwNDAwYTBiODIxNTE5MyBXV1BOIDB4MjAwNDAwYTBiODIxNTE5 NQppc3AxOiBQb3J0SUQgMHhmZmZmZmUgaGFuZGxlIDB4N2ZlIHJvbGUgKG5vbmUpIHN0YXll ZAogICAgICBXV05OIDB4MTAwMDAwMDUxZTM1ZTkxYSBXV1BOIDB4MjAwNTAwMDUxZTM1ZTkx YQppc3AxOiBpc3Bfa3RocmVhZDogRkMgc3RhdGUgT0sKaXNwMTogaXNwX2t0aHJlYWQ6IHJl bGVhc2luZyBzaW1xCmlzcDE6IGlzcF9rdGhyZWFkOiBzbGVlcCB0aW1lIDAKaXNwMDogaXNw X2ZjbGlua190ZXN0OiBub3QgYXQgRldfUkVBRFkgc3RhdGUKaXNwMDogaXNwX2ZjX3J1bnN0 YXRlOiBsaW5rdGVzdCBmYWlsZWQKaXNwMDoga3RocmVhZDogRkMgbG9vcCBub3QgdXAgKGRv d24gY291bnQgMCkKaXNwMDogaXNwX2t0aHJlYWQ6IHJlbGVhc2luZyBzaW1xCmlzcDA6IGlz cF9rdGhyZWFkOiBzbGVlcCB0aW1lIDEKaXNwMDogaXNwX2t0aHJlYWQ6IGNoZWNraW5nIEZD IHN0YXRlCmlzcDA6IEZDIExpbmsgVGVzdCBFbnRyeQppc3AwOiBsaW5lIDI0NTA6IG1hcmtw b3J0ZGIKaXNwMDogRmlybXdhcmUgU3RhdGUgPENvbmZpZyBXYWl0LT5Mb3NzIE9mIFN5bmM+ CmlzcDA6IGlzcF9mY2xpbmtfdGVzdDogbm90IGF0IEZXX1JFQURZIHN0YXRlCmlzcDA6IGlz cF9mY19ydW5zdGF0ZTogbGlua3Rlc3QgZmFpbGVkCmlzcDA6IGt0aHJlYWQ6IEZDIGxvb3Ag bm90IHVwIChkb3duIGNvdW50IDEpCmlzcDA6IGlzcF9rdGhyZWFkOiBzbGVlcCB0aW1lIDEK aXNwMDogaXNwX2t0aHJlYWQ6IGNoZWNraW5nIEZDIHN0YXRlCmlzcDA6IEZDIExpbmsgVGVz dCBFbnRyeQppc3AwOiBsaW5lIDI0NTA6IG1hcmtwb3J0ZGIKaXNwMDogRmlybXdhcmUgU3Rh dGUgPENvbmZpZyBXYWl0LT5Mb3NzIE9mIFN5bmM+CmlzcDA6IGlzcF9mY2xpbmtfdGVzdDog bm90IGF0IEZXX1JFQURZIHN0YXRlCmlzcDA6IGlzcF9mY19ydW5zdGF0ZTogbGlua3Rlc3Qg ZmFpbGVkCmlzcDA6IGt0aHJlYWQ6IEZDIGxvb3Agbm90IHVwIChkb3duIGNvdW50IDIpCmlz cDA6IGlzcF9rdGhyZWFkOiBzbGVlcCB0aW1lIDEKaXNwMDogaXNwX2t0aHJlYWQ6IGNoZWNr aW5nIEZDIHN0YXRlCmlzcDA6IEZDIExpbmsgVGVzdCBFbnRyeQppc3AwOiBsaW5lIDI0NTA6 IG1hcmtwb3J0ZGIKaXNwMDogRmlybXdhcmUgU3RhdGUgPENvbmZpZyBXYWl0LT5Mb3NzIE9m IFN5bmM+CmlzcDA6IGlzcF9mY2xpbmtfdGVzdDogbm90IGF0IEZXX1JFQURZIHN0YXRlCmlz cDA6IGlzcF9mY19ydW5zdGF0ZTogbGlua3Rlc3QgZmFpbGVkCmlzcDA6IGt0aHJlYWQ6IEZD IGxvb3Agbm90IHVwIChkb3duIGNvdW50IDMpCmlzcDA6IGlzcF9rdGhyZWFkOiBzbGVlcCB0 aW1lIDEKaXNwMDogaXNwX2t0aHJlYWQ6IGNoZWNraW5nIEZDIHN0YXRlCmlzcDA6IEZDIExp bmsgVGVzdCBFbnRyeQppc3AwOiBsaW5lIDI0NTA6IG1hcmtwb3J0ZGIKaXNwMDogRmlybXdh cmUgU3RhdGUgPENvbmZpZyBXYWl0LT5Mb3NzIE9mIFN5bmM+CmlzcDA6IGlzcF9mY2xpbmtf dGVzdDogbm90IGF0IEZXX1JFQURZIHN0YXRlCmlzcDA6IGlzcF9mY19ydW5zdGF0ZTogbGlu a3Rlc3QgZmFpbGVkCmlzcDA6IGt0aHJlYWQ6IEZDIGxvb3Agbm90IHVwIChkb3duIGNvdW50 IDQpCmlzcDA6IGlzcF9rdGhyZWFkOiBzbGVlcCB0aW1lIDEKaXNwMDogaXNwX2t0aHJlYWQ6 IGNoZWNraW5nIEZDIHN0YXRlCmlzcDA6IEZDIExpbmsgVGVzdCBFbnRyeQppc3AwOiBsaW5l IDI0NTA6IG1hcmtwb3J0ZGIKaXNwMDogRmlybXdhcmUgU3RhdGUgPENvbmZpZyBXYWl0LT5M b3NzIE9mIFN5bmM+CmlzcDA6IGlzcF9mY2xpbmtfdGVzdDogbm90IGF0IEZXX1JFQURZIHN0 YXRlCmlzcDA6IGlzcF9mY19ydW5zdGF0ZTogbGlua3Rlc3QgZmFpbGVkCmlzcDA6IGt0aHJl YWQ6IEZDIGxvb3Agbm90IHVwIChkb3duIGNvdW50IDUpCmlzcDA6IGlzcF9rdGhyZWFkOiBz bGVlcCB0aW1lIDEKaXNwMDogaXNwX2t0aHJlYWQ6IGNoZWNraW5nIEZDIHN0YXRlCmlzcDA6 IEZDIExpbmsgVGVzdCBFbnRyeQppc3AwOiBsaW5lIDI0NTA6IG1hcmtwb3J0ZGIKaXNwMDog RmlybXdhcmUgU3RhdGUgPENvbmZpZyBXYWl0LT5Mb3NzIE9mIFN5bmM+CmlzcDA6IGlzcF9m Y2xpbmtfdGVzdDogbm90IGF0IEZXX1JFQURZIHN0YXRlCmlzcDA6IGlzcF9mY19ydW5zdGF0 ZTogbGlua3Rlc3QgZmFpbGVkCmlzcDA6IGt0aHJlYWQ6IEZDIGxvb3Agbm90IHVwIChkb3du IGNvdW50IDYpCmlzcDA6IGlzcF9rdGhyZWFkOiBzbGVlcCB0aW1lIDEKaXNwMDogaXNwX2t0 aHJlYWQ6IGNoZWNraW5nIEZDIHN0YXRlCmlzcDA6IEZDIExpbmsgVGVzdCBFbnRyeQppc3Aw OiBsaW5lIDI0NTA6IG1hcmtwb3J0ZGIKaXNwMDogRmlybXdhcmUgU3RhdGUgPENvbmZpZyBX YWl0LT5Mb3NzIE9mIFN5bmM+CmlzcDA6IGlzcF9mY2xpbmtfdGVzdDogbm90IGF0IEZXX1JF QURZIHN0YXRlCmlzcDA6IGlzcF9mY19ydW5zdGF0ZTogbGlua3Rlc3QgZmFpbGVkCmlzcDA6 IGt0aHJlYWQ6IEZDIGxvb3Agbm90IHVwIChkb3duIGNvdW50IDcpCmlzcDA6IGlzcF9rdGhy ZWFkOiBzbGVlcCB0aW1lIDEKaXNwMDogaXNwX2t0aHJlYWQ6IGNoZWNraW5nIEZDIHN0YXRl CmlzcDA6IEZDIExpbmsgVGVzdCBFbnRyeQppc3AwOiBsaW5lIDI0NTA6IG1hcmtwb3J0ZGIK aXNwMDogRmlybXdhcmUgU3RhdGUgPENvbmZpZyBXYWl0LT5Mb3NzIE9mIFN5bmM+CmlzcDA6 IGlzcF9mY2xpbmtfdGVzdDogbm90IGF0IEZXX1JFQURZIHN0YXRlCmlzcDA6IGlzcF9mY19y dW5zdGF0ZTogbGlua3Rlc3QgZmFpbGVkCmlzcDA6IGt0aHJlYWQ6IEZDIGxvb3Agbm90IHVw IChkb3duIGNvdW50IDgpCmlzcDA6IGlzcF9rdGhyZWFkOiBzbGVlcCB0aW1lIDEKaXNwMDog aXNwX2t0aHJlYWQ6IGNoZWNraW5nIEZDIHN0YXRlCmlzcDA6IEZDIExpbmsgVGVzdCBFbnRy eQppc3AwOiBsaW5lIDI0NTA6IG1hcmtwb3J0ZGIKaXNwMDogRmlybXdhcmUgU3RhdGUgPENv bmZpZyBXYWl0LT5Mb3NzIE9mIFN5bmM+CmlzcDA6IGlzcF9mY2xpbmtfdGVzdDogbm90IGF0 IEZXX1JFQURZIHN0YXRlCmlzcDA6IGlzcF9mY19ydW5zdGF0ZTogbGlua3Rlc3QgZmFpbGVk CmlzcDA6IGt0aHJlYWQ6IEZDIGxvb3Agbm90IHVwIChkb3duIGNvdW50IDkpCmlzcDA6IGlz cF9rdGhyZWFkOiBzbGVlcCB0aW1lIDEKaXNwMDogTG9vcCBEb3duIFRpbWVyIGV4cGlyZWQK aXNwMDogaXNwX2t0aHJlYWQ6IGNoZWNraW5nIEZDIHN0YXRlCmlzcDA6IEZDIExpbmsgVGVz dCBFbnRyeQppc3AwOiBsaW5lIDI0NTA6IG1hcmtwb3J0ZGIKaXNwMDogRmlybXdhcmUgU3Rh dGUgPENvbmZpZyBXYWl0LT5Mb3NzIE9mIFN5bmM+CmlzcDA6IGlzcF9mY2xpbmtfdGVzdDog bm90IGF0IEZXX1JFQURZIHN0YXRlCmlzcDA6IGlzcF9mY19ydW5zdGF0ZTogbGlua3Rlc3Qg ZmFpbGVkCmlzcDA6IGt0aHJlYWQ6IEZDIGxvb3Agbm90IHVwIChkb3duIGNvdW50IDMwMikK aXNwMDogaXNwX2t0aHJlYWQ6IHJlbGVhc2luZyBzaW1xCmlzcDA6IGlzcF9rdGhyZWFkOiBz bGVlcCB0aW1lIDAKZGExIGF0IGlzcDEgYnVzIDAgdGFyZ2V0IDAgbHVuIDAKZGExOiA8SUJN IDE3MjQtMTAwICBGQVN0VCAwNTQyPiBGaXhlZCBEaXJlY3QgQWNjZXNzIFNDU0ktMyBkZXZp Y2UgCmRhMTogMTAwLjAwME1CL3MgdHJhbnNmZXJzLCBUYWdnZWQgUXVldWVpbmcgRW5hYmxl ZApkYTE6IDIwNDgwTUIgKDQxOTQzMDQwIDUxMiBieXRlIHNlY3RvcnM6IDI1NUggNjNTL1Qg MjYxMEMpCmRhMiBhdCBpc3AxIGJ1cyAwIHRhcmdldCAxIGx1biAwCmRhMjogPElCTSAxNzI0 LTEwMCAgRkFTdFQgMDU0Mj4gRml4ZWQgRGlyZWN0IEFjY2VzcyBTQ1NJLTMgZGV2aWNlIApk YTI6IDEwMC4wMDBNQi9zIHRyYW5zZmVycywgVGFnZ2VkIFF1ZXVlaW5nIEVuYWJsZWQKZGEy OiAyMDQ4ME1CICg0MTk0MzA0MCA1MTIgYnl0ZSBzZWN0b3JzOiAyNTVIIDYzUy9UIDI2MTBD KQpkYTAgYXQgbXB0MCBidXMgMCB0YXJnZXQgMCBsdW4gMApkYTA6IDxJQk0tRVNYUyBNQVky MDczUkMgVDEwNz4gRml4ZWQgRGlyZWN0IEFjY2VzcyBTQ1NJLTUgZGV2aWNlIApkYTA6IDMw MC4wMDBNQi9zIHRyYW5zZmVycywgVGFnZ2VkIFF1ZXVlaW5nIEVuYWJsZWQKZGEwOiA3MDAw Nk1CICgxNDMzNzQwMDAgNTEyIGJ5dGUgc2VjdG9yczogMjU1SCA2M1MvVCA4OTI0QykKU01Q OiBBUCBDUFUgIzEgTGF1bmNoZWQhClNNUDogQVAgQ1BVICMzIExhdW5jaGVkIQpTTVA6IEFQ IENQVSAjMiBMYXVuY2hlZCEKR0VPTV9MQUJFTDogTGFiZWwgZm9yIHByb3ZpZGVyIGRhMSBp cyB1ZnMvcXNlcnZpY2VzLgpHRU9NX0xBQkVMOiBMYWJlbCBmb3IgcHJvdmlkZXIgZGEwczFh IGlzIHVmcy9yb290LgpHRU9NX0xBQkVMOiBMYWJlbCBmb3IgcHJvdmlkZXIgZGEwczFiIGlz IGxhYmVsL3N3YXAuCkdFT01fTEFCRUw6IExhYmVsIGZvciBwcm92aWRlciBkYTBzMWQgaXMg dWZzL3Vzci4KR0VPTV9MQUJFTDogTGFiZWwgZm9yIHByb3ZpZGVyIGRhMHMxZSBpcyB1ZnMv dmFyLgpHRU9NX0xBQkVMOiBMYWJlbCBmb3IgcHJvdmlkZXIgZGEwczFmIGlzIHVmcy9ob21l LgpHRU9NX0xBQkVMOiBMYWJlbCBmb3IgcHJvdmlkZXIgZGEwczFnIGlzIHVmcy9zdG9yYWdl LgpUcnlpbmcgdG8gbW91bnQgcm9vdCBmcm9tIHVmczovZGV2L3Vmcy9yb290CmlzcDA6IGxp bmUgNTI3NDogbWFya3BvcnRkYgppc3AwOiBsaW5lIDUzNjM6IG1hcmtwb3J0ZGIKaXNwMDog U3RvcHBpbmcgTG9vcCBEb3duIFRpbWVyCmlzcDA6IGlzcF9rdGhyZWFkOiBjaGVja2luZyBG QyBzdGF0ZQppc3AwOiBGQyBMaW5rIFRlc3QgRW50cnkKaXNwMDogbGluZSAyNDUwOiBtYXJr cG9ydGRiCmlzcDA6IEZpcm13YXJlIFN0YXRlIDxDb25maWcgV2FpdC0+V2FpdCBMb2dpbj4K aXNwMDogaXNwX2ZjbGlua190ZXN0OiBub3QgYXQgRldfUkVBRFkgc3RhdGUKaXNwMDogaXNw X2ZjX3J1bnN0YXRlOiBsaW5rdGVzdCBmYWlsZWQKaXNwMDoga3RocmVhZDogRkMgbG9vcCBu b3QgdXAgKGRvd24gY291bnQgMzAyKQppc3AwOiBpc3Bfa3RocmVhZDogcmVsZWFzaW5nIHNp bXEKaXNwMDogaXNwX2t0aHJlYWQ6IHNsZWVwIHRpbWUgMAppc3AwOiBsaW5lIDUzMTA6IG1h cmtwb3J0ZGIKaXNwMDogbGluZSA1MzQ4OiBtYXJrcG9ydGRiCmlzcDA6IGlzcF9rdGhyZWFk OiBjaGVja2luZyBGQyBzdGF0ZQppc3AwOiBGQyBMaW5rIFRlc3QgRW50cnkKaXNwMDogbGlu ZSAyNDUwOiBtYXJrcG9ydGRiCmlzcDA6IEZpcm13YXJlIFN0YXRlIDxDb25maWcgV2FpdC0+ UmVhZHk+CmlzcDA6IFJlZ2lzdGVyIEZDNCBUeXBlIGFjY2VwdGVkCmlzcDA6IEhCQSBQb3J0 SUQgMHg4MTA1MDAgTi1Qb3J0IEhhbmRsZSAwLCBDb25uZWN0aW9uIFRvcG9sb2d5ICdGIFBv cnQnCmlzcDA6IEhCQSBXV05OIDB4MjAwMDAwZTA4YjlhNmQzOSBIQkEgV1dQTiAweDIxMDAw MGUwOGI5YTZkMzkKaXNwMDogRkMgTGluayBUZXN0IENvbXBsZXRlCmlzcDA6IEZDIFNjYW4g RmFicmljCmlzcDA6IGdvdCA5IHBvcnRzIGJhY2sgZnJvbSBuYW1lIHNlcnZlcgppc3AwOiBD aGVja2luZyBGYWJyaWMgUG9ydCAweDgxMDAwMAppc3AwOiBGYWJyaWMgUG9ydCAweDgxMDAw MCBpcyBOZXcgRW50cnkKaXNwMDogQ2hlY2tpbmcgRmFicmljIFBvcnQgMHg4MTAxMDAKaXNw MDogRmFicmljIFBvcnQgMHg4MTAxMDAgaXMgTmV3IEVudHJ5CmlzcDA6IENoZWNraW5nIEZh YnJpYyBQb3J0IDB4ODEwMjAwCmlzcDA6IEZhYnJpYyBQb3J0IDB4ODEwMjAwIGlzIE5ldyBF bnRyeQppc3AwOiBDaGVja2luZyBGYWJyaWMgUG9ydCAweDgxMDMwMAppc3AwOiBGYWJyaWMg UG9ydCAweDgxMDMwMCBpcyBOZXcgRW50cnkKaXNwMDogQ2hlY2tpbmcgRmFicmljIFBvcnQg MHg4MTA0MDAKaXNwMDogRmFicmljIFBvcnQgMHg4MTA0MDAgaXMgTmV3IEVudHJ5CmlzcDA6 IHNraXAgb3Vyc2VsdmVzIEAgUG9ydElEIDB4ODEwNTAwCmlzcDA6IENoZWNraW5nIEZhYnJp YyBQb3J0IDB4ODEwNjAwCmlzcDA6IEZhYnJpYyBQb3J0IDB4ODEwNjAwIGlzIE5ldyBFbnRy eQppc3AwOiBDaGVja2luZyBGYWJyaWMgUG9ydCAweDgxMDcwMAppc3AwOiBGYWJyaWMgUG9y dCAweDgxMDcwMCBpcyBOZXcgRW50cnkKaXNwMDogQ2hlY2tpbmcgRmFicmljIFBvcnQgMHg4 MTBmMDAKaXNwMDogRmFicmljIFBvcnQgMHg4MTBmMDAgaXMgTmV3IEVudHJ5CmlzcDA6IEZD IFNjYW4gRmFicmljIERvbmUKaXNwMDogU3luY2hyb25pemluZyBQREJzCmlzcDA6IFBvcnRJ RCAweDgxMDAwMCBoYW5kbGUgMHgxIHJvbGUgVGFyZ2V0IGFycml2ZWQgYXQgdGd0IDAKICAg ICAgV1dOTiAweDIwMDQwMGEwYjgyMTUxOTMgV1dQTiAweDIwMDQwMGEwYjgyMTUxOTQKaXNw MDogUG9ydElEIDB4ODEwMTAwIGhhbmRsZSAweDIgcm9sZSBJbml0aWF0b3IgYXJyaXZlZAog ICAgICBXV05OIDB4MjAwMDAwZTA4Yjg1MDc3MCBXV1BOIDB4MjEwMDAwZTA4Yjg1MDc3MApp c3AwOiBQb3J0SUQgMHg4MTAyMDAgaGFuZGxlIDB4MyByb2xlIEluaXRpYXRvciBhcnJpdmVk CiAgICAgIFdXTk4gMHgyMDAwMDBlMDhiODU2ODcxIFdXUE4gMHgyMTAwMDBlMDhiODU2ODcx CmlzcDA6IFBvcnRJRCAweDgxMDMwMCBoYW5kbGUgMHg0IHJvbGUgSW5pdGlhdG9yIGFycml2 ZWQKICAgICAgV1dOTiAweDIwMDAwMGUwOGI4NWRiNmUgV1dQTiAweDIxMDAwMGUwOGI4NWRi NmUKaXNwMDogUG9ydElEIDB4ODEwNDAwIGhhbmRsZSAweDUgcm9sZSBJbml0aWF0b3IgYXJy aXZlZAogICAgICBXV05OIDB4MjAwMDAwZTA4YjhiNjc2NCBXV1BOIDB4MjEwMDAwZTA4Yjhi Njc2NAppc3AwOiBQb3J0SUQgMHg4MTA2MDAgaGFuZGxlIDB4NiByb2xlIEluaXRpYXRvciBh cnJpdmVkCiAgICAgIFdXTk4gMHgyMDAwMDBlMDhiOWFhNTNhIFdXUE4gMHgyMTAwMDBlMDhi OWFhNTNhCmlzcDA6IFBvcnRJRCAweDgxMDcwMCBoYW5kbGUgMHg3IHJvbGUgSW5pdGlhdG9y IGFycml2ZWQKICAgICAgV1dOTiAweDIwMDAwMGUwOGI4NTNlNmYgV1dQTiAweDIxMDAwMGUw OGI4NTNlNmYKaXNwMDogUG9ydElEIDB4ODEwZjAwIGhhbmRsZSAweDggcm9sZSBUYXJnZXQg YXJyaXZlZCBhdCB0Z3QgMQogICAgICBXV05OIDB4MjAwNDAwYTBiODIxNTE5MyBXV1BOIDB4 MjAwNTAwYTBiODIxNTE5NQppc3AwOiBQb3J0SUQgMHhmZmZmZmUgaGFuZGxlIDB4N2ZlIHJv bGUgKG5vbmUpIHN0YXllZAogICAgICBXV05OIDB4MTAwMDAwMDUxZTM1ZWNjOCBXV1BOIDB4 MjAwNTAwMDUxZTM1ZWNjOAppc3AwOiBpc3Bfa3RocmVhZDogRkMgc3RhdGUgT0sKaXNwMDog aXNwX2t0aHJlYWQ6IHJlbGVhc2luZyBzaW1xCmlzcDA6IGlzcF9rdGhyZWFkOiBzbGVlcCB0 aW1lIDAKZGEzIGF0IGlzcDAgYnVzIDAgdGFyZ2V0IDAgbHVuIDAKZGEzOiA8SUJNIDE3MjQt MTAwICBGQVN0VCAwNTQyPiBGaXhlZCBEaXJlY3QgQWNjZXNzIFNDU0ktMyBkZXZpY2UgCmRh MzogMTAwLjAwME1CL3MgdHJhbnNmZXJzLCBUYWdnZWQgUXVldWVpbmcgRW5hYmxlZApkYTM6 IDIwNDgwTUIgKDQxOTQzMDQwIDUxMiBieXRlIHNlY3RvcnM6IDI1NUggNjNTL1QgMjYxMEMp CmRhNCBhdCBpc3AwIGJ1cyAwIHRhcmdldCAxIGx1biAwCmRhNDogPElCTSAxNzI0LTEwMCAg RkFTdFQgMDU0Mj4gRml4ZWQgRGlyZWN0IEFjY2VzcyBTQ1NJLTMgZGV2aWNlIApkYTQ6IDEw MC4wMDBNQi9zIHRyYW5zZmVycywgVGFnZ2VkIFF1ZXVlaW5nIEVuYWJsZWQKZGE0OiAyMDQ4 ME1CICg0MTk0MzA0MCA1MTIgYnl0ZSBzZWN0b3JzOiAyNTVIIDYzUy9UIDI2MTBDKQppc3Aw OiBsaW5lIDUzNDg6IG1hcmtwb3J0ZGIKaXNwMDogbGluZSA1MzQ4OiBtYXJrcG9ydGRiCmlz cDA6IGlzcF9rdGhyZWFkOiBjaGVja2luZyBGQyBzdGF0ZQppc3AwOiBGQyBTY2FuIEZhYnJp Ywppc3AwOiBnb3QgOSBwb3J0cyBiYWNrIGZyb20gbmFtZSBzZXJ2ZXIKaXNwMDogQ2hlY2tp bmcgRmFicmljIFBvcnQgMHg4MTAwMDAKaXNwMDogRmFicmljIFBvcnQgMHg4MTAwMDAgTm93 IFBlbmRpbmcgVmFsaWQKaXNwMDogQ2hlY2tpbmcgRmFicmljIFBvcnQgMHg4MTAxMDAKaXNw MDogRmFicmljIFBvcnQgMHg4MTAxMDAgTm93IFBlbmRpbmcgVmFsaWQKaXNwMDogQ2hlY2tp bmcgRmFicmljIFBvcnQgMHg4MTAyMDAKaXNwMDogRmFicmljIFBvcnQgMHg4MTAyMDAgTm93 IFBlbmRpbmcgVmFsaWQKaXNwMDogQ2hlY2tpbmcgRmFicmljIFBvcnQgMHg4MTAzMDAKaXNw MDogRmFicmljIFBvcnQgMHg4MTAzMDAgTm93IFBlbmRpbmcgVmFsaWQKaXNwMDogQ2hlY2tp bmcgRmFicmljIFBvcnQgMHg4MTA0MDAKaXNwMDogRmFicmljIFBvcnQgMHg4MTA0MDAgTm93 IFBlbmRpbmcgVmFsaWQKaXNwMDogc2tpcCBvdXJzZWx2ZXMgQCBQb3J0SUQgMHg4MTA1MDAK aXNwMDogQ2hlY2tpbmcgRmFicmljIFBvcnQgMHg4MTA2MDAKaXNwMDogRmFicmljIFBvcnQg MHg4MTA2MDAgTm93IFBlbmRpbmcgVmFsaWQKaXNwMDogQ2hlY2tpbmcgRmFicmljIFBvcnQg MHg4MTA3MDAKaXNwMDogRmFicmljIFBvcnQgMHg4MTA3MDAgTm93IFBlbmRpbmcgVmFsaWQK aXNwMDogQ2hlY2tpbmcgRmFicmljIFBvcnQgMHg4MTBmMDAKaXNwMDogRmFicmljIFBvcnQg MHg4MTBmMDAgTm93IFBlbmRpbmcgVmFsaWQKaXNwMDogRkMgU2NhbiBGYWJyaWMgRG9uZQpp c3AwOiBTeW5jaHJvbml6aW5nIFBEQnMKaXNwMDogUG9ydElEIDB4ODEwMDAwIGhhbmRsZSAw eDEgcm9sZSBUYXJnZXQgc3RheWVkIGF0IHRndCAwCiAgICAgIFdXTk4gMHgyMDA0MDBhMGI4 MjE1MTkzIFdXUE4gMHgyMDA0MDBhMGI4MjE1MTk0CmlzcDA6IFBvcnRJRCAweDgxMDEwMCBo YW5kbGUgMHgyIHJvbGUgSW5pdGlhdG9yIHN0YXllZAogICAgICBXV05OIDB4MjAwMDAwZTA4 Yjg1MDc3MCBXV1BOIDB4MjEwMDAwZTA4Yjg1MDc3MAppc3AwOiBQb3J0SUQgMHg4MTAyMDAg aGFuZGxlIDB4MyByb2xlIEluaXRpYXRvciBzdGF5ZWQKICAgICAgV1dOTiAweDIwMDAwMGUw OGI4NTY4NzEgV1dQTiAweDIxMDAwMGUwOGI4NTY4NzEKaXNwMDogUG9ydElEIDB4ODEwMzAw IGhhbmRsZSAweDQgcm9sZSBJbml0aWF0b3Igc3RheWVkCiAgICAgIFdXTk4gMHgyMDAwMDBl MDhiODVkYjZlIFdXUE4gMHgyMTAwMDBlMDhiODVkYjZlCmlzcDA6IFBvcnRJRCAweDgxMDQw MCBoYW5kbGUgMHg1IHJvbGUgSW5pdGlhdG9yIHN0YXllZAogICAgICBXV05OIDB4MjAwMDAw ZTA4YjhiNjc2NCBXV1BOIDB4MjEwMDAwZTA4YjhiNjc2NAppc3AwOiBQb3J0SUQgMHg4MTA2 MDAgaGFuZGxlIDB4NiByb2xlIEluaXRpYXRvciBzdGF5ZWQKICAgICAgV1dOTiAweDIwMDAw MGUwOGI5YWE1M2EgV1dQTiAweDIxMDAwMGUwOGI5YWE1M2EKaXNwMDogUG9ydElEIDB4ODEw NzAwIGhhbmRsZSAweDcgcm9sZSBJbml0aWF0b3Igc3RheWVkCiAgICAgIFdXTk4gMHgyMDAw MDBlMDhiODUzZTZmIFdXUE4gMHgyMTAwMDBlMDhiODUzZTZmCmlzcDA6IFBvcnRJRCAweDgx MGYwMCBoYW5kbGUgMHg4IHJvbGUgVGFyZ2V0IHN0YXllZCBhdCB0Z3QgMQogICAgICBXV05O IDB4MjAwNDAwYTBiODIxNTE5MyBXV1BOIDB4MjAwNTAwYTBiODIxNTE5NQppc3AwOiBQb3J0 SUQgMHhmZmZmZmUgaGFuZGxlIDB4N2ZlIHJvbGUgKG5vbmUpIHN0YXllZAogICAgICBXV05O IDB4MTAwMDAwMDUxZTM1ZWNjOCBXV1BOIDB4MjAwNTAwMDUxZTM1ZWNjOAppc3AwOiBpc3Bf a3RocmVhZDogRkMgc3RhdGUgT0sKaXNwMDogaXNwX2t0aHJlYWQ6IHJlbGVhc2luZyBzaW1x CmlzcDA6IGlzcF9rdGhyZWFkOiBzbGVlcCB0aW1lIDAK --------------000009040606010703070803-- From owner-freebsd-current@FreeBSD.ORG Mon Mar 12 14:16:45 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2035616A400; Mon, 12 Mar 2007 14:16:45 +0000 (UTC) (envelope-from kensmith@cse.Buffalo.EDU) Received: from opus.cse.buffalo.edu (opus.cse.Buffalo.EDU [128.205.32.4]) by mx1.freebsd.org (Postfix) with ESMTP id D765113C48C; Mon, 12 Mar 2007 14:16:44 +0000 (UTC) (envelope-from kensmith@cse.Buffalo.EDU) Received: from [127.0.0.1] (localhost.cse.buffalo.edu [127.0.0.1]) by opus.cse.buffalo.edu (8.13.8/8.12.4) with ESMTP id l2CEGiP9076174; Mon, 12 Mar 2007 10:16:44 -0400 (EDT) From: Ken Smith To: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-xsRQdbbs8pGNqdTMHc7K" Organization: U. Buffalo CSE Department Date: Mon, 12 Mar 2007 10:16:44 -0400 Message-Id: <1173709004.75556.8.camel@opus.cse.buffalo.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 FreeBSD GNOME Team Port Cc: Subject: March 2007 Monthly Snapshots... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Mar 2007 14:16:45 -0000 --=-xsRQdbbs8pGNqdTMHc7K Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Just a note to say the March 2007 Monthly Snapshots for HEAD and RELENG_6 are done and available at: ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/200703/ Checksums: MD5 (6.2-STABLE-200703-amd64-bootonly.iso) =3D 1c69b9a4026f2ab4f4a502faaa71= 22e2 MD5 (6.2-STABLE-200703-amd64-disc1.iso) =3D 1194716a684f2274e6d8064dbd3d2f0= d MD5 (6.2-STABLE-200703-amd64-disc2.iso) =3D 30168fd35e4fbb09a37071caa2521ff= 1 MD5 (6.2-STABLE-200703-amd64-docs.iso) =3D 518187c17d030f617cd5ed9926795e69 MD5 (6.2-STABLE-200703-i386-bootonly.iso) =3D 3d9519c07bf3598192307b6c30851= b74 MD5 (6.2-STABLE-200703-i386-disc1.iso) =3D 17894b0304a95789c792153c80a4c7ee MD5 (6.2-STABLE-200703-i386-disc2.iso) =3D 153c683ccd1c1139f8f73608e1a08fac MD5 (6.2-STABLE-200703-i386-docs.iso) =3D 6a401b8d615314db450873a1f46228cf MD5 (6.2-STABLE-200703-ia64-bootonly.iso) =3D 249df8d773cb6bb07d5bc2410e0a2= a36 MD5 (6.2-STABLE-200703-ia64-disc1.iso) =3D 4e36e46f32573d3f60fb5103ce6a1afc MD5 (6.2-STABLE-200703-ia64-docs.iso) =3D fd5cd75e0f9c4f6d974e7f51819d214d MD5 (6.2-STABLE-200703-ia64-livefs.iso) =3D d848a4eb908a41616bb3bc2a696406b= 5 MD5 (6.2-STABLE-200703-pc98-bootonly.iso) =3D cf6ec622ecbb36eba1e8d4b5bca41= 96c MD5 (6.2-STABLE-200703-pc98-disc1.iso) =3D 7012da8c292f3563dd2c5bc12e258f97 MD5 (6.2-STABLE-200703-powerpc-bootonly.iso) =3D 65af6cb49adfe032b5aaba0437= 853c29 MD5 (6.2-STABLE-200703-powerpc-disc1.iso) =3D 2a4407c39770d6fa7b6439218e513= 8b1 MD5 (6.2-STABLE-200703-powerpc-docs.iso) =3D 8a6fec16efd21d07c66b16073233e9= 70 MD5 (6.2-STABLE-200703-sparc64-bootonly.iso) =3D 26a6c0dd209befa81ff096aecd= d25153 MD5 (6.2-STABLE-200703-sparc64-disc1.iso) =3D 85f556f7f3ba0f259a39885443acd= 229 MD5 (6.2-STABLE-200703-sparc64-disc2.iso) =3D 51aed5cca20ccf4764a9dbd9cf1d9= 3ce MD5 (6.2-STABLE-200703-sparc64-docs.iso) =3D 8d95d035291884cbeaafcbbec71116= 1b MD5 (7.0-CURRENT-200703-amd64-bootonly.iso) =3D 522c1954d8f86fb5b74ea486cc8= 9711a MD5 (7.0-CURRENT-200703-amd64-disc1.iso) =3D 963aa62d61c3b565f8c40eb3cf18f1= 69 MD5 (7.0-CURRENT-200703-amd64-disc2.iso) =3D 48be7eeed8d40ae56b2db80a00f9f2= 02 MD5 (7.0-CURRENT-200703-amd64-docs.iso) =3D 183b4499ef36b6d65094aec41109c33= 8 MD5 (7.0-CURRENT-200703-i386-bootonly.iso) =3D 64669179db79d624bad8a895762a= 0541 MD5 (7.0-CURRENT-200703-i386-disc1.iso) =3D 01ac1445871e7b73dd43769df6a82ca= 9 MD5 (7.0-CURRENT-200703-i386-disc2.iso) =3D 26e13d92d4f99cbbae99785c6a77079= 1 MD5 (7.0-CURRENT-200703-i386-docs.iso) =3D 0a4cf465344788a4368ab428a75c80c5 MD5 (7.0-CURRENT-200703-ia64-bootonly.iso) =3D feeeb62ec4ba6d5607dfa78e5aeb= c791 MD5 (7.0-CURRENT-200703-ia64-disc1.iso) =3D 645887a09ee80e6044e7d356a68df9e= 4 MD5 (7.0-CURRENT-200703-ia64-docs.iso) =3D 0c2b784c98415fcbf814c2f2f3cb79b8 MD5 (7.0-CURRENT-200703-ia64-livefs.iso) =3D 052cf82f29255cb44987e61cf9fb7f= c1 MD5 (7.0-CURRENT-200703-pc98-bootonly.iso) =3D 87425dbc311bddd354dc15151662= 25e5 MD5 (7.0-CURRENT-200703-pc98-disc1.iso) =3D a026f2a9ff3c4754ffb0c2854be6c5d= 4 MD5 (7.0-CURRENT-200703-powerpc-bootonly.iso) =3D 120e6e4b7b8a7c1398ec9cecb= 988381b MD5 (7.0-CURRENT-200703-powerpc-disc1.iso) =3D 84fae671b371f9a3f8d79a8107a3= bed4 MD5 (7.0-CURRENT-200703-powerpc-docs.iso) =3D b8aec4061f754fb148053879a6b7b= 9f7 MD5 (7.0-CURRENT-200703-sparc64-bootonly.iso) =3D aa588fc6f2be82809c6fe85e3= 96ecc7d MD5 (7.0-CURRENT-200703-sparc64-disc1.iso) =3D f028f919fe4a00e2f8b7f9f0f2d1= 9c6d MD5 (7.0-CURRENT-200703-sparc64-disc2.iso) =3D 793cae7698066faf165051dfe7ad= 90c3 MD5 (7.0-CURRENT-200703-sparc64-docs.iso) =3D 9eb0a17786b32ee2854ae17547a54= c48 SHA256 (6.2-STABLE-200703-amd64-bootonly.iso) =3D 77421756b3c18dba29dc0b513= 72a9b097385323fb468fd300f4a783d57a6da60 SHA256 (6.2-STABLE-200703-amd64-disc1.iso) =3D 242857504bdb4264d075eb56dacb= 7a6c0e63c4952579e836223baf9d3becffd0 SHA256 (6.2-STABLE-200703-amd64-disc2.iso) =3D 1e319b38596566406ec32d2bdd44= 765179910b0fafda35330eaff3100c998865 SHA256 (6.2-STABLE-200703-amd64-docs.iso) =3D 08191cec4377d4c2a27327d1530da= 2376f7ab564d188b0a2e0559c76aeee2713 SHA256 (6.2-STABLE-200703-i386-bootonly.iso) =3D 564c1589636e2936ff37441ae8= 1f936e0a881a552f32ad8e548053871f8bd2c9 SHA256 (6.2-STABLE-200703-i386-disc1.iso) =3D d1d440d4cc42fdd14ac0c484ea8b0= 4fb86f5e19badf4b8322e265d6a0a8bb3d3 SHA256 (6.2-STABLE-200703-i386-disc2.iso) =3D 9540a5dc821ff92e47762b30b5899= e05ecbc13ce7c80b3f75ae5c592f079066a SHA256 (6.2-STABLE-200703-i386-docs.iso) =3D 251f2882ae368aae3368cf56d3f154= cc7962c54be59cbea1dd5ce42422adde1b SHA256 (6.2-STABLE-200703-ia64-bootonly.iso) =3D 005d3e2cfa201fdbf9eb031d82= aa69a4b8f143ac2f689e2dfef2849843245bcd SHA256 (6.2-STABLE-200703-ia64-disc1.iso) =3D da3718cbe0935015f5cb793716da9= f7be9d82c5ba69c5fba922ca16d3d346788 SHA256 (6.2-STABLE-200703-ia64-docs.iso) =3D d1ced06c63571f5b902cee3fcf6032= 1c5fe1eb46b40d064ed5c5f0f8cb8238c6 SHA256 (6.2-STABLE-200703-ia64-livefs.iso) =3D c4461a83dd916bf712a50c1f94e1= 4243a3027b6fee03ed2ba87f91076e06b33b SHA256 (6.2-STABLE-200703-pc98-bootonly.iso) =3D 8a09598e6676e6ffaedbaa79f2= bf9cfcfd49c07285216418e72c65c347c6158d SHA256 (6.2-STABLE-200703-pc98-disc1.iso) =3D 4f413978e8156c5238bf3dda6c40c= 4c1a173358697ceae8bd19ce221ef064046 SHA256 (6.2-STABLE-200703-powerpc-bootonly.iso) =3D 357cff39c46dd60084268d8= c9f6877e14ab3efddd0c03886b801bee9a7f0eb90 SHA256 (6.2-STABLE-200703-powerpc-disc1.iso) =3D 18bc78071f5daeb728b0f4c3cd= a9e464fc24134645ffe0749175de264afad75f SHA256 (6.2-STABLE-200703-powerpc-docs.iso) =3D 7345db1b15bde9b3fea84181dd4= 8bb01c289a3da08472b351205169b27c6c5c4 SHA256 (6.2-STABLE-200703-sparc64-bootonly.iso) =3D 56554b8fa01ce392df9a9be= d13712f2f6b5698e02d8807a595a6359770e0f421 SHA256 (6.2-STABLE-200703-sparc64-disc1.iso) =3D 4726899907d9a210479719557d= b673ac9ba73e95c5e942b6a8b9705c2ef86c7d SHA256 (6.2-STABLE-200703-sparc64-disc2.iso) =3D bb5db361a444a483c8e01691d5= e966583502ec7f5c7dd2363756564cab5cc10d SHA256 (6.2-STABLE-200703-sparc64-docs.iso) =3D 188c000b1b53f19ae0949923315= 0eab240211ac8675d4746b88aff4103ea383e SHA256 (7.0-CURRENT-200703-amd64-bootonly.iso) =3D caf39e84378e20b322caeaaf= 95a09dc5c11c4b7f9f3f25edf584ef7806448d5f SHA256 (7.0-CURRENT-200703-amd64-disc1.iso) =3D 0fc7aa97035047d21675a0ea8ed= 271b3fc042785df1a530d85ba6378151c4a7e SHA256 (7.0-CURRENT-200703-amd64-disc2.iso) =3D 5b8002be7fff5e1802bb6e0b387= bbda6e8528b4b52f2818ba61ec868ed8922fc SHA256 (7.0-CURRENT-200703-amd64-docs.iso) =3D 86b5d7a45bd7a84383ec1bbd09e9= acbca10aeb6e5d4e5865aff04f3727d96e2e SHA256 (7.0-CURRENT-200703-i386-bootonly.iso) =3D 7d0549fbfc5944ad12b08446c= 687d291c6ce48c8b68943c841e0f6f526e3b4a7 SHA256 (7.0-CURRENT-200703-i386-disc1.iso) =3D d4858a58fb4422bbc00ebc981d6a= d00d03958d8fa9cc6a34867d1967b90288cb SHA256 (7.0-CURRENT-200703-i386-disc2.iso) =3D afc962f645a97c6e7ad104879d74= 9da3af7323945471745a64b1da5c5e371391 SHA256 (7.0-CURRENT-200703-i386-docs.iso) =3D f87d85ce1946372e59d0d9287326b= 1ddcde7bdcf1e20402d4c76d54d23efd76b SHA256 (7.0-CURRENT-200703-ia64-bootonly.iso) =3D 94fe93b90d28497ad3764c243= 6d663fd7381fbdc74c2ba9acf02bf74ddecce56 SHA256 (7.0-CURRENT-200703-ia64-disc1.iso) =3D 319798af460bfc90a3d46f832321= 45a3a5272d5adfba80f6201b666c6418ca8d SHA256 (7.0-CURRENT-200703-ia64-docs.iso) =3D 5a6b6139b0f44d443a80b13e31ddd= 4c96119c91ef238a9c692af540f4004f347 SHA256 (7.0-CURRENT-200703-ia64-livefs.iso) =3D fcc4978bca066721285285ecbbe= 8ed80fafb2ce0b125e0fb0f6ffa743e0564d2 SHA256 (7.0-CURRENT-200703-pc98-bootonly.iso) =3D ba19fa3f2a32611955a7db3ea= 14301b6ebe3c9cf8c0cbe516c8bc67c26e4e104 SHA256 (7.0-CURRENT-200703-pc98-disc1.iso) =3D 289874a4c120eb263850c01b2d4a= 0c7c4ea0519c53d6ba7bc8b635aa9ea23b0a SHA256 (7.0-CURRENT-200703-powerpc-bootonly.iso) =3D 3e3c43ff8d7771cb7add9f= 7b5e75b36bb7b31bc80d35bd62659bfc8aa4bfe8e0 SHA256 (7.0-CURRENT-200703-powerpc-disc1.iso) =3D 2200d4be005db2f734af4044a= 2430e26f0f8816a10693d01531928ce18707642 SHA256 (7.0-CURRENT-200703-powerpc-docs.iso) =3D 28e6e38d759f8454f550a1e895= fd6c096b19b4782c15e568a880a1a75465eb7c SHA256 (7.0-CURRENT-200703-sparc64-bootonly.iso) =3D 53641b52c1e18f756c290b= 9c86091635103742b8380736ee7f566a9f937704bd SHA256 (7.0-CURRENT-200703-sparc64-disc1.iso) =3D 22cf09cadf2e4c915f2411138= d7f4054c73b9997fa9399416993e65207d33bcf SHA256 (7.0-CURRENT-200703-sparc64-disc2.iso) =3D 500a2b9daf0cfbe087b3969b3= bb41511b1e3113dd83bd4ab9cb90b46619fdbb4 SHA256 (7.0-CURRENT-200703-sparc64-docs.iso) =3D eda809ff2a897dab987b36377f= 4e0e5735dac96edbb2962c40af7223107d634c --=20 Ken Smith - From there to here, from here to | kensmith@cse.buffalo.edu there, funny things are everywhere. | - Theodore Geisel | --=-xsRQdbbs8pGNqdTMHc7K 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) iD8DBQBF9WDM/G14VSmup/YRAhDFAJoDGkGXnJi4YIFYOYpTmd0yNNhDvQCeNkkq EwZ8VvVxdWgx7ur4VSTjZBk= =wV9G -----END PGP SIGNATURE----- --=-xsRQdbbs8pGNqdTMHc7K-- From owner-freebsd-current@FreeBSD.ORG Mon Mar 12 18:18:12 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 40ECE16A400 for ; Mon, 12 Mar 2007 18:18:12 +0000 (UTC) (envelope-from lydianconcepts@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.247]) by mx1.freebsd.org (Postfix) with ESMTP id ADB7313C480 for ; Mon, 12 Mar 2007 18:18:11 +0000 (UTC) (envelope-from lydianconcepts@gmail.com) Received: by an-out-0708.google.com with SMTP id c24so1401355ana for ; Mon, 12 Mar 2007 11:18:11 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=QwiCZiJhczTFHMj8n4+qBVMf0h2iwxeLJ3Ms5IUZ0xYZBetSmcQvs1ydJXT6TSFb2O8GfHIh+GExevuXGR2p668PVQiGH/X6rnXBtn5OT3rgiNCUBywQ7kH8p2+Six6sCiM+E7k3uAeFBK+wusmoVyUIvjZf24u2AAxIOJ1s+QA= 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=t6oxLbuVgPwLEfIbmGERqg7CBNASgJuWOJY39VJoAhw8G4sQqy7VHX0ANZy+vi77aZ9kDSJGnFoNpP+fpX5NEQy9BwOo7rc0CJcbdU6do3xBykciPlReRG0GygsvVD82Qg+RIbhm78QwUXHxhrIu96BFD+R9i7ExJRk8+ombqOg= Received: by 10.114.112.1 with SMTP id k1mr1883423wac.1173720091963; Mon, 12 Mar 2007 10:21:31 -0700 (PDT) Received: by 10.114.24.2 with HTTP; Mon, 12 Mar 2007 10:21:31 -0700 (PDT) Message-ID: <7579f7fb0703121021r66aa163bnd1dae6705cd0646a@mail.gmail.com> Date: Mon, 12 Mar 2007 10:21:31 -0700 From: "Matthew Jacob" To: "Ivan Voras" In-Reply-To: <45F5494B.9040104@fer.hr> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <70e8236f0703091413o473db67fr451e3be49c44b025@mail.gmail.com> <20070309142918.V61513@ns1.feral.com> <45F1E27A.7090302@fer.hr> <20070309150157.L61706@ns1.feral.com> <45F1EB35.6020303@fer.hr> <20070309151901.L61859@ns1.feral.com> <45F1F08E.5030902@fer.hr> <20070309173523.P62771@ns1.feral.com> <45F5494B.9040104@fer.hr> Cc: freebsd-current@freebsd.org, mjacob@freebsd.org Subject: Re: MFC request: QLogic 24xx FibreChannel controller X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Mar 2007 18:18:12 -0000 Thanks. Jeez- they all get reported out via the fabric as separate devices. I have no idea what the internals of them are that cause such paths to be unconscious active/active. This is exactly the reason, btw, whey I *didn't* wire WWPN or Serial number knowledge into the geom_multipath module (to be MFC's sometime soon) as a requirement. Only the owner of the underlying storage in this case is going to be able figure out that these are two paths to the same storage. From owner-freebsd-current@FreeBSD.ORG Mon Mar 12 21:41:48 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5471316A410 for ; Mon, 12 Mar 2007 21:41:48 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Received: from tmailer.gwdg.de (tmailer.gwdg.de [134.76.10.23]) by mx1.freebsd.org (Postfix) with ESMTP id DF70413C4BA for ; Mon, 12 Mar 2007 21:41:47 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Received: from [87.139.104.184] (helo=[192.168.2.20]) by mailer.gwdg.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1HQsH3-00005s-2z; Mon, 12 Mar 2007 22:41:45 +0100 Message-ID: <45F5C914.3000805@gwdg.de> Date: Mon, 12 Mar 2007 22:41:40 +0100 From: Rainer Hurling User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: pyunyh@gmail.com References: <20070310074734.GC70613@cdnetworks.co.kr> <917080.87242.qm@web34701.mail.mud.yahoo.com> <20070311050627.GC79728@cdnetworks.co.kr> <45F3B94B.3030104@gwdg.de> <20070312045116.GA83433@cdnetworks.co.kr> In-Reply-To: <20070312045116.GA83433@cdnetworks.co.kr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated: Id:rhurlin X-Spam-Level: - X-Virus-Scanned: (clean) by exiscan+sophie Cc: darren780@yahoo.com, freebsd-current@freebsd.org Subject: Re: yongari nfe 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, 12 Mar 2007 21:41:48 -0000 Pyun YongHyeon, thank you for reply. Sorry for the late answer, but I have been on business trip. Pyun YongHyeon schrieb: > On Sun, Mar 11, 2007 at 09:09:47AM +0100, Rainer Hurling wrote: > > Pyun YongHyeon schrieb: > > >[... SNIP ...] > > > > > >Did stock nfe(4) work on MCP55? > > >(I'm not interested in how nve(4) works on MCP55.) > > >I'm afraid MCP55 requires different programming. Searching archives > > >for Linux forcedeth driver also reveals issues on MCP55 which is > > >exactly the same issue I think. > > >I'll let you know if I find a clue but it's hard to fix due to lack > > >of MCP55 hardware and documentation. > > > > > > Yes, nfe(4) works on MCP55, but with some strange behaviour, see below. > > > > I am working with FreeBSD 7.0-CURRENT from 03/07/2007 on MSI K9N Neo. > > 'dmesg | grep nfe' gives me: > > > > nfe0: port 0xb000-0xb007 mem > > 0xfbef7000-0xfbef7fff,0xfbefa800-0xfbefa8ff,0xfbefa400-0xfbefa40f irq 21 > > at device 8.0 on pci0 > > miibus0: on nfe0 > > ukphy0: PHY 1 on miibus0 > > ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, > > 1000baseT-FDX, auto > > nfe0: using obsoleted if_watchdog interface > > nfe0: Ethernet address: xx:xx:xx:xx:xx:xx > > nfe0: [ITHREAD] > > > > It seems that there is a problem with watchdog. Perhaps the choosen > > media interface ukphy0 is not correct? > > > > Normally nVidia GigEs use Marvell PHY which is served by e1000phy(4) > so I guess power saving mode had ukphy attach the PHY. > Booting/loading module with bootverbose mode will show up OUI/model/rev > of the PHY. Please let me know the OUI/model/rev output of ukphy(4). for ukphy0 bootverbose gives me : OUI 0x0001c1 model 0x0002 rev. 0 > > In the context with watchdog I observe an interesting behaviour of nfe0: > > After running WindowsXP on my board, I am not able to use the interface > > any more. Booting FreeBSD always gives me messages like this: > > > > ----- > > nfe0: link state changed to DOWN > > /etc/rc.d/dhclient: WARNING: $background_dhclient_nfe0 is not set > > properly - > > see > > rc.conf(5). > > nfe0: no link ....nfe0: link state changed to UP > > got link > > DHCPREQUEST on nfe0 to 255.255.255.255 port 67 > > nfe0: watchdog timeout > > nfe0: link state changed to DOWN > > nfe0: link state changed to UP > > DHCPREQUEST on nfe0 to 255.255.255.255 port 67 > > nfe0: watchdog timeout > > nfe0: link state changed to DOWN > > nfe0: link state changed to UP > > DHCPDISCOVER on nfe0 to 255.255.255.255 port 67 interval 5 > > nfe0: watchdog timeout > > nfe0: link state changed to DOWN > > DHCPDISCOVER on nfe0 to 255.255.255.255 port 67 interval 9 > > nfe0: link state changed to UP > > nfe0: watchdog timeout > > nfe0: link state changed to DOWN > > nfe0: link state changed to UP > > DHCPDISCOVER on nfe0 to 255.255.255.255 port 67 interval 14 > > nfe0: watchdog timeout > > nfe0: link state changed to DOWN > > nfe0: link state changed to UP > > DHCPDISCOVER on nfe0 to 255.255.255.255 port 67 interval 18 > > nfe0: watchdog timeout > > nfe0: link state changed to DOWN > > nfe0: link state changed to UP > > DHCPDISCOVER on nfe0 to 255.255.255.255 port 67 interval 9 > > nfe0: watchdog timeout > > nfe0: link state changed to DOWN > > nfe0: link state changed to UP > > DHCPDISCOVER on nfe0 to 255.255.255.255 port 67 interval 6 > > nfe0: watchdog timeout > > nfe0: link state changed to DOWN > > No DHCPOFFERS received. > > Trying recorded lease xxx.xxx.xxx.xxx > > nfe0: link state changed to UP > > bound: renewal in 429590 seconds. > > lo0: flags=8049 metric 0 mtu 16384 > > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 > > inet6 ::1 prefixlen 128 > > inet 127.0.0.1 netmask 0xff000000 > > nfe0: flags=8843 metric 0 mtu 1500 > > options=2b > > ether xx:xx:xx:xx:xx:xx > > media: Ethernet autoselect (100baseTX ) > > status: active > > ----- > > > > When booting 'cold' (means full power down) FreeBSD is able to use > > nfe(4) in the correct way. Also booting FreeBSD again after running > > FreeBSD gives me no errors. Obviously WindowsXP does not clear up all > > registers in MCP55 after leaving? > > > > I think Windows put the NIC/PHY in sleep/power saving mode and nfe(4) > will need a way to take PHY/NIC out of power down mode. > Try a WIP version at the following URL. > > http://people.freebsd.org/~yongari/nfe/WIP/if_nfe.c > http://people.freebsd.org/~yongari/nfe/WIP/if_nfereg.h > http://people.freebsd.org/~yongari/nfe/WIP/if_nfevar.h > > Note, it's just guess work from the Linux driver and I just tested > compilation. Due to lack of time/MCP55 hardware it's not easy for me > to fix. I tried your fixes. Bingo, you are right! Now I am able to use nfe(4) directly (without coldstart) after leaving from WindowsXP. Thank you very much, Rainer Hurling From owner-freebsd-current@FreeBSD.ORG Tue Mar 13 00:43:49 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7E4A416A418 for ; Tue, 13 Mar 2007 00:43:49 +0000 (UTC) (envelope-from pyunyh@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 9B6C313C469 for ; Tue, 13 Mar 2007 00:43:48 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by an-out-0708.google.com with SMTP id c24so1527448ana for ; Mon, 12 Mar 2007 17:43:48 -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=UBZx/xkFfkw8UCOJapJrPyc1sq8+2trH6KiXkOAq8LWZZiGuPyMK+/0YNMoILiuHXQX7DfLZ8zmejA+bniF9QJ6EzxJNhRPV7et1I/QsFmgVa7EGhPS159NUKtxNzaatYFqp6abqGi18w6zwx3OBW34n8sOBLQqaAZiJcs7ewjQ= 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=p4uE5CV+wmQQY7RfY0ksNUpiyJepaftL0MaKL6y6nmyOnir44Ck66uBc2/xWsJ85gZwtxEcNXwm+CkMLceaAHqq3AWLYG/Bir0JtPutzgJgLKDZr36XlSMufaGDy3UnvieCdXWW77aYLnouIKn5xflssdULWvffo8MKoBZV1KpY= Received: by 10.115.77.1 with SMTP id e1mr2150327wal.1173746627395; Mon, 12 Mar 2007 17:43:47 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTP id m26sm18145959pof.2007.03.12.17.43.45; Mon, 12 Mar 2007 17:43:46 -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 l2D0k2gk088542 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Mar 2007 09:46:02 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id l2D0k1NP088541; Tue, 13 Mar 2007 09:46:01 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Tue, 13 Mar 2007 09:46:01 +0900 From: Pyun YongHyeon To: Rainer Hurling Message-ID: <20070313004601.GA87608@cdnetworks.co.kr> References: <20070310074734.GC70613@cdnetworks.co.kr> <917080.87242.qm@web34701.mail.mud.yahoo.com> <20070311050627.GC79728@cdnetworks.co.kr> <45F3B94B.3030104@gwdg.de> <20070312045116.GA83433@cdnetworks.co.kr> <45F5C914.3000805@gwdg.de> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="sm4nu43k4a2Rpi4c" Content-Disposition: inline In-Reply-To: <45F5C914.3000805@gwdg.de> User-Agent: Mutt/1.4.2.1i Cc: darren780@yahoo.com, freebsd-current@freebsd.org Subject: Re: yongari nfe problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2007 00:43:49 -0000 --sm4nu43k4a2Rpi4c Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Mar 12, 2007 at 10:41:40PM +0100, Rainer Hurling wrote: > Pyun YongHyeon, thank you for reply. > > Sorry for the late answer, but I have been on business trip. > > Pyun YongHyeon schrieb: > >On Sun, Mar 11, 2007 at 09:09:47AM +0100, Rainer Hurling wrote: > > > Pyun YongHyeon schrieb: > > > >[... SNIP ...] > > > > > > > >Did stock nfe(4) work on MCP55? > > > >(I'm not interested in how nve(4) works on MCP55.) > > > >I'm afraid MCP55 requires different programming. Searching archives > > > >for Linux forcedeth driver also reveals issues on MCP55 which is > > > >exactly the same issue I think. > > > >I'll let you know if I find a clue but it's hard to fix due to lack > > > >of MCP55 hardware and documentation. > > > > > > > > > Yes, nfe(4) works on MCP55, but with some strange behaviour, see below. > > > > > > I am working with FreeBSD 7.0-CURRENT from 03/07/2007 on MSI K9N Neo. > > > 'dmesg | grep nfe' gives me: > > > > > > nfe0: port 0xb000-0xb007 mem > > > 0xfbef7000-0xfbef7fff,0xfbefa800-0xfbefa8ff,0xfbefa400-0xfbefa40f irq 21 > > > at device 8.0 on pci0 > > > miibus0: on nfe0 > > > ukphy0: PHY 1 on miibus0 > > > ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, > > > 1000baseT-FDX, auto > > > nfe0: using obsoleted if_watchdog interface > > > nfe0: Ethernet address: xx:xx:xx:xx:xx:xx > > > nfe0: [ITHREAD] > > > > > > It seems that there is a problem with watchdog. Perhaps the choosen > > > media interface ukphy0 is not correct? > > > > > > >Normally nVidia GigEs use Marvell PHY which is served by e1000phy(4) > >so I guess power saving mode had ukphy attach the PHY. > >Booting/loading module with bootverbose mode will show up OUI/model/rev > >of the PHY. Please let me know the OUI/model/rev output of ukphy(4). > > for ukphy0 bootverbose gives me : > > OUI 0x0001c1 model 0x0002 rev. 0 > Hmm, it's gigabit PHY from Vitesse semiconductor. AFAIK there is no driver for the PHY but I guess ciphy(4) would be a possible driver for the PHY. I've checked Vitesse site for the PHY documentation but it seems they require a kind of NDA and it's not available option to me. Please try attached patch and rebuild miibus(4) and give it a spin. > > > > In the context with watchdog I observe an interesting behaviour of > > nfe0: > After running WindowsXP on my board, I am not able to use the > > interface > any more. Booting FreeBSD always gives me messages like this: > > > > > > ----- > > > nfe0: link state changed to DOWN > > > /etc/rc.d/dhclient: WARNING: $background_dhclient_nfe0 is not set > > > properly - > > > see > > > rc.conf(5). > > > nfe0: no link ....nfe0: link state changed to UP > > > got link > > > DHCPREQUEST on nfe0 to 255.255.255.255 port 67 > > > nfe0: watchdog timeout > > > nfe0: link state changed to DOWN > > > nfe0: link state changed to UP > > > DHCPREQUEST on nfe0 to 255.255.255.255 port 67 > > > nfe0: watchdog timeout > > > nfe0: link state changed to DOWN > > > nfe0: link state changed to UP > > > DHCPDISCOVER on nfe0 to 255.255.255.255 port 67 interval 5 > > > nfe0: watchdog timeout > > > nfe0: link state changed to DOWN > > > DHCPDISCOVER on nfe0 to 255.255.255.255 port 67 interval 9 > > > nfe0: link state changed to UP > > > nfe0: watchdog timeout > > > nfe0: link state changed to DOWN > > > nfe0: link state changed to UP > > > DHCPDISCOVER on nfe0 to 255.255.255.255 port 67 interval 14 > > > nfe0: watchdog timeout > > > nfe0: link state changed to DOWN > > > nfe0: link state changed to UP > > > DHCPDISCOVER on nfe0 to 255.255.255.255 port 67 interval 18 > > > nfe0: watchdog timeout > > > nfe0: link state changed to DOWN > > > nfe0: link state changed to UP > > > DHCPDISCOVER on nfe0 to 255.255.255.255 port 67 interval 9 > > > nfe0: watchdog timeout > > > nfe0: link state changed to DOWN > > > nfe0: link state changed to UP > > > DHCPDISCOVER on nfe0 to 255.255.255.255 port 67 interval 6 > > > nfe0: watchdog timeout > > > nfe0: link state changed to DOWN > > > No DHCPOFFERS received. > > > Trying recorded lease xxx.xxx.xxx.xxx > > > nfe0: link state changed to UP > > > bound: renewal in 429590 seconds. > > > lo0: flags=8049 metric 0 mtu 16384 > > > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 > > > inet6 ::1 prefixlen 128 > > > inet 127.0.0.1 netmask 0xff000000 > > > nfe0: flags=8843 metric 0 mtu > > 1500 > > > options=2b > > > ether xx:xx:xx:xx:xx:xx > > > media: Ethernet autoselect (100baseTX ) > > > status: active > > > ----- > > > > > > When booting 'cold' (means full power down) FreeBSD is able to use > > > nfe(4) in the correct way. Also booting FreeBSD again after running > > > FreeBSD gives me no errors. Obviously WindowsXP does not clear up all > > > registers in MCP55 after leaving? > > > > > > >I think Windows put the NIC/PHY in sleep/power saving mode and nfe(4) > >will need a way to take PHY/NIC out of power down mode. > >Try a WIP version at the following URL. > > > >http://people.freebsd.org/~yongari/nfe/WIP/if_nfe.c > >http://people.freebsd.org/~yongari/nfe/WIP/if_nfereg.h > >http://people.freebsd.org/~yongari/nfe/WIP/if_nfevar.h > > > >Note, it's just guess work from the Linux driver and I just tested > >compilation. Due to lack of time/MCP55 hardware it's not easy for me > >to fix. > > I tried your fixes. Bingo, you are right! Now I am able to use nfe(4) > directly (without coldstart) after leaving from WindowsXP. > Great! Thank you for testing. > Thank you very much, > > Rainer Hurling > -- Regards, Pyun YongHyeon --sm4nu43k4a2Rpi4c Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="ciphy.patch" Index: miidevs =================================================================== RCS file: /home/ncvs/src/sys/dev/mii/miidevs,v retrieving revision 1.41 diff -u -r1.41 miidevs --- miidevs 21 Feb 2007 18:17:44 -0000 1.41 +++ miidevs 13 Mar 2007 00:42:49 -0000 @@ -67,6 +67,7 @@ oui TDK 0x00c039 TDK oui TI 0x080028 Texas Instruments oui XAQTI 0x00e0ae XaQti Corp. +oui VITESSE 0x0001c1 Vitesse Semiconductor oui MARVELL 0x005043 Marvell Semiconductor oui xxMARVELL 0x000ac2 Marvell Semiconductor @@ -135,6 +136,7 @@ /* Cicada Semiconductor PHYs (now owned by Vitesse?) */ model CICADA CS8201 0x0001 Cicada CS8201 10/100/1000TX PHY +model VITESSE VSC8601 0x0002 VSC8601 10/100/1000TX PHY model CICADA CS8201A 0x0020 Cicada CS8201 10/100/1000TX PHY model CICADA CS8201B 0x0021 Cicada CS8201 10/100/1000TX PHY Index: ciphy.c =================================================================== RCS file: /home/ncvs/src/sys/dev/mii/ciphy.c,v retrieving revision 1.8 diff -u -r1.8 ciphy.c --- ciphy.c 2 Dec 2006 19:36:25 -0000 1.8 +++ ciphy.c 13 Mar 2007 00:42:49 -0000 @@ -91,6 +91,7 @@ MII_PHY_DESC(CICADA, CS8201), MII_PHY_DESC(CICADA, CS8201A), MII_PHY_DESC(CICADA, CS8201B), + MII_PHY_DESC(VITESSE, VSC8601), MII_PHY_END }; @@ -339,7 +340,24 @@ static void ciphy_reset(struct mii_softc *sc) { + struct mii_data *mii; + uint16_t val; + mii = sc->mii_pdata; + if (strcmp(mii->mii_ifp->if_dname, "nfe") == 0) { + /* need to set for 2.5V RGMII for NVIDIA adapters */ + val = PHY_READ(sc, CIPHY_MII_ECTL1); + val &= ~(CIPHY_ECTL1_IOVOL | CIPHY_ECTL1_INTSEL); + val |= (CIPHY_IOVOL_2500MV | CIPHY_INTSEL_RGMII); + PHY_WRITE(sc, CIPHY_MII_ECTL1, val); + /* From Linux. */ + val = PHY_READ(sc, CIPHY_MII_AUXCSR); + val |= CIPHY_AUXCSR_MDPPS; + PHY_WRITE(sc, CIPHY_MII_AUXCSR, val); + val = PHY_READ(sc, CIPHY_MII_10BTCSR); + val |= CIPHY_10BTCSR_ECHO; + PHY_WRITE(sc, CIPHY_MII_10BTCSR, val); + } mii_phy_reset(sc); DELAY(1000); } --sm4nu43k4a2Rpi4c-- From owner-freebsd-current@FreeBSD.ORG Tue Mar 13 00:56:32 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 631DF16A401 for ; Tue, 13 Mar 2007 00:56:32 +0000 (UTC) (envelope-from pyunyh@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 04F3013C44C for ; Tue, 13 Mar 2007 00:56:31 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by wx-out-0506.google.com with SMTP id s18so1753849wxc for ; Mon, 12 Mar 2007 17:56:31 -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=FrEud4vkv7lZ6ZEZtOsqV0E0JU+hmCtrTypCYpv2yo0//FQLCyqkzWckpuExgdNTELbwbVUAnK7Ma9OzDaGBv71Uzego90pal1PVDkNeaMqMa4e3UwbQ5/khzfvwn2AEzwA81mmlwWiz4R3u0tpYbeUo4duYdmVYlfH+wxMidh0= 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=HHdiQx/jFeHWIwsZltfBdnXbT5oQFBgg9f2TBhU+0WLuaqPbrHlVODYg5AhhXXaJnK74UysiERGv9lb+lRCzUWf4TfBPKK7z9oMWuozd/QMl0kYxwisRVsJenmcY8/yaB1IUaym2mAK+p/d3BtDGNy2olmstMdyAfl8I3frfLek= Received: by 10.70.52.2 with SMTP id z2mr402344wxz.1173747391352; Mon, 12 Mar 2007 17:56:31 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTP id 34sm32421477nza.2007.03.12.17.56.28; Mon, 12 Mar 2007 17:56:30 -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 l2D0wlui088615 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Mar 2007 09:58:47 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id l2D0wlo4088614; Tue, 13 Mar 2007 09:58:47 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Tue, 13 Mar 2007 09:58:45 +0900 From: Pyun YongHyeon To: Rainer Hurling Message-ID: <20070313005845.GB87608@cdnetworks.co.kr> References: <20070310074734.GC70613@cdnetworks.co.kr> <917080.87242.qm@web34701.mail.mud.yahoo.com> <20070311050627.GC79728@cdnetworks.co.kr> <45F3B94B.3030104@gwdg.de> <20070312045116.GA83433@cdnetworks.co.kr> <45F5C914.3000805@gwdg.de> <20070313004601.GA87608@cdnetworks.co.kr> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Bn2rw/3z4jIqBvZU" Content-Disposition: inline In-Reply-To: <20070313004601.GA87608@cdnetworks.co.kr> User-Agent: Mutt/1.4.2.1i Cc: darren780@yahoo.com, freebsd-current@freebsd.org Subject: Re: yongari nfe problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2007 00:56:32 -0000 --Bn2rw/3z4jIqBvZU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Mar 13, 2007 at 09:46:01AM +0900, To Rainer Hurling wrote: > On Mon, Mar 12, 2007 at 10:41:40PM +0100, Rainer Hurling wrote: > > Pyun YongHyeon, thank you for reply. > > > > Sorry for the late answer, but I have been on business trip. > > > > Pyun YongHyeon schrieb: > > >On Sun, Mar 11, 2007 at 09:09:47AM +0100, Rainer Hurling wrote: > > > > Pyun YongHyeon schrieb: > > > > >[... SNIP ...] > > > > > > > > > >Did stock nfe(4) work on MCP55? > > > > >(I'm not interested in how nve(4) works on MCP55.) > > > > >I'm afraid MCP55 requires different programming. Searching archives > > > > >for Linux forcedeth driver also reveals issues on MCP55 which is > > > > >exactly the same issue I think. > > > > >I'll let you know if I find a clue but it's hard to fix due to lack > > > > >of MCP55 hardware and documentation. > > > > > > > > > > > > Yes, nfe(4) works on MCP55, but with some strange behaviour, see below. > > > > > > > > I am working with FreeBSD 7.0-CURRENT from 03/07/2007 on MSI K9N Neo. > > > > 'dmesg | grep nfe' gives me: > > > > > > > > nfe0: port 0xb000-0xb007 mem > > > > 0xfbef7000-0xfbef7fff,0xfbefa800-0xfbefa8ff,0xfbefa400-0xfbefa40f irq 21 > > > > at device 8.0 on pci0 > > > > miibus0: on nfe0 > > > > ukphy0: PHY 1 on miibus0 > > > > ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, > > > > 1000baseT-FDX, auto > > > > nfe0: using obsoleted if_watchdog interface > > > > nfe0: Ethernet address: xx:xx:xx:xx:xx:xx > > > > nfe0: [ITHREAD] > > > > > > > > It seems that there is a problem with watchdog. Perhaps the choosen > > > > media interface ukphy0 is not correct? > > > > > > > > > >Normally nVidia GigEs use Marvell PHY which is served by e1000phy(4) > > >so I guess power saving mode had ukphy attach the PHY. > > >Booting/loading module with bootverbose mode will show up OUI/model/rev > > >of the PHY. Please let me know the OUI/model/rev output of ukphy(4). > > > > for ukphy0 bootverbose gives me : > > > > OUI 0x0001c1 model 0x0002 rev. 0 > > > > Hmm, it's gigabit PHY from Vitesse semiconductor. > AFAIK there is no driver for the PHY but I guess ciphy(4) would be a > possible driver for the PHY. I've checked Vitesse site for the PHY > documentation but it seems they require a kind of NDA and it's not > available option to me. > > Please try attached patch and rebuild miibus(4) and give it a spin. > Oops, please use this patch. -- Regards, Pyun YongHyeon --Bn2rw/3z4jIqBvZU Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="ciphy.patch2" Index: miidevs =================================================================== RCS file: /home/ncvs/src/sys/dev/mii/miidevs,v retrieving revision 1.41 diff -u -r1.41 miidevs --- miidevs 21 Feb 2007 18:17:44 -0000 1.41 +++ miidevs 13 Mar 2007 00:53:47 -0000 @@ -66,6 +66,7 @@ oui SIS 0x00e006 Silicon Integrated Systems oui TDK 0x00c039 TDK oui TI 0x080028 Texas Instruments +oui VITESSE 0x0001c1 Vitesse Semiconductor oui XAQTI 0x00e0ae XaQti Corp. oui MARVELL 0x005043 Marvell Semiconductor oui xxMARVELL 0x000ac2 Marvell Semiconductor @@ -135,6 +136,7 @@ /* Cicada Semiconductor PHYs (now owned by Vitesse?) */ model CICADA CS8201 0x0001 Cicada CS8201 10/100/1000TX PHY +model VITESSE VSC8601 0x0002 VSC8601 10/100/1000TX PHY model CICADA CS8201A 0x0020 Cicada CS8201 10/100/1000TX PHY model CICADA CS8201B 0x0021 Cicada CS8201 10/100/1000TX PHY Index: ciphy.c =================================================================== RCS file: /home/ncvs/src/sys/dev/mii/ciphy.c,v retrieving revision 1.8 diff -u -r1.8 ciphy.c --- ciphy.c 2 Dec 2006 19:36:25 -0000 1.8 +++ ciphy.c 13 Mar 2007 00:53:47 -0000 @@ -91,6 +91,7 @@ MII_PHY_DESC(CICADA, CS8201), MII_PHY_DESC(CICADA, CS8201A), MII_PHY_DESC(CICADA, CS8201B), + MII_PHY_DESC(VITESSE, VSC8601), MII_PHY_END }; @@ -339,7 +340,24 @@ static void ciphy_reset(struct mii_softc *sc) { + struct mii_data *mii; + uint16_t val; + mii = sc->mii_pdata; + if (strcmp(mii->mii_ifp->if_dname, "nfe") == 0) { + /* need to set for 2.5V RGMII for NVIDIA adapters */ + val = PHY_READ(sc, CIPHY_MII_ECTL1); + val &= ~(CIPHY_ECTL1_IOVOL | CIPHY_ECTL1_INTSEL); + val |= (CIPHY_IOVOL_2500MV | CIPHY_INTSEL_RGMII); + PHY_WRITE(sc, CIPHY_MII_ECTL1, val); + /* From Linux. */ + val = PHY_READ(sc, CIPHY_MII_AUXCSR); + val |= CIPHY_AUXCSR_MDPPS; + PHY_WRITE(sc, CIPHY_MII_AUXCSR, val); + val = PHY_READ(sc, CIPHY_MII_10BTCSR); + val |= CIPHY_10BTCSR_ECHO; + PHY_WRITE(sc, CIPHY_MII_10BTCSR, val); + } mii_phy_reset(sc); DELAY(1000); } Index: ciphyreg.h =================================================================== RCS file: /home/ncvs/src/sys/dev/mii/ciphyreg.h,v retrieving revision 1.2 diff -u -r1.2 ciphyreg.h --- ciphyreg.h 6 Jan 2005 01:42:55 -0000 1.2 +++ ciphyreg.h 13 Mar 2007 00:53:47 -0000 @@ -251,6 +251,16 @@ /* Extended PHY control register #1 */ #define CIPHY_MII_ECTL1 0x17 #define CIPHY_ECTL1_ACTIPHY 0x0020 /* Enable ActiPHY power saving */ +#define CIPHY_ECTL1_IOVOL 0x0e00 /* MAC interface and I/O voltage select */ +#define CIPHY_ECTL1_INTSEL 0xf000 /* select MAC interface */ + +#define CIPHY_IOVOL_3300MV 0x0000 /* 3.3V for I/O pins */ +#define CIPHY_IOVOL_2500MV 0x0200 /* 2.5V for I/O pins */ + +#define CIPHY_INTSEL_GMII 0x0000 /* GMII/MII */ +#define CIPHY_INTSEL_RGMII 0x1000 +#define CIPHY_INTSEL_TBI 0x2000 +#define CIPHY_INTSEL_RTBI 0x3000 /* Extended PHY control register #2 */ #define CIPHY_MII_ECTL2 0x18 --Bn2rw/3z4jIqBvZU-- From owner-freebsd-current@FreeBSD.ORG Tue Mar 13 00:50:46 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AD85B16A402 for ; Tue, 13 Mar 2007 00:50:46 +0000 (UTC) (envelope-from admin@garyshood.com) Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.189]) by mx1.freebsd.org (Postfix) with ESMTP id 4F04313C44C for ; Tue, 13 Mar 2007 00:50:46 +0000 (UTC) (envelope-from admin@garyshood.com) Received: by mu-out-0910.google.com with SMTP id g7so2295915muf for ; Mon, 12 Mar 2007 17:50:45 -0700 (PDT) Received: by 10.82.167.5 with SMTP id p5mr456158bue.1173745585990; Mon, 12 Mar 2007 17:26:25 -0700 (PDT) Received: by 10.82.167.14 with HTTP; Mon, 12 Mar 2007 17:26:25 -0700 (PDT) Message-ID: Date: Mon, 12 Mar 2007 18:26:25 -0600 From: "Gary Suggett" 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: Tue, 13 Mar 2007 01:13:08 +0000 Subject: March -Current i386 Panic 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, 13 Mar 2007 00:50:46 -0000 Current 200702 runs and loads perfect on this machine, but can't say the same for the newest March snapshot, checksum okay. Booting up will get end up with the following message at the end, right as the blue screen that says probing for devices appears. BARF 170 <105 panic: Going nowhere without my init! cpuid = 0 KDB: enter: panic [thread pid 1 tid 100007] Stopped at kdb_enter+0x2b: nop db> On booting safe mode, the error gets this far. pci0: at device 31.3 (no driver attached) panic: vm_fault: fault on nofault entry addr: c000b000 cpuid = 0 KDB: enter: panic [thread pid 0 tid 0] Stopped at kdb_enter+0x2b: nop Like I said, the machine runs fine on the February snapshot, but won't boot on March. It's an i686 Intel pentium D 915 processor, so dual core, 64 bit, in case that throws anything off. From owner-freebsd-current@FreeBSD.ORG Tue Mar 13 05:29:33 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9D2CD16A402 for ; Tue, 13 Mar 2007 05:29:33 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Received: from tmailer.gwdg.de (tmailer.gwdg.de [134.76.10.23]) by mx1.freebsd.org (Postfix) with ESMTP id 21F3413C46A for ; Tue, 13 Mar 2007 05:29:33 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Received: from [87.139.104.184] (helo=[192.168.2.20]) by mailer.gwdg.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1HQzZh-0000TY-Us; Tue, 13 Mar 2007 06:29:30 +0100 Message-ID: <45F636B5.9060608@gwdg.de> Date: Tue, 13 Mar 2007 06:29:25 +0100 From: Rainer Hurling User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: pyunyh@gmail.com References: <20070310074734.GC70613@cdnetworks.co.kr> <917080.87242.qm@web34701.mail.mud.yahoo.com> <20070311050627.GC79728@cdnetworks.co.kr> <45F3B94B.3030104@gwdg.de> <20070312045116.GA83433@cdnetworks.co.kr> <45F5C914.3000805@gwdg.de> <20070313004601.GA87608@cdnetworks.co.kr> <20070313005845.GB87608@cdnetworks.co.kr> In-Reply-To: <20070313005845.GB87608@cdnetworks.co.kr> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated: Id:rhurlin X-Spam-Level: - X-Virus-Scanned: (clean) by exiscan+sophie Cc: darren780@yahoo.com, freebsd-current@freebsd.org Subject: Re: yongari nfe 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: Tue, 13 Mar 2007 05:29:33 -0000 Over night my systems works well, only one message from network came up: nfe0: watchdog timeout (missed Tx interrupts) -- recovering nfe0: watchdog timeout (missed Tx interrupts) -- recovering In the morning I tried your patch for mii and PHY. Bootingverbose again gives me: nfe0: port 0xb000-0xb007 mem 0xfbef3000-0xfbef3fff,0xfbefa800-0xfbefa8ff,0 xfbefa400-0xfbefa40f irq 22 at device 8.0 on pci0 nfe0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xfbef3000 nfe0: bpf attached nfe0: Ethernet address: 00:16:17:95:d9:7c miibus0: on nfe0 ciphy0: PHY 1 on miibus0 ciphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto nfe0: [MPSAFE] nfe0: [FILTER] First, all seems to be ok. Network was up and connected. After a minute I lost connection and the following messages appeared: miibus0: unknown CICADA PHY model 2 miibus0: unknown CICADA PHY model 2 miibus0: unknown CICADA PHY model 2 nfe0: watchdog timeout (missed Tx interrupts) -- recovering nfe0: watchdog timeout (missed Tx interrupts) -- recovering nfe0: watchdog timeout (missed Tx interrupts) -- recovering nfe0: watchdog timeout (missed Tx interrupts) -- recovering ... Probably a little more work on the patches is needed? I am offline for the next ten hours. After that I could test any new version ;-) Thank you very much, Rainer Pyun YongHyeon schrieb: > On Tue, Mar 13, 2007 at 09:46:01AM +0900, To Rainer Hurling wrote: > > On Mon, Mar 12, 2007 at 10:41:40PM +0100, Rainer Hurling wrote: > > > Pyun YongHyeon, thank you for reply. > > > > > > Sorry for the late answer, but I have been on business trip. > > > > > > Pyun YongHyeon schrieb: > > > >On Sun, Mar 11, 2007 at 09:09:47AM +0100, Rainer Hurling wrote: > > > > > Pyun YongHyeon schrieb: > > > > > >[... SNIP ...] > > > > > > > > > > > >Did stock nfe(4) work on MCP55? > > > > > >(I'm not interested in how nve(4) works on MCP55.) > > > > > >I'm afraid MCP55 requires different programming. Searching archives > > > > > >for Linux forcedeth driver also reveals issues on MCP55 which is > > > > > >exactly the same issue I think. > > > > > >I'll let you know if I find a clue but it's hard to fix due to lack > > > > > >of MCP55 hardware and documentation. > > > > > > > > > > > > > > > Yes, nfe(4) works on MCP55, but with some strange behaviour, see below. > > > > > > > > > > I am working with FreeBSD 7.0-CURRENT from 03/07/2007 on MSI K9N Neo. > > > > > 'dmesg | grep nfe' gives me: > > > > > > > > > > nfe0: port 0xb000-0xb007 mem > > > > > 0xfbef7000-0xfbef7fff,0xfbefa800-0xfbefa8ff,0xfbefa400-0xfbefa40f irq 21 > > > > > at device 8.0 on pci0 > > > > > miibus0: on nfe0 > > > > > ukphy0: PHY 1 on miibus0 > > > > > ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, > > > > > 1000baseT-FDX, auto > > > > > nfe0: using obsoleted if_watchdog interface > > > > > nfe0: Ethernet address: xx:xx:xx:xx:xx:xx > > > > > nfe0: [ITHREAD] > > > > > > > > > > It seems that there is a problem with watchdog. Perhaps the choosen > > > > > media interface ukphy0 is not correct? > > > > > > > > > > > > >Normally nVidia GigEs use Marvell PHY which is served by e1000phy(4) > > > >so I guess power saving mode had ukphy attach the PHY. > > > >Booting/loading module with bootverbose mode will show up OUI/model/rev > > > >of the PHY. Please let me know the OUI/model/rev output of ukphy(4). > > > > > > for ukphy0 bootverbose gives me : > > > > > > OUI 0x0001c1 model 0x0002 rev. 0 > > > > > > > Hmm, it's gigabit PHY from Vitesse semiconductor. > > AFAIK there is no driver for the PHY but I guess ciphy(4) would be a > > possible driver for the PHY. I've checked Vitesse site for the PHY > > documentation but it seems they require a kind of NDA and it's not > > available option to me. > > > > Please try attached patch and rebuild miibus(4) and give it a spin. > > > > Oops, please use this patch. > > > > ------------------------------------------------------------------------ > > Index: miidevs > =================================================================== > RCS file: /home/ncvs/src/sys/dev/mii/miidevs,v > retrieving revision 1.41 > diff -u -r1.41 miidevs > --- miidevs 21 Feb 2007 18:17:44 -0000 1.41 > +++ miidevs 13 Mar 2007 00:53:47 -0000 > @@ -66,6 +66,7 @@ > oui SIS 0x00e006 Silicon Integrated Systems > oui TDK 0x00c039 TDK > oui TI 0x080028 Texas Instruments > +oui VITESSE 0x0001c1 Vitesse Semiconductor > oui XAQTI 0x00e0ae XaQti Corp. > oui MARVELL 0x005043 Marvell Semiconductor > oui xxMARVELL 0x000ac2 Marvell Semiconductor > @@ -135,6 +136,7 @@ > > /* Cicada Semiconductor PHYs (now owned by Vitesse?) */ > model CICADA CS8201 0x0001 Cicada CS8201 10/100/1000TX PHY > +model VITESSE VSC8601 0x0002 VSC8601 10/100/1000TX PHY > model CICADA CS8201A 0x0020 Cicada CS8201 10/100/1000TX PHY > model CICADA CS8201B 0x0021 Cicada CS8201 10/100/1000TX PHY > > Index: ciphy.c > =================================================================== > RCS file: /home/ncvs/src/sys/dev/mii/ciphy.c,v > retrieving revision 1.8 > diff -u -r1.8 ciphy.c > --- ciphy.c 2 Dec 2006 19:36:25 -0000 1.8 > +++ ciphy.c 13 Mar 2007 00:53:47 -0000 > @@ -91,6 +91,7 @@ > MII_PHY_DESC(CICADA, CS8201), > MII_PHY_DESC(CICADA, CS8201A), > MII_PHY_DESC(CICADA, CS8201B), > + MII_PHY_DESC(VITESSE, VSC8601), > MII_PHY_END > }; > > @@ -339,7 +340,24 @@ > static void > ciphy_reset(struct mii_softc *sc) > { > + struct mii_data *mii; > + uint16_t val; > > + mii = sc->mii_pdata; > + if (strcmp(mii->mii_ifp->if_dname, "nfe") == 0) { > + /* need to set for 2.5V RGMII for NVIDIA adapters */ > + val = PHY_READ(sc, CIPHY_MII_ECTL1); > + val &= ~(CIPHY_ECTL1_IOVOL | CIPHY_ECTL1_INTSEL); > + val |= (CIPHY_IOVOL_2500MV | CIPHY_INTSEL_RGMII); > + PHY_WRITE(sc, CIPHY_MII_ECTL1, val); > + /* From Linux. */ > + val = PHY_READ(sc, CIPHY_MII_AUXCSR); > + val |= CIPHY_AUXCSR_MDPPS; > + PHY_WRITE(sc, CIPHY_MII_AUXCSR, val); > + val = PHY_READ(sc, CIPHY_MII_10BTCSR); > + val |= CIPHY_10BTCSR_ECHO; > + PHY_WRITE(sc, CIPHY_MII_10BTCSR, val); > + } > mii_phy_reset(sc); > DELAY(1000); > } > Index: ciphyreg.h > =================================================================== > RCS file: /home/ncvs/src/sys/dev/mii/ciphyreg.h,v > retrieving revision 1.2 > diff -u -r1.2 ciphyreg.h > --- ciphyreg.h 6 Jan 2005 01:42:55 -0000 1.2 > +++ ciphyreg.h 13 Mar 2007 00:53:47 -0000 > @@ -251,6 +251,16 @@ > /* Extended PHY control register #1 */ > #define CIPHY_MII_ECTL1 0x17 > #define CIPHY_ECTL1_ACTIPHY 0x0020 /* Enable ActiPHY power saving */ > +#define CIPHY_ECTL1_IOVOL 0x0e00 /* MAC interface and I/O voltage select */ > +#define CIPHY_ECTL1_INTSEL 0xf000 /* select MAC interface */ > + > +#define CIPHY_IOVOL_3300MV 0x0000 /* 3.3V for I/O pins */ > +#define CIPHY_IOVOL_2500MV 0x0200 /* 2.5V for I/O pins */ > + > +#define CIPHY_INTSEL_GMII 0x0000 /* GMII/MII */ > +#define CIPHY_INTSEL_RGMII 0x1000 > +#define CIPHY_INTSEL_TBI 0x2000 > +#define CIPHY_INTSEL_RTBI 0x3000 > > /* Extended PHY control register #2 */ > #define CIPHY_MII_ECTL2 0x18 From owner-freebsd-current@FreeBSD.ORG Tue Mar 13 06:59:38 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0399416A404 for ; Tue, 13 Mar 2007 06:59:38 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.227]) by mx1.freebsd.org (Postfix) with ESMTP id B46BF13C448 for ; Tue, 13 Mar 2007 06:59:37 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by wr-out-0506.google.com with SMTP id q50so1181316wrq for ; Mon, 12 Mar 2007 23:59:36 -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=ZuqfwoipdJQUxeX3mGNguLqj99WHYl2bFL/ONWThvw/QezDHOi1H5O6wVb+pr9p7h1agjnIqCpGlXBp729MDqn1LbfxVUQ8pbsO0MqU/fbpRi1N1eeeRi7aanZIXsJpQ2rIXdmOY2puSkbQpLvZUv8TI4Vgjlh8l1f57fcTwndc= 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=dT16wtuNPJH4KhlHtQ2eXfvvtVUvo5of3t+72br+ueHztQfoxTyWyeYzbhvu98LZ5+Tb88JFAIkJ7sLdmTybV+EiSqXfX2EBzHE8SgE7QnpLOx2+TX91uzrAW9EDivfJTykB0GD+3op0MM343MAA+grpVrGry7RdYPw1+WWdHdQ= Received: by 10.35.81.1 with SMTP id i1mr1038425pyl.1173769175233; Mon, 12 Mar 2007 23:59:35 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTP id 7sm33728828nzn.2007.03.12.23.59.33; Mon, 12 Mar 2007 23:59:34 -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 l2D71shF089730 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Mar 2007 16:01:55 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id l2D71rXc089729; Tue, 13 Mar 2007 16:01:53 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Tue, 13 Mar 2007 16:01:53 +0900 From: Pyun YongHyeon To: Rainer Hurling Message-ID: <20070313070153.GD87608@cdnetworks.co.kr> References: <20070310074734.GC70613@cdnetworks.co.kr> <917080.87242.qm@web34701.mail.mud.yahoo.com> <20070311050627.GC79728@cdnetworks.co.kr> <45F3B94B.3030104@gwdg.de> <20070312045116.GA83433@cdnetworks.co.kr> <45F5C914.3000805@gwdg.de> <20070313004601.GA87608@cdnetworks.co.kr> <20070313005845.GB87608@cdnetworks.co.kr> <45F636B5.9060608@gwdg.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45F636B5.9060608@gwdg.de> User-Agent: Mutt/1.4.2.1i Cc: darren780@yahoo.com, freebsd-current@freebsd.org Subject: Re: yongari nfe problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2007 06:59:38 -0000 On Tue, Mar 13, 2007 at 06:29:25AM +0100, Rainer Hurling wrote: > Over night my systems works well, only one message from network came up: > > nfe0: watchdog timeout (missed Tx interrupts) -- recovering > nfe0: watchdog timeout (missed Tx interrupts) -- recovering > I'm not sure this watchdog is related with VSC8601 PHY. However Mr. Darren also reported watchdog errors on MCP55 so I have to think again what makes MCP55 different. > In the morning I tried your patch for mii and PHY. Bootingverbose again > gives me: > > nfe0: port 0xb000-0xb007 mem > 0xfbef3000-0xfbef3fff,0xfbefa800-0xfbefa8ff,0 > xfbefa400-0xfbefa40f irq 22 at device 8.0 on pci0 > nfe0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xfbef3000 > nfe0: bpf attached > nfe0: Ethernet address: 00:16:17:95:d9:7c > miibus0: on nfe0 > ciphy0: PHY 1 on miibus0 > ciphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, > 1000baseT-FDX, auto > nfe0: [MPSAFE] > nfe0: [FILTER] > > > First, all seems to be ok. Network was up and connected. After a minute > I lost connection and the following messages appeared: > > miibus0: unknown CICADA PHY model 2 > miibus0: unknown CICADA PHY model 2 > miibus0: unknown CICADA PHY model 2 Sorry, you can ignore this. I've ommitted a code needed in fixup code for VSC8601. > nfe0: watchdog timeout (missed Tx interrupts) -- recovering > nfe0: watchdog timeout (missed Tx interrupts) -- recovering > nfe0: watchdog timeout (missed Tx interrupts) -- recovering > nfe0: watchdog timeout (missed Tx interrupts) -- recovering > ... > This is real problem. I guess ciphy(4) failed to report correct link state so watchdog handler was activated. Apparently we **NEED** a copy of the documentation for the PHY. :-( You can revert the PHY changes and use ukphy(4) until the issue is resolved. > > Probably a little more work on the patches is needed? > Yes, ciphy(4) should be educated to access magic registers. > I am offline for the next ten hours. After that I could test any new > version ;-) > I'll let you know if I have a patch for the watchdog errors. In these days I have little time to focus on FreeBSD stuff so don't expect quick reply. Thank you very much for testing and your time. > Thank you very much, > Rainer > -- Regards, Pyun YongHyeon From owner-freebsd-current@FreeBSD.ORG Tue Mar 13 07:10:39 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DBDA316A401 for ; Tue, 13 Mar 2007 07:10:39 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from cs1.cs.huji.ac.il (cs1.cs.huji.ac.il [132.65.16.10]) by mx1.freebsd.org (Postfix) with ESMTP id A029413C44B for ; Tue, 13 Mar 2007 07:10:39 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by cs1.cs.huji.ac.il with esmtp id 1HR19a-000BDp-BN; Tue, 13 Mar 2007 09:10:38 +0200 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: freebsd-current@freebsd.org In-reply-to: Your message of Thu, 08 Mar 2007 16:29:28 +0200 . Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 13 Mar 2007 09:10:38 +0200 From: Danny Braniss Message-ID: Cc: Pyun YongHyeon Subject: Re: nfe/PXE problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2007 07:10:39 -0000 > well, I can PXE boot this box if I use an fxp NIC, with the nfe I tracked the > problem > to sys/nfsclient/nfs_diskless, where in nfs_setup_diskless(void) > it does not find the nfe interface, ie, something does not match, but the > interface > was detected!. > i'll try and do some more debugging. > ok, I found the problem, in nfs_diskless.c nfs_setup_diskless(), there is a loop to search for the interface that was used to boot from, and no match is found because the hadrware ethernet address in the nfe is in the wrong byte order! and so the bcmp(...) fails. Interestingly, if booting NOT via PXE the Ethernet address is OK! nfe0: port 0xdc00-0xdc07 mem 0xfe02c000-0xfe02cfff irq 22 at device 20.0 on pci0 nfe0: Ethernet address: 00:18:f3:a9:6c:57 and via PXE: nfe0: Ethernet address: 57:6c:a9:f3:18:00 can someone with the right knowledge fix this? thanks, danny From owner-freebsd-current@FreeBSD.ORG Tue Mar 13 11:35:21 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5E40C16A401 for ; Tue, 13 Mar 2007 11:35:21 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1C5FE13C468 for ; Tue, 13 Mar 2007 11:35:20 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by py-out-1112.google.com with SMTP id f47so558349pye for ; Tue, 13 Mar 2007 04:35:20 -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=eyNK4uevH1Yka3k2iKeKgHw1I70mybsd7goziefspxpEAziAVr+s5kqABPRWJ/VwJznsqRQjtHM0IiMLi0690et/mv4CtrnrtWbd4hkVtpTnplK9fCedQorpinEBnglNkgG/jSe0Byr0DGdFDeo4e/JVMQ7Hd9dpyizTPaZWL3c= 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=XixHnP+TCDlpYbArsFf5Y+1t0aEa9hDIGDkMHAZeIi5XX6qpewaSTaqTW4jfITH0GQNq2DS0EEx5p2jEfvFnvK2A68hsFbuEpBYIWN3Sj+Us5GsA1nxqnmDV4dJAwOe1LAkrNxkL+Ts7FThQ8AulyLfiATKOsA9EDQstxwyzWKo= Received: by 10.35.121.2 with SMTP id y2mr1537858pym.1173785720456; Tue, 13 Mar 2007 04:35:20 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTP id 38sm34779265nza.2007.03.13.04.35.18; Tue, 13 Mar 2007 04:35:19 -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 l2DBbgnh090504 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Mar 2007 20:37:42 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id l2DBbfqg090503; Tue, 13 Mar 2007 20:37:41 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Tue, 13 Mar 2007 20:37:41 +0900 From: Pyun YongHyeon To: Danny Braniss Message-ID: <20070313113741.GE87608@cdnetworks.co.kr> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@freebsd.org Subject: Re: nfe/PXE problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2007 11:35:21 -0000 On Tue, Mar 13, 2007 at 09:10:38AM +0200, Danny Braniss wrote: > > > well, I can PXE boot this box if I use an fxp NIC, with the nfe I tracked the > > problem > > to sys/nfsclient/nfs_diskless, where in nfs_setup_diskless(void) > > it does not find the nfe interface, ie, something does not match, but the > > interface > > was detected!. > > i'll try and do some more debugging. > > > ok, I found the problem, in nfs_diskless.c nfs_setup_diskless(), > there is a loop to search for the interface that was used to boot from, > and no match is found because the hadrware ethernet address > in the nfe is in the wrong byte order! and so the bcmp(...) fails. Good catch! > Interestingly, if booting NOT via PXE the Ethernet address is OK! > > nfe0: port 0xdc00-0xdc07 mem > 0xfe02c000-0xfe02cfff irq 22 at device 20.0 on pci0 > nfe0: Ethernet address: 00:18:f3:a9:6c:57 > and via PXE: > nfe0: Ethernet address: 57:6c:a9:f3:18:00 > > can someone with the right knowledge fix this? > AFAIK there is no known way to get an ethernet address via EEPROM on NVIDIA NIC so nfe(4) reads specific address registers to get ethernet address as a workaround. The address registers are filled automatically by hardware after hardware reset. This type of acquisition of ethernet address is *NOT* correct way as it could get a fake etherent address since adiministor can program other ethernet address into the NIC.(e.g. ifconfig(8) can change ethernet address.) Therefore nfe(4) is very careful to save original ethernet address in device attach phase and restores the ethernet address at device detach time. To make matters worse, it seems that ethernet address in NVIDIA NIC is loaded backwards into registers so nfe(4) corrects it in nfe_init_locked(). However, it seems PXE code does not do necessary swapping for ethernet address and does not restore original MAC address in the end of PXE phase so the NIC will have bogusly programmed MAC address. When kernel boots and nfe(4) is attached it will load the bogus ethernet address which was already programmed by PXE. If /etc/start_if.nfe0 is honored in diskless boot you can override the ethernet address to use the same ethernet address as PXE did. Even if there is a way to get an ethernet address from EEPROM, PXE should be fixed first since it uses bogus ethernet address in booting stage. If I encounter the same situation I would contact vendor for updated PXE image for the NVIDIA NIC. If that is not available I think the only remaining option would be adding a new tunable to swap the ethernet address. I'm not familiar with PXE and I din't use PXE for a long time so I could be completely wrong. > thanks, > danny > > -- Regards, Pyun YongHyeon From owner-freebsd-current@FreeBSD.ORG Tue Mar 13 12:02:46 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0CBB216A402 for ; Tue, 13 Mar 2007 12:02:46 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from cs1.cs.huji.ac.il (cs1.cs.huji.ac.il [132.65.16.10]) by mx1.freebsd.org (Postfix) with ESMTP id C123A13C48A for ; Tue, 13 Mar 2007 12:02:45 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by cs1.cs.huji.ac.il with esmtp id 1HR5iG-0000YS-1p; Tue, 13 Mar 2007 14:02:44 +0200 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: pyunyh@gmail.com In-reply-to: Your message of Tue, 13 Mar 2007 20:37:41 +0900 . Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 13 Mar 2007 14:02:43 +0200 From: Danny Braniss Message-ID: Cc: freebsd-current@freebsd.org Subject: Re: nfe/PXE problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2007 12:02:46 -0000 > On Tue, Mar 13, 2007 at 09:10:38AM +0200, Danny Braniss wrote: > > > > > well, I can PXE boot this box if I use an fxp NIC, with the nfe I tracked the > > > problem > > > to sys/nfsclient/nfs_diskless, where in nfs_setup_diskless(void) > > > it does not find the nfe interface, ie, something does not match, but the > > > interface > > > was detected!. > > > i'll try and do some more debugging. > > > > > ok, I found the problem, in nfs_diskless.c nfs_setup_diskless(), > > there is a loop to search for the interface that was used to boot from, > > and no match is found because the hadrware ethernet address > > in the nfe is in the wrong byte order! and so the bcmp(...) fails. > > Good catch! > > > Interestingly, if booting NOT via PXE the Ethernet address is OK! > > > > nfe0: port 0xdc00-0xdc07 mem > > 0xfe02c000-0xfe02cfff irq 22 at device 20.0 on pci0 > > nfe0: Ethernet address: 00:18:f3:a9:6c:57 > > and via PXE: > > nfe0: Ethernet address: 57:6c:a9:f3:18:00 > > > > can someone with the right knowledge fix this? > > > > AFAIK there is no known way to get an ethernet address via EEPROM on > NVIDIA NIC so nfe(4) reads specific address registers to get ethernet > address as a workaround. The address registers are filled > automatically by hardware after hardware reset. This type of > acquisition of ethernet address is *NOT* correct way as it could get > a fake etherent address since adiministor can program other ethernet > address into the NIC.(e.g. ifconfig(8) can change ethernet address.) > Therefore nfe(4) is very careful to save original ethernet address > in device attach phase and restores the ethernet address at device > detach time. > To make matters worse, it seems that ethernet address in NVIDIA NIC > is loaded backwards into registers so nfe(4) corrects it in > nfe_init_locked(). However, it seems PXE code does not do necessary > swapping for ethernet address and does not restore original MAC > address in the end of PXE phase so the NIC will have bogusly > programmed MAC address. When kernel boots and nfe(4) is attached it > will load the bogus ethernet address which was already programmed by > PXE. If /etc/start_if.nfe0 is honored in diskless boot you can override > the ethernet address to use the same ethernet address as PXE did. > > Even if there is a way to get an ethernet address from EEPROM, PXE > should be fixed first since it uses bogus ethernet address in booting > stage. If I encounter the same situation I would contact vendor for > updated PXE image for the NVIDIA NIC. If that is not available I think > the only remaining option would be adding a new tunable to swap the > ethernet address. > > I'm not familiar with PXE and I din't use PXE for a long time so I > could be completely wrong. not completely :-) the DHCP/PXE boot works with the 'correct ethernet address'. this is because I use the static/registered mac, and so a bogus mac address can't get past the DHCP/PXE stage. so, the PXE is using the correct mac address. I can't use /etc/... because of the horse-cart problem, it's booting diskless, and the 'disk' is nfs readable via the NIC, but the NIC is not working the question now, is to see if the nfe driver can check if it was used by the PXE, and flip the address. or have NVIDIA comeup with a patch ... thanks, danny From owner-freebsd-current@FreeBSD.ORG Tue Mar 13 12:11:10 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1D43816A401 for ; Tue, 13 Mar 2007 12:11:10 +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 924AC13C44B for ; Tue, 13 Mar 2007 12:11:09 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.13.8/8.13.8) with ESMTP id l2DCB8Bl096455 for ; Tue, 13 Mar 2007 15:11:08 +0300 (MSK) (envelope-from ache@nagual.pp.ru) Received: (from ache@localhost) by nagual.pp.ru (8.13.8/8.13.8/Submit) id l2DCB8pN096454 for current@freebsd.org; Tue, 13 Mar 2007 15:11:08 +0300 (MSK) (envelope-from ache) Date: Tue, 13 Mar 2007 15:11:07 +0300 From: Andrey Chernov To: current@freebsd.org Message-ID: <20070313121106.GA96293@nagual.pp.ru> Mail-Followup-To: Andrey Chernov , current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.14 (2007-02-12) Cc: Subject: Bad gcc -O optimization cause core dump. What to do? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Mar 2007 12:11:10 -0000 Copy the segment below to the file a.c ---------------------- cut me here --------------------- #include main() { printf("%s\n", NULL); } ---------------------- cut me here --------------------- Compile first as cc a.c ./a.out got (null) Then compile as cc -O a.c ./a.out got core dump. Lets see assembler output from cc -O -S a.c .file "a.c" .text .p2align 2,,3 .globl main .type main, @function main: pushl %ebp movl %esp, %ebp subl $8, %esp andl $-16, %esp subl $28, %esp pushl $0 call puts leave ret .size main, .-main .ident "GCC: (GNU) 3.4.6 [FreeBSD] 20060825" It calls "puts(NULL)" with core dump. It means "printf("%s\n", NULL)" is overoptimized. BTW, things like "printf("1%s\n", NULL)" are not overoptimized. Any ideas? Is it right or needs to be fixed? -- http://ache.pp.ru/ From owner-freebsd-current@FreeBSD.ORG Tue Mar 13 12:33:14 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D814116A403 for ; Tue, 13 Mar 2007 12:33:14 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.174]) by mx1.freebsd.org (Postfix) with ESMTP id 6699F13C45D for ; Tue, 13 Mar 2007 12:33:14 +0000 (UTC) (envelope-from max@love2party.net) Received: from [88.66.11.22] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu7) with ESMTP (Nemesis), id 0ML2xA-1HR6Bk3A0m-000211; Tue, 13 Mar 2007 13:33:13 +0100 From: Max Laier Organization: FreeBSD To: freebsd-current@freebsd.org Date: Tue, 13 Mar 2007 13:33:01 +0100 User-Agent: KMail/1.9.5 References: <20070313121106.GA96293@nagual.pp.ru> In-Reply-To: <20070313121106.GA96293@nagual.pp.ru> X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1427497.Emh7oR0LCp"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200703131333.11692.max@love2party.net> X-Provags-ID: V01U2FsdGVkX1/yowmm+uYP0i9qRRiMh8FmT4bdTZpE0OEz3xg 0SGuday1WC1j9QbPny62iz8cM7fipc/C1yCb/St+s14mg/CgAV vkXw5l0OakG3P+Hg35AGg== Cc: Subject: Re: Bad gcc -O optimization cause core dump. What to do? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Mar 2007 12:33:14 -0000 --nextPart1427497.Emh7oR0LCp Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Tuesday 13 March 2007 13:11, Andrey Chernov wrote: > Copy the segment below to the file a.c > ---------------------- cut me here --------------------- > #include > > main() { > printf("%s\n", NULL); > } > ---------------------- cut me here --------------------- > Compile first as > cc a.c > ./a.out > got > (null) > Then compile as > cc -O a.c > ./a.out > got core dump. =2E.. > It calls "puts(NULL)" with core dump. > It means "printf("%s\n", NULL)" is overoptimized. > BTW, things like "printf("1%s\n", NULL)" are not overoptimized. > Any ideas? Is it right or needs to be fixed? See: http://www.ciselant.de/projects/gcc_printf/gcc_printf.html 3.1 =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart1427497.Emh7oR0LCp Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQBF9poHXyyEoT62BG0RAqPwAJ9OFBUGwQqZcagQU4Aji8kHy2F6wQCcCHRz gOPehzSH5fw+bsYLAsmrS7A= =hKZl -----END PGP SIGNATURE----- --nextPart1427497.Emh7oR0LCp-- From owner-freebsd-current@FreeBSD.ORG Tue Mar 13 12:48:44 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C86C016A400; Tue, 13 Mar 2007 12:48: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 83CA713C44B; Tue, 13 Mar 2007 12:48:44 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from codelabs.ru (pobox.codelabs.ru [144.206.177.45]) by pobox.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1HR6Ql-000Pg6-7T; Tue, 13 Mar 2007 15:48:43 +0300 Date: Tue, 13 Mar 2007 15:48:36 +0300 From: Eygene Ryabinkin To: Andrey Chernov , current@freebsd.org Message-ID: <20070313124836.GV58523@codelabs.ru> References: <20070313121106.GA96293@nagual.pp.ru> <20070313123717.GU58523@codelabs.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20070313123717.GU58523@codelabs.ru> Sender: rea-fbsd@codelabs.ru X-Spam-Status: No, score=-2.1 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_50 Cc: Subject: Re: Bad gcc -O optimization cause core dump. What to do? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Mar 2007 12:48:44 -0000 > The ATTR_NOTHROW_NONNULL_1 makes me think that not all is lost and something > can be done with the NULL pointer. I am not very familiar with gcc > internals, but I will try to see if something can be changed. OK, the 'gcc -O -o test -fno-builtin-printf test.c' is your friend. -- Eygene From owner-freebsd-current@FreeBSD.ORG Tue Mar 13 12:53:45 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EF94516A400; Tue, 13 Mar 2007 12:53:45 +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 AAA1C13C45A; Tue, 13 Mar 2007 12:53:45 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from codelabs.ru (pobox.codelabs.ru [144.206.177.45]) by pobox.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1HR6Fp-000PfM-2W; Tue, 13 Mar 2007 15:37:25 +0300 Date: Tue, 13 Mar 2007 15:37:18 +0300 From: Eygene Ryabinkin To: Andrey Chernov , current@freebsd.org Message-ID: <20070313123717.GU58523@codelabs.ru> References: <20070313121106.GA96293@nagual.pp.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20070313121106.GA96293@nagual.pp.ru> Sender: rea-fbsd@codelabs.ru X-Spam-Status: No, score=-2.6 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_05 Cc: Subject: Re: Bad gcc -O optimization cause core dump. What to do? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Mar 2007 12:53:46 -0000 Andrey, good day. > It calls "puts(NULL)" with core dump. > It means "printf("%s\n", NULL)" is overoptimized. > BTW, things like "printf("1%s\n", NULL)" are not overoptimized. Yes, it is in the gcc/builtins.c::expand_builtin_printf(). Currently it only handles "%s" and "%c". > Any ideas? Is it right or needs to be fixed? It is definitely not right, since it produces the bad code. And there are no compilation-time checks that can say for sure will the argument for the "%s" be NULL: ----- $ cat 1.c #include int main(void) { void *ptr = NULL; func(ptr); } int func(void *ptr) { printf("%s\n", ptr); } :: rea@codelabs : 15:31:43 : ~/xlam $ cat 1.s .file "1.c" .text .p2align 2,,3 .globl main .type main, @function main: pushl %ebp movl %esp, %ebp subl $8, %esp andl $-16, %esp subl $28, %esp pushl $0 call func leave ret .size main, .-main .p2align 2,,3 .globl func .type func, @function func: pushl %ebp movl %esp, %ebp subl $20, %esp pushl 8(%ebp) call puts leave ret .size func, .-func ----- The possible way to proceed with this optimization is to have the 'puts', but to enable runtime check for the NULL value. I see the following definition for the fn_puts in builtins.def: ----- DEF_EXT_LIB_BUILTIN (BUILT_IN_PUTS_UNLOCKED, "puts_unlocked", BT_FN_INT_CONST_STRING, ATTR_NOTHROW_NONNULL_1) ----- The ATTR_NOTHROW_NONNULL_1 makes me think that not all is lost and something can be done with the NULL pointer. I am not very familiar with gcc internals, but I will try to see if something can be changed. -- Eygene From owner-freebsd-current@FreeBSD.ORG Tue Mar 13 13:08:08 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3149516A401 for ; Tue, 13 Mar 2007 13:08:08 +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 A9C3D13C484 for ; Tue, 13 Mar 2007 13:08:07 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.13.8/8.13.8) with ESMTP id l2DD86iv097399; Tue, 13 Mar 2007 16:08:06 +0300 (MSK) (envelope-from ache@nagual.pp.ru) Received: (from ache@localhost) by nagual.pp.ru (8.13.8/8.13.8/Submit) id l2DD86qZ097398; Tue, 13 Mar 2007 16:08:06 +0300 (MSK) (envelope-from ache) Date: Tue, 13 Mar 2007 16:08:05 +0300 From: Andrey Chernov To: Max Laier Message-ID: <20070313130805.GA97256@nagual.pp.ru> Mail-Followup-To: Andrey Chernov , Max Laier , freebsd-current@freebsd.org References: <20070313121106.GA96293@nagual.pp.ru> <200703131333.11692.max@love2party.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+HP7ph2BbKc20aGI" Content-Disposition: inline In-Reply-To: <200703131333.11692.max@love2party.net> User-Agent: Mutt/1.5.14 (2007-02-12) Cc: freebsd-current@freebsd.org Subject: Re: Bad gcc -O optimization cause core dump. What to do? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Mar 2007 13:08:08 -0000 --+HP7ph2BbKc20aGI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Mar 13, 2007 at 01:33:01PM +0100, Max Laier wrote: > > It calls "puts(NULL)" with core dump. > > It means "printf("%s\n", NULL)" is overoptimized. > > BTW, things like "printf("1%s\n", NULL)" are not overoptimized. > > Any ideas? Is it right or needs to be fixed? >=20 > See: http://www.ciselant.de/projects/gcc_printf/gcc_printf.html 3.1 So, treated as "not a bug" by gcc people.=20 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D15685 Sigh. It means printf-coding requires now intrinsic knowledge of gcc=20 implementation details because our printf confusingly prints "(null)" too. Convert printf back to segfault? ;) --=20 http://ache.pp.ru/ --+HP7ph2BbKc20aGI Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.3 (FreeBSD) iD8DBQFF9qI1Vg5YK5ZEdN0RAl82AJ95U7KdgA+82lri/Crrsm3jBAaSFACfcEs9 1B4IJqF0sTeSFMyiXNiRum8= =8sZS -----END PGP SIGNATURE----- --+HP7ph2BbKc20aGI-- From owner-freebsd-current@FreeBSD.ORG Tue Mar 13 13:16:05 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 637AE16A402; Tue, 13 Mar 2007 13:16:05 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.174]) by mx1.freebsd.org (Postfix) with ESMTP id E1FB313C483; Tue, 13 Mar 2007 13:16:04 +0000 (UTC) (envelope-from max@love2party.net) Received: from [88.66.11.22] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu5) with ESMTP (Nemesis), id 0ML25U-1HR6qz1iWi-00070a; Tue, 13 Mar 2007 14:15:56 +0100 From: Max Laier Organization: FreeBSD To: freebsd-current@freebsd.org Date: Tue, 13 Mar 2007 14:15:38 +0100 User-Agent: KMail/1.9.5 References: <20070313121106.GA96293@nagual.pp.ru> <20070313123717.GU58523@codelabs.ru> In-Reply-To: <20070313123717.GU58523@codelabs.ru> X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2353553.gtTboZbrzb"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200703131415.45709.max@love2party.net> X-Provags-ID: V01U2FsdGVkX1/MttCl7XZRxN5JIM4PTQ/cZzhS+X/T5Q47ipW 8JcVc3X75YQwLQT/lkvMjv3Tq8mDf+RyS6ksvWn+0SWtgP/zgk PVErV7ND0tjsvBkonWsEg== Cc: Subject: Re: Bad gcc -O optimization cause core dump. What to do? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Mar 2007 13:16:05 -0000 --nextPart2353553.gtTboZbrzb Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Tuesday 13 March 2007 13:37, Eygene Ryabinkin wrote: > Andrey, good day. > > > It calls "puts(NULL)" with core dump. > > It means "printf("%s\n", NULL)" is overoptimized. > > BTW, things like "printf("1%s\n", NULL)" are not overoptimized. > > Yes, it is in the gcc/builtins.c::expand_builtin_printf(). Currently > it only handles "%s" and "%c". > > > Any ideas? Is it right or needs to be fixed? > > It is definitely not right, since it produces the bad code. > And there are no compilation-time checks that can say for > sure will the argument for the "%s" be NULL: This is simply a programming error. Just because the function is called=20 printf doesn't make it right. It's nice that the libc's printf does all=20 these neat tricks, but it's also expensive (See the link I posted=20 earlier). According to the printf(3) manpage: s The char * argument is expected to be a pointer to an array of character type (pointer to a string). Characters from the array are written up to (but not including) a terminating NUL charac- ter; if a precision is specified, no more than the number speci- fied are written. If a precision is given, no null character need be present; if the precision is not specified, or is greater than the size of the array, the array must contain a terminating NUL character. And I fail to see how "NULL" is a valid pointer to an array of character=20 type. This is C after all. > ----- > $ cat 1.c > #include > > int main(void) > { > void *ptr =3D NULL; > func(ptr); > } > > int func(void *ptr) > { > printf("%s\n", ptr); > } > > :: rea@codelabs : 15:31:43 : ~/xlam > > $ cat 1.s > .file "1.c" > .text > .p2align 2,,3 > .globl main > .type main, @function > main: > pushl %ebp > movl %esp, %ebp > subl $8, %esp > andl $-16, %esp > subl $28, %esp > pushl $0 > call func > leave > ret > .size main, .-main > .p2align 2,,3 > .globl func > .type func, @function > func: > pushl %ebp > movl %esp, %ebp > subl $20, %esp > pushl 8(%ebp) > call puts > leave > ret > .size func, .-func > ----- > The possible way to proceed with this optimization is to have the > 'puts', but to enable runtime check for the NULL value. > > I see the following definition for the fn_puts in builtins.def: > ----- > DEF_EXT_LIB_BUILTIN (BUILT_IN_PUTS_UNLOCKED, "puts_unlocked", > BT_FN_INT_CONST_STRING, ATTR_NOTHROW_NONNULL_1) ----- > The ATTR_NOTHROW_NONNULL_1 makes me think that not all is lost and > something can be done with the NULL pointer. I am not very familiar > with gcc internals, but I will try to see if something can be changed. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart2353553.gtTboZbrzb Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQBF9qQBXyyEoT62BG0RAqONAJwOCMP+nq0RW+AzM/dr2dvZltMc0wCbBIpF eqzpU0iXc9xBu6h9qPJyuT8= =vBHA -----END PGP SIGNATURE----- --nextPart2353553.gtTboZbrzb-- From owner-freebsd-current@FreeBSD.ORG Tue Mar 13 13:34:06 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B014316A402; Tue, 13 Mar 2007 13:34:06 +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 6515913C483; Tue, 13 Mar 2007 13:34:06 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from codelabs.ru (pobox.codelabs.ru [144.206.177.45]) by pobox.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1HR78f-000Pkd-0p; Tue, 13 Mar 2007 16:34:05 +0300 Date: Tue, 13 Mar 2007 16:34:00 +0300 From: Eygene Ryabinkin To: Max Laier Message-ID: <20070313133400.GW58523@codelabs.ru> References: <20070313121106.GA96293@nagual.pp.ru> <20070313123717.GU58523@codelabs.ru> <200703131415.45709.max@love2party.net> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <200703131415.45709.max@love2party.net> Sender: rea-fbsd@codelabs.ru X-Spam-Status: No, score=-3.4 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_00 Cc: freebsd-current@freebsd.org Subject: Re: Bad gcc -O optimization cause core dump. What to do? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Mar 2007 13:34:06 -0000 Slightly off-topic, sorry. > > > Any ideas? Is it right or needs to be fixed? > > > > It is definitely not right, since it produces the bad code. > > And there are no compilation-time checks that can say for > > sure will the argument for the "%s" be NULL: > > This is simply a programming error. Just because the function is called > printf doesn't make it right. It's nice that the libc's printf does all > these neat tricks, but it's also expensive (See the link I posted > earlier). According to the printf(3) manpage: > > s The char * argument is expected to be a pointer to an array of > character type (pointer to a string). Characters from the array > are written up to (but not including) a terminating NUL charac- > ter; if a precision is specified, no more than the number speci- > fied are written. If a precision is given, no null character > need be present; if the precision is not specified, or is greater > than the size of the array, the array must contain a terminating > NUL character. > > And I fail to see how "NULL" is a valid pointer to an array of character > type. This is C after all. In linux there were times (in 2.6 kernel) when mmap was able to return NULL as the handle to a perfectly valid memory area. So NULL is sometimes a good pointer. But it is not our case, so this was off-topic, just for the curiosity. I just wanted to point out that the familiar behaviour of printf() can be restored with the -fno-builtin-printf flag. -- Eygene From owner-freebsd-current@FreeBSD.ORG Tue Mar 13 13:38:38 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.ORG Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5E52216A404; Tue, 13 Mar 2007 13:38:38 +0000 (UTC) (envelope-from rnsanchez@wait4.org) Received: from sumo.dreamhost.com (sumo.dreamhost.com [66.33.216.29]) by mx1.freebsd.org (Postfix) with ESMTP id 3AC9D13C44B; Tue, 13 Mar 2007 13:38:38 +0000 (UTC) (envelope-from rnsanchez@wait4.org) Received: from spunkymail-a5.g.dreamhost.com (sd-green-bigip-74.dreamhost.com [208.97.132.74]) by sumo.dreamhost.com (Postfix) with ESMTP id A47EF17C972; Tue, 13 Mar 2007 06:13:19 -0700 (PDT) Received: from sauron.lan.box (unknown [200.180.160.204]) by spunkymail-a5.g.dreamhost.com (Postfix) with ESMTP id 0BCAA14D6B4; Tue, 13 Mar 2007 06:13:16 -0700 (PDT) Date: Tue, 13 Mar 2007 10:13:12 -0300 From: Ricardo Nabinger Sanchez To: Andrey Chernov Message-Id: <20070313101312.71d35c32.rnsanchez@wait4.org> In-Reply-To: <20070313121106.GA96293@nagual.pp.ru> References: <20070313121106.GA96293@nagual.pp.ru> Organization: SYS_WAIT4 X-Mailer: Sylpheed 2.4.0beta4 (GTK+ 2.10.9; i386-unknown-freebsd6.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-bugs@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: Bad gcc -O optimization cause core dump. What to do? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Mar 2007 13:38:38 -0000 On Tue, 13 Mar 2007 15:11:07 +0300 Andrey Chernov wrote: > cc -O -S a.c > .file "a.c" > .text > .p2align 2,,3 > .globl main > .type main, @function > main: > pushl %ebp > movl %esp, %ebp > subl $8, %esp > andl $-16, %esp > subl $28, %esp > pushl $0 > call puts > leave > ret > .size main, .-main > .ident "GCC: (GNU) 3.4.6 [FreeBSD] 20060825" Confirmed on FreeBSD-6.1 RELEASE: .file "bla.c" .text .p2align 2,,3 .globl main .type main, @function main: pushl %ebp movl %esp, %ebp subl $8, %esp andl $-16, %esp subl $28, %esp pushl $0 call puts leave ret .size main, .-main .ident "GCC: (GNU) 3.4.4 [FreeBSD] 20050518" > It calls "puts(NULL)" with core dump. > It means "printf("%s\n", NULL)" is overoptimized. > BTW, things like "printf("1%s\n", NULL)" are not overoptimized. > Any ideas? Is it right or needs to be fixed? Given that this is not what the user asked (replacing printf with puts), I consider this a bug. GCC made its assumption, and it was incorrect--it's not user's fault. -- Ricardo Nabinger Sanchez Powered by FreeBSD "Left to themselves, things tend to go from bad to worse." From owner-freebsd-current@FreeBSD.ORG Tue Mar 13 13:41:27 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B05CD16A401 for ; Tue, 13 Mar 2007 13:41:27 +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 6D0B413C46E for ; Tue, 13 Mar 2007 13:41:27 +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 BA7C52095; Tue, 13 Mar 2007 14:41:20 +0100 (CET) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: 0.0/3.0 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on tim.des.no Received: from dwp.des.no (des.no [80.203.243.180]) by tim.des.no (Postfix) with ESMTP id A6DF72085; Tue, 13 Mar 2007 14:41:20 +0100 (CET) Received: by dwp.des.no (Postfix, from userid 1001) id 8D936B88E; Tue, 13 Mar 2007 14:41:20 +0100 (CET) From: des@des.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) To: Julian Elischer References: <45F388D4.2080900@elischer.org> <45F45172.8070601@elischer.org> Date: Tue, 13 Mar 2007 14:41:20 +0100 In-Reply-To: <45F45172.8070601@elischer.org> (Julian Elischer's message of "Sun, 11 Mar 2007 11:58:58 -0700") Message-ID: <86r6rt6z27.fsf@dwp.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Current Subject: Re: netstat wierdness? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Mar 2007 13:41:27 -0000 Julian Elischer writes: > answering myself.. > comes from having options LOCK_PROFILING in my kernel. > adding the same to /etc/make.conf and recompiling netstat and libkvm help= ed. > (not sure if both are needed) This is very bad. LOCK_PROFILING should have no visible effect on userland. That is precisely what xinpcb, xunpcb, xtcpcb etc. are for: to isolate userland from kernel structures. They should not contain any locks or anything else which would be affected by LOCK_PROFILING or other kernel options. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Tue Mar 13 13:55:48 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 20AF316A507; Tue, 13 Mar 2007 13:55:48 +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 B649813C4BD; Tue, 13 Mar 2007 13:55:34 +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 87118208C; Tue, 13 Mar 2007 14:23:53 +0100 (CET) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: 0.0/3.0 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on tim.des.no Received: from dwp.des.no (des.no [80.203.243.180]) by tim.des.no (Postfix) with ESMTP id 6CA8E2089; Tue, 13 Mar 2007 14:23:53 +0100 (CET) Received: by dwp.des.no (Postfix, from userid 1001) id 55701B88E; Tue, 13 Mar 2007 14:23:53 +0100 (CET) From: des@des.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) To: Andrey Chernov References: <20070313121106.GA96293@nagual.pp.ru> Date: Tue, 13 Mar 2007 14:23:53 +0100 In-Reply-To: <20070313121106.GA96293@nagual.pp.ru> (Andrey Chernov's message of "Tue, 13 Mar 2007 15:11:07 +0300") Message-ID: <86veh56zva.fsf@dwp.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: current@freebsd.org Subject: Re: Bad gcc -O optimization cause core dump. What to do? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Mar 2007 13:55:48 -0000 Andrey Chernov writes: > Copy the segment below to the file a.c > ---------------------- cut me here --------------------- > #include > > main() { > printf("%s\n", NULL); > } > ---------------------- cut me here --------------------- > [...] > It calls "puts(NULL)" with core dump. > It means "printf("%s\n", NULL)" is overoptimized. > BTW, things like "printf("1%s\n", NULL)" are not overoptimized. > Any ideas? Is it right or needs to be fixed? The behaviour of printf("%s\n", NULL) is undefined. GCC is perfectly within its rights to translate it into something that dumps core (or causes your disk to crash, your monitor to explode, your dog to die of a venereal disease, and demons to fly out of your nose) Specifically, the C standard (=A77.19.6.1) requires the argument that corresponds to %s to be a pointer to "the initial element of an array of character type", which NULL is not. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Tue Mar 13 13:05:34 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 10D0816A402; Tue, 13 Mar 2007 13:05:34 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout1.pacific.net.au (mailout1-3.pacific.net.au [61.8.2.210]) by mx1.freebsd.org (Postfix) with ESMTP id CA8DE13C455; Tue, 13 Mar 2007 13:05:33 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.2.162]) by mailout1.pacific.net.au (Postfix) with ESMTP id 62D025A042E; Wed, 14 Mar 2007 00:05:32 +1100 (EST) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailproxy1.pacific.net.au (Postfix) with ESMTP id 62C978C05; Wed, 14 Mar 2007 00:05:31 +1100 (EST) Date: Wed, 14 Mar 2007 00:05:29 +1100 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Andrey Chernov In-Reply-To: <20070313121106.GA96293@nagual.pp.ru> Message-ID: <20070314000017.Y52372@delplex.bde.org> References: <20070313121106.GA96293@nagual.pp.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Tue, 13 Mar 2007 14:14:25 +0000 Cc: bugs@freebsd.org, ache@nagual.pp.ru, current@freebsd.org Subject: Re: Bad gcc -O optimization cause core dump. What to do? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Mar 2007 13:05:34 -0000 On Tue, 13 Mar 2007, Andrey Chernov wrote: > Copy the segment below to the file a.c > ---------------------- cut me here --------------------- > #include > > main() { > printf("%s\n", NULL); > } > ---------------------- cut me here --------------------- > It calls "puts(NULL)" with core dump. > It means "printf("%s\n", NULL)" is overoptimized. > BTW, things like "printf("1%s\n", NULL)" are not overoptimized. > Any ideas? Is it right or needs to be fixed? This happens with gcc-3.4.6 and 4.2 but not with 3.3.3. It also happens if NULL is replaced by a variable containing a null pointer. The case of a literal NULL should probably be an error at compile time (__nonnull() doesn't apply to printf() but the compiler could detect this error when it optimizes to use puts()). This is not wrong, since the null pointer gives undefined behaviour, but it breaks the normal undefined behaviour of printing "(null)". Bruce From owner-freebsd-current@FreeBSD.ORG Tue Mar 13 14:18:06 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F1DD416A403; Tue, 13 Mar 2007 14:18:06 +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 A6E7313C45B; Tue, 13 Mar 2007 14:18:06 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from codelabs.ru (pobox.codelabs.ru [144.206.177.45]) by pobox.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1HR7pF-000PoN-4D; Tue, 13 Mar 2007 17:18:05 +0300 Date: Tue, 13 Mar 2007 17:18:00 +0300 From: Eygene Ryabinkin To: freebsd-current@freebsd.org Message-ID: <20070313141800.GA99047@codelabs.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Sender: rea-fbsd@codelabs.ru X-Spam-Status: No, score=-2.1 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_50 Cc: marius@freebsd.org, cognet@freebsd.org Subject: Can someone look at the kern/106645: uart device description X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Mar 2007 14:18:07 -0000 Good day. Could someone, please, look into the kern/106645: it is rather old and the fix is simple enough. Marcel Moolenar once answered me that he will look into this, but he seems to be busy now. Thank you. -- Eygene From owner-freebsd-current@FreeBSD.ORG Tue Mar 13 14:38:36 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.ORG Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 690C116A401; Tue, 13 Mar 2007 14:38:36 +0000 (UTC) (envelope-from mux@freebsd.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 4CEB713C448; Tue, 13 Mar 2007 14:38:36 +0000 (UTC) (envelope-from mux@freebsd.org) Received: by elvis.mu.org (Postfix, from userid 1920) id C0E021A4D88; Tue, 13 Mar 2007 07:06:32 -0700 (PDT) Date: Tue, 13 Mar 2007 15:06:32 +0100 From: Maxime Henrion To: Ricardo Nabinger Sanchez Message-ID: <20070313140632.GK65356@elvis.mu.org> References: <20070313121106.GA96293@nagual.pp.ru> <20070313101312.71d35c32.rnsanchez@wait4.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070313101312.71d35c32.rnsanchez@wait4.org> User-Agent: Mutt/1.4.2.2i Cc: freebsd-bugs@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: Bad gcc -O optimization cause core dump. What to do? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Mar 2007 14:38:36 -0000 Ricardo Nabinger Sanchez wrote: > On Tue, 13 Mar 2007 15:11:07 +0300 > Andrey Chernov wrote: > > > cc -O -S a.c > > .file "a.c" > > .text > > .p2align 2,,3 > > .globl main > > .type main, @function > > main: > > pushl %ebp > > movl %esp, %ebp > > subl $8, %esp > > andl $-16, %esp > > subl $28, %esp > > pushl $0 > > call puts > > leave > > ret > > .size main, .-main > > .ident "GCC: (GNU) 3.4.6 [FreeBSD] 20060825" > > Confirmed on FreeBSD-6.1 RELEASE: > > .file "bla.c" > .text > .p2align 2,,3 > .globl main > .type main, @function > main: > pushl %ebp > movl %esp, %ebp > subl $8, %esp > andl $-16, %esp > subl $28, %esp > pushl $0 > call puts > leave > ret > .size main, .-main > .ident "GCC: (GNU) 3.4.4 [FreeBSD] 20050518" > > > It calls "puts(NULL)" with core dump. > > It means "printf("%s\n", NULL)" is overoptimized. > > BTW, things like "printf("1%s\n", NULL)" are not overoptimized. > > Any ideas? Is it right or needs to be fixed? > > Given that this is not what the user asked (replacing printf with puts), I > consider this a bug. GCC made its assumption, and it was incorrect--it's not > user's fault. GCC can do whatever it wants here, even printing "foobar42", because the C standard says that passing a NULL pointer to a %s format will yield undefined behaviour. It *is* user's fault to have passed NULL to printf() in the first place. So, while we could argue that GCC's behaviour here is useless, annoying, etc, this just can't be called a bug in GCC. As a side note, these "optimizations" are in place since a *long* time now. Cheers, Maxime From owner-freebsd-current@FreeBSD.ORG Tue Mar 13 15:49:43 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1C62A16A403 for ; Tue, 13 Mar 2007 15:49:43 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from cs1.cs.huji.ac.il (cs1.cs.huji.ac.il [132.65.16.10]) by mx1.freebsd.org (Postfix) with ESMTP id BE9CB13C44B for ; Tue, 13 Mar 2007 15:49:42 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by cs1.cs.huji.ac.il with esmtp id 1HR9Fs-000CoX-Jj; Tue, 13 Mar 2007 17:49:40 +0200 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: freebsd-current@freebsd.org In-reply-to: Your message of Tue, 13 Mar 2007 14:02:43 +0200 . Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 13 Mar 2007 17:49:40 +0200 From: Danny Braniss Message-ID: Cc: pyunyh@gmail.com Subject: Re: nfe/PXE problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2007 15:49:43 -0000 > > On Tue, Mar 13, 2007 at 09:10:38AM +0200, Danny Braniss wrote: > > > > > > > well, I can PXE boot this box if I use an fxp NIC, with the nfe I tracked the > > > > problem > > > > to sys/nfsclient/nfs_diskless, where in nfs_setup_diskless(void) > > > > it does not find the nfe interface, ie, something does not match, but the > > > > interface > > > > was detected!. > > > > i'll try and do some more debugging. > > > > > > > ok, I found the problem, in nfs_diskless.c nfs_setup_diskless(), > > > there is a loop to search for the interface that was used to boot from, > > > and no match is found because the hadrware ethernet address > > > in the nfe is in the wrong byte order! and so the bcmp(...) fails. > > > > Good catch! > > > > > Interestingly, if booting NOT via PXE the Ethernet address is OK! > > > > > > nfe0: port 0xdc00-0xdc07 mem > > > 0xfe02c000-0xfe02cfff irq 22 at device 20.0 on pci0 > > > nfe0: Ethernet address: 00:18:f3:a9:6c:57 > > > and via PXE: > > > nfe0: Ethernet address: 57:6c:a9:f3:18:00 > > > > > > can someone with the right knowledge fix this? > > > > > > > AFAIK there is no known way to get an ethernet address via EEPROM on > > NVIDIA NIC so nfe(4) reads specific address registers to get ethernet > > address as a workaround. The address registers are filled > > automatically by hardware after hardware reset. This type of > > acquisition of ethernet address is *NOT* correct way as it could get > > a fake etherent address since adiministor can program other ethernet > > address into the NIC.(e.g. ifconfig(8) can change ethernet address.) > > Therefore nfe(4) is very careful to save original ethernet address > > in device attach phase and restores the ethernet address at device > > detach time. > > To make matters worse, it seems that ethernet address in NVIDIA NIC > > is loaded backwards into registers so nfe(4) corrects it in > > nfe_init_locked(). However, it seems PXE code does not do necessary > > swapping for ethernet address and does not restore original MAC > > address in the end of PXE phase so the NIC will have bogusly > > programmed MAC address. When kernel boots and nfe(4) is attached it > > will load the bogus ethernet address which was already programmed by > > PXE. If /etc/start_if.nfe0 is honored in diskless boot you can override > > the ethernet address to use the same ethernet address as PXE did. > > > > Even if there is a way to get an ethernet address from EEPROM, PXE > > should be fixed first since it uses bogus ethernet address in booting > > stage. If I encounter the same situation I would contact vendor for > > updated PXE image for the NVIDIA NIC. If that is not available I think > > the only remaining option would be adding a new tunable to swap the > > ethernet address. > > > > I'm not familiar with PXE and I din't use PXE for a long time so I > > could be completely wrong. > > not completely :-) > the DHCP/PXE boot works with the 'correct ethernet address'. > this is because I use the static/registered mac, and so a bogus mac address > can't get past the DHCP/PXE stage. > so, the PXE is using the correct mac address. > I can't use /etc/... because of the horse-cart problem, it's booting > diskless, and the 'disk' is nfs readable via the NIC, but the NIC is not > working > > the question now, is to see if the nfe driver can check if it was > used by the PXE, and flip the address. or have NVIDIA comeup with > a patch ... new twist to the Nvidia saga: the problem (of the inverted mac) happens with the latest bios, a previous version is ok - unfourtunately, it seems impossible to downgrade. danny From owner-freebsd-current@FreeBSD.ORG Tue Mar 13 16:22:04 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.ORG Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DAB6B16A40B; Tue, 13 Mar 2007 16:22:04 +0000 (UTC) (envelope-from rnsanchez@wait4.org) Received: from spunkymail-a11.g.dreamhost.com (sd-green-bigip-207.dreamhost.com [208.97.132.207]) by mx1.freebsd.org (Postfix) with ESMTP id A7FC113C4C8; Tue, 13 Mar 2007 16:22:04 +0000 (UTC) (envelope-from rnsanchez@wait4.org) Received: from sauron.lan.box (unknown [200.180.163.93]) by spunkymail-a11.g.dreamhost.com (Postfix) with ESMTP id 6E949B7098; Tue, 13 Mar 2007 09:22:01 -0700 (PDT) Date: Tue, 13 Mar 2007 13:21:58 -0300 From: Ricardo Nabinger Sanchez To: Maxime Henrion Message-Id: <20070313132158.7368d186.rnsanchez@wait4.org> In-Reply-To: <20070313140632.GK65356@elvis.mu.org> References: <20070313121106.GA96293@nagual.pp.ru> <20070313101312.71d35c32.rnsanchez@wait4.org> <20070313140632.GK65356@elvis.mu.org> Organization: SYS_WAIT4 X-Mailer: Sylpheed 2.4.0beta4 (GTK+ 2.10.9; i386-unknown-freebsd6.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-bugs@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: Bad gcc -O optimization cause core dump. What to do? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Mar 2007 16:22:05 -0000 On Tue, 13 Mar 2007 15:06:32 +0100 Maxime Henrion wrote: > > Given that this is not what the user asked (replacing printf with puts), I > > consider this a bug. GCC made its assumption, and it was incorrect--it's > > not user's fault. > > GCC can do whatever it wants here, even printing "foobar42", because the > C standard says that passing a NULL pointer to a %s format will yield > undefined behaviour. It *is* user's fault to have passed NULL to > printf() in the first place. > > So, while we could argue that GCC's behaviour here is useless, annoying, > etc, this just can't be called a bug in GCC. As a side note, these > "optimizations" are in place since a *long* time now. ... Considered until now. :) Honestly, I wasn't aware of these specific issues (detail in the C standard + gcc builtin printf optimization), and that's surely _my_ fault, not gcc's. Sorry for the (useless) noise. Thank you (and DES) for pointing this out. -- Ricardo Nabinger Sanchez Powered by FreeBSD "Left to themselves, things tend to go from bad to worse." From owner-freebsd-current@FreeBSD.ORG Tue Mar 13 16:45:24 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AFA9716A404 for ; Tue, 13 Mar 2007 16:45:24 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 5F91E13C465 for ; Tue, 13 Mar 2007 16:45:23 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from root by ciao.gmane.org with local (Exim 4.43) id 1HRA7S-0002EA-PY for freebsd-current@freebsd.org; Tue, 13 Mar 2007 17:45:03 +0100 Received: from 87-196-92-92.net.novis.pt ([87.196.92.92]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 13 Mar 2007 17:45:02 +0100 Received: from rpaulo by 87-196-92-92.net.novis.pt with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 13 Mar 2007 17:45:02 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Rui Paulo Date: Tue, 13 Mar 2007 16:35:02 +0000 Lines: 29 Message-ID: <45F6D2B6.80107@fnop.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org Cc: freebsd-current@freebsd.org X-Gmane-NNTP-Posting-Host: 87-196-92-92.net.novis.pt User-Agent: Thunderbird 2.0b2 (Macintosh/20070116) In-Reply-To: Sender: news Subject: Re: March -Current i386 Panic 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, 13 Mar 2007 16:45:24 -0000 Gary Suggett wrote: > Current 200702 runs and loads perfect on this machine, but can't say > the same for the newest March snapshot, checksum okay. Booting up will > get end up with the following message at the end, right as the blue > screen that says probing for devices appears. > > BARF 170 <105 > panic: Going nowhere without my init! > cpuid = 0 > KDB: enter: panic > [thread pid 1 tid 100007] > Stopped at kdb_enter+0x2b: nop > db> > > On booting safe mode, the error gets this far. > > pci0: at device 31.3 (no driver attached) > panic: vm_fault: fault on nofault entry > addr: c000b000 > cpuid = 0 > KDB: enter: panic > [thread pid 0 tid 0] > Stopped at kdb_enter+0x2b: nop > > Like I said, the machine runs fine on the February snapshot, but won't > boot on March. It's an i686 Intel pentium D 915 processor, so dual > core, 64 bit, in case that throws anything off. Same problem on a white Macbook Core Duo, 2.0Ghz. From owner-freebsd-current@FreeBSD.ORG Tue Mar 13 16:48:41 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 03AF216A407 for ; Tue, 13 Mar 2007 16:48:41 +0000 (UTC) (envelope-from mjacob@freebsd.org) Received: from ns1.feral.com (ns1.feral.com [192.67.166.1]) by mx1.freebsd.org (Postfix) with ESMTP id C5B7413C48C for ; Tue, 13 Mar 2007 16:48:40 +0000 (UTC) (envelope-from mjacob@freebsd.org) Received: from ns1.feral.com (localhost [127.0.0.1]) by ns1.feral.com (8.13.8/8.13.8) with ESMTP id l2DGmQxR006169; Tue, 13 Mar 2007 08:48:34 -0800 (PST) (envelope-from mjacob@freebsd.org) Received: from localhost (mjacob@localhost) by ns1.feral.com (8.13.8/8.13.8/Submit) with ESMTP id l2DGmPTe006166; Tue, 13 Mar 2007 09:48:26 -0700 (PDT) (envelope-from mjacob@freebsd.org) X-Authentication-Warning: ns1.feral.com: mjacob owned process doing -bs Date: Tue, 13 Mar 2007 09:48:25 -0700 (PDT) From: mjacob@freebsd.org To: Ivan Voras In-Reply-To: <45F5494B.9040104@fer.hr> Message-ID: <20070313094808.O6163@ns1.feral.com> References: <45F18183.7050405@FreeBSD.org> <45F182F2.10604@fer.hr> <70e8236f0703091240q65d45300u836121454d799c64@mail.gmail.com> <45F1C77C.8010103@fer.hr> <70e8236f0703091413o473db67fr451e3be49c44b025@mail.gmail.com> <20070309142918.V61513@ns1.feral.com> <45F1E27A.7090302@fer.hr> <20070309150157.L61706@ns1.feral.com> <45F1EB35.6020303@fer.hr> <20070309151901.L61859@ns1.feral.com> <45F1F08E.5030902@fer.hr> <20070309173523.P62771@ns1.feral.com> <45F5494B.9040104@fer.hr> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: MFC request: QLogic 24xx FibreChannel controller X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mjacob@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2007 16:48:41 -0000 On Mon, 12 Mar 2007, Ivan Voras wrote: > mjacob@freebsd.org wrote: > >>>> hint.isp.0.debug=0x105 >>>> >>>> set and send me the boot output, would you? > > Here's the entire dmesg. It looks like there are now 4 (!?) devices > pointing to the same FC "drive"? > yes. From owner-freebsd-current@FreeBSD.ORG Tue Mar 13 16:35:09 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BB20E16A400 for ; Tue, 13 Mar 2007 16:35:09 +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 2944913C44C for ; Tue, 13 Mar 2007 16:35:09 +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 43D7D6905A6; Tue, 13 Mar 2007 16:36:02 +0000 (WET) Received: by core.fnop.net (Postfix, from userid 1015) id 049F1690600; Tue, 13 Mar 2007 16:36:02 +0000 (WET) X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on core.fnop.net X-Spam-Level: X-Spam-Status: No, score=-0.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,RCVD_IN_SORBS_DUL autolearn=no version=3.1.7 Received: from epsilon.local (87-196-92-92.net.novis.pt [87.196.92.92]) by core.fnop.net (Postfix) with ESMTP id 3A9136905A6; Tue, 13 Mar 2007 16:35:58 +0000 (WET) Message-ID: <45F6D2B6.80107@fnop.net> Date: Tue, 13 Mar 2007 16:35:02 +0000 From: Rui Paulo User-Agent: Thunderbird 2.0b2 (Macintosh/20070116) MIME-Version: 1.0 Newsgroups: gmane.os.freebsd.current To: Gary Suggett References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Mailman-Approved-At: Tue, 13 Mar 2007 16:51:28 +0000 Cc: freebsd-current@freebsd.org Subject: Re: March -Current i386 Panic 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, 13 Mar 2007 16:35:09 -0000 Gary Suggett wrote: > Current 200702 runs and loads perfect on this machine, but can't say > the same for the newest March snapshot, checksum okay. Booting up will > get end up with the following message at the end, right as the blue > screen that says probing for devices appears. > > BARF 170 <105 > panic: Going nowhere without my init! > cpuid = 0 > KDB: enter: panic > [thread pid 1 tid 100007] > Stopped at kdb_enter+0x2b: nop > db> > > On booting safe mode, the error gets this far. > > pci0: at device 31.3 (no driver attached) > panic: vm_fault: fault on nofault entry > addr: c000b000 > cpuid = 0 > KDB: enter: panic > [thread pid 0 tid 0] > Stopped at kdb_enter+0x2b: nop > > Like I said, the machine runs fine on the February snapshot, but won't > boot on March. It's an i686 Intel pentium D 915 processor, so dual > core, 64 bit, in case that throws anything off. Same problem on a white Macbook Core Duo, 2.0Ghz. From owner-freebsd-current@FreeBSD.ORG Tue Mar 13 21:23:02 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A7F8016A402 for ; Tue, 13 Mar 2007 21:23:02 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outC.internet-mail-service.net (outC.internet-mail-service.net [216.240.47.226]) by mx1.freebsd.org (Postfix) with ESMTP id 8756613C468 for ; Tue, 13 Mar 2007 21:23:02 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Tue, 13 Mar 2007 13:56:02 -0700 Received: from [192.168.2.5] (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id D2E78128DAE; Tue, 13 Mar 2007 13:16:34 -0700 (PDT) Message-ID: <45F706A2.5020106@elischer.org> Date: Tue, 13 Mar 2007 13:16:34 -0700 From: Julian Elischer User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= References: <45F388D4.2080900@elischer.org> <45F45172.8070601@elischer.org> <86r6rt6z27.fsf@dwp.des.no> In-Reply-To: <86r6rt6z27.fsf@dwp.des.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: FreeBSD Current Subject: Re: netstat wierdness? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Mar 2007 21:23:02 -0000 Dag-Erling Smørgrav wrote: > Julian Elischer writes: >> answering myself.. >> comes from having options LOCK_PROFILING in my kernel. >> adding the same to /etc/make.conf and recompiling netstat and libkvm helped. >> (not sure if both are needed) > > This is very bad. LOCK_PROFILING should have no visible effect on > userland. That is precisely what xinpcb, xunpcb, xtcpcb etc. are for: > to isolate userland from kernel structures. They should not contain > any locks or anything else which would be affected by LOCK_PROFILING > or other kernel options. > > DES sockstat actually told me that all those were the wrong size, so apparently they change size too.(!?) I haven't gone to look at their definition yet, but as you say, it sounds like something was done wrong. From owner-freebsd-current@FreeBSD.ORG Tue Mar 13 21:48:24 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BB2E316A402; Tue, 13 Mar 2007 21:48:24 +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 9D83E13C44B; Tue, 13 Mar 2007 21:48:24 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id 6CE751A4D88; Tue, 13 Mar 2007 14:48:24 -0700 (PDT) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 9D0B95132C; Tue, 13 Mar 2007 17:48:23 -0400 (EDT) Date: Tue, 13 Mar 2007 17:48:23 -0400 From: Kris Kennaway To: Julian Elischer Message-ID: <20070313214823.GA13287@xor.obsecurity.org> References: <45F388D4.2080900@elischer.org> <45F45172.8070601@elischer.org> <86r6rt6z27.fsf@dwp.des.no> <45F706A2.5020106@elischer.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IJpNTDwzlM2Ie8A6" Content-Disposition: inline In-Reply-To: <45F706A2.5020106@elischer.org> User-Agent: Mutt/1.4.2.2i Cc: Dag-Erling Sm?rgrav , FreeBSD Current , kmacy@FreeBSD.org Subject: LOCK_PROFILING variant struct sizes (Re: netstat wierdness?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Mar 2007 21:48:24 -0000 --IJpNTDwzlM2Ie8A6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Mar 13, 2007 at 01:16:34PM -0700, Julian Elischer wrote: > Dag-Erling Sm?rgrav wrote: > >Julian Elischer writes: > >>answering myself.. > >>comes from having options LOCK_PROFILING in my kernel. > >>adding the same to /etc/make.conf and recompiling netstat and libkvm=20 > >>helped. > >>(not sure if both are needed) > > > >This is very bad. LOCK_PROFILING should have no visible effect on > >userland. That is precisely what xinpcb, xunpcb, xtcpcb etc. are for: > >to isolate userland from kernel structures. They should not contain > >any locks or anything else which would be affected by LOCK_PROFILING > >or other kernel options. > > > >DES >=20 > sockstat actually told me that all those were the wrong size, so apparent= ly > they change size too.(!?) >=20 > I haven't gone to look at their definition yet, but as you say, it sounds= =20 > like > something was done wrong. Kip made some changes to this recently, perhaps he can comment. Kris --IJpNTDwzlM2Ie8A6 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFF9xwnWry0BWjoQKURAsmCAKDYsPPZUq7UKQdfe9/PQW6nDfT2OgCfdukS KEuPUbFzun9jmpGB8T6XmCw= =BnUH -----END PGP SIGNATURE----- --IJpNTDwzlM2Ie8A6-- From owner-freebsd-current@FreeBSD.ORG Tue Mar 13 22:00:55 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6AFD116A405 for ; Tue, 13 Mar 2007 22:00:55 +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 03D5B13C44C for ; Tue, 13 Mar 2007 22:00:54 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 5D38A487FC; Tue, 13 Mar 2007 22:43:36 +0100 (CET) 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 338EE45683; Tue, 13 Mar 2007 22:43:31 +0100 (CET) Date: Tue, 13 Mar 2007 22:43:29 +0100 From: Pawel Jakub Dawidek To: Julian Elischer Message-ID: <20070313214329.GB3932@garage.freebsd.pl> References: <45F0D1F5.9010200@elischer.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+QahgC5+KEYLbs62" Content-Disposition: inline In-Reply-To: <45F0D1F5.9010200@elischer.org> X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 User-Agent: mutt-ng/devel-r804 (FreeBSD) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-2.6 required=3.0 tests=BAYES_00 autolearn=ham version=3.0.4 Cc: FreeBSD Current Subject: Re: proc lock might become an sx lock? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2007 22:00:55 -0000 --+QahgC5+KEYLbs62 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Mar 08, 2007 at 07:18:13PM -0800, Julian Elischer wrote: > currently the thread list in the process is protected by the sched lock. > for a process with a lot of threads this is probably not a good idea. > I experimented with making it protected by the proc loc, but the followin= g sort of thing happens a lot: >=20 > sx_slock(&allproc_lock); > FOREACH_PROC_IN_SYSTEM(p) { > mtx_lock_spin(&sched_lock); > FOREACH_THREAD_IN_PROC(p, td) { > ... > } > mtx_unlock_spin(&sched_lock); >=20 > Changing the protection of the thread list to use the proc lock would > replace the sched_lock with the proc lock, but..... > this has a problem.. the proc lock is a mutex and can therefore not be in= side the > allproc_lock. Why not? Acquiring sx lock first and then a mutex is fine. The other way around is illegal. > and in fact you get: >=20 > Trying to mount root from ufs:/dev/aacd0s1d > panic: blockable sleep lock (sleep mutex) process lock @ kern/sched_4bsd.= c:383 This is because it's order is hardcoded in subr_witness.c. Move: { "process lock", &lock_class_mtx_sleep }, a bit up and change lock_class_mtx_sleep to lock_class_sx. PS. I'm not familiar with schedulers, so I don't know if sched_lock can be replaced there. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --+QahgC5+KEYLbs62 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFF9xsBForvXbEpPzQRAhdLAKD0v/KvP8g57m2iBgHGTbb9r9RC/wCdETFJ D1jPgxen2Ik5CYh8Rd0c6Gg= =kdTY -----END PGP SIGNATURE----- --+QahgC5+KEYLbs62-- From owner-freebsd-current@FreeBSD.ORG Tue Mar 13 22:23:37 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F08FA16A401; Tue, 13 Mar 2007 22:23:37 +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 9B17013C44B; Tue, 13 Mar 2007 22:23:37 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.13.8/8.13.8) with ESMTP id l2DMNahq074813; Tue, 13 Mar 2007 18:23:36 -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 l2DMNaiT038419; Tue, 13 Mar 2007 18:23:36 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 180CE73039; Tue, 13 Mar 2007 17:23:36 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070313222336.180CE73039@freebsd-current.sentex.ca> Date: Tue, 13 Mar 2007 17:23:35 -0500 (EST) 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: Tue, 13 Mar 2007 22:23:38 -0000 TB --- 2007-03-13 21:14:23 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-03-13 21:14:23 - starting HEAD tinderbox run for i386/i386 TB --- 2007-03-13 21:14:23 - cleaning the object tree TB --- 2007-03-13 21:15:05 - checking out the source tree TB --- 2007-03-13 21:15:05 - cd /tinderbox/HEAD/i386/i386 TB --- 2007-03-13 21:15:05 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-03-13 21:23:28 - building world (CFLAGS=-O2 -pipe) TB --- 2007-03-13 21:23:28 - cd /src TB --- 2007-03-13 21:23:28 - /usr/bin/make -B buildworld >>> World build started on Tue Mar 13 21:23:29 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 Tue Mar 13 22:17:56 UTC 2007 TB --- 2007-03-13 22:17:56 - generating LINT kernel config TB --- 2007-03-13 22:17:56 - cd /src/sys/i386/conf TB --- 2007-03-13 22:17:56 - /usr/bin/make -B LINT TB --- 2007-03-13 22:17:56 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-03-13 22:17:56 - cd /src TB --- 2007-03-13 22:17:56 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Mar 13 22:17:57 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 -fformat-extensions -nostdinc -I- -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/ata/ata-isa.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 -fformat-extensions -nostdinc -I- -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/ata/ata-lowlevel.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 -fformat-extensions -nostdinc -I- -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/ata/ata-pci.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -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/ata/ata-queue.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 -fformat-extensions -nostdinc -I- -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/ata/ata-raid.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 -fformat-extensions -nostdinc -I- -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/ata/atapi-cam.c /src/sys/dev/ata/atapi-cam.c: In function `atapi_cb': /src/sys/dev/ata/atapi-cam.c:732: error: structure has no member named `saved_cmd' *** Error code 1 Stop in /obj/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-03-13 22:23:35 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-03-13 22:23:35 - ERROR: failed to build lint kernel TB --- 2007-03-13 22:23:35 - tinderbox aborted TB --- 0.80 user 2.90 system 4152.33 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Tue Mar 13 22:27:48 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 16A7D16A413 for ; Tue, 13 Mar 2007 22:27:48 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.233]) by mx1.freebsd.org (Postfix) with ESMTP id BF7A513C483 for ; Tue, 13 Mar 2007 22:27:47 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: by wx-out-0506.google.com with SMTP id s18so2101268wxc for ; Tue, 13 Mar 2007 15:27:47 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=iXEc9b/PsOkssLl8QjilEnycv8Uy9CN7aindsX9Ru6+OhVdTgUPFMGUY2Zkjy20PTbxdJHeHCkPER8uXA/6hCz2yWIGMq5sf9vepTvlH/FRr623rgFJ73gaL7xfCJs17ueH90Xgsf2o7aAuVpEN4yIVCDjuoZwS5W3JPrD2D6Ck= 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+X/twfzQoUMf6D2EeQ6G7JorskGwv1Ail5v4HWHG9dzYkWG4in+aNO6C6LX6q07HhxTFNZ2xuyajoQYq2mJ6yvN/JmprDsmrr57QU9Bm7zIIcwv42mYBwYlbFRnb0vidBDiAqWN1FcKme2zwDdTsvQVKn4bq2t5RdzNfHFTkKA= Received: by 10.90.52.2 with SMTP id z2mr6604946agz.1173824867083; Tue, 13 Mar 2007 15:27:47 -0700 (PDT) Received: by 10.90.25.1 with HTTP; Tue, 13 Mar 2007 15:27:46 -0700 (PDT) Message-ID: Date: Tue, 13 Mar 2007 14:27:46 -0800 From: "Kip Macy" To: "Kris Kennaway" In-Reply-To: <20070313214823.GA13287@xor.obsecurity.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <45F388D4.2080900@elischer.org> <45F45172.8070601@elischer.org> <86r6rt6z27.fsf@dwp.des.no> <45F706A2.5020106@elischer.org> <20070313214823.GA13287@xor.obsecurity.org> Cc: Dag-Erling Sm?rgrav , kmacy@freebsd.org, Julian Elischer , FreeBSD Current Subject: Re: LOCK_PROFILING variant struct sizes (Re: netstat wierdness?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Mar 2007 22:27:48 -0000 > Kip made some changes to this recently, perhaps he can comment. I haven't actually fixed this yet - but having a LOCK_PROFILING kernel panic with a non-LOCK_PROFILING kernel module is very annoying. I'm not sure how to handle, I'm debating about adding a pointer to the lock object and moving the lock profiling data elsewhere. -Kip From owner-freebsd-current@FreeBSD.ORG Tue Mar 13 23:17:01 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5E82F16A401; Tue, 13 Mar 2007 23:17:01 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 1BC2613C45A; Tue, 13 Mar 2007 23:17:00 +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.6/8.13.6) with ESMTP id l2DNH0UV041281; Tue, 13 Mar 2007 19:17:00 -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 l2DNH00u066638; Tue, 13 Mar 2007 19:17:00 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 0B11F73039; Tue, 13 Mar 2007 18:16:59 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070313231700.0B11F73039@freebsd-current.sentex.ca> Date: Tue, 13 Mar 2007 18:16:59 -0500 (EST) X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on clamscanner1 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: Tue, 13 Mar 2007 23:17:01 -0000 TB --- 2007-03-13 22:10:44 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-03-13 22:10:44 - starting HEAD tinderbox run for i386/pc98 TB --- 2007-03-13 22:10:44 - cleaning the object tree TB --- 2007-03-13 22:11:16 - checking out the source tree TB --- 2007-03-13 22:11:16 - cd /tinderbox/HEAD/i386/pc98 TB --- 2007-03-13 22:11:16 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-03-13 22:19:14 - building world (CFLAGS=-O2 -pipe) TB --- 2007-03-13 22:19:14 - cd /src TB --- 2007-03-13 22:19:14 - /usr/bin/make -B buildworld >>> World build started on Tue Mar 13 22:19: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 Tue Mar 13 23:12:51 UTC 2007 TB --- 2007-03-13 23:12:51 - generating LINT kernel config TB --- 2007-03-13 23:12:51 - cd /src/sys/pc98/conf TB --- 2007-03-13 23:12:51 - /usr/bin/make -B LINT TB --- 2007-03-13 23:12:51 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-03-13 23:12:51 - cd /src TB --- 2007-03-13 23:12:51 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Mar 13 23:12: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 [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -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/ata/ata-dma.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 -fformat-extensions -nostdinc -I- -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/ata/ata-isa.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 -fformat-extensions -nostdinc -I- -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/ata/ata-lowlevel.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 -fformat-extensions -nostdinc -I- -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/ata/ata-pci.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -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/ata/ata-queue.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 -fformat-extensions -nostdinc -I- -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/ata/atapi-cam.c /src/sys/dev/ata/atapi-cam.c: In function `atapi_cb': /src/sys/dev/ata/atapi-cam.c:732: error: structure has no member named `saved_cmd' *** Error code 1 Stop in /obj/pc98/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-03-13 23:16:59 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-03-13 23:16:59 - ERROR: failed to build lint kernel TB --- 2007-03-13 23:16:59 - tinderbox aborted TB --- 0.87 user 2.65 system 3975.38 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Tue Mar 13 23:52:09 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0AC7816A402; Tue, 13 Mar 2007 23:52:09 +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 CA9A113C45D; Tue, 13 Mar 2007 23:52:08 +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.6/8.13.6) with ESMTP id l2DNq7e9043261; Tue, 13 Mar 2007 19:52:07 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.8/8.13.8) with ESMTP id l2DNq72v058738; Tue, 13 Mar 2007 19:52:07 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 6EA3A73039; Tue, 13 Mar 2007 18:52:07 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070313235207.6EA3A73039@freebsd-current.sentex.ca> Date: Tue, 13 Mar 2007 18:52:07 -0500 (EST) X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on clamscanner2 X-Virus-Scanned: ClamAV version devel-20070108, clamav-milter version devel-111206 on clamscanner2 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: Tue, 13 Mar 2007 23:52:09 -0000 TB --- 2007-03-13 22:23:36 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-03-13 22:23:36 - starting HEAD tinderbox run for ia64/ia64 TB --- 2007-03-13 22:23:36 - cleaning the object tree TB --- 2007-03-13 22:24:04 - checking out the source tree TB --- 2007-03-13 22:24:04 - cd /tinderbox/HEAD/ia64/ia64 TB --- 2007-03-13 22:24:04 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-03-13 22:31:17 - building world (CFLAGS=-O2 -pipe) TB --- 2007-03-13 22:31:17 - cd /src TB --- 2007-03-13 22:31:17 - /usr/bin/make -B buildworld >>> World build started on Tue Mar 13 22:31:18 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 Tue Mar 13 23:46:51 UTC 2007 TB --- 2007-03-13 23:46:51 - generating LINT kernel config TB --- 2007-03-13 23:46:51 - cd /src/sys/ia64/conf TB --- 2007-03-13 23:46:51 - /usr/bin/make -B LINT TB --- 2007-03-13 23:46:51 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-03-13 23:46:51 - cd /src TB --- 2007-03-13 23:46:51 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Mar 13 23:46: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 [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -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 -mno-sdata -ffreestanding -Werror /src/sys/dev/ata/ata-isa.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 -fformat-extensions -nostdinc -I- -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 -mno-sdata -ffreestanding -Werror /src/sys/dev/ata/ata-lowlevel.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 -fformat-extensions -nostdinc -I- -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 -mno-sdata -ffreestanding -Werror /src/sys/dev/ata/ata-pci.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -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 -mno-sdata -ffreestanding -Werror /src/sys/dev/ata/ata-queue.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 -fformat-extensions -nostdinc -I- -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 -mno-sdata -ffreestanding -Werror /src/sys/dev/ata/ata-raid.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 -fformat-extensions -nostdinc -I- -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 -mno-sdata -ffreestanding -Werror /src/sys/dev/ata/atapi-cam.c /src/sys/dev/ata/atapi-cam.c: In function `atapi_cb': /src/sys/dev/ata/atapi-cam.c:732: error: structure has no member named `saved_cmd' *** Error code 1 Stop in /obj/ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-03-13 23:52:07 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-03-13 23:52:07 - ERROR: failed to build lint kernel TB --- 2007-03-13 23:52:07 - tinderbox aborted TB --- 0.64 user 2.52 system 5310.92 real http://tinderbox.des.no/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Wed Mar 14 00:08:03 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 89AEF16A40B for ; Wed, 14 Mar 2007 00:08:03 +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 43B2B13C4C9 for ; Wed, 14 Mar 2007 00:08:03 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Tue, 13 Mar 2007 16:41:02 -0700 Received: from [192.168.2.5] (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id BC750125EA6; Tue, 13 Mar 2007 16:59:35 -0700 (PDT) Message-ID: <45F73AE7.6010508@elischer.org> Date: Tue, 13 Mar 2007 16:59:35 -0700 From: Julian Elischer User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: Robert Watson References: <200703092241.l29Mf2Ds062856@repoman.freebsd.org> <200703121535.22140.jhb@freebsd.org> <20070312200345.GB5688@garage.freebsd.pl> <200703121618.41084.jhb@freebsd.org> <45F5E1F9.5090806@elischer.org> <20070313010309.Q25395@fledge.watson.org> In-Reply-To: <20070313010309.Q25395@fledge.watson.org> Content-Type: multipart/mixed; boundary="------------080405010508000104080807" Cc: Pawel Jakub Dawidek , current@freebsd.org Subject: [RFC] locking.9 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Mar 2007 00:08:03 -0000 This is a multi-part message in MIME format. --------------080405010508000104080807 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit resend to the right place with a corrected attachment. Robert Watson wrote: > > The idea of a locking(9) has been kicked around for a while, and its > time has definitely come. It would summarize the properties and cross > reference the man pages of the various primitives, and suggest a > preference and strategy for using them in new code vs. existing code, > etc. Distinguishing dimensions would include things like whether it is > sleepable, supports priority propagation, can be acquired in interrupt > context (a result of the prior two properties), whether it is fair, etc, > etc. And include stern warnings about not using lockmgr in new code :-). > > Robert N M Watson > Computer Laboratory > University of Cambridge ok so how about I commit this to get us started and the nroff and locking experts can take it from there. --------------080405010508000104080807 Content-Type: text/plain; x-mac-type="0"; x-mac-creator="0"; name="locking.9" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="locking.9" .\" .\" Copyright (c) 1998 Berkeley Software Design, Inc. All rights reserved. .\" .\" Redistribution and use in source and binary forms, with or without .\" modification, are permitted provided that the following conditions .\" are met: .\" 1. Redistributions of source code must retain the above copyright .\" notice, this list of conditions and the following disclaimer. .\" 2. Redistributions in binary form must reproduce the above copyright .\" notice, this list of conditions and the following disclaimer in the .\" documentation and/or other materials provided with the distribution. .\" 3. Berkeley Software Design Inc's name may not be used to endorse or .\" promote products derived from this software without specific prior .\" written permission. .\" .\" THIS SOFTWARE IS PROVIDED BY BERKELEY SOFTWARE DESIGN INC ``AS IS'' AND .\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE .\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE .\" ARE DISCLAIMED. IN NO EVENT SHALL BERKELEY SOFTWARE DESIGN INC BE LIABLE .\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL .\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS .\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) .\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT .\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY .\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF .\" SUCH DAMAGE. .\" .\" from BSDI $Id: mutex.4,v 1.1.2.3 1998/04/27 22:53:13 ewv Exp $ .\" $FreeBSD: src/share/man/man9/mutex.9,v 1.54 2007/03/09 22:41:01 jhb Exp $ .\" .Dd March 14, 2007 .Dt LOCKING 9 .Os .Sh NAME .Nm locking , .Nd kernel synchronization primitives .Sh SYNOPSIS All sorts of stuff to go here. .Pp .Sh DESCRIPTION The .Em FreeBSD kernel is written to run across multiple CPUs and as such requires several different sychronization primatives to allow the developers to safely access and manipulate the many data types required. .Pp These include: .Bl -enum .It Spin Mutexes .It Sleep Mutexes .It pool Mutexes .It Shared-Exclusive locks .It Reader-Writer locks .It Turnstyles .It Semaphores .It Condition variables .It Sleep/wakeup .It Giant .It Lockmanager locks .El .Pp The primnatives interact and have a number of rules regarding how they can and can not be combined. Ther eare too many for the average humanmind and they keep changing. (if you disagree, please write replacement text) :-) .Pp Some of these primatives may be used at the low (interrupt) level and some may not. .Pp There are strict ordering requirements and for some of the types this is checked using the .Xr witness 4 code. .Pp .Ss SPIN Mutexes Mutexes are the basic primative. You either hold it or you don't. If you don't own it then you just spin, waiting for teh holder (on another CPU) to release it. Hopefully they are doing something fast. You can not do anythign that deschedules the thread while you are holding a SPIN mutex. .Ss Sleep Mutexes Basically sleep (regular) mutexes will deschedule the thread if the mutex can not be acquired. As in spin mutexes, you either get it or you don't. You may call the .Xr sleep 9 call .Fn msleep or the new .Fn mtx_sleep variant. These will atomically drop the mutex and reacquire it as part of waking up. .Ss Pool Mutexes A variant of SLEEP mutexes where the allocation of the mutex is handled more by the system. .Ss Sx_locks Shared/exclusive locks are used to protect data that are read far more often than they are written. Mutexes are inherently more efficient than shared/exclusive locks, so shared/exclusive locks should be used prudently. A thread may hold a shared or exclusive lock on an .Em sx_lock lock while sleeping. As a result, an .Em sx_lockm lock may not be acquired while holding a mutex. Otherwise, if one thread slept while holding an .Em sx_lockm lock while another thread blocked on the same .Em sx_lockm lock after acquiring a mutex, then the second thread would effectively end up sleeping while holding a mutex, which is not allowed. .Ss Rw_locks Reader/writer locks allow shared access to protected data by multiple threads, or exclusive access by a single thread. The threads with shared access are known as .Em readers since they only read the protected data. A thread with exclusive access is known as a .Em writer since it can modify protected data. .Pp Although reader/writer locks look very similar to .Xr sx 9 locks, their usage pattern is different. Reader/writer locks can be treated as mutexes (see .Xr mutex 9 ) with shared/exclusive semantics. Unlike .Xr sx 9 , an .Em rw_lock can be locked while holding a non-spin mutex, and an .Em rw_lock cannot be held while sleeping. The .Em rw_lock locks have priority propagation like mutexes, but priority can be propagated only to an exclusive holder. This limitation comes from the fact that shared owners are anonymous. Another important property is that shared holders of .Em rw_lock can recurse, but exclusive locks are not allowed to recurse. .Ss Turnstyless Turnstiles are used to hold a queue of threads blocked on non-sleepable locks. Sleepable locks use condition variables to implement their queues. Turnstiles differ from a sleep queue in that turnstile queue's are assigned to a lock held by an owning thread. Thus, when one thread is enqueued onto a turnstile, it can lend its priority to the owning thread. .Ss Semaphores .Ss Condition variables Condition variables are used in conjunction with mutexes to wait for conditions to occur. A thread must hold the mutex before calling the .Fn cv_wait* , functions. When a thread waits on a condition, the mutex is atomically released before the thread is blocked, then reacquired before the function call returns. .Ss Giant Giant is a special instance of a sleep lock. it has several special characteristics. .Ss Sleep/wakeup The functions .Fn tsleep , .Fn msleep , .Fn msleep_spin , .Fn pause , .Fn wakeup , and .Fn wakeup_one handle event-based thread blocking. If a thread must wait for an external event, it is put to sleep by .Fn tsleep , .Fn msleep , .Fn msleep_spin , or .Fn pause . Threads may also wait using one of the locking primitive sleep routines .Xr mtx_sleep 9 , .Xr rw_sleep 9 , or .Xr sx_sleep 9 . .Pp The parameter .Fa chan is an arbitrary address that uniquely identifies the event on which the thread is being put to sleep. All threads sleeping on a single .Fa chan are woken up later by .Fn wakeup , often called from inside an interrupt routine, to indicate that the resource the thread was blocking on is available now. .Pp Several of the sleep functions including .Fn msleep , .Fn msleep_spin , and the locking primitive sleep routines specify an additional lock parameter. The lock will be released before sleeping and reacquired before the sleep routine returns. If .Fa priority includes the .Dv PDROP flag, then the lock will not be reacquired before returning. The lock is used to ensure that a condition can be checked atomically, and that the current thread can be suspended without missing a change to the condition, or an associated wakeup. In addition, all of the sleep routines will fully drop the .Va Giant mutex (even if recursed) while the thread is suspended and will reacquire the .Va Giant mutex before the function returns. .Pp .Ss lockmanager locks Largly deprecated. See the .Xr lock 9 page for more information. I don't know what the downsides are but I'm sure someone will fill in this part. .Sh Interaction tables. the following table shows what you can an d can not do if you hold one of the synchronisation primatives discussed here: (someone who knows what they are talking about should write this table) .Bl -column ".Ic You have: You want:" ".Xr sleep" ".Xr sc_lock" ".Xr rw_lock" -offset indent .It Xo .Em "You have: You want:" Ta Xr sleep Ta Xr sx_lock Ta Xr rw_lock .Xc .It Ic SPIN mutex Ta \&tough Ta \&tough Ta \&tough .It Ic Sleep mutex Ta \&ok Ta \&??? Ta \&??? .El .Sh SEE ALSO .Xr condvar 9 , .Xr lock 9 .Xr mtx_pool 9 , .Xr rwlock 9 , .Xr sema 9 , .Xr sleep 9 , .Xr sx 9 .Xr LOCK_PROFILING 9 , .Xr WITNESS 9 , .Sh HISTORY These functions appeared in .Bsx 4.1 through .Fx 7.0 --------------080405010508000104080807-- From owner-freebsd-current@FreeBSD.ORG Wed Mar 14 00:26:31 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2C70416A400; Wed, 14 Mar 2007 00:26:31 +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 F042813C457; Wed, 14 Mar 2007 00:26:30 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.13.8/8.13.8) with ESMTP id l2E0QUuI082190; Tue, 13 Mar 2007 20:26:30 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.8/8.13.8) with ESMTP id l2E0QT8S043296; Tue, 13 Mar 2007 20:26:29 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id CB14C73039; Tue, 13 Mar 2007 19:26:29 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070314002629.CB14C73039@freebsd-current.sentex.ca> Date: Tue, 13 Mar 2007 19:26:29 -0500 (EST) X-Virus-Scanned: ClamAV version devel-20070108, clamav-milter version devel-111206 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: Wed, 14 Mar 2007 00:26:31 -0000 TB --- 2007-03-13 23:17:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-03-13 23:17:00 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2007-03-13 23:17:00 - cleaning the object tree TB --- 2007-03-13 23:17:29 - checking out the source tree TB --- 2007-03-13 23:17:29 - cd /tinderbox/HEAD/powerpc/powerpc TB --- 2007-03-13 23:17:29 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-03-13 23:24:38 - building world (CFLAGS=-O2 -pipe) TB --- 2007-03-13 23:24:38 - cd /src TB --- 2007-03-13 23:24:38 - /usr/bin/make -B buildworld >>> World build started on Tue Mar 13 23:24:39 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 Wed Mar 14 00:22:58 UTC 2007 TB --- 2007-03-14 00:22:58 - generating LINT kernel config TB --- 2007-03-14 00:22:58 - cd /src/sys/powerpc/conf TB --- 2007-03-14 00:22:58 - /usr/bin/make -B LINT TB --- 2007-03-14 00:22:58 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-03-14 00:22:58 - cd /src TB --- 2007-03-14 00:22:58 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Mar 14 00:22:59 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 -fformat-extensions -nostdinc -I- -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 -Werror /src/sys/dev/ata/ata-dma.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 -fformat-extensions -nostdinc -I- -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 -Werror /src/sys/dev/ata/ata-lowlevel.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 -fformat-extensions -nostdinc -I- -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 -Werror /src/sys/dev/ata/ata-pci.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -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 -Werror /src/sys/dev/ata/ata-queue.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 -fformat-extensions -nostdinc -I- -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 -Werror /src/sys/dev/ata/ata-raid.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 -fformat-extensions -nostdinc -I- -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 -Werror /src/sys/dev/ata/atapi-cam.c /src/sys/dev/ata/atapi-cam.c: In function `atapi_cb': /src/sys/dev/ata/atapi-cam.c:732: error: structure has no member named `saved_cmd' *** Error code 1 Stop in /obj/powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-03-14 00:26:29 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-03-14 00:26:29 - ERROR: failed to build lint kernel TB --- 2007-03-14 00:26:29 - tinderbox aborted TB --- 0.77 user 2.34 system 4169.29 real http://tinderbox.des.no/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Wed Mar 14 01:00:43 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3A22D16A400; Wed, 14 Mar 2007 01:00:43 +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 E060A13C4BA; Wed, 14 Mar 2007 01:00:42 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.13.8/8.13.8) with ESMTP id l2E10gIg084373; Tue, 13 Mar 2007 21:00:42 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.8/8.13.8) with ESMTP id l2E10gWh028398; Tue, 13 Mar 2007 21:00:42 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id D7ADB73039; Tue, 13 Mar 2007 20:00:41 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070314010041.D7ADB73039@freebsd-current.sentex.ca> Date: Tue, 13 Mar 2007 20:00:41 -0500 (EST) X-Virus-Scanned: ClamAV version devel-20070108, clamav-milter version devel-111206 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: Wed, 14 Mar 2007 01:00:43 -0000 TB --- 2007-03-13 23:52:07 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-03-13 23:52:07 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2007-03-13 23:52:07 - cleaning the object tree TB --- 2007-03-13 23:52:45 - checking out the source tree TB --- 2007-03-13 23:52:45 - cd /tinderbox/HEAD/sparc64/sparc64 TB --- 2007-03-13 23:52:45 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-03-14 00:00:52 - building world (CFLAGS=-O2 -pipe) TB --- 2007-03-14 00:00:52 - cd /src TB --- 2007-03-14 00:00:52 - /usr/bin/make -B buildworld >>> World build started on Wed Mar 14 00:00:53 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 Wed Mar 14 00:56:41 UTC 2007 TB --- 2007-03-14 00:56:41 - generating LINT kernel config TB --- 2007-03-14 00:56:41 - cd /src/sys/sparc64/conf TB --- 2007-03-14 00:56:41 - /usr/bin/make -B LINT TB --- 2007-03-14 00:56:41 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-03-14 00:56:41 - cd /src TB --- 2007-03-14 00:56:41 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Mar 14 00:56:41 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 -fformat-extensions -nostdinc -I- -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/ata/ata-isa.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 -fformat-extensions -nostdinc -I- -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/ata/ata-lowlevel.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 -fformat-extensions -nostdinc -I- -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/ata/ata-pci.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -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/ata/ata-queue.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 -fformat-extensions -nostdinc -I- -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/ata/ata-raid.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 -fformat-extensions -nostdinc -I- -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/ata/atapi-cam.c /src/sys/dev/ata/atapi-cam.c: In function `atapi_cb': /src/sys/dev/ata/atapi-cam.c:732: error: structure has no member named `saved_cmd' *** Error code 1 Stop in /obj/sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-03-14 01:00:41 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-03-14 01:00:41 - ERROR: failed to build lint kernel TB --- 2007-03-14 01:00:41 - tinderbox aborted TB --- 0.88 user 2.50 system 4113.99 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Wed Mar 14 01:29:19 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CFF8916A402; Wed, 14 Mar 2007 01:29:19 +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 9EA2F13C455; Wed, 14 Mar 2007 01:29:19 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.13.8/8.13.8) with ESMTP id l2E1TI9L086272; Tue, 13 Mar 2007 21:29:18 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.8/8.13.8) with ESMTP id l2E1TIci091260; Tue, 13 Mar 2007 21:29:18 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 6C86973039; Tue, 13 Mar 2007 20:29:18 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070314012918.6C86973039@freebsd-current.sentex.ca> Date: Tue, 13 Mar 2007 20:29:18 -0500 (EST) X-Virus-Scanned: ClamAV version devel-20070108, clamav-milter version devel-111206 on clamscanner2 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: Wed, 14 Mar 2007 01:29:20 -0000 TB --- 2007-03-14 00:26:30 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-03-14 00:26:30 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2007-03-14 00:26:30 - cleaning the object tree TB --- 2007-03-14 00:27:02 - checking out the source tree TB --- 2007-03-14 00:27:02 - cd /tinderbox/HEAD/sparc64/sun4v TB --- 2007-03-14 00:27:02 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-03-14 00:34:50 - building world (CFLAGS=-O2 -pipe) TB --- 2007-03-14 00:34:50 - cd /src TB --- 2007-03-14 00:34:50 - /usr/bin/make -B buildworld >>> World build started on Wed Mar 14 00:34:52 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 Wed Mar 14 01:25:42 UTC 2007 TB --- 2007-03-14 01:25:42 - generating LINT kernel config TB --- 2007-03-14 01:25:42 - cd /src/sys/sun4v/conf TB --- 2007-03-14 01:25:42 - /usr/bin/make -B LINT TB --- 2007-03-14 01:25:42 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-03-14 01:25:42 - cd /src TB --- 2007-03-14 01:25:42 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Mar 14 01:25:43 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 -fformat-extensions -nostdinc -I- -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/ata/ata-dma.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 -fformat-extensions -nostdinc -I- -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/ata/ata-lowlevel.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 -fformat-extensions -nostdinc -I- -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/ata/ata-pci.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -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/ata/ata-queue.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 -fformat-extensions -nostdinc -I- -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/ata/ata-raid.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 -fformat-extensions -nostdinc -I- -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/ata/atapi-cam.c /src/sys/dev/ata/atapi-cam.c: In function `atapi_cb': /src/sys/dev/ata/atapi-cam.c:732: error: structure has no member named `saved_cmd' *** Error code 1 Stop in /obj/sun4v/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-03-14 01:29:18 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-03-14 01:29:18 - ERROR: failed to build lint kernel TB --- 2007-03-14 01:29:18 - tinderbox aborted TB --- 0.74 user 2.13 system 3768.20 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From owner-freebsd-current@FreeBSD.ORG Wed Mar 14 03:05:06 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AED5116A403; Wed, 14 Mar 2007 03:05:06 +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 72D1E13C458; Wed, 14 Mar 2007 03:05:06 +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.6/8.13.6) with ESMTP id l2E355JW054012; Tue, 13 Mar 2007 23:05:05 -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 l2E354CN082983; Tue, 13 Mar 2007 23:05:05 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 2752B73039; Tue, 13 Mar 2007 22:05:04 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070314030504.2752B73039@freebsd-current.sentex.ca> Date: Tue, 13 Mar 2007 22:05:04 -0500 (EST) X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on clamscanner3 X-Virus-Scanned: ClamAV version devel-20070102, clamav-milter version devel-111206 on clamscanner4 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2007 03:05:06 -0000 TB --- 2007-03-14 01:30:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-03-14 01:30:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2007-03-14 01:30:00 - cleaning the object tree TB --- 2007-03-14 01:30:48 - checking out the source tree TB --- 2007-03-14 01:30:48 - cd /tinderbox/HEAD/amd64/amd64 TB --- 2007-03-14 01:30:48 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-03-14 01:39:54 - building world (CFLAGS=-O2 -pipe) TB --- 2007-03-14 01:39:54 - cd /src TB --- 2007-03-14 01:39:54 - /usr/bin/make -B buildworld >>> World build started on Wed Mar 14 01:39:57 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 Wed Mar 14 03:00:07 UTC 2007 TB --- 2007-03-14 03:00:07 - generating LINT kernel config TB --- 2007-03-14 03:00:07 - cd /src/sys/amd64/conf TB --- 2007-03-14 03:00:07 - /usr/bin/make -B LINT TB --- 2007-03-14 03:00:07 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-03-14 03:00:07 - cd /src TB --- 2007-03-14 03:00:07 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Mar 14 03:00:08 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 -fformat-extensions -nostdinc -I- -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/ata/ata-isa.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 -fformat-extensions -nostdinc -I- -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/ata/ata-lowlevel.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 -fformat-extensions -nostdinc -I- -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/ata/ata-pci.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -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/ata/ata-queue.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 -fformat-extensions -nostdinc -I- -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/ata/ata-raid.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 -fformat-extensions -nostdinc -I- -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/ata/atapi-cam.c /src/sys/dev/ata/atapi-cam.c: In function `atapi_cb': /src/sys/dev/ata/atapi-cam.c:732: error: structure has no member named `saved_cmd' *** Error code 1 Stop in /obj/amd64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-03-14 03:05:03 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-03-14 03:05:03 - ERROR: failed to build lint kernel TB --- 2007-03-14 03:05:03 - tinderbox aborted TB --- 1.06 user 3.48 system 5703.21 real http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Wed Mar 14 03:54:13 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 42DC016A405 for ; Wed, 14 Mar 2007 03:54:13 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outW.internet-mail-service.net (outW.internet-mail-service.net [216.240.47.246]) by mx1.freebsd.org (Postfix) with ESMTP id 2918613C457 for ; Wed, 14 Mar 2007 03:54:13 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Tue, 13 Mar 2007 20:27:10 -0700 Received: from [192.168.2.5] (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id CAD34125B99; Tue, 13 Mar 2007 20:54:11 -0700 (PDT) Message-ID: <45F771E2.9050709@elischer.org> Date: Tue, 13 Mar 2007 20:54:10 -0700 From: Julian Elischer User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: Julian Elischer References: <200703092241.l29Mf2Ds062856@repoman.freebsd.org> <200703121535.22140.jhb@freebsd.org> <20070312200345.GB5688@garage.freebsd.pl> <200703121618.41084.jhb@freebsd.org> <45F5E1F9.5090806@elischer.org> <20070313010309.Q25395@fledge.watson.org> <45F73AE7.6010508@elischer.org> In-Reply-To: <45F73AE7.6010508@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Pawel Jakub Dawidek , Robert Watson , current@freebsd.org Subject: Re: [RFC] locking.9 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Mar 2007 03:54:13 -0000 Julian Elischer wrote: > > ok so how about I commit this to get us started and the nroff and > locking experts can take it from there. > The first table I think may look like this (from quick reading.. but I may be wrong): The following table shows what you can and can not do if you hold one of the synchronisation primatives discussed here: (someone who knows what they are talking about should write this table) You have: You want: Spin_mtx Slp_mtx sx_lock rw_lock sleep SPIN mutex ok no no no no-3 Sleep mutex ok ok-1 no ok no-3 sx_lock ok no ?? no ok-4 rw_lock ok no no ok-2 no-3 *1 Recursion is defined per lock. lock order is important. *2 readers can recurse tough writers can not. lock order is important. *3 There are calls atomically release this primative when going to sleep and reacquire it on wakeup (e.g. mtx_sleep(), rw-sleep() and msleep_spin).() *4 One can also use sx_sleep() which atomically release this primative when going to sleep and reacquire it on wakeup. From owner-freebsd-current@FreeBSD.ORG Wed Mar 14 04:29:37 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9E1AA16A409; Wed, 14 Mar 2007 04:29: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 CD6FE13C45B; Wed, 14 Mar 2007 04:29:36 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 2BA00487F4; Wed, 14 Mar 2007 05:29:35 +0100 (CET) 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 D740D45685; Wed, 14 Mar 2007 05:29:29 +0100 (CET) Date: Wed, 14 Mar 2007 05:29:26 +0100 From: Pawel Jakub Dawidek To: Julian Elischer Message-ID: <20070314042926.GA6013@garage.freebsd.pl> References: <200703092241.l29Mf2Ds062856@repoman.freebsd.org> <200703121535.22140.jhb@freebsd.org> <20070312200345.GB5688@garage.freebsd.pl> <200703121618.41084.jhb@freebsd.org> <45F5E1F9.5090806@elischer.org> <20070313010309.Q25395@fledge.watson.org> <45F73AE7.6010508@elischer.org> <45F771E2.9050709@elischer.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ibTvN161/egqYuK8" Content-Disposition: inline In-Reply-To: <45F771E2.9050709@elischer.org> X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 User-Agent: mutt-ng/devel-r804 (FreeBSD) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-2.6 required=3.0 tests=BAYES_00 autolearn=ham version=3.0.4 Cc: Robert Watson , current@freebsd.org Subject: Re: [RFC] locking.9 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Mar 2007 04:29:37 -0000 --ibTvN161/egqYuK8 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Mar 13, 2007 at 08:54:10PM -0700, Julian Elischer wrote: > Julian Elischer wrote: >=20 > >ok so how about I commit this to get us started and the nroff and > >locking experts can take it from there. >=20 > The first table I think may look like this (from quick reading.. but I ma= y be wrong): >=20 >=20 > The following table shows what you can and can not do if you hold one= of > the synchronisation primatives discussed here: (someone who knows what > they are talking about should write this table) I think it should be: > You have: You want: Spin_mtx Slp_mtx sx_lock rw_lock sleep > SPIN mutex ok no no no no-3 > Sleep mutex ok ok-1 no ok no-3 > sx_lock ok no ?? no ok-4 sx_lock ok ok ok-2 ok ok > rw_lock ok no no ok-2 no-3 rw_lock ok ok no ok-2 no And I'd sort the table a bit differently: spin, mtx, rw, sx[, sleep]. > *1 Recursion is defined per lock. lock order is important. Lock order is always important, not only between the same lock types. You also can't mix order of acquiring mtx and rw locks, etc. > *2 readers can recurse tough writers can not. lock order is important. I think John or Attilio are working on adding a flag which will allow for recursion. > *3 There are calls atomically release this primative when going to sl= eep > and reacquire it on wakeup (e.g. mtx_sleep(), rw-sleep() and > msleep_spin).() >=20 > *4 One can also use sx_sleep() which atomically release this primative > when going to sleep and reacquire it on wakeup. What's the difference between 3 and 4? {rw,sx}_sleep(9) fucntions are quite new and I don't know if you can use then only while writer/exclusive lock or also while holding reader/shared lock. BTW. I just wake up with a feeling that I did something wrong in my code. I thought about it for a moment and it seems I'm right. When one always use rw/sx locks this way: sx_xlock(); /* do work */ sx_downgrade(); /* do work */ sx_sunlock(); (the same for rw(9)) the lock will _never_ be shared, because one still always acquire exclusive lock first, which serialize synchronization. Is my thinking correct? If so, I think it's not very obvious, so we may want to add a comment about such use to the manual page as well. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --ibTvN161/egqYuK8 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFF93omForvXbEpPzQRAgxjAJ9gw0ez5JupJhX0JxcFSp/UywlfyQCfTrqR XBOJcq5ydkK7I4GB3HzPl9w= =L4vQ -----END PGP SIGNATURE----- --ibTvN161/egqYuK8-- From owner-freebsd-current@FreeBSD.ORG Wed Mar 14 04:38:49 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5C7EF16A401; Wed, 14 Mar 2007 04:38:49 +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 F11E913C45D; Wed, 14 Mar 2007 04:38:48 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id A7ED2487FC; Wed, 14 Mar 2007 05:38:47 +0100 (CET) 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 9EAAD487F7; Wed, 14 Mar 2007 05:38:42 +0100 (CET) Date: Wed, 14 Mar 2007 05:38:39 +0100 From: Pawel Jakub Dawidek To: Julian Elischer Message-ID: <20070314043839.GC6013@garage.freebsd.pl> References: <200703092241.l29Mf2Ds062856@repoman.freebsd.org> <200703121535.22140.jhb@freebsd.org> <20070312200345.GB5688@garage.freebsd.pl> <200703121618.41084.jhb@freebsd.org> <45F5E1F9.5090806@elischer.org> <20070313010309.Q25395@fledge.watson.org> <45F73AE7.6010508@elischer.org> <45F771E2.9050709@elischer.org> <20070314042926.GA6013@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="w7PDEPdKQumQfZlR" Content-Disposition: inline In-Reply-To: <20070314042926.GA6013@garage.freebsd.pl> X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 User-Agent: mutt-ng/devel-r804 (FreeBSD) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-2.6 required=3.0 tests=BAYES_00 autolearn=ham version=3.0.4 Cc: Robert Watson , current@freebsd.org Subject: Re: [RFC] locking.9 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Mar 2007 04:38:49 -0000 --w7PDEPdKQumQfZlR Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 14, 2007 at 05:29:26AM +0100, Pawel Jakub Dawidek wrote: > On Tue, Mar 13, 2007 at 08:54:10PM -0700, Julian Elischer wrote: > > Julian Elischer wrote: > >=20 > > >ok so how about I commit this to get us started and the nroff and > > >locking experts can take it from there. > >=20 > > The first table I think may look like this (from quick reading.. but I = may be wrong): > >=20 > >=20 > > The following table shows what you can and can not do if you hold o= ne of > > the synchronisation primatives discussed here: (someone who knows w= hat > > they are talking about should write this table) >=20 > I think it should be: >=20 > > You have: You want: Spin_mtx Slp_mtx sx_lock rw_lock sleep > > SPIN mutex ok no no no no-3 > > Sleep mutex ok ok-1 no ok no-3 > > sx_lock ok no ?? no ok-4 > sx_lock ok ok ok-2 ok ok > > rw_lock ok no no ok-2 no-3 > rw_lock ok ok no ok-2 no I'd also add: You're in: You want: Spin_mtx Slp_mtx sx_lock rw_lock sleep interrupt\ ok no no no no context --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --w7PDEPdKQumQfZlR Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFF93xPForvXbEpPzQRAuGNAKCzZEf0VcdzWcpZnZeVaKDRYjZ8uQCeM0/Z i41KogWIqQRWMLN+NL8ebOU= =Bm+S -----END PGP SIGNATURE----- --w7PDEPdKQumQfZlR-- From owner-freebsd-current@FreeBSD.ORG Wed Mar 14 04:54:06 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AD04416A400 for ; Wed, 14 Mar 2007 04:54:06 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outU.internet-mail-service.net (outU.internet-mail-service.net [216.240.47.244]) by mx1.freebsd.org (Postfix) with ESMTP id 9917013C484 for ; Wed, 14 Mar 2007 04:54:06 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Tue, 13 Mar 2007 21:27:03 -0700 Received: from [192.168.2.5] (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id 7142B125DF2 for ; Tue, 13 Mar 2007 21:54:05 -0700 (PDT) Message-ID: <45F77FED.1030601@elischer.org> Date: Tue, 13 Mar 2007 21:54:05 -0700 From: Julian Elischer User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: locking(9) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Mar 2007 04:54:06 -0000 I've committed a skeleton locking (9) man page. Stolen some paragraphs from related man pages and made up some from whole cloth. I'm hoping that it at least gives those who know about locking, a place where they can write in a quick 2 sentence not on something, rather than having to do all the work of starting a new man page from scratch. The object of this page is to document the overall strategy for freeBSD locking, and the interactions between the various techniques. Come to think of it I should put in a section on Netgraph locking. If you know ANYTHING about lockin in the current kernel, check out share/man/man9/locking.9 and add your 10 cents worth. PLEASE! julian From owner-freebsd-current@FreeBSD.ORG Wed Mar 14 04:55:50 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 359C916A407 for ; Wed, 14 Mar 2007 04:55:50 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outT.internet-mail-service.net (outT.internet-mail-service.net [216.240.47.243]) by mx1.freebsd.org (Postfix) with ESMTP id 1B36813C4BB for ; Wed, 14 Mar 2007 04:55:49 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Tue, 13 Mar 2007 21:28:47 -0700 Received: from [192.168.2.5] (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id 06E6D125BE2; Tue, 13 Mar 2007 21:55:48 -0700 (PDT) Message-ID: <45F78054.7020203@elischer.org> Date: Tue, 13 Mar 2007 21:55:48 -0700 From: Julian Elischer User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: Pawel Jakub Dawidek References: <200703092241.l29Mf2Ds062856@repoman.freebsd.org> <200703121535.22140.jhb@freebsd.org> <20070312200345.GB5688@garage.freebsd.pl> <200703121618.41084.jhb@freebsd.org> <45F5E1F9.5090806@elischer.org> <20070313010309.Q25395@fledge.watson.org> <45F73AE7.6010508@elischer.org> <45F771E2.9050709@elischer.org> <20070314042926.GA6013@garage.freebsd.pl> <20070314043839.GC6013@garage.freebsd.pl> In-Reply-To: <20070314043839.GC6013@garage.freebsd.pl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Robert Watson , current@freebsd.org Subject: Re: [RFC] locking.9 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Mar 2007 04:55:50 -0000 Pawel Jakub Dawidek wrote: > On Wed, Mar 14, 2007 at 05:29:26AM +0100, Pawel Jakub Dawidek wrote: >> On Tue, Mar 13, 2007 at 08:54:10PM -0700, Julian Elischer wrote: >>> Julian Elischer wrote: >>> >>>> ok so how about I commit this to get us started and the nroff and >>>> locking experts can take it from there. >>> The first table I think may look like this (from quick reading.. but I may be wrong): >>> >>> >>> The following table shows what you can and can not do if you hold one of >>> the synchronisation primatives discussed here: (someone who knows what >>> they are talking about should write this table) >> I think it should be: >> >>> You have: You want: Spin_mtx Slp_mtx sx_lock rw_lock sleep >>> SPIN mutex ok no no no no-3 >>> Sleep mutex ok ok-1 no ok no-3 >>> sx_lock ok no ?? no ok-4 >> sx_lock ok ok ok-2 ok ok >>> rw_lock ok no no ok-2 no-3 >> rw_lock ok ok no ok-2 no > > I'd also add: > > You're in: You want: Spin_mtx Slp_mtx sx_lock rw_lock sleep > interrupt\ ok no no no no > context > I checked it in.. go for it! :-) From owner-freebsd-current@FreeBSD.ORG Wed Mar 14 05:57:57 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C16BA16A401; Wed, 14 Mar 2007 05:57: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 8953113C465; Wed, 14 Mar 2007 05:57:57 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.13.8/8.13.8) with ESMTP id l2E5vucF001990; Wed, 14 Mar 2007 01:57:56 -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 l2E5vu2u062680; Wed, 14 Mar 2007 01:57:56 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 2A09E73039; Wed, 14 Mar 2007 00:57:56 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070314055756.2A09E73039@freebsd-current.sentex.ca> Date: Wed, 14 Mar 2007 00:57:56 -0500 (EST) 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: Wed, 14 Mar 2007 05:57:57 -0000 TB --- 2007-03-14 04:41:22 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-03-14 04:41:22 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2007-03-14 04:41:22 - cleaning the object tree TB --- 2007-03-14 04:41:44 - checking out the source tree TB --- 2007-03-14 04:41:44 - cd /tinderbox/HEAD/powerpc/powerpc TB --- 2007-03-14 04:41:44 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-03-14 04:49:28 - building world (CFLAGS=-O2 -pipe) TB --- 2007-03-14 04:49:28 - cd /src TB --- 2007-03-14 04:49:28 - /usr/bin/make -B buildworld >>> World build started on Wed Mar 14 04:49:29 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 Wed Mar 14 05:46:41 UTC 2007 TB --- 2007-03-14 05:46:41 - generating LINT kernel config TB --- 2007-03-14 05:46:41 - cd /src/sys/powerpc/conf TB --- 2007-03-14 05:46:41 - /usr/bin/make -B LINT TB --- 2007-03-14 05:46:41 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-03-14 05:46:41 - cd /src TB --- 2007-03-14 05:46:41 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Mar 14 05:46:41 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 [...] /src/sys/modules/cxgb/../../dev/cxgb/cxgb_sge.c:940: warning: previous implicit declaration of 'wmb' was here /src/sys/modules/cxgb/../../dev/cxgb/cxgb_sge.c: In function `ctrl_xmit': /src/sys/modules/cxgb/../../dev/cxgb/cxgb_sge.c:1306: warning: nested extern declaration of `wmb' /src/sys/modules/cxgb/../../dev/cxgb/cxgb_sge.c:940: warning: redundant redeclaration of 'wmb' /src/sys/modules/cxgb/../../dev/cxgb/cxgb_sge.c:940: warning: previous implicit declaration of 'wmb' was here /src/sys/modules/cxgb/../../dev/cxgb/cxgb_sge.c: In function `process_responses': /src/sys/modules/cxgb/../../dev/cxgb/cxgb_sge.c:2069: warning: implicit declaration of function `smp_mb' /src/sys/modules/cxgb/../../dev/cxgb/cxgb_sge.c:2069: warning: nested extern declaration of `smp_mb' *** Error code 1 Stop in /src/sys/modules/cxgb. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-03-14 05:57:55 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-03-14 05:57:55 - ERROR: failed to build lint kernel TB --- 2007-03-14 05:57:55 - tinderbox aborted TB --- 0.59 user 1.77 system 4593.47 real http://tinderbox.des.no/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Wed Mar 14 06:06:15 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 62BA616A484; Wed, 14 Mar 2007 06:06:15 +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 141CE13C44B; Wed, 14 Mar 2007 06:06:14 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.13.8/8.13.8) with ESMTP id l2E66E5C002593; Wed, 14 Mar 2007 02:06:14 -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 l2E66ED8066587; Wed, 14 Mar 2007 02:06:14 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 21D7673039; Wed, 14 Mar 2007 01:06:14 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070314060614.21D7673039@freebsd-current.sentex.ca> Date: Wed, 14 Mar 2007 01:06:14 -0500 (EST) X-Virus-Scanned: ClamAV version devel-20070102, clamav-milter version devel-111206 on clamscanner3 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: Wed, 14 Mar 2007 06:06:15 -0000 TB --- 2007-03-14 04:24:25 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-03-14 04:24:25 - starting HEAD tinderbox run for ia64/ia64 TB --- 2007-03-14 04:24:25 - cleaning the object tree TB --- 2007-03-14 04:24:52 - checking out the source tree TB --- 2007-03-14 04:24:52 - cd /tinderbox/HEAD/ia64/ia64 TB --- 2007-03-14 04:24:52 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-03-14 04:32:29 - building world (CFLAGS=-O2 -pipe) TB --- 2007-03-14 04:32:29 - cd /src TB --- 2007-03-14 04:32:29 - /usr/bin/make -B buildworld >>> World build started on Wed Mar 14 04:32: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 Wed Mar 14 05:48:27 UTC 2007 TB --- 2007-03-14 05:48:27 - generating LINT kernel config TB --- 2007-03-14 05:48:27 - cd /src/sys/ia64/conf TB --- 2007-03-14 05:48:27 - /usr/bin/make -B LINT TB --- 2007-03-14 05:48:27 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-03-14 05:48:27 - cd /src TB --- 2007-03-14 05:48:27 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Mar 14 05:48:27 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 [...] :> export_syms awk -f /src/sys/modules/cue/../../conf/kmod_syms.awk if_cue.kld export_syms | xargs -J% objcopy % if_cue.kld ld -Bshareable -d -warn-common -o if_cue.ko if_cue.kld objcopy --strip-debug if_cue.ko ===> cxgb (all) uudecode -p < /src/sys/modules/cxgb/../../dev/cxgb/t3fw-3.2.bin.gz.uu | gzip -dc > t3fw-3.2.bin t3fw-3.2.bin t3fw-3.2.bin ld: failed to merge target specific data of file t3fw-3.2.bin *** Error code 1 Stop in /src/sys/modules/cxgb. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-03-14 06:06:13 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-03-14 06:06:13 - ERROR: failed to build lint kernel TB --- 2007-03-14 06:06:13 - tinderbox aborted TB --- 0.61 user 1.82 system 6108.95 real http://tinderbox.des.no/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Wed Mar 14 07:15:09 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0815016A401; Wed, 14 Mar 2007 07:15:09 +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 C269113C45A; Wed, 14 Mar 2007 07:15:08 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.13.8/8.13.8) with ESMTP id l2E7F7UR006978; Wed, 14 Mar 2007 03:15:07 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.8/8.13.8) with ESMTP id l2E7F7XG023824; Wed, 14 Mar 2007 03:15:07 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 816E773039; Wed, 14 Mar 2007 02:15:07 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070314071507.816E773039@freebsd-current.sentex.ca> Date: Wed, 14 Mar 2007 02:15:07 -0500 (EST) X-Virus-Scanned: ClamAV version devel-20070108, clamav-milter version devel-111206 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: Wed, 14 Mar 2007 07:15:09 -0000 TB --- 2007-03-14 05:57:56 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-03-14 05:57:56 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2007-03-14 05:57:56 - cleaning the object tree TB --- 2007-03-14 05:58:18 - checking out the source tree TB --- 2007-03-14 05:58:18 - cd /tinderbox/HEAD/sparc64/sparc64 TB --- 2007-03-14 05:58:18 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-03-14 06:05:56 - building world (CFLAGS=-O2 -pipe) TB --- 2007-03-14 06:05:56 - cd /src TB --- 2007-03-14 06:05:56 - /usr/bin/make -B buildworld >>> World build started on Wed Mar 14 06:05: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 >>> World build completed on Wed Mar 14 07:02:06 UTC 2007 TB --- 2007-03-14 07:02:06 - generating LINT kernel config TB --- 2007-03-14 07:02:06 - cd /src/sys/sparc64/conf TB --- 2007-03-14 07:02:06 - /usr/bin/make -B LINT TB --- 2007-03-14 07:02:06 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-03-14 07:02:06 - cd /src TB --- 2007-03-14 07:02:06 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Mar 14 07:02: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 [...] /src/sys/modules/cxgb/../../dev/cxgb/cxgb_sge.c:940: warning: previous implicit declaration of 'wmb' was here /src/sys/modules/cxgb/../../dev/cxgb/cxgb_sge.c: In function `ctrl_xmit': /src/sys/modules/cxgb/../../dev/cxgb/cxgb_sge.c:1306: warning: nested extern declaration of `wmb' /src/sys/modules/cxgb/../../dev/cxgb/cxgb_sge.c:940: warning: redundant redeclaration of 'wmb' /src/sys/modules/cxgb/../../dev/cxgb/cxgb_sge.c:940: warning: previous implicit declaration of 'wmb' was here /src/sys/modules/cxgb/../../dev/cxgb/cxgb_sge.c: In function `process_responses': /src/sys/modules/cxgb/../../dev/cxgb/cxgb_sge.c:2069: warning: implicit declaration of function `smp_mb' /src/sys/modules/cxgb/../../dev/cxgb/cxgb_sge.c:2069: warning: nested extern declaration of `smp_mb' *** Error code 1 Stop in /src/sys/modules/cxgb. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-03-14 07:15:07 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-03-14 07:15:07 - ERROR: failed to build lint kernel TB --- 2007-03-14 07:15:07 - tinderbox aborted TB --- 0.55 user 1.78 system 4630.89 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Wed Mar 14 07:20:57 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5915916A403; Wed, 14 Mar 2007 07:20:57 +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 1379613C468; Wed, 14 Mar 2007 07:20:56 +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.6/8.13.6) with ESMTP id l2E7KuNm063538; Wed, 14 Mar 2007 03:20: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.13.8/8.13.8) with ESMTP id l2E7KuY3036065; Wed, 14 Mar 2007 03:20:56 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 0E96E73039; Wed, 14 Mar 2007 02:20:56 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070314072056.0E96E73039@freebsd-current.sentex.ca> Date: Wed, 14 Mar 2007 02:20:56 -0500 (EST) X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on clamscanner2 X-Virus-Scanned: ClamAV version devel-20070108, clamav-milter version devel-111206 on clamscanner2 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: Wed, 14 Mar 2007 07:20:57 -0000 TB --- 2007-03-14 06:06:14 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-03-14 06:06:14 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2007-03-14 06:06:14 - cleaning the object tree TB --- 2007-03-14 06:06:47 - checking out the source tree TB --- 2007-03-14 06:06:47 - cd /tinderbox/HEAD/sparc64/sun4v TB --- 2007-03-14 06:06:47 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-03-14 06:14:19 - building world (CFLAGS=-O2 -pipe) TB --- 2007-03-14 06:14:19 - cd /src TB --- 2007-03-14 06:14:19 - /usr/bin/make -B buildworld >>> World build started on Wed Mar 14 06:14:20 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 Wed Mar 14 07:08:51 UTC 2007 TB --- 2007-03-14 07:08:51 - generating LINT kernel config TB --- 2007-03-14 07:08:51 - cd /src/sys/sun4v/conf TB --- 2007-03-14 07:08:51 - /usr/bin/make -B LINT TB --- 2007-03-14 07:08:51 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-03-14 07:08:51 - cd /src TB --- 2007-03-14 07:08:51 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Mar 14 07:08: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 [...] /src/sys/modules/cxgb/../../dev/cxgb/cxgb_sge.c:940: warning: previous implicit declaration of 'wmb' was here /src/sys/modules/cxgb/../../dev/cxgb/cxgb_sge.c: In function `ctrl_xmit': /src/sys/modules/cxgb/../../dev/cxgb/cxgb_sge.c:1306: warning: nested extern declaration of `wmb' /src/sys/modules/cxgb/../../dev/cxgb/cxgb_sge.c:940: warning: redundant redeclaration of 'wmb' /src/sys/modules/cxgb/../../dev/cxgb/cxgb_sge.c:940: warning: previous implicit declaration of 'wmb' was here /src/sys/modules/cxgb/../../dev/cxgb/cxgb_sge.c: In function `process_responses': /src/sys/modules/cxgb/../../dev/cxgb/cxgb_sge.c:2069: warning: implicit declaration of function `smp_mb' /src/sys/modules/cxgb/../../dev/cxgb/cxgb_sge.c:2069: warning: nested extern declaration of `smp_mb' *** Error code 1 Stop in /src/sys/modules/cxgb. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/sun4v/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-03-14 07:20:56 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-03-14 07:20:56 - ERROR: failed to build lint kernel TB --- 2007-03-14 07:20:56 - tinderbox aborted TB --- 0.57 user 1.98 system 4481.70 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From owner-freebsd-current@FreeBSD.ORG Wed Mar 14 09:17:04 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 149A916A401; Wed, 14 Mar 2007 09:17:04 +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 E125813C459; Wed, 14 Mar 2007 09:17:03 +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 3AE3946FA7; Wed, 14 Mar 2007 04:17:03 -0500 (EST) Date: Wed, 14 Mar 2007 10:17:03 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Pawel Jakub Dawidek In-Reply-To: <20070314042926.GA6013@garage.freebsd.pl> Message-ID: <20070314101424.A60010@fledge.watson.org> References: <200703092241.l29Mf2Ds062856@repoman.freebsd.org> <200703121535.22140.jhb@freebsd.org> <20070312200345.GB5688@garage.freebsd.pl> <200703121618.41084.jhb@freebsd.org> <45F5E1F9.5090806@elischer.org> <20070313010309.Q25395@fledge.watson.org> <45F73AE7.6010508@elischer.org> <45F771E2.9050709@elischer.org> <20070314042926.GA6013@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Julian Elischer , current@freebsd.org Subject: Re: [RFC] locking.9 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Mar 2007 09:17:04 -0000 On Wed, 14 Mar 2007, Pawel Jakub Dawidek wrote: > I think it should be: > >> You have: You want: Spin_mtx Slp_mtx sx_lock rw_lock sleep >> SPIN mutex ok no no no no-3 >> Sleep mutex ok ok-1 no ok no-3 >> sx_lock ok no ?? no ok-4 > sx_lock ok ok ok-2 ok ok >> rw_lock ok no no ok-2 no-3 > rw_lock ok ok no ok-2 no > > And I'd sort the table a bit differently: spin, mtx, rw, sx[, sleep]. Hmm. I was thinking more along the lines of a table that compared properties and locks. I.e., horizontally feature, vertically lock type. Features would be things like "safe in interrupt handlers", "can perform unbounded sleep while holding", "supports multiple readers, not just exclusion", "priority propagation", etc. > BTW. I just wake up with a feeling that I did something wrong in my code. I > thought about it for a moment and it seems I'm right. When one always use > rw/sx locks this way: > > sx_xlock(); > /* do work */ > sx_downgrade(); > /* do work */ > sx_sunlock(); > > (the same for rw(9)) the lock will _never_ be shared, because one still > always acquire exclusive lock first, which serialize synchronization. Is my > thinking correct? If so, I think it's not very obvious, so we may want to > add a comment about such use to the manual page as well. FYI, one of the problems with "downgrade" as a primitive is that if you always acquire exclusively and then downgrade, you never get multiple shared readers, as all shared readers must first go through an exclusive stage. It only helps if you have threads entering as shared from inception. This is one reason why naively moving to reader/writer locks doesn't solve concurrency limits in the TCP input path. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Wed Mar 14 11:30:21 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 69AC516A401 for ; Wed, 14 Mar 2007 11:30:21 +0000 (UTC) (envelope-from jhary@unsane.co.uk) Received: from unsane.co.uk (www.unsane.co.uk [85.233.185.162]) by mx1.freebsd.org (Postfix) with ESMTP id 0024313C45E for ; Wed, 14 Mar 2007 11:30:20 +0000 (UTC) (envelope-from jhary@unsane.co.uk) Received: from [192.168.10.217] (150.117-84-212.staticip.namesco.net [212.84.117.150]) (authenticated bits=0) by unsane.co.uk (8.14.0/8.14.0) with ESMTP id l2EB5uRN054110 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Mar 2007 11:05:56 GMT (envelope-from jhary@unsane.co.uk) Message-ID: <45F7D727.2080301@unsane.co.uk> Date: Wed, 14 Mar 2007 11:06:15 +0000 From: Vince User-Agent: Thunderbird 1.5.0.9 (X11/20070129) MIME-Version: 1.0 To: Willy@Offermans.Rompen.nl References: <20070314104732.GA5794@wiz> In-Reply-To: <20070314104732.GA5794@wiz> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 14 Mar 2007 11:32:48 +0000 Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: tap device at boot time X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Mar 2007 11:30:21 -0000 Willy Offermans wrote: > Dear FreeBSD friends, > > Is it possible to add and configure a tap device at boot time of > FreeBSD? I mean the same as a normal NIC. In my rc.conf: > > > ... > ifconfig_xl0="inet 192.168.0.2 promisc netmask 255.255.255.0" > ifconfig_rl0="inet 192.168.4.2 netmask 255.255.255.0" > ifconfig_tap0="inet 10.8.0.1 netmask 255.255.255.0" > ... > > try adding cloned_interfaces="tap0" to your rc.conf Vince > and in my /boot/loader.conf: > > ... > if_tap_load="YES" > ... > > > if_xl0 and if_rl0 are compiled into the kernel. > > Maybe it is even possible to set the MAC address of the tap device!? > > The tap device should be available before named and dhcpd have been > started. In that way I can provide IP addresses over the tap device > and add appropriate DNS entries. > > I like to run openvpn with tap devices and want to use the dhcpd server > to provide IP addresses and update the named. This works quite well. > However after reboot I always have to restart named and dhcpd again > since the tap device becomes available after these services have started > during boot. I guess this problem will be solved if the tap device is > already available and configured before named and dhcpd have started. > From owner-freebsd-current@FreeBSD.ORG Wed Mar 14 11:52:35 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9B52616A40B; Wed, 14 Mar 2007 11:52:35 +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 72EB113C459; Wed, 14 Mar 2007 11:52:35 +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.6/8.13.6) with ESMTP id l2EBqYXT074437; Wed, 14 Mar 2007 07:52:34 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.8/8.13.8) with ESMTP id l2EBqYC6013431; Wed, 14 Mar 2007 07:52:34 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id D98AF73039; Wed, 14 Mar 2007 06:52:33 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070314115233.D98AF73039@freebsd-current.sentex.ca> Date: Wed, 14 Mar 2007 06:52:33 -0500 (EST) X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on clamscanner2 X-Virus-Scanned: ClamAV version devel-20070108, clamav-milter version devel-111206 on clamscanner2 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: Wed, 14 Mar 2007 11:52:35 -0000 TB --- 2007-03-14 10:22:30 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-03-14 10:22:30 - starting HEAD tinderbox run for ia64/ia64 TB --- 2007-03-14 10:22:30 - cleaning the object tree TB --- 2007-03-14 10:22:56 - checking out the source tree TB --- 2007-03-14 10:22:56 - cd /tinderbox/HEAD/ia64/ia64 TB --- 2007-03-14 10:22:56 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-03-14 10:30:45 - building world (CFLAGS=-O2 -pipe) TB --- 2007-03-14 10:30:45 - cd /src TB --- 2007-03-14 10:30:45 - /usr/bin/make -B buildworld >>> World build started on Wed Mar 14 10:30: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 Wed Mar 14 11:46:43 UTC 2007 TB --- 2007-03-14 11:46:43 - generating LINT kernel config TB --- 2007-03-14 11:46:43 - cd /src/sys/ia64/conf TB --- 2007-03-14 11:46:43 - /usr/bin/make -B LINT TB --- 2007-03-14 11:46:44 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-03-14 11:46:44 - cd /src TB --- 2007-03-14 11:46:44 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Mar 14 11:46:44 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 [...] /src/sys/dev/cxgb/cxgb_sge.c:1751: warning: nested extern declaration of `prefetch' /src/sys/dev/cxgb/cxgb_sge.c: In function `process_responses': /src/sys/dev/cxgb/cxgb_sge.c:1951: warning: nested extern declaration of `prefetch' /src/sys/dev/cxgb/cxgb_sge.c:1751: warning: redundant redeclaration of 'prefetch' /src/sys/dev/cxgb/cxgb_sge.c:1751: warning: previous implicit declaration of 'prefetch' was here /src/sys/dev/cxgb/cxgb_sge.c:1959: error: `L1_CACHE_BYTES' undeclared (first use in this function) /src/sys/dev/cxgb/cxgb_sge.c:1959: error: (Each undeclared identifier is reported only once /src/sys/dev/cxgb/cxgb_sge.c:1959: error: for each function it appears in.) *** Error code 1 Stop in /obj/ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-03-14 11:52:33 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-03-14 11:52:33 - ERROR: failed to build lint kernel TB --- 2007-03-14 11:52:33 - tinderbox aborted TB --- 0.65 user 2.05 system 5403.23 real http://tinderbox.des.no/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Wed Mar 14 12:16:19 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 727D216A405; Wed, 14 Mar 2007 12:16:19 +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 1B80713C45A; Wed, 14 Mar 2007 12:16:18 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.13.8/8.13.8) with ESMTP id l2ECGHQV041657; Wed, 14 Mar 2007 08:16:17 -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 l2ECGHkv003742; Wed, 14 Mar 2007 08:16:17 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 775C473039; Wed, 14 Mar 2007 07:16:17 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070314121617.775C473039@freebsd-current.sentex.ca> Date: Wed, 14 Mar 2007 07:16:17 -0500 (EST) X-Virus-Scanned: ClamAV version devel-20070102, clamav-milter version devel-111206 on clamscanner4 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: Wed, 14 Mar 2007 12:16:19 -0000 TB --- 2007-03-14 11:07:21 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-03-14 11:07:21 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2007-03-14 11:07:21 - cleaning the object tree TB --- 2007-03-14 11:07:40 - checking out the source tree TB --- 2007-03-14 11:07:40 - cd /tinderbox/HEAD/powerpc/powerpc TB --- 2007-03-14 11:07:40 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-03-14 11:14:56 - building world (CFLAGS=-O2 -pipe) TB --- 2007-03-14 11:14:56 - cd /src TB --- 2007-03-14 11:14:56 - /usr/bin/make -B buildworld >>> World build started on Wed Mar 14 11:15:00 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 Wed Mar 14 12:12:41 UTC 2007 TB --- 2007-03-14 12:12:41 - generating LINT kernel config TB --- 2007-03-14 12:12:41 - cd /src/sys/powerpc/conf TB --- 2007-03-14 12:12:41 - /usr/bin/make -B LINT TB --- 2007-03-14 12:12:41 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-03-14 12:12:41 - cd /src TB --- 2007-03-14 12:12:41 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Mar 14 12:12: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 [...] /src/sys/dev/cxgb/cxgb_sge.c:1751: warning: nested extern declaration of `prefetch' /src/sys/dev/cxgb/cxgb_sge.c: In function `process_responses': /src/sys/dev/cxgb/cxgb_sge.c:1951: warning: nested extern declaration of `prefetch' /src/sys/dev/cxgb/cxgb_sge.c:1751: warning: redundant redeclaration of 'prefetch' /src/sys/dev/cxgb/cxgb_sge.c:1751: warning: previous implicit declaration of 'prefetch' was here /src/sys/dev/cxgb/cxgb_sge.c:1959: error: `L1_CACHE_BYTES' undeclared (first use in this function) /src/sys/dev/cxgb/cxgb_sge.c:1959: error: (Each undeclared identifier is reported only once /src/sys/dev/cxgb/cxgb_sge.c:1959: error: for each function it appears in.) *** Error code 1 Stop in /obj/powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-03-14 12:16:17 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-03-14 12:16:17 - ERROR: failed to build lint kernel TB --- 2007-03-14 12:16:17 - tinderbox aborted TB --- 0.48 user 2.05 system 4135.69 real http://tinderbox.des.no/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Wed Mar 14 12:21:36 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 273AB16A407 for ; Wed, 14 Mar 2007 12:21:36 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.247]) by mx1.freebsd.org (Postfix) with ESMTP id C182713C46C for ; Wed, 14 Mar 2007 12:21:35 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by an-out-0708.google.com with SMTP id c24so160656ana for ; Wed, 14 Mar 2007 05:21: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:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=udqedkLuLPz42i3Usns67emZDjJqKWFUMmfXJog8v2M078RpB8vf4dcoA+yAgeb8tyKiEpMrjys587AZpOvvJHSHNDRyO18FRYdEn1ISjDfCQsAOIZnTVIerL1m84ungBLZaiVwE1mlPzaHDHDWwCqWslp9Sb7m6fQCpKjcOOqk= 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=eFktHKCQQEwCJMaaRYjuJqAdecgeEqJQPi9fiyxN23m+JqhNIQl0rBmLu7VPQOi/sEPjv0FKuGKXvk4CmCOMuqQlhfstbGw4BL+oJnoByf8MReY7kYxU9Y/8WwL7yADA+FcQ3DiJgmMJ6QZBchR9GAEX3Abzfg8PyTUkMa8D/hk= Received: by 10.100.112.19 with SMTP id k19mr1619073anc.1173874894830; Wed, 14 Mar 2007 05:21:34 -0700 (PDT) Received: by 10.100.191.11 with HTTP; Wed, 14 Mar 2007 05:21:34 -0700 (PDT) Message-ID: <3bbf2fe10703140521x30e709c4g749a62b55f8aa61d@mail.gmail.com> Date: Wed, 14 Mar 2007 13:21:34 +0100 From: "Attilio Rao" Sender: asmrookie@gmail.com To: "Julian Elischer" In-Reply-To: <45F771E2.9050709@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200703092241.l29Mf2Ds062856@repoman.freebsd.org> <200703121535.22140.jhb@freebsd.org> <20070312200345.GB5688@garage.freebsd.pl> <200703121618.41084.jhb@freebsd.org> <45F5E1F9.5090806@elischer.org> <20070313010309.Q25395@fledge.watson.org> <45F73AE7.6010508@elischer.org> <45F771E2.9050709@elischer.org> X-Google-Sender-Auth: 7a04ec60357a8516 Cc: Robert Watson , Pawel Jakub Dawidek , current@freebsd.org Subject: Re: [RFC] locking.9 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Mar 2007 12:21:36 -0000 2007/3/14, Julian Elischer : > Julian Elischer wrote: > > > > > ok so how about I commit this to get us started and the nroff and > > locking experts can take it from there. > > > > The first table I think may look like this > (from quick reading.. but I may be wrong): > > > The following table shows what you can and can not do if you hold one of > the synchronisation primatives discussed here: (someone who knows what > they are talking about should write this table) > > You have: You want: Spin_mtx Slp_mtx sx_lock rw_lock sleep > SPIN mutex ok no no no no-3 > Sleep mutex ok ok-1 no ok no-3 > sx_lock ok no ?? no ok-4 > rw_lock ok no no ok-2 no-3 > > *1 Recursion is defined per lock. lock order is important. > > *2 readers can recurse tough writers can not. lock order is important. > > *3 There are calls atomically release this primative when going to sleep > and reacquire it on wakeup (e.g. mtx_sleep(), rw-sleep() and > msleep_spin).() > > *4 One can also use sx_sleep() which atomically release this primative > when going to sleep and reacquire it on wakeup. I think that we can do a better job describing the three main events (spinning, blocking, sleeping) the correspondence with every primitive and what is allowed to do (we can add an addictional paragraph about preemption and its nits, sched_bind, sched_pin, critical sections, etc.). Assuming that lock ordering is always important (not only in the mutexes case) and that very soon all the primitives will allow recursion (check for //depot/user/attilio/attilio_smpng/... for an example fo recursive sx), it is not really important to deal with these details. I think would help having a section per-primitive describing the better cases of usage for every primitive, i.e.: Spin Mutexes - To be used only in interrupt context or for path really short, as single assignment etc (even if in that case probabilly they can be replaced by something more appropriate. This informations should be just integrative with the table you previously mentioned and should not overlap. Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Wed Mar 14 13:01:20 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1E08C16A404; Wed, 14 Mar 2007 13:01:20 +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 D151C13C458; Wed, 14 Mar 2007 13:01:19 +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.6/8.13.6) with ESMTP id l2ED1JEi082455; Wed, 14 Mar 2007 09:01:19 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.8/8.13.8) with ESMTP id l2ED1IAw098475; Wed, 14 Mar 2007 09:01:18 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id B7AFB73039; Wed, 14 Mar 2007 08:01:18 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070314130118.B7AFB73039@freebsd-current.sentex.ca> Date: Wed, 14 Mar 2007 08:01:18 -0500 (EST) X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on clamscanner4 X-Virus-Scanned: ClamAV version devel-20070108, clamav-milter version devel-111206 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: Wed, 14 Mar 2007 13:01:20 -0000 TB --- 2007-03-14 11:52:33 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-03-14 11:52:33 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2007-03-14 11:52:33 - cleaning the object tree TB --- 2007-03-14 11:52:54 - checking out the source tree TB --- 2007-03-14 11:52:54 - cd /tinderbox/HEAD/sparc64/sparc64 TB --- 2007-03-14 11:52:54 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-03-14 12:01:01 - building world (CFLAGS=-O2 -pipe) TB --- 2007-03-14 12:01:01 - cd /src TB --- 2007-03-14 12:01:01 - /usr/bin/make -B buildworld >>> World build started on Wed Mar 14 12:01:04 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 Wed Mar 14 12:57:09 UTC 2007 TB --- 2007-03-14 12:57:09 - generating LINT kernel config TB --- 2007-03-14 12:57:09 - cd /src/sys/sparc64/conf TB --- 2007-03-14 12:57:09 - /usr/bin/make -B LINT TB --- 2007-03-14 12:57:09 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-03-14 12:57:09 - cd /src TB --- 2007-03-14 12:57:09 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Mar 14 12:57:09 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 [...] /src/sys/dev/cxgb/cxgb_sge.c:1751: warning: nested extern declaration of `prefetch' /src/sys/dev/cxgb/cxgb_sge.c: In function `process_responses': /src/sys/dev/cxgb/cxgb_sge.c:1951: warning: nested extern declaration of `prefetch' /src/sys/dev/cxgb/cxgb_sge.c:1751: warning: redundant redeclaration of 'prefetch' /src/sys/dev/cxgb/cxgb_sge.c:1751: warning: previous implicit declaration of 'prefetch' was here /src/sys/dev/cxgb/cxgb_sge.c:1959: error: `L1_CACHE_BYTES' undeclared (first use in this function) /src/sys/dev/cxgb/cxgb_sge.c:1959: error: (Each undeclared identifier is reported only once /src/sys/dev/cxgb/cxgb_sge.c:1959: error: for each function it appears in.) *** Error code 1 Stop in /obj/sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-03-14 13:01:18 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-03-14 13:01:18 - ERROR: failed to build lint kernel TB --- 2007-03-14 13:01:18 - tinderbox aborted TB --- 0.60 user 1.82 system 4124.57 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Wed Mar 14 13:21:44 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 58BAA16A405; Wed, 14 Mar 2007 13:21:44 +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 16EC213C489; Wed, 14 Mar 2007 13:21: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.6/8.13.6) with ESMTP id l2EDLgNs084940; Wed, 14 Mar 2007 09:21:42 -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 l2EDLgSc063383; Wed, 14 Mar 2007 09:21:42 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 1A53D73039; Wed, 14 Mar 2007 08:21:42 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070314132142.1A53D73039@freebsd-current.sentex.ca> Date: Wed, 14 Mar 2007 08:21:42 -0500 (EST) X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on clamscanner1 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: Wed, 14 Mar 2007 13:21:44 -0000 TB --- 2007-03-14 12:16:17 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-03-14 12:16:17 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2007-03-14 12:16:17 - cleaning the object tree TB --- 2007-03-14 12:16:40 - checking out the source tree TB --- 2007-03-14 12:16:40 - cd /tinderbox/HEAD/sparc64/sun4v TB --- 2007-03-14 12:16:40 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-03-14 12:24:25 - building world (CFLAGS=-O2 -pipe) TB --- 2007-03-14 12:24:25 - cd /src TB --- 2007-03-14 12:24:25 - /usr/bin/make -B buildworld >>> World build started on Wed Mar 14 12:24:27 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 Wed Mar 14 13:17:50 UTC 2007 TB --- 2007-03-14 13:17:50 - generating LINT kernel config TB --- 2007-03-14 13:17:50 - cd /src/sys/sun4v/conf TB --- 2007-03-14 13:17:50 - /usr/bin/make -B LINT TB --- 2007-03-14 13:17:51 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-03-14 13:17:51 - cd /src TB --- 2007-03-14 13:17:51 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Mar 14 13:17: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 [...] /src/sys/dev/cxgb/cxgb_sge.c:1751: warning: nested extern declaration of `prefetch' /src/sys/dev/cxgb/cxgb_sge.c: In function `process_responses': /src/sys/dev/cxgb/cxgb_sge.c:1951: warning: nested extern declaration of `prefetch' /src/sys/dev/cxgb/cxgb_sge.c:1751: warning: redundant redeclaration of 'prefetch' /src/sys/dev/cxgb/cxgb_sge.c:1751: warning: previous implicit declaration of 'prefetch' was here /src/sys/dev/cxgb/cxgb_sge.c:1959: error: `L1_CACHE_BYTES' undeclared (first use in this function) /src/sys/dev/cxgb/cxgb_sge.c:1959: error: (Each undeclared identifier is reported only once /src/sys/dev/cxgb/cxgb_sge.c:1959: error: for each function it appears in.) *** Error code 1 Stop in /obj/sun4v/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-03-14 13:21:42 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-03-14 13:21:42 - ERROR: failed to build lint kernel TB --- 2007-03-14 13:21:42 - tinderbox aborted TB --- 0.48 user 1.96 system 3924.55 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From owner-freebsd-current@FreeBSD.ORG Wed Mar 14 13:38:41 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B159C16A400 for ; Wed, 14 Mar 2007 13:38:41 +0000 (UTC) (envelope-from roberthuff@rcn.com) Received: from smtp02.lnh.mail.rcn.net (smtp02.lnh.mail.rcn.net [207.172.157.102]) by mx1.freebsd.org (Postfix) with ESMTP id 70B6613C448 for ; Wed, 14 Mar 2007 13:38:41 +0000 (UTC) (envelope-from roberthuff@rcn.com) Received: from mr08.lnh.mail.rcn.net ([207.172.157.28]) by smtp02.lnh.mail.rcn.net with ESMTP; 14 Mar 2007 09:09:28 -0400 Received: from smtp01.lnh.mail.rcn.net (smtp01.lnh.mail.rcn.net [207.172.4.11]) by mr08.lnh.mail.rcn.net (MOS 3.7.5a-GA) with ESMTP id IJS81968; Wed, 14 Mar 2007 09:09:23 -0400 (EDT) Received: from 65-78-26-179.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com (HELO jerusalem.litteratus.org.litteratus.org) ([65.78.26.179]) by smtp01.lnh.mail.rcn.net with ESMTP; 14 Mar 2007 08:09:22 -0500 From: Robert Huff MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17911.62465.534926.306376@jerusalem.litteratus.org> Date: Wed, 14 Mar 2007 08:09:21 -0500 To: current@freebsd.org X-Mailer: VM 7.17 under 21.5 (beta27) "fiddleheads" XEmacs Lucid X-Junkmail-Whitelist: YES (by domain whitelist at mr08.lnh.mail.rcn.net) Cc: Subject: network card not probed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Mar 2007 13:38:41 -0000 After updating my -CURRENT box to FreeBSD 7.0-CURRENT #0: Tue Mar 13 22:38:20 EST 2007 i386 one of the network cards was not found at boot. Checking with pciconf produced: none1@pci0:11:0: class=0x020000 card=0x00000000 chip=0x00091011 rev=0x11 hdr=0x00 vendor = 'Digital Equipment Corporation' device = 'DecChip 21140 Fast Ethernet Adapter' class = network subclass = ethernet and loading if_de.ko by hand produced the following: de0: port 0xa000 -0xa07f mem 0xef800000-0xef80007f irq 14 at device 11.0 on pci0 de0: ZNYX ZX34X 21140 [10-100Mb/s] pass 1.1 de0: using obsoleted if_watchdog interface de0: Ethernet address: 00:c0:95:f8:17:af de0: [GIANT-LOCKED] de0: [ITHREAD] The machine is running (I added the necessary line to loader.conf), but I'd like to eliminate user error before filing a PR. So: tracked down the "if_watchdog", no problem, but can't find anything on the "[ITHREAD]" /per se/. And what has changed to make the card invisible? Robert Huff From owner-freebsd-current@FreeBSD.ORG Wed Mar 14 14:22:51 2007 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4FAEA16A401 for ; Wed, 14 Mar 2007 14:22:51 +0000 (UTC) (envelope-from piso@newluxor.wired.org) Received: from mail.oltrelinux.com (krisma.oltrelinux.com [194.242.226.43]) by mx1.freebsd.org (Postfix) with ESMTP id 0E5CC13C44C for ; Wed, 14 Mar 2007 14:22:50 +0000 (UTC) (envelope-from piso@newluxor.wired.org) Received: from newluxor.wired.org (ip-115-132.sn1.eutelia.it [62.94.115.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.oltrelinux.com (Postfix) with ESMTP id 1AD4D11AE98; Wed, 14 Mar 2007 15:22:44 +0100 (CET) Received: (from piso@localhost) by newluxor.wired.org (8.13.8/8.13.8/Submit) id l2EDvCVJ002795; Wed, 14 Mar 2007 14:57:12 +0100 (CET) (envelope-from piso) Date: Wed, 14 Mar 2007 14:56:57 +0100 From: Paolo Pisati To: Robert Huff Message-ID: <20070314135657.GB2711@tin.it> References: <17911.62465.534926.306376@jerusalem.litteratus.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <17911.62465.534926.306376@jerusalem.litteratus.org> User-Agent: Mutt/1.4.2.2i X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at krisma.oltrelinux.com Cc: current@FreeBSD.org Subject: Re: network card not probed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Mar 2007 14:22:51 -0000 On Wed, Mar 14, 2007 at 08:09:21AM -0500, Robert Huff wrote: [snip] > and loading if_de.ko by hand produced the following: > > de0: port 0xa000 > -0xa07f mem 0xef800000-0xef80007f irq 14 at device 11.0 on pci0 > de0: ZNYX ZX34X 21140 [10-100Mb/s] pass 1.1 > de0: using obsoleted if_watchdog interface > de0: Ethernet address: 00:c0:95:f8:17:af > de0: [GIANT-LOCKED] > de0: [ITHREAD] > > The machine is running (I added the necessary line to > loader.conf), but I'd like to eliminate user error before filing a > PR. if the kernel didn't complain about duplicate symbols, it means you didn't have if_de compiled in your kernel. > So: tracked down the "if_watchdog", no problem, but can't find > anything on the "[ITHREAD]" /per se/. it's just a message saying "the handler for this NIC runs in the ithread context", part of the interrupt filtering commit. > And what has changed to make the card invisible? i guess something about module loading... bye, P. From owner-freebsd-current@FreeBSD.ORG Wed Mar 14 14:48:54 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E2F9C16A402 for ; Wed, 14 Mar 2007 14:48: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 B84D013C489 for ; Wed, 14 Mar 2007 14:48:54 +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 4FB7946EFA; Wed, 14 Mar 2007 09:48:54 -0500 (EST) Date: Wed, 14 Mar 2007 15:48:54 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Julian Elischer In-Reply-To: <45F706A2.5020106@elischer.org> Message-ID: <20070314154728.Y47292@fledge.watson.org> References: <45F388D4.2080900@elischer.org> <45F45172.8070601@elischer.org> <86r6rt6z27.fsf@dwp.des.no> <45F706A2.5020106@elischer.org> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-348664937-1173883734=:47292" Cc: =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= , FreeBSD Current Subject: Re: netstat wierdness? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Mar 2007 14:48:55 -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-348664937-1173883734=:47292 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Tue, 13 Mar 2007, Julian Elischer wrote: > Dag-Erling Sm=F8rgrav wrote: >> Julian Elischer writes: >>> answering myself.. comes from having options LOCK_PROFILING in my kerne= l.=20 >>> adding the same to /etc/make.conf and recompiling netstat and libkvm=20 >>> helped. (not sure if both are needed) >>=20 >> This is very bad. LOCK_PROFILING should have no visible effect on=20 >> userland. That is precisely what xinpcb, xunpcb, xtcpcb etc. are for: t= o=20 >> isolate userland from kernel structures. They should not contain any lo= cks=20 >> or anything else which would be affected by LOCK_PROFILING or other kern= el=20 >> options. > > sockstat actually told me that all those were the wrong size, so apparent= ly=20 > they change size too.(!?) > > I haven't gone to look at their definition yet, but as you say, it sounds= =20 > like something was done wrong. The x* structures in netinet are not correctly implemented, and do incorpor= ate=20 kernel data structures. I've been meaning to fix that for ages, but haven'= t=20 had time. In the mean time, we should continue to avoid having the size of= =20 kernel data structures vary with kernel options. This is also important so= =20 that you can use /dev/kmem on core dumps, etc, so while fixing the x*=20 structures for netinet is important, it doesn't eliminate the need to avoid= =20 variable data structure sizes. Robert N M Watson Computer Laboratory University of Cambridge --0-348664937-1173883734=:47292-- From owner-freebsd-current@FreeBSD.ORG Wed Mar 14 15:51:29 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 73A7A16A400 for ; Wed, 14 Mar 2007 15:51:29 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (palm.hoeg.nl [83.98.131.212]) by mx1.freebsd.org (Postfix) with ESMTP id 345AD13C45B for ; Wed, 14 Mar 2007 15:51:28 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 532621CC79; Wed, 14 Mar 2007 16:52:06 +0100 (CET) Date: Wed, 14 Mar 2007 16:52:06 +0100 From: Ed Schouten To: Pyun YongHyeon Message-ID: <20070314155206.GR7449@hoeg.nl> References: <20070310074734.GC70613@cdnetworks.co.kr> <917080.87242.qm@web34701.mail.mud.yahoo.com> <20070311050627.GC79728@cdnetworks.co.kr> <45F3B94B.3030104@gwdg.de> <20070312045116.GA83433@cdnetworks.co.kr> <45F5C914.3000805@gwdg.de> <20070313004601.GA87608@cdnetworks.co.kr> <20070313005845.GB87608@cdnetworks.co.kr> <45F636B5.9060608@gwdg.de> <20070313070153.GD87608@cdnetworks.co.kr> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Z1Z8UV8BNhgCynIS" Content-Disposition: inline In-Reply-To: <20070313070153.GD87608@cdnetworks.co.kr> User-Agent: Mutt/1.5.14 (2007-02-12) Cc: darren780@yahoo.com, FreeBSD Current Subject: Re: yongari nfe 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: Wed, 14 Mar 2007 15:51:29 -0000 --Z1Z8UV8BNhgCynIS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Pyun YongHyeon wrote: > Apparently we **NEED** a copy of the documentation for the PHY. :-( http://www.vitesse.com/products/product.php?number=3DVSC8601 This page contains download links, but you need to register. After you've registered, you need someone from the company to give you the permission to download these files. :-( --=20 Ed Schouten WWW: http://g-rave.nl/ --Z1Z8UV8BNhgCynIS Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFF+Bom52SDGA2eCwURApJDAJ485Wf3/unNsU3XAf7zc6OjawFDjQCffCHQ TEhaPjTjx7IKoyNACu9VmE4= =jOk9 -----END PGP SIGNATURE----- --Z1Z8UV8BNhgCynIS-- From owner-freebsd-current@FreeBSD.ORG Wed Mar 14 17:22:05 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D85C316A484 for ; Wed, 14 Mar 2007 17:22:05 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outW.internet-mail-service.net (outW.internet-mail-service.net [216.240.47.246]) by mx1.freebsd.org (Postfix) with ESMTP id 97E5413C45A for ; Wed, 14 Mar 2007 17:22:05 +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; Wed, 14 Mar 2007 09:54:58 -0700 Received: from [192.168.2.5] (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id 9B032125ADA; Wed, 14 Mar 2007 10:22:04 -0700 (PDT) Message-ID: <45F82F3C.8080906@elischer.org> Date: Wed, 14 Mar 2007 10:22:04 -0700 From: Julian Elischer User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: Attilio Rao References: <200703092241.l29Mf2Ds062856@repoman.freebsd.org> <200703121535.22140.jhb@freebsd.org> <20070312200345.GB5688@garage.freebsd.pl> <200703121618.41084.jhb@freebsd.org> <45F5E1F9.5090806@elischer.org> <20070313010309.Q25395@fledge.watson.org> <45F73AE7.6010508@elischer.org> <45F771E2.9050709@elischer.org> <3bbf2fe10703140521x30e709c4g749a62b55f8aa61d@mail.gmail.com> In-Reply-To: <3bbf2fe10703140521x30e709c4g749a62b55f8aa61d@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Robert Watson , Pawel Jakub Dawidek , current@freebsd.org Subject: Re: [RFC] locking.9 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Mar 2007 17:22:06 -0000 Attilio Rao wrote: > 2007/3/14, Julian Elischer : >> Julian Elischer wrote: >> >> > >> > ok so how about I commit this to get us started and the nroff and >> > locking experts can take it from there. >> > >> >> The first table I think may look like this >> (from quick reading.. but I may be wrong): >> >> >> The following table shows what you can and can not do if you hold >> one of >> the synchronisation primatives discussed here: (someone who knows >> what >> they are talking about should write this table) >> >> You have: You want: Spin_mtx Slp_mtx sx_lock rw_lock sleep >> SPIN mutex ok no no no no-3 >> Sleep mutex ok ok-1 no ok no-3 >> sx_lock ok no ?? no ok-4 >> rw_lock ok no no ok-2 no-3 >> >> *1 Recursion is defined per lock. lock order is important. >> >> *2 readers can recurse tough writers can not. lock order is >> important. >> >> *3 There are calls atomically release this primative when going to >> sleep >> and reacquire it on wakeup (e.g. mtx_sleep(), rw-sleep() and >> msleep_spin).() >> >> *4 One can also use sx_sleep() which atomically release this >> primative >> when going to sleep and reacquire it on wakeup. > > I think that we can do a better job describing the three main events > (spinning, blocking, sleeping) the correspondence with every primitive > and what is allowed to do (we can add an addictional paragraph about > preemption and its nits, sched_bind, sched_pin, critical sections, > etc.). > > Assuming that lock ordering is always important (not only in the > mutexes case) and that very soon all the primitives will allow > recursion (check for //depot/user/attilio/attilio_smpng/... for an > example fo recursive sx), it is not really important to deal with > these details. > I think would help having a section per-primitive describing the > better cases of usage for every primitive, i.e.: > > Spin Mutexes > - To be used only in interrupt context or for path really short, as > single assignment etc (even if in that case probabilly they can be > replaced by something more appropriate. when you get a few moments, check it out and add these features :-) That's why I committed it.. to give people something to start with so that they can add to it if they have just a few minutes free. > > This informations should be just integrative with the table you > previously mentioned and should not overlap. > > Attilio > > From owner-freebsd-current@FreeBSD.ORG Wed Mar 14 18:00:29 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3846E16A403; Wed, 14 Mar 2007 18:00:29 +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 DB36513C455; Wed, 14 Mar 2007 18:00:28 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.13.8/8.13.8) with ESMTP id l2EI0RZp078187; Wed, 14 Mar 2007 14:00:27 -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 l2EI0RVj028665; Wed, 14 Mar 2007 14:00:27 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 6587773039; Wed, 14 Mar 2007 13:00:27 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070314180027.6587773039@freebsd-current.sentex.ca> Date: Wed, 14 Mar 2007 13:00:27 -0500 (EST) X-Virus-Scanned: ClamAV version devel-20070102, clamav-milter version devel-111206 on clamscanner5 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: Wed, 14 Mar 2007 18:00:29 -0000 TB --- 2007-03-14 16:18:22 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-03-14 16:18:22 - starting HEAD tinderbox run for ia64/ia64 TB --- 2007-03-14 16:18:22 - cleaning the object tree TB --- 2007-03-14 16:18:45 - checking out the source tree TB --- 2007-03-14 16:18:45 - cd /tinderbox/HEAD/ia64/ia64 TB --- 2007-03-14 16:18:45 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-03-14 16:26:33 - building world (CFLAGS=-O2 -pipe) TB --- 2007-03-14 16:26:33 - cd /src TB --- 2007-03-14 16:26:33 - /usr/bin/make -B buildworld >>> World build started on Wed Mar 14 16:26:34 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 Wed Mar 14 17:42:40 UTC 2007 TB --- 2007-03-14 17:42:40 - generating LINT kernel config TB --- 2007-03-14 17:42:40 - cd /src/sys/ia64/conf TB --- 2007-03-14 17:42:40 - /usr/bin/make -B LINT TB --- 2007-03-14 17:42:40 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-03-14 17:42:40 - cd /src TB --- 2007-03-14 17:42:40 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Mar 14 17:42: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 [...] :> export_syms awk -f /src/sys/modules/cue/../../conf/kmod_syms.awk if_cue.kld export_syms | xargs -J% objcopy % if_cue.kld ld -Bshareable -d -warn-common -o if_cue.ko if_cue.kld objcopy --strip-debug if_cue.ko ===> cxgb (all) uudecode -p < /src/sys/modules/cxgb/../../dev/cxgb/t3fw-3.2.bin.gz.uu | gzip -dc > t3fw-3.2.bin t3fw-3.2.bin t3fw-3.2.bin ld: failed to merge target specific data of file t3fw-3.2.bin *** Error code 1 Stop in /src/sys/modules/cxgb. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-03-14 18:00:27 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-03-14 18:00:27 - ERROR: failed to build lint kernel TB --- 2007-03-14 18:00:27 - tinderbox aborted TB --- 0.59 user 1.87 system 6124.58 real http://tinderbox.des.no/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Wed Mar 14 22:40:47 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5B67816A404 for ; Wed, 14 Mar 2007 22:40:47 +0000 (UTC) (envelope-from db@nipsi.de) Received: from fop.bsdsystems.de (static.88-198-57-43.clients.your-server.de [88.198.57.43]) by mx1.freebsd.org (Postfix) with ESMTP id 2357813C459 for ; Wed, 14 Mar 2007 22:40:47 +0000 (UTC) (envelope-from db@nipsi.de) Received: from [172.16.1.13] (e176122167.adsl.alicedsl.de [85.176.122.167]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by fop.bsdsystems.de (Postfix) with ESMTP id 143042C363 for ; Wed, 14 Mar 2007 23:17:28 +0100 (CET) Message-ID: <45F87476.8060604@nipsi.de> Date: Wed, 14 Mar 2007 23:17:26 +0100 From: Dennis Berger User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: dl360 g4p / ciss controller not working on 7.0 snapshot from march X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Mar 2007 22:40:47 -0000 Hi list, FreeBSD 6.2 can be bootet correctly besides a strange 3 minute timeout after da0 has been detected on ciss0 FreeBSD 7.0 current from march or feb couldn't be bootet at all the kernel stuck after "pci2: on pcib6 found". Normally the kernel would find the ciss0 device after that, but it doesn't. and the kernel stuck. booting in verbose / safe /without acpi / disabling acpi related stuff in bios had no effect on this issue. Any hints whats going on with ciss driver on dl360 g4p box? regards, -Dennis From owner-freebsd-current@FreeBSD.ORG Thu Mar 15 01:57:42 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0B4E416A407 for ; Thu, 15 Mar 2007 01:57:42 +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 86BB213C457 for ; Thu, 15 Mar 2007 01:57:41 +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 4957069060B for ; Thu, 15 Mar 2007 01:58:27 +0000 (WET) Received: by core.fnop.net (Postfix, from userid 1015) id 0A7D369062E; Thu, 15 Mar 2007 01:58:27 +0000 (WET) X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on core.fnop.net X-Spam-Level: X-Spam-Status: No, score=-0.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,RCVD_IN_SORBS_DUL,UPPERCASE_25_50 autolearn=no version=3.1.7 Received: from epsilon.local (87-196-26-81.net.novis.pt [87.196.26.81]) by core.fnop.net (Postfix) with ESMTP id 93E8669060B for ; Thu, 15 Mar 2007 01:58:23 +0000 (WET) Message-ID: <45F8A80F.10407@fnop.net> Date: Thu, 15 Mar 2007 01:57:35 +0000 From: Rui Paulo User-Agent: Thunderbird 2.0b2 (Macintosh/20070116) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: multipart/mixed; boundary="------------070708030408060809090309" X-Virus-Scanned: ClamAV using ClamSMTP Subject: Apple's Mighty Mouse (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: Thu, 15 Mar 2007 01:57:42 -0000 This is a multi-part message in MIME format. --------------070708030408060809090309 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, The attached patch makes the wheel work correctly with in Apple's Mighty Mouse. Any comments? -- Rui Paulo | PGP: F0E4 C7C7 1653 79B7 78DC DD73 64FA B2C6 CF45 1F84 --------------070708030408060809090309 Content-Type: text/plain; x-mac-type="0"; x-mac-creator="0"; name="mightymouse.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="mightymouse.diff" Index: ums.c =================================================================== RCS file: /home/ncvs/src/sys/dev/usb/ums.c,v retrieving revision 1.83 diff -u -r1.83 ums.c --- ums.c 17 Jan 2007 03:50:45 -0000 1.83 +++ ums.c 15 Mar 2007 01:51:29 -0000 @@ -266,8 +266,16 @@ USB_ATTACH_ERROR_RETURN; } + /* Apple's Mighty Mouse reports HUG_Z as horizontal scrolling and + HUG_WHEEL as vertical scrolling. */ + if (uaa->vendor == USB_VENDOR_APPLE && + uaa->product == USB_PRODUCT_APPLE_OPTICALM) { + hid_locate(desc, size, HID_USAGE2(HUP_GENERIC_DESKTOP, + HUG_WHEEL), hid_input, &sc->sc_loc_z, &flags); + printf("mighty mouse\n"); + } /* try to guess the Z activator: first check Z, then WHEEL */ - if (hid_locate(desc, size, HID_USAGE2(HUP_GENERIC_DESKTOP, HUG_Z), + else if (hid_locate(desc, size, HID_USAGE2(HUP_GENERIC_DESKTOP, HUG_Z), hid_input, &sc->sc_loc_z, &flags) || hid_locate(desc, size, HID_USAGE2(HUP_GENERIC_DESKTOP, HUG_WHEEL), hid_input, &sc->sc_loc_z, &flags) || Index: usbdevs =================================================================== RCS file: /home/ncvs/src/sys/dev/usb/usbdevs,v retrieving revision 1.288 diff -u -r1.288 usbdevs --- usbdevs 27 Feb 2007 22:27:53 -0000 1.288 +++ usbdevs 15 Mar 2007 01:51:30 -0000 @@ -688,6 +688,7 @@ product APPLE IPOD_08 0x1208 iPod '08' product APPLE IPODVIDEO 0x1209 iPod Video product APPLE IPODNANO 0x120a iPod Nano +product APPLE OPTICALM 0x0304 Apple Optical USB Mouse /* Arkmicro Technologies */ product ARKMICRO ARK3116 0x0232 ARK3116 Serial --------------070708030408060809090309-- From owner-freebsd-current@FreeBSD.ORG Thu Mar 15 08:41:39 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EB0AF16A400 for ; Thu, 15 Mar 2007 08:41:39 +0000 (UTC) (envelope-from jerer606@student.liu.se) Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mx1.freebsd.org (Postfix) with ESMTP id 7DBD313C43E for ; Thu, 15 Mar 2007 08:41:39 +0000 (UTC) (envelope-from jerer606@student.liu.se) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 2632C200A1E2 for ; Thu, 15 Mar 2007 09:18:58 +0100 (CET) Received: from mail.lysator.liu.se ([127.0.0.1]) by localhost (lenin.lysator.liu.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 31398-01-100 for ; Thu, 15 Mar 2007 09:18:55 +0100 (CET) Received: from localhost (c83-252-204-215.bredband.comhem.se [83.252.204.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTP id 86CF0200A1EA for ; Thu, 15 Mar 2007 09:18:55 +0100 (CET) Date: Thu, 15 Mar 2007 09:25:39 +0000 From: Jerry Eriksson To: freebsd-current@freebsd.org Message-ID: <20070315092539.GA1300@procyon.mine.nu> References: <45EEC8D4.6050000@rambler.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45EEC8D4.6050000@rambler.ru> User-Agent: Mutt/1.4.2.2i X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at lysator.liu.se Subject: Re: glxgears in current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2007 08:41:40 -0000 On Wed, Mar 07, 2007 at 04:14:44PM +0200, Eugene Doer wrote: > I had tried to run glxgears in my FreeBSD 7-CURRENT, and got strange > results : X-server rebooted, but my processes werent killed, even > mplayer was producing sound. After this I logged on to KDE once more, > and tried again with same results. Mplayer & wget were working now in > background. Can anybody help ? > > /var/log/messages : > > Mar 7 15:59:38 doer kernel: pid 82971 (Xorg), uid 0: exited on signal 6 > Mar 7 15:59:38 doer kdm-bin[864]: X server for display :0 terminated > unexpectedly > > I'm using nvidia-driver-1.0.9746 binary drivers. > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" I have the same(?) problems when running glxgears/glxinfo on a system running current built yesterday with a intel card using the i810 driver and dri. My system does not hang at all, the only thing that happens is that glxgears/glxinfo segfaults. This is what I get when running it through GDB: dreamland> gdb glxinfo 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"...(no debugging symbols found)... (gdb) run Starting program: /usr/X11R6/bin/glxinfo (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...warning: Unable to get location for thread creation breakpoint: generic error [New LWP 100103] (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)... Program received signal SIGSEGV, Segmentation fault. [Switching to LWP 100103] 0x2823e743 in pthread_self () from /lib/libpthread.so.2 (gdb) bt #0 0x2823e743 in pthread_self () from /lib/libpthread.so.2 #1 0x2823edfc in pthread_rwlock_unlock () from /lib/libpthread.so.2 #2 0x2824a2b2 in pthread_join () from /lib/libpthread.so.2 #3 0x2823e74a in pthread_self () from /lib/libpthread.so.2 #4 0x2823edfc in pthread_rwlock_unlock () from /lib/libpthread.so.2 #5 0x2824a2b2 in pthread_join () from /lib/libpthread.so.2 #6 0x2823e74a in pthread_self () from /lib/libpthread.so.2 #7 0x2823edfc in pthread_rwlock_unlock () from /lib/libpthread.so.2 #8 0x2824a2b2 in pthread_join () from /lib/libpthread.so.2 #9 0x2823e74a in pthread_self () from /lib/libpthread.so.2 #10 0x2823edfc in pthread_rwlock_unlock () from /lib/libpthread.so.2 #11 0x2824a2b2 in pthread_join () from /lib/libpthread.so.2 #12 0x2823e74a in pthread_self () from /lib/libpthread.so.2 #13 0x2823edfc in pthread_rwlock_unlock () from /lib/libpthread.so.2 #14 0x2824a2b2 in pthread_join () from /lib/libpthread.so.2 #15 0x2823e74a in pthread_self () from /lib/libpthread.so.2 #16 0x2823edfc in pthread_rwlock_unlock () from /lib/libpthread.so.2 ... and so on Thanks, Jerry From owner-freebsd-current@FreeBSD.ORG Thu Mar 15 10:15:08 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AF18716A400 for ; Thu, 15 Mar 2007 10:15:08 +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 779D913C448 for ; Thu, 15 Mar 2007 10:15:08 +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:From:Subject:In-Reply-To:X-Attribution:Date:Message-Id; b=V/Frzw3SMXsUJ5pClm2GBZNgq8SzB+ghsIlsz+ue3LycB14hDOyYawU2PtFBqY1BICZXh1+kmWhpB44N2QftfTlfVTGcKFqC/5OdNX2E2PGEnBH+PaeeMYBtmKpzsoOGh5A7IKR2SGCSNCPhOxM9AOYzaYoo9XaybUYCnMm8p/HnnJW5kmoHOMZDSZceL0QPfeMglvOMMfRnf3iUI+kRpT+BbjIlU/brf4hzPsIZjHJment805L1bzaOFKYwDnN5; Received: from uucp by munchkin.clue.co.za with local (Exim 4.66) (envelope-from ) id 1HRmzD-0005U1-WC; Thu, 15 Mar 2007 10:15:08 +0000 Received: from cluetoy.clue.co.za ([10.0.0.19] helo=clue.co.za) by urchin.clue.co.za with esmtpa (Exim 4.66) (envelope-from ) id 1HRmyS-0000m0-Mr; Thu, 15 Mar 2007 10:14:20 +0000 Received: from localhost ([127.0.0.1]) by clue.co.za with esmtp (Exim 4.66 (FreeBSD)) (envelope-from ) id 1HRmyP-000110-Ae; Thu, 15 Mar 2007 12:14:17 +0200 To: freebsd-ipfw@FreeBSD.org, current@freebsd.org From: Ian FREISLICH In-Reply-To: Message from FreeBSD bugmaster of "Mon, 19 Feb 2007 11:08:20 GMT." <200702191108.l1JB8KDT021367@freefall.freebsd.org> X-Attribution: BOFH Date: Thu, 15 Mar 2007 12:14:17 +0200 Message-Id: Cc: Subject: Re: Current [ipfw] problem reports assigned to you X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Mar 2007 10:15:08 -0000 FreeBSD bugmaster wrote: > Current FreeBSD problem reports > Critical problems > Serious problems [snip] > 14 problems total. > > Non-critical problems [snip] > 20 problems total. I count 34 PRs here, some of which may no longer be problems, 18 of which have accompanying patches. The main problem, it appears, is that IPFW is mainterless at the moment as evidenced by src/MAINTAINERS: ipfw ipfw Pre-commit review preferred. send to ipfw@freebsd.org I have not seen much traffic on the ipfw list from people with commit bits in the last quite long while. I am willing to take on ipfw as maintainer. Is there someone willing to sponsor/mentor me? Ian -- Ian Freislich From owner-freebsd-current@FreeBSD.ORG Thu Mar 15 12:57:01 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 083E916A401 for ; Thu, 15 Mar 2007 12:57:01 +0000 (UTC) (envelope-from grafan@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.171]) by mx1.freebsd.org (Postfix) with ESMTP id 6F9CD13C459 for ; Thu, 15 Mar 2007 12:56:59 +0000 (UTC) (envelope-from grafan@gmail.com) Received: by ug-out-1314.google.com with SMTP id 71so308703ugh for ; Thu, 15 Mar 2007 05:56: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=Q5Ladr6vldPDcIlOScDK6oUJJ4lL+ko57DbUr8n7WgrtlJ6TAjMb+BnGrC2DTtbWOuOQMyMK/SSsHWETeBkveBNHJj9quIauMDtK1nBb5kazVoIgiCJ9bL7TUMcqWMsD8LnGUNezGIke/qmPvC2w8oKjGyMbaZ0zghuCjkfAwoE= 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=JaIZnCNDpiYXvhCtAXngs5wIz7CXCuUcun40lf71IZeNQI0hu3pcB20I2eCJJryD/RVRcxnQPSr0ILb1ll+A6YAi/dLl+NNPFkf+OQ/aLaYe8serdFvBpUHIf/PQH6u0t76q395AdEUwm1Mel3MywmGmIWTmEqQoYicnhIHK1iw= Received: by 10.78.120.6 with SMTP id s6mr318100huc.1173963417287; Thu, 15 Mar 2007 05:56:57 -0700 (PDT) Received: by 10.78.202.1 with HTTP; Thu, 15 Mar 2007 05:56:57 -0700 (PDT) Message-ID: <6eb82e0703150556u39ee7769s29fa73cbbbc25811@mail.gmail.com> Date: Thu, 15 Mar 2007 20:56:57 +0800 From: "Rong-en Fan" To: "Jack Vogel" In-Reply-To: <2a41acea0701221030x52dd8821pd858ae7e6740ce92@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <2a41acea0701171258k16b4c6ebuf1d4794b89d0749b@mail.gmail.com> <20070120065321.DB61216A405@hub.freebsd.org> <2a41acea0701201435g6f960b40r3cf0552d87ab2bfd@mail.gmail.com> <20070122083506.GW4485@FreeBSD.org> <2a41acea0701221030x52dd8821pd858ae7e6740ce92@mail.gmail.com> Cc: Bill Paul , jon.otterholm@ide.resurscentrum.se, Gleb Smirnoff , freebsd-stable@freebsd.org, freebsd-current@freebsd.org Subject: Re: Lenovo X60 em workaround X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Mar 2007 12:57:01 -0000 On 1/23/07, Jack Vogel wrote: > > Hey Gleb, > > Acknowledge... I can do better than that, I have a fix for this problem, and > its not temporary. Here is the code change (not a patch, I'm very busy), > its in hardware_init, should be obvious how to patch: > > /* Make sure we have a good EEPROM before we read from it */ > if (e1000_validate_nvm_checksum(&adapter->hw) < 0) { > /* > ** Some PCI-E parts fail the first check due to > ** the link being in sleep state, call it again, > ** if it fails a second time its a real issue. > */ > if (e1000_validate_nvm_checksum(&adapter->hw) < 0) { > device_printf(dev, > "The EEPROM Checksum Is Not Valid\n"); > return (EIO); > } > } > > This is already checked into my code base at Intel, I've just been too > busy to do anything with it, be my guest if you wish to check it in after > testing... I accidentally found this : http://www-307.ibm.com/pc/support/site.wss/document.do?sitestyle=lenovo&lndocid=MIGR-67166 which patches the eeprom. And it solves by problem. Regards, Rong-En Fan From owner-freebsd-current@FreeBSD.ORG Thu Mar 15 15:45:00 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 576FB16A402 for ; Thu, 15 Mar 2007 15:45:00 +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 F043F13C4C3 for ; Thu, 15 Mar 2007 15:44:59 +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 E915669078B for ; Thu, 15 Mar 2007 15:45:42 +0000 (WET) Received: by core.fnop.net (Postfix, from userid 1015) id 5ECE06907B4; Thu, 15 Mar 2007 15:45:42 +0000 (WET) X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on core.fnop.net X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.7 Received: from epsilon.local (out-alunos.ncc.up.pt [193.136.39.100]) by core.fnop.net (Postfix) with ESMTP id A083569078B for ; Thu, 15 Mar 2007 15:45:38 +0000 (WET) Message-ID: <45F969F5.5010303@fnop.net> Date: Thu, 15 Mar 2007 15:44:53 +0000 From: Rui Paulo User-Agent: Thunderbird 2.0b2 (Macintosh/20070116) MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <45F8A80F.10407@fnop.net> In-Reply-To: <45F8A80F.10407@fnop.net> Content-Type: multipart/mixed; boundary="------------080904070409090104030900" X-Virus-Scanned: ClamAV using ClamSMTP Subject: Re: Apple's Mighty Mouse (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: Thu, 15 Mar 2007 15:45:00 -0000 This is a multi-part message in MIME format. --------------080904070409090104030900 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Rui Paulo wrote: > Hi, > > The attached patch makes the wheel work correctly with in Apple's Mighty > Mouse. Even better: I synchronized the NetBSD version of ums.c with FreeBSD's. (only regarding to the Z/W axis). FreeBSD doesn't have mouse(4) support for the W axis but that should be easy to add. The patch is attached. Thanks in advance. -- Rui Paulo | PGP: F0E4 C7C7 1653 79B7 78DC DD73 64FA B2C6 CF45 1F84 --------------080904070409090104030900 Content-Type: text/plain; x-mac-type="0"; x-mac-creator="0"; name="mightymouse.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="mightymouse.diff" Index: ums.c =================================================================== RCS file: /home/ncvs/src/sys/dev/usb/ums.c,v retrieving revision 1.83 diff -u -p -r1.83 ums.c --- ums.c 17 Jan 2007 03:50:45 -0000 1.83 +++ ums.c 15 Mar 2007 15:36:35 -0000 @@ -104,7 +104,7 @@ struct ums_softc { u_char *sc_ibuf; u_int8_t sc_iid; int sc_isize; - struct hid_location sc_loc_x, sc_loc_y, sc_loc_z, sc_loc_t; + struct hid_location sc_loc_x, sc_loc_y, sc_loc_z, sc_loc_t, sc_loc_w; struct hid_location *sc_loc_btn; usb_callout_t callout_handle; /* for spurious button ups */ @@ -116,6 +116,7 @@ struct ums_softc { #define UMS_Z 0x01 /* z direction available */ #define UMS_SPUR_BUT_UP 0x02 /* spurious button up events */ #define UMS_T 0x04 /* aa direction available (tilt) */ +#define UMS_REVZ 0x08 /* Z-axis is reversed */ int nbuttons; #define MAX_BUTTONS 31 /* chosen because sc_buttons is int */ @@ -209,7 +210,7 @@ USB_ATTACH(ums) usbd_status err; char devinfo[1024]; u_int32_t flags; - int i; + int i, wheel; struct hid_location loc_btn; sc->sc_disconnected = 1; @@ -266,14 +267,44 @@ USB_ATTACH(ums) USB_ATTACH_ERROR_RETURN; } - /* try to guess the Z activator: first check Z, then WHEEL */ - if (hid_locate(desc, size, HID_USAGE2(HUP_GENERIC_DESKTOP, HUG_Z), - hid_input, &sc->sc_loc_z, &flags) || - hid_locate(desc, size, HID_USAGE2(HUP_GENERIC_DESKTOP, HUG_WHEEL), - hid_input, &sc->sc_loc_z, &flags) || - hid_locate(desc, size, HID_USAGE2(HUP_GENERIC_DESKTOP, HUG_TWHEEL), - hid_input, &sc->sc_loc_z, &flags)) { + /* Try the wheel first as the Z activator since it's tradition. */ + wheel = hid_locate(desc, size, HID_USAGE2(HUP_GENERIC_DESKTOP, + HUG_WHEEL), + hid_input, &sc->sc_loc_z, &flags); + + if (wheel) { + if ((flags & MOUSE_FLAGS_MASK) != MOUSE_FLAGS) { + printf("\n%s: Wheel report 0x%04x not supported\n", + device_get_nameunit(sc->sc_dev), flags); + sc->sc_loc_z.size = 0; /* Bad Z coord, ignore it */ + } else { + sc->flags |= UMS_Z; + if (!(uaa->vendor == USB_VENDOR_APPLE && + uaa->product == USB_PRODUCT_APPLE_OPTICALM)) { + /* Some wheels need the Z axis reversed. */ + sc->flags |= UMS_REVZ; + } + + } + /* + * We might have both a wheel and Z direction, if so put + * put the Z on the W coordinate. + */ + if (hid_locate(desc, size, HID_USAGE2(HUP_GENERIC_DESKTOP, + HUG_Z), + hid_input, &sc->sc_loc_w, &flags)) { + if ((flags & MOUSE_FLAGS_MASK) != MOUSE_FLAGS) { + printf("\n%s: Z report 0x%04x not supported\n", + device_get_nameunit(sc->sc_dev), flags); + sc->sc_loc_w.size = 0; /* Bad Z, ignore */ + } + } + } else if (hid_locate(desc, size, HID_USAGE2(HUP_GENERIC_DESKTOP, + HUG_Z), + hid_input, &sc->sc_loc_z, &flags)) { if ((flags & MOUSE_FLAGS_MASK) != MOUSE_FLAGS) { + printf("\n%s: Z report 0x%04x not supported\n", + device_get_nameunit(sc->sc_dev), flags); sc->sc_loc_z.size = 0; /* Bad Z coord, ignore it */ } else { sc->flags |= UMS_Z; @@ -424,7 +455,7 @@ ums_intr(xfer, addr, status) { struct ums_softc *sc = addr; u_char *ibuf; - int dx, dy, dz, dt; + int dx, dy, dz, dw, dt; int buttons = 0; int i; @@ -474,6 +505,9 @@ ums_intr(xfer, addr, status) dx = hid_get_data(ibuf, &sc->sc_loc_x); dy = -hid_get_data(ibuf, &sc->sc_loc_y); dz = -hid_get_data(ibuf, &sc->sc_loc_z); + dw = hid_get_data(ibuf, &sc->sc_loc_w); + if (sc->flags & UMS_REVZ) + dz = -dz; if (sc->flags & UMS_T) dt = -hid_get_data(ibuf, &sc->sc_loc_t); else @@ -482,16 +516,17 @@ ums_intr(xfer, addr, status) if (hid_get_data(ibuf, &sc->sc_loc_btn[i])) buttons |= (1 << UMS_BUT(i)); - if (dx || dy || dz || dt || (sc->flags & UMS_Z) + if (dx || dy || dz || dt || dw || (sc->flags & UMS_Z) || buttons != sc->status.button) { - DPRINTFN(5, ("ums_intr: x:%d y:%d z:%d t:%d buttons:0x%x\n", - dx, dy, dz, dt, buttons)); + DPRINTFN(5, ("ums_intr: x:%d y:%d z:%d w:%d t:%d buttons:0x%x\n", + dx, dy, dz, dw, dt, buttons)); sc->status.button = buttons; sc->status.dx += dx; sc->status.dy += dy; sc->status.dz += dz; - /* sc->status.dt += dt;*/ /* no way to export this yet */ + /* sc->status.dt += dt; */ /* no way to export this yet */ + /* sc->status.dw += dw; */ /* idem */ /* Discard data in case of full buffer */ if (sc->qcount == sizeof(sc->qbuf)) { Index: usbdevs =================================================================== RCS file: /home/ncvs/src/sys/dev/usb/usbdevs,v retrieving revision 1.288 diff -u -p -r1.288 usbdevs --- usbdevs 27 Feb 2007 22:27:53 -0000 1.288 +++ usbdevs 15 Mar 2007 15:36:36 -0000 @@ -688,6 +688,7 @@ product APPLE IPOD_07 0x1207 iPod '07' product APPLE IPOD_08 0x1208 iPod '08' product APPLE IPODVIDEO 0x1209 iPod Video product APPLE IPODNANO 0x120a iPod Nano +product APPLE OPTICALM 0x0304 Apple Optical USB Mouse /* Arkmicro Technologies */ product ARKMICRO ARK3116 0x0232 ARK3116 Serial @@ -1491,6 +1492,7 @@ product PRIMAX COMFORT 0x4d01 Comfort product PRIMAX MOUSEINABOX 0x4d02 Mouse-in-a-Box product PRIMAX PCGAUMS1 0x4d04 Sony PCGA-UMS1 + /* Prolific products */ product PROLIFIC PL2301 0x0000 PL2301 Host-Host interface product PROLIFIC PL2302 0x0001 PL2302 Host-Host interface --------------080904070409090104030900-- From owner-freebsd-current@FreeBSD.ORG Thu Mar 15 19:42:32 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D415716A400; Thu, 15 Mar 2007 19:42:32 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from smtp-3.dlr.de (smtp-3.dlr.de [195.37.61.187]) by mx1.freebsd.org (Postfix) with ESMTP id 2E8A413C458; Thu, 15 Mar 2007 19:42:31 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from [129.247.12.14] ([129.247.12.14]) by smtp-3.dlr.de with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Mar 2007 14:04:43 +0100 Message-ID: <45F6A169.9050008@dlr.de> Date: Tue, 13 Mar 2007 14:04:41 +0100 From: Hartmut Brandt User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Eygene Ryabinkin References: <20070313121106.GA96293@nagual.pp.ru> <20070313123717.GU58523@codelabs.ru> In-Reply-To: <20070313123717.GU58523@codelabs.ru> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Mar 2007 13:04:44.0215 (UTC) FILETIME=[2B654C70:01C76570] X-Mailman-Approved-At: Thu, 15 Mar 2007 20:57:39 +0000 Cc: current@freebsd.org Subject: Re: Bad gcc -O optimization cause core dump. What to do? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Mar 2007 19:42:32 -0000 Eygene Ryabinkin wrote: > Andrey, good day. > > >> It calls "puts(NULL)" with core dump. >> It means "printf("%s\n", NULL)" is overoptimized. >> BTW, things like "printf("1%s\n", NULL)" are not overoptimized. >> > > Yes, it is in the gcc/builtins.c::expand_builtin_printf(). Currently > it only handles "%s" and "%c". > > >> Any ideas? Is it right or needs to be fixed? >> > > It is definitely not right, since it produces the bad code. > And there are no compilation-time checks that can say for > sure will the argument for the "%s" be NULL: > ----- > $ cat 1.c > #include > > int main(void) > { > void *ptr = NULL; > func(ptr); > } > > int func(void *ptr) > { > printf("%s\n", ptr); > } > :: rea@codelabs : 15:31:43 : ~/xlam > $ cat 1.s > .file "1.c" > .text > .p2align 2,,3 > .globl main > .type main, @function > main: > pushl %ebp > movl %esp, %ebp > subl $8, %esp > andl $-16, %esp > subl $28, %esp > pushl $0 > call func > leave > ret > .size main, .-main > .p2align 2,,3 > .globl func > .type func, @function > func: > pushl %ebp > movl %esp, %ebp > subl $20, %esp > pushl 8(%ebp) > call puts > leave > ret > .size func, .-func > ----- > The possible way to proceed with this optimization is to have the > 'puts', but to enable runtime check for the NULL value. > > I see the following definition for the fn_puts in builtins.def: > ----- > DEF_EXT_LIB_BUILTIN (BUILT_IN_PUTS_UNLOCKED, "puts_unlocked", BT_FN_INT_CONST_STRING, ATTR_NOTHROW_NONNULL_1) > ----- > The ATTR_NOTHROW_NONNULL_1 makes me think that not all is lost and something > can be done with the NULL pointer. I am not very familiar with gcc > internals, but I will try to see if something can be changed. > The behaviour of gcc is correct. Passing NULL to the %s of printf() produces undefined behaviour. The compiler is free to do what ever it wants including burning your house. Depending on printf to print (null) or whatever is just bad programming. harti From owner-freebsd-current@FreeBSD.ORG Fri Mar 16 09:51:12 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 121B416A400 for ; Fri, 16 Mar 2007 09:51:12 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from smtp-1.dlr.de (smtp-1.dlr.de [195.37.61.185]) by mx1.freebsd.org (Postfix) with ESMTP id A2E6113C458 for ; Fri, 16 Mar 2007 09:51:11 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from knop-beagle.kn.op.dlr.de ([129.247.173.6]) by smtp-1.dlr.de over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Mar 2007 10:51:09 +0100 Date: Fri, 16 Mar 2007 10:51:06 +0100 (CET) From: Harti Brandt X-X-Sender: brandt_h@knop-beagle.kn.op.dlr.de To: freebsd-current@freebsd.org Message-ID: <20070316104749.J88087@knop-beagle.kn.op.dlr.de> X-OpenPGP-Key: harti@freebsd.org MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Content-ID: <20070316104754.K88087@knop-beagle.kn.op.dlr.de> X-OriginalArrivalTime: 16 Mar 2007 09:51:09.0812 (UTC) FILETIME=[9FE94B40:01C767B0] Subject: LOCAL_CREDS socket option X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Harti Brandt List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2007 09:51:12 -0000 Hi, is there any specific reason that we don't support the LOCAL_CREDS option for SOCK_DGRAM sockets in the local domain? It's documented in unix(4) for a long time and it looks like it is supported, for example, in NetBSD. harti From owner-freebsd-current@FreeBSD.ORG Fri Mar 16 10:14:14 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.ORG Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 30C5616A401 for ; Fri, 16 Mar 2007 10:14:14 +0000 (UTC) (envelope-from willy@Offermans.Rompen.nl) Received: from psmtp14.wxs.nl (psmtp14.wxs.nl [195.121.247.46]) by mx1.freebsd.org (Postfix) with ESMTP id BF41813C43E for ; Fri, 16 Mar 2007 10:14:13 +0000 (UTC) (envelope-from willy@Offermans.Rompen.nl) Received: from jerry.offrom.nl (ip5652b794.speed.planet.nl [86.82.183.148]) by psmtp14.wxs.nl (8.13.8/8.12.10) with ESMTP id l2EAlQr2000368; Wed, 14 Mar 2007 11:47:27 +0100 Received: from wiz.offrom.nl (wizvpn.offromvpn.nl [10.8.0.18]) by jerry.offrom.nl (8.13.6/8.13.6) with ESMTP id l2EAlNFP008718; Wed, 14 Mar 2007 11:47:23 +0100 (CET) (envelope-from willy@offrom.nl) Received: from willy by wiz.offrom.nl with local (Exim 4.50) id 1HRR12-0001kC-Dd; Wed, 14 Mar 2007 11:47:32 +0100 Date: Wed, 14 Mar 2007 11:47:32 +0100 From: Willy Offermans To: freebsd-stable@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Message-ID: <20070314104732.GA5794@wiz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i X-Virus-Scanned: ClamAV 0.90/2838/Wed Mar 14 08:33:07 2007 on jerry.offrom.nl X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=10.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on jerry.offrom.nl Cc: Subject: tap device at boot time X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Willy@Offermans.Rompen.nl List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2007 10:14:14 -0000 Dear FreeBSD friends, Is it possible to add and configure a tap device at boot time of FreeBSD? I mean the same as a normal NIC. In my rc.conf: ... ifconfig_xl0="inet 192.168.0.2 promisc netmask 255.255.255.0" ifconfig_rl0="inet 192.168.4.2 netmask 255.255.255.0" ifconfig_tap0="inet 10.8.0.1 netmask 255.255.255.0" ... and in my /boot/loader.conf: ... if_tap_load="YES" ... if_xl0 and if_rl0 are compiled into the kernel. Maybe it is even possible to set the MAC address of the tap device!? The tap device should be available before named and dhcpd have been started. In that way I can provide IP addresses over the tap device and add appropriate DNS entries. I like to run openvpn with tap devices and want to use the dhcpd server to provide IP addresses and update the named. This works quite well. However after reboot I always have to restart named and dhcpd again since the tap device becomes available after these services have started during boot. I guess this problem will be solved if the tap device is already available and configured before named and dhcpd have started. -- Met vriendelijke groeten, With kind regards, Mit freundlichen Gruessen, De jrus wah, Willy ************************************* W.K. Offermans Home: +31 45 544 49 44 Mobile: +31 653 27 16 23 e-mail: Willy@Offermans.Rompen.nl Powered by .... (__) \\\'',) \/ \ ^ .\._/_) www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Fri Mar 16 12:19:36 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9C09A16A402; Fri, 16 Mar 2007 12:19:36 +0000 (UTC) (envelope-from maxim@macomnet.ru) Received: from mp2.macomnet.net (mp2.macomnet.net [195.128.64.6]) by mx1.freebsd.org (Postfix) with ESMTP id 2541C13C448; Fri, 16 Mar 2007 12:19:35 +0000 (UTC) (envelope-from maxim@macomnet.ru) Received: from localhost (localhost.int.ru [127.0.0.1] (may be forged)) by mp2.macomnet.net (8.13.7/8.13.8) with ESMTP id l2GBvQIS091907; Fri, 16 Mar 2007 14:57:26 +0300 (MSK) (envelope-from maxim@macomnet.ru) Date: Fri, 16 Mar 2007 14:57:22 +0300 (MSK) From: Maxim Konovalov To: Harti Brandt In-Reply-To: <20070316104749.J88087@knop-beagle.kn.op.dlr.de> Message-ID: <20070316145524.T40420@mp2.macomnet.net> References: <20070316104749.J88087@knop-beagle.kn.op.dlr.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-current@freebsd.org Subject: Re: LOCAL_CREDS socket option X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Mar 2007 12:19:36 -0000 On Fri, 16 Mar 2007, 10:51+0100, Harti Brandt wrote: > > Hi, > > is there any specific reason that we don't support the LOCAL_CREDS > option for SOCK_DGRAM sockets in the local domain? It's documented > in unix(4) for a long time and it looks like it is supported, for > example, in NetBSD. IIRC it is supported. >From tools/regression/sockets/unix_cmsg/README: For SOCK_DGRAM sockets: ---------------------- [...] 3: Sending cmsgcred, receiving sockcred Server creates datagram socket and set socket option LOCAL_CREDS for it. Client sends one message with data and control message with SOCK_CREDS type to Server. Server should receive one message with data and control message with SCM_CREDS type followed by struct sockcred{} and this structure should contain correct information. -- Maxim Konovalov From owner-freebsd-current@FreeBSD.ORG Fri Mar 16 12:56:16 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 61FD716A401 for ; Fri, 16 Mar 2007 12:56:16 +0000 (UTC) (envelope-from maxim@macomnet.ru) Received: from mp2.macomnet.net (mp2.macomnet.net [195.128.64.6]) by mx1.freebsd.org (Postfix) with ESMTP id E296D13C4B9 for ; Fri, 16 Mar 2007 12:56:15 +0000 (UTC) (envelope-from maxim@macomnet.ru) Received: from localhost (localhost.int.ru [127.0.0.1] (may be forged)) by mp2.macomnet.net (8.13.7/8.13.8) with ESMTP id l2GCuDtT044444; Fri, 16 Mar 2007 15:56:14 +0300 (MSK) (envelope-from maxim@macomnet.ru) Date: Fri, 16 Mar 2007 15:56:13 +0300 (MSK) From: Maxim Konovalov To: Hartmut Brandt In-Reply-To: <45FA91CA.4030300@dlr.de> Message-ID: <20070316155548.M40420@mp2.macomnet.net> References: <20070316104749.J88087@knop-beagle.kn.op.dlr.de> <20070316145524.T40420@mp2.macomnet.net> <45FA91CA.4030300@dlr.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-current@freebsd.org Subject: Re: LOCAL_CREDS socket option X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Mar 2007 12:56:16 -0000 On Fri, 16 Mar 2007, 13:47+0100, Hartmut Brandt wrote: > Maxim Konovalov wrote: > > On Fri, 16 Mar 2007, 10:51+0100, Harti Brandt wrote: > > > > > > > Hi, > > > > > > is there any specific reason that we don't support the LOCAL_CREDS > > > option for SOCK_DGRAM sockets in the local domain? It's documented > > > in unix(4) for a long time and it looks like it is supported, for > > > example, in NetBSD. > > > > > > > IIRC it is supported. > > > > From tools/regression/sockets/unix_cmsg/README: > > > > For SOCK_DGRAM sockets: > > ---------------------- > > [...] > > 3: Sending cmsgcred, receiving sockcred > > > > Server creates datagram socket and set socket option LOCAL_CREDS > > for it. Client sends one message with data and control message with > > SOCK_CREDS type to Server. Server should receive one message with > > data and control message with SCM_CREDS type followed by struct > > sockcred{} and this structure should contain correct information. > > > > > Well, this comment does not actually mean, that the feature works - it just > means that the regression test tests it. If you look at uipc_usrreq.c: > > static struct protosw localsw[] = { > { > .pr_type = SOCK_STREAM, > .pr_domain = &localdomain, > .pr_flags = PR_CONNREQUIRED|PR_WANTRCVD|PR_RIGHTS, > .pr_ctloutput = &uipc_ctloutput, > .pr_usrreqs = &uipc_usrreqs > }, > { > .pr_type = SOCK_DGRAM, > .pr_domain = &localdomain, > .pr_flags = PR_ATOMIC|PR_ADDR|PR_RIGHTS, > .pr_usrreqs = &uipc_usrreqs > }, > > you see that .pr_ctloutput is NULL for SOCK_DGRAM sockets which > means they don't support any of the socket options described in > unix(4). Also I included that feature into bsnmp(1) where I found > out that it doesn't work. I've a patch to fix it, but wanted to know > whether it was left out on purpose or not. You are correct, it fails. SERVER: setsockopt(LOCAL_CREDS) for datagram socket: Protocol not available 3: Sending cmsgcred, receiving sockcred -- Maxim Konovalov From owner-freebsd-current@FreeBSD.ORG Fri Mar 16 12:47:14 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A365416A46F for ; Fri, 16 Mar 2007 12:47:14 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from smtp-3.dlr.de (smtp-3.dlr.de [195.37.61.187]) by mx1.freebsd.org (Postfix) with ESMTP id 4070213C455 for ; Fri, 16 Mar 2007 12:47:14 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from [129.247.12.22] ([129.247.12.22]) by smtp-3.dlr.de with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Mar 2007 13:47:12 +0100 Message-ID: <45FA91CA.4030300@dlr.de> Date: Fri, 16 Mar 2007 13:47:06 +0100 From: Hartmut Brandt User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Maxim Konovalov References: <20070316104749.J88087@knop-beagle.kn.op.dlr.de> <20070316145524.T40420@mp2.macomnet.net> In-Reply-To: <20070316145524.T40420@mp2.macomnet.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Mar 2007 12:47:12.0588 (UTC) FILETIME=[37D100C0:01C767C9] X-Mailman-Approved-At: Fri, 16 Mar 2007 13:07:36 +0000 Cc: freebsd-current@freebsd.org Subject: Re: LOCAL_CREDS socket option X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Mar 2007 12:47:14 -0000 Maxim Konovalov wrote: > On Fri, 16 Mar 2007, 10:51+0100, Harti Brandt wrote: > > >> Hi, >> >> is there any specific reason that we don't support the LOCAL_CREDS >> option for SOCK_DGRAM sockets in the local domain? It's documented >> in unix(4) for a long time and it looks like it is supported, for >> example, in NetBSD. >> > > IIRC it is supported. > > From tools/regression/sockets/unix_cmsg/README: > > For SOCK_DGRAM sockets: > ---------------------- > [...] > 3: Sending cmsgcred, receiving sockcred > > Server creates datagram socket and set socket option LOCAL_CREDS > for it. Client sends one message with data and control message with > SOCK_CREDS type to Server. Server should receive one message with > data and control message with SCM_CREDS type followed by struct > sockcred{} and this structure should contain correct information. > > Well, this comment does not actually mean, that the feature works - it just means that the regression test tests it. If you look at uipc_usrreq.c: static struct protosw localsw[] = { { .pr_type = SOCK_STREAM, .pr_domain = &localdomain, .pr_flags = PR_CONNREQUIRED|PR_WANTRCVD|PR_RIGHTS, .pr_ctloutput = &uipc_ctloutput, .pr_usrreqs = &uipc_usrreqs }, { .pr_type = SOCK_DGRAM, .pr_domain = &localdomain, .pr_flags = PR_ATOMIC|PR_ADDR|PR_RIGHTS, .pr_usrreqs = &uipc_usrreqs }, you see that .pr_ctloutput is NULL for SOCK_DGRAM sockets which means they don't support any of the socket options described in unix(4). Also I included that feature into bsnmp(1) where I found out that it doesn't work. I've a patch to fix it, but wanted to know whether it was left out on purpose or not. harti }; From owner-freebsd-current@FreeBSD.ORG Fri Mar 16 14:08:34 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BDAF116A400 for ; Fri, 16 Mar 2007 14:08:34 +0000 (UTC) (envelope-from grafan@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.191]) by mx1.freebsd.org (Postfix) with ESMTP id 52F5113C46E for ; Fri, 16 Mar 2007 14:08:34 +0000 (UTC) (envelope-from grafan@gmail.com) Received: by nf-out-0910.google.com with SMTP id k27so250262nfc for ; Fri, 16 Mar 2007 07:08: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:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Llu5HCCgNEiI4+ashO5ZZcd3lzl/ONY1mjY2vETYorYzxu8avlfxkav9+XtCkRMANakHk56fnjYMxLUzVZOKI4u25gHDEI/wXZftG42hyOZzG/LeDglKX3U7tuNviL8aBIeLNAdctZq/ToSt8uNrSuIcdwX+sa46Qfh8Z4B2s7E= 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=OblQ/g+PUq+bVJelQww2H+FJQKnWl/B3EKoXMoI1+ODBta16RcrPLw71HuiBbMxSzYQ3YduP7SkrqFnnSzvgVhevEG330QWOaK5PincZlfuzlwAGV/3uzGaEThYXDYEYhJtErsTIYn9fXzMnWdDn2EAgzs8OHTmcsGlkvOjcpsw= Received: by 10.78.200.3 with SMTP id x3mr1000612huf.1174054112983; Fri, 16 Mar 2007 07:08:32 -0700 (PDT) Received: by 10.78.202.1 with HTTP; Fri, 16 Mar 2007 07:08:32 -0700 (PDT) Message-ID: <6eb82e0703160708v36d0d081g5d43bee251f0bb3b@mail.gmail.com> Date: Fri, 16 Mar 2007 22:08:32 +0800 From: "Rong-en Fan" To: "FreeBSD Current" In-Reply-To: <6eb82e0612151202m6d283e33h530c91fe0662559a@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <6eb82e0612151043p46485043r6a14b93522e60487@mail.gmail.com> <6eb82e0612151202m6d283e33h530c91fe0662559a@mail.gmail.com> Subject: Re: vfs_hash_get panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Mar 2007 14:08:34 -0000 On 12/16/06, Rong-en Fan wrote: > On 12/16/06, Rong-en Fan wrote: > > I'm running amd64 SMP -current around Dec 14. It seems that I can reproduce > > this panic by 'mergemaster -iU' at /usr/src reliably. > > I did nothing but mergemater may not 100% reproduce this. > However, it seems that buildworld causes panic at different point > each time. I always do 'fsck -fy' each time after panic. Now > the host is in ddb again. > > > Fatal trap 12: page fault while in kernel mode > > cpuid = 0; apic id = 00 > > fault virtual address = 0x68 > > fault code = supervisor read data, page not present > > instruction pointer = 0x8:0xffffffff802e0ce3 > > stack pointer = 0x10:0xffffffffa0019510 > > frame pointer = 0x10:0xffffffffa0019570 > > code segment = base 0x0, limit 0xfffff, type 0x1b > > = DPL 0, pres 1, long 1, def32 0, gran 1 > > processor eflags = interrupt enabled, resume, IOPL = 0 > > current process = 786 (mtree) > > > > Due to no remote console attached, the console ddb backtrace > > is available at flickr: > > > > http://flickr.com/photos/rafan/323030710/ > > > > I put my kernel conf and kgdb output here: > > > > http://www.rafan.org/FreeBSD/panic/vfs_hash_get/KERNEL > > http://www.rafan.org/FreeBSD/panic/vfs_hash_get/kgdb.txt > > > > I saw there is another report on @hackers this Oct. But it seems > > the originator solves the problem by upgrading to latest RELENG_6. > > > > Any suggestions? I can provide more information if someone interested. For the record, it is solved by yesterday's commit to dev/sound/pci/hda/hdac.c by ariff@ (NOOP hda_dma_nocache). Regards, Rong-En Fan From owner-freebsd-current@FreeBSD.ORG Fri Mar 16 17:10:16 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6978E16A412 for ; Fri, 16 Mar 2007 17:10:16 +0000 (UTC) (envelope-from thierry.delhaise@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 F017C13C4BF for ; Fri, 16 Mar 2007 17:10:15 +0000 (UTC) (envelope-from thierry.delhaise@gmail.com) Received: by an-out-0708.google.com with SMTP id c24so630831ana for ; Fri, 16 Mar 2007 10:10:15 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:mime-version:content-transfer-encoding:message-id:content-type:to:from:subject:date:x-mailer; b=e4yTU4KJmnp/Y+SWP5YRcGrCGbyRikOv9+WA7l6Ynsw37Rf7TagmpO92mOASqvySKY8+n1JsszLOTVnGRHrz2x2GqgTPYryER9aJOlRWfLFgoYKCO06AXEzZSYNqlrwt/hDqfaonJn0l6/e5+KxaKgkAj3yo/k/Zn+ZDokzyM2I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:mime-version:content-transfer-encoding:message-id:content-type:to:from:subject:date:x-mailer; b=ENRynbUZbyTx02ykTmT2zgReZbKDYdhqy36zGnWzR/eOUH7Bn2M2CUcnRuJJN9PQw/HkX79aFLpGh7UDWZKQTkKQWYvXwW/+VGIYYl++4Dn70LlicI3vFzWgXoVQMaUuiUpTAUhbDmQG+hOHKaTifv/qIrh4MZkO1CU148/VUsA= Received: by 10.100.190.8 with SMTP id n8mr1700694anf.1174063469512; Fri, 16 Mar 2007 09:44:29 -0700 (PDT) Received: from ?192.168.1.2? ( [82.127.84.97]) by mx.google.com with ESMTP id a1sm4024906ugf.2007.03.16.09.44.28; Fri, 16 Mar 2007 09:44:28 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: quoted-printable Message-Id: <505E74B5-A64D-4B44-BFF1-B7A37124D135@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed To: freebsd-current@freebsd.org From: Thierry DELHAISE Date: Fri, 16 Mar 2007 17:44:25 +0100 X-Mailer: Apple Mail (2.752.2) Subject: xdm loging problem on CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2007 17:10:16 -0000 Hi all, I'm running CURRENT aka FreeBSD mercure.interne.delhaise.net 7.0-CURRENT FreeBSD 7.0-CURRENT =20 #4: Sun Mar 11 03:38:32 CET 2007 =20 root@mercure.interne.delhaise.net:/usr/obj/usr/src/sys/FBSD7 i386 In this full build I've one problem with xdm : messages:Mar 16 16:58:53 mercure xdm: in openpam_load_module(): no /=20 usr/lib/pam_nologin.so found but the module exist in the real place !! This is my final test (whith pam fullpath module name). The original /=20= etc/pam.d/xdm config file originaly do not contain fullpath for =20 module. This is just my final test. In fact the problem is : shortly it's a dlopen()/shared library loading problem (I can spend =20 time to explain to maintainer...). After quickly investigating libpam =20= code I 've dicovered the magic _openpam_debug ;-) So in gdb with _openpam_debug set to 1, I've got this : debug.log:Mar 16 16:59:26 mercure xdm: in openpam_dynamic(): /usr/lib/=20= pam_nologin.so: /lib/libutil.so.6: Undefined symbol "__use_pts" Where does come from __use_pts symbols ? it seems to me that =20 basically libpam missed a reference of an another shared lib =20 exporting this symbols but witch one ? Any advices, suggestions ? I can spend some time this night to =20 investigate more and may be provide a patch ... I sugest too that when something wrong append in the dlopen() call in =20= openpam_dynamic.c ( func openpam_dynamic() ) the dlerror() return =20 should be send to syslog ... It would help to know what its wrong =20 even if _openpam_debug is not set to 1 ... ;-) just mt 2 cts ;-) Thx in advance for any help (about __use_pts). Thierry =A8PS : Sorry for my poor shoolish english ;-)= From owner-freebsd-current@FreeBSD.ORG Fri Mar 16 17:21:41 2007 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5C86F16A402; Fri, 16 Mar 2007 17:21:41 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from anuket.mj.niksun.com (gwnew.niksun.com [65.115.46.162]) by mx1.freebsd.org (Postfix) with ESMTP id 10E4F13C448; Fri, 16 Mar 2007 17:21:40 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from niksun.com (anuket [10.70.0.5]) by anuket.mj.niksun.com (8.13.6/8.13.6) with ESMTP id l2GGuQpt095708; Fri, 16 Mar 2007 12:56:26 -0400 (EDT) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: acpi@FreeBSD.org Date: Fri, 16 Mar 2007 12:56:19 -0400 User-Agent: KMail/1.6.2 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200703161256.23996.jkim@FreeBSD.org> X-Virus-Scanned: ClamAV 0.88.6/2850/Fri Mar 16 07:05:03 2007 on anuket.mj.niksun.com X-Virus-Status: Clean Cc: current@FreeBSD.org Subject: [HEADSUP] ACPI-CA 20070126 import X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Mar 2007 17:21:41 -0000 I will import ACPI-CA 20070126 from Intel some time next week. Current mega-patch against -CURRENT is here: http://people.freebsd.org/~jkim/acpica-import-20070126.diff.gz (Note: Sorry, I had to gzip(1) it because it was too big.) This patch should fix many ACPI issues in -CURRENT (ACPI-CA 20051021), most notably memory leak. Full change log for ACPI-CA from the last import is here: http://people.freebsd.org/~jkim/acpica_changes_20051021_20070126.txt I believe it is quite stable because I have been using this patch on my primary desktop and laptop for a while and it was tested on amd64, i386, and ia64. However, since the patch is huge, I may have missed something. If you find something wrong, please let me know before it is too late. ;-) Little more info about the patch: ------------------------- Update ACPI-CA to 20070126 for -CURRENT. WARNING: DO NOT USE THIS PATCH FOR PRODUCTION! This patch removes five, adds ten, and touches 239 files. Don't forget '-p' option when you patch(1). Removed files: 5 files sys/contrib/dev/acpica/aeexec.c sys/contrib/dev/acpica/tbconvrt.c sys/contrib/dev/acpica/tbget.c sys/contrib/dev/acpica/tbgetall.c sys/contrib/dev/acpica/tbrsdt.c Added files: 10 files sys/contrib/dev/acpica/tbfadt.c sys/contrib/dev/acpica/tbfind.c sys/contrib/dev/acpica/utresrc.c sys/contrib/dev/acpica/uttrack.c sys/contrib/dev/acpica/common/adfile.c sys/contrib/dev/acpica/common/adwalk.c sys/contrib/dev/acpica/common/dmrestag.c sys/contrib/dev/acpica/common/dmtable.c sys/contrib/dev/acpica/common/dmtbdump.c sys/contrib/dev/acpica/common/dmtbinfo.c Modified files: 239 files sys/amd64/acpica/OsdEnvironment.c sys/amd64/acpica/madt.c sys/amd64/conf/NOTES sys/amd64/include/acpica_machdep.h sys/boot/i386/libi386/biosacpi.c sys/boot/ia64/ski/acpi_stub.c sys/conf/files sys/conf/options sys/contrib/dev/acpica/* sys/contrib/dev/acpica/common/* sys/contrib/dev/acpica/compiler/* sys/dev/acpi_support/acpi_asus.c sys/dev/acpi_support/acpi_fujitsu.c sys/dev/acpi_support/acpi_ibm.c sys/dev/acpica/acpi.c sys/dev/acpica/acpi_acad.c sys/dev/acpica/acpi_button.c sys/dev/acpica/acpi_cmbat.c sys/dev/acpica/acpi_cpu.c sys/dev/acpica/acpi_dock.c sys/dev/acpica/acpi_ec.c sys/dev/acpica/acpi_lid.c sys/dev/acpica/acpi_pci_link.c sys/dev/acpica/acpi_perf.c sys/dev/acpica/acpi_quirk.c sys/dev/acpica/acpi_resource.c sys/dev/acpica/acpi_throttle.c sys/dev/acpica/acpi_timer.c sys/dev/acpica/acpivar.h sys/dev/acpica/Osd/OsdDebug.c sys/dev/acpica/Osd/OsdMemory.c sys/dev/acpica/Osd/OsdSchedule.c sys/dev/acpica/Osd/OsdSynch.c sys/dev/acpica/Osd/OsdTable.c sys/i386/acpica/OsdEnvironment.c sys/i386/acpica/acpi_machdep.c sys/i386/acpica/madt.c sys/i386/conf/NOTES sys/i386/include/acpica_machdep.h sys/ia64/acpica/OsdEnvironment.c sys/ia64/acpica/madt.c sys/ia64/include/acpica_machdep.h sys/modules/Makefile sys/modules/acpi/Makefile sys/modules/acpi/acpi/Makefile sys/tools/acpi_quirks2h.awk usr.sbin/acpi/acpidb/Makefile usr.sbin/acpi/acpidb/acpidb.c usr.sbin/acpi/acpidump/acpi_user.c usr.sbin/acpi/iasl/Makefile ------------------------- Cheers, Jung-uk Kim From owner-freebsd-current@FreeBSD.ORG Fri Mar 16 17:29:58 2007 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 566DE16A408 for ; Fri, 16 Mar 2007 17:29:58 +0000 (UTC) (envelope-from nate@root.org) Received: from root.org (root.org [67.118.192.226]) by mx1.freebsd.org (Postfix) with ESMTP id 2621A13C44B for ; Fri, 16 Mar 2007 17:29:58 +0000 (UTC) (envelope-from nate@root.org) Received: (qmail 38559 invoked from network); 16 Mar 2007 17:29:57 -0000 Received: from ppp-71-139-35-160.dsl.snfc21.pacbell.net (HELO ?10.0.5.59?) (nate-mail@71.139.35.160) by root.org with ESMTPA; 16 Mar 2007 17:29:57 -0000 Message-ID: <45FAD457.7050803@root.org> Date: Fri, 16 Mar 2007 10:31:03 -0700 From: Nate Lawson User-Agent: Thunderbird 1.5.0.9 (X11/20070214) MIME-Version: 1.0 To: Jung-uk Kim References: <200703161256.23996.jkim@FreeBSD.org> In-Reply-To: <200703161256.23996.jkim@FreeBSD.org> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: acpi@FreeBSD.org, current@FreeBSD.org Subject: Re: [HEADSUP] ACPI-CA 20070126 import X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Mar 2007 17:29:58 -0000 Jung-uk Kim wrote: > I will import ACPI-CA 20070126 from Intel some time next week. > Current mega-patch against -CURRENT is here: > > http://people.freebsd.org/~jkim/acpica-import-20070126.diff.gz > > (Note: Sorry, I had to gzip(1) it because it was too big.) > > This patch should fix many ACPI issues in -CURRENT (ACPI-CA 20051021), > most notably memory leak. Full change log for ACPI-CA from the last > import is here: > > http://people.freebsd.org/~jkim/acpica_changes_20051021_20070126.txt > > I believe it is quite stable because I have been using this patch on > my primary desktop and laptop for a while and it was tested on amd64, > i386, and ia64. However, since the patch is huge, I may have missed > something. If you find something wrong, please let me know before it > is too late. ;-) Thank you very much for all your work. You've even improved other things along the way, not just the import. To clarify, this patch has also been run by me for a while and will be committed so if you're at all interested in testing, be sure to do so. If not, just accept the consequences via cvsup. And no whining! >:-) -- Nate From owner-freebsd-current@FreeBSD.ORG Fri Mar 16 18:35:50 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7413F16A404 for ; Fri, 16 Mar 2007 18:35:50 +0000 (UTC) (envelope-from thierry.delhaise@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.185]) by mx1.freebsd.org (Postfix) with ESMTP id D55DA13C4B0 for ; Fri, 16 Mar 2007 18:35:49 +0000 (UTC) (envelope-from thierry.delhaise@gmail.com) Received: by nf-out-0910.google.com with SMTP id k27so342467nfc for ; Fri, 16 Mar 2007 11:35:48 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:mime-version:content-transfer-encoding:message-id:content-type:to:from:subject:date:x-mailer; b=SGzxG7JquVrBx+c6bz/LlGNia9Hy6PhXxxWAK4LoTGh2RxSZQdibkyYeov9i/7HWlAl3aMObs0aMuLOUyR3f6mioiaIgZfhoZJL5iyzjG5rzBXwwtQtXyC4aTqd+bPEwt2zcFBsM7nNYVMDCC+Jxeka0bEWI0fCVJV+GOwmHMUw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:mime-version:content-transfer-encoding:message-id:content-type:to:from:subject:date:x-mailer; b=kuL0AdHcD6/uJUQbOrt6FgQrd3G4+oCyX8+R1EG4dPvNDpQ8QAiEAFZV4JbDDLGYiY9ZrdT2Iz11exHSx7FwV00VCSq0oliuKJSIZ1pH81qwUkLrYRoyDO3KZiXEm/EWRL3iu5peLtkD78t70/8EjB5bcr8U5UxQFv5ZKAzgOy8= Received: by 10.82.138.6 with SMTP id l6mr3694072bud.1174068480986; Fri, 16 Mar 2007 11:08:00 -0700 (PDT) Received: from ?192.168.1.2? ( [82.127.84.97]) by mx.google.com with ESMTP id g8sm7516717muf.2007.03.16.11.07.59; Fri, 16 Mar 2007 11:08:00 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: current@FreeBSD.org From: Thierry DELHAISE Date: Fri, 16 Mar 2007 19:07:57 +0100 X-Mailer: Apple Mail (2.752.2) Cc: Subject: xdm loging problem on CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2007 18:35:50 -0000 Hi all, I would like to report (suite to my previous post) that since the mistaken symbol is the function __use_pts() normaly owned by libc (if my previous dig in CURRENT was correct), I suspect a problem in MY OWN build tree : I can't imagine a problem relative to libc, I think many others would have encountered many problem before me. So I'm currently csup'ing CURRENT and will "buildworld, buildkernel, installkernel, installworld". Since I 've discovered the problem with xorg package, I've deinstalled xorg (but not xorg-libraries package since I've a dependency on I dont want to break) and will reinstall it via ports when my new system will be installed. I'll report here if the problem is again reproductible ... Best regards Thierry From owner-freebsd-current@FreeBSD.ORG Fri Mar 16 22:58:19 2007 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 202B116A401; Fri, 16 Mar 2007 22:58:19 +0000 (UTC) (envelope-from chris@hitnet.RWTH-Aachen.DE) Received: from mta-1.ms.rz.rwth-aachen.de (mta-1.ms.rz.RWTH-Aachen.DE [134.130.7.72]) by mx1.freebsd.org (Postfix) with ESMTP id C7FDD13C448; Fri, 16 Mar 2007 22:58:18 +0000 (UTC) (envelope-from chris@hitnet.RWTH-Aachen.DE) Received: from circe ([134.130.3.36]) by mta-1.ms.rz.RWTH-Aachen.de (Sun Java System Messaging Server 6.2-7.05 (built Sep 5 2006)) with ESMTP id <0JF0005DDPQNSY20@mta-1.ms.rz.RWTH-Aachen.de>; Fri, 16 Mar 2007 23:42:23 +0100 (CET) Received: from talos.rz.RWTH-Aachen.DE ([134.130.3.22]) by circe (MailMonitor for SMTP v1.2.2 ) ; Fri, 16 Mar 2007 23:42:23 +0100 (MET) Received: from bigboss.hitnet.rwth-aachen.de (bigspace.hitnet.RWTH-Aachen.DE [137.226.181.2]) by smarthost.rwth-aachen.de (8.13.8/8.13.1/1) with ESMTP id l2GMgNXc027106; Fri, 16 Mar 2007 23:42:23 +0100 Received: from haakonia.hitnet.rwth-aachen.de ([137.226.181.92]) by bigboss.hitnet.rwth-aachen.de with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1HSL7v-00013m-5W; Fri, 16 Mar 2007 23:42:23 +0100 Received: by haakonia.hitnet.rwth-aachen.de (Postfix, from userid 1001) id AECC23F429; Fri, 16 Mar 2007 23:42:22 +0100 (CET) Date: Fri, 16 Mar 2007 23:42:22 +0100 From: Christian Brueffer In-reply-to: <200703161256.23996.jkim@FreeBSD.org> To: Jung-uk Kim Message-id: <20070316224222.GD1926@haakonia.hitnet.RWTH-Aachen.DE> MIME-version: 1.0 Content-type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary=ZJcv+A0YCCLh2VIg Content-disposition: inline X-Operating-System: FreeBSD 6.2-STABLE X-PGP-Key: http://people.FreeBSD.org/~brueffer/brueffer.key.asc X-PGP-Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D References: <200703161256.23996.jkim@FreeBSD.org> User-Agent: Mutt/1.5.11 Cc: acpi@FreeBSD.org, current@FreeBSD.org Subject: Re: [HEADSUP] ACPI-CA 20070126 import X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Mar 2007 22:58:19 -0000 --ZJcv+A0YCCLh2VIg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Mar 16, 2007 at 12:56:19PM -0400, Jung-uk Kim wrote: > I will import ACPI-CA 20070126 from Intel some time next week. =20 > Current mega-patch against -CURRENT is here: >=20 > http://people.freebsd.org/~jkim/acpica-import-20070126.diff.gz >=20 > (Note: Sorry, I had to gzip(1) it because it was too big.) >=20 > This patch should fix many ACPI issues in -CURRENT (ACPI-CA 20051021),=20 > most notably memory leak. Full change log for ACPI-CA from the last=20 > import is here: >=20 > http://people.freebsd.org/~jkim/acpica_changes_20051021_20070126.txt >=20 > I believe it is quite stable because I have been using this patch on=20 > my primary desktop and laptop for a while and it was tested on amd64,=20 > i386, and ia64. However, since the patch is huge, I may have missed=20 > something. If you find something wrong, please let me know before it=20 > is too late. ;-) >=20 Thanks a lot for working on this! I get the following on boot on my T41p, which is a lot more verbose than it used to be. Is this the new default or will it be turned off once the code hits the tree? ACPI: RSDP @ 0x0xf6d70/0x0024 (v 2 IBM ) ACPI: XSDT @ 0x0x1ff6a6bd/0x004C (v 1 IBM TP-1R 0x00003210 LTP 0x00= 000000) ACPI: FACP @ 0x0x1ff6a800/0x00F4 (v 3 IBM TP-1R 0x00003210 IBM 0x000= 00001) ACPI Warning (tbfadt-0505): Optional field "Gpe1Block" has zero address or = length: 0 102C /0 [20070126] ACPI: DSDT @ 0x0x1ff6a9e7/0xC4E5 (v 1 IBM TP-1R 0x00003210 MSFT 0x01= 00000E) ACPI: FACS @ 0x0x1ff78000/0x0040 ACPI: SSDT @ 0x0x1ff6a9b4/0x0033 (v 1 IBM TP-1R 0x00003210 MSFT 0x01= 00000E) ACPI: ECDT @ 0x0x1ff76ecc/0x0052 (v 1 IBM TP-1R 0x00003210 IBM 0x000= 00001) ACPI: TCPA @ 0x0x1ff76f1e/0x0032 (v 1 IBM TP-1R 0x00003210 PTL 0x000= 00001) ACPI: BOOT @ 0x0x1ff76fd8/0x0028 (v 1 IBM TP-1R 0x00003210 LTP 0x00= 000001) Apart from that I haven't seen any regressions so far. - Christian --=20 Christian Brueffer chris@unixpages.org brueffer@FreeBSD.org GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D --ZJcv+A0YCCLh2VIg Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFF+x1ObHYXjKDtmC0RAhYbAKCSyr7NocycsOhog/GxaP/eYRCPwgCgtu3Y TOF6j+idI/SLKlksKBlRf+c= =rByJ -----END PGP SIGNATURE----- --ZJcv+A0YCCLh2VIg-- From owner-freebsd-current@FreeBSD.ORG Fri Mar 16 23:21:41 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BFC5416A400 for ; Fri, 16 Mar 2007 23:21:41 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from anuket.mj.niksun.com (gwnew.niksun.com [65.115.46.162]) by mx1.freebsd.org (Postfix) with ESMTP id 69B3313C455 for ; Fri, 16 Mar 2007 23:21:41 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from niksun.com (anuket [10.70.0.5]) by anuket.mj.niksun.com (8.13.6/8.13.6) with ESMTP id l2GN9Uuk017149; Fri, 16 Mar 2007 19:09:30 -0400 (EDT) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: Christian Brueffer Date: Fri, 16 Mar 2007 19:09:23 -0400 User-Agent: KMail/1.6.2 References: <200703161256.23996.jkim@FreeBSD.org> <20070316224222.GD1926@haakonia.hitnet.RWTH-Aachen.DE> In-Reply-To: <20070316224222.GD1926@haakonia.hitnet.RWTH-Aachen.DE> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200703161909.27843.jkim@FreeBSD.org> X-Virus-Scanned: ClamAV 0.88.6/2853/Fri Mar 16 15:48:54 2007 on anuket.mj.niksun.com X-Virus-Status: Clean Cc: freebsd-acpi@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: [HEADSUP] ACPI-CA 20070126 import X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Mar 2007 23:21:41 -0000 On Friday 16 March 2007 06:42 pm, Christian Brueffer wrote: > I get the following on boot on my T41p, which is a lot more verbose > than it used to be. Is this the new default or will it be turned > off once the code hits the tree? ------ >8 --- SNIP!!! --- >8 --- Yes and no. In fact, those are printed out from ACPI-CA itself and there is no option to turn it off. :-( > Apart from that I haven't seen any regressions so far. Great. Thanks for the report, Jung-uk Kim From owner-freebsd-current@FreeBSD.ORG Sat Mar 17 00:12:43 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B837C16A406 for ; Sat, 17 Mar 2007 00:12:43 +0000 (UTC) (envelope-from infofarmer@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 4EB1D13C448 for ; Sat, 17 Mar 2007 00:12:43 +0000 (UTC) (envelope-from infofarmer@gmail.com) Received: by ug-out-1314.google.com with SMTP id 71so822868ugh for ; Fri, 16 Mar 2007 17:12:42 -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=m0IDQaeDAssSxusvowKKwjOuzh2bMezKmLs/P/R/MFuoAcMf3mGlUabt1/o0vtN4ycOB+zfJi5lVi49y36agoL/0wp0b+GhQ5Hm9BFCZYYoqsUTSolN4MlVvGrDRWEnX6nkxsStjKkCfT4nyWMK3+pUFZuEYJw5mi7K6CGYmSPY= 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=RXmSOhJuwB7JISwACg8xa/3oGGI1pRMQcw5vbhaG9rO4/OrHb/Swva/TLpdQbHTwlj1i9DtmzSIzIyFzIbL4eALJ4wKrFIXjovGy0tR1kOG5hRYqrepWFOh6jDGg6I6JNph28uUW+b8OspLXaktrpBmeO1XMorivS0THFpWPDxU= Received: by 10.114.75.1 with SMTP id x1mr954483waa.1174090361383; Fri, 16 Mar 2007 17:12:41 -0700 (PDT) Received: by 10.114.201.2 with HTTP; Fri, 16 Mar 2007 17:12:41 -0700 (PDT) Message-ID: Date: Sat, 17 Mar 2007 03:12:41 +0300 From: "Andrew Pantyukhin" Sender: infofarmer@gmail.com To: "Jung-uk Kim" In-Reply-To: <200703161256.23996.jkim@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200703161256.23996.jkim@FreeBSD.org> X-Google-Sender-Auth: 8a638f79639c3dac Cc: acpi@freebsd.org, current@freebsd.org Subject: Re: [HEADSUP] ACPI-CA 20070126 import X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Mar 2007 00:12:43 -0000 Big thanks! Here's a dmesg just in case: http://bsd.cenkes.org/abc/dmesg.newacpi.bz2 My sleep button is now visible :-) No regressions spotted on my Turion64 x2 laptop. Thanks! From owner-freebsd-current@FreeBSD.ORG Sat Mar 17 00:25:05 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9A60816A401; Sat, 17 Mar 2007 00:25:05 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from anuket.mj.niksun.com (gwnew.niksun.com [65.115.46.162]) by mx1.freebsd.org (Postfix) with ESMTP id 3D5AC13C44C; Sat, 17 Mar 2007 00:25:05 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from niksun.com (anuket [10.70.0.5]) by anuket.mj.niksun.com (8.13.6/8.13.6) with ESMTP id l2H0P48e019164; Fri, 16 Mar 2007 20:25:04 -0400 (EDT) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-current@FreeBSD.org Date: Fri, 16 Mar 2007 20:24:59 -0400 User-Agent: KMail/1.6.2 References: <200703161256.23996.jkim@FreeBSD.org> In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200703162025.01587.jkim@FreeBSD.org> X-Virus-Scanned: ClamAV 0.88.6/2853/Fri Mar 16 15:48:54 2007 on anuket.mj.niksun.com X-Virus-Status: Clean Cc: Andrew Pantyukhin , freebsd-acpi@FreeBSD.org Subject: Re: [HEADSUP] ACPI-CA 20070126 import X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Mar 2007 00:25:05 -0000 On Friday 16 March 2007 08:12 pm, Andrew Pantyukhin wrote: > Big thanks! > > Here's a dmesg just in case: > http://bsd.cenkes.org/abc/dmesg.newacpi.bz2 Looks good. > My sleep button is now visible :-) Cool. I guess you meant it didn't work before? > No regressions spotted on my Turion64 x2 laptop. Thanks for the report, Jung-uk Kim From owner-freebsd-current@FreeBSD.ORG Sat Mar 17 00:59:15 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B13F416A402 for ; Sat, 17 Mar 2007 00:59:15 +0000 (UTC) (envelope-from infofarmer@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.239]) by mx1.freebsd.org (Postfix) with ESMTP id 6D9E013C455 for ; Sat, 17 Mar 2007 00:59:15 +0000 (UTC) (envelope-from infofarmer@gmail.com) Received: by wr-out-0506.google.com with SMTP id 36so750501wra for ; Fri, 16 Mar 2007 17:59: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:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=ijN2i6g5yXC4/Il5lRpNIcKmjEfKlBxLL43GnBPQNqySdHbBjx1mwglXcyssaSSamIq9p+vlM++UEOEcEiMO1oViEggFGWHCWNUxBfA6apaPIQToY73TJidESgWa7rWeDSaYFXiKrBJuQ6WO2xXmIhf9vr/z90UpN7xLz7/OA4U= 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=In2jlGXRaPSs+6he5haI44+HjWq/saOs7GURbh23JpeTcY3teaa2K2aUT7SfW+HY2OnfLuZoJwmhb6T9sqckVGnO0tjxWs15yoHAAOH0tHZAKW6Gu8SK6zk7qLtdbZXEnbMC8A0pb2LBlFxgwUMnWMg/IQVr7UG4mLREzUFx2a8= Received: by 10.114.151.13 with SMTP id y13mr951496wad.1174093154119; Fri, 16 Mar 2007 17:59:14 -0700 (PDT) Received: by 10.114.201.2 with HTTP; Fri, 16 Mar 2007 17:59:14 -0700 (PDT) Message-ID: Date: Sat, 17 Mar 2007 03:59:14 +0300 From: "Andrew Pantyukhin" Sender: infofarmer@gmail.com To: "Jung-uk Kim" In-Reply-To: <200703162025.01587.jkim@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200703161256.23996.jkim@FreeBSD.org> <200703162025.01587.jkim@FreeBSD.org> X-Google-Sender-Auth: 6d5962bd9b4481a0 Cc: freebsd-acpi@freebsd.org, freebsd-current@freebsd.org Subject: Re: [HEADSUP] ACPI-CA 20070126 import X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Mar 2007 00:59:15 -0000 On 3/17/07, Jung-uk Kim wrote: > On Friday 16 March 2007 08:12 pm, Andrew Pantyukhin wrote: > > Big thanks! > > > > Here's a dmesg just in case: > > http://bsd.cenkes.org/abc/dmesg.newacpi.bz2 > > Looks good. > > > My sleep button is now visible :-) > > Cool. I guess you meant it didn't work before? Hmm. Now that I've checked some older logs it did. Just forgot about it altogether :) From owner-freebsd-current@FreeBSD.ORG Sat Mar 17 02:22:47 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BAC2016A401 for ; Sat, 17 Mar 2007 02:22:47 +0000 (UTC) (envelope-from infofarmer@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 535C913C455 for ; Sat, 17 Mar 2007 02:22:47 +0000 (UTC) (envelope-from infofarmer@gmail.com) Received: by ug-out-1314.google.com with SMTP id 71so839095ugh for ; Fri, 16 Mar 2007 19:22:46 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; b=FUzaZfgYyMzNuxSM2RIS3Au4tMpUnS/eKo+a/FPVWfq9wCdqNKIWAB76kCh5KvrK+OfCGQHAfjkICqvQYEB53oacwT1spxl3rllpY8qrU/WQWKCEGM5Gg0h+xduTs3WYO34ODbir4oA584LQlW4Gks9qKaxW6KPvqVIih3Ehj+o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; b=eKbRoY4P/SYwz7cLRgh+3zrmuARnDI/95pZMsU8ARbhCob+OXItpZyPmdhWQPK2NBx3beb1s4LWlms0wpbwmOp4dbEopj74+p+/QDELfYKzAgcX3BOv1wXHSvCTYy4ItxqlcyUx5BCXFvqGmUni8cBJqp2IOMYlNwTluMk3+ANY= Received: by 10.114.148.1 with SMTP id v1mr975368wad.1174098165551; Fri, 16 Mar 2007 19:22:45 -0700 (PDT) Received: by 10.114.201.2 with HTTP; Fri, 16 Mar 2007 19:22:45 -0700 (PDT) Message-ID: Date: Sat, 17 Mar 2007 05:22:45 +0300 From: "Andrew Pantyukhin" Sender: infofarmer@gmail.com To: "FreeBSD Current" MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Google-Sender-Auth: a4a32a2f7bfe76ce Cc: Ariff Abdullah Subject: sound/snd_hda regression X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Mar 2007 02:22:47 -0000 -pcm0: +pcm0: this is the only diff between verbose dmesg, which is here (newacpi makes no difference): http://bsd.cenkes.org/abc/dmesg.newacpi.bz2 The new revision produces loud electronic noise, like very short looping, which makes the sound card virtually unusable. Thanks! From owner-freebsd-current@FreeBSD.ORG Sat Mar 17 02:39:00 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from misaki (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with SMTP id 842AC16A400; Sat, 17 Mar 2007 02:38:59 +0000 (UTC) (envelope-from ariff@FreeBSD.org) Date: Sat, 17 Mar 2007 10:38:47 +0800 From: Ariff Abdullah To: "Andrew Pantyukhin" Message-Id: <20070317103847.51960145.ariff@FreeBSD.org> In-Reply-To: References: Organization: FreeBSD X-Mailer: /usr/local/lib/ruby/1.8/net/smtp.rb Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="PGP-SHA1"; boundary="Signature=_Sat__17_Mar_2007_10_38_47_+0800_JIhe18g6zGaEUQXo" Cc: current@freebsd.org Subject: Re: sound/snd_hda regression X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Mar 2007 02:39:00 -0000 --Signature=_Sat__17_Mar_2007_10_38_47_+0800_JIhe18g6zGaEUQXo Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, 17 Mar 2007 05:22:45 +0300 "Andrew Pantyukhin" wrote: > -pcm0: > +pcm0: Latest revision is 20070317_0042. Please update all sound sources. #freebsd-azalia. >=20 > this is the only diff between verbose dmesg, which > is here (newacpi makes no difference): > http://bsd.cenkes.org/abc/dmesg.newacpi.bz2 >=20 > The new revision produces loud electronic noise, > like very short looping, which makes the sound > card virtually unusable. >=20 -- Ariff Abdullah FreeBSD ... Recording in stereo is obviously too advanced and confusing for us idiot ***** users :P ........ --Signature=_Sat__17_Mar_2007_10_38_47_+0800_JIhe18g6zGaEUQXo Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFF+1S3lr+deMUwTNoRAjJoAKC8OV8g7uebDXe449pRm2kXjgs+3gCgsZ9z Mg0aCvsiWWGj+RtfMfb4fOA= =huY9 -----END PGP SIGNATURE----- --Signature=_Sat__17_Mar_2007_10_38_47_+0800_JIhe18g6zGaEUQXo-- From owner-freebsd-current@FreeBSD.ORG Sat Mar 17 08:13:05 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7360916A402 for ; Sat, 17 Mar 2007 08:13:05 +0000 (UTC) (envelope-from duane@dwlabs.ca) Received: from smtpout.eastlink.ca (smtpout.eastlink.ca [24.222.0.30]) by mx1.freebsd.org (Postfix) with ESMTP id 3248B13C448 for ; Sat, 17 Mar 2007 08:13:05 +0000 (UTC) (envelope-from duane@dwlabs.ca) Received: from ip02.eastlink.ca ([24.222.10.10]) by mta01.eastlink.ca (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTP id <0JF1009ILERLW1H1@mta01.eastlink.ca> for freebsd-current@freebsd.org; Sat, 17 Mar 2007 04:42:57 -0300 (ADT) Received: from blk-224-199-230.eastlink.ca (HELO dwpc.dwlabs.ca) ([24.224.199.230]) by ip02.eastlink.ca with ESMTP; Sat, 17 Mar 2007 04:42:58 -0300 Received: from dwpc.dwlabs.ca (www.dwlabs.ca [192.168.0.10]) by dwpc.dwlabs.ca (8.13.8/8.13.8) with ESMTP id l2H7cuRi059791; Sat, 17 Mar 2007 04:39:02 -0300 (ADT envelope-from duane@dwpc.dwlabs.ca) Received: (from duane@localhost) by dwpc.dwlabs.ca (8.13.8/8.13.8/Submit) id l2H7ctkj059790; Sat, 17 Mar 2007 04:38:55 -0300 (ADT envelope-from duane) Date: Sat, 17 Mar 2007 04:38:55 -0300 From: Duane Whitty In-reply-to: <45F73AE7.6010508@elischer.org> To: Julian Elischer , Duane Whitty Message-id: <20070317073855.GA58662@dwpc.dwlabs.ca> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_kUUvEUDVInxTTnzno43fcA)" Content-disposition: inline X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAADc5+0UY4Mfmfmdsb2JhbACBZ412Ag X-IronPort-AV: i="4.14,295,1170648000"; d="scan'208"; a="123603942:sNHT36953154" X-Virus-Scanned: ClamAV 0.88.6/2853/Fri Mar 16 15:48:54 2007 on dwpc.dwlabs.ca X-Virus-Status: Clean X-Spam-Checker-Version: SpamAssassin 3.1.4 (2006-07-25) on dwpc.dwlabs.ca References: <200703092241.l29Mf2Ds062856@repoman.freebsd.org> <200703121535.22140.jhb@freebsd.org> <20070312200345.GB5688@garage.freebsd.pl> <200703121618.41084.jhb@freebsd.org> <45F5E1F9.5090806@elischer.org> <20070313010309.Q25395@fledge.watson.org> <45F73AE7.6010508@elischer.org> User-Agent: Mutt/1.4.2.2i X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00, UNPARSEABLE_RELAY autolearn=ham version=3.1.4 Cc: freebsd-current@freebsd.org Subject: Re: [RFC] locking.9 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Duane Whitty List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Mar 2007 08:13:05 -0000 --Boundary_(ID_kUUvEUDVInxTTnzno43fcA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline On Tuesday, 13 March 2007 at 16:59:35 -0700, Julian Elischer wrote: > resend to the right place with a corrected attachment. > > Robert Watson wrote: > > > >The idea of a locking(9) has been kicked around for a while, and its > >time has definitely come. It would summarize the properties and cross > >reference the man pages of the various primitives, and suggest a > >preference and strategy for using them in new code vs. existing code, > >etc. Distinguishing dimensions would include things like whether it is > >sleepable, supports priority propagation, can be acquired in interrupt > >context (a result of the prior two properties), whether it is fair, etc, > >etc. And include stern warnings about not using lockmgr in new code :-). > > > >Robert N M Watson > >Computer Laboratory > >University of Cambridge > > > ok so how about I commit this to get us started and the nroff and > locking experts can take it from there. > > This is great! Thank you on behalf of newcomers everywhere. It turns out the man9 page doesn't get installed. I've attached the patch for /usr/src/share/man/man9/Makefile so that this gets installed. I'm looking forward to reading this and I know I'll learn a lot. Duane Whitty > .\" > .\" Copyright (c) 1998 Berkeley Software Design, Inc. All rights reserved. > .\" > .\" Redistribution and use in source and binary forms, with or without > .\" modification, are permitted provided that the following conditions > .\" are met: > .\" 1. Redistributions of source code must retain the above copyright > .\" notice, this list of conditions and the following disclaimer. > .\" 2. Redistributions in binary form must reproduce the above copyright > .\" notice, this list of conditions and the following disclaimer in the > .\" documentation and/or other materials provided with the distribution. > .\" 3. Berkeley Software Design Inc's name may not be used to endorse or > .\" promote products derived from this software without specific prior > .\" written permission. > .\" > .\" THIS SOFTWARE IS PROVIDED BY BERKELEY SOFTWARE DESIGN INC ``AS IS'' AND > .\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE > .\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE > .\" ARE DISCLAIMED. IN NO EVENT SHALL BERKELEY SOFTWARE DESIGN INC BE LIABLE > .\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL > .\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS > .\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) > .\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT > .\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY > .\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF > .\" SUCH DAMAGE. > .\" > .\" from BSDI $Id: mutex.4,v 1.1.2.3 1998/04/27 22:53:13 ewv Exp $ > .\" $FreeBSD: src/share/man/man9/mutex.9,v 1.54 2007/03/09 22:41:01 jhb Exp $ > .\" > .Dd March 14, 2007 > .Dt LOCKING 9 > .Os > .Sh NAME > .Nm locking , > .Nd kernel synchronization primitives > .Sh SYNOPSIS > All sorts of stuff to go here. > .Pp > .Sh DESCRIPTION > The > .Em > FreeBSD > kernel is written to run across multiple CPUs and as such requires > several different sychronization primatives to allow the developers > to safely access and manipulate the many data types required. > .Pp > These include: > .Bl -enum > .It > Spin Mutexes > .It > Sleep Mutexes > .It > pool Mutexes > .It > Shared-Exclusive locks > .It > Reader-Writer locks > .It > Turnstyles > .It > Semaphores > .It > Condition variables > .It > Sleep/wakeup > .It > Giant > .It > Lockmanager locks > .El > > .Pp > The primnatives interact and have a number of rules regarding how > they can and can not be combined. Ther eare too many for the average humanmind and they > keep changing. (if you disagree, please write replacement text) :-) > .Pp > Some of these primatives may be used at the low (interrupt) level and some may not. > .Pp > There are strict ordering requirements and for some of the types this > is checked using the > .Xr witness 4 > code. > .Pp > .Ss SPIN Mutexes > Mutexes are the basic primative. > You either hold it or you don't. > If you don't own it then you just spin, waiting for teh holder (on another CPU) > to release it. Hopefully they are doing something fast. You can not do anythign that > deschedules the thread while you are holding a SPIN mutex. > .Ss Sleep Mutexes > Basically sleep (regular) mutexes will deschedule the thread if > the mutex can not be acquired. As in spin mutexes, you either get it or you don't. > You may call the > .Xr sleep 9 > call > .Fn msleep > or the new > .Fn mtx_sleep > variant. These will atomically drop the mutex and reacquire it > as part of waking up. > .Ss Pool Mutexes > A variant of SLEEP mutexes where the allocation of the mutex is handled more by the system. > .Ss Sx_locks > Shared/exclusive locks are used to protect data that are read far more often > than they are written. > Mutexes are inherently more efficient than shared/exclusive locks, so > shared/exclusive locks should be used prudently. > A thread may hold a shared or exclusive lock on an > .Em sx_lock > lock while sleeping. > As a result, an > .Em sx_lockm > lock may not be acquired while holding a mutex. > Otherwise, if one thread slept while holding an > .Em sx_lockm > lock while another thread blocked on the same > .Em sx_lockm > lock after acquiring a mutex, then the second thread would effectively > end up sleeping while holding a mutex, which is not allowed. > .Ss Rw_locks > Reader/writer locks allow shared access to protected data by multiple threads, > or exclusive access by a single thread. > The threads with shared access are known as > .Em readers > since they only read the protected data. > A thread with exclusive access is known as a > .Em writer > since it can modify protected data. > .Pp > Although reader/writer locks look very similar to > .Xr sx 9 > locks, their usage pattern is different. > Reader/writer locks can be treated as mutexes (see > .Xr mutex 9 ) > with shared/exclusive semantics. > Unlike > .Xr sx 9 , > an > .Em rw_lock > can be locked while holding a non-spin mutex, and an > .Em rw_lock > cannot be held while sleeping. > The > .Em rw_lock > locks have priority propagation like mutexes, but priority > can be propagated only to an exclusive holder. > This limitation comes from the fact that shared owners > are anonymous. > Another important property is that shared holders of > .Em rw_lock > can recurse, > but exclusive locks are not allowed to recurse. > .Ss Turnstyless > Turnstiles are used to hold a queue of threads blocked on > non-sleepable locks. Sleepable locks use condition variables to > implement their queues. Turnstiles differ from a sleep queue in that > turnstile queue's are assigned to a lock held by an owning thread. Thus, > when one thread is enqueued onto a turnstile, it can lend its priority > to the owning thread. > .Ss Semaphores > .Ss Condition variables > Condition variables are used in conjunction with mutexes to wait for conditions > to occur. > A thread must hold the mutex before calling the > .Fn cv_wait* , > functions. > When a thread waits on a condition, the mutex > is atomically released before the thread is blocked, then reacquired > before the function call returns. > .Ss Giant > Giant is a special instance of a sleep lock. > it has several special characteristics. > .Ss Sleep/wakeup > The functions > .Fn tsleep , > .Fn msleep , > .Fn msleep_spin , > .Fn pause , > .Fn wakeup , > and > .Fn wakeup_one > handle event-based thread blocking. > If a thread must wait for an > external event, it is put to sleep by > .Fn tsleep , > .Fn msleep , > .Fn msleep_spin , > or > .Fn pause . > Threads may also wait using one of the locking primitive sleep routines > .Xr mtx_sleep 9 , > .Xr rw_sleep 9 , > or > .Xr sx_sleep 9 . > .Pp > The parameter > .Fa chan > is an arbitrary address that uniquely identifies the event on which > the thread is being put to sleep. > All threads sleeping on a single > .Fa chan > are woken up later by > .Fn wakeup , > often called from inside an interrupt routine, to indicate that the > resource the thread was blocking on is available now. > .Pp > Several of the sleep functions including > .Fn msleep , > .Fn msleep_spin , > and the locking primitive sleep routines specify an additional lock > parameter. > The lock will be released before sleeping and reacquired > before the sleep routine returns. > If > .Fa priority > includes the > .Dv PDROP > flag, then > the lock will not be reacquired before returning. > The lock is used to ensure that a condition can be checked atomically, > and that the current thread can be suspended without missing a > change to the condition, or an associated wakeup. > In addition, all of the sleep routines will fully drop the > .Va Giant > mutex > (even if recursed) > while the thread is suspended and will reacquire the > .Va Giant > mutex before the function returns. > .Pp > .Ss lockmanager locks > Largly deprecated. See the > .Xr lock 9 > page for more information. > I don't know what the downsides are but I'm sure someone will fill in this part. > .Sh Interaction tables. > the following table shows what you can an d can not do if you hold > one of the synchronisation primatives discussed here: > (someone who knows what they are talking about should write this table) > .Bl -column ".Ic You have: You want:" ".Xr sleep" ".Xr sc_lock" ".Xr rw_lock" -offset indent > .It Xo > .Em "You have: You want:" Ta Xr sleep Ta Xr sx_lock Ta Xr rw_lock > .Xc > .It Ic SPIN mutex Ta \&tough Ta \&tough Ta \&tough > .It Ic Sleep mutex Ta \&ok Ta \&??? Ta \&??? > .El > .Sh SEE ALSO > .Xr condvar 9 , > .Xr lock 9 > .Xr mtx_pool 9 , > .Xr rwlock 9 , > .Xr sema 9 , > .Xr sleep 9 , > .Xr sx 9 > .Xr LOCK_PROFILING 9 , > .Xr WITNESS 9 , > .Sh HISTORY > These > functions appeared in > .Bsx 4.1 > through > .Fx 7.0 > _______________________________________________ > 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" --Boundary_(ID_kUUvEUDVInxTTnzno43fcA) Content-type: text/plain; NAME=Makefile.patch; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline; filename=Makefile.patch --- /usr/src/share/man/man9/Makefile.old Fri Mar 16 20:14:48 2007 +++ /usr/src/share/man/man9/Makefile Fri Mar 16 20:09:01 2007 @@ -133,6 +133,7 @@ kthread.9 \ ktr.9 \ lock.9 \ + locking.9 \ LOCK_PROFILING.9 \ mac.9 \ make_dev.9 \ --Boundary_(ID_kUUvEUDVInxTTnzno43fcA)-- From owner-freebsd-current@FreeBSD.ORG Sat Mar 17 10:39:36 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5F22116A401; Sat, 17 Mar 2007 10:39:36 +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 12DD713C4B0; Sat, 17 Mar 2007 10:39:35 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (p54A5D5D3.dip.t-dialin.net [84.165.213.211]) by redbull.bpaserver.net (Postfix) with ESMTP id 9C40B2E139; Sat, 17 Mar 2007 11:39:31 +0100 (CET) Received: from Magellan.Leidinger.net (Magellan.Leidinger.net [192.168.1.1]) by outgoing.leidinger.net (Postfix) with ESMTP id 93E985B4817; Sat, 17 Mar 2007 11:39:28 +0100 (CET) Date: Sat, 17 Mar 2007 11:39:28 +0100 From: Alexander Leidinger To: Nate Lawson Message-ID: <20070317113928.0543fdac@Magellan.Leidinger.net> In-Reply-To: <45FAD457.7050803@root.org> References: <200703161256.23996.jkim@FreeBSD.org> <45FAD457.7050803@root.org> X-Mailer: Claws Mail 2.8.1 (GTK+ 2.10.9; i686-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=-15.364, required 8, autolearn=not spam, BAYES_00 -15.00, DK_POLICY_SIGNSOME 0.00, FORGED_RCVD_HELO 0.14, SMILEY -0.50) X-BPAnet-MailScanner-From: alexander@leidinger.net X-Spam-Status: No Cc: acpi@FreeBSD.org, current@FreeBSD.org, Jung-uk Kim Subject: Re: [HEADSUP] ACPI-CA 20070126 import X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Mar 2007 10:39:36 -0000 Quoting Nate Lawson (Fri, 16 Mar 2007 10:31:03 -0700): > Jung-uk Kim wrote: > > I will import ACPI-CA 20070126 from Intel some time next week. > > Current mega-patch against -CURRENT is here: > > > > http://people.freebsd.org/~jkim/acpica-import-20070126.diff.gz > > > > (Note: Sorry, I had to gzip(1) it because it was too big.) > > > > This patch should fix many ACPI issues in -CURRENT (ACPI-CA 20051021), > > most notably memory leak. Full change log for ACPI-CA from the last > > import is here: > > > > http://people.freebsd.org/~jkim/acpica_changes_20051021_20070126.txt > > > > I believe it is quite stable because I have been using this patch on > > my primary desktop and laptop for a while and it was tested on amd64, > > i386, and ia64. However, since the patch is huge, I may have missed > > something. If you find something wrong, please let me know before it > > is too late. ;-) > > Thank you very much for all your work. You've even improved other > things along the way, not just the import. Does someone has a list or a pointer which gives an overview what changed / is improved? Bye, Alexander. -- Incorrect time syncronization 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 Sat Mar 17 10:50:34 2007 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3F7B316A400; Sat, 17 Mar 2007 10:50:34 +0000 (UTC) (envelope-from m.boyarov@bsd.by) Received: from mx1.cybernet.by (mx1.cybernet.by [212.98.164.131]) by mx1.freebsd.org (Postfix) with ESMTP id DC99713C45B; Sat, 17 Mar 2007 10:50:33 +0000 (UTC) (envelope-from m.boyarov@bsd.by) Received: from mx1.cybernet.by (mx1.cybernet.by [127.0.0.4]) by mx1.cybernet.by (Postfix) with ESMTP id BB27E3C0ADB; Sat, 17 Mar 2007 12:29:45 +0200 (EET) Received: by mx1.cybernet.by (Postfix, from userid 58) id A5F0C3C0588; Sat, 17 Mar 2007 12:29:45 +0200 (EET) X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on mx1.cybernet.by X-Spam-Level: X-Spam-Status: No, score=-2.3 required=8.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from deimos.bsd.by (h33-170-94-80.dialin.4enet.by [80.94.170.33]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.cybernet.by (Postfix) with ESMTP id 481783C04D3; Sat, 17 Mar 2007 12:29:40 +0200 (EET) Received: by deimos.bsd.by (Postfix, from userid 1001) id 8A11017059; Sat, 17 Mar 2007 12:32:00 +0200 (EET) X-Comment-To: Jung-uk Kim To: Jung-uk Kim References: <200703161256.23996.jkim@FreeBSD.org> From: m.boyarov@bsd.by (Max N. Boyarov) Date: Sat, 17 Mar 2007 12:32:00 +0200 In-Reply-To: <200703161256.23996.jkim@FreeBSD.org> (Jung-uk Kim's message of "Fri, 16 Mar 2007 12:56:19 -0400") Message-ID: <86abycxisf.fsf@bsd.by> X-Mailer: Gnus v5.11/GNU Emacs 22.0 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV using ClamSMTP on mx1.cybernet.by Cc: acpi@FreeBSD.org, current@FreeBSD.org Subject: Re: [HEADSUP] ACPI-CA 20070126 import X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Mar 2007 10:50:34 -0000 >>>>> "JK" == Jung-uk Kim writes: [cut] JK> I believe it is quite stable because I have been using this patch on JK> my primary desktop and laptop for a while and it was tested on amd64, JK> i386, and ia64. However, since the patch is huge, I may have missed JK> something. If you find something wrong, please let me know before it JK> is too late. ;-) Thanks! I don't see regression on my T60. dmesg http://ncd0.bsd.by/out/dmesg_acpi.txt -- Max N. Boyarov jabber: zotrix@jabber.ru From owner-freebsd-current@FreeBSD.ORG Sat Mar 17 17:11:53 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 76EB316A401 for ; Sat, 17 Mar 2007 17:11:53 +0000 (UTC) (envelope-from infofarmer@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.238]) by mx1.freebsd.org (Postfix) with ESMTP id 305A113C448 for ; Sat, 17 Mar 2007 17:11:53 +0000 (UTC) (envelope-from infofarmer@gmail.com) Received: by wr-out-0506.google.com with SMTP id 36so904782wra for ; Sat, 17 Mar 2007 10:11:52 -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=HRyJR+LJE3TecejCd1bgYSH62CZya91GDpNU+LyqI/Yt62rcfI2PidT2O6ofnrxOSEqSfU+5RefwChXMI1LS7k6QQlOeUPJVEsD5ShoNLj8oLCybppfl/0kNxx3dAFwmFDwWZeRDHdyHhy4T/nqjwKCHkbI/ZK6+nFoRHoB/j6A= 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=RfX4PaVNezQMePRLyn68CssMmS4P8MEgo9R2bJt+3ICPXA3voNJDj7unYMiLsVUeNo1OSSNlQxNVX9ARpOGLvzLEXtnp6sWN3s2BdCXX9zm6djM+cik4oh+SKjKYrATJvwJdYuNS39Vx1VMWitGLsvVE4DHw74e7Q0yqYvnIdgI= Received: by 10.65.61.16 with SMTP id o16mr5295331qbk.1174151512337; Sat, 17 Mar 2007 10:11:52 -0700 (PDT) Received: by 10.114.201.2 with HTTP; Sat, 17 Mar 2007 10:11:52 -0700 (PDT) Message-ID: Date: Sat, 17 Mar 2007 20:11:52 +0300 From: "Andrew Pantyukhin" Sender: infofarmer@gmail.com To: "Ariff Abdullah" In-Reply-To: <20070317103847.51960145.ariff@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070317103847.51960145.ariff@FreeBSD.org> X-Google-Sender-Auth: b6b283adc5332370 Cc: current@freebsd.org Subject: Re: sound/snd_hda regression X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Mar 2007 17:11:53 -0000 On 3/17/07, Ariff Abdullah wrote: > On Sat, 17 Mar 2007 05:22:45 +0300 > "Andrew Pantyukhin" wrote: > > -pcm0: > > +pcm0: > > Latest revision is 20070317_0042. Please update all sound sources. Unfortunately, it's almost the same. It all starts with loud clicks like millisecond gaps, sometimes there's electronic distortion, somewhat like very low-bitrate mp3 artifacts. From owner-freebsd-current@FreeBSD.ORG Sat Mar 17 17:22:30 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from misaki (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with SMTP id 576A616A406; Sat, 17 Mar 2007 17:22:29 +0000 (UTC) (envelope-from ariff@FreeBSD.org) Date: Sun, 18 Mar 2007 01:22:25 +0800 From: Ariff Abdullah To: "Andrew Pantyukhin" Message-Id: <20070318012225.6383018d.ariff@FreeBSD.org> In-Reply-To: References: <20070317103847.51960145.ariff@FreeBSD.org> Organization: FreeBSD X-Mailer: /usr/local/lib/ruby/1.8/net/smtp.rb Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="PGP-SHA1"; boundary="Signature=_Sun__18_Mar_2007_01_22_25_+0800_3YvP1tznyeTnaahx" Cc: current@freebsd.org Subject: Re: sound/snd_hda regression X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Mar 2007 17:22:30 -0000 --Signature=_Sun__18_Mar_2007_01_22_25_+0800_3YvP1tznyeTnaahx Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, 17 Mar 2007 20:11:52 +0300 "Andrew Pantyukhin" wrote: > On 3/17/07, Ariff Abdullah wrote: > > On Sat, 17 Mar 2007 05:22:45 +0300 > > "Andrew Pantyukhin" wrote: > > > -pcm0: > > > +pcm0: > > > > Latest revision is 20070317_0042. Please update all sound sources. >=20 > Unfortunately, it's almost the same. It all starts with > loud clicks like millisecond gaps, sometimes there's > electronic distortion, somewhat like very low-bitrate > mp3 artifacts. >=20 Try reverting hdac.c (just hdac.c) from the last working version. -- Ariff Abdullah FreeBSD ... Recording in stereo is obviously too advanced and confusing for us idiot ***** users :P ........ --Signature=_Sun__18_Mar_2007_01_22_25_+0800_3YvP1tznyeTnaahx Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFF/CPRlr+deMUwTNoRAkUSAKC1O4n2OVbcATK+qZUnCvZO2hh5pQCgyE6O FnlQtuO3P421lwjA6rX89ig= =Iyum -----END PGP SIGNATURE----- --Signature=_Sun__18_Mar_2007_01_22_25_+0800_3YvP1tznyeTnaahx-- From owner-freebsd-current@FreeBSD.ORG Sat Mar 17 17:33:34 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 594D916A403 for ; Sat, 17 Mar 2007 17:33:34 +0000 (UTC) (envelope-from probsd@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.244]) by mx1.freebsd.org (Postfix) with ESMTP id 0A8E813C45E for ; Sat, 17 Mar 2007 17:33:33 +0000 (UTC) (envelope-from probsd@gmail.com) Received: by an-out-0708.google.com with SMTP id c24so848276ana for ; Sat, 17 Mar 2007 10:33: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:mime-version:content-type:content-transfer-encoding:content-disposition; b=OuPaXD31Wz99dwOPL46/lAUUPJ0LSnbdOHZjja4iY7Pho8P4gHwut9JLhip4EAs/86Nz/ymE43LTbjvi45pBxKxMkRk+yeVctRwUJGbqZ3yQPfNZu0X5nSuvn32PvBPv1gCo2JiTSW/vxTvH1bdeSwvP2mhBO49WlvNCwxaipe0= 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=sa39DAxNNk7nM3XIPDj4LQwuajFr6Q52n9z2Aty3ejUIhZW1KS8VxxZAqGuJR31PStmRw1HqJaIBO8cJnhdLExfzv46XZrUx2R6rjJYW1r58hG4HPR3MOLIT4acg5B3KGuTUvBThMxvb4/DJd+W5v6BdNoy0gP/lJvCwXXkqT/4= Received: by 10.100.33.14 with SMTP id g14mr2395615ang.1174151166836; Sat, 17 Mar 2007 10:06:06 -0700 (PDT) Received: by 10.100.197.20 with HTTP; Sat, 17 Mar 2007 10:06:06 -0700 (PDT) Message-ID: <483316d70703171006q42f13f04j775465f45f8d29bf@mail.gmail.com> Date: Sat, 17 Mar 2007 12:06:06 -0500 From: "Rick Mullis" To: current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Subject: emu10kx SB Live 5.1 digital problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Mar 2007 17:33:34 -0000 I have been following current for a few months now and everything is working very good. Thanks to Hans the new USB is working flawless. I need some help with sound though. I have been reading the current maillists and searching google for a couple of weeks to fix the issue but I have had no luck. My situation is this, I have a Creative Labs SB Live 5.1 digital sound card (SB0220) but no sound. I don't know how to enable digital mode only. When I ran earlier versions of FreeBSD, I used the ports version of the driver and it worked great but after all the work everyone has put into the new base driver I wanted to test this. please help, here is my out put: fbsd7# sysctl -a | egrep 'snd|pcm' pcm0: on emu10kx0 pcm0: pcm0: on emu10kx0 pcm0: pcm0: on emu10kx0 pcm0: pcm0: on emu10kx0 pcm0: pcm0: detached pcm0: on emu10kx0 pcm0: pcm0: on emu10kx0 pcm0: hw.snd.latency_profile: 1 hw.snd.latency: 5 hw.snd.report_soft_formats: 1 hw.snd.feeder_buffersize: 16384 hw.snd.feeder_rate_round: 25 hw.snd.feeder_rate_max: 2016000 hw.snd.feeder_rate_min: 1 hw.snd.verbose: 1 hw.snd.maxautovchans: 4 hw.snd.default_unit: 0 dev.emu10kx.0._pcm_front_l: 100 dev.emu10kx.0._pcm_front_r: 100 dev.emu10kx.0._pcm_rec_l: 0 dev.emu10kx.0._pcm_rec_r: 0 dev.pcm.0.%desc: EMU10Kx DSP front PCM interface dev.pcm.0.%driver: pcm dev.pcm.0.%parent: emu10kx0 dev.pcm.0.eapd: 1 dev.pcm.0.buffersize: 65536 dev.pcm.0.vchans: 1 dev.pcm.0.vchanrate: 48000 dev.pcm.0.vchanformat: s16le fbsd7# cat /dev/sndstat FreeBSD Audio Driver (newpcm: 64bit) Installed devices: pcm0: on emu10kx0 (4p/1r/1v channels duplex default) fbsd7# cat /dev/emu10kx0 FreeBSD EMU10Kx Audio Driver Hardware resource usage: DSP General Purpose Registers: 32 used, 256 total DSP Instruction Registers: 52 used, 512 total Card supports AC97 codec, SBLive! DSP code Installed devices: EMU10Kx DSP front PCM interface on pcm0 EMU10Kx MIDI Interface On-card connector on midi0 IR reciever MIDI events enabled fbsd7#dmesg Copyright (c) 1992-2007 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.0-CURRENT #10: Fri Mar 16 17:30:34 CDT 2007 rick@fbsd7.probsd:/usr/obj/usr/src/sys/MAIN ACPI APIC Table: Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz (2407.21-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x6f6 Stepping = 6 Features=0xbfebfbff Features2=0xe3bd> AMD Features=0x20100800 AMD Features2=0x1 Cores per package: 2 usable memory = 4213706752 (4018 MB) avail memory = 4054458368 (3866 MB) FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 2 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 cpu0: on acpi0 acpi_perf0: on cpu0 acpi_perf0: failed in PERF_STATUS attach device_attach: acpi_perf0 attach returned 6 acpi_throttle0: on cpu0 acpi_perf0: on cpu0 acpi_perf0: failed in PERF_STATUS attach device_attach: acpi_perf0 attach returned 6 cpu1: on acpi0 acpi_perf1: on cpu1 acpi_perf1: failed in PERF_STATUS attach device_attach: acpi_perf1 attach returned 6 acpi_throttle1: on cpu1 acpi_throttle1: failed to attach P_CNT device_attach: acpi_throttle1 attach returned 6 acpi_perf1: on cpu1 acpi_perf1: failed in PERF_STATUS attach device_attach: acpi_perf1 attach returned 6 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 vgapci0: mem 0xe1000000-0xe1ffffff,0xd0000000-0xdfffffff,0xe0000000-0xe0ffffff irq 16 at device 0.0 on pci1 pci0: at device 3.0 (no driver attached) em0: port 0x30c0-0x30df mem 0xe2200000-0xe221ffff,0xe2224000-0xe2224fff irq 20 at device 25.0 on pci0 em0: Ethernet address: 00:16:76:ce:18:34 em0: [FILTER] uhci0: port 0x30a0-0x30bf irq 16 at device 26.0 on pci0 uhci0: [ITHREAD] uhci0: LegSup = 0x0f10 usb0: on uhci0 uhci1: port 0x3080-0x309f irq 21 at device 26.1 on pci0 uhci1: [ITHREAD] uhci1: LegSup = 0x0f10 usb1: on uhci1 ehci0: mem 0xe2225400-0xe22257ff irq 18 at device 26.7 on pci0 ehci0: [ITHREAD] usb2: EHCI version 1.0 usb2: on ehci0 pci0: at device 27.0 (no driver attached) pcib2: at device 28.0 on pci0 pci2: on pcib2 pcib3: at device 28.1 on pci0 pci3: on pcib3 atapci0: port 0x2018-0x201f,0x2024-0x2027,0x2010-0x2017,0x2020-0x2023,0x2000-0x200f mem 0xe2100000-0xe21001ff irq 17 at device 0.0 on pci3 atapci0: [ITHREAD] ata2: on atapci0 ata2: [ITHREAD] pcib4: at device 28.2 on pci0 pci4: on pcib4 pcib5: at device 28.3 on pci0 pci5: on pcib5 pcib6: at device 28.4 on pci0 pci6: on pcib6 uhci2: port 0x3060-0x307f irq 23 at device 29.0 on pci0 uhci2: [ITHREAD] uhci2: LegSup = 0x0f10 usb3: on uhci2 uhci3: port 0x3040-0x305f irq 19 at device 29.1 on pci0 uhci3: [ITHREAD] uhci3: LegSup = 0x0f10 usb4: on uhci3 uhci4: port 0x3020-0x303f irq 18 at device 29.2 on pci0 uhci4: [ITHREAD] uhci4: LegSup = 0x0f10 usb5: on uhci4 ehci1: mem 0xe2225000-0xe22253ff irq 23 at device 29.7 on pci0 ehci1: [ITHREAD] usb6: EHCI version 1.0 usb6: on ehci1 pcib7: at device 30.0 on pci0 pci7: on pcib7 emu10kx0: port 0x1000-0x101f irq 21 at device 0.0 on pci7 emu10kx0: [ITHREAD] pcm0: on emu10kx0 pcm0: midi0: on emu10kx0 emu10kx0: SB Live! IR MIDI events enabled. pci7: at device 0.1 (no driver attached) fwohci0: mem 0xe2004000-0xe20047ff,0xe2000000-0xe2003fff irq 19 at device 3.0 on pci7 fwohci0: [ITHREAD] fwohci0: OHCI version 1.10 (ROM=0) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:90:27:00:01:d5:11:f8 fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:90:27:d5:11:f8 fwe0: Ethernet address: 02:90:27:d5:11:f8 fwe0: if_start running deferred for Giant sbp0: on firewire0 fwohci0: Initiate bus reset fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) isab0: at device 31.0 on pci0 isa0: on isab0 atapci1: port 0x3138-0x313f,0x314c-0x314f,0x3130-0x3137,0x3148-0x314b,0x3110-0x311f,0x3100-0x310f irq 19 at device 31.2 on pci0 atapci1: [ITHREAD] ata3: on atapci1 ata3: [ITHREAD] ata4: on atapci1 ata4: [ITHREAD] pci0: at device 31.3 (no driver attached) atapci2: port 0x3128-0x312f,0x3144-0x3147,0x3120-0x3127,0x3140-0x3143,0x30f0-0x30ff,0x30e0-0x30ef irq 19 at device 31.5 on pci0 atapci2: [ITHREAD] ata5: on atapci2 ata5: [ITHREAD] ata6: on atapci2 ata6: [ITHREAD] fdc0: port 0x3f0-0x3f5,0x3f0 irq 6 drq 2 on acpi0 fdc0: [FILTER] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 ppc0: port 0x378-0x37f,0x778-0x77f irq 7 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold ppbus0: on ppc0 plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 ppc0: [GIANT-LOCKED] ppc0: [ITHREAD] atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model IntelliMouse Explorer, device ID 4 sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio0: [FILTER] orm0: at iomem 0xc0000-0xcefff,0xcf000-0xcffff,0xd0000-0xd0fff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounters tick every 1.000 msec usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 127 uhub0: 2 ports with 2 removable, self powered usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 127 uhub1: 2 ports with 2 removable, self powered usb2: USB revision 2.0 uhub2: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 127 uhub2: 4 ports with 4 removable, self powered usb3: USB revision 1.0 uhub3: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 127 uhub3: 2 ports with 2 removable, self powered usb4: USB revision 1.0 uhub4: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 127 uhub4: 2 ports with 2 removable, self powered usb5: USB revision 1.0 uhub5: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 127 uhub5: 2 ports with 2 removable, self powered usb6: USB revision 2.0 uhub6: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 127 uhub6: 6 ports with 6 removable, self powered uhub7: NEC Corporation USB2.0 Hub Controller, class 9/0, rev 2.00/1.00, addr 126 uhub7: 4 ports with 4 removable, self powered ulpt0: ulpt0: using bi-directional mode umass0: umass0: SCSI over Bulk-Only; quirks = 0x0000 umass0:1:0:-1: Attached to scbus1 (probe0:umass-sim0:0:0:0): Uninitialized Transport 5:ffffffff? acd0: DVDR at ata2-master UDMA33 acd1: CDROM at ata2-slave UDMA33 acd1: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 ad6: 239372MB at ata3-master SATA150 acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 (probe1:umass-sim0:0:0:1): Uninitialized Transport 5:7? (probe0:umass-sim0:0:0:2): Uninitialized Transport 5:49534353? (probe1:umass-sim0:0:0:3): Uninitialized Transport 5:49534353? SMP: AP CPU #1 Launched! cd0 at ata0 bus 0 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 33.000MB/s transfers cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed cd1 at ata0 bus 0 target 1 lun 0 cd1: Removable CD-ROM SCSI-0 device cd1: 33.000MB/s transfers cd1: Attempt to query device size failed: NOT READY, Medium not present 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/ad6s2a If you need any other info I will supply it. Thanks in advance for your help. Best regards, Rick Mullis From owner-freebsd-current@FreeBSD.ORG Sat Mar 17 22:38:27 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DCAE416A402 for ; Sat, 17 Mar 2007 22:38:27 +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 A6D0213C458 for ; Sat, 17 Mar 2007 22:38:27 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from [10.0.0.1] (63-226-247-187.tukw.qwest.net [63.226.247.187]) (authenticated bits=0) by webaccess-cl.virtdom.com (8.13.6/8.13.6) with ESMTP id l2HMcO5t019745 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO) for ; Sat, 17 Mar 2007 17:38:26 -0500 (EST) (envelope-from jroberson@chesapeake.net) Date: Sat, 17 Mar 2007 14:38:15 -0800 (PST) From: Jeff Roberson X-X-Sender: jroberson@10.0.0.1 To: current@freebsd.org Message-ID: <20070317143500.J560@10.0.0.1> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Subject: HEADS UP: nfs server locking. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Mar 2007 22:38:27 -0000 The nfs server has had the last vestiges of giant removed when the local filesystem doesn't require it. The nfsd locking has also been reduced in scope. These patches were tested fairly thoroughly by isilon and kris, but there is a potential for bugs. Let me know if you encounter anything unusual. Keep in mind that there are still client bugs under high load. If you attempt to break the server you more often break the client instead. Jeff ---------- Forwarded message ---------- Date: Sat, 17 Mar 2007 18:18:09 +0000 (UTC) From: Jeff Roberson To: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org Subject: cvs commit: src/sys/nfsserver nfs.h nfs_serv.c nfs_srvcache.c nfs_srvsock.c nfs_srvsubs.c nfs_syscalls.c nfsm_subs.h jeff 2007-03-17 18:18:09 UTC FreeBSD src repository Modified files: sys/nfsserver nfs.h nfs_serv.c nfs_srvcache.c nfs_srvsock.c nfs_srvsubs.c nfs_syscalls.c nfsm_subs.h Log: - Turn all explicit giant acquires into conditional VFS_LOCK_GIANTs. Only ops which used namei still remained. - Implement a scheme for reducing the overhead of tracking which vops require giant by constantly reducing the number of recursive giant acquires to one, leaving us with only one vfslocked variable. - Remove all NFSD lock acquisition and release from the individual nfs ops. Careful examination has shown that they are not required. This greatly simplifies the code. Sponsored by: Isilon Systems, Inc. Discussed with: rwatson Tested by: kkenn Approved by: re Revision Changes Path 1.82 +1 -4 src/sys/nfsserver/nfs.h 1.171 +187 -554 src/sys/nfsserver/nfs_serv.c 1.44 +2 -0 src/sys/nfsserver/nfs_srvcache.c 1.102 +0 -10 src/sys/nfsserver/nfs_srvsock.c 1.146 +42 -71 src/sys/nfsserver/nfs_srvsubs.c 1.112 +2 -0 src/sys/nfsserver/nfs_syscalls.c 1.39 +2 -5 src/sys/nfsserver/nfsm_subs.h