From owner-freebsd-stable@FreeBSD.ORG Sun May 3 00:03:09 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B75B9106564A for ; Sun, 3 May 2009 00:03:09 +0000 (UTC) (envelope-from artemb@gmail.com) Received: from mail-gx0-f167.google.com (mail-gx0-f167.google.com [209.85.217.167]) by mx1.freebsd.org (Postfix) with ESMTP id 6A54F8FC1B for ; Sun, 3 May 2009 00:03:09 +0000 (UTC) (envelope-from artemb@gmail.com) Received: by gxk11 with SMTP id 11so2278053gxk.19 for ; Sat, 02 May 2009 17:03:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=hKEJMgvEq0npJhKRV0cIgujKAZohT6UrXf00prABKwI=; b=b3a4EWGStkiy3hpxRhaOWwhYKbQGuHlyxrpoW6lpJ0EB1VmXuHK3qbGDlmPt9JiImw mYO85GZMl/DuEEdTweHuBz7hD+/DbLkQoDZMrd/O1azd24tcDxxi4OW8JkPLvlD7hFSf Vstyk5CEYsbduQKktgr84hxQ3xJMB35gw9kbI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=f8Vqk+hW0u1Ryrag2lUaXZCsamkJxBw4pOFZTUPG/Hryi3jn2Ha4iWUNDQ4wySxwVQ SzY8SyZceCZGfvcqj6GguyjXYe9YsQJyCyD4QOcqrC3kh/XxZhMe0YsazDjLa09L23RH sBwSWyD/5c5HIQmiy/1mFxGEZ5JvX1jXMQ/Lc= MIME-Version: 1.0 Sender: artemb@gmail.com Received: by 10.90.72.3 with SMTP id u3mr1217630aga.87.1241307295852; Sat, 02 May 2009 16:34:55 -0700 (PDT) In-Reply-To: References: <32A0BDD9-ACF8-43F4-8D2C-0FC151F1D7CB@cryptomonkeys.org> Date: Sat, 2 May 2009 16:34:55 -0700 X-Google-Sender-Auth: dbc3ba7f15c67408 Message-ID: From: Artem Belevich To: Freddie Cash Content-Type: multipart/mixed; boundary=00163630f1d76d29ad0468f660ce Cc: FreeBSD Stable Subject: Re: current zfs tuning in RELENG_7 (AMD64) suggestions ? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 May 2009 00:03:10 -0000 --00163630f1d76d29ad0468f660ce Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable >> This information is outdated.=A0 The current max in RELENG_7 for amd64 i= s >> ~3.75GB. Technically, RELENG_7 should allow kmem_size of up to 6G, but the sysctl variables used for tuning are 32-bit and *that* limits kmem_size to ~4G. It's been fixed in -current and can easily be fixed in RELENG_7 (if it's not fixedyet). As far as I can tell, all necessary code to support large kmem_size is already in RELENG_7. It's easy enough to allow even larger kmem_size. See attached diff that I'm using. With that diff you can set vm.kmem_size to ~16G. --Artem --00163630f1d76d29ad0468f660ce Content-Type: application/octet-stream; name="vm-large.diff" Content-Disposition: attachment; filename="vm-large.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_fu8y00c00 ZGlmZiAtciBiYmVlNDdiMjhmN2YgYW1kNjQvaW5jbHVkZS92bXBhcmFtLmgKLS0tIGEvYW1kNjQv aW5jbHVkZS92bXBhcmFtLmgJU2F0IEphbiAzMSAyMTowMzo1MyAyMDA5IC0wODAwCisrKyBiL2Ft ZDY0L2luY2x1ZGUvdm1wYXJhbS5oCVNhdCBNYXkgMDIgMTY6MjU6NDIgMjAwOSAtMDcwMApAQCAt MTQ5LDcgKzE0OSw3IEBACiAgKi8KIAogI2RlZmluZQlWTV9NQVhfS0VSTkVMX0FERFJFU1MJS1ZB RERSKEtQTUw0SSwgTlBEUEVQRy0xLCBOUERFUEctMSwgTlBURVBHLTEpCi0jZGVmaW5lCVZNX01J Tl9LRVJORUxfQUREUkVTUwlLVkFERFIoS1BNTDRJLCBOUERQRVBHLTYsIDAsIDApCisjZGVmaW5l CVZNX01JTl9LRVJORUxfQUREUkVTUwlLVkFERFIoS1BNTDRJLCBOUERQRVBHLTE2LCAwLCAwKQog CiAjZGVmaW5lCURNQVBfTUlOX0FERFJFU1MJS1ZBRERSKERNUE1MNEksIDAsIDAsIDApCiAjZGVm aW5lCURNQVBfTUFYX0FERFJFU1MJS1ZBRERSKERNUE1MNEkrMSwgMCwgMCwgMCkKZGlmZiAtciBi YmVlNDdiMjhmN2Yga2Vybi9rZXJuX21hbGxvYy5jCi0tLSBhL2tlcm4va2Vybl9tYWxsb2MuYwlT YXQgSmFuIDMxIDIxOjAzOjUzIDIwMDkgLTA4MDAKKysrIGIva2Vybi9rZXJuX21hbGxvYy5jCVNh dCBNYXkgMDIgMTY6MjU6NDIgMjAwOSAtMDcwMApAQCAtMTgxLDE2ICsxODEsMTYgQEAKICAqLwog c3RhdGljIHVtYV96b25lX3QgbXRfem9uZTsKIAotdV9pbnQgdm1fa21lbV9zaXplOwotU1lTQ1RM X1VJTlQoX3ZtLCBPSURfQVVUTywga21lbV9zaXplLCBDVExGTEFHX1JELCAmdm1fa21lbV9zaXpl LCAwLAordV9sb25nIHZtX2ttZW1fc2l6ZTsKK1NZU0NUTF9VTE9ORyhfdm0sIE9JRF9BVVRPLCBr bWVtX3NpemUsIENUTEZMQUdfUkQsICZ2bV9rbWVtX3NpemUsIDAsCiAgICAgIlNpemUgb2Yga2Vy bmVsIG1lbW9yeSIpOwogCi11X2ludCB2bV9rbWVtX3NpemVfbWluOwotU1lTQ1RMX1VJTlQoX3Zt LCBPSURfQVVUTywga21lbV9zaXplX21pbiwgQ1RMRkxBR19SRCwgJnZtX2ttZW1fc2l6ZV9taW4s IDAsCit1X2xvbmcgdm1fa21lbV9zaXplX21pbjsKK1NZU0NUTF9VTE9ORyhfdm0sIE9JRF9BVVRP LCBrbWVtX3NpemVfbWluLCBDVExGTEFHX1JELCAmdm1fa21lbV9zaXplX21pbiwgMCwKICAgICAi TWluaW11bSBzaXplIG9mIGtlcm5lbCBtZW1vcnkiKTsKIAotdV9pbnQgdm1fa21lbV9zaXplX21h eDsKLVNZU0NUTF9VSU5UKF92bSwgT0lEX0FVVE8sIGttZW1fc2l6ZV9tYXgsIENUTEZMQUdfUkQs ICZ2bV9rbWVtX3NpemVfbWF4LCAwLAordV9sb25nIHZtX2ttZW1fc2l6ZV9tYXg7CitTWVNDVExf VUxPTkcoX3ZtLCBPSURfQVVUTywga21lbV9zaXplX21heCwgQ1RMRkxBR19SRCwgJnZtX2ttZW1f c2l6ZV9tYXgsIDAsCiAgICAgIk1heGltdW0gc2l6ZSBvZiBrZXJuZWwgbWVtb3J5Iik7CiAKIHVf aW50IHZtX2ttZW1fc2l6ZV9zY2FsZTsKQEAgLTU4OSw3ICs1ODksNyBAQAogI2lmIGRlZmluZWQo Vk1fS01FTV9TSVpFX01JTikKIAl2bV9rbWVtX3NpemVfbWluID0gVk1fS01FTV9TSVpFX01JTjsK ICNlbmRpZgotCVRVTkFCTEVfSU5UX0ZFVENIKCJ2bS5rbWVtX3NpemVfbWluIiwgJnZtX2ttZW1f c2l6ZV9taW4pOworCVRVTkFCTEVfVUxPTkdfRkVUQ0goInZtLmttZW1fc2l6ZV9taW4iLCAmdm1f a21lbV9zaXplX21pbik7CiAJaWYgKHZtX2ttZW1fc2l6ZV9taW4gPiAwICYmIHZtX2ttZW1fc2l6 ZSA8IHZtX2ttZW1fc2l6ZV9taW4pIHsKIAkJdm1fa21lbV9zaXplID0gdm1fa21lbV9zaXplX21p bjsKIAl9CkBAIC01OTcsMTcgKzU5NywxOSBAQAogI2lmIGRlZmluZWQoVk1fS01FTV9TSVpFX01B WCkKIAl2bV9rbWVtX3NpemVfbWF4ID0gVk1fS01FTV9TSVpFX01BWDsKICNlbmRpZgotCVRVTkFC TEVfSU5UX0ZFVENIKCJ2bS5rbWVtX3NpemVfbWF4IiwgJnZtX2ttZW1fc2l6ZV9tYXgpOworCVRV TkFCTEVfVUxPTkdfRkVUQ0goInZtLmttZW1fc2l6ZV9tYXgiLCAmdm1fa21lbV9zaXplX21heCk7 CiAJaWYgKHZtX2ttZW1fc2l6ZV9tYXggPiAwICYmIHZtX2ttZW1fc2l6ZSA+PSB2bV9rbWVtX3Np emVfbWF4KQogCQl2bV9rbWVtX3NpemUgPSB2bV9rbWVtX3NpemVfbWF4OwogCiAJLyogQWxsb3cg ZmluYWwgb3ZlcnJpZGUgZnJvbSB0aGUga2VybmVsIGVudmlyb25tZW50ICovCiAjaWZuZGVmIEJV Uk5fQlJJREdFUwotCWlmIChUVU5BQkxFX0lOVF9GRVRDSCgia2Vybi52bS5rbWVtLnNpemUiLCAm dm1fa21lbV9zaXplKSAhPSAwKQorCWlmIChUVU5BQkxFX1VMT05HX0ZFVENIKCJrZXJuLnZtLmtt ZW0uc2l6ZSIsICZ2bV9rbWVtX3NpemUpICE9IDApCiAJCXByaW50Zigia2Vybi52bS5rbWVtLnNp emUgaXMgbm93IGNhbGxlZCB2bS5rbWVtX3NpemUhXG4iKTsKICNlbmRpZgotCVRVTkFCTEVfSU5U X0ZFVENIKCJ2bS5rbWVtX3NpemUiLCAmdm1fa21lbV9zaXplKTsKKwlUVU5BQkxFX1VMT05HX0ZF VENIKCJ2bS5rbWVtX3NpemUiLCAmdm1fa21lbV9zaXplKTsKIAorI2lmIDAgIC8qIGRvbid0IGVu Zm9yY2Uga21lbSBzaXplIGxpbWl0ICovCisJCiAJLyoKIAkgKiBMaW1pdCBrbWVtIHZpcnR1YWwg c2l6ZSB0byB0d2ljZSB0aGUgcGh5c2ljYWwgbWVtb3J5LgogCSAqIFRoaXMgYWxsb3dzIGZvciBr bWVtIG1hcCBzcGFyc2VuZXNzLCBidXQgbGltaXRzIHRoZSBzaXplCkBAIC02MTYsNyArNjE4LDgg QEAKIAkgKi8KIAlpZiAoKCh2bV9rbWVtX3NpemUgLyAyKSAvIFBBR0VfU0laRSkgPiBjbnQudl9w YWdlX2NvdW50KQogCQl2bV9rbWVtX3NpemUgPSAyICogY250LnZfcGFnZV9jb3VudCAqIFBBR0Vf U0laRTsKLQorI2VuZGlmCisJCiAJLyoKIAkgKiBUdW5lIHNldHRpbmdzIGJhc2VkIG9uIHRoZSBr bWVtIG1hcCdzIHNpemUgYXQgdGhpcyB0aW1lLgogCSAqLwpkaWZmIC1yIGJiZWU0N2IyOGY3ZiB2 bS92bV9rZXJuLmgKLS0tIGEvdm0vdm1fa2Vybi5oCVNhdCBKYW4gMzEgMjE6MDM6NTMgMjAwOSAt MDgwMAorKysgYi92bS92bV9rZXJuLmgJU2F0IE1heSAwMiAxNjoyNTo0MiAyMDA5IC0wNzAwCkBA IC02OSw2ICs2OSw2IEBACiBleHRlcm4gdm1fbWFwX3Qga21lbV9tYXA7CiBleHRlcm4gdm1fbWFw X3QgZXhlY19tYXA7CiBleHRlcm4gdm1fbWFwX3QgcGlwZV9tYXA7Ci1leHRlcm4gdV9pbnQgdm1f a21lbV9zaXplOworZXh0ZXJuIHVfbG9uZyB2bV9rbWVtX3NpemU7CiAKICNlbmRpZgkJCQkvKiBf Vk1fVk1fS0VSTl9IXyAqLwo= --00163630f1d76d29ad0468f660ce-- From owner-freebsd-stable@FreeBSD.ORG Sun May 3 02:05:01 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3F8F7106566B for ; Sun, 3 May 2009 02:05:01 +0000 (UTC) (envelope-from i.am.spaz.man@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.28]) by mx1.freebsd.org (Postfix) with ESMTP id D8DCA8FC18 for ; Sun, 3 May 2009 02:05:00 +0000 (UTC) (envelope-from i.am.spaz.man@gmail.com) Received: by yw-out-2324.google.com with SMTP id 9so1939766ywe.13 for ; Sat, 02 May 2009 19:05:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=80WLeUhQ3bcGeaeEepHGig/33CvdbR0xJUZw3SP3sEY=; b=cq7sHKprbz0GNl/Nl094oxNG4J8jsfl73wbarE1fz08NXm+Ks8EPa0STm3FyrFy2v1 wfkGR3GGj6McQCUuNkRZa5HOmxCpuu0rfgvFNt7JuPi2laa4SW9tTOsVDiCeBJrdGaBX zWp+A/X4jG7tSfWwhk2M0QqlsXxndMklvFiS8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:cc:subject:references :in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=AegBGPMoYw2YPre/XdwppUXO9ngzYMhoG4Iy+YfdH+On+NAtlLSulaOG4BDbQMxXYU 5ATuZISM9lyuROQ0Lvb8K37/FRr06/Dt0nILnn3s7bhmH4oHq1e975fPEDZhPdXaT1Y+ U99gsX60ys3PjjxRrprUIoFwqlubCroXWrp3k= Received: by 10.151.75.11 with SMTP id c11mr8792231ybl.197.1241314876044; Sat, 02 May 2009 18:41:16 -0700 (PDT) Received: from cyclone.whotookspaz.org (c-67-191-105-130.hsd1.fl.comcast.net [67.191.105.130]) by mx.google.com with ESMTPS id 6sm12603485ywp.4.2009.05.02.18.41.14 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 02 May 2009 18:41:15 -0700 (PDT) Message-ID: <49FCF638.8070604@gmail.com> Date: Sat, 02 May 2009 21:41:12 -0400 From: Jacob Myers User-Agent: Thunderbird 2.0.0.21 (X11/20090319) MIME-Version: 1.0 CC: FreeBSD-STABLE Mailing List References: <1234522194.13304.34.camel@horst-tla> In-Reply-To: <1234522194.13304.34.camel@horst-tla> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: [7-STABLE] failure during buildworld X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 May 2009 02:05:01 -0000 Horst GĂźnther Burkhardt III wrote: > Hey everybody :) > > I'm having a small issue compiling 7-STABLE... during make buildworld, this error > occurs: > > ===> gnu/lib/libstdc++ (depend) > ln -sf /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/config/cpu/generic/atomicity_mutex/atomicity.h atomicity.cc > ln -sf /usr/src/gnu/lib/libstdc++/../../../contrib/gcc/unwind-generic.h unwind.h > rm -f .depend > mkdep -f .depend -a -DIN_GLIBCPP_V3 -DHAVE_CONFIG_H -I/usr/src/gnu/lib/libstdc++ -I/usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++ -I/usr/src/gnu/lib/libstdc++/../../../contrib/gcc -I/usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/include -I/usr/src/gnu/lib/libstdc++/../../../contrib/gcclibs/include -I/usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/include -I. /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libmath/stubs.c /usr/src/gnu/lib/libstdc++/../../../contrib/gcclibs/libiberty/cp-demangle.c > mkdep -f .depend -a /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/bitmap_allocator.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/pool_allocator.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/mt_allocator.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/codecvt.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/compatibility.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/complex_io.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/ctype.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/debug.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/debug_list.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/functexcept.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/globals_io.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/ios.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/ios_failure.cc /usr/src/gnu/lib/libstdc++/../ ../../contrib/libstdc++/src/ios_init.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/ios_locale.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/limits.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/list.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/locale.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/locale_init.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/locale_facets.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/localename.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/stdexcept.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/strstream.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/tree.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/allocator-inst.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/concept-inst.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/fstream-inst.cc /usr/src/gnu/lib/libstdc ++/../../../contrib/libstdc++/src/ext-inst.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/ios-inst.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/iostream-inst.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/istream-inst.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/istream.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/locale-inst.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/misc-inst.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/ostream-inst.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/sstream-inst.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/streambuf-inst.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/streambuf.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/string-inst.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/valarray-inst.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/wlocale-ins t.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/wstring-inst.cc atomicity.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/config/locale/generic/codecvt_members.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/config/locale/generic/collate_members.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/config/locale/darwin/ctype_members.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/config/locale/generic/messages_members.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/config/locale/generic/monetary_members.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/config/locale/generic/numeric_members.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/config/locale/generic/time_members.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/config/io/basic_file_stdio.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/config/locale/generic/c_locale.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/d el_op.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/del_opnt.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/del_opv.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/del_opvnt.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/eh_alloc.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/eh_arm.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/eh_aux_runtime.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/eh_call.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/eh_catch.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/eh_exception.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/eh_globals.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/eh_personality.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/eh_term_handler.cc /usr/src/gnu/lib/libstdc++/../../../contrib/lib stdc++/libsupc++/eh_terminate.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/eh_throw.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/eh_type.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/eh_unex_handler.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/guard.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/new_handler.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/new_op.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/new_opnt.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/new_opv.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/new_opvnt.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/pure.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/tinfo.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/tinfo2.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstd c++/libsupc++/vec.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/vterminate.cc > In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/eh_alloc.cc:41: > /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-cxx.h:41:20: error: unwind.h: No such file or directory > In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/eh_arm.cc:31: > /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-cxx.h:41:20: error: unwind.h: No such file or directory > In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/eh_aux_runtime.cc:34: > /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-cxx.h:41:20: error: unwind.h: No such file or directory > In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/eh_call.cc:33: > /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-cxx.h:41:20: error: unwind.h: No such file or directory > /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/eh_call.cc:37:23: error: unwind-pe.h: No such file or directory > In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/eh_catch.cc:31: > /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-cxx.h:41:20: error: unwind.h: No such file or directory > In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/eh_exception.cc:34: > /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-cxx.h:41:20: error: unwind.h: No such file or directory > In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/eh_globals.cc:35: > /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-cxx.h:41:20: error: unwind.h: No such file or directory > In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/eh_personality.cc:33: > /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-cxx.h:41:20: error: unwind.h: No such file or directory > /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/eh_personality.cc:41:23: error: unwind-pe.h: No such file or directory > In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/eh_term_handler.cc:31: > /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-cxx.h:41:20: error: unwind.h: No such file or directory > In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/eh_terminate.cc:34: > /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-cxx.h:41:20: error: unwind.h: No such file or directory > In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/eh_throw.cc:31: > /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-cxx.h:41:20: error: unwind.h: No such file or directory > In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/eh_type.cc:33: > /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-cxx.h:41:20: error: unwind.h: No such file or directory > In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/eh_unex_handler.cc:30: > /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-cxx.h:41:20: error: unwind.h: No such file or directory > In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/pure.cc:32: > /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-cxx.h:41:20: error: unwind.h: No such file or directory > In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/vec.cc:37: > /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-cxx.h:41:20: error: unwind.h: No such file or directory > mkdep: compile failed > *** Error code 1 > > Stop in /usr/src/gnu/lib/libstdc++. > *** Error code 1 > > Stop in /usr/src/gnu/lib. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. > You have new mail in /var/mail/root > [ bsdbox ] [ root ] [ /usr/src ] ==> > > > Is anyone else experiencing this issue? If not, what's going on? This puzzles me. > > Any help would be much appreciated. > > Thanks kindly, > -- Horst. Hi, It looks like your source tree is missing a lot of files. Try checking it out again. If that fails, well, then we have a problem :p. -- Jacob From owner-freebsd-stable@FreeBSD.ORG Sun May 3 18:40:40 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5D4CA106566C for ; Sun, 3 May 2009 18:40:40 +0000 (UTC) (envelope-from rebotados@exemys.com) Received: from server2.hostmailing.com (server2.hostmailing.com [200.110.145.42]) by mx1.freebsd.org (Postfix) with ESMTP id 210BD8FC14 for ; Sun, 3 May 2009 18:40:39 +0000 (UTC) (envelope-from rebotados@exemys.com) Received: from web.hostmailing.com ([200.110.145.34] helo=www.hostmailing.com) by server2.hostmailing.com with esmtpa (Exim 4.68) (envelope-from ) id 1M0fz4-0003ML-RQ for freebsd-stable@freebsd.org; Sun, 03 May 2009 15:00:14 -0300 Date: Sun, 3 May 2009 16:30:18 -0300 To: freebsd-stable@freebsd.org From: Exemys Message-ID: X-Priority: 3 X-Mailer: wh4535 [version 3.1] MIME-Version: 1.0 Content-Type: text/plain; charset = "iso-8859-1" Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Ethernet - Internet I/O X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: exemys@exemys.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 May 2009 18:40:40 -0000 This is a message in multipart MIME format. Your mail client should not be displaying this. Consider upgrading your mail client to view this message correctly. From owner-freebsd-stable@FreeBSD.ORG Sun May 3 19:53:06 2009 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 48457106566B; Sun, 3 May 2009 19:53:06 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (unknown [IPv6:2001:2f0:104:e001::32]) by mx1.freebsd.org (Postfix) with ESMTP id C15A98FC14; Sun, 3 May 2009 19:53:05 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from delta.allbsd.org (p3138-ipbf904funabasi.chiba.ocn.ne.jp [122.26.38.138]) (authenticated bits=128) by mail.allbsd.org (8.14.3/8.14.2) with ESMTP id n43Jqskd019762; Mon, 4 May 2009 04:53:04 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (alph.allbsd.org [192.168.0.10]) (authenticated bits=0) by delta.allbsd.org (8.13.4/8.13.4) with ESMTP id n43JqemY085625; Mon, 4 May 2009 04:52:41 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Mon, 04 May 2009 04:52:04 +0900 (JST) Message-Id: <20090504.045204.59786498.hrs@allbsd.org> To: re@FreeBSD.org From: Hiroki Sato X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.2 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Mon_May__4_04_52_04_2009_044)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (mail.allbsd.org [133.31.130.32]); Mon, 04 May 2009 04:53:05 +0900 (JST) Cc: stable@FreeBSD.org Subject: possible loader regression on RELENG_7_2_0_RELEASE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 May 2009 19:53:06 -0000 ----Security_Multipart(Mon_May__4_04_52_04_2009_044)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit During upgrading boxes in allbsd.org to RELENG_7_2_0_RELEASE I found one of them could not boot at the loader stage. The error messages issued by the loader after "make installkernel + make installworld + reboot" were the following: |Loading /boot/defaults/loader.conf |/boot/kernel/kernel text=0x7cbd7c data=0xcece0+0x67940 |readin failed | |elf32_loadimage: read failed |/boot/kernel/kernel text=0x7cbd7c data=0xcece0+0x67940 |readin failed | |elf32_loadimage: read failed |Unable to load a kernel! The normal loader prompt was displayed after that and I can enter commands, but neither the kernel nor some old kernels which I confirmed they worked fine got loaded. Then I tried a livefs CDROM, but the same error occurred at the loader stage. So I tried 7.1R CDROM instead, mounted the root file system on the hard drive, and copied a loader binary from 7.1R. It worked with no problem with the RELENG_7_2_0_RELEASE kernel. The motherboard was Supermicro P4DPE (Xeon 2.4GHz x 2, 3GB RAM). The installed version was FreeBSD/i386. I did not narrow down the cause yet due to the time was limited, but it was reproducible and probably hardware-dependent. Replacing the loader binary with the old one worked as a workaround, so I guess there may be a regression around the boot loader. Just a report. -- | Hiroki SATO ----Security_Multipart(Mon_May__4_04_52_04_2009_044)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEABECAAYFAkn99eQACgkQTyzT2CeTzy0awQCeKfXVJ4pQlgPv4leN6hQp/JeO y2IAoMSV8hQRGRTCLmEEKy0Xh/LK+pIp =4oUj -----END PGP SIGNATURE----- ----Security_Multipart(Mon_May__4_04_52_04_2009_044)---- From owner-freebsd-stable@FreeBSD.ORG Mon May 4 08:27:01 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8DEEC1065670 for ; Mon, 4 May 2009 08:27:01 +0000 (UTC) (envelope-from lists@reiteration.net) Received: from smtp1.servage.net (smtp1.servage.net [77.232.76.11]) by mx1.freebsd.org (Postfix) with ESMTP id 522008FC08 for ; Mon, 4 May 2009 08:27:01 +0000 (UTC) (envelope-from lists@reiteration.net) Received: from [127.0.0.1] (roobarb.growveg.org [62.49.247.174]) by smtp1.servage.net (Postfix) with ESMTP id 7C500F9845A for ; Mon, 4 May 2009 08:26:59 +0000 (GMT) Message-ID: <49FEA6D1.2080503@reiteration.net> Date: Mon, 04 May 2009 09:26:57 +0100 From: John User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: FreeBSD Stable Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 090503-0, 03/05/2009), Outbound message X-Antivirus-Status: Clean Subject: cvsup.uk.freebsd.org appears to not be serving X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 08:27:02 -0000 Hi list, hopefully this is the right one and not -questions cvsup.uk.freebsd.org appears to have not been serving these last few weeks. I get, variously, in my logs: Parsing supfile "/etc/cvsupfile" Connecting to cvsup.uk.freebsd.org Connected to cvsup.uk.freebsd.org Rejected by server: Access limit exceeded; try again later Will retry at 03:08:08 Retrying Connecting to cvsup.uk.freebsd.org Connected to cvsup.uk.freebsd.org Server software version: SNAP_16_1h Negotiating file attribute support Exchanging collection information Establishing passive-mode data connection Cannot connect to data port: Connection refused Will retry at 03:18:04 Retrying Connecting to cvsup.uk.freebsd.org Connected to cvsup.uk.freebsd.org Server software version: SNAP_16_1h Negotiating file attribute support Exchanging collection information Establishing passive-mode data connection Cannot connect to data port: Connection refused Will retry at 03:37:33 Retrying ... on and on and on, continuously, 24/7. Because the update is called in a daily script by cron, potentially I get many instances of cvsup each time cron calls it and this happens - additionally the mailed output never arrives until the script successfully completes. So the first I knew of this was when I wasn't getting my mails for the daily run, but anyway... I'm now using cvsup4.uk.freebsd.org, which seems to work fine. Should cvsup.uk.freebsd.org be taken out of the list of cvsup servers? cheers -- John From owner-freebsd-stable@FreeBSD.ORG Mon May 4 09:16:37 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 919251065672 for ; Mon, 4 May 2009 09:16:37 +0000 (UTC) (envelope-from john.marshall@riverwillow.com.au) Received: from mail1.riverwillow.net.au (ns1.riverwillow.net.au [203.58.93.40]) by mx1.freebsd.org (Postfix) with ESMTP id 165DC8FC0A for ; Mon, 4 May 2009 09:16:33 +0000 (UTC) (envelope-from john.marshall@riverwillow.com.au) Received: from rwpc12.mby.riverwillow.net.au (rwpc12.mby.riverwillow.net.au [172.25.24.168]) by mail1.riverwillow.net.au (8.14.3/8.14.3) with ESMTP id n4490U9a012735 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 4 May 2009 19:00:30 +1000 (AEST) Received: from rwpc12.mby.riverwillow.net.au (localhost [127.0.0.1]) by rwpc12.mby.riverwillow.net.au (8.14.3/8.14.3) with ESMTP id n4490Ujr003404; Mon, 4 May 2009 19:00:30 +1000 (AEST) (envelope-from john.marshall@riverwillow.com.au) Received: (from john@localhost) by rwpc12.mby.riverwillow.net.au (8.14.3/8.14.3/Submit) id n4490TQK003403; Mon, 4 May 2009 19:00:29 +1000 (AEST) (envelope-from john) Date: Mon, 4 May 2009 19:00:29 +1000 From: John Marshall To: John Message-ID: <20090504090029.GF1006@rwpc12.mby.riverwillow.net.au> Mail-Followup-To: John , FreeBSD Stable References: <49FEA6D1.2080503@reiteration.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="oLBj+sq0vYjzfsbl" Content-Disposition: inline In-Reply-To: <49FEA6D1.2080503@reiteration.net> User-Agent: Mutt/1.4.2.3i X-PGP-Key: http://www.riverwillow.net.au/certs/pgp/johnmarshall.asc X-PGP-KeyID: 0xA29A84A2 Cc: FreeBSD Stable Subject: Re: cvsup.uk.freebsd.org appears to not be serving X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 09:16:37 -0000 --oLBj+sq0vYjzfsbl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, 04 May 2009, 09:26 +0100, John wrote: > Hi list, hopefully this is the right one and not -questions Perhaps -hubs would have been a better choice? > cvsup.uk.freebsd.org appears to have not been serving these last few > weeks. I get, variously, in my logs: >=20 > Parsing supfile "/etc/cvsupfile" > Connecting to cvsup.uk.freebsd.org > Connected to cvsup.uk.freebsd.org > Rejected by server: Access limit exceeded; try again later > Will retry at 03:08:08 > Retrying You are obviously connecting OK; it's just that the server is already as busy as it's minder is willing to let it be. Perhaps you'd be better off choosing something other than 03:00 as a starting point? > Connecting to cvsup.uk.freebsd.org > Connected to cvsup.uk.freebsd.org > Server software version: SNAP_16_1h > Negotiating file attribute support > Exchanging collection information > Establishing passive-mode data connection > Cannot connect to data port: Connection refused > Will retry at 03:18:04 > Retrying Don't do that! Use multiplexed mode "-P m" (from the cvsup man page, "All but multiplexed mode are deprecated"); or use csup which does multiplexed mode by default. On Saturday morning I updated two servers in London from from RELENG_7_1 to RELENG_7_2 using cvsup.uk. I checked again just now and it's still happy. -------------------------------------------------------------- >>> Running /usr/bin/csup -------------------------------------------------------------- Parsing supfile "/usr/local/etc/cvsup/src-supfile" Connecting to cvsup.uk.FreeBSD.org Connected to 131.111.8.41 Server software version: SNAP_16_1h Negotiating file attribute support Exchanging collection information Establishing multiplexed-mode data connection Running Updating collection src-all/cvs Shutting down connection to server Finished successfully --=20 John Marshall --oLBj+sq0vYjzfsbl Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAkn+rq0ACgkQw/tAaKKahKK75wCfVns31aVDT1j2dtckJiLmFAKa AaoAn1Niw3EDraOuV+tJgUdPq2NBDtQv =qtPx -----END PGP SIGNATURE----- --oLBj+sq0vYjzfsbl-- From owner-freebsd-stable@FreeBSD.ORG Mon May 4 10:17:27 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D8424106567C for ; Mon, 4 May 2009 10:17:27 +0000 (UTC) (envelope-from yaol.leo@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.233]) by mx1.freebsd.org (Postfix) with ESMTP id AB18E8FC16 for ; Mon, 4 May 2009 10:17:27 +0000 (UTC) (envelope-from yaol.leo@gmail.com) Received: by rv-out-0506.google.com with SMTP id k40so3137418rvb.43 for ; Mon, 04 May 2009 03:17:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:content-type :content-transfer-encoding; bh=Z68/WgMoG7LibwSdQNGmHeXyawk19JKlq+F75yQLsqY=; b=cRhvv1wT5g6T8W8S+DpJ3qza2hVcEQf77xHBpm2P5JfIgl6B4rfMorGLLXqVCVejaM JDXySnzd9mTjSWbiEwYY1YI/iZOJUlWcLDxzHBEHADez/9wz2aTjhYC9X2X2sZLR0wGV d7lsNvLYYgIoKnKKNsFUSUJK2vwY9eHOqGPmc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :content-type:content-transfer-encoding; b=ijtrzgnmlD0nHJnfFm9nnCTE/KrTsUmKQv7yiaMNew9Lal97kI9HslWfHlW6mTtlI5 ZDUkFXoXgoEUfBDcWVsCaMGGmBaEOj7NJfXGFwwlSuLqKeaxsaYEWXX5T9SoSHx4tVbo ymB/elvKYoWnkUzli5na35HM8P1AZgrGlY0Us= Received: by 10.140.142.15 with SMTP id p15mr1995659rvd.177.1241432247206; Mon, 04 May 2009 03:17:27 -0700 (PDT) Received: from ?10.75.237.107? ([64.104.127.198]) by mx.google.com with ESMTPS id f21sm14973268rvb.25.2009.05.04.03.17.24 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 04 May 2009 03:17:25 -0700 (PDT) Message-ID: <49FEC0AD.7090506@gmail.com> Date: Mon, 04 May 2009 18:17:17 +0800 From: Leo User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: bms@incunabulum.net Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: Help! regarding libpcap. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 10:17:28 -0000 Hi Burce, At first, I'm sorry replay late. I've test build libpcap without ports and using same tar ball. The error message still output. SLT2# make gcc -O2 -I. -DHAVE_CONFIG_H -D_U_="__attribute__((unused))" -c ./pcap-null.c ./pcap-null.c:43: error: conflicting types for 'pcap_activate' ./pcap/pcap.h:266: note: previous declaration of 'pcap_activate' was here *** Error code 1 Stop in /usr/ports/distfiles/libpcap-1.0.0. SLT2# Thank you! -Leo From owner-freebsd-stable@FreeBSD.ORG Mon May 4 10:50:42 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 03EBC106564A for ; Mon, 4 May 2009 10:50: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 4FE518FC24 for ; Mon, 4 May 2009 10:50:41 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (ppp121-45-85-201.lns10.adl6.internode.on.net [121.45.85.201]) (authenticated bits=0) by cain.gsoft.com.au (8.13.8/8.13.8) with ESMTP id n44AoR9b031760 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 4 May 2009 20:20:27 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-stable@freebsd.org Date: Mon, 4 May 2009 20:20:23 +0930 User-Agent: KMail/1.9.10 References: <49FBF3C2.8010809@bsdforen.de> <20090502114958.76c46f25@gluon.draftnet> <49FC3BB9.6000200@bsdforen.de> In-Reply-To: <49FC3BB9.6000200@bsdforen.de> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1988435.eiRNpCTbIG"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200905042020.24783.doconnor@gsoft.com.au> X-Spam-Score: -2.41 () AWL,BAYES_00,RDNS_DYNAMIC X-Scanned-By: MIMEDefang 2.63 on 203.31.81.10 Cc: Bruce Cran , Dominic Fandrey Subject: Re: bluetooth troubleshooting X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 10:50:42 -0000 --nextPart1988435.eiRNpCTbIG Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Sat, 2 May 2009, Dominic Fandrey wrote: > # hccontrol -n ubt0hci inquiry > Inquiry complete. Status: No error [00] > > is pretty lame compared to what should appear according to the > handbook: > > % hccontrol -n ubt0hci inquiry > Inquiry result, num_responses=3D1 > Inquiry result #0 > BD_ADDR: 00:80:37:29:19:a4 > Page Scan Rep. Mode: 0x1 > Page Scan Period Mode: 00 > Page Scan Mode: 00 > Class: 52:02:04 > Clock offset: 0x78ef > Inquiry complete. Status: No error [00] Depends what's in range. Your command indicates to me that there are no _discoverable_ BT modules=20 in range. (Note the discoverable part :) BTW the '-n ubt0hci' is optional if you only have one BT controller. If it isn't discoverable you can do something like.. sdpcontrol -a pda browse (I entered pda into /etc/bluetooth/hosts). If it doesn't show anything (like my phone) you need to bruteforce=20 search for services (I don't understand the rationale of that but=20 that's the way it is), eg.. sh -c 'for i in \ CIP CTP DUN FAX FTRN GN HID HSET LAN NAP OPUSH SP; do \ sdpcontrol -a pda search $i; done' There's a command in Bluez which does this for you but the above would=20 tell you a reasonable amount. =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 --nextPart1988435.eiRNpCTbIG Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iD8DBQBJ/shw5ZPcIHs/zowRAj4FAJ4nFkw9aGCPINPckbUe++Z2RW/rlwCdH0Vm IOECxiuZE8hAK5j7AjoeJNM= =un7/ -----END PGP SIGNATURE----- --nextPart1988435.eiRNpCTbIG-- From owner-freebsd-stable@FreeBSD.ORG Mon May 4 12:37:05 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 78CC6106564A; Mon, 4 May 2009 12:37:05 +0000 (UTC) (envelope-from matthias.schuendehuette@siemens.com) Received: from dragon3.automation.siemens.com (dragon3.automation.siemens.com [194.138.39.158]) by mx1.freebsd.org (Postfix) with ESMTP id 2BD228FC33; Mon, 4 May 2009 12:37:04 +0000 (UTC) (envelope-from matthias.schuendehuette@siemens.com) Received: from erld604x.erlf.siemens.de (erld604x.erlf.siemens.de [194.138.228.204]) by dragon3.automation.siemens.com (Postfix) with ESMTP id 4362B160C7; Mon, 4 May 2009 14:08:03 +0200 (CEST) Received: from DEERLF0AX5.ww004.siemens.net (deerlf0ax5.ww004.siemens.net [157.163.247.173]) by erld604x.erlf.siemens.de (Postfix) with ESMTP id 79EA86656E; Mon, 4 May 2009 14:08:03 +0200 (CEST) Received: from DEERLF0CX4.ww004.siemens.net ([157.163.247.170]) by DEERLF0AX5.ww004.siemens.net ([157.163.247.173]) with mapi; Mon, 4 May 2009 14:08:03 +0200 From: "Schuendehuette, Matthias" To: "freebsd-security-notifications-owner@freebsd.org" Date: Mon, 4 May 2009 14:08:05 +0200 Thread-Topic: FreeBSD supported branches update Thread-Index: AcnKziA7fU+YbdeAQemQgjN1EHqvqABt8dqA Message-ID: References: <49FBAE78.7090608@freebsd.org> In-Reply-To: <49FBAE78.7090608@freebsd.org> Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "freebsd-stable@freebsd.org" Subject: RE: FreeBSD supported branches update X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 12:37:06 -0000 Hello, owner-freebsd-security-notifications@freebsd.org wrote on : > The branches supported by the FreeBSD Security Officer have > been updated > to reflect the EoL (end-of-life) of FreeBSD 7.0. The new > list is below > and at . Please note that FreeBSD > 7.0 was originally announced with an EoL date of February 28, 2009, > but the EoL was delayed by two months in order to allow a 3 month > window for systems to be upgraded to FreeBSD 7.1. I have severe problems with this, because NFS-Locking is not working on FreeBSD-7.1 and later with HP-UX clients. See several PRs which are talking about this. Same is true f=FCr FreeBSD-6.4. So all Releases with kernel-supported NFS-Locking have problems with HP-UX clients. FreeBSD-7.0 is the last release that is working and that is therefor still productive at our site. What do you recommend? with best regards Matthias Sch=FCndeh=FCtte SIEMENS AG, Industry Sector, DT LD S IT Tel. +49-30-386 29957 --=20 Plain text mail please HTML is considered as SPAM From owner-freebsd-stable@FreeBSD.ORG Mon May 4 13:32:56 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 31FDA1065670 for ; Mon, 4 May 2009 13:32:56 +0000 (UTC) (envelope-from kensmith@cse.Buffalo.EDU) Received: from phoebe.cse.buffalo.edu (phoebe.cse.buffalo.edu [128.205.32.89]) by mx1.freebsd.org (Postfix) with ESMTP id EC6488FC15 for ; Mon, 4 May 2009 13:32:55 +0000 (UTC) (envelope-from kensmith@cse.Buffalo.EDU) Received: from [128.205.32.76] (bauer.cse.buffalo.edu [128.205.32.76]) (authenticated bits=0) by phoebe.cse.buffalo.edu (8.14.1/8.13.7) with ESMTP id n44DWqeM023551 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 4 May 2009 09:32:55 -0400 (EDT) (envelope-from kensmith@cse.buffalo.edu) From: Ken Smith To: freebsd-stable Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-PXodYaqgI+LnbsHcCYzX" Organization: U. Buffalo CSE Department Date: Mon, 04 May 2009 09:32:52 -0400 Message-Id: <1241443972.1158.5.camel@bauer.cse.buffalo.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 FreeBSD GNOME Team Port X-DCC-Buffalo.EDU-Metrics: phoebe.cse.buffalo.edu 1335; Body=0 Fuz1=0 Fuz2=0 Subject: FreeBSD 7.2-RELEASE Available X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 13:32:56 -0000 --=-PXodYaqgI+LnbsHcCYzX Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Just a quick note for those of you not subscribed to freebsd-announce@. We finished up 7.2-RELEASE over the weekend. The announcement message is available here: http://www.freebsd.org/releases/7.2R/announce.html Thanks for all the help with testing during the release cycle. --=20 Ken Smith - From there to here, from here to | kensmith@cse.buffalo.edu there, funny things are everywhere. | - Theodore Geisel | --=-PXodYaqgI+LnbsHcCYzX Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEABECAAYFAkn+7noACgkQ/G14VSmup/YjpwCgiCrgaq81xkathE0alDphWxXH TJMAn14vQk34/U1vUZIZkgGJVkU3pqX9 =live -----END PGP SIGNATURE----- --=-PXodYaqgI+LnbsHcCYzX-- From owner-freebsd-stable@FreeBSD.ORG Mon May 4 14:53:07 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 62903106566B for ; Mon, 4 May 2009 14:53:07 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id 395478FC0C for ; Mon, 4 May 2009 14:53:07 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 9B1B03279C7; Mon, 4 May 2009 10:53:06 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Mon, 04 May 2009 10:53:06 -0400 X-Sasl-enc: U2PfHEs8azusvi2pBDiip+s8ZrlduKu77QyiBxG3gXdh 1241448786 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id 18FAA1356D; Mon, 4 May 2009 10:53:06 -0400 (EDT) Message-ID: <49FF014F.7070107@incunabulum.net> Date: Mon, 04 May 2009 15:53:03 +0100 From: Bruce Simpson User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Leo References: <49FEC0AD.7090506@gmail.com> In-Reply-To: <49FEC0AD.7090506@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: Help! regarding libpcap. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 14:53:07 -0000 Leo wrote: > Hi Burce, > At first, I'm sorry replay late. I've test build libpcap without ports > and using same tar ball. The error message still output. > > SLT2# make > gcc -O2 -I. -DHAVE_CONFIG_H -D_U_="__attribute__((unused))" -c > ./pcap-null.c > ./pcap-null.c:43: error: conflicting types for 'pcap_activate' > ./pcap/pcap.h:266: note: previous declaration of 'pcap_activate' was here > *** Error code 1 Hi, I can't think what might be causing this for you... Do you have other pcap libraries installed on the system? Perhaps a define is incorrect. Are you trying this on a 7.2 or a HEAD system? I believe 7.2, so that should rule out changes in HEAD. Do you have BPF headers present on the system? Have you checked the output of config.log? Do you have a bpf device in your kernel? -- I think that might be it. The fix might be to specify --with-pcap=bpf in CONFIGURE_ARGS in the port. I just built the port on an i386 system tracking RELENG_7 sources, and couldn't reproduce this problem, although I have bpf in kernel there. thanks, BMS From owner-freebsd-stable@FreeBSD.ORG Mon May 4 14:55:23 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1C360106564A for ; Mon, 4 May 2009 14:55:23 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id E41648FC18 for ; Mon, 4 May 2009 14:55:22 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 15B67336F95; Mon, 4 May 2009 10:55:22 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Mon, 04 May 2009 10:55:22 -0400 X-Sasl-enc: 7QeG2VcX9yvQL9tI10bFJ/aX/tGi695D2w3tb36/VHP0 1241448921 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id 4319D28D93; Mon, 4 May 2009 10:55:21 -0400 (EDT) Message-ID: <49FF01D6.5020607@incunabulum.net> Date: Mon, 04 May 2009 15:55:18 +0100 From: Bruce Simpson User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Daniel O'Connor References: <49FBF3C2.8010809@bsdforen.de> <20090502114958.76c46f25@gluon.draftnet> <49FC3BB9.6000200@bsdforen.de> <200905042020.24783.doconnor@gsoft.com.au> In-Reply-To: <200905042020.24783.doconnor@gsoft.com.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Bruce Cran , Dominic Fandrey , freebsd-stable@freebsd.org Subject: Re: bluetooth troubleshooting X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 14:55:23 -0000 Daniel O'Connor wrote: > On Sat, 2 May 2009, Dominic Fandrey wrote: > >> # hccontrol -n ubt0hci inquiry >> Inquiry complete. Status: No error [00] >> >> is pretty lame compared to what should appear according to the >> handbook: >> >> % hccontrol -n ubt0hci inquiry >> Inquiry result, num_responses=1 >> Inquiry result #0 >> BD_ADDR: 00:80:37:29:19:a4 >> Page Scan Rep. Mode: 0x1 >> Page Scan Period Mode: 00 >> Page Scan Mode: 00 >> Class: 52:02:04 >> Clock offset: 0x78ef >> Inquiry complete. Status: No error [00] >> > > Depends what's in range. > > Your command indicates to me that there are no _discoverable_ BT modules > in range. (Note the discoverable part :) > > Not all devices need be INQUIRE-able. Some may not have INQUIRE scan enabled. In that case you need to know the Bluetooth address of the device you're looking for so you can PAGE it. If you're expecting to see a mobile phone or other handheld device you might need to enable discoverability on the device itself. There are also other IAC codes used for INQUIRY, but generally these aren't used. cheers, BMS From owner-freebsd-stable@FreeBSD.ORG Mon May 4 15:29:48 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 79381106567C for ; Mon, 4 May 2009 15:29:48 +0000 (UTC) (envelope-from yaol.leo@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.227]) by mx1.freebsd.org (Postfix) with ESMTP id 4115B8FC19 for ; Mon, 4 May 2009 15:29:48 +0000 (UTC) (envelope-from yaol.leo@gmail.com) Received: by rv-out-0506.google.com with SMTP id k40so3268580rvb.43 for ; Mon, 04 May 2009 08:29:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=O5us5LY8ma2RNFxog+lRtjUveuOZFIfFj2Dhpibpf4Q=; b=soQ4Qr7SLy9WY3TresMxXILyr4Lg/0xh5fnAJciA7EEnmiXVfyiRSOuEIEyUWvsE8T N6m9+15QH4afvluVmcwTStXD+U0iFGNwzzLQ07usoqb4fRnThE8Sc0jlpZovLkk3M90Q Lxv4YJja+4UM+vDUR47KOtpvFXWJ5DTXFQNIw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=FdAIcFQnE5Pms3gxXXR/SnncvNmEq2FsCVI+9d8r9Gpyb8jhyX6YRrt0AZoW+awhgO CZlYAI/FOf6/ccw4FImv2JN2ktZ/TU64YFPGL0jpNIHt673JWzdw6xJk/9LgCnIZaHMI YgROZ0e2jrA7jIE/tP37U1nDLnHlFtvpPgn7c= Received: by 10.141.198.2 with SMTP id a2mr2102000rvq.58.1241450987757; Mon, 04 May 2009 08:29:47 -0700 (PDT) Received: from ?10.75.238.84? ([64.104.127.198]) by mx.google.com with ESMTPS id k37sm15568212rvb.48.2009.05.04.08.29.45 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 04 May 2009 08:29:46 -0700 (PDT) Message-ID: <49FF09E1.5010306@gmail.com> Date: Mon, 04 May 2009 23:29:37 +0800 From: Leo User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Bruce Simpson References: <49FEC0AD.7090506@gmail.com> <49FF014F.7070107@incunabulum.net> In-Reply-To: <49FF014F.7070107@incunabulum.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: Help! regarding libpcap. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 15:29:53 -0000 Bruce Simpson wrote: > Leo wrote: >> Hi Burce, >> At first, I'm sorry replay late. I've test build libpcap without >> ports and using same tar ball. The error message still output. >> >> SLT2# make >> gcc -O2 -I. -DHAVE_CONFIG_H -D_U_="__attribute__((unused))" -c >> ./pcap-null.c >> ./pcap-null.c:43: error: conflicting types for 'pcap_activate' >> ./pcap/pcap.h:266: note: previous declaration of 'pcap_activate' was >> here >> *** Error code 1 > > Hi, > > I can't think what might be causing this for you... Do you have other > pcap libraries installed on the system? Perhaps a define is incorrect. > > Are you trying this on a 7.2 or a HEAD system? I believe 7.2, so that > should rule out changes in HEAD. > > Do you have BPF headers present on the system? Have you checked the > output of config.log? Do you have a bpf device in your kernel? > -- I think that might be it. The fix might be to specify > --with-pcap=bpf in CONFIGURE_ARGS in the port. > > I just built the port on an i386 system tracking RELENG_7 sources, and > couldn't reproduce this problem, although I have bpf in kernel there. > > thanks, > BMS > Hi Bruce, I don't have other pcap lib installed on this box. Previously installed a libpcap 0.9 on this box , But I've deleted this version. On my box, not enable BPF. Let me try if enable the feature. -Leo From owner-freebsd-stable@FreeBSD.ORG Mon May 4 16:07:00 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B9270106566B for ; Mon, 4 May 2009 16:07:00 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id 8EE338FC08 for ; Mon, 4 May 2009 16:07:00 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id 3451C33A16C; Mon, 4 May 2009 12:07:00 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute2.internal (MEProxy); Mon, 04 May 2009 12:07:00 -0400 X-Sasl-enc: Nk7sYFYTvFTxmHj5dFGT2VDREVU0UA84CsxSHF3dGZu4 1241453219 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id A651B29013; Mon, 4 May 2009 12:06:59 -0400 (EDT) Message-ID: <49FF12A0.3010009@incunabulum.net> Date: Mon, 04 May 2009 17:06:56 +0100 From: Bruce Simpson User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Leo References: <49FEC0AD.7090506@gmail.com> <49FF014F.7070107@incunabulum.net> <49FF09E1.5010306@gmail.com> In-Reply-To: <49FF09E1.5010306@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: Help! regarding libpcap. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 16:07:01 -0000 Leo wrote: > > I don't have other pcap lib installed on this box. Previously > installed a libpcap 0.9 on this box , But I've deleted this version. > On my box, not enable BPF. Let me try if enable the feature. That's probably what it is. Can you try the following: * give pcap configure --with-pcap=bpf WITHOUT having bpf in your kernel config. * try enabling bpf in kernel config and building the port as usual. Most likely libpcap's new configure script is detecting the lack of /dev/bpf* and assuming there is no packet capture support in the system. This needs to be fixed for cross compiling to be possible. If you could try at least the first fix then this is the answer. thanks, BMS From owner-freebsd-stable@FreeBSD.ORG Mon May 4 17:56:49 2009 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CA815106566C for ; Mon, 4 May 2009 17:56:49 +0000 (UTC) (envelope-from korvus@comcast.net) Received: from mx04.pub.collaborativefusion.com (mx04.pub.collaborativefusion.com [206.210.72.84]) by mx1.freebsd.org (Postfix) with ESMTP id 95CB78FC12 for ; Mon, 4 May 2009 17:56:49 +0000 (UTC) (envelope-from korvus@comcast.net) Received: from [192.168.2.164] ([206.210.89.202]) by mx04.pub.collaborativefusion.com (StrongMail Enterprise 4.1.1.4(4.1.1.4-47689)); Mon, 04 May 2009 13:39:08 -0400 X-VirtualServerGroup: Default X-MailingID: 00000::00000::00000::00000::::6 X-SMHeaderMap: mid="X-MailingID" X-Destination-ID: freebsd-stable@FreeBSD.org X-SMFBL: ZnJlZWJzZC1zdGFibGVARnJlZUJTRC5vcmc= Message-ID: <49FF28BC.5080304@comcast.net> Date: Mon, 04 May 2009 13:41:16 -0400 From: Steve Polyack User-Agent: Thunderbird 2.0.0.21 (X11/20090327) MIME-Version: 1.0 To: freebsd-x11 , freebsd-stable Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Radeon 9250 DRM in 7.2-RELEASE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 17:56:50 -0000 I upgraded my workstation (via source) to 7.2-RELEASE from 7.1-RELEASE about a day ago. After the upgrade procedure, I'm having no luck with using DRM in X11. It worked fine before and gave reasonable performance. Now when I start up X with DRI enabled, both of my screens display garbage. The mouse pointer is also not visible. I'm using a PCI Radeon 9250. I can get more details if necessary. I can also try to revert the kernel DRM module code to 7.1. From dmesg: drm2: on vgapci2 vgapci2: child drm2 requested pci_enable_busmaster info: [drm] Initialized radeon 1.29.0 20080528 info: [drm] Setting GART location based on new memory map info: [drm] Loading R200 Microcode info: [drm] writeback test succeeded in 2 usecs drm2: [ITHREAD] Any ideas or suggestions would be appreciated. Thanks. From owner-freebsd-stable@FreeBSD.ORG Mon May 4 18:13:57 2009 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C9FDD106566B; Mon, 4 May 2009 18:13:57 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id 746B88FC18; Mon, 4 May 2009 18:13:57 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from [192.168.1.4] (adsl-19-214-20.bna.bellsouth.net [68.19.214.20]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id n44IDnUV061305 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 May 2009 14:13:49 -0400 (EDT) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Steve Polyack In-Reply-To: <49FF28BC.5080304@comcast.net> References: <49FF28BC.5080304@comcast.net> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-A8gPSLLPhE5BAdoC3ozi" Organization: FreeBSD Date: Mon, 04 May 2009 13:13:36 -0500 Message-Id: <1241460816.1788.22.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1.1 FreeBSD GNOME Team Port X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, MIME_QP_LONG_LINE,RDNS_DYNAMIC autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: freebsd-x11 , freebsd-stable Subject: Re: Radeon 9250 DRM in 7.2-RELEASE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 18:13:58 -0000 --=-A8gPSLLPhE5BAdoC3ozi Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 2009-05-04 at 13:41 -0400, Steve Polyack wrote: > I upgraded my workstation (via source) to 7.2-RELEASE from 7.1-RELEASE=20 > about a day ago. After the upgrade procedure, I'm having no luck with=20 > using DRM in X11. It worked fine before and gave reasonable=20 > performance. Now when I start up X with DRI enabled, both of my screens=20 > display garbage. The mouse pointer is also not visible. >=20 > I'm using a PCI Radeon 9250. I can get more details if necessary. I=20 > can also try to revert the kernel DRM module code to 7.1. >=20 > From dmesg: > drm2: on vgapci2 Why is this drm2? Is this a multicard setup? Multicard doesn't work right now. If you aren't using more than one card, can you disable whatever else drm is attaching to? robert. > vgapci2: child drm2 requested pci_enable_busmaster > info: [drm] Initialized radeon 1.29.0 20080528 > info: [drm] Setting GART location based on new memory map > info: [drm] Loading R200 Microcode > info: [drm] writeback test succeeded in 2 usecs > drm2: [ITHREAD] >=20 > Any ideas or suggestions would be appreciated. Thanks. >=20 > _______________________________________________ > freebsd-x11@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-x11 > To unsubscribe, send any mail to "freebsd-x11-unsubscribe@freebsd.org" --=20 Robert Noland FreeBSD --=-A8gPSLLPhE5BAdoC3ozi Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEABECAAYFAkn/MFAACgkQM4TrQ4qfROPZQgCePQ5iqX6J1cQyMsICmlmcKiy1 evwAoIPs33gKk5EWW97OGwBdyiH0afyj =HFOr -----END PGP SIGNATURE----- --=-A8gPSLLPhE5BAdoC3ozi-- From owner-freebsd-stable@FreeBSD.ORG Mon May 4 18:43:19 2009 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 304151065678 for ; Mon, 4 May 2009 18:43:19 +0000 (UTC) (envelope-from korvus@comcast.net) Received: from mx04.pub.collaborativefusion.com (mx04.pub.collaborativefusion.com [206.210.72.84]) by mx1.freebsd.org (Postfix) with ESMTP id EE2628FC25 for ; Mon, 4 May 2009 18:43:18 +0000 (UTC) (envelope-from korvus@comcast.net) Received: from [192.168.2.164] ([206.210.89.202]) by mx04.pub.collaborativefusion.com (StrongMail Enterprise 4.1.1.4(4.1.1.4-47689)); Mon, 04 May 2009 14:41:08 -0400 X-VirtualServerGroup: Default X-MailingID: 00000::00000::00000::00000::::7 X-SMHeaderMap: mid="X-MailingID" X-Destination-ID: freebsd-stable@FreeBSD.org X-SMFBL: ZnJlZWJzZC1zdGFibGVARnJlZUJTRC5vcmc= Message-ID: <49FF3744.1000908@comcast.net> Date: Mon, 04 May 2009 14:43:16 -0400 From: Steve Polyack User-Agent: Thunderbird 2.0.0.21 (X11/20090327) MIME-Version: 1.0 To: Paul Schmehl References: <49FF28BC.5080304@comcast.net> <57B64585162157F0FE51E05F@utd65257.utdallas.edu> In-Reply-To: <57B64585162157F0FE51E05F@utd65257.utdallas.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-x11 , freebsd-stable Subject: Re: Radeon 9250 DRM in 7.2-RELEASE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 18:43:19 -0000 Paul Schmehl wrote: > > Read /usr/portsUPDATING wrt xorg. There were major changes in the > config file and peripheral detection between 7.1 and 7.2 > > You need to make sure that both dbus and hald are running. Remove the > mouse and keyboard sections from your xorg.conf file. They are no > longer needed. Make sure to remove any line that references RgbPath. > > This may help to get the mouse working (ignore the DontZap line): > > Section "ServerFlags" > Option "DontZap" "No" > Option "AllowEmptyInput" "No" > EndSection > > This should get DRI working: > > Section "DRI" > Group 0 > Mode 0660 > EndSection > I tackled the above when I upgraded Xorg to 7.4 months ago, independently of any FreeBSD release updates. From owner-freebsd-stable@FreeBSD.ORG Mon May 4 18:45:48 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 15DC810656C9; Mon, 4 May 2009 18:45:48 +0000 (UTC) (envelope-from prvs=3684acee7=pauls@utdallas.edu) Received: from ip-relay-001.utdallas.edu (ip-relay-001.utdallas.edu [129.110.20.111]) by mx1.freebsd.org (Postfix) with ESMTP id CA2928FC0A; Mon, 4 May 2009 18:45:47 +0000 (UTC) (envelope-from prvs=3684acee7=pauls@utdallas.edu) X-Group: RELAYLIST X-IronPort-AV: E=Sophos;i="4.40,292,1238994000"; d="scan'208";a="11341105" Received: from smtp3.utdallas.edu ([129.110.20.110]) by ip-relay-001.utdallas.edu with ESMTP; 04 May 2009 13:16:09 -0500 Received: from utd65257.utdallas.edu (utd65257.utdallas.edu [129.110.3.28]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp3.utdallas.edu (Postfix) with ESMTPSA id 0E1AE8407; Mon, 4 May 2009 13:16:09 -0500 (CDT) Date: Mon, 04 May 2009 18:16:08 +0000 From: Paul Schmehl To: Steve Polyack , freebsd-x11 , freebsd-stable Message-ID: <57B64585162157F0FE51E05F@utd65257.utdallas.edu> In-Reply-To: <49FF28BC.5080304@comcast.net> References: <49FF28BC.5080304@comcast.net> X-Mailer: Mulberry/4.0.6 (Linux/x86) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=sha1; protocol="application/pkcs7-signature"; boundary="==========7BAB80CAE092B37F0991==========" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: Radeon 9250 DRM in 7.2-RELEASE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 18:45:48 -0000 --==========7BAB80CAE092B37F0991========== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline --On Monday, May 04, 2009 12:41:16 -0500 Steve Polyack =20 wrote: > > I upgraded my workstation (via source) to 7.2-RELEASE from 7.1-RELEASE > about a day ago. After the upgrade procedure, I'm having no luck with > using DRM in X11. It worked fine before and gave reasonable > performance. Now when I start up X with DRI enabled, both of my screens > display garbage. The mouse pointer is also not visible. > > I'm using a PCI Radeon 9250. I can get more details if necessary. I > can also try to revert the kernel DRM module code to 7.1. > > From dmesg: > drm2: on vgapci2 > vgapci2: child drm2 requested pci_enable_busmaster > info: [drm] Initialized radeon 1.29.0 20080528 > info: [drm] Setting GART location based on new memory map > info: [drm] Loading R200 Microcode > info: [drm] writeback test succeeded in 2 usecs > drm2: [ITHREAD] > > Any ideas or suggestions would be appreciated. Thanks. > Read /usr/portsUPDATING wrt xorg. There were major changes in the config file=20 and peripheral detection between 7.1 and 7.2 You need to make sure that both dbus and hald are running. Remove the mouse=20 and keyboard sections from your xorg.conf file. They are no longer needed.=20 Make sure to remove any line that references RgbPath. This may help to get the mouse working (ignore the DontZap line): Section "ServerFlags" Option "DontZap" "No" Option "AllowEmptyInput" "No" EndSection This should get DRI working: Section "DRI" Group 0 Mode 0660 EndSection --=20 Paul Schmehl (pauls@utdallas.edu) Senior Information Security Analyst The University of Texas at Dallas http://www.utdallas.edu/ir/security/ --==========7BAB80CAE092B37F0991==========-- From owner-freebsd-stable@FreeBSD.ORG Mon May 4 18:48:33 2009 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ED6B9106567B for ; Mon, 4 May 2009 18:48:33 +0000 (UTC) (envelope-from korvus@comcast.net) Received: from mx04.pub.collaborativefusion.com (mx04.pub.collaborativefusion.com [206.210.72.84]) by mx1.freebsd.org (Postfix) with ESMTP id 60DDB8FC1E for ; Mon, 4 May 2009 18:48:33 +0000 (UTC) (envelope-from korvus@comcast.net) Received: from [192.168.2.164] ([206.210.89.202]) by mx04.pub.collaborativefusion.com (StrongMail Enterprise 4.1.1.4(4.1.1.4-47689)); Mon, 04 May 2009 14:46:22 -0400 X-VirtualServerGroup: Default X-MailingID: 00000::00000::00000::00000::::7 X-SMHeaderMap: mid="X-MailingID" X-Destination-ID: freebsd-stable@FreeBSD.org X-SMFBL: ZnJlZWJzZC1zdGFibGVARnJlZUJTRC5vcmc= Message-ID: <49FF387F.1080203@comcast.net> Date: Mon, 04 May 2009 14:48:31 -0400 From: Steve Polyack User-Agent: Thunderbird 2.0.0.21 (X11/20090327) MIME-Version: 1.0 To: Robert Noland References: <49FF28BC.5080304@comcast.net> <1241460816.1788.22.camel@balrog.2hip.net> In-Reply-To: <1241460816.1788.22.camel@balrog.2hip.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-x11 , freebsd-stable Subject: Re: Radeon 9250 DRM in 7.2-RELEASE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 18:48:34 -0000 Robert Noland wrote: > > Why is this drm2? Is this a multicard setup? Multicard doesn't work > right now. If you aren't using more than one card, can you disable > whatever else drm is attaching to? > > robert. > > This is something funny I had to deal with initially. There is *no* drm0 or drm1 being probed. Consequently, there is only one entry in /dev/dri/, card2. As a result, Xorg doesn't even recognize card2 as a source for DRM (probably due to what you said). In the past, I have symlinked /dev/dri/card2 to /dev/dri/card0 and Xorg would work correctly, utilizing DRM. I have an onboard Intel VGA device, but as far as I know it is disabled. I can double check, but as I've noted things have worked fine with the above tweak until upgrading to 7.2-RELEASE. Thanks, From owner-freebsd-stable@FreeBSD.ORG Mon May 4 19:07:52 2009 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D52B310656DF; Mon, 4 May 2009 19:07:52 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id 7DC3D8FC13; Mon, 4 May 2009 19:07:52 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from [192.168.1.4] (adsl-19-214-20.bna.bellsouth.net [68.19.214.20]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id n44J7kO1061664 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 May 2009 15:07:46 -0400 (EDT) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Steve Polyack In-Reply-To: <49FF387F.1080203@comcast.net> References: <49FF28BC.5080304@comcast.net> <1241460816.1788.22.camel@balrog.2hip.net> <49FF387F.1080203@comcast.net> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-ELjmG92NjRRBRIo7qIfe" Organization: FreeBSD Date: Mon, 04 May 2009 14:07:33 -0500 Message-Id: <1241464053.1788.32.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1.1 FreeBSD GNOME Team Port X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, MIME_QP_LONG_LINE,RDNS_DYNAMIC autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: freebsd-x11 , freebsd-stable Subject: Re: Radeon 9250 DRM in 7.2-RELEASE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 19:07:53 -0000 --=-ELjmG92NjRRBRIo7qIfe Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 2009-05-04 at 14:48 -0400, Steve Polyack wrote: > Robert Noland wrote: > > > > Why is this drm2? Is this a multicard setup? Multicard doesn't work > > right now. If you aren't using more than one card, can you disable > > whatever else drm is attaching to? > > > > robert. > > > > =20 >=20 > This is something funny I had to deal with initially. There is *no*=20 > drm0 or drm1 being probed. Consequently, there is only one entry in=20 > /dev/dri/, card2. As a result, Xorg doesn't even recognize card2 as a=20 > source for DRM (probably due to what you said). In the past, I have=20 > symlinked /dev/dri/card2 to /dev/dri/card0 and Xorg would work=20 > correctly, utilizing DRM. >=20 > I have an onboard Intel VGA device, but as far as I know it is=20 > disabled. I can double check, but as I've noted things have worked fine=20 > with the above tweak until upgrading to 7.2-RELEASE. Can you send me a "pciconf -lvb" robert. > Thanks, >=20 > _______________________________________________ > freebsd-x11@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-x11 > To unsubscribe, send any mail to "freebsd-x11-unsubscribe@freebsd.org" --=20 Robert Noland FreeBSD --=-ELjmG92NjRRBRIo7qIfe Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEABECAAYFAkn/PPUACgkQM4TrQ4qfROO8GgCeOhhCQFyc61eoGTrZYma6/Mzf mhgAn18dw/l2+1EWGyvWZ/xjjkP0aL6D =weya -----END PGP SIGNATURE----- --=-ELjmG92NjRRBRIo7qIfe-- From owner-freebsd-stable@FreeBSD.ORG Mon May 4 19:22:19 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 10CD41065686 for ; Mon, 4 May 2009 19:22:19 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id D7C778FC0C for ; Mon, 4 May 2009 19:22:18 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 8D4B446B8A; Mon, 4 May 2009 15:22:18 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 841E08A026; Mon, 4 May 2009 15:22:17 -0400 (EDT) From: John Baldwin To: freebsd-stable@freebsd.org Date: Mon, 4 May 2009 10:15:32 -0400 User-Agent: KMail/1.9.7 References: <910e60e80905021111v1ef2d386j17db9bccb953b609@mail.gmail.com> In-Reply-To: <910e60e80905021111v1ef2d386j17db9bccb953b609@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200905041015.32695.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Mon, 04 May 2009 15:22:17 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.5 required=4.2 tests=AWL,BAYES_00, DATE_IN_PAST_03_06,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: dikshie Subject: Re: #0 sched_switch (td=0xc579b230, newtd=Variable "newtd" is not available. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 19:22:19 -0000 On Saturday 02 May 2009 2:11:59 pm dikshie wrote: > is this known bug? > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x8c000180 > fault code = supervisor read, page not present > instruction pointer = 0x20:0xc063d904 > stack pointer = 0x28:0xe7704608 > frame pointer = 0x28:0xe7704620 > 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 = 2013 (firefox-bin) > trap number = 12 > panic: page fault > cpuid = 0 > Uptime: 5h1m34s > Physical memory: 2038 MB > Dumping 194 MB: 179 163 147 131 115 99 83 (CTRL-C to abort) 67 > (CTRL-C to abort) (CTRL-C to abort) (CTRL-C to abort) 51 (CTRL-C to > abort) 35 19 3 > > kgdb: kvm_read: invalid address (0x4c414e52) > kgdb: kvm_read: invalid address (0x35b2e804) > kgdb: kvm_read: invalid address (0x5502) > kgdb: kvm_read: invalid address (0x6a02) > Reading symbols from /boot/kernel/geom_journal.ko...Reading symbols > from /boot/kernel/geom_journal.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/geom_journal.ko > Reading symbols from /boot/kernel/acpi_ibm.ko...Reading symbols from > /boot/kernel/acpi_ibm.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/acpi_ibm.ko > Reading symbols from /boot/kernel/acpi.ko...Reading symbols from > /boot/kernel/acpi.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/acpi.ko > Reading symbols from /boot/kernel/linprocfs.ko...Reading symbols from > /boot/kernel/linprocfs.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/linprocfs.ko > Reading symbols from /boot/kernel/linux.ko...Reading symbols from > /boot/kernel/linux.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/linux.ko > #0 sched_switch (td=0xc579b230, newtd=Variable "newtd" is not available. > ) at /usr/src/sys/kern/sched_ule.c:1944 > 1944 cpuid = PCPU_GET(cpuid); > (kgdb) Please get a backtrace using 'bt'. Also, 'l *0xc063d904' may also be useful. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Mon May 4 19:56:09 2009 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CF1BE1065673 for ; Mon, 4 May 2009 19:56:09 +0000 (UTC) (envelope-from korvus@comcast.net) Received: from mx04.pub.collaborativefusion.com (mx04.pub.collaborativefusion.com [206.210.72.84]) by mx1.freebsd.org (Postfix) with ESMTP id 96C398FC13 for ; Mon, 4 May 2009 19:56:09 +0000 (UTC) (envelope-from korvus@comcast.net) Received: from [192.168.2.164] ([206.210.89.202]) by mx04.pub.collaborativefusion.com (StrongMail Enterprise 4.1.1.4(4.1.1.4-47689)); Mon, 04 May 2009 15:53:58 -0400 X-VirtualServerGroup: Default X-MailingID: 00000::00000::00000::00000::::8 X-SMHeaderMap: mid="X-MailingID" X-Destination-ID: freebsd-stable@FreeBSD.org X-SMFBL: ZnJlZWJzZC1zdGFibGVARnJlZUJTRC5vcmc= Message-ID: <49FF4857.4070904@comcast.net> Date: Mon, 04 May 2009 15:56:07 -0400 From: Steve Polyack User-Agent: Thunderbird 2.0.0.21 (X11/20090327) MIME-Version: 1.0 To: Robert Noland References: <49FF28BC.5080304@comcast.net> <1241460816.1788.22.camel@balrog.2hip.net> <49FF387F.1080203@comcast.net> <1241464053.1788.32.camel@balrog.2hip.net> In-Reply-To: <1241464053.1788.32.camel@balrog.2hip.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-x11 , freebsd-stable Subject: Re: Radeon 9250 DRM in 7.2-RELEASE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 19:56:10 -0000 Robert Noland wrote: > On Mon, 2009-05-04 at 14:48 -0400, Steve Polyack wrote: > >> This is something funny I had to deal with initially. There is *no* >> drm0 or drm1 being probed. Consequently, there is only one entry in >> /dev/dri/, card2. As a result, Xorg doesn't even recognize card2 as a >> source for DRM (probably due to what you said). In the past, I have >> symlinked /dev/dri/card2 to /dev/dri/card0 and Xorg would work >> correctly, utilizing DRM. >> >> I have an onboard Intel VGA device, but as far as I know it is >> disabled. I can double check, but as I've noted things have worked fine >> with the above tweak until upgrading to 7.2-RELEASE. >> > > Can you send me a "pciconf -lvb" > > robert. > > $ pciconf -lvb hostb0@pci0:0:0:0: class=0x060000 card=0x01ad1028 chip=0x27708086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82945G/GZ/P/PL Host Bridge/DRAM Controller' class = bridge subclass = HOST-PCI pcib1@pci0:0:1:0: class=0x060400 card=0x00008086 chip=0x27718086 rev=0x02 hdr=0x01 vendor = 'Intel Corporation' device = '82945G/GZ/P/PL Host to PCI Express Bridge' class = bridge subclass = PCI-PCI vgapci0@pci0:0:2:0: class=0x038000 card=0x01ad1028 chip=0x27728086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82945G Integrated Graphics Controller' class = display bar [10] = type Memory, range 32, base 0xfeb00000, size 524288, enabled bar [14] = type I/O Port, range 32, base 0xe898, size 8, enabled bar [18] = type Prefetchable Memory, range 32, base 0xd0000000, size 268435456, enabled bar [1c] = type Memory, range 32, base 0xfeac0000, size 262144, enabled vgapci1@pci0:0:2:1: class=0x038000 card=0x01ad1028 chip=0x27768086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82945G Integrated Graphics Controller' class = display bar [10] = type Memory, range 32, base 0xfeb80000, size 524288, enabled pcib2@pci0:0:28:0: class=0x060400 card=0x00000000 chip=0x27d08086 rev=0x01 hdr=0x01 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) PCIe Root Port' class = bridge subclass = PCI-PCI pcib3@pci0:0:28:1: class=0x060400 card=0x00000000 chip=0x27d28086 rev=0x01 hdr=0x01 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) PCIe Root Port' class = bridge subclass = PCI-PCI uhci0@pci0:0:29:0: class=0x0c0300 card=0x01ad1028 chip=0x27c88086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) USB Universal Host Controller' class = serial bus subclass = USB bar [20] = type I/O Port, range 32, base 0xff80, size 32, enabled uhci1@pci0:0:29:1: class=0x0c0300 card=0x01ad1028 chip=0x27c98086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) USB Universal Host Controller' class = serial bus subclass = USB bar [20] = type I/O Port, range 32, base 0xff60, size 32, enabled uhci2@pci0:0:29:2: class=0x0c0300 card=0x01ad1028 chip=0x27ca8086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) USB Universal Host Controller' class = serial bus subclass = USB bar [20] = type I/O Port, range 32, base 0xff40, size 32, enabled uhci3@pci0:0:29:3: class=0x0c0300 card=0x01ad1028 chip=0x27cb8086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) USB Universal Host Controller' class = serial bus subclass = USB bar [20] = type I/O Port, range 32, base 0xff20, size 32, enabled ehci0@pci0:0:29:7: class=0x0c0320 card=0x01ad1028 chip=0x27cc8086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) USB 2.0 Enhanced Host Controller' class = serial bus subclass = USB bar [10] = type Memory, range 32, base 0xffa80800, size 1024, enabled pcib4@pci0:0:30:0: class=0x060401 card=0x00000000 chip=0x244e8086 rev=0xe1 hdr=0x01 vendor = 'Intel Corporation' device = '82801 Family (ICH2/3/4/4/5/5/6/7/8/9,63xxESB) Hub Interface to PCI Bridge' class = bridge subclass = PCI-PCI pcm0@pci0:0:30:2: class=0x040100 card=0x01ad1028 chip=0x27de8086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82801GB I/O Controller Hub AC'97 Audio' class = multimedia subclass = audio bar [10] = type I/O Port, range 32, base 0xec00, size 256, enabled bar [14] = type I/O Port, range 32, base 0xe8c0, size 64, enabled bar [18] = type Memory, range 32, base 0xfeabfa00, size 512, enabled bar [1c] = type Memory, range 32, base 0xfeabf900, size 256, enabled isab0@pci0:0:31:0: class=0x060100 card=0x00000000 chip=0x27b88086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '945GL Intel 82801GB/GR (ICH7 Family) LPC Interface Controller - 27B8' class = bridge subclass = PCI-ISA atapci0@pci0:0:31:1: class=0x01018a card=0x01ad1028 chip=0x27df8086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) Ultra ATA Storage Controller' class = mass storage subclass = ATA bar [10] = type I/O Port, range 32, base 0x1f0, size 8, enabled bar [14] = type I/O Port, range 32, base 0x3f4, size 1, enabled bar [18] = type I/O Port, range 32, base 0x170, size 8, enabled bar [1c] = type I/O Port, range 32, base 0x374, size 1, enabled bar [20] = type I/O Port, range 32, base 0xffa0, size 16, enabled atapci1@pci0:0:31:2: class=0x01018f card=0x01ad1028 chip=0x27c08086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82801GB/GR/GH (ICH7 Family) Serial ATA Storage Controller' class = mass storage subclass = ATA bar [10] = type I/O Port, range 32, base 0xfe00, size 8, enabled bar [14] = type I/O Port, range 32, base 0xfe10, size 4, enabled bar [18] = type I/O Port, range 32, base 0xfe20, size 8, enabled bar [1c] = type I/O Port, range 32, base 0xfe30, size 4, enabled bar [20] = type I/O Port, range 32, base 0xfea0, size 16, enabled none0@pci0:0:31:3: class=0x0c0500 card=0x01ad1028 chip=0x27da8086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) SMBus Controller' class = serial bus subclass = SMBus bar [20] = type I/O Port, range 32, base 0xe8a0, size 32, enabled bge0@pci0:2:0:0: class=0x020000 card=0x01ad1028 chip=0x167714e4 rev=0x01 hdr=0x00 vendor = 'Broadcom Corporation' device = 'BCM5750A1 NetXtreme Gigabit Ethernet PCI Express' class = network subclass = ethernet bar [10] = type Memory, range 64, base 0xfe8f0000, size 65536, enabled vgapci2@pci0:4:0:0: class=0x030000 card=0x0250174b chip=0x59601002 rev=0x01 hdr=0x00 vendor = 'ATI Technologies Inc' device = 'RV280 Radeon 9200 Pro' class = display subclass = VGA bar [10] = type Prefetchable Memory, range 32, base 0xe8000000, size 134217728, enabled bar [14] = type I/O Port, range 32, base 0xdc00, size 256, enabled bar [18] = type Memory, range 32, base 0xfe5e0000, size 65536, enabled vgapci3@pci0:4:0:1: class=0x038000 card=0x0251174b chip=0x59401002 rev=0x01 hdr=0x00 vendor = 'ATI Technologies Inc' device = 'RV280 Radeon 9200 Pro - Secondary' class = display bar [10] = type Prefetchable Memory, range 32, base 0xe0000000, size 134217728, enabled bar [14] = type Memory, range 32, base 0xfe5f0000, size 65536, enabled From owner-freebsd-stable@FreeBSD.ORG Mon May 4 20:10:48 2009 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6FA4D106564A; Mon, 4 May 2009 20:10:48 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id 306018FC16; Mon, 4 May 2009 20:10:48 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from [192.168.1.4] (adsl-19-214-20.bna.bellsouth.net [68.19.214.20]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id n44KAena062087 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 May 2009 16:10:41 -0400 (EDT) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Steve Polyack In-Reply-To: <49FF4857.4070904@comcast.net> References: <49FF28BC.5080304@comcast.net> <1241460816.1788.22.camel@balrog.2hip.net> <49FF387F.1080203@comcast.net> <1241464053.1788.32.camel@balrog.2hip.net> <49FF4857.4070904@comcast.net> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-nMpkYSAsJ/3t8X/LxbEs" Organization: FreeBSD Date: Mon, 04 May 2009 15:10:27 -0500 Message-Id: <1241467827.1788.43.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1.1 FreeBSD GNOME Team Port X-Spam-Status: No, score=-3.2 required=5.0 tests=AWL,BAYES_00,RDNS_DYNAMIC autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: freebsd-x11 , freebsd-stable Subject: Re: Radeon 9250 DRM in 7.2-RELEASE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 20:10:48 -0000 --=-nMpkYSAsJ/3t8X/LxbEs Content-Type: multipart/mixed; boundary="=-kTzW5pPU8lBnV+qpbJLP" --=-kTzW5pPU8lBnV+qpbJLP Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 2009-05-04 at 15:56 -0400, Steve Polyack wrote: > vgapci0@pci0:0:2:0: class=3D0x038000 card=3D0x01ad1028 chip=3D0x277280= 86=20 > rev=3D0x02 hdr=3D0x00 > vendor =3D 'Intel Corporation' > device =3D '82945G Integrated Graphics Controller' > class =3D display > bar [10] =3D type Memory, range 32, base 0xfeb00000, size 524288,=20 > enabled > bar [14] =3D type I/O Port, range 32, base 0xe898, size 8, > enabled > bar [18] =3D type Prefetchable Memory, range 32, base 0xd0000000,=20 > size 268435456, enabled > bar [1c] =3D type Memory, range 32, base 0xfeac0000, size 262144,=20 > enabled > vgapci1@pci0:0:2:1: class=3D0x038000 card=3D0x01ad1028 chip=3D0x277680= 86=20 > rev=3D0x02 hdr=3D0x00 > vendor =3D 'Intel Corporation' > device =3D '82945G Integrated Graphics Controller' > class =3D display > bar [10] =3D type Memory, range 32, base 0xfeb80000, size 524288,=20 > enabled Ok, they are at least partially disabled... I wonder if a BIOS update would help. Anyway, the garbled screen issue is usually associated with the caching method used on the PCI GART. On IGP chips we force the GART to be uncacheable. On PCI chips they are supposed to be able to snoop the bus and DTRT. All of the fixes for memory caching should be in 7. Please try the attached patch and see if that makes a difference. robert. --=20 Robert Noland FreeBSD --=-kTzW5pPU8lBnV+qpbJLP Content-Disposition: attachment; filename="radeon_disable_wc.patch" Content-Transfer-Encoding: base64 Content-Type: text/x-patch; name="radeon_disable_wc.patch"; charset="us-ascii" SW5kZXg6IHJhZGVvbl9jcC5jDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQotLS0gcmFkZW9uX2NwLmMJKHJldmlzaW9u IDE5MTc5MykNCisrKyByYWRlb25fY3AuYwkod29ya2luZyBjb3B5KQ0KQEAgLTE0MjksNyArMTQy OSw3IEBADQogCQkJZGV2X3ByaXYtPmdhcnRfaW5mby5tYXBwaW5nLnNpemUgPQ0KIAkJCSAgICBk ZXZfcHJpdi0+Z2FydF9pbmZvLnRhYmxlX3NpemU7DQogDQotCQkJZHJtX2NvcmVfaW9yZW1hcF93 YygmZGV2X3ByaXYtPmdhcnRfaW5mby5tYXBwaW5nLCBkZXYpOw0KKwkJCWRybV9jb3JlX2lvcmVt YXAoJmRldl9wcml2LT5nYXJ0X2luZm8ubWFwcGluZywgZGV2KTsNCiAJCQlkZXZfcHJpdi0+Z2Fy dF9pbmZvLmFkZHIgPQ0KIAkJCSAgICBkZXZfcHJpdi0+Z2FydF9pbmZvLm1hcHBpbmcuaGFuZGxl Ow0KIA0K --=-kTzW5pPU8lBnV+qpbJLP-- --=-nMpkYSAsJ/3t8X/LxbEs Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEABECAAYFAkn/S7MACgkQM4TrQ4qfROORnACfQkBq09RDRbpctrQjH/hSnJgk mnkAnjQ5Cex7OFFzWQVaH0WBSbWRRTW2 =aRMC -----END PGP SIGNATURE----- --=-nMpkYSAsJ/3t8X/LxbEs-- From owner-freebsd-stable@FreeBSD.ORG Mon May 4 20:36:14 2009 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 401C51065680 for ; Mon, 4 May 2009 20:36:14 +0000 (UTC) (envelope-from korvus@comcast.net) Received: from mx04.pub.collaborativefusion.com (mx04.pub.collaborativefusion.com [206.210.72.84]) by mx1.freebsd.org (Postfix) with ESMTP id 083738FC13 for ; Mon, 4 May 2009 20:36:13 +0000 (UTC) (envelope-from korvus@comcast.net) Received: from [192.168.2.164] ([206.210.89.202]) by mx04.pub.collaborativefusion.com (StrongMail Enterprise 4.1.1.4(4.1.1.4-47689)); Mon, 04 May 2009 16:34:03 -0400 X-VirtualServerGroup: Default X-MailingID: 00000::00000::00000::00000::::15 X-SMHeaderMap: mid="X-MailingID" X-Destination-ID: freebsd-stable@FreeBSD.org X-SMFBL: ZnJlZWJzZC1zdGFibGVARnJlZUJTRC5vcmc= Message-ID: <49FF51BC.5050104@comcast.net> Date: Mon, 04 May 2009 16:36:12 -0400 From: Steve Polyack User-Agent: Thunderbird 2.0.0.21 (X11/20090327) MIME-Version: 1.0 To: Robert Noland References: <49FF28BC.5080304@comcast.net> <1241460816.1788.22.camel@balrog.2hip.net> <49FF387F.1080203@comcast.net> <1241464053.1788.32.camel@balrog.2hip.net> <49FF4857.4070904@comcast.net> <1241467827.1788.43.camel@balrog.2hip.net> In-Reply-To: <1241467827.1788.43.camel@balrog.2hip.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-x11 , freebsd-stable Subject: Re: Radeon 9250 DRM in 7.2-RELEASE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 20:36:14 -0000 Robert Noland wrote: > Ok, they are at least partially disabled... I wonder if a BIOS update > would help. > > Anyway, the garbled screen issue is usually associated with the caching > method used on the PCI GART. On IGP chips we force the GART to be > uncacheable. On PCI chips they are supposed to be able to snoop the bus > and DTRT. All of the fixes for memory caching should be in 7. > > Please try the attached patch and see if that makes a difference. > > robert. > > Unfortunately, this didn't help. I should also clarify what I'm seeing, as it's not complete garbage as I thought. I have a dual monitor setup, side-by-side using xrandr. When I start X (xfce4) with drm available, the left monitor (primary) is a sold light shade of blue, except for a black corner which is maybe 10pix square. The right monitor displays my typical background image with another black box over part of it. If it shift back to the console and then back into X, I can see the outlines of my startup windows, but they contain garbage and the outlines are fuzzed with green and magenta garbage. From owner-freebsd-stable@FreeBSD.ORG Mon May 4 20:49:47 2009 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C547B106564A; Mon, 4 May 2009 20:49:47 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id 8678C8FC14; Mon, 4 May 2009 20:49:47 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from [192.168.1.4] (adsl-19-214-20.bna.bellsouth.net [68.19.214.20]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id n44KneOT062337 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 May 2009 16:49:41 -0400 (EDT) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Steve Polyack In-Reply-To: <49FF51BC.5050104@comcast.net> References: <49FF28BC.5080304@comcast.net> <1241460816.1788.22.camel@balrog.2hip.net> <49FF387F.1080203@comcast.net> <1241464053.1788.32.camel@balrog.2hip.net> <49FF4857.4070904@comcast.net> <1241467827.1788.43.camel@balrog.2hip.net> <49FF51BC.5050104@comcast.net> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-7ouv/hKRhU9RJjhhl9IQ" Organization: FreeBSD Date: Mon, 04 May 2009 15:49:27 -0500 Message-Id: <1241470167.1788.45.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1.1 FreeBSD GNOME Team Port X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00, MIME_QP_LONG_LINE,RDNS_DYNAMIC autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: freebsd-x11 , freebsd-stable Subject: Re: Radeon 9250 DRM in 7.2-RELEASE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 20:49:48 -0000 --=-7ouv/hKRhU9RJjhhl9IQ Content-Type: multipart/mixed; boundary="=-OPtFaaOQ7DZ485aE8++h" --=-OPtFaaOQ7DZ485aE8++h Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 2009-05-04 at 16:36 -0400, Steve Polyack wrote: > Robert Noland wrote: > > Ok, they are at least partially disabled... I wonder if a BIOS update > > would help. > > > > Anyway, the garbled screen issue is usually associated with the caching > > method used on the PCI GART. On IGP chips we force the GART to be > > uncacheable. On PCI chips they are supposed to be able to snoop the bu= s > > and DTRT. All of the fixes for memory caching should be in 7. > > > > Please try the attached patch and see if that makes a difference. > > > > robert. > > > > =20 >=20 > Unfortunately, this didn't help. I should also clarify what I'm seeing,=20 > as it's not complete garbage as I thought. I have a dual monitor setup,=20 > side-by-side using xrandr. When I start X (xfce4) with drm available,=20 > the left monitor (primary) is a sold light shade of blue, except for a=20 > black corner which is maybe 10pix square. The right monitor displays my=20 > typical background image with another black box over part of it. If it=20 > shift back to the console and then back into X, I can see the outlines=20 > of my startup windows, but they contain garbage and the outlines are=20 > fuzzed with green and magenta garbage. ok, how about this one... If this doesn't do it, then we need to start digging... robert. --=20 Robert Noland FreeBSD --=-OPtFaaOQ7DZ485aE8++h Content-Disposition: attachment; filename="radeon_pci_gart.patch" Content-Transfer-Encoding: base64 Content-Type: text/x-patch; name="radeon_pci_gart.patch"; charset="us-ascii" SW5kZXg6IGF0aV9wY2lnYXJ0LmMNCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCi0tLSBhdGlfcGNpZ2FydC5jCShyZXZp c2lvbiAxOTE3OTMpDQorKysgYXRpX3BjaWdhcnQuYwkod29ya2luZyBjb3B5KQ0KQEAgLTgzLDcg KzgzLDcgQEANCiAJfQ0KIA0KIAlmbGFncyA9IEJVU19ETUFfV0FJVE9LIHwgQlVTX0RNQV9aRVJP Ow0KLQlpZiAoZ2FydF9pbmZvLT5nYXJ0X3JlZ19pZiA9PSBEUk1fQVRJX0dBUlRfSUdQKQ0KKy8v CWlmIChnYXJ0X2luZm8tPmdhcnRfcmVnX2lmID09IERSTV9BVElfR0FSVF9JR1ApDQogCSAgICBm bGFncyB8PSBCVVNfRE1BX05PQ0FDSEU7DQogCQ0KIAlyZXQgPSBidXNfZG1hbWVtX2FsbG9jKGRt YWgtPnRhZywgJmRtYWgtPnZhZGRyLCBmbGFncywgJmRtYWgtPm1hcCk7DQo= --=-OPtFaaOQ7DZ485aE8++h-- --=-7ouv/hKRhU9RJjhhl9IQ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEABECAAYFAkn/VNcACgkQM4TrQ4qfROPkawCeLSIQnDjnEluf5my1KKOjH8H3 Qs0AnRHN6M2fVMTGa/DQBtEsHhVTOutj =arb4 -----END PGP SIGNATURE----- --=-7ouv/hKRhU9RJjhhl9IQ-- From owner-freebsd-stable@FreeBSD.ORG Mon May 4 20:51:03 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8957210656AC for ; Mon, 4 May 2009 20:51:03 +0000 (UTC) (envelope-from torfinn.ingolfsen@broadpark.no) Received: from osl1smout1.broadpark.no (osl1smout1.broadpark.no [80.202.4.58]) by mx1.freebsd.org (Postfix) with ESMTP id 4AD088FC15 for ; Mon, 4 May 2009 20:51:03 +0000 (UTC) (envelope-from torfinn.ingolfsen@broadpark.no) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII Received: from osl1sminn1.broadpark.no ([80.202.4.59]) by osl1smout1.broadpark.no (Sun Java(tm) System Messaging Server 6.3-3.01 (built Jul 12 2007; 32bit)) with ESMTP id <0KJ500ALU0JPO820@osl1smout1.broadpark.no> for freebsd-stable@freebsd.org; Mon, 04 May 2009 22:50:13 +0200 (CEST) Received: from kg-v2.kg4.no ([80.202.83.38]) by osl1sminn1.broadpark.no (Sun Java(tm) System Messaging Server 6.3-3.01 (built Jul 12 2007; 32bit)) with SMTP id <0KJ500DY80JOEJB0@osl1sminn1.broadpark.no> for freebsd-stable@freebsd.org; Mon, 04 May 2009 22:50:13 +0200 (CEST) Date: Mon, 04 May 2009 22:50:12 +0200 From: Torfinn Ingolfsen To: freebsd-stable@freebsd.org Message-id: <20090504225012.392fa49f.torfinn.ingolfsen@broadpark.no> X-Mailer: Sylpheed 2.6.0 (GTK+ 2.16.1; amd64-portbld-freebsd7.2) X-Face: "t9w2,-X@O^I`jVW\sonI3.,36KBLZE*AL[y9lL[PyFD*r_S:dIL9c[8Y>V42R0"!"yb_zN,f#%.[PYYNq; m"_0v; ~rUM2Yy!zmkh)3&U|u!=T(zyv,MHJv"nDH>OJ`t(@mil461d_B'Uo|'nMwlKe0Mv=kvV?Nh@>Hb<3s_z2jYgZhPb@?Wi^x1a~Hplz1.zH Subject: RELENG_7 - has mergemaster changed logic since 7.2-RELEASE? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 20:51:03 -0000 Ok, this is strange. I just upgraded from 7.2-prerelease (as of 20090401) to 7.2-stable as of today, using csup and building world. As part of that process I did (as I always do) 'mergemaster -iU' after the 'make installworld' step. A few files on my machines are modified by me, and thus should nevber be upgraded: /etc/dhclient.conf /etc/motd (mergemeaster will usually ask about this - this time it did not, it claimed it wasn't user modified, huh?) /etc/profile /root/.profile /etc/passwd (mergemaster sked about it, I pressed 'd', but it was still upgraded, ugh!) /etc/group (mergemaster sked about it, I pressed 'd', but it was still upgraded, ugh!) It can be more files, I haven't found out yet. Has anyone else seen this? I am upgrading my next machine, this time I'll have backups and keep better notes. -- Regards, Torfinn Ingolfsen From owner-freebsd-stable@FreeBSD.ORG Mon May 4 21:05:02 2009 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7BBDC1065670 for ; Mon, 4 May 2009 21:05:02 +0000 (UTC) (envelope-from josh.carroll@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.30]) by mx1.freebsd.org (Postfix) with ESMTP id 36FD58FC15 for ; Mon, 4 May 2009 21:05:02 +0000 (UTC) (envelope-from josh.carroll@gmail.com) Received: by yw-out-2324.google.com with SMTP id 9so2521051ywe.13 for ; Mon, 04 May 2009 14:05:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:date:message-id :subject:from:to:content-type:content-transfer-encoding; bh=eeMIxY6t17OPn9wGHwrYTMgX/bfTJ5V7fIwlWWasWEQ=; b=Xa5o9Qk4veXAIy87CDvY+I0HqY5Bq3kNKW0CFqUCuM1rbPu/xdjkIDNXTMWqb6nmXF dUaEfc/v+QcVd8SV3JzAC0DT3zAiP4aMdX2fZr4WepOAbKBlF03kRQ3hMxVjHTn5LuAF 6tmtBETZ5PBbQ8AZ0f2oXhpzqPFsdie91f6wY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=OtB+OIiV1BZFR/p3CnV9HEWIbjWGjyssh47+Z413eKJPxpeeBTM8S3dP5BZgNkeykV Ykj2HyOeTf5p31BhLUvSU01YMbJJVyFet3+QoqfuZJUULtL4n2+FMZchmco2Tq/ArupI AljTp5KxnGQHSQGa3v7Io8fA/9vJ0ceGMcDGo= MIME-Version: 1.0 Received: by 10.100.140.15 with SMTP id n15mr13913809and.83.1241471101448; Mon, 04 May 2009 14:05:01 -0700 (PDT) Date: Mon, 4 May 2009 17:04:59 -0400 Message-ID: <8cb6106e0905041404m57361accg1b61b44d9bc39199@mail.gmail.com> From: Josh Carroll To: stable Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: ext2fs inode size fix never MFC'd X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: josh.carroll@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 21:05:02 -0000 I just noticed that the changes to the ext2 code to support inode sizes other than 128 was never MFC'd: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/gnu/fs/ext2fs/ext2_linux_ialloc.c?r1=1.25.8.1;sortby=date#diff I submitted a patch to this PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=124621&cat= Which was partially adopted (or at least the same idea was used) and committed to HEAD back in January, but the MFC after 2 weeks to RELENG_7 never happened, unfortunately. I was hoping this would make it into 7.1, and I seem to have noticed this too late for 7.2-RELEASE but can someone get this merged into RELENG_7? Regards, Josh From owner-freebsd-stable@FreeBSD.ORG Mon May 4 21:07:17 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6699E1065673 for ; Mon, 4 May 2009 21:07:17 +0000 (UTC) (envelope-from sonic2000gr@gmail.com) Received: from mail-ew0-f171.google.com (mail-ew0-f171.google.com [209.85.219.171]) by mx1.freebsd.org (Postfix) with ESMTP id B74D88FC1E for ; Mon, 4 May 2009 21:07:16 +0000 (UTC) (envelope-from sonic2000gr@gmail.com) Received: by ewy19 with SMTP id 19so4172615ewy.43 for ; Mon, 04 May 2009 14:07:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=4n9sGiaXP/DApEN/YVrTtJ2AEMcLyT6f9DVuIaNTjKw=; b=YFwO3HDPNjDUeMV2lmUCUIgTRu3sOheS/pRIC2KvmvNsCPX1BIbN14f1VT/vPR7tG2 gIePRCK9HFUfVYZNBh5DUJ2yCQ+NzzZ+n3MnvumL4iJrOhHhtTpE3cSLaAQWazigZyUN T2V8g3f+4a84WCL/ogMIaZWas6gJpNeZWrv70= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=eCMzJo5x4e5ugOuJ4aX2+hOOR2sTvSyDmMOaWdfNDbAyjdiL9AnPoB2GXa14kDEDmT gwQDtkbjZkskZXiErIk2hTdR2H0X5RupVZ0pfuGfG3MWuKKUR/Dq0SujnLTPPduxwizZ cZowDIn2C+gWQotUPm+18HhOQpv7gyXGcujm4= Received: by 10.216.20.74 with SMTP id o52mr1965500weo.147.1241471235512; Mon, 04 May 2009 14:07:15 -0700 (PDT) Received: from atlantis.dyndns.org (athedsl-4471802.home.otenet.gr [94.71.123.234]) by mx.google.com with ESMTPS id 28sm174631eyg.58.2009.05.04.14.07.14 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 04 May 2009 14:07:14 -0700 (PDT) Message-ID: <49FF5901.600@gmail.com> Date: Tue, 05 May 2009 00:07:13 +0300 From: Manolis Kiagias User-Agent: Thunderbird 2.0.0.21 (X11/20090414) MIME-Version: 1.0 To: Torfinn Ingolfsen References: <20090504225012.392fa49f.torfinn.ingolfsen@broadpark.no> In-Reply-To: <20090504225012.392fa49f.torfinn.ingolfsen@broadpark.no> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: RELENG_7 - has mergemaster changed logic since 7.2-RELEASE? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 21:07:20 -0000 Torfinn Ingolfsen wrote: > Ok, this is strange. > > I just upgraded from 7.2-prerelease (as of 20090401) to 7.2-stable as > of today, using csup and building world. > > As part of that process I did (as I always do) 'mergemaster -iU' after > the 'make installworld' step. > A few files on my machines are modified by me, and thus should nevber > be upgraded: > /etc/dhclient.conf > /etc/motd (mergemeaster will usually ask about this - this time it did > not, it claimed it wasn't user modified, huh?) > /etc/profile > /root/.profile > /etc/passwd (mergemaster sked about it, I pressed 'd', but it was still > upgraded, ugh!) > /etc/group (mergemaster sked about it, I pressed 'd', but it was still > upgraded, ugh!) > > It can be more files, I haven't found out yet. > > Has anyone else seen this? > > I am upgrading my next machine, this time I'll have backups and keep > better notes. > I always use -iU too. I've lost motd, passwd, group and master.passwd During mergemaster -p I was asked to merge changes to some of these, and still they were replaced with the newer versions. I don't know what went wrong but have restored them from backup. (I always tar /etc before a source upgrade). Upgrading another system using freebsd-update did not cause any problem. From owner-freebsd-stable@FreeBSD.ORG Mon May 4 21:32:06 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E798C106564A for ; Mon, 4 May 2009 21:32:06 +0000 (UTC) (envelope-from vince@unsane.co.uk) Received: from unsane.co.uk (unsane-pt.tunnel.tserv5.lon1.ipv6.he.net [IPv6:2001:470:1f08:110::2]) by mx1.freebsd.org (Postfix) with ESMTP id 541A08FC08 for ; Mon, 4 May 2009 21:32:06 +0000 (UTC) (envelope-from vince@unsane.co.uk) Received: from vhoffman-macbook.local ([IPv6:2001:470:9099:0:214:51ff:feed:712d]) (authenticated bits=0) by unsane.co.uk (8.14.3/8.14.0) with ESMTP id n44LX0Qu067074 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 4 May 2009 22:33:01 +0100 (BST) (envelope-from vince@unsane.co.uk) Message-ID: <49FF5D9C.5060409@unsane.co.uk> Date: Mon, 04 May 2009 22:26:52 +0100 From: Vincent Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-GB; rv:1.9.1b3pre) Gecko/20081204 Thunderbird/3.0b1 MIME-Version: 1.0 To: Torfinn Ingolfsen References: <20090504225012.392fa49f.torfinn.ingolfsen@broadpark.no> In-Reply-To: <20090504225012.392fa49f.torfinn.ingolfsen@broadpark.no> X-Enigmail-Version: 0.96a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: RELENG_7 - has mergemaster changed logic since 7.2-RELEASE? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 21:32:07 -0000 On 4/5/09 21:50, Torfinn Ingolfsen wrote: > Ok, this is strange. > > I just upgraded from 7.2-prerelease (as of 20090401) to 7.2-stable as > of today, using csup and building world. > > As part of that process I did (as I always do) 'mergemaster -iU' after > the 'make installworld' step. > A few files on my machines are modified by me, and thus should nevber > be upgraded: > /etc/dhclient.conf > /etc/motd (mergemeaster will usually ask about this - this time it did > not, it claimed it wasn't user modified, huh?) > /etc/profile > /root/.profile > /etc/passwd (mergemaster sked about it, I pressed 'd', but it was still > upgraded, ugh!) > /etc/group (mergemaster sked about it, I pressed 'd', but it was still > upgraded, ugh!) > > It can be more files, I haven't found out yet. > > Has anyone else seen this? > > I am upgrading my next machine, this time I'll have backups and keep > better notes. > Not that its a cure but are master.passwd and group backups in /var/backups any help to you in this case? Vince From owner-freebsd-stable@FreeBSD.ORG Mon May 4 21:41:15 2009 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4B576106566B for ; Mon, 4 May 2009 21:41:15 +0000 (UTC) (envelope-from korvus@comcast.net) Received: from mx04.pub.collaborativefusion.com (mx04.pub.collaborativefusion.com [206.210.72.84]) by mx1.freebsd.org (Postfix) with ESMTP id 113D28FC17 for ; Mon, 4 May 2009 21:41:14 +0000 (UTC) (envelope-from korvus@comcast.net) Received: from [192.168.2.164] ([206.210.89.202]) by mx04.pub.collaborativefusion.com (StrongMail Enterprise 4.1.1.4(4.1.1.4-47689)); Mon, 04 May 2009 17:39:03 -0400 X-VirtualServerGroup: Default X-MailingID: 00000::00000::00000::00000::::16 X-SMHeaderMap: mid="X-MailingID" X-Destination-ID: freebsd-stable@FreeBSD.org X-SMFBL: ZnJlZWJzZC1zdGFibGVARnJlZUJTRC5vcmc= Message-ID: <49FF60F9.6010303@comcast.net> Date: Mon, 04 May 2009 17:41:13 -0400 From: Steve Polyack User-Agent: Thunderbird 2.0.0.21 (X11/20090327) MIME-Version: 1.0 To: Robert Noland References: <49FF28BC.5080304@comcast.net> <1241460816.1788.22.camel@balrog.2hip.net> <49FF387F.1080203@comcast.net> <1241464053.1788.32.camel@balrog.2hip.net> <49FF4857.4070904@comcast.net> <1241467827.1788.43.camel@balrog.2hip.net> <49FF51BC.5050104@comcast.net> <1241470167.1788.45.camel@balrog.2hip.net> In-Reply-To: <1241470167.1788.45.camel@balrog.2hip.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-x11 , freebsd-stable Subject: Re: Radeon 9250 DRM in 7.2-RELEASE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 21:41:15 -0000 Robert Noland wrote: > ok, how about this one... If this doesn't do it, then we need to start > digging... > > robert. > > No change when using this patch either. I've also updated to the latest BIOS and have ensured that the onboard Intel adapter is as disabled as it can get. I can provide you some photos of the screen behavior if you think it may help. Thanks again so far! From owner-freebsd-stable@FreeBSD.ORG Mon May 4 21:53:24 2009 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3CDAA106564A; Mon, 4 May 2009 21:53:24 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id D66B78FC1B; Mon, 4 May 2009 21:53:23 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from [192.168.1.4] (adsl-19-214-20.bna.bellsouth.net [68.19.214.20]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id n44LrHZD062713 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 May 2009 17:53:17 -0400 (EDT) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Steve Polyack In-Reply-To: <49FF60F9.6010303@comcast.net> References: <49FF28BC.5080304@comcast.net> <1241460816.1788.22.camel@balrog.2hip.net> <49FF387F.1080203@comcast.net> <1241464053.1788.32.camel@balrog.2hip.net> <49FF4857.4070904@comcast.net> <1241467827.1788.43.camel@balrog.2hip.net> <49FF51BC.5050104@comcast.net> <1241470167.1788.45.camel@balrog.2hip.net> <49FF60F9.6010303@comcast.net> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-2CqOy1dmfQAHqvex7lr0" Organization: FreeBSD Date: Mon, 04 May 2009 16:53:03 -0500 Message-Id: <1241473983.1788.48.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1.1 FreeBSD GNOME Team Port X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00, MIME_QP_LONG_LINE,RDNS_DYNAMIC autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: freebsd-x11 , freebsd-stable Subject: Re: Radeon 9250 DRM in 7.2-RELEASE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 21:53:24 -0000 --=-2CqOy1dmfQAHqvex7lr0 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 2009-05-04 at 17:41 -0400, Steve Polyack wrote: > Robert Noland wrote: > > ok, how about this one... If this doesn't do it, then we need to start > > digging... > > > > robert. > > > > =20 >=20 > No change when using this patch either. I've also updated to the latest=20 > BIOS and have ensured that the onboard Intel adapter is as disabled as=20 > it can get. I can provide you some photos of the screen behavior if you=20 > think it may help. Thanks again so far! Ok, so to start with, we need an xorg log and conf. If you kldload radeon.ko before starting X then you can set hw.dri.0.debug=3D1 which will dump a bunch of drm debugging into /var/log/messages. That would be useful. Also having a look at "memcontrol list" might be a good idea. robert. > _______________________________________________ > freebsd-x11@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-x11 > To unsubscribe, send any mail to "freebsd-x11-unsubscribe@freebsd.org" --=20 Robert Noland FreeBSD --=-2CqOy1dmfQAHqvex7lr0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEABECAAYFAkn/Y78ACgkQM4TrQ4qfROMp2QCfaKExZDuA4nsPIdP6tOVgPC1B Vj4AoIYG7bERwu0Y51Iimr4Vls+EIVBn =h2Xz -----END PGP SIGNATURE----- --=-2CqOy1dmfQAHqvex7lr0-- From owner-freebsd-stable@FreeBSD.ORG Mon May 4 22:29:20 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5AD7B106564A for ; Mon, 4 May 2009 22:29:20 +0000 (UTC) (envelope-from torfinn.ingolfsen@broadpark.no) Received: from osl1smout1.broadpark.no (osl1smout1.broadpark.no [80.202.4.58]) by mx1.freebsd.org (Postfix) with ESMTP id 7C9908FC08 for ; Mon, 4 May 2009 22:29:19 +0000 (UTC) (envelope-from torfinn.ingolfsen@broadpark.no) MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_ViuTdbt408rA3J9o9Nv7wA)" Received: from osl1sminn1.broadpark.no ([80.202.4.59]) by osl1smout1.broadpark.no (Sun Java(tm) System Messaging Server 6.3-3.01 (built Jul 12 2007; 32bit)) with ESMTP id <0KJ500A2254UO860@osl1smout1.broadpark.no> for freebsd-stable@freebsd.org; Tue, 05 May 2009 00:29:18 +0200 (CEST) Received: from kg-v2.kg4.no ([80.202.83.38]) by osl1sminn1.broadpark.no (Sun Java(tm) System Messaging Server 6.3-3.01 (built Jul 12 2007; 32bit)) with SMTP id <0KJ500K27549TRA0@osl1sminn1.broadpark.no> for freebsd-stable@freebsd.org; Tue, 05 May 2009 00:29:18 +0200 (CEST) Sun-Java-System-SMTP-Warning: Lines longer than SMTP allows found and truncated. Date: Tue, 05 May 2009 00:28:56 +0200 From: Torfinn Ingolfsen To: freebsd-stable@freebsd.org Message-id: <20090505002856.75fe1800.torfinn.ingolfsen@broadpark.no> In-reply-to: <20090504225012.392fa49f.torfinn.ingolfsen@broadpark.no> References: <20090504225012.392fa49f.torfinn.ingolfsen@broadpark.no> X-Mailer: Sylpheed 2.6.0 (GTK+ 2.16.1; amd64-portbld-freebsd7.2) X-Face: "t9w2,-X@O^I`jVW\sonI3.,36KBLZE*AL[y9lL[PyFD*r_S:dIL9c[8Y>V42R0"!"yb_zN,f#%.[PYYNq; m"_0v; ~rUM2Yy!zmkh)3&U|u!=T(zyv,MHJv"nDH>OJ`t(@mil461d_B'Uo|'nMwlKe0Mv=kvV?Nh@>Hb<3s_z2jYgZhPb@?Wi^x1a~Hplz1.zH Subject: Re: RELENG_7 - has mergemaster changed logic since 7.2-RELEASE? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 22:29:20 -0000 This is a multi-part message in MIME format. --Boundary_(ID_ViuTdbt408rA3J9o9Nv7wA) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT On Mon, 04 May 2009 22:50:12 +0200 Torfinn Ingolfsen wrote: > I am upgrading my next machine, this time I'll have backups and keep > better notes. Ok, this machine was last upgraded a few days ago (20090501) so there wasn't a lot of changes. This time, only /etc/motd got hit. Here are the files: root@kg-quiet# ls -l /etc/motd_ti /etc/motd -rw-r--r-- 1 root wheel 1112 May 4 23:59 /etc/motd -rw-r--r-- 1 root wheel 792 May 1 21:52 /etc/motd_ti The file named motd_ti is my backup. Before this installation it was a copy of the file motd. Howcan mergemaster say that these two files are the same, or that /etc/motd wasn't user modified? script output from 'mergemaster -p' and 'mergemaster -iU' attached in case it helps. (I got this tip in mail) HTH -- Regards, Torfinn Ingolfsen --Boundary_(ID_ViuTdbt408rA3J9o9Nv7wA) Content-type: text/plain; name=mergemaster-p.txt Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=mergemaster-p.txt Script started on Mon May 4 23:49:30 2009 root@kg-quiet# mergemaster -p *** Creating the temporary root environment in /var/tmp/temproot *** /var/tmp/temproot ready for use *** Creating and populating directory structure in /var/tmp/temproot *** Beginning comparison *** Temp ./etc/master.passwd and installed have the same CVS Id, deleting *** Temp ./etc/group and installed have the same CVS Id, deleting *** Comparison complete *** Saving mtree database for future upgrades Do you wish to delete what is left of /var/tmp/temproot? [no] yes *** /var/tmp/temproot has been deleted *** Comparing make variables *** From /etc/make.conf *** From /usr/src/share/examples/etc/make.conf NO_PROFILE= true # Avoid compiling profiled libraries * No example variable with this name PERL_VERSION=5.8.9 * No example variable with this name root@kg-quiet# ^D Script done on Mon May 4 23:49:44 2009 --Boundary_(ID_ViuTdbt408rA3J9o9Nv7wA) Content-type: text/plain; name=mergemaster-iU.txt Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=mergemaster-iU.txt Script started on Mon May 4 23:54:21 2009 root@kg-quiet# mergemaster -iU *** Creating the temporary root environment in /var/tmp/temproot *** /var/tmp/temproot ready for use *** Creating and populating directory structure in /var/tmp/temproot cd /usr/src/etc; MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=amd64 MACHINE=amd64 CPUTYPE= GROFF_BIN_PATH=/usr/obj/usr/src/tmp/legacy/usr/bin GROFF_FONT_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/groff_font GROFF_TMAC_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/tmac PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin make distrib-dirs mtree -eU -f /usr/src/etc/mtree/BSD.root.dist -p /var/tmp/temproot/ ./bin missing (created) ./boot missing (created) ./boot/defaults missing (created) ./boot/firmware missing (created) ./boot/kernel missing (created) ./boot/modules missing (created) ./boot/zfs missing (created) ./dev missing (created) ./etc missing (created) ./etc/X11 missing (created) ./etc/bluetooth missing (created) ./etc/defaults missing (created) ./etc/gnats missing (created) ./etc/gss missing (created) ./etc/isdn missing (created) ./etc/mail missing (created) ./etc/mtree missing (created) ./etc/ntp missing (created) ./etc/pam.d missing (created) ./etc/periodic missing (created) ./etc/periodic/daily missing (created) ./etc/periodic/monthly missing (created) ./etc/periodic/security missing (created) ./etc/periodic/weekly missing (created) ./etc/ppp missing (created) ./etc/rc.d missing (created) ./etc/security missing (created) ./etc/skel missing (created) ./etc/ssh missing (created) ./etc/ssl missing (created) ./etc/zfs missing (created) ./lib missing (created) ./lib/geom missing (created) ./libexec missing (created) ./media missing (created) ./mnt missing (created) ./proc missing (created) ./rescue missing (created) ./root missing (created) ./sbin missing (created) ./tmp missing (created) ./usr missing (created) ./var missing (created) mtree -eU -f /usr/src/etc/mtree/BSD.var.dist -p /var/tmp/temproot/var ./account missing (created) ./at missing (created) ./at/jobs missing (created) ./at/spool missing (created) ./audit missing (created) ./backups missing (created) ./crash missing (created) ./cron missing (created) ./cron/tabs missing (created) ./db missing (created) ./db/entropy missing (created) ./db/freebsd-update missing (created) ./db/ipf missing (created) ./db/pkg missing (created) ./db/ports missing (created) ./db/portsnap missing (created) ./empty missing (created) ./games missing (created) ./heimdal missing (created) ./log missing (created) ./mail missing (created) ./msgs missing (created) ./named missing (created) ./preserve missing (created) ./run missing (created) ./run/named missing (created) ./run/ppp missing (created) ./rwho missing (created) ./spool missing (created) ./spool/lock missing (created) ./spool/lpd missing (created) ./spool/mqueue missing (created) ./spool/opielocks missing (created) ./spool/output missing (created) ./spool/output/lpd missing (created) ./tmp missing (created) ./tmp/vi.recover missing (created) ./yp missing (created) mtree -eU -f /usr/src/etc/mtree/BSD.usr.dist -p /var/tmp/temproot/usr ./bin missing (created) ./games missing (created) ./include missing (created) ./lib missing (created) ./lib/aout missing (created) ./lib/compat missing (created) ./lib/compat/aout missing (created) ./lib/dtrace missing (created) ./lib/engines missing (created) ./libdata missing (created) ./libdata/gcc missing (created) ./libdata/ldscripts missing (created) ./libdata/lint missing (created) ./libexec missing (created) ./libexec/lpr missing (created) ./libexec/lpr/ru missing (created) ./libexec/sendmail missing (created) ./libexec/sm.bin missing (created) ./local missing (created) ./obj missing (created) ./sbin missing (created) ./share missing (created) ./share/calendar missing (created) ./share/calendar/de_DE.ISO8859-1 missing (created) ./share/calendar/fr_FR.ISO8859-1 missing (created) ./share/calendar/hr_HR.ISO8859-2 missing (created) ./share/calendar/hu_HU.ISO8859-2 missing (created) ./share/calendar/ru_RU.KOI8-R missing (created) ./share/calendar/uk_UA.KOI8-U missing (created) ./share/dict missing (created) ./share/doc missing (created) ./share/doc/IPv6 missing (created) ./share/doc/atm missing (created) ./share/doc/bind9 missing (created) ./share/doc/bind9/arm missing (created) ./share/doc/bind9/misc missing (created) ./share/doc/legal missing (created) ./share/doc/legal/intel_ipw missing (created) ./share/doc/legal/intel_iwi missing (created) ./share/doc/legal/intel_wpi missing (created) ./share/doc/ncurses missing (created) ./share/doc/ntp missing (created) ./share/doc/papers missing (created) ./share/doc/psd missing (created) ./share/doc/psd/01.cacm missing (created) ./share/doc/psd/02.implement missing (created) ./share/doc/psd/03.iosys missing (created) ./share/doc/psd/04.uprog missing (created) ./share/doc/psd/05.sysman missing (created) ./share/doc/psd/06.Clang missing (created) ./share/doc/psd/12.make missing (created) ./share/doc/psd/13.rcs missing (created) ./share/doc/psd/15.yacc missing (created) ./share/doc/psd/16.lex missing (created) ./share/doc/psd/17.m4 missing (created) ./share/doc/psd/18.gprof missing (created) ./share/doc/psd/20.ipctut missing (created) ./share/doc/psd/21.ipc missing (created) ./share/doc/psd/22.rpcgen missing (created) ./share/doc/psd/23.rpc missing (created) ./share/doc/psd/24.xdr missing (created) ./share/doc/psd/25.xdrrfc missing (created) ./share/doc/psd/26.rpcrfc missing (created) ./share/doc/psd/27.nfsrfc missing (created) ./share/doc/psd/28.cvs missing (created) ./share/doc/smm missing (created) ./share/doc/smm/01.setup missing (created) ./share/doc/smm/02.config missing (created) ./share/doc/smm/03.fsck missing (created) ./share/doc/smm/04.quotas missing (created) ./share/doc/smm/05.fastfs missing (created) ./share/doc/smm/06.nfs missing (created) ./share/doc/smm/07.lpd missing (created) ./share/doc/smm/08.sendmailop missing (created) ./share/doc/smm/11.timedop missing (created) ./share/doc/smm/12.timed missing (created) ./share/doc/smm/18.net missing (created) ./share/doc/usd missing (created) ./share/doc/usd/04.csh missing (created) ./share/doc/usd/07.mail missing (created) ./share/doc/usd/10.exref missing (created) ./share/doc/usd/11.edit missing (created) ./share/doc/usd/12.vi missing (created) ./share/doc/usd/13.viref missing (created) ./share/doc/usd/18.msdiffs missing (created) ./share/doc/usd/19.memacros missing (created) ./share/doc/usd/20.meref missing (created) ./share/doc/usd/21.troff missing (created) ./share/doc/usd/22.trofftut missing (created) ./share/examples missing (created) ./share/examples/BSD_daemon missing (created) ./share/examples/FreeBSD_version missing (created) ./share/examples/IPv6 missing (created) ./share/examples/bc missing (created) ./share/examples/bootforth missing (created) ./share/examples/cvs missing (created) ./share/examples/cvs/contrib missing (created) ./share/examples/cvsup missing (created) ./share/examples/dialog missing (created) ./share/examples/diskless missing (created) ./share/examples/drivers missing (created) ./share/examples/etc missing (created) ./share/examples/etc/defaults missing (created) ./share/examples/find_interface missing (created) ./share/examples/hostapd missing (created) ./share/examples/ibcs2 missing (created) ./share/examples/ipfilter missing (created) ./share/examples/ipfw missing (created) ./share/examples/iscsi missing (created) ./share/examples/isdn missing (created) ./share/examples/isdn/contrib missing (created) ./share/examples/isdn/i4brunppp missing (created) ./share/examples/isdn/v21 missing (created) ./share/examples/kld missing (created) ./share/examples/kld/cdev missing (created) ./share/examples/kld/cdev/module missing (created) ./share/examples/kld/cdev/test missing (created) ./share/examples/kld/dyn_sysctl missing (created) ./share/examples/kld/syscall missing (created) ./share/examples/kld/syscall/module missing (created) ./share/examples/kld/syscall/test missing (created) ./share/examples/libdialog missing (created) ./share/examples/libvgl missing (created) ./share/examples/mdoc missing (created) ./share/examples/netgraph missing (created) ./share/examples/netgraph/bluetooth missing (created) ./share/examples/nwclient missing (created) ./share/examples/perfmon missing (created) ./share/examples/pf missing (created) ./share/examples/portal missing (created) ./share/examples/ppi missing (created) ./share/examples/ppp missing (created) ./share/examples/pppd missing (created) ./share/examples/printing missing (created) ./share/examples/scsi_target missing (created) ./share/examples/ses missing (created) ./share/examples/ses/getencstat missing (created) ./share/examples/ses/sesd missing (created) ./share/examples/ses/setencstat missing (created) ./share/examples/ses/setobjstat missing (created) ./share/examples/ses/srcs missing (created) ./share/examples/slattach missing (created) ./share/examples/sliplogin missing (created) ./share/examples/smbfs missing (created) ./share/examples/smbfs/print missing (created) ./share/examples/startslip missing (created) ./share/examples/sunrpc missing (created) ./share/examples/sunrpc/dir missing (created) ./share/examples/sunrpc/msg missing (created) ./share/examples/sunrpc/sort missing (created) ./share/examples/tcsh missing (created) ./share/examples/wpa_supplicant missing (created) ./share/games missing (created) ./share/games/fortune missing (created) ./share/groff_font missing (created) ./share/groff_font/devX100 missing (created) ./share/groff_font/devX100-12 missing (created) ./share/groff_font/devX75 missing (created) ./share/groff_font/devX75-12 missing (created) ./share/groff_font/devascii missing (created) ./share/groff_font/devcp1047 missing (created) ./share/groff_font/devdvi missing (created) ./share/groff_font/devhtml missing (created) ./share/groff_font/devkoi8-r missing (created) ./share/groff_font/devlatin1 missing (created) ./share/groff_font/devlbp missing (created) ./share/groff_font/devlj4 missing (created) ./share/groff_font/devps missing (created) ./share/groff_font/devutf8 missing (created) ./share/info missing (created) ./share/isdn missing (created) ./share/locale missing (created) ./share/locale/UTF-8 missing (created) ./share/locale/af_ZA.ISO8859-1 missing (created) ./share/locale/af_ZA.ISO8859-15 missing (created) ./share/locale/af_ZA.UTF-8 missing (created) ./share/locale/am_ET.UTF-8 missing (created) ./share/locale/be_BY.CP1131 missing (created) ./share/locale/be_BY.CP1251 missing (created) ./share/locale/be_BY.ISO8859-5 missing (created) ./share/locale/be_BY.UTF-8 missing (created) ./share/locale/bg_BG.CP1251 missing (created) ./share/locale/bg_BG.UTF-8 missing (created) ./share/locale/ca_ES.ISO8859-1 missing (created) ./share/locale/ca_ES.ISO8859-15 missing (created) ./share/locale/ca_ES.UTF-8 missing (created) ./share/locale/cs_CZ.ISO8859-2 missing (created) ./share/locale/cs_CZ.UTF-8 missing (created) ./share/locale/da_DK.ISO8859-1 missing (created) ./share/locale/da_DK.ISO8859-15 missing (created) ./share/locale/da_DK.UTF-8 missing (created) ./share/locale/de_AT.ISO8859-1 missing (created) ./share/locale/de_AT.ISO8859-15 missing (created) ./share/locale/de_AT.UTF-8 missing (created) ./share/locale/de_CH.ISO8859-1 missing (created) ./share/locale/de_CH.ISO8859-15 missing (created) ./share/locale/de_CH.UTF-8 missing (created) ./share/locale/de_DE.ISO8859-1 missing (created) ./share/locale/de_DE.ISO8859-15 missing (created) ./share/locale/de_DE.UTF-8 missing (created) ./share/locale/el_GR.ISO8859-7 missing (created) ./share/locale/el_GR.UTF-8 missing (created) ./share/locale/en_AU.ISO8859-1 missing (created) ./share/locale/en_AU.ISO8859-15 missing (created) ./share/locale/en_AU.US-ASCII missing (created) ./share/locale/en_AU.UTF-8 missing (created) ./share/locale/en_CA.ISO8859-1 missing (created) ./share/locale/en_CA.ISO8859-15 missing (created) ./share/locale/en_CA.US-ASCII missing (created) ./share/locale/en_CA.UTF-8 missing (created) ./share/locale/en_GB.ISO8859-1 missing (created) ./share/locale/en_GB.ISO8859-15 missing (created) ./share/locale/en_GB.US-ASCII missing (created) ./share/locale/en_GB.UTF-8 missing (created) ./share/locale/en_IE.UTF-8 missing (created) ./share/locale/en_NZ.ISO8859-1 missing (created) ./share/locale/en_NZ.ISO8859-15 missing (created) ./share/locale/en_NZ.US-ASCII missing (created) ./share/locale/en_NZ.UTF-8 missing (created) ./share/locale/en_US.ISO8859-1 missing (created) ./share/locale/en_US.ISO8859-15 missing (created) ./share/locale/en_US.US-ASCII missing (created) ./share/locale/en_US.UTF-8 missing (created) ./share/locale/es_ES.ISO8859-1 missing (created) ./share/locale/es_ES.ISO8859-15 missing (created) ./share/locale/es_ES.UTF-8 missing (created) ./share/locale/et_EE.ISO8859-15 missing (created) ./share/locale/et_EE.UTF-8 missing (created) ./share/locale/eu_ES.ISO8859-1 missing (created) ./share/locale/eu_ES.ISO8859-15 missing (created) ./share/locale/eu_ES.UTF-8 missing (created) ./share/locale/fi_FI.ISO8859-1 missing (created) ./share/locale/fi_FI.ISO8859-15 missing (created) ./share/locale/fi_FI.UTF-8 missing (created) ./share/locale/fr_BE.ISO8859-1 missing (created) ./share/locale/fr_BE.ISO8859-15 missing (created) ./share/locale/fr_BE.UTF-8 missing (created) ./share/locale/fr_CA.ISO8859-1 missing (created) ./share/locale/fr_CA.ISO8859-15 missing (created) ./share/locale/fr_CA.UTF-8 missing (created) ./share/locale/fr_CH.ISO8859-1 missing (created) ./share/locale/fr_CH.ISO8859-15 missing (created) ./share/locale/fr_CH.UTF-8 missing (created) ./share/locale/fr_FR.ISO8859-1 missing (created) ./share/locale/fr_FR.ISO8859-15 missing (created) ./share/locale/fr_FR.UTF-8 missing (created) ./share/locale/he_IL.UTF-8 missing (created) ./share/locale/hi_IN.ISCII-DEV missing (created) ./share/locale/hr_HR.ISO8859-2 missing (created) ./share/locale/hr_HR.UTF-8 missing (created) ./share/locale/hu_HU.ISO8859-2 missing (created) ./share/locale/hu_HU.UTF-8 missing (created) ./share/locale/hy_AM.ARMSCII-8 missing (created) ./share/locale/hy_AM.UTF-8 missing (created) ./share/locale/is_IS.ISO8859-1 missing (created) ./share/locale/is_IS.ISO8859-15 missing (created) ./share/locale/is_IS.UTF-8 missing (created) ./share/locale/it_CH.ISO8859-1 missing (created) ./share/locale/it_CH.ISO8859-15 missing (created) ./share/locale/it_CH.UTF-8 missing (created) ./share/locale/it_IT.ISO8859-1 missing (created) ./share/locale/it_IT.ISO8859-15 missing (created) ./share/locale/it_IT.UTF-8 missing (created) ./share/locale/ja_JP.SJIS missing (created) ./share/locale/ja_JP.UTF-8 missing (created) ./share/locale/ja_JP.eucJP missing (created) ./share/locale/kk_KZ.PT154 missing (created) ./share/locale/kk_KZ.UTF-8 missing (created) ./share/locale/ko_KR.CP949 missing (created) ./share/locale/ko_KR.UTF-8 missing (created) ./share/locale/ko_KR.eucKR missing (created) ./share/locale/la_LN.ISO8859-1 missing (created) ./share/locale/la_LN.ISO8859-15 missing (created) ./share/locale/la_LN.ISO8859-2 missing (created) ./share/locale/la_LN.ISO8859-4 missing (created) ./share/locale/la_LN.US-ASCII missing (created) ./share/locale/lt_LT.ISO8859-13 missing (created) ./share/locale/lt_LT.ISO8859-4 missing (created) ./share/locale/lt_LT.UTF-8 missing (created) ./share/locale/mn_MN.UTF-8 missing (created) ./share/locale/nb_NO.ISO8859-1 missing (created) ./share/locale/nb_NO.ISO8859-15 missing (created) ./share/locale/nb_NO.UTF-8 missing (created) ./share/locale/nl_BE.ISO8859-1 missing (created) ./share/locale/nl_BE.ISO8859-15 missing (created) ./share/locale/nl_BE.UTF-8 missing (created) ./share/locale/nl_NL.ISO8859-1 missing (created) ./share/locale/nl_NL.ISO8859-15 missing (created) ./share/locale/nl_NL.UTF-8 missing (created) ./share/locale/nn_NO.ISO8859-1 missing (created) ./share/locale/nn_NO.ISO8859-15 missing (created) ./share/locale/nn_NO.UTF-8 missing (created) ./share/locale/no_NO.ISO8859-1 missing (created) ./share/locale/no_NO.ISO8859-15 missing (created) ./share/locale/no_NO.UTF-8 missing (created) ./share/locale/pl_PL.ISO8859-2 missing (created) ./share/locale/pl_PL.UTF-8 missing (created) ./share/locale/pt_BR.ISO8859-1 missing (created) ./share/locale/pt_BR.UTF-8 missing (created) ./share/locale/pt_PT.ISO8859-1 missing (created) ./share/locale/pt_PT.ISO8859-15 missing (created) ./share/locale/pt_PT.UTF-8 missing (created) ./share/locale/ro_RO.ISO8859-2 missing (created) ./share/locale/ro_RO.UTF-8 missing (created) ./share/locale/ru_RU.CP1251 missing (created) ./share/locale/ru_RU.CP866 missing (created) ./share/locale/ru_RU.ISO8859-5 missing (created) ./share/locale/ru_RU.KOI8-R missing (created) ./share/locale/ru_RU.UTF-8 missing (created) ./share/locale/sk_SK.ISO8859-2 missing (created) ./share/locale/sk_SK.UTF-8 missing (created) ./share/locale/sl_SI.ISO8859-2 missing (created) ./share/locale/sl_SI.UTF-8 missing (created) ./share/locale/sr_YU.ISO8859-2 missing (created) ./share/locale/sr_YU.ISO8859-5 missing (created) ./share/locale/sr_YU.UTF-8 missing (created) ./share/locale/sv_SE.ISO8859-1 missing (created) ./share/locale/sv_SE.ISO8859-15 missing (created) ./share/locale/sv_SE.UTF-8 missing (created) ./share/locale/tr_TR.ISO8859-9 missing (created) ./share/locale/tr_TR.UTF-8 missing (created) ./share/locale/uk_UA.CP1251 missing (created) ./share/locale/uk_UA.ISO8859-5 missing (created) ./share/locale/uk_UA.KOI8-U missing (created) ./share/locale/uk_UA.UTF-8 missing (created) ./share/locale/zh_CN.GB18030 missing (created) ./share/locale/zh_CN.GB2312 missing (created) ./share/locale/zh_CN.GBK missing (created) ./share/locale/zh_CN.UTF-8 missing (created) ./share/locale/zh_CN.eucCN missing (created) ./share/locale/zh_HK.Big5HKSCS missing (created) ./share/locale/zh_HK.UTF-8 missing (created) ./share/locale/zh_TW.Big5 missing (created) ./share/locale/zh_TW.UTF-8 missing (created) ./share/man missing (created) ./share/man/cat1 missing (created) ./share/man/cat1aout missing (created) ./share/man/cat2 missing (created) ./share/man/cat3 missing (created) ./share/man/cat4 missing (created) ./share/man/cat4/amd64 missing (created) ./share/man/cat4/arm missing (created) ./share/man/cat4/i386 missing (created) ./share/man/cat4/powerpc missing (created) ./share/man/cat4/sparc64 missing (created) ./share/man/cat5 missing (created) ./share/man/cat6 missing (created) ./share/man/cat7 missing (created) ./share/man/cat8 missing (created) ./share/man/cat8/amd64 missing (created) ./share/man/cat8/i386 missing (created) ./share/man/cat8/powerpc missing (created) ./share/man/cat8/sparc64 missing (created) ./share/man/cat9 missing (created) ./share/man/en.ISO8859-1 missing (created) ./share/man/en.ISO8859-1/cat1 missing (created) ./share/man/en.ISO8859-1/cat1aout missing (created) ./share/man/en.ISO8859-1/cat2 missing (created) ./share/man/en.ISO8859-1/cat3 missing (created) ./share/man/en.ISO8859-1/cat4 missing (created) ./share/man/en.ISO8859-1/cat4/amd64 missing (created) ./share/man/en.ISO8859-1/cat4/arm missing (created) ./share/man/en.ISO8859-1/cat4/i386 missing (created) ./share/man/en.ISO8859-1/cat4/powerpc missing (created) ./share/man/en.ISO8859-1/cat4/sparc64 missing (created) ./share/man/en.ISO8859-1/cat5 missing (created) ./share/man/en.ISO8859-1/cat6 missing (created) ./share/man/en.ISO8859-1/cat7 missing (created) ./share/man/en.ISO8859-1/cat8 missing (created) ./share/man/en.ISO8859-1/cat8/amd64 missing (created) ./share/man/en.ISO8859-1/cat8/i386 missing (created) ./share/man/en.ISO8859-1/cat8/powerpc missing (created) ./share/man/en.ISO8859-1/cat8/sparc64 missing (created) ./share/man/en.ISO8859-1/cat9 missing (created) ./share/man/ja missing (created) ./share/man/ja/cat1 missing (created) ./share/man/ja/cat2 missing (created) ./share/man/ja/cat3 missing (created) ./share/man/ja/cat4 missing (created) ./share/man/ja/cat5 missing (created) ./share/man/ja/cat6 missing (created) ./share/man/ja/cat7 missing (created) ./share/man/ja/cat8 missing (created) ./share/man/ja/cat9 missing (created) ./share/man/ja/man1 missing (created) ./share/man/ja/man2 missing (created) ./share/man/ja/man3 missing (created) ./share/man/ja/man4 missing (created) ./share/man/ja/man5 missing (created) ./share/man/ja/man6 missing (created) ./share/man/ja/man7 missing (created) ./share/man/ja/man8 missing (created) ./share/man/ja/man9 missing (created) ./share/man/man1 missing (created) ./share/man/man1aout missing (created) ./share/man/man2 missing (created) ./share/man/man3 missing (created) ./share/man/man4 missing (created) ./share/man/man4/amd64 missing (created) ./share/man/man4/arm missing (created) ./share/man/man4/i386 missing (created) ./share/man/man4/powerpc missing (created) ./share/man/man4/sparc64 missing (created) ./share/man/man5 missing (created) ./share/man/man6 missing (created) ./share/man/man7 missing (created) ./share/man/man8 missing (created) ./share/man/man8/amd64 missing (created) ./share/man/man8/i386 missing (created) ./share/man/man8/powerpc missing (created) ./share/man/man8/sparc64 missing (created) ./share/man/man9 missing (created) ./share/me missing (created) ./share/misc missing (created) ./share/misc/fonts missing (created) ./share/mk missing (created) ./share/nls missing (created) ./share/nls/C missing (created) ./share/nls/af_ZA.ISO8859-1 missing (created) ./share/nls/af_ZA.ISO8859-15 missing (created) ./share/nls/af_ZA.UTF-8 missing (created) ./share/nls/am_ET.UTF-8 missing (created) ./share/nls/be_BY.CP1131 missing (created) ./share/nls/be_BY.CP1251 missing (created) ./share/nls/be_BY.ISO8859-5 missing (created) ./share/nls/be_BY.UTF-8 missing (created) ./share/nls/bg_BG.CP1251 missing (created) ./share/nls/bg_BG.UTF-8 missing (created) ./share/nls/ca_ES.ISO8859-1 missing (created) ./share/nls/ca_ES.ISO8859-15 missing (created) ./share/nls/ca_ES.UTF-8 missing (created) ./share/nls/cs_CZ.ISO8859-2 missing (created) ./share/nls/cs_CZ.UTF-8 missing (created) ./share/nls/da_DK.ISO8859-1 missing (created) ./share/nls/da_DK.ISO8859-15 missing (created) ./share/nls/da_DK.UTF-8 missing (created) ./share/nls/de_AT.ISO8859-1 missing (created) ./share/nls/de_AT.ISO8859-15 missing (created) ./share/nls/de_AT.UTF-8 missing (created) ./share/nls/de_CH.ISO8859-1 missing (created) ./share/nls/de_CH.ISO8859-15 missing (created) ./share/nls/de_CH.UTF-8 missing (created) ./share/nls/de_DE.ISO8859-1 missing (created) ./share/nls/de_DE.ISO8859-15 missing (created) ./share/nls/de_DE.UTF-8 missing (created) ./share/nls/el_GR.ISO8859-7 missing (created) ./share/nls/el_GR.UTF-8 missing (created) ./share/nls/en_AU.ISO8859-1 missing (created) ./share/nls/en_AU.ISO8859-15 missing (created) ./share/nls/en_AU.US-ASCII missing (created) ./share/nls/en_AU.UTF-8 missing (created) ./share/nls/en_CA.ISO8859-1 missing (created) ./share/nls/en_CA.ISO8859-15 missing (created) ./share/nls/en_CA.US-ASCII missing (created) ./share/nls/en_CA.UTF-8 missing (created) ./share/nls/en_GB.ISO8859-1 missing (created) ./share/nls/en_GB.ISO8859-15 missing (created) ./share/nls/en_GB.US-ASCII missing (created) ./share/nls/en_GB.UTF-8 missing (created) ./share/nls/en_IE.UTF-8 missing (created) ./share/nls/en_NZ.ISO8859-1 missing (created) ./share/nls/en_NZ.ISO8859-15 missing (created) ./share/nls/en_NZ.US-ASCII missing (created) ./share/nls/en_NZ.UTF-8 missing (created) ./share/nls/en_US.ISO8859-1 missing (created) ./share/nls/en_US.ISO8859-15 missing (created) ./share/nls/en_US.UTF-8 missing (created) ./share/nls/es_ES.ISO8859-1 missing (created) ./share/nls/es_ES.ISO8859-15 missing (created) ./share/nls/es_ES.UTF-8 missing (created) ./share/nls/et_EE.ISO8859-15 missing (created) ./share/nls/et_EE.UTF-8 missing (created) ./share/nls/fi_FI.ISO8859-1 missing (created) ./share/nls/fi_FI.ISO8859-15 missing (created) ./share/nls/fi_FI.UTF-8 missing (created) ./share/nls/fr_BE.ISO8859-1 missing (created) ./share/nls/fr_BE.ISO8859-15 missing (created) ./share/nls/fr_BE.UTF-8 missing (created) ./share/nls/fr_CA.ISO8859-1 missing (created) ./share/nls/fr_CA.ISO8859-15 missing (created) ./share/nls/fr_CA.UTF-8 missing (created) ./share/nls/fr_CH.ISO8859-1 missing (created) ./share/nls/fr_CH.ISO8859-15 missing (created) ./share/nls/fr_CH.UTF-8 missing (created) ./share/nls/fr_FR.ISO8859-1 missing (created) ./share/nls/fr_FR.ISO8859-15 missing (created) ./share/nls/fr_FR.UTF-8 missing (created) ./share/nls/he_IL.UTF-8 missing (created) ./share/nls/hi_IN.ISCII-DEV missing (created) ./share/nls/hr_HR.ISO8859-2 missing (created) ./share/nls/hr_HR.UTF-8 missing (created) ./share/nls/hu_HU.ISO8859-2 missing (created) ./share/nls/hu_HU.UTF-8 missing (created) ./share/nls/hy_AM.ARMSCII-8 missing (created) ./share/nls/hy_AM.UTF-8 missing (created) ./share/nls/is_IS.ISO8859-1 missing (created) ./share/nls/is_IS.ISO8859-15 missing (created) ./share/nls/is_IS.UTF-8 missing (created) ./share/nls/it_CH.ISO8859-1 missing (created) ./share/nls/it_CH.ISO8859-15 missing (created) ./share/nls/it_CH.UTF-8 missing (created) ./share/nls/it_IT.ISO8859-1 missing (created) ./share/nls/it_IT.ISO8859-15 missing (created) ./share/nls/it_IT.UTF-8 missing (created) ./share/nls/ja_JP.SJIS missing (created) ./share/nls/ja_JP.UTF-8 missing (created) ./share/nls/ja_JP.eucJP missing (created) ./share/nls/kk_KZ.PT154 missing (created) ./share/nls/kk_KZ.UTF-8 missing (created) ./share/nls/ko_KR.CP949 missing (created) ./share/nls/ko_KR.UTF-8 missing (created) ./share/nls/ko_KR.eucKR missing (created) ./share/nls/la_LN.ISO8859-1 missing (created) ./share/nls/la_LN.ISO8859-15 missing (created) ./share/nls/la_LN.ISO8859-2 missing (created) ./share/nls/la_LN.ISO8859-4 missing (created) ./share/nls/la_LN.US-ASCII missing (created) ./share/nls/lt_LT.ISO8859-13 missing (created) ./share/nls/lt_LT.ISO8859-4 missing (created) ./share/nls/lt_LT.UTF-8 missing (created) ./share/nls/mn_MN.UTF-8 missing (created) ./share/nls/nl_BE.ISO8859-1 missing (created) ./share/nls/nl_BE.ISO8859-15 missing (created) ./share/nls/nl_BE.UTF-8 missing (created) ./share/nls/nl_NL.ISO8859-1 missing (created) ./share/nls/nl_NL.ISO8859-15 missing (created) ./share/nls/nl_NL.UTF-8 missing (created) ./share/nls/no_NO.ISO8859-1 missing (created) ./share/nls/no_NO.ISO8859-15 missing (created) ./share/nls/no_NO.UTF-8 missing (created) ./share/nls/pl_PL.ISO8859-2 missing (created) ./share/nls/pl_PL.UTF-8 missing (created) ./share/nls/pt_BR.ISO8859-1 missing (created) ./share/nls/pt_BR.UTF-8 missing (created) ./share/nls/pt_PT.ISO8859-1 missing (created) ./share/nls/pt_PT.ISO8859-15 missing (created) ./share/nls/pt_PT.UTF-8 missing (created) ./share/nls/ro_RO.ISO8859-2 missing (created) ./share/nls/ro_RO.UTF-8 missing (created) ./share/nls/ru_RU.CP1251 missing (created) ./share/nls/ru_RU.CP866 missing (created) ./share/nls/ru_RU.ISO8859-5 missing (created) ./share/nls/ru_RU.KOI8-R missing (created) ./share/nls/ru_RU.UTF-8 missing (created) ./share/nls/sk_SK.ISO8859-2 missing (created) ./share/nls/sk_SK.UTF-8 missing (created) ./share/nls/sl_SI.ISO8859-2 missing (created) ./share/nls/sl_SI.UTF-8 missing (created) ./share/nls/sr_YU.ISO8859-2 missing (created) ./share/nls/sr_YU.ISO8859-5 missing (created) ./share/nls/sr_YU.UTF-8 missing (created) ./share/nls/sv_SE.ISO8859-1 missing (created) ./share/nls/sv_SE.ISO8859-15 missing (created) ./share/nls/sv_SE.UTF-8 missing (created) ./share/nls/tr_TR.ISO8859-9 missing (created) ./share/nls/tr_TR.UTF-8 missing (created) ./share/nls/uk_UA.ISO8859-5 missing (created) ./share/nls/uk_UA.KOI8-U missing (created) ./share/nls/uk_UA.UTF-8 missing (created) ./share/nls/zh_CN.GB18030 missing (created) ./share/nls/zh_CN.GB2312 missing (created) ./share/nls/zh_CN.GBK missing (created) ./share/nls/zh_CN.UTF-8 missing (created) ./share/nls/zh_CN.eucCN missing (created) ./share/nls/zh_HK.Big5HKSCS missing (created) ./share/nls/zh_HK.UTF-8 missing (created) ./share/nls/zh_TW.Big5 missing (created) ./share/nls/zh_TW.UTF-8 missing (created) ./share/openssl missing (created) ./share/openssl/man missing (created) ./share/openssl/man/cat1 missing (created) ./share/openssl/man/cat3 missing (created) ./share/openssl/man/en.ISO8859-1 missing (created) ./share/openssl/man/en.ISO8859-1/cat1 missing (created) ./share/openssl/man/en.ISO8859-1/cat3 missing (created) ./share/openssl/man/man1 missing (created) ./share/openssl/man/man3 missing (created) ./share/security missing (created) ./share/sendmail missing (created) ./share/skel missing (created) ./share/snmp missing (created) ./share/snmp/defs missing (created) ./share/snmp/mibs missing (created) ./share/syscons missing (created) ./share/syscons/fonts missing (created) ./share/syscons/keymaps missing (created) ./share/syscons/scrnmaps missing (created) ./share/tabset missing (created) ./share/tmac missing (created) ./share/tmac/mdoc missing (created) ./share/tmac/mm missing (created) ./share/vi missing (created) ./share/vi/catalog missing (created) ./share/zoneinfo missing (created) ./share/zoneinfo/Africa missing (created) ./share/zoneinfo/America missing (created) ./share/zoneinfo/America/Argentina missing (created) ./share/zoneinfo/America/Indiana missing (created) ./share/zoneinfo/America/Kentucky missing (created) ./share/zoneinfo/America/North_Dakota missing (created) ./share/zoneinfo/Antarctica missing (created) ./share/zoneinfo/Arctic missing (created) ./share/zoneinfo/Asia missing (created) ./share/zoneinfo/Atlantic missing (created) ./share/zoneinfo/Australia missing (created) ./share/zoneinfo/Etc missing (created) ./share/zoneinfo/Europe missing (created) ./share/zoneinfo/Indian missing (created) ./share/zoneinfo/Pacific missing (created) ./share/zoneinfo/SystemV missing (created) ./src missing (created) mtree -eU -f /usr/src/etc/mtree/BSD.include.dist -p /var/tmp/temproot/usr/include ./altq missing (created) ./arpa missing (created) ./bsm missing (created) ./bsnmp missing (created) ./c++ missing (created) ./c++/4.2 missing (created) ./c++/4.2/backward missing (created) ./c++/4.2/bits missing (created) ./c++/4.2/debug missing (created) ./c++/4.2/ext missing (created) ./c++/4.2/ext/pb_ds missing (created) ./c++/4.2/ext/pb_ds/detail missing (created) ./c++/4.2/ext/pb_ds/detail/basic_tree_policy missing (created) ./c++/4.2/ext/pb_ds/detail/bin_search_tree_ missing (created) ./c++/4.2/ext/pb_ds/detail/binary_heap_ missing (created) ./c++/4.2/ext/pb_ds/detail/binomial_heap_ missing (created) ./c++/4.2/ext/pb_ds/detail/binomial_heap_base_ missing (created) ./c++/4.2/ext/pb_ds/detail/cc_hash_table_map_ missing (created) ./c++/4.2/ext/pb_ds/detail/eq_fn missing (created) ./c++/4.2/ext/pb_ds/detail/gp_hash_table_map_ missing (created) ./c++/4.2/ext/pb_ds/detail/hash_fn missing (created) ./c++/4.2/ext/pb_ds/detail/left_child_next_sibling_heap_ missing (created) ./c++/4.2/ext/pb_ds/detail/list_update_map_ missing (created) ./c++/4.2/ext/pb_ds/detail/list_update_policy missing (created) ./c++/4.2/ext/pb_ds/detail/ov_tree_map_ missing (created) ./c++/4.2/ext/pb_ds/detail/pairing_heap_ missing (created) ./c++/4.2/ext/pb_ds/detail/pat_trie_ missing (created) ./c++/4.2/ext/pb_ds/detail/rb_tree_map_ missing (created) ./c++/4.2/ext/pb_ds/detail/rc_binomial_heap_ missing (created) ./c++/4.2/ext/pb_ds/detail/resize_policy missing (created) ./c++/4.2/ext/pb_ds/detail/splay_tree_ missing (created) ./c++/4.2/ext/pb_ds/detail/thin_heap_ missing (created) ./c++/4.2/ext/pb_ds/detail/tree_policy missing (created) ./c++/4.2/ext/pb_ds/detail/trie_policy missing (created) ./c++/4.2/ext/pb_ds/detail/unordered_iterator missing (created) ./c++/4.2/tr1 missing (created) ./cam missing (created) ./cam/scsi missing (created) ./crypto missing (created) ./dev missing (created) ./dev/acpica missing (created) ./dev/an missing (created) ./dev/bktr missing (created) ./dev/firewire missing (created) ./dev/hwpmc missing (created) ./dev/ic missing (created) ./dev/ieee488 missing (created) ./dev/iicbus missing (created) ./dev/lmc missing (created) ./dev/mpt missing (created) ./dev/mpt/mpilib missing (created) ./dev/ofw missing (created) ./dev/pbio missing (created) ./dev/powermac_nvram missing (created) ./dev/ppbus missing (created) ./dev/smbus missing (created) ./dev/speaker missing (created) ./dev/usb missing (created) ./dev/utopia missing (created) ./dev/vkbd missing (created) ./dev/wi missing (created) ./fs missing (created) ./fs/devfs missing (created) ./fs/fdescfs missing (created) ./fs/fifofs missing (created) ./fs/msdosfs missing (created) ./fs/ntfs missing (created) ./fs/nullfs missing (created) ./fs/nwfs missing (created) ./fs/portalfs missing (created) ./fs/procfs missing (created) ./fs/smbfs missing (created) ./fs/udf missing (created) ./fs/unionfs missing (created) ./geom missing (created) ./geom/cache missing (created) ./geom/concat missing (created) ./geom/eli missing (created) ./geom/gate missing (created) ./geom/journal missing (created) ./geom/label missing (created) ./geom/mirror missing (created) ./geom/multipath missing (created) ./geom/nop missing (created) ./geom/raid3 missing (created) ./geom/shsec missing (created) ./geom/stripe missing (created) ./geom/virstor missing (created) ./gnu missing (created) ./gnu/posix missing (created) ./gpib missing (created) ./gssapi missing (created) ./i4b missing (created) ./isofs missing (created) ./isofs/cd9660 missing (created) ./kadm5 missing (created) ./libmilter missing (created) ./lwres missing (created) ./machine missing (created) ./machine/pc missing (created) ./net missing (created) ./net80211 missing (created) ./netatalk missing (created) ./netgraph missing (created) ./netgraph/atm missing (created) ./netgraph/bluetooth missing (created) ./netgraph/bluetooth/include missing (created) ./netgraph/netflow missing (created) ./netinet missing (created) ./netinet6 missing (created) ./netipsec missing (created) ./netipx missing (created) ./netnatm missing (created) ./netnatm/api missing (created) ./netnatm/msg missing (created) ./netnatm/saal missing (created) ./netnatm/sig missing (created) ./netncp missing (created) ./netsmb missing (created) ./nfs missing (created) ./nfsclient missing (created) ./nfsserver missing (created) ./objc missing (created) ./openssl missing (created) ./pccard missing (created) ./protocols missing (created) ./readline missing (created) ./rpc missing (created) ./rpcsvc missing (created) ./security missing (created) ./security/audit missing (created) ./security/mac_biba missing (created) ./security/mac_bsdextended missing (created) ./security/mac_lomac missing (created) ./security/mac_mls missing (created) ./security/mac_partition missing (created) ./ssp missing (created) ./sys missing (created) ./ufs missing (created) ./ufs/ffs missing (created) ./ufs/ufs missing (created) ./vm missing (created) mtree -deU -f /usr/src/etc/mtree/BIND.chroot.dist -p /var/tmp/temproot/var/named ./dev missing (created) ./etc missing (created) ./etc/namedb missing (created) ./etc/namedb/dynamic missing (created) ./etc/namedb/master missing (created) ./etc/namedb/slave missing (created) ./var missing (created) ./var/dump missing (created) ./var/log missing (created) ./var/run missing (created) ./var/run/named missing (created) ./var/stats missing (created) mtree -deU -f /usr/src/etc/mtree/BSD.sendmail.dist -p /var/tmp/temproot/ ./var/spool/clientmqueue missing (created) cd /var/tmp/temproot/; rm -f /var/tmp/temproot/sys; ln -s usr/src/sys sys cd /var/tmp/temproot/usr/share/man/en.ISO8859-1; ln -sf ../man* . cd /var/tmp/temproot/usr/share/man; set - `grep "^[a-zA-Z]" /usr/src/etc/man.alias`; while [ $# -gt 0 ] ; do rm -rf "$1"; ln -s "$2" "$1"; shift; shift; done cd /var/tmp/temproot/usr/share/openssl/man; set - `grep "^[a-zA-Z]" /usr/src/etc/man.alias`; while [ $# -gt 0 ] ; do rm -rf "$1"; ln -s "$2" "$1"; shift; shift; done cd /var/tmp/temproot/usr/share/openssl/man/en.ISO8859-1; ln -sf ../man* . cd /var/tmp/temproot/usr/share/nls; set - `grep "^[a-zA-Z]" /usr/src/etc/nls.alias`; while [ $# -gt 0 ] ; do rm -rf "$1"; ln -s "$2" "$1"; shift; shift; done -------------------------------------------------------------- >>> stage 2.2: rebuilding the object tree -------------------------------------------------------------- cd /usr/src; MAKEOBJDIRPREFIX=/var/tmp/temproot/usr/obj MACHINE_ARCH=amd64 MACHINE=amd64 CPUTYPE= GROFF_BIN_PATH=/var/tmp/temproot/usr/obj/usr/src/tmp/legacy/usr/bin GROFF_FONT_PATH=/var/tmp/temproot/usr/obj/usr/src/tmp/legacy/usr/share/groff_font GROFF_TMAC_PATH=/var/tmp/temproot/usr/obj/usr/src/tmp/legacy/usr/share/tmac _SHLIBDIRPREFIX=/var/tmp/temproot/usr/obj/usr/src/tmp VERSION="FreeBSD 7.2-PRERELEASE amd64 702100" INSTALL="sh /usr/src/tools/install.sh" PATH=/var/tmp/temproot/usr/obj/usr/src/tmp/legacy/usr/sbin:/var/tmp/temproot/usr/obj/usr/src/tmp/legacy/usr/bin:/var/tmp/temproot/usr/obj/usr/src/tmp/legacy/usr/games:/var/tmp/temproot/usr/obj/usr/src/tmp/usr/sbin:/var/tmp/temproot/usr/obj/usr/src/tmp/usr/bin:/var/tmp/temproot/usr/obj/usr/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin NO_CTF=1 make -f Makefile.inc1 DESTDIR=/var/tmp/temproot/usr/obj/usr/src/tmp par-obj ===> etc (obj) /var/tmp/temproot/usr/obj/usr/src/etc created for /usr/src/etc ===> etc/sendmail (obj) /var/tmp/temproot/usr/obj/usr/src/etc/sendmail created for /usr/src/etc/sendmail -------------------------------------------------------------- >>> stage 4.4: building everything -------------------------------------------------------------- cd /usr/src; MAKEOBJDIRPREFIX=/var/tmp/temproot/usr/obj MACHINE_ARCH=amd64 MACHINE=amd64 CPUTYPE= GROFF_BIN_PATH=/var/tmp/temproot/usr/obj/usr/src/tmp/legacy/usr/bin GROFF_FONT_PATH=/var/tmp/temproot/usr/obj/usr/src/tmp/legacy/usr/share/groff_font GROFF_TMAC_PATH=/var/tmp/temproot/usr/obj/usr/src/tmp/legacy/usr/share/tmac _SHLIBDIRPREFIX=/var/tmp/temproot/usr/obj/usr/src/tmp VERSION="FreeBSD 7.2-PRERELEASE amd64 702100" INSTALL="sh /usr/src/tools/install.sh" PATH=/var/tmp/temproot/usr/obj/usr/src/tmp/legacy/usr/sbin:/var/tmp/temproot/usr/obj/usr/src/tmp/legacy/usr/bin:/var/tmp/temproot/usr/obj/usr/src/tmp/legacy/usr/games:/var/tmp/temproot/usr/obj/usr/src/tmp/usr/sbin:/var/tmp/temproot/usr/obj/usr/src/tmp/usr/bin:/var/tmp/temproot/usr/obj/usr/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin NO_CTF=1 make -f Makefile.inc1 DESTDIR=/var/tmp/temproot/usr/obj/usr/src/tmp par-all ===> etc (all) ===> etc/sendmail (all) rm -f freebsd.cf m4 -D_CF_DIR_=/usr/src/etc/sendmail/../../contrib/sendmail/cf/ /usr/src/etc/sendmail/../../contrib/sendmail/cf/m4/cf.m4 /usr/src/etc/sendmail/freebsd.mc > freebsd.cf chmod 444 freebsd.cf rm -f freebsd.submit.cf m4 -D_CF_DIR_=/usr/src/etc/sendmail/../../contrib/sendmail/cf/ /usr/src/etc/sendmail/../../contrib/sendmail/cf/m4/cf.m4 /usr/src/etc/sendmail/freebsd.submit.mc > freebsd.submit.cf chmod 444 freebsd.submit.cf cd /usr/src/etc; MAKEOBJDIRPREFIX=/var/tmp/temproot/usr/obj MACHINE_ARCH=amd64 MACHINE=amd64 CPUTYPE= GROFF_BIN_PATH=/var/tmp/temproot/usr/obj/usr/src/tmp/legacy/usr/bin GROFF_FONT_PATH=/var/tmp/temproot/usr/obj/usr/src/tmp/legacy/usr/share/groff_font GROFF_TMAC_PATH=/var/tmp/temproot/usr/obj/usr/src/tmp/legacy/usr/share/tmac PATH=/var/tmp/temproot/usr/obj/usr/src/tmp/legacy/usr/sbin:/var/tmp/temproot/usr/obj/usr/src/tmp/legacy/usr/bin:/var/tmp/temproot/usr/obj/usr/src/tmp/legacy/usr/games:/var/tmp/temproot/usr/obj/usr/src/tmp/usr/sbin:/var/tmp/temproot/usr/obj/usr/src/tmp/usr/bin:/var/tmp/temproot/usr/obj/usr/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin make distribution cd /usr/src/etc; install -o root -g wheel -m 644 auth.conf crontab devd.conf devfs.conf ddb.conf dhclient.conf disktab fbtab ftpusers gettytab group hosts hosts.allow hosts.equiv inetd.conf libalias.conf login.access login.conf mac.conf motd netconfig network.subr networks newsyslog.conf nsswitch.conf phones profile protocols rc rc.bsdextended rc.firewall rc.firewall6 rc.initdiskless rc.sendmail rc.shutdown rc.subr remote rpc services shells sysctl.conf syslog.conf etc.amd64/ttys amd.map apmd.conf snmpd.config freebsd-update.conf /usr/src/etc/../usr.bin/locate/locate/locate.rc hosts.lpd printcap /usr/src/etc/../usr.bin/mail/misc/mail.rc /usr/src/etc/../gnu/usr.bin/man/manpath/manpath.config nscd.conf portsnap.conf pf.os csh.cshrc csh.login csh.logout /var/tmp/temproot/etc; cap_mkdb -l /var/tmp/temproot/etc/login.conf; install -o root -g wheel -m 755 netstart pccard_ether rc.suspend rc.resume /var/tmp/temproot/etc; install -o root -g wheel -m 600 master.pass wd nsmb. pwd_mkdb -L -i -p -d /var/tmp/temproot/etc /var/tmp/temproot/etc/master.passwd cd /usr/src/etc/bluetooth; make install install -o root -g wheel -m 600 hcsecd.conf /var/tmp/temproot/etc/bluetooth/hcsecd.conf install -o root -g wheel -m 644 hosts /var/tmp/temproot/etc/bluetooth/hosts install -o root -g wheel -m 444 protocols /var/tmp/temproot/etc/bluetooth cd /usr/src/etc/defaults; make install install -o root -g wheel -m 444 bluetooth.device.conf devfs.rules pccard.conf periodic.conf rc.conf /var/tmp/temproot/etc/defaults cd /usr/src/etc/gss; make install install -o root -g wheel -m 444 mech qop /var/tmp/temproot/etc/gss cd /usr/src/etc/periodic; make install ===> daily (install) install -o root -g wheel -m 755 100.clean-disks 110.clean-tmps 120.clean-preserve 200.backup-passwd 330.news 400.status-disks 404.status-zfs 405.status-ata-raid 406.status-gmirror 407.status-graid3 408.status-gstripe 409.status-gconcat 420.status-network 450.status-security 999.local 310.accounting 470.status-named 300.calendar 130.clean-msgs 480.status-ntpd 140.clean-rwho 430.status-rwho 150.clean-hoststat 210.backup-aliases 440.status-mailq 460.status-mail-rejects 500.queuerun /var/tmp/temproot/etc/periodic/daily ===> security (install) install -o root -g wheel -m 755 100.chksetuid 200.chkmounts 300.chkuid0 400.passwdless 410.logincheck 700.kernelmsg 800.loginfail 900.tcpwrap security.functions 510.ipfdenied 500.ipfwdenied 550.ipfwlimit 520.pfdenied /var/tmp/temproot/etc/periodic/security ===> weekly (install) install -o root -g wheel -m 755 340.noid 999.local 310.locate 320.whatis 330.catman 400.status-pkg /var/tmp/temproot/etc/periodic/weekly ===> monthly (install) install -o root -g wheel -m 755 999.local 200.accounting /var/tmp/temproot/etc/periodic/monthly cd /usr/src/etc/rc.d; make install install -o root -g wheel -m 555 DAEMON FILESYSTEMS LOGIN NETWORKING SERVERS abi accounting addswap adjkerntz amd apm apmd archdep atm1 atm2 atm3 auditd auto_linklocal bgfsck bluetooth bootparams bridge bsnmpd bthidd ccd cleanvar cleartmp cron ddb devd devfs dhclient dmesg dumpon early.sh encswap fsck ftp-proxy ftpd gbde geli geli2 hcsecd hostapd hostid hostname idmapd inetd initrandom ip6addrctl ip6fw ipfilter ipfs ipfw ipmon ipnat ipsec ipxrouted isdnd jail kadmind kerberos keyserv kldxref kpasswdd ldconfig local localpkg lockd lpd mixer motd mountcritlocal mountcritremote mountlate mdconfig mdconfig2 mountd moused mroute6d mrouted msgs named natd netif netoptions network_ipv6 newsyslog nfsclient nfsd nfsserver nisdomain nsswitch ntpd ntpdate othermta pf pflog pfsync powerd power_profile ppp pppoed pwcheck quota random rarpd resolv rfcomm_pppd_server root route6d routed routing rpcbind rtadvd rwho savecore sdpd securelevel sendmail serial sppp statd swap1 syscons sysctl sys logd tim cd /usr/src/etc/../gnu/usr.bin/send-pr; make etc-gnats-freefall install -o root -g wheel -m 0644 /usr/src/gnu/usr.bin/send-pr/categories /var/tmp/temproot/etc/gnats/freefall cd /usr/src/etc/../share/termcap; make etc-termcap ln -fs /usr/share/misc/termcap /var/tmp/temproot/etc/termcap cd /usr/src/etc/../usr.sbin/rmt; make etc-rmt rm -f /var/tmp/temproot/etc/rmt ln -s /usr/sbin/rmt /var/tmp/temproot/etc/rmt cd /usr/src/etc/pam.d; make install install -o root -g wheel -m 444 README /var/tmp/temproot/etc/pam.d/README install -o root -g wheel -m 644 atrun cron ftpd gdm imap kde login other passwd pop3 rsh sshd su system telnetd xdm /var/tmp/temproot/etc/pam.d /var/tmp/temproot/etc/pam.d/ftp -> /var/tmp/temproot/etc/pam.d/ftpd cd /usr/src/etc; install -o root -g wheel -m 0444 /usr/src/etc/../contrib/openbsm/etc/audit_class /usr/src/etc/../contrib/openbsm/etc/audit_event /var/tmp/temproot/etc/security cd /usr/src/etc; install -o root -g wheel -m 0600 /usr/src/etc/../contrib/openbsm/etc/audit_control /usr/src/etc/../contrib/openbsm/etc/audit_user /var/tmp/temproot/etc/security cd /usr/src/etc; install -o root -g wheel -m 0500 /usr/src/etc/../contrib/openbsm/etc/audit_warn /var/tmp/temproot/etc/security cd /usr/src/etc/isdn; make install install -o root -g wheel -m 700 answer /var/tmp/temproot/etc/isdn/answer install -o root -g wheel -m 700 isdntel.sh /var/tmp/temproot/etc/isdn/isdntel install -o root -g wheel -m 700 record /var/tmp/temproot/etc/isdn/record install -o root -g wheel -m 700 tell /var/tmp/temproot/etc/isdn/tell install -o root -g wheel -m 700 tell-record /var/tmp/temproot/etc/isdn/tell-record install -o root -g wheel -m 700 unknown_incoming /var/tmp/temproot/etc/isdn/unknown_incoming install -o root -g wheel -m 600 holidays.D isdnd.rates.A isdnd.rates.D isdnd.rates.F isdnd.rates.L isdnd.rates.UK.BT isdnd.rc.sample isdntel.alias.sample /var/tmp/temproot/etc/isdn + ln -s ../var/named/etc/namedb /var/tmp/temproot/etc/namedb cd /usr/src/etc/namedb; make install install -o root -g wheel -m 644 named.conf named.root /var/tmp/temproot/etc/namedb ===> master (install) install -o root -g wheel -m 644 empty.db localhost-forward.db localhost-reverse.db /var/tmp/temproot/etc/namedb/master cd /usr/src/etc/sendmail; make distribution install -o root -g wheel -m 644 /usr/src/etc/sendmail/freebsd.mc freebsd.cf /var/tmp/temproot/etc/mail install -o root -g wheel -m 444 /usr/src/etc/sendmail/freebsd.submit.mc freebsd.submit.cf /var/tmp/temproot/etc/mail install -o root -g wheel -m 444 /usr/src/etc/sendmail/../../contrib/sendmail/src/helpfile /var/tmp/temproot/etc/mail install -o root -g wheel -m 640 /dev/null /var/tmp/temproot/var/log/sendmail.st install -o root -g wheel -m 644 freebsd.cf /var/tmp/temproot/etc/mail/sendmail.cf install -o root -g wheel -m 444 freebsd.submit.cf /var/tmp/temproot/etc/mail/submit.cf cd /usr/src/etc; install -o root -g wheel -m 644 /usr/src/etc/../crypto/openssh/ssh_config /usr/src/etc/../crypto/openssh/sshd_config /usr/src/etc/../crypto/openssh/moduli /var/tmp/temproot/etc/ssh cd /usr/src/etc; install -o root -g wheel -m 644 /usr/src/etc/../crypto/openssl/apps/openssl.cnf /var/tmp/temproot/etc/ssl cd /usr/src/etc/root; install -o root -g wheel -m 644 dot.k5login /var/tmp/temproot/root/.k5login; cd /usr/src/etc/root; install -o root -g wheel -m 644 dot.profile /var/tmp/temproot/root/.profile; rm -f /var/tmp/temproot/.profile; ln /var/tmp/temproot/root/.profile /var/tmp/temproot/.profile cd /usr/src/etc/root; install -o root -g wheel -m 644 dot.cshrc /var/tmp/temproot/root/.cshrc; install -o root -g wheel -m 644 dot.login /var/tmp/temproot/root/.login; rm -f /var/tmp/temproot/.cshrc; ln /var/tmp/temproot/root/.cshrc /var/tmp/temproot/.cshrc cd /usr/src/etc/mtree; install -o root -g wheel -m 444 BSD.include.dist BSD.local.dist BSD.root.dist BSD.usr.dist BSD.var.dist BSD.x11.dist BSD.x11-4.dist BSD.sendmail.dist BIND.chroot.dist /var/tmp/temproot/etc/mtree cd /usr/src/etc/ppp; install -o root -g wheel -m 600 ppp.conf /var/tmp/temproot/etc/ppp cd /usr/src/etc/mail; install -o root -g wheel -m 644 Makefile README mailer.conf access.sample virtusertable.sample mailertable.sample aliases /var/tmp/temproot/etc/mail + ln -s mail/aliases /var/tmp/temproot/etc/aliases install -o root -g operator -m 664 /dev/null /var/tmp/temproot/etc/dumpdates install -o nobody -g wheel -m 644 /dev/null /var/tmp/temproot/var/db/locate.database install -o root -g wheel -m 644 /usr/src/etc/minfree /var/tmp/temproot/var/crash cd /usr/src/etc/..; install -o root -g wheel -m 444 COPYRIGHT /var/tmp/temproot/ install -o root -g wheel -m 444 /usr/src/etc/../sys/amd64/conf/GENERIC.hints /var/tmp/temproot/boot/device.hints *** Beginning comparison *** Checking /etc/rc.d for stale files *** No stale files found *** Temp ./boot/device.hints and installed have the same CVS Id, deleting *** Temp ./etc/bluetooth/hcsecd.conf and installed have the same CVS Id, deleting *** Temp ./etc/bluetooth/hosts and installed have the same CVS Id, deleting *** Temp ./etc/bluetooth/protocols and installed have the same CVS Id, deleting *** Temp ./etc/defaults/bluetooth.device.conf and installed have the same CVS Id, deleting *** Temp ./etc/defaults/devfs.rules and installed have the same CVS Id, deleting *** Temp ./etc/defaults/pccard.conf and installed have the same CVS Id, deleting *** Temp ./etc/defaults/periodic.conf and installed have the same CVS Id, deleting *** Temp ./etc/defaults/rc.conf and installed have the same CVS Id, deleting *** Temp ./etc/gnats/freefall and installed have the same CVS Id, deleting *** Temp ./etc/gss/mech and installed have the same CVS Id, deleting *** Temp ./etc/gss/qop and installed have the same CVS Id, deleting *** Temp ./etc/isdn/answer and installed have the same CVS Id, deleting *** Temp ./etc/isdn/isdntel and installed have the same CVS Id, deleting *** Temp ./etc/isdn/record and installed have the same CVS Id, deleting *** Temp ./etc/isdn/tell and installed have the same CVS Id, deleting *** Temp ./etc/isdn/tell-record and installed have the same CVS Id, deleting *** Temp ./etc/isdn/unknown_incoming and installed have the same CVS Id, deleting *** Temp ./etc/isdn/holidays.D and installed have the same CVS Id, deleting *** Temp ./etc/isdn/isdnd.rates.A and installed have the same CVS Id, deleting *** Temp ./etc/isdn/isdnd.rates.D and installed have the same CVS Id, deleting *** Temp ./etc/isdn/isdnd.rates.F and installed have the same CVS Id, deleting *** Temp ./etc/isdn/isdnd.rates.L and installed have the same CVS Id, deleting *** Temp ./etc/isdn/isdnd.rates.UK.BT and installed have the same CVS Id, deleting *** Temp ./etc/isdn/isdnd.rc.sample and installed have the same CVS Id, deleting *** Temp ./etc/isdn/isdntel.alias.sample and installed have the same CVS Id, deleting *** Temp ./etc/mail/freebsd.mc and installed have the same CVS Id, deleting *** Temp ./etc/mail/freebsd.cf and installed have the same CVS Id, deleting *** Temp ./etc/mail/freebsd.submit.mc and installed have the same CVS Id, deleting *** Temp ./etc/mail/freebsd.submit.cf and installed have the same CVS Id, deleting *** Temp ./etc/mail/helpfile and installed are the same, deleting *** Temp ./etc/mail/sendmail.cf and installed have the same CVS Id, deleting *** Temp ./etc/mail/submit.cf and installed have the same CVS Id, deleting *** Temp ./etc/mail/Makefile and installed have the same CVS Id, deleting *** Temp ./etc/mail/README and installed have the same CVS Id, deleting *** Temp ./etc/mail/mailer.conf and installed have the same CVS Id, deleting *** Temp ./etc/mail/access.sample and installed have the same CVS Id, deleting *** Temp ./etc/mail/virtusertable.sample and installed have the same CVS Id, deleting *** Temp ./etc/mail/mailertable.sample and installed have the same CVS Id, deleting *** Temp ./etc/mail/aliases and installed have the same CVS Id, deleting *** Temp ./etc/mtree/BSD.include.dist and installed have the same CVS Id, deleting *** Temp ./etc/mtree/BSD.local.dist and installed have the same CVS Id, deleting *** Temp ./etc/mtree/BSD.root.dist and installed have the same CVS Id, deleting *** Temp ./etc/mtree/BSD.usr.dist and installed have the same CVS Id, deleting *** Temp ./etc/mtree/BSD.var.dist and installed have the same CVS Id, deleting *** Temp ./etc/mtree/BSD.x11.dist and installed have the same CVS Id, deleting *** Temp ./etc/mtree/BSD.x11-4.dist and installed have the same CVS Id, deleting *** Temp ./etc/mtree/BSD.sendmail.dist and installed have the same CVS Id, deleting *** Temp ./etc/mtree/BIND.chroot.dist and installed have the same CVS Id, deleting *** Temp ./etc/pam.d/README and installed have the same CVS Id, deleting *** Temp ./etc/pam.d/atrun and installed have the same CVS Id, deleting *** Temp ./etc/pam.d/cron and installed have the same CVS Id, deleting *** Temp ./etc/pam.d/ftpd and installed have the same CVS Id, deleting *** Temp ./etc/pam.d/gdm and installed have the same CVS Id, deleting *** Temp ./etc/pam.d/imap and installed have the same CVS Id, deleting *** Temp ./etc/pam.d/kde and installed have the same CVS Id, deleting *** Temp ./etc/pam.d/login and installed have the same CVS Id, deleting *** Temp ./etc/pam.d/other and installed have the same CVS Id, deleting *** Temp ./etc/pam.d/passwd and installed have the same CVS Id, deleting *** Temp ./etc/pam.d/pop3 and installed have the same CVS Id, deleting *** Temp ./etc/pam.d/rsh and installed have the same CVS Id, deleting *** Temp ./etc/pam.d/sshd and installed have the same CVS Id, deleting *** Temp ./etc/pam.d/su and installed have the same CVS Id, deleting *** Temp ./etc/pam.d/system and installed have the same CVS Id, deleting *** Temp ./etc/pam.d/telnetd and installed have the same CVS Id, deleting *** Temp ./etc/pam.d/xdm and installed have the same CVS Id, deleting *** Temp ./etc/pam.d/ftp and installed have the same CVS Id, deleting *** Temp ./etc/periodic/daily/100.clean-disks and installed have the same CVS Id, deleting *** Temp ./etc/periodic/daily/110.clean-tmps and installed have the same CVS Id, deleting *** Temp ./etc/periodic/daily/120.clean-preserve and installed have the same CVS Id, deleting *** Temp ./etc/periodic/daily/200.backup-passwd and installed have the same CVS Id, deleting *** Temp ./etc/periodic/daily/330.news and installed have the same CVS Id, deleting *** Temp ./etc/periodic/daily/400.status-disks and installed have the same CVS Id, deleting *** Temp ./etc/periodic/daily/404.status-zfs and installed have the same CVS Id, deleting *** Temp ./etc/periodic/daily/405.status-ata-raid and installed have the same CVS Id, deleting *** Temp ./etc/periodic/daily/406.status-gmirror and installed have the same CVS Id, deleting *** Temp ./etc/periodic/daily/407.status-graid3 and installed have the same CVS Id, deleting *** Temp ./etc/periodic/daily/408.status-gstripe and installed have the same CVS Id, deleting *** Temp ./etc/periodic/daily/409.status-gconcat and installed have the same CVS Id, deleting *** Temp ./etc/periodic/daily/420.status-network and installed have the same CVS Id, deleting *** Temp ./etc/periodic/daily/450.status-security and installed have the same CVS Id, deleting *** Temp ./etc/periodic/daily/999.local and installed have the same CVS Id, deleting *** Temp ./etc/periodic/daily/310.accounting and installed have the same CVS Id, deleting *** Temp ./etc/periodic/daily/470.status-named and installed have the same CVS Id, deleting *** Temp ./etc/periodic/daily/300.calendar and installed have the same CVS Id, deleting *** Temp ./etc/periodic/daily/130.clean-msgs and installed have the same CVS Id, deleting *** Temp ./etc/periodic/daily/480.status-ntpd and installed have the same CVS Id, deleting *** Temp ./etc/periodic/daily/140.clean-rwho and installed have the same CVS Id, deleting *** Temp ./etc/periodic/daily/430.status-rwho and installed have the same CVS Id, deleting *** Temp ./etc/periodic/daily/150.clean-hoststat and installed have the same CVS Id, deleting *** Temp ./etc/periodic/daily/210.backup-aliases and installed have the same CVS Id, deleting *** Temp ./etc/periodic/daily/440.status-mailq and installed have the same CVS Id, deleting *** Temp ./etc/periodic/daily/460.status-mail-rejects and installed have the same CVS Id, deleting *** Temp ./etc/periodic/daily/500.queuerun and installed have the same CVS Id, deleting *** Temp ./etc/periodic/monthly/999.local and installed have the same CVS Id, deleting *** Temp ./etc/periodic/monthly/200.accounting and installed have the same CVS Id, deleting *** Temp ./etc/periodic/security/100.chksetuid and installed have the same CVS Id, deleting *** Temp ./etc/periodic/security/200.chkmounts and installed have the same CVS Id, deleting *** Temp ./etc/periodic/security/300.chkuid0 and installed have the same CVS Id, deleting *** Temp ./etc/periodic/security/400.passwdless and installed have the same CVS Id, deleting *** Temp ./etc/periodic/security/410.logincheck and installed have the same CVS Id, deleting *** Temp ./etc/periodic/security/700.kernelmsg and installed have the same CVS Id, deleting *** Temp ./etc/periodic/security/800.loginfail and installed have the same CVS Id, deleting *** Temp ./etc/periodic/security/900.tcpwrap and installed have the same CVS Id, deleting *** Temp ./etc/periodic/security/security.functions and installed have the same CVS Id, deleting *** Temp ./etc/periodic/security/510.ipfdenied and installed have the same CVS Id, deleting *** Temp ./etc/periodic/security/500.ipfwdenied and installed have the same CVS Id, deleting *** Temp ./etc/periodic/security/550.ipfwlimit and installed have the same CVS Id, deleting *** Temp ./etc/periodic/security/520.pfdenied and installed have the same CVS Id, deleting *** Temp ./etc/periodic/weekly/340.noid and installed have the same CVS Id, deleting *** Temp ./etc/periodic/weekly/999.local and installed have the same CVS Id, deleting *** Temp ./etc/periodic/weekly/310.locate and installed have the same CVS Id, deleting *** Temp ./etc/periodic/weekly/320.whatis and installed have the same CVS Id, deleting *** Temp ./etc/periodic/weekly/330.catman and installed have the same CVS Id, deleting *** Temp ./etc/periodic/weekly/400.status-pkg and installed have the same CVS Id, deleting *** Temp ./etc/ppp/ppp.conf and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/DAEMON and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/FILESYSTEMS and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/LOGIN and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/NETWORKING and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/SERVERS and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/abi and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/accounting and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/addswap and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/adjkerntz and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/amd and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/apm and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/apmd and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/archdep and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/atm1 and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/atm2 and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/atm3 and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/auditd and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/auto_linklocal and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/bgfsck and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/bluetooth and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/bootparams and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/bridge and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/bsnmpd and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/bthidd and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/ccd and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/cleanvar and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/cleartmp and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/cron and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/ddb and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/devd and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/devfs and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/dhclient and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/dmesg and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/dumpon and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/early.sh and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/encswap and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/fsck and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/ftp-proxy and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/ftpd and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/gbde and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/geli and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/geli2 and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/hcsecd and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/hostapd and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/hostid and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/hostname and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/idmapd and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/inetd and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/initrandom and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/ip6addrctl and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/ip6fw and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/ipfilter and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/ipfs and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/ipfw and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/ipmon and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/ipnat and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/ipsec and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/ipxrouted and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/isdnd and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/jail and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/kadmind and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/kerberos and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/keyserv and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/kldxref and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/kpasswdd and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/ldconfig and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/local and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/localpkg and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/lockd and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/lpd and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/mixer and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/motd and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/mountcritlocal and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/mountcritremote and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/mountlate and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/mdconfig and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/mdconfig2 and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/mountd and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/moused and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/mroute6d and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/mrouted and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/msgs and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/named and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/natd and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/netif and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/netoptions and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/network_ipv6 and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/newsyslog and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/nfsclient and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/nfsd and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/nfsserver and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/nisdomain and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/nsswitch and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/ntpd and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/ntpdate and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/othermta and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/pf and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/pflog and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/pfsync and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/powerd and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/power_profile and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/ppp and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/pppoed and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/pwcheck and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/quota and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/random and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/rarpd and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/resolv and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/rfcomm_pppd_server and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/root and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/route6d and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/routed and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/routing and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/rpcbind and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/rtadvd and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/rwho and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/tmp and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/savecore and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/sdpd and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/securelevel and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/sendmail and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/serial and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/sppp and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/statd and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/swap1 and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/syscons and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/sysctl and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/syslogd and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/timed and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/ugidfw and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/var and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/virecover and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/watchdogd and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/wpa_supplicant and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/ypbind and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/yppasswdd and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/ypserv and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/ypset and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/ypupdated and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/ypxfrd and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/zfs and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/sshd and installed have the same CVS Id, deleting *** Temp ./etc/rc.d/nscd and installed have the same CVS Id, deleting *** Temp ./etc/security/audit_class and installed have the same CVS Id, deleting *** Temp ./etc/security/audit_event and installed have the same CVS Id, deleting *** Temp ./etc/security/audit_control and installed have the same CVS Id, deleting *** Temp ./etc/security/audit_user and installed have the same CVS Id, deleting *** Temp ./etc/security/audit_warn and installed have the same CVS Id, deleting *** Temp ./etc/ssh/ssh_config and installed have the same CVS Id, deleting *** Temp ./etc/ssh/sshd_config and installed have the same CVS Id, deleting *** Temp ./etc/ssh/moduli and installed are the same, deleting *** Temp ./etc/ssl/openssl.cnf and installed have the same CVS Id, deleting *** Temp ./etc/auth.conf and installed have the same CVS Id, deleting *** Temp ./etc/crontab and installed have the same CVS Id, deleting *** Temp ./etc/devd.conf and installed have the same CVS Id, deleting *** Temp ./etc/devfs.conf and installed have the same CVS Id, deleting *** Temp ./etc/ddb.conf and installed have the same CVS Id, deleting *** Temp ./etc/dhclient.conf and installed have the same CVS Id, deleting *** Temp ./etc/disktab and installed have the same CVS Id, deleting *** Temp ./etc/fbtab and installed have the same CVS Id, deleting *** Temp ./etc/ftpusers and installed have the same CVS Id, deleting *** Temp ./etc/gettytab and installed have the same CVS Id, deleting *** Temp ./etc/group and installed have the same CVS Id, deleting *** Temp ./etc/hosts and installed have the same CVS Id, deleting *** Temp ./etc/hosts.allow and installed have the same CVS Id, deleting *** Temp ./etc/hosts.equiv and installed have the same CVS Id, deleting *** Temp ./etc/inetd.conf and installed have the same CVS Id, deleting *** Temp ./etc/libalias.conf and installed have the same CVS Id, deleting *** Temp ./etc/login.access and installed have the same CVS Id, deleting *** Temp ./etc/login.conf and installed have the same CVS Id, deleting *** Temp ./etc/mac.conf and installed have the same CVS Id, deleting *** ./etc/motd has not been user modified. *** ./etc/motd upgraded successfully *** Temp ./etc/netconfig and installed have the same CVS Id, deleting *** Temp ./etc/network.subr and installed have the same CVS Id, deleting *** Temp ./etc/networks and installed have the same CVS Id, deleting *** Temp ./etc/newsyslog.conf and installed have the same CVS Id, deleting *** Temp ./etc/nsswitch.conf and installed have the same CVS Id, deleting *** Temp ./etc/phones and installed have the same CVS Id, deleting *** Temp ./etc/profile and installed have the same CVS Id, deleting *** Temp ./etc/protocols and installed have the same CVS Id, deleting *** Temp ./etc/rc and installed have the same CVS Id, deleting *** Temp ./etc/rc.bsdextended and installed have the same CVS Id, deleting *** Temp ./etc/rc.firewall and installed have the same CVS Id, deleting *** Temp ./etc/rc.firewall6 and installed have the same CVS Id, deleting *** Temp ./etc/rc.initdiskless and installed have the same CVS Id, deleting *** Temp ./etc/rc.sendmail and installed have the same CVS Id, deleting *** Temp ./etc/rc.shutdown and installed have the same CVS Id, deleting *** Temp ./etc/rc.subr and installed have the same CVS Id, deleting *** Temp ./etc/remote and installed have the same CVS Id, deleting *** Temp ./etc/rpc and installed have the same CVS Id, deleting *** Temp ./etc/services and installed have the same CVS Id, deleting *** Temp ./etc/shells and installed have the same CVS Id, deleting *** Temp ./etc/sysctl.conf and installed have the same CVS Id, deleting *** Temp ./etc/syslog.conf and installed have the same CVS Id, deleting *** Temp ./etc/ttys and installed have the same CVS Id, deleting *** Temp ./etc/amd.map and installed have the same CVS Id, deleting *** Temp ./etc/apmd.conf and installed have the same CVS Id, deleting *** Temp ./etc/snmpd.config and installed have the same CVS Id, deleting *** Temp ./etc/freebsd-update.conf and installed have the same CVS Id, deleting *** Temp ./etc/locate.rc and installed have the same CVS Id, deleting *** Temp ./etc/hosts.lpd and installed have the same CVS Id, deleting *** Temp ./etc/printcap and installed have the same CVS Id, deleting *** Temp ./etc/mail.rc and installed are the same, deleting *** Temp ./etc/manpath.config and installed have the same CVS Id, deleting *** Temp ./etc/nscd.conf and installed have the same CVS Id, deleting *** Temp ./etc/portsnap.conf and installed have the same CVS Id, deleting *** Temp ./etc/pf.os and installed have the same CVS Id, deleting *** Temp ./etc/csh.cshrc and installed have the same CVS Id, deleting *** Temp ./etc/csh.login and installed have the same CVS Id, deleting *** Temp ./etc/csh.logout and installed have the same CVS Id, deleting *** Temp ./etc/netstart and installed have the same CVS Id, deleting *** Temp ./etc/pccard_ether and installed have the same CVS Id, deleting *** Temp ./etc/rc.suspend and installed have the same CVS Id, deleting *** Temp ./etc/rc.resume and installed have the same CVS Id, deleting *** Temp ./etc/master.passwd and installed have the same CVS Id, deleting *** Temp ./etc/nsmb.conf and installed have the same CVS Id, deleting *** Temp ./etc/opieaccess and installed have the same CVS Id, deleting *** Temp ./root/.k5login and installed have the same CVS Id, deleting *** Temp ./root/.profile and installed have the same CVS Id, deleting *** Temp ./root/.cshrc and installed have the same CVS Id, deleting *** Temp ./root/.login and installed have the same CVS Id, deleting *** Temp ./var/crash/minfree and installed are the same, deleting *** Temp ./var/named/etc/namedb/master/empty.db and installed have the same CVS Id, deleting *** Temp ./var/named/etc/namedb/master/localhost-forward.db and installed have the same CVS Id, deleting *** Temp ./var/named/etc/namedb/master/localhost-reverse.db and installed have the same CVS Id, deleting *** Temp ./var/named/etc/namedb/named.conf and installed have the same CVS Id, deleting *** Temp ./var/named/etc/namedb/named.root and installed have the same CVS Id, deleting *** Temp ./.profile and installed have the same CVS Id, deleting *** Temp ./.cshrc and installed have the same CVS Id, deleting *** Temp ./COPYRIGHT and installed have the same CVS Id, deleting *** Comparison complete *** Saving mtree database for future upgrades Do you wish to delete what is left of /var/tmp/temproot? [no] yes *** /var/tmp/temproot has been deleted *** You chose the automatic upgrade option for files that you did not alter on your system. The following were upgraded for you: /etc/motd  root@kg-quiet# ^D Script done on Mon May 4 23:55:07 2009 --Boundary_(ID_ViuTdbt408rA3J9o9Nv7wA)-- From owner-freebsd-stable@FreeBSD.ORG Mon May 4 22:34:07 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1B8A51065776 for ; Mon, 4 May 2009 22:34:07 +0000 (UTC) (envelope-from torfinn.ingolfsen@broadpark.no) Received: from osl1smout1.broadpark.no (osl1smout1.broadpark.no [80.202.4.58]) by mx1.freebsd.org (Postfix) with ESMTP id CCB2E8FC1F for ; Mon, 4 May 2009 22:34:06 +0000 (UTC) (envelope-from torfinn.ingolfsen@broadpark.no) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII Received: from osl1sminn1.broadpark.no ([80.202.4.59]) by osl1smout1.broadpark.no (Sun Java(tm) System Messaging Server 6.3-3.01 (built Jul 12 2007; 32bit)) with ESMTP id <0KJ500A9P5CTO860@osl1smout1.broadpark.no> for freebsd-stable@freebsd.org; Tue, 05 May 2009 00:34:05 +0200 (CEST) Received: from kg-v2.kg4.no ([80.202.83.38]) by osl1sminn1.broadpark.no (Sun Java(tm) System Messaging Server 6.3-3.01 (built Jul 12 2007; 32bit)) with SMTP id <0KJ5003EO5CTQ950@osl1sminn1.broadpark.no> for freebsd-stable@freebsd.org; Tue, 05 May 2009 00:34:05 +0200 (CEST) Date: Tue, 05 May 2009 00:34:05 +0200 From: Torfinn Ingolfsen To: freebsd-stable@freebsd.org Message-id: <20090505003405.52398ad2.torfinn.ingolfsen@broadpark.no> In-reply-to: <49FF5D9C.5060409@unsane.co.uk> References: <20090504225012.392fa49f.torfinn.ingolfsen@broadpark.no> <49FF5D9C.5060409@unsane.co.uk> X-Mailer: Sylpheed 2.6.0 (GTK+ 2.16.1; amd64-portbld-freebsd7.2) X-Face: "t9w2,-X@O^I`jVW\sonI3.,36KBLZE*AL[y9lL[PyFD*r_S:dIL9c[8Y>V42R0"!"yb_zN,f#%.[PYYNq; m"_0v; ~rUM2Yy!zmkh)3&U|u!=T(zyv,MHJv"nDH>OJ`t(@mil461d_B'Uo|'nMwlKe0Mv=kvV?Nh@>Hb<3s_z2jYgZhPb@?Wi^x1a~Hplz1.zH Subject: Re: RELENG_7 - has mergemaster changed logic since 7.2-RELEASE? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 22:34:07 -0000 On Mon, 04 May 2009 22:26:52 +0100 Vincent Hoffman wrote: > Not that its a cure but are master.passwd and group backups in > /var/backups any help to you in this case? Ah - great tip - thanks! (In case of the first server, the changes to group and passwd files were few, so I just re-did the changes from memory. The only part I had to look up was user and group mysql. So restoring from /var/backups would have been quicker.) -- Regards, Torfinn Ingolfsen From owner-freebsd-stable@FreeBSD.ORG Tue May 5 02:39:29 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 57764106564A for ; Tue, 5 May 2009 02:39:29 +0000 (UTC) (envelope-from yaol.leo@gmail.com) Received: from mail-fx0-f162.google.com (mail-fx0-f162.google.com [209.85.220.162]) by mx1.freebsd.org (Postfix) with ESMTP id B22F68FC14 for ; Tue, 5 May 2009 02:39:28 +0000 (UTC) (envelope-from yaol.leo@gmail.com) Received: by fxm6 with SMTP id 6so4195936fxm.43 for ; Mon, 04 May 2009 19:39:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=pC4NeYM7rt+vei5ekCoGOIWO7nJyuIuNakfOxKULz4I=; b=Fr6K9T5QTlXt5y2ztlWkAPtdrvSQ/jBP7RWIqJTrG18DtrCcFUMtbn/vcPgToEIQPQ om0GA7xazna1T78dwaWDjyTyQf2crV1XT2kkOzOlKpBP55LtE91l59viUCbnqswYnRSH 8PqMLj7j4dRvFLywmDzagV0IjI8xLLL0uoSwo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=Gqb3d8HGHutzWNCUEdD4h02pH62tqOPsK+WrCRXyVpjtujD1bGeLmo0KG/z5qmhlw1 3OVXg8/2O4y0SqLynkJSgobujd/ga8HiOBgHXXmOUdwNg8WIDnRtwgvSLzXT6WUOqV0W venqtkjAP0ZmoYVChxRunw3WmPLoU05qsOe7E= Received: by 10.86.82.6 with SMTP id f6mr6514611fgb.79.1241491167405; Mon, 04 May 2009 19:39:27 -0700 (PDT) Received: from ?10.74.113.17? ([64.104.127.198]) by mx.google.com with ESMTPS id d6sm12023987fga.17.2009.05.04.19.39.23 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 04 May 2009 19:39:25 -0700 (PDT) Message-ID: <49FFA6D8.7090508@gmail.com> Date: Tue, 05 May 2009 10:39:20 +0800 From: Leo User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Bruce Simpson References: <49FEC0AD.7090506@gmail.com> <49FF014F.7070107@incunabulum.net> <49FF09E1.5010306@gmail.com> <49FF12A0.3010009@incunabulum.net> In-Reply-To: <49FF12A0.3010009@incunabulum.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: Help! regarding libpcap. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 02:39:29 -0000 Bruce Simpson wrote: > Leo wrote: >> >> I don't have other pcap lib installed on this box. Previously >> installed a libpcap 0.9 on this box , But I've deleted this version. >> On my box, not enable BPF. Let me try if enable the feature. > > That's probably what it is. Can you try the following: > * give pcap configure --with-pcap=bpf WITHOUT having bpf in your > kernel config. > * try enabling bpf in kernel config and building the port as usual. > > Most likely libpcap's new configure script is detecting the lack of > /dev/bpf* and assuming there is no packet capture support in the > system. This needs to be fixed for cross compiling to be possible. If > you could try at least the first fix then this is the answer. > > thanks, > BMS > > Hi Bruce, I've tried 2 method on my box. that you previously mentioned. Both of these 2 method can build successfully! Thank your for your help!! Best Regards! -Leo From owner-freebsd-stable@FreeBSD.ORG Tue May 5 03:41:37 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B3696106568C; Tue, 5 May 2009 03:41:37 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-fx0-f162.google.com (mail-fx0-f162.google.com [209.85.220.162]) by mx1.freebsd.org (Postfix) with ESMTP id E8E288FC27; Tue, 5 May 2009 03:41:36 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: by fxm6 with SMTP id 6so4217631fxm.43 for ; Mon, 04 May 2009 20:41:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=EKCcalFeVAxJX9h187YvxRIBA0ubyNIIHIQq6X+bnAA=; b=VStTyXLzUcvJN2EGJeaC+I7HLpyUpeBc5NPzyikn7QC1QpDJBqsm6rjnUfdr2A1NDK BtB8/ndi2N9eFaObbL8NvY6hHMvvAMKSuMXgdkwn9TeGSCFdFpT9ntRphKret0m4sPO6 MBuaZaPLghHVnp8FBfGN0eGK02UpVFGtBw6TI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=NAOiOgeRdhFrq5Lwn7bg+/P5XE8eClPEK6KWM0oTLUtgizhGEEmw4iib6sE4XE5+rS 4kliGY8OIEqsCU8mrHJcSyNq1heflrxaLYor9OsJF+RfN3tkBARRiRdRzyWz3KpHz2mD zeKvGItLLFGHHBHwQMPpx6r2whmDHRH59QM7s= MIME-Version: 1.0 Received: by 10.103.175.9 with SMTP id c9mr4100382mup.3.1241494895966; Mon, 04 May 2009 20:41:35 -0700 (PDT) In-Reply-To: <200905010949.45927.jhb@freebsd.org> References: <200905010949.45927.jhb@freebsd.org> Date: Tue, 5 May 2009 07:41:35 +0400 Message-ID: From: pluknet To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: lock up in 6.2 (procs massively stuck in Giant) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 03:41:38 -0000 2009/5/1 John Baldwin : > On Thursday 30 April 2009 2:36:34 am pluknet wrote: >> Hi folks. >> >> Today I got a new locking issue. >> This is the first time I got it, and it's merely reproduced. >> >> The box has lost both remote connection and local access. >> No SIGINFO output on the local console even. >> Jumping in ddb> shows the next: >> >> 1) first, this is a 8-way web server. No processes on runqueue except one > httpd >> (i.e. ps shows R in its state): > > You need to find who owns Giant and what that thread is doing. You can try > using 'show lock Giant' as well as 'show lockchain 11568'. > Hi, John! Just reproduced now on another box. Hmm.. stack of the process owing Giant looks garbled. db> show lock Giant class: sleep mutex name: Giant flags: {DEF, RECURSE} state: {OWNED, CONTESTED} owner: 0xd0d79320 (tid 102754, pid 34594, "httpd") db> show lockchain 34594 thread 102754 (pid 34594, httpd) running on CPU 7 db> show lockchain 102754 thread 102754 (pid 34594, httpd) running on CPU 7 db> bt 102754 Tracing pid 34594 tid 102754 td 0xd0d79320 sched_switch(2,2,1,f1a3fb3c,c08a55d9,...) at sched_switch+0x143 MAXCPU(e5895590,62e85356,e8000110,ffffa3d5,ffb988e8,...) at 0xf7 *** error reading from address f8658d94 *** What can I do else? db> show allpcpu Current CPU: 1 cpuid = 0 curthread = 0xcd963960: pid 95678 "httpd" curpcb = 0xf0593d90 fpcurthread = none idlethread = 0xc7cfeaf0: pid 17 "idle: cpu0" APIC ID = 0 currentldt = 0x50 cpuid = 1 curthread = 0xc7dfaaf0: pid 40 "swi0: sio" curpcb = 0xe82ebd90 fpcurthread = none idlethread = 0xc7cfe000: pid 16 "idle: cpu1" APIC ID = 1 currentldt = 0x50 cpuid = 2 curthread = 0xca8aa640: pid 31167 "httpd" curpcb = 0xf1279d90 fpcurthread = none idlethread = 0xc7cfde10: pid 15 "idle: cpu2" APIC ID = 2 currentldt = 0x50 cpuid = 3 curthread = 0xc8b62e10: pid 17221 "httpd" curpcb = 0xee951d90 fpcurthread = none idlethread = 0xc7cfdc80: pid 14 "idle: cpu3" APIC ID = 3 currentldt = 0x50 cpuid = 4 curthread = 0xca1f2c80: pid 39078 "httpd" curpcb = 0xeec17d90 fpcurthread = none idlethread = 0xc7cfdaf0: pid 13 "idle: cpu4" APIC ID = 4 currentldt = 0x50 cpuid = 5 curthread = 0xcd423af0: pid 74960 "httpd" curpcb = 0xf03f2d90 fpcurthread = none idlethread = 0xc7cfd960: pid 12 "idle: cpu5" APIC ID = 5 currentldt = 0x50 cpuid = 6 curthread = 0xcaa89c80: pid 23426 "httpd" curpcb = 0xef1aed90 fpcurthread = none idlethread = 0xc7cfd7d0: pid 11 "idle: cpu6" APIC ID = 6 currentldt = 0x50 cpuid = 7 curthread = 0xd0d79320: pid 34594 "httpd" curpcb = 0xf1a3fd90 fpcurthread = none idlethread = 0xc7cfd640: pid 10 "idle: cpu7" APIC ID = 7 currentldt = 0x50 -- wbr, pluknet From owner-freebsd-stable@FreeBSD.ORG Tue May 5 03:47:14 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4AA0710656A8 for ; Tue, 5 May 2009 03:47:14 +0000 (UTC) (envelope-from david@usermode.org) Received: from proxy.meer.net (proxy.meer.net [64.13.141.13]) by mx1.freebsd.org (Postfix) with ESMTP id 2FCE58FC24 for ; Tue, 5 May 2009 03:47:14 +0000 (UTC) (envelope-from david@usermode.org) Received: from mail.meer.net (mail.meer.net [64.13.141.3]) by proxy.meer.net (8.14.3/8.14.3) with ESMTP id n453FYHI062723 for ; Mon, 4 May 2009 20:15:34 -0700 (PDT) (envelope-from david@usermode.org) Received: from radagast.usermode.org (netblock-66-245-217-76.dslextreme.com [66.245.217.76]) by mail.meer.net (8.13.3/8.13.3/meer) with ESMTP id n453FTFr015228 for ; Mon, 4 May 2009 20:15:29 -0700 (PDT) (envelope-from david@usermode.org) From: David Johnson To: freebsd-stable@freebsd.org Date: Mon, 4 May 2009 20:15:29 -0700 User-Agent: KMail/1.11.2 (FreeBSD/7.2-RELEASE; KDE/4.2.2; i386; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200905042015.29394.david@usermode.org> X-Spam-Score: undef - spam scanning disabled X-CanIt-Geo: ip=64.13.141.3; country=US; region=CA; city=Mountain View; latitude=37.3974; longitude=-122.0732; metrocode=807; areacode=650; http://maps.google.com/maps?q=37.3974,-122.0732&z=6 X-CanItPRO-Stream: default X-Canit-Stats-ID: Bayes signature not available X-Scanned-By: CanIt (www . roaringpenguin . com) on 64.13.141.13 Subject: Xorg hangs with drmwtq in 7.2-RELEASE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 03:47:14 -0000 This topic has been recently discussed twice before in the past month and a half, but without resolution. It now reappears on my system as I upgrade to 7.2-RELEASE. It does not happen with a build from RELENG_7 date=2009.03.13. I am desperately hoping for a resolution. To reiterate the problem: Xorg will occassionally hang. This only happens when compositing it enabled. I am using KDE 4.2.2, radeon driver, all ports updated to this morning. About a third of the time the kernel locks up, and I cannot ssh into the system. The other half of the time I can ssh into the system. There I notice that Xorg has the state of "drmwtq", with perhaps some other GUI processes in the same state. The video card is a Radeon X1550. I have tried with and without AGPMode set, and both XAA and EXA render modes. No change. You can look at my xorg.conf and Xorg log at: http://www.usermode.org/misc/xorg.conf http://www.usermode.org/misc/Xorg.0.log.old p.s. Posting to freebsd-stable, as this problem has been previously discussed here. If this is no longer the appropriate list, please let me know. Thank you, -- David Johnson From owner-freebsd-stable@FreeBSD.ORG Tue May 5 06:20:37 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 10ABE106564A for ; Tue, 5 May 2009 06:20:37 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id C98AD8FC08 for ; Tue, 5 May 2009 06:20:36 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from [192.168.1.4] (adsl-19-214-20.bna.bellsouth.net [68.19.214.20]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id n456KVxE065034 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 May 2009 02:20:31 -0400 (EDT) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: David Johnson In-Reply-To: <200905042015.29394.david@usermode.org> References: <200905042015.29394.david@usermode.org> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-KMR4JhjSr3Fv0cSrcIRO" Organization: FreeBSD Date: Tue, 05 May 2009 01:20:17 -0500 Message-Id: <1241504417.1828.19.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1.1 FreeBSD GNOME Team Port X-Spam-Status: No, score=-3.2 required=5.0 tests=AWL,BAYES_00,RDNS_DYNAMIC autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: freebsd-stable@freebsd.org Subject: Re: Xorg hangs with drmwtq in 7.2-RELEASE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 06:20:37 -0000 --=-KMR4JhjSr3Fv0cSrcIRO Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 2009-05-04 at 20:15 -0700, David Johnson wrote: > This topic has been recently discussed twice before in the past month and= a=20 > half, but without resolution. It now reappears on my system as I upgrade = to=20 > 7.2-RELEASE. It does not happen with a build from RELENG_7 date=3D2009.03= .13. I=20 > am desperately hoping for a resolution. >=20 > To reiterate the problem: Xorg will occassionally hang. This only happens= when=20 > compositing it enabled. I am using KDE 4.2.2, radeon driver, all ports up= dated=20 > to this morning. About a third of the time the kernel locks up, and I can= not=20 > ssh into the system. The other half of the time I can ssh into the system= .=20 > There I notice that Xorg has the state of "drmwtq", with perhaps some oth= er=20 > GUI processes in the same state. >=20 > The video card is a Radeon X1550. I have tried with and without AGPMode s= et,=20 > and both XAA and EXA render modes. No change. >=20 > You can look at my xorg.conf and Xorg log at: > http://www.usermode.org/misc/xorg.conf > http://www.usermode.org/misc/Xorg.0.log.old >=20 > p.s. Posting to freebsd-stable, as this problem has been previously discu= ssed=20 > here. If this is no longer the appropriate list, please let me know. Unfortunately, hanging in drmwtq isn't really that informative... What this says is that we have submitted commands to the GPU and are waiting on it to process them. When userland tells us to wait for the event, we check to see if the card has already processed the command. If it has, then we just return immediately. If it hasn't, then we sleep waiting on an interrupt from the card once it has processed the command. We will sleep for at most 3 seconds, but userland (via libdrm) will just keep asking us over and over. This generally suggests that the GPU is locked up... Given that you say sometimes it locks up hard (usually a panic, that you can't see since X is running) and other times only X is stalled it might be related to this patch, if you haven't tried this on already. http://people.freebsd.org/~rnoland/drm_radeon-copyin-fix-try2.patch I would usually suggest that you try AGPMode 1, but since you have already tried PCI mode, that should rule that out. You should be using EXA on this card, but having tried XAA is also good for a sanity check. I rarely get to run a card for very long anymore... I end up swapping cards out a few times a day lately, but I have recently been running an x600 pcie (r300) with compiz for at least several hours without issue. If you can figure out a way to reproduce it, or manage to get a core file from one of the panics that would help. Preferably without involving KDE, since I don't run it... I have also run an x1650 PCI-E somewhat recently, which is the closest I have to your card, though I don't remember exactly how long ago it was that I ran it for more than an hour. Probably 2 or 3 weeks ago. robert. > Thank you, --=20 Robert Noland FreeBSD --=-KMR4JhjSr3Fv0cSrcIRO Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEABECAAYFAkn/2qEACgkQM4TrQ4qfROMyLgCfXPI5R5f6OiMK5T538H4eQjHH cvAAnReLnHaElAcifouqNSAZdHSW2Gqe =FqRf -----END PGP SIGNATURE----- --=-KMR4JhjSr3Fv0cSrcIRO-- From owner-freebsd-stable@FreeBSD.ORG Tue May 5 08:01:33 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5B2571065672 for ; Tue, 5 May 2009 08:01:33 +0000 (UTC) (envelope-from danger@FreeBSD.org) Received: from services.rulez.sk (services.rulez.sk [92.240.234.125]) by mx1.freebsd.org (Postfix) with ESMTP id 1275A8FC15 for ; Tue, 5 May 2009 08:01:32 +0000 (UTC) (envelope-from danger@FreeBSD.org) Received: from localhost (services.rulez.sk [92.240.234.125]) by services.rulez.sk (Postfix) with ESMTP id 6C8EA133447A; Tue, 5 May 2009 09:46:32 +0200 (CEST) X-Virus-Scanned: amavisd-new at rulez.sk Received: from services.rulez.sk ([92.240.234.125]) by localhost (services.rulez.sk [92.240.234.125]) (amavisd-new, port 10024) with ESMTP id 6+wWJD+mqOwU; Tue, 5 May 2009 09:46:31 +0200 (CEST) Received: from [10.50.0.2] (danger.mcrn.sk [84.16.37.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: danger@rulez.sk) by services.rulez.sk (Postfix) with ESMTPSA id 8EA981334421; Tue, 5 May 2009 09:46:31 +0200 (CEST) Message-ID: <49FFEECE.20403@FreeBSD.org> Date: Tue, 05 May 2009 09:46:22 +0200 From: Daniel Gerzo Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Manolis Kiagias References: <20090504225012.392fa49f.torfinn.ingolfsen@broadpark.no> <49FF5901.600@gmail.com> In-Reply-To: <49FF5901.600@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Torfinn Ingolfsen , freebsd-stable@freebsd.org Subject: Re: RELENG_7 - has mergemaster changed logic since 7.2-RELEASE? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 08:01:33 -0000 Manolis Kiagias wrote: > I always use -iU too. > I've lost motd, passwd, group and master.passwd > During mergemaster -p I was asked to merge changes to some of these, and > still they were replaced with the newer versions. I don't know what went > wrong but have restored them from backup. (I always tar /etc before a > source upgrade). Upgrading another system using freebsd-update did not > cause any problem. I have the same experience while I was upgrading a few machines upgrading from RELENG_7 to RELENG_7_2. I haven't experienced when upgrading from 7.1-R to 7.2-R. Here auth.conf, csh.cshrc, hosts, crontab, syslogd.conf, passswd, master.passwd, group, sysctl.conf motd and maybe some more got overwritten :-( I had to restore from backups. -- S pozdravom / Best regards Daniel Gerzo, FreeBSD committer From owner-freebsd-stable@FreeBSD.ORG Tue May 5 09:40:01 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A6BCD106566B for ; Tue, 5 May 2009 09:40:01 +0000 (UTC) (envelope-from lists@reiteration.net) Received: from smtp1.servage.net (smtp1.servage.net [77.232.76.11]) by mx1.freebsd.org (Postfix) with ESMTP id 5DE9B8FC08 for ; Tue, 5 May 2009 09:40:01 +0000 (UTC) (envelope-from lists@reiteration.net) Received: from [127.0.0.1] (roobarb.growveg.org [62.49.247.174]) by smtp1.servage.net (Postfix) with ESMTP id 389B4F985DA; Tue, 5 May 2009 09:39:59 +0000 (GMT) Message-ID: <4A00096D.50801@reiteration.net> Date: Tue, 05 May 2009 10:39:57 +0100 From: John User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: John , FreeBSD Stable References: <49FEA6D1.2080503@reiteration.net> <20090504090029.GF1006@rwpc12.mby.riverwillow.net.au> In-Reply-To: <20090504090029.GF1006@rwpc12.mby.riverwillow.net.au> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 090504-1, 04/05/2009), Outbound message X-Antivirus-Status: Clean Cc: Subject: Re: cvsup.uk.freebsd.org appears to not be serving X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 09:40:05 -0000 John Marshall wrote: > You are obviously connecting OK; it's just that the server is already as > busy as it's minder is willing to let it be. Perhaps you'd be better > off choosing something other than 03:00 as a starting point? Maybe... but I think that would make no odds, because although it started at 0300, it subsequently retried at different times throughout the following week. >> Establishing passive-mode data connection >> Cannot connect to data port: Connection refused >> Will retry at 03:18:04 >> Retrying > > Don't do that! Use multiplexed mode "-P m" (from the cvsup man page, > "All but multiplexed mode are deprecated"); or use csup which does > multiplexed mode by default. OK I'm using -P m now on all the freebsd boxes. Still using cvsup4.uk, will try again with cvsup.uk when I've got more time, and if necessary report the issue to -hubs. cheers, -- John From owner-freebsd-stable@FreeBSD.ORG Tue May 5 09:48:09 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8F5F810656FC for ; Tue, 5 May 2009 09:48:09 +0000 (UTC) (envelope-from chris#@1command.com) Received: from mail.1command.com (dsl081-172-045.sea1.dsl.speakeasy.net [64.81.172.45]) by mx1.freebsd.org (Postfix) with ESMTP id 3A84B8FC12 for ; Tue, 5 May 2009 09:48:08 +0000 (UTC) (envelope-from chris#@1command.com) Received: from mail.1command.com (localhost.1command.com [127.0.0.1]) by mail.1command.com (8.13.3/8.13.3) with ESMTP id n459m0rI029322 for ; Tue, 5 May 2009 02:48:06 -0700 (PDT) (envelope-from chris#@1command.com) Received: (from www@localhost) by mail.1command.com (8.13.3/8.13.3/Submit) id n459m0cK029321 for freebsd-stable@freebsd.org; Tue, 5 May 2009 02:48:00 -0700 (PDT) (envelope-from chris#@1command.com) Received: from hitme.hitometer.net (hitme.hitometer.net [64.81.172.194]) by webmail.1command.com (H.R. Communications Messaging System) with HTTP; Tue, 05 May 2009 02:48:00 -0700 Message-ID: <20090505024800.tk0saqntsgk8kk8c@webmail.1command.com> X-Priority: 3 (Normal) Date: Tue, 05 May 2009 02:48:00 -0700 From: Chris H To: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: H.R. Communications Internet Messaging System (HCIMS) 4.1 Professional (not for redistribution) / UNIX Subject: GEOM_STRIPE: Cannot add disk da2c to st0 (error=17). X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 09:48:10 -0000 Greetings, I'm attempting to upgrade one of our servers to 6.4 (from 6.2) Before doing so I need to stripe 3 identical drives on the same SCSI port into one drive, the drives are on an LSI controller with 2 ports: May 5 02:10:15 hitme kernel: sym0: <1010-66> port 0xe400-0xe4ff mem 0xfebe0000-0xfebe03ff,0xfebd8000-0xfebd9fff irq 29 at device 6.0 on pci1 May 5 02:10:15 hitme kernel: sym0: Reserved 0x400 bytes for rid 0x14 type 3 at 0xfebe0000 May 5 02:10:15 hitme kernel: sym0: Reserved 0x2000 bytes for rid 0x1c type 3 at 0xfebd8000 May 5 02:10:15 hitme kernel: sym0: Symbios NVRAM, ID 7, Fast-80, LVD, parity checking May 5 02:10:15 hitme kernel: sym0: open drain IRQ line driver, using on-chip SRAM May 5 02:10:15 hitme kernel: sym0: using LOAD/STORE-based firmware. May 5 02:10:15 hitme kernel: sym0: handling phase mismatch from SCRIPTS. May 5 02:10:15 hitme kernel: sym0: initial SCNTL3/DMODE/DCNTL/CTEST3/4/5 = (hex) 00/4e/a0/01/00/04 May 5 02:10:15 hitme kernel: sym0: final SCNTL3/DMODE/DCNTL/CTEST3/4/5 = (hex) 00/4e/80/01/08/04 May 5 02:10:15 hitme kernel: ioapic1: routing intpin 13 (PCI IRQ 29) to vector 52 May 5 02:10:15 hitme kernel: sym0: [GIANT-LOCKED] May 5 02:10:15 hitme kernel: sym0: enabling clock multiplier May 5 02:10:15 hitme kernel: sym0: Downloading SCSI SCRIPTS. May 5 02:10:15 hitme kernel: sym1: <1010-66> port 0xe800-0xe8ff mem 0xfebf8000-0xfebf83ff,0xfebf0000-0xfebf1fff irq 28 at device 6.1 on pci1 May 5 02:10:15 hitme kernel: sym1: Reserved 0x400 bytes for rid 0x14 type 3 at 0xfebf8000 May 5 02:10:15 hitme kernel: sym1: Reserved 0x2000 bytes for rid 0x1c type 3 at 0xfebf0000 May 5 02:10:15 hitme kernel: sym1: Symbios NVRAM, ID 7, Fast-80, SE, parity checking May 5 02:10:15 hitme kernel: sym1: open drain IRQ line driver, using on-chip SRAM May 5 02:10:15 hitme kernel: sym1: using LOAD/STORE-based firmware. May 5 02:10:15 hitme kernel: sym1: handling phase mismatch from SCRIPTS. May 5 02:10:15 hitme kernel: sym1: initial SCNTL3/DMODE/DCNTL/CTEST3/4/5 = (hex) 00/4e/a0/01/00/04 May 5 02:10:15 hitme kernel: sym1: final SCNTL3/DMODE/DCNTL/CTEST3/4/5 = (hex) 00/4e/80/01/08/04 the drives are identical 17.5Gb U160 drives (unused) May 5 02:10:15 hitme kernel: pass0: Fixed Direct Access SCSI-3 device May 5 02:10:15 hitme kernel: pass0: Serial Number ZE0E4501 May 5 02:10:15 hitme kernel: pass0: 160.000MB/s transfers (80.000MHz, offset 62, 16bit), Tagged Queueing Enabled May 5 02:10:15 hitme kernel: pass1 at sym0 bus 0 target 1 lun 0 May 5 02:10:15 hitme kernel: pass1: Fixed Direct Access SCSI-3 device May 5 02:10:15 hitme kernel: pass1: Serial Number ZE0G1630 May 5 02:10:15 hitme kernel: pass1: 160.000MB/s transfers (80.000MHz, offset 62, 16bit), Tagged Queueing Enabled May 5 02:10:15 hitme kernel: pass2 at sym0 bus 0 target 2 lun 0 May 5 02:10:15 hitme kernel: pass2: Fixed Direct Access SCSI-3 device May 5 02:10:15 hitme kernel: pass2: Serial Number ZE0B4449 May 5 02:10:15 hitme kernel: pass2: 160.000MB/s transfers (80.000MHz, offset 62, 16bit), Tagged Queueing Enabled May 5 02:10:15 hitme kernel: pass3 at sym1 bus 0 target 3 lun 0 The current system (6.2) is on a single drive on the other SCSI port (IBM - identical to the others). However, when I attempt to stripe the 3 unused drives, I recieve an error regarding da2: gstripe label -v st0 /dev/da0 /dev/da1 /dev/da2 GEOM_STRIPE: Device st0 created (id=2607126992). GEOM_STRIPE: Disk da0 attached to st0. Metadata value stored on /dev/da0. GEOM_STRIPE: Disk da1 attached to st0. Metadata value stored on /dev/da1. GEOM_STRIPE: Disk da2 attached to st0. GEOM_STRIPE: Device st0 activated. GEOM_STRIPE: Cannot add disk da2c to st0 (error=17). Metadata value stored on /dev/da2. I blanked the 3 drives prior to attempting any of this, and it's on a fresh reboot. I'm afraid I don't know how to proceed. Is it a problem with gstripe(8)? I /really/ need to stripe these drives so as to upgrade the system. Thank you for all your time and consideration in this matter. Sincerely, Chris H From owner-freebsd-stable@FreeBSD.ORG Tue May 5 10:27:03 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 70EA91065672 for ; Tue, 5 May 2009 10:27:03 +0000 (UTC) (envelope-from hk@alogis.com) Received: from alogis.com (firewall.solit-ag.de [212.184.102.1]) by mx1.freebsd.org (Postfix) with ESMTP id 957128FC08 for ; Tue, 5 May 2009 10:27:02 +0000 (UTC) (envelope-from hk@alogis.com) Received: from alogis.com (localhost [127.0.0.1]) by alogis.com (8.13.4/8.13.1) with ESMTP id n45AD1uu031793; Tue, 5 May 2009 12:13:01 +0200 (CEST) (envelope-from hk@alogis.com) Received: (from hk@localhost) by alogis.com (8.13.4/8.13.1/Submit) id n45AD1mP031792; Tue, 5 May 2009 12:13:01 +0200 (CEST) (envelope-from hk) Date: Tue, 5 May 2009 12:13:01 +0200 From: Holger Kipp To: Chris H Message-ID: <20090505101301.GA31143@intserv.int1.b.intern> References: <20090505024800.tk0saqntsgk8kk8c@webmail.1command.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090505024800.tk0saqntsgk8kk8c@webmail.1command.com> User-Agent: Mutt/1.4.2.1i Cc: freebsd-stable@freebsd.org Subject: Re: GEOM_STRIPE: Cannot add disk da2c to st0 (error=17). X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 10:27:03 -0000 On Tue, May 05, 2009 at 02:48:00AM -0700, Chris H wrote: > Greetings, > I'm attempting to upgrade one of our servers to 6.4 (from 6.2) > Before doing so I need to stripe 3 identical drives on the > same SCSI port into one drive, the drives are on an LSI controller > with 2 ports: [..] > However, when I attempt to stripe the 3 unused drives, I recieve an > error regarding da2: > > gstripe label -v st0 /dev/da0 /dev/da1 /dev/da2 > GEOM_STRIPE: Device st0 created (id=2607126992). > GEOM_STRIPE: Disk da0 attached to st0. > Metadata value stored on /dev/da0. > GEOM_STRIPE: Disk da1 attached to st0. > Metadata value stored on /dev/da1. > GEOM_STRIPE: Disk da2 attached to st0. > GEOM_STRIPE: Device st0 activated. > GEOM_STRIPE: Cannot add disk da2c to st0 (error=17). > Metadata value stored on /dev/da2. > > I blanked the 3 drives prior to attempting any of this, and it's > on a fresh reboot. I'm afraid I don't know how to proceed. Is it > a problem with gstripe(8)? I /really/ need to stripe these drives > so as to upgrade the system. Can you check if you have any fdisk metadata on either of your disks? Especially as da0, da1, da2 are attached to st0 without problems, but then GEOM_STRIPE complains about da2c (which looks like a partition entry)... Mind you, this is just a wild guess from my side ;-) Regards, Holger From owner-freebsd-stable@FreeBSD.ORG Tue May 5 11:06:27 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 02536106564A for ; Tue, 5 May 2009 11:06:27 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from megatron.madpilot.net (megatron.madpilot.net [88.149.173.206]) by mx1.freebsd.org (Postfix) with ESMTP id 192A38FC17 for ; Tue, 5 May 2009 11:06:25 +0000 (UTC) (envelope-from mad@madpilot.net) Received: by megatron.madpilot.net (Postfix, from userid 1000) id DF4EC130C54; Tue, 5 May 2009 13:06:24 +0200 (CEST) Date: Tue, 5 May 2009 13:06:24 +0200 From: Guido Falsi To: freebsd-stable@freebsd.org Message-ID: <20090505110624.GA83487@megatron.madpilot.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Operating-System: FreeBSD 7.1-STABLE User-Agent: Mutt/1.5.19 (2009-01-05) Subject: [PANIC] recent 7.2-STABLE when probing drm X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 11:06:27 -0000 Hi! I'm using FreeBSD/i386 stable on a HP DC7800 PC. It has an Intel Q35 graphic chip. After upgrading to a recent stable I experienced a pani on boot, just after probing drm. I investigated a little and found out that reverting the file src/sys/dev/pci/pci.c to rev. 1.355.2.9 (SVN Rev 190092) solves the crash. I could not investigatte urther right away, but some regression was introduced with this rev. Is any more information needed? Thank you in advance for any help or information on this. Here is the dmesg from the working kernel the other one panics just after the line marked with [*]: Copyright (c) 1992-2009 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.2-STABLE #16: Tue May 5 12:32:40 CEST 2009 root@vwg82.hq.ignesti.it:/usr/obj/usr/src/sys/VWG82 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 Duo CPU E6550 @ 2.33GHz (2327.51-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6fb Stepping = 11 Features=0xbfebfbff Features2=0xe3fd AMD Features=0x20100000 AMD Features2=0x1 Cores per package: 2 real memory = 3740987392 (3567 MB) avail memory = 3661430784 (3491 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 1 ioapic0 irqs 0-23 on motherboard netsmb_dev: loaded kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, dff00000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0xf808-0xf80b on acpi0 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 vgapci0: port 0x1230-0x1237 mem 0xf0100000-0xf017ffff,0xe0000000-0xefffffff,0xf0000000-0xf00fffff irq 16 at device 2.0 on pci0 agp0: on vgapci0 agp0: detected 6140k stolen memory agp0: aperture size is 256M drm0: on vgapci0 [*] vgapci0: child drm0 requested pci_enable_busmaster info: [drm] AGP at 0xe0000000 256MB info: [drm] Initialized i915 1.6.0 20080730 pci0: at device 3.0 (no driver attached) atapci0: port 0x1238-0x123f,0x1270-0x1273,0x1240-0x1247,0x1274-0x1277,0x11e0-0x11ef irq 18 at device 3.2 on pci0 atapci0: [ITHREAD] ata2: on atapci0 ata2: [ITHREAD] ata3: on atapci0 ata3: [ITHREAD] pci0: at device 3.3 (no driver attached) em0: port 0x1100-0x111f mem 0xf0180000-0xf019ffff,0xf01a5000-0xf01a5fff irq 19 at device 25.0 on pci0 em0: Using MSI interrupt em0: [FILTER] em0: Ethernet address: 00:1e:0b:ab:e6:a7 uhci0: port 0x1120-0x113f irq 20 at device 26.0 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0x1140-0x115f irq 21 at device 26.1 on pci0 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0x1160-0x117f irq 22 at device 26.2 on pci0 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb2: on uhci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered ehci0: mem 0xf01a6000-0xf01a63ff irq 22 at device 26.7 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb3: EHCI version 1.0 usb3: companion controllers, 2 ports each: usb0 usb1 usb2 usb3: on ehci0 usb3: USB revision 2.0 uhub3: on usb3 uhub3: 6 ports with 6 removable, self powered hdac0: mem 0xf01a0000-0xf01a3fff irq 21 at device 27.0 on pci0 hdac0: HDA Driver Revision: 20090329_0131 hdac0: [ITHREAD] pcib1: at device 28.0 on pci0 pci32: on pcib1 pcib2: irq 21 at device 28.1 on pci0 pci48: on pcib2 uhci3: port 0x1180-0x119f irq 20 at device 29.0 on pci0 uhci3: [GIANT-LOCKED] uhci3: [ITHREAD] usb4: on uhci3 usb4: USB revision 1.0 uhub4: on usb4 uhub4: 2 ports with 2 removable, self powered uhci4: port 0x11a0-0x11bf irq 21 at device 29.1 on pci0 uhci4: [GIANT-LOCKED] uhci4: [ITHREAD] usb5: on uhci4 usb5: USB revision 1.0 uhub5: on usb5 uhub5: 2 ports with 2 removable, self powered ehci1: mem 0xf01a6400-0xf01a67ff irq 20 at device 29.7 on pci0 ehci1: [GIANT-LOCKED] ehci1: [ITHREAD] usb6: EHCI version 1.0 usb6: companion controllers, 2 ports each: usb4 usb5 usb6: on ehci1 usb6: USB revision 2.0 uhub6: on usb6 uhub6: 4 ports with 4 removable, self powered pcib3: at device 30.0 on pci0 pci7: on pcib3 isab0: at device 31.0 on pci0 isa0: on isab0 atapci1: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x11f0-0x11ff,0x1200-0x120f irq 18 at device 31.2 on pci0 ata0: on atapci1 ata0: [ITHREAD] ata1: on atapci1 ata1: [ITHREAD] atapci2: port 0x1260-0x1267,0x1280-0x1283,0x1268-0x126f,0x1284-0x1287,0x1210-0x121f,0x1220-0x122f irq 18 at device 31.5 on pci0 atapci2: [ITHREAD] ata4: on atapci2 ata4: [ITHREAD] ata5: on atapci2 ata5: [ITHREAD] acpi_button0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] sio0: port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio0: [FILTER] cpu0: on acpi0 est0: on cpu0 p4tcc0: on cpu0 cpu1: on acpi0 est1: on cpu1 p4tcc1: on cpu1 pmtimer0 on isa0 ppc0: at port 0x378-0x37f irq 7 on isa0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/13 bytes threshold ppbus0: on ppc0 ppbus0: [ITHREAD] plip0: on ppbus0 plip0: WARNING: using obsoleted IFF_NEEDSGIANT flag lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 ppc0: [GIANT-LOCKED] ppc0: [ITHREAD] sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ums0: on uhub2 ums0: 16 buttons and Z dir. uhid0: on uhub2 -- Guido Falsi From owner-freebsd-stable@FreeBSD.ORG Tue May 5 11:12:37 2009 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2E3E11065673 for ; Tue, 5 May 2009 11:12:37 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from mail-gw1.york.ac.uk (mail-gw1.york.ac.uk [144.32.128.246]) by mx1.freebsd.org (Postfix) with ESMTP id B23328FC1A for ; Tue, 5 May 2009 11:12:36 +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-gw1.york.ac.uk (8.13.6/8.13.6) with ESMTP id n45BCX1C019956; Tue, 5 May 2009 12:12:33 +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.68) (envelope-from ) id 1M1IZd-0002oT-1W; Tue, 05 May 2009 12:12:33 +0100 Received: from buffy.york.ac.uk (localhost [127.0.0.1]) by buffy.york.ac.uk (8.14.3/8.14.3) with ESMTP id n45BCWeh048136; Tue, 5 May 2009 12:12:32 +0100 (BST) (envelope-from gavin@FreeBSD.org) Received: (from ga9@localhost) by buffy.york.ac.uk (8.14.3/8.14.3/Submit) id n45BCWMb048135; Tue, 5 May 2009 12:12:32 +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: Guido Falsi In-Reply-To: <20090505110624.GA83487@megatron.madpilot.net> References: <20090505110624.GA83487@megatron.madpilot.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Tue, 05 May 2009 12:12:31 +0100 Message-Id: <1241521951.47323.3.camel@buffy.york.ac.uk> Mime-Version: 1.0 X-Mailer: Evolution 2.22.2 FreeBSD GNOME Team Port X-York-MailScanner: Found to be clean X-York-MailScanner-From: gavin@freebsd.org Cc: freebsd-stable@FreeBSD.org Subject: Re: [PANIC] recent 7.2-STABLE when probing drm X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 11:12:41 -0000 On Tue, 2009-05-05 at 13:06 +0200, Guido Falsi wrote: > Hi! > > I'm using FreeBSD/i386 stable on a HP DC7800 PC. > > It has an Intel Q35 graphic chip. > > After upgrading to a recent stable I experienced a pani on boot, just > after probing drm. > > I investigated a little and found out that reverting the file > > src/sys/dev/pci/pci.c > > to rev. 1.355.2.9 (SVN Rev 190092) solves the crash. > > I could not investigatte urther right away, but some regression was > introduced with this rev. > > Is any more information needed? When it panics, can you please type "bt" (assuming you have the debugger compiled in) and show the output? Gavin From owner-freebsd-stable@FreeBSD.ORG Tue May 5 12:08:13 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 479471065674 for ; Tue, 5 May 2009 12:08:13 +0000 (UTC) (envelope-from chris#@1command.com) Received: from mail.1command.com (dsl081-172-045.sea1.dsl.speakeasy.net [64.81.172.45]) by mx1.freebsd.org (Postfix) with ESMTP id DDBD88FC19 for ; Tue, 5 May 2009 12:08:12 +0000 (UTC) (envelope-from chris#@1command.com) Received: from mail.1command.com (localhost.1command.com [127.0.0.1]) by mail.1command.com (8.13.3/8.13.3) with ESMTP id n45C6668037242; Tue, 5 May 2009 05:06:12 -0700 (PDT) (envelope-from chris#@1command.com) Received: (from www@localhost) by mail.1command.com (8.13.3/8.13.3/Submit) id n45C66H1037241; Tue, 5 May 2009 05:06:06 -0700 (PDT) (envelope-from chris#@1command.com) Received: from hitme.hitometer.net (hitme.hitometer.net [64.81.172.194]) by webmail.1command.com (H.R. Communications Messaging System) with HTTP; Tue, 05 May 2009 05:06:06 -0700 Message-ID: <20090505050606.hkxc6cgl3k8ccgws@webmail.1command.com> X-Priority: 3 (Normal) Date: Tue, 05 May 2009 05:06:06 -0700 From: Chris H To: Holger Kipp References: <20090505024800.tk0saqntsgk8kk8c@webmail.1command.com> <20090505101301.GA31143@intserv.int1.b.intern> In-Reply-To: <20090505101301.GA31143@intserv.int1.b.intern> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: H.R. Communications Internet Messaging System (HCIMS) 4.1 Professional (not for redistribution) / UNIX Cc: freebsd-stable@freebsd.org Subject: Re: GEOM_STRIPE: Cannot add disk da2c to st0 (error=17). X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 12:08:13 -0000 Hello, and thank you for your reply... Quoting Holger Kipp : > On Tue, May 05, 2009 at 02:48:00AM -0700, Chris H wrote: >> Greetings, >> I'm attempting to upgrade one of our servers to 6.4 (from 6.2) >> Before doing so I need to stripe 3 identical drives on the >> same SCSI port into one drive, the drives are on an LSI controller >> with 2 ports: > [..] >> However, when I attempt to stripe the 3 unused drives, I recieve an >> error regarding da2: >> >> gstripe label -v st0 /dev/da0 /dev/da1 /dev/da2 >> GEOM_STRIPE: Device st0 created (id=2607126992). >> GEOM_STRIPE: Disk da0 attached to st0. >> Metadata value stored on /dev/da0. >> GEOM_STRIPE: Disk da1 attached to st0. >> Metadata value stored on /dev/da1. >> GEOM_STRIPE: Disk da2 attached to st0. >> GEOM_STRIPE: Device st0 activated. >> GEOM_STRIPE: Cannot add disk da2c to st0 (error=17). >> Metadata value stored on /dev/da2. >> >> I blanked the 3 drives prior to attempting any of this, and it's >> on a fresh reboot. I'm afraid I don't know how to proceed. Is it >> a problem with gstripe(8)? I /really/ need to stripe these drives >> so as to upgrade the system. > > Can you check if you have any fdisk metadata on either of your disks? > Especially as da0, da1, da2 are attached to st0 without problems, > but then GEOM_STRIPE complains about da2c (which looks like a partition > entry)... I cheated, and went into sysinstall > custom > partition chose each of da0, da1, and da2 pressed "f" then "no" then "yes". Which forced a "dangerously" dedicated disk. I also chose "w" on all occasions, and each time the response indicated Successfully written to disk. I then bailed out of sysinstall, then went back, and deleted the partitions, and again, chose "w". Which also indicated "Successfully written to disk". I then bailed out of sysinstall. Having felt the disks were all now clean, I proceeded with the command: gstripe label -v st0 /dev/da0 /dev/da1 /dev/da2 ...well, you know the rest of the story. :) Is this not a good (the best) direction to take? Thank you again for your reply. --Chris H > > Mind you, this is just a wild guess from my side ;-) > > Regards, > Holger > From owner-freebsd-stable@FreeBSD.ORG Tue May 5 12:13:23 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A60701065670; Tue, 5 May 2009 12:13:23 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.terabit.net.ua (mail.terabit.net.ua [195.137.202.147]) by mx1.freebsd.org (Postfix) with ESMTP id 38A838FC1A; Tue, 5 May 2009 12:13:23 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from skuns.zoral.com.ua ([91.193.166.194] helo=mail.zoral.com.ua) by mail.terabit.net.ua with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1M1JWT-000K7n-Hq; Tue, 05 May 2009 15:13:21 +0300 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id n45CClaJ010830 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 May 2009 15:12:48 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id n45CClA0075086; Tue, 5 May 2009 15:12:47 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id n45CClY7075085; Tue, 5 May 2009 15:12:47 +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: Tue, 5 May 2009 15:12:47 +0300 From: Kostik Belousov To: jhb@freebsd.org Message-ID: <20090505121247.GN1948@deviant.kiev.zoral.com.ua> References: <20090505110624.GA83487@megatron.madpilot.net> <1241521951.47323.3.camel@buffy.york.ac.uk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="XBg9NAhDNArbJUtw" Content-Disposition: inline In-Reply-To: <1241521951.47323.3.camel@buffy.york.ac.uk> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua X-Virus-Scanned: mail.terabit.net.ua 1M1JWT-000K7n-Hq 9443483e5f45d0b8b75122fcf78c88d3 X-Terabit: YES Cc: Gavin Atkinson , freebsd-stable@freebsd.org, Guido Falsi Subject: Re: [PANIC] recent 7.2-STABLE when probing drm X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 12:13:23 -0000 --XBg9NAhDNArbJUtw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, May 05, 2009 at 12:12:31PM +0100, Gavin Atkinson wrote: > On Tue, 2009-05-05 at 13:06 +0200, Guido Falsi wrote: > > Hi! > >=20 > > I'm using FreeBSD/i386 stable on a HP DC7800 PC. > >=20 > > It has an Intel Q35 graphic chip. > >=20 > > After upgrading to a recent stable I experienced a pani on boot, just > > after probing drm. > >=20 > > I investigated a little and found out that reverting the file > >=20 > > src/sys/dev/pci/pci.c > >=20 > > to rev. 1.355.2.9 (SVN Rev 190092) solves the crash. > >=20 > > I could not investigatte urther right away, but some regression was > > introduced with this rev. > >=20 > > Is any more information needed? >=20 > When it panics, can you please type "bt" (assuming you have the debugger > compiled in) and show the output? I have this too. I have dump too. drm0: on vgapci0 panic: resource_list_alloc: resource entry is busy KDB: stack backtrace: db_trace_self_wrapper(c07214ff,c2b46764,c04c928f,c071f823,c078b080,...) at = 0xc044df46 =3D db_trace_self_wrapper+0x26 kdb_backtrace(c071f823,c078b080,c07211b1,c2b46770,c2b46770,...) at 0xc04f41= f9 =3D kdb_backtrace+0x29 panic(c07211b1,3,10,c04e9484,c2e37000,...) at 0xc04c928f =3D panic+0xaf resource_list_alloc(c2cffb04,c2d00a80,c2d00c80,3,c2d2a1fc,...) at 0xc04f0c0= 6 =3D resource_list_alloc+0xd6 pci_alloc_resource(c2d00a80,c2d00c80,3,c2d2a1fc,0,ffffffff,1,4) at 0xc045a2= d1 =3D pci_alloc_resource+0x581 bus_alloc_resource(c2d00c80,3,c2d2a1fc,0,ffffffff,...) at 0xc04f0a8c =3D bu= s_alloc_resource+0x7c vga_pci_alloc_resource(c2d00c80,c2cfa080,3,c2d2a1fc,0,ffffffff,1,4) at 0xc0= 4600ab =3D vga_pci_alloc_resource+0x3b bus_alloc_resource(c2cfa080,3,c2d2a1fc,0,ffffffff,...) at 0xc04f0a8c =3D bu= s_alloc_resource+0x7c drm_alloc_resource(fffffff4,c2d2a000,c2b468fc,c36a0b9b,c2d2a000,...) at 0xc= 36b7726 =3D drm_alloc_resource+0xf6 drm_get_resource_start(c2d2a000,0,1,4,c04d2010,...) at 0xc36b780c =3D drm_g= et_resource_start+0x1c i915_driver_load(c2d2a000,6,c36bfe5c,1c2,ffffffff,...) at 0xc36a0b9b =3D i9= 15_driver_load+0x13b drm_attach(c2cfa080,c36a59a0,102,c2d00c80,c2cfa0cc,...) at 0xc36bb0e1 =3D d= rm_attach+0x4b1 i915_attach(c2cfa080,c32a9054,c0748368,c0721002,80000000,...) at 0xc36a0f41= =3D i915_attach+0x111 device_attach(c2cfa080,c2cfa080,c2d00c80,c2cfa080,c2d00c80,...) at 0xc04ef7= 07 =3D device_attach+0x387 device_probe_and_attach(c2cfa080,c2d00c80,c0748358,c2d00c80,0,...) at 0xc04= f0702 =3D device_probe_and_attach+0xe2 bus_generic_driver_added(c2d00c80,c36a5b7c,101,0,c36a5b68,...) at 0xc04f07d= 5 =3D bus_generic_driver_added+0x75 devclass_add_driver(c2ca4480,c36a5b7c,c2b46a2c,2d,c36a5b7c,...) at 0xc04ee4= c8 =3D devclass_add_driver+0xc8 driver_module_handler(c2e420c0,0,c36a5b68,0,0,...) at 0xc04ef2a9 =3D driver= _module_handler+0x79 module_register_init(c36a5b5c,c071dad9,c2b46c10,c2b46c0c,0,...) at 0xc04b9d= 25 =3D module_register_init+0x105 linker_load_module(0,c2b46c40,2,c2b46c58,c04b7b99,...) at 0xc04b2462 =3D li= nker_load_module+0xa02 kern_kldload(c2e79af0,c2d12000,c2b46c70,0,0,...) at 0xc04b294c =3D kern_kld= load+0xec kldload(c2e79af0,c2b46cfc,4,c2b46d38,c2b46d2c,...) at 0xc04b2ae4 =3D kldloa= d+0x74 syscall(c2b46d38) at 0xc06f6eb5 =3D syscall+0x3a5 Xint0x80_syscall() at 0xc06de760 =3D Xint0x80_syscall+0x20 --- syscall (304, FreeBSD ELF32, kldload), eip =3D 0x28566d57, esp =3D 0xbf= bfe89c, ebp =3D 0xbfbfe8a8 --- --XBg9NAhDNArbJUtw Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkoALT4ACgkQC3+MBN1Mb4jv4wCgyLfoS/IgZPoVbaIuAvJM4MGq J+cAoMgXL3/vzRhSiFxBgiH00lZJk8LG =PDXt -----END PGP SIGNATURE----- --XBg9NAhDNArbJUtw-- From owner-freebsd-stable@FreeBSD.ORG Tue May 5 12:35:32 2009 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 136C9106566B for ; Tue, 5 May 2009 12:35:32 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from mail-gw2.york.ac.uk (mail-gw2.york.ac.uk [144.32.128.247]) by mx1.freebsd.org (Postfix) with ESMTP id 7DAFB8FC17 for ; Tue, 5 May 2009 12:35:31 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from mail-gw6.york.ac.uk (mail-gw6.york.ac.uk [144.32.129.26]) by mail-gw2.york.ac.uk (8.13.6/8.13.6) with ESMTP id n45CZSVd006872; Tue, 5 May 2009 13:35:28 +0100 (BST) Received: from buffy-128.york.ac.uk ([144.32.128.160] helo=buffy.york.ac.uk) by mail-gw6.york.ac.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1M1Jrs-0000sR-JI; Tue, 05 May 2009 13:35:28 +0100 Received: from buffy.york.ac.uk (localhost [127.0.0.1]) by buffy.york.ac.uk (8.14.3/8.14.3) with ESMTP id n45CZSPK048606; Tue, 5 May 2009 13:35:28 +0100 (BST) (envelope-from gavin@FreeBSD.org) Received: (from ga9@localhost) by buffy.york.ac.uk (8.14.3/8.14.3/Submit) id n45CZSkx048605; Tue, 5 May 2009 13:35:28 +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: Kostik Belousov In-Reply-To: <20090505121247.GN1948@deviant.kiev.zoral.com.ua> References: <20090505110624.GA83487@megatron.madpilot.net> <1241521951.47323.3.camel@buffy.york.ac.uk> <20090505121247.GN1948@deviant.kiev.zoral.com.ua> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Tue, 05 May 2009 13:35:27 +0100 Message-Id: <1241526927.47323.5.camel@buffy.york.ac.uk> Mime-Version: 1.0 X-Mailer: Evolution 2.22.2 FreeBSD GNOME Team Port X-York-MailScanner: Found to be clean X-York-MailScanner-From: gavin@freebsd.org Cc: freebsd-stable@FreeBSD.org, Guido Falsi , jhb@FreeBSD.org Subject: Re: [PANIC] recent 7.2-STABLE when probing drm X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 12:35:32 -0000 On Tue, 2009-05-05 at 15:12 +0300, Kostik Belousov wrote: > On Tue, May 05, 2009 at 12:12:31PM +0100, Gavin Atkinson wrote: > > On Tue, 2009-05-05 at 13:06 +0200, Guido Falsi wrote: > > > Hi! > > > > > > I'm using FreeBSD/i386 stable on a HP DC7800 PC. > > > > > > It has an Intel Q35 graphic chip. > > > > > > After upgrading to a recent stable I experienced a pani on boot, just > > > after probing drm. > > > > > > I investigated a little and found out that reverting the file > > > > > > src/sys/dev/pci/pci.c > > > > > > to rev. 1.355.2.9 (SVN Rev 190092) solves the crash. > > > > > > I could not investigatte urther right away, but some regression was > > > introduced with this rev. > > > > > > Is any more information needed? > > > > When it panics, can you please type "bt" (assuming you have the debugger > > compiled in) and show the output? > > I have this too. I have dump too. > > drm0: on vgapci0 > panic: resource_list_alloc: resource entry is busy > KDB: stack backtrace: > db_trace_self_wrapper(c07214ff,c2b46764,c04c928f,c071f823,c078b080,...) at 0xc044df46 = db_trace_self_wrapper+0x26 > kdb_backtrace(c071f823,c078b080,c07211b1,c2b46770,c2b46770,...) at 0xc04f41f9 = kdb_backtrace+0x29 > panic(c07211b1,3,10,c04e9484,c2e37000,...) at 0xc04c928f = panic+0xaf > resource_list_alloc(c2cffb04,c2d00a80,c2d00c80,3,c2d2a1fc,...) at 0xc04f0c06 = resource_list_alloc+0xd6 > pci_alloc_resource(c2d00a80,c2d00c80,3,c2d2a1fc,0,ffffffff,1,4) at 0xc045a2d1 = pci_alloc_resource+0x581 > bus_alloc_resource(c2d00c80,3,c2d2a1fc,0,ffffffff,...) at 0xc04f0a8c = bus_alloc_resource+0x7c > vga_pci_alloc_resource(c2d00c80,c2cfa080,3,c2d2a1fc,0,ffffffff,1,4) at 0xc04600ab = vga_pci_alloc_resource+0x3b [...] I wonder if r189373 also needs merging? Gavin From owner-freebsd-stable@FreeBSD.ORG Tue May 5 12:38:19 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D43EE1065676 for ; Tue, 5 May 2009 12:38:19 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) by mx1.freebsd.org (Postfix) with ESMTP id 8FF8B8FC1F for ; Tue, 5 May 2009 12:38:19 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from localhost (localhost.codelab.cz [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 9DE5319E043; Tue, 5 May 2009 14:38:14 +0200 (CEST) Received: from [192.168.1.2] (r5bb235.net.upc.cz [86.49.61.235]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 804E819E044; Tue, 5 May 2009 14:38:12 +0200 (CEST) Message-ID: <4A003334.70807@quip.cz> Date: Tue, 05 May 2009 14:38:12 +0200 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: cz, cs, en, en-us MIME-Version: 1.0 To: Chris H References: <20090505024800.tk0saqntsgk8kk8c@webmail.1command.com> <20090505101301.GA31143@intserv.int1.b.intern> <20090505050606.hkxc6cgl3k8ccgws@webmail.1command.com> In-Reply-To: <20090505050606.hkxc6cgl3k8ccgws@webmail.1command.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: GEOM_STRIPE: Cannot add disk da2c to st0 (error=17). X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 12:38:20 -0000 Chris H wrote: > Hello, and thank you for your reply... > > Quoting Holger Kipp : > [...] >> >> Can you check if you have any fdisk metadata on either of your disks? >> Especially as da0, da1, da2 are attached to st0 without problems, >> but then GEOM_STRIPE complains about da2c (which looks like a partition >> entry)... > > > I cheated, and went into sysinstall > custom > partition > > chose each of da0, da1, and da2 > > pressed "f" then "no" then "yes". Which forced a "dangerously" dedicated > disk. I also chose "w" on all occasions, and each time the response > indicated > Successfully written to disk. I then bailed out of sysinstall, then went > back, and deleted the partitions, and again, chose "w". Which also > indicated > "Successfully written to disk". I then bailed out of sysinstall. > Having felt the disks were all now clean, I proceeded with the command: > > gstripe label -v st0 /dev/da0 /dev/da1 /dev/da2 > > ...well, you know the rest of the story. :) > > Is this not a good (the best) direction to take? I recommend you to use dd if=/dev/zero of=/dev/da0 count=1000 dd if=/dev/zero of=/dev/da1 count=1000 dd if=/dev/zero of=/dev/da2 count=1000 to clear the begining of the disks. The next step should be to clear the few last sectors, where metadata of GEOM mirror, journal, stripe etc. are stored, so you end up with "clear disks" which you can use in whatever setup you want without problem with old data, partitions etc. Miroslav Lachman From owner-freebsd-stable@FreeBSD.ORG Tue May 5 13:16:18 2009 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BAE18106566B for ; Tue, 5 May 2009 13:16:18 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from megatron.madpilot.net (megatron.madpilot.net [88.149.173.206]) by mx1.freebsd.org (Postfix) with ESMTP id 538708FC15 for ; Tue, 5 May 2009 13:16:18 +0000 (UTC) (envelope-from mad@madpilot.net) Received: by megatron.madpilot.net (Postfix, from userid 1000) id 57D9D130C54; Tue, 5 May 2009 15:16:17 +0200 (CEST) Date: Tue, 5 May 2009 15:16:17 +0200 From: Guido Falsi To: Gavin Atkinson Message-ID: <20090505131617.GB83487@megatron.madpilot.net> References: <20090505110624.GA83487@megatron.madpilot.net> <1241521951.47323.3.camel@buffy.york.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1241521951.47323.3.camel@buffy.york.ac.uk> X-Operating-System: FreeBSD 7.1-STABLE User-Agent: Mutt/1.5.19 (2009-01-05) Cc: freebsd-stable@FreeBSD.org Subject: Re: [PANIC] recent 7.2-STABLE when probing drm X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 13:16:19 -0000 On Tue, May 05, 2009 at 12:12:31PM +0100, Gavin Atkinson wrote: > > Is any more information needed? > > When it panics, can you please type "bt" (assuming you have the debugger > compiled in) and show the output? I did not have a kernel with debugger handy. Here you go (copying by hand...): drm0: on vgapci0 panic: resource_list_alloc: resource entry busy cpuid = 0 KDB: enter: panic [thread pid 0 tid 0 ] Stopped at kdb_enter_why+0x3a: movl $0,kdb_why db> bt kdb_enter_why(c07d0374,c07d0374,c07d2cf1,c0c20760,0,...) at kdb_enter_why+0x3a panic(c07d2cf1,3,10,c086a7b4,c0c20788,...) at panic+0x131 resource_list_alloc(c6d56604,c6d88a80,c6d88a80,3,c6d79dfc,...) at resource_list_alloc+0xee pci_alloc_resource(c6d88a80,c6d88a80,3,c6d79dfc,0,ffffffff,1,4) at pci_alloc_resource+0x554 bus_alloc_resource(c6d88a80,3,c6d79dfc,0,ffffffff,...) at bus_alloc_resource+0x7e vga_pci_alloc_resource(c6d88a80,c6d81d80,3,c6d79dfc,0,ffffffff,1,4) at vga_pci_alloc_resource+0x3b bus_alloc_resource(c6d88a80,3,c6d79dfc,0,ffffffff,...) at bus_alloc_resource+0x7e drm_alloc_resource(c6d88b80,c6d88b80,c6d79c00,c0c208fc,c04a6946,...) at drm_alloc_resource+0xea drm_get_resource_start(c6d79c00,0,1,8,c07b652b,...) at drm_get_resource_start0x17 i915_driver_load(c6d79c00,6,c07b652b,1c2,ffffffff,...) at i915_driver_load+0x139 drm_attach(c6d81d80,c08078a0,102) at drm_attach+0x604 i915_attach(c6d81d80,c6d0f858,c0818470,c07d2b42,80000000,...) at i915_attach+0x10a device_attach(c6d81d80,c6d81d80,c07d2aa0,932,c6d81d80,...) at device+attach+0x36a device_probe_and_attach(c6d81d80,c6d88b80,c0c209f4,c04dc7f8,c6d88b80,...) at device_probe_and_attach+0xfd bus_generic_attach(...) at bus_generic_attach+0x19 vga_pci_attach(...) at vga_pci_attach+0x32 device_attach(...) at device_attach+0x36a device_probe_and_attach(...) at device_probe_and_attach+0xfd bus_generic_attach(...) at bus_generic_attach+0x19 acpi_pci_attach(...) at acpi_pci_attach+0x171 device_attach(...) at device_attach+0x36a device_probe_and_attach(...) at device_probe_and_attach+0xfd bus_generic_attach(...) at bus_generic_attach+0x19 acpi_pcib_attach(...) at acpi_pcib_attach+0x18e acpi_pcib_acpi_attach(...) at acpi_pcib_acpi_attach+0x1ad device_attach(...) at device_attach+0x36a device_probe_and_attach(...) at device_probe_and_attach+0xfd bus_generic_attach(...) at bus_generic_attach+0x19 acpi_pci_attach(...) at acpi_pci_attach+0x171 device_attach(...) at device_attach+0x36a device_probe_and_attach(...) at device_probe_and_attach+0xfd bus_generic_attach(...) at bus_generic_attach+0x19 nexus_attach(...) at nexus_attach+0x1a device_attach(...) at device_attach+0x36a device_probe_and_attach(...) at device_probe_and_attach+0xfd root_bus_configure(...) at root_bus_configure+0x1b configure(...) at configure0xc mi_startup() at mi_startup+0x90 begin() at begin+0x2c (I cut some parameters, hope they were not important) Contact me as you wish if any other information or tests are needed. -- Guido Falsi From owner-freebsd-stable@FreeBSD.ORG Tue May 5 13:51:21 2009 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 418C610656B1; Tue, 5 May 2009 13:51:21 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from mail-gw1.york.ac.uk (mail-gw1.york.ac.uk [144.32.128.246]) by mx1.freebsd.org (Postfix) with ESMTP id C73418FC1F; Tue, 5 May 2009 13:51:20 +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-gw1.york.ac.uk (8.13.6/8.13.6) with ESMTP id n45DpHbI023962; Tue, 5 May 2009 14:51:17 +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.68) (envelope-from ) id 1M1L3F-0007Ar-Qz; Tue, 05 May 2009 14:51:17 +0100 Received: from buffy.york.ac.uk (localhost [127.0.0.1]) by buffy.york.ac.uk (8.14.3/8.14.3) with ESMTP id n45DpHBC085141; Tue, 5 May 2009 14:51:17 +0100 (BST) (envelope-from gavin@FreeBSD.org) Received: (from ga9@localhost) by buffy.york.ac.uk (8.14.3/8.14.3/Submit) id n45DpHFC085140; Tue, 5 May 2009 14:51:17 +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: Kostik Belousov In-Reply-To: <1241526927.47323.5.camel@buffy.york.ac.uk> References: <20090505110624.GA83487@megatron.madpilot.net> <1241521951.47323.3.camel@buffy.york.ac.uk> <20090505121247.GN1948@deviant.kiev.zoral.com.ua> <1241526927.47323.5.camel@buffy.york.ac.uk> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Tue, 05 May 2009 14:51:16 +0100 Message-Id: <1241531476.47323.8.camel@buffy.york.ac.uk> Mime-Version: 1.0 X-Mailer: Evolution 2.22.2 FreeBSD GNOME Team Port X-York-MailScanner: Found to be clean X-York-MailScanner-From: gavin@freebsd.org Cc: freebsd-stable@FreeBSD.org, Guido Falsi , jhb@FreeBSD.org Subject: Re: [PANIC] recent 7.2-STABLE when probing drm X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 13:51:22 -0000 On Tue, 2009-05-05 at 13:35 +0100, Gavin Atkinson wrote: > On Tue, 2009-05-05 at 15:12 +0300, Kostik Belousov wrote: > > On Tue, May 05, 2009 at 12:12:31PM +0100, Gavin Atkinson wrote: > > > On Tue, 2009-05-05 at 13:06 +0200, Guido Falsi wrote: > > > > Hi! > > > > > > > > I'm using FreeBSD/i386 stable on a HP DC7800 PC. > > > > > > > > It has an Intel Q35 graphic chip. > > > > > > > > After upgrading to a recent stable I experienced a pani on boot, just > > > > after probing drm. > > > > > > > > I investigated a little and found out that reverting the file > > > > > > > > src/sys/dev/pci/pci.c > > > > > > > > to rev. 1.355.2.9 (SVN Rev 190092) solves the crash. > > > > > > > > I could not investigatte urther right away, but some regression was > > > > introduced with this rev. > > > > > > > > Is any more information needed? > > > > > > When it panics, can you please type "bt" (assuming you have the debugger > > > compiled in) and show the output? > > > > I have this too. I have dump too. > > > > drm0: on vgapci0 > > panic: resource_list_alloc: resource entry is busy > > KDB: stack backtrace: > > db_trace_self_wrapper(c07214ff,c2b46764,c04c928f,c071f823,c078b080,...) at 0xc044df46 = db_trace_self_wrapper+0x26 > > kdb_backtrace(c071f823,c078b080,c07211b1,c2b46770,c2b46770,...) at 0xc04f41f9 = kdb_backtrace+0x29 > > panic(c07211b1,3,10,c04e9484,c2e37000,...) at 0xc04c928f = panic+0xaf > > resource_list_alloc(c2cffb04,c2d00a80,c2d00c80,3,c2d2a1fc,...) at 0xc04f0c06 = resource_list_alloc+0xd6 > > pci_alloc_resource(c2d00a80,c2d00c80,3,c2d2a1fc,0,ffffffff,1,4) at 0xc045a2d1 = pci_alloc_resource+0x581 > > bus_alloc_resource(c2d00c80,3,c2d2a1fc,0,ffffffff,...) at 0xc04f0a8c = bus_alloc_resource+0x7c > > vga_pci_alloc_resource(c2d00c80,c2cfa080,3,c2d2a1fc,0,ffffffff,1,4) at 0xc04600ab = vga_pci_alloc_resource+0x3b > [...] > > I wonder if r189373 also needs merging? Looking at a thread on -current, it looks like this is probably the case. It's not a straight merge from head as other bits have changed, but you could test http://people.freebsd.org/~gavin/189373_7.diff (warning: compile tested only) Gavin From owner-freebsd-stable@FreeBSD.ORG Tue May 5 13:56:08 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B345F1065677; Tue, 5 May 2009 13:56:08 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.terabit.net.ua (mail.terabit.net.ua [195.137.202.147]) by mx1.freebsd.org (Postfix) with ESMTP id 4563F8FC19; Tue, 5 May 2009 13:56:08 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from skuns.zoral.com.ua ([91.193.166.194] helo=mail.zoral.com.ua) by mail.terabit.net.ua with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1M1L7u-00058h-B0; Tue, 05 May 2009 16:56:06 +0300 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id n45Du2So016862 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 May 2009 16:56:03 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id n45Du23B013727; Tue, 5 May 2009 16:56:02 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id n45Du2vO013726; Tue, 5 May 2009 16:56:02 +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: Tue, 5 May 2009 16:56:02 +0300 From: Kostik Belousov To: Gavin Atkinson Message-ID: <20090505135602.GO1948@deviant.kiev.zoral.com.ua> References: <20090505110624.GA83487@megatron.madpilot.net> <1241521951.47323.3.camel@buffy.york.ac.uk> <20090505121247.GN1948@deviant.kiev.zoral.com.ua> <1241526927.47323.5.camel@buffy.york.ac.uk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="f0PSjARDFl/vfYT5" Content-Disposition: inline In-Reply-To: <1241526927.47323.5.camel@buffy.york.ac.uk> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua X-Virus-Scanned: mail.terabit.net.ua 1M1L7u-00058h-B0 df00bf64a0d47484affb671b18956053 X-Terabit: YES Cc: freebsd-stable@freebsd.org, Guido Falsi , jhb@freebsd.org Subject: Re: [PANIC] recent 7.2-STABLE when probing drm X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 13:56:09 -0000 --f0PSjARDFl/vfYT5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, May 05, 2009 at 01:35:27PM +0100, Gavin Atkinson wrote: > On Tue, 2009-05-05 at 15:12 +0300, Kostik Belousov wrote: > > On Tue, May 05, 2009 at 12:12:31PM +0100, Gavin Atkinson wrote: > > > On Tue, 2009-05-05 at 13:06 +0200, Guido Falsi wrote: > > > > Hi! > > > >=20 > > > > I'm using FreeBSD/i386 stable on a HP DC7800 PC. > > > >=20 > > > > It has an Intel Q35 graphic chip. > > > >=20 > > > > After upgrading to a recent stable I experienced a pani on boot, ju= st > > > > after probing drm. > > > >=20 > > > > I investigated a little and found out that reverting the file > > > >=20 > > > > src/sys/dev/pci/pci.c > > > >=20 > > > > to rev. 1.355.2.9 (SVN Rev 190092) solves the crash. > > > >=20 > > > > I could not investigatte urther right away, but some regression was > > > > introduced with this rev. > > > >=20 > > > > Is any more information needed? > > >=20 > > > When it panics, can you please type "bt" (assuming you have the debug= ger > > > compiled in) and show the output? > >=20 > > I have this too. I have dump too. > >=20 > > drm0: on vgapci0 > > panic: resource_list_alloc: resource entry is busy > > KDB: stack backtrace: > > db_trace_self_wrapper(c07214ff,c2b46764,c04c928f,c071f823,c078b080,...)= at 0xc044df46 =3D db_trace_self_wrapper+0x26 > > kdb_backtrace(c071f823,c078b080,c07211b1,c2b46770,c2b46770,...) at 0xc0= 4f41f9 =3D kdb_backtrace+0x29 > > panic(c07211b1,3,10,c04e9484,c2e37000,...) at 0xc04c928f =3D panic+0xaf > > resource_list_alloc(c2cffb04,c2d00a80,c2d00c80,3,c2d2a1fc,...) at 0xc04= f0c06 =3D resource_list_alloc+0xd6 > > pci_alloc_resource(c2d00a80,c2d00c80,3,c2d2a1fc,0,ffffffff,1,4) at 0xc0= 45a2d1 =3D pci_alloc_resource+0x581 > > bus_alloc_resource(c2d00c80,3,c2d2a1fc,0,ffffffff,...) at 0xc04f0a8c = =3D bus_alloc_resource+0x7c > > vga_pci_alloc_resource(c2d00c80,c2cfa080,3,c2d2a1fc,0,ffffffff,1,4) at = 0xc04600ab =3D vga_pci_alloc_resource+0x3b > [...] >=20 > I wonder if r189373 also needs merging? Thanks for the hint. We need both r183095 and r189373, but the actual bugfix is r189373, as you rightly pointed out. Below is the patch that works for me. Index: dev/pci/vga_pci.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- dev/pci/vga_pci.c (revision 191816) +++ dev/pci/vga_pci.c (working copy) @@ -42,10 +42,22 @@ #include #include #include +#include +#include =20 #include #include =20 +struct vga_resource { + struct resource *vr_res; + int vr_refs; +}; + +struct vga_pci_softc { + device_t vga_msi_child; /* Child driver using MSI. */ + struct vga_resource vga_res[PCIR_MAX_BAR_0 + 1]; +}; + static int vga_pci_probe(device_t dev) { @@ -110,7 +122,27 @@ vga_pci_alloc_resource(device_t dev, device_t child, int type, int *rid, u_long start, u_long end, u_long count, u_int flags) { + struct vga_pci_softc *sc; + int bar; =20 + switch (type) { + case SYS_RES_MEMORY: + case SYS_RES_IOPORT: + /* + * For BARs, we cache the resource so that we only allocate it + * from the PCI bus once. + */ + bar =3D PCI_RID2BAR(*rid); + if (bar < 0 || bar > PCIR_MAX_BAR_0) + return (NULL); + sc =3D device_get_softc(dev); + if (sc->vga_res[bar].vr_res =3D=3D NULL) + sc->vga_res[bar].vr_res =3D bus_alloc_resource(dev, type, + rid, start, end, count, flags); + if (sc->vga_res[bar].vr_res !=3D NULL) + sc->vga_res[bar].vr_refs++; + return (sc->vga_res[bar].vr_res); + } return (bus_alloc_resource(dev, type, rid, start, end, count, flags)); } =20 @@ -118,7 +150,38 @@ vga_pci_release_resource(device_t dev, device_t child, int type, int rid, struct resource *r) { + struct vga_pci_softc *sc; + int bar, error; =20 + switch (type) { + case SYS_RES_MEMORY: + case SYS_RES_IOPORT: + /* + * For BARs, we release the resource from the PCI bus + * when the last child reference goes away. + */ + bar =3D PCI_RID2BAR(rid); + if (bar < 0 || bar > PCIR_MAX_BAR_0) + return (EINVAL); + sc =3D device_get_softc(dev); + if (sc->vga_res[bar].vr_res =3D=3D NULL) + return (EINVAL); + KASSERT(sc->vga_res[bar].vr_res =3D=3D r, + ("vga_pci resource mismatch")); + if (sc->vga_res[bar].vr_refs > 1) { + sc->vga_res[bar].vr_refs--; + return (0); + } + KASSERT(sc->vga_res[bar].vr_refs > 0, + ("vga_pci resource reference count underflow")); + error =3D bus_release_resource(dev, type, rid, r); + if (error =3D=3D 0) { + sc->vga_res[bar].vr_res =3D NULL; + sc->vga_res[bar].vr_refs =3D 0; + } + return (error); + } + return (bus_release_resource(dev, type, rid, r)); } =20 @@ -176,6 +239,21 @@ } =20 static int +vga_pci_get_vpd_ident(device_t dev, device_t child, const char **identptr) +{ + + return (pci_get_vpd_ident(dev, identptr)); +} + +static int +vga_pci_get_vpd_readonly(device_t dev, device_t child, const char *kw, + const char **vptr) +{ + + return (pci_get_vpd_readonly(dev, kw, vptr)); +} + +static int vga_pci_set_powerstate(device_t dev, device_t child, int state) { =20 @@ -210,6 +288,77 @@ return (pci_find_extcap(dev, capability, capreg)); } =20 +static int +vga_pci_alloc_msi(device_t dev, device_t child, int *count) +{ + struct vga_pci_softc *sc; + int error; + + sc =3D device_get_softc(dev); + if (sc->vga_msi_child !=3D NULL) + return (EBUSY); + error =3D pci_alloc_msi(dev, count); + if (error =3D=3D 0) + sc->vga_msi_child =3D child; + return (error); +} + +static int +vga_pci_alloc_msix(device_t dev, device_t child, int *count) +{ + struct vga_pci_softc *sc; + int error; + + sc =3D device_get_softc(dev); + if (sc->vga_msi_child !=3D NULL) + return (EBUSY); + error =3D pci_alloc_msix(dev, count); + if (error =3D=3D 0) + sc->vga_msi_child =3D child; + return (error); +} + +static int +vga_pci_remap_msix(device_t dev, device_t child, int count, + const u_int *vectors) +{ + struct vga_pci_softc *sc; + + sc =3D device_get_softc(dev); + if (sc->vga_msi_child !=3D child) + return (ENXIO); + return (pci_remap_msix(dev, count, vectors)); +} + +static int +vga_pci_release_msi(device_t dev, device_t child) +{ + struct vga_pci_softc *sc; + int error; + + sc =3D device_get_softc(dev); + if (sc->vga_msi_child !=3D child) + return (ENXIO); + error =3D pci_release_msi(dev); + if (error =3D=3D 0) + sc->vga_msi_child =3D NULL; + return (error); +} + +static int +vga_pci_msi_count(device_t dev, device_t child) +{ + + return (pci_msi_count(dev)); +} + +static int +vga_pci_msix_count(device_t dev, device_t child) +{ + + return (pci_msix_count(dev)); +} + static device_method_t vga_pci_methods[] =3D { /* Device interface */ DEVMETHOD(device_probe, vga_pci_probe), @@ -236,10 +385,18 @@ DEVMETHOD(pci_disable_busmaster, vga_pci_disable_busmaster), DEVMETHOD(pci_enable_io, vga_pci_enable_io), DEVMETHOD(pci_disable_io, vga_pci_disable_io), + DEVMETHOD(pci_get_vpd_ident, vga_pci_get_vpd_ident), + DEVMETHOD(pci_get_vpd_readonly, vga_pci_get_vpd_readonly), DEVMETHOD(pci_get_powerstate, vga_pci_get_powerstate), DEVMETHOD(pci_set_powerstate, vga_pci_set_powerstate), DEVMETHOD(pci_assign_interrupt, vga_pci_assign_interrupt), DEVMETHOD(pci_find_extcap, vga_pci_find_extcap), + DEVMETHOD(pci_alloc_msi, vga_pci_alloc_msi), + DEVMETHOD(pci_alloc_msix, vga_pci_alloc_msix), + DEVMETHOD(pci_remap_msix, vga_pci_remap_msix), + DEVMETHOD(pci_release_msi, vga_pci_release_msi), + DEVMETHOD(pci_msi_count, vga_pci_msi_count), + DEVMETHOD(pci_msix_count, vga_pci_msix_count), =20 { 0, 0 } }; @@ -247,7 +404,7 @@ static driver_t vga_pci_driver =3D { "vgapci", vga_pci_methods, - 1, + sizeof(struct vga_pci_softc), }; =20 static devclass_t vga_devclass; --f0PSjARDFl/vfYT5 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkoARXIACgkQC3+MBN1Mb4hGdgCg4cQHGq+ELgmVnhAv4DjmVaO/ kxYAn0g4ylHxrZPIlBmScl8Q8tKzxw7z =g7aU -----END PGP SIGNATURE----- --f0PSjARDFl/vfYT5-- From owner-freebsd-stable@FreeBSD.ORG Tue May 5 13:58:30 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A56B6106568A for ; Tue, 5 May 2009 13:58:30 +0000 (UTC) (envelope-from jimmiejaz@gmail.com) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.170]) by mx1.freebsd.org (Postfix) with ESMTP id 749A98FC08 for ; Tue, 5 May 2009 13:58:30 +0000 (UTC) (envelope-from jimmiejaz@gmail.com) Received: by wf-out-1314.google.com with SMTP id 24so3354308wfg.7 for ; Tue, 05 May 2009 06:58:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:reply-to :user-agent:mime-version:to:subject:content-type :content-transfer-encoding; bh=6z8yEudoiG/vZtUA0fzq2cCpDSIyVbVo/GzjQHULC7k=; b=d19pKBWuPYqKCcrKGArFGFTRp/3mgS/itlmVqdcbX45eC/kmY+w0VTXR3crpDSlxxW TSmH0HM/lmysdZQNiaxjfUMndxvR0mEdBhieEJOGtYLErpjm4ziykqy2KCyxtMuBgpmv JaT4m8/QKD83uWVPCqoeVBX9ExgAUZnJecarc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:reply-to:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=YaAUnb2RpBAbiRSUJzke2etGJHTnX5rzp2Ic4K4gs2PkTYziH41vHSWkOhcZ0wbJB9 j0AnaEOxf/7MC5ntsC/2DXwCQgK5CRQluDQloRcMwP67UVPY+LNuUX5D08/j9HTfSByS BHG6IUJOPIzjqwSYZXKdek5Vye1qcW+jTiitc= Received: by 10.142.216.18 with SMTP id o18mr19968wfg.251.1241530530906; Tue, 05 May 2009 06:35:30 -0700 (PDT) Received: from jimmiejaz.org (bas1-toronto44-1279614634.dsl.bell.ca [76.69.94.170]) by mx.google.com with ESMTPS id 30sm5456399wfg.10.2009.05.05.06.35.29 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 05 May 2009 06:35:30 -0700 (PDT) Message-ID: <4A00409B.9030809@gmail.com> Date: Tue, 05 May 2009 09:35:23 -0400 From: Jimmie James User-Agent: Thunderbird 2.0.0.7pre (X11/20090406) MIME-Version: 1.0 To: freebsd-stable@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: [PANIC] recent 7.2-STABLE when probing drm X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jimmiejaz@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 13:58:31 -0000 On Tue, 2009-05-05 at 13:06 +0200, Guido Falsi wrote: > Hi! > > I'm using FreeBSD/i386 stable on a HP DC7800 PC. > > It has an Intel Q35 graphic chip. > > After upgrading to a recent stable I experienced a pani on boot, just > after probing drm. > > I investigated a little and found out that reverting the file > > src/sys/dev/pci/pci.c > > to rev. 1.355.2.9 (SVN Rev 190092) solves the crash. > > I could not investigatte urther right away, but some regression was > introduced with this rev. > > Is any more information needed? I want to add a "me too". I can't compile in a debugger as my sources are updated to 7.2, and any kernel built panics with the same message. I did find this on the CURRENT mailing list, but it wont apply cleanly: http://www.mailinglistarchive.com/freebsd-current@freebsd.org/msg26975.html vgapci0@pci0:0:2:0: class=0x030000 card=0x25821043 chip=0x25828086 rev=0x04 hdr=0x00 vendor = 'Intel Corporation' device = '82915G/GV/GL, 82910GL Integrated Graphics Device' class = display subclass = VGA vgapci1@pci0:0:2:1: class=0x038000 card=0x25821043 chip=0x27828086 rev=0x04 hdr=0x00 vendor = 'Intel Corporation' device = '82915G Graphics device: 82915G/GV/910GL Express Chipset Family' class = display From a 7.2-PRERELEASE kernel. vgapci0: port 0x6800-0x6807 mem 0xcfd80000-0xcfdfffff,0xd0000000-0xdfffffff,0xcfe80000-0xcfebffff at device 2.0 on pci0 agp0: on vgapci0 drm0: on vgapci0 vgapci0: child drm0 requested pci_enable_busmaster vgapci1: mem 0xcfe00000-0xcfe7ffff at device 2.1 on pci0 vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 drm0: on vgapci0 vgapci0: child drm0 requested pci_enable_busmaster info: [drm] AGP at 0xd0000000 256MB info: [drm] Initialized i915 1.6.0 20080730 drm0: [ITHREAD] drm0: [ITHREAD] -- Over the years I've come to regard you as people I've met. From owner-freebsd-stable@FreeBSD.ORG Tue May 5 14:03:12 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F6901065670 for ; Tue, 5 May 2009 14:03:12 +0000 (UTC) (envelope-from terry@tmk.com) Received: from server.tmk.com (server.tmk.com [204.141.35.63]) by mx1.freebsd.org (Postfix) with ESMTP id 0C26C8FC1E for ; Tue, 5 May 2009 14:03:11 +0000 (UTC) (envelope-from terry@tmk.com) Received: from tmk.com by tmk.com (PMDF V6.3-x13 #37010) id <01N8L78DEKCG003G45@tmk.com> for freebsd-stable@freebsd.org; Tue, 05 May 2009 09:40:27 -0400 (EDT) Date: Tue, 05 May 2009 09:35:11 -0400 (EDT) From: terry+freebsd-stable@tmk.com Sender: Terry Kennedy To: freebsd-stable@freebsd.org Message-id: <01N8L7H5796S003G45@tmk.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Subject: Regression in SCSI tape detection at boot in 7.2-RELEASE? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 14:03:12 -0000 Sometime between the 7.2-PRERELEASE cycle started and 7.2-RELEASE, boot-time probing of tape drives (at least a Quantum DLT8000 and a Quantum SDLT600) started generating error messages, such as these: ahc1: port 0xd800-0xd8ff mem 0xfe1fe000-0xfe1fefff irq 25 at device 1.1 on pci2 ahc1: [ITHREAD] aic7899: Ultra160 Wide Channel B, SCSI Id=7, 32/253 SCBs ... Waiting 5 seconds for SCSI devices to settle (probe21:ahc1:0:6:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe21:ahc1:0:6:0): CAM Status: SCSI Status Error (probe21:ahc1:0:6:0): SCSI Status: Check Condition (probe21:ahc1:0:6:0): UNIT ATTENTION asc:29,2 (probe21:ahc1:0:6:0): SCSI bus reset occurred (probe21:ahc1:0:6:0): Retrying Command (per Sense Data) (probe21:ahc1:0:6:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe21:ahc1:0:6:0): CAM Status: SCSI Status Error (probe21:ahc1:0:6:0): SCSI Status: Check Condition (probe21:ahc1:0:6:0): UNIT ATTENTION asc:28,0 (probe21:ahc1:0:6:0): Not ready to ready change, medium may have changed (probe21:ahc1:0:6:0): Retrying Command (per Sense Data) sa0 at ahc1 bus 0 target 6 lun 0 sa0: Removable Sequential Access SCSI-4 device sa0: 160.000MB/s transfers (80.000MHz DT, offset 120, 16bit) This is happening for both stand-alone and loader drives, regardless of whether there is a tape in the drive at boot time. There is no problem with using the drive - no further messages are log- ged and the drive operates properly. Does anyone have any idea what is causing this, and where I should look to try to track it down? Terry Kennedy http://www.tmk.com terry@tmk.com New York, NY USA From owner-freebsd-stable@FreeBSD.ORG Tue May 5 14:12:52 2009 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 91F28106564A; Tue, 5 May 2009 14:12:52 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from megatron.madpilot.net (megatron.madpilot.net [88.149.173.206]) by mx1.freebsd.org (Postfix) with ESMTP id 04A678FC0C; Tue, 5 May 2009 14:12:51 +0000 (UTC) (envelope-from mad@madpilot.net) Received: by megatron.madpilot.net (Postfix, from userid 1000) id A5290130C54; Tue, 5 May 2009 16:12:50 +0200 (CEST) Date: Tue, 5 May 2009 16:12:50 +0200 From: Guido Falsi To: Gavin Atkinson Message-ID: <20090505141250.GA85300@megatron.madpilot.net> References: <20090505110624.GA83487@megatron.madpilot.net> <1241521951.47323.3.camel@buffy.york.ac.uk> <20090505121247.GN1948@deviant.kiev.zoral.com.ua> <1241526927.47323.5.camel@buffy.york.ac.uk> <1241531476.47323.8.camel@buffy.york.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1241531476.47323.8.camel@buffy.york.ac.uk> X-Operating-System: FreeBSD 7.1-STABLE User-Agent: Mutt/1.5.19 (2009-01-05) Cc: Kostik Belousov , freebsd-stable@FreeBSD.org, jhb@FreeBSD.org Subject: Re: [PANIC] recent 7.2-STABLE when probing drm X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 14:12:52 -0000 On Tue, May 05, 2009 at 02:51:16PM +0100, Gavin Atkinson wrote: > On Tue, 2009-05-05 at 13:35 +0100, Gavin Atkinson wrote: > > [...] > > > > I wonder if r189373 also needs merging? > > Looking at a thread on -current, it looks like this is probably the > case. It's not a straight merge from head as other bits have changed, > but you could test http://people.freebsd.org/~gavin/189373_7.diff > (warning: compile tested only) Tested the patch, it solves the problem. The system now boots cleanly. Im using the PC as normal with no ill effects with this new kernel. -- Guido Falsi From owner-freebsd-stable@FreeBSD.ORG Tue May 5 16:45:48 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 14F93106566B; Tue, 5 May 2009 16:45:48 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id DAD2A8FC0A; Tue, 5 May 2009 16:45:46 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id TAA23083; Tue, 05 May 2009 19:45:44 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4A006D38.50901@icyb.net.ua> Date: Tue, 05 May 2009 19:45:44 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.21 (X11/20090406) MIME-Version: 1.0 To: John Baldwin References: <49F8B859.7060908@umn.edu> <200905010947.54855.jhb@freebsd.org> <49FB2847.406@umn.edu> <200905011501.40083.jhb@freebsd.org> In-Reply-To: <200905011501.40083.jhb@freebsd.org> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Alan Amesbury , freebsd-acpi@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Garbled output from kgdb? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 16:45:48 -0000 on 01/05/2009 22:01 John Baldwin said the following: > The trace actually ends here. There is nothing super bad here but there is a > big problem actually in that the idle threads cannot block on a lock, so it is > a problem for the ACPI code to be acquiring a mutex here. Perhaps the locks > protecting the idle registers need to use spin locks instead. The problem with > blocking in the idle thread is that the scheduler assumes (even requires) that > the idle thread is _always_ runnable. Very interesting! So it seems that we are not having more of such crashes by a pure luck (low probability)? Looking at the method's signature: ACPI_NATIVE_UINT AcpiOsAcquireLock (ACPI_SPINLOCK Handle) I think that the name of the parameter type is a big hint. Further, looking into ACPICA reference document: > Wait for and acquire a spin lock. May be called from interrupt handlers, GPE > handlers, and Fixed event handlers. Single threaded OSL implementations should > always return AE_OK for this interface. P.S. the comment before AcpiOsAcquireLock function (in stable/7 code) seems to be outdated/bogus too - first of all there is no Flags parameter (it's actualy a return value "to be used when lock is released") and, second, having ithreads is no excuse to not care about type of blocking, and the term 'blocking' is used incorrectly too: /* * The Flags parameter seems to state whether or not caller is an ISR * (and thus can't block) but since we have ithreads, we don't worry * about potentially blocking. */ -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Tue May 5 16:51:42 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6569C106564A; Tue, 5 May 2009 16:51:42 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 058598FC1E; Tue, 5 May 2009 16:51:40 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id TAA23148; Tue, 05 May 2009 19:51:39 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4A006E9A.7060806@icyb.net.ua> Date: Tue, 05 May 2009 19:51:38 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.21 (X11/20090406) MIME-Version: 1.0 To: John Baldwin , Jung-uk Kim References: <49F8B859.7060908@umn.edu> <200905010947.54855.jhb@freebsd.org> <49FB2847.406@umn.edu> <200905011501.40083.jhb@freebsd.org> <4A006D38.50901@icyb.net.ua> In-Reply-To: <4A006D38.50901@icyb.net.ua> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Alan Amesbury , freebsd-acpi@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Garbled output from kgdb? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 16:51:43 -0000 BTW, this issue seems to be fixed in Jung-uk's acpi patches for newer acpica imports, but it is not fixed both in stable/7 and head. on 05/05/2009 19:45 Andriy Gapon said the following: > on 01/05/2009 22:01 John Baldwin said the following: >> The trace actually ends here. There is nothing super bad here but there is a >> big problem actually in that the idle threads cannot block on a lock, so it is >> a problem for the ACPI code to be acquiring a mutex here. Perhaps the locks >> protecting the idle registers need to use spin locks instead. The problem with >> blocking in the idle thread is that the scheduler assumes (even requires) that >> the idle thread is _always_ runnable. > > > Very interesting! So it seems that we are not having more of such crashes by a > pure luck (low probability)? > > Looking at the method's signature: > ACPI_NATIVE_UINT AcpiOsAcquireLock (ACPI_SPINLOCK Handle) > I think that the name of the parameter type is a big hint. > > Further, looking into ACPICA reference document: >> Wait for and acquire a spin lock. May be called from interrupt handlers, GPE >> handlers, and Fixed event handlers. Single threaded OSL implementations should >> always return AE_OK for this interface. > > P.S. the comment before AcpiOsAcquireLock function (in stable/7 code) seems to be > outdated/bogus too - first of all there is no Flags parameter (it's actualy a > return value "to be used when lock is released") and, second, having ithreads is > no excuse to not care about type of blocking, and the term 'blocking' is used > incorrectly too: > /* > * The Flags parameter seems to state whether or not caller is an ISR > * (and thus can't block) but since we have ithreads, we don't worry > * about potentially blocking. > */ > > -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Tue May 5 16:54:18 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B654510656CD for ; Tue, 5 May 2009 16:54:18 +0000 (UTC) (envelope-from rsmith@xs4all.nl) Received: from smtp-vbr12.xs4all.nl (smtp-vbr12.xs4all.nl [194.109.24.32]) by mx1.freebsd.org (Postfix) with ESMTP id 2C8C68FC16 for ; Tue, 5 May 2009 16:54:17 +0000 (UTC) (envelope-from rsmith@xs4all.nl) Received: from slackbox.xs4all.nl (slackbox.xs4all.nl [213.84.242.160]) by smtp-vbr12.xs4all.nl (8.13.8/8.13.8) with ESMTP id n45GsFCJ058719; Tue, 5 May 2009 18:54:15 +0200 (CEST) (envelope-from rsmith@xs4all.nl) Received: by slackbox.xs4all.nl (Postfix, from userid 1001) id F3FB8BAA7; Tue, 5 May 2009 18:54:14 +0200 (CEST) Date: Tue, 5 May 2009 18:54:14 +0200 From: Roland Smith To: Daniel Gerzo Message-ID: <20090505165414.GA31550@slackbox.xs4all.nl> References: <20090504225012.392fa49f.torfinn.ingolfsen@broadpark.no> <49FF5901.600@gmail.com> <49FFEECE.20403@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1yeeQ81UyVL57Vl7" Content-Disposition: inline In-Reply-To: <49FFEECE.20403@FreeBSD.org> X-GPG-Fingerprint: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 X-GPG-Key: http://www.xs4all.nl/~rsmith/pubkey.txt X-GPG-Notice: If this message is not signed, don't assume I sent it! User-Agent: Mutt/1.5.19 (2009-01-05) X-Virus-Scanned: by XS4ALL Virus Scanner Cc: Torfinn Ingolfsen , freebsd-stable@freebsd.org, Manolis Kiagias Subject: Re: RELENG_7 - has mergemaster changed logic since 7.2-RELEASE? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 16:54:19 -0000 --1yeeQ81UyVL57Vl7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, May 05, 2009 at 09:46:22AM +0200, Daniel Gerzo wrote: > Manolis Kiagias wrote: >=20 > > I always use -iU too. > > I've lost motd, passwd, group and master.passwd > > During mergemaster -p I was asked to merge changes to some of these, and > > still they were replaced with the newer versions. I don't know what went > > wrong but have restored them from backup. (I always tar /etc before a > > source upgrade). Upgrading another system using freebsd-update did not > > cause any problem. >=20 > I have the same experience while I was upgrading a few machines=20 > upgrading from RELENG_7 to RELENG_7_2. I haven't experienced when=20 > upgrading from 7.1-R to 7.2-R. >=20 > Here auth.conf, csh.cshrc, hosts, crontab, syslogd.conf, passswd,=20 > master.passwd, group, sysctl.conf motd and maybe some more got=20 > overwritten :-( I had to restore from backups. When upgrading from 7-STABLE to 7.2-RELEASE mergemaster -s -i -U overwrote all the file I'd changed without asking. Luckily I keep all config files that I've changed in a separate repository, so putting it all back was a question of running an install script. But the change is annoying. Roland --=20 R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) --1yeeQ81UyVL57Vl7 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAkoAbzYACgkQEnfvsMMhpyW8KgCeJRs5eh2ofqHa4oX390DYX3I4 FSwAoK+6g9Vzic/Pt/u6/z5vQ8WjV/S5 =CTZq -----END PGP SIGNATURE----- --1yeeQ81UyVL57Vl7-- From owner-freebsd-stable@FreeBSD.ORG Tue May 5 17:35:42 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D5A6F106564A for ; Tue, 5 May 2009 17:35:42 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from noop.in-addr.com (mail.in-addr.com [IPv6:2001:470:8:162::1]) by mx1.freebsd.org (Postfix) with ESMTP id ADC1C8FC20 for ; Tue, 5 May 2009 17:35:42 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from gjp by noop.in-addr.com with local (Exim 4.54 (FreeBSD)) id 1M1OYN-0000XB-5R; Tue, 05 May 2009 13:35:39 -0400 Date: Tue, 5 May 2009 13:35:39 -0400 From: Gary Palmer To: John Message-ID: <20090505173539.GA58014@in-addr.com> References: <49FEA6D1.2080503@reiteration.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49FEA6D1.2080503@reiteration.net> Cc: FreeBSD Stable Subject: Re: cvsup.uk.freebsd.org appears to not be serving X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 17:35:43 -0000 On Mon, May 04, 2009 at 09:26:57AM +0100, John wrote: > Hi list, hopefully this is the right one and not -questions > > cvsup.uk.freebsd.org appears to have not been serving these last few > weeks. I get, variously, in my logs: > > Parsing supfile "/etc/cvsupfile" > Connecting to cvsup.uk.freebsd.org > Connected to cvsup.uk.freebsd.org > Rejected by server: Access limit exceeded; try again later > Will retry at 03:08:08 > Retrying > Connecting to cvsup.uk.freebsd.org > Connected to cvsup.uk.freebsd.org > Server software version: SNAP_16_1h > Negotiating file attribute support > Exchanging collection information > Establishing passive-mode data connection > Cannot connect to data port: Connection refused > Will retry at 03:18:04 > Retrying > Connecting to cvsup.uk.freebsd.org > Connected to cvsup.uk.freebsd.org > Server software version: SNAP_16_1h > Negotiating file attribute support > Exchanging collection information > Establishing passive-mode data connection > Cannot connect to data port: Connection refused > Will retry at 03:37:33 > Retrying > > ... on and on and on, continuously, 24/7. Datapoint: I've been running cvsup daily against cvsup.uk.freebsd.org without issue for a lot longer than a few weeks. cvsup ends up running somewhere between 6am and 8am and its been a while since I saw any access limit problems. Regards, Gary From owner-freebsd-stable@FreeBSD.ORG Tue May 5 17:48:45 2009 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CB0B7106573D; Tue, 5 May 2009 17:48:45 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id 865818FC16; Tue, 5 May 2009 17:48:45 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from [192.168.1.4] (adsl-19-214-20.bna.bellsouth.net [68.19.214.20]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id n45HmeLC068900 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 May 2009 13:48:40 -0400 (EDT) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Gavin Atkinson In-Reply-To: <1241526927.47323.5.camel@buffy.york.ac.uk> References: <20090505110624.GA83487@megatron.madpilot.net> <1241521951.47323.3.camel@buffy.york.ac.uk> <20090505121247.GN1948@deviant.kiev.zoral.com.ua> <1241526927.47323.5.camel@buffy.york.ac.uk> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-PI4EXWfZF4wvDUhYAaEh" Organization: FreeBSD Date: Tue, 05 May 2009 12:48:25 -0500 Message-Id: <1241545705.1828.25.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1.1 FreeBSD GNOME Team Port X-Spam-Status: No, score=-3.2 required=5.0 tests=AWL,BAYES_00,RDNS_DYNAMIC autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: Kostik Belousov , freebsd-stable@FreeBSD.org, Guido Falsi , jhb@FreeBSD.org Subject: Re: [PANIC] recent 7.2-STABLE when probing drm X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 17:48:46 -0000 --=-PI4EXWfZF4wvDUhYAaEh Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2009-05-05 at 13:35 +0100, Gavin Atkinson wrote: > On Tue, 2009-05-05 at 15:12 +0300, Kostik Belousov wrote: > > On Tue, May 05, 2009 at 12:12:31PM +0100, Gavin Atkinson wrote: > > > On Tue, 2009-05-05 at 13:06 +0200, Guido Falsi wrote: > > > > Hi! > > > >=20 > > > > I'm using FreeBSD/i386 stable on a HP DC7800 PC. > > > >=20 > > > > It has an Intel Q35 graphic chip. > > > >=20 > > > > After upgrading to a recent stable I experienced a pani on boot, ju= st > > > > after probing drm. > > > >=20 > > > > I investigated a little and found out that reverting the file > > > >=20 > > > > src/sys/dev/pci/pci.c > > > >=20 > > > > to rev. 1.355.2.9 (SVN Rev 190092) solves the crash. > > > >=20 > > > > I could not investigatte urther right away, but some regression was > > > > introduced with this rev. > > > >=20 > > > > Is any more information needed? > > >=20 > > > When it panics, can you please type "bt" (assuming you have the debug= ger > > > compiled in) and show the output? > >=20 > > I have this too. I have dump too. > >=20 > > drm0: on vgapci0 > > panic: resource_list_alloc: resource entry is busy > > KDB: stack backtrace: > > db_trace_self_wrapper(c07214ff,c2b46764,c04c928f,c071f823,c078b080,...)= at 0xc044df46 =3D db_trace_self_wrapper+0x26 > > kdb_backtrace(c071f823,c078b080,c07211b1,c2b46770,c2b46770,...) at 0xc0= 4f41f9 =3D kdb_backtrace+0x29 > > panic(c07211b1,3,10,c04e9484,c2e37000,...) at 0xc04c928f =3D panic+0xaf > > resource_list_alloc(c2cffb04,c2d00a80,c2d00c80,3,c2d2a1fc,...) at 0xc04= f0c06 =3D resource_list_alloc+0xd6 > > pci_alloc_resource(c2d00a80,c2d00c80,3,c2d2a1fc,0,ffffffff,1,4) at 0xc0= 45a2d1 =3D pci_alloc_resource+0x581 > > bus_alloc_resource(c2d00c80,3,c2d2a1fc,0,ffffffff,...) at 0xc04f0a8c = =3D bus_alloc_resource+0x7c > > vga_pci_alloc_resource(c2d00c80,c2cfa080,3,c2d2a1fc,0,ffffffff,1,4) at = 0xc04600ab =3D vga_pci_alloc_resource+0x3b > [...] >=20 > I wonder if r189373 also needs merging? Yes, that looks right, resources are owned by both agp and drm on Intel. robert. >=20 > Gavin > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" --=20 Robert Noland FreeBSD --=-PI4EXWfZF4wvDUhYAaEh Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEABECAAYFAkoAe+kACgkQM4TrQ4qfROP2CACaAp5TfqbQHGTEsMyEyixzT8tT xLcAnRQqsawYE/z7AuU8ahKPC7AEjNJt =glmd -----END PGP SIGNATURE----- --=-PI4EXWfZF4wvDUhYAaEh-- From owner-freebsd-stable@FreeBSD.ORG Tue May 5 18:02:27 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EB6C71065714 for ; Tue, 5 May 2009 18:02:27 +0000 (UTC) (envelope-from cristiano.deana@gmail.com) Received: from mail-ew0-f159.google.com (mail-ew0-f159.google.com [209.85.219.159]) by mx1.freebsd.org (Postfix) with ESMTP id 5CB928FC27 for ; Tue, 5 May 2009 18:02:27 +0000 (UTC) (envelope-from cristiano.deana@gmail.com) Received: by ewy3 with SMTP id 3so39290ewy.43 for ; Tue, 05 May 2009 11:02:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=Y4VjnIS3YpZuQW5jIjuPPK+iACHHL5/EK8Wt8/+9IYk=; b=r6rxTDS5etIzwEmjeWSlmIZEu52s7LqJIflQoux5dBYddRdMV0c35oC10JIFLzBy1J rBelS1IYIP/+zXC/pa/3h6BS2T0hcbKal8TEsLcNy0TsoiyNbe8Y6jim+caV0HFT6PSc ADeZz6pznL976/C8VObJIijPmeAQIYFyZ5YFg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=XOiOXmh//+vvpow+GlARHAbnskXr4aomC/8cWl3ohA0K2b/B8FDE88mpMpOxnJwAWK +d7q3wQQT4kN7CYXBO/zBchOOP9d7SvQhl1FDMD0cGjOIO6EwgoExwjgi0y/DMOERo/M EK1duRkGiuqx/Xj1XKItgNZHSotmDvZjEhdkk= MIME-Version: 1.0 Received: by 10.216.0.73 with SMTP id 51mr415991wea.52.1241544850136; Tue, 05 May 2009 10:34:10 -0700 (PDT) In-Reply-To: <20090504225012.392fa49f.torfinn.ingolfsen@broadpark.no> References: <20090504225012.392fa49f.torfinn.ingolfsen@broadpark.no> Date: Tue, 5 May 2009 19:34:10 +0200 Message-ID: From: Cristiano Deana To: FreeBSD Stable Mailing List Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: RELENG_7 - has mergemaster changed logic since 7.2-RELEASE? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 18:02:28 -0000 On Mon, May 4, 2009 at 10:50 PM, Torfinn Ingolfsen wrote: > I just upgraded from 7.2-prerelease (as of 20090401) to 7.2-stable as > of today, using csup and building world. i upgraded fw machines from _7_1 to _7_2. no problem at all here. did mergemaster is changed from -RELEASE to -STABLE? hint: use always -P option -- Cris, member of G.U.F.I Italian FreeBSD User Group http://www.gufi.org/ From owner-freebsd-stable@FreeBSD.ORG Tue May 5 20:08:07 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A65C5106564A; Tue, 5 May 2009 20:08:07 +0000 (UTC) (envelope-from pj@smo.de) Received: from ilk.de (mx-out13.ilk.de [194.121.104.13]) by mx1.freebsd.org (Postfix) with ESMTP id 10D2B8FC15; Tue, 5 May 2009 20:08:06 +0000 (UTC) (envelope-from pj@smo.de) Received: from bologna.intern.smo.de (pool37.ka.ilk.net [212.86.194.37]) by ilk.de (8.13.4/8.13.4/ilk-relay) with ESMTP id n44KMjq8017158; Mon, 4 May 2009 22:22:45 +0200 Received: from [192.168.153.208] (herdubreid.intern.smo.de [192.168.153.208]) by bologna.intern.smo.de (8.13.8+Sun/8.13.8) with ESMTP id n44KMSfM011194; Mon, 4 May 2009 22:22:29 +0200 (CEST) Message-ID: <49FF4E49.4000902@smo.de> Date: Mon, 04 May 2009 22:21:29 +0200 From: Philipp Ost User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.13) Gecko/20090411 X-Accept-Language: de, en-us, en MIME-Version: 1.0 To: Steve Polyack References: <49FF28BC.5080304@comcast.net> In-Reply-To: <49FF28BC.5080304@comcast.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-x11 , freebsd-stable Subject: Re: Radeon 9250 DRM in 7.2-RELEASE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 20:08:08 -0000 Steve Polyack wrote: > I upgraded my workstation (via source) to 7.2-RELEASE from 7.1-RELEASE > about a day ago. After the upgrade procedure, I'm having no luck with > using DRM in X11. It worked fine before and gave reasonable > performance. Now when I start up X with DRI enabled, both of my screens > display garbage. The mouse pointer is also not visible. > > I'm using a PCI Radeon 9250. I can get more details if necessary. I > can also try to revert the kernel DRM module code to 7.1. > > From dmesg: > drm2: on vgapci2 > vgapci2: child drm2 requested pci_enable_busmaster > info: [drm] Initialized radeon 1.29.0 20080528 > info: [drm] Setting GART location based on new memory map > info: [drm] Loading R200 Microcode > info: [drm] writeback test succeeded in 2 usecs > drm2: [ITHREAD] > > Any ideas or suggestions would be appreciated. Thanks. I'm using a AGP Radeon 9250. Ever since I enabled direct rendering I get similar notifications in dmesg: info: [drm] Setting GART location based on new memory map info: [drm] Loading R200 Microcode info: [drm] writeback test succeeded in 1 usecs drm0: [ITHREAD] $ glxinfo | grep rendering direct rendering: Yes $ I'm running 7.2-Prerelease (i386) from May, 1. BTW: hald is not running here, I tweaked my xorg.conf as per the entry 20090123 in ports/UPDATING. HTH, Philipp From owner-freebsd-stable@FreeBSD.ORG Tue May 5 20:09:46 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id A88981065676; Tue, 5 May 2009 20:09:46 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: Andriy Gapon Date: Tue, 5 May 2009 16:09:35 -0400 User-Agent: KMail/1.6.2 References: <49F8B859.7060908@umn.edu> <4A006D38.50901@icyb.net.ua> <4A006E9A.7060806@icyb.net.ua> In-Reply-To: <4A006E9A.7060806@icyb.net.ua> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200905051609.38689.jkim@FreeBSD.org> Cc: Alan Amesbury , freebsd-acpi@freebsd.org, freebsd-stable@freebsd.org, John Baldwin Subject: Re: Garbled output from kgdb? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 20:09:47 -0000 On Tuesday 05 May 2009 12:51 pm, Andriy Gapon wrote: > BTW, this issue seems to be fixed in Jung-uk's acpi patches for > newer acpica imports, but it is not fixed both in stable/7 and > head. Yes, it was fixed in my patchsets long ago, which uses spin lock for AcpiOsAcquireLock(). :-) Jung-uk Kim > on 05/05/2009 19:45 Andriy Gapon said the following: > > on 01/05/2009 22:01 John Baldwin said the following: > >> The trace actually ends here. There is nothing super bad here > >> but there is a big problem actually in that the idle threads > >> cannot block on a lock, so it is a problem for the ACPI code to > >> be acquiring a mutex here. Perhaps the locks protecting the > >> idle registers need to use spin locks instead. The problem with > >> blocking in the idle thread is that the scheduler assumes (even > >> requires) that the idle thread is _always_ runnable. > > > > Very interesting! So it seems that we are not having more of such > > crashes by a pure luck (low probability)? > > > > Looking at the method's signature: > > ACPI_NATIVE_UINT AcpiOsAcquireLock (ACPI_SPINLOCK Handle) > > I think that the name of the parameter type is a big hint. > > > > Further, looking into ACPICA reference document: > >> Wait for and acquire a spin lock. May be called from interrupt > >> handlers, GPE handlers, and Fixed event handlers. Single > >> threaded OSL implementations should always return AE_OK for this > >> interface. > > > > P.S. the comment before AcpiOsAcquireLock function (in stable/7 > > code) seems to be outdated/bogus too - first of all there is no > > Flags parameter (it's actualy a return value "to be used when > > lock is released") and, second, having ithreads is no excuse to > > not care about type of blocking, and the term 'blocking' is used > > incorrectly too: > > /* > > * The Flags parameter seems to state whether or not caller is an > > ISR * (and thus can't block) but since we have ithreads, we don't > > worry * about potentially blocking. > > */ From owner-freebsd-stable@FreeBSD.ORG Tue May 5 20:23:30 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5A1461065673; Tue, 5 May 2009 20:23:30 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 2AE368FC08; Tue, 5 May 2009 20:23:30 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id C153F46B09; Tue, 5 May 2009 16:23:29 -0400 (EDT) Received: from John-Baldwins-Macbook-Pro.local (localhost [127.0.0.1]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 24E518A022; Tue, 5 May 2009 16:23:28 -0400 (EDT) Message-ID: <4A00A042.20806@FreeBSD.org> Date: Tue, 05 May 2009 16:23:30 -0400 From: John Baldwin User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Jung-uk Kim References: <49F8B859.7060908@umn.edu> <4A006D38.50901@icyb.net.ua> <4A006E9A.7060806@icyb.net.ua> <200905051609.38689.jkim@FreeBSD.org> In-Reply-To: <200905051609.38689.jkim@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Tue, 05 May 2009 16:23:28 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.9 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Alan Amesbury , freebsd-acpi@freebsd.org, freebsd-stable@freebsd.org, Andriy Gapon Subject: Re: Garbled output from kgdb? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 20:23:31 -0000 Jung-uk Kim wrote: > On Tuesday 05 May 2009 12:51 pm, Andriy Gapon wrote: >> BTW, this issue seems to be fixed in Jung-uk's acpi patches for >> newer acpica imports, but it is not fixed both in stable/7 and >> head. > > Yes, it was fixed in my patchsets long ago, which uses spin lock for > AcpiOsAcquireLock(). :-) I'm not sure all ACPI locks need to be spin locks, but any locks used by the idle code must be spin locks. Regardless, are you going to import a newer ACPI-CA and commit your patches soon? It sounds like several things are fixed in the outstanding patches by now including both this and the problem with the Alias() operator. > Jung-uk Kim > >> on 05/05/2009 19:45 Andriy Gapon said the following: >>> on 01/05/2009 22:01 John Baldwin said the following: >>>> The trace actually ends here. There is nothing super bad here >>>> but there is a big problem actually in that the idle threads >>>> cannot block on a lock, so it is a problem for the ACPI code to >>>> be acquiring a mutex here. Perhaps the locks protecting the >>>> idle registers need to use spin locks instead. The problem with >>>> blocking in the idle thread is that the scheduler assumes (even >>>> requires) that the idle thread is _always_ runnable. >>> Very interesting! So it seems that we are not having more of such >>> crashes by a pure luck (low probability)? >>> >>> Looking at the method's signature: >>> ACPI_NATIVE_UINT AcpiOsAcquireLock (ACPI_SPINLOCK Handle) >>> I think that the name of the parameter type is a big hint. >>> >>> Further, looking into ACPICA reference document: >>>> Wait for and acquire a spin lock. May be called from interrupt >>>> handlers, GPE handlers, and Fixed event handlers. Single >>>> threaded OSL implementations should always return AE_OK for this >>>> interface. >>> P.S. the comment before AcpiOsAcquireLock function (in stable/7 >>> code) seems to be outdated/bogus too - first of all there is no >>> Flags parameter (it's actualy a return value "to be used when >>> lock is released") and, second, having ithreads is no excuse to >>> not care about type of blocking, and the term 'blocking' is used >>> incorrectly too: >>> /* >>> * The Flags parameter seems to state whether or not caller is an >>> ISR * (and thus can't block) but since we have ithreads, we don't >>> worry * about potentially blocking. >>> */ -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Tue May 5 20:24:29 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 494E2106566B; Tue, 5 May 2009 20:24:29 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 1A0988FC1D; Tue, 5 May 2009 20:24:29 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id C482646B17; Tue, 5 May 2009 16:24:28 -0400 (EDT) Received: from John-Baldwins-Macbook-Pro.local (localhost [127.0.0.1]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 73C1E8A022; Tue, 5 May 2009 16:24:27 -0400 (EDT) Message-ID: <4A00A07D.9090401@FreeBSD.org> Date: Tue, 05 May 2009 16:24:29 -0400 From: John Baldwin User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Kostik Belousov References: <20090505110624.GA83487@megatron.madpilot.net> <1241521951.47323.3.camel@buffy.york.ac.uk> <20090505121247.GN1948@deviant.kiev.zoral.com.ua> In-Reply-To: <20090505121247.GN1948@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Tue, 05 May 2009 16:24:27 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-3.2 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Gavin Atkinson , freebsd-stable@freebsd.org, Guido Falsi Subject: Re: [PANIC] recent 7.2-STABLE when probing drm X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 20:24:29 -0000 Kostik Belousov wrote: > On Tue, May 05, 2009 at 12:12:31PM +0100, Gavin Atkinson wrote: >> On Tue, 2009-05-05 at 13:06 +0200, Guido Falsi wrote: >>> Hi! >>> >>> I'm using FreeBSD/i386 stable on a HP DC7800 PC. >>> >>> It has an Intel Q35 graphic chip. >>> >>> After upgrading to a recent stable I experienced a pani on boot, just >>> after probing drm. >>> >>> I investigated a little and found out that reverting the file >>> >>> src/sys/dev/pci/pci.c >>> >>> to rev. 1.355.2.9 (SVN Rev 190092) solves the crash. >>> >>> I could not investigatte urther right away, but some regression was >>> introduced with this rev. >>> >>> Is any more information needed? >> When it panics, can you please type "bt" (assuming you have the debugger >> compiled in) and show the output? > > I have this too. I have dump too. Sorry about that. I merged the fixes to vgapci this morning so this should be fixed now. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Tue May 5 20:56:35 2009 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 5B6A51065673; Tue, 5 May 2009 20:56:35 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-stable@FreeBSD.org Date: Tue, 5 May 2009 16:56:25 -0400 User-Agent: KMail/1.6.2 References: <49F8B859.7060908@umn.edu> <200905051609.38689.jkim@FreeBSD.org> <4A00A042.20806@FreeBSD.org> In-Reply-To: <4A00A042.20806@FreeBSD.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200905051656.27439.jkim@FreeBSD.org> Cc: freebsd-acpi@freebsd.org, Alan Amesbury , Andriy Gapon , John Baldwin Subject: Re: Garbled output from kgdb? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 20:56:35 -0000 On Tuesday 05 May 2009 04:23 pm, John Baldwin wrote: > Jung-uk Kim wrote: > > On Tuesday 05 May 2009 12:51 pm, Andriy Gapon wrote: > >> BTW, this issue seems to be fixed in Jung-uk's acpi patches for > >> newer acpica imports, but it is not fixed both in stable/7 and > >> head. > > > > Yes, it was fixed in my patchsets long ago, which uses spin lock > > for AcpiOsAcquireLock(). :-) > > I'm not sure all ACPI locks need to be spin locks, but any locks > used by the idle code must be spin locks. There are several types of ACPI locks internally and externally. The AcpiOs{Create,Acquire,Release}Lock() is just one of them, which is a spin lock and it is mostly used for interrupt handlers, e.g., GPE and HW. I have to say there were a lot of confusions between ACPI developers because it was not well-documented. In fact, I personally had to exchange lengthy e-mails with Intel engineers to understand the meaning of these myself. Now Intel has documented everything you need to know about ACPI-CA for OS developers: http://git.moblin.org/cgit.cgi/acpica/tree/documents > Regardless, are you going to import a newer ACPI-CA and commit your > patches soon? It sounds like several things are fixed in the > outstanding patches by now including both this and the problem with > the Alias() operator. Unfortunately, I don't have much time to work on it recently. Couple of developers volunteered to do the actual import work although I haven't heard from them in a while. :-( Jung-uk Kim From owner-freebsd-stable@FreeBSD.ORG Tue May 5 21:18:43 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 890D81065672 for ; Tue, 5 May 2009 21:18:43 +0000 (UTC) (envelope-from scrappy@hub.org) Received: from hub.org (hub.org [200.46.204.220]) by mx1.freebsd.org (Postfix) with ESMTP id 2F2B68FC1C for ; Tue, 5 May 2009 21:18:42 +0000 (UTC) (envelope-from scrappy@hub.org) Received: from localhost (maia-1.hub.org [200.46.208.211]) by hub.org (Postfix) with ESMTP id B362F53BC78 for ; Tue, 5 May 2009 17:59:32 -0300 (ADT) Received: from hub.org ([200.46.204.220]) by localhost (mx1.hub.org [200.46.208.211]) (amavisd-maia, port 10024) with ESMTP id 59520-03 for ; Tue, 5 May 2009 17:59:27 -0300 (ADT) Received: by hub.org (Postfix, from userid 1002) id 4918353BC68; Tue, 5 May 2009 17:59:32 -0300 (ADT) Received: from localhost (localhost [127.0.0.1]) by hub.org (Postfix) with ESMTP id 47D8153BC63 for ; Tue, 5 May 2009 17:59:32 -0300 (ADT) Date: Tue, 5 May 2009 17:59:32 -0300 (ADT) From: "Marc G. Fournier" To: freebsd-stable@freebsd.org Message-ID: <20090505174426.M18967@hub.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: server hangs, break to DDB hangs ... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 21:18:44 -0000 I have two HP Proliant servers that, until recently, have run very stable ... within the past 2 months, the servers hang after anywhere from 10hrs through 19 days (one just hung up this aft) ... vmstat, about the time it hangs, shows: # cat 16/vmstat.out procs memory page disks faults cpu r b w avm fre flt re pi po fr sr da0 pa0 in sy cs us sy id 109 156 1 17035752 62152 803 19 5 3 1907 1785 0 0 437 294 853 50 28 22 2 332 5 17109460 23056 147346 4319 2061 3139 44030 6539423 1029 0 4027 398263 38616 40 58 2 0 32 8 17110588 23052 626 4216 35 203 344 745 572 0 597 16414 5741 4 10 86 0 35 14 17110592 23084 446 5102 2 410 210 1596 540 0 516 31616 4461 4 10 85 0 25 20 17110588 23032 196 7734 2 280 22 1179 445 0 434 34992 3543 5 7 88 with, by the time I was able to reboot it, the final vmstat was showing: # cat 46/vmstat.out procs memory page disks faults cpu r b w avm fre flt re pi po fr sr da0 pa0 in sy cs us sy id 1 492 1595 24292424 99564 809 20 5 4 1909 1896 0 0 437 737 863 50 28 22 1 399 1596 24285028 90708 6195 152 393 76 3185 1061 414 0 683 54948 32062 8 9 82 2 231 1595 24276684 85164 4709 94 219 152 3729 642 554 0 420 39442 20612 7 12 80 1 174 1595 24259144 71288 8204 143 314 158 3379 1314 605 0 547 36228 21219 11 18 71 2 199 1593 24242500 72116 4637 52 251 195 3957 1609 496 0 383 32305 20225 6 12 82 When I try and break to DDB, all I get on the screen is: === KDB: enter: Break sequence on conec === And then it hangs there ... I have ps listings that go back for just over an hour before I rebooted (the script runs every 5 minutes, or is supposed to): # ls -lt */ps* -rw-r--r-- 1 root wheel 509908 May 5 16:47 46/ps.out -rw-r--r-- 1 root wheel 450704 May 5 16:35 35/ps.out -rw-r--r-- 1 root wheel 424047 May 5 16:32 26/ps.out -rw-r--r-- 1 root wheel 329105 May 5 16:21 21/ps.out -rw-r--r-- 1 root wheel 278189 May 5 16:17 16/ps.out -rw-r--r-- 1 root wheel 246726 May 5 15:55 55/ps.out -rw-r--r-- 1 root wheel 231937 May 5 15:50 50/ps.out -rw-r--r-- 1 root wheel 240260 May 5 15:45 45/ps.out -rw-r--r-- 1 root wheel 234731 May 5 15:40 40/ps.out -rw-r--r-- 1 root wheel 233719 May 5 15:30 30/ps.out -rw-r--r-- 1 root wheel 222749 May 5 15:25 25/ps.out -rw-r--r-- 1 root wheel 231617 May 5 15:20 20/ps.out Looking at swap usage over that period, its obvious that something is sucking back the RAM reasonably fast: neptune# cat 46/swap.out Device 512-blocks Used Avail Capacity /dev/da0s1b 16777216 13789464 2987752 82% neptune# cat 35/swap.out Device 512-blocks Used Avail Capacity /dev/da0s1b 16777216 12482312 4294904 74% neptune# cat 26/swap.out Device 512-blocks Used Avail Capacity /dev/da0s1b 16777216 12351920 4425296 74% neptune# cat 21/swap.out Device 512-blocks Used Avail Capacity /dev/da0s1b 16777216 7807240 8969976 47% neptune# cat 16/swap.out Device 512-blocks Used Avail Capacity /dev/da0s1b 16777216 5752832 11024384 34% neptune# cat 55/swap.out Device 512-blocks Used Avail Capacity /dev/da0s1b 16777216 4398928 12378288 26% But I'm not sure what to look at in the ps output to determine what is going awry here ... I'm running 7.1-STABLE FreeBSD 7.1-STABLE #14: Sat Mar 28 00:05:19 ADT 2009 On the server that just hung, so will upgrade to the latest 7.2-RELEASE next, but ... if someone can give me pointers at what else I should be checking for, or something in the ps listings that I should be looking for? My monitor script is currently doing: /usr/sbin/jls > jaillist.out /bin/ps -aucxHl -O jid > ps.out /usr/sbin/pstat -s > swap.out /usr/bin/vmstat 1 5 > vmstat.out /usr/bin/awk '{print $15}' /proc/*/status | /usr/bin/sort | /usr/bin/uniq -c > vps_dist.out Any pointers appreciated ... Thx ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . scrappy@hub.org MSN . scrappy@hub.org Yahoo . yscrappy Skype: hub.org ICQ . 7615664 From owner-freebsd-stable@FreeBSD.ORG Tue May 5 21:40:42 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EDED8106566C for ; Tue, 5 May 2009 21:40:42 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx23.fluidhosting.com [204.14.89.6]) by mx1.freebsd.org (Postfix) with ESMTP id 7C7F18FC0C for ; Tue, 5 May 2009 21:40:42 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 15598 invoked by uid 399); 5 May 2009 21:34:00 -0000 Received: from localhost (HELO 192.168.0.106) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 5 May 2009 21:34:00 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4A00B0C1.4060009@FreeBSD.org> Date: Tue, 05 May 2009 14:33:53 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.21 (X11/20090423) MIME-Version: 1.0 To: Cristiano Deana References: <20090504225012.392fa49f.torfinn.ingolfsen@broadpark.no> In-Reply-To: X-Enigmail-Version: 0.95.7 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Stable Mailing List Subject: Re: RELENG_7 - has mergemaster changed logic since 7.2-RELEASE? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 21:40:43 -0000 Cristiano Deana wrote: > On Mon, May 4, 2009 at 10:50 PM, Torfinn Ingolfsen > wrote: > >> I just upgraded from 7.2-prerelease (as of 20090401) to 7.2-stable as >> of today, using csup and building world. > > i upgraded fw machines from _7_1 to _7_2. no problem at all here. > did mergemaster is changed from -RELEASE to -STABLE? The last change was before the 7.2-release cycle started (6 weeks ago). > hint: > use always -P option I agree, it's a good thing to have in your .mergemasterrc (PRESERVE_FILES=yes). Doug -- This .signature sanitized for your protection From owner-freebsd-stable@FreeBSD.ORG Tue May 5 21:43:11 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 35A381065679; Tue, 5 May 2009 21:43:11 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: Andriy Gapon Date: Tue, 5 May 2009 17:43:01 -0400 User-Agent: KMail/1.6.2 References: <49F8B859.7060908@umn.edu> <4A006E9A.7060806@icyb.net.ua> <200905051609.38689.jkim@FreeBSD.org> In-Reply-To: <200905051609.38689.jkim@FreeBSD.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: Multipart/Mixed; boundary="Boundary-00=_nLLAKMdakiVOZxJ" Message-Id: <200905051743.03520.jkim@FreeBSD.org> Cc: Alan Amesbury , freebsd-acpi@freebsd.org, freebsd-stable@freebsd.org, John Baldwin Subject: Re: Garbled output from kgdb? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 21:43:12 -0000 --Boundary-00=_nLLAKMdakiVOZxJ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline On Tuesday 05 May 2009 04:09 pm, Jung-uk Kim wrote: > On Tuesday 05 May 2009 12:51 pm, Andriy Gapon wrote: > > BTW, this issue seems to be fixed in Jung-uk's acpi patches for > > newer acpica imports, but it is not fixed both in stable/7 and > > head. > > Yes, it was fixed in my patchsets long ago, which uses spin lock > for AcpiOsAcquireLock(). :-) The attached patch is for -STABLE. Note that it is only compile tested on amd64. Jung-uk Kim --Boundary-00=_nLLAKMdakiVOZxJ Content-Type: text/plain; charset="iso-8859-1"; name="OsdSynch.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="OsdSynch.diff" --- sys/dev/acpica/Osd/OsdSynch.c (revision 191834) +++ sys/dev/acpica/Osd/OsdSynch.c (working copy) @@ -1,6 +1,7 @@ /*- * Copyright (c) 2000 Michael Smith * Copyright (c) 2000 BSDi + * Copyright (c) 2007-2009 Jung-uk Kim * All rights reserved. * * Redistribution and use in source and binary forms, with or without @@ -35,365 +36,313 @@ #include #include "opt_acpi.h" +#include #include -#include -#include #include +#include #include +#include -#define _COMPONENT ACPI_OS_SERVICES +#define _COMPONENT ACPI_OS_SERVICES ACPI_MODULE_NAME("SYNCH") MALLOC_DEFINE(M_ACPISEM, "acpisem", "ACPI semaphore"); -#define AS_LOCK(as) mtx_lock(&(as)->as_mtx) -#define AS_UNLOCK(as) mtx_unlock(&(as)->as_mtx) +/* Convert microseconds to hz. */ +static int +timeout2hz(long timo) +{ + struct timeval tv; + tv.tv_sec = timo / 1000000; + tv.tv_usec = timo % 1000000; + + return (tvtohz(&tv)); +} + +/* Adjust timeout from the previous uptime. */ +static long +adjust_timeout(long *tmop, struct timeval *tvp) +{ + struct timeval now, slept; + + getmicrouptime(&now); + slept = now; + timevalsub(&slept, tvp); + *tmop -= slept.tv_sec * 1000000 + slept.tv_usec; + *tvp = now; + + return (*tmop); +} + /* - * Simple counting semaphore implemented using a mutex. (Subsequently used - * in the OSI code to implement a mutex. Go figure.) + * ACPI_SEMAPHORE: a sleepable counting semaphore */ struct acpi_semaphore { - struct mtx as_mtx; - UINT32 as_units; - UINT32 as_maxunits; - UINT32 as_pendings; - UINT32 as_resetting; - UINT32 as_timeouts; + struct sx as_lock; + char as_name[32]; + struct cv as_cv; + UINT32 as_units; + UINT32 as_maxunits; }; -/* Default number of maximum pending threads. */ -#ifndef ACPI_NO_SEMAPHORES -#ifndef ACPI_SEMAPHORES_MAX_PENDING -#define ACPI_SEMAPHORES_MAX_PENDING 4 -#endif - -static int acpi_semaphore_debug = 0; -TUNABLE_INT("debug.acpi_semaphore_debug", &acpi_semaphore_debug); -SYSCTL_DECL(_debug_acpi); -SYSCTL_INT(_debug_acpi, OID_AUTO, semaphore_debug, CTLFLAG_RW, - &acpi_semaphore_debug, 0, "Enable ACPI semaphore debug messages"); -#endif /* !ACPI_NO_SEMAPHORES */ - ACPI_STATUS AcpiOsCreateSemaphore(UINT32 MaxUnits, UINT32 InitialUnits, ACPI_SEMAPHORE *OutHandle) { -#ifndef ACPI_NO_SEMAPHORES - struct acpi_semaphore *as; + struct acpi_semaphore *as; - ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__); + ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__); - if (OutHandle == NULL) - return_ACPI_STATUS (AE_BAD_PARAMETER); - if (InitialUnits > MaxUnits) - return_ACPI_STATUS (AE_BAD_PARAMETER); + if (OutHandle == NULL || InitialUnits > MaxUnits) + return_ACPI_STATUS (AE_BAD_PARAMETER); - if ((as = malloc(sizeof(*as), M_ACPISEM, M_NOWAIT | M_ZERO)) == NULL) - return_ACPI_STATUS (AE_NO_MEMORY); + if ((as = malloc(sizeof(*as), M_ACPISEM, M_NOWAIT | M_ZERO)) == NULL) + return_ACPI_STATUS (AE_NO_MEMORY); - mtx_init(&as->as_mtx, "ACPI semaphore", NULL, MTX_DEF); - as->as_units = InitialUnits; - as->as_maxunits = MaxUnits; - as->as_pendings = as->as_resetting = as->as_timeouts = 0; + snprintf(as->as_name, sizeof(as->as_name), "ACPI sema (%p)", as); + sx_init(&as->as_lock, as->as_name); + cv_init(&as->as_cv, as->as_name); + as->as_units = InitialUnits; + as->as_maxunits = MaxUnits; - ACPI_DEBUG_PRINT((ACPI_DB_MUTEX, - "created semaphore %p max %d, initial %d\n", - as, InitialUnits, MaxUnits)); + ACPI_DEBUG_PRINT((ACPI_DB_MUTEX, + "created semaphore %p, max %u, initial %u\n", + as, InitialUnits, MaxUnits)); - *OutHandle = (ACPI_HANDLE)as; -#else - *OutHandle = (ACPI_HANDLE)OutHandle; -#endif /* !ACPI_NO_SEMAPHORES */ + *OutHandle = (ACPI_SEMAPHORE)as; - return_ACPI_STATUS (AE_OK); + return_ACPI_STATUS (AE_OK); } ACPI_STATUS AcpiOsDeleteSemaphore(ACPI_SEMAPHORE Handle) { -#ifndef ACPI_NO_SEMAPHORES - struct acpi_semaphore *as = (struct acpi_semaphore *)Handle; + struct acpi_semaphore *as = (struct acpi_semaphore *)Handle; - ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__); + ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__); - ACPI_DEBUG_PRINT((ACPI_DB_MUTEX, "destroyed semaphore %p\n", as)); - mtx_destroy(&as->as_mtx); - free(Handle, M_ACPISEM); -#endif /* !ACPI_NO_SEMAPHORES */ + ACPI_DEBUG_PRINT((ACPI_DB_MUTEX, "delete semaphore %p\n", as)); - return_ACPI_STATUS (AE_OK); + if (as != NULL) { + sx_destroy(&as->as_lock); + cv_destroy(&as->as_cv); + free(as, M_ACPISEM); + return_ACPI_STATUS (AE_OK); + } else + ACPI_DEBUG_PRINT((ACPI_DB_MUTEX, + "cannot delete null semaphore\n")); + + return_ACPI_STATUS (AE_BAD_PARAMETER); } -/* - * This implementation has a bug, in that it has to stall for the entire - * timeout before it will return AE_TIME. A better implementation would - * use getmicrotime() to correctly adjust the timeout after being woken up. - */ ACPI_STATUS AcpiOsWaitSemaphore(ACPI_SEMAPHORE Handle, UINT32 Units, UINT16 Timeout) { -#ifndef ACPI_NO_SEMAPHORES - ACPI_STATUS result; - struct acpi_semaphore *as = (struct acpi_semaphore *)Handle; - int rv, tmo; - struct timeval timeouttv, currenttv, timelefttv; + struct acpi_semaphore *as = (struct acpi_semaphore *)Handle; + struct timeval tv; + long tmo; - ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__); + ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__); - if (as == NULL) - return_ACPI_STATUS (AE_BAD_PARAMETER); + if (as == NULL || Units == 0) + return_ACPI_STATUS (AE_BAD_PARAMETER); - if (cold) - return_ACPI_STATUS (AE_OK); + sx_xlock(&as->as_lock); + ACPI_DEBUG_PRINT((ACPI_DB_MUTEX, + "get %u units from semaphore %p (has %u), timeout %u\n", + Units, as, as->as_units, Timeout)); -#if 0 - if (as->as_units < Units && as->as_timeouts > 10) { - printf("%s: semaphore %p too many timeouts, resetting\n", __func__, as); - AS_LOCK(as); - as->as_units = as->as_maxunits; - if (as->as_pendings) - as->as_resetting = 1; - as->as_timeouts = 0; - wakeup(as); - AS_UNLOCK(as); - return_ACPI_STATUS (AE_TIME); - } - - if (as->as_resetting) - return_ACPI_STATUS (AE_TIME); -#endif - - /* a timeout of ACPI_WAIT_FOREVER means "forever" */ - if (Timeout == ACPI_WAIT_FOREVER) { - tmo = 0; - timeouttv.tv_sec = ((0xffff/1000) + 1); /* cf. ACPI spec */ - timeouttv.tv_usec = 0; - } else { - /* compute timeout using microseconds per tick */ - tmo = (Timeout * 1000) / (1000000 / hz); - if (tmo <= 0) - tmo = 1; - timeouttv.tv_sec = Timeout / 1000; - timeouttv.tv_usec = (Timeout % 1000) * 1000; - } - - /* calculate timeout value in timeval */ - getmicrotime(¤ttv); - timevaladd(&timeouttv, ¤ttv); - - AS_LOCK(as); - ACPI_DEBUG_PRINT((ACPI_DB_MUTEX, - "get %d units from semaphore %p (has %d), timeout %d\n", - Units, as, as->as_units, Timeout)); - for (;;) { if (as->as_maxunits == ACPI_NO_UNIT_LIMIT) { - result = AE_OK; - break; + sx_xunlock(&as->as_lock); + return_ACPI_STATUS (AE_OK); } - if (as->as_units >= Units) { - as->as_units -= Units; - result = AE_OK; - break; + if (as->as_maxunits < Units) { + ACPI_DEBUG_PRINT((ACPI_DB_MUTEX, "exceeded max units %u\n", + as->as_maxunits)); + sx_xunlock(&as->as_lock); + return_ACPI_STATUS (AE_LIMIT); } - /* limit number of pending threads */ - if (as->as_pendings >= ACPI_SEMAPHORES_MAX_PENDING) { - result = AE_TIME; - break; + switch (Timeout) { + case ACPI_DO_NOT_WAIT: + if (as->as_units >= Units) { + as->as_units -= Units; + sx_xunlock(&as->as_lock); + return_ACPI_STATUS (AE_OK); + } + break; + case ACPI_WAIT_FOREVER: + while (as->as_units < Units) + cv_wait(&as->as_cv, &as->as_lock); + as->as_units -= Units; + sx_xunlock(&as->as_lock); + return_ACPI_STATUS (AE_OK); + default: + tmo = (long)Timeout * 1000; + getmicrouptime(&tv); + do { + if (as->as_units >= Units) { + as->as_units -= Units; + sx_xunlock(&as->as_lock); + return_ACPI_STATUS (AE_OK); + } + if (cv_timedwait(&as->as_cv, &as->as_lock, + timeout2hz(tmo)) == EWOULDBLOCK) + break; + } while (adjust_timeout(&tmo, &tv) > 0); } + sx_xunlock(&as->as_lock); - /* if timeout values of zero is specified, return immediately */ - if (Timeout == 0) { - result = AE_TIME; - break; - } + return_ACPI_STATUS (AE_TIME); +} - ACPI_DEBUG_PRINT((ACPI_DB_MUTEX, - "semaphore blocked, calling msleep(%p, %p, %d, \"acsem\", %d)\n", - as, &as->as_mtx, PCATCH, tmo)); +ACPI_STATUS +AcpiOsSignalSemaphore(ACPI_SEMAPHORE Handle, UINT32 Units) +{ + struct acpi_semaphore *as = (struct acpi_semaphore *)Handle; - as->as_pendings++; + ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__); - if (acpi_semaphore_debug) { - printf("%s: Sleep %d, pending %d, semaphore %p, thread %d\n", - __func__, Timeout, as->as_pendings, as, AcpiOsGetThreadId()); - } + if (as == NULL || Units == 0) + return_ACPI_STATUS (AE_BAD_PARAMETER); - rv = msleep(as, &as->as_mtx, PCATCH, "acsem", tmo); + sx_xlock(&as->as_lock); + ACPI_DEBUG_PRINT((ACPI_DB_MUTEX, + "return %u units to semaphore %p (has %u)\n", + Units, as, as->as_units)); - as->as_pendings--; - -#if 0 - if (as->as_resetting) { - /* semaphore reset, return immediately */ - if (as->as_pendings == 0) { - as->as_resetting = 0; - } - result = AE_TIME; - break; + if (as->as_maxunits == ACPI_NO_UNIT_LIMIT) { + sx_xunlock(&as->as_lock); + return_ACPI_STATUS (AE_OK); } -#endif - - ACPI_DEBUG_PRINT((ACPI_DB_MUTEX, "msleep(%d) returned %d\n", tmo, rv)); - if (rv == EWOULDBLOCK) { - result = AE_TIME; - break; + if (as->as_maxunits < Units || + as->as_maxunits - Units < as->as_units) { + ACPI_DEBUG_PRINT((ACPI_DB_MUTEX, "exceeded max units %u\n", + as->as_maxunits)); + sx_xunlock(&as->as_lock); + return_ACPI_STATUS (AE_LIMIT); } - /* check if we already awaited enough */ - timelefttv = timeouttv; - getmicrotime(¤ttv); - timevalsub(&timelefttv, ¤ttv); - if (timelefttv.tv_sec < 0) { - ACPI_DEBUG_PRINT((ACPI_DB_MUTEX, "await semaphore %p timeout\n", - as)); - result = AE_TIME; - break; - } + as->as_units += Units; + cv_broadcast(&as->as_cv); + sx_xunlock(&as->as_lock); - /* adjust timeout for the next sleep */ - tmo = (timelefttv.tv_sec * 1000000 + timelefttv.tv_usec) / - (1000000 / hz); - if (tmo <= 0) - tmo = 1; - - if (acpi_semaphore_debug) { - printf("%s: Wakeup timeleft(%jd, %lu), tmo %u, sem %p, thread %d\n", - __func__, (intmax_t)timelefttv.tv_sec, timelefttv.tv_usec, tmo, as, - AcpiOsGetThreadId()); - } - } - - if (acpi_semaphore_debug) { - if (result == AE_TIME && Timeout > 0) { - printf("%s: Timeout %d, pending %d, semaphore %p\n", - __func__, Timeout, as->as_pendings, as); - } - if (result == AE_OK && (as->as_timeouts > 0 || as->as_pendings > 0)) { - printf("%s: Acquire %d, units %d, pending %d, sem %p, thread %d\n", - __func__, Units, as->as_units, as->as_pendings, as, - AcpiOsGetThreadId()); - } - } - - if (result == AE_TIME) - as->as_timeouts++; - else - as->as_timeouts = 0; - - AS_UNLOCK(as); - return_ACPI_STATUS (result); -#else - return_ACPI_STATUS (AE_OK); -#endif /* !ACPI_NO_SEMAPHORES */ + return_ACPI_STATUS (AE_OK); } +/* + * ACPI_SPINLOCK: a non-sleepable spinlock + */ +struct acpi_spinlock { + struct mtx al_lock; + char al_name[32]; + int al_nested; +}; + ACPI_STATUS -AcpiOsSignalSemaphore(ACPI_SEMAPHORE Handle, UINT32 Units) +AcpiOsCreateLock(ACPI_SPINLOCK *OutHandle) { -#ifndef ACPI_NO_SEMAPHORES - struct acpi_semaphore *as = (struct acpi_semaphore *)Handle; + struct acpi_spinlock *al; - ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__); + ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__); - if (as == NULL) - return_ACPI_STATUS(AE_BAD_PARAMETER); + if (OutHandle == NULL) + return_ACPI_STATUS (AE_BAD_PARAMETER); + al = malloc(sizeof(*al), M_ACPISEM, M_NOWAIT | M_ZERO); + if (al == NULL) + return_ACPI_STATUS (AE_NO_MEMORY); - AS_LOCK(as); - ACPI_DEBUG_PRINT((ACPI_DB_MUTEX, - "return %d units to semaphore %p (has %d)\n", - Units, as, as->as_units)); - if (as->as_maxunits != ACPI_NO_UNIT_LIMIT) { - as->as_units += Units; - if (as->as_units > as->as_maxunits) - as->as_units = as->as_maxunits; - } + /* Build a unique name based on the address of the handle. */ + if (OutHandle == &AcpiGbl_GpeLock) + snprintf(al->al_name, sizeof(al->al_name), "ACPI lock (GPE)"); + else if (OutHandle == &AcpiGbl_HardwareLock) + snprintf(al->al_name, sizeof(al->al_name), "ACPI lock (HW)"); + else + snprintf(al->al_name, sizeof(al->al_name), "ACPI lock (%p)", + OutHandle); + mtx_init(&al->al_lock, al->al_name, NULL, MTX_SPIN); - if (acpi_semaphore_debug && (as->as_timeouts > 0 || as->as_pendings > 0)) { - printf("%s: Release %d, units %d, pending %d, semaphore %p, thread %d\n", - __func__, Units, as->as_units, as->as_pendings, as, AcpiOsGetThreadId()); - } + ACPI_DEBUG_PRINT((ACPI_DB_MUTEX, "created %s\n", al->al_name)); - wakeup(as); - AS_UNLOCK(as); -#endif /* !ACPI_NO_SEMAPHORES */ + *OutHandle = (ACPI_SPINLOCK)al; - return_ACPI_STATUS (AE_OK); + return_ACPI_STATUS (AE_OK); } -/* Combined mutex + mutex name storage since the latter must persist. */ -struct acpi_spinlock { - struct mtx lock; - char name[32]; -}; - -ACPI_STATUS -AcpiOsCreateLock (ACPI_SPINLOCK *OutHandle) +void +AcpiOsDeleteLock(ACPI_SPINLOCK Handle) { - struct acpi_spinlock *h; + struct acpi_spinlock *al = (struct acpi_spinlock *)Handle; - if (OutHandle == NULL) - return (AE_BAD_PARAMETER); - h = malloc(sizeof(*h), M_ACPISEM, M_NOWAIT | M_ZERO); - if (h == NULL) - return (AE_NO_MEMORY); + ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__); - /* Build a unique name based on the address of the handle. */ - if (OutHandle == &AcpiGbl_GpeLock) - snprintf(h->name, sizeof(h->name), "acpi subsystem GPE lock"); - else if (OutHandle == &AcpiGbl_HardwareLock) - snprintf(h->name, sizeof(h->name), "acpi subsystem HW lock"); - else - snprintf(h->name, sizeof(h->name), "acpi subsys %p", OutHandle); - mtx_init(&h->lock, h->name, NULL, MTX_DEF); - *OutHandle = (ACPI_SPINLOCK)h; - return (AE_OK); + ACPI_DEBUG_PRINT((ACPI_DB_MUTEX, "delete %s\n", al->al_name)); + + if (al != NULL) { + mtx_destroy(&al->al_lock); + free(al, M_ACPISEM); + } else + ACPI_DEBUG_PRINT((ACPI_DB_MUTEX, + "cannot delete null spinlock\n")); } -void -AcpiOsDeleteLock (ACPI_SPINLOCK Handle) +ACPI_CPU_FLAGS +AcpiOsAcquireLock(ACPI_SPINLOCK Handle) { - struct acpi_spinlock *h = (struct acpi_spinlock *)Handle; + struct acpi_spinlock *al = (struct acpi_spinlock *)Handle; - if (Handle == NULL) - return; - mtx_destroy(&h->lock); - free(h, M_ACPISEM); -} + ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__); -/* - * The Flags parameter seems to state whether or not caller is an ISR - * (and thus can't block) but since we have ithreads, we don't worry - * about potentially blocking. - */ -ACPI_NATIVE_UINT -AcpiOsAcquireLock (ACPI_SPINLOCK Handle) -{ - struct acpi_spinlock *h = (struct acpi_spinlock *)Handle; + ACPI_DEBUG_PRINT((ACPI_DB_MUTEX, "acquire %s\n", al->al_name)); - if (Handle == NULL) + if (al != NULL) { + if (mtx_owned(&al->al_lock)) { + al->al_nested++; + ACPI_DEBUG_PRINT((ACPI_DB_MUTEX, + "acquire nested %s, depth %d\n", + al->al_name, al->al_nested)); + } else + mtx_lock_spin(&al->al_lock); + } else + ACPI_DEBUG_PRINT((ACPI_DB_MUTEX, + "cannot acquire null spinlock\n")); + return (0); - mtx_lock(&h->lock); - return (0); } void -AcpiOsReleaseLock (ACPI_SPINLOCK Handle, ACPI_CPU_FLAGS Flags) +AcpiOsReleaseLock(ACPI_SPINLOCK Handle, ACPI_CPU_FLAGS Flags) { - struct acpi_spinlock *h = (struct acpi_spinlock *)Handle; + struct acpi_spinlock *al = (struct acpi_spinlock *)Handle; - if (Handle == NULL) - return; - mtx_unlock(&h->lock); + ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__); + + ACPI_DEBUG_PRINT((ACPI_DB_MUTEX, "release %s\n", al->al_name)); + + if (al != NULL) { + if (mtx_owned(&al->al_lock)) { + if (al->al_nested > 0) { + ACPI_DEBUG_PRINT((ACPI_DB_MUTEX, + "release nested %s, depth %d\n", + al->al_name, al->al_nested)); + al->al_nested--; + } else + mtx_unlock_spin(&al->al_lock); + } else + ACPI_DEBUG_PRINT((ACPI_DB_MUTEX, + "cannot release unowned %s\n", al->al_name)); + } else + ACPI_DEBUG_PRINT((ACPI_DB_MUTEX, + "cannot release null spinlock\n")); } -/* Section 5.2.9.1: global lock acquire/release functions */ -#define GL_ACQUIRED (-1) -#define GL_BUSY 0 -#define GL_BIT_PENDING 0x1 -#define GL_BIT_OWNED 0x2 -#define GL_BIT_MASK (GL_BIT_PENDING | GL_BIT_OWNED) +/* Section 5.2.10.1: global lock acquire/release functions */ +#define GL_ACQUIRED (-1) +#define GL_BUSY 0 +#define GL_BIT_PENDING 0x01 +#define GL_BIT_OWNED 0x02 +#define GL_BIT_MASK (GL_BIT_PENDING | GL_BIT_OWNED) /* * Acquire the global lock. If busy, set the pending bit. The caller @@ -403,7 +352,7 @@ int acpi_acquire_global_lock(uint32_t *lock) { - uint32_t new, old; + uint32_t new, old; do { old = *lock; @@ -422,7 +371,7 @@ int acpi_release_global_lock(uint32_t *lock) { - uint32_t new, old; + uint32_t new, old; do { old = *lock; --Boundary-00=_nLLAKMdakiVOZxJ-- From owner-freebsd-stable@FreeBSD.ORG Tue May 5 21:57:51 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 08D171065693 for ; Tue, 5 May 2009 21:57:51 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx23.fluidhosting.com [204.14.89.6]) by mx1.freebsd.org (Postfix) with ESMTP id 88ABC8FC1D for ; Tue, 5 May 2009 21:57:50 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 5875 invoked by uid 399); 5 May 2009 21:28:24 -0000 Received: from localhost (HELO 192.168.0.106) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 5 May 2009 21:28:24 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4A00AF76.8010604@FreeBSD.org> Date: Tue, 05 May 2009 14:28:22 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.21 (X11/20090423) MIME-Version: 1.0 To: Torfinn Ingolfsen References: <20090504225012.392fa49f.torfinn.ingolfsen@broadpark.no> In-Reply-To: <20090504225012.392fa49f.torfinn.ingolfsen@broadpark.no> X-Enigmail-Version: 0.95.7 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: RELENG_7 - has mergemaster changed logic since 7.2-RELEASE? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 21:57:52 -0000 Torfinn Ingolfsen wrote: > Ok, this is strange. > > I just upgraded from 7.2-prerelease (as of 20090401) to 7.2-stable as > of today, using csup and building world. I've read this thread and find the whole thing very odd. In particular regarding your case, the last change to mergemaster was done on March 23rd, so if you updated a system on April 1st then again on May 4th you should have been using the same version of mergemaster. > As part of that process I did (as I always do) 'mergemaster -iU' after > the 'make installworld' step. > /etc/passwd (mergemaster sked about it, I pressed 'd', but it was still > upgraded, ugh!) > /etc/group (mergemaster sked about it, I pressed 'd', but it was still > upgraded, ugh!) That shouldn't even be possible. You have to affirmatively choose 'i' (for install) for it to be installed at all, the default is to leave it in the temproot directory. Additionally, the code to handle deleting is some of the oldest code in the script, and hasn't changed in over 8 years. I saw your followup message, can you please do me a favor and modify your /etc/motd file again, then run the following in a script(1) and send me the log? /bin/sh -x mergemaster -iU Thanks, Doug -- This .signature sanitized for your protection From owner-freebsd-stable@FreeBSD.ORG Tue May 5 23:38:00 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 506851065670; Tue, 5 May 2009 23:38:00 +0000 (UTC) (envelope-from amesbury@umn.edu) Received: from mta-m3.tc.umn.edu (mta-m3.tc.umn.edu [134.84.135.123]) by mx1.freebsd.org (Postfix) with ESMTP id 1338A8FC12; Tue, 5 May 2009 23:37:59 +0000 (UTC) (envelope-from amesbury@umn.edu) Received: from [160.94.247.212] (optimator.oitsec.umn.edu [160.94.247.212]) by mta-m3.tc.umn.edu (UMN smtpd) with ESMTP Tue, 5 May 2009 18:37:59 -0500 (CDT) X-Umn-Remote-Mta: [N] optimator.oitsec.umn.edu [160.94.247.212] #+LO+TS+AU+HN X-Umn-Classification: local Message-ID: <4A00CDD6.4080303@umn.edu> Date: Tue, 05 May 2009 18:37:58 -0500 From: Alan Amesbury User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: Jung-uk Kim References: <49F8B859.7060908@umn.edu> <4A006E9A.7060806@icyb.net.ua> <200905051609.38689.jkim@FreeBSD.org> <200905051743.03520.jkim@FreeBSD.org> In-Reply-To: <200905051743.03520.jkim@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org, freebsd-stable@freebsd.org, John Baldwin Subject: Re: Garbled output from kgdb? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 23:38:00 -0000 Jung-uk Kim wrote: > The attached patch is for -STABLE. Note that it is only compile > tested on amd64. The platform in question is 7.1-RELEASE-p5/amd64, and the patch you supplied looks like it applies cleanly to it. While I am unable to pin down the specific trigger of this flaw (the host simply panicked a couple times while under moderate-to-heavy use), I'm willing to apply the patch to the host's current source tree, provided you and John Baldwin are in agreement that it's safe to do so. Note that's not meant to imply I don't trust your coding skills; I'm just not ready to modify production assets without a second look. ;-) Thanks again for your help on this. I appreciate it! -- Alan Amesbury OIT Security and Assurance University of Minnesota From owner-freebsd-stable@FreeBSD.ORG Tue May 5 23:40:14 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BD05010656D1; Tue, 5 May 2009 23:40:14 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (brucec-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:c09::2]) by mx1.freebsd.org (Postfix) with ESMTP id 799EF8FC08; Tue, 5 May 2009 23:40:14 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id 8C5D819011; Wed, 6 May 2009 00:40:18 +0000 (GMT) X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on muon X-Spam-Level: X-Spam-Status: No, score=-2.6 required=8.0 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.2.5 Received: from gluon.draftnet (unknown [IPv6:2a01:348:10f:0:240:f4ff:fe57:9871]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA; Wed, 6 May 2009 00:40:18 +0000 (GMT) Date: Wed, 6 May 2009 00:40:09 +0100 From: Bruce Cran To: Doug Barton Message-ID: <20090506004009.12729c32@gluon.draftnet> In-Reply-To: <4A00AF76.8010604@FreeBSD.org> References: <20090504225012.392fa49f.torfinn.ingolfsen@broadpark.no> <4A00AF76.8010604@FreeBSD.org> X-Mailer: Claws Mail 3.7.1 (GTK+ 2.16.1; i386-portbld-freebsd7.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Torfinn Ingolfsen , freebsd-stable@freebsd.org Subject: Re: RELENG_7 - has mergemaster changed logic since 7.2-RELEASE? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 23:40:15 -0000 On Tue, 05 May 2009 14:28:22 -0700 Doug Barton wrote: > Torfinn Ingolfsen wrote: > > Ok, this is strange. > > > > I just upgraded from 7.2-prerelease (as of 20090401) to 7.2-stable > > as of today, using csup and building world. > > I've read this thread and find the whole thing very odd. In particular > regarding your case, the last change to mergemaster was done on March > 23rd, so if you updated a system on April 1st then again on May 4th > you should have been using the same version of mergemaster. There was a recent thread on -questions about this issue too, with the title "mergemaster -U overwriting modified files". I've seen mergemaster clobber named.conf but I've failed to repeat it despite changing the revision, file timestamp etc. -- Bruce Cran From owner-freebsd-stable@FreeBSD.ORG Tue May 5 23:54:58 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EC694106564A for ; Tue, 5 May 2009 23:54:58 +0000 (UTC) (envelope-from steve@ibctech.ca) Received: from ibctech.ca (unknown [IPv6:2607:f118::b6]) by mx1.freebsd.org (Postfix) with SMTP id 76E198FC1B for ; Tue, 5 May 2009 23:54:58 +0000 (UTC) (envelope-from steve@ibctech.ca) Received: (qmail 61071 invoked by uid 89); 5 May 2009 23:56:21 -0000 Received: from unknown (HELO ?IPv6:2607:f118::5?) (steve@ibctech.ca@2607:f118::5) by 2607:f118::b6 with ESMTPA; 5 May 2009 23:56:21 -0000 Message-ID: <4A00D1C5.2010806@ibctech.ca> Date: Tue, 05 May 2009 19:54:45 -0400 From: Steve Bertrand User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: FreeBSD X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Jails and IPv6 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 23:54:59 -0000 Hi all, I've been using VMWare on Linux for quite some time, but I am fed up to the gills with the hassles I have to go through every time the box needs to be rebooted. I don't want to start a flame war, so let's just say that I'm already convinced of migrating to a solution that I don't need a Linux host for. I need to be able to run multiple instances of FreeBSD on a single box, but I *need* IPv6 to work on the virtual machines. I've read that this is now possible under 7.2. Is this really true? What I'm looking to do, is set up a new host as IPv6 only. I don't want to use dedicated hardware if I don't have to, so I'm asking about jails first. Operationally, are there any success stories regarding v6 and jails that anyone could share? Steve From owner-freebsd-stable@FreeBSD.ORG Wed May 6 03:41:52 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8FD031065679; Wed, 6 May 2009 03:41:52 +0000 (UTC) (envelope-from david@usermode.org) Received: from proxy.meer.net (proxy.meer.net [64.13.141.13]) by mx1.freebsd.org (Postfix) with ESMTP id 718138FC16; Wed, 6 May 2009 03:41:52 +0000 (UTC) (envelope-from david@usermode.org) Received: from mail.meer.net (mail.meer.net [64.13.141.3]) by proxy.meer.net (8.14.3/8.14.3) with ESMTP id n463for7026761; Tue, 5 May 2009 20:41:52 -0700 (PDT) (envelope-from david@usermode.org) Received: from radagast.usermode.org (netblock-66-245-218-157.dslextreme.com [66.245.218.157]) by mail.meer.net (8.13.3/8.13.3/meer) with ESMTP id n463fnfA037686; Tue, 5 May 2009 20:41:49 -0700 (PDT) (envelope-from david@usermode.org) From: David Johnson To: Robert Noland Date: Tue, 5 May 2009 20:41:48 -0700 User-Agent: KMail/1.11.2 (FreeBSD/7.2-RELEASE; KDE/4.2.2; i386; ; ) References: <200905042015.29394.david@usermode.org> <1241504417.1828.19.camel@balrog.2hip.net> In-Reply-To: <1241504417.1828.19.camel@balrog.2hip.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200905052041.48623.david@usermode.org> X-Spam-Score: undef - spam scanning disabled X-CanIt-Geo: ip=64.13.141.3; country=US; region=CA; city=Mountain View; latitude=37.3974; longitude=-122.0732; metrocode=807; areacode=650; http://maps.google.com/maps?q=37.3974,-122.0732&z=6 X-CanItPRO-Stream: default X-Canit-Stats-ID: Bayes signature not available X-Scanned-By: CanIt (www . roaringpenguin . com) on 64.13.141.13 Cc: freebsd-stable@freebsd.org Subject: Re: Xorg hangs with drmwtq in 7.2-RELEASE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 03:41:52 -0000 On Monday 04 May 2009 11:20:17 pm Robert Noland wrote: > This generally suggests that the GPU is locked up... Given that you say > sometimes it locks up hard (usually a panic, that you can't see since X > is running) and other times only X is stalled it might be related to > this patch, if you haven't tried this on already. > > http://people.freebsd.org/~rnoland/drm_radeon-copyin-fix-try2.patch Nope, that didn't help. Still froze when I tried opening multiple windows at once. I'm backing out the patch to get back to a clean state. I also edited my xorg.conf to be closer to yours. No difference. What information do you need to go forward, and how do I collect it? p.s. I didn't have a problem with sources from RELENG_7 date=2009.03.13, if that helps any. Thanks for you time, -- David Johnson From owner-freebsd-stable@FreeBSD.ORG Wed May 6 06:25:25 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 06277106564A for ; Wed, 6 May 2009 06:25:25 +0000 (UTC) (envelope-from chris#@1command.com) Received: from mail.1command.com (dsl081-172-045.sea1.dsl.speakeasy.net [64.81.172.45]) by mx1.freebsd.org (Postfix) with ESMTP id 9D5098FC08 for ; Wed, 6 May 2009 06:25:24 +0000 (UTC) (envelope-from chris#@1command.com) Received: from mail.1command.com (localhost.1command.com [127.0.0.1]) by mail.1command.com (8.13.3/8.13.3) with ESMTP id n466PFOQ041203; Tue, 5 May 2009 23:25:21 -0700 (PDT) (envelope-from chris#@1command.com) Received: (from www@localhost) by mail.1command.com (8.13.3/8.13.3/Submit) id n466PFS7041202; Tue, 5 May 2009 23:25:15 -0700 (PDT) (envelope-from chris#@1command.com) Received: from hitme.hitometer.net (hitme.hitometer.net [64.81.172.194]) by webmail.1command.com (H.R. Communications Messaging System) with HTTP; Tue, 05 May 2009 23:25:14 -0700 Message-ID: <20090505232514.eq979b6w0gcg00og@webmail.1command.com> X-Priority: 3 (Normal) Date: Tue, 05 May 2009 23:25:14 -0700 From: Chris H To: Miroslav Lachman <000.fbsd@quip.cz> References: <20090505024800.tk0saqntsgk8kk8c@webmail.1command.com> <20090505101301.GA31143@intserv.int1.b.intern> <20090505050606.hkxc6cgl3k8ccgws@webmail.1command.com> <4A003334.70807@quip.cz> In-Reply-To: <4A003334.70807@quip.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: H.R. Communications Internet Messaging System (HCIMS) 4.1 Professional (not for redistribution) / UNIX Cc: freebsd-stable@freebsd.org Subject: Re: GEOM_STRIPE: Cannot add disk da2c to st0 (error=17). [SOLVED] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 06:25:25 -0000 Hello Miroslav, and thank you for your reply... Quoting Miroslav Lachman <000.fbsd@quip.cz>: > Chris H wrote: >> Hello, and thank you for your reply... >> >> Quoting Holger Kipp : >> > [...] >>> >>> Can you check if you have any fdisk metadata on either of your disks? >>> Especially as da0, da1, da2 are attached to st0 without problems, >>> but then GEOM_STRIPE complains about da2c (which looks like a partition >>> entry)... >> >> >> I cheated, and went into sysinstall > custom > partition >> >> chose each of da0, da1, and da2 >> >> pressed "f" then "no" then "yes". Which forced a "dangerously" dedicated >> disk. I also chose "w" on all occasions, and each time the response >> indicated >> Successfully written to disk. I then bailed out of sysinstall, then went >> back, and deleted the partitions, and again, chose "w". Which also indicated >> "Successfully written to disk". I then bailed out of sysinstall. >> Having felt the disks were all now clean, I proceeded with the command: >> >> gstripe label -v st0 /dev/da0 /dev/da1 /dev/da2 >> >> ...well, you know the rest of the story. :) >> >> Is this not a good (the best) direction to take? > > I recommend you to use > dd if=/dev/zero of=/dev/da0 count=1000 > dd if=/dev/zero of=/dev/da1 count=1000 > dd if=/dev/zero of=/dev/da2 count=1000 > This is good advice, I decided that if I chose this method, that I should /really/ just change count=. But decided if I go this route, I might as well bounce the box and simply use the SCSI's BIOS routine to re-format all 3 drives. So that's what I did, and guess what - yep, you guessed it; every thing worked (gstripe(8)) as it should have. So good news, nothing wrong within GEOM, and family. :) Thank you again for taking the time to respond Miroslav. --Chris > to clear the begining of the disks. The next step should be to clear > the few last sectors, where metadata of GEOM mirror, journal, stripe > etc. are stored, so you end up with "clear disks" which you can use > in whatever setup you want without problem with old data, partitions > etc. > > Miroslav Lachman > From owner-freebsd-stable@FreeBSD.ORG Wed May 6 09:04:14 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 96C93106567F for ; Wed, 6 May 2009 09:04:14 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 53FC68FC27 for ; Wed, 6 May 2009 09:04:14 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1M1d2z-0002BS-3q for freebsd-stable@freebsd.org; Wed, 06 May 2009 09:04:13 +0000 Received: from 91.205.197.96 ([91.205.197.96]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 06 May 2009 09:04:13 +0000 Received: from jumper99 by 91.205.197.96 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 06 May 2009 09:04:13 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: "Helmut Schneider" Date: Wed, 6 May 2009 11:04:03 +0200 Lines: 21 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 91.205.197.96 X-MSMail-Priority: Normal X-Newsreader: vi with a tiny little GUI X-MimeOLE: Huh, what?! Sender: news Subject: [7.2] R/W mount of / denied. Filesystem not clean - run fsck. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 09:04:15 -0000 Hi, after upgrading a few systems yesterday from 7.1-RELEASE to 7.2-RELEASE on one machine I got the error above. The problem was that - I was unable to cope with it but booting from a live CD. - the message appeared ~ 1000 times and then the kernel paniced. After fsck'ing / with the help of the live CD I rebooted the machine but now I got the same problem with /home. How can I avoid such issues (except of not letting the machine crash)? Is there a way to boot at least to single user mode and then run fsck (I was at home, far away from the machine, not funny)? Thanks, Helmut -- No Swen today, my love has gone away My mailbox stands for lorn, a symbol of the dawn From owner-freebsd-stable@FreeBSD.ORG Wed May 6 09:30:43 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6782A1065670 for ; Wed, 6 May 2009 09:30:43 +0000 (UTC) (envelope-from amarat@ksu.ru) Received: from mx.kzn.ru (mx.kzn.ru [194.85.243.38]) by mx1.freebsd.org (Postfix) with ESMTP id 63FB68FC12 for ; Wed, 6 May 2009 09:30:42 +0000 (UTC) (envelope-from amarat@ksu.ru) Authentication-Results: iout.kzn.ru; dkim=neutral (message not signed) header.i=none Received-SPF: None identity=pra; client-ip=193.232.252.56; receiver=iout.kzn.ru; envelope-from="amarat@ksu.ru"; x-sender="amarat@ksu.ru"; x-conformance=sidf_compatible Received-SPF: None identity=mailfrom; client-ip=193.232.252.56; receiver=iout.kzn.ru; envelope-from="amarat@ksu.ru"; x-sender="amarat@ksu.ru"; x-conformance=sidf_compatible Received-SPF: None identity=helo; client-ip=193.232.252.56; receiver=iout.kzn.ru; envelope-from="amarat@ksu.ru"; x-sender="postmaster@ruby.ksu.ru"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArUFAP/0AErB6Pw4/2dsb2JhbACBUL5GAZAfglABG4EVBQ X-IronPort-AV: E=Sophos;i="4.40,301,1238961600"; d="p7s'?scan'208";a="3348952" Received: from mail.ksu.ru (HELO ruby.ksu.ru) ([193.232.252.56]) by iout.kzn.ru with ESMTP; 06 May 2009 13:30:39 +0400 X-Pass-Through: Kazan State University Network Received: from zealot.ksu.ru ([194.85.245.161]) by ksu.ru (8.13.4/8.13.4) with ESMTP id n468UN1n015551; Wed, 6 May 2009 08:30:23 GMT Received: from zealot.ksu.ru (localhost.lnet [127.0.0.1]) by zealot.ksu.ru (8.14.3/8.14.3) with ESMTP id n469Nnos072070; Wed, 6 May 2009 13:23:50 +0400 (MSD) (envelope-from amarat@ksu.ru) Message-ID: <4A015725.3050603@ksu.ru> Date: Wed, 06 May 2009 13:23:49 +0400 From: "Marat N.Afanasyev" User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.8.1.19) Gecko/20090124 SeaMonkey/1.1.14 MIME-Version: 1.0 To: Helmut Schneider References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050907060609080802000903" Cc: freebsd-stable@freebsd.org Subject: Re: [7.2] R/W mount of / denied. Filesystem not clean - run fsck. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 09:30:43 -0000 This is a cryptographically signed message in MIME format. --------------ms050907060609080802000903 Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Helmut Schneider wrote: > Hi, > > after upgrading a few systems yesterday from 7.1-RELEASE to 7.2-RELEASE > on one machine I got the error above. The problem was that > > - I was unable to cope with it but booting from a live CD. > - the message appeared ~ 1000 times and then the kernel paniced. > > After fsck'ing / with the help of the live CD I rebooted the machine but > now I got the same problem with /home. > > How can I avoid such issues (except of not letting the machine crash)? > Is there a way to boot at least to single user mode and then run fsck (I > was at home, far away from the machine, not funny)? > > Thanks, Helmut > if there's a problem with home you can change PermitRoorLogin yes in /etc/ssh/sshd_config, restart sshd, login as root, unmount home and fsck it. if you have another machine in there, you can try to make a serial console. or install a ip-kvm extender ;) -- SY, Marat --------------ms050907060609080802000903 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII8zCC AtQwggI9oAMCAQICEHpsMo6nkbUVegxjAzzxYCkwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDQwMTE5MTUxOFoX DTEwMDQwMTE5MTUxOFowPzEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEcMBoG CSqGSIb3DQEJARYNYW1hcmF0QGtzdS5ydTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALqa7MfgjbsxmgpTOKxAN7w+cFViFA8NrULAARwVQJQJCnVRGf3i97EwNdLE8VTNniU4 ybS4gtLsy9gfNuuyPV2AJESpgrxaG+KZyHu1f6P4e31YBbnbtWVTUxZ3U/vWoL+BOAOI4S84 Cx834a4uYK75WhpZKd56qet5loyn9N1wBZNgCh9AwU31lA/Q0iCSKpEIxuhbElNXHNnqAlts CtNXsKgsT8mP7QI52h0cBOPSZqvz++e/wruJGgKeCECqo8ftwwya3CYkH1lhH2Q1zeXwez1E 1+solM48odH+odn29ctmOqr3PzZfmBJyGFf5FagTKNia/ys48yBtVU/RXHsCAwEAAaMqMCgw GAYDVR0RBBEwD4ENYW1hcmF0QGtzdS5ydTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUA A4GBAG4Pj7KRSJ/M28KNynJOPCHg26L15S9OfQ+ckMaPPDRAejtdlUdCgkoyD9d1Du/amAk6 A3NcY2I/MsFW2vSonQfU+7cJZiyuhfw7wQlOovCx7USw1dmF6u3EljWZV+Kg4Vi3vN2dPyJx tv8li9McWQoMLmm5zzFGGRaSRnnrnZFsMIIC1DCCAj2gAwIBAgIQemwyjqeRtRV6DGMDPPFg KTANBgkqhkiG9w0BAQUFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElz c3VpbmcgQ0EwHhcNMDkwNDAxMTkxNTE4WhcNMTAwNDAxMTkxNTE4WjA/MR8wHQYDVQQDExZU aGF3dGUgRnJlZW1haWwgTWVtYmVyMRwwGgYJKoZIhvcNAQkBFg1hbWFyYXRAa3N1LnJ1MIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuprsx+CNuzGaClM4rEA3vD5wVWIUDw2t QsABHBVAlAkKdVEZ/eL3sTA10sTxVM2eJTjJtLiC0uzL2B8267I9XYAkRKmCvFob4pnIe7V/ o/h7fVgFudu1ZVNTFndT+9agv4E4A4jhLzgLHzfhri5grvlaGlkp3nqp63mWjKf03XAFk2AK H0DBTfWUD9DSIJIqkQjG6FsSU1cc2eoCW2wK01ewqCxPyY/tAjnaHRwE49Jmq/P757/Cu4ka Ap4IQKqjx+3DDJrcJiQfWWEfZDXN5fB7PUTX6yiUzjyh0f6h2fb1y2Y6qvc/Nl+YEnIYV/kV qBMo2Jr/KzjzIG1VT9FcewIDAQABoyowKDAYBgNVHREEETAPgQ1hbWFyYXRAa3N1LnJ1MAwG A1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEFBQADgYEAbg+PspFIn8zbwo3Kck48IeDbovXlL059 D5yQxo88NEB6O12VR0KCSjIP13UO79qYCToDc1xjYj8ywVba9KidB9T7twlmLK6F/DvBCU6i 8LHtRLDV2YXq7cSWNZlX4qDhWLe83Z0/InG2/yWL0xxZCgwuabnPMUYZFpJGeeudkWwwggM/ MIICqKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMM V2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25z dWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYD VQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNv bmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMwNzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5 WjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRk LjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwgZ8wDQYJ KoZIhvcNAQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5owHUEcJ3f6f+jHuy9zfVb8hp2 vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuvPAsH5/EfkTYkKhPPK9Xzgnc9 A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAeZBlyYLf7AgMBAAGjgZQwgZEw EgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0hjJodHRwOi8vY3JsLnRoYXd0 ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDALBgNVHQ8EBAMCAQYwKQYDVR0R BCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0GCSqGSIb3DQEBBQUAA4GB AEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYvwPQcUCCTcDz9reFhYsPZ Ohl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bGCE6u9uo05RAaWzVN d+NWIXiC3CEZNd4ksdMdRv9dX2VPMYIDZDCCA2ACAQEwdjBiMQswCQYDVQQGEwJaQTElMCMG A1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEHpsMo6nkbUVegxjAzzxYCkwCQYFKw4DAhoF AKCCAcMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkwNTA2 MDkyMzQ5WjAjBgkqhkiG9w0BCQQxFgQUBLhJ/wICe/slWe3lhZhccjKjKRowUgYJKoZIhvcN AQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYF Kw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhB6bDKOp5G1FXoMYwM88WApMIGHBgsq hkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAhB6bDKOp5G1FXoMYwM88WApMA0GCSqGSIb3DQEBAQUABIIBABpDypaBLb+F6A82 OFfOP93wScXlmKyE2FK4iX+8V7yjQ51Poq9OXoECl8WpLRI5/ax2Yz4cIJg8795h1SdX5ySp O/zk1jd+eNQDpvyvR5YNjTGohrxatBELaM3kofR6otORPVyczJdUFScStzkFAtYMZmpSAysG HPYCzg3XSAlKTCko+hOcA6nqESxZttTBl3Lj0tpOYopmmIh4+j7UWyeUaBHP7TXIaqKQeisP QUDl5yAvfQpP7OYFYvVelB26dkXRw6Svv3AesuHBmqPJ01ipkbc136lLbYDt98u1FWAULA77 B1Hg4eBevXtzPHKXitg66VDRSQLigNHVNNjW9ycAAAAAAAA= --------------ms050907060609080802000903-- From owner-freebsd-stable@FreeBSD.ORG Wed May 6 09:50:25 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A5715106571B for ; Wed, 6 May 2009 09:50:25 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 612958FC08 for ; Wed, 6 May 2009 09:50:25 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1M1dlg-0004E2-CM for freebsd-stable@freebsd.org; Wed, 06 May 2009 09:50:24 +0000 Received: from 91.205.197.96 ([91.205.197.96]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 06 May 2009 09:50:24 +0000 Received: from jumper99 by 91.205.197.96 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 06 May 2009 09:50:24 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: "Helmut Schneider" Date: Wed, 6 May 2009 11:50:11 +0200 Lines: 38 Message-ID: References: <4A015725.3050603@ksu.ru> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 91.205.197.96 X-MSMail-Priority: Normal X-Newsreader: vi with a tiny little GUI X-MimeOLE: Huh, what?! Sender: news Subject: Re: [7.2] R/W mount of / denied. Filesystem not clean - run fsck. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 09:50:26 -0000 Marat N.Afanasyev wrote: > Helmut Schneider wrote: >> Hi, >> >> after upgrading a few systems yesterday from 7.1-RELEASE to 7.2-RELEASE >> on one machine I got the error above. The problem was that >> >> - I was unable to cope with it but booting from a live CD. >> - the message appeared ~ 1000 times and then the kernel paniced. >> >> After fsck'ing / with the help of the live CD I rebooted the machine but >> now I got the same problem with /home. >> >> How can I avoid such issues (except of not letting the machine crash)? Is >> there a way to boot at least to single user mode and then run fsck (I was >> at home, far away from the machine, not funny)? >> >> Thanks, Helmut >> > if there's a problem with home you can change > > PermitRoorLogin yes > > in /etc/ssh/sshd_config, restart sshd, login as root, unmount home and There is no 'login' when / cannot be mounted... > fsck it. if you have another machine in there, you can try to make a > serial console. or install a ip-kvm extender ;) I do have such thing (IBM Blade Center) but I'm looking for something to avoid the situation above. Something that lets me at least boot into single user mode. -- No Swen today, my love has gone away My mailbox stands for lorn, a symbol of the dawn From owner-freebsd-stable@FreeBSD.ORG Wed May 6 10:03:17 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 62DCF106564A for ; Wed, 6 May 2009 10:03:17 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from smtp-out1.tiscali.nl (smtp-out1.tiscali.nl [195.241.79.176]) by mx1.freebsd.org (Postfix) with ESMTP id 29BA48FC1F for ; Wed, 6 May 2009 10:03:16 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from [212.123.145.58] (helo=sjakie.klop.ws) by smtp-out1.tiscali.nl with esmtp id 1M1dy7-0002b8-Cr for ; Wed, 06 May 2009 12:03:15 +0200 Received: from 82-170-177-25.ip.telfort.nl (localhost [127.0.0.1]) by sjakie.klop.ws (Postfix) with ESMTP id C14AAA217 for ; Wed, 6 May 2009 12:03:14 +0200 (CEST) Date: Wed, 06 May 2009 12:03:14 +0200 To: freebsd-stable@freebsd.org From: "Ronald Klop" Content-Type: text/plain; format=flowed; delsp=yes; charset=us-ascii MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Message-ID: User-Agent: Opera Mail/9.64 (FreeBSD) Subject: devd doesn't fire event on boot X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 10:03:17 -0000 Hello, Running 7.2-STABLE/amd64. I have a USB-disk and added stuff to devd to mount it readonly on attach. This does work if I attach it after booting up, but not if it is attached before booting. [root@sjakie ~]# cat /etc/devd/philips.conf attach 10 { device-name "umass[0-9]+"; match "vendor" "0x0471"; match "product" "0x083a"; match "sernum" "20521126"; action "/root/bin/mountphilips.sh"; }; [root@sjakie ~]# cat /root/bin/mountphilips.sh #! /bin/sh ( # Sleep, so geom and other kernel stuff can handle the disk # before we try to mount it. sleep 10 mount -v /mnt/backupdisk ) & [root@sjakie ~]# grep backupdisk /etc/fstab /dev/ufs/Extern /mnt/backupdisk ufs ro,noauto 0 0 What can be wrong? Is it possible devd misses events which happened before devd was started? Is this known behaviour? Ronald. From owner-freebsd-stable@FreeBSD.ORG Wed May 6 10:05:13 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9C4241065677 for ; Wed, 6 May 2009 10:05:13 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from smtp-out2.tiscali.nl (smtp-out2.tiscali.nl [195.241.79.177]) by mx1.freebsd.org (Postfix) with ESMTP id EE6C28FC1B for ; Wed, 6 May 2009 10:05:12 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from [212.123.145.58] (helo=sjakie.klop.ws) by smtp-out2.tiscali.nl with esmtp id 1M1dzz-0006nN-0F for ; Wed, 06 May 2009 12:05:11 +0200 Received: from 82-170-177-25.ip.telfort.nl (localhost [127.0.0.1]) by sjakie.klop.ws (Postfix) with ESMTP id 84BDFA218 for ; Wed, 6 May 2009 12:05:10 +0200 (CEST) Date: Wed, 06 May 2009 12:05:10 +0200 To: "freebsd-stable@freebsd.org" From: "Ronald Klop" Content-Type: multipart/mixed; boundary=----------ESLH01tHZyv2bPjGWDQAWF MIME-Version: 1.0 References: <820356.29.1241424820214.JavaMail.tomcat@localhost> Message-ID: In-Reply-To: <820356.29.1241424820214.JavaMail.tomcat@localhost> User-Agent: Opera Mail/9.64 (FreeBSD) Subject: coredump in usb stack X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 10:05:14 -0000 ------------ESLH01tHZyv2bPjGWDQAWF Content-Type: text/plain; format=flowed; delsp=yes; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, I had a coredump from within the usb stack at work a couple of days ago. GENERIC kernel amd64 Apr 28 12:59:12 ronald kernel: FreeBSD 7.2-PRERELEASE #32: Mon Apr 27 17:35:55 CEST 2009 Attached is the kgdb output and dmesg. Is this known? Did I forget something. Ronald. ------------ESLH01tHZyv2bPjGWDQAWF Content-Disposition: attachment; filename=dmesg.txt Content-Type: text/plain; name=dmesg.txt Content-Transfer-Encoding: 7bit Copyright (c) 1992-2009 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.2-PRERELEASE #32: Mon Apr 27 17:35:55 CEST 2009 root@ronald.office.base.nl:/usr/obj/usr/src/sys/GENERIC Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 Duo CPU E6850 @ 3.00GHz (2992.50-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x6fb Stepping = 11 Features=0xbfebfbff Features2=0xe3fd AMD Features=0x20100800 AMD Features2=0x1 Cores per package: 2 usable memory = 4145065984 (3953 MB) avail memory = 3976499200 (3792 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 8 ioapic0 irqs 0-23 on motherboard lapic0: Forcing LINT1 to edge trigger kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 16 at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0xdc00-0xdcff mem 0xd0000000-0xdfffffff,0xfe9f0000-0xfe9fffff irq 16 at device 0.0 on pci1 pci0: at device 3.0 (no driver attached) atapci0: port 0xfe80-0xfe87,0xfe90-0xfe93,0xfea0-0xfea7,0xfeb0-0xfeb3,0xfef0-0xfeff irq 18 at device 3.2 on pci0 atapci0: [ITHREAD] ata2: on atapci0 ata2: [ITHREAD] ata3: on atapci0 ata3: [ITHREAD] pci0: at device 3.3 (no driver attached) em0: port 0xecc0-0xecdf mem 0xfebe0000-0xfebfffff,0xfebdb000-0xfebdbfff irq 21 at device 25.0 on pci0 em0: Using MSI interrupt em0: [FILTER] em0: Ethernet address: 00:1e:4f:ee:e8:5f uhci0: port 0xff20-0xff3f irq 16 at device 26.0 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xff00-0xff1f irq 17 at device 26.1 on pci0 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered ehci0: mem 0xfebd9c00-0xfebd9fff irq 22 at device 26.7 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb2: EHCI version 1.0 usb2: wrong number of companions (3 != 2) usb2: companion controllers, 2 ports each: usb0 usb1 usb2: on ehci0 usb2: USB revision 2.0 uhub2: on usb2 uhub2: 6 ports with 6 removable, self powered hdac0: mem 0xfebdc000-0xfebdffff irq 16 at device 27.0 on pci0 hdac0: HDA Driver Revision: 20090329_0131 hdac0: [ITHREAD] pcib2: irq 16 at device 28.0 on pci0 pci2: on pcib2 uhci2: port 0xff80-0xff9f irq 23 at device 29.0 on pci0 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb3: on uhci2 usb3: USB revision 1.0 uhub3: on usb3 uhub3: 2 ports with 2 removable, self powered uhci3: port 0xff60-0xff7f irq 17 at device 29.1 on pci0 uhci3: [GIANT-LOCKED] uhci3: [ITHREAD] usb4: on uhci3 usb4: USB revision 1.0 uhub4: on usb4 uhub4: 2 ports with 2 removable, self powered uhci4: port 0xff40-0xff5f irq 18 at device 29.2 on pci0 uhci4: [GIANT-LOCKED] uhci4: [ITHREAD] usb5: on uhci4 usb5: USB revision 1.0 uhub5: on usb5 uhub5: 2 ports with 2 removable, self powered ehci1: mem 0xff980800-0xff980bff irq 23 at device 29.7 on pci0 ehci1: [GIANT-LOCKED] ehci1: [ITHREAD] usb6: EHCI version 1.0 usb6: companion controllers, 2 ports each: usb3 usb4 usb5 usb6: on ehci1 usb6: USB revision 2.0 uhub6: on usb6 uhub6: 6 ports with 6 removable, self powered uhub7: on uhub6 uhub7: multiple transaction translators uhub7: 4 ports with 4 removable, self powered pcib3: at device 30.0 on pci0 pci3: on pcib3 isab0: at device 31.0 on pci0 isa0: on isab0 atapci1: port 0xfe00-0xfe07,0xfe10-0xfe13,0xfe20-0xfe27,0xfe30-0xfe33,0xfec0-0xfedf mem 0xff970000-0xff9707ff irq 18 at device 31.2 on pci0 atapci1: [ITHREAD] atapci1: AHCI Version 01.20 controller with 6 ports detected ata4: on atapci1 ata4: [ITHREAD] ata5: on atapci1 ata5: [ITHREAD] ata6: on atapci1 ata6: [ITHREAD] ata7: on atapci1 ata7: port not implemented ata7: [ITHREAD] ata8: on atapci1 ata8: port not implemented ata8: [ITHREAD] ata9: on atapci1 ata9: [ITHREAD] ichsmb0: port 0xece0-0xecff mem 0xfebd9b00-0xfebd9bff irq 18 at device 31.3 on pci0 ichsmb0: [GIANT-LOCKED] ichsmb0: [ITHREAD] smbus0: on ichsmb0 ppc0: port 0x378-0x37f,0x778-0x77f irq 7 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold ppbus0: on ppc0 ppbus0: [ITHREAD] plip0: on ppbus0 plip0: WARNING: using obsoleted IFF_NEEDSGIANT flag lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 ppc0: [GIANT-LOCKED] ppc0: [ITHREAD] sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio0: [FILTER] cpu0: on acpi0 coretemp0: on cpu0 est0: on cpu0 p4tcc0: on cpu0 cpu1: on acpi0 coretemp1: on cpu1 est1: on cpu1 p4tcc1: on cpu1 orm0: at iomem 0xc0000-0xcefff,0xcf000-0xd0fff,0xd1000-0xd37ff,0xd3800-0xd3fff on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ums0: on uhub0 ums0: 8 buttons and Z dir. ukbd0: on uhub0 kbd2 at ukbd0 ums1: on uhub0 ums1: 5 buttons and Z dir. ubt0: on uhub1 ubt0: Interface 0 endpoints: interrupt=0x81, bulk-in=0x82, bulk-out=0x2 ubt0: Interface 1 (alt.config 4) endpoints: isoc-in=0x83, isoc-out=0x3; wMaxPacketSize=64; nframes=5, buffer size=320 Timecounters tick every 1.000 msec ad8: 238418MB at ata4-master SATA300 acd0: DVDROM at ata5-master SATA150 hdac0: HDA Codec #0: Analog Devices AD1984 pcm0: at cad 0 nid 1 on hdac0 pcm1: at cad 0 nid 1 on hdac0 lapic1: Forcing LINT1 to edge trigger SMP: AP CPU #1 Launched! GEOM_LABEL: Label for provider ad8s1a is ufsid/48aed81cc4f3cefd. GEOM_LABEL: Label for provider ad8s1d is ufsid/48aed8252c64bcc1. GEOM_LABEL: Label for provider ad8s1e is ufsid/48aed81ca20f6419. GEOM_JOURNAL: Journal 4268017618: ad8s1f contains data. GEOM_JOURNAL: Journal 4268017618: ad8s1g contains journal. GEOM_JOURNAL: Journal ad8s1f consistent. GEOM_JOURNAL: Journal 3980389559: ad8s1h contains data. GEOM_JOURNAL: Journal 3980389559: ad8s1h contains journal. GEOM_JOURNAL: Journal ad8s1h consistent. GEOM_LABEL: Label for provider ad8s1f.journal is ufsid/4947eceea4f32377. GEOM_LABEL: Label for provider ad8s1h.journal is ufsid/48e3ab88aa9b5e37. Trying to mount root from ufs:/dev/ad8s1a WARNING: / was not properly dismounted GEOM_LABEL: Label ufsid/48aed81cc4f3cefd removed. GEOM_LABEL: Label for provider ad8s1a is ufsid/48aed81cc4f3cefd. GEOM_LABEL: Label ufsid/48aed81ca20f6419 removed. GEOM_LABEL: Label for provider ad8s1e is ufsid/48aed81ca20f6419. GEOM_LABEL: Label ufsid/48e3ab88aa9b5e37 removed. GEOM_LABEL: Label for provider ad8s1h.journal is ufsid/48e3ab88aa9b5e37. GEOM_LABEL: Label ufsid/4947eceea4f32377 removed. GEOM_LABEL: Label for provider ad8s1f.journal is ufsid/4947eceea4f32377. GEOM_LABEL: Label ufsid/48aed8252c64bcc1 removed. GEOM_LABEL: Label for provider ad8s1d is ufsid/48aed8252c64bcc1. GEOM_LABEL: Label ufsid/48aed81cc4f3cefd removed. GEOM_LABEL: Label ufsid/48aed81ca20f6419 removed. WARNING: TMPFS is considered to be a highly experimental feature in FreeBSD. GEOM_LABEL: Label ufsid/48e3ab88aa9b5e37 removed. GEOM_LABEL: Label ufsid/4947eceea4f32377 removed. GEOM_LABEL: Label ufsid/48aed8252c64bcc1 removed. WARNING: attempt to net_add_domain(bluetooth) after domainfinalize() WARNING: attempt to net_add_domain(netgraph) after domainfinalize() netsmb_dev: loaded drm0: on vgapci0 vgapci0: child drm0 requested pci_enable_busmaster info: [drm] Initialized radeon 1.29.0 20080528 info: [drm] Setting GART location based on new memory map info: [drm] Loading RV610 CP Microcode info: [drm] Loading RV610 PFP Microcode info: [drm] Resetting GPU info: [drm] writeback test succeeded in 1 usecs drm0: [ITHREAD] ------------ESLH01tHZyv2bPjGWDQAWF Content-Disposition: attachment; filename=coredump.txt Content-Type: text/plain; name=coredump.txt Content-Transfer-Encoding: 7bit # root@ronald [/usr/obj/usr/src/sys/GENERIC] kgdb kernel.debug /var/crash/vmcore.2 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Unread portion of the kernel message buffer: Fatal trap 9: general protection fault while in kernel mode cpuid = 1; apic id = 01 instruction pointer = 0x8:0xffffffff80434d75 stack pointer = 0x10:0xfffffffe8002db50 frame pointer = 0x10:0x4 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 13 (swi4: clock sio) trap number = 9 panic: general protection fault cpuid = 1 Uptime: 5d21h0m13s Physical memory: 3953 MB Dumping 643 MB: 628 612 596 580 564 548 532 516 500 484 468 452 436 420 404 388 372 356 340 324 308 292 276 260 244 228 212 196 180 164 148 132 116 100 84 68 52 36 20 4 #0 doadump () at pcpu.h:195 195 __asm __volatile("movq %%gs:0,%0" : "=r" (td)); (kgdb) list *0xffffffff80434d75 0xffffffff80434d75 is in ehci_timeout (/usr/src/sys/dev/usb/ehci.c:2729). 2724 #ifdef USB_DEBUG 2725 if (ehcidebug > 1) 2726 usbd_dump_pipe(exfer->xfer.pipe); 2727 #endif 2728 2729 if (sc->sc_dying) { 2730 ehci_abort_xfer(&exfer->xfer, USBD_TIMEOUT); 2731 return; 2732 } 2733 (kgdb) bt #0 doadump () at pcpu.h:195 #1 0x0000000000000004 in ?? () #2 0xffffffff804e38a1 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 #3 0xffffffff804e3cdc in panic (fmt=0x104
) at /usr/src/sys/kern/kern_shutdown.c:574 #4 0xffffffff8078ae6a in trap_fatal (frame=0xffffff0001419000, eva=Variable "eva" is not available. ) at /usr/src/sys/amd64/amd64/trap.c:757 #5 0xffffffff8078b922 in trap (frame=0xfffffffe8002daa0) at /usr/src/sys/amd64/amd64/trap.c:558 #6 0xffffffff80770fee in calltrap () at /usr/src/sys/amd64/amd64/exception.S:209 #7 0xffffffff80434d75 in ehci_timeout (addr=0xffffff00046f7800) at /usr/src/sys/dev/usb/ehci.c:2729 #8 0xffffffff804f50ee in softclock (dummy=Variable "dummy" is not available. ) at /usr/src/sys/kern/kern_timeout.c:274 #9 0xffffffff804c5880 in ithread_loop (arg=0xffffff0001415920) at /usr/src/sys/kern/kern_intr.c:1088 #10 0xffffffff804c284d in fork_exit (callout=0xffffffff804c5716 , arg=0xffffff0001415920, frame=0xfffffffe8002dc80) at /usr/src/sys/kern/kern_fork.c:810 #11 0xffffffff807713ae in fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:455 #12 0x0000000000000000 in ?? () #13 0x0000000000000000 in ?? () #14 0x0000000000000001 in ?? () #15 0x0000000000000000 in ?? () #16 0x0000000000000000 in ?? () #17 0x0000000000000000 in ?? () #18 0x0000000000000000 in ?? () #19 0x0000000000000000 in ?? () #20 0x0000000000000000 in ?? () #21 0x0000000000000000 in ?? () #22 0x0000000000000000 in ?? () #23 0x0000000000000000 in ?? () #24 0x0000000000000000 in ?? () #25 0x0000000000000000 in ?? () #26 0x0000000000000000 in ?? () #27 0x0000000000000000 in ?? () #28 0x0000000000000000 in ?? () #29 0x0000000000000000 in ?? () #30 0x0000000000000000 in ?? () #31 0x0000000000000000 in ?? () #32 0x0000000000000000 in ?? () #33 0x0000000000000000 in ?? () #34 0x0000000000000000 in ?? () #35 0x0000000000000000 in ?? () #36 0x0000000000d85000 in ?? () #37 0xffffffff80ae7540 in tdg_maxid () #38 0xffffffff80af3d40 in tdq_cpu () #39 0xffffffff80af3d40 in tdq_cpu () #40 0xffffff0001419000 in ?? () #41 0xffffff0001419330 in ?? () #42 0xfffffffe8002d3b8 in ?? () #43 0x0000000000000000 in ?? () #44 0xffffffff805054d3 in sched_switch (td=0xffffffff804c5716, newtd=0x8006968d0, flags=Variable "flags" is not available. ) at /usr/src/sys/kern/sched_ule.c:1938 #45 0x0000000000000000 in ?? () #46 0x0000000000000000 in ?? () #47 0x0000000000000000 in ?? () #48 0x0000000000000000 in ?? () #49 0x0000000000000000 in ?? () #50 0x0000000000000000 in ?? () #51 0x0000000000000000 in ?? () #52 0x0000000000000000 in ?? () #53 0x0000000000000000 in ?? () #54 0x0000000000000000 in ?? () #55 0x0000000000000000 in ?? () #56 0x0000000000000000 in ?? () #57 0x0000000000000000 in ?? () #58 0x0000000000000000 in ?? () #59 0x0000000000000000 in ?? () #60 0x0000000000000000 in ?? () ---Type to continue, or q to quit--- #61 0x0000000000000000 in ?? () #62 0x0000000000000000 in ?? () #63 0x0000000000000000 in ?? () #64 0x0000000000000000 in ?? () #65 0x0000000000000000 in ?? () #66 0x0000000000000000 in ?? () #67 0x0000000000000000 in ?? () #68 0x0000000000000000 in ?? () #69 0x0000000000000000 in ?? () #70 0x0000000000000000 in ?? () #71 0x0000000000000000 in ?? () #72 0x0000000000000000 in ?? () #73 0x0000000000000000 in ?? () #74 0x0000000000000000 in ?? () #75 0x0000000000000000 in ?? () #76 0x0000000000000000 in ?? () #77 0x0000000000000000 in ?? () #78 0x0000000000000000 in ?? () #79 0x0000000000000000 in ?? () #80 0x0000000000000000 in ?? () #81 0x0000000000000000 in ?? () #82 0x0000000000000000 in ?? () #83 0x0000000000000000 in ?? () #84 0x0000000000000000 in ?? () #85 0x0000000000000000 in ?? () #86 0x0000000000000000 in ?? () #87 0x0000000000000000 in ?? () #88 0x0000000000000000 in ?? () #89 0x0000000000000000 in ?? () #90 0x0000000000000000 in ?? () #91 0x0000000000000000 in ?? () #92 0x0000000000000000 in ?? () #93 0x0000000000000000 in ?? () #94 0x0000000000000000 in ?? () #95 0x0000000000000000 in ?? () #96 0x0000000000000000 in ?? () #97 0x0000000000000000 in ?? () #98 0x0000000000000000 in ?? () #99 0x0000000000000000 in ?? () #100 0x0000000000000000 in ?? () #101 0x0000000000000000 in ?? () #102 0x0000000000000000 in ?? () #103 0x0000000000000000 in ?? () #104 0x0000000000000000 in ?? () #105 0x0000000000000000 in ?? () #106 0x0000000000000000 in ?? () #107 0x0000000000000000 in ?? () #108 0x0000000000000000 in ?? () #109 0x0000000000000000 in ?? () #110 0x0000000000000000 in ?? () #111 0x0000000000000000 in ?? () #112 0x0000000000000000 in ?? () Cannot access memory at address 0xfffffffe8002e000 ------------ESLH01tHZyv2bPjGWDQAWF-- From owner-freebsd-stable@FreeBSD.ORG Wed May 6 10:06:02 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CAF1810656B3 for ; Wed, 6 May 2009 10:06:02 +0000 (UTC) (envelope-from byshenknet@byshenk.net) Received: from core.byshenk.net (core.byshenk.net [62.58.73.230]) by mx1.freebsd.org (Postfix) with ESMTP id 46F618FC20 for ; Wed, 6 May 2009 10:06:02 +0000 (UTC) (envelope-from byshenknet@byshenk.net) Received: from core.byshenk.net (localhost.aoes.com [127.0.0.1]) by core.byshenk.net (8.14.3/8.14.3) with ESMTP id n46A608P038737; Wed, 6 May 2009 12:06:00 +0200 (CEST) (envelope-from byshenknet@core.byshenk.net) Received: (from byshenknet@localhost) by core.byshenk.net (8.14.3/8.14.3/Submit) id n46A60FP038736; Wed, 6 May 2009 12:06:00 +0200 (CEST) (envelope-from byshenknet) Date: Wed, 6 May 2009 12:06:00 +0200 From: Greg Byshenk To: Helmut Schneider Message-ID: <20090506100559.GP1550@core.byshenk.net> References: <4A015725.3050603@ksu.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on core.byshenk.net Cc: freebsd-stable@freebsd.org Subject: Re: [7.2] R/W mount of / denied. Filesystem not clean - run fsck. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 10:06:03 -0000 On Wed, May 06, 2009 at 11:50:11AM +0200, Helmut Schneider wrote: > Marat N.Afanasyev wrote: > >Helmut Schneider wrote: > >>after upgrading a few systems yesterday from 7.1-RELEASE to 7.2-RELEASE > >>on one machine I got the error above. The problem was that > >> > >>- I was unable to cope with it but booting from a live CD. > >>- the message appeared ~ 1000 times and then the kernel paniced. > >> > >>After fsck'ing / with the help of the live CD I rebooted the machine but > >>now I got the same problem with /home. > >> > >>How can I avoid such issues (except of not letting the machine crash)? Is > >>there a way to boot at least to single user mode and then run fsck (I was > >>at home, far away from the machine, not funny)? > There is no 'login' when / cannot be mounted... > > >fsck it. if you have another machine in there, you can try to make a > >serial console. or install a ip-kvm extender ;) > > I do have such thing (IBM Blade Center) but I'm looking for something to > avoid the situation above. Something that lets me at least boot into single > user mode. If you had access to the console (I'm guessing you did in order to use the live CD), did you try booting into single-user from the beastie menu? IME, failure to fsck the / menu should drop automatically to single-user at the console, but if this fails, then you should be able to choose single-user boot from the menu, which will then not try to run fsck or mount / rw. From there you should be able to fsck and remount /, as well as /home or anything else. This will fail if there is something horribly wrong with /, causing a failure even when / is mounted ro, but then there may be no good solution. -- greg byshenk - gbyshenk@byshenk.net - Leiden, NL From owner-freebsd-stable@FreeBSD.ORG Wed May 6 10:22:34 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8681D1065675 for ; Wed, 6 May 2009 10:22:34 +0000 (UTC) (envelope-from amarat@ksu.ru) Received: from mx.kzn.ru (mx.kzn.ru [194.85.243.38]) by mx1.freebsd.org (Postfix) with ESMTP id 6BF308FC0C for ; Wed, 6 May 2009 10:22:33 +0000 (UTC) (envelope-from amarat@ksu.ru) Authentication-Results: iout.kzn.ru; dkim=neutral (message not signed) header.i=none Received-SPF: None identity=pra; client-ip=193.232.252.56; receiver=iout.kzn.ru; envelope-from="amarat@ksu.ru"; x-sender="amarat@ksu.ru"; x-conformance=sidf_compatible Received-SPF: None identity=mailfrom; client-ip=193.232.252.56; receiver=iout.kzn.ru; envelope-from="amarat@ksu.ru"; x-sender="amarat@ksu.ru"; x-conformance=sidf_compatible Received-SPF: None identity=helo; client-ip=193.232.252.56; receiver=iout.kzn.ru; envelope-from="amarat@ksu.ru"; x-sender="postmaster@ruby.ksu.ru"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArUFAOUBAUrB6Pw4/2dsb2JhbACBUL47AZAgglABG4EVBQ X-IronPort-AV: E=Sophos;i="4.40,302,1238961600"; d="p7s'?scan'208";a="3349990" Received: from mail.ksu.ru (HELO ruby.ksu.ru) ([193.232.252.56]) by iout.kzn.ru with ESMTP; 06 May 2009 14:22:32 +0400 X-Pass-Through: Kazan State University Network Received: from zealot.ksu.ru ([194.85.245.161]) by ksu.ru (8.13.4/8.13.4) with ESMTP id n469L7Bf005692; Wed, 6 May 2009 09:21:07 GMT Received: from zealot.ksu.ru (localhost.lnet [127.0.0.1]) by zealot.ksu.ru (8.14.3/8.14.3) with ESMTP id n46AEY1f072444; Wed, 6 May 2009 14:14:34 +0400 (MSD) (envelope-from amarat@ksu.ru) Message-ID: <4A01630A.5080201@ksu.ru> Date: Wed, 06 May 2009 14:14:34 +0400 From: "Marat N.Afanasyev" User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.8.1.19) Gecko/20090124 SeaMonkey/1.1.14 MIME-Version: 1.0 To: Helmut Schneider References: <4A015725.3050603@ksu.ru> In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060105000103090100030306" Cc: freebsd-stable@freebsd.org Subject: Re: [7.2] R/W mount of / denied. Filesystem not clean - run fsck. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 10:22:34 -0000 This is a cryptographically signed message in MIME format. --------------ms060105000103090100030306 Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Helmut Schneider wrote: > Marat N.Afanasyev wrote: >> Helmut Schneider wrote: >>> Hi, >>> >>> after upgrading a few systems yesterday from 7.1-RELEASE to >>> 7.2-RELEASE on one machine I got the error above. The problem was that >>> >>> - I was unable to cope with it but booting from a live CD. >>> - the message appeared ~ 1000 times and then the kernel paniced. >>> >>> After fsck'ing / with the help of the live CD I rebooted the machine >>> but now I got the same problem with /home. >>> >>> How can I avoid such issues (except of not letting the machine >>> crash)? Is there a way to boot at least to single user mode and then >>> run fsck (I was at home, far away from the machine, not funny)? >>> >>> Thanks, Helmut >>> >> if there's a problem with home you can change >> >> PermitRoorLogin yes >> >> in /etc/ssh/sshd_config, restart sshd, login as root, unmount home and > > There is no 'login' when / cannot be mounted... > >> fsck it. if you have another machine in there, you can try to make a >> serial console. or install a ip-kvm extender ;) > > I do have such thing (IBM Blade Center) but I'm looking for something to > avoid the situation above. Something that lets me at least boot into > single user mode. > if you have an ip-kvm you can drop into single-user and fsck any disk you have. all you need to do is to choose 'single user' from beastie-menu. or start kernel with -s parameter -- SY, Marat --------------ms060105000103090100030306 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII8zCC AtQwggI9oAMCAQICEHpsMo6nkbUVegxjAzzxYCkwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDQwMTE5MTUxOFoX DTEwMDQwMTE5MTUxOFowPzEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEcMBoG CSqGSIb3DQEJARYNYW1hcmF0QGtzdS5ydTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALqa7MfgjbsxmgpTOKxAN7w+cFViFA8NrULAARwVQJQJCnVRGf3i97EwNdLE8VTNniU4 ybS4gtLsy9gfNuuyPV2AJESpgrxaG+KZyHu1f6P4e31YBbnbtWVTUxZ3U/vWoL+BOAOI4S84 Cx834a4uYK75WhpZKd56qet5loyn9N1wBZNgCh9AwU31lA/Q0iCSKpEIxuhbElNXHNnqAlts CtNXsKgsT8mP7QI52h0cBOPSZqvz++e/wruJGgKeCECqo8ftwwya3CYkH1lhH2Q1zeXwez1E 1+solM48odH+odn29ctmOqr3PzZfmBJyGFf5FagTKNia/ys48yBtVU/RXHsCAwEAAaMqMCgw GAYDVR0RBBEwD4ENYW1hcmF0QGtzdS5ydTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUA A4GBAG4Pj7KRSJ/M28KNynJOPCHg26L15S9OfQ+ckMaPPDRAejtdlUdCgkoyD9d1Du/amAk6 A3NcY2I/MsFW2vSonQfU+7cJZiyuhfw7wQlOovCx7USw1dmF6u3EljWZV+Kg4Vi3vN2dPyJx tv8li9McWQoMLmm5zzFGGRaSRnnrnZFsMIIC1DCCAj2gAwIBAgIQemwyjqeRtRV6DGMDPPFg KTANBgkqhkiG9w0BAQUFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElz c3VpbmcgQ0EwHhcNMDkwNDAxMTkxNTE4WhcNMTAwNDAxMTkxNTE4WjA/MR8wHQYDVQQDExZU aGF3dGUgRnJlZW1haWwgTWVtYmVyMRwwGgYJKoZIhvcNAQkBFg1hbWFyYXRAa3N1LnJ1MIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuprsx+CNuzGaClM4rEA3vD5wVWIUDw2t QsABHBVAlAkKdVEZ/eL3sTA10sTxVM2eJTjJtLiC0uzL2B8267I9XYAkRKmCvFob4pnIe7V/ o/h7fVgFudu1ZVNTFndT+9agv4E4A4jhLzgLHzfhri5grvlaGlkp3nqp63mWjKf03XAFk2AK H0DBTfWUD9DSIJIqkQjG6FsSU1cc2eoCW2wK01ewqCxPyY/tAjnaHRwE49Jmq/P757/Cu4ka Ap4IQKqjx+3DDJrcJiQfWWEfZDXN5fB7PUTX6yiUzjyh0f6h2fb1y2Y6qvc/Nl+YEnIYV/kV qBMo2Jr/KzjzIG1VT9FcewIDAQABoyowKDAYBgNVHREEETAPgQ1hbWFyYXRAa3N1LnJ1MAwG A1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEFBQADgYEAbg+PspFIn8zbwo3Kck48IeDbovXlL059 D5yQxo88NEB6O12VR0KCSjIP13UO79qYCToDc1xjYj8ywVba9KidB9T7twlmLK6F/DvBCU6i 8LHtRLDV2YXq7cSWNZlX4qDhWLe83Z0/InG2/yWL0xxZCgwuabnPMUYZFpJGeeudkWwwggM/ MIICqKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMM V2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25z dWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYD VQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNv bmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMwNzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5 WjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRk LjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwgZ8wDQYJ KoZIhvcNAQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5owHUEcJ3f6f+jHuy9zfVb8hp2 vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuvPAsH5/EfkTYkKhPPK9Xzgnc9 A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAeZBlyYLf7AgMBAAGjgZQwgZEw EgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0hjJodHRwOi8vY3JsLnRoYXd0 ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDALBgNVHQ8EBAMCAQYwKQYDVR0R BCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0GCSqGSIb3DQEBBQUAA4GB AEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYvwPQcUCCTcDz9reFhYsPZ Ohl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bGCE6u9uo05RAaWzVN d+NWIXiC3CEZNd4ksdMdRv9dX2VPMYIDZDCCA2ACAQEwdjBiMQswCQYDVQQGEwJaQTElMCMG A1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEHpsMo6nkbUVegxjAzzxYCkwCQYFKw4DAhoF AKCCAcMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkwNTA2 MTAxNDM0WjAjBgkqhkiG9w0BCQQxFgQUuZm8MLyeh+g2evXs0D2OPR/AcTMwUgYJKoZIhvcN AQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYF Kw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhB6bDKOp5G1FXoMYwM88WApMIGHBgsq hkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAhB6bDKOp5G1FXoMYwM88WApMA0GCSqGSIb3DQEBAQUABIIBAHjvtrdF1KD961WP e9bOWlgxLjyASRPeBQeHMdC7gUETFW1UXdmwgkHjt7e3kdvIAOdMEE7+izxg/WoAiseji8Ym 6qX7gXEVG5VboxfUArCKqna8MjwzN6TAgY8FELVvjOFda5djPQ1fAl0MOXTjNlujtjNd2wCk Od8efZq5IeyUvpdAWYVULzWuavNgQw3uoL4kR54ZDvSZNQ+95IhGAFVc5RIixrQP2XehXp0c TAlb47otEXzLrVVZm49IcveMg/8awllk0mNOeB+4XqcPx0my2IwRxSQBpRfornufQiK5nsmz lhXcVbRfo2iN/YPE0GbrtO4RFqYX6lq9oIWz+W8AAAAAAAA= --------------ms060105000103090100030306-- From owner-freebsd-stable@FreeBSD.ORG Wed May 6 11:01:11 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9909C1065676 for ; Wed, 6 May 2009 11:01:11 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 281188FC0C for ; Wed, 6 May 2009 11:01:10 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1M1es6-0007Lh-MU for freebsd-stable@freebsd.org; Wed, 06 May 2009 11:01:06 +0000 Received: from 91.205.197.96 ([91.205.197.96]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 06 May 2009 11:01:06 +0000 Received: from jumper99 by 91.205.197.96 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 06 May 2009 11:01:06 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: "Helmut Schneider" Date: Wed, 6 May 2009 13:00:54 +0200 Lines: 47 Message-ID: References: <4A015725.3050603@ksu.ru> <20090506100559.GP1550@core.byshenk.net> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 91.205.197.96 X-MSMail-Priority: Normal X-Newsreader: vi with a tiny little GUI X-MimeOLE: Huh, what?! Sender: news Subject: Re: [7.2] R/W mount of / denied. Filesystem not clean - run fsck. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 11:01:12 -0000 Greg Byshenk wrote: > On Wed, May 06, 2009 at 11:50:11AM +0200, Helmut Schneider wrote: >> Marat N.Afanasyev wrote: >>> Helmut Schneider wrote: > >>>> after upgrading a few systems yesterday from 7.1-RELEASE to >>>> 7.2-RELEASE on one machine I got the error above. The problem was that >>>> >>>> - I was unable to cope with it but booting from a live CD. >>>> - the message appeared ~ 1000 times and then the kernel paniced. >>>> >>>> After fsck'ing / with the help of the live CD I rebooted the >>>> machine but now I got the same problem with /home. >>>> >>>> How can I avoid such issues (except of not letting the machine >>>> crash)? Is there a way to boot at least to single user mode and >>>> then run fsck (I was at home, far away from the machine, not funny)? > >> There is no 'login' when / cannot be mounted... >> >>> fsck it. if you have another machine in there, you can try to make a >>> serial console. or install a ip-kvm extender ;) >> >> I do have such thing (IBM Blade Center) but I'm looking for something to >> avoid the situation above. Something that lets me at least boot into >> single user mode. > > If you had access to the console (I'm guessing you did in order to use the > live CD), did you try booting into single-user from the beastie menu? Yes, I did, same issue, screen filled up with message above, after ~5 minutes kernel panic. > IME, failure to fsck the / menu should drop automatically to single-user > at the console, but if this fails, then you should be able to choose > single-user boot from the menu, which will then not try to run fsck or > mount / rw. From there you should be able to fsck and remount /, as well > as /home or anything else. This will fail if there is something horribly > wrong with /, causing a failure even when / is mounted ro, but then there > may be no good solution. There were only 2 or 3 inodes broken, fix from live CD ran smoothly. -- No Swen today, my love has gone away My mailbox stands for lorn, a symbol of the dawn From owner-freebsd-stable@FreeBSD.ORG Wed May 6 11:44:08 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4ACA810656F7 for ; Wed, 6 May 2009 11:44:08 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 89B088FC1C for ; Wed, 6 May 2009 11:44:07 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1M1fXg-0000i1-Kt for freebsd-stable@freebsd.org; Wed, 06 May 2009 11:44:04 +0000 Received: from 91.205.197.96 ([91.205.197.96]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 06 May 2009 11:44:04 +0000 Received: from jumper99 by 91.205.197.96 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 06 May 2009 11:44:04 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: "Helmut Schneider" Date: Wed, 6 May 2009 13:43:50 +0200 Lines: 329 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 91.205.197.96 X-MSMail-Priority: Normal X-Newsreader: vi with a tiny little GUI X-MimeOLE: Huh, what?! Sender: news Subject: Re: [7.2] R/W mount of / denied. Filesystem not clean - run fsck. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 11:44:08 -0000 Helmut Schneider wrote: > after upgrading a few systems yesterday from 7.1-RELEASE to 7.2-RELEASE > on one machine I got the error above. The problem was that > > - I was unable to cope with it but booting from a live CD. > - the message appeared ~ 1000 times and then the kernel paniced. Here's the debug if one is interested in (first boot after I fixed /): [root@BSDHelmut /usr/obj/usr/src/sys/GENERIC-QUOTA-PF-ALTQ]# kgdb kernel.debug /var/crash/vmcore.0 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd"... Unread portion of the kernel message buffer: Copyright (c) 1992-2009 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.2-RELEASE #4: Mon May 4 15:47:30 CEST 2009 root@BSDHelmut:/usr/obj/usr/src/sys/GENERIC-QUOTA-PF-ALTQ Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(TM) CPU 3.20GHz (3200.13-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf4a Stepping = 10 Features=0xbfebfbff Features2=0x641d AMD Features=0x20000000 AMD Features2=0x1 Logical CPUs per core: 2 real memory = 2147155968 (2047 MB) avail memory = 2091483136 (1994 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP/HT): APIC ID: 1 cpu2 (AP): APIC ID: 6 cpu3 (AP/HT): APIC ID: 7 ioapic3 irqs 72-95 on motherboard ioapic2 irqs 48-71 on motherboard ioapic1 irqs 24-47 on motherboard ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x588-0x58b on acpi0 pcib0: on acpi0 pci0: on pcib0 pci0: at device 0.1 (no driver attached) pcib1: at device 3.0 on pci0 pci4: on pcib1 pcib2: at device 0.0 on pci4 pci6: on pcib2 pcib3: at device 0.2 on pci4 pci5: on pcib3 bge0: mem 0xdcff0000-0xdcffffff irq 77 at device 1.0 on pci5 bge0: Ethernet address: 00:14:5e:bd:0e:9c bge0: [ITHREAD] bge1: mem 0xdcfe0000-0xdcfeffff irq 78 at device 1.1 on pci5 bge1: Ethernet address: 00:14:5e:bd:0e:9d bge1: [ITHREAD] pci0: at device 8.0 (no driver attached) pcib4: at device 28.0 on pci0 pci2: on pcib4 mpt0: port 0x4000-0x40ff mem 0xdeff0000-0xdeffffff,0xdefe0000-0xdefeffff irq 24 at device 1.0 on pci2 mpt0: [ITHREAD] mpt0: MPI Version=1.2.15.0 mpt0: Capabilities: ( RAID-1E RAID-1 SAFTE ) mpt0: 1 Active Volume (1 Max) mpt0: 2 Hidden Drive Members (6 Max) uhci0: port 0x2200-0x221f irq 16 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0x2600-0x261f irq 19 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered pci0: at device 29.4 (no driver attached) pcib5: at device 30.0 on pci0 pci1: on pcib5 vgapci0: port 0x3000-0x30ff mem 0xf0000000-0xf7ffffff,0xf8000000-0xf800ffff irq 20 at device 1.0 on pci1 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376 at device 31.1 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] pci0: at device 31.3 (no driver attached) sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio0: [FILTER] cpu0: on acpi0 p4tcc0: on cpu0 cpu1: on acpi0 p4tcc1: on cpu1 cpu2: on acpi0 p4tcc2: on cpu2 cpu3: on acpi0 p4tcc3: on cpu3 pmtimer0 on isa0 orm0: at iomem 0xc0000-0xc8fff pnpid ORM0000 on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: unable to set the command byte. ppc0: parallel port not found. sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 uhub2: on uhub0 uhub2: 4 ports with 4 removable, self powered umass0: on uhub2 umass1: on uhub2 ukbd0: on uhub0 kbd0 at ukbd0 ums0: on uhub0 ums0: 3 buttons and Z dir. Timecounters tick every 1.000 msec Waiting 5 seconds for SCSI devices to settle mpt0:vol0(mpt0:0:0): Settings ( Hot-Plug-Spares ) mpt0:vol0(mpt0:0:0): Using Spare Pool: 0 mpt0:vol0(mpt0:0:0): 2 Members: (mpt0:1:0:0): Primary Online (mpt0:1:1:0): Secondary Online mpt0:vol0(mpt0:0:0): RAID-1 - Optimal mpt0:vol0(mpt0:0:0): Status ( Enabled ) (mpt0:vol0:0): Physical (mpt0:0:0:0), Pass-thru (mpt0:1:0:0) (mpt0:vol0:0): Online (mpt0:vol0:1): Physical (mpt0:0:1:0), Pass-thru (mpt0:1:1:0) (mpt0:vol0:1): Online (probe3:umass-sim1:1:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe3:umass-sim1:1:0:0): CAM Status: SCSI Status Error (probe3:umass-sim1:1:0:0): SCSI Status: Check Condition (probe3:umass-sim1:1:0:0): UNIT ATTENTION asc:29,0 (probe3:umass-sim1:1:0:0): Power on, reset, or bus device reset occurred (probe3:umass-sim1:1:0:0): Retrying Command (per Sense Data) (probe2:umass-sim0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe2:umass-sim0:0:0:0): CAM Status: SCSI Status Error (probe2:umass-sim0:0:0:0): SCSI Status: Check Condition (probe2:umass-sim0:0:0:0): UNIT ATTENTION asc:29,0 (probe2:umass-sim0:0:0:0): Power on, reset, or bus device reset occurred (probe2:umass-sim0:0:0:0): Retrying Command (per Sense Data) (probe3:umass-sim1:1:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe3:umass-sim1:1:0:0): CAM Status: SCSI Status Error (probe3:umass-sim1:1:0:0): SCSI Status: Check Condition (probe3:umass-sim1:1:0:0): NOT READY asc:3a,0 (probe3:umass-sim1:1:0:0): Medium not present (probe3:umass-sim1:1:0:0): Unretryable error (probe2:umass-sim0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe2:umass-sim0:0:0:0): CAM Status: SCSI Status Error (probe2:umass-sim0:0:0:0): SCSI Status: Check Condition (probe2:umass-sim0:0:0:0): NOT READY asc:3a,0 (probe2:umass-sim0:0:0:0): Medium not present (probe2:umass-sim0:0:0:0): Unretryable error da0 at mpt0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 320.000MB/s transfers (160.000MHz, offset 63, 16bit) da0: Command Queueing Enabled da0: 69878MB (143110144 512 byte sectors: 255H 63S/T 8908C) SMP: AP CPU #2 Launched! SMP: AP CPU #1 Launched! SMP: AP CPU #3 Launched! da1 at umass-sim0 bus 0 target 0 lun 0 da1: Removable Direct Access SCSI-0 device da1: 1.000MB/s transfers da1: Attempt to query device size failed: NOT READY, Medium not present cd0 at umass-sim1 bus 1 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 1.000MB/s transfers cd0: Attempt to query device size failed: NOT READY, Medium not present GEOM_LABEL: Label for provider da0s1a is ufsid/4602dc3f7f0abdcb. GEOM_LABEL: Label for provider da0s1d is ufsid/4602dc41e4bc65f2. GEOM_LABEL: Label for provider da0s1e is ufsid/4602dc42e0009b6a. GEOM_LABEL: Label for provider da0s1f is ufsid/4602dc435ff503cc. GEOM_LABEL: Label for provider da0s2a is ufsid/49c3b072f1da1672. GEOM_LABEL: Label for provider da0s2b is ufsid/49c3b074abff4750. GEOM_LABEL: Label for provider da0s2d is ufsid/49c3b0c3bda46fb5. GEOM_LABEL: Label for provider da0s2e is ufsid/49c3b0c4862f53b3. Trying to mount root from ufs:/dev/da0s1a GEOM_LABEL: Label ufsid/4602dc3f7f0abdcb removed. GEOM_LABEL: Label ufsid/49c3b0c4862f53b3 removed. WARNING: R/W mount of /home denied. Filesystem is not clean - run fsck GEOM_LABEL: Label for provider da0s2e is ufsid/49c3b0c4862f53b3. GEOM_LABEL: Label ufsid/49c3b0c4862f53b3 removed. WARNING: R/W mount of /home denied. Filesystem is not clean - run fsck GEOM_LABEL: Label for provider da0s2e is ufsid/49c3b0c4862f53b3. GEOM_LABEL: Label ufsid/49c3b0c4862f53b3 removed. WARNING: R/W mount of /home denied. Filesystem is not clean - run fsck GEOM_LABEL: Label for provider da0s2e is ufsid/49c3b0c4862f53b3. GEOM_LABEL: Label ufsid/49c3b0c4862f53b3 removed. WARNING: R/W mount of /home denied. Filesystem is not clean - run fsck GEOM_LABEL: Label for provider da0s2e is ufsid/49c3b0c4862f53b3. GEOM_LABEL: Label ufsid/49c3b0c4862f53b3 removed. WARNING: R/W mount of /home denied. Filesystem is not clean - run fsck GEOM_LABEL: Label for provider da0s2e is ufsid/49c3b0c4862f53b3. GEOM_LABEL: Label ufsid/49c3b0c4862f53b3 removed. WARNING: R/W mount of /home denied. Filesystem is not clean - run fsck GEOM_LABEL: Label for provider da0s2e is ufsid/49c3b0c4862f53b3. GEOM_LABEL: Label ufsid/49c3b0c4862f53b3 removed. WARNING: R/W mount of /home denied. Filesystem is not clean - run fsck GEOM_LABEL: Label for provider da0s2e is ufsid/49c3b0c4862f53b3. GEOM_LABEL: Label ufsid/49c3b0c4862f53b3 removed. WARNING: R/W mount of /home denied. Filesystem is not clean - run fsck GEOM_LABEL: Label for provider da0s2e is ufsid/49c3b0c4862f53b3. GEOM_LABEL: Label ufsid/49c3b0c4862f53b3 removed. WARNING: R/W mount of /home denied. Filesystem is not clean - run fsck GEOM_LABEL: Label for provider da0s2e is ufsid/49c3b0c4862f53b3. GEOM_LABEL: Label ufsid/49c3b0c4862f53b3 removed. WARNING: R/W mount of /home denied. Filesystem is not clean - run fsck GEOM_LABEL: Label for provider da0s2e is ufsid/49c3b0c4862f53b3. GEOM_LABEL: Label ufsid/49c3b0c4862f53b3 removed. WARNING: R/W mount of /home denied. Filesystem is not clean - run fsck GEOM_LABEL: Label for provider da0s2e is ufsid/49c3b0c4862f53b3. GEOM_LABEL: Label ufsid/49c3b0c4862f53b3 removed. WARNING: R/W mount of /home denied. Filesystem is not clean - run fsck GEOM_LABEL: Label for provider da0s2e is ufsid/49c3b0c4862f53b3. GEOM_LABEL: Label ufsid/49c3b0c4862f53b3 removed. WARNING: R/W mount of /home denied. Filesystem is not clean - run fsck GEOM_LABEL: Label for provider da0s2e is ufsid/49c3b0c4862f53b3. GEOM_LABEL: Label ufsid/49c3b0c4862f53b3 removed. WARNING: R/W mount of /home denied. Filesystem is not clean - run fsck GEOM_LABEL: Label for provider da0s2e is ufsid/49c3b0c4862f53b3. GEOM_LABEL: Label ufsid/49c3b0c4862f53b3 removed. WARNING: R/W mount of /home denied. Filesystem is not clean - run fsck GEOM_LABEL: Label for provider da0s2e is ufsid/49c3b0c4862f53b3. GEOM_LABEL: Label ufsid/49c3b0c4862f53b3 removed. WARNING: R/W mount of /home denied. Filesystem is not clean - run fsck GEOM_LABEL: Label for provider da0s2e is ufsid/49c3b0c4862f53b3. GEOM_LABEL: Label ufsid/49c3b0c4862f53b3 removed. WARNING: R/W mount of /home denied. Filesystem is not clean - run fsck GEOM_LABEL: Label for provider da0s2e is ufsid/49c3b0c4862f53b3. GEOM_LABEL: Label ufsid/49c3b0c4862f53b3 removed. WARNING: R/W mount of /home denied. Filesystem is not clean - run fsck GEOM_LABEL: Label for provider da0s2e is ufsid/49c3b0c4862f53b3. GEOM_LABEL: Label ufsid/49c3b0c4862f53b3 removed. WARNING: R/W mount of /home denied. Filesystem is not clean - run fsck GEOM_LABEL: Label for provider da0s2e is ufsid/49c3b0c4862f53b3. GEOM_LABEL: Label ufsid/49c3b0c4862f53b3 removed. WARNING: R/W mount of /home denied. Filesystem is not clean - run fsck GEOM_LABEL: Label for provider da0s2e is ufsid/49c3b0c4862f53b3. GEOM_LABEL: Label ufsid/49c3b0c4862f53b3 removed. WARNING: R/W mount of /home denied. Filesystem is not clean - run fsck GEOM_LABEL: Label for provider da0s2e is ufsid/49c3b0c4862f53b3. GEOM_LABEL: Label ufsid/49c3b0c4862f53b3 removed. WARNING: R/W mount of /home denied. Filesystem is not clean - run fsck GEOM_LABEL: Label for provider da0s2e is ufsid/49c3b0c4862f53b3. GEOM_LABEL: Label ufsid/49c3b0c4862f53b3 removed. WARNING: R/W mount of /home denied. Filesystem is not clean - run fsck GEOM_LABEL: Label for provider da0s2e is ufsid/49c3b0c4862f53b3. GEOM_LABEL: Label ufsid/49c3b0c4862f53b3 removed. WARNING: R/W mount of /home denied. Filesystem is not clean - run fsck GEOM_LABEL: Label for provider da0s2e is ufsid/49c3b0c4862f53b3. GEOM_LABEL: Label ufsid/49c3b0c4862f53b3 removed. WARNING: R/W mount of /home denied. Filesystem is not clean - run fsck GEOM_LABEL: Label for provider da0s2e is ufsid/49c3b0c4862f53b3. GEOM_LABEL: Label ufsid/49c3b0c4862f53b3 removed. WARNING: R/W mount of /home denied. Filesystem is not clean - run fsck GEOM_LABEL: Label for provider da0s2e is ufsid/49c3b0c4862f53b3. GEOM_LABEL: Label ufsid/49c3b0c4862f53b3 removed. WARNING: R/W mount of /home denied. Filesystem is not clean - run fsck GEOM_LABEL: Label for provider da0s2e is ufsid/49c3b0c4862f53b3. GEOM_LABEL: Label ufsid/49c3b0c4862f53b3 removed. WARNING: R/W mount of /home denied. Filesystem is not clean - run fsck GEOM_LABEL: Label for provider da0s2e is ufsid/49c3b0c4862f53b3. ukbd0: at uhub0 port 2 (addr 5) disconnected ukbd0: detached ums0: at uhub0 port 2 (addr 5) disconnected ums0: detached Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x30 fault code = supervisor read, page not present instruction pointer = 0x20:0xc0ad121f stack pointer = 0x28:0xe5720c64 frame pointer = 0x28:0xe5720c74 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 = 16 (swi4: clock sio) trap number = 12 panic: page fault cpuid = 0 Uptime: 24s Physical memory: 2035 MB Dumping 66 MB: 51 35 19 3 Reading symbols from /boot/kernel/acpi.ko...Reading symbols from /boot/kernel/acpi.ko.symbols...done. done. Loaded symbols for /boot/kernel/acpi.ko #0 doadump () at pcpu.h:196 196 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); (kgdb) -- No Swen today, my love has gone away My mailbox stands for lorn, a symbol of the dawn From owner-freebsd-stable@FreeBSD.ORG Wed May 6 12:54:52 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F65B1065673 for ; Wed, 6 May 2009 12:54:52 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 6C3EB8FC14 for ; Wed, 6 May 2009 12:54:51 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id PAA11551; Wed, 06 May 2009 15:54:48 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4A018897.4060303@icyb.net.ua> Date: Wed, 06 May 2009 15:54:47 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.21 (X11/20090406) MIME-Version: 1.0 To: Helmut Schneider References: In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: [7.2] R/W mount of / denied. Filesystem not clean - run fsck. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 12:54:52 -0000 on 06/05/2009 14:43 Helmut Schneider said the following: > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x30 > fault code = supervisor read, page not present > instruction pointer = 0x20:0xc0ad121f > stack pointer = 0x28:0xe5720c64 > frame pointer = 0x28:0xe5720c74 > 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 = 16 (swi4: clock sio) > trap number = 12 > panic: page fault > cpuid = 0 > Uptime: 24s > Physical memory: 2035 MB > Dumping 66 MB: 51 35 19 3 > > Reading symbols from /boot/kernel/acpi.ko...Reading symbols from > /boot/kernel/acpi.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/acpi.ko > #0 doadump () at pcpu.h:196 > 196 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); > (kgdb) Output of bt command is missing after this line :-) Do you maybe have some problem with your /etc directory or your rc.conf configuration? Like missing /etc/rc.d/fsck or missing/corrupted other important rc script. Or some such - pure guessing here. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Wed May 6 13:22:15 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 167C51065674 for ; Wed, 6 May 2009 13:22:15 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 99F6D8FC16 for ; Wed, 6 May 2009 13:22:14 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1M1h4d-0005BP-4w for freebsd-stable@freebsd.org; Wed, 06 May 2009 13:22:11 +0000 Received: from 91.205.197.96 ([91.205.197.96]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 06 May 2009 13:22:11 +0000 Received: from jumper99 by 91.205.197.96 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 06 May 2009 13:22:11 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: "Helmut Schneider" Date: Wed, 6 May 2009 15:21:55 +0200 Lines: 65 Message-ID: References: <4A018897.4060303@icyb.net.ua> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 91.205.197.96 X-MSMail-Priority: Normal X-Newsreader: vi with a tiny little GUI X-MimeOLE: Huh, what?! Sender: news Subject: Re: [7.2] R/W mount of / denied. Filesystem not clean - run fsck. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 13:22:15 -0000 Andriy Gapon wrote: > on 06/05/2009 14:43 Helmut Schneider said the following: >> Fatal trap 12: page fault while in kernel mode >> cpuid = 0; apic id = 00 >> fault virtual address = 0x30 >> fault code = supervisor read, page not present >> instruction pointer = 0x20:0xc0ad121f >> stack pointer = 0x28:0xe5720c64 >> frame pointer = 0x28:0xe5720c74 >> 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 = 16 (swi4: clock sio) >> trap number = 12 >> panic: page fault >> cpuid = 0 >> Uptime: 24s >> Physical memory: 2035 MB >> Dumping 66 MB: 51 35 19 3 >> >> Reading symbols from /boot/kernel/acpi.ko...Reading symbols from >> /boot/kernel/acpi.ko.symbols...done. >> done. >> Loaded symbols for /boot/kernel/acpi.ko >> #0 doadump () at pcpu.h:196 >> 196 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); >> (kgdb) > > Output of bt command is missing after this line :-) (kgdb) bt #0 doadump () at pcpu.h:196 #1 0xc081d7e7 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 #2 0xc081dab9 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:574 #3 0xc0b1fc9c in trap_fatal (frame=0xe5720c24, eva=48) at /usr/src/sys/i386/i386/trap.c:939 #4 0xc0b1ff20 in trap_pfault (frame=0xe5720c24, usermode=0, eva=48) at /usr/src/sys/i386/i386/trap.c:852 #5 0xc0b208cc in trap (frame=0xe5720c24) at /usr/src/sys/i386/i386/trap.c:530 #6 0xc0b04fdb in calltrap () at /usr/src/sys/i386/i386/exception.s:159 #7 0xc0ad121f in atkbd_timeout (arg=0xc0d09a00) at /usr/src/sys/dev/atkbdc/atkbd.c:165 #8 0xc08301da in softclock (dummy=0x0) at /usr/src/sys/kern/kern_timeout.c:274 #9 0xc07fb74b in ithread_loop (arg=0xc5491260) at /usr/src/sys/kern/kern_intr.c:1088 #10 0xc07f8299 in fork_exit (callout=0xc07fb590 , arg=0xc5491260, frame=0xe5720d38) at /usr/src/sys/kern/kern_fork.c:810 #11 0xc0b05050 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:264 (kgdb) > Do you maybe have some problem with your /etc directory or your rc.conf > configuration? Like missing /etc/rc.d/fsck or missing/corrupted other > important rc script. Or some such - pure guessing here. 'mergemaster -iF' says it's fine. -- No Swen today, my love has gone away My mailbox stands for lorn, a symbol of the dawn From owner-freebsd-stable@FreeBSD.ORG Wed May 6 14:06:08 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 740CB106564A for ; Wed, 6 May 2009 14:06:08 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id AFF8A8FC27 for ; Wed, 6 May 2009 14:06:07 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id RAA12415; Wed, 06 May 2009 17:05:53 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4A019941.8030807@icyb.net.ua> Date: Wed, 06 May 2009 17:05:53 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.21 (X11/20090406) MIME-Version: 1.0 To: Helmut Schneider References: <4A018897.4060303@icyb.net.ua> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: [7.2] R/W mount of / denied. Filesystem not clean - run fsck. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 14:06:08 -0000 on 06/05/2009 16:21 Helmut Schneider said the following: > (kgdb) bt > #0 doadump () at pcpu.h:196 > #1 0xc081d7e7 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 > #2 0xc081dab9 in panic (fmt=Variable "fmt" is not available. > ) at /usr/src/sys/kern/kern_shutdown.c:574 > #3 0xc0b1fc9c in trap_fatal (frame=0xe5720c24, eva=48) at > /usr/src/sys/i386/i386/trap.c:939 > #4 0xc0b1ff20 in trap_pfault (frame=0xe5720c24, usermode=0, eva=48) at > /usr/src/sys/i386/i386/trap.c:852 > #5 0xc0b208cc in trap (frame=0xe5720c24) at > /usr/src/sys/i386/i386/trap.c:530 > #6 0xc0b04fdb in calltrap () at /usr/src/sys/i386/i386/exception.s:159 > #7 0xc0ad121f in atkbd_timeout (arg=0xc0d09a00) at > /usr/src/sys/dev/atkbdc/atkbd.c:165 > #8 0xc08301da in softclock (dummy=0x0) at > /usr/src/sys/kern/kern_timeout.c:274 > #9 0xc07fb74b in ithread_loop (arg=0xc5491260) at > /usr/src/sys/kern/kern_intr.c:1088 > #10 0xc07f8299 in fork_exit (callout=0xc07fb590 , > arg=0xc5491260, frame=0xe5720d38) > at /usr/src/sys/kern/kern_fork.c:810 > #11 0xc0b05050 in fork_trampoline () at > /usr/src/sys/i386/i386/exception.s:264 > (kgdb) Could you please examine frame 7? (fr 7; list; i loc; maybe some prints for the variables of interest - kbd, kbdsw) >> Do you maybe have some problem with your /etc directory or your rc.conf >> configuration? Like missing /etc/rc.d/fsck or missing/corrupted other >> important rc script. Or some such - pure guessing here. > > 'mergemaster -iF' says it's fine. > That's good. Although not very likely it's still possible that src tree might have some problems. Just in case, do you have PS/2 keyboard attached? -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Wed May 6 14:14:20 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 70EB1106564A for ; Wed, 6 May 2009 14:14:20 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 917518FC12 for ; Wed, 6 May 2009 14:14:19 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id RAA12510; Wed, 06 May 2009 17:14:16 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4A019B38.3060101@icyb.net.ua> Date: Wed, 06 May 2009 17:14:16 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.21 (X11/20090406) MIME-Version: 1.0 To: Helmut Schneider , freebsd-stable@freebsd.org References: In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: kbd0 at both atkbd0 and ukbd0 [Was: [7.2] R/W mount of / denied. Filesystem not clean - run fsck.] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 14:14:20 -0000 on 06/05/2009 14:43 Helmut Schneider said the following: > kbd1 at kbdmux0 [snip] > atkbdc0: at port 0x60,0x64 on isa0 > atkbd0: irq 1 on atkbdc0 > kbd0 at atkbd0 > atkbd0: [GIANT-LOCKED] > atkbd0: [ITHREAD] [snip] > ukbd0: on uhub0 > kbd0 at ukbd0 It took me three passes to notice the above: "kbd0 at atkbd0" and then again "kbd0 at ukbd0". I am not sure what this actually means, an expert is needed. Just in case, do you have KBD_INSTALL_CDEV in kernel config? -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Wed May 6 14:50:59 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 216C7106564A for ; Wed, 6 May 2009 14:50:59 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id D015B8FC18 for ; Wed, 6 May 2009 14:50:58 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1M1iSW-0001Gm-9M for freebsd-stable@freebsd.org; Wed, 06 May 2009 14:50:56 +0000 Received: from 91.205.197.96 ([91.205.197.96]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 06 May 2009 14:50:56 +0000 Received: from jumper99 by 91.205.197.96 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 06 May 2009 14:50:56 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: "Helmut Schneider" Date: Wed, 6 May 2009 16:50:39 +0200 Lines: 39 Message-ID: References: <4A019B38.3060101@icyb.net.ua> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 91.205.197.96 X-MSMail-Priority: Normal X-Newsreader: vi with a tiny little GUI X-MimeOLE: Huh, what?! Sender: news Subject: Re: kbd0 at both atkbd0 and ukbd0 [Was: [7.2] R/W mount of / denied. Filesystem not clean - run fsck.] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 14:50:59 -0000 Andriy Gapon wrote: > on 06/05/2009 14:43 Helmut Schneider said the following: >> kbd1 at kbdmux0 > [snip] >> atkbdc0: at port 0x60,0x64 on isa0 >> atkbd0: irq 1 on atkbdc0 >> kbd0 at atkbd0 >> atkbd0: [GIANT-LOCKED] >> atkbd0: [ITHREAD] > [snip] >> ukbd0: on uhub0 >> kbd0 at ukbd0 > > It took me three passes to notice the above: "kbd0 at atkbd0" and then > again "kbd0 at ukbd0". I am not sure what this actually means, an expert > is needed. Just in case, do you have KBD_INSTALL_CDEV in kernel config? # cat /sys/i386/conf/GENERIC-QUOTA-PF-ALTQ include GENERIC ident GENERIC-QUOTA-PF-ALTQ options QUOTA options ALTQ options ALTQ_CBQ # Class Bases Queuing (CBQ) options ALTQ_RED # Random Early Detection (RED) options ALTQ_RIO # RED In/Out options ALTQ_HFSC # Hierarchical Packet Scheduler (HFSC) options ALTQ_PRIQ # Priority Queuing (PRIQ) options ALTQ_NOPCC # Required for SMP build device pf device pflog device pfsync # -- No Swen today, my love has gone away My mailbox stands for lorn, a symbol of the dawn From owner-freebsd-stable@FreeBSD.ORG Wed May 6 15:00:08 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AE8C710656A3 for ; Wed, 6 May 2009 15:00:08 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 3827A8FC1F for ; Wed, 6 May 2009 15:00:07 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from root by ciao.gmane.org with local (Exim 4.43) id 1M1ibK-0001ij-K7 for freebsd-stable@freebsd.org; Wed, 06 May 2009 15:00:02 +0000 Received: from 91.205.197.96 ([91.205.197.96]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 06 May 2009 15:00:02 +0000 Received: from jumper99 by 91.205.197.96 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 06 May 2009 15:00:02 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: "Helmut Schneider" Date: Wed, 6 May 2009 16:54:53 +0200 Lines: 61 Message-ID: References: <4A018897.4060303@icyb.net.ua> <4A019941.8030807@icyb.net.ua> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 91.205.197.96 X-MSMail-Priority: Normal X-Newsreader: vi with a tiny little GUI X-MimeOLE: Huh, what?! Sender: news Subject: Re: [7.2] R/W mount of / denied. Filesystem not clean - run fsck. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 15:00:09 -0000 Andriy Gapon wrote: > on 06/05/2009 16:21 Helmut Schneider said the following: >> (kgdb) bt >> #0 doadump () at pcpu.h:196 >> #1 0xc081d7e7 in boot (howto=260) at >> /usr/src/sys/kern/kern_shutdown.c:418 #2 0xc081dab9 in panic >> (fmt=Variable "fmt" is not available. ) at >> /usr/src/sys/kern/kern_shutdown.c:574 #3 0xc0b1fc9c in trap_fatal >> (frame=0xe5720c24, eva=48) at /usr/src/sys/i386/i386/trap.c:939 >> #4 0xc0b1ff20 in trap_pfault (frame=0xe5720c24, usermode=0, eva=48) at >> /usr/src/sys/i386/i386/trap.c:852 >> #5 0xc0b208cc in trap (frame=0xe5720c24) at >> /usr/src/sys/i386/i386/trap.c:530 >> #6 0xc0b04fdb in calltrap () at /usr/src/sys/i386/i386/exception.s:159 >> #7 0xc0ad121f in atkbd_timeout (arg=0xc0d09a00) at >> /usr/src/sys/dev/atkbdc/atkbd.c:165 >> #8 0xc08301da in softclock (dummy=0x0) at >> /usr/src/sys/kern/kern_timeout.c:274 >> #9 0xc07fb74b in ithread_loop (arg=0xc5491260) at >> /usr/src/sys/kern/kern_intr.c:1088 >> #10 0xc07f8299 in fork_exit (callout=0xc07fb590 , >> arg=0xc5491260, frame=0xe5720d38) >> at /usr/src/sys/kern/kern_fork.c:810 >> #11 0xc0b05050 in fork_trampoline () at >> /usr/src/sys/i386/i386/exception.s:264 >> (kgdb) > > Could you please examine frame 7? (fr 7; list; i loc; maybe some prints > for the variables of interest - kbd, kbdsw) (kgdb) fr 7 #7 0xc0ad121f in atkbd_timeout (arg=0xc0d09a00) at /usr/src/sys/dev/atkbdc/atkbd.c:165 165 if ((*kbdsw[kbd->kb_index]->lock)(kbd, TRUE)) { (kgdb) list 160 * 161 * The keyboard apparently unwedges the irq in most cases. 162 */ 163 s = spltty(); 164 kbd = (keyboard_t *)arg; 165 if ((*kbdsw[kbd->kb_index]->lock)(kbd, TRUE)) { 166 /* 167 * We have seen the lock flag is not set. Let's reset 168 * the flag early, otherwise the LED update routine fails 169 * which may want the lock during the interrupt routine. (kgdb) i loc No locals. (kgdb) > Just in case, do you have PS/2 keyboard attached? No. Well. It's a module of the Blade Center which is connected via USB while mouse/keyboard are connected via PS/2. But the OS only sees an USB device. -- No Swen today, my love has gone away My mailbox stands for lorn, a symbol of the dawn From owner-freebsd-stable@FreeBSD.ORG Wed May 6 15:19:23 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 54F20106566B; Wed, 6 May 2009 15:19:23 +0000 (UTC) (envelope-from Gabor@Zahemszky.HU) Received: from relay01.digicable.hu (relay01.digicable.hu [92.249.128.189]) by mx1.freebsd.org (Postfix) with ESMTP id 600F28FC0A; Wed, 6 May 2009 15:19:22 +0000 (UTC) (envelope-from Gabor@Zahemszky.HU) Received: from [94.21.9.157] (helo=Picasso.Zahemszky.HU) by relay01.digicable.hu with esmtpa id 1M1i96-0004iz-6J ; Wed, 06 May 2009 16:30:52 +0200 Date: Wed, 6 May 2009 16:30:43 +0200 From: Zahemszky =?ISO-8859-2?Q?G=E1bor?= To: Marcel Moolenaar Message-ID: <20090506163043.0aad883b@Picasso.Zahemszky.HU> In-Reply-To: References: <20090429063852.26767.qmail@mail.integrity.hu> Organization: Zahemszky Bt. X-Mailer: Claws Mail 3.7.1 (GTK+ 2.16.1; i386-portbld-freebsd7.1) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="MP_/4DwaaI7uYI8yALurU_OsGzu" X-Original: 94.21.9.157 Cc: freebsd-stable@freebsd.org, ia64@freebsd.org Subject: Re: IA64 7.2-RC2 in HP Integrity Virtual Machine X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 15:19:23 -0000 --MP_/4DwaaI7uYI8yALurU_OsGzu Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline > I believe there's a problem with mpt(4) that relates to > its error recovery, or lack thereof. >=20 > Can you send a backtrace so that we can confirm or de- > bunk that statement? Hi! here it is. (sorry for the ESC-sequences, it is the virtual machine's EFI boot loader) Attached. G=E1bor < Gabor at Zahemszky dot HU > --=20 #!/bin/ksh Z=3D'21N16I25C25E30, 40M30E33E25T15U!'; IFS=3D' ABCDEFGHIJKLMNOPQRSTUVWXYZ '; set -- $Z;for i;{ [[ $i =3D ? ]]&&print $i&&break; [[ $i =3D ??? ]]&&j=3D$i&&i=3D${i%?}; typeset -i40 i=3D8#$i;print -n ${i#???}; [[ "$j" =3D ??? ]]&&print -n "${j#??} "&&j=3D;typeset +i i;}; IFS=3D' 0123456789 ';set -- $Z;for i;{ [[ $i =3D , ]]&&i=3D2; [[ $i =3D ?? ]]||typeset -l i;j=3D"$j $i";typeset +l i;};print "$j" --MP_/4DwaaI7uYI8yALurU_OsGzu Content-Type: application/octet-stream; name=typescript Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=typescript U2NyaXB0IHN0YXJ0ZWQgb24gV2VkIE1heSAgNiAxNDo0MDo0MSAyMDA5CiMgaHB2bXN0YXR1cyAt cCAyMApbVmlydHVhbCBNYWNoaW5lIERldGFpbHNdClZpcnR1YWwgTWFjaGluZSBOYW1lIFZNICMg IE9TIFR5cGUgU3RhdGUKPT09PT09PT09PT09PT09PT09PT0gPT09PT0gPT09PT09PSA9PT09PT09 PQpidWQtc2FhYmkgICAgICAgICAgICAgICAyMCBXSU5ET1dTIE9mZiAgICAgICAKCltBdXRob3Jp emVkIEFkbWluaXN0cmF0b3JzXQpPcGVyIEdyb3VwcyAgICAgICAgICAgICA6IApBZG1pbiBHcm91 cHMgICAgICAgICAgICA6IApPcGVyIFVzZXJzICAgICAgICAgICAgICA6IApBZG1pbiBVc2VycyAg ICAgICAgICAgICA6IAoKW1ZpcnR1YWwgQ1BVIERldGFpbHNdCiN2Q1BVcyBFbnRpdGxlbWVudCBN YXhpbXVtCj09PT09PSA9PT09PT09PT09PSA9PT09PT09CiAgICAgMSAgICAgICAxMC4wJSAgMTAw LjAlIAoKW01lbW9yeSBEZXRhaWxzXQpUb3RhbCAgICBSZXNlcnZlZApNZW1vcnkgICBNZW1vcnkg IAo9PT09PT09ICA9PT09PT09PQogICAyIEdCICAgICA2NCBNQiAKCltTdG9yYWdlIEludGVyZmFj ZSBEZXRhaWxzXQpHdWVzdCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFBoeXNpY2Fs CkRldmljZSAgQWRhcHRvciAgICBCdXMgRGV2IEZ0biBUZ3QgTHVuIFN0b3JhZ2UgICBEZXZpY2UK PT09PT09PSA9PT09PT09PT09ID09PSA9PT0gPT09ID09PSA9PT0gPT09PT09PT09ID09PT09PT09 PT09PT09PT09PT09PT09PT0KZGlzayAgICBzY3NpICAgICAgICAgMCAgIDAgICAwICAgMCAgIDAg ZGlzayAgICAgIC9kZXYvcmRpc2svZGlzazE1CmR2ZCAgICAgc2NzaSAgICAgICAgIDAgICAwICAg MCAgIDEgICAwIGZpbGUgICAgICAvdmFyL29wdC9ocHZtL0lTTy1pbWFnZXMvbGludXgvNy4yLVJF TEVBU0UtaWE2NC1ib290b25seS5pc28KCltOZXR3b3JrIEludGVyZmFjZSBEZXRhaWxzXQpJbnRl cmZhY2UgQWRhcHRvciAgICBOYW1lL051bSAgIFBvcnROdW0gQnVzIERldiBGdG4gTWFjIEFkZHJl c3MKPT09PT09PT09ID09PT09PT09PT0gPT09PT09PT09PSA9PT09PT09ID09PSA9PT0gPT09ID09 PT09PT09PT09PT09PT09CnZzd2l0Y2ggICBsYW4gICAgICAgIHZzX2xhbjIgICAgNSAgICAgICAg IDAgICAxICAgMCA0Mi1iOC00NS0wYy05OS1iZQoKW01pc2MgSW50ZXJmYWNlIERldGFpbHNdCkd1 ZXN0ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUGh5c2ljYWwKRGV2aWNlICBBZGFw dG9yICAgIEJ1cyBEZXYgRnRuIFRndCBMdW4gU3RvcmFnZSAgIERldmljZQo9PT09PT09ID09PT09 PT09PT0gPT09ID09PSA9PT0gPT09ID09PSA9PT09PT09PT0gPT09PT09PT09PT09PT09PT09PT09 PT09PQpzZXJpYWwgIGNvbTEgICAgICAgICAgICAgICAgICAgICAgICAgICB0dHkgICAgICAgY29u c29sZQojIGhwdm1zdGFydCAtcCAyMAooQykgQ29weXJpZ2h0IDIwMDAgLSAyMDA5IEhld2xldHQt UGFja2FyZCBEZXZlbG9wbWVudCBDb21wYW55LCBMLlAuCk9wZW5pbmcgbWlub3IgZGV2aWNlIGFu ZCBjcmVhdGluZyBndWVzdCBtYWNoaW5lIGNvbnRhaW5lcgpDcmVhdGlvbiBvZiBWTSwgbWlub3Ig ZGV2aWNlIDUKQWxsb2NhdGluZyBndWVzdCBtZW1vcnk6IDIwNDhNQgogIGFsbG9jYXRpbmcgbG93 IFJBTSAoMC04MDAwMDAwMCwgMjA0OE1CKQovb3B0L2hwdm0vbGJpbi9ocHZtYXBwICgvdmFyL29w dC9ocHZtL3V1aWRzL2VhZjZkODc4LWU3YWItMTFkZC1hMzAyLTAwMWUwYjQ1MDkwMC92bW1fY29u ZmlnLmN1cnJlbnQpOiBBbGxvY2F0ZWQgMjE0NzQ4MzY0OCBieXRlcyBhdCAweDYwMDAwMDAxMDAw MDAwMDAKICAgIGxvY2tpbmcgbWVtb3J5OiAwLTgwMDAwMDAwCiAgYWxsb2NhdGluZyBkYXRhbG9n Z2VyIG1lbW9yeTogRkY4MDAwMDAtRkY4MTAwMDAgKDY0S0IgZm9yIDEyS0IpCi9vcHQvaHB2bS9s YmluL2hwdm1hcHAgKC92YXIvb3B0L2hwdm0vdXVpZHMvZWFmNmQ4NzgtZTdhYi0xMWRkLWEzMDIt MDAxZTBiNDUwOTAwL3ZtbV9jb25maWcuY3VycmVudCk6IEFsbG9jYXRlZCA2NTUzNiBieXRlcyBh dCAweDYwMDAwMDAyMDAwMDAwMDAKICAgIGxvY2tpbmcgZGF0YWxvZ2dlciBtZW1vcnkKICBhbGxv Y2F0aW5nIGZpcm13YXJlIFJBTSAoZmZmMDAwMDAtZmZmMjAwMDAsIDEyOEtCKQovb3B0L2hwdm0v bGJpbi9ocHZtYXBwICgvdmFyL29wdC9ocHZtL3V1aWRzL2VhZjZkODc4LWU3YWItMTFkZC1hMzAy LTAwMWUwYjQ1MDkwMC92bW1fY29uZmlnLmN1cnJlbnQpOiBBbGxvY2F0ZWQgMTMxMDcyIGJ5dGVz IGF0IDB4NjAwMDAwMDIwMDAyMDAwMAogICAgbG9ja2VkIFNBTCBSQU06IDAwMDAwMDAwZmZmMDAw MDAgKDhLQikKICAgIGxvY2tlZCBFU0kgUkFNOiAwMDAwMDAwMGZmZjAyMDAwICg4S0IpCiAgICBs b2NrZWQgUEFMIFJBTTogMDAwMDAwMDBmZmYwNDAwMCAoOEtCKQogICAgbG9ja2VkIE1pbiBTYXZl IFN0YXRlOiAwMDAwMDAwMGZmZjA2MDAwICg0S0IpCiAgICBsb2NrZWQgZGF0YWxvZ2dlcjogMDAw MDAwMDBmZjgwMDAwMCAoNjRLQikKTG9hZGluZyBib290IGltYWdlCkltYWdlIGluaXRpYWwgSVA9 MTAyMDAwIEdQPTY4NjAwMApJbml0aWFsaXplIGd1ZXN0IG1lbW9yeSBtYXBwaW5nIHRhYmxlcwpT dGFydGluZyBldmVudCBwb2xsaW5nIHRocmVhZApTdGFydGluZyB0aHJlYWQgaW5pdGlhbGl6YXRp b24KRGFlbW9uaXppbmcuLi4uCmhwdm1zdGFydDogU3VjY2Vzc2Z1bCBzdGFydCBpbml0aWF0aW9u IG9mIGd1ZXN0ICdidWQtc2FhYmknCiMgaHB2bWNvbnNvbGUgLXAgMjAKCgogICB2TVAgTUFJTiBN RU5VCgogICAgICAgICBDTzogQ29uc29sZQogICAgICAgICBDTTogQ29tbWFuZCBNZW51CiAgICAg ICAgIENMOiBDb25zb2xlIExvZwogICAgICAgICBTTDogU2hvdyBFdmVudCBMb2dzCiAgICAgICAg IFZNOiBWaXJ0dWFsIE1hY2hpbmUgTWVudQogICAgICAgICBIRTogTWFpbiBIZWxwIE1lbnUKICAg ICAgICAgIFg6IEV4aXQgQ29ubmVjdGlvbgoKW2J1ZC1zYWFiaV0gdk1QPiBjbwoKCgogICAgICAg IChVc2UgQ3RybC1CIHRvIHJldHVybiB0byB2TVAgbWFpbiBtZW51LikKCgoKLSAtIC0gLSAtIC0g LSAtIC0gLSBQcmlvciBDb25zb2xlIE91dHB1dCAtIC0gLSAtIC0gLSAtIC0gLSAtCgpMb2FkaW5n LjogQXV4aWxpYXJ5IEZsb2F0aW5nIFBvaW50IERyaXZlcgpTdGFydGluZzogQXV4aWxpYXJ5IEZs b2F0aW5nIFBvaW50IERyaXZlcgpTdGFydCBvZiBBdXhpbGlhcnkgRmxvYXRpbmcgUG9pbnQgRHJp dmVyIGZhaWxlZDogQWxyZWFkeSBzdGFydGVkCgobWzBtG1szN20bWzQwbRtbMkobWzAxOzAxSBtb MW0bWzMzbRtbNDBtRUZJIEJvb3QgTWFuYWdlciB2ZXIgMS4xMCBbMTQuNjJdIFtCdWlsZDogTW9u IE5vdiAgMyAxNDoxODo1NiAyMDA4XQoKUGxlYXNlIHNlbGVjdCBhIGJvb3Qgb3B0aW9uChtbMDU7 MDVIG1swbRtbMzdtG1s0MG1XaW5kb3dzIFNlcnZlciAyMDAzLCBFbnRlcnByaXNlICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgG1swNjswNUgbWzBtG1szN20bWzQwbUVGSSBTaGVsbCBb QnVpbHQtaW5dICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAbWzA3 OzA1SBtbMG0bWzM3bRtbNDBtQm9vdCBvcHRpb24gbWFpbnRlbmFuY2UgbWVudSAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIBtbMTA7MDVIVXNlIF4gYW5kIHYgdG8gY2hhbmdlIG9w dGlvbihzKS4gVXNlIEVudGVyIHRvIHNlbGVjdCBhbiBvcHRpb24KG1swNzswNUhCb290IG9wdGlv biBtYWludGVuYW5jZSBtZW51ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgG1sw bRtbMzBtG1s0N20bWzA1OzA1SFdpbmRvd3MgU2VydmVyIDIwMDMsIEVudGVycHJpc2UgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAbWzBtG1szN20bWzQwbRtbMTE7MDVIRGVmYXVsdCBi b290IHNlbGVjdGlvbiB3aWxsIGJlIGJvb3RlZCBpbiAzMCBzZWNvbmRzICAbWzExOzA1SERlZmF1 bHQgYm9vdCBzZWxlY3Rpb24gd2lsbCBiZSBib290ZWQgaW4gMjkgc2Vjb25kcyAgG1sxMTswNUhE ZWZhdWx0IGJvb3Qgc2VsZWN0aW9uIHdpbGwgYmUgYm9vdGVkIGluIDI4IHNlY29uZHMgIBtbMTE7 MDVIRGVmYXVsdCBib290IHNlbGVjdGlvbiB3aWxsIGJlIGJvb3RlZCBpbiAyNyBzZWNvbmRzICAb WzExOzA1SERlZmF1bHQgYm9vdCBzZWxlY3Rpb24gd2lsbCBiZSBib290ZWQgaW4gMjYgc2Vjb25k cyAgCi0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtIExpdmUgQ29uc29sZSAtIC0gLSAtIC0gLSAtIC0g LSAtIC0gLQobWzExOzA1SERlZmF1bHQgYm9vdCBzZWxlY3Rpb24gd2lsbCBiZSBib290ZWQgaW4g MjUgc2Vjb25kcyAgG1sxMTswNUggICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgG1swNTswNUhXaW5kb3dzIFNlcnZlciAyMDAzLCBF bnRlcnByaXNlICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgG1swbRtbMzBtG1s0N20b WzA2OzA1SEVGSSBTaGVsbCBbQnVpbHQtaW5dICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAbWzBtG1szN20bWzQwbRtbMTE7MDVIICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIBtbMDY7MDVIG1sxbRtb MzdtG1s0MG1FRkkgU2hlbGwgW0J1aWx0LWluXSAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgG1sxMDswMUgKTG9hZGluZy46IEVGSSBTaGVsbCBbQnVpbHQtaW5dChtb MW0bWzMzbRtbNDBtRUZJIFNoZWxsIHZlcnNpb24gMS4xMCBbMTQuNjJdChtbMG0bWzM3bRtbNDBt G1swbRtbMzdtG1s0MG0bWzBtG1szN20bWzQwbRtbMG0bWzM3bRtbNDBtG1swbRtbMzdtG1s0MG0b WzBtG1szN20bWzQwbRtbMG0bWzM3bRtbNDBtG1swbRtbMzdtG1s0MG0bWzBtG1szN20bWzQwbRtb MG0bWzM3bRtbNDBtG1swbRtbMzdtG1s0MG0bWzBtG1szN20bWzQwbRtbMG0bWzM3bRtbNDBtG1sw bRtbMzdtG1s0MG0bWzBtG1szN20bWzQwbRtbMG0bWzM3bRtbNDBtG1swbRtbMzdtG1s0MG0bWzBt G1szN20bWzQwbRtbMG0bWzM3bRtbNDBtG1swbRtbMzdtG1s0MG0bWzBtG1szN20bWzQwbRtbMG0b WzM3bRtbNDBtG1swbRtbMzdtG1s0MG0bWzBtG1szN20bWzQwbRtbMG0bWzM3bRtbNDBtG1swbRtb MzdtG1s0MG0bWzBtG1szN20bWzQwbRtbMG0bWzM3bRtbNDBtG1swbRtbMzdtG1s0MG0bWzBtG1sz N20bWzQwbRtbMG0bWzM3bRtbNDBtG1swbRtbMzdtG1s0MG0bWzBtG1szN20bWzQwbRtbMG0bWzM3 bRtbNDBtG1swbRtbMzdtG1s0MG0bWzBtG1szN20bWzQwbRtbMG0bWzM3bRtbNDBtG1swbRtbMzdt G1s0MG0bWzBtG1szN20bWzQwbRtbMG0bWzM3bRtbNDBtG1swbRtbMzdtG1s0MG0bWzBtG1szN20b WzQwbRtbMG0bWzM3bRtbNDBtG1swbRtbMzdtG1s0MG0bWzBtG1szN20bWzQwbRtbMG0bWzM3bRtb NDBtG1swbRtbMzdtG1s0MG0bWzBtG1szN20bWzQwbRtbMG0bWzM3bRtbNDBtG1swbRtbMzdtG1s0 MG0bWzFtG1szM20bWzQwbURldmljZSBtYXBwaW5nIHRhYmxlG1swbRtbMzdtG1s0MG0KICAbWzFt G1szN20bWzQwbWZzMCAbWzBtG1szN20bWzQwbSA6IEFjcGkoUE5QMEEwMywwKS9QY2koMHwwKS9T Y3NpKFB1bjAsTHVuMCkvSEQoUGFydDEsU2lnNDQ5RDZCRTAtQzgwQy0wMUM5LTkyRTAtM0M3NzJF NDNBQzQwKQogIBtbMW0bWzM3bRtbNDBtZnMxIBtbMG0bWzM3bRtbNDBtIDogQWNwaShQTlAwQTAz LDApL1BjaSgwfDApL1Njc2koUHVuMSxMdW4wKS9DRFJPTShFbnRyeTApCiAgG1sxbRtbMzdtG1s0 MG1ibGswG1swbRtbMzdtG1s0MG0gOiBBY3BpKFBOUDBBMDMsMCkvUGNpKDB8MCkvU2NzaShQdW4w LEx1bjApCiAgG1sxbRtbMzdtG1s0MG1ibGsxG1swbRtbMzdtG1s0MG0gOiBBY3BpKFBOUDBBMDMs MCkvUGNpKDB8MCkvU2NzaShQdW4wLEx1bjApL0hEKFBhcnQxLFNpZzQ0OUQ2QkUwLUM4MEMtMDFD OS05MkUwLTNDNzcyRTQzQUM0MCkKICAbWzFtG1szN20bWzQwbWJsazIbWzBtG1szN20bWzQwbSA6 IEFjcGkoUE5QMEEwMywwKS9QY2koMHwwKS9TY3NpKFB1bjAsTHVuMCkvSEQoUGFydDIsU2lnNDRB ODFBNDAtQzgwQy0wMUM5LTUwN0ItOUU1RjgwNzhGNTMxKQogIBtbMW0bWzM3bRtbNDBtYmxrMxtb MG0bWzM3bRtbNDBtIDogQWNwaShQTlAwQTAzLDApL1BjaSgwfDApL1Njc2koUHVuMCxMdW4wKS9I RChQYXJ0MyxTaWc0RTVBQjUyMC1DODBDLTAxQzktRjFCMy0xMjcxNEY3NTg4MjEpCiAgG1sxbRtb MzdtG1s0MG1ibGs0G1swbRtbMzdtG1s0MG0gOiBBY3BpKFBOUDBBMDMsMCkvUGNpKDB8MCkvU2Nz aShQdW4xLEx1bjApCiAgG1sxbRtbMzdtG1s0MG1ibGs1G1swbRtbMzdtG1s0MG0gOiBBY3BpKFBO UDBBMDMsMCkvUGNpKDB8MCkvU2NzaShQdW4xLEx1bjApL0NEUk9NKEVudHJ5MCkKG1swbRtbMzdt G1s0MG0bWzBtG1szN20bWzQwbRtbMG0bWzM3bRtbNDBtG1syNTswMUgbWzFtG1szM20bWzQwbVNo ZWxsPiAbWzI1OzA4SGYbWzI1OzA5SBtbMjU7MDlIcxtbMjU7MTBIG1syNTsxMEgxG1syNTsxMUgb WzI1OzExSDobWzI1OzEySBtbMjU7MTJIICAKG1swbRtbMzdtG1s0MG0bWzBtG1szN20bWzQwbQob WzI1OzAxSBtbMW0bWzMzbRtbNDBtZnMxOlw+IBtbMjU7MDhIZBtbMjU7MDlIG1syNTswOUhpG1sy NTsxMEgbWzI1OzEwSHIbWzI1OzExSBtbMjU7MTFIICAKG1swbRtbMzdtG1s0MG1EaXJlY3Rvcnkg b2Y6IBtbMW0bWzM3bRtbNDBtZnMxOlwbWzBtG1szN20bWzQwbQoKICAwNS8wMi8wOSAgMDQ6MDRh IDxESVI+ICAgICAgICAgIDgsMTkyICBlZmkKICAwNS8wMi8wOSAgMDQ6MDRhIDxESVI+ICAgICAg ICAgIDgsMTkyICBib290CiAgICAgICAgICAwIEZpbGUocykgICAgICAgICAgIDAgYnl0ZXMKICAg ICAgICAgIDIgRGlyKHMpCgobWzBtG1szN20bWzQwbQobWzI1OzAxSBtbMW0bWzMzbRtbNDBtZnMx Olw+IBtbMjU7MDhIZBtbMjU7MDlIG1syNTswOUhpG1syNTsxMEgbWzI1OzEwSHIbWzI1OzExSBtb MjU7MTFIIBtbMjU7MTJIG1syNTsxMkhiG1syNTsxM0gbWzI1OzEzSG8bWzI1OzE0SBtbMjU7MTRI bxtbMjU7MTVIG1syNTsxNUh0G1syNTsxNkgbWzI1OzE2SCAgChtbMG0bWzM3bRtbNDBtRGlyZWN0 b3J5IG9mOiAbWzFtG1szN20bWzQwbWZzMTpcYm9vdBtbMG0bWzM3bRtbNDBtCgogIDA1LzAyLzA5 ICAwNDowNGEgPERJUj4gICAgICAgICAgOCwxOTIgIC4KICAwNS8wMi8wOSAgMDQ6MDRhIDxESVI+ ICAgICAgICAgICAgICAwICAuLgogIDA1LzAyLzA5ICAwNDowNGEgPERJUj4gICAgICAgICAgOCwx OTIgIGtlcm5lbAogIDA1LzAyLzA5ICAwNDowNGEgPERJUj4gICAgICAgICAgOCwxOTIgIGRlZmF1 bHRzCiAgMDUvMDIvMDkgIDA0OjA0YSAgICAgICByICAgICAgICAgIDExNyAgZGV2aWNlLmhpbnRz CiAgMDUvMDIvMDkgIDA0OjA0YSAgICAgICByICAgICAgICAgIDM2MCAgbG9hZGVyLnJjCiAgMDUv MDIvMDkgIDA0OjA0YSAgICAgICByICAgICAgIDEzLDMyMCAgbG9hZGVyLmhlbHAKICAwNS8wMi8w OSAgMDQ6MDRhICAgICAgICAgICAgICAgICAgIDcyICBsb2FkZXIuY29uZgogIDA1LzAyLzA5ICAw NDowNGEgICAgICAgciAgICAgICAgNSw4NjUgIGxvYWRlci40dGgKICAwNS8wMi8wOSAgMDQ6MDRh ICAgICAgICAgICAgMSw4OTUsODA3ICBtZnNyb290Lmd6CiAgMDUvMDIvMDkgIDA0OjA0YSAgICAg ICByICAgICAgIDM1LDEzNiAgc3VwcG9ydC40dGgKICAgICAgICAgIDcgRmlsZShzKSAgIDEsOTUw LDY3NyBieXRlcwogICAgICAgICAgNCBEaXIocykKChtbMG0bWzM3bRtbNDBtChtbMjU7MDFIG1sx bRtbMzNtG1s0MG1mczE6XD4gG1syNTswOEhkG1syNTswOUgbWzI1OzA5SGkbWzI1OzEwSBtbMjU7 MTBIchtbMjU7MTFIG1syNTsxMUggG1syNTsxMkgbWzI1OzEySGUbWzI1OzEzSBtbMjU7MTNIZhtb MjU7MTRIG1syNTsxNEhpG1syNTsxNUgbWzI1OzE1SCAgChtbMG0bWzM3bRtbNDBtRGlyZWN0b3J5 IG9mOiAbWzFtG1szN20bWzQwbWZzMTpcZWZpG1swbRtbMzdtG1s0MG0KCiAgMDUvMDIvMDkgIDA0 OjA0YSA8RElSPiAgICAgICAgICA4LDE5MiAgLgogIDA1LzAyLzA5ICAwNDowNGEgPERJUj4gICAg ICAgICAgICAgIDAgIC4uCiAgMDUvMDIvMDkgIDA0OjA0YSA8RElSPiAgICAgICAgICA4LDE5MiAg Ym9vdAogICAgICAgICAgMCBGaWxlKHMpICAgICAgICAgICAwIGJ5dGVzCiAgICAgICAgICAzIERp cihzKQoKG1swbRtbMzdtG1s0MG0KG1syNTswMUgbWzFtG1szM20bWzQwbWZzMTpcPiAbWzI1OzA4 SGQbWzI1OzA5SBtbMjU7MDlIaRtbMjU7MTBIG1syNTsxMEhyG1syNTsxMUgbWzI1OzExSCAbWzI1 OzEySBtbMjU7MTJIZRtbMjU7MTNIG1syNTsxM0hmG1syNTsxNEgbWzI1OzE0SGkbWzI1OzE1SBtb MjU7MTVIXBtbMjU7MTZIG1syNTsxNkhiG1syNTsxN0gbWzI1OzE3SG8bWzI1OzE4SBtbMjU7MThI bxtbMjU7MTlIG1syNTsxOUh0G1syNTsyMEgbWzI1OzIwSCAgChtbMG0bWzM3bRtbNDBtRGlyZWN0 b3J5IG9mOiAbWzFtG1szN20bWzQwbWZzMTpcZWZpXGJvb3QbWzBtG1szN20bWzQwbQoKICAwNS8w Mi8wOSAgMDQ6MDRhIDxESVI+ICAgICAgICAgIDgsMTkyICAuCiAgMDUvMDIvMDkgIDA0OjA0YSA8 RElSPiAgICAgICAgICA4LDE5MiAgLi4KICAwNS8wMi8wOSAgMDQ6MDRhICAgICAgIHIgICAgICA1 NzksNDc1ICBib290aWE2NC5lZmkKICAgICAgICAgIDEgRmlsZShzKSAgICAgNTc5LDQ3NSBieXRl cwogICAgICAgICAgMiBEaXIocykKChtbMG0bWzM3bRtbNDBtChtbMjU7MDFIG1sxbRtbMzNtG1s0 MG1mczE6XD4gG1syNTswOEhlG1syNTswOUgbWzI1OzA5SGYbWzI1OzEwSBtbMjU7MTBIaRtbMjU7 MTFIG1syNTsxMUhcG1syNTsxMkgbWzI1OzEySGIbWzI1OzEzSBtbMjU7MTNIbxtbMjU7MTRIG1sy NTsxNEhvG1syNTsxNUgbWzI1OzE1SHQbWzI1OzE2SBtbMjU7MTZIXBtbMjU7MTdIG1syNTsxN0hi G1syNTsxOEgbWzI1OzE4SG8bWzI1OzE5SBtbMjU7MTlIbxtbMjU7MjBIG1syNTsyMEh0G1syNTsy MUgbWzI1OzIxSGkbWzI1OzIySBtbMjU7MjJIYRtbMjU7MjNIG1syNTsyM0g2G1syNTsyNEgbWzI1 OzI0SDQbWzI1OzI1SBtbMjU7MjVILhtbMjU7MjZIG1syNTsyNkhlG1syNTsyN0gbWzI1OzI3SGYb WzI1OzI4SBtbMjU7MjhIaRtbMjU7MjlIG1syNTsyOUggIAobWzBtG1szN20bWzQwbRtbMG0bWzM3 bRtbNDBtQ29uc29sZXM6IEVGSSBjb25zb2xlICAKSW1hZ2UgYmFzZTogMHgwMDAwMDAwMDdlZjZk MDAwCgpGcmVlQlNEL2lhNjQgRUZJIGJvb3QsIFJldmlzaW9uIDEuMgoocm9vdEBwbHV0bzEuZnJl ZWJzZC5vcmcsIEZyaSBNYXkgIDEgMTc6MTY6NTcgVVRDIDIwMDkpCnwILwhMb2FkaW5nIC9ib290 L2RlZmF1bHRzL2xvYWRlci5jb25mIAotCFwIfAgvCC0IXAh8CC8IL2Jvb3Qva2VybmVsL2tlcm5l bCB0ZXh0PTB4YjRmYjI4IGRhdGE9MHhhY2NjOCsweDQ1MTkwIHN5bXM9WzB4OCsweDgxN2Y4KzB4 OCsweDcxMWJmXQotCFwIfAgvCApIaXQgW0VudGVyXSB0byBib290IGltbWVkaWF0ZWx5LCBvciBh bnkgb3RoZXIga2V5IGZvciBjb21tYW5kIHByb21wdC4KDUJvb3RpbmcgWy9ib290L2tlcm5lbC9r ZXJuZWxdIGluIDkgc2Vjb25kcy4uLiANQm9vdGluZyBbL2Jvb3Qva2VybmVsL2tlcm5lbF0gaW4g OCBzZWNvbmRzLi4uIAoKVHlwZSAnPycgZm9yIGEgbGlzdCBvZiBjb21tYW5kcywgJ2hlbHAnIGZv ciBtb3JlIGRldGFpbGVkIGhlbHAuCk9LIHNldCBib290X3ZlcmJvc2U9MQpPSyBhdXRvYm9vdD0x CmF1dG9ib290PTEgbm90IGZvdW5kCk9LIGF1dG9ib290IDEKSGl0IFtFbnRlcl0gdG8gYm9vdCBp bW1lZGlhdGVseSwgb3IgYW55IG90aGVyIGtleSBmb3IgY29tbWFuZCBwcm9tcHQuCg1Cb290aW5n IFsvYm9vdC9rZXJuZWwva2VybmVsXS4uLiAgICAgICAgICAgICAgIAotCFwIRW50ZXJpbmcgL2Jv b3Qva2VybmVsL2tlcm5lbCBhdCAweGUwMDAwMDAwMDQwNzgwMDAuLi4KUEFMIFByb2MgYXQgMHhl MDAwMDAwMGZmZjA0MDAwClNBTCBQcm9jIGF0IDB4ZTAwMDAwMDBmZmYwMDAwMCwgR1AgYXQgMHhl MDAwMDAwMGZmZjE3MDAwClNBTDogQVAgd2FrZS11cCB2ZWN0b3I6IDB4ZWUKUGxhdGZvcm0gY2xv Y2sgZnJlcXVlbmN5IDI2NjE0MTcwMCBIegpQcm9jZXNzb3IgcmF0aW8gMTYwMC8yNjcsIEJ1cyBy YXRpbyAxLzEsIElUQyByYXRpbyA2LzQKcHRjLmUgYmFzZT0weDAsIGNvdW50MT0xLCBjb3VudDI9 MSwgc3RyaWRlMT0weDAsIHN0cmlkZTI9MHgwClByb2Nlc3NvciBzdXBwb3J0cyAyMSBSZWdpb24g SUQgYml0cwpUcnlpbmcgVkhQVCBzaXplIDB4ODAwMDAwClB1dHRpbmcgVkhQVCBhdCAweDgwMDAw MApTcGxpdHRpbmcgWzB4NjM0MDAwLTB4NDAwMDAwMF0KR0RCOiBubyBkZWJ1ZyBwb3J0cyBwcmVz ZW50CktEQjogZGVidWdnZXIgYmFja2VuZHM6IGRkYgpLREI6IGN1cnJlbnQgYmFja2VuZDogZGRi CkNvcHlyaWdodCAoYykgMTk5Mi0yMDA5IFRoZSBGcmVlQlNEIFByb2plY3QuCkNvcHlyaWdodCAo YykgMTk3OSwgMTk4MCwgMTk4MywgMTk4NiwgMTk4OCwgMTk4OSwgMTk5MSwgMTk5MiwgMTk5Mywg MTk5NAoJVGhlIFJlZ2VudHMgb2YgdGhlIFVuaXZlcnNpdHkgb2YgQ2FsaWZvcm5pYS4gQWxsIHJp Z2h0cyByZXNlcnZlZC4KRnJlZUJTRCBpcyBhIHJlZ2lzdGVyZWQgdHJhZGVtYXJrIG9mIFRoZSBG cmVlQlNEIEZvdW5kYXRpb24uCkZyZWVCU0QgNy4yLVJFTEVBU0UgIzA6IFNhdCBNYXkgIDIgMDI6 NTc6NTMgVVRDIDIwMDkKICAgIHJvb3RAcGx1dG8xLmZyZWVic2Qub3JnOi91c3Ivb2JqL3Vzci9z cmMvc3lzL0dFTkVSSUMKVU5XSU5EOiB0YWJsZSBhZGRlZDogYmFzZT1lMDAwMDAwMDA0MDAwMDAw LCBzdGFydD1lMDAwMDAwMDA0YjE0MzgwLCBlbmQ9ZTAwMDAwMDAwNGI0ZmIyOApQcmVsb2FkZWQg ZWxmIGtlcm5lbCAiL2Jvb3Qva2VybmVsL2tlcm5lbCIgYXQgMHhlMDAwMDAwMDA1NTM2ODIwLgpQ cmVsb2FkZWQgbWZzX3Jvb3QgIi9ib290L21mc3Jvb3QiIGF0IDB4ZTAwMDAwMDAwNTUzNjhmMC4K Q1BVOiB1bmtub3duICgxNTk0Ljg2LU1oeiBJdGFuaXVtIDIpCiAgT3JpZ2luID0gIkdlbnVpbmVJ bnRlbCIgIFJldmlzaW9uID0gMQogIEZlYXR1cmVzID0gMHhkPExCLEFPPgpyZWFsIG1lbW9yeSAg PSAyMTMzODYwMzUyICgyMDM1IE1CKQpQaHlzaWNhbCBtZW1vcnkgY2h1bmsocyk6CjB4MDM4MDAw MDAgLSAweDAzZmZmZmZmLCA4Mzg4NjA4IGJ5dGVzICgxMDI0IHBhZ2VzKQoweDA1NTM4MDAwIC0g MHg3ZDFjN2ZmZiwgMjAwOTY2MTQ0MCBieXRlcyAoMjQ1MzIwIHBhZ2VzKQoweDdlZmZlMDAwIC0g MHg3ZjQ1M2ZmZiwgNDU0NjU2MCBieXRlcyAoNTU1IHBhZ2VzKQoweDdmODAyMDAwIC0gMHg3Zjhh ZGZmZiwgNzA0NTEyIGJ5dGVzICg4NiBwYWdlcykKMHg3ZjlmZTAwMCAtIDB4N2ZkMmRmZmYsIDMz NDIzMzYgYnl0ZXMgKDQwOCBwYWdlcykKMHg3ZmRmZTAwMCAtIDB4N2ZlM2RmZmYsIDI2MjE0NCBi eXRlcyAoMzIgcGFnZXMpCjB4N2ZlN2UwMDAgLSAweDdmZmI5ZmZmLCAxMjk0MzM2IGJ5dGVzICgx NTggcGFnZXMpCmF2YWlsIG1lbW9yeSA9IDIwMTYwNTkzOTIgKDE5MjIgTUIpCkZQU1dBIFJldmlz aW9uID0gMHgxMDAxMiwgRW50cnkgPSAweGUwMDAwMDAwN2ZkN2EwNTAKVGFibGUgJ0ZBQ1AnIGF0 IDB4ZTAwMDAwMDAwMDAyNmI0MApUYWJsZSAnQVBJQycgYXQgMHhlMDAwMDAwMDAwMDI1Mzg4CglM b2NhbCBBUElDIGFkZHJlc3M9MHhmZWUwMDAwMAoJTG9jYWwgU0FQSUMgZW50cnkKCQlQcm9jZXNz b3JJZD0weDAsIElkPTB4MCwgRWlkPTB4MAoJSS9PIFNBUElDIGVudHJ5CgkJSWQ9MHgwLCBJbnRl cnJ1cHRCYXNlPTB4MCwgQWRkcmVzcz0weGZlYzAwMDAwClRhYmxlICdTUENSJyBhdCAweGUwMDAw MDAwMDAwMjZjMzgKVGFibGUgJ1NQTUknIGF0IDB4ZTAwMDAwMDAwMDAyNmM4OApUYWJsZSAnQ1BF UCcgYXQgMHhlMDAwMDAwMDAwMDI2Y2M4Ck1DQTogYWxsb2NhdGVkIDgxOTIgYnl0ZXMgZm9yIHN0 YXRlIGluZm8uCm1lbTogPG1lbW9yeT4KbnVsbDogPG51bGwgZGV2aWNlLCB6ZXJvIGRldmljZT4K bmZzbG9jazogcHNldWRvLWRldmljZQpyYW5kb206IDxlbnRyb3B5IHNvdXJjZSwgU29mdHdhcmUs IFlhcnJvdz4KQUNQSTogUlNEUCBAIDB4MHgyNmQ4OC8weDAwMjggKHYgIDIgICBfSFBfKQpBQ1BJ OiBYU0RUIEAgMHgweDI2ZDM4LzB4MDA0QyAodiAgMiAgIF9IUF8gICAgIFZNTSAgMHgwMDAwMDAw MCBfSFBfIDB4MDAwMDAwMDApCkFDUEk6IEZBQ1AgQCAweDB4MjZiNDAvMHgwMEY0ICh2ICAzICAg X0hQXyAgICAgVk1NICAweDAwMDAwMDAwIF9IUF8gMHgwMDAwMDAwMCkKQUNQSTogRFNEVCBAIDB4 MHgyNTNkMC8weDE3MkIgKHYgIDEgICAgIEhQICAgICBIUFZNIDB4MDAwMDAwMDAgSU5UTCAweDIw MDYwOTEyKQpBQ1BJOiBGQUNTIEAgMHgweDI2YjAwLzB4MDA0MApBQ1BJOiBBUElDIEAgMHgweDI1 Mzg4LzB4MDA0OCAodiAgMiAgIF9IUF8gICAgIFZNTSAgMHgwMDAwMDAwMCBfSFBfIDB4MDAwMDAw MDApCkFDUEk6IFNQQ1IgQCAweDB4MjZjMzgvMHgwMDUwICh2ICAyICAgX0hQXyAgICAgVk1NICAw eDAwMDAwMDAwIF9IUF8gMHgwMDAwMDAwMCkKQUNQSTogU1BNSSBAIDB4MHgyNmM4OC8weDAwNDAg KHYgIDIgICBfSFBfICAgICBWTU0gIDB4MDAwMDAwMDAgX0hQXyAweDAwMDAwMDAwKQpBQ1BJOiBD UEVQIEAgMHgweDI2Y2M4LzB4MDAzNCAodiAgMSAgIF9IUF8gICAgIFZNTSAgMHgwMDAwMDAwMCBf SFBfIDB4MDAwMDAwMDApCmFjcGkwOiA8X0hQXz4gb24gbW90aGVyYm9hcmQKYWNwaTA6IFtNUFNB RkVdCmFjcGkwOiBbSVRIUkVBRF0KYWNwaTA6IFBvd2VyIEJ1dHRvbiAoZml4ZWQpCnVua25vd246 IEkvTyByYW5nZSBub3Qgc3VwcG9ydGVkCkFDUEkgdGltZXI6IDAvNTIgMC8xNDQgMC8xNjIgMC83 NSAwLzc3IDAvMTk2IDAvNDAgMC84MSAwLzk4IDAvMTMxIC0+IDAKVGltZWNvdW50ZXIgIkFDUEkt c2FmZSIgZnJlcXVlbmN5IDM1Nzk1NDUgSHogcXVhbGl0eSA4NTAKYWNwaV90aW1lcjA6IDwzMi1i aXQgdGltZXIgYXQgMy41Nzk1NDVNSHo+IHBvcnQgMHhhMDgtMHhhMGIgb24gYWNwaTAKcGNpYjA6 IDxBQ1BJIEhvc3QtUENJIGJyaWRnZT4gb24gYWNwaTAKcGNpMDogPEFDUEkgUENJIGJ1cz4gb24g cGNpYjAKcGNpMDogZG9tYWluPTAsIHBoeXNpY2FsIGJ1cz0wCmZvdW5kLT4JdmVuZG9yPTB4MTAw MCwgZGV2PTB4MDAzMCwgcmV2aWQ9MHgwNwoJZG9tYWluPTAsIGJ1cz0wLCBzbG90PTAsIGZ1bmM9 MAoJY2xhc3M9MDEtMDAtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MAoJY21kcmVnPTB4MDAwNywg c3RhdHJlZz0weDAyMjAsIGNhY2hlbG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0weDQwICgxOTIw IG5zKSwgbWluZ250PTB4MTAgKDQwMDAgbnMpLCBtYXhsYXQ9MHgwNiAoMTUwMCBucykKCWludHBp bj1hLCBpcnE9MAoJbWFwWzEwXTogdHlwZSBJL08gUG9ydCwgcmFuZ2UgMzIsIGJhc2UgMHg4MDAw LCBzaXplICA4LCBlbmFibGVkCgltYXBbMTRdOiB0eXBlIE1lbW9yeSwgcmFuZ2UgNjQsIGJhc2Ug MHhhMDAwMDAwMCwgc2l6ZSAxMCwgZW5hYmxlZAoJbWFwWzFjXTogdHlwZSBNZW1vcnksIHJhbmdl IDY0LCBiYXNlIDB4YTAwMTAwMDAsIHNpemUgMTYsIGVuYWJsZWQKcGNpYjA6IG1hdGNoZWQgZW50 cnkgZm9yIDAuMC5JTlRBCnBjaWIwOiBzbG90IDAgSU5UQSBoYXJkd2lyZWQgdG8gSVJRIDE2CmZv dW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4MTAwZSwgcmV2aWQ9MHgwMAoJZG9tYWluPTAsIGJ1 cz0wLCBzbG90PTEsIGZ1bmM9MAoJY2xhc3M9MDItMDAtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9 MAoJY21kcmVnPTB4MDAwNiwgc3RhdHJlZz0weDAyMjAsIGNhY2hlbG5zej0wIChkd29yZHMpCgls YXR0aW1lcj0weDIwICg5NjAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weGZmICg2 Mzc1MCBucykKCWludHBpbj1hLCBpcnE9MAoJbWFwWzEwXTogdHlwZSBNZW1vcnksIHJhbmdlIDY0 LCBiYXNlIDB4YTAwMjAwMDAsIHNpemUgMTcsIGVuYWJsZWQKCW1hcFsxOF06IHR5cGUgTWVtb3J5 LCByYW5nZSA2NCwgYmFzZSAweGEwMDQwMDAwLCBzaXplIDE2LCBlbmFibGVkCgltYXBbMjBdOiB0 eXBlIEkvTyBQb3J0LCByYW5nZSAzMiwgYmFzZSAweDgxMDAsIHNpemUgIDMsIHBvcnQgZGlzYWJs ZWQKcGNpYjA6IG1hdGNoZWQgZW50cnkgZm9yIDAuMS5JTlRBCnBjaWIwOiBzbG90IDEgSU5UQSBo YXJkd2lyZWQgdG8gSVJRIDE3CmZvdW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4NzYwMCwgcmV2 aWQ9MHgwMQoJZG9tYWluPTAsIGJ1cz0wLCBzbG90PTMsIGZ1bmM9MAoJY2xhc3M9MDYtMDEtMDAs IGhkcnR5cGU9MHgwMCwgbWZkZXY9MQoJY21kcmVnPTB4MDAwZiwgc3RhdHJlZz0weDAyODAsIGNh Y2hlbG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAg bnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCW1hcFsxMF06IHR5cGUgSS9PIFBvcnQsIHJhbmdlIDMy LCBiYXNlIDAsIHNpemUgIDIsIGVuYWJsZWQKCW1hcFsxNF06IHR5cGUgTWVtb3J5LCByYW5nZSAz MiwgYmFzZSAwLCBzaXplIDEyLCBlbmFibGVkCm1wdDA6IDxMU0lMb2dpYyAxMDMwIFVsdHJhNCBB ZGFwdGVyPiBwb3J0IDB4ODAwMC0weDgwZmYgbWVtIDB4YTAwMDAwMDAtMHhhMDAwMDNmZiwweGEw MDEwMDAwLTB4YTAwMWZmZmYgaXJxIDE2IGF0IGRldmljZSAwLjAgb24gcGNpMAptcHQwOiBSZXNl cnZlZCAweDEwMCBieXRlcyBmb3IgcmlkIDB4MTAgdHlwZSA0IGF0IDB4ODAwMAptcHQwOiBSZXNl cnZlZCAweDQwMCBieXRlcyBmb3IgcmlkIDB4MTQgdHlwZSAzIGF0IDB4YTAwMDAwMDAKbXB0MDog W01QU0FGRV0KbXB0MDogW0lUSFJFQURdCm1wdDA6IE1QSSBWZXJzaW9uPTEuMi4wLjAKbXB0MDog Tm8gSGFuZGxlcnMgRm9yIEFueSBFdmVudCBOb3RpZnkgRnJhbWVzLiBFdmVudCAweGEgKEFDSyBu b3QgcmVxdWlyZWQpLgptcHQwOiBObyBIYW5kbGVycyBGb3IgQW55IEV2ZW50IE5vdGlmeSBGcmFt ZXMuIEV2ZW50IDB4YSAoQUNLIG5vdCByZXF1aXJlZCkuCmVtMDogPEludGVsKFIpIFBSTy8xMDAw IE5ldHdvcmsgQ29ubmVjdGlvbiA2LjkuNj4gcG9ydCAweDgxMDAtMHg4MTA3IG1lbSAweGEwMDIw MDAwLTB4YTAwM2ZmZmYsMHhhMDA0MDAwMC0weGEwMDRmZmZmIGlycSAxNyBhdCBkZXZpY2UgMS4w IG9uIHBjaTAKZW0wOiBSZXNlcnZlZCAweDIwMDAwIGJ5dGVzIGZvciByaWQgMHgxMCB0eXBlIDMg YXQgMHhhMDAyMDAwMAplbTA6IGZhaWxlZCB0byBlbmFibGUgcG9ydCBtYXBwaW5nIQplbTA6IFVu YWJsZSB0byBhbGxvY2F0ZSBidXMgcmVzb3VyY2U6IGlvcG9ydAplbTA6IEFsbG9jYXRpb24gb2Yg UENJIHJlc291cmNlcyBmYWlsZWQKZGV2aWNlX2F0dGFjaDogZW0wIGF0dGFjaCByZXR1cm5lZCA2 CnBjaTA6IDxicmlkZ2UsIFBDSS1JU0E+IGF0IGRldmljZSAzLjAgKG5vIGRyaXZlciBhdHRhY2hl ZCkKcGNpYjE6IDxBQ1BJIEhvc3QtUENJIGJyaWRnZT4gb24gYWNwaTAKcGNpMTogPEFDUEkgUENJ IGJ1cz4gb24gcGNpYjEKcGNpMTogZG9tYWluPTAsIHBoeXNpY2FsIGJ1cz0xCnBjaWIyOiA8QUNQ SSBIb3N0LVBDSSBicmlkZ2U+IG9uIGFjcGkwCnBjaTI6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIy CnBjaTI6IGRvbWFpbj0wLCBwaHlzaWNhbCBidXM9MgpwY2liMzogPEFDUEkgSG9zdC1QQ0kgYnJp ZGdlPiBvbiBhY3BpMApwY2kzOiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liMwpwY2kzOiBkb21haW49 MCwgcGh5c2ljYWwgYnVzPTMKcGNpYjQ6IDxBQ1BJIEhvc3QtUENJIGJyaWRnZT4gb24gYWNwaTAK cGNpNDogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjQKcGNpNDogZG9tYWluPTAsIHBoeXNpY2FsIGJ1 cz00CnBjaWI1OiA8QUNQSSBIb3N0LVBDSSBicmlkZ2U+IG9uIGFjcGkwCnBjaTU6IDxBQ1BJIFBD SSBidXM+IG9uIHBjaWI1CnBjaTU6IGRvbWFpbj0wLCBwaHlzaWNhbCBidXM9NQpwY2liNjogPEFD UEkgSG9zdC1QQ0kgYnJpZGdlPiBvbiBhY3BpMApwY2k2OiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2li NgpwY2k2OiBkb21haW49MCwgcGh5c2ljYWwgYnVzPTYKcGNpYjc6IDxBQ1BJIEhvc3QtUENJIGJy aWRnZT4gb24gYWNwaTAKcGNpNzogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjcKcGNpNzogZG9tYWlu PTAsIHBoeXNpY2FsIGJ1cz03CmNwdTA6IDxBQ1BJIENQVT4gb24gYWNwaTAKY3B1MDogc3dpdGNo aW5nIHRvIGdlbmVyaWMgQ3ggbW9kZQpwcm9jZnMgcmVnaXN0ZXJlZApUaW1lY291bnRlcnMgdGlj ayBldmVyeSAxLjAwMCBtc2VjCmxvMDogYnBmIGF0dGFjaGVkCldhaXRpbmcgNSBzZWNvbmRzIGZv ciBTQ1NJIGRldmljZXMgdG8gc2V0dGxlCih4cHQwOm1wdDA6MDotMTotMSk6IHJlc2V0IGJ1cwoK ZmF0YWwga2VybmVsIHRyYXAgKGNwdSAwKToKCiAgICB0cmFwIHZlY3RvciA9IDB4MTQgKFBhZ2Ug Tm90IFByZXNlbnQpCiAgICBjci5paXAgICAgICA9IDB4ZTAwMDAwMDAwNGExZGJhMAogICAgY3Iu aXBzciAgICAgPSAweDEwMTAwODBhMjAxMCAobWZsLGljLGR0LGRmaCxydCxjcGw9MCxpdCxyaT0w LGJuKQogICAgY3IuaXNyICAgICAgPSAweDgwNDAwMDAwMDAwIChjb2RlPTAsdmVjdG9yPTAscixl aT0wLGVkKQogICAgY3IuaWZhICAgICAgPSAweDEKICAgIGN1cnRocmVhZCAgID0gMHhlMDAwMDAw MDA0YzFmYTQwCiAgICAgICAgcGlkID0gMCwgY29tbSA9IHN3YXBwZXIKClt0aHJlYWQgcGlkIDAg dGlkIDAgXQpTdG9wcGVkIGF0ICAgICAgcG1hcF9zd2l0Y2grMHgxMjA6ICAgICAgW00wXSAgICBs ZDQgcjE0PVtyMTddLDB4NApkYj4gdHJhY2UgIApUcmFjaW5nIHBpZCAwIHRpZCAwIHRkIDB4ZTAw MDAwMDAwNGMxZmE0MApwbWFwX3N3aXRjaCgweGUwMDAwMDAwMDRjMWZlOTAsIDB4ZTAwMDAwMDAw NGM0M2NiOCkgYXQgcG1hcF9zd2l0Y2grMHgxMjAKY3B1X3N3aXRjaCgweGEwMDAwMDAwMzA1Nzk3 ODAsIDB4ZTAwMDAwMDAxMDQzOGFiMCwgMHhlMDAwMDAwMDA0YjZiNzgwLCAweGUwMDAwMDAwMDQ1 ZDkzZDAsIDB4NDAwMDAwMDAwMDAwMDQ4ZSkgYXQgY3B1X3N3aXRjaCsweGIwCnNjaGVkX3N3aXRj aCgweGUwMDAwMDAwMDRjMWZhNDAsIDB4ZTAwMDAwMDAxMDQzOGFiMCwgMHgxKSBhdCBzY2hlZF9z d2l0Y2grMHgzZDAKbWlfc3dpdGNoKDB4MSwgMHgwLCAweGUwMDAwMDAwMDRjMWZhNDApIGF0IG1p X3N3aXRjaCsweDMwMApzbGVlcHFfc3dpdGNoKDB4ZTAwMDAwMDAwNGJiNjJhOCwgMHhlMDAwMDAw MDA0YzFmYTQwLCAweGUwMDAwMDAwMDRjMmRkYTAsIDB4ZTAwMDAwMDAwNDVmZjg5MCkgYXQgc2xl ZXBxX3N3aXRjaCsweDIzMApzbGVlcHFfdGltZWR3YWl0KDB4ZTAwMDAwMDAwNGJiNjJhOCwgMHhl MDAwMDAwMDA0YzFmYTQwLCAweGUwMDAwMDAwMDQ1YTMxZjAsIDB4NDAwMDAwMDAwMDAwMDgxNSwg MHhlMDAwMDAwMDA0YzFmYTQwKSBhdCBzbGVlcHFfdGltZWR3YWl0KzB4NjAKX3NsZWVwKDB4ZTAw MDAwMDAwNGJiNjJhOCwgMHhlMDAwMDAwMDA0YzJiNDEwLCAweDYwLCAweGUwMDAwMDAwMDRhOTA5 MDAsIDB4MSkgYXQgX3NsZWVwKzB4NWYwCnJ1bl9pbnRlcnJ1cHRfZHJpdmVuX2NvbmZpZ19ob29r cygweGUwMDAwMDAwMDRjMmI0MzAsIDB4ZTAwMDAwMDAwNGMyYjQzMCkgYXQgcnVuX2ludGVycnVw dF9kcml2ZW5fY29uZmlnX2hvb2tzKzB4MjYwCm1pX3N0YXJ0dXAoMHhlMDAwMDAwMDA0YmRlMTYw LCAweGUwMDAwMDAwMDRiZmY4MjgsIDB4ZTAwMDAwMDAwNGJmZjgzMCwgMHhlMDAwMDAwMDA0YmZm ODIwLCAweGUwMDAwMDAwMDRiZmY4MzgsIDB4ZTAwMDAwMDAwNGJkY2M5OCwgMHhlMDAwMDAwMDA0 YmIwMjU4LCAweGUwMDAwMDAwMDRhMTU5ZTApIGF0IG1pX3N0YXJ0dXArMHgyNjAKaWE2NF9pbml0 KDB4ZTAwMDAwMDAwNGMxZmM5MCkgYXQgaWE2NF9pbml0KzB4ZWMwCl9fc3RhcnQoKSBhdCBfX3N0 YXJ0KzB4YTAKZGI+IHNob3cgcmVnICAKaXAgICAgICAgICAgMHhlMDAwMDAwMDA0YTFkYmEwICBw bWFwX3N3aXRjaCsweDEyMApjci5pZnMgICAgICAweDgwMDAwMDAwMDAwMDAzMDYKY3IuaWZhICAg ICAgICAgICAgIDB4MQphci5ic3BzdG9yZSAweGUwMDAwMDAwMDRiNjQyNzggIGtzdGFjaysweDI3 OApuZGlydHkgICAgICAgICAgICAweDYwCnJwICAgICAgICAgIDB4ZTAwMDAwMDAwNGExZGFhMCAg cG1hcF9zd2l0Y2grMHgyMAphci5wZnMgICAgICAweDQwMDAwMDAwMDAwMDAzMDYKcHNyICAgICAg ICAgMHgxMDEwMDgwYTIwMTAKY3IuaXNyICAgICAgMHg4MDQwMDAwMDAwMApwciAgICAgICAgICAg ICAweDI5YTQxCmFyLnJzYyAgICAgICAgICAgICAweDcKYXIucm5hdCAgICAgICAgICAgICAgMAph ci51bmF0ICAgICAgICAgICAgICAwCmFyLmZwc3IgICAgIDB4OTgwNGM4YTcwMDMzZgpncCAgICAg ICAgICAweGUwMDAwMDAwMDRkZGY5ZjAgIF9fZ3AKc3AgICAgICAgICAgMHhlMDAwMDAwMDA0YjZi NDkwICBrc3RhY2srMHg3NDkwCnRwICAgICAgICAgIDB4ZTAwMDAwMDAwNGM0MzEzMCAgcGNwdTAK YjYgICAgICAgICAgMHhlMDAwMDAwMDA0MTU1MjgwICBhY3BpX3RpbWVyX2dldF90aW1lY291bnRf c2FmZQpiNyAgICAgICAgICAgIDB4NDQ0YjAwCnIyICAgICAgICAgICAgICAgICAgIDAKLS1Nb3Jl LS0NICAgICAgICANcjMgICAgICAgICAgIDB4ZDU0MDAwMApyOCAgICAgICAgICAgICAgICAgICAw CnI5ICAgICAgICAgICAgICAgIDB4ZmYKcjEwICAgICAgICAgICAgICAgICAgMApyMTEgICAgICAg ICAgICAgICAgICAwCnIxNCAgICAgICAgICAgICAgMHg4MzUgIGludHJfbisweDczNQpyMTUgICAg ICAgICAweDIwMDAwMDAwMDAwMDAwMDAKcjE2ICAgICAgICAgICAgICAgIDB4MQpyMTcgICAgICAg ICAgICAgICAgMHgxCnIxOCAgICAgICAgICAgIDB4MjlhNDEKcjE5ICAgICAgICAgICAgICAgICAg MApyMjAgICAgICAgICAweGUwMDAwMDAwMDRjMWZjYzAgIHRocmVhZDArMHgyODAKcjIxICAgICAg ICAgMHhlMDAwMDAwMDEwNTI0ODA4CnIyMiAgICAgICAgICAgICAgICAgIDAKcjIzICAgICAgICAg ICAgICAgICAgMApyMjQgICAgICAgICAgICAgICAgICAwCnIyNSAgICAgICAgICAgICAgICAgIDAK cjI2ICAgICAgICAgICAgICAgIDB4MQpyMjcgICAgICAgICAgICAgICAgICAwCnIyOCAgICAgICAg ICAgICAgICAgIDAKLS1Nb3JlLS0NICAgICAgICANcjI5ICAgICAgICAgMHhlMDAwMDAwMDA0YzE4 YTE0ICByYW5kb21fc3RhdGUrMHgxNmMKcjMwICAgICAgICAgMHhlMDAwMDAwMDA0YjZiODEwICBr c3RhY2srMHg3ODEwCnIzMSAgICAgICAgIDB4ZTAwMDAwMDAwNGI2YjlhMCAga3N0YWNrKzB4Nzlh MApwbWFwX3N3aXRjaCsweDEyMDogICAgICBbTTBdICAgIGxkNCByMTQ9W3IxN10sMHg0CmRiPiAg IAoKICAgdk1QIE1BSU4gTUVOVQoKICAgICAgICAgQ086IENvbnNvbGUKICAgICAgICAgQ006IENv bW1hbmQgTWVudQogICAgICAgICBDTDogQ29uc29sZSBMb2cKICAgICAgICAgU0w6IFNob3cgRXZl bnQgTG9ncwogICAgICAgICBWTTogVmlydHVhbCBNYWNoaW5lIE1lbnUKICAgICAgICAgSEU6IE1h aW4gSGVscCBNZW51CiAgICAgICAgICBYOiBFeGl0IENvbm5lY3Rpb24KCltidWQtc2FhYmldIHZN UD4geAojIAoKc2NyaXB0IGRvbmUgb24gV2VkIE1heSAgNiAxNDo0MzowMyAyMDA5Cg== --MP_/4DwaaI7uYI8yALurU_OsGzu-- From owner-freebsd-stable@FreeBSD.ORG Wed May 6 15:23:30 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0B94C1065674 for ; Wed, 6 May 2009 15:23:30 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) by mx1.freebsd.org (Postfix) with ESMTP id BE9EE8FC22 for ; Wed, 6 May 2009 15:23:29 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from localhost (localhost.codelab.cz [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id A844319E044; Wed, 6 May 2009 17:23:27 +0200 (CEST) Received: from [192.168.1.2] (r5bb235.net.upc.cz [86.49.61.235]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 52AF019E043; Wed, 6 May 2009 17:23:25 +0200 (CEST) Message-ID: <4A01AB6D.2080304@quip.cz> Date: Wed, 06 May 2009 17:23:25 +0200 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: cz, cs, en, en-us MIME-Version: 1.0 To: Steve Bertrand References: <4A00D1C5.2010806@ibctech.ca> In-Reply-To: <4A00D1C5.2010806@ibctech.ca> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Subject: Re: Jails and IPv6 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 15:23:30 -0000 Steve Bertrand wrote: > Hi all, > > I've been using VMWare on Linux for quite some time, but I am fed up to > the gills with the hassles I have to go through every time the box needs > to be rebooted. I don't want to start a flame war, so let's just say > that I'm already convinced of migrating to a solution that I don't need > a Linux host for. > > I need to be able to run multiple instances of FreeBSD on a single box, > but I *need* IPv6 to work on the virtual machines. > > I've read that this is now possible under 7.2. Is this really true? > > What I'm looking to do, is set up a new host as IPv6 only. I don't want > to use dedicated hardware if I don't have to, so I'm asking about jails > first. > > Operationally, are there any success stories regarding v6 and jails that > anyone could share? I am not using IPv6, but it works. The freebsd-jail@ mailinglist is better place to ask. http://lists.freebsd.org/pipermail/freebsd-jail/2009-January/000702.html http://lists.freebsd.org/pipermail/freebsd-jail/2008-December/000631.html Miroslav Lachman From owner-freebsd-stable@FreeBSD.ORG Wed May 6 16:00:07 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8E84B1065674 for ; Wed, 6 May 2009 16:00:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [195.88.108.3]) by mx1.freebsd.org (Postfix) with ESMTP id 405088FC1B for ; Wed, 6 May 2009 16:00:06 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 1FF5C41C75E; Wed, 6 May 2009 18:00:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([195.88.108.3]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id nhGAIDztcZW1; Wed, 6 May 2009 18:00:05 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id A059641C75A; Wed, 6 May 2009 18:00:05 +0200 (CEST) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 501B54448EC; Wed, 6 May 2009 15:58:32 +0000 (UTC) Date: Wed, 6 May 2009 15:58:32 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Steve Bertrand In-Reply-To: <4A00D1C5.2010806@ibctech.ca> Message-ID: <20090506155341.R72053@maildrop.int.zabbadoz.net> References: <4A00D1C5.2010806@ibctech.ca> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD Subject: Re: Jails and IPv6 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 16:00:07 -0000 On Tue, 5 May 2009, Steve Bertrand wrote: Hi, > I've been using VMWare on Linux for quite some time, but I am fed up to > the gills with the hassles I have to go through every time the box needs > to be rebooted. I don't want to start a flame war, so let's just say > that I'm already convinced of migrating to a solution that I don't need > a Linux host for. > > I need to be able to run multiple instances of FreeBSD on a single box, > but I *need* IPv6 to work on the virtual machines. > > I've read that this is now possible under 7.2. Is this really true? yes. > What I'm looking to do, is set up a new host as IPv6 only. I don't want > to use dedicated hardware if I don't have to, so I'm asking about jails > first. > > Operationally, are there any success stories regarding v6 and jails that > anyone could share? Apart from that a FreeBSD Cluster system has been using it since the beta time of the patch w/o a crash, a few people on freebsd-jail@ who had been using it. /bz -- Bjoern A. Zeeb The greatest risk is not taking one. From owner-freebsd-stable@FreeBSD.ORG Wed May 6 16:22:27 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9688E1065698; Wed, 6 May 2009 16:22:27 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout022.mac.com (asmtpout022.mac.com [17.148.16.97]) by mx1.freebsd.org (Postfix) with ESMTP id 8094F8FC31; Wed, 6 May 2009 16:22:27 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Received: from ajain-mbp.jnpr.net (natint3.juniper.net [66.129.224.36]) by asmtp022.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KJ8008C9DHAXB70@asmtp022.mac.com>; Wed, 06 May 2009 09:22:22 -0700 (PDT) Message-id: From: Marcel Moolenaar To: =?ISO-8859-2?Q?Zahemszky_G=E1bor?= In-reply-to: <20090506163043.0aad883b@Picasso.Zahemszky.HU> Content-transfer-encoding: quoted-printable Date: Wed, 06 May 2009 09:22:21 -0700 References: <20090429063852.26767.qmail@mail.integrity.hu> <20090506163043.0aad883b@Picasso.Zahemszky.HU> X-Mailer: Apple Mail (2.930.3) Cc: freebsd-stable@freebsd.org, ia64@freebsd.org Subject: Re: IA64 7.2-RC2 in HP Integrity Virtual Machine X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 16:22:28 -0000 On May 6, 2009, at 7:30 AM, Zahemszky G=E1bor wrote: >> I believe there's a problem with mpt(4) that relates to >> its error recovery, or lack thereof. >> >> Can you send a backtrace so that we can confirm or de- >> bunk that statement? > > Hi! > > here it is. (sorry for the ESC-sequences, it is the virtual machine's > EFI boot loader) > > Attached. Ok. It's not mpt(4). It looks like it's the VM itself that's the problem. The page fault is the result of a clobbered r17. Looking at the registers and the source code, as well as the assembly I conclude that writes to the region registers (which are virtualized) cause a trap in the VM and the context is not properly saved or restored. I conclude this based on r16 being 1 (we've had 1 iteration of the loop on line 2220 in file sys/ia64/ia64/pmap.c (assuming r16 is not clobbered). This means we had at least 1 write to the region register. r17 is initialized to (&pm->pm_rid[0]) and since the load has a post-increment of 4, it "walks" the pm_rid array. It never has a value of 1. So, r17 must have been clobbered, because it's never assigned 1 in the program. So either the VM is buggy, or you need explicit support for the VM in the guest OS by design. FYI, --=20 Marcel Moolenaar xcllnt@mac.com From owner-freebsd-stable@FreeBSD.ORG Wed May 6 16:45:02 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2C2141065687 for ; Wed, 6 May 2009 16:45:02 +0000 (UTC) (envelope-from torfinn.ingolfsen@broadpark.no) Received: from osl1smout1.broadpark.no (osl1smout1.broadpark.no [80.202.4.58]) by mx1.freebsd.org (Postfix) with ESMTP id DB7828FC41 for ; Wed, 6 May 2009 16:45:01 +0000 (UTC) (envelope-from torfinn.ingolfsen@broadpark.no) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII Received: from osl1sminn1.broadpark.no ([80.202.4.59]) by osl1smout1.broadpark.no (Sun Java(tm) System Messaging Server 6.3-3.01 (built Jul 12 2007; 32bit)) with ESMTP id <0KJ800F35EJ03D80@osl1smout1.broadpark.no> for freebsd-stable@freebsd.org; Wed, 06 May 2009 18:45:00 +0200 (CEST) Received: from kg-v2.kg4.no ([80.202.83.38]) by osl1sminn1.broadpark.no (Sun Java(tm) System Messaging Server 6.3-3.01 (built Jul 12 2007; 32bit)) with SMTP id <0KJ8002GSEJ0O8E0@osl1sminn1.broadpark.no> for freebsd-stable@freebsd.org; Wed, 06 May 2009 18:45:00 +0200 (CEST) Date: Wed, 06 May 2009 18:45:00 +0200 From: Torfinn Ingolfsen To: freebsd-stable@freebsd.org Message-id: <20090506184500.70b2c6f2.torfinn.ingolfsen@broadpark.no> In-reply-to: <4A00AF76.8010604@FreeBSD.org> References: <20090504225012.392fa49f.torfinn.ingolfsen@broadpark.no> <4A00AF76.8010604@FreeBSD.org> X-Mailer: Sylpheed 2.6.0 (GTK+ 2.16.1; amd64-portbld-freebsd7.2) X-Face: "t9w2,-X@O^I`jVW\sonI3.,36KBLZE*AL[y9lL[PyFD*r_S:dIL9c[8Y>V42R0"!"yb_zN,f#%.[PYYNq; m"_0v; ~rUM2Yy!zmkh)3&U|u!=T(zyv,MHJv"nDH>OJ`t(@mil461d_B'Uo|'nMwlKe0Mv=kvV?Nh@>Hb<3s_z2jYgZhPb@?Wi^x1a~Hplz1.zH Subject: Re: RELENG_7 - has mergemaster changed logic since 7.2-RELEASE? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 16:45:05 -0000 On Tue, 05 May 2009 14:28:22 -0700 Doug Barton wrote: > I've read this thread and find the whole thing very odd. In particular I agree - it is odd. I have a few more machines to upgrade in the coming weeks - if anyone have a better testcase to find out what is going on, I'm ready for it. > That shouldn't even be possible. You have to affirmatively choose 'i' > (for install) for it to be installed at all, the default is to leave > it in the temproot directory. Additionally, the code to handle > deleting is some of the oldest code in the script, and hasn't changed > in over 8 years. Well, something has changed in the way mergemaster handles this, unless there is something else in the make world procedure that updates files in /etc? To be clear, I follow this procedure: 1. make buildworld 2. make kernel 3. shutdown now 4. mergemaster -p 5. make installworld 6. mergemaster -iU 7. fastboot > I saw your followup message, can you please do me a favor and modify > your /etc/motd file again, then run the following in a script(1) and > send me the log? /bin/sh -x mergemaster -iU Done - sent in personal mail. HTH -- Regards, Torfinn Ingolfsen From owner-freebsd-stable@FreeBSD.ORG Wed May 6 16:52:11 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 34BE2106566C for ; Wed, 6 May 2009 16:52:11 +0000 (UTC) (envelope-from paul@paulstewart.org) Received: from smtp.nexicom.net (mail-incoming.nexicom.net [216.168.96.29]) by mx1.freebsd.org (Postfix) with ESMTP id DF0FB8FC19 for ; Wed, 6 May 2009 16:52:10 +0000 (UTC) (envelope-from paul@paulstewart.org) Received: from smtp.nexicom.net (smtp.nexicom.net [216.168.96.13]) by smtp.nexicom.net (8.13.6/8.13.4) with ESMTP id n46GN1aw022005 for ; Wed, 6 May 2009 12:23:20 -0400 Received: from pstewart ([216.168.115.179] helo=pstewart) with IPv4:25 by smtp.nexicom.net; 6 May 2009 12:23:01 -0400 Received: from pstewart by pstewart (PGP Universal service); Wed, 06 May 2009 12:23:20 -0500 X-PGP-Universal: processed; by pstewart on Wed, 06 May 2009 12:23:20 -0500 From: "Paul Stewart" To: Date: Wed, 6 May 2009 12:23:01 -0400 Message-ID: <000001c9ce66$ed588fc0$c809af40$@org> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnOZurzPkUvky1rRCmn0GMt5UUSCg== Content-Language: en-us Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Keeping Updated X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 16:52:11 -0000 Hi there. I'm sorry if this seems like a basic question but slowly drifting back to the FreeBSD world after 10 years away in the Linux world ;) After some consideration, I believe I still like the idea of source based updating versus binary. This raises my first question - getting updating source. Where do I obtain it from and how do I know when it's updated? I presume only during major updates/upgrades and/or security issues is when the source tree ever changes? I understand (or believe I do) on the whole "make buildworld", "make installworld", "mergemaster -v" steps unless anything has changed in 7.2-RELEASE that I need to know about. I also remember how to build my own kernels and see that you can now do "make buildkernel KERNCONF=NEWKERNEL" and "make installkernel KERNCONF=NEWKERNEL" which is nice too. With that aside, I've been running "portsnap update" to keep the ports updated.. am I missing anything here? I presume that when portsnap finds an updated port then I just need to rebuild it and upgrade? I guess I'm kinda wondering the "condensed quick version" of what people are typically doing to keep their system updated from source without making life difficult ;) Yes, I've been reading through various things to get myself updated to newer info but there's also a lot of stuff on the Internet based on older info hence why I'm asking. Cheers, Paul From owner-freebsd-stable@FreeBSD.ORG Wed May 6 17:31:22 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F0BCC1065675 for ; Wed, 6 May 2009 17:31:22 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.30]) by mx1.freebsd.org (Postfix) with ESMTP id A5ADC8FC16 for ; Wed, 6 May 2009 17:31:22 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: by yx-out-2324.google.com with SMTP id 8so131463yxb.13 for ; Wed, 06 May 2009 10:31:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=1NpZQfK91f7ZWE+fiLDAimymZP5m+x09+/W3/qXyg+I=; b=jzuyQoABzZMt7kihzh3eT4ML+JNK8DliBkCrb4nEong7iXfM+IkWfwurP2g+IzqguH ORfmkGDQLa/YZEO+VShod8UOeGVlceRh9p+t6A21OcukoQ0mmrSUWe5la2OBWH+I5JbQ DwfaJJYfY1lGyzQy2BRN0HRSr6d+AVAdVDmGw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=efTs7Y4yMIIcjBiovpYefaU9Jpi2+a3zGYNYBIgATIw5fI8XZa42caRxDSnpGev5h6 IWgZKuNpB9y6f6ys8V+14CADcgDmxKrPnCMnVd1tJKMRyjyS9dvGHRbABLk5Ax4LGtN9 ecypHLjrd391p/7XY3MRPTsH0mVkjl5l7ZJmo= MIME-Version: 1.0 Received: by 10.151.125.8 with SMTP id c8mr2685631ybn.202.1241631082138; Wed, 06 May 2009 10:31:22 -0700 (PDT) In-Reply-To: <000001c9ce66$ed588fc0$c809af40$@org> References: <000001c9ce66$ed588fc0$c809af40$@org> Date: Wed, 6 May 2009 10:31:22 -0700 Message-ID: From: Freddie Cash To: Paul Stewart Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org Subject: Re: Keeping Updated X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 17:31:23 -0000 On Wed, May 6, 2009 at 9:23 AM, Paul Stewart wrote: > I guess I'm kinda wondering the "condensed quick version" of what people = are > typically doing to keep their system updated from source without making l= ife > difficult ;) =C2=A0Yes, I've been reading through various things to get m= yself > updated to newer info but there's also a lot of stuff on the Internet bas= ed > on older info hence why I'm asking. This is what I do. I don't claim that it's perfect, nor that it's the recommended way, but it works nicely, and provides some safety nets, just in case. For ports (requires the installation of portmaster and portaudit): # portsnap fetch update # portaudit -Fda > ~/ports-with-issues # pkg_version -vl '<' > ~/ports-with-updates # more /usr/ports/UPDATING If there's anything in ports-with-issues, then look if there's an update in ports-with-updates. If there's anything in ports-with-updates that *needs* to be updated (security fix, bug fix, major feature needed, etc), then update only those ports: # portmaster -bd [portname] For source: Subscribe to the freebsd security announcement mailing list. Copy /usr/share/examples/cvsup/stable-supfile to /etc/supfile.source Edit /etc/supfile.source to set tag=3D to RELENG_X_Y where X_Y is the version you want to upgrade to (7_2, for example). Then, whenever a security announcement is made: # csup /etc/supfile.source # cd /usr/src # make buildworld # make KERNCONF=3DWHATEVER buildkernel # make KERNCONF=3DWHATEVER KODIR=3D/boot/newkernel installkernel # nextboot -k newkernel # shutdown -r now # cd /usr/src # make installworld # mergemaster -iU # mv /boot/kernel /boot/kernel.bak # mv /boot/newkernel /boot/kernel # shutdown -r now Using KODIR and nextboot allows you a safety net. If the boot using /boot/newkernel fails, a simple reboot will bring it back up with /boot/kernel (the old, working kernel). --=20 Freddie Cash fjwcash@gmail.com From owner-freebsd-stable@FreeBSD.ORG Wed May 6 19:18:15 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 406DF1065670 for ; Wed, 6 May 2009 19:18:15 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id ED7188FC18 for ; Wed, 6 May 2009 19:18:14 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1M1mdB-0005tm-6P for freebsd-stable@freebsd.org; Wed, 06 May 2009 19:18:13 +0000 Received: from p4fe5e1e3.dip.t-dialin.net ([79.229.225.227]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 06 May 2009 19:18:13 +0000 Received: from jumper99 by p4fe5e1e3.dip.t-dialin.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 06 May 2009 19:18:13 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: "Helmut Schneider" Date: Wed, 6 May 2009 21:18:02 +0200 Lines: 18 Message-ID: References: <4A015725.3050603@ksu.ru> <4A01630A.5080201@ksu.ru> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=response Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: p4fe5e1e3.dip.t-dialin.net X-MSMail-Priority: Normal X-Newsreader: vi with a tiny GUI... X-MimeOLE: Huh, what?! Sender: news Subject: Re: [7.2] R/W mount of / denied. Filesystem not clean - run fsck. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 19:18:15 -0000 Marat N.Afanasyev wrote: > Helmut Schneider wrote: >> I do have such thing (IBM Blade Center) but I'm looking for something to >> avoid the situation above. Something that lets me at least boot into >> single user mode. >> > > if you have an ip-kvm you can drop into single-user and fsck any disk you > have. all you need to do is to choose 'single user' from beastie-menu. or > start kernel with -s parameter I *do* now how to enter single user mode but the kernel panic'ed *before* the shell started. :) -- No Swen today, my love has gone away My mailbox stands for lorn, a symbol of the dawn From owner-freebsd-stable@FreeBSD.ORG Wed May 6 19:57:48 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4D3C71065672 for ; Wed, 6 May 2009 19:57:48 +0000 (UTC) (envelope-from djv@iki.fi) Received: from kirsi2.inet.fi (mta-out.inet.fi [195.156.147.13]) by mx1.freebsd.org (Postfix) with ESMTP id D8C6F8FC13 for ; Wed, 6 May 2009 19:57:47 +0000 (UTC) (envelope-from djv@iki.fi) Received: from [192.168.1.5] (10.16.63.4) by kirsi2.inet.fi (8.5.014) id 49F6DD580056E9A3 for freebsd-stable@freebsd.org; Wed, 6 May 2009 22:46:50 +0300 Message-ID: <4A01E933.7070007@iki.fi> Date: Wed, 06 May 2009 22:46:59 +0300 From: Tuomo Latto User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.21) Gecko/20090302 Thunderbird/2.0.0.21 Mnenhy/0.7.6.666 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <000001c9ce66$ed588fc0$c809af40$@org> In-Reply-To: <000001c9ce66$ed588fc0$c809af40$@org> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Subject: Re: Keeping Updated X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 19:57:48 -0000 Paul Stewart wrote: > This raises my first question - getting updating source. Where do I obtain > it from and how do I know when it's updated? I presume only during major > updates/upgrades and/or security issues is when the source tree ever > changes? Umm... No. Or depends on what you mean. http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/current-stable.html#STABLE > I understand (or believe I do) on the whole "make buildworld", "make > installworld", "mergemaster -v" steps unless anything has changed in > 7.2-RELEASE that I need to know about. I also remember how to build my own > kernels and see that you can now do "make buildkernel KERNCONF=NEWKERNEL" > and "make installkernel KERNCONF=NEWKERNEL" which is nice too. http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/makeworld.html#CANONICAL-BUILD > I guess I'm kinda wondering the "condensed quick version" of what people are > typically doing to keep their system updated from source without making life > difficult ;) Yes, I've been reading through various things to get myself > updated to newer info but there's also a lot of stuff on the Internet based > on older info hence why I'm asking. I don't know if remember this, but the Handbook is pretty much always up-to-date and along with manual pages should be your first reference for anything. http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/index.html To be more specific, you seemed to be interested in these topics (but don't limit your reading to these): http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ports.html http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig.html http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/updating-upgrading.html -- Tuomo ... Google "how to hook up a hose to a kitchen sink" Did you mean: "how to hook up a /horse/ to a kitchen sink" >> I hope there was a non-return valve in the hose connection somewhere; >> horse-sh!t in your water supply is baaaaad. > No, horse-shit in your water is just disgusting. > Sheep-shit in your water is baaaaaaaaad! :-) Sheep puns are baaaaaaaaad. ;) -- on http://thedailywtf.com/Comments/ Yes,_That_0x27_s_Exactly_What_I_Meant.aspx From owner-freebsd-stable@FreeBSD.ORG Wed May 6 20:14:44 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8CA40106566B for ; Wed, 6 May 2009 20:14:44 +0000 (UTC) (envelope-from byshenknet@byshenk.net) Received: from core.byshenk.net (core.byshenk.net [62.58.73.230]) by mx1.freebsd.org (Postfix) with ESMTP id 24E8F8FC08 for ; Wed, 6 May 2009 20:14:43 +0000 (UTC) (envelope-from byshenknet@byshenk.net) Received: from core.byshenk.net (localhost.aoes.com [127.0.0.1]) by core.byshenk.net (8.14.3/8.14.3) with ESMTP id n46KEgtX048868; Wed, 6 May 2009 22:14:42 +0200 (CEST) (envelope-from byshenknet@core.byshenk.net) Received: (from byshenknet@localhost) by core.byshenk.net (8.14.3/8.14.3/Submit) id n46KEgEh048867; Wed, 6 May 2009 22:14:42 +0200 (CEST) (envelope-from byshenknet) Date: Wed, 6 May 2009 22:14:42 +0200 From: Greg Byshenk To: Helmut Schneider Message-ID: <20090506201442.GR1550@core.byshenk.net> References: <4A01630A.5080201@ksu.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on core.byshenk.net Cc: freebsd-stable@freebsd.org Subject: Re: [7.2] R/W mount of / denied. Filesystem not clean - run fsck. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 20:14:44 -0000 On Wed, May 06, 2009 at 09:18:02PM +0200, Helmut Schneider wrote: > Marat N.Afanasyev wrote: > >Helmut Schneider wrote: > >>I do have such thing (IBM Blade Center) but I'm looking for something to > >>avoid the situation above. Something that lets me at least boot into > >>single user mode. > >if you have an ip-kvm you can drop into single-user and fsck any disk you > >have. all you need to do is to choose 'single user' from beastie-menu. or > >start kernel with -s parameter > I *do* now how to enter single user mode but the kernel panic'ed *before* > the shell started. :) The problem is that, if something is so far wrong that you can't even get to the single-user shell, then there probably isn't anything else but rescue. One thing that might be an option: at work, we use PXE for Linux and FreeBSD installs, so one thing I've done is to create a pxeboot rescue image (using the mfsroot from the rescue CD). This means that, if there is this sort of problem, we can boot into rescue mode from the network (the BIOS is also redirected to the serial console) and not have to worry about swapping CDs. The same thing should also work for remote locations. -- greg byshenk - gbyshenk@byshenk.net - Leiden, NL From owner-freebsd-stable@FreeBSD.ORG Wed May 6 21:47:52 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 015731065673 for ; Wed, 6 May 2009 21:47:52 +0000 (UTC) (envelope-from amarat@ksu.ru) Received: from mx.kzn.ru (mx.kzn.ru [194.85.243.38]) by mx1.freebsd.org (Postfix) with ESMTP id F281F8FC1E for ; Wed, 6 May 2009 21:47:49 +0000 (UTC) (envelope-from amarat@ksu.ru) Authentication-Results: iout.kzn.ru; dkim=neutral (message not signed) header.i=none Received-SPF: None identity=pra; client-ip=193.232.252.56; receiver=iout.kzn.ru; envelope-from="amarat@ksu.ru"; x-sender="amarat@ksu.ru"; x-conformance=sidf_compatible Received-SPF: None identity=mailfrom; client-ip=193.232.252.56; receiver=iout.kzn.ru; envelope-from="amarat@ksu.ru"; x-sender="amarat@ksu.ru"; x-conformance=sidf_compatible Received-SPF: None identity=helo; client-ip=193.232.252.56; receiver=iout.kzn.ru; envelope-from="amarat@ksu.ru"; x-sender="postmaster@ruby.ksu.ru"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArUFAG+iAUrB6Pw4/2dsb2JhbACBUM9bgmyBFQU X-IronPort-AV: E=Sophos;i="4.40,304,1238961600"; d="p7s'?scan'208";a="3358049" Received: from mail.ksu.ru (HELO ruby.ksu.ru) ([193.232.252.56]) by iout.kzn.ru with ESMTP; 07 May 2009 01:47:48 +0400 X-Pass-Through: Kazan State University Network Received: from zealot.ksu.ru ([194.85.245.161]) by ksu.ru (8.13.4/8.13.4) with ESMTP id n46Kq3uh015719; Wed, 6 May 2009 20:52:03 GMT Received: from zealot.ksu.ru (localhost.lnet [127.0.0.1]) by zealot.ksu.ru (8.14.3/8.14.3) with ESMTP id n46LjL6N076833; Thu, 7 May 2009 01:45:22 +0400 (MSD) (envelope-from amarat@ksu.ru) Message-ID: <4A0204F1.1060700@ksu.ru> Date: Thu, 07 May 2009 01:45:21 +0400 From: "Marat N.Afanasyev" User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.8.1.19) Gecko/20090124 SeaMonkey/1.1.14 MIME-Version: 1.0 To: Helmut Schneider References: <4A015725.3050603@ksu.ru> <4A01630A.5080201@ksu.ru> In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040703030103030303090208" Cc: freebsd-stable@freebsd.org Subject: Re: [7.2] R/W mount of / denied. Filesystem not clean - run fsck. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 21:47:52 -0000 This is a cryptographically signed message in MIME format. --------------ms040703030103030303090208 Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Helmut Schneider wrote: > Marat N.Afanasyev wrote: >> Helmut Schneider wrote: >>> I do have such thing (IBM Blade Center) but I'm looking for something >>> to avoid the situation above. Something that lets me at least boot >>> into single user mode. >>> >> >> if you have an ip-kvm you can drop into single-user and fsck any disk >> you have. all you need to do is to choose 'single user' from >> beastie-menu. or start kernel with -s parameter > > I *do* now how to enter single user mode but the kernel panic'ed > *before* the shell started. :) > as far as I can guess from you other message panic occurs only after you see Trying to mount root from ufs:/dev/da0s1a WARNING: R/W mount of /home denied. Filesystem is not clean - run fsck GEOM_LABEL: Label for provider da0s2e is ufsid/49c3b0c4862f53b3. [lots more] Fatal trap 12: page fault while in kernel mode so, I can suppose you don't start in single-user mode, because in single-user init do not try to mount root at all, so you cannot see the messages above. if panics occur either in single or multiuser, then you can try livefs_cd/PXE -- SY, Marat --------------ms040703030103030303090208 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII8zCC AtQwggI9oAMCAQICEHpsMo6nkbUVegxjAzzxYCkwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDQwMTE5MTUxOFoX DTEwMDQwMTE5MTUxOFowPzEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEcMBoG CSqGSIb3DQEJARYNYW1hcmF0QGtzdS5ydTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALqa7MfgjbsxmgpTOKxAN7w+cFViFA8NrULAARwVQJQJCnVRGf3i97EwNdLE8VTNniU4 ybS4gtLsy9gfNuuyPV2AJESpgrxaG+KZyHu1f6P4e31YBbnbtWVTUxZ3U/vWoL+BOAOI4S84 Cx834a4uYK75WhpZKd56qet5loyn9N1wBZNgCh9AwU31lA/Q0iCSKpEIxuhbElNXHNnqAlts CtNXsKgsT8mP7QI52h0cBOPSZqvz++e/wruJGgKeCECqo8ftwwya3CYkH1lhH2Q1zeXwez1E 1+solM48odH+odn29ctmOqr3PzZfmBJyGFf5FagTKNia/ys48yBtVU/RXHsCAwEAAaMqMCgw GAYDVR0RBBEwD4ENYW1hcmF0QGtzdS5ydTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUA A4GBAG4Pj7KRSJ/M28KNynJOPCHg26L15S9OfQ+ckMaPPDRAejtdlUdCgkoyD9d1Du/amAk6 A3NcY2I/MsFW2vSonQfU+7cJZiyuhfw7wQlOovCx7USw1dmF6u3EljWZV+Kg4Vi3vN2dPyJx tv8li9McWQoMLmm5zzFGGRaSRnnrnZFsMIIC1DCCAj2gAwIBAgIQemwyjqeRtRV6DGMDPPFg KTANBgkqhkiG9w0BAQUFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElz c3VpbmcgQ0EwHhcNMDkwNDAxMTkxNTE4WhcNMTAwNDAxMTkxNTE4WjA/MR8wHQYDVQQDExZU aGF3dGUgRnJlZW1haWwgTWVtYmVyMRwwGgYJKoZIhvcNAQkBFg1hbWFyYXRAa3N1LnJ1MIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuprsx+CNuzGaClM4rEA3vD5wVWIUDw2t QsABHBVAlAkKdVEZ/eL3sTA10sTxVM2eJTjJtLiC0uzL2B8267I9XYAkRKmCvFob4pnIe7V/ o/h7fVgFudu1ZVNTFndT+9agv4E4A4jhLzgLHzfhri5grvlaGlkp3nqp63mWjKf03XAFk2AK H0DBTfWUD9DSIJIqkQjG6FsSU1cc2eoCW2wK01ewqCxPyY/tAjnaHRwE49Jmq/P757/Cu4ka Ap4IQKqjx+3DDJrcJiQfWWEfZDXN5fB7PUTX6yiUzjyh0f6h2fb1y2Y6qvc/Nl+YEnIYV/kV qBMo2Jr/KzjzIG1VT9FcewIDAQABoyowKDAYBgNVHREEETAPgQ1hbWFyYXRAa3N1LnJ1MAwG A1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEFBQADgYEAbg+PspFIn8zbwo3Kck48IeDbovXlL059 D5yQxo88NEB6O12VR0KCSjIP13UO79qYCToDc1xjYj8ywVba9KidB9T7twlmLK6F/DvBCU6i 8LHtRLDV2YXq7cSWNZlX4qDhWLe83Z0/InG2/yWL0xxZCgwuabnPMUYZFpJGeeudkWwwggM/ MIICqKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMM V2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25z dWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYD VQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNv bmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMwNzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5 WjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRk LjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwgZ8wDQYJ KoZIhvcNAQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5owHUEcJ3f6f+jHuy9zfVb8hp2 vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuvPAsH5/EfkTYkKhPPK9Xzgnc9 A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAeZBlyYLf7AgMBAAGjgZQwgZEw EgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0hjJodHRwOi8vY3JsLnRoYXd0 ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDALBgNVHQ8EBAMCAQYwKQYDVR0R BCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0GCSqGSIb3DQEBBQUAA4GB AEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYvwPQcUCCTcDz9reFhYsPZ Ohl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bGCE6u9uo05RAaWzVN d+NWIXiC3CEZNd4ksdMdRv9dX2VPMYIDZDCCA2ACAQEwdjBiMQswCQYDVQQGEwJaQTElMCMG A1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEHpsMo6nkbUVegxjAzzxYCkwCQYFKw4DAhoF AKCCAcMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkwNTA2 MjE0NTIxWjAjBgkqhkiG9w0BCQQxFgQUX/7XrADPebaTB0m5wZtl2CqiQwEwUgYJKoZIhvcN AQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYF Kw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhB6bDKOp5G1FXoMYwM88WApMIGHBgsq hkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAhB6bDKOp5G1FXoMYwM88WApMA0GCSqGSIb3DQEBAQUABIIBACY0ZlYqyYEM8L+I 6cBGUo8JXi0X53PHVT31cpWZDxv+rA7KKasBwfOCOQ6ThiTdBMDCL4f/cfjWxH0esxT4lB2r XVLNwxh8vVmoyh0dgaD5sGPjIkWuIazQTsSfjnDAWtrtc9Xx1eePfnTEZQd99nnE09jH7HHo O/YiU2g0iXazIWfUPiwXMWe8kewxpmsLOf80auyELfXPRQ4a8iq9q1S8eUUP69+YZDZu0fKH nnw4i1oP06P2tA9nVYG+qdbhYWviLms7MnZbdzj/kLAIRK0XDTGAQfPkopMdNV+53d3ftvq9 ssj2e8sKEgHJTjholNrnzmRIuu9DuK+Isnw+iLIAAAAAAAA= --------------ms040703030103030303090208-- From owner-freebsd-stable@FreeBSD.ORG Wed May 6 23:33:53 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A8B20106566B for ; Wed, 6 May 2009 23:33:53 +0000 (UTC) (envelope-from bc979@lafn.org) Received: from zoom.lafn.org (zoom.lafn.org [206.117.18.8]) by mx1.freebsd.org (Postfix) with ESMTP id 725658FC13 for ; Wed, 6 May 2009 23:33:53 +0000 (UTC) (envelope-from bc979@lafn.org) Received: from [10.0.1.4] (pool-71-109-162-173.lsanca.dsl-w.verizon.net [71.109.162.173]) (authenticated bits=0) by zoom.lafn.org (8.14.2/8.14.2) with ESMTP id n46NXqoE021293 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 6 May 2009 16:33:53 -0700 (PDT) (envelope-from bc979@lafn.org) Message-Id: <1BA7DBA9-3C49-490A-B97C-DEB08DF2F696@lafn.org> From: Doug Hardie To: freebsd-stable Stable Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 6 May 2009 16:33:52 -0700 X-Mailer: Apple Mail (2.930.3) X-Virus-Scanned: clamav-milter 0.95.1 at zoom.lafn.org X-Virus-Status: Clean Subject: Mergemaster X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 23:33:53 -0000 I have been following the discussion on mergemaster and one item is a bit annoying. You can use -U in the command args which sets "AUTO_UPGRADE=yes". That flag is not in mergemaster.rc. It could be easily added to the rc file, but I suspect it would conflict with -p. Hence it seems like if "unset AUTO_UPGRADE" were added to the -p section then it would work. It would be helpful to be able to include it in the rc file so I don't have to remember the options each time. From owner-freebsd-stable@FreeBSD.ORG Thu May 7 01:23:33 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B605B1065672 for ; Thu, 7 May 2009 01:23:33 +0000 (UTC) (envelope-from a.j.caines@halplant.com) Received: from eastrmpop109.cox.net (eastrmpop109.cox.net [68.230.240.51]) by mx1.freebsd.org (Postfix) with ESMTP id 48B878FC1F for ; Thu, 7 May 2009 01:23:33 +0000 (UTC) (envelope-from a.j.caines@halplant.com) Received: from eastrmimpo03.cox.net ([68.1.16.126]) by eastrmmtao101.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20090507005657.LOJY5257.eastrmmtao101.cox.net@eastrmimpo03.cox.net> for ; Wed, 6 May 2009 20:56:57 -0400 Received: from mail.halplant.com ([68.105.188.179]) by eastrmimpo03.cox.net with bizsmtp id oQww1b00J3sgWP002QwwLB; Wed, 06 May 2009 20:56:56 -0400 X-Authority-Analysis: v=1.0 c=1 a=Gt4o6GHaAAAA:8 a=l7W4BFllca6BpM6Ith8A:9 a=2l6WGuvHmo2yCXu_5MADo4S4ChUA:4 a=ZuKNhn6kRXAA:10 X-CM-Score: 0.00 Received: from hal10000.halplant.com (hal10000.halplant.com [192.168.0.3]) by mail.halplant.com (Postfix) with ESMTP id 4653D5191 for ; Wed, 6 May 2009 20:56:56 -0400 (EDT) Message-ID: <4A0231D7.1020206@halplant.com> Date: Wed, 06 May 2009 20:56:55 -0400 From: "Andrew J. Caines" Organization: H.A.L. Plant User-Agent: Thunderbird 2.0.0.21 (X11/20090411) MIME-Version: 1.0 CC: freebsd-stable@freebsd.org References: <000001c9ce66$ed588fc0$c809af40$@org> In-Reply-To: <000001c9ce66$ed588fc0$c809af40$@org> X-Enigmail-Version: 0.95.7 OpenPGP: id=67C318A1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: Keeping Updated X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2009 01:23:34 -0000 Paul, > I guess I'm kinda wondering the "condensed quick version" of what > people are typically doing to keep their system updated from source > without making life difficult ;) In addition to the reference already given, there is a concise description under "COMMON ITEMS" near the end of src/UPDATING, with header "To rebuild everything and install it on the current system". I note what might be a missed correction where it says "make kernel" as opposed to "make buildkernel". I do it the wrong way, which has always worked perfectly for me for many years using http://halplant.com:2001/software/FreeBSD/scripts/update_fbsd to fetch sources, build world and kernel while in multi-user, run from cron. When I'm ready to install, I shutdown and run http://halplant.com:2001/software/FreeBSD/scripts/install_fbsd This is wrong because I don't boot the new kernel before installing the new world. -- -Andrew J. Caines- Unix Systems Engineer A.J.Caines@halplant.com FreeBSD/Linux/Solaris, Web/Mail/Proxy/... http://halplant.com:2001/ "Machines take me by surprise with great frequency" - Alan Turing From owner-freebsd-stable@FreeBSD.ORG Thu May 7 07:56:03 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 99D2B1065678; Thu, 7 May 2009 07:56:03 +0000 (UTC) (envelope-from ma@dt.e-technik.tu-dortmund.de) Received: from unimail.uni-dortmund.de (mx1.HRZ.Uni-Dortmund.DE [129.217.128.51]) by mx1.freebsd.org (Postfix) with ESMTP id 1C7A48FC23; Thu, 7 May 2009 07:56:02 +0000 (UTC) (envelope-from ma@dt.e-technik.tu-dortmund.de) Received: from merlin.emma.line.org (g226231102.adsl.alicedsl.de [92.226.231.102]) (authenticated bits=0) by unimail.uni-dortmund.de (8.14.3/8.14.3) with ESMTP id n477eqPN016912 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 7 May 2009 09:41:06 +0200 (CEST) Date: Thu, 07 May 2009 09:40:52 +0200 To: "Daniel Gerzo" , "Manolis Kiagias" From: "Matthias Andree" Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8 MIME-Version: 1.0 References: <20090504225012.392fa49f.torfinn.ingolfsen@broadpark.no> <49FF5901.600@gmail.com> <49FFEECE.20403@FreeBSD.org> Content-Transfer-Encoding: 7bit Organization: Message-ID: In-Reply-To: <49FFEECE.20403@FreeBSD.org> User-Agent: Opera Mail/9.64 (Linux) Cc: Torfinn Ingolfsen , freebsd-stable@freebsd.org Subject: Re: RELENG_7 - has mergemaster changed logic since 7.2-RELEASE? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2009 07:56:03 -0000 Am 05.05.2009, 09:46 Uhr, schrieb Daniel Gerzo : > Manolis Kiagias wrote: > >> I always use -iU too. >> I've lost motd, passwd, group and master.passwd >> During mergemaster -p I was asked to merge changes to some of these, and >> still they were replaced with the newer versions. I don't know what went >> wrong but have restored them from backup. (I always tar /etc before a >> source upgrade). Upgrading another system using freebsd-update did not >> cause any problem. > > I have the same experience while I was upgrading a few machines > upgrading from RELENG_7 to RELENG_7_2. I haven't experienced when > upgrading from 7.1-R to 7.2-R. Careful there - RELENG_7 is _newer_ than RELENG_7_2. The latter is branched off RELENG_7 at some point and progresses much slower (as in: errata and security, but no development), so that's no "update", but often the reverse. -- Matthias Andree From owner-freebsd-stable@FreeBSD.ORG Thu May 7 12:27:35 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 07CCA106564A for ; Thu, 7 May 2009 12:27:35 +0000 (UTC) (envelope-from steve@ibctech.ca) Received: from ibctech.ca (v6.ibctech.ca [IPv6:2607:f118::b6]) by mx1.freebsd.org (Postfix) with SMTP id 84A218FC15 for ; Thu, 7 May 2009 12:27:34 +0000 (UTC) (envelope-from steve@ibctech.ca) Received: (qmail 32815 invoked by uid 89); 7 May 2009 12:29:07 -0000 Received: from unknown (HELO ?IPv6:2607:f118::5?) (steve@ibctech.ca@2607:f118::5) by 2607:f118::b6 with ESMTPA; 7 May 2009 12:29:07 -0000 Message-ID: <4A02D3AC.1050903@ibctech.ca> Date: Thu, 07 May 2009 08:27:24 -0400 From: Steve Bertrand User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Paul Stewart References: <000001c9ce66$ed588fc0$c809af40$@org> In-Reply-To: <000001c9ce66$ed588fc0$c809af40$@org> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: Keeping Updated X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2009 12:27:35 -0000 Paul Stewart wrote: > I guess I'm kinda wondering the "condensed quick version" of what people are > typically doing to keep their system updated from source without making life > difficult ;) Yes, I've been reading through various things to get myself > updated to newer info but there's also a lot of stuff on the Internet based > on older info hence why I'm asking. Not to take away from any of the other great responses, I just want to throw out there that I use fastest_cvsup to find the csup server with the lowest latency: # pkg_add -r fastest_cvsup ... and then run it like this: # fastest_cvsup -c ca,us Given that I know where you are, you will likely always be best off with cvsup.ca.FreeBSD.org, and put that into your supfile against default host. I then run "csup -L 2 -g /etc/supfile" in cron for once a week. I'll then update the actual system for advisories, new features if they apply to me, or generally any time I turn up a new system or VM to keep them all consistent. Cheers, Steve From owner-freebsd-stable@FreeBSD.ORG Thu May 7 13:08:36 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 890171065674 for ; Thu, 7 May 2009 13:08:36 +0000 (UTC) (envelope-from avk@vl.ru) Received: from csmtp-2.masterhost.ru (csmtp1.masterhost.ru [83.222.22.203]) by mx1.freebsd.org (Postfix) with SMTP id B052F8FC0C for ; Thu, 7 May 2009 13:08:27 +0000 (UTC) (envelope-from avk@vl.ru) Received: (qmail 13998 invoked from network); 7 May 2009 12:41:44 -0000 Received: from gw2.masterhost.ru (HELO ?10.100.114.238?) (akriventsov@masterhost.ru@87.242.97.5) by csmtp1.masterhost.ru with SMTP; 7 May 2009 12:41:44 -0000 Message-ID: <4A02D708.3040805@vl.ru> Date: Thu, 07 May 2009 16:41:44 +0400 From: Alexander Kriventsov User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: RELENG_7 fatal trap X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: avk@vl.ru List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2009 13:08:36 -0000 Hi, Sorry for my english. I have fatal trap on my box. Kernel compiled with debug options. System is RELENG_7 amd64 dated 2009-04-14. Kernel config is include GENERIC ident GENERIC-DEBUG device carp options INCLUDE_CONFIG_FILE options KDB options KDB_UNATTENDED options DDB options BREAK_TO_DEBUGGER nooptions SCHED_4BSD options SCHED_ULE options SHMMAXPGS=65536 options SEMMNI=40 options SEMMNS=240 options SEMUME=40 options SEMMNU=120 $ uname -a FreeBSD svc13.masterhost.ru 7.2-amd64-20090414-RELENG_7 FreeBSD 7.2-amd64-20090414-RELENG_7 #0: Tue Apr 14 07:28:46 UTC 2009 root@svc13.masterhost.ru:/usr/obj/usr/src/sys/GENERICDEBUG amd64 In kgdb $ kgdb /boot/GENERICDEBUG/kernel /var/crash/vmcore.2 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0x108 fault code = supervisor write data, page not present instruction pointer = 0x8:0xffffffff805964bc stack pointer = 0x10:0xfffffffebe8b66d0 frame pointer = 0x10:0xfffffffebe8b6740 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 6010 (sh) trap number = 12 panic: page fault cpuid = 1 GEOM_MIRROR: Device gm1: rebuilding provider da1s2 stopped. Uptime: 27m29s Physical memory: 2029 MB Dumping 322 MB: 307 291 275 259 243 227 211 195 179 163 147 131 115 99 83 67 51 35 19 3 Reading symbols from /boot/kernel/geom_mirror.ko...Reading symbols from /boot/GENERICDEBUG/geom_mirror.ko.symbols...done. done. Loaded symbols for /boot/kernel/geom_mirror.ko Reading symbols from /boot/kernel/geom_stripe.ko...Reading symbols from /boot/GENERICDEBUG/geom_stripe.ko.symbols...done. done. Loaded symbols for /boot/kernel/geom_stripe.ko Reading symbols from /boot/kernel/ipmi.ko...Reading symbols from /boot/GENERICDEBUG/ipmi.ko.symbols...done. done. Loaded symbols for /boot/kernel/ipmi.ko Reading symbols from /boot/kernel/smbus.ko...Reading symbols from /boot/GENERICDEBUG/smbus.ko.symbols...done. done. Loaded symbols for /boot/kernel/smbus.ko Reading symbols from /boot/kernel/ipl.ko...Reading symbols from /boot/GENERICDEBUG/ipl.ko.symbols...done. done. Loaded symbols for /boot/kernel/ipl.ko Reading symbols from /boot/kernel/if_vlan.ko...Reading symbols from /boot/GENERICDEBUG/if_vlan.ko.symbols...done. done. Loaded symbols for /boot/kernel/if_vlan.ko Reading symbols from /boot/kernel/nullfs.ko...Reading symbols from /boot/GENERICDEBUG/nullfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/nullfs.ko Reading symbols from /boot/kernel/linprocfs.ko...Reading symbols from /boot/GENERICDEBUG/linprocfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/linprocfs.ko Reading symbols from /boot/kernel/linux.ko...Reading symbols from /boot/GENERICDEBUG/linux.ko.symbols...done. done. Loaded symbols for /boot/kernel/linux.ko #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 0xffffffff80521b08 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 #2 0xffffffff80521f6c in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:574 #3 0xffffffff807f1fc3 in trap_fatal (frame=0xc, eva=Variable "eva" is not available. ) at /usr/src/sys/amd64/amd64/trap.c:757 #4 0xffffffff807f23a4 in trap_pfault (frame=0xfffffffebe8b6620, usermode=0) at /usr/src/sys/amd64/amd64/trap.c:673 #5 0xffffffff807f2d52 in trap (frame=0xfffffffebe8b6620) at /usr/src/sys/amd64/amd64/trap.c:444 #6 0xffffffff807d660e in calltrap () at /usr/src/sys/amd64/amd64/exception.S:209 #7 0xffffffff805964bc in cache_lookup (dvp=0x0, vpp=0xfffffffebe8b6978, cnp=0xfffffffebe8b69a0) at atomic.h:143 #8 0xffffffff80596903 in vfs_cache_lookup (ap=Variable "ap" is not available. ) at /usr/src/sys/kern/vfs_cache.c:747 #9 0xffffffff808393a0 in VOP_LOOKUP_APV (vop=0xffffffff80afcc20, a=0xfffffffebe8b6820) at vnode_if.c:99 #10 0xffffffff8059d0d8 in lookup (ndp=0xfffffffebe8b6950) at vnode_if.h:57 #11 0xffffffff8059debe in namei (ndp=0xfffffffebe8b6950) at /usr/src/sys/kern/vfs_lookup.c:215 #12 0xffffffff805ac721 in kern_stat (td=0xffffff004546e000, path=0x800b04400
, pathseg=Variable "pathseg" is not available. ) at /usr/src/sys/kern/vfs_syscalls.c:2123 #13 0xffffffff805ac98a in stat (td=Variable "td" is not available. ) at /usr/src/sys/kern/vfs_syscalls.c:2107 #14 0xffffffff807f2626 in syscall (frame=0xfffffffebe8b6c80) at /usr/src/sys/amd64/amd64/trap.c:900 #15 0xffffffff807d681b in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:330 #16 0x00000008009895ec in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) bt full #0 doadump () at pcpu.h:195 No locals. #1 0xffffffff80521b08 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 _ep = (struct eventhandler_entry *) 0x0 _el = Variable "_el" is not available. Please give me advise. Thanks From owner-freebsd-stable@FreeBSD.ORG Thu May 7 13:46:09 2009 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8C91E106566C for ; Thu, 7 May 2009 13:46:09 +0000 (UTC) (envelope-from danger@FreeBSD.org) Received: from hosting.cia.sk (hosting.cia.sk [92.240.234.123]) by mx1.freebsd.org (Postfix) with ESMTP id 10B108FC08 for ; Thu, 7 May 2009 13:46:08 +0000 (UTC) (envelope-from danger@FreeBSD.org) Received: from hosting.cia.sk (hosting.cia.sk [92.240.234.123]) by hosting.cia.sk (8.14.3/8.14.3) with ESMTP id n47D9Vg6013192; Thu, 7 May 2009 15:09:31 +0200 (CEST) (envelope-from danger@FreeBSD.org) Received: (from www@localhost) by hosting.cia.sk (8.14.3/8.14.3/Submit) id n47D9Pp1013023; Thu, 7 May 2009 15:09:25 +0200 (CEST) (envelope-from danger@FreeBSD.org) X-Authentication-Warning: hosting.cia.sk: www set sender to danger@FreeBSD.org using -f To: Matthias Andree MIME-Version: 1.0 Date: Thu, 07 May 2009 15:09:25 +0200 From: Daniel Gerzo Organization: The FreeBSD Project In-Reply-To: References: <20090504225012.392fa49f.torfinn.ingolfsen@broadpark.no> <49FF5901.600@gmail.com> <49FFEECE.20403@FreeBSD.org> Message-ID: <62bf86e574316680f37efd872c1d361a@services.rulez.sk> X-Sender: danger@FreeBSD.org User-Agent: RoundCube Webmail/0.2a Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="UTF-8" Cc: Torfinn Ingolfsen , freebsd-stable@FreeBSD.org, Manolis Kiagias Subject: Re: RELENG_7 - has mergemaster changed logic since 7.2-RELEASE? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2009 13:46:09 -0000 On Thu, 07 May 2009 09:40:52 +0200, "Matthias Andree" wrote: > Am 05.05.2009, 09:46 Uhr, schrieb Daniel Gerzo : > >> Manolis Kiagias wrote: >> >>> I always use -iU too. >>> I've lost motd, passwd, group and master.passwd >>> During mergemaster -p I was asked to merge changes to some of these, and >>> still they were replaced with the newer versions. I don't know what went >>> wrong but have restored them from backup. (I always tar /etc before a >>> source upgrade). Upgrading another system using freebsd-update did not >>> cause any problem. >> >> I have the same experience while I was upgrading a few machines >> upgrading from RELENG_7 to RELENG_7_2. I haven't experienced when >> upgrading from 7.1-R to 7.2-R. > > Careful there - RELENG_7 is _newer_ than RELENG_7_2. The latter is > branched off RELENG_7 at some point and progresses much slower (as in: > errata and security, but no development), so that's no "update", but often > > the reverse. That's not definitely true all the time. You could for example update your 7.1 to releng_7, say in Sept. 2008, then run this box until releng_7_2 was branched and when you update to it at that point you actually are doing an update, definitely not a downgrade. -- Kind regards Daniel From owner-freebsd-stable@FreeBSD.ORG Thu May 7 14:17:58 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3EC5C106564A for ; Thu, 7 May 2009 14:17:58 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id E88F28FC1E for ; Thu, 7 May 2009 14:17:57 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1M24Q6-0003zF-W6 for freebsd-stable@freebsd.org; Thu, 07 May 2009 14:17:55 +0000 Received: from 91.205.197.96 ([91.205.197.96]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 07 May 2009 14:17:54 +0000 Received: from jumper99 by 91.205.197.96 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 07 May 2009 14:17:54 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: "Helmut Schneider" Date: Thu, 7 May 2009 16:17:42 +0200 Lines: 29 Message-ID: References: <4A019B38.3060101@icyb.net.ua> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 91.205.197.96 X-MSMail-Priority: Normal X-Newsreader: vi with a tiny little GUI X-MimeOLE: Huh, what?! Sender: news Subject: Re: kbd0 at both atkbd0 and ukbd0 [Was: [7.2] R/W mount of / denied. Filesystem not clean - run fsck.] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2009 14:17:58 -0000 Andriy Gapon wrote: > on 06/05/2009 14:43 Helmut Schneider said the following: >> kbd1 at kbdmux0 > [snip] >> atkbdc0: at port 0x60,0x64 on isa0 >> atkbd0: irq 1 on atkbdc0 >> kbd0 at atkbd0 >> atkbd0: [GIANT-LOCKED] >> atkbd0: [ITHREAD] > [snip] >> ukbd0: on uhub0 >> kbd0 at ukbd0 > > It took me three passes to notice the above: "kbd0 at atkbd0" and then > again "kbd0 at ukbd0". Good point: http://www.freebsd.org/cgi/query-pr.cgi?pr=122887 http://www.freebsd.org/cgi/query-pr.cgi?pr=133919 I have 'hint.atkbd.0.disabled="1"' at /boot/default.hints and (probably) freebsd-update killed that one and silently replaced it with 1.16.8.1. The whole mess might be related. D'oh! -- No Swen today, my love has gone away My mailbox stands for lorn, a symbol of the dawn From owner-freebsd-stable@FreeBSD.ORG Thu May 7 16:02:12 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 978AF106566B for ; Thu, 7 May 2009 16:02:12 +0000 (UTC) (envelope-from riccardo.torrini@esaote.com) Received: from gw-fi.esaote.com (gw-fi.esaote.com [85.18.189.242]) by mx1.freebsd.org (Postfix) with ESMTP id E7D838FC15 for ; Thu, 7 May 2009 16:02:11 +0000 (UTC) (envelope-from riccardo.torrini@esaote.com) Received: from tiger.fi.esaote.it (tiger.fi.esaote.it [192.168.6.66]) by gw-fi.esaote.com (8.14.3/8.14.3) with ESMTP id n47FoClf071902; Thu, 7 May 2009 17:50:13 +0200 (CEST) (envelope-from riccardo.torrini@esaote.com) Received: from tiger.fi.esaote.it (localhost [127.0.0.1]) by tiger.fi.esaote.it (Postfix) with ESMTP id D08D31CC9A; Thu, 7 May 2009 17:50:12 +0200 (CEST) Received: by tiger.fi.esaote.it (Postfix, from userid 201) id B41AF1CC99; Thu, 7 May 2009 17:50:12 +0200 (CEST) Date: Thu, 7 May 2009 17:50:12 +0200 From: Riccardo Torrini To: freebsd-stable@freebsd.org Message-ID: <20090507155012.GW21112@tiger.fi.esaote.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.19 (2009-01-05) X-AV-Checked: ClamAV using ClamSMTP Cc: siedar@nplay.pl, scottl@freebsd.org, jhb@freebsd.org Subject: kern/130330: [mpt] [panic] Panic and reboot machine MPT ... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2009 16:02:12 -0000 I just submitted a follow-up to PR kern/130330 with the same info. Maybe I found the committed lines doing the crash. Please see PR for more detailed info (and cc: this thread to me). I restricted the time window of the problem doing (a lot of) build&install world from 2008.07 up to now (read last week). With 2008.07.28.17.00.00 (7.0-STABLE) works fine but with 2008.07.28.18.00.00 start crashing removing the the second disk of a mirror (when the mirror is ok) or adding the second disk of a degraded ones. Also note that the same crash happens with all 7.1 stable or release and even all 7.2-PRE I tested. (wrapping long lines) # cd /home/ncvs/src/sys/ # grep -R "date.*2008\.07\.28\.17" ./ | grep -v /Attic ./dev/wi/if_wi.c,v: date 2008.07.28.17.00.37; author imp; state Exp; ./dev/wi/if_wivar.h,v: date 2008.07.28.17.00.37; author imp; state Exp; ./dev/mpt/mpt_raid.c,v: date 2008.07.28.17.10.09; author jhb; state Exp; ./dev/mpt/mpt_raid.c,v: date 2008.07.28.17.05.09; author jhb; state Exp; ./kern/sched_4bsd.c,v: date 2008.07.28.17.25.24; author jhb; state Exp; ./modules/et/Makefile,v: date 2008.07.28.17.56.37; author antoine; state Exp; In that time window there are only 4 file changed in src/sys/dev, and I bet to mpt_raid.c :-) This is the commit log extracted from cvsweb -----8<----- Revision 1.15.2.1: Mon Jul 28 17:05:09 2008 UTC (9 months, 1 week ago) by jhb Branches: RELENG_7 CVS tags: RELENG_7_1_BP Branch point for: RELENG_7_1 Diff to: previous 1.15: preferred, colored Changes since revision 1.15: +4 -4 lines SVN rev 180920 on 2008-07-28 17:05:09Z by jhb MFC: Allocate a single CCB at the start of the main loop of the RAID monitoring kthread of the mpt(4) driver. -----8<----- Here are the diff: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/mpt/mpt_raid.c.diff?r1=1.15;r2=1.15.2.1 What can I do now? -- Riccardo. Network Manager @ ESAOTE S.p.A. From owner-freebsd-stable@FreeBSD.ORG Thu May 7 22:59:47 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D3B03106564A for ; Thu, 7 May 2009 22:59:47 +0000 (UTC) (envelope-from steve@ibctech.ca) Received: from ibctech.ca (v6.ibctech.ca [IPv6:2607:f118::b6]) by mx1.freebsd.org (Postfix) with SMTP id 920048FC14 for ; Thu, 7 May 2009 22:59:47 +0000 (UTC) (envelope-from steve@ibctech.ca) Received: (qmail 54013 invoked by uid 89); 7 May 2009 23:01:23 -0000 Received: from unknown (HELO ?IPv6:2607:f118::5?) (steve@ibctech.ca@2607:f118::5) by 2607:f118::b6 with ESMTPA; 7 May 2009 23:01:23 -0000 Message-ID: <4A0367DA.80200@ibctech.ca> Date: Thu, 07 May 2009 18:59:38 -0400 From: Steve Bertrand User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: FreeBSD X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Jails and IPv6 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2009 22:59:48 -0000 I just want to throw out a heart-felt thank you, congratulations and excellent work to all those who had their hand in making the jail framework so completely flexible (particularly on the IP side of things). Kudos, and thank you all. IPv6 works flawlessly! Steve From owner-freebsd-stable@FreeBSD.ORG Fri May 8 05:29:23 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 730A01065674; Fri, 8 May 2009 05:29:23 +0000 (UTC) (envelope-from david@usermode.org) Received: from proxy.meer.net (proxy.meer.net [64.13.141.13]) by mx1.freebsd.org (Postfix) with ESMTP id 5370E8FC0C; Fri, 8 May 2009 05:29:23 +0000 (UTC) (envelope-from david@usermode.org) Received: from mail.meer.net (mail.meer.net [64.13.141.3]) by proxy.meer.net (8.14.3/8.14.3) with ESMTP id n485TMsc053822; Thu, 7 May 2009 22:29:23 -0700 (PDT) (envelope-from david@usermode.org) Received: from radagast.usermode.org (netblock-66-245-218-138.dslextreme.com [66.245.218.138]) by mail.meer.net (8.13.3/8.13.3/meer) with ESMTP id n485TInb056900; Thu, 7 May 2009 22:29:18 -0700 (PDT) (envelope-from david@usermode.org) From: David Johnson To: freebsd-stable@freebsd.org Date: Thu, 7 May 2009 22:29:17 -0700 User-Agent: KMail/1.11.2 (FreeBSD/7.2-RELEASE; KDE/4.2.2; i386; ; ) References: <200905042015.29394.david@usermode.org> <1241504417.1828.19.camel@balrog.2hip.net> <200905052041.48623.david@usermode.org> In-Reply-To: <200905052041.48623.david@usermode.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200905072229.17798.david@usermode.org> X-Spam-Score: undef - spam scanning disabled X-CanIt-Geo: ip=64.13.141.3; country=US; region=CA; city=Mountain View; latitude=37.3974; longitude=-122.0732; metrocode=807; areacode=650; http://maps.google.com/maps?q=37.3974,-122.0732&z=6 X-CanItPRO-Stream: default X-Canit-Stats-ID: Bayes signature not available X-Scanned-By: CanIt (www . roaringpenguin . com) on 64.13.141.13 Cc: Robert Noland Subject: Re: Xorg hangs with drmwtq in 7.2-RELEASE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2009 05:29:23 -0000 On Tuesday 05 May 2009 08:41:48 pm David Johnson wrote: > On Monday 04 May 2009 11:20:17 pm Robert Noland wrote: > > This generally suggests that the GPU is locked up... Given that you say > > sometimes it locks up hard (usually a panic, that you can't see since X > > is running) and other times only X is stalled it might be related to > > this patch, if you haven't tried this on already. > > > > http://people.freebsd.org/~rnoland/drm_radeon-copyin-fix-try2.patch > > Nope, that didn't help. Still froze when I tried opening multiple windows > at once. I'm backing out the patch to get back to a clean state. > > I also edited my xorg.conf to be closer to yours. No difference. > > What information do you need to go forward, and how do I collect it? > > p.s. I didn't have a problem with sources from RELENG_7 date=2009.03.13, if > that helps any. I just upgraded graphics/libdrm. It didn't help any. I'm just shooting blanks in the dark. Any help would be greatly appreciated. Please let me know what information is needed and how I collect it. Thank you, -- David Johnson From owner-freebsd-stable@FreeBSD.ORG Fri May 8 10:05:53 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CFDB21065672 for ; Fri, 8 May 2009 10:05:53 +0000 (UTC) (envelope-from david.marec@davenulle.org) Received: from smtp.lamaiziere.net (net.lamaiziere.net [91.121.44.19]) by mx1.freebsd.org (Postfix) with ESMTP id 99F468FC14 for ; Fri, 8 May 2009 10:05:53 +0000 (UTC) (envelope-from david.marec@davenulle.org) Received: from david (17.4.193-77.rev.gaoland.net [77.193.4.17]) by smtp.lamaiziere.net (Postfix) with ESMTPA id ED910633301 for ; Fri, 8 May 2009 11:47:47 +0200 (CEST) From: David Marec Organization: LaMienne To: "freebsd-stable" Date: Fri, 8 May 2009 11:47:46 +0200 User-Agent: KMail/1.9.10 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200905081147.46736.david.marec@davenulle.org> Subject: EEEPC and FreeBSD 7.2 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2009 10:05:54 -0000 hi! I am trying to use an EEEPC 701 as a diskless station, running FreeBSD 7.2. The EEPC station boots well with PXE then runs the kernel, but the only network card that is recognized is the wireless one (ath0). I read that the wired NIC ( ae? ) has been committed to HEAD; is there any way to make it work on 7-STABLE ? -- http://david.marec.free.fr/ http://www.freebsd.org/fr/ http://www.diablotins.org/ From owner-freebsd-stable@FreeBSD.ORG Fri May 8 11:17:58 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 42688106566C for ; Fri, 8 May 2009 11:17:58 +0000 (UTC) (envelope-from sklarkin@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.155]) by mx1.freebsd.org (Postfix) with ESMTP id C53008FC22 for ; Fri, 8 May 2009 11:17:57 +0000 (UTC) (envelope-from sklarkin@gmail.com) Received: by fg-out-1718.google.com with SMTP id 22so253962fge.12 for ; Fri, 08 May 2009 04:17:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:subject :message-id:in-reply-to:references:x-mailer:mime-version :content-type:content-transfer-encoding; bh=l+I0GOzQbzUUWXLL01eaMIrmhaXO10jgH6ycRlgHHow=; b=dmgZ7u0oG4NJPea6knedD0ZLg+BRLJVoIwYjvu8yhlVArRFYDVLcdhaZCkiTzYNdsC blrhbwhlM+6Lz+fEKADx44KEgj9vsxKseP31V1hJ8/hu3LhZXaopFZCnUAVFe3JzQ0xn gG7eIfykx3TA2okIxR5iPAm5HfyDR6/WUP+jU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type:content-transfer-encoding; b=pYwT1U3KSMHhoTJb9ULObOUoDxJUwdmPaanGfZbV4834He0xD78vIitE1z/sr2If72 S1CDLjGR+N2EJGeH549cMJfzSZwivk7uS36dGJ5+rC+klc/q2g+n9AAuFhIv6uu29qvE A9KwnZKh2EsDTUCDXcMLmSccGnnVVMBe2yd88= Received: by 10.86.53.2 with SMTP id b2mr3474503fga.67.1241779901026; Fri, 08 May 2009 03:51:41 -0700 (PDT) Received: from localhost ([213.181.8.29]) by mx.google.com with ESMTPS id e20sm790401fga.0.2009.05.08.03.51.39 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 08 May 2009 03:51:40 -0700 (PDT) Date: Fri, 8 May 2009 14:51:38 +0400 From: sklarkin To: freebsd-stable@freebsd.org Message-ID: <20090508145138.7269eb1a@gmail.com> In-Reply-To: <200905081147.46736.david.marec@davenulle.org> References: <200905081147.46736.david.marec@davenulle.org> X-Mailer: Claws Mail 3.7.1 (GTK+ 2.16.1; i386-portbld-freebsd7.1) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: EEEPC and FreeBSD 7.2 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2009 11:17:58 -0000 =D0=92 Fri, 8 May 2009 11:47:46 +0200 David Marec =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > hi! >=20 > I am trying to use an EEEPC 701 as a diskless station, running > FreeBSD 7.2. >=20 > The EEPC station boots well with PXE then runs the kernel, but the > only network card that is recognized is the wireless one (ath0). >=20 > I read that the wired NIC ( ae? ) has been committed to HEAD; is > there any way to make it work on 7-STABLE ? >=20 >=20 >=20 http://wiki.freebsd.org/AsusEee --=20 From owner-freebsd-stable@FreeBSD.ORG Fri May 8 13:46:55 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3969C106564A for ; Fri, 8 May 2009 13:46:55 +0000 (UTC) (envelope-from chris@hitnet.RWTH-Aachen.DE) Received: from mta-2.ms.rz.rwth-aachen.de (mta-2.ms.rz.RWTH-Aachen.DE [134.130.7.73]) by mx1.freebsd.org (Postfix) with ESMTP id D5D8F8FC12 for ; Fri, 8 May 2009 13:46:54 +0000 (UTC) (envelope-from chris@hitnet.RWTH-Aachen.DE) MIME-version: 1.0 Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) by mta-2.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0KJB003B5U85F690@mta-2.ms.rz.RWTH-Aachen.de> for freebsd-stable@freebsd.org; Fri, 08 May 2009 15:16:53 +0200 (CEST) X-IronPort-AV: E=Sophos;i="4.40,317,1238968800"; d="scan'208";a="11213380" Received: from smarthost-2.ms.rz.rwth-aachen.de (HELO smarthost.rwth-aachen.de) ([134.130.7.90]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Fri, 08 May 2009 15:16:53 +0200 Received: from bigboss.hitnet.rwth-aachen.de (bigspace.hitnet.RWTH-Aachen.DE [137.226.181.2]) by smarthost.rwth-aachen.de (8.13.8+Sun/8.13.8/1) with ESMTP id n48DGrns025868; Fri, 08 May 2009 15:16:53 +0200 (CEST) Received: from haakonia.hitnet.rwth-aachen.de ([137.226.181.92]) by bigboss.hitnet.rwth-aachen.de with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1M2Pwb-0002m1-Bx; Fri, 08 May 2009 15:16:53 +0200 Received: by haakonia.hitnet.rwth-aachen.de (Postfix, from userid 1001) id 07AC63F41E; Fri, 08 May 2009 15:16:53 +0200 (CEST) Date: Fri, 08 May 2009 15:16:52 +0200 From: Christian Brueffer To: Ken Smith Message-id: <20090508131652.GB1187@haakonia.hitnet.RWTH-Aachen.DE> References: <49F5BB24.2090206@nlink.com.br> <1240844716.59908.14.camel@bauer.cse.buffalo.edu> <49F5E723.6040700@nlink.com.br> <1240852596.59908.33.camel@bauer.cse.buffalo.edu> <49F6FC02.7060803@nlink.com.br> <1241006514.38254.12.camel@neo.cse.buffalo.edu> <49F8458D.7000607@nlink.com.br> <49F86536.9080604@nlink.com.br> <1241017310.68402.133.camel@bauer.cse.buffalo.edu> Content-type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary=mYCpIKhGyMATD0i+ Content-disposition: inline In-reply-to: <1241017310.68402.133.camel@bauer.cse.buffalo.edu> X-Operating-System: FreeBSD 6.4-STABLE X-PGP-Key: http://people.FreeBSD.org/~brueffer/brueffer.key.asc X-PGP-Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D User-Agent: Mutt/1.5.11 Cc: freebsd-stable@freebsd.org Subject: Re: Freebsd 7.2-RC boot problem X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2009 13:46:55 -0000 --mYCpIKhGyMATD0i+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 29, 2009 at 11:01:50AM -0400, Ken Smith wrote: > On Wed, 2009-04-29 at 11:33 -0300, Paulo Fragoso wrote: > > Hardware: > > MB: Gigabyte GA-M61PME-S2 > > acd0: DVDR at ata3-master SATA150 > >=20 > > ISO MEDIA BOOT > > 7.2-RC2-i386-dvd1.iso DVD-RW OK > > 7.2-RC2-i386-livefs.iso CD-RW OK! > > 7.2-RC2-amd64-disc1.iso CD-RW OK > > 7.2-RC2-i386-disc1.iso CD-RW,CD-R FAILS >=20 > Thanks, greatly appreciate all the testing. >=20 > As part of looking into this I went looking for another Gigabyte > motherboard and through the past 2 days was able to test the same set of > things with the same results. So far I haven't been able to reproduce > this on anything but Gigabyte. This is such a bizarre problem I really > needed someone else to confirm so thank you very much. Since there is a > workaround I don't think I'll hold the release for this problem but we > will need to mention this in the Errata (and possibly the announcement > itself). >=20 I just got bitten by this on a VIA EPIA-M system. 7.2-RELEASE-i386-disc1.iso doesn't work 7.2-RELEASE-i386-bootonly.iso works - Christian --=20 Christian Brueffer chris@unixpages.org brueffer@FreeBSD.org GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D --mYCpIKhGyMATD0i+ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFKBDDEbHYXjKDtmC0RAi1kAJ9jhHCL7veSP9cVKnwMqwaTZ+2RVgCg9dlL u/Ub1Y7RbLkuukzsv+dYMRk= =u8yV -----END PGP SIGNATURE----- --mYCpIKhGyMATD0i+-- From owner-freebsd-stable@FreeBSD.ORG Fri May 8 14:18:40 2009 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B7DDD106567C for ; Fri, 8 May 2009 14:18:40 +0000 (UTC) (envelope-from dudu.meyer@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.30]) by mx1.freebsd.org (Postfix) with ESMTP id 762E48FC12 for ; Fri, 8 May 2009 14:18:40 +0000 (UTC) (envelope-from dudu.meyer@gmail.com) Received: by yw-out-2324.google.com with SMTP id 9so839509ywe.13 for ; Fri, 08 May 2009 07:18:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=NABaxgTs5SPHB/CwEGQypTqgix1qLRT0amRbO0IcElE=; b=DNuN7agU2pd1KlFc1OHn0QgGNPqCUj0KCuU1/gbTuoBFyNDF6IqioMvAkVgvmwhpNP +nR4EBL18HhNQ++YhUL0BpLLYbzSTDhx9DBO70HwkvfIr0ss/p+G2l9gy02lpeMJ9jjt D8scbOsCLca1llUSWcWhl12J5iAPipt3o2FnU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=PLBWqaGAeLwSWFk1Sy/VPtfhTY8MQlKDEL5EoEKJIQUFkYWrCRivCLPWRS0SDA5jpv gL1wDqVvkW3PBRk+fetEEosbc/bbbqOfTbm1eXJXzNUqkEzT4tTkgmd6NTR/jHDakfiJ tyaPdUrj4svn1Va0cbXIVck5kmStnZOgvUo5U= MIME-Version: 1.0 Received: by 10.100.163.15 with SMTP id l15mr8743078ane.22.1241790662205; Fri, 08 May 2009 06:51:02 -0700 (PDT) Date: Fri, 8 May 2009 10:51:02 -0300 Message-ID: From: Eduardo Meyer To: stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: "maxproc limit exceeded" making no sense X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2009 14:18:41 -0000 Hello, I have a problem which makes no sense to me, at least not the way I understand. My mail server is compaining about maxproc limit: # tail /var/log/messages May 8 10:34:15 mx kernel: maxproc limit exceeded by uid 82, please see tuning(7) and login.conf(5). May 8 10:34:38 mx last message repeated 12 times May 8 10:35:14 mx last message repeated 18 times May 8 10:36:32 mx last message repeated 41 times May 8 10:36:35 mx kernel: maxproc limit exceeded by uid 82, please see tuning(7) and login.conf(5). My maxproc as well as maxfiles are artificially raised (a lot raised): # sysctl kern.maxfiles kern.maxfiles: 80000 # sysctl kern.maxfilesperproc kern.maxfilesperproc: 80000 # sysctl kern.maxproc kern.maxproc: 9000 # sysctl kern.maxprocperuid kern.maxprocperuid: 80000 However what I see regarding proc usage is by uid 82 is: # ps -U 82 | wc -l 723 Proccess count for UID 82 is never highter than 913 (monitored the last whole hour, while log messages were still showing, complaining about maxproc limit beeing exceeded). I would like to understand and figure out what I need to tune in order to raise the current limit, and also find what the current limit is. Thank you a lot and in advance. -- =========== Eduardo Meyer pessoal: dudu.meyer@gmail.com profissional: ddm.farmaciap@saude.gov.br From owner-freebsd-stable@FreeBSD.ORG Fri May 8 14:36:12 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8A796106566C for ; Fri, 8 May 2009 14:36:11 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id 30FDC8FC08 for ; Fri, 8 May 2009 14:36:11 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from [192.168.1.4] (adsl-154-182-184.bna.bellsouth.net [68.154.182.184]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id n48Ea5oP091359 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 8 May 2009 10:36:05 -0400 (EDT) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: David Johnson In-Reply-To: <200905072229.17798.david@usermode.org> References: <200905042015.29394.david@usermode.org> <1241504417.1828.19.camel@balrog.2hip.net> <200905052041.48623.david@usermode.org> <200905072229.17798.david@usermode.org> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-+phztL67T4U4HxhEOVa+" Organization: FreeBSD Date: Fri, 08 May 2009 09:35:45 -0500 Message-Id: <1241793345.1733.5.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1.1 FreeBSD GNOME Team Port X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_PBL, RCVD_IN_SORBS_DUL,RDNS_DYNAMIC autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: freebsd-stable@freebsd.org Subject: Re: Xorg hangs with drmwtq in 7.2-RELEASE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2009 14:36:12 -0000 --=-+phztL67T4U4HxhEOVa+ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2009-05-07 at 22:29 -0700, David Johnson wrote: > On Tuesday 05 May 2009 08:41:48 pm David Johnson wrote: > > On Monday 04 May 2009 11:20:17 pm Robert Noland wrote: > > > This generally suggests that the GPU is locked up... Given that you = say > > > sometimes it locks up hard (usually a panic, that you can't see since= X > > > is running) and other times only X is stalled it might be related to > > > this patch, if you haven't tried this on already. > > > > > > http://people.freebsd.org/~rnoland/drm_radeon-copyin-fix-try2.patch > > > > Nope, that didn't help. Still froze when I tried opening multiple windo= ws > > at once. I'm backing out the patch to get back to a clean state. > > > > I also edited my xorg.conf to be closer to yours. No difference. > > > > What information do you need to go forward, and how do I collect it? > > > > p.s. I didn't have a problem with sources from RELENG_7 date=3D2009.03.= 13, if > > that helps any. >=20 > I just upgraded graphics/libdrm. It didn't help any. I'm just shooting bl= anks=20 > in the dark. Any help would be greatly appreciated. Please let me know wh= at=20 > information is needed and how I collect it. I still can't reproduce this... I updated the Xserver, libGL and dri ports yesterday, all of which could be related to locking up the GPU and worth a shot. Failing that, I need you to enabled drm debugging. Start the system without X, kldload radeon.ko, set sysctl hw.dri.0.debug=3D1 then startx. robert. > Thank you, >=20 --=20 Robert Noland FreeBSD --=-+phztL67T4U4HxhEOVa+ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEABECAAYFAkoEQ0EACgkQM4TrQ4qfRON6tACcDcp3Am99Dx+MpUeE9geRekmj Ob4AninYZXIbqKzuRyOPEdBtGLxaXMfV =S/qx -----END PGP SIGNATURE----- --=-+phztL67T4U4HxhEOVa+-- From owner-freebsd-stable@FreeBSD.ORG Fri May 8 20:00:05 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DA0C2106564A for ; Fri, 8 May 2009 20:00:05 +0000 (UTC) (envelope-from ubm@u-boot-man.de) Received: from mail.upper.net (mail.upper.net [62.75.224.33]) by mx1.freebsd.org (Postfix) with ESMTP id 6252D8FC0A for ; Fri, 8 May 2009 20:00:05 +0000 (UTC) (envelope-from ubm@u-boot-man.de) Received: from ubm.mine.nu (mail.upper.net [62.75.224.33]) (authenticated bits=0) by mail.upper.net (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id n48JePBY010576 for ; Fri, 8 May 2009 21:40:25 +0200 Received: from ubm.mine.nu ([85.181.29.16] helo=ubm.mine.nu) by ASSP.nospam.UpPeRnEt; 8 May 2009 21:40:25 +0200 Date: Fri, 8 May 2009 21:40:25 +0200 From: Marc "UBM" Bocklet To: freebsd-stable@freebsd.org Message-Id: <20090508214025.540b78e8.ubm@u-boot-man.de> In-Reply-To: <20090329110153.f625612f.ubm@u-boot-man.de> References: <20090119202016.11f42e3b.ubm.freebsd@gmail.com> <49750137.7020105@modulus.org> <20090120080829.b4006877.ubm@u-boot-man.de> <20090329110153.f625612f.ubm@u-boot-man.de> X-Mailer: Sylpheed 2.6.0 (GTK+ 2.12.10; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: problems with sata disks (taskqueue timeout) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2009 20:00:06 -0000 On Sun, 29 Mar 2009 11:01:53 +0200 Marc "UBM" Bocklet wrote: > On Tue, 20 Jan 2009 08:08:29 +0100 > Marc "UBM" Bocklet wrote: > > > On Tue, 20 Jan 2009 09:39:51 +1100 > > Andrew Snow wrote: > > > > > > > > I think that if you use eSATA you probably need dedicated eSATA > > > controller ports. eSATA standard specifies a higher voltage for > > > the longer cable distances. > > > > > > Judging from the sporadic problem reports, Promise TX4 is probably > > > not the best at signal purity to begin with so using it for eSATA > > > pushes it over the edge. > > > > > > > > > Hope that helps, > > > > Thanks for the fast answer! :-) > > > > Although my version of the TX4 has two dedicated e-sata ports, the > > other posts seem to indicate that it got something to do with the > > controller (maybe signal purity, like you said). I'll try upgrading > > next and will report back after that. > > A very late followup here: > > I upgraded to the latest stable, but things did not improve: > > Mar 29 10:57:29 hamstor kernel: ad10: WARNING - WRITE_DMA48 UDMA ICRC > error (retrying request) LBA=1087300992 Mar 29 10:57:34 hamstor > kernel: ad10: FAILURE - SET_MULTI status=51 > error=4 > > Mar 29 10:57:34 hamstor kernel: ad10: TIMEOUT - WRITE_DMA48 retrying > (0 retries left) LBA=1087300992 > > Mar 29 10:57:34 hamstor kernel: ad10: FAILURE - WRITE_DMA48 > status=ff > error=ff > LBA=1087300992 > > Mar 29 10:57:34 hamstor root: ZFS: vdev I/O failure, > zpool=gedaerm path=/dev/ad10 offset=556698042368 size=131072 error=5 > > Mar 29 10:57:43 hamstor kernel: ad10: WARNING - SETFEATURES SET > TRANSFER MODE taskqueue timeout - completing request directly > > Mar 29 10:57:47 hamstor kernel: ad10: WARNING - SETFEATURES SET > TRANSFER MODE taskqueue timeout - completing request directly > > Mar 29 10:57:51 hamstor kernel: ad10: WARNING - SETFEATURES ENABLE > WCACHE taskqueue timeout - completing request directly > > Mar 29 10:57:55 hamstor kernel: ad10: WARNING - SET_MULTI taskqueue > timeout - completing request directly > > Mar 29 10:57:55 hamstor kernel: ad10: TIMEOUT - WRITE_DMA48 retrying > (1 retry left) LBA=1087301248 > > Mar 29 10:57:55 hamstor kernel: ad10: WARNING - WRITE_DMA48 UDMA ICRC > error (retrying request) LBA=1087301248 > > Mar 29 10:58:00 hamstor kernel: ad10: FAILURE - SET_MULTI > status=51 error=4 > > Mar 29 10:58:00 hamstor kernel: ad10: FAILURE - WRITE_DMA48 timed out > LBA=1087301248 > > Mar 29 10:58:00 hamstor root: ZFS: vdev I/O failure, zpool=gedaerm > path=/dev/ad10 offset=556698173440 size=131072 error=5 > > > > Any further ideas anybody? :-) Another update, upgrading to -current dating from April 25th 2009 seems to have "fixed" the problem, I've encountered no errors as of yet and I've copied about 250GB in large chunks, something that was sure to provoke the errors with -stable. FreeBSD xxx 8.0-CURRENT FreeBSD 8.0-CURRENT #1: Sat Apr 25 13:33:18 CEST 2009 xxx:/usr/obj/usr/src/sys/xxx amd64 Bye Marc -- "And what rough beast, its hour come round at last, Slouches towards Bethlehem to be born?" W.B. Yeats, The Second Coming From owner-freebsd-stable@FreeBSD.ORG Fri May 8 20:50:07 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A6CD3106566B for ; Fri, 8 May 2009 20:50:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [195.88.108.3]) by mx1.freebsd.org (Postfix) with ESMTP id 61A3C8FC15 for ; Fri, 8 May 2009 20:50:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 2BB9141C756; Fri, 8 May 2009 22:50:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([195.88.108.3]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id 3DDA6V-+CAOB; Fri, 8 May 2009 22:50:05 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id AEDE341C751; Fri, 8 May 2009 22:50:05 +0200 (CEST) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 540614448EC; Fri, 8 May 2009 20:49:08 +0000 (UTC) Date: Fri, 8 May 2009 20:49:08 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Steve Bertrand In-Reply-To: <4A0367DA.80200@ibctech.ca> Message-ID: <20090508204023.T72053@maildrop.int.zabbadoz.net> References: <4A0367DA.80200@ibctech.ca> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD Subject: Re: Jails and IPv6 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2009 20:50:07 -0000 On Thu, 7 May 2009, Steve Bertrand wrote: Hi Steve, > I just want to throw out a heart-felt thank you, congratulations and > excellent work to all those who had their hand in making the jail > framework so completely flexible (particularly on the IP side of things). > > Kudos, and thank you all. IPv6 works flawlessly! Happy to see things work fine for you as well:) It's really great to get feedback like that! Obviously, if you find any problem we'll also like to hear about that. In that case you may probably want to post to the freebsd-jail mailing list to get help. The same obviously applies to anyone going to give it a try;-) /bz PS: saying what I have said before: if you are using jails and like the new features and they work out for you or you may make money by using them and want to give something back, consider a donation to the FreeBSD Foundation: see http://www.freebsdfoundation.org/donate/ -- Bjoern A. Zeeb The greatest risk is not taking one. From owner-freebsd-stable@FreeBSD.ORG Fri May 8 21:59:01 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 41F831065675; Fri, 8 May 2009 21:59:01 +0000 (UTC) (envelope-from david@usermode.org) Received: from proxy.meer.net (proxy.meer.net [64.13.141.13]) by mx1.freebsd.org (Postfix) with ESMTP id 233B28FC08; Fri, 8 May 2009 21:59:01 +0000 (UTC) (envelope-from david@usermode.org) Received: from mail.meer.net (mail.meer.net [64.13.141.3]) by proxy.meer.net (8.14.3/8.14.3) with ESMTP id n48Lx0wj095060; Fri, 8 May 2009 14:59:00 -0700 (PDT) (envelope-from david@usermode.org) Received: from radagast.usermode.org (netblock-66-245-217-105.dslextreme.com [66.245.217.105]) by mail.meer.net (8.13.3/8.13.3/meer) with ESMTP id n48Lwrem041391; Fri, 8 May 2009 14:58:53 -0700 (PDT) (envelope-from david@usermode.org) From: David Johnson To: freebsd-stable@freebsd.org Date: Fri, 8 May 2009 14:58:53 -0700 User-Agent: KMail/1.11.2 (FreeBSD/7.2-RELEASE; KDE/4.2.2; i386; ; ) References: <200905042015.29394.david@usermode.org> <200905072229.17798.david@usermode.org> <1241793345.1733.5.camel@balrog.2hip.net> In-Reply-To: <1241793345.1733.5.camel@balrog.2hip.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200905081458.53651.david@usermode.org> X-Spam-Score: undef - spam scanning disabled X-CanIt-Geo: ip=64.13.141.3; country=US; region=CA; city=Mountain View; latitude=37.3974; longitude=-122.0732; metrocode=807; areacode=650; http://maps.google.com/maps?q=37.3974,-122.0732&z=6 X-CanItPRO-Stream: default X-Canit-Stats-ID: Bayes signature not available X-Scanned-By: CanIt (www . roaringpenguin . com) on 64.13.141.13 Cc: Robert Noland Subject: Re: Xorg hangs with drmwtq in 7.2-RELEASE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2009 21:59:01 -0000 On Friday 08 May 2009 07:35:45 am Robert Noland wrote: > I still can't reproduce this... I updated the Xserver, libGL and dri > ports yesterday, all of which could be related to locking up the GPU and > worth a shot. Failing that, I need you to enabled drm debugging. Start > the system without X, kldload radeon.ko, set sysctl hw.dri.0.debug=1 > then startx. I've got all the updated ports as of last night, so that wasn't it. I turned AIGLX back on, and it promptly locked up again. This time, however, the screen went black instead of freezing, but otherwise the same as always. I then turned on hw.dri.0.debug, and messages quickly filled up with the following repeated message: [drm:pid1195:drm_ioctl] returning 4 [drm:pid1195:drm_ioctl] pid=1195, cmd=0x80046457, nr=0x57, dev 0xc615fa00, auth=1 -- David Johnson From owner-freebsd-stable@FreeBSD.ORG Fri May 8 22:31:31 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3721A106564A for ; Fri, 8 May 2009 22:31:31 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id EB5C18FC1A for ; Fri, 8 May 2009 22:31:30 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from [192.168.1.4] (adsl-154-182-184.bna.bellsouth.net [68.154.182.184]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id n48MVPAa094625 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 8 May 2009 18:31:25 -0400 (EDT) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: David Johnson In-Reply-To: <200905081458.53651.david@usermode.org> References: <200905042015.29394.david@usermode.org> <200905072229.17798.david@usermode.org> <1241793345.1733.5.camel@balrog.2hip.net> <200905081458.53651.david@usermode.org> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-D0bQcSOzGXYMt3hJuZLW" Organization: FreeBSD Date: Fri, 08 May 2009 17:31:04 -0500 Message-Id: <1241821864.1733.51.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1.1 FreeBSD GNOME Team Port X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_PBL, RCVD_IN_SORBS_DUL,RDNS_DYNAMIC autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: freebsd-stable@freebsd.org Subject: Re: Xorg hangs with drmwtq in 7.2-RELEASE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2009 22:31:31 -0000 --=-D0bQcSOzGXYMt3hJuZLW Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 2009-05-08 at 14:58 -0700, David Johnson wrote: > On Friday 08 May 2009 07:35:45 am Robert Noland wrote: > > I still can't reproduce this... I updated the Xserver, libGL and dri > > ports yesterday, all of which could be related to locking up the GPU an= d > > worth a shot. Failing that, I need you to enabled drm debugging. Start > > the system without X, kldload radeon.ko, set sysctl hw.dri.0.debug=3D1 > > then startx. >=20 > I've got all the updated ports as of last night, so that wasn't it. >=20 > I turned AIGLX back on, and it promptly locked up again. This time, howev= er, > the screen went black instead of freezing, but otherwise the same as alwa= ys. > I then turned on hw.dri.0.debug, and messages quickly filled up with the > following repeated message: >=20 > [drm:pid1195:drm_ioctl] returning 4 > [drm:pid1195:drm_ioctl] pid=3D1195, cmd=3D0x80046457, nr=3D0x57, dev 0xc6= 15fa00, auth=3D1 >=20 This is too late to really see anything... This still just suggests that the GPU is locked up. What is happening below is that we have emitted an "irq" to the card and we are waiting on it to parse that. The return value 4 is EINTR which says that we were interrupted while we were waiting. When we return EINTR, libdrm just performs the ioctl over again. We first read the register from the card to see if it has parsed at least up to what we are looking for, if so we just return success and don't sleep. If the register says that we haven't parsed the command, then we sleep for a max of 3 seconds waiting on the card to catch up. In your case, the card is never catching up, which suggests that the card is hung and not processing the command stream anymore.=20 static int radeon_wait_irq(struct drm_device * dev, int swi_nr) { drm_radeon_private_t *dev_priv =3D (drm_radeon_private_t *) dev->dev_private; int ret =3D 0; =20 if (RADEON_READ(RADEON_LAST_SWI_REG) >=3D swi_nr) return 0; dev_priv->stats.boxes |=3D RADEON_BOX_WAIT_IDLE; =20 DRM_WAIT_ON(ret, dev_priv->swi_queue, 3 * DRM_HZ, RADEON_READ(RADEON_LAST_SWI_REG) >=3D swi_nr); if (ret =3D=3D -ERESTART) DRM_DEBUG("restarting syscall"); return ret; } In order to guess what might be causing this, drm debugging needs to be enabled before the hang, so that we can hopefully figure out what leads up to the hung GPU. robert. --=20 Robert Noland FreeBSD --=-D0bQcSOzGXYMt3hJuZLW Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEABECAAYFAkoEsqgACgkQM4TrQ4qfROOaRQCcCJnWOQUp5M/COKSDS0g4Th8j qjsAnRBC7vRUfaHLh8UqLNcoKxLBD4gI =NtzA -----END PGP SIGNATURE----- --=-D0bQcSOzGXYMt3hJuZLW-- From owner-freebsd-stable@FreeBSD.ORG Sat May 9 07:38:52 2009 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D51B81065670 for ; Sat, 9 May 2009 07:38:52 +0000 (UTC) (envelope-from dwmalone@maths.tcd.ie) Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [IPv6:2001:770:10:300::86e2:510b]) by mx1.freebsd.org (Postfix) with SMTP id F37278FC14 for ; Sat, 9 May 2009 07:38:51 +0000 (UTC) (envelope-from dwmalone@maths.tcd.ie) Received: from walton.maths.tcd.ie ([134.226.81.10] helo=walton.maths.tcd.ie) by salmon.maths.tcd.ie with SMTP id ; 9 May 2009 08:38:50 +0100 (BST) Date: Sat, 9 May 2009 07:12:29 +0100 From: David Malone To: Eduardo Meyer Message-ID: <20090509061229.GA63615@walton.maths.tcd.ie> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i Sender: dwmalone@maths.tcd.ie Cc: stable@freebsd.org Subject: Re: "maxproc limit exceeded" making no sense X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 May 2009 07:38:53 -0000 On Fri, May 08, 2009 at 10:51:02AM -0300, Eduardo Meyer wrote: > However what I see regarding proc usage is by uid 82 is: > > # ps -U 82 | wc -l > 723 > > Proccess count for UID 82 is never highter than 913 (monitored the > last whole hour, while log messages were still showing, complaining > about maxproc limit beeing exceeded). I guess user 82 is exceeding their per-user process limit. This is set (traditionally) using the limit or ulimit shell builtins, but can also be configured in /etc/login.conf or by certain pam modules. I'd start with login.conf. David. From owner-freebsd-stable@FreeBSD.ORG Sat May 9 08:27:39 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 99BD0106564A; Sat, 9 May 2009 08:27:39 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mail.bsdforen.de (bsdforen.de [212.204.60.79]) by mx1.freebsd.org (Postfix) with ESMTP id 50AB88FC38; Sat, 9 May 2009 08:27:39 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mobileKamikaze.norad (unknown [88.130.192.63]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bsdforen.de (Postfix) with ESMTP id 279BE8A01A8; Sat, 9 May 2009 10:27:24 +0200 (CEST) Message-ID: <4A053E52.5030602@bsdforen.de> Date: Sat, 09 May 2009 10:26:58 +0200 From: Dominic Fandrey User-Agent: Thunderbird 2.0.0.21 (X11/20090408) MIME-Version: 1.0 To: Robert Noland References: <1238293386.00093672.1238281804@10.7.7.3> <49CF0803.1070505@FreeBSD.org> <49CF2F8D.6000905@bsdforen.de> <49CF4EB9.60108@FreeBSD.org> <49CF49F5.6010800@bsdforen.de> <49CF615A.6050304@FreeBSD.org> <49CF595A.30805@bsdforen.de> <49CF6B28.2080400@FreeBSD.org> <49CF60AB.4040709@bsdforen.de> <49CF6899.2060002@bsdforen.de> <49CF8E8D.1080604@bsdforen.de> <49CF9C19.3020509@FreeBSD.org> <49D5DA33.4010800@bsdforen.de> <1238778004.65025.30.camel@balrog.2hip.net> <49DF5D60.9010803@bsdforen.de> <1239384104.1922.70.camel@balrog.2hip.net> In-Reply-To: <1239384104.1922.70.camel@balrog.2hip.net> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Alexander Motin , freebsd-stable@freebsd.org Subject: Re: powerd broken X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 May 2009 08:27:39 -0000 Robert Noland wrote: > On Fri, 2009-04-10 at 16:53 +0200, Dominic Fandrey wrote: >> Robert Noland wrote: >>> I've been working on the Intel vblank / irq issues. Every time I commit >>> something thinking that I have it resolved, it isn't. So I'm waiting on >>> hardware to arrive that will let me test this all more thoroughly. I do >>> have a patch that I think fixes most of the issues on Intel, but the ddx >>> driver is still doing some silly things that cause issues in some cases. >>> I *think* the only outstanding issue I have with Intel is if something >>> is rendering (synced to vblank or not) when the display goes into dpms >>> sleep, there isn't anything to block that app, so it renders as hard as >>> it can even though it isn't being displayed. In reality, this probably >>> isn't a huge issue, but running gears while the display is asleep keeps >>> the cpu at 100%, which isn't ideal. Normal apps that aren't trying to >>> draw as fast as they can, shouldn't cause an issue. >> With the latest drm, the IRQ craziness is gone. However, the crappy >> performance remains. 2 months ago a RELENG_7 with all packages >> up to date yielded 124fps in a q3 timedemo that now yields 80fps. > > Things are still not quite right with the Intel driver. But performance > regressions are reported across Linux as well. A little of this might > be us, but most of it is Intel... > I don't know what you did with the last update, but performance is now better than ever (2% above what it used to be), which equels 3-4 more frames in ioQuake3 or 200 more in glxgears. The uptime of the notebook is now 15 hours and the interrupt load insignificant. I get no more than 8000 interrupts per seconds. 4000 of these are CPU timers (2000 for each core) and 1000 more are from my mouse, when I move it very fast. Around 2500 from vgapci, when I run glxgears and the rest is just scraps of whatever else is running (e.g. sound). Thanks a lot. Regards From owner-freebsd-stable@FreeBSD.ORG Sat May 9 12:07:16 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DEB5F106566B; Sat, 9 May 2009 12:07:16 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id AD8828FC17; Sat, 9 May 2009 12:07:16 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from [192.168.1.4] (adsl-154-182-184.bna.bellsouth.net [68.154.182.184]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id n49C78Ch002342 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 9 May 2009 08:07:08 -0400 (EDT) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Dominic Fandrey In-Reply-To: <4A053E52.5030602@bsdforen.de> References: <1238293386.00093672.1238281804@10.7.7.3> <49CF0803.1070505@FreeBSD.org> <49CF2F8D.6000905@bsdforen.de> <49CF4EB9.60108@FreeBSD.org> <49CF49F5.6010800@bsdforen.de> <49CF615A.6050304@FreeBSD.org> <49CF595A.30805@bsdforen.de> <49CF6B28.2080400@FreeBSD.org> <49CF60AB.4040709@bsdforen.de> <49CF6899.2060002@bsdforen.de> <49CF8E8D.1080604@bsdforen.de> <49CF9C19.3020509@FreeBSD.org> <49D5DA33.4010800@bsdforen.de> <1238778004.65025.30.camel@balrog.2hip.net> <49DF5D60.9010803@bsdforen.de> <1239384104.1922.70.camel@balrog.2hip.net> <4A053E52.5030602@bsdforen.de> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-7lYvHUPjFi8yZb42B3xx" Organization: FreeBSD Date: Sat, 09 May 2009 07:06:46 -0500 Message-Id: <1241870806.1733.61.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1.1 FreeBSD GNOME Team Port X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_PBL, RCVD_IN_SORBS_DUL,RDNS_DYNAMIC autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: Alexander Motin , freebsd-stable@freebsd.org Subject: Re: powerd broken X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 May 2009 12:07:17 -0000 --=-7lYvHUPjFi8yZb42B3xx Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Sat, 2009-05-09 at 10:26 +0200, Dominic Fandrey wrote: > Robert Noland wrote: > > On Fri, 2009-04-10 at 16:53 +0200, Dominic Fandrey wrote: > >> Robert Noland wrote: > >>> I've been working on the Intel vblank / irq issues. Every time I com= mit > >>> something thinking that I have it resolved, it isn't. So I'm waiting= on > >>> hardware to arrive that will let me test this all more thoroughly. I= do > >>> have a patch that I think fixes most of the issues on Intel, but the = ddx > >>> driver is still doing some silly things that cause issues in some cas= es. > >>> I *think* the only outstanding issue I have with Intel is if somethin= g > >>> is rendering (synced to vblank or not) when the display goes into dpm= s > >>> sleep, there isn't anything to block that app, so it renders as hard = as > >>> it can even though it isn't being displayed. In reality, this probab= ly > >>> isn't a huge issue, but running gears while the display is asleep kee= ps > >>> the cpu at 100%, which isn't ideal. Normal apps that aren't trying t= o > >>> draw as fast as they can, shouldn't cause an issue. > >> With the latest drm, the IRQ craziness is gone. However, the crappy > >> performance remains. 2 months ago a RELENG_7 with all packages > >> up to date yielded 124fps in a q3 timedemo that now yields 80fps. > >=20 > > Things are still not quite right with the Intel driver. But performanc= e > > regressions are reported across Linux as well. A little of this might > > be us, but most of it is Intel... > >=20 >=20 > I don't know what you did with the last update, but performance is now > better than ever (2% above what it used to be), which equels 3-4 more > frames in ioQuake3 or 200 more in glxgears. >=20 > The uptime of the notebook is now 15 hours and the interrupt load > insignificant. I get no more than 8000 interrupts per seconds. > 4000 of these are CPU timers (2000 for each core) and 1000 more are > from my mouse, when I move it very fast. Around 2500 from vgapci, when > I run glxgears and the rest is just scraps of whatever else is running > (e.g. sound). Which update, what? I haven't touched the kernel tree in a while, just trying to sort it all out with patches here and there. Are you saying the the 2.7.0 intel driver helped? Or maybe the Xserver or mesa updates? robert. > Thanks a lot. >=20 > Regards --=20 Robert Noland FreeBSD --=-7lYvHUPjFi8yZb42B3xx Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEUEABECAAYFAkoFcdYACgkQM4TrQ4qfROPdtgCXaZO9jXX7bQqq4F81LPKgyA+N lACeM0PrzpTeKRsqTm1XGESUbw92Rvo= =7tk2 -----END PGP SIGNATURE----- --=-7lYvHUPjFi8yZb42B3xx-- From owner-freebsd-stable@FreeBSD.ORG Sat May 9 13:10:36 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F61F106564A; Sat, 9 May 2009 13:10:36 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mail.bsdforen.de (bsdforen.de [212.204.60.79]) by mx1.freebsd.org (Postfix) with ESMTP id D72588FC20; Sat, 9 May 2009 13:10:35 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mobileKamikaze.norad (unknown [88.130.192.63]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bsdforen.de (Postfix) with ESMTP id 8B1078A0199; Sat, 9 May 2009 15:10:34 +0200 (CEST) Message-ID: <4A0580C9.6050902@bsdforen.de> Date: Sat, 09 May 2009 15:10:33 +0200 From: Dominic Fandrey User-Agent: Thunderbird 2.0.0.21 (X11/20090408) MIME-Version: 1.0 To: Robert Noland References: <1238293386.00093672.1238281804@10.7.7.3> <49CF0803.1070505@FreeBSD.org> <49CF2F8D.6000905@bsdforen.de> <49CF4EB9.60108@FreeBSD.org> <49CF49F5.6010800@bsdforen.de> <49CF615A.6050304@FreeBSD.org> <49CF595A.30805@bsdforen.de> <49CF6B28.2080400@FreeBSD.org> <49CF60AB.4040709@bsdforen.de> <49CF6899.2060002@bsdforen.de> <49CF8E8D.1080604@bsdforen.de> <49CF9C19.3020509@FreeBSD.org> <49D5DA33.4010800@bsdforen.de> <1238778004.65025.30.camel@balrog.2hip.net> <49DF5D60.9010803@bsdforen.de> <1239384104.1922.70.camel@balrog.2hip.net> <4A053E52.5030602@bsdforen.de> <1241870806.1733.61.camel@balrog.2hip.net> In-Reply-To: <1241870806.1733.61.camel@balrog.2hip.net> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Alexander Motin , freebsd-stable@freebsd.org Subject: Re: powerd broken X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 May 2009 13:10:36 -0000 Robert Noland wrote: > On Sat, 2009-05-09 at 10:26 +0200, Dominic Fandrey wrote: >> Robert Noland wrote: >>> On Fri, 2009-04-10 at 16:53 +0200, Dominic Fandrey wrote: >>>> Robert Noland wrote: >>>>> I've been working on the Intel vblank / irq issues. Every time I commit >>>>> something thinking that I have it resolved, it isn't. So I'm waiting on >>>>> hardware to arrive that will let me test this all more thoroughly. I do >>>>> have a patch that I think fixes most of the issues on Intel, but the ddx >>>>> driver is still doing some silly things that cause issues in some cases. >>>>> I *think* the only outstanding issue I have with Intel is if something >>>>> is rendering (synced to vblank or not) when the display goes into dpms >>>>> sleep, there isn't anything to block that app, so it renders as hard as >>>>> it can even though it isn't being displayed. In reality, this probably >>>>> isn't a huge issue, but running gears while the display is asleep keeps >>>>> the cpu at 100%, which isn't ideal. Normal apps that aren't trying to >>>>> draw as fast as they can, shouldn't cause an issue. >>>> With the latest drm, the IRQ craziness is gone. However, the crappy >>>> performance remains. 2 months ago a RELENG_7 with all packages >>>> up to date yielded 124fps in a q3 timedemo that now yields 80fps. >>> Things are still not quite right with the Intel driver. But performance >>> regressions are reported across Linux as well. A little of this might >>> be us, but most of it is Intel... >>> >> I don't know what you did with the last update, but performance is now >> better than ever (2% above what it used to be), which equels 3-4 more >> frames in ioQuake3 or 200 more in glxgears. >> >> The uptime of the notebook is now 15 hours and the interrupt load >> insignificant. I get no more than 8000 interrupts per seconds. >> 4000 of these are CPU timers (2000 for each core) and 1000 more are >> from my mouse, when I move it very fast. Around 2500 from vgapci, when >> I run glxgears and the rest is just scraps of whatever else is running >> (e.g. sound). > > Which update, what? I haven't touched the kernel tree in a while, just > trying to sort it all out with patches here and there. Are you saying > the the 2.7.0 intel driver helped? Or maybe the Xserver or mesa > updates? I update my ports daily, without really looking at what. I think xorg-server was one of them. It must have been something that happened during the last 48 hours. > robert. > >> Thanks a lot. >> >> Regards From owner-freebsd-stable@FreeBSD.ORG Sat May 9 13:14:06 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9CAD21065670; Sat, 9 May 2009 13:14:06 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id 69D998FC12; Sat, 9 May 2009 13:14:06 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from [192.168.1.4] (adsl-154-182-184.bna.bellsouth.net [68.154.182.184]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id n49DDwVJ002632 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 9 May 2009 09:13:59 -0400 (EDT) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Dominic Fandrey In-Reply-To: <4A0580C9.6050902@bsdforen.de> References: <1238293386.00093672.1238281804@10.7.7.3> <49CF0803.1070505@FreeBSD.org> <49CF2F8D.6000905@bsdforen.de> <49CF4EB9.60108@FreeBSD.org> <49CF49F5.6010800@bsdforen.de> <49CF615A.6050304@FreeBSD.org> <49CF595A.30805@bsdforen.de> <49CF6B28.2080400@FreeBSD.org> <49CF60AB.4040709@bsdforen.de> <49CF6899.2060002@bsdforen.de> <49CF8E8D.1080604@bsdforen.de> <49CF9C19.3020509@FreeBSD.org> <49D5DA33.4010800@bsdforen.de> <1238778004.65025.30.camel@balrog.2hip.net> <49DF5D60.9010803@bsdforen.de> <1239384104.1922.70.camel@balrog.2hip.net> <4A053E52.5030602@bsdforen.de> <1241870806.1733.61.camel@balrog.2hip.net> <4A0580C9.6050902@bsdforen.de> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-tH3pDxOEQHJPlcDA+LwW" Organization: FreeBSD Date: Sat, 09 May 2009 08:13:37 -0500 Message-Id: <1241874817.71435.1.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1.1 FreeBSD GNOME Team Port X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_PBL, RCVD_IN_SORBS_DUL,RDNS_DYNAMIC autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: Alexander Motin , freebsd-stable@freebsd.org Subject: Re: powerd broken X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 May 2009 13:14:07 -0000 --=-tH3pDxOEQHJPlcDA+LwW Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Sat, 2009-05-09 at 15:10 +0200, Dominic Fandrey wrote: > Robert Noland wrote: > > On Sat, 2009-05-09 at 10:26 +0200, Dominic Fandrey wrote: > >> Robert Noland wrote: > >>> On Fri, 2009-04-10 at 16:53 +0200, Dominic Fandrey wrote: > >>>> Robert Noland wrote: > >>>>> I've been working on the Intel vblank / irq issues. Every time I c= ommit > >>>>> something thinking that I have it resolved, it isn't. So I'm waiti= ng on > >>>>> hardware to arrive that will let me test this all more thoroughly. = I do > >>>>> have a patch that I think fixes most of the issues on Intel, but th= e ddx > >>>>> driver is still doing some silly things that cause issues in some c= ases. > >>>>> I *think* the only outstanding issue I have with Intel is if someth= ing > >>>>> is rendering (synced to vblank or not) when the display goes into d= pms > >>>>> sleep, there isn't anything to block that app, so it renders as har= d as > >>>>> it can even though it isn't being displayed. In reality, this prob= ably > >>>>> isn't a huge issue, but running gears while the display is asleep k= eeps > >>>>> the cpu at 100%, which isn't ideal. Normal apps that aren't trying= to > >>>>> draw as fast as they can, shouldn't cause an issue. > >>>> With the latest drm, the IRQ craziness is gone. However, the crappy > >>>> performance remains. 2 months ago a RELENG_7 with all packages > >>>> up to date yielded 124fps in a q3 timedemo that now yields 80fps. > >>> Things are still not quite right with the Intel driver. But performa= nce > >>> regressions are reported across Linux as well. A little of this migh= t > >>> be us, but most of it is Intel... > >>> > >> I don't know what you did with the last update, but performance is now > >> better than ever (2% above what it used to be), which equels 3-4 more > >> frames in ioQuake3 or 200 more in glxgears. > >> > >> The uptime of the notebook is now 15 hours and the interrupt load > >> insignificant. I get no more than 8000 interrupts per seconds. > >> 4000 of these are CPU timers (2000 for each core) and 1000 more are > >> from my mouse, when I move it very fast. Around 2500 from vgapci, when > >> I run glxgears and the rest is just scraps of whatever else is running > >> (e.g. sound). > >=20 > > Which update, what? I haven't touched the kernel tree in a while, just > > trying to sort it all out with patches here and there. Are you saying > > the the 2.7.0 intel driver helped? Or maybe the Xserver or mesa > > updates? >=20 > I update my ports daily, without really looking at what. I think > xorg-server was one of them. It must have been something that happened > during the last 48 hours. Ok, well server, mesa and intel driver all got updates in my sweep the other day. robert. > > robert. > >=20 > >> Thanks a lot. > >> > >> Regards >=20 --=20 Robert Noland FreeBSD --=-tH3pDxOEQHJPlcDA+LwW Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEABECAAYFAkoFgYEACgkQM4TrQ4qfROOq2wCfTUZFvywiqMiwkWUb++/+JMcR OBEAniwt6Ben4nOaAc7TeQQfmLRLt65E =ZMVU -----END PGP SIGNATURE----- --=-tH3pDxOEQHJPlcDA+LwW-- From owner-freebsd-stable@FreeBSD.ORG Sat May 9 19:40:33 2009 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2C72A106566B for ; Sat, 9 May 2009 19:40:33 +0000 (UTC) (envelope-from so14k@valentine.liquidneon.com) Received: from valentine.liquidneon.com (valentine.liquidneon.com [216.87.78.132]) by mx1.freebsd.org (Postfix) with ESMTP id 49DD98FC14 for ; Sat, 9 May 2009 19:40:32 +0000 (UTC) (envelope-from so14k@valentine.liquidneon.com) Received: by valentine.liquidneon.com (Postfix, from userid 1018) id 070CA8FE62; Sat, 9 May 2009 13:12:54 -0600 (MDT) Date: Sat, 9 May 2009 13:12:53 -0600 From: Brad Davis To: freebsd-hackers@FreeBSD.org Message-ID: <20090509191253.GD40521@valentine.liquidneon.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: FreeBSD Status Reports January - March, 2009 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 May 2009 19:40:34 -0000 FreeBSD Quarterly Status Report Introduction Since the last Status Reports there has been interesting progress in FreeBSD Development. FreeBSD 7.2 was released just a few days ago. Some of the highlights include: Support for superpages in the FreeBSD Virtual Memory subsystem. The FreeBSD Kernel Virtual Address space has been increased to 6GB on amd64. An updated jail(8) subsystem that supports multi-IPv4/IPv6/noIP and much more. Lots of FreeBSD Developers are in Ottawa, Canada attending the FreeBSD Developer Summit that is before BSDCan. BSDCan officially starts tomorrow and should cover lots of interesting topics, see the BSDCan Website for more information. Thanks to all the reporters for the excellent work! We hope you enjoy reading. __________________________________________________________________ Projects * Clang replacing GCC in the base system * Device mmap() Extensions * OpenBSM * Release Engineering * Sysinfo - a set of scripts which document your system * TrustedBSD MAC Framework in GENERIC * VFS/NFS DTrace Probes * VirtualBox on FreeBSD FreeBSD Team Reports * FreeBSD BugBusting Team Architectures * FreeBSD/powerpc G5 Support * FreeBSD/sparc64 UltraSPARC III support Documentation * Dutch Documentation Project * German Documentation Project * Hungarian Documentation Project Google Summer of Code * BSD-licensed text-processing tools __________________________________________________________________ BSD-licensed text-processing tools URL: http://perforce.freebsd.org/depotTreeBrowser.cgi?FSPC=//depot/projects/ soc2008/gabor_textproc Contact: Gábor Kövesdán Currently, grep is finished and is only waiting for a portbuild test. It is known to be more or less feature complete, while it is much smaller than the GNU version. As for sort, there has been some progress with the complete rewrite and it is lacking few options. Performance is to be measured, as well. Open tasks: 1. Test grep on pointyhat. 2. Complete sort with the missing features. 3. Do performance measurements for sort and look for possible optimization opportunities. 4. Test sort on pointyhat. __________________________________________________________________ Clang replacing GCC in the base system URL: http://wiki.freebsd.org/BuildingFreeBSDWithClang URL: http://git.hoeg.nl/?p=llvm-bmake URL: http://clang.llvm.org/ Contact: Ed Schouten Contact: Roman Divacky Contact: Brooks Davis Contact: Pawel Worach The last 3-4 months we've been working together with the LLVM developers to discuss any bugs and issues we are experiencing with their Clang compiler frontend. The FreeBSD project is looking at the possibility to replace GCC with Clang as a system compiler. It can compile 99% of the FreeBSD world and can compile booting kernel on i386/amd64 but it still contains bugs and its C++ support is still immature. Ed is maintaining a patchset for the FreeBSD sources to replace cc(1) by a Clang binary and bootstrap almost all sources with the Clang compiler. The LLVM developers are very helpful fixing most of the bugs we've reported (over 100). Unfortunately we are currently blocked on some bug reports that prevent us from building libc, libm, libcrypto and various CDDL libraries with Clang but the FreeBSD kernel itself compiles and boots. Open tasks: 1. Testing Clang with compilation of various applications and reporting bugs. 2. Testing the llvm-bmake branch to find more bugs. 3. Arranging an experimental ports build. __________________________________________________________________ Device mmap() Extensions URL: http://www.FreeBSD.org/~jhb/pat/ Contact: John Baldwin GPU device drivers are increasingly requiring more sophisticated support for mapping objects into both userland and the kernel. For example, memory used for textures often needs to be mapped Write-Combining rather than Write-Back. I have recently created three patches to provide several extensions. The first patch allows device drivers to use a different VM object to back specific mmap() calls instead of always using the device pager. The second patch introduces a new VM object type that can map an arbitrary set of physical address ranges. This can be used to let userland mmap PCI BARs, etc. The third patch allows memory mappings to use different caching modes (e.g. Write-Combining or Uncacheable). Together I believe these patches provide the remaining pieces needed for an Nvidia amd64 driver. They will also be useful for future Xorg DRM support as well. The current set of patches can be safely merged back to 7.x as well. Currently I am waiting for review and feedback from several folks. I am hopeful that these patches will be in HEAD soon, prior to the 8.0 freeze. __________________________________________________________________ Dutch Documentation Project URL: http://wiki.freebsd.org/DutchDocumentationProject URL: http://www.freebsd.org/doc/nl/ URL: http://p4web.freebsd.org/@md=d&cd=//&c=pFl@//depot/projects/docproj_nl/ ?ac=83 Contact: Remko Lodder Contact: René Ladan The FreeBSD Dutch Documentation Project is an ongoing project to translate FreeBSD Documentation into the Dutch language. The translation of the Handbook was completed last January. It is kept up-to-date with the English version. Furthermore five articles and the flyer have been translated. Some initial work has been done to translate the website, but most likely more translators are needed to fully realize it. Open tasks: 1. Recruit more translators. 2. Keep the translations up-to-date with the English versions. 3. Finish the translation of the FAQ. 4. Translate more articles and maybe some books. __________________________________________________________________ FreeBSD BugBusting Team URL: http://www.FreeBSD.org/support.html#gnats URL: http://wiki.FreeBSD.org/BugBusting URL: http://people.FreeBSD.org/~linimon/studies/prs/ URL: http://people.freebsd.org/~linimon/studies/prs/recommended_prs.html Contact: Mark Linimon Contact: Remko Lodder We continue to classify PRs as they arrive, with 'tags' corresponding to the kernel subsystem, or man page references for userland PRs. These tags, in turn, produce lists of PRs sorted both by tag and by manpage Mark Linimon (linimon@) has created special reports for the Release Engineering Team to help focus on regressions and other areas of interest relating to the release of FreeBSD 7.2 in the coming weeks. This is a refinement of the 'customized reports for developers' announced in the last status report. A full list of all the automatically generated reports is also available. Any recommendations for reports which do not currently exist but which would be beneficial are welcomed. Mark Linimon also continues attempting to define the general problem and investigating possible new work flow models, and will be presenting on the subject at BSDCan. The list of PRs recommended for committer evaluation by the BugBusting team continues to receive new additions. This list contains PRs, mostly with patches, that the BugBusting team feel are probably ready to be committed as-is, or are probably trivially resolved in the hands of a committer with knowledge of the particular subsystem. All committers are invited to take a look at this list whenever they have a spare 5 minutes and wish to close a PR. Since the last status report, the number of open bugs continued to hover around the 5600 mark, although has began to rise with the 7.2 ports freeze. As always, more help is appreciated, and committers and non-committers alike are invited to join us on #freebsd-bugbusters on EFnet and help close stale PRs or commit patches from valid PRs. Open tasks: 1. Try to find ways to get more committers helping us with closing PRs that the team has already analyzed. 2. Think of some way for committers to only view PRs that have been in some way 'vetted' or 'confirmed'. 3. Generate more publicity for what we've already got in place, and for what we intend to do next. 4. Define new categories, classifications, and states for PRs, that will better match our work flow (in progress). __________________________________________________________________ FreeBSD/powerpc G5 Support Contact: Nathan Whitehorn FreeBSD 8.0-CURRENT now has support for PowerPC CPUs operating in the 64-bit bridge mode. This includes the PowerPC 970 (G5) as well as the POWER3 and POWER4. Currently only Apple systems are known to work. Open tasks: 1. IBM systems currently are not supported due to missing northbridge support. 2. Software fan control on SMU-based Apple G5 systems (G5 iMac, later Powermac G5) is not available. __________________________________________________________________ FreeBSD/sparc64 UltraSPARC III support Contact: Marius Strobl Like announced in the previous status report, support for sun4u-machines based on UltraSPARC III and beyond has been MFC'ed to stable/7 (the last missing piece was r190297) and thus will be present in the upcoming 7.2-RELEASE and can be already tested with 7.2-RC1. Additionally, as of r191076 machfb(4) has been fixed to work with UltraSPARC III and beyond, that fix unfortunately did not make it into 7.2-RC1 but will be in the final version. The X.Org 7.4 and Firefox ports as well as some other gecko-based ones like Seamonkey once again have been fixed to also work and package on sparc64, including on UltraSPARC III and UltraSPARC IIIi based machines equipped with cards driven by creator(4) or machfb(4). The driver for the Sun Cassini/Cassini+ as well as National Semiconductor DP83065 Saturn Gigabit NICs found on-board for example in Fire V440 and as add-on cards is coming along nicely, the last thing which needs to be implemented before it can hit CURRENT is support for jumbo frames. __________________________________________________________________ German Documentation Project URL: https://doc.bsdgroup.de Contact: Johann Kois Contact: Martin Wilke In February 2009 the German version of the FreeBSD Developer's handbook went online. Additionally we managed to update large areas of the FAQ thanks to the contributions of Benedict Reuschling. The website (at least the areas we see as relevant for a translation) is translated and updated constantly. More volunteers are always welcome of course, as there is still plenty of work to be done. Open tasks: 1. Update the existing documentation set (especially the handbook). 2. Read the translations. Check for problems/mistakes. Send feedback. __________________________________________________________________ Hungarian Documentation Project URL: http://www.FreeBSD.org/hu URL: http://www.FreeBSD.org/doc/hu URL: http://wiki.FreeBSD.org/HungarianDocumentationProject URL: http://p4web.freebsd.org/@md=d&cd=//depot/projects/docproj_hu/&c=aXw@// depot/projects/docproj_hu/?ac=83 Contact: Gábor Kövesdán Contact: Gábor Páli We are proud to announce that the FreeBSD Hungarian web pages have been extended by the following items: * Project news entries, staring from 2009 (HTML, RSS, RDF) * Press releases, starting from 2008 (HTML, RSS) * Events, starting from 2009 (HTML, RSS) * Security advisories (HTML, RSS) We are still hoping that having the FDP Primer translated will encourage others to help our work. Feel free to contribute, every submitted line of translation or feedback is appreciated and is highly welcome. For more information on how to contribute, please read the project's introduction (in Hungarian). Open tasks: 1. Translate news entries, press releases. 2. Translate Release Notes for -CURRENT and 8.X. 3. Translate articles. 4. Translate web pages. 5. Read the translations, send feedback. __________________________________________________________________ OpenBSM URL: http://www.openbsm.org/ Contact: Robert Watson Contact: TrustedBSD audit mailing list The TrustedBSD Project has now released OpenBSM 1.1, the second production release of the OpenBSM code base. OpenBSM 1.1 has been merged to FreeBSD 8-CURRENT, and will be merged to 7-STABLE before FreeBSD 7.3. Major changes since OpenBSM 1.0 include: * Trail files now include the host where the trail is generated. Crash recovery has been improved. Trail expiration based on size and date is now supported; by default trail files will be expired after 10MB of trails. The default individual trail limit is now 2MB. * Mac OS X Snow Leopard is now a fully supported platform; launchd(8) can now be used to launchd auditd(8). Command line tools and libraries are now supported on Mac OS X Leopard. * Extended header tokens are now supported, allowing audit trails to be tagged with a host identifier. IPv6 addresses are now supported in subject tokens. BSM token and record types have been further synchronized to OpenSolaris; support for many new system calls has been added. Local errors and socket types are mapped to and from BSM values. Since the last test release, OpenBSM 1.1 beta 1, 32/64-bit compatibility has been fixed for the auditon(2) system call. A default "expire-after" of 10MB is now set in audit_control(5). Local fcntl(2) arguments are now mapped to wire BSM versions using new APIs. The audit_submit(3) man page has been fixed. A new audit event class has been added for post-login authentication and access control events. Open tasks: 1. Migrate to sbufs in token-encoding. 2. Support for auditing NFS RPCs. __________________________________________________________________ Release Engineering URL: http://www.FreeBSD.org/releng/ Contact: Release Engineering Team The Release Engineering Team (with lots of help from lots of other people) released FreeBSD 7.2 on May 4th, 2009. During this period we have also begun reminding developers of the upcoming FreeBSD 8.0 release cycle which is scheduled to begin in early June 2009 with release targeted at early September 2009. __________________________________________________________________ Sysinfo - a set of scripts which document your system URL: http://danger.rulez.sk/index.php/2009/04/14/sysinfo-a-set-of-scripts-wh ich-document-your-freebsd-system/ URL: https://forums.freebsd.org/showthread.php?p=19321 Contact: Daniel Gerzo Sysinfo a shell script which purpose is to automatically gather system information and document hardware and software configuration of the given host system. The goal is to provide a system operator with descriptive information about an unknown FreeBSD installation. It consists of several modules (also shell scripts), thus is easily extensible and provides an easy way to inspect overall system configuration. It has been written as part of my Bachelor thesis and its development is a work in progress. Therefore, I would appreciate if you could provide me with some feedback as I will defend my thesis soon. Your feedback is welcome at the forums , or alternatively you can send me a private email. The tool itself can now be installed using the Ports tree from the sysutils/sysinfo port. Open tasks: 1. Receive additional feedback. 2. Perform more testing. 3. Extend and improve the tool. __________________________________________________________________ TrustedBSD MAC Framework in GENERIC URL: http://www.trustedBSD.org/mac.html Contact: Robert Watson Contact: TrustedBSD discussion mailing list There is on-going work to allow "options MAC" to be included in the GENERIC kernel for 8.0. This primarily consists of performance work to reduce overhead when policies are used, and eliminate when none are configured. Work to date includes: * The MAC Framework now detects which object types are labeled by policies, and MAC label storage is not allocated when it won't be used. * Add MAC Framework DTrace probes so allow more easy analysis of MAC Framework and policy interactions. * Eliminate mutex-protected reference count used to prevent module unload during entry point invocation, and replace with an sx lock and an rwlock, respectively for long-sleepable and short-sleepable entry points, significantly lowering the overhead of entering the MAC Framework. If no dynamic policies are loaded, no locking overhead is taken. Open tasks: 1. Move to rmlocks for non-sleepable entry points to reduce cache line thrashing under load. 2. Macroize invocation of MAC Framework entry points from the kernel, and perform caller-side determination of whether MAC is enabled in order to avoid additional function call overhead in the caller path if MAC is disabled. __________________________________________________________________ VFS/NFS DTrace Probes Contact: Robert Watson A new DTrace provider, dtnfsclient, has been added to the FreeBSD 8.x kernel, and will be merged to 7.x before 7.3. The following probes are available: * nfsclient:{nfs2,nfs3}:{procname}:start - NFSv2 and NFSv3 RPC start probes * nfsclient:{nfs2,nfs3}:{procname}:done - NFSv2 and NFSv3 RPC done probes * nfsclient:accesscache:: - NFS access cache flush/hit/miss/load probes * nfsclient:attrcache:: - NFS attribute cache flush/hit/miss/done In addition, a number of VFS probes have been added: * vfs:vop:{vopname}:entry - VOP entry probe * vfs:vop:{vopname}:return - VOP return probe * vfs:namei:lookup:entry - VFS name lookup entry probe * vfs:namei:lookup:return - VFS name lookup return probe * vfs:namecache:*:* - VFS namecache enter/enter_negative/fullpath_enter/fullpath_hit/fullpath_miss/full path_return/lookup_hit/lookup_hit_negative/lookup_miss/purge/purge_ negative/purgevfs/zap/zap_negative probes These probes make it much easier to trace NFS and VFS events. Open tasks: 1. Add VFSOP tracing. 2. Add RPC-layer tracing, such as RPC retransmits. 3. Provide decoded NFS RPCs in order to expose transaction IDs and file handles. __________________________________________________________________ VirtualBox on FreeBSD URL: http://miwi.bsdcrew.de/2009/05/virtualbox-on-freebsd/ URL: http://miwi.bsdcrew.de/2009/05/virtualbox-on-freebsd-first-screenshots/ URL: http://vbox.innotek.de/pipermail/vbox-dev/2009-May/001369.html Contact: Beat Gaetzi Contact: Bernhard Froehlich Contact: Dennis Herrmann Contact: Martin Wilke After the first mail from Alexander Eichner on the vbox-dev mailinglist, we started the work on a VirtualBox port. 6 Days was needed to get VirtualBox to start with over 20 patches. We'd like to say thanks to Alexander Eichner, all the VirtualBox Developers, Gustau Perez and Ulf Lilleengen. If you like to play with the current port you can checkout the port here. Please do not ping us about any problems, we know about a lot and are still working to get them all solved before we do an official call for testing. Open tasks: 1. Fix kernel crashes on 7.2-RELEASE. 2. Code cleanup. 3. Fix errors on AMD64. 4. Fix user/permission problems. From owner-freebsd-stable@FreeBSD.ORG Sat May 9 22:43:18 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 87883106564A for ; Sat, 9 May 2009 22:43:18 +0000 (UTC) (envelope-from scrappy@hub.org) Received: from hub.org (hub.org [200.46.204.220]) by mx1.freebsd.org (Postfix) with ESMTP id 2BA168FC14 for ; Sat, 9 May 2009 22:43:18 +0000 (UTC) (envelope-from scrappy@hub.org) Received: from localhost (maia-1.hub.org [200.46.208.211]) by hub.org (Postfix) with ESMTP id 9B5A953BC88; Sat, 9 May 2009 19:43:17 -0300 (ADT) Received: from hub.org ([200.46.204.220]) by localhost (mx1.hub.org [200.46.208.211]) (amavisd-maia, port 10024) with ESMTP id 31984-03; Sat, 9 May 2009 19:43:10 -0300 (ADT) Received: by hub.org (Postfix, from userid 1002) id 8CE9D53BC73; Sat, 9 May 2009 19:43:16 -0300 (ADT) Received: from localhost (localhost [127.0.0.1]) by hub.org (Postfix) with ESMTP id 8BA8A53BC63; Sat, 9 May 2009 19:43:16 -0300 (ADT) Date: Sat, 9 May 2009 19:43:16 -0300 (ADT) From: "Marc G. Fournier" To: Gavin Atkinson In-Reply-To: <1240920035.85945.7.camel@buffy.york.ac.uk> Message-ID: <20090509193937.T10574@hub.org> References: <1240920035.85945.7.camel@buffy.york.ac.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Martin Schmidt , freebsd-stable@FreeBSD.org Subject: RE: 7.1-STABLE Sun Mar 29 01:06:46 ADT 2009 Locks up ... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 May 2009 22:43:18 -0000 On Tue, 28 Apr 2009, Gavin Atkinson wrote: > On Fri, 2009-04-24 at 20:39 +0200, Martin Schmidt wrote: >> Hi Marc and List, >> >> i had similar issues with FreeBSD 7.2-PRERELEASE. Server (zfs,nfs) >> seems to hang in intervals of about 8 hours. >> kernel is still there but no connections can be made to nfs/ssh and >> login on local console doesn't seem to >> work due to incredible slowness. breaking to the debugger takes a >> moment but works. >> (compiling kernel with WITNESS didnt help) >> >> the server had been solid before with 7 stable kernel from around 19 >> October 2008. >> >> I now added these lines to /boot/loader.conf >> >> hw.pci.enable_msi=0 >> hw.pci.enable_msix=0 >> >> to disable Message Signaled Interrupts. Which are used by the 3ware >> twa driver and igb network driver on our server. > > If you are willing to test further on your server, it may be helpful if > you could determine which of those two lines in loader.conf fixes the > problem for you. It would also be useful to provide a dmesg from the > machine when both msi and msix are enabled. > > FWIW, looking at the "vmstat -i" output it appears that only the igb > driver that are using MSI/MSIX, unless you have a reason to suspect > otherwise? How do you tell that, about igb? looking at the server I have the igb device on, it doesn't seem to say anything about that ... # vmstat -i interrupt total rate irq1: atkbd0 162 0 irq30: twa0 402647215 187 cpu0: timer 4284778818 1999 irq256: igb0 1282945461 598 irq257: igb0 215507100 100 irq258: igb0 417702261 194 irq259: igb0 314601966 146 irq260: igb0 568062067 265 irq261: igb0 3 0 cpu5: timer 4284744445 1999 cpu6: timer 4284731466 1999 cpu7: timer 4284724508 1999 cpu1: timer 4284893874 1999 cpu3: timer 4284899807 1999 cpu2: timer 4284892325 1999 cpu4: timer 4284897264 1999 Total 37480028742 17493 The server(s) that I am experiencing the hangs on, vmstat -i shows: # vmstat -i interrupt total rate irq1: atkbd0 2 0 irq3: sio1 8 0 irq25: bge0 4614816 213 irq72: ciss0 1835763 85 cpu0: timer 43113685 1997 cpu1: timer 43116889 1997 Total 92681163 4293 Are any of these similiarly using MSI/MSIX? ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . scrappy@hub.org MSN . scrappy@hub.org Yahoo . yscrappy Skype: hub.org ICQ . 7615664 From owner-freebsd-stable@FreeBSD.ORG Sat May 9 23:17:14 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 382D21065676; Sat, 9 May 2009 23:17:14 +0000 (UTC) (envelope-from scrappy@hub.org) Received: from hub.org (hub.org [200.46.204.220]) by mx1.freebsd.org (Postfix) with ESMTP id 015518FC1E; Sat, 9 May 2009 23:17:13 +0000 (UTC) (envelope-from scrappy@hub.org) Received: from maia.hub.org (maia-4.hub.org [200.46.204.183]) by hub.org (Postfix) with ESMTP id 9498053BC8F; Sat, 9 May 2009 20:17:13 -0300 (ADT) Received: from hub.org ([200.46.204.220]) by maia.hub.org (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 90672-08; Sat, 9 May 2009 20:17:12 -0300 (ADT) Received: by hub.org (Postfix, from userid 1002) id 1FA9F53BC89; Sat, 9 May 2009 20:17:13 -0300 (ADT) Received: from localhost (localhost [127.0.0.1]) by hub.org (Postfix) with ESMTP id 1E3CA53BC6D; Sat, 9 May 2009 20:17:13 -0300 (ADT) Date: Sat, 9 May 2009 20:17:12 -0300 (ADT) From: "Marc G. Fournier" To: Gavin Atkinson In-Reply-To: <1240920035.85945.7.camel@buffy.york.ac.uk> Message-ID: <20090509201505.R10574@hub.org> References: <1240920035.85945.7.camel@buffy.york.ac.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Martin Schmidt , freebsd-stable@FreeBSD.org Subject: RE: 7.1-STABLE Sun Mar 29 01:06:46 ADT 2009 Locks up ... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 May 2009 23:17:14 -0000 'k, based on grep'ng the source files, turns out that the if_bge device driver uses msi, while, as you point out, the igb uses msix ... I have disabled msi on the two servers with bge devices, and msix on the one with igb ... all three have given the same sort of problem after varying periods of time ... let's see if I can get to 30 days uptime with this ... On Tue, 28 Apr 2009, Gavin Atkinson wrote: > On Fri, 2009-04-24 at 20:39 +0200, Martin Schmidt wrote: >> Hi Marc and List, >> >> i had similar issues with FreeBSD 7.2-PRERELEASE. Server (zfs,nfs) >> seems to hang in intervals of about 8 hours. >> kernel is still there but no connections can be made to nfs/ssh and >> login on local console doesn't seem to >> work due to incredible slowness. breaking to the debugger takes a >> moment but works. >> (compiling kernel with WITNESS didnt help) >> >> the server had been solid before with 7 stable kernel from around 19 >> October 2008. >> >> I now added these lines to /boot/loader.conf >> >> hw.pci.enable_msi=0 >> hw.pci.enable_msix=0 >> >> to disable Message Signaled Interrupts. Which are used by the 3ware >> twa driver and igb network driver on our server. > > If you are willing to test further on your server, it may be helpful if > you could determine which of those two lines in loader.conf fixes the > problem for you. It would also be useful to provide a dmesg from the > machine when both msi and msix are enabled. > > FWIW, looking at the "vmstat -i" output it appears that only the igb > driver that are using MSI/MSIX, unless you have a reason to suspect > otherwise? > > Gavin > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . scrappy@hub.org MSN . scrappy@hub.org Yahoo . yscrappy Skype: hub.org ICQ . 7615664