From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 22 00:03:20 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 990FE16A41F for ; Sun, 22 Jan 2006 00:03:20 +0000 (GMT) (envelope-from mbsd@pacbell.net) Received: from ylpvm15.prodigy.net (ylpvm15-ext.prodigy.net [207.115.57.46]) by mx1.FreeBSD.org (Postfix) with ESMTP id 22F2D43D45 for ; Sun, 22 Jan 2006 00:03:20 +0000 (GMT) (envelope-from mbsd@pacbell.net) Received: from pimout6-ext.prodigy.net (pimout6-int.prodigy.net [207.115.4.22]) by ylpvm15.prodigy.net (8.12.10 outbound/8.12.10) with ESMTP id k0M03UEX027277 for ; Sat, 21 Jan 2006 19:03:30 -0500 X-ORBL: [71.139.4.112] DomainKey-Signature: a=rsa-sha1; s=sbc01; d=pacbell.net; c=nofws; q=dns; h=date:from:x-x-sender:to:cc:subject:in-reply-to:message-id: references:mime-version:content-type; b=E1yK+CGbJjqI9lhAN40QrDyeOICJrWjZWRrK23Eiy/+UWlZcsyklnxnCaIvrESEGV 6IuEoPdTHzaYbRFjbZHFA== Received: from spirou.home (ppp-71-139-4-112.dsl.snfc21.pacbell.net [71.139.4.112]) by pimout6-ext.prodigy.net (8.13.4 outbound domainkey aix/8.13.4) with ESMTP id k0M03GnR045198; Sat, 21 Jan 2006 19:03:17 -0500 Date: Sat, 21 Jan 2006 16:03:20 -0800 (PST) From: =?ISO-8859-1?Q?Mikko_Ty=F6l=E4j=E4rvi?= X-X-Sender: mikko@spirou.home To: Antti Korpela In-Reply-To: <49431.195.139.252.5.1137461466.squirrel@webmail.i13i.com> Message-ID: <20060121155821.Y73866@spirou.home> References: <43CC3C6B.4060703@devnet.fi> <49431.195.139.252.5.1137461466.squirrel@webmail.i13i.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org Subject: Re: FreeBSD 6.0 default pty/tty-limit (256) OFF! X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jan 2006 00:03:20 -0000 Hi Antti, > I need patch to raise FreeBSD 6.0 default pty/tty-limit (256) UP or OFF. > In shell-production usage, that limit is ridiculous, there must be stop to > this and put PTY-limits off! > I changed my servers operating systems moment ago from Linux to FreeBSD > thinking that FreeBSD could be more better, but how this can be possible, > that so important think like PTYs are limited to so low?? every UNIX has > more ptys. This is a long standing problem, as is evident from kern/25866 [1] from 2001. A more recent report is standards/90896 [2], wich also contains a patch. I'd suggest you try the patch and provide feedback to the bug report. $.02, /Mikko 1) http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/25866) 2) http://www.freebsd.org/cgi/query-pr.cgi?pr=standards/90896 From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 22 23:53:20 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D1AF016A41F for ; Sun, 22 Jan 2006 23:53:20 +0000 (GMT) (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 AD8B843D62 for ; Sun, 22 Jan 2006 23:53:19 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 8BFBE46BA8; Sun, 22 Jan 2006 18:53:13 -0500 (EST) Date: Sun, 22 Jan 2006 23:54:22 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: =?ISO-8859-1?Q?Mikko_Ty=F6l=E4j=E4rvi?= In-Reply-To: <20060121155821.Y73866@spirou.home> Message-ID: <20060122235133.Y89461@fledge.watson.org> References: <43CC3C6B.4060703@devnet.fi> <49431.195.139.252.5.1137461466.squirrel@webmail.i13i.com> <20060121155821.Y73866@spirou.home> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-527915674-1137974062=:89461" Cc: freebsd-hackers@freebsd.org, Antti Korpela Subject: Re: FreeBSD 6.0 default pty/tty-limit (256) OFF! X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jan 2006 23:53:21 -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-527915674-1137974062=:89461 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Sat, 21 Jan 2006, Mikko Ty=F6l=E4j=E4rvi wrote: >> I need patch to raise FreeBSD 6.0 default pty/tty-limit (256) UP or OFF.= In=20 >> shell-production usage, that limit is ridiculous, there must be stop to= =20 >> this and put PTY-limits off! I changed my servers operating systems mome= nt=20 >> ago from Linux to FreeBSD thinking that FreeBSD could be more better, bu= t=20 >> how this can be possible, that so important think like PTYs are limited = to=20 >> so low?? every UNIX has more ptys. > > This is a long standing problem, as is evident from kern/25866 [1] from= =20 > 2001. A more recent report is standards/90896 [2], wich also contains a= =20 > patch. > > I'd suggest you try the patch and provide feedback to the bug report. FYI, there's also a tty_pts.c floating around, based on some work I did at= =20 McAfee a couple of years ago, that implements /dev/ptmx and /dev/pts for=20 FreeBSD. Among other things, it removes the limit on the number pty's, and= =20 adopts the Sys V pty naming convention. While there are upsides and downsi= des=20 to the naming convention, it does attempt to normalize the way we handle=20 pty's, as well as removing the requirement for root privilege in order to= =20 allocate and properly protect a pty. I have an older version at=20 http://www.watson.org/~robert/freebsd/pts/. However, it's fairly dated, an= d=20 may not work due to other changes since it was written (I've not looked to= =20 see). I've tried several times to trick developers into picking it up and= =20 doing the last remaining work to make it real -- largely what's required is= =20 work on the forward/backward compatibility issue, that and extensive testin= g=20 and a security audit. It would be nice to ship 7.x with these changes as i= t=20 would resolve a lot of problems. Robert N M Watson --0-527915674-1137974062=:89461-- From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 23 09:24:34 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 93C1C16A42B for ; Mon, 23 Jan 2006 09:24:34 +0000 (GMT) (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 039D443D46 for ; Mon, 23 Jan 2006 09:24:33 +0000 (GMT) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 420682082; Mon, 23 Jan 2006 10:24:28 +0100 (CET) X-Spam-Tests: AWL,BAYES_00,FORGED_RCVD_HELO X-Spam-Learn: ham X-Spam-Score: -3.2/3.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on tim.des.no Received: from xps.des.no (des.no [80.203.243.180]) by tim.des.no (Postfix) with ESMTP id AB2082081; Mon, 23 Jan 2006 10:24:27 +0100 (CET) Received: by xps.des.no (Postfix, from userid 1001) id 8D87933C1D; Mon, 23 Jan 2006 10:24:27 +0100 (CET) To: Peter Jeremy References: <2209162.1137777933811.JavaMail.root@vms075.mailsrvcs.net> <20060120193741.GC39932@xor.obsecurity.org> <43D15C19.314EC346@verizon.net> <20060120222629.GA43985@xor.obsecurity.org> <43D19011.D15F8462@verizon.net> <20060121015311.GA46753@xor.obsecurity.org> <20060121160739.GH63244@over-yonder.net> <20060121202321.GA83848@xor.obsecurity.org> <20060121203057.GK63244@over-yonder.net> <20060121210956.GU25397@cirb503493.alcatel.com.au> From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) Date: Mon, 23 Jan 2006 10:24:27 +0100 In-Reply-To: <20060121210956.GU25397@cirb503493.alcatel.com.au> (Peter Jeremy's message of "Sun, 22 Jan 2006 08:09:56 +1100") Message-ID: <86hd7vcn5g.fsf@xps.des.no> User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, "Matthew D. Fuller" Subject: Re: speed up port compiling using RAM (tmpfs) ??? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2006 09:24:34 -0000 Peter Jeremy writes: > On Sat, 2006-Jan-21 14:30:57 -0600, Matthew D. Fuller wrote: > > Yes, but portupgrade and friends already do most of that, so they can > > upgrade stuff "in order". > Actually, they rely on there being an up-to-date INDEX file and build > their own dependency database from that. porteasy doesn't; it parses the Makefile to attempt to detect master / slave relationships, then uses make -V to obtain fetch / build / lib / run dependencies. Replacing make with a specialized tool with a more expressive syntax would make this much easier, and much faster. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 23 21:00:00 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6822016A426 for ; Mon, 23 Jan 2006 21:00:00 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.FreeBSD.org (Postfix) with ESMTP id 32E0543D5C for ; Mon, 23 Jan 2006 20:59:58 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.5b3) with ESMTP id 6790122 for multiple; Mon, 23 Jan 2006 16:01:05 -0500 Received: from localhost (john@localhost [127.0.0.1]) by server.baldwin.cx (8.13.4/8.13.4) with ESMTP id k0NKxsoA003319; Mon, 23 Jan 2006 15:59:55 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: Craig Boston Date: Mon, 23 Jan 2006 15:43:50 -0500 User-Agent: KMail/1.9.1 References: <20060120014307.GA3118@nowhere> <200601201542.23464.jhb@freebsd.org> <20060120212647.GB5660@nowhere> In-Reply-To: <20060120212647.GB5660@nowhere> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200601231543.51931.jhb@freebsd.org> X-Virus-Scanned: ClamAV 0.87.1/1247/Sat Jan 21 05:24:51 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.4 required=4.2 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on server.baldwin.cx X-Server: High Performance Mail Server - http://surgemail.com r=1653887525 Cc: freebsd-hackers@freebsd.org Subject: Re: Weird PCI interrupt delivery problem (resolution, sort of) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2006 21:00:00 -0000 On Friday 20 January 2006 16:26, Craig Boston wrote: > On Fri, Jan 20, 2006 at 03:42:21PM -0500, John Baldwin wrote: > > Hmm, well, you can actually try the PAT patch if you are feeling brave as > > it maps all devices (including APICs) as uncacheable. > > Heh, took me a minute to find. I first found the one at > http://people.freebsd.org/~jhb/patches/pat.patch > but it maps devices as write-back. I'm guessing you mean to use the > version in perforce? Yeah, I need to generate an updated patch. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 24 02:25:16 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5D96116A41F; Tue, 24 Jan 2006 02:25:16 +0000 (GMT) (envelope-from craig@tobuj.gank.org) Received: from ion.gank.org (ion.gank.org [69.55.238.164]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1EAFD43D48; Tue, 24 Jan 2006 02:25:15 +0000 (GMT) (envelope-from craig@tobuj.gank.org) Received: by ion.gank.org (mail, from userid 1001) id 6611F2AA01; Mon, 23 Jan 2006 20:25:15 -0600 (CST) Date: Mon, 23 Jan 2006 20:25:11 -0600 From: Craig Boston To: John Baldwin Message-ID: <20060124022511.GA99552@nowhere> Mail-Followup-To: Craig Boston , John Baldwin , freebsd-hackers@freebsd.org, Scott Long References: <20060120014307.GA3118@nowhere> <43D07273.6030804@samsco.org> <20060120152731.GA5660@nowhere> <200601201542.23464.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200601201542.23464.jhb@freebsd.org> User-Agent: Mutt/1.4.2.1i Cc: freebsd-hackers@freebsd.org, Scott Long Subject: Re: Weird PCI interrupt delivery problem (resolution, sort of) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2006 02:25:16 -0000 On Fri, Jan 20, 2006 at 03:42:21PM -0500, John Baldwin wrote: > On Thu, Jan 19, 2006 at 10:17:39PM -0700, Scott Long wrote: > > This points to a bus coherency problem. I wonder if your BIOS is > > incorrectly setting the memory region of the apics as cachable. You'll > > want to bug Baldwin about this. > > Hmm, well, you can actually try the PAT patch if you are feeling brave as it > maps all devices (including APICs) as uncacheable. Tried the updated PAT patch (with s/pmap_unmapbios/pmap_unmap_bios/ to get ACPI to compile). Unfortunately if it is a caching problem, PAT isn't able to fix it. Same result as stock kernel -- interrupts stop arriving after a dozen or so. AFAICT the local APIC is the only memory-mapped I/O region that seems to be problematic. Instead of writing the value twice, I also tried inserting an __asm("nop") before the write with no effect. Also, a single write to an unrelated area doesn't help: +static volatile int dummyeoi; + lapic_eoi(void) { + dummyeoi = 1; lapic->eoi = 0; + dummyeoi = 2; } I'm _reasonably_ certain that marking dummyeoi volatile and leaving it uninitialized will prevent gcc from optimizng that out. Forcing R/W cycles (++dummyeoi) before and after doesn't work either. A DELAY(1) before the lapic->eoi write does the trick, but DELAY does lots of complicated things so I don't know how useful of a data point that is. I'm probably missing something, but if bad cache behavior was causing writes to the lapic EOI register to not always take effect, wouldn't the _next_ irq (even if it's a different line) cause the one that's currently pending to be acknowledged? Craig From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 24 02:52:10 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9A50B16A420 for ; Tue, 24 Jan 2006 02:52:10 +0000 (GMT) (envelope-from matt@gsicomp.on.ca) Received: from skippyii.compar.com (cistore.compar.com [216.208.38.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id AB7D143D46 for ; Tue, 24 Jan 2006 02:52:09 +0000 (GMT) (envelope-from matt@gsicomp.on.ca) Received: from hermes (CPE00062566c7bb-CM0011e6ede298.cpe.net.cable.rogers.com [70.28.254.189]) by skippyii.compar.com (8.13.1/8.13.1) with ESMTP id k0O2sent039638; Mon, 23 Jan 2006 21:54:41 -0500 (EST) (envelope-from matt@gsicomp.on.ca) Message-ID: <002801c62091$46a05fe0$1200a8c0@gsicomp.on.ca> From: "Matt Emmerton" To: "M. Warner Losh" References: <001501c61ca7$9c1d7450$1200a8c0@gsicomp.on.ca> <20060120.222231.82100775.imp@bsdimp.com> Date: Mon, 23 Jan 2006 21:52:53 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1506 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Cc: freebsd-hackers@freebsd.org Subject: Re: Config(8) dependency checking - first patches X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2006 02:52:10 -0000 > : Notes and patches against 7-CURRENT are at > : http://www.gsicomp.on.ca/projects/freebsd/configdep.html. > > How would you encode ed's dependencies? The ed driver only depends on > mii when built with pccard enabled. I suspected that conditional dependencies would be neccessary, but didn't have any examples. Now I do. Thanks! -- Matt Emmerton From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 24 09:22:00 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5F4A516A41F for ; Tue, 24 Jan 2006 09:22:00 +0000 (GMT) (envelope-from pranavpeshwe@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.207]) by mx1.FreeBSD.org (Postfix) with ESMTP id C34AB43D49 for ; Tue, 24 Jan 2006 09:21:59 +0000 (GMT) (envelope-from pranavpeshwe@gmail.com) Received: by wproxy.gmail.com with SMTP id i31so1091361wra for ; Tue, 24 Jan 2006 01:21:59 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=KT/UDB3MPkrHlMX9Wi0B2p3VEWp8Ll9qnHQTaPMK3CspQ/b9P6HZqbZO89IWjJOabEiGMDhWiQgAtlA3knUpYlLuqSbmmpZh5Sdb0P0vv+jyEKflyS+tEHmK0OFE9wqMhjhi57nNtaAf9JQCUt1K/opf7LM1HTmJn8gtN9HrgIM= Received: by 10.54.122.13 with SMTP id u13mr6836012wrc; Tue, 24 Jan 2006 01:21:59 -0800 (PST) Received: by 10.54.99.13 with HTTP; Tue, 24 Jan 2006 01:21:59 -0800 (PST) Message-ID: Date: Tue, 24 Jan 2006 14:51:59 +0530 From: Pranav Peshwe To: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Subject: Difference between a kthread and an ordinary process. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2006 09:22:00 -0000 Hello, When a kthread is created using the kthread_create (9) function, i found out that a new instance of struct proc is created and allocated for the thread just as in case of a creation of a new process.Also, the thread is assigned a pid as in the case of a process. What is the difference between a kernel thread and a normal process created using fork ? except the address space sharing with swapper and kernel mode execution of the kthread. Is a kthread effectively just a process always running in kernel mode ? TIA. Regards, Pranav. From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 24 10:23:45 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E0EEF16A41F for ; Tue, 24 Jan 2006 10:23:44 +0000 (GMT) (envelope-from kamalpr@gmail.com) Received: from uproxy.gmail.com (uproxy.gmail.com [66.249.92.198]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6F4A943D5A for ; Tue, 24 Jan 2006 10:23:43 +0000 (GMT) (envelope-from kamalpr@gmail.com) Received: by uproxy.gmail.com with SMTP id j3so191396ugf for ; Tue, 24 Jan 2006 02:23:42 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references; b=XdBjAiLBUABUarvYTSgzUYfa4L+cXOaRh/J9yjoa8iyYCwzRgqeJW1x4X8+uXndNioj4erAZZnsOEac7u/RDRgtIqW1jdTVbKeuohkp+v4Y23zdtRtL6SkwoPYf24TzcfpdWtKyvYVHR/NkUslxr4AJu9LrNAavoQukPHmEJJrs= Received: by 10.48.225.3 with SMTP id x3mr422343nfg; Tue, 24 Jan 2006 02:23:41 -0800 (PST) Received: by 10.49.14.17 with HTTP; Tue, 24 Jan 2006 02:23:41 -0800 (PST) Message-ID: Date: Tue, 24 Jan 2006 15:53:41 +0530 From: "Kamal R. Prasad" Sender: kamalpr@gmail.com To: Pranav Peshwe In-Reply-To: MIME-Version: 1.0 References: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org Subject: Re: Difference between a kthread and an ordinary process. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2006 10:23:45 -0000 On 1/24/06, Pranav Peshwe wrote: [snip] > What is the difference between a kernel thread and a normal process > created using fork ? except the address space sharing with swapper and more than one kernel thread can be associated with a process and they all share the same address space. kernel mode execution of the kthread. Is a kthread effectively just a > process always running in kernel mode ? you mean - effectively just a kernel process? A kernel thread can be associated with one or more userland threads, but a kernel process doesn't have anything associated with it in userspace. Further, more than one kerne= l thread can share a single U area/user address space. When they were first introduced -Sun microsystems referred to kernel threads as light-weight processes, which is what you seem to have concluded. regards -kamal TIA. > > Regards, > Pranav. > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org= " > From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 24 14:53:26 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0D82B16A420 for ; Tue, 24 Jan 2006 14:53:26 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id C8E1743D4C for ; Tue, 24 Jan 2006 14:53:19 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (junior.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id k0OErEMc017740; Tue, 24 Jan 2006 07:53:15 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <43D63F5F.9080203@samsco.org> Date: Tue, 24 Jan 2006 07:53:19 -0700 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20051230 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pranav Peshwe References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on pooker.samsco.org Cc: freebsd-hackers@freebsd.org Subject: Re: Difference between a kthread and an ordinary process. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2006 14:53:26 -0000 Pranav Peshwe wrote: > Hello, > When a kthread is created using the kthread_create (9) > function, i found out that a new instance of struct proc is created > and allocated for the thread just as in case of a creation of a new > process.Also, the thread is assigned a pid as in the case of a > process. > What is the difference between a kernel thread and a normal process > created using fork ? except the address space sharing with swapper and > kernel mode execution of the kthread. Is a kthread effectively just a > process always running in kernel mode ? > That is exactly what a kthread is. There is some work in process to make them true threads within one or more processes. Scott From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 24 15:43:02 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B670B16A420 for ; Tue, 24 Jan 2006 15:43:02 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0EB1D43D5F for ; Tue, 24 Jan 2006 15:43:01 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.5b3) with ESMTP id 6850351 for multiple; Tue, 24 Jan 2006 10:44:10 -0500 Received: from localhost (john@localhost [127.0.0.1]) by server.baldwin.cx (8.13.4/8.13.4) with ESMTP id k0OFgtqE012691; Tue, 24 Jan 2006 10:42:58 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: Craig Boston Date: Tue, 24 Jan 2006 10:43:49 -0500 User-Agent: KMail/1.9.1 References: <20060120014307.GA3118@nowhere> <200601201542.23464.jhb@freebsd.org> <20060124022511.GA99552@nowhere> In-Reply-To: <20060124022511.GA99552@nowhere> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200601241043.51094.jhb@freebsd.org> X-Virus-Scanned: ClamAV 0.87.1/1248/Tue Jan 24 05:54:38 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.4 required=4.2 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on server.baldwin.cx X-Server: High Performance Mail Server - http://surgemail.com r=1653887525 Cc: freebsd-hackers@freebsd.org, Scott Long Subject: Re: Weird PCI interrupt delivery problem (resolution, sort of) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2006 15:43:02 -0000 On Monday 23 January 2006 21:25, Craig Boston wrote: > On Fri, Jan 20, 2006 at 03:42:21PM -0500, John Baldwin wrote: > > On Thu, Jan 19, 2006 at 10:17:39PM -0700, Scott Long wrote: > > > This points to a bus coherency problem. I wonder if your BIOS is > > > incorrectly setting the memory region of the apics as cachable. You'll > > > want to bug Baldwin about this. > > > > Hmm, well, you can actually try the PAT patch if you are feeling brave as > > it maps all devices (including APICs) as uncacheable. > > Tried the updated PAT patch (with s/pmap_unmapbios/pmap_unmap_bios/ to > get ACPI to compile). Unfortunately if it is a caching problem, PAT > isn't able to fix it. Same result as stock kernel -- interrupts stop > arriving after a dozen or so. AFAICT the local APIC is the only > memory-mapped I/O region that seems to be problematic. Ok. > Instead of writing the value twice, I also tried inserting an > __asm("nop") before the write with no effect. Also, a single write to > an unrelated area doesn't help: > > +static volatile int dummyeoi; > + > lapic_eoi(void) > { > > + dummyeoi = 1; > lapic->eoi = 0; > + dummyeoi = 2; > } > > I'm _reasonably_ certain that marking dummyeoi volatile and leaving it > uninitialized will prevent gcc from optimizng that out. Forcing R/W > cycles (++dummyeoi) before and after doesn't work either. > > A DELAY(1) before the lapic->eoi write does the trick, but DELAY does > lots of complicated things so I don't know how useful of a data point > that is. > > I'm probably missing something, but if bad cache behavior was causing > writes to the lapic EOI register to not always take effect, wouldn't the > _next_ irq (even if it's a different line) cause the one that's > currently pending to be acknowledged? What if you do a read of the lapic before the write? Maybe doing 'x = lapic->eoi; lapic->eoi = 0;'? -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 24 17:15:00 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7303716A41F for ; Tue, 24 Jan 2006 17:15:00 +0000 (GMT) (envelope-from julian@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5833643D66 for ; Tue, 24 Jan 2006 17:14:58 +0000 (GMT) (envelope-from julian@elischer.org) Received: from unknown (HELO [192.168.2.4]) ([10.251.60.68]) by a50.ironport.com with ESMTP; 24 Jan 2006 09:14:57 -0800 X-IronPort-Anti-Spam-Filtered: true Message-ID: <43D6608E.6060506@elischer.org> Date: Tue, 24 Jan 2006 09:14:54 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.11) Gecko/20050727 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Scott Long References: <43D63F5F.9080203@samsco.org> In-Reply-To: <43D63F5F.9080203@samsco.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, Pranav Peshwe Subject: Re: Difference between a kthread and an ordinary process. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2006 17:15:00 -0000 Scott Long wrote: > Pranav Peshwe wrote: > >> Hello, >> When a kthread is created using the kthread_create (9) >> function, i found out that a new instance of struct proc is created >> and allocated for the thread just as in case of a creation of a new >> process.Also, the thread is assigned a pid as in the case of a >> process. >> What is the difference between a kernel thread and a normal process >> created using fork ? except the address space sharing with swapper and >> kernel mode execution of the kthread. Is a kthread effectively just a >> process always running in kernel mode ? >> > > That is exactly what a kthread is. There is some work in process to > make them true threads within one or more processes. > see http://www.freebsd.org/~julian/kthread.diff > Scott > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to > "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 24 23:48:41 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DCA2816A420 for ; Tue, 24 Jan 2006 23:48:41 +0000 (GMT) (envelope-from surerlistmail@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.195]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6D7A543D4C for ; Tue, 24 Jan 2006 23:48:40 +0000 (GMT) (envelope-from surerlistmail@gmail.com) Received: by zproxy.gmail.com with SMTP id 9so1307706nzo for ; Tue, 24 Jan 2006 15:48:39 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=t9ueypGXgr0NGv4Yvlr2FsFMuZSPlWoBawwhPAxHltu9Y+G97LGaIDQtsWk6bo0dJ7mEapx6Q24GXFF/NRM57xy65Gac28u6H+Y47Wz/RuwaYqfjMcxMwj/pX2s/PGSCJVkJNgkV3k+ZslVA4O5WWrCtU9TZxoKkMOtn0+tosbA= Received: by 10.36.81.11 with SMTP id e11mr40052nzb; Tue, 24 Jan 2006 15:48:37 -0800 (PST) Received: by 10.36.41.11 with HTTP; Tue, 24 Jan 2006 15:48:37 -0800 (PST) Message-ID: Date: Tue, 24 Jan 2006 18:48:37 -0500 From: Surer Dink To: freebsd-hackers@freebsd.org MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 25 Jan 2006 00:28:33 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: CPU/case/disk temperature sensors for Dell PowerEdge 2850 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2006 23:48:42 -0000 All, (I was told this was /one/ of the appropriate forums for this message - however I did not want to cross-post - if this is not the correct place, please let me know and I will try the other suggestions [acpi- and ports-].= ) I have tried every means I could find to read the temperature sensors (CPU, case, disk) on Dell PowerEdge 2850 machines, and none seem to work. Has anyone had success in doing this? If such support does not exist, what would be required to add it? If needed, I am willing to finance (within reason) development of this feature. [I was told that Linux and Windows software to read this information is available, so I assume this is possible.] Thanks! From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 25 00:34:09 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C5D9B16A41F; Wed, 25 Jan 2006 00:34:09 +0000 (GMT) (envelope-from craig@tobuj.gank.org) Received: from ion.gank.org (ion.gank.org [69.55.238.164]) by mx1.FreeBSD.org (Postfix) with ESMTP id 89CBD43D45; Wed, 25 Jan 2006 00:34:09 +0000 (GMT) (envelope-from craig@tobuj.gank.org) Received: by ion.gank.org (mail, from userid 1001) id 1F5502AB34; Tue, 24 Jan 2006 18:34:09 -0600 (CST) Date: Tue, 24 Jan 2006 18:34:05 -0600 From: Craig Boston To: John Baldwin Message-ID: <20060125003405.GA29970@nowhere> Mail-Followup-To: Craig Boston , John Baldwin , freebsd-hackers@freebsd.org, Scott Long References: <20060120014307.GA3118@nowhere> <200601201542.23464.jhb@freebsd.org> <20060124022511.GA99552@nowhere> <200601241043.51094.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200601241043.51094.jhb@freebsd.org> User-Agent: Mutt/1.4.2.1i Cc: freebsd-hackers@freebsd.org, Scott Long Subject: Re: Weird PCI interrupt delivery problem (resolution, sort of) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2006 00:34:09 -0000 On Tue, Jan 24, 2006 at 10:43:49AM -0500, John Baldwin wrote: > What if you do a read of the lapic before the write? Maybe doing 'x = > lapic->eoi; lapic->eoi = 0;'? Reading the lapic before the write has no effect. Reading the lapic after the write makes it work. Craig From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 25 08:35:03 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 153CE16A41F for ; Wed, 25 Jan 2006 08:35:03 +0000 (GMT) (envelope-from pranavpeshwe@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.198]) by mx1.FreeBSD.org (Postfix) with ESMTP id C6C6543D6B for ; Wed, 25 Jan 2006 08:34:57 +0000 (GMT) (envelope-from pranavpeshwe@gmail.com) Received: by wproxy.gmail.com with SMTP id i31so46738wra for ; Wed, 25 Jan 2006 00:34:56 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=dtSKQikE241USSLH89QAvE/BWfdmNL0N5iv26sqt7UY8TJ55J95BKLiLm7zF7sUSKb1+nd81vMUKhfH6wCYDC/CYogwoVjHNxOz7gGK05+t6fF0EMPrd9g73GZjK0ubq0UY4Wayjrc9J1kg4D8fFaS5gzYEYCgzvu+g1yWZYW3o= Received: by 10.54.100.2 with SMTP id x2mr631956wrb; Wed, 25 Jan 2006 00:34:56 -0800 (PST) Received: by 10.54.99.13 with HTTP; Wed, 25 Jan 2006 00:34:56 -0800 (PST) Message-ID: Date: Wed, 25 Jan 2006 14:04:56 +0530 From: Pranav Peshwe To: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Subject: KTR not working !! X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2006 08:35:03 -0000 Hello, I recompiled the kernel with KTR (4) support.But i could find the logged messages nowhere ! When i use 'ktrdump' on the console ,the ouput is : index trace ------ ----- When i try to view the logging from DDB by issuing 'show ktr', only a message saying '--- End of trace buffer ---' is displayed. I paste a portion (related to debugging options) of the config file i used, to recompile the kernel. #----- options =09KTR=09=09=09=09 options =09KTR_ENTRIES=3D8192 options =09KTR_VERBOSE options=09=09INVARIANTS options =09INVARIANT_SUPPORT options =09WITNESS=09=09=09=09=09=09 options =09WITNESS_KDB options KDB options KDB_TRACE options DDB options GDB options=09BREAK_TO_DEBUGGER #----- Am i missing something very important ? How can i view the information logged by the various CTR[0-5] macros used in the kernel source ? TIA. Regards, Pranav --------------------------------------------------------------------------- Heisenberg is out for a drive when he's stopped by a traffic cop. The cop says: "Do you know how fast you were going?" Heisenberg replies: "No,but I know where I am" From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 25 08:40:30 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5CDDF16A41F for ; Wed, 25 Jan 2006 08:40:30 +0000 (GMT) (envelope-from pranavpeshwe@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id C5DFA43D45 for ; Wed, 25 Jan 2006 08:40:29 +0000 (GMT) (envelope-from pranavpeshwe@gmail.com) Received: by wproxy.gmail.com with SMTP id i31so47473wra for ; Wed, 25 Jan 2006 00:40:29 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=h345gMfL0pX+mQQ0gwAB/yEkk+GgyQgIkNgW+2P1UfmLUWyB0tqc1lwpfbGvLsXgPWK4YCgnBrpa0VYkNJr1JI6/8Ue/Vb8R8M4WQNN49eJFHClr/yamdttcYdOdGjfGSptOt9fPt5b0uxpVJMIos4uEqwT2drMPYDOkiaC/cko= Received: by 10.54.92.8 with SMTP id p8mr647415wrb; Wed, 25 Jan 2006 00:40:28 -0800 (PST) Received: by 10.54.99.13 with HTTP; Wed, 25 Jan 2006 00:40:27 -0800 (PST) Message-ID: Date: Wed, 25 Jan 2006 14:10:27 +0530 From: Pranav Peshwe To: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Subject: Re: KTR not working !! X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2006 08:40:30 -0000 Sorry !! Forgot to mention that I am using FreeBSD 5.4-RELEASE on the i386 platform. Regards, Pranav --------------------------------------------------------------------------- "Everything that can be invented has already been invented." -- Charles H. Duell, director of the U.S. Patent Office, 1899 From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 25 08:45:44 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AB12116A41F for ; Wed, 25 Jan 2006 08:45:44 +0000 (GMT) (envelope-from joseph.koshy@gmail.com) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4003843D46 for ; Wed, 25 Jan 2006 08:45:44 +0000 (GMT) (envelope-from joseph.koshy@gmail.com) Received: by xproxy.gmail.com with SMTP id s9so37082wxc for ; Wed, 25 Jan 2006 00:45:43 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=EQmvZgzxhEbKHA3R5LZg8sgBZtU8FLCyWqQIASgAYZGYgvb6sAFRO1jX+mOBhwVY031makPg9VDdbOOSoEYPuncoObrtjXxdP9Z1QVhmgiwZq3wKu17HedlF/Ep3k42h57xdGYaof9TnyWt1u5w/hLQXj8npv5Wy7kc/LMUefzE= Received: by 10.70.61.3 with SMTP id j3mr209385wxa; Wed, 25 Jan 2006 00:45:43 -0800 (PST) Received: by 10.70.105.2 with HTTP; Wed, 25 Jan 2006 00:45:43 -0800 (PST) Message-ID: <84dead720601250045h33447be0y21d6c2239749bd15@mail.gmail.com> Date: Wed, 25 Jan 2006 14:15:43 +0530 From: Joseph Koshy To: Pranav Peshwe In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: Cc: freebsd-hackers@freebsd.org Subject: Re: KTR not working !! X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2006 08:45:44 -0000 > #----- > options KTR > options KTR_ENTRIES=3D8192 > options KTR_VERBOSE ... > Am i missing something very important ? What is the value of sysctl debug.ktr.mask? -- FreeBSD Volunteer, http://people.freebsd.org/~jkoshy From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 25 08:58:20 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CE2F016A41F for ; Wed, 25 Jan 2006 08:58:20 +0000 (GMT) (envelope-from pranavpeshwe@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id 34A8743D53 for ; Wed, 25 Jan 2006 08:58:20 +0000 (GMT) (envelope-from pranavpeshwe@gmail.com) Received: by wproxy.gmail.com with SMTP id i31so49767wra for ; Wed, 25 Jan 2006 00:58:19 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=BIQLJbvt64LZya81v5qn23FF8gS1xkVzMZDg3A4kV3s8OxtIscXNIXMCUpykSdywVFlEdMN6lFsYXBTfA/7NL7gr8pL+NjxCZDDWB96X0Ee3m28MEEIvugGjfNVUi0taYAFqoL+tj8lSme5TSUBwmu9Sw2Qe/eO/OWj53E5H0/I= Received: by 10.54.114.1 with SMTP id m1mr666201wrc; Wed, 25 Jan 2006 00:58:19 -0800 (PST) Received: by 10.54.99.13 with HTTP; Wed, 25 Jan 2006 00:58:19 -0800 (PST) Message-ID: Date: Wed, 25 Jan 2006 14:28:19 +0530 From: Pranav Peshwe To: Joseph Koshy In-Reply-To: <84dead720601250045h33447be0y21d6c2239749bd15@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <84dead720601250045h33447be0y21d6c2239749bd15@mail.gmail.com> Cc: freebsd-hackers@freebsd.org Subject: Re: KTR not working !! X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2006 08:58:20 -0000 On 1/25/06, Joseph Koshy wrote: > > #----- > > options KTR > > options KTR_ENTRIES=3D8192 > > options KTR_VERBOSE > ... > > Am i missing something very important ? > > What is the value of sysctl debug.ktr.mask? Hello, Currently the value is 4608.I tried it setting to 0x3fffffff i.e KTR_ALL. But still did not work. Other KTR related values are : debug.ktr.cpumask: -1 debug.ktr.mask: 1073741823 debug.ktr.compile: 1 debug.ktr.entries: 8192 debug.ktr.version: 1 debug.ktr.verbose: 1 TIA. Regards, Pranav --------------------------------------------------------------------------- A formula is worth a thousand pictures. - Edsger W. Dijkstra From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 25 10:05:28 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D95FC16A41F for ; Wed, 25 Jan 2006 10:05:28 +0000 (GMT) (envelope-from kedentojas@yahoo.co.uk) Received: from web25413.mail.ukl.yahoo.com (web25413.mail.ukl.yahoo.com [217.146.176.231]) by mx1.FreeBSD.org (Postfix) with SMTP id 217D143D49 for ; Wed, 25 Jan 2006 10:05:27 +0000 (GMT) (envelope-from kedentojas@yahoo.co.uk) Received: (qmail 67812 invoked by uid 60001); 25 Jan 2006 10:05:22 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.uk; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=HB14Gc5knaTWcMoejMaGtqeZxwiIuwprlMij6ZY7+9Gy3jg1Qf3FbgekFIGpmRnLH1f14Xd/ZpmyvjV47+mkURJMNPJsun1Wqo4FpK6XR+bo1764GSTYhDqNJ50jPLrwOCqaRZGFTDxMxf3ybMfkwduuS0PIswYxD/v6BExll/E= ; Message-ID: <20060125100522.67806.qmail@web25413.mail.ukl.yahoo.com> Received: from [195.182.82.250] by web25413.mail.ukl.yahoo.com via HTTP; Wed, 25 Jan 2006 10:05:22 GMT Date: Wed, 25 Jan 2006 10:05:22 +0000 (GMT) From: Aivaras Kondrotas To: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: cat problems ? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2006 10:05:29 -0000 Can anybody explain me if cat command is different in Freebsd than in other linux/unix/bsd os'es, because this problem appear just in Freebsd. I am running a FreeBSD 6.0. To get working my printer I have to upgrade my firmware, but I get problem "cat: stdout: Input/output error". Searched for days in google, but it appears that all results leads to just Freebsd OS. Do I have to switch OS just to make my printer work? ---------------------------------------------------------------- #dmesg | grep ulpt ulpt0: Hewlett-Packard hp LaserJet 1000, rev 1.10/1.20, addr 2, iclass 7/1 ulpt0: using bi-directional mode # cat SIhp1000.dl > /dev/ulpt0 cat: stdout: Input/output error ___________________________________________________________ NEW Yahoo! Cars - sell your car and browse thousands of new and used cars online! http://uk.cars.yahoo.com/ From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 25 10:14:50 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A0F0D16A471 for ; Wed, 25 Jan 2006 10:14:50 +0000 (GMT) (envelope-from Jose-Marcio.Martins@ensmp.fr) Received: from saci.ensmp.fr (saci.ensmp.fr [194.214.158.176]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3195443D76 for ; Wed, 25 Jan 2006 10:14:45 +0000 (GMT) (envelope-from Jose-Marcio.Martins@ensmp.fr) Received: from [127.0.0.1] (localhost.ensmp.fr. [127.0.0.1]) by saci.ensmp.fr (sendmail X.1.0.PreAlpha0.0) with ESMTP id S00000000000002AF00; Wed, 25 Jan 2006 11:14:42 +0100 Message-ID: <43D74F91.2090009@ensmp.fr> Date: Wed, 25 Jan 2006 11:14:41 +0100 From: Jose Marcio Martins da Cruz User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20041221 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-hackers@freebsd.org X-Enigmail-Version: 0.90.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Changes from 5.2.1 to 5.3 (theads / signal handling) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2006 10:14:50 -0000 Hello, I have a problem with an application I wrote. It works fine under Solaris, Linux, and FreeBSD till release 5.2.1. Under FreeBSD 5.3 and newers I have problems. The application is constituted by two processes : a supervisor and modules. The supervisor forks and become a module when it shall launch one. The supervisor is a single loop and it has a thread to handle signals. Each module is a multithreaded server, with its own thread to handle signals. Under FreeBSD 5.3 and newers, when the supervisor forks to become a module, it receives a SIGABRT and exits immediately when it launches the signal handler thread. I solved this by replacing the signal handling of the father : using a handler defined with sigaction instead of using a thread. But I'd like to understanding what's wrong with this and what changed from FreeBSD 5.2.1 to 5.3 Thanks Jose-Marcio From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 25 08:13:43 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 985AA16A41F for ; Wed, 25 Jan 2006 08:13:43 +0000 (GMT) (envelope-from jarda@grisoft.cz) Received: from ms.grisoft.cz (ms.grisoft.cz [193.85.188.248]) by mx1.FreeBSD.org (Postfix) with ESMTP id 11AED43D46 for ; Wed, 25 Jan 2006 08:13:42 +0000 (GMT) (envelope-from jarda@grisoft.cz) Received: from localhost (gate2 [127.0.0.1]) by ms.grisoft.cz (Postfix) with ESMTP id 314116801E; Wed, 25 Jan 2006 09:13:41 +0100 (CET) Received: from ms.grisoft.cz ([127.0.0.1]) by localhost (gate2 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10683-06; Wed, 25 Jan 2006 09:13:41 +0100 (CET) Received: from jardas.grisoft.cz (jardas.grisoft.cz [192.168.104.167]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ms.grisoft.cz (Postfix) with ESMTP id E8C5468018; Wed, 25 Jan 2006 09:13:40 +0100 (CET) Received: from jardas.grisoft.cz (localhost [127.0.0.1]) by jardas.grisoft.cz (8.13.4/8.13.3) with ESMTP id k0P8DZov091601; Wed, 25 Jan 2006 09:13:35 +0100 (CET) (envelope-from jarda@jardas.grisoft.cz) Received: (from jarda@localhost) by jardas.grisoft.cz (8.13.4/8.13.4/Submit) id k0P8DYbA091600; Wed, 25 Jan 2006 09:13:34 +0100 (CET) (envelope-from jarda) Date: Wed, 25 Jan 2006 09:13:34 +0100 From: JAroslav Suchanek To: Surer Dink Message-ID: <20060125081334.GL51084@jardas.grisoft.cz> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 6.0-STABLE X-Virus-Scanned: by AVG Anti-Virus at grisoft.cz X-Mailman-Approved-At: Wed, 25 Jan 2006 12:32:05 +0000 Cc: freebsd-hackers@freebsd.org Subject: Re: CPU/case/disk temperature sensors for Dell PowerEdge 2850 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2006 08:13:43 -0000 Hi, have you tried ipmitools? See sysutils/ipmitool. -- Jaroslav Suchanek On Tue, Jan 24, 2006 at 06:48:37PM -0500, Surer Dink wrote: > All, > (I was told this was /one/ of the appropriate forums for this message - > however I did not want to cross-post - if this is not the correct place, > please let me know and I will try the other suggestions [acpi- and ports-].) > > I have tried every means I could find to read the temperature sensors (CPU, > case, disk) on Dell PowerEdge 2850 machines, and none seem to work. Has > anyone had success in doing this? If such support does not exist, what > would be required to add it? If needed, I am willing to finance (within > reason) development of this feature. [I was told that Linux and Windows > software to read this information is available, so I assume this is > possible.] > > Thanks! > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 25 12:47:11 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F25E716A41F for ; Wed, 25 Jan 2006 12:47:10 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 31CC143D49 for ; Wed, 25 Jan 2006 12:47:07 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (ppp208-69.lns1.adl2.internode.on.net [203.122.208.69]) (authenticated bits=0) by cain.gsoft.com.au (8.13.5/8.13.4) with ESMTP id k0PCl2Vc060517 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Jan 2006 23:17:02 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-hackers@freebsd.org Date: Wed, 25 Jan 2006 23:17:01 +1030 User-Agent: KMail/1.9.1 References: <20060125100522.67806.qmail@web25413.mail.ukl.yahoo.com> In-Reply-To: <20060125100522.67806.qmail@web25413.mail.ukl.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1441775.nHkQUMsTWo"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200601252317.01768.doconnor@gsoft.com.au> X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.54 on 203.31.81.10 Cc: Aivaras Kondrotas Subject: Re: cat problems ? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2006 12:47:11 -0000 --nextPart1441775.nHkQUMsTWo Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wednesday 25 January 2006 20:35, Aivaras Kondrotas wrote: > #dmesg | grep ulpt > ulpt0: Hewlett-Packard hp LaserJet 1000, rev > 1.10/1.20, addr 2, iclass 7/1 > ulpt0: using bi-directional mode > > # cat SIhp1000.dl > /dev/ulpt0 > cat: stdout: Input/output error I don't think it is cat, it's the ulpt driver. You haven't said what version of FreeBSD you're using. Have you tried outputting to /dev/unplt0? =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart1441775.nHkQUMsTWo Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQBD13NF5ZPcIHs/zowRAhmrAJ4nYaMGYhDp1mSXPb1lOEtqZL+7tACgpXGC FiH4z4E4Ib7iYjSrrR73KHk= =nqCu -----END PGP SIGNATURE----- --nextPart1441775.nHkQUMsTWo-- From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 25 13:44:47 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 150B016A41F for ; Wed, 25 Jan 2006 13:44:47 +0000 (GMT) (envelope-from ducrot@poupinou.org) Received: from poup.poupinou.org (poup.poupinou.org [195.101.94.96]) by mx1.FreeBSD.org (Postfix) with ESMTP id AA20043D48 for ; Wed, 25 Jan 2006 13:44:46 +0000 (GMT) (envelope-from ducrot@poupinou.org) Received: from ducrot by poup.poupinou.org with local (Exim) id 1F1kwz-0003CB-00; Wed, 25 Jan 2006 14:44:41 +0100 Date: Wed, 25 Jan 2006 14:44:41 +0100 To: Surer Dink Message-ID: <20060125134441.GA11603@poupinou.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i From: Bruno Ducrot Cc: freebsd-hackers@freebsd.org Subject: Re: CPU/case/disk temperature sensors for Dell PowerEdge 2850 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2006 13:44:47 -0000 On Tue, Jan 24, 2006 at 06:48:37PM -0500, Surer Dink wrote: > All, > (I was told this was /one/ of the appropriate forums for this message - > however I did not want to cross-post - if this is not the correct place, > please let me know and I will try the other suggestions [acpi- and ports-].) > > I have tried every means I could find to read the temperature sensors (CPU, > case, disk) on Dell PowerEdge 2850 machines, and none seem to work. Has > anyone had success in doing this? If such support does not exist, what > would be required to add it? If needed, I am willing to finance (within > reason) development of this feature. [I was told that Linux and Windows > software to read this information is available, so I assume this is > possible.] > First, install sysutils/freeipmi, then try it by this command: # bmc-info If it don't work, or loop forever, please install dmidecode (sysutils/dmidecode) then give us the output from it for the type entry 38 (IPMI Device Information). An example of such entry is: Handle 0x002B DMI type 38, 18 bytes. IPMI Device Information Interface Type: KCS (Keyboard Control Style) Specification Version: 1.5 I2C Slave Address: 0x10 NV Storage Device: Not Present Base Address: 0x0000000000000CA8 (I/O) Register Spacing: 32-bit Boundaries Cheers, -- Bruno Ducrot -- Which is worse: ignorance or apathy? -- Don't know. Don't care. From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 25 13:55:32 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 026E016A41F for ; Wed, 25 Jan 2006 13:55:32 +0000 (GMT) (envelope-from ray@redshift.com) Received: from mail-webmail.redshift.com (mail-webmail.redshift.com [216.228.2.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id C7AD243D45 for ; Wed, 25 Jan 2006 13:55:31 +0000 (GMT) (envelope-from ray@redshift.com) Received: (qmail 18775 invoked by uid 89); 25 Jan 2006 13:55:30 -0000 Received: from unknown (HELO workstation) (216.228.19.21) by mail-webmail.redshift.com with SMTP; 25 Jan 2006 13:55:30 -0000 Message-Id: <3.0.1.32.20060125055530.00f47428@pop.redshift.com> X-Mailer: na X-Sender: redshift.com Date: Wed, 25 Jan 2006 05:55:30 -0800 To: freebsd-hackers@freebsd.org From: ray@redshift.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: streaming server question X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2006 13:55:32 -0000 Just a shot in the dark... anyone on the list have any experience with streaming audio servers for FreeBSD? I've installed icecast2, but seems like the lag time between broadcast and reception by clients is up to 60 seconds (??). I have heard that darwin's streaming server by Apple works, but have as of yet not installed it. Just wondering if anyone has fooled around in this area for audio or video? Thanks! Ray From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 25 14:08:20 2006 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B935C16A431 for ; Wed, 25 Jan 2006 14:08:20 +0000 (GMT) (envelope-from vit.ska@gmail.com) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id 449D243D48 for ; Wed, 25 Jan 2006 14:08:20 +0000 (GMT) (envelope-from vit.ska@gmail.com) Received: by xproxy.gmail.com with SMTP id s9so72322wxc for ; Wed, 25 Jan 2006 06:08:19 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=GvyZbK+i0gR9Fqyqr+2JfMxTPMXnC6LzZE2GHkq3VaJAkz00C2O+8zD107NV/sziKKdCkIGoqPRuGyngVdDeOk0BXRnLVK7TjLRxGH/CoKQxrVexGXKkPG2lKmMndl0eJ3EXAEG1if/yZHo4YXrbWiGajWKAcwFesPPIWwhnrns= Received: by 10.70.28.9 with SMTP id b9mr911357wxb; Wed, 25 Jan 2006 06:08:19 -0800 (PST) Received: by 10.70.118.3 with HTTP; Wed, 25 Jan 2006 06:08:19 -0800 (PST) Message-ID: <806128ad0601250608u67aae744u@mail.gmail.com> Date: Wed, 25 Jan 2006 16:08:19 +0200 From: Vitaliy Skakun To: hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_23569_13959861.1138198099382" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Comtrol Rocketport UNIVERSAL PCI 32-port X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2006 14:08:20 -0000 ------=_Part_23569_13959861.1138198099382 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline SGkgZXZlcnlib2R5IQoKRHVlIHRvIGh0dHA6Ly93d3cuZnJlZWJzZC5vcmcvcmVsZWFzZXMvNi4w Ui9oYXJkd2FyZS1pMzg2Lmh0bWwgLCB0cmllZCB0bwpzZXQgdXAgdGhlIGZvbGxvd2luZyBkZXZp Y2UKd2l0aCBkcml2ZXIgcnAoNCk6Cmh0dHA6Ly93d3cuc2hvcGNvbXRyb2wuY29tL3Byb2R1Y3Qu YXNwP3NrdT0yMzM4NTEwCgpyb290QHBsMjovPDM+ZGV2L3JwIFswXSMgdW5hbWUgLWEKRnJlZUJT RCBwbDIueHh4Lnl5eSA2LjAtU1RBQkxFIEZyZWVCU0QgNi4wLVNUQUJMRSAjNzogV2VkIEphbiAy NSAxMDo0OToyOApVVEMgMjAwNiAgICAgcm9vdEBwbDIueHh4Lnl5eTovdXNyL29iai91c3Ivc3Jj L3N5cy9KQk9TUy00QlNEIGkzODYKCiggUkVMRU5HXzYgIGRhdGluZyBhYm91dCBtaWRkbGUgb2Yg RGVjZW1iZXIsIDIwMDUgKQoKSSBnb3QgdGhlIGZvbGxvd2luZyBtZXNzYWdlIGZyb20ga2VybmVs OgpycDA6IDxSb2NrZXRQb3J0IFBDST4gcG9ydCAweDljODAtMHg5Y2ZmLDB4OTgwMC0weDk4ZmYg bWVtCjB4ZmRjZmZjMDAtMHhmZGNmZmM3ZiBpcnEgMTYgYXQgZGV2aWNlIDEuMCBvbiBwY2kxNgpy cDA6IGlvYWRkciBtYXBwaW5nIGZhaWxlZCBmb3IgUm9ja2V0UG9ydChQQ0kpLgpkZXZpY2VfYXR0 YWNoOiBycDAgYXR0YWNoIHJldHVybmVkIDYKCkFmdGVyIHF1aWNrIGludmVzdGlnYXRpb24gZGlz Y292ZXJlZCB0aGF0IHJwKDQpIGRvZXNuJ3QgaGF2ZSBzdXBwb3J0IGZvcgp0aGlzIGRldmljZSdz IFBDSSBpZCAoIGNvcnJlY3QgbWUgcGxzIGlmIG15IHVuZGVyc3RhbmRpbmcgaXMgd3JvbmcpLApz byBJIGFkZGVkIGl0LgoKcm9vdEBwbDI6LzwzPmRldi9ycCBbMF0jIHBjaWNvbmYgLWx2CgojLi4u b3V0cHV0IHNraXBwZWQKCnJwMEBwY2kxNjoxOjA6ICBjbGFzcz0weDA3ODAwMCBjYXJkPTB4MDgw MTExZmUgY2hpcD0weDA4MDExMWZlIHJldj0weDAxCmhkcj0weDAwCiAgICB2ZW5kb3IgICA9ICdD b210cm9sIENvcnAnCiAgICBkZXZpY2UgICA9ICdSb2NrZXRQb3J0IFVQQ0kgMzIgcG9ydCB3L2V4 dGVybmFsIEkvRicKICAgIGNsYXNzICAgID0gc2ltcGxlIGNvbW1zCgpkZXZpY2UgaWQgPSAweDA4 MDEKCkFzIHRoZSBjdXJyZW50IFJFTEVOR182IHJwX3BjaS5jIHJldmlzaW9uIGlzIHRoZSBzYW1l IGFzIEkgaGF2ZSBvbiBzZXJ2ZXIgKD0KMS4xMSksIEkgYXR0YWNoZWQgdGhlIHBhdGNoLgpQbHMg Y2hlY2suCgpQLlMuIEFmdGVyIHRoaXMgYXBwbHlpbmcgcGF0Y2ggdGhlIGRldmljZSBzZWVtIHRv IGJlIHdvcmtpbmcgb2s6CnJvb3RAcGwyOi88Mz5kZXYvcnAgWzBdIyBncmVwIC1pIHJvY2tldHBv cnQgL3Zhci9ydW4vZG1lc2cuYm9vdApycDA6IDxSb2NrZXRQb3J0IFBDST4gcG9ydCAweDljODAt MHg5Y2ZmLDB4OTgwMC0weDk4ZmYgbWVtCjB4ZmRjZmZjMDAtMHhmZGNmZmM3ZiBpcnEgMTYgYXQg ZGV2aWNlIDEuMCBvbiBwY2kxNgpSb2NrZXRQb3J0MCAoVmVyc2lvbiAzLjAyKSAzMiBwb3J0cy4K CkxvdHMgb2Ygc2VyaWFsIGRldmljZXMgYXBwZWFyZWQgaW4gL2Rldi8gLCBhbmQgc2ltcGxlIHRl c3Rpbmcgc2hvdyB0aGVtCndvcmtpbmcuCgpDaGVlcnMsClZpdAo= ------=_Part_23569_13959861.1138198099382 Content-Type: application/octet-stream; name=rp_pci.c.1.11.diff Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="rp_pci.c.1.11.diff" --- rp_pci.c.orig Wed Jan 25 11:21:42 2006 +++ rp_pci.c Wed Jan 25 11:19:52 2006 @@ -68,6 +68,7 @@ #define RP_DEVICE_ID_6M 0x000C #define RP_DEVICE_ID_4M 0x000D #define RP_DEVICE_ID_UPCI_8O 0x0805 +#define RP_DEVICE_ID_UPCI_32 0x0801 /************************************************************************** MUDBAC remapped for PCI @@ -180,6 +181,7 @@ switch (pci_get_device(dev)) { case RP_DEVICE_ID_UPCI_8O: + case RP_DEVICE_ID_UPCI_32: ctlp->io_rid[0] = PCIR_BAR(2); break; default: ------=_Part_23569_13959861.1138198099382-- From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 25 14:56:03 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BE23216A41F for ; Wed, 25 Jan 2006 14:56:03 +0000 (GMT) (envelope-from ashas@takas.lt) Received: from calypso.bi.lt (calypso.bi.lt [213.226.153.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 594BF43D48 for ; Wed, 25 Jan 2006 14:56:03 +0000 (GMT) (envelope-from ashas@takas.lt) Received: from calypso.bi.lt (localhost [127.0.0.1]) by calypso.bi.lt (Postfix) with ESMTP id B96BB481054 for ; Wed, 25 Jan 2006 16:56:01 +0200 (EET) Received: from [127.0.0.1] (unknown [84.15.66.60]) by calypso.bi.lt (Postfix) with ESMTP id 9ED65481047 for ; Wed, 25 Jan 2006 16:56:01 +0200 (EET) Message-ID: <43D79179.4090700@takas.lt> Date: Wed, 25 Jan 2006 16:55:53 +0200 From: ashas@takas.lt User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 CC: freebsd-hackers@freebsd.org References: <20060125100522.67806.qmail@web25413.mail.ukl.yahoo.com> <200601252317.01768.doconnor@gsoft.com.au> In-Reply-To: <200601252317.01768.doconnor@gsoft.com.au> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: cat problems ? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2006 14:56:03 -0000 Same problem for me on freebsd 6.0, but on archlinux working just fine. Tryed on /dev/ulpt0 and /dev/unlpt0 - same error. Daniel O'Connor wrote: > On Wednesday 25 January 2006 20:35, Aivaras Kondrotas wrote: > >> #dmesg | grep ulpt >> ulpt0: Hewlett-Packard hp LaserJet 1000, rev >> 1.10/1.20, addr 2, iclass 7/1 >> ulpt0: using bi-directional mode >> >> # cat SIhp1000.dl > /dev/ulpt0 >> cat: stdout: Input/output error >> > > I don't think it is cat, it's the ulpt driver. > You haven't said what version of FreeBSD you're using. > > Have you tried outputting to /dev/unplt0? > > From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 25 14:56:08 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CC19116A41F for ; Wed, 25 Jan 2006 14:56:08 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.FreeBSD.org (Postfix) with ESMTP id BF89943D45 for ; Wed, 25 Jan 2006 14:56:07 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.5b3) with ESMTP id 6941701 for multiple; Wed, 25 Jan 2006 09:54:53 -0500 Received: from localhost (john@localhost [127.0.0.1]) by server.baldwin.cx (8.13.4/8.13.4) with ESMTP id k0PEu2gm024929; Wed, 25 Jan 2006 09:56:04 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: Craig Boston Date: Wed, 25 Jan 2006 09:16:57 -0500 User-Agent: KMail/1.9.1 References: <20060120014307.GA3118@nowhere> <200601241043.51094.jhb@freebsd.org> <20060125003405.GA29970@nowhere> In-Reply-To: <20060125003405.GA29970@nowhere> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200601250916.59336.jhb@freebsd.org> X-Virus-Scanned: ClamAV 0.87.1/1248/Tue Jan 24 05:54:38 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.4 required=4.2 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on server.baldwin.cx X-Server: High Performance Mail Server - http://surgemail.com r=1653887525 Cc: freebsd-hackers@freebsd.org, Scott Long Subject: Re: Weird PCI interrupt delivery problem (resolution, sort of) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2006 14:56:08 -0000 On Tuesday 24 January 2006 19:34, Craig Boston wrote: > On Tue, Jan 24, 2006 at 10:43:49AM -0500, John Baldwin wrote: > > What if you do a read of the lapic before the write? Maybe doing 'x = > > lapic->eoi; lapic->eoi = 0;'? > > Reading the lapic before the write has no effect. > > Reading the lapic after the write makes it work. Hmm, perhaps the read forces the write to post? Scott? -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 25 14:56:13 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3287816A41F for ; Wed, 25 Jan 2006 14:56:13 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8306C43D45 for ; Wed, 25 Jan 2006 14:56:12 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.5b3) with ESMTP id 6941710 for multiple; Wed, 25 Jan 2006 09:55:00 -0500 Received: from localhost (john@localhost [127.0.0.1]) by server.baldwin.cx (8.13.4/8.13.4) with ESMTP id k0PEu2go024929; Wed, 25 Jan 2006 09:56:09 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Wed, 25 Jan 2006 09:52:40 -0500 User-Agent: KMail/1.9.1 References: <84dead720601250045h33447be0y21d6c2239749bd15@mail.gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200601250952.41784.jhb@freebsd.org> X-Virus-Scanned: ClamAV 0.87.1/1248/Tue Jan 24 05:54:38 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.4 required=4.2 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on server.baldwin.cx X-Server: High Performance Mail Server - http://surgemail.com r=1653887525 Cc: Pranav Peshwe Subject: Re: KTR not working !! X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2006 14:56:13 -0000 On Wednesday 25 January 2006 03:58, Pranav Peshwe wrote: > On 1/25/06, Joseph Koshy wrote: > > > #----- > > > options KTR > > > options KTR_ENTRIES=8192 > > > options KTR_VERBOSE > > > > ... > > > > > Am i missing something very important ? > > > > What is the value of sysctl debug.ktr.mask? > > Hello, > Currently the value is 4608.I tried it setting to 0x3fffffff > i.e KTR_ALL. But still did not work. > Other KTR related values are : > > debug.ktr.cpumask: -1 > debug.ktr.mask: 1073741823 > debug.ktr.compile: 1 You only have KTR_GEN traces compiled in. Try adding 'KTR_COMPILE=KTR_ALL' If you run with all traces enabled your system is going to get really really slow though. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 25 14:56:16 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0C3A216A41F; Wed, 25 Jan 2006 14:56:16 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.FreeBSD.org (Postfix) with ESMTP id 468F843D45; Wed, 25 Jan 2006 14:56:15 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.5b3) with ESMTP id 6941713 for multiple; Wed, 25 Jan 2006 09:55:02 -0500 Received: from localhost (john@localhost [127.0.0.1]) by server.baldwin.cx (8.13.4/8.13.4) with ESMTP id k0PEu2gp024929; Wed, 25 Jan 2006 09:56:12 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Wed, 25 Jan 2006 09:56:34 -0500 User-Agent: KMail/1.9.1 References: <806128ad0601250608u67aae744u@mail.gmail.com> In-Reply-To: <806128ad0601250608u67aae744u@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200601250956.35818.jhb@freebsd.org> X-Virus-Scanned: ClamAV 0.87.1/1248/Tue Jan 24 05:54:38 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.4 required=4.2 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on server.baldwin.cx X-Server: High Performance Mail Server - http://surgemail.com r=1653887525 Cc: hackers@freebsd.org, Vitaliy Skakun Subject: Re: Comtrol Rocketport UNIVERSAL PCI 32-port X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2006 14:56:16 -0000 On Wednesday 25 January 2006 09:08, Vitaliy Skakun wrote: > Hi everybody! > > Due to http://www.freebsd.org/releases/6.0R/hardware-i386.html , tried to > set up the following device > with driver rp(4): > http://www.shopcomtrol.com/product.asp?sku=2338510 > > root@pl2:/<3>dev/rp [0]# uname -a > FreeBSD pl2.xxx.yyy 6.0-STABLE FreeBSD 6.0-STABLE #7: Wed Jan 25 10:49:28 > UTC 2006 root@pl2.xxx.yyy:/usr/obj/usr/src/sys/JBOSS-4BSD i386 > > ( RELENG_6 dating about middle of December, 2005 ) > > I got the following message from kernel: > rp0: port 0x9c80-0x9cff,0x9800-0x98ff mem > 0xfdcffc00-0xfdcffc7f irq 16 at device 1.0 on pci16 > rp0: ioaddr mapping failed for RocketPort(PCI). > device_attach: rp0 attach returned 6 > > After quick investigation discovered that rp(4) doesn't have support for > this device's PCI id ( correct me pls if my understanding is wrong), > so I added it. > > root@pl2:/<3>dev/rp [0]# pciconf -lv > > #...output skipped > > rp0@pci16:1:0: class=0x078000 card=0x080111fe chip=0x080111fe rev=0x01 > hdr=0x00 > vendor = 'Comtrol Corp' > device = 'RocketPort UPCI 32 port w/external I/F' > class = simple comms > > device id = 0x0801 > > As the current RELENG_6 rp_pci.c revision is the same as I have on server > (= 1.11), I attached the patch. > Pls check. > > P.S. After this applying patch the device seem to be working ok: > root@pl2:/<3>dev/rp [0]# grep -i rocketport /var/run/dmesg.boot > rp0: port 0x9c80-0x9cff,0x9800-0x98ff mem > 0xfdcffc00-0xfdcffc7f irq 16 at device 1.0 on pci16 > RocketPort0 (Version 3.02) 32 ports. > > Lots of serial devices appeared in /dev/ , and simple testing show them > working. > > Cheers, > Vit I've committed it to HEAD and will MFC in a few days so it will be in 6.1. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 25 14:56:16 2006 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0C3A216A41F; Wed, 25 Jan 2006 14:56:16 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.FreeBSD.org (Postfix) with ESMTP id 468F843D45; Wed, 25 Jan 2006 14:56:15 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.5b3) with ESMTP id 6941713 for multiple; Wed, 25 Jan 2006 09:55:02 -0500 Received: from localhost (john@localhost [127.0.0.1]) by server.baldwin.cx (8.13.4/8.13.4) with ESMTP id k0PEu2gp024929; Wed, 25 Jan 2006 09:56:12 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Wed, 25 Jan 2006 09:56:34 -0500 User-Agent: KMail/1.9.1 References: <806128ad0601250608u67aae744u@mail.gmail.com> In-Reply-To: <806128ad0601250608u67aae744u@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200601250956.35818.jhb@freebsd.org> X-Virus-Scanned: ClamAV 0.87.1/1248/Tue Jan 24 05:54:38 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.4 required=4.2 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on server.baldwin.cx X-Server: High Performance Mail Server - http://surgemail.com r=1653887525 Cc: hackers@freebsd.org, Vitaliy Skakun Subject: Re: Comtrol Rocketport UNIVERSAL PCI 32-port X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2006 14:56:16 -0000 On Wednesday 25 January 2006 09:08, Vitaliy Skakun wrote: > Hi everybody! > > Due to http://www.freebsd.org/releases/6.0R/hardware-i386.html , tried to > set up the following device > with driver rp(4): > http://www.shopcomtrol.com/product.asp?sku=2338510 > > root@pl2:/<3>dev/rp [0]# uname -a > FreeBSD pl2.xxx.yyy 6.0-STABLE FreeBSD 6.0-STABLE #7: Wed Jan 25 10:49:28 > UTC 2006 root@pl2.xxx.yyy:/usr/obj/usr/src/sys/JBOSS-4BSD i386 > > ( RELENG_6 dating about middle of December, 2005 ) > > I got the following message from kernel: > rp0: port 0x9c80-0x9cff,0x9800-0x98ff mem > 0xfdcffc00-0xfdcffc7f irq 16 at device 1.0 on pci16 > rp0: ioaddr mapping failed for RocketPort(PCI). > device_attach: rp0 attach returned 6 > > After quick investigation discovered that rp(4) doesn't have support for > this device's PCI id ( correct me pls if my understanding is wrong), > so I added it. > > root@pl2:/<3>dev/rp [0]# pciconf -lv > > #...output skipped > > rp0@pci16:1:0: class=0x078000 card=0x080111fe chip=0x080111fe rev=0x01 > hdr=0x00 > vendor = 'Comtrol Corp' > device = 'RocketPort UPCI 32 port w/external I/F' > class = simple comms > > device id = 0x0801 > > As the current RELENG_6 rp_pci.c revision is the same as I have on server > (= 1.11), I attached the patch. > Pls check. > > P.S. After this applying patch the device seem to be working ok: > root@pl2:/<3>dev/rp [0]# grep -i rocketport /var/run/dmesg.boot > rp0: port 0x9c80-0x9cff,0x9800-0x98ff mem > 0xfdcffc00-0xfdcffc7f irq 16 at device 1.0 on pci16 > RocketPort0 (Version 3.02) 32 ports. > > Lots of serial devices appeared in /dev/ , and simple testing show them > working. > > Cheers, > Vit I've committed it to HEAD and will MFC in a few days so it will be in 6.1. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 25 15:04:04 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A14FC16A423 for ; Wed, 25 Jan 2006 15:04:04 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id E1B9C43D55 for ; Wed, 25 Jan 2006 15:04:02 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (junior.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id k0PF41bF027527; Wed, 25 Jan 2006 08:04:01 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <43D79367.6020304@samsco.org> Date: Wed, 25 Jan 2006 08:04:07 -0700 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20051230 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Craig Boston References: <20060120014307.GA3118@nowhere> <200601241043.51094.jhb@freebsd.org> <20060125003405.GA29970@nowhere> <200601250916.59336.jhb@freebsd.org> In-Reply-To: <200601250916.59336.jhb@freebsd.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on pooker.samsco.org Cc: freebsd-hackers@freebsd.org Subject: Re: Weird PCI interrupt delivery problem (resolution, sort of) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2006 15:04:04 -0000 John Baldwin wrote: > On Tuesday 24 January 2006 19:34, Craig Boston wrote: > >>On Tue, Jan 24, 2006 at 10:43:49AM -0500, John Baldwin wrote: >> >>>What if you do a read of the lapic before the write? Maybe doing 'x = >>>lapic->eoi; lapic->eoi = 0;'? >> >>Reading the lapic before the write has no effect. >> >>Reading the lapic after the write makes it work. > > > Hmm, perhaps the read forces the write to post? Scott? > Either that, or the read imposes enough delay to let whatever was happening during the DELAY call work. I find it hard to believe that uncached writes would get delayed like this. I've lost the original posting on this, could you provide the dmesg and computer make/model again? Scott From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 25 18:40:10 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ED36816A41F for ; Wed, 25 Jan 2006 18:40:10 +0000 (GMT) (envelope-from wayne@manor.msen.com) Received: from manor.msen.com (manor.msen.com [148.59.4.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 81FC043D46 for ; Wed, 25 Jan 2006 18:40:08 +0000 (GMT) (envelope-from wayne@manor.msen.com) Received: from manor.msen.com (localhost [127.0.0.1]) by manor.msen.com (8.12.9p2/8.12.9) with ESMTP id k0PIe6c1018352 for ; Wed, 25 Jan 2006 13:40:06 -0500 (EST) (envelope-from wayne@manor.msen.com) Received: (from wayne@localhost) by manor.msen.com (8.12.9p2/8.12.9/Submit) id k0PIe6MB018351 for freebsd-hackers@freebsd.org; Wed, 25 Jan 2006 13:40:06 -0500 (EST) (envelope-from wayne) Date: Wed, 25 Jan 2006 13:40:06 -0500 From: "Michael R. Wayne" To: freebsd-hackers@freebsd.org Message-ID: <20060125184006.GQ64778@manor.msen.com> Mail-Followup-To: freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: Debugging a hanging 5.4 system X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2006 18:40:11 -0000 We've got a system running 5.4-RELEASE-p8 that occasionally hangs while dump is running. I suspect it's something to do with the SCSI controller hanging: ahc0: because the machine remains pingable and I can hit on the serial console and keep getting login prompts until I enter a username at which point the machine ceases to respond. I've compiled a kernel with include GENERIC options ALT_BREAK_TO_DEBUGGER options KDB options DDB in preparation for the last crash. There is a portmaster hooked to the serial port so that I can telnet to it and break to the debugger. Obviously, I will not be able to create a crash dump. My question is what specific DDB commands I should use when the system is hung so that I can generate sufficient information to create a useful PR. Any other hints/tips would also be appreciated. /\/\ \/\/ From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 25 18:46:32 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4257816A41F for ; Wed, 25 Jan 2006 18:46:32 +0000 (GMT) (envelope-from julian@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0A4D243D45 for ; Wed, 25 Jan 2006 18:46:31 +0000 (GMT) (envelope-from julian@elischer.org) Received: from unknown (HELO [10.251.17.229]) ([10.251.17.229]) by a50.ironport.com with ESMTP; 25 Jan 2006 10:46:31 -0800 Message-ID: <43D7C786.1090803@elischer.org> Date: Wed, 25 Jan 2006 10:46:30 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.11) Gecko/20050727 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jose Marcio Martins da Cruz References: <43D74F91.2090009@ensmp.fr> In-Reply-To: <43D74F91.2090009@ensmp.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: Changes from 5.2.1 to 5.3 (theads / signal handling) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2006 18:46:32 -0000 Jose Marcio Martins da Cruz wrote: >Hello, > >I have a problem with an application I wrote. > >It works fine under Solaris, Linux, and FreeBSD till release 5.2.1. > >Under FreeBSD 5.3 and newers I have problems. > >The application is constituted by two processes : a supervisor and modules. The >supervisor forks and become a module when it shall launch one. > >The supervisor is a single loop and it has a thread to handle signals. Each >module is a multithreaded server, with its own thread to handle signals. > >Under FreeBSD 5.3 and newers, when the supervisor forks to become a module, it >receives a SIGABRT and exits immediately when it launches the signal handler thread. > >I solved this by replacing the signal handling of the father : using a handler >defined with sigaction instead of using a thread. But I'd like to understanding >what's wrong with this and what changed from FreeBSD 5.2.1 to 5.3 > > a new threading library. have you tried 6.0? also, does the child do an exec() after forking? >Thanks > >Jose-Marcio >_______________________________________________ >freebsd-hackers@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > > From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 25 19:04:23 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B5FE816A41F for ; Wed, 25 Jan 2006 19:04:23 +0000 (GMT) (envelope-from julian@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8135E43D46 for ; Wed, 25 Jan 2006 19:04:23 +0000 (GMT) (envelope-from julian@elischer.org) Received: from unknown (HELO [10.251.17.229]) ([10.251.17.229]) by a50.ironport.com with ESMTP; 25 Jan 2006 11:04:23 -0800 Message-ID: <43D7CBB7.8070306@elischer.org> Date: Wed, 25 Jan 2006 11:04:23 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.11) Gecko/20050727 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ray@redshift.com References: <3.0.1.32.20060125055530.00f47428@pop.redshift.com> In-Reply-To: <3.0.1.32.20060125055530.00f47428@pop.redshift.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: streaming server question X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2006 19:04:23 -0000 ray@redshift.com wrote: >Just a shot in the dark... anyone on the list have any experience with streaming >audio servers for FreeBSD? I've installed icecast2, but seems like the lag time >between broadcast and reception by clients is up to 60 seconds (??). I have >heard that darwin's streaming server by Apple works, but have as of yet not >installed it. Just wondering if anyone has fooled around in this area for audio >or video? > > I've used tghe apple streaming server.. seems to work.. I have only streamed video from the apple broadcaster on my powerbook. p.s. you should have posted to "multimedia@freebsd.org" >Thanks! > >Ray > >_______________________________________________ >freebsd-hackers@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > > From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 25 21:21:07 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C5C2816A54B for ; Wed, 25 Jan 2006 21:20:56 +0000 (GMT) (envelope-from Jose-Marcio.Martins@ensmp.fr) Received: from joe.j-chkmail.org (mar92-6-82-226-38-60.fbx.proxad.net [82.226.38.60]) by mx1.FreeBSD.org (Postfix) with ESMTP id C02FA44635 for ; Wed, 25 Jan 2006 20:49:35 +0000 (GMT) (envelope-from Jose-Marcio.Martins@ensmp.fr) Received: from [127.0.0.1] (localhost. [127.0.0.1]) by joe.j-chkmail.org (sendmail X.1.0.PreAlpha1.0) with ESMTP id S000000000000025901; Wed, 25 Jan 2006 21:49:34 +0100 Message-ID: <43D7E45E.8070103@ensmp.fr> Date: Wed, 25 Jan 2006 21:49:34 +0100 From: Jose Marcio Martins da Cruz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050920 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <43D74F91.2090009@ensmp.fr> <43D7C786.1090803@elischer.org> In-Reply-To: <43D7C786.1090803@elischer.org> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000106080202010109080209" Subject: Re: Changes from 5.2.1 to 5.3 (theads / signal handling) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Jose-Marcio.Martins@ensmp.fr List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2006 21:21:08 -0000 This is a cryptographically signed message in MIME format. --------------ms000106080202010109080209 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Julian Elischer wrote: > Jose Marcio Martins da Cruz wrote: >=20 > a new threading library. Hmmmm. Here are my compile flags : CPPFLAGS : only some -I and -D flags CFLAGS : -D_THREAD_SAFE -pthread LDFLAGS : -lmilter -lkvm -lm -lpthread >=20 > have you tried 6.0? Yes. It presents the same behaviour. Either way, I've found it with 6.0, = and=20 tried back with previous versions till find when the change took place. > also, does the child do an exec() after forking? No. The child gets out the father loop and calls another initialisation f= unction. As It seemed to me that all father's threads are stopped in the forked pr= ocess,=20 this seemed to me not be a problem. Am I right ? The signal handler thread is launched by the following sequence of instru= ctions. sigemptyset(&set); sigaddset(&set, SIGHUP); sigaddset(&set, SIGTERM); sigaddset(&set, SIGINT); sigaddset(&set, SIGUSR1); sigaddset(&set, SIGUSR2); if ((r =3D pthread_sigmask(SIG_BLOCK, &set, NULL)) !=3D 0) { errno =3D r; LOG_SYS_ERROR("Couldn't mask signals"); } if ((r =3D pthread_create(&tid, NULL, filter_signal_handler, NULL)) !=3D= 0) LOG_SYS_ERROR("Error launching filter_signal_handler"); Thanks for your help. Jos=E9-Marcio --------------ms000106080202010109080209 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKKDCC BRAwggL4oAMCAQICAwHW9zANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0wNjAx MjExNDQ4MjBaFw0wNzAxMjExNDQ4MjBaMFMxJDAiBgNVBAMTG0pvc2UtTWFyY2lvIE1hcnRp bnMgZGEgQ3J1ejErMCkGCSqGSIb3DQEJARYcSm9zZS1NYXJjaW8uTWFydGluc0BlbnNtcC5m cjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMyu8K6aUJMX2ZJP69UGRaB/gZ2W FzSXUpLmA+1lNGlc40X8D6N9mTwWX/IpI1Ppcxd9QYOBLm2M2Atc7IjV78MXj75dGYbOT0Dz YUovwoTGhKOYg18VIuxQ4rinGEI8eIqX6gMJ/Ftzox3H/og04AiIZxyMClAjuV5QFN7FRRtI uYGYgLaT+Hq5Q2LXizthF0ewXBfqH1GmJFyErhjkxWQTH4Dq8oFZuRnWA4V2Y30Ss6dn1mjx ySA3AsMaMNQTAZssa6R0BOqAFui3vm58zghLL23Mp5De2bpM83Y2mA8yqMEsF0DWr8Hi40a8 6xCYZHqKtTVxjeXqVRv5OxF8J/sCAwEAAaOBxjCBwzAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG +EIBDQRJFkdUbyBnZXQgeW91ciBvd24gY2VydGlmaWNhdGUgZm9yIEZSRUUgaGVhZCBvdmVy IHRvIGh0dHA6Ly93d3cuQ0FjZXJ0Lm9yZzAyBggrBgEFBQcBAQQmMCQwIgYIKwYBBQUHMAGG Fmh0dHA6Ly9vY3NwLmNhY2VydC5vcmcwJwYDVR0RBCAwHoEcSm9zZS1NYXJjaW8uTWFydGlu c0BlbnNtcC5mcjANBgkqhkiG9w0BAQUFAAOCAgEAh0j3DWg17BIm//AnhNDPDwTbDZUBtI3b CPSXu3QZCvxSgkx980F8MxA2AJ0nW8BOH9siGYd/2KZX1N2juZqgz5H/kq8y5kSFAiMrqxWL Oy8YdaJak+NRATe1JXl0V1VBSVTgi3/QlpcaHgQgHa+GZq5qDnnQvRqYjeajNyLLBXLWBPiL w8rR/JwlMObaGEgaVggyNTtxBTHHf4bc0ErKdwV6y0P55kvvDqorYY5pQ1VZG2NQchfZHScs I4RBNSRx1Dnm8c9sFxR2EJ972HsqTkLunz43NKDHOF15KXv4ePSoRbdMcHTCTEEvPuYMv8rS i1bp0OlRdW1EWxT58MAI1nRGDbaAeAGRRVC6PfMx6QgGeyMQOL8ibK8NpXBIoMvggbxjF497 u1y5SnEfUCJdHDUpW0dzaTbh96tCfywdXxJTKfKivbrju3nnAqiMGMFX1+XJ2F444SD4eL76 Qbyme/vKsqvWsuKBB6+j1c8gyotKuke0HwQEOPc+zZ7YJUgLI/1ghrGdfB9h4qkvKjSyG4an iXZyvod+iFlszEcF5Y6N9jEwN+7zrRNlvQfY0xHgJNmKOP8Y7s8iflr9UTKPAWgKaxcDDFAJ 07zM98jB7jiOpIS3MhFDj/njtNzeCFpgrojM/X490841ME0EYeoDt7ZhhWMsu1/FGk3Ov4mv rNMwggUQMIIC+KADAgECAgMB1vcwDQYJKoZIhvcNAQEFBQAweTEQMA4GA1UEChMHUm9vdCBD QTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNp Z25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcwHhcN MDYwMTIxMTQ0ODIwWhcNMDcwMTIxMTQ0ODIwWjBTMSQwIgYDVQQDExtKb3NlLU1hcmNpbyBN YXJ0aW5zIGRhIENydXoxKzApBgkqhkiG9w0BCQEWHEpvc2UtTWFyY2lvLk1hcnRpbnNAZW5z bXAuZnIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDMrvCumlCTF9mST+vVBkWg f4Gdlhc0l1KS5gPtZTRpXONF/A+jfZk8Fl/yKSNT6XMXfUGDgS5tjNgLXOyI1e/DF4++XRmG zk9A82FKL8KExoSjmINfFSLsUOK4pxhCPHiKl+oDCfxbc6Mdx/6INOAIiGccjApQI7leUBTe xUUbSLmBmIC2k/h6uUNi14s7YRdHsFwX6h9RpiRchK4Y5MVkEx+A6vKBWbkZ1gOFdmN9ErOn Z9Zo8ckgNwLDGjDUEwGbLGukdATqgBbot75ufM4ISy9tzKeQ3tm6TPN2NpgPMqjBLBdA1q/B 4uNGvOsQmGR6irU1cY3l6lUb+TsRfCf7AgMBAAGjgcYwgcMwDAYDVR0TAQH/BAIwADBWBglg hkgBhvhCAQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQg b3ZlciB0byBodHRwOi8vd3d3LkNBY2VydC5vcmcwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUF BzABhhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMCcGA1UdEQQgMB6BHEpvc2UtTWFyY2lvLk1h cnRpbnNAZW5zbXAuZnIwDQYJKoZIhvcNAQEFBQADggIBAIdI9w1oNewSJv/wJ4TQzw8E2w2V AbSN2wj0l7t0GQr8UoJMffNBfDMQNgCdJ1vATh/bIhmHf9imV9Tdo7maoM+R/5KvMuZEhQIj K6sVizsvGHWiWpPjUQE3tSV5dFdVQUlU4It/0JaXGh4EIB2vhmauag550L0amI3mozciywVy 1gT4i8PK0fycJTDm2hhIGlYIMjU7cQUxx3+G3NBKyncFestD+eZL7w6qK2GOaUNVWRtjUHIX 2R0nLCOEQTUkcdQ55vHPbBcUdhCfe9h7Kk5C7p8+NzSgxzhdeSl7+Hj0qEW3THB0wkxBLz7m DL/K0otW6dDpUXVtRFsU+fDACNZ0Rg22gHgBkUVQuj3zMekIBnsjEDi/ImyvDaVwSKDL4IG8 YxePe7tcuUpxH1AiXRw1KVtHc2k24ferQn8sHV8SUynyor2647t55wKojBjBV9flydheOOEg +Hi++kG8pnv7yrKr1rLigQevo9XPIMqLSrpHtB8EBDj3Ps2e2CVICyP9YIaxnXwfYeKpLyo0 shuGp4l2cr6HfohZbMxHBeWOjfYxMDfu860TZb0H2NMR4CTZijj/GO7PIn5a/VEyjwFoCmsX AwxQCdO8zPfIwe44jqSEtzIRQ4/547Tc3ghaYK6IzP1+PdPONTBNBGHqA7e2YYVjLLtfxRpN zr+Jr6zTMYIDhzCCA4MCAQEwgYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0 cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5 MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwHW9zAJBgUrDgMCGgUAoIIB 2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNjAxMjUyMDQ5 MzRaMCMGCSqGSIb3DQEJBDEWBBRJvZBHFQkGO394w33cG6/F/e70pjBSBgkqhkiG9w0BCQ8x RTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMC BzANBggqhkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGDMIGAMHkxEDAOBgNVBAoTB1Jvb3Qg Q0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBT aWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMB 1vcwgZMGCyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsT FWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhv cml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMB1vcwDQYJKoZIhvcN AQEBBQAEggEABhFBxuuVre5+6JGAr7QDjtS4hPwwlAGMGNmWsctTlTrYp1vuVTEy7fZxgv/R GadcgF4vTldgxEJ5Ad0Wic14zV68EykYPtEzgPR7jkiOjPaQcp5TUmzJfjReTKk5vto9EJxG OGcaqChqjm5HSqjQgnGoKZSUR8hqATmpxxA9+3nszkyrVqyVwx858enId6vfIAaCAB4jJh5u wzDDFvny9CeKsCfLH0Vlvu34GHaEzCKSdFDNVzcMCn8HFajkaAxcyKv/someMekZxdR7d8YM aUirg6mhv/1wp0cfCt2yXrmSAdd8UtvukqtWqnmZhvdrbDhCL9iniPykq8w5CvoNcQAAAAAA AA== --------------ms000106080202010109080209-- From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 25 21:05:39 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0E8E916A677 for ; Wed, 25 Jan 2006 21:05:26 +0000 (GMT) (envelope-from surerlistmail@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id A719B44C77 for ; Wed, 25 Jan 2006 20:39:45 +0000 (GMT) (envelope-from surerlistmail@gmail.com) Received: by zproxy.gmail.com with SMTP id 9so202594nzo for ; Wed, 25 Jan 2006 12:39:45 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=HATwb/RC+lLgcwmLsMJkc0DGw6T2ZIV59GX+olg7Knpa6S5kTwMEcCr3cPlnKRER+djNhL/Sauw2NWLWoXf9vVybIPQvireXkFfLlML5bH4h7ksvlfcNjgRVZu9Xkra/mm4zKkqxM7dMBSbd++G+VvDK4TfDNd2QIpMGmVBqzdI= Received: by 10.36.48.1 with SMTP id v1mr848762nzv; Wed, 25 Jan 2006 12:39:44 -0800 (PST) Received: by 10.36.41.11 with HTTP; Wed, 25 Jan 2006 12:39:44 -0800 (PST) Message-ID: Date: Wed, 25 Jan 2006 15:39:44 -0500 From: Surer Dink To: Bruno Ducrot In-Reply-To: <20060125134441.GA11603@poupinou.org> MIME-Version: 1.0 References: <20060125134441.GA11603@poupinou.org> X-Mailman-Approved-At: Wed, 25 Jan 2006 22:14:59 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org Subject: Re: CPU/case/disk temperature sensors for Dell PowerEdge 2850 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2006 21:05:41 -0000 On 1/25/06, Bruno Ducrot wrote: > > On Tue, Jan 24, 2006 at 06:48:37PM -0500, Surer Dink wrote: > > I have tried every means I could find to read the temperature sensors > (CPU, > > case, disk) on Dell PowerEdge 2850 machines, and none seem to work. Ha= s > > anyone had success in doing this? If such support does not exist, what > > would be required to add it? If needed, I am willing to finance (withi= n > > reason) development of this feature. [I was told that Linux and Window= s > > software to read this information is available, so I assume this is > > possible.] > > First, install sysutils/freeipmi, then try it by this command: > # bmc-info > > If it don't work, or loop forever, please install > dmidecode (sysutils/dmidecode) then give us the output from > it for the type entry 38 (IPMI Device Information). bmc-info hangs, output of dmidecode for type 38 is: Handle 0x2600 DMI type 38, 18 bytes. IPMI Device Information Interface Type: KCS (Keyboard Control Style) Specification Version: 1.5 I2C Slave Address: 0x10 NV Storage Device: Not Present Base Address: 0x0000000000000CA8 (I/O) Register Spacing: 32-bit Boundaries Incidentally, I attempted the same on other servers (Dell 2550 and some Supermicros) and they do not contain a "type 38" at all... From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 25 21:39:17 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1983A16A428 for ; Wed, 25 Jan 2006 21:39:17 +0000 (GMT) (envelope-from LoN_Kamikaze@gmx.de) Received: from mail.gmx.net (mail.gmx.de [213.165.64.21]) by mx1.FreeBSD.org (Postfix) with SMTP id 38C1C43D9D for ; Wed, 25 Jan 2006 21:38:44 +0000 (GMT) (envelope-from LoN_Kamikaze@gmx.de) Received: (qmail invoked by alias); 25 Jan 2006 21:38:43 -0000 Received: from p54A7FB8D.dip.t-dialin.net (EHLO [192.168.0.12]) [84.167.251.141] by mail.gmx.net (mp025) with SMTP; 25 Jan 2006 22:38:43 +0100 X-Authenticated: #5465401 Message-ID: <43D7EFBE.2080600@gmx.de> Date: Wed, 25 Jan 2006 22:38:06 +0100 From: "[LoN]Kamikaze" Organization: Lords of Nightmare User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051219) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-hackers@freebsd.org X-Enigmail-Version: 0.93.0.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig3497ACEAB2C4C9EF8AF73D5A" X-Y-GMX-Trusted: 0 X-Mailman-Approved-At: Wed, 25 Jan 2006 22:15:21 +0000 Subject: mount_smbfs with cygwin like symlink support X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2006 21:39:17 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3497ACEAB2C4C9EF8AF73D5A Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit It would be nice to have pretend symlink support for the mount_smbfs, like implemented in cygwin. I'd like to build my ports on a samba share and most require symlinking. I had a look into the code under /usr/src/contrib/smbfs/mount_smbfs, but it's (from my point of view, which is 50% commenting and 50% sourcecode) not commented at all. So I've got no clue where in the code I'd have to get started. --------------enig3497ACEAB2C4C9EF8AF73D5A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFD1+/DfMDIb41/+S0RAtwUAJ953V1B4rU92fhnrKWlc3LIwoM4BgCcDxN8 wLEsgm1pssEV1uVfjmhVFp0= =x10W -----END PGP SIGNATURE----- --------------enig3497ACEAB2C4C9EF8AF73D5A-- From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 25 22:59:43 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CA7FC16A420; Wed, 25 Jan 2006 22:59:43 +0000 (GMT) (envelope-from julian@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id 879B443D45; Wed, 25 Jan 2006 22:59:43 +0000 (GMT) (envelope-from julian@elischer.org) Received: from unknown (HELO [10.251.17.229]) ([10.251.17.229]) by a50.ironport.com with ESMTP; 25 Jan 2006 14:59:42 -0800 Message-ID: <43D802DF.9040003@elischer.org> Date: Wed, 25 Jan 2006 14:59:43 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.11) Gecko/20050727 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jose-Marcio.Martins@ensmp.fr References: <43D74F91.2090009@ensmp.fr> <43D7C786.1090803@elischer.org> <43D7E45E.8070103@ensmp.fr> In-Reply-To: <43D7E45E.8070103@ensmp.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-hackers@freebsd.org, freebsd-threads@freebsd.org Subject: Re: Changes from 5.2.1 to 5.3 (theads / signal handling) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2006 22:59:44 -0000 Jose Marcio Martins da Cruz wrote: > Julian Elischer wrote: > >> Jose Marcio Martins da Cruz wrote: > > >> >> a new threading library. > > > Hmmmm. > > Here are my compile flags : > > CPPFLAGS : only some -I and -D flags > CFLAGS : -D_THREAD_SAFE -pthread > LDFLAGS : -lmilter -lkvm -lm -lpthread > >> >> have you tried 6.0? > > Yes. It presents the same behaviour. Either way, I've found it with > 6.0, and tried back with previous versions till find when the change > took place. > >> also, does the child do an exec() after forking? > > > No. The child gets out the father loop and calls another > initialisation function. The Posix spec says that after a fork(0 teh child must do almost nothing before calling exec() and that AT A MAXIMUM it should only call async-safe functions. (i.e. functions that can be called from within signal handlers). There is all sorts of state being kept for the "now non existant" threads in that address space. For example, some of them will still exist if they were stopped in user space at the time, but some of them will not (if tehy were in the kenrel at teh time). In addition, the process will now be marked "non threaded" in the kernel, as it now only has one kernel thread (as specified by posix) so an attempt to schedule another thread from user space will lead to unknown behaviour. The child will most likely run for a bit and then freeze up or die in some mysterious way. ( sound familiar?). > > As It seemed to me that all father's threads are stopped in the forked > process, this seemed to me not be a problem. Am I right ? no. Nothing has told the user half of the threading system about this. > > The signal handler thread is launched by the following sequence of > instructions. > > sigemptyset(&set); > > sigaddset(&set, SIGHUP); > sigaddset(&set, SIGTERM); > sigaddset(&set, SIGINT); > sigaddset(&set, SIGUSR1); > sigaddset(&set, SIGUSR2); > > if ((r = pthread_sigmask(SIG_BLOCK, &set, NULL)) != 0) > { > errno = r; > LOG_SYS_ERROR("Couldn't mask signals"); > } > > if ((r = pthread_create(&tid, NULL, filter_signal_handler, NULL)) != 0) > LOG_SYS_ERROR("Error launching filter_signal_handler"); > > Thanks for your help. > > José-Marcio > > From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 25 23:13:42 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C83B416A420; Wed, 25 Jan 2006 23:13:42 +0000 (GMT) (envelope-from julian@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8351C43D46; Wed, 25 Jan 2006 23:13:42 +0000 (GMT) (envelope-from julian@elischer.org) Received: from unknown (HELO [10.251.17.229]) ([10.251.17.229]) by a50.ironport.com with ESMTP; 25 Jan 2006 15:13:42 -0800 Message-ID: <43D80626.7030003@elischer.org> Date: Wed, 25 Jan 2006 15:13:42 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.11) Gecko/20050727 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julian Elischer References: <43D74F91.2090009@ensmp.fr> <43D7C786.1090803@elischer.org> <43D7E45E.8070103@ensmp.fr> <43D802DF.9040003@elischer.org> In-Reply-To: <43D802DF.9040003@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-hackers@freebsd.org, Jose-Marcio.Martins@ensmp.fr, freebsd-threads@freebsd.org Subject: Re: Changes from 5.2.1 to 5.3 (theads / signal handling) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2006 23:13:43 -0000 Julian Elischer wrote: > Jose Marcio Martins da Cruz wrote: > >> Julian Elischer wrote: >> >>> Jose Marcio Martins da Cruz wrote: >> >> >> >>> >>> a new threading library. >> >> >> >> Hmmmm. >> >> Here are my compile flags : >> >> CPPFLAGS : only some -I and -D flags >> CFLAGS : -D_THREAD_SAFE -pthread >> LDFLAGS : -lmilter -lkvm -lm -lpthread >> >>> >>> have you tried 6.0? >> >> >> Yes. It presents the same behaviour. Either way, I've found it with >> 6.0, and tried back with previous versions till find when the change >> took place. >> >>> also, does the child do an exec() after forking? >> >> >> >> No. The child gets out the father loop and calls another >> initialisation function. > > > > The Posix spec says that after a fork(0 teh child must do almost > nothing before calling exec() > and that AT A MAXIMUM it should only call async-safe functions. (i.e. > functions that can be called from > within signal handlers). > > There is all sorts of state being kept for the "now non existant" > threads in that address space. > > For example, some of them will still exist if they were stopped in > user space at the time, > but some of them will not (if tehy were in the kenrel at teh time). In > addition, > the process will now be marked "non threaded" in the kernel, as it now > only > has one kernel thread (as specified by posix) so an attempt to > schedule another thread > from user space will lead to unknown behaviour. The child will most > likely > run for a bit and then freeze up or die in some mysterious way. ( > sound familiar?). I might add that you can also try libthr instead of libpthread. They are compatible but use different methods to achieve their results. and thus have different failure modes. However relying on such thing sis not wise. I think the Linux thread people tried very hard to allow people to do as much as possible after the fork, however there are limitations there too. You shouldn't keep running "forever" in this way after a fork. How often does this forking occur? would an exec (argv[0]....., "aschild",); be a practical thing? Does the parent have to have become threaded before forking the children? This is a posix restriction. > > > > > > >> >> As It seemed to me that all father's threads are stopped in the >> forked process, this seemed to me not be a problem. Am I right ? > > > > no. Nothing has told the user half of the threading system about this. > >> >> The signal handler thread is launched by the following sequence of >> instructions. >> >> sigemptyset(&set); >> >> sigaddset(&set, SIGHUP); >> sigaddset(&set, SIGTERM); >> sigaddset(&set, SIGINT); >> sigaddset(&set, SIGUSR1); >> sigaddset(&set, SIGUSR2); >> >> if ((r = pthread_sigmask(SIG_BLOCK, &set, NULL)) != 0) >> { >> errno = r; >> LOG_SYS_ERROR("Couldn't mask signals"); >> } >> >> if ((r = pthread_create(&tid, NULL, filter_signal_handler, NULL)) >> != 0) >> LOG_SYS_ERROR("Error launching filter_signal_handler"); >> >> Thanks for your help. >> >> José-Marcio >> >> > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to > "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 26 00:10:04 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1595816A420 for ; Thu, 26 Jan 2006 00:10:04 +0000 (GMT) (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 48F3343D48 for ; Thu, 26 Jan 2006 00:10:03 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 4A17746B8C; Wed, 25 Jan 2006 19:09:56 -0500 (EST) Date: Thu, 26 Jan 2006 00:11:22 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Pranav Peshwe In-Reply-To: Message-ID: <20060126001021.B89523@fledge.watson.org> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org Subject: Re: KTR not working !! X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2006 00:10:04 -0000 On Wed, 25 Jan 2006, Pranav Peshwe wrote: > Hello, > I recompiled the kernel with KTR (4) support.But i could find the > logged messages nowhere ! When i use 'ktrdump' on the console ,the ouput is > : You might take a glance at: http://www.watson.org/~robert/freebsd/netperf/ktr/ And make sure you didn't miss any steps. In particulare, make sure that you have both compiled in support for the ktrace record types you want, and enabled them at runtime. Robert N M Watson > > index trace > ------ ----- > > When i try to view the logging from DDB by issuing 'show ktr', only a > message saying '--- End of trace buffer ---' is displayed. > > I paste a portion (related to debugging options) of the config file i > used, to recompile the kernel. > > #----- > options KTR > options KTR_ENTRIES=8192 > options KTR_VERBOSE > > options INVARIANTS > options INVARIANT_SUPPORT > options WITNESS > options WITNESS_KDB > > options KDB > options KDB_TRACE > options DDB > options GDB > options BREAK_TO_DEBUGGER > #----- > > Am i missing something very important ? How can i view the > information logged by the various CTR[0-5] macros used in the kernel > source ? > > TIA. > > Regards, > Pranav > > --------------------------------------------------------------------------- > Heisenberg is out for a drive when he's stopped by a traffic cop. > The cop says: "Do you know how fast you were going?" > Heisenberg replies: "No,but I know where I am" > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 26 00:17:09 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2A49F16A422 for ; Thu, 26 Jan 2006 00:17:09 +0000 (GMT) (envelope-from craig@tobuj.gank.org) Received: from ion.gank.org (ion.gank.org [69.55.238.164]) by mx1.FreeBSD.org (Postfix) with ESMTP id E541E43D53 for ; Thu, 26 Jan 2006 00:17:08 +0000 (GMT) (envelope-from craig@tobuj.gank.org) Received: by ion.gank.org (mail, from userid 1001) id 2EB222AB1B; Wed, 25 Jan 2006 18:17:08 -0600 (CST) Date: Wed, 25 Jan 2006 18:17:06 -0600 From: Craig Boston To: Scott Long Message-ID: <20060126001705.GA34411@nowhere> Mail-Followup-To: Craig Boston , Scott Long , freebsd-hackers@freebsd.org References: <20060120014307.GA3118@nowhere> <200601241043.51094.jhb@freebsd.org> <20060125003405.GA29970@nowhere> <200601250916.59336.jhb@freebsd.org> <43D79367.6020304@samsco.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43D79367.6020304@samsco.org> User-Agent: Mutt/1.4.2.1i Cc: freebsd-hackers@freebsd.org Subject: Re: Weird PCI interrupt delivery problem (resolution, sort of) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2006 00:17:09 -0000 On Wed, Jan 25, 2006 at 08:04:07AM -0700, Scott Long wrote: > Either that, or the read imposes enough delay to let whatever was > happening during the DELAY call work. I find it hard to believe that > uncached writes would get delayed like this. I've lost the original > posting on this, could you provide the dmesg and computer make/model > again? It's a Toshiba Satellite L25-S1192. The chipset is ATI Radeon Xpress 200M (RS480). Verbose dmesgs are up at http://www.gank.org/freebsd/l25 acpi+apic.txt is a 6.0-RELEASE GENERIC kernel (before I upgraded the memory, but the APIC thing is independent of that) apic2.txt is a verbose dmesg with my current kernel (stock 6.0-STABLE + read-after-write change to local_apic.c). Craig From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 26 04:09:43 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2446516A420 for ; Thu, 26 Jan 2006 04:09:43 +0000 (GMT) (envelope-from pranavpeshwe@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6940C43D5C for ; Thu, 26 Jan 2006 04:09:39 +0000 (GMT) (envelope-from pranavpeshwe@gmail.com) Received: by wproxy.gmail.com with SMTP id i31so248782wra for ; Wed, 25 Jan 2006 20:09:38 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ILqgHnx8l2nMvIxlfN6hZqklVSv4/ebkjKeFcWrMHIgHKYLR+kRaBTez5WVBb0qxh6nydus51oxizfNPvxrVtphuv5Yj/0gqyYU4qFJScH9fSECA05Uj/sMC595kp3rDST6qg4ZCv1aIki0Yu0Bd6Tkvqjgp1LOS3BU3snJ7fN8= Received: by 10.54.80.5 with SMTP id d5mr1517542wrb; Wed, 25 Jan 2006 20:09:38 -0800 (PST) Received: by 10.54.99.13 with HTTP; Wed, 25 Jan 2006 20:09:38 -0800 (PST) Message-ID: Date: Thu, 26 Jan 2006 09:39:38 +0530 From: Pranav Peshwe To: John Baldwin In-Reply-To: <200601250952.41784.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <84dead720601250045h33447be0y21d6c2239749bd15@mail.gmail.com> <200601250952.41784.jhb@freebsd.org> Cc: freebsd-hackers@freebsd.org Subject: Re: KTR not working !! X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2006 04:09:43 -0000 On 1/25/06, John Baldwin wrote: > You only have KTR_GEN traces compiled in. Try adding 'KTR_COMPILE=3DKTR_= ALL' > If you run with all traces enabled your system is going to get really rea= lly > slow though. > Thank you !! It works now. I turned on 'verbose' and got a flurry of messages rushing across the screen.But, ktrdump has not shown more than 7 messages.Does ktrdump just 'tail' all those messages ? or, is there any separate mask/environment variable for ktrdump ? TIA. Regards, Pranav ------------------------------------------------------------------------- No matter how much cats fight, there always seem to be plenty of kittens. ---Abraham Lincoln From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 26 08:55:07 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EE43A16A420; Thu, 26 Jan 2006 08:55:07 +0000 (GMT) (envelope-from Jose-Marcio.Martins@ensmp.fr) Received: from saci.ensmp.fr (saci.ensmp.fr [194.214.158.176]) by mx1.FreeBSD.org (Postfix) with ESMTP id 87DBD43D45; Thu, 26 Jan 2006 08:55:07 +0000 (GMT) (envelope-from Jose-Marcio.Martins@ensmp.fr) Received: from [127.0.0.1] (localhost.ensmp.fr. [127.0.0.1]) by saci.ensmp.fr (sendmail X.1.0.PreAlpha0.0) with ESMTP id S00000000000002D100; Thu, 26 Jan 2006 09:55:05 +0100 Message-ID: <43D88E69.1020102@ensmp.fr> Date: Thu, 26 Jan 2006 09:55:05 +0100 From: Jose Marcio Martins da Cruz User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20041221 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julian Elischer References: <43D74F91.2090009@ensmp.fr> <43D7C786.1090803@elischer.org> <43D7E45E.8070103@ensmp.fr> <43D802DF.9040003@elischer.org> In-Reply-To: <43D802DF.9040003@elischer.org> X-Enigmail-Version: 0.90.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, freebsd-threads@freebsd.org Subject: Re: Changes from 5.2.1 to 5.3 (theads / signal handling) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2006 08:55:08 -0000 Hello, Julian Elischer wrote: > Jose Marcio Martins da Cruz wrote: >>> also, does the child do an exec() after forking? >> >> No. The child gets out the father loop and calls another >> initialisation function. > > The Posix spec says that after a fork(0 teh child must do almost nothing > before calling exec() > and that AT A MAXIMUM it should only call async-safe functions. (i.e. > functions that can be called from > within signal handlers). So, if I understood, the better I can do is, instead of letting the child follow a different path after the fork, he shall better do an exec of another thing and start a clean process... > > There is all sorts of state being kept for the "now non existant" > threads in that address space. > > For example, some of them will still exist if they were stopped in user > space at the time, > but some of them will not (if tehy were in the kenrel at teh time). In > addition, > the process will now be marked "non threaded" in the kernel, as it now only > has one kernel thread (as specified by posix) so an attempt to schedule > another thread > from user space will lead to unknown behaviour. The child will most likely > run for a bit and then freeze up or die in some mysterious way. ( sound > familiar?). Very clear... Even on releases older than 5.3... 8-( You clarified a bug which was "harassing" me for a very long time... Can you point me a good doc about threads, signals, and such kind of things in FreeBSD context ? Thanks very much for all your very helpful hints. Jose-Marcio From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 26 10:54:09 2006 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DC49816A420 for ; Thu, 26 Jan 2006 10:54:08 +0000 (GMT) (envelope-from vit.ska@gmail.com) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.197]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6CC0643D48 for ; Thu, 26 Jan 2006 10:54:08 +0000 (GMT) (envelope-from vit.ska@gmail.com) Received: by xproxy.gmail.com with SMTP id s9so201635wxc for ; Thu, 26 Jan 2006 02:54:07 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=ry1e8GBzkQs3RJGd8ouGpjuYnRtnLocZJW2psWFa9i8NcHF4/08q0DsADEuG7zWapkT7R3V3ueiUgaDUXeilj4/G3hWNFy/3ZEzepBPrg9OG0PzMAXBI6e99ZvMBM2KRCOdNeUyi6gnZUoeMcKVBXSZs4GX5cHAKZ5mHWt3tDGE= Received: by 10.70.61.8 with SMTP id j8mr2084064wxa; Thu, 26 Jan 2006 02:54:07 -0800 (PST) Received: by 10.70.118.3 with HTTP; Thu, 26 Jan 2006 02:54:07 -0800 (PST) Message-ID: <806128ad0601260254u42dfd927k@mail.gmail.com> Date: Thu, 26 Jan 2006 12:54:07 +0200 From: Vitaliy Skakun To: hackers@freebsd.org In-Reply-To: <200601250956.35818.jhb@freebsd.org> MIME-Version: 1.0 References: <806128ad0601250608u67aae744u@mail.gmail.com> <200601250956.35818.jhb@freebsd.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: Comtrol Rocketport UNIVERSAL PCI 32-port X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2006 10:54:09 -0000 SGkgZXZlcnlib2R5IQoKT25lIHByb2JsZW0gYXJpc2VkOgoKd2hlbiBkb2luZyBpbiB0aGUgc2hl bGwKZWNobyAifldTIiA+IC9kZXYvY3VhUjAwCgpmb3Igc2V2ZXJhbCB0aW1lcyBhcyBxdWljayBh cyBJIGNhbiwgSSBnZXQgcGFuaWMgd2l0aCB0aGUgZm9sbG93aW5nIG1lc3NhZ2U6CnBhbmljOiBk ZXZpY2VfdW5idXN5OiBjYWxsZWQgZm9yIG5vbi1idXN5IGRldmljZSBycDAKCnNhbWUgdGhpbmcg d2hlbiB0cnlpbmcgdG8gc2VuZCBkYXRhIHRvIC9kZXYvY3VhUjAwIHZpYSBKREsgRmlsZSBzdHJl YW1zIC4uLgo6KCgoCgooU29tZSBraW5kIG9mIGJhcmNvZGUgcHJpbnRlcnMgYXJlIGF0dGFjaGVk IHRvIHRoaXMgbXVsdGlwb3J0IGNhcmQpCgpBbnkgaGVscCB3aWxsIGJlIGtpbmRseSBhY2NlcHRl ZC4KCkNoZWVycwpWaXQKCjIwMDYvMS8yNSwgSm9obiBCYWxkd2luIDxqaGJAZnJlZWJzZC5vcmc+ Ogo+Cj4gSSd2ZSBjb21taXR0ZWQgaXQgdG8gSEVBRCBhbmQgd2lsbCBNRkMgaW4gYSBmZXcgZGF5 cyBzbyBpdCB3aWxsIGJlIGluIDYuMS4KPgo+IC0tCj4gSm9obiBCYWxkd2luIDxqaGJARnJlZUJT RC5vcmc+ICA8PjwgIGh0dHA6Ly93d3cuRnJlZUJTRC5vcmcvfmpoYi8KPiAiUG93ZXIgVXNlcnMg VXNlIHRoZSBQb3dlciB0byBTZXJ2ZSIgID0gIGh0dHA6Ly93d3cuRnJlZUJTRC5vcmcKPgo= From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 26 12:37:31 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 09FC116A420; Thu, 26 Jan 2006 12:37:31 +0000 (GMT) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.177]) by mx1.FreeBSD.org (Postfix) with ESMTP id D3DA443D53; Thu, 26 Jan 2006 12:37:26 +0000 (GMT) (envelope-from max@love2party.net) Received: from [84.163.212.17] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu8) with ESMTP (Nemesis), id 0ML2ov-1F26NL2eW9-0000fk; Thu, 26 Jan 2006 13:37:22 +0100 From: Max Laier Organization: FreeBSD To: freebsd-hackers@freebsd.org Date: Thu, 26 Jan 2006 13:37:49 +0100 User-Agent: KMail/1.9.1 MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_fKM2DGHbXhH9kQO" Message-Id: <200601261337.51906.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:61c499deaeeba3ba5be80f48ecc83056 Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: FreeBSD Status Report Fourth Quarter 2005 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2006 12:37:31 -0000 --Boundary-00=_fKM2DGHbXhH9kQO Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline --Boundary-00=_fKM2DGHbXhH9kQO Content-Type: text/plain; charset="us-ascii"; name="report-oct-2005-dec-2005.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline; filename="report-oct-2005-dec-2005.txt" October-December 2005 Status Report Introduction This report is about the rather quite last quarter of 2005, with the release of FreeBSD 6.0 and the holiday season things evolved in the background. Nontheless, most exciting projects hit the tree (or are going to very soon). Upcoming events, such as the release of FreeBSD 6.1/5.5 and the third BSDCan conference with a big developer summit promise to provide a busier start in 2006. The foundation for upcoming development, however, are the projects that are described herein. We hope that you find interesting projects to look at or work on. The next status report collection will be April 7 2006. We are looking forward to your report then. Thanks again to everyone who submitted reports, and thanks to Brad Davis who stepped up for an extensive spelling and grammar review. Enjoy reading! _________________________________________________________________ Projects * FreeSBIE * jemalloc * variant symlinks Documentation * FreeBSD list of projects and ideas for volunteers (TODO list for volunteers) * Problem Report Database * The FreeBSD Dutch Documentation Project =46reeBSD team reports * FreeBSD Security Officer and Security Team * Ports Collection * Release Engineering Status Report Kernel * Bt878 Audio Driver (aka FusionHDTV 5 Lite) * E1000 driver improvements * LSI MegaRAID improvements * Sound subsystem improvements Network infrastructure * Early Binding Updates and Credit-Based Authorization for the Kame-Shisa Mobile IPv6 Software * FAST_IPSEC Upgrade * KAME Project Status Report * New Networking Features in FreeBSD 6.0 * Optimizing the FreeBSD IP and TCP Stack Userland programs * OpenBSD dhclient Architectures * FreeBSD on Xen 3.0 * FreeBSD/xbox Ports * FreshPorts Vendor / 3rd Party Software * SysKonnect/Marvell Yukon device driver Miscellaneous * A Comprehensive Delay Analysis for Reactive and Proactive Handoffs with Mobile IPv6 Route Optimization * BSDCan 2006 * TCP/IP Optimization Fundraiser Status _________________________________________________________________ A Comprehensive Delay Analysis for Reactive and Proactive Handoffs with Mobile IPv6 Route Optimization URL: http://doc.tm.uka.de/2006/vogt-2006-delay-analysis-for-reactive-and-pr oactive-handoffs.pdf Contact: Christian Vogt Optimizations to reduce handoff delays inherent in Mobile IPv6 Route Optimization as well as IPv6 router discovery, address configuration, and movement detection have so far been mostly considered on an individual basis. This document evaluates three integrated solutions for improved handoff experience in surroundings with different preconditions: reactive handoffs with unmodified routers, reactive handoffs with router support, and movement anticipation and proactive handoff management. _________________________________________________________________ BSDCan 2006 URL: http://www.bsdcan.org/ Contact: Dan Langille We are well into the process of selecting the talks for BSDCan 2006. Our new program committee has a hard selection task over the new few weeks. The deadline for the Call For Papers has passed, but it's not too late to submit a talk. Please see the above URL for details. After the success of the Work in Progress last year , we are going to do it again this year. If you are working on something you'd like to tell the world about, considering giving a 5 minute talk at BSDCan. The registration prices for BSDCan 2006 will be the same as they were for 2005 . We will be again in the SITE building at University of Ottawa and you'll have lots of opportunity to meet with people from all over the world. Be sure to make your travel plans now and don't miss out on the biggest BSD event this year: BSDCan 2006. Open tasks: 1. We're looking for volunteers to help out just before and during the conference. Contact Dan at the above address. 2. If you have a talk you'd like to present, contact Dan at the above address. _________________________________________________________________ Bt878 Audio Driver (aka FusionHDTV 5 Lite) URL: http://perforce.freebsd.org/fileSearch.cgi?FSPC=3D%2F%2Fdepot%2Fuser%2Fj mg%2Fbktrau%2F...&ignore=3DGO%21 Contact: John-Mark Gurney Basic audio capture is working. All of the parameters are set by userland, while the RISC program generation is by kernel. No real audio has been captured as there are no drivers for the tuner yet. Someone with a real Bt878 NTSC card that is supported by bktr(4) could use this to capture audio w/o using the sound card. The real goal of this driver is to make HD capture possible with the DViCO FusionHDTV5 Lite card that I have. I have some of the documentation that I need, but I'm still missing two key docs. The docs for the LGDT3303 ATSC/8VSB/QAM demodulator chip and a block diagram of the board showing which GPIO lines go where and how the chips are interconnected. DViCO has been responsive in acknowledging my emails, but they have yet to produced any data besides pointing me to the Linux driver (which is difficult to figure out stuff by). Open tasks: 1. Complete basic capture driver. 2. Make the bktr(4) drive cleanly attach to the card, and possibly add support for analog capture. _________________________________________________________________ E1000 driver improvements Contact: Scott Long Contact: Andre Opperman In an effort to solve the 'interrupt aliasing' problem that plagues many motherboards under FreeBSD, I modified the Intel e1000 network driver (if_em) to use a combination of fast interrupts and taskqueues. This technique avoids interrupt threads entirely, which in turn avoids triggering the aliasing problem in the Intel APIC. The result is that the driver now handles and masks interrupts immediately, and a private taskqueue is then scheduled to run to process the link events and rx/tx events. A side effect of this asynchronous processing is that it acts much as traditional polling does, in that the amount of work done in the taskqueue can be controlled, and the taskqueue rescheduled to process work at a later time. This leads to the driver having the low-latency benefits of interrupts and the workload segmentation of polling, all without complicated heuristics. Several users have reported that the driver can handle higher loads than traditional polling without deadlocks. Along with this work, I modified the SMPng locking in the driver so that no lock is required for the RX path. Since this path is already implicitly serialized by the interrupt and/or taskqueue and/or polling handler (all of which are exclusive to each other), there was no need for extra synchronization. This has two benefits. The first is reduction in processing overhead to unlock and lock the driver for every RX packet, and significant reduction in contention of the driver lock when transmitting and receiving packets at the same time. I believe that it is further possible to run the TX-complete path without a lock, further reducing overhead and contention for high transmit loads. The reduced contention also greatly benefitted the fast-forward bridging code in FreeBSD, with up to 25% performance improvement seen, as well as lower CPU utilization. The work can be found in FreeBSD 7-CURRENT for now. There are still some rough edges relating to falling back to traditional ithread and polling behavior, and I do not intend to merge the changes back to FreeBSD 6.x until these are resolved. I also hope to extend the INTR_FAST+taskqueue model into a general framework for doing Mac OSX style filter interrupts. The work in the if_em driver can also be extended to other high-performance network drivers such as if_bge and if_ti. Any help with investigating these topics is welcomed. _________________________________________________________________ Early Binding Updates and Credit-Based Authorization for the Kame-Shisa Mobile IPv6 Software URL: http://www.tm.uka.de/~chvogt/ebucba/ URL: http://doc.tm.uka.de/2005/draft-vogt-mobopts-early-binding-updates-00. txt URL: http://doc.tm.uka.de/2005/draft-vogt-mobopts-credit-based-authorizatio n-00.txt Contact: Christian Vogt Based on the Kame-Shisa Mobile IPv6 Software for FreeBSD 5.4, we implemented the performance optimization "Early Binding Updates" and "Credit-Based Authorization". The combined optimizations facilitate significant reductions in handoff delay without compromising protocol security [1][2]. _________________________________________________________________ =46AST_IPSEC Upgrade Contact: George Neville-Neil Contact: Bjoern A. Zeeb Currently splitting out the rest of the PF_KEY data-structures from the key database. This will mean the user level applications and the kernel will not share datastructures and that they can, hopefully, advance on their own without being in lockstep. Open tasks: 1. Calculate diffs between Kame IPv4 version of IPSec and FAST_IPSEC and upgrade FAST to the latest standards. 2. Add IPv6 support to FAST_IPSEC. _________________________________________________________________ =46reeBSD list of projects and ideas for volunteers (TODO list for voluntee= rs) URL: http://www.FreeBSD.org/projects/ideas/ Contact: Joel Dahl Contact: Alexander Leidinger The "TODO list for volunteers" is now committed as the "FreeBSD list of projects and ideas for volunteers". So far the interest in the list is high and some volunteers already took the opportunity to start tackling some of the entries. Unfortunately the FreeBSD project does not have enough human resources to provide a technical contact for every entry. Interested volunteers should not be afraid to try to come up with a solution for an entry without a technical contact. The people on the hackers and current mailing list are typically very helpful regarding answering specific questions (as long as they know the answer...). We are looking forward to hear about new ideas, people willing to be technical contacts for generic topics (e.g. USB) or specific entries (already existing or newly created), suggestions for existing entries or completion reports for (parts of) an entry. Open tasks: 1. Add more ideas. 2. Find more technical contacts. _________________________________________________________________ =46reeBSD on Xen 3.0 URL: http://www.fsmware.com/xenofreebsd/7.0/STATUS Contact: Kip Macy Full domU support in p4 branch of -CURRENT, except suspend / restore. Dom0 work is in progress. Scott Long is working on xenbus integration with newbus. After newbus integration it will go into CVS. I hope to see it MFCed to RELENG_6 so it will be available for 6.1. Open tasks: 1. Port the backend drivers from Linux. 2. Port the domain management tools from Linux. 3. Add multiboot support to loader(8) to support it booting xen. 4. SMP, x86_64, and PAE support. _________________________________________________________________ =46reeBSD Security Officer and Security Team URL: http://www.freebsd.org/security/ URL: http://www.freebsd.org/doc/en_US.ISO8859-1/articles/contributors/staff -listing.html#STAFF-SECTEAM URL: http://vuxml.freebsd.org/ Contact: Security Officer Contact: Security Team This report covers the period July 2005 - January 2006, since the FreeBSD Security Team did not submit a status report for July - October 2005. In August 2005, the long-time Security Officer, Jacques Vidrine, stepped down and was replaced by Colin Percival. Jacques remains with the team as Security Officer Emeritus, and the team thanks him for all his work over the past four years. Also in August 2005, Dag-Erling C. Sm=F8rgrav was replaced by Simon L. Nielsen as Deputy Security Officer. In addition, Tom Rhodes and Guido van Rooij retired from the team in September 2005 and January 2006 respectively in order to devote their time to other parts of the FreeBSD project. The current Security Team membership is published on the web site. In the time since the last status report, ten security advisories have been issued (five in 2005, five in 2006) concerning problems in the base system of FreeBSD; of these, four problems were in "contributed" code, while six were in code maintained within FreeBSD. The Vulnerabilities and Exposures Markup Language (VuXML) document has continued to be updated by the Security Team and the Ports Committers documenting new vulnerabilities in the FreeBSD Ports Collection; since the last status report, 117 new entries have been added, bringing the total up to 636. The following FreeBSD releases are supported by the FreeBSD Security Team: FreeBSD 4.10, FreeBSD 4.11, FreeBSD 5.3, FreeBSD 5.4, and FreeBSD 6.0. Their respective End of Life dates are listed on the web site. _________________________________________________________________ =46reeBSD/xbox URL: http://xbox-bsd.nl Contact: Rink Springer FreeBSD/xbox support is nearing completion. Patches are available for nve(4) ethernet support, as well as a syscons(4)-capable console. I am working to integrate these in CURRENT, a backport to 6.x is planned too. Work is under way to support X.Org as well; people with more detailed knowledge of X.Org are welcome to assist. Open tasks: 1. Enable framebuffer support in X.Org 2. Figure out a way to use mfsroots without using loader(8) _________________________________________________________________ =46reeSBIE URL: http://www.freesbie.org URL: http://torrent.freesbie.org URL: freesbie@gufi.org Contact: FreeSBIE staff Development is going on after the complete rewrite of the toolkit. There are many plugins available and we're testing a new implementation of unionfs for 6.x. Since it's a bit unstable, it won't be included in the release anyway. Developers hope to enter the BETA state on February 1st, to release an -RC image around February 15th and the RELEASE around March 1st. We need more people to test the images we provide. Torrents for them are available at torrent.freesbie.org . Open tasks: 1. A new BETA Release, based on 6-STABLE, is available for testing. _________________________________________________________________ =46reshPorts URL: http://www.freshports.org/ Contact: Dan Langille FreshPorts recently moved to a new webserver. This should speed things up considerably. You can read all about the new hardware on the recently introduced FreshPorts Blog . This blog will include technical discussions about ports and the problems they present with respect to FreshPorts. Site announcements will be posted there. As bugs are found, they will be listed, as well as their fixes. Supporting multiple platforms and architectures is still in the development stage. Lack of time is affecting progress. A fix for virtual ports is in the works. I'm also going to implement more caching to speed things up. If interested in discussing the options there, please get involved in the blog. _________________________________________________________________ jemalloc Contact: Jason Evans libc's malloc implementation has been replaced with an implementation that is designed to scale well for multi-threaded applications running on multi-processor systems. This is accomplished by creating multiple allocation arenas that are independent of each other, and permanently assigning threads to these arenas. In the common case, threads do not access the same allocator arena at the same time, which reduces contention and cache sloshing. Single-threaded application performance is approximately equivalent to what it was with phkmalloc, but for multi-threaded applications that make heavy use of malloc, the performance difference can be huge (orders of magnitude). As with phkmalloc, the new malloc implementation supports runtime configuration via the MALLOC_OPTIONS environment variable. See the malloc(3) manpage for details on supported options, as well as more information about the allocator's architecture. _________________________________________________________________ KAME Project Status Report URL: http://www.kame.net/ URL: http://www.kame.net/newsletter/20051107/ URL: http://www.wide.ad.jp/news/press/20051107-KAME-e.html URL: http://ipv6style.jp/en/special/kame/20051205/index.shtml Contact: SUZUKI Shinsuke Most of the latest KAME code has been merged to 7-current and 6-stable, to prepare for the project conclusion in March 2006. For the same reason, we moved some ports applications (security/racoon, net/pim6sd, net/pim6dd, net/dhcp6) from KAME to sourceforge.net. Some of the items (e.g. IGMPv3/MLDv2, Mobile-IPv6/NEMO, SCTP, DCCP, ISATAP) are not merged yet from the latest KAME code for several reasons. Other projects will continue to merge their work. Open tasks: 1. remove __P() macros 2. set net.inet6.ip6.kame_version to a more appropriate date :-) 3. update src/sys/netinet6/README _________________________________________________________________ LSI MegaRAID improvements Contact: Scott Long Contact: Doug Ambrisko Major work has gone into improving both the performance of the LSI MegaRAID (amr) driver, and in adding Linux compatiblity support. SMGng locking was added in Oct 2005 as well as a number of performance improvements. The result is 138% performance improvement in some local transaction tests. Throughout 2005 a lot of work has gone into adding Linux compatibility to the driver. It is now possible to run many of the LSI-provided management apps for Linux under FreeBSD. Both this feature and the performance improvements are in the 7-CURRENT development branch of FreeBSD and are scheduled to be backported in time for the FreeBSD 6.1 release. _________________________________________________________________ New Networking Features in FreeBSD 6.0 URL: http://people.freebsd.org/New%20Networking%20Features%20in%20FreeBSD%2 06%20-%20Presentation.pdf URL: http://people.freebsd.org/New%20Networking%20Features%20in%20FreeBSD%2 06%20-%20Paper.pdf URL: http://www.eurobsdcon.org Contact: Andre Oppermann FreeBSD 6 has evolved drastically in the development branch since FreeBSD 5.3 and especially so in the network area. The presentation and paper give an in-depth overview of all network stack related enhancements, changes and new code with a narrative on their rationale. _________________________________________________________________ OpenBSD dhclient Contact: Brooks Davis Contact: Sam Leffler The OpenBSD rewrite of dhclient has been imported, replacing the ISC dhclient. The OpenBSD client provides better support for roaming on wireless networks and a simpler model of operation. Instead of a single dhclient process per system, there is one per network interface. This instance automatically goes away in the even of link loss and is restarted via devd when link is reacquired. To support this change, many aspects of the network interface configuration process were overhauled. Support for adding aliases to DHCP configured interfaces has been committed to CURRENT and will be merged before 6.1-RELEASE. Soon work will begin to merge changes from OpenBSD that have taken place since the initial import. Work on further interface configuration enhancements is underway for FreeBSD 7.0. _________________________________________________________________ Optimizing the FreeBSD IP and TCP Stack URL: http://people.freebsd.org/Optimizing%20the%20FreeBSD%20IP%20and%20TCP% 20Stack%20-%20Presentation.pdf URL: http://people.freebsd.org/Optimizing%20the%20FreeBSD%20IP%20and%20TCP% 20Stack%20-%20Paper.pdf URL: http://www.eurobsdcon.org URL: http://people.freebsd.org/~andre/tcpoptimization.html Contact: Andre Oppermann FreeBSD has gained fine grained locking in the network stack throughout the 5.x-RELEASE series cumulating in 6.0-RELEASE. Hardware architecture and performance characteristics have evolved significantly since various BSD networking subsystems have been designed and implemented. This paper gives a detailed look into the implementation and design changes in FreeBSD 7-CURRENT to extract the maximum network performance from the underlying hardware. Sponsored by: TCP/IP Optimization Fundraiser 2005 _________________________________________________________________ Ports Collection URL: http://www.freebsd.org/ports/ URL: http://people.freebsd.org/~fenner/portsurvey/ URL: http://edwin.adsl.barnet.com.au/~edwin/ports/ URL: http://portsmon.FreeBSD.org/index.html URL: http://www.freebsd.org/portmgr/index.html URL: http://tinderbox.marcuscom.com Contact: Mark Linimon During this time, the number of ports PRs briefly dipped below 500 -- a number not seen since late 2000, when there were 4000 ports instead of our new total of over 14,000 ports. This is due to the hard work of a large number of individuals, including pav, edwin, mnag, garga, and many others. Congratulations folks! Some of this was due to more aggressively committing PRs where the maintainer had not responded within the timeout period. Although controversial, this new policy seems to be succeeding in its goal of improving the Ports Collection. A new file, ports/KNOBS, was added by ahze to help bring some order in the chaos that had been the OPTIONS namespace. dougb has changed the way that rc.d works in -HEAD to work more like the base rc.d scripts. We are hoping that this change will make ports maintenance easier in the future. However, in the meantime a few bugs have been introduced (which we intend to have fixed by the time 6.1 is released). While this regression is unfortunate, it was decided that now was the best time to try to make this change rather than waiting for 7.0. We hope our users can be patient with us in the interim. Work continues to improve the marcuscom ports tinderbox, with new features added by marcus, aDe, and edwin in particular. Several ports committers are now running their own copies to test ports changes. The www.FreeBSD.org/ports page, and the portmgr web pages, were reworked as well. We have added 4 new committers since the last report. Open tasks: 1. Progress has been made in cracking down on ports that do not correctly install when LOCALBASE is not /usr/local, but some ports remain. 2. portmgr would like to remind committers that PRs for their ports should be handled (either committed or marked 'suspended' or 'analyzed') within the two week timeout period. In this way other committers do not have to invoke the maintainer timeout and things will work more smoothly. _________________________________________________________________ Problem Report Database URL: http://www.freebsd.org/support.html#gnats Contact: Mark Linimon The experiment to add 'tags' to many of the kern and related PRs, including such things as '[nfs]', '[fxp]', and so forth, continues. In addition, PRs with patches have been more consistently tagged with '[patch]'. Two new periodic reports based on both functional tags and PRs with patches have been added, with the goal of making these PRs more visible. _________________________________________________________________ Release Engineering Status Report URL: http://www.freebsd.org/releng URL: http://www.freebsd.org/releases Contact: RE Team Another very busy year for the FreeBSD Release Engineering Team. Recognizing the problems, both technical and emotional, surrounding the FreeBSD 5.x releases, our primary focus was in getting the bugs out of FreeBSD 6.0 and getting it released. We succeeded at that quite well, and the 6.0 release on Nov 18 was a huge success for the project. Many thanks to all of the developers who put in countless hours fixing bugs and improving performance, and to the users who helped find, fix, and verify bugs. Moving forward to 2006, we plan on doing a joint release of FreeBSD 5.5 and 6.1 in late March. The 5.5 release will mark the end of active FreeBSD 5.x development and releases, and is intended to help users who have not yet switched to FreeBSD 6. It consists primarily of bug fixes and minor improvements. FreeBSD 6.1 will be an upgrade to 6.0 and will include new drivers, better performance in certain areas, as well as bug fixes. We expect to release FreeBSD 6.2 and 6.3 later in 2006. _________________________________________________________________ Sound subsystem improvements URL: http://people.FreeBSD.org/~ariff/ URL: http://www.FreeBSD.org/projects/ideas/ Contact: Ariff Abdullah Contact: Alexander Leidinger Contact: Multimedia Mailinglist A lot of changes have taken place in the sound system since the last status report. They range from less hickups and distortion by disk accesses and/or driver bugs to new and improved features (software volume control implemented for soundcards which do not have hardware volume control). Additionally a new driver (snd_atiixp) has seen the light and a lot of problem reports where fixed. Most of those changes and the changes mentioned in the previous status report are already merged to RELENG_6 and will be part of 6.1-RELEASE. Open tasks: 1. Have a look at the sound related entries on the ideas list. 2. Rewrite some parts (e.g. a new mixer subsystem with OSS compatibility). 3. sndctl(1): tool to control non-mixer parts of the sound system (e.g. spdif switching, virtual-3D effects) by an user (instead of the sysctl approach in -current); pcmplay(1), pcmrec(1), pcmutil(1). 4. Plugable FEEDER infrastructure. For ease of debugging various feeder stuff and/or as userland library and test suite. 5. Support for new hardware (envy24, Intel HDA). 6. Performance enhancement (via 'slave'-channels). 7. Closer compatibility with OSS, especially for the upcoming OSS v4. _________________________________________________________________ SysKonnect/Marvell Yukon device driver URL: http://www.marvell.com URL: http://www.syskonnect.de Contact: Karim Jamal This project provides support for SysKonnect's SK-98xx, SK-95xx,SK-9Exx and SK-9Sxx PCI/PCI-Express Gigabit Ethernet adapters via the yk(4) driver, as well as Marvell's Yukon LOM Gigabit Ethernet controllers via the myk(4) driver. Driver source has been made available to selected members of the FreeBSD project. _________________________________________________________________ TCP/IP Optimization Fundraiser Status URL: http://people.freebsd.org/~andre/tcpoptimization.html URL: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/em/if_em.c?rev=3D1.98& content-type=3Dtext/x-cvsweb-markup URL: http://www.freebsd.org/news/status/report-july-2005-oct-2005.html#TCP- &-IP-Routing-Optimization-Fundraise Contact: Andre Oppermann The fundraise has been very successful and I want to thank everyone who has pledged their support and tipped the jar. The full amount plus a little bit more has been raised in a very short timeframe. More information on the exact amounts and their sponsors can be found at the first link. After the delays on this project caused by the FreeBSD 6.0 Release cycle code freeze work has picked up and a paper was written and a presentation held on "Optimizing the FreeBSD IP and TCP Stack" for EuroBSDCon 05 on November 27th. See related status report under that title. From December 21st to January 11th I received access to a calibrated Agilent N2X gigabit tester and traffic generator. Stock FreeBSD 7-current was tested and profiled extensively in this timeframe. A first proof of concept optimization was developed in cooperation with Scott Long. It involved converting the Intel Gigabit ethernet em(4) driver to make use of fast interrupt handlers, taskqueues and lockless RX ring handling. This improved the performance from 570kpps to 750kpps, a 25% improvement, with IP fastforwarding enabled. Open tasks: 1. A large number of profiles and measurements was taken and a detailed report on the performance characteristics and remaining bottlenecks is under preparation. 2. Further optimizations and new features described on the Optimization Fundraiser page. _________________________________________________________________ The FreeBSD Dutch Documentation Project URL: http://www.freebsd.org/doc/nl/books/handbook URL: http://www.freebsd-nl.org/doc/nl URL: http://www.freebsd-nl.org/www/nl/ Contact: Remko Lodder Contact: Siebrand Mazeland The FreeBSD Dutch Documentation Project is an ongoing project, focussed on translating the English documentation and website to the Dutch language. Currently we are almost done with the FreeBSD Handbook and started the initial translation of the FreeBSD Website. We are always looking for people to help out, if you can help, please contact Siebrand or me so that we can divide the work amongst us. Recent publications: Recently the Printing and the Serial Communications chapters were added to the FreeBSD Dutch Handbook. Recently started items: We started with the translation of the PPP and SLIP chapter and the translation of the website. Open tasks: 1. Translate the final parts of the FreeBSD handbook. 2. Translate the FreeBSD Website _________________________________________________________________ variant symlinks URL: http://butcher.heavennet.ru/patches/kernel/varsym/ Contact: Andrey Elsukov The port of DragonFly's variant symlinks ( project ideas ) to FreeBSD. Variant symlinks is a dynamic symbolic link implementation. Source file of a variant symlink may contain one or more variable names. Each of these variable names is enclosed in braces and preceded by a dollar sign in the style of variable references in sh(1). Whenever a variant symlink is followed, each variable found in source file is replaced by its associated value. In this manner, a variant symlink may resolve to different paths based on context. Open tasks: 1. Document a new system calls. 2. More testing. 3. Write the rc.d script for the variant symlinks initialization. _________________________________________________________________ Legal Notices | =A9 1995-2005 The FreeBSD Project. All rights reserved. --Boundary-00=_fKM2DGHbXhH9kQO-- From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 26 12:46:50 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E14C616A420 for ; Thu, 26 Jan 2006 12:46:50 +0000 (GMT) (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 5949343D69 for ; Thu, 26 Jan 2006 12:46:50 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id E6BD446B2D; Thu, 26 Jan 2006 07:46:43 -0500 (EST) Date: Thu, 26 Jan 2006 12:48:13 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: =?ISO-8859-1?Q?Mikko_Ty=F6l=E4j=E4rvi?= In-Reply-To: <20060122235133.Y89461@fledge.watson.org> Message-ID: <20060126123025.F16741@fledge.watson.org> References: <43CC3C6B.4060703@devnet.fi> <49431.195.139.252.5.1137461466.squirrel@webmail.i13i.com> <20060121155821.Y73866@spirou.home> <20060122235133.Y89461@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org, Antti Korpela Subject: Re: FreeBSD 6.0 default pty/tty-limit (256) OFF! X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2006 12:46:51 -0000 On Sun, 22 Jan 2006, Robert Watson wrote: > FYI, there's also a tty_pts.c floating around, based on some work I did at > McAfee a couple of years ago, that implements /dev/ptmx and /dev/pts for > FreeBSD. Among other things, it removes the limit on the number pty's, and > adopts the Sys V pty naming convention. While there are upsides and > downsides to the naming convention, it does attempt to normalize the way we > handle pty's, as well as removing the requirement for root privilege in > order to allocate and properly protect a pty. I have an older version at > http://www.watson.org/~robert/freebsd/pts/. However, it's fairly dated, and > may not work due to other changes since it was written (I've not looked to > see). I've tried several times to trick developers into picking it up and > doing the last remaining work to make it real -- largely what's required is > work on the forward/backward compatibility issue, that and extensive testing > and a security audit. It would be nice to ship 7.x with these changes as it > would resolve a lot of problems. As a follow-up, Olivier Houchard just committed tty_pts.c and supporting libc pieces to 7-CURRENT; you can find details in the HEADS UP post on freebsd-current. By default the limit is 1000 pty's, but that can be increased. Testing most welcome. Robert N M Watson From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 26 15:03:08 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 73D0C16A423 for ; Thu, 26 Jan 2006 15:03:08 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.FreeBSD.org (Postfix) with ESMTP id C69C043D48 for ; Thu, 26 Jan 2006 15:03:07 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.5b3) with ESMTP id 7030846 for multiple; Thu, 26 Jan 2006 10:01:49 -0500 Received: from localhost (john@localhost [127.0.0.1]) by server.baldwin.cx (8.13.4/8.13.4) with ESMTP id k0QF2uKs042547; Thu, 26 Jan 2006 10:02:57 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: Pranav Peshwe Date: Thu, 26 Jan 2006 09:52:16 -0500 User-Agent: KMail/1.9.1 References: <200601250952.41784.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200601260952.17149.jhb@freebsd.org> X-Virus-Scanned: ClamAV 0.87.1/1252/Thu Jan 26 06:03:25 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.4 required=4.2 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on server.baldwin.cx X-Server: High Performance Mail Server - http://surgemail.com r=1653887525 Cc: freebsd-hackers@freebsd.org Subject: Re: KTR not working !! X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2006 15:03:08 -0000 On Wednesday 25 January 2006 23:09, Pranav Peshwe wrote: > On 1/25/06, John Baldwin wrote: > > You only have KTR_GEN traces compiled in. Try adding > > 'KTR_COMPILE=KTR_ALL' If you run with all traces enabled your system is > > going to get really really slow though. > > Thank you !! It works now. > > I turned on 'verbose' and got a flurry of messages rushing across the > screen.But, ktrdump has not shown more than 7 messages.Does ktrdump > just 'tail' all those messages ? or, is there any separate > mask/environment variable for ktrdump ? I am not sure. Generally I just use 'show ktr' in kdb when I use KTR traces rather than using ktrdump. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 26 15:29:47 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 63C7F16A422; Thu, 26 Jan 2006 15:29:47 +0000 (GMT) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id AE80F43D58; Thu, 26 Jan 2006 15:29:46 +0000 (GMT) (envelope-from max@love2party.net) Received: from [84.163.212.17] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu8) with ESMTP (Nemesis), id 0ML2ov-1F294D0HCk-0000jG; Thu, 26 Jan 2006 16:29:45 +0100 From: Max Laier Organization: FreeBSD To: freebsd-hackers@freebsd.org Date: Thu, 26 Jan 2006 16:30:07 +0100 User-Agent: KMail/1.9.1 References: <200601261337.51906.max@love2party.net> In-Reply-To: <200601261337.51906.max@love2party.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1303815.kbdf5qYR6H"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200601261630.15251.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:61c499deaeeba3ba5be80f48ecc83056 Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: FreeBSD Status Report Fourth Quarter 2005 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2006 15:29:47 -0000 --nextPart1303815.kbdf5qYR6H Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Simon Barner just informed me that the links for Andre Opperman's papers ar= e=20 wrong. The correct location is: http://people.freebsd.org/~andre/ http://people.freebsd.org/~andre/New%20Networking%20Features%20in%20FreeBSD= %206%20-%20Presentation.pdf http://people.freebsd.org/~andre/New%20Networking%20Features%20in%20FreeBSD= %206%20-%20Paper.pdf http://people.freebsd.org/~andre/Optimizing%20the%20FreeBSD%20IP%20and%20TC= P%20Stack%20-%20Presentation.pdf http://people.freebsd.org/~andre/Optimizing%20the%20FreeBSD%20IP%20and%20TC= P%20Stack%20-%20Paper.pdf Sorry. =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 --nextPart1303815.kbdf5qYR6H Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQBD2OsHXyyEoT62BG0RAlKUAJ4lx0+2H+bCl3hDdkgi8GGDv6YqfACfcXDy tRzPv557CDFP4DbwcULXyb8= =poLb -----END PGP SIGNATURE----- --nextPart1303815.kbdf5qYR6H-- From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 26 15:54:20 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BE1D516A422 for ; Thu, 26 Jan 2006 15:54:20 +0000 (GMT) (envelope-from ducrot@poupinou.org) Received: from poup.poupinou.org (poup.poupinou.org [195.101.94.96]) by mx1.FreeBSD.org (Postfix) with ESMTP id BAC6743D69 for ; Thu, 26 Jan 2006 15:54:19 +0000 (GMT) (envelope-from ducrot@poupinou.org) Received: from ducrot by poup.poupinou.org with local (Exim) id 1F29Rs-0001zJ-00; Thu, 26 Jan 2006 16:54:12 +0100 Date: Thu, 26 Jan 2006 16:54:12 +0100 To: Surer Dink Message-ID: <20060126155412.GB11603@poupinou.org> References: <20060125134441.GA11603@poupinou.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="7JfCtLOvnd9MIVvH" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i From: Bruno Ducrot Cc: freebsd-hackers@freebsd.org Subject: Re: CPU/case/disk temperature sensors for Dell PowerEdge 2850 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2006 15:54:20 -0000 --7JfCtLOvnd9MIVvH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Jan 25, 2006 at 03:39:44PM -0500, Surer Dink wrote: > On 1/25/06, Bruno Ducrot wrote: > > > > On Tue, Jan 24, 2006 at 06:48:37PM -0500, Surer Dink wrote: > > > I have tried every means I could find to read the temperature sensors > > (CPU, > > > case, disk) on Dell PowerEdge 2850 machines, and none seem to work. Has > > > anyone had success in doing this? If such support does not exist, what > > > would be required to add it? If needed, I am willing to finance (within > > > reason) development of this feature. [I was told that Linux and Windows > > > software to read this information is available, so I assume this is > > > possible.] > > > > First, install sysutils/freeipmi, then try it by this command: > > # bmc-info > > > > If it don't work, or loop forever, please install > > dmidecode (sysutils/dmidecode) then give us the output from > > it for the type entry 38 (IPMI Device Information). > > > bmc-info hangs, output of dmidecode for type 38 is: > Handle 0x2600 > DMI type 38, 18 bytes. > IPMI Device Information > Interface Type: KCS (Keyboard Control Style) > Specification Version: 1.5 > I2C Slave Address: 0x10 > NV Storage Device: Not Present > Base Address: 0x0000000000000CA8 (I/O) > Register Spacing: 32-bit Boundaries > > Incidentally, I attempted the same on other servers (Dell 2550 and some > Supermicros) and they do not contain a "type 38" at all... The DMI stuff is more or less optional. If not present, this won't means IPMI is not there. For both Dell 2550 (this time..) and the Supermicros, if there are some remote cards control then FreeIPMI should work even if no such handle does not exist at all. If this won't work, for the supermicro at least I think sysutils/mbmon may work. Back to the Dell 2850, the problem is the 'Register Spacing: 32-bit Boundaries' line. FreeIPMI 0.1.3 does not implement this feature and use always the default 8-bit boundary. The symptom is that bmc-info hang forever. Fortunately, the next release will include this support. By now, there is a beta available but no port has been done. By now, you can try to copy the attached file to ports/sysutils/freeipmi/files and rebuild the port. -- Bruno Ducrot -- Which is worse: ignorance or apathy? -- Don't know. Don't care. --7JfCtLOvnd9MIVvH Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=patch-correct-sizes --- libfreeipmi/src/ipmi-kcs-interface.c 2006/01/26 11:20:55 1.1 +++ libfreeipmi/src/ipmi-kcs-interface.c 2006/01/26 11:24:14 @@ -70,11 +70,11 @@ #include "freeipmi.h" #if defined(__FreeBSD__) -#define _INB(port) inb (port) -#define _OUTB(data, port) outb (port, data) +#define _INL(port) inl (port) +#define _OUTL(data, port) outl (port, data) #else -#define _INB(port) inb (port) -#define _OUTB(data, port) outb (data, port) +#define _INL(port) inL (port) +#define _OUTL(data, port) outL (data, port) #endif static u_int64_t kcs_poll_count; @@ -115,7 +115,7 @@ #ifdef __FreeBSD__ #ifdef USE_IOPERM /* i386_set_ioperm has known problems on FBSD 5.x (bus errors). */ - return (i386_set_ioperm(sms_io_base, 0x02, 0x01)); + return (i386_set_ioperm(sms_io_base, 0x08, 0x01)); #else /* Opening /dev/io raises IOPL bits for current process. */ /* XXX This fd will remain open until exit as there is no @@ -206,7 +206,7 @@ int8_t ipmi_kcs_get_status (u_int16_t sms_io_base) { - return _INB (IPMI_KCS_REG_STATUS (sms_io_base)); + return _INL (IPMI_KCS_REG_STATUS (sms_io_base)); } /* @@ -244,7 +244,7 @@ int8_t ipmi_kcs_read_byte (u_int16_t sms_io_base) { - return _INB (IPMI_KCS_REG_DATAOUT (sms_io_base)); + return _INL (IPMI_KCS_REG_DATAOUT (sms_io_base)); } /* @@ -253,7 +253,7 @@ void ipmi_kcs_read_next (u_int16_t sms_io_base) { - _OUTB (IPMI_KCS_CTRL_READ, IPMI_KCS_REG_DATAIN (sms_io_base)); + _OUTL (IPMI_KCS_CTRL_READ, IPMI_KCS_REG_DATAIN (sms_io_base)); } /* * Set up channel for writing. @@ -261,7 +261,7 @@ void ipmi_kcs_start_write (u_int16_t sms_io_base) { - _OUTB (IPMI_KCS_CTRL_WRITE_START, IPMI_KCS_REG_CMD (sms_io_base)); + _OUTL (IPMI_KCS_CTRL_WRITE_START, IPMI_KCS_REG_CMD (sms_io_base)); } /* @@ -270,7 +270,7 @@ void ipmi_kcs_write_byte (u_int16_t sms_io_base, u_int8_t byte) { - _OUTB (byte, IPMI_KCS_REG_DATAIN (sms_io_base)); + _OUTL (byte, IPMI_KCS_REG_DATAIN (sms_io_base)); } /* @@ -279,7 +279,7 @@ void ipmi_kcs_end_write (u_int16_t sms_io_base) { - _OUTB (IPMI_KCS_CTRL_WRITE_END, IPMI_KCS_REG_CMD (sms_io_base)); + _OUTL (IPMI_KCS_CTRL_WRITE_END, IPMI_KCS_REG_CMD (sms_io_base)); } /* @@ -288,7 +288,7 @@ void ipmi_kcs_get_abort (u_int16_t sms_io_base) { - _OUTB (IPMI_KCS_CTRL_GET_ABORT, IPMI_KCS_REG_CMD (sms_io_base)); + _OUTL (IPMI_KCS_CTRL_GET_ABORT, IPMI_KCS_REG_CMD (sms_io_base)); } int8_t --- libfreeipmi/src/ipmi-kcs-interface.h 2006/01/26 11:20:55 1.1 +++ libfreeipmi/src/ipmi-kcs-interface.h 2006/01/26 11:24:42 @@ -49,8 +49,8 @@ /* IPMI KCS SMS Interface Registers */ #define IPMI_KCS_REG_DATAIN(sms_io_base) (sms_io_base) #define IPMI_KCS_REG_DATAOUT(sms_io_base) (sms_io_base) -#define IPMI_KCS_REG_CMD(sms_io_base) (sms_io_base+1) -#define IPMI_KCS_REG_STATUS(sms_io_base) (sms_io_base+1) +#define IPMI_KCS_REG_CMD(sms_io_base) (sms_io_base+4) +#define IPMI_KCS_REG_STATUS(sms_io_base) (sms_io_base+4) /* KCS Interface Status Register Bits */ /* Scheme BIT Calculator Example --7JfCtLOvnd9MIVvH-- From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 26 16:09:04 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 03BD616A420 for ; Thu, 26 Jan 2006 16:09:04 +0000 (GMT) (envelope-from shulik_freebsd@matrixhome.net) Received: from mail.donec.net (ns.donec.net [193.108.38.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 85BC143D45 for ; Thu, 26 Jan 2006 16:09:02 +0000 (GMT) (envelope-from shulik_freebsd@matrixhome.net) Received: from [192.168.133.9] (proxy.donec.net [193.108.38.2]) by mail.donec.net (Postfix) with ESMTP id 6AD73187F2B for ; Thu, 26 Jan 2006 18:09:01 +0200 (EET) Message-ID: <43D8F427.9060704@matrixhome.net> Date: Thu, 26 Jan 2006 18:09:11 +0200 From: Alexander User-Agent: Mozilla Thunderbird 1.0.6 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: FreeBSD vs pl2303 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2006 16:09:04 -0000 Hi! I have mobile phone Siemens CXV70 and USB data cable for it. When I attach phone to cable in Linux I can see, that device ttyUSB0 with driver pl2303 attached. On FreeBSD when I attach phone to cable I see ugen0 (uplcom, ucom, umodem loaded). When I try to change source code and add my vendor to uplcom - I received: ucom0: Siemens AG Siemens USB Connectivity, rev 1.10/0.95, addr 3 ucom0: uplcom_reset: STALLED ucom0: reset failed: NOMEM device_attach: ucom0 attach returned 6 # usbdevs -v Controller /dev/usb0: addr 1: full speed, self powered, config 1, UHCI root hub(0x0000), Intel(0x0000), rev 1.00 port 1 addr 3: full speed, power 98 mA, config 1, Siemens USB Connectivity(0x0003), Siemens AG(0x11f5), rev 0.95 port 2 addr 2: low speed, power 100 mA, config 1, Microsoft 3-Button Mouse with IntelliEye(TM)(0x0040), Microsoft(0x045e), rev 3.00 Controller /dev/usb1: addr 1: full speed, self powered, config 1, UHCI root hub(0x0000), Intel(0x0000), rev 1.00 port 1 powered port 2 powered How I can get this device to work? From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 26 16:32:49 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4FD0916A420 for ; Thu, 26 Jan 2006 16:32:49 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.FreeBSD.org (Postfix) with ESMTP id 973A743D49 for ; Thu, 26 Jan 2006 16:32:48 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.5b3) with ESMTP id 7037605 for multiple; Thu, 26 Jan 2006 11:31:37 -0500 Received: from localhost (john@localhost [127.0.0.1]) by server.baldwin.cx (8.13.4/8.13.4) with ESMTP id k0QGWj1S043117; Thu, 26 Jan 2006 11:32:45 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Thu, 26 Jan 2006 11:33:38 -0500 User-Agent: KMail/1.9.1 References: <806128ad0601250608u67aae744u@mail.gmail.com> <200601250956.35818.jhb@freebsd.org> <806128ad0601260254u42dfd927k@mail.gmail.com> In-Reply-To: <806128ad0601260254u42dfd927k@mail.gmail.com> MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_jnP2DIjaYjxVBkg" Message-Id: <200601261133.39848.jhb@freebsd.org> X-Virus-Scanned: ClamAV 0.87.1/1252/Thu Jan 26 06:03:25 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.4 required=4.2 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on server.baldwin.cx X-Server: High Performance Mail Server - http://surgemail.com r=1653887525 Cc: Vitaliy Skakun Subject: Re: Comtrol Rocketport UNIVERSAL PCI 32-port X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2006 16:32:49 -0000 --Boundary-00=_jnP2DIjaYjxVBkg Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline On Thursday 26 January 2006 05:54, Vitaliy Skakun wrote: > Hi everybody! > > One problem arised: > > when doing in the shell > echo "~WS" > /dev/cuaR00 > > for several times as quick as I can, I get panic with the following > message: panic: device_unbusy: called for non-busy device rp0 > > same thing when trying to send data to /dev/cuaR00 via JDK File streams ... > > :((( > > (Some kind of barcode printers are attached to this multiport card) > > Any help will be kindly accepted. > > Cheers > Vit Try the attached patch. tty's don't use D_TRACKCLOSE but rp(4) was expecting that rpclose() was called on every close, not just the last close. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org --Boundary-00=_jnP2DIjaYjxVBkg Content-Type: text/x-diff; charset="iso-8859-1"; name="rp_busy.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="rp_busy.patch" Index: rp.c =================================================================== RCS file: /usr/cvs/src/sys/dev/rp/rp.c,v retrieving revision 1.71 diff -u -r1.71 rp.c --- rp.c 4 Dec 2005 10:06:04 -0000 1.71 +++ rp.c 26 Jan 2006 16:32:48 -0000 @@ -929,7 +929,9 @@ rp_callout_handle = timeout(rp_do_poll, (void *)NULL, POLL_INTERVAL); - device_busy(rp->rp_ctlp->dev); + if (rp->rp_open_count == 0) + device_busy(rp->rp_ctlp->dev); + rp->rp_open_count++; return(0); } @@ -960,6 +962,7 @@ tp->t_actout = FALSE; wakeup(&tp->t_actout); wakeup(TSA_CARR_ON(tp)); + rp->rp_open_count = 0; device_unbusy(rp->rp_ctlp->dev); } Index: rpvar.h =================================================================== RCS file: /usr/cvs/src/sys/dev/rp/rpvar.h,v retrieving revision 1.9 diff -u -r1.9 rpvar.h --- rpvar.h 4 Dec 2005 10:06:04 -0000 1.9 +++ rpvar.h 26 Jan 2006 16:31:59 -0000 @@ -47,6 +47,7 @@ unsigned char state; /* state of dtr */ int rp_port; + int rp_open_count; int rp_flags; int rp_unit:2; int rp_aiop:2; --Boundary-00=_jnP2DIjaYjxVBkg-- From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 26 16:49:56 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F1B1416A422 for ; Thu, 26 Jan 2006 16:49:56 +0000 (GMT) (envelope-from tdamas@gmail.com) Received: from nproxy.gmail.com (nproxy.gmail.com [64.233.182.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id 08F0A43D45 for ; Thu, 26 Jan 2006 16:49:55 +0000 (GMT) (envelope-from tdamas@gmail.com) Received: by nproxy.gmail.com with SMTP id l37so21513nfc for ; Thu, 26 Jan 2006 08:49:54 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=aM0VL73cYOncQpEJVMRErlzh1ULyNK7xKmf0lKl83DfODetBZGQQEBmlvSJYBZZnv2TyK4665jqeQMSfqkvOYyOt7hlC0F9YzAz4gzx9XWxFKmjNdaaXh/BnjrRWKVB7ZKH8UdqMD/gfobNH2taOfuH4ahnj+XAJb/sE3rUBUFA= Received: by 10.48.239.6 with SMTP id m6mr73366nfh; Thu, 26 Jan 2006 08:49:54 -0800 (PST) Received: by 10.48.210.7 with HTTP; Thu, 26 Jan 2006 08:49:54 -0800 (PST) Message-ID: Date: Thu, 26 Jan 2006 14:49:54 -0200 From: Thiago Damas To: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Subject: if_bridge hangs ifconfig X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2006 16:49:57 -0000 Hi, I'm having some problems using if_bridge, in FreeBSD 6.0 RELEASE. I have the following situation: vr0: flags=3D8943 mtu 1500 inet6 fe80::20f:eaff:fea4:a2f5%vr0 prefixlen 64 scopeid 0x4 ether 00:0f:ea:a4:a2:f5 media: Ethernet autoselect (10baseT/UTP) status: active xl0: flags=3D8843 mtu 1500 options=3D8 inet6 fe80::260:8ff:fe3b:56de%xl0 prefixlen 64 scopeid 0x2 ether 00:60:08:3b:56:de media: Ethernet 10baseT/UTP (10baseT/UTP ) status: active So, I created a bridge0 interface using "ifconfig bridge0 create ; ifconfig bridge0 addm vr0" bridge0: flags=3D8041 mtu 1500 inet 10.5.1.24 netmask 0xffffff00 ether ac:de:48:d1:3f:f1 priority 32768 hellotime 2 fwddelay 15 maxage 20 member: vr0 flags=3D3 Now, I want to change the member vr0 of bridge0 to xl0 (for backup purpos= es): ifconfig bridge0 deletem vr0 (it hangs here) ifconfig bridge0 addm xl0 When using the command "ifconfig bridge0 deletem vr0", its hangs, and sometimes show the error: vr0: refusing to decrement non-positive refcount 0for interface flag 256 In this machine, I'm using ipfw too, with rules like this: ipfw add 1 pipe 1 ip from any to any via bridge0 in ipfw add 2 pipe 2 ip from any to any via bridge0 out ipfw pipe 1 config bw 1Mbit/s ipfw pipe 2 config bw 1Mbit/s ipfw add 50 check-state ... ... I tried to do a flush of these rules before "ifconfig bridge0 deletem vr0", but this doesnt worked. Someone already have this problem and can help me? Thiago From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 26 17:28:47 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 580C116A420 for ; Thu, 26 Jan 2006 17:28:47 +0000 (GMT) (envelope-from thompsa@freebsd.org) Received: from dbmail-mx4.orcon.co.nz (loadbalancer1.orcon.net.nz [219.88.242.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id B88F543D45 for ; Thu, 26 Jan 2006 17:28:46 +0000 (GMT) (envelope-from thompsa@freebsd.org) Received: from heff.fud.org.nz (60-234-149-201.bitstream.orcon.net.nz [60.234.149.201]) by dbmail-mx4.orcon.co.nz (8.13.5/8.13.5/Debian-3) with ESMTP id k0QHSahU021095; Fri, 27 Jan 2006 06:28:37 +1300 Received: by heff.fud.org.nz (Postfix, from userid 1001) id 5FA971CC1F; Fri, 27 Jan 2006 06:28:43 +1300 (NZDT) Date: Fri, 27 Jan 2006 06:28:43 +1300 From: Andrew Thompson To: Thiago Damas Message-ID: <20060126172843.GA33764@heff.fud.org.nz> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.11 X-Virus-Scanned: ClamAV 0.88/1252/Fri Jan 27 00:03:25 2006 on dbmail-mx4.orcon.co.nz X-Virus-Status: Clean Cc: freebsd-hackers@freebsd.org Subject: Re: if_bridge hangs ifconfig X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2006 17:28:47 -0000 On Thu, Jan 26, 2006 at 02:49:54PM -0200, Thiago Damas wrote: > I'm having some problems using if_bridge, in FreeBSD 6.0 RELEASE. > I have the following situation: > > When using the command "ifconfig bridge0 deletem vr0", its hangs, > and sometimes show the error: > vr0: refusing to decrement non-positive refcount 0for interface flag 256 This has been fixed in 6-STABLE and will work in the upcomming 6.1 release, see the 2005/11/16 entry in http://www.freebsd.org/releases/6.0R/errata.html I would advise upgrading to RELENG_6. regards, Andrew From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 26 18:04:33 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D324F16A420 for ; Thu, 26 Jan 2006 18:04:33 +0000 (GMT) (envelope-from surerlistmail@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.195]) by mx1.FreeBSD.org (Postfix) with ESMTP id 725B743D55 for ; Thu, 26 Jan 2006 18:04:24 +0000 (GMT) (envelope-from surerlistmail@gmail.com) Received: by zproxy.gmail.com with SMTP id 9so431924nzo for ; Thu, 26 Jan 2006 10:04:23 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=mRuY6WVGz+6dWs3qByzN585UZ5gl14RDM5OkmwpZgpgDf2bl7bHnk16/KQN8k8Tmu+vSV6VqaS+CEgKDkItpLQOsAHYVzYZspbjREsqH4+6Ug2X4clL0zlSgjM5GxUtxdRMbHN0s4aVjfwqm1xMe1ct5vKptqar3wDTJ4KZipiE= Received: by 10.36.115.2 with SMTP id n2mr1662615nzc; Thu, 26 Jan 2006 10:04:23 -0800 (PST) Received: by 10.36.41.11 with HTTP; Thu, 26 Jan 2006 10:04:23 -0800 (PST) Message-ID: Date: Thu, 26 Jan 2006 13:04:23 -0500 From: Surer Dink To: Bruno Ducrot In-Reply-To: <20060126155412.GB11603@poupinou.org> MIME-Version: 1.0 References: <20060125134441.GA11603@poupinou.org> <20060126155412.GB11603@poupinou.org> X-Mailman-Approved-At: Thu, 26 Jan 2006 18:07:47 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org Subject: Re: CPU/case/disk temperature sensors for Dell PowerEdge 2850 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2006 18:04:33 -0000 On 1/26/06, Bruno Ducrot wrote: > > > > First, install sysutils/freeipmi, then try it by this command: > > > # bmc-info > > > > > > If it don't work, or loop forever, please install > > > dmidecode (sysutils/dmidecode) then give us the output from > > > it for the type entry 38 (IPMI Device Information). > > > > > > bmc-info hangs, output of dmidecode for type 38 is: > > Handle 0x2600 > > DMI type 38, 18 bytes. > > IPMI Device Information > > Interface Type: KCS (Keyboard Control Style) > > Specification Version: 1.5 > > I2C Slave Address: 0x10 > > NV Storage Device: Not Present > > Base Address: 0x0000000000000CA8 (I/O) > > Register Spacing: 32-bit Boundaries > > > > Incidentally, I attempted the same on other servers (Dell 2550 and some > > Supermicros) and they do not contain a "type 38" at all... > > The DMI stuff is more or less optional. If not present, this won't > means IPMI is not there. For both Dell 2550 (this time..) and the > Supermicros, if there are some remote cards control then FreeIPMI should > work even if no such handle does not exist at all. > If this won't work, for the supermicro at least I > think sysutils/mbmon may work. > > Back to the Dell 2850, the problem is the 'Register Spacing: > 32-bit Boundaries' line. > FreeIPMI 0.1.3 does not implement this feature and use > always the default 8-bit boundary. The symptom is that bmc-info > hang forever. > > Fortunately, the next release will include this support. By now, > there is a beta available but no port has been done. > > By now, you can try to copy the attached file to > ports/sysutils/freeipmi/files > and rebuild the port. Gave it a shot, but seemingly no change. bmc-info still hangs, bmc-config -o outputs: Section User1 ## Give username Username Anonymous ## Give password or leave it blank to clear password Password and then hangs... It's good to know the solution is 'in the works'. If I understand correctly, having these tools work will allow me to actually enable/configure this interface, correct? (re Dell 2550 - bmc-info/bmc-config have identical behavior to the 2850 (with the patch and without), -info hangs, -config -o hangs after spitting out the above...) From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 26 18:04:56 2006 Return-Path: X-Original-To: freebsd-hackers@FreeBSD.ORG Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8857016A420 for ; Thu, 26 Jan 2006 18:04:56 +0000 (GMT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [83.120.8.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id BC41E43D46 for ; Thu, 26 Jan 2006 18:04:55 +0000 (GMT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (ytmlif@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.4/8.13.4) with ESMTP id k0QI4mE5073349 for ; Thu, 26 Jan 2006 19:04:53 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.4/8.13.1/Submit) id k0QI4mZk073348; Thu, 26 Jan 2006 19:04:48 +0100 (CET) (envelope-from olli) Date: Thu, 26 Jan 2006 19:04:48 +0100 (CET) Message-Id: <200601261804.k0QI4mZk073348@lurza.secnetix.de> From: Oliver Fromme To: freebsd-hackers@FreeBSD.ORG In-Reply-To: <20060126155412.GB11603@poupinou.org> X-Newsgroups: list.freebsd-hackers User-Agent: tin/1.8.0-20051224 ("Ronay") (UNIX) (FreeBSD/4.11-STABLE (i386)) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Thu, 26 Jan 2006 19:04:54 +0100 (CET) X-Mailman-Approved-At: Thu, 26 Jan 2006 18:07:56 +0000 Cc: Subject: Re: CPU/case/disk temperature sensors for Dell PowerEdge 2850 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-hackers@FreeBSD.ORG List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2006 18:04:56 -0000 Hi, Sorry for jumping into this thread. I have the same problem, but on different hardware. Bruno Ducrot wrote: > > > First, install sysutils/freeipmi, then try it by this command: > > > # bmc-info It hangs forever. "bmc-config -o" prints a few lines (starts with "Section User1" and doesn't seem useful), then also hangs forever. Oh, by thy way, my machine is a HP ProLiant DL360 G4 (formerly Compaq). > > > If it don't work, or loop forever, please install > > > dmidecode (sysutils/dmidecode) then give us the output from > > > it for the type entry 38 (IPMI Device Information). That prints quite a lot of information, which is even partially useful (e.g. it lists the configration of the RAM DIMM slots, CPUs and the machine serial number). Thanks for mentioning that tool! However -- no type 38. :-( > The DMI stuff is more or less optional. If not present, this won't > means IPMI is not there. For both Dell 2550 (this time..) and the > Supermicros, if there are some remote cards control then FreeIPMI should > work even if no such handle does not exist at all. The DL360 has such remote control stuff, too. > If this won't work, for the supermicro at least I > think sysutils/mbmon may work. That was the first thing I've tried. No go. I've also tried other similar ports (lmmon, healthd). Same thing. > Back to the Dell 2850, the problem is the 'Register Spacing: > 32-bit Boundaries' line. > FreeIPMI 0.1.3 does not implement this feature and use > always the default 8-bit boundary. The symptom is that bmc-info > hang forever. > > Fortunately, the next release will include this support. By now, > there is a beta available but no port has been done. > > By now, you can try to copy the attached file to > ports/sysutils/freeipmi/files > and rebuild the port. I compiled the port with that patch file, but the symptom didn't change. Still hangs forever. Any further advice would be very welcome. Also, if I can provide any information, just tell me what you need. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "One of the main causes of the fall of the Roman Empire was that, lacking zero, they had no way to indicate successful termination of their C programs." -- Robert Firth From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 26 18:07:27 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9D65916A422 for ; Thu, 26 Jan 2006 18:07:27 +0000 (GMT) (envelope-from vit.ska@gmail.com) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.197]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1E25443D4C for ; Thu, 26 Jan 2006 18:07:25 +0000 (GMT) (envelope-from vit.ska@gmail.com) Received: by xproxy.gmail.com with SMTP id s9so256390wxc for ; Thu, 26 Jan 2006 10:07:25 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=ibDQ9bNfYEArVbWsvRAw8xWCX2H1l2xvhfyc+WUYvSZHgwYjB4wLqbOy1mcDjd/7i36D49jBdL4jwRz0ZFJxNo2FaIrOohc8xJCbhvk0icG/mNTcgEioB38e1JaWbd/LaIiHBs/wx1J2dfEAr4hTSibGQxwMvKygFRaGzP7jvzA= Received: by 10.70.73.7 with SMTP id v7mr2502484wxa; Thu, 26 Jan 2006 10:07:25 -0800 (PST) Received: by 10.70.118.3 with HTTP; Thu, 26 Jan 2006 10:07:25 -0800 (PST) Message-ID: <806128ad0601261007n29b19bb3y@mail.gmail.com> Date: Thu, 26 Jan 2006 20:07:25 +0200 From: Vitaliy Skakun To: freebsd-hackers@freebsd.org In-Reply-To: <200601261133.39848.jhb@freebsd.org> MIME-Version: 1.0 References: <806128ad0601250608u67aae744u@mail.gmail.com> <200601250956.35818.jhb@freebsd.org> <806128ad0601260254u42dfd927k@mail.gmail.com> <200601261133.39848.jhb@freebsd.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: Comtrol Rocketport UNIVERSAL PCI 32-port X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2006 18:07:27 -0000 dHJpZWQgdGhpcyBwYXRjaAoKZWNobyAifldDIiA+IC9kZXYvY3VhUjAwCgp3b3JrZWQgb2sgd2hl biBJIHRyaWVkIHRoaXMgYSBsb3Qgb2YgdGltZXMgcXVpY2tseSwgYnV0IHdoZW4gSSB0cnkgdG8g c2VuZApsYXJnZXIgZmlsZXMsIGl0IHBhbmljcyBhZ2FpbiA6Cgpyb290QHBsMjp+IFswXSMgY2F0 IDEudHh0ID4gL2Rldi9jdWFSMDAKcm9vdEBwbDI6fiBbMF0jIGNhdCAxLnR4dCA+IC9kZXYvY3Vh UjAwCgpeXl5eIGFmdGVyIHRoaXMgdGhlIHNhbWUgcGFuaWMgb2NjdXJlZAoKdGhlIHNpemUgb2Yg ZmlsZSBpcyAxOTQgYnl0ZXMuIHNhbWUgdGhpbmcgb2NjdXJlZCB3aGVuIEkgc2VudCBvbmx5IG9u Y2UgdGhlCmZpbGUgb2Ygc2l6ZT0xMTY0CgphZnRlciByZWJvb3Q6Cgpyb290QHBsMjp+IFswXSMg Z3JlcCBwYW5pYyAvdmFyL2xvZy9tZXNzYWdlcwpKYW4gMjYgMTc6Mzg6NDkgcGwyIHNhdmVjb3Jl OiByZWJvb3QgYWZ0ZXIgcGFuaWM6IGRldmljZV91bmJ1c3k6IGNhbGxlZCBmb3IKbm9uLWJ1c3kg ZGV2aWNlIHJwMAoKYWxzbyBub3RpY2VkIHRoZSBmb2xsb3dpbmcgOgp3aGVuIHRyeWluZwoKcm9v dEBwbDI6fiBbMF0jIGNhdCAvcm9vdC8xLnR4dHxjdSAtbGN1YVIwMApDb25uZWN0ZWQKfi4Kfi5e QwpeXl4gY3UgaGFuZwoKcm9vdEBwbDI6fiBbMV0jIHBzIHhhdXxncmVwIGN1CnJvb3QgICAgNzMz ICAwLjAgIDAuMCAgMTI4NCAgIDk3MiAgcDAtIEkgICAgIDU6NTVQTSAgIDA6MDAuMDAgY3UgLWxj dWFSMDAKCnJvb3RAcGwyOn4gWzBdIyBraWxsYWxsIGN1CgpBbmQgY3UgaXMga2lsbGVkLCB3aXRo IG5vIHBhbmljLgoKQ2hlZXJzClZpdAoKMjAwNi8xLzI2LCBKb2huIEJhbGR3aW4gPGpoYkBmcmVl YnNkLm9yZz46Cj4KPiBPbiBUaHVyc2RheSAyNiBKYW51YXJ5IDIwMDYgMDU6NTQsIFZpdGFsaXkg U2tha3VuIHdyb3RlOgo+ID4gSGkgZXZlcnlib2R5IQo+ID4KPiA+IE9uZSBwcm9ibGVtIGFyaXNl ZDoKPiA+Cj4gPiB3aGVuIGRvaW5nIGluIHRoZSBzaGVsbAo+ID4gZWNobyAifldTIiA+IC9kZXYv Y3VhUjAwCj4gPgo+ID4gZm9yIHNldmVyYWwgdGltZXMgYXMgcXVpY2sgYXMgSSBjYW4sIEkgZ2V0 IHBhbmljIHdpdGggdGhlIGZvbGxvd2luZwo+ID4gbWVzc2FnZTogcGFuaWM6IGRldmljZV91bmJ1 c3k6IGNhbGxlZCBmb3Igbm9uLWJ1c3kgZGV2aWNlIHJwMAo+ID4KPiA+IHNhbWUgdGhpbmcgd2hl biB0cnlpbmcgdG8gc2VuZCBkYXRhIHRvIC9kZXYvY3VhUjAwIHZpYSBKREsgRmlsZSBzdHJlYW1z Cj4gLi4uCj4gPgo+ID4gOigoKAo+ID4KPiA+IChTb21lIGtpbmQgb2YgYmFyY29kZSBwcmludGVy cyBhcmUgYXR0YWNoZWQgdG8gdGhpcyBtdWx0aXBvcnQgY2FyZCkKPiA+Cj4gPiBBbnkgaGVscCB3 aWxsIGJlIGtpbmRseSBhY2NlcHRlZC4KPiA+Cj4gPiBDaGVlcnMKPiA+IFZpdAo+Cj4gVHJ5IHRo ZSBhdHRhY2hlZCBwYXRjaC4gIHR0eSdzIGRvbid0IHVzZSBEX1RSQUNLQ0xPU0UgYnV0IHJwKDQp IHdhcwo+IGV4cGVjdGluZwo+IHRoYXQgcnBjbG9zZSgpIHdhcyBjYWxsZWQgb24gZXZlcnkgY2xv c2UsIG5vdCBqdXN0IHRoZSBsYXN0IGNsb3NlLgo+Cj4gLS0KPiBKb2huIEJhbGR3aW4gPGpoYkBG cmVlQlNELm9yZz4gIDw+PCAgaHR0cDovL3d3dy5GcmVlQlNELm9yZy9+amhiLwo+ICJQb3dlciBV c2VycyBVc2UgdGhlIFBvd2VyIHRvIFNlcnZlIiAgPSAgaHR0cDovL3d3dy5GcmVlQlNELm9yZwo+ Cj4KPgo= From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 26 18:18:09 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C3F6716A420 for ; Thu, 26 Jan 2006 18:18:09 +0000 (GMT) (envelope-from vit.ska@gmail.com) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0372943D48 for ; Thu, 26 Jan 2006 18:18:06 +0000 (GMT) (envelope-from vit.ska@gmail.com) Received: by xproxy.gmail.com with SMTP id s9so257748wxc for ; Thu, 26 Jan 2006 10:18:06 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=iynLfnEMLt5EhNJaUvtDsPnydSW0cv9UgYMeYE4Fb0+46050hQ0HfnW+nMrk/LfvUuFmxFGOMN65EkBBqOq5sqETcDA9E3Xpl/KVn/Pomcjv72DchxuQ6uJQG3coZ/DNoKGRCfZeU+2zzNXC+Xfdf5Cn0wWhdDxf6J5gZG9fVwg= Received: by 10.70.125.18 with SMTP id x18mr2583375wxc; Thu, 26 Jan 2006 10:18:06 -0800 (PST) Received: by 10.70.118.3 with HTTP; Thu, 26 Jan 2006 10:18:05 -0800 (PST) Message-ID: <806128ad0601261018p474db087u@mail.gmail.com> Date: Thu, 26 Jan 2006 20:18:05 +0200 From: Vitaliy Skakun To: freebsd-hackers@freebsd.org In-Reply-To: <200601261133.39848.jhb@freebsd.org> MIME-Version: 1.0 References: <806128ad0601250608u67aae744u@mail.gmail.com> <200601250956.35818.jhb@freebsd.org> <806128ad0601260254u42dfd927k@mail.gmail.com> <200601261133.39848.jhb@freebsd.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: Comtrol Rocketport UNIVERSAL PCI 32-port X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2006 18:18:09 -0000 aW4gYWRkaXRpb24gdG8gcHJldmlvdXMgZW1haWwgOgoKcm9vdEBwbDI6fiBbMF0jIGtnZGIgL2Jv b3Qva2VybmVsL2tlcm5lbCAvYmFja3Vwcy9jcmFzaC92bWNvcmUuMApbR0RCIHdpbGwgbm90IGJl IGFibGUgdG8gZGVidWcgdXNlci1tb2RlIHRocmVhZHM6IC91c3IvbGliL2xpYnRocmVhZF9kYi5z bzoKVW5kZWZpbmVkIHN5bWJvbCAicHNfcGdsb2JhbF9sb29rdXAiXQpHTlUgZ2RiIDYuMS4xIFtG cmVlQlNEXQpDb3B5cmlnaHQgMjAwNCBGcmVlIFNvZnR3YXJlIEZvdW5kYXRpb24sIEluYy4KR0RC IGlzIGZyZWUgc29mdHdhcmUsIGNvdmVyZWQgYnkgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNl bnNlLCBhbmQgeW91IGFyZQp3ZWxjb21lIHRvIGNoYW5nZSBpdCBhbmQvb3IgZGlzdHJpYnV0ZSBj b3BpZXMgb2YgaXQgdW5kZXIgY2VydGFpbgpjb25kaXRpb25zLgpUeXBlICJzaG93IGNvcHlpbmci IHRvIHNlZSB0aGUgY29uZGl0aW9ucy4KVGhlcmUgaXMgYWJzb2x1dGVseSBubyB3YXJyYW50eSBm b3IgR0RCLiAgVHlwZSAic2hvdyB3YXJyYW50eSIgZm9yIGRldGFpbHMuClRoaXMgR0RCIHdhcyBj b25maWd1cmVkIGFzICJpMzg2LW1hcmNlbC1mcmVlYnNkIi4KKG5vIGRlYnVnZ2luZyBzeW1ib2xz IGZvdW5kKS4uLkF0dGVtcHQgdG8gZXh0cmFjdCBhIGNvbXBvbmVudCBvZiBhIHZhbHVlCnRoYXQg aXMgbm90IGEgc3RydWN0dXJlIHBvaW50ZXIuCihrZ2RiKSBidAojMCAgMHhjMDU4NGRhOSBpbiBk b2FkdW1wICgpCiMxICAweGMwNTg1NDA3IGluIGJvb3QgKCkKIzIgIDB4YzA1ODVhMjAgaW4gcGFu aWMgKCkKIzMgIDB4YzA1OWU4MmMgaW4gZGV2aWNlX3VuYnVzeSAoKQojNCAgMHhjMDVjMTU1ZiBp biB0dHljbG9zZSAoKQojNSAgMHhjMDU1MTY3ZiBpbiBnaWFudF9jbG9zZSAoKQojNiAgMHhjMDUz MjYwMiBpbiBkZXZmc19jbG9zZSAoKQojNyAgMHhjMDczMTQ3OCBpbiBWT1BfQ0xPU0VfQVBWICgp CiM4ICAweGMwNWZkOWVjIGluIHZuX2Nsb3NlICgpCiM5ICAweGMwNWZkYTk2IGluIHZuX2Nsb3Nl ZmlsZSAoKQojMTAgMHhjMDU1ODczYyBpbiBmZHJvcF9sb2NrZWQgKCkKIzExIDB4YzA1NThiZjgg aW4gY2xvc2VmICgpCiMxMiAweGMwNTU5NzRiIGluIGNsb3NlICgpCiMxMyAweGMwNzFhNzQ1IGlu IHN5c2NhbGwgKCkKIzE0IDB4YzA3MDYwN2YgaW4gWGludDB4ODBfc3lzY2FsbCAoKQojMTUgMHgw MDAwMDAzMyBpbiA/PyAoKQpQcmV2aW91cyBmcmFtZSBpbm5lciB0byB0aGlzIGZyYW1lIChjb3Jy dXB0IHN0YWNrPykKClNob3VsZCBJIHRyeSB0byByZXByb2R1Y2Ugd2l0aCBrZXJuZWwuZGVidWcg PwoKQ2hlZXJzClZpdAo= From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 26 19:03:36 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 439B016A420 for ; Thu, 26 Jan 2006 19:03:36 +0000 (GMT) (envelope-from tdamas@gmail.com) Received: from nproxy.gmail.com (nproxy.gmail.com [64.233.182.197]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9E55443D45 for ; Thu, 26 Jan 2006 19:03:35 +0000 (GMT) (envelope-from tdamas@gmail.com) Received: by nproxy.gmail.com with SMTP id l37so5796nfc for ; Thu, 26 Jan 2006 11:03:01 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=lpfAYjU3JHVtRdMRujO86GzEZLt4XmHG/ksj5klqJeUq9Igeg+8ROL61nk5mxVgoLeJu5QtqTEUbdHKGEMS0cyUkC9M1jf3N6gDP3K0+2JXW4dLQk2PKOjhp3c7Nb0sLlOrom0bKsNE3gRlnvE/DI4KuP1wHWfwNls08qwFEEZ0= Received: by 10.48.108.7 with SMTP id g7mr83460nfc; Thu, 26 Jan 2006 10:31:48 -0800 (PST) Received: by 10.48.210.7 with HTTP; Thu, 26 Jan 2006 10:31:48 -0800 (PST) Message-ID: Date: Thu, 26 Jan 2006 16:31:48 -0200 From: Thiago Damas To: Andrew Thompson In-Reply-To: <20060126172843.GA33764@heff.fud.org.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <20060126172843.GA33764@heff.fud.org.nz> Cc: freebsd-hackers@freebsd.org Subject: Re: if_bridge hangs ifconfig X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2006 19:03:36 -0000 How can I patch my system, 6.0-RELEASE for only this bug? I want to minimize the downtime? Its possible? best regards, Thiago 2006/1/26, Andrew Thompson : > On Thu, Jan 26, 2006 at 02:49:54PM -0200, Thiago Damas wrote: > > I'm having some problems using if_bridge, in FreeBSD 6.0 RELEASE. > > I have the following situation: > > > > When using the command "ifconfig bridge0 deletem vr0", its hangs, > > and sometimes show the error: > > vr0: refusing to decrement non-positive refcount 0for interface flag 25= 6 > > This has been fixed in 6-STABLE and will work in the upcomming 6.1 > release, see the 2005/11/16 entry in > > http://www.freebsd.org/releases/6.0R/errata.html > > I would advise upgrading to RELENG_6. > > > regards, > Andrew > From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 26 19:17:09 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3D4FC16A420 for ; Thu, 26 Jan 2006 19:17:09 +0000 (GMT) (envelope-from thompsa@freebsd.org) Received: from dbmail-mx4.orcon.co.nz (loadbalancer1.orcon.net.nz [219.88.242.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id 983FA43D55 for ; Thu, 26 Jan 2006 19:17:08 +0000 (GMT) (envelope-from thompsa@freebsd.org) Received: from heff.fud.org.nz (60-234-149-201.bitstream.orcon.net.nz [60.234.149.201]) by dbmail-mx4.orcon.co.nz (8.13.5/8.13.5/Debian-3) with ESMTP id k0QJGxZ1029997; Fri, 27 Jan 2006 08:17:00 +1300 Received: by heff.fud.org.nz (Postfix, from userid 1001) id E66971CC1F; Fri, 27 Jan 2006 08:17:05 +1300 (NZDT) Date: Fri, 27 Jan 2006 08:17:05 +1300 From: Andrew Thompson To: Thiago Damas Message-ID: <20060126191705.GB33764@heff.fud.org.nz> References: <20060126172843.GA33764@heff.fud.org.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.11 X-Virus-Scanned: ClamAV 0.88/1252/Fri Jan 27 00:03:25 2006 on dbmail-mx4.orcon.co.nz X-Virus-Status: Clean Cc: freebsd-hackers@freebsd.org Subject: Re: if_bridge hangs ifconfig X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2006 19:17:09 -0000 On Thu, Jan 26, 2006 at 04:31:48PM -0200, Thiago Damas wrote: > 2006/1/26, Andrew Thompson : > > On Thu, Jan 26, 2006 at 02:49:54PM -0200, Thiago Damas wrote: > > > I'm having some problems using if_bridge, in FreeBSD 6.0 RELEASE. > > > I have the following situation: > > > > > > When using the command "ifconfig bridge0 deletem vr0", its hangs, > > > and sometimes show the error: > > > vr0: refusing to decrement non-positive refcount 0for interface flag 256 > > > > This has been fixed in 6-STABLE and will work in the upcomming 6.1 > > release, see the 2005/11/16 entry in > > > > http://www.freebsd.org/releases/6.0R/errata.html > > > > I would advise upgrading to RELENG_6. > > > > How can I patch my system, 6.0-RELEASE for only this bug? I want to > minimize the downtime? Its possible? You can apply this patch http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/net/if_bridge.c.diff?r1=1.32&r2=1.34 If you are using modules then you dont even need to reboot, patch the file, make+install /sys/modules/if_bridge, kldunload+kldload. cheers, Andrew From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 26 19:28:42 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E898116A420; Thu, 26 Jan 2006 19:28:42 +0000 (GMT) (envelope-from julian@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3E09B43D7D; Thu, 26 Jan 2006 19:28:22 +0000 (GMT) (envelope-from julian@elischer.org) Received: from unknown (HELO [10.251.17.229]) ([10.251.17.229]) by a50.ironport.com with ESMTP; 26 Jan 2006 11:28:20 -0800 Message-ID: <43D922D5.1000307@elischer.org> Date: Thu, 26 Jan 2006 11:28:21 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.11) Gecko/20050727 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jose Marcio Martins da Cruz References: <43D74F91.2090009@ensmp.fr> <43D7C786.1090803@elischer.org> <43D7E45E.8070103@ensmp.fr> <43D802DF.9040003@elischer.org> <43D88E69.1020102@ensmp.fr> In-Reply-To: <43D88E69.1020102@ensmp.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, freebsd-threads@freebsd.org Subject: Re: Changes from 5.2.1 to 5.3 (theads / signal handling) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2006 19:28:43 -0000 Jose Marcio Martins da Cruz wrote: >Hello, > >Julian Elischer wrote: > > >>Jose Marcio Martins da Cruz wrote: >> >> > > > >>>>also, does the child do an exec() after forking? >>>> >>>> >>>No. The child gets out the father loop and calls another >>>initialisation function. >>> >>> >>The Posix spec says that after a fork(0 teh child must do almost nothing >>before calling exec() >>and that AT A MAXIMUM it should only call async-safe functions. (i.e. >>functions that can be called from >>within signal handlers). >> >> > >So, if I understood, the better I can do is, instead of letting the child follow >a different path after the fork, he shall better do an exec of another thing and >start a clean process... > > > often what is done is to exec itself again with a different argument to make it know it is the child. why do you need to fork? why not just use more threads? >>There is all sorts of state being kept for the "now non existant" >>threads in that address space. >> >>For example, some of them will still exist if they were stopped in user >>space at the time, >>but some of them will not (if tehy were in the kenrel at teh time). In >>addition, >>the process will now be marked "non threaded" in the kernel, as it now only >>has one kernel thread (as specified by posix) so an attempt to schedule >>another thread >>from user space will lead to unknown behaviour. The child will most likely >>run for a bit and then freeze up or die in some mysterious way. ( sound >>familiar?). >> >> > >Very clear... Even on releases older than 5.3... 8-( > >You clarified a bug which was "harassing" me for a very long time... > >Can you point me a good doc about threads, signals, and such kind of things in >FreeBSD context ? > > I can suggest the threads programming book Programming with POSIX Threads by David R. Butenhof He was the main person behind the posix threads anyhow so he's pretty authoratative. >Thanks very much for all your very helpful hints. > >Jose-Marcio > >_______________________________________________ >freebsd-threads@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-threads >To unsubscribe, send any mail to "freebsd-threads-unsubscribe@freebsd.org" > > From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 26 19:32:19 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6CECD16A420; Thu, 26 Jan 2006 19:32:19 +0000 (GMT) (envelope-from jasone@freebsd.org) Received: from lh.synack.net (lh.synack.net [204.152.188.37]) by mx1.FreeBSD.org (Postfix) with ESMTP id 91A2143D6E; Thu, 26 Jan 2006 19:32:18 +0000 (GMT) (envelope-from jasone@freebsd.org) Received: by lh.synack.net (Postfix, from userid 100) id 6E5455E48EC; Thu, 26 Jan 2006 11:32:18 -0800 (PST) Received: from [192.168.168.203] (moscow-cuda-gen2-68-64-60-20.losaca.adelphia.net [68.64.60.20]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by lh.synack.net (Postfix) with ESMTP id F36F85E48D3; Thu, 26 Jan 2006 11:32:12 -0800 (PST) In-Reply-To: <43D88E69.1020102@ensmp.fr> References: <43D74F91.2090009@ensmp.fr> <43D7C786.1090803@elischer.org> <43D7E45E.8070103@ensmp.fr> <43D802DF.9040003@elischer.org> <43D88E69.1020102@ensmp.fr> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Jason Evans Date: Thu, 26 Jan 2006 11:32:08 -0800 To: Jose Marcio Martins da Cruz X-Mailer: Apple Mail (2.746.2) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on lh.synack.net X-Spam-Level: * X-Spam-Status: No, score=1.8 required=5.0 tests=RCVD_IN_NJABL_DUL, RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: freebsd-hackers@freebsd.org, Julian Elischer , freebsd-threads@freebsd.org Subject: Re: Changes from 5.2.1 to 5.3 (theads / signal handling) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2006 19:32:19 -0000 On Jan 26, 2006, at 12:55 AM, Jose Marcio Martins da Cruz wrote: > Can you point me a good doc about threads, signals, and such kind > of things in > FreeBSD context ? David Butenhof's book, "Programming with POSIX Threads", includes a good discussion of signals in the context of pthreads. How to avoid the problems you have been experiencing is covered in that book. If you haven't read the book, I highly recommend that you do so. Jason From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 26 20:43:10 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2EB7516A420; Thu, 26 Jan 2006 20:43:10 +0000 (GMT) (envelope-from julian@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id E1D5343D45; Thu, 26 Jan 2006 20:43:09 +0000 (GMT) (envelope-from julian@elischer.org) Received: from unknown (HELO [10.251.17.229]) ([10.251.17.229]) by a50.ironport.com with ESMTP; 26 Jan 2006 12:43:09 -0800 Message-ID: <43D9345D.9010205@elischer.org> Date: Thu, 26 Jan 2006 12:43:09 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.11) Gecko/20050727 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jose-Marcio.Martins@ensmp.fr References: <43D74F91.2090009@ensmp.fr> <43D7C786.1090803@elischer.org> <43D7E45E.8070103@ensmp.fr> <43D802DF.9040003@elischer.org> <43D88E69.1020102@ensmp.fr> <43D922D5.1000307@elischer.org> <43D9324A.40905@ensmp.fr> In-Reply-To: <43D9324A.40905@ensmp.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, freebsd-threads@freebsd.org Subject: Re: Changes from 5.2.1 to 5.3 (theads / signal handling) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2006 20:43:10 -0000 Jose Marcio Martins da Cruz wrote: > Julian Elischer wrote: > >> Jose Marcio Martins da Cruz wrote: > > >>> So, if I understood, the better I can do is, instead of letting the >>> child follow >>> a different path after the fork, he shall better do an exec of >>> another thing and >>> start a clean process... >>> >>> >>> >> >> often what is done is to exec itself again with a different argument >> to make it know it is the child. >> >> why do you need to fork? why not just use more threads? > > > This is a security issue. The application is a sendmail mail filter. > For many reasons the filter may die : an attack may succeed or there > may be a bug. > > The father is a supervisor only. He launches the child which is the > real filter. From time to time, the father checks if the filter is > alive and running (not blocked) - this is done by a non blocking wait > and a pipe between the father and the child. If there is a problem > with the child (died of blocked), the father does some clean up and > launches a fresh child. sounds like the parent need not be threaded yet. > > I use a different process instead of more threads because a problem > with a thread can compromise all the process. > > This application runs fine under Solaris (four years long now). Each implementation has different side-effects On FreeBSD 6, try the libthr() threading library. > > Well, I definitely shall try to change this architecture, at least for > FreeBSD and maybe Linux too. > >> >> I can suggest the threads programming book >> Programming with POSIX Threads >> by >> David R. Butenhof > > > Thanks, I have it. I read it long time ago... > > > From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 26 23:03:32 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9A09E16A420 for ; Thu, 26 Jan 2006 23:03:32 +0000 (GMT) (envelope-from kurt@intricatesoftware.com) Received: from mta4.srv.hcvlny.cv.net (mta4.srv.hcvlny.cv.net [167.206.4.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1C34C43D4C for ; Thu, 26 Jan 2006 23:03:32 +0000 (GMT) (envelope-from kurt@intricatesoftware.com) Received: from [172.16.1.72] (ool-457a77e8.dyn.optonline.net [69.122.119.232]) by mta4.srv.hcvlny.cv.net (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTP id <0ITQ00M9P2PU55V0@mta4.srv.hcvlny.cv.net> for freebsd-hackers@freebsd.org; Thu, 26 Jan 2006 18:03:31 -0500 (EST) Date: Thu, 26 Jan 2006 18:03:30 -0500 From: Kurt Miller To: freebsd-hackers@freebsd.org Message-id: <200601261803.30503.kurt@intricatesoftware.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline User-Agent: KMail/1.9 X-Mailman-Approved-At: Thu, 26 Jan 2006 23:24:02 +0000 Subject: read hang on datagram socket X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2006 23:03:32 -0000 I'm working on 1.5 jdk certification on 5.4 and 6.0. One of the jck tests hangs on 5.4 but works ok on 6.0. I've reduced the problem down to the following C program that hangs on 5.4 but works fine (finishes) on 6.0 and 4.11. I could use some assistance with finding a work-around to the problem or an explanation as to why the program hangs on 5.4. Thank you, -Kurt #include #include #include #include #include #include #include void buildAddr4(struct sockaddr_in *addr4, int address, short port) { memset((char *) addr4, 0, sizeof(struct sockaddr_in)); addr4->sin_port = htons(port); addr4->sin_addr.s_addr = (uint32_t) htonl(address); addr4->sin_family = AF_INET; } void setAddress(struct sockaddr_in *addr4, int address) { addr4->sin_addr.s_addr = (uint32_t) htonl(address); } int getHostAddress() { char hostname[MAXHOSTNAMELEN]; struct addrinfo hints, *res; int address = 0; if (gethostname(hostname, MAXHOSTNAMELEN) != 0) exit(1); memset(&hints, 0, sizeof(hints)); hints.ai_flags = AI_CANONNAME; hints.ai_family = AF_INET; if(getaddrinfo(hostname, "domain", &hints, &res) != 0) exit(1); while( res != NULL ) { if (res->ai_family == AF_INET) { address = ntohl(((struct sockaddr_in*)(res->ai_addr))->sin_addr.s_addr); break; } res = res->ai_next; } return address; } int main() { int sock1, sock2; int optval = 1; struct sockaddr addr; struct sockaddr sock1Addr, sock2Addr; int sock1AddrLen, sock2AddrLen; short port1, port2; char sendBuf, readBuf; int hostAddress; if ((hostAddress = getHostAddress()) == 0) exit(1); buildAddr4((struct sockaddr_in *)&addr, 0, 0); if ((sock1 = socket(AF_INET, SOCK_DGRAM, 0)) < 0) exit(1); if (setsockopt(sock1, SOL_SOCKET, SO_BROADCAST, (char*) &optval, sizeof(optval)) != 0) exit(1); if (bind(sock1, (struct sockaddr *)&addr, sizeof(struct sockaddr_in)) != 0) exit(1); if (getsockname(sock1, &sock1Addr, &sock1AddrLen) != 0) exit(1); setAddress((struct sockaddr_in *)&sock1Addr, hostAddress); if ((sock2 = socket(AF_INET, SOCK_DGRAM, 0)) < 0) exit(1); if (bind(sock2, (struct sockaddr *)&addr, sizeof(struct sockaddr_in)) != 0) exit(1); if (getsockname(sock2, &sock2Addr, &sock2AddrLen) != 0) exit(1); setAddress((struct sockaddr_in *)&sock2Addr, hostAddress); if (connect(sock2, &sock1Addr, sock1AddrLen) != 0) exit(1); sendBuf = 22; if (sendto(sock1, &sendBuf, 1, 0, &sock2Addr, sock2AddrLen) != 1) exit(1); if (read(sock2, &readBuf, 1) != 1) exit(1); printf("no hang\n"); } From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 26 23:26:30 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 02C6616A46B for ; Thu, 26 Jan 2006 23:26:30 +0000 (GMT) (envelope-from lists@intricatesoftware.com) Received: from mta2.srv.hcvlny.cv.net (mta2.srv.hcvlny.cv.net [167.206.4.197]) by mx1.FreeBSD.org (Postfix) with ESMTP id A532743D6D for ; Thu, 26 Jan 2006 23:26:23 +0000 (GMT) (envelope-from lists@intricatesoftware.com) Received: from [172.16.1.72] (ool-457a77e8.dyn.optonline.net [69.122.119.232]) by mta2.srv.hcvlny.cv.net (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTP id <0ITQ00EOY3QNOPJ0@mta2.srv.hcvlny.cv.net> for freebsd-hackers@freebsd.org; Thu, 26 Jan 2006 18:25:35 -0500 (EST) Resent-date: Thu, 26 Jan 2006 18:25:11 -0500 Date: Thu, 26 Jan 2006 18:25:34 -0500 Resent-from: Kurt Miller From: Kurt Miller Resent-to: freebsd-hackers@freebsd.org To: freebsd-hackers@freebsd.org Resent-message-id: <200601261825.11402.kurt@intricatesoftware.com> Message-id: <200601261803.30503.kurt@intricatesoftware.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline User-Agent: KMail/1.9 Subject: read hang on datagram socket X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2006 23:26:30 -0000 I'm working on 1.5 jdk certification on 5.4 and 6.0. One of the jck tests hangs on 5.4 but works ok on 6.0. I've reduced the problem down to the following C program that hangs on 5.4 but works fine (finishes) on 6.0 and 4.11. I could use some assistance with finding a work-around to the problem or an explanation as to why the program hangs on 5.4. Thank you, -Kurt #include #include #include #include #include #include #include void buildAddr4(struct sockaddr_in *addr4, int address, short port) { memset((char *) addr4, 0, sizeof(struct sockaddr_in)); addr4->sin_port = htons(port); addr4->sin_addr.s_addr = (uint32_t) htonl(address); addr4->sin_family = AF_INET; } void setAddress(struct sockaddr_in *addr4, int address) { addr4->sin_addr.s_addr = (uint32_t) htonl(address); } int getHostAddress() { char hostname[MAXHOSTNAMELEN]; struct addrinfo hints, *res; int address = 0; if (gethostname(hostname, MAXHOSTNAMELEN) != 0) exit(1); memset(&hints, 0, sizeof(hints)); hints.ai_flags = AI_CANONNAME; hints.ai_family = AF_INET; if(getaddrinfo(hostname, "domain", &hints, &res) != 0) exit(1); while( res != NULL ) { if (res->ai_family == AF_INET) { address = ntohl(((struct sockaddr_in*)(res->ai_addr))->sin_addr.s_addr); break; } res = res->ai_next; } return address; } int main() { int sock1, sock2; int optval = 1; struct sockaddr addr; struct sockaddr sock1Addr, sock2Addr; int sock1AddrLen, sock2AddrLen; short port1, port2; char sendBuf, readBuf; int hostAddress; if ((hostAddress = getHostAddress()) == 0) exit(1); buildAddr4((struct sockaddr_in *)&addr, 0, 0); if ((sock1 = socket(AF_INET, SOCK_DGRAM, 0)) < 0) exit(1); if (setsockopt(sock1, SOL_SOCKET, SO_BROADCAST, (char*) &optval, sizeof(optval)) != 0) exit(1); if (bind(sock1, (struct sockaddr *)&addr, sizeof(struct sockaddr_in)) != 0) exit(1); if (getsockname(sock1, &sock1Addr, &sock1AddrLen) != 0) exit(1); setAddress((struct sockaddr_in *)&sock1Addr, hostAddress); if ((sock2 = socket(AF_INET, SOCK_DGRAM, 0)) < 0) exit(1); if (bind(sock2, (struct sockaddr *)&addr, sizeof(struct sockaddr_in)) != 0) exit(1); if (getsockname(sock2, &sock2Addr, &sock2AddrLen) != 0) exit(1); setAddress((struct sockaddr_in *)&sock2Addr, hostAddress); if (connect(sock2, &sock1Addr, sock1AddrLen) != 0) exit(1); sendBuf = 22; if (sendto(sock1, &sendBuf, 1, 0, &sock2Addr, sock2AddrLen) != 1) exit(1); if (read(sock2, &readBuf, 1) != 1) exit(1); printf("no hang\n"); } From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 26 23:34:40 2006 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5C48716A422 for ; Thu, 26 Jan 2006 23:34:40 +0000 (GMT) (envelope-from ambrisko@ambrisko.com) Received: from mail.ambrisko.com (mail.ambrisko.com [64.174.51.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id 03B8843D58 for ; Thu, 26 Jan 2006 23:34:37 +0000 (GMT) (envelope-from ambrisko@ambrisko.com) Received: from server2.ambrisko.com (HELO www.ambrisko.com) ([192.168.1.2]) by mail.ambrisko.com with ESMTP; 26 Jan 2006 15:34:37 -0800 Received: from ambrisko.com (localhost [127.0.0.1]) by www.ambrisko.com (8.12.11/8.12.9) with ESMTP id k0QNYbJQ004174; Thu, 26 Jan 2006 15:34:37 -0800 (PST) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.12.11/8.12.11/Submit) id k0QNYbuS004173; Thu, 26 Jan 2006 15:34:37 -0800 (PST) (envelope-from ambrisko) From: Doug Ambrisko Message-Id: <200601262334.k0QNYbuS004173@ambrisko.com> In-Reply-To: <806128ad0601260254u42dfd927k@mail.gmail.com> To: Vitaliy Skakun Date: Thu, 26 Jan 2006 15:34:37 -0800 (PST) X-Mailer: ELM [version 2.4ME+ PL94b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Cc: hackers@freebsd.org Subject: Re: Comtrol Rocketport UNIVERSAL PCI 32-port X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2006 23:34:40 -0000 Vitaliy Skakun writes: | Hi everybody! | | One problem arised: | | when doing in the shell | echo "~WS" > /dev/cuaR00 | | for several times as quick as I can, I get panic with the following message: | panic: device_unbusy: called for non-busy device rp0 | | same thing when trying to send data to /dev/cuaR00 via JDK File streams ... | :((( | | (Some kind of barcode printers are attached to this multiport card) | | Any help will be kindly accepted. If you want you can try: Index: rp.c =================================================================== RCS file: /home/ncvs/src/sys/dev/rp/rp.c,v retrieving revision 1.71 diff -u -p -r1.71 rp.c --- rp.c 4 Dec 2005 10:06:04 -0000 1.71 +++ rp.c 26 Jan 2006 23:33:19 -0000 @@ -32,20 +32,23 @@ */ #include -__FBSDID("$FreeBSD: src/sys/dev/rp/rp.c,v 1.71 2005/12/04 10:06:04 ru Exp $"); +__FBSDID("$FreeBSD: src/sys/dev/rp/rp.c,v 1.69 2005/10/16 20:35:05 phk Exp $"); -/* +/* * rp.c - for RocketPort FreeBSD */ +#include #include "opt_compat.h" #include +#include #include #include #include #include #include +#include #include #include #include @@ -57,7 +60,7 @@ __FBSDID("$FreeBSD: src/sys/dev/rp/rp.c, #include #include -static const char RocketPortVersion[] = "3.02"; +static const char RocketPortVersion[] = "1.0"; static Byte_t RData[RDATASIZE] = { @@ -116,6 +119,8 @@ Byte_t rp_sBitMapSetTbl[8] = 0x01,0x02,0x04,0x08,0x10,0x20,0x40,0x80 }; +int next_unit_number = 0; +int num_devices_found = 0; /*************************************************************************** Function: sReadAiopID Purpose: Read the AIOP idenfication number directly from an AIOP. @@ -587,6 +592,9 @@ static void rp_do_receive(struct rp_port unsigned int CharNStat; int ToRecv, wRecv, ch, ttynocopy; + if (tp->t_state & TS_TBLOCK) + return; + ToRecv = sGetRxCnt(cp); if(ToRecv == 0) return; @@ -615,7 +623,7 @@ static void rp_do_receive(struct rp_port CharNStat = rp_readch2(cp,sGetTxRxDataIO(cp)); ch = CharNStat & 0xff; - if((CharNStat & STMBREAK) || (CharNStat & STMFRAMEH)) + if((CharNStat & STMBREAKH) || (CharNStat & STMFRAMEH)) ch |= TTY_FE; else if (CharNStat & STMPARITYH) ch |= TTY_PE; @@ -645,6 +653,12 @@ static void rp_do_receive(struct rp_port if ( ToRecv > RXFIFO_SIZE ) { ToRecv = RXFIFO_SIZE; } + if ((tp->t_rawq.c_cc + ToRecv > tp->t_ihiwat) && + ((tp->t_cflag & CRTS_IFLOW) || + (tp->t_iflag & IXOFF)) && + !(tp->t_state & TS_TBLOCK)) + ttyblock(tp); + wRecv = ToRecv >> 1; if ( wRecv ) { rp_readmultich2(cp,sGetTxRxDataIO(cp),(u_int16_t *)rp->RxBuf,wRecv); @@ -686,6 +700,7 @@ static void rp_handle_port(struct rp_por IntMask = sGetChanIntID(cp); IntMask = IntMask & rp->rp_intmask; ChanStatus = sGetChanStatus(cp); + if(IntMask & RXF_TRIG) if(!(tp->t_state & TS_TBLOCK) && (tp->t_state & TS_CARR_ON) && (tp->t_state & TS_ISOPEN)) { rp_do_receive(rp, tp, cp, ChanStatus); @@ -752,7 +767,7 @@ static void rp_do_poll(void *not_used) } } if(rp_num_ports_open) - rp_callout_handle = timeout(rp_do_poll, + rp_callout_handle = timeout(rp_do_poll, (void *)NULL, POLL_INTERVAL); } @@ -769,22 +784,23 @@ rp_attachcommon(CONTROLLER_T *ctlp, int unit = device_get_unit(ctlp->dev); - printf("RocketPort%d (Version %s) %d ports.\n", unit, - RocketPortVersion, num_ports); + printf("RocketPort%d = %d ports.\n", unit, num_ports); rp_num_ports[unit] = num_ports; callout_handle_init(&rp_callout_handle); ctlp->rp = rp = (struct rp_port *) - malloc(sizeof(struct rp_port) * num_ports, M_TTYS, M_NOWAIT | M_ZERO); + malloc(sizeof(struct rp_port) * (num_ports+1), M_TTYS, M_NOWAIT | M_ZERO); if (rp == NULL) { device_printf(ctlp->dev, "rp_attachcommon: Could not malloc rp_ports structures.\n"); retval = ENOMEM; goto nogo; } - +/* else { + device_printf(ctlp->dev, "malloc'd rp_ports structures=%08x.\n", rp); + }*/ count = unit * 32; /* board times max ports per card SG */ - bzero(rp, sizeof(struct rp_port) * num_ports); + bzero(rp, sizeof(struct rp_port) * (num_ports+1)); oldspl = spltty(); rp_addr(unit) = rp; splx(oldspl); @@ -926,7 +942,7 @@ rpopen(struct tty *tp, struct cdev *dev) ChanStatus = sGetChanStatus(&rp->rp_channel); if(rp_num_ports_open == 1) - rp_callout_handle = timeout(rp_do_poll, + rp_callout_handle = timeout(rp_do_poll, (void *)NULL, POLL_INTERVAL); device_busy(rp->rp_ctlp->dev); @@ -1015,9 +1031,10 @@ rpmodem(struct tty *tp, int sigon, int s } return (0); } - +#define B460800 460800 +#define B921600 921600 static struct speedtab baud_table[] = { - {B0, 0}, {B50, BRD50}, {B75, BRD75}, + {B0, BRD0}, {B50, BRD50}, {B75, BRD75}, {B110, BRD110}, {B134, BRD134}, {B150, BRD150}, {B200, BRD200}, {B300, BRD300}, {B600, BRD600}, {B1200, BRD1200}, {B1800, BRD1800}, {B2400, BRD2400}, @@ -1028,6 +1045,18 @@ static struct speedtab baud_table[] = { {-1, -1} }; +static struct speedtab ab_baud_table[] = { + {B0, AB_BRD0}, {B50, AB_BRD50}, {B75, AB_BRD75}, + {B110, AB_BRD110}, {B134, AB_BRD134}, {B150, AB_BRD150}, + {B200, AB_BRD200}, {B300, AB_BRD300}, {B600, AB_BRD600}, + {B1200, AB_BRD1200}, {B1800, AB_BRD1800}, {B2400, AB_BRD2400}, + {B4800, AB_BRD4800}, {B9600, AB_BRD9600}, {B19200, AB_BRD19200}, + {B38400, AB_BRD38400}, {B7200, AB_BRD7200}, {B14400, AB_BRD14400}, + {B57600, AB_BRD57600}, {B76800, AB_BRD76800}, {B115200, AB_BRD115200}, + {B230400,AB_BRD230400}, {B460800,AB_BRD460800}, {B921600, AB_BRD921600}, + {-1, -1} +}; + static int rpparam(tp, t) struct tty *tp; @@ -1041,7 +1070,6 @@ rpparam(tp, t) int devshift; #endif - rp = tp->t_sc; cp = &rp->rp_channel; oldspl = spltty(); @@ -1058,7 +1086,10 @@ rpparam(tp, t) oflag = t->c_oflag; lflag = t->c_lflag; - ospeed = ttspeedtab(t->c_ispeed, baud_table); + if (cardIsRocketportPlus(rp->rp_ctlp->dev)) + ospeed = ttspeedtab(t->c_ispeed, ab_baud_table); + else + ospeed = ttspeedtab(t->c_ispeed, baud_table); if(ospeed < 0 || t->c_ispeed != t->c_ospeed) return(EINVAL); Index: rp_isa.c =================================================================== RCS file: /home/ncvs/src/sys/dev/rp/rp_isa.c,v retrieving revision 1.8 diff -u -p -r1.8 rp_isa.c --- rp_isa.c 4 Dec 2005 10:06:04 -0000 1.8 +++ rp_isa.c 26 Jan 2006 23:33:19 -0000 @@ -35,7 +35,7 @@ */ #include -__FBSDID("$FreeBSD: src/sys/dev/rp/rp_isa.c,v 1.8 2005/12/04 10:06:04 ru Exp $"); +__FBSDID("$FreeBSD: src/sys/dev/rp/rp_isa.c,v 1.7 2005/01/06 01:43:11 imp Exp $"); #include #include @@ -63,8 +63,8 @@ struct ISACONTROLLER_T { int MReg1IO; /* offset1 of the Mudbac controller for this controller */ int MReg2IO; /* offset2 of the Mudbac controller for this controller */ int MReg3IO; /* offset3 of the Mudbac controller for this controller */ - Byte_t MReg2; - Byte_t MReg3; + unsigned char MReg2; + unsigned char MReg3; }; typedef struct ISACONTROLLER_T ISACONTROLLER_t; @@ -140,6 +140,12 @@ static rp_aiop2rid_t rp_isa_aiop2rid; static rp_aiop2off_t rp_isa_aiop2off; static rp_ctlmask_t rp_isa_ctlmask; +/* +struct isa_driver rpdriver = { + rpprobe, rpattach, "rp" + }; +*/ + static int rp_probe(device_t dev) { @@ -149,6 +155,9 @@ rp_probe(device_t dev) CONTROLLER_t *ctlp; int retval; + if (num_devices_found >= 4) + return (ENXIO); + /* * We have no PnP RocketPort cards. * (At least according to LINT) @@ -156,8 +165,8 @@ rp_probe(device_t dev) if (isa_get_logicalid(dev) != 0) return (ENXIO); - /* We need IO port resource to configure an ISA device. */ - if (bus_get_resource_count(dev, SYS_RES_IOPORT, 0) == 0) + /* We need IO port resource to configure an ISA device. */ + if (bus_get_resource_start(dev, SYS_RES_IOPORT, 0) == 0) return (ENXIO); unit = device_get_unit(dev); @@ -176,20 +185,23 @@ rp_probe(device_t dev) /* The IO ports of AIOPs for an ISA controller are discrete. */ ctlp->io_num = 1; - ctlp->io_rid = malloc(sizeof(*(ctlp->io_rid)) * MAX_AIOPS_PER_BOARD, M_DEVBUF, M_NOWAIT | M_ZERO); - ctlp->io = malloc(sizeof(*(ctlp->io)) * MAX_AIOPS_PER_BOARD, M_DEVBUF, M_NOWAIT | M_ZERO); + ctlp->io_rid = malloc(sizeof(*(ctlp->io_rid)) * MAX_AIOPS_PER_BOARD, M_DEVBUF, M_NOWAIT/* | M_ZERO*/); + ctlp->io = malloc(sizeof(*(ctlp->io)) * MAX_AIOPS_PER_BOARD, M_DEVBUF, M_NOWAIT/* | M_ZERO*/); if (ctlp->io_rid == NULL || ctlp->io == NULL) { device_printf(dev, "rp_attach: Out of memory.\n"); retval = ENOMEM; goto nogo; } + bzero(ctlp->io_rid, sizeof(*(ctlp->io_rid)) * MAX_AIOPS_PER_BOARD); + bzero(ctlp->io, sizeof(*(ctlp->io)) * MAX_AIOPS_PER_BOARD); - ctlp->bus_ctlp = malloc(sizeof(ISACONTROLLER_t) * 1, M_DEVBUF, M_NOWAIT | M_ZERO); + ctlp->bus_ctlp = malloc(sizeof(ISACONTROLLER_t) * 1, M_DEVBUF, M_NOWAIT/* | M_ZERO*/); if (ctlp->bus_ctlp == NULL) { device_printf(dev, "rp_attach: Out of memory.\n"); retval = ENOMEM; goto nogo; } + bzero(ctlp->bus_ctlp, sizeof(ISACONTROLLER_t) * 1); ctlp->io_rid[0] = 0; if (rp_controller != NULL) { @@ -218,6 +230,7 @@ rp_probe(device_t dev) if (rp_controller == NULL) rp_controller = controller; rp_nisadevs++; + num_devices_found++; device_set_desc(dev, "RocketPort ISA"); @@ -416,7 +429,7 @@ sInitController( CONTROLLER_T *CtlP, CtlP->NumAiop = 0; for(i=0; i < AiopNum; i++) { - if (CtlP->io[i] == NULL) { + if (i > 0 /*CtlP->io[i] == NULL*/) { CtlP->io_rid[i] = i; aiop_base = rman_get_start(CtlP->io[0]) + 0x400 * i; if (rp_nisadevs == 0) Index: rp_pci.c =================================================================== RCS file: /home/ncvs/src/sys/dev/rp/rp_pci.c,v retrieving revision 1.13 diff -u -p -r1.13 rp_pci.c --- rp_pci.c 25 Jan 2006 14:55:11 -0000 1.13 +++ rp_pci.c 26 Jan 2006 23:33:19 -0000 @@ -67,8 +67,19 @@ __FBSDID("$FreeBSD: src/sys/dev/rp/rp_pc #define RP_DEVICE_ID_4J 0x0007 #define RP_DEVICE_ID_6M 0x000C #define RP_DEVICE_ID_4M 0x000D -#define RP_DEVICE_ID_UPCI_32 0x0801 -#define RP_DEVICE_ID_UPCI_8O 0x0805 +#define RP_DEVICE_ID_PL4 0x000A +#define RP_DEVICE_ID_PL8 0x000B +#define RP_DEVICE_ID_PL2 0x000E +#define RP_DEVICE_ID_U32 0x0801 +#define RP_DEVICE_ID_U8PL 0x0802 +#define RP_DEVICE_ID_U16 0x0803 +#define RP_DEVICE_ID_U8QO 0x0805 +#define RP_DEVICE_ID_UP8QO 0x080B +#define RP_DEVICE_ID_UP2 0x080E +#define RP_DEVICE_ID_UP2SMPTE 0x080F +#define RP_DEVICE_ID_UP4J 0x0810 +#define RP_DEVICE_ID_UP8J 0x0811 +#define RP_DEVICE_ID_UP422QO 0x0812 /************************************************************************** MUDBAC remapped for PCI @@ -76,9 +87,20 @@ __FBSDID("$FreeBSD: src/sys/dev/rp/rp_pc #define _CFG_INT_PCI 0x40 #define _PCI_INT_FUNC 0x3A +#define _UPCI_INT_FUNC 0x4 #define PCI_STROB 0x2000 +#define UPCI_STROB_C 0x0000 +#define UPCI_STROB_S 0x0001 + #define INTR_EN_PCI 0x0010 +#define INTR_EN_UPCI 0x0081 + +#define _UPCI_GPIO 0x54 +#define _UPCI_QUAD_IN 0x0000 +#define _UPCI_OCTAL_IN 0x4000 + +#define _UPCI_RING_IND 0xc /*************************************************************************** Function: sPCIControllerEOI @@ -101,6 +123,40 @@ Return: Byte_t: The controller interru */ #define sPCIGetControllerIntStatus(CTLP) ((rp_readio2(CTLP, 0, _PCI_INT_FUNC) >> 8) & 0x1f) +/*************************************************************************** + * Returns the state of RI. The following products have RI: + * UPCI 4/8 port, RP Plus 4/8 port, RP Plus 2 port 232/422 + * For all other devices, this function returns 0. + * + * Returns: 1 if RI is set, else 0. + */ +int sGetChanRI(CHANNEL_T * ChP) +{ + CONTROLLER_t *CtlP = ChP->CtlP; + int ChanNum = ChP->ChanNum; + int RingInd; + + switch (pci_get_device(CtlP->dev)) { + case RP_DEVICE_ID_U32: + case RP_DEVICE_ID_U8PL: + case RP_DEVICE_ID_U16: + case RP_DEVICE_ID_U8QO: + RingInd = !(rp_readio1(CtlP, 0, _UPCI_RING_IND) & rp_sBitMapSetTbl[ChanNum]); + break; + case RP_DEVICE_ID_PL4: + case RP_DEVICE_ID_PL8: + case RP_DEVICE_ID_PL2: + case RP_DEVICE_ID_UP8QO: + case RP_DEVICE_ID_UP2: + RingInd = rp_readch1(ChP, ((ChanNum * 2) + (_CHN_STAT0 + 8))) & DSR_ACT; + break; + default: + RingInd = 0; + } + + return RingInd; +} + static devclass_t rp_devclass; static int rp_pciprobe(device_t dev); @@ -115,7 +171,7 @@ static int sPCIInitController( CONTROLLE int IRQNum, Byte_t Frequency, int PeriodicOnly, - int VendorDevice); + uint16_t VendorDevice); static rp_aiop2rid_t rp_pci_aiop2rid; static rp_aiop2off_t rp_pci_aiop2off; static rp_ctlmask_t rp_pci_ctlmask; @@ -129,12 +185,88 @@ static int rp_pciprobe(device_t dev) { char *s; + uint16_t VenDev; - s = NULL; - if (pci_get_vendor(dev) == RP_VENDOR_ID) - s = "RocketPort PCI"; + if (num_devices_found >= 4) + return ENXIO; + s = NULL; + if (pci_get_vendor(dev) == RP_VENDOR_ID) { + VenDev = pci_get_device(dev); + switch( VenDev ) { + case RP_DEVICE_ID_4Q: + s = "RocketPort PCI Quad"; + break; + case RP_DEVICE_ID_4J: + s = "RocketPort PCI 4J"; + break; + case RP_DEVICE_ID_4M: + s = "RocketModem II PCI 4"; + break; + case RP_DEVICE_ID_PL4: + s = "RocketPort Plus PCI Quad"; + break; + case RP_DEVICE_ID_6M: + s = "RocketModem II PCI 6"; + break; + case RP_DEVICE_ID_8O: + s = "RocketPort PCI Octa"; + break; + case RP_DEVICE_ID_8J: + s = "RocketPort PCI 8J"; + break; + case RP_DEVICE_ID_8I: + s = "RocketPort PCI 8"; + break; + case RP_DEVICE_ID_U8PL: + s = "RocketPort Universal PCI 8 Low Profile"; + break; + case RP_DEVICE_ID_U8QO: + s = "RocketPort Universal PCI Quad/Octa"; + break; + case RP_DEVICE_ID_16I: + s = "RocketPort PCI 16"; + break; + case RP_DEVICE_ID_U16: + s = "RocketPort Universal PCI 16"; + break; + case RP_DEVICE_ID_32I: + s = "RocketPort PCI 32"; + break; + case RP_DEVICE_ID_U32: + s = "RocketPort Universal PCI 32"; + break; + case RP_DEVICE_ID_PL8: + s = "RocketPort Plus PCI Octa"; + break; + case RP_DEVICE_ID_PL2: + s = "RocketPort Plus PCI 2"; + break; + case RP_DEVICE_ID_UP8QO: + s = "RocketPort Plus Universal PCI Quad/Octa"; + break; + case RP_DEVICE_ID_UP2: + s = "RocketPort Plus Universal PCI 2"; + break; + case RP_DEVICE_ID_UP2SMPTE: + s = "RocketPort Plus Universal PCI 2 SMPTE"; + break; + case RP_DEVICE_ID_UP4J: + s = "RocketPort Plus Universal PCI 4J"; + break; + case RP_DEVICE_ID_UP8J: + s = "RocketPort Plus Universal PCI 8J"; + break; + case RP_DEVICE_ID_UP422QO: + s = "RocketPort Plus Universal PCI 422 Quad/Octa"; + break; + default: + s = NULL; + break; + } + } if (s != NULL) { + num_devices_found++; device_set_desc(dev, s); return (BUS_PROBE_DEFAULT); } @@ -150,10 +282,14 @@ rp_pciattach(device_t dev) CONTROLLER_t *ctlp; int unit; int retval; - u_int32_t stcmd; + uint32_t stcmd; + uint16_t VenDev; + VenDev = pci_get_device(dev); ctlp = device_get_softc(dev); bzero(ctlp, sizeof(*ctlp)); + + ctlp->CtlID = CTLID_0001; /* controller type 1 */ ctlp->dev = dev; unit = device_get_unit(dev); ctlp->aiop2rid = rp_pci_aiop2rid; @@ -168,37 +304,47 @@ rp_pciattach(device_t dev) } /* The IO ports of AIOPs for a PCI controller are continuous. */ - ctlp->io_num = 1; - ctlp->io_rid = malloc(sizeof(*(ctlp->io_rid)) * ctlp->io_num, M_DEVBUF, M_NOWAIT | M_ZERO); - ctlp->io = malloc(sizeof(*(ctlp->io)) * ctlp->io_num, M_DEVBUF, M_NOWAIT | M_ZERO); + if (cardIsUPCI(ctlp->dev)) /* if RocketPort UPCI with PLX chip */ + ctlp->io_num = 2; /* then setup two base addresses */ + else + ctlp->io_num = 1; /* or just setup one base address */ + ctlp->io_rid = malloc(sizeof(*(ctlp->io_rid)) * ctlp->io_num, M_DEVBUF, M_NOWAIT/* | M_ZERO*/); + ctlp->io = malloc(sizeof(*(ctlp->io)) * ctlp->io_num, M_DEVBUF, M_NOWAIT/* | M_ZERO*/); if (ctlp->io_rid == NULL || ctlp->io == NULL) { device_printf(dev, "rp_pciattach: Out of memory.\n"); retval = ENOMEM; goto nogo; } + bzero(ctlp->io_rid, sizeof(*(ctlp->io_rid)) * ctlp->io_num); + bzero(ctlp->io, sizeof(*(ctlp->io)) * ctlp->io_num); ctlp->bus_ctlp = NULL; - switch (pci_get_device(dev)) { - case RP_DEVICE_ID_UPCI_32: - case RP_DEVICE_ID_UPCI_8O: - ctlp->io_rid[0] = PCIR_BAR(2); - break; - default: - ctlp->io_rid[0] = PCIR_BAR(0); - break; + if (cardIsUPCI(ctlp->dev)) { /* if RocketPort UPCI with PLX chip */ + ctlp->io_rid[0] = 0x18; /* then setup two base addresses */ + ctlp->io_rid[1] = 0x14; + } + else { + ctlp->io_rid[0] = 0x10; /* or just setup one base address */ } - ctlp->io[0] = bus_alloc_resource_any(dev, SYS_RES_IOPORT, - &ctlp->io_rid[0], RF_ACTIVE); + + ctlp->io[0] = bus_alloc_resource_any(dev, SYS_RES_IOPORT, &ctlp->io_rid[0], RF_ACTIVE); + /*device_printf(dev, "ioaddr (%x) mapping for RocketPort(PCI) is %08x.\n", ctlp->io_rid[0], ctlp->io[0]);*/ if(ctlp->io[0] == NULL) { device_printf(dev, "ioaddr mapping failed for RocketPort(PCI).\n"); retval = ENXIO; goto nogo; } - - num_aiops = sPCIInitController(ctlp, - MAX_AIOPS_PER_BOARD, 0, - FREQ_DIS, 0, pci_get_device(dev)); + if (cardIsUPCI(ctlp->dev)) { /* if RocketPort UPCI with PLX chip */ + ctlp->io[1] = bus_alloc_resource(dev, SYS_RES_IOPORT, &ctlp->io_rid[1], 0, ~0, 1, RF_ACTIVE); + /*device_printf(dev, "ioaddr (%x) mapping for RocketPort(UPCI) is %08x.\n", ctlp->io_rid[1], ctlp->io[1]);*/ + if(ctlp->io[1] == NULL) { + device_printf(dev, "ioaddr mapping failed for RocketPort(UPCI).\n"); + retval = ENXIO; + goto nogo; + } + } + num_aiops = sPCIInitController(ctlp, MAX_AIOPS_PER_BOARD, 0, FREQ_DIS, 0, VenDev); num_ports = 0; for(aiop=0; aiop < num_aiops; aiop++) { @@ -271,14 +417,68 @@ sPCIInitController( CONTROLLER_t *CtlP, int IRQNum, Byte_t Frequency, int PeriodicOnly, - int VendorDevice) + uint16_t VendorDevice) { - int i; + int i, AiopChanCnt, gpio_dat; - CtlP->CtlID = CTLID_0001; /* controller release 1 */ - - sPCIControllerEOI(CtlP); + if (cardIsUPCI(CtlP->dev)) /* if RocketPort UPCI with PLX chip */ + rp_writeio2(CtlP, 1, _UPCI_INT_FUNC, 0x0000); /* disable ints */ + else + sPCIControllerEOI(CtlP); + switch( VendorDevice ) { + case RP_DEVICE_ID_4Q: + case RP_DEVICE_ID_4J: + case RP_DEVICE_ID_4M: + case RP_DEVICE_ID_PL4: + case RP_DEVICE_ID_UP4J: + AiopChanCnt = 4; + AiopNum = 1; + break; + case RP_DEVICE_ID_6M: + AiopChanCnt = 6; + AiopNum = 1; + break; + case RP_DEVICE_ID_8O: + case RP_DEVICE_ID_8J: + case RP_DEVICE_ID_8I: + case RP_DEVICE_ID_U8PL: + case RP_DEVICE_ID_U8QO: + AiopNum = 1; + AiopChanCnt = 8; + break; + case RP_DEVICE_ID_16I: + case RP_DEVICE_ID_U16: + AiopNum = 2; + AiopChanCnt = 8; + break; + case RP_DEVICE_ID_32I: + case RP_DEVICE_ID_U32: + AiopNum = 4; + AiopChanCnt = 8; + break; + case RP_DEVICE_ID_PL8: + case RP_DEVICE_ID_UP8J: + case RP_DEVICE_ID_UP8QO: + case RP_DEVICE_ID_UP422QO: + AiopNum = 2; + AiopChanCnt = 4; + break; + case RP_DEVICE_ID_PL2: + case RP_DEVICE_ID_UP2: + case RP_DEVICE_ID_UP2SMPTE: + AiopNum = 1; + AiopChanCnt = 2; + break; + default: + AiopNum = 1; +#if notdef + AiopChanCnt = 8; +#else + AiopChanCnt = sReadAiopNumChan(CtlP, 0); +#endif /* notdef */ + break; + } /* Init AIOPs */ CtlP->NumAiop = 0; for(i=0; i < AiopNum; i++) @@ -290,39 +490,24 @@ sPCIInitController( CONTROLLER_t *CtlP, { break; /* done looking for AIOPs */ } - - switch( VendorDevice ) { - case RP_DEVICE_ID_4Q: - case RP_DEVICE_ID_4J: - case RP_DEVICE_ID_4M: - CtlP->AiopNumChan[i] = 4; - break; - case RP_DEVICE_ID_6M: - CtlP->AiopNumChan[i] = 6; - break; - case RP_DEVICE_ID_8O: - case RP_DEVICE_ID_8J: - case RP_DEVICE_ID_8I: - case RP_DEVICE_ID_16I: - case RP_DEVICE_ID_32I: - CtlP->AiopNumChan[i] = 8; - break; - default: -#ifdef notdef - CtlP->AiopNumChan[i] = 8; -#else - CtlP->AiopNumChan[i] = sReadAiopNumChan(CtlP, i); -#endif /* notdef */ - break; + if (VendorDevice == RP_DEVICE_ID_U8QO) { /* if UPCI QUAD/OCTAL board */ + gpio_dat = rp_readio2(CtlP, 1, _UPCI_GPIO); /* read GPIO reg */ + if (!(gpio_dat & _UPCI_OCTAL_IN)) /* if quad cable attached, */ + AiopChanCnt = 4; /* set for only four channels */ } + CtlP->AiopNumChan[i] = AiopChanCnt; /*device_printf(CtlP->dev, "%d channels.\n", CtlP->AiopNumChan[i]);*/ rp_writeaiop2(CtlP, i, _INDX_ADDR,_CLK_PRE); /* clock prescaler */ - /*device_printf(CtlP->dev, "configuring clock prescaler.\n");*/ - rp_writeaiop1(CtlP, i, _INDX_DATA,CLOCK_PRESC); - /*device_printf(CtlP->dev, "configured clock prescaler.\n");*/ + if (cardIsRocketportPlus(CtlP->dev)) { + rp_writeaiop1(CtlP, i, _INDX_DATA, AB_CLOCK_PRESC); + /*device_printf(CtlP->dev, "configured clock prescaler (%04x = %02x).\n",_CLK_PRE, AB_CLOCK_PRESC);*/ + } + else { + rp_writeaiop1(CtlP, i, _INDX_DATA, CLOCK_PRESC); + /*device_printf(CtlP->dev, "configured clock prescaler (%04x = %02x).\n",_CLK_PRE, CLOCK_PRESC);*/ + } CtlP->NumAiop++; /* bump count of AIOPs */ } - if(CtlP->NumAiop == 0) return(-1); else @@ -355,7 +540,80 @@ rp_pci_aiop2off(int aiop, int offset) static unsigned char rp_pci_ctlmask(CONTROLLER_t *ctlp) { - return sPCIGetControllerIntStatus(ctlp); + int cmsk; + unsigned char cret=0; + + if (cardIsUPCI(ctlp->dev)) { /* if RocketPort UPCI with PLX chip */ + cmsk = rp_readio2(ctlp, 1, _UPCI_GPIO); + if (cmsk & UINTSTAT0) /* convert PLX int bits to AIOPIC int bits */ + cret |= INTSTAT0; + if (cmsk & UINTSTAT1) + cret |= INTSTAT1; + if (cmsk & UINTSTAT2) + cret |= INTSTAT2; + if (cmsk & UINTSTAT3) + cret |= INTSTAT3; + cmsk = rp_readio2(ctlp, 1, _UPCI_INT_FUNC); /* get int active bit */ + if (cmsk & UINTACT) + cret |= 0x10; + return cret; + } + else { + return sPCIGetControllerIntStatus(ctlp); + } +} +int +cardIsUPCI(device_t dev) +{ + uint16_t VenDev; + int upci_fnd; + + upci_fnd = FALSE; + VenDev = pci_get_device(dev); + switch( VenDev ) { + case RP_DEVICE_ID_U8PL: + case RP_DEVICE_ID_U8QO: + case RP_DEVICE_ID_U16: + case RP_DEVICE_ID_U32: + case RP_DEVICE_ID_UP8QO: + case RP_DEVICE_ID_UP2: + case RP_DEVICE_ID_UP2SMPTE: + case RP_DEVICE_ID_UP4J: + case RP_DEVICE_ID_UP8J: + case RP_DEVICE_ID_UP422QO: + upci_fnd = TRUE; /* controller with PLX9030 chip */ + break; + default: + upci_fnd = FALSE; + break; + } + return(upci_fnd); +} +int +cardIsRocketportPlus(device_t dev) +{ + uint16_t VenDev; + int rpl_fnd; + + rpl_fnd = FALSE; + VenDev = pci_get_device(dev); + switch( VenDev ) { + case RP_DEVICE_ID_PL4: + case RP_DEVICE_ID_PL8: + case RP_DEVICE_ID_PL2: + case RP_DEVICE_ID_UP8QO: + case RP_DEVICE_ID_UP2: + case RP_DEVICE_ID_UP2SMPTE: + case RP_DEVICE_ID_UP4J: + case RP_DEVICE_ID_UP8J: + case RP_DEVICE_ID_UP422QO: + rpl_fnd = TRUE; /* RocketPort Plus board */ + break; + default: + rpl_fnd = FALSE; + break; + } + return(rpl_fnd); } static device_method_t rp_pcimethods[] = { Index: rpreg.h =================================================================== RCS file: /home/ncvs/src/sys/dev/rp/rpreg.h,v retrieving revision 1.7 diff -u -p -r1.7 rpreg.h --- rpreg.h 6 Jan 2005 01:43:11 -0000 1.7 +++ rpreg.h 26 Jan 2006 23:33:19 -0000 @@ -60,12 +60,12 @@ typedef unsigned int DWordIO_t; #define rp_writeio1(ctlp, rid, offset, data) rp_writeio(1, ctlp, rid, offset, data) #define rp_writeio2(ctlp, rid, offset, data) rp_writeio(2, ctlp, rid, offset, data) #define rp_writeio4(ctlp, rid, offset, data) rp_writeio(4, ctlp, rid, offset, data) -#define rp_readmultiio1(ctlp, rid, offset, addr, count) rp_readmultiio(1, ctlp, rid, offset, addr, count) -#define rp_readmultiio2(ctlp, rid, offset, addr, count) rp_readmultiio(2, ctlp, rid, offset, addr, count) -#define rp_readmultiio4(ctlp, rid, offset, addr, count) rp_readmultiio(4, ctlp, rid, offset, addr, count) -#define rp_writemultiio1(ctlp, rid, offset, addr, count) rp_writemultiio(1, ctlp, rid, offset, addr, count) -#define rp_writemultiio2(ctlp, rid, offset, addr, count) rp_writemultiio(2, ctlp, rid, offset, addr, count) -#define rp_writemultiio4(ctlp, rid, offset, addr, count) rp_writemultiio(4, ctlp, rid, offset, addr, count) +#define rp_readmultiio1(ctlp, rid, offset, addr, count) rp_readmultiio(1, ctlp, rid, offset, addr, count) +#define rp_readmultiio2(ctlp, rid, offset, addr, count) rp_readmultiio(2, ctlp, rid, offset, addr, count) +#define rp_readmultiio4(ctlp, rid, offset, addr, count) rp_readmultiio(4, ctlp, rid, offset, addr, count) +#define rp_writemultiio1(ctlp, rid, offset, addr, count) rp_writemultiio(1, ctlp, rid, offset, addr, count) +#define rp_writemultiio2(ctlp, rid, offset, addr, count) rp_writemultiio(2, ctlp, rid, offset, addr, count) +#define rp_writemultiio4(ctlp, rid, offset, addr, count) rp_writemultiio(4, ctlp, rid, offset, addr, count) #define rp_readaiop1(ctlp, aiop, offset) \ (rp_readio1((ctlp), (ctlp)->aiop2rid(aiop, offset), (ctlp)->aiop2off(aiop, offset))) @@ -133,6 +133,8 @@ typedef unsigned int DWordIO_t; /* Controller ID numbers */ #define CTLID_NULL -1 /* no controller exists */ #define CTLID_0001 0x0001 /* controller release 1 */ +#define CTLID_0002 0x0002 /* controller with PLX9030 chip */ +#define CTLID_0003 0x0003 /* Rocketport Plus board */ /* AIOP ID numbers, identifies AIOP type implementing channel */ #define AIOPID_NULL -1 /* no AIOP or channel exists */ @@ -213,8 +215,11 @@ Channel Register Offsets - Indexed - Int #define _BAUD 0xFF4 /* Baud Rate 16 Write */ #define _CLK_PRE 0xFF6 /* Clock Prescaler 8 Write */ +/************************************************************************ + Baud rate divisors using mod 9 clock prescaler and 36.873 clock +************************************************************************/ #define CLOCK_PRESC 0x19 /* mod 9 (divide by 10) prescale */ - +#define BRD0 3 /* tps remapped for 57.6KB */ #define BRD50 4607 #define BRD75 3071 #define BRD110 2094 @@ -238,6 +243,35 @@ Channel Register Offsets - Indexed - Int #define BRD76800 2 #define BRD115200 1 #define BRD230400 0 +/************************************************************************ + Baud rate divisors using mod 2 clock prescaler and 44.2368 clock +************************************************************************/ +#define AB_CLOCK_PRESC 0x12 /* mod 2 prescale */ +#define AB_BRD0 3 /* tps remapped for 57.6KB */ +#define AB_BRD50 18431 +#define AB_BRD75 12287 +#define AB_BRD110 8377 +#define AB_BRD134 6852 +#define AB_BRD150 6143 +#define AB_BRD200 4607 +#define AB_BRD300 3071 +#define AB_BRD600 1535 +#define AB_BRD1200 767 +#define AB_BRD1800 511 +#define AB_BRD2400 383 +#define AB_BRD4800 191 +#define AB_BRD7200 127 +#define AB_BRD9600 95 +#define AB_BRD14400 63 +#define AB_BRD19200 47 +#define AB_BRD28800 31 +#define AB_BRD38400 23 +#define AB_BRD57600 15 +#define AB_BRD76800 11 +#define AB_BRD115200 7 +#define AB_BRD230400 3 +#define AB_BRD460800 2 +#define AB_BRD921600 0 #define STMBREAK 0x08 /* BREAK */ #define STMFRAME 0x04 /* framing error */ @@ -316,6 +350,12 @@ Channel Register Offsets - Indexed - Int #define INTSTAT2 0x04 /* AIOP 2 interrupt status */ #define INTSTAT3 0x08 /* AIOP 3 interrupt status */ +#define UINTACT 0x04 /* UPCI AIOP Interrupt active */ +#define UINTSTAT0 0x04 /* UPCI AIOP 0 interrupt status */ +#define UINTSTAT1 0x20 /* UPCI AIOP 1 interrupt status */ +#define UINTSTAT2 0x100 /* UPCI AIOP 2 interrupt status */ +#define UINTSTAT3 0x800 /* UPCI AIOP 3 interrupt status */ + #define INTR_EN 0x08 /* allow interrupts to host */ #define INT_STROB 0x04 /* strobe and clear interrupt line (EOI) */ @@ -1004,7 +1044,12 @@ void sEnInterrupts(CHANNEL_T *ChP,Word_t void sDisInterrupts(CHANNEL_T *ChP,Word_t Flags); int rp_attachcommon(CONTROLLER_T *ctlp, int num_aiops, int num_ports); void rp_releaseresource(CONTROLLER_t *ctlp); +int cardIsUPCI(device_t dev); +int cardIsRocketportPlus(device_t dev); +int sGetChanRI(CHANNEL_T * ChP); void rp_untimeout(void); +extern int next_unit_number; +extern int num_devices_found; #ifndef ROCKET_C extern Byte_t R[RDATASIZE]; Index: rpvar.h =================================================================== RCS file: /home/ncvs/src/sys/dev/rp/rpvar.h,v retrieving revision 1.9 diff -u -p -r1.9 rpvar.h --- rpvar.h 4 Dec 2005 10:06:04 -0000 1.9 +++ rpvar.h 26 Jan 2006 23:33:19 -0000 @@ -29,7 +29,7 @@ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. * - * $FreeBSD: src/sys/dev/rp/rpvar.h,v 1.9 2005/12/04 10:06:04 ru Exp $ + * $FreeBSD: src/sys/dev/rp/rpvar.h,v 1.8 2005/01/06 01:43:11 imp Exp $ */ /* @@ -63,8 +63,8 @@ struct rp_port { int rp_xmit_stopped:1; CONTROLLER_t * rp_ctlp; CHANNEL_t rp_channel; - unsigned short TxBuf[TXFIFO_SIZE/2 +1]; - unsigned short RxBuf[RXFIFO_SIZE/2 +1]; + unsigned short TxBuf[TXFIFO_SIZE/2 + 1]; + unsigned short RxBuf[RXFIFO_SIZE/2 + 1]; }; /* Actually not used */ From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 26 23:48:48 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 837D416A420 for ; Thu, 26 Jan 2006 23:48:48 +0000 (GMT) (envelope-from ambrisko@ambrisko.com) Received: from mail.ambrisko.com (mail.ambrisko.com [64.174.51.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id C8EA943D72 for ; Thu, 26 Jan 2006 23:48:39 +0000 (GMT) (envelope-from ambrisko@ambrisko.com) Received: from server2.ambrisko.com (HELO www.ambrisko.com) ([192.168.1.2]) by mail.ambrisko.com with ESMTP; 26 Jan 2006 15:48:39 -0800 Received: from ambrisko.com (localhost [127.0.0.1]) by www.ambrisko.com (8.12.11/8.12.9) with ESMTP id k0QNmd0m004928; Thu, 26 Jan 2006 15:48:39 -0800 (PST) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.12.11/8.12.11/Submit) id k0QNmdvB004927; Thu, 26 Jan 2006 15:48:39 -0800 (PST) (envelope-from ambrisko) From: Doug Ambrisko Message-Id: <200601262348.k0QNmdvB004927@ambrisko.com> In-Reply-To: To: Surer Dink Date: Thu, 26 Jan 2006 15:48:39 -0800 (PST) X-Mailer: ELM [version 2.4ME+ PL94b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Cc: freebsd-hackers@freebsd.org Subject: Re: CPU/case/disk temperature sensors for Dell PowerEdge 2850 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2006 23:48:48 -0000 Surer Dink writes: | (I was told this was /one/ of the appropriate forums for this message - | however I did not want to cross-post - if this is not the correct place, | please let me know and I will try the other suggestions [acpi- and ports-].) ipmitool will work fine over lan in ports. It will not work to locally read the values. I have an OpenIPMI compatible driver that we use here locally with a patched ipmitool (to fix the wrong IOCTL defines since we care about read/write semantics). We use it at work to read IPMI stuff on PE2850/PE850 and update the BMC firmware via a binary tool on a PE2850. It should work with any IPMI device that is defined in SMBIOS. I have not done ACPI attachment. I implemented the IPMI watchdog to tie into FreeBSD's watchdog code. I like ipmitool since Dell supplies them with patches etc. I probably should check it into -current. It's not all done but good enough to do a bunch of stuff and Tom Rhodes started a man page for it. I work on it as I get time or have new needs for it. Doug A. From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 26 23:56:44 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F3CE416A420 for ; Thu, 26 Jan 2006 23:56:43 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 922F343D6D for ; Thu, 26 Jan 2006 23:56:43 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.ntplx.net (8.13.5/8.13.5/NETPLEX) with ESMTP id k0QNugpn022969; Thu, 26 Jan 2006 18:56:42 -0500 (EST) Date: Thu, 26 Jan 2006 18:56:42 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Kurt Miller In-Reply-To: <200601261803.30503.kurt@intricatesoftware.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) Cc: freebsd-hackers@freebsd.org Subject: Re: read hang on datagram socket X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2006 23:56:44 -0000 On Thu, 26 Jan 2006, Kurt Miller wrote: > I'm working on 1.5 jdk certification on 5.4 and 6.0. One of the jck > tests hangs on 5.4 but works ok on 6.0. I've reduced the problem > down to the following C program that hangs on 5.4 but works fine > (finishes) on 6.0 and 4.11. > > I could use some assistance with finding a work-around to the > problem or an explanation as to why the program hangs on 5.4. It exit'd in the last connect() in Solaris 9. I modified it to work -- see below. > > Thank you, > -Kurt > > #include > #include > #include > #include > #include > #include > #include [ ... ] > int > main() { > int sock1, sock2; > int optval = 1; > struct sockaddr addr; > struct sockaddr sock1Addr, sock2Addr; > int sock1AddrLen, sock2AddrLen; > short port1, port2; > char sendBuf, readBuf; > int hostAddress; > > if ((hostAddress = getHostAddress()) == 0) > exit(1); > > buildAddr4((struct sockaddr_in *)&addr, 0, 0); > > if ((sock1 = socket(AF_INET, SOCK_DGRAM, 0)) < 0) > exit(1); > if (setsockopt(sock1, SOL_SOCKET, SO_BROADCAST, (char*) &optval, sizeof(optval)) != 0) > exit(1); > if (bind(sock1, (struct sockaddr *)&addr, sizeof(struct sockaddr_in)) != 0) > exit(1); + sock1AddrLen = sizeof(sock1Addr); > if (getsockname(sock1, &sock1Addr, &sock1AddrLen) != 0) > exit(1); > setAddress((struct sockaddr_in *)&sock1Addr, hostAddress); > > if ((sock2 = socket(AF_INET, SOCK_DGRAM, 0)) < 0) > exit(1); > if (bind(sock2, (struct sockaddr *)&addr, sizeof(struct sockaddr_in)) != 0) > exit(1); + sock2AddrLen = sizeof(sock2Addr); > if (getsockname(sock2, &sock2Addr, &sock2AddrLen) != 0) > exit(1); > setAddress((struct sockaddr_in *)&sock2Addr, hostAddress); > if (connect(sock2, &sock1Addr, sock1AddrLen) != 0) > exit(1); > > sendBuf = 22; > if (sendto(sock1, &sendBuf, 1, 0, &sock2Addr, sock2AddrLen) != 1) > exit(1); > > if (read(sock2, &readBuf, 1) != 1) > exit(1); > > printf("no hang\n"); > } -- DE From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 27 00:21:55 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 679D916A422; Fri, 27 Jan 2006 00:21:55 +0000 (GMT) (envelope-from lists@intricatesoftware.com) Received: from mta8.srv.hcvlny.cv.net (mta8.srv.hcvlny.cv.net [167.206.4.203]) by mx1.FreeBSD.org (Postfix) with ESMTP id CB9D243D70; Fri, 27 Jan 2006 00:21:52 +0000 (GMT) (envelope-from lists@intricatesoftware.com) Received: from [172.16.1.72] (ool-457a77e8.dyn.optonline.net [69.122.119.232]) by mta8.srv.hcvlny.cv.net (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTP id <0ITQ00IG46BSLNF0@mta8.srv.hcvlny.cv.net>; Thu, 26 Jan 2006 19:21:28 -0500 (EST) Date: Thu, 26 Jan 2006 19:21:27 -0500 From: Kurt Miller In-reply-to: To: freebsd-hackers@freebsd.org, Daniel Eischen Message-id: <200601261921.27799.lists@intricatesoftware.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline References: User-Agent: KMail/1.9 Cc: Subject: Re: read hang on datagram socket X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: kurt@intricatesoftware.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2006 00:21:55 -0000 On Thursday 26 January 2006 6:56 pm, Daniel Eischen wrote: > On Thu, 26 Jan 2006, Kurt Miller wrote: > > > I'm working on 1.5 jdk certification on 5.4 and 6.0. One of the jck > > tests hangs on 5.4 but works ok on 6.0. I've reduced the problem > > down to the following C program that hangs on 5.4 but works fine > > (finishes) on 6.0 and 4.11. > > > > I could use some assistance with finding a work-around to the > > problem or an explanation as to why the program hangs on 5.4. > > It exit'd in the last connect() in Solaris 9. I modified it > to work -- see below. Thanks, that was my bug (the jdk did it right). It Sill hangs on 5.4 though. Sorry about the double post. My first message was moderator approved while I was resending from my lists@ address. -Kurt From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 27 00:26:38 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4234916A420 for ; Fri, 27 Jan 2006 00:26:38 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 42F2B43D5A for ; Fri, 27 Jan 2006 00:26:35 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.ntplx.net (8.13.5/8.13.5/NETPLEX) with ESMTP id k0R0QYVR021397; Thu, 26 Jan 2006 19:26:34 -0500 (EST) Date: Thu, 26 Jan 2006 19:26:34 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: kurt@intricatesoftware.com In-Reply-To: <200601261921.27799.lists@intricatesoftware.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) Cc: freebsd-hackers@freebsd.org Subject: Re: read hang on datagram socket X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2006 00:26:38 -0000 On Thu, 26 Jan 2006, Kurt Miller wrote: > On Thursday 26 January 2006 6:56 pm, Daniel Eischen wrote: > > On Thu, 26 Jan 2006, Kurt Miller wrote: > > > > > I'm working on 1.5 jdk certification on 5.4 and 6.0. One of the jck > > > tests hangs on 5.4 but works ok on 6.0. I've reduced the problem > > > down to the following C program that hangs on 5.4 but works fine > > > (finishes) on 6.0 and 4.11. > > > > > > I could use some assistance with finding a work-around to the > > > problem or an explanation as to why the program hangs on 5.4. > > > > It exit'd in the last connect() in Solaris 9. I modified it > > to work -- see below. > > Thanks, that was my bug (the jdk did it right). It Sill hangs on 5.4 > though. The modified version does not hang on 5.2. Do you have multiple interfaces on your 5.4 box? What happens when you try using non-zero IP addresses and ports? -- DE From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 27 04:41:14 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1986D16A420; Fri, 27 Jan 2006 04:41:14 +0000 (GMT) (envelope-from lists@intricatesoftware.com) Received: from mta6.srv.hcvlny.cv.net (mta6.srv.hcvlny.cv.net [167.206.4.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id BE51343D4C; Fri, 27 Jan 2006 04:41:11 +0000 (GMT) (envelope-from lists@intricatesoftware.com) Received: from [172.16.1.72] (ool-457a77e8.dyn.optonline.net [69.122.119.232]) by mta6.srv.hcvlny.cv.net (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTP id <0ITQ00HIUIBZSJX0@mta6.srv.hcvlny.cv.net>; Thu, 26 Jan 2006 23:40:47 -0500 (EST) Date: Thu, 26 Jan 2006 23:40:46 -0500 From: Kurt Miller In-reply-to: To: freebsd-hackers@freebsd.org, Daniel Eischen Message-id: <200601262340.46999.lists@intricatesoftware.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline References: User-Agent: KMail/1.9 Cc: Subject: Re: read hang on datagram socket X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2006 04:41:14 -0000 On Thursday 26 January 2006 7:26 pm, Daniel Eischen wrote: > On Thu, 26 Jan 2006, Kurt Miller wrote: > > > On Thursday 26 January 2006 6:56 pm, Daniel Eischen wrote: > > > On Thu, 26 Jan 2006, Kurt Miller wrote: > > > > > > > I'm working on 1.5 jdk certification on 5.4 and 6.0. One of the jck > > > > tests hangs on 5.4 but works ok on 6.0. I've reduced the problem > > > > down to the following C program that hangs on 5.4 but works fine > > > > (finishes) on 6.0 and 4.11. > > > > > > > > I could use some assistance with finding a work-around to the > > > > problem or an explanation as to why the program hangs on 5.4. > > > > > > It exit'd in the last connect() in Solaris 9. I modified it > > > to work -- see below. > > > > Thanks, that was my bug (the jdk did it right). It Sill hangs on 5.4 > > though. > > The modified version does not hang on 5.2. Do you have multiple > interfaces on your 5.4 box? No, the 5.4 box is virtually identical to the 6.0 box. I set them both up at the same time from initial installs for the project. truk@freebsd5-4$ ifconfig lnc0: flags=108843 mtu 1500 inet6 fe80::250:56ff:fe40:451a%lnc0 prefixlen 64 scopeid 0x1 inet 172.16.1.36 netmask 0xffffff00 broadcast 172.16.1.255 ether 00:50:56:40:45:1a lo0: flags=8049 mtu 16384 inet 127.0.0.1 netmask 0xff000000 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 truk@freebsd6-0$ ifconfig lnc0: flags=108843 mtu 1500 inet6 fe80::250:56ff:fe40:4533%lnc0 prefixlen 64 scopeid 0x1 inet 172.16.1.37 netmask 0xffffff00 broadcast 172.16.1.255 ether 00:50:56:40:45:33 lo0: flags=8049 mtu 16384 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 inet 127.0.0.1 netmask 0xff000000 > What happens when you try using non-zero IP addresses and ports? > Setting the ports doesn't effect the problem, however setting the addresses does. It really seems like binding to INADDR_ANY only binds to loopback address 127.0.0.1 and not all the interfaces. If sock1 is bound to the hostAddress and sock2 connects to sock1 at the hostAddress it works ok. If sock1 is bound to INADDR_ANY and sock2 connects to sock1 using INADDR_ANY it works. but any mixture of of using INADDR_ANY with the hostAddress fails. Unfortunately, I don't have control over the addresses, the java programs do. This particular jck test binds the first socket with INADDR_ANY (InetAddress.getByName("0.0.0.0")) and connects the second socket to the first using the hostAddress (InetAddress.getLocalHost()). netstat output when stopping the program at the sendto call on 5.4 looks like this: udp4 0 0 localhost.55513 172.16.1.36.52099 on 6.0: udp4 0 0 172.16.1.37.53952 172.16.1.37.62241 Doesn't the above output indicate a problem with how datagram sockets are bound to INADDR_ANY? Perhaps its related to my configuration. Can anyone else with a 5.4-release system try the program to see if it works for them? -Kurt From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 27 10:40:56 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C0A3416A420; Fri, 27 Jan 2006 10:40:56 +0000 (GMT) (envelope-from fli+freebsd-hackers@shapeshifter.se) Received: from mx1.h3q.net (manticore.shapeshifter.se [212.37.5.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 24E5143D48; Fri, 27 Jan 2006 10:40:53 +0000 (GMT) (envelope-from fli+freebsd-hackers@shapeshifter.se) Received: from localhost (localhost [127.0.0.1]) by mx1.h3q.net (Postfix) with ESMTP id CF3A31A84C; Fri, 27 Jan 2006 11:40:51 +0100 (CET) Received: from mx1.h3q.net ([127.0.0.1]) by localhost (mx1.h3q.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14193-08; Fri, 27 Jan 2006 11:40:50 +0100 (CET) Received: from [192.168.0.83] (81-234-243-91-o926.tbon.telia.com [81.234.243.91]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.h3q.net (Postfix) with ESMTP id 32D601A6A8; Fri, 27 Jan 2006 11:40:50 +0100 (CET) Message-ID: <43D9F8AD.2020502@shapeshifter.se> Date: Fri, 27 Jan 2006 11:40:45 +0100 From: Fredrik Lindberg User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050928) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kurt Miller References: <200601262340.46999.lists@intricatesoftware.com> In-Reply-To: <200601262340.46999.lists@intricatesoftware.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at h3q.net Cc: Daniel Eischen , freebsd-hackers@freebsd.org Subject: Re: read hang on datagram socket X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2006 10:40:56 -0000 Kurt Miller wrote: > On Thursday 26 January 2006 7:26 pm, Daniel Eischen wrote: > >>On Thu, 26 Jan 2006, Kurt Miller wrote: >> >> >>>On Thursday 26 January 2006 6:56 pm, Daniel Eischen wrote: >>> >>>>On Thu, 26 Jan 2006, Kurt Miller wrote: >>>> >>>> >>>>>I'm working on 1.5 jdk certification on 5.4 and 6.0. One of the jck >>>>>tests hangs on 5.4 but works ok on 6.0. I've reduced the problem >>>>>down to the following C program that hangs on 5.4 but works fine >>>>>(finishes) on 6.0 and 4.11. >>>>> >>>>>I could use some assistance with finding a work-around to the >>>>>problem or an explanation as to why the program hangs on 5.4. >>>> >>>>It exit'd in the last connect() in Solaris 9. I modified it >>>>to work -- see below. >>> >>>Thanks, that was my bug (the jdk did it right). It Sill hangs on 5.4 >>>though. >> >>The modified version does not hang on 5.2. Do you have multiple >>interfaces on your 5.4 box? > > > No, the 5.4 box is virtually identical to the 6.0 box. I set them both > up at the same time from initial installs for the project. > > truk@freebsd5-4$ ifconfig > lnc0: flags=108843 mtu 1500 > inet6 fe80::250:56ff:fe40:451a%lnc0 prefixlen 64 scopeid 0x1 > inet 172.16.1.36 netmask 0xffffff00 broadcast 172.16.1.255 > ether 00:50:56:40:45:1a > lo0: flags=8049 mtu 16384 > inet 127.0.0.1 netmask 0xff000000 > inet6 ::1 prefixlen 128 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 > > truk@freebsd6-0$ ifconfig > lnc0: flags=108843 mtu 1500 > inet6 fe80::250:56ff:fe40:4533%lnc0 prefixlen 64 scopeid 0x1 > inet 172.16.1.37 netmask 0xffffff00 broadcast 172.16.1.255 > ether 00:50:56:40:45:33 > lo0: flags=8049 mtu 16384 > inet6 ::1 prefixlen 128 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 > inet 127.0.0.1 netmask 0xff000000 > > >>What happens when you try using non-zero IP addresses and ports? >> > > > Setting the ports doesn't effect the problem, however setting the > addresses does. It really seems like binding to INADDR_ANY only binds > to loopback address 127.0.0.1 and not all the interfaces. > > If sock1 is bound to the hostAddress and sock2 connects to sock1 at > the hostAddress it works ok. If sock1 is bound to INADDR_ANY and sock2 > connects to sock1 using INADDR_ANY it works. but any mixture of of > using INADDR_ANY with the hostAddress fails. > > Unfortunately, I don't have control over the addresses, the java > programs do. This particular jck test binds the first socket with > INADDR_ANY (InetAddress.getByName("0.0.0.0")) and connects the second > socket to the first using the hostAddress (InetAddress.getLocalHost()). > > netstat output when stopping the program at the sendto call on 5.4 > looks like this: > udp4 0 0 localhost.55513 172.16.1.36.52099 > > on 6.0: > udp4 0 0 172.16.1.37.53952 172.16.1.37.62241 > > Doesn't the above output indicate a problem with how datagram > sockets are bound to INADDR_ANY? > > Perhaps its related to my configuration. Can anyone else with a > 5.4-release system try the program to see if it works for them? > It works on a 5.4-RELEASE-p5 system. fli> ./test no hang fli> ifconfig em0: flags=8843 mtu 1500 options=b inet 212.XX.XX.XX netmask 0xfffffff8 broadcast 212.XX.XX.XX inet6 fe80::240:d0ff:fe43:b964%em0 prefixlen 64 scopeid 0x1 ether 00:40:d0:43:b9:64 media: Ethernet autoselect (100baseTX ) status: active em1: flags=8802 mtu 1500 options=b ether 00:40:d0:43:b9:65 media: Ethernet autoselect status: no carrier lo0: flags=8049 mtu 16384 inet 127.0.0.1 netmask 0xff000000 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 Stopping it before sendto() gives udp4 0 0 212.XX.XX.XX.54074 212.XX.XX.XX.56604 Fredrik Lindberg From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 27 10:49:10 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2CF2716A420; Fri, 27 Jan 2006 10:49:10 +0000 (GMT) (envelope-from bra@fsn.hu) Received: from people.fsn.hu (people.fsn.hu [195.228.252.137]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8E2B143D45; Fri, 27 Jan 2006 10:49:08 +0000 (GMT) (envelope-from bra@fsn.hu) Received: from localhost (localhost [127.0.0.1]) by people.fsn.hu (Postfix) with ESMTP id 29A7C84420; Fri, 27 Jan 2006 11:49:07 +0100 (CET) Received: from people.fsn.hu ([127.0.0.1]) by localhost (people.fsn.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 80196-01; Fri, 27 Jan 2006 11:49:01 +0100 (CET) Received: from [172.16.164.75] (fw.axelero.hu [195.228.243.120]) by people.fsn.hu (Postfix) with ESMTP id 3D4CF8441E; Fri, 27 Jan 2006 11:49:01 +0100 (CET) Message-ID: <43D9FAA1.70105@fsn.hu> Date: Fri, 27 Jan 2006 11:49:05 +0100 From: Attila Nagy User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at fsn.hu Cc: freebsd-scsi@freebsd.org Subject: Not so deep and not so correct benchmark for SCSI target mode X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2006 10:49:10 -0000 Hello, I've tried to do a quick benchmark of FreeBSD's target mode on Fibre Channel. The graphs are here: http://people.fsn.hu/~bra/freebsd/tmode-bench/ -- Attila Nagy e-mail: Attila.Nagy@fsn.hu Free Software Network (FSN.HU) phone: +3630 306 6758 http://www.fsn.hu/ From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 27 11:35:02 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5D92216A420 for ; Fri, 27 Jan 2006 11:35:02 +0000 (GMT) (envelope-from ducrot@poupinou.org) Received: from poup.poupinou.org (poup.poupinou.org [195.101.94.96]) by mx1.FreeBSD.org (Postfix) with ESMTP id D4DBA43D46 for ; Fri, 27 Jan 2006 11:35:01 +0000 (GMT) (envelope-from ducrot@poupinou.org) Received: from ducrot by poup.poupinou.org with local (Exim) id 1F2Rsa-0003q0-00 for ; Fri, 27 Jan 2006 12:35:00 +0100 Date: Fri, 27 Jan 2006 12:35:00 +0100 To: freebsd-hackers@FreeBSD.ORG Message-ID: <20060127113500.GA14672@poupinou.org> References: <20060126155412.GB11603@poupinou.org> <200601261804.k0QI4mZk073348@lurza.secnetix.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200601261804.k0QI4mZk073348@lurza.secnetix.de> User-Agent: Mutt/1.5.9i From: Bruno Ducrot Cc: Subject: Re: CPU/case/disk temperature sensors for Dell PowerEdge 2850 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2006 11:35:02 -0000 On Thu, Jan 26, 2006 at 07:04:48PM +0100, Oliver Fromme wrote: > Hi, > > Sorry for jumping into this thread. > I have the same problem, but on different hardware. > > Bruno Ducrot wrote: > > > > First, install sysutils/freeipmi, then try it by this command: > > > > # bmc-info > > It hangs forever. "bmc-config -o" prints a few lines > (starts with "Section User1" and doesn't seem useful), > then also hangs forever. > > Oh, by thy way, my machine is a HP ProLiant DL360 G4 > (formerly Compaq). Ask HP. They use a propritary solution. If they can't help you, I'm afraid nobody can't here. -- Bruno Ducrot -- Which is worse: ignorance or apathy? -- Don't know. Don't care. From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 27 11:37:53 2006 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B98D216A420 for ; Fri, 27 Jan 2006 11:37:53 +0000 (GMT) (envelope-from vit.ska@gmail.com) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.197]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0937443D45 for ; Fri, 27 Jan 2006 11:37:52 +0000 (GMT) (envelope-from vit.ska@gmail.com) Received: by xproxy.gmail.com with SMTP id s9so356527wxc for ; Fri, 27 Jan 2006 03:37:52 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=lmOAWgUZuWAquk6B18dOVUh9n1sGBgi+r4X5NjbNlu7bb6A7nbrlz6kk6wKWUnLBlOZ0hawttqMS0e4o8+6pQffoastkKrzp5Ov4YIyPxKDebV1JhDxBuJORubY6NMpl99g+GBZyFbcsIz2HTNRDkAn2y4iYEz4TukDdXDmf+aw= Received: by 10.70.125.18 with SMTP id x18mr3497399wxc; Fri, 27 Jan 2006 03:37:52 -0800 (PST) Received: by 10.70.118.3 with HTTP; Fri, 27 Jan 2006 03:37:52 -0800 (PST) Message-ID: <806128ad0601270337g53663aabk@mail.gmail.com> Date: Fri, 27 Jan 2006 13:37:52 +0200 From: Vitaliy Skakun To: hackers@freebsd.org In-Reply-To: <200601262334.k0QNYbuS004173@ambrisko.com> MIME-Version: 1.0 References: <806128ad0601260254u42dfd927k@mail.gmail.com> <200601262334.k0QNYbuS004173@ambrisko.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: Comtrol Rocketport UNIVERSAL PCI 32-port X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2006 11:37:53 -0000 dGhhbmtzLCBidXQgSSBzZWUgdGhpcyBwYXRjaCBpcyBhZ2FpbnN0IHJlY2VudCBIRUFECgpJJ3Zl IGdvdCB0aGUgeWVzdGVyZGF5cyBSRUxFTkdfNiBzb3VyY2VzIGFuZCBjYW4ndCBzaW1wbHkgdXBk YXRlIHRvIEhFQUQgKAppdCBpcyBhIHNlcnZlciApCgpzbywgSSd2ZSBmYWlsZWQgdG8gYXBwbHkg eW91ciBwYXRjaCBjbGVhbmx5LCBhbmQgZmFpbGVkIHRvIHJlY29tcGlsZSB0aGUKa2VybmVsOgoK L3Vzci9zcmMvc3lzL21vZHVsZXMvcnAvLi4vLi4vZGV2L3JwL3JwLmM6IEluIGZ1bmN0aW9uIGBy cF9hdHRhY2hjb21tb24nOgovdXNyL3NyYy9zeXMvbW9kdWxlcy9ycC8uLi8uLi9kZXYvcnAvcnAu Yzo4NDI6IGVycm9yOiBgVFNfQ0FMTE9VVCcKdW5kZWNsYXJlZCAoZmlyc3QgdXNlIGluIHRoaXMg ZnVuY3Rpb24pCi91c3Ivc3JjL3N5cy9tb2R1bGVzL3JwLy4uLy4uL2Rldi9ycC9ycC5jOjg0Mjog ZXJyb3I6IChFYWNoIHVuZGVjbGFyZWQKaWRlbnRpZmllciBpcyByZXBvcnRlZCBvbmx5IG9uY2UK L3Vzci9zcmMvc3lzL21vZHVsZXMvcnAvLi4vLi4vZGV2L3JwL3JwLmM6ODQyOiBlcnJvcjogZm9y IGVhY2ggZnVuY3Rpb24gaXQKYXBwZWFycyBpbi4pCi91c3Ivc3JjL3N5cy9tb2R1bGVzL3JwLy4u Ly4uL2Rldi9ycC9ycC5jOjg0Mjogd2FybmluZzogcGFzc2luZyBhcmcgMyBvZgpgdHR5Y3JlYXRl JyBtYWtlcyBpbnRlZ2VyIGZyb20gcG9pbnRlciB3aXRob3V0IGEKY2FzdC91c3Ivc3JjL3N5cy9t b2R1bGVzL3JwLy4uLy4uL2Rldi9ycC9ycC5jOjg0Mjogd2FybmluZzogcGFzc2luZyBhcmcgNSBv ZgpgdHR5Y3JlYXRlJyBtYWtlcyBwb2ludGVyIGZyb20gaW50ZWdlciB3aXRob3V0IGEgY2FzdCoq KiBFcnJvciBjb2RlIDEKMSBlcnJvcgoqKiogRXJyb3IgY29kZSAyCjEgZXJyb3IKKioqIEVycm9y IGNvZGUgMgoyIGVycm9ycwoqKiogRXJyb3IgY29kZSAyCjEgZXJyb3IKKioqIEVycm9yIGNvZGUg MgoxIGVycm9yCgpDaGVlcnMKVml0Cg== From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 27 15:18:06 2006 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B1E6B16A420 for ; Fri, 27 Jan 2006 15:18:06 +0000 (GMT) (envelope-from ambrisko@ambrisko.com) Received: from mail.ambrisko.com (mail.ambrisko.com [64.174.51.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id E4C4344450 for ; Fri, 27 Jan 2006 15:18:05 +0000 (GMT) (envelope-from ambrisko@ambrisko.com) Received: from server2.ambrisko.com (HELO www.ambrisko.com) ([192.168.1.2]) by mail.ambrisko.com with ESMTP; 27 Jan 2006 07:18:05 -0800 Received: from ambrisko.com (localhost [127.0.0.1]) by www.ambrisko.com (8.12.11/8.12.9) with ESMTP id k0RFI4aW055229; Fri, 27 Jan 2006 07:18:04 -0800 (PST) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.12.11/8.12.11/Submit) id k0RFI3Fx055228; Fri, 27 Jan 2006 07:18:03 -0800 (PST) (envelope-from ambrisko) From: Doug Ambrisko Message-Id: <200601271518.k0RFI3Fx055228@ambrisko.com> In-Reply-To: <806128ad0601270337g53663aabk@mail.gmail.com> To: Vitaliy Skakun Date: Fri, 27 Jan 2006 07:18:03 -0800 (PST) X-Mailer: ELM [version 2.4ME+ PL94b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Cc: hackers@freebsd.org Subject: Re: Comtrol Rocketport UNIVERSAL PCI 32-port X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2006 15:18:06 -0000 Vitaliy Skakun writes: | thanks, but I see this patch is against recent HEAD | | I've got the yesterdays RELENG_6 sources and can't simply update to HEAD ( | it is a server ) Give this a shot against RELENG_6: Index: rp.c =================================================================== RCS file: /home/ncvs/src/sys/dev/rp/rp.c,v retrieving revision 1.67.2.1 diff -u -p -r1.67.2.1 rp.c --- rp.c 8 Nov 2005 15:35:27 -0000 1.67.2.1 +++ rp.c 27 Jan 2006 15:13:37 -0000 @@ -34,18 +34,21 @@ #include __FBSDID("$FreeBSD: src/sys/dev/rp/rp.c,v 1.67.2.1 2005/11/08 15:35:27 jhb Exp $"); -/* +/* * rp.c - for RocketPort FreeBSD */ +#include #include "opt_compat.h" #include +#include #include #include #include #include #include +#include #include #include #include @@ -57,7 +60,7 @@ __FBSDID("$FreeBSD: src/sys/dev/rp/rp.c, #include #include -static const char RocketPortVersion[] = "3.02"; +static const char RocketPortVersion[] = "1.0"; static Byte_t RData[RDATASIZE] = { @@ -116,6 +119,8 @@ Byte_t rp_sBitMapSetTbl[8] = 0x01,0x02,0x04,0x08,0x10,0x20,0x40,0x80 }; +int next_unit_number = 0; +int num_devices_found = 0; /*************************************************************************** Function: sReadAiopID Purpose: Read the AIOP idenfication number directly from an AIOP. @@ -587,6 +592,9 @@ static void rp_do_receive(struct rp_port unsigned int CharNStat; int ToRecv, wRecv, ch, ttynocopy; + if (tp->t_state & TS_TBLOCK) + return; + ToRecv = sGetRxCnt(cp); if(ToRecv == 0) return; @@ -615,7 +623,7 @@ static void rp_do_receive(struct rp_port CharNStat = rp_readch2(cp,sGetTxRxDataIO(cp)); ch = CharNStat & 0xff; - if((CharNStat & STMBREAK) || (CharNStat & STMFRAMEH)) + if((CharNStat & STMBREAKH) || (CharNStat & STMFRAMEH)) ch |= TTY_FE; else if (CharNStat & STMPARITYH) ch |= TTY_PE; @@ -645,6 +653,12 @@ static void rp_do_receive(struct rp_port if ( ToRecv > RXFIFO_SIZE ) { ToRecv = RXFIFO_SIZE; } + if ((tp->t_rawq.c_cc + ToRecv > tp->t_ihiwat) && + ((tp->t_cflag & CRTS_IFLOW) || + (tp->t_iflag & IXOFF)) && + !(tp->t_state & TS_TBLOCK)) + ttyblock(tp); + wRecv = ToRecv >> 1; if ( wRecv ) { rp_readmultich2(cp,sGetTxRxDataIO(cp),(u_int16_t *)rp->RxBuf,wRecv); @@ -686,6 +700,7 @@ static void rp_handle_port(struct rp_por IntMask = sGetChanIntID(cp); IntMask = IntMask & rp->rp_intmask; ChanStatus = sGetChanStatus(cp); + if(IntMask & RXF_TRIG) if(!(tp->t_state & TS_TBLOCK) && (tp->t_state & TS_CARR_ON) && (tp->t_state & TS_ISOPEN)) { rp_do_receive(rp, tp, cp, ChanStatus); @@ -752,7 +767,7 @@ static void rp_do_poll(void *not_used) } } if(rp_num_ports_open) - rp_callout_handle = timeout(rp_do_poll, + rp_callout_handle = timeout(rp_do_poll, (void *)NULL, POLL_INTERVAL); } @@ -769,22 +784,23 @@ rp_attachcommon(CONTROLLER_T *ctlp, int unit = device_get_unit(ctlp->dev); - printf("RocketPort%d (Version %s) %d ports.\n", unit, - RocketPortVersion, num_ports); + printf("RocketPort%d = %d ports.\n", unit, num_ports); rp_num_ports[unit] = num_ports; callout_handle_init(&rp_callout_handle); ctlp->rp = rp = (struct rp_port *) - malloc(sizeof(struct rp_port) * num_ports, M_TTYS, M_NOWAIT | M_ZERO); + malloc(sizeof(struct rp_port) * (num_ports+1), M_TTYS, M_NOWAIT | M_ZERO); if (rp == NULL) { device_printf(ctlp->dev, "rp_attachcommon: Could not malloc rp_ports structures.\n"); retval = ENOMEM; goto nogo; } - +/* else { + device_printf(ctlp->dev, "malloc'd rp_ports structures=%08x.\n", rp); + }*/ count = unit * 32; /* board times max ports per card SG */ - bzero(rp, sizeof(struct rp_port) * num_ports); + bzero(rp, sizeof(struct rp_port) * (num_ports+1)); oldspl = spltty(); rp_addr(unit) = rp; splx(oldspl); @@ -927,7 +943,7 @@ rpopen(struct tty *tp, struct cdev *dev) ChanStatus = sGetChanStatus(&rp->rp_channel); if(rp_num_ports_open == 1) - rp_callout_handle = timeout(rp_do_poll, + rp_callout_handle = timeout(rp_do_poll, (void *)NULL, POLL_INTERVAL); device_busy(rp->rp_ctlp->dev); @@ -1016,9 +1032,10 @@ rpmodem(struct tty *tp, int sigon, int s } return (0); } - +#define B460800 460800 +#define B921600 921600 static struct speedtab baud_table[] = { - {B0, 0}, {B50, BRD50}, {B75, BRD75}, + {B0, BRD0}, {B50, BRD50}, {B75, BRD75}, {B110, BRD110}, {B134, BRD134}, {B150, BRD150}, {B200, BRD200}, {B300, BRD300}, {B600, BRD600}, {B1200, BRD1200}, {B1800, BRD1800}, {B2400, BRD2400}, @@ -1029,6 +1046,18 @@ static struct speedtab baud_table[] = { {-1, -1} }; +static struct speedtab ab_baud_table[] = { + {B0, AB_BRD0}, {B50, AB_BRD50}, {B75, AB_BRD75}, + {B110, AB_BRD110}, {B134, AB_BRD134}, {B150, AB_BRD150}, + {B200, AB_BRD200}, {B300, AB_BRD300}, {B600, AB_BRD600}, + {B1200, AB_BRD1200}, {B1800, AB_BRD1800}, {B2400, AB_BRD2400}, + {B4800, AB_BRD4800}, {B9600, AB_BRD9600}, {B19200, AB_BRD19200}, + {B38400, AB_BRD38400}, {B7200, AB_BRD7200}, {B14400, AB_BRD14400}, + {B57600, AB_BRD57600}, {B76800, AB_BRD76800}, {B115200, AB_BRD115200}, + {B230400,AB_BRD230400}, {B460800,AB_BRD460800}, {B921600, AB_BRD921600}, + {-1, -1} +}; + static int rpparam(tp, t) struct tty *tp; @@ -1042,7 +1071,6 @@ rpparam(tp, t) int devshift; #endif - rp = tp->t_sc; cp = &rp->rp_channel; oldspl = spltty(); @@ -1059,7 +1087,10 @@ rpparam(tp, t) oflag = t->c_oflag; lflag = t->c_lflag; - ospeed = ttspeedtab(t->c_ispeed, baud_table); + if (cardIsRocketportPlus(rp->rp_ctlp->dev)) + ospeed = ttspeedtab(t->c_ispeed, ab_baud_table); + else + ospeed = ttspeedtab(t->c_ispeed, baud_table); if(ospeed < 0 || t->c_ispeed != t->c_ospeed) return(EINVAL); Index: rp_isa.c =================================================================== RCS file: /home/ncvs/src/sys/dev/rp/rp_isa.c,v retrieving revision 1.7 diff -u -p -r1.7 rp_isa.c --- rp_isa.c 6 Jan 2005 01:43:11 -0000 1.7 +++ rp_isa.c 27 Jan 2006 15:13:37 -0000 @@ -63,8 +63,8 @@ struct ISACONTROLLER_T { int MReg1IO; /* offset1 of the Mudbac controller for this controller */ int MReg2IO; /* offset2 of the Mudbac controller for this controller */ int MReg3IO; /* offset3 of the Mudbac controller for this controller */ - Byte_t MReg2; - Byte_t MReg3; + unsigned char MReg2; + unsigned char MReg3; }; typedef struct ISACONTROLLER_T ISACONTROLLER_t; @@ -140,6 +140,12 @@ static rp_aiop2rid_t rp_isa_aiop2rid; static rp_aiop2off_t rp_isa_aiop2off; static rp_ctlmask_t rp_isa_ctlmask; +/* +struct isa_driver rpdriver = { + rpprobe, rpattach, "rp" + }; +*/ + static int rp_probe(device_t dev) { @@ -149,6 +155,9 @@ rp_probe(device_t dev) CONTROLLER_t *ctlp; int retval; + if (num_devices_found >= 4) + return (ENXIO); + /* * We have no PnP RocketPort cards. * (At least according to LINT) @@ -156,8 +165,8 @@ rp_probe(device_t dev) if (isa_get_logicalid(dev) != 0) return (ENXIO); - /* We need IO port resource to configure an ISA device. */ - if (bus_get_resource_count(dev, SYS_RES_IOPORT, 0) == 0) + /* We need IO port resource to configure an ISA device. */ + if (bus_get_resource_start(dev, SYS_RES_IOPORT, 0) == 0) return (ENXIO); unit = device_get_unit(dev); @@ -176,20 +185,23 @@ rp_probe(device_t dev) /* The IO ports of AIOPs for an ISA controller are discrete. */ ctlp->io_num = 1; - ctlp->io_rid = malloc(sizeof(*(ctlp->io_rid)) * MAX_AIOPS_PER_BOARD, M_DEVBUF, M_NOWAIT | M_ZERO); - ctlp->io = malloc(sizeof(*(ctlp->io)) * MAX_AIOPS_PER_BOARD, M_DEVBUF, M_NOWAIT | M_ZERO); + ctlp->io_rid = malloc(sizeof(*(ctlp->io_rid)) * MAX_AIOPS_PER_BOARD, M_DEVBUF, M_NOWAIT/* | M_ZERO*/); + ctlp->io = malloc(sizeof(*(ctlp->io)) * MAX_AIOPS_PER_BOARD, M_DEVBUF, M_NOWAIT/* | M_ZERO*/); if (ctlp->io_rid == NULL || ctlp->io == NULL) { device_printf(dev, "rp_attach: Out of memory.\n"); retval = ENOMEM; goto nogo; } + bzero(ctlp->io_rid, sizeof(*(ctlp->io_rid)) * MAX_AIOPS_PER_BOARD); + bzero(ctlp->io, sizeof(*(ctlp->io)) * MAX_AIOPS_PER_BOARD); - ctlp->bus_ctlp = malloc(sizeof(ISACONTROLLER_t) * 1, M_DEVBUF, M_NOWAIT | M_ZERO); + ctlp->bus_ctlp = malloc(sizeof(ISACONTROLLER_t) * 1, M_DEVBUF, M_NOWAIT/* | M_ZERO*/); if (ctlp->bus_ctlp == NULL) { device_printf(dev, "rp_attach: Out of memory.\n"); retval = ENOMEM; goto nogo; } + bzero(ctlp->bus_ctlp, sizeof(ISACONTROLLER_t) * 1); ctlp->io_rid[0] = 0; if (rp_controller != NULL) { @@ -218,6 +230,7 @@ rp_probe(device_t dev) if (rp_controller == NULL) rp_controller = controller; rp_nisadevs++; + num_devices_found++; device_set_desc(dev, "RocketPort ISA"); @@ -416,7 +429,7 @@ sInitController( CONTROLLER_T *CtlP, CtlP->NumAiop = 0; for(i=0; i < AiopNum; i++) { - if (CtlP->io[i] == NULL) { + if (i > 0 /*CtlP->io[i] == NULL*/) { CtlP->io_rid[i] = i; aiop_base = rman_get_start(CtlP->io[0]) + 0x400 * i; if (rp_nisadevs == 0) Index: rp_pci.c =================================================================== RCS file: /home/ncvs/src/sys/dev/rp/rp_pci.c,v retrieving revision 1.11 diff -u -p -r1.11 rp_pci.c --- rp_pci.c 25 Mar 2005 03:10:51 -0000 1.11 +++ rp_pci.c 27 Jan 2006 15:13:37 -0000 @@ -67,7 +67,19 @@ __FBSDID("$FreeBSD: src/sys/dev/rp/rp_pc #define RP_DEVICE_ID_4J 0x0007 #define RP_DEVICE_ID_6M 0x000C #define RP_DEVICE_ID_4M 0x000D -#define RP_DEVICE_ID_UPCI_8O 0x0805 +#define RP_DEVICE_ID_PL4 0x000A +#define RP_DEVICE_ID_PL8 0x000B +#define RP_DEVICE_ID_PL2 0x000E +#define RP_DEVICE_ID_U32 0x0801 +#define RP_DEVICE_ID_U8PL 0x0802 +#define RP_DEVICE_ID_U16 0x0803 +#define RP_DEVICE_ID_U8QO 0x0805 +#define RP_DEVICE_ID_UP8QO 0x080B +#define RP_DEVICE_ID_UP2 0x080E +#define RP_DEVICE_ID_UP2SMPTE 0x080F +#define RP_DEVICE_ID_UP4J 0x0810 +#define RP_DEVICE_ID_UP8J 0x0811 +#define RP_DEVICE_ID_UP422QO 0x0812 /************************************************************************** MUDBAC remapped for PCI @@ -75,9 +87,20 @@ __FBSDID("$FreeBSD: src/sys/dev/rp/rp_pc #define _CFG_INT_PCI 0x40 #define _PCI_INT_FUNC 0x3A +#define _UPCI_INT_FUNC 0x4 #define PCI_STROB 0x2000 +#define UPCI_STROB_C 0x0000 +#define UPCI_STROB_S 0x0001 + #define INTR_EN_PCI 0x0010 +#define INTR_EN_UPCI 0x0081 + +#define _UPCI_GPIO 0x54 +#define _UPCI_QUAD_IN 0x0000 +#define _UPCI_OCTAL_IN 0x4000 + +#define _UPCI_RING_IND 0xc /*************************************************************************** Function: sPCIControllerEOI @@ -100,6 +123,40 @@ Return: Byte_t: The controller interru */ #define sPCIGetControllerIntStatus(CTLP) ((rp_readio2(CTLP, 0, _PCI_INT_FUNC) >> 8) & 0x1f) +/*************************************************************************** + * Returns the state of RI. The following products have RI: + * UPCI 4/8 port, RP Plus 4/8 port, RP Plus 2 port 232/422 + * For all other devices, this function returns 0. + * + * Returns: 1 if RI is set, else 0. + */ +int sGetChanRI(CHANNEL_T * ChP) +{ + CONTROLLER_t *CtlP = ChP->CtlP; + int ChanNum = ChP->ChanNum; + int RingInd; + + switch (pci_get_device(CtlP->dev)) { + case RP_DEVICE_ID_U32: + case RP_DEVICE_ID_U8PL: + case RP_DEVICE_ID_U16: + case RP_DEVICE_ID_U8QO: + RingInd = !(rp_readio1(CtlP, 0, _UPCI_RING_IND) & rp_sBitMapSetTbl[ChanNum]); + break; + case RP_DEVICE_ID_PL4: + case RP_DEVICE_ID_PL8: + case RP_DEVICE_ID_PL2: + case RP_DEVICE_ID_UP8QO: + case RP_DEVICE_ID_UP2: + RingInd = rp_readch1(ChP, ((ChanNum * 2) + (_CHN_STAT0 + 8))) & DSR_ACT; + break; + default: + RingInd = 0; + } + + return RingInd; +} + static devclass_t rp_devclass; static int rp_pciprobe(device_t dev); @@ -114,7 +171,7 @@ static int sPCIInitController( CONTROLLE int IRQNum, Byte_t Frequency, int PeriodicOnly, - int VendorDevice); + uint16_t VendorDevice); static rp_aiop2rid_t rp_pci_aiop2rid; static rp_aiop2off_t rp_pci_aiop2off; static rp_ctlmask_t rp_pci_ctlmask; @@ -128,12 +185,88 @@ static int rp_pciprobe(device_t dev) { char *s; + uint16_t VenDev; - s = NULL; - if (pci_get_vendor(dev) == RP_VENDOR_ID) - s = "RocketPort PCI"; + if (num_devices_found >= 4) + return ENXIO; + s = NULL; + if (pci_get_vendor(dev) == RP_VENDOR_ID) { + VenDev = pci_get_device(dev); + switch( VenDev ) { + case RP_DEVICE_ID_4Q: + s = "RocketPort PCI Quad"; + break; + case RP_DEVICE_ID_4J: + s = "RocketPort PCI 4J"; + break; + case RP_DEVICE_ID_4M: + s = "RocketModem II PCI 4"; + break; + case RP_DEVICE_ID_PL4: + s = "RocketPort Plus PCI Quad"; + break; + case RP_DEVICE_ID_6M: + s = "RocketModem II PCI 6"; + break; + case RP_DEVICE_ID_8O: + s = "RocketPort PCI Octa"; + break; + case RP_DEVICE_ID_8J: + s = "RocketPort PCI 8J"; + break; + case RP_DEVICE_ID_8I: + s = "RocketPort PCI 8"; + break; + case RP_DEVICE_ID_U8PL: + s = "RocketPort Universal PCI 8 Low Profile"; + break; + case RP_DEVICE_ID_U8QO: + s = "RocketPort Universal PCI Quad/Octa"; + break; + case RP_DEVICE_ID_16I: + s = "RocketPort PCI 16"; + break; + case RP_DEVICE_ID_U16: + s = "RocketPort Universal PCI 16"; + break; + case RP_DEVICE_ID_32I: + s = "RocketPort PCI 32"; + break; + case RP_DEVICE_ID_U32: + s = "RocketPort Universal PCI 32"; + break; + case RP_DEVICE_ID_PL8: + s = "RocketPort Plus PCI Octa"; + break; + case RP_DEVICE_ID_PL2: + s = "RocketPort Plus PCI 2"; + break; + case RP_DEVICE_ID_UP8QO: + s = "RocketPort Plus Universal PCI Quad/Octa"; + break; + case RP_DEVICE_ID_UP2: + s = "RocketPort Plus Universal PCI 2"; + break; + case RP_DEVICE_ID_UP2SMPTE: + s = "RocketPort Plus Universal PCI 2 SMPTE"; + break; + case RP_DEVICE_ID_UP4J: + s = "RocketPort Plus Universal PCI 4J"; + break; + case RP_DEVICE_ID_UP8J: + s = "RocketPort Plus Universal PCI 8J"; + break; + case RP_DEVICE_ID_UP422QO: + s = "RocketPort Plus Universal PCI 422 Quad/Octa"; + break; + default: + s = NULL; + break; + } + } if (s != NULL) { + num_devices_found++; device_set_desc(dev, s); return (BUS_PROBE_DEFAULT); } @@ -149,10 +282,14 @@ rp_pciattach(device_t dev) CONTROLLER_t *ctlp; int unit; int retval; - u_int32_t stcmd; + uint32_t stcmd; + uint16_t VenDev; + VenDev = pci_get_device(dev); ctlp = device_get_softc(dev); bzero(ctlp, sizeof(*ctlp)); + + ctlp->CtlID = CTLID_0001; /* controller type 1 */ ctlp->dev = dev; unit = device_get_unit(dev); ctlp->aiop2rid = rp_pci_aiop2rid; @@ -167,36 +304,47 @@ rp_pciattach(device_t dev) } /* The IO ports of AIOPs for a PCI controller are continuous. */ - ctlp->io_num = 1; - ctlp->io_rid = malloc(sizeof(*(ctlp->io_rid)) * ctlp->io_num, M_DEVBUF, M_NOWAIT | M_ZERO); - ctlp->io = malloc(sizeof(*(ctlp->io)) * ctlp->io_num, M_DEVBUF, M_NOWAIT | M_ZERO); + if (cardIsUPCI(ctlp->dev)) /* if RocketPort UPCI with PLX chip */ + ctlp->io_num = 2; /* then setup two base addresses */ + else + ctlp->io_num = 1; /* or just setup one base address */ + ctlp->io_rid = malloc(sizeof(*(ctlp->io_rid)) * ctlp->io_num, M_DEVBUF, M_NOWAIT/* | M_ZERO*/); + ctlp->io = malloc(sizeof(*(ctlp->io)) * ctlp->io_num, M_DEVBUF, M_NOWAIT/* | M_ZERO*/); if (ctlp->io_rid == NULL || ctlp->io == NULL) { device_printf(dev, "rp_pciattach: Out of memory.\n"); retval = ENOMEM; goto nogo; } + bzero(ctlp->io_rid, sizeof(*(ctlp->io_rid)) * ctlp->io_num); + bzero(ctlp->io, sizeof(*(ctlp->io)) * ctlp->io_num); ctlp->bus_ctlp = NULL; - switch (pci_get_device(dev)) { - case RP_DEVICE_ID_UPCI_8O: - ctlp->io_rid[0] = PCIR_BAR(2); - break; - default: - ctlp->io_rid[0] = PCIR_BAR(0); - break; + if (cardIsUPCI(ctlp->dev)) { /* if RocketPort UPCI with PLX chip */ + ctlp->io_rid[0] = 0x18; /* then setup two base addresses */ + ctlp->io_rid[1] = 0x14; + } + else { + ctlp->io_rid[0] = 0x10; /* or just setup one base address */ } - ctlp->io[0] = bus_alloc_resource_any(dev, SYS_RES_IOPORT, - &ctlp->io_rid[0], RF_ACTIVE); + + ctlp->io[0] = bus_alloc_resource_any(dev, SYS_RES_IOPORT, &ctlp->io_rid[0], RF_ACTIVE); + /*device_printf(dev, "ioaddr (%x) mapping for RocketPort(PCI) is %08x.\n", ctlp->io_rid[0], ctlp->io[0]);*/ if(ctlp->io[0] == NULL) { device_printf(dev, "ioaddr mapping failed for RocketPort(PCI).\n"); retval = ENXIO; goto nogo; } - - num_aiops = sPCIInitController(ctlp, - MAX_AIOPS_PER_BOARD, 0, - FREQ_DIS, 0, pci_get_device(dev)); + if (cardIsUPCI(ctlp->dev)) { /* if RocketPort UPCI with PLX chip */ + ctlp->io[1] = bus_alloc_resource(dev, SYS_RES_IOPORT, &ctlp->io_rid[1], 0, ~0, 1, RF_ACTIVE); + /*device_printf(dev, "ioaddr (%x) mapping for RocketPort(UPCI) is %08x.\n", ctlp->io_rid[1], ctlp->io[1]);*/ + if(ctlp->io[1] == NULL) { + device_printf(dev, "ioaddr mapping failed for RocketPort(UPCI).\n"); + retval = ENXIO; + goto nogo; + } + } + num_aiops = sPCIInitController(ctlp, MAX_AIOPS_PER_BOARD, 0, FREQ_DIS, 0, VenDev); num_ports = 0; for(aiop=0; aiop < num_aiops; aiop++) { @@ -269,14 +417,68 @@ sPCIInitController( CONTROLLER_t *CtlP, int IRQNum, Byte_t Frequency, int PeriodicOnly, - int VendorDevice) + uint16_t VendorDevice) { - int i; - - CtlP->CtlID = CTLID_0001; /* controller release 1 */ + int i, AiopChanCnt, gpio_dat; - sPCIControllerEOI(CtlP); + if (cardIsUPCI(CtlP->dev)) /* if RocketPort UPCI with PLX chip */ + rp_writeio2(CtlP, 1, _UPCI_INT_FUNC, 0x0000); /* disable ints */ + else + sPCIControllerEOI(CtlP); + switch( VendorDevice ) { + case RP_DEVICE_ID_4Q: + case RP_DEVICE_ID_4J: + case RP_DEVICE_ID_4M: + case RP_DEVICE_ID_PL4: + case RP_DEVICE_ID_UP4J: + AiopChanCnt = 4; + AiopNum = 1; + break; + case RP_DEVICE_ID_6M: + AiopChanCnt = 6; + AiopNum = 1; + break; + case RP_DEVICE_ID_8O: + case RP_DEVICE_ID_8J: + case RP_DEVICE_ID_8I: + case RP_DEVICE_ID_U8PL: + case RP_DEVICE_ID_U8QO: + AiopNum = 1; + AiopChanCnt = 8; + break; + case RP_DEVICE_ID_16I: + case RP_DEVICE_ID_U16: + AiopNum = 2; + AiopChanCnt = 8; + break; + case RP_DEVICE_ID_32I: + case RP_DEVICE_ID_U32: + AiopNum = 4; + AiopChanCnt = 8; + break; + case RP_DEVICE_ID_PL8: + case RP_DEVICE_ID_UP8J: + case RP_DEVICE_ID_UP8QO: + case RP_DEVICE_ID_UP422QO: + AiopNum = 2; + AiopChanCnt = 4; + break; + case RP_DEVICE_ID_PL2: + case RP_DEVICE_ID_UP2: + case RP_DEVICE_ID_UP2SMPTE: + AiopNum = 1; + AiopChanCnt = 2; + break; + default: + AiopNum = 1; +#if notdef + AiopChanCnt = 8; +#else + AiopChanCnt = sReadAiopNumChan(CtlP, 0); +#endif /* notdef */ + break; + } /* Init AIOPs */ CtlP->NumAiop = 0; for(i=0; i < AiopNum; i++) @@ -288,39 +490,24 @@ sPCIInitController( CONTROLLER_t *CtlP, { break; /* done looking for AIOPs */ } - - switch( VendorDevice ) { - case RP_DEVICE_ID_4Q: - case RP_DEVICE_ID_4J: - case RP_DEVICE_ID_4M: - CtlP->AiopNumChan[i] = 4; - break; - case RP_DEVICE_ID_6M: - CtlP->AiopNumChan[i] = 6; - break; - case RP_DEVICE_ID_8O: - case RP_DEVICE_ID_8J: - case RP_DEVICE_ID_8I: - case RP_DEVICE_ID_16I: - case RP_DEVICE_ID_32I: - CtlP->AiopNumChan[i] = 8; - break; - default: -#if notdef - CtlP->AiopNumChan[i] = 8; -#else - CtlP->AiopNumChan[i] = sReadAiopNumChan(CtlP, i); -#endif /* notdef */ - break; + if (VendorDevice == RP_DEVICE_ID_U8QO) { /* if UPCI QUAD/OCTAL board */ + gpio_dat = rp_readio2(CtlP, 1, _UPCI_GPIO); /* read GPIO reg */ + if (!(gpio_dat & _UPCI_OCTAL_IN)) /* if quad cable attached, */ + AiopChanCnt = 4; /* set for only four channels */ } + CtlP->AiopNumChan[i] = AiopChanCnt; /*device_printf(CtlP->dev, "%d channels.\n", CtlP->AiopNumChan[i]);*/ rp_writeaiop2(CtlP, i, _INDX_ADDR,_CLK_PRE); /* clock prescaler */ - /*device_printf(CtlP->dev, "configuring clock prescaler.\n");*/ - rp_writeaiop1(CtlP, i, _INDX_DATA,CLOCK_PRESC); - /*device_printf(CtlP->dev, "configured clock prescaler.\n");*/ + if (cardIsRocketportPlus(CtlP->dev)) { + rp_writeaiop1(CtlP, i, _INDX_DATA, AB_CLOCK_PRESC); + /*device_printf(CtlP->dev, "configured clock prescaler (%04x = %02x).\n",_CLK_PRE, AB_CLOCK_PRESC);*/ + } + else { + rp_writeaiop1(CtlP, i, _INDX_DATA, CLOCK_PRESC); + /*device_printf(CtlP->dev, "configured clock prescaler (%04x = %02x).\n",_CLK_PRE, CLOCK_PRESC);*/ + } CtlP->NumAiop++; /* bump count of AIOPs */ } - if(CtlP->NumAiop == 0) return(-1); else @@ -353,7 +540,80 @@ rp_pci_aiop2off(int aiop, int offset) static unsigned char rp_pci_ctlmask(CONTROLLER_t *ctlp) { - return sPCIGetControllerIntStatus(ctlp); + int cmsk; + unsigned char cret=0; + + if (cardIsUPCI(ctlp->dev)) { /* if RocketPort UPCI with PLX chip */ + cmsk = rp_readio2(ctlp, 1, _UPCI_GPIO); + if (cmsk & UINTSTAT0) /* convert PLX int bits to AIOPIC int bits */ + cret |= INTSTAT0; + if (cmsk & UINTSTAT1) + cret |= INTSTAT1; + if (cmsk & UINTSTAT2) + cret |= INTSTAT2; + if (cmsk & UINTSTAT3) + cret |= INTSTAT3; + cmsk = rp_readio2(ctlp, 1, _UPCI_INT_FUNC); /* get int active bit */ + if (cmsk & UINTACT) + cret |= 0x10; + return cret; + } + else { + return sPCIGetControllerIntStatus(ctlp); + } +} +int +cardIsUPCI(device_t dev) +{ + uint16_t VenDev; + int upci_fnd; + + upci_fnd = FALSE; + VenDev = pci_get_device(dev); + switch( VenDev ) { + case RP_DEVICE_ID_U8PL: + case RP_DEVICE_ID_U8QO: + case RP_DEVICE_ID_U16: + case RP_DEVICE_ID_U32: + case RP_DEVICE_ID_UP8QO: + case RP_DEVICE_ID_UP2: + case RP_DEVICE_ID_UP2SMPTE: + case RP_DEVICE_ID_UP4J: + case RP_DEVICE_ID_UP8J: + case RP_DEVICE_ID_UP422QO: + upci_fnd = TRUE; /* controller with PLX9030 chip */ + break; + default: + upci_fnd = FALSE; + break; + } + return(upci_fnd); +} +int +cardIsRocketportPlus(device_t dev) +{ + uint16_t VenDev; + int rpl_fnd; + + rpl_fnd = FALSE; + VenDev = pci_get_device(dev); + switch( VenDev ) { + case RP_DEVICE_ID_PL4: + case RP_DEVICE_ID_PL8: + case RP_DEVICE_ID_PL2: + case RP_DEVICE_ID_UP8QO: + case RP_DEVICE_ID_UP2: + case RP_DEVICE_ID_UP2SMPTE: + case RP_DEVICE_ID_UP4J: + case RP_DEVICE_ID_UP8J: + case RP_DEVICE_ID_UP422QO: + rpl_fnd = TRUE; /* RocketPort Plus board */ + break; + default: + rpl_fnd = FALSE; + break; + } + return(rpl_fnd); } static device_method_t rp_pcimethods[] = { Index: rpreg.h =================================================================== RCS file: /home/ncvs/src/sys/dev/rp/rpreg.h,v retrieving revision 1.7 diff -u -p -r1.7 rpreg.h --- rpreg.h 6 Jan 2005 01:43:11 -0000 1.7 +++ rpreg.h 27 Jan 2006 15:13:38 -0000 @@ -60,12 +60,12 @@ typedef unsigned int DWordIO_t; #define rp_writeio1(ctlp, rid, offset, data) rp_writeio(1, ctlp, rid, offset, data) #define rp_writeio2(ctlp, rid, offset, data) rp_writeio(2, ctlp, rid, offset, data) #define rp_writeio4(ctlp, rid, offset, data) rp_writeio(4, ctlp, rid, offset, data) -#define rp_readmultiio1(ctlp, rid, offset, addr, count) rp_readmultiio(1, ctlp, rid, offset, addr, count) -#define rp_readmultiio2(ctlp, rid, offset, addr, count) rp_readmultiio(2, ctlp, rid, offset, addr, count) -#define rp_readmultiio4(ctlp, rid, offset, addr, count) rp_readmultiio(4, ctlp, rid, offset, addr, count) -#define rp_writemultiio1(ctlp, rid, offset, addr, count) rp_writemultiio(1, ctlp, rid, offset, addr, count) -#define rp_writemultiio2(ctlp, rid, offset, addr, count) rp_writemultiio(2, ctlp, rid, offset, addr, count) -#define rp_writemultiio4(ctlp, rid, offset, addr, count) rp_writemultiio(4, ctlp, rid, offset, addr, count) +#define rp_readmultiio1(ctlp, rid, offset, addr, count) rp_readmultiio(1, ctlp, rid, offset, addr, count) +#define rp_readmultiio2(ctlp, rid, offset, addr, count) rp_readmultiio(2, ctlp, rid, offset, addr, count) +#define rp_readmultiio4(ctlp, rid, offset, addr, count) rp_readmultiio(4, ctlp, rid, offset, addr, count) +#define rp_writemultiio1(ctlp, rid, offset, addr, count) rp_writemultiio(1, ctlp, rid, offset, addr, count) +#define rp_writemultiio2(ctlp, rid, offset, addr, count) rp_writemultiio(2, ctlp, rid, offset, addr, count) +#define rp_writemultiio4(ctlp, rid, offset, addr, count) rp_writemultiio(4, ctlp, rid, offset, addr, count) #define rp_readaiop1(ctlp, aiop, offset) \ (rp_readio1((ctlp), (ctlp)->aiop2rid(aiop, offset), (ctlp)->aiop2off(aiop, offset))) @@ -133,6 +133,8 @@ typedef unsigned int DWordIO_t; /* Controller ID numbers */ #define CTLID_NULL -1 /* no controller exists */ #define CTLID_0001 0x0001 /* controller release 1 */ +#define CTLID_0002 0x0002 /* controller with PLX9030 chip */ +#define CTLID_0003 0x0003 /* Rocketport Plus board */ /* AIOP ID numbers, identifies AIOP type implementing channel */ #define AIOPID_NULL -1 /* no AIOP or channel exists */ @@ -213,8 +215,11 @@ Channel Register Offsets - Indexed - Int #define _BAUD 0xFF4 /* Baud Rate 16 Write */ #define _CLK_PRE 0xFF6 /* Clock Prescaler 8 Write */ +/************************************************************************ + Baud rate divisors using mod 9 clock prescaler and 36.873 clock +************************************************************************/ #define CLOCK_PRESC 0x19 /* mod 9 (divide by 10) prescale */ - +#define BRD0 3 /* tps remapped for 57.6KB */ #define BRD50 4607 #define BRD75 3071 #define BRD110 2094 @@ -238,6 +243,35 @@ Channel Register Offsets - Indexed - Int #define BRD76800 2 #define BRD115200 1 #define BRD230400 0 +/************************************************************************ + Baud rate divisors using mod 2 clock prescaler and 44.2368 clock +************************************************************************/ +#define AB_CLOCK_PRESC 0x12 /* mod 2 prescale */ +#define AB_BRD0 3 /* tps remapped for 57.6KB */ +#define AB_BRD50 18431 +#define AB_BRD75 12287 +#define AB_BRD110 8377 +#define AB_BRD134 6852 +#define AB_BRD150 6143 +#define AB_BRD200 4607 +#define AB_BRD300 3071 +#define AB_BRD600 1535 +#define AB_BRD1200 767 +#define AB_BRD1800 511 +#define AB_BRD2400 383 +#define AB_BRD4800 191 +#define AB_BRD7200 127 +#define AB_BRD9600 95 +#define AB_BRD14400 63 +#define AB_BRD19200 47 +#define AB_BRD28800 31 +#define AB_BRD38400 23 +#define AB_BRD57600 15 +#define AB_BRD76800 11 +#define AB_BRD115200 7 +#define AB_BRD230400 3 +#define AB_BRD460800 2 +#define AB_BRD921600 0 #define STMBREAK 0x08 /* BREAK */ #define STMFRAME 0x04 /* framing error */ @@ -316,6 +350,12 @@ Channel Register Offsets - Indexed - Int #define INTSTAT2 0x04 /* AIOP 2 interrupt status */ #define INTSTAT3 0x08 /* AIOP 3 interrupt status */ +#define UINTACT 0x04 /* UPCI AIOP Interrupt active */ +#define UINTSTAT0 0x04 /* UPCI AIOP 0 interrupt status */ +#define UINTSTAT1 0x20 /* UPCI AIOP 1 interrupt status */ +#define UINTSTAT2 0x100 /* UPCI AIOP 2 interrupt status */ +#define UINTSTAT3 0x800 /* UPCI AIOP 3 interrupt status */ + #define INTR_EN 0x08 /* allow interrupts to host */ #define INT_STROB 0x04 /* strobe and clear interrupt line (EOI) */ @@ -1004,7 +1044,12 @@ void sEnInterrupts(CHANNEL_T *ChP,Word_t void sDisInterrupts(CHANNEL_T *ChP,Word_t Flags); int rp_attachcommon(CONTROLLER_T *ctlp, int num_aiops, int num_ports); void rp_releaseresource(CONTROLLER_t *ctlp); +int cardIsUPCI(device_t dev); +int cardIsRocketportPlus(device_t dev); +int sGetChanRI(CHANNEL_T * ChP); void rp_untimeout(void); +extern int next_unit_number; +extern int num_devices_found; #ifndef ROCKET_C extern Byte_t R[RDATASIZE]; Index: rpvar.h =================================================================== RCS file: /home/ncvs/src/sys/dev/rp/rpvar.h,v retrieving revision 1.8 diff -u -p -r1.8 rpvar.h --- rpvar.h 6 Jan 2005 01:43:11 -0000 1.8 +++ rpvar.h 27 Jan 2006 15:13:38 -0000 @@ -63,8 +63,8 @@ struct rp_port { int rp_xmit_stopped:1; CONTROLLER_t * rp_ctlp; CHANNEL_t rp_channel; - unsigned short TxBuf[TXFIFO_SIZE/2 +1]; - unsigned short RxBuf[RXFIFO_SIZE/2 +1]; + unsigned short TxBuf[TXFIFO_SIZE/2 + 1]; + unsigned short RxBuf[RXFIFO_SIZE/2 + 1]; }; /* Actually not used */ From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 27 15:42:18 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 22EF916A420; Fri, 27 Jan 2006 15:42:18 +0000 (GMT) (envelope-from lists@intricatesoftware.com) Received: from mta2.srv.hcvlny.cv.net (mta2.srv.hcvlny.cv.net [167.206.4.197]) by mx1.FreeBSD.org (Postfix) with ESMTP id 13B9E43DD1; Fri, 27 Jan 2006 15:42:16 +0000 (GMT) (envelope-from lists@intricatesoftware.com) Received: from [172.16.1.72] (ool-457a77e8.dyn.optonline.net [69.122.119.232]) by mta2.srv.hcvlny.cv.net (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTP id <0ITR00EWUCY4OP81@mta2.srv.hcvlny.cv.net>; Fri, 27 Jan 2006 10:42:05 -0500 (EST) Date: Fri, 27 Jan 2006 10:42:04 -0500 From: Kurt Miller In-reply-to: To: Daniel Eischen Message-id: <200601271042.04315.lists@intricatesoftware.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline References: User-Agent: KMail/1.9 Cc: freebsd-hackers@freebsd.org Subject: Re: read hang on datagram socket X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: kurt@intricatesoftware.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2006 15:42:18 -0000 On Friday 27 January 2006 9:16 am, Daniel Eischen wrote: > On Thu, 26 Jan 2006, Kurt Miller wrote: > > > On Thursday 26 January 2006 7:26 pm, Daniel Eischen wrote: > > > > > > The modified version does not hang on 5.2. Do you have multiple > > > interfaces on your 5.4 box? > > > > No, the 5.4 box is virtually identical to the 6.0 box. I set them both > > up at the same time from initial installs for the project. > > > > truk@freebsd5-4$ ifconfig > > lnc0: flags=108843 mtu 1500 > > inet6 fe80::250:56ff:fe40:451a%lnc0 prefixlen 64 scopeid 0x1 > > inet 172.16.1.36 netmask 0xffffff00 broadcast 172.16.1.255 > > ether 00:50:56:40:45:1a > > lo0: flags=8049 mtu 16384 > > inet 127.0.0.1 netmask 0xff000000 > > inet6 ::1 prefixlen 128 > > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 > > [ ... ] > > > > What happens when you try using non-zero IP addresses and ports? > > > > > > > Setting the ports doesn't effect the problem, however setting the > > addresses does. It really seems like binding to INADDR_ANY only binds > > to loopback address 127.0.0.1 and not all the interfaces. > > > > If sock1 is bound to the hostAddress and sock2 connects to sock1 at > > the hostAddress it works ok. If sock1 is bound to INADDR_ANY and sock2 > > connects to sock1 using INADDR_ANY it works. but any mixture of of > > using INADDR_ANY with the hostAddress fails. > > According to Steven's Network Programming, when binding to > INADDR_ANY, the operating system doesn't assign an address > until the first write. This is unlike the port, where using > port 0, an ephemeral port is assigned right away. I don't > have the book handy right now, so I forgot if the INADDR_ANY > behavior is only when you have multiple interfaces or not. The book I'm using is not that clear about it (Advanced Programming in the UNIX Environment). It does say that using connect with a datagram socket will receive datagrams only from the address specified, which seems related to the problem. > > Unfortunately, I don't have control over the addresses, the java > > programs do. This particular jck test binds the first socket with > > INADDR_ANY (InetAddress.getByName("0.0.0.0")) and connects the second > > socket to the first using the hostAddress (InetAddress.getLocalHost()). > > You can try sending a byte before getting the address for the > port and see if that works. Do you have anything weird, like > not having a default route (gateway)? Yes, sending a byte before doing the connect(sock2, &sock1Addres does work. However, calling connect/send/read after that fails too. The problem appears to be related to sock1's selection of it source address, or perhaps the connect call is ignoring the hostAddress and using the loopback address. The netstat output leads me to believe it is the latter. It is behaving like a mismatch between source address of the message and the address enforced by the connect call. I've confirmed that the sock1Addr struct is filled in correctly with the hostAddress and port of sock1 and sock2Addr is filled in correctly with the hostAddress and port of sock2. I've got a pretty standard setup. All three machines are using DHCP to get their addresses, default route and name servers. I've set the dhcp server to give them the same IP addresses each time. Here's the routing table for each: truk@freebsd6-0$ netstat -r -f inet Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 172.16.1.1 UGS 0 34 lnc0 localhost localhost UH 0 0 lo0 172.16.1/24 link#1 UC 0 0 lnc0 172.16.1.1 00:00:24:c2:47:b5 UHLW 2 0 lnc0 671 172.16.1.10 00:13:46:c9:0a:5c UHLW 1 0 lnc0 1103 172.16.1.72 00:12:f0:b5:f4:6c UHLW 1 118 lnc0 961 truk@freebsd5-4$ netstat -r -f inet Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 172.16.1.1 UGS 0 112 lnc0 localhost localhost UH 1 19 lo0 172.16.1/24 link#1 UC 0 0 lnc0 172.16.1.1 00:00:24:c2:47:b5 UHLW 1 0 lnc0 40 172.16.1.10 00:13:46:c9:0a:5c UHLW 0 0 lnc0 1106 172.16.1.36 localhost UGHS 0 7 lo0 172.16.1.72 00:12:f0:b5:f4:6c UHLW 0 3151 lnc0 749 $ netstat -r -f inet #freebsd4-11 Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 172.16.1.1 UGSc 1 0 lnc0 localhost localhost UH 1 0 lo0 172.16.1/24 link#1 UC 2 0 lnc0 172.16.1.1 00:00:24:c2:47:b5 UHLW 2 0 lnc0 1200 172.16.1.30 localhost UGHS 0 0 lo0 172.16.1.72 00:12:f0:b5:f4:6c UHLW 1 112 lnc0 1195 Thanks for the ideas and suggestions. -Kurt From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 27 15:50:38 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7608A16A424; Fri, 27 Jan 2006 15:50:38 +0000 (GMT) (envelope-from lists@intricatesoftware.com) Received: from mta2.srv.hcvlny.cv.net (mta2.srv.hcvlny.cv.net [167.206.4.197]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9CD3F43E4C; Fri, 27 Jan 2006 14:17:08 +0000 (GMT) (envelope-from lists@intricatesoftware.com) Received: from [172.16.1.72] (ool-457a77e8.dyn.optonline.net [69.122.119.232]) by mta2.srv.hcvlny.cv.net (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTP id <0ITR00EZO90JOP41@mta2.srv.hcvlny.cv.net>; Fri, 27 Jan 2006 09:17:08 -0500 (EST) Date: Fri, 27 Jan 2006 09:17:06 -0500 From: Kurt Miller In-reply-to: <43D9F8AD.2020502@shapeshifter.se> To: freebsd-hackers@freebsd.org Message-id: <200601270917.06842.lists@intricatesoftware.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline References: <200601262340.46999.lists@intricatesoftware.com> <43D9F8AD.2020502@shapeshifter.se> User-Agent: KMail/1.9 Cc: Fredrik Lindberg , Daniel Eischen Subject: Re: read hang on datagram socket X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: kurt@intricatesoftware.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2006 15:50:38 -0000 On Friday 27 January 2006 5:40 am, Fredrik Lindberg wrote: > Kurt Miller wrote: > > netstat output when stopping the program at the sendto call on 5.4 > > looks like this: > > udp4 0 0 localhost.55513 172.16.1.36.52099 > > > > on 6.0: > > udp4 0 0 172.16.1.37.53952 172.16.1.37.62241 > > > > Doesn't the above output indicate a problem with how datagram > > sockets are bound to INADDR_ANY? > > > > Perhaps its related to my configuration. Can anyone else with a > > 5.4-release system try the program to see if it works for them? > > > > It works on a 5.4-RELEASE-p5 system. > fli> ./test > no hang > > fli> ifconfig > em0: flags=8843 mtu 1500 > options=b > inet 212.XX.XX.XX netmask 0xfffffff8 broadcast 212.XX.XX.XX > inet6 fe80::240:d0ff:fe43:b964%em0 prefixlen 64 scopeid 0x1 > ether 00:40:d0:43:b9:64 > media: Ethernet autoselect (100baseTX ) > status: active > em1: flags=8802 mtu 1500 > options=b > ether 00:40:d0:43:b9:65 > media: Ethernet autoselect > status: no carrier > lo0: flags=8049 mtu 16384 > inet 127.0.0.1 netmask 0xff000000 > inet6 ::1 prefixlen 128 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 > > > Stopping it before sendto() gives > udp4 0 0 212.XX.XX.XX.54074 212.XX.XX.XX.56604 > Thanks for trying it out. I updated my kernel to p10 and the problem persists for me. I guess that makes the issue a configuration issue or a possibly a lnc driver issue. At the moment I can't think of anything in my configuration that is different for the 5-4 install. I'll work on trying a different nic next. -Kurt From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 27 18:37:25 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5494E16A426 for ; Fri, 27 Jan 2006 18:37:25 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id E646243E1F for ; Fri, 27 Jan 2006 14:16:09 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.ntplx.net (8.13.5/8.13.5/NETPLEX) with ESMTP id k0REG8QL012423; Fri, 27 Jan 2006 09:16:08 -0500 (EST) Date: Fri, 27 Jan 2006 09:16:08 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Kurt Miller In-Reply-To: <200601262340.46999.lists@intricatesoftware.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) Cc: freebsd-hackers@freebsd.org Subject: Re: read hang on datagram socket X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2006 18:37:25 -0000 On Thu, 26 Jan 2006, Kurt Miller wrote: > On Thursday 26 January 2006 7:26 pm, Daniel Eischen wrote: > > > > The modified version does not hang on 5.2. Do you have multiple > > interfaces on your 5.4 box? > > No, the 5.4 box is virtually identical to the 6.0 box. I set them both > up at the same time from initial installs for the project. > > truk@freebsd5-4$ ifconfig > lnc0: flags=108843 mtu 1500 > inet6 fe80::250:56ff:fe40:451a%lnc0 prefixlen 64 scopeid 0x1 > inet 172.16.1.36 netmask 0xffffff00 broadcast 172.16.1.255 > ether 00:50:56:40:45:1a > lo0: flags=8049 mtu 16384 > inet 127.0.0.1 netmask 0xff000000 > inet6 ::1 prefixlen 128 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 [ ... ] > > What happens when you try using non-zero IP addresses and ports? > > > > Setting the ports doesn't effect the problem, however setting the > addresses does. It really seems like binding to INADDR_ANY only binds > to loopback address 127.0.0.1 and not all the interfaces. > > If sock1 is bound to the hostAddress and sock2 connects to sock1 at > the hostAddress it works ok. If sock1 is bound to INADDR_ANY and sock2 > connects to sock1 using INADDR_ANY it works. but any mixture of of > using INADDR_ANY with the hostAddress fails. According to Steven's Network Programming, when binding to INADDR_ANY, the operating system doesn't assign an address until the first write. This is unlike the port, where using port 0, an ephemeral port is assigned right away. I don't have the book handy right now, so I forgot if the INADDR_ANY behavior is only when you have multiple interfaces or not. > Unfortunately, I don't have control over the addresses, the java > programs do. This particular jck test binds the first socket with > INADDR_ANY (InetAddress.getByName("0.0.0.0")) and connects the second > socket to the first using the hostAddress (InetAddress.getLocalHost()). You can try sending a byte before getting the address for the port and see if that works. Do you have anything weird, like not having a default route (gateway)? -- DE From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 27 19:35:10 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 49BC116A422; Fri, 27 Jan 2006 19:35:10 +0000 (GMT) (envelope-from lists@intricatesoftware.com) Received: from mta1.srv.hcvlny.cv.net (mta1.srv.hcvlny.cv.net [167.206.4.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5B1C943D80; Fri, 27 Jan 2006 19:34:56 +0000 (GMT) (envelope-from lists@intricatesoftware.com) Received: from [172.16.1.72] (ool-457a77e8.dyn.optonline.net [69.122.119.232]) by mta1.srv.hcvlny.cv.net (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTP id <0ITR00H21NQ7KX20@mta1.srv.hcvlny.cv.net>; Fri, 27 Jan 2006 14:34:55 -0500 (EST) Date: Fri, 27 Jan 2006 14:34:54 -0500 From: Kurt Miller In-reply-to: <200601271042.04315.lists@intricatesoftware.com> To: freebsd-hackers@freebsd.org Message-id: <200601271434.54776.lists@intricatesoftware.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline References: <200601271042.04315.lists@intricatesoftware.com> User-Agent: KMail/1.9 Cc: Daniel Eischen Subject: Re: read hang on datagram socket X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: kurt@intricatesoftware.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2006 19:35:10 -0000 On Friday 27 January 2006 10:42 am, Kurt Miller wrote: > On Friday 27 January 2006 9:16 am, Daniel Eischen wrote: > > On Thu, 26 Jan 2006, Kurt Miller wrote: > > > > > On Thursday 26 January 2006 7:26 pm, Daniel Eischen wrote: > > > > > > > > The modified version does not hang on 5.2. Do you have multiple > > > > interfaces on your 5.4 box? > > > > > > No, the 5.4 box is virtually identical to the 6.0 box. I set them both > > > up at the same time from initial installs for the project. > > > > > > truk@freebsd5-4$ ifconfig > > > lnc0: flags=108843 mtu 1500 > > > inet6 fe80::250:56ff:fe40:451a%lnc0 prefixlen 64 scopeid 0x1 > > > inet 172.16.1.36 netmask 0xffffff00 broadcast 172.16.1.255 > > > ether 00:50:56:40:45:1a > > > lo0: flags=8049 mtu 16384 > > > inet 127.0.0.1 netmask 0xff000000 > > > inet6 ::1 prefixlen 128 > > > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 > > > > [ ... ] > > > > > > What happens when you try using non-zero IP addresses and ports? > > > > > > > > > > Setting the ports doesn't effect the problem, however setting the > > > addresses does. It really seems like binding to INADDR_ANY only binds > > > to loopback address 127.0.0.1 and not all the interfaces. > > > > > > If sock1 is bound to the hostAddress and sock2 connects to sock1 at > > > the hostAddress it works ok. If sock1 is bound to INADDR_ANY and sock2 > > > connects to sock1 using INADDR_ANY it works. but any mixture of of > > > using INADDR_ANY with the hostAddress fails. > > > > According to Steven's Network Programming, when binding to > > INADDR_ANY, the operating system doesn't assign an address > > until the first write. This is unlike the port, where using > > port 0, an ephemeral port is assigned right away. I don't > > have the book handy right now, so I forgot if the INADDR_ANY > > behavior is only when you have multiple interfaces or not. > > The book I'm using is not that clear about it (Advanced > Programming in the UNIX Environment). It does say that using > connect with a datagram socket will receive datagrams only > from the address specified, which seems related to the problem. > > > > Unfortunately, I don't have control over the addresses, the java > > > programs do. This particular jck test binds the first socket with > > > INADDR_ANY (InetAddress.getByName("0.0.0.0")) and connects the second > > > socket to the first using the hostAddress (InetAddress.getLocalHost()). > > > > You can try sending a byte before getting the address for the > > port and see if that works. Do you have anything weird, like > > not having a default route (gateway)? > > Yes, sending a byte before doing the connect(sock2, &sock1Addres > does work. However, calling connect/send/read after that fails too. > The problem appears to be related to sock1's selection of it source > address, or perhaps the connect call is ignoring the hostAddress and > using the loopback address. The netstat output leads me to believe > it is the latter. It is behaving like a mismatch between source > address of the message and the address enforced by the connect call. > > I've confirmed that the sock1Addr struct is filled in correctly with > the hostAddress and port of sock1 and sock2Addr is filled in correctly > with the hostAddress and port of sock2. > > I've got a pretty standard setup. All three machines are using DHCP > to get their addresses, default route and name servers. I've set > the dhcp server to give them the same IP addresses each time. Here's > the routing table for each: > > truk@freebsd6-0$ netstat -r -f inet > Routing tables > > Internet: > Destination Gateway Flags Refs Use Netif Expire > default 172.16.1.1 UGS 0 34 lnc0 > localhost localhost UH 0 0 lo0 > 172.16.1/24 link#1 UC 0 0 lnc0 > 172.16.1.1 00:00:24:c2:47:b5 UHLW 2 0 lnc0 671 > 172.16.1.10 00:13:46:c9:0a:5c UHLW 1 0 lnc0 1103 > 172.16.1.72 00:12:f0:b5:f4:6c UHLW 1 118 lnc0 961 > > truk@freebsd5-4$ netstat -r -f inet > Routing tables > > Internet: > Destination Gateway Flags Refs Use Netif Expire > default 172.16.1.1 UGS 0 112 lnc0 > localhost localhost UH 1 19 lo0 > 172.16.1/24 link#1 UC 0 0 lnc0 > 172.16.1.1 00:00:24:c2:47:b5 UHLW 1 0 lnc0 40 > 172.16.1.10 00:13:46:c9:0a:5c UHLW 0 0 lnc0 1106 > 172.16.1.36 localhost UGHS 0 7 lo0 > 172.16.1.72 00:12:f0:b5:f4:6c UHLW 0 3151 lnc0 749 > > $ netstat -r -f inet #freebsd4-11 > Routing tables > > Internet: > Destination Gateway Flags Refs Use Netif Expire > default 172.16.1.1 UGSc 1 0 lnc0 > localhost localhost UH 1 0 lo0 > 172.16.1/24 link#1 UC 2 0 lnc0 > 172.16.1.1 00:00:24:c2:47:b5 UHLW 2 0 lnc0 1200 > 172.16.1.30 localhost UGHS 0 0 lo0 > 172.16.1.72 00:12:f0:b5:f4:6c UHLW 1 112 lnc0 1195 > > Thanks for the ideas and suggestions. The problem turned out to be related to how dhcp sets up the routing table. Switching to a fixed address setup adjusted the routing table and now the the program works. Go figure. Here's the routing table when using a fixed address: Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 172.16.1.1 UGS 0 48 lnc0 localhost localhost UH 0 0 lo0 172.16.1/24 link#1 UC 0 0 lnc0 172.16.1.1 00:00:24:c2:47:b5 UHLW 1 0 lnc0 1200 172.16.1.20 00:07:e9:47:0f:f9 UHLW 0 2 lnc0 429 172.16.1.21 00:40:96:39:b6:f9 UHLW 0 3 lnc0 1197 172.16.1.36 00:50:56:40:45:1a UHLW 0 1 lo0 172.16.1.72 00:12:f0:b5:f4:6c UHLW 0 637 lnc0 1187 Notice the difference in the gateway for 172.16.1.36. Thanks for all the help and suggestions. -Kurt From owner-freebsd-hackers@FreeBSD.ORG Sat Jan 28 07:10:40 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 69A1016A420 for ; Sat, 28 Jan 2006 07:10:40 +0000 (GMT) (envelope-from lorenl@alzatex.com) Received: from hosea.tallye.com (joel.tallye.com [216.99.199.78]) by mx1.FreeBSD.org (Postfix) with ESMTP id C7B6543D45 for ; Sat, 28 Jan 2006 07:10:39 +0000 (GMT) (envelope-from lorenl@alzatex.com) Received: from hosea.tallye.com (localhost.localdomain [127.0.0.1]) by hosea.tallye.com (8.12.8/8.12.10) with ESMTP id k0S7AcBd017563 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 27 Jan 2006 23:10:38 -0800 Received: (from sttng359@localhost) by hosea.tallye.com (8.12.8/8.12.8/Submit) id k0S7AcNT017561 for freebsd-hackers@freebsd.org; Fri, 27 Jan 2006 23:10:38 -0800 Date: Fri, 27 Jan 2006 23:10:38 -0800 From: "Loren M. Lang" To: FreeBSD Hackers Message-ID: <20060128071038.GA17471@alzatex.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="NzB8fVQJ5HfG6fxh" Content-Disposition: inline User-Agent: Mutt/1.4.1i X-GPG-Key: ftp://ftp.tallye.com/pub/lorenl_pubkey.asc X-GPG-Fingerprint: B3B9 D669 69C9 09EC 1BCD 835A FAF3 7A46 E4A3 280C X-Virus-Scanned: ClamAV version 0.87, clamav-milter version 0.87 on hosea.tallye.com X-Virus-Status: Clean Subject: FreeBSD Real Mode interface X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jan 2006 07:10:40 -0000 --NzB8fVQJ5HfG6fxh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Is there any equivalent to the Linux Real Mode interface in FreeBSD? I would like to port a program called atitvout to FreeBSD, but it uses calls to the vesa bios in real mode on the x86 arch. I can't seem to find out how to do this in FreeBSD. --=20 Loren M. Lang lorenl@north-winds.org http://www.north-winds.org/ Public Key: ftp://ftp.north-winds.org/pub/lorenl_pubkey.asc Fingerprint: CEE1 AAE2 F66C 59B5 34CA C415 6D35 E847 0118 A3D2 =20 --NzB8fVQJ5HfG6fxh Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFD2xjubTXoRwEYo9IRAn0SAJ9uGA1GI57zhcS1iIrA/wmZUJ/48ACfVV1u VUgt2X9dXRtrpdMPvM1YId4= =kK77 -----END PGP SIGNATURE----- --NzB8fVQJ5HfG6fxh-- From owner-freebsd-hackers@FreeBSD.ORG Sat Jan 28 09:00:51 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A71F616A420 for ; Sat, 28 Jan 2006 09:00:51 +0000 (GMT) (envelope-from mistry.7@osu.edu) Received: from mail.united-ware.com (am-productions.biz [69.61.164.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 30D3B43D45 for ; Sat, 28 Jan 2006 09:00:48 +0000 (GMT) (envelope-from mistry.7@osu.edu) Received: from [192.168.1.100] (am-productions.biz [69.61.164.22]) (authenticated bits=0) by mail.united-ware.com (8.13.4/8.13.4) with ESMTP id k0S98Wvh054993 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 28 Jan 2006 04:08:38 -0500 (EST) (envelope-from mistry.7@osu.edu) From: Anish Mistry To: "Loren M. Lang" Date: Sat, 28 Jan 2006 04:03:34 -0500 User-Agent: KMail/1.9.1 References: <20060128071038.GA17471@alzatex.com> In-Reply-To: <20060128071038.GA17471@alzatex.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart4585574.rphgxNqlp5"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200601280403.43065.mistry.7@osu.edu> X-Spam-Status: No, score=-5.7 required=5.0 tests=ALL_TRUSTED,BAYES_40, MYFREEBSD3 autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on mail.united-ware.com X-Virus-Scanned: ClamAV 0.88/1254/Fri Jan 27 12:22:39 2006 on mail.united-ware.com X-Virus-Status: Clean Cc: freebsd-hackers@freebsd.org Subject: Re: FreeBSD Real Mode interface X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jan 2006 09:00:51 -0000 --nextPart4585574.rphgxNqlp5 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Saturday 28 January 2006 02:10, Loren M. Lang wrote: > Is there any equivalent to the Linux Real Mode interface in > FreeBSD? I would like to port a program called atitvout to > FreeBSD, but it uses calls to the vesa bios in real mode on the x86 > arch. I can't seem to find out how to do this in FreeBSD. If you're trying to do tvout with your mach64 chipset, the Xorg config=20 file options work. =2D-=20 Anish Mistry --nextPart4585574.rphgxNqlp5 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQBD2zNvxqA5ziudZT0RAqh9AKDOTLxVwdYmPjYCewuEzAu/1QLX7QCeLJWi ufzD5pdNQq+U5by5eh9x6wQ= =zc3z -----END PGP SIGNATURE----- --nextPart4585574.rphgxNqlp5-- From owner-freebsd-hackers@FreeBSD.ORG Sat Jan 28 10:16:04 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3B6BD16A420 for ; Sat, 28 Jan 2006 10:16:04 +0000 (GMT) (envelope-from lorenl@alzatex.com) Received: from hosea.tallye.com (joel.tallye.com [216.99.199.78]) by mx1.FreeBSD.org (Postfix) with ESMTP id BF4E743D45 for ; Sat, 28 Jan 2006 10:16:03 +0000 (GMT) (envelope-from lorenl@alzatex.com) Received: from hosea.tallye.com (localhost.localdomain [127.0.0.1]) by hosea.tallye.com (8.12.8/8.12.10) with ESMTP id k0SAFxBd020069 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 28 Jan 2006 02:15:59 -0800 Received: (from sttng359@localhost) by hosea.tallye.com (8.12.8/8.12.8/Submit) id k0SAFvNM020067; Sat, 28 Jan 2006 02:15:57 -0800 Date: Sat, 28 Jan 2006 02:15:57 -0800 From: "Loren M. Lang" To: Anish Mistry Message-ID: <20060128101557.GB19978@alzatex.com> References: <20060128071038.GA17471@alzatex.com> <200601280403.43065.mistry.7@osu.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GRPZ8SYKNexpdSJ7" Content-Disposition: inline In-Reply-To: <200601280403.43065.mistry.7@osu.edu> User-Agent: Mutt/1.4.1i X-GPG-Key: ftp://ftp.tallye.com/pub/lorenl_pubkey.asc X-GPG-Fingerprint: B3B9 D669 69C9 09EC 1BCD 835A FAF3 7A46 E4A3 280C X-Virus-Scanned: ClamAV version 0.87, clamav-milter version 0.87 on hosea.tallye.com X-Virus-Status: Clean Cc: freebsd-hackers@freebsd.org, "Loren M. Lang" Subject: Re: FreeBSD Real Mode interface X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jan 2006 10:16:04 -0000 --GRPZ8SYKNexpdSJ7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jan 28, 2006 at 04:03:34AM -0500, Anish Mistry wrote: > On Saturday 28 January 2006 02:10, Loren M. Lang wrote: > > Is there any equivalent to the Linux Real Mode interface in > > FreeBSD? I would like to port a program called atitvout to > > FreeBSD, but it uses calls to the vesa bios in real mode on the x86 > > arch. I can't seem to find out how to do this in FreeBSD. > If you're trying to do tvout with your mach64 chipset, the Xorg config=20 > file options work. First of all, this is not confurable after Xorg has started, AFAIK. Secondly, when Xorg does autodetect the S-Video connection, it loads the screen on both the LCD and S-Video interface which my video card does not like very well. Linux has the exact same issue, the only solution was to make sure the s-video connection was unplugged during Xorg startup and plug it in afterwards. Then use atitvout to switch over to the s-video and shut the lcd signal off. If Xorg can do this after it's started then I might try that. >=20 > --=20 > Anish Mistry --=20 Loren M. Lang lorenl@north-winds.org http://www.north-winds.org/ Public Key: ftp://ftp.north-winds.org/pub/lorenl_pubkey.asc Fingerprint: CEE1 AAE2 F66C 59B5 34CA C415 6D35 E847 0118 A3D2 =20 --GRPZ8SYKNexpdSJ7 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFD20RdbTXoRwEYo9IRAjjeAJoDH5+wQsfpRGNa5fRTh8iWBMC9zQCfUMUa X96Hssb+nf0yu6EXKmKqobY= =GAuA -----END PGP SIGNATURE----- --GRPZ8SYKNexpdSJ7-- From owner-freebsd-hackers@FreeBSD.ORG Sat Jan 28 17:49:50 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DB6ED16A420 for ; Sat, 28 Jan 2006 17:49:50 +0000 (GMT) (envelope-from mistry.7@osu.edu) Received: from mail.united-ware.com (am-productions.biz [69.61.164.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id CD61943D4C for ; Sat, 28 Jan 2006 17:49:49 +0000 (GMT) (envelope-from mistry.7@osu.edu) Received: from [192.168.1.100] (am-productions.biz [69.61.164.22]) (authenticated bits=0) by mail.united-ware.com (8.13.4/8.13.4) with ESMTP id k0SHvZBC064984 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 28 Jan 2006 12:57:41 -0500 (EST) (envelope-from mistry.7@osu.edu) From: Anish Mistry To: "Loren M. Lang" Date: Sat, 28 Jan 2006 12:52:36 -0500 User-Agent: KMail/1.9.1 References: <20060128071038.GA17471@alzatex.com> <200601280403.43065.mistry.7@osu.edu> <20060128101557.GB19978@alzatex.com> In-Reply-To: <20060128101557.GB19978@alzatex.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2761612.VKUTJ4uih6"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200601281252.44231.mistry.7@osu.edu> X-Spam-Status: No, score=-6.2 required=5.0 tests=ALL_TRUSTED,BAYES_20, MYFREEBSD3 autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on mail.united-ware.com X-Virus-Scanned: ClamAV 0.88/1254/Fri Jan 27 12:22:39 2006 on mail.united-ware.com X-Virus-Status: Clean Cc: freebsd-hackers@freebsd.org Subject: Re: FreeBSD Real Mode interface X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jan 2006 17:49:51 -0000 --nextPart2761612.VKUTJ4uih6 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Saturday 28 January 2006 05:15, you wrote: > On Sat, Jan 28, 2006 at 04:03:34AM -0500, Anish Mistry wrote: > > On Saturday 28 January 2006 02:10, Loren M. Lang wrote: > > > Is there any equivalent to the Linux Real Mode interface in > > > FreeBSD? I would like to port a program called atitvout to > > > FreeBSD, but it uses calls to the vesa bios in real mode on the > > > x86 arch. I can't seem to find out how to do this in FreeBSD. > > > > If you're trying to do tvout with your mach64 chipset, the Xorg > > config file options work. > > First of all, this is not confurable after Xorg has started, AFAIK. Right. > Secondly, when Xorg does autodetect the S-Video connection, it > loads the screen on both the LCD and S-Video interface which my > video card does not like very well. Hmmm...my card doesn't. What I do is have a separate ServerLayou=20 section for the SVIDEO out. I think use a script that I run when I=20 want to run the SVIDEO out. It can be run while X is running on the=20 LCD panel. It will start a new display and session on the TV. http://am-productions.biz/docs/xorg.conf http://am-productions.biz/docs/tvout > Linux has the exact same=20 > issue, the only solution was to make sure the s-video connection > was unplugged during Xorg startup and plug it in afterwards. Then > use atitvout to switch over to the s-video and shut the lcd signal > off. If Xorg can do this after it's started then I might try that. > > > -- > > Anish Mistry =2D-=20 Anish Mistry --nextPart2761612.VKUTJ4uih6 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQBD269sxqA5ziudZT0RAqspAKCtu9OUyVALya6yZ/mCiL6yoNEGmQCfXVC0 URBlfgc4RuwhdKWuS65wn2A= =HGLx -----END PGP SIGNATURE----- --nextPart2761612.VKUTJ4uih6-- From owner-freebsd-hackers@FreeBSD.ORG Sat Jan 28 18:47:04 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 659FA16A420 for ; Sat, 28 Jan 2006 18:47:04 +0000 (GMT) (envelope-from greeen.anton@gmail.com) Received: from uproxy.gmail.com (uproxy.gmail.com [66.249.92.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id 34DA543D46 for ; Sat, 28 Jan 2006 18:47:02 +0000 (GMT) (envelope-from greeen.anton@gmail.com) Received: by uproxy.gmail.com with SMTP id m2so293505uge for ; Sat, 28 Jan 2006 10:47:02 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:subject:message-id:x-mailer:mime-version:content-type:content-transfer-encoding; b=MEMBBAZ3o+AtWLqvuaeDk+Nau4AemZeTV+01/9fM8P5QKv7PUCR4MFVxXm3wpHpGWLANtgqP2NOqKakYDA85QhR2xzz8y+zWqHoiIkAT7uIDeS8clYSaE+fLLmLRgSlba8iJiBUmuagwokbcoIPzTun/ZOZQr94ZSBPt19F6O0A= Received: by 10.49.17.5 with SMTP id u5mr519334nfi; Sat, 28 Jan 2006 01:24:53 -0800 (PST) Received: from localhost ( [83.149.32.48]) by mx.gmail.com with ESMTP id a24sm149807nfc.2006.01.28.01.24.49; Sat, 28 Jan 2006 01:24:52 -0800 (PST) Date: Sat, 28 Jan 2006 14:23:23 +0500 From: Anton Barsukov To: freebsd-hackers@freebsd.org Message-Id: <20060128142323.046e186c.greeen.anton@gmail.com> X-Mailer: Sylpheed version 2.0.0 (GTK+ 2.6.9; i386-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: kernel panic with pmap_qremove() X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jan 2006 18:47:04 -0000 Hi everybody I install ports/benchmarks/forkbomb, when i run '%forkbomb -f', kernel panic. instruction pointer = pmap_qremove(sva=4290785280, count=0) at /usr/src/sys/i386/i386/pmap.c:896 FreeBSD 6.0-RELEASE(GENERIC) i386 machine( MB -- P4P800SE, CPU -- P4 3GHz, RAM -- 2x512Mb )