From owner-freebsd-current@FreeBSD.ORG Sun May 9 01:33:16 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5A14F106564A for ; Sun, 9 May 2010 01:33:16 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id AB4368FC08 for ; Sun, 9 May 2010 01:33:15 +0000 (UTC) Received: by fxm15 with SMTP id 15so1851351fxm.13 for ; Sat, 08 May 2010 18:33:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=rY6lUUHFc3KGBYCkHZ16S49yKI+e1wfJ0tQPgEOlHWI=; b=rP2t+OMgOEPo/YQSbvtc6mp0P2B3YRqVcKtgMr7p9gcksSBpokIXNw9+c3B70ZRUPv 0HB9MTi6h9KNQH8CwwhywSg+0EaUkiud5fJ3JqCqRLm9C31zraWWPNXWCZM+VpX9XDyJ APz0MdOal+HMVx78RT39yxkPoNPtZWrO15hZ0= 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 :content-transfer-encoding; b=lBmHZhPjQ1rMM5+2DYZsRmhHR1y9p5NFFT5+x72yB1FCa93CRQG9BbvmSnZV54yZJn 9tIV8QPxcMNWRRXT59R5bv5NGw5aCZ0zFIjq1Kyy258Ua1UB57/0NW32xrk2i+7Yc5kT dO+bu3BRIKiKpAvkErBNp6F72hAeWWUpWLQgU= MIME-Version: 1.0 Received: by 10.239.193.74 with SMTP id h10mr203909hbi.115.1273368794157; Sat, 08 May 2010 18:33:14 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.239.129.207 with HTTP; Sat, 8 May 2010 18:33:14 -0700 (PDT) In-Reply-To: References: <20100508102005.GB1867@elmar.spoerlein.net> <20100508155127.GC1867@elmar.spoerlein.net> <20100508174838.GJ88504@acme.spoerlein.net> Date: Sun, 9 May 2010 03:33:14 +0200 X-Google-Sender-Auth: 57c25b4b02cf1c2c Message-ID: From: Attilio Rao To: Jeff Roberson Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Cc: current@freebsd.org Subject: Re: LOR: ufs vs bufwait X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 May 2010 01:33:16 -0000 MjAxMC81LzkgSmVmZiBSb2JlcnNvbiA8anJvYmVyc29uQGpyb2JlcnNvbi5uZXQ+Ogo+IE9uIFNh dCwgOCBNYXkgMjAxMCwgVWxyaWNoIFNwP3JsZWluIHdyb3RlOgo+Cj4+IE9uIFNhdCwgMDguMDUu MjAxMCBhdCAxODowMDo1MCArMDIwMCwgQXR0aWxpbyBSYW8gd3JvdGU6Cj4+Pgo+Pj4gMjAxMC81 LzggVWxyaWNoIFNwP3JsZWluIDx1cXNAc3BvZXJsZWluLm5ldD46Cj4+Pj4KPj4+PiBPbiBTYXQs IDA4LjA1LjIwMTAgYXQgMTI6MjA6MDUgKzAyMDAsIFVscmljaCBTcD9ybGVpbiB3cm90ZToKPj4+ Pj4KPj4+Pj4gVGhpcyBMT1IgYWxzbyBpcyBub3QgeWV0IGxpc3RlZCBvbiB0aGUgTE9SIHBhZ2Us IHNvIEkgZ3Vlc3MgaXQncyByYXRoZXIKPj4+Pj4gbmV3LiBJIGRvIHVzZSBTVUouCj4+Pj4+Cj4+ Pj4+IGxvY2sgb3JkZXIgcmV2ZXJzYWw6Cj4+Pj4+IMKgMXN0IDB4YzQ4Mzg4ZDggdWZzICh1ZnMp IEAgL3Vzci9zcmMvc3lzL2tlcm4vdmZzX2xvb2t1cC5jOjUwMgo+Pj4+PiDCoDJuZCAweGVjMGZl MzA0IGJ1ZndhaXQgKGJ1ZndhaXQpIEAKPj4+Pj4gL3Vzci9zcmMvc3lzL3Vmcy9mZnMvZmZzX3Nv ZnRkZXAuYzoxMTM2Mwo+Pj4+PiDCoDNyZCAweGM0OWU1NmI4IHVmcyAodWZzKSBAIC91c3Ivc3Jj L3N5cy9rZXJuL3Zmc19zdWJyLmM6MjA5MQo+Pj4+PiBLREI6IHN0YWNrIGJhY2t0cmFjZToKPj4+ Pj4gZGJfdHJhY2Vfc2VsZl93cmFwcGVyKGMwOTM5NGZlLGZiODE3MzA4LGMwNjJlNTE1LGMwNjFl OGFiLGMwOTNjNGYxLC4uLikKPj4+Pj4gYXQgZGJfdHJhY2Vfc2VsZl93cmFwcGVyKzB4MjYKPj4+ Pj4ga2RiX2JhY2t0cmFjZShjMDYxZThhYixjMDkzYzRmMSxjNDE4YjE2OCxjNDE4ZWYyOCxmYjgx NzM2NCwuLi4pIGF0Cj4+Pj4+IGtkYl9iYWNrdHJhY2UrMHgyOQo+Pj4+PiBfd2l0bmVzc19kZWJ1 Z2dlcihjMDkzYzRmMSxjNDllNTZiOCxjMDkyZTc4NSxjNDE4ZWYyOCxjMDk0MzY5ZCwuLi4pIGF0 Cj4+Pj4+IF93aXRuZXNzX2RlYnVnZ2VyKzB4MjUKPj4+Pj4gd2l0bmVzc19jaGVja29yZGVyKGM0 OWU1NmI4LDksYzA5NDM2OWQsODJiLDAsLi4uKSBhdAo+Pj4+PiB3aXRuZXNzX2NoZWNrb3JkZXIr MHg4MzkKPj4+Pj4gX19sb2NrbWdyX2FyZ3MoYzQ5ZTU2YjgsODAxMDAsYzQ5ZTU2ZDgsMCwwLC4u LikgYXQgX19sb2NrbWdyX2FyZ3MrMHg3ZjkKPj4+Pj4gZmZzX2xvY2soZmI4MTc0ODgsYzA2MmUy YmIsYzA5NDJiM2YsODAxMDAsYzQ5ZTU2NjAsLi4uKSBhdAo+Pj4+PiBmZnNfbG9jaysweDgyCj4+ Pj4+IFZPUF9MT0NLMV9BUFYoYzA5YmQ2MDAsZmI4MTc0ODgsYzQ4MjdjZDQsYzA5ZDYyYTAsYzQ5 ZTU2NjAsLi4uKSBhdAo+Pj4+PiBWT1BfTE9DSzFfQVBWKzB4YjUKPj4+Pj4gX3ZuX2xvY2soYzQ5 ZTU2NjAsODAxMDAsYzA5NDM2OWQsODJiLDQsLi4uKSBhdCBfdm5fbG9jaysweDVlCj4+Pj4+IHZn ZXQoYzQ5ZTU2NjAsODAxMDAsYzQ4MjdjMzAsNTAsMCwuLi4pIGF0IHZnZXQrMHhiOQo+Pj4+PiB2 ZnNfaGFzaF9nZXQoYzQ3YmVhMjAsYjgwMyw4MDAwMCxjNDgyN2MzMCxmYjgxNzVkOCwuLi4pIGF0 Cj4+Pj4+IHZmc19oYXNoX2dldCsweGU2Cj4+Pj4+IGZmc192Z2V0ZihjNDdiZWEyMCxiODAzLDgw MDAwLGZiODE3NWQ4LDEsLi4uKSBhdCBmZnNfdmdldGYrMHg0OQo+Pj4+PiBzb2Z0ZGVwX3N5bmNf bWV0YWRhdGEoYzQ4Mzg4ODAsMCxjMDk2Mjk1NywxNDQsMCwuLi4pIGF0Cj4+Pj4+IHNvZnRkZXBf c3luY19tZXRhZGF0YSsweGM4Mgo+Pj4+PiBmZnNfc3luY3Zub2RlKGM0ODM4ODgwLDEsYzQ4Mjdj MzAsZmI4MTc2OTgsMjQ2LC4uLikgYXQKPj4+Pj4gZmZzX3N5bmN2bm9kZSsweDNlMgo+Pj4+PiBm ZnNfdHJ1bmNhdGUoYzQ4Mzg4ODAsMjAwLDAsODgwLGM0MWZiNDgwLC4uLikgYXQgZmZzX3RydW5j YXRlKzB4ODYyCj4+Pj4+IHVmc19kaXJlbnRlcihjNDgzODg4MCxjNDllNTY2MCxmYjgxNzk0Yyxm YjgxN2JkNCwwLC4uLikgYXQKPj4+Pj4gdWZzX2RpcmVudGVyKzB4OGQ0Cj4+Pj4+IHVmc19tYWtl aW5vZGUoZmI4MTdiZDQsMCxmYjgxN2IzMCxmYjgxN2E5NCxjMDhlNGNmNSwuLi4pIGF0Cj4+Pj4+ IHVmc19tYWtlaW5vZGUrMHg1MTcKPj4+Pj4gdWZzX2NyZWF0ZShmYjgxN2IzMCxmYjgxN2I0OCww LDAsZmI4MTdiYTgsLi4uKSBhdCB1ZnNfY3JlYXRlKzB4MzAKPj4+Pj4gVk9QX0NSRUFURV9BUFYo YzA5YmQ2MDAsZmI4MTdiMzAsMixmYjgxN2FjMCwwLC4uLikgYXQKPj4+Pj4gVk9QX0NSRUFURV9B UFYrMHhhNQo+Pj4+PiB2bl9vcGVuX2NyZWQoZmI4MTdiYTgsZmI4MTdjNWMsMWE0LDAsYzQxZmI0 ODAsLi4uKSBhdAo+Pj4+PiB2bl9vcGVuX2NyZWQrMHgxZGUKPj4+Pj4gdm5fb3BlbihmYjgxN2Jh OCxmYjgxN2M1YywxYTQsYzQ3ZTI0MjgsMCwuLi4pIGF0IHZuX29wZW4rMHgzYgo+Pj4+PiBrZXJu X29wZW5hdChjNDgyN2MzMCxmZmZmZmY5Yyw4MDRjNWU4LDAsNjAyLC4uLikgYXQga2Vybl9vcGVu YXQrMHgxMjUKPj4+Pj4ga2Vybl9vcGVuKGM0ODI3YzMwLDgwNGM1ZTgsMCw2MDEsMjFiNiwuLi4p IGF0IGtlcm5fb3BlbisweDM1Cj4+Pj4+IG9wZW4oYzQ4MjdjMzAsZmI4MTdjZjgsYzA5NzI3MjUs YzA5MWYwNjIsYzQ3ZWEyYTgsLi4uKSBhdCBvcGVuKzB4MzAKPj4+Pj4gc3lzY2FsbChmYjgxN2Qz OCkgYXQgc3lzY2FsbCsweDIyMAo+Pj4+PiBYaW50MHg4MF9zeXNjYWxsKCkgYXQgWGludDB4ODBf c3lzY2FsbCsweDIwCj4+Pj4+IC0tLSBzeXNjYWxsICg1LCBGcmVlQlNEIEVMRjMyLCBvcGVuKSwg ZWlwID0gMHgyODE3YmYzMywgZXNwID0KPj4+Pj4gMHhiZmJmZWM0YywgZWJwID0gMHhiZmJmZWNi OCAtLS0KPj4+Pgo+Pj4+IEFuZCBub3cgdGhlIHN5c3RlbSBpcyBoYW5naW5nIGFnYWluLiBXaGls ZSBJIGNhbiBzdGlsbCBwaW5nIGFuZCByZWNlaXZlCj4+Pj4gZG1lc2cgdXBkYXRlcyAoZWcuIFVT QiBwb3J0cyBhcHBlYXJpbmcpLCBJL08gaXMgZnJvemVuIHNvbGlkLiBUaGlzIGlzCj4+Pj4gZHVy aW5nIHBvcnR1cGdyYWRlLCB3aGVuIHRoZSBjb25maWd1cmUgc2NyaXB0IHJ1bnMgYW5kIHVzdWFs bHkgdGFrZXMgMS0yCj4+Pj4gbWludXRlcyB0byBwcm92b2tlLgo+Pj4+Cj4+Pj4gVGhpcyBwYXJ0 IGxvb2tzIHN1cHNpY2lvdXMgdG8gbWU6Cj4+Pj4KPj4+PiBkYj4gc2hvdyBhbGxsb2Nrcwo+Pj4+ IFByb2Nlc3MgMjgwMTQgKG1rZGlyKSB0aHJlYWQgMHhjNjkxYWMzMCAoMTAwMTUyKQo+Pj4+IGV4 Y2x1c2l2ZSBsb2NrbWdyIGJ1ZndhaXQgKGJ1ZndhaXQpIHIgPSAwICgweGVjMmJkYWYwKSBsb2Nr ZWQgQAo+Pj4+IC91c3Ivc3JjL3N5cy91ZnMvZmZzL2Zmc19zb2Z0ZGVwLmM6MTA2ODQKPj4+PiBl eGNsdXNpdmUgbG9ja21nciB1ZnMgKHVmcykgciA9IDAgKDB4YzZiY2Q1YTgpIGxvY2tlZCBACj4+ Pj4gL3Vzci9zcmMvc3lzL2tlcm4vdmZzX3N1YnIuYzoyMDkxCj4+Pj4gZXhjbHVzaXZlIGxvY2tt Z3IgYnVmd2FpdCAoYnVmd2FpdCkgciA9IDAgKDB4ZWMyOTgzZjQpIGxvY2tlZCBACj4+Pj4gL3Vz ci9zcmMvc3lzL3Vmcy9mZnMvZmZzX3NvZnRkZXAuYzoxMTM2Mwo+Pj4+IGV4Y2x1c2l2ZSBsb2Nr bWdyIHVmcyAodWZzKSByID0gMCAoMHhjNmQ5NzZiOCkgbG9ja2VkIEAKPj4+PiAvdXNyL3NyYy9z eXMva2Vybi92ZnNfbG9va3VwLmM6NTAyCj4+Pj4gUHJvY2VzcyAxOTkwIChzc2hkKSB0aHJlYWQg MHhjNTQ2Mjc1MCAoMTAwMTE3KQo+Pj4+IGV4Y2x1c2l2ZSBzeCBzb19yY3Zfc3ggKHNvX3Jjdl9z eCkgciA9IDAgKDB4YzU0NmUwOGMpIGxvY2tlZCBACj4+Pj4gL3Vzci9zcmMvc3lzL2tlcm4vdWlw Y19zb2NrYnVmLmM6MTQ4Cj4+Pj4gUHJvY2VzcyAxMiAoaW50cikgdGhyZWFkIDB4YzQxZjQ3NTAg KDEwMDAwNCkKPj4+PiBleGNsdXNpdmUgc2xlZXAgbXV0ZXggdHR5bXR4ICh0dHltdHgpIHIgPSAw ICgweGM0MjVhZTA0KSBsb2NrZWQgQAo+Pj4+IC91c3Ivc3JjL3N5cy9kZXYvZGNvbnMvZGNvbnNf b3MuYzoyMzIKPj4+PiBkYj4KPj4+Cj4+PiBBbG9uZyB3aXRoIHNob3cgYWxsbG9ja3MgbWF5IHlv dSBhbHNvIGdldCB0aGUgZm9sbG93aW5nIGZyb20gRERCOgo+Pj4gcHMsIHNob3cgcGNwdSwgYWxs dHJhY2UsIGxvY2tlZHZub2RzLgo+Pgo+PiAxLiBhIGtlcm5lbCBiZWZvcmUgU1VKIHdlbnQgaW4g aXMgcnVubmluZyBmaW5lIHdpdGggU1Ugb25seQo+PiAyLiB0aGUgZm9sbG93aW5nIGlzIG9uIGEg cmVjZW50IC1DVVJSRU5UIHRoYXQgaGFzIFNVSiwgKmJ1dCogaSd2ZQo+PiBkaXNhYmxlZCBpdCwg c28gaXQgaXMgcnVubmluZyB3aXRoIHNvZnQtdXBkYXRlcyBvbmx5IChJIGhvcGUpCj4+Cj4+IEkg cmFuIGEgcG9ydHVwZ3JhZGUgYW5kIHRoZSBmaXJzdCBjb25maWd1cmUgc2NyaXB0IHRyaWdnZXJl ZCB0aGUgSS9PCj4+IGhhbmcKPj4KPj4gZGI+IHBzCj4+IMKgcGlkIMKgcHBpZCDCoHBncnAgwqAg dWlkIMKgIHN0YXRlIMKgIHdtZXNnIMKgIMKgIHdjaGFuIMKgIMKgY21kCj4+IDEzNDY3IDEzNDQ0 IDEyOTM3IMKgIMKgIDAgwqBSKyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oG1rZGlyCj4+IDEzNDQ0IDEzMjA0IDEyOTM3IMKgIMKgIDAgwqBTKyDCoCDCoCDCoHdhaXQgwqAg wqAgMHhjNTQzNTJhOCBzaAo+PiAxMzIwNCAxMzAzNSAxMjkzNyDCoCDCoCAwIMKgUysgwqAgwqAg wqB3YWl0IMKgIMKgIDB4YzU0MzYwMDAgc2gKPj4gMTMwMzUgMTI5MzcgMTI5MzcgwqAgwqAgMCDC oFMrIMKgIMKgIMKgd2FpdCDCoCDCoCAweGM0ZmZhZDQ4IHNoCj4+IDEyOTM3IDEyOTM2IDEyOTM3 IMKgIMKgIDAgwqBTcysgwqAgwqAgd2FpdCDCoCDCoCAweGM0ZmY5ZDQ4IG1ha2UKPj4gMTI5MzYg wqAzNzIyIMKgMzcyMiDCoCDCoCAwIMKgUisgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqBzY3JpcHQKPj4gMzcyMiDCoDIwMjEgwqAzNzIyIMKgIMKgIDAgwqBTKyDCoCDCoCDC oCh0aHJlYWRlZCkgwqAgwqAgwqAgwqAgwqBydWJ5MTgKPj4gMTAwMTMyIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIFMgwqAgwqAgwqAgd2FpdCDCoCDCoCAweGM0ZmZhN2Y4IHJ1YnkxOAo+PiAy NDA0IMKgMjAwNyDCoDI0MDQgwqAxMDAwIMKgU3MrIMKgIMKgIHR0eWluIMKgIMKgMHhjNGQ3NDg3 MCB6c2gKPj4gMjMyNSDCoDIwMTUgwqAyMzI1IMKgMTAwMCDCoFIrIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgdG9wCj4+IDIwMjEgwqAyMDA5IMKgMjAyMSDCoCDCoCAwIMKg UysgwqAgwqAgwqBwYXVzZSDCoCDCoDB4YzRmZjkwNTggY3NoCj4+IDIwMTUgwqAyMDA3IMKgMjAx NSDCoDEwMDAgwqBTcysgwqAgwqAgcGF1c2UgwqAgwqAweGM0ZmZhMDU4IHpzaAo+PiAyMDA5IMKg MjAwNyDCoDIwMDkgwqAxMDAwIMKgU3MrIMKgIMKgIHBhdXNlIMKgIMKgMHhjNGQ0ZTg1MCB6c2gK Pj4gMjAwNyDCoDIwMDYgwqAyMDA3IMKgMTAwMCDCoFJzIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgc2NyZWVuCj4+IDIwMDYgwqAxOTkxIMKgMjAwNiDCoDEwMDAgwqBSKyDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHNjcmVlbgo+PiAyMDA1IMKgMjAw MSDCoDIwMDUgwqAgwqAgMCDCoFIrIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgc3lzdGF0Cj4+IDIwMDEgwqAxOTc2IMKgMjAwMSDCoCDCoCAwIMKgUysgwqAgwqAgwqBwYXVz ZSDCoCDCoDB4YzNkNTIwNTggY3NoCj4+IDIwMDAgwqAgwqAgMSDCoDIwMDAgwqAgwqAgMCDCoFNz IMKgIMKgIMKgc2VsZWN0IMKgIDB4YzNkNWIxYTQgc3NoLWFnZW50Cj4+IDE5OTEgwqAxOTkwIMKg MTk5MSDCoDEwMDAgwqBTcysgwqAgwqAgcGF1c2UgwqAgwqAweGMzZDUyODUwIHpzaAo+PiAxOTkw IMKgMTk4NiDCoDE5ODYgwqAxMDAwIMKgUyDCoCDCoCDCoCBzZWxlY3QgwqAgMHhjM2Q1YWNhNCBz c2hkCj4+IDE5ODkgwqAgwqAgMSDCoDE5ODkgwqAxMDAwIMKgU3MgwqAgwqAgwqBzZWxlY3QgwqAg MHhjM2Q1YWUyNCBzc2gtYWdlbnQKPj4gMTk4NiDCoDE4ODQgwqAxOTg2IMKgIMKgIDAgwqBTcyDC oCDCoCDCoHNid2FpdCDCoCAweGM0ZjIwNThjIHNzaGQKPj4gMTk4NSDCoCDCoCAxIMKgMTk4NSDC oCDCoCAwIMKgU3MrIMKgIMKgIHR0eWluIMKgIMKgMHhjM2U2MjY3MCBnZXR0eQo+PiAxOTg0IMKg IMKgIDEgwqAxOTg0IMKgIMKgIDAgwqBTcysgwqAgwqAgdHR5aW4gwqAgwqAweGMzZTYxYzcwIGdl dHR5Cj4+IDE5ODMgwqAgwqAgMSDCoDE5ODMgwqAgwqAgMCDCoFNzKyDCoCDCoCB0dHlpbiDCoCDC oDB4YzNlNjAwNzAgZ2V0dHkKPj4gMTk4MiDCoCDCoCAxIMKgMTk4MiDCoCDCoCAwIMKgU3MrIMKg IMKgIHR0eWluIMKgIMKgMHhjM2U2MGE3MCBnZXR0eQo+PiAxOTgxIMKgIMKgIDEgwqAxOTgxIMKg IMKgIDAgwqBTcysgwqAgwqAgdHR5aW4gwqAgwqAweGMzZGE3YTcwIGdldHR5Cj4+IDE5ODAgwqAg wqAgMSDCoDE5ODAgwqAgwqAgMCDCoFNzKyDCoCDCoCB0dHlpbiDCoCDCoDB4YzNkYTdjNzAgZ2V0 dHkKPj4gMTk3OSDCoCDCoCAxIMKgMTk3OSDCoCDCoCAwIMKgU3MrIMKgIMKgIHR0eWluIMKgIMKg MHhjM2U2MGM3MCBnZXR0eQo+PiAxOTc2IMKgIMKgIDEgwqAxOTc2IMKgIMKgIDAgwqBTcysgwqAg wqAgd2FpdCDCoCDCoCAweGM0YzM5MmE4IGxvZ2luCj4+IDE5NTUgwqAgwqAgMSDCoDE5NTUgwqAg wqAgMCDCoFJzIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgYnNubXBkCj4+ IDE5MzEgwqAgwqAgMSDCoDE5MzEgwqAgwqAgMCDCoFNzIMKgIMKgIMKgc2VsZWN0IMKgIDB4YzRk MGYxNjQgaW5ldGQKPj4gMTg5MCDCoCDCoCAxIMKgMTg5MCDCoCDCoCAwIMKgUnMgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBjcm9uCj4+IDE4ODQgwqAgwqAgMSDCoDE4ODQg wqAgwqAgMCDCoFNzIMKgIMKgIMKgc2VsZWN0IMKgIDB4YzRkMGVkYTQgc3NoZAo+PiAxODA4IMKg IMKgIDEgwqAxODA4IMKgIMKgIDAgwqBScyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoHNlbmRtYWlsCj4+IDE3NjQgwqAgwqAgMSDCoDE3NjQgwqAgwqAgMCDCoFJzIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgbW91c2VkCj4+IDE3NTQgwqAgwqAgMSDC oDE3NTQgwqAgwqAgMCDCoFNzIMKgIMKgIMKgKHRocmVhZGVkKSDCoCDCoCDCoCDCoCDCoG5zbGNk Cj4+IDEwMDExMSDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBTIMKgIMKgIMKgIGFjY2VwdCDC oCAweGM0ZDA3NmFlIG5zbGNkCj4+IDEwMDExMCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBT IMKgIMKgIMKgIGFjY2VwdCDCoCAweGM0ZDA3NmFlIG5zbGNkCj4+IDEwMDEwOSDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCBTIMKgIMKgIMKgIGFjY2VwdCDCoCAweGM0ZDA3NmFlIG5zbGNkCj4+ IDEwMDEwOCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBTIMKgIMKgIMKgIGFjY2VwdCDCoCAw eGM0ZDA3NmFlIG5zbGNkCj4+IDEwMDEwNyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBTIMKg IMKgIMKgIGFjY2VwdCDCoCAweGM0ZDA3NmFlIG5zbGNkCj4+IDEwMDA3NiDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCBTIMKgIMKgIMKgIHV3YWl0IMKgIMKgMHhjNDQ5MzE4MCBuc2xjZAo+PiAx NzQ4IMKgIMKgIDEgwqAxNzQ4IMKgIMKgIDAgwqBScyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoG9wZW52cG4KPj4gMTcyNCDCoCDCoCAxIMKgMTcyNCDCoCAyMDEgwqBTcyDC oCDCoCDCoGFjY2VwdCDCoCAweGM0ZDA3YjgyIHByaXZveHkKPj4gMTY3MiDCoCDCoCAxIMKgMTY3 MiDCoCDCoCAwIMKgUnMgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBwb3dl cmQKPj4gMTY2NCDCoCDCoCAxIMKgMTY2NCDCoCDCoCAwIMKgUnMgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqBudHBkCj4+IDE2NTggwqAgwqAgMSDCoDE2NTggwqAgwqAgMCDC oFNzIMKgIMKgIMKgKHRocmVhZGVkKSDCoCDCoCDCoCDCoCDCoG5zY2QKPj4gMTAwMDk0IMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIFMgwqAgwqAgwqAga3FyZWFkIMKgIDB4YzRjZjE3MDAgbnNj ZAo+PiAxMDAwOTMgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgUyDCoCDCoCDCoCBrcXJlYWQg wqAgMHhjNGNmMTcwMCBuc2NkCj4+IDEwMDA5MiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBT IMKgIMKgIMKgIGtxcmVhZCDCoCAweGM0Y2YxNzAwIG5zY2QKPj4gMTAwMDkxIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIFMgwqAgwqAgwqAga3FyZWFkIMKgIDB4YzRjZjE3MDAgbnNjZAo+PiAx MDAwOTAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgUyDCoCDCoCDCoCBrcXJlYWQgwqAgMHhj NGNmMTcwMCBuc2NkCj4+IDEwMDA4OSDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBTIMKgIMKg IMKgIGtxcmVhZCDCoCAweGM0Y2YxNzAwIG5zY2QKPj4gMTAwMDg4IMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIFMgwqAgwqAgwqAga3FyZWFkIMKgIDB4YzRjZjE3MDAgbnNjZAo+PiAxMDAwODcg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgUyDCoCDCoCDCoCBrcXJlYWQgwqAgMHhjNGNmMTcw MCBuc2NkCj4+IDEwMDA3NSDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBTIMKgIMKgIMKgIHV3 YWl0IMKgIMKgMHhjNDQ5ZjY4MCBuc2NkCj4+IDE1NzYgwqAgwqAgMSDCoDE1NzYgwqAgMzg5IMKg U3MgwqAgwqAgwqAodGhyZWFkZWQpIMKgIMKgIMKgIMKgIMKgc2xhcGQKPj4gMTAwMTE1IMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIFMgwqAgwqAgwqAgdWNvbmQgwqAgwqAweGM0Y2YyNzAwIHNs YXBkCj4+IDEwMDA4NiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBTIMKgIMKgIMKgIHVjb25k IMKgIMKgMHhjNGNmMjYwMCBzbGFwZAo+PiAxMDAwODUgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgUyDCoCDCoCDCoCBzZWxlY3QgwqAgMHhjNGQwZWVhNCBzbGFwZAo+PiAxMDAwNzMgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgUyDCoCDCoCDCoCB1d2FpdCDCoCDCoDB4YzQyYTk1ODAgc2xh cGQKPj4gMTU2MyDCoCDCoCAxIMKgMTU2MiDCoCDCoCAwIMKgUyDCoCDCoCDCoCBuYW5zbHAgwqAg MHhjMDlmMzg2NCBzbWFydGQKPj4gMTUyNiDCoCDCoCAxIMKgMTUyNiDCoCDCoCAwIMKgUnMgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBycGMuc3RhdGQKPj4gMTQ0NSDCoCDC oCAxIMKgMTQ0NSDCoCDCoCAwIMKgUnMgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqBhbWQKPj4gMTQxOCDCoCDCoCAxIMKgMTQxOCDCoCDCoCAwIMKgUnMgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBycGNiaW5kCj4+IDE0MDMgwqAgwqAgMSDCoDE0MDMg wqAgwqA1MyDCoFNzIMKgIMKgIMKgKHRocmVhZGVkKSDCoCDCoCDCoCDCoCDCoG5hbWVkCj4+IDEw MDA4NCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBTIMKgIMKgIMKgIGtxcmVhZCDCoCAweGM0 Y2RjYjgwIG5hbWVkCj4+IDEwMDA4MyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBTIMKgIMKg IMKgIHVjb25kIMKgIMKgMHhjNDI2MGIwMCBuYW1lZAo+PiAxMDAwODIgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgUyDCoCDCoCDCoCB1Y29uZCDCoCDCoDB4YzQ0OWZiODAgbmFtZWQKPj4gMTAw MDc0IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIFMgwqAgwqAgwqAgc2lnd2FpdCDCoDB4ZmI0 YjhiZTAgbmFtZWQKPj4gMTMwNiDCoCDCoCAxIMKgMTMwNiDCoCDCoCAwIMKgUnMgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBzeXNsb2dkCj4+IMKgOTk3IMKgIMKgIDAgwqAg wqAgMCDCoCDCoCAwIMKgUkwgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBb cGZwdXJnZV0KPj4gwqA5NzMgwqAgwqAgMSDCoCA5NzMgwqAgwqAgMCDCoFNzIMKgIMKgIMKgc2Vs ZWN0IMKgIDB4YzQxZWIwYTQgZGV2ZAo+PiDCoDk2NCDCoCDCoCAxIMKgIDk2NCDCoCDCoDY1IMKg U3MgwqAgwqAgwqBzZWxlY3QgwqAgMHhjNDRhYzUyNCBkaGNsaWVudAo+PiDCoDk0MiDCoCDCoCAx IMKgIDk0MiDCoCDCoCAwIMKgU3MgwqAgwqAgwqBzZWxlY3QgwqAgMHhjNDI2ZjQyNCBkaGNsaWVu dAo+PiDCoDg1NiDCoCDCoCAxIMKgIDg1NiDCoCDCoCAwIMKgU3MgwqAgwqAgwqBzZWxlY3QgwqAg MHhjNDFlYjQyNCBtb3VzZWQKPj4gwqA1NjEgwqAgwqAgMSDCoCA1NjEgwqAgwqAgMCDCoFNzIMKg IMKgIMKgc2VsZWN0IMKgIDB4YzQ0YWNkZTQgd3BhX3N1cHBsaWNhbnQKPj4gwqAxNTAgwqAgwqAg MSDCoCAxNTAgwqAgwqAgMCDCoFNzIMKgIMKgIMKgcGF1c2UgwqAgwqAweGM0MmVjODUwIGFkamtl cm50ego+PiDCoDk1IMKgIMKgIDAgwqAgwqAgMCDCoCDCoCAwIMKgREwgwqAgwqAgwqBtZHdhaXQg wqAgMHhjNDI2YTAwMCBbbWQwXQo+PiDCoDc0IMKgIMKgIDAgwqAgwqAgMCDCoCDCoCAwIMKgREwg wqAgwqAgwqBnZWxpOncgwqAgMHhjNDI2NTQwMCBbZ19lbGlbMF0gYWQwczRmXQo+PiDCoDIyIMKg IMKgIDAgwqAgwqAgMCDCoCDCoCAwIMKgUkwgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqBbc29mdGRlcGZsdXNoXQo+PiDCoDIxIMKgIMKgIDAgwqAgwqAgMCDCoCDCoCAwIMKg UkwgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBbc3luY2VyXQo+PiDCoDIw IMKgIMKgIDAgwqAgwqAgMCDCoCDCoCAwIMKgUkwgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqBbdm5scnVdCj4+IMKgMTkgwqAgwqAgMCDCoCDCoCAwIMKgIMKgIDAgwqBSTCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoFtidWZkYWVtb25dCj4+IMKgMTgg wqAgwqAgMCDCoCDCoCAwIMKgIMKgIDAgwqBSTCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoFtwYWdlemVyb10KPj4gwqAxNyDCoCDCoCAwIMKgIMKgIDAgwqAgwqAgMCDCoERM IMKgIMKgIMKgcHNsZWVwIMKgIDB4YzBiNzY5ZDggW3ZtZGFlbW9uXQo+PiDCoDE2IMKgIMKgIDAg wqAgwqAgMCDCoCDCoCAwIMKgUkwgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqBbcGFnZWRhZW1vbl0KPj4gwqAgOSDCoCDCoCAwIMKgIMKgIDAgwqAgwqAgMCDCoERMIMKgIMKg IMKgY2NiX3NjYW4gMHhjMDlkNzhkNCBbeHB0X3RocmRdCj4+IMKgMTUgwqAgwqAgMCDCoCDCoCAw IMKgIMKgIDAgwqBETCDCoCDCoCDCoHR6cG9sbCDCoCAweGMwOWRhZmNjIFthY3BpX3RoZXJtYWxd Cj4+IMKgIDggwqAgwqAgMCDCoCDCoCAwIMKgIMKgIDAgwqBTTCDCoCDCoCDCoC0gwqAgwqAgwqAg wqAweGMzZjU1MDAwIFtmdzBfcHJvYmVdCj4+IMKgIDcgwqAgwqAgMCDCoCDCoCAwIMKgIMKgIDAg wqBETCDCoCDCoCDCoC0gwqAgwqAgwqAgwqAweGMzZWJkM2JjIFtjYmIwIGV2ZW50IHRocmVhZF0K Pj4gwqAxNCDCoCDCoCAwIMKgIMKgIDAgwqAgwqAgMCDCoERMIMKgIMKgIMKgKHRocmVhZGVkKSDC oCDCoCDCoCDCoCDCoFt1c2JdCj4+IDEwMDA0MCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBE IMKgIMKgIMKgIC0gwqAgwqAgwqAgwqAweGMzZjM5ZDBjIFt1c2J1czNdCj4+IDEwMDAzOSDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBEIMKgIMKgIMKgIC0gwqAgwqAgwqAgwqAweGMzZjM5Y2Rj IFt1c2J1czNdCj4+IDEwMDAzOCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBEIMKgIMKgIMKg IC0gwqAgwqAgwqAgwqAweGMzZjM5Y2FjIFt1c2J1czNdCj4+IDEwMDAzNyDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCBEIMKgIMKgIMKgIC0gwqAgwqAgwqAgwqAweGMzZjM5YzdjIFt1c2J1czNd Cj4+IDEwMDAzNiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBEIMKgIMKgIMKgIC0gwqAgwqAg wqAgwqAweGMzZjFmZGFjIFt1c2J1czJdCj4+IDEwMDAzNSDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCBEIMKgIMKgIMKgIC0gwqAgwqAgwqAgwqAweGMzZjFmZDdjIFt1c2J1czJdCj4+IDEwMDAz NCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBEIMKgIMKgIMKgIC0gwqAgwqAgwqAgwqAweGMz ZjFmZDRjIFt1c2J1czJdCj4+IDEwMDAzMyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBEIMKg IMKgIMKgIC0gwqAgwqAgwqAgwqAweGMzZjFmZDFjIFt1c2J1czJdCj4+IDEwMDAzMiDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCBEIMKgIMKgIMKgIC0gwqAgwqAgwqAgwqAweGMzZjBkZGFjIFt1 c2J1czFdCj4+IDEwMDAzMSDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBEIMKgIMKgIMKgIC0g wqAgwqAgwqAgwqAweGMzZjBkZDdjIFt1c2J1czFdCj4+IDEwMDAzMCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCBEIMKgIMKgIMKgIC0gwqAgwqAgwqAgwqAweGMzZjBkZDRjIFt1c2J1czFdCj4+ IDEwMDAyOSDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBEIMKgIMKgIMKgIC0gwqAgwqAgwqAg wqAweGMzZjBkZDFjIFt1c2J1czFdCj4+IDEwMDAyOCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCBEIMKgIMKgIMKgIC0gwqAgwqAgwqAgwqAweGMzZWY3ZGFjIFt1c2J1czBdCj4+IDEwMDAyNyDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBEIMKgIMKgIMKgIC0gwqAgwqAgwqAgwqAweGMzZWY3 ZDdjIFt1c2J1czBdCj4+IDEwMDAyNiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBEIMKgIMKg IMKgIC0gwqAgwqAgwqAgwqAweGMzZWY3ZDRjIFt1c2J1czBdCj4+IDEwMDAyNSDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCBEIMKgIMKgIMKgIC0gwqAgwqAgwqAgwqAweGMzZWY3ZDFjIFt1c2J1 czBdCj4+IMKgIDYgwqAgwqAgMCDCoCDCoCAwIMKgIMKgIDAgwqBETCDCoCDCoCDCoGNyeXB0b19y IDB4YzBiNzQ0NmMgW2NyeXB0byByZXR1cm5zXQo+PiDCoCA1IMKgIMKgIDAgwqAgwqAgMCDCoCDC oCAwIMKgREwgwqAgwqAgwqBjcnlwdG9fdyAweGMwYjc0NDQ4IFtjcnlwdG9dCj4+IMKgMTMgwqAg wqAgMCDCoCDCoCAwIMKgIMKgIDAgwqBETCDCoCDCoCDCoC0gwqAgwqAgwqAgwqAweGMwOWYzNmM0 IFt5YXJyb3ddCj4+IMKgIDQgwqAgwqAgMCDCoCDCoCAwIMKgIMKgIDAgwqBETCDCoCDCoCDCoC0g wqAgwqAgwqAgwqAweGMwOWYxM2U0IFtnX2Rvd25dCj4+IMKgIDMgwqAgwqAgMCDCoCDCoCAwIMKg IMKgIDAgwqBETCDCoCDCoCDCoC0gwqAgwqAgwqAgwqAweGMwOWYxM2UwIFtnX3VwXQo+PiDCoCAy IMKgIMKgIDAgwqAgwqAgMCDCoCDCoCAwIMKgUkwgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqBbZ19ldmVudF0KPj4gwqAxMiDCoCDCoCAwIMKgIMKgIDAgwqAgwqAgMCDCoFJM IMKgIMKgIMKgKHRocmVhZGVkKSDCoCDCoCDCoCDCoCDCoFtpbnRyXQo+PiAxMDAwNDkgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgSSDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCBbaXJxMTI6IHBzbTBdCj4+IDEwMDA0OCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBJ IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIFtpcnExOiBhdGtiZDBdCj4+ IDEwMDA0NiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBJIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIFtpcnExNTogYXRhMV0KPj4gMTAwMDQ1IMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIEkgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgW2ly cTE0OiBhdGEwXQo+PiAxMDAwMjQgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgSSDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBbaXJxMTE6IGNiYjAgYmZlMCsrKl0KPj4g MTAwMDIzIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIEkgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgW2lycTk6IHBjbTAgaXdpMCtdCj4+IDEwMDAyMiDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCBJIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IFtzd2k2OiBHaWFudCB0YXNrcV0KPj4gMTAwMDIwIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IEkgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgW3N3aTU6ICtdCj4+IDEw MDAxOSDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBJIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIFtzd2kyOiBjYW1iaW9dCj4+IDEwMDAxNCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCBJIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIFtzd2k2 OiB0YXNrIHF1ZXVlXQo+PiAxMDAwMDYgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgSSDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBbc3dpMzogdm1dCj4+IDEwMDAwNSDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBSdW4gwqAgwqAgQ1BVIDAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgW3N3aTQ6IGNsb2NrXQo+PiAxMDAwMDQgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg SSDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBbc3dpMTogbmV0aXNyIDBd Cj4+IMKgMTEgwqAgwqAgMCDCoCDCoCAwIMKgIMKgIDAgwqBSTCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoFtpZGxlOiBjcHUwXQo+PiDCoCAxIMKgIMKgIDAgwqAgwqAgMSDC oCDCoCAwIMKgU0xzIMKgIMKgIHdhaXQgwqAgwqAgMHhjM2RmMmQ0OCBbaW5pdF0KPj4gwqAxMCDC oCDCoCAwIMKgIMKgIDAgwqAgwqAgMCDCoERMIMKgIMKgIMKgYXVkaXRfd28gMHhjMGI3NDdlMCBb YXVkaXRdCj4+IMKgIDAgwqAgwqAgMCDCoCDCoCAwIMKgIMKgIDAgwqBSTHMgwqAgwqAgKHRocmVh ZGVkKSDCoCDCoCDCoCDCoCDCoFtrZXJuZWxdCj4+IDEwMDA1MCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCBEIMKgIMKgIMKgIGRlYWRsa3JlIDB4YzA5ZjM2YzQgW2RlYWRsa3Jlc10KPj4gMTAw MDQ0IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIEQgwqAgwqAgwqAgLSDCoCDCoCDCoCDCoDB4 YzNmNWRiODAgW2l3aTAgdGFza3FdCj4+IDEwMDA0MiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCBEIMKgIMKgIMKgIC0gwqAgwqAgwqAgwqAweGMzZjVlOGMwIFtmdzBfdGFza3FdCj4+IDEwMDAy MSDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBEIMKgIMKgIMKgIC0gwqAgwqAgwqAgwqAweGMz ZWEwOGMwIFt0aHJlYWQgdGFza3FdCj4+IDEwMDAxOCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCBEIMKgIMKgIMKgIC0gwqAgwqAgwqAgwqAweGMzZWEwYTgwIFtrcXVldWUgdGFza3FdCj4+IDEw MDAxNyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBEIMKgIMKgIMKgIC0gwqAgwqAgwqAgwqAw eGMzZWEwYzQwIFthY3BpX3Rhc2tfMl0KPj4gMTAwMDE2IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIEQgwqAgwqAgwqAgLSDCoCDCoCDCoCDCoDB4YzNlYTBjNDAgW2FjcGlfdGFza18xXQo+PiAx MDAwMTUgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgRCDCoCDCoCDCoCAtIMKgIMKgIMKgIMKg MHhjM2VhMGM0MCBbYWNwaV90YXNrXzBdCj4+IDEwMDAxMCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCBEIMKgIMKgIMKgIC0gwqAgwqAgwqAgwqAweGMzZGRhOWMwIFtmaXJtd2FyZSB0YXNrcV0K Pj4gMTAwMDAwIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIFJ1blEgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqBbc3dhcHBlcl0KPj4gMTk5OSDCoDE5NzYgwqAxOTc2IMKgIMKg IDAgwqBaKyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHNzaC1hZ2VudAo+ PiAxOTg4IMKgMTk4NiDCoDE5ODYgwqAxMDAwIMKgWiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCBzc2gtYWdlbnQKPj4gZGI+IHNob3cgYWxsbG9ja3MKPj4gUHJvY2VzcyAx MzQ2NyAobWtkaXIpIHRocmVhZCAweGM1NDNiMjcwICgxMDAxNTApCj4+IGV4Y2x1c2l2ZSBsb2Nr bWdyIGJ1ZndhaXQgKGJ1ZndhaXQpIHIgPSAwICgweGViZDFmOGVjKSBsb2NrZWQgQAo+PiAvdXNy L3NyYy9zeXMva2Vybi92ZnNfYmlvLmM6MjU4MQo+PiBleGNsdXNpdmUgbG9ja21nciB1ZnMgKHVm cykgciA9IDAgKDB4YzU0MmZjMDgpIGxvY2tlZCBACj4+IC91c3Ivc3JjL3N5cy9rZXJuL3Zmc19z dWJyLmM6MjA5MQo+PiBleGNsdXNpdmUgbG9ja21nciBidWZ3YWl0IChidWZ3YWl0KSByID0gMCAo MHhlYmQxNTE5NCkgbG9ja2VkIEAKPj4gL3Vzci9zcmMvc3lzL3Vmcy9mZnMvZmZzX3NvZnRkZXAu YzoxMTM2Mwo+PiBleGNsdXNpdmUgbG9ja21nciB1ZnMgKHVmcykgciA9IDAgKDB4YzU0Mjc5ZTgp IGxvY2tlZCBACj4+IC91c3Ivc3JjL3N5cy9rZXJuL3Zmc19sb29rdXAuYzo1MDIKPj4gUHJvY2Vz cyAxOTg2IChzc2hkKSB0aHJlYWQgMHhjNGQyZWMzMCAoMTAwMTEzKQo+PiBleGNsdXNpdmUgc3gg c29fcmN2X3N4IChzb19yY3Zfc3gpIHIgPSAwICgweGM0ZjIwNTYwKSBsb2NrZWQgQAo+PiAvdXNy L3NyYy9zeXMva2Vybi91aXBjX3NvY2tidWYuYzoxNDgKPj4gUHJvY2VzcyAyMiAoc29mdGRlcGZs dXNoKSB0aHJlYWQgMHhjNDI4Zjc1MCAoMTAwMDU4KQo+PiBleGNsdXNpdmUgc2xlZXAgbXV0ZXgg c3RydWN0IG1vdW50IG10eCAoc3RydWN0IG1vdW50IG10eCkgciA9IDAKPj4gKDB4YzQyYTNhMjAp IGxvY2tlZCBAIC91c3Ivc3JjL3N5cy9rZXJuL3Zmc19zdWJyLmM6MzQxCj4+IFByb2Nlc3MgMTIg KGludHIpIHRocmVhZCAweGMzZGY0NGUwICgxMDAwMDUpCj4+IGV4Y2x1c2l2ZSBzbGVlcCBtdXRl eCB0dHltdHggKHR0eW10eCkgciA9IDAgKDB4YzNlNjM2MDQpIGxvY2tlZCBACj4+IC91c3Ivc3Jj L3N5cy9kZXYvZGNvbnMvZGNvbnNfb3MuYzoyMzIKPj4gZGI+IHNob3cgcGNwdQo+PiBjcHVpZCDC oCDCoCDCoCDCoD0gMAo+PiBkeW5hbWljIHBjcHUgwqAgwqA9IDB4NjRlNDAwCj4+IGN1cnRocmVh ZCDCoCDCoD0gMHhjM2RmNDRlMDogcGlkIDEyICJzd2k0OiBjbG9jayIKPj4gY3VycGNiIMKgIMKg IMKgID0gMHhjM2JmYmQ5MAo+PiBmcGN1cnRocmVhZCDCoD0gbm9uZQo+PiBpZGxldGhyZWFkIMKg ID0gMHhjM2RmNDljMDogcGlkIDExICJpZGxlOiBjcHUwIgo+PiBBUElDIElEIMKgIMKgIMKgPSAw Cj4+IGN1cnJlbnRsZHQgwqAgPSAweDUwCj4+IHNwaW4gbG9ja3MgaGVsZDoKPj4gZGI+IHNob3cg bG9ja2Vkdm5vZHMKPj4gTG9ja2VkIHZub2Rlcwo+Pgo+PiAweGM1NDI3OTkwOiB0YWcgdWZzLCB0 eXBlIFZESVIKPj4gwqAgdXNlY291bnQgNSwgd3JpdGVjb3VudCAwLCByZWZjb3VudCA3IG1vdW50 ZWRoZXJlIDAKPj4gwqAgZmxhZ3MgKCkKPj4gwqAgdl9vYmplY3QgMHhjNTQyMjRjOCByZWYgMCBw YWdlcyAwCj4+IMKgIGxvY2sgdHlwZSB1ZnM6IEVYQ0wgYnkgdGhyZWFkIDB4YzU0M2IyNzAgKHBp ZCAxMzQ2NykKPj4gwqAgwqAgwqAgaW5vIDExMzc1ODMxLCBvbiBkZXYgYWQwczRmLmVsaQo+Pgo+ PiAweGM1NDJmYmIwOiB0YWcgdWZzLCB0eXBlIFZSRUcKPj4gwqAgdXNlY291bnQgMiwgd3JpdGVj b3VudCAwLCByZWZjb3VudCA1IG1vdW50ZWRoZXJlIDAKPj4gwqAgZmxhZ3MgKCkKPj4gwqAgdl9v YmplY3QgMHhjNTQyMjg4MCByZWYgMCBwYWdlcyA3Cj4+IMKgIGxvY2sgdHlwZSB1ZnM6IEVYQ0wg YnkgdGhyZWFkIDB4YzU0M2IyNzAgKHBpZCAxMzQ2NykKPj4gwqAgwqAgwqAgaW5vIDExMzc1ODg0 LCBvbiBkZXYgYWQwczRmLmVsaQo+PiBkYj4gYWxsdHJhY2UKPj4KPj4gVHJhY2luZyBjb21tYW5k IG1rZGlyIHBpZCAxMzQ2NyB0aWQgMTAwMTUwIHRkIDB4YzU0M2IyNzAKPj4gc2NoZWRfc3dpdGNo KGM1NDNiMjcwLDAsMTA0LDE5MSxmNjE0YjI4ZCwuLi4pIGF0IHNjaGVkX3N3aXRjaCsweDM2YQo+ PiBtaV9zd2l0Y2goMTA0LDAsYzA5M2E4NTMsMWViLDRjLC4uLikgYXQgbWlfc3dpdGNoKzB4MjAw Cj4+IHNsZWVwcV9zd2l0Y2goYzU0M2IyNzAsMCxjMDkzYTg1MywyNjAsMCwuLi4pIGF0IHNsZWVw cV9zd2l0Y2grMHgxNWYKPj4gc2xlZXBxX3dhaXQoZWJkMWY4OGMsNGMsYzA5NDE3OTUsMCwwLC4u LikgYXQgc2xlZXBxX3dhaXQrMHg2Mwo+PiBfc2xlZXAoZWJkMWY4OGMsYzNkYTE0YWMsNGMsYzA5 NDE3OTUsMCwuLi4pIGF0IF9zbGVlcCsweDM2NQo+PiBid2FpdChlYmQxZjg4Yyw0YyxjMDk0MTc5 NSxlYmQxZjg4YyxmYjVkNTU4NCwuLi4pIGF0IGJ3YWl0KzB4NmYKPj4gYnVmd2FpdChlYmQxZjg4 YyxlYmQxZjg4YywwLGViZDFmODhjLGM1NDE2NWU0LC4uLikgYXQgYnVmd2FpdCsweDQ4Cj4+IGJ1 ZndyaXRlKGViZDFmODhjLDAsYzA5NjI1ZTMsNzRkLDApIGF0IGJ1ZndyaXRlKzB4MTY1Cj4+IGZm c19idWZ3cml0ZShlYmQxZjg4YyxjNTQyZDUwMCwxMDAsNDAwMCwwLC4uLikgYXQgZmZzX2J1Zndy aXRlKzB4MjkwCj4+IGZmc191cGRhdGUoYzU0MmZiYjAsMSw4MDAwMCxmYjVkNTY3YywxLC4uLikg YXQgZmZzX3VwZGF0ZSsweDI3Ywo+PiBzb2Z0ZGVwX3N5bmNfbWV0YWRhdGEoYzU0Mjc5OTAsMCxj MDk2MmI3NiwxNDQsMCwuLi4pIGF0Cj4+IHNvZnRkZXBfc3luY19tZXRhZGF0YSsweGM5Zgo+PiBm ZnNfc3luY3Zub2RlKGM1NDI3OTkwLDEsYzU0M2IyNzAsZmI1ZDU3M2MsMjQ2LC4uLikgYXQgZmZz X3N5bmN2bm9kZSsweDNlMgo+PiBmZnNfdHJ1bmNhdGUoYzU0Mjc5OTAsNDAwLDAsODgwLGM0YzRm NjgwLC4uLikgYXQgZmZzX3RydW5jYXRlKzB4ODYyCj4+IHVmc19kaXJlbnRlcihjNTQyNzk5MCxj NTQyZjY2MCxmYjVkNWExYyxmYjVkNWMwMCxlYmQyYTkzMCwuLi4pIGF0Cj4+IHVmc19kaXJlbnRl cisweDhkNAo+PiB1ZnNfbWtkaXIoZmI1ZDVjMjgsZmI1ZDVjM2MsMCxmYjVkNWJkNCxmYjVkNWI2 YywuLi4pIGF0IHVmc19ta2RpcisweDgxZgo+PiBWT1BfTUtESVJfQVBWKGMwOWJkODQwLGZiNWQ1 YzI4LDY4LGZiNWQ1YmMwLDAsLi4uKSBhdCBWT1BfTUtESVJfQVBWKzB4YTUKPj4ga2Vybl9ta2Rp cmF0KGM1NDNiMjcwLGZmZmZmZjljLGJmYmZlYWEyLDAsMWZmLC4uLikgYXQga2Vybl9ta2RpcmF0 KzB4MjExCj4+IGtlcm5fbWtkaXIoYzU0M2IyNzAsYmZiZmVhYTIsMCwxZmYsZmI1ZDVkMmMsLi4u KSBhdCBrZXJuX21rZGlyKzB4MmUKPj4gbWtkaXIoYzU0M2IyNzAsZmI1ZDVjZjgsYyxjLGM1NDM0 YWEwLC4uLikgYXQgbWtkaXIrMHgyOQo+PiBzeXNjYWxsKGZiNWQ1ZDM4KSBhdCBzeXNjYWxsKzB4 MjIwCj4+IFhpbnQweDgwX3N5c2NhbGwoKSBhdCBYaW50MHg4MF9zeXNjYWxsKzB4MjAKPj4gLS0t IHN5c2NhbGwgKDEzNiwgRnJlZUJTRCBFTEYzMiwgbWtkaXIpLCBlaXAgPSAweDI4MTc4ZWYzLCBl c3AgPQo+PiAweGJmYmZlN2VjLCBlYnAgPSAweGJmYmZlOGI4IC0tLQo+Pgo+PiBUcmFjaW5nIGNv bW1hbmQgc2ggcGlkIDEzNDQ0IHRpZCAxMDAxNDcgdGQgMHhjNGZmZjljMAo+PiBzY2hlZF9zd2l0 Y2goYzRmZmY5YzAsMCwxMDQsMTkxLGY1ZDgwNjEzLC4uLikgYXQgc2NoZWRfc3dpdGNoKzB4MzZh Cj4+IG1pX3N3aXRjaCgxMDQsMCxjMDkzYTg1MywxZWIsNWMsLi4uKSBhdCBtaV9zd2l0Y2grMHgy MDAKPj4gc2xlZXBxX3N3aXRjaChjNGZmZjljMCwwLGMwOTNhODUzLDFhMCw1YywuLi4pIGF0IHNs ZWVwcV9zd2l0Y2grMHgxNWYKPj4gc2xlZXBxX2NhdGNoX3NpZ25hbHMoYzA5M2E4NTMsMTYwLDAs MTAwLDEwMCwuLi4pIGF0Cj4+IHNsZWVwcV9jYXRjaF9zaWduYWxzKzB4YjcKPj4gc2xlZXBxX3dh aXRfc2lnKGM1NDM1MmE4LDVjLGMwOTNkMTEyLDEwMCwwLC4uLikgYXQgc2xlZXBxX3dhaXRfc2ln KzB4MTcKPj4gX3NsZWVwKGM1NDM1MmE4LGM1NDM1MzMwLDE1YyxjMDkzZDExMiwwLC4uLikgYXQg X3NsZWVwKzB4MzRlCj4+IGtlcm5fd2FpdChjNGZmZjljMCxmZmZmZmZmZixmYjVjY2M3NCwyLDAs Li4uKSBhdCBrZXJuX3dhaXQrMHhiNzYKPj4gd2FpdDQoYzRmZmY5YzAsZmI1Y2NjZjgsYzA5NzI5 NDQsYzA5M2QwZjEsYzU0MzUyYTgsLi4uKSBhdCB3YWl0NCsweDNkCj4+IHN5c2NhbGwoZmI1Y2Nk MzgpIGF0IHN5c2NhbGwrMHgyMjAKPj4gWGludDB4ODBfc3lzY2FsbCgpIGF0IFhpbnQweDgwX3N5 c2NhbGwrMHgyMAo+PiAtLS0gc3lzY2FsbCAoNywgRnJlZUJTRCBFTEYzMiwgd2FpdDQpLCBlaXAg PSAweDI4MTY4MWViLCBlc3AgPSAweGJmYmZlNWJjLAo+PiBlYnAgPSAweGJmYmZlNWQ4IC0tLQo+ Pgo+Pgo+PiA8c25pcD4KPj4gSSBob3BlIHlvdSBkb24ndCByZWFsbHkgbmVlZCBhbGwgb2YgdGhl IHRyYWNlcywgSSdsbCBrZWVwIHRoZSBzeXN0ZW0gYXQKPj4gdGhlIEREQiBwcm9tcHQgZm9yIG5v dywgc28gSSBjYW4gZG8gb3RoZXIgc3R1ZmYuCj4KPiBJIHJlYWxseSBuZWVkIGFueSB0cmFjZSB0 aGF0IGlzIGludm9sdmVkIGluIHZmcy4gwqBJcyB0aGlzIG1hY2hpbmUgaG9va2VkIHRvCj4gYSBz ZXJpYWwgY29uc29sZSBmb3IgZGRiIHNvIHlvdSBjYW4gcGlwZSBvdXRwdXQgdG8gYSBmaWxlIHdp dGggc2NyaXB0KDEpPyDCoEkKPiB1bmRlcnN0YW5kIHRoZSBwYXRocyB0aGF0IGhvbGQgdGhlIGxv Y2tzIGJ1dCBJIGRvbid0IHVuZGVyc3RhbmQgd2hvIGlzCj4gZGVhZGxvY2tlZCBhZ2FpbnN0IGl0 LiDCoEl0IGxvb2tzIGxpa2UgdGhlIHRocmVhZCB0aGF0IGlzIGhvbGRpbmcgdGhlIGxvY2tzCj4g aXMganVzdCB3YWl0aW5nIG9uIGlvIHRvIGNvbXBsZXRlLiDCoFNvIHNvbWV0aGluZyB0aGF0IGNv bXBsZXRlcyBJTyBpcyBodW5nLgoKTWF5IHlvdSBwbGVhc2Ugc2hvdyB0aGUgJ3N5c2N0bCB2bScg cHJpbnRvdXQ/CgpBdHRpbGlvCgoKLS0gClBlYWNlIGNhbiBvbmx5IGJlIGFjaGlldmVkIGJ5IHVu ZGVyc3RhbmRpbmcgLSBBLiBFaW5zdGVpbgo= From owner-freebsd-current@FreeBSD.ORG Sun May 9 01:54:36 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 49510106564A; Sun, 9 May 2010 01:54:36 +0000 (UTC) (envelope-from nork@FreeBSD.org) Date: Sun, 9 May 2010 10:54:35 +0900 From: Norikatsu Shigemura To: Jung-uk Kim Message-Id: <20100509105435.766b9629.nork@FreeBSD.org> In-Reply-To: <201005051351.15012.jkim@FreeBSD.org> References: <20100505154312.49e7a2cc.nork@FreeBSD.org> <201005051351.15012.jkim@FreeBSD.org> X-Mailer: Sylpheed 3.0.0 (GTK+ 2.18.7; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: amdtemp(4) issue X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 May 2010 01:54:36 -0000 Hi jkim. On Wed, 5 May 2010 13:51:10 -0400 Jung-uk Kim wrote: > > 11 - 0x01 = +10C > > 11 - 0x18 = -13C > > 11 - 0x3f = -52C > > [*] http://support.amd.com/us/Processor_TechDocs/31116.pdf > AMD keeps flipping the sign from core to core. :-( Please see > AMDTEMP_FLAG_DO_SIGN for Family 0Fh, for example. In fact, Linux > driver (k10temp) does not care about the DiodeOffset at all. > Instead, they just say "input" temperature. Oh my god... OK, I see. > > I got following thermal related registers in amdtemp_gettemp > > function: May 5 15:06:53 nadesico kernel: amdtemp0: F3x64 Hardware > > Thermal Control(HTC) Register = 0x3a4c0005 May 5 15:06:53 nadesico > > kernel: amdtemp0: F3x68 Software Thermal Control(STC) Register = > > 0x10000000 May 5 15:06:53 nadesico kernel: amdtemp0: F3xA4 > > Reported Temperature Control Register = 0x000c1880 May 5 15:06:53 > > nadesico kernel: amdtemp0: F3xE4 Thermtrip Status Register > > = 0x1cc01830 May 5 15:06:53 nadesico kernel: amdtemp0: F3xE8 > > Northbridge Capabilities Register = 0x0207df19 > > But I don't have any idea to fix register's paraemters. Do you > > have any idea? > Sorry, I don't. You may find Linux k10temp driver > (drivers/hwmon/k10temp.c) useful, though. Thank you, I'll compare other implementations. From owner-freebsd-current@FreeBSD.ORG Sun May 9 02:59:24 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 712811065677 for ; Sun, 9 May 2010 02:59:24 +0000 (UTC) (envelope-from jamesbrandongooch@gmail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 2BC238FC0C for ; Sun, 9 May 2010 02:59:23 +0000 (UTC) Received: by gwaa20 with SMTP id a20so997149gwa.13 for ; Sat, 08 May 2010 19:59:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=vKTh6iX1yQ8cIygIwp8Py+LLslX9n49yUaZhwJME8vU=; b=vtg7+8tkXamz6prRnmJXPOJvb5WfCYtPGlVWK7BzJ+cK7fcmonHmhmasZKVUTOaatI 4wHGxCub55t/7QmJ8tgf9z3N9bIcAdcaSwOkh07XX2gR0z5jzdmol1ixwcn5NFIM/KTX hLcAZI/M6ys3NStxzPz5JVjj059WxN4Xy1Pq8= 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=Xuia9zIxws+uKy8iaXuR5k/9mXhhlSRuWn7lk/nek7376kkgUvsHkGoNnkH3Js52U2 w9hNqJI2wGsbz5LXZagmoFsj+CeeL9H8jHYG5wbU7QP0dIXwVl53i06GuVDIoAAHBpny 35xk6DUSh5IMyYYuW7bB7os82+sBicli16g/w= MIME-Version: 1.0 Received: by 10.231.191.138 with SMTP id dm10mr1124444ibb.73.1273373963224; Sat, 08 May 2010 19:59:23 -0700 (PDT) Received: by 10.231.115.3 with HTTP; Sat, 8 May 2010 19:59:23 -0700 (PDT) In-Reply-To: <20100508203549.GA8088@exodus.desync.com> References: <20100508200032.GB31100@weongyo> <20100508203549.GA8088@exodus.desync.com> Date: Sat, 8 May 2010 21:59:23 -0500 Message-ID: From: Brandon Gooch To: ben wilber Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Benjamin Kaduk , current@freebsd.org Subject: Re: a panic on uart_z8530_class? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 May 2010 02:59:24 -0000 On Sat, May 8, 2010 at 3:35 PM, ben wilber wrote: > On Sat, May 08, 2010 at 04:11:49PM -0400, Benjamin Kaduk wrote: >> > [root@test ~]# kgdb /boot/kernel/kernel /var/crash/vmcore.1 >> > GNU gdb 6.1.1 [FreeBSD] >> > Copyright 2004 Free Software Foundation, Inc. >> > GDB is free software, covered by the GNU General Public License, and y= ou are >> > welcome to change it and/or distribute copies of it under certain cond= itions. >> > Type "show copying" to see the conditions. >> > There is absolutely no warranty for GDB. =A0Type "show warranty" for d= etails. >> > This GDB was configured as "amd64-marcel-freebsd"... >> > Cannot access memory at address 0xffffff0127ffffe0 >> > (kgdb) bt >> > #0 =A00x0000000000000000 in ?? () >> > Cannot access memory at address 0x0 >> > (kgdb) q >> >> >> I have seen this behavior from kgdb --- it doesn't seem to be able to >> handle coredumps I've made recently. =A0At first I thought that I manage= d to >> trash either my kernel image or kgdb binary with all the unclean >> shutdowns I've been having, but if you're seeing kgdb failures, maybe it= 's >> not just my local system. >> >> Yet I am assuming that this is not broken for *everyone*, or we would ha= ve >> heard more noise about it. >> >> I'm running a current snapshot from April 4th; maybe I will try updating >> to a new snapshot tonight and see if kgdb behaves better after everythin= g >> is rebuilt. > > Same here, for the last couple months maybe. I'll chime in here with a "me too". Since at early April, I've been trying to figure out why my laptop locks up overnight (something about the CPUs going into C3). I can nearly always get it to coredump, but the vmcore files I generate are unusable... -Brandon From owner-freebsd-current@FreeBSD.ORG Sun May 9 03:54:43 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CF0BB1065675 for ; Sun, 9 May 2010 03:54:43 +0000 (UTC) (envelope-from yuri.pankov@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.152]) by mx1.freebsd.org (Postfix) with ESMTP id 51A2E8FC16 for ; Sun, 9 May 2010 03:54:42 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id 22so216000fge.13 for ; Sat, 08 May 2010 20:54:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received :x-authentication-warning:date:from:to:subject:message-id:references :mime-version:content-type:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=gghKwcrN63/d9jmUcyqjs3kBASEHtyGLfXHA3nTscXc=; b=I2q4MPtJIVfvhZS+ubmH9Z/4QgWVSg8Ep8BIrPhmq385rgVzvrx2P5FeMH7lQV2wrf MO14sHyyX6TpcXjdYA50eobkXZYfGoTCmAkNUFu6aR7Jb+8uKXbsNKai1wp/ArrAUlF2 QFeI8TcmnUNSixhM3eti+NBHJFTkb+H/mN5e8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=x-authentication-warning:date:from:to:subject:message-id:references :mime-version:content-type:content-disposition :content-transfer-encoding:in-reply-to:user-agent; b=SrWVgeE757hTHrv/NVVH4LEHUKzr/jJsLqDuwHstzMC2OujITxpDgHc7T8twBq+dvK 3PM1ViQspRistdcU1ZVQBSU6P+eHnKa5Rn1zwrNmZedo0dV+Bi4oaIgjm76p6oY0SNms 93X52CSvRdKhB2Yk3RdQmI+BCmLT/RKZDuAnY= Received: by 10.86.239.37 with SMTP id m37mr6576254fgh.72.1273375679756; Sat, 08 May 2010 20:27:59 -0700 (PDT) Received: from darklight.org.ru ([213.132.76.142]) by mx.google.com with ESMTPS id 22sm7020197fkq.17.2010.05.08.20.27.58 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 08 May 2010 20:27:59 -0700 (PDT) Received: from darklight.org.ru (yuri@darklight.org.ru [127.0.0.1]) by darklight.org.ru (8.14.4/8.14.4) with ESMTP id o493Ru32090330 for ; Sun, 9 May 2010 07:27:57 +0400 (MSD) (envelope-from yuri.pankov@gmail.com) Received: (from yuri@localhost) by darklight.org.ru (8.14.4/8.14.4/Submit) id o493Ruam090329 for freebsd-current@freebsd.org; Sun, 9 May 2010 07:27:56 +0400 (MSD) (envelope-from yuri.pankov@gmail.com) X-Authentication-Warning: darklight.org.ru: yuri set sender to yuri.pankov@gmail.com using -f Date: Sun, 9 May 2010 07:27:56 +0400 From: Yuri Pankov To: freebsd-current@freebsd.org Message-ID: <20100509032756.GA90127@darklight.org.ru> References: <20100508200032.GB31100@weongyo> <20100508203549.GA8088@exodus.desync.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: a panic on uart_z8530_class? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 May 2010 03:54:43 -0000 On Sat, May 08, 2010 at 09:59:23PM -0500, Brandon Gooch wrote: > On Sat, May 8, 2010 at 3:35 PM, ben wilber wrote: > > On Sat, May 08, 2010 at 04:11:49PM -0400, Benjamin Kaduk wrote: > >> > [root@test ~]# kgdb /boot/kernel/kernel /var/crash/vmcore.1 > >> > 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"... > >> > Cannot access memory at address 0xffffff0127ffffe0 > >> > (kgdb) bt > >> > #0  0x0000000000000000 in ?? () > >> > Cannot access memory at address 0x0 > >> > (kgdb) q > >> > >> > >> I have seen this behavior from kgdb --- it doesn't seem to be able to > >> handle coredumps I've made recently.  At first I thought that I managed to > >> trash either my kernel image or kgdb binary with all the unclean > >> shutdowns I've been having, but if you're seeing kgdb failures, maybe it's > >> not just my local system. > >> > >> Yet I am assuming that this is not broken for *everyone*, or we would have > >> heard more noise about it. > >> > >> I'm running a current snapshot from April 4th; maybe I will try updating > >> to a new snapshot tonight and see if kgdb behaves better after everything > >> is rebuilt. > > > > Same here, for the last couple months maybe. > > I'll chime in here with a "me too". > > Since at early April, I've been trying to figure out why my laptop > locks up overnight (something about the CPUs going into C3). I can > nearly always get it to coredump, but the vmcore files I generate are > unusable... > > -Brandon Just another "me too". May be we have something common in our setup? (I'm dumping to /dev/gpt/swap 8Gb GPT partition, using ahci(4) on a ATI IXP700 AHCI SATA controller). Another issue - dump is written extremely slow (1.5Gb in ~5 minutes). Yuri From owner-freebsd-current@FreeBSD.ORG Sun May 9 09:54:22 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0F2A4106567F for ; Sun, 9 May 2010 09:54:22 +0000 (UTC) (envelope-from joe@hostedcontent.com) Received: from mail01.fasti.net (mail01.fasti.net [216.105.91.156]) by mx1.freebsd.org (Postfix) with ESMTP id D2A708FC16 for ; Sun, 9 May 2010 09:54:21 +0000 (UTC) Received: from mail01.fasti.net (localhost [127.0.0.2]) by mail01.fasti.net (Postfix) with ESMTP id F0AC094B103C; Sun, 9 May 2010 05:54:20 -0400 (EDT) X-Virus-Scanned: amavisd-new at fasti.net Received: from mail01.fasti.net ([127.0.0.2]) by mail01.fasti.net (mail01.fasti.net [127.0.0.2]) (amavisd-new, port 10024) with ESMTP id 6o0bZVORbxQM; Sun, 9 May 2010 05:54:19 -0400 (EDT) Received: from [192.168.1.137] (69-165-175-27.dsl.teksavvy.com [69.165.175.27]) by mail01.fasti.net (Postfix) with ESMTPA id 251DE94B103A; Sun, 9 May 2010 05:54:19 -0400 (EDT) Message-ID: <4BE6864B.5060906@hostedcontent.com> Date: Sun, 09 May 2010 05:54:19 -0400 From: joe User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Jack Vogel References: <4BE565E5.9030505@hostedcontent.com> <4BE529FF.5000008@hostedcontent.com> <4BE59434.9070308@hostedcontent.com> <4BE599B0.60203@hostedcontent.com> <4BE59DBD.4000105@hostedcontent.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ian FREISLICH , Fabien Thomas , freebsd-current@freebsd.org Subject: Re: igb broken? Unexplained weirdness with intel 82576 nics on a supermicro board. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 May 2010 09:54:22 -0000 On 05/08/2010 02:21 PM, Jack Vogel wrote: > The cable, its a simple thing but make SURE you try that, a slightly > damaged one can do weird things and its quick to check, don't overlook > it. > > Jack > > > On Sat, May 8, 2010 at 10:22 AM, joe > wrote: > > On 05/08/2010 01:53 PM, Jack Vogel wrote: > > I still am not clear on this system, how many ports are on it, > and its > an 82576? > Sounds to me like you've proven its not on the box if you can do > fine > when its > on its own. So change ports in the switch, as I said, change > cables, must be > something in that environment. > > Jack > > > On Sat, May 8, 2010 at 10:04 AM, joe > >> > wrote: > > On 05/08/2010 01:31 PM, Jack Vogel wrote: > > Looks like something to do with system C, you might > isolate it, > and try > a back > to back connection with its NICs, change cables, look at > BIOS > settings, > change > the slot the nic is in... All just off the top of my head. > > Jack > > > On Sat, May 8, 2010 at 9:41 AM, joe > > > > > >>> > > wrote: > > On 05/08/2010 11:17 AM, Ian FREISLICH wrote: > > joe wrote: > > On 05/08/2010 06:55 AM, Ian FREISLICH wrote: > > joe wrote: > > I have just tried your > suggeston and > it has > no effect for me ;( > > > Do you have another brand of NIC that > you can > try? At > least that > will isolate whether it's igb(4) or > something else. > > > I will grab a new nic today and try...my > options are > limited > though. > Here are the nics i can get my hands on > > TP-LINK TL-TG3468, 10/100/1000Mbps PCIe Adapter > (supported > by fbsd?) > > > Based on the RTL8168B chip. Should be supported > by the > re(4) > driver. > > Intel (EXPI9301CT) Gigabit CT Desktop > Adapter (yet > another > intel nic) > > > i82574L chip. Should be supported by the em(4) > driver. > I have had > good performance in the past with this driver > and less than > satisfactory performance with the igb(4) driver. > > That may not be your problem though. Before you > go out > and buy, > have a look at the amount of interrupt time your > slow > machine spends > in 'top' or 'systat -vm'. systat will also show the > interrupt rate > for each driver, perhaps it's not doing > interrupt moderation > properly. > This will manifest as more than about a 1000 per > second. > There are > loader tunables for the driver to increase the > number of > transfer > descriptors and to tune interrupt moderation. > > You could try running trafshow (port) on the > interface while > performing the transfer. Perhaps promiscuous > mode will > turn off > some hardware feature that will improve things. > It may > however > break hardware vlanning as it does on my 82575GB > 4 port > igb card. > > Ian > > -- > Ian Freislich > > > I bought those two cards anyways, im in a rush to > figure out > this > problem. That being said i am still encountering the > exact same > problem regardless on which network card i am > running. I am at a > complete loss. I am about to try a raid card to see > if the > problem > might lay within the onboard sata ports. I did pull the > server and > brought it home so that i can test more things quicker. > > I am going to try using a raid card instead of the > onboard sata > ports and see if i still encounter the same problem. > I would > love > any suggestions you may have on where to go from here to > figure out > where the problem might be. > > joe > > _______________________________________________ > freebsd-current@freebsd.org > > > > >> > > mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org > > > > > >>" > > > > I think it might have something to so with the nics / > switch, and > their features. I brought the box home, plugged into my gb > switch, > and i am able to FTP data to the server at around 35MB/sec. > > I dont know what would cause this other than some sort of > issue with > the the 3 different types of nics and the switch i am using. > > Any suggestions? > > > > There are two embedded intel 82576 nics on this motherboard. I do > believe i have proven it is not the box itself as it is capable of > high incoming throughput. I have other servers on the switch which > do 55MB/sec without issues. I believe it is a combination of this > server and/or the nics i have and the switch i am using. It's the > only logical explanation if i get the desired throughput on my home > switch but not on the switch that is collocated. I will try updating > the firmware of the switch tonight as well as bringing the switch i > use at home with me. > > Here is a follow-up just incase anyone ever encounters this problem again. I updated the firmware on the switch, made sure jumbo packets were enabled, and the switch was restarted. I'm now seeing the throughput i had expected on this box! 897755008 bytes received in 00:11 (72.74 MB/s) Once again, thank you all for the help! Joe From owner-freebsd-current@FreeBSD.ORG Sun May 9 14:58:34 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6C0E0106566C for ; Sun, 9 May 2010 14:58:34 +0000 (UTC) (envelope-from nyan@FreeBSD.org) Received: from sakura.ccs.furiru.org (s195024.ppp.asahi-net.or.jp [220.157.195.24]) by mx1.freebsd.org (Postfix) with ESMTP id 03C9D8FC08 for ; Sun, 9 May 2010 14:58:33 +0000 (UTC) Received: from localhost (authenticated bits=0) by sakura.ccs.furiru.org (unknown) with ESMTP id o49EgmoP011625 for ; Sun, 9 May 2010 23:42:51 +0900 (JST) (envelope-from nyan@FreeBSD.org) Date: Sun, 09 May 2010 23:42:47 +0900 (JST) Message-Id: <20100509.234247.98947977.nyan@FreeBSD.org> To: current@freebsd.org From: TAKAHASHI Yoshihiro X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Subject: Today's snapshot is broken X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 May 2010 14:58:34 -0000 Today's snapshot for pc98 (and other archs) is broken. Building 9.0-CURRENT-20100509-SNAP is failed. Last 50 lines of logfile are: cc -Os -pipe -c minigzip_stub.c ld -dc -r -o minigzip.lo minigzip_stub.o /usr/obj/pc98//usr/src/usr.bin/minigzip/minigzip.o crunchide -k _crunched_minigzip_stub minigzip.lo echo "int _crunched_sed_stub(int argc, char **argv, char **envp){return main(argc,argv,envp);}" >sed_stub.c cc -Os -pipe -c sed_stub.c ld -dc -r -o sed.lo sed_stub.o /usr/obj/pc98//usr/src/usr.bin/sed/compile.o /usr/obj/pc98//usr/src/usr.bin/sed/main.o /usr/obj/pc98//usr/src/usr.bin/sed/misc.o /usr/obj/pc98//usr/src/usr.bin/sed/process.o crunchide -k _crunched_sed_stub sed.lo echo "int _crunched_arp_stub(int argc, char **argv, char **envp){return main(argc,argv,envp);}" >arp_stub.c cc -Os -pipe -c arp_stub.c ld -dc -r -o arp.lo arp_stub.o /usr/obj/pc98//usr/src/usr.sbin/arp/arp.o crunchide -k _crunched_arp_stub arp.lo echo "int _crunched_ppp_stub(int argc, char **argv, char **envp){return main(argc,argv,envp);}" >ppp_stub.c cc -Os -pipe -c ppp_stub.c ld -dc -r -o ppp.lo ppp_stub.o /usr/obj/pc98//usr/src/usr.sbin/ppp/acf.o /usr/obj/pc98//usr/src/usr.sbin/ppp/arp.o /usr/obj/pc98//usr/src/usr.sbin/ppp/async.o /usr/obj/pc98//usr/src/usr.sbin/ppp/auth.o /usr/obj/pc98//usr/src/usr.sbin/ppp/bundle.o /usr/obj/pc98//usr/src/usr.sbin/ppp/cbcp.o /usr/obj/pc98//usr/src/usr.sbin/ppp/ccp.o /usr/obj/pc98//usr/src/usr.sbin/ppp/chap.o /usr/obj/pc98//usr/src/usr.sbin/ppp/chat.o /usr/obj/pc98//usr/src/usr.sbin/ppp/command.o /usr/obj/pc98//usr/src/usr.sbin/ppp/datalink.o /usr/obj/pc98//usr/src/usr.sbin/ppp/deflate.o /usr/obj/pc98//usr/src/usr.sbin/ppp/defs.o /usr/obj/pc98//usr/src/usr.sbin/ppp/exec.o /usr/obj/pc98//usr/src/usr.sbin/ppp/filter.o /usr/obj/pc98//usr/src/usr.sbin/ppp/fsm.o /usr/obj/pc98//usr/src/usr.sbin/ppp/hdlc.o /usr/obj/pc98//usr/src/usr.sbin/ppp/iface.o /usr/obj/pc98//usr/src/usr.sbin/ppp/ip.o /usr/obj/pc98//usr/src/usr.sbin/ppp/ipcp.o /usr/obj/pc98//usr/src/usr.sbin/ppp/ipv6cp.o /usr/obj/pc98//usr/src/usr.sbin/ppp/iplist.o /usr/obj/pc98//usr/src/usr.sbin/ppp/lcp.o /usr/obj/pc98//usr/src/usr.sbin/ppp/link.o /usr/obj/pc98//usr/src/usr.sbin/ppp/log.o /usr/obj/pc98//usr/src/usr.sbin/ppp/lqr.o /usr/obj/pc98//usr/src/usr.sbin/ppp/main.o /usr/obj/pc98//usr/src/usr.sbin/ppp/mbuf.o /usr/obj/pc98//usr/src/usr.sbin/ppp/mp.o /usr/obj/pc98//usr/src/usr.sbin/ppp/ncp.o /usr/obj/pc98//usr/src/usr.sbin/ppp/ncpaddr.o /usr/obj/pc98//usr/src/usr.sbin/ppp/pap.o /usr/obj/pc98//usr/src/usr.sbin/ppp/physical.o /usr/obj/pc98//usr/src/usr.sbin/ppp/pred.o /usr/obj/pc98//usr/src/usr.sbin/ppp/probe.o /usr/obj/pc98//usr/src/usr.sbin/ppp/prompt.o /usr/obj/pc98//usr/src/usr.sbin/ppp/proto.o /usr/obj/pc98//usr/src/usr.sbin/ppp/route.o /usr/obj/pc98//usr/src/usr.sbin/ppp/server.o /usr/obj/pc98//usr/src/usr.sbin/ppp/sig.o /usr/obj/pc98//usr/src/usr.sbin/ppp/slcompress.o /usr/obj/pc98//usr/src/usr.sbin/ppp/sync.o /usr/obj/pc98//usr/src/usr.sbin/ppp/systems.o /usr/obj/pc98//usr/src/usr.sbin/ppp/tcp.o /usr/obj/pc98//usr/src/usr.sbin/ppp/tcpmss.o /usr/obj/pc98//usr/src/usr.sbin/ppp/throughput.o /usr/obj/pc98//usr/src/usr.sbin/ppp/timer.o /usr/obj/pc98//usr/src/usr.sbin/ppp/tty.o /usr/obj/pc98//usr/src/usr.sbin/ppp/tun.o /usr/obj/pc98//usr/src/usr.sbin/ppp/udp.o /usr/obj/pc98//usr/src/usr.sbin/ppp/vjcomp.o /usr/obj/pc98//usr/src/usr.sbin/ppp/ether.o crunchide -k _crunched_ppp_stub ppp.lo echo "int _crunched_sysinstall_stub(int argc, char **argv, char **envp){return main(argc,argv,envp);}" >sysinstall_stub.c cc -Os -pipe -c sysinstall_stub.c ld -dc -r -o sysinstall.lo sysinstall_stub.o /usr/obj/pc98//usr/src/usr.sbin/sysinstall/anonFTP.o /usr/obj/pc98//usr/src/usr.sbin/sysinstall/cdrom.o /usr/obj/pc98//usr/src/usr.sbin/sysinstall/command.o /usr/obj/pc98//usr/src/usr.sbin/sysinstall/config.o /usr/obj/pc98//usr/src/usr.sbin/sysinstall/devices.o /usr/obj/pc98//usr/src/usr.sbin/sysinstall/dhcp.o /usr/obj/pc98//usr/src/usr.sbin/sysinstall/disks.o /usr/obj/pc98//usr/src/usr.sbin/sysinstall/dispatch.o /usr/obj/pc98//usr/src/usr.sbin/sysinstall/dist.o /usr/obj/pc98//usr/src/usr.sbin/sysinstall/dmenu.o /usr/obj/pc98//usr/src/usr.sbin/sysinstall/doc.o /usr/obj/pc98//usr/src/usr.sbin/sysinstall/dos.o /usr/obj/pc98//usr/src/usr.sbin/sysinstall/floppy.o /usr/obj/pc98//usr/src/usr.sbin/sysinstall/ftp.o /usr/obj/pc98//usr/src/usr.sbin/sysinstall/globals.o /usr/obj/pc98//usr/src/usr.sbin/sysinstall/http.o /usr/obj/pc98//usr/src/usr.sbin/sysinstall/index.o /usr/obj/pc98//usr/src/usr.sbin/sysinstall/install.o /usr/obj/pc98//usr/src/usr.sbin/sysinstall/installUpgrade.o /usr/obj/pc98//usr/src/usr.sbin/sysinstall/keymap.o /usr/obj/pc98//usr/src/usr.sbin/sysinstall/label.o /usr/obj/pc98//usr/src/usr.sbin/sysinstall/main.o /usr/obj/pc98//usr/src/usr.sbin/sysinstall/makedevs.o /usr/obj/pc98//usr/src/usr.sbin/sysinstall/media.o /usr/obj/pc98//usr/src/usr.sbin/sysinstall/menus.o /usr/obj/pc98//usr/src/usr.sbin/sysinstall/misc.o /usr/obj/pc98//usr/src/usr.sbin/sysinstall/modules.o /usr/obj/pc98//usr/src/usr.sbin/sysinstall/mouse.o /usr/obj/pc98//usr/src/usr.sbin/sysinstall/msg.o /usr/obj/pc98//usr/src/usr.sbin/sysinstall/network.o /usr/obj/pc98//usr/src/usr.sbin/sysinstall/nfs.o /usr/obj/pc98//usr/src/usr.sbin/sysinstall/options.o /usr/obj/pc98//usr/src/usr.sbin/sysinstall/package.o /usr/obj/pc98//usr/src/usr.sbin/sysinstall/system.o /usr/obj/pc98//usr/src/usr.sbin/sysinstall/tcpip.o /usr/obj/pc98//usr/src/usr.sbin/sysinstall/termcap.o /usr/obj/pc98//usr/src/usr.sbin/sysinstall/ttys.o /usr/obj/pc98//usr/src/usr.sbin/sysinstall/ufs.o /usr/obj/pc98//usr/src/usr.sbin/sysinstall/usb.o /usr/obj/pc98//usr/src/usr.sbin/sysinstall/user.o /usr/obj/pc98//usr/src/usr.sbin/sysinstall/variable.o /usr/obj/pc98//usr/src/usr.sbin/sysinstall/wizard.o crunchide -k _crunched_sysinstall_stub sysinstall.lo cc -static -o boot_crunch boot_crunch.o hostname.lo pwd.lo rm.lo sh.lo test.lo camcontrol.lo dhclient.lo fsck_ffs.lo ifconfig.lo mount_nfs.lo newfs.lo route.lo rtsol.lo tunefs.lo cpio.lo find.lo minigzip.lo sed.lo arp.lo ppp.lo sysinstall.lo -ll -ledit -lutil -lmd -lcrypt -lftpio -lz -lnetgraph -ldialog -lncurses -ldisk -lcam -lsbuf -lufs -lbsdxml -larchive -lbz2 -ljail /usr/obj/pc98/usr/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0x9e8): In function `archive_write_mtree_finish_entry': : undefined reference to `SHA1_Final' /usr/obj/pc98/usr/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0xa2e): In function `archive_write_mtree_finish_entry': : undefined reference to `RIPEMD160_Final' /usr/obj/pc98/usr/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0xa78): In function `archive_write_mtree_finish_entry': : undefined reference to `MD5_Final' /usr/obj/pc98/usr/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0xe43): In function `archive_write_mtree_data': : undefined reference to `SHA1_Update' /usr/obj/pc98/usr/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0xe63): In function `archive_write_mtree_data': : undefined reference to `MD5_Update' /usr/obj/pc98/usr/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0xe8b): In function `archive_write_mtree_data': : undefined reference to `RIPEMD160_Update' /usr/obj/pc98/usr/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0x1297): In function `archive_write_mtree_header': : undefined reference to `SHA1_Init' /usr/obj/pc98/usr/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0x12c7): In function `archive_write_mtree_header': : undefined reference to `RIPEMD160_Init' /usr/obj/pc98/usr/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0x12f4): In function `archive_write_mtree_header': : undefined reference to `MD5_Init' *** Error code 1 Stop in /usr/obj/usr/src/release/boot_crunch. *** Error code 1 Stop in /usr/src/release. + umount /dev *** Error code 1 --- TAKAHASHI Yoshihiro From owner-freebsd-current@FreeBSD.ORG Sun May 9 17:14:36 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BFE47106566C for ; Sun, 9 May 2010 17:14:36 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-ww0-f54.google.com (mail-ww0-f54.google.com [74.125.82.54]) by mx1.freebsd.org (Postfix) with ESMTP id 28EB08FC12 for ; Sun, 9 May 2010 17:14:35 +0000 (UTC) Received: by wwd20 with SMTP id 20so642820wwd.13 for ; Sun, 09 May 2010 10:14:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=lXkL1qyj7A9oFe0rsYDZ8OQ3WAOLznn/ICzLvQVVq4M=; b=QF8hi3dEXJjC1VKNuAMk7Dxza8OO2DQQa4LV9pcmFpIhMQHU5zsF9n4+kVC68LNFXS 8kgmhhTJUtjZz4JH/846tlyQ6r3+VYL/hKopE6ZTTHg+nou72QM3ALXZ/aEungmN5yT8 Fn0tA2y+s/OquWYf3K8D5k+0miGMNw835Ikok= 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; b=vnHel0k4Sd6j1+OpQ/YosVayvc3QKFO66m8zPDCVJeT+J048+Zywh+wu+6ppQ4HYQu gE4/WR5do+IfmJCAdjEK6TG1VGf/h263XvHtSfY/SLp5LgJHmNnf63DyRx+TLY0oHZDB YsO29BHh07T6krlg7CBWUehGhUazMBa9wYQMk= MIME-Version: 1.0 Received: by 10.216.161.14 with SMTP id v14mr1650557wek.179.1273425275228; Sun, 09 May 2010 10:14:35 -0700 (PDT) Received: by 10.216.29.129 with HTTP; Sun, 9 May 2010 10:14:35 -0700 (PDT) In-Reply-To: <4BE6864B.5060906@hostedcontent.com> References: <4BE565E5.9030505@hostedcontent.com> <4BE59434.9070308@hostedcontent.com> <4BE599B0.60203@hostedcontent.com> <4BE59DBD.4000105@hostedcontent.com> <4BE6864B.5060906@hostedcontent.com> Date: Sun, 9 May 2010 10:14:35 -0700 Message-ID: From: Jack Vogel To: joe Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Ian FREISLICH , Fabien Thomas , freebsd-current@freebsd.org Subject: Re: igb broken? Unexplained weirdness with intel 82576 nics on a supermicro board. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 May 2010 17:14:36 -0000 On Sun, May 9, 2010 at 2:54 AM, joe wrote: > On 05/08/2010 02:21 PM, Jack Vogel wrote: > >> The cable, its a simple thing but make SURE you try that, a slightly >> damaged one can do weird things and its quick to check, don't overlook >> it. >> >> Jack >> >> >> On Sat, May 8, 2010 at 10:22 AM, joe > > wrote: >> >> On 05/08/2010 01:53 PM, Jack Vogel wrote: >> >> I still am not clear on this system, how many ports are on it, >> and its >> an 82576? >> Sounds to me like you've proven its not on the box if you can do >> fine >> when its >> on its own. So change ports in the switch, as I said, change >> cables, must be >> something in that environment. >> >> Jack >> >> >> On Sat, May 8, 2010 at 10:04 AM, joe > >> >> >> wrote: >> >> On 05/08/2010 01:31 PM, Jack Vogel wrote: >> >> Looks like something to do with system C, you might >> isolate it, >> and try >> a back >> to back connection with its NICs, change cables, look at >> BIOS >> settings, >> change >> the slot the nic is in... All just off the top of my head. >> >> Jack >> >> >> On Sat, May 8, 2010 at 9:41 AM, joe >> >> > >> >> >>> >> >> wrote: >> >> On 05/08/2010 11:17 AM, Ian FREISLICH wrote: >> >> joe wrote: >> >> On 05/08/2010 06:55 AM, Ian FREISLICH wrote: >> >> joe wrote: >> >> I have just tried your >> suggeston and >> it has >> no effect for me ;( >> >> >> Do you have another brand of NIC that >> you can >> try? At >> least that >> will isolate whether it's igb(4) or >> something else. >> >> >> I will grab a new nic today and try...my >> options are >> limited >> though. >> Here are the nics i can get my hands on >> >> TP-LINK TL-TG3468, 10/100/1000Mbps PCIe Adapter >> (supported >> by fbsd?) >> >> >> Based on the RTL8168B chip. Should be supported >> by the >> re(4) >> driver. >> >> Intel (EXPI9301CT) Gigabit CT Desktop >> Adapter (yet >> another >> intel nic) >> >> >> i82574L chip. Should be supported by the em(4) >> driver. >> I have had >> good performance in the past with this driver >> and less than >> satisfactory performance with the igb(4) driver. >> >> That may not be your problem though. Before you >> go out >> and buy, >> have a look at the amount of interrupt time your >> slow >> machine spends >> in 'top' or 'systat -vm'. systat will also show >> the >> interrupt rate >> for each driver, perhaps it's not doing >> interrupt moderation >> properly. >> This will manifest as more than about a 1000 per >> second. >> There are >> loader tunables for the driver to increase the >> number of >> transfer >> descriptors and to tune interrupt moderation. >> >> You could try running trafshow (port) on the >> interface while >> performing the transfer. Perhaps promiscuous >> mode will >> turn off >> some hardware feature that will improve things. >> It may >> however >> break hardware vlanning as it does on my 82575GB >> 4 port >> igb card. >> >> Ian >> >> -- >> Ian Freislich >> >> >> I bought those two cards anyways, im in a rush to >> figure out >> this >> problem. That being said i am still encountering the >> exact same >> problem regardless on which network card i am >> running. I am at a >> complete loss. I am about to try a raid card to see >> if the >> problem >> might lay within the onboard sata ports. I did pull the >> server and >> brought it home so that i can test more things quicker. >> >> I am going to try using a raid card instead of the >> onboard sata >> ports and see if i still encounter the same problem. >> I would >> love >> any suggestions you may have on where to go from here >> to >> figure out >> where the problem might be. >> >> joe >> >> _______________________________________________ >> freebsd-current@freebsd.org >> > > >> > >> > >> >> >> mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to >> "freebsd-current-unsubscribe@freebsd.org >> >> > > >> > >> > >>" >> >> >> >> I think it might have something to so with the nics / >> switch, and >> their features. I brought the box home, plugged into my gb >> switch, >> and i am able to FTP data to the server at around 35MB/sec. >> >> I dont know what would cause this other than some sort of >> issue with >> the the 3 different types of nics and the switch i am using. >> >> Any suggestions? >> >> >> >> There are two embedded intel 82576 nics on this motherboard. I do >> believe i have proven it is not the box itself as it is capable of >> high incoming throughput. I have other servers on the switch which >> do 55MB/sec without issues. I believe it is a combination of this >> server and/or the nics i have and the switch i am using. It's the >> only logical explanation if i get the desired throughput on my home >> switch but not on the switch that is collocated. I will try updating >> the firmware of the switch tonight as well as bringing the switch i >> use at home with me. >> >> >> > Here is a follow-up just incase anyone ever encounters this problem again. > I updated the firmware on the switch, made sure jumbo packets were enabled, > and the switch was restarted. I'm now seeing the throughput i had expected > on this box! > > 897755008 bytes received in 00:11 (72.74 MB/s) > > Once again, thank you all for the help! > > Joe > Glad the issue is resolved Joe. Jack From owner-freebsd-current@FreeBSD.ORG Sun May 9 19:29:33 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B5C8C1065680 for ; Sun, 9 May 2010 19:29:33 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-6.mit.edu (DMZ-MAILSEC-SCANNER-6.MIT.EDU [18.7.68.35]) by mx1.freebsd.org (Postfix) with ESMTP id 6E9E58FC1E for ; Sun, 9 May 2010 19:29:33 +0000 (UTC) X-AuditID: 12074423-b7c0bae0000030f0-09-4be70d1c54fd Received: from mailhub-auth-1.mit.edu (MAILHUB-AUTH-1.MIT.EDU [18.9.21.35]) by dmz-mailsec-scanner-6.mit.edu (Symantec Brightmail Gateway) with SMTP id AE.29.12528.C1D07EB4; Sun, 9 May 2010 15:29:32 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id o49JTWpY021864 for ; Sun, 9 May 2010 15:29:32 -0400 Received: from multics.mit.edu (MULTICS.MIT.EDU [18.187.1.73]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id o49JTUU5010639 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sun, 9 May 2010 15:29:32 -0400 (EDT) Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id o49JTUoT017985; Sun, 9 May 2010 15:29:30 -0400 (EDT) Date: Sun, 9 May 2010 15:29:30 -0400 (EDT) From: Benjamin Kaduk To: freebsd-current@freebsd.org In-Reply-To: <20100509032756.GA90127@darklight.org.ru> Message-ID: References: <20100508200032.GB31100@weongyo> <20100508203549.GA8088@exodus.desync.com> <20100509032756.GA90127@darklight.org.ru> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Brightmail-Tracker: AAAAAA== Subject: Re: a panic on uart_z8530_class? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 May 2010 19:29:33 -0000 On Sun, 9 May 2010, Yuri Pankov wrote: > On Sat, May 08, 2010 at 09:59:23PM -0500, Brandon Gooch wrote: >> Since at early April, I've been trying to figure out why my laptop >> locks up overnight (something about the CPUs going into C3). I can >> nearly always get it to coredump, but the vmcore files I generate are >> unusable... My cores are not *completely* unuseable -- I can (e.g.) walk the process tree starting at allproc, and things look sane, but kgdb's 'proc' command claims that all PIDs are invalid, and doesn't give me backtraces. >> >> -Brandon > > Just another "me too". May be we have something common in our setup? > (I'm dumping to /dev/gpt/swap 8Gb GPT partition, using ahci(4) on a ATI > IXP700 AHCI SATA controller). > > Another issue - dump is written extremely slow (1.5Gb in ~5 minutes). I am more inclined to believe that this is a kgdb bug than a problem with the dump itself, but I am running on atapci0: AHCI v1.20 (Intel ICH9 family). (Old-ish) dmesg and pciconf may be found in http://stuff.mit.edu/afs/sipb.mit.edu/user/kaduk/freebsd/glossolalia/ -Ben From owner-freebsd-current@FreeBSD.ORG Sun May 9 20:27:06 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 86DD71065674 for ; Sun, 9 May 2010 20:27:06 +0000 (UTC) (envelope-from jamesbrandongooch@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3D6A98FC18 for ; Sun, 9 May 2010 20:27:05 +0000 (UTC) Received: by gyh20 with SMTP id 20so1624788gyh.13 for ; Sun, 09 May 2010 13:27:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=8kcsceGeddOg5GgqLMhvSao8mO9uwUWeyJi+M1o5/wA=; b=iJiVhB8Wg82AdCi20fx0G2EGEkjj47dsdQ9Z66dnZwhRMlMJ5zBS89QncalBFn6tgl Fl+ki19OhLkNdLHTv+6EnFGUq2C2HhsvxEYlmEBDhhQRPSZ7eOnw2BkZout+HlQbQzz6 srij5lvG3SO8GwsMB3ReznD2f3WibSApON8OQ= 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=aoYHaoR0lNeqX1iM1/MJxrGg9rVwihF0sIUr3F3YU5ZwvVGb1S7BZnIV6iYy9YMLna pndJFdv8YhWalNRBPHc08AN6wmdaHocJbdHmPABV3pcsyH7lPSSi71ijwaGlknNrQS1I visfOBX7QKln2Mu29WG2UJ7kC3Eif9kjIC9zw= MIME-Version: 1.0 Received: by 10.231.143.137 with SMTP id v9mr1172297ibu.70.1273436825179; Sun, 09 May 2010 13:27:05 -0700 (PDT) Received: by 10.231.115.3 with HTTP; Sun, 9 May 2010 13:27:05 -0700 (PDT) In-Reply-To: <20100509032756.GA90127@darklight.org.ru> References: <20100508200032.GB31100@weongyo> <20100508203549.GA8088@exodus.desync.com> <20100509032756.GA90127@darklight.org.ru> Date: Sun, 9 May 2010 15:27:05 -0500 Message-ID: From: Brandon Gooch To: Yuri Pankov Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: a panic on uart_z8530_class? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 May 2010 20:27:06 -0000 On Sat, May 8, 2010 at 10:27 PM, Yuri Pankov wrote: > On Sat, May 08, 2010 at 09:59:23PM -0500, Brandon Gooch wrote: >> On Sat, May 8, 2010 at 3:35 PM, ben wilber wrote: >> > On Sat, May 08, 2010 at 04:11:49PM -0400, Benjamin Kaduk wrote: >> >> > [root@test ~]# kgdb /boot/kernel/kernel /var/crash/vmcore.1 >> >> > GNU gdb 6.1.1 [FreeBSD] >> >> > Copyright 2004 Free Software Foundation, Inc. >> >> > GDB is free software, covered by the GNU General Public License, an= d you are >> >> > welcome to change it and/or distribute copies of it under certain c= onditions. >> >> > Type "show copying" to see the conditions. >> >> > There is absolutely no warranty for GDB. =A0Type "show warranty" fo= r details. >> >> > This GDB was configured as "amd64-marcel-freebsd"... >> >> > Cannot access memory at address 0xffffff0127ffffe0 >> >> > (kgdb) bt >> >> > #0 =A00x0000000000000000 in ?? () >> >> > Cannot access memory at address 0x0 >> >> > (kgdb) q >> >> >> >> >> >> I have seen this behavior from kgdb --- it doesn't seem to be able to >> >> handle coredumps I've made recently. =A0At first I thought that I man= aged to >> >> trash either my kernel image or kgdb binary with all the unclean >> >> shutdowns I've been having, but if you're seeing kgdb failures, maybe= it's >> >> not just my local system. >> >> >> >> Yet I am assuming that this is not broken for *everyone*, or we would= have >> >> heard more noise about it. >> >> >> >> I'm running a current snapshot from April 4th; maybe I will try updat= ing >> >> to a new snapshot tonight and see if kgdb behaves better after everyt= hing >> >> is rebuilt. >> > >> > Same here, for the last couple months maybe. >> >> I'll chime in here with a "me too". >> >> Since at early April, I've been trying to figure out why my laptop >> locks up overnight (something about the CPUs going into C3). I can >> nearly always get it to coredump, but the vmcore files I generate are >> unusable... >> >> -Brandon > > Just another "me too". May be we have something common in our setup? > (I'm dumping to /dev/gpt/swap 8Gb GPT partition, using ahci(4) on a ATI > IXP700 AHCI SATA controller). > > Another issue - dump is written extremely slow (1.5Gb in ~5 minutes). I'm dumping to /dev/gpt/swap0 and yes, the dump is VERY slow. I've only recently began doing dumps, so I have little to compare the experience to -- although it does seem to have been slowing down now for a while :( I'm actually in the middle of doadump() right now, and it's been about 4 minutes, and I'm not even halfway done... --Brandon From owner-freebsd-current@FreeBSD.ORG Mon May 10 02:50:33 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9AB601065674; Mon, 10 May 2010 02:50:33 +0000 (UTC) (envelope-from jamesbrandongooch@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3EB7C8FC16; Mon, 10 May 2010 02:50:32 +0000 (UTC) Received: by gyh20 with SMTP id 20so1738949gyh.13 for ; Sun, 09 May 2010 19:50:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=t4r9RzuY9TTbjX1xgC1AL1dwehExQe2VIJ0KukSVZRY=; b=SFq3PeJckO0ZyokvvZQlNPerK4MYIbdt77kZfY5rE1zs59vr3StWEg21+Ve0jmOb2H zo+JM08BN4AX1pLdko3MGXcX+tin/qV9FWhEDKp820eWvgfUIDy82GzSB3iPp2cFh9jk vVrQr9XCiWYGMwogBSrhA7hDvlzw2RxvMP0No= 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=VRw+2N0Tx2B195/TCcny7S3mQy1ASKPZSXw4f8esYbzeAJ5V7MZPQQreUOvhhrWYfJ W51BUgp0e1fnxxxltMXi1gwVAW0H7zDdFL0L+mFltxbnIdGT/H/XjfmnAnpqJpDiv18u uBHUDhTn5RmQdMLS7xvj9LILBDoDQOJFCPJc0= MIME-Version: 1.0 Received: by 10.231.160.142 with SMTP id n14mr2042313ibx.52.1273459831910; Sun, 09 May 2010 19:50:31 -0700 (PDT) Received: by 10.231.115.3 with HTTP; Sun, 9 May 2010 19:50:31 -0700 (PDT) In-Reply-To: References: Date: Sun, 9 May 2010 21:50:31 -0500 Message-ID: From: Brandon Gooch To: Kip Macy Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: bf1783@gmail.com, alc@freebsd.org, freebsd-current@freebsd.org Subject: Re: Recent sys/vm/ changes and nvidia-driver X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 02:50:33 -0000 On Sat, May 8, 2010 at 4:44 PM, Kip Macy wrote: > On Sat, May 8, 2010 at 2:39 PM, Brandon Gooch > wrote: >> On Sat, May 8, 2010 at 4:20 PM, b. f. wrote: >>> On 05/08/10 13:36, Alan Cox wrote: >>>> Doug Barton wrote: >>>>> On 05/05/10 11:56, Alan Cox wrote: >>>>> >>>>>> I'm afraid that I would advise waiting a few days. =A0This round of >>>>>> changes >>>>>> are not yet complete. >>> >>> What performance differences, if any, can we expect on uniprocessors >>> from the vm page lock-related changes? Kip's original post on -arch >>> mentioned some performance improvements and no significant >>> regressions, but on a dual 4-core machine. >> >> Alan (or Kip): Is there a document available that describes the work >> being done on the VM system? >> >> I would like to -- or like make and attempt to -- read such a document..= . >> >> Hey b. f., to which post on -arch are you referring? > > there is no document. The basic idea is straightforward, but there are > some unpleasant edges to cope with. > > http://www.mavetju.org/mail/view_message.php?list=3Dfreebsd-arch&id=3D315= 5260&thread=3Dno Thanks for the link, surprisingly, I think I "get it" and it does actually make sense to me :) Is there a final "target state" regarding the work and/or a time-frame for completion? Perhaps a "heads-up" e-mail to the freebsd-current mailing list when the first round of commits have settled in? I'm wondering, due to the Nvidia issue stated in this thread, as well as panics I'm seeing using VirtualBox on my computer running HEAD. Thank you so much for taking on this task, all of you, Kip, Alan, and Jeff too -- even though I don't understand all of it, or know about all of the work that goes in to get it done, we all appreciate and benefit from the end result: a faster and better FreeBSD. -Brandon From owner-freebsd-current@FreeBSD.ORG Mon May 10 03:18:33 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5CFF0106566C; Mon, 10 May 2010 03:18:33 +0000 (UTC) (envelope-from bf1783@googlemail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 86E488FC13; Mon, 10 May 2010 03:18:30 +0000 (UTC) Received: by wyg36 with SMTP id 36so306615wyg.13 for ; Sun, 09 May 2010 20:18:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:reply-to :in-reply-to:references:date:message-id:subject:from:to:cc :content-type; bh=GgiV7DrSgq/czX70prm8Pqhun0BOajwaHQoa78AiHEk=; b=gpawLfJO83ObBPtquyiLa3qnrEM8tclSiMecqYFuLeFG1rrOrUDVziHv7vpOz38FYA jBkgXAhjCzfjixqjtBhYZg0U0K5/DMXfiwBADVnZlwx7BrDm4nC5BZspwg+f7N0wXPPP 9VHuXtVfvaV7BbWG7q7Pu20Awbq3aoNEhTrB4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=gSMjAwBAdC6o/nm6emMhnIc6o1xbtvqEsfd2ppkSttHl3YYSM5dj89uz5Qpgjehtnk c+1tWp21ISqZVBtzHwhdae9//HnMNvNjAMt0BhhJblBfKPjhhvGKFtLebBWe6GxR7uFU TXWCaCoH6oKumIrzWGhpNotiAw7VXNtX+iAtE= MIME-Version: 1.0 Received: by 10.216.86.71 with SMTP id v49mr2022546wee.14.1273461509319; Sun, 09 May 2010 20:18:29 -0700 (PDT) Received: by 10.216.163.21 with HTTP; Sun, 9 May 2010 20:18:29 -0700 (PDT) In-Reply-To: References: Date: Mon, 10 May 2010 03:18:29 +0000 Message-ID: From: "b. f." To: Brandon Gooch Content-Type: text/plain; charset=ISO-8859-1 Cc: alc@freebsd.org, Kip Macy , freebsd-current@freebsd.org, miwi@FreeBSD.org Subject: Re: Recent sys/vm/ changes and nvidia-driver X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bf1783@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 03:18:33 -0000 On 5/10/10, Brandon Gooch wrote: > > Is there a final "target state" regarding the work and/or a time-frame > for completion? Perhaps a "heads-up" e-mail to the freebsd-current > mailing list when the first round of commits have settled in? I'm > wondering, due to the Nvidia issue stated in this thread, as well as > panics I'm seeing using VirtualBox on my computer running HEAD. > Kip, could you please add an entry for the __FreeBSD_version 900011 to the Porter's Handbook table in doc/en_US.ISO8859-1/books/porters-handbook/book.sgml , as documented in src/sys/sys/param.h, if no one else beats you to it? In addition to alerting porters to the VM changes, it will remind them that we've also had a version bump after the import of OpenSSL 0.9.8n. Regards, b. From owner-freebsd-current@FreeBSD.ORG Mon May 10 06:11:02 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 14E951065670 for ; Mon, 10 May 2010 06:11:02 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from mail10.syd.optusnet.com.au (mail10.syd.optusnet.com.au [211.29.132.191]) by mx1.freebsd.org (Postfix) with ESMTP id 7D3A68FC0C for ; Mon, 10 May 2010 06:11:01 +0000 (UTC) Received: from server.vk2pj.dyndns.org (c122-106-253-149.belrs3.nsw.optusnet.com.au [122.106.253.149]) by mail10.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o4A6AwvX022926 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 10 May 2010 16:10:59 +1000 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.4/8.14.4) with ESMTP id o4A6AvUV093087 for ; Mon, 10 May 2010 16:10:58 +1000 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.4/8.14.4/Submit) id o4A6AvhD093086 for current@freebsd.org; Mon, 10 May 2010 16:10:57 +1000 (EST) (envelope-from peter) Date: Mon, 10 May 2010 16:10:57 +1000 From: Peter Jeremy To: current@freebsd.org Message-ID: <20100510061057.GA93038@server.vk2pj.dyndns.org> References: <20100508102005.GB1867@elmar.spoerlein.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="EeQfGwPcQSOJBaQU" Content-Disposition: inline In-Reply-To: <20100508102005.GB1867@elmar.spoerlein.net> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Subject: Re: LOR: ufs vs bufwait X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 06:11:02 -0000 --EeQfGwPcQSOJBaQU Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2010-May-08 12:20:05 +0200, Ulrich Sp=F6rlein wrote: >This LOR also is not yet listed on the LOR page, so I guess it's rather >new. I do use SUJ. > >lock order reversal: > 1st 0xc48388d8 ufs (ufs) @ /usr/src/sys/kern/vfs_lookup.c:502 > 2nd 0xec0fe304 bufwait (bufwait) @ /usr/src/sys/ufs/ffs/ffs_softdep.c:113= 63 > 3rd 0xc49e56b8 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2091 I'm seeing exactly the same LOR (and subsequent deadlock) on a recent -current without SUJ. --=20 Peter Jeremy --EeQfGwPcQSOJBaQU Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkvno3EACgkQ/opHv/APuIfFZQCfRZlbeOiEVCW9rAZVEBE5IY+x oWsAoJlUHsvOtINWsve2e4L7cYbUMrVn =a4ne -----END PGP SIGNATURE----- --EeQfGwPcQSOJBaQU-- From owner-freebsd-current@FreeBSD.ORG Mon May 10 08:42:10 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4E8961065670 for ; Mon, 10 May 2010 08:42:10 +0000 (UTC) (envelope-from admin@lissyara.su) Received: from hosting.lissyara.su (hosting.lissyara.su [77.221.149.162]) by mx1.freebsd.org (Postfix) with ESMTP id 041DB8FC12 for ; Mon, 10 May 2010 08:42:09 +0000 (UTC) Received: from [77.41.96.17] (port=37387 helo=dc7700p.lissyara.su) by hosting.lissyara.su with esmtpa (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OBOYw-000EvZ-My for freebsd-current@freebsd.org; Mon, 10 May 2010 12:42:06 +0400 Message-ID: <4BE7C6DC.4060000@lissyara.su> Date: Mon, 10 May 2010 12:42:04 +0400 From: Alex Keda User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; ru-RU; rv:1.9.1.9) Gecko/20100403 Thunderbird/3.0.4 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <86d3x6pd6x.fsf@gmail.com> In-Reply-To: <86d3x6pd6x.fsf@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-White-List: YES X-Spam-Description: if spam count > 60 - this is spam X-Spam-Count: 0 X-Descriptions: powered by www.lissyara.su X-Bounce-ID: hosting.lissyara.su Subject: Re: SC_PIXEL_MODE in GENERIC on i386/amd64? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 08:42:10 -0000 08.05.2010 20:31, Anonymous пишет: > - jfbterm > - boot splash > - apps that use libvgl (e.g. mplayer) > - other uses for graphic modes > > Is there a way to avoid recompiling kernel just to use them? may be need include SC_PIXEL_MODE into GENERIC for amd64 and i386? From owner-freebsd-current@FreeBSD.ORG Mon May 10 14:07:23 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8B55A1065674 for ; Mon, 10 May 2010 14:07:23 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from bunrab.catwhisker.org (adsl-63-193-123-122.dsl.snfc21.pacbell.net [63.193.123.122]) by mx1.freebsd.org (Postfix) with ESMTP id CA6868FC08 for ; Mon, 10 May 2010 14:07:22 +0000 (UTC) Received: from bunrab.catwhisker.org (localhost [127.0.0.1]) by bunrab.catwhisker.org (8.13.3/8.13.3) with ESMTP id o4AE7Mkp091910 for ; Mon, 10 May 2010 07:07:22 -0700 (PDT) (envelope-from david@bunrab.catwhisker.org) Received: (from david@localhost) by bunrab.catwhisker.org (8.13.3/8.13.3/Submit) id o4AE7MoN091909 for current@freebsd.org; Mon, 10 May 2010 07:07:22 -0700 (PDT) (envelope-from david) Date: Mon, 10 May 2010 07:07:22 -0700 From: David Wolfskill To: current@freebsd.org Message-ID: <20100510140722.GD49209@bunrab.catwhisker.org> Mail-Followup-To: David Wolfskill , current@freebsd.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1sPOHk9wyUr/csgM" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Cc: Subject: Panic @r207844; current process: flowcleaner "Fatal trap 12: page fault while in kernel mode" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 14:07:23 -0000 --1sPOHk9wyUr/csgM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable During transition to multi-user mode on first reboot after upgrading from r207812 -> r207844; from the sserial console: 3 Select option, [Enter] for default 3 3 or [Space] to pause timer 0 3 @DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2010 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 9.0-CURRENT #154 r207844: Mon May 10 06:03:54 PDT 2010 root@freebeast.catwhisker.org:/usr/obj/usr/src/sys/GENERIC i386 WARNING: WITNESS option enabled, expect reduced performance. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(TM) CPU 3.60GHz (3614.54-MHz 686-class CPU) Origin =3D "GenuineIntel" Id =3D 0xf41 Family =3D f Model =3D 4 Stepp= ing =3D 1 Features=3D0xbfebfbff Features2=3D0x659d AMD Features=3D0x20100000 TSC: P-state invariant real memory =3D 2147483648 (2048 MB) avail memory =3D 2086129664 (1989 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 2 package(s) x 1 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 6 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-47 on motherboard ioapic2 irqs 48-71 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 0x1008-0x100b on acpi0 cpu0: on acpi0 cpu1: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: at device 0.1 (no driver attached) pci0: at device 1.0 (no driver attached) pcib1: irq 16 at device 2.0 on pci0 pci1: on pcib1 pcib2: at device 0.0 on pci1 pci2: on pcib2 aac0: mem 0xdc000000-0xdfffffff irq 24 at device = 1.0 on pci2 aac0: Enable Raw I/O aac0: New comm. interface enabled aac0: [ITHREAD] aac0: Adaptec 2200S, aac driver 2.1.9-1 aacp0: on aac0 aacp1: on aac0 pcib3: at device 0.2 on pci1 pci3: on pcib3 em0: port 0x2000-0x203f= mem 0xd8200000-0xd821ffff irq 54 at device 2.0 on pci3 em0: [FILTER] em0: Ethernet address: 00:30:48:2d:32:6a em1: port 0x2040-0x207f= mem 0xd8220000-0xd823ffff irq 55 at device 2.1 on pci3 em1: [FILTER] em1: Ethernet address: 00:30:48:2d:32:6b pcib4: irq 16 at device 4.0 on pci0 pci4: on pcib4 pcib5: irq 16 at device 6.0 on pci0 pci5: on pcib5 uhci0: port 0x1400-0x141f irq 1= 6 at device 29.0 on pci0 uhci0: [ITHREAD] usbus0: on uhci0 uhci1: port 0x1420-0x143f irq 1= 9 at device 29.1 on pci0 uhci1: [ITHREAD] usbus1: on uhci1 uhci2: port 0x1440-0x145f irq 1= 8 at device 29.2 on pci0 uhci2: [ITHREAD] usbus2: on uhci2 uhci3: port 0x1460-0x147f irq 1= 6 at device 29.3 on pci0 uhci3: [ITHREAD] usbus3: on uhci3 ehci0: mem 0xd8001000-0xd80013f= f irq 23 at device 29.7 on pci0 ehci0: [ITHREAD] usbus4: EHCI version 1.0 usbus4: on ehci0 pcib6: at device 30.0 on pci0 pci6: on pcib6 vgapci0: port 0x3000-0x30ff mem 0xd9000000-0xd9fff= fff,0xd8300000-0xd8300fff irq 17 at device 1.0 on pci6 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177= ,0x376,0x14a0-0x14af at device 31.1 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] pci0: at device 31.3 (no driver attached) acpi_button0: on acpi0 atrtc0: port 0x70-0x77 irq 8 on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model Generic PS/2 mouse, device ID 0 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart0: [FILTER] uart0: console (9600,n,8,1) uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 uart1: [FILTER] fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FILTER] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 pmtimer0 on isa0 orm0: at iomem 0xc0000-0xc7fff,0xc8000-0xc8fff,0xc9000-0x= c9fff,0xca000-0xcafff,0xcb000-0xcf7ff pnpid ORM0000 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=3D0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ppc0: parallel port not found. est0: on cpu0 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 122d00000e24 device_attach: est0 attach returned 6 p4tcc0: on cpu0 est1: on cpu1 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 122d00000e24 device_attach: est1 attach returned 6 p4tcc1: on cpu1 Timecounters tick every 1.000 msec usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 12Mbps Full Speed USB v1.0 usbus4: 480Mbps High Speed USB v2.0 ata1: DMA limited to UDMA33, controller found non-ATA66 cable ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 ugen4.1: at usbus4 uhub4: on usbus4 acd0: DVDROM at ata1-slave UDMA33=20 aacd0: on aac0 aacd0: 34970MB (71619584 sectors) aacd1: on aac0 aacd1: 69974MB (143307008 sectors) uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered uhub3: 2 ports with 2 removable, self powered uhub4: 8 ports with 8 removable, self powered ses0 at aacp0 bus 0 scbus0 target 6 lun 0 ses0: Fixed Uninstalled SCSI-2 device=20 ses0: 3.300MB/s transfers ses0: SAF-TE Compliant Device pass0 at aacp0 bus 0 scbus0 target 0 lun 0 pass0: Fixed Uninstalled SCSI-3 device=20 pass0: 3.300MB/s transfers pass1 at aacp0 bus 0 scbus0 target 1 lun 0 pass1: Fixed Uninstalled SCSI-3 device=20 pass1: 3.300MB/s transfers pass2 at aacp0 bus 0 scbus0 target 2 lun 0 pass2: Fixed Uninstalled SCSI-3 device=20 pass2: 3.300MB/s transfers pass3 at aacp0 bus 0 scbus0 target 3 lun 0 pass3: Fixed Uninstalled SCSI-3 device=20 pass3: 3.300MB/s transfers SMP: AP CPU #1 Launched! WARNING: WITNESS option enabled, expect reduced performance. Trying to mount root from ufs:/dev/aacd0s4a Setting hostuuid: 80f1e964-dc63-0010-89d5-0030482d326a. Setting hostid: 0xc74551dd. Entropy harvesting: interrupts ethernet point_to_point kickstart. Starting file system checks: /dev/aacd0s4a: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/aacd0s4a: clean, 499351 free (1567 frags, 62223 blocks, 0.2% fragmenta= tion) /dev/aacd1s1e: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/aacd1s1e: clean, 4681742 free (261046 frags, 552587 blocks, 2.0% fragm= entation) /dev/aacd0s1a: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/aacd0s1a: clean, 424969 free (1913 frags, 52882 blocks, 0.3% fragmenta= tion) /dev/aacd0s1d: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/aacd0s1d: clean, 1031838 free (4190 frags, 128456 blocks, 0.2% fragmen= tation) /dev/aacd1s1d: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/aacd1s1d: clean, 11717829 free (197893 frags, 1439992 blocks, 1.2% fra= gmentation) /dev/aacd0s2a: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/aacd0s2a: clean, 596256 free (1488 frags, 74346 blocks, 0.2% fragmenta= tion) /dev/aacd0s2d: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/aacd0s2d: clean, 1108521 free (23105 frags, 135677 blocks, 1.3% fragme= ntation) /dev/aacd0s3a: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/aacd0s3a: clean, 578034 free (1146 frags, 72111 blocks, 0.2% fragmenta= tion) /dev/aacd0s3d: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/aacd0s3d: clean, 1070844 free (39380 frags, 128933 blocks, 2.2% fragme= ntation) /dev/aacd0s4d: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/aacd0s4d: clean, 1075985 free (60161 frags, 126978 blocks, 3.4% fragme= ntation) /dev/aacd0s4f: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/aacd0s4f: clean, 2106329 free (345 frags, 263248 blocks, 0.0% fragment= ation) Mounting local file systems:. Setting hostname: freebeast.catwhisker.org. lock order reversal: 1st 0xc645b9e8 ufs (ufs) @ /usr/src/sys/kern/vfs_lookup.c:502 2nd 0xd94fe700 bufwait (bufwait) @ /usr/src/sys/ufs/ffs/ffs_softdep.c:11363 3rd 0xc6495388 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2091 KDB: stack backtrace: db_trace_self_wrapper(c0cc7245,ebe28300,c08e9f65,c08da2db,c0cca238,...) at = db_trace_self_wrapper+0x26 kdb_backtrace(c08da2db,c0cca238,c553d030,c5540568,ebe2835c,...) at kdb_back= trace+0x29 _witness_debugger(c0cca238,c6495388,c0cbc55d,c5540568,c0cd1351,...) at _wit= ness_debugger+0x25 witness_checkorder(c6495388,9,c0cd1351,82b,0,...) at witness_checkorder+0x8= 39 __lockmgr_args(c6495388,80100,c64953a8,0,0,...) at __lockmgr_args+0x7f9 ffs_lock(ebe28480,c08e9d0b,c0cd07f6,80100,c6495330,...) at ffs_lock+0x8a VOP_LOCK1_APV(c0dd4e80,ebe28480,c5a1bcd4,c0def8c0,c6495330,...) at VOP_LOCK= 1_APV+0xb5 _vn_lock(c6495330,80100,c0cd1351,82b,4,...) at _vn_lock+0x5e vget(c6495330,80100,c5a1bc30,50,0,...) at vget+0xb9 vfs_hash_get(c6461ca8,78c1d,80000,c5a1bc30,ebe285d0,...) at vfs_hash_get+0x= e6 ffs_vgetf(c6461ca8,78c1d,80000,ebe285d0,1,...) at ffs_vgetf+0x49 softdep_sync_metadata(c645b990,0,c0ced598,144,0,...) at softdep_sync_metada= ta+0xc92 ffs_syncvnode(c645b990,1,c5a1bc30,ebe28690,246,...) at ffs_syncvnode+0x3e2 ffs_truncate(c645b990,200,0,880,c5588480,...) at ffs_truncate+0x862 ufs_direnter(c645b990,c6495330,ebe28944,ebe28bd4,0,...) at ufs_direnter+0x8= d4 ufs_makeinode(ebe28bd4,0,ebe28b30,ebe28a8c,c0c03285,...) at ufs_makeinode+0= x557 ufs_create(ebe28b30,ebe28b48,0,0,ebe28ba8,...) at ufs_create+0x30 VOP_CREATE_APV(c0dd4e80,ebe28b30,ebe28bd4,ebe28ac8,0,...) at VOP_CREATE_APV= +0xa5 vn_open_cred(ebe28ba8,ebe28c5c,1a4,0,c5588480,...) at vn_open_cred+0x215 vn_open(ebe28ba8,ebe28c5c,1a4,c5f9e1c0,0,...) at vn_open+0x3b kern_openat(c5a1bc30,ffffff9c,804c5e8,0,602,...) at kern_openat+0x125 kern_open(c5a1bc30,804c5e8,0,601,21b6,...) at kern_open+0x35 open(c5a1bc30,ebe28cf8,c0cffd9b,c0caa674,c647f2a8,...) at open+0x30 syscall(ebe28d38) at syscall+0x220 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (5, FreeBSD ELF32, open), eip =3D 0x281744b3, esp =3D 0xbfbfec4= c, ebp =3D 0xbfbfecb8 --- Starting Network: lo0 em0 em1. lo0: flags=3D8049 metric 0 mtu 16384 options=3D3 inet 127.0.0.1 netmask 0xff000000=20 inet6 ::1 prefixlen 128=20 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3=20 nd6 options=3D21 em0: flags=3D8843 metric 0 mtu 1500 options=3D389b ether 00:30:48:2d:32:6a inet 172.16.8.10 netmask 0xffffff00 broadcast 172.16.8.255 inet6 fe80::230:48ff:fe2d:326a%em0 prefixlen 64 tentative scopeid 0= x1=20 nd6 options=3D29 media: Ethernet autoselect status: no carrier em1: flags=3D8802 metric 0 mtu 1500 options=3D389b ether 00:30:48:2d:32:6b media: Ethernet autoselect status: no carrier Starting devd. Starting Network: em1. em1: flags=3D8802 metric 0 mtu 1500 options=3D389b ether 00:30:48:2d:32:6b media: Ethernet autoselect status: no carrier add net default: gateway 172.16.8.1 add net ::ffff:0.0.0.0: gateway ::1 add net ::0.0.0.0: gateway ::1 add net fe80::: gateway ::1 add net ff02::: gateway ::1 ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib /usr/local/= lib/compat a.out ldconfig path: /usr/lib/aout /usr/lib/compat/aout Creating and/or trimming log files. Starting syslogd. No core dumps found. Starting rpcbind. NFS access cache time=3D60 Setting NIS domain: lmdhw.com. Starting ypbind. Starting amd. Clearing /tmp (X related). Starting mountd. Starting nfsd. Starting lpd. Updating motd:. Starting ntpd. Starting powerd. Starting rsyncd. Starting cvsupd. Configuring syscons: blanktime. Starting sshd. Starting cron. Starting background file system checks in 60 seconds. Mon May 10 06:48:07 PDT 2010 FreeBSD/i386 (freebeast.catwhisker.org) (ttyu0) login:=20 Fatal trap 12: page fault while in kernel mode cpuid =3D 1; apic id =3D 06 fault virtual address =3D 0x68 fault code =3D supervisor read, page not present instruction pointer =3D 0x20:0xc0894196 stack pointer =3D 0x28:0xe9bc6c5c frame pointer =3D 0x28:0xe9bc6c7c code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, def32 1, gran 1 processor eflags =3D interrupt enabled, resume, IOPL =3D 0 current process =3D 20 (flowcleaner) [ thread pid 20 tid 100067 ] Stopped at _mtx_lock_flags+0x46: movl 0x10(%ebx),%eax db> show lockchain thread 100067 (pid 20, flowcleaner) running on CPU 1 db> db> ps pid ppid pgrp uid state wmesg wchan cmd 1300 1 1300 0 Ss+ ttyin 0xc560f870 getty 1299 1 1299 0 Ss+ ttyin 0xc58e9070 getty 1298 1 1298 0 Ss+ ttyin 0xc58e9270 getty 1297 1 1297 0 Ss+ ttyin 0xc560fe70 getty 1296 1 1296 0 Ss+ ttyin 0xc5856a70 getty 1295 1 1295 0 Ss+ ttyin 0xc5856270 getty 1294 1 1294 0 Ss+ ttyin 0xc5856870 getty 1293 1 1293 0 Ss+ ttyin 0xc5856070 getty 1292 1 1292 0 Ss+ ttyin 0xc560f670 getty 1289 1287 21 0 S+ nanslp 0xc0e24ec4 sleep 1288 1 21 0 S+ piperd 0xc5fe9188 logger 1287 1 21 0 S+ wait 0xc647eaa0 sh 1228 1 1228 0 Ss nanslp 0xc0e24ec4 cron 1221 1 1221 25 Ss pause 0xc5feada0 sendmail 1217 1 1217 0 Ss select 0xc6549ce4 sendmail 1209 1 1209 0 Ss select 0xc5f3eb64 sshd 1180 1 1180 1004 Ss select 0xc5f2c164 cvsupd 1167 1 1167 0 Ss select 0xc5f2cc64 rsync 1120 1 1120 0 Ss select 0xc654aa64 powerd 1112 1 1112 0 Ss select 0xc6549824 ntpd 1078 1 1078 0 Ss select 0xc5f2c0a4 lpd 1015 1014 1014 0 S (threaded) nfsd 100120 S rpcsvc 0xc6549550 nfsd: service 100119 S rpcsvc 0xc5f2cd10 nfsd: service 100118 S rpcsvc 0xc5f001d0 nfsd: service 100073 S rpcsvc 0xc5f2ba10 nfsd: master 1014 1 1014 0 Ss select 0xc58f2764 nfsd 1012 1 1012 0 Ss select 0xc654a3e4 mountd 922 1 922 0 Ss select 0xc6549064 amd 908 1 908 0 Ss select 0xc58f2724 ypbind 881 1 881 0 Ss select 0xc58f1164 rpcbind 857 1 857 0 Ss select 0xc5f3d464 syslogd 660 1 660 0 Ss select 0xc654a0a4 devd 20 0 0 0 RL CPU 1 [flowcleaner] 19 0 0 0 DL sdflush 0xc0f9ce60 [softdepflush] 18 0 0 0 DL vlruwt 0xc5f367f8 [vnlru] 17 0 0 0 DL syncer 0xc0f91554 [syncer] 16 0 0 0 DL psleep 0xc0f91288 [bufdaemon] 15 0 0 0 DL pgzero 0xc0f9ec94 [pagezero] 9 0 0 0 DL psleep 0xc0f9e8d8 [vmdaemon] 8 0 0 0 DL psleep 0xc0f9e8a0 [pagedaemon] 7 0 0 0 DL ccb_scan 0xc0df0c54 [xpt_thrd] 6 0 0 0 DL - 0xc560fc3c [fdc0] 14 0 0 0 DL (threaded) [usb] 100051 D - 0xc58b1d0c [usbus4] 100050 D - 0xc58b1cdc [usbus4] 100049 D - 0xc58b1cac [usbus4] 100048 D - 0xc58b1c7c [usbus4] 100046 D - 0xc589adac [usbus3] 100045 D - 0xc589ad7c [usbus3] 100044 D - 0xc589ad4c [usbus3] 100043 D - 0xc589ad1c [usbus3] 100042 D - 0xc5889dac [usbus2] 100041 D - 0xc5889d7c [usbus2] 100040 D - 0xc5889d4c [usbus2] 100039 D - 0xc5889d1c [usbus2] 100037 D - 0xc5874dac [usbus1] 100036 D - 0xc5874d7c [usbus1] 100035 D - 0xc5874d4c [usbus1] 100034 D - 0xc5874d1c [usbus1] 100032 D - 0xc5861dac [usbus0] 100031 D - 0xc5861d7c [usbus0] 100030 D - 0xc5861d4c [usbus0] 100029 D - 0xc5861d1c [usbus0] 5 0 0 0 DL aifthd 0xc56c92a8 [aac0aif] 13 0 0 0 DL - 0xc0e24d24 [yarrow] 4 0 0 0 DL - 0xc0e22a44 [g_down] 3 0 0 0 DL - 0xc0e22a40 [g_up] 2 0 0 0 DL - 0xc0e22a38 [g_event] 12 0 0 0 WL (threaded) [intr] 100056 I [swi0: uart uart] 100055 I [irq12: psm0] 100054 I [irq1: atkbd0] 100053 I [irq15: ata1] 100052 I [irq14: ata0] 100047 I [irq23: ehci0] 100038 I [irq18: uhci2] 100033 I [irq19: uhci1] 100028 I [irq16: uhci0 uhci3] 100024 I [irq24: aac0] 100023 I [irq9: acpi0] 100018 I [swi2: cambio] 100017 I [swi6: task queue] 100016 I [swi6: Giant taskq] 100014 I [swi5: +] 100008 I [swi4: clock] 100007 I [swi4: clock] 100006 I [swi1: netisr 0] 100005 I [swi3: vm] 11 0 0 0 RL (threaded) [idle] 100004 Run CPU 0 [idle: cpu0] 100003 CanRun [idle: cpu1] 1 0 1 0 SLs wait 0xc557fd48 [init] 10 0 0 0 DL audit_wo 0xc0f9c680 [audit] 0 0 0 0 DLs (threaded) [kernel] 100058 D deadlkre 0xc0e24d24 [deadlkres] 100027 D - 0xc57f81c0 [em1 taskq] 100026 D - 0xc57f8980 [em0 taskq] 100022 D - 0xc56c6dc0 [kqueue taskq] 100021 D - 0xc56c6e00 [acpi_task_2] 100020 D - 0xc56c6e00 [acpi_task_1] 100019 D - 0xc56c6e00 [acpi_task_0] 100015 D - 0xc56c7300 [thread taskq] 100009 D - 0xc5566c00 [firmware taskq] 100000 D sched 0xc0e22b20 [swapper] db>=20 As shown above, this is a dual CPU, single-core amchine running a FreeBSD/i386 GENERIC kernel. My laptop is still building the world for the same transition; more info there when I have it, if it seems relevant. I'll leave it in this state while I head in to work; I should be back in email range in about 70 minutes. Peace, david --=20 David H. Wolfskill david@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --1sPOHk9wyUr/csgM Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iEYEARECAAYFAkvoExkACgkQmprOCmdXAD0mvQCfVVANpapahpgszOOCO+8d2bfq mT8An0IFlLlHOuG0hndpP+PvUfiRaqOn =m4oC -----END PGP SIGNATURE----- --1sPOHk9wyUr/csgM-- From owner-freebsd-current@FreeBSD.ORG Mon May 10 18:10:07 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DFA3C106568A for ; Mon, 10 May 2010 18:10:07 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (muon.cran.org.uk [109.74.192.160]) by mx1.freebsd.org (Postfix) with ESMTP id 9F3098FC13 for ; Mon, 10 May 2010 18:10:07 +0000 (UTC) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id 9987AC400C; Mon, 10 May 2010 18:10:06 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on muon.cran.org.uk X-Spam-Level: X-Spam-Status: No, score=-2.5 required=8.0 tests=AWL,BAYES_00,RDNS_DYNAMIC autolearn=no version=3.2.5 Received: from core.draftnet (87-194-158-129.bethere.co.uk [87.194.158.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA; Mon, 10 May 2010 18:10:06 +0000 (UTC) From: Bruce Cran To: freebsd-current@freebsd.org, gljennjohn@googlemail.com Date: Mon, 10 May 2010 19:09:15 +0100 User-Agent: KMail/1.13.3 (FreeBSD/9.0-CURRENT; KDE/4.4.3; amd64; ; ) References: <4BD8F7FA.2080103@jrv.org> <4BDA07B4.40506@digiware.nl> <20100430101149.35d50368@ernst.jennejohn.org> In-Reply-To: <20100430101149.35d50368@ernst.jennejohn.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201005101909.16234.bruce@cran.org.uk> Cc: Willem Jan Withagen , Artem Belevich , "James R. Van Artsdalen" Subject: Re: kmem_map too small: 3832475648 total allocated X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 18:10:08 -0000 On Friday 30 April 2010 09:11:49 Gary Jennejohn wrote: > A number of variables go into calculating vm.kmem_size (see kmeminit() > in kern_malloc.c). > > In the end, the kernel won't allocate more than twice the physical memory > size _which it has discovered_. > > The question is, how much of your physical memory does the kernel actually > see? It would appear that the maximum value for vm.kmem_size is twice the amount of "avail memory" - as opposed to the "real memory". I have 6GB installed; 6144MB gets detected but only 5873MB is available. Setting vm.kmem_size to 12G fails but 10G works. -- Bruce Cran From owner-freebsd-current@FreeBSD.ORG Mon May 10 18:26:32 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8B69D1065679 for ; Mon, 10 May 2010 18:26:32 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from bunrab.catwhisker.org (adsl-63-193-123-122.dsl.snfc21.pacbell.net [63.193.123.122]) by mx1.freebsd.org (Postfix) with ESMTP id 5C38F8FC18 for ; Mon, 10 May 2010 18:26:32 +0000 (UTC) Received: from bunrab.catwhisker.org (localhost [127.0.0.1]) by bunrab.catwhisker.org (8.13.3/8.13.3) with ESMTP id o4AIQPrI093613; Mon, 10 May 2010 11:26:25 -0700 (PDT) (envelope-from david@bunrab.catwhisker.org) Received: (from david@localhost) by bunrab.catwhisker.org (8.13.3/8.13.3/Submit) id o4AIQPxm093612; Mon, 10 May 2010 11:26:25 -0700 (PDT) (envelope-from david) Date: Mon, 10 May 2010 11:26:25 -0700 From: David Wolfskill To: Ed Schouten Message-ID: <20100510182625.GF49209@bunrab.catwhisker.org> Mail-Followup-To: David Wolfskill , Ed Schouten , current@freebsd.org References: <20100510140722.GD49209@bunrab.catwhisker.org> <20100510182243.GV56080@hoeg.nl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2rNXa4ZKUTN10Xl5" Content-Disposition: inline In-Reply-To: <20100510182243.GV56080@hoeg.nl> User-Agent: Mutt/1.4.2.1i Cc: current@freebsd.org Subject: Re: Panic @r207844; current process: flowcleaner "Fatal trap 12: page fault while in kernel mode" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 18:26:32 -0000 --2rNXa4ZKUTN10Xl5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, May 10, 2010 at 08:22:43PM +0200, Ed Schouten wrote: > ... > You don't happen to have a backtrace? Oops -- sorry; got caught up in getting ready to head in to work: db> bt Tracing pid 20 tid 100067 td 0xc5a19000 _mtx_lock_flags(58,0,c0cd2d5b,570,80,...) at _mtx_lock_flags+0x46 flowtable_free_stale(c0e28f40,0,c0cd2d5b,600,0,...) at flowtable_free_stale= +0x2fb flowtable_cleaner(0,e9bc6d38,c0cbf058,343,c5f362a8,...) at flowtable_cleane= r+0xd0 fork_exit(c094f920,0,e9bc6d38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip =3D 0, esp =3D 0xe9bc6d70, ebp =3D 0 --- db>=20 Anything else that might be useful or interesting, please let me know; as noted earlier, I left the machine in that state. (I normally power it off after the morning's build/test festivities, as it's loud & uses a fair amount of power.) Peace, david --=20 David H. Wolfskill david@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --2rNXa4ZKUTN10Xl5 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iEYEARECAAYFAkvoT9AACgkQmprOCmdXAD33/gCcCpP8H3jFpf0i8nqfIhwLtg4J Xv8An1L9o3OSf3WavdCeCrNyDEGNAmRI =GgwE -----END PGP SIGNATURE----- --2rNXa4ZKUTN10Xl5-- From owner-freebsd-current@FreeBSD.ORG Mon May 10 18:33:11 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EFB841065756 for ; Mon, 10 May 2010 18:33:11 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by mx1.freebsd.org (Postfix) with ESMTP id 909268FC16 for ; Mon, 10 May 2010 18:33:11 +0000 (UTC) Received: from bcs-mail03.internal.cacheflow.com ([10.2.2.95]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id o4AIWeaD005143; Mon, 10 May 2010 11:32:41 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 10 May 2010 11:32:21 -0700 Message-ID: In-Reply-To: <20100510182625.GF49209@bunrab.catwhisker.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Panic @r207844; current process: flowcleaner "Fatal trap 12: page fault while inkernel mode" Thread-Index: Acrwbl/mbBqJgLzgSUOC/z0TF3vhhAAAKu4g References: <20100510140722.GD49209@bunrab.catwhisker.org><20100510182243.GV56080@hoeg.nl> <20100510182625.GF49209@bunrab.catwhisker.org> From: "Li, Qing" To: "David Wolfskill" , "Ed Schouten" Cc: current@freebsd.org Subject: RE: Panic @r207844; current process: flowcleaner "Fatal trap 12: page fault while inkernel mode" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 18:33:12 -0000 Hi David, I will take a look later this afternoon PST. Thanks, -- Qing > -----Original Message----- > From: owner-freebsd-current@freebsd.org [mailto:owner-freebsd- > current@freebsd.org] On Behalf Of David Wolfskill > Sent: Monday, May 10, 2010 11:26 AM > To: Ed Schouten > Cc: current@freebsd.org > Subject: Re: Panic @r207844;current process: flowcleaner "Fatal trap 12: > page fault while inkernel mode" >=20 > On Mon, May 10, 2010 at 08:22:43PM +0200, Ed Schouten wrote: > > ... > > You don't happen to have a backtrace? >=20 > Oops -- sorry; got caught up in getting ready to head in to work: >=20 > db> bt > Tracing pid 20 tid 100067 td 0xc5a19000 > _mtx_lock_flags(58,0,c0cd2d5b,570,80,...) at _mtx_lock_flags+0x46 > flowtable_free_stale(c0e28f40,0,c0cd2d5b,600,0,...) at > flowtable_free_stale+0x2fb > flowtable_cleaner(0,e9bc6d38,c0cbf058,343,c5f362a8,...) at > flowtable_cleaner+0xd0 > fork_exit(c094f920,0,e9bc6d38) at fork_exit+0xb8 > fork_trampoline() at fork_trampoline+0x8 > --- trap 0, eip =3D 0, esp =3D 0xe9bc6d70, ebp =3D 0 --- > db> >=20 > Anything else that might be useful or interesting, please let me > know; as noted earlier, I left the machine in that state. (I > normally power it off after the morning's build/test festivities, > as it's loud & uses a fair amount of power.) >=20 > Peace, > david > -- > David H. Wolfskill david@catwhisker.org > Depriving a girl or boy of an opportunity for education is evil. >=20 > See http://www.catwhisker.org/~david/publickey.gpg for my public key. From owner-freebsd-current@FreeBSD.ORG Mon May 10 19:56:33 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0B22D1065677 for ; Mon, 10 May 2010 19:56:33 +0000 (UTC) (envelope-from weongyo.jeong@gmail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.25]) by mx1.freebsd.org (Postfix) with ESMTP id 7EC948FC14 for ; Mon, 10 May 2010 19:56:32 +0000 (UTC) Received: by ey-out-2122.google.com with SMTP id d26so208861eyd.9 for ; Mon, 10 May 2010 12:56:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:mail-followup-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent:organization:x-operation-sytem; bh=khvWE0gdb/dzS5ntgB14APS9Uk4Hp7g1Kci6Aqft4U8=; b=ezn6Sj7GUobYTtq0kkn4nQSJg+4zBgQqwNL6bMdYlhYlgjhchvfqHMpIN50Nl+aXIf rcXiRf8JhBn67IF8aejN5VHeRyMNWfq4xHe0IKi92zeOKTgtrbxykU7DfIAJDWieDUb8 kwEeBv3pSIg8IV/CYjpBUsA7uJ0dBqLjnJlMI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:mail-followup-to :references:mime-version:content-type:content-disposition :in-reply-to:user-agent:organization:x-operation-sytem; b=psMocNG5Aym0ijlCqDSk8uqqbsvJk6URi18+4F/GEu9p0dIn2ccIIhpMwNgX021hDI hfVNzOqtK/V7Axc5bEMXFGhxgY+0utYmXiZxi0HkqdCFEnBkGUDRD9ITK+LUGKQogwTw Bh7NFmp0ci66WINvqSrpGCiA0YOETyjmBD7vM= Received: by 10.213.51.138 with SMTP id d10mr1491565ebg.75.1273521391086; Mon, 10 May 2010 12:56:31 -0700 (PDT) Received: from weongyo ([174.35.1.224]) by mx.google.com with ESMTPS id 13sm2681713ewy.13.2010.05.10.12.56.26 (version=SSLv3 cipher=RC4-MD5); Mon, 10 May 2010 12:56:27 -0700 (PDT) Received: by weongyo (sSMTP sendmail emulation); Mon, 10 May 2010 12:56:22 -0700 From: Weongyo Jeong Date: Mon, 10 May 2010 12:56:22 -0700 To: Gustavo Perez Querol Message-ID: <20100510195622.GA1295@weongyo> Mail-Followup-To: Gustavo Perez Querol , current@freebsd.org, Ian FREISLICH References: <20100228095259.GB3536@weongyo> <20100301103240.3a4aac8a.ray@dlink.ua> <20100303082833.GB22865@weongyo> <20100303111014.6564ea1e.ray@dlink.ua> <20100312231333.GZ1295@weongyo> <4BD2201E.3090409@entel.upc.edu> <20100424231755.GI65380@weongyo> <4BD4A928.8020901@entel.upc.edu> <20100506190653.GA31100@weongyo> <58220.88.15.97.205.1273248485.squirrel@webmail.entel.upc.edu> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="rJwd6BRFiFCcLxzm" Content-Disposition: inline In-Reply-To: <58220.88.15.97.205.1273248485.squirrel@webmail.entel.upc.edu> User-Agent: Mutt/1.4.2.3i Organization: CDNetworks. X-Operation-Sytem: FreeBSD Cc: Ian FREISLICH , current@freebsd.org Subject: Re: Call for Test and Review: bwn(4) - another Broadcom Wireless driver X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Weongyo Jeong List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 19:56:33 -0000 --rJwd6BRFiFCcLxzm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, May 07, 2010 at 06:08:05PM +0200, Gustavo Perez Querol wrote: > > > > > Hello Gustau, I'm so sorry for belated response that I had no time to > > read and work email and wireless stuffs. > > > > Could you please test this symptom with attached patch? It looks in > > CURRENT it missed to initialize a ratectl when it associates with AP. > > > > The patch made the machine to panic. I think it happened when launching > the supplicant. In fact, right now it works by putting the RF switch to > OFF. As soon as I change it to ON the machine panics. > > It get a trap 12, with two reasons : page fault and "bufwrite, buffer is > not busy?" > > I'm running 9.0/AMD64 from 1 of May (don't know exact svn revision). > > Do you want me to test anything else ? OK. The patch is ready to test. Could you please test it with attached patch? regards, Weongyo Jeong --rJwd6BRFiFCcLxzm Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="patch_bwn_20100510.diff" Index: if_bwn.c =================================================================== --- if_bwn.c (revision 207881) +++ if_bwn.c (working copy) @@ -8329,6 +8329,7 @@ static int bwn_newstate(struct ieee80211vap *vap, enum ieee80211_state nstate, int arg) { + const struct ieee80211_txparam *tp; struct bwn_vap *bvp = BWN_VAP(vap); struct ieee80211com *ic= vap->iv_ic; struct ifnet *ifp = ic->ic_ifp; @@ -8377,6 +8378,11 @@ bwn_set_pretbtt(mac); bwn_spu_setdelay(mac, 0); bwn_set_macaddr(mac); + + /* Initializes ratectl for a node. */ + tp = &vap->iv_txparms[ieee80211_chan2mode(ic->ic_curchan)]; + if (tp->ucastrate == IEEE80211_FIXED_RATE_NONE) + ieee80211_ratectl_node_init(vap->iv_bss); } BWN_UNLOCK(sc); @@ -8994,7 +9000,7 @@ struct bwn_stats *stats = &mac->mac_stats; struct ieee80211_node *ni; struct ieee80211vap *vap; - int slot; + int retrycnt = 0, slot; BWN_ASSERT_LOCKED(mac->mac_sc); @@ -9027,7 +9033,7 @@ status->ack ? IEEE80211_RATECTL_TX_SUCCESS : IEEE80211_RATECTL_TX_FAILURE, - NULL, 0); + &retrycnt, 0); break; } slot = bwn_dma_nextslot(dr, slot); @@ -9048,7 +9054,7 @@ status->ack ? IEEE80211_RATECTL_TX_SUCCESS : IEEE80211_RATECTL_TX_FAILURE, - NULL, 0); + &retrycnt, 0); } bwn_pio_handle_txeof(mac, status); } --rJwd6BRFiFCcLxzm-- From owner-freebsd-current@FreeBSD.ORG Mon May 10 20:53:33 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CB4C01065670 for ; Mon, 10 May 2010 20:53:33 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 57D858FC0C for ; Mon, 10 May 2010 20:53:33 +0000 (UTC) Received: by fxm15 with SMTP id 15so3322160fxm.13 for ; Mon, 10 May 2010 13:53:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=5IhIGxnMwQBX2GvDHJPd35J9m3OFXZbQM3jv3Z+4cUE=; b=vqrgpDxgB/RsLnQZH0XrXHbBUvj6SF3znBvGTRrZ/EFqh67/pFajByZ9A9NXt9OH8n GBsSarAboGK40DDstQ2uvHiQ/nroLzbd9KeT8HJ0BFqoPZZMNO7p4m41NUxmxEBZH+2C auaSTVvIbRsDFuchHF5fSUzGd+XgrtYs3qp6A= 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 :content-transfer-encoding; b=dU6cHWyiYj6+PpcQJGFPAASRRKZrb5txpAsZ4O79e0+7QJn96/z2JRMGZGWs1dLciJ w0TevIFhYbOZvrvtXUpAvAcQjDMAwAvFA0rns/SnOSz9SdB3auQIUQLV73kGlKeNmThZ +mgTzZqdr0Pylwz+2t+zf3SRIKPo75vfn2z7Q= MIME-Version: 1.0 Received: by 10.239.190.83 with SMTP id w19mr397086hbh.144.1273524812199; Mon, 10 May 2010 13:53:32 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.239.129.207 with HTTP; Mon, 10 May 2010 13:53:32 -0700 (PDT) In-Reply-To: <20100510061057.GA93038@server.vk2pj.dyndns.org> References: <20100508102005.GB1867@elmar.spoerlein.net> <20100510061057.GA93038@server.vk2pj.dyndns.org> Date: Mon, 10 May 2010 22:53:32 +0200 X-Google-Sender-Auth: ba0e602dacd1c496 Message-ID: From: Attilio Rao To: Peter Jeremy Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: current@freebsd.org Subject: Re: LOR: ufs vs bufwait X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 20:53:33 -0000 2010/5/10 Peter Jeremy : > On 2010-May-08 12:20:05 +0200, Ulrich Sp=C3=B6rlein w= rote: >>This LOR also is not yet listed on the LOR page, so I guess it's rather >>new. I do use SUJ. >> >>lock order reversal: >> 1st 0xc48388d8 ufs (ufs) @ /usr/src/sys/kern/vfs_lookup.c:502 >> 2nd 0xec0fe304 bufwait (bufwait) @ /usr/src/sys/ufs/ffs/ffs_softdep.c:11= 363 >> 3rd 0xc49e56b8 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2091 > > I'm seeing exactly the same LOR (and subsequent deadlock) on a recent > -current without SUJ. I think this LOR was reported since a long time. The deadlock may be new and someway related to the vm_page_lock work (if not SUJ). Attilio --=20 Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Mon May 10 20:22:28 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1EB53106564A for ; Mon, 10 May 2010 20:22:28 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from mail.digiware.nl (mail.digiware.nl [80.255.245.173]) by mx1.freebsd.org (Postfix) with ESMTP id CDA468FC1B for ; Mon, 10 May 2010 20:22:27 +0000 (UTC) Received: from localhost (localhost.digiware.nl [127.0.0.1]) by mail.digiware.nl (Postfix) with ESMTP id 8EEE1153470; Mon, 10 May 2010 22:22:26 +0200 (CEST) X-Virus-Scanned: amavisd-new at digiware.nl Received: from mail.digiware.nl ([127.0.0.1]) by localhost (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ej56pCiNnBfu; Mon, 10 May 2010 22:22:22 +0200 (CEST) Received: from [127.0.0.1] (vaio [192.168.10.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.digiware.nl (Postfix) with ESMTPSA id 0D03E15348D; Mon, 10 May 2010 21:49:15 +0200 (CEST) Message-ID: <4BE8633C.5030206@digiware.nl> Date: Mon, 10 May 2010 21:49:16 +0200 From: Willem Jan Withagen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Bruce Cran References: <4BD8F7FA.2080103@jrv.org> <4BDA07B4.40506@digiware.nl> <20100430101149.35d50368@ernst.jennejohn.org> <201005101909.16234.bruce@cran.org.uk> In-Reply-To: <201005101909.16234.bruce@cran.org.uk> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 100510-0, 10-05-2010), Outbound message X-Antivirus-Status: Clean X-Mailman-Approved-At: Mon, 10 May 2010 21:09:09 +0000 Cc: "James R. Van Artsdalen" , freebsd-current@freebsd.org, Artem Belevich Subject: Re: kmem_map too small: 3832475648 total allocated X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 20:22:28 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10-5-2010 20:09, Bruce Cran wrote: > On Friday 30 April 2010 09:11:49 Gary Jennejohn wrote: > >> A number of variables go into calculating vm.kmem_size (see kmeminit() >> in kern_malloc.c). >> >> In the end, the kernel won't allocate more than twice the physical memory >> size _which it has discovered_. >> >> The question is, how much of your physical memory does the kernel actually >> see? > > It would appear that the maximum value for vm.kmem_size is twice the amount of > "avail memory" - as opposed to the "real memory". I have 6GB installed; 6144MB > gets detected but only 5873MB is available. Setting vm.kmem_size to 12G fails > but 10G works. real memory = 8589934592 (8192 MB) avail memory = 8257212416 (7874 MB) So I'm setting it to 14G and reboot. (Which is a pain on my Areca card, since it keeps losing disks bu thatt is for another topic) Ans now it gives me: vm.kmem_size: 15032385536 So perhaps somebody should anotate /boot/defaults/loader.conf and/or list this op more positions...... - --WjW -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) iQEcBAEBAgAGBQJL6GM8AAoJEP4k4K6R6rBhUEkH/30RkWpqcNnxK3rc0TTl1TWw vNDxNRx+daq3lTjq7H21aM4mblmqhyTDTE+8+JtZA8Imy2hDpgK5dna4YVz5fLX+ Z5bFod2nVFlY1JfsCVpJTP0w2mdlH+DqYFh1C0bqeVLczc9W8BwPPrs8ucatmy2y Fhtgh3T4wKDkb43jneWVxOBpzjXUR3AekvFyL1Dh52WS65KjfgyRPsBnISYs6+iO /ysB2DGXjBwEuPxlEKXWItW/ghA3bnLRGsCqzu16rULIDRaDr2G85sRkMcR0CmSn NNodAW1qOQetmV7RUkwejZqPsxl/pumIK4CbCVjz9hDoXSrApPJE8O4spZyvZiA= =c4Bz -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Mon May 10 21:32:17 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B79FA106566B for ; Mon, 10 May 2010 21:32:17 +0000 (UTC) (envelope-from kmatthew.macy@gmail.com) Received: from mail-qy0-f181.google.com (mail-qy0-f181.google.com [209.85.221.181]) by mx1.freebsd.org (Postfix) with ESMTP id 660548FC16 for ; Mon, 10 May 2010 21:32:17 +0000 (UTC) Received: by qyk11 with SMTP id 11so6216452qyk.13 for ; Mon, 10 May 2010 14:32:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:reply-to:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:content-type:content-transfer-encoding; bh=X9Znep50ZGu1NPH4A0++58G8fk/jXqVVdkWMwFHlZI0=; b=N+RnZKlEVUxjoWhAnnepEXc6ZvmRDUqJyYF4sQ1KsL7xYi1LJZ5TK9oYrYrTqU/zsg tIukJHr0SDRgFxRPbxDHNgftDy4++SgBs7vcJZPeCdVie64cGJrW2SzwXu4S3WjiYKCM zMBtGPbUaDromzinK3FmyU6C9K1skC8O8M7Bg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:reply-to:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; b=aj5782fmhttZPZ8q1bCnhvkqmCDJOQnJU/fy38OEJSgAXSQ/HnleoOgI8huabVbwwx 0HD/9IVw8mGdKX30UE1gz6sqMY62MQ/b3Ysh/kzQ3yf+PB/gEZf3KFvZbgH6prtU1n4P ERBZvSypMDa2w+ERZ2ECFo/efAWV1xHtngKwk= MIME-Version: 1.0 Received: by 10.224.110.11 with SMTP id l11mr3096678qap.334.1273527134621; Mon, 10 May 2010 14:32:14 -0700 (PDT) Sender: kmatthew.macy@gmail.com Received: by 10.229.224.71 with HTTP; Mon, 10 May 2010 14:32:14 -0700 (PDT) In-Reply-To: <20100510182625.GF49209@bunrab.catwhisker.org> References: <20100510140722.GD49209@bunrab.catwhisker.org> <20100510182243.GV56080@hoeg.nl> <20100510182625.GF49209@bunrab.catwhisker.org> Date: Mon, 10 May 2010 14:32:14 -0700 X-Google-Sender-Auth: 4OAiyt_fhEpKBwA4sX89jblMX54 Message-ID: From: "K. Macy" To: David Wolfskill , Ed Schouten , current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: Panic @r207844; current process: flowcleaner "Fatal trap 12: page fault while in kernel mode" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: kmacy@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 21:32:17 -0000 Could you please try with 207902? Thanks, Kip On Mon, May 10, 2010 at 11:26 AM, David Wolfskill wr= ote: > On Mon, May 10, 2010 at 08:22:43PM +0200, Ed Schouten wrote: >> ... >> You don't happen to have a backtrace? > > Oops -- sorry; got caught up in getting ready to head in to work: > > db> bt > Tracing pid 20 tid 100067 td 0xc5a19000 > _mtx_lock_flags(58,0,c0cd2d5b,570,80,...) at _mtx_lock_flags+0x46 > flowtable_free_stale(c0e28f40,0,c0cd2d5b,600,0,...) at flowtable_free_sta= le+0x2fb > flowtable_cleaner(0,e9bc6d38,c0cbf058,343,c5f362a8,...) at flowtable_clea= ner+0xd0 > fork_exit(c094f920,0,e9bc6d38) at fork_exit+0xb8 > fork_trampoline() at fork_trampoline+0x8 > --- trap 0, eip =3D 0, esp =3D 0xe9bc6d70, ebp =3D 0 --- > db> > > Anything else that might be useful or interesting, please let me > know; as noted earlier, I left the machine in that state. =A0(I > normally power it off after the morning's =A0build/test festivities, > as it's loud & uses a fair amount of power.) > > Peace, > david > -- > David H. Wolfskill =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0david@catwhisker.org > Depriving a girl or boy of an opportunity for education is evil. > > See http://www.catwhisker.org/~david/publickey.gpg for my public key. > From owner-freebsd-current@FreeBSD.ORG Mon May 10 21:33:36 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BEB23106568A for ; Mon, 10 May 2010 21:33:36 +0000 (UTC) (envelope-from kmatthew.macy@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 331038FC18 for ; Mon, 10 May 2010 21:33:35 +0000 (UTC) Received: by vws8 with SMTP id 8so960495vws.13 for ; Mon, 10 May 2010 14:33:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:reply-to:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=3Aah+7uqNqfsIwGTnq6h7BHnF+s5wK9SBJTfGYLFxjs=; b=E8BpjrtMyogz16GS/KwM9SxyZ3YE/WirOxkS8OrxrCzXRkktxOI817xaN8NsnzASkf tVmZzw1n+nQXAbNqi2flfWvQ1YNUo5prrMIBy33tRbyDTtJxrgnNpqJz9vwmhLf338KR PHJwSfLJP4O+oR5quVFcyMzbhfbobSe9uOPNo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:reply-to:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; b=LpwuvhV4DIKOPLrk3JeQhTznp8r6H4QLSk2wpk1i5d087DiK/70VIyYMCrfN4Y/ZKM rTDNy4XL2+VQwZvTf1nyJLyqG/RbD496IEDFsK0J0Q045RU8jBw4SNnq45LIIpd0iTv6 xYBeJvQ1UryXbtGNGUnQGo013EZh007P+H5Go= MIME-Version: 1.0 Received: by 10.229.28.80 with SMTP id l16mr3051687qcc.91.1273527214450; Mon, 10 May 2010 14:33:34 -0700 (PDT) Sender: kmatthew.macy@gmail.com Received: by 10.229.224.71 with HTTP; Mon, 10 May 2010 14:33:34 -0700 (PDT) In-Reply-To: References: <20100510140722.GD49209@bunrab.catwhisker.org> <20100510182243.GV56080@hoeg.nl> <20100510182625.GF49209@bunrab.catwhisker.org> Date: Mon, 10 May 2010 14:33:34 -0700 X-Google-Sender-Auth: HReCRcRv0_NPOpkxybDiVPtW808 Message-ID: From: "K. Macy" To: David Wolfskill , Ed Schouten , current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: Re: Panic @r207844; current process: flowcleaner "Fatal trap 12: page fault while in kernel mode" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: kmacy@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 21:33:36 -0000 On Mon, May 10, 2010 at 2:32 PM, K. Macy wrote: > Could you please try with 207902? And if not, please get a coredump with a backtrace with symbols. Thanks From owner-freebsd-current@FreeBSD.ORG Mon May 10 21:41:40 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6718A106566B for ; Mon, 10 May 2010 21:41:40 +0000 (UTC) (envelope-from ianf@clue.co.za) Received: from inbound01.jnb1.gp-online.net (inbound01.jnb1.gp-online.net [41.161.16.135]) by mx1.freebsd.org (Postfix) with ESMTP id F1A498FC15 for ; Mon, 10 May 2010 21:41:39 +0000 (UTC) Received: from [41.154.88.19] (helo=clue.co.za) by inbound01.jnb1.gp-online.net with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1OBajJ-0004un-Jc; Mon, 10 May 2010 23:41:37 +0200 Received: from localhost ([127.0.0.1] helo=clue.co.za) by clue.co.za with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1OBajG-0000Qp-4R; Mon, 10 May 2010 23:41:34 +0200 To: Gustavo Perez Querol , current@freebsd.org From: Ian FREISLICH In-Reply-To: <20100510195622.GA1295@weongyo> References: <20100510195622.GA1295@weongyo> <20100228095259.GB3536@weongyo> <20100301103240.3a4aac8a.ray@dlink.ua> <20100303082833.GB22865@weongyo> <20100303111014.6564ea1e.ray@dlink.ua> <20100312231333.GZ1295@weongyo> <4BD2201E.3090409@entel.upc.edu> <20100424231755.GI65380@weongyo> <4BD4A928.8020901@entel.upc.edu> <20100506190653.GA31100@weongyo> <58220.88.15.97.205.1273248485.squirrel@webmail.entel.upc.edu> X-Attribution: BOFH Date: Mon, 10 May 2010 23:41:34 +0200 Message-Id: Cc: Subject: Re: Call for Test and Review: bwn(4) - another Broadcom Wireless driver X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 21:41:40 -0000 Weongyo Jeong wrote: > > Do you want me to test anything else ? > > OK. The patch is ready to test. Could you please test it with attached > patch? No panic this time. I also don't get these messages any more: May 10 23:25:36 mini kernel: bwn0: unsupported rate 0 May 10 23:26:13 mini last message repeated 2 times May 10 23:28:29 mini last message repeated 320 times May 10 23:28:32 mini last message repeated 61 times May 10 23:29:42 mini shutdown: reboot by ianf: It still doesn't associate with my AP until I destroy the wlan interface and create it again: wlan0: Ethernet address: 00:26:5e:57:23:33 bwn0: firmware version (rev 478 patch 104 date 0x8701 time 0x657) bwn0: need multicast update callback bwn0: RX decryption attempted (old 0 keyidx 0x1) bwn0: need multicast update callback bwn0: need multicast update callback and then I get lots of these but no where near the rate of the'unsupported rate' messages: May 10 23:31:39 mini kernel: bwn0: RX decryption attempted (old 0 keyidx 0x1) May 10 23:32:10 mini last message repeated 13 times May 10 23:34:09 mini last message repeated 34 times Ian -- Ian Freislich From owner-freebsd-current@FreeBSD.ORG Mon May 10 22:08:55 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 44EDA106566B; Mon, 10 May 2010 22:08:55 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from bunrab.catwhisker.org (adsl-63-193-123-122.dsl.snfc21.pacbell.net [63.193.123.122]) by mx1.freebsd.org (Postfix) with ESMTP id 9EEE18FC15; Mon, 10 May 2010 22:08:54 +0000 (UTC) Received: from bunrab.catwhisker.org (localhost [127.0.0.1]) by bunrab.catwhisker.org (8.13.3/8.13.3) with ESMTP id o4AM8skw096011; Mon, 10 May 2010 15:08:54 -0700 (PDT) (envelope-from david@bunrab.catwhisker.org) Received: (from david@localhost) by bunrab.catwhisker.org (8.13.3/8.13.3/Submit) id o4AM8sJ3096010; Mon, 10 May 2010 15:08:54 -0700 (PDT) (envelope-from david) Date: Mon, 10 May 2010 15:08:54 -0700 From: David Wolfskill To: "K. Macy" Message-ID: <20100510220854.GK49209@bunrab.catwhisker.org> Mail-Followup-To: David Wolfskill , "K. Macy" , current@freebsd.org References: <20100510140722.GD49209@bunrab.catwhisker.org> <20100510182243.GV56080@hoeg.nl> <20100510182625.GF49209@bunrab.catwhisker.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="KBQi/TxAuyHKotC8" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: current@freebsd.org Subject: Re: Panic @r207844; current process: flowcleaner "Fatal trap 12: page fault while in kernel mode" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 22:08:55 -0000 --KBQi/TxAuyHKotC8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, May 10, 2010 at 02:32:14PM -0700, K. Macy wrote: > Could you please try with 207902? > ... First, thanks for the response. OK; I grabbed r207902 & applied it (via "patch -p1"), then rebuilt the kernel & rebooted; here's the panic now: 3 Select option, [Enter] for default 3 3 or [Space] to pause timer 9 3 @DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2010 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 9.0-CURRENT #155 r207844M: Mon May 10 14:55:41 PDT 2010 root@freebeast.catwhisker.org:/usr/obj/usr/src/sys/GENERIC i386 WARNING: WITNESS option enabled, expect reduced performance. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(TM) CPU 3.60GHz (3610.95-MHz 686-class CPU) Origin =3D "GenuineIntel" Id =3D 0xf41 Family =3D f Model =3D 4 Stepp= ing =3D 1 Features=3D0xbfebfbff Features2=3D0x659d AMD Features=3D0x20100000 TSC: P-state invariant real memory =3D 2147483648 (2048 MB) avail memory =3D 2086129664 (1989 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 2 package(s) x 1 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 6 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-47 on motherboard ioapic2 irqs 48-71 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 0x1008-0x100b on acpi0 cpu0: on acpi0 cpu1: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: at device 0.1 (no driver attached) pci0: at device 1.0 (no driver attached) pcib1: irq 16 at device 2.0 on pci0 pci1: on pcib1 pcib2: at device 0.0 on pci1 pci2: on pcib2 aac0: mem 0xdc000000-0xdfffffff irq 24 at device = 1.0 on pci2 aac0: Enable Raw I/O aac0: New comm. interface enabled aac0: [ITHREAD] aac0: Adaptec 2200S, aac driver 2.1.9-1 aacp0: on aac0 aacp1: on aac0 pcib3: at device 0.2 on pci1 pci3: on pcib3 em0: port 0x2000-0x203f= mem 0xd8200000-0xd821ffff irq 54 at device 2.0 on pci3 em0: [FILTER] em0: Ethernet address: 00:30:48:2d:32:6a em1: port 0x2040-0x207f= mem 0xd8220000-0xd823ffff irq 55 at device 2.1 on pci3 em1: [FILTER] em1: Ethernet address: 00:30:48:2d:32:6b pcib4: irq 16 at device 4.0 on pci0 pci4: on pcib4 pcib5: irq 16 at device 6.0 on pci0 pci5: on pcib5 uhci0: port 0x1400-0x141f irq 1= 6 at device 29.0 on pci0 uhci0: [ITHREAD] usbus0: on uhci0 uhci1: port 0x1420-0x143f irq 1= 9 at device 29.1 on pci0 uhci1: [ITHREAD] usbus1: on uhci1 uhci2: port 0x1440-0x145f irq 1= 8 at device 29.2 on pci0 uhci2: [ITHREAD] usbus2: on uhci2 uhci3: port 0x1460-0x147f irq 1= 6 at device 29.3 on pci0 uhci3: [ITHREAD] usbus3: on uhci3 ehci0: mem 0xd8001000-0xd80013f= f irq 23 at device 29.7 on pci0 ehci0: [ITHREAD] usbus4: EHCI version 1.0 usbus4: on ehci0 pcib6: at device 30.0 on pci0 pci6: on pcib6 vgapci0: port 0x3000-0x30ff mem 0xd9000000-0xd9fff= fff,0xd8300000-0xd8300fff irq 17 at device 1.0 on pci6 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177= ,0x376,0x14a0-0x14af at device 31.1 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] pci0: at device 31.3 (no driver attached) acpi_button0: on acpi0 atrtc0: port 0x70-0x77 irq 8 on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model Generic PS/2 mouse, device ID 0 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart0: [FILTER] uart0: console (9600,n,8,1) uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 uart1: [FILTER] fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FILTER] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 pmtimer0 on isa0 orm0: at iomem 0xc0000-0xc7fff,0xc8000-0xc8fff,0xc9000-0x= c9fff,0xca000-0xcafff,0xcb000-0xcf7ff pnpid ORM0000 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=3D0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ppc0: parallel port not found. est0: on cpu0 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 122d00000e24 device_attach: est0 attach returned 6 p4tcc0: on cpu0 est1: on cpu1 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 122d00000e24 device_attach: est1 attach returned 6 p4tcc1: on cpu1 Timecounters tick every 1.000 msec usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 12Mbps Full Speed USB v1.0 usbus4: 480Mbps High Speed USB v2.0 ata1: DMA limited to UDMA33, controller found non-ATA66 cable ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 ugen4.1: at usbus4 uhub4: on usbus4 acd0: DVDROM at ata1-slave UDMA33=20 aacd0: on aac0 aacd0: 34970MB (71619584 sectors) aacd1: on aac0 aacd1: 69974MB (143307008 sectors) uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered uhub3: 2 ports with 2 removable, self powered uhub4: 8 ports with 8 removable, self powered ses0 at aacp0 bus 0 scbus0 target 6 lun 0 ses0: Fixed Uninstalled SCSI-2 device=20 ses0: 3.300MB/s transfers ses0: SAF-TE Compliant Device pass0 at aacp0 bus 0 scbus0 target 0 lun 0 pass0: Fixed Uninstalled SCSI-3 device=20 pass0: 3.300MB/s transfers pass1 at aacp0 bus 0 scbus0 target 1 lun 0 pass1: Fixed Uninstalled SCSI-3 device=20 pass1: 3.300MB/s transfers pass2 at aacp0 bus 0 scbus0 target 2 lun 0 pass2: Fixed Uninstalled SCSI-3 device=20 pass2: 3.300MB/s transfers pass3 at aacp0 bus 0 scbus0 target 3 lun 0 pass3: Fixed Uninstalled SCSI-3 device=20 pass3: 3.300MB/s transfers SMP: AP CPU #1 Launched! WARNING: WITNESS option enabled, expect reduced performance. Trying to mount root from ufs:/dev/aacd0s4a Setting hostuuid: 80f1e964-dc63-0010-89d5-0030482d326a. Setting hostid: 0xc74551dd. Entropy harvesting: interrupts ethernet point_to_point kickstart. Starting file system checks: /dev/aacd0s4a: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/aacd0s4a: clean, 422048 free (1216 frags, 52604 blocks, 0.2% fragmenta= tion) /dev/aacd1s1e: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/aacd1s1e: clean, 4681662 free (261046 frags, 552577 blocks, 2.0% fragm= entation) /dev/aacd0s1a: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/aacd0s1a: clean, 424969 free (1913 frags, 52882 blocks, 0.3% fragmenta= tion) /dev/aacd0s1d: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/aacd0s1d: clean, 1031838 free (4190 frags, 128456 blocks, 0.2% fragmen= tation) /dev/aacd1s1d: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/aacd1s1d: clean, 11717829 free (197893 frags, 1439992 blocks, 1.2% fra= gmentation) /dev/aacd0s2a: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/aacd0s2a: clean, 596256 free (1488 frags, 74346 blocks, 0.2% fragmenta= tion) /dev/aacd0s2d: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/aacd0s2d: clean, 1108521 free (23105 frags, 135677 blocks, 1.3% fragme= ntation) /dev/aacd0s3a: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/aacd0s3a: clean, 578034 free (1146 frags, 72111 blocks, 0.2% fragmenta= tion) /dev/aacd0s3d: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/aacd0s3d: clean, 1070844 free (39380 frags, 128933 blocks, 2.2% fragme= ntation) /dev/aacd0s4d: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/aacd0s4d: clean, 1075950 free (60166 frags, 126973 blocks, 3.4% fragme= ntation) /dev/aacd0s4f: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/aacd0s4f: clean, 2106304 free (344 frags, 263245 blocks, 0.0% fragment= ation) Mounting local file systems:. Setting hostname: freebeast.catwhisker.org. lock order reversal: 1st 0xc683e7c8 ufs (ufs) @ /usr/src/sys/kern/vfs_lookup.c:502 2nd 0xd94fe700 bufwait (bufwait) @ /usr/src/sys/ufs/ffs/ffs_softdep.c:11363 3rd 0xc6871168 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2091 KDB: stack backtrace: db_trace_self_wrapper(c0cc72a5,ebdf2300,c08e9f65,c08da2db,c0cca298,...) at = db_trace_self_wrapper+0x26 kdb_backtrace(c08da2db,c0cca298,c553d030,c5540568,ebdf235c,...) at kdb_back= trace+0x29 _witness_debugger(c0cca298,c6871168,c0cbc5bd,c5540568,c0cd13b1,...) at _wit= ness_debugger+0x25 witness_checkorder(c6871168,9,c0cd13b1,82b,0,...) at witness_checkorder+0x8= 39 __lockmgr_args(c6871168,80100,c6871188,0,0,...) at __lockmgr_args+0x7f9 ffs_lock(ebdf2480,c08e9d0b,c0cd0856,80100,c6871110,...) at ffs_lock+0x8a VOP_LOCK1_APV(c0dd4ee0,ebdf2480,c63cecd4,c0def920,c6871110,...) at VOP_LOCK= 1_APV+0xb5 _vn_lock(c6871110,80100,c0cd13b1,82b,4,...) at _vn_lock+0x5e vget(c6871110,80100,c63cec30,50,0,...) at vget+0xb9 vfs_hash_get(c6857ca8,78c22,80000,c63cec30,ebdf25d0,...) at vfs_hash_get+0x= e6 ffs_vgetf(c6857ca8,78c22,80000,ebdf25d0,1,...) at ffs_vgetf+0x49 softdep_sync_metadata(c683e770,0,c0ced5f8,144,0,...) at softdep_sync_metada= ta+0xc92 ffs_syncvnode(c683e770,1,c63cec30,ebdf2690,246,...) at ffs_syncvnode+0x3e2 ffs_truncate(c683e770,200,0,880,c5588480,...) at ffs_truncate+0x862 ufs_direnter(c683e770,c6871110,ebdf2944,ebdf2bd4,0,...) at ufs_direnter+0x8= d4 ufs_makeinode(ebdf2bd4,0,ebdf2b30,ebdf2a8c,c0c032e5,...) at ufs_makeinode+0= x557 ufs_create(ebdf2b30,ebdf2b48,0,0,ebdf2ba8,...) at ufs_create+0x30 VOP_CREATE_APV(c0dd4ee0,ebdf2b30,ebdf2bd4,ebdf2ac8,0,...) at VOP_CREATE_APV= +0xa5 vn_open_cred(ebdf2ba8,ebdf2c5c,1a4,0,c5588480,...) at vn_open_cred+0x215 vn_open(ebdf2ba8,ebdf2c5c,1a4,c637ee70,0,...) at vn_open+0x3b kern_openat(c63cec30,ffffff9c,804c5e8,0,602,...) at kern_openat+0x125 kern_open(c63cec30,804c5e8,0,601,21b6,...) at kern_open+0x35 open(c63cec30,ebdf2cf8,c0cffdfb,c0caa6d4,c63c9d48,...) at open+0x30 syscall(ebdf2d38) at syscall+0x220 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (5, FreeBSD ELF32, open), eip =3D 0x281744b3, esp =3D 0xbfbfec4= c, ebp =3D 0xbfbfecb8 --- Starting Network: lo0 em0 em1. lo0: flags=3D8049 metric 0 mtu 16384 options=3D3 inet 127.0.0.1 netmask 0xff000000=20 inet6 ::1 prefixlen 128=20 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3=20 nd6 options=3D21 em0: flags=3D8843 metric 0 mtu 1500 options=3D389b ether 00:30:48:2d:32:6a inet 172.16.8.10 netmask 0xffffff00 broadcast 172.16.8.255 inet6 fe80::230:48ff:fe2d:326a%em0 prefixlen 64 tentative scopeid 0= x1=20 nd6 options=3D29 media: Ethernet autoselect status: no carrier em1: flags=3D8802 metric 0 mtu 1500 options=3D389b ether 00:30:48:2d:32:6b media: Ethernet autoselect status: no carrier Starting devd. Starting Network: em1. em1: flags=3D8802 metric 0 mtu 1500 options=3D389b ether 00:30:48:2d:32:6b media: Ethernet autoselect status: no carrier add net default: gateway 172.16.8.1 add net ::ffff:0.0.0.0: gateway ::1 add net ::0.0.0.0: gateway ::1 add net fe80::: gateway ::1 add net ff02::: gateway ::1 ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib /usr/local/= lib/compat a.out ldconfig path: /usr/lib/aout /usr/lKernel page fault with the followi= ng non-sleepable locks held: exclusive sleep mutex mld_mtx (mld_mtx) r =3D 0 (0xc0f96468) locked @ /usr/= src/sys/netinet6/mld6.c:1352 exclusive sleep mutex in6_multi_mtx (in6_multi_mtx) r =3D 0 (0xc0f95408) lo= cked @ /usr/src/sys/netinet6/mld6.c:1351 KDB: stack backtrace: db_trace_self_wrapper(c0cc72a5,c5213864,c08e9f65,c0ce3e07,547,...) at db_tr= ace_self_wrapper+0x26 kdb_backtrace(c0ce3e07,547,ffffffff,c0f65a1c,c521389c,...) at kdb_backtrace= +0x29 _witness_debugger(c0cc982b,c52138b0,4,1,0,...) at _witness_debugger+0x25 witness_warn(5,0,c0cffec8,c55810a4,c557f7f8,...) at witness_warn+0x1fd trap(c521393c) at trap+0x19e calltrap() at calltrap+0x6 --- trap 0xc, eip =3D 0xc0a4d340, esp =3D 0xc521397c, ebp =3D 0xc5213b14 --- ip6_output(c5a4fc00,c0f964a0,0,1,c5213b44,...) at ip6_output+0x840 mld_dispatch_packet(0,0,c5213c1c,c0a509a7,c56fca2c,...) at mld_dispatch_pac= ket+0x30d mld_dispatch_queue(c56fca2c,0,c0ce3e07,591,c0cbb984,...) at mld_dispatch_qu= eue+0x38 mld_fasttimo(c5213c48,c0904cc9,c5213c48,c0893aa4,c0e24f80,...) at mld_fastt= imo+0x747 icmp6_fasttimo(c5213c48,c0893aa4,c0e24f80,4,c0cc24d6,...) at icmp6_fasttimo= +0x8 pffasttimo(0,0,c0cc5113,189,c0e24fb8,...) at pffasttimo+0x29 softclock(c0e24f80,c5213cc8,c0893aa4,c0e28940,c5588838,...) at softclock+0x= 24a intr_event_execute_handlers(c557f7f8,c5588800,c0cbf33f,533,c5588870,...) at= intr_event_execute_handlers+0x125 ithread_loop(c557e120,c5213d38,c0cbf0b8,343,c557f7f8,...) at ithread_loop+0= x9f fork_exit(c087c780,c557e120,c5213d38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip =3D 0, esp =3D 0xc5213d70, ebp =3D 0 --- Fatal trap 12: page fault while in kernel mode cpuid =3D 0; apic id =3D 00 fault virtual address =3D 0x3c fault code =3D supervisor read, page not present instruction pointer =3D 0x20:0xc0a4d340 stack pointer =3D 0x28:0xc521397c frame pointer =3D 0x28:0xc5213b14 code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, def32 1, gran 1 processor eflags =3D interrupt enabled, resume, IOPL =3D 0 current process =3D 12 (swi4: clock) [ thread pid 12 tid 100007 ] Stopped at ip6_output+0x840: movl 0x3c(%eax),%eax db> bt Tracing pid 12 tid 100007 td 0xc5581000 ip6_output(c5a4fc00,c0f964a0,0,1,c5213b44,...) at ip6_output+0x840 mld_dispatch_packet(0,0,c5213c1c,c0a509a7,c56fca2c,...) at mld_dispatch_pac= ket+0x30d mld_dispatch_queue(c56fca2c,0,c0ce3e07,591,c0cbb984,...) at mld_dispatch_qu= eue+0x38 mld_fasttimo(c5213c48,c0904cc9,c5213c48,c0893aa4,c0e24f80,...) at mld_fastt= imo+0x747 icmp6_fasttimo(c5213c48,c0893aa4,c0e24f80,4,c0cc24d6,...) at icmp6_fasttimo= +0x8 pffasttimo(0,0,c0cc5113,189,c0e24fb8,...) at pffasttimo+0x29 softclock(c0e24f80,c5213cc8,c0893aa4,c0e28940,c5588838,...) at softclock+0x= 24a intr_event_execute_handlers(c557f7f8,c5588800,c0cbf33f,533,c5588870,...) at= intr_event_execute_handlers+0x125 ithread_loop(c557e120,c5213d38,c0cbf0b8,343,c557f7f8,...) at ithread_loop+0= x9f fork_exit(c087c780,c557e120,c5213d38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip =3D 0, esp =3D 0xc5213d70, ebp =3D 0 --- db>=20 Again, I can poke at it a bit if additional information might be useful. On a positive note, when I powered it off earlier, I had (only) disabled wol_mcast, so I was able to power it back up remotely by telling my firewall machine to send magic packets to it. :-} Peace, david --=20 David H. Wolfskill david@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --KBQi/TxAuyHKotC8 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iEYEARECAAYFAkvog/UACgkQmprOCmdXAD0GQQCdERNo/Mmb6+odE7b+jBFuLIxZ BbUAniAf9AI5qKJNX8+EOqUybfCUX8UP =VQZQ -----END PGP SIGNATURE----- --KBQi/TxAuyHKotC8-- From owner-freebsd-current@FreeBSD.ORG Mon May 10 22:39:12 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AF3B71065672; Mon, 10 May 2010 22:39:12 +0000 (UTC) (envelope-from kmatthew.macy@gmail.com) Received: from mail-qy0-f181.google.com (mail-qy0-f181.google.com [209.85.221.181]) by mx1.freebsd.org (Postfix) with ESMTP id 490B78FC1F; Mon, 10 May 2010 22:39:11 +0000 (UTC) Received: by qyk11 with SMTP id 11so6301549qyk.13 for ; Mon, 10 May 2010 15:39:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:reply-to:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:content-type:content-transfer-encoding; bh=paMsq0NDwisFP50Zed41pyQShLZOPsS1z6g+F6/3OrI=; b=CJerndIGrWTYBLiZvQTWOR7fVBKNV74ZzcgJu7YL3ir8PJVCke9Zzvj6vdbQ9rqrui KxrDeVEv7+FwI3v9kj7CKVEPBqebbZPGpJloLRVNNH0uMyff7Sju+CnjGouwnZBtM/QK 0FNyJwtLWPkS2wash3oBJ7OTUOAtf3psSLnoY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:reply-to:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; b=rlkJc7Ry7pMZuI7yzOE8Idyj8LY260y00P9xB7iLH6dVL73YawXGmFdMOvxlvhnn76 4GujQgzXQn43V5rvvANY2qM5rksdwrfOAmivaY2N1Wpx7+cCPQ1yd2D1sk9y3qjiudOT 6wkiTr3lHBfeyqfQ0qxi2xBejnS7nAIyvgATI= MIME-Version: 1.0 Received: by 10.229.222.208 with SMTP id ih16mr3952069qcb.55.1273531151374; Mon, 10 May 2010 15:39:11 -0700 (PDT) Sender: kmatthew.macy@gmail.com Received: by 10.229.224.71 with HTTP; Mon, 10 May 2010 15:39:11 -0700 (PDT) In-Reply-To: <20100510220854.GK49209@bunrab.catwhisker.org> References: <20100510140722.GD49209@bunrab.catwhisker.org> <20100510182243.GV56080@hoeg.nl> <20100510182625.GF49209@bunrab.catwhisker.org> <20100510220854.GK49209@bunrab.catwhisker.org> Date: Mon, 10 May 2010 15:39:11 -0700 X-Google-Sender-Auth: 2NtBCSaIDcJiXGgxM8aGGhYfYB8 Message-ID: From: "K. Macy" To: David Wolfskill , "K. Macy" , current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: Panic @r207844; current process: flowcleaner "Fatal trap 12: page fault while in kernel mode" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: kmacy@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 22:39:12 -0000 Are you not able to dump core? Thanks, Kip On Mon, May 10, 2010 at 3:08 PM, David Wolfskill wro= te: > On Mon, May 10, 2010 at 02:32:14PM -0700, K. Macy wrote: >> Could you please try with 207902? >> ... > > First, thanks for the response. > > OK; I grabbed r207902 & applied it (via "patch -p1"), then rebuilt the > kernel & rebooted; here's the panic now: > > =A03 =A0Select option, [Enter] for default =A0 =A0 3 > =A03 =A0or [Space] to pause timer =A09 =A0 =A0 =A0 =A0 =A0 3 > =A0@DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY > > > GDB: no debug ports present > KDB: debugger backends: ddb > KDB: current backend: ddb > Copyright (c) 1992-2010 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > =A0 =A0 =A0 =A0The Regents of the University of California. All rights re= served. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 9.0-CURRENT #155 r207844M: Mon May 10 14:55:41 PDT 2010 > =A0 =A0root@freebeast.catwhisker.org:/usr/obj/usr/src/sys/GENERIC i386 > WARNING: WITNESS option enabled, expect reduced performance. > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: Intel(R) Xeon(TM) CPU 3.60GHz (3610.95-MHz 686-class CPU) > =A0Origin =3D "GenuineIntel" =A0Id =3D 0xf41 =A0Family =3D f =A0Model =3D= 4 =A0Stepping =3D 1 > =A0Features=3D0xbfebfbff > =A0Features2=3D0x659d > =A0AMD Features=3D0x20100000 > =A0TSC: P-state invariant > real memory =A0=3D 2147483648 (2048 MB) > avail memory =3D 2086129664 (1989 MB) > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > FreeBSD/SMP: 2 package(s) x 1 core(s) > =A0cpu0 (BSP): APIC ID: =A00 > =A0cpu1 (AP): APIC ID: =A06 > ioapic0 irqs 0-23 on motherboard > ioapic1 irqs 24-47 on motherboard > ioapic2 irqs 48-71 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 0x1008-0x100b on acpi0 > cpu0: on acpi0 > cpu1: on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > pci0: at device 0.1 (no driver attached) > pci0: at device 1.0 (no driver attached) > pcib1: irq 16 at device 2.0 on pci0 > pci1: on pcib1 > pcib2: at device 0.0 on pci1 > pci2: on pcib2 > aac0: mem 0xdc000000-0xdfffffff irq 24 at devic= e 1.0 on pci2 > aac0: Enable Raw I/O > aac0: New comm. interface enabled > aac0: [ITHREAD] > aac0: Adaptec 2200S, aac driver 2.1.9-1 > aacp0: on aac0 > aacp1: on aac0 > pcib3: at device 0.2 on pci1 > pci3: on pcib3 > em0: port 0x2000-0x20= 3f mem 0xd8200000-0xd821ffff irq 54 at device 2.0 on pci3 > em0: [FILTER] > em0: Ethernet address: 00:30:48:2d:32:6a > em1: port 0x2040-0x20= 7f mem 0xd8220000-0xd823ffff irq 55 at device 2.1 on pci3 > em1: [FILTER] > em1: Ethernet address: 00:30:48:2d:32:6b > pcib4: irq 16 at device 4.0 on pci0 > pci4: on pcib4 > pcib5: irq 16 at device 6.0 on pci0 > pci5: on pcib5 > uhci0: port 0x1400-0x141f irq= 16 at device 29.0 on pci0 > uhci0: [ITHREAD] > usbus0: on uhci0 > uhci1: port 0x1420-0x143f irq= 19 at device 29.1 on pci0 > uhci1: [ITHREAD] > usbus1: on uhci1 > uhci2: port 0x1440-0x145f irq= 18 at device 29.2 on pci0 > uhci2: [ITHREAD] > usbus2: on uhci2 > uhci3: port 0x1460-0x147f irq= 16 at device 29.3 on pci0 > uhci3: [ITHREAD] > usbus3: on uhci3 > ehci0: mem 0xd8001000-0xd8001= 3ff irq 23 at device 29.7 on pci0 > ehci0: [ITHREAD] > usbus4: EHCI version 1.0 > usbus4: on ehci0 > pcib6: at device 30.0 on pci0 > pci6: on pcib6 > vgapci0: port 0x3000-0x30ff mem 0xd9000000-0xd9f= fffff,0xd8300000-0xd8300fff irq 17 at device 1.0 on pci6 > isab0: at device 31.0 on pci0 > isa0: on isab0 > atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x1= 77,0x376,0x14a0-0x14af at device 31.1 on pci0 > ata0: on atapci0 > ata0: [ITHREAD] > ata1: on atapci0 > ata1: [ITHREAD] > pci0: at device 31.3 (no driver attached) > acpi_button0: on acpi0 > atrtc0: port 0x70-0x77 irq 8 on acpi0 > atkbdc0: port 0x60,0x64 irq 1 on acpi0 > atkbd0: irq 1 on atkbdc0 > kbd0 at atkbd0 > atkbd0: [GIANT-LOCKED] > atkbd0: [ITHREAD] > psm0: irq 12 on atkbdc0 > psm0: [GIANT-LOCKED] > psm0: [ITHREAD] > psm0: model Generic PS/2 mouse, device ID 0 > uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 > uart0: [FILTER] > uart0: console (9600,n,8,1) > uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 > uart1: [FILTER] > fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acp= i0 > fdc0: [FILTER] > fd0: <1440-KB 3.5" drive> on fdc0 drive 0 > pmtimer0 on isa0 > orm0: at iomem 0xc0000-0xc7fff,0xc8000-0xc8fff,0xc9000-= 0xc9fff,0xca000-0xcafff,0xcb000-0xcf7ff pnpid ORM0000 on isa0 > sc0: at flags 0x100 on isa0 > sc0: VGA <16 virtual consoles, flags=3D0x300> > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > ppc0: parallel port not found. > est0: on cpu0 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 122d00000e24 > device_attach: est0 attach returned 6 > p4tcc0: on cpu0 > est1: on cpu1 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 122d00000e24 > device_attach: est1 attach returned 6 > p4tcc1: on cpu1 > Timecounters tick every 1.000 msec > usbus0: 12Mbps Full Speed USB v1.0 > usbus1: 12Mbps Full Speed USB v1.0 > usbus2: 12Mbps Full Speed USB v1.0 > usbus3: 12Mbps Full Speed USB v1.0 > usbus4: 480Mbps High Speed USB v2.0 > ata1: DMA limited to UDMA33, controller found non-ATA66 cable > ugen0.1: at usbus0 > uhub0: on usbus0 > ugen1.1: at usbus1 > uhub1: on usbus1 > ugen2.1: at usbus2 > uhub2: on usbus2 > ugen3.1: at usbus3 > uhub3: on usbus3 > ugen4.1: at usbus4 > uhub4: on usbus4 > acd0: DVDROM at ata1-slave UDMA33 > aacd0: on aac0 > aacd0: 34970MB (71619584 sectors) > aacd1: on aac0 > aacd1: 69974MB (143307008 sectors) > uhub0: 2 ports with 2 removable, self powered > uhub1: 2 ports with 2 removable, self powered > uhub2: 2 ports with 2 removable, self powered > uhub3: 2 ports with 2 removable, self powered > uhub4: 8 ports with 8 removable, self powered > ses0 at aacp0 bus 0 scbus0 target 6 lun 0 > ses0: Fixed Uninstalled SCSI-2 device > ses0: 3.300MB/s transfers > ses0: SAF-TE Compliant Device > pass0 at aacp0 bus 0 scbus0 target 0 lun 0 > pass0: Fixed Uninstalled SCSI-3 device > pass0: 3.300MB/s transfers > pass1 at aacp0 bus 0 scbus0 target 1 lun 0 > pass1: Fixed Uninstalled SCSI-3 device > pass1: 3.300MB/s transfers > pass2 at aacp0 bus 0 scbus0 target 2 lun 0 > pass2: Fixed Uninstalled SCSI-3 device > pass2: 3.300MB/s transfers > pass3 at aacp0 bus 0 scbus0 target 3 lun 0 > pass3: Fixed Uninstalled SCSI-3 device > pass3: 3.300MB/s transfers > SMP: AP CPU #1 Launched! > WARNING: WITNESS option enabled, expect reduced performance. > Trying to mount root from ufs:/dev/aacd0s4a > Setting hostuuid: 80f1e964-dc63-0010-89d5-0030482d326a. > Setting hostid: 0xc74551dd. > Entropy harvesting: interrupts ethernet point_to_point kickstart. > Starting file system checks: > /dev/aacd0s4a: FILE SYSTEM CLEAN; SKIPPING CHECKS > /dev/aacd0s4a: clean, 422048 free (1216 frags, 52604 blocks, 0.2% fragmen= tation) > /dev/aacd1s1e: FILE SYSTEM CLEAN; SKIPPING CHECKS > /dev/aacd1s1e: clean, 4681662 free (261046 frags, 552577 blocks, 2.0% fra= gmentation) > /dev/aacd0s1a: FILE SYSTEM CLEAN; SKIPPING CHECKS > /dev/aacd0s1a: clean, 424969 free (1913 frags, 52882 blocks, 0.3% fragmen= tation) > /dev/aacd0s1d: FILE SYSTEM CLEAN; SKIPPING CHECKS > /dev/aacd0s1d: clean, 1031838 free (4190 frags, 128456 blocks, 0.2% fragm= entation) > /dev/aacd1s1d: FILE SYSTEM CLEAN; SKIPPING CHECKS > /dev/aacd1s1d: clean, 11717829 free (197893 frags, 1439992 blocks, 1.2% f= ragmentation) > /dev/aacd0s2a: FILE SYSTEM CLEAN; SKIPPING CHECKS > /dev/aacd0s2a: clean, 596256 free (1488 frags, 74346 blocks, 0.2% fragmen= tation) > /dev/aacd0s2d: FILE SYSTEM CLEAN; SKIPPING CHECKS > /dev/aacd0s2d: clean, 1108521 free (23105 frags, 135677 blocks, 1.3% frag= mentation) > /dev/aacd0s3a: FILE SYSTEM CLEAN; SKIPPING CHECKS > /dev/aacd0s3a: clean, 578034 free (1146 frags, 72111 blocks, 0.2% fragmen= tation) > /dev/aacd0s3d: FILE SYSTEM CLEAN; SKIPPING CHECKS > /dev/aacd0s3d: clean, 1070844 free (39380 frags, 128933 blocks, 2.2% frag= mentation) > /dev/aacd0s4d: FILE SYSTEM CLEAN; SKIPPING CHECKS > /dev/aacd0s4d: clean, 1075950 free (60166 frags, 126973 blocks, 3.4% frag= mentation) > /dev/aacd0s4f: FILE SYSTEM CLEAN; SKIPPING CHECKS > /dev/aacd0s4f: clean, 2106304 free (344 frags, 263245 blocks, 0.0% fragme= ntation) > Mounting local file systems:. > Setting hostname: freebeast.catwhisker.org. > lock order reversal: > =A01st 0xc683e7c8 ufs (ufs) @ /usr/src/sys/kern/vfs_lookup.c:502 > =A02nd 0xd94fe700 bufwait (bufwait) @ /usr/src/sys/ufs/ffs/ffs_softdep.c:= 11363 > =A03rd 0xc6871168 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2091 > KDB: stack backtrace: > db_trace_self_wrapper(c0cc72a5,ebdf2300,c08e9f65,c08da2db,c0cca298,...) a= t db_trace_self_wrapper+0x26 > kdb_backtrace(c08da2db,c0cca298,c553d030,c5540568,ebdf235c,...) at kdb_ba= cktrace+0x29 > _witness_debugger(c0cca298,c6871168,c0cbc5bd,c5540568,c0cd13b1,...) at _w= itness_debugger+0x25 > witness_checkorder(c6871168,9,c0cd13b1,82b,0,...) at witness_checkorder+0= x839 > __lockmgr_args(c6871168,80100,c6871188,0,0,...) at __lockmgr_args+0x7f9 > ffs_lock(ebdf2480,c08e9d0b,c0cd0856,80100,c6871110,...) at ffs_lock+0x8a > VOP_LOCK1_APV(c0dd4ee0,ebdf2480,c63cecd4,c0def920,c6871110,...) at VOP_LO= CK1_APV+0xb5 > _vn_lock(c6871110,80100,c0cd13b1,82b,4,...) at _vn_lock+0x5e > vget(c6871110,80100,c63cec30,50,0,...) at vget+0xb9 > vfs_hash_get(c6857ca8,78c22,80000,c63cec30,ebdf25d0,...) at vfs_hash_get+= 0xe6 > ffs_vgetf(c6857ca8,78c22,80000,ebdf25d0,1,...) at ffs_vgetf+0x49 > softdep_sync_metadata(c683e770,0,c0ced5f8,144,0,...) at softdep_sync_meta= data+0xc92 > ffs_syncvnode(c683e770,1,c63cec30,ebdf2690,246,...) at ffs_syncvnode+0x3e= 2 > ffs_truncate(c683e770,200,0,880,c5588480,...) at ffs_truncate+0x862 > ufs_direnter(c683e770,c6871110,ebdf2944,ebdf2bd4,0,...) at ufs_direnter+0= x8d4 > ufs_makeinode(ebdf2bd4,0,ebdf2b30,ebdf2a8c,c0c032e5,...) at ufs_makeinode= +0x557 > ufs_create(ebdf2b30,ebdf2b48,0,0,ebdf2ba8,...) at ufs_create+0x30 > VOP_CREATE_APV(c0dd4ee0,ebdf2b30,ebdf2bd4,ebdf2ac8,0,...) at VOP_CREATE_A= PV+0xa5 > vn_open_cred(ebdf2ba8,ebdf2c5c,1a4,0,c5588480,...) at vn_open_cred+0x215 > vn_open(ebdf2ba8,ebdf2c5c,1a4,c637ee70,0,...) at vn_open+0x3b > kern_openat(c63cec30,ffffff9c,804c5e8,0,602,...) at kern_openat+0x125 > kern_open(c63cec30,804c5e8,0,601,21b6,...) at kern_open+0x35 > open(c63cec30,ebdf2cf8,c0cffdfb,c0caa6d4,c63c9d48,...) at open+0x30 > syscall(ebdf2d38) at syscall+0x220 > Xint0x80_syscall() at Xint0x80_syscall+0x20 > --- syscall (5, FreeBSD ELF32, open), eip =3D 0x281744b3, esp =3D 0xbfbfe= c4c, ebp =3D 0xbfbfecb8 --- > Starting Network: lo0 em0 em1. > lo0: flags=3D8049 metric 0 mtu 16384 > =A0 =A0 =A0 =A0options=3D3 > =A0 =A0 =A0 =A0inet 127.0.0.1 netmask 0xff000000 > =A0 =A0 =A0 =A0inet6 ::1 prefixlen 128 > =A0 =A0 =A0 =A0inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 > =A0 =A0 =A0 =A0nd6 options=3D21 > em0: flags=3D8843 metric 0 mtu 15= 00 > =A0 =A0 =A0 =A0options=3D389b > =A0 =A0 =A0 =A0ether 00:30:48:2d:32:6a > =A0 =A0 =A0 =A0inet 172.16.8.10 netmask 0xffffff00 broadcast 172.16.8.255 > =A0 =A0 =A0 =A0inet6 fe80::230:48ff:fe2d:326a%em0 prefixlen 64 tentative = scopeid 0x1 > =A0 =A0 =A0 =A0nd6 options=3D29 > =A0 =A0 =A0 =A0media: Ethernet autoselect > =A0 =A0 =A0 =A0status: no carrier > em1: flags=3D8802 metric 0 mtu 1500 > =A0 =A0 =A0 =A0options=3D389b > =A0 =A0 =A0 =A0ether 00:30:48:2d:32:6b > =A0 =A0 =A0 =A0media: Ethernet autoselect > =A0 =A0 =A0 =A0status: no carrier > Starting devd. > Starting Network: em1. > em1: flags=3D8802 metric 0 mtu 1500 > =A0 =A0 =A0 =A0options=3D389b > =A0 =A0 =A0 =A0ether 00:30:48:2d:32:6b > =A0 =A0 =A0 =A0media: Ethernet autoselect > =A0 =A0 =A0 =A0status: no carrier > add net default: gateway 172.16.8.1 > add net ::ffff:0.0.0.0: gateway ::1 > add net ::0.0.0.0: gateway ::1 > add net fe80::: gateway ::1 > add net ff02::: gateway ::1 > ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib /usr/loca= l/lib/compat > a.out ldconfig path: /usr/lib/aout /usr/lKernel page fault with the follo= wing non-sleepable locks held: > exclusive sleep mutex mld_mtx (mld_mtx) r =3D 0 (0xc0f96468) locked @ /us= r/src/sys/netinet6/mld6.c:1352 > exclusive sleep mutex in6_multi_mtx (in6_multi_mtx) r =3D 0 (0xc0f95408) = locked @ /usr/src/sys/netinet6/mld6.c:1351 > KDB: stack backtrace: > db_trace_self_wrapper(c0cc72a5,c5213864,c08e9f65,c0ce3e07,547,...) at db_= trace_self_wrapper+0x26 > kdb_backtrace(c0ce3e07,547,ffffffff,c0f65a1c,c521389c,...) at kdb_backtra= ce+0x29 > _witness_debugger(c0cc982b,c52138b0,4,1,0,...) at _witness_debugger+0x25 > witness_warn(5,0,c0cffec8,c55810a4,c557f7f8,...) at witness_warn+0x1fd > trap(c521393c) at trap+0x19e > calltrap() at calltrap+0x6 > --- trap 0xc, eip =3D 0xc0a4d340, esp =3D 0xc521397c, ebp =3D 0xc5213b14 = --- > ip6_output(c5a4fc00,c0f964a0,0,1,c5213b44,...) at ip6_output+0x840 > mld_dispatch_packet(0,0,c5213c1c,c0a509a7,c56fca2c,...) at mld_dispatch_p= acket+0x30d > mld_dispatch_queue(c56fca2c,0,c0ce3e07,591,c0cbb984,...) at mld_dispatch_= queue+0x38 > mld_fasttimo(c5213c48,c0904cc9,c5213c48,c0893aa4,c0e24f80,...) at mld_fas= ttimo+0x747 > icmp6_fasttimo(c5213c48,c0893aa4,c0e24f80,4,c0cc24d6,...) at icmp6_fastti= mo+0x8 > pffasttimo(0,0,c0cc5113,189,c0e24fb8,...) at pffasttimo+0x29 > softclock(c0e24f80,c5213cc8,c0893aa4,c0e28940,c5588838,...) at softclock+= 0x24a > intr_event_execute_handlers(c557f7f8,c5588800,c0cbf33f,533,c5588870,...) = at intr_event_execute_handlers+0x125 > ithread_loop(c557e120,c5213d38,c0cbf0b8,343,c557f7f8,...) at ithread_loop= +0x9f > fork_exit(c087c780,c557e120,c5213d38) at fork_exit+0xb8 > fork_trampoline() at fork_trampoline+0x8 > --- trap 0, eip =3D 0, esp =3D 0xc5213d70, ebp =3D 0 --- > > > Fatal trap 12: page fault while in kernel mode > cpuid =3D 0; apic id =3D 00 > fault virtual address =A0 =3D 0x3c > fault code =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D supervisor read, page not prese= nt > instruction pointer =A0 =A0 =3D 0x20:0xc0a4d340 > stack pointer =A0 =A0 =A0 =A0 =A0 =3D 0x28:0xc521397c > frame pointer =A0 =A0 =A0 =A0 =A0 =3D 0x28:0xc5213b14 > code segment =A0 =A0 =A0 =A0 =A0 =A0=3D base 0x0, limit 0xfffff, type 0x1= b > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D DPL 0, pres 1, def32 1= , gran 1 > processor eflags =A0 =A0 =A0 =A0=3D interrupt enabled, resume, IOPL =3D 0 > current process =A0 =A0 =A0 =A0 =3D 12 (swi4: clock) > [ thread pid 12 tid 100007 ] > Stopped at =A0 =A0 =A0ip6_output+0x840: =A0 =A0 =A0 movl =A0 =A00x3c(%eax= ),%eax > db> bt > Tracing pid 12 tid 100007 td 0xc5581000 > ip6_output(c5a4fc00,c0f964a0,0,1,c5213b44,...) at ip6_output+0x840 > mld_dispatch_packet(0,0,c5213c1c,c0a509a7,c56fca2c,...) at mld_dispatch_p= acket+0x30d > mld_dispatch_queue(c56fca2c,0,c0ce3e07,591,c0cbb984,...) at mld_dispatch_= queue+0x38 > mld_fasttimo(c5213c48,c0904cc9,c5213c48,c0893aa4,c0e24f80,...) at mld_fas= ttimo+0x747 > icmp6_fasttimo(c5213c48,c0893aa4,c0e24f80,4,c0cc24d6,...) at icmp6_fastti= mo+0x8 > pffasttimo(0,0,c0cc5113,189,c0e24fb8,...) at pffasttimo+0x29 > softclock(c0e24f80,c5213cc8,c0893aa4,c0e28940,c5588838,...) at softclock+= 0x24a > intr_event_execute_handlers(c557f7f8,c5588800,c0cbf33f,533,c5588870,...) = at intr_event_execute_handlers+0x125 > ithread_loop(c557e120,c5213d38,c0cbf0b8,343,c557f7f8,...) at ithread_loop= +0x9f > fork_exit(c087c780,c557e120,c5213d38) at fork_exit+0xb8 > fork_trampoline() at fork_trampoline+0x8 > --- trap 0, eip =3D 0, esp =3D 0xc5213d70, ebp =3D 0 --- > db> > > > Again, I can poke at it a bit if additional information might be useful. > > On a positive note, when I powered it off earlier, I had (only) > disabled wol_mcast, so I was able to power it back up remotely by > telling my firewall machine to send magic packets to it. =A0:-} > > Peace, > david > -- > David H. Wolfskill =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0david@catwhisker.org > Depriving a girl or boy of an opportunity for education is evil. > > See http://www.catwhisker.org/~david/publickey.gpg for my public key. > From owner-freebsd-current@FreeBSD.ORG Mon May 10 22:52:09 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 99DF5106564A; Mon, 10 May 2010 22:52:09 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from bunrab.catwhisker.org (adsl-63-193-123-122.dsl.snfc21.pacbell.net [63.193.123.122]) by mx1.freebsd.org (Postfix) with ESMTP id CE21E8FC12; Mon, 10 May 2010 22:52:07 +0000 (UTC) Received: from bunrab.catwhisker.org (localhost [127.0.0.1]) by bunrab.catwhisker.org (8.13.3/8.13.3) with ESMTP id o4AMq7Cb098169; Mon, 10 May 2010 15:52:07 -0700 (PDT) (envelope-from david@bunrab.catwhisker.org) Received: (from david@localhost) by bunrab.catwhisker.org (8.13.3/8.13.3/Submit) id o4AMq7VW098168; Mon, 10 May 2010 15:52:07 -0700 (PDT) (envelope-from david) Date: Mon, 10 May 2010 15:52:07 -0700 From: David Wolfskill To: "K. Macy" Message-ID: <20100510225207.GM49209@bunrab.catwhisker.org> Mail-Followup-To: David Wolfskill , "K. Macy" , current@freebsd.org References: <20100510140722.GD49209@bunrab.catwhisker.org> <20100510182243.GV56080@hoeg.nl> <20100510182625.GF49209@bunrab.catwhisker.org> <20100510220854.GK49209@bunrab.catwhisker.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vYDx0ctV5ggqAdB/" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: current@freebsd.org Subject: Re: Panic @r207844; current process: flowcleaner "Fatal trap 12: page fault while in kernel mode" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 22:52:09 -0000 --vYDx0ctV5ggqAdB/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, May 10, 2010 at 03:39:11PM -0700, K. Macy wrote: > Are you not able to dump core? > .... Here's the crash summary; I can put the dump on my Web server on request. (It weighs in at 89MB.) freebeast.catwhisker.org dumped core - see /var/crash/vmcore.0 Mon May 10 15:47:10 PDT 2010 FreeBSD freebeast.catwhisker.org 9.0-CURRENT FreeBSD 9.0-CURRENT #155 r2078= 44M: Mon May 10 14:55:41 PDT 2010 root@freebeast.catwhisker.org:/usr/ob= j/usr/src/sys/GENERIC i386 panic: from debugger 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 condition= s. 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: <118>Starting ypbind. <118>Starting amd. Kernel page fault with the following non-sleepable locks held: exclusive sleep mutex mld_mtx (mld_mtx) r =3D 0 (0xc0f96468) locked @ /usr/= src/sys/netinet6/mld6.c:1352 exclusive sleep mutex in6_multi_mtx (in6_multi_mtx) r =3D 0 (0xc0f95408) lo= cked @ /usr/src/sys/netinet6/mld6.c:1351 KDB: stack backtrace: db_trace_self_wrapper(c0cc72a5,c5213864,c08e9f65,c0ce3e07,547,...) at db_tr= ace_self_wrapper+0x26 kdb_backtrace(c0ce3e07,547,ffffffff,c0f65a1c,c521389c,...) at kdb_backtrace= +0x29 _witness_debugger(c0cc982b,c52138b0,4,1,0,...) at _witness_debugger+0x25 witness_warn(5,0,c0cffec8,c55810a4,c557f7f8,...) at witness_warn+0x1fd trap(c521393c) at trap+0x19e calltrap() at calltrap+0x6 --- trap 0xc, eip =3D 0xc0a4d340, esp =3D 0xc521397c, ebp =3D 0xc5213b14 --- ip6_output(c5a4fc00,c0f964a0,0,1,c5213b44,...) at ip6_output+0x840 mld_dispatch_packet(0,0,c5213c1c,c0a509a7,c56fca2c,...) at mld_dispatch_pac= ket+0x30d mld_dispatch_queue(c56fca2c,0,c0ce3e07,591,c0cbb984,...) at mld_dispatch_qu= eue+0x38 mld_fasttimo(c5213c48,c0904cc9,c5213c48,c0893aa4,c0e24f80,...) at mld_fastt= imo+0x747 icmp6_fasttimo(c5213c48,c0893aa4,c0e24f80,4,c0cc24d6,...) at icmp6_fasttimo= +0x8 pffasttimo(0,0,c0cc5113,189,c0e24fb8,...) at pffasttimo+0x29 softclock(c0e24f80,c5213cc8,c0893aa4,c0e28940,c5588838,...) at softclock+0x= 24a intr_event_execute_handlers(c557f7f8,c5588800,c0cbf33f,533,c5588870,...) at= intr_event_execute_handlers+0x125 ithread_loop(c557e120,c5213d38,c0cbf0b8,343,c557f7f8,...) at ithread_loop+0= x9f fork_exit(c087c780,c557e120,c5213d38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip =3D 0, esp =3D 0xc5213d70, ebp =3D 0 --- Fatal trap 12: page fault while in kernel mode cpuid =3D 0; apic id =3D 00 fault virtual address =3D 0x3c fault code =3D supervisor read, page not present instruction pointer =3D 0x20:0xc0a4d340 stack pointer =3D 0x28:0xc521397c frame pointer =3D 0x28:0xc5213b14 code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, def32 1, gran 1 processor eflags =3D interrupt enabled, resume, IOPL =3D 0 current process =3D 12 (swi4: clock) panic: from debugger cpuid =3D 0 Uptime: 20s Physical memory: 2030 MB Dumping 89 MB: 74 58 42 26 10 #0 doadump () at pcpu.h:246 246 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump () at pcpu.h:246 #1 0xc08a384e in boot (howto=3D260) at /usr/src/sys/kern/kern_shutdown.c:4= 16 #2 0xc08a3b22 in panic (fmt=3DVariable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:590 #3 0xc04d2c97 in db_panic (addr=3DCould not find the frame base for "db_pa= nic". ) at /usr/src/sys/ddb/db_command.c:478 #4 0xc04d32c1 in db_command (last_cmdp=3D0xc0df1d5c, cmd_table=3D0x0, dopa= ger=3D1) at /usr/src/sys/ddb/db_command.c:445 #5 0xc04d341a in db_command_loop () at /usr/src/sys/ddb/db_command.c:498 #6 0xc04d52bd in db_trap (type=3D12, code=3D0) at /usr/src/sys/ddb/db_main= .c:229 #7 0xc08d5ee6 in kdb_trap (type=3D12, code=3D0, tf=3D0xc521393c) at /usr/src/sys/kern/subr_kdb.c:535 #8 0xc0be703f in trap_fatal (frame=3D0xc521393c, eva=3D60) at /usr/src/sys/i386/i386/trap.c:931 #9 0xc0be78ac in trap (frame=3D0xc521393c) at /usr/src/sys/i386/i386/trap.= c:328 #10 0xc0bc8ecb in calltrap () at /usr/src/sys/i386/i386/exception.s:165 #11 0xc0a4d340 in ip6_output (m0=3D0xc5a4fc00, opt=3D0xc0f964a0, ro=3D0xc52= 13a68,=20 flags=3D1, im6o=3D0xc5213b44, ifpp=3D0xc5213b64, inp=3D0x0) at /usr/src/sys/netinet6/ip6_output.c:600 #12 0xc0a4ec3d in mld_dispatch_packet (m=3D0xc5a4fd00) at /usr/src/sys/netinet6/mld6.c:3119 #13 0xc0a4efe8 in mld_dispatch_queue (ifq=3D0xc5213be8, limit=3D0) at /usr/src/sys/netinet6/mld6.c:417 #14 0xc0a509a7 in mld_fasttimo () at /usr/src/sys/netinet6/mld6.c:1431 #15 0xc0a34158 in icmp6_fasttimo () at /usr/src/sys/netinet6/icmp6.c:2240 #16 0xc0904cc9 in pffasttimo (arg=3D0x0) at /usr/src/sys/kern/uipc_domain.c= :531 #17 0xc08b6bda in softclock (arg=3D0xc0e24f80) at /usr/src/sys/kern/kern_timeout.c:430 #18 0xc087ba45 in intr_event_execute_handlers (p=3D0xc557f7f8, ie=3D0xc5588= 800) at /usr/src/sys/kern/kern_intr.c:1220 #19 0xc087c81f in ithread_loop (arg=3D0xc557e120) at /usr/src/sys/kern/kern_intr.c:1233 #20 0xc0879798 in fork_exit (callout=3D0xc087c780 ,=20 arg=3D0xc557e120, frame=3D0xc5213d38) at /usr/src/sys/kern/kern_fork.c:= 843 #21 0xc0bc8f40 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:= 270 (kgdb)=20 ------------------------------------------------------------------------ ps -axl UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMA= ND 0 0 0 0 -16 0 0 0 deadlk DLs ?? 6689708:24.00 [= kernel] 0 1 0 0 76 0 8032 0 wait DLs ?? 7839166:30.00 [= init] 0 2 0 0 -8 0 0 0 - DL ?? 1613170:30.00 [= g_event] 0 3 0 0 -8 0 0 0 - DL ?? 806945:51.00 [g= _up] 0 4 0 0 -8 0 0 0 - DL ?? 890180:42.00 [g= _down] 0 5 0 0 -16 0 0 0 aifthd DL ?? 0:00.00 [aac0= aif] 0 6 0 0 -16 0 0 0 - DL ?? 4397:15.00 [fdc= 0] 0 7 0 0 76 0 0 0 ccb_sc DL ?? 0:00.00 [xpt_= thrd 0 8 0 0 76 0 0 0 psleep DL ?? 8770:39.00 [pag= edaem 0 9 0 0 76 0 0 0 psleep DL ?? 238:03.00 [vmda= emon 0 10 0 0 -16 0 0 0 audit_ DL ?? 0:00.00 [audi= t] 0 11 0 0 171 0 0 0 - RL ?? -17871428:-11.5= 5 [idle] 0 12 0 0 -48 0 0 0 - WL ?? 5797222:57.00 [= intr] 0 13 0 0 -16 0 0 0 - DL ?? 138261:00.00 [y= arrow] 0 14 0 0 -64 0 0 0 - DL ?? 13587:54.00 [us= b] 0 15 0 0 76 0 0 0 pgzero DL ?? 357:36.00 [page= zero 0 16 0 0 76 0 0 0 psleep DL ?? 5494:21.00 [buf= daemo 0 17 0 0 76 0 0 0 syncer DL ?? 12605:51.00 [sy= ncer] 0 18 0 0 76 0 0 0 vlruwt DL ?? 4270:03.00 [vnl= ru] 0 19 0 0 76 0 0 0 sdflus DL ?? 104670:27.00 [s= oftdepf 0 20 0 0 76 0 0 0 flowcl DL ?? 3432:27.00 [flo= wclea 0 21 1 0 76 0 9800 0 wait Ds+ ?? 3872524:03.00 [= sh] 0 660 1 0 76 0 8032 0 select Ds ?? 57910:21.00 [de= vd] 0 857 1 0 76 0 9528 0 select Ds ?? 767461:39.00 [s= yslogd] 0 881 1 0 76 0 9688 0 select Ds ?? 466142:42.00 [r= pcbind] 0 908 1 0 76 0 9460 0 select Ds ?? 295696:21.00 [y= pbind] 0 915 21 0 76 0 9800 0 wait D+ ?? 313004:15.00 [s= h] 0 921 915 0 76 0 328 0 vnread D+ ?? 0:00.00 [sh] ------------------------------------------------------------------------ vmstat -s 41366 cpu context switches 4837 device interrupts 3046 software interrupts 70181 traps 104641 system calls 20 kernel threads created 879 fork() calls 22 vfork() calls 0 rfork() calls 0 swap pager pageins 0 swap pager pages paged in 0 swap pager pageouts 0 swap pager pages paged out 145 vnode pager pageins 843 vnode pager pages paged in 0 vnode pager pageouts 0 vnode pager pages paged out 0 page daemon wakeups 0 pages examined by the page daemon 28 pages reactivated 24192 copy-on-write faults 19 copy-on-write optimized faults 28560 zero fill pages zeroed 1048 zero fill pages prezeroed 2 intransit blocking page faults 69993 total VM faults taken 0 pages affected by kernel thread creation 839931 pages affected by fork() 21560 pages affected by vfork() 0 pages affected by rfork() 0 pages cached 64820 pages freed 0 pages freed by daemon 0 pages freed by exiting processes 560 pages active 777 pages inactive 0 pages in VM cache 8298 pages wired down 500911 pages free 4096 bytes per page 9658 total name lookups cache hits (84% pos + 8% neg) system 0% per-directory deletions 0%, falsehits 0%, toolong 0% ------------------------------------------------------------------------ vmstat -m Type InUse MemUse HighUse Requests Size(s) cdev 10 2K - 10 128 pci_link 16 2K - 16 32,64,128 sigio 1 1K - 1 32 filedesc 28 7K - 922 256 kenv 79 7K - 83 16,32,64,128,4096 proc-args 6 1K - 259 32,64,128 ithread 125 12K - 125 16,64,128 SCSI SES 1 2K - 1 2048 KTRACE 100 13K - 100 128 linker 113 4K - 115 16,32,512 lockf 17 1K - 17 32,64 ip6ndp 5 1K - 6 64,128 temp 22 229K - 5555 16,32,64,128,256,512,1024,2048= ,4096 devbuf 3945 3999K - 3991 16,32,64,128,256,512,1024,2048= ,4096 module 457 29K - 457 64,128 entropy 1024 64K - 1024 64 mtx_pool 2 8K - 2 4096 subproc 101 131K - 995 256,4096 proc 2 8K - 2 4096 session 6 1K - 6 64 pgrp 6 1K - 6 64 cred 28 3K - 1832 64,128 uidinfo 2 2K - 2 64,1024 plimit 2 1K - 36 256 sysctltmp 0 0K - 212 16,32,64,128,4096 sysctloid 3114 95K - 3250 16,32,64,128 sysctl 0 0K - 456 16,32,64 callout 1 256K - 1 =20 umtx 264 25K - 264 64,128 p1003.1b 1 1K - 1 16 SWAP 4 4377K - 4 64 bus-sc 63 194K - 2974 16,32,64,128,256,512,1024,2048= ,4096 bus 1112 51K - 5655 16,32,64,128,256,512,1024 devstat 14 29K - 14 16,4096 eventhandler 81 4K - 81 32,64,128 kobj 330 660K - 391 2048 Per-cpu 1 1K - 1 16 UART 6 3K - 6 16,256,1024 ddb_capture 1 48K - 1 =20 rman 195 12K - 693 16,32,64 aacbuf 261 41K - 261 32,128 sbuf 0 0K - 1198 16,32,64,128,256,512,1024,2048= ,4096 stack 0 0K - 2 128 taskqueue 15 1K - 15 16,64 Unitno 11 1K - 55 16,64 acpica 1370 68K - 66145 16,32,64,128,256,512,1024 acpitask 1 1K - 1 1024 Witness 1 104K - 1 =20 iov 0 0K - 305 16,64,128,256 select 6 1K - 6 64 ioctlops 0 0K - 520 16,32,64,128,512,1024 msg 4 25K - 4 1024,4096 sem 4 6K - 4 256,512,1024,4096 shm 1 12K - 1 =20 tty 21 11K - 23 512,2048 mbuf_tag 0 0K - 13 32,64 ksem 1 4K - 1 4096 shmfd 1 4K - 1 4096 pcb 19 79K - 26 16,64,512,1024,2048,4096 soname 4 1K - 123 16,32,128 vfscache 1 512K - 1 =20 vfs_hash 1 256K - 1 =20 vnodes 2 1K - 2 128 USBdev 20 6K - 20 32,128,1024 vnodemarker 0 0K - 33 512 mount 188 7K - 232 16,32,64,128,256 BPF 3 1K - 3 64 ether_multi 40 2K - 46 16,32,64 ifaddr 43 9K - 43 16,32,64,128,256,512,2048 ifnet 4 4K - 4 64,1024 USB 35 6K - 35 16,32,64,1024 clone 6 24K - 6 4096 arpcom 2 1K - 2 16 lltable 15 4K - 15 128,256 CAM XPT 44 14K - 415 16,32,64,256,1024,2048 acpisem 18 3K - 18 64,128 CAM dev queue 3 1K - 3 128 routetbl 101 8212K - 178 16,32,64,128,256 igmp 3 1K - 3 128 CAM queue 19 1K - 589 16,32 kbdmux 6 18K - 6 16,256,1024,2048 LED 2 1K - 2 64 in_multi 2 1K - 2 128 sctp_iter 0 0K - 3 128 sctp_ifn 2 1K - 2 128 sctp_ifa 5 1K - 5 128 sctp_vrf 1 1K - 1 64 sctp_a_it 0 0K - 3 16 hostcache 1 16K - 1 =20 syncache 1 72K - 1 =20 DEVFS1 117 30K - 139 256 ip6_moptions 2 1K - 2 32,128 in6_multi 22 3K - 22 16,256 in6_mfilter 1 1K - 1 512 DEVFS3 134 17K - 157 128 mld 3 1K - 3 128 NFS FHA 1 1K - 1 1024 rpc 2 5K - 2 128,4096 audit_evclass 172 3K - 211 16 sbdep 0 0K - 1 32 freework 0 0K - 7 64 dirrem 1 1K - 17 64 diradd 13 1K - 18 64 freefile 0 0K - 14 32 freeblks 0 0K - 7 64 freefrag 0 0K - 1 64 newblk 6 65K - 14 128 bmsafemap 5 5K - 7 128,4096 inodedep 17 260K - 35 256 pagedep 5 65K - 6 128 ufs_dirhash 27 5K - 27 16,32,64,512 ufs_mount 33 77K - 33 256,2048,4096 DEVFS 17 1K - 18 16,64 vm_pgdata 3 65K - 3 64 atkbddev 2 1K - 2 32 pfs_nodes 21 3K - 21 128 CAM SIM 3 1K - 3 128 apmdev 1 1K - 1 64 GEOM 193 58K - 1321 16,32,64,128,512,1024,2048 ata_generic 1 1K - 1 1024 io_apic 3 3K - 3 1024 memdesc 1 4K - 1 4096 nexusdev 4 1K - 4 16 acd_driver 1 2K - 1 2048 isadev 5 1K - 5 64 CAM periph 8 1K - 83 16,32,64,128 acpidev 62 2K - 62 32 ------------------------------------------------------------------------ vmstat -z ITEM SIZE LIMIT USED FREE REQUESTS FAIL= URES UMA Kegs: 128, 0, 88, 2, 88, = 0 UMA Zones: 888, 0, 88, 0, 88, = 0 UMA Slabs: 284, 0, 844, 10, 1790, = 0 UMA RCntSlabs: 544, 0, 195, 1, 195, = 0 UMA Hash: 128, 0, 4, 26, 4, = 0 16 Bucket: 76, 0, 42, 8, 63, = 0 32 Bucket: 140, 0, 35, 21, 56, = 0 64 Bucket: 268, 0, 34, 8, 80, = 13 128 Bucket: 524, 0, 44, 5, 1078, = 112 VM OBJECT: 136, 0, 495, 114, 10183, = 0 MAP: 140, 0, 7, 21, 7, = 0 KMAP ENTRY: 72, 57505, 34, 231, 4441, = 0 MAP ENTRY: 72, 0, 82, 236, 18673, = 0 DP fakepg: 72, 0, 0, 0, 0, = 0 SG fakepg: 72, 0, 0, 0, 0, = 0 mt_zone: 2056, 0, 282, 0, 282, = 0 16: 16, 0, 2744, 504, 36762, = 0 32: 32, 0, 2696, 242, 38485, = 0 64: 64, 0, 4416, 304, 6716, = 0 128: 128, 0, 2538, 222, 6347, = 0 256: 256, 0, 584, 61, 2556, = 0 512: 512, 0, 55, 41, 1903, = 0 1024: 1024, 0, 42, 154, 1121, = 0 2048: 2048, 0, 359, 41, 642, = 0 4096: 4096, 0, 397, 53, 6095, = 0 Files: 56, 0, 42, 226, 3377, = 0 TURNSTILE: 72, 0, 133, 47, 133, = 0 umtx pi: 52, 0, 0, 0, 0, = 0 MAC labels: 20, 0, 0, 0, 0, = 0 PROC: 680, 0, 27, 45, 921, = 0 THREAD: 624, 0, 112, 20, 112, = 0 SLEEPQUEUE: 48, 0, 133, 103, 133, = 0 VMSPACE: 240, 0, 8, 72, 903, = 0 cpuset: 40, 0, 2, 182, 2, = 0 audit_record: 816, 0, 0, 0, 0, = 0 mbuf_packet: 256, 0, 256, 133, 537, = 0 mbuf: 256, 0, 6, 255, 74, = 0 mbuf_cluster: 2048, 25600, 384, 6, 384, = 0 mbuf_jumbo_page: 4096, 12800, 0, 0, 0, = 0 mbuf_jumbo_9k: 9216, 19200, 0, 0, 0, = 0 mbuf_jumbo_16k: 16384, 12800, 0, 0, 0, = 0 mbuf_ext_refcnt: 4, 0, 0, 0, 0, = 0 ttyinq: 152, 0, 15, 37, 15, = 0 ttyoutq: 256, 0, 8, 22, 8, = 0 g_bio: 140, 0, 4, 108, 4426, = 0 ata_request: 208, 0, 0, 38, 18, = 0 ata_composite: 180, 0, 0, 0, 0, = 0 VNODE: 272, 0, 383, 23, 398, = 0 VNODEPOLL: 60, 0, 0, 0, 0, = 0 S VFS Cache: 72, 0, 350, 74, 628, = 0 L VFS Cache: 292, 0, 0, 0, 0, = 0 NAMEI: 1024, 0, 1, 35, 4632, = 0 NFSMOUNT: 524, 0, 0, 0, 0, = 0 NFSNODE: 468, 0, 0, 0, 0, = 0 DIRHASH: 1024, 0, 25, 11, 25, = 0 pipe: 392, 0, 0, 40, 621, = 0 ksiginfo: 80, 0, 54, 1002, 55, = 0 itimer: 220, 0, 0, 0, 0, = 0 KNOTE: 72, 0, 0, 0, 0, = 0 socket: 412, 25605, 15, 21, 200, = 0 unpcb: 172, 25622, 4, 65, 21, = 0 ipq: 32, 904, 0, 0, 0, = 0 udp_inpcb: 220, 25614, 8, 46, 171, = 0 udpcb: 8, 25781, 8, 398, 171, = 0 tcp_inpcb: 220, 25614, 3, 51, 3, = 0 tcpcb: 632, 25602, 3, 15, 3, = 0 tcptw: 52, 5184, 0, 0, 0, = 0 syncache: 112, 15365, 0, 0, 0, = 0 hostcache: 76, 15400, 0, 0, 0, = 0 tcpreass: 20, 1690, 0, 0, 0, = 0 sackhole: 20, 0, 0, 0, 0, = 0 sctp_ep: 860, 25600, 0, 0, 0, = 0 sctp_asoc: 1484, 40000, 0, 0, 0, = 0 sctp_laddr: 24, 80040, 0, 290, 4, = 0 sctp_raddr: 432, 80001, 0, 0, 0, = 0 sctp_chunk: 92, 400008, 0, 0, 0, = 0 sctp_readq: 76, 400000, 0, 0, 0, = 0 sctp_stream_msg_out: 64, 400020, 0, 0, 0, = 0 sctp_asconf: 24, 400055, 0, 0, 0, = 0 sctp_asconf_ack: 24, 400055, 0, 0, 0, = 0 ripcb: 220, 25614, 0, 0, 0, = 0 rtentry: 108, 0, 17, 91, 17, = 0 selfd: 28, 0, 21, 360, 390, = 0 ip4flow: 40, 50232, 8, 268, 8, = 0 ip6flow: 64, 50228, 0, 0, 0, = 0 Mountpoints: 648, 0, 12, 12, 12, = 0 FFS inode: 116, 0, 350, 46, 364, = 0 FFS1 dinode: 128, 0, 0, 0, 0, = 0 FFS2 dinode: 256, 0, 350, 40, 364, = 0 SWAPMETA: 276, 121576, 0, 0, 0, = 0 ------------------------------------------------------------------------ vmstat -i interrupt total rate irq1: atkbd0 6 0 irq4: uart0 2305 67 irq6: fdc0 6 0 irq15: ata1 35 1 irq16: uhci0 uhci3 1235 36 irq24: aac0 1221 35 irq54: em0 29 0 cpu0: timer 31220 918 cpu1: timer 25893 761 Total 61950 1822 ------------------------------------------------------------------------ pstat -T 42/12328 files 0M/20479M swap space ------------------------------------------------------------------------ pstat -s Device 512-blocks Used Avail Capacity /dev/aacd0s4b 20971264 0 20971264 0% /dev/aacd1s1b 20971264 0 20971264 0% Total 41942528 0 41942528 0% ------------------------------------------------------------------------ iostat iostat: kvm_read(_tk_nin): invalid address (0x0) iostat: disabling TTY statistics iostat: kvm_getcptime: invalid address (0x0) iostat: disabling CPU time statistics aacd0 aacd1 pass0=20 KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s=20 8.70 29 0.25 4.49 4 0.02 0.00 0 0.00=20 ------------------------------------------------------------------------ ipcs -a Message Queues: T ID KEY MODE OWNER GROUP CREATOR CGROUP = CBYTES QNUM QBYTES LSPI= D LRPID STIME RTIME CTIME =20 Shared Memory: T ID KEY MODE OWNER GROUP CREATOR CGROUP = NATTCH SEGSZ CPID LPID ATIME DTIME CTIM= E =20 Semaphores: T ID KEY MODE OWNER GROUP CREATOR CGROUP = NSEMS OTIME CTIME =20 ------------------------------------------------------------------------ ipcs -T msginfo: msgmax: 16384 (max characters in a message) msgmni: 40 (# of message queues) msgmnb: 2048 (max characters in a message queue) msgtql: 40 (max # of messages in system) msgssz: 8 (size of a message segment) msgseg: 2048 (# of message segments in system) shminfo: shmmax: 33554432 (max shared memory segment size) shmmin: 1 (min shared memory segment size) shmmni: 192 (max number of shared memory identifiers) shmseg: 128 (max shared memory segments per process) shmall: 8192 (max amount of shared memory in pages) seminfo: semmap: 30 (# of entries in semaphore map) semmni: 10 (# of semaphore identifiers) semmns: 60 (# of semaphores in system) semmnu: 30 (# of undo structures in system) semmsl: 60 (max # of semaphores per id) semopm: 100 (max # of operations per semop call) semume: 10 (max # of undo entries per process) semusz: 136 (size in bytes of undo structure) semvmx: 32767 (semaphore maximum value) semaem: 16384 (adjust on exit max value) ------------------------------------------------------------------------ nfsstat Client Info: Rpc Counts: Getattr Setattr Lookup Readlink Read Write Create Re= move 0 0 0 0 0 0 0 = 0 Rename Link Symlink Mkdir Rmdir Readdir RdirPlus Ac= cess 0 0 0 0 0 0 0 = 0 Mknod Fsstat Fsinfo PathConf Commit 0 0 0 0 0 Rpc Info: TimedOut Invalid X Replies Retries Requests 0 0 0 0 0 Cache Info: Attr Hits Misses Lkup Hits Misses BioR Hits Misses BioW Hits Mi= sses 0 0 0 0 0 0 0 = 0 BioRLHits Misses BioD Hits Misses DirE Hits Misses 0 0 0 0 0 0 Server Info: Getattr Setattr Lookup Readlink Read Write Create Re= move 0 0 0 0 0 0 0 = 0 Rename Link Symlink Mkdir Rmdir Readdir RdirPlus Ac= cess 0 0 0 0 0 0 0 = 0 Mknod Fsstat Fsinfo PathConf Commit 0 0 0 0 0 Server Ret-Failed 0 Server Faults 0 Server Cache Stats: Inprog Idem Non-idem Misses 0 0 0 0 Server Write Gathering: WriteOps WriteRPC Opsaved 0 0 0 ------------------------------------------------------------------------ netstat -s tcp: 0 packets sent 0 data packets (0 bytes) 0 data packets (0 bytes) retransmitted 0 data packets unnecessarily retransmitted 0 resends initiated by MTU discovery 0 ack-only packets (0 delayed) 0 URG only packets 0 window probe packets 0 window update packets 0 control packets 0 packets received 0 acks (for 0 bytes) 0 duplicate acks 0 acks for unsent data 0 packets (0 bytes) received in-sequence 0 completely duplicate packets (0 bytes) 0 old duplicate packets 0 packets with some dup. data (0 bytes duped) 0 out-of-order packets (0 bytes) 0 packets (0 bytes) of data after window 0 window probes 0 window update packets 0 packets received after close 0 discarded for bad checksums 0 discarded for bad header offset fields 0 discarded because packet too short 0 discarded due to memory problems 0 connection requests 0 connection accepts 0 bad connection attempts 0 listen queue overflows 0 ignored RSTs in the windows 0 connections established (including accepts) 0 connections closed (including 0 drops) 0 connections updated cached RTT on close 0 connections updated cached RTT variance on close 0 connections updated cached ssthresh on close 0 embryonic connections dropped 0 segments updated rtt (of 0 attempts) 0 retransmit timeouts 0 connections dropped by rexmit timeout 0 persist timeouts 0 connections dropped by persist timeout 0 Connections (fin_wait_2) dropped because of timeout 0 keepalive timeouts 0 keepalive probes sent 0 connections dropped by keepalive 0 correct ACK header predictions 0 correct data packet header predictions 0 syncache entries added 0 retransmitted 0 dupsyn 0 dropped 0 completed 0 bucket overflow 0 cache overflow 0 reset 0 stale 0 aborted 0 badack 0 unreach 0 zone failures 0 cookies sent 0 cookies received 0 SACK recovery episodes 0 segment rexmits in SACK recovery episodes 0 byte rexmits in SACK recovery episodes 0 SACK options (SACK blocks) received 0 SACK options (SACK blocks) sent 0 SACK scoreboard overflow 0 packets with ECN CE bit set 0 packets with ECN ECT(0) bit set 0 packets with ECN ECT(1) bit set 0 successful ECN handshakes 0 times ECN reduced the congestion window udp: 12 datagrams received 0 with incomplete header 0 with bad data length field 0 with bad checksum 0 with no checksum 3 dropped due to no socket 0 broadcast/multicast datagrams undelivered 0 dropped due to full socket buffers 0 not for hashed pcb 9 delivered 7 datagrams output 0 times multicast source filter matched ip: 8 total packets received 0 bad header checksums 0 with size smaller than minimum 0 with data size < data length 0 with ip length > max ip packet size 0 with header length < data size 0 with data length < header length 0 with bad options 0 with incorrect version number 0 fragments received 0 fragments dropped (dup or out of space) 0 fragments dropped after timeout 0 packets reassembled ok 8 packets for this host 0 packets for unknown/unsupported protocol 0 packets forwarded (0 packets fast forwarded) 0 packets not forwardable 0 packets received for unknown multicast group 0 redirects sent 5 packets sent from this host 0 packets sent with fabricated ip header 0 output packets dropped due to no bufs, etc. 0 output packets discarded due to no route 0 output datagrams fragmented 0 fragments created 0 datagrams that can't be fragmented 0 tunneling packets that can't find gif 0 datagrams with bad address in header icmp: 3 calls to icmp_error 0 errors not generated in response to an icmp message Output histogram: destination unreachable: 3 0 messages with bad code fields 0 messages less than the minimum length 0 messages with bad checksum 0 messages with bad length 0 multicast echo requests ignored 0 multicast timestamp requests ignored 0 message responses generated 0 invalid return addresses 0 no return routes igmp: 0 messages received 0 messages received with too few bytes 0 messages received with wrong TTL 0 messages received with bad checksum 0 V1/V2 membership queries received 0 V3 membership queries received 0 membership queries received with invalid field(s) 0 general queries received 0 group queries received 0 group-source queries received 0 group-source queries dropped 0 membership reports received 0 membership reports received with invalid field(s) 0 membership reports received for groups to which we belong 0 V3 reports received without Router Alert 0 membership reports sent arp: 3 ARP requests sent 0 ARP replies sent 12 ARP requests received 2 ARP replies received 14 ARP packets received 0 total packets dropped due to no ARP entry 0 ARP entrys timed out 0 Duplicate IPs seen ip6: 4 total packets received 0 with size smaller than minimum 0 with data size < data length 0 with bad options 0 with incorrect version number 0 fragments received 0 fragments dropped (dup or out of space) 0 fragments dropped after timeout 0 fragments that exceeded limit 0 packets reassembled ok 4 packets for this host 0 packets forwarded 0 packets not forwardable 0 redirects sent 11 packets sent from this host 0 packets sent with fabricated ip header 0 output packets dropped due to no bufs, etc. 0 output packets discarded due to no route 0 output datagrams fragmented 0 fragments created 0 datagrams that can't be fragmented 0 packets that violated scope rules 0 multicast packets which we don't join Input histogram: UDP: 4 Mbuf statistics: 5 one mbuf 0 one ext mbuf 0 two or more ext mbuf 0 packets whose headers are not continuous 0 tunneling packets that can't find gif 0 packets discarded because of too many headers 0 failures of source address selection Source addresses selection rule applied: 5 first candidate 4 matching label icmp6: 0 calls to icmp6_error 0 errors not generated in response to an icmp6 message 0 errors not generated because of rate limitation Output histogram: neighbor solicitation: 1 0 messages with bad code fields 0 messages < minimum length 0 bad checksums 0 messages with bad length Histogram of error messages to be generated: 0 no route 0 administratively prohibited 0 beyond scope 0 address unreachable 0 port unreachable 0 packet too big 0 time exceed transit 0 time exceed reassembly 0 erroneous header field 0 unrecognized next header 0 unrecognized option 0 redirect 0 unknown 0 message responses generated 0 messages with too many ND options 0 messages with bad ND options 0 bad neighbor solicitation messages 0 bad neighbor advertisement messages 0 bad router solicitation messages 0 bad router advertisement messages 0 bad redirect messages 0 path MTU changes rip6: 0 messages received 0 checksum calculations on inbound 0 messages with bad checksum 0 messages dropped due to no socket 0 multicast messages dropped due to no socket 0 messages dropped due to full socket buffers 0 delivered 0 datagrams output ------------------------------------------------------------------------ netstat -m 262/388/650 mbufs in use (current/cache/total) 251/139/390/25600 mbuf clusters in use (current/cache/total/max) 256/133 mbuf+clusters out of packet secondary zone in use (current/cache) 0/0/0/12800 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/19200 9k jumbo clusters in use (current/cache/total/max) 0/0/0/12800 16k jumbo clusters in use (current/cache/total/max) 567K/375K/942K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile 0 calls to protocol drain routines ------------------------------------------------------------------------ netstat -id Name Mtu Network Address Ipkts Ierrs Idrop Opkts O= errs Coll Drop em0 1500 00:30:48:2d:32:6a 23 0 0 8 = 0 0 0=20 em0 1500 172.16.8.0 freebeast 8 - - 5 = - - -=20 em0 1500 fe80:1::230:4 fe80:1::230:48ff: 0 - - 1 = - - -=20 em1* 1500 00:30:48:2d:32:6b 0 0 0 0 = 0 0 0=20 lo0 16384 4 0 0 0 = 0 0 0=20 lo0 16384 your-net localhost 0 - - 0 = - - -=20 lo0 16384 localhost ::1 0 - - 0 = - - -=20 lo0 16384 fe80:3::1 fe80:3::1 0 - - 0 = - - -=20 ------------------------------------------------------------------------ netstat -anr Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 172.16.8.1 UGS 0 0 em0 127.0.0.1 link#3 UH 0 0 lo0 172.16.8.0/24 link#1 U 4 5 em0 172.16.8.10 link#1 UHS 0 0 lo0 Internet6: Destination Gateway Flags = Netif Expire ::/96 ::1 UGRS = lo0 ::1 ::1 UH = lo0 ::ffff:0.0.0.0/96 ::1 UGRS = lo0 fe80::/10 ::1 UGRS = lo0 fe80::%em0/64 link#1 U = em0 fe80::230:48ff:fe2d:326a%em0 link#1 UHS = lo0 fe80::%lo0/64 link#3 U = lo0 fe80::1%lo0 link#3 UHS = lo0 ff01:1::/32 fe80::230:48ff:fe2d:326a%em0 U = em0 ff01:3::/32 ::1 U = lo0 ff02::/16 ::1 UGRS = lo0 ff02::%em0/32 fe80::230:48ff:fe2d:326a%em0 U = em0 ff02::%lo0/32 ::1 U = lo0 ------------------------------------------------------------------------ netstat -anA Active Internet connections (including servers) Tcpcb Proto Recv-Q Send-Q Local Address Foreign Address (state) c69b94f0 tcp4 0 0 *.925 *.* LISTEN c69b2c58 tcp4 0 0 *.111 *.* LISTEN c69b3000 tcp6 0 0 *.111 *.* LISTEN c686c528 udp4 0 0 *.907 *.* =20 c686b7bc udp6 0 0 *.* *.* =20 c686b000 udp4 0 0 *.832 *.* =20 c686b1b8 udp4 0 0 *.111 *.* =20 c686b294 udp6 0 0 *.736 *.* =20 c686b44c udp6 0 0 *.111 *.* =20 c686b604 udp4 0 0 *.514 *.* =20 c686b528 udp6 0 0 *.514 *.* =20 Active UNIX domain sockets Address Type Recv-Q Send-Q Inode Conn Refs Nextref Addr c6942ac0 stream 0 0 c69af440 0 0 0 /var/run/= rpcbind.sock c6942d70 stream 0 0 c6944660 0 0 0 /var/run/= devd.pipe c6943e1c dgram 0 0 c69ac440 0 0 0 /var/run/= logpriv c6943ec8 dgram 0 0 c6861880 0 0 0 /var/run/= log ------------------------------------------------------------------------ netstat -aL Current listen queue sizes (qlen/incqlen/maxqlen) Proto Listen Local Address =20 tcp4 0/0/128 *.925 =20 tcp4 0/0/128 *.sunrpc =20 tcp6 0/0/128 *.sunrpc =20 unix 0/0/128 /var/run/rpcbind.sock unix 0/0/4 /var/run/devd.pipe ------------------------------------------------------------------------ fstat USER CMD PID FD MOUNT INUM MODE SZ|DV R/W root sh 921 root / 2 drwxr-xr-x 1024 r root sh 921 wd / 2 drwxr-xr-x 1024 r root sh 921 text / 119072 -r-xr-xr-x 120188 r root sh 921 0 /dev 5 crw------- console rw root sh 921 1 /var 494633 -rw-r--r-- 0 w root sh 921 2 /dev 25 crw-rw-rw- null w root sh 915 root / 2 drwxr-xr-x 1024 r root sh 915 wd / 2 drwxr-xr-x 1024 r root sh 915 text / 119072 -r-xr-xr-x 120188 r root sh 915 0 /dev 5 crw------- console rw root sh 915 1 /dev 5 crw------- console rw root sh 915 2 /dev 5 crw------- console rw root sh 915 10 / 47279 -r-xr-xr-x 972 r root ypbind 908 root / 2 drwxr-xr-x 1024 r root ypbind 908 wd / 2 drwxr-xr-x 1024 r root ypbind 908 text /usr 286756 -r-xr-xr-x 16276 r root ypbind 908 0 /dev 25 crw-rw-rw- null rw root ypbind 908 1 /dev 25 crw-rw-rw- null rw root ypbind 908 2 /dev 25 crw-rw-rw- null rw root ypbind 908 3 /var 494632 -r--r--r-- 0 r root ypbind 908 4* internet dgram udp c686c528 root ypbind 908 5* internet stream tcp c69b94f0 root ypbind 908 6 /var 94209 -rw-r--r-- 14 rw root rpcbind 881 root / 2 drwxr-xr-x 1024 r root rpcbind 881 wd / 2 drwxr-xr-x 1024 r root rpcbind 881 text /usr 285496 -r-xr-xr-x 39500 r root rpcbind 881 0 /dev 25 crw-rw-rw- null rw root rpcbind 881 1 /dev 25 crw-rw-rw- null rw root rpcbind 881 2 /dev 25 crw-rw-rw- null rw root rpcbind 881 3 /var 494629 -r--r--r-- 0 r root rpcbind 881 4* internet6 dgram udp c686b7bc root rpcbind 881 5* local stream c6942ac0 root rpcbind 881 6* internet6 dgram udp c686b44c root rpcbind 881 7* internet6 dgram udp c686b294 root rpcbind 881 8* internet6 stream tcp c69b3000 root rpcbind 881 9* internet dgram udp c686b1b8 root rpcbind 881 10* internet dgram udp c686b000 root rpcbind 881 11* internet stream tcp c69b2c58 root syslogd 857 root / 2 drwxr-xr-x 1024 r root syslogd 857 wd / 2 drwxr-xr-x 1024 r root syslogd 857 text /usr 286269 -r-xr-xr-x 35860 r root syslogd 857 0 /dev 25 crw-rw-rw- null rw root syslogd 857 1 /dev 25 crw-rw-rw- null rw root syslogd 857 2 /dev 25 crw-rw-rw- null rw root syslogd 857 3 /var 494624 -rw------- 3 w root syslogd 857 4* local dgram c6943ec8 root syslogd 857 5* local dgram c6943e1c root syslogd 857 6* internet6 dgram udp c686b528 root syslogd 857 7* internet dgram udp c686b604 root syslogd 857 8 /dev 28 crw------- klog r root syslogd 857 10 /dev 5 crw------- console w root syslogd 857 11 /var 141316 -rw-r--r-- 103943 w root syslogd 857 12 /var 141323 -rw------- 55 w root syslogd 857 13 /var 141317 -rw------- 81022 w root syslogd 857 14 /var 141315 -rw-r----- 3264 w root syslogd 857 15 /var 141319 -rw-r--r-- 64145 w root syslogd 857 16 /var 141325 -rw------- 55 w root syslogd 857 17 /var 141320 -rw------- 26693 w root syslogd 857 18 /var 141318 -rw------- 55 w root syslogd 857 19 /var 141322 -rw-r----- 55 w root devd 660 root / 2 drwxr-xr-x 1024 r root devd 660 wd / 2 drwxr-xr-x 1024 r root devd 660 text / 75 -r-xr-xr-x 400520 r root devd 660 0 /dev 25 crw-rw-rw- null rw root devd 660 1 /dev 25 crw-rw-rw- null rw root devd 660 2 /dev 25 crw-rw-rw- null rw root devd 660 3 / 23572 drwxr-xr-x 512 r root devd 660 4 /dev 4 crw------- devctl r root devd 660 5* local stream c6942d70 root devd 660 6 /var 494620 -rw------- 3 w root sh 21 root / 2 drwxr-xr-x 1024 r root sh 21 wd / 2 drwxr-xr-x 1024 r root sh 21 text / 119072 -r-xr-xr-x 120188 r root sh 21 0 /dev 5 crw------- console rw root sh 21 1 /dev 5 crw------- console rw root sh 21 2 /dev 5 crw------- console rw root sh 21 10 / 23873 -rw-r--r-- 3710 r root init 1 root / 2 drwxr-xr-x 1024 r root init 1 wd / 2 drwxr-xr-x 1024 r root init 1 text / 91 -r-xr-xr-x 677768 r root kernel 0 root / 2 drwxr-xr-x 1024 r root kernel 0 wd / 2 drwxr-xr-x 1024 r ------------------------------------------------------------------------ dmesg Copyright (c) 1992-2010 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 9.0-CURRENT #155 r207844M: Mon May 10 14:55:41 PDT 2010 root@freebeast.catwhisker.org:/usr/obj/usr/src/sys/GENERIC i386 WARNING: WITNESS option enabled, expect reduced performance. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(TM) CPU 3.60GHz (3610.95-MHz 686-class CPU) Origin =3D "GenuineIntel" Id =3D 0xf41 Family =3D f Model =3D 4 Stepp= ing =3D 1 Features=3D0xbfebfbff Features2=3D0x659d AMD Features=3D0x20100000 TSC: P-state invariant real memory =3D 2147483648 (2048 MB) avail memory =3D 2086129664 (1989 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 2 package(s) x 1 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 6 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-47 on motherboard ioapic2 irqs 48-71 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 0x1008-0x100b on acpi0 cpu0: on acpi0 cpu1: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: at device 0.1 (no driver attached) pci0: at device 1.0 (no driver attached) pcib1: irq 16 at device 2.0 on pci0 pci1: on pcib1 pcib2: at device 0.0 on pci1 pci2: on pcib2 aac0: mem 0xdc000000-0xdfffffff irq 24 at device = 1.0 on pci2 aac0: Enable Raw I/O aac0: New comm. interface enabled aac0: [ITHREAD] aac0: Adaptec 2200S, aac driver 2.1.9-1 aacp0: on aac0 aacp1: on aac0 pcib3: at device 0.2 on pci1 pci3: on pcib3 em0: port 0x2000-0x203f= mem 0xd8200000-0xd821ffff irq 54 at device 2.0 on pci3 em0: [FILTER] em0: Ethernet address: 00:30:48:2d:32:6a em1: port 0x2040-0x207f= mem 0xd8220000-0xd823ffff irq 55 at device 2.1 on pci3 em1: [FILTER] em1: Ethernet address: 00:30:48:2d:32:6b pcib4: irq 16 at device 4.0 on pci0 pci4: on pcib4 pcib5: irq 16 at device 6.0 on pci0 pci5: on pcib5 uhci0: port 0x1400-0x141f irq 1= 6 at device 29.0 on pci0 uhci0: [ITHREAD] usbus0: on uhci0 uhci1: port 0x1420-0x143f irq 1= 9 at device 29.1 on pci0 uhci1: [ITHREAD] usbus1: on uhci1 uhci2: port 0x1440-0x145f irq 1= 8 at device 29.2 on pci0 uhci2: [ITHREAD] usbus2: on uhci2 uhci3: port 0x1460-0x147f irq 1= 6 at device 29.3 on pci0 uhci3: [ITHREAD] usbus3: on uhci3 ehci0: mem 0xd8001000-0xd80013f= f irq 23 at device 29.7 on pci0 ehci0: [ITHREAD] usbus4: EHCI version 1.0 usbus4: on ehci0 pcib6: at device 30.0 on pci0 pci6: on pcib6 vgapci0: port 0x3000-0x30ff mem 0xd9000000-0xd9fff= fff,0xd8300000-0xd8300fff irq 17 at device 1.0 on pci6 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177= ,0x376,0x14a0-0x14af at device 31.1 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] pci0: at device 31.3 (no driver attached) acpi_button0: on acpi0 atrtc0: port 0x70-0x77 irq 8 on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model Generic PS/2 mouse, device ID 0 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart0: [FILTER] uart0: console (9600,n,8,1) uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 uart1: [FILTER] fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FILTER] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 pmtimer0 on isa0 orm0: at iomem 0xc0000-0xc7fff,0xc8000-0xc8fff,0xc9000-0x= c9fff,0xca000-0xcafff,0xcb000-0xcf7ff pnpid ORM0000 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=3D0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ppc0: parallel port not found. est0: on cpu0 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 122d00000e24 device_attach: est0 attach returned 6 p4tcc0: on cpu0 est1: on cpu1 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 122d00000e24 device_attach: est1 attach returned 6 p4tcc1: on cpu1 Timecounters tick every 1.000 msec usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 12Mbps Full Speed USB v1.0 usbus4: 480Mbps High Speed USB v2.0 ata1: DMA limited to UDMA33, controller found non-ATA66 cable ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 ugen4.1: at usbus4 uhub4: on usbus4 acd0: DVDROM at ata1-slave UDMA33=20 aacd0: on aac0 aacd0: 34970MB (71619584 sectors) aacd1: on aac0 aacd1: 69974MB (143307008 sectors) uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered uhub3: 2 ports with 2 removable, self powered uhub4: 8 ports with 8 removable, self powered ses0 at aacp0 bus 0 scbus0 target 6 lun 0 ses0: Fixed Uninstalled SCSI-2 device=20 ses0: 3.300MB/s transfers ses0: SAF-TE Compliant Device pass0 at aacp0 bus 0 scbus0 target 0 lun 0 pass0: Fixed Uninstalled SCSI-3 device=20 pass0: 3.300MB/s transfers pass1 at aacp0 bus 0 scbus0 target 1 lun 0 pass1: Fixed Uninstalled SCSI-3 device=20 pass1: 3.300MB/s transfers pass2 at aacp0 bus 0 scbus0 target 2 lun 0 pass2: Fixed Uninstalled SCSI-3 device=20 pass2: 3.300MB/s transfers pass3 at aacp0 bus 0 scbus0 target 3 lun 0 pass3: Fixed Uninstalled SCSI-3 device=20 pass3: 3.300MB/s transfers SMP: AP CPU #1 Launched! WARNING: WITNESS option enabled, expect reduced performance. Trying to mount root from ufs:/dev/aacd0s4a Setting hostuuid: 80f1e964-dc63-0010-89d5-0030482d326a. Setting hostid: 0xc74551dd. Entropy harvesting: interrupts ethernet point_to_point kickstart =2E Starting file system checks: /dev/aacd0s4a: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/aacd0s4a: clean, 422048 free (1216 frags, 52604 blocks, 0.2% fragmenta= tion) /dev/aacd1s1e: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/aacd1s1e: clean, 4681662 free (261046 frags, 552577 blocks, 2.0% fragm= entation) /dev/aacd0s1a: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/aacd0s1a: clean, 424969 free (1913 frags, 52882 blocks, 0.3% fragmenta= tion) /dev/aacd0s1d: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/aacd0s1d: clean, 1031838 free (4190 frags, 128456 blocks, 0.2% fragmen= tation) /dev/aacd1s1d: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/aacd1s1d: clean, 11717829 free (197893 frags, 1439992 blocks, 1.2% fra= gmentation) /dev/aacd0s2a: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/aacd0s2a: clean, 596256 free (1488 frags, 74346 blocks, 0.2% fragmenta= tion) /dev/aacd0s2d: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/aacd0s2d: clean, 1108521 free (23105 frags, 135677 blocks, 1.3% fragme= ntation) /dev/aacd0s3a: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/aacd0s3a: clean, 578034 free (1146 frags, 72111 blocks, 0.2% fragmenta= tion) /dev/aacd0s3d: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/aacd0s3d: clean, 1070844 free (39380 frags, 128933 blocks, 2.2% fragme= ntation) /dev/aacd0s4d: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/aacd0s4d: clean, 1075950 free (60166 frags, 126973 blocks, 3.4% fragme= ntation) /dev/aacd0s4f: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/aacd0s4f: clean, 2106304 free (344 frags, 263245 blocks, 0.0% fragment= ation) Mounting local file systems: =2E Setting hostname: freebeast.catwhisker.org =2E lock order reversal: 1st 0xc683e7c8 ufs (ufs) @ /usr/src/sys/kern/vfs_lookup.c:502 2nd 0xd94fe700 bufwait (bufwait) @ /usr/src/sys/ufs/ffs/ffs_softdep.c:11363 3rd 0xc6871168 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2091 KDB: stack backtrace: db_trace_self_wrapper(c0cc72a5,ebdf2300,c08e9f65,c08da2db,c0cca298,...) at = db_trace_self_wrapper+0x26 kdb_backtrace(c08da2db,c0cca298,c553d030,c5540568,ebdf235c,...) at kdb_back= trace+0x29 _witness_debugger(c0cca298,c6871168,c0cbc5bd,c5540568,c0cd13b1,...) at _wit= ness_debugger+0x25 witness_checkorder(c6871168,9,c0cd13b1,82b,0,...) at witness_checkorder+0x8= 39 __lockmgr_args(c6871168,80100,c6871188,0,0,...) at __lockmgr_args+0x7f9 ffs_lock(ebdf2480,c08e9d0b,c0cd0856,80100,c6871110,...) at ffs_lock+0x8a VOP_LOCK1_APV(c0dd4ee0,ebdf2480,c63cecd4,c0def920,c6871110,...) at VOP_LOCK= 1_APV+0xb5 _vn_lock(c6871110,80100,c0cd13b1,82b,4,...) at _vn_lock+0x5e vget(c6871110,80100,c63cec30,50,0,...) at vget+0xb9 vfs_hash_get(c6857ca8,78c22,80000,c63cec30,ebdf25d0,...) at vfs_hash_get+0x= e6 ffs_vgetf(c6857ca8,78c22,80000,ebdf25d0,1,...) at ffs_vgetf+0x49 softdep_sync_metadata(c683e770,0,c0ced5f8,144,0,...) at softdep_sync_metada= ta+0xc92 ffs_syncvnode(c683e770,1,c63cec30,ebdf2690,246,...) at ffs_syncvnode+0x3e2 ffs_truncate(c683e770,200,0,880,c5588480,...) at ffs_truncate+0x862 ufs_direnter(c683e770,c6871110,ebdf2944,ebdf2bd4,0,...) at ufs_direnter+0x8= d4 ufs_makeinode(ebdf2bd4,0,ebdf2b30,ebdf2a8c,c0c032e5,...) at ufs_makeinode+0= x557 ufs_create(ebdf2b30,ebdf2b48,0,0,ebdf2ba8,...) at ufs_create+0x30 VOP_CREATE_APV(c0dd4ee0,ebdf2b30,ebdf2bd4,ebdf2ac8,0,...) at VOP_CREATE_APV= +0xa5 vn_open_cred(ebdf2ba8,ebdf2c5c,1a4,0,c5588480,...) at vn_open_cred+0x215 vn_open(ebdf2ba8,ebdf2c5c,1a4,c637ee70,0,...) at vn_open+0x3b kern_openat(c63cec30,ffffff9c,804c5e8,0,602,...) at kern_openat+0x125 kern_open(c63cec30,804c5e8,0,601,21b6,...) at kern_open+0x35 open(c63cec30,ebdf2cf8,c0cffdfb,c0caa6d4,c63c9d48,...) at open+0x30 syscall(ebdf2d38) at syscall+0x220 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (5, FreeBSD ELF32, open), eip =3D 0x281744b3, esp =3D 0xbfbfec4= c, ebp =3D 0xbfbfecb8 --- Starting Network: lo0 em0 em1. lo0: flags=3D8049 metric 0 mtu 16384 options=3D3 inet 127.0.0.1 netmask 0xff000000=20 inet6 ::1 prefixlen 128=20 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3=20 nd6 options=3D21 em0: flags=3D8843 metric 0 mtu 1500 options=3D389b ether 00:30:48:2d:32:6a inet 172.16.8.10 netmask 0xffffff00 broadcast 172.16.8.255 inet6 fe80::230:48ff:fe2d:326a%em0 prefixlen 64 tentative scopeid 0x1=20 nd6 options=3D29 media: Ethernet autoselect status: no carrier em1: flags=3D8802 metric 0 mtu 1500 options=3D389b ether 00:30:48:2d:32:6b media: Ethernet autoselect status: no carrier Starting devd. Starting Network: em1. em1: flags=3D8802 metric 0 mtu 1500 options=3D389b ether 00:30:48:2d:32:6b media: Ethernet autoselect status: no carrier add net default: gateway 172.16.8.1 add net ::ffff:0.0.0.0: gateway ::1 add net ::0.0.0.0: gateway ::1 add net fe80::: gateway ::1 add net ff02::: gateway ::1 ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib /usr/local/= lib/compat a.out ldconfig path: /usr/lib/aout /usr/lib/compat/aout Creating and/or trimming log files =2E Starting syslogd. No core dumps found. Starting rpcbind. NFS access cache time=3D60 em0: link state changed to UP Setting NIS domain: lmdhw.com. Starting ypbind. Starting amd. Kernel page fault with the following non-sleepable locks held: exclusive sleep mutex mld_mtx (mld_mtx) r =3D 0 (0xc0f96468) locked @ /usr/= src/sys/netinet6/mld6.c:1352 exclusive sleep mutex in6_multi_mtx (in6_multi_mtx) r =3D 0 (0xc0f95408) lo= cked @ /usr/src/sys/netinet6/mld6.c:1351 KDB: stack backtrace: db_trace_self_wrapper(c0cc72a5,c5213864,c08e9f65,c0ce3e07,547,...) at db_tr= ace_self_wrapper+0x26 kdb_backtrace(c0ce3e07,547,ffffffff,c0f65a1c,c521389c,...) at kdb_backtrace= +0x29 _witness_debugger(c0cc982b,c52138b0,4,1,0,...) at _witness_debugger+0x25 witness_warn(5,0,c0cffec8,c55810a4,c557f7f8,...) at witness_warn+0x1fd trap(c521393c) at trap+0x19e calltrap() at calltrap+0x6 --- trap 0xc, eip =3D 0xc0a4d340, esp =3D 0xc521397c, ebp =3D 0xc5213b14 --- ip6_output(c5a4fc00,c0f964a0,0,1,c5213b44,...) at ip6_output+0x840 mld_dispatch_packet(0,0,c5213c1c,c0a509a7,c56fca2c,...) at mld_dispatch_pac= ket+0x30d mld_dispatch_queue(c56fca2c,0,c0ce3e07,591,c0cbb984,...) at mld_dispatch_qu= eue+0x38 mld_fasttimo(c5213c48,c0904cc9,c5213c48,c0893aa4,c0e24f80,...) at mld_fastt= imo+0x747 icmp6_fasttimo(c5213c48,c0893aa4,c0e24f80,4,c0cc24d6,...) at icmp6_fasttimo= +0x8 pffasttimo(0,0,c0cc5113,189,c0e24fb8,...) at pffasttimo+0x29 softclock(c0e24f80,c5213cc8,c0893aa4,c0e28940,c5588838,...) at softclock+0x= 24a intr_event_execute_handlers(c557f7f8,c5588800,c0cbf33f,533,c5588870,...) at= intr_event_execute_handlers+0x125 ithread_loop(c557e120,c5213d38,c0cbf0b8,343,c557f7f8,...) at ithread_loop+0= x9f fork_exit(c087c780,c557e120,c5213d38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip =3D 0, esp =3D 0xc5213d70, ebp =3D 0 --- Fatal trap 12: page fault while in kernel mode cpuid =3D 0; apic id =3D 00 fault virtual address =3D 0x3c fault code =3D supervisor read, page not present instruction pointer =3D 0x20:0xc0a4d340 stack pointer =3D 0x28:0xc521397c frame pointer =3D 0x28:0xc5213b14 code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, def32 1, gran 1 processor eflags =3D interrupt enabled, resume, IOPL =3D 0 current process =3D 12 (swi4: clock) panic: from debugger cpuid =3D 0 Uptime: 20s Physical memory: 2030 MB Dumping 89 MB: 74 58 42 26 10 ------------------------------------------------------------------------ kernel config options CONFIG_AUTOGENERATED ident GENERIC machine i386 cpu I686_CPU cpu I586_CPU cpu I486_CPU makeoptions DEBUG=3D-g options USB_DEBUG options AH_SUPPORT_AR5416 options IEEE80211_SUPPORT_MESH options IEEE80211_AMPDU_AGE options IEEE80211_DEBUG options AHD_REG_PRETTY_PRINT options AHC_REG_PRETTY_PRINT options ATA_STATIC_ID options SMP options WITNESS_SKIPSPIN options WITNESS options INVARIANT_SUPPORT options INVARIANTS options DEADLKRES options GDB options DDB options KDB options INCLUDE_CONFIG_FILE options FLOWTABLE options MAC options AUDIT options HWPMC_HOOKS options KBD_INSTALL_CDEV options PRINTF_BUFR_SIZE=3D128 options _KPOSIX_PRIORITY_SCHEDULING options P1003_1B_SEMAPHORES options SYSVSEM options SYSVMSG options SYSVSHM options STACK options KTRACE options SCSI_DELAY=3D5000 options COMPAT_FREEBSD7 options COMPAT_FREEBSD6 options COMPAT_FREEBSD5 options COMPAT_FREEBSD4 options GEOM_LABEL options GEOM_PART_GPT options PSEUDOFS options PROCFS options CD9660 options MSDOSFS options NFS_ROOT options NFSLOCKD options NFSSERVER options NFSCLIENT options MD_ROOT options UFS_GJOURNAL options UFS_DIRHASH options UFS_ACL options SOFTUPDATES options FFS options SCTP options INET6 options INET options PREEMPTION options SCHED_ULE options NATIVE options GEOM_PART_MBR options GEOM_PART_EBR_COMPAT options GEOM_PART_EBR options GEOM_PART_BSD options ISAPNP device isa device npx device mem device io device uart_ns8250 device atpic device apic device cpufreq device acpi device eisa device pci device fdc device ata device atadisk device ataraid device atapicd device atapifd device atapist device ahb device ahc device ahd device amd device hptiop device isp device mpt device sym device trm device adv device adw device aha device aic device bt device ncv device nsp device stg device scbus device ch device da device sa device cd device pass device ses device amr device arcmsr device asr device ciss device dpt device hptmv device hptrr device iir device ips device mly device twa device aac device aacp device ida device mfi device mlx device pst device twe device atkbdc device atkbd device psm device kbdmux device vga device splash device sc device agp device pmtimer device cbb device pccard device cardbus device uart device ppc device ppbus device lpt device plip device ppi device de device em device igb device ixgb device le device ti device txp device vx device miibus device ae device age device alc device ale device bce device bfe device bge device dc device et device fxp device jme device lge device msk device nfe device nge device pcn device re device rl device sf device sge device sis device sk device ste device stge device tl device tx device vge device vr device wb device xl device cs device ed device ex device ep device fe device ie device sn device xe device wlan device wlan_wep device wlan_ccmp device wlan_tkip device wlan_amrr device an device ath device ath_hal device ath_rate_sample device ral device wi device loop device random device ether device vlan device tun device pty device md device gif device faith device firmware device bpf device uhci device ohci device ehci device usb device uhid device ukbd device ulpt device umass device ums device urio device u3g device uark device ubsa device uftdi device uipaq device uplcom device uslcom device uvisor device uvscom device aue device axe device cdce device cue device kue device rue device udav device rum device uath device ural device zyd device firewire device sbp device fwe device fwip device dcons device dcons_crom ------------------------------------------------------------------------ ddb capture buffer Peace, david --=20 David H. Wolfskill david@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --vYDx0ctV5ggqAdB/ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iEYEARECAAYFAkvojhYACgkQmprOCmdXAD116gCfVBmSF7otPikqf4wIC/Sd5GV4 7L0AnRrRguEHZffrH+3Sl7EsgnhjaRBK =FB7A -----END PGP SIGNATURE----- --vYDx0ctV5ggqAdB/-- From owner-freebsd-current@FreeBSD.ORG Mon May 10 23:33:22 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3A087106566C; Mon, 10 May 2010 23:33:22 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from bunrab.catwhisker.org (adsl-63-193-123-122.dsl.snfc21.pacbell.net [63.193.123.122]) by mx1.freebsd.org (Postfix) with ESMTP id 06E5B8FC21; Mon, 10 May 2010 23:33:21 +0000 (UTC) Received: from bunrab.catwhisker.org (localhost [127.0.0.1]) by bunrab.catwhisker.org (8.13.3/8.13.3) with ESMTP id o4ANXLou098351; Mon, 10 May 2010 16:33:21 -0700 (PDT) (envelope-from david@bunrab.catwhisker.org) Received: (from david@localhost) by bunrab.catwhisker.org (8.13.3/8.13.3/Submit) id o4ANXLBL098350; Mon, 10 May 2010 16:33:21 -0700 (PDT) (envelope-from david) Date: Mon, 10 May 2010 16:33:21 -0700 From: David Wolfskill To: "K. Macy" , current@freebsd.org Message-ID: <20100510233321.GO49209@bunrab.catwhisker.org> Mail-Followup-To: David Wolfskill , "K. Macy" , current@freebsd.org References: <20100510140722.GD49209@bunrab.catwhisker.org> <20100510182243.GV56080@hoeg.nl> <20100510182625.GF49209@bunrab.catwhisker.org> <20100510220854.GK49209@bunrab.catwhisker.org> <20100510225207.GM49209@bunrab.catwhisker.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="oJoa/b7Rsqp4yzB0" Content-Disposition: inline In-Reply-To: <20100510225207.GM49209@bunrab.catwhisker.org> User-Agent: Mutt/1.4.2.1i Cc: Subject: Re: Panic @r207844; current process: flowcleaner "Fatal trap 12: page fault while in kernel mode" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 23:33:22 -0000 --oJoa/b7Rsqp4yzB0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, May 10, 2010 at 03:52:07PM -0700, David Wolfskill wrote: > On Mon, May 10, 2010 at 03:39:11PM -0700, K. Macy wrote: > > Are you not able to dump core? > > .... >=20 > Here's the crash summary; I can put the dump on my Web server on request. > (It weighs in at 89MB.) > .... Compression reduced the resulting file to 10MB; it may be found at . I'll be leaving the office to head home between 16:50 - 16:55, and I'll be off-Net until I get home (no earlier than 18:00, but probably before 19:00 -- depending on errands being run). Peace, david --=20 David H. Wolfskill david@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --oJoa/b7Rsqp4yzB0 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iEYEARECAAYFAkvol8AACgkQmprOCmdXAD201ACdEn7nJydgg+lhTUbfPqzWQKNV ZmIAn0O54VkFk731BZPbvM+5CB7Hb4/q =emx9 -----END PGP SIGNATURE----- --oJoa/b7Rsqp4yzB0-- From owner-freebsd-current@FreeBSD.ORG Tue May 11 03:07:28 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 586F0106564A for ; Tue, 11 May 2010 03:07:28 +0000 (UTC) (envelope-from widawsky@gmail.com) Received: from mail-qy0-f181.google.com (mail-qy0-f181.google.com [209.85.221.181]) by mx1.freebsd.org (Postfix) with ESMTP id 123388FC0C for ; Tue, 11 May 2010 03:07:27 +0000 (UTC) Received: by qyk11 with SMTP id 11so6647576qyk.13 for ; Mon, 10 May 2010 20:07:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=gCSHI3r0F9PFnAyRsUVaOyiWSEMxsETR9WQonOktAOY=; b=XwbV7ZE2xzv3w+wP1Ax4/434HHP4Fju90vnjXSUzrYsRvdP/rQpTXleI/Q1VlEMRjs sJ1y5Hhpbd3kGyUTNjXF2ICA/OzQ2Xm+Oro+155lnb1waI6kstaFsD5UBF2lv18DQoZE /Ic+BFsT3JRMTUyv/lEjCW5qvdh7Kwh47xNpg= 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=JOghkpUCyyHlOtlW28uopbYlmNYAvJwKEKYNXT2CJ1FnjkXL+I5ASWcUb7+U9ezif4 /8X4Bcw53iN1tm2w23sHDWfCa6aWOtHqAuRqOoj0Jeygm8f+dwuuo6SreDsAgM/MEe0Q 4uCbt7YnM3V5ax8ucKaVGvUQNuUv6U7uT/Nyk= MIME-Version: 1.0 Received: by 10.224.73.27 with SMTP id o27mr3326381qaj.177.1273547247242; Mon, 10 May 2010 20:07:27 -0700 (PDT) Received: by 10.224.67.84 with HTTP; Mon, 10 May 2010 20:07:27 -0700 (PDT) In-Reply-To: <20100508135031.00fcd71e@ernst.jennejohn.org> References: <20100508135031.00fcd71e@ernst.jennejohn.org> Date: Mon, 10 May 2010 20:07:27 -0700 Message-ID: From: Ben Widawsky To: gljennjohn@googlemail.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: PT_ATTACH resumes suspended process X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2010 03:07:28 -0000 > Looking at the sendsig label in sys_process.c:kern_ptrace() makes it clea= r > what's happening - in your testing the process was already stopped so > the code sets td_xsig to SIGSTOP and wakes it up to send it the signal. > > But td_xsig doesn't seem to be used anywhere to set pending signals. =A0M= aybe > I missed the place where that happens. > > The assumption seems to be that a process being traced will only be > stopped if the debugger is already attached and that any signals being > sent to it are coming from the debugger itself. > > This assumption is wrong if the process being attached to was already > stopped. > > It seems to me that checking for req =3D=3D PT_ATTACH when the process is > already stopped and doing a break; in that case might be a solution. Could you be more specific? It seems to me even if you had a special case i= n kern_ptrace to handle PT_ATTACH when the process is suspended, the code wou= ld end up being almost identical to ptracestop(). Unless I didn't follow you. Because of this, I think what I suggested initially, esentially resuming th= e thread with a pending SIGSTOP (by checking the value of xsig when the threa= d switches back in issignal) would be a better approach. The hack I put in bo= thers me a bit because some of the other threads may resume, and even run for a w= hile, but it's still better than the existing behavior. From owner-freebsd-current@FreeBSD.ORG Tue May 11 08:04:41 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 67145106567C for ; Tue, 11 May 2010 08:04:41 +0000 (UTC) (envelope-from ianf@clue.co.za) Received: from inbound01.jnb1.gp-online.net (inbound01.jnb1.gp-online.net [41.161.16.135]) by mx1.freebsd.org (Postfix) with ESMTP id EFC888FC27 for ; Tue, 11 May 2010 08:04:40 +0000 (UTC) Received: from [41.154.88.19] (helo=clue.co.za) by inbound01.jnb1.gp-online.net with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1OBkSE-0001GI-7E; Tue, 11 May 2010 10:04:38 +0200 Received: from localhost ([127.0.0.1] helo=clue.co.za) by clue.co.za with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1OBkSA-0000Rq-Fw; Tue, 11 May 2010 10:04:34 +0200 To: Weongyo Jeong From: Ian FREISLICH In-Reply-To: References: <20100510195622.GA1295@weongyo> <20100228095259.GB3536@weongyo> <20100301103240.3a4aac8a.ray@dlink.ua> <20100303082833.GB22865@weongyo> <20100303111014.6564ea1e.ray@dlink.ua> <20100312231333.GZ1295@weongyo> <4BD2201E.3090409@entel.upc.edu> <20100424231755.GI65380@weongyo> <4BD4A928.8020901@entel.upc.edu> <20100506190653.GA31100@weongyo> <58220.88.15.97.205.1273248485.squirrel@webmail.entel.upc.edu> X-Attribution: BOFH Date: Tue, 11 May 2010 10:04:34 +0200 Message-Id: Cc: Gustavo Perez Querol , current@freebsd.org Subject: Re: Call for Test and Review: bwn(4) - another Broadcom Wireless driver X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2010 08:04:41 -0000 Ian FREISLICH wrote: > Weongyo Jeong wrote: > > > Do you want me to test anything else ? > > > > OK. The patch is ready to test. Could you please test it with attached > > patch? > > No panic this time. I also don't get these messages any more: > > May 10 23:25:36 mini kernel: bwn0: unsupported rate 0 > May 10 23:26:13 mini last message repeated 2 times > May 10 23:28:29 mini last message repeated 320 times > May 10 23:28:32 mini last message repeated 61 times > May 10 23:29:42 mini shutdown: reboot by ianf: > > It still doesn't associate with my AP until I destroy the wlan > interface and create it again: But, after about 12 hours it reduced the rate to 36mbit/s OFDM with large amounts of time either not transmitting or not recieving - 86% packet loss over 5 minutes. Ian -- Ian Freislich From owner-freebsd-current@FreeBSD.ORG Tue May 11 13:18:22 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EEB0A1065670; Tue, 11 May 2010 13:18:22 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from bunrab.catwhisker.org (adsl-63-193-123-122.dsl.snfc21.pacbell.net [63.193.123.122]) by mx1.freebsd.org (Postfix) with ESMTP id 496158FC1D; Tue, 11 May 2010 13:18:21 +0000 (UTC) Received: from bunrab.catwhisker.org (localhost [127.0.0.1]) by bunrab.catwhisker.org (8.13.3/8.13.3) with ESMTP id o4BDIH5x001150; Tue, 11 May 2010 06:18:17 -0700 (PDT) (envelope-from david@bunrab.catwhisker.org) Received: (from david@localhost) by bunrab.catwhisker.org (8.13.3/8.13.3/Submit) id o4BDIHH2001149; Tue, 11 May 2010 06:18:17 -0700 (PDT) (envelope-from david) Date: Tue, 11 May 2010 06:18:17 -0700 From: David Wolfskill To: "K. Macy" Message-ID: <20100511131817.GB685@bunrab.catwhisker.org> Mail-Followup-To: David Wolfskill , "K. Macy" , Ed Schouten , current@freebsd.org References: <20100510140722.GD49209@bunrab.catwhisker.org> <20100510182243.GV56080@hoeg.nl> <20100510182625.GF49209@bunrab.catwhisker.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Bn2rw/3z4jIqBvZU" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: Ed Schouten , current@freebsd.org Subject: Re: Panic @r207844; current process: flowcleaner "Fatal trap 12: page fault while in kernel mode" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2010 13:18:23 -0000 --Bn2rw/3z4jIqBvZU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, May 10, 2010 at 02:32:14PM -0700, K. Macy wrote: > Could you please try with 207902? > ... I saved that environment (documented elsewhere ini the thread), then performed the normal (for me) daily update, this time, to r207911. Again, I see a panic during transition from single-user mode to multi-user mode: =2E.. 3 Select option, [Enter] for default 3 3 or [Space] to pause timer 9 3 @DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2010 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 9.0-CURRENT #156 r207911: Tue May 11 05:55:18 PDT 2010 root@freebeast.catwhisker.org:/usr/obj/usr/src/sys/GENERIC i386 WARNING: WITNESS option enabled, expect reduced performance. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(TM) CPU 3.60GHz (3614.55-MHz 686-class CPU) Origin =3D "GenuineIntel" Id =3D 0xf41 Family =3D f Model =3D 4 Stepp= ing =3D 1 Features=3D0xbfebfbff Features2=3D0x659d AMD Features=3D0x20100000 TSC: P-state invariant real memory =3D 2147483648 (2048 MB) avail memory =3D 2086129664 (1989 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 2 package(s) x 1 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 6 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-47 on motherboard ioapic2 irqs 48-71 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 0x1008-0x100b on acpi0 cpu0: on acpi0 cpu1: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: at device 0.1 (no driver attached) pci0: at device 1.0 (no driver attached) pcib1: irq 16 at device 2.0 on pci0 pci1: on pcib1 pcib2: at device 0.0 on pci1 pci2: on pcib2 aac0: mem 0xdc000000-0xdfffffff irq 24 at device = 1.0 on pci2 aac0: Enable Raw I/O aac0: New comm. interface enabled aac0: [ITHREAD] aac0: Adaptec 2200S, aac driver 2.1.9-1 aacp0: on aac0 aacp1: on aac0 pcib3: at device 0.2 on pci1 pci3: on pcib3 em0: port 0x2000-0x203f= mem 0xd8200000-0xd821ffff irq 54 at device 2.0 on pci3 em0: [FILTER] em0: Ethernet address: 00:30:48:2d:32:6a em1: port 0x2040-0x207f= mem 0xd8220000-0xd823ffff irq 55 at device 2.1 on pci3 em1: [FILTER] em1: Ethernet address: 00:30:48:2d:32:6b pcib4: irq 16 at device 4.0 on pci0 pci4: on pcib4 pcib5: irq 16 at device 6.0 on pci0 pci5: on pcib5 uhci0: port 0x1400-0x141f irq 1= 6 at device 29.0 on pci0 uhci0: [ITHREAD] usbus0: on uhci0 uhci1: port 0x1420-0x143f irq 1= 9 at device 29.1 on pci0 uhci1: [ITHREAD] usbus1: on uhci1 uhci2: port 0x1440-0x145f irq 1= 8 at device 29.2 on pci0 uhci2: [ITHREAD] usbus2: on uhci2 uhci3: port 0x1460-0x147f irq 1= 6 at device 29.3 on pci0 uhci3: [ITHREAD] usbus3: on uhci3 ehci0: mem 0xd8001000-0xd80013f= f irq 23 at device 29.7 on pci0 ehci0: [ITHREAD] usbus4: EHCI version 1.0 usbus4: on ehci0 pcib6: at device 30.0 on pci0 pci6: on pcib6 vgapci0: port 0x3000-0x30ff mem 0xd9000000-0xd9fff= fff,0xd8300000-0xd8300fff irq 17 at device 1.0 on pci6 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177= ,0x376,0x14a0-0x14af at device 31.1 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] pci0: at device 31.3 (no driver attached) acpi_button0: on acpi0 atrtc0: port 0x70-0x77 irq 8 on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model Generic PS/2 mouse, device ID 0 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart0: [FILTER] uart0: console (9600,n,8,1) uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 uart1: [FILTER] fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FILTER] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 pmtimer0 on isa0 orm0: at iomem 0xc0000-0xc7fff,0xc8000-0xc8fff,0xc9000-0x= c9fff,0xca000-0xcafff,0xcb000-0xcf7ff pnpid ORM0000 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=3D0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ppc0: parallel port not found. est0: on cpu0 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 122d00000e24 device_attach: est0 attach returned 6 p4tcc0: on cpu0 est1: on cpu1 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 122d00000e24 device_attach: est1 attach returned 6 p4tcc1: on cpu1 Timecounters tick every 1.000 msec usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 12Mbps Full Speed USB v1.0 usbus4: 480Mbps High Speed USB v2.0 ata1: DMA limited to UDMA33, controller found non-ATA66 cable ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 ugen4.1: at usbus4 uhub4: on usbus4 acd0: DVDROM at ata1-slave UDMA33=20 aacd0: on aac0 aacd0: 34970MB (71619584 sectors) aacd1: on aac0 aacd1: 69974MB (143307008 sectors) uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered uhub3: 2 ports with 2 removable, self powered uhub4: 8 ports with 8 removable, self powered ses0 at aacp0 bus 0 scbus0 target 6 lun 0 ses0: Fixed Uninstalled SCSI-2 device=20 ses0: 3.300MB/s transfers ses0: SAF-TE Compliant Device pass0 at aacp0 bus 0 scbus0 target 0 lun 0 pass0: Fixed Uninstalled SCSI-3 device=20 pass0: 3.300MB/s transfers pass1 at aacp0 bus 0 scbus0 target 1 lun 0 pass1: Fixed Uninstalled SCSI-3 device=20 pass1: 3.300MB/s transfers pass2 at aacp0 bus 0 scbus0 target 2 lun 0 pass2: Fixed Uninstalled SCSI-3 device=20 pass2: 3.300MB/s transfers pass3 at aacp0 bus 0 scbus0 target 3 lun 0 pass3: Fixed Uninstalled SCSI-3 device=20 pass3: 3.300MB/s transfers SMP: AP CPU #1 Launched! WARNING: WITNESS option enabled, expect reduced performance. Trying to mount root from ufs:/dev/aacd0s4a Setting hostuuid: 80f1e964-dc63-0010-89d5-0030482d326a. Setting hostid: 0xc74551dd. Entropy harvesting: interrupts ethernet point_to_point kickstart. Starting file system checks: /dev/aacd0s4a: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/aacd0s4a: clean, 344803 free (2027 frags, 42847 blocks, 0.3% fragmenta= tion) /dev/aacd1s1e: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/aacd1s1e: clean, 4753395 free (263851 frags, 561193 blocks, 2.0% fragm= entation) /dev/aacd0s1a: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/aacd0s1a: clean, 422042 free (682 frags, 52670 blocks, 0.1% fragmentat= ion) /dev/aacd0s1d: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/aacd0s1d: clean, 1076253 free (237 frags, 134502 blocks, 0.0% fragment= ation) /dev/aacd1s1d: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/aacd1s1d: clean, 11714543 free (199151 frags, 1439424 blocks, 1.2% fra= gmentation) /dev/aacd0s2a: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/aacd0s2a: clean, 596264 free (1144 frags, 74390 blocks, 0.2% fragmenta= tion) /dev/aacd0s2d: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/aacd0s2d: clean, 1108483 free (24155 frags, 135541 blocks, 1.3% fragme= ntation) /dev/aacd0s3a: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/aacd0s3a: clean, 578034 free (1186 frags, 72106 blocks, 0.2% fragmenta= tion) /dev/aacd0s3d: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/aacd0s3d: clean, 1070803 free (41819 frags, 128623 blocks, 2.3% fragme= ntation) /dev/aacd0s4d: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/aacd0s4d: clean, 1075758 free (60510 frags, 126906 blocks, 3.4% fragme= ntation) /dev/aacd0s4f: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/aacd0s4f: clean, 2071008 free (368 frags, 258830 blocks, 0.0% fragment= ation) Mounting local file systems:. Setting hostname: freebeast.catwhisker.org. lock order reversal: 1st 0xc684b6b8 ufs (ufs) @ /usr/src/sys/kern/vfs_lookup.c:502 2nd 0xd94fe304 bufwait (bufwait) @ /usr/src/sys/ufs/ffs/ffs_softdep.c:11363 3rd 0xc6875168 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2091 KDB: stack backtrace: db_trace_self_wrapper(c0cc7405,ebe3d300,c08ea0d5,c08da44b,c0cca3f8,...) at = db_trace_self_wrapper+0x26 kdb_backtrace(c08da44b,c0cca3f8,c553d030,c5540568,ebe3d35c,...) at kdb_back= trace+0x29 _witness_debugger(c0cca3f8,c6875168,c0cbc71d,c5540568,c0cd1511,...) at _wit= ness_debugger+0x25 witness_checkorder(c6875168,9,c0cd1511,82b,0,...) at witness_checkorder+0x8= 39 __lockmgr_args(c6875168,80100,c6875188,0,0,...) at __lockmgr_args+0x7f9 ffs_lock(ebe3d480,c08e9e7b,c0cd09b6,80100,c6875110,...) at ffs_lock+0x8a VOP_LOCK1_APV(c0dd5040,ebe3d480,c6868cd4,c0defa80,c6875110,...) at VOP_LOCK= 1_APV+0xb5 _vn_lock(c6875110,80100,c0cd1511,82b,4,...) at _vn_lock+0x5e vget(c6875110,80100,c6868c30,50,0,...) at vget+0xb9 vfs_hash_get(c6846ca8,78c22,80000,c6868c30,ebe3d5d0,...) at vfs_hash_get+0x= e6 ffs_vgetf(c6846ca8,78c22,80000,ebe3d5d0,1,...) at ffs_vgetf+0x49 softdep_sync_metadata(c684b660,0,c0ced758,144,0,...) at softdep_sync_metada= ta+0xc92 ffs_syncvnode(c684b660,1,c6868c30,ebe3d690,246,...) at ffs_syncvnode+0x3e2 ffs_truncate(c684b660,200,0,880,c5588480,...) at ffs_truncate+0x862 ufs_direnter(c684b660,c6875110,ebe3d944,ebe3dbd4,0,...) at ufs_direnter+0x8= d4 ufs_makeinode(ebe3dbd4,0,ebe3db30,ebe3da8c,c0c03435,...) at ufs_makeinode+0= x557 ufs_create(ebe3db30,ebe3db48,0,0,ebe3dba8,...) at ufs_create+0x30 VOP_CREATE_APV(c0dd5040,ebe3db30,ebe3dbd4,ebe3dac8,0,...) at VOP_CREATE_APV= +0xa5 vn_open_cred(ebe3dba8,ebe3dc5c,1a4,0,c5588480,...) at vn_open_cred+0x215 vn_open(ebe3dba8,ebe3dc5c,1a4,c637e380,0,...) at vn_open+0x3b kern_openat(c6868c30,ffffff9c,804c5e8,0,602,...) at kern_openat+0x125 kern_open(c6868c30,804c5e8,0,601,21b6,...) at kern_open+0x35 open(c6868c30,ebe3dcf8,c0cfff5b,c0caa834,c63cbaa0,...) at open+0x30 syscall(ebe3dd38) at syscall+0x220 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (5, FreeBSD ELF32, open), eip =3D 0x281744b3, esp =3D 0xbfbfec4= c, ebp =3D 0xbfbfecb8 --- Starting Network: lo0 em0 em1. lo0: flags=3D8049 metric 0 mtu 16384 options=3D3 inet 127.0.0.1 netmask 0xff000000=20 inet6 ::1 prefixlen 128=20 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3=20 nd6 options=3D21 em0: flags=3D8843 metric 0 mtu 1500 options=3D289b ether 00:30:48:2d:32:6a inet 172.16.8.10 netmask 0xffffff00 broadcast 172.16.8.255 inet6 fe80::230:48ff:fe2d:326a%em0 prefixlen 64 tentative scopeid 0= x1=20 nd6 options=3D29 media: Ethernet autoselect status: no carrier em1: flags=3D8802 metric 0 mtu 1500 options=3D389b ether 00:30:48:2d:32:6b media: Ethernet autoselect status: no carrier Starting devd. Starting Network: em1. em1: flags=3D8802 metric 0 mtu 1500 options=3D389b ether 00:30:48:2d:32:6b media: Ethernet autoselect status: no carrier add net default: gateway 172.16.8.1 add net ::ffff:0.0.0.0: gateway ::1 add net ::0.0.0.0: gateway ::1 add net fe80::: gateway ::1 add net ff02::: gateway ::1 ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib /usr/local/= lib/compat a.out ldconfig path: /usr/lib/aout /usr/lib/compat/aout Creating and/or trimming log files. Starting syslogd. No core dumps found. Starting rpcKernel page fault with the following non-sleepable locks held: exclusive sleep mutex mld_mtx (mld_mtx) r =3D 0 (0xc0f965e8) locked @ /usr/= src/sys/netinet6/mld6.c:1352 exclusive sleep mutex in6_multi_mtx (in6_multi_mtx) r =3D 0 (0xc0f95588) lo= cked @ /usr/src/sys/netinet6/mld6.c:1351 KDB: stack backtrace: db_trace_self_wrapper(c0cc7405,c5213864,c08ea0d5,c0ce3f67,547,...) at db_tr= ace_self_wrapper+0x26 kdb_backtrace(c0ce3f67,547,ffffffff,c0f65a94,c521389c,...) at kdb_backtrace= +0x29 _witness_debugger(c0cc998b,c52138b0,4,1,0,...) at _witness_debugger+0x25 witness_warn(5,0,c0d00028,c55810a4,c557f7f8,...) at witness_warn+0x1fd trap(c521393c) at trap+0x19e calltrap() at calltrap+0x6 --- trap 0xc, eip =3D 0xc0a4d4b0, esp =3D 0xc521397c, ebp =3D 0xc5213b14 --- ip6_output(c6938600,c0f96620,0,1,c5213b44,...) at ip6_output+0x840 mld_dispatch_packet(0,0,c5213c1c,c0a50b17,c56fca2c,...) at mld_dispatch_pac= ket+0x30d mld_dispatch_queue(c56fca2c,0,c0ce3f67,591,c0cbbae4,...) at mld_dispatch_qu= eue+0x38 mld_fasttimo(c5213c48,c0904e39,c5213c48,c0893c14,c0e25100,...) at mld_fastt= imo+0x747 icmp6_fasttimo(c5213c48,c0893c14,c0e25100,4,c0cc2636,...) at icmp6_fasttimo= +0x8 pffasttimo(0,0,c0cc5273,189,c0e25138,...) at pffasttimo+0x29 softclock(c0e25100,c5213cc8,c0893c14,c0e29140,c5588838,...) at softclock+0x= 24a intr_event_execute_handlers(c557f7f8,c5588800,c0cbf49f,533,c5588870,...) at= intr_event_execute_handlers+0x125 ithread_loop(c557e120,c5213d38,c0cbf218,343,c557f7f8,...) at ithread_loop+0= x9f fork_exit(c087c8f0,c557e120,c5213d38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip =3D 0, esp =3D 0xc5213d70, ebp =3D 0 --- Fatal trap 12: page fault while in kernel mode cpuid =3D 1; apic id =3D 06 fault virtual address =3D 0x3c fault code =3D supervisor read, page not present instruction pointer =3D 0x20:0xc0a4d4b0 stack pointer =3D 0x28:0xc521397c frame pointer =3D 0x28:0xc5213b14 code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, def32 1, gran 1 processor eflags =3D interrupt enabled, resume, IOPL =3D 0 current process =3D 12 (swi4: clock) [ thread pid 12 tid 100007 ] Stopped at ip6_output+0x840: movl 0x3c(%eax),%eax db> bt Tracing pid 12 tid 100007 td 0xc5581000 ip6_output(c6938600,c0f96620,0,1,c5213b44,...) at ip6_output+0x840 mld_dispatch_packet(0,0,c5213c1c,c0a50b17,c56fca2c,...) at mld_dispatch_pac= ket+0x30d mld_dispatch_queue(c56fca2c,0,c0ce3f67,591,c0cbbae4,...) at mld_dispatch_qu= eue+0x38 mld_fasttimo(c5213c48,c0904e39,c5213c48,c0893c14,c0e25100,...) at mld_fastt= imo+0x747 icmp6_fasttimo(c5213c48,c0893c14,c0e25100,4,c0cc2636,...) at icmp6_fasttimo= +0x8 pffasttimo(0,0,c0cc5273,189,c0e25138,...) at pffasttimo+0x29 softclock(c0e25100,c5213cc8,c0893c14,c0e29140,c5588838,...) at softclock+0x= 24a intr_event_execute_handlers(c557f7f8,c5588800,c0cbf49f,533,c5588870,...) at= intr_event_execute_handlers+0x125 ithread_loop(c557e120,c5213d38,c0cbf218,343,c557f7f8,...) at ithread_loop+0= x9f fork_exit(c087c8f0,c557e120,c5213d38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip =3D 0, esp =3D 0xc5213d70, ebp =3D 0 --- db>=20 Again, I'll leave it in this state so folks can suggest other information or patches to try. Peace, david --=20 David H. Wolfskill david@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --Bn2rw/3z4jIqBvZU Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iEYEARECAAYFAkvpWRgACgkQmprOCmdXAD1k5ACfXNBNcF0INlKobk2l1o0DIApM IhMAmQFQlJrqVS401Wlppwd2Vu8QP1Yi =TSWj -----END PGP SIGNATURE----- --Bn2rw/3z4jIqBvZU-- From owner-freebsd-current@FreeBSD.ORG Tue May 11 17:35:09 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 606041065675; Tue, 11 May 2010 17:35:09 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 1C4BB8FC0C; Tue, 11 May 2010 17:35:09 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 2ACEF1FFC51; Tue, 11 May 2010 17:35:08 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 6709D84495; Tue, 11 May 2010 19:33:00 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Ivan Voras References: <201005070036.o470a3pl044330@chez.mckusick.com> Date: Tue, 11 May 2010 19:33:00 +0200 In-Reply-To: (Ivan Voras's message of "Fri, 07 May 2010 11:20:56 +0200") Message-ID: <86d3x24a43.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.95 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: HEADS UP: 64-bit quotas going in to head today X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2010 17:35:09 -0000 Ivan Voras writes: > Just wondering - does the quota code have that much impact on the file > system that it's still today left out of the GENERIC kernel? It adds quite a bit of code to pretty much every UFS VOP. I haven't benchmarked or profiled it, so I have no idea how much it affects performance, but I suspect it's noticeable for disk-intensive workloads such as busy databases. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Tue May 11 18:46:19 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8F4AC106566C for ; Tue, 11 May 2010 18:46:19 +0000 (UTC) (envelope-from nox@jelal.kn-bremen.de) Received: from smtp.kn-bremen.de (gelbbaer.kn-bremen.de [78.46.108.116]) by mx1.freebsd.org (Postfix) with ESMTP id EA6F08FC1B for ; Tue, 11 May 2010 18:46:18 +0000 (UTC) Received: by smtp.kn-bremen.de (Postfix, from userid 10) id 869DA1E000E8; Tue, 11 May 2010 20:46:17 +0200 (CEST) Received: from triton8.kn-bremen.de (noident@localhost [127.0.0.1]) by triton8.kn-bremen.de (8.14.3/8.14.3) with ESMTP id o4BIffO2004545; Tue, 11 May 2010 20:41:41 +0200 (CEST) (envelope-from nox@triton8.kn-bremen.de) Received: (from nox@localhost) by triton8.kn-bremen.de (8.14.3/8.14.3/Submit) id o4BIffRv004544; Tue, 11 May 2010 20:41:41 +0200 (CEST) (envelope-from nox) From: Juergen Lock Date: Tue, 11 May 2010 20:41:41 +0200 To: freebsd-current@FreeBSD.org Message-ID: <20100511184140.GA3983@triton8.kn-bremen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Cc: yokota@FreeBSD.org Subject: [PATCH:] psm(4) IntelliMouse Explorer KVM hack breaks my mouse X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2010 18:46:19 -0000 (..and older vbox versions.) Hi! I just saw this vbox ticket: http://www.virtualbox.org/ticket/6488 (`Mouse wheel scrolling interpredted as click events in guest -> fixed after the 3.1.6 release') ..which sounded just like what a physical mouse I have (MS `IntelliMouse Optical 1.1A' according to whats printed on the bottom) did outside of a VM too, so I got curious and patched my psm driver to disable the KVM hack mentioned in that ticket which was introduced back in Apr 2000 by this commit: http://svn.freebsd.org/viewvc/base?view=revision&revision=58923 (`Add temporary workaround to fool some "clever" KVM switch products which think they know the IntelliMouse 4-byte packet and believe, wrongly, that any other protocols use 3-byte packets.') ..and indeed, now the stray click events are gone for me too! :) So now I made a patch that allows disabling that KVM hack via device hints, appended below. (hint.psm.0.flags="0x10000" - or do you guys think the hack should be disabled by default instead?) Cheers, Juergen Index: src/sys/dev/atkbdc/psm.c =================================================================== RCS file: /home/scvs/src/sys/dev/atkbdc/psm.c,v retrieving revision 1.104.2.2 diff -u -p -r1.104.2.2 psm.c --- src/sys/dev/atkbdc/psm.c 20 Aug 2009 20:23:28 -0000 1.104.2.2 +++ src/sys/dev/atkbdc/psm.c 11 May 2010 18:06:01 -0000 @@ -326,6 +326,7 @@ static devclass_t psm_devclass; #define PSM_CONFIG_HOOKRESUME 0x2000 /* hook the system resume event */ #define PSM_CONFIG_INITAFTERSUSPEND 0x4000 /* init the device at the resume event */ #define PSM_CONFIG_SYNCHACK 0x8000 /* enable `out-of-sync' hack */ +#define PSM_CONFIG_NOKVMHACK 0x10000 /* disable IntelliMouse Explorer KVM hack */ #define PSM_CONFIG_FLAGS \ (PSM_CONFIG_RESOLUTION | \ @@ -337,7 +338,8 @@ static devclass_t psm_devclass; PSM_CONFIG_FORCETAP | \ PSM_CONFIG_IGNPORTERROR | \ PSM_CONFIG_HOOKRESUME | \ - PSM_CONFIG_INITAFTERSUSPEND) + PSM_CONFIG_INITAFTERSUSPEND | \ + PSM_CONFIG_NOKVMHACK) /* other flags (flags) */ #define PSM_FLAGS_FINGERDOWN 0x0001 /* VersaPad finger down */ @@ -3779,20 +3781,23 @@ enable_msexplorer(struct psm_softc *sc) sc->hw.hwid = id; sc->hw.buttons = 5; /* IntelliMouse Explorer XXX */ - /* - * XXX: this is a kludge to fool some KVM switch products - * which think they are clever enough to know the 4-byte IntelliMouse - * protocol, and assume any other protocols use 3-byte packets. - * They don't convey 4-byte data packets from the IntelliMouse Explorer - * correctly to the host computer because of this! - * The following sequence is actually IntelliMouse's "wake up" - * sequence; it will make the KVM think the mouse is IntelliMouse - * when it is in fact IntelliMouse Explorer. - */ - for (i = 0; i < sizeof(rate0)/sizeof(rate0[0]); ++i) - if (set_mouse_sampling_rate(kbdc, rate0[i]) != rate0[i]) - break; - id = get_aux_id(kbdc); + if (!(sc->config & PSM_CONFIG_NOKVMHACK)) { + /* + * XXX: this is a kludge to fool some KVM switch products + * which think they are clever enough to know the 4-byte + * IntelliMouse protocol, and assume any other protocols + * use 3-byte packets. + * They don't convey 4-byte data packets from the IntelliMouse + * Explorer correctly to the host computer because of this! + * The following sequence is actually IntelliMouse's "wake up" + * sequence; it will make the KVM think the mouse is + * IntelliMouse when it is in fact IntelliMouse Explorer. + */ + for (i = 0; i < sizeof(rate0)/sizeof(rate0[0]); ++i) + if (set_mouse_sampling_rate(kbdc, rate0[i]) != rate0[i]) + break; + id = get_aux_id(kbdc); + } return (TRUE); } Index: src/share/man/man4/psm.4 =================================================================== RCS file: /home/scvs/src/share/man/man4/psm.4,v retrieving revision 1.49.2.1 diff -u -p -r1.49.2.1 psm.4 --- src/share/man/man4/psm.4 3 Aug 2009 08:13:06 -0000 1.49.2.1 +++ src/share/man/man4/psm.4 11 May 2010 18:04:16 -0000 @@ -349,6 +349,11 @@ after the `resume' event. It has no effect unless the .Em HOOKRESUME flag is set as well. +.It bit 16 NOKVMHACK +This flag disables the IntelliMouse Explorer protocol KVM switch +workaround that makes some virtual machine's mouse emulations as well +as at least one physical IntelliMouse Optical model misbehave +(causing the scroll wheel to produce stray click events.) .El .Sh LOADER TUNABLES Extended support for Synaptics touchpads can be enabled by setting From owner-freebsd-current@FreeBSD.ORG Tue May 11 19:31:39 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C72071065673 for ; Tue, 11 May 2010 19:31:39 +0000 (UTC) (envelope-from shuvaev@physik.uni-wuerzburg.de) Received: from mailrelay.rz.uni-wuerzburg.de (mailrelay.rz.uni-wuerzburg.de [132.187.3.28]) by mx1.freebsd.org (Postfix) with ESMTP id 48ED28FC1F for ; Tue, 11 May 2010 19:31:39 +0000 (UTC) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 2611621A73 for ; Tue, 11 May 2010 21:31:27 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 1F75749093 for ; Tue, 11 May 2010 21:31:27 +0200 (CEST) X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Received: from mail.physik.uni-wuerzburg.de (wthp192.physik.uni-wuerzburg.de [132.187.40.192]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id EFB265CFEB for ; Tue, 11 May 2010 21:31:26 +0200 (CEST) Received: from wep4035 ([132.187.37.35]) by mail.physik.uni-wuerzburg.de (Lotus Domino Release 8.5.1FP2HF71) with ESMTP id 2010051121312537-63123 ; Tue, 11 May 2010 21:31:25 +0200 Received: by wep4035 (sSMTP sendmail emulation); Tue, 11 May 2010 21:31:25 +0200 Date: Tue, 11 May 2010 21:31:25 +0200 From: Alexey Shuvaev To: freebsd-current@freebsd.org Message-ID: <20100511193125.GA59928@wep4035.physik.uni-wuerzburg.de> MIME-Version: 1.0 Organization: Universitaet Wuerzburg User-Agent: Mutt/1.5.20 (2009-06-14) X-MIMETrack: Itemize by SMTP Server on domino1/uni-wuerzburg(Release 8.5.1FP2HF71 | April 5, 2010) at 05/11/2010 09:31:26 PM, Serialize by Router on domino1/uni-wuerzburg(Release 8.5.1FP2HF71 | April 5, 2010) at 05/11/2010 09:31:26 PM, Serialize complete at 05/11/2010 09:31:26 PM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Addition of lzma/xz compression to HEAD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2010 19:31:40 -0000 Hello! Just FYI: noticed addition of lzma directory to BSD.include.dist mtree file. Well, now it seems to work! /* Test file size 264 MiB */ [wep4035] ~> ll /usr/local/tinderbox/jails/9-amd64/9-amd64.tar -rw-r--r-- 1 root wheel 277209600 Apr 20 20:58 /usr/local/tinderbox/jails/9-amd64/9-amd64.tar /* Cache file in memory */ [wep4035] ~> cat /usr/local/tinderbox/jails/9-amd64/9-amd64.tar > /dev/null /* 30 seconds to gzip it */ [wep4035] ~> time tar -cvzf 9-amd64.tar.tar.gz /usr/local/tinderbox/jails/9-amd64/9-amd64.tar tar: Removing leading '/' from member names a usr/local/tinderbox/jails/9-amd64/9-amd64.tar 30.043u 0.541s 0:15.32 199.6% 37+2093k 0+747io 0pf+0w /* 64 seconds to bzip2 it */ [wep4035] ~> time tar -cvjf 9-amd64.tar.tar.bz2 /usr/local/tinderbox/jails/9-amd64/9-amd64.tar tar: Removing leading '/' from member names a usr/local/tinderbox/jails/9-amd64/9-amd64.tar 63.454u 0.686s 0:32.09 199.8% 37+2108k 0+650io 1pf+0w /* And 140 seconds to xz it */ [wep4035] ~> time tar -cvJf 9-amd64.tar.tar.xz /usr/local/tinderbox/jails/9-amd64/9-amd64.tar tar: Removing leading '/' from member names a usr/local/tinderbox/jails/9-amd64/9-amd64.tar 277.625u 0.857s 2:19.26 199.9% 37+2092k 0+432io 0pf+0w /* Resulting sizes :)))) */ [wep4035] ~> ll 9-amd64.tar.tar.* -rw-r--r-- 1 lexx lexx 84830128 May 11 21:07 9-amd64.tar.tar.bz2 -rw-r--r-- 1 lexx lexx 97667581 May 11 21:07 9-amd64.tar.tar.gz -rw-r--r-- 1 lexx lexx 56366908 May 11 21:10 9-amd64.tar.tar.xz /* 3.5 seconds to gunzip the file (mostly IO-limited) */ [wep4035] ~> cat 9-amd64.tar.tar.gz > /dev/null [wep4035] ~> time tar -xvf 9-amd64.tar.tar.gz x usr/local/tinderbox/jails/9-amd64/9-amd64.tar 2.721u 0.747s 0:03.54 97.7% 42+2365k 3+2116io 0pf+0w [wep4035] ~> rm -R usr/ /* 18 seconds to bunzip2 it */ [wep4035] ~> cat 9-amd64.tar.tar.bz2 > /dev/null [wep4035] ~> time tar -xvf 9-amd64.tar.tar.bz2 x usr/local/tinderbox/jails/9-amd64/9-amd64.tar 18.136u 0.999s 0:09.59 199.3% 37+2110k 1+2116io 0pf+0w [wep4035] ~> rm -R usr/ /* And only 10 seconds to xzdec it */ [wep4035] ~> cat 9-amd64.tar.tar.xz > /dev/null [wep4035] ~> time tar -xvf 9-amd64.tar.tar.xz x usr/local/tinderbox/jails/9-amd64/9-amd64.tar 10.304u 0.771s 0:05.59 198.0% 38+2164k 3+2116io 0pf+0w [wep4035] ~> rm -R usr/ Thanks to all involved in bringing it to HEAD! Alexey. P.S. I'm not claiming any statistical validity of provided timings nor that the testing procedure is correct. It is just to show that tar in HEAD now works with lzma/xz compression. From owner-freebsd-current@FreeBSD.ORG Tue May 11 19:33:42 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5B0121065674; Tue, 11 May 2010 19:33:42 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id AE6378FC14; Tue, 11 May 2010 19:33:41 +0000 (UTC) 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 o4BJXkLq066153 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 May 2010 22:33:46 +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.4/8.14.4) with ESMTP id o4BJXXtx049191; Tue, 11 May 2010 22:33:33 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o4BJXXqw049190; Tue, 11 May 2010 22:33:33 +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, 11 May 2010 22:33:33 +0300 From: Kostik Belousov To: Dag-Erling Sm??rgrav Message-ID: <20100511193333.GW83316@deviant.kiev.zoral.com.ua> References: <201005070036.o470a3pl044330@chez.mckusick.com> <86d3x24a43.fsf@ds4.des.no> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="S5Rg6oz6PtEXgjQf" Content-Disposition: inline In-Reply-To: <86d3x24a43.fsf@ds4.des.no> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-2.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_50, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-current@freebsd.org, Ivan Voras Subject: Re: HEADS UP: 64-bit quotas going in to head today X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2010 19:33:42 -0000 --S5Rg6oz6PtEXgjQf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, May 11, 2010 at 07:33:00PM +0200, Dag-Erling Sm??rgrav wrote: > Ivan Voras writes: > > Just wondering - does the quota code have that much impact on the file > > system that it's still today left out of the GENERIC kernel? >=20 > It adds quite a bit of code to pretty much every UFS VOP. I haven't > benchmarked or profiled it, so I have no idea how much it affects > performance, but I suspect it's noticeable for disk-intensive workloads > such as busy databases. No, it does not. Essentially, it adds one or two function calls per vop that allocate or deallocate blocks or inodes, and the function bodies verify two array members and return if those are NULL. My assertion is that this overhead is negligible. I intended to move quota code to kern/vfs_quota.c, because it actually is fs-agnostic, and can be used by any fs that does block and inode-based allocation of some space. In particular, tmpfs could use it. After that, I planned to enable option QUOTA for GENERIC. Also please note that ufs_quota.c is compiled into the kernel unconditionally (or rather, conditional on option UFS), and only hooks are placed under #ifdef QUOTA. --S5Rg6oz6PtEXgjQf Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkvpsQwACgkQC3+MBN1Mb4h5jwCfaBfxgtZkDQHhT85sC/KqI4HH mQQAmwR9rCr7wDH1FiZdtIcGRk+UNVw5 =2vKm -----END PGP SIGNATURE----- --S5Rg6oz6PtEXgjQf-- From owner-freebsd-current@FreeBSD.ORG Tue May 11 20:13:57 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 423FF1065673 for ; Tue, 11 May 2010 20:13:57 +0000 (UTC) (envelope-from alexbestms@uni-muenster.de) Received: from SECMAIL.UNI-MUENSTER.DE (SECMAIL.UNI-MUENSTER.DE [128.176.192.141]) by mx1.freebsd.org (Postfix) with ESMTP id C11998FC1C for ; Tue, 11 May 2010 20:13:56 +0000 (UTC) Received: from mail-ew0-f224.google.com (mail-ew0-f224.google.com [209.85.219.224]) by SECMAIL.UNI-MUENSTER.DE (Postfix) with ESMTP id 103DDBF406 for ; Tue, 11 May 2010 22:13:53 +0200 (CEST) Received: by ewy24 with SMTP id 24so1499325ewy.13 for ; Tue, 11 May 2010 13:13:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.102.16.36 with SMTP id 36mr3705546mup.124.1273608832195; Tue, 11 May 2010 13:13:52 -0700 (PDT) Received: by 10.103.167.8 with HTTP; Tue, 11 May 2010 13:13:52 -0700 (PDT) In-Reply-To: <3a142e751003291708nc3e110bjca1789cc807f61a2@mail.gmail.com> References: <3a142e751003291708nc3e110bjca1789cc807f61a2@mail.gmail.com> Date: Tue, 11 May 2010 22:13:52 +0200 Message-ID: From: Alexander Best To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: fsck unable to read disk sectors X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2010 20:13:57 -0000 the problem is getting more awkward. if i do `fsck /dev/label/rootfs` fsck complains that it cannot read a specific sector of my hdd as i mentioned before. if i run fsck on the device node directly using `fsck /dev/ada0p3` however, fsck succeeds. what i did was to boot into single user mode with / being mounted read only. for some reason however fsck will check /dev/label/rootfs in write mode, but if i want fsck to check ada0p3 it will only do so in read mode. this looks like something is really broken. right now the only way to get the clean flag set on my hdd is to boot from a livefs cd and then run `fsck /dev/ada0p3` (again: `fsck /dev/label/rootfs` will NOT succeed). this is the output of `glabel status` btw: Name Status Components label/boot N/A ada0p1 gptid/e52df583-e446-11de-bb92-000fb58207c8 N/A ada0p1 label/swap N/A ada0p2 label/rootfs N/A ada0p3 cheers. On Tue, Mar 30, 2010 at 2:08 AM, Paul B Mahol wrote: > On 3/29/10, Alexander Best wrote: >> hi there, >> >> when doing fsck on my / fs i get this error: >> >> "Cannot Read BLK. 471617640" and "The Following Disk Sectors could not be >> read: 471617643". after this message the partition gets marked dirty. >> >> i performed the following steps to verify the problem: >> >> 1) dd if=/dev/ada0 of=/dev/null bs=1m >> 2) fsck / under freebsd 7 >> 3) mount -u -o snapshot /.snap/snapshot1 / && fsck_ffs /.snap/snapshot1 >> >> all three steps showed no problem with that harddrive whatsoever. also >> smartd >> doesn't complain about anything. >> >> i'm running HEAD (r205860) on amd64. >> >> this is the output of `dmesg -a|grep ada0`: >> >> ada0 at ahcich2 bus 0 scbus3 target 0 lun 0 >> ada0: ATA-7 SATA 2.x device >> ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) >> ada0: Command Queueing enabled >> ada0: 238474MB (488395055 512 byte sectors: 16H 63S/T 16383C) > > Last time I tried ahci on dead disk it did not complained at all > (usually I get dead LBA listed on console). > -- Alexander Best From owner-freebsd-current@FreeBSD.ORG Tue May 11 20:15:14 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D71E51065675 for ; Tue, 11 May 2010 20:15:14 +0000 (UTC) (envelope-from alexbestms@uni-muenster.de) Received: from SECMAIL.UNI-MUENSTER.DE (SECMAIL.UNI-MUENSTER.DE [128.176.192.141]) by mx1.freebsd.org (Postfix) with ESMTP id 5FC078FC21 for ; Tue, 11 May 2010 20:15:14 +0000 (UTC) Received: from mail-ew0-f224.google.com (mail-ew0-f224.google.com [209.85.219.224]) by SECMAIL.UNI-MUENSTER.DE (Postfix) with ESMTP id 9D5B1BF406 for ; Tue, 11 May 2010 22:15:13 +0200 (CEST) Received: by ewy24 with SMTP id 24so1499951ewy.13 for ; Tue, 11 May 2010 13:15:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.102.80.36 with SMTP id d36mr3723155mub.29.1273608913255; Tue, 11 May 2010 13:15:13 -0700 (PDT) Received: by 10.103.167.8 with HTTP; Tue, 11 May 2010 13:15:13 -0700 (PDT) In-Reply-To: References: <3a142e751003291708nc3e110bjca1789cc807f61a2@mail.gmail.com> Date: Tue, 11 May 2010 22:15:13 +0200 Message-ID: From: Alexander Best To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: fsck unable to read disk sectors X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2010 20:15:15 -0000 i've posted a log here which is pretty self explanatory: http://pastebin.com/tn3NiDDW On Tue, May 11, 2010 at 10:13 PM, Alexander Best wrote: > the problem is getting more awkward. > > if i do `fsck /dev/label/rootfs` fsck complains that it cannot read a > specific sector of my hdd as i mentioned before. if i run fsck on the > device node directly using `fsck /dev/ada0p3` however, fsck succeeds. > what i did was to boot into single user mode with / being mounted read > only. for some reason however fsck will check /dev/label/rootfs in > write mode, but if i want fsck to check ada0p3 it will only do so in > read mode. > > this looks like something is really broken. right now the only way to > get the clean flag set on my hdd is to boot from a livefs cd and then > run `fsck /dev/ada0p3` (again: `fsck /dev/label/rootfs` will NOT > succeed). > > this is the output of `glabel status` btw: > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 N= ame =A0Status =A0Components > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 label/boot = =A0 =A0 N/A =A0ada0p1 > gptid/e52df583-e446-11de-bb92-000fb58207c8 =A0 =A0 N/A =A0ada0p1 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 label/swap = =A0 =A0 N/A =A0ada0p2 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 label/rootfs =A0 = =A0 N/A =A0ada0p3 > > cheers. > > On Tue, Mar 30, 2010 at 2:08 AM, Paul B Mahol wrote: >> On 3/29/10, Alexander Best wrote: >>> hi there, >>> >>> when doing fsck on my / fs i get this error: >>> >>> "Cannot Read BLK. 471617640" and "The Following Disk Sectors could not = be >>> read: 471617643". after this message the partition gets marked dirty. >>> >>> i performed the following steps to verify the problem: >>> >>> 1) dd if=3D/dev/ada0 of=3D/dev/null bs=3D1m >>> 2) fsck / under freebsd 7 >>> 3) mount -u -o snapshot /.snap/snapshot1 / && fsck_ffs /.snap/snapshot1 >>> >>> all three steps showed no problem with that harddrive whatsoever. also >>> smartd >>> doesn't complain about anything. >>> >>> i'm running HEAD (r205860) on amd64. >>> >>> this is the output of `dmesg -a|grep ada0`: >>> >>> ada0 at ahcich2 bus 0 scbus3 target 0 lun 0 >>> ada0: ATA-7 SATA 2.x device >>> ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) >>> ada0: Command Queueing enabled >>> ada0: 238474MB (488395055 512 byte sectors: 16H 63S/T 16383C) >> >> Last time I tried ahci on dead disk it did not complained at all >> (usually I get dead LBA listed on console). >> > > > > -- > Alexander Best > --=20 Alexander Best From owner-freebsd-current@FreeBSD.ORG Tue May 11 23:56:33 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id ECFD2106566B for ; Tue, 11 May 2010 23:56:33 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [211.166.10.233]) by mx1.freebsd.org (Postfix) with ESMTP id 3384F8FC0C for ; Tue, 11 May 2010 23:56:32 +0000 (UTC) Received: from mail.geekcn.org (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id 2302BA6978A; Wed, 12 May 2010 07:38:19 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([211.166.10.233]) by mail.geekcn.org (mail.geekcn.org [211.166.10.233]) (amavisd-new, port 10024) with LMTP id j+qjkJMc6FDF; Wed, 12 May 2010 07:37:56 +0800 (CST) Received: from delta.delphij.net (drawbridge.ixsystems.com [206.40.55.65]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id BE7FAA69787; Wed, 12 May 2010 07:37:55 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:subject:x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=N0+BD4z3fv45rAXif3EMPQzRg0LB0BpSsaHEs1OoudO1xdAcwVsd+1+5Qwy2fM/Oo rGwhj0GKqLNN+zkBamSgQ== Message-ID: <4BE9EA4F.9010803@delphij.net> Date: Tue, 11 May 2010 16:37:51 -0700 From: Xin LI Organization: The Geek China Organization User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.9) Gecko/20100408 Thunderbird/3.0.4 ThunderBrowse/3.2.8.1 MIME-Version: 1.0 To: FreeBSD Current X-Enigmail-Version: 1.0.1 OpenPGP: id=3FCA37C1; url=http://www.delphij.net/delphij.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Subject: [mini headsup] updating from 7.x to -CURRENT after lzma import X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2010 23:56:34 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, The recent lzma import has enabled libarchive's lzma support. However, it have come to our attention that building -HEAD on earlier FreeBSD versions (specifically, 7.x after 700044 through 8.x before 800022) have been broken. The reason behind this is that 'make buildworld' will build a new ar(1) binary which links to libarchive, causing build to break on these systems. A hack-ish patch can be used to relieve this: http://people.freebsd.org/~delphij/for_review/patch-lzmabuild.diff Alternatively, one can update to 8-STABLE before jumping to 9-CURRENT. Another way to work around this is to build and install lzma static library before doing 'make buildworld': cd /usr/src make buildenv cd lib/liblzma make obj make depend make -DNO_PIC -DWITHOUT_PROFILE -DNO_SHARED all make -DNO_PIC -DWITHOUT_PROFILE -DNO_SHARED install We are working on a better solution for this and sorry for the breakage. Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iQEcBAEBAgAGBQJL6epPAAoJEATO+BI/yjfB37MIAJ+Xy9sftRRwdc1n61UDxeGd iy08OvhZesQltDOIaezFSET250HVtUG0Z+aenaxgMV8tzfRysK1FNdBozWCE0hbY cgyIy/bi1JOEP2F2qiFLyKIRtZSSoMJkMEegKEFlRC21rQBmWCRBK0zPrnq/sgTS qyLB83QrlJsH7tLS301ac0r8bK1TdvOc21EyXvtbmWa5fZjpJMrwwhcSevUgOAci DYixML6SMLcxai/kz3lAbUbxXiecm0tg9uUYQR7T94nCFpxde5tu8KMNx4jsoC8x cS2VdToswpCtIVc2PuTotl3A1WGMUFUM45KWk2UzBP40nn+r0G/cVpCgx/7BpzY= =nPLF -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Wed May 12 01:46:57 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2895D1065670 for ; Wed, 12 May 2010 01:46:57 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id A8C4D8FC13 for ; Wed, 12 May 2010 01:46:56 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id o4C1ksxD019779 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 12 May 2010 03:46:54 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by mail.cicely.de (8.14.3/8.14.3) with ESMTP id o4C1kpnL004704 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 May 2010 03:46:51 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id o4C1kpsT077659; Wed, 12 May 2010 03:46:51 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id o4C1kpjx077658; Wed, 12 May 2010 03:46:51 +0200 (CEST) (envelope-from ticso) Date: Wed, 12 May 2010 03:46:51 +0200 From: Bernd Walter To: Alexander Best Message-ID: <20100512014651.GN73283@cicely7.cicely.de> References: <3a142e751003291708nc3e110bjca1789cc807f61a2@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 autolearn=ham version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de Cc: freebsd-current@freebsd.org Subject: Re: fsck unable to read disk sectors X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 01:46:57 -0000 On Tue, May 11, 2010 at 10:15:13PM +0200, Alexander Best wrote: > i've posted a log here which is pretty self explanatory: > > http://pastebin.com/tn3NiDDW > > On Tue, May 11, 2010 at 10:13 PM, Alexander Best > wrote: > > the problem is getting more awkward. > > > > if i do `fsck /dev/label/rootfs` fsck complains that it cannot read a > > specific sector of my hdd as i mentioned before. if i run fsck on the > > device node directly using `fsck /dev/ada0p3` however, fsck succeeds. So this is not hardware it is bad partitioning. > > what i did was to boot into single user mode with / being mounted read > > only. for some reason however fsck will check /dev/label/rootfs in > > write mode, but if i want fsck to check ada0p3 it will only do so in > > read mode. > > > > this looks like something is really broken. right now the only way to > > get the clean flag set on my hdd is to boot from a livefs cd and then > > run `fsck /dev/ada0p3` (again: `fsck /dev/label/rootfs` will NOT > > succeed). One of the typical problems users have is that they forget that adding a label takes one sector, so the labeled device is smaller. This is no problem if you create the filesystem on the labeled drive, but often enough people add the label after creating the filesystem. Everything seems to work fine until the FS decides to use that special sector. I wouldn't add a label for ufs anyway, since UFS has labeling itself, which is also handled by glabel module and doesn't require extra space. Just setup the ufs label with tunefs -L and use the resulting /dev/ufs/... device. You only need extra label for swap, but this is not problem, since it has no persistent ondisk structures. > > this is the output of `glabel status` btw: > > > >                                     Name  Status  Components > >                               label/boot     N/A  ada0p1 > > gptid/e52df583-e446-11de-bb92-000fb58207c8     N/A  ada0p1 > >                               label/swap     N/A  ada0p2 > >                             label/rootfs     N/A  ada0p3 > > > > cheers. > > > > On Tue, Mar 30, 2010 at 2:08 AM, Paul B Mahol wrote: > >> On 3/29/10, Alexander Best wrote: > >>> hi there, > >>> > >>> when doing fsck on my / fs i get this error: > >>> > >>> "Cannot Read BLK. 471617640" and "The Following Disk Sectors could not be > >>> read: 471617643". after this message the partition gets marked dirty. > >>> > >>> i performed the following steps to verify the problem: > >>> > >>> 1) dd if=/dev/ada0 of=/dev/null bs=1m > >>> 2) fsck / under freebsd 7 > >>> 3) mount -u -o snapshot /.snap/snapshot1 / && fsck_ffs /.snap/snapshot1 > >>> > >>> all three steps showed no problem with that harddrive whatsoever. also > >>> smartd > >>> doesn't complain about anything. > >>> > >>> i'm running HEAD (r205860) on amd64. > >>> > >>> this is the output of `dmesg -a|grep ada0`: > >>> > >>> ada0 at ahcich2 bus 0 scbus3 target 0 lun 0 > >>> ada0: ATA-7 SATA 2.x device > >>> ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) > >>> ada0: Command Queueing enabled > >>> ada0: 238474MB (488395055 512 byte sectors: 16H 63S/T 16383C) > >> > >> Last time I tried ahci on dead disk it did not complained at all > >> (usually I get dead LBA listed on console). -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-current@FreeBSD.ORG Wed May 12 03:30:12 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7D6A21065672; Wed, 12 May 2010 03:30:12 +0000 (UTC) (envelope-from kmatthew.macy@gmail.com) Received: from mail-qy0-f190.google.com (mail-qy0-f190.google.com [209.85.221.190]) by mx1.freebsd.org (Postfix) with ESMTP id E9AEE8FC08; Wed, 12 May 2010 03:30:11 +0000 (UTC) Received: by qyk28 with SMTP id 28so838199qyk.27 for ; Tue, 11 May 2010 20:30:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:reply-to:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:content-type:content-transfer-encoding; bh=WQ8Iaq3+HefCaA1zY/q3J6J1e1CV41CNCF2OMBvBkCM=; b=NJA4tGKMKMTtXDSVioJDJOEhx52veuJUulwXQMxTjsiICOwyNvx0RfF43QrRRHphvO 91vOBYl8XBUY+MW7TWLwIAyj8x5xpKxGmq+jcKIp6NBB/AvuhfvTFZ2SViNF0qZYsx6c 2QMKN9gPw11vsjUpPSaR6GVsM+gnEKYpzVLhY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:reply-to:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; b=reVQ3uQDkp1ryqiiHRU4PMXdHTKU2XpAntSCq7jyhD8XBPQbN8qCxsguk2lxJQm6xQ PsNCdCoJmD02ItaPj6i7Q8L2LPL+L+swF6eASdGHd1LpH5dk4EqhUe0nDAKWmB0WFhtF Q2VQxaJiL3Mcp93e75M2q616JCgkROt80ZJEo= MIME-Version: 1.0 Received: by 10.229.241.80 with SMTP id ld16mr446214qcb.111.1273635009618; Tue, 11 May 2010 20:30:09 -0700 (PDT) Sender: kmatthew.macy@gmail.com Received: by 10.229.224.71 with HTTP; Tue, 11 May 2010 20:30:09 -0700 (PDT) In-Reply-To: <20100511131817.GB685@bunrab.catwhisker.org> References: <20100510140722.GD49209@bunrab.catwhisker.org> <20100510182243.GV56080@hoeg.nl> <20100510182625.GF49209@bunrab.catwhisker.org> <20100511131817.GB685@bunrab.catwhisker.org> Date: Tue, 11 May 2010 20:30:09 -0700 X-Google-Sender-Auth: 5WKnKOpa89Z6qtf0nntwbZu_OIY Message-ID: From: "K. Macy" To: David Wolfskill , "K. Macy" , Ed Schouten , current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: Panic @r207844; current process: flowcleaner "Fatal trap 12: page fault while in kernel mode" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: kmacy@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 03:30:12 -0000 Please try 207949 .... Thanks, Kip On Tue, May 11, 2010 at 6:18 AM, David Wolfskill wro= te: > On Mon, May 10, 2010 at 02:32:14PM -0700, K. Macy wrote: >> Could you please try with 207902? >> ... > > I saved that environment (documented elsewhere ini the thread), then > performed the normal (for me) daily update, this time, to r207911. > > Again, I see a panic during transition from single-user mode to > multi-user mode: > > ... > =A03 =A0Select option, [Enter] for default =A0 =A0 3 > =A03 =A0or [Space] to pause timer =A09 =A0 =A0 =A0 =A0 =A0 3 > =A0@DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY > > > GDB: no debug ports present > KDB: debugger backends: ddb > KDB: current backend: ddb > Copyright (c) 1992-2010 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > =A0 =A0 =A0 =A0The Regents of the University of California. All rights re= served. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 9.0-CURRENT #156 r207911: Tue May 11 05:55:18 PDT 2010 > =A0 =A0root@freebeast.catwhisker.org:/usr/obj/usr/src/sys/GENERIC i386 > WARNING: WITNESS option enabled, expect reduced performance. > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: Intel(R) Xeon(TM) CPU 3.60GHz (3614.55-MHz 686-class CPU) > =A0Origin =3D "GenuineIntel" =A0Id =3D 0xf41 =A0Family =3D f =A0Model =3D= 4 =A0Stepping =3D 1 > =A0Features=3D0xbfebfbff > =A0Features2=3D0x659d > =A0AMD Features=3D0x20100000 > =A0TSC: P-state invariant > real memory =A0=3D 2147483648 (2048 MB) > avail memory =3D 2086129664 (1989 MB) > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > FreeBSD/SMP: 2 package(s) x 1 core(s) > =A0cpu0 (BSP): APIC ID: =A00 > =A0cpu1 (AP): APIC ID: =A06 > ioapic0 irqs 0-23 on motherboard > ioapic1 irqs 24-47 on motherboard > ioapic2 irqs 48-71 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 0x1008-0x100b on acpi0 > cpu0: on acpi0 > cpu1: on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > pci0: at device 0.1 (no driver attached) > pci0: at device 1.0 (no driver attached) > pcib1: irq 16 at device 2.0 on pci0 > pci1: on pcib1 > pcib2: at device 0.0 on pci1 > pci2: on pcib2 > aac0: mem 0xdc000000-0xdfffffff irq 24 at devic= e 1.0 on pci2 > aac0: Enable Raw I/O > aac0: New comm. interface enabled > aac0: [ITHREAD] > aac0: Adaptec 2200S, aac driver 2.1.9-1 > aacp0: on aac0 > aacp1: on aac0 > pcib3: at device 0.2 on pci1 > pci3: on pcib3 > em0: port 0x2000-0x20= 3f mem 0xd8200000-0xd821ffff irq 54 at device 2.0 on pci3 > em0: [FILTER] > em0: Ethernet address: 00:30:48:2d:32:6a > em1: port 0x2040-0x20= 7f mem 0xd8220000-0xd823ffff irq 55 at device 2.1 on pci3 > em1: [FILTER] > em1: Ethernet address: 00:30:48:2d:32:6b > pcib4: irq 16 at device 4.0 on pci0 > pci4: on pcib4 > pcib5: irq 16 at device 6.0 on pci0 > pci5: on pcib5 > uhci0: port 0x1400-0x141f irq= 16 at device 29.0 on pci0 > uhci0: [ITHREAD] > usbus0: on uhci0 > uhci1: port 0x1420-0x143f irq= 19 at device 29.1 on pci0 > uhci1: [ITHREAD] > usbus1: on uhci1 > uhci2: port 0x1440-0x145f irq= 18 at device 29.2 on pci0 > uhci2: [ITHREAD] > usbus2: on uhci2 > uhci3: port 0x1460-0x147f irq= 16 at device 29.3 on pci0 > uhci3: [ITHREAD] > usbus3: on uhci3 > ehci0: mem 0xd8001000-0xd8001= 3ff irq 23 at device 29.7 on pci0 > ehci0: [ITHREAD] > usbus4: EHCI version 1.0 > usbus4: on ehci0 > pcib6: at device 30.0 on pci0 > pci6: on pcib6 > vgapci0: port 0x3000-0x30ff mem 0xd9000000-0xd9f= fffff,0xd8300000-0xd8300fff irq 17 at device 1.0 on pci6 > isab0: at device 31.0 on pci0 > isa0: on isab0 > atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x1= 77,0x376,0x14a0-0x14af at device 31.1 on pci0 > ata0: on atapci0 > ata0: [ITHREAD] > ata1: on atapci0 > ata1: [ITHREAD] > pci0: at device 31.3 (no driver attached) > acpi_button0: on acpi0 > atrtc0: port 0x70-0x77 irq 8 on acpi0 > atkbdc0: port 0x60,0x64 irq 1 on acpi0 > atkbd0: irq 1 on atkbdc0 > kbd0 at atkbd0 > atkbd0: [GIANT-LOCKED] > atkbd0: [ITHREAD] > psm0: irq 12 on atkbdc0 > psm0: [GIANT-LOCKED] > psm0: [ITHREAD] > psm0: model Generic PS/2 mouse, device ID 0 > uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 > uart0: [FILTER] > uart0: console (9600,n,8,1) > uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 > uart1: [FILTER] > fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acp= i0 > fdc0: [FILTER] > fd0: <1440-KB 3.5" drive> on fdc0 drive 0 > pmtimer0 on isa0 > orm0: at iomem 0xc0000-0xc7fff,0xc8000-0xc8fff,0xc9000-= 0xc9fff,0xca000-0xcafff,0xcb000-0xcf7ff pnpid ORM0000 on isa0 > sc0: at flags 0x100 on isa0 > sc0: VGA <16 virtual consoles, flags=3D0x300> > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > ppc0: parallel port not found. > est0: on cpu0 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 122d00000e24 > device_attach: est0 attach returned 6 > p4tcc0: on cpu0 > est1: on cpu1 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 122d00000e24 > device_attach: est1 attach returned 6 > p4tcc1: on cpu1 > Timecounters tick every 1.000 msec > usbus0: 12Mbps Full Speed USB v1.0 > usbus1: 12Mbps Full Speed USB v1.0 > usbus2: 12Mbps Full Speed USB v1.0 > usbus3: 12Mbps Full Speed USB v1.0 > usbus4: 480Mbps High Speed USB v2.0 > ata1: DMA limited to UDMA33, controller found non-ATA66 cable > ugen0.1: at usbus0 > uhub0: on usbus0 > ugen1.1: at usbus1 > uhub1: on usbus1 > ugen2.1: at usbus2 > uhub2: on usbus2 > ugen3.1: at usbus3 > uhub3: on usbus3 > ugen4.1: at usbus4 > uhub4: on usbus4 > acd0: DVDROM at ata1-slave UDMA33 > aacd0: on aac0 > aacd0: 34970MB (71619584 sectors) > aacd1: on aac0 > aacd1: 69974MB (143307008 sectors) > uhub0: 2 ports with 2 removable, self powered > uhub1: 2 ports with 2 removable, self powered > uhub2: 2 ports with 2 removable, self powered > uhub3: 2 ports with 2 removable, self powered > uhub4: 8 ports with 8 removable, self powered > ses0 at aacp0 bus 0 scbus0 target 6 lun 0 > ses0: Fixed Uninstalled SCSI-2 device > ses0: 3.300MB/s transfers > ses0: SAF-TE Compliant Device > pass0 at aacp0 bus 0 scbus0 target 0 lun 0 > pass0: Fixed Uninstalled SCSI-3 device > pass0: 3.300MB/s transfers > pass1 at aacp0 bus 0 scbus0 target 1 lun 0 > pass1: Fixed Uninstalled SCSI-3 device > pass1: 3.300MB/s transfers > pass2 at aacp0 bus 0 scbus0 target 2 lun 0 > pass2: Fixed Uninstalled SCSI-3 device > pass2: 3.300MB/s transfers > pass3 at aacp0 bus 0 scbus0 target 3 lun 0 > pass3: Fixed Uninstalled SCSI-3 device > pass3: 3.300MB/s transfers > SMP: AP CPU #1 Launched! > WARNING: WITNESS option enabled, expect reduced performance. > Trying to mount root from ufs:/dev/aacd0s4a > Setting hostuuid: 80f1e964-dc63-0010-89d5-0030482d326a. > Setting hostid: 0xc74551dd. > Entropy harvesting: interrupts ethernet point_to_point kickstart. > Starting file system checks: > /dev/aacd0s4a: FILE SYSTEM CLEAN; SKIPPING CHECKS > /dev/aacd0s4a: clean, 344803 free (2027 frags, 42847 blocks, 0.3% fragmen= tation) > /dev/aacd1s1e: FILE SYSTEM CLEAN; SKIPPING CHECKS > /dev/aacd1s1e: clean, 4753395 free (263851 frags, 561193 blocks, 2.0% fra= gmentation) > /dev/aacd0s1a: FILE SYSTEM CLEAN; SKIPPING CHECKS > /dev/aacd0s1a: clean, 422042 free (682 frags, 52670 blocks, 0.1% fragment= ation) > /dev/aacd0s1d: FILE SYSTEM CLEAN; SKIPPING CHECKS > /dev/aacd0s1d: clean, 1076253 free (237 frags, 134502 blocks, 0.0% fragme= ntation) > /dev/aacd1s1d: FILE SYSTEM CLEAN; SKIPPING CHECKS > /dev/aacd1s1d: clean, 11714543 free (199151 frags, 1439424 blocks, 1.2% f= ragmentation) > /dev/aacd0s2a: FILE SYSTEM CLEAN; SKIPPING CHECKS > /dev/aacd0s2a: clean, 596264 free (1144 frags, 74390 blocks, 0.2% fragmen= tation) > /dev/aacd0s2d: FILE SYSTEM CLEAN; SKIPPING CHECKS > /dev/aacd0s2d: clean, 1108483 free (24155 frags, 135541 blocks, 1.3% frag= mentation) > /dev/aacd0s3a: FILE SYSTEM CLEAN; SKIPPING CHECKS > /dev/aacd0s3a: clean, 578034 free (1186 frags, 72106 blocks, 0.2% fragmen= tation) > /dev/aacd0s3d: FILE SYSTEM CLEAN; SKIPPING CHECKS > /dev/aacd0s3d: clean, 1070803 free (41819 frags, 128623 blocks, 2.3% frag= mentation) > /dev/aacd0s4d: FILE SYSTEM CLEAN; SKIPPING CHECKS > /dev/aacd0s4d: clean, 1075758 free (60510 frags, 126906 blocks, 3.4% frag= mentation) > /dev/aacd0s4f: FILE SYSTEM CLEAN; SKIPPING CHECKS > /dev/aacd0s4f: clean, 2071008 free (368 frags, 258830 blocks, 0.0% fragme= ntation) > Mounting local file systems:. > Setting hostname: freebeast.catwhisker.org. > lock order reversal: > =A01st 0xc684b6b8 ufs (ufs) @ /usr/src/sys/kern/vfs_lookup.c:502 > =A02nd 0xd94fe304 bufwait (bufwait) @ /usr/src/sys/ufs/ffs/ffs_softdep.c:= 11363 > =A03rd 0xc6875168 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2091 > KDB: stack backtrace: > db_trace_self_wrapper(c0cc7405,ebe3d300,c08ea0d5,c08da44b,c0cca3f8,...) a= t db_trace_self_wrapper+0x26 > kdb_backtrace(c08da44b,c0cca3f8,c553d030,c5540568,ebe3d35c,...) at kdb_ba= cktrace+0x29 > _witness_debugger(c0cca3f8,c6875168,c0cbc71d,c5540568,c0cd1511,...) at _w= itness_debugger+0x25 > witness_checkorder(c6875168,9,c0cd1511,82b,0,...) at witness_checkorder+0= x839 > __lockmgr_args(c6875168,80100,c6875188,0,0,...) at __lockmgr_args+0x7f9 > ffs_lock(ebe3d480,c08e9e7b,c0cd09b6,80100,c6875110,...) at ffs_lock+0x8a > VOP_LOCK1_APV(c0dd5040,ebe3d480,c6868cd4,c0defa80,c6875110,...) at VOP_LO= CK1_APV+0xb5 > _vn_lock(c6875110,80100,c0cd1511,82b,4,...) at _vn_lock+0x5e > vget(c6875110,80100,c6868c30,50,0,...) at vget+0xb9 > vfs_hash_get(c6846ca8,78c22,80000,c6868c30,ebe3d5d0,...) at vfs_hash_get+= 0xe6 > ffs_vgetf(c6846ca8,78c22,80000,ebe3d5d0,1,...) at ffs_vgetf+0x49 > softdep_sync_metadata(c684b660,0,c0ced758,144,0,...) at softdep_sync_meta= data+0xc92 > ffs_syncvnode(c684b660,1,c6868c30,ebe3d690,246,...) at ffs_syncvnode+0x3e= 2 > ffs_truncate(c684b660,200,0,880,c5588480,...) at ffs_truncate+0x862 > ufs_direnter(c684b660,c6875110,ebe3d944,ebe3dbd4,0,...) at ufs_direnter+0= x8d4 > ufs_makeinode(ebe3dbd4,0,ebe3db30,ebe3da8c,c0c03435,...) at ufs_makeinode= +0x557 > ufs_create(ebe3db30,ebe3db48,0,0,ebe3dba8,...) at ufs_create+0x30 > VOP_CREATE_APV(c0dd5040,ebe3db30,ebe3dbd4,ebe3dac8,0,...) at VOP_CREATE_A= PV+0xa5 > vn_open_cred(ebe3dba8,ebe3dc5c,1a4,0,c5588480,...) at vn_open_cred+0x215 > vn_open(ebe3dba8,ebe3dc5c,1a4,c637e380,0,...) at vn_open+0x3b > kern_openat(c6868c30,ffffff9c,804c5e8,0,602,...) at kern_openat+0x125 > kern_open(c6868c30,804c5e8,0,601,21b6,...) at kern_open+0x35 > open(c6868c30,ebe3dcf8,c0cfff5b,c0caa834,c63cbaa0,...) at open+0x30 > syscall(ebe3dd38) at syscall+0x220 > Xint0x80_syscall() at Xint0x80_syscall+0x20 > --- syscall (5, FreeBSD ELF32, open), eip =3D 0x281744b3, esp =3D 0xbfbfe= c4c, ebp =3D 0xbfbfecb8 --- > Starting Network: lo0 em0 em1. > lo0: flags=3D8049 metric 0 mtu 16384 > =A0 =A0 =A0 =A0options=3D3 > =A0 =A0 =A0 =A0inet 127.0.0.1 netmask 0xff000000 > =A0 =A0 =A0 =A0inet6 ::1 prefixlen 128 > =A0 =A0 =A0 =A0inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 > =A0 =A0 =A0 =A0nd6 options=3D21 > em0: flags=3D8843 metric 0 mtu 15= 00 > =A0 =A0 =A0 =A0options=3D289b > =A0 =A0 =A0 =A0ether 00:30:48:2d:32:6a > =A0 =A0 =A0 =A0inet 172.16.8.10 netmask 0xffffff00 broadcast 172.16.8.255 > =A0 =A0 =A0 =A0inet6 fe80::230:48ff:fe2d:326a%em0 prefixlen 64 tentative = scopeid 0x1 > =A0 =A0 =A0 =A0nd6 options=3D29 > =A0 =A0 =A0 =A0media: Ethernet autoselect > =A0 =A0 =A0 =A0status: no carrier > em1: flags=3D8802 metric 0 mtu 1500 > =A0 =A0 =A0 =A0options=3D389b > =A0 =A0 =A0 =A0ether 00:30:48:2d:32:6b > =A0 =A0 =A0 =A0media: Ethernet autoselect > =A0 =A0 =A0 =A0status: no carrier > Starting devd. > Starting Network: em1. > em1: flags=3D8802 metric 0 mtu 1500 > =A0 =A0 =A0 =A0options=3D389b > =A0 =A0 =A0 =A0ether 00:30:48:2d:32:6b > =A0 =A0 =A0 =A0media: Ethernet autoselect > =A0 =A0 =A0 =A0status: no carrier > add net default: gateway 172.16.8.1 > add net ::ffff:0.0.0.0: gateway ::1 > add net ::0.0.0.0: gateway ::1 > add net fe80::: gateway ::1 > add net ff02::: gateway ::1 > ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib /usr/loca= l/lib/compat > a.out ldconfig path: /usr/lib/aout /usr/lib/compat/aout > Creating and/or trimming log files. > Starting syslogd. > No core dumps found. > Starting rpcKernel page fault with the following non-sleepable locks held= : > exclusive sleep mutex mld_mtx (mld_mtx) r =3D 0 (0xc0f965e8) locked @ /us= r/src/sys/netinet6/mld6.c:1352 > exclusive sleep mutex in6_multi_mtx (in6_multi_mtx) r =3D 0 (0xc0f95588) = locked @ /usr/src/sys/netinet6/mld6.c:1351 > KDB: stack backtrace: > db_trace_self_wrapper(c0cc7405,c5213864,c08ea0d5,c0ce3f67,547,...) at db_= trace_self_wrapper+0x26 > kdb_backtrace(c0ce3f67,547,ffffffff,c0f65a94,c521389c,...) at kdb_backtra= ce+0x29 > _witness_debugger(c0cc998b,c52138b0,4,1,0,...) at _witness_debugger+0x25 > witness_warn(5,0,c0d00028,c55810a4,c557f7f8,...) at witness_warn+0x1fd > trap(c521393c) at trap+0x19e > calltrap() at calltrap+0x6 > --- trap 0xc, eip =3D 0xc0a4d4b0, esp =3D 0xc521397c, ebp =3D 0xc5213b14 = --- > ip6_output(c6938600,c0f96620,0,1,c5213b44,...) at ip6_output+0x840 > mld_dispatch_packet(0,0,c5213c1c,c0a50b17,c56fca2c,...) at mld_dispatch_p= acket+0x30d > mld_dispatch_queue(c56fca2c,0,c0ce3f67,591,c0cbbae4,...) at mld_dispatch_= queue+0x38 > mld_fasttimo(c5213c48,c0904e39,c5213c48,c0893c14,c0e25100,...) at mld_fas= ttimo+0x747 > icmp6_fasttimo(c5213c48,c0893c14,c0e25100,4,c0cc2636,...) at icmp6_fastti= mo+0x8 > pffasttimo(0,0,c0cc5273,189,c0e25138,...) at pffasttimo+0x29 > softclock(c0e25100,c5213cc8,c0893c14,c0e29140,c5588838,...) at softclock+= 0x24a > intr_event_execute_handlers(c557f7f8,c5588800,c0cbf49f,533,c5588870,...) = at intr_event_execute_handlers+0x125 > ithread_loop(c557e120,c5213d38,c0cbf218,343,c557f7f8,...) at ithread_loop= +0x9f > fork_exit(c087c8f0,c557e120,c5213d38) at fork_exit+0xb8 > fork_trampoline() at fork_trampoline+0x8 > --- trap 0, eip =3D 0, esp =3D 0xc5213d70, ebp =3D 0 --- > > > Fatal trap 12: page fault while in kernel mode > cpuid =3D 1; apic id =3D 06 > fault virtual address =A0 =3D 0x3c > fault code =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D supervisor read, page not prese= nt > instruction pointer =A0 =A0 =3D 0x20:0xc0a4d4b0 > stack pointer =A0 =A0 =A0 =A0 =A0 =3D 0x28:0xc521397c > frame pointer =A0 =A0 =A0 =A0 =A0 =3D 0x28:0xc5213b14 > code segment =A0 =A0 =A0 =A0 =A0 =A0=3D base 0x0, limit 0xfffff, type 0x1= b > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D DPL 0, pres 1, def32 1= , gran 1 > processor eflags =A0 =A0 =A0 =A0=3D interrupt enabled, resume, IOPL =3D 0 > current process =A0 =A0 =A0 =A0 =3D 12 (swi4: clock) > [ thread pid 12 tid 100007 ] > Stopped at =A0 =A0 =A0ip6_output+0x840: =A0 =A0 =A0 movl =A0 =A00x3c(%eax= ),%eax > db> bt > Tracing pid 12 tid 100007 td 0xc5581000 > ip6_output(c6938600,c0f96620,0,1,c5213b44,...) at ip6_output+0x840 > mld_dispatch_packet(0,0,c5213c1c,c0a50b17,c56fca2c,...) at mld_dispatch_p= acket+0x30d > mld_dispatch_queue(c56fca2c,0,c0ce3f67,591,c0cbbae4,...) at mld_dispatch_= queue+0x38 > mld_fasttimo(c5213c48,c0904e39,c5213c48,c0893c14,c0e25100,...) at mld_fas= ttimo+0x747 > icmp6_fasttimo(c5213c48,c0893c14,c0e25100,4,c0cc2636,...) at icmp6_fastti= mo+0x8 > pffasttimo(0,0,c0cc5273,189,c0e25138,...) at pffasttimo+0x29 > softclock(c0e25100,c5213cc8,c0893c14,c0e29140,c5588838,...) at softclock+= 0x24a > intr_event_execute_handlers(c557f7f8,c5588800,c0cbf49f,533,c5588870,...) = at intr_event_execute_handlers+0x125 > ithread_loop(c557e120,c5213d38,c0cbf218,343,c557f7f8,...) at ithread_loop= +0x9f > fork_exit(c087c8f0,c557e120,c5213d38) at fork_exit+0xb8 > fork_trampoline() at fork_trampoline+0x8 > --- trap 0, eip =3D 0, esp =3D 0xc5213d70, ebp =3D 0 --- > db> > > Again, I'll leave it in this state so folks can suggest other > information or patches to try. > > Peace, > david > -- > David H. Wolfskill =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0david@catwhisker.org > Depriving a girl or boy of an opportunity for education is evil. > > See http://www.catwhisker.org/~david/publickey.gpg for my public key. > From owner-freebsd-current@FreeBSD.ORG Wed May 12 04:22:04 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 227A51065670 for ; Wed, 12 May 2010 04:22:04 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 948EF8FC0A for ; Wed, 12 May 2010 04:22:02 +0000 (UTC) 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 o4C4LqA3006235 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 May 2010 07:21:52 +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.4/8.14.4) with ESMTP id o4C4Ldub052297; Wed, 12 May 2010 07:21:39 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o4C4LdkH052296; Wed, 12 May 2010 07:21:39 +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: Wed, 12 May 2010 07:21:39 +0300 From: Kostik Belousov To: d@delphij.net Message-ID: <20100512042139.GZ83316@deviant.kiev.zoral.com.ua> References: <4BE9EA4F.9010803@delphij.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6ysXqiu0yoUmUNJB" Content-Disposition: inline In-Reply-To: <4BE9EA4F.9010803@delphij.net> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-2.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_50, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: FreeBSD Current Subject: Re: [mini headsup] updating from 7.x to -CURRENT after lzma import X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 04:22:04 -0000 --6ysXqiu0yoUmUNJB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, May 11, 2010 at 04:37:51PM -0700, Xin LI wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > Hi, >=20 > The recent lzma import has enabled libarchive's lzma support. However, > it have come to our attention that building -HEAD on earlier FreeBSD > versions (specifically, 7.x after 700044 through 8.x before 800022) have > been broken. >=20 > The reason behind this is that 'make buildworld' will build a new ar(1) > binary which links to libarchive, causing build to break on these systems. >=20 > A hack-ish patch can be used to relieve this: >=20 > http://people.freebsd.org/~delphij/for_review/patch-lzmabuild.diff >=20 > Alternatively, one can update to 8-STABLE before jumping to 9-CURRENT. >=20 > Another way to work around this is to build and install lzma static > library before doing 'make buildworld': >=20 > cd /usr/src > make buildenv > cd lib/liblzma > make obj > make depend > make -DNO_PIC -DWITHOUT_PROFILE -DNO_SHARED all > make -DNO_PIC -DWITHOUT_PROFILE -DNO_SHARED install >=20 > We are working on a better solution for this and sorry for the breakage. The project policy is to require at least recent STABLE_(X-1) to build HEAD. The heads up is good thing, but functionality "broken" is only provided on best effort basis. --6ysXqiu0yoUmUNJB Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkvqLNIACgkQC3+MBN1Mb4hH5gCePZTZGLlWMeJ2DiyJWXre8y6b YhcAoMAs3dOMrvvAtEyyL84R4UKojFrd =9E87 -----END PGP SIGNATURE----- --6ysXqiu0yoUmUNJB-- From owner-freebsd-current@FreeBSD.ORG Wed May 12 04:24:35 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BAB2F106566C; Wed, 12 May 2010 04:24:35 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from bunrab.catwhisker.org (adsl-63-193-123-122.dsl.snfc21.pacbell.net [63.193.123.122]) by mx1.freebsd.org (Postfix) with ESMTP id 423438FC0C; Wed, 12 May 2010 04:24:34 +0000 (UTC) Received: from bunrab.catwhisker.org (localhost [127.0.0.1]) by bunrab.catwhisker.org (8.13.3/8.13.3) with ESMTP id o4C4OUdl004872; Tue, 11 May 2010 21:24:30 -0700 (PDT) (envelope-from david@bunrab.catwhisker.org) Received: (from david@localhost) by bunrab.catwhisker.org (8.13.3/8.13.3/Submit) id o4C4OUCx004871; Tue, 11 May 2010 21:24:30 -0700 (PDT) (envelope-from david) Date: Tue, 11 May 2010 21:24:30 -0700 From: David Wolfskill To: "K. Macy" Message-ID: <20100512042430.GH685@bunrab.catwhisker.org> Mail-Followup-To: David Wolfskill , "K. Macy" , Ed Schouten , current@freebsd.org References: <20100510140722.GD49209@bunrab.catwhisker.org> <20100510182243.GV56080@hoeg.nl> <20100510182625.GF49209@bunrab.catwhisker.org> <20100511131817.GB685@bunrab.catwhisker.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="NzX0AQGjRQPusK/O" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: Ed Schouten , current@freebsd.org Subject: Re: Panic @r207844; current process: flowcleaner "Fatal trap 12: page fault while in kernel mode" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 04:24:35 -0000 --NzX0AQGjRQPusK/O Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, May 11, 2010 at 08:30:09PM -0700, K. Macy wrote: > Please try 207949 .... > ... The panic (this time) didn't show up until about 10 seconds after the login: prompt showed up on the serial console. Here's what it looks like: =2E.. 3 Select option, [Enter] for default 3 3 or [Space] to pause timer 9 3 @DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2010 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 9.0-CURRENT #157 r207911M: Tue May 11 20:54:25 PDT 2010 root@freebeast.catwhisker.org:/usr/obj/usr/src/sys/GENERIC i386 WARNING: WITNESS option enabled, expect reduced performance. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(TM) CPU 3.60GHz (3614.55-MHz 686-class CPU) Origin =3D "GenuineIntel" Id =3D 0xf41 Family =3D f Model =3D 4 Stepp= ing =3D 1 Features=3D0xbfebfbff Features2=3D0x659d AMD Features=3D0x20100000 TSC: P-state invariant real memory =3D 2147483648 (2048 MB) avail memory =3D 2086129664 (1989 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 2 package(s) x 1 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 6 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-47 on motherboard ioapic2 irqs 48-71 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 0x1008-0x100b on acpi0 cpu0: on acpi0 cpu1: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: at device 0.1 (no driver attached) pci0: at device 1.0 (no driver attached) pcib1: irq 16 at device 2.0 on pci0 pci1: on pcib1 pcib2: at device 0.0 on pci1 pci2: on pcib2 aac0: mem 0xdc000000-0xdfffffff irq 24 at device = 1.0 on pci2 aac0: Enable Raw I/O aac0: New comm. interface enabled aac0: [ITHREAD] aac0: Adaptec 2200S, aac driver 2.1.9-1 aacp0: on aac0 aacp1: on aac0 pcib3: at device 0.2 on pci1 pci3: on pcib3 em0: port 0x2000-0x203f= mem 0xd8200000-0xd821ffff irq 54 at device 2.0 on pci3 em0: [FILTER] em0: Ethernet address: 00:30:48:2d:32:6a em1: port 0x2040-0x207f= mem 0xd8220000-0xd823ffff irq 55 at device 2.1 on pci3 em1: [FILTER] em1: Ethernet address: 00:30:48:2d:32:6b pcib4: irq 16 at device 4.0 on pci0 pci4: on pcib4 pcib5: irq 16 at device 6.0 on pci0 pci5: on pcib5 uhci0: port 0x1400-0x141f irq 1= 6 at device 29.0 on pci0 uhci0: [ITHREAD] usbus0: on uhci0 uhci1: port 0x1420-0x143f irq 1= 9 at device 29.1 on pci0 uhci1: [ITHREAD] usbus1: on uhci1 uhci2: port 0x1440-0x145f irq 1= 8 at device 29.2 on pci0 uhci2: [ITHREAD] usbus2: on uhci2 uhci3: port 0x1460-0x147f irq 1= 6 at device 29.3 on pci0 uhci3: [ITHREAD] usbus3: on uhci3 ehci0: mem 0xd8001000-0xd80013f= f irq 23 at device 29.7 on pci0 ehci0: [ITHREAD] usbus4: EHCI version 1.0 usbus4: on ehci0 pcib6: at device 30.0 on pci0 pci6: on pcib6 vgapci0: port 0x3000-0x30ff mem 0xd9000000-0xd9fff= fff,0xd8300000-0xd8300fff irq 17 at device 1.0 on pci6 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177= ,0x376,0x14a0-0x14af at device 31.1 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] pci0: at device 31.3 (no driver attached) acpi_button0: on acpi0 atrtc0: port 0x70-0x77 irq 8 on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model Generic PS/2 mouse, device ID 0 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart0: [FILTER] uart0: console (9600,n,8,1) uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 uart1: [FILTER] fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FILTER] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 pmtimer0 on isa0 orm0: at iomem 0xc0000-0xc7fff,0xc8000-0xc8fff,0xc9000-0x= c9fff,0xca000-0xcafff,0xcb000-0xcf7ff pnpid ORM0000 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=3D0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ppc0: parallel port not found. est0: on cpu0 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 122d00000e24 device_attach: est0 attach returned 6 p4tcc0: on cpu0 est1: on cpu1 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 122d00000e24 device_attach: est1 attach returned 6 p4tcc1: on cpu1 Timecounters tick every 1.000 msec usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 12Mbps Full Speed USB v1.0 usbus4: 480Mbps High Speed USB v2.0 ata1: DMA limited to UDMA33, controller found non-ATA66 cable ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 ugen4.1: at usbus4 uhub4: on usbus4 acd0: DVDROM at ata1-slave UDMA33=20 aacd0: on aac0 aacd0: 34970MB (71619584 sectors) aacd1: on aac0 aacd1: 69974MB (143307008 sectors) uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered uhub3: 2 ports with 2 removable, self powered uhub4: 8 ports with 8 removable, self powered ses0 at aacp0 bus 0 scbus0 target 6 lun 0 ses0: Fixed Uninstalled SCSI-2 device=20 ses0: 3.300MB/s transfers ses0: SAF-TE Compliant Device pass0 at aacp0 bus 0 scbus0 target 0 lun 0 pass0: Fixed Uninstalled SCSI-3 device=20 pass0: 3.300MB/s transfers pass1 at aacp0 bus 0 scbus0 target 1 lun 0 pass1: Fixed Uninstalled SCSI-3 device=20 pass1: 3.300MB/s transfers pass2 at aacp0 bus 0 scbus0 target 2 lun 0 pass2: Fixed Uninstalled SCSI-3 device=20 pass2: 3.300MB/s transfers pass3 at aacp0 bus 0 scbus0 target 3 lun 0 pass3: Fixed Uninstalled SCSI-3 device=20 pass3: 3.300MB/s transfers SMP: AP CPU #1 Launched! WARNING: WITNESS option enabled, expect reduced performance. Trying to mount root from ufs:/dev/aacd0s4a Setting hostuuid: 80f1e964-dc63-0010-89d5-0030482d326a. Setting hostid: 0xc74551dd. Entropy harvesting: interrupts ethernet point_to_point kickstart. Starting file system checks: /dev/aacd0s4a: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/aacd0s4a: clean, 267641 free (2161 frags, 33185 blocks, 0.3% fragmenta= tion) /dev/aacd1s1e: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/aacd1s1e: clean, 4751807 free (262119 frags, 561211 blocks, 2.0% fragm= entation) /dev/aacd0s1a: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/aacd0s1a: clean, 422042 free (682 frags, 52670 blocks, 0.1% fragmentat= ion) /dev/aacd0s1d: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/aacd0s1d: clean, 1076253 free (237 frags, 134502 blocks, 0.0% fragment= ation) /dev/aacd1s1d: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/aacd1s1d: clean, 11714564 free (199148 frags, 1439427 blocks, 1.2% fra= gmentation) /dev/aacd0s2a: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/aacd0s2a: clean, 596264 free (1144 frags, 74390 blocks, 0.2% fragmenta= tion) /dev/aacd0s2d: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/aacd0s2d: clean, 1108504 free (24176 frags, 135541 blocks, 1.3% fragme= ntation) /dev/aacd0s3a: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/aacd0s3a: clean, 578034 free (1186 frags, 72106 blocks, 0.2% fragmenta= tion) /dev/aacd0s3d: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/aacd0s3d: clean, 1070824 free (41840 frags, 128623 blocks, 2.3% fragme= ntation) /dev/aacd0s4d: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/aacd0s4d: clean, 1075779 free (60523 frags, 126907 blocks, 3.4% fragme= ntation) /dev/aacd0s4f: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/aacd0s4f: clean, 2071045 free (357 frags, 258836 blocks, 0.0% fragment= ation) Mounting local file systems:. Setting hostname: freebeast.catwhisker.org. lock order reversal: 1st 0xc68406b8 ufs (ufs) @ /usr/src/sys/kern/vfs_lookup.c:502 2nd 0xd94fe304 bufwait (bufwait) @ /usr/src/sys/ufs/ffs/ffs_softdep.c:11363 3rd 0xc6867af8 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2091 KDB: stack backtrace: db_trace_self_wrapper(c0cc73e5,ebe22300,c08ea0d5,c08da44b,c0cca3d8,...) at = db_trace_self_wrapper+0x26 kdb_backtrace(c08da44b,c0cca3d8,c553d030,c5540568,ebe2235c,...) at kdb_back= trace+0x29 _witness_debugger(c0cca3d8,c6867af8,c0cbc6fd,c5540568,c0cd14f1,...) at _wit= ness_debugger+0x25 witness_checkorder(c6867af8,9,c0cd14f1,82b,0,...) at witness_checkorder+0x8= 39 __lockmgr_args(c6867af8,80100,c6867b18,0,0,...) at __lockmgr_args+0x7f9 ffs_lock(ebe22480,c08e9e7b,c0cd0996,80100,c6867aa0,...) at ffs_lock+0x8a VOP_LOCK1_APV(c0dd5020,ebe22480,c638e0a4,c0defa60,c6867aa0,...) at VOP_LOCK= 1_APV+0xb5 _vn_lock(c6867aa0,80100,c0cd14f1,82b,4,...) at _vn_lock+0x5e vget(c6867aa0,80100,c638e000,50,0,...) at vget+0xb9 vfs_hash_get(c6848ca8,78c22,80000,c638e000,ebe225d0,...) at vfs_hash_get+0x= e6 ffs_vgetf(c6848ca8,78c22,80000,ebe225d0,1,...) at ffs_vgetf+0x49 softdep_sync_metadata(c6840660,0,c0ced738,144,0,...) at softdep_sync_metada= ta+0xc92 ffs_syncvnode(c6840660,1,c638e000,ebe22690,246,...) at ffs_syncvnode+0x3e2 ffs_truncate(c6840660,200,0,880,c5588480,...) at ffs_truncate+0x862 ufs_direnter(c6840660,c6867aa0,ebe22944,ebe22bd4,0,...) at ufs_direnter+0x8= d4 ufs_makeinode(ebe22bd4,0,ebe22b30,ebe22a8c,c0c03425,...) at ufs_makeinode+0= x557 ufs_create(ebe22b30,ebe22b48,0,0,ebe22ba8,...) at ufs_create+0x30 VOP_CREATE_APV(c0dd5020,ebe22b30,ebe22bd4,ebe22ac8,0,...) at VOP_CREATE_APV= +0xa5 vn_open_cred(ebe22ba8,ebe22c5c,1a4,0,c5588480,...) at vn_open_cred+0x215 vn_open(ebe22ba8,ebe22c5c,1a4,c637e770,0,...) at vn_open+0x3b kern_openat(c638e000,ffffff9c,804c5e8,0,602,...) at kern_openat+0x125 kern_open(c638e000,804c5e8,0,601,21b6,...) at kern_open+0x35 open(c638e000,ebe22cf8,c0cfff3b,c0caa814,c6866550,...) at open+0x30 syscall(ebe22d38) at syscall+0x220 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (5, FreeBSD ELF32, open), eip =3D 0x281744b3, esp =3D 0xbfbfec4= c, ebp =3D 0xbfbfecb8 --- Starting Network: lo0 em0 em1. lo0: flags=3D8049 metric 0 mtu 16384 options=3D3 inet 127.0.0.1 netmask 0xff000000=20 inet6 ::1 prefixlen 128=20 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3=20 nd6 options=3D21 em0: flags=3D8843 metric 0 mtu 1500 options=3D289b ether 00:30:48:2d:32:6a inet 172.16.8.10 netmask 0xffffff00 broadcast 172.16.8.255 inet6 fe80::230:48ff:fe2d:326a%em0 prefixlen 64 tentative scopeid 0= x1=20 nd6 options=3D29 media: Ethernet autoselect status: no carrier em1: flags=3D8802 metric 0 mtu 1500 options=3D389b ether 00:30:48:2d:32:6b media: Ethernet autoselect status: no carrier Starting devd. Starting Network: em1. em1: flags=3D8802 metric 0 mtu 1500 options=3D389b ether 00:30:48:2d:32:6b media: Ethernet autoselect status: no carrier add net default: gateway 172.16.8.1 add net ::ffff:0.0.0.0: gateway ::1 add net ::0.0.0.0: gateway ::1 add net fe80::: gateway ::1 add net ff02::: gateway ::1 ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib /usr/local/= lib/compat a.out ldconfig path: /usr/lib/aout /usr/lib/compat/aout Creating and/or trimming log files. Starting syslogd. No core dumps found. Starting rpcbind. NFS access cache time=3D60 Setting NIS domain: lmdhw.com. Starting ypbind. Starting amd. Clearing /tmp (X related). Starting mountd. Starting nfsd. Starting lpd. Updating motd:. Starting ntpd. Starting powerd. Starting rsyncd. Starting cvsupd. Configuring syscons: blanktime. Starting sshd. Starting cron. Starting background file system checks in 60 seconds. Tue May 11 21:20:35 PDT 2010 FreeBSD/i386 (freebeast.catwhisker.org) (ttyu0) login:=20 Fatal trap 12: page fault while in kernel mode cpuid =3D 0; apic id =3D 00 fault virtual address =3D 0x68 fault code =3D supervisor read, page not present instruction pointer =3D 0x20:0xc0894306 stack pointer =3D 0x28:0xe9bc6c5c frame pointer =3D 0x28:0xe9bc6c7c code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, def32 1, gran 1 processor eflags =3D interrupt enabled, resume, IOPL =3D 0 current process =3D 20 (flowcleaner) [ thread pid 20 tid 100067 ] Stopped at _mtx_lock_flags+0x46: movl 0x10(%ebx),%eax db> bt Tracing pid 20 tid 100067 td 0xc5a19000 _mtx_lock_flags(58,0,c0cd2efb,570,0,...) at _mtx_lock_flags+0x46 flowtable_free_stale(c0e28ac0,0,c0cd2efb,600,0,...) at flowtable_free_stale= +0x2fb flowtable_cleaner(0,e9bc6d38,c0cbf1f8,343,c63172a8,...) at flowtable_cleane= r+0xd0 fork_exit(c094fa90,0,e9bc6d38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip =3D 0, esp =3D 0xe9bc6d70, ebp =3D 0 --- db>=20 I wish I had better news; sorry. Peace, david --=20 David H. Wolfskill david@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --NzX0AQGjRQPusK/O Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iEYEARECAAYFAkvqLXoACgkQmprOCmdXAD1QUwCeOTvc8Tn7yNx2OS4gMlBhLzio 90YAnjNn7nUrAAkcXkE0d53jgpGcrUak =Yt/K -----END PGP SIGNATURE----- --NzX0AQGjRQPusK/O-- From owner-freebsd-current@FreeBSD.ORG Wed May 12 04:27:09 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 377D7106564A; Wed, 12 May 2010 04:27:09 +0000 (UTC) (envelope-from kmatthew.macy@gmail.com) Received: from mail-qy0-f191.google.com (mail-qy0-f191.google.com [209.85.221.191]) by mx1.freebsd.org (Postfix) with ESMTP id 939718FC12; Wed, 12 May 2010 04:27:08 +0000 (UTC) Received: by qyk29 with SMTP id 29so9315921qyk.14 for ; Tue, 11 May 2010 21:27:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:reply-to:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:content-type:content-transfer-encoding; bh=YoB1p4vslpYcwLnj3s6b9nsyotfzCR2ARN9yspabbsQ=; b=eEEBalXLBdfNq3RVCzpzDJ0E/NrA6kTTdSszcfqZCZGa71c3ms+vt/jNzDLmpHZ4i5 j5OfaY7/qQJwzAvGakXMsYk2WNBSVB+AZfG52Y8zy+YkNGVZdd9ayCcdLcEoq0pXC2or sK5s1pYAfSeNqsiPZu1keUuERiRjlSL0brp1c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:reply-to:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; b=nJKLRBKzAyDUGqRS/TVmhZJJU9IuGtAg6DZEAA0ystIWC1f1bPImCRv9H93iZhOHTR 6VMuqcIiH33Pb3S/hY/UUPyz4RD/ha2agdHpdu7g/03jmzm/ZmMRXthWF4GNlSAZCaoR +8g46v77DP5mY7tkwuLkALFz8SC1PlWnmwbOs= MIME-Version: 1.0 Received: by 10.229.214.20 with SMTP id gy20mr454730qcb.149.1273638426538; Tue, 11 May 2010 21:27:06 -0700 (PDT) Sender: kmatthew.macy@gmail.com Received: by 10.229.224.71 with HTTP; Tue, 11 May 2010 21:27:06 -0700 (PDT) In-Reply-To: <20100512042430.GH685@bunrab.catwhisker.org> References: <20100510140722.GD49209@bunrab.catwhisker.org> <20100510182243.GV56080@hoeg.nl> <20100510182625.GF49209@bunrab.catwhisker.org> <20100511131817.GB685@bunrab.catwhisker.org> <20100512042430.GH685@bunrab.catwhisker.org> Date: Tue, 11 May 2010 21:27:06 -0700 X-Google-Sender-Auth: RhbUZfjbnch1blv3zcBpUeQ0TZM Message-ID: From: "K. Macy" To: David Wolfskill , "K. Macy" , Ed Schouten , current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: Panic @r207844; current process: flowcleaner "Fatal trap 12: page fault while in kernel mode" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: kmacy@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 04:27:09 -0000 On Tue, May 11, 2010 at 9:24 PM, David Wolfskill wro= te: > On Tue, May 11, 2010 at 08:30:09PM -0700, K. Macy wrote: >> Please try 207949 .... >> ... > > The panic (this time) didn't show up until about 10 seconds after the > login: prompt showed up on the serial console. =A0Here's what it looks > like: > > ... > =A03 =A0Select option, [Enter] for default =A0 =A0 3 > =A03 =A0or [Space] to pause timer =A09 =A0 =A0 =A0 =A0 =A0 3 > =A0@DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY > > > GDB: no debug ports present > KDB: debugger backends: ddb > KDB: current backend: ddb > Copyright (c) 1992-2010 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > =A0 =A0 =A0 =A0The Regents of the University of California. All rights re= served. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 9.0-CURRENT #157 r207911M: Tue May 11 20:54:25 PDT 2010 > =A0 =A0root@freebeast.catwhisker.org:/usr/obj/usr/src/sys/GENERIC i386 > WARNING: WITNESS option enabled, expect reduced performance. > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: Intel(R) Xeon(TM) CPU 3.60GHz (3614.55-MHz 686-class CPU) > =A0Origin =3D "GenuineIntel" =A0Id =3D 0xf41 =A0Family =3D f =A0Model =3D= 4 =A0Stepping =3D 1 > =A0Features=3D0xbfebfbff > =A0Features2=3D0x659d > =A0AMD Features=3D0x20100000 > =A0TSC: P-state invariant > real memory =A0=3D 2147483648 (2048 MB) > avail memory =3D 2086129664 (1989 MB) > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > FreeBSD/SMP: 2 package(s) x 1 core(s) > =A0cpu0 (BSP): APIC ID: =A00 > =A0cpu1 (AP): APIC ID: =A06 > ioapic0 irqs 0-23 on motherboard > ioapic1 irqs 24-47 on motherboard > ioapic2 irqs 48-71 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 0x1008-0x100b on acpi0 > cpu0: on acpi0 > cpu1: on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > pci0: at device 0.1 (no driver attached) > pci0: at device 1.0 (no driver attached) > pcib1: irq 16 at device 2.0 on pci0 > pci1: on pcib1 > pcib2: at device 0.0 on pci1 > pci2: on pcib2 > aac0: mem 0xdc000000-0xdfffffff irq 24 at devic= e 1.0 on pci2 > aac0: Enable Raw I/O > aac0: New comm. interface enabled > aac0: [ITHREAD] > aac0: Adaptec 2200S, aac driver 2.1.9-1 > aacp0: on aac0 > aacp1: on aac0 > pcib3: at device 0.2 on pci1 > pci3: on pcib3 > em0: port 0x2000-0x20= 3f mem 0xd8200000-0xd821ffff irq 54 at device 2.0 on pci3 > em0: [FILTER] > em0: Ethernet address: 00:30:48:2d:32:6a > em1: port 0x2040-0x20= 7f mem 0xd8220000-0xd823ffff irq 55 at device 2.1 on pci3 > em1: [FILTER] > em1: Ethernet address: 00:30:48:2d:32:6b > pcib4: irq 16 at device 4.0 on pci0 > pci4: on pcib4 > pcib5: irq 16 at device 6.0 on pci0 > pci5: on pcib5 > uhci0: port 0x1400-0x141f irq= 16 at device 29.0 on pci0 > uhci0: [ITHREAD] > usbus0: on uhci0 > uhci1: port 0x1420-0x143f irq= 19 at device 29.1 on pci0 > uhci1: [ITHREAD] > usbus1: on uhci1 > uhci2: port 0x1440-0x145f irq= 18 at device 29.2 on pci0 > uhci2: [ITHREAD] > usbus2: on uhci2 > uhci3: port 0x1460-0x147f irq= 16 at device 29.3 on pci0 > uhci3: [ITHREAD] > usbus3: on uhci3 > ehci0: mem 0xd8001000-0xd8001= 3ff irq 23 at device 29.7 on pci0 > ehci0: [ITHREAD] > usbus4: EHCI version 1.0 > usbus4: on ehci0 > pcib6: at device 30.0 on pci0 > pci6: on pcib6 > vgapci0: port 0x3000-0x30ff mem 0xd9000000-0xd9f= fffff,0xd8300000-0xd8300fff irq 17 at device 1.0 on pci6 > isab0: at device 31.0 on pci0 > isa0: on isab0 > atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x1= 77,0x376,0x14a0-0x14af at device 31.1 on pci0 > ata0: on atapci0 > ata0: [ITHREAD] > ata1: on atapci0 > ata1: [ITHREAD] > pci0: at device 31.3 (no driver attached) > acpi_button0: on acpi0 > atrtc0: port 0x70-0x77 irq 8 on acpi0 > atkbdc0: port 0x60,0x64 irq 1 on acpi0 > atkbd0: irq 1 on atkbdc0 > kbd0 at atkbd0 > atkbd0: [GIANT-LOCKED] > atkbd0: [ITHREAD] > psm0: irq 12 on atkbdc0 > psm0: [GIANT-LOCKED] > psm0: [ITHREAD] > psm0: model Generic PS/2 mouse, device ID 0 > uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 > uart0: [FILTER] > uart0: console (9600,n,8,1) > uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 > uart1: [FILTER] > fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acp= i0 > fdc0: [FILTER] > fd0: <1440-KB 3.5" drive> on fdc0 drive 0 > pmtimer0 on isa0 > orm0: at iomem 0xc0000-0xc7fff,0xc8000-0xc8fff,0xc9000-= 0xc9fff,0xca000-0xcafff,0xcb000-0xcf7ff pnpid ORM0000 on isa0 > sc0: at flags 0x100 on isa0 > sc0: VGA <16 virtual consoles, flags=3D0x300> > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > ppc0: parallel port not found. > est0: on cpu0 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 122d00000e24 > device_attach: est0 attach returned 6 > p4tcc0: on cpu0 > est1: on cpu1 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 122d00000e24 > device_attach: est1 attach returned 6 > p4tcc1: on cpu1 > Timecounters tick every 1.000 msec > usbus0: 12Mbps Full Speed USB v1.0 > usbus1: 12Mbps Full Speed USB v1.0 > usbus2: 12Mbps Full Speed USB v1.0 > usbus3: 12Mbps Full Speed USB v1.0 > usbus4: 480Mbps High Speed USB v2.0 > ata1: DMA limited to UDMA33, controller found non-ATA66 cable > ugen0.1: at usbus0 > uhub0: on usbus0 > ugen1.1: at usbus1 > uhub1: on usbus1 > ugen2.1: at usbus2 > uhub2: on usbus2 > ugen3.1: at usbus3 > uhub3: on usbus3 > ugen4.1: at usbus4 > uhub4: on usbus4 > acd0: DVDROM at ata1-slave UDMA33 > aacd0: on aac0 > aacd0: 34970MB (71619584 sectors) > aacd1: on aac0 > aacd1: 69974MB (143307008 sectors) > uhub0: 2 ports with 2 removable, self powered > uhub1: 2 ports with 2 removable, self powered > uhub2: 2 ports with 2 removable, self powered > uhub3: 2 ports with 2 removable, self powered > uhub4: 8 ports with 8 removable, self powered > ses0 at aacp0 bus 0 scbus0 target 6 lun 0 > ses0: Fixed Uninstalled SCSI-2 device > ses0: 3.300MB/s transfers > ses0: SAF-TE Compliant Device > pass0 at aacp0 bus 0 scbus0 target 0 lun 0 > pass0: Fixed Uninstalled SCSI-3 device > pass0: 3.300MB/s transfers > pass1 at aacp0 bus 0 scbus0 target 1 lun 0 > pass1: Fixed Uninstalled SCSI-3 device > pass1: 3.300MB/s transfers > pass2 at aacp0 bus 0 scbus0 target 2 lun 0 > pass2: Fixed Uninstalled SCSI-3 device > pass2: 3.300MB/s transfers > pass3 at aacp0 bus 0 scbus0 target 3 lun 0 > pass3: Fixed Uninstalled SCSI-3 device > pass3: 3.300MB/s transfers > SMP: AP CPU #1 Launched! > WARNING: WITNESS option enabled, expect reduced performance. > Trying to mount root from ufs:/dev/aacd0s4a > Setting hostuuid: 80f1e964-dc63-0010-89d5-0030482d326a. > Setting hostid: 0xc74551dd. > Entropy harvesting: interrupts ethernet point_to_point kickstart. > Starting file system checks: > /dev/aacd0s4a: FILE SYSTEM CLEAN; SKIPPING CHECKS > /dev/aacd0s4a: clean, 267641 free (2161 frags, 33185 blocks, 0.3% fragmen= tation) > /dev/aacd1s1e: FILE SYSTEM CLEAN; SKIPPING CHECKS > /dev/aacd1s1e: clean, 4751807 free (262119 frags, 561211 blocks, 2.0% fra= gmentation) > /dev/aacd0s1a: FILE SYSTEM CLEAN; SKIPPING CHECKS > /dev/aacd0s1a: clean, 422042 free (682 frags, 52670 blocks, 0.1% fragment= ation) > /dev/aacd0s1d: FILE SYSTEM CLEAN; SKIPPING CHECKS > /dev/aacd0s1d: clean, 1076253 free (237 frags, 134502 blocks, 0.0% fragme= ntation) > /dev/aacd1s1d: FILE SYSTEM CLEAN; SKIPPING CHECKS > /dev/aacd1s1d: clean, 11714564 free (199148 frags, 1439427 blocks, 1.2% f= ragmentation) > /dev/aacd0s2a: FILE SYSTEM CLEAN; SKIPPING CHECKS > /dev/aacd0s2a: clean, 596264 free (1144 frags, 74390 blocks, 0.2% fragmen= tation) > /dev/aacd0s2d: FILE SYSTEM CLEAN; SKIPPING CHECKS > /dev/aacd0s2d: clean, 1108504 free (24176 frags, 135541 blocks, 1.3% frag= mentation) > /dev/aacd0s3a: FILE SYSTEM CLEAN; SKIPPING CHECKS > /dev/aacd0s3a: clean, 578034 free (1186 frags, 72106 blocks, 0.2% fragmen= tation) > /dev/aacd0s3d: FILE SYSTEM CLEAN; SKIPPING CHECKS > /dev/aacd0s3d: clean, 1070824 free (41840 frags, 128623 blocks, 2.3% frag= mentation) > /dev/aacd0s4d: FILE SYSTEM CLEAN; SKIPPING CHECKS > /dev/aacd0s4d: clean, 1075779 free (60523 frags, 126907 blocks, 3.4% frag= mentation) > /dev/aacd0s4f: FILE SYSTEM CLEAN; SKIPPING CHECKS > /dev/aacd0s4f: clean, 2071045 free (357 frags, 258836 blocks, 0.0% fragme= ntation) > Mounting local file systems:. > Setting hostname: freebeast.catwhisker.org. > lock order reversal: > =A01st 0xc68406b8 ufs (ufs) @ /usr/src/sys/kern/vfs_lookup.c:502 > =A02nd 0xd94fe304 bufwait (bufwait) @ /usr/src/sys/ufs/ffs/ffs_softdep.c:= 11363 > =A03rd 0xc6867af8 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2091 > KDB: stack backtrace: > db_trace_self_wrapper(c0cc73e5,ebe22300,c08ea0d5,c08da44b,c0cca3d8,...) a= t db_trace_self_wrapper+0x26 > kdb_backtrace(c08da44b,c0cca3d8,c553d030,c5540568,ebe2235c,...) at kdb_ba= cktrace+0x29 > _witness_debugger(c0cca3d8,c6867af8,c0cbc6fd,c5540568,c0cd14f1,...) at _w= itness_debugger+0x25 > witness_checkorder(c6867af8,9,c0cd14f1,82b,0,...) at witness_checkorder+0= x839 > __lockmgr_args(c6867af8,80100,c6867b18,0,0,...) at __lockmgr_args+0x7f9 > ffs_lock(ebe22480,c08e9e7b,c0cd0996,80100,c6867aa0,...) at ffs_lock+0x8a > VOP_LOCK1_APV(c0dd5020,ebe22480,c638e0a4,c0defa60,c6867aa0,...) at VOP_LO= CK1_APV+0xb5 > _vn_lock(c6867aa0,80100,c0cd14f1,82b,4,...) at _vn_lock+0x5e > vget(c6867aa0,80100,c638e000,50,0,...) at vget+0xb9 > vfs_hash_get(c6848ca8,78c22,80000,c638e000,ebe225d0,...) at vfs_hash_get+= 0xe6 > ffs_vgetf(c6848ca8,78c22,80000,ebe225d0,1,...) at ffs_vgetf+0x49 > softdep_sync_metadata(c6840660,0,c0ced738,144,0,...) at softdep_sync_meta= data+0xc92 > ffs_syncvnode(c6840660,1,c638e000,ebe22690,246,...) at ffs_syncvnode+0x3e= 2 > ffs_truncate(c6840660,200,0,880,c5588480,...) at ffs_truncate+0x862 > ufs_direnter(c6840660,c6867aa0,ebe22944,ebe22bd4,0,...) at ufs_direnter+0= x8d4 > ufs_makeinode(ebe22bd4,0,ebe22b30,ebe22a8c,c0c03425,...) at ufs_makeinode= +0x557 > ufs_create(ebe22b30,ebe22b48,0,0,ebe22ba8,...) at ufs_create+0x30 > VOP_CREATE_APV(c0dd5020,ebe22b30,ebe22bd4,ebe22ac8,0,...) at VOP_CREATE_A= PV+0xa5 > vn_open_cred(ebe22ba8,ebe22c5c,1a4,0,c5588480,...) at vn_open_cred+0x215 > vn_open(ebe22ba8,ebe22c5c,1a4,c637e770,0,...) at vn_open+0x3b > kern_openat(c638e000,ffffff9c,804c5e8,0,602,...) at kern_openat+0x125 > kern_open(c638e000,804c5e8,0,601,21b6,...) at kern_open+0x35 > open(c638e000,ebe22cf8,c0cfff3b,c0caa814,c6866550,...) at open+0x30 > syscall(ebe22d38) at syscall+0x220 > Xint0x80_syscall() at Xint0x80_syscall+0x20 > --- syscall (5, FreeBSD ELF32, open), eip =3D 0x281744b3, esp =3D 0xbfbfe= c4c, ebp =3D 0xbfbfecb8 --- > Starting Network: lo0 em0 em1. > lo0: flags=3D8049 metric 0 mtu 16384 > =A0 =A0 =A0 =A0options=3D3 > =A0 =A0 =A0 =A0inet 127.0.0.1 netmask 0xff000000 > =A0 =A0 =A0 =A0inet6 ::1 prefixlen 128 > =A0 =A0 =A0 =A0inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 > =A0 =A0 =A0 =A0nd6 options=3D21 > em0: flags=3D8843 metric 0 mtu 15= 00 > =A0 =A0 =A0 =A0options=3D289b > =A0 =A0 =A0 =A0ether 00:30:48:2d:32:6a > =A0 =A0 =A0 =A0inet 172.16.8.10 netmask 0xffffff00 broadcast 172.16.8.255 > =A0 =A0 =A0 =A0inet6 fe80::230:48ff:fe2d:326a%em0 prefixlen 64 tentative = scopeid 0x1 > =A0 =A0 =A0 =A0nd6 options=3D29 > =A0 =A0 =A0 =A0media: Ethernet autoselect > =A0 =A0 =A0 =A0status: no carrier > em1: flags=3D8802 metric 0 mtu 1500 > =A0 =A0 =A0 =A0options=3D389b > =A0 =A0 =A0 =A0ether 00:30:48:2d:32:6b > =A0 =A0 =A0 =A0media: Ethernet autoselect > =A0 =A0 =A0 =A0status: no carrier > Starting devd. > Starting Network: em1. > em1: flags=3D8802 metric 0 mtu 1500 > =A0 =A0 =A0 =A0options=3D389b > =A0 =A0 =A0 =A0ether 00:30:48:2d:32:6b > =A0 =A0 =A0 =A0media: Ethernet autoselect > =A0 =A0 =A0 =A0status: no carrier > add net default: gateway 172.16.8.1 > add net ::ffff:0.0.0.0: gateway ::1 > add net ::0.0.0.0: gateway ::1 > add net fe80::: gateway ::1 > add net ff02::: gateway ::1 > ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib /usr/loca= l/lib/compat > a.out ldconfig path: /usr/lib/aout /usr/lib/compat/aout > Creating and/or trimming log files. > Starting syslogd. > No core dumps found. > Starting rpcbind. > NFS access cache time=3D60 > Setting NIS domain: lmdhw.com. > Starting ypbind. > Starting amd. > Clearing /tmp (X related). > Starting mountd. > Starting nfsd. > Starting lpd. > Updating motd:. > Starting ntpd. > Starting powerd. > Starting rsyncd. > Starting cvsupd. > Configuring syscons: blanktime. > Starting sshd. > Starting cron. > Starting background file system checks in 60 seconds. > > Tue May 11 21:20:35 PDT 2010 > > FreeBSD/i386 (freebeast.catwhisker.org) (ttyu0) > > login: > > Fatal trap 12: page fault while in kernel mode > cpuid =3D 0; apic id =3D 00 > fault virtual address =A0 =3D 0x68 > fault code =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D supervisor read, page not prese= nt > instruction pointer =A0 =A0 =3D 0x20:0xc0894306 > stack pointer =A0 =A0 =A0 =A0 =A0 =3D 0x28:0xe9bc6c5c > frame pointer =A0 =A0 =A0 =A0 =A0 =3D 0x28:0xe9bc6c7c > code segment =A0 =A0 =A0 =A0 =A0 =A0=3D base 0x0, limit 0xfffff, type 0x1= b > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D DPL 0, pres 1, def32 1= , gran 1 > processor eflags =A0 =A0 =A0 =A0=3D interrupt enabled, resume, IOPL =3D 0 > current process =A0 =A0 =A0 =A0 =3D 20 (flowcleaner) > [ thread pid 20 tid 100067 ] > Stopped at =A0 =A0 =A0_mtx_lock_flags+0x46: =A0 movl =A0 =A00x10(%ebx),%e= ax > db> bt > Tracing pid 20 tid 100067 td 0xc5a19000 > _mtx_lock_flags(58,0,c0cd2efb,570,0,...) at _mtx_lock_flags+0x46 > flowtable_free_stale(c0e28ac0,0,c0cd2efb,600,0,...) at flowtable_free_sta= le+0x2fb > flowtable_cleaner(0,e9bc6d38,c0cbf1f8,343,c63172a8,...) at flowtable_clea= ner+0xd0 > fork_exit(c094fa90,0,e9bc6d38) at fork_exit+0xb8 > fork_trampoline() at fork_trampoline+0x8 > --- trap 0, eip =3D 0, esp =3D 0xe9bc6d70, ebp =3D 0 --- > db> > > Could you please get me the backtrace from the core? Thanks, Kip From owner-freebsd-current@FreeBSD.ORG Wed May 12 07:03:09 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C1C9C1065672 for ; Wed, 12 May 2010 07:03:09 +0000 (UTC) (envelope-from fabien.thomas@netasq.com) Received: from work.netasq.com (mars.netasq.com [91.212.116.3]) by mx1.freebsd.org (Postfix) with ESMTP id 325F68FC2A for ; Wed, 12 May 2010 07:03:08 +0000 (UTC) Received: from [192.168.0.1] (unknown [172.16.0.46]) by work.netasq.com (Postfix) with ESMTPSA id 1BB79740010; Wed, 12 May 2010 09:02:44 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=iso-8859-1 From: Fabien Thomas In-Reply-To: <20100511193125.GA59928@wep4035.physik.uni-wuerzburg.de> Date: Wed, 12 May 2010 09:03:06 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <84A14133-1537-474A-B2C7-AB8E2A71A1E1@netasq.com> References: <20100511193125.GA59928@wep4035.physik.uni-wuerzburg.de> To: Alexey Shuvaev X-Mailer: Apple Mail (2.1078) Cc: freebsd-current@freebsd.org Subject: Re: Addition of lzma/xz compression to HEAD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 07:03:09 -0000 Thanks, this is very useful. Fabien Le 11 mai 2010 =E0 21:31, Alexey Shuvaev a =E9crit : > Hello! >=20 > Just FYI: noticed addition of lzma directory to BSD.include.dist mtree = file. > Well, now it seems to work! >=20 > /* Test file size 264 MiB */ > [wep4035] ~> ll /usr/local/tinderbox/jails/9-amd64/9-amd64.tar=20= > -rw-r--r-- 1 root wheel 277209600 Apr 20 20:58 = /usr/local/tinderbox/jails/9-amd64/9-amd64.tar >=20 > /* Cache file in memory */ > [wep4035] ~> cat /usr/local/tinderbox/jails/9-amd64/9-amd64.tar = > /dev/null >=20 > /* 30 seconds to gzip it */ > [wep4035] ~> time tar -cvzf 9-amd64.tar.tar.gz = /usr/local/tinderbox/jails/9-amd64/9-amd64.tar=20 > tar: Removing leading '/' from member names > a usr/local/tinderbox/jails/9-amd64/9-amd64.tar > 30.043u 0.541s 0:15.32 199.6% 37+2093k 0+747io 0pf+0w >=20 > /* 64 seconds to bzip2 it */ > [wep4035] ~> time tar -cvjf 9-amd64.tar.tar.bz2 = /usr/local/tinderbox/jails/9-amd64/9-amd64.tar > tar: Removing leading '/' from member names > a usr/local/tinderbox/jails/9-amd64/9-amd64.tar > 63.454u 0.686s 0:32.09 199.8% 37+2108k 0+650io 1pf+0w >=20 > /* And 140 seconds to xz it */ > [wep4035] ~> time tar -cvJf 9-amd64.tar.tar.xz = /usr/local/tinderbox/jails/9-amd64/9-amd64.tar > tar: Removing leading '/' from member names > a usr/local/tinderbox/jails/9-amd64/9-amd64.tar > 277.625u 0.857s 2:19.26 199.9% 37+2092k 0+432io 0pf+0w >=20 > /* Resulting sizes :)))) */ > [wep4035] ~> ll 9-amd64.tar.tar.* > -rw-r--r-- 1 lexx lexx 84830128 May 11 21:07 = 9-amd64.tar.tar.bz2 > -rw-r--r-- 1 lexx lexx 97667581 May 11 21:07 = 9-amd64.tar.tar.gz > -rw-r--r-- 1 lexx lexx 56366908 May 11 21:10 = 9-amd64.tar.tar.xz >=20 > /* 3.5 seconds to gunzip the file (mostly IO-limited) */ > [wep4035] ~> cat 9-amd64.tar.tar.gz > /dev/null=20 > [wep4035] ~> time tar -xvf 9-amd64.tar.tar.gz=20 > x usr/local/tinderbox/jails/9-amd64/9-amd64.tar > 2.721u 0.747s 0:03.54 97.7% 42+2365k 3+2116io 0pf+0w > [wep4035] ~> rm -R usr/ >=20 > /* 18 seconds to bunzip2 it */ > [wep4035] ~> cat 9-amd64.tar.tar.bz2 > /dev/null > [wep4035] ~> time tar -xvf 9-amd64.tar.tar.bz2=20 > x usr/local/tinderbox/jails/9-amd64/9-amd64.tar > 18.136u 0.999s 0:09.59 199.3% 37+2110k 1+2116io 0pf+0w > [wep4035] ~> rm -R usr/ >=20 > /* And only 10 seconds to xzdec it */ > [wep4035] ~> cat 9-amd64.tar.tar.xz > /dev/null > [wep4035] ~> time tar -xvf 9-amd64.tar.tar.xz > x usr/local/tinderbox/jails/9-amd64/9-amd64.tar > 10.304u 0.771s 0:05.59 198.0% 38+2164k 3+2116io 0pf+0w > [wep4035] ~> rm -R usr/ >=20 >=20 > Thanks to all involved in bringing it to HEAD! >=20 > Alexey. >=20 > P.S. I'm not claiming any statistical validity of provided timings nor > that the testing procedure is correct. It is just to show that tar in = HEAD > now works with lzma/xz compression. > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to = "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Wed May 12 07:16:13 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 13E10106564A for ; Wed, 12 May 2010 07:16:13 +0000 (UTC) (envelope-from alexbestms@uni-muenster.de) Received: from SECMAIL.UNI-MUENSTER.DE (SECMAIL.UNI-MUENSTER.DE [128.176.192.141]) by mx1.freebsd.org (Postfix) with ESMTP id 978308FC15 for ; Wed, 12 May 2010 07:16:12 +0000 (UTC) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by SECMAIL.UNI-MUENSTER.DE (Postfix) with ESMTP id 2EF50BF406 for ; Wed, 12 May 2010 09:16:10 +0200 (CEST) Received: by fxm1 with SMTP id 1so603395fxm.13 for ; Wed, 12 May 2010 00:16:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.102.13.24 with SMTP id 24mr4179193mum.6.1273648569543; Wed, 12 May 2010 00:16:09 -0700 (PDT) Received: by 10.103.167.8 with HTTP; Wed, 12 May 2010 00:16:09 -0700 (PDT) In-Reply-To: <20100512014651.GN73283@cicely7.cicely.de> References: <3a142e751003291708nc3e110bjca1789cc807f61a2@mail.gmail.com> <20100512014651.GN73283@cicely7.cicely.de> Date: Wed, 12 May 2010 09:16:09 +0200 Message-ID: From: Alexander Best To: ticso@cicely.de Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: fsck unable to read disk sectors X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 07:16:13 -0000 On Wed, May 12, 2010 at 3:46 AM, Bernd Walter wro= te: > On Tue, May 11, 2010 at 10:15:13PM +0200, Alexander Best wrote: >> i've posted a log here which is pretty self explanatory: >> >> http://pastebin.com/tn3NiDDW >> >> On Tue, May 11, 2010 at 10:13 PM, Alexander Best >> wrote: >> > the problem is getting more awkward. >> > >> > if i do `fsck /dev/label/rootfs` fsck complains that it cannot read a >> > specific sector of my hdd as i mentioned before. if i run fsck on the >> > device node directly using `fsck /dev/ada0p3` however, fsck succeeds. > > So this is not hardware it is bad partitioning. puh. that's a relief. but since smartd didn't complain about anything and dd if=3D/dev/ada0 of=3D/dev/null bs=3D1m reported no errors i kinda thought that my hdd wasn't the cause for this. > >> > what i did was to boot into single user mode with / being mounted read >> > only. for some reason however fsck will check /dev/label/rootfs in >> > write mode, but if i want fsck to check ada0p3 it will only do so in >> > read mode. >> > >> > this looks like something is really broken. right now the only way to >> > get the clean flag set on my hdd is to boot from a livefs cd and then >> > run `fsck /dev/ada0p3` (again: `fsck /dev/label/rootfs` will NOT >> > succeed). > > One of the typical problems users have is that they forget that > adding a label takes one sector, so the labeled device is smaller. > This is no problem if you create the filesystem on the labeled > drive, but often enough people add the label after creating the > filesystem. > Everything seems to work fine until the FS decides to use that special > sector. > I wouldn't add a label for ufs anyway, since UFS has labeling itself, > which is also handled by glabel module and doesn't require extra space. > Just setup the ufs label with tunefs -L and use the resulting /dev/ufs/..= . > device. > You only need extra label for swap, but this is not problem, since > it has no persistent ondisk structures. thanks a lot for the explanation. i never would have thought about that. since / already has a ufs label i'll simply change fstab to use /dev/ufs/rootfs as /, then boot into single user mode and remove the glabel for ada0p3. i followed the steps described in the gpart(8) manual to create my partition layout. maybe the manual should state that if one wants to create a glabel it should happen before creating a filesystem? > >> > this is the output of `glabel status` btw: >> > >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 Name =A0Status =A0Components >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 label/boot= =A0 =A0 N/A =A0ada0p1 >> > gptid/e52df583-e446-11de-bb92-000fb58207c8 =A0 =A0 N/A =A0ada0p1 >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 label/swap= =A0 =A0 N/A =A0ada0p2 >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 label/rootfs = =A0 =A0 N/A =A0ada0p3 >> > >> > cheers. >> > >> > On Tue, Mar 30, 2010 at 2:08 AM, Paul B Mahol wrote= : >> >> On 3/29/10, Alexander Best wrote: >> >>> hi there, >> >>> >> >>> when doing fsck on my / fs i get this error: >> >>> >> >>> "Cannot Read BLK. 471617640" and "The Following Disk Sectors could n= ot be >> >>> read: 471617643". after this message the partition gets marked dirty= . >> >>> >> >>> i performed the following steps to verify the problem: >> >>> >> >>> 1) dd if=3D/dev/ada0 of=3D/dev/null bs=3D1m >> >>> 2) fsck / under freebsd 7 >> >>> 3) mount -u -o snapshot /.snap/snapshot1 / && fsck_ffs /.snap/snapsh= ot1 >> >>> >> >>> all three steps showed no problem with that harddrive whatsoever. al= so >> >>> smartd >> >>> doesn't complain about anything. >> >>> >> >>> i'm running HEAD (r205860) on amd64. >> >>> >> >>> this is the output of `dmesg -a|grep ada0`: >> >>> >> >>> ada0 at ahcich2 bus 0 scbus3 target 0 lun 0 >> >>> ada0: ATA-7 SATA 2.x device >> >>> ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) >> >>> ada0: Command Queueing enabled >> >>> ada0: 238474MB (488395055 512 byte sectors: 16H 63S/T 16383C) >> >> >> >> Last time I tried ahci on dead disk it did not complained at all >> >> (usually I get dead LBA listed on console). > > -- > B.Walter http://www.bwct.de > Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. > --=20 Alexander Best From owner-freebsd-current@FreeBSD.ORG Wed May 12 10:43:22 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4C7211065675 for ; Wed, 12 May 2010 10:43:22 +0000 (UTC) (envelope-from gljennjohn@googlemail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id A56A88FC15 for ; Wed, 12 May 2010 10:43:21 +0000 (UTC) Received: by fxm1 with SMTP id 1so854108fxm.13 for ; Wed, 12 May 2010 03:43:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:in-reply-to:references:reply-to:x-mailer:mime-version :content-type:content-transfer-encoding; bh=t4BdifEVVTus0UinMCGm1QbjgLbKo22Ghbv8nSC96z8=; b=b+bf2bsjAdNuWJBEX6bs6i4hx/FYZHQQPUzfHcEcgMb24hFNyT5FQrv3S5Pk0d5O89 cP92syHmP4rPad6UGEpaKHYA4PtmaH5z5/VxI7jB+SUKPcf4WGXBvkwkR57ljYuEwGNP RaomM1laslhIlgDKObDlby6KnNoJFDXzglyGE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :x-mailer:mime-version:content-type:content-transfer-encoding; b=x2f8G73FtCtfeRDx0rHdTkK07mCShM/KN00Zwo0QQZI1rQ+PJpNjt8KZKxythlYLxA pQfUhT7ztmX7t8ibDajh+4knSHB4NfTaAF2GrbkgbilqGoaugMIi2IYPE3qX+l4xHeZB wCE8dRjStm2UjPoH4K1bLucyXKnOQk2z0wGyI= Received: by 10.223.144.79 with SMTP id y15mr958074fau.22.1273660957123; Wed, 12 May 2010 03:42:37 -0700 (PDT) Received: from ernst.jennejohn.org (p57AE5487.dip.t-dialin.net [87.174.84.135]) by mx.google.com with ESMTPS id 2sm111432faf.15.2010.05.12.03.42.35 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 12 May 2010 03:42:36 -0700 (PDT) Date: Wed, 12 May 2010 12:42:34 +0200 From: Gary Jennejohn To: Juergen Lock Message-ID: <20100512124234.12f4d156@ernst.jennejohn.org> In-Reply-To: <20100511184140.GA3983@triton8.kn-bremen.de> References: <20100511184140.GA3983@triton8.kn-bremen.de> X-Mailer: Claws Mail 3.7.5 (GTK+ 2.18.7; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, yokota@FreeBSD.org Subject: Re: [PATCH:] psm(4) IntelliMouse Explorer KVM hack breaks my mouse X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gljennjohn@googlemail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 10:43:22 -0000 On Tue, 11 May 2010 20:41:41 +0200 Juergen Lock wrote: > So now I made a patch that allows disabling that KVM hack via device > hints, appended below. (hint.psm.0.flags="0x10000" - or do you guys > think the hack should be disabled by default instead?) > Don't change the behavior, leave it enabled by default. For POLA. -- Gary Jennejohn From owner-freebsd-current@FreeBSD.ORG Wed May 12 12:07:16 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 072E9106566B; Wed, 12 May 2010 12:07:16 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id BA3AC8FC1D; Wed, 12 May 2010 12:07:15 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id CDF7B1FFC51; Wed, 12 May 2010 12:07:14 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 055DA844B0; Wed, 12 May 2010 14:05:07 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Kostik Belousov References: <201005070036.o470a3pl044330@chez.mckusick.com> <86d3x24a43.fsf@ds4.des.no> <20100511193333.GW83316@deviant.kiev.zoral.com.ua> Date: Wed, 12 May 2010 14:05:06 +0200 In-Reply-To: <20100511193333.GW83316@deviant.kiev.zoral.com.ua> (Kostik Belousov's message of "Tue, 11 May 2010 22:33:33 +0300") Message-ID: <86hbmduxzh.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.95 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, Ivan Voras Subject: Re: HEADS UP: 64-bit quotas going in to head today X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 12:07:16 -0000 Kostik Belousov writes: > Dag-Erling Sm=C3=B8rgrav writes: > > It adds quite a bit of code to pretty much every UFS VOP. > No, it does not. Essentially, it adds one or two function calls per > vop that allocate or deallocate blocks or inodes, and the function > bodies verify two array members and return if those are NULL. Read ufs_vnops.c, count the number of #ifdef QUOTA. There's quite a bit more than just "one or two function calls per vop". Quite a bit of locking going on, too, e.g. in ufs_accessx(). DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Wed May 12 12:16:03 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A7DC8106564A; Wed, 12 May 2010 12:16:03 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 040F58FC13; Wed, 12 May 2010 12:16:02 +0000 (UTC) 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 o4CCGAfA048559 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 May 2010 15:16:10 +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.4/8.14.4) with ESMTP id o4CCFurm055147; Wed, 12 May 2010 15:15:56 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o4CCFu2p055146; Wed, 12 May 2010 15:15:56 +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: Wed, 12 May 2010 15:15:56 +0300 From: Kostik Belousov To: Dag-Erling Sm??rgrav Message-ID: <20100512121556.GA83316@deviant.kiev.zoral.com.ua> References: <201005070036.o470a3pl044330@chez.mckusick.com> <86d3x24a43.fsf@ds4.des.no> <20100511193333.GW83316@deviant.kiev.zoral.com.ua> <86hbmduxzh.fsf@ds4.des.no> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="bgVZo3zXaTQrZhjg" Content-Disposition: inline In-Reply-To: <86hbmduxzh.fsf@ds4.des.no> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-2.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_50, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-current@freebsd.org, Ivan Voras Subject: Re: HEADS UP: 64-bit quotas going in to head today X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 12:16:03 -0000 --bgVZo3zXaTQrZhjg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, May 12, 2010 at 02:05:06PM +0200, Dag-Erling Sm??rgrav wrote: > Kostik Belousov writes: > > Dag-Erling Sm??rgrav writes: > > > It adds quite a bit of code to pretty much every UFS VOP. > > No, it does not. Essentially, it adds one or two function calls per > > vop that allocate or deallocate blocks or inodes, and the function > > bodies verify two array members and return if those are NULL. >=20 > Read ufs_vnops.c, count the number of #ifdef QUOTA. There's quite a bit > more than just "one or two function calls per vop". Quite a bit of > locking going on, too, e.g. in ufs_accessx(). I did read the code when I fine-locked quotas. I stand on my position that it is one or two accounting calls per vop that do nothing in case of disabled quotas. ufs_accessx() path is seldomly executed. You mostly have to open file read-write if you are going to modify inode, and vn_open_cred() already uses exclusive locking there. It is calls like chmod(2) that are catched at this point, performing the operation by path instead of fd. --bgVZo3zXaTQrZhjg Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkvqm/wACgkQC3+MBN1Mb4hPCwCg2q0r2r1bGjAQoUbQ9ZNGPo1L HGkAn0q4cojd53TaWHG/+7+Ixnekka2b =0qcU -----END PGP SIGNATURE----- --bgVZo3zXaTQrZhjg-- From owner-freebsd-current@FreeBSD.ORG Wed May 12 14:12:00 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7675D106566C; Wed, 12 May 2010 14:12:00 +0000 (UTC) (envelope-from uqs@spoerlein.net) Received: from acme.spoerlein.net (acme.spoerlein.net [188.72.220.29]) by mx1.freebsd.org (Postfix) with ESMTP id DC1C98FC1F; Wed, 12 May 2010 14:11:59 +0000 (UTC) Received: from acme.spoerlein.net (localhost.spoerlein.net [IPv6:::1]) by acme.spoerlein.net (8.14.4/8.14.4) with ESMTP id o4CEBsdA022827 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 May 2010 16:11:54 +0200 (CEST) (envelope-from uqs@spoerlein.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=spoerlein.net; s=dkim200908; t=1273673514; bh=jbmYBae+N8Kg6ILf1YaBGdLNFw9dXr4ivtJLDvuusJk=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Transfer-Encoding:In-Reply-To; b=sHDZEzqzpuMUPrMem9o1cAENvFz8PehNDMjbf8BVZewHui2uGw1iOFedXHvZe/cSe LBwB15iABIJFKGzfXOrGAvNJAQOJD9DpocxT7Mq2DVyrnvlF00rkPMaYKNXMubAVxj pMidHKENeN58b8PPGaEwdswG9LMqrG1oprMp0UO4= Received: (from uqs@localhost) by acme.spoerlein.net (8.14.4/8.14.4/Submit) id o4CEBs9e022826; Wed, 12 May 2010 16:11:54 +0200 (CEST) (envelope-from uqs@spoerlein.net) Date: Wed, 12 May 2010 16:11:54 +0200 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= To: Attilio Rao Message-ID: <20100512141154.GF88504@acme.spoerlein.net> Mail-Followup-To: Attilio Rao , Peter Jeremy , current@freebsd.org References: <20100508102005.GB1867@elmar.spoerlein.net> <20100510061057.GA93038@server.vk2pj.dyndns.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: current@freebsd.org, Peter Jeremy Subject: Re: LOR: ufs vs bufwait X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 14:12:00 -0000 On Mon, 10.05.2010 at 22:53:32 +0200, Attilio Rao wrote: > 2010/5/10 Peter Jeremy : > > On 2010-May-08 12:20:05 +0200, Ulrich Spörlein wrote: > >>This LOR also is not yet listed on the LOR page, so I guess it's rather > >>new. I do use SUJ. > >> > >>lock order reversal: > >> 1st 0xc48388d8 ufs (ufs) @ /usr/src/sys/kern/vfs_lookup.c:502 > >> 2nd 0xec0fe304 bufwait (bufwait) @ /usr/src/sys/ufs/ffs/ffs_softdep.c:11363 > >> 3rd 0xc49e56b8 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2091 > > > > I'm seeing exactly the same LOR (and subsequent deadlock) on a recent > > -current without SUJ. > > I think this LOR was reported since a long time. > The deadlock may be new and someway related to the vm_page_lock work > (if not SUJ). I was not able to reproduce this with a kernel prior to SUJ, a kernel just after SUJ went it shows this "deadlock" or infinite loop ... Now it might be that the SUJ kernel only increases the pressure so it happens during a systems uptime. It does not seem directly related to actually using SUJ on a volume, as I could reproduce it with SU only, too. I will try to get a hang not involving GELI and also re-do my tests when the volumes have neither SUJ nor SU enabled, which led to 10-20s "hangs" of the system IIRC. It seems SU/SUJ then only prolongs these hangs ad infinitum. I'll be back next week with new results here Uli From owner-freebsd-current@FreeBSD.ORG Wed May 12 14:40:34 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9C52D1065698 for ; Wed, 12 May 2010 14:40:34 +0000 (UTC) (envelope-from mahan@mahan.org) Received: from ns.mahan.org (ns.mahan.org [67.116.10.138]) by mx1.freebsd.org (Postfix) with ESMTP id 576BD8FC31 for ; Wed, 12 May 2010 14:40:33 +0000 (UTC) Received: from Gypsy.mahan.org (crowTrobot [67.116.10.140]) by ns.mahan.org (8.13.6/8.13.6) with ESMTP id o4CEL0BT032297; Wed, 12 May 2010 07:21:01 -0700 (PDT) (envelope-from mahan@mahan.org) Message-ID: <4BEAB812.5030203@mahan.org> Date: Wed, 12 May 2010 07:15:46 -0700 From: Patrick Mahan User-Agent: Thunderbird 2.0.0.22 (X11/20090605) MIME-Version: 1.0 To: joe References: <4BE565E5.9030505@hostedcontent.com> <4BE5303B.8050409@hostedcontent.com> <4BE529FF.5000008@hostedcontent.com> <4BE59434.9070308@hostedcontent.com> <4BE599B0.60203@hostedcontent.com> In-Reply-To: <4BE599B0.60203@hostedcontent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ian FREISLICH , Fabien Thomas , Jack Vogel , freebsd-current@freebsd.org Subject: Re: igb broken? Unexplained weirdness with intel 82576 nics on a supermicro board. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 14:40:34 -0000 Check to make sure the links are all full-duplex. We started seeing bad performance with the em(4) driver on our HP Proliant 360DL G5's using 1000Mbits. It turned out that switch was setting it's port to half-duplex and the emX interface was following suit. HTH, Patrick joe wrote: > On 05/08/2010 01:31 PM, Jack Vogel wrote: >> Looks like something to do with system C, you might isolate it, and try >> a back >> to back connection with its NICs, change cables, look at BIOS settings, >> change >> the slot the nic is in... All just off the top of my head. >> >> Jack >> >> >> On Sat, May 8, 2010 at 9:41 AM, joe > > wrote: >> >> On 05/08/2010 11:17 AM, Ian FREISLICH wrote: >> >> joe wrote: >> >> On 05/08/2010 06:55 AM, Ian FREISLICH wrote: >> >> joe wrote: >> >> I have just tried your suggeston and it has >> no effect for me ;( >> >> >> Do you have another brand of NIC that you can try? At >> least that >> will isolate whether it's igb(4) or something else. >> >> >> I will grab a new nic today and try...my options are limited >> though. >> Here are the nics i can get my hands on >> >> TP-LINK TL-TG3468, 10/100/1000Mbps PCIe Adapter (supported >> by fbsd?) >> >> >> Based on the RTL8168B chip. Should be supported by the re(4) >> driver. >> >> Intel (EXPI9301CT) Gigabit CT Desktop Adapter (yet another >> intel nic) >> >> >> i82574L chip. Should be supported by the em(4) driver. I >> have had >> good performance in the past with this driver and less than >> satisfactory performance with the igb(4) driver. >> >> That may not be your problem though. Before you go out and buy, >> have a look at the amount of interrupt time your slow machine >> spends >> in 'top' or 'systat -vm'. systat will also show the interrupt >> rate >> for each driver, perhaps it's not doing interrupt moderation >> properly. >> This will manifest as more than about a 1000 per second. >> There are >> loader tunables for the driver to increase the number of transfer >> descriptors and to tune interrupt moderation. >> >> You could try running trafshow (port) on the interface while >> performing the transfer. Perhaps promiscuous mode will turn off >> some hardware feature that will improve things. It may however >> break hardware vlanning as it does on my 82575GB 4 port igb card. >> >> Ian >> >> -- >> Ian Freislich >> >> >> I bought those two cards anyways, im in a rush to figure out this >> problem. That being said i am still encountering the exact same >> problem regardless on which network card i am running. I am at a >> complete loss. I am about to try a raid card to see if the problem >> might lay within the onboard sata ports. I did pull the server and >> brought it home so that i can test more things quicker. >> >> I am going to try using a raid card instead of the onboard sata >> ports and see if i still encounter the same problem. I would love >> any suggestions you may have on where to go from here to figure out >> where the problem might be. >> >> joe >> >> _______________________________________________ >> freebsd-current@freebsd.org >> mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to >> "freebsd-current-unsubscribe@freebsd.org >> " >> >> > > I think it might have something to so with the nics / switch, and their > features. I brought the box home, plugged into my gb switch, and i am > able to FTP data to the server at around 35MB/sec. > > I dont know what would cause this other than some sort of issue with the > the 3 different types of nics and the switch i am using. > > Any suggestions? > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > From owner-freebsd-current@FreeBSD.ORG Wed May 12 16:55:36 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 660B41065675 for ; Wed, 12 May 2010 16:55:36 +0000 (UTC) (envelope-from shuvaev@physik.uni-wuerzburg.de) Received: from mailrelay.rz.uni-wuerzburg.de (mailrelay.rz.uni-wuerzburg.de [132.187.3.28]) by mx1.freebsd.org (Postfix) with ESMTP id 076808FC1A for ; Wed, 12 May 2010 16:55:35 +0000 (UTC) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 92E685AC6E; Wed, 12 May 2010 18:55:31 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 8FA6E5AC5E; Wed, 12 May 2010 18:55:31 +0200 (CEST) X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Received: from mail.physik.uni-wuerzburg.de (wthp192.physik.uni-wuerzburg.de [132.187.40.192]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 63BD55CC68; Wed, 12 May 2010 18:55:31 +0200 (CEST) Received: from wep4035 ([132.187.37.35]) by mail.physik.uni-wuerzburg.de (Lotus Domino Release 8.5.1FP2HF71) with ESMTP id 2010051218553023-72660 ; Wed, 12 May 2010 18:55:30 +0200 Received: by wep4035 (sSMTP sendmail emulation); Wed, 12 May 2010 18:55:30 +0200 Date: Wed, 12 May 2010 18:55:30 +0200 From: Alexey Shuvaev To: freebsd-current@freebsd.org Message-ID: <20100512165530.GA40826@wep4035.physik.uni-wuerzburg.de> MIME-Version: 1.0 Organization: Universitaet Wuerzburg User-Agent: Mutt/1.5.20 (2009-06-14) X-MIMETrack: Itemize by SMTP Server on domino1/uni-wuerzburg(Release 8.5.1FP2HF71 | April 5, 2010) at 05/12/2010 06:55:31 PM, Serialize by Router on domino1/uni-wuerzburg(Release 8.5.1FP2HF71 | April 5, 2010) at 05/12/2010 06:55:31 PM, Serialize complete at 05/12/2010 06:55:31 PM Content-Type: multipart/mixed; boundary="LQksG6bCIzRHxTLp" Content-Disposition: inline Cc: gabor@FreeBSD.org Subject: dc(1) -e "6 2 / p" is still broken as of r207919 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 16:55:36 -0000 --LQksG6bCIzRHxTLp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hello! Just to remind that still: ~> dc -e "6 2 / p" Segmentation fault (core dumped) This was already mentioned on this list: http://lists.freebsd.org/pipermail/freebsd-current/2010-April/016560.html and there is a patch proposed in the same thread: http://lists.freebsd.org/pipermail/freebsd-current/2010-April/016603.html Note, however, that reverting r203438 also fixes the problem (gabor@ CC-ed), so I'm not sure what is the right way to fix it. Attached is slightly modified reverse patch to revert 203438. Thanks, Alexey. --LQksG6bCIzRHxTLp Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=patch --- dc.c 2010/01/20 21:30:52 202719 +++ dc.c 2010/02/03 19:13:41 203438 @@ -82,15 +82,7 @@ { int ch; bool extended_regs = false, preproc_done = false; - char *buf; - if ((buf = strdup("")) == NULL) - err(1, NULL); - - init_bmachine(extended_regs); - setlinebuf(stdout); - setlinebuf(stderr); - /* accept and ignore a single dash to be 4.4BSD dc(1) compatible */ while ((ch = getopt_long(argc, argv, "e:f:Vx", long_options, NULL)) != -1) { switch (ch) { @@ -123,6 +115,10 @@ argc -= optind; argv += optind; + init_bmachine(extended_regs); + setlinebuf(stdout); + setlinebuf(stderr); + if (argc > 1) usage(); if (argc == 1) { --LQksG6bCIzRHxTLp-- From owner-freebsd-current@FreeBSD.ORG Wed May 12 20:44:43 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EFCBF106566C; Wed, 12 May 2010 20:44:43 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: from mail-ww0-f54.google.com (mail-ww0-f54.google.com [74.125.82.54]) by mx1.freebsd.org (Postfix) with ESMTP id 61D818FC1A; Wed, 12 May 2010 20:44:42 +0000 (UTC) Received: by wwd20 with SMTP id 20so445183wwd.13 for ; Wed, 12 May 2010 13:44:42 -0700 (PDT) Received: by 10.227.132.69 with SMTP id a5mr7396724wbt.119.1273697081243; Wed, 12 May 2010 13:44:41 -0700 (PDT) Received: from [10.0.1.198] (udp022762uds.hawaiiantel.net [72.234.79.107]) by mx.google.com with ESMTPS id e82sm434825wej.4.2010.05.12.13.44.36 (version=SSLv3 cipher=RC4-MD5); Wed, 12 May 2010 13:44:39 -0700 (PDT) Date: Wed, 12 May 2010 10:44:34 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: =?ISO-8859-15?Q?Ulrich_Sp=F6rlein?= In-Reply-To: <20100512141154.GF88504@acme.spoerlein.net> Message-ID: References: <20100508102005.GB1867@elmar.spoerlein.net> <20100510061057.GA93038@server.vk2pj.dyndns.org> <20100512141154.GF88504@acme.spoerlein.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Attilio Rao , current@freebsd.org, Peter Jeremy Subject: Re: LOR: ufs vs bufwait X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 20:44:44 -0000 On Wed, 12 May 2010, Ulrich Sp?rlein wrote: > On Mon, 10.05.2010 at 22:53:32 +0200, Attilio Rao wrote: >> 2010/5/10 Peter Jeremy : >>> On 2010-May-08 12:20:05 +0200, Ulrich Sp?rlein wrote: >>>> This LOR also is not yet listed on the LOR page, so I guess it's rather >>>> new. I do use SUJ. >>>> >>>> lock order reversal: >>>> 1st 0xc48388d8 ufs (ufs) @ /usr/src/sys/kern/vfs_lookup.c:502 >>>> 2nd 0xec0fe304 bufwait (bufwait) @ /usr/src/sys/ufs/ffs/ffs_softdep.c:11363 >>>> 3rd 0xc49e56b8 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2091 >>> >>> I'm seeing exactly the same LOR (and subsequent deadlock) on a recent >>> -current without SUJ. >> >> I think this LOR was reported since a long time. >> The deadlock may be new and someway related to the vm_page_lock work >> (if not SUJ). > > I was not able to reproduce this with a kernel prior to SUJ, a kernel > just after SUJ went it shows this "deadlock" or infinite loop ... > > Now it might be that the SUJ kernel only increases the pressure so it > happens during a systems uptime. It does not seem directly related to > actually using SUJ on a volume, as I could reproduce it with SU only, > too. > > I will try to get a hang not involving GELI and also re-do my tests when > the volumes have neither SUJ nor SU enabled, which led to 10-20s "hangs" > of the system IIRC. It seems SU/SUJ then only prolongs these hangs ad > infinitum. I think Peter Holm also saw this once while we were testing SUJ and reproduced ~30 second hangs with stock sources. At this point we need to brainstorm ideas for adding debugging instrumentation and come up with the quickest possible repro. It would probably be good to add some KTR tracing and log that when it wedges. The core I looked at was hung in bufwait. Is there any cpu activity or io activity when things hang? You'll prboably have to keep iostat/vmstat in memory to find out so they don't try to fault in pages once things are hung. Thanks, Jeff > > I'll be back next week with new results here > > Uli > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Wed May 12 20:55:05 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8CEFD106566C for ; Wed, 12 May 2010 20:55:05 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 15F7C8FC08 for ; Wed, 12 May 2010 20:55:04 +0000 (UTC) Received: by fxm1 with SMTP id 1so609730fxm.13 for ; Wed, 12 May 2010 13:55:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=C2FqpM7frrcmt1FZPP8jik4f9TBz4gz+FOgRtKsoHbc=; b=eDXM91wmLjAF7TaPzJfOPh2pZ9IOgif1JRZ2KaTR9Zvz/3d6XItNjiraBguXut6ReS wD1lm1mi0iA3an/ffWYNeth9U+WQVHL5H3+vX/jn+cKL3GQe+vfrS++6r+zuUWwcvb6a t/zoDIkKZfxx+1pmNO1Mt/pP+D5gzbBV61YdU= 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 :content-transfer-encoding; b=uTAmgETbWHVKFEOWhLNKh6McfuFvliO6Y2hDUPbVKwVGHdqwxDtsoVky3b2vcx36ua +b7Y1y6Fo99Z/AxeTyhgmLzxaRq28owXttTAbMA5/WjUagpi7wstuJHVCr/WaJXNSsu5 8y4xhEwF3ooXgDHa1atzhVtvXquLL5lCJonG0= MIME-Version: 1.0 Received: by 10.239.190.83 with SMTP id w19mr696424hbh.144.1273697703115; Wed, 12 May 2010 13:55:03 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.239.129.207 with HTTP; Wed, 12 May 2010 13:55:02 -0700 (PDT) In-Reply-To: References: <20100508102005.GB1867@elmar.spoerlein.net> <20100510061057.GA93038@server.vk2pj.dyndns.org> <20100512141154.GF88504@acme.spoerlein.net> Date: Wed, 12 May 2010 22:55:02 +0200 X-Google-Sender-Auth: c904ed5cf7854c34 Message-ID: From: Attilio Rao To: Jeff Roberson Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: current@freebsd.org, Peter Jeremy Subject: Re: LOR: ufs vs bufwait X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 20:55:05 -0000 2010/5/12 Jeff Roberson : > On Wed, 12 May 2010, Ulrich Sp?rlein wrote: > >> On Mon, 10.05.2010 at 22:53:32 +0200, Attilio Rao wrote: >>> >>> 2010/5/10 Peter Jeremy : >>>> >>>> On 2010-May-08 12:20:05 +0200, Ulrich Sp?rlein >>>> wrote: >>>>> >>>>> This LOR also is not yet listed on the LOR page, so I guess it's rath= er >>>>> new. I do use SUJ. >>>>> >>>>> lock order reversal: >>>>> 1st 0xc48388d8 ufs (ufs) @ /usr/src/sys/kern/vfs_lookup.c:502 >>>>> 2nd 0xec0fe304 bufwait (bufwait) @ >>>>> /usr/src/sys/ufs/ffs/ffs_softdep.c:11363 >>>>> 3rd 0xc49e56b8 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2091 >>>> >>>> I'm seeing exactly the same LOR (and subsequent deadlock) on a recent >>>> -current without SUJ. >>> >>> I think this LOR was reported since a long time. >>> The deadlock may be new and someway related to the vm_page_lock work >>> (if not SUJ). >> >> I was not able to reproduce this with a kernel prior to SUJ, a kernel >> just after SUJ went it shows this "deadlock" or infinite loop ... >> >> Now it might be that the SUJ kernel only increases the pressure so it >> happens during a systems uptime. It does not seem directly related to >> actually using SUJ on a volume, as I could reproduce it with SU only, >> too. >> >> I will try to get a hang not involving GELI and also re-do my tests when >> the volumes have neither SUJ nor SU enabled, which led to 10-20s "hangs" >> of the system IIRC. It seems SU/SUJ then only prolongs these hangs ad >> infinitum. > > I think Peter Holm also saw this once while we were testing SUJ and > reproduced ~30 second hangs with stock sources. =C2=A0At this point we ne= ed to > brainstorm ideas for adding debugging instrumentation and come up with th= e > quickest possible repro. > > It would probably be good to add some KTR tracing and log that when it > wedges. =C2=A0The core I looked at was hung in bufwait. =C2=A0Is there an= y cpu > activity or io activity when things hang? =C2=A0You'll prboably have to k= eep > iostat/vmstat in memory to find out so they don't try to fault in pages o= nce > things are hung. I think I also have some reports about deadlock on unmount -f (not specific to UFS) that seems to me still the same buffer cache async deadlock. I will forward you the traces in a separate e-mail (Peter got to reproduce it with KTR on). Attilio --=20 Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Thu May 13 14:43:58 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 51268106564A; Thu, 13 May 2010 14:43:58 +0000 (UTC) (envelope-from tevans.uk@gmail.com) Received: from mail-ew0-f224.google.com (mail-ew0-f224.google.com [209.85.219.224]) by mx1.freebsd.org (Postfix) with ESMTP id B1A5C8FC0A; Thu, 13 May 2010 14:43:57 +0000 (UTC) Received: by ewy24 with SMTP id 24so462540ewy.13 for ; Thu, 13 May 2010 07:43:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=v/01A+k8jZph+ho+YLgbG3DEh/aetWNVF1p+TE69yqo=; b=oXXGV91ocuvNrfnvjxv09oYd25041eW/bVqZi0NIvrrOh1e47mcGofw5F61hjvJWLi zyycRA7L3dqKYrVqOZ6UFxcs67JBsR+DZs5BZdACpVTpcclOhFR2APAFXH5GVR1wmFrN yiPyFqQm2VUn2BZcxMxxJb3bO1Gf6tSFKQrzg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=iy67ellhimkUYyUyFEtsHOeJCxqlT0nmkzNGS7r/V/evkznlbnBzmKopVQP0diAzkU eQ4PMJK/6JN+vJ0kjLAoN5+B+zKlfXPQHjaAk5S8uGyOthREf07HBtes3GyS82Bymgbx qk5Pz80LyzStkIJWemJEgHJrjoCqXy5vBbx9E= MIME-Version: 1.0 Received: by 10.239.146.210 with SMTP id x18mr871852hba.182.1273760515810; Thu, 13 May 2010 07:21:55 -0700 (PDT) Received: by 10.239.142.17 with HTTP; Thu, 13 May 2010 07:21:55 -0700 (PDT) Date: Thu, 13 May 2010 15:21:55 +0100 Message-ID: From: Tom Evans To: freebsd-current , rwatson@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Mailman-Approved-At: Thu, 13 May 2010 17:52:49 +0000 Cc: Subject: GrandCentralDispatch in FreeBSD? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2010 14:43:58 -0000 Hi Robert I saw today that you've written a proof of concept MPM for apache in GCD [1] - are there any plans to port GCD to FreeBSD? Cheers Tom [1] http://lists.macosforge.org/pipermail/libdispatch-dev/2010-May/000352.html From owner-freebsd-current@FreeBSD.ORG Thu May 13 18:47:49 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 478421065676 for ; Thu, 13 May 2010 18:47:49 +0000 (UTC) (envelope-from chris@brueffer.de) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by mx1.freebsd.org (Postfix) with ESMTP id CAEC78FC22 for ; Thu, 13 May 2010 18:47:48 +0000 (UTC) Received: from brueffer.de ([192.75.139.253]) by mrelayeu.kundenserver.de (node=mreu0) with ESMTP (Nemesis) id 0LwVKN-1NF5JQ21Gh-018NPE; Thu, 13 May 2010 20:35:12 +0200 Received: by brueffer.de (Postfix, from userid 1001) id 13C8C17025; Thu, 13 May 2010 18:35:07 -0400 (EDT) Date: Fri, 14 May 2010 00:35:07 +0200 From: Christian Brueffer To: Tom Evans Message-ID: <20100513223507.GA2193@serenity.wireless.uottawa.ca> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="uAKRQypu60I7Lcqm" Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 9.0-CURRENT 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.19 (2009-01-05) X-Provags-ID: V01U2FsdGVkX1/N8RFjqLXRJ0joBXlz7ljQgziR8TMgaoDxA9F HIuG8jGC7K2EZiA7pwZvZw1tvgtaW76wpBdZS4myW7r2S0N8I1 mfIh8lblV9+z/kYALAgVUD+0vCUEEZz Cc: freebsd-current Subject: Re: GrandCentralDispatch in FreeBSD? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2010 18:47:49 -0000 --uAKRQypu60I7Lcqm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, May 13, 2010 at 03:21:55PM +0100, Tom Evans wrote: > Hi Robert >=20 > I saw today that you've written a proof of concept MPM for apache in > GCD [1] - are there any plans to port GCD to FreeBSD? >=20 It's already there, see http://wiki.freebsd.org/GCD - 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 --uAKRQypu60I7Lcqm Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkvsfpoACgkQbHYXjKDtmC0KsACgty82rY/dhAOa1iWebgdma/2S c8MAnjjN3LCiWumld/8QZBUlaNCQNDR/ =rfNy -----END PGP SIGNATURE----- --uAKRQypu60I7Lcqm-- From owner-freebsd-current@FreeBSD.ORG Thu May 13 18:50:19 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 19C0A106564A; Thu, 13 May 2010 18:50:19 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (lor.one-eyed-alien.net [69.66.77.232]) by mx1.freebsd.org (Postfix) with ESMTP id B36CC8FC08; Thu, 13 May 2010 18:50:18 +0000 (UTC) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.3/8.14.3) with ESMTP id o4DIn3pj092933; Thu, 13 May 2010 13:49:03 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.3/8.14.3/Submit) id o4DIn3gg092932; Thu, 13 May 2010 13:49:03 -0500 (CDT) (envelope-from brooks) Date: Thu, 13 May 2010 13:49:02 -0500 From: Brooks Davis To: Tom Evans Message-ID: <20100513184902.GA92890@lor.one-eyed-alien.net> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HlL+5n6rz5pIUxbD" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (lor.one-eyed-alien.net [127.0.0.1]); Thu, 13 May 2010 13:49:03 -0500 (CDT) Cc: freebsd-current , rwatson@freebsd.org Subject: Re: GrandCentralDispatch in FreeBSD? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2010 18:50:19 -0000 --HlL+5n6rz5pIUxbD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, May 13, 2010 at 03:21:55PM +0100, Tom Evans wrote: > Hi Robert >=20 > I saw today that you've written a proof of concept MPM for apache in > GCD [1] - are there any plans to port GCD to FreeBSD? Robert ported it to FreeBSD when Apple released it: http://libdispatch.macosforge.org/post/libdispatch-on-freebsd/ -- Brooks --HlL+5n6rz5pIUxbD Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iD8DBQFL7EmeXY6L6fI4GtQRArD9AJ9+OWfvyqhztify4lmrwan5nhGzYACeIVGX H/urw5qXT63xHxje2YcBEcU= =EQ6T -----END PGP SIGNATURE----- --HlL+5n6rz5pIUxbD-- From owner-freebsd-current@FreeBSD.ORG Thu May 13 20:05:37 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 43E9C1065674 for ; Thu, 13 May 2010 20:05:37 +0000 (UTC) (envelope-from rwatson@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 1EF248FC08 for ; Thu, 13 May 2010 20:05:37 +0000 (UTC) Received: from [172.24.102.75] (unknown [192.75.139.252]) by cyrus.watson.org (Postfix) with ESMTPSA id 94CE746B86; Thu, 13 May 2010 16:05:36 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: "Robert N. M. Watson" In-Reply-To: Date: Thu, 13 May 2010 16:05:35 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Tom Evans X-Mailer: Apple Mail (2.1078) Cc: freebsd-current Subject: Re: GrandCentralDispatch in FreeBSD? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2010 20:05:37 -0000 On 13 May 2010, at 10:21, Tom Evans wrote: > I saw today that you've written a proof of concept MPM for apache in > GCD [1] - are there any plans to port GCD to FreeBSD? Hi Tom-- Actually, I also ported GCD to FreeBSD last year, and developed the MPM = on FreeBSD/GCD :-). It requires a post-8.0 version of 8-STABLE, and then = libdispatch port + clang compiler. You can find out more here: http://wiki.freebsd.org/GCD The clang dependency is due to C Blocks, and we have an unpatched gcc so = gcc-compiled applications can't use blocks. Robert= From owner-freebsd-current@FreeBSD.ORG Thu May 13 20:21:18 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 655AE106564A; Thu, 13 May 2010 20:21:18 +0000 (UTC) (envelope-from nox@jelal.kn-bremen.de) Received: from smtp.kn-bremen.de (gelbbaer.kn-bremen.de [78.46.108.116]) by mx1.freebsd.org (Postfix) with ESMTP id 201EE8FC0C; Thu, 13 May 2010 20:21:18 +0000 (UTC) Received: by smtp.kn-bremen.de (Postfix, from userid 10) id E58AB1E00161; Thu, 13 May 2010 22:21:16 +0200 (CEST) Received: from triton8.kn-bremen.de (noident@localhost [127.0.0.1]) by triton8.kn-bremen.de (8.14.3/8.14.3) with ESMTP id o4DKHsGK036474; Thu, 13 May 2010 22:17:54 +0200 (CEST) (envelope-from nox@triton8.kn-bremen.de) Received: (from nox@localhost) by triton8.kn-bremen.de (8.14.3/8.14.3/Submit) id o4DKHsTv036473; Thu, 13 May 2010 22:17:54 +0200 (CEST) (envelope-from nox) From: Juergen Lock Date: Thu, 13 May 2010 22:17:54 +0200 To: Gary Jennejohn Message-ID: <20100513201754.GA36439@triton8.kn-bremen.de> References: <20100511184140.GA3983@triton8.kn-bremen.de> <20100512124234.12f4d156@ernst.jennejohn.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100512124234.12f4d156@ernst.jennejohn.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-current@FreeBSD.org, yokota@FreeBSD.org, Juergen Lock Subject: Re: [PATCH:] psm(4) IntelliMouse Explorer KVM hack breaks my mouse X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2010 20:21:18 -0000 On Wed, May 12, 2010 at 12:42:34PM +0200, Gary Jennejohn wrote: > On Tue, 11 May 2010 20:41:41 +0200 > Juergen Lock wrote: > > > So now I made a patch that allows disabling that KVM hack via device > > hints, appended below. (hint.psm.0.flags="0x10000" - or do you guys > > think the hack should be disabled by default instead?) > > > > Don't change the behavior, leave it enabled by default. For POLA. Yeah ok I guess you are right... I've now put the patch on freefall:public_html too, and added links to the relevant threads for it and the other pending src patches: http://people.freebsd.org/~nox/ Thanx, :) Juergen From owner-freebsd-current@FreeBSD.ORG Fri May 14 04:55:39 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 907DE1065675 for ; Fri, 14 May 2010 04:55:39 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-5.mit.edu (DMZ-MAILSEC-SCANNER-5.MIT.EDU [18.7.68.34]) by mx1.freebsd.org (Postfix) with ESMTP id 4DD458FC1A for ; Fri, 14 May 2010 04:55:38 +0000 (UTC) X-AuditID: 12074422-b7c13ae000003829-dc-4becd7ca8f4f Received: from mailhub-auth-2.mit.edu (MAILHUB-AUTH-2.MIT.EDU [18.7.62.36]) by dmz-mailsec-scanner-5.mit.edu (Symantec Brightmail Gateway) with SMTP id 87.6C.14377.AC7DCEB4; Fri, 14 May 2010 00:55:38 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id o4E4tbdo025121; Fri, 14 May 2010 00:55:37 -0400 Received: from multics.mit.edu (MULTICS.MIT.EDU [18.187.1.73]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id o4E4tZr6003377 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 14 May 2010 00:55:37 -0400 (EDT) Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id o4E4tZUd003072; Fri, 14 May 2010 00:55:35 -0400 (EDT) Date: Fri, 14 May 2010 00:55:35 -0400 (EDT) From: Benjamin Kaduk To: alc@freebsd.org, attilio@freebsd.org, freebsd-current@freebsd.org Message-ID: User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Brightmail-Tracker: AAAAAA== Cc: Subject: kgdb unuseable with cores on current (for some people) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 04:55:39 -0000 Hi all, As was revealed in a recent thread here [1], several people have been unable to use kgdb on coredumps for the past few months (but possibly not everyone). I am one of those affected, and have narrowed the breakage with a binary search to between SVN revisions 202883 and 202954 (that is, Jan 23 1200h and Jan 25 0000h). Looking at the changes, alc's revision 202897 and attilio's revision 202933 look to be the most plausible culprits in terms of what they touched. I will continue with my bisection, but with only 36 revisions in play, it is probably worth looking for the bug in parallel with the bisection. To recall, this manifests itself as kgdb printing the following on startup: Cannot access memory at address 0xffffff0127ffffe0 'bt' seems to think that it is on a NULL stack pointer (and fails), and attempting to set a different current process/thread using the 'proc' or 'thread' commands errors with "invalid [p|t]id". However, I can walk the process list starting from allproc .... Looking at kgdb/kthr.c , the kgdb troubles would seem to stem from static struct kthr *first failing to get properly initialized, as the 'proc' command searches starting from that pointer. It's not immediately clear to me where in kgdb_thr_init() it is failing, though --- I see none of the warning messages from its error cases. If no one has thoughts on a possible cause, I guess I can start instrumenting kgdb to locate its failure, but help would be appreciated. Since this may be machine- and/or configuration-dependent, I have posted a dmesg and pciconf output here [2]; it's an amd64 machine with a Core2 Duo (T9400). Thanks, Ben Kaduk [1] http://lists.freebsd.org/pipermail/freebsd-current/2010-May/017195.html [2] http://stuff.mit.edu/afs/sipb.mit.edu/user/kaduk/freebsd/glossolalia/ From owner-freebsd-current@FreeBSD.ORG Fri May 14 05:39:13 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5A3A91065670; Fri, 14 May 2010 05:39:13 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id C55EC8FC08; Fri, 14 May 2010 05:39:12 +0000 (UTC) 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 o4E5dLtw046494 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 May 2010 08:39:21 +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.4/8.14.4) with ESMTP id o4E5d8jF052688; Fri, 14 May 2010 08:39:08 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o4E5d7b7052687; Fri, 14 May 2010 08:39:07 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 14 May 2010 08:39:07 +0300 From: Kostik Belousov To: Benjamin Kaduk Message-ID: <20100514053907.GL83316@deviant.kiev.zoral.com.ua> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="SUaMdvPJwViBZG9r" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_40, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: alc@freebsd.org, attilio@freebsd.org, freebsd-current@freebsd.org Subject: Re: kgdb unuseable with cores on current (for some people) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 05:39:13 -0000 --SUaMdvPJwViBZG9r Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, May 14, 2010 at 12:55:35AM -0400, Benjamin Kaduk wrote: > Hi all, >=20 > As was revealed in a recent thread here [1], several people have been=20 > unable to use kgdb on coredumps for the past few months (but possibly not= =20 > everyone). >=20 > I am one of those affected, and have narrowed the breakage with a binary= =20 > search to between SVN revisions 202883 and 202954 (that is, Jan 23 1200h= =20 > and Jan 25 0000h). Looking at the changes, alc's revision 202897 and=20 > attilio's revision 202933 look to be the most plausible culprits in terms= =20 > of what they touched. I will continue with my bisection, but with only 3= 6=20 > revisions in play, it is probably worth looking for the bug in parallel= =20 > with the bisection. Try reverting r202897 on fresh HEAD. I very much doubt that r202933 can be responsible. --SUaMdvPJwViBZG9r Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkvs4fsACgkQC3+MBN1Mb4iLrACcDLaRSwh4WkBb4khXHXVDn85S pDYAoLbk7/vt5t+a+wAukXOKRP2jvl0T =g73c -----END PGP SIGNATURE----- --SUaMdvPJwViBZG9r-- From owner-freebsd-current@FreeBSD.ORG Fri May 14 06:44:10 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EEE501065672; Fri, 14 May 2010 06:44:10 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-7.mit.edu (DMZ-MAILSEC-SCANNER-7.MIT.EDU [18.7.68.36]) by mx1.freebsd.org (Postfix) with ESMTP id 7F8A58FC29; Fri, 14 May 2010 06:44:10 +0000 (UTC) X-AuditID: 12074424-b7b9dae000002832-fb-4becf1399b32 Received: from mailhub-auth-2.mit.edu (MAILHUB-AUTH-2.MIT.EDU [18.7.62.36]) by dmz-mailsec-scanner-7.mit.edu (Symantec Brightmail Gateway) with SMTP id 1E.5A.10290.931FCEB4; Fri, 14 May 2010 02:44:09 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id o4E6i9KO029750; Fri, 14 May 2010 02:44:09 -0400 Received: from multics.mit.edu (MULTICS.MIT.EDU [18.187.1.73]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id o4E6i7j6008998 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 14 May 2010 02:44:08 -0400 (EDT) Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id o4E6i7Rk004052; Fri, 14 May 2010 02:44:07 -0400 (EDT) Date: Fri, 14 May 2010 02:44:07 -0400 (EDT) From: Benjamin Kaduk To: Kostik Belousov In-Reply-To: <20100514053907.GL83316@deviant.kiev.zoral.com.ua> Message-ID: References: <20100514053907.GL83316@deviant.kiev.zoral.com.ua> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Brightmail-Tracker: AAAAAA== Cc: alc@freebsd.org, attilio@freebsd.org, freebsd-current@freebsd.org Subject: Re: kgdb unuseable with cores on current (for some people) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 06:44:11 -0000 On Fri, 14 May 2010, Kostik Belousov wrote: > On Fri, May 14, 2010 at 12:55:35AM -0400, Benjamin Kaduk wrote: >> Hi all, >> >> As was revealed in a recent thread here [1], several people have been >> unable to use kgdb on coredumps for the past few months (but possibly not >> everyone). >> >> I am one of those affected, and have narrowed the breakage with a binary >> search to between SVN revisions 202883 and 202954 (that is, Jan 23 1200h >> and Jan 25 0000h). Looking at the changes, alc's revision 202897 and >> attilio's revision 202933 look to be the most plausible culprits in terms >> of what they touched. I will continue with my bisection, but with only 36 >> revisions in play, it is probably worth looking for the bug in parallel >> with the bisection. > > Try reverting r202897 on fresh HEAD. I very much doubt that r202933 > can be responsible. > Indeed, 202933 was cleared of blame in the latest bisection. I'm currently pulling up to HEAD and will try reverting 202897. -Ben From owner-freebsd-current@FreeBSD.ORG Fri May 14 11:12:25 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DC2A61065670; Fri, 14 May 2010 11:12:25 +0000 (UTC) (envelope-from gljennjohn@googlemail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 3BA998FC18; Fri, 14 May 2010 11:12:24 +0000 (UTC) Received: by fxm17 with SMTP id 17so1491670fxm.13 for ; Fri, 14 May 2010 04:12:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:in-reply-to:references:reply-to:x-mailer:mime-version :content-type:content-transfer-encoding; bh=+c6Pw+YMoN1cY463C2KqDq23wIRfMxDYxWNV/glY6YQ=; b=BuFpD3TjNKlO5YkZrd2WoSL+xtRh8E8WKxSb0oC0TfPiw3J9DYzIr6ft7rS/9v7pZa fFUCxIGoMd0Czc+1joYJAeBeJcvflMwwZvt0C7Nq3QctKo7a1Enxqo8N20QruMFGVuBd aSl5wvem3lcDVCFs3DL7AGfJ8u3MvuvfnQy7k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :x-mailer:mime-version:content-type:content-transfer-encoding; b=JoO4TdPsfYkfeyxHA7Ad51rtn08A+g7fgbfa0ybIhqsHxkxoo6Oc2sgQp6sLheyPU3 OdrpZ4jWBVPJg9VdNjj6tR7VkWBajswkExB2bsPSmTzJVC3n9MrYqh/CKUhuHQlADJaO 8WP/6YHLkw4aJSHd8SURADC1g//NBk1Dvsbxk= Received: by 10.223.6.152 with SMTP id 24mr1453195faz.25.1273835543869; Fri, 14 May 2010 04:12:23 -0700 (PDT) Received: from ernst.jennejohn.org (p57AE4DB2.dip.t-dialin.net [87.174.77.178]) by mx.google.com with ESMTPS id g10sm10449459fai.12.2010.05.14.04.12.22 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 14 May 2010 04:12:23 -0700 (PDT) Date: Fri, 14 May 2010 13:12:21 +0200 From: Gary Jennejohn To: Juergen Lock Message-ID: <20100514131221.5669c666@ernst.jennejohn.org> In-Reply-To: <20100513201754.GA36439@triton8.kn-bremen.de> References: <20100511184140.GA3983@triton8.kn-bremen.de> <20100512124234.12f4d156@ernst.jennejohn.org> <20100513201754.GA36439@triton8.kn-bremen.de> X-Mailer: Claws Mail 3.7.5 (GTK+ 2.18.7; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, yokota@FreeBSD.org Subject: Re: [PATCH:] psm(4) IntelliMouse Explorer KVM hack breaks my mouse X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gljennjohn@googlemail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 11:12:25 -0000 On Thu, 13 May 2010 22:17:54 +0200 Juergen Lock wrote: > On Wed, May 12, 2010 at 12:42:34PM +0200, Gary Jennejohn wrote: > > On Tue, 11 May 2010 20:41:41 +0200 > > Juergen Lock wrote: > > > > > So now I made a patch that allows disabling that KVM hack via device > > > hints, appended below. (hint.psm.0.flags="0x10000" - or do you guys > > > think the hack should be disabled by default instead?) > > > > > > > Don't change the behavior, leave it enabled by default. For POLA. > > Yeah ok I guess you are right... > > I've now put the patch on freefall:public_html too, and added links > to the relevant threads for it and the other pending src patches: > > http://people.freebsd.org/~nox/ > Looks good to me FWIW. -- Gary Jennejohn (gj@) From owner-freebsd-current@FreeBSD.ORG Fri May 14 15:06:03 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 033F5106567B; Fri, 14 May 2010 15:06:03 +0000 (UTC) (envelope-from scjamorim@bsd.com.br) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 2DD4F8FC1C; Fri, 14 May 2010 15:06:01 +0000 (UTC) Received: by fxm17 with SMTP id 17so1770069fxm.13 for ; Fri, 14 May 2010 08:06:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.5.89 with SMTP id 25mr1767615fau.87.1273849560966; Fri, 14 May 2010 08:06:00 -0700 (PDT) Sender: scjamorim@bsd.com.br Received: by 10.223.105.136 with HTTP; Fri, 14 May 2010 08:05:59 -0700 (PDT) Date: Fri, 14 May 2010 12:05:59 -0300 X-Google-Sender-Auth: wL0y_m5qQKnftspGMr2xyD5YzaU Message-ID: From: Sylvio Cesar Teixeira To: freebsd-current@freebsd.org, freebsd-questions@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: jeff@FreeBSD.org Subject: cpuset at boot time or separating processes by CPU X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 15:06:03 -0000 Hi list, I'm with a need to run the cpuset for certain processes, for example: run VirtualBox on CPU 1; run firefox on CPU 0; and the other processes are balanced between the CPU 0 and 1. I can do this separation, but only with the root, but I need to do as a regular user. is it possible? Regards, Sylvio Cesar From owner-freebsd-current@FreeBSD.ORG Fri May 14 15:42:45 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1DDE71065672; Fri, 14 May 2010 15:42:45 +0000 (UTC) (envelope-from matthew.fleming@isilon.com) Received: from seaxch09.isilon.com (seaxch09.isilon.com [74.85.160.25]) by mx1.freebsd.org (Postfix) with ESMTP id EF6488FC0A; Fri, 14 May 2010 15:42:44 +0000 (UTC) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 14 May 2010 08:42:44 -0700 Message-ID: <06D5F9F6F655AD4C92E28B662F7F853E021D4D5E@seaxch09.desktop.isilon.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Crash dump problem - sleeping thread owns a non-sleepable lock during crash dump write Thread-Index: AcrzcBgZpUhlL2PhT9OENHWVaOT1DQAChHTp References: <01NN32EOXMYC006UN1@tmk.com> <4BED3912.9080509@FreeBSD.org> <01NN3PQCOFHE006UN1@tmk.com> From: "Matthew Fleming" To: "Terry Kennedy" X-Mailman-Approved-At: Fri, 14 May 2010 17:02:30 +0000 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org, freebsd-stable@FreeBSD.org, John Baldwin Subject: RE: Crash dump problem - sleeping thread owns a non-sleepable lock during crash dump write X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 15:42:45 -0000 > As an aside, this is a quad-core in one package CPU (an X3363). On = both > this box and a similar one with an X5470, console messages continue to > print out after "the system has been halted - press any key to reboot" = - > in particular, the shutdown makes a bunch of the "behind the scenes" = man- > agement stuff like the virtual keyboard and monitor appear. Plugging = or > unplugging USB devices will go through the whole deal of detecting and > making their service available. Oops, youre right that other CPUs are running. The stop_cpus() call is only made if kdb is entered. doadump() is = called out of boot() which comes later. At Isilon weve been running = with a patch that does stop_cpus() pretty close to the front of = panic(9). As an design decision it seems reasonable to call stop_cpus() early in = panic(9) simply because most causes for panic means something = unexpected, and the sooner the other CPUs arent running the more likely = it is that they dont do more damage, leaving the system in a more useful = state for dump or {g,d}db analysis. This should be done before dump or = entering kdb. Im ccing -current@ since I would like a small discussion of moving the = stop_cpus() to earlier in panic. If this change is agreeable I can roll = up a patch and test it on CURRENT. Im not sure yet how much of the = other panic-related changes we have made at Isilon would be required. Thanks, matthew From owner-freebsd-current@FreeBSD.ORG Fri May 14 17:04:59 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EC668106566C; Fri, 14 May 2010 17:04:59 +0000 (UTC) (envelope-from mj@feral.com) Received: from ns1.feral.com (ns1.feral.com [192.67.166.1]) by mx1.freebsd.org (Postfix) with ESMTP id A46908FC19; Fri, 14 May 2010 17:04:59 +0000 (UTC) Received: from [192.168.221.2] (remotevpn [192.168.221.2]) by ns1.feral.com (8.14.3/8.14.3) with ESMTP id o4EH4wfR078128; Fri, 14 May 2010 10:04:58 -0700 (PDT) (envelope-from mj@feral.com) Message-ID: <4BED82BA.4060904@feral.com> Date: Fri, 14 May 2010 10:04:58 -0700 From: Matthew Jacob Organization: Feral Software User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) To: Matthew Fleming References: <01NN32EOXMYC006UN1@tmk.com> <4BED3912.9080509@FreeBSD.org> <01NN3PQCOFHE006UN1@tmk.com> <06D5F9F6F655AD4C92E28B662F7F853E021D4D5E@seaxch09.desktop.isilon.com> In-Reply-To: <06D5F9F6F655AD4C92E28B662F7F853E021D4D5E@seaxch09.desktop.isilon.com> Content-Transfer-Encoding: 7bit X-Greylist: Sender DNS name whitelisted, not delayed by milter-greylist-4.2.3 (ns1.feral.com [192.168.221.1]); Fri, 14 May 2010 10:04:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org, Terry Kennedy Subject: Re: Crash dump problem - sleeping thread owns a non-sleepable lock during crash dump write X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 17:05:00 -0000 Matthew Fleming wrote: As an aside, this is a quad-core in one package CPU (an X3363). On both this box and a similar one with an X5470, console messages continue to print out after "the system has been halted - press any key to reboot" - in particular, the shutdown makes a bunch of the "behind the scenes" man- agement stuff like the virtual keyboard and monitor appear. Plugging or unplugging USB devices will go through the whole deal of detecting and making their service available. Oops, youre right that other CPUs are running. The stop_cpus() call is only made if kdb is entered. doadump() is called out o f boot() which comes later. At Isilon weve been running with a patch that does stop_cpus() pretty close to the front of panic(9). As an design decision it seems reasonable to call stop_cpus() early in panic(9) simply because most causes for panic means something unexpected, and the soone r the other CPUs arent running the more likely it is that they dont do more dam age, leaving the system in a more useful state for dump or {g,d}db analysis. T his should be done before dump or entering kdb. Im ccing -current@ since I would like a small discussion of moving the stop_cpu s() to earlier in panic. If this change is agreeable I can roll up a patch and test it on CURRENT. Im not sure yet how much of the other panic-related chang es we have made at Isilon would be required. Work along this lines has been done at Panasas. We were planning on put it back to the community. There turns out to be lots of edge cases by changing this that we're still sorting thru. From owner-freebsd-current@FreeBSD.ORG Fri May 14 17:20:20 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 915541065674; Fri, 14 May 2010 17:20:20 +0000 (UTC) (envelope-from nox@jelal.kn-bremen.de) Received: from smtp.kn-bremen.de (gelbbaer.kn-bremen.de [78.46.108.116]) by mx1.freebsd.org (Postfix) with ESMTP id 4C5098FC20; Fri, 14 May 2010 17:20:20 +0000 (UTC) Received: by smtp.kn-bremen.de (Postfix, from userid 10) id 3A4361E0013A; Fri, 14 May 2010 19:20:18 +0200 (CEST) Received: from triton8.kn-bremen.de (noident@localhost [127.0.0.1]) by triton8.kn-bremen.de (8.14.3/8.14.3) with ESMTP id o4EHIdHM051501; Fri, 14 May 2010 19:18:39 +0200 (CEST) (envelope-from nox@triton8.kn-bremen.de) Received: (from nox@localhost) by triton8.kn-bremen.de (8.14.3/8.14.3/Submit) id o4EHIdcV051500; Fri, 14 May 2010 19:18:39 +0200 (CEST) (envelope-from nox) From: Juergen Lock Date: Fri, 14 May 2010 19:18:39 +0200 To: Gary Jennejohn Message-ID: <20100514171839.GA51477@triton8.kn-bremen.de> References: <20100511184140.GA3983@triton8.kn-bremen.de> <20100512124234.12f4d156@ernst.jennejohn.org> <20100513201754.GA36439@triton8.kn-bremen.de> <20100514131221.5669c666@ernst.jennejohn.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100514131221.5669c666@ernst.jennejohn.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-current@FreeBSD.org, yokota@FreeBSD.org, Juergen Lock Subject: Re: [PATCH:] psm(4) IntelliMouse Explorer KVM hack breaks my mouse X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 17:20:20 -0000 On Fri, May 14, 2010 at 01:12:21PM +0200, Gary Jennejohn wrote: > On Thu, 13 May 2010 22:17:54 +0200 > Juergen Lock wrote: > > > On Wed, May 12, 2010 at 12:42:34PM +0200, Gary Jennejohn wrote: > > > On Tue, 11 May 2010 20:41:41 +0200 > > > Juergen Lock wrote: > > > > > > > So now I made a patch that allows disabling that KVM hack via device > > > > hints, appended below. (hint.psm.0.flags="0x10000" - or do you guys > > > > think the hack should be disabled by default instead?) > > > > > > > > > > Don't change the behavior, leave it enabled by default. For POLA. > > > > Yeah ok I guess you are right... > > > > I've now put the patch on freefall:public_html too, and added links > > to the relevant threads for it and the other pending src patches: > > > > http://people.freebsd.org/~nox/ > > > > Looks good to me FWIW. Thanx, feel free to commit! :) Juergen From owner-freebsd-current@FreeBSD.ORG Fri May 14 17:39:59 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D48A2106566B; Fri, 14 May 2010 17:39:59 +0000 (UTC) (envelope-from alc@cs.rice.edu) Received: from mail.cs.rice.edu (mail.cs.rice.edu [128.42.1.31]) by mx1.freebsd.org (Postfix) with ESMTP id 8AE808FC1F; Fri, 14 May 2010 17:39:59 +0000 (UTC) Received: from mail.cs.rice.edu (localhost.localdomain [127.0.0.1]) by mail.cs.rice.edu (Postfix) with ESMTP id E10C12C2AAC; Fri, 14 May 2010 12:39:58 -0500 (CDT) X-Virus-Scanned: by amavis-2.4.0 at mail.cs.rice.edu Received: from mail.cs.rice.edu ([127.0.0.1]) by mail.cs.rice.edu (mail.cs.rice.edu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id PJCCPEk0FXfg; Fri, 14 May 2010 12:39:51 -0500 (CDT) Received: from [172.24.99.75] (unknown [192.75.139.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.cs.rice.edu (Postfix) with ESMTP id CE6082C2A81; Fri, 14 May 2010 12:39:50 -0500 (CDT) Message-ID: <4BED8ADE.1030100@cs.rice.edu> Date: Fri, 14 May 2010 12:39:42 -0500 From: Alan Cox User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Benjamin Kaduk References: <20100514053907.GL83316@deviant.kiev.zoral.com.ua> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Kostik Belousov , alc@freebsd.org, freebsd-current@freebsd.org, attilio@freebsd.org Subject: Re: kgdb unuseable with cores on current (for some people) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 17:39:59 -0000 On 5/14/2010 1:44 AM, Benjamin Kaduk wrote: > On Fri, 14 May 2010, Kostik Belousov wrote: > >> On Fri, May 14, 2010 at 12:55:35AM -0400, Benjamin Kaduk wrote: >>> Hi all, >>> >>> As was revealed in a recent thread here [1], several people have been >>> unable to use kgdb on coredumps for the past few months (but >>> possibly not >>> everyone). >>> >>> I am one of those affected, and have narrowed the breakage with a >>> binary >>> search to between SVN revisions 202883 and 202954 (that is, Jan 23 >>> 1200h >>> and Jan 25 0000h). Looking at the changes, alc's revision 202897 and >>> attilio's revision 202933 look to be the most plausible culprits in >>> terms >>> of what they touched. I will continue with my bisection, but with >>> only 36 >>> revisions in play, it is probably worth looking for the bug in parallel >>> with the bisection. >> >> Try reverting r202897 on fresh HEAD. I very much doubt that r202933 >> can be responsible. >> > > Indeed, 202933 was cleared of blame in the latest bisection. I'm > currently pulling up to HEAD and will try reverting 202897. I suspect the following is needed: Index: vm/vm_page.c =================================================================== --- vm/vm_page.c (revision 207823) +++ vm/vm_page.c (working copy) @@ -108,6 +108,7 @@ __FBSDID("$FreeBSD$"); #include #include #include +#include #include #include #include @@ -375,6 +376,14 @@ vm_page_startup(vm_offset_t vaddr) new_end + vm_page_dump_size, VM_PROT_READ | VM_PROT_WRITE); bzero((void *)vm_page_dump, vm_page_dump_size); #endif +#ifdef __amd64__ + pa = DMAP_TO_PHYS((vm_offset_t)msgbufp); + last_pa = pa + round_page(MSGBUF_SIZE); + while (pa < last_pa) { + dump_add_page(pa); + pa += PAGE_SIZE; + } +#endif /* * Compute the number of pages of memory that will be available for * use (taking into account the overhead of a page structure per From owner-freebsd-current@FreeBSD.ORG Fri May 14 18:39:38 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2AFAE1065674; Fri, 14 May 2010 18:39:38 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-7.mit.edu (DMZ-MAILSEC-SCANNER-7.MIT.EDU [18.7.68.36]) by mx1.freebsd.org (Postfix) with ESMTP id C35F08FC13; Fri, 14 May 2010 18:39:37 +0000 (UTC) X-AuditID: 12074424-b7b9dae000002832-dd-4bed98e8a5bc Received: from mailhub-auth-3.mit.edu (MAILHUB-AUTH-3.MIT.EDU [18.9.21.43]) by dmz-mailsec-scanner-7.mit.edu (Symantec Brightmail Gateway) with SMTP id 17.44.10290.8E89DEB4; Fri, 14 May 2010 14:39:36 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id o4EIdaib031958; Fri, 14 May 2010 14:39:36 -0400 Received: from multics.mit.edu (MULTICS.MIT.EDU [18.187.1.73]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id o4EIdY0t004977 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 14 May 2010 14:39:35 -0400 (EDT) Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id o4EIdXNQ012240; Fri, 14 May 2010 14:39:33 -0400 (EDT) Date: Fri, 14 May 2010 14:39:32 -0400 (EDT) From: Benjamin Kaduk To: Alan Cox In-Reply-To: <4BED8ADE.1030100@cs.rice.edu> Message-ID: References: <20100514053907.GL83316@deviant.kiev.zoral.com.ua> <4BED8ADE.1030100@cs.rice.edu> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Brightmail-Tracker: AAAAAA== Cc: Kostik Belousov , alc@freebsd.org, freebsd-current@freebsd.org Subject: Re: kgdb unuseable with cores on current (for some people) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 18:39:38 -0000 On Fri, 14 May 2010, Alan Cox wrote: > On 5/14/2010 1:44 AM, Benjamin Kaduk wrote: >> On Fri, 14 May 2010, Kostik Belousov wrote: >> >>> >>> Try reverting r202897 on fresh HEAD. I very much doubt that r202933 >>> can be responsible. >>> >> >> Indeed, 202933 was cleared of blame in the latest bisection. I'm currently >> pulling up to HEAD and will try reverting 202897. HEAD with 202897 reverted works; HEAD with the patch below does not work Hm, but the "Cannot access memory" is preceeded by "Unread portion of the kernel message buffer:\n"; I don't remember whether that was there before. I'll compile another kernel from stock HEAD to check if that's actually due to the patch (or just poor memory on my part). Any other thoughts, Alan? > > I suspect the following is needed: > > Index: vm/vm_page.c > =================================================================== > --- vm/vm_page.c (revision 207823) > +++ vm/vm_page.c (working copy) > @@ -108,6 +108,7 @@ __FBSDID("$FreeBSD$"); > #include > #include > #include > +#include > #include > #include > #include > @@ -375,6 +376,14 @@ vm_page_startup(vm_offset_t vaddr) > new_end + vm_page_dump_size, VM_PROT_READ | VM_PROT_WRITE); > bzero((void *)vm_page_dump, vm_page_dump_size); > #endif > +#ifdef __amd64__ > + pa = DMAP_TO_PHYS((vm_offset_t)msgbufp); > + last_pa = pa + round_page(MSGBUF_SIZE); > + while (pa < last_pa) { > + dump_add_page(pa); > + pa += PAGE_SIZE; > + } > +#endif > /* > * Compute the number of pages of memory that will be available for > * use (taking into account the overhead of a page structure per > > From owner-freebsd-current@FreeBSD.ORG Fri May 14 19:15:25 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4B8AC1065673; Fri, 14 May 2010 19:15:25 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-8.mit.edu (DMZ-MAILSEC-SCANNER-8.MIT.EDU [18.7.68.37]) by mx1.freebsd.org (Postfix) with ESMTP id DE8958FC08; Fri, 14 May 2010 19:15:24 +0000 (UTC) X-AuditID: 12074425-b7d00ae000002295-d8-4beda14cb4db Received: from mailhub-auth-1.mit.edu (MAILHUB-AUTH-1.MIT.EDU [18.9.21.35]) by dmz-mailsec-scanner-8.mit.edu (Symantec Brightmail Gateway) with SMTP id 10.E4.08853.C41ADEB4; Fri, 14 May 2010 15:15:24 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id o4EJFNSM026973; Fri, 14 May 2010 15:15:24 -0400 Received: from multics.mit.edu (MULTICS.MIT.EDU [18.187.1.73]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id o4EJFMY2014495 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 14 May 2010 15:15:23 -0400 (EDT) Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id o4EJFLjQ012760; Fri, 14 May 2010 15:15:21 -0400 (EDT) Date: Fri, 14 May 2010 15:15:21 -0400 (EDT) From: Benjamin Kaduk To: Alan Cox In-Reply-To: Message-ID: References: <20100514053907.GL83316@deviant.kiev.zoral.com.ua> <4BED8ADE.1030100@cs.rice.edu> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Brightmail-Tracker: AAAAAA== Cc: Kostik Belousov , alc@freebsd.org, freebsd-current@freebsd.org Subject: Re: kgdb unuseable with cores on current (for some people) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 19:15:25 -0000 On Fri, 14 May 2010, Benjamin Kaduk wrote: > > Hm, but the "Cannot access memory" is preceeded by "Unread portion of the > kernel message buffer:\n"; I don't remember whether that was there before. > > I'll compile another kernel from stock HEAD to check if that's actually due > to the patch (or just poor memory on my part). The "Unread portion of the kernel message buffer:" text is new with Alan's patch. So, it seems to be a step in the right direction, but not a full fix. -Ben From owner-freebsd-current@FreeBSD.ORG Fri May 14 18:37:44 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AADA5106566B for ; Fri, 14 May 2010 18:37:44 +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 835068FC0A for ; Fri, 14 May 2010 18:37:44 +0000 (UTC) Received: from tmk.com by tmk.com (PMDF V6.4 #37010) id <01NN3XLDKJ28006UN1@tmk.com>; Fri, 14 May 2010 14:08:24 -0400 (EDT) Date: Fri, 14 May 2010 14:02:47 -0400 (EDT) From: Terry Kennedy In-reply-to: "Your message dated Fri, 14 May 2010 08:42:44 -0700" <06D5F9F6F655AD4C92E28B662F7F853E021D4D5E@seaxch09.desktop.isilon.com> To: Matthew Fleming Message-id: <01NN3XTJDNMS006UN1@tmk.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=iso-8859-1 References: <01NN32EOXMYC006UN1@tmk.com> <4BED3912.9080509@FreeBSD.org> <01NN3PQCOFHE006UN1@tmk.com> X-Mailman-Approved-At: Fri, 14 May 2010 21:23:40 +0000 Cc: freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org, John Baldwin Subject: RE: Crash dump problem - sleeping thread owns a non-sleepable lock during crash dump write X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 18:37:44 -0000 > Oops, youre right that other CPUs are running. > > The stop_cpus() call is only made if kdb is entered. doadump() is called > out of boot() which comes later. At Isilon weve been running with a patch > that does stop_cpus() pretty close to the front of panic(9). This is interesting, and changing the behavior will probably allow the crash dump for the original problem (repeatable crash in the bce driver) to be analyzed. At the moment, I'm more interested in dealing with the original problem of the crash in bce. Right now, I'm running this vendor's product under Linux compatibility mode. The vendor is hard at work building a native FreeBSD version of their product. One of two things is going to happen here: 1) the crash doesn't happen in native mode due to different code paths being taken, and I lose the ability to reproduce the crash when the box goes into production, or 2) the crash continues to happen and the ven- dor gets the impression FreeBSD is unstable and not worth supporting. I'd like to avoid that. So, any ideas on how to troubleshoot the panic in bce? Thanks, Terry Kennedy http://www.tmk.com terry@tmk.com New York, NY USA From owner-freebsd-current@FreeBSD.ORG Sat May 15 02:12:23 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ED00D106564A; Sat, 15 May 2010 02:12:23 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-1.mit.edu (DMZ-MAILSEC-SCANNER-1.MIT.EDU [18.9.25.12]) by mx1.freebsd.org (Postfix) with ESMTP id 5A7638FC0C; Sat, 15 May 2010 02:12:22 +0000 (UTC) X-AuditID: 1209190c-b7bd2ae000005d05-6b-4bee0306d1a4 Received: from mailhub-auth-2.mit.edu (MAILHUB-AUTH-2.MIT.EDU [18.7.62.36]) by dmz-mailsec-scanner-1.mit.edu (Symantec Brightmail Gateway) with SMTP id 2D.37.23813.6030EEB4; Fri, 14 May 2010 22:12:22 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id o4F2CMdC020853; Fri, 14 May 2010 22:12:22 -0400 Received: from multics.mit.edu (MULTICS.MIT.EDU [18.187.1.73]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id o4F2CKvg015130 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 14 May 2010 22:12:21 -0400 (EDT) Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id o4F2CJYt017567; Fri, 14 May 2010 22:12:19 -0400 (EDT) Date: Fri, 14 May 2010 22:12:19 -0400 (EDT) From: Benjamin Kaduk To: Alan Cox In-Reply-To: Message-ID: References: <20100514053907.GL83316@deviant.kiev.zoral.com.ua> <4BED8ADE.1030100@cs.rice.edu> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Brightmail-Tracker: AAAAAA== Cc: Kostik Belousov , alc@freebsd.org, freebsd-current@freebsd.org Subject: Re: kgdb unuseable with cores on current (for some people) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 May 2010 02:12:24 -0000 On Fri, 14 May 2010, Benjamin Kaduk wrote: > On Fri, 14 May 2010, Alan Cox wrote: > >> >> I suspect the following is needed: >> >> Index: vm/vm_page.c >> =================================================================== >> --- vm/vm_page.c (revision 207823) >> +++ vm/vm_page.c (working copy) >> @@ -108,6 +108,7 @@ __FBSDID("$FreeBSD$"); >> #include >> #include >> #include >> +#include >> #include >> #include >> #include >> @@ -375,6 +376,14 @@ vm_page_startup(vm_offset_t vaddr) >> new_end + vm_page_dump_size, VM_PROT_READ | VM_PROT_WRITE); >> bzero((void *)vm_page_dump, vm_page_dump_size); >> #endif >> +#ifdef __amd64__ >> + pa = DMAP_TO_PHYS((vm_offset_t)msgbufp); If I change this to be msgbufp->msg_ptr, then all works as expected. While tracking this down, I realized that passing the -q(uiet) argument to kgdb would have been a valid workaround all along. Alan, could you please commit the modified patch? Thanks, Ben Kaduk >> + last_pa = pa + round_page(MSGBUF_SIZE); >> + while (pa < last_pa) { >> + dump_add_page(pa); >> + pa += PAGE_SIZE; >> + } >> +#endif >> /* >> * Compute the number of pages of memory that will be available for >> * use (taking into account the overhead of a page structure per >> >> > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Sat May 15 10:04:09 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EC23F1065670; Sat, 15 May 2010 10:04:09 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 6238B8FC0A; Sat, 15 May 2010 10:04:08 +0000 (UTC) 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 o4FA4FGV073611 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 15 May 2010 13:04:15 +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.4/8.14.4) with ESMTP id o4FA42wv042472; Sat, 15 May 2010 13:04:02 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o4FA41Ij042471; Sat, 15 May 2010 13:04:01 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 15 May 2010 13:04:01 +0300 From: Kostik Belousov To: freebsd-current@freebsd.org Message-ID: <20100515100401.GT83316@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="8bIXokQePRfDuBGo" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-2.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_50, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-amd64@freebsd.org Subject: AESNI driver and fpu_kern KPI X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 May 2010 10:04:10 -0000 --8bIXokQePRfDuBGo Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hello, please find at http://people.freebsd.org/~kib/misc/aesni.1.patch the combined patch, containing the fpu_kern KPI and Intel AESNI crypto(9) driver. I did development and some testing on the hardware generously provided by Sentex Communications to Netperf cluster. I already posted the kern_fpu part. This is a KPI for x86 arches to denote the region of the kernel code as using the FPU/SSE hardware. I wanted to use the KPI for some in-kernel SSE code to have a proof that interface is useful and up to the task. The crypto(9) driver using AESNI instructions appeared to be a perfect match. Also, the patch should fix the "fpu dna in kernel mode" messages usually appearing when using VIA padlock engine. Padlock does not use FPU resources, but occasionally issues NPX exception if FPU is marked as unavailable due to context switch. I am interested in the problem reports and reviews. Maintainers of !x86-oids are welcome to provide feedback whether they feel that proposed KPI could be implemented on their architectures, or what modifications they consider as needed to be able to implement it. Unless major objections are raised or bugs are found, I plan to commit the fpu_kern KPI shortly. On the other hand, some code in the AESNI driver was derived from the Intel whitepaper, that does not specified a license for the code explicitely. I asked the author of the paper for clarification, he seems to be supportive. In the worst case, aeskeys_{i386,amd64}.S files would be rewritten from scratch. Until the issue is resolved, AESNI part cannot be committed. --8bIXokQePRfDuBGo Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkvucZEACgkQC3+MBN1Mb4hm2gCg7bUL49W0EgcFJMsCtyjUI+x6 WzIAoKc/Pvey+o1xty4W5eGcyWCuohor =IPGe -----END PGP SIGNATURE----- --8bIXokQePRfDuBGo-- From owner-freebsd-current@FreeBSD.ORG Sat May 15 11:04:38 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E83E1106564A for ; Sat, 15 May 2010 11:04:38 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 4FBF08FC17 for ; Sat, 15 May 2010 11:04:37 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.3/8.14.3/ALCHEMY.FRANKEN.DE) with ESMTP id o4FB4aUX007394; Sat, 15 May 2010 13:04:36 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.3/8.14.3/Submit) id o4FB4anT007393; Sat, 15 May 2010 13:04:36 +0200 (CEST) (envelope-from marius) Date: Sat, 15 May 2010 13:04:36 +0200 From: Marius Strobl To: Kostik Belousov Message-ID: <20100515110436.GA7224@alchemy.franken.de> References: <20100515100401.GT83316@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100515100401.GT83316@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org, freebsd-amd64@freebsd.org Subject: Re: AESNI driver and fpu_kern KPI X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 May 2010 11:04:39 -0000 On Sat, May 15, 2010 at 01:04:01PM +0300, Kostik Belousov wrote: > > I am interested in the problem reports and reviews. Maintainers of > !x86-oids are welcome to provide feedback whether they feel that > proposed KPI could be implemented on their architectures, or what > modifications they consider as needed to be able to implement > it. > FYI, sparc64 doesn't need such a KPI as it supports using the FPU in kernel unconditionally for ages. Marius From owner-freebsd-current@FreeBSD.ORG Sat May 15 11:41:57 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 31CD4106566C; Sat, 15 May 2010 11:41:57 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id A46F08FC13; Sat, 15 May 2010 11:41:56 +0000 (UTC) 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 o4FBfQ0U082664 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 15 May 2010 14:41:26 +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.4/8.14.4) with ESMTP id o4FBfCRL042829; Sat, 15 May 2010 14:41:12 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o4FBfCDO042828; Sat, 15 May 2010 14:41:12 +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: Sat, 15 May 2010 14:41:12 +0300 From: Kostik Belousov To: Marius Strobl Message-ID: <20100515114112.GU83316@deviant.kiev.zoral.com.ua> References: <20100515100401.GT83316@deviant.kiev.zoral.com.ua> <20100515110436.GA7224@alchemy.franken.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="FxsMg9mYBDvYslEH" Content-Disposition: inline In-Reply-To: <20100515110436.GA7224@alchemy.franken.de> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-2.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_50, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-current@freebsd.org, freebsd-amd64@freebsd.org Subject: Re: AESNI driver and fpu_kern KPI X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 May 2010 11:41:57 -0000 --FxsMg9mYBDvYslEH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, May 15, 2010 at 01:04:36PM +0200, Marius Strobl wrote: > On Sat, May 15, 2010 at 01:04:01PM +0300, Kostik Belousov wrote: > >=20 > > I am interested in the problem reports and reviews. Maintainers of > > !x86-oids are welcome to provide feedback whether they feel that > > proposed KPI could be implemented on their architectures, or what > > modifications they consider as needed to be able to implement > > it. > >=20 >=20 > FYI, sparc64 doesn't need such a KPI as it supports using the FPU > in kernel unconditionally for ages. How is this done on sparc64 ? Is PSTATE.PEF cleared on kernel entry, or FPU is disabled ? When I researched the problem space, I noted that windows on amd64 also provides an unrestricted access to XMM, while not on i386: http://msdn.microsoft.com/en-us/library/ff545910%28VS.85%29.aspx It seems that windows unconditionally set CR0.TS on kernel-mode entry from usermode. --FxsMg9mYBDvYslEH Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkvuiFgACgkQC3+MBN1Mb4iqgQCgnDzTLp4J2jRphSsSifiVIg7v mRgAnR+dB+TuJYppy1w/D7WR7ngbr1bS =xSd4 -----END PGP SIGNATURE----- --FxsMg9mYBDvYslEH-- From owner-freebsd-current@FreeBSD.ORG Sat May 15 13:23:20 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 276E9106566B for ; Sat, 15 May 2010 13:23:20 +0000 (UTC) (envelope-from taku@tackymt.homeip.net) Received: from basalt.tackymt.homeip.net (unknown [IPv6:2001:3e0:577:0:20d:61ff:fecc:2253]) by mx1.freebsd.org (Postfix) with ESMTP id B993C8FC08 for ; Sat, 15 May 2010 13:23:19 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by basalt.tackymt.homeip.net (Postfix) with ESMTP id CF8B410765; Sat, 15 May 2010 22:23:18 +0900 (JST) X-Virus-Scanned: amavisd-new at tackymt.homeip.net Received: from localhost ([127.0.0.1]) by localhost (basalt.tackymt.homeip.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uix5CHm6yANa; Sat, 15 May 2010 22:23:17 +0900 (JST) Received: from basalt.tackymt.homeip.net (basalt.tackymt.homeip.net [IPv6:2001:3e0:577:0:20d:61ff:fecc:2253]) by basalt.tackymt.homeip.net (Postfix) with ESMTP; Sat, 15 May 2010 22:23:17 +0900 (JST) Date: Sat, 15 May 2010 22:23:17 +0900 From: Taku YAMAMOTO To: Jack Vogel Message-Id: <20100515222317.2db5bab5.taku@tackymt.homeip.net> In-Reply-To: <20100501171252.e05f257f.taku@tackymt.homeip.net> References: <20100501171252.e05f257f.taku@tackymt.homeip.net> X-Mailer: Sylpheed 2.4.8 (GTK+ 2.16.6; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Followup: if_em.c prevents the 2nd time resuming X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 May 2010 13:23:20 -0000 PR filed as kern/146614. http://www.freebsd.org/cgi/query-pr.cgi?pr=146614 -- -|-__ YAMAMOTO, Taku | __ < - A chicken is an egg's way of producing more eggs. - From owner-freebsd-current@FreeBSD.ORG Sat May 15 15:02:52 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B14DE106566C; Sat, 15 May 2010 15:02:52 +0000 (UTC) (envelope-from gperez@entel.upc.edu) Received: from dash.upc.es (dash.upc.es [147.83.2.50]) by mx1.freebsd.org (Postfix) with ESMTP id 274C28FC13; Sat, 15 May 2010 15:02:51 +0000 (UTC) Received: from ackerman2.upc.es (ackerman2.upc.es [147.83.2.244]) by dash.upc.es (8.14.1/8.13.1) with ESMTP id o4FF2ni0018214 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 15 May 2010 17:02:49 +0200 Received: from [192.168.100.187] (100.Red-79-144-109.dynamicIP.rima-tde.net [79.144.109.100]) (authenticated bits=0) by ackerman2.upc.es (8.13.8/8.13.8) with ESMTP id o4FF2gb6029688 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 15 May 2010 17:02:48 +0200 Message-ID: <4BEEB792.3040105@entel.upc.edu> Date: Sat, 15 May 2010 17:02:42 +0200 From: =?UTF-8?B?R3VzdGF1IFDDqXJleg==?= User-Agent: Thunderbird 2.0.0.24 (X11/20100509) MIME-Version: 1.0 To: Weongyo Jeong , current@freebsd.org References: <20100228095259.GB3536@weongyo> <20100301103240.3a4aac8a.ray@dlink.ua> <20100303082833.GB22865@weongyo> <20100303111014.6564ea1e.ray@dlink.ua> <20100312231333.GZ1295@weongyo> <4BD2201E.3090409@entel.upc.edu> <20100424231755.GI65380@weongyo> <4BD4A928.8020901@entel.upc.edu> <20100506190653.GA31100@weongyo> <58220.88.15.97.205.1273248485.squirrel@webmail.entel.upc.edu> <20100510195622.GA1295@weongyo> In-Reply-To: <20100510195622.GA1295@weongyo> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.63 on 147.83.2.244 X-Mail-Scanned: Criba 2.0 + Clamd X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (dash.upc.es [147.83.2.50]); Sat, 15 May 2010 17:02:50 +0200 (CEST) Cc: Subject: Re: Call for Test and Review: bwn(4) - another Broadcom Wireless driver X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 May 2010 15:02:52 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 En/na Weongyo Jeong ha escrit: > On Fri, May 07, 2010 at 06:08:05PM +0200, Gustavo Perez Querol wrote: >>> Hello Gustau, I'm so sorry for belated response that I had no time to >>> read and work email and wireless stuffs. >>> >>> Could you please test this symptom with attached patch? It looks in >>> CURRENT it missed to initialize a ratectl when it associates with AP. >>> >> The patch made the machine to panic. I think it happened when launching >> the supplicant. In fact, right now it works by putting the RF switch to >> OFF. As soon as I change it to ON the machine panics. >> >> It get a trap 12, with two reasons : page fault and "bufwrite, buffer is >> not busy?" >> >> I'm running 9.0/AMD64 from 1 of May (don't know exact svn revision). >> >> Do you want me to test anything else ? > > OK. The patch is ready to test. Could you please test it with attached > patch? > > regards, > Weongyo Jeong > It worked fine with current. I still haven't tested it a few hours, let's see if it works. Thanks ! However, right now I'm testing zfs with the same laptop (with a different HDD) and unfortunately I'm seeing the same with STABLE. Tons of : "bwn0: unsupported rate 0" I wonder if the patch you sent will work with stable's source code ... Regards, Gustau - -- PGP KEY : http://www-entel.upc.edu/gus/gus.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJL7reSAAoJEH+VVM1WSYnPPh0P/1u/Z/RPR/8nworwJw7SDCtb q+2ZI2171LnbMKVYPPsIxeuRMCV6w0M7pzizMJ7hdbW9XRz2PSdcubFa+WutTYZx 3k+AZMjJObM/9gLKveqmTLkz16Pc8WsNOSaxWbDKsxGhF0/CZ6hH7y5iiAdN/UTB eVSRSFVrqXRgtGBrKvMM0LvhGJM+l7txHxjSoHLF3zXAQYmggt7jo+3qUCe3m17J 8Wm2An3l9wPfCmtUbXF/6tJpUmtqqopRZSV7LjmpWuqk8w4JIajt5YTVn9F7w0ZX iB12mTYamWy4ZzFsIg0Tbj/x68XbVDgR5RoNSPsSbqO85C9CP/Nx6R+U9lIye40+ rOX/ApXjM87S7uoDSLjDAc706KZGo56O6tpopazGpoTgtyH5dCoSumRUEucz3zJJ wMIahSK4TyGjO0Nz/dRxqIjPZbxQ2DSbC0KaiCHakWD+aYvNC7i6gC8Hfnx1Z3C2 8XoSiJo/SyfmC0lfzKvz+RzXLifJWRLrY9QbPYvKhrfwHquoAU3hDVS62Slyjrg6 hdGxx3pXK2gr8+vjeKC/k3lVl/h39oQfYEoIhuduur9v2H3ftqNlqWfi3Q4SRL9a 89BEZCvL6F1F/TzrAIZUIr1iLPAbWsQBxyhkqeSqWFpokgLDZ2nsJU8oPsr5ls/Q Wef0yTu4lulwIXYUtBol =wEO7 -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Sat May 15 16:55:25 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EF5671065675 for ; Sat, 15 May 2010 16:55:25 +0000 (UTC) (envelope-from jamesbrandongooch@gmail.com) Received: from mail-pz0-f174.google.com (mail-pz0-f174.google.com [209.85.222.174]) by mx1.freebsd.org (Postfix) with ESMTP id C44F68FC13 for ; Sat, 15 May 2010 16:55:25 +0000 (UTC) Received: by pzk4 with SMTP id 4so1998880pzk.7 for ; Sat, 15 May 2010 09:55:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=P3CGBqHwCSVOyqp6K9zpRaiP4L3L88+y8bPSCm8oZjs=; b=WXUXPec9NaX2ehkJ4VFP8J744H3BNoRVgnYcBL6nzlhhY2Lb5JHNPTjg3JBDPYqtnS AaJCJGnj2/t8cTMNvSPnyUG5t6fdS5dYM06s8tlU2qsCMJmo3Y/V2Sm53JF/bXtezPXo eH5UEkdtZ63usREgBuDcvW/Dd8U9Gxy3ZvIkw= 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; b=jEeOFt9WfVqTfgsM26a+oRorrCuSVZGfkjyNtArzLgD5aLk30B6pZkbb97ArtV5Jwz sis73gMgGhYLQUX4C1khU3svmqCLjCixUOYy2ihS5RUbunQwir50M8vMAqy8ZbhSl5bK HeXDIa4ErWRvlwbFBoFSpMPb1dBie2mtfjFCA= MIME-Version: 1.0 Received: by 10.142.65.22 with SMTP id n22mr1726369wfa.86.1273942524591; Sat, 15 May 2010 09:55:24 -0700 (PDT) Received: by 10.142.52.15 with HTTP; Sat, 15 May 2010 09:55:24 -0700 (PDT) In-Reply-To: <20100515222317.2db5bab5.taku@tackymt.homeip.net> References: <20100501171252.e05f257f.taku@tackymt.homeip.net> <20100515222317.2db5bab5.taku@tackymt.homeip.net> Date: Sat, 15 May 2010 11:55:24 -0500 Message-ID: From: Brandon Gooch To: Taku YAMAMOTO Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org, Jack Vogel Subject: Re: Followup: if_em.c prevents the 2nd time resuming X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 May 2010 16:55:26 -0000 On Sat, May 15, 2010 at 8:23 AM, Taku YAMAMOTO wrote: > PR filed as kern/146614. > http://www.freebsd.org/cgi/query-pr.cgi?pr=146614 Thanks brother! I didn't know exactly how to fix it -- I just commented the code out! Gad someone did (no offense Jack, you're still THE MAN!!!) ;) -Brandon From owner-freebsd-current@FreeBSD.ORG Sat May 15 19:48:15 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 16BD31065670 for ; Sat, 15 May 2010 19:48:15 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 74E2F8FC0A for ; Sat, 15 May 2010 19:48:14 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.3/8.14.3/ALCHEMY.FRANKEN.DE) with ESMTP id o4FJmDKo010741; Sat, 15 May 2010 21:48:13 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.3/8.14.3/Submit) id o4FJmCdI010740; Sat, 15 May 2010 21:48:12 +0200 (CEST) (envelope-from marius) Date: Sat, 15 May 2010 21:48:12 +0200 From: Marius Strobl To: Taku YAMAMOTO Message-ID: <20100515194812.GA10554@alchemy.franken.de> References: <20100501171252.e05f257f.taku@tackymt.homeip.net> <20100515222317.2db5bab5.taku@tackymt.homeip.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100515222317.2db5bab5.taku@tackymt.homeip.net> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org, Jack Vogel Subject: Re: Followup: if_em.c prevents the 2nd time resuming X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 May 2010 19:48:15 -0000 On Sat, May 15, 2010 at 10:23:17PM +0900, Taku YAMAMOTO wrote: > PR filed as kern/146614. > http://www.freebsd.org/cgi/query-pr.cgi?pr=146614 > That was an mismerge introduced when moving the original patch forward to a newer version of the e1000 source. It's now fixed. Thanks for reporting. Marius From owner-freebsd-current@FreeBSD.ORG Sat May 15 21:13:08 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A416A1065675 for ; Sat, 15 May 2010 21:13:08 +0000 (UTC) (envelope-from weongyo.jeong@gmail.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 6B9708FC0C for ; Sat, 15 May 2010 21:13:08 +0000 (UTC) Received: by pwi9 with SMTP id 9so2215798pwi.13 for ; Sat, 15 May 2010 14:13:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:mail-followup-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent:organization:x-operation-sytem; bh=ogCdiiynZxCQ98ZYbuJpURiuCEt6e1VhPl/fJyO030I=; b=iIuMhWb2MlIbxWO0fm0n4HPhNRBhzy207jnxdt3SpCNGw+OPxy3AMueX2PI8K4orS0 Xc9JFY9mo5RUoZAL3941coNgNkRpWEk6HZdXBtfJ6UHCvvY96MSk5VrAsdVF/3BCShHh wErz5aA1wNbMidSc7kURSy6S1WBUz4y7ENWQQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:mail-followup-to :references:mime-version:content-type:content-disposition :in-reply-to:user-agent:organization:x-operation-sytem; b=wcReqHSWfme50IChv0HAumq5BKReq1jYQ5Ew6mAN09FpvQT787kt55hpHZM2Th4kdQ 9JIpw1dBA+YsYzMjqleXsM5/T3JWdkWrem55kx71CBRuGeGtdYyozNlvnkJOVz+uksls +OaSdfMGx18Y47qkVd5srS8iXanKxS6P++Wpg= Received: by 10.115.67.11 with SMTP id u11mr2551490wak.196.1273957987909; Sat, 15 May 2010 14:13:07 -0700 (PDT) Received: from weongyo ([174.35.1.224]) by mx.google.com with ESMTPS id c14sm32968434waa.1.2010.05.15.14.13.06 (version=SSLv3 cipher=RC4-MD5); Sat, 15 May 2010 14:13:06 -0700 (PDT) Received: by weongyo (sSMTP sendmail emulation); Sat, 15 May 2010 14:13:12 -0700 From: Weongyo Jeong Date: Sat, 15 May 2010 14:13:12 -0700 To: Gustau P??rez Message-ID: <20100515211312.GB1295@weongyo> Mail-Followup-To: Gustau P??rez , current@freebsd.org References: <20100303082833.GB22865@weongyo> <20100303111014.6564ea1e.ray@dlink.ua> <20100312231333.GZ1295@weongyo> <4BD2201E.3090409@entel.upc.edu> <20100424231755.GI65380@weongyo> <4BD4A928.8020901@entel.upc.edu> <20100506190653.GA31100@weongyo> <58220.88.15.97.205.1273248485.squirrel@webmail.entel.upc.edu> <20100510195622.GA1295@weongyo> <4BEEB792.3040105@entel.upc.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BEEB792.3040105@entel.upc.edu> User-Agent: Mutt/1.4.2.3i Organization: CDNetworks. X-Operation-Sytem: FreeBSD Cc: current@freebsd.org Subject: Re: Call for Test and Review: bwn(4) - another Broadcom Wireless driver X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Weongyo Jeong List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 May 2010 21:13:08 -0000 On Sat, May 15, 2010 at 05:02:42PM +0200, Gustau P??rez wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > En/na Weongyo Jeong ha escrit: > > On Fri, May 07, 2010 at 06:08:05PM +0200, Gustavo Perez Querol wrote: > >>> Hello Gustau, I'm so sorry for belated response that I had no time to > >>> read and work email and wireless stuffs. > >>> > >>> Could you please test this symptom with attached patch? It looks in > >>> CURRENT it missed to initialize a ratectl when it associates with AP. > >>> > >> The patch made the machine to panic. I think it happened when launching > >> the supplicant. In fact, right now it works by putting the RF switch to > >> OFF. As soon as I change it to ON the machine panics. > >> > >> It get a trap 12, with two reasons : page fault and "bufwrite, buffer is > >> not busy?" > >> > >> I'm running 9.0/AMD64 from 1 of May (don't know exact svn revision). > >> > >> Do you want me to test anything else ? > > > > OK. The patch is ready to test. Could you please test it with attached > > patch? > > > > regards, > > Weongyo Jeong > > > > It worked fine with current. I still haven't tested it a few hours, > let's see if it works. Thanks ! > > However, right now I'm testing zfs with the same laptop (with a > different HDD) and unfortunately I'm seeing the same with STABLE. > Tons of : > > "bwn0: unsupported rate 0" > > I wonder if the patch you sent will work with stable's source code ... Recently the ratectl framwork was MFC to STABLE_8 so it could cause this problem. I'll MFC my patch to STABLE_8 as soon as possible. regards, Weongyo Jeong From owner-freebsd-current@FreeBSD.ORG Sat May 15 21:30:36 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 43A6D106566B for ; Sat, 15 May 2010 21:30:36 +0000 (UTC) (envelope-from weongyo.jeong@gmail.com) Received: from mail-pz0-f174.google.com (mail-pz0-f174.google.com [209.85.222.174]) by mx1.freebsd.org (Postfix) with ESMTP id 0A3B48FC17 for ; Sat, 15 May 2010 21:30:35 +0000 (UTC) Received: by pzk4 with SMTP id 4so2059080pzk.7 for ; Sat, 15 May 2010 14:30:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:mail-followup-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent:organization:x-operation-sytem; bh=F650BJPk/LTOKL91mh3n4/++yUzRyUzG09X8wpX5qAg=; b=VuzMyE33il2aw2QgrWBV6Tei8RDm+sGYuqoRVB6AlUZrbDHGSxfElw5S3OJwrpiraa UNmpcVzEQ36o+Iu0wTec85+ti2sDDvdZzBhbdDfAL1UMbH+8IvlGx6uPBi3sn+ENVe6v Ik8SeeZb9QHGDb9HnLXNWGO/yiGum0CrBEiL4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:mail-followup-to :references:mime-version:content-type:content-disposition :in-reply-to:user-agent:organization:x-operation-sytem; b=VZF3UrFNcnu3vegHdZuq4W2kyUUd38c/HO0fgt5mnBsjHCmd087OqjhgBlMIfBYRDA tGCX3nygPz0FiViIE8BlVJds/pLas9U2W17bPTaZwksvaCOdWb+npNCAE02Nsn7EzSSY izPjvh1foJRZuCjzubgZYXvDviUOwJKB/TpUM= Received: by 10.141.110.6 with SMTP id n6mr2082497rvm.163.1273959035548; Sat, 15 May 2010 14:30:35 -0700 (PDT) Received: from weongyo ([174.35.1.224]) by mx.google.com with ESMTPS id g14sm3099813rvb.1.2010.05.15.14.30.33 (version=SSLv3 cipher=RC4-MD5); Sat, 15 May 2010 14:30:34 -0700 (PDT) Received: by weongyo (sSMTP sendmail emulation); Sat, 15 May 2010 14:30:39 -0700 From: Weongyo Jeong Date: Sat, 15 May 2010 14:30:39 -0700 To: Ian FREISLICH Message-ID: <20100515213039.GC1295@weongyo> Mail-Followup-To: Ian FREISLICH , Gustavo Perez Querol , current@freebsd.org References: <20100301103240.3a4aac8a.ray@dlink.ua> <20100303082833.GB22865@weongyo> <20100303111014.6564ea1e.ray@dlink.ua> <20100312231333.GZ1295@weongyo> <4BD2201E.3090409@entel.upc.edu> <20100424231755.GI65380@weongyo> <4BD4A928.8020901@entel.upc.edu> <20100506190653.GA31100@weongyo> <58220.88.15.97.205.1273248485.squirrel@webmail.entel.upc.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Organization: CDNetworks. X-Operation-Sytem: FreeBSD Cc: Gustavo Perez Querol , current@freebsd.org Subject: Re: Call for Test and Review: bwn(4) - another Broadcom Wireless driver X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Weongyo Jeong List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 May 2010 21:30:36 -0000 On Tue, May 11, 2010 at 10:04:34AM +0200, Ian FREISLICH wrote: > Ian FREISLICH wrote: > > Weongyo Jeong wrote: > > > > Do you want me to test anything else ? > > > > > > OK. The patch is ready to test. Could you please test it with attached > > > patch? > > > > No panic this time. I also don't get these messages any more: > > > > May 10 23:25:36 mini kernel: bwn0: unsupported rate 0 > > May 10 23:26:13 mini last message repeated 2 times > > May 10 23:28:29 mini last message repeated 320 times > > May 10 23:28:32 mini last message repeated 61 times > > May 10 23:29:42 mini shutdown: reboot by ianf: > > > > It still doesn't associate with my AP until I destroy the wlan > > interface and create it again: > > But, after about 12 hours it reduced the rate to 36mbit/s OFDM with > large amounts of time either not transmitting or not recieving - > 86% packet loss over 5 minutes. The rate change to 36 MBit/s is a normal operation depending on the rate control algorithm. But the packet loss could be a problem so I think we need to narrow down this issue why this happens. regards, Weongyo Jeong From owner-freebsd-current@FreeBSD.ORG Sat May 15 21:35:26 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 23CED1065673 for ; Sat, 15 May 2010 21:35:26 +0000 (UTC) (envelope-from weongyo.jeong@gmail.com) Received: from mail-pz0-f174.google.com (mail-pz0-f174.google.com [209.85.222.174]) by mx1.freebsd.org (Postfix) with ESMTP id DD7138FC16 for ; Sat, 15 May 2010 21:35:25 +0000 (UTC) Received: by pzk4 with SMTP id 4so2060012pzk.7 for ; Sat, 15 May 2010 14:35:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:mail-followup-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent:organization:x-operation-sytem; bh=Pdvi7GT7aiXou6pAvwtyNcCj+ilf5efFiJDTQGn7I3o=; b=eOf2hR6WwoWcFynuEOYtlpR9hNk8bHtYMw44zv737dZevSE8FKPLXtwEA82NZvt07K UpEDEdcFMJOS/biDcJtPw7MNq5sy/nPb44w1ACfT87djMEaKe+dBeDqoLQO4Ga7qcjxD XOPQD5E78ilafQOsA/8QaXjc6CWNJn21+FtpA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:mail-followup-to :references:mime-version:content-type:content-disposition :in-reply-to:user-agent:organization:x-operation-sytem; b=S38y+oRIgf4/+DdQmv/Ble3cCDqfLSG9XNX9hS/5N3pe4KqSinkKlPi9TTEFFufWx1 tK2RSspJ76Ib9WIXOODUN8uABfsY9aClnUxhk0w6KoslAyYl75f54HajVArrksRxtfJH r27hJUHPcssTwRXE0pW7mfUupt9k2XyC8PwE8= Received: by 10.141.4.8 with SMTP id g8mr2094379rvi.87.1273959325400; Sat, 15 May 2010 14:35:25 -0700 (PDT) Received: from weongyo ([174.35.1.224]) by mx.google.com with ESMTPS id b12sm3104484rvn.10.2010.05.15.14.35.23 (version=SSLv3 cipher=RC4-MD5); Sat, 15 May 2010 14:35:24 -0700 (PDT) Received: by weongyo (sSMTP sendmail emulation); Sat, 15 May 2010 14:35:30 -0700 From: Weongyo Jeong Date: Sat, 15 May 2010 14:35:29 -0700 To: Ian FREISLICH Message-ID: <20100515213529.GD1295@weongyo> Mail-Followup-To: Ian FREISLICH , Gustavo Perez Querol , current@freebsd.org References: <20100301103240.3a4aac8a.ray@dlink.ua> <20100303082833.GB22865@weongyo> <20100303111014.6564ea1e.ray@dlink.ua> <20100312231333.GZ1295@weongyo> <4BD2201E.3090409@entel.upc.edu> <20100424231755.GI65380@weongyo> <4BD4A928.8020901@entel.upc.edu> <20100506190653.GA31100@weongyo> <58220.88.15.97.205.1273248485.squirrel@webmail.entel.upc.edu> <4be87dcd.a788d80a.70dd.7416SMTPIN_ADDED@mx.google.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4be87dcd.a788d80a.70dd.7416SMTPIN_ADDED@mx.google.com> User-Agent: Mutt/1.4.2.3i Organization: CDNetworks. X-Operation-Sytem: FreeBSD Cc: Gustavo Perez Querol , current@freebsd.org Subject: Re: Call for Test and Review: bwn(4) - another Broadcom Wireless driver X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Weongyo Jeong List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 May 2010 21:35:26 -0000 On Mon, May 10, 2010 at 11:41:34PM +0200, Ian FREISLICH wrote: > Weongyo Jeong wrote: > > > Do you want me to test anything else ? > > > > OK. The patch is ready to test. Could you please test it with attached > > patch? > > No panic this time. I also don't get these messages any more: > > May 10 23:25:36 mini kernel: bwn0: unsupported rate 0 > May 10 23:26:13 mini last message repeated 2 times > May 10 23:28:29 mini last message repeated 320 times > May 10 23:28:32 mini last message repeated 61 times > May 10 23:29:42 mini shutdown: reboot by ianf: > > It still doesn't associate with my AP until I destroy the wlan > interface and create it again: Could you please show me your setup and steps you did? It would be helpful if you give me a typescript file using script(1). regards, Weongyo Jeong From owner-freebsd-current@FreeBSD.ORG Sat May 15 22:06:48 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A75DB1065670 for ; Sat, 15 May 2010 22:06:48 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 70C4A8FC15 for ; Sat, 15 May 2010 22:06:48 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 90A8573098; Sun, 16 May 2010 00:18:01 +0200 (CEST) Date: Sun, 16 May 2010 00:18:01 +0200 From: Luigi Rizzo To: current@freebsd.org Message-ID: <20100515221801.GA25152@onelab2.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: Subject: missing /usr/lib/liblzma.a during HEAD buildworld ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 May 2010 22:06:48 -0000 Hi, building HEAD on my laptop (stable/7 approx jun 2009) fails with the following error: sh /usr/home/luigi/FreeBSD/head/tools/install.sh -o root -g wheel -m 444 fr.ISO8859-1-s /home/luigi/FreeBSD/obj_head/usr/home/luigi/FreeBSD/head/tmp/legacy/usr/share/tmac/mdoc/fr.ISO8859-1 sh /usr/home/luigi/FreeBSD/head/tools/install.sh -o root -g wheel -m 444 ru.KOI8-R-s /home/luigi/FreeBSD/obj_head/usr/home/luigi/FreeBSD/head/tmp/legacy/usr/share/tmac/mdoc/ru.KOI8-R ===> usr.bin/ar (obj,depend,all,install) make: don't know how to make /usr/lib/liblzma.a. Stop *** Error code 2 Stop in /usr/home/luigi/FreeBSD/head. *** Error code 1 The build apparently works fine on my desktop, still stable/7 from Sep.2009) Any idea on what could be wrong ? cheers luigi From owner-freebsd-current@FreeBSD.ORG Sat May 15 23:10:14 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8025F106564A for ; Sat, 15 May 2010 23:10:14 +0000 (UTC) (envelope-from rbgarga@gmail.com) Received: from mail-ww0-f54.google.com (mail-ww0-f54.google.com [74.125.82.54]) by mx1.freebsd.org (Postfix) with ESMTP id 175F08FC16 for ; Sat, 15 May 2010 23:10:13 +0000 (UTC) Received: by wwb34 with SMTP id 34so185361wwb.13 for ; Sat, 15 May 2010 16:10:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=CXfNJvFos5fBj/JP+Gu/FfNjtqhiYZBoSU//SUCQlio=; b=HpWKRpns94eu9QXRNkL/xxHsWE21xSGVT+2p2gbgpGpp/U5jIIhSXdM2+W4zJjciyp 9nEXEWjD2L/qMuR8KAegmVf5XS1n1t9n4UHBvsHB8S80tfptV3rTBDwC+2Pc5s96Ty9B YZ7RjHpDK05xt1yIGHbUndnrErPPatXI5nQI0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=G/gtaXZiUTLSyFpfk/QlepIhpH87r8NGkW5g9lwZH/bC6n2xniR4uUxlHvwqUqXSvW Yfzv9EdsNBaCzn9mWwR4hb2fhZax3mH/JoCRiEsQrayqlQIDYjc5dnQqQ+xbrbmVUQEo JrwvVakF8R1dOB1vSytzXfd+0u9WsR9OU7tQU= Received: by 10.216.185.209 with SMTP id u59mr1951057wem.112.1273965012614; Sat, 15 May 2010 16:10:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.161.146 with HTTP; Sat, 15 May 2010 16:09:52 -0700 (PDT) In-Reply-To: <20100515221801.GA25152@onelab2.iet.unipi.it> References: <20100515221801.GA25152@onelab2.iet.unipi.it> From: Renato Botelho Date: Sat, 15 May 2010 19:09:52 -0400 Message-ID: To: Luigi Rizzo Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Current Subject: Re: missing /usr/lib/liblzma.a during HEAD buildworld ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 May 2010 23:10:14 -0000 On Sat, May 15, 2010 at 6:18 PM, Luigi Rizzo wrote: > Hi, > building HEAD on my laptop (stable/7 approx jun 2009) > fails with the following error: > > sh /usr/home/luigi/FreeBSD/head/tools/install.sh -o root -g wheel -m 444 = =A0fr.ISO8859-1-s /home/luigi/FreeBSD/obj_head/usr/home/luigi/FreeBSD/head/= tmp/legacy/usr/share/tmac/mdoc/fr.ISO8859-1 > sh /usr/home/luigi/FreeBSD/head/tools/install.sh -o root -g wheel -m 444 = =A0ru.KOI8-R-s /home/luigi/FreeBSD/obj_head/usr/home/luigi/FreeBSD/head/tmp= /legacy/usr/share/tmac/mdoc/ru.KOI8-R > =3D=3D=3D> usr.bin/ar (obj,depend,all,install) > make: don't know how to make /usr/lib/liblzma.a. Stop > *** Error code 2 > > Stop in /usr/home/luigi/FreeBSD/head. > *** Error code 1 > > The build apparently works fine on my desktop, still stable/7 from Sep.20= 09) > > Any idea on what could be wrong ? http://lists.freebsd.org/pipermail/freebsd-current/2010-May/017250.html --=20 Renato Botelho