From owner-freebsd-current@FreeBSD.ORG Sun Sep 2 01:06:35 2007 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2808516A418 for ; Sun, 2 Sep 2007 01:06:35 +0000 (UTC) (envelope-from hugo@barafranca.com) Received: from mail.barafranca.com (mail.barafranca.com [67.19.101.164]) by mx1.freebsd.org (Postfix) with ESMTP id E489713C459 for ; Sun, 2 Sep 2007 01:06:34 +0000 (UTC) (envelope-from hugo@barafranca.com) Received: from localhost (localhost [127.0.0.1]) by mail.barafranca.com (Postfix) with ESMTP id 52C4BC496D for ; Sun, 2 Sep 2007 01:49:22 +0000 (UTC) Received: from mail.barafranca.com ([67.19.101.164]) by localhost (mail.barafranca.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 47033-04 for ; Sun, 2 Sep 2007 01:48:41 +0000 (UTC) Received: from nexus.bsdlan.org (64.b6.1343.static.theplanet.com [67.19.182.100]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.barafranca.com (Postfix) with ESMTP id 6E7B3C481D for ; Sun, 2 Sep 2007 01:48:41 +0000 (UTC) Message-ID: <46DA0C5E.1050506@barafranca.com> Date: Sun, 02 Sep 2007 02:05:34 +0100 From: Hugo User-Agent: Thunderbird 2.0.0.6 (X11/20070816) MIME-Version: 1.0 To: freebsd-current@FreeBSD.ORG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at barafranca.com X-Spam-Status: No, score=0 tagged_above=-1 required=4 tests=[none] X-Spam-Score: 0 X-Spam-Level: Cc: Subject: rtfree: 0xc3e377f8 has 1 refs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Sep 2007 01:06:35 -0000 Hi list, While experimenting with IPv6 on a spare server, I noticed the following in the logs: Sep 2 00:24:33 deserteagle kernel: rtfree: 0xc3e377f8 has 1 refs Sep 2 00:25:01 deserteagle last message repeated 139 times Sep 2 00:25:01 deserteagle kernel: rtfree: 0xc3e377f8 has 1 refs Sep 2 00:25:17 deserteagle last message repeated 401 times Sep 2 00:27:38 deserteagle last message repeated 1204 times Sep 2 00:35:32 deserteagle last message repeated 1032 times Sep 2 00:47:03 deserteagle last message repeated 164 times Connectivity is fine, but these messages are filling up the logs. The only traffic that particular server gets right now is ssh (over ipv6, altough by looking at the logs the messages show up even before I login) uname: 7.0-CURRENT FreeBSD 7.0-CURRENT #2: Sat Sep 1 23:07:18 UTC 2007 klr@deserteagle.barafranca.com:/usr/obj/usr/src/sys/DESERTEAGLE i386 netstat -rn: Internet6: Destination Gateway Flags Netif Expire ::/96 ::1 UGRS lo0 => default 2002:c058:6301:: UGS stf0 ::1 ::1 UHL lo0 ::ffff:0.0.0.0/96 ::1 UGRS lo0 2002::/24 ::1 UGRS lo0 => 2002::/16 2002:4655:c4f2::1 U stf0 2002:4655:c4f2::/48 link#1 UC em0 2002:4655:c4f2::1 link#4 UHL lo0 2002:4655:c4f2::ac1d:242 00:0c:f1:bf:2a:54 UHL lo0 2002:4655:c4f2::ac1d:243 00:0c:f1:bf:2a:54 UHL lo0 2002:7f00::/24 ::1 UGRS lo0 2002:e000::/20 ::1 UGRS lo0 2002:ff00::/24 ::1 UGRS lo0 fe80::/10 ::1 UGRS lo0 fe80::%em0/64 link#1 UC em0 fe80::20c:f1ff:febf:2a54%em0 00:0c:f1:bf:2a:54 UHL lo0 fe80::%lo0/64 fe80::1%lo0 U lo0 fe80::1%lo0 link#3 UHL lo0 ff01:1::/32 link#1 UC em0 ff01:3::/32 ::1 UC lo0 ff02::/16 ::1 UGRS lo0 ff02::%em0/32 link#1 UC em0 ff02::%lo0/32 ::1 UC lo0 I have never seen this error before. On a 6.2-RELEASE-p1 box at home (which also got ipv6 connectivity) I do not see these errors. Ideas? Best regards, Hugo From owner-freebsd-current@FreeBSD.ORG Sun Sep 2 01:16:16 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6EED916A418 for ; Sun, 2 Sep 2007 01:16:16 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.188]) by mx1.freebsd.org (Postfix) with ESMTP id F228B13C45A for ; Sun, 2 Sep 2007 01:16:15 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by nf-out-0910.google.com with SMTP id k4so920527nfd for ; Sat, 01 Sep 2007 18:16:05 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=MgBlWsUUTW5BphYnz1tKjfT78w11dLFgtmYK17VVVHSVF/Iy+l8CJVYWqJabOFd1ARxcZ0/b4V/mVmzDQa75hAX19Qfdb+Box9g46oK6IHFPdHODMuzDW70UGIDGC9zKSZjetm3JrnVd0Dd2lVMzbRNRjyA+LXqwMeixAopnwZI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=W8yo0r5D88jE8VjyQpCwIihL7rL6UUMYQFcIH1ddxi1kznzldCyRYHE2u196h7wXNuhTdrt8M3ffJsa9GJ7P+/UMD0JYHpBuOq5cNaLtFZSNljsx0ifvxgDaMrVS2VwGWeky+SGtkrP26XcQJK/zl9VPZsbQ3KgREe4Y8Xmowic= Received: by 10.78.172.20 with SMTP id u20mr2422419hue.1188695764794; Sat, 01 Sep 2007 18:16:04 -0700 (PDT) Received: by 10.78.97.18 with HTTP; Sat, 1 Sep 2007 18:16:04 -0700 (PDT) Message-ID: <3bbf2fe10709011816tf793fa0o8b276498efb62e80@mail.gmail.com> Date: Sun, 2 Sep 2007 03:16:04 +0200 From: "Attilio Rao" Sender: asmrookie@gmail.com To: Hugo In-Reply-To: <46DA0C5E.1050506@barafranca.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <46DA0C5E.1050506@barafranca.com> X-Google-Sender-Auth: 891852429c93264d Cc: freebsd-current@freebsd.org, csjp@freebsd.org Subject: Re: rtfree: 0xc3e377f8 has 1 refs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Sep 2007 01:16:16 -0000 2007/9/2, Hugo : > Hi list, > > While experimenting with IPv6 on a spare server, I noticed the following > in the logs: > > Sep 2 00:24:33 deserteagle kernel: rtfree: 0xc3e377f8 has 1 refs > Sep 2 00:25:01 deserteagle last message repeated 139 times > Sep 2 00:25:01 deserteagle kernel: rtfree: 0xc3e377f8 has 1 refs > Sep 2 00:25:17 deserteagle last message repeated 401 times > Sep 2 00:27:38 deserteagle last message repeated 1204 times > Sep 2 00:35:32 deserteagle last message repeated 1032 times > Sep 2 00:47:03 deserteagle last message repeated 164 times csjp@ (attached) should have a patch for it (and he can comment on this for sure). Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Sun Sep 2 09:12:07 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 11B5416A417 for ; Sun, 2 Sep 2007 09:12:07 +0000 (UTC) (envelope-from thomas@FreeBSD.ORG) Received: from melamine.cuivre.fr.eu.org (melusine.cuivre.fr.eu.org [82.225.155.84]) by mx1.freebsd.org (Postfix) with ESMTP id BB3FB13C4B3 for ; Sun, 2 Sep 2007 09:12:06 +0000 (UTC) (envelope-from thomas@FreeBSD.ORG) Received: by melamine.cuivre.fr.eu.org (Postfix, from userid 1000) id BBF115C5E9; Sun, 2 Sep 2007 11:11:45 +0200 (CEST) Date: Sun, 2 Sep 2007 11:11:45 +0200 From: Thomas Quinot To: Patrick Hajek Message-ID: <20070902091145.GB71871@melamine.cuivre.fr.eu.org> References: <20070829170749.GA20549@lbl.gov> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070829170749.GA20549@lbl.gov> X-message-flag: WARNING! Using Outlook can damage your computer. User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-current@freebsd.org Subject: Re: Recent changes in atapi-cam? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Sep 2007 09:12:07 -0000 * Patrick Hajek, 2007-08-29 : > >> The upgrade was successful with one exception: > >> ad0: 95205MB at ata0-master UDMA100 > >> acd0: DVDR at ata1-master UDMA33 > >> acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 > >> acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 > >> acd0: FAILURE - READ_TOC ILLEGAL REQUEST asc=0x24 ascq=0x00 > >> acd0: FAILURE - READ_TOC ILLEGAL REQUEST asc=0x24 ascq=0x00 > > >atapicam is disabled in your kernel configuration, so I assume you are > >loading it as a module. Do you still get the errors above (on acd0) if > >you do *not* load the atapi-cam module? > > >Thomas. > > Correct. When I first encountered the error, the vaious components were > compiled into the kernel. Taking a wild stab, I decided to see if > loading it as a module would result the the same issue and yes, it did. so can you confirm whether you still get the acd0 errors when you do NOT load atapi-cam at all (nor have it precompiled in the kernel)? Thomas. From owner-freebsd-current@FreeBSD.ORG Sun Sep 2 09:54:34 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6252816A418 for ; Sun, 2 Sep 2007 09:54:34 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (c220-239-20-82.belrs4.nsw.optusnet.com.au [220.239.20.82]) by mx1.freebsd.org (Postfix) with ESMTP id DBCEE13C483 for ; Sun, 2 Sep 2007 09:54:33 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by turion.vk2pj.dyndns.org (8.14.1/8.14.1) with ESMTP id l829sHLd023865; Sun, 2 Sep 2007 19:54:17 +1000 (EST) (envelope-from peter@turion.vk2pj.dyndns.org) Received: (from peter@localhost) by turion.vk2pj.dyndns.org (8.14.1/8.14.1/Submit) id l829sHVZ023864; Sun, 2 Sep 2007 19:54:17 +1000 (EST) (envelope-from peter) Date: Sun, 2 Sep 2007 19:54:17 +1000 From: Peter Jeremy To: Bruce Cran Message-ID: <20070902095417.GN1181@turion.vk2pj.dyndns.org> References: <46D83351.9000407@cran.org.uk> <46D8719A.1070109@cran.org.uk> <20070901204947.GY1181@turion.vk2pj.dyndns.org> <46D9EE1E.9030009@cran.org.uk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OROCMA9jn6tkzFBc" Content-Disposition: inline In-Reply-To: <46D9EE1E.9030009@cran.org.uk> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.16 (2007-06-09) Cc: current@freebsd.org Subject: Re: High interrupt load on VIA C3 machine X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Sep 2007 09:54:34 -0000 --OROCMA9jn6tkzFBc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2007-Sep-01 23:56:30 +0100, Bruce Cran wrote: >The VIA C3 supports 2 frequencies - 531 and 265 MHz. The high interrupt= =20 >load only occurs when I set dev.cpu.0.freq to 265, which makes sense. Half the clock rate implies twice the interrupt load - it it should be about 3.5% at 531MHz if its 7% at 265MHz. If you're seeing something significantly different then there is some other factor at work. --=20 Peter Jeremy --OROCMA9jn6tkzFBc Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFG2ohJ/opHv/APuIcRAvEKAJ9BDnGc/VEfjbOUr6YHji0qvhFb3gCeLvw5 TuMpkbC1FpwcKuRfqoiebpw= =P33y -----END PGP SIGNATURE----- --OROCMA9jn6tkzFBc-- From owner-freebsd-current@FreeBSD.ORG Sun Sep 2 10:58:12 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F1CA116A419 for ; Sun, 2 Sep 2007 10:58:12 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.bluestop.org (muon.bluestop.org [80.68.94.188]) by mx1.freebsd.org (Postfix) with ESMTP id B5AC513C461 for ; Sun, 2 Sep 2007 10:58:12 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.draftnet (dyn-62-56-105-44.dslaccess.co.uk [62.56.105.44]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by muon.bluestop.org (Postfix) with ESMTP id 146AD3000D; Sun, 2 Sep 2007 11:53:48 +0100 (BST) Message-ID: <46DA96DB.2090700@cran.org.uk> Date: Sun, 02 Sep 2007 11:56:27 +0100 From: Bruce Cran User-Agent: Thunderbird 2.0.0.6 (X11/20070809) MIME-Version: 1.0 To: Peter Jeremy References: <46D83351.9000407@cran.org.uk> <46D8719A.1070109@cran.org.uk> <20070901204947.GY1181@turion.vk2pj.dyndns.org> <46D9EE1E.9030009@cran.org.uk> <20070902095417.GN1181@turion.vk2pj.dyndns.org> In-Reply-To: <20070902095417.GN1181@turion.vk2pj.dyndns.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: High interrupt load on VIA C3 machine X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Sep 2007 10:58:13 -0000 Peter Jeremy wrote: > On 2007-Sep-01 23:56:30 +0100, Bruce Cran wrote: > >> The VIA C3 supports 2 frequencies - 531 and 265 MHz. The high interrupt >> load only occurs when I set dev.cpu.0.freq to 265, which makes sense. >> > > Half the clock rate implies twice the interrupt load - it it should be > about 3.5% at 531MHz if its 7% at 265MHz. If you're seeing something > significantly different then there is some other factor at work. > > It seems there is something different happening, but I don't know if it's to do with FreeBSD or just the way the CPU works. At 531MHz the "swi4: clock sio" task uses 0.2% CPU and the "interrupt" line in top goes up to about 1.6%. At 265MHz the "swi4: clock sio" task uses about 10% CPU and the "interrupt" line varies between 14 and 20%. -- Bruce Cran From owner-freebsd-current@FreeBSD.ORG Sun Sep 2 13:56:58 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E5BF916A420; Sun, 2 Sep 2007 13:56:58 +0000 (UTC) (envelope-from h.schmalzbauer@omnisec.de) Received: from host.omnisec.de (host.omnisec.de [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id 7246513C442; Sun, 2 Sep 2007 13:56:58 +0000 (UTC) (envelope-from h.schmalzbauer@omnisec.de) Received: from tek.flintsbach.schmalzbauer.de (tek.flintsbach.schmalzbauer.de [172.21.2.3]) by host.omnisec.de (8.13.8/8.13.8) with ESMTP id l82DuN3B010188 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 2 Sep 2007 15:56:28 +0200 (CEST) (envelope-from h.schmalzbauer@omnisec.de) Received: from titan.flintsbach.schmalzbauer.de (titan.flintsbach.schmalzbauer.de [IPv6:fec0::1:0:0:1:1]) by tek.flintsbach.schmalzbauer.de (8.13.8/8.13.8) with ESMTP id l82DuNab003355; Sun, 2 Sep 2007 15:56:23 +0200 (CEST) (envelope-from h.schmalzbauer@omnisec.de) Received: by titan.flintsbach.schmalzbauer.de (8.14.1/8.14.1/Submit) id l82DvMim061236; Sun, 2 Sep 2007 15:57:22 +0200 (CEST) (envelope-from h.schmalzbauer@omnisec.de) X-Authentication-Warning: titan.flintsbach.schmalzbauer.de: harry set sender to h.schmalzbauer@omnisec.de using -f From: Harald Schmalzbauer Organization: OmniSEC To: freebsd-current@freebsd.org Date: Sun, 2 Sep 2007 15:57:21 +0200 User-Agent: KMail/1.9.7 References: <200708210339.l7L3dUX0038042@repoman.freebsd.org> <46CB50FE.7000306@FreeBSD.org> In-Reply-To: <46CB50FE.7000306@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200709021557.22191.h.schmalzbauer@omnisec.de> Cc: "Constantine A. Murenin" Subject: Re: GSoC2007: cnst-sensors.2007-08-20.patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Sep 2007 13:56:59 -0000 Am Dienstag, 21. August 2007 22:54:22 schrieb Constantine A. Murenin: > Dear freebsd-current@, > > It is my pleasure to present a Technology Preview patch that ports most > of the base components of OpenBSD's hardware sensors framework to FreeBSD. [*SNIP*] > Apply to FreeBSD 7.0-CURRENT as of 2007-08-20 by doing: > > cd /usr/src > fetch > http://p4web.freebsd.org/depot/projects/soc2007/cnst-sensors/cnst-sensors.2 >007-08-20.patch mkdir sys/dev/lm sys/modules/lm usr.sbin/sensorsd > patch < cnst-sensors.2007-08-20.patch For your convenience I wrote a little shell script which dosn't only do all the neccessary steps to apply the patch (including download) but also removes it (for example if one wants to recsup the tree). Otherwise you would end up breaking build if not cleanly removed before applied again. It also uses the latest version of coretemp.c which isn't included in the original patch. Please find it at http://www.schmalzbauer.de/downloads/sensors_patch.sh Best regards, -Harry From owner-freebsd-current@FreeBSD.ORG Sun Sep 2 15:37:56 2007 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4DDCE16A417; Sun, 2 Sep 2007 15:37:56 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) by mx1.freebsd.org (Postfix) with ESMTP id E095213C4A8; Sun, 2 Sep 2007 15:37:55 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.1/8.14.1) with ESMTP id l82FbX01097834; Sun, 2 Sep 2007 19:37:33 +0400 (MSD) (envelope-from marck@rinet.ru) Date: Sun, 2 Sep 2007 19:37:33 +0400 (MSD) From: Dmitry Morozovsky To: Pawel Jakub Dawidek Message-ID: <20070902193609.O95913@woozle.rinet.ru> X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (woozle.rinet.ru [0.0.0.0]); Sun, 02 Sep 2007 19:37:33 +0400 (MSD) Cc: current@FreeBSD.org Subject: quotas on gjournal X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Sep 2007 15:37:56 -0000 Dear Pawel, it seems gjournal is not fully compatible with quotas now: root@n5600:/# /usr/obj/usr/src/sbin/quotacheck/quotacheck -v -a /dev/mirror/m0d (/usr): EXITED WITH SIGNAL 11 /dev/mirror/m0e.journal (/var): EXITED WITH SIGNAL 11 /dev/mirror/m0f.journal (/lh): EXITED WITH SIGNAL 11 /dev/mirror/m0g.journal (/st): EXITED WITH SIGNAL 11 THE FOLLOWING FILE SYSTEMS HAD AN UNEXPECTED INCONSISTENCY: /dev/mirror/m0d (/usr), /dev/mirror/m0e.journal (/var), /dev/mirror/m0f.journal (/lh), /dev/mirror/m0g.journal (/st) root@n5600:/# !gdb gdb /usr/obj/usr/src/sbin/quotacheck/quotacheck quotacheck.core GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Core was generated by `quotacheck'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/libc.so.7...done. Loaded symbols for /lib/libc.so.7 Reading symbols from /libexec/ld-elf.so.1...done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x0000000000402bc2 in chkquota (fsname=0x800932140 "/dev/mirror/m0g.journal", mntpt=0x8009200d8 "/st", qnp=0x936000) at /usr/src/sbin/quotacheck/quotacheck.c:287 287 if (qnp->flags & HASUSR) (gdb) bt #0 0x0000000000402bc2 in chkquota (fsname=0x800932140 "/dev/mirror/m0g.journal", mntpt=0x8009200d8 "/st", qnp=0x936000) at /usr/src/sbin/quotacheck/quotacheck.c:287 #1 0x0000000000403291 in startdisk (dk=0x800932060, checkit=0x4028b0 ) at /usr/src/sbin/quotacheck/preen.c:278 #2 0x0000000000403776 in checkfstab (preen=1, maxrun=1, docheck=0x402170 , chkit=0x4028b0 ) at /usr/src/sbin/quotacheck/preen.c:164 #3 0x0000000000403101 in main (argc=0, argv=0x7fffffffebb8) at /usr/src/sbin/quotacheck/quotacheck.c:205 Any hints? Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Sun Sep 2 17:12:54 2007 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AF4F516A417 for ; Sun, 2 Sep 2007 17:12:54 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id A853613C442 for ; Sun, 2 Sep 2007 17:12:54 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id C6A7D470E0 for ; Sun, 2 Sep 2007 13:12:46 -0400 (EDT) Date: Sun, 2 Sep 2007 18:12:46 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: current@FreeBSD.org Message-ID: <20070902181119.E21906@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Subject: more(1) has gotten more demanding? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Sep 2007 17:12:54 -0000 I recently saw this on the serial console for a box: cyrus# ps ax | more WARNING: terminal is not fully functional - (press RETURN) more(1) now seems to want me to acknowledge the inadequacy of my serial console every time I view any file. I'm sure it didn't always do this, and to be honest, I would rather it continued to not do this very time I view a file or man page. Or for every patch applied by mergemaster. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Sun Sep 2 17:19:39 2007 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C70AF16A418; Sun, 2 Sep 2007 17:19:39 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [210.51.165.229]) by mx1.freebsd.org (Postfix) with ESMTP id 9A64813C457; Sun, 2 Sep 2007 17:19:39 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from localhost (tarsier.geekcn.org [210.51.165.229]) by tarsier.geekcn.org (Postfix) with ESMTP id DD1A6EB3E52; Mon, 3 Sep 2007 01:19:22 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([210.51.165.229]) by localhost (mail.geekcn.org [210.51.165.229]) (amavisd-new, port 10024) with ESMTP id pShcveAGFbid; Mon, 3 Sep 2007 01:19:14 +0800 (CST) Received: from charlie.delphij.net (unknown [221.216.128.158]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id A38D8EB3CC3; Mon, 3 Sep 2007 01:19:14 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type; b=IEmPkDfKYYBHYFjmCgFlXIlv1ItxUpmTgeXzENje298dgYEq2KwfjC9pm9xWnhaVt 353XzLGw2d5GEPiBcuEYA== Message-ID: <46DAF092.1030708@delphij.net> Date: Mon, 03 Sep 2007 01:19:14 +0800 From: Xin LI User-Agent: Thunderbird 2.0.0.6 (X11/20070803) MIME-Version: 1.0 To: Robert Watson References: <20070902181119.E21906@fledge.watson.org> In-Reply-To: <20070902181119.E21906@fledge.watson.org> Content-Type: multipart/mixed; boundary="------------070201070505040501050201" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: current@FreeBSD.org Subject: Re: more(1) has gotten more demanding? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Sep 2007 17:19:39 -0000 This is a multi-part message in MIME format. --------------070201070505040501050201 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Robert Watson wrote: > > I recently saw this on the serial console for a box: > > cyrus# ps ax | more > WARNING: terminal is not fully functional > - (press RETURN) > > more(1) now seems to want me to acknowledge the inadequacy of my serial > console every time I view any file. I'm sure it didn't always do this, > and to be honest, I would rather it continued to not do this very time I > view a file or man page. Or for every patch applied by mergemaster. Will the attached patch help? Cheers, --------------070201070505040501050201-- From owner-freebsd-current@FreeBSD.ORG Sun Sep 2 18:33:31 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 89DC816A473 for ; Sun, 2 Sep 2007 18:33:31 +0000 (UTC) (envelope-from dougk@dougk-ff7.net) Received: from mail.dougk-ff7.net (shen.liquidneon.com [216.87.78.181]) by mx1.freebsd.org (Postfix) with ESMTP id 7D9E813C46E for ; Sun, 2 Sep 2007 18:33:31 +0000 (UTC) (envelope-from dougk@dougk-ff7.net) Received: from localhost (localhost.liquidneon.com [127.0.0.1]) by mail.dougk-ff7.net (Postfix) with ESMTP id A28A295868 for ; Sun, 2 Sep 2007 12:11:23 -0600 (MDT) X-Virus-Scanned: by amavisd-new at dougk-ff7.net Received: from mail.dougk-ff7.net ([127.0.0.1]) by localhost (shen.liquidneon.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wmFg3WQKTsKQ for ; Sun, 2 Sep 2007 12:11:21 -0600 (MDT) Received: from [192.168.10.249] (CPE-24-163-209-195.kc.res.rr.com [24.163.209.195]) by mail.dougk-ff7.net (Postfix) with ESMTP id 82C4E95866 for ; Sun, 2 Sep 2007 12:11:21 -0600 (MDT) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <67ACF758-1A7A-4696-9A16-71D31D13327B@dougk-ff7.net> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: freebsd-current@freebsd.org From: Doug Kelly Date: Sun, 2 Sep 2007 13:07:31 -0500 X-Mailer: Apple Mail (2.752.3) Subject: kldload fails (missing symbols?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Sep 2007 18:33:31 -0000 On a updated build of -CURRENT (as of when I ran cvsup on September 1st), I have a strange issue running kldload. Some modules will throw an error, claiming they're missing symbols (but they don't say what symbol). Here's an example of such output: machine# kldload zlib link_elf: symbol undefined kldload: can't load zlib: No such file or directory machine# kldload xfs link_elf: symbol undefined kldload: can't load xfs: No such file or directory machine# kldload lpt machine# As you may notice, the actual symbol which is undefined isn't named-- according to the error. dmesg only contains the exact same output. Oddly enough, not all modules are impacted, either--lpt loaded fine, as do a few other modules. I did go back to an April snapshot of -CURRENT, and this problem did not exist (zlib loaded fine), so presumably, something has changed in the five months since then. Also, this is a SPARC64 build of FreeBSD. If my question would be better directed to that list, please let me know. Thanks in advance, Doug Kelly From owner-freebsd-current@FreeBSD.ORG Sun Sep 2 18:48:24 2007 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1EE3516A419 for ; Sun, 2 Sep 2007 18:48:24 +0000 (UTC) (envelope-from erikt@midgard.homeip.net) Received: from ch-smtp02.sth.basefarm.net (ch-smtp02.sth.basefarm.net [80.76.149.213]) by mx1.freebsd.org (Postfix) with ESMTP id EA43C13C469 for ; Sun, 2 Sep 2007 18:48:23 +0000 (UTC) (envelope-from erikt@midgard.homeip.net) Received: from c83-253-31-60.bredband.comhem.se ([83.253.31.60]:61236 helo=falcon.midgard.homeip.net) by ch-smtp02.sth.basefarm.net with esmtp (Exim 4.66) (envelope-from ) id 1IRuG2-0005SA-6V for current@FreeBSD.org; Sun, 02 Sep 2007 20:33:14 +0200 Received: (qmail 22419 invoked from network); 2 Sep 2007 20:33:07 +0200 Received: from owl.midgard.homeip.net (10.1.5.7) by falcon.midgard.homeip.net with ESMTP; 2 Sep 2007 20:33:07 +0200 Received: (qmail 19935 invoked by uid 1001); 2 Sep 2007 20:33:07 +0200 Date: Sun, 2 Sep 2007 20:33:07 +0200 From: Erik Trulsson To: Robert Watson Message-ID: <20070902183307.GA19800@owl.midgard.homeip.net> Mail-Followup-To: Robert Watson , current@FreeBSD.org References: <20070902181119.E21906@fledge.watson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070902181119.E21906@fledge.watson.org> User-Agent: Mutt/1.5.16 (2007-06-09) X-Originating-IP: 83.253.31.60 X-Scan-Result: No virus found in message 1IRuG2-0005SA-6V. X-Scan-Signature: ch-smtp02.sth.basefarm.net 1IRuG2-0005SA-6V f0ebf998da3c492c9640010894077225 Cc: current@FreeBSD.org Subject: Re: more(1) has gotten more demanding? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Sep 2007 18:48:24 -0000 On Sun, Sep 02, 2007 at 06:12:46PM +0100, Robert Watson wrote: > > I recently saw this on the serial console for a box: > > cyrus# ps ax | more > WARNING: terminal is not fully functional > - (press RETURN) > > more(1) now seems to want me to acknowledge the inadequacy of my serial > console every time I view any file. I'm sure it didn't always do this, and > to be honest, I would rather it continued to not do this very time I view a > file or man page. Or for every patch applied by mergemaster. As a workaround you should be able to use the '-d' option to less(1) to suppress that message. If you do not wish to add that to the commandline you can put the options into the LESS environment variable. -- Erik Trulsson ertr1013@student.uu.se From owner-freebsd-current@FreeBSD.ORG Mon Sep 3 00:39:50 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B084F16A41A for ; Mon, 3 Sep 2007 00:39:50 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.181]) by mx1.freebsd.org (Postfix) with ESMTP id 7138813C480 for ; Mon, 3 Sep 2007 00:39:50 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by wa-out-1112.google.com with SMTP id k17so1781205waf for ; Sun, 02 Sep 2007 17:39:33 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:received:received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=OcZZcUMk3bvpe0p5GGwM7ZuSSFy5TAaP+kcvpjloWz0Kz85YiHjuHJAcJZqvxiyQDzmK5t+TbYmKBuzZktPbjUYYo+Gan068EQbxT8ulEgGGzgJLvaPog3F8z7R+ypGJMVjDATJD9Z7aAMruQSdpMQQwj3h9K3MtIFuFnHEYipQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=uGBCcvUJSk+O2GbGK9ZZzv4+VHLs1e+Lugc9CzVH4S6g5Aj+pSEvvoO1US2xcbioFkbitVdE5Lw0ULfNBv04GoTa3q8CqO5v6FNPQ2C9lLz6ZLj9MpdYwgxaGz1snj+TGdG6/pZplynqb58kbLw1RA3cAcLNUGK2M5nZE6o0efU= Received: by 10.114.109.1 with SMTP id h1mr2669401wac.1188779973383; Sun, 02 Sep 2007 17:39:33 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTPS id m40sm3406736wag.2007.09.02.17.39.29 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 02 Sep 2007 17:39:31 -0700 (PDT) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id l830dPWV008382 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Sep 2007 09:39:25 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id l830dPOh008381; Mon, 3 Sep 2007 09:39:25 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Mon, 3 Sep 2007 09:39:25 +0900 From: Pyun YongHyeon To: Mario Ferreira Message-ID: <20070903003925.GA8166@cdnetworks.co.kr> References: <683701cf0708310509l40c14a78te54e6608c2f7d9ed@mail.gmail.com> <683701cf0708311058l5e80198fr432abb06d8128924@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <683701cf0708311058l5e80198fr432abb06d8128924@mail.gmail.com> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@freebsd.org Subject: Re: nfe(4) not working on asus m2n32sli-deluxe X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2007 00:39:50 -0000 On Fri, Aug 31, 2007 at 02:58:54PM -0300, Mario Ferreira wrote: > Hi, > > I tried installing FreeBSD 7.0-Current 200708 i386 snapshot on a > asus m2n32sli-deluxe wifi edition but I had some issues: > > 1) on board wlan adapter RTL8187_Wireless not supported > 2) on board lan adapter NForce 590 SLI MCP does not work > > The lack of support for RTL8187_Wireless is not a problem for now. > However, the NForce 590 SLI MCP Gigabit adapter is an issue. > > The nfe(4) driver detects the network carrier but it never ever > detects the media settings. I tried hand setting media/mediaopt but it > did not help. > > media: Ethernet autoselect (none) > status: active > > Any suggestions? Let me know if there is anything I can do to help. > Your dmesg shows Marvell 88E8116 PHY. It's known to me the PHY driver , e1000phy(4), has unresolved issues. Some variants of the 88E8116 are well supported by the e1000phy(4) driver but other variants are not. ATM I have no idea what's the root cause of the issue due to lack of PHY documentation and hardware. Some time ago, I've sent several patches to a user who reported the issue to me but I've failed to make it work. The only clue I know is ukphy(4) works for auto-sensing media type(Manual media selection with ukphy(4) didn't work for 88E8116). I vaguely guess it's related with power down mode of the MAC/PHY but working without real hardware made it difficult for me to fix. See PR kern/114086 for possible workaround. > Regards, -- Regards, Pyun YongHyeon From owner-freebsd-current@FreeBSD.ORG Mon Sep 3 01:19:54 2007 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8C06116A417; Mon, 3 Sep 2007 01:19:54 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [210.51.165.229]) by mx1.freebsd.org (Postfix) with ESMTP id 2DCA013C459; Mon, 3 Sep 2007 01:19:54 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from localhost (tarsier.geekcn.org [210.51.165.229]) by tarsier.geekcn.org (Postfix) with ESMTP id 952CBEB8D81; Mon, 3 Sep 2007 09:11:01 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([210.51.165.229]) by localhost (mail.geekcn.org [210.51.165.229]) (amavisd-new, port 10024) with ESMTP id KFNk12kSythJ; Mon, 3 Sep 2007 09:10:53 +0800 (CST) Received: from charlie.delphij.net (unknown [221.216.128.158]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id 57B29EB3D82; Mon, 3 Sep 2007 09:10:53 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type; b=wC/Riw/sQ/ZTrE4kxiaxxMK5tpNlsdhCA1PKrHCNcGUXUZAszmtxmuq6ZPRMLTsxu MORae/mEEiz8wj8qLQ1pA== Message-ID: <46DB5F1C.4020807@delphij.net> Date: Mon, 03 Sep 2007 09:10:52 +0800 From: Xin LI User-Agent: Thunderbird 2.0.0.6 (X11/20070803) MIME-Version: 1.0 To: Robert Watson References: <20070902181119.E21906@fledge.watson.org> <46DAF092.1030708@delphij.net> In-Reply-To: <46DAF092.1030708@delphij.net> Content-Type: multipart/mixed; boundary="------------050008030207060206090903" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: current@FreeBSD.org Subject: Re: more(1) has gotten more demanding? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2007 01:19:54 -0000 This is a multi-part message in MIME format. --------------050008030207060206090903 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sorry, the patch. Cheers, --------------050008030207060206090903-- From owner-freebsd-current@FreeBSD.ORG Mon Sep 3 01:52:02 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F253D16A41A for ; Mon, 3 Sep 2007 01:52:02 +0000 (UTC) (envelope-from marinosi@diogenis.ceid.upatras.gr) Received: from poseidon.ceid.upatras.gr (poseidon.ceid.upatras.gr [150.140.141.169]) by mx1.freebsd.org (Postfix) with ESMTP id 8FF5513C442 for ; Mon, 3 Sep 2007 01:52:02 +0000 (UTC) (envelope-from marinosi@diogenis.ceid.upatras.gr) Received: from mail.ceid.upatras.gr (unknown [10.1.0.143]) by poseidon.ceid.upatras.gr (Postfix) with ESMTP id B055FEB4873 for ; Mon, 3 Sep 2007 03:51:38 +0300 (EEST) Received: from localhost (europa.ceid.upatras.gr [127.0.0.1]) by mail.ceid.upatras.gr (Postfix) with ESMTP id 515CA1576F5 for ; Mon, 3 Sep 2007 03:51:38 +0300 (EEST) X-Virus-Scanned: amavisd-new at ceid.upatras.gr Received: from mail.ceid.upatras.gr ([127.0.0.1]) by localhost (europa.ceid.upatras.gr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3MbsUPON4Lj9 for ; Mon, 3 Sep 2007 03:51:38 +0300 (EEST) Received: from diogenis.ceid.upatras.gr (unknown [10.1.0.181]) by mail.ceid.upatras.gr (Postfix) with ESMTP id 27A1A1576DC for ; Mon, 3 Sep 2007 03:51:38 +0300 (EEST) Received: by diogenis.ceid.upatras.gr (Postfix, from userid 3149) id 9E9ED8FF55; Mon, 3 Sep 2007 03:51:37 +0300 (EEST) Date: Mon, 3 Sep 2007 03:51:37 +0300 From: Marinos Ilias To: freebsd-current@freebsd.org Message-ID: <20070903005137.GA26694@ceid.upatras.gr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.2i Subject: Disk failure - READ_DMA X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2007 01:52:03 -0000 Hello list, I had problem with yesterday's CURRENT and my SATA disk.IIRC , I had exactly the same problem about 3 months before. Here are some messages I 've kept during the boot, which now fails and dives a db console. ad10: TIMEOUT - READ_DMA retrying (1 retry left ) LBA=30175 ad10: FAILURE - READ_DMA timed out LBA=30175 g_vfs_done():ad10s1a [READ(offset = 15417344, length =65536)] error=5 vnode_pager_getpages: I/O read error exec /rescue/init = error 5 init: not found in path ... These messages occur if I load the old boot loader ( load /boot/loader.old), else the new loader does not start.(BLX error) Unfortunately I don't have any serial console to catch any more messages. Is there any way , to boot my system again?Or I need a fresh install? Thanks, Ilias P.S: I 've tried kernel.old but nothing... From owner-freebsd-current@FreeBSD.ORG Mon Sep 3 02:26:12 2007 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E242016A417 for ; Mon, 3 Sep 2007 02:26:12 +0000 (UTC) (envelope-from keramida@FreeBSD.org) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.freebsd.org (Postfix) with ESMTP id 259E713C45D for ; Mon, 3 Sep 2007 02:26:11 +0000 (UTC) (envelope-from keramida@FreeBSD.org) Received: from kobe.laptop (dialup237.ach.sch.gr [81.186.70.237]) (authenticated bits=128) by igloo.linux.gr (8.14.1/8.14.1/Debian-8) with ESMTP id l832BQW0017082 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 3 Sep 2007 05:11:37 +0300 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.1/8.14.1) with ESMTP id l832BK6s013329; Mon, 3 Sep 2007 05:11:20 +0300 (EEST) (envelope-from keramida@FreeBSD.org) Received: (from keramida@localhost) by kobe.laptop (8.14.1/8.14.1/Submit) id l832BKs8013328; Mon, 3 Sep 2007 05:11:20 +0300 (EEST) (envelope-from keramida@FreeBSD.org) Date: Mon, 3 Sep 2007 05:11:19 +0300 From: Giorgos Keramidas To: Xin LI Message-ID: <20070903021119.GD12449@kobe.laptop> References: <20070902181119.E21906@fledge.watson.org> <46DAF092.1030708@delphij.net> <46DB5F1C.4020807@delphij.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46DB5F1C.4020807@delphij.net> X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-4.088, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.31, BAYES_00 -2.60) X-Hellug-MailScanner-From: keramida@freebsd.org X-Spam-Status: No Cc: Robert Watson , current@FreeBSD.org Subject: Re: more(1) has gotten more demanding? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2007 02:26:13 -0000 On 2007-09-03 09:10, Xin LI wrote: > Sorry, the patch. > Cheers, Still filtered out by our mail servers. Tip: It won't get through if you use a MIME type that is not text/plain. You can also put it on freefall:~delphij/public_html/ and then link to it from the email, which is some times less trouble :) From owner-freebsd-current@FreeBSD.ORG Mon Sep 3 02:34:45 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 722CA16A419; Mon, 3 Sep 2007 02:34:45 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [210.51.165.229]) by mx1.freebsd.org (Postfix) with ESMTP id EE02213C45E; Mon, 3 Sep 2007 02:34:44 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from localhost (tarsier.geekcn.org [210.51.165.229]) by tarsier.geekcn.org (Postfix) with ESMTP id 300E0EB253F; Mon, 3 Sep 2007 10:24:49 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([210.51.165.229]) by localhost (mail.geekcn.org [210.51.165.229]) (amavisd-new, port 10024) with ESMTP id TPb7jF7GxWhE; Mon, 3 Sep 2007 10:24:41 +0800 (CST) Received: from LI-Xins-MacBook.local (sina152-194.staff.sina.com.cn [61.135.152.194]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id 59DFAEB0EAA; Mon, 3 Sep 2007 10:24:41 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:cc:subject:references:in-reply-to: x-enigmail-version:openpgp:content-type; b=u2g0pHNhF30e/uArnN8BhttdTWFrJ7sCxX+UWVEr04mihU94ApmuqBSfTJCCKYIj4 Fm2viQ1+JgLhYwGtmjaPA== Message-ID: <46DB705C.2090205@delphij.net> Date: Mon, 03 Sep 2007 10:24:28 +0800 From: LI Xin Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Giorgos Keramidas References: <20070902181119.E21906@fledge.watson.org> <46DAF092.1030708@delphij.net> <46DB5F1C.4020807@delphij.net> <20070903021119.GD12449@kobe.laptop> In-Reply-To: <20070903021119.GD12449@kobe.laptop> X-Enigmail-Version: 0.95.3 OpenPGP: url=http://www.delphij.net/delphij.asc Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig8695AF335D7017A8741035F1" Cc: Robert Watson , current@freebsd.org Subject: Re: more(1) has gotten more demanding? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2007 02:34:45 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig8695AF335D7017A8741035F1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Giorgos Keramidas wrote: > On 2007-09-03 09:10, Xin LI wrote: >> Sorry, the patch. >> Cheers, >=20 > Still filtered out by our mail servers. >=20 > Tip: It won't get through if you use a MIME type that is not text/plain= =2E >=20 > You can also put it on freefall:~delphij/public_html/ and then > link to it from the email, which is some times less trouble :) I have not noticed it, sorry, let's try this: http://people.freebsd.org/~delphij/for_review/main.c.diff Cheers, --=20 Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! --------------enig8695AF335D7017A8741035F1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG23BcOfuToMruuMARCpfCAJ4y0Qzm0Ihp/kKP/gSh6aZi/NnfDgCfYZ17 CjS9nlDDwPcnvAPQcs+epio= =RbEX -----END PGP SIGNATURE----- --------------enig8695AF335D7017A8741035F1-- From owner-freebsd-current@FreeBSD.ORG Mon Sep 3 02:59:42 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4788916A41A for ; Mon, 3 Sep 2007 02:59:42 +0000 (UTC) (envelope-from marinosi@diogenis.ceid.upatras.gr) Received: from poseidon.ceid.upatras.gr (poseidon.ceid.upatras.gr [150.140.141.169]) by mx1.freebsd.org (Postfix) with ESMTP id CF86F13C45D for ; Mon, 3 Sep 2007 02:59:41 +0000 (UTC) (envelope-from marinosi@diogenis.ceid.upatras.gr) Received: from mail.ceid.upatras.gr (unknown [10.1.0.143]) by poseidon.ceid.upatras.gr (Postfix) with ESMTP id B3A24EB47B4 for ; Mon, 3 Sep 2007 05:59:08 +0300 (EEST) Received: from localhost (europa.ceid.upatras.gr [127.0.0.1]) by mail.ceid.upatras.gr (Postfix) with ESMTP id 2F4461579EF for ; Mon, 3 Sep 2007 05:59:08 +0300 (EEST) X-Virus-Scanned: amavisd-new at ceid.upatras.gr Received: from mail.ceid.upatras.gr ([127.0.0.1]) by localhost (europa.ceid.upatras.gr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lw79zTGEPGft for ; Mon, 3 Sep 2007 05:59:08 +0300 (EEST) Received: from diogenis.ceid.upatras.gr (unknown [10.1.0.181]) by mail.ceid.upatras.gr (Postfix) with ESMTP id DE0231578C3 for ; Mon, 3 Sep 2007 05:59:07 +0300 (EEST) Received: by diogenis.ceid.upatras.gr (Postfix, from userid 3149) id 02CE18FF55; Mon, 3 Sep 2007 05:59:06 +0300 (EEST) Date: Mon, 3 Sep 2007 05:59:06 +0300 From: Marinos Ilias To: freebsd-current@freebsd.org Message-ID: <20070903025905.GA31885@ceid.upatras.gr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.2i Subject: Re: Disk Failure - READ_DMA X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2007 02:59:42 -0000 Update to my previous mail: Ok I managed to boot the system with the old kernel.The new kernel will cause a failure though.So I'll go on with my old kernel .:-) Thanks , Ilias From owner-freebsd-current@FreeBSD.ORG Mon Sep 3 03:49:56 2007 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D747316A417 for ; Mon, 3 Sep 2007 03:49:56 +0000 (UTC) (envelope-from csjp@sub.vaned.net) Received: from sub.vaned.net (sub.vaned.net [205.200.235.40]) by mx1.freebsd.org (Postfix) with ESMTP id A75D313C46A for ; Mon, 3 Sep 2007 03:49:56 +0000 (UTC) (envelope-from csjp@sub.vaned.net) Received: by sub.vaned.net (Postfix, from userid 1001) id E3BE41722F; Sun, 2 Sep 2007 22:47:54 -0500 (CDT) Date: Sun, 2 Sep 2007 22:47:54 -0500 From: "Christian S.J. Peron" To: Hugo Message-ID: <20070903034754.GA79704@sub.vaned.net> References: <46DA0C5E.1050506@barafranca.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="bg08WKrSYDhXBjb5" Content-Disposition: inline In-Reply-To: <46DA0C5E.1050506@barafranca.com> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-current@FreeBSD.ORG Subject: Re: rtfree: 0xc3e377f8 has 1 refs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2007 03:49:57 -0000 --bg08WKrSYDhXBjb5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Basically, this looks like a side effect of calling rtfree() on a route when we dont hold the last reference. In reality we should be using the RTFREE()/REFREE_LOCKED() helper macros which manage reference counts in this case. I have attached a patch, please let me know if this helps. BTW, nice hostname :) On Sun, Sep 02, 2007 at 02:05:34AM +0100, Hugo wrote: > Hi list, > > While experimenting with IPv6 on a spare server, I noticed the following in > the logs: > > Sep 2 00:24:33 deserteagle kernel: rtfree: 0xc3e377f8 has 1 refs > Sep 2 00:25:01 deserteagle last message repeated 139 times > Sep 2 00:25:01 deserteagle kernel: rtfree: 0xc3e377f8 has 1 refs > Sep 2 00:25:17 deserteagle last message repeated 401 times > Sep 2 00:27:38 deserteagle last message repeated 1204 times > Sep 2 00:35:32 deserteagle last message repeated 1032 times > Sep 2 00:47:03 deserteagle last message repeated 164 times > > > Connectivity is fine, but these messages are filling up the logs. The only > traffic that particular server gets right now is ssh (over ipv6, altough by > looking at the logs the messages show up even before I login) > > > uname: > 7.0-CURRENT FreeBSD 7.0-CURRENT #2: Sat Sep 1 23:07:18 UTC 2007 > klr@deserteagle.barafranca.com:/usr/obj/usr/src/sys/DESERTEAGLE i386 > > > netstat -rn: > Internet6: > Destination Gateway Flags > Netif Expire > ::/96 ::1 UGRS > lo0 => > default 2002:c058:6301:: UGS > stf0 > ::1 ::1 UHL > lo0 > ::ffff:0.0.0.0/96 ::1 UGRS > lo0 > 2002::/24 ::1 UGRS > lo0 => > 2002::/16 2002:4655:c4f2::1 U > stf0 > 2002:4655:c4f2::/48 link#1 UC > em0 > 2002:4655:c4f2::1 link#4 UHL > lo0 > 2002:4655:c4f2::ac1d:242 00:0c:f1:bf:2a:54 UHL > lo0 > 2002:4655:c4f2::ac1d:243 00:0c:f1:bf:2a:54 UHL > lo0 > 2002:7f00::/24 ::1 UGRS > lo0 > 2002:e000::/20 ::1 UGRS > lo0 > 2002:ff00::/24 ::1 UGRS > lo0 > fe80::/10 ::1 UGRS > lo0 > fe80::%em0/64 link#1 UC > em0 > fe80::20c:f1ff:febf:2a54%em0 00:0c:f1:bf:2a:54 UHL > lo0 > fe80::%lo0/64 fe80::1%lo0 U > lo0 > fe80::1%lo0 link#3 UHL > lo0 > ff01:1::/32 link#1 UC > em0 > ff01:3::/32 ::1 UC > lo0 > ff02::/16 ::1 UGRS > lo0 > ff02::%em0/32 link#1 UC > em0 > ff02::%lo0/32 ::1 UC > lo0 > > > > I have never seen this error before. On a 6.2-RELEASE-p1 box at home (which > also got ipv6 connectivity) I do not see these errors. > > Ideas? > > Best regards, > > Hugo > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" -- Christian S.J. Peron csjp@FreeBSD.ORG FreeBSD Committer --bg08WKrSYDhXBjb5 Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="rt.diff" Index: net/if_stf.c =================================================================== RCS file: /usr/ncvs/src/sys/net/if_stf.c,v retrieving revision 1.59 diff -u -r1.59 if_stf.c --- net/if_stf.c 22 Oct 2006 11:52:15 -0000 1.59 +++ net/if_stf.c 27 Aug 2007 23:51:19 -0000 @@ -607,10 +607,10 @@ (u_int32_t)ntohl(sin.sin_addr.s_addr)); #endif if (rt) - rtfree(rt); + RTFREE_LOCKED(rt); return -1; } - rtfree(rt); + RTFREE_LOCKED(rt); } return 0; Index: netinet/in_gif.c =================================================================== RCS file: /usr/ncvs/src/sys/netinet/in_gif.c,v retrieving revision 1.36 diff -u -r1.36 in_gif.c --- netinet/in_gif.c 10 May 2007 15:58:47 -0000 1.36 +++ netinet/in_gif.c 27 Aug 2007 23:48:04 -0000 @@ -374,10 +374,10 @@ (u_int32_t)ntohl(sin.sin_addr.s_addr)); #endif if (rt) - rtfree(rt); + RTFREE_LOCKED(rt); return 0; } - rtfree(rt); + RTFREE_LOCKED(rt); } return 32 * 2; --bg08WKrSYDhXBjb5-- From owner-freebsd-current@FreeBSD.ORG Mon Sep 3 03:57:15 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 70C2D16A417 for ; Mon, 3 Sep 2007 03:57:15 +0000 (UTC) (envelope-from matheusber@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.180]) by mx1.freebsd.org (Postfix) with ESMTP id 4B81813C458 for ; Mon, 3 Sep 2007 03:57:15 +0000 (UTC) (envelope-from matheusber@gmail.com) Received: by wa-out-1112.google.com with SMTP id k17so1826265waf for ; Sun, 02 Sep 2007 20:56:54 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=SVSKHo8BcwChb0EPWzz5yW3OS1XU6tlXjWDg0SZoK0nkLan7dVlfM8cMrt+rwMDPgH3CmCDYJpwEt9XpPE2dTbb6Zejc8msoqoppiWiluDmcTWbHEQLY234YUPHpREOnc+MFSRY9qxsJgA2ZsGcAo5WAtAgz58whlQ4QDXwbmKA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=Zp7UlXGWkHYYiKbg9dpCzjHd3sf014IuOsjUYV+bJpAZFAra12Fi7PCxqcGniteQWigI6poliC+iWVa5HYOk2rk15dmdJ7UizZkPemuqUQAyvwyYSkF+WBM6mdRRP9u0/QMXmbslB9Zl0A/y6TkqwYYKsS+GPYqD6R5d5Gb6TS8= Received: by 10.114.181.1 with SMTP id d1mr2812367waf.1188791813913; Sun, 02 Sep 2007 20:56:53 -0700 (PDT) Received: by 10.115.77.13 with HTTP; Sun, 2 Sep 2007 20:56:53 -0700 (PDT) Message-ID: <4956a5e50709022056o16fe85c8oab72532afe335b43@mail.gmail.com> Date: Mon, 3 Sep 2007 00:56:53 -0300 From: Nenhum_de_Nos To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Mailman-Approved-At: Mon, 03 Sep 2007 04:18:12 +0000 Subject: qemu on a recent -current, slow like a 486 ! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2007 03:57:15 -0000 hail, I have a Turion X2 1.8GHz and created a SMP 64bits VM just for running folding at home. I'm now compiling linux kernel source for gentoo distro, and it takes a century for each module (.o) to be compiled. FreeBSD xxx.apartnet 7.0-CURRENT FreeBSD 7.0-CURRENT #0: Thu Aug 9 01:44:04 BRT 2007 root@xxx.apartnet:/usr/obj/usr/src/sys/xxx i386 and QEMU PC emulator version 0.9.0, Copyright (c) 2003-2007 Fabrice Bellard any more info, just ask ... is it always this slow ?! thanks matheus -- We will call you cygnus, The God of balance you shall be From owner-freebsd-current@FreeBSD.ORG Mon Sep 3 04:25:35 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6925F16A419 for ; Mon, 3 Sep 2007 04:25:34 +0000 (UTC) (envelope-from dougk@dougk-ff7.net) Received: from mail.dougk-ff7.net (shen.liquidneon.com [216.87.78.181]) by mx1.freebsd.org (Postfix) with ESMTP id 44A1613C45D for ; Mon, 3 Sep 2007 04:25:33 +0000 (UTC) (envelope-from dougk@dougk-ff7.net) Received: from localhost (localhost.liquidneon.com [127.0.0.1]) by mail.dougk-ff7.net (Postfix) with ESMTP id 33AB095864 for ; Sun, 2 Sep 2007 22:25:13 -0600 (MDT) X-Virus-Scanned: by amavisd-new at dougk-ff7.net Received: from mail.dougk-ff7.net ([127.0.0.1]) by localhost (shen.liquidneon.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sm1t9TKBQTgu for ; Sun, 2 Sep 2007 22:25:11 -0600 (MDT) Received: from [192.168.10.249] (CPE-24-163-209-195.kc.res.rr.com [24.163.209.195]) by mail.dougk-ff7.net (Postfix) with ESMTP id 4D6D795863 for ; Sun, 2 Sep 2007 22:25:11 -0600 (MDT) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <4956a5e50709022056o16fe85c8oab72532afe335b43@mail.gmail.com> References: <4956a5e50709022056o16fe85c8oab72532afe335b43@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <059F5A32-4979-422B-B42B-8163A151E874@dougk-ff7.net> Content-Transfer-Encoding: 7bit From: Doug Kelly Date: Sun, 2 Sep 2007 23:21:23 -0500 To: freebsd-current@freebsd.org X-Mailer: Apple Mail (2.752.3) Subject: Re: qemu on a recent -current, slow like a 486 ! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2007 04:25:35 -0000 On Sep 2, 2007, at 10:56 PM, Nenhum_de_Nos wrote: > hail, > > I have a Turion X2 1.8GHz and created a SMP 64bits VM just for running > folding at home. I'm now compiling linux kernel source for gentoo > distro, and it takes a century for each module (.o) to be compiled. > > FreeBSD xxx.apartnet 7.0-CURRENT FreeBSD 7.0-CURRENT #0: Thu Aug 9 > 01:44:04 BRT 2007 root@xxx.apartnet:/usr/obj/usr/src/sys/xxx i386 > > and > > QEMU PC emulator version 0.9.0, Copyright (c) 2003-2007 Fabrice > Bellard > > any more info, just ask ... > > is it always this slow ?! Well, I know -CURRENT's kernel has a ton of debug options enabled by default, which will adversely impact performance. You can disable them in the kernel's config file (you'll need to rebuild the kernel, though), and the GENERIC config has some notes about them. Also, qemu is a full emulator--although there is a kernel module for Linux to allow some type of virtualization, I'm not sure if it's been ported to any other OSes. In short, yes, it will be slow. I'm sure "a century" is hyperbole, but yes, even though you are on a rather fast machine, it will be slow, as every single instruction on your qemu VM is going to be emulated. --Doug Kelly From owner-freebsd-current@FreeBSD.ORG Mon Sep 3 05:24:12 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3745E16A417 for ; Mon, 3 Sep 2007 05:24:12 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.bluestop.org (muon.bluestop.org [80.68.94.188]) by mx1.freebsd.org (Postfix) with ESMTP id F093F13C478 for ; Mon, 3 Sep 2007 05:24:11 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.draftnet (dyn-62-56-57-198.dslaccess.co.uk [62.56.57.198]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by muon.bluestop.org (Postfix) with ESMTP id 931143000D; Mon, 3 Sep 2007 06:19:58 +0100 (BST) Message-ID: <46DB9A1E.4080000@cran.org.uk> Date: Mon, 03 Sep 2007 06:22:38 +0100 From: Bruce Cran User-Agent: Thunderbird 2.0.0.6 (X11/20070809) MIME-Version: 1.0 To: Doug Kelly References: <4956a5e50709022056o16fe85c8oab72532afe335b43@mail.gmail.com> <059F5A32-4979-422B-B42B-8163A151E874@dougk-ff7.net> In-Reply-To: <059F5A32-4979-422B-B42B-8163A151E874@dougk-ff7.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: qemu on a recent -current, slow like a 486 ! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2007 05:24:12 -0000 Doug Kelly wrote: > On Sep 2, 2007, at 10:56 PM, Nenhum_de_Nos wrote: > >> hail, >> >> I have a Turion X2 1.8GHz and created a SMP 64bits VM just for running >> folding at home. I'm now compiling linux kernel source for gentoo >> distro, and it takes a century for each module (.o) to be compiled. >> >> FreeBSD xxx.apartnet 7.0-CURRENT FreeBSD 7.0-CURRENT #0: Thu Aug 9 >> 01:44:04 BRT 2007 root@xxx.apartnet:/usr/obj/usr/src/sys/xxx i386 >> >> and >> >> QEMU PC emulator version 0.9.0, Copyright (c) 2003-2007 Fabrice Bellard >> >> any more info, just ask ... >> >> is it always this slow ?! > > Well, I know -CURRENT's kernel has a ton of debug options enabled by > default, which will adversely impact performance. You can disable > them in the kernel's config file (you'll need to rebuild the kernel, > though), and the GENERIC config has some notes about them. Also, qemu > is a full emulator--although there is a kernel module for Linux to > allow some type of virtualization, I'm not sure if it's been ported to > any other OSes. > > In short, yes, it will be slow. I'm sure "a century" is hyperbole, > but yes, even though you are on a rather fast machine, it will be > slow, as every single instruction on your qemu VM is going to be > emulated. The kernel module to speed up execution of the x86 emulation on x86 platforms is available in the emulators/kqemu-kmod port. -- Bruce Cran From owner-freebsd-current@FreeBSD.ORG Mon Sep 3 06:40:55 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3EDD316A417 for ; Mon, 3 Sep 2007 06:40:55 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe02.swip.net [212.247.154.33]) by mx1.freebsd.org (Postfix) with ESMTP id CD27F13C459 for ; Mon, 3 Sep 2007 06:40:54 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] Received: from [194.248.135.20] (account mc467741@c2i.net HELO laptop.lan) by mailfe02.swip.net (CommuniGate Pro SMTP 5.1.10) with ESMTPA id 601340130; Mon, 03 Sep 2007 08:39:57 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Mon, 3 Sep 2007 08:40:12 +0200 User-Agent: KMail/1.9.7 References: <20070901215358.22135.qmail@mail.integrity.hu> In-Reply-To: <20070901215358.22135.qmail@mail.integrity.hu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200709030840.13329.hselasky@c2i.net> Cc: Zahemszky Gabor Subject: Re: Panic with if_rum X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2007 06:40:55 -0000 On Saturday 01 September 2007, Zahemszky Gabor wrote: > Hi! > > Current of today, and a new USB Wifi-card. Edimax-EW-7318UG. The system > knows it, I have a rum0 interface. I can: > > ifconfig rum0 up > > OK. But: > > ifconfig rum0 scan > > and some seconds later, kernel panic: > > panic: Bad link elm 0xc5ade458 prev -> next != elm > > Any takers? > > Zahy < Gabor at Zahemszky dot HU > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" You are using OHCI ? --HPS From owner-freebsd-current@FreeBSD.ORG Mon Sep 3 10:10:37 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DE11616A417; Mon, 3 Sep 2007 10:10:37 +0000 (UTC) (envelope-from keramida@freebsd.org) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.freebsd.org (Postfix) with ESMTP id 3DB5713C45B; Mon, 3 Sep 2007 10:10:36 +0000 (UTC) (envelope-from keramida@freebsd.org) Received: from kobe.laptop (vader.bytemobile.ondsl.gr [83.235.244.135]) (authenticated bits=128) by igloo.linux.gr (8.14.1/8.14.1/Debian-8) with ESMTP id l83A9cA0011984 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 3 Sep 2007 13:09:48 +0300 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.1/8.14.1) with ESMTP id l83A9Mtm002255; Mon, 3 Sep 2007 13:09:37 +0300 (EEST) (envelope-from keramida@freebsd.org) Received: (from keramida@localhost) by kobe.laptop (8.14.1/8.14.1/Submit) id l83A9KaG002254; Mon, 3 Sep 2007 13:09:20 +0300 (EEST) (envelope-from keramida@freebsd.org) Date: Mon, 3 Sep 2007 13:09:20 +0300 From: Giorgos Keramidas To: LI Xin Message-ID: <20070903100920.GA1920@kobe.laptop> References: <20070902181119.E21906@fledge.watson.org> <46DAF092.1030708@delphij.net> <46DB5F1C.4020807@delphij.net> <20070903021119.GD12449@kobe.laptop> <46DB705C.2090205@delphij.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46DB705C.2090205@delphij.net> X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-4.079, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.32, BAYES_00 -2.60) X-Hellug-MailScanner-From: keramida@freebsd.org X-Spam-Status: No Cc: Robert Watson , current@freebsd.org Subject: Re: more(1) has gotten more demanding? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2007 10:10:38 -0000 On 2007-09-03 10:24, LI Xin wrote: >Giorgos Keramidas wrote: >> On 2007-09-03 09:10, Xin LI wrote: >>> Sorry, the patch. >>> Cheers, >> >> Still filtered out by our mail servers. >> Tip: It won't get through if you use a MIME type that is not text/plain. >> >> You can also put it on freefall:~delphij/public_html/ and then >> link to it from the email, which is some times less trouble :) > > I have not noticed it, sorry, let's try this: > http://people.freebsd.org/~delphij/for_review/main.c.diff This looks much better, and the diff is ok AFAICT :-) From owner-freebsd-current@FreeBSD.ORG Mon Sep 3 12:44:33 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E42DD16A421 for ; Mon, 3 Sep 2007 12:44:33 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.freebsd.org (Postfix) with ESMTP id 7D15813C458 for ; Mon, 3 Sep 2007 12:44:33 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 7E5FF45EBA; Mon, 3 Sep 2007 14:43:52 +0200 (CEST) Received: from localhost (pjd.wheel.pl [10.0.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 9F9CC45685; Mon, 3 Sep 2007 14:43:43 +0200 (CEST) Date: Mon, 3 Sep 2007 14:42:33 +0200 From: Pawel Jakub Dawidek To: Nathan Butcher Message-ID: <20070903124232.GC64967@garage.freebsd.pl> References: <46D4EFFF.5080807@fusiongol.com> <46D5B46D.5010202@gmail.com> <46D66A23.3060108@fusiongol.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="r7U+bLA8boMOj+mD" Content-Disposition: inline In-Reply-To: <46D66A23.3060108@fusiongol.com> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-5.9 required=3.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 Cc: freebsd-current@freebsd.org, Christian Walther Subject: Re: Encrypted zfs? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2007 12:44:34 -0000 --r7U+bLA8boMOj+mD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 30, 2007 at 03:56:35PM +0900, Nathan Butcher wrote: > > AFAIK zfs is immune against device enumeration issues itself. There is a > > nice video on YouTube showing Sun engineers setting up a ZFS pool on a > > bunch of USB sticks. Afterwards they remove all of them, shuffle them, > > and put them back in. No problem. >=20 > You're correct,... only as long as the zpool is EXPORTED FIRST, and > imported after the drives have been shuffled around. ZFS has no trouble > piecing them back together wherever they are during an import, it seems. >=20 > If you were to, say, forget to export the zpool, shutdown your system, > shuffle the drives around, and THEN restart the system with the drives > in the wrong places, zfs will consider the zpool unavailable. In this > case, all the drives will be turn up as FAULTED due to "corrupted > data"... when in reality, ZFS was set up to expect certain data to be on > certain drives, and now it just can't find it thanks to the harddrive > "hokey-pokey" done on it. >=20 > I guess glabeling isn't really necessary, but it does prevent the above > issue from ever occuring.... "An ounce of prevention" or something like > that. You are correct, but not entirely. If you don't export the pool before shuffling driver around, ZFS can still recognize them after reboot, but those drives have to support GEOM::ident attribute. A disk, when asked about this attribute, returns its serial number. If ZFS can find disk using its name, it tries to use its ident. Not all GEOM providers support idents. Currently only ATA disks and slices/partitions on top of ATA disks. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --r7U+bLA8boMOj+mD Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFG3AE4ForvXbEpPzQRArw6AJ9BdneGpbJLOPmE5WOAcBvE09x9lgCgvTZe icdEu0jztGVLMEBH0k0/Q28= =amWA -----END PGP SIGNATURE----- --r7U+bLA8boMOj+mD-- From owner-freebsd-current@FreeBSD.ORG Mon Sep 3 13:40:15 2007 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7E07D16A418 for ; Mon, 3 Sep 2007 13:40:15 +0000 (UTC) (envelope-from hugo@barafranca.com) Received: from mail.barafranca.com (mail.barafranca.com [67.19.101.164]) by mx1.freebsd.org (Postfix) with ESMTP id 5306813C468 for ; Mon, 3 Sep 2007 13:40:15 +0000 (UTC) (envelope-from hugo@barafranca.com) Received: from localhost (localhost [127.0.0.1]) by mail.barafranca.com (Postfix) with ESMTP id 97781C382B; Mon, 3 Sep 2007 14:06:25 +0000 (UTC) Received: from mail.barafranca.com ([67.19.101.164]) by localhost (mail.barafranca.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 74657-01; Mon, 3 Sep 2007 14:05:47 +0000 (UTC) Received: from nexus.bsdlan.org (64.b6.1343.static.theplanet.com [67.19.182.100]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.barafranca.com (Postfix) with ESMTP id A1DC1C4932; Mon, 3 Sep 2007 14:05:46 +0000 (UTC) Message-ID: <46DC0A96.3030101@barafranca.com> Date: Mon, 03 Sep 2007 14:22:30 +0100 From: Hugo User-Agent: Thunderbird 2.0.0.6 (X11/20070816) MIME-Version: 1.0 To: "Christian S.J. Peron" , freebsd-current@FreeBSD.ORG References: <46DA0C5E.1050506@barafranca.com> <20070903034754.GA79704@sub.vaned.net> In-Reply-To: <20070903034754.GA79704@sub.vaned.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at barafranca.com X-Spam-Status: No, score=0 tagged_above=-1 required=4 tests=[none] X-Spam-Score: 0 X-Spam-Level: Cc: Subject: Re: rtfree: 0xc3e377f8 has 1 refs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2007 13:40:15 -0000 Christian S.J. Peron wrote: > Basically, this looks like a side effect of calling rtfree() on a route > when we dont hold the last reference. In reality we should be using the > RTFREE()/REFREE_LOCKED() helper macros which manage reference counts > in this case. > > I have attached a patch, please let me know if this helps. BTW, nice > hostname :) > > Hi, I've applied the patch and so far (10 mins) the messages are gone :) I'll send another email if the situation changes. Thanks for the patch! Best regards, Hugo From owner-freebsd-current@FreeBSD.ORG Mon Sep 3 13:43:58 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 311B216A420 for ; Mon, 3 Sep 2007 13:43:58 +0000 (UTC) (envelope-from citrin@citrin.ru) Received: from mail.classis.ru (classis.ru [213.248.60.120]) by mx1.freebsd.org (Postfix) with ESMTP id DEE8B13C457 for ; Mon, 3 Sep 2007 13:43:57 +0000 (UTC) (envelope-from citrin@citrin.ru) Received: from citrin (unknown [81.19.65.104]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: citrin.citrin.ru) by mail.classis.ru (Postfix) with ESMTP id BF80812221B1 for ; Mon, 3 Sep 2007 17:29:05 +0400 (MSD) Date: Mon, 3 Sep 2007 17:30:24 +0400 From: Anton Yuzhaninov X-Mailer: The Bat! (v3.99.3) Professional Organization: Rambler X-Priority: 3 (Normal) Message-ID: <372905364.20070903173024@citrin.ru> To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: dovecot kqueue problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2007 13:43:58 -0000 Hello. dovecot-1.0.3 compiled with kqueue support periodically stop to accept connections: Listen queue not empty: Current listen queue sizes (qlen/incqlen/maxqlen) Proto Listen Local Address tcp4 6/0/8 *.143 however kevent return 0 pending event: truss -D -p 71851 0.000000000 SIGNAL 17 (SIGSTOP) 0.000016761 gettimeofday({1188823517.452247},0x525bd0) = 0 (0x0) 0.000015923 gettimeofday({1188823517.452459},0x0) = 0 (0x0) 0.624191428 kevent(8,0x0,0,{},78,{0.623541000}) = 0 (0x0) 0.000016202 gettimeofday({1188823518.077250},0x525bd0) = 0 (0x0) 0.000015644 gettimeofday({1188823518.077458},0x0) = 0 (0x0) 1.000150078 kevent(8,0x0,0,{},78,{0.999542000}) = 0 (0x0) $ uname -a FreeBSD mailsupport.rambler.ru 7.0-CURRENT FreeBSD 7.0-CURRENT #6: Mon Aug 13 17:10:28 MSD 2007 citrin@mailsupport.rambler.ru:/usr/obj/usr/src/sys/MAIL amd64 How I can debug this problem? It may dovecot bug as well as kernel bug. How I can see list of knotes corresponding to given kqueue? I try to see kqueue->kq_knlist (via kgdb), but it always empty, even when dovecot work properly. -- WBR, Anton Yuzhaninov. From owner-freebsd-current@FreeBSD.ORG Mon Sep 3 14:11:08 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8A00D16A41A for ; Mon, 3 Sep 2007 14:11:08 +0000 (UTC) (envelope-from citrin@citrin.ru) Received: from mail.classis.ru (classis.ru [213.248.60.120]) by mx1.freebsd.org (Postfix) with ESMTP id 04D1113C483 for ; Mon, 3 Sep 2007 14:11:07 +0000 (UTC) (envelope-from citrin@citrin.ru) Received: from citrin (unknown [81.19.65.104]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: citrin.citrin.ru) by mail.classis.ru (Postfix) with ESMTP id E4D5012221B1 for ; Mon, 3 Sep 2007 18:11:06 +0400 (MSD) Date: Mon, 3 Sep 2007 18:12:21 +0400 From: Anton Yuzhaninov X-Mailer: The Bat! (v3.99.3) Professional Organization: Rambler X-Priority: 3 (Normal) Message-ID: <1975211233.20070903181221@citrin.ru> To: freebsd-current@freebsd.org In-Reply-To: <372905364.20070903173024@citrin.ru> References: <372905364.20070903173024@citrin.ru> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="----------FE127348BE067" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: dovecot kqueue problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2007 14:11:08 -0000 This is a cryptographically signed message in MIME format. ------------FE127348BE067 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable AY> dovecot-1.0.3 compiled with kqueue support periodically stop to accept AY> connections: AY> Listen queue not empty: AY> Current listen queue sizes (qlen/incqlen/maxqlen) AY> Proto Listen Local Address AY> tcp4 6/0/8 *.143 AY> however kevent return 0 pending event: with poll it also stop working: Current listen queue sizes (qlen/incqlen/maxqlen) Proto Listen Local Address tcp4 3/0/8 *.143 It seems to be dovecot bug... --=20 Anton Yuzhaninov. ------------FE127348BE067-- From owner-freebsd-current@FreeBSD.ORG Mon Sep 3 15:24:42 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EE87316A418 for ; Mon, 3 Sep 2007 15:24:41 +0000 (UTC) (envelope-from citrin@citrin.ru) Received: from mail.classis.ru (classis.ru [213.248.60.120]) by mx1.freebsd.org (Postfix) with ESMTP id 6D4A313C465 for ; Mon, 3 Sep 2007 15:24:41 +0000 (UTC) (envelope-from citrin@citrin.ru) Received: from citrin (unknown [81.19.65.104]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: citrin.citrin.ru) by mail.classis.ru (Postfix) with ESMTP id 08BE61227C05 for ; Mon, 3 Sep 2007 19:24:40 +0400 (MSD) Date: Mon, 3 Sep 2007 19:25:58 +0400 From: Anton Yuzhaninov X-Mailer: The Bat! (v3.99.3) Professional Organization: Rambler X-Priority: 3 (Normal) Message-ID: <8488755.20070903192558@citrin.ru> To: freebsd-current@freebsd.org In-Reply-To: <372905364.20070903173024@citrin.ru> References: <372905364.20070903173024@citrin.ru> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="----------D618ACD36BECF40" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: dovecot kqueue problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2007 15:24:42 -0000 This is a cryptographically signed message in MIME format. ------------D618ACD36BECF40 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable AY> dovecot-1.0.3 compiled with kqueue support periodically stop to accept AY> connections: AY> Listen queue not empty: AY> Current listen queue sizes (qlen/incqlen/maxqlen) AY> Proto Listen Local Address AY> tcp4 6/0/8 *.143 sorry for noise, it was my configuration mistake Dovecot use imap-login procees not only for auth, but all time when imap connection open, and so can handle not more than login_max_processes_count concurrent imap connections. --=20 Anton Yuzhaninov. ------------D618ACD36BECF40-- From owner-freebsd-current@FreeBSD.ORG Mon Sep 3 16:02:20 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9FD5E16A417 for ; Mon, 3 Sep 2007 16:02:20 +0000 (UTC) (envelope-from gabor@zahemszky.hu) Received: from mail.integrity.hu (mail.integrity.hu [195.56.44.40]) by mx1.freebsd.org (Postfix) with SMTP id 05BBF13C491 for ; Mon, 3 Sep 2007 16:02:17 +0000 (UTC) (envelope-from gabor@zahemszky.hu) Received: (qmail 26567 invoked by uid 89); 3 Sep 2007 18:02:15 +0200 Message-ID: <20070903160215.26566.qmail@mail.integrity.hu> References: <20070901215358.22135.qmail@mail.integrity.hu> <200709030840.13329.hselasky@c2i.net> In-Reply-To: <200709030840.13329.hselasky@c2i.net> From: "Zahemszky Gabor" To: Hans Petter Selasky Date: Mon, 03 Sep 2007 18:02:15 +0200 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2"; format=flowed Content-Transfer-Encoding: quoted-printable X-Sender: gabor@zahemszky.hu X-Mailman-Approved-At: Mon, 03 Sep 2007 16:25:11 +0000 Cc: freebsd-current@freebsd.org Subject: Re: Panic with if_rum X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2007 16:02:20 -0000 Hans Petter Selasky =EDrta:=20 >> Current of today, and a new USB Wifi-card. Edimax-EW-7318UG. The syste= m >> knows it, I have a rum0 interface. I can:=20 >> >> ifconfig rum0 up=20 >> >> OK. But:=20 >> >> ifconfig rum0 scan=20 >> >> and some seconds later, kernel panic:=20 >> >> panic: Bad link elm 0xc5ade458 prev -> next !=3D elm > You are using OHCI ? Hi!=20 Now, my machine use uhci. Snippet from dmesg=20 $ dmesg | fgrep -e uhci -e ohci -e ehci -e usb -e rum | fgrep -v fwohci uhci0: port 0x30a0-0x30bf irq 16 at devic= e=20 26.0 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhci1: port 0x3080-0x309f irq 21 at devic= e=20 26.1 on pci0 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 ehci0: mem 0x90325400-0x903257ff irq = 18=20 at device 26.7 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb2: EHCI version 1.0 usb2: companion controllers, 2 ports each: usb0 usb1 usb2: on ehci0 usb2: USB revision 2.0 uhub2: on usb2 uhci2: port 0x3060-0x307f irq 23 at devic= e=20 29.0 on pci0 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb3: on uhci2 usb3: USB revision 1.0 uhub3: on usb3 uhci3: port 0x3040-0x305f irq 19 at devic= e=20 29.1 on pci0 uhci3: [GIANT-LOCKED] uhci3: [ITHREAD] usb4: on uhci3 usb4: USB revision 1.0 uhub4: on usb4 uhci4: port 0x3020-0x303f irq 18 at devic= e=20 29.2 on pci0 uhci4: [GIANT-LOCKED] uhci4: [ITHREAD] usb5: on uhci4 usb5: USB revision 1.0 uhub5: on usb5 ehci1: mem 0x90325000-0x903253ff irq = 23=20 at device 29.7 on pci0 ehci1: [GIANT-LOCKED] ehci1: [ITHREAD] usb6: EHCI version 1.0 usb6: companion controllers, 2 ports each: usb3 usb4 usb5 usb6: on ehci1 usb6: USB revision 2.0 uhub6: on usb6 rum0: on uhub2 rum0: MAC/BBP RT2573 (rev 0x2573a), RF RT2528 rum0: Ethernet address: 00:0e:2e:c1:27:42 rum0: if_start running deferred for Giant $=20 Have you got any idea?=20 Thanks, Zahy < Gabor at Zahemszky dot HU > From owner-freebsd-current@FreeBSD.ORG Mon Sep 3 16:36:46 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8788516A469 for ; Mon, 3 Sep 2007 16:36:46 +0000 (UTC) (envelope-from oliver@akephalos.de) Received: from mailout05.sul.t-online.com (mailout05.sul.t-online.de [194.25.134.82]) by mx1.freebsd.org (Postfix) with ESMTP id 2624A13C494 for ; Mon, 3 Sep 2007 16:36:45 +0000 (UTC) (envelope-from oliver@akephalos.de) Received: from fwd32.aul.t-online.de by mailout05.sul.t-online.com with smtp id 1ISEuq-0005u9-02; Mon, 03 Sep 2007 18:36:44 +0200 Received: from localhost (V8domaZVQeh4E8W1wG81bhqpvTpb21-Mo11bIawqEmv8UdWJ+53ikE@[84.165.104.7]) by fwd32.t-online.de with esmtp id 1ISEui-1lCcCG0; Mon, 3 Sep 2007 18:36:36 +0200 Date: Mon, 3 Sep 2007 18:36:34 +0200 From: Oliver Herold To: freebsd-current@freebsd.org Message-ID: <20070903163634.GA37746@olymp.home> References: <20070901215358.22135.qmail@mail.integrity.hu> <200709030840.13329.hselasky@c2i.net> <20070903160215.26566.qmail@mail.integrity.hu> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20070903160215.26566.qmail@mail.integrity.hu> User-Agent: Mutt/1.5.16 (2007-06-09) X-ID: V8domaZVQeh4E8W1wG81bhqpvTpb21-Mo11bIawqEmv8UdWJ+53ikE X-TOI-MSGID: 32ed2904-0741-4784-8081-c6412ee39450 Subject: Re: Panic with if_rum X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2007 16:36:46 -0000 Hi I made the same experience with current, could load if_rum, but after a while a kernel panic occured. It's a silver Edimax USB stick (rt71). Oliver On Mon, Sep 03, 2007 at 06:02:15PM +0200, Zahemszky Gabor wrote: > Hans Petter Selasky írta: >>> Current of today, and a new USB Wifi-card. Edimax-EW-7318UG. The system >>> knows it, I have a rum0 interface. I can: >>> ifconfig rum0 up >>> OK. But: >>> ifconfig rum0 scan >>> and some seconds later, kernel panic: >>> panic: Bad link elm 0xc5ade458 prev -> next != elm > >> You are using OHCI ? > > Hi! > Now, my machine use uhci. Snippet from dmesg > $ dmesg | fgrep -e uhci -e ohci -e ehci -e usb -e rum | fgrep -v fwohci > uhci0: port 0x30a0-0x30bf irq 16 at device > 26.0 on pci0 > uhci0: [GIANT-LOCKED] > uhci0: [ITHREAD] > usb0: on uhci0 > usb0: USB revision 1.0 > uhub0: on usb0 > uhci1: port 0x3080-0x309f irq 21 at device > 26.1 on pci0 > uhci1: [GIANT-LOCKED] > uhci1: [ITHREAD] > usb1: on uhci1 > usb1: USB revision 1.0 > uhub1: on usb1 > ehci0: mem 0x90325400-0x903257ff irq 18 > at device 26.7 on pci0 > ehci0: [GIANT-LOCKED] > ehci0: [ITHREAD] > usb2: EHCI version 1.0 > usb2: companion controllers, 2 ports each: usb0 usb1 > usb2: on ehci0 > usb2: USB revision 2.0 > uhub2: on usb2 > uhci2: port 0x3060-0x307f irq 23 at device > 29.0 on pci0 > uhci2: [GIANT-LOCKED] > uhci2: [ITHREAD] > usb3: on uhci2 > usb3: USB revision 1.0 > uhub3: on usb3 > uhci3: port 0x3040-0x305f irq 19 at device > 29.1 on pci0 > uhci3: [GIANT-LOCKED] > uhci3: [ITHREAD] > usb4: on uhci3 > usb4: USB revision 1.0 > uhub4: on usb4 > uhci4: port 0x3020-0x303f irq 18 at device > 29.2 on pci0 > uhci4: [GIANT-LOCKED] > uhci4: [ITHREAD] > usb5: on uhci4 > usb5: USB revision 1.0 > uhub5: on usb5 > ehci1: mem 0x90325000-0x903253ff irq 23 > at device 29.7 on pci0 > ehci1: [GIANT-LOCKED] > ehci1: [ITHREAD] > usb6: EHCI version 1.0 > usb6: companion controllers, 2 ports each: usb3 usb4 usb5 > usb6: on ehci1 > usb6: USB revision 2.0 > uhub6: on usb6 > rum0: on uhub2 > rum0: MAC/BBP RT2573 (rev 0x2573a), RF RT2528 > rum0: Ethernet address: 00:0e:2e:c1:27:42 > rum0: if_start running deferred for Giant > $ > Have you got any idea? > Thanks, Zahy < Gabor at Zahemszky dot HU > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" -- Anarchy may not be the best form of government, but it's better than no government at all. From owner-freebsd-current@FreeBSD.ORG Mon Sep 3 19:14:53 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3B75D16A41A for ; Mon, 3 Sep 2007 19:14:53 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.191]) by mx1.freebsd.org (Postfix) with ESMTP id C13F513C46A for ; Mon, 3 Sep 2007 19:14:52 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: by nf-out-0910.google.com with SMTP id k4so1227867nfd for ; Mon, 03 Sep 2007 12:14:51 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:received:received:date:from:to:subject:message-id:mail-followup-to:mime-version:content-type:content-disposition:user-agent; b=Gh6VOWM0XSuXWSeSWgFYp9ZrVCTiYSrbtJHzU7h2CEP0dHrfYhAxBZQZL35wnbjBX16V12o8zpwzoFnVuDqzmbh8qgpF92tQ2Lqi6IV24+Ls0M8CZw9rO2Eppi/T/JtSFLozGp6Z3FcmuC6Nhl9r7FvRxI8fMhR/MOCiH9bFG5s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:date:from:to:subject:message-id:mail-followup-to:mime-version:content-type:content-disposition:user-agent; b=S6nsg14eAsILZnwAZLwhpIOFXUopQ0VduQn6dg+J9ea3EhtuOmIr4H5vlgzLEg2Gy/zv4K9AiVJ6vOali/PEE27rR/lSoxsAzHgAFOWfO7tPZm0EPgKG5TOTx5bN7f8mnIXzZzK+tWaqGcH4TleYh6pEmXYKwM50X3jUS8cliW8= Received: by 10.86.80.5 with SMTP id d5mr3658431fgb.1188846891333; Mon, 03 Sep 2007 12:14:51 -0700 (PDT) Received: from roadrunner.spoerlein.net ( [85.180.187.67]) by mx.google.com with ESMTPS id 22sm6524691fkr.2007.09.03.12.14.49 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 03 Sep 2007 12:14:49 -0700 (PDT) Received: from roadrunner.spoerlein.net (localhost [127.0.0.1]) by roadrunner.spoerlein.net (8.14.1/8.14.1) with ESMTP id l83JElMn004723 for ; Mon, 3 Sep 2007 21:14:47 +0200 (CEST) (envelope-from uspoerlein@gmail.com) Received: (from q@localhost) by roadrunner.spoerlein.net (8.14.1/8.14.1/Submit) id l83JEkuP004722 for current@freebsd.org; Mon, 3 Sep 2007 21:14:46 +0200 (CEST) (envelope-from uspoerlein@gmail.com) Date: Mon, 3 Sep 2007 21:14:46 +0200 From: Ulrich Spoerlein To: current@freebsd.org Message-ID: <20070903191446.GA2609@roadrunner.spoerlein.net> Mail-Followup-To: current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.16 (2007-06-09) Cc: Subject: ls(1) referring to xterm-color X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2007 19:14:53 -0000 Hi current, ls(1) contains the following passage under ENVIRONMENT about color output: CLICOLOR Use ANSI color sequences to distinguish file types. See LSCOLORS below. In addition to the file types mentioned in the -F option some extra attributes (setuid bit set, etc.) are also displayed. The colorization is dependent on a terminal type with the proper termcap(5) capabili- ties. The default ``cons25'' console has the proper capabilities, but to display the colors in an xterm(1), for example, the TERM variable must be set to ``xterm-color''. Other terminal types may require simi- lar adjustments. Colorization is silently disabled if the output is not directed to a terminal unless the CLICOLOR_FORCE variable is defined. But xterm grew color support some time ago, so the reference to 'xterm-color' should probably be removed or changed to 'xterm'. Cheers, Ulrich Spoerlein -- It is better to remain silent and be thought a fool, than to speak, and remove all doubt. From owner-freebsd-current@FreeBSD.ORG Mon Sep 3 19:56:38 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0D66116A41A for ; Mon, 3 Sep 2007 19:56:38 +0000 (UTC) (envelope-from dickey@saltmine.radix.net) Received: from saltmine.radix.net (saltmine.radix.net [207.192.128.40]) by mx1.freebsd.org (Postfix) with ESMTP id CBB3513C458 for ; Mon, 3 Sep 2007 19:56:37 +0000 (UTC) (envelope-from dickey@saltmine.radix.net) Received: from saltmine.radix.net (localhost [127.0.0.1]) by saltmine.radix.net (8.12.2/8.12.2) with ESMTP id l83Jualj016176 for ; Mon, 3 Sep 2007 15:56:36 -0400 (EDT) Received: (from dickey@localhost) by saltmine.radix.net (8.12.2/8.12.2/Submit) id l83Jua3k016175 for current@freebsd.org; Mon, 3 Sep 2007 15:56:36 -0400 (EDT) Date: Mon, 3 Sep 2007 15:56:36 -0400 From: Thomas Dickey To: current@freebsd.org Message-ID: <20070903195636.GA13138@saltmine.radix.net> References: <20070903191446.GA2609@roadrunner.spoerlein.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3V7upXqbjpZ4EhLz" Content-Disposition: inline In-Reply-To: <20070903191446.GA2609@roadrunner.spoerlein.net> User-Agent: Mutt/1.3.27i Cc: Subject: Re: ls(1) referring to xterm-color X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2007 19:56:38 -0000 --3V7upXqbjpZ4EhLz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Sep 03, 2007 at 09:14:46PM +0200, Ulrich Spoerlein wrote: > ls(1) contains the following passage under ENVIRONMENT about color > output: =2E.. > But xterm grew color support some time ago, so the reference to > 'xterm-color' should probably be removed or changed to 'xterm'. xterm grew color about 4 years before ls was changed in 2000 to provide this feature... --=20 Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net --3V7upXqbjpZ4EhLz Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (SunOS) Comment: For info see http://www.gnupg.org iD8DBQFG3GbztIqByHxlDocRAkmoAKCb/0NSbA00Zvb4TGKPKu/eeCepmwCfcmxq DQ1RT3KioOCyxi89PBW2PqY= =jXWf -----END PGP SIGNATURE----- --3V7upXqbjpZ4EhLz-- From owner-freebsd-current@FreeBSD.ORG Mon Sep 3 23:54:57 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D03BE16A474 for ; Mon, 3 Sep 2007 23:54:57 +0000 (UTC) (envelope-from matheusber@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.180]) by mx1.freebsd.org (Postfix) with ESMTP id AC91F13C457 for ; Mon, 3 Sep 2007 23:54:57 +0000 (UTC) (envelope-from matheusber@gmail.com) Received: by wa-out-1112.google.com with SMTP id k17so2107283waf for ; Mon, 03 Sep 2007 16:54:57 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=JVdkmZ6w4h4ajhaFKx3tkNhojDkYBVg/Sy/1m5+i04fadrcLRNpn9NOkgOTVb+WwaVCoSum1yDCDXmndOPINpSnrlEmwthQZh/PEe+kkO2TDoDYCFHhYqfomWeNRVIt+R1qtoH2na047+ru7oBK7Dzok/IGd/UVzKFpTfOD3T8c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=WXuDGuxt1yRduyFFugP3aVnS6/ijO28XasoQTaIA3yRuJ1f0mQC6J3MGG06n/pggM5rv9NdB2m1DPz72/c2ayOta7tI3SEiP1GWrOG+Qad4IIALAGaEuWj5nTiC095nRmHPDUPB9b61Gg9eghq4aNMBlJbsHAPYsYzvCqs/ibbc= Received: by 10.114.160.1 with SMTP id i1mr236943wae.1188863697117; Mon, 03 Sep 2007 16:54:57 -0700 (PDT) Received: by 10.115.77.13 with HTTP; Mon, 3 Sep 2007 16:54:57 -0700 (PDT) Message-ID: <4956a5e50709031654v9b13eb9na0a964dd9cb7f497@mail.gmail.com> Date: Mon, 3 Sep 2007 20:54:57 -0300 From: Nenhum_de_Nos To: "Bruce Cran" , freebsd-current@freebsd.org In-Reply-To: <46DC4118.8020300@cran.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4956a5e50709022056o16fe85c8oab72532afe335b43@mail.gmail.com> <059F5A32-4979-422B-B42B-8163A151E874@dougk-ff7.net> <46DB9A1E.4080000@cran.org.uk> <4956a5e50709030343x6de3ab6frab925421859bd7f0@mail.gmail.com> <46DC4118.8020300@cran.org.uk> X-Mailman-Approved-At: Tue, 04 Sep 2007 00:20:18 +0000 Cc: Subject: Re: qemu on a recent -current, slow like a 486 ! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2007 23:54:57 -0000 On 9/3/07, Bruce Cran wrote: > Nenhum_de_Nos wrote: > > I have disabled all but one debug support: > > > > makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols > > > > no witness also > > > > thanks > > > > matheus > > > > > > Hi Matheus, > > If you haven't tried kqemu-kmod, I would highly recommend it - with the > caveat that, being a kernel module that hasn't been extensively tested, > it may crash your system. > It should speed up qemu to near-native speeds since it allows the code > to run natively instead of being interpreted one instruction at a time. > > Cheers, > Bruce Cran hm, I'll try this today :) thanks, but now what I think will most kill performance is that even though I say -smp 2 and it has two cpus (my machine is in fact dual core), it has one and only one process for all qemu vm, and there fore uses just one core. is it really supposed to behave this way ? thanks again matheus -- We will call you cygnus, The God of balance you shall be From owner-freebsd-current@FreeBSD.ORG Tue Sep 4 02:40:05 2007 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 19C1616A418; Tue, 4 Sep 2007 02:40:05 +0000 (UTC) (envelope-from mpp@mppsystems.com) Received: from lugdush.gulftel.com (lugdush.gulftel.com [216.231.163.39]) by mx1.freebsd.org (Postfix) with ESMTP id EC43013C4A3; Tue, 4 Sep 2007 02:40:04 +0000 (UTC) (envelope-from mpp@mppsystems.com) Received: from localhost (localhost [127.0.0.1]) by lugdush.gulftel.com (Postfix) with ESMTP id BEBC9C3B3; Mon, 3 Sep 2007 20:44:13 -0500 (CDT) X-Virus-Scanned: amavisd-new at gulftel.com Received: from lugdush.gulftel.com ([127.0.0.1]) by localhost (lugdush.gulftel.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yNIMPUZf91ih; Mon, 3 Sep 2007 20:44:12 -0500 (CDT) Received: from mail.mppsystems.com (unknown [10.17.6.142]) by lugdush.gulftel.com (Postfix) with ESMTP id 8CF54C380; Mon, 3 Sep 2007 20:44:08 -0500 (CDT) Received: by mail.mppsystems.com (Postfix, from userid 1000) id 0AC5C115E0; Mon, 3 Sep 2007 20:44:07 -0500 (CDT) Date: Mon, 3 Sep 2007 20:44:07 -0500 From: Mike Pritchard To: Dmitry Morozovsky Message-ID: <20070904014407.GA58342@mail.mppsystems.com> References: <20070902193609.O95913@woozle.rinet.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070902193609.O95913@woozle.rinet.ru> User-Agent: mutt-ng/devel-r804 (FreeBSD) X-Mailman-Approved-At: Tue, 04 Sep 2007 03:25:48 +0000 Cc: Pawel Jakub Dawidek , current@FreeBSD.org Subject: Re: quotas on gjournal X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2007 02:40:05 -0000 On Sun, Sep 02, 2007 at 07:37:33PM +0400, Dmitry Morozovsky wrote: > Dear Pawel, > > it seems gjournal is not fully compatible with quotas now: > > root@n5600:/# /usr/obj/usr/src/sbin/quotacheck/quotacheck -v -a > /dev/mirror/m0d (/usr): EXITED WITH SIGNAL 11 > /dev/mirror/m0e.journal (/var): EXITED WITH SIGNAL 11 > /dev/mirror/m0f.journal (/lh): EXITED WITH SIGNAL 11 > /dev/mirror/m0g.journal (/st): EXITED WITH SIGNAL 11 > THE FOLLOWING FILE SYSTEMS HAD AN UNEXPECTED INCONSISTENCY: > /dev/mirror/m0d (/usr), /dev/mirror/m0e.journal (/var), > /dev/mirror/m0f.journal (/lh), /dev/mirror/m0g.journal (/st) > > Any hints? What does /etc/fstab look like for those file systems? -- Mike Pritchard mpp @ FreeBSD.org "If tyranny and oppression come to this land, it will be in the guise of fighting a foreign enemy." - James Madison (1787) From owner-freebsd-current@FreeBSD.ORG Tue Sep 4 03:41:24 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E438D16A417 for ; Tue, 4 Sep 2007 03:41:24 +0000 (UTC) (envelope-from ntarmos@ceid.upatras.gr) Received: from poseidon.ceid.upatras.gr (poseidon.ceid.upatras.gr [150.140.141.169]) by mx1.freebsd.org (Postfix) with ESMTP id 62DB113C4B6 for ; Tue, 4 Sep 2007 03:41:24 +0000 (UTC) (envelope-from ntarmos@ceid.upatras.gr) Received: from mail.ceid.upatras.gr (unknown [10.1.0.143]) by poseidon.ceid.upatras.gr (Postfix) with ESMTP id BB98EEB48C1 for ; Tue, 4 Sep 2007 06:16:26 +0300 (EEST) Received: from localhost (europa.ceid.upatras.gr [127.0.0.1]) by mail.ceid.upatras.gr (Postfix) with ESMTP id 6512D157C3B for ; Tue, 4 Sep 2007 06:16:26 +0300 (EEST) X-Virus-Scanned: amavisd-new at ceid.upatras.gr Received: from mail.ceid.upatras.gr ([127.0.0.1]) by localhost (europa.ceid.upatras.gr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dpvFPQMdjmVb for ; Tue, 4 Sep 2007 06:16:26 +0300 (EEST) Received: from ace.b020.ceid.upatras.gr (ppp235-080.dsl.hol.gr [89.210.235.80]) by mail.ceid.upatras.gr (Postfix) with ESMTP id 0F739157BE1 for ; Tue, 4 Sep 2007 06:16:26 +0300 (EEST) Received: by ace.b020.ceid.upatras.gr (Postfix, from userid 1001) id 0220E3F40B; Tue, 4 Sep 2007 06:16:31 +0300 (EEST) Date: Tue, 4 Sep 2007 06:16:31 +0300 From: Nikos Ntarmos To: FreeBSD Current Message-ID: <20070904031631.GA24637@ace.b020.ceid.upatras.gr> Mail-Followup-To: FreeBSD Current References: <20070904030616.GA76410@ace.b020.ceid.upatras.gr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070904030616.GA76410@ace.b020.ceid.upatras.gr> Organization: NetCInS Lab., C.E.I.D., U. of Patras, Greece WWW-Homepage: http://ntarmos.dyndns.org/ X-PGP-Fingerprint: 9680 60A7 DE60 0298 B1F0 9B22 9BA2 7569 CF95 160A Office-Phone: +30-2610-996919 Office-Fax: +30-2610-969011 GPS-Info: 38.31N, 21.82E User-Agent: mutt-ng/devel-r804 (FreeBSD) Subject: find(1)'s -L and -delete not working well together (bin/90687) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2007 03:41:25 -0000 Hi there. I just submitted the following as a followup to bin/90687. I'm also posting it here should someone think it is important enough to go into the upcoming 7.0 release, since bin/90687 has been buried for nearly two years. I just stumbled upon this issue while reading the manpage for find(1). IMHO the fact that -delete turns -follow off is a good thing, so I consider this more of a bug in the manpage. The included patch removes the erroneous example and adds a word or two about -delete not honoring -L. There is a mention of -delete not interacting well with options that alter the traversal algorithm, but that is somewhat vague in this case. --- find.1.diff begins here --- Index: find.1 =================================================================== RCS file: /opt/freebsd/cvs/src/usr.bin/find/find.1,v retrieving revision 1.82 diff -u -r1.82 find.1 --- find.1 28 Feb 2007 10:19:25 -0000 1.82 +++ find.1 4 Sep 2007 02:56:40 -0000 @@ -306,6 +306,24 @@ .Dq Pa \&. for security reasons. Depth-first traversal processing is implied by this option. +Moreover, beware that +.Ic -delete +does +.Ar not +honor the semantics of +.Ic -L +since it turns off following of symbolic links for security reasons. +Thus, +.Pp +.Dl "find -L /usr/ports/packages -type l -delete" +.Pp +would delete +.Ar all +symbolic links under +.Ar /usr/ports/packages +as if +.Ic -L +had not been defined in the command line at all. .It Ic -depth Always true; same as the @@ -843,9 +861,6 @@ Use the .Xr echo 1 command to print out a list of all the files. -.It Li "find -L /usr/ports/packages -type l -delete" -Delete all broken symbolic links in -.Pa /usr/ports/packages . .It Li "find /usr/src -name CVS -prune -o -depth +6 -print" Find files and directories that are at least seven levels deep in the working directory ---- find.1.diff ends here ---- Cheers \n\n From owner-freebsd-current@FreeBSD.ORG Tue Sep 4 04:56:41 2007 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C415916A417; Tue, 4 Sep 2007 04:56:41 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) by mx1.freebsd.org (Postfix) with ESMTP id 485A713C467; Tue, 4 Sep 2007 04:56:41 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.1/8.14.1) with ESMTP id l844ud8n082823; Tue, 4 Sep 2007 08:56:39 +0400 (MSD) (envelope-from marck@rinet.ru) Date: Tue, 4 Sep 2007 08:56:39 +0400 (MSD) From: Dmitry Morozovsky To: Mike Pritchard In-Reply-To: <20070904014407.GA58342@mail.mppsystems.com> Message-ID: <20070904085202.E62050@woozle.rinet.ru> References: <20070902193609.O95913@woozle.rinet.ru> <20070904014407.GA58342@mail.mppsystems.com> X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (woozle.rinet.ru [0.0.0.0]); Tue, 04 Sep 2007 08:56:39 +0400 (MSD) Cc: Pawel Jakub Dawidek , current@FreeBSD.org Subject: Re: quotas on gjournal X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2007 04:56:41 -0000 On Mon, 3 Sep 2007, Mike Pritchard wrote: MP> > it seems gjournal is not fully compatible with quotas now: MP> > MP> > root@n5600:/# /usr/obj/usr/src/sbin/quotacheck/quotacheck -v -a MP> > /dev/mirror/m0d (/usr): EXITED WITH SIGNAL 11 MP> > /dev/mirror/m0e.journal (/var): EXITED WITH SIGNAL 11 MP> > /dev/mirror/m0f.journal (/lh): EXITED WITH SIGNAL 11 MP> > /dev/mirror/m0g.journal (/st): EXITED WITH SIGNAL 11 MP> > THE FOLLOWING FILE SYSTEMS HAD AN UNEXPECTED INCONSISTENCY: MP> > /dev/mirror/m0d (/usr), /dev/mirror/m0e.journal (/var), MP> > /dev/mirror/m0f.journal (/lh), /dev/mirror/m0g.journal (/st) MP> > MP> > Any hints? MP> MP> What does /etc/fstab look like for those file systems? No excessive and/or unusual params: /dev/mirror/m0d /usr ufs rw 2 2 /dev/mirror/m0e.journal /var ufs rw,async,userquota 2 2 /dev/mirror/m0f.journal /lh ufs rw,async,noatime,userquota 2 2 /dev/mirror/m0g.journal /st ufs rw,async,noatime,userquota 2 2 I turned quotas on /usr temporary, as it is small and is not glournalled; the result was the same. Also, I can quotacheck single file systems, only preen mode (-a) seems to be affected. I'm a bit puzzled now. Did anyone test quotas work on -current? Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Tue Sep 4 05:39:00 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2506B16A418 for ; Tue, 4 Sep 2007 05:39:00 +0000 (UTC) (envelope-from crapsh@monkeybrains.net) Received: from ape.monkeybrains.net (ape.monkeybrains.net [208.69.40.11]) by mx1.freebsd.org (Postfix) with ESMTP id EB4A913C47E for ; Tue, 4 Sep 2007 05:38:59 +0000 (UTC) (envelope-from crapsh@monkeybrains.net) Received: from monchichi.monkeybrains.net (adsl-76-193-116-40.dsl.pltn13.sbcglobal.net [76.193.116.40]) (authenticated bits=0) by ape.monkeybrains.net (8.14.1/8.14.1) with ESMTP id l845ICCR058964 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 3 Sep 2007 22:18:12 -0700 (PDT) (envelope-from crapsh@monkeybrains.net) Message-ID: <46DCEA17.2060006@monkeybrains.net> Date: Mon, 03 Sep 2007 22:16:07 -0700 From: Rudy Rucker User-Agent: Thunderbird 2.0.0.6 (X11/20070805) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.91.1, clamav-milter version 0.91.1 on pita.monkeybrains.net X-Virus-Status: Clean Subject: emerald seems to crash... and HOW-TO set up beryl X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2007 05:39:00 -0000 There are several things that seem to crash emerald. I use this 'wrapper' to launch emerald and it works great. Specifically, "System->Preferences->Theme" crashes emerald on my system. Several other things cause it to crash as well. This wrapper will automatically restart emerald for you. ------------------------------------------------------------------------- /usr/local/bin/emerald-wrapper ------------------------------------------------------------------------- #!/bin/sh PIDFILE=/tmp/emerald-wrapper.pid case "$1" in start) echo $$ > $PIDFILE /usr/local/bin/emerald ; sleep 4; logger "Restarting emerald." $0 start & ;; stop) if [ -f $PIDFILE ]; then PID=`cat $PIDFILE` if [ $PID -gt 10 ]; then logger "Killing emerald-wrapper: $PID" kill $PID 2> /dev/null rm $PIDFILE fi fi killall emerald ;; *) echo "" echo "Usage: `basename $0` { start | stop }" echo "" exit 64 ;; esac ------------------------------------------------------------------------- Also, it took me a while to figure out how to set up beryl & emerald on my desktop. Here is my ~/.xinitrc: ------------------------------------------------------------------------- beryl & /usr/local/bin/emerald-wrapper start & sleep 2 gnome-session ------------------------------------------------------------------------- Replace gnome-session with startxfce4 or whatever it is you use :) Also, if emerald doesn't crash for you, then you can replace the /usr/local/bin/emerald-wrapper start & line with simplily emerald & You know emerald has crashed when mid flight, all your windows lose their frames. - RUdy From owner-freebsd-current@FreeBSD.ORG Tue Sep 4 08:06:56 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2932416A421 for ; Tue, 4 Sep 2007 08:06:56 +0000 (UTC) (envelope-from crapsh@monkeybrains.net) Received: from ape.monkeybrains.net (ape.monkeybrains.net [208.69.40.11]) by mx1.freebsd.org (Postfix) with ESMTP id 1184713C45D for ; Tue, 4 Sep 2007 08:06:55 +0000 (UTC) (envelope-from crapsh@monkeybrains.net) Received: from monchichi.monkeybrains.net (adsl-76-193-116-40.dsl.pltn13.sbcglobal.net [76.193.116.40]) (authenticated bits=0) by ape.monkeybrains.net (8.14.1/8.14.1) with ESMTP id l8486tOD095701 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 4 Sep 2007 01:06:55 -0700 (PDT) (envelope-from crapsh@monkeybrains.net) Message-ID: <46DD11A2.9070207@monkeybrains.net> Date: Tue, 04 Sep 2007 01:04:50 -0700 From: Rudy Rucker User-Agent: Thunderbird 2.0.0.6 (X11/20070805) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.91.1, clamav-milter version 0.91.1 on pita.monkeybrains.net X-Virus-Status: Clean Subject: how-to build native JDK15 in FreeBSD 7 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2007 08:06:56 -0000 [HOW-TO] The diablo-jdk15 port didn't work for me. It used the FreeBSD6 build. This method worked for me, so I grabbed the FreeBSD 5 version and installed it. Then, from the port, I built a native jdk15. Downlaod diablo-jdk-freebsd5.i386.1.5.0.07.01.tbz and then run these commands: pkg_add -r compat5x pkg_add diablo-jdk-freebsd5.i386.1.5.0.07.01.tbz then build the native port: cd /usr/ports/java/jdk15 && make install (You will manually have to download some files -- follow the instructions.) (note, your kernel config needs FreeBSD 5 compat built into it... the generic FreeBSD 7 kernel has this.) Rudy From owner-freebsd-current@FreeBSD.ORG Tue Sep 4 08:12:58 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AC32B16A41B for ; Tue, 4 Sep 2007 08:12:58 +0000 (UTC) (envelope-from crapsh@monkeybrains.net) Received: from ape.monkeybrains.net (ape.monkeybrains.net [208.69.40.11]) by mx1.freebsd.org (Postfix) with ESMTP id 9566B13C459 for ; Tue, 4 Sep 2007 08:12:58 +0000 (UTC) (envelope-from crapsh@monkeybrains.net) Received: from monchichi.monkeybrains.net (adsl-76-193-116-40.dsl.pltn13.sbcglobal.net [76.193.116.40]) (authenticated bits=0) by ape.monkeybrains.net (8.14.1/8.14.1) with ESMTP id l848CwI0097011 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 4 Sep 2007 01:12:58 -0700 (PDT) (envelope-from crapsh@monkeybrains.net) Message-ID: <46DD130D.5070604@monkeybrains.net> Date: Tue, 04 Sep 2007 01:10:53 -0700 From: Rudy Rucker User-Agent: Thunderbird 2.0.0.6 (X11/20070805) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.91.1, clamav-milter version 0.91.1 on pita.monkeybrains.net X-Virus-Status: Clean Subject: m4a troubles in FreeBSD 7 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2007 08:12:58 -0000 FreeBSD 7 doesn't seem to play m4a files in Rhythmbox. I can decode m4a files with faad on the command line, but Rhythmbox says it doesn't know how to play m4a files. What plugin am I missing? Also, to get mpd to play m4a files and not log this error: faad2 error: No standard extension payload allowed in DRM I had to edit the /usr/ports/audio/faad/Makefile and comment out this line: #CONFIGURE_ARGS= --with-drm then rebuild faad. Oh, and I had to restart mpd before it would work. /usr/local/etc/rc.d/musicpd forcerestart This 'faad hack' also fixed the xmms-faad plugin error. - Rudy Here are my gstreamer plugins: gstreamer-0.10.14 Development framework for creating media applications gstreamer-ffmpeg-0.10.2_1 GStreamer plug-in for manipulating MPEG video streams gstreamer-plugins-0.10.14,3 GStreamer written collection of plugins handling several me gstreamer-plugins-a52dec-0.10.6_2,3 Gstreamer ATSC A/52 stream aka AC-3 (dvd audio) plugin gstreamer-plugins-aalib-0.10.6_2,3 Gstreamer ascii art plugin gstreamer-plugins-annodex-0.10.6_1,3 Gstreamer annodex CMML plugin gstreamer-plugins-bad-0.10.5_2,3 Bad gstreamer-plugins gstreamer-plugins-bz2-0.10.5_1,3 Gstreamer bz2 plugin gstreamer-plugins-cairo-0.10.6_2,3 Gstreamer vector graphics plugin gstreamer-plugins-cdaudio-0.10.5_1,3 Gstreamer frontend to libcdaudio gstreamer-plugins-cdparanoia-0.10.14_3,3 Gstreamer CDDA extraction (aka audio ripping) plugin gstreamer-plugins-core-0.10_9 Core set of typical audio and video gstreamer-plugins gstreamer-plugins-dts-0.10.5_3,3 Gstreamer dts plugin gstreamer-plugins-dv-0.10.6_2,3 Gstreamer dv plugin gstreamer-plugins-dvd-0.10.6_1,3 Gstreamer dvd plugin set gstreamer-plugins-esound-0.10.6_2,3 Gstreamer enlightenment sound library plugin gstreamer-plugins-faac-0.10.5_2,3 Gstreamer MPEG-2 and MPEG-4 AAC encoder plugin gstreamer-plugins-faad-0.10.5_4,3 Gstreamer MPEG-2 and MPEG-4 AAC decoder plugin gstreamer-plugins-flac-0.10.6_2,3 Gstreamer free lossless audio encoder/decoder plugin gstreamer-plugins-gconf-0.10.6_4,3 Gstreamer gconf plugin gstreamer-plugins-gnomevfs-0.10.14_2,3 Gstreamer gnomevfs plugin gstreamer-plugins-gnonlin-0.10.9 Gstreamer lib for writing non-linear audio and video gstreamer-plugins-good-0.10.6,3 Good gstreamer-plugins gstreamer-plugins-gsm-0.10.5_2,3 Gstreamer gsm encoding/decoding plugin gstreamer-plugins-hal-0.10.6_1,3 Gstreamer hal plugin gstreamer-plugins-ivorbis-0.10.5_3,3 Gstreamer integer only Ogg Vorbis decoder plugin gstreamer-plugins-jack-0.10.5_1,3 Gstreamer low-latency audio server plugin gstreamer-plugins-jpeg-0.10.6_2,3 Gstreamer jpeg encoder/decoder plugin gstreamer-plugins-ladspa-0.10.6_2,3 Gstreamer ladspa (Linux Audio Developer's Simple Plugin API gstreamer-plugins-lame-0.10.6_2,3 Gstreamer mp3 encode plugin gstreamer-plugins-libcaca-0.10.6_3,3 Gstreamer color ascii art plugin gstreamer-plugins-libmms-0.10.5_2,3 Gstreamer mms:// and mmsh:// plugin gstreamer-plugins-libpng-0.10.6_2,3 Gstreamer png plugin gstreamer-plugins-mad-0.10.6_3,3 Gstreamer mp3 decoder plugin gstreamer-plugins-mp3-0.10.0 Gstreamer Plugins Mp3 decoder meta-port gstreamer-plugins-mpeg2dec-0.10.6_2,3 Gstreamer mpeg decode plugin gstreamer-plugins-ogg-0.10.14_2,3 Gstreamer Ogg bitstream plugin gstreamer-plugins-pango-0.10.14_2,3 Gstreamer pango textoverlay plugin gstreamer-plugins-theora-0.10.14_3,3 Gstreamer theora plugin gstreamer-plugins-ugly-0.10.6,3 Ugly gstreamer-plugins gstreamer-plugins-vorbis-0.10.14_3,3 Gstreamer vorbis encoder/decoder plugin gstreamer-plugins-xvid-0.10.5_1,3 Gstreamer xvid plugin From owner-freebsd-current@FreeBSD.ORG Tue Sep 4 08:22:31 2007 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DE6E016A417 for ; Tue, 4 Sep 2007 08:22:31 +0000 (UTC) (envelope-from pav@FreeBSD.org) Received: from nat-application.b1.lan.prg.vol.cz (nat-application.b1.lan.prg.vol.cz [195.122.204.152]) by mx1.freebsd.org (Postfix) with ESMTP id 51CB713C457 for ; Tue, 4 Sep 2007 08:22:31 +0000 (UTC) (envelope-from pav@FreeBSD.org) Received: from pav.hide.vol.cz (localhost [127.0.0.1]) by nat-application.b1.lan.prg.vol.cz (8.14.1/8.14.1) with ESMTP id l847u1Sd029257 for ; Tue, 4 Sep 2007 09:56:01 +0200 (CEST) (envelope-from pav@FreeBSD.org) Received: (from pav@localhost) by pav.hide.vol.cz (8.14.1/8.14.1/Submit) id l847u1EV029256 for current@FreeBSD.org; Tue, 4 Sep 2007 09:56:01 +0200 (CEST) (envelope-from pav@FreeBSD.org) X-Authentication-Warning: pav.hide.vol.cz: pav set sender to pav@FreeBSD.org using -f From: Pav Lucistnik To: current@FreeBSD.org Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-qCgz/79WcIGAbGbPk3UD" Date: Tue, 04 Sep 2007 09:56:00 +0200 Message-Id: <1188892560.28297.27.camel@pav.hide.vol.cz> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 FreeBSD GNOME Team Port Cc: Subject: [Fwd: gkrellmwireless-2.0.2_7 failed on amd64 7] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pav@FreeBSD.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2007 08:22:32 -0000 --=-qCgz/79WcIGAbGbPk3UD Content-Type: text/plain; charset=ISO8859-2 Content-Transfer-Encoding: quoted-printable Hey list, a bunch of ports broke on recent CURRENT, similar to the log below. Who's responsible for this change - who should I nag to fix the ports? -------- P=F8eposlan=E1 zpr=E1va -------- > Od: User Ports-amd64 > Komu: kris@freebsd.org, pav@freebsd.org > P=F8edm=ECt: gkrellmwireless-2.0.2_7 failed on amd64 7 > Datum: Tue, 4 Sep 2007 00:02:52 GMT >=20 > building gkrellmwireless-2.0.2_7 on hammer1.isc.gumbysoft.com > in directory /usr2/pkgbuild/7/chroot/2693 > building for: 7.0-CURRENT amd64 > maintained by: ktsin@acm.org > port directory: /usr/ports/net/gkrellmwireless2 > build started at Tue Sep 4 00:01:21 UTC 2007 [..] > =3D=3D=3D> Building for gkrellmwireless-2.0.2_7 > cc -O2 -Wall -fPIC `pkg-config gtk+-2.0 --cflags` -c -o wireless.o wi= reless.c > wireless.c: In function 'get_wi_link_quality': > wireless.c:247: error: storage size of 'wreq' isn't known > wireless.c:247: warning: unused variable 'wreq' > gmake: *** [wireless.o] Error 1 > *** Error code 2 >=20 > Stop in /a/ports/net/gkrellmwireless2. > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > build of /usr/ports/net/gkrellmwireless2 ended at Tue Sep 4 00:02:53 UTC= 2007 --=20 Pav Lucistnik With sufficient thrust, pigs fly just fine. -- RFC 1925 --=-qCgz/79WcIGAbGbPk3UD Content-Type: application/pgp-signature; name=signature.asc Content-Description: Toto je =?UTF-8?Q?digit=C3=A1ln=C4=9B?= =?ISO-8859-1?Q?_podepsan=E1?= =?UTF-8?Q?_=C4=8D=C3=A1st?= =?ISO-8859-1?Q?_zpr=E1vy?= -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQBG3Q+QntdYP8FOsoIRAmwoAJ9K3myyrIohvOOsnw82VZYSi6FbZwCfTL9J oik7ylRoPCUbufhLeM4Zar8= =FlIo -----END PGP SIGNATURE----- --=-qCgz/79WcIGAbGbPk3UD-- From owner-freebsd-current@FreeBSD.ORG Tue Sep 4 10:07:47 2007 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 26F4716A419 for ; Tue, 4 Sep 2007 10:07:47 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 0372113C465 for ; Tue, 4 Sep 2007 10:07:46 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 962EF47626; Tue, 4 Sep 2007 06:07:46 -0400 (EDT) Date: Tue, 4 Sep 2007 11:07:46 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Xin LI In-Reply-To: <46DB5F1C.4020807@delphij.net> Message-ID: <20070904110720.F68312@fledge.watson.org> References: <20070902181119.E21906@fledge.watson.org> <46DAF092.1030708@delphij.net> <46DB5F1C.4020807@delphij.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: current@FreeBSD.org Subject: Re: more(1) has gotten more demanding? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2007 10:07:47 -0000 On Mon, 3 Sep 2007, Xin LI wrote: > Sorry, the patch. This sounds great, thanks. I'm afraid I'm rather from the old world order -- I'd like more to be a little less less, and a little more more. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Tue Sep 4 11:25:08 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B420016A419 for ; Tue, 4 Sep 2007 11:25:08 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 6947313C478 for ; Tue, 4 Sep 2007 11:25:08 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from root by ciao.gmane.org with local (Exim 4.43) id 1ISWWk-0005Gh-Pq for freebsd-current@freebsd.org; Tue, 04 Sep 2007 13:25:02 +0200 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 04 Sep 2007 13:25:02 +0200 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 04 Sep 2007 13:25:02 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Date: Tue, 04 Sep 2007 12:31:57 +0200 Lines: 41 Message-ID: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-ripemd160; protocol="application/pgp-signature"; boundary="------------enigA89CA92D0D512C901D3D7911" X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 1.5.0.12 (X11/20060911) X-Enigmail-Version: 0.94.4.0 Sender: news Cc: freebsd-hackers@freebsd.org Subject: Progress for 7.0 - the "what's cooking" page X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2007 11:25:08 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA89CA92D0D512C901D3D7911 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Hi, As some of you may know, I'm maintaining a web page which aims to=20 enumerate and describe major new features for FreeBSD 7, located at=20 http://ivoras.sharanet.org/freebsd/freebsd7.html . Since 7.0 should be released "soon", I'd like to update the page with=20 the current status of the projects. In particular, I'd like to mark=20 projects that won't be ready for 7.0. To do so, I need input from the=20 projects' authors and maintainers. So if you are listed on the page and=20 your project status is updated and no longer matches what's written on=20 the page, please respond to this thread. Also, if a feature won't be=20 ready for 7.0 but will be sometime during 7.x, please state so. Of course, additions, corrections, etc. are also welcome. Thanks :) --------------enigA89CA92D0D512C901D3D7911 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFG3TQdldnAQVacBcgRAxyXAKCKpIfn02G625JSdnc34jwT9OnmegCfbpK3 NYW+g5EXfHpY/detwGg+AsQ= =OXtA -----END PGP SIGNATURE----- --------------enigA89CA92D0D512C901D3D7911-- From owner-freebsd-current@FreeBSD.ORG Tue Sep 4 11:32:22 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 14EC516A419 for ; Tue, 4 Sep 2007 11:32:22 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id A09C313C4CB for ; Tue, 4 Sep 2007 11:32:21 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.61.5]) by phk.freebsd.dk (Postfix) with ESMTP id 38CF017105; Tue, 4 Sep 2007 11:32:20 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.1/8.14.1) with ESMTP id l84BWJ90003607; Tue, 4 Sep 2007 11:32:20 GMT (envelope-from phk@critter.freebsd.dk) To: Ivan Voras From: "Poul-Henning Kamp" In-Reply-To: Your message of "Tue, 04 Sep 2007 12:31:57 +0200." Date: Tue, 04 Sep 2007 11:32:19 +0000 Message-ID: <3606.1188905539@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: Progress for 7.0 - the "what's cooking" page X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2007 11:32:22 -0000 In message , Ivan Voras writes: >As some of you may know, I'm maintaining a web page which aims to=20 >enumerate and describe major new features for FreeBSD 7, located at=20 >http://ivoras.sharanet.org/freebsd/freebsd7.html . Feel free to add: ACPI suspend/resume does not work on SMP systems, including multi-core laptops. :-/ -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Tue Sep 4 11:52:53 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E2AFF16A41B for ; Tue, 4 Sep 2007 11:52:53 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.183]) by mx1.freebsd.org (Postfix) with ESMTP id 6847913C49D for ; Tue, 4 Sep 2007 11:52:53 +0000 (UTC) (envelope-from max@love2party.net) Received: from dslb-088-066-008-045.pools.arcor-ip.net [88.66.8.45] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu3) with ESMTP (Nemesis), id 0MKxQS-1ISWxe3fQA-0008KZ; Tue, 04 Sep 2007 13:52:52 +0200 From: Max Laier Organization: FreeBSD To: Ivan Voras Date: Tue, 4 Sep 2007 13:52:36 +0200 User-Agent: KMail/1.9.7 References: In-Reply-To: X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1370531.6dAgFudZzx"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200709041352.41546.max@love2party.net> X-Provags-ID: V01U2FsdGVkX18gwry2mZbQ4HwrQ+zgFaV0aIud2J0vorKctWR Kc0PDqqQqO6WsBx1QGfPwA/K3WUNMHxyxB+RRF+sthu5atfHmF 6AVapGfcxllIjQ+i/s9vLv1r989c3frJe/gIhFXJUQ= Cc: freebsd-current@freebsd.org Subject: Re: Progress for 7.0 - the "what's cooking" page X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2007 11:52:54 -0000 --nextPart1370531.6dAgFudZzx Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Tuesday 04 September 2007, Ivan Voras wrote: > Hi, > > As some of you may know, I'm maintaining a web page which aims to > enumerate and describe major new features for FreeBSD 7, located at > http://ivoras.sharanet.org/freebsd/freebsd7.html . > > Since 7.0 should be released "soon", I'd like to update the page with > the current status of the projects. In particular, I'd like to mark > projects that won't be ready for 7.0. To do so, I need input from the > projects' authors and maintainers. So if you are listed on the page and > your project status is updated and no longer matches what's written on > the page, please respond to this thread. Also, if a feature won't be > ready for 7.0 but will be sometime during 7.x, please state so. > > Of course, additions, corrections, etc. are also welcome. You might want to add the pf update to 4.1 as a new feature. See=20 http://www.nabble.com/List-of-pf-changes-p11413803.html for some details=20 on the new features included. =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 --nextPart1370531.6dAgFudZzx Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQBG3UcJXyyEoT62BG0RAu2CAJ92y1t72k14GIZv3MbF1SKvRsozEQCfUvPl 2qJa5KI/Lnj40dlPz9Z4Hak= =8rUq -----END PGP SIGNATURE----- --nextPart1370531.6dAgFudZzx-- From owner-freebsd-current@FreeBSD.ORG Tue Sep 4 11:54:01 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7993A16A417 for ; Tue, 4 Sep 2007 11:54:01 +0000 (UTC) (envelope-from varga@stonehenge.sk) Received: from otana.stonehenge.sk (otana.stonehenge.sk [82.208.39.177]) by mx1.freebsd.org (Postfix) with SMTP id BCCE913C467 for ; Tue, 4 Sep 2007 11:54:00 +0000 (UTC) (envelope-from varga@stonehenge.sk) Received: (qmail 50178 invoked from network); 4 Sep 2007 11:53:51 -0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on otana.stonehenge.sk X-Spam-Level: X-Spam-Status: No, score=0.5 required=5.0 tests=RCVD_IN_PBL shortcircuit=no autolearn=disabled version=3.2.3 Received: from r6cb57.net.upc.cz (HELO ?10.0.100.2?) (secure@89.176.79.57) by otana.stonehenge.sk with SMTP; 4 Sep 2007 11:53:51 -0000 From: Michal Varga To: Mario Ferreira In-Reply-To: <20070903003925.GA8166@cdnetworks.co.kr> References: <683701cf0708310509l40c14a78te54e6608c2f7d9ed@mail.gmail.com> <683701cf0708311058l5e80198fr432abb06d8128924@mail.gmail.com> <20070903003925.GA8166@cdnetworks.co.kr> Content-Type: text/plain Organization: Stonehenge Date: Tue, 04 Sep 2007 13:53:51 +0200 Message-Id: <1188906831.54484.40.camel@xenon.stonehenge.sk> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: pyunyh@gmail.com, freebsd-current@freebsd.org Subject: Re: nfe(4) not working on asus m2n32sli-deluxe X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2007 11:54:01 -0000 On Mon, 2007-09-03 at 09:39 +0900, Pyun YongHyeon wrote: > On Fri, Aug 31, 2007 at 02:58:54PM -0300, Mario Ferreira wrote: > > Hi, > > > > I tried installing FreeBSD 7.0-Current 200708 i386 snapshot on a > > asus m2n32sli-deluxe wifi edition but I had some issues: > > > > 1) on board wlan adapter RTL8187_Wireless not supported > > 2) on board lan adapter NForce 590 SLI MCP does not work > > > > The lack of support for RTL8187_Wireless is not a problem for now. > > However, the NForce 590 SLI MCP Gigabit adapter is an issue. > > > > The nfe(4) driver detects the network carrier but it never ever > > detects the media settings. I tried hand setting media/mediaopt but it > > did not help. > > > > media: Ethernet autoselect (none) > > status: active > > > > Any suggestions? Let me know if there is anything I can do to help. > > Sorry for indirect quotation, I didn't catch the original mail and don't want to break the thread now. Anyway, to Mario's problem with nfe: What I see in your log looks very similiar to what I experienced with my wife's m2n32-sli-deluxe, this most craptacular piece of hardware I've seen in years (and the nfe is probably the best working part there). There is a (I think widely known, at least I've seen it discussed a few times somewhere) problem with nfe initialization under FreeBSD when you reboot from Windows, as far as I remember the symptoms are exactly the same as yours. So, if by any chance you were running Windows somewhere around the same time as FreeBSD, here is your solution: Give it another try, but start the computer right into FreeBSD from the first power-on. Not even cold reboot fixes this, so power down your PSU (feel free to tear the power cord off the wall if you're desperate), wait for a few minutes *without power*, then start your PSU, boot into FreeBSD, tada, nfe will miraculously work as it should. Pure magic. m. -- Michal Varga Stonehenge From owner-freebsd-current@FreeBSD.ORG Tue Sep 4 12:26:54 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EC4FB16A421 for ; Tue, 4 Sep 2007 12:26:54 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 983D813C4A7 for ; Tue, 4 Sep 2007 12:26:54 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1ISXRd-0007TO-Qj for freebsd-current@freebsd.org; Tue, 04 Sep 2007 14:23:49 +0200 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 04 Sep 2007 14:23:49 +0200 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 04 Sep 2007 14:23:49 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Date: Tue, 04 Sep 2007 14:16:08 +0200 Lines: 35 Message-ID: References: <3606.1188905539@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-ripemd160; protocol="application/pgp-signature"; boundary="------------enigB085F04D575E7A18979D0FC3" X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 1.5.0.12 (X11/20060911) In-Reply-To: <3606.1188905539@critter.freebsd.dk> X-Enigmail-Version: 0.94.4.0 Sender: news Cc: freebsd-hackers@freebsd.org Subject: Re: Progress for 7.0 - the "what's cooking" page X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2007 12:26:55 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB085F04D575E7A18979D0FC3 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Poul-Henning Kamp wrote: > Feel free to add: >=20 > ACPI suspend/resume does not work on SMP systems, including > multi-core laptops. Since it hasn't worked for me on any system I tried it on, ever, I'm not = particularly surprised :) But it's more an item for the Errata page and=20 BSD-bashing blogs than the "what's cooking" page. --------------enigB085F04D575E7A18979D0FC3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFG3UyOldnAQVacBcgRA1v6AKD5MDiaUHOfjLHt1j58Ht8tskVFHQCdENeH Jlc+sMGaKvNZcTE80MdQHmU= =clcy -----END PGP SIGNATURE----- --------------enigB085F04D575E7A18979D0FC3-- From owner-freebsd-current@FreeBSD.ORG Tue Sep 4 13:22:09 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D380816A46E for ; Tue, 4 Sep 2007 13:22:09 +0000 (UTC) (envelope-from ianf@clue.co.za) Received: from munchkin.clue.co.za (munchkin.clue.co.za [66.219.59.160]) by mx1.freebsd.org (Postfix) with ESMTP id 9020113C500 for ; Tue, 4 Sep 2007 13:22:09 +0000 (UTC) (envelope-from ianf@clue.co.za) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=20070313; d=clue.co.za; h=Received:Received:Received:cc:From:Subject:In-Reply-To:X-Attribution:Date:Message-Id; b=L0jo3/9cr/KY/1xmCZ9E+D1AhxHAaTklyk0WyLTtbRxWVZSSCGhppgbV6o3rLnLFahGkxpVFJrUTNokWRXnC33BdI8gGeyYdpQ4/DPngTfPTIrKSH1zK19Oq3H/gix2fuqpD2sXTHNi/xP80w1nYRbeaESaceaeitM/eU1oxCPScreQCt0FCFrN7hU2RA9Pea7DvTw2m1411MWgINlbXTx14YAqiABovYvIfyk9NJYL8AH3ES2atQDxOELaycPgS; Received: from uucp by munchkin.clue.co.za with local-rmail (Exim 4.66) (envelope-from ) id 1ISYM4-0003Yt-7D; Tue, 04 Sep 2007 13:22:08 +0000 Received: from ianf.clue.co.za ([10.0.0.6] helo=clue.co.za) by urchin.clue.co.za with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.66) (envelope-from ) id 1ISYL2-0002Ge-RD; Tue, 04 Sep 2007 13:21:05 +0000 Received: from localhost ([127.0.0.1] helo=clue.co.za) by clue.co.za with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ISYL0-000158-7n; Tue, 04 Sep 2007 15:21:02 +0200 From: Ian FREISLICH In-Reply-To: Message from Ian FREISLICH of "Tue, 03 Jul 2007 15:06:41 +0200." X-Attribution: BOFH Date: Tue, 04 Sep 2007 15:21:02 +0200 Message-Id: Cc: bu7cher@yandex.ru, rwatson@freebsd.org, freebsd-current@freebsd.org Subject: Re: Panic in ipfw X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2007 13:22:09 -0000 Ian FREISLICH wrote: > "Andrey V. Elsukov" wrote: > > Hi, Ian. > > > > > I got this panic yesterday on a fairly busy firewall. I have some > > > private patches to ip_fw2.c and to the em driver (see the earlier > > > "em0 hijacking traffic to port 623" thread). I don't think this > > > panic is a result of those changes. > > > > > It occurred round about the time an address was added to an interface. > > > > I have a patch that can help you (i guess..). > > Can you test this patch? > > > > http://butcher.heavennet.ru/patches/kernel/inaddr_locking/ > > Thanks. Wow, that looks like it touches a lot more than just ipfw. > It took about 1.5 years of production at 2.3 billion backets a day > to trigger this condition twice. It's going to be difficult to > tell if this patch fixes the problem. Well, I've just had another related panic (I think): Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 06 fault virtual address = 0xbd fault code = supervisor read, page not present instruction pointer = 0x20:0xc059be50 stack pointer = 0x28:0xe95ecaf0 frame pointer = 0x28:0xe95ecaf0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 36 (idlepoll) trap number = 12 panic: page fault cpuid = 1 KDB: stack backtrace: db_trace_self_wrapper(c0691f59,e95ec994,c04fe600,c06a6a38,1,...) at db_trace_sel f_wrapper+0x26 kdb_backtrace(c06a6a38,1,c0684a3b,e95ec9a0,1,...) at kdb_backtrace+0x29 panic(c0684a3b,c06a7d15,c4e5cc8c,1,1,...) at panic+0x10f trap_fatal(c06f28c0,0,1,0,c4ddd800,...) at trap_fatal+0x327 trap_pfault(c05895ae,c4ddd800,0,e95eca70,c4e5cab0,...) at trap_pfault+0x244 trap(e95ecab0) at trap+0x363 calltrap() at calltrap+0x6 --- trap 0xc, eip = 0xc059be50, esp = 0xe95ecaf0, ebp = 0xe95ecaf0 --- in_localip(b3c9cc29,caf3d600,e95ecb30,c57dc960,0,...) at in_localip+0x50 ip_fastforward(c5588100,e,257,c0665207,c503d800,...) at ip_fastforward+0x2b9 ether_demux(c503d800,c5588100,3,4,2,...) at ether_demux+0x165 ether_input(c503d800,c5588100,0,c5578000,800,...) at ether_input+0x3e4 vlan_input(c4dcac00,c5588100,47,e95ecc30,c046a3fd,...) at vlan_input+0x16d ether_demux(c4dcac00,c5588100,6,47,c52f3354,...) at ether_demux+0x102 ether_input(c4dcac00,c5588100,e95ecc54,c0519523,c06f6420,...) at ether_input+0x3 e4 em_rxeof(e95e0008,c04f0028,c4e5cab0,c4e5cab0,429f1f94,...) at em_rxeof+0x45e em_poll(c4dcac00,0,32,c4e5da00,e95eccd0,...) at em_poll+0x141 ether_poll(32,0,c068f8f0,24f,bb8,...) at ether_poll+0xd1 poll_idle(0,e95ecd38,0,0,0,...) at poll_idle+0xdb fork_exit(c04f3fb3,0,e95ecd38) at fork_exit+0x2a fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe95ecd70, ebp = 0 --- Uptime: 12d22h28m28s Physical memory: 2039 MB Dumping 235 MB: 220 204 188 172 156 140 124 108 92 76 60 44 28 12 #0 doadump () at pcpu.h:195 195 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:195 #1 0xc04fe342 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 #2 0xc04fe62f in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:563 #3 0xc065b3b2 in trap_fatal (frame=0xe95ecab0, eva=189) at /usr/src/sys/i386/i386/trap.c:873 #4 0xc065b602 in trap_pfault (frame=0xe95ecab0, usermode=0, eva=189) at /usr/src/sys/i386/i386/trap.c:784 #5 0xc065bf1f in trap (frame=0xe95ecab0) at /usr/src/sys/i386/i386/trap.c:462 #6 0xc0642c8b in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #7 0xc059be50 in in_localip (in={s_addr = 3016346665}) at /usr/src/sys/netinet/in.c:125 #8 0xc05a96f7 in ip_fastforward (m=0xc5588100) at /usr/src/sys/netinet/ip_fastfwd.c:330 #9 0xc058ff3e in ether_demux (ifp=0xc503d800, m=0xc5588100) at /usr/src/sys/net/if_ethersubr.c:779 #10 0xc059041e in ether_input (ifp=0xc503d800, m=0xc5588100) at /usr/src/sys/net/if_ethersubr.c:701 #11 0xc0591fb1 in vlan_input (ifp=0xc4dcac00, m=0xc5588100) at /usr/src/sys/net/if_vlan.c:973 #12 0xc058fedb in ether_demux (ifp=0xc4dcac00, m=0xc5588100) at /usr/src/sys/net/if_ethersubr.c:752 #13 0xc059041e in ether_input (ifp=0xc4dcac00, m=0xc5588100) at /usr/src/sys/net/if_ethersubr.c:701 ---Type to continue, or q to quit--- #14 0xc046ba35 in em_rxeof (adapter=0xc4d79000, count=46) at /usr/src/sys/dev/em/if_em.c:4301 #15 0xc046d5ef in em_poll (ifp=0xc4dcac00, cmd=POLL_ONLY, count=50) at /usr/src/sys/dev/em/if_em.c:1375 #16 0xc04f30a1 in ether_poll (count=50) at /usr/src/sys/kern/kern_poll.c:339 #17 0xc04f408e in poll_idle () at /usr/src/sys/kern/kern_poll.c:590 #18 0xc04de792 in fork_exit (callout=0xc04f3fb3 , arg=0x0, frame=0xe95ecd38) at /usr/src/sys/kern/kern_fork.c:787 #19 0xc0642d00 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:205 (kgdb) frame 7 #7 0xc059be50 in in_localip (in={s_addr = 3016346665}) at /usr/src/sys/netinet/in.c:125 125 if (IA_SIN(ia)->sin_addr.s_addr == in.s_addr) (kgdb) l 120 in_localip(struct in_addr in) 121 { 122 struct in_ifaddr *ia; 123 124 LIST_FOREACH(ia, INADDR_HASH(in.s_addr), ia_hash) { 125 if (IA_SIN(ia)->sin_addr.s_addr == in.s_addr) 126 return 1; 127 } 128 return 0; 129 } (kgdb) print ia $1 = (struct in_ifaddr *) 0x1 This code is touched by Andrey's patch. I'm going to put that patch into production tomorrow - this locking issue is raising it's head too often now. Interestingly, in my testing this patch *improves* firewall performance in an SMP environment by ~30Kpps (10%). I can't think why that should be. The test ruleset was: 00005 10203042 295891608 tee 666 ip from any to any via bge0 00010 20406493 591856418 allow ip from not me to not me 65535 193 24418 allow ip from any to any I got 307Kpps before the patch was applied and 343Kpps with the patch. Ian -- Ian Freislich From owner-freebsd-current@FreeBSD.ORG Tue Sep 4 13:33:55 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 36E2416A418 for ; Tue, 4 Sep 2007 13:33:55 +0000 (UTC) (envelope-from kvs@binarysolutions.dk) Received: from solow.pil.dk (relay.pil.dk [195.41.47.164]) by mx1.freebsd.org (Postfix) with ESMTP id 015B313C457 for ; Tue, 4 Sep 2007 13:33:54 +0000 (UTC) (envelope-from kvs@binarysolutions.dk) Received: from coruscant.pil.dk (fw2.pil.dk [83.90.227.58]) by solow.pil.dk (Postfix) with ESMTP id 412291CC0B8 for ; Tue, 4 Sep 2007 15:08:20 +0200 (CEST) Received: by coruscant.pil.dk (Postfix, from userid 502) id 8DF575FF4AF; Tue, 4 Sep 2007 15:08:20 +0200 (CEST) To: freebsd-current@freebsd.org From: Kenneth Vestergaard Schmidt Date: Tue, 04 Sep 2007 15:08:20 +0200 Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (darwin) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Tue, 04 Sep 2007 13:36:21 +0000 Subject: Unkillable and runaway processes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2007 13:33:55 -0000 Hello. Our ZFS testbed is experiencing some weird problems with rsync. We run a nightly backup of about 1.6 TB data (that's how much is stored, not how much is transferred), but after the initial sync I haven't been able to get the machine through one full cycle. After many hours of rsyncing data from 50+ machines, suddenly one rsync-process will hang, spinning on the CPU. It switches state between CPU0, CPU1, RUN and 'zfs:(&', but doesn't really do anything. It can't be killed, and you can't reboot the machine - it'll get past syncing disks, but won't shutdown or reboot. I can't do an 'ls' in the directory that rsync is running on - it'll just hang, too. The machine is running current from August 29th. I could use some pointers on what to do - is there some way I can debug this better, maybe give some better info? -- Kenneth Schmidt pil.dk From owner-freebsd-current@FreeBSD.ORG Tue Sep 4 13:41:05 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B126216A417 for ; Tue, 4 Sep 2007 13:41:05 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 7FF3013C48D for ; Tue, 4 Sep 2007 13:41:04 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1ISYcy-000779-8s for freebsd-current@freebsd.org; Tue, 04 Sep 2007 15:39:36 +0200 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 04 Sep 2007 15:39:36 +0200 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 04 Sep 2007 15:39:36 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Date: Tue, 04 Sep 2007 15:33:50 +0200 Lines: 30 Message-ID: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-ripemd160; protocol="application/pgp-signature"; boundary="------------enig479ED4F723C4457A22BF92B9" X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 1.5.0.12 (X11/20060911) X-Enigmail-Version: 0.94.4.0 Sender: news Cc: freebsd-hackers@freebsd.org Subject: VirtualBox? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2007 13:41:05 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig479ED4F723C4457A22BF92B9 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Hi, Is anyone working on porting VirtualBox? http://www.virtualbox.org/wiki/Porting_VirtualBox It mentions FreeBSD but nothing conclusive. It should be easier than=20 VMWare :) --------------enig479ED4F723C4457A22BF92B9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFG3V6+ldnAQVacBcgRA8zcAKDZyMH5/MVM+NzhkWYJnPov4IVIywCfalFB Lq/ywXhunKGv0UNOoMsgH14= =lWKT -----END PGP SIGNATURE----- --------------enig479ED4F723C4457A22BF92B9-- From owner-freebsd-current@FreeBSD.ORG Tue Sep 4 13:47:25 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8760116A417 for ; Tue, 4 Sep 2007 13:47:25 +0000 (UTC) (envelope-from minimarmot@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.170]) by mx1.freebsd.org (Postfix) with ESMTP id 17B3813C45D for ; Tue, 4 Sep 2007 13:47:24 +0000 (UTC) (envelope-from minimarmot@gmail.com) Received: by ug-out-1314.google.com with SMTP id a2so437491ugf for ; Tue, 04 Sep 2007 06:47:23 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=iskyy0MzbUvr55bGzucyO/ud+9cA+Uly6IJ3EcSnDxJKKBH8MGrYThOnX7DAtJbRXv9rdSMTEIDbGdkK1cRn+KLT7IPyo0prVTS0+qt5foX9VAcESHTPYfkcyh42RYsKCAGjfzN9mXtWMRIP9eNTqb9KkPPMI8ESkHUh5TCrI0Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Lr2OHIsP9Jr2EG5IpcM1WHezMoWpRSAGhXKEcyiiOUDoOEGbAI0QyLB77Fv+liK0RjFKkhOahFSSlD8p4YKXtHAK4dgveHOkIfkiO1AphAN36QJp4CylRX7bhlp3pKzLQ7eyc93BtHoBbQVSpXVNraV13RbRqVkOLW+QUun5M7g= Received: by 10.142.89.9 with SMTP id m9mr284560wfb.1188912019877; Tue, 04 Sep 2007 06:20:19 -0700 (PDT) Received: by 10.143.1.8 with HTTP; Tue, 4 Sep 2007 06:20:19 -0700 (PDT) Message-ID: <47d0403c0709040620u30ac2951x4b5f38fcfeb81f6e@mail.gmail.com> Date: Tue, 4 Sep 2007 09:20:19 -0400 From: "Ben Kaduk" To: "Ivan Voras" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: Progress for 7.0 - the "what's cooking" page X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2007 13:47:25 -0000 On 9/4/07, Ivan Voras wrote: > Hi, > > As some of you may know, I'm maintaining a web page which aims to > enumerate and describe major new features for FreeBSD 7, located at > http://ivoras.sharanet.org/freebsd/freebsd7.html . > > Since 7.0 should be released "soon", I'd like to update the page with > the current status of the projects. In particular, I'd like to mark > projects that won't be ready for 7.0. To do so, I need input from the > projects' authors and maintainers. So if you are listed on the page and > your project status is updated and no longer matches what's written on > the page, please respond to this thread. Also, if a feature won't be > ready for 7.0 but will be sometime during 7.x, please state so. > > Of course, additions, corrections, etc. are also welcome. > Would it be worth mentioning more prominently that NET_NEEDS_GIANT has been axed? It may be included in ``pushing GIANT farther back'', but it seems deserving of an explicit mention, to me. (Thanks to everyone who put the work in to get that done!) -Ben Kaduk From owner-freebsd-current@FreeBSD.ORG Tue Sep 4 13:49:06 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3D66A16A468 for ; Tue, 4 Sep 2007 13:49:06 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id E182C13C4B4 for ; Tue, 4 Sep 2007 13:49:05 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1ISYlO-0000nR-Rd for freebsd-current@freebsd.org; Tue, 04 Sep 2007 15:48:18 +0200 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 04 Sep 2007 15:48:18 +0200 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 04 Sep 2007 15:48:18 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Date: Tue, 04 Sep 2007 15:46:49 +0200 Lines: 40 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-ripemd160; protocol="application/pgp-signature"; boundary="------------enigD9B16D6AEB9E26B96D81950A" X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 1.5.0.12 (X11/20060911) In-Reply-To: X-Enigmail-Version: 0.94.4.0 Sender: news Subject: Re: Unkillable and runaway processes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2007 13:49:06 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD9B16D6AEB9E26B96D81950A Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Kenneth Vestergaard Schmidt wrote: > Our ZFS testbed is experiencing some weird problems with rsync. We run = a > nightly backup of about 1.6 TB data (that's how much is stored, not how= > much is transferred), but after the initial sync I haven't been able to= > get the machine through one full cycle. >=20 > After many hours of rsyncing data from 50+ machines, suddenly one > rsync-process will hang, spinning on the CPU. I have a similar, but possibly unrelated problem: almost the same as=20 yours (ZFS & rsync backups), except there's a kernel panic in=20 zfs_reclaim instead of a hang. This is on an old P3/1GHz machine,=20 running without debugging options. --------------enigD9B16D6AEB9E26B96D81950A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFG3WHJldnAQVacBcgRA5QOAKCCZCvdNYry54kpPNjxeozBVehzWgCfaQJ2 yDMpbebiiDG/GICCHJ3/sO4= =hbVt -----END PGP SIGNATURE----- --------------enigD9B16D6AEB9E26B96D81950A-- From owner-freebsd-current@FreeBSD.ORG Tue Sep 4 14:00:30 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B833316A418 for ; Tue, 4 Sep 2007 14:00:30 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 62FB913C461 for ; Tue, 4 Sep 2007 14:00:30 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from root by ciao.gmane.org with local (Exim 4.43) id 1ISYwk-00035I-9f for freebsd-current@freebsd.org; Tue, 04 Sep 2007 16:00:02 +0200 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 04 Sep 2007 16:00:02 +0200 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 04 Sep 2007 16:00:02 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Date: Tue, 04 Sep 2007 15:52:11 +0200 Lines: 29 Message-ID: References: <47d0403c0709040620u30ac2951x4b5f38fcfeb81f6e@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-ripemd160; protocol="application/pgp-signature"; boundary="------------enig9A29B4DE4A37DB09DC2F3C99" X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 1.5.0.12 (X11/20060911) In-Reply-To: <47d0403c0709040620u30ac2951x4b5f38fcfeb81f6e@mail.gmail.com> X-Enigmail-Version: 0.94.4.0 Sender: news Cc: freebsd-hackers@freebsd.org Subject: Re: Progress for 7.0 - the "what's cooking" page X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2007 14:00:30 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig9A29B4DE4A37DB09DC2F3C99 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Ben Kaduk wrote: > Would it be worth mentioning more prominently that NET_NEEDS_GIANT > has been axed? It may be included in ``pushing GIANT farther back'', > but it seems deserving of an explicit mention, to me. Ok, here's something like it. --------------enig9A29B4DE4A37DB09DC2F3C99 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFG3WMLldnAQVacBcgRA2OsAKDAjK8kHqXjW2zsl/bjUjUYvyfeogCfa3CJ VQamnKCaiWImyIzUVtb6OLo= =E1OC -----END PGP SIGNATURE----- --------------enig9A29B4DE4A37DB09DC2F3C99-- From owner-freebsd-current@FreeBSD.ORG Tue Sep 4 15:26:12 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3D60A16A419 for ; Tue, 4 Sep 2007 15:26:12 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.freebsd.org (Postfix) with ESMTP id 029F813C480 for ; Tue, 4 Sep 2007 15:26:11 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.14.1/8.14.1) id l84EmHxl020697; Tue, 4 Sep 2007 09:48:17 -0500 (CDT) (envelope-from dan) Date: Tue, 4 Sep 2007 09:48:16 -0500 From: Dan Nelson To: Kenneth Vestergaard Schmidt Message-ID: <20070904144815.GB3547@dan.emsphone.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-OS: FreeBSD 7.0-CURRENT User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-current@freebsd.org Subject: Re: Unkillable and runaway processes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2007 15:26:12 -0000 In the last episode (Sep 04), Kenneth Vestergaard Schmidt said: > Our ZFS testbed is experiencing some weird problems with rsync. We > run a nightly backup of about 1.6 TB data (that's how much is stored, > not how much is transferred), but after the initial sync I haven't > been able to get the machine through one full cycle. > > After many hours of rsyncing data from 50+ machines, suddenly one > rsync-process will hang, spinning on the CPU. > > It switches state between CPU0, CPU1, RUN and 'zfs:(&', but doesn't > really do anything. It can't be killed, and you can't reboot the > machine - it'll get past syncing disks, but won't shutdown or reboot. The zfs wchan strings are way too long for ps or top to print, but if the rsync is running from a tty somewhere, hit ^T and you'll get the full wait string. -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-current@FreeBSD.ORG Tue Sep 4 15:51:33 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 52FBB16A41B for ; Tue, 4 Sep 2007 15:51:33 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from cs1.cs.huji.ac.il (cs1.cs.huji.ac.il [132.65.16.10]) by mx1.freebsd.org (Postfix) with ESMTP id 0DE7C13C46C for ; Tue, 4 Sep 2007 15:51:33 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by cs1.cs.huji.ac.il with esmtp id 1ISagd-000EcK-ME for freebsd-current@freebsd.org; Tue, 04 Sep 2007 18:51:31 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 04 Sep 2007 18:51:31 +0300 From: Danny Braniss Message-ID: Subject: dump problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2007 15:51:33 -0000 dump start out nicely, but then it justs hangs. have tried it with different file systems, the output is also a file, again tried it with different file system. the only way it works is if the output file is /dev/null (very fast, but not realy helpful :-) the host is smp, and iddle. and just in case, it's running -current from last week. any insights? danny From owner-freebsd-current@FreeBSD.ORG Tue Sep 4 16:09:34 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A0F4416A417 for ; Tue, 4 Sep 2007 16:09:34 +0000 (UTC) (envelope-from bsd-current@epcdirect.co.uk) Received: from gunfright.epcdirect.co.uk (gunfright.epcdirect.co.uk [195.10.242.32]) by mx1.freebsd.org (Postfix) with ESMTP id 2311F13C46E for ; Tue, 4 Sep 2007 16:09:33 +0000 (UTC) (envelope-from bsd-current@epcdirect.co.uk) Received: from localhost (localhost.epcdirect.co.uk [127.0.0.1]) by gunfright.epcdirect.co.uk (Postfix) with ESMTP id 2E1E061B9; Tue, 4 Sep 2007 17:09:32 +0100 (BST) X-Virus-Scanned: by GunFright.EPCDirect.co.uk Received: from gunfright.epcdirect.co.uk ([127.0.0.1]) by localhost (gunfright.epcdirect.co.uk [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id KWP58iAt5y2n; Tue, 4 Sep 2007 17:09:31 +0100 (BST) Received: from lfarr (l-farr.int.epcdirect.co.uk [192.168.6.200]) by gunfright.epcdirect.co.uk (Postfix) with ESMTP id D3CF661AB; Tue, 4 Sep 2007 17:09:31 +0100 (BST) From: "Lawrence Farr" To: "'Danny Braniss'" , References: In-Reply-To: Date: Tue, 4 Sep 2007 17:09:30 +0100 Message-ID: <016b01c7ef0d$f98fc270$ecaf4750$@co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcfvC5zvaGB0hIfKSo2miXz1aSqCDgAAjnmA Content-Language: en-gb Cc: Subject: RE: dump problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2007 16:09:34 -0000 > -----Original Message----- > From: owner-freebsd-current@freebsd.org [mailto:owner-freebsd- > current@freebsd.org] On Behalf Of Danny Braniss > Sent: 04 September 2007 16:52 > To: freebsd-current@freebsd.org > Subject: dump problems > > dump start out nicely, but then it justs hangs. > have tried it with different file systems, the output > is also a file, again tried it with different file system. > the only way it works is if the output file is /dev/null (very > fast, but not realy helpful :-) > > the host is smp, and iddle. > and just in case, it's running -current from last week. > > any insights? > > danny Im also seeing the same on SMP and UP. From owner-freebsd-current@FreeBSD.ORG Tue Sep 4 16:51:14 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BB50916A419; Tue, 4 Sep 2007 16:51:14 +0000 (UTC) (envelope-from mezz7@cox.net) Received: from eastrmmtai104.cox.net (eastrmmtai104.cox.net [68.230.240.11]) by mx1.freebsd.org (Postfix) with ESMTP id 1D79B13C465; Tue, 4 Sep 2007 16:51:14 +0000 (UTC) (envelope-from mezz7@cox.net) Received: from eastrmimpo02.cox.net ([68.1.16.120]) by eastrmmtao102.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20070904152337.SJXP19980.eastrmmtao102.cox.net@eastrmimpo02.cox.net>; Tue, 4 Sep 2007 11:23:37 -0400 Received: from mezz.mezzweb.com ([24.255.149.218]) by eastrmimpo02.cox.net with bizsmtp id kFPc1X00C4iy4EG0000000; Tue, 04 Sep 2007 11:23:36 -0400 Date: Tue, 04 Sep 2007 10:27:33 -0500 To: "Ivan Voras" From: "Jeremy Messenger" Content-Type: text/plain; format=flowed; delsp=yes; charset=us-ascii MIME-Version: 1.0 References: Content-Transfer-Encoding: Quoted-Printable Message-ID: In-Reply-To: User-Agent: Opera Mail/9.23 (Linux) Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: VirtualBox? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2007 16:51:14 -0000 On Tue, 04 Sep 2007 08:33:50 -0500, Ivan Voras wrot= e: > Hi, > > Is anyone working on porting VirtualBox? > > http://www.virtualbox.org/wiki/Porting_VirtualBox > > It mentions FreeBSD but nothing conclusive. It should be easier than > VMWare :) http://www.virtualbox.org/wiki/VBox_vs_Others (see in host box) http://www.virtualbox.org/wiki/FreeBSD%20build%20instructions http://www.virtualbox.org/search?q=3Dfreebsd&wiki=3Don&changeset=3Don&ti= cket=3Don It looks like they are working on it. Cheers, Mezz -- = mezz7@cox.net - mezz@FreeBSD.org FreeBSD GNOME Team - FreeBSD Multimedia Hat (ports, not src) http://www.FreeBSD.org/gnome/ - gnome@FreeBSD.org http://wiki.freebsd.org/multimedia - multimedia@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Tue Sep 4 16:56:28 2007 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AA2DE16A420 for ; Tue, 4 Sep 2007 16:56:28 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from mail-gw0.york.ac.uk (mail-gw0.york.ac.uk [144.32.128.245]) by mx1.freebsd.org (Postfix) with ESMTP id 4334913C49D for ; Tue, 4 Sep 2007 16:56:28 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from mail-gw7.york.ac.uk (mail-gw7.york.ac.uk [144.32.129.30]) by mail-gw0.york.ac.uk (8.13.6/8.13.6) with ESMTP id l84GOYck008654; Tue, 4 Sep 2007 17:24:34 +0100 (BST) Received: from buffy-128.york.ac.uk ([144.32.128.160] helo=buffy.york.ac.uk) by mail-gw7.york.ac.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1ISbCb-0002VE-Vn; Tue, 04 Sep 2007 17:24:34 +0100 Received: from buffy.york.ac.uk (localhost [127.0.0.1]) by buffy.york.ac.uk (8.14.1/8.14.1) with ESMTP id l84GOXH7074803; Tue, 4 Sep 2007 17:24:33 +0100 (BST) (envelope-from gavin@FreeBSD.org) Received: (from ga9@localhost) by buffy.york.ac.uk (8.14.1/8.14.1/Submit) id l84GOXPf074802; Tue, 4 Sep 2007 17:24:33 +0100 (BST) (envelope-from gavin@FreeBSD.org) X-Authentication-Warning: buffy.york.ac.uk: ga9 set sender to gavin@FreeBSD.org using -f From: Gavin Atkinson To: Danny Braniss In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Tue, 04 Sep 2007 17:24:32 +0100 Message-Id: <1188923072.73362.37.camel@buffy.york.ac.uk> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 FreeBSD GNOME Team Port X-York-MailScanner: Found to be clean X-York-MailScanner-From: gavin@freebsd.org Cc: freebsd-current@FreeBSD.org Subject: Re: dump problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2007 16:56:28 -0000 On Tue, 2007-09-04 at 18:51 +0300, Danny Braniss wrote: > dump start out nicely, but then it justs hangs. > have tried it with different file systems, the output > is also a file, again tried it with different file system. > the only way it works is if the output file is /dev/null (very > fast, but not realy helpful :-) When it hangs, what is printed when you send it a CTRL-T? Gavin From owner-freebsd-current@FreeBSD.ORG Tue Sep 4 17:05:44 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0F50E16A419; Tue, 4 Sep 2007 17:05:44 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from mail.ipt.ru (mail.ipt.ru [194.62.233.102]) by mx1.freebsd.org (Postfix) with ESMTP id B895C13C465; Tue, 4 Sep 2007 17:05:43 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from srv.sem.ipt.ru ([192.168.12.1] helo=ipt.ru) by mail.ipt.ru with esmtp (Exim 4.62 (FreeBSD)) (envelope-from ) id 1ISbSm-0003rL-CF; Tue, 04 Sep 2007 20:41:16 +0400 Received: from bsam by ipt.ru with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1ISbVN-000F1s-Mm; Tue, 04 Sep 2007 20:43:57 +0400 To: Ivan Voras References: From: Boris Samorodov Date: Tue, 04 Sep 2007 20:43:57 +0400 In-Reply-To: (Ivan Voras's message of "Tue\, 04 Sep 2007 12\:31\:57 +0200") Message-ID: <22108082@srv.sem.ipt.ru> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.99 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: Progress for 7.0 - the "what's cooking" page X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2007 17:05:44 -0000 On Tue, 04 Sep 2007 12:31:57 +0200 Ivan Voras wrote: > Of course, additions, corrections, etc. are also welcome. It may be worth mentioning that iscsi_initiator appeared. WBR -- Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-current@FreeBSD.ORG Tue Sep 4 17:05:44 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B234216A417; Tue, 4 Sep 2007 17:05:44 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from mail.ipt.ru (mail.ipt.ru [194.62.233.102]) by mx1.freebsd.org (Postfix) with ESMTP id 6642413C46B; Tue, 4 Sep 2007 17:05:44 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from stat.sem.ipt.ru ([192.168.12.1] helo=ipt.ru) by mail.ipt.ru with esmtp (Exim 4.62 (FreeBSD)) (envelope-from ) id 1ISbNk-0003qn-HE; Tue, 04 Sep 2007 20:36:04 +0400 Received: from bsam by ipt.ru with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1ISbQL-000Esz-RB; Tue, 04 Sep 2007 20:38:45 +0400 To: Ivan Voras References: From: Boris Samorodov Date: Tue, 04 Sep 2007 20:38:45 +0400 In-Reply-To: (Ivan Voras's message of "Tue\, 04 Sep 2007 12\:31\:57 +0200") Message-ID: <98908394@srv.sem.ipt.ru> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.99 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, netchild@FreeBSD.org Subject: Re: Progress for 7.0 - the "what's cooking" page X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2007 17:05:44 -0000 Hi Ivan! On Tue, 04 Sep 2007 12:31:57 +0200 Ivan Voras wrote: > As some of you may know, I'm maintaining a web page which aims to > enumerate and describe major new features for FreeBSD 7, located at > http://ivoras.sharanet.org/freebsd/freebsd7.html . > Since 7.0 should be released "soon", I'd like to update the page with > the current status of the projects. In particular, I'd like to mark > projects that won't be ready for 7.0. To do so, I need input from the > projects' authors and maintainers. So if you are listed on the page > and your project status is updated and no longer matches what's > written on the page, please respond to this thread. Also, if a feature > won't be ready for 7.0 but will be sometime during 7.x, please state > so. > Of course, additions, corrections, etc. are also welcome. As for linuxulator. The default sysctl will be "compat.linux.osrelease: 2.4.2" and the port will be linux_base-fc4: http://lists.freebsd.org/pipermail/freebsd-emulation/2007-August/003914.html HTH & WBR -- bsam From owner-freebsd-current@FreeBSD.ORG Tue Sep 4 17:54:36 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 060DE16A417 for ; Tue, 4 Sep 2007 17:54:36 +0000 (UTC) (envelope-from mnslinky@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.246]) by mx1.freebsd.org (Postfix) with ESMTP id B5E9F13C478 for ; Tue, 4 Sep 2007 17:54:35 +0000 (UTC) (envelope-from mnslinky@gmail.com) Received: by an-out-0708.google.com with SMTP id c14so437042anc for ; Tue, 04 Sep 2007 10:54:35 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:in-reply-to:references:mime-version:content-type:message-id:cc:content-transfer-encoding:from:subject:date:to:x-mailer; b=CJRQuiO9dUnDSzIvTEaTw27k3wCxFLtnlnKgQW8DgDjpeTh5/HePjn49kpQVxh1xQ5jHPqsCL536DZBfvGdGoZSHybvHrPiihsFQWoMV5cLcpg1A5ZIj9QJxzcemwzf1jceahz5b8DoI/7mISbuYzuxsjtjXbrxfEGvDZU9qHc4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:in-reply-to:references:mime-version:content-type:message-id:cc:content-transfer-encoding:from:subject:date:to:x-mailer; b=PLx4L1SPigVVocjhRUfEUm7KEntJMAAIuekHcc5I3UTmW/VdZg/m7qWxiPKu3gqX10LfnfMP4waLtrG9mMHRH1eza7V4ZvduNrjQbo+NmqbZPj44JI2hzv/iRYQp7emgWZy6OCUJWvMUZJNgOt4ER0uikwRzU0CKRDg/XBlfxEQ= Received: by 10.100.153.17 with SMTP id a17mr4916039ane.1188927029528; Tue, 04 Sep 2007 10:30:29 -0700 (PDT) Received: from ?10.0.0.14? ( [74.95.66.25]) by mx.google.com with ESMTPS id z80sm7104312pyg.2007.09.04.10.30.26 (version=SSLv3 cipher=OTHER); Tue, 04 Sep 2007 10:30:27 -0700 (PDT) In-Reply-To: <98908394@srv.sem.ipt.ru> References: <98908394@srv.sem.ipt.ru> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Eric Crist Date: Tue, 4 Sep 2007 12:30:24 -0500 To: Boris Samorodov X-Mailer: Apple Mail (2.752.3) X-Mailman-Approved-At: Tue, 04 Sep 2007 18:30:36 +0000 Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: Progress for 7.0 - the "what's cooking" page X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2007 17:54:36 -0000 On Sep 4, 2007, at 11:38 AMSep 4, 2007, Boris Samorodov wrote: > As for linuxulator. The default sysctl will be > "compat.linux.osrelease: 2.4.2" and the port will be linux_base-fc4: > http://lists.freebsd.org/pipermail/freebsd-emulation/2007-August/ > 003914.html I'm sure I'm wrong, but I could have sworn I read something today about linuxolator being 2.6.16 kernel with Fedora Core 6? ----- Eric F Crist Secure Computing Networks From owner-freebsd-current@FreeBSD.ORG Tue Sep 4 18:15:43 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 820C216A419; Tue, 4 Sep 2007 18:15:43 +0000 (UTC) (envelope-from matt@ixsystems.com) Received: from mail.iXsystems.com (newknight.ixsystems.net [206.40.55.70]) by mx1.freebsd.org (Postfix) with ESMTP id 61FA913C428; Tue, 4 Sep 2007 18:15:43 +0000 (UTC) (envelope-from matt@ixsystems.com) Received: from localhost (localhost [127.0.0.1]) by mail.iXsystems.com (Postfix) with ESMTP id A17E4BE63; Tue, 4 Sep 2007 10:48:59 -0700 (PDT) Received: from mail.iXsystems.com ([127.0.0.1]) by localhost (mail.ixsystems.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12079-04; Tue, 4 Sep 2007 10:48:42 -0700 (PDT) Received: from client-173.nat.ixsystems.net (unknown [192.168.1.173]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.iXsystems.com (Postfix) with ESMTP id 80C6DBE22; Tue, 4 Sep 2007 10:48:42 -0700 (PDT) From: Matt Olander Organization: iXsystems To: freebsd-hackers@freebsd.org Date: Tue, 4 Sep 2007 10:48:41 -0700 User-Agent: KMail/1.9.5 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200709041048.41892.matt@ixsystems.com> X-Virus-Scanned: Maia Mailguard X-Mailman-Approved-At: Tue, 04 Sep 2007 18:30:36 +0000 Cc: Jeremy Messenger , freebsd-current@freebsd.org, Ivan Voras Subject: Re: VirtualBox? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2007 18:15:43 -0000 On Tuesday 04 September 2007 8:27 am, Jeremy Messenger wrote: > On Tue, 04 Sep 2007 08:33:50 -0500, Ivan Voras wrote: > > Hi, > > > > Is anyone working on porting VirtualBox? > > > > http://www.virtualbox.org/wiki/Porting_VirtualBox > > > > It mentions FreeBSD but nothing conclusive. It should be easier than > > VMWare :) > > http://www.virtualbox.org/wiki/VBox_vs_Others (see in host box) > http://www.virtualbox.org/wiki/FreeBSD%20build%20instructions > http://www.virtualbox.org/search?q=3Dfreebsd&wiki=3Don&changeset=3Don&tic= ket=3Don > > It looks like they are working on it. I spoke with a couple of their devs on Freenode and while they are willing = to=20 assist contributors porting to FreeBSD, they are not actively working on it= =20 themselves. Their response to my inquiry was "check out source and start=20 porting!" A few of their devs hang out in #vbox-dev on Freenode. This would be an=20 excellent port for FreeBSD. best, =2Dmatt =2D-=20 Matt Olander CTO, iXsystems - "Servers for Open Source" =A0http://www.iXsystems.com Public Relations, The FreeBSD Project =A0 =A0 =A0 =A0 http://www.FreeBSD.org BSD on the Desktop! =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= http://www.pcbsd.org Phone: (408)943-4100 ext. 113 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Fax: = (408)943-4101 From owner-freebsd-current@FreeBSD.ORG Tue Sep 4 18:44:03 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A0A7E16A41B for ; Tue, 4 Sep 2007 18:44:03 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.187]) by mx1.freebsd.org (Postfix) with ESMTP id 313F813C442 for ; Tue, 4 Sep 2007 18:44:02 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: by nf-out-0910.google.com with SMTP id k4so1484912nfd for ; Tue, 04 Sep 2007 11:44:01 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:received:received:date:from:to:subject:message-id:mail-followup-to:mime-version:content-type:content-disposition:user-agent; b=U4gKwr02K8M34QvyRE7lSmCgrCYrri73/58GBhl0+r1lf2raD4X08U7h5dasYj3mRCqNrvDzjZ6UdHa0KbaXxg0FAEXApOR4bgfz2+wDEG2M6ZUZ/xEF8uSGyfX8SmhJHoPzi6Y7uxwNYS1DUljLX9F1SqfCvuInH/HQffjkL2I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:date:from:to:subject:message-id:mail-followup-to:mime-version:content-type:content-disposition:user-agent; b=OoEjnz6wRJ4LvRmtum/zTs7SLSlsLywV4zLIHUqeB5zimxf0PMoRbZWGBOb4/6Pn6XvBP/UBJ+MrY9HI6PvOBkflt0tGAeWWhEtST5g9DsNjsiGK23Eu8QNl7tZ2TUm6isF13EKbbPsBouULHvYPzYbF8Q80zmVrDquLuA3zDWk= Received: by 10.86.58.3 with SMTP id g3mr4489697fga.1188931441548; Tue, 04 Sep 2007 11:44:01 -0700 (PDT) Received: from roadrunner.spoerlein.net ( [85.180.160.220]) by mx.google.com with ESMTPS id f31sm8712867fkf.2007.09.04.11.44.00 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 04 Sep 2007 11:44:01 -0700 (PDT) Received: from roadrunner.spoerlein.net (localhost [127.0.0.1]) by roadrunner.spoerlein.net (8.14.1/8.14.1) with ESMTP id l84IhtGW003449 for ; Tue, 4 Sep 2007 20:43:55 +0200 (CEST) (envelope-from uspoerlein@gmail.com) Received: (from q@localhost) by roadrunner.spoerlein.net (8.14.1/8.14.1/Submit) id l84Iht3M003448 for current@freebsd.org; Tue, 4 Sep 2007 20:43:55 +0200 (CEST) (envelope-from uspoerlein@gmail.com) Date: Tue, 4 Sep 2007 20:43:54 +0200 From: Ulrich Spoerlein To: current@freebsd.org Message-ID: <20070904184354.GA1466@roadrunner.spoerlein.net> Mail-Followup-To: current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.16 (2007-06-09) Cc: Subject: CVS repository corruption in src/usr.sbin/pkg_install/pkg? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2007 18:44:03 -0000 Hi all, since I can't seem to find a mail address for the cvsmeisters, I'm writing to -current. Perhaps someone can forward this mail to the responsible person. I'm playing with the conversion of the FreeBSD CVS repository into various other formats, among them svn. When using cvs2svn 2.0 it (rightly) complains about the state of the repository for pkg_install ERROR: Directory name conflicts with filename. Please remove or rename one of the following: "/data/ncvs/src/usr.sbin/pkg_install/pkg" "/data/ncvs/src/usr.sbin/pkg_install/Attic/pkg,v" Exited due to fatal error(s). src/usr.sbin/pkg_install/pkg is an empty (!) directory, which serves no purpose AFAICT. If/When someone removes the directory on the master CVS server, will that correctly propagate through cvsup? Cheers, Ulrich Spoerlein -- It is better to remain silent and be thought a fool, than to speak, and remove all doubt. From owner-freebsd-current@FreeBSD.ORG Tue Sep 4 18:47:17 2007 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5E31016A417 for ; Tue, 4 Sep 2007 18:47:17 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from cs1.cs.huji.ac.il (cs1.cs.huji.ac.il [132.65.16.10]) by mx1.freebsd.org (Postfix) with ESMTP id 18D0613C45D for ; Tue, 4 Sep 2007 18:47:17 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by cs1.cs.huji.ac.il with esmtp id 1ISdQi-000GkC-4v; Tue, 04 Sep 2007 21:47:16 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Gavin Atkinson In-reply-to: Your message of Tue, 04 Sep 2007 17:24:32 +0100 . Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 04 Sep 2007 21:47:16 +0300 From: Danny Braniss Message-ID: Cc: freebsd-current@FreeBSD.org Subject: Re: dump problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2007 18:47:17 -0000 > On Tue, 2007-09-04 at 18:51 +0300, Danny Braniss wrote: > > dump start out nicely, but then it justs hangs. > > have tried it with different file systems, the output > > is also a file, again tried it with different file system. > > the only way it works is if the output file is /dev/null (very > > fast, but not realy helpful :-) > > When it hangs, what is printed when you send it a CTRL-T? > off the top of my head: ... running ... it seems to be a problem on the writing side, since setting the output to /dev/null actually works. the commands used were: dump 0Lf - /some/file/system | restore rf - this got stuck, so I started experimenting: dump 0Lf file.dump /some/file/system gets stuck, ^T will mostly return ... [running] ... since at least one of the dump process is running, but my guess it's just monitoring. I also tried without the L flag, but did not change the result. the only dump that finishes, is when the output is /dev/null. danny From owner-freebsd-current@FreeBSD.ORG Tue Sep 4 18:58:52 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 703D116A419 for ; Tue, 4 Sep 2007 18:58:52 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from mail.ipt.ru (mail.ipt.ru [194.62.233.102]) by mx1.freebsd.org (Postfix) with ESMTP id 2B20C13C467 for ; Tue, 4 Sep 2007 18:58:52 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from admin.sem.ipt.ru ([192.168.12.1] helo=ipt.ru) by mail.ipt.ru with esmtp (Exim 4.62 (FreeBSD)) (envelope-from ) id 1ISdbt-0004DA-Rm; Tue, 04 Sep 2007 22:58:49 +0400 Received: from bsam by ipt.ru with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1ISdeV-000Ixa-HQ; Tue, 04 Sep 2007 23:01:31 +0400 To: Eric Crist References: <98908394@srv.sem.ipt.ru> From: Boris Samorodov Date: Tue, 04 Sep 2007 23:01:31 +0400 In-Reply-To: (Eric Crist's message of "Tue\, 4 Sep 2007 12\:30\:24 -0500") Message-ID: <89949828@srv.sem.ipt.ru> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.99 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-current@freebsd.org Subject: Re: Progress for 7.0 - the "what's cooking" page X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2007 18:58:52 -0000 On Tue, 4 Sep 2007 12:30:24 -0500 Eric Crist wrote: > On Sep 4, 2007, at 11:38 AMSep 4, 2007, Boris Samorodov wrote: > > As for linuxulator. The default sysctl will be > > "compat.linux.osrelease: 2.4.2" and the port will be linux_base-fc4: > > http://lists.freebsd.org/pipermail/freebsd-emulation/2007-August/ > > 003914.html > I'm sure I'm wrong, but I could have sworn I read something today > about linuxolator being 2.6.16 kernel with Fedora Core 6? Well, to use Fedora Core 6 at -CURRENT you definitely must set linux.osrelease to 2.6.16. But this feature is highly experimental for now. So do linux_base-fc6 port. It won't be a default for 7.0-RELEASE. WBR -- Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-current@FreeBSD.ORG Tue Sep 4 20:55:00 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C2E8516A419 for ; Tue, 4 Sep 2007 20:55:00 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from vlakno.cz (vlk.vlakno.cz [62.168.28.247]) by mx1.freebsd.org (Postfix) with ESMTP id 7CAFD13C468 for ; Tue, 4 Sep 2007 20:54:59 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from localhost (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 7101C8C26D4; Tue, 4 Sep 2007 22:54:58 +0200 (CEST) X-Virus-Scanned: amavisd-new at vlakno.cz Received: from vlakno.cz ([127.0.0.1]) by localhost (vlk.vlakno.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O9nk5tcBWems; Tue, 4 Sep 2007 22:54:57 +0200 (CEST) Received: from vlk.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 18C778C26CF; Tue, 4 Sep 2007 22:54:57 +0200 (CEST) Received: (from rdivacky@localhost) by vlk.vlakno.cz (8.13.8/8.13.8/Submit) id l84Ksus3069906; Tue, 4 Sep 2007 22:54:56 +0200 (CEST) (envelope-from rdivacky) Date: Tue, 4 Sep 2007 22:54:56 +0200 From: Roman Divacky To: Boris Samorodov Message-ID: <20070904205456.GA69763@freebsd.org> References: <98908394@srv.sem.ipt.ru> <89949828@srv.sem.ipt.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <89949828@srv.sem.ipt.ru> User-Agent: Mutt/1.4.2.3i Cc: Eric Crist , freebsd-current@freebsd.org Subject: Re: Progress for 7.0 - the "what's cooking" page X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2007 20:55:00 -0000 On Tue, Sep 04, 2007 at 11:01:31PM +0400, Boris Samorodov wrote: > On Tue, 4 Sep 2007 12:30:24 -0500 Eric Crist wrote: > > On Sep 4, 2007, at 11:38 AMSep 4, 2007, Boris Samorodov wrote: > > > > As for linuxulator. The default sysctl will be > > > "compat.linux.osrelease: 2.4.2" and the port will be linux_base-fc4: > > > http://lists.freebsd.org/pipermail/freebsd-emulation/2007-August/ > > > 003914.html > > > I'm sure I'm wrong, but I could have sworn I read something today > > about linuxolator being 2.6.16 kernel with Fedora Core 6? > > Well, to use Fedora Core 6 at -CURRENT you definitely must set > linux.osrelease to 2.6.16. But this feature is highly experimental > for now. So do linux_base-fc6 port. It won't be a default for > 7.0-RELEASE. I am not sure it's "highly" experimental but it's definitely not targeted for any critical use. works fine for an interesting portion of programs though... roman From owner-freebsd-current@FreeBSD.ORG Tue Sep 4 21:04:03 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 757A016A417 for ; Tue, 4 Sep 2007 21:04:03 +0000 (UTC) (envelope-from sziszi@bsd.hu) Received: from mail.rubicom.hu (mail.rubicom.hu [89.147.80.28]) by mx1.freebsd.org (Postfix) with ESMTP id 2D3D613C45D for ; Tue, 4 Sep 2007 21:04:03 +0000 (UTC) (envelope-from sziszi@bsd.hu) Received: from localhost ([127.0.0.1] helo=mail.rubicom.hu) by mail.rubicom.hu with smtp (Exim 4.63) (envelope-from ) id 1ISf3t-0006Jb-8H for freebsd-current@freebsd.org; Tue, 04 Sep 2007 22:31:49 +0200 Received: from ip5993549e.rubicom.hu ([89.147.84.158] helo=baranyfelhocske.buza.adamsfamily.xx) by mail.rubicom.hu with esmtp (Exim 4.63) (envelope-from ) id 1ISf3s-0006J9-C4 for freebsd-current@freebsd.org; Tue, 04 Sep 2007 22:31:48 +0200 Received: from baranyfelhocske.buza.adamsfamily.xx (localhost [127.0.0.1]) by baranyfelhocske.buza.adamsfamily.xx (8.14.1/8.14.1) with ESMTP id l84KWPdL003096 for ; Tue, 4 Sep 2007 22:32:25 +0200 (CEST) (envelope-from sziszi@bsd.hu) Received: (from sziszi@localhost) by baranyfelhocske.buza.adamsfamily.xx (8.14.1/8.14.1/Submit) id l84KWP8I003095 for freebsd-current@freebsd.org; Tue, 4 Sep 2007 22:32:25 +0200 (CEST) (envelope-from sziszi@bsd.hu) X-Authentication-Warning: baranyfelhocske.buza.adamsfamily.xx: sziszi set sender to sziszi@bsd.hu using -f Date: Tue, 4 Sep 2007 22:32:25 +0200 From: Szilveszter Adam To: freebsd-current@freebsd.org Message-ID: <20070904203225.GA1895@baranyfelhocske.buza.adamsfamily.xx> Mail-Followup-To: Szilveszter Adam , freebsd-current@freebsd.org References: <1188892560.28297.27.camel@pav.hide.vol.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline In-Reply-To: <1188892560.28297.27.camel@pav.hide.vol.cz> User-Agent: Mutt/1.5.16 (2007-06-09) Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by baranyfelhocske.buza.adamsfamily.xx id l84KWPdL003096 Subject: Re: [Fwd: gkrellmwireless-2.0.2_7 failed on amd64 7] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2007 21:04:03 -0000 On Tue, Sep 04, 2007 at 09:56:00AM +0200, Pav Lucistnik wrote: > Hey list, >=20 > a bunch of ports broke on recent CURRENT, similar to the log below. > Who's responsible for this change - who should I nag to fix the ports? The commit that caused this is=20 http://lists.freebsd.org/pipermail/cvs-all/2007-July/226628.html by thompsa.=20 The log says that the ioctls that used to be used by wicontrol were removed. It seems that several applications relied on this interface (even in the case of non-wi cards/chips) probably because this used to be one of the first such interfaces on FreeBSD and then just continued working (TM). Unfortunately some =F6of the affected apps are esentially abandoned (eg wmwifi) so I have no idea if the port maintainer can fix them alone. But it would be nice, because now it is really hard to find any wlan signal monitoring apps for FreeBSD apart from Gnome/KDE applets. --=20 Regards: Szilveszter ADAM Budapest Hungary From owner-freebsd-current@FreeBSD.ORG Tue Sep 4 21:29:59 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 45B6A16A419 for ; Tue, 4 Sep 2007 21:29:59 +0000 (UTC) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id 2086513C461 for ; Tue, 4 Sep 2007 21:29:59 +0000 (UTC) (envelope-from sam@errno.com) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id l84LTdhi039268 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Sep 2007 14:29:41 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <46DDCF48.4060805@errno.com> Date: Tue, 04 Sep 2007 14:34:00 -0700 From: Sam Leffler User-Agent: Thunderbird 2.0.0.6 (X11/20070814) MIME-Version: 1.0 To: Szilveszter Adam , freebsd-current@freebsd.org References: <1188892560.28297.27.camel@pav.hide.vol.cz> <20070904203225.GA1895@baranyfelhocske.buza.adamsfamily.xx> In-Reply-To: <20070904203225.GA1895@baranyfelhocske.buza.adamsfamily.xx> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Subject: Re: [Fwd: gkrellmwireless-2.0.2_7 failed on amd64 7] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2007 21:29:59 -0000 Szilveszter Adam wrote: > On Tue, Sep 04, 2007 at 09:56:00AM +0200, Pav Lucistnik wrote: > >> Hey list, >> >> a bunch of ports broke on recent CURRENT, similar to the log below. >> Who's responsible for this change - who should I nag to fix the ports? >> > > The commit that caused this is > > http://lists.freebsd.org/pipermail/cvs-all/2007-July/226628.html > > by thompsa. > > The log says that the ioctls that used to be used by wicontrol were > removed. It seems that several applications relied on this interface > (even in the case of non-wi cards/chips) probably because this used to > be one of the first such interfaces on FreeBSD and then just continued > working (TM). Unfortunately some öof the affected apps are esentially > abandoned (eg wmwifi) so I have no idea if the port maintainer can fix > them alone. But it would be nice, because now it is really hard to find > any wlan signal monitoring apps for FreeBSD apart from Gnome/KDE applets. > The old wi ioctl's have been deprecated for a very long time. There are replacements that should be used instead. The easiest thing to do is crib code from ifconfig. Sam From owner-freebsd-current@FreeBSD.ORG Tue Sep 4 23:47:47 2007 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 42D5C16A417; Tue, 4 Sep 2007 23:47:47 +0000 (UTC) (envelope-from cpghost@cordula.ws) Received: from fw.farid-hajji.net (fw.farid-hajji.net [213.146.115.42]) by mx1.freebsd.org (Postfix) with ESMTP id D21D613C461; Tue, 4 Sep 2007 23:47:46 +0000 (UTC) (envelope-from cpghost@cordula.ws) Received: from epia-2.farid-hajji.net (epia-2 [192.168.254.11]) by fw.farid-hajji.net (Postfix) with ESMTP id 0CA6DDF141; Wed, 5 Sep 2007 01:31:06 +0200 (CEST) Date: Wed, 5 Sep 2007 01:32:46 +0200 From: cpghost To: Danny Braniss Message-ID: <20070904233246.GA2409@epia-2.farid-hajji.net> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-current@FreeBSD.org, Gavin Atkinson Subject: Re: dump problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2007 23:47:47 -0000 On Tue, Sep 04, 2007 at 09:47:16PM +0300, Danny Braniss wrote: > > On Tue, 2007-09-04 at 18:51 +0300, Danny Braniss wrote: > > > dump start out nicely, but then it justs hangs. > > > have tried it with different file systems, the output > > > is also a file, again tried it with different file system. > > > the only way it works is if the output file is /dev/null (very > > > fast, but not realy helpful :-) > > > > When it hangs, what is printed when you send it a CTRL-T? > > > off the top of my head: > > ... running ... > > it seems to be a problem on the writing side, since setting the output > to /dev/null actually works. > > the commands used were: > > dump 0Lf - /some/file/system | restore rf - > this got stuck, so I started experimenting: > dump 0Lf file.dump /some/file/system > > gets stuck, ^T will mostly return ... [running] ... since at least > one of the dump process is running, but my guess it's just monitoring. > I also tried without the L flag, but did not change the result. > the only dump that finishes, is when the output is /dev/null. Try again with the 'a' flag. dump(8) still assumes that it writes to a set of tapes, and if the writing stalls for some reason (restore(8) being slow or somesuch), dump may ask to switch tapes. Since all this is of course bogus now, use 'a' to disable all those tape size calculation heuristics, as in # dump 0Luaf - /some/file/system | restore rf - > danny Good luck, -cpghost. -- Cordula's Web. http://www.cordula.ws/ From owner-freebsd-current@FreeBSD.ORG Tue Sep 4 20:52:00 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 19BEC16A418 for ; Tue, 4 Sep 2007 20:52:00 +0000 (UTC) (envelope-from nox@saturn.kn-bremen.de) Received: from gwyn.kn-bremen.de (gwyn.kn-bremen.de [212.63.36.242]) by mx1.freebsd.org (Postfix) with ESMTP id 97DD113C428 for ; Tue, 4 Sep 2007 20:51:57 +0000 (UTC) (envelope-from nox@saturn.kn-bremen.de) Received: by gwyn.kn-bremen.de (Postfix, from userid 10) id A43912184B6; Tue, 4 Sep 2007 22:51:55 +0200 (CEST) Received: from saturn.kn-bremen.de (nox@localhost [127.0.0.1]) by saturn.kn-bremen.de (8.13.8/8.13.6) with ESMTP id l84KndC3077338; Tue, 4 Sep 2007 22:49:39 +0200 (CEST) (envelope-from nox@saturn.kn-bremen.de) Received: (from nox@localhost) by saturn.kn-bremen.de (8.13.8/8.13.6/Submit) id l84Kndbs077337; Tue, 4 Sep 2007 22:49:39 +0200 (CEST) (envelope-from nox) From: Juergen Lock Date: Tue, 4 Sep 2007 22:49:39 +0200 To: Nenhum_de_Nos Message-ID: <20070904204939.GA74683@saturn.kn-bremen.de> References: <4956a5e50709022056o16fe85c8oab72532afe335b43@mail.gmail.com> <059F5A32-4979-422B-B42B-8163A151E874@dougk-ff7.net> <46DB9A1E.4080000@cran.org.uk> <4956a5e50709030343x6de3ab6frab925421859bd7f0@mail.gmail.com> <46DC4118.8020300@cran.org.uk> <4956a5e50709031654v9b13eb9na0a964dd9cb7f497@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4956a5e50709031654v9b13eb9na0a964dd9cb7f497@mail.gmail.com> User-Agent: Mutt/1.5.16 (2007-06-09) X-Mailman-Approved-At: Wed, 05 Sep 2007 02:08:14 +0000 Cc: Bruce Cran , freebsd-current@freebsd.org Subject: Re: qemu on a recent -current, slow like a 486 ! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2007 20:52:00 -0000 On Mon, Sep 03, 2007 at 08:54:57PM -0300, Nenhum_de_Nos wrote: > On 9/3/07, Bruce Cran wrote: > > Nenhum_de_Nos wrote: > > > I have disabled all but one debug support: > > > > > > makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols > > > > > > no witness also > > > > > > thanks > > > > > > matheus > > > > > > > > > > Hi Matheus, > > > > If you haven't tried kqemu-kmod, I would highly recommend it - with the > > caveat that, being a kernel module that hasn't been extensively tested, > > it may crash your system. > > It should speed up qemu to near-native speeds since it allows the code > > to run natively instead of being interpreted one instruction at a time. > > > > Cheers, > > Bruce Cran > > hm, I'll try this today :) > thanks, but now what I think will most kill performance is that even > though I say -smp 2 and it has two cpus (my machine is in fact dual > core), it has one and only one process for all qemu vm, and there fore > uses just one core. > > is it really supposed to behave this way ? -smp is meant more for testing purposes than running stuff where performance matters, qemu is still single-threaded and -smp doesn't work with kqemu... Oh and if you want to use kqemu don't forget to rebuild qemu with kqemu support enabled to get the relevant bits compiled in (do `make config' to get the OPTIONS menu back), that will also build kqemu as a dependency so you don't need to build that seperately. Also there is -kernel-kqemu too, altho not all guests really work with that. (freebsd guests mostly work, I have seen guest kernels complain about the clock going backwards tho.) HTH, Juergen From owner-freebsd-current@FreeBSD.ORG Tue Sep 4 23:07:38 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EFFB516A418 for ; Tue, 4 Sep 2007 23:07:38 +0000 (UTC) (envelope-from Benjamin.Close@clearchain.com) Received: from ipmail03.adl2.internode.on.net (ipmail03.adl2.internode.on.net [203.16.214.135]) by mx1.freebsd.org (Postfix) with ESMTP id 570C813C468 for ; Tue, 4 Sep 2007 23:07:38 +0000 (UTC) (envelope-from Benjamin.Close@clearchain.com) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FADN+3UZ5La7a/2dsb2JhbACBWQ X-IronPort-AV: E=Sophos;i="4.20,208,1186324200"; d="scan'208";a="143407475" Received: from ppp121-45-174-218.lns11.adl2.internode.on.net (HELO mail.clearchain.com) ([121.45.174.218]) by ipmail03.adl2.internode.on.net with ESMTP; 05 Sep 2007 08:22:18 +0930 Received: from benjamin-closes-powerbook-g4-12.local (wcl.ml.unisa.edu.au [130.220.166.5]) (authenticated bits=0) by mail.clearchain.com (8.13.8/8.13.8) with ESMTP id l84Mq7un065049 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Sep 2007 08:22:15 +0930 (CST) (envelope-from Benjamin.Close@clearchain.com) Message-ID: <46DDE44B.1060203@clearchain.com> Date: Wed, 05 Sep 2007 08:33:39 +0930 From: Benjamin Close User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Kenneth Vestergaard Schmidt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on pegasus.clearchain.com X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (mail.clearchain.com [192.168.154.1]); Wed, 05 Sep 2007 08:22:15 +0930 (CST) X-Mailman-Approved-At: Wed, 05 Sep 2007 02:08:14 +0000 Cc: freebsd-current@freebsd.org Subject: Re: Unkillable and runaway processes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2007 23:07:39 -0000 Kenneth Vestergaard Schmidt wrote: > Hello. > > Our ZFS testbed is experiencing some weird problems with rsync. We run a > nightly backup of about 1.6 TB data (that's how much is stored, not how > much is transferred), but after the initial sync I haven't been able to > get the machine through one full cycle. > > After many hours of rsyncing data from 50+ machines, suddenly one > rsync-process will hang, spinning on the CPU. > > It switches state between CPU0, CPU1, RUN and 'zfs:(&', but doesn't > really do anything. It can't be killed, and you can't reboot the machine > - it'll get past syncing disks, but won't shutdown or reboot. > > I can't do an 'ls' in the directory that rsync is running on - it'll > just hang, too. > > The machine is running current from August 29th. > > I could use some pointers on what to do - is there some way I can debug > this better, maybe give some better info? > > I do a similar thing with close to 3 TB of data and have found that too much activity causes the same hang you mention. Disabiling ZIL fixes the issues: vfs.zfs.zil_disable=1 in /boot/loader.conf Since ZFS is always consistent on disk and ZIL and it's a nightly rsync, disabling ZIL is quite safe. I'd love to debug here this but can't as the box uses a USB mouse/keyboard so every time I drop to a debugger I lose keyboard support :( Cheers, Benjamin From owner-freebsd-current@FreeBSD.ORG Wed Sep 5 02:34:30 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D8B6316A41A for ; Wed, 5 Sep 2007 02:34:30 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.186]) by mx1.freebsd.org (Postfix) with ESMTP id 6D10113C461 for ; Wed, 5 Sep 2007 02:34:30 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: by nf-out-0910.google.com with SMTP id k4so1582472nfd for ; Tue, 04 Sep 2007 19:34:29 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=U+wtANiEl+G6Hz2fqGDDyl5b/e5HW9c0iYsTpqb999dszFjwHtrEIk69td/F6Em+mkUq0T7ecAkl1B57BtXzQby2FgBPYdmSQUQZNfhGfDFarGy+K7y5jDLIY1QiDndibV8Fjrzj+zAiFqkWsSLTd7AfPh2XByvsMF8jeM8CnQc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=czB4BQF4KMpuo2LNZh3BR3pAugug6hAhnBs++4m8hvDMJIIh4XLQ3YlXDGW75uJTahgaUu0N974h/EuwPhLJhCxp80MdlzIzeLxLYutccFGb4NL4Wr/255mwJk/GL3DPf7RKj1365wzJEKH1x3iYOleyzpXB0qcKMqZWTGvDKig= Received: by 10.78.180.16 with SMTP id c16mr4734242huf.1188959668822; Tue, 04 Sep 2007 19:34:28 -0700 (PDT) Received: by 10.78.162.18 with HTTP; Tue, 4 Sep 2007 19:34:28 -0700 (PDT) Message-ID: Date: Tue, 4 Sep 2007 19:34:28 -0700 From: "Kip Macy" To: "Kenneth Vestergaard Schmidt" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: Cc: freebsd-current@freebsd.org Subject: Re: Unkillable and runaway processes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2007 02:34:30 -0000 - re-compile the kernel with DDB - drop into DDB when the problem occurs ddb> ps ddb> show proc ddb> thread ddb> bt Send the backtrace to pjd. -Kip On 9/4/07, Kenneth Vestergaard Schmidt wrote: > Hello. > > Our ZFS testbed is experiencing some weird problems with rsync. We run a > nightly backup of about 1.6 TB data (that's how much is stored, not how > much is transferred), but after the initial sync I haven't been able to > get the machine through one full cycle. > > After many hours of rsyncing data from 50+ machines, suddenly one > rsync-process will hang, spinning on the CPU. > > It switches state between CPU0, CPU1, RUN and 'zfs:(&', but doesn't > really do anything. It can't be killed, and you can't reboot the machine > - it'll get past syncing disks, but won't shutdown or reboot. > > I can't do an 'ls' in the directory that rsync is running on - it'll > just hang, too. > > The machine is running current from August 29th. > > I could use some pointers on what to do - is there some way I can debug > this better, maybe give some better info? > > -- > Kenneth Schmidt > pil.dk > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Wed Sep 5 04:44:15 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6FC5E16A420 for ; Wed, 5 Sep 2007 04:44:15 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.189]) by mx1.freebsd.org (Postfix) with ESMTP id E9AAD13C483 for ; Wed, 5 Sep 2007 04:44:14 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: by nf-out-0910.google.com with SMTP id k4so1603257nfd for ; Tue, 04 Sep 2007 21:44:13 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=FBjEKOd7bfamjxybkyB3dU1PDMI0oBCLXrlNq8Ld6jZllY7nYrZQrhqe8zb+nz2PILq9mQx0zwt9Grhw42W1cXouKarjph3rXwPh87O3Z/nbz/4ie+fN41arceb/3G+LMDfLSUt1vGsgEAqrn4X0seSNFW7YraqPJyZIhnbke+Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=Trv39Exv0Jf0iXzpBs+lQsdj0afo8/TydiNXtaEwwNU21wNO1H9eCy/LUGQ1fV30KvcxcY/DjmU4ijJMooIFgvqBVoSV5ucuRrM7CDs5LEwqAryLRBQ8hGToqYeLDvxqdc202H9R9XpkIOnxqmp+jDA471SW0wGSq/128yNPjYg= Received: by 10.86.81.8 with SMTP id e8mr4844276fgb.1188965853096; Tue, 04 Sep 2007 21:17:33 -0700 (PDT) Received: by 10.86.52.6 with HTTP; Tue, 4 Sep 2007 21:17:28 -0700 (PDT) Message-ID: <11167f520709042117m54b60531l4b23cb4b040f40d4@mail.gmail.com> Date: Tue, 4 Sep 2007 23:17:28 -0500 From: "Sam Fourman Jr." To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Alltel PPC6700 Wireless Modem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2007 04:44:15 -0000 hello, I have a PPC6700 HTC device that acts as a Wireless Modem, I recently asked in the OpenBSD misc@ list if they could add my device so it would be detected as a Modem. I was Given the Following diff, it works Great in OpenBSD now, Would I beable to ask for some help creating a diff for FreeBSD -Current, I did Try to Manually Edit the files and Recompile, but the modem still came up at ugen0 in OpenBSD You have to run 'make' in /usr/src/sys/dev/usb/ before compiling a kernel. do you have to do this In FreeBSD as Well? *************************************************************************** **** THE FOLLOWING IS A OPENBSD PATCH **** Index: sys/dev/usb/usbdevs =================================================================== RCS file: /cvs/src/sys/dev/usb/usbdevs,v retrieving revision 1.289 diff -u -p -r1.289 usbdevs --- sys/dev/usb/usbdevs 30 Aug 2007 05:06:21 -0000 1.289 +++ sys/dev/usb/usbdevs 31 Aug 2007 22:40:07 -0000 @@ -383,6 +383,7 @@ vendor ASUS 0x0b05 ASUS vendor SIIG2 0x0b39 SIIG vendor TEKRAM 0x0b3b Tekram Technology vendor HAL 0x0b41 HAL Corporation +vendor HTC 0x0bb4 HTC vendor NEC2 0x0b62 NEC vendor ATI2 0x0b6f ATI vendor KURUSUGAWA 0x0b7e Kurusugawa Electronics @@ -1285,6 +1286,9 @@ product HP 568J 0x1116 Jornada 568 /* HP products */ product HP2 C500 0x6002 PhotoSmart C500 + +/* HTC products */ +product HTC PPC6700MODEM 0x00cf PPC6700 Modem /* HUAWEI products */ product HUAWEI E618 0x1001 HUAWEI Mobile E618 Index: sys/dev/usb/uipaq.c =================================================================== RCS file: /cvs/src/sys/dev/usb/uipaq.c,v retrieving revision 1.12 diff -u -p -r1.12 uipaq.c --- sys/dev/usb/uipaq.c 14 Jun 2007 10:11:16 -0000 1.12 +++ sys/dev/usb/uipaq.c 31 Aug 2007 22:40:07 -0000 @@ -121,11 +121,12 @@ struct uipaq_type { }; static const struct uipaq_type uipaq_devs[] = { + {{ USB_VENDOR_ASUS, USB_PRODUCT_ASUS_MYPAL_A730} , 0}, + {{ USB_VENDOR_CASIO, USB_PRODUCT_CASIO_BE300} , 0}, + {{ USB_VENDOR_COMPAQ, USB_PRODUCT_COMPAQ_IPAQPOCKETPC} , 0}, {{ USB_VENDOR_HP, USB_PRODUCT_HP_2215 }, 0 }, {{ USB_VENDOR_HP, USB_PRODUCT_HP_568J }, 0}, - {{ USB_VENDOR_COMPAQ, USB_PRODUCT_COMPAQ_IPAQPOCKETPC} , 0}, - {{ USB_VENDOR_CASIO, USB_PRODUCT_CASIO_BE300} , 0}, - {{ USB_VENDOR_ASUS, USB_PRODUCT_ASUS_MYPAL_A730} , 0} + {{ USB_VENDOR_HTC, USB_PRODUCT_HTC_PPC6700MODEM }, 0} }; #define uipaq_lookup(v, p) ((struct uipaq_type *)usb_lookup(uipaq_devs, v, p)) Thank you for any help you can provide Sam Fourman Jr. From owner-freebsd-current@FreeBSD.ORG Wed Sep 5 05:12:09 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A730A16A468 for ; Wed, 5 Sep 2007 05:12:09 +0000 (UTC) (envelope-from Johan@double-l.nl) Received: from smtp-vbr7.xs4all.nl (smtp-vbr7.xs4all.nl [194.109.24.27]) by mx1.freebsd.org (Postfix) with ESMTP id 3819F13C48D for ; Wed, 5 Sep 2007 05:12:09 +0000 (UTC) (envelope-from Johan@double-l.nl) Received: from w2003s01.double-l.local (dpm.xs4all.nl [213.84.11.61]) by smtp-vbr7.xs4all.nl (8.13.8/8.13.8) with ESMTP id l855C7aR062001; Wed, 5 Sep 2007 07:12:08 +0200 (CEST) (envelope-from Johan@double-l.nl) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 5 Sep 2007 07:12:06 +0200 Message-ID: <57200BF94E69E54880C9BB1AF714BBCB19BCE6@w2003s01.double-l.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Progress for 7.0 - the "what's cooking" page Thread-Index: Acfu5pubUni9BhPCRqGXrKoJ5PJwjwAlCxtg References: From: "Johan Hendriks" To: "Ivan Voras" X-Virus-Scanned: by XS4ALL Virus Scanner Cc: freebsd-current@freebsd.org Subject: RE: Progress for 7.0 - the "what's cooking" page X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2007 05:12:09 -0000 DQo+SGksDQoNCj5BcyBzb21lIG9mIHlvdSBtYXkga25vdywgSSdtIG1haW50YWluaW5nIGEgd2Vi IHBhZ2Ugd2hpY2ggYWltcyB0byBlbnVtZXJhdGUgYW5kIGRlc2NyaWJlIG1ham9yIG5ldyBmZWF0 dXJlcyBmb3IgRnJlZUJTRCA3LCBsb2NhdGVkIGF0ID5odHRwOi8vaXZvcmFzLnNoYXJhbmV0Lm9y Zy9mcmVlYnNkL2ZyZWVic2Q3Lmh0bWwgLg0KDQo+U2luY2UgNy4wIHNob3VsZCBiZSByZWxlYXNl ZCAic29vbiIsIEknZCBsaWtlIHRvIHVwZGF0ZSB0aGUgcGFnZSB3aXRoIHRoZSBjdXJyZW50IHN0 YXR1cyBvZiB0aGUgcHJvamVjdHMuIEluIHBhcnRpY3VsYXIsIEknZCBsaWtlIHRvIG1hcmsgPnBy b2plY3RzIHRoYXQgd29uJ3QgYmUgcmVhZHkgZm9yIDcuMC4gVG8gZG8gc28sIEkgbmVlZCBpbnB1 dCBmcm9tIHRoZSBwcm9qZWN0cycgYXV0aG9ycyBhbmQgbWFpbnRhaW5lcnMuIFNvIGlmIHlvdSBh cmUgbGlzdGVkIG9uIHRoZSBwYWdlIGFuZCA+eW91ciBwcm9qZWN0IHN0YXR1cyBpcyB1cGRhdGVk IGFuZCBubyBsb25nZXIgbWF0Y2hlcyB3aGF0J3Mgd3JpdHRlbiBvbiB0aGUgcGFnZSwgcGxlYXNl IHJlc3BvbmQgdG8gdGhpcyB0aHJlYWQuIEFsc28sIGlmIGEgZmVhdHVyZSB3b24ndCBiZSA+cmVh ZHkgZm9yIDcuMCBidXQgd2lsbCBiZSBzb21ldGltZSBkdXJpbmcgNy54LCBwbGVhc2Ugc3RhdGUg c28uDQoNCj5PZiBjb3Vyc2UsIGFkZGl0aW9ucywgY29ycmVjdGlvbnMsIGV0Yy4gYXJlIGFsc28g d2VsY29tZS4NCg0KPlRoYW5rcyA6KQ0KDQpJIHdvdWxkIGxpa2UgdG8ga25vdyB0aGUgc3RhdHVz IG9mIGd2aXJzdG9yLiBPbiB0aGUgY29va2luZyBwYWdlIHRoZSBzdGF0dXMgaXMgd2FpdGluZyB0 byBjb21taXQuDQpXaXRoIHRoZSBuZXcgcmVsZWFzZSB0byBjb21lIEkgdGhpbmsgaXQgY291bGQg dXNlIHNvbWUgd2lkZSBzcHJlYWQgdGVzdGluZy4NCk9yIHdpbGwgaXQgYmUgbWFya2VkIGV4cGVy aW1lbnRhbCBsaWtlIFpGUz8NCg0KUmVnYXJkcywNCkpvaGFuIEhlbmRyaWtzDQoNCg0K From owner-freebsd-current@FreeBSD.ORG Wed Sep 5 05:46:44 2007 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 049A816A418; Wed, 5 Sep 2007 05:46:44 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from cs1.cs.huji.ac.il (cs1.cs.huji.ac.il [132.65.16.10]) by mx1.freebsd.org (Postfix) with ESMTP id B014313C459; Wed, 5 Sep 2007 05:46:43 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by cs1.cs.huji.ac.il with esmtp id 1ISnig-000Nbm-Ep; Wed, 05 Sep 2007 08:46:30 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: cpghost In-reply-to: <20070904233246.GA2409@epia-2.farid-hajji.net> References: <20070904233246.GA2409@epia-2.farid-hajji.net> Comments: In-reply-to cpghost message dated "Wed, 05 Sep 2007 01:32:46 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 05 Sep 2007 08:46:30 +0300 From: Danny Braniss Message-ID: Cc: freebsd-current@FreeBSD.org, Gavin Atkinson Subject: Re: dump problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2007 05:46:44 -0000 > On Tue, Sep 04, 2007 at 09:47:16PM +0300, Danny Braniss wrote: > > > On Tue, 2007-09-04 at 18:51 +0300, Danny Braniss wrote: > > > > dump start out nicely, but then it justs hangs. > > > > have tried it with different file systems, the output > > > > is also a file, again tried it with different file system. > > > > the only way it works is if the output file is /dev/null (very > > > > fast, but not realy helpful :-) > > > > > > When it hangs, what is printed when you send it a CTRL-T? > > > > > off the top of my head: > > > > ... running ... > > > > it seems to be a problem on the writing side, since setting the output > > to /dev/null actually works. > > > > the commands used were: > > > > dump 0Lf - /some/file/system | restore rf - > > this got stuck, so I started experimenting: > > dump 0Lf file.dump /some/file/system > > > > gets stuck, ^T will mostly return ... [running] ... since at least > > one of the dump process is running, but my guess it's just monitoring. > > I also tried without the L flag, but did not change the result. > > the only dump that finishes, is when the output is /dev/null. > > Try again with the 'a' flag. dump(8) still assumes that it writes > to a set of tapes, and if the writing stalls for some reason (restore(8) > being slow or somesuch), dump may ask to switch tapes. Since all this > is of course bogus now, use 'a' to disable all those tape size > calculation heuristics, as in > > # dump 0Luaf - /some/file/system | restore rf - true, but 1- if output is stdout it does not do any tape size calculations 2- it does not differentiate between 'regular file' and 'special file' and thus will stop requesting for another tape. so, yes, i forgot to say that i did use the -a flag, but i did say it's stuck, not that it's waiting for any tape change. so, sorry, no cookies yet :-) danny From owner-freebsd-current@FreeBSD.ORG Wed Sep 5 06:40:36 2007 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7A7D016A417 for ; Wed, 5 Sep 2007 06:40:36 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from mail.ipt.ru (mail.ipt.ru [194.62.233.102]) by mx1.freebsd.org (Postfix) with ESMTP id 3673213C4B3 for ; Wed, 5 Sep 2007 06:40:36 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from admin.sem.ipt.ru ([192.168.12.1] helo=ipt.ru) by mail.ipt.ru with esmtp (Exim 4.62 (FreeBSD)) (envelope-from ) id 1ISoZ0-0006nj-GC; Wed, 05 Sep 2007 10:40:34 +0400 Received: from bsam by ipt.ru with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1ISobd-000DAG-VJ; Wed, 05 Sep 2007 10:43:17 +0400 To: freebsd-current@FreeBSD.org From: Boris Samorodov Date: Wed, 05 Sep 2007 10:43:17 +0400 Message-ID: <75694330@srv.sem.ipt.ru> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.99 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: scottl@FreeBSD.org Subject: [iscsi_initiator] at amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2007 06:40:36 -0000 Hello Danny, Scott and All, Thank you for your work on iscsi! It's very appreciated. When testing iscsi I've got and error at amd64-current, while it's OK at i386-current. I've got two amd64 and one i386 machine for tests: iscsi-target (both from ports and a new snapshot, see PR/116097) work just fine. While iscsi_initiator works (discovery requests for localhost and remote machines) without errors only at i386. At both amd64 machines I get "0x0200: Initiator error" for command "iscontrol -dt [localhost|remote]". Here are the debugging info (debug.iscsi_initiator: 9) from the i386-machine (good session for localhost and bad request for remote amd64 machine): ftp://ftp.ipt.ru/pub/FreeBSD/test/iscsi/iscsi-i386.log.txt ftp://ftp.ipt.ru/pub/FreeBSD/test/iscsi/iscsi-amd64.log.txt All machines run a recent (two-thee days) -current and (almost) GENERIC kernel. Let me know if you need some more info/testing. Thank you! WBR -- Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-current@FreeBSD.ORG Wed Sep 5 09:07:52 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BEC1716A417; Wed, 5 Sep 2007 09:07:52 +0000 (UTC) (envelope-from gabor@FreeBSD.org) Received: from server.t-hosting.hu (server.t-hosting.hu [81.2.252.59]) by mx1.freebsd.org (Postfix) with ESMTP id 7758C13C474; Wed, 5 Sep 2007 09:07:52 +0000 (UTC) (envelope-from gabor@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) by server.t-hosting.hu (Postfix) with ESMTP id 12AC6A49B68; Wed, 5 Sep 2007 10:49:36 +0200 (CEST) X-Virus-Scanned: amavisd-new at t-hosting.hu Received: from server.t-hosting.hu ([127.0.0.1]) by localhost (server.t-hosting.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id zD2UxfwlX6KR; Wed, 5 Sep 2007 10:49:23 +0200 (CEST) Received: from [192.168.2.186] (catv-5063f539.catv.broadband.hu [80.99.245.57]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by server.t-hosting.hu (Postfix) with ESMTP id 87B6AA49B3B; Wed, 5 Sep 2007 10:49:23 +0200 (CEST) Message-ID: <46DE6D82.7000904@FreeBSD.org> Date: Wed, 05 Sep 2007 10:49:06 +0200 From: Gabor Kovesdan User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ivan Voras References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: Craig Rodrigues , freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: Progress for 7.0 - the "what's cooking" page X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2007 09:07:52 -0000 Ivan Voras escribió: > > Since 7.0 should be released "soon", I'd like to update the page with > the current status of the projects. In particular, I'd like to mark > projects that won't be ready for 7.0. To do so, I need input from the > projects' authors and maintainers. So if you are listed on the page > and your project status is updated and no longer matches what's > written on the page, please respond to this thread. Also, if a feature > won't be ready for 7.0 but will be sometime during 7.x, please state so. Read-only XFS support? Afaik it is only in -current. -- Gabor Kovesdan FreeBSD Volunteer EMAIL: gabor@FreeBSD.org .:|:. gabor@kovesdan.org WEB: http://people.FreeBSD.org/~gabor .:|:. http://kovesdan.org From owner-freebsd-current@FreeBSD.ORG Wed Sep 5 10:13:42 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D1DD416A417 for ; Wed, 5 Sep 2007 10:13:42 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 88BE813C48A for ; Wed, 5 Sep 2007 10:13:42 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1ISrsk-0002km-NR for freebsd-current@freebsd.org; Wed, 05 Sep 2007 12:13:10 +0200 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 05 Sep 2007 12:13:10 +0200 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 05 Sep 2007 12:13:10 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Date: Wed, 05 Sep 2007 12:12:51 +0200 Lines: 36 Message-ID: References: <57200BF94E69E54880C9BB1AF714BBCB19BCE6@w2003s01.double-l.local> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-ripemd160; protocol="application/pgp-signature"; boundary="------------enig4EC764CE2C30AE2823B42759" X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 1.5.0.12 (X11/20060911) In-Reply-To: <57200BF94E69E54880C9BB1AF714BBCB19BCE6@w2003s01.double-l.local> X-Enigmail-Version: 0.94.4.0 Sender: news Subject: Re: Progress for 7.0 - the "what's cooking" page X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2007 10:13:42 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig4EC764CE2C30AE2823B42759 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Johan Hendriks wrote: > I would like to know the status of gvirstor. On the cooking page the st= atus is waiting to commit. > With the new release to come I think it could use some wide spread test= ing. I think it's ready, but I'm waiting on a very busy mentor to do the=20 commit (pjd). > Or will it be marked experimental like ZFS? I have no such plans but I also haven't heard any reports of people=20 testing it in a while. --------------enig4EC764CE2C30AE2823B42759 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFG3oEpldnAQVacBcgRAxS2AKC7UaI8duuWv22FlW/nwP9kV8jmFwCfX3th ho1+eIKoyqEMNmBDeqCVSKI= =jHCA -----END PGP SIGNATURE----- --------------enig4EC764CE2C30AE2823B42759-- From owner-freebsd-current@FreeBSD.ORG Wed Sep 5 07:17:08 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4B0D216A417 for ; Wed, 5 Sep 2007 07:17:08 +0000 (UTC) (envelope-from jrisom@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.181]) by mx1.freebsd.org (Postfix) with ESMTP id 06F7D13C46A for ; Wed, 5 Sep 2007 07:17:07 +0000 (UTC) (envelope-from jrisom@gmail.com) Received: by py-out-1112.google.com with SMTP id u77so5962904pyb for ; Wed, 05 Sep 2007 00:17:07 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:in-reply-to:references:mime-version:content-type:message-id:content-transfer-encoding:cc:from:subject:date:to:x-mailer; b=Eglb36DI6vBSqlf/bF/fdCf4Nq1rANR2yKY1lfl/EKz6ua6ACoIKjHznVN9ka0FTALx1LmYMstXr46wnANl12WNV9UxLA6w20ww8+mDt6J5WHMsnQPhp4Y72qdwtzISDXSuUeVUKA0CI3MI7AWHISqFBXHPlXO85va3EkaQBBPM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:in-reply-to:references:mime-version:content-type:message-id:content-transfer-encoding:cc:from:subject:date:to:x-mailer; b=lmZurA2D5jYKa/fbRnjwT5nBo5NIo7Fp2g7B5ziCiyLfLbKexMyoC29pVuz6qF53h/qD+E9J7n1K58S92HujTOvp2edkL5aiXiYPYhcEMF/LmaFtoK1rhSG8yXD7QLkACcZD/Sevc+cNDBpoS175kJu/gzAuSDJDXwkkQFVPeao= Received: by 10.35.87.8 with SMTP id p8mr8370729pyl.1188975096688; Tue, 04 Sep 2007 23:51:36 -0700 (PDT) Received: from ?192.168.1.3? ( [74.134.230.123]) by mx.google.com with ESMTPS id f55sm8297674pyh.2007.09.04.23.51.32 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 04 Sep 2007 23:51:33 -0700 (PDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Joshua Isom Date: Wed, 5 Sep 2007 01:53:42 -0500 To: Ivan Voras X-Mailer: Apple Mail (2.624) X-Mailman-Approved-At: Wed, 05 Sep 2007 11:41:59 +0000 Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: Progress for 7.0 - the "what's cooking" page X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2007 07:17:08 -0000 I think some mention of ATAPI SATA drives should be mentioned. I have an SATA DVD-RW drive that needs a 7.0 kernel to be recognized, and given some comments on the list, the problem seems to be have been support for ATAPI SATA drives on FreeBSD 6.x(it's not in -STABLE). The chipset on the motherboard is "supported" under 6.x and it's a generic DVD-RW drive, but combined it's not supported without -CURRENT. I think is related but I haven't tested the code(I'm currently on 6-STABLE and about to upgrade to 7-CURRENT kernel and 6-STABLE userland). On Sep 4, 2007, at 5:31 AM, Ivan Voras wrote: > Hi, > > As some of you may know, I'm maintaining a web page which aims to > enumerate and describe major new features for FreeBSD 7, located at > http://ivoras.sharanet.org/freebsd/freebsd7.html . > > Since 7.0 should be released "soon", I'd like to update the page with > the current status of the projects. In particular, I'd like to mark > projects that won't be ready for 7.0. To do so, I need input from the > projects' authors and maintainers. So if you are listed on the page > and your project status is updated and no longer matches what's > written on the page, please respond to this thread. Also, if a feature > won't be ready for 7.0 but will be sometime during 7.x, please state > so. > > Of course, additions, corrections, etc. are also welcome. > > Thanks :) > > > From owner-freebsd-current@FreeBSD.ORG Wed Sep 5 14:09:09 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 013DD16A421; Wed, 5 Sep 2007 14:09:09 +0000 (UTC) (envelope-from gallatin@cs.duke.edu) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.freebsd.org (Postfix) with ESMTP id B91B813C457; Wed, 5 Sep 2007 14:09:08 +0000 (UTC) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.14.0/8.14.0) with ESMTP id l85E8rTj005859 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Sep 2007 10:08:53 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.12.9p2/8.12.9/Submit) id l85E8Pdf067908; Wed, 5 Sep 2007 10:08:25 -0400 (EDT) (envelope-from gallatin) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18142.47216.305394.719129@grasshopper.cs.duke.edu> Date: Wed, 5 Sep 2007 10:08:25 -0400 (EDT) To: Ivan Voras In-Reply-To: References: X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: Progress for 7.0 - the "what's cooking" page X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2007 14:09:09 -0000 The TSO/LRO section needs a little updating. According to find sys/dev | xargs grep -l IFCAP_TSO, TSO is present in at least: bce, cxgb, em, ixgbe, msk, mxge, nfe, nxge, re Based on grepping for IFCAP_LRO, LRO is currently available only in mxge. Note that the LRO in mxge is currently a driver specific hack (I wrote it, so I can say it :), intended to tide us over until Andre finishes his more extensive LRO infastructure. Further, LRO is currently done in software. Jack Vogel was looking at porting the mxge LRO into something that could be used by several 10GbE drivers; I'm not sure what happened to that. Drew From owner-freebsd-current@FreeBSD.ORG Wed Sep 5 14:19:23 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AAAC116A418 for ; Wed, 5 Sep 2007 14:19:23 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.freebsd.org (Postfix) with ESMTP id 4A20D13C45E for ; Wed, 5 Sep 2007 14:19:23 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 69F7A45E98; Wed, 5 Sep 2007 16:19:21 +0200 (CEST) Received: from localhost (pjd.wheel.pl [10.0.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 49A6A45E90; Wed, 5 Sep 2007 16:19:13 +0200 (CEST) Date: Wed, 5 Sep 2007 16:17:59 +0200 From: Pawel Jakub Dawidek To: Kenneth Vestergaard Schmidt Message-ID: <20070905141759.GJ12013@garage.freebsd.pl> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="EEx6GiKZGZ1wKUra" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-5.9 required=3.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 Cc: freebsd-current@freebsd.org Subject: Re: Unkillable and runaway processes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2007 14:19:23 -0000 --EEx6GiKZGZ1wKUra Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Sep 04, 2007 at 03:08:20PM +0200, Kenneth Vestergaard Schmidt wrote: > Hello. >=20 > Our ZFS testbed is experiencing some weird problems with rsync. We run a > nightly backup of about 1.6 TB data (that's how much is stored, not how > much is transferred), but after the initial sync I haven't been able to > get the machine through one full cycle. >=20 > After many hours of rsyncing data from 50+ machines, suddenly one > rsync-process will hang, spinning on the CPU. >=20 > It switches state between CPU0, CPU1, RUN and 'zfs:(&', but doesn't > really do anything. It can't be killed, and you can't reboot the machine > - it'll get past syncing disks, but won't shutdown or reboot. >=20 > I can't do an 'ls' in the directory that rsync is running on - it'll > just hang, too. >=20 > The machine is running current from August 29th. >=20 > I could use some pointers on what to do - is there some way I can debug > this better, maybe give some better info? Try disabling ZIL. This looks like a bug was already reported by Kris. This was already reported to OpenSolaris. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --EEx6GiKZGZ1wKUra Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFG3rqXForvXbEpPzQRAn58AJ0eoBSM3HrN1eVBpIX13DqV+kYjXQCcCO3J /n1Zb7ziZA0fAc1mK/iUe5Q= =DZa/ -----END PGP SIGNATURE----- --EEx6GiKZGZ1wKUra-- From owner-freebsd-current@FreeBSD.ORG Wed Sep 5 15:48:26 2007 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ACD1616A418 for ; Wed, 5 Sep 2007 15:48:26 +0000 (UTC) (envelope-from keramida@FreeBSD.org) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.freebsd.org (Postfix) with ESMTP id 1F70513C4A7 for ; Wed, 5 Sep 2007 15:48:25 +0000 (UTC) (envelope-from keramida@FreeBSD.org) Received: from kobe.laptop (vader.bytemobile.ondsl.gr [83.235.244.135]) (authenticated bits=128) by igloo.linux.gr (8.14.1/8.14.1/Debian-8) with ESMTP id l85FlsfW007438 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 5 Sep 2007 18:48:06 +0300 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.1/8.14.1) with ESMTP id l85Flh7D008683; Wed, 5 Sep 2007 18:47:52 +0300 (EEST) (envelope-from keramida@FreeBSD.org) Received: (from keramida@localhost) by kobe.laptop (8.14.1/8.14.1/Submit) id l85FlhxL008682; Wed, 5 Sep 2007 18:47:43 +0300 (EEST) (envelope-from keramida@FreeBSD.org) Date: Wed, 5 Sep 2007 18:47:42 +0300 From: Giorgos Keramidas To: Ulrich Spoerlein Message-ID: <20070905154742.GA8526@kobe.laptop> References: <20070904184354.GA1466@roadrunner.spoerlein.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gBBFr7Ir9EOA20Yy" Content-Disposition: inline In-Reply-To: <20070904184354.GA1466@roadrunner.spoerlein.net> X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-4.072, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.33, BAYES_00 -2.60) X-Hellug-MailScanner-From: keramida@freebsd.org X-Spam-Status: No Cc: current@FreeBSD.org Subject: Re: CVS repository corruption in src/usr.sbin/pkg_install/pkg? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2007 15:48:26 -0000 --gBBFr7Ir9EOA20Yy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi Ulrich, The email alias for CVS admins is `cvsadm'. Do you want me to forward this email to cvsadm@ or do you prefer to do it yourself? Feel free to Cc: me too, as I'm interested in conversion tool from CVS to Mercurial. - Giorgos On 2007-09-04 20:43, Ulrich Spoerlein wrote: > Hi all, > > since I can't seem to find a mail address for the cvsmeisters, I'm > writing to -current. Perhaps someone can forward this mail to the > responsible person. > > I'm playing with the conversion of the FreeBSD CVS repository into > various other formats, among them svn. When using cvs2svn 2.0 it > (rightly) complains about the state of the repository for pkg_install > > ERROR: Directory name conflicts with filename. Please remove or rename one > of the following: > "/data/ncvs/src/usr.sbin/pkg_install/pkg" > "/data/ncvs/src/usr.sbin/pkg_install/Attic/pkg,v" > Exited due to fatal error(s). > > src/usr.sbin/pkg_install/pkg is an empty (!) directory, which serves no > purpose AFAICT. If/When someone removes the directory on the master CVS > server, will that correctly propagate through cvsup? > > Cheers, > Ulrich Spoerlein --gBBFr7Ir9EOA20Yy Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFG3s+e1g+UGjGGA7YRAjVtAJ9RsN3TNt2yMELNuQoGNWY/WlEDjgCeKOid 4hTGTwaCtTKD+/Wk32tBGO4= =Fx7q -----END PGP SIGNATURE----- --gBBFr7Ir9EOA20Yy-- From owner-freebsd-current@FreeBSD.ORG Wed Sep 5 15:57:49 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E20C316A417; Wed, 5 Sep 2007 15:57:49 +0000 (UTC) (envelope-from kvs@binarysolutions.dk) Received: from solow.pil.dk (relay.pil.dk [195.41.47.164]) by mx1.freebsd.org (Postfix) with ESMTP id 9ED6C13C458; Wed, 5 Sep 2007 15:57:49 +0000 (UTC) (envelope-from kvs@binarysolutions.dk) Received: from coruscant.local (naboo.binarysolutions.dk [80.196.17.173]) by solow.pil.dk (Postfix) with ESMTP id 9118C1CC0F6; Wed, 5 Sep 2007 17:25:09 +0200 (CEST) Received: by coruscant.local (Postfix, from userid 502) id 0009360135F; Wed, 5 Sep 2007 17:25:09 +0200 (CEST) To: Pawel Jakub Dawidek References: <20070905141759.GJ12013@garage.freebsd.pl> From: Kenneth Vestergaard Schmidt Date: Wed, 05 Sep 2007 17:25:09 +0200 In-Reply-To: <20070905141759.GJ12013@garage.freebsd.pl> (Pawel Jakub Dawidek's message of "Wed\, 5 Sep 2007 16\:17\:59 +0200") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (darwin) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Wed, 05 Sep 2007 16:03:09 +0000 Cc: freebsd-current@freebsd.org Subject: Re: Unkillable and runaway processes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2007 15:57:50 -0000 Pawel Jakub Dawidek writes: >> I could use some pointers on what to do - is there some way I can debug >> this better, maybe give some better info? > > Try disabling ZIL. This looks like a bug was already reported by Kris. > This was already reported to OpenSolaris. We disabled ZIL, but the bug crept up again. I've just now rebooted the machine with DDB-support, so I can get some more info, per Kris's mail. The full state of the process hanging is 'zfs:(&tx->tx_quiesce_done_cv)' - it cycles between RUN, CPUx and this one. -- Kenneth Schmidt pil.dk From owner-freebsd-current@FreeBSD.ORG Wed Sep 5 17:19:23 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D890116A417 for ; Wed, 5 Sep 2007 17:19:23 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.freebsd.org (Postfix) with ESMTP id 7321413C483 for ; Wed, 5 Sep 2007 17:19:23 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 3965F45EBA; Wed, 5 Sep 2007 19:19:03 +0200 (CEST) Received: from localhost (154.81.datacomsa.pl [195.34.81.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id C31E245E8F; Wed, 5 Sep 2007 19:18:57 +0200 (CEST) Date: Wed, 5 Sep 2007 19:17:41 +0200 From: Pawel Jakub Dawidek To: Kenneth Vestergaard Schmidt Message-ID: <20070905171741.GA15709@garage.freebsd.pl> References: <20070905141759.GJ12013@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Q68bSM7Ycu6FN28Q" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-2.6 required=3.0 tests=BAYES_00 autolearn=ham version=3.0.4 Cc: freebsd-current@freebsd.org Subject: Re: Unkillable and runaway processes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2007 17:19:23 -0000 --Q68bSM7Ycu6FN28Q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Sep 05, 2007 at 05:25:09PM +0200, Kenneth Vestergaard Schmidt wrote: > Pawel Jakub Dawidek writes: > >> I could use some pointers on what to do - is there some way I can debug > >> this better, maybe give some better info? > > > > Try disabling ZIL. This looks like a bug was already reported by Kris. > > This was already reported to OpenSolaris. >=20 > We disabled ZIL, but the bug crept up again. I've just now rebooted the > machine with DDB-support, so I can get some more info, per Kris's mail. >=20 > The full state of the process hanging is 'zfs:(&tx->tx_quiesce_done_cv)' > - it cycles between RUN, CPUx and this one. Hmm, this means it didn't deadlock... --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --Q68bSM7Ycu6FN28Q Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFG3uS1ForvXbEpPzQRApouAJ9SJVVTKf+TsbkLOqscydR0Sf3dUwCgyweO keD6G9i86+CGzEn5XaN1iUU= =V24x -----END PGP SIGNATURE----- --Q68bSM7Ycu6FN28Q-- From owner-freebsd-current@FreeBSD.ORG Wed Sep 5 17:23:46 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A09CE16A418; Wed, 5 Sep 2007 17:23:46 +0000 (UTC) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.org (trang.nuxi.org [74.95.12.85]) by mx1.freebsd.org (Postfix) with ESMTP id 7C7C913C47E; Wed, 5 Sep 2007 17:23:46 +0000 (UTC) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.org (obrien@localhost [127.0.0.1]) by dragon.nuxi.org (8.14.1/8.14.1) with ESMTP id l85HND7o095917; Wed, 5 Sep 2007 10:23:13 -0700 (PDT) (envelope-from obrien@dragon.nuxi.org) Received: (from obrien@localhost) by dragon.nuxi.org (8.14.1/8.14.1/Submit) id l85HNC6F095916; Wed, 5 Sep 2007 10:23:12 -0700 (PDT) (envelope-from obrien) Date: Wed, 5 Sep 2007 10:23:12 -0700 From: "David O'Brien" To: d@delphij.net Message-ID: <20070905172312.GA95447@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, d@delphij.net, Giorgos Keramidas , Robert Watson , freebsd-current@freebsd.org References: <20070902181119.E21906@fledge.watson.org> <46DAF092.1030708@delphij.net> <46DB5F1C.4020807@delphij.net> <20070903021119.GD12449@kobe.laptop> <46DB705C.2090205@delphij.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46DB705C.2090205@delphij.net> X-Operating-System: FreeBSD 7.0-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 User-Agent: Mutt/1.5.11 Cc: freebsd-current@freebsd.org, Robert Watson , Giorgos Keramidas Subject: Re: more(1) has gotten more demanding? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: obrien@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2007 17:23:46 -0000 On Mon, Sep 03, 2007 at 10:24:28AM +0800, LI Xin wrote: > Giorgos Keramidas wrote: > > On 2007-09-03 09:10, Xin LI wrote: > >> Sorry, the patch. > http://people.freebsd.org/~delphij/for_review/main.c.diff Will it work for the 'b' key when invoked as 'more' BSD more is more functional than simple SysV more which only paged in the forward direction. -- -- David (obrien@FreeBSD.org) From owner-freebsd-current@FreeBSD.ORG Wed Sep 5 18:32:43 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8130E16A417 for ; Wed, 5 Sep 2007 18:32:43 +0000 (UTC) (envelope-from mfp49_freebsd@plass-family.net) Received: from plass-family.net (adsl-68-127-22-237.dsl.pltn13.pacbell.net [68.127.22.237]) by mx1.freebsd.org (Postfix) with ESMTP id 5CF4D13C467 for ; Wed, 5 Sep 2007 18:32:43 +0000 (UTC) (envelope-from mfp49_freebsd@plass-family.net) Received: from nat.plass-family.net (nat.plass-family.net [68.127.22.235]) by plass-family.net (Postfix) with ESMTP id 746C02284B for ; Wed, 5 Sep 2007 11:22:26 -0700 (PDT) Received: from [13.2.117.100] (presto.parc.xerox.com [13.2.117.100]) by garage.plass-family.net (Postfix) with ESMTP id E8D785C22 for ; Wed, 5 Sep 2007 11:22:25 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: <20070905120016.2470416A4F8@hub.freebsd.org> References: <20070905120016.2470416A4F8@hub.freebsd.org> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2D3D02AF-9586-4908-997D-E889A70E5A90@plass-family.net> Content-Transfer-Encoding: 7bit From: Michael Plass Date: Wed, 5 Sep 2007 11:22:19 -0700 To: freebsd-current@freebsd.org X-Mailer: Apple Mail (2.752.2) Subject: Re: Unkillable and runaway processes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2007 18:32:43 -0000 On Wed, 05 Sep 2007, Benjamin Close wrote: > I'd love to debug here this but can't as the box uses a USB > mouse/keyboard so every time I drop to a debugger I lose keyboard > support :( I have had some success using DDB with a USB keyboard by removing atk and kbdmux from the kernel config (nodevice lines for atkbdc, atkbd, psm, and kbdmux). A downside is that when I do this, dumps stop working - they hang on the call to cncheckc() when checking for user abort (the cncheckc() never returns). Replacing this call with (-1) allows the dump to proceed. For me, the relevant file is /usr/src/sys/amd64/amd64/ minidump_machdep.c. - Michael From owner-freebsd-current@FreeBSD.ORG Wed Sep 5 18:39:06 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E038F16A419 for ; Wed, 5 Sep 2007 18:39:06 +0000 (UTC) (envelope-from plass@parc.com) Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by mx1.freebsd.org (Postfix) with ESMTP id AEB9113C469 for ; Wed, 5 Sep 2007 18:39:06 +0000 (UTC) (envelope-from plass@parc.com) Received: from [13.2.117.100] ([13.2.117.100]) by alpha.xerox.com with SMTP id <512399(1)>; Wed, 5 Sep 2007 11:20:49 PDT In-Reply-To: <20070905120016.2470416A4F8@hub.freebsd.org> References: <20070905120016.2470416A4F8@hub.freebsd.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <803595E4-8B91-4762-8F49-A9CD688D4EC2@parc.com> Content-Transfer-Encoding: 7bit From: Michael Plass Date: Wed, 5 Sep 2007 11:20:48 PDT To: freebsd-current@freebsd.org X-Mailer: Apple Mail (2.752.2) X-Mailman-Approved-At: Wed, 05 Sep 2007 19:29:03 +0000 Cc: Michael Plass Subject: Re: Unkillable and runaway processes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2007 18:39:07 -0000 On Wed, 05 Sep 2007, Benjamin Close wrote: > I'd love to debug here this but can't as the box uses a USB > mouse/keyboard so every time I drop to a debugger I lose keyboard > support :( I have had some success using DDB with a USB keyboard by removing atk and kbdmux from the kernel config (nodevice lines for atkbdc, atkbd, psm, and kbdmux). A downside is that when I do this, dumps stop working - they hang on the call to cncheckc() when checking for user abort (the cncheckc() never returns). Replacing this call with (-1) allows the dump to proceed. For me, the relevant file is /usr/src/sys/amd64/amd64/ minidump_machdep.c. - Michael From owner-freebsd-current@FreeBSD.ORG Thu Sep 6 01:34:38 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7E5F816A46E for ; Thu, 6 Sep 2007 01:34:38 +0000 (UTC) (envelope-from weongyo.jeong@gmail.com) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.187]) by mx1.freebsd.org (Postfix) with ESMTP id 3BBF613C45E for ; Thu, 6 Sep 2007 01:34:37 +0000 (UTC) (envelope-from weongyo.jeong@gmail.com) Received: by rv-out-0910.google.com with SMTP id l15so4687rvb for ; Wed, 05 Sep 2007 18:34:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:received:date:to:cc:subject:message-id:mail-followup-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent:organization:x-operation-sytem:from; bh=03iQtWv4MTtighqPzi2qTDJJgnTu8z76zlhWTM1jgrQ=; b=ssrGRHA2KqnzmUIhC+3wGq8pTZ2mnCT951ezISSSbFUv3bBHPO/SWyRIBrjZttJoYFgdJul3JQ0LGzUi82e4gR9PJEhwr5l8VO6NkBMevHTmmJ66IZ1UwUhEYb2A4idLz6p1RM6KVhZHMkN8idSj0SRegojZWOG+RbWbLxzP82Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:date:to:cc:subject:message-id:mail-followup-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent:organization:x-operation-sytem:from; b=OX2jHbtbOm8wBBxFaGSukxTtmEDt3gfG3+xaLdzdXBZQ6T/VyJdOUiGusEVhSa5zz0Ki8xE5H8pADqphMJ48t2U2nphaUXrmzsxHJxDCBhOGzkr5Wt3LaaIAT20DcblTVIwSrulp/Ng9RnwsK3RUE8litB4g6X5hQwqDWiAVoVo= Received: by 10.114.73.1 with SMTP id v1mr23457waa.1189042473529; Wed, 05 Sep 2007 18:34:33 -0700 (PDT) Received: from freebsd.weongyo.org ( [211.53.35.67]) by mx.google.com with ESMTPS id k23sm8439214waf.2007.09.05.18.34.29 (version=SSLv3 cipher=OTHER); Wed, 05 Sep 2007 18:34:31 -0700 (PDT) Received: by freebsd.weongyo.org (sSMTP sendmail emulation); Thu, 6 Sep 2007 10:34:21 +0900 Date: Thu, 6 Sep 2007 10:34:21 +0900 To: Ted Lindgreen Message-ID: <20070906013421.GC2809@freebsd.weongyo.org> Mail-Followup-To: Ted Lindgreen , freebsd-current@freebsd.org References: <200708301414.l7UEEMSi004166@omval.tednet.nl> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="cvVnyQ+4j833TQvp" Content-Disposition: inline In-Reply-To: <200708301414.l7UEEMSi004166@omval.tednet.nl> User-Agent: Mutt/1.4.2.3i Organization: CDNetworks. X-Operation-Sytem: FreeBSD From: Weongyo Jeong Cc: freebsd-current@freebsd.org Subject: Re: New if_zyd driver X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2007 01:34:38 -0000 --cvVnyQ+4j833TQvp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Aug 30, 2007 at 04:14:22PM +0200, Ted Lindgreen wrote: > Hi, > > I'd like to report success with new zyd driver, and to thank the > author for his work. > > I had tried the diff that was published previously. With ifconfig, > the device associated with the access-point, but no traffic was > possible. With the files now included in CVS, the device works! > > However, the stick needs to be inserted after booting up. Then I can > also remove the stick without ill effects (for logmessages see below). > > When the stick is present during boot, the log shows: > Aug 30 15:25:17 lapje kernel: zyd0: on uhub4 > Aug 30 15:25:17 lapje kernel: zyd0: setting config no failed > and there are 2 problems: > 1. "ifconfig -a" shows no zyd0 device. > 2. when the stick is removed, the laptop panics (page fault) This panic is caused by a zyd driver bug and would be fixed by a patch that just prevents a panic. The patch is attached with this email. After testing why the stick can't be initialized during booting up, I can see that this condition only appears when I reboot my FreeBSD, not power on. It was loaded successfully whenever I power on. I think this problem is caused by the problem of the usb stick hardware reset and take some time to fix though I am looking at the code. Thank you for your feedback! Best Regards, Weongyo Jeong --cvVnyQ+4j833TQvp Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="zyd_patch_2ted_20070905.diff" Index: if_zyd.c =================================================================== RCS file: /data/zyd/zyd/if_zyd.c,v retrieving revision 1.24 diff -u -r1.24 if_zyd.c --- if_zyd.c 5 Sep 2007 02:20:11 -0000 1.24 +++ if_zyd.c 5 Sep 2007 02:21:37 -0000 @@ -307,7 +307,10 @@ STAILQ_INIT(&sc->sc_rqh); - zyd_attachhook(sc); + if (zyd_attachhook(sc) != 0) { + if_free(ifp); + return ENXIO; + } return 0; } --cvVnyQ+4j833TQvp-- From owner-freebsd-current@FreeBSD.ORG Thu Sep 6 05:25:16 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0D89516A418 for ; Thu, 6 Sep 2007 05:25:16 +0000 (UTC) (envelope-from n-butcher=freebsd-current=freebsd.org=sbibybnr@fusiongol.com) Received: from smtp02.dentaku.gol.com (smtp02.dentaku.gol.com [203.216.5.72]) by mx1.freebsd.org (Postfix) with ESMTP id 9EC3313C469 for ; Thu, 6 Sep 2007 05:25:15 +0000 (UTC) (envelope-from n-butcher=freebsd-current=freebsd.org=sbibybnr@fusiongol.com) Received: from pat.gol.co.jp ([203.216.1.191] helo=[127.0.0.1]) by smtp02.dentaku.gol.com with esmtpa (Dentaku) id 1IT9rA-0006Bm-Bz for ; Thu, 06 Sep 2007 14:24:44 +0900 Message-ID: <46DF8F1B.3020003@fusiongol.com> Date: Thu, 06 Sep 2007 14:24:43 +0900 From: Nathan Butcher User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: freebsd-current@freebsd.org X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV GOL X-Abuse-Complaints: abuse@gol.com Subject: DVD drive not detected on GA-G33-DS3R X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2007 05:25:16 -0000 I picked up a Gigabyte GA-G33-DS3R with the intent on running ZFS on it. The GA-G33-DS3R has 8 internal SATA ports of which 6 are provided by the Intel Southbridge ICH9 chipset and the other 2 are provided by the 'Gigabyte SATAII' chipset, which in reality is a JMicron JMB363, a supposedly very well supported chip, and FreeBSD detects it as such. I have a standard SATA DVD combo drive, but regardless of what mode (IDE, RAID, AHCI) I put the "Gigabyte SATAII chipset" in, FreeBSD won't detect it as /dev/acd0. Strange, because I can boot up the snapshot CD and get as far as selecting media from which to install FreeBSD -- except to be told that no CD drive is found. Working from the 200708-amd64 snapshot, the ICH9 only works in SATA300 mode when the chipset is placed in RAID mode, and is then detected by FreeBSD as ICH8 - and that seems to work. FreeBSD isn't picking up the drives when the chipset is in AHCI mode despite this message back in July: http://lists.freebsd.org/pipermail/freebsd-hardware/2007-July/004562.html Will try updating to the latest sources from the 200708 snapshot to see if that changes anything. From owner-freebsd-current@FreeBSD.ORG Thu Sep 6 06:14:42 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2FFFA16A417 for ; Thu, 6 Sep 2007 06:14:42 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id B7E7D13C480 for ; Thu, 6 Sep 2007 06:14:41 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (inchoate.gsoft.com.au [203.31.81.57]) (authenticated bits=0) by cain.gsoft.com.au (8.13.8/8.13.8) with ESMTP id l866EdnZ052941 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Sep 2007 15:44:39 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-current@freebsd.org Date: Thu, 6 Sep 2007 15:44:19 +0930 User-Agent: KMail/1.9.7 References: <46DF8F1B.3020003@fusiongol.com> In-Reply-To: <46DF8F1B.3020003@fusiongol.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2930320.Mp3YMScmo4"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200709061544.33646.doconnor@gsoft.com.au> X-Spam-Score: -3.977 () ALL_TRUSTED,BAYES_00 X-Scanned-By: MIMEDefang 2.58 on 203.31.81.10 Cc: Nathan Butcher Subject: Re: DVD drive not detected on GA-G33-DS3R X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2007 06:14:42 -0000 --nextPart2930320.Mp3YMScmo4 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thu, 6 Sep 2007, Nathan Butcher wrote: > I picked up a Gigabyte GA-G33-DS3R with the intent on running ZFS on > it. The GA-G33-DS3R has 8 internal SATA ports of which 6 are provided > by the Intel Southbridge ICH9 chipset and the other 2 are provided by > the 'Gigabyte SATAII' chipset, which in reality is a JMicron JMB363, > a supposedly very well supported chip, and FreeBSD detects it as > such. > > I have a standard SATA DVD combo drive, but regardless of what mode > (IDE, RAID, AHCI) I put the "Gigabyte SATAII chipset" in, FreeBSD > won't detect it as /dev/acd0. Strange, because I can boot up the > snapshot CD and get as far as selecting media from which to install > FreeBSD -- except to be told that no CD drive is found. I have the same issue with the JMicron part.. Interestingly it works in=20 6.2 but not -current so there is a regression. I asked sos@ about it and he said he'd try and look into it but I guess=20 he's been to busy with Real Life (tm) :) =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 --nextPart2930320.Mp3YMScmo4 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQBG35rJ5ZPcIHs/zowRAq9qAJ9BIf8hQmJLuCThuQCB7oYocnNjpwCgh1jv RUkZM4D3pY/gwtbmQVq/DqY= =FJOS -----END PGP SIGNATURE----- --nextPart2930320.Mp3YMScmo4-- From owner-freebsd-current@FreeBSD.ORG Thu Sep 6 07:09:41 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 52AFD16A419; Thu, 6 Sep 2007 07:09:41 +0000 (UTC) (envelope-from ianf@clue.co.za) Received: from munchkin.clue.co.za (munchkin.clue.co.za [66.219.59.160]) by mx1.freebsd.org (Postfix) with ESMTP id 1C2D313C46C; Thu, 6 Sep 2007 07:09:40 +0000 (UTC) (envelope-from ianf@clue.co.za) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=20070313; d=clue.co.za; h=Received:Received:Received:cc:From:Subject:In-Reply-To:X-Attribution:Date:Message-Id; b=yRI8hcgDE8iUlDKSREBmHR+gakC3mQEAB/kQ1KnY0KMATtTtbss8+i1ECNvWcOs+KZLT2K3A8TJ2CNWQEhpTAfNWy3xcAkngeubYYg0S4siLbSsSgoWieESPWfF4Yp7gfrwQOGr/Dj7VAOv4hE8PDhVUBRVYA+d4hZ0yKVJixvJ9U5P4oIXMIQ6qodweKJnonXJAXCLW0oo5wOu64TfMsw4oaZBxIHoIdPdAPHrKtfCq2iRjlKUBE+aPerVgGCAX; Received: from uucp by munchkin.clue.co.za with local-rmail (Exim 4.66) (envelope-from ) id 1ITBUA-00005c-Oa; Thu, 06 Sep 2007 07:09:06 +0000 Received: from ianf.clue.co.za ([10.0.0.6] helo=clue.co.za) by urchin.clue.co.za with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.66) (envelope-from ) id 1ITBTz-0006QG-Tj; Thu, 06 Sep 2007 07:08:56 +0000 Received: from localhost ([127.0.0.1] helo=clue.co.za) by clue.co.za with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1ITBTy-00056T-4G; Thu, 06 Sep 2007 09:08:54 +0200 From: Ian FREISLICH In-Reply-To: Message from Ian FREISLICH of "Tue, 04 Sep 2007 15:21:02 +0200." X-Attribution: BOFH Date: Thu, 06 Sep 2007 09:08:53 +0200 Message-Id: Cc: bu7cher@yandex.ru, rwatson@freebsd.org, freebsd-current@freebsd.org Subject: Re: Panic in ipfw X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2007 07:09:41 -0000 Ian FREISLICH wrote: > Ian FREISLICH wrote: > > "Andrey V. Elsukov" wrote: > > > Hi, Ian. > > > > > > > I got this panic yesterday on a fairly busy firewall. I have some > > > > private patches to ip_fw2.c and to the em driver (see the earlier > > > > "em0 hijacking traffic to port 623" thread). I don't think this > > > > panic is a result of those changes. > > > > > > > It occurred round about the time an address was added to an interface. > > > > > > I have a patch that can help you (i guess..). > > > Can you test this patch? > > > > > > http://butcher.heavennet.ru/patches/kernel/inaddr_locking/ > > > > Thanks. Wow, that looks like it touches a lot more than just ipfw. > > It took about 1.5 years of production at 2.3 billion backets a day > > to trigger this condition twice. It's going to be difficult to > > tell if this patch fixes the problem. > > This code is touched by Andrey's patch. I'm going to put that patch > into production tomorrow - this locking issue is raising it's head > too often now. That didn't go too well. The onsite admins messed up the serial console arangement so I couldn't see what happened when things went wrong. But they did. The only difference to the kernel was the inclusion of Audrey's patch. After about 6 hours we started seeing about 90% packet loss. I'm not sure if I'll get another chance to try this patch. Ian -- Ian Freislich From owner-freebsd-current@FreeBSD.ORG Thu Sep 6 07:11:49 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8637F16A419 for ; Thu, 6 Sep 2007 07:11:49 +0000 (UTC) (envelope-from lulf@stud.ntnu.no) Received: from royk.itea.ntnu.no (royk.itea.ntnu.no [129.241.190.230]) by mx1.freebsd.org (Postfix) with ESMTP id 3F25A13C491 for ; Thu, 6 Sep 2007 07:11:49 +0000 (UTC) (envelope-from lulf@stud.ntnu.no) Received: from localhost (localhost [127.0.0.1]) by royk.itea.ntnu.no (Postfix) with ESMTP id 13A7B66DDC; Thu, 6 Sep 2007 09:11:39 +0200 (CEST) Received: from twoflower.idi.ntnu.no (twoflower.idi.ntnu.no [129.241.104.169]) by royk.itea.ntnu.no (Postfix) with ESMTP; Thu, 6 Sep 2007 09:11:38 +0200 (CEST) Received: by twoflower.idi.ntnu.no (Postfix, from userid 1002) id D5B4417138; Fri, 24 Aug 2007 20:44:11 +0200 (CEST) Date: Fri, 24 Aug 2007 20:44:11 +0200 From: Ulf Lilleengen To: Jeremie Le Hen Message-ID: <20070824184411.GA29878@twoflower.idi.ntnu.no> Mail-Followup-To: Jeremie Le Hen , Nathan Butcher , freebsd-current@freebsd.org References: <46BFE620.8070906@fusiongol.com> <20070813091802.GB3078@stud.ntnu.no> <20070823071056.GA50852@obiwan.tataz.chchile.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070823071056.GA50852@obiwan.tataz.chchile.org> User-Agent: Mutt/1.5.15 (2007-04-06) X-Content-Scanned: with sophos and spamassassin at mailgw.ntnu.no. Cc: Nathan Butcher , freebsd-current@freebsd.org Subject: Re: Promise SATA 300 TX4 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "..."@twoflower.idi.ntnu.no List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2007 07:11:49 -0000 On tor, aug 23, 2007 at 09:10:56am +0200, Jeremie Le Hen wrote: > Hi Ulf, > > On Mon, Aug 13, 2007 at 11:18:02AM +0200, Ulf Lilleengen wrote: > > I have problems with this card in -CURRENT too. Details can be found > > here: > > http://lists.freebsd.org/pipermail/freebsd-current/2007-July/074960.html > > > > I never bothered trying with earlier versions of -CURRENT, but it > > works good in 6.2. > > I'm planning to switch my own server from 6.2 to -CURRENT soon. > Are you still experiencing such problems? I have not tried since then, but I'm planning to try again when I come back home next week. AFAIK, 'it' has not been fixed. -- Ulf Lilleengen From owner-freebsd-current@FreeBSD.ORG Thu Sep 6 07:30:26 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9723E16A5FC for ; Thu, 6 Sep 2007 07:30:26 +0000 (UTC) (envelope-from h.schmalzbauer@omnisec.de) Received: from host.omnisec.de (host.omnisec.de [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id 0A6BC13C468 for ; Thu, 6 Sep 2007 07:30:25 +0000 (UTC) (envelope-from h.schmalzbauer@omnisec.de) Received: from tek.flintsbach.schmalzbauer.de (tek.flintsbach.schmalzbauer.de [172.21.2.3]) by host.omnisec.de (8.13.8/8.13.8) with ESMTP id l867UBbr069491 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Sep 2007 09:30:16 +0200 (CEST) (envelope-from h.schmalzbauer@omnisec.de) Received: from titan.flintsbach.schmalzbauer.de (titan.flintsbach.schmalzbauer.de [IPv6:fec0::1:0:0:1:1]) by tek.flintsbach.schmalzbauer.de (8.13.8/8.13.8) with ESMTP id l867UBRX042084; Thu, 6 Sep 2007 09:30:11 +0200 (CEST) (envelope-from h.schmalzbauer@omnisec.de) Received: by titan.flintsbach.schmalzbauer.de (8.14.1/8.14.1/Submit) id l867VE1j001380; Thu, 6 Sep 2007 09:31:14 +0200 (CEST) (envelope-from h.schmalzbauer@omnisec.de) X-Authentication-Warning: titan.flintsbach.schmalzbauer.de: harry set sender to h.schmalzbauer@omnisec.de using -f From: Harald Schmalzbauer Organization: OmniSEC To: freebsd-current@freebsd.org Date: Thu, 6 Sep 2007 09:31:13 +0200 User-Agent: KMail/1.9.7 References: <46DF8F1B.3020003@fusiongol.com> In-Reply-To: <46DF8F1B.3020003@fusiongol.com> MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_Bz63GZWEvKQVUfO" Message-Id: <200709060931.13903.h.schmalzbauer@omnisec.de> Cc: Nathan Butcher Subject: Re: DVD drive not detected on GA-G33-DS3R X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2007 07:30:26 -0000 --Boundary-00=_Bz63GZWEvKQVUfO Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Content-Disposition: inline Am Donnerstag, 6. September 2007 07:24:43 schrieb Nathan Butcher: > I picked up a Gigabyte GA-G33-DS3R with the intent on running ZFS on it. > The GA-G33-DS3R has 8 internal SATA ports of which 6 are provided by the > Intel Southbridge ICH9 chipset and the other 2 are provided by the > 'Gigabyte SATAII' chipset, which in reality is a JMicron JMB363, a > supposedly very well supported chip, and FreeBSD detects it as such. > > I have a standard SATA DVD combo drive, but regardless of what mode > (IDE, RAID, AHCI) I put the "Gigabyte SATAII chipset" in, FreeBSD won't > detect it as /dev/acd0. Strange, because I can boot up the snapshot CD > and get as far as selecting media from which to install FreeBSD -- > except to be told that no CD drive is found. > > Working from the 200708-amd64 snapshot, the ICH9 only works in SATA300 > mode when the chipset is placed in RAID mode, and is then detected by > FreeBSD as ICH8 - and that seems to work. FreeBSD isn't picking up the > drives when the chipset is in AHCI mode despite this message back in July: Please find attached a patch I use with my ich9 board. The original author wanted to check some registers before commiting but I heard several times that ich8 and ich9 are identical regarding ATA. I'm using AHCI and it works fine, although I have some CD-Rom problems too (ATAPI) but haven't hd time to track it down (mostly burncd makes trouble) Best regards, -Harry --Boundary-00=_Bz63GZWEvKQVUfO Content-Type: text/x-diff; charset="iso-2022-jp"; name="ata-ich9.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ata-ich9.diff" --- sys/dev/ata/ata-pci.h.orig 2007-07-09 10:50:35.000000000 +0200 +++ sys/dev/ata/ata-pci.h 2007-07-17 20:35:45.000000000 +0200 @@ -167,6 +167,10 @@ #define ATA_I82801HB_S2 0x28258086 #define ATA_I82801HBM_S1 0x28298086 #define ATA_I82801HBM_S2 0x282a8086 +#define ATA_I82801IB_S1 0x29208086 +#define ATA_I82801IB_AH6 0x29228086 +#define ATA_I82801IB_AH4 0x29238086 +#define ATA_I82801IB_S2 0x29268086 #define ATA_I31244 0x32008086 #define ATA_ITE_ID 0x1283 --- sys/dev/ata/ata-chipset.c.orig 2007-07-09 10:50:35.000000000 +0200 +++ sys/dev/ata/ata-chipset.c 2007-07-17 20:35:35.000000000 +0200 @@ -1710,6 +1710,10 @@ { ATA_I82801HB_AH6, 0, AHCI, 0x00, ATA_SA300, "ICH8" }, { ATA_I82801HBM_S1, 0, AHCI, 0x00, ATA_SA300, "ICH8M" }, { ATA_I82801HBM_S2, 0, AHCI, 0x00, ATA_SA300, "ICH8M" }, + { ATA_I82801IB_S1, 0, AHCI, 0x00, ATA_SA300, "ICH9" }, + { ATA_I82801IB_S2, 0, AHCI, 0x00, ATA_SA300, "ICH9" }, + { ATA_I82801IB_AH4, 0, AHCI, 0x00, ATA_SA300, "ICH9" }, + { ATA_I82801IB_AH6, 0, AHCI, 0x00, ATA_SA300, "ICH9" }, { ATA_I31244, 0, 0, 0x00, ATA_SA150, "31244" }, { 0, 0, 0, 0, 0, 0}}; char buffer[64]; --Boundary-00=_Bz63GZWEvKQVUfO-- From owner-freebsd-current@FreeBSD.ORG Thu Sep 6 11:08:52 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7C5EA16A418 for ; Thu, 6 Sep 2007 11:08:52 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 346A913C45B for ; Thu, 6 Sep 2007 11:08:52 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1ITEUP-0005fC-AO for freebsd-current@freebsd.org; Thu, 06 Sep 2007 12:21:33 +0200 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 06 Sep 2007 12:21:33 +0200 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 06 Sep 2007 12:21:33 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Date: Thu, 06 Sep 2007 12:21:12 +0200 Lines: 37 Message-ID: References: <18142.47216.305394.719129@grasshopper.cs.duke.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-ripemd160; protocol="application/pgp-signature"; boundary="------------enigD0F965A5FA700546C7BAB381" X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 1.5.0.12 (X11/20060911) In-Reply-To: <18142.47216.305394.719129@grasshopper.cs.duke.edu> X-Enigmail-Version: 0.94.4.0 Sender: news Cc: freebsd-hackers@freebsd.org Subject: Re: Progress for 7.0 - the "what's cooking" page X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2007 11:08:52 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD0F965A5FA700546C7BAB381 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Andrew Gallatin wrote: >=20 > The TSO/LRO section needs a little updating. >=20 > According to find sys/dev | xargs grep -l IFCAP_TSO, TSO is present in > at least: bce, cxgb, em, ixgbe, msk, mxge, nfe, nxge, re >=20 > Based on grepping for IFCAP_LRO, LRO is currently available only in mxg= e. Ok, I've updated this information, and most of the others given in this=20 thread. Does anyone know what's going on with features like sun4v architecture=20 and superpages? --------------enigD0F965A5FA700546C7BAB381 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFG39ShldnAQVacBcgRA/gMAJ9KCDhukfvGiGZJOpDpZ5lCeR5H1wCg1sOk jApxYr48F5tkJQ3ru0Bi2Bo= =xdWD -----END PGP SIGNATURE----- --------------enigD0F965A5FA700546C7BAB381-- From owner-freebsd-current@FreeBSD.ORG Thu Sep 6 12:29:19 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DF48E16A419 for ; Thu, 6 Sep 2007 12:29:19 +0000 (UTC) (envelope-from keramida@freebsd.org) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.freebsd.org (Postfix) with ESMTP id 5967B13C4D9 for ; Thu, 6 Sep 2007 12:29:19 +0000 (UTC) (envelope-from keramida@freebsd.org) Received: from kobe.laptop (vader.bytemobile.ondsl.gr [83.235.244.135]) (authenticated bits=128) by igloo.linux.gr (8.14.1/8.14.1/Debian-8) with ESMTP id l86CSkIu011106 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 6 Sep 2007 15:29:04 +0300 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.1/8.14.1) with ESMTP id l86CSNF8001810 for ; Thu, 6 Sep 2007 15:28:41 +0300 (EEST) (envelope-from keramida@freebsd.org) Received: (from keramida@localhost) by kobe.laptop (8.14.1/8.14.1/Submit) id l86CSNJm001809 for current@freebsd.org; Thu, 6 Sep 2007 15:28:23 +0300 (EEST) (envelope-from keramida@freebsd.org) Date: Thu, 6 Sep 2007 15:28:23 +0300 From: Giorgos Keramidas To: current@freebsd.org Message-ID: <20070906122822.GA1723@kobe.laptop> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-4.076, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.32, BAYES_00 -2.60) X-Hellug-MailScanner-From: keramida@freebsd.org X-Spam-Status: No Cc: Subject: Anyone seen this panic? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2007 12:29:20 -0000 A relatively CURRENT kernel from: FreeBSD kobe 7.0-CURRENT FreeBSD 7.0-CURRENT #0: Sun Sep 2 03:46:34 EEST 2007 just panicked on me with the following backtrace: (kgdb) bt #0 doadump () at pcpu.h:195 #1 0xc05bcb0e in boot (howto=260) at /home/build/src/sys/kern/kern_shutdown.c:409 #2 0xc05bcdcb in panic (fmt=Variable "fmt" is not available. ) at /home/build/src/sys/kern/kern_shutdown.c:563 #3 0xc081bfb3 in trap_fatal (frame=0xd5e8f934, eva=3216998400) at /home/build/src/sys/i386/i386/trap.c:872 #4 0xc081c890 in trap (frame=0xd5e8f934) at /home/build/src/sys/i386/i386/trap.c:277 #5 0xc08026eb in calltrap () at /home/build/src/sys/i386/i386/exception.s:139 #6 0xc0819e4c in slow_copyout () at /home/build/src/sys/i386/i386/support.s:772 Previous frame inner to this frame (corrupt stack?) (kgdb) Does this look familiar to anyone? Line 772 of support.s is here: 767 #if defined(I586_CPU) && defined(DEV_NPX) 768 ALIGN_TEXT 769 slow_copyout: 770 #endif 771 shrl $2,%ecx 772 cld 773 rep 774 movsl 775 movb %bl,%cl 776 andb $3,%cl 777 rep 778 movsb From owner-freebsd-current@FreeBSD.ORG Thu Sep 6 16:18:54 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 52C1F16A419 for ; Thu, 6 Sep 2007 16:18:54 +0000 (UTC) (envelope-from tomdean@speakeasy.org) Received: from mail7.sea5.speakeasy.net (mail7.sea5.speakeasy.net [69.17.117.9]) by mx1.freebsd.org (Postfix) with ESMTP id 3371613C46C for ; Thu, 6 Sep 2007 16:18:54 +0000 (UTC) (envelope-from tomdean@speakeasy.org) Received: (qmail 960 invoked from network); 6 Sep 2007 15:52:13 -0000 Received: from dsl081-173-150.sea1.dsl.speakeasy.net (HELO asus.tddhome) ([64.81.173.150]) (envelope-sender ) by mail7.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 6 Sep 2007 15:52:13 -0000 Received: from asus.tddhome (localhost.tddhome [127.0.0.1]) by asus.tddhome (8.13.8/8.13.8) with ESMTP id l86FqDh8056199; Thu, 6 Sep 2007 08:52:13 -0700 (PDT) (envelope-from tomdean@asus.tddhome) Received: (from tomdean@localhost) by asus.tddhome (8.13.8/8.13.8/Submit) id l86FqCHN056196; Thu, 6 Sep 2007 08:52:12 -0700 (PDT) (envelope-from tomdean) Date: Thu, 6 Sep 2007 08:52:12 -0700 (PDT) Message-Id: <200709061552.l86FqCHN056196@asus.tddhome> From: "Thomas D. Dean" To: keramida@freebsd.org In-reply-to: <20070906122822.GA1723@kobe.laptop> (message from Giorgos Keramidas on Thu, 6 Sep 2007 15:28:23 +0300) References: <20070906122822.GA1723@kobe.laptop> Cc: current@freebsd.org Subject: Re: Anyone seen this panic? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2007 16:18:54 -0000 I see this with the wpi driver under development. The driver works OK from the local console, but, rsh ifconfig wpi0 list scan causes the panic. Something is blowing away the stack. tomdean From owner-freebsd-current@FreeBSD.ORG Thu Sep 6 17:16:55 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5766216A417; Thu, 6 Sep 2007 17:16:55 +0000 (UTC) (envelope-from bp@barryp.org) Received: from eden.barryp.org (host-42-60-230-24.midco.net [24.230.60.42]) by mx1.freebsd.org (Postfix) with ESMTP id 2DB5713C478; Thu, 6 Sep 2007 17:16:55 +0000 (UTC) (envelope-from bp@barryp.org) Received: from geo.med.und.nodak.edu ([134.129.166.11]) by eden.barryp.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ITKQy-000HIo-U5; Thu, 06 Sep 2007 11:42:25 -0500 Message-ID: <46E02DEE.1010007@barryp.org> Date: Thu, 06 Sep 2007 11:42:22 -0500 From: Barry Pederson User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: Pawel Jakub Dawidek References: <46D4EFFF.5080807@fusiongol.com> <46D5B46D.5010202@gmail.com> <46D66A23.3060108@fusiongol.com> <20070903124232.GC64967@garage.freebsd.pl> In-Reply-To: <20070903124232.GC64967@garage.freebsd.pl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Encrypted zfs? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2007 17:16:55 -0000 Pawel Jakub Dawidek wrote: > On Thu, Aug 30, 2007 at 03:56:35PM +0900, Nathan Butcher wrote: >>> AFAIK zfs is immune against device enumeration issues itself. There is a >>> nice video on YouTube showing Sun engineers setting up a ZFS pool on a >>> bunch of USB sticks. Afterwards they remove all of them, shuffle them, >>> and put them back in. No problem. >> You're correct,... only as long as the zpool is EXPORTED FIRST, and >> imported after the drives have been shuffled around. ZFS has no trouble >> piecing them back together wherever they are during an import, it seems. >> >> If you were to, say, forget to export the zpool, shutdown your system, >> shuffle the drives around, and THEN restart the system with the drives >> in the wrong places, zfs will consider the zpool unavailable. In this >> case, all the drives will be turn up as FAULTED due to "corrupted >> data"... when in reality, ZFS was set up to expect certain data to be on >> certain drives, and now it just can't find it thanks to the harddrive >> "hokey-pokey" done on it. >> >> I guess glabeling isn't really necessary, but it does prevent the above >> issue from ever occuring.... "An ounce of prevention" or something like >> that. > > You are correct, but not entirely. If you don't export the pool before > shuffling driver around, ZFS can still recognize them after reboot, but > those drives have to support GEOM::ident attribute. A disk, when asked > about this attribute, returns its serial number. If ZFS can find disk > using its name, it tries to use its ident. Not all GEOM providers > support idents. Currently only ATA disks and slices/partitions on top of > ATA disks. I've been fooling with a zpool of 8 glabeled SATA disks, 4 of which are connected to motherboard SATA ports, and 4 to SAS ports. After shutting the machine down (without exporting the pool) and shuffling disks around , it seems that the disks that were originally connected via SATA but that are now on the SAS controller show up as "UNAVAIL"/"cannot open", and doing a "zpool online tank label/750_03" (for example) doesn't have any effect. The disks really are present though, showing up in dmesg, glabel status, and able do "dd" from them. The disks that were originally on the SAS controller when the pool was created show up fine when connected to the motherboard SATA ports. Doing a "strings /boot/zfs/zpool.cache" I see that it's storing the serial numbers as described above, of the originally SATA-connected pool members, such as: path /dev/label/750_03 devid 5QD01BS6s0 but the originally SAS-connected drives don't show that "devid" (which makes sense). Does ZFS ignore the path if it thinks the device should have a certain devid? Is there a slick way to clear out the devid/serial-number from the zpool's memory? Barry From owner-freebsd-current@FreeBSD.ORG Thu Sep 6 18:45:23 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C870916A41B for ; Thu, 6 Sep 2007 18:45:23 +0000 (UTC) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.freebsd.org (Postfix) with ESMTP id A13F013C494 for ; Thu, 6 Sep 2007 18:45:23 +0000 (UTC) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.13.6) with ESMTP id l86IASvU083798; Thu, 6 Sep 2007 11:10:28 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id l86IASle083797; Thu, 6 Sep 2007 11:10:28 -0700 (PDT) (envelope-from rizzo) Date: Thu, 6 Sep 2007 11:10:28 -0700 From: Luigi Rizzo To: current@freebsd.org Message-ID: <20070906111028.A83649@xorpc.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i Cc: Subject: how to tell 64 vs 32 bit architecture ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2007 18:45:23 -0000 hi, i was wondering what is the proper way to tell a 64 vs 32 bit architecture. I see that some code in sys/ uses ' #ifdef __LP64__ ' but i am not sure if this is generic enough (ie not gcc or FreeBSD specific), and also suitable for userland (i.e. works on linux or other platforms as well). cheers luigi From owner-freebsd-current@FreeBSD.ORG Thu Sep 6 18:49:18 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D3CD416A46E for ; Thu, 6 Sep 2007 18:49:18 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.191]) by mx1.freebsd.org (Postfix) with ESMTP id 4743913C468 for ; Thu, 6 Sep 2007 18:49:18 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: by nf-out-0910.google.com with SMTP id k4so209015nfd for ; Thu, 06 Sep 2007 11:49:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:received:received:date:from:to:cc:subject:message-id:mail-followup-to:mime-version:content-type:content-disposition:user-agent; bh=AxdevVSAXZ+kA+Q5JmSYBKZqvFFTMmJ6IBnHOlE9rW8=; b=trhvB2NH7oSm7hBdHTYgchQSM3S97R+TcU8gA2iFTWH4aJzC4SOKXV411iP//XUR92LXH4Tgt4Axy5jVCtRTnV0fAr+1/gJSy2KR/DaMVu/mu9XDO6TP6HJs50jCMidp2Cvb4QW8Sailqv0xIUmfrEGKO8V5SA8lTPcEwW+p9us= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:date:from:to:cc:subject:message-id:mail-followup-to:mime-version:content-type:content-disposition:user-agent; b=YoN6KGlIau/uEmHmsg6J7YnX/d8gbcS2ay5EldXR0bnOH8JDQxEvdGYx3K+8fKjzaIC1Dc8vTx6rp5g9XbvSbK17XVpr7AjioZ4d62PwORhHQpEzDpGtqijcnEz5iIbfX0oQWpl4DTuDXP/sBhQPjmyHJq3lnaUmHSXG2kgV240= Received: by 10.86.80.5 with SMTP id d5mr799304fgb.1189104544481; Thu, 06 Sep 2007 11:49:04 -0700 (PDT) Received: from roadrunner.spoerlein.net ( [85.180.130.37]) by mx.google.com with ESMTPS id p38sm13196604fke.2007.09.06.11.49.03 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 06 Sep 2007 11:49:04 -0700 (PDT) Received: from roadrunner.spoerlein.net (localhost [127.0.0.1]) by roadrunner.spoerlein.net (8.14.1/8.14.1) with ESMTP id l86ImtIN097674; Thu, 6 Sep 2007 20:48:55 +0200 (CEST) (envelope-from uspoerlein@gmail.com) Received: (from q@localhost) by roadrunner.spoerlein.net (8.14.1/8.14.1/Submit) id l86ImtAI097673; Thu, 6 Sep 2007 20:48:55 +0200 (CEST) (envelope-from uspoerlein@gmail.com) Date: Thu, 6 Sep 2007 20:48:53 +0200 From: Ulrich Spoerlein To: current@freebsd.org Message-ID: <20070906184853.GB90021@roadrunner.spoerlein.net> Mail-Followup-To: current@freebsd.org, pjd@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.16 (2007-06-09) Cc: pjd@freebsd.org Subject: ZFS not caching right? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2007 18:49:19 -0000 Hi, it's me again with another stupid question, ever since I switched my /usr and /home to ZFS, the system has become _very_ unresponsive under load. This is not because of CPU load, but I/O load. This is on laptop with a lousy 4800RPM hard disk and 1 GB RAM. After boot, the system is snappy as ever up to a certain point. If I build a large port for example it takes less than an hour to bring the system to a crawl. Right now, I'm building OOo in the background and tried to start amarok. This took, like 3 minutes or more while the disk is going nuts # zpool iostat 1 tank 12.4G 14.8G 100 0 12.4M 0 tank 12.4G 14.8G 47 42 5.45M 387K tank 12.4G 14.8G 27 85 3.34M 392K tank 12.4G 14.8G 38 27 4.83M 129K tank 12.4G 14.8G 47 46 5.94M 864K tank 12.4G 14.8G 43 47 5.37M 242K tank 12.4G 14.8G 84 0 10.2M 0 tank 12.4G 14.8G 63 0 7.92M 0 tank 12.4G 14.8G 87 0 10.9M 0 tank 12.4G 14.8G 73 0 9.16M 0 tank 12.4G 14.8G 35 72 4.46M 678K tank 12.4G 14.8G 19 73 2.29M 997K tank 12.4G 14.8G 71 3 8.91M 3.96K tank 12.4G 14.8G 91 0 11.4M 0 tank 12.4G 14.8G 84 0 10.5M 0 tank 12.4G 14.8G 54 88 6.81M 403K tank 12.4G 14.8G 77 0 9.65M 0 tank 12.4G 14.8G 82 0 10.3M 0 The mem and cache settings as shown by systat -vm are as follows 7 users Load 1.01 1.12 1.15 Sep 6 20:42 Mem:KB REAL VIRTUAL VN PAGER SWAP PAGER Tot Share Tot Share Free in out in out Act 515148 55612 1283636 118028 138308 count 6 All 713292 62660 3724916 139796 pages 2 27 Proc: Interrupts r p d s w Csw Trp Sys Int Sof Flt 322 cow 370 total 4 1 143 3740 6830 20k 371 371 5797 4092 zfod 100 clk irq0 58 ozfod atkbd0 1 13.0%Sys 0.3%Intr 6.7%User 74.9%Nice 5.1%Idle 1%ozfod 128 rtc irq8 | | | | | | | | | | | daefr pcm0 iwi0+ =======>>>------------------------------------- 4016 prcfr 106 cbb0 bfe0+ 3 dtbuf 4824 totfr 28 ata0 irq14 Namei Name-cache Dir-cache 50000 desvn 4 react 8 ata1 irq15 Calls hits % hits % 30904 numvn pdwak psm0 irq12 38614 38555 100 17491 frevn pdpgs 6 intrn Disks ad0 da0 pass0 196884 wire KB/t 8.36 0.00 0.00 552976 act tps 27 0 0 131128 inact MB/s 0.22 0.00 0.00 22796 cache %busy 9 0 0 115512 free 110176 buf Yesterday, the cache value was hovering at 900 and not improving much, this is abnormal, right? I "tuned" ZFS with the following settings as recommended by the Wiki and on -current vfs.zfs.zil_disable="1" vfs.zfs.prefetch_disable="1" vfs.zfs.arc_max="128*1024*1024" Is the tremendous amount of disk reading due to ZFS' nature or is it VM related? Cheers, Ulrich Spoerlein -- It is better to remain silent and be thought a fool, than to speak, and remove all doubt. From owner-freebsd-current@FreeBSD.ORG Thu Sep 6 18:57:11 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 664EE16A417; Thu, 6 Sep 2007 18:57:11 +0000 (UTC) (envelope-from bmah@freebsd.org) Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by mx1.freebsd.org (Postfix) with ESMTP id 4F59113C458; Thu, 6 Sep 2007 18:57:11 +0000 (UTC) (envelope-from bmah@freebsd.org) Received: from dhcp-2-119.packetdesign.com (hornet.kitchenlab.org [64.142.31.105]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id l86Iuup3004415 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Sep 2007 11:56:56 -0700 Message-ID: <46E04D6D.9090501@freebsd.org> Date: Thu, 06 Sep 2007 11:56:45 -0700 From: "Bruce A. Mah" User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Ivan Voras References: <18142.47216.305394.719129@grasshopper.cs.duke.edu> In-Reply-To: X-Enigmail-Version: 0.95.3 OpenPGP: id=5ba052c3 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig70EA247CB341381AE61A907E" Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: Progress for 7.0 - the "what's cooking" page X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2007 18:57:11 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig70EA247CB341381AE61A907E Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable If memory serves me right, Ivan Voras wrote: > Andrew Gallatin wrote: >> The TSO/LRO section needs a little updating. >> >> According to find sys/dev | xargs grep -l IFCAP_TSO, TSO is present in= >> at least: bce, cxgb, em, ixgbe, msk, mxge, nfe, nxge, re >> >> Based on grepping for IFCAP_LRO, LRO is currently available only in mx= ge. >=20 > Ok, I've updated this information, and most of the others given in this= =20 > thread. >=20 > Does anyone know what's going on with features like sun4v architecture = > and superpages? (Replying to a random message in this thread.) As you work on this, consider submitting changes to the release notes in case those of us who work on them have forgotten something. The audience and purpose of the release notes is a little different from your Web page, but some appropriate of overlap is a Good Thing (TM). Thanks! Bruce. --------------enig70EA247CB341381AE61A907E Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG4E1t2MoxcVugUsMRAjttAKDazpTAVsdbqEES5kvM0JcTO4Ve2gCgycsW JUvxwNAZF/CTYaoqxZQ3ZFA= =SGcA -----END PGP SIGNATURE----- --------------enig70EA247CB341381AE61A907E-- From owner-freebsd-current@FreeBSD.ORG Thu Sep 6 19:06:50 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 587FE16A41B for ; Thu, 6 Sep 2007 19:06:50 +0000 (UTC) (envelope-from biancalana@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.176]) by mx1.freebsd.org (Postfix) with ESMTP id 1003C13C467 for ; Thu, 6 Sep 2007 19:06:49 +0000 (UTC) (envelope-from biancalana@gmail.com) Received: by py-out-1112.google.com with SMTP id u77so501570pyb for ; Thu, 06 Sep 2007 12:06:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; bh=9+vC0swq9kxjRIc9z3DUOBAm+SK/pkl6uoFzDmnqmW0=; b=WIA8LPczOLQwS+Y+mcR8CJWVKJ7JOivD9AzVwlypXVQRmRbmqGVhcKDtam37n0fnyb4h/oLRFjA66+GjhqkkAOakVSzYrHMsVPI/7jHpqP85arEfAOZsNwhyWUe99m3I0UQm8h3Fuq2dbv5cFoGHHEMbOEbFgk0tsE7Uo+xkZZQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=gzUUgXrlPhnfUmSymPry9L89+mNHPPmlSWOBdEKEtRfj63rLs2xeitjKVrqArwnw5rkRnTbmPhUkMn286wkWMiN7eI173p0m5o7IERZcXhW6CWjU8EQN9qs1kwniejWMCxKxYNunzEZVDcZmGbgrhOKyOtoxOt2xwV7d+whubuc= Received: by 10.64.184.16 with SMTP id h16mr1664814qbf.1189103851862; Thu, 06 Sep 2007 11:37:31 -0700 (PDT) Received: by 10.64.233.13 with HTTP; Thu, 6 Sep 2007 11:37:31 -0700 (PDT) Message-ID: <8e10486b0709061137x35a1392bqc28169b1fae1bc01@mail.gmail.com> Date: Thu, 6 Sep 2007 15:37:31 -0300 From: "Alexandre Biancalana" To: current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: libexec/ld-elf.so.1: /lib/libc.so.7: version FBSD_1.0 required by ./gengtype not defined X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2007 19:06:50 -0000 Hi list, I installed one with -CURRENT using the following 200704-ZFS snapshot. After csup the sources, trying to update the buildworld stops with the following error: cc -O2 -fno-strict-aliasing -pipe -I. -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/usr\" -I/usr/obj/usr/src/gnu/usr.bin/cc/cc_tools/../cc_tools -I/usr/src/gnu/usr.bin/cc/cc_tools/../cc_tools -I/usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc -I/usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/config -I/usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/include -I/usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/libcpp/include -I/usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/libdecnumber -g -DGENERATOR_FILE -DHAVE_CONFIG_H -o gengtype gengtype.ogengtype-yacc+%DIKED.o gengtype-lex.o errors.o libiberty.a ./gengtype /libexec/ld-elf.so.1: /lib/libc.so.7: version FBSD_1.0 required by ./gengtype not defined *** Error code 1 Stop in /usr/src/gnu/usr.bin/cc/cc_tools. *** Error code 1 Stop in /usr/src/gnu/usr.bin/cc. *** Error code 1 Stop in /usr/src/gnu/usr.bin. *** Error code 1 Stop in /usr/src/gnu. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. Any hints ?! Regards, From owner-freebsd-current@FreeBSD.ORG Thu Sep 6 19:50:45 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E62D116A418 for ; Thu, 6 Sep 2007 19:50:45 +0000 (UTC) (envelope-from rottled@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.184]) by mx1.freebsd.org (Postfix) with ESMTP id 78D4913C49D for ; Thu, 6 Sep 2007 19:50:45 +0000 (UTC) (envelope-from rottled@gmail.com) Received: by nf-out-0910.google.com with SMTP id k4so222401nfd for ; Thu, 06 Sep 2007 12:50:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=x4IsJ78f+dNc98XUxN5CIiQvfIrn/vR92LSCgdjPtlI=; b=RZrEHTMSnaDVR9VzW486k/ziBymYIiQcl3UXp5+UAlJSOSPBEqR4m7i/JBPRlsVuTk0u7gRGVUbqI3R0tCOuRd9GUBAluzfaU4fjAPEabVS+iIKQJYcr2uWRIqFNCg9jWNnRRF8y6JU4PWteygUamLeMpOQfYk9/b63smvpBL2s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=mCZ8jO78fJqLAtAVfnJ7Dmzk3Jgrw3LJghP1HPJ7bXtfev51RiJA9gLmKlmFd0haM6/PL14ltL+J3sorNZuJgFBdO+unhdkc1jbWfSR/4hA16mKxKyQp+vTS7lLfbgj/bLNm/5eN2sVdy2fzPzmceLhQBa3NhV+g+WZTdVf76CU= Received: by 10.86.84.5 with SMTP id h5mr826625fgb.1189106752542; Thu, 06 Sep 2007 12:25:52 -0700 (PDT) Received: by 10.86.25.18 with HTTP; Thu, 6 Sep 2007 12:25:52 -0700 (PDT) Message-ID: <54b90fdf0709061225q48af11c2yca8d330eff514159@mail.gmail.com> Date: Thu, 6 Sep 2007 15:25:52 -0400 From: Yan To: "Luigi Rizzo" In-Reply-To: <20070906111028.A83649@xorpc.icir.org> MIME-Version: 1.0 References: <20070906111028.A83649@xorpc.icir.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: current@freebsd.org Subject: Re: how to tell 64 vs 32 bit architecture ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2007 19:50:46 -0000 Perhaps "if(sizeof(void*)==4) { /* 32 */} else if(sizeof(void*) ==8) { /* 64 */ }" ? Or do you need something for the preprocessor? -yan On 9/6/07, Luigi Rizzo wrote: > > hi, > i was wondering what is the proper way to tell a 64 vs 32 bit > architecture. > > I see that some code in sys/ uses ' #ifdef __LP64__ ' but i am not > sure if this is generic enough (ie not gcc or FreeBSD specific), > and also suitable for userland (i.e. works on linux or other platforms > as well). > > cheers > luigi > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Thu Sep 6 19:55:55 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5256A16A417 for ; Thu, 6 Sep 2007 19:55:55 +0000 (UTC) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.freebsd.org (Postfix) with ESMTP id 2C68D13C46B for ; Thu, 6 Sep 2007 19:55:55 +0000 (UTC) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.13.6) with ESMTP id l86JsdMV084754; Thu, 6 Sep 2007 12:54:39 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id l86Jsdki084753; Thu, 6 Sep 2007 12:54:39 -0700 (PDT) (envelope-from rizzo) Date: Thu, 6 Sep 2007 12:54:39 -0700 From: Luigi Rizzo To: Yan Message-ID: <20070906125439.A84696@xorpc.icir.org> References: <20070906111028.A83649@xorpc.icir.org> <54b90fdf0709061225q48af11c2yca8d330eff514159@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <54b90fdf0709061225q48af11c2yca8d330eff514159@mail.gmail.com>; from rottled@gmail.com on Thu, Sep 06, 2007 at 03:25:52PM -0400 Cc: current@freebsd.org Subject: Re: how to tell 64 vs 32 bit architecture ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2007 19:55:55 -0000 On Thu, Sep 06, 2007 at 03:25:52PM -0400, Yan wrote: > Perhaps "if(sizeof(void*)==4) { /* 32 */} else if(sizeof(void*) ==8) { /* 64 > */ }" ? > > Or do you need something for the preprocessor? preprocessor. cheers luigi > -yan > > On 9/6/07, Luigi Rizzo wrote: > > > > hi, > > i was wondering what is the proper way to tell a 64 vs 32 bit > > architecture. > > > > I see that some code in sys/ uses ' #ifdef __LP64__ ' but i am not > > sure if this is generic enough (ie not gcc or FreeBSD specific), > > and also suitable for userland (i.e. works on linux or other platforms > > as well). > > > > cheers > > luigi > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Thu Sep 6 20:08:21 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8A4D716A41A for ; Thu, 6 Sep 2007 20:08:21 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.freebsd.org (Postfix) with ESMTP id DDF9113C478 for ; Thu, 6 Sep 2007 20:08:20 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 6194445E97; Thu, 6 Sep 2007 22:08:18 +0200 (CEST) Received: from localhost (154.81.datacomsa.pl [195.34.81.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id ED16845EB2; Thu, 6 Sep 2007 22:08:11 +0200 (CEST) Date: Thu, 6 Sep 2007 22:06:52 +0200 From: Pawel Jakub Dawidek To: Barry Pederson Message-ID: <20070906200652.GB33420@garage.freebsd.pl> References: <46D4EFFF.5080807@fusiongol.com> <46D5B46D.5010202@gmail.com> <46D66A23.3060108@fusiongol.com> <20070903124232.GC64967@garage.freebsd.pl> <46E02DEE.1010007@barryp.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GPJrCs/72TxItFYR" Content-Disposition: inline In-Reply-To: <46E02DEE.1010007@barryp.org> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-2.6 required=3.0 tests=BAYES_00 autolearn=ham version=3.0.4 Cc: freebsd-current@freebsd.org Subject: Re: Encrypted zfs? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2007 20:08:21 -0000 --GPJrCs/72TxItFYR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Sep 06, 2007 at 11:42:22AM -0500, Barry Pederson wrote: > Pawel Jakub Dawidek wrote: > >On Thu, Aug 30, 2007 at 03:56:35PM +0900, Nathan Butcher wrote: > >>>AFAIK zfs is immune against device enumeration issues itself. There is= a > >>>nice video on YouTube showing Sun engineers setting up a ZFS pool on a > >>>bunch of USB sticks. Afterwards they remove all of them, shuffle them, > >>>and put them back in. No problem. > >>You're correct,... only as long as the zpool is EXPORTED FIRST, and > >>imported after the drives have been shuffled around. ZFS has no trouble > >>piecing them back together wherever they are during an import, it seems. > >> > >>If you were to, say, forget to export the zpool, shutdown your system, > >>shuffle the drives around, and THEN restart the system with the drives > >>in the wrong places, zfs will consider the zpool unavailable. In this > >>case, all the drives will be turn up as FAULTED due to "corrupted > >>data"... when in reality, ZFS was set up to expect certain data to be on > >>certain drives, and now it just can't find it thanks to the harddrive > >>"hokey-pokey" done on it. > >> > >>I guess glabeling isn't really necessary, but it does prevent the above > >> issue from ever occuring.... "An ounce of prevention" or something like > >>that. > > > >You are correct, but not entirely. If you don't export the pool before > >shuffling driver around, ZFS can still recognize them after reboot, but > >those drives have to support GEOM::ident attribute. A disk, when asked > >about this attribute, returns its serial number. If ZFS can find disk > >using its name, it tries to use its ident. Not all GEOM providers > >support idents. Currently only ATA disks and slices/partitions on top of > >ATA disks. >=20 > I've been fooling with a zpool of 8 glabeled SATA disks, 4 of which are= =20 > connected to motherboard SATA ports, and 4 to SAS ports. >=20 > After shutting the machine down (without exporting the pool) and=20 > shuffling disks around , it seems that the disks that were originally=20 > connected via SATA but that are now on the SAS controller show up as=20 > "UNAVAIL"/"cannot open", and doing a "zpool online tank label/750_03"=20 > (for example) doesn't have any effect. The disks really are present=20 > though, showing up in dmesg, glabel status, and able do "dd" from them. >=20 > The disks that were originally on the SAS controller when the pool was=20 > created show up fine when connected to the motherboard SATA ports. >=20 > Doing a "strings /boot/zfs/zpool.cache" I see that it's storing the=20 > serial numbers as described above, of the originally SATA-connected pool= =20 > members, such as: >=20 > path > /dev/label/750_03 > devid > 5QD01BS6s0 >=20 > but the originally SAS-connected drives don't show that "devid" (which=20 > makes sense). >=20 > Does ZFS ignore the path if it thinks the device should have a certain=20 > devid? Is there a slick way to clear out the devid/serial-number from=20 > the zpool's memory? Have you tried zpool export/import? --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --GPJrCs/72TxItFYR Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFG4F3cForvXbEpPzQRAioMAJ4oo5gmxj21pRs48zqxJf3C3w0tIACggh2W hYi69aZEtMXipHtGSRQAvBE= =3ytc -----END PGP SIGNATURE----- --GPJrCs/72TxItFYR-- From owner-freebsd-current@FreeBSD.ORG Thu Sep 6 20:33:25 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2A4DA16A418; Thu, 6 Sep 2007 20:33:25 +0000 (UTC) (envelope-from bp@barryp.org) Received: from eden.barryp.org (host-42-60-230-24.midco.net [24.230.60.42]) by mx1.freebsd.org (Postfix) with ESMTP id 01E7713C46B; Thu, 6 Sep 2007 20:33:24 +0000 (UTC) (envelope-from bp@barryp.org) Received: from geo.med.und.nodak.edu ([134.129.166.11]) by eden.barryp.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ITO2W-000HqS-0j; Thu, 06 Sep 2007 15:33:24 -0500 Message-ID: <46E06411.4040206@barryp.org> Date: Thu, 06 Sep 2007 15:33:21 -0500 From: Barry Pederson User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: Pawel Jakub Dawidek References: <46D4EFFF.5080807@fusiongol.com> <46D5B46D.5010202@gmail.com> <46D66A23.3060108@fusiongol.com> <20070903124232.GC64967@garage.freebsd.pl> <46E02DEE.1010007@barryp.org> <20070906200652.GB33420@garage.freebsd.pl> In-Reply-To: <20070906200652.GB33420@garage.freebsd.pl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Encrypted zfs? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2007 20:33:25 -0000 Pawel Jakub Dawidek wrote: >> >> Does ZFS ignore the path if it thinks the device should have a certain >> devid? Is there a slick way to clear out the devid/serial-number from >> the zpool's memory? > > Have you tried zpool export/import? Yes, that works fine. I was wondering if there was a way to do it that didn't involve rebooting (I'm using that pool as root) or otherwise taking the pool offline. I guess this isn't something that a person really needs to be able to do, I'm just poking around to find out what the limitations or tricks are to how ZFS deals with things. Moving a disk from a SATA controller to a non-SATA controller seemed like something worth trying. Barry From owner-freebsd-current@FreeBSD.ORG Thu Sep 6 22:17:22 2007 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7DC1A16A41A for ; Thu, 6 Sep 2007 22:17:22 +0000 (UTC) (envelope-from nate@root.org) Received: from root.org (root.org [67.118.192.226]) by mx1.freebsd.org (Postfix) with ESMTP id 47FE913C46C for ; Thu, 6 Sep 2007 22:17:22 +0000 (UTC) (envelope-from nate@root.org) Received: (qmail 68262 invoked from network); 6 Sep 2007 22:17:23 -0000 Received: from ppp-71-139-1-224.dsl.snfc21.pacbell.net (HELO ?10.0.0.15?) (nate-mail@71.139.1.224) by root.org with ESMTPA; 6 Sep 2007 22:17:23 -0000 Message-ID: <46E07AAF.2060000@root.org> Date: Thu, 06 Sep 2007 15:09:51 -0700 From: Nate Lawson User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: current@FreeBSD.org References: <46E0777A.8070901@root.org> In-Reply-To: <46E0777A.8070901@root.org> X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: acpi@FreeBSD.ORG Subject: Re: PATCH: ecng for 6.x and 7.x X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2007 22:17:22 -0000 Nate Lawson wrote: > I've done some major rework on the EC driver. This should help with > various problems, including timeouts while checking battery status or > temperature. The attached patches are for 6.x and 7.x. Please test and > let me know if you get any new errors on dmesg or if it fixes things for > you (especially HP/Compaq laptop owners). > > If you still have problems, try setting each of these tunables > individually and then both together (i.e., in /boot/loader.conf). Note > that this will be four (4) test runs total, so don't just set both and > say it doesn't work. > > debug.acpi.ec.burst="1" > debug.acpi.ec.polled="1" > > I've tested both patches on a Panasonic Y4 and UnnamedOEM laptop, no > problems in either regular or burst mode. > > > Commit message: > Rewrite the EC driver event model. The main goal is to avoid > polling/interrupt-driven fallback and instead use polling only during > boot and pure interrupt-driven mode after boot. Polled mode could be > relegated completely to a legacy role if we could enable interrupts > during boot. Polled mode can be forced after boot by setting > debug.acpi.ec.polled="1", i.e. if there are timeouts. One minor note -- power off shutdown (shutdown/halt -p) is turned into a (safe) reboot with this patch. I have tested the fix, which is just to force polled mode during shutdown as well. I don't have time to re-roll the patch today but will send tomorrow. Please test the patch as posted, ignoring that minor issue. The test results during normal use are still valid. -- Nate From owner-freebsd-current@FreeBSD.ORG Thu Sep 6 22:23:00 2007 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6408D16A41B for ; Thu, 6 Sep 2007 22:23:00 +0000 (UTC) (envelope-from nate@root.org) Received: from root.org (root.org [67.118.192.226]) by mx1.freebsd.org (Postfix) with ESMTP id 46DFD13C45A for ; Thu, 6 Sep 2007 22:23:00 +0000 (UTC) (envelope-from nate@root.org) Received: (qmail 65524 invoked from network); 6 Sep 2007 21:56:18 -0000 Received: from ppp-71-139-1-224.dsl.snfc21.pacbell.net (HELO ?10.0.5.18?) (nate-mail@71.139.1.224) by root.org with ESMTPA; 6 Sep 2007 21:56:18 -0000 Message-ID: <46E0777A.8070901@root.org> Date: Thu, 06 Sep 2007 14:56:10 -0700 From: Nate Lawson User-Agent: Thunderbird 2.0.0.6 (X11/20070810) MIME-Version: 1.0 To: current@FreeBSD.org X-Enigmail-Version: 0.95.0 Content-Type: multipart/mixed; boundary="------------020803020602030709060703" Cc: acpi@FreeBSD.ORG Subject: PATCH: ecng for 6.x and 7.x X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2007 22:23:00 -0000 This is a multi-part message in MIME format. --------------020803020602030709060703 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I've done some major rework on the EC driver. This should help with various problems, including timeouts while checking battery status or temperature. The attached patches are for 6.x and 7.x. Please test and let me know if you get any new errors on dmesg or if it fixes things for you (especially HP/Compaq laptop owners). If you still have problems, try setting each of these tunables individually and then both together (i.e., in /boot/loader.conf). Note that this will be four (4) test runs total, so don't just set both and say it doesn't work. debug.acpi.ec.burst="1" debug.acpi.ec.polled="1" I've tested both patches on a Panasonic Y4 and UnnamedOEM laptop, no problems in either regular or burst mode. Commit message: Rewrite the EC driver event model. The main goal is to avoid polling/interrupt-driven fallback and instead use polling only during boot and pure interrupt-driven mode after boot. Polled mode could be relegated completely to a legacy role if we could enable interrupts during boot. Polled mode can be forced after boot by setting debug.acpi.ec.polled="1", i.e. if there are timeouts. - Use polling only during boot or if requested by the user. Otherwise, use a generation count of GPEs, incremented atomically. This prevents an old status value from being used if the EC is really slow and the same condition (i.e. multiple IBEs for a write transaction) is being checked. - Check for and run the query handler directly if the SCI bit is set in the status register during boot. Previously, the query handler wouldn't run until interrupts were finally enabled late in boot. - During boot and after starting a command, check if the event appears to already have occurred before we even start waiting. If so, it's possible the EC is very slow and we might accept an old status value. Print a warning in this case. Once we've booted, interrupt-driven mode should work just fine but polled mode will be unreliable. There's not much more we can do about this until interrupts are enabled during boot. - Hold the sx lock over the entire query handler, since the GPE handler no longer grabs any lock - Use upper-case hex for the _Qxx method - Use device_printf for errors, don't hide them under verbose - Increase default total timeout to 750 ms and polling interval to 5 us. - Don't pass the status value via the softc. Just read it directly. - Remove the mutex. We use the sx lock for transaction serialization with the query handler. - Remove the Intel copyright notice as no code of theirs was ever present in this file (verified against rev 1.1) -Nate --------------020803020602030709060703 Content-Type: text/x-patch; name="ecng-6a.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ecng-6a.diff" Index: sys/dev/acpica/acpi_ec.c =================================================================== RCS file: /home/ncvs/src/sys/dev/acpica/acpi_ec.c,v retrieving revision 1.65.2.3 diff -u -r1.65.2.3 acpi_ec.c --- sys/dev/acpica/acpi_ec.c 4 Sep 2007 22:40:39 -0000 1.65.2.3 +++ sys/dev/acpica/acpi_ec.c 6 Sep 2007 21:16:14 -0000 @@ -1,5 +1,5 @@ /*- - * Copyright (c) 2003 Nate Lawson + * Copyright (c) 2003-2007 Nate Lawson * Copyright (c) 2000 Michael Smith * Copyright (c) 2000 BSDi * All rights reserved. @@ -25,115 +25,6 @@ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. */ -/*- - ****************************************************************************** - * - * 1. Copyright Notice - * - * Some or all of this work - Copyright (c) 1999, Intel Corp. All rights - * reserved. - * - * 2. License - * - * 2.1. This is your license from Intel Corp. under its intellectual property - * rights. You may have additional license terms from the party that provided - * you this software, covering your right to use that party's intellectual - * property rights. - * - * 2.2. Intel grants, free of charge, to any person ("Licensee") obtaining a - * copy of the source code appearing in this file ("Covered Code") an - * irrevocable, perpetual, worldwide license under Intel's copyrights in the - * base code distributed originally by Intel ("Original Intel Code") to copy, - * make derivatives, distribute, use and display any portion of the Covered - * Code in any form, with the right to sublicense such rights; and - * - * 2.3. Intel grants Licensee a non-exclusive and non-transferable patent - * license (with the right to sublicense), under only those claims of Intel - * patents that are infringed by the Original Intel Code, to make, use, sell, - * offer to sell, and import the Covered Code and derivative works thereof - * solely to the minimum extent necessary to exercise the above copyright - * license, and in no event shall the patent license extend to any additions - * to or modifications of the Original Intel Code. No other license or right - * is granted directly or by implication, estoppel or otherwise; - * - * The above copyright and patent license is granted only if the following - * conditions are met: - * - * 3. Conditions - * - * 3.1. Redistribution of Source with Rights to Further Distribute Source. - * Redistribution of source code of any substantial portion of the Covered - * Code or modification with rights to further distribute source must include - * the above Copyright Notice, the above License, this list of Conditions, - * and the following Disclaimer and Export Compliance provision. In addition, - * Licensee must cause all Covered Code to which Licensee contributes to - * contain a file documenting the changes Licensee made to create that Covered - * Code and the date of any change. Licensee must include in that file the - * documentation of any changes made by any predecessor Licensee. Licensee - * must include a prominent statement that the modification is derived, - * directly or indirectly, from Original Intel Code. - * - * 3.2. Redistribution of Source with no Rights to Further Distribute Source. - * Redistribution of source code of any substantial portion of the Covered - * Code or modification without rights to further distribute source must - * include the following Disclaimer and Export Compliance provision in the - * documentation and/or other materials provided with distribution. In - * addition, Licensee may not authorize further sublicense of source of any - * portion of the Covered Code, and must include terms to the effect that the - * license from Licensee to its licensee is limited to the intellectual - * property embodied in the software Licensee provides to its licensee, and - * not to intellectual property embodied in modifications its licensee may - * make. - * - * 3.3. Redistribution of Executable. Redistribution in executable form of any - * substantial portion of the Covered Code or modification must reproduce the - * above Copyright Notice, and the following Disclaimer and Export Compliance - * provision in the documentation and/or other materials provided with the - * distribution. - * - * 3.4. Intel retains all right, title, and interest in and to the Original - * Intel Code. - * - * 3.5. Neither the name Intel nor any other trademark owned or controlled by - * Intel shall be used in advertising or otherwise to promote the sale, use or - * other dealings in products derived from or relating to the Covered Code - * without prior written authorization from Intel. - * - * 4. Disclaimer and Export Compliance - * - * 4.1. INTEL MAKES NO WARRANTY OF ANY KIND REGARDING ANY SOFTWARE PROVIDED - * HERE. ANY SOFTWARE ORIGINATING FROM INTEL OR DERIVED FROM INTEL SOFTWARE - * IS PROVIDED "AS IS," AND INTEL WILL NOT PROVIDE ANY SUPPORT, ASSISTANCE, - * INSTALLATION, TRAINING OR OTHER SERVICES. INTEL WILL NOT PROVIDE ANY - * UPDATES, ENHANCEMENTS OR EXTENSIONS. INTEL SPECIFICALLY DISCLAIMS ANY - * IMPLIED WARRANTIES OF MERCHANTABILITY, NONINFRINGEMENT AND FITNESS FOR A - * PARTICULAR PURPOSE. - * - * 4.2. IN NO EVENT SHALL INTEL HAVE ANY LIABILITY TO LICENSEE, ITS LICENSEES - * OR ANY OTHER THIRD PARTY, FOR ANY LOST PROFITS, LOST DATA, LOSS OF USE OR - * COSTS OF PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES, OR FOR ANY INDIRECT, - * SPECIAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THIS AGREEMENT, UNDER ANY - * CAUSE OF ACTION OR THEORY OF LIABILITY, AND IRRESPECTIVE OF WHETHER INTEL - * HAS ADVANCE NOTICE OF THE POSSIBILITY OF SUCH DAMAGES. THESE LIMITATIONS - * SHALL APPLY NOTWITHSTANDING THE FAILURE OF THE ESSENTIAL PURPOSE OF ANY - * LIMITED REMEDY. - * - * 4.3. Licensee shall not export, either directly or indirectly, any of this - * software or system incorporating such software without first obtaining any - * required license or other approval from the U. S. Department of Commerce or - * any other agency or department of the United States Government. In the - * event Licensee exports any such software from the United States or - * re-exports any such software from a foreign destination, Licensee shall - * ensure that the distribution and export/re-export of the software is in - * compliance with all laws, regulations, orders, or other restrictions of the - * U.S. Export Administration Regulations. Licensee agrees that neither it nor - * any of its subsidiaries will export/re-export any technical data, process, - * software, or service, directly or indirectly, to any country for which the - * United States government or any agency thereof requires an export license, - * other governmental approval, or letter of assurance, without first obtaining - * such license, approval or letter. - * - *****************************************************************************/ #include __FBSDID("$FreeBSD$"); @@ -142,9 +33,9 @@ #include #include #include +#include #include #include -#include #include #include @@ -188,15 +79,15 @@ * | | | +--------- Burst Mode Enabled? * | | +----------- SCI Event? * | +------------- SMI Event? - * +--------------- + * +--------------- * */ typedef UINT8 EC_STATUS; #define EC_FLAG_OUTPUT_BUFFER ((EC_STATUS) 0x01) #define EC_FLAG_INPUT_BUFFER ((EC_STATUS) 0x02) +#define EC_FLAG_DATA_IS_CMD ((EC_STATUS) 0x08) #define EC_FLAG_BURST_MODE ((EC_STATUS) 0x10) -#define EC_FLAG_SCI ((EC_STATUS) 0x20) /* * EC_EVENT: @@ -208,6 +99,10 @@ #define EC_EVENT_OUTPUT_BUFFER_FULL ((EC_EVENT) 0x01) #define EC_EVENT_INPUT_BUFFER_EMPTY ((EC_EVENT) 0x02) #define EC_EVENT_SCI ((EC_EVENT) 0x20) +#define EC_EVENT_SMI ((EC_EVENT) 0x40) + +/* Data byte returned after burst enable indicating it was successful. */ +#define EC_BURST_ACK 0x90 /* * Register access primitives @@ -227,11 +122,11 @@ /* Embedded Controller Boot Resources Table (ECDT) */ typedef struct { ACPI_TABLE_HEADER header; - ACPI_GENERIC_ADDRESS control; - ACPI_GENERIC_ADDRESS data; - UINT32 uid; - UINT8 gpe_bit; - char ec_id[0]; + ACPI_GENERIC_ADDRESS Control; + ACPI_GENERIC_ADDRESS Data; + UINT32 Uid; + UINT8 Gpe; + char Id[0]; } ACPI_TABLE_ECDT; /* Additional params to pass from the probe routine */ @@ -243,7 +138,7 @@ }; /* Indicate that this device has already been probed via ECDT. */ -#define DEV_ECDT(x) (acpi_get_magic(x) == (int)&acpi_ec_devclass) +#define DEV_ECDT(x) (acpi_get_magic(x) == (uintptr_t)&acpi_ec_devclass) /* * Driver softc. @@ -254,7 +149,6 @@ int ec_uid; ACPI_HANDLE ec_gpehandle; UINT8 ec_gpebit; - UINT8 ec_csrvalue; int ec_data_rid; struct resource *ec_data_res; @@ -268,6 +162,9 @@ int ec_glk; int ec_glkhandle; + int ec_burstactive; + int ec_sci_pend; + u_int ec_gencount; }; /* @@ -277,11 +174,11 @@ */ #define EC_LOCK_TIMEOUT 1000 -/* Default interval in microseconds for the status polling loop. */ -#define EC_POLL_DELAY 10 +/* Default delay in microseconds between each run of the status polling loop. */ +#define EC_POLL_DELAY 5 -/* Total time in ms spent in the poll loop waiting for a response. */ -#define EC_POLL_TIMEOUT 100 +/* Total time in ms spent waiting for a response from EC. */ +#define EC_TIMEOUT 750 #define EVENT_READY(event, status) \ (((event) == EC_EVENT_OUTPUT_BUFFER_FULL && \ @@ -289,36 +186,46 @@ ((event) == EC_EVENT_INPUT_BUFFER_EMPTY && \ ((status) & EC_FLAG_INPUT_BUFFER) == 0)) -static int ec_poll_timeout = EC_POLL_TIMEOUT; -TUNABLE_INT("hw.acpi.ec.poll_timeout", &ec_poll_timeout); - ACPI_SERIAL_DECL(ec, "ACPI embedded controller"); -static __inline ACPI_STATUS +SYSCTL_DECL(_debug_acpi); +SYSCTL_NODE(_debug_acpi, OID_AUTO, ec, CTLFLAG_RD, NULL, "EC debugging"); + +static int ec_burst_mode; +TUNABLE_INT("debug.acpi.ec.burst", &ec_burst_mode); +SYSCTL_INT(_debug_acpi_ec, OID_AUTO, burst, CTLFLAG_RW, &ec_burst_mode, 0, + "Enable use of burst mode (faster for nearly all systems)"); +static int ec_polled_mode; +TUNABLE_INT("debug.acpi.ec.polled", &ec_polled_mode); +SYSCTL_INT(_debug_acpi_ec, OID_AUTO, polled, CTLFLAG_RW, &ec_polled_mode, 0, + "Force use of polled mode (only if interrupt mode doesn't work)"); +static int ec_timeout = EC_TIMEOUT; +TUNABLE_INT("debug.acpi.ec.timeout", &ec_timeout); +SYSCTL_INT(_debug_acpi_ec, OID_AUTO, timeout, CTLFLAG_RW, &ec_timeout, + EC_TIMEOUT, "Total time spent waiting for a response (poll+sleep)"); + +static ACPI_STATUS EcLock(struct acpi_ec_softc *sc) { ACPI_STATUS status; - /* Always acquire the exclusive lock. */ + /* If _GLK is non-zero, acquire the global lock. */ status = AE_OK; - ACPI_SERIAL_BEGIN(ec); - - /* If _GLK is non-zero, also acquire the global lock. */ if (sc->ec_glk) { status = AcpiAcquireGlobalLock(EC_LOCK_TIMEOUT, &sc->ec_glkhandle); if (ACPI_FAILURE(status)) - ACPI_SERIAL_END(ec); + return (status); } - + ACPI_SERIAL_BEGIN(ec); return (status); } -static __inline void +static void EcUnlock(struct acpi_ec_softc *sc) { + ACPI_SERIAL_END(ec); if (sc->ec_glk) AcpiReleaseGlobalLock(sc->ec_glkhandle); - ACPI_SERIAL_END(ec); } static uint32_t EcGpeHandler(void *Context); @@ -328,7 +235,8 @@ ACPI_PHYSICAL_ADDRESS Address, UINT32 width, ACPI_INTEGER *Value, void *Context, void *RegionContext); -static ACPI_STATUS EcWaitEvent(struct acpi_ec_softc *sc, EC_EVENT Event); +static ACPI_STATUS EcWaitEvent(struct acpi_ec_softc *sc, EC_EVENT Event, + u_int gen_count); static ACPI_STATUS EcCommand(struct acpi_ec_softc *sc, EC_COMMAND cmd); static ACPI_STATUS EcRead(struct acpi_ec_softc *sc, UINT8 Address, UINT8 *Data); @@ -369,7 +277,9 @@ * Look for an ECDT and if we find one, set up default GPE and * space handlers to catch attempts to access EC space before * we have a real driver instance in place. - * TODO: if people report invalid ECDTs, add a tunable to disable them. + * + * TODO: Some old Gateway laptops need us to fake up an ECDT or + * otherwise attach early so that _REG methods can run. */ void acpi_ec_ecdt_probe(device_t parent) @@ -387,20 +297,20 @@ status = AcpiGetFirmwareTable("ECDT", 1, ACPI_LOGICAL_ADDRESSING, &hdr); ecdt = (ACPI_TABLE_ECDT *)hdr; if (ACPI_FAILURE(status) || - ecdt->control.RegisterBitWidth != 8 || - ecdt->data.RegisterBitWidth != 8) { + ecdt->Control.RegisterBitWidth != 8 || + ecdt->Data.RegisterBitWidth != 8) { return; } /* Create the child device with the given unit number. */ - child = BUS_ADD_CHILD(parent, 0, "acpi_ec", ecdt->uid); + child = BUS_ADD_CHILD(parent, 0, "acpi_ec", ecdt->Uid); if (child == NULL) { printf("%s: can't add child\n", __func__); return; } /* Find and save the ACPI handle for this device. */ - status = AcpiGetHandle(NULL, ecdt->ec_id, &h); + status = AcpiGetHandle(NULL, ecdt->Id, &h); if (ACPI_FAILURE(status)) { device_delete_child(parent, child); printf("%s: can't get handle\n", __func__); @@ -409,9 +319,9 @@ acpi_set_handle(child, h); /* Set the data and CSR register addresses. */ - bus_set_resource(child, SYS_RES_IOPORT, 0, ecdt->data.Address, + bus_set_resource(child, SYS_RES_IOPORT, 0, ecdt->Data.Address, /*count*/1); - bus_set_resource(child, SYS_RES_IOPORT, 1, ecdt->control.Address, + bus_set_resource(child, SYS_RES_IOPORT, 1, ecdt->Control.Address, /*count*/1); /* @@ -423,11 +333,11 @@ */ params = malloc(sizeof(struct acpi_ec_params), M_TEMP, M_WAITOK | M_ZERO); params->gpe_handle = NULL; - params->gpe_bit = ecdt->gpe_bit; - params->uid = ecdt->uid; + params->gpe_bit = ecdt->Gpe; + params->uid = ecdt->Uid; acpi_GetInteger(h, "_GLK", ¶ms->glk); acpi_set_private(child, params); - acpi_set_magic(child, (int)&acpi_ec_devclass); + acpi_set_magic(child, (uintptr_t)&acpi_ec_devclass); /* Finish the attach process. */ if (device_probe_and_attach(child) != 0) @@ -688,100 +598,92 @@ struct acpi_ec_softc *sc = (struct acpi_ec_softc *)Context; UINT8 Data; ACPI_STATUS Status; - EC_STATUS EcStatus; char qxx[5]; ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__); KASSERT(Context != NULL, ("EcGpeQueryHandler called with NULL")); + /* Serialize user access with EcSpaceHandler(). */ Status = EcLock(sc); if (ACPI_FAILURE(Status)) { - ACPI_VPRINT(sc->ec_dev, acpi_device_get_parent_softc(sc->ec_dev), - "GpeQuery lock error: %s\n", AcpiFormatException(Status)); + device_printf(sc->ec_dev, "GpeQuery lock error: %s\n", + AcpiFormatException(Status)); return; } /* - * If the EC_SCI bit of the status register is not set, then pass - * it along to any potential waiters as it may be an IBE/OBF event. - */ - EcStatus = EC_GET_CSR(sc); - if ((EcStatus & EC_EVENT_SCI) == 0) { - CTR1(KTR_ACPI, "ec event was not SCI, status %#x", EcStatus); - sc->ec_csrvalue = EcStatus; - wakeup(&sc->ec_csrvalue); - EcUnlock(sc); - goto re_enable; - } - - /* * Send a query command to the EC to find out which _Qxx call it * wants to make. This command clears the SCI bit and also the - * interrupt source since we are edge-triggered. + * interrupt source since we are edge-triggered. To prevent the GPE + * that may arise from running the query from causing another query + * to be queued, we clear the pending flag only after running it. */ Status = EcCommand(sc, EC_COMMAND_QUERY); + sc->ec_sci_pend = FALSE; if (ACPI_FAILURE(Status)) { EcUnlock(sc); - ACPI_VPRINT(sc->ec_dev, acpi_device_get_parent_softc(sc->ec_dev), - "GPE query failed - %s\n", AcpiFormatException(Status)); - goto re_enable; + device_printf(sc->ec_dev, "GPE query failed: %s\n", + AcpiFormatException(Status)); + return; } Data = EC_GET_DATA(sc); - EcUnlock(sc); /* Ignore the value for "no outstanding event". (13.3.5) */ - CTR2(KTR_ACPI, "ec query ok,%s running _Q%02x", Data ? "" : " not", Data); - if (Data == 0) - goto re_enable; + CTR2(KTR_ACPI, "ec query ok,%s running _Q%02X", Data ? "" : " not", Data); + if (Data == 0) { + EcUnlock(sc); + return; + } /* Evaluate _Qxx to respond to the controller. */ - sprintf(qxx, "_Q%02x", Data); + snprintf(qxx, sizeof(qxx), "_Q%02X", Data); AcpiUtStrupr(qxx); Status = AcpiEvaluateObject(sc->ec_handle, qxx, NULL, NULL); if (ACPI_FAILURE(Status) && Status != AE_NOT_FOUND) { - ACPI_VPRINT(sc->ec_dev, acpi_device_get_parent_softc(sc->ec_dev), - "evaluation of GPE query method %s failed - %s\n", - qxx, AcpiFormatException(Status)); + device_printf(sc->ec_dev, "evaluation of query method %s failed: %s\n", + qxx, AcpiFormatException(Status)); } -re_enable: - /* Re-enable the GPE event so we'll get future requests. */ - Status = AcpiEnableGpe(sc->ec_gpehandle, sc->ec_gpebit, ACPI_NOT_ISR); - if (ACPI_FAILURE(Status)) - printf("EcGpeQueryHandler: AcpiEnableEvent failed\n"); + EcUnlock(sc); } /* - * Handle a GPE. Currently we only handle SCI events as others must - * be handled by polling in EcWaitEvent(). This is because some ECs - * treat events as level when they should be edge-triggered. + * The GPE handler is called when IBE/OBF or SCI events occur. We are + * called from an unknown lock context. */ static uint32_t EcGpeHandler(void *Context) { struct acpi_ec_softc *sc = Context; ACPI_STATUS Status; + EC_STATUS EcStatus; KASSERT(Context != NULL, ("EcGpeHandler called with NULL")); + CTR0(KTR_ACPI, "ec gpe handler start"); /* - * Disable further GPEs while we handle this one. Since we are directly - * called by ACPI-CA and it may have unknown locks held, we specify the - * ACPI_ISR flag to keep it from acquiring any more mutexes (which could - * potentially sleep.) + * Notify EcWaitEvent() that the status register is now fresh. If we + * didn't do this, it wouldn't be possible to distinguish an old IBE + * from a new one, for example when doing a write transaction (writing + * address and then data values.) */ - AcpiDisableGpe(sc->ec_gpehandle, sc->ec_gpebit, ACPI_ISR); + atomic_add_int(&sc->ec_gencount, 1); + wakeup(&sc->ec_gencount); - /* Schedule the GPE query handler. */ - Status = AcpiOsQueueForExecution(OSD_PRIORITY_GPE, EcGpeQueryHandler, - Context); - if (ACPI_FAILURE(Status)) { - printf("Queuing GPE query handler failed.\n"); - Status = AcpiEnableGpe(sc->ec_gpehandle, sc->ec_gpebit, ACPI_ISR); - if (ACPI_FAILURE(Status)) - printf("EcGpeHandler: AcpiEnableEvent failed\n"); + /* + * If the EC_SCI bit of the status register is set, queue a query handler. + * It will run the query and _Qxx method later, under the lock. + */ + EcStatus = EC_GET_CSR(sc); + if ((EcStatus & EC_EVENT_SCI) && !sc->ec_sci_pend) { + CTR0(KTR_ACPI, "ec gpe queueing query handler"); + Status = AcpiOsQueueForExecution(OSD_PRIORITY_GPE, EcGpeQueryHandler, + Context); + if (ACPI_SUCCESS(Status)) + sc->ec_sci_pend = TRUE; + else + printf("EcGpeHandler: queuing GPE query handler failed\n"); } - return (0); } @@ -825,6 +727,18 @@ EcAddr = Address; Status = AE_ERROR; + /* + * If booting, check if we need to run the query handler. If so, we + * we call it directly here since our thread taskq is not active yet. + */ + if (cold) { + if ((EC_GET_CSR(sc) & EC_EVENT_SCI)) { + CTR0(KTR_ACPI, "ec running gpe handler directly"); + EcGpeQueryHandler(sc); + } + } + + /* Serialize with EcGpeQueryHandler() at transaction granularity. */ Status = EcLock(sc); if (ACPI_FAILURE(Status)) return_ACPI_STATUS (Status); @@ -850,149 +764,188 @@ if (ACPI_FAILURE(Status)) break; } - EcUnlock(sc); + return_ACPI_STATUS (Status); } static ACPI_STATUS -EcWaitEvent(struct acpi_ec_softc *sc, EC_EVENT Event) +EcWaitEvent(struct acpi_ec_softc *sc, EC_EVENT Event, u_int gen_count) { EC_STATUS EcStatus; ACPI_STATUS Status; - int count, i, period, retval, slp_ival; + int count, i, slp_ival; ACPI_SERIAL_ASSERT(ec); Status = AE_NO_HARDWARE_RESPONSE; - /* - * Wait for 1 us before checking the CSR. Testing shows about - * 50% of requests complete in 1 us and 90% of them complete - * in 5 us or less. - */ - AcpiOsStall(1); - /* - * Poll the EC status register for up to 1 ms in chunks of 10 us - * to detect completion of the last command. + * The main CPU should be much faster than the EC. So the status should + * be "not ready" when we start waiting. But if the main CPU is really + * slow, it's possible we see the current "ready" response. Since that + * can't be distinguished from the previous response in polled mode, + * this is a potential issue. We really should have interrupts enabled + * during boot so there is no ambiguity in polled mode. For now, let's + * collect some stats about how many systems actually have this issue. */ - for (i = 0; i < 1000 / EC_POLL_DELAY; i++) { + if (cold || ec_polled_mode) { + static int once; + EcStatus = EC_GET_CSR(sc); - if (EVENT_READY(Event, EcStatus)) { - Status = AE_OK; - break; + if (!once && EVENT_READY(Event, EcStatus)) { + device_printf(sc->ec_dev, + "warning: EC done before starting event wait\n"); + once = 1; } - AcpiOsStall(EC_POLL_DELAY); } - period = i * EC_POLL_DELAY; - /* - * If we still don't have a response and we're up and running, wait up - * to ec_poll_timeout ms for completion, sleeping for chunks of 10 ms. - */ - slp_ival = 0; - if (Status != AE_OK) { - retval = ENXIO; - count = ec_poll_timeout / 10; - if (count == 0) + /* Wait for event by polling or GPE (interrupt). */ + if (cold || ec_polled_mode) { + count = (ec_timeout * 1000) / EC_POLL_DELAY; + if (count <= 0) count = 1; - slp_ival = hz / 100; - if (slp_ival == 0) - slp_ival = 1; for (i = 0; i < count; i++) { - if (retval != 0) - EcStatus = EC_GET_CSR(sc); - else - EcStatus = sc->ec_csrvalue; + EcStatus = EC_GET_CSR(sc); + if (sc->ec_burstactive && !(EcStatus & EC_FLAG_BURST_MODE)) { + CTR0(KTR_ACPI, "ec burst disabled in waitevent (poll)"); + sc->ec_burstactive = FALSE; + } if (EVENT_READY(Event, EcStatus)) { + CTR1(KTR_ACPI, "ec poll wait ready, status %#x", EcStatus); Status = AE_OK; break; } - if (!cold) - retval = tsleep(&sc->ec_csrvalue, PZERO, "ecpoll", slp_ival); - else - AcpiOsStall(10000); + AcpiOsStall(EC_POLL_DELAY); + } + } else { + slp_ival = hz / 1000; + if (slp_ival != 0) { + count = ec_timeout / slp_ival; + } else { + /* hz has less than 1000 Hz resolution so scale timeout. */ + slp_ival = 1; + count = ec_timeout / (1000 / hz); } - } - - /* Calculate new delay and log it. */ - if (slp_ival > 0) - period += i * 10000; - CTR2(KTR_ACPI, "ec got event %#x after %d us", EcStatus, period); + /* + * Wait for the GPE to signal the status changed, checking the + * status register each time. + */ + for (i = 0; i < count; i++) { + if (gen_count != sc->ec_gencount) { + /* + * Record new generation count. It's possible the GPE was + * just to notify us that a query is needed and we need to + * wait for a second GPE to signal the completion of the + * event we are actually waiting for. + */ + gen_count = sc->ec_gencount; + EcStatus = EC_GET_CSR(sc); + if (sc->ec_burstactive && !(EcStatus & EC_FLAG_BURST_MODE)) { + CTR0(KTR_ACPI, "ec burst disabled in waitevent (sleep)"); + sc->ec_burstactive = FALSE; + } + if (EVENT_READY(Event, EcStatus)) { + CTR1(KTR_ACPI, "ec sleep wait ready, status %#x", EcStatus); + Status = AE_OK; + break; + } + } + tsleep(&sc->ec_gencount, PZERO, "ecgpe", slp_ival); + } + } + if (Status != AE_OK) + CTR0(KTR_ACPI, "error: ec wait timed out"); return (Status); -} +} static ACPI_STATUS EcCommand(struct acpi_ec_softc *sc, EC_COMMAND cmd) { - ACPI_STATUS Status; - EC_EVENT Event; + ACPI_STATUS status; + EC_EVENT event; + EC_STATUS ec_status; + u_int gen_count; ACPI_SERIAL_ASSERT(ec); + /* Don't use burst mode if user disabled it. */ + if (!ec_burst_mode && cmd == EC_COMMAND_BURST_ENABLE) + return (AE_ERROR); + /* Decide what to wait for based on command type. */ switch (cmd) { case EC_COMMAND_READ: case EC_COMMAND_WRITE: case EC_COMMAND_BURST_DISABLE: - Event = EC_EVENT_INPUT_BUFFER_EMPTY; + event = EC_EVENT_INPUT_BUFFER_EMPTY; break; case EC_COMMAND_QUERY: case EC_COMMAND_BURST_ENABLE: - Event = EC_EVENT_OUTPUT_BUFFER_FULL; + event = EC_EVENT_OUTPUT_BUFFER_FULL; break; default: - ACPI_VPRINT(sc->ec_dev, acpi_device_get_parent_softc(sc->ec_dev), - "EcCommand: Invalid command %#x\n", cmd); + device_printf(sc->ec_dev, "EcCommand: invalid command %#x\n", cmd); return (AE_BAD_PARAMETER); } /* Run the command and wait for the chosen event. */ + CTR1(KTR_ACPI, "ec running command %#x", cmd); + gen_count = sc->ec_gencount; EC_SET_CSR(sc, cmd); - Status = EcWaitEvent(sc, Event); - if (ACPI_FAILURE(Status)) { - ACPI_VPRINT(sc->ec_dev, acpi_device_get_parent_softc(sc->ec_dev), - "EcCommand: no response to %#x\n", cmd); - } - - return (Status); + status = EcWaitEvent(sc, event, gen_count); + if (ACPI_SUCCESS(status)) { + /* If we succeeded, burst flag should now be present. */ + if (cmd == EC_COMMAND_BURST_ENABLE) { + ec_status = EC_GET_CSR(sc); + if ((ec_status & EC_FLAG_BURST_MODE) == 0) + status = AE_ERROR; + } + } else + device_printf(sc->ec_dev, "EcCommand: no response to %#x\n", cmd); + return (status); } static ACPI_STATUS EcRead(struct acpi_ec_softc *sc, UINT8 Address, UINT8 *Data) { - ACPI_STATUS Status; + ACPI_STATUS status; + UINT8 data; + u_int gen_count; ACPI_SERIAL_ASSERT(ec); CTR1(KTR_ACPI, "ec read from %#x", Address); -#ifdef notyet /* If we can't start burst mode, continue anyway. */ - EcCommand(sc, EC_COMMAND_BURST_ENABLE); -#endif + status = EcCommand(sc, EC_COMMAND_BURST_ENABLE); + if (status == AE_OK) { + data = EC_GET_DATA(sc); + if (data == EC_BURST_ACK) { + CTR0(KTR_ACPI, "ec burst enabled"); + sc->ec_burstactive = TRUE; + } + } - Status = EcCommand(sc, EC_COMMAND_READ); - if (ACPI_FAILURE(Status)) - return (Status); + status = EcCommand(sc, EC_COMMAND_READ); + if (ACPI_FAILURE(status)) + return (status); + gen_count = sc->ec_gencount; EC_SET_DATA(sc, Address); - Status = EcWaitEvent(sc, EC_EVENT_OUTPUT_BUFFER_FULL); - if (ACPI_FAILURE(Status)) { - ACPI_VPRINT(sc->ec_dev, acpi_device_get_parent_softc(sc->ec_dev), - "EcRead: Failed waiting for EC to send data.\n"); - return (Status); + status = EcWaitEvent(sc, EC_EVENT_OUTPUT_BUFFER_FULL, gen_count); + if (ACPI_FAILURE(status)) { + device_printf(sc->ec_dev, "EcRead: failed waiting to get data\n"); + return (status); } - *Data = EC_GET_DATA(sc); -#ifdef notyet if (sc->ec_burstactive) { - Status = EcCommand(sc, EC_COMMAND_BURST_DISABLE); - if (ACPI_FAILURE(Status)) - return (Status); + sc->ec_burstactive = FALSE; + status = EcCommand(sc, EC_COMMAND_BURST_DISABLE); + if (ACPI_FAILURE(status)) + return (status); + CTR0(KTR_ACPI, "ec disabled burst ok"); } -#endif return (AE_OK); } @@ -1000,43 +953,50 @@ static ACPI_STATUS EcWrite(struct acpi_ec_softc *sc, UINT8 Address, UINT8 *Data) { - ACPI_STATUS Status; + ACPI_STATUS status; + UINT8 data; + u_int gen_count; ACPI_SERIAL_ASSERT(ec); CTR2(KTR_ACPI, "ec write to %#x, data %#x", Address, *Data); -#ifdef notyet /* If we can't start burst mode, continue anyway. */ - EcCommand(sc, EC_COMMAND_BURST_ENABLE); -#endif + status = EcCommand(sc, EC_COMMAND_BURST_ENABLE); + if (status == AE_OK) { + data = EC_GET_DATA(sc); + if (data == EC_BURST_ACK) { + CTR0(KTR_ACPI, "ec burst enabled"); + sc->ec_burstactive = TRUE; + } + } - Status = EcCommand(sc, EC_COMMAND_WRITE); - if (ACPI_FAILURE(Status)) - return (Status); + status = EcCommand(sc, EC_COMMAND_WRITE); + if (ACPI_FAILURE(status)) + return (status); + gen_count = sc->ec_gencount; EC_SET_DATA(sc, Address); - Status = EcWaitEvent(sc, EC_EVENT_INPUT_BUFFER_EMPTY); - if (ACPI_FAILURE(Status)) { - ACPI_VPRINT(sc->ec_dev, acpi_device_get_parent_softc(sc->ec_dev), - "EcRead: Failed waiting for EC to process address\n"); - return (Status); + status = EcWaitEvent(sc, EC_EVENT_INPUT_BUFFER_EMPTY, gen_count); + if (ACPI_FAILURE(status)) { + device_printf(sc->ec_dev, "EcRead: failed waiting for sent address\n"); + return (status); } + gen_count = sc->ec_gencount; EC_SET_DATA(sc, *Data); - Status = EcWaitEvent(sc, EC_EVENT_INPUT_BUFFER_EMPTY); - if (ACPI_FAILURE(Status)) { - ACPI_VPRINT(sc->ec_dev, acpi_device_get_parent_softc(sc->ec_dev), - "EcWrite: Failed waiting for EC to process data\n"); - return (Status); + status = EcWaitEvent(sc, EC_EVENT_INPUT_BUFFER_EMPTY, gen_count); + if (ACPI_FAILURE(status)) { + device_printf(sc->ec_dev, "EcWrite: failed waiting for sent data\n"); + return (status); } -#ifdef notyet if (sc->ec_burstactive) { - Status = EcCommand(sc, EC_COMMAND_BURST_DISABLE); - if (ACPI_FAILURE(Status)) - return (Status); + sc->ec_burstactive = FALSE; + status = EcCommand(sc, EC_COMMAND_BURST_DISABLE); + if (ACPI_FAILURE(status)) + return (status); + CTR0(KTR_ACPI, "ec disabled burst ok"); } -#endif return (AE_OK); } --------------020803020602030709060703 Content-Type: text/x-patch; name="ecng-7a.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ecng-7a.diff" Index: sys/dev/acpica/acpi_ec.c =================================================================== RCS file: /home/ncvs/src/sys/dev/acpica/acpi_ec.c,v retrieving revision 1.75 diff -u -r1.75 acpi_ec.c --- sys/dev/acpica/acpi_ec.c 15 Jun 2007 18:02:33 -0000 1.75 +++ sys/dev/acpica/acpi_ec.c 6 Sep 2007 21:22:02 -0000 @@ -1,5 +1,5 @@ /*- - * Copyright (c) 2003 Nate Lawson + * Copyright (c) 2003-2007 Nate Lawson * Copyright (c) 2000 Michael Smith * Copyright (c) 2000 BSDi * All rights reserved. @@ -25,115 +25,6 @@ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. */ -/*- - ****************************************************************************** - * - * 1. Copyright Notice - * - * Some or all of this work - Copyright (c) 1999, Intel Corp. All rights - * reserved. - * - * 2. License - * - * 2.1. This is your license from Intel Corp. under its intellectual property - * rights. You may have additional license terms from the party that provided - * you this software, covering your right to use that party's intellectual - * property rights. - * - * 2.2. Intel grants, free of charge, to any person ("Licensee") obtaining a - * copy of the source code appearing in this file ("Covered Code") an - * irrevocable, perpetual, worldwide license under Intel's copyrights in the - * base code distributed originally by Intel ("Original Intel Code") to copy, - * make derivatives, distribute, use and display any portion of the Covered - * Code in any form, with the right to sublicense such rights; and - * - * 2.3. Intel grants Licensee a non-exclusive and non-transferable patent - * license (with the right to sublicense), under only those claims of Intel - * patents that are infringed by the Original Intel Code, to make, use, sell, - * offer to sell, and import the Covered Code and derivative works thereof - * solely to the minimum extent necessary to exercise the above copyright - * license, and in no event shall the patent license extend to any additions - * to or modifications of the Original Intel Code. No other license or right - * is granted directly or by implication, estoppel or otherwise; - * - * The above copyright and patent license is granted only if the following - * conditions are met: - * - * 3. Conditions - * - * 3.1. Redistribution of Source with Rights to Further Distribute Source. - * Redistribution of source code of any substantial portion of the Covered - * Code or modification with rights to further distribute source must include - * the above Copyright Notice, the above License, this list of Conditions, - * and the following Disclaimer and Export Compliance provision. In addition, - * Licensee must cause all Covered Code to which Licensee contributes to - * contain a file documenting the changes Licensee made to create that Covered - * Code and the date of any change. Licensee must include in that file the - * documentation of any changes made by any predecessor Licensee. Licensee - * must include a prominent statement that the modification is derived, - * directly or indirectly, from Original Intel Code. - * - * 3.2. Redistribution of Source with no Rights to Further Distribute Source. - * Redistribution of source code of any substantial portion of the Covered - * Code or modification without rights to further distribute source must - * include the following Disclaimer and Export Compliance provision in the - * documentation and/or other materials provided with distribution. In - * addition, Licensee may not authorize further sublicense of source of any - * portion of the Covered Code, and must include terms to the effect that the - * license from Licensee to its licensee is limited to the intellectual - * property embodied in the software Licensee provides to its licensee, and - * not to intellectual property embodied in modifications its licensee may - * make. - * - * 3.3. Redistribution of Executable. Redistribution in executable form of any - * substantial portion of the Covered Code or modification must reproduce the - * above Copyright Notice, and the following Disclaimer and Export Compliance - * provision in the documentation and/or other materials provided with the - * distribution. - * - * 3.4. Intel retains all right, title, and interest in and to the Original - * Intel Code. - * - * 3.5. Neither the name Intel nor any other trademark owned or controlled by - * Intel shall be used in advertising or otherwise to promote the sale, use or - * other dealings in products derived from or relating to the Covered Code - * without prior written authorization from Intel. - * - * 4. Disclaimer and Export Compliance - * - * 4.1. INTEL MAKES NO WARRANTY OF ANY KIND REGARDING ANY SOFTWARE PROVIDED - * HERE. ANY SOFTWARE ORIGINATING FROM INTEL OR DERIVED FROM INTEL SOFTWARE - * IS PROVIDED "AS IS," AND INTEL WILL NOT PROVIDE ANY SUPPORT, ASSISTANCE, - * INSTALLATION, TRAINING OR OTHER SERVICES. INTEL WILL NOT PROVIDE ANY - * UPDATES, ENHANCEMENTS OR EXTENSIONS. INTEL SPECIFICALLY DISCLAIMS ANY - * IMPLIED WARRANTIES OF MERCHANTABILITY, NONINFRINGEMENT AND FITNESS FOR A - * PARTICULAR PURPOSE. - * - * 4.2. IN NO EVENT SHALL INTEL HAVE ANY LIABILITY TO LICENSEE, ITS LICENSEES - * OR ANY OTHER THIRD PARTY, FOR ANY LOST PROFITS, LOST DATA, LOSS OF USE OR - * COSTS OF PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES, OR FOR ANY INDIRECT, - * SPECIAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THIS AGREEMENT, UNDER ANY - * CAUSE OF ACTION OR THEORY OF LIABILITY, AND IRRESPECTIVE OF WHETHER INTEL - * HAS ADVANCE NOTICE OF THE POSSIBILITY OF SUCH DAMAGES. THESE LIMITATIONS - * SHALL APPLY NOTWITHSTANDING THE FAILURE OF THE ESSENTIAL PURPOSE OF ANY - * LIMITED REMEDY. - * - * 4.3. Licensee shall not export, either directly or indirectly, any of this - * software or system incorporating such software without first obtaining any - * required license or other approval from the U. S. Department of Commerce or - * any other agency or department of the United States Government. In the - * event Licensee exports any such software from the United States or - * re-exports any such software from a foreign destination, Licensee shall - * ensure that the distribution and export/re-export of the software is in - * compliance with all laws, regulations, orders, or other restrictions of the - * U.S. Export Administration Regulations. Licensee agrees that neither it nor - * any of its subsidiaries will export/re-export any technical data, process, - * software, or service, directly or indirectly, to any country for which the - * United States government or any agency thereof requires an export license, - * other governmental approval, or letter of assurance, without first obtaining - * such license, approval or letter. - * - *****************************************************************************/ #include __FBSDID("$FreeBSD$"); @@ -248,7 +139,6 @@ int ec_uid; ACPI_HANDLE ec_gpehandle; UINT8 ec_gpebit; - UINT8 ec_csrvalue; int ec_data_rid; struct resource *ec_data_res; @@ -260,11 +150,11 @@ bus_space_tag_t ec_csr_tag; bus_space_handle_t ec_csr_handle; - struct mtx ec_mtx; int ec_glk; int ec_glkhandle; int ec_burstactive; int ec_sci_pend; + u_int ec_gencount; }; /* @@ -275,13 +165,10 @@ #define EC_LOCK_TIMEOUT 1000 /* Default delay in microseconds between each run of the status polling loop. */ -#define EC_POLL_DELAY 10 - -/* Default time in microseconds spent polling before sleep waiting. */ -#define EC_POLL_TIME 500 +#define EC_POLL_DELAY 5 /* Total time in ms spent waiting for a response from EC. */ -#define EC_TIMEOUT 500 +#define EC_TIMEOUT 750 #define EVENT_READY(event, status) \ (((event) == EC_EVENT_OUTPUT_BUFFER_FULL && \ @@ -298,17 +185,17 @@ TUNABLE_INT("debug.acpi.ec.burst", &ec_burst_mode); SYSCTL_INT(_debug_acpi_ec, OID_AUTO, burst, CTLFLAG_RW, &ec_burst_mode, 0, "Enable use of burst mode (faster for nearly all systems)"); -static int ec_poll_time = EC_POLL_TIME; -TUNABLE_INT("debug.acpi.ec.poll_time", &ec_poll_time); -SYSCTL_INT(_debug_acpi_ec, OID_AUTO, poll_time, CTLFLAG_RW, &ec_poll_time, - EC_POLL_TIME, "Time spent polling vs. sleeping (CPU intensive)"); +static int ec_polled_mode; +TUNABLE_INT("debug.acpi.ec.polled", &ec_polled_mode); +SYSCTL_INT(_debug_acpi_ec, OID_AUTO, polled, CTLFLAG_RW, &ec_polled_mode, 0, + "Force use of polled mode (only if interrupt mode doesn't work)"); static int ec_timeout = EC_TIMEOUT; TUNABLE_INT("debug.acpi.ec.timeout", &ec_timeout); SYSCTL_INT(_debug_acpi_ec, OID_AUTO, timeout, CTLFLAG_RW, &ec_timeout, EC_TIMEOUT, "Total time spent waiting for a response (poll+sleep)"); -static __inline ACPI_STATUS -EcLock(struct acpi_ec_softc *sc, int serialize) +static ACPI_STATUS +EcLock(struct acpi_ec_softc *sc) { ACPI_STATUS status; @@ -319,25 +206,14 @@ if (ACPI_FAILURE(status)) return (status); } - - /* - * If caller is executing a series of commands, acquire the exclusive lock - * to serialize with other users. - * To sync with bottom-half interrupt handler, always acquire the mutex. - */ - if (serialize) - ACPI_SERIAL_BEGIN(ec); - mtx_lock(&sc->ec_mtx); - + ACPI_SERIAL_BEGIN(ec); return (status); } -static __inline void +static void EcUnlock(struct acpi_ec_softc *sc) { - mtx_unlock(&sc->ec_mtx); - if (sx_xlocked(&ec_sxlock)) - ACPI_SERIAL_END(ec); + ACPI_SERIAL_END(ec); if (sc->ec_glk) AcpiReleaseGlobalLock(sc->ec_glkhandle); } @@ -349,7 +225,8 @@ ACPI_PHYSICAL_ADDRESS Address, UINT32 width, ACPI_INTEGER *Value, void *Context, void *RegionContext); -static ACPI_STATUS EcWaitEvent(struct acpi_ec_softc *sc, EC_EVENT Event); +static ACPI_STATUS EcWaitEvent(struct acpi_ec_softc *sc, EC_EVENT Event, + u_int gen_count); static ACPI_STATUS EcCommand(struct acpi_ec_softc *sc, EC_COMMAND cmd); static ACPI_STATUS EcRead(struct acpi_ec_softc *sc, UINT8 Address, UINT8 *Data); @@ -390,7 +267,9 @@ * Look for an ECDT and if we find one, set up default GPE and * space handlers to catch attempts to access EC space before * we have a real driver instance in place. - * TODO: if people report invalid ECDTs, add a tunable to disable them. + * + * TODO: Some old Gateway laptops need us to fake up an ECDT or + * otherwise attach early so that _REG methods can run. */ void acpi_ec_ecdt_probe(device_t parent) @@ -578,7 +457,6 @@ params = acpi_get_private(dev); sc->ec_dev = dev; sc->ec_handle = acpi_get_handle(dev); - mtx_init(&sc->ec_mtx, "ACPI EC lock", NULL, MTX_DEF); /* Retrieve previously probed values via device ivars. */ sc->ec_glk = params->glk; @@ -661,7 +539,6 @@ if (sc->ec_data_res) bus_release_resource(sc->ec_dev, SYS_RES_IOPORT, sc->ec_data_rid, sc->ec_data_res); - mtx_destroy(&sc->ec_mtx); return (ENXIO); } @@ -715,57 +592,52 @@ KASSERT(Context != NULL, ("EcGpeQueryHandler called with NULL")); /* Serialize user access with EcSpaceHandler(). */ - Status = EcLock(sc, TRUE); + Status = EcLock(sc); if (ACPI_FAILURE(Status)) { - ACPI_VPRINT(sc->ec_dev, acpi_device_get_parent_softc(sc->ec_dev), - "GpeQuery lock error: %s\n", AcpiFormatException(Status)); + device_printf(sc->ec_dev, "GpeQuery lock error: %s\n", + AcpiFormatException(Status)); return; } /* * Send a query command to the EC to find out which _Qxx call it * wants to make. This command clears the SCI bit and also the - * interrupt source since we are edge-triggered. + * interrupt source since we are edge-triggered. To prevent the GPE + * that may arise from running the query from causing another query + * to be queued, we clear the pending flag only after running it. */ Status = EcCommand(sc, EC_COMMAND_QUERY); + sc->ec_sci_pend = FALSE; if (ACPI_FAILURE(Status)) { EcUnlock(sc); - ACPI_VPRINT(sc->ec_dev, acpi_device_get_parent_softc(sc->ec_dev), - "GPE query failed - %s\n", AcpiFormatException(Status)); - goto re_enable; + device_printf(sc->ec_dev, "GPE query failed: %s\n", + AcpiFormatException(Status)); + return; } Data = EC_GET_DATA(sc); - sc->ec_sci_pend = FALSE; - - /* Drop locks before evaluating _Qxx method since it may trigger GPEs. */ - EcUnlock(sc); /* Ignore the value for "no outstanding event". (13.3.5) */ - CTR2(KTR_ACPI, "ec query ok,%s running _Q%02x", Data ? "" : " not", Data); - if (Data == 0) - goto re_enable; + CTR2(KTR_ACPI, "ec query ok,%s running _Q%02X", Data ? "" : " not", Data); + if (Data == 0) { + EcUnlock(sc); + return; + } /* Evaluate _Qxx to respond to the controller. */ - snprintf(qxx, sizeof(qxx), "_Q%02x", Data); + snprintf(qxx, sizeof(qxx), "_Q%02X", Data); AcpiUtStrupr(qxx); Status = AcpiEvaluateObject(sc->ec_handle, qxx, NULL, NULL); if (ACPI_FAILURE(Status) && Status != AE_NOT_FOUND) { - ACPI_VPRINT(sc->ec_dev, acpi_device_get_parent_softc(sc->ec_dev), - "evaluation of GPE query method %s failed - %s\n", - qxx, AcpiFormatException(Status)); + device_printf(sc->ec_dev, "evaluation of query method %s failed: %s\n", + qxx, AcpiFormatException(Status)); } -re_enable: - /* Re-enable the GPE event so we'll get future requests. */ - Status = AcpiEnableGpe(sc->ec_gpehandle, sc->ec_gpebit, ACPI_ISR); - if (ACPI_FAILURE(Status)) - printf("EcGpeQueryHandler: AcpiEnableEvent failed\n"); + EcUnlock(sc); } /* - * Handle a GPE. Currently we only handle SCI events as others must - * be handled by polling in EcWaitEvent(). This is because some ECs - * treat events as level when they should be edge-triggered. + * The GPE handler is called when IBE/OBF or SCI events occur. We are + * called from an unknown lock context. */ static uint32_t EcGpeHandler(void *Context) @@ -773,68 +645,32 @@ struct acpi_ec_softc *sc = Context; ACPI_STATUS Status; EC_STATUS EcStatus; - int query_pend; KASSERT(Context != NULL, ("EcGpeHandler called with NULL")); + CTR0(KTR_ACPI, "ec gpe handler start"); /* - * Disable further GPEs while we handle this one. Since we are directly - * called by ACPI-CA and it may have unknown locks held, we specify the - * ACPI_ISR flag to keep it from acquiring any more mutexes (although - * sleeping would be ok since we're in an ithread.) + * Notify EcWaitEvent() that the status register is now fresh. If we + * didn't do this, it wouldn't be possible to distinguish an old IBE + * from a new one, for example when doing a write transaction (writing + * address and then data values.) */ - AcpiDisableGpe(sc->ec_gpehandle, sc->ec_gpebit, ACPI_ISR); - - /* For interrupt (GPE) handler, don't acquire serialization lock. */ - Status = EcLock(sc, FALSE); - if (ACPI_FAILURE(Status)) { - ACPI_VPRINT(sc->ec_dev, acpi_device_get_parent_softc(sc->ec_dev), - "GpeQuery lock error: %s\n", AcpiFormatException(Status)); - return (-1); - } + atomic_add_int(&sc->ec_gencount, 1); + wakeup(&sc->ec_gencount); /* - * If burst was active, but the status bit was cleared, the EC had to - * exit burst mode for some reason. Record this for later. + * If the EC_SCI bit of the status register is set, queue a query handler. + * It will run the query and _Qxx method later, under the lock. */ EcStatus = EC_GET_CSR(sc); - if (sc->ec_burstactive && (EcStatus & EC_FLAG_BURST_MODE) == 0) { - CTR0(KTR_ACPI, "ec burst disabled in query handler"); - sc->ec_burstactive = FALSE; - } - - /* - * If the EC_SCI bit of the status register is not set, then pass - * it along to any potential waiters as it may be an IBE/OBF event. - * If it is set, queue a query handler. - */ - query_pend = FALSE; - if ((EcStatus & EC_EVENT_SCI) == 0) { - CTR1(KTR_ACPI, "ec event was IBE/OBF, status %#x", EcStatus); - sc->ec_csrvalue = EcStatus; - wakeup(&sc->ec_csrvalue); - } else if (!sc->ec_sci_pend) { - /* SCI bit set and no pending query handler, so schedule one. */ - CTR0(KTR_ACPI, "ec queueing gpe handler"); + if ((EcStatus & EC_EVENT_SCI) && !sc->ec_sci_pend) { + CTR0(KTR_ACPI, "ec gpe queueing query handler"); Status = AcpiOsExecute(OSL_GPE_HANDLER, EcGpeQueryHandler, Context); - if (ACPI_SUCCESS(Status)) { + if (ACPI_SUCCESS(Status)) sc->ec_sci_pend = TRUE; - query_pend = TRUE; - } else - printf("Queuing GPE query handler failed.\n"); - } - - /* - * If we didn't queue a query handler, which will eventually re-enable - * the GPE, re-enable it right now so we can get more events. - */ - if (!query_pend) { - Status = AcpiEnableGpe(sc->ec_gpehandle, sc->ec_gpebit, ACPI_ISR); - if (ACPI_FAILURE(Status)) - printf("EcGpeHandler: AcpiEnableGpe failed\n"); + else + printf("EcGpeHandler: queuing GPE query handler failed\n"); } - - EcUnlock(sc); return (0); } @@ -878,8 +714,19 @@ EcAddr = Address; Status = AE_ERROR; - /* Grab serialization lock to hold across command sequence. */ - Status = EcLock(sc, TRUE); + /* + * If booting, check if we need to run the query handler. If so, we + * we call it directly here since our thread taskq is not active yet. + */ + if (cold) { + if ((EC_GET_CSR(sc) & EC_EVENT_SCI)) { + CTR0(KTR_ACPI, "ec running gpe handler directly"); + EcGpeQueryHandler(sc); + } + } + + /* Serialize with EcGpeQueryHandler() at transaction granularity. */ + Status = EcLock(sc); if (ACPI_FAILURE(Status)) return_ACPI_STATUS (Status); @@ -910,83 +757,94 @@ } static ACPI_STATUS -EcWaitEvent(struct acpi_ec_softc *sc, EC_EVENT Event) +EcWaitEvent(struct acpi_ec_softc *sc, EC_EVENT Event, u_int gen_count) { EC_STATUS EcStatus; ACPI_STATUS Status; - int count, i, retval, slp_ival; + int count, i, slp_ival; ACPI_SERIAL_ASSERT(ec); Status = AE_NO_HARDWARE_RESPONSE; - EcStatus = 0; /* - * Poll for up to ec_poll_time microseconds since many ECs complete - * the command quickly, especially if in burst mode. + * The main CPU should be much faster than the EC. So the status should + * be "not ready" when we start waiting. But if the main CPU is really + * slow, it's possible we see the current "ready" response. Since that + * can't be distinguished from the previous response in polled mode, + * this is a potential issue. We really should have interrupts enabled + * during boot so there is no ambiguity in polled mode. For now, let's + * collect some stats about how many systems actually have this issue. */ -#if 0 /* Enable this as a possible workaround if EC times out. */ - AcpiOsStall(EC_POLL_DELAY); -#endif - count = ec_poll_time / EC_POLL_DELAY; - if (count <= 0) - count = 1; - for (i = 0; i < count; i++) { + if (cold || ec_polled_mode) { + static int once; + EcStatus = EC_GET_CSR(sc); - if (sc->ec_burstactive && (EcStatus & EC_FLAG_BURST_MODE) == 0) { - CTR0(KTR_ACPI, "ec burst disabled in waitevent (poll)"); - sc->ec_burstactive = FALSE; + if (!once && EVENT_READY(Event, EcStatus)) { + device_printf(sc->ec_dev, + "warning: EC done before starting event wait\n"); + once = 1; } - if (EVENT_READY(Event, EcStatus)) { - CTR1(KTR_ACPI, "ec poll wait ready, status %#x", EcStatus); - Status = AE_OK; - break; - } - AcpiOsStall(EC_POLL_DELAY); } - /* - * If we still don't have a response and we're up and running, wait up - * to ec_timeout ms for completion, sleeping for chunks of 1 ms or the - * smallest resolution hz supports. - */ - slp_ival = 0; - if (Status != AE_OK) { - retval = ENXIO; - if (!cold) { - slp_ival = hz / 1000; - if (slp_ival != 0) { - count = ec_timeout / slp_ival; - } else { - /* hz has less than 1000 Hz resolution so scale timeout. */ - slp_ival = 1; - count = ec_timeout / (1000 / hz); - } - } else - count = ec_timeout; + /* Wait for event by polling or GPE (interrupt). */ + if (cold || ec_polled_mode) { + count = (ec_timeout * 1000) / EC_POLL_DELAY; + if (count <= 0) + count = 1; for (i = 0; i < count; i++) { - if (retval != 0) - EcStatus = EC_GET_CSR(sc); - else - EcStatus = sc->ec_csrvalue; - if (sc->ec_burstactive && (EcStatus & EC_FLAG_BURST_MODE) == 0) { - CTR0(KTR_ACPI, "ec burst disabled in waitevent (slp)"); + EcStatus = EC_GET_CSR(sc); + if (sc->ec_burstactive && !(EcStatus & EC_FLAG_BURST_MODE)) { + CTR0(KTR_ACPI, "ec burst disabled in waitevent (poll)"); sc->ec_burstactive = FALSE; } if (EVENT_READY(Event, EcStatus)) { - CTR1(KTR_ACPI, "ec sleep wait ready, status %#x", EcStatus); + CTR1(KTR_ACPI, "ec poll wait ready, status %#x", EcStatus); Status = AE_OK; break; } - if (!cold) { - retval = msleep(&sc->ec_csrvalue, &sc->ec_mtx, PZERO, "ecpoll", - slp_ival); - } else - AcpiOsStall(1000); + AcpiOsStall(EC_POLL_DELAY); + } + } else { + slp_ival = hz / 1000; + if (slp_ival != 0) { + count = ec_timeout / slp_ival; + } else { + /* hz has less than 1000 Hz resolution so scale timeout. */ + slp_ival = 1; + count = ec_timeout / (1000 / hz); } - } + /* + * Wait for the GPE to signal the status changed, checking the + * status register each time. + */ + for (i = 0; i < count; i++) { + if (gen_count != sc->ec_gencount) { + /* + * Record new generation count. It's possible the GPE was + * just to notify us that a query is needed and we need to + * wait for a second GPE to signal the completion of the + * event we are actually waiting for. + */ + gen_count = sc->ec_gencount; + EcStatus = EC_GET_CSR(sc); + if (sc->ec_burstactive && !(EcStatus & EC_FLAG_BURST_MODE)) { + CTR0(KTR_ACPI, "ec burst disabled in waitevent (sleep)"); + sc->ec_burstactive = FALSE; + } + if (EVENT_READY(Event, EcStatus)) { + CTR1(KTR_ACPI, "ec sleep wait ready, status %#x", EcStatus); + Status = AE_OK; + break; + } + } + tsleep(&sc->ec_gencount, PZERO, "ecgpe", slp_ival); + } + } + if (Status != AE_OK) + CTR0(KTR_ACPI, "error: ec wait timed out"); return (Status); -} +} static ACPI_STATUS EcCommand(struct acpi_ec_softc *sc, EC_COMMAND cmd) @@ -994,6 +852,7 @@ ACPI_STATUS status; EC_EVENT event; EC_STATUS ec_status; + u_int gen_count; ACPI_SERIAL_ASSERT(ec); @@ -1013,15 +872,15 @@ event = EC_EVENT_OUTPUT_BUFFER_FULL; break; default: - ACPI_VPRINT(sc->ec_dev, acpi_device_get_parent_softc(sc->ec_dev), - "EcCommand: Invalid command %#x\n", cmd); + device_printf(sc->ec_dev, "EcCommand: invalid command %#x\n", cmd); return (AE_BAD_PARAMETER); } /* Run the command and wait for the chosen event. */ CTR1(KTR_ACPI, "ec running command %#x", cmd); + gen_count = sc->ec_gencount; EC_SET_CSR(sc, cmd); - status = EcWaitEvent(sc, event); + status = EcWaitEvent(sc, event, gen_count); if (ACPI_SUCCESS(status)) { /* If we succeeded, burst flag should now be present. */ if (cmd == EC_COMMAND_BURST_ENABLE) { @@ -1029,11 +888,8 @@ if ((ec_status & EC_FLAG_BURST_MODE) == 0) status = AE_ERROR; } - } else { - ACPI_VPRINT(sc->ec_dev, acpi_device_get_parent_softc(sc->ec_dev), - "EcCommand: no response to %#x\n", cmd); - } - + } else + device_printf(sc->ec_dev, "EcCommand: no response to %#x\n", cmd); return (status); } @@ -1042,6 +898,7 @@ { ACPI_STATUS status; UINT8 data; + u_int gen_count; ACPI_SERIAL_ASSERT(ec); CTR1(KTR_ACPI, "ec read from %#x", Address); @@ -1060,21 +917,20 @@ if (ACPI_FAILURE(status)) return (status); + gen_count = sc->ec_gencount; EC_SET_DATA(sc, Address); - status = EcWaitEvent(sc, EC_EVENT_OUTPUT_BUFFER_FULL); + status = EcWaitEvent(sc, EC_EVENT_OUTPUT_BUFFER_FULL, gen_count); if (ACPI_FAILURE(status)) { - ACPI_VPRINT(sc->ec_dev, acpi_device_get_parent_softc(sc->ec_dev), - "EcRead: Failed waiting for EC to send data.\n"); + device_printf(sc->ec_dev, "EcRead: failed waiting to get data\n"); return (status); } - *Data = EC_GET_DATA(sc); if (sc->ec_burstactive) { + sc->ec_burstactive = FALSE; status = EcCommand(sc, EC_COMMAND_BURST_DISABLE); if (ACPI_FAILURE(status)) return (status); - sc->ec_burstactive = FALSE; CTR0(KTR_ACPI, "ec disabled burst ok"); } @@ -1086,6 +942,7 @@ { ACPI_STATUS status; UINT8 data; + u_int gen_count; ACPI_SERIAL_ASSERT(ec); CTR2(KTR_ACPI, "ec write to %#x, data %#x", Address, *Data); @@ -1104,27 +961,27 @@ if (ACPI_FAILURE(status)) return (status); + gen_count = sc->ec_gencount; EC_SET_DATA(sc, Address); - status = EcWaitEvent(sc, EC_EVENT_INPUT_BUFFER_EMPTY); + status = EcWaitEvent(sc, EC_EVENT_INPUT_BUFFER_EMPTY, gen_count); if (ACPI_FAILURE(status)) { - ACPI_VPRINT(sc->ec_dev, acpi_device_get_parent_softc(sc->ec_dev), - "EcRead: Failed waiting for EC to process address\n"); + device_printf(sc->ec_dev, "EcRead: failed waiting for sent address\n"); return (status); } + gen_count = sc->ec_gencount; EC_SET_DATA(sc, *Data); - status = EcWaitEvent(sc, EC_EVENT_INPUT_BUFFER_EMPTY); + status = EcWaitEvent(sc, EC_EVENT_INPUT_BUFFER_EMPTY, gen_count); if (ACPI_FAILURE(status)) { - ACPI_VPRINT(sc->ec_dev, acpi_device_get_parent_softc(sc->ec_dev), - "EcWrite: Failed waiting for EC to process data\n"); + device_printf(sc->ec_dev, "EcWrite: failed waiting for sent data\n"); return (status); } if (sc->ec_burstactive) { + sc->ec_burstactive = FALSE; status = EcCommand(sc, EC_COMMAND_BURST_DISABLE); if (ACPI_FAILURE(status)) return (status); - sc->ec_burstactive = FALSE; CTR0(KTR_ACPI, "ec disabled burst ok"); } --------------020803020602030709060703-- From owner-freebsd-current@FreeBSD.ORG Thu Sep 6 22:46:04 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6601F16A41A for ; Thu, 6 Sep 2007 22:46:04 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.freebsd.org (Postfix) with ESMTP id A27C513C481 for ; Thu, 6 Sep 2007 22:46:03 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from kobe.laptop (dialup148.ach.sch.gr [81.186.70.148]) (authenticated bits=128) by igloo.linux.gr (8.14.1/8.14.1/Debian-8) with ESMTP id l86MRC5V012188 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 7 Sep 2007 01:27:21 +0300 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.1/8.14.1) with ESMTP id l86MQueu003184; Fri, 7 Sep 2007 01:26:58 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Received: (from keramida@localhost) by kobe.laptop (8.14.1/8.14.1/Submit) id l86MQm7d003176; Fri, 7 Sep 2007 01:26:48 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Date: Fri, 7 Sep 2007 01:26:47 +0300 From: Giorgos Keramidas To: Luigi Rizzo Message-ID: <20070906222647.GB2737@kobe.laptop> References: <20070906111028.A83649@xorpc.icir.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070906111028.A83649@xorpc.icir.org> X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-3.872, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.53, BAYES_00 -2.60) X-Hellug-MailScanner-From: keramida@ceid.upatras.gr X-Spam-Status: No Cc: current@freebsd.org Subject: Re: how to tell 64 vs 32 bit architecture ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2007 22:46:04 -0000 On 2007-09-06 11:10, Luigi Rizzo wrote: > hi, > i was wondering what is the proper way to tell a 64 vs 32 bit > architecture. > > I see that some code in sys/ uses ' #ifdef __LP64__ ' but i am not > sure if this is generic enough (ie not gcc or FreeBSD specific), > and also suitable for userland (i.e. works on linux or other platforms > as well). This is usually needed to differentiate between a feature "X" which behaves differently in amd64 vs. i386 vs. sparc vs. sparc64, etc. If this is for userland-code, why can't you test directly for #ifdef HAVE_FEATURE_X (sorry for the autotools/GNU'ism there)? It's safer this way in the long term, because if one of teh architectures which currently lack "feature X" grows support for it, you won't get bitten down the road by the wrong assumption in one of the "#ifdef AMD64" checks in the source. I'm not really suggesting that it is completely wrong to check for the system architecture in general, but I have seen very few use cases for this at ${realjob} at the C preprocessor level. Almost every time someone used "#ifdef __solaris__" or something like "#ifdef __amd64__" it became a pain to debug later when, for example, we upgraded our compiler suite or something :-( - Giorgos From owner-freebsd-current@FreeBSD.ORG Thu Sep 6 23:11:37 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9C3FF16A417 for ; Thu, 6 Sep 2007 23:11:37 +0000 (UTC) (envelope-from dunstan@freebsd.czest.pl) Received: from freebsd.czest.pl (freebsd.czest.pl [80.48.250.4]) by mx1.freebsd.org (Postfix) with ESMTP id F1AC413C442 for ; Thu, 6 Sep 2007 23:11:36 +0000 (UTC) (envelope-from dunstan@freebsd.czest.pl) Received: from freebsd.czest.pl (freebsd.czest.pl [80.48.250.4]) by freebsd.czest.pl (8.13.4/8.12.9) with ESMTP id l86NS9u2024999; Thu, 6 Sep 2007 23:28:09 GMT (envelope-from dunstan@freebsd.czest.pl) Received: (from dunstan@localhost) by freebsd.czest.pl (8.13.4/8.12.9/Submit) id l86NS9iO024998; Thu, 6 Sep 2007 23:28:09 GMT (envelope-from dunstan) Date: Thu, 6 Sep 2007 23:28:08 +0000 From: "Wojciech A. Koszek" To: Alexandre Biancalana Message-ID: <20070906232808.GA24938@FreeBSD.czest.pl> References: <8e10486b0709061137x35a1392bqc28169b1fae1bc01@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline In-Reply-To: <8e10486b0709061137x35a1392bqc28169b1fae1bc01@mail.gmail.com> User-Agent: Mutt/1.4.2.1i X-Greylist: Sender DNS name whitelisted, not delayed by milter-greylist-2.0.2 (freebsd.czest.pl [80.48.250.4]); Thu, 06 Sep 2007 23:28:09 +0000 (UTC) Cc: current@freebsd.org Subject: Re: libexec/ld-elf.so.1: /lib/libc.so.7: version FBSD_1.0 required by ./gengtype not defined X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2007 23:11:37 -0000 On Thu, Sep 06, 2007 at 03:37:31PM -0300, Alexandre Biancalana wrote: > Hi list, > > I installed one with -CURRENT using the following 200704-ZFS snapshot. > After csup the sources, trying to update the buildworld stops with the > following error: > > > cc -O2 -fno-strict-aliasing -pipe -I. -DIN_GCC -DHAVE_CONFIG_H > -DPREFIX=\"/usr\" -I/usr/obj/usr/src/gnu/usr.bin/cc/cc_tools/../cc_tools > -I/usr/src/gnu/usr.bin/cc/cc_tools/../cc_tools > -I/usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc > -I/usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/config > -I/usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/include > -I/usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/libcpp/include > -I/usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/libdecnumber > -g -DGENERATOR_FILE -DHAVE_CONFIG_H -o gengtype > gengtype.ogengtype-yacc+%DIKED.o > gengtype-lex.o errors.o libiberty.a > ./gengtype > /libexec/ld-elf.so.1: /lib/libc.so.7: version FBSD_1.0 required by > ./gengtype not defined > *** Error code 1 I expirienced the very same problem which you described. I tried to compile my sources with various options with no success. I divided upgrade procedure into two, separate but similar steps. First, I fetched src/... version just after symbol versioning has been imported, and it went fine. Once I had my world working, I did second step by fetching the newest sources at that time and compiled them. Warnings you've shown here didn't appear then. -- Wojciech A. Koszek wkoszek@FreeBSD.org http://FreeBSD.czest.pl/dunstan/ From owner-freebsd-current@FreeBSD.ORG Fri Sep 7 03:07:28 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4373916A41A for ; Fri, 7 Sep 2007 03:07:28 +0000 (UTC) (envelope-from oceanare@pacific.net.sg) Received: from smtpgate1.pacific.net.sg (smtpgate1.pacific.net.sg [203.120.90.31]) by mx1.freebsd.org (Postfix) with SMTP id 618DC13C442 for ; Fri, 7 Sep 2007 03:07:27 +0000 (UTC) (envelope-from oceanare@pacific.net.sg) Received: (qmail 2173 invoked from network); 7 Sep 2007 02:39:26 -0000 Received: from bb121-7-106-120.singnet.com.sg (HELO P2120.somewherefaraway.com) (oceanare@121.7.106.120) by smtpgate1.pacific.net.sg with ESMTPA; 7 Sep 2007 02:39:25 -0000 Message-ID: <46E0B9D3.8000505@pacific.net.sg> Date: Fri, 07 Sep 2007 10:39:15 +0800 From: Erich Dollansky User-Agent: Thunderbird 2.0.0.6 (X11/20070826) MIME-Version: 1.0 To: Luigi Rizzo References: <20070906111028.A83649@xorpc.icir.org> <54b90fdf0709061225q48af11c2yca8d330eff514159@mail.gmail.com> <20070906125439.A84696@xorpc.icir.org> In-Reply-To: <20070906125439.A84696@xorpc.icir.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Yan , current@freebsd.org Subject: Re: how to tell 64 vs 32 bit architecture ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2007 03:07:28 -0000 Hi, I have not found a method yet whic works 100% and is portable. Luigi Rizzo wrote: > On Thu, Sep 06, 2007 at 03:25:52PM -0400, Yan wrote: Consider this: >> Perhaps "if(sizeof(void*)==4) { /* 32 */} else if(sizeof(void*) ==8) { /* 64 >> */ }" ? >> and also sizeof (int) The rest will be platform specific. Erich From owner-freebsd-current@FreeBSD.ORG Fri Sep 7 03:26:52 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C13AB16A418 for ; Fri, 7 Sep 2007 03:26:52 +0000 (UTC) (envelope-from davids@webmaster.com) Received: from mail1.webmaster.com (mail1.webmaster.com [216.152.64.169]) by mx1.freebsd.org (Postfix) with ESMTP id A770313C474 for ; Fri, 7 Sep 2007 03:26:52 +0000 (UTC) (envelope-from davids@webmaster.com) Received: from however by webmaster.com (MDaemon.PRO.v8.1.3.R) with ESMTP id md50001666549.msg for ; Thu, 06 Sep 2007 20:16:10 -0700 From: "David Schwartz" To: "Current@Freebsd. Org" Date: Thu, 6 Sep 2007 20:15:24 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <46E0B9D3.8000505@pacific.net.sg> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Importance: Normal X-Authenticated-Sender: joelkatz@webmaster.com X-Spam-Processed: mail1.webmaster.com, Thu, 06 Sep 2007 20:16:10 -0700 (not processed: message from trusted or authenticated source) X-MDRemoteIP: 206.171.168.138 X-Return-Path: davids@webmaster.com X-MDaemon-Deliver-To: current@freebsd.org X-MDAV-Processed: mail1.webmaster.com, Thu, 06 Sep 2007 20:16:10 -0700 Cc: Subject: RE: how to tell 64 vs 32 bit architecture ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: davids@webmaster.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2007 03:26:52 -0000 > I have not found a method yet whic works 100% and is portable. Only because terms like "32-bit architecture" are not well-defined. If you can define more precisely what it is you really want to test for, it may become more obvious how to test for it. DS From owner-freebsd-current@FreeBSD.ORG Fri Sep 7 06:24:51 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C0C3716A418 for ; Fri, 7 Sep 2007 06:24:51 +0000 (UTC) (envelope-from spawk@acm.poly.edu) Received: from acm.poly.edu (acm.poly.edu [128.238.9.200]) by mx1.freebsd.org (Postfix) with ESMTP id 8C0FD13C469 for ; Fri, 7 Sep 2007 06:24:51 +0000 (UTC) (envelope-from spawk@acm.poly.edu) Received: (qmail 88164 invoked from network); 7 Sep 2007 05:59:40 -0000 Received: from unknown (HELO ?192.168.0.2?) (spawk@69.123.41.145) by acm.poly.edu with AES256-SHA encrypted SMTP; 7 Sep 2007 05:59:40 -0000 Message-ID: <46E0E85E.3080809@acm.poly.edu> Date: Fri, 07 Sep 2007 01:57:50 -0400 From: Boris Kochergin User-Agent: Thunderbird 2.0.0.0 (X11/20070609) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: how to tell 64 vs 32 bit architecture ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2007 06:24:51 -0000 I don't know about 100% portable, but the following works across FreeBSD, Linux, and Solaris since at least GCC 2.95: __LONG_BIT (as found in /usr/include/machine/_limits.h on FreeBSD) is #defined as 32 on 32-bit machines and 64 on 64-bit machines. I suspect it may even be part of a standard as the comments at the top of that file indicate so. -Boris From owner-freebsd-current@FreeBSD.ORG Fri Sep 7 06:33:08 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DA2FE16A418 for ; Fri, 7 Sep 2007 06:33:08 +0000 (UTC) (envelope-from brucec@muon.bluestop.org) Received: from muon.bluestop.org (muon.bluestop.org [80.68.94.188]) by mx1.freebsd.org (Postfix) with ESMTP id A0B3813C468 for ; Fri, 7 Sep 2007 06:33:08 +0000 (UTC) (envelope-from brucec@muon.bluestop.org) Received: by muon.bluestop.org (Postfix, from userid 1000) id BF7A33010B; Fri, 7 Sep 2007 07:28:59 +0100 (BST) Date: Fri, 7 Sep 2007 07:28:59 +0100 From: bruce@cran.org.uk To: Erich Dollansky Message-ID: <20070907062859.GA15310@muon.bluestop.org> References: <20070906111028.A83649@xorpc.icir.org> <54b90fdf0709061225q48af11c2yca8d330eff514159@mail.gmail.com> <20070906125439.A84696@xorpc.icir.org> <46E0B9D3.8000505@pacific.net.sg> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46E0B9D3.8000505@pacific.net.sg> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: Luigi Rizzo , Yan , current@freebsd.org Subject: Re: how to tell 64 vs 32 bit architecture ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2007 06:33:08 -0000 On Fri, Sep 07, 2007 at 10:39:15AM +0800, Erich Dollansky wrote: > Hi, > > I have not found a method yet whic works 100% and is portable. > > Luigi Rizzo wrote: > >On Thu, Sep 06, 2007 at 03:25:52PM -0400, Yan wrote: > > Consider this: > > >>Perhaps "if(sizeof(void*)==4) { /* 32 */} else if(sizeof(void*) ==8) { /* > >>64 > >>*/ }" ? > >> > and also > > sizeof (int) > > The rest will be platform specific. > An int usually remains as 4 bytes on 64-bit platforms; long changes to 64-bit. -- Bruce Cran From owner-freebsd-current@FreeBSD.ORG Fri Sep 7 07:11:59 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 45DE316A417 for ; Fri, 7 Sep 2007 07:11:59 +0000 (UTC) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.freebsd.org (Postfix) with ESMTP id 2603213C49D for ; Fri, 7 Sep 2007 07:11:59 +0000 (UTC) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.13.6) with ESMTP id l8779odJ091235; Fri, 7 Sep 2007 00:09:50 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id l8779o1Q091234; Fri, 7 Sep 2007 00:09:50 -0700 (PDT) (envelope-from rizzo) Date: Fri, 7 Sep 2007 00:09:50 -0700 From: Luigi Rizzo To: Giorgos Keramidas Message-ID: <20070907000950.A91211@xorpc.icir.org> References: <20070906111028.A83649@xorpc.icir.org> <20070906222647.GB2737@kobe.laptop> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20070906222647.GB2737@kobe.laptop>; from keramida@ceid.upatras.gr on Fri, Sep 07, 2007 at 01:26:47AM +0300 Cc: current@freebsd.org Subject: Re: how to tell 64 vs 32 bit architecture ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2007 07:11:59 -0000 On Fri, Sep 07, 2007 at 01:26:47AM +0300, Giorgos Keramidas wrote: > On 2007-09-06 11:10, Luigi Rizzo wrote: > > hi, > > i was wondering what is the proper way to tell a 64 vs 32 bit > > architecture. > > > > I see that some code in sys/ uses ' #ifdef __LP64__ ' but i am not > > sure if this is generic enough (ie not gcc or FreeBSD specific), > > and also suitable for userland (i.e. works on linux or other platforms > > as well). > > This is usually needed to differentiate between a feature "X" which > behaves differently in amd64 vs. i386 vs. sparc vs. sparc64, etc. i am actually looking at pointer sizes, as i need to do some pointer manipulation going through intptr_t, and need to know that in the preprocessor because some constants need to be 32 or 64 bit depending on that, and are not trivial (i.e. not 0, 1 or something i can build with size-agnostic expressions) cheers luigi From owner-freebsd-current@FreeBSD.ORG Fri Sep 7 11:51:15 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 890E216A421 for ; Fri, 7 Sep 2007 11:51:15 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.freebsd.org (Postfix) with ESMTP id 09B6913C48A for ; Fri, 7 Sep 2007 11:51:14 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from kobe.laptop (vader.bytemobile.ondsl.gr [83.235.244.135]) (authenticated bits=128) by igloo.linux.gr (8.14.1/8.14.1/Debian-8) with ESMTP id l87Bog78021844 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 7 Sep 2007 14:51:03 +0300 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.1/8.14.1) with ESMTP id l87BoN5g002793; Fri, 7 Sep 2007 14:50:39 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Received: (from keramida@localhost) by kobe.laptop (8.14.1/8.14.1/Submit) id l87BoMcH002792; Fri, 7 Sep 2007 14:50:22 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Date: Fri, 7 Sep 2007 14:50:21 +0300 From: Giorgos Keramidas To: Luigi Rizzo Message-ID: <20070907115021.GA2718@kobe.laptop> References: <20070906111028.A83649@xorpc.icir.org> <20070906222647.GB2737@kobe.laptop> <20070907000950.A91211@xorpc.icir.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070907000950.A91211@xorpc.icir.org> X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-3.96, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.44, BAYES_00 -2.60) X-Hellug-MailScanner-From: keramida@ceid.upatras.gr X-Spam-Status: No Cc: current@freebsd.org Subject: Re: how to tell 64 vs 32 bit architecture ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2007 11:51:15 -0000 On 2007-09-07 00:09, Luigi Rizzo wrote: >On Fri, Sep 07, 2007 at 01:26:47AM +0300, Giorgos Keramidas wrote: >>On 2007-09-06 11:10, Luigi Rizzo wrote: >>> hi, >>> i was wondering what is the proper way to tell a 64 vs 32 bit >>> architecture. >>> >>> I see that some code in sys/ uses ' #ifdef __LP64__ ' but i am not >>> sure if this is generic enough (ie not gcc or FreeBSD specific), >>> and also suitable for userland (i.e. works on linux or other platforms >>> as well). >> >> This is usually needed to differentiate between a feature "X" which >> behaves differently in amd64 vs. i386 vs. sparc vs. sparc64, etc. > > i am actually looking at pointer sizes, as i need to do some pointer > manipulation going through intptr_t, and need to know that in the > preprocessor because some constants need to be 32 or 64 bit depending > on that, and are not trivial (i.e. not 0, 1 or something i can build > with size-agnostic expressions) An intptr_t can safely hold any void pointer value, and C99 says: % 7.18.1.4 Integer types capable of holding object pointers % % 1 The following type designates a signed integer type with the % property that any valid pointer to void can be converted to % this type, then converted back to pointer to void, and the % result will compare equal to the original pointer: % % intptr_t What sort of manipulation? Can this sort of manipulation be written in a way that uses sizeof(intptr_t) instead of 4, 8, or preprocessor magic? If not, then I can't think of any cross-compiler and cross-platform way to check in the preprocessor, and you may have to resort to custom checks (i.e. like those written in autoconf scripts) :-( - Giorgos From owner-freebsd-current@FreeBSD.ORG Fri Sep 7 12:05:42 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9855916A41B for ; Fri, 7 Sep 2007 12:05:42 +0000 (UTC) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.freebsd.org (Postfix) with ESMTP id 70D5413C45E for ; Fri, 7 Sep 2007 12:05:42 +0000 (UTC) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.13.6) with ESMTP id l87C3AM6094682; Fri, 7 Sep 2007 05:03:10 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id l87C3Ac6094681; Fri, 7 Sep 2007 05:03:10 -0700 (PDT) (envelope-from rizzo) Date: Fri, 7 Sep 2007 05:03:10 -0700 From: Luigi Rizzo To: Giorgos Keramidas Message-ID: <20070907050310.A94579@xorpc.icir.org> References: <20070906111028.A83649@xorpc.icir.org> <20070906222647.GB2737@kobe.laptop> <20070907000950.A91211@xorpc.icir.org> <20070907115021.GA2718@kobe.laptop> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20070907115021.GA2718@kobe.laptop>; from keramida@ceid.upatras.gr on Fri, Sep 07, 2007 at 02:50:21PM +0300 Cc: current@freebsd.org Subject: Re: how to tell 64 vs 32 bit architecture ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2007 12:05:42 -0000 On Fri, Sep 07, 2007 at 02:50:21PM +0300, Giorgos Keramidas wrote: > On 2007-09-07 00:09, Luigi Rizzo wrote: > >On Fri, Sep 07, 2007 at 01:26:47AM +0300, Giorgos Keramidas wrote: > >>On 2007-09-06 11:10, Luigi Rizzo wrote: > >>> hi, > >>> i was wondering what is the proper way to tell a 64 vs 32 bit > >>> architecture. > >>> > >>> I see that some code in sys/ uses ' #ifdef __LP64__ ' but i am not > >>> sure if this is generic enough (ie not gcc or FreeBSD specific), > >>> and also suitable for userland (i.e. works on linux or other platforms > >>> as well). > >> > >> This is usually needed to differentiate between a feature "X" which > >> behaves differently in amd64 vs. i386 vs. sparc vs. sparc64, etc. > > > > i am actually looking at pointer sizes, as i need to do some pointer > > manipulation going through intptr_t, and need to know that in the > > preprocessor because some constants need to be 32 or 64 bit depending > > on that, and are not trivial (i.e. not 0, 1 or something i can build > > with size-agnostic expressions) > > An intptr_t can safely hold any void pointer value, and C99 says: > > % 7.18.1.4 Integer types capable of holding object pointers > % > % 1 The following type designates a signed integer type with the > % property that any valid pointer to void can be converted to > % this type, then converted back to pointer to void, and the > % result will compare equal to the original pointer: > % > % intptr_t > > What sort of manipulation? Can this sort of manipulation be written in > a way that uses sizeof(intptr_t) instead of 4, 8, or preprocessor magic? i need to do this: #ifdef BUILT_FOR_64BIT_POINTERS #define MY_MAGIC 0xdeadbeefd00de123 /* 64 bit */ #else #define MY_MAGIC 0xdeadbeef /* 32 bit */ If you know of a way to implement this without preprocessor magic, i am all ears. If the values were simpler (eg all ones or so) i could have used ~((unitptr_t)0) but this is not the case here cheers luigi From owner-freebsd-current@FreeBSD.ORG Fri Sep 7 12:50:11 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3DEEC16A417 for ; Fri, 7 Sep 2007 12:50:11 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.freebsd.org (Postfix) with ESMTP id B43EA13C457 for ; Fri, 7 Sep 2007 12:50:10 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from kobe.laptop (vader.bytemobile.ondsl.gr [83.235.244.135]) (authenticated bits=128) by igloo.linux.gr (8.14.1/8.14.1/Debian-8) with ESMTP id l87CnuVr025449 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 7 Sep 2007 15:50:02 +0300 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.1/8.14.1) with ESMTP id l87CneC9003477; Fri, 7 Sep 2007 15:49:55 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Received: (from keramida@localhost) by kobe.laptop (8.14.1/8.14.1/Submit) id l87CndPd003476; Fri, 7 Sep 2007 15:49:39 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Date: Fri, 7 Sep 2007 15:49:39 +0300 From: Giorgos Keramidas To: Luigi Rizzo Message-ID: <20070907124938.GE3164@kobe.laptop> References: <20070906111028.A83649@xorpc.icir.org> <20070906222647.GB2737@kobe.laptop> <20070907000950.A91211@xorpc.icir.org> <20070907115021.GA2718@kobe.laptop> <20070907050310.A94579@xorpc.icir.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070907050310.A94579@xorpc.icir.org> X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-3.96, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.44, BAYES_00 -2.60) X-Hellug-MailScanner-From: keramida@ceid.upatras.gr X-Spam-Status: No Cc: current@freebsd.org Subject: Re: how to tell 64 vs 32 bit architecture ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2007 12:50:11 -0000 On 2007-09-07 05:03, Luigi Rizzo wrote: >On Fri, Sep 07, 2007 at 02:50:21PM +0300, Giorgos Keramidas wrote: >>> i am actually looking at pointer sizes, as i need to do some pointer >>> manipulation going through intptr_t, and need to know that in the >>> preprocessor because some constants need to be 32 or 64 bit depending >>> on that, and are not trivial (i.e. not 0, 1 or something i can build >>> with size-agnostic expressions) >> >> An intptr_t can safely hold any void pointer value [..a.] >> What sort of manipulation? Can this sort of manipulation be written in >> a way that uses sizeof(intptr_t) instead of 4, 8, or preprocessor magic? > > i need to do this: > > #ifdef BUILT_FOR_64BIT_POINTERS > #define MY_MAGIC 0xdeadbeefd00de123 /* 64 bit */ > #else > #define MY_MAGIC 0xdeadbeef /* 32 bit */ > > If you know of a way to implement this without preprocessor > magic, i am all ears. If the values were simpler (eg all ones or so) > i could have used ~((unitptr_t)0) but this is not the case here You essentially want sizeof() at the preprocessor context. I don't think this is possible to write portably without preprocessor magic. From owner-freebsd-current@FreeBSD.ORG Fri Sep 7 13:39:13 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4B82216A46D for ; Fri, 7 Sep 2007 13:39:13 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from relay02.kiev.sovam.com (relay02.kiev.sovam.com [62.64.120.197]) by mx1.freebsd.org (Postfix) with ESMTP id 04E2013C474 for ; Fri, 7 Sep 2007 13:39:12 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from [212.82.216.226] (helo=deviant.kiev.zoral.com.ua) by relay02.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1ITe35-0000KJ-GP; Fri, 07 Sep 2007 16:39:11 +0300 Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.1/8.14.1) with ESMTP id l87Dd1hP090794; Fri, 7 Sep 2007 16:39:01 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.1/8.14.1/Submit) id l87Dd1Et090793; Fri, 7 Sep 2007 16:39:01 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 7 Sep 2007 16:39:01 +0300 From: Kostik Belousov To: Nate Lawson Message-ID: <20070907133901.GL53667@deviant.kiev.zoral.com.ua> References: <46E0777A.8070901@root.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="AGBBLMjITsWHeOTZ" Content-Disposition: inline In-Reply-To: <46E0777A.8070901@root.org> User-Agent: Mutt/1.4.2.3i X-Scanner-Signature: 6f32a619495bd298c8ed4cb100af0918 X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Info: Profiles 1448 [September 7 2007] X-SpamTest-Info: helo_type=3 X-SpamTest-Info: {received from trusted relay: not dialup} X-SpamTest-Method: none X-SpamTest-Method: Local Lists X-SpamTest-Rate: 0 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0255], KAS30/Release Cc: acpi@freebsd.org, current@freebsd.org Subject: Re: PATCH: ecng for 6.x and 7.x X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2007 13:39:13 -0000 --AGBBLMjITsWHeOTZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Sep 06, 2007 at 02:56:10PM -0700, Nate Lawson wrote: > I've done some major rework on the EC driver. This should help with > various problems, including timeouts while checking battery status or > temperature. The attached patches are for 6.x and 7.x. Please test and > let me know if you get any new errors on dmesg or if it fixes things for > you (especially HP/Compaq laptop owners). Ok, I tryed it on Acer 2490-kind of laptop. I see no difference with the patch, battery status seems to be reported correctly both before and after applying it. The only thing I want to note is that reboot on the laptop is turned into poweroff. You said in the followup to original letter that poweroff is turned into reboot, I did not checked it; this is opposite. --AGBBLMjITsWHeOTZ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFG4VR0C3+MBN1Mb4gRAhBEAJ45Z0nSQC0KmE7SZ8FzsO/IGIF9+ACgz06G WnZnKNF3YLngTp7ayVFWKus= =sgd4 -----END PGP SIGNATURE----- --AGBBLMjITsWHeOTZ-- From owner-freebsd-current@FreeBSD.ORG Fri Sep 7 13:50:07 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7980E16A417 for ; Fri, 7 Sep 2007 13:50:07 +0000 (UTC) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.freebsd.org (Postfix) with ESMTP id 721BC13C46E for ; Fri, 7 Sep 2007 13:50:07 +0000 (UTC) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.13.6) with ESMTP id l87Dmpkm095996; Fri, 7 Sep 2007 06:48:51 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id l87DmpOg095995; Fri, 7 Sep 2007 06:48:51 -0700 (PDT) (envelope-from rizzo) Date: Fri, 7 Sep 2007 06:48:51 -0700 From: Luigi Rizzo To: current@freebsd.org Message-ID: <20070907064851.A95655@xorpc.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i Cc: Subject: diskless system freeze in bios16_call() on some Intel motherboards X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2007 13:50:07 -0000 Hi, we are having some annoying problems with a number of Intel motherboards (Pentium4, ich6 and ich7 based, the laters are on D945PAW boards with SN94510J.86A bios if that matters). The symptoms are that booting a 6.x or 7.x kernel with etherboot causes a system freeze. This happens also if we try to etherboot the kernel from a 6.2 install CD. On the other hand, on the same hardware: - a 4.11 kernel booted with etherboot boots ok. - a 6.2 install CD boots ok; - a 6.2 install CD with the kernel replaced with ours boots ok. So it seems that at least part of the problem is how the execution environment is set up by etherboot as opposed to /boot/loader . However, it is still unclear to me why the 4.11 kernel works. After some instrumenting, it turns out that the freeze is in the call to bios16_call, and specifically in this line in sys/i386/i386/bioscall.s lcallw *bioscall_vector /* 16-bit call */ Looking at the arguments there is nothing strange - the selector is 0x70 as on other machines, the address seems reasonable. If I comment out the lcallw, then things proceed, but apparently the interrupt for the network card is not set up correctly because the subsequent bootp replies are not received (i see them on the server with tcpdump) and have 'watchdog timeout' messages on the console of the diskless client. Any ideas on what could the problem be ? cheers luigi From owner-freebsd-current@FreeBSD.ORG Fri Sep 7 13:54:38 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6DC4516A41A for ; Fri, 7 Sep 2007 13:54:38 +0000 (UTC) (envelope-from rottled@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.185]) by mx1.freebsd.org (Postfix) with ESMTP id B93F913C48D for ; Fri, 7 Sep 2007 13:54:36 +0000 (UTC) (envelope-from rottled@gmail.com) Received: by nf-out-0910.google.com with SMTP id k4so389357nfd for ; Fri, 07 Sep 2007 06:54:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=HZmEXrhmDEN6ERMx6mMwZwEDbtIYWQhSVpsd9CBhPUk=; b=fP6PL3b/CgH/SsV82w4FUlsN+jPbN5oEmOiPcY4BpJqciEpFKe9MbWvlp0vTNI1ZewwFZuKsn2ZkxhgOqgaJx43lrVKSIQH5fZwv2D+w9PWhfCNqg5cMUbNiyowhTyioN2P4TR3oN0EuxaIkTZl70fTOu98yllBcfozQHggl9JU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=Sd1SKhzwCOpCC3EbaqBg6+9ABmCiLbC0Y5KyrbvK2v+wKGNzWJm0CKh1AR1g/N7pbyiFesbSR6DEguNBIzMV/rTCNHRHb9Z/20OWbwQbd6Iy+ejsS6gxKt1HduY2e2LH2WnhYIGhH5nU+cTUBoibYwXxK2wY2dXqkg7lKq5kw8I= Received: by 10.86.51.2 with SMTP id y2mr1454996fgy.1189173275554; Fri, 07 Sep 2007 06:54:35 -0700 (PDT) Received: by 10.86.25.18 with HTTP; Fri, 7 Sep 2007 06:54:35 -0700 (PDT) Message-ID: <54b90fdf0709070654h103316f3sa3d423f4ff75fee3@mail.gmail.com> Date: Fri, 7 Sep 2007 09:54:35 -0400 From: Yan To: "Luigi Rizzo" In-Reply-To: <20070907050310.A94579@xorpc.icir.org> MIME-Version: 1.0 References: <20070906111028.A83649@xorpc.icir.org> <20070906222647.GB2737@kobe.laptop> <20070907000950.A91211@xorpc.icir.org> <20070907115021.GA2718@kobe.laptop> <20070907050310.A94579@xorpc.icir.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: current@freebsd.org Subject: Re: how to tell 64 vs 32 bit architecture ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2007 13:54:38 -0000 How about this: #define MY_MAGIC ((sizeof(intptr_t)==4) ? 0Xdeadbeef : 0xdeadbeefd00de123) You can also test it via 'if(sizeof(intptr_t)&0x4)'. This is assuming you won't run this on a 16 bit architecture :p -yan On 9/7/07, Luigi Rizzo wrote: > > On Fri, Sep 07, 2007 at 02:50:21PM +0300, Giorgos Keramidas wrote: > > On 2007-09-07 00:09, Luigi Rizzo wrote: > > >On Fri, Sep 07, 2007 at 01:26:47AM +0300, Giorgos Keramidas wrote: > > >>On 2007-09-06 11:10, Luigi Rizzo wrote: > > >>> hi, > > >>> i was wondering what is the proper way to tell a 64 vs 32 bit > > >>> architecture. > > >>> > > >>> I see that some code in sys/ uses ' #ifdef __LP64__ ' but i am not > > >>> sure if this is generic enough (ie not gcc or FreeBSD specific), > > >>> and also suitable for userland (i.e. works on linux or other > platforms > > >>> as well). > > >> > > >> This is usually needed to differentiate between a feature "X" which > > >> behaves differently in amd64 vs. i386 vs. sparc vs. sparc64, etc. > > > > > > i am actually looking at pointer sizes, as i need to do some pointer > > > manipulation going through intptr_t, and need to know that in the > > > preprocessor because some constants need to be 32 or 64 bit depending > > > on that, and are not trivial (i.e. not 0, 1 or something i can build > > > with size-agnostic expressions) > > > > An intptr_t can safely hold any void pointer value, and C99 says: > > > > % 7.18.1.4 Integer types capable of holding object pointers > > % > > % 1 The following type designates a signed integer type with the > > % property that any valid pointer to void can be converted to > > % this type, then converted back to pointer to void, and the > > % result will compare equal to the original pointer: > > % > > % intptr_t > > > > What sort of manipulation? Can this sort of manipulation be written in > > a way that uses sizeof(intptr_t) instead of 4, 8, or preprocessor magic? > > i need to do this: > > #ifdef BUILT_FOR_64BIT_POINTERS > #define MY_MAGIC 0xdeadbeefd00de123 /* 64 bit */ > #else > #define MY_MAGIC 0xdeadbeef /* 32 bit */ > > If you know of a way to implement this without preprocessor > magic, i am all ears. If the values were simpler (eg all ones or so) > i could have used ~((unitptr_t)0) but this is not the case here > > cheers > luigi > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Fri Sep 7 14:49:45 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0D47416A419 for ; Fri, 7 Sep 2007 14:49:45 +0000 (UTC) (envelope-from alexandre.delay@free.fr) Received: from postfix2-g20.free.fr (postfix2-g20.free.fr [212.27.60.43]) by mx1.freebsd.org (Postfix) with ESMTP id BE88113C458 for ; Fri, 7 Sep 2007 14:49:44 +0000 (UTC) (envelope-from alexandre.delay@free.fr) Received: from smtp6-g19.free.fr (smtp6-g19.free.fr [212.27.42.36]) by postfix2-g20.free.fr (Postfix) with ESMTP id E29D61A014CC for ; Fri, 7 Sep 2007 15:15:22 +0200 (CEST) Received: from smtp6-g19.free.fr (localhost.localdomain [127.0.0.1]) by smtp6-g19.free.fr (Postfix) with ESMTP id 7730ACA594 for ; Fri, 7 Sep 2007 16:14:25 +0200 (CEST) Received: from imp4-g19.free.fr (imp4-g19.free.fr [212.27.42.4]) by smtp6-g19.free.fr (Postfix) with ESMTP id 72ABDCA671 for ; Fri, 7 Sep 2007 16:14:25 +0200 (CEST) Received: by imp4-g19.free.fr (Postfix, from userid 33) id E350E12649; Fri, 7 Sep 2007 17:14:24 +0200 (CEST) Received: from smtp.cerbere3.com (smtp.cerbere3.com [82.241.190.84]) by imp.free.fr (IMP) with HTTP for ; Fri, 07 Sep 2007 17:14:24 +0200 Message-ID: <1189178064.46e16ad0a941a@imp.free.fr> Date: Fri, 07 Sep 2007 17:14:24 +0200 From: alexandre.delay@free.fr To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.5 X-Originating-IP: 82.241.190.84 Subject: diffuse audio through modem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2007 14:49:45 -0000 Hi! I'm searching the way to call, from my freebsd box connected to a serial modem, a phone number and diffuse audio (wav, mp3 or wathever). Does anyone has a light to help me find the way? cheers Alex From owner-freebsd-current@FreeBSD.ORG Fri Sep 7 15:07:52 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F181A16A420 for ; Fri, 7 Sep 2007 15:07:51 +0000 (UTC) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.freebsd.org (Postfix) with ESMTP id EA5E713C478 for ; Fri, 7 Sep 2007 15:07:51 +0000 (UTC) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.13.6) with ESMTP id l87F6ZAl096897; Fri, 7 Sep 2007 08:06:35 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id l87F6Zd1096896; Fri, 7 Sep 2007 08:06:35 -0700 (PDT) (envelope-from rizzo) Date: Fri, 7 Sep 2007 08:06:35 -0700 From: Luigi Rizzo To: current@freebsd.org Message-ID: <20070907080635.A96828@xorpc.icir.org> References: <20070907064851.A95655@xorpc.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20070907064851.A95655@xorpc.icir.org>; from rizzo@icir.org on Fri, Sep 07, 2007 at 06:48:51AM -0700 Cc: Subject: Re: diskless system freeze in bios16_call() on some Intel motherboards X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2007 15:07:52 -0000 [note, all these tests have been done on -stable, though -current kernel exhibits the same problems in some of the tests so i suspect there is a common problem] On Fri, Sep 07, 2007 at 06:48:51AM -0700, Luigi Rizzo wrote: > Hi, > we are having some annoying problems with a number of Intel > motherboards (Pentium4, ich6 and ich7 based, the laters are on > D945PAW boards with SN94510J.86A bios if that matters). > > The symptoms are that booting a 6.x or 7.x kernel with > etherboot causes a system freeze. This happens also if we > try to etherboot the kernel from a 6.2 install CD. > > On the other hand, on the same hardware: > - a 4.11 kernel booted with etherboot boots ok. > - a 6.2 install CD boots ok; > - a 6.2 install CD with the kernel replaced with ours boots ok. > > So it seems that at least part of the problem is how > the execution environment is set up by etherboot as opposed to > /boot/loader . However, it is still unclear to me why the 4.11 kernel > works. > > After some instrumenting, it turns out that the freeze is in the > call to bios16_call, and specifically in this line in > sys/i386/i386/bioscall.s > > lcallw *bioscall_vector /* 16-bit call */ > > Looking at the arguments there is nothing strange - the selector is > 0x70 as on other machines, the address seems reasonable. > If I comment out the lcallw, then things proceed, but apparently the > interrupt for the network card is not set up correctly because the > subsequent bootp replies are not received (i see them on the > server with tcpdump) and have 'watchdog timeout' messages on the console > of the diskless client. > > Any ideas on what could the problem be ? For the benefit of the archives, and upon further investigation: the problem is definitely related to pnpbios/bios16 calls. One of the difference between the CD and etherboot is that the CD loads acpi.ko as a module. This apparently prevent the calls to the offending pnpbios stuff, and also lets the apic code correctly configure things. The following causes a PANIC: - booting from etherboot with acpi compiled-in the kernel itself panics in pmap_mapbios(), right after calling AcpiOsMapMemory() . The following causes the system to FREEZE: - booting from etherboot without acpi, with SMP+apic, and with bios16_call() uncommented (essentially it is this call that causes the freeze). - booting from CD without loading acpi.ko (the 'safe mode'!). This too causes the call to bios16_call() which in turn freezes. the following causes 'WATCHDOG TIMEOUT' on the network card: - booting from etherboot with SMP+apic, bios16_call() commented out, and no acpi. Presumably, the apic does not route interrupts properly on this hardware without acpi. finally, the following WORKS WELL: - boot from etherboot without SMP, without acpi, without apic., and commenting out the call to bios16_call() in bios.c This is probably using the hardware in a similar way to what 4.11 does. Note however that we need to patch the kernel source. - boot from the CD, loading acpi.ko as a module, and irrespective of SMP+apic. I don't know why loading acpi.ko as a module works better than compiled in, but perhaps it is related to the order in which the functions are called ? I cannot do more tests now, but surely it would be interesting to see what changes in acpi between compiled-in and kldloaded. cheers luigi From owner-freebsd-current@FreeBSD.ORG Fri Sep 7 15:20:09 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0686316A417 for ; Fri, 7 Sep 2007 15:20:09 +0000 (UTC) (envelope-from william88@gmail.com) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.186]) by mx1.freebsd.org (Postfix) with ESMTP id DA27013C46B for ; Fri, 7 Sep 2007 15:20:08 +0000 (UTC) (envelope-from william88@gmail.com) Received: by rv-out-0910.google.com with SMTP id l15so442307rvb for ; Fri, 07 Sep 2007 08:19:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=WeFlSH0vdSQXVYJYF15pW19kXBEu4PtangqjEs9T8WY=; b=j78Q9knhhyzw0VfRoQZNX0EE5j6ZTZe7wz/YvBhy4SsmOHCMG0gBF1Q9DobIvFOmYHcfH2loqkP4GI0aNsyEn6+xv2WPG2SyKxBEBiJaLHQNQuHKgMuGGKldTrmquN86ZGjDyakdoZZPmFaOvcOeHMAukYwoRx0JymzEDMkL+Ss= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=QESA720hmDL+IZpkvCzBVhW71f9mCuvaYNWADAr7m+COrlHkugon5K4WZQ9B4KPPxhB4iRdXlQw7cDgaT4aK0Yxu96faf4JYRzqYF153FV0iQih5o8nSTehTJR1ResNk8K9Ul4/QZ32PMCS5Ld/BQiWgMz1eciFOXBv/dGIrfrY= Received: by 10.140.174.11 with SMTP id w11mr751415rve.1189176749501; Fri, 07 Sep 2007 07:52:29 -0700 (PDT) Received: by 10.141.136.13 with HTTP; Fri, 7 Sep 2007 07:52:29 -0700 (PDT) Message-ID: <632825b40709070752o6fe867a2s3e7647e5444b1b5b@mail.gmail.com> Date: Fri, 7 Sep 2007 11:52:29 -0300 From: "William Grzybowski" To: "Nate Lawson" In-Reply-To: <46E07AAF.2060000@root.org> MIME-Version: 1.0 References: <46E0777A.8070901@root.org> <46E07AAF.2060000@root.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: acpi@freebsd.org, current@freebsd.org Subject: Re: PATCH: ecng for 6.x and 7.x X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2007 15:20:09 -0000 On 9/6/07, Nate Lawson wrote: > > Nate Lawson wrote: > > I've done some major rework on the EC driver. This should help with > > various problems, including timeouts while checking battery status or > > temperature. The attached patches are for 6.x and 7.x. Please test and > > let me know if you get any new errors on dmesg or if it fixes things for > > you (especially HP/Compaq laptop owners). > > > > If you still have problems, try setting each of these tunables > > individually and then both together (i.e., in /boot/loader.conf). Note > > that this will be four (4) test runs total, so don't just set both and > > say it doesn't work. > > > > debug.acpi.ec.burst="1" > > debug.acpi.ec.polled="1" > > > > I've tested both patches on a Panasonic Y4 and UnnamedOEM laptop, no > > problems in either regular or burst mode. > > > > > > Commit message: > > Rewrite the EC driver event model. The main goal is to avoid > > polling/interrupt-driven fallback and instead use polling only during > > boot and pure interrupt-driven mode after boot. Polled mode could be > > relegated completely to a legacy role if we could enable interrupts > > during boot. Polled mode can be forced after boot by setting > > debug.acpi.ec.polled="1", i.e. if there are timeouts. > > One minor note -- power off shutdown (shutdown/halt -p) is turned into a > (safe) reboot with this patch. I have tested the fix, which is just to > force polled mode during shutdown as well. I don't have time to re-roll > the patch today but will send tomorrow. > > Please test the patch as posted, ignoring that minor issue. The test > results during normal use are still valid. > Hi Nate, I tested this patch on my acer notebook (intel chipset) and i did not notice any changes, unless some errors on dmesg, like: acpi_ec0: EcCommand: no response to 0x84 acpi_ec0: GPE query failed: AE_NO_HARDWARE_RESPONSE acpi_ec0: EcCommand: no response to 0x82 acpi_ec0: EcCommand: no response to 0x80 ACPI Error (psparse-0626): Method parse/execution failed [\\_TZ_.THRM._TMP] (Node 0xc3bbdcc0), AE_NO_HARDWARE_RESPONSE ACPI Error (psparse-0626): Method parse/execution failed [\\_SB_.ACAD._PSR] (Node 0xc3bc02a0), AE_NO_HARDWARE_RESPONSE I tried the 4 test runs which you mentioned , when I boot with both debug.acpi (burst and polled = 1) I got a kernel panic but i couldn't save the backtrace, but it was about _sx_xlock_hard in recursed on non-recursive function, line 209 on acpi_ec.c I'm send links for 3 verbose boot's (i couldnt for burst and polled because the panic) if you want to take a look.. http://www.inf.ufpr.br/wg06/dmesg-acpi-ec.gz http://www.inf.ufpr.br/wg06/dmesg-acpi-ec-burst.gz http://www.inf.ufpr.br/wg06/dmesg-acpi-ec-polled.gz Thanks, bye. -- William Grzybowski ------------------------------------------ Jabber: william88 at gmail dot com Curitiba/PR - Brazil From owner-freebsd-current@FreeBSD.ORG Fri Sep 7 15:21:24 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5220816A468 for ; Fri, 7 Sep 2007 15:21:24 +0000 (UTC) (envelope-from fabio@freebsd.org) Received: from sssup.it (ms01.sssup.it [193.205.80.99]) by mx1.freebsd.org (Postfix) with ESMTP id DF9E513C45A for ; Fri, 7 Sep 2007 15:21:23 +0000 (UTC) (envelope-from fabio@freebsd.org) Received: from [10.30.3.4] (HELO granpasso.retis) by sssup.it (CommuniGate Pro SMTP 4.1.8) with SMTP id 33656854 for current@freebsd.org; Fri, 07 Sep 2007 16:10:53 +0200 Received: (qmail 45522 invoked from network); 7 Sep 2007 14:21:11 -0000 Received: from unknown (HELO granpasso.retis) (127.0.0.1) by localhost.retis with SMTP; 7 Sep 2007 14:21:11 -0000 Received: (from fabio@localhost) by granpasso.retis (8.14.1/8.14.1/Submit) id l87EL9LV045520; Fri, 7 Sep 2007 16:21:09 +0200 (CEST) (envelope-from fabio@freebsd.org) X-Authentication-Warning: granpasso.retis: fabio set sender to fabio@freebsd.org using -f Date: Fri, 7 Sep 2007 16:21:09 +0200 From: Fabio Checconi To: Luigi Rizzo Message-ID: <20070907142109.GL30045@gandalf.sssup.it> References: <20070906111028.A83649@xorpc.icir.org> <20070906222647.GB2737@kobe.laptop> <20070907000950.A91211@xorpc.icir.org> <20070907115021.GA2718@kobe.laptop> <20070907050310.A94579@xorpc.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070907050310.A94579@xorpc.icir.org> User-Agent: Mutt/1.4.2.3i Cc: Giorgos Keramidas , current@freebsd.org Subject: Re: how to tell 64 vs 32 bit architecture ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2007 15:21:24 -0000 On Fri, Sep 07, 2007 at 05:03:10AM -0700, Luigi Rizzo wrote: > i need to do this: > > #ifdef BUILT_FOR_64BIT_POINTERS > #define MY_MAGIC 0xdeadbeefd00de123 /* 64 bit */ > #else > #define MY_MAGIC 0xdeadbeef /* 32 bit */ > > If you know of a way to implement this without preprocessor > magic, i am all ears. If the values were simpler (eg all ones or so) > i could have used ~((unitptr_t)0) but this is not the case here #include #if UINTPTR_MAX < 0xdeadbeefd00de123 /* <= 0xffffffff */ #define MY_MAGIC 0xdeadbeef #else #define MY_MAGIC 0xdeadbeefd00de123 #endif does something like that look good to you ? fabio From owner-freebsd-current@FreeBSD.ORG Fri Sep 7 15:37:34 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 517CF16A41A for ; Fri, 7 Sep 2007 15:37:34 +0000 (UTC) (envelope-from oli@unixcraft.org) Received: from 42.mail-out.ovh.net (42.mail-out.ovh.net [213.251.189.42]) by mx1.freebsd.org (Postfix) with SMTP id B851113C4A7 for ; Fri, 7 Sep 2007 15:37:33 +0000 (UTC) (envelope-from oli@unixcraft.org) Received: (qmail 26280 invoked by uid 503); 7 Sep 2007 15:11:03 -0000 Received: from gw2.ovh.net (HELO mail186.ha.ovh.net) (213.251.189.202) by 42.mail-out.ovh.net with SMTP; 7 Sep 2007 15:11:03 -0000 Received: from b0.ovh.net (HELO queue-out) (213.186.33.50) by b0.ovh.net with SMTP; 7 Sep 2007 15:10:17 -0000 Received: from 150.21.202.62.fix.bluewin.ch (HELO localhost) (62.202.21.150) by ns0.ovh.net with SMTP; 7 Sep 2007 15:10:15 -0000 Date: Fri, 7 Sep 2007 17:11:32 +0200 From: Olivier Brisson To: alexandre.delay@free.fr Message-ID: <20070907151132.GB87574@haribo.unixcraft.org> References: <1189178064.46e16ad0a941a@imp.free.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <1189178064.46e16ad0a941a@imp.free.fr> User-Agent: Mutt/1.4.2.3i X-Ovh-Remote: 62.202.21.150 (150.21.202.62.fix.bluewin.ch) X-Ovh-Local: 213.186.33.20 (ns0.ovh.net) X-Spam-Check: DONE|H 0.5/N Cc: freebsd-current@freebsd.org Subject: Re: diffuse audio through modem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2007 15:37:34 -0000 * alexandre.delay@free.fr [070907 17:00]: > Hi! > > I'm searching the way to call, from my freebsd box connected to a serial modem, > a phone number and diffuse audio (wav, mp3 or wathever). > > Does anyone has a light to help me find the way? > > cheers > > Alex Hi Alex, You could use MPD (Multi-link PPP daemon for FreeBSD) [1] to get a connection to your freebsd box. Then stream your music with shoutcast or similar. [1] http://mpd.sourceforge.net/ Olivier From owner-freebsd-current@FreeBSD.ORG Fri Sep 7 15:38:06 2007 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9D9B516A41B for ; Fri, 7 Sep 2007 15:38:06 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) by mx1.freebsd.org (Postfix) with ESMTP id 320EC13C491 for ; Fri, 7 Sep 2007 15:38:04 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.1/8.14.1) with ESMTP id l87Fc3hC029835 for ; Fri, 7 Sep 2007 19:38:03 +0400 (MSD) (envelope-from marck@rinet.ru) Date: Fri, 7 Sep 2007 19:38:03 +0400 (MSD) From: Dmitry Morozovsky To: current@FreeBSD.org Message-ID: <20070907192152.V98273@woozle.rinet.ru> X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (woozle.rinet.ru [0.0.0.0]); Fri, 07 Sep 2007 19:38:03 +0400 (MSD) Cc: Subject: Possible 7.0 showstopper: SATA/eSATA are unable to init hot-plugs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2007 15:38:06 -0000 Dear colleagues, on most (possibly all, but I'm not fully sure and a bit limited in testing) motherboard/controller configuration I've tested so far -current is unable to properly attach hot-plugged disks. Sometimes even atacontrol detach/atacontrol attach sequence can't bring disk into working state (only reboot does). One example (today's current/amd64, verbose boot): [attach on the fly to eSATA port] Sep 7 16:56:08 hamster kernel: ata7: CONNECT requested Sep 7 16:56:08 hamster kernel: ata7: CONNECTED Sep 7 16:56:08 hamster kernel: ata7: SATA connect time=0ms Sep 7 16:56:08 hamster kernel: ata7: reset tp1 mask=00 ostat0=ff ostat1=00 Sep 7 16:56:24 hamster kernel: ata7: DISCONNECT requested Sep 7 16:56:24 hamster kernel: ata7: DISCONNECTED Sep 7 16:56:33 hamster kernel: ata7: CONNECT requested Sep 7 16:56:33 hamster kernel: ata7: CONNECTED Sep 7 16:56:33 hamster kernel: ata7: SATA connect time=0ms Sep 7 16:56:33 hamster kernel: ata7: reset tp1 mask=00 ostat0=ff ostat1=00 Sep 7 16:57:00 hamster kernel: ata7: SATA connect time=0ms Sep 7 16:57:00 hamster kernel: ata7: reset tp1 mask=01 ostat0=50 ostat1=00 Sep 7 16:57:00 hamster kernel: ata7: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 Sep 7 16:57:00 hamster kernel: ata7: reset tp2 stat0=50 stat1=00 devices=0x1 Sep 7 16:57:00 hamster kernel: ata7: [MPSAFE] Sep 7 16:57:00 hamster kernel: ata7: [ITHREAD] Sep 7 16:57:34 hamster kernel: ata7: reiniting channel .. Sep 7 16:57:34 hamster kernel: ata7: SATA connect time=0ms Sep 7 16:57:34 hamster kernel: ata7: reset tp1 mask=01 ostat0=58 ostat1=00 Sep 7 16:57:34 hamster kernel: ata7: stat0=0xd8 err=0x00 lsb=0x00 msb=0x00 Sep 7 16:57:34 hamster last message repeated 232 times Sep 7 16:57:34 hamster kernel: ata7: stat0=0xd8 err=0x00 lsb=0x00 msb=0x00 Sep 7 16:57:34 hamster last message repeated 76 times Sep 7 16:57:34 hamster kernel: ata7: reset tp2 stat0=d8 stat1=00 devices=0x0 Sep 7 16:57:34 hamster kernel: ata7: reinit done .. Sep 7 16:57:34 hamster kernel: unknown: timeout waiting to issue command Sep 7 16:57:34 hamster kernel: unknown: error issuing ATA_IDENTIFY command Sep 7 16:58:14 hamster kernel: ata7: SATA connect time=0ms Sep 7 16:58:14 hamster kernel: ata7: reset tp1 mask=01 ostat0=d8 ostat1=00 Sep 7 16:58:14 hamster kernel: ata7: stat0=0xd8 err=0x00 lsb=0x00 msb=0x00 Sep 7 16:58:14 hamster last message repeated 309 times Sep 7 16:58:14 hamster kernel: ata7: reset tp2 stat0=d8 stat1=00 devices=0x0 Sep 7 16:58:14 hamster kernel: ata7: [MPSAFE] Sep 7 16:58:14 hamster kernel: ata7: [ITHREAD] Sep 7 17:08:02 hamster kernel: ata7: DISCONNECT requested Sep 7 17:08:02 hamster kernel: ata7: DISCONNECTED Sep 7 17:08:28 hamster kernel: ata7: SATA connect time=0ms Sep 7 17:08:28 hamster kernel: ata7: reset tp1 mask=00 ostat0=ff ostat1=00 Sep 7 17:08:28 hamster kernel: ata7: [MPSAFE] Sep 7 17:08:28 hamster kernel: ata7: [ITHREAD] Sep 7 17:08:36 hamster kernel: ata7: reiniting channel .. Sep 7 17:08:36 hamster kernel: ata7: SATA connect time=0ms Sep 7 17:08:36 hamster kernel: ata7: reset tp1 mask=00 ostat0=ff ostat1=00 Sep 7 17:08:36 hamster kernel: ata7: reinit done .. Sep 7 17:08:42 hamster kernel: ata7: DISCONNECT requested Sep 7 17:08:42 hamster kernel: ata7: DISCONNECTED Sep 7 17:08:46 hamster kernel: ata7: CONNECT requested Sep 7 17:08:46 hamster kernel: ata7: CONNECTED Sep 7 17:08:46 hamster kernel: ata7: SATA connect time=0ms Sep 7 17:08:46 hamster kernel: ata7: reset tp1 mask=00 ostat0=ff ostat1=00 [reboot] Sep 7 17:13:27 hamster kernel: atapci3: port 0xa800-0xa87f,0xa400-0xa4ff mem 0xfdffe000-0xfdffefff,0xfdfc0000-0xfdfdffff irq 16 at device 7.0 on pci1 Sep 7 17:13:27 hamster kernel: pci1: child atapci3 requested type 4 for rid 0x20, but the BAR says it is an memio Sep 7 17:13:27 hamster kernel: ioapic0: routing intpin 16 (PCI IRQ 16) to vector 53 Sep 7 17:13:27 hamster kernel: atapci3: [MPSAFE] Sep 7 17:13:27 hamster kernel: atapci3: [ITHREAD] Sep 7 17:13:27 hamster kernel: atapci3: Reserved 0x20000 bytes for rid 0x20 type 3 at 0xfdfc0000 Sep 7 17:13:27 hamster kernel: atapci3: Reserved 0x1000 bytes for rid 0x1c type 3 at 0xfdffe000 Sep 7 17:13:27 hamster kernel: ioapic0: routing intpin 16 (PCI IRQ 16) to vector 53 Sep 7 17:13:27 hamster kernel: atapci3: [MPSAFE] Sep 7 17:13:27 hamster kernel: atapci3: [ITHREAD] Sep 7 17:13:27 hamster kernel: ata7: on atapci3 Sep 7 17:13:27 hamster kernel: ata7: SATA connect time=0ms Sep 7 17:13:27 hamster kernel: ata7: reset tp1 mask=01 ostat0=50 ostat1=00 Sep 7 17:13:27 hamster kernel: ata7: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 Sep 7 17:13:27 hamster kernel: ata7: reset tp2 stat0=50 stat1=00 devices=0x1 Sep 7 17:13:27 hamster kernel: ata7: [MPSAFE] Sep 7 17:13:27 hamster kernel: ata7: [ITHREAD] Sep 7 17:13:27 hamster kernel: ata7-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire Sep 7 17:13:27 hamster kernel: ad14: 381554MB at ata7-master SATA150 Sep 7 17:13:27 hamster kernel: ad14: 781422768 sectors [775221C/16H/63S] 16 sectors/interrupt 1 depth queue Sep 7 17:13:27 hamster kernel: GEOM: new disk ad14 Sep 7 17:16:35 hamster kernel: ad14: detached Sep 7 17:16:40 hamster kernel: ata7: SATA connect time=0ms Sep 7 17:16:40 hamster kernel: ata7: reset tp1 mask=01 ostat0=50 ostat1=00 Sep 7 17:16:40 hamster kernel: ata7: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 Sep 7 17:16:40 hamster kernel: ata7: reset tp2 stat0=50 stat1=00 devices=0x1 Sep 7 17:16:40 hamster kernel: ata7: [MPSAFE] Sep 7 17:16:40 hamster kernel: ata7: [ITHREAD] Sep 7 17:17:14 hamster kernel: ata7: reiniting channel .. Sep 7 17:17:14 hamster kernel: ata7: SATA connect time=0ms Sep 7 17:17:14 hamster kernel: ata7: reset tp1 mask=01 ostat0=58 ostat1=00 Sep 7 17:17:14 hamster kernel: ata7: stat0=0xd8 err=0x00 lsb=0x00 msb=0x00 Sep 7 17:17:14 hamster kernel: ata7: reset tp2 stat0=d8 stat1=00 devices=0x0 Sep 7 17:17:14 hamster kernel: ata7: reinit done .. Sep 7 17:22:27 hamster kernel: ata7: reiniting channel .. Sep 7 17:22:27 hamster kernel: ata7: SATA connect time=0ms Sep 7 17:22:27 hamster kernel: ata7: reset tp1 mask=01 ostat0=d8 ostat1=00 Sep 7 17:22:27 hamster kernel: ata7: stat0=0xd8 err=0x00 lsb=0x00 msb=0x00 Sep 7 17:22:27 hamster kernel: ata7: reset tp2 stat0=d8 stat1=00 devices=0x0 Sep 7 17:22:27 hamster kernel: ata7: reinit done .. RELENG_6 usually does attach successfully (can't check right now, but hopefully will do this weekend). Any hints? Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Fri Sep 7 16:01:24 2007 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 39E0016A418 for ; Fri, 7 Sep 2007 16:01:24 +0000 (UTC) (envelope-from dds@FreeBSD.org) Received: from mx-out-05.forthnet.gr (mx-out.forthnet.gr [193.92.150.103]) by mx1.freebsd.org (Postfix) with ESMTP id B466113C4A6 for ; Fri, 7 Sep 2007 16:01:23 +0000 (UTC) (envelope-from dds@FreeBSD.org) Received: from mx-av-01.forthnet.gr (mx-av.forthnet.gr [193.92.150.27]) by mx-out-05.forthnet.gr (8.13.8/8.13.8) with ESMTP id l87FiT5V015351; Fri, 7 Sep 2007 18:44:29 +0300 Received: from MX-IN-02.forthnet.gr (mx-in-02.forthnet.gr [193.92.150.185]) by mx-av-01.forthnet.gr (8.14.1/8.14.1) with ESMTP id l87FiT2t016601; Fri, 7 Sep 2007 18:44:29 +0300 Received: from [192.168.136.22] (ppp61-250.adsl.forthnet.gr [62.1.21.250]) by MX-IN-02.forthnet.gr (8.14.1/8.14.1) with ESMTP id l87FiMdZ002846; Fri, 7 Sep 2007 18:44:22 +0300 Authentication-Results: MX-IN-02.forthnet.gr smtp.mail=dds@FreeBSD.org; spf=permerror Authentication-Results: MX-IN-02.forthnet.gr header.from=dds@FreeBSD.org; sender-id=permerror Message-ID: <46E171BE.5060506@FreeBSD.org> Date: Fri, 07 Sep 2007 18:43:58 +0300 From: Diomidis Spinellis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.4) Gecko/20070509 SeaMonkey/1.1.2 MIME-Version: 1.0 To: alexandre.delay@free.fr References: <1189178064.46e16ad0a941a@imp.free.fr> In-Reply-To: <1189178064.46e16ad0a941a@imp.free.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: diffuse audio through modem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2007 16:01:24 -0000 alexandre.delay@free.fr wrote: > I'm searching the way to call, from my freebsd box connected to a serial modem, > a phone number and diffuse audio (wav, mp3 or wathever). > > Does anyone has a light to help me find the way? I have used vgetty (and in particular Perl scripts running under the provided vm program) to have my home machine call my cellhpone through its serial modem and play back pre-recorded messages. Look at /usr/ports/comms/mgetty+sendfax and in particular at voice/vm. In theory, you could also use a PBX program, like Asterisk, but I haven't any experience in interfacing Asterisk with a serial modem. Diomidis Spinellis - htp://www.spinellis.gr From owner-freebsd-current@FreeBSD.ORG Fri Sep 7 18:47:27 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CFDE816A41A for ; Fri, 7 Sep 2007 18:47:27 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay07.ispgateway.de (smtprelay07.ispgateway.de [80.67.29.7]) by mx1.freebsd.org (Postfix) with ESMTP id 0817413C465 for ; Fri, 7 Sep 2007 18:47:26 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: (qmail 27040 invoked from network); 7 Sep 2007 18:20:44 -0000 Received: from unknown (HELO localhost) (775067@[217.50.146.2]) (envelope-sender ) by smtprelay07.ispgateway.de (qmail-ldap-1.03) with SMTP for ; 7 Sep 2007 18:20:44 -0000 Date: Fri, 7 Sep 2007 20:20:36 +0200 From: Fabian Keil To: freebsd-current@freebsd.org Message-ID: <20070907202036.07bb4909@localhost> X-Mailer: Claws Mail 2.10.0 (GTK+ 2.10.14; i386-portbld-freebsd7.0) X-PGP-KEY-URL: http://www.fabiankeil.de/gpg-keys/freebsd-listen-2008-08-18.asc Mime-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_sp+PsoWI.KfC1BjLQCw=yJL"; protocol="application/pgp-signature"; micalg=PGP-SHA1 Subject: Panic in tcp_sackhole_remove X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2007 18:47:27 -0000 --Sig_sp+PsoWI.KfC1BjLQCw=yJL Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable With: FreeBSD tor.fabiankeil.de 7.0-CURRENT FreeBSD 7.0-CURRENT #2: Sun Aug 19 13:49:56 CEST 2007 fk@tor.fabiankeil.de:/usr/obj/usr/src/sys/DEADEND i386 I just got the following panic (no "panic string" as I logged into the console afterwards): db> where Tracing pid 12 tid 100002 td 0xc2d9cc00 kdb_enter(c0a93473,0,c0aa829c,d9e8ec24,0,...) at kdb_enter+0x32 panic(c0aa829c,c32f8974,0) at panic+0x124 tcp_sackhole_remove(c5506a68,1,c0aa8266,223,c58baca8,...) at tcp_sackhole_r= emove+0xc5 tcp_free_sackholes(c58baca8,1,c0aa8fed,11d,c5506a68,...) at tcp_free_sackho= les+0x47 tcp_timer(c55069d8,0,c0a9467b,f8,0,...) at tcp_timer+0xce softclock(0,0,c0a9008d,471,c2d97c64,...) at softclock+0x299 ithread_loop(c2d9a280,d9e8ed38,c0a8fe01,315,c2d9b558,...) at ithread_loop+0= x1b5 fork_exit(c0730c40,c2d9a280,d9e8ed38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip =3D 0, esp =3D 0xd9e8ed70, ebp =3D 0 --- db> ps pid ppid pgrp uid state wmesg wchan cmd 41132 1 41131 256 SJ (threaded) tor 100091 S sbwait 0xc66c9ea8 tor 100099 S kqread 0xc7be3200 tor 40872 1 40871 256 RJ (threaded) tor 100090 S sbwait 0xc79ba3d4 tor 100079 RunQ tor 1812 0 0 0 SL geli:w 0xc60c3400 [g_eli[0] zvol/tank/] 1811 0 0 0 SL crypto_r 0xcb567774 [crypto returns] 1810 0 0 0 SL crypto_w 0xcb56774c [crypto] 1131 0 0 0 SL vgeom:io 0xc3247bc8 [vdev:worker ad0s3] 1079 1 1079 0 Ss+ ttyin 0xc2f2e810 getty 1038 1 1038 0 Ss nanslp 0xc0ba7a04 cron 1032 1 1032 25 Ss pause 0xc3076060 sendmail 1026 1 1026 0 Ss select 0xc0bf461c sendmail 827 1 827 0 Ss select 0xc0bf461c sshd 729 1 729 0 Ss select 0xc0bf461c syslogd 672 1 672 0 Ss select 0xc0bf461c devd 469 0 0 0 SL pftm 0xc3c39ab0 [pfpurge] 130 0 0 0 SL zvol:io 0xc300b520 [zvol:worker zvol/ta] 129 0 0 0 SL zfs:(&tq 0xc31959e0 [zil_clean] 128 0 0 0 SL zfs:(&tx 0xc30a892c [txg_thread_enter] 127 0 0 0 SL zfs:(&tx 0xc30a890c [txg_thread_enter] 126 0 0 0 SL zfs:(&tx 0xc30a891c [txg_thread_enter] 124 0 0 0 SL zfs:(&tq 0xc3195914 [spa_zio_intr_5] 123 0 0 0 SL zfs:(&tq 0xc3195848 [spa_zio_issue_5] 122 0 0 0 SL zfs:(&tq 0xc319577c [spa_zio_intr_4] 121 0 0 0 SL zfs:(&tq 0xc31956b0 [spa_zio_issue_4] 120 0 0 0 SL zfs:(&tq 0xc31955e4 [spa_zio_intr_3] 119 0 0 0 SL zfs:(&tq 0xc3195050 [spa_zio_issue_3] 118 0 0 0 SL zfs:(&tq 0xc319511c [spa_zio_intr_2] 117 0 0 0 SL zfs:(&tq 0xc31951e8 [spa_zio_issue_2] 116 0 0 0 SL zfs:(&tq 0xc31952b4 [spa_zio_intr_1] 115 0 0 0 SL zfs:(&tq 0xc3195380 [spa_zio_issue_1] 114 0 0 0 SL zfs:(&tq 0xc319544c [spa_zio_intr_0] 113 0 0 0 SL zfs:(&tq 0xc3195518 [spa_zio_issue_0] 97 0 0 0 SL zfs:(&ar 0xc316916c [arc_reclaim_thread] 96 0 0 0 SL zfs:(&tq 0xc3196050 [system_taskq] 39 0 0 0 SL - 0xc0ba7834 [schedcpu] 38 0 0 0 SL sdflush 0xc0c00304 [softdepflush] 37 0 0 0 SL syncer 0xc0ba782c [syncer] 36 0 0 0 SL vlruwt 0xc3034ab0 [vnlru] 35 0 0 0 SL psleep 0xc0bf4ac4 [bufdaemon] 34 0 0 0 SL pgzero 0xc0c00db8 [pagezero] 33 0 0 0 SL psleep 0xc0c00ad4 [vmdaemon] 32 0 0 0 SL psleep 0xc0c00a9c [pagedaemon] 31 0 0 0 SL waiting_ 0xc0bf6828 [sctp_iterator] 30 0 0 0 WL [irq7: ppc0] 29 0 0 0 WL [irq1: atkbd0] 28 0 0 0 WL [swi0: sio] 27 0 0 0 SL - 0xc2d89a3c [fdc0] 26 0 0 0 SL cooling 0xc2f117d4 [acpi_cooling0] 25 0 0 0 SL tzpoll 0xc0d72d20 [acpi_thermal] 24 0 0 0 WL [irq15: ata1] 23 0 0 0 WL [irq14: ata0] 22 0 0 0 RL [irq12: fxp0 fxp1] 21 0 0 0 WL [irq9: acpi0] 20 0 0 0 WL [swi2: cambio] 19 0 0 0 SL ccb_scan 0xc0b76314 [xpt_thrd] 9 0 0 0 SL - 0xc2e86b80 [kqueue taskq] 18 0 0 0 WL [swi6: task queue] 8 0 0 0 SL - 0xc2e86d00 [acpi_task_2] 7 0 0 0 SL - 0xc2e86d00 [acpi_task_1] 6 0 0 0 SL - 0xc2e86d00 [acpi_task_0] 17 0 0 0 WL [swi6: Giant taskq] 5 0 0 0 SL - 0xc2d99300 [thread taskq] 16 0 0 0 WL [swi5: +] 15 0 0 0 SL - 0xc0ba7834 [yarrow] 4 0 0 0 SL - 0xc0ba58ac [g_down] 3 0 0 0 SL - 0xc0ba58a8 [g_up] 2 0 0 0 SL - 0xc0ba58a0 [g_event] 14 0 0 0 WL [swi1: net] 13 0 0 0 WL [swi3: vm] 12 0 0 0 RL CPU 0 [swi4: clock sio] 11 0 0 0 RL [idle: cpu0] 1 0 1 0 SLs wait 0xc2d9bab0 [init] 10 0 0 0 SL audit_wo 0xc0bffd74 [audit] 0 0 0 0 WLs [swapper] db> show allpcpu Current CPU: 0 cpuid =3D 0 curthread =3D 0xc2d9cc00: pid 12 "swi4: clock sio" curpcb =3D 0xd9e8ed90 fpcurthread =3D none idlethread =3D 0xc2d9ca00: pid 11 "idle: cpu0" APIC ID =3D 0 currentldt =3D 0x50 spin locks held: db> show alllocks Process 41132 (tor) thread 0xc357be00 (100091) exclusive sx so_rcv_sx r =3D 0 (0xc66c9e78) locked @ /usr/src/sys/kern/uipc= _sockbuf.c:145 Process 40872 (tor) thread 0xc6e30000 (100090) exclusive sx so_rcv_sx r =3D 0 (0xc79ba3a4) locked @ /usr/src/sys/kern/uipc= _sockbuf.c:145 Process 12 (swi4: clock sio) thread 0xc2d9cc00 (100002) exclusive sleep mutex inp (tcpinp) r =3D 0 (0xc5506a68) locked @ /usr/src/s= ys/kern/kern_timeout.c:248 db> show lockedvnods Locked vnodes db> trace 41132 Tracing pid 41132 tid 100091 td 0xc357be00 sched_switch(c357be00,0,1,180,26dad554,...) at sched_switch+0x1b6 mi_switch(1,0,c0a96ae6,1bd,0,...) at mi_switch+0x217 sleepq_switch(c357be00,0,c0a96ae6,199,c66c9ea8,...) at sleepq_switch+0xf0 sleepq_catch_signals(c074058d,c0ba93e0,1,c0a921df,58,...) at sleepq_catch_s= ignals+0x21e sleepq_wait_sig(c66c9ea8,0,c0a93dde,da,0,...) at sleepq_wait_sig+0x14 _sleep(c66c9ea8,c66c9e60,158,c0a9b8bc,0) at _sleep+0x359 sbwait(c66c9e3c,1,c0a9b9d1,5ae,c66c9e60,...) at sbwait+0x76 soreceive_generic(c66c9dec,dc594be8,dc594bf4,0,0,...) at soreceive_generic+= 0x42f soreceive(c66c9dec,dc594be8,dc594bf4,0,0,...) at soreceive+0x4d kern_recvit(c357be00,18,dc594c60,0,0,...) at kern_recvit+0x156 recvit(0,dc594c80,c07a9b88,bf9feec1,1,0,0,dc594c58,1,0,28406e78,0) at recvi= t+0x31 recvfrom(c357be00,dc594cfc,18,c0a98dee,c0b3f4b8,...) at recvfrom+0x76 syscall(dc594d38) at syscall+0x2b3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (29, FreeBSD ELF32, recvfrom), eip =3D 0x283ad807, esp =3D 0xbf= 9fec9c, ebp =3D 0xbf9fecc8 --- db> trace 40872 Tracing pid 40872 tid 100090 td 0xc6e30000 sched_switch(c6e30000,0,1,180,5cdde984,...) at sched_switch+0x1b6 mi_switch(1,0,c0a96ae6,1bd,0,...) at mi_switch+0x217 sleepq_switch(c6e30000,0,c0a96ae6,199,c79ba3d4,...) at sleepq_switch+0xf0 sleepq_catch_signals(c074058d,c0ba93e0,1,c0a921df,58,...) at sleepq_catch_s= ignals+0x21e sleepq_wait_sig(c79ba3d4,0,c0a93dde,da,0,...) at sleepq_wait_sig+0x14 _sleep(c79ba3d4,c79ba38c,158,c0a9b8bc,0) at _sleep+0x359 sbwait(c79ba368,1,c0a9b9d1,5ae,c79ba38c,...) at sbwait+0x76 soreceive_generic(c79ba318,dc4c4be8,dc4c4bf4,0,0,...) at soreceive_generic+= 0x42f soreceive(c79ba318,dc4c4be8,dc4c4bf4,0,0,...) at soreceive+0x4d kern_recvit(c6e30000,18,dc4c4c60,0,0,...) at kern_recvit+0x156 recvit(0,dc4c4c80,c07a9b88,bf9feec1,1,0,0,dc4c4c58,1,0,28406e78,0) at recvi= t+0x31 recvfrom(c6e30000,dc4c4cfc,18,c0a98dee,c0b3f4b8,...) at recvfrom+0x76 syscall(dc4c4d38) at syscall+0x2b3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (29, FreeBSD ELF32, recvfrom), eip =3D 0x283ad807, esp =3D 0xbf= 9fec9c, ebp =3D 0xbf9fecc8 --- db> panic panic: from debugger cpuid =3D 0 Uptime: 10d16h52m51s Cannot dump. No dump device defined. Automatic reboot in 15 seconds - press a key on the console to abort I'm aware that a core dump would probably be nice, but as the system is using ZFS for everything except the root partition I can't configure a dump device. I hope this report isn't entirely useless anyway. Are there any additional db commands I should try in case the system runs into this one again? Fabian --Sig_sp+PsoWI.KfC1BjLQCw=yJL Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFG4ZZ1BYqIVf93VJ0RAtAjAKDMU62hu8NMr4BS1RJP/Q71NxgD6ACfdXE/ cd0g4yCB538pk12ZK5SxWcA= =Mn2+ -----END PGP SIGNATURE----- --Sig_sp+PsoWI.KfC1BjLQCw=yJL-- From owner-freebsd-current@FreeBSD.ORG Fri Sep 7 21:25:55 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3F6DA16A417 for ; Fri, 7 Sep 2007 21:25:55 +0000 (UTC) (envelope-from andrew_terekhov@yahoo.com) Received: from web54407.mail.yahoo.com (web54407.mail.yahoo.com [206.190.49.137]) by mx1.freebsd.org (Postfix) with SMTP id DF9EA13C45B for ; Fri, 7 Sep 2007 21:25:54 +0000 (UTC) (envelope-from andrew_terekhov@yahoo.com) Received: (qmail 47147 invoked by uid 60001); 7 Sep 2007 20:59:14 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=mD24/VtOeFSS5T8Scb9YXLWC3Tg8G+Iic3aFgUgWjjhoy61yihSepIuT4+gdtROno7LmhE4MkPoLpWXGfLfpiykBHvb9YbPeBfC9EA4HYg0uK5n8SVwq36S6YIZW3Ijj8k+bmpxehscj0vAdP8/cBMeQjaYyF/txeQ7gU5ZpTZ4=; X-YMail-OSG: HjHTl2YVM1ndx0uy2xN9g5L0zPypHbhbhyOzd4kje0VR6APzx2WGNi7bWF0AEaJPRg-- Received: from [69.147.98.50] by web54407.mail.yahoo.com via HTTP; Fri, 07 Sep 2007 13:59:14 PDT X-Mailer: YahooMailRC/651.50 YahooMailWebService/0.7.134 Date: Fri, 7 Sep 2007 13:59:14 -0700 (PDT) From: andrew_terekhov@yahoo.com To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-ID: <526915.46102.qm@web54407.mail.yahoo.com> Subject: SATA DMA errors X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2007 21:25:55 -0000 Current kernel/world (i386) from a few days ago on 2 different computers ex= hibits DMA read/write =0Aerrors when accessing SATA drives. IDE drives work= fine.=0A=0AErrors are similar to described here:=0A=0Ahttp://lists.freebsd= .org/pipermail/freebsd-current/2007-September/076776.html=0Ahttp://lists.fr= eebsd.org/pipermail/freebsd-current/2007-September/076699.html=0Ahttp://lis= ts.freebsd.org/pipermail/freebsd-questions/2007-August/156029.html=0A=0AAft= er a few DMA errors both systems usually hard lockup.=0A=0AI took advice fo= und here:=0A=0Ahttp://lists.freebsd.org/pipermail/freebsd-current/2007-Augu= st/076219.html=0A=0Aand rebuilt both systems with =0A=0A*date=3D2007.06.16.= 03.00.00=0A=0AThe problem was gone - running for the second day with heavy = use of SATA drives with no errors. =0ABefore it took a few minutes to bring= down computers.=0A=0A=0AHardware:=0A=0ASystem 1:=0A=0Aatapci1: port 0xe300-0xe307,0xe400-0xe403,0xe500-0xe507,0xe600-0xe= 603,0xe700-0xe70f irq 11 at device 5.0 on pci0=0Aad4: 305245MB at ata2-master SATA150=0A=0A=0ASystem 2:=0A=0Aatapci2: port 0xcc00-0xcc7f,0xc800-0xc8ff mem 0xfe= aff000-0xfeafffff,0xfeac0000-0xfeadffff irq 16 at device 3.0 on pci5=0Aad8:= 194481MB at ata4-master SATA150=0Aad10: 286168MB= at ata5-master SATA300=0A=0A=0AIt seems someth= ing was changed after 2007-06-16 that broke SATA in current.=0A=0A=0A=0A=0A= =0A =0A______________________________________________________________= ______________________=0AYahoo! oneSearch: Finally, mobile search =0Athat g= ives answers, not web links. =0Ahttp://mobile.yahoo.com/mobileweb/onesearch= ?refer=3D1ONXIC From owner-freebsd-current@FreeBSD.ORG Sat Sep 8 02:41:34 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5BBFB16A420 for ; Sat, 8 Sep 2007 02:41:34 +0000 (UTC) (envelope-from nate@root.org) Received: from root.org (root.org [67.118.192.226]) by mx1.freebsd.org (Postfix) with ESMTP id 3BCAC13C45E for ; Sat, 8 Sep 2007 02:41:34 +0000 (UTC) (envelope-from nate@root.org) Received: (qmail 96174 invoked from network); 8 Sep 2007 02:41:35 -0000 Received: from ppp-71-139-1-224.dsl.snfc21.pacbell.net (HELO ?10.0.0.15?) (nate-mail@71.139.1.224) by root.org with ESMTPA; 8 Sep 2007 02:41:35 -0000 Message-ID: <46E20A1D.7050608@root.org> Date: Fri, 07 Sep 2007 19:34:05 -0700 From: Nate Lawson User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: William Grzybowski References: <46E0777A.8070901@root.org> <46E07AAF.2060000@root.org> <632825b40709070752o6fe867a2s3e7647e5444b1b5b@mail.gmail.com> In-Reply-To: <632825b40709070752o6fe867a2s3e7647e5444b1b5b@mail.gmail.com> X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: acpi@freebsd.org, current@freebsd.org Subject: Re: PATCH: ecng for 6.x and 7.x X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Sep 2007 02:41:34 -0000 William Grzybowski wrote: > On 9/6/07, *Nate Lawson* > wrote: > > Nate Lawson wrote: > > I've done some major rework on the EC driver. This should help with > > various problems, including timeouts while checking battery status or > > temperature. The attached patches are for 6.x and 7.x. Please > test and > > let me know if you get any new errors on dmesg or if it fixes > things for > > you (especially HP/Compaq laptop owners). > > > > If you still have problems, try setting each of these tunables > > individually and then both together (i.e., in > /boot/loader.conf). Note > > that this will be four (4) test runs total, so don't just set both and > > say it doesn't work. > > > > debug.acpi.ec.burst= "1" > > debug.acpi.ec.polled="1" > > > > I've tested both patches on a Panasonic Y4 and UnnamedOEM laptop, no > > problems in either regular or burst mode. > > I tested this patch on my acer notebook (intel chipset) and i did not > notice any changes, unless some errors on dmesg, like: > acpi_ec0: EcCommand: no response to 0x84 > acpi_ec0: GPE query failed: AE_NO_HARDWARE_RESPONSE > acpi_ec0: EcCommand: no response to 0x82 > acpi_ec0: EcCommand: no response to 0x80 > ACPI Error (psparse-0626): Method parse/execution failed > [\\_TZ_.THRM._TMP] (Node 0xc3bbdcc0), AE_NO_HARDWARE_RESPONSE > ACPI Error (psparse-0626): Method parse/execution failed > [\\_SB_.ACAD._PSR] (Node 0xc3bc02a0), AE_NO_HARDWARE_RESPONSE Are those errors new or have they always been there? I noticed with the "polled" tunable set, it appears to go away. Is this right or are there errors later in the dmesg? > I tried the 4 test runs which you mentioned , when I boot with both > debug.acpi (burst and polled = 1) I got a kernel panic but i couldn't > save the backtrace, but it was about _sx_xlock_hard in recursed on > non-recursive function, line 209 on acpi_ec.c If you could try this again and get the full panic message, that would help a lot. I need both places the sx was locked, not just one. It usually will report something like "attempt to acquire sx at XXX, previously acquired at YYY". I need both values to figure out what lock order is happening on your system. > I'm send links for 3 verbose boot's (i couldnt for burst and polled > because the panic) if you want to take a look.. > http://www.inf.ufpr.br/wg06/dmesg-acpi-ec.gz > > http://www.inf.ufpr.br/wg06/dmesg-acpi-ec-burst.gz > http://www.inf.ufpr.br/wg06/dmesg-acpi-ec-polled.gz > One thing I noted in your dmesg for the polled case was the "acpi_ec0: warning: EC done before starting event wait" message. That tells me your system probably needs some extra checking to figure out when the status is actually ready, but that's a complicated case I'm not sure how to solve yet. But did any other errors show up in that case? Did thermal/battery status get reported correctly? One thing you could do to help me is to build the kernel and acpi module with: options KTR options KTR_COMPILE=KTR_DEV options KTR_ENTRIES=65536 Then, boot to multi-user for each of the 4 cases I mentioned above (don't bother for the panic case) and run: ktrdump -rt | sort -n | gzip -9c > foo.ktr I'll then be able to see more detail about how the EC is behaving on your system. Thanks, -- Nate From owner-freebsd-current@FreeBSD.ORG Sat Sep 8 05:45:14 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2588016A420 for ; Sat, 8 Sep 2007 05:45:14 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id C54FF13C45E for ; Sat, 8 Sep 2007 05:45:12 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (ppp121-45-93-75.lns10.adl6.internode.on.net [121.45.93.75]) (authenticated bits=0) by cain.gsoft.com.au (8.13.8/8.13.8) with ESMTP id l885j3qs005081 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 8 Sep 2007 15:15:03 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-current@freebsd.org Date: Sat, 8 Sep 2007 15:14:49 +0930 User-Agent: KMail/1.9.7 References: <1189178064.46e16ad0a941a@imp.free.fr> In-Reply-To: <1189178064.46e16ad0a941a@imp.free.fr> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1318544.ZuPOVDRn3k"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200709081514.57284.doconnor@gsoft.com.au> X-Spam-Score: -2.312 () BAYES_00 X-Scanned-By: MIMEDefang 2.58 on 203.31.81.10 Cc: alexandre.delay@free.fr Subject: Re: diffuse audio through modem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Sep 2007 05:45:14 -0000 --nextPart1318544.ZuPOVDRn3k Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Sat, 8 Sep 2007, alexandre.delay@free.fr wrote: > I'm searching the way to call, from my freebsd box connected to a > serial modem, a phone number and diffuse audio (wav, mp3 or > wathever). > > Does anyone has a light to help me find the way? vgetty should be able to do this, look in comms/mgetty+sendfax in the=20 ports tree. I use it to record voice mail and email it to me as an MP3 http://www.gsoft.com.au/~doconnor/mp3-voicemail/ =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 --nextPart1318544.ZuPOVDRn3k Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQBG4jbZ5ZPcIHs/zowRAhDZAKChiazYCGgIy21rB3uBcqPWiqGdCgCfQjgg QY2KT+sx80oaOdOkSxSJ3AA= =wZ35 -----END PGP SIGNATURE----- --nextPart1318544.ZuPOVDRn3k-- From owner-freebsd-current@FreeBSD.ORG Sat Sep 8 09:43:37 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AD3C916A421 for ; Sat, 8 Sep 2007 09:43:37 +0000 (UTC) (envelope-from qpadla@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.187]) by mx1.freebsd.org (Postfix) with ESMTP id 386CF13C457 for ; Sat, 8 Sep 2007 09:43:36 +0000 (UTC) (envelope-from qpadla@gmail.com) Received: by nf-out-0910.google.com with SMTP id k4so532357nfd for ; Sat, 08 Sep 2007 02:43:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:from:reply-to:to:subject:date:user-agent:mime-version:content-type:content-transfer-encoding:message-id; bh=hS0I9p4MEpL3wbjmDBRIS+4MSKEkdNNgihcSS06DKRM=; b=WJvsPsdxa+oeJ0mEVDQpZSfS5JDSddtLb+XzRX8B7WfVJpwJH0/X+Jo5qBcdaBtf919AotIitsheBu+vGmgPmXj7d5ZG89myAOLEaPnog/aYixYg8CIFVHhtfGO0aRZ/IcKTnhGz+kp2nglce9PoxFvroK2l0YTXaMQuwOmdmOM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:from:reply-to:to:subject:date:user-agent:mime-version:content-type:content-transfer-encoding:message-id; b=DF5qcyhPpz+bGaGGXMb2n08FKzwTAyw9ghRgB/ZKtBJMMDCM6pB5iVtG4k+SIWbJ4ee4kY7zmVWXojzYLl8qyvISlfSWXw6/5N3q4JSIOwC0QgYwI0mvOn3fQMZ4UfXLaEpR6JcFXkj9jOAfR2RoA7R9tGCDhH2USbOe2PwgU14= Received: by 10.78.168.1 with SMTP id q1mr1043649hue.1189244615224; Sat, 08 Sep 2007 02:43:35 -0700 (PDT) Received: from orion ( [77.109.37.125]) by mx.google.com with ESMTPS id 32sm1184525hui.2007.09.08.02.43.29 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 08 Sep 2007 02:43:34 -0700 (PDT) From: Nikolay Pavlov To: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Date: Sat, 8 Sep 2007 12:43:44 +0300 User-Agent: KMail/1.9.7 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3566643.daDD0r832G"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200709081243.48890.qpadla@gmail.com> Cc: Subject: On-disk indexing for "Project Ideas" page X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: qpadla@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Sep 2007 09:43:37 -0000 --nextPart3566643.daDD0r832G Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Recently while reading "Design and Implementation of FreeBSD operation=20 system" by Marshall Kirk McKusick and gnn i have found a very intresting=20 paragraph regarding UFS2 implementation, indexing and B-trees. According=20 to it on-disk indexes was not implemented, but some structures was=20 reserved for future development. May be some SOC students could implement=20 this in future. How about to adding this into Project Ideas page?=20 Let me quote from the paragraph "8.3 Naming": =46inding of Names in Directories A common request to the filesystem is to lookup a specific name in a=20 directory. The kernel usually does the lookup by starting at the beginning= =20 of the directory and going through, comparing each entry in turn. First,=20 the length of the sought-after name is compared with the length of the=20 name being checked. If the lengths are identical, a string comparison of=20 the name being sought and the directory entry is made. If they match, the=20 search is complete; if they fail, either in the length or in the string=20 comparison, the search continues with the next entry. Whenever a name is=20 found, its name and containing directory are entered into the systemwide=20 name cache described in Section 6.6. Whenever a search is unsuccessful, an= =20 entry is made in the cache showing that the name does not exist in the=20 particular directory. Before starting a directory scan, the kernel looks=20 for the name in the cache. If either a positive or negative entry is=20 found, the directory scan can be avoided. Another common operation is to lookup all the entries in a directory. For=20 example, many programs do a stat system call on each name in a directory=20 in the order that the names appear in the directory. To improve=20 performance for these programs, the kernel maintains the directory offset=20 of the last successful lookup for each directory. Each time that a lookup=20 is done in that directory, the search is started from the offset at which=20 the previous name was found (instead of from the beginning of the=20 directory). For programs that step sequentially through a directory with n= =20 files, search time decreases from Order(n2) to Order(n). One quick benchmark that demonstrates the maximum effectiveness of the=20 cache is running the ls -l command on a directory containing 600 files. On= =20 a system that retains the most recent directory offset, the amount of=20 system time for this test is reduced by 85 percent. Unfortunately, the=20 maximum effectiveness is much greater than the average effectiveness.=20 Although the cache is 90 percent effective when hit, it is applicable to=20 only about 25 percent of the names being looked up. Despite the amount of=20 time spent in the lookup routine itself decreasing substantially, the=20 improvement is diminished because more time is spent in the routines that=20 that routine calls. Each cache miss causes a directory to be accessed=20 twice=E2=80=94once to search from the middle to the end and once to search = from=20 the beginning to the middle. These caches provide good directory lookup performance but are ineffective= =20 for large directories that have a high rate of entry creation and=20 deletion. Each time a new directory entry is created, the kernel must scan= =20 the entire directory to ensure that the entry does not already exist. When= =20 an existing entry is deleted, the kernel must scan the directory to find=20 the entry to be removed. For directories with many entries these linear=20 scans are time-consuming. The approach to solving this problem in FreeBSD 5.2 is to introduce dynamic= =20 directory hashing that retrofits a directory indexing system to UFS [Dowse= =20 & Malone, 2002]. To avoid repeated linear searches of large directories,=20 the dynamic directory hashing builds a hash table of directory entries on=20 the fly when the directory is first accessed. This table avoids directory=20 scans on later lookups, creates, and deletes. Unlike filesystems=20 originally designed with large directories in mind, these indices are not=20 saved on disk and so the system is backward compatible. The drawback is=20 that the indices need to be built the first time that a large directory is= =20 encountered after each system reboot. The effect of the dynamic directory=20 hashing is that large directories in UFS cause minimal performance=20 problems. When we built UFS2, we contemplated solving the large directory update=20 problem by changing to a more complex directory structure such as one that= =20 uses B-trees. This technique is used in many modern filesystems such as=20 XFS [Sweeney et al., 1996], JFS [Best & Kleikamp, 2003], ReiserFS [Reiser,= =20 2001], and in later versions of Ext2 [Phillips, 2001]. We decided not to=20 make the change at the time that UFS2 was first implemented for several=20 reasons. First, we had limited time and resources, and we wanted to get=20 something working and stable that could be used in the time frame of=20 =46reeBSD 5.2. By keeping the same directory format, we were able to reuse= =20 all the directory code from UFS1, did not have to change numerous=20 filesystem utilities to understand and maintain a new directory format,=20 and were able to produce a stable and reliable filesystem in the time=20 frame available to us. The other reason that we felt that we could retain=20 the existing directory structure is because of the dynamic directory=20 hashing that was added to FreeBSD. Borrowing the technique used by the Ext2 filesystem a flag was also added=20 to show that an on-disk indexing structure is supported for directories=20 [Phillips, 2001]. This flag is unconditionally turned off by the existing=20 implementation of UFS. In the future, if an implementation of an on-disk=20 directory-indexing structure is added, the implementations that support it= =20 will not turn the flag off. Index-supporting kernels will maintain the=20 indices and leave the flag on. If an old non-index-supporting kernel is=20 run, it will turn off the flag so that when the filesystem is once again=20 run under a new kernel, the new kernel will discover that the indexing=20 flag has been turned off and will know that the indices may be out date=20 and have to be rebuilt before being used. The only constraint on an=20 implementation of the indices is that they have to be an auxiliary data=20 structure that references the old linear directory format. =2D-=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 =2D Best regards, Nikolay Pavlov. <<<----------------------------------- = =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 --nextPart3566643.daDD0r832G Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBG4m7U/2R6KvEYGaIRAkA9AJ9v24dpn2ptSVReq1qxZmLeHy3MmACfcnYm XukTYaTHTXrzVmbG0BAGZxs= =Q+9o -----END PGP SIGNATURE----- --nextPart3566643.daDD0r832G-- From owner-freebsd-current@FreeBSD.ORG Sat Sep 8 10:26:05 2007 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4D63516A41B for ; Sat, 8 Sep 2007 10:26:05 +0000 (UTC) (envelope-from bsd-current@epcdirect.co.uk) Received: from gunfright.epcdirect.co.uk (gunfright.epcdirect.co.uk [195.10.242.32]) by mx1.freebsd.org (Postfix) with ESMTP id DF68413C45D for ; Sat, 8 Sep 2007 10:26:04 +0000 (UTC) (envelope-from bsd-current@epcdirect.co.uk) Received: from localhost (localhost.epcdirect.co.uk [127.0.0.1]) by gunfright.epcdirect.co.uk (Postfix) with ESMTP id E4BF76176; Sat, 8 Sep 2007 11:26:03 +0100 (BST) X-Virus-Scanned: by GunFright.EPCDirect.co.uk Received: from gunfright.epcdirect.co.uk ([127.0.0.1]) by localhost (gunfright.epcdirect.co.uk [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id X+iAUJNBEjTC; Sat, 8 Sep 2007 11:26:03 +0100 (BST) Received: from lfarr (lfarr.adsl.gemsoft.co.uk [195.10.239.114]) by gunfright.epcdirect.co.uk (Postfix) with ESMTP id 560346128; Sat, 8 Sep 2007 11:26:03 +0100 (BST) From: "Lawrence Farr" To: "'Danny Braniss'" , "'cpghost'" References: <20070904233246.GA2409@epia-2.farid-hajji.net> In-Reply-To: Date: Sat, 8 Sep 2007 11:26:01 +0100 Message-ID: <043a01c7f202$a7ad0920$f7071b60$@co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcfvgFXwJTQl7kvVQ0CjruOoG1yfPgCgbqFw Content-Language: en-gb Cc: freebsd-current@FreeBSD.org, 'Gavin Atkinson' Subject: RE: dump problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Sep 2007 10:26:05 -0000 > -----Original Message----- > From: owner-freebsd-current@freebsd.org [mailto:owner-freebsd- > current@freebsd.org] On Behalf Of Danny Braniss > Sent: 05 September 2007 06:47 > To: cpghost > Cc: freebsd-current@FreeBSD.org; Gavin Atkinson > Subject: Re: dump problems > > > On Tue, Sep 04, 2007 at 09:47:16PM +0300, Danny Braniss wrote: > > > > On Tue, 2007-09-04 at 18:51 +0300, Danny Braniss wrote: > > > > > dump start out nicely, but then it justs hangs. > > > > > have tried it with different file systems, the output > > > > > is also a file, again tried it with different file system. > > > > > the only way it works is if the output file is /dev/null (very > > > > > fast, but not realy helpful :-) > > > > > > > > When it hangs, what is printed when you send it a CTRL-T? > > > > > > > off the top of my head: > > > > > > ... running ... > > > > > > it seems to be a problem on the writing side, since setting the > output > > > to /dev/null actually works. > > > > > > the commands used were: > > > > > > dump 0Lf - /some/file/system | restore rf - > > > this got stuck, so I started experimenting: > > > dump 0Lf file.dump /some/file/system > > > > > > gets stuck, ^T will mostly return ... [running] ... since at least > > > one of the dump process is running, but my guess it's just > monitoring. > > > I also tried without the L flag, but did not change the result. > > > the only dump that finishes, is when the output is /dev/null. > > > > Try again with the 'a' flag. dump(8) still assumes that it writes > > to a set of tapes, and if the writing stalls for some reason > (restore(8) > > being slow or somesuch), dump may ask to switch tapes. Since all this > > is of course bogus now, use 'a' to disable all those tape size > > calculation heuristics, as in > > > > # dump 0Luaf - /some/file/system | restore rf - > true, but > 1- if output is stdout it does not do any tape size calculations > 2- it does not differentiate between 'regular file' and 'special > file' > and thus will stop requesting for another tape. > so, yes, i forgot to say that i did use the -a flag, but i did say it's > stuck, > not that it's waiting for any tape change. > > so, sorry, no cookies yet :-) > > danny > I'm running my dumps from a periodic script, and it's been sat like this since last night: 0 30447 30374 0 8 0 28240 25964 wait S ?? 0:00.20 dump -1auf /mnt/dump/epcduk1/da0s1f.1.dmp /dev/da0s1f (dump) 0 30448 30447 0 4 0 28240 25988 sbwait S ?? 0:00.87 dump: /dev/da0s1f: pass 4: 0.08% done, finished in 13:35 at Sat Sep 8 14:37:36 2007 (dump) 0 30449 30448 0 20 0 28240 25964 pause S ?? 0:00.99 dump -1auf /mnt/dump/epcduk1/da0s1f.1.dmp /dev/da0s1f (dump) 0 30450 30448 0 20 0 28240 25964 pause S ?? 0:01.00 dump -1auf /mnt/dump/epcduk1/da0s1f.1.dmp /dev/da0s1f (dump) 0 30451 30448 0 20 0 28240 25964 pause S ?? 0:01.00 dump -1auf /mnt/dump/epcduk1/da0s1f.1.dmp /dev/da0s1f (dump) Is there any way of working out what's happening to these? From owner-freebsd-current@FreeBSD.ORG Sat Sep 8 10:28:56 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 56C8716A41A for ; Sat, 8 Sep 2007 10:28:56 +0000 (UTC) (envelope-from bsd-current@epcdirect.co.uk) Received: from gunfright.epcdirect.co.uk (gunfright.epcdirect.co.uk [195.10.242.32]) by mx1.freebsd.org (Postfix) with ESMTP id ED56F13C46E for ; Sat, 8 Sep 2007 10:28:55 +0000 (UTC) (envelope-from bsd-current@epcdirect.co.uk) Received: from localhost (localhost.epcdirect.co.uk [127.0.0.1]) by gunfright.epcdirect.co.uk (Postfix) with ESMTP id 4F205619C; Sat, 8 Sep 2007 11:28:55 +0100 (BST) X-Virus-Scanned: by GunFright.EPCDirect.co.uk Received: from gunfright.epcdirect.co.uk ([127.0.0.1]) by localhost (gunfright.epcdirect.co.uk [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id eB0aNrgzY3mb; Sat, 8 Sep 2007 11:28:55 +0100 (BST) Received: from lfarr (lfarr.adsl.gemsoft.co.uk [195.10.239.114]) by gunfright.epcdirect.co.uk (Postfix) with ESMTP id B3C896189; Sat, 8 Sep 2007 11:28:54 +0100 (BST) From: "Lawrence Farr" To: "'Remy Nonnenmacher'" References: <46C9B99C.1060403@moneybookers.com> <012501c7e348$288c6af0$79a540d0$@co.uk> <46CAB40B.6030605@activnetworks.com> In-Reply-To: <46CAB40B.6030605@activnetworks.com> Date: Sat, 8 Sep 2007 11:28:52 +0100 Message-ID: <043b01c7f203$0dc95330$295bf990$@co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acfj2zIGs1njJhGfQ/yyTrKNZSLuHAOJ4IyQ Content-Language: en-gb Cc: freebsd-current@freebsd.org Subject: RE: Solid hang with bge interface X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Sep 2007 10:28:56 -0000 > -----Original Message----- > From: Remy Nonnenmacher [mailto:remy.nonnenmacher@activnetworks.com] > Sent: 21 August 2007 10:45 > To: Lawrence Farr > Cc: freebsd-current@freebsd.org > Subject: Re: Solid hang with bge interface > > Lawrence Farr wrote: > > I have a Supermicro H8DAR-T based server, that was happily > > running 6-stable from last year sometime. I swapped it out and > > have been trying to get -CURRENT installed on it but it hangs > > solid as soon as you configure the bge0 interface. The bge1 > > interface will work occasionally tho. To try and rule out a > > hardware fault I booted an AMD64-6.0RC1 cd that I had, which > > had no problems at all with the interface: > > > > http://www.epcdirect.com/bootlog/6boot.txt > > > > But the current snapshot from June, and from todays source > > hangs solid as soon as you try to set up the bge0 interface. > > > > http://www.epcdirect.com/bootlog/currentboot.txt > > > > As you can see, it hangs solid at "Setting hostname". > > > > I've also removed the 3ware card "just in case" but it made > > no difference. Latest BIOS too. I found some references to > > a similar problem with bge recently too: > > > > http://lists.freebsd.org/pipermail/freebsd-current/2007- > August/075998.html > > > > > > Anyone else seeing this? > > > > Same here with a Supermicro H8SSL-I2 (Serverworks HT1000 based). > > bge0 locks the system hard when going up, bge1 OK (but goes down a few > hours after start). Also, an ifconfig indicates: > > bge0: flags=8802 metric 0 mtu 1500 > options=9b > ether 00:30:48:5e:6e:56 > media: Ethernet autoselect (none ) > ^^^^^^^^^^^^^^^^^^ > status: no carrier > bge1: flags=8843 metric 0 mtu > 1500 > options=9b > ether 00:30:48:5e:6e:57 > inet 192.168.1.49 netmask 0xffffff00 broadcast 192.168.1.255 > media: Ethernet autoselect (1000baseTX ) > status: active > > An the dmesg shows: (see "^^^^..") > > . > . > bge0: 0x2100> mem 0xff4f0000-0xff4fffff irq 24 at device 3.0 on pci2 > miibus0: on bge0 > brgphy0: PHY 1 on miibus0 > brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, > 1000baseT-FDX, auto > bge0: Ethernet address: 00:30:48:5e:6e:56 > bge0: [ITHREAD] > pci2:3:1: bad VPD cksum, remain 14 > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > bge1: 0x2100> > mem 0xff4e0000-0xff4effff irq 25 at device 3.1 on pci2 > miibus1: on bge1 > brgphy1: PHY 1 on miibus1 > brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, > 1000baseT-FDX, auto > bge1: Ethernet address: 00:30:48:5e:6e:57 > bge1: [ITHREAD] > . > . > > (I also have strange problems with the SATA controller and recent > kernels (that works fine on other machines) that seems to read random > sectors (at least not those requested) causing core-dumps, compiler > internal errors, trashed sources and false positives about corrupted > filesystems.I don't know what is going on on this platform but it > smells^Gdoesn't looks very sane.) > > RN. > IeM > > This is still hanging with yesterdays current in i386 and AMD64, is it worth opening a PR? From owner-freebsd-current@FreeBSD.ORG Sat Sep 8 14:09:55 2007 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7F84016A418; Sat, 8 Sep 2007 14:09:55 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from cs1.cs.huji.ac.il (cs1.cs.huji.ac.il [132.65.16.10]) by mx1.freebsd.org (Postfix) with ESMTP id 33F7B13C459; Sat, 8 Sep 2007 14:09:54 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by cs1.cs.huji.ac.il with esmtp id 1IU10R-000MRT-T8; Sat, 08 Sep 2007 17:09:51 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: "Lawrence Farr" In-reply-to: <043a01c7f202$a7ad0920$f7071b60$@co.uk> References: <20070904233246.GA2409@epia-2.farid-hajji.net> <043a01c7f202$a7ad0920$f7071b60$@co.uk> Comments: In-reply-to "Lawrence Farr" message dated "Sat, 08 Sep 2007 11:26:01 +0100." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 08 Sep 2007 17:09:51 +0300 From: Danny Braniss Message-ID: Cc: freebsd-current@FreeBSD.org, 'cpghost' , 'Gavin Atkinson' Subject: Re: dump problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Sep 2007 14:09:55 -0000 > > -----Original Message----- > > From: owner-freebsd-current@freebsd.org [mailto:owner-freebsd- > > current@freebsd.org] On Behalf Of Danny Braniss > > Sent: 05 September 2007 06:47 > > To: cpghost > > Cc: freebsd-current@FreeBSD.org; Gavin Atkinson > > Subject: Re: dump problems > > > > > On Tue, Sep 04, 2007 at 09:47:16PM +0300, Danny Braniss wrote: > > > > > On Tue, 2007-09-04 at 18:51 +0300, Danny Braniss wrote: > > > > > > dump start out nicely, but then it justs hangs. > > > > > > have tried it with different file systems, the output > > > > > > is also a file, again tried it with different file system. > > > > > > the only way it works is if the output file is /dev/null (very > > > > > > fast, but not realy helpful :-) > > > > > > > > > > When it hangs, what is printed when you send it a CTRL-T? > > > > > > > > > off the top of my head: > > > > > > > > ... running ... > > > > > > > > it seems to be a problem on the writing side, since setting the > > output > > > > to /dev/null actually works. > > > > > > > > the commands used were: > > > > > > > > dump 0Lf - /some/file/system | restore rf - > > > > this got stuck, so I started experimenting: > > > > dump 0Lf file.dump /some/file/system > > > > > > > > gets stuck, ^T will mostly return ... [running] ... since at least > > > > one of the dump process is running, but my guess it's just > > monitoring. > > > > I also tried without the L flag, but did not change the result. > > > > the only dump that finishes, is when the output is /dev/null. > > > > > > Try again with the 'a' flag. dump(8) still assumes that it writes > > > to a set of tapes, and if the writing stalls for some reason > > (restore(8) > > > being slow or somesuch), dump may ask to switch tapes. Since all this > > > is of course bogus now, use 'a' to disable all those tape size > > > calculation heuristics, as in > > > > > > # dump 0Luaf - /some/file/system | restore rf - > > true, but > > 1- if output is stdout it does not do any tape size calculations > > 2- it does not differentiate between 'regular file' and 'special > > file' > > and thus will stop requesting for another tape. > > so, yes, i forgot to say that i did use the -a flag, but i did say it's > > stuck, > > not that it's waiting for any tape change. > > > > so, sorry, no cookies yet :-) > > > > danny > > > > > I'm running my dumps from a periodic script, and it's been sat like this > since last night: > > 0 30447 30374 0 8 0 28240 25964 wait S ?? 0:00.20 dump > -1auf /mnt/dump/epcduk1/da0s1f.1.dmp /dev/da0s1f (dump) > 0 30448 30447 0 4 0 28240 25988 sbwait S ?? 0:00.87 dump: > /dev/da0s1f: pass 4: 0.08% done, finished in 13:35 at Sat Sep 8 14:37:36 > 2007 (dump) > 0 30449 30448 0 20 0 28240 25964 pause S ?? 0:00.99 dump > -1auf /mnt/dump/epcduk1/da0s1f.1.dmp /dev/da0s1f (dump) > 0 30450 30448 0 20 0 28240 25964 pause S ?? 0:01.00 dump > -1auf /mnt/dump/epcduk1/da0s1f.1.dmp /dev/da0s1f (dump) > 0 30451 30448 0 20 0 28240 25964 pause S ?? 0:01.00 dump > -1auf /mnt/dump/epcduk1/da0s1f.1.dmp /dev/da0s1f (dump) > > Is there any way of working out what's happening to these? > the only indication I can see, is that one of the dump procs. is waiting on sbwait, and probably it's some deadlock, which is similar to what I keep seeing here, i'll try now with SCHED_ULE to see if it make a difference. danny From owner-freebsd-current@FreeBSD.ORG Sat Sep 8 15:05:09 2007 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6DD0116A417; Sat, 8 Sep 2007 15:05:09 +0000 (UTC) (envelope-from bsd-current@epcdirect.co.uk) Received: from gunfright.epcdirect.co.uk (gunfright.epcdirect.co.uk [195.10.242.32]) by mx1.freebsd.org (Postfix) with ESMTP id 2BC8113C45A; Sat, 8 Sep 2007 15:05:09 +0000 (UTC) (envelope-from bsd-current@epcdirect.co.uk) Received: from localhost (localhost.epcdirect.co.uk [127.0.0.1]) by gunfright.epcdirect.co.uk (Postfix) with ESMTP id 2E50E617C; Sat, 8 Sep 2007 16:05:08 +0100 (BST) X-Virus-Scanned: by GunFright.EPCDirect.co.uk Received: from gunfright.epcdirect.co.uk ([127.0.0.1]) by localhost (gunfright.epcdirect.co.uk [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id srFknU49DNj6; Sat, 8 Sep 2007 16:05:07 +0100 (BST) Received: from lfarr (lfarr.adsl.gemsoft.co.uk [195.10.239.114]) by gunfright.epcdirect.co.uk (Postfix) with ESMTP id 576EB6176; Sat, 8 Sep 2007 16:05:05 +0100 (BST) From: "Lawrence Farr" To: "'Danny Braniss'" References: <20070904233246.GA2409@epia-2.farid-hajji.net> <043a01c7f202$a7ad0920$f7071b60$@co.uk> In-Reply-To: Date: Sat, 8 Sep 2007 16:05:03 +0100 Message-ID: <046801c7f229$a4534510$ecf9cf30$@co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcfyJjcSRld9Kgw+Rhanj/p+P4ULaQAA0OMw Content-Language: en-gb Cc: freebsd-current@FreeBSD.org, 'cpghost' , 'Gavin Atkinson' Subject: RE: dump problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Sep 2007 15:05:09 -0000 > > the only indication I can see, is that one of the dump procs. is > waiting on > sbwait, and probably it's some deadlock, which is similar to what I > keep > seeing here, i'll try now with SCHED_ULE to see if it make a > difference. I'm running SCHED_ULE on these already, if your not I guess it's not the scheduler? From owner-freebsd-current@FreeBSD.ORG Sat Sep 8 15:37:09 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0F3DD16A41A for ; Sat, 8 Sep 2007 15:37:09 +0000 (UTC) (envelope-from peter.schuller@infidyne.com) Received: from proxy1.bredband.net (proxy1.bredband.net [195.54.101.71]) by mx1.freebsd.org (Postfix) with ESMTP id BC37713C459 for ; Sat, 8 Sep 2007 15:37:08 +0000 (UTC) (envelope-from peter.schuller@infidyne.com) Received: from prometheus.scode.org (85.229.22.84) by proxy1.bredband.net (7.3.127) id 46DEA057000EAC74 for freebsd-current@freebsd.org; Sat, 8 Sep 2007 17:16:44 +0200 Received: from localhost (localhost [127.0.0.1]) by prometheus.scode.org (Postfix) with ESMTP id BBE521CC8E for ; Sat, 8 Sep 2007 17:17:05 +0200 (CEST) From: Peter Schuller To: freebsd-current@freebsd.org Date: Sat, 8 Sep 2007 17:17:04 +0200 User-Agent: KMail/1.9.7 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200709081717.05006.peter.schuller@infidyne.com> Subject: Swapping on ZFS - stability issue X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Sep 2007 15:37:09 -0000 Hello, Yesterday a machine went unresponsive (pinged, TCP connections died instantly after establishment) died after someone started MySQL with cranked up buffer sizes. When I got to the machine there was no sensible message on the console, but I did see output to the effect of "swap", "pager" and such all garbled. The machine had swap configured on a ZVOL which made me suspicious, so after rebooting I tried running a simple loop: for (int i =0 ; i < 4000; i++) { char* mem = (char*)malloc(1024*1024); memset(mem, NULL, 1024*1024); } The machine swaped a select few megs and then died completely (no messages; couldn't kill top or the test application, though the console still worked). This was done on a machine with 4 GB of RAM and 4 GB of swap on a ZVOL on 7-CURRENT. Later on I tried this on my workstation too (3 GB of RAM). Swapping to glabel-on-disk behaved as you would expect; it swapped hundreds of megs to swap device without the system every being adversely affected beyond the obvious result of disk activity and memory pressue. However, swapping either to a ZVOL or a file (through md) on ZFS exhibited similar behavior to that observed on the original server; it would get off a few megs fairly slowly followed by the system becoming completely unusable, with both top and the test app not being killable by CTRL-C, though virtual console switching was operational. Swapping to ZFS was significantly slower (on the order of factor 10 or so), yet I do not believe slowness in and of itself is the only explanation for the difference (as I would still have expected to be able to recover, even if it might have taken a bit longer). I'll see if I can confirm behavior on a more recent CURRENT. The above was on CURRENT:s from 1-2 months ago in both cases. -- / Peter Schuller PGP userID: 0xE9758B7D or 'Peter Schuller ' Key retrieval: Send an E-Mail to getpgpkey@scode.org E-Mail: peter.schuller@infidyne.com Web: http://www.scode.org From owner-freebsd-current@FreeBSD.ORG Sat Sep 8 16:41:57 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1C1DC16A468 for ; Sat, 8 Sep 2007 16:41:57 +0000 (UTC) (envelope-from tomdean@speakeasy.org) Received: from mail4.sea5.speakeasy.net (mail4.sea5.speakeasy.net [69.17.117.6]) by mx1.freebsd.org (Postfix) with ESMTP id E2E2D13C47E for ; Sat, 8 Sep 2007 16:41:56 +0000 (UTC) (envelope-from tomdean@speakeasy.org) Received: (qmail 19500 invoked from network); 8 Sep 2007 16:41:56 -0000 Received: from dsl081-173-150.sea1.dsl.speakeasy.net (HELO asus.tddhome) ([64.81.173.150]) (envelope-sender ) by mail4.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 8 Sep 2007 16:41:55 -0000 Received: from asus.tddhome (localhost.tddhome [127.0.0.1]) by asus.tddhome (8.13.8/8.13.8) with ESMTP id l88GftZ3064477 for ; Sat, 8 Sep 2007 09:41:55 -0700 (PDT) (envelope-from tomdean@asus.tddhome) Received: (from tomdean@localhost) by asus.tddhome (8.13.8/8.13.8/Submit) id l88Gft3q064474; Sat, 8 Sep 2007 09:41:55 -0700 (PDT) (envelope-from tomdean) Date: Sat, 8 Sep 2007 09:41:55 -0700 (PDT) Message-Id: <200709081641.l88Gft3q064474@asus.tddhome> From: "Thomas D. Dean" To: freebsd-current@freebsd.org Subject: Accessing non-existant cuad0 Causes Lockup X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Sep 2007 16:41:57 -0000 # uname -a FreeBSD dv6000.tddhome 7.0-CURRENT FreeBSD 7.0-CURRENT #4: \ Sat Sep 8 00:21:44 PDT 2007 \ root@dv6000.tddhome:/usr/src/sys/GENERIC i386 I have an HP Pavillion dv6446 notebook with -current. The notebook does not have a serial port. Dmesg shows sio. Dmesg from boot -v is below. With a typo, I used tip to connect to cuad0 as a normal user in the dialer group. The system locked up, no response to the keyboard, no response to ping. etc/remote has hw38400:dv=/dev/cuad0:br#38400:pa=none hu38400:dv=/dev/cuaU0:br#38400:pa=none # tip hw38400 connected and, lockup. What additional information may I provide? tomdean # dmesg Copyright (c) 1992-2007 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.0-CURRENT #4: Sat Sep 8 00:21:44 PDT 2007 root@dv6000.tddhome:/usr/src/sys/GENERIC WARNING: WITNESS option enabled, expect reduced performance. Preloaded elf kernel "/boot/kernel/kernel" at 0xc0d8c000. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc0d8c248. Calibrating clock(s) ... i8254 clock: 1193193 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 1995613575 Hz CPU: Intel(R) Core(TM) Duo CPU T2450 @ 2.00GHz (1995.61-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6ec Stepping = 12 Features=0xbfe9fbff Features2=0xc189 AMD Features=0x100000 Cores per package: 2 Instruction TLB: 4 KB Pages, 4-way set associative, 128 entries Data TLB: 4 KB Pages, 4-way set associative, 128 entries Instruction TLB: 4 MB pages, fully associative, 2 entries 2nd-level cache: 2-MB, 8-way set associative, 64-byte line size 1st-level instruction cache: 32 KB, 8-way set associative, 64 byte line size Data TLB: 4 MB Pages, 4-way set associative, 8 entries 1st-level data cache: 32 KB, 8-way set associative, 64 byte line size L2 cache: 2048 kbytes, 8-way associative, 64 bytes/line real memory = 2137456640 (2038 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009efff, 647168 bytes (158 pages) 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) 0x0000000001028000 - 0x000000007d24afff, 2082615296 bytes (508451 pages) avail memory = 2082082816 (1985 MB) MP Configuration Table version 1.4 found at 0xc009fd71 Table 'FACP' at 0x7f683bf8 Table 'APIC' at 0x7f683cec MADT: Found table at 0x7f683cec APIC: Using the MADT enumerator. MADT: Found CPU APIC ID 0 ACPI ID 0: enabled SMP: Added CPU 0 (AP) MADT: Found CPU APIC ID 1 ACPI ID 1: enabled SMP: Added CPU 1 (AP) ACPI APIC Table: INTR: Adding local APIC 1 as a target FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 bios32: Found BIOS32 Service Directory header at 0xc00f7cc0 bios32: Entry = 0xfd610 (c00fd610) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xfd610+0x273 pnpbios: Found PnP BIOS data at 0xc00f7d30 pnpbios: Entry = f0000:bde5 Rev = 1.0 Other BIOS signatures found: APIC: CPU 0 has ACPI ID 0 APIC: CPU 1 has ACPI ID 1 ACPI: RSDP @ 0x0xf7c60/0x0024 (v 2 HP ) ACPI: XSDT @ 0x0x7f67b353/0x0084 (v 1 HPQOEM SLIC-MPC 0x06040000 LTP 0x00000000) ACPI: FACP @ 0x0x7f683bf8/0x00F4 (v 3 INTEL CALISTGA 0x06040000 ALAN 0x00000001) ACPI: DSDT @ 0x0x7f67c655/0x752F (v 1 HP 30BB 0x06040000 MSFT 0x0100000E) ACPI: FACS @ 0x0x7f684fc0/0x0040 ACPI: APIC @ 0x0x7f683cec/0x0068 (v 1 HP 30BB 0x06040000 LOHR 0x0000005A) ACPI: HPET @ 0x0x7f683d54/0x0038 (v 1 HP 30BB 0x06040000 LOHR 0x0000005A) ACPI: MCFG @ 0x0x7f683d8c/0x003C (v 1 HP 30BB 0x06040000 LOHR 0x0000005A) ACPI: TCPA @ 0x0x7f683dc8/0x0032 (v 1 HP 30BB 0x06040000 PTL 0x00000001) ACPI: APIC @ 0x0x7f683dfa/0x0068 (v 1 HP 30BB 0x06040000 LTP 0x00000000) ACPI: BOOT @ 0x0x7f683e62/0x0028 (v 1 HP 30BB 0x06040000 LTP 0x00000001) ACPI: SLIC @ 0x0x7f683e8a/0x0176 (v 1 HPQOEM SLIC-MPC 0x06040000 LTP 0x00000001) ACPI: SSDT @ 0x0x7f67c44b/0x020A (v 1 HP 30BB 0x00001000 INTL 0x20050624) ACPI: SSDT @ 0x0x7f67b963/0x025F (v 1 HP 30BB 0x00003000 INTL 0x20050624) ACPI: SSDT @ 0x0x7f67b8bd/0x00A6 (v 1 HP 30BB 0x00003000 INTL 0x20050624) ACPI: SSDT @ 0x0x7f67b3d7/0x04E6 (v 1 HP 30BB 0x00003000 INTL 0x20050624) MADT: Found IO APIC ID 1, Interrupt 0 at 0xfec00000 ioapic0: Changing APIC ID to 1 ioapic0: Routing external 8259A's -> intpin 0 MADT: Interrupt override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 MADT: Interrupt override: source 9, irq 9 ioapic0: intpin 9 trigger: level lapic0: Routing NMI -> LINT1 lapic0: LINT1 trigger: edge lapic0: LINT1 polarity: high lapic1: Routing NMI -> LINT1 lapic1: LINT1 trigger: edge lapic1: LINT1 polarity: high ioapic0 irqs 0-23 on motherboard cpu0 BSP: ID: 0x00000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00000200 err: 0x00010000 pcm: 0x00010000 wlan: <802.11 Link Layer> ath_rate: version 1.2 wlan_amrr: random: nfslock: pseudo-device kbd: new array size 4 kbd1 at kbdmux0 mem: Pentium Pro MTRR support enabled io: null: ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) rr232x: RocketRAID 232x controller driver v1.02 (Sep 8 2007 00:21:27) npx0: INT 16 interface acpi0: on motherboard ioapic0: routing intpin 9 (ISA IRQ 9) to vector 48 acpi0: [MPSAFE] acpi0: [ITHREAD] acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 acpi_hpet0: vend: 0x8086 rev: 0x1 num: 1 hz: 14318180 opts: leg_route count_size Timecounter "HPET" frequency 14318180 Hz quality 900 acpi0: Power Button (fixed) acpi0: wakeup code va 0xd906f000 pa 0x1000 pci_open(1): mode 1 addr port (0x0cf8) is 0x8000fa20 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=27a08086) pcibios: BIOS version 2.10 AcpiOsDerivePciId: \\_SB_.PCI0.HBUS -> bus 0 dev 0 func 0 AcpiOsDerivePciId: \\_SB_.PCI0.RP02.P2CS -> bus 0 dev 28 func 1 AcpiOsDerivePciId: \\_SB_.PCI0.RP03.P3CS -> bus 0 dev 28 func 2 AcpiOsDerivePciId: \\_SB_.PCI0.LPCB.LPC0 -> bus 0 dev 31 func 0 acpi0: reservation of fed00000, 400 (3) failed ACPI timer: 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 -> 10 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 acpi_ec0: port 0x62,0x66 on acpi0 pci_link0: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 11 Validation 0 11 N 0 11 After Disable 0 255 N 0 11 pci_link1: Index IRQ Rtd Ref IRQs Initial Probe 0 3 N 0 3 Validation 0 3 N 0 3 After Disable 0 255 N 0 3 pci_link2: Index IRQ Rtd Ref IRQs Initial Probe 0 3 N 0 3 Validation 0 3 N 0 3 After Disable 0 255 N 0 3 pci_link3: Index IRQ Rtd Ref IRQs Initial Probe 0 4 N 0 4 Validation 0 4 N 0 4 After Disable 0 255 N 0 4 pci_link4: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 10 Validation 0 10 N 0 10 After Disable 0 255 N 0 10 pci_link5: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 11 Validation 0 255 N 0 11 After Disable 0 255 N 0 11 pci_link6: Index IRQ Rtd Ref IRQs Initial Probe 0 5 N 0 5 Validation 0 5 N 0 5 After Disable 0 255 N 0 5 pci_link7: Index IRQ Rtd Ref IRQs Initial Probe 0 7 N 0 7 Validation 0 7 N 0 7 After Disable 0 255 N 0 7 cpu0: on acpi0 ACPI: SSDT @ 0x0x7f67c109/0x027A (v 1 HP 30BB 0x00003000 INTL 0x20050624) ACPI: SSDT @ 0x0x7f67bbc2/0x04C2 (v 1 HP 30BB 0x00003001 INTL 0x20050624) est0: on cpu0 p4tcc0: on cpu0 cpu1: on acpi0 ACPI: SSDT @ 0x0x7f67c383/0x00C8 (v 1 HP 30BB 0x00003000 INTL 0x20050624) ACPI: SSDT @ 0x0x7f67c084/0x0085 (v 1 HP 30BB 0x00003000 INTL 0x20050624) est1: on cpu1 p4tcc1: on cpu1 acpi_button0: on acpi0 acpi_button1: on acpi0 acpi_acad0: on acpi0 battery0: on acpi0 acpi_lid0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: physical bus=0 found-> vendor=0x8086, dev=0x27a0, revid=0x03 bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0106, statreg=0x2090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x27a2, revid=0x03 bus=0, slot=2, func=0 class=03-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message map[10]: type Memory, range 32, base 0xd8100000, size 19, enabled map[14]: type I/O Port, range 32, base 0x1800, size 3, enabled map[18]: type Prefetchable Memory, range 32, base 0xc0000000, size 28, enabled map[1c]: type Memory, range 32, base 0xd8200000, size 18, enabled pcib0: matched entry for 0.2.INTA pcib0: slot 2 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x27a6, revid=0x03 bus=0, slot=2, func=1 class=03-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xd8180000, size 19, enabled found-> vendor=0x8086, dev=0x27d8, revid=0x02 bus=0, slot=27, func=0 class=04-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 64, base 0xd8240000, size 14, enabled pcib0: matched entry for 0.27.INTA pcib0: slot 27 INTA hardwired to IRQ 22 found-> vendor=0x8086, dev=0x27d0, revid=0x02 bus=0, slot=28, func=0 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) intpin=a, irq=3 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTA pcib0: slot 28 INTA hardwired to IRQ 17 found-> vendor=0x8086, dev=0x27d2, revid=0x02 bus=0, slot=28, func=1 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) intpin=b, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTB pcib0: slot 28 INTB hardwired to IRQ 16 found-> vendor=0x8086, dev=0x27c8, revid=0x02 bus=0, slot=29, func=0 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=7 map[20]: type I/O Port, range 32, base 0x1820, size 5, enabled pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 23 found-> vendor=0x8086, dev=0x27c9, revid=0x02 bus=0, slot=29, func=1 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=10 map[20]: type I/O Port, range 32, base 0x1840, size 5, enabled pcib0: matched entry for 0.29.INTB pcib0: slot 29 INTB hardwired to IRQ 19 found-> vendor=0x8086, dev=0x27ca, revid=0x02 bus=0, slot=29, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=3 map[20]: type I/O Port, range 32, base 0x1860, size 5, enabled pcib0: matched entry for 0.29.INTC pcib0: slot 29 INTC hardwired to IRQ 18 found-> vendor=0x8086, dev=0x27cb, revid=0x02 bus=0, slot=29, func=3 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=d, irq=11 map[20]: type I/O Port, range 32, base 0x1880, size 5, enabled pcib0: matched entry for 0.29.INTD pcib0: slot 29 INTD hardwired to IRQ 16 found-> vendor=0x8086, dev=0x27cc, revid=0x02 bus=0, slot=29, func=7 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=7 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xd8444000, size 10, enabled pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 23 found-> vendor=0x8086, dev=0x2448, revid=0xe2 bus=0, slot=30, func=0 class=06-04-01, hdrtype=0x01, mfdev=0 cmdreg=0x0004, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x27b9, revid=0x02 bus=0, slot=31, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x27df, revid=0x02 bus=0, slot=31, func=1 class=01-01-8a, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 map[20]: type I/O Port, range 32, base 0x1810, size 4, enabled found-> vendor=0x8086, dev=0x27c5, revid=0x02 bus=0, slot=31, func=2 class=01-06-01, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x02b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=4 powerspec 2 supports D0 D3 current D0 MSI supports 1 message map[10]: type I/O Port, range 32, base 0x18d0, size 3, enabled map[14]: type I/O Port, range 32, base 0x18c4, size 2, enabled map[18]: type I/O Port, range 32, base 0x18c8, size 3, enabled map[1c]: type I/O Port, range 32, base 0x18c0, size 2, enabled map[20]: type I/O Port, range 32, base 0x18b0, size 4, enabled map[24]: type Memory, range 32, base 0xd8444400, size 10, enabled pcib0: matched entry for 0.31.INTB pcib0: slot 31 INTB hardwired to IRQ 19 found-> vendor=0x8086, dev=0x27da, revid=0x02 bus=0, slot=31, func=3 class=0c-05-00, hdrtype=0x00, mfdev=0 cmdreg=0x0001, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=4 map[20]: type I/O Port, range 32, base 0x18e0, size 5, enabled pcib0: matched entry for 0.31.INTB pcib0: slot 31 INTB hardwired to IRQ 19 vgapci0: port 0x1800-0x1807 mem 0xd8100000-0xd817ffff,0xc0000000-0xcfffffff,0xd8200000-0xd823ffff irq 16 at device 2.0 on pci0 agp0: on vgapci0 vgapci0: Reserved 0x10000000 bytes for rid 0x18 type 3 at 0xc0000000 vgapci0: Reserved 0x80000 bytes for rid 0x10 type 3 at 0xd8100000 vgapci0: Reserved 0x40000 bytes for rid 0x1c type 3 at 0xd8200000 agp0: detected 7932k stolen memory agp0: aperture size is 256M vgapci1: mem 0xd8180000-0xd81fffff at device 2.1 on pci0 pci0: at device 27.0 (no driver attached) pcib1: irq 17 at device 28.0 on pci0 pcib1: secondary bus 2 pcib1: subordinate bus 2 pcib1: I/O decode 0x2000-0x2fff pcib1: memory decode 0xd6000000-0xd7ffffff pcib1: prefetched decode 0xd2000000-0xd3ffffff pci2: on pcib1 pci2: physical bus=2 found-> vendor=0x8086, dev=0x4222, revid=0x02 bus=2, slot=0, func=0 class=02-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 32, base 0xd6000000, size 12, enabled pcib1: requested memory range 0xd6000000-0xd6000fff: good pcib1: matched entry for 2.0.INTA pcib1: slot 0 INTA hardwired to IRQ 16 pci2: at device 0.0 (no driver attached) pcib2: irq 16 at device 28.1 on pci0 pcib2: secondary bus 3 pcib2: subordinate bus 4 pcib2: I/O decode 0x3000-0x3fff pcib2: memory decode 0xd4000000-0xd5ffffff pcib2: prefetched decode 0xd0000000-0xd1ffffff pci3: on pcib2 pci3: physical bus=3 uhci0: port 0x1820-0x183f irq 23 at device 29.0 on pci0 uhci0: Reserved 0x20 bytes for rid 0x20 type 4 at 0x1820 ioapic0: routing intpin 23 (PCI IRQ 23) to vector 49 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0x1840-0x185f irq 19 at device 29.1 on pci0 uhci1: Reserved 0x20 bytes for rid 0x20 type 4 at 0x1840 ioapic0: routing intpin 19 (PCI IRQ 19) to vector 50 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0x1860-0x187f irq 18 at device 29.2 on pci0 uhci2: Reserved 0x20 bytes for rid 0x20 type 4 at 0x1860 ioapic0: routing intpin 18 (PCI IRQ 18) to vector 51 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb2: on uhci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered uhci3: port 0x1880-0x189f irq 16 at device 29.3 on pci0 uhci3: Reserved 0x20 bytes for rid 0x20 type 4 at 0x1880 ioapic0: routing intpin 16 (PCI IRQ 16) to vector 52 uhci3: [GIANT-LOCKED] uhci3: [ITHREAD] usb3: on uhci3 usb3: USB revision 1.0 uhub3: on usb3 uhub3: 2 ports with 2 removable, self powered ehci0: mem 0xd8444000-0xd84443ff irq 23 at device 29.7 on pci0 ehci0: Reserved 0x400 bytes for rid 0x10 type 3 at 0xd8444000 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb4: EHCI version 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: on ehci0 usb4: USB revision 2.0 uhub4: on usb4 uhub4: 8 ports with 8 removable, self powered ugen0: on uhub4 pcib3: at device 30.0 on pci0 pcib3: secondary bus 5 pcib3: subordinate bus 5 pcib3: I/O decode 0x0-0x0 pcib3: no prefetched decode pcib3: Subtractively decoded bridge. pci5: on pcib3 pci5: physical bus=5 found-> vendor=0x1180, dev=0x0832, revid=0x00 bus=5, slot=5, func=0 class=0c-00-10, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x04 (1000 ns) intpin=a, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0xd8001000, size 11, enabled pcib3: requested memory range 0xd8001000-0xd80017ff: good pcib3: matched entry for 5.5.INTA pcib3: slot 5 INTA hardwired to IRQ 16 found-> vendor=0x1180, dev=0x0822, revid=0x19 bus=5, slot=5, func=1 class=08-05-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=3 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0xd8001800, size 8, memory disabled pcib3: requested memory range 0xd8001800-0xd80018ff: good pcib3: matched entry for 5.5.INTB pcib3: slot 5 INTB hardwired to IRQ 17 found-> vendor=0x1180, dev=0x0843, revid=0x01 bus=5, slot=5, func=2 class=08-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=3 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0xd8001c00, size 8, memory disabled pcib3: requested memory range 0xd8001c00-0xd8001cff: good pcib3: matched entry for 5.5.INTB pcib3: slot 5 INTB hardwired to IRQ 17 found-> vendor=0x1180, dev=0x0592, revid=0x0a bus=5, slot=5, func=3 class=08-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=3 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0xd8002000, size 8, memory disabled pcib3: requested memory range 0xd8002000-0xd80020ff: good pcib3: matched entry for 5.5.INTB pcib3: slot 5 INTB hardwired to IRQ 17 found-> vendor=0x1180, dev=0x0852, revid=0x05 bus=5, slot=5, func=4 class=08-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=3 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0xd8002400, size 8, memory disabled pcib3: requested memory range 0xd8002400-0xd80024ff: good pcib3: matched entry for 5.5.INTB pcib3: slot 5 INTB hardwired to IRQ 17 found-> vendor=0x8086, dev=0x1092, revid=0x02 bus=5, slot=8, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0003, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x08 (2000 ns), maxlat=0x38 (14000 ns) intpin=a, irq=10 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0xd8000000, size 12, enabled pcib3: requested memory range 0xd8000000-0xd8000fff: good map[14]: type I/O Port, range 32, base 0x4000, size 6, enabled pcib3: matched entry for 5.8.INTA pcib3: slot 8 INTA hardwired to IRQ 20 fwohci0: vendor=1180, dev=832 fwohci0: vendor=1180, dev=832 fwohci0: <1394 Open Host Controller Interface> mem 0xd8001000-0xd80017ff irq 16 at device 5.0 on pci5 fwohci0: Reserved 0x800 bytes for rid 0x10 type 3 at 0xd8001000 fwohci0: [MPSAFE] fwohci0: [FILTER] fwohci0: OHCI version 1.10 (ROM=0) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:24:1b:00:bb:30:23:00 fwohci0: Phy 1394a available S400, 1 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:24:1b:30:23:00 fwe0: bpf attached fwe0: Ethernet address: 02:24:1b:30:23:00 fwip0: on firewire0 fwip0: bpf attached fwip0: Firewire address: 00:24:1b:00:bb:30:23:00 @ 0xfffe00000000, S400, maxrec 2048 sbp0: on firewire0 dcons_crom0: on firewire0 dcons_crom0: bus_addr 0x7d0c0000 fwohci0: Initiate bus reset fwohci0: BUS reset fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode pci5: at device 5.1 (no driver attached) pci5: at device 5.2 (no driver attached) pci5: at device 5.3 (no driver attached) pci5: at device 5.4 (no driver attached) fxp0: port 0x4000-0x403f mem 0xd8000000-0xd8000fff irq 20 at device 8.0 on pci5 fxp0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xd8000000 fxp0: using memory space register mapping fxp0: PCI IDs: 8086 1092 103c 30bb 0002 fxp0: Dynamic Standby mode is enabled miibus0: on fxp0 inphy0: PHY 1 on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: bpf attached fxp0: Ethernet address: 00:1b:24:49:da:97 ioapic0: routing intpin 20 (PCI IRQ 20) to vector 53 fxp0: [MPSAFE] fxp0: [ITHREAD] isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1810-0x181f at device 31.1 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0x1810 ata0: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 atapci0: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 ata0: reset tp1 mask=03 ostat0=50 ostat1=00 ata0: stat0=0x00 err=0x01 lsb=0x14 msb=0xeb ata0: stat1=0x00 err=0x00 lsb=0x00 msb=0x00 ata0: reset tp2 stat0=00 stat1=00 devices=0x4 ioapic0: routing intpin 14 (ISA IRQ 14) to vector 54 ata0: [MPSAFE] ata0: [ITHREAD] ata1: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170 atapci0: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376 ata1: reset tp1 mask=00 ostat0=ff ostat1=ff ioapic0: routing intpin 15 (ISA IRQ 15) to vector 55 ata1: [MPSAFE] ata1: [ITHREAD] atapci1: port 0x18d0-0x18d7,0x18c4-0x18c7,0x18c8-0x18cf,0x18c0-0x18c3,0x18b0-0x18bf mem 0xd8444400-0xd84447ff irq 19 at device 31.2 on pci0 atapci1: Reserved 0x10 bytes for rid 0x20 type 4 at 0x18b0 atapci1: [MPSAFE] atapci1: [ITHREAD] atapci1: Reserved 0x400 bytes for rid 0x24 type 3 at 0xd8444400 atapci1: AHCI Version 01.10 controller with 4 ports detected ata2: on atapci1 ata2: SATA connect time=0ms ata2: [MPSAFE] ata2: [ITHREAD] ata3: on atapci1 ata3: port not implemented ata3: [MPSAFE] ata3: [ITHREAD] ata4: on atapci1 ata4: SATA connect status=00000000 ata4: [MPSAFE] ata4: [ITHREAD] ata5: on atapci1 ata5: port not implemented ata5: [MPSAFE] ata5: [ITHREAD] pci0: at device 31.3 (no driver attached) acpi_tz0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0047 atkbd: keyboard ID 0x41ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 ioapic0: routing intpin 1 (ISA IRQ 1) to vector 56 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: unable to allocate IRQ psmcpnp0: irq 12 on acpi0 psm0: current command byte:0047 psm0: irq 12 on atkbdc0 ioapic0: routing intpin 12 (ISA IRQ 12) to vector 57 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model IntelliMouse, device ID 3-00, 3 buttons psm0: config:00000000, flags:00000008, packet size:4 psm0: syncmask:08, syncbits:00 unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff ex_isa_identify() ata: ata0 already exists; skipping it ata: ata1 already exists; skipping it atkbdc: atkbdc0 already exists; skipping it pnp_identify: Trying Read_Port at 203 pnp_identify: Trying Read_Port at 243 pnp_identify: Trying Read_Port at 283 pnp_identify: Trying Read_Port at 2c3 pnp_identify: Trying Read_Port at 303 pnp_identify: Trying Read_Port at 343 pnp_identify: Trying Read_Port at 383 pnp_identify: Trying Read_Port at 3c3 PNP Identify complete sc: sc0 already exists; skipping it vga: vga0 already exists; skipping it isa_probe_children: disabling PnP devices isa_probe_children: probing non-PnP devices pmtimer0 on isa0 orm0: at iomem 0xce800-0xcffff,0xdf000-0xdf7ff,0xe0000-0xe17ff pnpid ORM0000 on isa0 adv0: not probed (disabled) aha0: not probed (disabled) aic0: not probed (disabled) bt0: not probed (disabled) cs0: not probed (disabled) ed0: not probed (disabled) fdc0 failed to probe at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fe0: not probed (disabled) ie0: not probed (disabled) le0: not probed (disabled) ppc0: parallel port not found. ppc0: failed to probe at irq 7 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd1, terminal emulator: sc (syscons terminal) sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: irq maps: 0xeb9 0xeb9 0xeb9 0xeb9 sio0: probe failed test(s): 0 1 2 4 6 7 9 sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: irq maps: 0xeb9 0xeb9 0xeb9 0xeb9 sio0: probe failed test(s): 0 1 2 4 6 7 9 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 8250 or not responding ioapic0: routing intpin 4 (ISA IRQ 4) to vector 58 sio0: [FILTER] sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1: irq maps: 0xeb9 0xeb9 0xeb9 0xeb9 sio1: probe failed test(s): 0 1 2 4 6 7 9 sio1 failed to probe at port 0x2f8-0x2ff irq 3 on isa0 sio2: not probed (disabled) sio3: not probed (disabled) sn0: not probed (disabled) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 vt0: not probed (disabled) isa_probe_children: probing PnP devices Device configuration finished. Reducing kern.maxvnodes 133508 -> 100000 procfs registered lapic: Divisor 2, Frequency 66520468 hz Timecounter "TSC" frequency 1995613575 Hz quality -100 Timecounters tick every 1.000 msec lo0: bpf attached rr232x: no controller detected. firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) ata0-master: pio=PIO4 wdma=WDMA2 udma=UNSUPPORTED cable=40 wire acd0: setting PIO4 on ICH7 chip acpi_acad0: acline initialization start acpi_acad0: On Line acpi_acad0: acline initialization done, tried 1 times battery0: battery initialization start acd0: DVDR drive at ata0 as master acd0: read 4134KB/s (4134KB/s) write 4134KB/s (4134KB/s), 2048KB buffer, PIO4 acd0: Reads: CDR, CDRW, CDDA stream, DVDROM, DVDR, DVDRAM, packet acd0: Writes: CDR, CDRW, DVDR, DVDRAM, test write, burnproof acd0: Audio: play, 256 volume levels acd0: Mechanism: ejectable tray, unlocked acd0: Medium: no/blank disc ata2-master: pio=PIO4 wdma=WDMA2 udma=UDMA100 cable=40 wire ad4: 152627MB at ata2-master SATA150 ad4: 312581808 sectors [310101C/16H/63S] 16 sectors/interrupt 1 depth queue GEOM: new disk ad4 battery0: battery initialization done, tried 1 times ad4: Intel check1 failed ad4: Adaptec check1 failed ad4: LSI (v3) check1 failed ad4: LSI (v2) check1 failed ad4: FreeBSD check1 failed (probe0:sbp0:0:0:0): error 22 (probe0:sbp0:0:0:0): Unretryable Error (probe1:sbp0:0:1:0): error 22 (probe1:sbp0:0:1:0): Unretryable Error (probe2:sbp0:0:2:0): error 22 (probe2:sbp0:0:2:0): Unretryable Error (probe3:sbp0:0:3:0): error 22 (probe3:sbp0:0:3:0): Unretryable Error (probe4:sbp0:0:4:0): error 22 (probe4:sbp0:0:4:0): Unretryable Error (probe5:sbp0:0:5:0): error 22 (probe5:sbp0:0:5:0): Unretryable Error (probe6:sbp0:0:6:0): error 22 (probe6:sbp0:0:6:0): Unretryable Error ATA PseudoRAID loaded SMP: AP CPU #1 Launched! cpu1 AP: ID: 0x01000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010200 err: 0x00010000 pcm: 0x00010000 ioapic0: Assigning ISA IRQ 1 to local APIC 0 ioapic0: Assigning ISA IRQ 4 to local APIC 1 ioapic0: Assigning ISA IRQ 9 to local APIC 0 ioapic0: Assigning ISA IRQ 12 to local APIC 1 ioapic0: Assigning ISA IRQ 14 to local APIC 0 ioapic0: Assigning ISA IRQ 15 to local APIC 1 ioapic0: Assigning PCI IRQ 16 to local APIC 0 ioapic0: Assigning PCI IRQ 18 to local APIC 1 ioapic0: Assigning PCI IRQ 19 to local APIC 0 ioapic0: Assigning PCI IRQ 20 to local APIC 1 ioapic0: Assigning PCI IRQ 23 to local APIC 0 WARNING: WITNESS option enabled, expect reduced performance. Trying to mount root from ufs:/dev/ad4s1a start_init: trying /sbin/init Linux ELF exec handler installed From owner-freebsd-current@FreeBSD.ORG Sat Sep 8 17:08:12 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D353816A417 for ; Sat, 8 Sep 2007 17:08:12 +0000 (UTC) (envelope-from scode@hyperion.scode.org) Received: from hyperion.scode.org (cl-1361.ams-04.nl.sixxs.net [IPv6:2001:960:2:550::2]) by mx1.freebsd.org (Postfix) with ESMTP id 8EDB213C45E for ; Sat, 8 Sep 2007 17:08:12 +0000 (UTC) (envelope-from scode@hyperion.scode.org) Received: by hyperion.scode.org (Postfix, from userid 1001) id C150A23C4B4; Sat, 8 Sep 2007 19:08:10 +0200 (CEST) Date: Sat, 8 Sep 2007 19:08:10 +0200 From: Peter Schuller To: freebsd-current@freebsd.org Message-ID: <20070908170810.GA90578@hyperion.scode.org> References: <200709081717.05006.peter.schuller@infidyne.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="oyUTqETQ0mS9luUI" Content-Disposition: inline In-Reply-To: <200709081717.05006.peter.schuller@infidyne.com> User-Agent: Mutt/1.5.16 (2007-06-09) Subject: Re: Swapping on ZFS - stability issue X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Sep 2007 17:08:12 -0000 --oyUTqETQ0mS9luUI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > I'll see if I can confirm behavior on a more recent CURRENT. The above wa= s on=20 > CURRENT:s from 1-2 months ago in both cases. Confirmed on CURRENT cvsup:ed today (2007-09-08). However, the speed at which swap was filling was much faster - on par with swap on non-ZFS. But the machine still effectively froze, save the console/ping, after a few seconds. Also, I forgot to say this is all on amd64 machines. --=20 / Peter Schuller PGP userID: 0xE9758B7D or 'Peter Schuller ' Key retrieval: Send an E-Mail to getpgpkey@scode.org E-Mail: peter.schuller@infidyne.com Web: http://www.scode.org --oyUTqETQ0mS9luUI Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFG4tb5DNor2+l1i30RAuVmAKDX3Phq/KkfQYd+FHVIDEHfsXc/xgCguJ33 xdRHm1Nf9wvgI5RRfC0JkEw= =XFEE -----END PGP SIGNATURE----- --oyUTqETQ0mS9luUI-- From owner-freebsd-current@FreeBSD.ORG Sat Sep 8 17:19:53 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3EC7316A418 for ; Sat, 8 Sep 2007 17:19:53 +0000 (UTC) (envelope-from nike_d@cytexbg.com) Received: from mail.interbgc.com (mx04.interbgc.com [217.9.224.231]) by mx1.freebsd.org (Postfix) with SMTP id 8C05913C457 for ; Sat, 8 Sep 2007 17:19:51 +0000 (UTC) (envelope-from nike_d@cytexbg.com) Received: (qmail 42495 invoked from network); 8 Sep 2007 16:53:08 -0000 Received: from nike_d@cytexbg.com by keeper.interbgc.com by uid 1002 with qmail-scanner-1.14 (uvscan: v4.2.40/v4374. spamassassin: 2.63. Clear:SA:0(-2.6/8.0):. Processed in 2.990671 secs); 08 Sep 2007 16:53:08 -0000 X-Spam-Status: No, hits=-2.6 required=8.0 Received: from unknown (HELO ndenev.totalterror.net) (85.130.5.170) by mx04.interbgc.com with SMTP; 8 Sep 2007 16:53:05 -0000 Received: (qmail 5050 invoked from network); 8 Sep 2007 19:52:11 +0300 Received: from unknown (HELO ?127.0.0.1?) (127.0.0.1) by ndenev.totalterror.net with SMTP; 8 Sep 2007 19:52:11 +0300 Message-ID: <46E2D33B.9000207@cytexbg.com> Date: Sat, 08 Sep 2007 19:52:11 +0300 From: Niki Denev User-Agent: Thunderbird 1.5.0.10 (X11/20070326) MIME-Version: 1.0 To: "Thomas D. Dean" References: <200709081641.l88Gft3q064474@asus.tddhome> In-Reply-To: <200709081641.l88Gft3q064474@asus.tddhome> X-Enigmail-Version: 0.94.3.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Accessing non-existant cuad0 Causes Lockup X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Sep 2007 17:19:53 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thomas D. Dean wrote: > # uname -a > FreeBSD dv6000.tddhome 7.0-CURRENT FreeBSD 7.0-CURRENT #4: \ > Sat Sep 8 00:21:44 PDT 2007 \ > root@dv6000.tddhome:/usr/src/sys/GENERIC i386 > > I have an HP Pavillion dv6446 notebook with -current. The notebook > does not have a serial port. Dmesg shows sio. Dmesg from boot -v is > below. > > With a typo, I used tip to connect to cuad0 as a normal user in the > dialer group. The system locked up, no response to the keyboard, no > response to ping. > > etc/remote has > hw38400:dv=/dev/cuad0:br#38400:pa=none > hu38400:dv=/dev/cuaU0:br#38400:pa=none > > # tip hw38400 > connected > > and, lockup. > > What additional information may I provide? > > tomdean > > # dmesg > Copyright (c) 1992-2007 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 7.0-CURRENT #4: Sat Sep 8 00:21:44 PDT 2007 > root@dv6000.tddhome:/usr/src/sys/GENERIC > WARNING: WITNESS option enabled, expect reduced performance. > Preloaded elf kernel "/boot/kernel/kernel" at 0xc0d8c000. > Preloaded elf module "/boot/kernel/acpi.ko" at 0xc0d8c248. > Calibrating clock(s) ... i8254 clock: 1193193 Hz > CLK_USE_I8254_CALIBRATION not specified - using default frequency > Timecounter "i8254" frequency 1193182 Hz quality 0 > Calibrating TSC clock ... TSC clock: 1995613575 Hz > CPU: Intel(R) Core(TM) Duo CPU T2450 @ 2.00GHz (1995.61-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0x6ec Stepping = 12 > Features=0xbfe9fbff > Features2=0xc189 > AMD Features=0x100000 > Cores per package: 2 > > Instruction TLB: 4 KB Pages, 4-way set associative, 128 entries > Data TLB: 4 KB Pages, 4-way set associative, 128 entries > Instruction TLB: 4 MB pages, fully associative, 2 entries > 2nd-level cache: 2-MB, 8-way set associative, 64-byte line size > 1st-level instruction cache: 32 KB, 8-way set associative, 64 byte line size > Data TLB: 4 MB Pages, 4-way set associative, 8 entries > 1st-level data cache: 32 KB, 8-way set associative, 64 byte line size > L2 cache: 2048 kbytes, 8-way associative, 64 bytes/line > real memory = 2137456640 (2038 MB) > Physical memory chunk(s): > 0x0000000000001000 - 0x000000000009efff, 647168 bytes (158 pages) > 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) > 0x0000000001028000 - 0x000000007d24afff, 2082615296 bytes (508451 pages) > avail memory = 2082082816 (1985 MB) > MP Configuration Table version 1.4 found at 0xc009fd71 > Table 'FACP' at 0x7f683bf8 > Table 'APIC' at 0x7f683cec > MADT: Found table at 0x7f683cec > APIC: Using the MADT enumerator. > MADT: Found CPU APIC ID 0 ACPI ID 0: enabled > SMP: Added CPU 0 (AP) > MADT: Found CPU APIC ID 1 ACPI ID 1: enabled > SMP: Added CPU 1 (AP) > ACPI APIC Table: > INTR: Adding local APIC 1 as a target > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 1 > bios32: Found BIOS32 Service Directory header at 0xc00f7cc0 > bios32: Entry = 0xfd610 (c00fd610) Rev = 0 Len = 1 > pcibios: PCI BIOS entry at 0xfd610+0x273 > pnpbios: Found PnP BIOS data at 0xc00f7d30 > pnpbios: Entry = f0000:bde5 Rev = 1.0 > Other BIOS signatures found: > APIC: CPU 0 has ACPI ID 0 > APIC: CPU 1 has ACPI ID 1 > ACPI: RSDP @ 0x0xf7c60/0x0024 (v 2 HP ) > ACPI: XSDT @ 0x0x7f67b353/0x0084 (v 1 HPQOEM SLIC-MPC 0x06040000 LTP 0x00000000) > ACPI: FACP @ 0x0x7f683bf8/0x00F4 (v 3 INTEL CALISTGA 0x06040000 ALAN 0x00000001) > ACPI: DSDT @ 0x0x7f67c655/0x752F (v 1 HP 30BB 0x06040000 MSFT 0x0100000E) > ACPI: FACS @ 0x0x7f684fc0/0x0040 > ACPI: APIC @ 0x0x7f683cec/0x0068 (v 1 HP 30BB 0x06040000 LOHR 0x0000005A) > ACPI: HPET @ 0x0x7f683d54/0x0038 (v 1 HP 30BB 0x06040000 LOHR 0x0000005A) > ACPI: MCFG @ 0x0x7f683d8c/0x003C (v 1 HP 30BB 0x06040000 LOHR 0x0000005A) > ACPI: TCPA @ 0x0x7f683dc8/0x0032 (v 1 HP 30BB 0x06040000 PTL 0x00000001) > ACPI: APIC @ 0x0x7f683dfa/0x0068 (v 1 HP 30BB 0x06040000 LTP 0x00000000) > ACPI: BOOT @ 0x0x7f683e62/0x0028 (v 1 HP 30BB 0x06040000 LTP 0x00000001) > ACPI: SLIC @ 0x0x7f683e8a/0x0176 (v 1 HPQOEM SLIC-MPC 0x06040000 LTP 0x00000001) > ACPI: SSDT @ 0x0x7f67c44b/0x020A (v 1 HP 30BB 0x00001000 INTL 0x20050624) > ACPI: SSDT @ 0x0x7f67b963/0x025F (v 1 HP 30BB 0x00003000 INTL 0x20050624) > ACPI: SSDT @ 0x0x7f67b8bd/0x00A6 (v 1 HP 30BB 0x00003000 INTL 0x20050624) > ACPI: SSDT @ 0x0x7f67b3d7/0x04E6 (v 1 HP 30BB 0x00003000 INTL 0x20050624) > MADT: Found IO APIC ID 1, Interrupt 0 at 0xfec00000 > ioapic0: Changing APIC ID to 1 > ioapic0: Routing external 8259A's -> intpin 0 > MADT: Interrupt override: source 0, irq 2 > ioapic0: Routing IRQ 0 -> intpin 2 > MADT: Interrupt override: source 9, irq 9 > ioapic0: intpin 9 trigger: level > lapic0: Routing NMI -> LINT1 > lapic0: LINT1 trigger: edge > lapic0: LINT1 polarity: high > lapic1: Routing NMI -> LINT1 > lapic1: LINT1 trigger: edge > lapic1: LINT1 polarity: high > ioapic0 irqs 0-23 on motherboard > cpu0 BSP: > ID: 0x00000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff > lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff > timer: 0x000100ef therm: 0x00000200 err: 0x00010000 pcm: 0x00010000 > wlan: <802.11 Link Layer> > ath_rate: version 1.2 > wlan_amrr: > random: > nfslock: pseudo-device > kbd: new array size 4 > kbd1 at kbdmux0 > mem: > Pentium Pro MTRR support enabled > io: > null: > ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) > rr232x: RocketRAID 232x controller driver v1.02 (Sep 8 2007 00:21:27) > npx0: INT 16 interface > acpi0: on motherboard > ioapic0: routing intpin 9 (ISA IRQ 9) to vector 48 > acpi0: [MPSAFE] > acpi0: [ITHREAD] > acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 > acpi_hpet0: vend: 0x8086 rev: 0x1 num: 1 hz: 14318180 opts: leg_route count_size > Timecounter "HPET" frequency 14318180 Hz quality 900 > acpi0: Power Button (fixed) > acpi0: wakeup code va 0xd906f000 pa 0x1000 > pci_open(1): mode 1 addr port (0x0cf8) is 0x8000fa20 > pci_open(1a): mode1res=0x80000000 (0x80000000) > pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=27a08086) > pcibios: BIOS version 2.10 > AcpiOsDerivePciId: \\_SB_.PCI0.HBUS -> bus 0 dev 0 func 0 > AcpiOsDerivePciId: \\_SB_.PCI0.RP02.P2CS -> bus 0 dev 28 func 1 > AcpiOsDerivePciId: \\_SB_.PCI0.RP03.P3CS -> bus 0 dev 28 func 2 > AcpiOsDerivePciId: \\_SB_.PCI0.LPCB.LPC0 -> bus 0 dev 31 func 0 > acpi0: reservation of fed00000, 400 (3) failed > ACPI timer: 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 -> 10 > Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 > acpi_ec0: port 0x62,0x66 on acpi0 > pci_link0: Index IRQ Rtd Ref IRQs > Initial Probe 0 11 N 0 11 > Validation 0 11 N 0 11 > After Disable 0 255 N 0 11 > pci_link1: Index IRQ Rtd Ref IRQs > Initial Probe 0 3 N 0 3 > Validation 0 3 N 0 3 > After Disable 0 255 N 0 3 > pci_link2: Index IRQ Rtd Ref IRQs > Initial Probe 0 3 N 0 3 > Validation 0 3 N 0 3 > After Disable 0 255 N 0 3 > pci_link3: Index IRQ Rtd Ref IRQs > Initial Probe 0 4 N 0 4 > Validation 0 4 N 0 4 > After Disable 0 255 N 0 4 > pci_link4: Index IRQ Rtd Ref IRQs > Initial Probe 0 10 N 0 10 > Validation 0 10 N 0 10 > After Disable 0 255 N 0 10 > pci_link5: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 11 > Validation 0 255 N 0 11 > After Disable 0 255 N 0 11 > pci_link6: Index IRQ Rtd Ref IRQs > Initial Probe 0 5 N 0 5 > Validation 0 5 N 0 5 > After Disable 0 255 N 0 5 > pci_link7: Index IRQ Rtd Ref IRQs > Initial Probe 0 7 N 0 7 > Validation 0 7 N 0 7 > After Disable 0 255 N 0 7 > cpu0: on acpi0 > ACPI: SSDT @ 0x0x7f67c109/0x027A (v 1 HP 30BB 0x00003000 INTL 0x20050624) > ACPI: SSDT @ 0x0x7f67bbc2/0x04C2 (v 1 HP 30BB 0x00003001 INTL 0x20050624) > est0: on cpu0 > p4tcc0: on cpu0 > cpu1: on acpi0 > ACPI: SSDT @ 0x0x7f67c383/0x00C8 (v 1 HP 30BB 0x00003000 INTL 0x20050624) > ACPI: SSDT @ 0x0x7f67c084/0x0085 (v 1 HP 30BB 0x00003000 INTL 0x20050624) > est1: on cpu1 > p4tcc1: on cpu1 > acpi_button0: on acpi0 > acpi_button1: on acpi0 > acpi_acad0: on acpi0 > battery0: on acpi0 > acpi_lid0: on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > pci0: physical bus=0 > found-> vendor=0x8086, dev=0x27a0, revid=0x03 > bus=0, slot=0, func=0 > class=06-00-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0106, statreg=0x2090, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > found-> vendor=0x8086, dev=0x27a2, revid=0x03 > bus=0, slot=2, func=0 > class=03-00-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0007, statreg=0x0090, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=a, irq=11 > powerspec 2 supports D0 D3 current D0 > MSI supports 1 message > map[10]: type Memory, range 32, base 0xd8100000, size 19, enabled > map[14]: type I/O Port, range 32, base 0x1800, size 3, enabled > map[18]: type Prefetchable Memory, range 32, base 0xc0000000, size 28, enabled > map[1c]: type Memory, range 32, base 0xd8200000, size 18, enabled > pcib0: matched entry for 0.2.INTA > pcib0: slot 2 INTA hardwired to IRQ 16 > found-> vendor=0x8086, dev=0x27a6, revid=0x03 > bus=0, slot=2, func=1 > class=03-80-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0007, statreg=0x0090, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > powerspec 2 supports D0 D3 current D0 > map[10]: type Memory, range 32, base 0xd8180000, size 19, enabled > found-> vendor=0x8086, dev=0x27d8, revid=0x02 > bus=0, slot=27, func=0 > class=04-03-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0006, statreg=0x0010, cachelnsz=16 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=a, irq=5 > powerspec 2 supports D0 D3 current D0 > MSI supports 1 message, 64 bit > map[10]: type Memory, range 64, base 0xd8240000, size 14, enabled > pcib0: matched entry for 0.27.INTA > pcib0: slot 27 INTA hardwired to IRQ 22 > found-> vendor=0x8086, dev=0x27d0, revid=0x02 > bus=0, slot=28, func=0 > class=06-04-00, hdrtype=0x01, mfdev=1 > cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) > lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) > intpin=a, irq=3 > powerspec 2 supports D0 D3 current D0 > MSI supports 1 message > pcib0: matched entry for 0.28.INTA > pcib0: slot 28 INTA hardwired to IRQ 17 > found-> vendor=0x8086, dev=0x27d2, revid=0x02 > bus=0, slot=28, func=1 > class=06-04-00, hdrtype=0x01, mfdev=1 > cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) > lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) > intpin=b, irq=11 > powerspec 2 supports D0 D3 current D0 > MSI supports 1 message > pcib0: matched entry for 0.28.INTB > pcib0: slot 28 INTB hardwired to IRQ 16 > found-> vendor=0x8086, dev=0x27c8, revid=0x02 > bus=0, slot=29, func=0 > class=0c-03-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=a, irq=7 > map[20]: type I/O Port, range 32, base 0x1820, size 5, enabled > pcib0: matched entry for 0.29.INTA > pcib0: slot 29 INTA hardwired to IRQ 23 > found-> vendor=0x8086, dev=0x27c9, revid=0x02 > bus=0, slot=29, func=1 > class=0c-03-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=b, irq=10 > map[20]: type I/O Port, range 32, base 0x1840, size 5, enabled > pcib0: matched entry for 0.29.INTB > pcib0: slot 29 INTB hardwired to IRQ 19 > found-> vendor=0x8086, dev=0x27ca, revid=0x02 > bus=0, slot=29, func=2 > class=0c-03-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=c, irq=3 > map[20]: type I/O Port, range 32, base 0x1860, size 5, enabled > pcib0: matched entry for 0.29.INTC > pcib0: slot 29 INTC hardwired to IRQ 18 > found-> vendor=0x8086, dev=0x27cb, revid=0x02 > bus=0, slot=29, func=3 > class=0c-03-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=d, irq=11 > map[20]: type I/O Port, range 32, base 0x1880, size 5, enabled > pcib0: matched entry for 0.29.INTD > pcib0: slot 29 INTD hardwired to IRQ 16 > found-> vendor=0x8086, dev=0x27cc, revid=0x02 > bus=0, slot=29, func=7 > class=0c-03-20, hdrtype=0x00, mfdev=0 > cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=a, irq=7 > powerspec 2 supports D0 D3 current D0 > map[10]: type Memory, range 32, base 0xd8444000, size 10, enabled > pcib0: matched entry for 0.29.INTA > pcib0: slot 29 INTA hardwired to IRQ 23 > found-> vendor=0x8086, dev=0x2448, revid=0xe2 > bus=0, slot=30, func=0 > class=06-04-01, hdrtype=0x01, mfdev=0 > cmdreg=0x0004, statreg=0x0010, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > found-> vendor=0x8086, dev=0x27b9, revid=0x02 > bus=0, slot=31, func=0 > class=06-01-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0007, statreg=0x0210, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > found-> vendor=0x8086, dev=0x27df, revid=0x02 > bus=0, slot=31, func=1 > class=01-01-8a, hdrtype=0x00, mfdev=0 > cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=a, irq=255 > map[20]: type I/O Port, range 32, base 0x1810, size 4, enabled > found-> vendor=0x8086, dev=0x27c5, revid=0x02 > bus=0, slot=31, func=2 > class=01-06-01, hdrtype=0x00, mfdev=0 > cmdreg=0x0007, statreg=0x02b0, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=b, irq=4 > powerspec 2 supports D0 D3 current D0 > MSI supports 1 message > map[10]: type I/O Port, range 32, base 0x18d0, size 3, enabled > map[14]: type I/O Port, range 32, base 0x18c4, size 2, enabled > map[18]: type I/O Port, range 32, base 0x18c8, size 3, enabled > map[1c]: type I/O Port, range 32, base 0x18c0, size 2, enabled > map[20]: type I/O Port, range 32, base 0x18b0, size 4, enabled > map[24]: type Memory, range 32, base 0xd8444400, size 10, enabled > pcib0: matched entry for 0.31.INTB > pcib0: slot 31 INTB hardwired to IRQ 19 > found-> vendor=0x8086, dev=0x27da, revid=0x02 > bus=0, slot=31, func=3 > class=0c-05-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0001, statreg=0x0280, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=b, irq=4 > map[20]: type I/O Port, range 32, base 0x18e0, size 5, enabled > pcib0: matched entry for 0.31.INTB > pcib0: slot 31 INTB hardwired to IRQ 19 > vgapci0: port 0x1800-0x1807 mem 0xd8100000-0xd817ffff,0xc0000000-0xcfffffff,0xd8200000-0xd823ffff irq 16 at device 2.0 on pci0 > agp0: on vgapci0 > vgapci0: Reserved 0x10000000 bytes for rid 0x18 type 3 at 0xc0000000 > vgapci0: Reserved 0x80000 bytes for rid 0x10 type 3 at 0xd8100000 > vgapci0: Reserved 0x40000 bytes for rid 0x1c type 3 at 0xd8200000 > agp0: detected 7932k stolen memory > agp0: aperture size is 256M > vgapci1: mem 0xd8180000-0xd81fffff at device 2.1 on pci0 > pci0: at device 27.0 (no driver attached) > pcib1: irq 17 at device 28.0 on pci0 > pcib1: secondary bus 2 > pcib1: subordinate bus 2 > pcib1: I/O decode 0x2000-0x2fff > pcib1: memory decode 0xd6000000-0xd7ffffff > pcib1: prefetched decode 0xd2000000-0xd3ffffff > pci2: on pcib1 > pci2: physical bus=2 > found-> vendor=0x8086, dev=0x4222, revid=0x02 > bus=2, slot=0, func=0 > class=02-80-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0006, statreg=0x0010, cachelnsz=16 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=a, irq=11 > powerspec 2 supports D0 D3 current D0 > MSI supports 1 message, 64 bit > map[10]: type Memory, range 32, base 0xd6000000, size 12, enabled > pcib1: requested memory range 0xd6000000-0xd6000fff: good > pcib1: matched entry for 2.0.INTA > pcib1: slot 0 INTA hardwired to IRQ 16 > pci2: at device 0.0 (no driver attached) > pcib2: irq 16 at device 28.1 on pci0 > pcib2: secondary bus 3 > pcib2: subordinate bus 4 > pcib2: I/O decode 0x3000-0x3fff > pcib2: memory decode 0xd4000000-0xd5ffffff > pcib2: prefetched decode 0xd0000000-0xd1ffffff > pci3: on pcib2 > pci3: physical bus=3 > uhci0: port 0x1820-0x183f irq 23 at device 29.0 on pci0 > uhci0: Reserved 0x20 bytes for rid 0x20 type 4 at 0x1820 > ioapic0: routing intpin 23 (PCI IRQ 23) to vector 49 > uhci0: [GIANT-LOCKED] > uhci0: [ITHREAD] > usb0: on uhci0 > usb0: USB revision 1.0 > uhub0: on usb0 > uhub0: 2 ports with 2 removable, self powered > uhci1: port 0x1840-0x185f irq 19 at device 29.1 on pci0 > uhci1: Reserved 0x20 bytes for rid 0x20 type 4 at 0x1840 > ioapic0: routing intpin 19 (PCI IRQ 19) to vector 50 > uhci1: [GIANT-LOCKED] > uhci1: [ITHREAD] > usb1: on uhci1 > usb1: USB revision 1.0 > uhub1: on usb1 > uhub1: 2 ports with 2 removable, self powered > uhci2: port 0x1860-0x187f irq 18 at device 29.2 on pci0 > uhci2: Reserved 0x20 bytes for rid 0x20 type 4 at 0x1860 > ioapic0: routing intpin 18 (PCI IRQ 18) to vector 51 > uhci2: [GIANT-LOCKED] > uhci2: [ITHREAD] > usb2: on uhci2 > usb2: USB revision 1.0 > uhub2: on usb2 > uhub2: 2 ports with 2 removable, self powered > uhci3: port 0x1880-0x189f irq 16 at device 29.3 on pci0 > uhci3: Reserved 0x20 bytes for rid 0x20 type 4 at 0x1880 > ioapic0: routing intpin 16 (PCI IRQ 16) to vector 52 > uhci3: [GIANT-LOCKED] > uhci3: [ITHREAD] > usb3: on uhci3 > usb3: USB revision 1.0 > uhub3: on usb3 > uhub3: 2 ports with 2 removable, self powered > ehci0: mem 0xd8444000-0xd84443ff irq 23 at device 29.7 on pci0 > ehci0: Reserved 0x400 bytes for rid 0x10 type 3 at 0xd8444000 > ehci0: [GIANT-LOCKED] > ehci0: [ITHREAD] > usb4: EHCI version 1.0 > usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 > usb4: on ehci0 > usb4: USB revision 2.0 > uhub4: on usb4 > uhub4: 8 ports with 8 removable, self powered > ugen0: on uhub4 > pcib3: at device 30.0 on pci0 > pcib3: secondary bus 5 > pcib3: subordinate bus 5 > pcib3: I/O decode 0x0-0x0 > pcib3: no prefetched decode > pcib3: Subtractively decoded bridge. > pci5: on pcib3 > pci5: physical bus=5 > found-> vendor=0x1180, dev=0x0832, revid=0x00 > bus=5, slot=5, func=0 > class=0c-00-10, hdrtype=0x00, mfdev=1 > cmdreg=0x0006, statreg=0x0210, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x04 (1000 ns) > intpin=a, irq=11 > powerspec 2 supports D0 D1 D2 D3 current D0 > map[10]: type Memory, range 32, base 0xd8001000, size 11, enabled > pcib3: requested memory range 0xd8001000-0xd80017ff: good > pcib3: matched entry for 5.5.INTA > pcib3: slot 5 INTA hardwired to IRQ 16 > found-> vendor=0x1180, dev=0x0822, revid=0x19 > bus=5, slot=5, func=1 > class=08-05-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0000, statreg=0x0210, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=b, irq=3 > powerspec 2 supports D0 D1 D2 D3 current D0 > map[10]: type Memory, range 32, base 0xd8001800, size 8, memory disabled > pcib3: requested memory range 0xd8001800-0xd80018ff: good > pcib3: matched entry for 5.5.INTB > pcib3: slot 5 INTB hardwired to IRQ 17 > found-> vendor=0x1180, dev=0x0843, revid=0x01 > bus=5, slot=5, func=2 > class=08-80-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0000, statreg=0x0210, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=b, irq=3 > powerspec 2 supports D0 D1 D2 D3 current D0 > map[10]: type Memory, range 32, base 0xd8001c00, size 8, memory disabled > pcib3: requested memory range 0xd8001c00-0xd8001cff: good > pcib3: matched entry for 5.5.INTB > pcib3: slot 5 INTB hardwired to IRQ 17 > found-> vendor=0x1180, dev=0x0592, revid=0x0a > bus=5, slot=5, func=3 > class=08-80-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0000, statreg=0x0210, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=b, irq=3 > powerspec 2 supports D0 D1 D2 D3 current D0 > map[10]: type Memory, range 32, base 0xd8002000, size 8, memory disabled > pcib3: requested memory range 0xd8002000-0xd80020ff: good > pcib3: matched entry for 5.5.INTB > pcib3: slot 5 INTB hardwired to IRQ 17 > found-> vendor=0x1180, dev=0x0852, revid=0x05 > bus=5, slot=5, func=4 > class=08-80-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0000, statreg=0x0210, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=b, irq=3 > powerspec 2 supports D0 D1 D2 D3 current D0 > map[10]: type Memory, range 32, base 0xd8002400, size 8, memory disabled > pcib3: requested memory range 0xd8002400-0xd80024ff: good > pcib3: matched entry for 5.5.INTB > pcib3: slot 5 INTB hardwired to IRQ 17 > found-> vendor=0x8086, dev=0x1092, revid=0x02 > bus=5, slot=8, func=0 > class=02-00-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0003, statreg=0x0290, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x08 (2000 ns), maxlat=0x38 (14000 ns) > intpin=a, irq=10 > powerspec 2 supports D0 D1 D2 D3 current D0 > map[10]: type Memory, range 32, base 0xd8000000, size 12, enabled > pcib3: requested memory range 0xd8000000-0xd8000fff: good > map[14]: type I/O Port, range 32, base 0x4000, size 6, enabled > pcib3: matched entry for 5.8.INTA > pcib3: slot 8 INTA hardwired to IRQ 20 > fwohci0: vendor=1180, dev=832 > fwohci0: vendor=1180, dev=832 > fwohci0: <1394 Open Host Controller Interface> mem 0xd8001000-0xd80017ff irq 16 at device 5.0 on pci5 > fwohci0: Reserved 0x800 bytes for rid 0x10 type 3 at 0xd8001000 > fwohci0: [MPSAFE] > fwohci0: [FILTER] > fwohci0: OHCI version 1.10 (ROM=0) > fwohci0: No. of Isochronous channels is 4. > fwohci0: EUI64 00:24:1b:00:bb:30:23:00 > fwohci0: Phy 1394a available S400, 1 ports. > fwohci0: Link S400, max_rec 2048 bytes. > firewire0: on fwohci0 > fwe0: on firewire0 > if_fwe0: Fake Ethernet address: 02:24:1b:30:23:00 > fwe0: bpf attached > fwe0: Ethernet address: 02:24:1b:30:23:00 > fwip0: on firewire0 > fwip0: bpf attached > fwip0: Firewire address: 00:24:1b:00:bb:30:23:00 @ 0xfffe00000000, S400, maxrec 2048 > sbp0: on firewire0 > dcons_crom0: on firewire0 > dcons_crom0: bus_addr 0x7d0c0000 > fwohci0: Initiate bus reset > fwohci0: BUS reset > fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode > pci5: at device 5.1 (no driver attached) > pci5: at device 5.2 (no driver attached) > pci5: at device 5.3 (no driver attached) > pci5: at device 5.4 (no driver attached) > fxp0: port 0x4000-0x403f mem 0xd8000000-0xd8000fff irq 20 at device 8.0 on pci5 > fxp0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xd8000000 > fxp0: using memory space register mapping > fxp0: PCI IDs: 8086 1092 103c 30bb 0002 > fxp0: Dynamic Standby mode is enabled > miibus0: on fxp0 > inphy0: PHY 1 on miibus0 > inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > fxp0: bpf attached > fxp0: Ethernet address: 00:1b:24:49:da:97 > ioapic0: routing intpin 20 (PCI IRQ 20) to vector 53 > fxp0: [MPSAFE] > fxp0: [ITHREAD] > isab0: at device 31.0 on pci0 > isa0: on isab0 > atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1810-0x181f at device 31.1 on pci0 > atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0x1810 > ata0: on atapci0 > atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 > atapci0: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 > ata0: reset tp1 mask=03 ostat0=50 ostat1=00 > ata0: stat0=0x00 err=0x01 lsb=0x14 msb=0xeb > ata0: stat1=0x00 err=0x00 lsb=0x00 msb=0x00 > ata0: reset tp2 stat0=00 stat1=00 devices=0x4 > ioapic0: routing intpin 14 (ISA IRQ 14) to vector 54 > ata0: [MPSAFE] > ata0: [ITHREAD] > ata1: on atapci0 > atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170 > atapci0: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376 > ata1: reset tp1 mask=00 ostat0=ff ostat1=ff > ioapic0: routing intpin 15 (ISA IRQ 15) to vector 55 > ata1: [MPSAFE] > ata1: [ITHREAD] > atapci1: port 0x18d0-0x18d7,0x18c4-0x18c7,0x18c8-0x18cf,0x18c0-0x18c3,0x18b0-0x18bf mem 0xd8444400-0xd84447ff irq 19 at device 31.2 on pci0 > atapci1: Reserved 0x10 bytes for rid 0x20 type 4 at 0x18b0 > atapci1: [MPSAFE] > atapci1: [ITHREAD] > atapci1: Reserved 0x400 bytes for rid 0x24 type 3 at 0xd8444400 > atapci1: AHCI Version 01.10 controller with 4 ports detected > ata2: on atapci1 > ata2: SATA connect time=0ms > ata2: [MPSAFE] > ata2: [ITHREAD] > ata3: on atapci1 > ata3: port not implemented > ata3: [MPSAFE] > ata3: [ITHREAD] > ata4: on atapci1 > ata4: SATA connect status=00000000 > ata4: [MPSAFE] > ata4: [ITHREAD] > ata5: on atapci1 > ata5: port not implemented > ata5: [MPSAFE] > ata5: [ITHREAD] > pci0: at device 31.3 (no driver attached) > acpi_tz0: on acpi0 > atkbdc0: port 0x60,0x64 irq 1 on acpi0 > atkbd0: irq 1 on atkbdc0 > atkbd: the current kbd controller command byte 0047 > atkbd: keyboard ID 0x41ab (2) > kbd0 at atkbd0 > kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 > ioapic0: routing intpin 1 (ISA IRQ 1) to vector 56 > atkbd0: [GIANT-LOCKED] > atkbd0: [ITHREAD] > psm0: unable to allocate IRQ > psmcpnp0: irq 12 on acpi0 > psm0: current command byte:0047 > psm0: irq 12 on atkbdc0 > ioapic0: routing intpin 12 (ISA IRQ 12) to vector 57 > psm0: [GIANT-LOCKED] > psm0: [ITHREAD] > psm0: model IntelliMouse, device ID 3-00, 3 buttons > psm0: config:00000000, flags:00000008, packet size:4 > psm0: syncmask:08, syncbits:00 > unknown: status reg test failed ff > unknown: status reg test failed ff > unknown: status reg test failed ff > unknown: status reg test failed ff > unknown: status reg test failed ff > unknown: status reg test failed ff > ex_isa_identify() > ata: ata0 already exists; skipping it > ata: ata1 already exists; skipping it > atkbdc: atkbdc0 already exists; skipping it > pnp_identify: Trying Read_Port at 203 > pnp_identify: Trying Read_Port at 243 > pnp_identify: Trying Read_Port at 283 > pnp_identify: Trying Read_Port at 2c3 > pnp_identify: Trying Read_Port at 303 > pnp_identify: Trying Read_Port at 343 > pnp_identify: Trying Read_Port at 383 > pnp_identify: Trying Read_Port at 3c3 > PNP Identify complete > sc: sc0 already exists; skipping it > vga: vga0 already exists; skipping it > isa_probe_children: disabling PnP devices > isa_probe_children: probing non-PnP devices > pmtimer0 on isa0 > orm0: at iomem 0xce800-0xcffff,0xdf000-0xdf7ff,0xe0000-0xe17ff pnpid ORM0000 on isa0 > adv0: not probed (disabled) > aha0: not probed (disabled) > aic0: not probed (disabled) > bt0: not probed (disabled) > cs0: not probed (disabled) > ed0: not probed (disabled) > fdc0 failed to probe at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 > fe0: not probed (disabled) > ie0: not probed (disabled) > le0: not probed (disabled) > ppc0: parallel port not found. > ppc0: failed to probe at irq 7 on isa0 > sc0: at flags 0x100 on isa0 > sc0: VGA <16 virtual consoles, flags=0x300> > sc0: fb0, kbd1, terminal emulator: sc (syscons terminal) > sio0: configured irq 4 not in bitmap of probed irqs 0 > sio0: port may not be enabled > sio0: irq maps: 0xeb9 0xeb9 0xeb9 0xeb9 > sio0: probe failed test(s): 0 1 2 4 6 7 9 > sio0: configured irq 4 not in bitmap of probed irqs 0 > sio0: port may not be enabled > sio0: irq maps: 0xeb9 0xeb9 0xeb9 0xeb9 > sio0: probe failed test(s): 0 1 2 4 6 7 9 > sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 > sio0: type 8250 or not responding > ioapic0: routing intpin 4 (ISA IRQ 4) to vector 58 > sio0: [FILTER] > sio1: configured irq 3 not in bitmap of probed irqs 0 > sio1: port may not be enabled > sio1: irq maps: 0xeb9 0xeb9 0xeb9 0xeb9 > sio1: probe failed test(s): 0 1 2 4 6 7 9 > sio1 failed to probe at port 0x2f8-0x2ff irq 3 on isa0 > sio2: not probed (disabled) > sio3: not probed (disabled) > sn0: not probed (disabled) > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > vt0: not probed (disabled) > isa_probe_children: probing PnP devices > Device configuration finished. > Reducing kern.maxvnodes 133508 -> 100000 > procfs registered > lapic: Divisor 2, Frequency 66520468 hz > Timecounter "TSC" frequency 1995613575 Hz quality -100 > Timecounters tick every 1.000 msec > lo0: bpf attached > rr232x: no controller detected. > firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) > firewire0: bus manager 0 (me) > ata0-master: pio=PIO4 wdma=WDMA2 udma=UNSUPPORTED cable=40 wire > acd0: setting PIO4 on ICH7 chip > acpi_acad0: acline initialization start > acpi_acad0: On Line > acpi_acad0: acline initialization done, tried 1 times > battery0: battery initialization start > acd0: DVDR drive at ata0 as master > acd0: read 4134KB/s (4134KB/s) write 4134KB/s (4134KB/s), 2048KB buffer, PIO4 > acd0: Reads: CDR, CDRW, CDDA stream, DVDROM, DVDR, DVDRAM, packet > acd0: Writes: CDR, CDRW, DVDR, DVDRAM, test write, burnproof > acd0: Audio: play, 256 volume levels > acd0: Mechanism: ejectable tray, unlocked > acd0: Medium: no/blank disc > ata2-master: pio=PIO4 wdma=WDMA2 udma=UDMA100 cable=40 wire > ad4: 152627MB at ata2-master SATA150 > ad4: 312581808 sectors [310101C/16H/63S] 16 sectors/interrupt 1 depth queue > GEOM: new disk ad4 > battery0: battery initialization done, tried 1 times > ad4: Intel check1 failed > ad4: Adaptec check1 failed > ad4: LSI (v3) check1 failed > ad4: LSI (v2) check1 failed > ad4: FreeBSD check1 failed > (probe0:sbp0:0:0:0): error 22 > (probe0:sbp0:0:0:0): Unretryable Error > (probe1:sbp0:0:1:0): error 22 > (probe1:sbp0:0:1:0): Unretryable Error > (probe2:sbp0:0:2:0): error 22 > (probe2:sbp0:0:2:0): Unretryable Error > (probe3:sbp0:0:3:0): error 22 > (probe3:sbp0:0:3:0): Unretryable Error > (probe4:sbp0:0:4:0): error 22 > (probe4:sbp0:0:4:0): Unretryable Error > (probe5:sbp0:0:5:0): error 22 > (probe5:sbp0:0:5:0): Unretryable Error > (probe6:sbp0:0:6:0): error 22 > (probe6:sbp0:0:6:0): Unretryable Error > ATA PseudoRAID loaded > SMP: AP CPU #1 Launched! > cpu1 AP: > ID: 0x01000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff > lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff > timer: 0x000200ef therm: 0x00010200 err: 0x00010000 pcm: 0x00010000 > ioapic0: Assigning ISA IRQ 1 to local APIC 0 > ioapic0: Assigning ISA IRQ 4 to local APIC 1 > ioapic0: Assigning ISA IRQ 9 to local APIC 0 > ioapic0: Assigning ISA IRQ 12 to local APIC 1 > ioapic0: Assigning ISA IRQ 14 to local APIC 0 > ioapic0: Assigning ISA IRQ 15 to local APIC 1 > ioapic0: Assigning PCI IRQ 16 to local APIC 0 > ioapic0: Assigning PCI IRQ 18 to local APIC 1 > ioapic0: Assigning PCI IRQ 19 to local APIC 0 > ioapic0: Assigning PCI IRQ 20 to local APIC 1 > ioapic0: Assigning PCI IRQ 23 to local APIC 0 > WARNING: WITNESS option enabled, expect reduced performance. > Trying to mount root from ufs:/dev/ad4s1a > start_init: trying /sbin/init > Linux ELF exec handler installed > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" I don't know if this is going to help but I've had similar issues some time ago, I think the bios i faking this serial port because of docking station support. On my IBM it was additional IDE channel, not a serial port that was detected, but disabling docking support with one awkward dos utility fixed the problem. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG4tM6HNAJ/fLbfrkRAhJsAJ9oJFrUvmTktTCqnYAPXGopSnsobACdF+J7 8EozYxUybJytrzWvY/5kG0Y= =G9SQ -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Sat Sep 8 21:23:40 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6C05D16A418 for ; Sat, 8 Sep 2007 21:23:40 +0000 (UTC) (envelope-from almarrie@gmail.com) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.187]) by mx1.freebsd.org (Postfix) with ESMTP id E278F13C458 for ; Sat, 8 Sep 2007 21:23:39 +0000 (UTC) (envelope-from almarrie@gmail.com) Received: by fk-out-0910.google.com with SMTP id b27so947225fka for ; Sat, 08 Sep 2007 14:23:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=l0yfcCvBkY62kaWqKXyDj5EBqY8cRiZn+vtJDPyY4vU=; b=p/WUGJH9iUFkBFPe4mJ0lReXioL2khXo0MUftof5vTOnorR+ddFME6uPMrgH5B5SVEv2qxdfXBVEx6GL+koW2L605D0VpM2DuC9H7AuKAl0aHPSEwF0cVfJBrDejbh+M7cHyZUht5OQTkdxHO/7xuXLFhMUN4U27Q+uc7dg1NXQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=idt5LkMIZGU8qhUKISRvuMOGpyuZWZWvXGV1NPFWANydaXhepHOz05IahEybZUQqQrSM4SrR4jH5YezrHfQIkEJ3e2dtHEIC3rIas05DyBjuCJdbiUXl4sMbJoSoLeN8Ks3bD8MHqlYn3LYPZyTMV/9bbF78RAM4o8lLrtoCFhY= Received: by 10.86.23.17 with SMTP id 17mr2458906fgw.1189286618740; Sat, 08 Sep 2007 14:23:38 -0700 (PDT) Received: by 10.86.2.1 with HTTP; Sat, 8 Sep 2007 14:23:38 -0700 (PDT) Message-ID: <499c70c0709081423m584a052en32e479c9bc248da2@mail.gmail.com> Date: Sun, 9 Sep 2007 00:23:38 +0300 From: "Abdullah Ibn Hamad Al-Marri" To: "Ivan Voras" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: Progress for 7.0 - the "what's cooking" page X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Sep 2007 21:23:40 -0000 On 9/4/07, Ivan Voras wrote: > Hi, > > As some of you may know, I'm maintaining a web page which aims to > enumerate and describe major new features for FreeBSD 7, located at > http://ivoras.sharanet.org/freebsd/freebsd7.html . Hello, I just need to know if this is still the state for SCHED_ULE or not in the your page. "ULE will not be enabled by default for 7.0 but it's an officially recommended performance optimization." If not is it going to be in the FreeBSD 7.1? -- Regards, -Abdullah Ibn Hamad Al-Marri Arab Portal http://www.WeArab.Net/ From owner-freebsd-current@FreeBSD.ORG Sat Sep 8 21:51:04 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9DA0416A417; Sat, 8 Sep 2007 21:51:04 +0000 (UTC) (envelope-from scode@hyperion.scode.org) Received: from hyperion.scode.org (cl-1361.ams-04.nl.sixxs.net [IPv6:2001:960:2:550::2]) by mx1.freebsd.org (Postfix) with ESMTP id 50F5313C458; Sat, 8 Sep 2007 21:51:04 +0000 (UTC) (envelope-from scode@hyperion.scode.org) Received: by hyperion.scode.org (Postfix, from userid 1001) id 39C4223C46D; Sat, 8 Sep 2007 23:51:03 +0200 (CEST) Date: Sat, 8 Sep 2007 23:51:03 +0200 From: Peter Schuller To: Simun Mikecin Message-ID: <20070908215102.GA8291@hyperion.scode.org> References: <855622.76488.qm@web36601.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tThc/1wpZn/ma/RB" Content-Disposition: inline In-Reply-To: <855622.76488.qm@web36601.mail.mud.yahoo.com> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: Swapping on ZFS - stability issue X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Sep 2007 21:51:04 -0000 --tThc/1wpZn/ma/RB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > Try one of this (depends wheter you need encrypted swap or not): >=20 > 1. create zvol with 4k blocksize instead of default 8k: > zfs create -b 4k -V 4g tank/swap > swapon /dev/zvol/tank/swap Using a 4k blocksize did not seem to have an effect on the problem. The test I am doing is with top in one virtual console and the test program on another. I keep refreshing top seeing memory use climb, until it starts hitting swap. After a few seconds, top hangs and the only indications of life are ping and the console. --=20 / Peter Schuller PGP userID: 0xE9758B7D or 'Peter Schuller ' Key retrieval: Send an E-Mail to getpgpkey@scode.org E-Mail: peter.schuller@infidyne.com Web: http://www.scode.org --tThc/1wpZn/ma/RB Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD4DBQFG4xlGDNor2+l1i30RAnqMAJ9Kmwt+OMBIgh8HDSWRQzyqOvXCJgCY4pfa CFATcOuiutKhY4P+CcSoEw== =/ntz -----END PGP SIGNATURE----- --tThc/1wpZn/ma/RB--