From owner-freebsd-arm@FreeBSD.ORG Sun Nov 23 02:17:45 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B1F543BE for ; Sun, 23 Nov 2014 02:17:45 +0000 (UTC) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8AEAE2D5 for ; Sun, 23 Nov 2014 02:17:44 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id sAN1v3Sg034973; Sun, 23 Nov 2014 01:57:03 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.108] (gateway.kientzle.com [192.168.1.65]) by kientzle.com with SMTP id bhdjiyhgn4jnchjqw2zccrbq4s; Sun, 23 Nov 2014 01:57:03 +0000 (UTC) (envelope-from tim@kientzle.com) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Subject: Re: latest VM images fail to compile for ARM From: Tim Kientzle In-Reply-To: <54710D7D.3000303@foxvalley.net> Date: Sat, 22 Nov 2014 17:57:03 -0800 Message-Id: <6C5FAA6F-B1B1-4499-8C0F-73C26D6D35C9@kientzle.com> References: <54710D7D.3000303@foxvalley.net> To: Dan Raymond X-Mailer: Apple Mail (2.1993) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Nov 2014 02:17:45 -0000 > On Nov 22, 2014, at 2:26 PM, Dan Raymond wrote: > > I am getting errors while building xdev. What errors? From owner-freebsd-arm@FreeBSD.ORG Sun Nov 23 02:22:03 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C309C595 for ; Sun, 23 Nov 2014 02:22:03 +0000 (UTC) Received: from mail.FoxValley.net (mail.FoxValley.net [64.135.192.34]) by mx1.freebsd.org (Postfix) with SMTP id 8B04538D for ; Sun, 23 Nov 2014 02:22:03 +0000 (UTC) Received: (qmail 18121 invoked from network) for freebsd-arm@freebsd.org; 22 Nov 2014 20:22:02 -0600 Received: from 71-211-193-1.hlrn.qwest.net (HELO ?192.168.1.3?) (draymond@71.211.193.1) by mail.foxvalley.net with SMTP; 22 Nov 2014 20:22:01 -0600 Message-ID: <547144C5.5090002@foxvalley.net> Date: Sat, 22 Nov 2014 19:21:57 -0700 From: Dan Raymond User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Tim Kientzle Subject: Re: latest VM images fail to compile for ARM References: <54710D7D.3000303@foxvalley.net> <6C5FAA6F-B1B1-4499-8C0F-73C26D6D35C9@kientzle.com> In-Reply-To: <6C5FAA6F-B1B1-4499-8C0F-73C26D6D35C9@kientzle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Nov 2014 02:22:03 -0000 On 11/22/2014 6:57 PM, Tim Kientzle wrote: > >> On Nov 22, 2014, at 2:26 PM, Dan Raymond > > wrote: >> >> I am getting errors while building xdev. > > What errors? The first error was that it couldn't find 'gperf'. When I ran it again it gave me a different error but I don't recall the details. Let me know if you need a log and I will set up another VM to get it. From owner-freebsd-arm@FreeBSD.ORG Sun Nov 23 15:50:40 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 03FBFC33 for ; Sun, 23 Nov 2014 15:50:40 +0000 (UTC) Received: from mailgate-02.zdv.uni-mainz.de (mailgate-02.zdv.Uni-Mainz.DE [IPv6:2001:4c80:40:62d:203:ffff:fe5d:b2f6]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "IronPort Appliance Demo Certificate", Issuer "IronPort Appliance Demo Certificate" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 22414315 for ; Sun, 23 Nov 2014 15:50:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uni-mainz.de; i=@uni-mainz.de; q=dns/txt; s=ironport; t=1416757837; x=1448293837; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=VZos2UyY2yRwl2HVxhcVV6ICCuhP3MSIFCEhHOeUovM=; b=LOkyoUNw3fWV9wf0Uj7jyFRfwZtynQEmVrEJt4u1UaRob8RZPZEoSoIx MdVtjXCK/68o9yyX9bTC2mjZLJpIJ+78Xmv8lYYZHp2kNxoy3KvaT+xMO LsSskeIyZO+PoJ1CI4cV1vDlyQrNaDW4wGSrEjYzV+Q2mwibhyJnH42dZ E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AogJAAgBclQKXgZQ/2dsb2JhbABcDgiCVXhZBIMCyG8KhhVVAhx9AQEBAQF9hAIBAQEDAQEBASARGiALDAQCAQgOAwQBAQECAiMDAgICJQEJARQBCAgCBAgCBAEEAQcSAQIEiBcJAQy3QJUyAQEBAQYBAQEBAQEBARqBLYlEhTIXAQEBMxsHBoIyQRKBQwWXTYQnhEE/hhJAikuECoICIIEbQHgBAQEEgQg5gQMBAQE X-IPAS-Result: AogJAAgBclQKXgZQ/2dsb2JhbABcDgiCVXhZBIMCyG8KhhVVAhx9AQEBAQF9hAIBAQEDAQEBASARGiALDAQCAQgOAwQBAQECAiMDAgICJQEJARQBCAgCBAgCBAEEAQcSAQIEiBcJAQy3QJUyAQEBAQYBAQEBAQEBARqBLYlEhTIXAQEBMxsHBoIyQRKBQwWXTYQnhEE/hhJAikuECoICIIEbQHgBAQEEgQg5gQMBAQE Received: from e14hub-01.zdv.uni-mainz.de ([10.94.6.80]) by mailgate-02.zdv.uni-mainz.de with ESMTP/TLS/AES128-SHA; 23 Nov 2014 16:50:31 +0100 Received: from e15be-01.zdv.Uni-Mainz.DE (2001:4c80:40:606:92e2:baff:fe19:9090) by E14HUB-01.zdv.Uni-Mainz.DE (2001:4c80:40:606:21d:d8ff:feb7:1c5f) with Microsoft SMTP Server (TLS) id 14.3.210.2; Sun, 23 Nov 2014 16:50:30 +0100 Received: from e15be-01.zdv.Uni-Mainz.DE (2001:4c80:40:606:92e2:baff:fe19:9090) by e15be-01.zdv.Uni-Mainz.DE (2001:4c80:40:606:92e2:baff:fe19:9090) with Microsoft SMTP Server (TLS) id 15.0.1044.22; Sun, 23 Nov 2014 16:50:30 +0100 Received: from e15be-01.zdv.Uni-Mainz.DE ([fe80::92e2:baff:fe19:9090]) by e15be-01.zdv.Uni-Mainz.DE ([fe80::92e2:baff:fe19:9090%15]) with mapi id 15.00.1044.021; Sun, 23 Nov 2014 16:50:30 +0100 From: =?utf-8?B?V2Vpw58sICBEci4gSsO8cmdlbg==?= To: 'David Rayson' Subject: RE: Jetson TK1 board support Thread-Topic: Jetson TK1 board support Thread-Index: AQHP18iUBDzcFmGHMkWO9pZPd3gkEJwT3s2wgAlm2oCAASHcUIBBkY+AgADsnnCABiaVgIADTroAgARY15A= Date: Sun, 23 Nov 2014 15:50:29 +0000 Message-ID: <046b20c08ef14a7095b9200444e2465c@e15be-01.zdv.Uni-Mainz.DE> References: <542271AE.6070807@andrew.cmu.edu> <2c451765bffb43e8b9dab56927bb351a@e15be-02.zdv.Uni-Mainz.DE> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [134.93.178.73] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Nov 2014 15:50:40 -0000 TGludXggdXNlcyB0aGUgcnRjIG9uIHRoZSBhczM3MjIgcG93ZXIgbWFuYWdlbWVudCBjb250cm9s bGVyLiBUaGUNCnJ0YyBvbiB0aGUgdGVncmEgc29jIGRvZXMgbm90IHNlZW0gdG8gcmV0YWluIHRp bWUgb3ZlciByZWJvb3RzLCB0aGUgcnRjIG9uIHRoZQ0KdGhlIGFzMzcyMiBkb2VzLiBUaGVyZSBp cyBhIGNhcGFjaXRvciBvZiAxNCBtRiBjb25uZWN0ZWQgdG8gdGhlDQphczM3MjIuIE5vIGlkZWEg aG93IGxvbmcgaXQgcmV0YWlucyBydGMgcG93ZXIgZXZlbiB3aXRob3V0IGFueSBsaW5lIHBvd2Vy Lg0KDQpKdWVyZ2VuDQoNCkp1ZXJnZW4gV2Vpc3MgICAgICB8VW5pdmVyc2l0YWV0IE1haW56LCBa ZW50cnVtIGZ1ZXIgRGF0ZW52ZXJhcmJlaXR1bmcsDQp3ZWlzc0B1bmktbWFpbnouZGUgfDU1MDk5 IE1haW56LCBUZWw6ICs0OSg2MTMxKTM5LTI2MzYxLCBGQVg6ICs0OSg2MTMxKTM5LTI2NDA3DQoN Cj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogRGF2aWQgUmF5c29uIFttYWls dG86ZHJheXNvbkBhbmRyZXcuY211LmVkdV0NCj4gU2VudDogVGh1cnNkYXksIE5vdmVtYmVyIDIw LCAyMDE0IDExOjAyIFBNDQo+IFRvOiBXZWnDnywgRHIuIErDvHJnZW4NCj4gQ2M6IGZyZWVic2Qt YXJtQGZyZWVic2Qub3JnDQo+IFN1YmplY3Q6IFJlOiBKZXRzb24gVEsxIGJvYXJkIHN1cHBvcnQN Cj4gDQo+IEhlcmUgaXMgYSBwYXRjaCAob24gdG9wIG9mIHlvdXIgbGFzdCBwYXRjaCBzZXQpIHRo YXQgYWRkcyBzdXBwb3J0IGZvciB0aGUgUlRDIChqdXN0IGZvcg0KPiB1c2UgYXMgYSBjbG9jazsg bm90IGZvciB0aW1lcnMvYWxhcm1zKToNCj4gaHR0cDovL3d3dy5jb250cmliLmFuZHJldy5jbXUu ZWR1L35kcmF5c29uL3RlZ3JhLXJ0Yy5wYXRjaA0KPiANCj4gDQo+IEknbSBhbHNvIHRha2luZyBh IGxvb2sgYXQgd2hhdCBpdCB3b3VsZCB0YWtlIHRvIGdldCBhIGZyYW1lYnVmZmVyIGNvbnNvbGUg d29ya2luZy4uLg0KPiANCj4gDQo+IC0tRGF2aWQNCj4gDQo+IA0KPiBPbiBUdWUsIE5vdiAxOCwg MjAxNCBhdCAyOjMxIFBNLCBEYXZpZCBSYXlzb24gPGRyYXlzb25AYW5kcmV3LmNtdS5lZHU+IHdy b3RlOg0KPiANCj4gDQo+IAlUaGFua3MgLS0gaXQgd29ya3MgZm9yIG1lIG5vdyEgIEkgYWRkZWQg YSBkcml2ZXIgZm9yIHRoZSBSVEMgKGFsdGhvdWdoIGl0J3Mgc3RpbGwgbm90DQo+IHN1cGVyIHVz ZWZ1bCB3aXRob3V0IGJlaW5nIGJhdHRlcnktYmFja2VkKTsgSSdsbCBzZW5kIHBhdGNoZXMgbGF0 ZXIgdG9kYXkuICBXb3VsZCBpdCBtYWtlDQo+IHNlbnNlIHRvIHNldCB1cCBhIHJlcG9zaXRvcnkg c29tZXdoZXJlIHRvIHB1dCB0aGlzIGluIGluc3RlYWQgb2YganVzdCBzZW5kaW5nIGFyb3VuZA0K PiBwYXRjaGVzPw0KPiANCj4gDQo+IAktLURhdmlkDQo+IA0KPiANCj4gCU9uIEZyaSwgTm92IDE0 LCAyMDE0IGF0IDM6NTggUE0sIFdlacOfLCBEci4gSsO8cmdlbiA8d2Vpc3NAdW5pLW1haW56LmRl PiB3cm90ZToNCj4gDQo+IA0KPiAJCVRoZSBFdGhlcm5ldCB3b3JrcyBxdWl0ZSB3ZWxsLiBCdXQg dGhlcmUgaGFzIGJlZW4gYSBjaGFuZ2UgaW4gYSBtb3JlDQo+IAkJcmVjZW50IHZlcnNpb24gb2Yg dS1ib290IHdoaWNoIGRpZCBub3QgaW5pdGlhbGl6ZSB0aGUgaW50ZXJydXB0DQo+IAkJcm91dGlu ZyBvZiB0aGUgcGNpZSBicmlkZ2UuIFNvIHlvdSBkbyBub3QgZ2V0IHJlY2VpdmUgaW50ZXJydXB0 cy4NCj4gDQo+IAkJSSBwdXQgbW9yZSByZWNlbnQgcGF0Y2hlcyBmb3IgdGhlIGpldHNvbiB0azEg Ym9hcmQgdG8NCj4gDQo+IAkJIGh0dHA6Ly93d3cuc3RhZmYudW5pLW1haW56LmRlL3dlaXNzL2pl dHNvbi10azEtMjAxNDExMTQudGd6DQo+IA0KPiAJCU5ldyBjaGFuZ2VzIHRvIHUtYm9vdDoNCj4g CQkgIChkaWZmIHRvIGdpdDovL252LXRlZ3JhLm52aWRpYS5jb20vM3JkcGFydHkvdS1ib290Lmdp dCk6DQo+IAkJICBkZXZpY2UgZW51bWVyYXRpb24gdGhyb3VnaCB0aGUgdS1ib290IEFQSSBkaWQg b25seSByZXR1cm4gdGhlDQo+IAkJICBmaXJzdCBkZXZpY2Ugb2YgZWFjaCB0eXBlLg0KPiANCj4g CQlOZXcgY2hhbmdlcyB0byB0aGUgRnJlZUJTRCBrZXJuZWw6DQo+IAkJICAoZGlmZiB0byBGcmVl QlNEIGN1cnJlbnQpOg0KPiAJCSAgYmV0dGVyIGluaXRpYWxpemUgcGNpZSBicmlkZ2UgaW50ZXJy dXB0IHJvdXRpbmcuDQo+IAkJICBjaGFuZ2UgY3B1IGNsb2NrIHRvIDIgR0h6IChhYm91dCAzIHRp bWVzIGZhc3RlcikNCj4gCQkgIFNESENJIHN1cHBvcnQuIFRlc3RlZCBvbmx5IHdpdGggbm9uLWhp Z2hzcGVlZCBjYXJkcy4NCj4gCQkgIGNoYW5nZWQgY3B1X3Jlc2V0IHRvIHJldHVybiB0byBib290 IGxvYWRlciAodS1ib290KS4NCj4gDQo+IAkJUmVnYXJkcw0KPiANCj4gCQlKdWVyZ2VuDQo+IA0K PiAJCUp1ZXJnZW4gV2Vpc3MgICAgICB8VW5pdmVyc2l0YWV0IE1haW56LCBaZW50cnVtIGZ1ZXIg RGF0ZW52ZXJhcmJlaXR1bmcsDQo+IAkJd2Vpc3NAdW5pLW1haW56LmRlIHw1NTA5OSBNYWlueiwg VGVsOiArNDkoNjEzMSkzOS0yNjM2MSA8dGVsOiUyQjQ5JTI4NjEzMSUyOTM5LQ0KPiAyNjM2MT4g LCBGQVg6ICs0OSg2MTMxKTM5LTI2NDA3IDx0ZWw6JTJCNDklMjg2MTMxJTI5MzktMjY0MDc+DQo+ IA0KPiANCj4gCQk+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IAkJPiBGcm9tOiBEYXZp ZCBSYXlzb24gW21haWx0bzpkcmF5c29uQGFuZHJldy5jbXUuZWR1XQ0KPiAJCT4gU2VudDogRnJp ZGF5LCBOb3ZlbWJlciAxNCwgMjAxNCA4OjI5IEFNDQo+IAkJPiBUbzogV2Vpw58sIERyLiBKw7xy Z2VuDQo+IAkJPiBDYzogZnJlZWJzZC1hcm1AZnJlZWJzZC5vcmcNCj4gCQk+IFN1YmplY3Q6IFJl OiBKZXRzb24gVEsxIGJvYXJkIHN1cHBvcnQNCj4gCQk+DQo+IAkJPiBIb3cgd2VsbCBkb2VzIHRo ZSBldGhlcm5ldCBzdXBwb3J0IHdvcmsgZm9yIHlvdT8gIFdoZW4gSSB0cnkgdG8gdXNlIGl0LA0K PiBwYWNrZXRzIGFyZSBzZW50DQo+IAkJPiBzdWNjZXNzZnVsbHksIGJ1dCBubyBwYWNrZXRzIGFy ZSByZWNlaXZlZCAodXN1YWxseSkuICBJIHRoaW5rIHRoZXJlIG1pZ2h0IGJlDQo+IHNvbWUgc29y dCBvZg0KPiAJCT4gb2RkIHJhY2UgY29uZGl0aW9uOiBpZiBJIGJyZWFrIGludG8gdGhlIGRlYnVn Z2VyLCBsZXQgaXQgc2l0IGZvciBhIHdoaWxlLCB0aGVuDQo+IGNvbnRpbnVlLA0KPiAJCT4gaXQg d2lsbCBzdGFydCB0byAodmVyeSBpbnRlcm1pdHRlbnRseSkgcmVjZWl2ZSBhIHBhY2tldCBldmVy eSBub3cgYW5kIHRoZW4NCj4gKHR5cGljYWxseQ0KPiAJCT4gYWZ0ZXIgYSB3YXRjaGRvZyB0aW1l b3V0IG1lc3NhZ2UgZnJvbSB0aGUgZXRoZXJuZXQgZHJpdmVyKS4gIEFueSBpZGVhIHdoYXQNCj4g Y291bGQgYmUgZ29pbmcNCj4gCQk+IG9uIHRoZXJlPw0KPiAJCT4NCj4gCQk+DQo+IAkJPiAtLURh dmlkDQo+IAkJPg0KPiAJCT4NCj4gCQk+IE9uIEZyaSwgT2N0IDMsIDIwMTQgYXQgOTozMyBBTSwg V2Vpw58sIERyLiBKw7xyZ2VuIDx3ZWlzc0B1bmktbWFpbnouZGU+IHdyb3RlOg0KPiAJCT4NCj4g CQk+DQo+IAkJPiAgICAgICBJZiB5b3UgZW5hYmxlIHRoZSBzZGhjaSBjb250cm9sbGVyKHMpIGlu IHRoZSBmZHQsIHRoZSBjb250cm9sbGVycyBhbmQNCj4gCQk+ICAgICAgIHRoZSBjYXJkcyBhcmUg KGF0IGxlYXN0IHBhcnRpYWxseSkgcmVjb2duaXplZC4gUmVhZCBkYXRhIHRyYW5zZmVycw0KPiAJ CT4gICAgICAgZnJvbSB0aGUgc2QgY2FyZCBzbG90IHJldHVybiBvbmx5IGRhdGEgYnl0ZXMgd2l0 aCB6ZXJvIGNvbnRlbnRzLg0KPiAJCT4gICAgICAgVGhlIHF1aXJrIGluIHRoZSBmZHQgc2hvdWxk IGRpc2FibGUgRE1BLiBUaGUgdHJhbnNmZXJzIGFyZSBkb25lDQo+IAkJPiAgICAgICBpbiBwaW8g bW9kZS4NCj4gCQk+DQo+IAkJPiAgICAgICBVLWJvb3Qgc2hvdWxkIGFscmVhZHkgaGF2ZSBpbml0 aWFsaXplZCB0aGUgY29udHJvbGxlcnMuIEJ1dCB0aGUNCj4gCQk+ICAgICAgIGdlbmVyaWMgc2Ro Y2kgZHJpdmVyIHRyaWVzIGF0IGxlYXN0IHRvIHNldCBmcmVxdWVuY3kgYW5kIGJ1cyB3aWR0aA0K PiAJCT4gICAgICAgYWNjb3JkaW5nIHRvIHRoZSBjYXJkcyBwcmVzZW50LiBGb3IgdGhlIEVNTUMg aXQgY2VydGFpbmx5IGRvZXMNCj4gCQk+ICAgICAgIG5vdCBrbm93IGhvdyB0byBoYW5kbGUgOCBi aXQgdHJhbnNmZXJzIHdpdGhvdXQgZnVydGhlciBoZWxwDQo+IAkJPiAgICAgICBmcm9tIGEgdGVn cmEgc3BlY2lmaWMgZHJpdmVyIGV4dGVuc2lvbnMuDQo+IAkJPg0KPiAJCT4gICAgICAgSnVlcmdl bg0KPiAJCT4NCj4gCQk+ICAgICAgIEp1ZXJnZW4gV2Vpc3MgICAgICB8VW5pdmVyc2l0YWV0IE1h aW56LCBaZW50cnVtIGZ1ZXIgRGF0ZW52ZXJhcmJlaXR1bmcsDQo+IA0KPiAJCT4gICAgICAgd2Vp c3NAdW5pLW1haW56LmRlIHw1NTA5OSBNYWlueiwgVGVsOiArNDkoNjEzMSkzOS0yNjM2MQ0KPiA8 dGVsOiUyQjQ5JTI4NjEzMSUyOTM5LTI2MzYxPiAgPHRlbDolMkI0OSUyODYxMzElMjkzOS0yNjM2 MT4NCj4gCQk+ICwgRkFYOiArNDkoNjEzMSkzOS0yNjQwNyA8dGVsOiUyQjQ5JTI4NjEzMSUyOTM5 LTI2NDA3Pg0KPiA8dGVsOiUyQjQ5JTI4NjEzMSUyOTM5LTI2NDA3Pg0KPiAJCT4NCj4gCQk+ICAg ICAgID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gCQk+ICAgICAgID4gRnJvbTogRGF2 aWQgUmF5c29uIFttYWlsdG86ZHJheXNvbkBhbmRyZXcuY211LmVkdV0NCj4gCQk+ICAgICAgID4g U2VudDogVGh1cnNkYXksIE9jdG9iZXIgMDIsIDIwMTQgMTE6NTQgUE0NCj4gCQk+ICAgICAgID4g VG86IFdlacOfLCBEci4gSsO8cmdlbg0KPiAJCT4gICAgICAgPiBDYzogZnJlZWJzZC1hcm1AZnJl ZWJzZC5vcmcNCj4gCQk+ICAgICAgID4gU3ViamVjdDogUmU6IEpldHNvbiBUSzEgYm9hcmQgc3Vw cG9ydA0KPiAJCT4gICAgICAgPg0KPiAJCT4NCj4gCQk+ICAgICAgID4gSG93IG11Y2ggd29yayBk byB5b3UgdGhpbmsgd291bGQgYmUgbmVlZGVkIHRvIGdldCB0aGUgU0QgY29udHJvbGxlcg0KPiB3 b3JraW5nPyAgV291bGQNCj4gCQk+IGl0DQo+IAkJPiAgICAgICA+IHNpbXBseSBiZSBhIG1hdHRl ciBvZiBkb2luZyB0aGUgYXBwcm9wcmlhdGUgaW5pdGlhbGl6YXRpb24gKHdvdWxkbid0DQo+IFUt Qm9vdCBkbyB0aGlzDQo+IAkJPiAgICAgICA+IGFscmVhZHkgZXZlbj8pLCBlbmFibGluZyBpdCBp biB0aGUgZGV2aWNlIHRyZWUsIGFuZCB1c2luZyB0aGUgc3RhbmRhcmQNCj4gRnJlZUJTRA0KPiAJ CT4gU0RIQ0kNCj4gCQk+ICAgICAgID4gZHJpdmVyLCBvciBpcyB0aGVyZSBzb21ldGhpbmcgbW9y ZSBjb21wbGljYXRlZCB0aGF0IHdvdWxkIG5lZWQgdG8gYmUNCj4gZG9uZT8NCj4gCQk+ICAgICAg ID4NCj4gCQk+ICAgICAgID4NCj4gCQk+ICAgICAgID4gKFRoaXMgd291bGQgcHJvYmFibHkgYmUg c2ltcGxlIHRvIHRlc3QsIGJ1dCBJIGRvbid0IGhhdmUgYWNjZXNzIHRvIHRoZQ0KPiBoYXJkd2Fy ZQ0KPiAJCT4gcmlnaHQgbm93KQ0KPiAJCT4gICAgICAgPg0KPiAJCT4gICAgICAgPg0KPiAJCT4g ICAgICAgPiAtLURhdmlkDQo+IAkJPiAgICAgICA+DQo+IAkJPiAgICAgICA+DQo+IAkJPiAgICAg ICA+IE9uIEZyaSwgU2VwIDI2LCAyMDE0IGF0IDQ6MzkgUE0sIFdlacOfLCBEci4gSsO8cmdlbiA8 d2Vpc3NAdW5pLW1haW56LmRlPg0KPiB3cm90ZToNCj4gCQk+ICAgICAgID4NCj4gCQk+ICAgICAg ID4NCj4gCQk+ICAgICAgID4gICAgICAgSGksDQo+IAkJPiAgICAgICA+DQo+IAkJPiAgICAgICA+ ICAgICAgIHNvcnJ5LCBJIGRpZCBub3QgaGF2ZSBhbnkgdGltZSBkdXJpbmcgdGhlIHdlZWsuDQo+ IAkJPiAgICAgICA+DQo+IAkJPiAgICAgICA+ICAgICAgIEkganVzdCBzZW50IGEgbWFpbCB0byB0 aGUgbGlzdCB3aXRoIGEgbGluayB0byBteSBjaGFuZ2VzLg0KPiAJCT4gICAgICAgPg0KPiAJCT4g ICAgICAgPiAgICAgICBPbmx5IHNlcmlhbCwgVVNCMiBhbmQgUENJZS9FdGhlcm5ldCBoYXJkd2Fy ZSBpcyB3b3JraW5nIC0gc28gbm8NCj4gCQk+ICAgICAgID4gICAgICAgU0FUQS4NCj4gCQk+ICAg ICAgID4NCj4gCQk+ICAgICAgID4gICAgICAgVGhlIGRyaXZlcnMgcmVseSBvbiB1LWJvb3QgdG8g aW5pdGlhbGl6ZSB0aGUgaGFyZHdhcmUuIFdoaWxlDQo+IHRoaXMNCj4gCQk+ICAgICAgID4gICAg ICAgaXMgb2sgZm9yIHBpbm11eCwgb3RoZXIgaW5pdGlhbGl6YXRpb25zIHNob3VsZCBiZSBkb25l IGJ5IHRoZQ0KPiAJCT4gICAgICAgPiAgICAgICBkcml2ZXJzLg0KPiAJCT4gICAgICAgPg0KPiAJ CT4gICAgICAgPiAgICAgICBUaGUgaW50ZXJydXB0IGhhbmRsaW5nIGZvciBQQ0llIGlzIHJhdGhl ciBhZCBob2MuIFRoZSBpbnRlcnJ1cHQNCj4gCQk+ICAgICAgID4gICAgICAgcm91dGluZyBzaG91 bGQgaG9ub3IgdGhlIEZEVCBkZXNjcmlwdGlvbi4NCj4gCQk+ICAgICAgID4NCj4gCQk+ICAgICAg ID4gICAgICAgVGhlIFRlZ3JhIHBsYXRmb3JtIGhhcyBhIEdJQyB3aXRoIGV4dGVuc2lvbnMgZm9y IGludGVycnVwdA0KPiAJCT4gICAgICAgPiAgICAgICByb3V0aW5nLiBJIGp1c3QgbWFkZSBhIGNv cHkgb2YgdGhlIEdJQyBjb2RlIGVuZCBleHRlbmRlZCBpdA0KPiAJCT4gICAgICAgPiAgICAgICBp biBhIGZldyBjYXNlcy4gVGhlcmUgc2hvdWxkIHByb2JhYmx5IGJlIGEgbWVjaGFuaXNtIHRvIGRv DQo+IAkJPiAgICAgICA+ICAgICAgIHRoaXMgd2l0aG91dCBkdXBsaWNhdGluZyBjb2RlLg0KPiAJ CT4gICAgICAgPg0KPiAJCT4gICAgICAgPiAgICAgICBJIGNoYW5nZWQgc29tZSBub24gdGVncmEg ZmlsZXMgdG8gZ2V0IEZyZWVCU0QgcnVubmluZyBvbiB0aGUNCj4gCQk+ICAgICAgID4gICAgICAg aGFyZHdhcmUuIFRoZXJlIHNob3VsZCBiZSBiZXR0ZXIgc29sdXRpb25zLCB3aGljaCBjYW4gYmUg bWVyZ2VkDQo+IAkJPiAgICAgICA+ICAgICAgIGJhY2sgdG8gdGhlIEZyZWVCU0Qgc291cmNlIHRy ZWUuIEZvciBleGFtcGxlIHRoZSBwcm9ibGVtDQo+IAkJPiAgICAgICA+ICAgICAgIHdpdGggY2Fj aGUgY29oZXJlbmN5IGR1ZSB0byBhZ2dyZXNzaXZlIEwyIHByZWZldGNoIGF3YWl0cw0KPiAJCT4g ICAgICAgPiAgICAgICBhIHJlYWwgc29sdXRpb24uDQo+IAkJPiAgICAgICA+DQo+IAkJPiAgICAg ICA+ICAgICAgIFRoZXJlIGlzIG5vIGNvZGUgdG8gY2hhbmdlIHRoZSBjcHUgY2xvY2sgeWV0Lg0K PiAJCT4gICAgICAgPg0KPiAJCT4gICAgICAgPiAgICAgICBUaGVyZSBpcyBubyBzdXBwb3J0IGZv ciBTREhDSSBvciBFTU1DLg0KPiAJCT4gICAgICAgPg0KPiAJCT4gICAgICAgPiAgICAgICBTbyBJ IHdvdWxkIGNvbnNpZGVyIHRoaXMgYSBmaXJzdCBzdGVwLCB3aGljaCBhbGxvd3MgdG8gZG8NCj4g CQk+ICAgICAgID4gICAgICAgbmF0aXZlIGRldmVsb3BtZW50IG9uIHRoZSBwbGF0Zm9ybS4NCj4g CQk+ICAgICAgID4NCj4gCQk+ICAgICAgID4gICAgICAgQmVzaWRlcyB0aGF0LCB0aGUga2VybmVs IHNlZW1zIHRvIGJlIHF1aXRlIHN0YWJsZSAtIGF0IGxlYXN0DQo+IHdpdGgNCj4gCQk+ICAgICAg ID4gICAgICAgdGhlIGNvbXBpbGVzIEkgZGlkLg0KPiAJCT4gICAgICAgPg0KPiAJCT4gICAgICAg PiAgICAgICBSZWdhcmRzDQo+IAkJPiAgICAgICA+DQo+IAkJPiAgICAgICA+ICAgICAgIEp1ZXJn ZW4NCj4gCQk+ICAgICAgID4NCj4gCQk+ICAgICAgID4gICAgICAgSnVlcmdlbiBXZWlzcyAgICAg IHxVbml2ZXJzaXRhZXQgTWFpbnosIFplbnRydW0gZnVlcg0KPiBEYXRlbnZlcmFyYmVpdHVuZywN Cj4gCQk+DQo+IAkJPiAgICAgICA+ICAgICAgIHdlaXNzQHVuaS1tYWluei5kZSB8NTUwOTkgTWFp bnosIFRlbDogKzQ5KDYxMzEpMzktMjYzNjENCj4gPHRlbDolMkI0OSUyODYxMzElMjkzOS0yNjM2 MT4NCj4gDQo+IAkJPiA8dGVsOiUyQjQ5JTI4NjEzMSUyOTM5LTI2MzYxPiAgPHRlbDolMkI0OSUy ODYxMzElMjkzOS0yNjM2MT4NCj4gCQk+ICAgICAgID4gLCBGQVg6ICs0OSg2MTMxKTM5LTI2NDA3 IDx0ZWw6JTJCNDklMjg2MTMxJTI5MzktMjY0MDc+DQo+IDx0ZWw6JTJCNDklMjg2MTMxJTI5Mzkt MjY0MDc+ICA8dGVsOiUyQjQ5JTI4NjEzMSUyOTM5LQ0KPiANCj4gCQk+IDI2NDA3Pg0KPiAJCT4N Cj4gCQk+ICAgICAgID4NCj4gCQk+ICAgICAgID4NCj4gCQk+ICAgICAgID4gICAgICAgPiAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiAJCT4gICAgICAgPiAgICAgICA+IEZyb206IG93bmVy LWZyZWVic2QtYXJtQGZyZWVic2Qub3JnIFttYWlsdG86b3duZXItZnJlZWJzZC0NCj4gYXJtQGZy ZWVic2Qub3JnXQ0KPiAJCT4gT24NCj4gCQk+ICAgICAgID4gQmVoYWxmIE9mDQo+IAkJPiAgICAg ICA+ICAgICAgID4gRGF2aWQgUmF5c29uDQo+IAkJPiAgICAgICA+ICAgICAgID4gU2VudDogV2Vk bmVzZGF5LCBTZXB0ZW1iZXIgMjQsIDIwMTQgOToyNSBBTQ0KPiAJCT4gICAgICAgPiAgICAgICA+ IFRvOiBmcmVlYnNkLWFybUBmcmVlYnNkLm9yZw0KPiAJCT4gICAgICAgPiAgICAgICA+IFN1Ympl Y3Q6IFJlOiBKZXRzb24gVEsxIGJvYXJkIHN1cHBvcnQNCj4gCQk+ICAgICAgID4gICAgICAgPg0K PiAJCT4gICAgICAgPiAgICAgICA+IEhpLA0KPiAJCT4gICAgICAgPiAgICAgICA+DQo+IAkJPiAg ICAgICA+ICAgICAgID4gV2hhdCBvdGhlciB3b3JrIHdvdWxkIGJlIHVzZWZ1bCB0byBnZXQgdGhp cyBwb3J0IHdvcmtpbmcgd2VsbD8NCj4gSSBtaWdodA0KPiAJCT4gICAgICAgPiAgICAgICA+IGJl IGludGVyZXN0ZWQgaW4gd29ya2luZyBvbiBpbXByb3ZpbmcgaXQsIGJ1dCBmaXJzdCBJIHdhbnQg dG8NCj4gbWFrZSBzdXJlDQo+IAkJPiAgICAgICA+ICAgICAgID4gSSBoYXZlIGEgY2xlYXIgc2Vu c2Ugb2Ygd2hhdCdzIGJlZW4gZG9uZSBzbyBmYXIgKGFuZCBob3cNCj4gc3RhYmxlL25vdCBpdA0K PiAJCT4gICAgICAgPiAgICAgICA+IGlzKSBhbmQgd2hhdCBzdGlsbCByZW1haW5zIHRvIGJlIGRv bmUuDQo+IAkJPiAgICAgICA+ICAgICAgID4NCj4gCQk+ICAgICAgID4gICAgICAgPiAtLURhdmlk DQo+IAkJPiAgICAgICA+ICAgICAgID4NCj4gCQk+ICAgICAgID4gICAgICAgPiA+IEhpLA0KPiAJ CT4gICAgICAgPiAgICAgICA+ID4NCj4gCQk+ICAgICAgID4gICAgICAgPiA+IEkgaGF2ZSBhIHJh dGhlciByb3VnaCBwb3J0IG9mIEZyZWVCU0QgY3VycmVudCBvbiBhcm0gdG8NCj4gSmV0c29uIFRL MS4gSQ0KPiAJCT4gICAgICAgPiAgICAgICA+ID4gdXNlZCBTdGVwaGVuIFdhcnJlbidzIHRlZ3Jh IHUtYm9vdCBzb3VyY2VzLCB3aGljaCBpbml0aWFsaXplDQo+IGFuZA0KPiAJCT4gY29uZmlndXJl DQo+IAkJPiAgICAgICA+ICAgICAgID4gPiBVU0IgYW5kIFBDSWUuDQo+IAkJPiAgICAgICA+ICAg ICAgID4gPg0KPiAJCT4gICAgICAgPiAgICAgICA+ID4gU28gU01QLCBVU0IgYW5kIHRoZSBvbmJv YXJkIFBDSWUgRXRoZXJuZXQgYWRhcHRlciB3b3JrLg0KPiAJCT4gICAgICAgPiAgICAgICA+ID4N Cj4gCQk+ICAgICAgID4gICAgICAgPiA+IEFmdGVyIElhbidzIGNoYW5nZXMgdG8gYnVzZG1hX21h Y2hkZXAtdjYgKHIyNjkyMTIpIEkgaGFkDQo+IHByb2JsZW1zIHdpdGgNCj4gCQk+ICAgICAgID4g ICAgICAgPiA+IGNhY2hlIGNvaGVyZW5jeSB3aXRoIHRoZSBFdGhlcm5ldCBhZGFwdGVyLiBTZWVt cyB0aGlzIGlzIGR1ZQ0KPiB0byB0aGUNCj4gCQk+IGFnZ3Jlc3NpdmUNCj4gCQk+ICAgICAgID4g ICAgICAgPiA+IEwyIHByZWZldGNoZXIgb2YgQ29ydGV4IEExNS4gRGlzYWJsaW5nIEwyIHByZWZl dGNoIGRvZXMNCj4gaGVscCwgYXMgd2VsbCBhcw0KPiAJCT4gICAgICAgPiAgICAgICA+ID4gaW52 YWxpZGF0aW5nIHRoZSBjYWNoZSBhIHNlY29uZCB0aW1lIGFmdGVyIHRoZSBkbWEgdHJhbnNmZXIu DQo+IEknbSBub3QNCj4gCQk+ICAgICAgID4gICAgICAgPiA+IHN1cmUgd2hhdCB0aGUgY29ycmVj dCBzb2x1dGlvbiB0byB0aGlzIHByb2JsZW0gaXMuIEkgd29uZGVyDQo+IGhvdw0KPiAJCT4gICAg ICAgPiAgICAgICA+ID4gb3RoZXIgQ29ydGV4IEExNSBwbGF0Zm9ybXMgKGV4eW5vczUpIGhhbmRs ZSB0aGlzLg0KPiAJCT4gICAgICAgPiAgICAgICA+ID4NCj4gCQk+ICAgICAgID4gICAgICAgPiA+ IEkgd2lsbCBwcm9iYWJseSBiZSBhYmxlIHRvIGRvIHNvbWUgY2xlYW51cHMgYW5kIHB1dCBwYXRj aGVzDQo+IG9uIHRoZSB3ZWINCj4gCQk+ICAgICAgID4gICAgICAgPiA+IHdpdGhpbiBhIHdlZWsu DQo+IAkJPiAgICAgICA+ICAgICAgID4gPg0KPiAJCT4gICAgICAgPiAgICAgICA+ID4gUmVnYXJk cw0KPiAJCT4gICAgICAgPiAgICAgICA+ID4NCj4gCQk+ICAgICAgID4gICAgICAgPiA+IEp1ZXJn ZW4NCj4gCQk+ICAgICAgID4gICAgICAgPiA+DQo+IAkJPiAgICAgICA+ICAgICAgID4gPiBKdWVy Z2VuIFdlaXNzICAgICAgfFVuaXZlcnNpdGFldCBNYWlueiwgWmVudHJ1bSBmdWVyDQo+IERhdGVu dmVyYXJiZWl0dW5nLA0KPiAJCT4gICAgICAgPiAgICAgICA+ID4gd2Vpc3MgYXQgdW5pLW1haW56 LmRlDQo+IAkJPiA8aHR0cDovL2xpc3RzLmZyZWVic2Qub3JnL21haWxtYW4vbGlzdGluZm8vZnJl ZWJzZC1hcm0+DQo+IAkJPiAgICAgICA+IHw1NTA5OQ0KPiAJCT4NCj4gCQk+ICAgICAgID4gICAg ICAgPiBNYWlueiwgVGVsOiArNDkoNjEzMSkzOS0yNjM2MSA8dGVsOiUyQjQ5JTI4NjEzMSUyOTM5 LTI2MzYxPg0KPiA8dGVsOiUyQjQ5JTI4NjEzMSUyOTM5LTI2MzYxPg0KPiANCj4gCQk+IDx0ZWw6 JTJCNDklMjg2MTMxJTI5MzktMjYzNjE+ICwgRkFYOiArNDkoNjEzMSkzOSA8dGVsOiUyQjQ5JTI4 NjEzMSUyOTM5Pg0KPiA8dGVsOiUyQjQ5JTI4NjEzMSUyOTM5PiAtDQo+IAkJPiAgICAgICA+IDI2 NDA3IDx0ZWw6JTJCNDklMjg2MTMxJTI5MzktMjY0MDc+DQo+IAkJPg0KPiAJCT4gICAgICAgPiAg ICAgICA+ID4NCj4gCQk+ICAgICAgID4gICAgICAgPiA+ID4vICAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPiAJCT4gICAgICAgPiAgICAgICA+ID4gLz4vICBGcm9tOm93bmVyLWZyZWVic2Qt YXJtIGF0IGZyZWVic2Qub3JnDQo+IAkJPiAgICAgICA+ICAgICAgID4gPGh0dHA6Ly9saXN0cy5m cmVlYnNkLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ZyZWVic2QtYXJtPg0KPiBbbWFpbHRvOm93bmVy LQ0KPiAJCT4gZnJlZWJzZC1hcm0NCj4gCQk+ICAgICAgID4gYXQNCj4gCQk+ICAgICAgID4gICAg ICAgPiBmcmVlYnNkLm9yZw0KPiA8aHR0cDovL2xpc3RzLmZyZWVic2Qub3JnL21haWxtYW4vbGlz dGluZm8vZnJlZWJzZC1hcm0+XSBPbg0KPiANCj4gCQk+IEJlaGFsZiBPZg0KPiAJCT4gICAgICAg PiAgICAgICA+ID4gLz4vICBJYW4gTGVwb3JlDQo+IAkJPiAgICAgICA+ICAgICAgID4gPiAvPi8g IFNlbnQ6IFN1bmRheSwgU2VwdGVtYmVyIDIxLCAyMDE0IDM6NDQgUE0NCj4gCQk+ICAgICAgID4g ICAgICAgPiA+IC8+LyAgVG86IEx1bmRiZXJnLCBKb2hhbm5lcw0KPiAJCT4gICAgICAgPiAgICAg ICA+ID4gLz4vICBDYzpmcmVlYnNkLWFybSBhdCBmcmVlYnNkLm9yZw0KPiAJCT4gICAgICAgPiA8 aHR0cDovL2xpc3RzLmZyZWVic2Qub3JnL21haWxtYW4vbGlzdGluZm8vZnJlZWJzZC0NCj4gCQk+ ICAgICAgID4gICAgICAgPiBhcm0+DQo+IAkJPiAgICAgICA+ICAgICAgID4gPiAvPi8gIFN1Ympl Y3Q6IFJlOiBKZXRzb24gVEsxIGJvYXJkIHN1cHBvcnQNCj4gCQk+ICAgICAgID4gICAgICAgPiA+ IC8+Lw0KPiAJCT4gICAgICAgPiAgICAgICA+ID4gLz4vICBPbiBTdW4sIDIwMTQtMDktMjEgYXQg MTY6NDUgKzA5MDAsIEx1bmRiZXJnLCBKb2hhbm5lcw0KPiB3cm90ZToNCj4gCQk+ICAgICAgID4g ICAgICAgPiA+IC8+LyAgPiBHcmVhdCENCj4gCQk+ICAgICAgID4gICAgICAgPiA+IC8+LyAgPg0K PiAJCT4gICAgICAgPiAgICAgICA+ID4gLz4vICA+IFdoYXQgSSd2ZSBkb25lIHNvIGZhciBpcw0K PiAJCT4gICAgICAgPiAgICAgICA+ID4gLz4vICA+DQo+IAkJPiAgICAgICA+ICAgICAgID4gPiAv Pi8gID4gLSBidWlsZCBhbmQgcGF0Y2ggKGVuYWJsZSBBUEkpIHUtYm9vdC1udmlkaWEgb24NCj4g ZnJlZWJzZCAoaSB0aGluayBpDQo+IAkJPiBnb3QgaXQNCj4gCQk+ICAgICAgID4gICAgICAgPiA+ IC8+LyAgPiBmcm9tZ2l0Oi8vbnYtdGVncmEubnZpZGlhLmNvbS8zcmRwYXJ0eS91LWJvb3QuZ2l0 LA0KPiB0aGUgbm9ybWFsIHUtDQo+IAkJPiBib290DQo+IAkJPiAgICAgICA+ICAgICAgID4gPiAv Pi8gID4gd291bGRuJ3Qgd29yay4uLikNCj4gCQk+ICAgICAgID4gICAgICAgPiA+IC8+LyAgPiAt IGZsYXNoIHUtYm9vdC1kdGItdGVncmEuaW1nIG9udG8gdGhlIGJvYXJkJ3MgbW1jDQo+IHVzaW5n IG52aWRpYSdzDQo+IAkJPiBmbGFzaA0KPiAJCT4gICAgICAgPiB0b29sDQo+IAkJPiAgICAgICA+ ICAgICAgID4gPiAvPi8gID4gb24gdWJ1bnR1DQo+IAkJPiAgICAgICA+ICAgICAgID4gPiAvPi8g ID4gLSBidWlsZCBhbiBpbWFnZSB1c2luZyBjcm9jaGV0IGFuZCBkZCB0byBzZCBjYXJkIChzbw0K PiBmYXIgSSBjb3BpZWQNCj4gCQk+IHRoZQ0KPiAJCT4gICAgICAgPiAgICAgICA+ID4gLz4vICA+ IGJlYWdsZWJvbmUgc2V0dXAsIGp1c3QgdG8gZ2V0IGEgdWJsZHIgYW5kIGEga2VybmVsDQo+IGZp bGUpDQo+IAkJPiAgICAgICA+ICAgICAgID4gPiAvPi8gID4NCj4gCQk+ICAgICAgID4gICAgICAg PiA+IC8+LyAgPg0KPiAJCT4gICAgICAgPiAgICAgICA+ID4gLz4vICA+IEZyb20gdS1ib290IEkg Y2FuIHNlZSBhbGwgZGV2aWNlcy4gSSBsb2FkIHVibGRyIHdpdGgNCj4gCQk+ICAgICAgID4gICAg ICAgPiA+IC8+LyAgPiBmYXRsb2FkIG1tYyAxOjEgMHg4MDIwMDAwMCB1Ymxkcg0KPiAJCT4gICAg ICAgPiAgICAgICA+ID4gLz4vICA+IGJvb3RlbGYgMHg4MDIwMDAwMA0KPiAJCT4gICAgICAgPiAg ICAgICA+ID4gLz4vICA+DQo+IAkJPiAgICAgICA+ICAgICAgID4gPiAvPi8gID4gdWJsZHIgbG9h ZCBmaW5lIGJ1dCwgZnJvbSB1YmxkciBJIGNhbiBvbmx5IHNlZSB0aGUNCj4gbW1jIDAgYW5kIG5l dA0KPiAJCT4gZGV2aWNlcy4NCj4gCQk+ICAgICAgID4gICAgICAgPiA+IC8+LyAgPiBUaGVyZSdz IG5vIHNkIGNhcmQgKG1tYyAxKSwgYW5kIG5vIHVmcyBwYXJ0aXRpb24uLg0KPiAJCT4gICAgICAg PiAgICAgICA+ID4gLz4vICA+DQo+IAkJPiAgICAgICA+ICAgICAgID4gPiAvPi8gID4NCj4gCQk+ ICAgICAgID4gICAgICAgPiA+IC8+LyAgPg0KPiAJCT4gICAgICAgPiAgICAgICA+ID4gLz4vICA+ DQo+IAkJPiAgICAgICA+ICAgICAgID4gPiAvPi8gID4gLS0NCj4gCQk+ICAgICAgID4gICAgICAg PiA+IC8+LyAgPiBKb2hhbm5lcyBMdW5kYmVyZw0KPiAJCT4gICAgICAgPiAgICAgICA+ID4gLz4v ICA+IEJSSUxMSUFOVFNFUlZJQ0UgQ08uLCBMVEQuDQo+IAkJPiAgICAgICA+ICAgICAgID4gPiAv Pi8gID4NCj4gCQk+ICAgICAgID4gICAgICAgPiA+IC8+LyAgPiBPbiBGcmksIFNlcCAxOSwgMjAx NCBhdCA4OjI1IFBNLCBKb2huIEhvd2llIDxqb2huIGF0DQo+IHRoZWhvd2llcy5jb20NCj4gCQk+ ICAgICAgID4gICAgICAgPiA8aHR0cDovL2xpc3RzLmZyZWVic2Qub3JnL21haWxtYW4vbGlzdGlu Zm8vZnJlZWJzZC1hcm0+Pg0KPiB3cm90ZToNCj4gCQk+ICAgICAgID4gICAgICAgPiA+IC8+LyAg Pg0KPiAJCT4gICAgICAgPiAgICAgICA+ID4gLz4vICA+ID4gSGkgYWxsLA0KPiAJCT4gICAgICAg PiAgICAgICA+ID4gLz4vICA+ID4NCj4gCQk+ICAgICAgID4gICAgICAgPiA+IC8+LyAgPiA+IEkg YW0gdXAgZm9yIHRlc3RpbmcgYW5kIHN1cHBvcnRpbmcgdGhpcyBib2FyZC4gSQ0KPiBvcmRlcmVk IGFuZA0KPiAJCT4gcmVjZWl2ZWQNCj4gCQk+ICAgICAgID4gICAgICAgPiA+IC8+LyAgPiA+IG1p bmUsIGJ1dCBoYXZlIG5vdCByZWFsbHkgaGFkIGEgY2hhbmNlIHRvIHVzZSBpdA0KPiBkdWUgdG8g d29yayB0by0NCj4gCQk+IGRhdGUuDQo+IAkJPiAgICAgICA+IFRoZQ0KPiAJCT4gICAgICAgPiAg ICAgICA+ID4gLz4vICA+ID4gZ29vZCBuZXdzIGlzIHRoZSBuZXh0IGZldyBtb250aHMgSSB3aWxs IGhhdmUNCj4gYmFuZHdpZHRoLg0KPiAJCT4gICAgICAgPiAgICAgICA+ID4gLz4vICA+ID4NCj4g CQk+ICAgICAgID4gICAgICAgPiA+IC8+LyAgPiA+IFJlZ2FyZHMsDQo+IAkJPiAgICAgICA+ICAg ICAgID4gPiAvPi8gID4gPg0KPiAJCT4gICAgICAgPiAgICAgICA+ID4gLz4vICA+ID4gSm9obg0K PiAJCT4gICAgICAgPiAgICAgICA+ID4gLz4vICA+ID4NCj4gCQk+ICAgICAgID4gICAgICAgPiA+ IC8+LyAgPiA+DQo+IAkJPiAgICAgICA+ICAgICAgID4gPiAvPi8gID4gPiBPbiA5LzE5LzE0LCAx MjoxNSBQTSwgIkx1bmRiZXJnLCBKb2hhbm5lcyINCj4gCQk+ICAgICAgID4gICAgICAgPiA+IC8+ LyAgPiA+IDxqb2hhbm5lcyBhdCBicmlsbGlhbnRzZXJ2aWNlLmNvLmpwDQo+IAkJPiAgICAgICA+ ICAgICAgID4gPGh0dHA6Ly9saXN0cy5mcmVlYnNkLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ZyZWVi c2QtYXJtPj4NCj4gd3JvdGU6DQo+IAkJPiAgICAgICA+ICAgICAgID4gPiAvPi8gID4gPg0KPiAJ CT4gICAgICAgPiAgICAgICA+ID4gLz4vICA+ID4gPkhpDQo+IAkJPiAgICAgICA+ICAgICAgID4g PiAvPi8gID4gPiA+DQo+IAkJPiAgICAgICA+ICAgICAgID4gPiAvPi8gID4gPiA+SSBzdGFydGVk IHdvcmtpbmcgb24gYWRkaW5nIHRoZSBKZXRzb24gVEsxIGJvYXJkDQo+IHRvIENyb2NoZXQuIElz DQo+IAkJPiB0aGVyZQ0KPiAJCT4gICAgICAgPiBhbnkNCj4gCQk+ICAgICAgID4gICAgICAgPiA+ IC8+LyAgPiA+ID53b3JrIGluIHByb2dyZXNzIG9uIHRoaXM/DQo+IAkJPiAgICAgICA+ICAgICAg ID4gPiAvPi8gID4gPiA+SSBndWVzcyB0aGVyZSBpcyBxdWl0ZSBhIGxvdCBvZiB3b3JrIHRoYXQg aGFzIHRvDQo+IGJlZW4gZG9uZSB0bw0KPiAJCT4gZ2V0IGZ1bGwNCj4gCQk+ICAgICAgID4gICAg ICAgPiA+IC8+LyAgPiA+ID5zdXBwb3J0IGZvciBpdCBpbiB0aGUga2VybmVsIGFzIHdlbGwuLg0K PiAJCT4gICAgICAgPiAgICAgICA+ID4gLz4vICA+ID4gPg0KPiAJCT4gICAgICAgPiAgICAgICA+ ID4gLz4vICA+ID4gPkJlc3QgcmVnYXJkcw0KPiAJCT4gICAgICAgPiAgICAgICA+ID4gLz4vICA+ ID4gPi0tDQo+IAkJPiAgICAgICA+ICAgICAgID4gPiAvPi8gID4gPiA+Sm9oYW5uZXMgTHVuZGJl cmcNCj4gCQk+ICAgICAgID4gICAgICAgPiA+IC8+LyAgPiA+ID4NCj4gCQk+ICAgICAgID4gICAg ICAgPiA+IC8+Lw0KPiAJCT4gICAgICAgPiAgICAgICA+ID4gLz4vICBZb3UgbWF5IGhhdmUgdG8g Y2hhbmdlIHNvbWUgdS1ib290IG9wdGlvbnMgdG8gc3VwcG9ydA0KPiBtdWx0aXBsZQ0KPiAJCT4g bW1jL3NkDQo+IAkJPiAgICAgICA+ICAgICAgID4gPiAvPi8gIGludGVyZmFjZXMuICBMb29rIGlu IHRoZSBjb25maWcgaGVhZGVyIGZvcg0KPiAJCT4gQ09ORklHX1NZU19NTUNfTUFYX0RFVklDRTsg aWYNCj4gCQk+ICAgICAgID4gICAgICAgPiA+IC8+LyAgaXQncyBub3QgdGhlcmUgeW91IG1heSBu ZWVkIHRvIGFkZCBpdC4gIEZvciB3YW5kYm9hcmQgSQ0KPiBhbHNvIGhhZCB0bw0KPiAJCT4gYWRk DQo+IAkJPiAgICAgICA+ICAgICAgID4gPiAvPi8gIGEgZnJlZXNjYWxlLXNwZWNpZmljIG9uZSwg Q09ORklHX1NZU19GU0xfVVNESENfTlVNLCBzbw0KPiB0aGVyZSBtYXkgYmUNCj4gCQk+ICAgICAg ID4gICAgICAgPiA+IC8+LyAgc29tZXRoaW5nIGxpa2UgdGhhdCB5b3UgbmVlZCB0byBmaW5kIGFz IHdlbGwuDQo+IAkJPiAgICAgICA+ICAgICAgID4gPiAvPi8NCj4gCQk+ICAgICAgID4gICAgICAg PiA+IC8+LyAgLS0gSWFuDQo+IAkJPiAgICAgICA+ICAgICAgID4gPiAvPi8NCj4gCQk+ICAgICAg ID4gICAgICAgPiA+IC8+Lw0KPiAJCT4gICAgICAgPiAgICAgICA+ID4gLz4vICBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiAJCT4gICAgICAgPiAgICAg ICA+ID4gLz4vICBmcmVlYnNkLWFybSBhdCBmcmVlYnNkLm9yZw0KPiAJCT4gICAgICAgPiA8aHR0 cDovL2xpc3RzLmZyZWVic2Qub3JnL21haWxtYW4vbGlzdGluZm8vZnJlZWJzZC1hcm0+DQo+IAkJ PiAgICAgICA+ICAgICAgID4gbWFpbGluZyBsaXN0DQo+IAkJPiAgICAgICA+ICAgICAgID4gPiAv Pi8gIGh0dHA6Ly9saXN0cy5mcmVlYnNkLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ZyZWVic2QtYXJt DQo+IAkJPiAgICAgICA+ICAgICAgID4gPiAvPi8gIFRvIHVuc3Vic2NyaWJlLCBzZW5kIGFueSBt YWlsIHRvICJmcmVlYnNkLWFybS0NCj4gdW5zdWJzY3JpYmUgYXQNCj4gCQk+IGZyZWVic2Qub3Jn DQo+IAkJPiAgICAgICA+ICAgICAgID4gPGh0dHA6Ly9saXN0cy5mcmVlYnNkLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2ZyZWVic2QtYXJtPiIvDQo+IAkJPiAgICAgICA+ICAgICAgID4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gCQk+ICAgICAgID4gICAg ICAgPiBmcmVlYnNkLWFybUBmcmVlYnNkLm9yZyBtYWlsaW5nIGxpc3QNCj4gCQk+ICAgICAgID4g ICAgICAgPiBodHRwOi8vbGlzdHMuZnJlZWJzZC5vcmcvbWFpbG1hbi9saXN0aW5mby9mcmVlYnNk LWFybQ0KPiAJCT4gICAgICAgPiAgICAgICA+IFRvIHVuc3Vic2NyaWJlLCBzZW5kIGFueSBtYWls IHRvICJmcmVlYnNkLWFybS0NCj4gdW5zdWJzY3JpYmVAZnJlZWJzZC5vcmciDQo+IAkJPiAgICAg ICA+DQo+IAkJPiAgICAgICA+DQo+IAkJPg0KPiAJCT4NCj4gCQk+DQo+IA0KPiANCj4gDQo+IA0K DQo= From owner-freebsd-arm@FreeBSD.ORG Sun Nov 23 18:27:22 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 51D7899A for ; Sun, 23 Nov 2014 18:27:22 +0000 (UTC) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1FCE237F for ; Sun, 23 Nov 2014 18:27:20 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id sANIRHqi037998; Sun, 23 Nov 2014 18:27:17 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.109] (gateway.kientzle.com [192.168.1.65]) by kientzle.com with SMTP id rnvbkw22wyngu2bcpaza2rd8in; Sun, 23 Nov 2014 18:27:17 +0000 (UTC) (envelope-from tim@kientzle.com) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Subject: Re: latest VM images fail to compile for ARM From: Tim Kientzle In-Reply-To: <547144C5.5090002@foxvalley.net> Date: Sun, 23 Nov 2014 10:27:17 -0800 Message-Id: References: <54710D7D.3000303@foxvalley.net> <6C5FAA6F-B1B1-4499-8C0F-73C26D6D35C9@kientzle.com> <547144C5.5090002@foxvalley.net> To: Dan Raymond X-Mailer: Apple Mail (2.1993) Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Nov 2014 18:27:22 -0000 > On Nov 22, 2014, at 6:21 PM, Dan Raymond = wrote: >=20 > On 11/22/2014 6:57 PM, Tim Kientzle wrote: >>=20 >>> On Nov 22, 2014, at 2:26 PM, Dan Raymond > wrote: >>>=20 >>> I am getting errors while building xdev.=20 >>=20 >> What errors? >=20 > The first error was that it couldn't find 'gperf'. When I ran it = again it gave me a different error but I don't recall the details. Let = me know if you need a log and I will set up another VM to get it. I suspect the culprit is: r272849 emaste: Build gperf only if we=92re using g++ (not clang++) It seems that the xdev targets need to be updated to build gperf as a = prerequisite for GCC. You can work around this by manually building and = installing gperf. $ cd /usr/src/gnu/usr.bin/gperf $ make && make install As described in http://stackoverflow.com/questions/3040801 = , trying to build GCC = without gperf installed leaves some broken files behind, so you need to = clean out the obj directory before trying again lest you encounter other = problems: $ rm -rf /usr/obj/armv6-freebsd/ Cheers, Tim From owner-freebsd-arm@FreeBSD.ORG Sun Nov 23 21:28:29 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A0A54985 for ; Sun, 23 Nov 2014 21:28:29 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8908897F for ; Sun, 23 Nov 2014 21:28:29 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id sANLSTKZ047170 for ; Sun, 23 Nov 2014 21:28:29 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 195314] New: device mmcd1 not registered on boot from sd card Date: Sun, 23 Nov 2014 21:28:29 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: 10.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: mmitchel@gmail.com X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Nov 2014 21:28:29 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195314 Bug ID: 195314 Summary: device mmcd1 not registered on boot from sd card Product: Base System Version: 10.1-RELEASE Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: mmitchel@gmail.com release 10.1 beaglebone black rev C, the internal emmc does not appear to be enumerated on boot -- expected behavior is to see the device at /dev/mmcsd1. does not appear probed in the dmesg output at boot. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-arm@FreeBSD.ORG Sun Nov 23 21:28:52 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4B1D7AFD for ; Sun, 23 Nov 2014 21:28:52 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 330E5986 for ; Sun, 23 Nov 2014 21:28:52 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id sANLSq0P047397 for ; Sun, 23 Nov 2014 21:28:52 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 195314] device mmcd1 not registered on boot from sd card Date: Sun, 23 Nov 2014 21:28:52 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: 10.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: mmitchel@gmail.com X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: rep_platform Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Nov 2014 21:28:52 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195314 mmitchel@gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Hardware|Any |arm -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-arm@FreeBSD.ORG Sun Nov 23 21:29:07 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8F5C6B3B for ; Sun, 23 Nov 2014 21:29:07 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 76E73987 for ; Sun, 23 Nov 2014 21:29:07 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id sANLT70J047575 for ; Sun, 23 Nov 2014 21:29:07 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 195314] device mmcsdd1 not registered on boot from sd card Date: Sun, 23 Nov 2014 21:29:07 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: 10.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: mmitchel@gmail.com X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: short_desc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Nov 2014 21:29:07 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195314 mmitchel@gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|device mmcd1 not registered |device mmcsdd1 not |on boot from sd card |registered on boot from sd | |card -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-arm@FreeBSD.ORG Sun Nov 23 21:29:19 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6AEC2C56 for ; Sun, 23 Nov 2014 21:29:19 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 52A7898D for ; Sun, 23 Nov 2014 21:29:19 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id sANLTJbI047781 for ; Sun, 23 Nov 2014 21:29:19 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 195314] device mmcsd1 not registered on boot from sd card Date: Sun, 23 Nov 2014 21:29:19 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: 10.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: mmitchel@gmail.com X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: short_desc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Nov 2014 21:29:19 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195314 mmitchel@gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|device mmcsdd1 not |device mmcsd1 not |registered on boot from sd |registered on boot from sd |card |card -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-arm@FreeBSD.ORG Sun Nov 23 21:53:28 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7399671D for ; Sun, 23 Nov 2014 21:53:28 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5BE36C58 for ; Sun, 23 Nov 2014 21:53:28 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id sANLrSZf031796 for ; Sun, 23 Nov 2014 21:53:28 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 195314] device mmcsd1 not registered on boot from sd card Date: Sun, 23 Nov 2014 21:53:28 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: 10.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: fidaj@ukr.net X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Nov 2014 21:53:28 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195314 Ivan Klymenko changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fidaj@ukr.net --- Comment #1 from Ivan Klymenko --- This is a duplicate of this error message https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193341 -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-arm@FreeBSD.ORG Sun Nov 23 22:35:47 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 23FCF900 for ; Sun, 23 Nov 2014 22:35:47 +0000 (UTC) Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AC150FF1 for ; Sun, 23 Nov 2014 22:35:46 +0000 (UTC) Received: by mail-wi0-f179.google.com with SMTP id ex7so4071498wid.6 for ; Sun, 23 Nov 2014 14:35:39 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:content-type:content-transfer-encoding; bh=+sQpCgU+qt991lh/coGETM1ZWjjILSKkoSL9AqfQqAE=; b=jpVMmCD67K7CJloboGu0mTHHKPih9laPg0H3pNCZgA8o481uBdlFrnOcG2fE35wDtw 7Bk76fhzVJ677CwH1EXFPt0g5+EKBNnD6Lu54IfymWO8+jErV8aZGuTCoKpMafjlSg1w Ht51mCUO3q+y2uUGN9toqWQ7rqzHq+s82KFJs+mg5iIKQE6dKm/2VR+3OK+9mBqvFTV5 08YMiCaE0QTTpkcyK8CfnSrggngmyT5zent2mCsFCvhHu7VoW2SPTDZ6cUMUMJhw5b2+ rM6kYBx8FEax9mfRxK1JOkMrkK3DbdjfNL9B0962IKNX9TBdw9RHPBwBxSUyTcOkJete vfsQ== X-Gm-Message-State: ALoCoQlc7x8mHtmgVJIzZ3FlAxy6q2VmG4dw+cIxDVr4umT7Jd1yl6Xk+Kcl4jktB19JTZ7EVj1f X-Received: by 10.180.84.98 with SMTP id x2mr4543548wiy.14.1416782138900; Sun, 23 Nov 2014 14:35:38 -0800 (PST) Received: from Juliens-MacBook-Pro.local (cpc12-cmbg15-2-0-cust92.5-4.cable.virginm.net. [86.30.247.93]) by mx.google.com with ESMTPSA id 4sm15024749wjs.24.2014.11.23.14.35.37 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 23 Nov 2014 14:35:38 -0800 (PST) Message-ID: <54726138.3090003@linaro.org> Date: Sun, 23 Nov 2014 22:35:36 +0000 From: Julien Grall User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: freebsd-xen@freebsd.org, "xen-devel@lists.xen.org" , gibbs@freebsd.org, freebsd-arm@freebsd.org, roger.pau@citrix.com Subject: [RFC v2] Add support for Xen ARM guest on FreeBSD Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Denis Schneider , Ian Campbell , Stefano Stabellini X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Nov 2014 22:35:47 -0000 Hello all, At the beginning of the year, I have sent a first RFC to add support for FreeBSD on Xen ARM [1]. The first version was very primitive: hardcoded DTB, only single user-mode support,... Since then, I have improved the support and rebased everything on master. Thanks for the FreeBSD ARM team which did a great job and remove all most of my issues (Userspace hanging, Device Tree Bindings). Major changes in this new version: * Add Device Tree support via Linux Boot ABI * Add zImage support * Netfront support * Blkfront fixes * DOM0 support (separate branch see below) The former item is very hackish. I was wondering if there is another way to do it? Or maybe we should support FreeBSD Bootloader in ARM guest? The patch series is divided in X parts: * #1 - #14: Clean up and bug fixes for Xen. They can be applied without the rest of the series * #15 - #19: Update Xen interface to 4.4 and fix compilation. It's required for ARM. * #20 - #26: Update Xen code to support ARM * #27 - #33: Rework the event channel code for supporting ARM. I will work with Royger to come with a common interface with x86 * #34 - #36: Add support for ARM in Xen code * #37 - #46: ARM bug fixes and new features. Some of thoses patches (#37 - #40) could be applied without the rest of the series * #47 - #48: Add Xen ARM platform I don't really know how works patch review on Freebsd. Therefore, I provided the series in git format and file format. All based on Royger's pvh dom0 work v8: git://xenbits.xen.org/people/julieng/freebsd.git branch xen-arm-v2 http://xenbits.xen.org/people/julieng/xen-arm-v2.1/ As said above, there is a separate branch for DOM0, the patches are not part of this series. The support has been done and demoed for the Arndale (though I've been tested since a while), but there is lots of work to clean up (device tree stuff and hack in the code): git://xenbits.xen.org/people/julieng/freebsd.git branch dom0-arm-v0 http://xenbits.xen.org/people/julieng/dom0-arm-v0 TODO: * Add SMP/PSCI support in FreeBSD. Could be useful other platform too * Only FreeBSD to load anywhere. Currently there is a 2M alignment which require a patch in Xen. * ELF support in Xen ARM? Not sure it's useful. Any help, comments, questions are welcomed. Sincerely yours, [1] http://lists.freebsd.org/pipermail/freebsd-xen/2014-January/001974.html ============= Instruction to test FreeBSD on Xen on ARM =========== FreeBSD miss some support to fully boot on Xen ARM. This patch applied to Xen ARM help FreeBSD to boot correctly for the time being: * https://patches.linaro.org/32742/ To compile and boot Xen on your board, you can refer to the wiki page: http://wiki.xen.org/wiki/Xen_ARM_with_Virtualization_Extensions The instruction to compile FreeBSD for Xen on ARM: $ truncate -s 512 xenvm.img $ sudo mdconfig -f xenvm.img -u0 $ sudo newfs /dev/md0 $ sudo mount /dev/md0 /mnt $ sudo make TARGET_ARCH=armv6 kernel-toolchain $ sudo make TARGET_ARCH=armv6 KERNCONF=XENHVM buildkernel $ sudo make TARGET_ARCH=armv6 buildworld $ sudo make TARGET_ARCH=armv6 DESTDIR=/mnt installworld distribution $ echo "/dev/xbd0 / ufs rw 1 1" > /mnt/etc/fstab $ vi /mnt/etc/ttys (add the line 'xc0 "/usr/libexec/getty Pc" xterm on secure") $ sudo umount /mnt $ sudo mdconfig -d u0 Then you can copy the rootfs and the kernel to DOM 0 on your board. To boot the a FreeBSD your will required the following configuration file $ cat freebsd.xl kernel="kernel" memory=64 name="freebsd" vcpus=1 autoballon="off" disk=[ 'phy:/dev/loop0,xvda,w' ] $ losetup /dev/loop0 xenvm.img $ xl create freebsd.xl $ xl console freebsd -- Julien Grall From owner-freebsd-arm@FreeBSD.ORG Mon Nov 24 08:00:17 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C58242A2 for ; Mon, 24 Nov 2014 08:00:17 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B0C6BB72 for ; Mon, 24 Nov 2014 08:00:17 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id sAO80HYI019643 for ; Mon, 24 Nov 2014 08:00:17 GMT (envelope-from bugzilla-noreply@freebsd.org) Message-Id: <201411240800.sAO80HYI019643@kenobi.freebsd.org> From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [FreeBSD Bugzilla] Commit Needs MFC MIME-Version: 1.0 X-Bugzilla-Type: whine X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated Date: Mon, 24 Nov 2014 08:00:17 +0000 Content-Type: text/plain X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2014 08:00:17 -0000 Hi, You have a bug in the "Needs MFC" state which has not been touched in 7 or more days. This email serves as a reminder that you may want to MFC this bug or marked it as completed. In the event you have a longer MFC timeout you may update this bug with a comment and I won't remind you again for 7 days. This reminder is only sent on Mondays. Please file a bug about concerns you may have. This search was scheduled by eadler@FreeBSD.org. (28 bugs) Bug 191261: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191261 Severity: Affects Only Me Priority: --- Hardware: Any Assignee: freebsd-arm@FreeBSD.org Status: New Resolution: Summary: [raspberry pi] no cursor on latest -HEAD Bug 191599: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191599 Severity: Affects Some People Priority: --- Hardware: Any Assignee: freebsd-arm@FreeBSD.org Status: New Resolution: Summary: base OS svnlite segfaults at random Bug 193437: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193437 Severity: Affects Only Me Priority: --- Hardware: arm Assignee: freebsd-arm@FreeBSD.org Status: New Resolution: Summary: Cubieboard2: lock order reversal on poweroff Bug 193608: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193608 Severity: Affects Only Me Priority: --- Hardware: arm Assignee: freebsd-arm@FreeBSD.org Status: New Resolution: Summary: cubieboard2: kernel crash on disconnect/connect serial console Bug 194101: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194101 Severity: Affects Only Me Priority: --- Hardware: arm Assignee: freebsd-arm@FreeBSD.org Status: New Resolution: Summary: Packet forwarding not working with nat Bug 194562: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194562 Severity: Affects Only Me Priority: --- Hardware: arm Assignee: freebsd-arm@FreeBSD.org Status: New Resolution: Summary: Cubieboard2: only one USB device is seen by the system Bug 194635: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194635 Severity: Affects Many People Priority: Normal Hardware: arm Assignee: freebsd-arm@FreeBSD.org Status: Open Resolution: Summary: Speed optimisation for framebuffer console driver on Raspberry Pi Bug 134368: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=134368 Severity: Affects Only Me Priority: Normal Hardware: Any Assignee: freebsd-arm@FreeBSD.org Status: In Progress Resolution: Summary: [new driver] [patch] nslu2_led driver for the LEDs on the NSLU2 Bug 150581: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=150581 Severity: Affects Only Me Priority: Normal Hardware: Any Assignee: freebsd-arm@FreeBSD.org Status: In Progress Resolution: Summary: [irq] Unknown error generates IRQ address decoding error Bug 153380: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=153380 Severity: Affects Only Me Priority: Normal Hardware: Any Assignee: freebsd-arm@FreeBSD.org Status: In Progress Resolution: Summary: Panic / translation fault with wlan on ARM Bug 158950: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=158950 Severity: Affects Only Me Priority: Normal Hardware: Any Assignee: freebsd-arm@FreeBSD.org Status: In Progress Resolution: Summary: arm/sheevaplug fails fsx when mmap operations are enabled Bug 162159: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=162159 Severity: Affects Only Me Priority: Normal Hardware: Any Assignee: freebsd-arm@FreeBSD.org Status: In Progress Resolution: Summary: [panic] USB errors leading to panic on DockStar 9.0-RC1/arm Bug 171096: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=171096 Severity: Affects Only Me Priority: Normal Hardware: Any Assignee: freebsd-arm@FreeBSD.org Status: In Progress Resolution: Summary: [arm][xscale][ixp]Allow 16bit access on PCI bus Bug 173617: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=173617 Severity: Affects Only Me Priority: Normal Hardware: Any Assignee: freebsd-arm@FreeBSD.org Status: In Progress Resolution: Summary: Dreamplug exhibits eSATA file corruption using network interface Bug 177538: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=177538 Severity: Affects Only Me Priority: Normal Hardware: Any Assignee: freebsd-arm@FreeBSD.org Status: In Progress Resolution: Summary: tunefs(8) and mount(8) can not access a newfs(8)'d filesystem (clang, EABI). Bug 177686: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=177686 Severity: Affects Only Me Priority: Normal Hardware: Any Assignee: freebsd-arm@FreeBSD.org Status: In Progress Resolution: Summary: assertion failed in ld-elf.so.1 when invoking telnet with parameters (clang, EABI) Bug 177687: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=177687 Severity: Affects Only Me Priority: Normal Hardware: Any Assignee: freebsd-arm@FreeBSD.org Status: In Progress Resolution: Summary: gdb gets installed but does not know the EABI version if world is compiled with clang. Bug 178495: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=178495 Severity: Affects Only Me Priority: Normal Hardware: Any Assignee: freebsd-arm@FreeBSD.org Status: In Progress Resolution: Summary: buildworld fail on arm/raspberry pi Bug 179532: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=179532 Severity: Affects Only Me Priority: Normal Hardware: Any Assignee: freebsd-arm@FreeBSD.org Status: In Progress Resolution: Summary: wireless networking on ARM Bug 181601: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=181601 Severity: Affects Only Me Priority: Normal Hardware: Any Assignee: freebsd-arm@FreeBSD.org Status: In Progress Resolution: Summary: Sporadic failure of root mount on ARM/Raspberry Bug 181718: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=181718 Severity: Affects Only Me Priority: Normal Hardware: Any Assignee: freebsd-arm@FreeBSD.org Status: In Progress Resolution: Summary: threads caused hung on ARM/RPI Bug 181722: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=181722 Severity: Affects Only Me Priority: Normal Hardware: Any Assignee: freebsd-arm@FreeBSD.org Status: In Progress Resolution: Summary: gdb on ARM unable to sensibly debug core file from assert(3) Bug 183926: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=183926 Severity: Affects Only Me Priority: Normal Hardware: Any Assignee: freebsd-arm@FreeBSD.org Status: In Progress Resolution: Summary: Crash when ctrl-c while process is enter Bug 185046: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=185046 Severity: Affects Only Me Priority: Normal Hardware: Any Assignee: freebsd-arm@FreeBSD.org Status: In Progress Resolution: Summary: [armv6] issues with dhclient/sshd and jemalloc on raspberry pi and others Bug 186486: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=186486 Severity: Affects Only Me Priority: Normal Hardware: Any Assignee: freebsd-arm@FreeBSD.org Status: In Progress Resolution: Summary: WPS authentication is failing Bug 188933: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=188933 Severity: Affects Only Me Priority: Normal Hardware: Any Assignee: freebsd-arm@FreeBSD.org Status: In Progress Resolution: Summary: [lor] lock order reversal: backtrace while writing to SD/eMMC Bug 189415: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=189415 Severity: Affects Only Me Priority: Normal Hardware: Any Assignee: freebsd-arm@FreeBSD.org Status: In Progress Resolution: Summary: [patch] mount_smbfs missing from arm Bug 194251: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194251 Severity: Affects Only Me Priority: --- Hardware: arm Assignee: freebsd-arm@FreeBSD.org Status: In Progress Resolution: Summary: Efika MX Smartbook (imx51) WiFi does not work anymore From owner-freebsd-arm@FreeBSD.ORG Mon Nov 24 12:28:13 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 30063C9D for ; Mon, 24 Nov 2014 12:28:13 +0000 (UTC) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::4]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.smtp.rzone.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8F607C8B for ; Mon, 24 Nov 2014 12:28:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1416832068; l=16559; s=domk; d=ulrich-grey.de; h=Content-Transfer-Encoding:Content-Type:Mime-Version:References: In-Reply-To:Subject:Cc:To:From:Date; bh=2X4fy2SpoceHt6C3p8iNvGWz4JA=; b=J52tKUhim2bIqy4U7EsEUYNQ7SSqzk3PD7pAMOQrPN0zJae8cvxMwRvzrjqvtLnjadK lVXCVBULt2VyhafTCUWGrNm/JgrBzXKjbYqDh+E+VSOTVBVs3UVYD5116Ehq50D3rSx9m EM9vigGtwltHN5dTRdrgbYPs9vY6LPJdgEs= X-RZG-AUTH: :OX8Be0W8W+pMC3rDLL/lo2xV/LZTbZkYhOcjg8suic3iYr/B8J9Lzp3TJg46sMv8clXI X-RZG-CLASS-ID: mo00 Received: from bbu (p548680DD.dip0.t-ipconnect.de [84.134.128.221]) by smtp.strato.de (RZmta 35.13 DYNA|AUTH) with ESMTPSA id Y008e8qAOCRZTPR (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate); Mon, 24 Nov 2014 13:27:35 +0100 (CET) Date: Mon, 24 Nov 2014 13:27:33 +0100 From: Ulrich Grey To: Ulrich Grey Subject: Test Run with Alternative pmap Implementation Message-Id: <20141124132733.4e96b906f0d1ab69969dddd9@ulrich-grey.de> In-Reply-To: <20141121115941.54d4e36b103341c3adf7eb36@ulrich-grey.de> References: <20141113125236.b16cd4e5f0e339eac0494cd4@ulrich-grey.de> <20141115143444.5ad037548e06f289d2532fb7@ulrich-grey.de> <20141119225903.81fbbc7809093a0e6e0de9d5@ulrich-grey.de> <20141120151900.a68c6d8316b96a62cb65d17a@ulrich-grey.de> <20141121115941.54d4e36b103341c3adf7eb36@ulrich-grey.de> Organization: - X-Mailer: Sylpheed 3.3.0 (GTK+ 2.24.22; armv6-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org, Rui Paulo X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2014 12:28:13 -0000 Hello, as a starting point I have build an image (crochet, wandboard-quad) with the source tree from here (751adfd(master)): https://github.com/strejda/freebsd Then I build the kernel with new pmap and rebuild the whole systen. The system I used for the test run is entirely build on the wandboard-quad. The kernel is build with debugging enabled: # Debugging support. Always need this: options KDB # Enable kernel debugger support. # For minimum debugger support use KDB_TRACE, for interactive use DDB. options KDB_TRACE # Print a stack trace for a panic. options DDB # Support DDB. # For full debugger support use this instead: #options GDB # Support remote GDB. # Other debugging options... makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols options ALT_BREAK_TO_DEBUGGER # Use to enter debugger. #options DEBUG #options DEADLKRES # Enable the deadlock resolver options INVARIANTS # Enable calls of extra sanity checking options INVARIANT_SUPPORT # Extra sanity checks of internal structures, required by INVARIANTS options DIAGNOSTIC #options WITNESS # Enable checks to detect #deadlocks and cycles # I have added These options: makeoptions WITHOUT_MODULES="ispfw" # !! wihout this I get a compile error, if I build the kernel on the wandboard-quad. If I compile an image with crochet, there are no problems. # options ARM_NEW_PMAP # new pmap options NKPT2PG=64 # minimum =21 on my device # Then I had to change two files (advice from Svatopluk Kraus): # sys/arm/include/vm.h change following line: #define VM_MEMATTR_UNCACHEABLE VM_MEMATTR_NOCACHE to #define VM_MEMATTR_UNCACHEABLE VM_MEMATTR_SO # sys/arm/arm/pmap-v6-new.c put the following three lines in pmap_pinit() under comment: 2111 vm_page_t m; 2127 m = PHYS_TO_VM_PAGE(vtophys(pmap->pm_pt2tab)); 2128 m->pindex = pte1_index((vm_offset_t)PT2MAP); These changes are the result of some testruns. # As a test I did: # root@quad:/usr/src # make -j20 buildworld --- buildworld --- --- buildworld_prologue --- -------------------------------------------------------------- >>> World build started on Sun Nov 23 20:30:52 UTC 2014 -------------------------------------------------------------- # --- buildworld_epilogue --- -------------------------------------------------------------- >>> World build completed on Mon Nov 24 05:10:11 UTC 2014 -------------------------------------------------------------- # root@quad:/usr/home/gwgpi # sysctl vm.pmap. vm.pmap.pv_entry_max: 1744848 vm.pmap.shpgperproc: 200 vm.pmap.nkpt2pg: 64 vm.pmap.sp_enabled: 1 vm.pmap.pte1.demotions: 5662 vm.pmap.pte1.mappings: 106 vm.pmap.pte1.p_failures: 193942 vm.pmap.pte1.promotions: 71377 vm.pmap.pv_entry_count: 15222 vm.pmap.pc_chunk_count: 62 vm.pmap.pc_chunk_allocs: 3013814 vm.pmap.pc_chunk_frees: 3013752 vm.pmap.pc_chunk_tryfail: 0 vm.pmap.pv_entry_frees: 943580587 vm.pmap.pv_entry_allocs: 943595809 vm.pmap.pv_entry_spare: 5610 root@quad:/usr/home/gwgpi # # root@quad:/usr/home/gwgpi # uname -a FreeBSD quad 11.0-CURRENT FreeBSD 11.0-CURRENT #0 751adfd (master)-dirty: Sun Nov 23 02:42:02 UTC 2014 root@quad:/usr/local/DEVEL/obj/usr/local/DEVEL/STREJDA/freebsd/sys/WANDBOARD-QUAD arm # Here are some load averages from top -P I watched during compilation: 22.03 19,60 16,44 20,49 20,58 20,18 23,51 21,80 20,78 hw.imx6.temperature shows 46.9 C The board has a cooling fin but no case. regards Ulrich ----------------------------------------- On Fri, 21 Nov 2014 11:59:41 +0100 Ulrich Grey wrote: > Now it works! > > I have cloned the source tree from here: > > https://github.com/strejda/freebsd > > With crochet I have compiled an Image for Wandboard-Quad. > This Image started without problems. > To use the new pmap I had to add: > > options ARM_NEW_PMAP > > to the file src/sys/arm/conf/IMX6 > and to recompile the kernel. > > This kernel was not bootable, it crashes immediately. > I had to add > > options NKPT2PG=64 (advice from Svatopluk Kraus)* > > to the kernel config file and recompile. > This time the kernel booted without problems. > > root@quad:/usr/src # uname -a > FreeBSD quad 11.0-CURRENT FreeBSD 11.0-CURRENT #2 751adfd > (master)-dirty: Thu Nov 20 23:41:14 UTC 2014 > gwgpi@quad:/usr/local/DEVEL/obj/usr/local/DEVEL/STREJDA/freebsd/sys/WANDBOARD-QUAD > arm > > root@quad:/usr/src # sysctl vm.pmap. > vm.pmap.pv_entry_max: 1744848 > vm.pmap.shpgperproc: 200 > vm.pmap.nkpt2pg: 64 > vm.pmap.sp_enabled: 1 > vm.pmap.pte1.demotions: 146 > vm.pmap.pte1.mappings: 0 > vm.pmap.pte1.p_failures: 8089 > vm.pmap.pte1.promotions: 2815 > vm.pmap.pv_entry_count: 65363 > vm.pmap.pc_chunk_count: 247 > vm.pmap.pc_chunk_allocs: 177924 > vm.pmap.pc_chunk_frees: 177677 > vm.pmap.pc_chunk_tryfail: 0 > vm.pmap.pv_entry_frees: 54109068 > vm.pmap.pv_entry_allocs: 54174439 > vm.pmap.pv_entry_spare: 17620 > > In /usr/src I did: > > make -j10 buildworld > > and it accomplished without crash. > > Thank you to all for the advice > Ulrich > --- > * You can experiment with the number. Explanation can be > found in sys/arm/include/pmap-v6.h (advice from Svatopluk Kraus). > ------------------------------------------------------------------ > On Thu, 20 Nov 2014 17:06:16 +0100 > Svatopluk Kraus wrote: > > > Are you running the kernel with our pmap? If you type "sysctl > > vm.pmap", you should get something like this: > > > > root@pandaboard:~ # sysctl vm.pmap > > vm.pmap.pv_entry_max: 1488480 > > vm.pmap.shpgperproc: 200 > > vm.pmap.nkpt2pg: 10 > > vm.pmap.sp_enabled: 1 > > vm.pmap.pte1.demotions: 0 > > vm.pmap.pte1.mappings: 0 > > vm.pmap.pte1.p_failures: 44 > > vm.pmap.pte1.promotions: 9 > > vm.pmap.pv_entry_count: 11082 > > vm.pmap.pc_chunk_count: 42 > > vm.pmap.pc_chunk_allocs: 2882 > > vm.pmap.pc_chunk_frees: 2840 > > vm.pmap.pc_chunk_tryfail: 0 > > vm.pmap.pv_entry_frees: 534924 > > vm.pmap.pv_entry_allocs: 546006 > > vm.pmap.pv_entry_spare: 3030 > > > > > > Svatopluk Kraus > > > > > > > > On Thu, Nov 20, 2014 at 3:19 PM, Ulrich Grey > > wrote: > > > > > Hello, > > > > > > here the second try: > > > > > > I added this two lines in src/sys/arm/conf/IMX6 > > > > > > makeoptions WITHOUT_MODULES="ispfw" > > > without this I got a compile error in the past. > > > > > > options ARM_NEW_PMAP > > > > > > I have build the kernel without problems and rebooted. > > > Superpages are enabled. > > > > > > This is the running kernel: > > > > > > root@quad:~ # uname -a > > > FreeBSD quad 11.0-CURRENT FreeBSD 11.0-CURRENT #0 751adfd > > > (master)-dirty: Wed Nov 19 17:15:31 UTC 2014 > > > gwgpi@quad > > > :/usr/local/DEVEL/obj/usr/local/DEVEL/STREJDA/freebsd/sys/WANDBOARD-QUAD > > > arm > > > > > > The userland is on revision: r274634M > > > > > > Then I went to /usr/src and build your source tree: > > > > > > make -j10 buildworld > > > > > > After some hours the compilation stopped, but no crash occurs (an > > > endless loop?): > > > > > > cc -fpic -DPIC -O -pipe > > > -I/usr/local/DEVEL/STREJDA/freebsd/lib/libc/include > > > -I/usr/local/DEVEL/STREJDA/freebsd/lib/libc/../../include > > > -I/usr/local/DEVEL/STREJDA/freebsd/lib/lib c/arm -DNLS > > > -D__DBINTERFACE_PRIVATE > > > -I/usr/local/DEVEL/STREJDA/freebsd/lib/libc/../../contrib/gdtoa > > > -I/usr/local/DEVEL/STREJDA/freebsd/lib/libc/../../contrib/libc-vis > > > -DINET6 -I/ > > > usr/obj/usr/local/DEVEL/STREJDA/freebsd/lib/libc > > > -I/usr/local/DEVEL/STREJDA/freebsd/lib/libc/resolv -D_ACL_PRIVATE > > > -DPOSIX_MISTAKE -I/usr/local/DEVEL/STREJDA/freebsd/lib/libc/../li > > > bmd > > > -I/usr/local/DEVEL/STREJDA/freebsd/lib/libc/../../contrib/jemalloc/include > > > -I/usr/local/DEVEL/STREJDA/freebsd/lib/libc/../../contrib/tzcode/stdtime > > > -I/usr/local/DEVEL/STREJDA/f reebsd/lib/libc/stdtime > > > -I/usr/local/DEVEL/STREJDA/freebsd/lib/libc/locale -DBROKEN_DES > > > -DPORTMAP -DDES_BUILTIN > > > -I/usr/local/DEVEL/STREJDA/freebsd/lib/libc/rpc > > > -I/usr/local/DEVEL/ > > > STREJDA/freebsd/lib/libc/arm/softfloat > > > -I/usr/local/DEVEL/STREJDA/freebsd/lib/libc/softfloat > > > -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -DSYMBOL_VERSIONING > > > -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k > > > -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body > > > -Wno-string-plus-int -Wno-unused-const-variable > > > -Wno-tautological-compare -Wno-unused-value -Wno- > > > parentheses-equality -Wno-unused-function > > > -Wno-enum-conversion -Wno-switch -Wno-switch-enum > > > -Wno-knr-promoted-parameter -Qunused-arguments -c nslexer.c -o > > > nslexer.So > > > --- libc.so.7 --- > > > --- libc_pic.a --- > > > building shared library libc.so.7 > > > building special pic c library > > > ranlib -D libc_pic.a > > > > > > I waited some hours, but nothing happened anymore. > > > > > > root@quad:~ # ps auxww > > > USER PID %CPU %MEM VSZ RSS TT STAT STARTED > > > TIME COMMAND > > > > > > root 10 295.9 0.5 0 10488 - RL 1:16AM > > > 1121:36.09 [idle] > > > > > > root 92318 100.0 1.3 35396 27460 0 R 3:34AM > > > 344:30.76 cc -O -pipe > > > -I/usr/local/DEVEL/STREJDA/freebsd/lib/libc/include > > > -I/usr/local/DEVEL/STREJDA/freebsd/lib/libc/../../include > > > -I/usr/local/DEVEL/STREJDA/freebsd/lib/libc/arm -DNLS > > > -D__DBINTERFACE_PRIVATE > > > -I/usr/local/DEVEL/STREJDA/freebsd/lib/libc/../../contrib/gdtoa > > > -I/usr/local/DEVEL/STREJDA/freebsd/lib/libc/../../contrib/libc-vis > > > -DINET6 -I/usr/obj/usr/local/DEVEL/STREJDA/freebsd/lib/libc > > > -I/usr/local/DEVEL/STREJDA/freebsd/lib/libc/resolv -D_ACL_PRIVATE > > > -DPOSIX_MISTAKE > > > -I/usr/local/DEVEL/STREJDA/freebsd/lib/libc/../libmd > > > -I/usr/local/DEVEL/STREJDA/freebsd/lib/libc/../../contrib/jemalloc/include > > > -I/usr/local/DEVEL/STREJDA/freebsd/lib/libc/../../contrib/tzcode/stdtime > > > -I/usr/local/DEVEL/STREJDA/freebsd/lib/libc/stdtime > > > -I/usr/local/DEVEL/STREJDA/freebsd/lib/libc/locale -DBROKEN_DES > > > -DPORTMAP -DDES_BUILTIN > > > -I/usr/local/DEVEL/STREJDA/freebsd/lib/libc/rpc > > > -I/usr/local/DEVEL/STREJDA/freebsd/lib/libc/arm/softfloat > > > -I/usr/local/DEVEL/STREJDA/freebsd/lib/libc/softfloat > > > -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -DSYMBOL_VERSIONING > > > -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k > > > -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body > > > -Wno-string-plus-int -Wno-unused-const-variable > > > -Wno-tautological-compare -Wno-unused-value > > > -Wno-parentheses-equality -Wno-unused-function > > > -Wno-enum-conversion -Wno-switch -Wno-switch-enum > > > -Wno-knr-promoted-parameter -Qunused-arguments -c munlock.S > > > > > > root 16 0.2 0.5 0 10464 - DL 1:16AM > > > 1:54.06 [syncer] > > > > > > root 97452 0.2 0.1 11580 2996 1 S+ 9:14AM > > > 0:01.34 top -P > > > > > > root 0 0.0 0.5 0 10488 - DLs 1:16AM > > > 0:00.19 [kernel] > > > > > > root 1 0.0 0.0 9296 884 - ILs 1:16AM > > > 0:00.05 /sbin/init -- > > > > > > root 2 0.0 0.5 0 10472 - DL 1:16AM > > > 7:43.52 [cam] > > > > > > root 3 0.0 0.5 0 10464 - DL 1:16AM > > > 0:00.00 [sctp_iterator] > > > > > > root 4 0.0 0.5 0 10464 - DL 1:16AM > > > 0:00.21 [mmcsd0: mmc/sd card] > > > > > > root 5 0.0 0.5 0 10464 - DL 1:16AM > > > 0:00.26 [mmcsd1: mmc/sd card] > > > > > > root 6 0.0 0.5 0 10464 - DL 1:16AM > > > 0:12.04 [pagedaemon] > > > > > > root 7 0.0 0.5 0 10464 - DL 1:16AM > > > 0:00.00 [vmdaemon] > > > > > > root 8 0.0 0.5 0 10464 - DL 1:16AM > > > 0:00.00 [pagezero] > > > > > > root 9 0.0 0.5 0 10472 - DL 1:16AM > > > 0:01.06 [bufdaemon] > > > > > > root 11 0.0 0.5 0 10576 - WL 1:16AM > > > 50:52.07 [intr] > > > > > > root 12 0.0 0.5 0 10480 - DL 1:16AM > > > 5:42.76 [geom] > > > > > > root 13 0.0 0.5 0 10464 - DL 1:16AM > > > 2:14.70 [rand_harvestq] > > > > > > root 14 0.0 0.5 0 10520 - DL 1:16AM > > > 54:25.17 [usb] > > > > > > root 15 0.0 0.5 0 10464 - DL 1:16AM > > > 0:03.81 [vnlru] > > > > > > root 262 0.0 0.1 8896 1048 - Ss 1:17AM > > > 0:00.05 /sbin/devd > > > > > > root 347 0.0 0.1 10224 1528 - Ss 1:17AM > > > 0:00.18 /usr/sbin/syslogd -ss > > > > > > root 440 0.0 0.1 10468 1216 - Is 1:17AM > > > 0:00.01 casperd: zygote (casperd) > > > > > > root 441 0.0 0.1 10468 1292 - Is 1:17AM > > > 0:00.02 /sbin/casperd > > > > > > messagebus 475 0.0 0.1 10780 1552 - Is 1:17AM > > > 0:00.01 /usr/local/bin/dbus-daemon --system > > > > > > root 511 0.0 0.1 12712 2604 - Ss 1:17AM > > > 0:02.21 /usr/sbin/ntpd -g -c /etc/ntp.conf -p /var/run/ntpd.pid > > > -f /var/db/ntpd.drift > > > > > > root 541 0.0 0.1 15836 3012 - Is 1:17AM > > > 0:00.02 /usr/sbin/sshd > > > > > > root 545 0.0 0.1 10300 1784 - Ss 1:17AM > > > 0:00.43 /usr/sbin/cron -s > > > > > > root 601 0.0 0.3 18904 6452 - Is 1:19AM > > > 0:00.13 sshd: gwgpi [priv] (sshd) > > > > > > gwgpi 604 0.0 0.2 18904 4032 - I 1:19AM > > > 2:23.04 sshd: gwgpi@pts/0 (sshd) > > > > > > root 878 0.0 0.3 18904 6540 <3%2018904%20%206540> - > > > Is 1:20AM 0:00.18 > > > sshd: gwgpi [priv] (sshd) > > > > > > gwgpi 896 0.0 0.2 18904 4032 - S 1:20AM > > > 0:01.03 sshd: gwgpi@pts/1 (sshd) > > > > > > root 590 0.0 0.1 11208 2864 u0 Is 1:17AM > > > 0:00.10 login [pam] (login) > > > > > > root 591 0.0 0.2 11208 4472 u0 S 1:17AM > > > 0:00.21 -csh (csh) > > > > > > root 97457 0.0 0.1 10448 2084 u0 R+ 9:21AM > > > 0:00.01 ps auxww > > > > > > gwgpi 605 0.0 0.2 11208 3768 0 Is 1:19AM > > > 0:00.07 -csh (csh) > > > > > > root 607 0.0 0.1 11200 2708 0 I 1:19AM > > > 0:00.08 su > > > > > > root 608 0.0 0.2 11208 3764 0 I 1:19AM > > > 0:00.08 _su (csh) > > > > > > root 613 0.0 0.1 8944 1120 0 S+ 1:20AM > > > 0:03.32 make -j10 buildworld > > > > > > root 618 0.0 0.1 10740 2288 0 I 1:20AM > > > 0:00.01 sh -ev > > > > > > root 619 0.0 0.1 8944 1648 0 S 1:20AM > > > 0:02.76 make -m /usr/local/DEVEL/STREJDA/freebsd/share/mk -f > > > Makefile.inc1 TARGET=arm TARGET_ARCH=armv6 buildworld > > > > > > root 83869 0.0 0.1 10740 2340 0 I 3:23AM > > > 0:00.02 sh -ev > > > > > > root 83870 0.0 0.1 8944 1724 0 S 3:23AM > > > 0:00.94 make -f Makefile.inc1 > > > DESTDIR=/usr/obj/usr/local/DEVEL/STREJDA/freebsd/tmp -DNO_FSCHG > > > MK_HTML=no MK_INFO=no -DNO_LINT MK_MAN=no MK_PROFILE=no > > > MK_TESTS=no MK_TESTS_SUPPORT=yes libraries > > > > > > root 83883 0.0 0.1 10740 2288 0 I 3:23AM > > > 0:00.01 sh -ev > > > > > > root 84734 0.0 0.1 8944 1724 0 S 3:24AM > > > 0:01.01 make -f Makefile.inc1 _startup_libs > > > > > > root 84750 0.0 0.1 10740 2340 0 I 3:24AM > > > 0:00.04 sh -ev > > > > > > root 86840 0.0 1.2 29424 24084 0 S 3:28AM > > > 0:15.96 make MK_TESTS=no DIRPRFX=lib/libc/ all > > > > > > root 92313 0.0 0.1 10740 2284 0 I 3:34AM > > > 0:00.09 sh -ev > > > > > > gwgpi 897 0.0 0.2 11208 3768 1 Is 1:20AM > > > 0:00.08 -csh (csh) > > > > > > root 906 0.0 0.1 11200 2708 1 I 1:20AM > > > 0:00.11 su > > > > > > root 945 0.0 0.2 11208 3764 1 I 1:20AM > > > 0:00.21 _su (csh) > > > > > > root@quad:~ # sysctl vm.pmap. > > > vm.pmap.sp_enabled: 1 > > > vm.pmap.pv_entry_count: 5691 > > > vm.pmap.pv_entry_max: 1744848 > > > vm.pmap.shpgperproc: 200 > > > vm.pmap.section.demotions: 3 > > > vm.pmap.section.mappings: 0 > > > vm.pmap.section.p_failures: 35 > > > vm.pmap.section.promotions: 8 > > > > > > -- > > > regards > > > Ulrich > > > ---------------------------------- > > > On Thu, 20 Nov 2014 00:04:38 +0100 > > > Svatopluk Kraus wrote: > > > > > > > On Wed, Nov 19, 2014 at 10:59 PM, Ulrich Grey > > > > wrote: > > > > > > > > > Thank you for the offer, I have tried it. > > > > > > > > > > After I had cloned your repository I have added 2 lines to > > > > > src/sys/arm/conf/IMX6: > > > > > > > > > > makeoptions WITHOUT_MODULES="ispfw" # compile error > > > > > makeoptions ARM_NEW_PMAP="yes" # is that ok ? > > > > > > > > > > > > > > Add this line to sys/arm/conf/IMX6 file: > > > > > > > > options ARM_NEW_PMAP > > > > > > > > Svatopluk Kraus > > > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@FreeBSD.ORG Mon Nov 24 14:53:38 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CBA697BE for ; Mon, 24 Nov 2014 14:53:38 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9A589F23 for ; Mon, 24 Nov 2014 14:53:38 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Xsv1E-000Eoz-P1; Mon, 24 Nov 2014 14:53:36 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id sAOErZue010724; Mon, 24 Nov 2014 07:53:35 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19ZOCBHyh65hQx6xHntQpCf X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: Test Run with Alternative pmap Implementation From: Ian Lepore To: Ulrich Grey In-Reply-To: <20141124132733.4e96b906f0d1ab69969dddd9@ulrich-grey.de> References: <20141113125236.b16cd4e5f0e339eac0494cd4@ulrich-grey.de> <20141115143444.5ad037548e06f289d2532fb7@ulrich-grey.de> <20141119225903.81fbbc7809093a0e6e0de9d5@ulrich-grey.de> <20141120151900.a68c6d8316b96a62cb65d17a@ulrich-grey.de> <20141121115941.54d4e36b103341c3adf7eb36@ulrich-grey.de> <20141124132733.4e96b906f0d1ab69969dddd9@ulrich-grey.de> Content-Type: text/plain; charset="us-ascii" Date: Mon, 24 Nov 2014 07:53:34 -0700 Message-ID: <1416840814.1147.380.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2014 14:53:39 -0000 On Mon, 2014-11-24 at 13:27 +0100, Ulrich Grey wrote: > Hello, > > as a starting point I have build an image (crochet, wandboard-quad) with > the source tree from here (751adfd(master)): > > https://github.com/strejda/freebsd > > Then I build the kernel with new pmap and rebuild the whole systen. > The system I used for the test run is entirely build on the > wandboard-quad. > [...] I've also been testing those pmap changes this weekend. The only change I made was to add options ARM_NEW_PMAP and NKPT2PG=64 to the kernel config. In particular, I did not change VM_MEMATTR_UNCACHEABLE (so that in effect I'm also testing the recent busdma changes). I've had two wandboard quads doing builds continuously all weekend. I did the builds that have previously been reported as problems here -- buildworld -j10, ports libX11, plus a lot of other ports including much of the full xorg (until it ran into some x86 device drivers and died), some of libreoffice (it had a problem that wasn't related to crashing or anything), python, bash, emacs, boost, rsync. After all that I just set both boards to continuously doing "rm -rf /usr/obj/* ; make -j5 buildworld" in a loop, and they're still running. One is using an SSD drive and the other is using NFS. In all that building all weekend the only glitches I've seen are this: warning: pmap_remove_pages called with non-current pmap that appeared twice on the board using NFS root. For anyone else wanting to test, there is currently one conflict when applying the patches, in busdma_machdep-v6.c, because some of the changes in the patch have already been applied. Just resolve the conflict by skipping that file / restoring the original unpatched file. This stuff is looking really good. It wouldn't hurt at all if some more people were testing it, especially on other hardware including rpi and beaglebone. -- Ian From owner-freebsd-arm@FreeBSD.ORG Mon Nov 24 15:17:42 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B2B2196; Mon, 24 Nov 2014 15:17:42 +0000 (UTC) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 443B71BC; Mon, 24 Nov 2014 15:17:42 +0000 (UTC) Received: by mail-wi0-f180.google.com with SMTP id n3so6145557wiv.7 for ; Mon, 24 Nov 2014 07:17:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=TDlWwbY2O1kPkEZBebYZVgtHc2t5CikUL1BaqFUZpM4=; b=JaTfwIjVU5Zm8E2iWsmNFas9iKC7DRs8IIw1QpK7WXqgqMd0JatAi7gxxalDq6EMeH Izby/ISfBTbKq2lNQsDdnUjoNFcPUI2FxfhMDmSLsit8OvatBzNu00dK++GxDQ9ho5Ud DIau0Y4wwJ7tYLlYWgMVe3R27qK96DogiBEXAWz+bm3QVXJd8oJhSJKNSr4h0an1PwYB suaHHACPRRjWEPvbeDLf/HfcMvWGwko+jxdiOn3DPSxH+a2Gj91YHqssKFuxORbmqryT 66ZZZH5Z5f25+NeKvj/asGC5VsAT3RGBaeUNBRJ+qN0cmO1REJVHvO0dijKNDPZVaDXM Lncg== MIME-Version: 1.0 X-Received: by 10.180.85.198 with SMTP id j6mr22131148wiz.23.1416842260481; Mon, 24 Nov 2014 07:17:40 -0800 (PST) Sender: zbodek@gmail.com Received: by 10.216.123.1 with HTTP; Mon, 24 Nov 2014 07:17:40 -0800 (PST) In-Reply-To: <1416840814.1147.380.camel@revolution.hippie.lan> References: <20141113125236.b16cd4e5f0e339eac0494cd4@ulrich-grey.de> <20141115143444.5ad037548e06f289d2532fb7@ulrich-grey.de> <20141119225903.81fbbc7809093a0e6e0de9d5@ulrich-grey.de> <20141120151900.a68c6d8316b96a62cb65d17a@ulrich-grey.de> <20141121115941.54d4e36b103341c3adf7eb36@ulrich-grey.de> <20141124132733.4e96b906f0d1ab69969dddd9@ulrich-grey.de> <1416840814.1147.380.camel@revolution.hippie.lan> Date: Mon, 24 Nov 2014 16:17:40 +0100 X-Google-Sender-Auth: OgLpQzhlKbm4OmB5yGBNcLqVy0I Message-ID: Subject: Re: Test Run with Alternative pmap Implementation From: Zbigniew Bodek To: Ian Lepore Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2014 15:17:42 -0000 2014-11-24 15:53 GMT+01:00 Ian Lepore : > On Mon, 2014-11-24 at 13:27 +0100, Ulrich Grey wrote: >> Hello, >> >> as a starting point I have build an image (crochet, wandboard-quad) with >> the source tree from here (751adfd(master)): >> >> https://github.com/strejda/freebsd >> >> Then I build the kernel with new pmap and rebuild the whole systen. >> The system I used for the test run is entirely build on the >> wandboard-quad. >> [...] > > I've also been testing those pmap changes this weekend. The only change > I made was to add options ARM_NEW_PMAP and NKPT2PG=64 to the kernel > config. In particular, I did not change VM_MEMATTR_UNCACHEABLE (so that > in effect I'm also testing the recent busdma changes). > > I've had two wandboard quads doing builds continuously all weekend. I > did the builds that have previously been reported as problems here -- > buildworld -j10, ports libX11, plus a lot of other ports including much > of the full xorg (until it ran into some x86 device drivers and died), > some of libreoffice (it had a problem that wasn't related to crashing or > anything), python, bash, emacs, boost, rsync. > > After all that I just set both boards to continuously doing "rm > -rf /usr/obj/* ; make -j5 buildworld" in a loop, and they're still > running. One is using an SSD drive and the other is using NFS. > > In all that building all weekend the only glitches I've seen are this: > > warning: pmap_remove_pages called with non-current pmap > > that appeared twice on the board using NFS root. > > For anyone else wanting to test, there is currently one conflict when > applying the patches, in busdma_machdep-v6.c, because some of the > changes in the patch have already been applied. Just resolve the > conflict by skipping that file / restoring the original unpatched file. > > This stuff is looking really good. It wouldn't hurt at all if some more > people were testing it, especially on other hardware including rpi and > beaglebone. > Hello, This new pmap implementation looks VERY good indeed. However I was not able to boot this kernel on Armada XP and currently I don't have time to debug this. On the other hand after e-mails with crash reports on Wandbord I did similar (buildworld, port build) tests on AXP and it didn't crash. In particular it survived 2 days of buildworld in loop. I wonder, what is the functional difference between AXP and other that prevents those crashes. Ian, are you planning to replace the pmap with the new implementation? Best regards zbb From owner-freebsd-arm@FreeBSD.ORG Mon Nov 24 15:40:54 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0DE8847D for ; Mon, 24 Nov 2014 15:40:54 +0000 (UTC) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::11]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.smtp.rzone.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 90A9B3F1 for ; Mon, 24 Nov 2014 15:40:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1416843624; l=1789; s=domk; d=ulrich-grey.de; h=Content-Transfer-Encoding:Content-Type:Mime-Version:References: In-Reply-To:Subject:Cc:To:From:Date; bh=T+hIdsKtBqY4+WTVs7DWhuRKoF4=; b=AISqFgGmIesRhPCgRvK++pm9H7HT5J1C21+3y8nCGEqwjwEIBVZSZfQrMcvXqE7wWwe RvbOXgglENWa8A1jlpb1eo3uZTxgRZFL1c7Do2NEFfPdejq7uUp5ONksMNiGw3aAoD7Ij kq0wIEW03T9IemH3OjQrm1cdY2hxM0rdFb4= X-RZG-AUTH: :OX8Be0W8W+pMC3rDLL/lo2xV/LZTbZkYhOcjg8suic3iYr/B8J9Lzp3TJg46sMv8clXI X-RZG-CLASS-ID: mo00 Received: from bbu (p548680DD.dip0.t-ipconnect.de [84.134.128.221]) by smtp.strato.de (RZmta 35.13 DYNA|AUTH) with ESMTPSA id 604ec5qAOFe8Xoj (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate); Mon, 24 Nov 2014 16:40:08 +0100 (CET) Date: Mon, 24 Nov 2014 16:40:06 +0100 From: Ulrich Grey To: Ian Lepore Subject: Re: Test Run with Alternative pmap Implementation Message-Id: <20141124164006.ce3e101e04828df66bacada5@ulrich-grey.de> In-Reply-To: <1416840814.1147.380.camel@revolution.hippie.lan> References: <20141113125236.b16cd4e5f0e339eac0494cd4@ulrich-grey.de> <20141115143444.5ad037548e06f289d2532fb7@ulrich-grey.de> <20141119225903.81fbbc7809093a0e6e0de9d5@ulrich-grey.de> <20141120151900.a68c6d8316b96a62cb65d17a@ulrich-grey.de> <20141121115941.54d4e36b103341c3adf7eb36@ulrich-grey.de> <20141124132733.4e96b906f0d1ab69969dddd9@ulrich-grey.de> <1416840814.1147.380.camel@revolution.hippie.lan> Organization: - X-Mailer: Sylpheed 3.3.0 (GTK+ 2.24.22; armv6-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2014 15:40:54 -0000 On Mon, 24 Nov 2014 07:53:34 -0700 Ian Lepore wrote: Hello, > I've also been testing those pmap changes this weekend. The only change > I made was to add options ARM_NEW_PMAP and NKPT2PG=64 to the kernel > config. In particular, I did not change VM_MEMATTR_UNCACHEABLE (so that > in effect I'm also testing the recent busdma changes). Here is the reason, why I changed VM_MEMATTR_UNCACHEABLE (from an email to Svatopluk Kraus): When I tried to log into the system with ssh, it lasts a minute or more to get an input prompt. It is the kernel, that was compiled with: options NKPT2PG=64 I tried to reduce the number (32, 26, 23, 21). 20 is the default in sys/arm/include/pmap-v6.h and crashes the system, # 21 works! If I decrease the numbers, the delay is reduced but remains cumbersome. If I use the kernel with old pmap, no delay is noticeable. If I use the TAB-key for autocompletition, there is a delay of some seconds until the prompt appears. If I press the RIGHT-ARROW-key after the TAB-key, sometimes it is faster. In the editor ee the cursor disappears for seconds. I have never observed such a behavior before. This appears only with ssh. On the serial console there is no delay. Is there any way to improve that? The answer from Svatopluk Kraus: I have only one idea for now what you can try. We changed memory attributes for uncacheable DMA buffers. However, some not well designed drivers could have unpredictable behaviour now. Get sys/arm/include/vm.h file and change following line: #define VM_MEMATTR_UNCACHEABLE VM_MEMATTR_NOCACHE to #define VM_MEMATTR_UNCACHEABLE VM_MEMATTR_SO My answer: I have changed sys/arm/include/vm.h and rebuild the kernel. The normal behavior is back. Ulrich From owner-freebsd-arm@FreeBSD.ORG Mon Nov 24 16:05:48 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0FFC4BF3; Mon, 24 Nov 2014 16:05:48 +0000 (UTC) Received: from mail-qa0-x22b.google.com (mail-qa0-x22b.google.com [IPv6:2607:f8b0:400d:c00::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B4D7794D; Mon, 24 Nov 2014 16:05:47 +0000 (UTC) Received: by mail-qa0-f43.google.com with SMTP id bm13so6646693qab.30 for ; Mon, 24 Nov 2014 08:05:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=J6mHm2hellfwoImwCFhPgm3+zyr12HIEQA/G+GH39h8=; b=W8Vks3JILgsWfXEIH3KU1RbBkbEvy+4QMEXTKLVwZ/msBegrSE4D8un6sijUg8Y7u2 z/w/i1P7J4nlYXuR2uzBlAvdiZh7xdSave3dAFYs9vQtNAhgWhcZrcDJp3V2eOn2t6yn JbfZH7gcA0p3NZY+KI96gaDAzFx5tOH+5bVrnGjSbt355KUkbmKFSt3RqGCjrtO5zxmb 0FWGsqg72rU8aLDx9QCGx9IbTm9oI3W6HGrLciO8CeYUikwwY1T/fmXaAgcf+ytb34/2 iDsStYy4WvajSa4Sm55j1tVM/nfQaznc00yl+mzDM3kSO6XagjwsAIOhoFkDmKOAqbAX gyow== MIME-Version: 1.0 X-Received: by 10.140.44.36 with SMTP id f33mr29738107qga.105.1416845146791; Mon, 24 Nov 2014 08:05:46 -0800 (PST) Received: by 10.140.23.242 with HTTP; Mon, 24 Nov 2014 08:05:46 -0800 (PST) In-Reply-To: <1416840814.1147.380.camel@revolution.hippie.lan> References: <20141113125236.b16cd4e5f0e339eac0494cd4@ulrich-grey.de> <20141115143444.5ad037548e06f289d2532fb7@ulrich-grey.de> <20141119225903.81fbbc7809093a0e6e0de9d5@ulrich-grey.de> <20141120151900.a68c6d8316b96a62cb65d17a@ulrich-grey.de> <20141121115941.54d4e36b103341c3adf7eb36@ulrich-grey.de> <20141124132733.4e96b906f0d1ab69969dddd9@ulrich-grey.de> <1416840814.1147.380.camel@revolution.hippie.lan> Date: Mon, 24 Nov 2014 17:05:46 +0100 Message-ID: Subject: Re: Test Run with Alternative pmap Implementation From: Svatopluk Kraus To: Ian Lepore Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2014 16:05:48 -0000 On Mon, Nov 24, 2014 at 3:53 PM, Ian Lepore wrote: > On Mon, 2014-11-24 at 13:27 +0100, Ulrich Grey wrote: > > Hello, > > > > as a starting point I have build an image (crochet, wandboard-quad) with > > the source tree from here (751adfd(master)): > > > > https://github.com/strejda/freebsd > > > > Then I build the kernel with new pmap and rebuild the whole systen. > > The system I used for the test run is entirely build on the > > wandboard-quad. > > [...] > > I've also been testing those pmap changes this weekend. The only change > I made was to add options ARM_NEW_PMAP and NKPT2PG=64 to the kernel > config. In particular, I did not change VM_MEMATTR_UNCACHEABLE (so that > in effect I'm also testing the recent busdma changes). > > I've had two wandboard quads doing builds continuously all weekend. I > did the builds that have previously been reported as problems here -- > buildworld -j10, ports libX11, plus a lot of other ports including much > of the full xorg (until it ran into some x86 device drivers and died), > some of libreoffice (it had a problem that wasn't related to crashing or > anything), python, bash, emacs, boost, rsync. > > After all that I just set both boards to continuously doing "rm > -rf /usr/obj/* ; make -j5 buildworld" in a loop, and they're still > running. One is using an SSD drive and the other is using NFS. > > In all that building all weekend the only glitches I've seen are this: > > warning: pmap_remove_pages called with non-current pmap > > that appeared twice on the board using NFS root. > > It could be false positive prints due to the way how current pmap is got there. Even if I know that PCPU_GET() is not atomic and need to be wrapped in this case at least by sched_pin() and sched_unpin() calls, I missed it there. Svata > For anyone else wanting to test, there is currently one conflict when > applying the patches, in busdma_machdep-v6.c, because some of the > changes in the patch have already been applied. Just resolve the > conflict by skipping that file / restoring the original unpatched file. > > This stuff is looking really good. It wouldn't hurt at all if some more > people were testing it, especially on other hardware including rpi and > beaglebone. > > -- Ian > > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > From owner-freebsd-arm@FreeBSD.ORG Mon Nov 24 16:13:51 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 02C139E for ; Mon, 24 Nov 2014 16:13:51 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C2BE5A3D for ; Mon, 24 Nov 2014 16:13:50 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1XswGr-000IMP-4s; Mon, 24 Nov 2014 16:13:49 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id sAOGDlRG010855; Mon, 24 Nov 2014 09:13:47 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+f0cbjfK8Bi5zf/nULdG/H X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: Test Run with Alternative pmap Implementation From: Ian Lepore To: Ulrich Grey In-Reply-To: <20141124164006.ce3e101e04828df66bacada5@ulrich-grey.de> References: <20141113125236.b16cd4e5f0e339eac0494cd4@ulrich-grey.de> <20141115143444.5ad037548e06f289d2532fb7@ulrich-grey.de> <20141119225903.81fbbc7809093a0e6e0de9d5@ulrich-grey.de> <20141120151900.a68c6d8316b96a62cb65d17a@ulrich-grey.de> <20141121115941.54d4e36b103341c3adf7eb36@ulrich-grey.de> <20141124132733.4e96b906f0d1ab69969dddd9@ulrich-grey.de> <1416840814.1147.380.camel@revolution.hippie.lan> <20141124164006.ce3e101e04828df66bacada5@ulrich-grey.de> Content-Type: text/plain; charset="us-ascii" Date: Mon, 24 Nov 2014 09:13:46 -0700 Message-ID: <1416845626.1147.391.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2014 16:13:51 -0000 On Mon, 2014-11-24 at 16:40 +0100, Ulrich Grey wrote: > On Mon, 24 Nov 2014 07:53:34 -0700 > Ian Lepore wrote: > > Hello, > > I've also been testing those pmap changes this weekend. The only change > > I made was to add options ARM_NEW_PMAP and NKPT2PG=64 to the kernel > > config. In particular, I did not change VM_MEMATTR_UNCACHEABLE (so that > > in effect I'm also testing the recent busdma changes). > > Here is the reason, why I changed VM_MEMATTR_UNCACHEABLE > (from an email to Svatopluk Kraus): > > When I tried to log into the system with ssh, it lasts a minute or more > to get an input prompt. It is the kernel, that was compiled with: > > options NKPT2PG=64 > > I tried to reduce the number (32, 26, 23, 21). 20 is the default in > sys/arm/include/pmap-v6.h and crashes the system, # 21 works! If I > decrease the numbers, the delay is reduced but remains cumbersome. If I > use the kernel with old pmap, no delay is noticeable. > > If I use the TAB-key for autocompletition, there is a delay of some > seconds until the prompt appears. If I press the RIGHT-ARROW-key after > the TAB-key, sometimes it is faster. In the editor ee the cursor > disappears for seconds. I have never observed such a behavior before. > > This appears only with ssh. On the serial console there is no delay. > Is there any way to improve that? > > The answer from Svatopluk Kraus: > > I have only one idea for now what you can try. We changed memory attributes > for uncacheable DMA buffers. However, some not well designed drivers could > have unpredictable behaviour now. Get sys/arm/include/vm.h file and > change following line: > > #define VM_MEMATTR_UNCACHEABLE VM_MEMATTR_NOCACHE > > to > > #define VM_MEMATTR_UNCACHEABLE VM_MEMATTR_SO > > My answer: > > I have changed sys/arm/include/vm.h > and rebuild the kernel. > > The normal behavior is back. Oh, of course! This is my fault and I forgot all about it, I'm sorry. There is a bug in the ffec driver that was being masked by the VM_MEMATTR_SO, I discovered it right away Saturday morning when I applied the pmap patches (I couldn't even boot with nfsroot), fixed it, then forgot to commit the fix. I'll go commit it right now (r274967), then you should be able to set the MEMATTR back to VM_MEMATTR_NOCACHE. We may find similar trouble in other device drivers, especially network drivers. -- Ian From owner-freebsd-arm@FreeBSD.ORG Mon Nov 24 16:39:26 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B8C30A87; Mon, 24 Nov 2014 16:39:26 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 726F1CCE; Mon, 24 Nov 2014 16:39:26 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Xswfd-000Afo-2o; Mon, 24 Nov 2014 16:39:25 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id sAOGdOTf010882; Mon, 24 Nov 2014 09:39:24 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18liOwxo3gFzR42Tbu7fECL X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: Test Run with Alternative pmap Implementation From: Ian Lepore To: Zbigniew Bodek In-Reply-To: References: <20141113125236.b16cd4e5f0e339eac0494cd4@ulrich-grey.de> <20141115143444.5ad037548e06f289d2532fb7@ulrich-grey.de> <20141119225903.81fbbc7809093a0e6e0de9d5@ulrich-grey.de> <20141120151900.a68c6d8316b96a62cb65d17a@ulrich-grey.de> <20141121115941.54d4e36b103341c3adf7eb36@ulrich-grey.de> <20141124132733.4e96b906f0d1ab69969dddd9@ulrich-grey.de> <1416840814.1147.380.camel@revolution.hippie.lan> Content-Type: text/plain; charset="us-ascii" Date: Mon, 24 Nov 2014 09:39:23 -0700 Message-ID: <1416847163.1147.396.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2014 16:39:26 -0000 On Mon, 2014-11-24 at 16:17 +0100, Zbigniew Bodek wrote: > 2014-11-24 15:53 GMT+01:00 Ian Lepore : > > On Mon, 2014-11-24 at 13:27 +0100, Ulrich Grey wrote: > >> Hello, > >> > >> as a starting point I have build an image (crochet, wandboard-quad) with > >> the source tree from here (751adfd(master)): > >> > >> https://github.com/strejda/freebsd > >> > >> Then I build the kernel with new pmap and rebuild the whole systen. > >> The system I used for the test run is entirely build on the > >> wandboard-quad. > >> [...] > > > > I've also been testing those pmap changes this weekend. The only change > > I made was to add options ARM_NEW_PMAP and NKPT2PG=64 to the kernel > > config. In particular, I did not change VM_MEMATTR_UNCACHEABLE (so that > > in effect I'm also testing the recent busdma changes). > > > > I've had two wandboard quads doing builds continuously all weekend. I > > did the builds that have previously been reported as problems here -- > > buildworld -j10, ports libX11, plus a lot of other ports including much > > of the full xorg (until it ran into some x86 device drivers and died), > > some of libreoffice (it had a problem that wasn't related to crashing or > > anything), python, bash, emacs, boost, rsync. > > > > After all that I just set both boards to continuously doing "rm > > -rf /usr/obj/* ; make -j5 buildworld" in a loop, and they're still > > running. One is using an SSD drive and the other is using NFS. > > > > In all that building all weekend the only glitches I've seen are this: > > > > warning: pmap_remove_pages called with non-current pmap > > > > that appeared twice on the board using NFS root. > > > > For anyone else wanting to test, there is currently one conflict when > > applying the patches, in busdma_machdep-v6.c, because some of the > > changes in the patch have already been applied. Just resolve the > > conflict by skipping that file / restoring the original unpatched file. > > > > This stuff is looking really good. It wouldn't hurt at all if some more > > people were testing it, especially on other hardware including rpi and > > beaglebone. > > > > Hello, > > This new pmap implementation looks VERY good indeed. > However I was not able to boot this kernel on Armada XP and currently > I don't have time to debug this. > On the other hand after e-mails with crash reports on Wandbord I did > similar (buildworld, port build) tests on AXP and it didn't crash. > In particular it survived 2 days of buildworld in loop. > I wonder, what is the functional difference between AXP and other that > prevents those crashes. > > Ian, are you planning to replace the pmap with the new implementation? > Eventually (and soon I hope), yes it will be committed, but not before we've tested it on all the platforms we support (or at least all the ones we can get someone to test, we can't wait forever for obscure hardware nobody has anymore). One quick thing that might be worth trying on AXP is the change mentioned eariler... in arm/include/vm.h, in the line #define VM_MEMATTR_UNCACHEABLE VM_MEMATTR_NOCACHE Replace VM_MEMATTR_NOCACHE with VM_MEMATTR_SO; that will cover up a lot of bugs in old drivers. -- Ian From owner-freebsd-arm@FreeBSD.ORG Mon Nov 24 18:57:59 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E5479464; Mon, 24 Nov 2014 18:57:58 +0000 (UTC) Received: from mail-qc0-x22b.google.com (mail-qc0-x22b.google.com [IPv6:2607:f8b0:400d:c01::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 93E4867; Mon, 24 Nov 2014 18:57:58 +0000 (UTC) Received: by mail-qc0-f171.google.com with SMTP id r5so7256893qcx.2 for ; Mon, 24 Nov 2014 10:57:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=erLNT74obDZmSiPs419kjGSGBcRMrHEZwxrI2pJWHdU=; b=QgJ7XKhnAqZQmp3bzQw8XwJlOabwidz3IizQGf8fq/44s4tUCDEN6Gpb1z0mAsai4i A9yGfvY2xkDqsD33a4sqdaGsua8109pUedTuXYw8YBWONDMUG1wY3keHXizc2Gh4wXDo C7nu2TJOMRcOc5CV1Wtsy3GvYUQ8PrkzVw1MskWsjxi/Z30GQYpCR1RyO6IMj11pELj2 7kQdoU7bmqqbpzsxlzJQG2iq6bj3KgtPqa4PWjzgqTDwRsGEUuk4hEFn7UUaHAxQviSa HkfLmucDtMlglNFiApVWz+aRai0aCJMyaojaYjd4p2imAJkPHRQSKExvvnIdfhhYML46 2YYQ== MIME-Version: 1.0 X-Received: by 10.224.129.196 with SMTP id p4mr32016935qas.1.1416855477855; Mon, 24 Nov 2014 10:57:57 -0800 (PST) Received: by 10.140.23.242 with HTTP; Mon, 24 Nov 2014 10:57:57 -0800 (PST) In-Reply-To: <1416847163.1147.396.camel@revolution.hippie.lan> References: <20141113125236.b16cd4e5f0e339eac0494cd4@ulrich-grey.de> <20141115143444.5ad037548e06f289d2532fb7@ulrich-grey.de> <20141119225903.81fbbc7809093a0e6e0de9d5@ulrich-grey.de> <20141120151900.a68c6d8316b96a62cb65d17a@ulrich-grey.de> <20141121115941.54d4e36b103341c3adf7eb36@ulrich-grey.de> <20141124132733.4e96b906f0d1ab69969dddd9@ulrich-grey.de> <1416840814.1147.380.camel@revolution.hippie.lan> <1416847163.1147.396.camel@revolution.hippie.lan> Date: Mon, 24 Nov 2014 19:57:57 +0100 Message-ID: Subject: Re: Test Run with Alternative pmap Implementation From: Svatopluk Kraus To: Ian Lepore Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2014 18:57:59 -0000 On Mon, Nov 24, 2014 at 5:39 PM, Ian Lepore wrote: > On Mon, 2014-11-24 at 16:17 +0100, Zbigniew Bodek wrote: > > 2014-11-24 15:53 GMT+01:00 Ian Lepore : > > > On Mon, 2014-11-24 at 13:27 +0100, Ulrich Grey wrote: > > >> Hello, > > >> > > >> as a starting point I have build an image (crochet, wandboard-quad) > with > > >> the source tree from here (751adfd(master)): > > >> > > >> https://github.com/strejda/freebsd > > >> > > >> Then I build the kernel with new pmap and rebuild the whole systen. > > >> The system I used for the test run is entirely build on the > > >> wandboard-quad. > > >> [...] > > > > > > I've also been testing those pmap changes this weekend. The only > change > > > I made was to add options ARM_NEW_PMAP and NKPT2PG=64 to the kernel > > > config. In particular, I did not change VM_MEMATTR_UNCACHEABLE (so > that > > > in effect I'm also testing the recent busdma changes). > > > > > > I've had two wandboard quads doing builds continuously all weekend. I > > > did the builds that have previously been reported as problems here -- > > > buildworld -j10, ports libX11, plus a lot of other ports including much > > > of the full xorg (until it ran into some x86 device drivers and died), > > > some of libreoffice (it had a problem that wasn't related to crashing > or > > > anything), python, bash, emacs, boost, rsync. > > > > > > After all that I just set both boards to continuously doing "rm > > > -rf /usr/obj/* ; make -j5 buildworld" in a loop, and they're still > > > running. One is using an SSD drive and the other is using NFS. > > > > > > In all that building all weekend the only glitches I've seen are this: > > > > > > warning: pmap_remove_pages called with non-current pmap > > > > > > that appeared twice on the board using NFS root. > > > > > > For anyone else wanting to test, there is currently one conflict when > > > applying the patches, in busdma_machdep-v6.c, because some of the > > > changes in the patch have already been applied. Just resolve the > > > conflict by skipping that file / restoring the original unpatched file. > > > > > > This stuff is looking really good. It wouldn't hurt at all if some > more > > > people were testing it, especially on other hardware including rpi and > > > beaglebone. > > > > > > > Hello, > > > > This new pmap implementation looks VERY good indeed. > > However I was not able to boot this kernel on Armada XP and currently > > I don't have time to debug this. > > On the other hand after e-mails with crash reports on Wandbord I did > > similar (buildworld, port build) tests on AXP and it didn't crash. > > In particular it survived 2 days of buildworld in loop. > > I wonder, what is the functional difference between AXP and other that > > prevents those crashes. > > > > Ian, are you planning to replace the pmap with the new implementation? > > > > Eventually (and soon I hope), yes it will be committed, but not before > we've tested it on all the platforms we support (or at least all the > ones we can get someone to test, we can't wait forever for obscure > hardware nobody has anymore). > > One quick thing that might be worth trying on AXP is the change > mentioned eariler... in arm/include/vm.h, in the line > > #define VM_MEMATTR_UNCACHEABLE VM_MEMATTR_NOCACHE > > Replace VM_MEMATTR_NOCACHE with VM_MEMATTR_SO; that will cover up a lot > of bugs in old drivers. > > -- Ian > > > Michal has updated git repository. As we are tracking current freebsd tree, we use rebase. This way git pull command does not work and after any update git clone command must be used again. We are sorry for that. We changed default value for NKPT2PG option. Hopefully, it covers needs of all freebsd supported armv6 platforms with RAM up to 2GB for testing purposes. Anyhow, it is an option to be set invidually for each platform. Next, two small fixes was done. The one of them could be critical for system startup. The other was exposed by Ulrich Grey testing. We leave memory attributes for DMA buffer untouched. So, if anything does not work, first try to change this attributes how was already described in this thread. Svata From owner-freebsd-arm@FreeBSD.ORG Tue Nov 25 19:17:32 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BE6C935B for ; Tue, 25 Nov 2014 19:17:32 +0000 (UTC) Received: from mail.FoxValley.net (mail.FoxValley.net [64.135.192.34]) by mx1.freebsd.org (Postfix) with SMTP id 89ACC9F0 for ; Tue, 25 Nov 2014 19:17:32 +0000 (UTC) Received: (qmail 6699 invoked from network) for freebsd-arm@freebsd.org; 25 Nov 2014 13:17:26 -0600 Received: from marengo.foxvalley.net (draymond@64.135.192.25) by mail.foxvalley.net with SMTP; 25 Nov 2014 13:17:26 -0600 Received: from sp5.qualcomm.com (sp5.qualcomm.com [199.106.103.55]) by webmail.FoxValley.net (Horde MIME library) with HTTP; Tue, 25 Nov 2014 13:17:26 -0600 Message-ID: <20141125131726.u0wepbqanhv0owog@webmail.FoxValley.net> Date: Tue, 25 Nov 2014 13:17:26 -0600 From: draymond@FoxValley.net To: freebsd-arm@freebsd.org Subject: re: new support for Raspberry Pi B+ MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.2) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2014 19:17:32 -0000 It seems that "portsnap fetch update" is a consistent way to generate =20 a panic. I have now seen panics with all four of my SD cards on two =20 different Raspberry Pis, and with three different power cables. All =20 occurred while running at low speed for SD (25MHz) on r274416. Here =20 is the latest panic: ssh output: ----------- root@raspberry-pi:~ # time portsnap fetch update Looking up portsnap.FreeBSD.org mirrors... 7 mirrors found. Fetching public key from isc.portsnap.freebsd.org... done. Fetching snapshot tag from isc.portsnap.freebsd.org... done. Fetching snapshot metadata... done. Fetching snapshot generated at Mon Nov 24 17:13:37 MST 2014: a9871e18baf0354c1d0795484a204847f79729af04cbfe100% of 70 MB 740 kBps 01m3= 7s Extracting snapshot... done. Verifying snapshot integrity... done. Fetching snapshot tag from isc.portsnap.freebsd.org... done. Fetching snapshot metadata... done. Updating from Mon Nov 24 17:13:37 MST 2014 to Mon Nov 24 21:03:40 MST 2014. Fetching 4 metadata patches... done. Applying metadata patches... done. Fetching 0 metadata files... done. Fetching 66 patches. (66/66) 100.00% done. done. Applying patches... done. Fetching 20 new ports or files... done. Removing old files and directories... console output: --------------- dev =3D mmcsd0s2a, block =3D 343613, fs =3D /root/crochet/work/_.mount.freeb= sd panic: ffs_blkfree_cg: freeing free frag KDB: enter: panic [ thread pid 8 tid 100056 ] Stopped at $d: ldrb r15, [r15, r15, r15, ror r15]! db> Ian, you mentioned that you thought this looked like a memory =20 corruption similar to the issues reported on Wandboard. I have been =20 reading those threads but I don't fully understand what is the issue. =20 Can you clarify? I also saw some discussion about some new changes =20 currently under testing and planned for release. Are these expected =20 to resolve the memory corruption? What is the root cause and is the =20 problem present in all builds or just recent builds? From owner-freebsd-arm@FreeBSD.ORG Tue Nov 25 21:55:38 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6A4BCB4C for ; Tue, 25 Nov 2014 21:55:38 +0000 (UTC) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::1]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.smtp.rzone.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C91EBD65 for ; Tue, 25 Nov 2014 21:55:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1416952507; l=18245; s=domk; d=ulrich-grey.de; h=Content-Transfer-Encoding:Content-Type:Mime-Version:References: In-Reply-To:Subject:Cc:To:From:Date; bh=mmk4KZdYkJCUchz9XaR6+tNvzlw=; b=f42FSNQ+nq2m+oCxTWLVIqW6AyX8xbjhpSUdNQgfmdyFQfoRLxGoYT8VRoJyY44GAJX mcY0wuVH5tP8Ttu0oUbgBvF/ZoB22LNoPhvIrarYQETqv8xNs8lcW6rtyWGjb7sMQvPiA Ww98qAZ0VSkOnbZoqCCzk8CSb1GwumCZ2C4= X-RZG-AUTH: :OX8Be0W8W+pMC3rDLL/lo2xV/LZTbZkYhOcjg8suic3iYr/B8J9Lzp3TJg4+usv/2wFQ X-RZG-CLASS-ID: mo00 Received: from bbu (p5486A29F.dip0.t-ipconnect.de [84.134.162.159]) by smtp.strato.de (RZmta 35.13 DYNA|AUTH) with ESMTPSA id Q05bf2qAPLsqlgW (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate); Tue, 25 Nov 2014 22:54:52 +0100 (CET) Date: Tue, 25 Nov 2014 22:54:51 +0100 From: Ulrich Grey To: Ian Lepore Subject: Another Test Run with Alternative pmap Implementation Message-Id: <20141125225451.924a5df4bdb4753db273b8c5@ulrich-grey.de> In-Reply-To: <1416840814.1147.380.camel@revolution.hippie.lan> References: <20141113125236.b16cd4e5f0e339eac0494cd4@ulrich-grey.de> <20141115143444.5ad037548e06f289d2532fb7@ulrich-grey.de> <20141119225903.81fbbc7809093a0e6e0de9d5@ulrich-grey.de> <20141120151900.a68c6d8316b96a62cb65d17a@ulrich-grey.de> <20141121115941.54d4e36b103341c3adf7eb36@ulrich-grey.de> <20141124132733.4e96b906f0d1ab69969dddd9@ulrich-grey.de> <1416840814.1147.380.camel@revolution.hippie.lan> Organization: - X-Mailer: Sylpheed 3.3.0 (GTK+ 2.24.22; armv6-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2014 21:55:38 -0000 Hello, I updated the source tree from Svatopluk Kraus and build an Image (crochet, wandboard-quad). The kernel is compiled with ARM_NEW_PMAP: root@quad:/usr/home/gwgpi # uname -a FreeBSD quad 11.0-CURRENT FreeBSD 11.0-CURRENT #0 428e9d2(master)-dirty: Tue Nov 25 09:45:07 UTC 2014 root@quad:/usr/local/DEVEL/obj/usr/local/DEVEL/STREJDA/freebsd/sys/WANDBOARD-QUAD arm root@quad:/usr/home/gwgpi # sysctl vm.pmap. vm.pmap.pv_entry_max: 1745184 vm.pmap.shpgperproc: 200 vm.pmap.nkpt2pg: 32 vm.pmap.sp_enabled: 1 vm.pmap.pte1.demotions: 22 vm.pmap.pte1.mappings: 0 vm.pmap.pte1.p_failures: 122 vm.pmap.pte1.promotions: 38 vm.pmap.pv_entry_count: 12369 vm.pmap.pc_chunk_count: 43 vm.pmap.pc_chunk_allocs: 1981 vm.pmap.pc_chunk_frees: 1938 vm.pmap.pc_chunk_tryfail: 0 vm.pmap.pv_entry_frees: 417470 vm.pmap.pv_entry_allocs: 429839 vm.pmap.pv_entry_spare: 2079 # Then I did: root@quad:/usr/src # make -j20 buildworld # The build hangs here (not for the first time): --- cpp_helpers --- c++ -O -pipe -I/usr/local/DEVEL/STREJDA/freebsd/contrib/atf -Qunused-arguments -Wno-c+ +11-extensions -L/usr/obj/usr/local/DEVEL/STREJDA/freebsd/tmp/usr/lib/private -rpath /usr/lib/private -o cpp_helpers cpp_helpers.o /usr/obj/usr/local/DEVEL/STREJDA/freebsd/lib/atf/libatf-c++/libatf-c+ +.so /usr/obj/usr/local/DEVEL/STREJDA/freebsd/lib/atf/libatf-c/libatf-c.so # I did a break into the debugger and this is the output: KDB: enter: Break to debugger [ thread pid 10 tid 100002 ] Stopped at $d: ldrb r15, [r15, r15, ror r15]! db> show all pcpu Current CPU: 0 cpuid = 0 dynamic pcpu = 0x203fc0 curthread = 0xc6f8d9c0: pid 10 "idle: cpu0" curpcb = 0xf2e62ea8 fpcurthread = 0xc74bc340: pid 528 "ntpd" idlethread = 0xc6f8d9c0: tid 100002 "idle: cpu0" spin locks held: cpuid = 1 dynamic pcpu = 0x1f5f1fc0 curthread = 0xc6f8d680: pid 10 "idle: cpu1" curpcb = 0xf2e65ea8 fpcurthread = 0xc7cb39c0: pid 72591 "top" idlethread = 0xc6f8d680: tid 100003 "idle: cpu1" spin locks held: cpuid = 2 dynamic pcpu = 0x1f5f2fc0 --More-- curthread = 0xc6f8d340: pid 10 "idle: cpu2" --More-- curpcb = 0xf2e68ea8 --More-- fpcurthread = 0xc7cb39c0: pid 72591 "top" --More-- idlethread = 0xc6f8d340: tid 100004 "idle: cpu2" --More-- spin locks held: --More-- --More-- cpuid = 3 --More-- dynamic pcpu = 0x1f5f3fc0 --More-- curthread = 0xc80299c0: pid 92540 "make" --More-- curpcb = 0xfb06bea8 --More-- fpcurthread = 0xc74bc340: pid 528 "ntpd" --More-- idlethread = 0xc6f8d000: tid 100005 "idle: cpu3" --More-- spin locks held: --More-- --More-- ## db> where Tracing pid 10 tid 100002 td 0xc6f8d9c0 db_trace_self() at db_trace_self pc = 0xc23c63d4 lr = 0xc2038b34 (db_stack_trace+0xf4) sp = 0xf2e629a8 fp = 0xf2e629c0 r10 = 0xc258784c db_stack_trace() at db_stack_trace+0xf4 pc = 0xc2038b34 lr = 0xc20384a4 (db_command+0x270) sp = 0xf2e629c8 fp = 0xf2e62a68 r4 = 0x00000000 r5 = 0x00000000 r6 = 0x00000072 db_command() at db_command+0x270 pc = 0xc20384a4 lr = 0xc2038208 (db_command_loop+0x60) sp = 0xf2e62a70 fp = 0xf2e62a80 r4 = 0xc240c830 r5 = 0xc2424f13 r6 = 0xc2587838 r7 = 0xf2e62c50 r8 = 0x00000001 r9 = 0xc24cf8a8 r10 = 0xc2525774 db_command_loop() at db_command_loop+0x60 pc = 0xc2038208 lr = 0xc203ac7c (db_trap+0xd8) sp = 0xf2e62a88 fp = 0xf2e62ba8 --More-- r4 = 0x00000000 r5 = 0xc2587844 --More-- r6 = 0xc2525798 --More-- db_trap() at db_trap+0xd8 --More-- pc = 0xc203ac7c lr = 0xc21a6158 (kdb_trap+0x15c) --More-- sp = 0xf2e62bb0 fp = 0xf2e62bd0 --More-- r4 = 0x00000000 r5 = 0x00000001 --More-- r6 = 0xc2525798 r7 = 0xf2e62c50 --More-- kdb_trap() at kdb_trap+0x15c --More-- pc = 0xc21a6158 lr = 0xc23deb08 (undefinedinstruction+0x2c4) --More-- sp = 0xf2e62bd8 fp = 0xf2e62c48 --More-- r4 = 0x00000000 r5 = 0x00000000 --More-- r6 = 0xc23de794 r7 = 0xe7ffffff --More-- r8 = 0xc6f8d9c0 r9 = 0xc21a5a80 --More-- r10 = 0xf2e62c50 --More-- undefinedinstruction() at undefinedinstruction+0x2c4 --More-- pc = 0xc23deb08 lr = 0xc23c81ac (exception_exit) --More-- sp = 0xf2e62c50 fp = 0xf2e62cb0 --More-- r4 = 0xc707dc00 r5 = 0xc707dc88 --More-- r6 = 0x00000049 r7 = 0x00040000 --More-- r8 = 0x00000001 r9 = 0xc24d4b0c --More-- r10 = 0xc707dc00 --More-- exception_exit() at exception_exit --More-- pc = 0xc23c81ac lr = 0xc21a5a70 (kdb_alt_break_internal+0x174) --More-- sp = 0xf2e62ca0 fp = 0xf2e62cb0 --More-- r0 = 0xc2525784 r1 = 0x00000000 --More-- r2 = 0x00000001 r3 = 0x60000193 --More-- r4 = 0xc707dc00 r5 = 0xc707dc88 --More-- r6 = 0x00000049 r7 = 0x00040000 --More-- r8 = 0x00000001 r9 = 0xc24d4b0c --More-- r10 = 0xc707dc00 r12 = 0x000000c0 --More-- $a() at $a --More-- pc = 0xc21a5a84 lr = 0xc21a58f4 (kdb_alt_break+0x10) --More-- sp = 0xf2e62cb8 fp = 0xf2e62cb8 --More-- r4 = 0xc707dc00 r5 = 0xc707dc88 --More-- r6 = 0x00000049 r7 = 0x00040000 --More-- kdb_alt_break() at kdb_alt_break+0x10 --More-- pc = 0xc21a58f4 lr = 0xc206d558 (uart_intr_rxready+0x88) --More-- sp = 0xf2e62cc0 fp = 0xf2e62cd8 --More-- uart_intr_rxready() at uart_intr_rxready+0x88 --More-- pc = 0xc206d558 lr = 0xc206e0d8 (uart_intr+0x11c) --More-- sp = 0xf2e62ce0 fp = 0xf2e62d20 --More-- r4 = 0x00000000 r5 = 0xf2e62d68 --More-- r6 = 0xc707dd74 --More-- uart_intr() at uart_intr+0x11c --More-- pc = 0xc206e0d8 lr = 0xc213baec (intr_event_handle+0x7c) --More-- sp = 0xf2e62d28 fp = 0xf2e62d48 --More-- r4 = 0xc6e66d00 r5 = 0xf2e62d68 --More-- r6 = 0xc2591dcc r7 = 0xc6f8d9c0 --More-- r8 = 0x00000000 r9 = 0xc241ed30 --More-- r10 = 0xc7071b40 --More-- intr_event_handle() at intr_event_handle+0x7c --More-- pc = 0xc213baec lr = 0xc23c9694 (arm_irq_handler+0x60) --More-- sp = 0xf2e62d50 fp = 0xf2e62d60 --More-- r4 = 0xf2e62d68 r5 = 0x0000003a --More-- r6 = 0xc2591dcc r7 = 0xc25861dc --More-- r8 = 0xc6f8d9c0 r9 = 0xc2523a44 --More-- r10 = 0xc2523a40 --More-- arm_irq_handler() at arm_irq_handler+0x60 --More-- pc = 0xc23c9694 lr = 0xc23c81ac (exception_exit) --More-- sp = 0xf2e62d68 fp = 0xf2e62dc0 --More-- r4 = 0xc6f8d9c0 r5 = 0xc2523a48 --More-- r6 = 0x00000002 r7 = 0xc2523a56 --More-- exception_exit() at exception_exit --More-- pc = 0xc23c81ac lr = 0xc23c9dd0 (cpu_idle+0x8c) --More-- sp = 0xf2e62db8 fp = 0xf2e62dc0 --More-- r0 = 0x00000000 r1 = 0x000000c0 --More-- r2 = 0x600000d3 r3 = 0x60000013 --More-- r4 = 0xc6f8d9c0 r5 = 0xc2523a48 --More-- r6 = 0x00000002 r7 = 0xc2523a56 --More-- r8 = 0xc6f8d9c0 r9 = 0xc2523a44 --More-- r10 = 0xc2523a40 r12 = 0x000000c0 --More-- cpu_idle() at cpu_idle+0xb8 --More-- pc = 0xc23c9dfc lr = 0xc2194dd0 (sched_idletd+0x3c8) --More-- sp = 0xf2e62dc8 fp = 0xf2e62e30 --More-- r4 = 0xc2523a54 --More-- sched_idletd() at sched_idletd+0x3c8 --More-- pc = 0xc2194dd0 lr = 0xc2139270 (fork_exit+0xa0) --More-- sp = 0xf2e62e38 fp = 0xf2e62e50 --More-- r4 = 0xc6f8d9c0 r5 = 0xc6f8a320 --More-- r6 = 0xc2194a08 r7 = 0x00000000 --More-- r8 = 0xf2e62e58 r9 = 0x00000000 --More-- r10 = 0x00000000 --More-- fork_exit() at fork_exit+0xa0 --More-- pc = 0xc2139270 lr = 0xc23c8144 (swi_exit) --More-- sp = 0xf2e62e58 fp = 0x00000000 --More-- r4 = 0xc2194a08 r5 = 0x00000000 --More-- r6 = 0x00000000 r7 = 0x00000000 --More-- r8 = 0x00000000 --More-- swi_exit() at swi_exit --More-- pc = 0xc23c8144 lr = 0xc23c8144 (swi_exit) --More-- sp = 0xf2e62e58 fp = 0x00000000 --More-- db> ## db> ps pid ppid pgrp uid state wmesg wchan cmd 72591 846 72591 0 S+ select 0xc7dc9e24 top 54936 54928 54928 0 S+ ttydcd 0xc707da90 ex 54928 54845 54928 0 S+ wait 0xc7d02c80 sh 54845 92681 92681 0 S+ select 0xc742aae4 make 92681 92591 92681 0 S+ wait 0xc8002320 sh 92591 92577 92577 0 S+ select 0xc73c69e4 make 92577 92540 92577 0 S+ wait 0xc7569960 sh 92540 92539 92539 0 R+ CPU 3 make 92539 622 92539 0 S+ wait 0xc8002000 sh 846 840 846 0 S+ pause 0xc7569068 csh 840 833 840 1001 S+ wait 0xc7a63c80 su 833 832 833 1001 Ss+ pause 0xc7a639c8 csh 832 787 787 1001 S select 0xc7387924 sshd 787 558 787 0 Ss select 0xc713e9e4 sshd 622 621 621 0 S+ select 0xc70749e4 make 621 616 621 0 S+ wait 0xc74b1320 sh 616 608 616 0 S+ select 0xc742c764 make 608 607 608 0 S+ pause 0xc734c6a8 csh 607 1 607 0 Ss+ wait 0xc74b2960 login --More-- 562 1 562 0 Ss nanslp 0xc25177f1 cron --More-- 558 1 558 0 Ss select 0xc7387624 sshd --More-- 528 1 528 0 Ss select 0xc7387764 ntpd --More-- 455 1 455 0 Ss select 0xc7387d24 casperd --More-- 454 1 454 0 Ss select 0xc713eaa4 casperd --More-- 422 1 422 0 Ss select 0xc73c6324 syslogd --More-- 275 1 275 0 Ss select 0xc73c5ee4 devd --More-- 16 0 0 0 DL syncer 0xc2582b0c [syncer] --More-- 15 0 0 0 DL vlruwt 0xc734bc80 [vnlru] --More-- 9 0 0 0 DL (threaded) [bufdaemon] --More-- 100046 D psleep 0xc2582890 [bufdaemon] --More-- 100055 D sdflush 0xc7343a84 [/ worker] --More-- 8 0 0 0 DL pgzero 0xc25859bc [pagezero] --More-- 7 0 0 0 DL psleep 0xc258584c [vmdaemon] --More-- 6 0 0 0 DL psleep 0xc258c9c4 [pagedaemon] --More-- 5 0 0 0 DL jobqueue 0xc7151f00 [mmcsd1: mmc/sd card] --More-- 4 0 0 0 DL jobqueue 0xc7031b80 [mmcsd0: mmc/sd card] --More-- 3 0 0 0 DL waiting_ 0xc2589d0c [sctp_iterator] --More-- 14 0 0 0 DL (threaded) [usb] --More-- 100026 D - 0xc706aca4 [usbus0] --More-- 100027 D - 0xc706acd4 [usbus0] --More-- 100028 D - 0xc706ad04 [usbus0] --More-- 100029 D - 0xc706ad34 [usbus0] --More-- 100031 D - 0xc7145ca4 [usbus1] --More-- 100032 D - 0xc7145cd4 [usbus1] --More-- 100033 D - 0xc7145d04 [usbus1] --More-- 100034 D - 0xc7145d34 [usbus1] --More-- 2 0 0 0 DL (threaded) [cam] --More-- 100021 D - 0xc25060c0 [doneq0] --More-- 100040 D - 0xc25062a8 [scanner] --More-- 13 0 0 0 DL - 0xc2513120 [rand_harvestq] --More-- 12 0 0 0 DL (threaded) [geom] --More-- 100012 D - 0xc2588464 [g_event] --More-- 100013 D - 0xc2588468 [g_up] --More-- 100014 D - 0xc258846c [g_down] --More-- 11 0 0 0 WL (threaded) [intr] --More-- 100006 I [swi3: vm] --More-- 100007 I [swi1: netisr 0] --More-- 100008 I [swi4: clock (0)] --More-- 100009 I [swi4: clock (1)] --More-- 100010 I [swi4: clock (2)] --More-- 100011 I [swi4: clock (3)] --More-- 100016 I [swi6: Giant taskq] --More-- 100018 I [swi5: fast taskq] --More-- 100022 I [swi6: task queue] --More-- 100023 I [swi0: uart] --More-- 100024 I [intr150: ffec0] --More-- 100025 I [intr75: ehci0] --More-- 100030 I [intr72: ehci1] --More-- 100035 I [intr54: sdhci_imx0] --More-- 100036 I [intr56: sdhci_imx1] --More-- 10 0 0 0 RL (threaded) [idle] --More-- 100002 Run CPU 0 [idle: cpu0] --More-- 100003 Run CPU 1 [idle: cpu1] --More-- 100004 Run CPU 2 [idle: cpu2] --More-- 100005 CanRun [idle: cpu3] --More-- 1 0 1 0 SLs wait 0xc6f8a640 [init] --More-- 0 0 0 0 DLs (threaded) [kernel] --More-- 100000 D swapin 0xc2588488 [swapper] --More-- 100017 D - 0xc7031380 [thread taskq] --More-- 100019 D - 0xc7031280 [ffs_trim taskq] --More-- 100020 D - 0xc7031200 [kqueue taskq] --More-- 100037 D - 0xc25166d1 [deadlkres] --More-- 100039 D - 0xc7031180 [CAM taskq] --More-- db> pid ppid pgrp uid state wmesg wchan cmd 72591 846 72591 0 S+ select 0xc7dc9e24 top 54936 54928 54928 0 S+ ttydcd 0xc707da90 ex 54928 54845 54928 0 S+ wait 0xc7d02c80 sh 54845 92681 92681 0 S+ select 0xc742aae4 make 92681 92591 92681 0 S+ wait 0xc8002320 sh 92591 92577 92577 0 S+ select 0xc73c69e4 make 92577 92540 92577 0 S+ wait 0xc7569960 sh 92540 92539 92539 0 R+ CPU 3 make 92539 622 92539 0 S+ wait 0xc8002000 sh 846 840 846 0 S+ pause 0xc7569068 csh 840 833 840 1001 S+ wait 0xc7a63c80 su 833 832 833 1001 Ss+ pause 0xc7a639c8 csh 832 787 787 1001 S select 0xc7387924 sshd 787 558 787 0 Ss select 0xc713e9e4 sshd 622 621 621 0 S+ select 0xc70749e4 make 621 616 621 0 S+ wait 0xc74b1320 sh 616 608 616 0 S+ select 0xc742c764 make 608 607 608 0 S+ pause 0xc734c6a8 csh 607 1 607 0 Ss+ wait 0xc74b2960 login --More-- 562 1 562 0 Ss nanslp 0xc25177f1 cron --More-- 558 1 558 0 Ss select 0xc7387624 sshd --More-- 528 1 528 0 Ss select 0xc7387764 ntpd --More-- 455 1 455 0 Ss select 0xc7387d24 casperd --More-- 454 1 454 0 Ss select 0xc713eaa4 casperd --More-- 422 1 422 0 Ss select 0xc73c6324 syslogd --More-- 275 1 275 0 Ss select 0xc73c5ee4 devd --More-- 16 0 0 0 DL syncer 0xc2582b0c [syncer] --More-- 15 0 0 0 DL vlruwt 0xc734bc80 [vnlru] --More-- 9 0 0 0 DL (threaded) [bufdaemon] --More-- 100046 D psleep 0xc2582890 [bufdaemon] --More-- 100055 D sdflush 0xc7343a84 [/ worker] --More-- 8 0 0 0 DL pgzero 0xc25859bc [pagezero] --More-- 7 0 0 0 DL psleep 0xc258584c [vmdaemon] --More-- 6 0 0 0 DL psleep 0xc258c9c4 [pagedaemon] --More-- 5 0 0 0 DL jobqueue 0xc7151f00 [mmcsd1: mmc/sd card] --More-- 4 0 0 0 DL jobqueue 0xc7031b80 [mmcsd0: mmc/sd card] --More-- 3 0 0 0 DL waiting_ 0xc2589d0c [sctp_iterator] --More-- 14 0 0 0 DL (threaded) [usb] --More-- 100026 D - 0xc706aca4 [usbus0] --More-- 100027 D - 0xc706acd4 [usbus0] --More-- 100028 D - 0xc706ad04 [usbus0] --More-- 100029 D - 0xc706ad34 [usbus0] --More-- 100031 D - 0xc7145ca4 [usbus1] --More-- 100032 D - 0xc7145cd4 [usbus1] --More-- 100033 D - 0xc7145d04 [usbus1] --More-- 100034 D - 0xc7145d34 [usbus1] --More-- 2 0 0 0 DL (threaded) [cam] --More-- 100021 D - 0xc25060c0 [doneq0] --More-- 100040 D - 0xc25062a8 [scanner] --More-- 13 0 0 0 DL - 0xc2513120 [rand_harvestq] --More-- 12 0 0 0 DL (threaded) [geom] --More-- 100012 D - 0xc2588464 [g_event] --More-- 100013 D - 0xc2588468 [g_up] --More-- 100014 D - 0xc258846c [g_down] --More-- 11 0 0 0 WL (threaded) [intr] --More-- 100006 I [swi3: vm] --More-- 100007 I [swi1: netisr 0] --More-- 100008 I [swi4: clock (0)] --More-- 100009 I [swi4: clock (1)] --More-- 100010 I [swi4: clock (2)] --More-- 100011 I [swi4: clock (3)] --More-- 100016 I [swi6: Giant taskq] --More-- 100018 I [swi5: fast taskq] --More-- 100022 I [swi6: task queue] --More-- 100023 I [swi0: uart] --More-- 100024 I [intr150: ffec0] --More-- 100025 I [intr75: ehci0] --More-- 100030 I [intr72: ehci1] --More-- 100035 I [intr54: sdhci_imx0] --More-- 100036 I [intr56: sdhci_imx1] --More-- 10 0 0 0 RL (threaded) [idle] --More-- 100002 Run CPU 0 [idle: cpu0] --More-- 100003 Run CPU 1 [idle: cpu1] --More-- 100004 Run CPU 2 [idle: cpu2] --More-- 100005 CanRun [idle: cpu3] --More-- 1 0 1 0 SLs wait 0xc6f8a640 [init] --More-- 0 0 0 0 DLs (threaded) [kernel] --More-- 100000 D swapin 0xc2588488 [swapper] --More-- 100017 D - 0xc7031380 [thread taskq] --More-- 100019 D - 0xc7031280 [ffs_trim taskq] --More-- 100020 D - 0xc7031200 [kqueue taskq] --More-- 100037 D - 0xc25166d1 [deadlkres] --More-- 100039 D - 0xc7031180 [CAM taskq] --More-- db> ## -- Ulrich ---------------------------------- On Mon, 24 Nov 2014 07:53:34 -0700 Ian Lepore wrote: > On Mon, 2014-11-24 at 13:27 +0100, Ulrich Grey wrote: > > Hello, > > > > as a starting point I have build an image (crochet, wandboard-quad) with > > the source tree from here (751adfd(master)): > > > > https://github.com/strejda/freebsd > > > > Then I build the kernel with new pmap and rebuild the whole systen. > > The system I used for the test run is entirely build on the > > wandboard-quad. > > [...] > > I've also been testing those pmap changes this weekend. The only change > I made was to add options ARM_NEW_PMAP and NKPT2PG=64 to the kernel > config. In particular, I did not change VM_MEMATTR_UNCACHEABLE (so that > in effect I'm also testing the recent busdma changes). > > I've had two wandboard quads doing builds continuously all weekend. I > did the builds that have previously been reported as problems here -- > buildworld -j10, ports libX11, plus a lot of other ports including much > of the full xorg (until it ran into some x86 device drivers and died), > some of libreoffice (it had a problem that wasn't related to crashing or > anything), python, bash, emacs, boost, rsync. > > After all that I just set both boards to continuously doing "rm > -rf /usr/obj/* ; make -j5 buildworld" in a loop, and they're still > running. One is using an SSD drive and the other is using NFS. > > In all that building all weekend the only glitches I've seen are this: > > warning: pmap_remove_pages called with non-current pmap > > that appeared twice on the board using NFS root. > > For anyone else wanting to test, there is currently one conflict when > applying the patches, in busdma_machdep-v6.c, because some of the > changes in the patch have already been applied. Just resolve the > conflict by skipping that file / restoring the original unpatched file. > > This stuff is looking really good. It wouldn't hurt at all if some more > people were testing it, especially on other hardware including rpi and > beaglebone. > > -- Ian > > From owner-freebsd-arm@FreeBSD.ORG Wed Nov 26 10:54:43 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E89A1131; Wed, 26 Nov 2014 10:54:43 +0000 (UTC) Received: from mail-qa0-x22c.google.com (mail-qa0-x22c.google.com [IPv6:2607:f8b0:400d:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 99B2865D; Wed, 26 Nov 2014 10:54:43 +0000 (UTC) Received: by mail-qa0-f44.google.com with SMTP id i13so1735256qae.3 for ; Wed, 26 Nov 2014 02:54:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=eNNrkPW8fbpf0wqxXtjLxhI2wbtZPHFdlrsxQV6p4+4=; b=MOLop+/B9UVrCN3BXxg6mBZxqvWPt5ckUj0lXBhEFR3HFrwYqDmNmvLld628jI0WqO oKRm/PRihEKgGYQBsF95tTHRoL5m/yYsdxWRoMfcECTAFtu31NLzQMTBLQbSV0Oy7A1Q 4IW68gmQskB5zKvU8c9oKQqbPMixpDAQZYTQ9Jbqvah12fpQeYRsyBEe4lZfXkAJvdp6 7gY+ZsI1pT12HM3o4fxIzPgunR7gZSmYKzKp3gP4tn/7TZqIqUCXjGJIpdf5yTmTmwVv EcRSCHzNaC4qJafRjVJmk6d/0sdXL9Bf114S4LwwPugpvnhnb8TOo4g93fkScz1YE3xZ nNNg== MIME-Version: 1.0 X-Received: by 10.224.129.9 with SMTP id m9mr45095722qas.50.1416999282856; Wed, 26 Nov 2014 02:54:42 -0800 (PST) Received: by 10.140.23.242 with HTTP; Wed, 26 Nov 2014 02:54:42 -0800 (PST) In-Reply-To: <20141125225451.924a5df4bdb4753db273b8c5@ulrich-grey.de> References: <20141113125236.b16cd4e5f0e339eac0494cd4@ulrich-grey.de> <20141115143444.5ad037548e06f289d2532fb7@ulrich-grey.de> <20141119225903.81fbbc7809093a0e6e0de9d5@ulrich-grey.de> <20141120151900.a68c6d8316b96a62cb65d17a@ulrich-grey.de> <20141121115941.54d4e36b103341c3adf7eb36@ulrich-grey.de> <20141124132733.4e96b906f0d1ab69969dddd9@ulrich-grey.de> <1416840814.1147.380.camel@revolution.hippie.lan> <20141125225451.924a5df4bdb4753db273b8c5@ulrich-grey.de> Date: Wed, 26 Nov 2014 11:54:42 +0100 Message-ID: Subject: Re: Another Test Run with Alternative pmap Implementation From: Svatopluk Kraus To: Ulrich Grey Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-arm@freebsd.org, Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Nov 2014 10:54:44 -0000 On Tue, Nov 25, 2014 at 10:54 PM, Ulrich Grey wrote: > Hello, > > I updated the source tree from Svatopluk Kraus and build an Image (crochet, > wandboard-quad). The kernel is compiled with ARM_NEW_PMAP: > > root@quad:/usr/home/gwgpi # uname -a > FreeBSD quad 11.0-CURRENT FreeBSD 11.0-CURRENT #0 428e9d2(master)-dirty: > Tue Nov 25 > 09:45:07 UTC 2014 > root@quad:/usr/local/DEVEL/obj/usr/local/DEVEL/STREJDA/freebsd/sys/WANDBOARD-QUAD > arm > > root@quad:/usr/home/gwgpi # sysctl vm.pmap. > vm.pmap.pv_entry_max: 1745184 > vm.pmap.shpgperproc: 200 > vm.pmap.nkpt2pg: 32 > vm.pmap.sp_enabled: 1 > vm.pmap.pte1.demotions: 22 > vm.pmap.pte1.mappings: 0 > vm.pmap.pte1.p_failures: 122 > vm.pmap.pte1.promotions: 38 > vm.pmap.pv_entry_count: 12369 > vm.pmap.pc_chunk_count: 43 > vm.pmap.pc_chunk_allocs: 1981 > vm.pmap.pc_chunk_frees: 1938 > vm.pmap.pc_chunk_tryfail: 0 > vm.pmap.pv_entry_frees: 417470 > vm.pmap.pv_entry_allocs: 429839 > vm.pmap.pv_entry_spare: 2079 > > # > Then I did: > root@quad:/usr/src # make -j20 buildworld > > # > The build hangs here (not for the first time): > > --- cpp_helpers --- > > c++ -O -pipe -I/usr/local/DEVEL/STREJDA/freebsd/contrib/atf > -Qunused-arguments -Wno-c+ > +11-extensions > -L/usr/obj/usr/local/DEVEL/STREJDA/freebsd/tmp/usr/lib/private > -rpath /usr/lib/private -o cpp_helpers > cpp_helpers.o > /usr/obj/usr/local/DEVEL/STREJDA/freebsd/lib/atf/libatf-c++/libatf-c+ > +.so /usr/obj/usr/local/DEVEL/STREJDA/freebsd/lib/atf/libatf-c/libatf-c.so > > # > I did a break into the debugger and this is the output: > [...] > Please tell me: (0) Does system hang or only the build? Can you terminate the build when it hangs by ctrl c? (1) Invariants was on or off? (2) Memory attributes for DMA buffers was VM_MEMATTR_NOCACHE or VM_MEMATTR_SO? (3) How long does the build run before it hangs? (4) Does it really hang on same place? Can you run the test with invariants on if it was off and with memory attributes for DMA buffers VM_MEMATTR_SO if it was VM_MEMATTR_NOCACHE? If it helps, set invariants off and try again. It's always worth to try it with vm.pmap.sp_enabled=0. Considering debug terminal, after you type "show all pcpu", look at output and type "where #pid" for current threads on all cpus except idle ones. For example, in sent debug output, there is only one non idle current thread on cpu #3, so it would be "where 92540". Svatopluk Kraus From owner-freebsd-arm@FreeBSD.ORG Wed Nov 26 11:58:43 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 29749D02; Wed, 26 Nov 2014 11:58:43 +0000 (UTC) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::11]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.smtp.rzone.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 86D08CDC; Wed, 26 Nov 2014 11:58:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1417003098; l=5541; s=domk; d=ulrich-grey.de; h=Content-Transfer-Encoding:Content-Type:Mime-Version:References: In-Reply-To:Subject:Cc:To:From:Date; bh=fUB6fiiVinVvH8Bbrt7UXcMgufs=; b=udcooQbTdDO2r/wbzXwxudl5vB62UUaShphQdA6msSPV75wh9pNHRMKSInkV7xKOaV0 6C7BVceVyCLKUcsJY1cXXPjwQ61vBQgTFN5TVl2tKDP0LdmM3m7ls8SzeJtfqK634ES75 k18w9fMUQ379P9bTebrIocxofl3CAWCXbHs= X-RZG-AUTH: :OX8Be0W8W+pMC3rDLL/lo2xV/LZTbZkYhOcjg8suic3iYr/B8J9Lzp3TJg49scv6otY= X-RZG-CLASS-ID: mo00 Received: from bbu (p54869F28.dip0.t-ipconnect.de [84.134.159.40]) by smtp.strato.de (RZmta 36.1 DYNA|AUTH) with ESMTPSA id t01ca8qAQBw81pd (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate); Wed, 26 Nov 2014 12:58:08 +0100 (CET) Date: Wed, 26 Nov 2014 12:58:06 +0100 From: Ulrich Grey To: Svatopluk Kraus Subject: Re: Another Test Run with Alternative pmap Implementation Message-Id: <20141126125806.78f2df97328e807d12746ae3@ulrich-grey.de> In-Reply-To: References: <20141113125236.b16cd4e5f0e339eac0494cd4@ulrich-grey.de> <20141115143444.5ad037548e06f289d2532fb7@ulrich-grey.de> <20141119225903.81fbbc7809093a0e6e0de9d5@ulrich-grey.de> <20141120151900.a68c6d8316b96a62cb65d17a@ulrich-grey.de> <20141121115941.54d4e36b103341c3adf7eb36@ulrich-grey.de> <20141124132733.4e96b906f0d1ab69969dddd9@ulrich-grey.de> <1416840814.1147.380.camel@revolution.hippie.lan> <20141125225451.924a5df4bdb4753db273b8c5@ulrich-grey.de> Organization: - X-Mailer: Sylpheed 3.3.0 (GTK+ 2.24.22; armv6-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org, Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Nov 2014 11:58:43 -0000 Hello, yesterday I have made two testruns with your updated source tree. In the FIRST run no debug options were activated. Only ARM_NEW_PMAP was added to the kernel configuration. The _build_ (make -j20) hung after about 6 to 7 hours here (see my email from 2014-11-22, the same situation, I think): --- cpp_helpers --- c++ -O -pipe -I/usr/local/DEVEL/STREJDA/freebsd/contrib/atf -Qunused-arguments -Wno-c+ +11-extensions -L/usr/obj/usr/local/DEVEL/STREJDA/freebsd/tmp/usr/lib/private -rpath /usr/lib/private -o cpp_helpers cpp_helpers.o /usr/obj/usr/local/DEVEL/STREJDA/freebsd/lib/atf/libatf-c++/libatf-c+ +.so /usr/obj/usr/local/DEVEL/STREJDA/freebsd/lib/atf/libatf-c/libatf-c.so I tried a second run with make -DNO_CLEAN buildworld, but that hung here: ===> share/termcap (all) TERM=dumb TERMCAP=dumb: ex - /usr/local/DEVEL/STREJDA/freebsd/share/termcap/termcap.src < /usr/local/DEVEL/STREJDA/freebsd/share/termcap/reorder ## To prepare the SECOND run, I build a new kernel with debug options and ARM_NEW_PMAP: # Debugging support. Always need this: options KDB # Enable kernel debugger support. # For minimum debugger support use KDB_TRACE, for interactive use DDB. options KDB_TRACE # Print a stack trace for a panic. options DDB # Support DDB. # For full debugger support use this instead: #options GDB # Support remote GDB. # Other debugging options... makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols options ALT_BREAK_TO_DEBUGGER # Use to enter debugger. options DEBUG options DEADLKRES # Enable the deadlock resolver options INVARIANTS # Enable calls of extra sanity checking options INVARIANT_SUPPORT # Extra sanity checks of internal structures, # required by INVARIANTS options WITNESS # Enable # checks to detect deadlocks and cycles options DIAGNOSTIC # I build a new kernel, checked all filesystems twice, deleted /usr/obj/* and cleaned the source tree twice. Then I did: root@quad:/usr/src # make -j20 buildworld the _build_ hung after ca. 8 - 9 hours. top -P on another terminal works, the system works furthermore. I have waited some time, then breaked to debugger. --- cpp_helpers --- c++ -O -pipe -I/usr/local/DEVEL/STREJDA/freebsd/contrib/atf -Qunused-arguments -Wno-c+ +11-extensions -L/usr/obj/usr/local/DEVEL/STREJDA/freebsd/tmp/usr/lib/private -rpath /usr/lib/private -o cpp_helpers cpp_helpers.o /usr/obj/usr/local/DEVEL/STREJDA/freebsd/lib/atf/libatf-c++/libatf-c+ +.so /usr/obj/usr/local/DEVEL/STREJDA/freebsd/lib/atf/libatf-c/libatf-c.so It is the same place, I think. ## root@quad:/usr/src/sys/arm/include # from file vm.h: #define VM_MEMATTR_UNCACHEABLE VM_MEMATTR_NOCACHE /*name is misused by DMA */ regards Ulrich ---------------------------------- On Wed, 26 Nov 2014 11:54:42 +0100 Svatopluk Kraus wrote: > On Tue, Nov 25, 2014 at 10:54 PM, Ulrich Grey wrote: > > > Hello, > > > > I updated the source tree from Svatopluk Kraus and build an Image (crochet, > > wandboard-quad). The kernel is compiled with ARM_NEW_PMAP: > > > > root@quad:/usr/home/gwgpi # uname -a > > FreeBSD quad 11.0-CURRENT FreeBSD 11.0-CURRENT #0 428e9d2(master)-dirty: > > Tue Nov 25 > > 09:45:07 UTC 2014 > > root@quad:/usr/local/DEVEL/obj/usr/local/DEVEL/STREJDA/freebsd/sys/WANDBOARD-QUAD > > arm > > > > root@quad:/usr/home/gwgpi # sysctl vm.pmap. > > vm.pmap.pv_entry_max: 1745184 > > vm.pmap.shpgperproc: 200 > > vm.pmap.nkpt2pg: 32 > > vm.pmap.sp_enabled: 1 > > vm.pmap.pte1.demotions: 22 > > vm.pmap.pte1.mappings: 0 > > vm.pmap.pte1.p_failures: 122 > > vm.pmap.pte1.promotions: 38 > > vm.pmap.pv_entry_count: 12369 > > vm.pmap.pc_chunk_count: 43 > > vm.pmap.pc_chunk_allocs: 1981 > > vm.pmap.pc_chunk_frees: 1938 > > vm.pmap.pc_chunk_tryfail: 0 > > vm.pmap.pv_entry_frees: 417470 > > vm.pmap.pv_entry_allocs: 429839 > > vm.pmap.pv_entry_spare: 2079 > > > > # > > Then I did: > > root@quad:/usr/src # make -j20 buildworld > > > > # > > The build hangs here (not for the first time): > > > > --- cpp_helpers --- > > > > c++ -O -pipe -I/usr/local/DEVEL/STREJDA/freebsd/contrib/atf > > -Qunused-arguments -Wno-c+ > > +11-extensions > > -L/usr/obj/usr/local/DEVEL/STREJDA/freebsd/tmp/usr/lib/private > > -rpath /usr/lib/private -o cpp_helpers > > cpp_helpers.o > > /usr/obj/usr/local/DEVEL/STREJDA/freebsd/lib/atf/libatf-c++/libatf-c+ > > +.so /usr/obj/usr/local/DEVEL/STREJDA/freebsd/lib/atf/libatf-c/libatf-c.so > > > > # > > I did a break into the debugger and this is the output: > > [...] > > > > Please tell me: > (0) Does system hang or only the build? Can you terminate the build when it > hangs by ctrl c? > (1) Invariants was on or off? > (2) Memory attributes for DMA buffers was VM_MEMATTR_NOCACHE or > VM_MEMATTR_SO? > (3) How long does the build run before it hangs? > (4) Does it really hang on same place? > > Can you run the test with invariants on if it was off and with memory > attributes for DMA buffers VM_MEMATTR_SO if it was VM_MEMATTR_NOCACHE? If > it helps, set invariants off and try again. > > It's always worth to try it with vm.pmap.sp_enabled=0. > > Considering debug terminal, after you type "show all pcpu", look at output > and type "where #pid" for current threads on all cpus except idle ones. For > example, in sent debug output, there is only one non idle current thread on > cpu #3, so it would be "where 92540". > > Svatopluk Kraus From owner-freebsd-arm@FreeBSD.ORG Wed Nov 26 22:19:06 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2F28538A; Wed, 26 Nov 2014 22:19:06 +0000 (UTC) Received: from mailgate-02.zdv.uni-mainz.de (mailgate-02.zdv.Uni-Mainz.DE [IPv6:2001:4c80:40:62d:203:ffff:fe5d:b2f6]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "IronPort Appliance Demo Certificate", Issuer "IronPort Appliance Demo Certificate" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 39BB0B80; Wed, 26 Nov 2014 22:19:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uni-mainz.de; i=@uni-mainz.de; q=dns/txt; s=ironport; t=1417040345; x=1448576345; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=CuoyYomOh9fhyTUXzBgbjQeHnmzYyxQJp5LfdjkgoGU=; b=lwQ2MrPPQkIinarCiUnBnrwwaum/6fZhcnlvsbPgdV0QV+EZZmUrlEBc JWf+nTLh9NwavdnGl0DqSSDflvxT1KW7j19PZyLWoo4URNAyE5/mHK1gV agajLklkFfmGlsarieUIdyVinAjQuskB6lL+KtYd4QhWRxxIBBpwQGOPz I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArcEALlQdlQKXgZY/2dsb2JhbABbgmOBTATOZwKBJgEBAQEBfYQDAQEEeRACAQgOODIlAgQBDQUIiDgB0lcBAQEBAQUBAQEBAQEBARqQeweETQWLaIRRlk+PFYN8d4FIgQIBAQE X-IPAS-Result: ArcEALlQdlQKXgZY/2dsb2JhbABbgmOBTATOZwKBJgEBAQEBfYQDAQEEeRACAQgOODIlAgQBDQUIiDgB0lcBAQEBAQUBAQEBAQEBARqQeweETQWLaIRRlk+PFYN8d4FIgQIBAQE Received: from e14hub-02.zdv.uni-mainz.de ([10.94.6.88]) by mailgate-02.zdv.uni-mainz.de with ESMTP/TLS/AES128-SHA; 26 Nov 2014 23:19:02 +0100 Received: from e15be-02.zdv.Uni-Mainz.DE (2001:4c80:40:606:92e2:baff:fe19:8fb0) by E14HUB-02.zdv.Uni-Mainz.DE (2001:4c80:40:606:21d:d8ff:feb7:1c60) with Microsoft SMTP Server (TLS) id 14.3.210.2; Wed, 26 Nov 2014 23:18:59 +0100 Received: from e15be-01.zdv.Uni-Mainz.DE (2001:4c80:40:606:92e2:baff:fe19:9090) by e15be-02.zdv.Uni-Mainz.DE (2001:4c80:40:606:92e2:baff:fe19:8fb0) with Microsoft SMTP Server (TLS) id 15.0.1044.22; Wed, 26 Nov 2014 23:18:59 +0100 Received: from e15be-01.zdv.Uni-Mainz.DE ([fe80::92e2:baff:fe19:9090]) by e15be-01.zdv.Uni-Mainz.DE ([fe80::92e2:baff:fe19:9090%15]) with mapi id 15.00.1044.021; Wed, 26 Nov 2014 23:18:59 +0100 From: =?iso-8859-1?Q?Wei=DF=2C__Dr=2E_J=FCrgen?= To: 'Ulrich Grey' , Svatopluk Kraus Subject: RE: Another Test Run with Alternative pmap Implementation Thread-Topic: Another Test Run with Alternative pmap Implementation Thread-Index: AQHQB+IsE+qgHr3iw0yZSzSGyGR5M5xvzE8AgAIICYCAANnjAIAAEbcAgAC51CA= Date: Wed, 26 Nov 2014 22:18:58 +0000 Message-ID: <519fde5db60e4fc594956a600c6cad4e@e15be-01.zdv.Uni-Mainz.DE> References: <20141113125236.b16cd4e5f0e339eac0494cd4@ulrich-grey.de> <20141115143444.5ad037548e06f289d2532fb7@ulrich-grey.de> <20141119225903.81fbbc7809093a0e6e0de9d5@ulrich-grey.de> <20141120151900.a68c6d8316b96a62cb65d17a@ulrich-grey.de> <20141121115941.54d4e36b103341c3adf7eb36@ulrich-grey.de> <20141124132733.4e96b906f0d1ab69969dddd9@ulrich-grey.de> <1416840814.1147.380.camel@revolution.hippie.lan> <20141125225451.924a5df4bdb4753db273b8c5@ulrich-grey.de> <20141126125806.78f2df97328e807d12746ae3@ulrich-grey.de> In-Reply-To: <20141126125806.78f2df97328e807d12746ae3@ulrich-grey.de> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [134.93.178.81] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "freebsd-arm@freebsd.org" , Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Nov 2014 22:19:06 -0000 I made a testrun with the updated source tree and the patches for=20 the jetson tk1 platform. With=20 options ARM_NEW_PMAP options DEBUG options DIAGNOSTIC options INVARIANTS # Enable calls of extra sanity chec= king options INVARIANT_SUPPORT # Extra sanity checks of internal s= tructures, required by INVARIAN and no special sysctl settings. A make -j6 buildworld finishes successfully after 2h15m. There is=20 one kernel message kernel: warning: pmap_remove_pages called with non-current pmap /usr/src and /usr/obj over nfs, /tmp on tmpfs Regards Juergen Juergen Weiss |Universitaet Mainz, Zentrum fuer Datenverarbeitung, weiss@uni-mainz.de |55099 Mainz, Tel: +49(6131)39-26361, FAX: +49(6131)39-2= 6407 From owner-freebsd-arm@FreeBSD.ORG Thu Nov 27 10:36:25 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8360526D for ; Thu, 27 Nov 2014 10:36:25 +0000 (UTC) Received: from eu1sys200aog102.obsmtp.com (eu1sys200aog102.obsmtp.com [207.126.144.113]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9B01AD87 for ; Thu, 27 Nov 2014 10:36:23 +0000 (UTC) Received: from mail-wg0-f44.google.com ([74.125.82.44]) (using TLSv1) by eu1sys200aob102.postini.com ([207.126.147.11]) with SMTP ID DSNKVHb+ipcBhy9Og91wv1ZmtmjFogTYoEfx@postini.com; Thu, 27 Nov 2014 10:36:24 UTC Received: by mail-wg0-f44.google.com with SMTP id b13so6072171wgh.17 for ; Thu, 27 Nov 2014 02:35:54 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:message-id:to:subject:reply-to; bh=kbJEPbC7tPYyoK/12BJKDM5VNhHzYfPGJiFouSDxpeE=; b=UBrTvTKMudwwOx+LQ1UlAuCx3sruPDayaWWKh6OkZSIWDxb3FZ8WJlcdSBnXnjHldG 2YwDoRxbv/J345suv9u4QQGc8QD39Gpmb3lrh8/wj3Ui296mqZBNFCLR3f2ZQQv1UTh3 o+lBhjao9nVekFT6FORvO0M/KQpz+qYBP/KsiU+T6CCTsja08L/USuFaz5V5f8lAvtmu 59nN41oTKpwU/xInWP8jkDTQdAvko2w+UUVbwTI1GOZcWL8nmyHgU0w2knn6490h2/k9 KhlxrEGxYpk1OiSBtYsmxEQ0AINfTL9wONyG1IyaimtypH52+658bs7RVLtkUx2p3dCv xuWw== X-Gm-Message-State: ALoCoQkM4FD4BOZyzcszRyM4OJEZgUV2s9evoeDjq2KMXq6m0Xt+hKZJ2iKhZOQnIBaFbbymM3IjbXwaa0Zyz2jxnnXA9xHQHHuicDJf7NZXiRm/h3PFDuWH76EoE8rxbjWgLBc127VgqyiDRFHGjl5aT/HT04TPsQ== X-Received: by 10.194.156.201 with SMTP id wg9mr57627296wjb.59.1417084554487; Thu, 27 Nov 2014 02:35:54 -0800 (PST) X-Received: by 10.194.156.201 with SMTP id wg9mr57627270wjb.59.1417084554307; Thu, 27 Nov 2014 02:35:54 -0800 (PST) Received: from mech-as221.men.bris.ac.uk (mech-as221.men.bris.ac.uk. [137.222.187.221]) by mx.google.com with ESMTPSA id mc10sm24636089wic.24.2014.11.27.02.35.53 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 27 Nov 2014 02:35:53 -0800 (PST) Date: Thu, 27 Nov 2014 02:35:53 -0800 (PST) X-Google-Original-Date: Thu, 27 Nov 2014 10:35:52 GMT Received: from mech-as221.men.bris.ac.uk (localhost [127.0.0.1]) by mech-as221.men.bris.ac.uk (8.14.9/8.14.9) with ESMTP id sARAZqcT092572 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 27 Nov 2014 10:35:52 GMT (envelope-from mexas@mech-as221.men.bris.ac.uk) Received: (from mexas@localhost) by mech-as221.men.bris.ac.uk (8.14.9/8.14.9/Submit) id sARAZqn5092571 for freebsd-arm@freebsd.org; Thu, 27 Nov 2014 10:35:52 GMT (envelope-from mexas) From: Anton Shterenlikht Message-Id: <201411271035.sARAZqn5092571@mech-as221.men.bris.ac.uk> To: freebsd-arm@freebsd.org Subject: built xorg-server, what next? Reply-To: mexas@bris.ac.uk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Nov 2014 10:36:25 -0000 Hi I managed to build xorg-server-1.12.4_9,1 on RPI-B 10.1-RELEASE, no build failures along the way, just a couple of panics. I then followed: http://blog.cochard.me/2013/03/xorg-for-freebsd-on-raspberry-pi.html ( Is this guide still valid?) and built xf86-video-scfb-0.0.4_1 On X -configure I got: # X -configure X.Org X Server 1.12.4 Release Date: 2012-08-27 X Protocol Version 11, Revision 0 Build Operating System: FreeBSD 10.1-RELEASE arm Current Operating System: FreeBSD b827eb88ec3f.anet.bris.ac.uk 10.1-RELEASE FreeBSD 10.1-RELEASE #0 r274401: Wed Nov 12 04:42:19 UTC 2014 root@releng1.nyi.freebsd.org:/usr/obj/arm.armv6/usr/src/sys/RPI-B arm Build Date: 17 November 2014 08:39:11PM Current version of pixman: 0.32.6 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/Xorg.0.log", Time: Tue Nov 18 13:02:41 2014 List of video drivers: scfb scfb trace: probe start No devices to configure. Configuration failed. Server terminated with error (2). Closing log file. Is scfb the wrong driver for this board? Please help Thanks Anton From owner-freebsd-arm@FreeBSD.ORG Thu Nov 27 12:39:52 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 20FF0298; Thu, 27 Nov 2014 12:39:52 +0000 (UTC) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::11]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.smtp.rzone.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7DA0CDA7; Thu, 27 Nov 2014 12:39:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1417091962; l=5450; s=domk; d=ulrich-grey.de; h=Content-Transfer-Encoding:Content-Type:Mime-Version:References: In-Reply-To:Subject:Cc:To:From:Date; bh=zZxly5sBLanyveRKh/XxeBDiWYA=; b=yDY/PetZ4BW1l0Kre8RibcepnleGVXb17sMugUigvTRth0kcyB42I5KiSAneh4AfPsY 7P+i3LGGaipyPmfLcmHCOtDNLr0GoQ4rNmHyXS7fLDg03fZJvL72drzQ+N13JCEBRxT/6 EuKuG1wHCH38m5eC6srh7LguqWDgF/7VtkQ= X-RZG-AUTH: :OX8Be0W8W+pMC3rDLL/lo2xV/LZTbZkYhOcjg8suic3iYr/B8J9Lzp3TJg49uMv/iwf9 X-RZG-CLASS-ID: mo00 Received: from bbu (p548696C0.dip0.t-ipconnect.de [84.134.150.192]) by smtp.strato.de (RZmta 36.1 DYNA|AUTH) with ESMTPSA id I04a4aqARCdAKtw (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate); Thu, 27 Nov 2014 13:39:10 +0100 (CET) Date: Thu, 27 Nov 2014 13:39:08 +0100 From: Ulrich Grey To: Svatopluk Kraus Subject: Re: Another Test Run with Alternative pmap Implementation Message-Id: <20141127133908.532e7963aade036f67d49a1d@ulrich-grey.de> In-Reply-To: References: <20141113125236.b16cd4e5f0e339eac0494cd4@ulrich-grey.de> <20141115143444.5ad037548e06f289d2532fb7@ulrich-grey.de> <20141119225903.81fbbc7809093a0e6e0de9d5@ulrich-grey.de> <20141120151900.a68c6d8316b96a62cb65d17a@ulrich-grey.de> <20141121115941.54d4e36b103341c3adf7eb36@ulrich-grey.de> <20141124132733.4e96b906f0d1ab69969dddd9@ulrich-grey.de> <1416840814.1147.380.camel@revolution.hippie.lan> <20141125225451.924a5df4bdb4753db273b8c5@ulrich-grey.de> Organization: - X-Mailer: Sylpheed 3.3.0 (GTK+ 2.24.22; armv6-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org, Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Nov 2014 12:39:52 -0000 I have built a new kernel with debugging options and ARM_NEW_PMAP. I have modified the file /src/sys/arm/include/vm.h: /* #define VM_MEMATTR_UNCACHEABLE VM_MEMATTR_NOCACHE XXname is misused by DMA */ #define VM_MEMATTR_UNCACHEABLE VM_MEMATTR_SO /*name is misused by DMA */ my crashtest make -j20 buildworld hung after about 8 - 9 hours at the usual place: --- cpp_helpers --- c++ -O -pipe -I/usr/local/DEVEL/STREJDA/freebsd/contrib/atf -Qunused-arguments -Wno-c+ +11-extensions -L/usr/obj/usr/local/DEVEL/STREJDA/freebsd/tmp/usr/lib/private -rpath /usr/lib/private -o cpp_helpers cpp_helpers.o /usr/obj/usr/local/DEVEL/STREJDA/freebsd/lib/atf/libatf-c++/libatf-c+ +.so /usr/obj/usr/local/DEVEL/STREJDA/freebsd/lib/atf/libatf-c/libatf-c.so Something went wrong and I lost connection to the serial console, so I could not break to debugger. Here some explanation about my "test system". It was not set up to test something. I only wanted to build some ports which depend on qt4-* (lyx, texworks which depens on texlive). The device has 2 SD-Cards. On /dev/mmcsd1s2a lives root, on /dev/mmcsd0 lives /usr/local. I use USB-Drives, as far as I know there is no SATA-Driver yet for FreeBSD. On /dev/da1 are the portstree and the working directories for compiling ports and the source tree and the obj tree for compiling the system (via symbolic links from /usr). On /dev/da0s1b I have a swap partition (4 GB). As far as I have watched, the system uses no swap, the RAM seems to be big enough. If "top" shows high load (20 or more) there is enough free RAM. It is for precaution only because with my Raspberry I had some crashes during compilation due to tight RAM. Here is an example from the last test: last pid: 65435; load averages: 19.90, 19.41, 19.60 up 0+06:16:00 23:09:00 102 processes: 19 running, 83 sleeping CPU 0: 97.3% user, 0.0% nice, 2.3% system, 0.4% interrupt, 0.0% idle CPU 1: 98.4% user, 0.0% nice, 1.6% system, 0.0% interrupt, 0.0% idle CPU 2: 92.6% user, 0.0% nice, 7.4% system, 0.0% interrupt, 0.0% idle CPU 3: 23.8% user, 0.0% nice, 76.2% system, 0.0% interrupt, 0.0% idle Mem: 499M Active, 849M Inact, 176M Wired, 5824K Cache, 112M Buf, 470M Free Swap: 4095M Total, 4095M Free As a terminal (serial console) I use the Raspberry and a TV Set (HDMI-Interface). root@quad:/usr/src/sys/arm/include # mount /dev/mmcsd1s2a on / (ufs, local, noatime, journaled soft-updates, nfsv4acls) devfs on /dev (devfs, local) /dev/mmcsd1s1 on /boot/msdos (msdosfs, local, noatime) /dev/mmcsd0 on /usr/local (ufs, local, noatime) /dev/da1 on /usr/local/DEVEL (ufs, local) /tmp is not mounted on tmpfs Regards Ulrich ---------------------------------- On Wed, 26 Nov 2014 11:54:42 +0100 Svatopluk Kraus wrote: > On Tue, Nov 25, 2014 at 10:54 PM, Ulrich Grey wrote: > > > Hello, > > > > I updated the source tree from Svatopluk Kraus and build an Image (crochet, > > wandboard-quad). The kernel is compiled with ARM_NEW_PMAP: > > > > root@quad:/usr/home/gwgpi # uname -a > > FreeBSD quad 11.0-CURRENT FreeBSD 11.0-CURRENT #0 428e9d2(master)-dirty: > > Tue Nov 25 > > 09:45:07 UTC 2014 > > root@quad:/usr/local/DEVEL/obj/usr/local/DEVEL/STREJDA/freebsd/sys/WANDBOARD-QUAD > > arm > > > > root@quad:/usr/home/gwgpi # sysctl vm.pmap. > > vm.pmap.pv_entry_max: 1745184 > > vm.pmap.shpgperproc: 200 > > vm.pmap.nkpt2pg: 32 > > vm.pmap.sp_enabled: 1 > > vm.pmap.pte1.demotions: 22 > > vm.pmap.pte1.mappings: 0 > > vm.pmap.pte1.p_failures: 122 > > vm.pmap.pte1.promotions: 38 > > vm.pmap.pv_entry_count: 12369 > > vm.pmap.pc_chunk_count: 43 > > vm.pmap.pc_chunk_allocs: 1981 > > vm.pmap.pc_chunk_frees: 1938 > > vm.pmap.pc_chunk_tryfail: 0 > > vm.pmap.pv_entry_frees: 417470 > > vm.pmap.pv_entry_allocs: 429839 > > vm.pmap.pv_entry_spare: 2079 > > > > # > > Then I did: > > root@quad:/usr/src # make -j20 buildworld > > > > # > > The build hangs here (not for the first time): > > > > --- cpp_helpers --- > > > > c++ -O -pipe -I/usr/local/DEVEL/STREJDA/freebsd/contrib/atf > > -Qunused-arguments -Wno-c+ > > +11-extensions > > -L/usr/obj/usr/local/DEVEL/STREJDA/freebsd/tmp/usr/lib/private > > -rpath /usr/lib/private -o cpp_helpers > > cpp_helpers.o > > /usr/obj/usr/local/DEVEL/STREJDA/freebsd/lib/atf/libatf-c++/libatf-c+ > > +.so /usr/obj/usr/local/DEVEL/STREJDA/freebsd/lib/atf/libatf-c/libatf-c.so > > > > # > > I did a break into the debugger and this is the output: > > [...] > > > > Please tell me: > (0) Does system hang or only the build? Can you terminate the build when it > hangs by ctrl c? > (1) Invariants was on or off? > (2) Memory attributes for DMA buffers was VM_MEMATTR_NOCACHE or > VM_MEMATTR_SO? > (3) How long does the build run before it hangs? > (4) Does it really hang on same place? > > Can you run the test with invariants on if it was off and with memory > attributes for DMA buffers VM_MEMATTR_SO if it was VM_MEMATTR_NOCACHE? If > it helps, set invariants off and try again. > > It's always worth to try it with vm.pmap.sp_enabled=0. > > Considering debug terminal, after you type "show all pcpu", look at output > and type "where #pid" for current threads on all cpus except idle ones. For > example, in sent debug output, there is only one non idle current thread on > cpu #3, so it would be "where 92540". > > Svatopluk Kraus From owner-freebsd-arm@FreeBSD.ORG Thu Nov 27 13:32:00 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 31335D6C for ; Thu, 27 Nov 2014 13:32:00 +0000 (UTC) Received: from frontend1.warwick.net (webmail.warwick.net [204.255.24.102]) by mx1.freebsd.org (Postfix) with SMTP id DD3493BA for ; Thu, 27 Nov 2014 13:31:59 +0000 (UTC) Received: (qmail 29370 invoked from network); 27 Nov 2014 13:25:16 -0000 Received: from 70.44.113.83.res-cmts.sefg.ptd.net (HELO 70.44.113.83.res-cmts.sefg.ptd.net) (egunther@warwick.net@70.44.113.83) by frontend1.warwick.net with SMTP (d3613704-7638-11e4-a1a4-001e0b616b8e); Thu, 27 Nov 2014 08:25:16 -0500 Message-ID: <1417094728.2530.1.camel@warwick.net> Subject: Raspberry Pi composite video problem From: Eric Gunther To: freebsd-arm@freebsd.org Date: Thu, 27 Nov 2014 08:25:28 -0500 Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.12.7 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-MagicMail-UUID: d3613704-7638-11e4-a1a4-001e0b616b8e X-MagicMail-Authenticated: egunther@warwick.net X-MagicMail-SourceIP: 70.44.113.83 X-MagicMail-EnvelopeFrom: X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Nov 2014 13:32:00 -0000 Hi, I posted to this list earlier this month and did not receive any input. I have an old tv with composite input and outputs, I thought this would be ideal for a low cost monitor for the RPi. I have been experiencing a problem in which the text is drawn past the bottom,top and sides. I have looked around quite a bit but cannot resolve the issue. Changes to the overscan_left, overscan_right, etc. in /boot/config.txt do not change the behavior. framebuffer_height and framebuffer_width settings do seem to change the behavior. The tv itself has controls for the picture and v-hold but no horizontal control. The rear of the tv has two set-screws which are labeled focus and screen (screen controls the brightness). I have seen mention of copying the firmware over, but have also seen that it seems that this is unnecessary. Unfortunately I have encountered issues with cards that I plug back into this machine after writing the image, so I cannot copy the firmware over. I would use putty or ssh, to log in and put that there but I have run into trouble there as well. I have enabled sshd, and set the hostname although I cannot seem to find the RPi on the network while using Ethernet cable (Cat 5e)... This is not surprising because I am novice with networking. I have also tried telnet, although I saw elsewhere on this list that one has to enable it. I have not found the place to do that, I looked in loader.conf and rc.conf. SO, I cannot report dmesg, netstat or other output because I cannot ssh into the machine. I have the intention of running a simple boa webserver serving a commercial portfolio website. Thanks, - From owner-freebsd-arm@FreeBSD.ORG Thu Nov 27 17:10:04 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B4256F75 for ; Thu, 27 Nov 2014 17:10:04 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7B261EB3 for ; Thu, 27 Nov 2014 17:10:04 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Xu2Zn-000AwI-UM; Thu, 27 Nov 2014 17:09:56 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id sARH9rgw001271; Thu, 27 Nov 2014 10:09:54 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19TZBagc4ESrO90ytooCnuJ X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: RE: Another Test Run with Alternative pmap Implementation From: Ian Lepore To: =?ISO-8859-1?Q?Wei=DF=2C?= "Dr." =?ISO-8859-1?Q?J=FCrgen?= In-Reply-To: <519fde5db60e4fc594956a600c6cad4e@e15be-01.zdv.Uni-Mainz.DE> References: <20141113125236.b16cd4e5f0e339eac0494cd4@ulrich-grey.de> <20141115143444.5ad037548e06f289d2532fb7@ulrich-grey.de> <20141119225903.81fbbc7809093a0e6e0de9d5@ulrich-grey.de> <20141120151900.a68c6d8316b96a62cb65d17a@ulrich-grey.de> <20141121115941.54d4e36b103341c3adf7eb36@ulrich-grey.de> <20141124132733.4e96b906f0d1ab69969dddd9@ulrich-grey.de> <1416840814.1147.380.camel@revolution.hippie.lan> <20141125225451.924a5df4bdb4753db273b8c5@ulrich-grey.de> <20141126125806.78f2df97328e807d12746ae3@ulrich-grey.de> <519fde5db60e4fc594956a600c6cad4e@e15be-01.zdv.Uni-Mainz.DE> Content-Type: text/plain; charset="ISO-8859-1" Date: Thu, 27 Nov 2014 10:09:53 -0700 Message-ID: <1417108193.1055.2.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ilsoft.org id sARH9rgw001271 Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Nov 2014 17:10:04 -0000 On Wed, 2014-11-26 at 22:18 +0000, Wei=DF, Dr. J=FCrgen wrote: > I made a testrun with the updated source tree and the patches for=20 > the jetson tk1 platform. With=20 >=20 > options ARM_NEW_PMAP > options DEBUG > options DIAGNOSTIC > options INVARIANTS # Enable calls of extra sanity = checking > options INVARIANT_SUPPORT # Extra sanity checks of intern= al structures, required by INVARIAN >=20 > and no special sysctl settings. >=20 > A make -j6 buildworld finishes successfully after 2h15m. There is=20 > one kernel message > kernel: warning: pmap_remove_pages called with non-current pmap >=20 > /usr/src and /usr/obj over nfs, /tmp on tmpfs >=20 > Regards That's similar to my results. I changed to -j20 to see if that would recreate the problems that Ulrich is seeing, but buildworld runs fine for me, in about 2 hours. I've never seen the non-current pmap warning on the system that uses a usb ssd drive as root, but I've seen it with nfs root. BTW, the DIAGNOSTIC option adds a LOT of performance overhead to an arm system without adding a lot of value. I usually leave it off, sometimes turn it on when I encounter a problem to see if it generates more info (usually it doesn't). -- Ian From owner-freebsd-arm@FreeBSD.ORG Thu Nov 27 18:26:29 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B958BAAD; Thu, 27 Nov 2014 18:26:29 +0000 (UTC) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "raven.bwct.de", Issuer "BWCT" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B4B4B80; Thu, 27 Nov 2014 18:26:28 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id sARIPm07096309 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 27 Nov 2014 19:26:03 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by mail.cicely.de (8.14.5/8.14.4) with ESMTP id sARIPXnq005178 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 Nov 2014 19:25:33 +0100 (CET) (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 sARIPXhC055949; Thu, 27 Nov 2014 19:25:33 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id sARIPXrB055948; Thu, 27 Nov 2014 19:25:33 +0100 (CET) (envelope-from ticso) Date: Thu, 27 Nov 2014 19:25:33 +0100 From: Bernd Walter To: Ian Lepore Subject: Re: Another Test Run with Alternative pmap Implementation Message-ID: <20141127182533.GC55348@cicely7.cicely.de> Reply-To: ticso@cicely.de References: <20141120151900.a68c6d8316b96a62cb65d17a@ulrich-grey.de> <20141121115941.54d4e36b103341c3adf7eb36@ulrich-grey.de> <20141124132733.4e96b906f0d1ab69969dddd9@ulrich-grey.de> <1416840814.1147.380.camel@revolution.hippie.lan> <20141125225451.924a5df4bdb4753db273b8c5@ulrich-grey.de> <20141126125806.78f2df97328e807d12746ae3@ulrich-grey.de> <519fde5db60e4fc594956a600c6cad4e@e15be-01.zdv.Uni-Mainz.DE> <1417108193.1055.2.camel@revolution.hippie.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1417108193.1055.2.camel@revolution.hippie.lan> 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=unavailable version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Nov 2014 18:26:29 -0000 On Thu, Nov 27, 2014 at 10:09:53AM -0700, Ian Lepore wrote: > On Wed, 2014-11-26 at 22:18 +0000, Weiß, Dr. Jürgen wrote: > > I made a testrun with the updated source tree and the patches for > > the jetson tk1 platform. With > > > > options ARM_NEW_PMAP > > options DEBUG > > options DIAGNOSTIC > > options INVARIANTS # Enable calls of extra sanity checking > > options INVARIANT_SUPPORT # Extra sanity checks of internal structures, required by INVARIAN > > > > and no special sysctl settings. > > > > A make -j6 buildworld finishes successfully after 2h15m. There is > > one kernel message > > kernel: warning: pmap_remove_pages called with non-current pmap > > > > /usr/src and /usr/obj over nfs, /tmp on tmpfs > > > > Regards > > That's similar to my results. I changed to -j20 to see if that would > recreate the problems that Ulrich is seeing, but buildworld runs fine > for me, in about 2 hours. I've never seen the non-current pmap warning > on the system that uses a usb ssd drive as root, but I've seen it with > nfs root. Probably USB related - he wrote that he is using an USB memory stick. > BTW, the DIAGNOSTIC option adds a LOT of performance overhead to an arm > system without adding a lot of value. I usually leave it off, sometimes > turn it on when I encounter a problem to see if it generates more info > (usually it doesn't). > > -- Ian > > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@FreeBSD.ORG Thu Nov 27 19:48:33 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 77DAD937; Thu, 27 Nov 2014 19:48:33 +0000 (UTC) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::2]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.smtp.rzone.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D1BC2369; Thu, 27 Nov 2014 19:48:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1417117687; l=4421; s=domk; d=ulrich-grey.de; h=Content-Transfer-Encoding:Content-Type:Mime-Version:References: In-Reply-To:Subject:Cc:To:From:Date; bh=2SXWRvdQv4I2Hn17K1AL2tZDXfA=; b=V/QBpLe5mq2uHdNaCSNdoVOQICjsSZbKewfmLwGUgtV7T0hNPGSAySBwOXowSlWs0nz RKqe6exPnA9jQUqpq3EPZV06ZkSdEShk1MKDWxIT4OmoeLBbeHnyLdr82eGeb1bqT6RXb eAOfcivhTnwnkqszRRm4sdSHnzf7bcFCTBA= X-RZG-AUTH: :OX8Be0W8W+pMC3rDLL/lo2xV/LZTbZkYhOcjg8suic3iYr/B8J9Lzp3TJg49uMv/iwf9 X-RZG-CLASS-ID: mo00 Received: from bbu (p548696C0.dip0.t-ipconnect.de [84.134.150.192]) by smtp.strato.de (RZmta 36.2 DYNA|AUTH) with ESMTPSA id j02188qARJm62xP (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate); Thu, 27 Nov 2014 20:48:06 +0100 (CET) Date: Thu, 27 Nov 2014 20:48:05 +0100 From: Ulrich Grey To: Ulrich Grey Subject: Re: Another Test Run with Alternative pmap Implementation Message-Id: <20141127204805.5c2aa62c957fa1984717b592@ulrich-grey.de> In-Reply-To: <20141127133908.532e7963aade036f67d49a1d@ulrich-grey.de> References: <20141113125236.b16cd4e5f0e339eac0494cd4@ulrich-grey.de> <20141115143444.5ad037548e06f289d2532fb7@ulrich-grey.de> <20141119225903.81fbbc7809093a0e6e0de9d5@ulrich-grey.de> <20141120151900.a68c6d8316b96a62cb65d17a@ulrich-grey.de> <20141121115941.54d4e36b103341c3adf7eb36@ulrich-grey.de> <20141124132733.4e96b906f0d1ab69969dddd9@ulrich-grey.de> <1416840814.1147.380.camel@revolution.hippie.lan> <20141125225451.924a5df4bdb4753db273b8c5@ulrich-grey.de> <20141127133908.532e7963aade036f67d49a1d@ulrich-grey.de> Organization: - X-Mailer: Sylpheed 3.3.0 (GTK+ 2.24.22; armv6-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org, Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Nov 2014 19:48:33 -0000 The USB-Drives I use are USB-Harddrives, connected by an active USB-Hub. Root mount waiting for: usbus1 usbus0 uhub0: 1 port with 1 removable, self powered uhub1: 1 port with 1 removable, self powered ugen1.2: at usbus1 uhub2: on usbus1 Root mount waiting for: usbus1 uhub2: 4 ports with 3 removable, self powered Root mount waiting for: usbus1 ugen1.3: at usbus1 umass0: on usbus1 da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 da0: Fixed Direct Access SCSI-0 device da0: Serial Number 100 da0: 40.000MB/s transfers da0: 57231MB (117210240 512 byte sectors: 255H 63S/T 7296C) da0: quirks=0x2 ugen1.4: at usbus1 uhub3: on usbus1 uhub3: 4 ports with 4 removable, self powered Root mount waiting for: usbus1 Root mount waiting for: usbus1 ugen1.5: at usbus1 umass1: on usbus1 Trying to mount root from ufs:/dev/mmcsd1s2a [rw,noatime]... da1 at umass-sim1 bus 1 scbus1 target 0 lun 0 da1: Fixed Direct Access SCSI-4 device da1: Serial Number 2HB50SN0 da1: 40.000MB/s transfers da1:w a1r5n2i6n2g7:M Bn o( 3t1i2m5e8-1o8f0-8d a5y1 2c lboyctke rseegcitsotresr:e d2,5 5sHy s6t3eSm/ Tt i1m9e4 5w7iCl)l ndoat1 :b eq usiertk sa=c0cxu2r wrote: > I have built a new kernel with debugging options and ARM_NEW_PMAP. > I have modified the file /src/sys/arm/include/vm.h: > > /* #define VM_MEMATTR_UNCACHEABLE VM_MEMATTR_NOCACHE XXname is misused by DMA */ > #define VM_MEMATTR_UNCACHEABLE VM_MEMATTR_SO /*name is misused by DMA */ > > my crashtest make -j20 buildworld hung after about 8 - 9 hours at the usual place: > > --- cpp_helpers --- > > c++ -O -pipe -I/usr/local/DEVEL/STREJDA/freebsd/contrib/atf -Qunused-arguments -Wno-c > + +11-extensions -L/usr/obj/usr/local/DEVEL/STREJDA/freebsd/tmp/usr/lib/private > -rpath /usr/lib/private -o cpp_helpers > cpp_helpers.o /usr/obj/usr/local/DEVEL/STREJDA/freebsd/lib/atf/libatf-c++/libatf-c+ > +.so /usr/obj/usr/local/DEVEL/STREJDA/freebsd/lib/atf/libatf-c/libatf-c.so > > Something went wrong and I lost connection to the serial console, so I could not break > to debugger. > > Here some explanation about my "test system". It was not set up to test something. I > only wanted to build some ports which depend on qt4-* (lyx, texworks which depens on > texlive). > > The device has 2 SD-Cards. > On /dev/mmcsd1s2a lives root, > on /dev/mmcsd0 lives /usr/local. > > I use USB-Drives, as far as I know there is no SATA-Driver yet for FreeBSD. > > On /dev/da1 are the portstree and the working directories for compiling ports and the > source tree and the obj tree for compiling the system (via symbolic links from /usr). > > On /dev/da0s1b I have a swap partition (4 GB). As far as I have watched, the system uses > no swap, the RAM seems to be big enough. If "top" shows high load (20 or more) there is > enough free RAM. It is for precaution only because with my Raspberry I had some crashes > during compilation due to tight RAM. Here is an example from the last test: > > last pid: 65435; load averages: 19.90, 19.41, 19.60 up 0+06:16:00 23:09:00 > 102 processes: 19 running, 83 sleeping > CPU 0: 97.3% user, 0.0% nice, 2.3% system, 0.4% interrupt, 0.0% idle > CPU 1: 98.4% user, 0.0% nice, 1.6% system, 0.0% interrupt, 0.0% idle > CPU 2: 92.6% user, 0.0% nice, 7.4% system, 0.0% interrupt, 0.0% idle > CPU 3: 23.8% user, 0.0% nice, 76.2% system, 0.0% interrupt, 0.0% idle > Mem: 499M Active, 849M Inact, 176M Wired, 5824K Cache, 112M Buf, 470M Free > Swap: 4095M Total, 4095M Free > > As a terminal (serial console) I use the Raspberry and a TV Set (HDMI-Interface). > > root@quad:/usr/src/sys/arm/include # mount > /dev/mmcsd1s2a on / (ufs, local, noatime, journaled soft-updates, nfsv4acls) > devfs on /dev (devfs, local) > /dev/mmcsd1s1 on /boot/msdos (msdosfs, local, noatime) > /dev/mmcsd0 on /usr/local (ufs, local, noatime) > /dev/da1 on /usr/local/DEVEL (ufs, local) > > /tmp is not mounted on tmpfs > > Regards > > Ulrich From owner-freebsd-arm@FreeBSD.ORG Thu Nov 27 22:43:16 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0D427BF1; Thu, 27 Nov 2014 22:43:16 +0000 (UTC) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::4]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.smtp.rzone.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4042C92D; Thu, 27 Nov 2014 22:43:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1417128166; l=18901; s=domk; d=ulrich-grey.de; h=Content-Transfer-Encoding:Content-Type:Mime-Version:References: In-Reply-To:Subject:Cc:To:From:Date; bh=3NUi0HteCn4c9AZps9qbUHXdzg4=; b=SsX+Pkjy7l30TRHYRFVZ0pW09NbkeCc6XYLKR9UCW2Fs0PmJT8Q3OgSfQeKtcbTJP6d UB4eU+0Roh2o5z4aNGQZmwvA2RQmfxjiqOmzwRFFD9pCCOWdjlZpwaTqdQjFX6oi1b1cF Cpva7AhFZMdm5MUbZVVBgOUTAyxCto3f8R0= X-RZG-AUTH: :OX8Be0W8W+pMC3rDLL/lo2xV/LZTbZkYhOcjg8suic3iYr/B8J9Lzp3TJg49uMv/iwf9 X-RZG-CLASS-ID: mo00 Received: from bbu (p548696C0.dip0.t-ipconnect.de [84.134.150.192]) by smtp.strato.de (RZmta 36.2 DYNA|AUTH) with ESMTPSA id h010b6qARMge3vT (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate); Thu, 27 Nov 2014 23:42:40 +0100 (CET) Date: Thu, 27 Nov 2014 23:42:39 +0100 From: Ulrich Grey To: Svatopluk Kraus Subject: Re: Another Test Run with Alternative pmap Implementation Message-Id: <20141127234239.e2c40a8fb99ba41f9ec3a7e7@ulrich-grey.de> In-Reply-To: References: <20141113125236.b16cd4e5f0e339eac0494cd4@ulrich-grey.de> <20141115143444.5ad037548e06f289d2532fb7@ulrich-grey.de> <20141119225903.81fbbc7809093a0e6e0de9d5@ulrich-grey.de> <20141120151900.a68c6d8316b96a62cb65d17a@ulrich-grey.de> <20141121115941.54d4e36b103341c3adf7eb36@ulrich-grey.de> <20141124132733.4e96b906f0d1ab69969dddd9@ulrich-grey.de> <1416840814.1147.380.camel@revolution.hippie.lan> <20141125225451.924a5df4bdb4753db273b8c5@ulrich-grey.de> Organization: - X-Mailer: Sylpheed 3.3.0 (GTK+ 2.24.22; armv6-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org, Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Nov 2014 22:43:16 -0000 hello, on advice from Svatopluk Kraus I additionally compiled these debugging options into the kernel: options KTR options KTR_MASK=KTR_ALL options KTR_ENTRIES=65536 I did my crashtest. The system crashes after some hours, I could not do anything on another terminal. cc -fpic -DPIC -O -pipe -I/usr/local/DEVEL/STREJDA/freebsd/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi -I/usr/local/DEVEL/STREJDA/freebsd/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi/krb5 -I/usr/local/DEVEL/STREJDA/freebsd/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi/gssapi -I/usr/local/DEVEL/STREJDA/freebsd/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/krb5 -I/usr/local/DEVEL/STREJDA/freebsd/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/asn1 -I/usr/local/DEVEL/STREJDA/freebsd/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/usr/local/DEVEL/STREJDA/freebsd/kerberos5/lib/libgssapi_krb5/../../include -std=gnu99 -Qunused-arguments -c /usr/local/DEVEL/STREJDA/freebsd/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi/krb5/inquire_cred_by_oid.c -o inquire_cred_by_oid.So mmcsd1: Error indicated: 1 Timeout sdhci_immmxc1-sslot0:d 1G:ot dEata rinterrruopt r0 xi0n0d0i0c0a0t10,e db:u t1 tThiemreeo uits no active command. sdhci_imx1-slot0: ============== REGISTER DUMP ============== sdhci_imx1-slot0: Sys addr: 0x00000000 | Version: 0x00000002 sdhci_imx1-slot0: Blk size: 0x00000200 | Blk cnt: 0x00000040 sdhci_imx1-slot0: Argument: 0x001dffc0 | Trn mode: 0x00000026 sdhci_imx1-slot0: Present: 0x00fd0000 | Host ctl: 0x00000003 sdhci_imx1-slot0: Power: 0x0000000d | Blk gap: 0x00000080 sdhci_imx1-slot0: Wake-up: 0x00000000 | Clock: 0x00000207 sdhci_imx1-slot0: Timeout: 0x0000000d | Int stat: 0x00000000 sdhci_imx1-slot0: Int enab: 0x017f00fb | Sig enab: 0x017f00fb sdhci_imx1-slot0: AC12 err: 0x00000000 | Slot int: 0x00000000 sdhci_imx1-slot0: Caps: 0x0377c800 | Max curr: 0x80000026 sdhci_imx1-slot0: =========================================== g_vfs_done():mmcsd1s2a[WRITE(offset=945684480, length=32768)]error = 5 g_vfs_done():mmcsd1s2a[WRITE(offset=945717248, length=32768)]error = 5 sdhci_imx1-slot0: Got data interrupt 0x00000010, but there is no active command. sdhci_imx1-slot0: ============== REGISTER DUMP ============== sdhci_imx1-slot0: Sys addr: 0x00000000 | Version: 0x00000002 sdhci_imx1-slot0: Blk size: 0x00000200 | Blk cnt: m m0cxs0d010:0 0E0r0r8o r sidnhdciic_aitmexd1:- s1l oTti0m:e oAurtg u ment: 0x0030e9f8 | Trn mode: 0x00000026 sdhci_imx1-slot0: Present: 0x00fd0000 | Host ctl: 0x00000003 sdhci_imx1-slot0: Power: 0x0000000d | Blk gap: 0x00000080 sdhci_imx1-slot0: Wake-up: 0x00000000 | Clock: 0x00000207 sdhci_imx1-slot0: Timeout: 0x0000000d | Int stat: 0x00000000 sdhci_imx1-slot0: Int enab: 0x017f00fb | Sig enab: 0x017f00fb sdhci_imx1-slot0: AC12 err: 0x00000000 | Slot int: 0x00000000 sdhci_imx1-slot0: Caps: 0x0377c800 | Max curr: 0x80000026 sdhci_imx1-slot0: =========================================== g_vfs_done():mmcsd1s2a[WRITE(offset=1580396544, length=4096)]error = 5 sdhci_imx1-slot0: Got data interrupt 0x00000010, but there is no active command. sdhci_imx1-slot0: ============== REGISTER DUMP ============== sdhci_imx1-slot0: Sys addr: 0x00000000 | Version: 0x00000002 sdhci_imx1-slot0: Blk size: 0x00000200 | Blk cnt: 0x00000008 sdhci_imx1-slot0: Argument: 0x0030e9f8 | Trn mode: 0x00000026 sdhci_imx1-slot0: Present: 0x00fd0000 | Host ctl: 0x00000003 sdhci_imx1-slot0: Power: 0x0000000d | Blk gap: 0x00000080 sdhci_imx1-slot0: Wake-up: 0x00000000 | Clock: 0x00000207 sdhci_imx1-slot0: Timeout: 0x0000000d | Int stat: 0x00000000 sdhci_imx1-slot0: Int enab: 0x017f00fb | Sig enab: 0x017f00fb sdhci_imx1-slot0: AC12 err: 0x00000000 | Slot int: 0x00000000 sdhci_imx1-slot0: Caps: 0x0377c800 | Max curr: 0x80000026 sdhci_imx1-slot0: =========================================== mmcsd1: Error indicated: 1 Timeout g_vfs_done():mmcsd1s2a[WRITE(offset=1580396544, length=4096)]error = 5 sdhcmim_cismdx11:- sElrorto0r: iGnodti cdaattead :i n1t eTrirmuepotu t0 x 00000010, but there is no active command. sdhci_imx1-slot0: ============== REGISTEpanic: initiate_write_inodeblock_ufs2: already started cpuid = 1 KDB: stack backtrace: db_trace_self() at db_trace_self pc = 0xc23d5b18 lr = 0xc203abb0 (db_trace_self_wrapper+0x30) sp = 0xfb0447a8 fp = 0xfb0448c0 r10 = 0xc82ed000 db_trace_self_wrapper() at db_trace_self_wrapper+0x30 pc = 0xc203abb0 lr = 0xc21ab500 (kdb_backtrace+0x38) sp = 0xfb0448c8 fp = 0xfb0448d0 r4 = 0xc253d7f4 r5 = 0x00000001 r6 = 0xc2460f8a r7 = 0xc252e478 kdb_backtrace() at kdb_backtrace+0x38 pc = 0xc21ab500 lr = 0xc216dd68 (vpanic+0x114) sp = 0xfb0448d8 fp = 0xfb0448f8 r4 = 0x00000100 vpanic() at vpanic+0x114 pc = 0xc216dd68 lr = 0xc216ddfc (kproc_shutdown) sp = 0xfb044900 fp = 0xfb044904 r4 = 0xc77fe700 r5 = 0xe778c000 r6 = 0x00820901 r7 = 0xa0020020 r8 = 0xfb044948 r9 = 0xc80cf900 r10 = 0xe1bb6af0 kproc_shutdown() at kproc_shutdown pc = 0xc216ddfc lr = 0xa0020020 (-0x5ffdffe0) sp = 0xfb04490c fp = 0xfb044978 r4 = 0xc216ddfc r5 = 0xfb04490c Unable to unwind into user mode KDB: enter: panic [ thread pid 47412 tid 100206 ] Stopped at $d: ldrb r15, [r15, r15, ror r15]! db> show all pcpu Current CPU: 1 cpuid = 0 dynamic pcpu = 0x1ea7c0 curthread = 0xc74ba370: pid 11 "intr56: sdhci_imx1" curpcb = 0xc6a32ea8 fpcurthread = 0xc8ff46e0: pid 47377 "sh" idlethread = 0xc730da50: tid 100002 "idle: cpu0" spin locks held: cpuid = 1 dynamic pcpu = 0x1f5d87c0 curthread = 0xc82ed000: pid 47412 "sh" curpcb = 0xfb044ea8 fpcurthread = 0xc7844370: pid 422 "syslogd" idlethread = 0xc730d6e0: tid 100003 "idle: cpu1" spin locks held: cpuid = 2 dynamic pcpu = 0x1f5d97c0 --More-- curthread = 0xc78f0370: pid 47411 "tblgen" curpcb = 0xfab4fea8 fpcurthread = 0xc82ed000: pid 47412 "sh" idlethread = 0xc730d370: tid 100004 "idle: cpu2" spin locks held: cpuid = 3 dynamic pcpu = 0x1f5da7c0 curthread = 0xc76b5370: pid 5 "mmcsd1: mmc/sd card" curpcb = 0xc6a45ea8 fpcurthread = 0xc7844370: pid 422 "syslogd" idlethread = 0xc730d000: tid 100005 "idle: cpu3" spin locks held: db> where 11 Tracing pid 11 tid 100006 td 0xc730ca50 uart_sab82532_class() at 0 pc = 0x00000000 lr = 0xc23ed380 (fork_trampoline) sp = 0xf2e6ee58 fp = 0x00000000 db> where 47377 Tracing pid 47377 tid 100342 td 0xc8ff46e0 cpu_switch() at cpu_switch+0x18 pc = 0xc23ed174 lr = 0xc2197774 (sched_switch+0x44c) sp = 0xfb4a6608 fp = 0xfb4a6638 Unwind failure (no registers changed) db> where 47412 Tracing pid 47412 tid 100206 td 0xc82ed000 db_trace_self() at db_trace_self pc = 0xc23d5b18 lr = 0xc2038b34 (db_stack_trace+0xf4) sp = 0xfb0445d0 fp = 0xfb0445e8 r10 = 0xc259f8cc db_stack_trace() at db_stack_trace+0xf4 pc = 0xc2038b34 lr = 0xc20384a4 (db_command+0x270) sp = 0xfb0445f0 fp = 0xfb044690 r4 = 0x00000000 r5 = 0x00000000 r6 = 0x00000072 db_command() at db_command+0x270 pc = 0xc20384a4 lr = 0xc2038208 (db_command_loop+0x60) sp = 0xfb044698 fp = 0xfb0446a8 r4 = 0xc241ebff r5 = 0xc24384c8 r6 = 0xc259f8b8 r7 = 0xfb044878 r8 = 0x00000000 r9 = 0xc24e8e38 r10 = 0xc253d7f4 db_command_loop() at db_command_loop+0x60 pc = 0xc2038208 lr = 0xc203ace4 (db_trap+0xd8) sp = 0xfb0446b0 fp = 0xfb0447d0 --More-- r4 = 0x00000000 r5 = 0xc259f8c4 r6 = 0xc253d818 db_trap() at db_trap+0xd8 pc = 0xc203ace4 lr = 0xc21abb38 (kdb_trap+0x15c) sp = 0xfb0447d8 fp = 0xfb0447f8 r4 = 0x00000000 r5 = 0x00000001 r6 = 0xc253d818 r7 = 0xfb044878 kdb_trap() at kdb_trap+0x15c pc = 0xc21abb38 lr = 0xc23eebc4 (undefinedinstruction+0x2c4) sp = 0xfb044800 fp = 0xfb044870 r4 = 0x00000000 r5 = 0x00000000 r6 = 0xc23ee850 r7 = 0xe7ffffff r8 = 0xc82ed000 r9 = 0xc21ab2a4 r10 = 0xfb044878 undefinedinstruction() at undefinedinstruction+0x2c4 pc = 0xc23eebc4 lr = 0xc23d78f0 (exception_exit) sp = 0xfb044878 fp = 0xfb0448d0 r4 = 0xc243851d r5 = 0x00000001 r6 = 0xc2460f8a r7 = 0xc252e478 r8 = 0xfb04490c r9 = 0xc25aefa4 --More-- r10 = 0xc82ed000 exception_exit() at exception_exit pc = 0xc23d78f0 lr = 0xc21ab298 (kdb_enter+0x40) sp = 0xfb0448c8 fp = 0xfb0448d0 r0 = 0xc253d804 r1 = 0x00000000 r2 = 0xc243d424 r3 = 0x000000aa r4 = 0xc243851d r5 = 0x00000001 r6 = 0xc2460f8a r7 = 0xc252e478 r8 = 0xfb04490c r9 = 0xc25aefa4 r10 = 0xc82ed000 r12 = 0x00000000 $a() at $a pc = 0xc21ab2a8 lr = 0xc216dd84 (vpanic+0x130) sp = 0xfb0448d8 fp = 0xfb0448f8 r4 = 0x00000100 vpanic() at vpanic+0x130 pc = 0xc216dd84 lr = 0xc216ddfc (kproc_shutdown) sp = 0xfb044900 fp = 0xfb044904 r4 = 0xc77fe700 r5 = 0xe778c000 r6 = 0x00820901 r7 = 0xa0020020 r8 = 0xfb044948 r9 = 0xc80cf900 --More-- r10 = 0xe1bb6af0 kproc_shutdown() at kproc_shutdown pc = 0xc216ddfc lr = 0xa0020020 (-0x5ffdffe0) sp = 0xfb04490c fp = 0xfb044978 r4 = 0xc216ddfc r5 = 0xfb04490c Unable to unwind into user mode db> where 422 Tracing pid 422 tid 100063 td 0xc7844370 cpu_switch() at cpu_switch+0x18 pc = 0xc23ed174 lr = 0xc2197774 (sched_switch+0x44c) sp = 0xfa902998 fp = 0xfa9029c8 Unwind failure (no registers changed) db> where 47411 Tracing pid 47411 tid 100075 td 0xc78f0370 savectx() at savectx+0x14 pc = 0xc23ed368 lr = 0xc23db518 ($a+0xe0) sp = 0xfab4fdb0 fp = 0xfab4fdf0 Unwind failure (no registers changed) db> where 5 Tracing pid 5 tid 100042 td 0xc76b5370 savectx() at savectx+0x14 pc = 0xc23ed368 lr = 0xc23db518 ($a+0xe0) sp = 0xc6a45b40 fp = 0xc6a45b80 Unwind failure (no registers changed) db> where Tracing pid 47412 tid 100206 td 0xc82ed000 db_trace_self() at db_trace_self pc = 0xc23d5b18 lr = 0xc2038b34 (db_stack_trace+0xf4) sp = 0xfb0445d0 fp = 0xfb0445e8 r10 = 0xc259f8cc db_stack_trace() at db_stack_trace+0xf4 pc = 0xc2038b34 lr = 0xc20384a4 (db_command+0x270) sp = 0xfb0445f0 fp = 0xfb044690 r4 = 0x00000000 r5 = 0x00000000 r6 = 0x00000072 db_command() at db_command+0x270 pc = 0xc20384a4 lr = 0xc2038208 (db_command_loop+0x60) sp = 0xfb044698 fp = 0xfb0446a8 r4 = 0xc241ebff r5 = 0xc24384c8 r6 = 0xc259f8b8 r7 = 0xfb044878 r8 = 0x00000000 r9 = 0xc24e8e38 r10 = 0xc253d7f4 db_command_loop() at db_command_loop+0x60 pc = 0xc2038208 lr = 0xc203ace4 (db_trap+0xd8) sp = 0xfb0446b0 fp = 0xfb0447d0 --More-- r4 = 0x00000000 r5 = 0xc259f8c4 r6 = 0xc253d818 db_trap() at db_trap+0xd8 pc = 0xc203ace4 lr = 0xc21abb38 (kdb_trap+0x15c) sp = 0xfb0447d8 fp = 0xfb0447f8 r4 = 0x00000000 r5 = 0x00000001 r6 = 0xc253d818 r7 = 0xfb044878 kdb_trap() at kdb_trap+0x15c pc = 0xc21abb38 lr = 0xc23eebc4 (undefinedinstruction+0x2c4) sp = 0xfb044800 fp = 0xfb044870 r4 = 0x00000000 r5 = 0x00000000 r6 = 0xc23ee850 r7 = 0xe7ffffff r8 = 0xc82ed000 r9 = 0xc21ab2a4 r10 = 0xfb044878 undefinedinstruction() at undefinedinstruction+0x2c4 pc = 0xc23eebc4 lr = 0xc23d78f0 (exception_exit) sp = 0xfb044878 fp = 0xfb0448d0 r4 = 0xc243851d r5 = 0x00000001 r6 = 0xc2460f8a r7 = 0xc252e478 r8 = 0xfb04490c r9 = 0xc25aefa4 --More-- r10 = 0xc82ed000 exception_exit() at exception_exit pc = 0xc23d78f0 lr = 0xc21ab298 (kdb_enter+0x40) sp = 0xfb0448c8 fp = 0xfb0448d0 r0 = 0xc253d804 r1 = 0x00000000 r2 = 0xc243d424 r3 = 0x000000aa r4 = 0xc243851d r5 = 0x00000001 r6 = 0xc2460f8a r7 = 0xc252e478 r8 = 0xfb04490c r9 = 0xc25aefa4 r10 = 0xc82ed000 r12 = 0x00000000 $a() at $a pc = 0xc21ab2a8 lr = 0xc216dd84 (vpanic+0x130) sp = 0xfb0448d8 fp = 0xfb0448f8 r4 = 0x00000100 vpanic() at vpanic+0x130 pc = 0xc216dd84 lr = 0xc216ddfc (kproc_shutdown) sp = 0xfb044900 fp = 0xfb044904 r4 = 0xc77fe700 r5 = 0xe778c000 r6 = 0x00820901 r7 = 0xa0020020 r8 = 0xfb044948 r9 = 0xc80cf900 --More-- r10 = 0xe1bb6af0 kproc_shutdown() at kproc_shutdown pc = 0xc216ddfc lr = 0xa0020020 (-0x5ffdffe0) sp = 0xfb04490c fp = 0xfb044978 r4 = 0xc216ddfc r5 = 0xfb04490c Unable to unwind into user mode db> ps pid ppid pgrp uid state wmesg wchan cmd 47515 47513 47512 0 R+ cc 47514 47503 47502 0 R+ cc 47513 47512 47512 0 S+ wait 0xc76cb640 cc 47512 45553 47512 0 S+ wait 0xc7d37640 sh 47511 47508 47506 0 R+ cc 47510 47507 47496 0 D+ biord 0xe1bc1830 cc 47509 47505 47504 0 R+ cc 47508 47506 47506 0 S+ wait 0xc78e3640 cc 47507 47501 47496 0 S+ wait 0xc78e3000 cc 47506 45553 47506 0 S+ wait 0xc8007000 sh 47505 47504 47504 0 S+ wait 0xc834e320 cc 47504 45553 47504 0 S+ wait 0xc834e000 sh 47503 47502 47502 0 S+ wait 0xc783ac80 cc 47502 45553 47502 0 S+ wait 0xc783a960 sh 47501 47496 47496 0 S+ wait 0xc8007960 sh 47500 47499 47498 0 R+ cc 47499 47498 47498 0 S+ wait 0xc7d37960 cc 47498 45553 47498 0 S+ wait 0xc8007320 sh 47496 47165 47496 0 S+ wait 0xc8007640 sh --More-- 47492 47491 47490 0 D+ ufs 0xc7ca0db4 cc 47491 47490 47490 0 S+ wait 0xc7d37000 cc 47490 46307 47490 0 S+ wait 0xc76cc320 sh 47485 47366 47363 0 DL+ vnread 0xe1b0b7c0 cc 47453 47452 47451 0 D+ ufs 0xc7ca0db4 cc 47452 47451 47451 0 S+ wait 0xc83e7640 cc 47451 46307 47451 0 S+ wait 0xc82ec640 sh 47428 47427 47427 0 R+ tblgen 47427 47393 47427 0 S+ wait 0xc83e7c80 sh 47412 47393 47412 0 REL+ CPU 1 sh 47411 47410 47410 0 R+ CPU 2 tblgen 47410 47393 47410 0 S+ wait 0xc82fd000 sh 47405 47393 47405 0 RE+ sh 47393 47391 47391 0 S+ select 0xc7756564 make 47391 41911 47391 0 S+ wait 0xc82eb960 sh 47377 47179 47377 0 DE+ getblk 0xe1b2ce40 sh 47366 47365 47363 0 S+ wait 0xc83e5000 cc 47365 47363 47363 0 S+ wait 0xc8f05000 sh 47363 46965 47363 0 S+ wait 0xc8932960 sh 47298 47296 47296 0 D+ ufs 0xc7ca0db4 make --More-- 47296 41911 47296 0 S+ wait 0xc7d36320 sh 47209 47206 47206 0 D+ ufs 0xc7ca0db4 make 47206 41911 47206 0 S+ wait 0xc7febc80 sh 47186 47185 47185 0 D+ ufs 0xc7ca0db4 make 47185 41911 47185 0 S+ wait 0xc7d37c80 sh 47179 47176 47176 0 D+ ufs 0xc7ca0db4 make 47176 41911 47176 0 S+ wait 0xc7f9f000 sh 47165 47164 47164 0 S+ select 0xc8422aa4 make 47164 41911 47164 0 S+ wait 0xc82ebc80 sh 46965 46953 46953 0 S+ select 0xc8501b24 make 46953 41911 46953 0 S+ wait 0xc78e2000 sh 46307 42746 42746 0 D+ ufs 0xc7ca0db4 make 45553 45537 45537 0 R+ make 45537 45518 45537 0 S+ wait 0xc8f00640 sh 45518 36706 36706 0 S+ select 0xc77357a4 make 42746 42715 42746 0 S+ wait 0xc7917640 sh 42715 36704 36704 0 S+ select 0xc7754e24 make 41911 41907 41907 0 D+ ufs 0xc7ca0db4 make 41907 39473 41907 0 S+ wait 0xc8934960 sh 39473 36707 36707 0 S+ select 0xc80c5f24 make --More-- 36707 36691 36707 0 S+ wait 0xc78e3960 sh 36706 36691 36706 0 S+ wait 0xc8008320 sh 36704 36691 36704 0 S+ wait 0xc7fe9960 sh 36691 98664 98664 0 S+ select 0xc80c54e4 make 31862 31845 31862 0 S+ ttyin 0xcadcc270 csh 31845 31803 31845 1001 S+ wait 0xc834ec80 su 31803 31745 31803 1001 Ss+ pause 0xc7fdace8 csh 31745 31700 31700 1001 S select 0xc7c837a4 sshd 31700 558 31700 0 Ss select 0xc80c65e4 sshd 98664 98651 98664 0 S+ wait 0xc8932000 sh 98651 98650 98650 0 S+ select 0xc8421b24 make 98650 642 98650 0 S+ wait 0xc83d2960 sh 642 641 641 0 S+ select 0xc7c83864 make 641 636 641 0 S+ wait 0xc7918320 sh 636 608 636 0 S+ select 0xc77556e4 make 625 624 625 0 S+ ttyin 0xc7743670 csh 624 622 624 1001 S+ wait 0xc7d38640 su 622 621 622 1001 Ss+ pause 0xc76cc6a8 csh 621 618 618 1001 S select 0xc77561a4 sshd 618 558 618 0 Ss select 0xc7755764 sshd --More-- 608 607 608 0 S+ pause 0xc79189c8 csh 607 1 607 0 Ss+ wait 0xc78e2960 login 562 1 562 0 Ss nanslp 0xc252f810 cron 558 1 558 0 Ss select 0xc7755664 sshd 528 1 528 0 Ss select 0xc7709f64 ntpd 455 1 455 0 Ss select 0xc73d1ae4 casperd 454 1 454 0 Ss select 0xc7757264 casperd 422 1 422 0 Ds biowr 0xe1b43980 syslogd 279 1 279 0 Ss select 0xc74bf064 devd 16 0 0 0 DL syncer 0xc259ab8c [syncer] 15 0 0 0 DL vlruwt 0xc76cbc80 [vnlru] 9 0 0 0 DL (threaded) [bufdaemon] 100046 D psleep 0xc259a910 [bufdaemon] 100055 D sdflush 0xc76c0484 [/ worker] 8 0 0 0 DL pgzero 0xc259da3c [pagezero] 7 0 0 0 DL psleep 0xc259d8cc [vmdaemon] 6 0 0 0 DL psleep 0xc25b2a44 [pagedaemon] 5 0 0 0 RL CPU 3 [mmcsd1: mmc/sd card] 4 0 0 0 DL jobqueue 0xc73b2b80 [mmcsd0: mmc/sd card] 3 0 0 0 DL waiting_ 0xc25afd8c [sctp_iterator] --More-- 14 0 0 0 DL (threaded) [usb] 100026 D - 0xc73eaca4 [usbus0] 100027 D - 0xc73eacd4 [usbus0] 100028 D - 0xc73ead04 [usbus0] 100029 D - 0xc73ead34 [usbus0] 100031 D - 0xc74c5ca4 [usbus1] 100032 D - 0xc74c5cd4 [usbus1] 100033 D - 0xc74c5d04 [usbus1] 100034 D - 0xc74c5d34 [usbus1] 2 0 0 0 RL (threaded) [cam] 100020 RunQ [doneq0] 100040 D - 0xc251e2a8 [scanner] 13 0 0 0 DL - 0xc252b120 [rand_harvestq] 12 0 0 0 DL (threaded) [geom] 100012 D - 0xc25a04e4 [g_event] 100013 D - 0xc25a04e8 [g_up] 100014 D - 0xc25a04ec [g_down] 11 0 0 0 RL (threaded) [intr] 100006 I [swi3: vm] 100007 I [swi1: netisr 0] --More-- 100008 I [swi4: clock (0)] 100009 I [swi4: clock (1)] 100010 I [swi4: clock (2)] 100011 I [swi4: clock (3)] 100016 I [swi6: Giant taskq] 100018 I [swi5: fast taskq] 100022 I [swi6: task queue] 100023 I [swi0: uart] 100024 I [intr150: ffec0] 100025 I [intr75: ehci0] 100030 I [intr72: ehci1] 100035 I [intr54: sdhci_imx0] 100036 Run CPU 0 [intr56: sdhci_imx1] 10 0 0 0 RL (threaded) [idle] 100002 CanRun [idle: cpu0] 100003 CanRun [idle: cpu1] 100004 CanRun [idle: cpu2] 100005 CanRun [idle: cpu3] 1 0 1 0 SLs wait 0xc730a640 [init] 0 0 0 0 DLs (threaded) [kernel] --More-- 100000 D swapin 0xc25a0508 [swapper] 100017 D - 0xc73b2380 [thread taskq] 100019 D - 0xc73b2280 [ffs_trim taskq] 100021 D - 0xc73b1f00 [kqueue taskq] 100037 D - 0xc252e6f1 [deadlkres] 100039 D - 0xc73b2200 [CAM taskq] db> root@devel:~ # root@devel:~ # Script done on Thu Nov 27 22:23:39 2014 # It looks like problems with the SD-Card. It is a relative new SanDisk 8 GB card speed 4. I have some of these cards. I never had problems with them. Regards Ulrich From owner-freebsd-arm@FreeBSD.ORG Thu Nov 27 23:07:49 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8D45E185; Thu, 27 Nov 2014 23:07:49 +0000 (UTC) Received: from mail-qg0-x22b.google.com (mail-qg0-x22b.google.com [IPv6:2607:f8b0:400d:c04::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3BCC7B23; Thu, 27 Nov 2014 23:07:49 +0000 (UTC) Received: by mail-qg0-f43.google.com with SMTP id q108so4065318qgd.16 for ; Thu, 27 Nov 2014 15:07:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7uyOYNTNhZmNpKaOo3vK6KvwbT2wkqaA3XqHqsrivow=; b=fAjbleujuK4JDYuDKB9nJkLbFIuDQJXtOZwXUAgLemZRlcyoeG5lIuVzae8YN9aapy ovdqdJjoNcP0jkEjLIPIBFz3cLo91wT8GvGrGOOcXM/BMviabKHefwxPCfAD6l5+tfmq inU4+e0P8TTb4gb99lMFcVd7DfA19ufVD242eFVwJGvfWW80KQPAFBq60OasRAbZ/Mec b05XwnZydJLvkJP7Y8YUMpq4ZfgbrBt4/1hGpWkCqPz+irQSdDZ9OuC9ANLhWoVBk2KV RLECqKJKsM33MrNuf/eWZSCuJmxPycdSa/cF4V6qI7Ht4HJDDBFAfSKNMLmmNvP9EH9g IUfA== MIME-Version: 1.0 X-Received: by 10.224.129.196 with SMTP id p4mr59598111qas.1.1417129668107; Thu, 27 Nov 2014 15:07:48 -0800 (PST) Received: by 10.140.23.242 with HTTP; Thu, 27 Nov 2014 15:07:48 -0800 (PST) In-Reply-To: <20141127234239.e2c40a8fb99ba41f9ec3a7e7@ulrich-grey.de> References: <20141113125236.b16cd4e5f0e339eac0494cd4@ulrich-grey.de> <20141115143444.5ad037548e06f289d2532fb7@ulrich-grey.de> <20141119225903.81fbbc7809093a0e6e0de9d5@ulrich-grey.de> <20141120151900.a68c6d8316b96a62cb65d17a@ulrich-grey.de> <20141121115941.54d4e36b103341c3adf7eb36@ulrich-grey.de> <20141124132733.4e96b906f0d1ab69969dddd9@ulrich-grey.de> <1416840814.1147.380.camel@revolution.hippie.lan> <20141125225451.924a5df4bdb4753db273b8c5@ulrich-grey.de> <20141127234239.e2c40a8fb99ba41f9ec3a7e7@ulrich-grey.de> Date: Fri, 28 Nov 2014 00:07:48 +0100 Message-ID: Subject: Re: Another Test Run with Alternative pmap Implementation From: Svatopluk Kraus To: Ulrich Grey Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-arm@freebsd.org, Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Nov 2014 23:07:49 -0000 Well, your "make buildworld" runs really long time. It was strange for me from first moment. Now, when Ian wrote that his build runs about two hours on same platform, it's another indicia. It looks that your temporary files are created on SD card, where writes are really long. So try to move it to usb disk. And whatever what writes to SD card much during build. This way we would be able to isolate the problem to SD card stuff. Svata On Thu, Nov 27, 2014 at 11:42 PM, Ulrich Grey wrote: > hello, > > on advice from Svatopluk Kraus I additionally compiled these debugging > options into the > kernel: > > options KTR > options KTR_MASK=KTR_ALL > options KTR_ENTRIES=65536 > > I did my crashtest. The system crashes after some hours, I could not do > anything on > another terminal. > > cc -fpic -DPIC -O -pipe > > -I/usr/local/DEVEL/STREJDA/freebsd/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi > > -I/usr/local/DEVEL/STREJDA/freebsd/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi/krb5 > > -I/usr/local/DEVEL/STREJDA/freebsd/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi/gssapi > > -I/usr/local/DEVEL/STREJDA/freebsd/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/krb5 > > -I/usr/local/DEVEL/STREJDA/freebsd/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/asn1 > > -I/usr/local/DEVEL/STREJDA/freebsd/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/roken > -I. -DHAVE_CONFIG_H > > -I/usr/local/DEVEL/STREJDA/freebsd/kerberos5/lib/libgssapi_krb5/../../include > -std=gnu99 -Qunused-arguments > -c > /usr/local/DEVEL/STREJDA/freebsd/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi/krb5/inquire_cred_by_oid.c > -o inquire_cred_by_oid.So > > mmcsd1: Error indicated: 1 Timeout > > sdhci_immmxc1-sslot0:d 1G:ot dEata rinterrruopt r0 xi0n0d0i0c0a0t10,e > db:u t1 > tThiemreeo uits > no active command. > > From owner-freebsd-arm@FreeBSD.ORG Thu Nov 27 23:13:07 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2503443A; Thu, 27 Nov 2014 23:13:07 +0000 (UTC) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::6]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.smtp.rzone.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 507BABE9; Thu, 27 Nov 2014 23:13:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1417129958; l=37696; s=domk; d=ulrich-grey.de; h=Content-Transfer-Encoding:Content-Type:Mime-Version:References: In-Reply-To:Subject:Cc:To:From:Date; bh=8wIeBXnY0KEAVidH0XTr2ZCzwOQ=; b=CL8ppxIjH9k5qbbEz93RHlpOnrujnqoCR9HtqPd6pxSAFnihAf2JZZth8Jo3LhftKW+ s2eV+5zUPwQ9B/+l9oPetv+T+1RFqWZXSsHbpRKtQIWlVx+Me/xZPNxnGBf6fiusnFfwE JtqY4imQrrsPI3VG3vR+URT3xz7pCzbhqv8= X-RZG-AUTH: :OX8Be0W8W+pMC3rDLL/lo2xV/LZTbZkYhOcjg8suic3iYr/B8J9Lzp3TJg49uMv/iwf9 X-RZG-CLASS-ID: mo00 Received: from bbu (p548696C0.dip0.t-ipconnect.de [84.134.150.192]) by smtp.strato.de (RZmta 36.2 DYNA|AUTH) with ESMTPSA id 402f2eqARNCa3qk (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate); Fri, 28 Nov 2014 00:12:36 +0100 (CET) Date: Fri, 28 Nov 2014 00:12:35 +0100 From: Ulrich Grey To: Ulrich Grey Subject: Re: Another Test Run with Alternative pmap Implementation Message-Id: <20141128001235.6591396b2f6298b861a96b57@ulrich-grey.de> In-Reply-To: <20141127234239.e2c40a8fb99ba41f9ec3a7e7@ulrich-grey.de> References: <20141113125236.b16cd4e5f0e339eac0494cd4@ulrich-grey.de> <20141115143444.5ad037548e06f289d2532fb7@ulrich-grey.de> <20141119225903.81fbbc7809093a0e6e0de9d5@ulrich-grey.de> <20141120151900.a68c6d8316b96a62cb65d17a@ulrich-grey.de> <20141121115941.54d4e36b103341c3adf7eb36@ulrich-grey.de> <20141124132733.4e96b906f0d1ab69969dddd9@ulrich-grey.de> <1416840814.1147.380.camel@revolution.hippie.lan> <20141125225451.924a5df4bdb4753db273b8c5@ulrich-grey.de> <20141127234239.e2c40a8fb99ba41f9ec3a7e7@ulrich-grey.de> Organization: - X-Mailer: Sylpheed 3.3.0 (GTK+ 2.24.22; armv6-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org, Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Nov 2014 23:13:07 -0000 I have found this messages in dmesg output: Feeding entropy:. inm_print: --- begin inm 0xc7760300 --- addr 224.0.0.1 ifp 0xc7698400(lo0) ifma 0xc7758d20 timer 0 state not-member refcount 1 scq.len 0 igi 0xc74d2d00 nsrc 0 sctimer 0 scrv 0 t0: fmode un asm 0 ex 0 in 0 rec 0 t1: fmode ex asm 1 ex 1 in 0 rec 0 inm_print: --- end inm 0xc7760300 --- inm_print: --- begin inm 0xc7760300 --- addr 224.0.0.1 ifp 0xc7698400(lo0) ifma 0xc7758d20 timer 0 state silent refcount 1 scq.len 0 igi 0xc74d2d00 nsrc 0 sctimer 0 scrv 0 t0: fmode un asm 0 ex 0 in 0 rec 0 t1: fmode ex asm 1 ex 1 in 0 rec 0 inm_print: --- end inm 0xc7760300 --- in6m_print: --- begin in6m 0xc77a6300 --- addr ff02:2::1:ff00:1 ifp 0xc7698400(lo0) ifma 0xc7758d00 timer 0 state not-member refcount 1 scq.len 0 mli 0xc74d2c00 nsrc 0 sctimer 0 scrv 0 t0: fmode un asm 0 ex 0 in 0 rec 0 t1: fmode ex asm 1 ex 1 in 0 rec 0 in6m_print: --- end in6m 0xc77a6300 --- in6m_print: --- begin in6m 0xc77a6300 --- addr ff02:2::1:ff00:1 ifp 0xc7698400(lo0) ifma 0xc7758d00 timer 0 state silent refcount 1 scq.len 0 mli 0xc74d2c00 nsrc 0 sctimer 0 scrv 0 t0: fmode un asm 0 ex 0 in 0 rec 0 t1: fmode ex asm 1 ex 1 in 0 rec 0 in6m_print: --- end in6m 0xc77a6300 --- in6m_print: --- begin in6m 0xc77a6200 --- addr ff02:2::1 ifp 0xc7698400(lo0) ifma 0xc7758cc0 timer 0 state not-member refcount 1 scq.len 0 mli 0xc74d2c00 nsrc 0 sctimer 0 scrv 0 t0: fmode un asm 0 ex 0 in 0 rec 0 t1: fmode ex asm 1 ex 1 in 0 rec 0 in6m_print: --- end in6m 0xc77a6200 --- in6m_print: --- begin in6m 0xc77a6200 --- addr ff02:2::1 ifp 0xc7698400(lo0) ifma 0xc7758cc0 timer 0 state silent refcount 1 scq.len 0 mli 0xc74d2c00 nsrc 0 sctimer 0 scrv 0 t0: fmode un asm 0 ex 0 in 0 rec 0 t1: fmode ex asm 1 ex 1 in 0 rec 0 in6m_print: --- end in6m 0xc77a6200 --- in6m_print: --- begin in6m 0xc77a6100 --- addr ff02:2::2:ffeb:aec2 ifp 0xc7698400(lo0) ifma 0xc7758c80 timer 0 state not-member refcount 1 scq.len 0 mli 0xc74d2c00 nsrc 0 sctimer 0 scrv 0 t0: fmode un asm 0 ex 0 in 0 rec 0 t1: fmode ex asm 1 ex 1 in 0 rec 0 in6m_print: --- end in6m 0xc77a6100 --- in6m_print: --- begin in6m 0xc77a6100 --- addr ff02:2::2:ffeb:aec2 ifp 0xc7698400(lo0) ifma 0xc7758c80 timer 0 state silent refcount 1 scq.len 0 mli 0xc74d2c00 nsrc 0 sctimer 0 scrv 0 t0: fmode un asm 0 ex 0 in 0 rec 0 t1: fmode ex asm 1 ex 1 in 0 rec 0 in6m_print: --- end in6m 0xc77a6100 --- in6m_print: --- begin in6m 0xc77a6000 --- addr ff02:2::2:ebae:c2ef ifp 0xc7698400(lo0) ifma 0xc7758c40 timer 0 state not-member refcount 1 scq.len 0 mli 0xc74d2c00 nsrc 0 sctimer 0 scrv 0 t0: fmode un asm 0 ex 0 in 0 rec 0 t1: fmode ex asm 1 ex 1 in 0 rec 0 in6m_print: --- end in6m 0xc77a6000 --- in6m_print: --- begin in6m 0xc77a6000 --- addr ff02:2::2:ebae:c2ef ifp 0xc7698400(lo0) ifma 0xc7758c40 timer 0 state silent refcount 1 scq.len 0 mli 0xc74d2c00 nsrc 0 sctimer 0 scrv 0 t0: fmode un asm 0 ex 0 in 0 rec 0 t1: fmode ex asm 1 ex 1 in 0 rec 0 in6m_print: --- end in6m 0xc77a6000 --- in6m_print: --- begin in6m 0xc77a5e00 --- addr ff01:2::1 ifp 0xc7698400(lo0) ifma 0xc7758c00 timer 0 state not-member refcount 1 scq.len 0 mli 0xc74d2c00 nsrc 0 sctimer 0 scrv 0 t0: fmode un asm 0 ex 0 in 0 rec 0 t1: fmode ex asm 1 ex 1 in 0 rec 0 in6m_print: --- end in6m 0xc77a5e00 --- in6m_print: --- begin in6m 0xc77a5e00 --- addr ff01:2::1 ifp 0xc7698400(lo0) ifma 0xc7758c00 timer 0 state silent refcount 1 scq.len 0 mli 0xc74d2c00 nsrc 0 sctimer 0 scrv 0 t0: fmode un asm 0 ex 0 in 0 rec 0 t1: fmode ex asm 1 ex 1 in 0 rec 0 in6m_print: --- end in6m 0xc77a5e00 --- in6m_print: --- begin in6m 0xc77a6300 --- addr ff02:2::1:ff00:1 ifp 0xc7698400(lo0) ifma 0xc7758d00 timer 0 state silent refcount 2 scq.len 0 mli 0xc74d2c00 nsrc 0 sctimer 0 scrv 0 t0: fmode ex asm 1 ex 1 in 0 rec 0 t1: fmode ex asm 2 ex 2 in 0 rec 0 in6m_print: --- end in6m 0xc77a6300 --- in6m_print: --- begin in6m 0xc77a6300 --- addr ff02:2::1:ff00:1 ifp 0xc7698400(lo0) ifma 0xc7758d00 timer 0 state silent refcount 2 scq.len 0 mli 0xc74d2c00 nsrc 0 sctimer 0 scrv 0 t0: fmode ex asm 1 ex 1 in 0 rec 0 t1: fmode ex asm 2 ex 2 in 0 rec 0 in6m_print: --- end in6m 0xc77a6300 --- in6m_print: --- begin in6m 0xc77a6200 --- addr ff02:2::1 ifp 0xc7698400(lo0) ifma 0xc7758cc0 timer 0 state silent refcount 2 scq.len 0 mli 0xc74d2c00 nsrc 0 sctimer 0 scrv 0 t0: fmode ex asm 1 ex 1 in 0 rec 0 t1: fmode ex asm 2 ex 2 in 0 rec 0 in6m_print: --- end in6m 0xc77a6200 --- in6m_print: --- begin in6m 0xc77a6200 --- addr ff02:2::1 ifp 0xc7698400(lo0) ifma 0xc7758cc0 timer 0 state silent refcount 2 scq.len 0 mli 0xc74d2c00 nsrc 0 sctimer 0 scrv 0 t0: fmode ex asm 1 ex 1 in 0 rec 0 t1: fmode ex asm 2 ex 2 in 0 rec 0 in6m_print: --- end in6m 0xc77a6200 --- in6m_print: --- begin in6m 0xc77a6100 --- addr ff02:2::2:ffeb:aec2 ifp 0xc7698400(lo0) ifma 0xc7758c80 timer 0 state silent refcount 2 scq.len 0 mli 0xc74d2c00 nsrc 0 sctimer 0 scrv 0 t0: fmode ex asm 1 ex 1 in 0 rec 0 t1: fmode ex asm 2 ex 2 in 0 rec 0 in6m_print: --- end in6m 0xc77a6100 --- in6m_print: --- begin in6m 0xc77a6100 --- addr ff02:2::2:ffeb:aec2 ifp 0xc7698400(lo0) ifma 0xc7758c80 timer 0 state silent refcount 2 scq.len 0 mli 0xc74d2c00 nsrc 0 sctimer 0 scrv 0 t0: fmode ex asm 1 ex 1 in 0 rec 0 t1: fmode ex asm 2 ex 2 in 0 rec 0 in6m_print: --- end in6m 0xc77a6100 --- in6m_print: --- begin in6m 0xc77a6000 --- addr ff02:2::2:ebae:c2ef ifp 0xc7698400(lo0) ifma 0xc7758c40 timer 0 state silent refcount 2 scq.len 0 mli 0xc74d2c00 nsrc 0 sctimer 0 scrv 0 t0: fmode ex asm 1 ex 1 in 0 rec 0 t1: fmode ex asm 2 ex 2 in 0 rec 0 in6m_print: --- end in6m 0xc77a6000 --- in6m_print: --- begin in6m 0xc77a6000 --- addr ff02:2::2:ebae:c2ef ifp 0xc7698400(lo0) ifma 0xc7758c40 timer 0 state silent refcount 2 scq.len 0 mli 0xc74d2c00 nsrc 0 sctimer 0 scrv 0 t0: fmode ex asm 1 ex 1 in 0 rec 0 t1: fmode ex asm 2 ex 2 in 0 rec 0 in6m_print: --- end in6m 0xc77a6000 --- in6m_print: --- begin in6m 0xc77a5e00 --- addr ff01:2::1 ifp 0xc7698400(lo0) ifma 0xc7758c00 timer 0 state silent refcount 2 scq.len 0 mli 0xc74d2c00 nsrc 0 sctimer 0 scrv 0 t0: fmode ex asm 1 ex 1 in 0 rec 0 t1: fmode ex asm 2 ex 2 in 0 rec 0 in6m_print: --- end in6m 0xc77a5e00 --- in6m_print: --- begin in6m 0xc77a5e00 --- addr ff01:2::1 ifp 0xc7698400(lo0) ifma 0xc7758c00 timer 0 state silent refcount 2 scq.len 0 mli 0xc74d2c00 nsrc 0 sctimer 0 scrv 0 t0: fmode ex asm 1 ex 1 in 0 rec 0 t1: fmode ex asm 2 ex 2 in 0 rec 0 in6m_print: --- end in6m 0xc77a5e00 --- inm_print: --- begin inm 0xc7703b80 --- addr 224.0.0.1 ifp 0xc7408400(ffec0) ifma 0xc7758d40 timer 0 state not-member refcount 1 scq.len 0 igi 0xc74d2f00 nsrc 0 sctimer 0 scrv 0 t0: fmode un asm 0 ex 0 in 0 rec 0 t1: fmode ex asm 1 ex 1 in 0 rec 0 inm_print: --- end inm 0xc7703b80 --- inm_print: --- begin inm 0xc7703b80 --- addr 224.0.0.1 ifp 0xc7408400(ffec0) ifma 0xc7758d40 timer 0 state silent refcount 1 scq.len 0 igi 0xc74d2f00 nsrc 0 sctimer 0 scrv 0 t0: fmode un asm 0 ex 0 in 0 rec 0 t1: fmode ex asm 1 ex 1 in 0 rec 0 inm_print: --- end inm 0xc7703b80 --- Starting Network: lo0 ffec0. lo0: flags=8049 metric 0 mtu 16384 options=600003 inet 127.0.0.1 netmask 0xff000000 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 groups: lo nd6 options=21 ffec0: flags=8843 metric 0 mtu 1500 options=80008 ether 00:1f:7b:b4:10:71 inet 192.168.0.200 netmask 0xffffff00 broadcast 192.168.0.255 media: Ethernet autoselect (none) status: no carrier nd6 options=29 Starting devd. Starting pflogd: add net default: gateway 192.168.0.155 Additional inet routing options: ignore ICMP redirect=YES log ICMP redirect=YES. add net fe80::: gateway ::1 add net ff02::: gateway ::1 add net ::ffff:0.0.0.0: gateway ::1 add net ::0.0.0.0: gateway ::1 Creating and/or trimming log files. Starting syslogd. No core dumps found. ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib /usr/local/lib/qt4 Starting casperd. Clearing /tmp. Starting dbus. Failed to start message bus: Could not get UID and GID for username "messagebus" /etc/rc: WARNING: failed to start dbus Updating motd:. Mounting late file systems:. Starting ntpd. Performing sanity check on sshd configuration. Starting sshd. Starting cron. Starting background file system checks in 60 seconds. Thu Nov 27 15:17:36 UTC 2014 Nov 27 15:17:41 quad login: ROOT LOGIN (root) ON ttyu0 lock order reversal: 1st 0xe1b3a820 bufwait (bufwait) @ /usr/local/DEVEL/STREJDA/freebsd/sys/kern/vfs_bio.c:3093 2nd 0xc774dc00 dirhash (dirhash) @ /usr/local/DEVEL/STREJDA/freebsd/sys/ufs/ufs/ufs_dirhash.c:285 KDB: stack backtrace: db_trace_self() at db_trace_self pc = 0xc23d5b18 lr = 0xc203abb0 (db_trace_self_wrapper+0x30) sp = 0xfab4f988 fp = 0xfab4faa0 r10 = 0xc774dc00 db_trace_self_wrapper() at db_trace_self_wrapper+0x30 pc = 0xc203abb0 lr = 0xc21ab500 (kdb_backtrace+0x38) sp = 0xfab4faa8 fp = 0xfab4fab0 r4 = 0xc253d7f4 r5 = 0xc242ca32 r6 = 0xc24630d3 r7 = 0xc256f074 kdb_backtrace() at kdb_backtrace+0x38 pc = 0xc21ab500 lr = 0xc21c7908 (witness_checkorder+0xe5c) sp = 0xfab4fab8 fp = 0xfab4fb08 r4 = 0xc246349d witness_checkorder() at witness_checkorder+0xe5c pc = 0xc21c7908 lr = 0xc2175758 (_sx_xlock+0x7c) sp = 0xfab4fb10 fp = 0xfab4fb50 r4 = 0x0000011d r5 = 0xc24630d0 r6 = 0xc774dc10 r7 = 0xc774dc00 r8 = 0x00000000 r9 = 0xc78a0a80 r10 = 0x00000000 _sx_xlock() at _sx_xlock+0x7c pc = 0xc2175758 lr = 0xc238e31c (ufsdirhash_remove+0x3c) sp = 0xfab4fb58 fp = 0xfab4fb70 r4 = 0xc774dc00 r5 = 0xc7cae48c r6 = 0xe235c018 r7 = 0xc78a0a80 r8 = 0x00000018 ufsdirhash_remove() at ufsdirhash_remove+0x3c pc = 0xc238e31c lr = 0xc2391400 (ufs_dirremove+0x14c) sp = 0xfab4fb78 fp = 0xfab4fba8 r4 = 0xc78a0a00 r5 = 0xc7cae48c r6 = 0xc7cae480 r7 = 0xe235c018 r8 = 0x00000000 ufs_dirremove() at ufs_dirremove+0x14c pc = 0xc2391400 lr = 0xc2397934 (ufs_remove+0x70) sp = 0xfab4fbb0 fp = 0xfab4fbd8 r4 = 0xc7cae360 r5 = 0x00000001 r6 = 0xfab4fd50 r7 = 0xc78a0a00 r8 = 0xc7cae480 r9 = 0xc78f0370 r10 = 0x00000000 ufs_remove() at ufs_remove+0x70 pc = 0xc2397934 lr = 0xc240048c (VOP_REMOVE_APV+0x100) sp = 0xfab4fbe0 fp = 0xfab4fc08 r4 = 0xfab4fd50 r5 = 0xc2515bc4 r6 = 0x00000000 r7 = 0xc247089d r8 = 0x00000000 r9 = 0xc7cae360 VOP_REMOVE_APV() at VOP_REMOVE_APV+0x100 pc = 0xc240048c lr = 0xc2225aa4 (kern_unlinkat+0x1b4) sp = 0xfab4fc10 fp = 0xfab4fd80 r4 = 0xfab4fcb0 r5 = 0xc78f0370 r6 = 0x2081e3d8 r7 = 0xffffff9c kern_unlinkat() at kern_unlinkat+0x1b4 pc = 0xc2225aa4 lr = 0xc22258e8 (sys_unlink+0x24) sp = 0xfab4fd88 fp = 0xfab4fd90 r4 = 0xc78f0370 r5 = 0xc78e2640 r6 = 0x00000000 r7 = 0x00000008 r8 = 0xfab4fe08 r9 = 0xfab4fe00 r10 = 0x00000000 sys_unlink() at sys_unlink+0x24 pc = 0xc22258e8 lr = 0xc23ed828 (swi_handler+0x2cc) sp = 0xfab4fd98 fp = 0xfab4fe50 swi_handler() at swi_handler+0x2cc pc = 0xc23ed828 lr = 0xc23d7888 (swi_exit) sp = 0xfab4fe58 fp = 0xbfbffd00 r4 = 0x20803080 r5 = 0x0000a4de r6 = 0x00000000 r7 = 0x0000000a r8 = 0x00000001 r9 = 0x00000000 r10 = 0x000127a0 swi_exit() at swi_exit pc = 0xc23d7888 lr = 0xc23d7888 (swi_exit) sp = 0xfab4fe58 fp = 0xbfbffd00 Nov 27 15:20:25 quad su: gwgpi to root on /dev/pts/0 lock order reversal: 1st 0xc7ca0db4 ufs (ufs) @ /usr/local/DEVEL/STREJDA/freebsd/sys/kern/vfs_subr.c:2144 2nd 0xe1b30560 bufwait (bufwait) @ /usr/local/DEVEL/STREJDA/freebsd/sys/ufs/ffs/ffs_vnops.c:263 3rd 0xc8039274 ufs (ufs) @ /usr/local/DEVEL/STREJDA/freebsd/sys/kern/vfs_subr.c:2144 KDB: stack backtrace: db_trace_self() at db_trace_self pc = 0xc23d5b18 lr = 0xc203abb0 (db_trace_self_wrapper+0x30) sp = 0xfab89370 fp = 0xfab89488 r10 = 0xc8039274 db_trace_self_wrapper() at db_trace_self_wrapper+0x30 pc = 0xc203abb0 lr = 0xc21ab500 (kdb_backtrace+0x38) sp = 0xfab89490 fp = 0xfab89498 r4 = 0xc253d7f4 r5 = 0xc242ca32 r6 = 0xc244a3e6 r7 = 0xc256ed4c kdb_backtrace() at kdb_backtrace+0x38 pc = 0xc21ab500 lr = 0xc21c7908 (witness_checkorder+0xe5c) sp = 0xfab894a0 fp = 0xfab894f0 r4 = 0xc242d235 witness_checkorder() at witness_checkorder+0xe5c pc = 0xc21c7908 lr = 0xc214f12c (__lockmgr_args+0xb54) sp = 0xfab894f8 fp = 0xfab89570 r4 = 0xc8039274 r5 = 0x00000000 r6 = 0x00080100 r7 = 0xc24ff8b0 r8 = 0xc8039294 r9 = 0x00000100 r10 = 0xc244a3e3 __lockmgr_args() at __lockmgr_args+0xb54 pc = 0xc214f12c lr = 0xc23888d8 (ffs_lock+0x80) sp = 0xfab89578 fp = 0xfab895a0 r4 = 0xfab895d8 r5 = 0x00080100 r6 = 0xc8039240 r7 = 0xc8039274 r8 = 0xc8039294 r9 = 0x00000000 r10 = 0x00000860 ffs_lock() at ffs_lock+0x80 pc = 0xc23888d8 lr = 0xc2401434 (VOP_LOCK1_APV+0x108) sp = 0xfab895a8 fp = 0xfab895d0 r4 = 0xfab895d8 r5 = 0xc2515648 r6 = 0x00000000 r7 = 0xc2471004 r8 = 0xfab895d8 r9 = 0xc2462064 VOP_LOCK1_APV() at VOP_LOCK1_APV+0x108 pc = 0xc2401434 lr = 0xc222aff4 (_vn_lock+0x44) sp = 0xfab895d8 fp = 0xfab89608 r4 = 0xc8039240 r5 = 0x0001d1f3 r6 = 0xc244a3e3 r7 = 0x00080100 _vn_lock() at _vn_lock+0x44 pc = 0xc222aff4 lr = 0xc221bf88 (vget+0x90) sp = 0xfab89610 fp = 0xfab89648 r4 = 0xc8039240 r5 = 0x0001d1f3 r6 = 0x00080100 r7 = 0xc259aa6c r8 = 0xc78e4000 r9 = 0xc2462064 r10 = 0x00000000 vget() at vget+0x90 pc = 0xc221bf88 lr = 0xc220fcf8 (vfs_hash_get+0xd8) sp = 0xfab89650 fp = 0xfab89680 r4 = 0xc259aa50 r5 = 0x0001d1f3 r6 = 0xc77f32b0 r7 = 0xc259aa6c r8 = 0xc8039240 r9 = 0xc24494b9 vfs_hash_get() at vfs_hash_get+0xd8 pc = 0xc220fcf8 lr = 0xc2383ad4 (ffs_vgetf+0x38) sp = 0xfab89688 fp = 0xfab896e0 r4 = 0xc77fe700 r5 = 0x00080000 r6 = 0xc77f32b0 r7 = 0x0001d1f3 r8 = 0xc7737000 r9 = 0xc245ed7c r10 = 0xfab89748 ffs_vgetf() at ffs_vgetf+0x38 pc = 0xc2383ad4 lr = 0xc237ae0c (softdep_sync_buf+0xad4) sp = 0xfab896e8 fp = 0xfab89768 r4 = 0xc77fe700 r5 = 0x0001d1f3 r6 = 0x00000000 r7 = 0x0000088d r8 = 0xc7737000 r9 = 0xc245ed7c r10 = 0xc7ca6d34 softdep_sync_buf() at softdep_sync_buf+0xad4 pc = 0xc237ae0c lr = 0xc23895a8 (ffs_syncvnode+0x2e0) sp = 0xfab89770 fp = 0xfab897c0 r4 = 0xc7ca0d80 r5 = 0x00000000 r6 = 0xc2462b7d r7 = 0x00000001 r8 = 0xe1b30560 r9 = 0xe1b30510 r10 = 0x00000010 ffs_syncvnode() at ffs_syncvnode+0x2e0 pc = 0xc23895a8 lr = 0xc235e378 (ffs_truncate+0x6d0) sp = 0xfab897c8 fp = 0xfab89978 r4 = 0xc7ca0d80 r5 = 0x00000000 r6 = 0x00000200 r7 = 0xc78d8900 r8 = 0x00000880 r9 = 0x00000000 r10 = 0x00000200 ffs_truncate() at ffs_truncate+0x6d0 pc = 0xc235e378 lr = 0xc2391124 (ufs_direnter+0x88c) sp = 0xfab89980 fp = 0xfab899e8 r4 = 0xc7ca0d80 r5 = 0xc78d8900 r6 = 0x00000000 r7 = 0x00000000 r8 = 0xc8039240 r9 = 0xc7ca0d80 r10 = 0x00000000 ufs_direnter() at ufs_direnter+0x88c pc = 0xc2391124 lr = 0xc239a37c (ufs_makeinode+0x3e8) sp = 0xfab899f0 fp = 0xfab89b50 r4 = 0x00000000 r5 = 0xfab89d08 r6 = 0xfab89a10 r7 = 0x00000000 r8 = 0xfab89d20 r9 = 0xc7ca0d80 r10 = 0xc7f3e280 ufs_makeinode() at ufs_makeinode+0x3e8 pc = 0xc239a37c lr = 0xc239682c (ufs_create+0x24) sp = 0xfab89b58 fp = 0xfab89b58 r4 = 0xfab89c40 r5 = 0xc2515bc4 r6 = 0x00000000 r7 = 0xc246faa8 r8 = 0xfab89d28 r9 = 0x00000000 r10 = 0x00000000 ufs_create() at ufs_create+0x24 pc = 0xc239682c lr = 0xc23fe9cc (VOP_CREATE_APV+0xfc) sp = 0xfab89b60 fp = 0xfab89b88 VOP_CREATE_APV() at VOP_CREATE_APV+0xfc pc = 0xc23fe9cc lr = 0xc222a898 (vn_open_cred+0x208) sp = 0xfab89b90 fp = 0xfab89c70 r4 = 0xfab89cb8 r5 = 0xfab89d08 r6 = 0x00000800 r7 = 0x00000a03 vn_open_cred() at vn_open_cred+0x208 pc = 0xc222a898 lr = 0xc222a688 (vn_open+0x24) sp = 0xfab89c78 fp = 0xfab89c80 r4 = 0xc78e4000 r5 = 0x000500cf r6 = 0x00000012 r7 = 0xfab89cb8 r8 = 0x00000000 r9 = 0xbfbfe0ac r10 = 0xfab89ca8 vn_open() at vn_open+0x24 pc = 0xc222a688 lr = 0xc22247d4 (kern_openat+0x248) sp = 0xfab89c88 fp = 0xfab89d80 kern_openat() at kern_openat+0x248 pc = 0xc22247d4 lr = 0xc2224584 (sys_open+0x28) sp = 0xfab89d88 fp = 0xfab89d90 r4 = 0xc78e4000 r5 = 0xc78e1640 r6 = 0x00000000 r7 = 0x00000180 r8 = 0xfab89e08 r9 = 0xfab89e00 r10 = 0x00000000 sys_open() at sys_open+0x28 pc = 0xc2224584 lr = 0xc23ed828 (swi_handler+0x2cc) sp = 0xfab89d98 fp = 0xfab89e50 swi_handler() at swi_handler+0x2cc pc = 0xc23ed828 lr = 0xc23d7888 (swi_exit) sp = 0xfab89e58 fp = 0xbfbfe090 r4 = 0x00000000 r5 = 0xbfbfe09c r6 = 0xbfbfe0ac r7 = 0x00000005 r8 = 0x00000000 r9 = 0xbfbfe0b5 r10 = 0x00000011 swi_exit() at swi_exit pc = 0xc23d7888 lr = 0xc23d7888 (swi_exit) sp = 0xfab89e58 fp = 0xbfbfe090 Nov 27 16:00:14 syslogd: /dev/console: Interrupted system call Expensive timeout(9) function: 0xc2074fb4(0xc74c5c78) 0.002307912 s Expensive timeout(9) function: 0xc23fbfd4(0xc73e6000) 0.002396580 s Nov 27 19:00:26 syslogd: /dev/console: Interrupted system call root@quad:/usr/home/gwgpi # Write failed: Broken pipe osx-mini:~ mac$ Ulrich ----------------------------------- On Thu, 27 Nov 2014 23:42:39 +0100 Ulrich Grey wrote: > hello, > > on advice from Svatopluk Kraus I additionally compiled these debugging options into the > kernel: > > options KTR > options KTR_MASK=KTR_ALL > options KTR_ENTRIES=65536 > > I did my crashtest. The system crashes after some hours, I could not do anything on > another terminal. > > cc -fpic -DPIC -O -pipe > -I/usr/local/DEVEL/STREJDA/freebsd/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi > -I/usr/local/DEVEL/STREJDA/freebsd/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi/krb5 > -I/usr/local/DEVEL/STREJDA/freebsd/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi/gssapi > -I/usr/local/DEVEL/STREJDA/freebsd/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/krb5 > -I/usr/local/DEVEL/STREJDA/freebsd/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/asn1 > -I/usr/local/DEVEL/STREJDA/freebsd/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/roken > -I. -DHAVE_CONFIG_H > -I/usr/local/DEVEL/STREJDA/freebsd/kerberos5/lib/libgssapi_krb5/../../include > -std=gnu99 -Qunused-arguments > -c /usr/local/DEVEL/STREJDA/freebsd/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi/krb5/inquire_cred_by_oid.c > -o inquire_cred_by_oid.So > > mmcsd1: Error indicated: 1 Timeout > > sdhci_immmxc1-sslot0:d 1G:ot dEata rinterrruopt r0 xi0n0d0i0c0a0t10,e db:u t1 > tThiemreeo uits > no active command. > > sdhci_imx1-slot0: ============== REGISTER DUMP ============== > > sdhci_imx1-slot0: Sys addr: 0x00000000 | Version: 0x00000002 > > sdhci_imx1-slot0: Blk size: 0x00000200 | Blk cnt: 0x00000040 > > sdhci_imx1-slot0: Argument: 0x001dffc0 | Trn mode: 0x00000026 > > sdhci_imx1-slot0: Present: 0x00fd0000 | Host ctl: 0x00000003 > > sdhci_imx1-slot0: Power: 0x0000000d | Blk gap: 0x00000080 > > sdhci_imx1-slot0: Wake-up: 0x00000000 | Clock: 0x00000207 > > sdhci_imx1-slot0: Timeout: 0x0000000d | Int stat: 0x00000000 > > sdhci_imx1-slot0: Int enab: 0x017f00fb | Sig enab: 0x017f00fb > > sdhci_imx1-slot0: AC12 err: 0x00000000 | Slot int: 0x00000000 > > sdhci_imx1-slot0: Caps: 0x0377c800 | Max curr: 0x80000026 > > sdhci_imx1-slot0: =========================================== > > g_vfs_done():mmcsd1s2a[WRITE(offset=945684480, length=32768)]error = 5 > > g_vfs_done():mmcsd1s2a[WRITE(offset=945717248, length=32768)]error = 5 > > sdhci_imx1-slot0: Got data interrupt 0x00000010, but there is no active command. > > sdhci_imx1-slot0: ============== REGISTER DUMP ============== > > sdhci_imx1-slot0: Sys addr: 0x00000000 | Version: 0x00000002 > > sdhci_imx1-slot0: Blk size: 0x00000200 | Blk cnt: m m0cxs0d010:0 0E0r0r8o > r > sidnhdciic_aitmexd1:- s1l oTti0m:e oAurtg > u > ment: 0x0030e9f8 | Trn mode: 0x00000026 > > sdhci_imx1-slot0: Present: 0x00fd0000 | Host ctl: 0x00000003 > > sdhci_imx1-slot0: Power: 0x0000000d | Blk gap: 0x00000080 > > sdhci_imx1-slot0: Wake-up: 0x00000000 | Clock: 0x00000207 > > sdhci_imx1-slot0: Timeout: 0x0000000d | Int stat: 0x00000000 > > sdhci_imx1-slot0: Int enab: 0x017f00fb | Sig enab: 0x017f00fb > > sdhci_imx1-slot0: AC12 err: 0x00000000 | Slot int: 0x00000000 > > sdhci_imx1-slot0: Caps: 0x0377c800 | Max curr: 0x80000026 > > sdhci_imx1-slot0: =========================================== > > g_vfs_done():mmcsd1s2a[WRITE(offset=1580396544, length=4096)]error = 5 > > sdhci_imx1-slot0: Got data interrupt 0x00000010, but there is no active command. > > sdhci_imx1-slot0: ============== REGISTER DUMP ============== > > sdhci_imx1-slot0: Sys addr: 0x00000000 | Version: 0x00000002 > > sdhci_imx1-slot0: Blk size: 0x00000200 | Blk cnt: 0x00000008 > > sdhci_imx1-slot0: Argument: 0x0030e9f8 | Trn mode: 0x00000026 > > sdhci_imx1-slot0: Present: 0x00fd0000 | Host ctl: 0x00000003 > > sdhci_imx1-slot0: Power: 0x0000000d | Blk gap: 0x00000080 > > sdhci_imx1-slot0: Wake-up: 0x00000000 | Clock: 0x00000207 > > sdhci_imx1-slot0: Timeout: 0x0000000d | Int stat: 0x00000000 > > sdhci_imx1-slot0: Int enab: 0x017f00fb | Sig enab: 0x017f00fb > > sdhci_imx1-slot0: AC12 err: 0x00000000 | Slot int: 0x00000000 > > sdhci_imx1-slot0: Caps: 0x0377c800 | Max curr: 0x80000026 > > sdhci_imx1-slot0: =========================================== > > mmcsd1: Error indicated: 1 Timeout > > g_vfs_done():mmcsd1s2a[WRITE(offset=1580396544, length=4096)]error = 5 > > sdhcmim_cismdx11:- sElrorto0r: iGnodti cdaattead :i n1t eTrirmuepotu t0 > x > 00000010, but there is no active command. > > sdhci_imx1-slot0: ============== REGISTEpanic: initiate_write_inodeblock_ufs2: already > started > > cpuid = 1 > > KDB: stack backtrace: > > db_trace_self() at db_trace_self > > pc = 0xc23d5b18 lr = 0xc203abb0 (db_trace_self_wrapper+0x30) > > sp = 0xfb0447a8 fp = 0xfb0448c0 > > r10 = 0xc82ed000 > > db_trace_self_wrapper() at db_trace_self_wrapper+0x30 > > pc = 0xc203abb0 lr = 0xc21ab500 (kdb_backtrace+0x38) > > sp = 0xfb0448c8 fp = 0xfb0448d0 > > r4 = 0xc253d7f4 r5 = 0x00000001 > > r6 = 0xc2460f8a r7 = 0xc252e478 > > kdb_backtrace() at kdb_backtrace+0x38 > > pc = 0xc21ab500 lr = 0xc216dd68 (vpanic+0x114) > > sp = 0xfb0448d8 fp = 0xfb0448f8 > > r4 = 0x00000100 > > vpanic() at vpanic+0x114 > > pc = 0xc216dd68 lr = 0xc216ddfc (kproc_shutdown) > > sp = 0xfb044900 fp = 0xfb044904 > > r4 = 0xc77fe700 r5 = 0xe778c000 > > r6 = 0x00820901 r7 = 0xa0020020 > > r8 = 0xfb044948 r9 = 0xc80cf900 > > r10 = 0xe1bb6af0 > > kproc_shutdown() at kproc_shutdown > > pc = 0xc216ddfc lr = 0xa0020020 (-0x5ffdffe0) > > sp = 0xfb04490c fp = 0xfb044978 > > r4 = 0xc216ddfc r5 = 0xfb04490c > > Unable to unwind into user mode > > KDB: enter: panic > > [ thread pid 47412 tid 100206 ] > > Stopped at $d: ldrb r15, [r15, r15, ror r15]! > > db> show all pcpu > > Current CPU: 1 > > > > cpuid = 0 > > dynamic pcpu = 0x1ea7c0 > > curthread = 0xc74ba370: pid 11 "intr56: sdhci_imx1" > > curpcb = 0xc6a32ea8 > > fpcurthread = 0xc8ff46e0: pid 47377 "sh" > > idlethread = 0xc730da50: tid 100002 "idle: cpu0" > > spin locks held: > > > > cpuid = 1 > > dynamic pcpu = 0x1f5d87c0 > > curthread = 0xc82ed000: pid 47412 "sh" > > curpcb = 0xfb044ea8 > > fpcurthread = 0xc7844370: pid 422 "syslogd" > > idlethread = 0xc730d6e0: tid 100003 "idle: cpu1" > > spin locks held: > > > > cpuid = 2 > > dynamic pcpu = 0x1f5d97c0 > > --More-- > > curthread = 0xc78f0370: pid 47411 "tblgen" > > curpcb = 0xfab4fea8 > > fpcurthread = 0xc82ed000: pid 47412 "sh" > > idlethread = 0xc730d370: tid 100004 "idle: cpu2" > > spin locks held: > > > > cpuid = 3 > > dynamic pcpu = 0x1f5da7c0 > > curthread = 0xc76b5370: pid 5 "mmcsd1: mmc/sd card" > > curpcb = 0xc6a45ea8 > > fpcurthread = 0xc7844370: pid 422 "syslogd" > > idlethread = 0xc730d000: tid 100005 "idle: cpu3" > > spin locks held: > > > > db> where 11 > > Tracing pid 11 tid 100006 td 0xc730ca50 > > uart_sab82532_class() at 0 > > pc = 0x00000000 lr = 0xc23ed380 (fork_trampoline) > > sp = 0xf2e6ee58 fp = 0x00000000 > > db> where 47377 > > Tracing pid 47377 tid 100342 td 0xc8ff46e0 > > cpu_switch() at cpu_switch+0x18 > > pc = 0xc23ed174 lr = 0xc2197774 (sched_switch+0x44c) > > sp = 0xfb4a6608 fp = 0xfb4a6638 > > Unwind failure (no registers changed) > > db> where 47412 > > Tracing pid 47412 tid 100206 td 0xc82ed000 > > db_trace_self() at db_trace_self > > pc = 0xc23d5b18 lr = 0xc2038b34 (db_stack_trace+0xf4) > > sp = 0xfb0445d0 fp = 0xfb0445e8 > > r10 = 0xc259f8cc > > db_stack_trace() at db_stack_trace+0xf4 > > pc = 0xc2038b34 lr = 0xc20384a4 (db_command+0x270) > > sp = 0xfb0445f0 fp = 0xfb044690 > > r4 = 0x00000000 r5 = 0x00000000 > > r6 = 0x00000072 > > db_command() at db_command+0x270 > > pc = 0xc20384a4 lr = 0xc2038208 (db_command_loop+0x60) > > sp = 0xfb044698 fp = 0xfb0446a8 > > r4 = 0xc241ebff r5 = 0xc24384c8 > > r6 = 0xc259f8b8 r7 = 0xfb044878 > > r8 = 0x00000000 r9 = 0xc24e8e38 > > r10 = 0xc253d7f4 > > db_command_loop() at db_command_loop+0x60 > > pc = 0xc2038208 lr = 0xc203ace4 (db_trap+0xd8) > > sp = 0xfb0446b0 fp = 0xfb0447d0 > > --More-- > > r4 = 0x00000000 r5 = 0xc259f8c4 > > r6 = 0xc253d818 > > db_trap() at db_trap+0xd8 > > pc = 0xc203ace4 lr = 0xc21abb38 (kdb_trap+0x15c) > > sp = 0xfb0447d8 fp = 0xfb0447f8 > > r4 = 0x00000000 r5 = 0x00000001 > > r6 = 0xc253d818 r7 = 0xfb044878 > > kdb_trap() at kdb_trap+0x15c > > pc = 0xc21abb38 lr = 0xc23eebc4 (undefinedinstruction+0x2c4) > > sp = 0xfb044800 fp = 0xfb044870 > > r4 = 0x00000000 r5 = 0x00000000 > > r6 = 0xc23ee850 r7 = 0xe7ffffff > > r8 = 0xc82ed000 r9 = 0xc21ab2a4 > > r10 = 0xfb044878 > > undefinedinstruction() at undefinedinstruction+0x2c4 > > pc = 0xc23eebc4 lr = 0xc23d78f0 (exception_exit) > > sp = 0xfb044878 fp = 0xfb0448d0 > > r4 = 0xc243851d r5 = 0x00000001 > > r6 = 0xc2460f8a r7 = 0xc252e478 > > r8 = 0xfb04490c r9 = 0xc25aefa4 > > --More-- > > r10 = 0xc82ed000 > > exception_exit() at exception_exit > > pc = 0xc23d78f0 lr = 0xc21ab298 (kdb_enter+0x40) > > sp = 0xfb0448c8 fp = 0xfb0448d0 > > r0 = 0xc253d804 r1 = 0x00000000 > > r2 = 0xc243d424 r3 = 0x000000aa > > r4 = 0xc243851d r5 = 0x00000001 > > r6 = 0xc2460f8a r7 = 0xc252e478 > > r8 = 0xfb04490c r9 = 0xc25aefa4 > > r10 = 0xc82ed000 r12 = 0x00000000 > > $a() at $a > > pc = 0xc21ab2a8 lr = 0xc216dd84 (vpanic+0x130) > > sp = 0xfb0448d8 fp = 0xfb0448f8 > > r4 = 0x00000100 > > vpanic() at vpanic+0x130 > > pc = 0xc216dd84 lr = 0xc216ddfc (kproc_shutdown) > > sp = 0xfb044900 fp = 0xfb044904 > > r4 = 0xc77fe700 r5 = 0xe778c000 > > r6 = 0x00820901 r7 = 0xa0020020 > > r8 = 0xfb044948 r9 = 0xc80cf900 > > --More-- > > r10 = 0xe1bb6af0 > > kproc_shutdown() at kproc_shutdown > > pc = 0xc216ddfc lr = 0xa0020020 (-0x5ffdffe0) > > sp = 0xfb04490c fp = 0xfb044978 > > r4 = 0xc216ddfc r5 = 0xfb04490c > > Unable to unwind into user mode > > db> where 422 > > Tracing pid 422 tid 100063 td 0xc7844370 > > cpu_switch() at cpu_switch+0x18 > > pc = 0xc23ed174 lr = 0xc2197774 (sched_switch+0x44c) > > sp = 0xfa902998 fp = 0xfa9029c8 > > Unwind failure (no registers changed) > > db> where 47411 > > Tracing pid 47411 tid 100075 td 0xc78f0370 > > savectx() at savectx+0x14 > > pc = 0xc23ed368 lr = 0xc23db518 ($a+0xe0) > > sp = 0xfab4fdb0 fp = 0xfab4fdf0 > > Unwind failure (no registers changed) > > db> where 5 > > Tracing pid 5 tid 100042 td 0xc76b5370 > > savectx() at savectx+0x14 > > pc = 0xc23ed368 lr = 0xc23db518 ($a+0xe0) > > sp = 0xc6a45b40 fp = 0xc6a45b80 > > Unwind failure (no registers changed) > > db> where > > Tracing pid 47412 tid 100206 td 0xc82ed000 > > db_trace_self() at db_trace_self > > pc = 0xc23d5b18 lr = 0xc2038b34 (db_stack_trace+0xf4) > > sp = 0xfb0445d0 fp = 0xfb0445e8 > > r10 = 0xc259f8cc > > db_stack_trace() at db_stack_trace+0xf4 > > pc = 0xc2038b34 lr = 0xc20384a4 (db_command+0x270) > > sp = 0xfb0445f0 fp = 0xfb044690 > > r4 = 0x00000000 r5 = 0x00000000 > > r6 = 0x00000072 > > db_command() at db_command+0x270 > > pc = 0xc20384a4 lr = 0xc2038208 (db_command_loop+0x60) > > sp = 0xfb044698 fp = 0xfb0446a8 > > r4 = 0xc241ebff r5 = 0xc24384c8 > > r6 = 0xc259f8b8 r7 = 0xfb044878 > > r8 = 0x00000000 r9 = 0xc24e8e38 > > r10 = 0xc253d7f4 > > db_command_loop() at db_command_loop+0x60 > > pc = 0xc2038208 lr = 0xc203ace4 (db_trap+0xd8) > > sp = 0xfb0446b0 fp = 0xfb0447d0 > > --More-- > > r4 = 0x00000000 r5 = 0xc259f8c4 > > r6 = 0xc253d818 > > db_trap() at db_trap+0xd8 > > pc = 0xc203ace4 lr = 0xc21abb38 (kdb_trap+0x15c) > > sp = 0xfb0447d8 fp = 0xfb0447f8 > > r4 = 0x00000000 r5 = 0x00000001 > > r6 = 0xc253d818 r7 = 0xfb044878 > > kdb_trap() at kdb_trap+0x15c > > pc = 0xc21abb38 lr = 0xc23eebc4 (undefinedinstruction+0x2c4) > > sp = 0xfb044800 fp = 0xfb044870 > > r4 = 0x00000000 r5 = 0x00000000 > > r6 = 0xc23ee850 r7 = 0xe7ffffff > > r8 = 0xc82ed000 r9 = 0xc21ab2a4 > > r10 = 0xfb044878 > > undefinedinstruction() at undefinedinstruction+0x2c4 > > pc = 0xc23eebc4 lr = 0xc23d78f0 (exception_exit) > > sp = 0xfb044878 fp = 0xfb0448d0 > > r4 = 0xc243851d r5 = 0x00000001 > > r6 = 0xc2460f8a r7 = 0xc252e478 > > r8 = 0xfb04490c r9 = 0xc25aefa4 > > --More-- > > r10 = 0xc82ed000 > > exception_exit() at exception_exit > > pc = 0xc23d78f0 lr = 0xc21ab298 (kdb_enter+0x40) > > sp = 0xfb0448c8 fp = 0xfb0448d0 > > r0 = 0xc253d804 r1 = 0x00000000 > > r2 = 0xc243d424 r3 = 0x000000aa > > r4 = 0xc243851d r5 = 0x00000001 > > r6 = 0xc2460f8a r7 = 0xc252e478 > > r8 = 0xfb04490c r9 = 0xc25aefa4 > > r10 = 0xc82ed000 r12 = 0x00000000 > > $a() at $a > > pc = 0xc21ab2a8 lr = 0xc216dd84 (vpanic+0x130) > > sp = 0xfb0448d8 fp = 0xfb0448f8 > > r4 = 0x00000100 > > vpanic() at vpanic+0x130 > > pc = 0xc216dd84 lr = 0xc216ddfc (kproc_shutdown) > > sp = 0xfb044900 fp = 0xfb044904 > > r4 = 0xc77fe700 r5 = 0xe778c000 > > r6 = 0x00820901 r7 = 0xa0020020 > > r8 = 0xfb044948 r9 = 0xc80cf900 > > --More-- > > r10 = 0xe1bb6af0 > > kproc_shutdown() at kproc_shutdown > > pc = 0xc216ddfc lr = 0xa0020020 (-0x5ffdffe0) > > sp = 0xfb04490c fp = 0xfb044978 > > r4 = 0xc216ddfc r5 = 0xfb04490c > > Unable to unwind into user mode > > db> ps > > pid ppid pgrp uid state wmesg wchan cmd > > 47515 47513 47512 0 R+ cc > > 47514 47503 47502 0 R+ cc > > 47513 47512 47512 0 S+ wait 0xc76cb640 cc > > 47512 45553 47512 0 S+ wait 0xc7d37640 sh > > 47511 47508 47506 0 R+ cc > > 47510 47507 47496 0 D+ biord 0xe1bc1830 cc > > 47509 47505 47504 0 R+ cc > > 47508 47506 47506 0 S+ wait 0xc78e3640 cc > > 47507 47501 47496 0 S+ wait 0xc78e3000 cc > > 47506 45553 47506 0 S+ wait 0xc8007000 sh > > 47505 47504 47504 0 S+ wait 0xc834e320 cc > > 47504 45553 47504 0 S+ wait 0xc834e000 sh > > 47503 47502 47502 0 S+ wait 0xc783ac80 cc > > 47502 45553 47502 0 S+ wait 0xc783a960 sh > > 47501 47496 47496 0 S+ wait 0xc8007960 sh > > 47500 47499 47498 0 R+ cc > > 47499 47498 47498 0 S+ wait 0xc7d37960 cc > > 47498 45553 47498 0 S+ wait 0xc8007320 sh > > 47496 47165 47496 0 S+ wait 0xc8007640 sh > > --More-- > > 47492 47491 47490 0 D+ ufs 0xc7ca0db4 cc > > 47491 47490 47490 0 S+ wait 0xc7d37000 cc > > 47490 46307 47490 0 S+ wait 0xc76cc320 sh > > 47485 47366 47363 0 DL+ vnread 0xe1b0b7c0 cc > > 47453 47452 47451 0 D+ ufs 0xc7ca0db4 cc > > 47452 47451 47451 0 S+ wait 0xc83e7640 cc > > 47451 46307 47451 0 S+ wait 0xc82ec640 sh > > 47428 47427 47427 0 R+ tblgen > > 47427 47393 47427 0 S+ wait 0xc83e7c80 sh > > 47412 47393 47412 0 REL+ CPU 1 sh > > 47411 47410 47410 0 R+ CPU 2 tblgen > > 47410 47393 47410 0 S+ wait 0xc82fd000 sh > > 47405 47393 47405 0 RE+ sh > > 47393 47391 47391 0 S+ select 0xc7756564 make > > 47391 41911 47391 0 S+ wait 0xc82eb960 sh > > 47377 47179 47377 0 DE+ getblk 0xe1b2ce40 sh > > 47366 47365 47363 0 S+ wait 0xc83e5000 cc > > 47365 47363 47363 0 S+ wait 0xc8f05000 sh > > 47363 46965 47363 0 S+ wait 0xc8932960 sh > > 47298 47296 47296 0 D+ ufs 0xc7ca0db4 make > > --More-- > > 47296 41911 47296 0 S+ wait 0xc7d36320 sh > > 47209 47206 47206 0 D+ ufs 0xc7ca0db4 make > > 47206 41911 47206 0 S+ wait 0xc7febc80 sh > > 47186 47185 47185 0 D+ ufs 0xc7ca0db4 make > > 47185 41911 47185 0 S+ wait 0xc7d37c80 sh > > 47179 47176 47176 0 D+ ufs 0xc7ca0db4 make > > 47176 41911 47176 0 S+ wait 0xc7f9f000 sh > > 47165 47164 47164 0 S+ select 0xc8422aa4 make > > 47164 41911 47164 0 S+ wait 0xc82ebc80 sh > > 46965 46953 46953 0 S+ select 0xc8501b24 make > > 46953 41911 46953 0 S+ wait 0xc78e2000 sh > > 46307 42746 42746 0 D+ ufs 0xc7ca0db4 make > > 45553 45537 45537 0 R+ make > > 45537 45518 45537 0 S+ wait 0xc8f00640 sh > > 45518 36706 36706 0 S+ select 0xc77357a4 make > > 42746 42715 42746 0 S+ wait 0xc7917640 sh > > 42715 36704 36704 0 S+ select 0xc7754e24 make > > 41911 41907 41907 0 D+ ufs 0xc7ca0db4 make > > 41907 39473 41907 0 S+ wait 0xc8934960 sh > > 39473 36707 36707 0 S+ select 0xc80c5f24 make > > --More-- > > 36707 36691 36707 0 S+ wait 0xc78e3960 sh > > 36706 36691 36706 0 S+ wait 0xc8008320 sh > > 36704 36691 36704 0 S+ wait 0xc7fe9960 sh > > 36691 98664 98664 0 S+ select 0xc80c54e4 make > > 31862 31845 31862 0 S+ ttyin 0xcadcc270 csh > > 31845 31803 31845 1001 S+ wait 0xc834ec80 su > > 31803 31745 31803 1001 Ss+ pause 0xc7fdace8 csh > > 31745 31700 31700 1001 S select 0xc7c837a4 sshd > > 31700 558 31700 0 Ss select 0xc80c65e4 sshd > > 98664 98651 98664 0 S+ wait 0xc8932000 sh > > 98651 98650 98650 0 S+ select 0xc8421b24 make > > 98650 642 98650 0 S+ wait 0xc83d2960 sh > > 642 641 641 0 S+ select 0xc7c83864 make > > 641 636 641 0 S+ wait 0xc7918320 sh > > 636 608 636 0 S+ select 0xc77556e4 make > > 625 624 625 0 S+ ttyin 0xc7743670 csh > > 624 622 624 1001 S+ wait 0xc7d38640 su > > 622 621 622 1001 Ss+ pause 0xc76cc6a8 csh > > 621 618 618 1001 S select 0xc77561a4 sshd > > 618 558 618 0 Ss select 0xc7755764 sshd > > --More-- > > 608 607 608 0 S+ pause 0xc79189c8 csh > > 607 1 607 0 Ss+ wait 0xc78e2960 login > > 562 1 562 0 Ss nanslp 0xc252f810 cron > > 558 1 558 0 Ss select 0xc7755664 sshd > > 528 1 528 0 Ss select 0xc7709f64 ntpd > > 455 1 455 0 Ss select 0xc73d1ae4 casperd > > 454 1 454 0 Ss select 0xc7757264 casperd > > 422 1 422 0 Ds biowr 0xe1b43980 syslogd > > 279 1 279 0 Ss select 0xc74bf064 devd > > 16 0 0 0 DL syncer 0xc259ab8c [syncer] > > 15 0 0 0 DL vlruwt 0xc76cbc80 [vnlru] > > 9 0 0 0 DL (threaded) [bufdaemon] > > 100046 D psleep 0xc259a910 [bufdaemon] > > 100055 D sdflush 0xc76c0484 [/ worker] > > 8 0 0 0 DL pgzero 0xc259da3c [pagezero] > > 7 0 0 0 DL psleep 0xc259d8cc [vmdaemon] > > 6 0 0 0 DL psleep 0xc25b2a44 [pagedaemon] > > 5 0 0 0 RL CPU 3 [mmcsd1: mmc/sd card] > > 4 0 0 0 DL jobqueue 0xc73b2b80 [mmcsd0: mmc/sd card] > > 3 0 0 0 DL waiting_ 0xc25afd8c [sctp_iterator] > > --More-- > > 14 0 0 0 DL (threaded) [usb] > > 100026 D - 0xc73eaca4 [usbus0] > > 100027 D - 0xc73eacd4 [usbus0] > > 100028 D - 0xc73ead04 [usbus0] > > 100029 D - 0xc73ead34 [usbus0] > > 100031 D - 0xc74c5ca4 [usbus1] > > 100032 D - 0xc74c5cd4 [usbus1] > > 100033 D - 0xc74c5d04 [usbus1] > > 100034 D - 0xc74c5d34 [usbus1] > > 2 0 0 0 RL (threaded) [cam] > > 100020 RunQ [doneq0] > > 100040 D - 0xc251e2a8 [scanner] > > 13 0 0 0 DL - 0xc252b120 [rand_harvestq] > > 12 0 0 0 DL (threaded) [geom] > > 100012 D - 0xc25a04e4 [g_event] > > 100013 D - 0xc25a04e8 [g_up] > > 100014 D - 0xc25a04ec [g_down] > > 11 0 0 0 RL (threaded) [intr] > > 100006 I [swi3: vm] > > 100007 I [swi1: netisr 0] > > --More-- > > 100008 I [swi4: clock (0)] > > 100009 I [swi4: clock (1)] > > 100010 I [swi4: clock (2)] > > 100011 I [swi4: clock (3)] > > 100016 I [swi6: Giant taskq] > > 100018 I [swi5: fast taskq] > > 100022 I [swi6: task queue] > > 100023 I [swi0: uart] > > 100024 I [intr150: ffec0] > > 100025 I [intr75: ehci0] > > 100030 I [intr72: ehci1] > > 100035 I [intr54: sdhci_imx0] > > 100036 Run CPU 0 [intr56: sdhci_imx1] > > 10 0 0 0 RL (threaded) [idle] > > 100002 CanRun [idle: cpu0] > > 100003 CanRun [idle: cpu1] > > 100004 CanRun [idle: cpu2] > > 100005 CanRun [idle: cpu3] > > 1 0 1 0 SLs wait 0xc730a640 [init] > > 0 0 0 0 DLs (threaded) [kernel] > > --More-- > > 100000 D swapin 0xc25a0508 [swapper] > > 100017 D - 0xc73b2380 [thread taskq] > > 100019 D - 0xc73b2280 [ffs_trim taskq] > > 100021 D - 0xc73b1f00 [kqueue taskq] > > 100037 D - 0xc252e6f1 [deadlkres] > > 100039 D - 0xc73b2200 [CAM taskq] > > db> root@devel:~ # > > > root@devel:~ # > > > Script done on Thu Nov 27 22:23:39 2014 > # > It looks like problems with the SD-Card. It is a relative new SanDisk 8 GB card speed 4. > I have some of these cards. I never had problems with them. > > Regards > > Ulrich > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@FreeBSD.ORG Fri Nov 28 03:05:33 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8BB2493D for ; Fri, 28 Nov 2014 03:05:33 +0000 (UTC) Received: from alogt.com (alogt.com [69.36.191.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6820E2C3 for ; Fri, 28 Nov 2014 03:05:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alogt.com; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=/s0tYjGQMRVdy31gMay5v46ZE97ZEQVDAYa7tVnUPVs=; b=dlW5rfaF4OeJT+PVNZ2hvqLCkDa7PYcZJkzFt8IeskHcZSeHxq5B8jnZcpA9u/hHVqmBEBbGwow6kKGWi2mhN1ZfiwNDcG18dp3MQtyWtDr+ME8ZiCUmHcGiRp0es9BLenMsumA2h1D7FxFFbiBr0jLvYZPR0pjjXt+U2ur2KuA=; Received: from [114.124.24.195] (port=45787 helo=X220.alogt.com) by sl-508-2.slc.westdc.net with esmtpa (Exim 4.84) (envelope-from ) id 1XuBsB-001LZz-Uy; Thu, 27 Nov 2014 20:05:32 -0700 Date: Fri, 28 Nov 2014 11:05:27 +0800 From: Erich Dollansky To: Eric Gunther Subject: Re: Raspberry Pi composite video problem Message-ID: <20141128110527.043a158f@X220.alogt.com> In-Reply-To: <1417094728.2530.1.camel@warwick.net> References: <1417094728.2530.1.camel@warwick.net> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sl-508-2.slc.westdc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - alogt.com X-Get-Message-Sender-Via: sl-508-2.slc.westdc.net: authenticated_id: erichsfreebsdlist@alogt.com X-Source: X-Source-Args: X-Source-Dir: Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Nov 2014 03:05:33 -0000 Hi, On Thu, 27 Nov 2014 08:25:28 -0500 Eric Gunther wrote: > input. I have an old tv with composite input and outputs, I thought I am not able to help you here. > I have enabled sshd, and set the hostname although I cannot seem to > find the RPi on the network while using Ethernet cable (Cat 5e)... Use telnet for the start to make sure that you avoided the simplest problems. You need inetd and /etc/inetd.conf with telnet enabled in there. > This is not surprising because I am novice with networking. I have > also tried telnet, although I saw elsewhere on this list that one has > to enable it. I have not found the place to do that, I looked in > loader.conf and rc.conf. > You have to enable inetd in rc.conf and telnet on /etc/inetd.conf. Erich From owner-freebsd-arm@FreeBSD.ORG Fri Nov 28 03:42:48 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6950ABDF for ; Fri, 28 Nov 2014 03:42:48 +0000 (UTC) Received: from alogt.com (alogt.com [69.36.191.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 396ED870 for ; Fri, 28 Nov 2014 03:42:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alogt.com; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=ZwrUFXweof5hJWmzeioxl0Q6xnaQLww+OlqT1QMTILw=; b=qpwe7w+oZ2KL2l2UqSSVNPuwCeTlFqug8Y0qDtdCilGnBS4zDXu9iJXmaCATj27F3wDn5T1NXDQBzl7iavJT4EtHpyso+jz4sMPjXNcC5AF8FOHUuc6Bo1k2nwAKVUaDPRLgAqgwvBYiXepJVcSP1MsQpDjV2EbOxIti5Gezv1A=; Received: from [114.124.24.195] (port=45921 helo=X220.alogt.com) by sl-508-2.slc.westdc.net with esmtpa (Exim 4.84) (envelope-from ) id 1XuBoJ-001Hyv-Ly; Thu, 27 Nov 2014 20:01:32 -0700 Date: Fri, 28 Nov 2014 11:01:25 +0800 From: Erich Dollansky To: Anton Shterenlikht Subject: Re: built xorg-server, what next? Message-ID: <20141128110125.596a598c@X220.alogt.com> In-Reply-To: <201411271035.sARAZqn5092571@mech-as221.men.bris.ac.uk> References: <201411271035.sARAZqn5092571@mech-as221.men.bris.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sl-508-2.slc.westdc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - alogt.com X-Get-Message-Sender-Via: sl-508-2.slc.westdc.net: authenticated_id: erichsfreebsdlist@alogt.com X-Source: X-Source-Args: X-Source-Dir: Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Nov 2014 03:42:48 -0000 Hi, On Thu, 27 Nov 2014 02:35:53 -0800 (PST) Anton Shterenlikht wrote: > I managed to build xorg-server-1.12.4_9,1 > on RPI-B 10.1-RELEASE, no build failures > along the way, just a couple of panics. > > I then followed: > > http://blog.cochard.me/2013/03/xorg-for-freebsd-on-raspberry-pi.html > ( Is this guide still valid?) > > and built xf86-video-scfb-0.0.4_1 > I did the normal builds just like on a x86. > On X -configure I got: I did not do this. I use an xorg.conf with this content: Section "Files" ModulePath "/usr/local/lib/xorg/modules" FontPath "/usr/local/lib/X11/fonts/misc/" FontPath "/usr/local/lib/X11/fonts/TTF/" FontPath "/usr/local/lib/X11/fonts/OTF" FontPath "/usr/local/lib/X11/fonts/Type1/" FontPath "/usr/local/lib/X11/fonts/100dpi/" FontPath "/usr/local/lib/X11/fonts/75dpi/" FontPath "/usr/local/lib/X11/fonts/dejavu/" FontPath "/usr/local/lib/X11/fonts/Droid/" FontPath "/usr/local/lib/X11/fonts/webfonts/" EndSection Section "Module" Load "dbe" Disable "dri" Disable "dri2" Disable "glx" SubSection "extmod" Option "omit xfree86-dga" EndSubSection EndSection Section "ServerFlags" Option "AIGLX" "false" Option "NoAccel" "True" Option "NoDRI" "True" Option "DRI" "False" Option "DRI2" "False" EndSection Section "InputDevice" Identifier "Keyboard1" Driver "kbd" EndSection # Section "InputDevice" Identifier "Mouse1" Driver "mouse" Option "Protocol" "auto" Option "Device" "/dev/sysmouse" EndSection Section "Monitor" Identifier "Monitor" EndSection Section "Device" Identifier "Generic FB" Driver "scfb" Option "NoAccel" "True" EndSection Section "Screen" Identifier "Screen" Device "Generic FB" Monitor "Monitor" DefaultDepth 16 SubSection "Display" Depth 16 EndSubsection EndSection Section "ServerLayout" Identifier "layout" Screen 0 "Screen" 0 0 InputDevice "Mouse1" "CorePointer" InputDevice "Keyboard1" "CoreKeyboard" EndSection Please check the output and the log file of startx for errors. > Is scfb the wrong driver for this board? I also use it. Erich From owner-freebsd-arm@FreeBSD.ORG Fri Nov 28 09:31:08 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 71136FF6; Fri, 28 Nov 2014 09:31:08 +0000 (UTC) Received: from mail-qa0-x22c.google.com (mail-qa0-x22c.google.com [IPv6:2607:f8b0:400d:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 18BCEB67; Fri, 28 Nov 2014 09:31:08 +0000 (UTC) Received: by mail-qa0-f44.google.com with SMTP id i13so4317659qae.3 for ; Fri, 28 Nov 2014 01:31:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4usI8XG4mT6RMcU9xDzvNqRCAt/aqMxaKATuw36EXzU=; b=CQDRC5XNBRNCxQ+4udc7O8bCfsKSBj4Dm2k95N8aeITEj+UjX+8x55DTuQEKjU/TI3 38Qt99gWFu2lfXUK0ui1XhiDrIoeI0HiJ9JNSBFay+mDBhTnki4hjDSc9if94lPmabPD jVTM16q1v97igMrJq0JZaJiJ90Q0Q8C1wbLhcswm/Cz6C5xivJ3xCscpqaI565FBv7or R9XYIqUjVCE08vB/yot/Kwz5Al/tLr29QorsUBqYiYKIgIo6S5Pe5hP3/XGCJxwi+5LI u2KOzh9jzZZLGokCZQs0WGi5EzHJLHU5Lpgu3nzQVsTbe+2WCK6KyUHH34wcaJURoMNO vlbw== MIME-Version: 1.0 X-Received: by 10.224.94.9 with SMTP id x9mr46687906qam.45.1417167067263; Fri, 28 Nov 2014 01:31:07 -0800 (PST) Received: by 10.140.23.242 with HTTP; Fri, 28 Nov 2014 01:31:07 -0800 (PST) In-Reply-To: <1417108193.1055.2.camel@revolution.hippie.lan> References: <20141113125236.b16cd4e5f0e339eac0494cd4@ulrich-grey.de> <20141115143444.5ad037548e06f289d2532fb7@ulrich-grey.de> <20141119225903.81fbbc7809093a0e6e0de9d5@ulrich-grey.de> <20141120151900.a68c6d8316b96a62cb65d17a@ulrich-grey.de> <20141121115941.54d4e36b103341c3adf7eb36@ulrich-grey.de> <20141124132733.4e96b906f0d1ab69969dddd9@ulrich-grey.de> <1416840814.1147.380.camel@revolution.hippie.lan> <20141125225451.924a5df4bdb4753db273b8c5@ulrich-grey.de> <20141126125806.78f2df97328e807d12746ae3@ulrich-grey.de> <519fde5db60e4fc594956a600c6cad4e@e15be-01.zdv.Uni-Mainz.DE> <1417108193.1055.2.camel@revolution.hippie.lan> Date: Fri, 28 Nov 2014 10:31:07 +0100 Message-ID: Subject: Re: Another Test Run with Alternative pmap Implementation From: Svatopluk Kraus To: Ian Lepore Content-Type: multipart/mixed; boundary=047d7b673a84a1ea8b0508e7eb2c X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Nov 2014 09:31:08 -0000 --047d7b673a84a1ea8b0508e7eb2c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I think that the pmap_remove_page warning is very likely due to not atomic PCPU_GET(). Can you please try attached patch. Svata On Thu, Nov 27, 2014 at 6:09 PM, Ian Lepore wrote: > On Wed, 2014-11-26 at 22:18 +0000, Wei=C3=9F, Dr. J=C3=BCrgen wrote: > > I made a testrun with the updated source tree and the patches for > > the jetson tk1 platform. With > > > > options ARM_NEW_PMAP > > options DEBUG > > options DIAGNOSTIC > > options INVARIANTS # Enable calls of extra sanity > checking > > options INVARIANT_SUPPORT # Extra sanity checks of > internal structures, required by INVARIAN > > > > and no special sysctl settings. > > > > A make -j6 buildworld finishes successfully after 2h15m. There is > > one kernel message > > kernel: warning: pmap_remove_pages called with non-current pmap > > > > /usr/src and /usr/obj over nfs, /tmp on tmpfs > > > > Regards > > That's similar to my results. I changed to -j20 to see if that would > recreate the problems that Ulrich is seeing, but buildworld runs fine > for me, in about 2 hours. I've never seen the non-current pmap warning > on the system that uses a usb ssd drive as root, but I've seen it with > nfs root. > > BTW, the DIAGNOSTIC option adds a LOT of performance overhead to an arm > system without adding a lot of value. I usually leave it off, sometimes > turn it on when I encounter a problem to see if it generates more info > (usually it doesn't). > > -- Ian > > > --047d7b673a84a1ea8b0508e7eb2c Content-Type: application/octet-stream; name="pmap_remove_pages.patch" Content-Disposition: attachment; filename="pmap_remove_pages.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_i31cm8ab0 LS0tIHN5cy9hcm0vYXJtL3BtYXAtdjYtbmV3LmMKKysrIHN5cy9hcm0vYXJtL3BtYXAtdjYtbmV3 LmMKQEAgLTQyODUsNyArNDI4NSw3IEBACiAJdWludDMyX3QgaW51c2UsIGJpdG1hc2s7CiAJYm9v bGVhbl90IGFsbGZyZWU7CgotCWlmIChwbWFwICE9IFBDUFVfR0VUKGN1cnBtYXApKSB7CisJaWYg KHBtYXAgIT0gdm1zcGFjZV9wbWFwKGN1cnRocmVhZC0+dGRfcHJvYy0+cF92bXNwYWNlKSkgewog CQlwcmludGYoIndhcm5pbmc6ICVzIGNhbGxlZCB3aXRoIG5vbi1jdXJyZW50IHBtYXBcbiIsIF9f ZnVuY19fKTsKIAkJcmV0dXJuOwogCX0K --047d7b673a84a1ea8b0508e7eb2c-- From owner-freebsd-arm@FreeBSD.ORG Fri Nov 28 09:43:50 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A2F1B3D1; Fri, 28 Nov 2014 09:43:50 +0000 (UTC) Received: from mail-qc0-x22c.google.com (mail-qc0-x22c.google.com [IPv6:2607:f8b0:400d:c01::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 301F1C5A; Fri, 28 Nov 2014 09:43:50 +0000 (UTC) Received: by mail-qc0-f172.google.com with SMTP id m20so4643564qcx.3 for ; Fri, 28 Nov 2014 01:43:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kOKbjTbh+bgT56cUwY0GGlwgMpUxAMsV3J0BQi9oQxQ=; b=g3IVH/Kt7HUmIYU3o4IyqGjCtWckBL7qw2IGuEwsNSirtfWmA+duZa8i4KrSvpwMeT Uice1thWVICXnE5JdzZCLNStH2yDK/ov/uN07cUIc8eTxYSH63fA8N1fOZqeNDTE5j7J rIlzYyi9F2hxZdvYwJk9qnItUYBWJfXT0TBlON42g/5G/y5nbUqPpBr/033gNFw5ciJg Xepy1m35ouDKuPlUln6y7EPDCXmnEbNnLSc3G87Rj08ow0B2TfdH7ZYRXmfpXC9/I3hM LpRKmwWB+kRn3h5eaSDgsTjApO2Ir9Bx+A46HTtN+0sTOy9meyahMoIvPsZ8a4iUBSfH iDMA== MIME-Version: 1.0 X-Received: by 10.140.38.170 with SMTP id t39mr22946483qgt.15.1417167829145; Fri, 28 Nov 2014 01:43:49 -0800 (PST) Received: by 10.140.23.242 with HTTP; Fri, 28 Nov 2014 01:43:49 -0800 (PST) In-Reply-To: <20141128001235.6591396b2f6298b861a96b57@ulrich-grey.de> References: <20141113125236.b16cd4e5f0e339eac0494cd4@ulrich-grey.de> <20141115143444.5ad037548e06f289d2532fb7@ulrich-grey.de> <20141119225903.81fbbc7809093a0e6e0de9d5@ulrich-grey.de> <20141120151900.a68c6d8316b96a62cb65d17a@ulrich-grey.de> <20141121115941.54d4e36b103341c3adf7eb36@ulrich-grey.de> <20141124132733.4e96b906f0d1ab69969dddd9@ulrich-grey.de> <1416840814.1147.380.camel@revolution.hippie.lan> <20141125225451.924a5df4bdb4753db273b8c5@ulrich-grey.de> <20141127234239.e2c40a8fb99ba41f9ec3a7e7@ulrich-grey.de> <20141128001235.6591396b2f6298b861a96b57@ulrich-grey.de> Date: Fri, 28 Nov 2014 10:43:49 +0100 Message-ID: Subject: Re: Another Test Run with Alternative pmap Implementation From: Svatopluk Kraus To: Ulrich Grey Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-arm@freebsd.org, Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Nov 2014 09:43:50 -0000 Hmm, IMO, the LOR is well known. The broken pipe likely points to a problem with SD card where your system is running. So, somehow your SD card stops working. It could be caused, in the order of likelihood, because of (1) bad SD card, (2) bad driver, (3) something else. Svata On Fri, Nov 28, 2014 at 12:12 AM, Ulrich Grey wrote: > I have found this messages in dmesg output: > > Feeding entropy:. > inm_print: --- begin inm 0xc7760300 --- > addr 224.0.0.1 ifp 0xc7698400(lo0) ifma 0xc7758d20 > timer 0 state not-member refcount 1 scq.len 0 > igi 0xc74d2d00 nsrc 0 sctimer 0 scrv 0 > t0: fmode un asm 0 ex 0 in 0 rec 0 > t1: fmode ex asm 1 ex 1 in 0 rec 0 > inm_print: --- end inm 0xc7760300 --- > inm_print: --- begin inm 0xc7760300 --- > addr 224.0.0.1 ifp 0xc7698400(lo0) ifma 0xc7758d20 > timer 0 state silent refcount 1 scq.len 0 > igi 0xc74d2d00 nsrc 0 sctimer 0 scrv 0 > t0: fmode un asm 0 ex 0 in 0 rec 0 > t1: fmode ex asm 1 ex 1 in 0 rec 0 > inm_print: --- end inm 0xc7760300 --- > in6m_print: --- begin in6m 0xc77a6300 --- > addr ff02:2::1:ff00:1 ifp 0xc7698400(lo0) ifma 0xc7758d00 > timer 0 state not-member refcount 1 scq.len 0 > mli 0xc74d2c00 nsrc 0 sctimer 0 scrv 0 > t0: fmode un asm 0 ex 0 in 0 rec 0 > t1: fmode ex asm 1 ex 1 in 0 rec 0 > in6m_print: --- end in6m 0xc77a6300 --- > in6m_print: --- begin in6m 0xc77a6300 --- > addr ff02:2::1:ff00:1 ifp 0xc7698400(lo0) ifma 0xc7758d00 > timer 0 state silent refcount 1 scq.len 0 > mli 0xc74d2c00 nsrc 0 sctimer 0 scrv 0 > t0: fmode un asm 0 ex 0 in 0 rec 0 > t1: fmode ex asm 1 ex 1 in 0 rec 0 > in6m_print: --- end in6m 0xc77a6300 --- > in6m_print: --- begin in6m 0xc77a6200 --- > addr ff02:2::1 ifp 0xc7698400(lo0) ifma 0xc7758cc0 > timer 0 state not-member refcount 1 scq.len 0 > mli 0xc74d2c00 nsrc 0 sctimer 0 scrv 0 > t0: fmode un asm 0 ex 0 in 0 rec 0 > t1: fmode ex asm 1 ex 1 in 0 rec 0 > in6m_print: --- end in6m 0xc77a6200 --- > in6m_print: --- begin in6m 0xc77a6200 --- > addr ff02:2::1 ifp 0xc7698400(lo0) ifma 0xc7758cc0 > timer 0 state silent refcount 1 scq.len 0 > mli 0xc74d2c00 nsrc 0 sctimer 0 scrv 0 > t0: fmode un asm 0 ex 0 in 0 rec 0 > t1: fmode ex asm 1 ex 1 in 0 rec 0 > in6m_print: --- end in6m 0xc77a6200 --- > in6m_print: --- begin in6m 0xc77a6100 --- > addr ff02:2::2:ffeb:aec2 ifp 0xc7698400(lo0) ifma 0xc7758c80 > timer 0 state not-member refcount 1 scq.len 0 > mli 0xc74d2c00 nsrc 0 sctimer 0 scrv 0 > t0: fmode un asm 0 ex 0 in 0 rec 0 > t1: fmode ex asm 1 ex 1 in 0 rec 0 > in6m_print: --- end in6m 0xc77a6100 --- > in6m_print: --- begin in6m 0xc77a6100 --- > addr ff02:2::2:ffeb:aec2 ifp 0xc7698400(lo0) ifma 0xc7758c80 > timer 0 state silent refcount 1 scq.len 0 > mli 0xc74d2c00 nsrc 0 sctimer 0 scrv 0 > t0: fmode un asm 0 ex 0 in 0 rec 0 > t1: fmode ex asm 1 ex 1 in 0 rec 0 > in6m_print: --- end in6m 0xc77a6100 --- > in6m_print: --- begin in6m 0xc77a6000 --- > addr ff02:2::2:ebae:c2ef ifp 0xc7698400(lo0) ifma 0xc7758c40 > timer 0 state not-member refcount 1 scq.len 0 > mli 0xc74d2c00 nsrc 0 sctimer 0 scrv 0 > t0: fmode un asm 0 ex 0 in 0 rec 0 > t1: fmode ex asm 1 ex 1 in 0 rec 0 > in6m_print: --- end in6m 0xc77a6000 --- > in6m_print: --- begin in6m 0xc77a6000 --- > addr ff02:2::2:ebae:c2ef ifp 0xc7698400(lo0) ifma 0xc7758c40 > timer 0 state silent refcount 1 scq.len 0 > mli 0xc74d2c00 nsrc 0 sctimer 0 scrv 0 > t0: fmode un asm 0 ex 0 in 0 rec 0 > t1: fmode ex asm 1 ex 1 in 0 rec 0 > in6m_print: --- end in6m 0xc77a6000 --- > in6m_print: --- begin in6m 0xc77a5e00 --- > addr ff01:2::1 ifp 0xc7698400(lo0) ifma 0xc7758c00 > timer 0 state not-member refcount 1 scq.len 0 > mli 0xc74d2c00 nsrc 0 sctimer 0 scrv 0 > t0: fmode un asm 0 ex 0 in 0 rec 0 > t1: fmode ex asm 1 ex 1 in 0 rec 0 > in6m_print: --- end in6m 0xc77a5e00 --- > in6m_print: --- begin in6m 0xc77a5e00 --- > addr ff01:2::1 ifp 0xc7698400(lo0) ifma 0xc7758c00 > timer 0 state silent refcount 1 scq.len 0 > mli 0xc74d2c00 nsrc 0 sctimer 0 scrv 0 > t0: fmode un asm 0 ex 0 in 0 rec 0 > t1: fmode ex asm 1 ex 1 in 0 rec 0 > in6m_print: --- end in6m 0xc77a5e00 --- > in6m_print: --- begin in6m 0xc77a6300 --- > addr ff02:2::1:ff00:1 ifp 0xc7698400(lo0) ifma 0xc7758d00 > timer 0 state silent refcount 2 scq.len 0 > mli 0xc74d2c00 nsrc 0 sctimer 0 scrv 0 > t0: fmode ex asm 1 ex 1 in 0 rec 0 > t1: fmode ex asm 2 ex 2 in 0 rec 0 > in6m_print: --- end in6m 0xc77a6300 --- > in6m_print: --- begin in6m 0xc77a6300 --- > addr ff02:2::1:ff00:1 ifp 0xc7698400(lo0) ifma 0xc7758d00 > timer 0 state silent refcount 2 scq.len 0 > mli 0xc74d2c00 nsrc 0 sctimer 0 scrv 0 > t0: fmode ex asm 1 ex 1 in 0 rec 0 > t1: fmode ex asm 2 ex 2 in 0 rec 0 > in6m_print: --- end in6m 0xc77a6300 --- > in6m_print: --- begin in6m 0xc77a6200 --- > addr ff02:2::1 ifp 0xc7698400(lo0) ifma 0xc7758cc0 > timer 0 state silent refcount 2 scq.len 0 > mli 0xc74d2c00 nsrc 0 sctimer 0 scrv 0 > t0: fmode ex asm 1 ex 1 in 0 rec 0 > t1: fmode ex asm 2 ex 2 in 0 rec 0 > in6m_print: --- end in6m 0xc77a6200 --- > in6m_print: --- begin in6m 0xc77a6200 --- > addr ff02:2::1 ifp 0xc7698400(lo0) ifma 0xc7758cc0 > timer 0 state silent refcount 2 scq.len 0 > mli 0xc74d2c00 nsrc 0 sctimer 0 scrv 0 > t0: fmode ex asm 1 ex 1 in 0 rec 0 > t1: fmode ex asm 2 ex 2 in 0 rec 0 > in6m_print: --- end in6m 0xc77a6200 --- > in6m_print: --- begin in6m 0xc77a6100 --- > addr ff02:2::2:ffeb:aec2 ifp 0xc7698400(lo0) ifma 0xc7758c80 > timer 0 state silent refcount 2 scq.len 0 > mli 0xc74d2c00 nsrc 0 sctimer 0 scrv 0 > t0: fmode ex asm 1 ex 1 in 0 rec 0 > t1: fmode ex asm 2 ex 2 in 0 rec 0 > in6m_print: --- end in6m 0xc77a6100 --- > in6m_print: --- begin in6m 0xc77a6100 --- > addr ff02:2::2:ffeb:aec2 ifp 0xc7698400(lo0) ifma 0xc7758c80 > timer 0 state silent refcount 2 scq.len 0 > mli 0xc74d2c00 nsrc 0 sctimer 0 scrv 0 > t0: fmode ex asm 1 ex 1 in 0 rec 0 > t1: fmode ex asm 2 ex 2 in 0 rec 0 > in6m_print: --- end in6m 0xc77a6100 --- > in6m_print: --- begin in6m 0xc77a6000 --- > addr ff02:2::2:ebae:c2ef ifp 0xc7698400(lo0) ifma 0xc7758c40 > timer 0 state silent refcount 2 scq.len 0 > mli 0xc74d2c00 nsrc 0 sctimer 0 scrv 0 > t0: fmode ex asm 1 ex 1 in 0 rec 0 > t1: fmode ex asm 2 ex 2 in 0 rec 0 > in6m_print: --- end in6m 0xc77a6000 --- > in6m_print: --- begin in6m 0xc77a6000 --- > addr ff02:2::2:ebae:c2ef ifp 0xc7698400(lo0) ifma 0xc7758c40 > timer 0 state silent refcount 2 scq.len 0 > mli 0xc74d2c00 nsrc 0 sctimer 0 scrv 0 > t0: fmode ex asm 1 ex 1 in 0 rec 0 > t1: fmode ex asm 2 ex 2 in 0 rec 0 > in6m_print: --- end in6m 0xc77a6000 --- > in6m_print: --- begin in6m 0xc77a5e00 --- > addr ff01:2::1 ifp 0xc7698400(lo0) ifma 0xc7758c00 > timer 0 state silent refcount 2 scq.len 0 > mli 0xc74d2c00 nsrc 0 sctimer 0 scrv 0 > t0: fmode ex asm 1 ex 1 in 0 rec 0 > t1: fmode ex asm 2 ex 2 in 0 rec 0 > in6m_print: --- end in6m 0xc77a5e00 --- > in6m_print: --- begin in6m 0xc77a5e00 --- > addr ff01:2::1 ifp 0xc7698400(lo0) ifma 0xc7758c00 > timer 0 state silent refcount 2 scq.len 0 > mli 0xc74d2c00 nsrc 0 sctimer 0 scrv 0 > t0: fmode ex asm 1 ex 1 in 0 rec 0 > t1: fmode ex asm 2 ex 2 in 0 rec 0 > in6m_print: --- end in6m 0xc77a5e00 --- > inm_print: --- begin inm 0xc7703b80 --- > addr 224.0.0.1 ifp 0xc7408400(ffec0) ifma 0xc7758d40 > timer 0 state not-member refcount 1 scq.len 0 > igi 0xc74d2f00 nsrc 0 sctimer 0 scrv 0 > t0: fmode un asm 0 ex 0 in 0 rec 0 > t1: fmode ex asm 1 ex 1 in 0 rec 0 > inm_print: --- end inm 0xc7703b80 --- > inm_print: --- begin inm 0xc7703b80 --- > addr 224.0.0.1 ifp 0xc7408400(ffec0) ifma 0xc7758d40 > timer 0 state silent refcount 1 scq.len 0 > igi 0xc74d2f00 nsrc 0 sctimer 0 scrv 0 > t0: fmode un asm 0 ex 0 in 0 rec 0 > t1: fmode ex asm 1 ex 1 in 0 rec 0 > inm_print: --- end inm 0xc7703b80 --- > Starting Network: lo0 ffec0. > lo0: flags=8049 metric 0 mtu 16384 > options=600003 > inet 127.0.0.1 netmask 0xff000000 > inet6 ::1 prefixlen 128 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 > groups: lo > nd6 options=21 > ffec0: flags=8843 metric 0 mtu 1500 > options=80008 > ether 00:1f:7b:b4:10:71 > inet 192.168.0.200 netmask 0xffffff00 broadcast 192.168.0.255 > media: Ethernet autoselect (none) > status: no carrier > nd6 options=29 > Starting devd. > Starting pflogd: > add net default: gateway 192.168.0.155 > Additional inet routing options: ignore ICMP redirect=YES log ICMP > redirect=YES. > add net fe80::: gateway ::1 > add net ff02::: gateway ::1 > add net ::ffff:0.0.0.0: gateway ::1 > add net ::0.0.0.0: gateway ::1 > Creating and/or trimming log files. > Starting syslogd. > No core dumps found. > ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib > /usr/local/lib/qt4 > Starting casperd. > Clearing /tmp. > Starting dbus. > Failed to start message bus: Could not get UID and GID for username > "messagebus" > /etc/rc: WARNING: failed to start dbus > Updating motd:. > Mounting late file systems:. > Starting ntpd. > Performing sanity check on sshd configuration. > Starting sshd. > Starting cron. > Starting background file system checks in 60 seconds. > > Thu Nov 27 15:17:36 UTC 2014 > Nov 27 15:17:41 quad login: ROOT LOGIN (root) ON ttyu0 > lock order reversal: > 1st 0xe1b3a820 bufwait (bufwait) > @ /usr/local/DEVEL/STREJDA/freebsd/sys/kern/vfs_bio.c:3093 2nd 0xc774dc00 > dirhash > (dirhash) @ /usr/local/DEVEL/STREJDA/freebsd/sys/ufs/ufs/ufs_dirhash.c:285 > KDB: stack > backtrace: db_trace_self() at db_trace_self > pc = 0xc23d5b18 lr = 0xc203abb0 (db_trace_self_wrapper+0x30) > sp = 0xfab4f988 fp = 0xfab4faa0 > r10 = 0xc774dc00 > db_trace_self_wrapper() at db_trace_self_wrapper+0x30 > pc = 0xc203abb0 lr = 0xc21ab500 (kdb_backtrace+0x38) > sp = 0xfab4faa8 fp = 0xfab4fab0 > r4 = 0xc253d7f4 r5 = 0xc242ca32 > r6 = 0xc24630d3 r7 = 0xc256f074 > kdb_backtrace() at kdb_backtrace+0x38 > pc = 0xc21ab500 lr = 0xc21c7908 (witness_checkorder+0xe5c) > sp = 0xfab4fab8 fp = 0xfab4fb08 > r4 = 0xc246349d > witness_checkorder() at witness_checkorder+0xe5c > pc = 0xc21c7908 lr = 0xc2175758 (_sx_xlock+0x7c) > sp = 0xfab4fb10 fp = 0xfab4fb50 > r4 = 0x0000011d r5 = 0xc24630d0 > r6 = 0xc774dc10 r7 = 0xc774dc00 > r8 = 0x00000000 r9 = 0xc78a0a80 > r10 = 0x00000000 > _sx_xlock() at _sx_xlock+0x7c > pc = 0xc2175758 lr = 0xc238e31c (ufsdirhash_remove+0x3c) > sp = 0xfab4fb58 fp = 0xfab4fb70 > r4 = 0xc774dc00 r5 = 0xc7cae48c > r6 = 0xe235c018 r7 = 0xc78a0a80 > r8 = 0x00000018 > ufsdirhash_remove() at ufsdirhash_remove+0x3c > pc = 0xc238e31c lr = 0xc2391400 (ufs_dirremove+0x14c) > sp = 0xfab4fb78 fp = 0xfab4fba8 > r4 = 0xc78a0a00 r5 = 0xc7cae48c > r6 = 0xc7cae480 r7 = 0xe235c018 > r8 = 0x00000000 > ufs_dirremove() at ufs_dirremove+0x14c > pc = 0xc2391400 lr = 0xc2397934 (ufs_remove+0x70) > sp = 0xfab4fbb0 fp = 0xfab4fbd8 > r4 = 0xc7cae360 r5 = 0x00000001 > r6 = 0xfab4fd50 r7 = 0xc78a0a00 > r8 = 0xc7cae480 r9 = 0xc78f0370 > r10 = 0x00000000 > ufs_remove() at ufs_remove+0x70 > pc = 0xc2397934 lr = 0xc240048c (VOP_REMOVE_APV+0x100) > sp = 0xfab4fbe0 fp = 0xfab4fc08 > r4 = 0xfab4fd50 r5 = 0xc2515bc4 > r6 = 0x00000000 r7 = 0xc247089d > r8 = 0x00000000 r9 = 0xc7cae360 > VOP_REMOVE_APV() at VOP_REMOVE_APV+0x100 > pc = 0xc240048c lr = 0xc2225aa4 (kern_unlinkat+0x1b4) > sp = 0xfab4fc10 fp = 0xfab4fd80 > r4 = 0xfab4fcb0 r5 = 0xc78f0370 > r6 = 0x2081e3d8 r7 = 0xffffff9c > kern_unlinkat() at kern_unlinkat+0x1b4 > pc = 0xc2225aa4 lr = 0xc22258e8 (sys_unlink+0x24) > sp = 0xfab4fd88 fp = 0xfab4fd90 > r4 = 0xc78f0370 r5 = 0xc78e2640 > r6 = 0x00000000 r7 = 0x00000008 > r8 = 0xfab4fe08 r9 = 0xfab4fe00 > r10 = 0x00000000 > sys_unlink() at sys_unlink+0x24 > pc = 0xc22258e8 lr = 0xc23ed828 (swi_handler+0x2cc) > sp = 0xfab4fd98 fp = 0xfab4fe50 > swi_handler() at swi_handler+0x2cc > pc = 0xc23ed828 lr = 0xc23d7888 (swi_exit) > sp = 0xfab4fe58 fp = 0xbfbffd00 > r4 = 0x20803080 r5 = 0x0000a4de > r6 = 0x00000000 r7 = 0x0000000a > r8 = 0x00000001 r9 = 0x00000000 > r10 = 0x000127a0 > swi_exit() at swi_exit > pc = 0xc23d7888 lr = 0xc23d7888 (swi_exit) > sp = 0xfab4fe58 fp = 0xbfbffd00 > Nov 27 15:20:25 quad su: gwgpi to root on /dev/pts/0 > lock order reversal: > 1st 0xc7ca0db4 ufs (ufs) @ > /usr/local/DEVEL/STREJDA/freebsd/sys/kern/vfs_subr.c:2144 > 2nd 0xe1b30560 bufwait (bufwait) > @ /usr/local/DEVEL/STREJDA/freebsd/sys/ufs/ffs/ffs_vnops.c:263 3rd > 0xc8039274 ufs (ufs) > @ /usr/local/DEVEL/STREJDA/freebsd/sys/kern/vfs_subr.c:2144 KDB: stack > backtrace: > db_trace_self() at db_trace_self > pc = 0xc23d5b18 lr = 0xc203abb0 (db_trace_self_wrapper+0x30) > sp = 0xfab89370 fp = 0xfab89488 > r10 = 0xc8039274 > db_trace_self_wrapper() at db_trace_self_wrapper+0x30 > pc = 0xc203abb0 lr = 0xc21ab500 (kdb_backtrace+0x38) > sp = 0xfab89490 fp = 0xfab89498 > r4 = 0xc253d7f4 r5 = 0xc242ca32 > r6 = 0xc244a3e6 r7 = 0xc256ed4c > kdb_backtrace() at kdb_backtrace+0x38 > pc = 0xc21ab500 lr = 0xc21c7908 (witness_checkorder+0xe5c) > sp = 0xfab894a0 fp = 0xfab894f0 > r4 = 0xc242d235 > witness_checkorder() at witness_checkorder+0xe5c > pc = 0xc21c7908 lr = 0xc214f12c (__lockmgr_args+0xb54) > sp = 0xfab894f8 fp = 0xfab89570 > r4 = 0xc8039274 r5 = 0x00000000 > r6 = 0x00080100 r7 = 0xc24ff8b0 > r8 = 0xc8039294 r9 = 0x00000100 > r10 = 0xc244a3e3 > __lockmgr_args() at __lockmgr_args+0xb54 > pc = 0xc214f12c lr = 0xc23888d8 (ffs_lock+0x80) > sp = 0xfab89578 fp = 0xfab895a0 > r4 = 0xfab895d8 r5 = 0x00080100 > r6 = 0xc8039240 r7 = 0xc8039274 > r8 = 0xc8039294 r9 = 0x00000000 > r10 = 0x00000860 > ffs_lock() at ffs_lock+0x80 > pc = 0xc23888d8 lr = 0xc2401434 (VOP_LOCK1_APV+0x108) > sp = 0xfab895a8 fp = 0xfab895d0 > r4 = 0xfab895d8 r5 = 0xc2515648 > r6 = 0x00000000 r7 = 0xc2471004 > r8 = 0xfab895d8 r9 = 0xc2462064 > VOP_LOCK1_APV() at VOP_LOCK1_APV+0x108 > pc = 0xc2401434 lr = 0xc222aff4 (_vn_lock+0x44) > sp = 0xfab895d8 fp = 0xfab89608 > r4 = 0xc8039240 r5 = 0x0001d1f3 > r6 = 0xc244a3e3 r7 = 0x00080100 > _vn_lock() at _vn_lock+0x44 > pc = 0xc222aff4 lr = 0xc221bf88 (vget+0x90) > sp = 0xfab89610 fp = 0xfab89648 > r4 = 0xc8039240 r5 = 0x0001d1f3 > r6 = 0x00080100 r7 = 0xc259aa6c > r8 = 0xc78e4000 r9 = 0xc2462064 > r10 = 0x00000000 > vget() at vget+0x90 > pc = 0xc221bf88 lr = 0xc220fcf8 (vfs_hash_get+0xd8) > sp = 0xfab89650 fp = 0xfab89680 > r4 = 0xc259aa50 r5 = 0x0001d1f3 > r6 = 0xc77f32b0 r7 = 0xc259aa6c > r8 = 0xc8039240 r9 = 0xc24494b9 > vfs_hash_get() at vfs_hash_get+0xd8 > pc = 0xc220fcf8 lr = 0xc2383ad4 (ffs_vgetf+0x38) > sp = 0xfab89688 fp = 0xfab896e0 > r4 = 0xc77fe700 r5 = 0x00080000 > r6 = 0xc77f32b0 r7 = 0x0001d1f3 > r8 = 0xc7737000 r9 = 0xc245ed7c > r10 = 0xfab89748 > ffs_vgetf() at ffs_vgetf+0x38 > pc = 0xc2383ad4 lr = 0xc237ae0c (softdep_sync_buf+0xad4) > sp = 0xfab896e8 fp = 0xfab89768 > r4 = 0xc77fe700 r5 = 0x0001d1f3 > r6 = 0x00000000 r7 = 0x0000088d > r8 = 0xc7737000 r9 = 0xc245ed7c > r10 = 0xc7ca6d34 > softdep_sync_buf() at softdep_sync_buf+0xad4 > pc = 0xc237ae0c lr = 0xc23895a8 (ffs_syncvnode+0x2e0) > sp = 0xfab89770 fp = 0xfab897c0 > r4 = 0xc7ca0d80 r5 = 0x00000000 > r6 = 0xc2462b7d r7 = 0x00000001 > r8 = 0xe1b30560 r9 = 0xe1b30510 > r10 = 0x00000010 > ffs_syncvnode() at ffs_syncvnode+0x2e0 > pc = 0xc23895a8 lr = 0xc235e378 (ffs_truncate+0x6d0) > sp = 0xfab897c8 fp = 0xfab89978 > r4 = 0xc7ca0d80 r5 = 0x00000000 > r6 = 0x00000200 r7 = 0xc78d8900 > r8 = 0x00000880 r9 = 0x00000000 > r10 = 0x00000200 > ffs_truncate() at ffs_truncate+0x6d0 > pc = 0xc235e378 lr = 0xc2391124 (ufs_direnter+0x88c) > sp = 0xfab89980 fp = 0xfab899e8 > r4 = 0xc7ca0d80 r5 = 0xc78d8900 > r6 = 0x00000000 r7 = 0x00000000 > r8 = 0xc8039240 r9 = 0xc7ca0d80 > r10 = 0x00000000 > ufs_direnter() at ufs_direnter+0x88c > pc = 0xc2391124 lr = 0xc239a37c (ufs_makeinode+0x3e8) > sp = 0xfab899f0 fp = 0xfab89b50 > r4 = 0x00000000 r5 = 0xfab89d08 > r6 = 0xfab89a10 r7 = 0x00000000 > r8 = 0xfab89d20 r9 = 0xc7ca0d80 > r10 = 0xc7f3e280 > ufs_makeinode() at ufs_makeinode+0x3e8 > pc = 0xc239a37c lr = 0xc239682c (ufs_create+0x24) > sp = 0xfab89b58 fp = 0xfab89b58 > r4 = 0xfab89c40 r5 = 0xc2515bc4 > r6 = 0x00000000 r7 = 0xc246faa8 > r8 = 0xfab89d28 r9 = 0x00000000 > r10 = 0x00000000 > ufs_create() at ufs_create+0x24 > pc = 0xc239682c lr = 0xc23fe9cc (VOP_CREATE_APV+0xfc) > sp = 0xfab89b60 fp = 0xfab89b88 > VOP_CREATE_APV() at VOP_CREATE_APV+0xfc > pc = 0xc23fe9cc lr = 0xc222a898 (vn_open_cred+0x208) > sp = 0xfab89b90 fp = 0xfab89c70 > r4 = 0xfab89cb8 r5 = 0xfab89d08 > r6 = 0x00000800 r7 = 0x00000a03 > vn_open_cred() at vn_open_cred+0x208 > pc = 0xc222a898 lr = 0xc222a688 (vn_open+0x24) > sp = 0xfab89c78 fp = 0xfab89c80 > r4 = 0xc78e4000 r5 = 0x000500cf > r6 = 0x00000012 r7 = 0xfab89cb8 > r8 = 0x00000000 r9 = 0xbfbfe0ac > r10 = 0xfab89ca8 > vn_open() at vn_open+0x24 > pc = 0xc222a688 lr = 0xc22247d4 (kern_openat+0x248) > sp = 0xfab89c88 fp = 0xfab89d80 > kern_openat() at kern_openat+0x248 > pc = 0xc22247d4 lr = 0xc2224584 (sys_open+0x28) > sp = 0xfab89d88 fp = 0xfab89d90 > r4 = 0xc78e4000 r5 = 0xc78e1640 > r6 = 0x00000000 r7 = 0x00000180 > r8 = 0xfab89e08 r9 = 0xfab89e00 > r10 = 0x00000000 > sys_open() at sys_open+0x28 > pc = 0xc2224584 lr = 0xc23ed828 (swi_handler+0x2cc) > sp = 0xfab89d98 fp = 0xfab89e50 > swi_handler() at swi_handler+0x2cc > pc = 0xc23ed828 lr = 0xc23d7888 (swi_exit) > sp = 0xfab89e58 fp = 0xbfbfe090 > r4 = 0x00000000 r5 = 0xbfbfe09c > r6 = 0xbfbfe0ac r7 = 0x00000005 > r8 = 0x00000000 r9 = 0xbfbfe0b5 > r10 = 0x00000011 > swi_exit() at swi_exit > pc = 0xc23d7888 lr = 0xc23d7888 (swi_exit) > sp = 0xfab89e58 fp = 0xbfbfe090 > Nov 27 16:00:14 syslogd: /dev/console: Interrupted system call > Expensive timeout(9) function: 0xc2074fb4(0xc74c5c78) 0.002307912 s > Expensive timeout(9) function: 0xc23fbfd4(0xc73e6000) 0.002396580 s > Nov 27 19:00:26 syslogd: /dev/console: Interrupted system call > root@quad:/usr/home/gwgpi # Write failed: Broken pipe > osx-mini:~ mac$ > > Ulrich > ----------------------------------- > On Thu, 27 Nov 2014 23:42:39 +0100 > Ulrich Grey wrote: > > > hello, > > > > on advice from Svatopluk Kraus I additionally compiled these debugging > options into the > > kernel: > > > > options KTR > > options KTR_MASK=KTR_ALL > > options KTR_ENTRIES=65536 > > > > I did my crashtest. The system crashes after some hours, I could not do > anything on > > another terminal. > > > > cc -fpic -DPIC -O -pipe > > > -I/usr/local/DEVEL/STREJDA/freebsd/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi > > > -I/usr/local/DEVEL/STREJDA/freebsd/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi/krb5 > > > -I/usr/local/DEVEL/STREJDA/freebsd/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi/gssapi > > > -I/usr/local/DEVEL/STREJDA/freebsd/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/krb5 > > > -I/usr/local/DEVEL/STREJDA/freebsd/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/asn1 > > > -I/usr/local/DEVEL/STREJDA/freebsd/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/roken > > -I. -DHAVE_CONFIG_H > > > -I/usr/local/DEVEL/STREJDA/freebsd/kerberos5/lib/libgssapi_krb5/../../include > > -std=gnu99 -Qunused-arguments > > -c > /usr/local/DEVEL/STREJDA/freebsd/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi/krb5/inquire_cred_by_oid.c > > -o inquire_cred_by_oid.So > > > > mmcsd1: Error indicated: 1 Timeout > > > > sdhci_immmxc1-sslot0:d 1G:ot dEata rinterrruopt r0 xi0n0d0i0c0a0t10,e > db:u t1 > > tThiemreeo uits > > no active command. > > > > sdhci_imx1-slot0: ============== REGISTER DUMP ============== > > > > sdhci_imx1-slot0: Sys addr: 0x00000000 | Version: 0x00000002 > > > > sdhci_imx1-slot0: Blk size: 0x00000200 | Blk cnt: 0x00000040 > > > > sdhci_imx1-slot0: Argument: 0x001dffc0 | Trn mode: 0x00000026 > > > > sdhci_imx1-slot0: Present: 0x00fd0000 | Host ctl: 0x00000003 > > > > sdhci_imx1-slot0: Power: 0x0000000d | Blk gap: 0x00000080 > > > > sdhci_imx1-slot0: Wake-up: 0x00000000 | Clock: 0x00000207 > > > > sdhci_imx1-slot0: Timeout: 0x0000000d | Int stat: 0x00000000 > > > > sdhci_imx1-slot0: Int enab: 0x017f00fb | Sig enab: 0x017f00fb > > > > sdhci_imx1-slot0: AC12 err: 0x00000000 | Slot int: 0x00000000 > > > > sdhci_imx1-slot0: Caps: 0x0377c800 | Max curr: 0x80000026 > > > > sdhci_imx1-slot0: =========================================== > > > > g_vfs_done():mmcsd1s2a[WRITE(offset=945684480, length=32768)]error = 5 > > > > g_vfs_done():mmcsd1s2a[WRITE(offset=945717248, length=32768)]error = 5 > > > > sdhci_imx1-slot0: Got data interrupt 0x00000010, but there is no active > command. > > > > sdhci_imx1-slot0: ============== REGISTER DUMP ============== > > > > sdhci_imx1-slot0: Sys addr: 0x00000000 | Version: 0x00000002 > > > > sdhci_imx1-slot0: Blk size: 0x00000200 | Blk cnt: m m0cxs0d010:0 0E0r0r8o > > r > > sidnhdciic_aitmexd1:- s1l oTti0m:e oAurtg > > u > > ment: 0x0030e9f8 | Trn mode: 0x00000026 > > > > sdhci_imx1-slot0: Present: 0x00fd0000 | Host ctl: 0x00000003 > > > > sdhci_imx1-slot0: Power: 0x0000000d | Blk gap: 0x00000080 > > > > sdhci_imx1-slot0: Wake-up: 0x00000000 | Clock: 0x00000207 > > > > sdhci_imx1-slot0: Timeout: 0x0000000d | Int stat: 0x00000000 > > > > sdhci_imx1-slot0: Int enab: 0x017f00fb | Sig enab: 0x017f00fb > > > > sdhci_imx1-slot0: AC12 err: 0x00000000 | Slot int: 0x00000000 > > > > sdhci_imx1-slot0: Caps: 0x0377c800 | Max curr: 0x80000026 > > > > sdhci_imx1-slot0: =========================================== > > > > g_vfs_done():mmcsd1s2a[WRITE(offset=1580396544, length=4096)]error = 5 > > > > sdhci_imx1-slot0: Got data interrupt 0x00000010, but there is no active > command. > > > > sdhci_imx1-slot0: ============== REGISTER DUMP ============== > > > > sdhci_imx1-slot0: Sys addr: 0x00000000 | Version: 0x00000002 > > > > sdhci_imx1-slot0: Blk size: 0x00000200 | Blk cnt: 0x00000008 > > > > sdhci_imx1-slot0: Argument: 0x0030e9f8 | Trn mode: 0x00000026 > > > > sdhci_imx1-slot0: Present: 0x00fd0000 | Host ctl: 0x00000003 > > > > sdhci_imx1-slot0: Power: 0x0000000d | Blk gap: 0x00000080 > > > > sdhci_imx1-slot0: Wake-up: 0x00000000 | Clock: 0x00000207 > > > > sdhci_imx1-slot0: Timeout: 0x0000000d | Int stat: 0x00000000 > > > > sdhci_imx1-slot0: Int enab: 0x017f00fb | Sig enab: 0x017f00fb > > > > sdhci_imx1-slot0: AC12 err: 0x00000000 | Slot int: 0x00000000 > > > > sdhci_imx1-slot0: Caps: 0x0377c800 | Max curr: 0x80000026 > > > > sdhci_imx1-slot0: =========================================== > > > > mmcsd1: Error indicated: 1 Timeout > > > > g_vfs_done():mmcsd1s2a[WRITE(offset=1580396544, length=4096)]error = 5 > > > > sdhcmim_cismdx11:- sElrorto0r: iGnodti cdaattead :i n1t eTrirmuepotu t0 > > x > > 00000010, but there is no active command. > > > > sdhci_imx1-slot0: ============== REGISTEpanic: > initiate_write_inodeblock_ufs2: already > > started > > > > cpuid = 1 > > > > KDB: stack backtrace: > > > > db_trace_self() at db_trace_self > > > > pc = 0xc23d5b18 lr = 0xc203abb0 (db_trace_self_wrapper+0x30) > > > > sp = 0xfb0447a8 fp = 0xfb0448c0 > > > > r10 = 0xc82ed000 > > > > db_trace_self_wrapper() at db_trace_self_wrapper+0x30 > > > > pc = 0xc203abb0 lr = 0xc21ab500 (kdb_backtrace+0x38) > > > > sp = 0xfb0448c8 fp = 0xfb0448d0 > > > > r4 = 0xc253d7f4 r5 = 0x00000001 > > > > r6 = 0xc2460f8a r7 = 0xc252e478 > > > > kdb_backtrace() at kdb_backtrace+0x38 > > > > pc = 0xc21ab500 lr = 0xc216dd68 (vpanic+0x114) > > > > sp = 0xfb0448d8 fp = 0xfb0448f8 > > > > r4 = 0x00000100 > > > > vpanic() at vpanic+0x114 > > > > pc = 0xc216dd68 lr = 0xc216ddfc (kproc_shutdown) > > > > sp = 0xfb044900 fp = 0xfb044904 > > > > r4 = 0xc77fe700 r5 = 0xe778c000 > > > > r6 = 0x00820901 r7 = 0xa0020020 > > > > r8 = 0xfb044948 r9 = 0xc80cf900 > > > > r10 = 0xe1bb6af0 > > > > kproc_shutdown() at kproc_shutdown > > > > pc = 0xc216ddfc lr = 0xa0020020 (-0x5ffdffe0) > > > > sp = 0xfb04490c fp = 0xfb044978 > > > > r4 = 0xc216ddfc r5 = 0xfb04490c > > > > Unable to unwind into user mode > > > > KDB: enter: panic > > > > [ thread pid 47412 tid 100206 ] > > > > Stopped at $d: ldrb r15, [r15, r15, ror r15]! > > > > db> show all pcpu > > > > Current CPU: 1 > > > > > > > > cpuid = 0 > > > > dynamic pcpu = 0x1ea7c0 > > > > curthread = 0xc74ba370: pid 11 "intr56: sdhci_imx1" > > > > curpcb = 0xc6a32ea8 > > > > fpcurthread = 0xc8ff46e0: pid 47377 "sh" > > > > idlethread = 0xc730da50: tid 100002 "idle: cpu0" > > > > spin locks held: > > > > > > > > cpuid = 1 > > > > dynamic pcpu = 0x1f5d87c0 > > > > curthread = 0xc82ed000: pid 47412 "sh" > > > > curpcb = 0xfb044ea8 > > > > fpcurthread = 0xc7844370: pid 422 "syslogd" > > > > idlethread = 0xc730d6e0: tid 100003 "idle: cpu1" > > > > spin locks held: > > > > > > > > cpuid = 2 > > > > dynamic pcpu = 0x1f5d97c0 > > > > --More-- > > > > curthread = 0xc78f0370: pid 47411 "tblgen" > > > > curpcb = 0xfab4fea8 > > > > fpcurthread = 0xc82ed000: pid 47412 "sh" > > > > idlethread = 0xc730d370: tid 100004 "idle: cpu2" > > > > spin locks held: > > > > > > > > cpuid = 3 > > > > dynamic pcpu = 0x1f5da7c0 > > > > curthread = 0xc76b5370: pid 5 "mmcsd1: mmc/sd card" > > > > curpcb = 0xc6a45ea8 > > > > fpcurthread = 0xc7844370: pid 422 "syslogd" > > > > idlethread = 0xc730d000: tid 100005 "idle: cpu3" > > > > spin locks held: > > > > > > > > db> where 11 > > > > Tracing pid 11 tid 100006 td 0xc730ca50 > > > > uart_sab82532_class() at 0 > > > > pc = 0x00000000 lr = 0xc23ed380 (fork_trampoline) > > > > sp = 0xf2e6ee58 fp = 0x00000000 > > > > db> where 47377 > > > > Tracing pid 47377 tid 100342 td 0xc8ff46e0 > > > > cpu_switch() at cpu_switch+0x18 > > > > pc = 0xc23ed174 lr = 0xc2197774 (sched_switch+0x44c) > > > > sp = 0xfb4a6608 fp = 0xfb4a6638 > > > > Unwind failure (no registers changed) > > > > db> where 47412 > > > > Tracing pid 47412 tid 100206 td 0xc82ed000 > > > > db_trace_self() at db_trace_self > > > > pc = 0xc23d5b18 lr = 0xc2038b34 (db_stack_trace+0xf4) > > > > sp = 0xfb0445d0 fp = 0xfb0445e8 > > > > r10 = 0xc259f8cc > > > > db_stack_trace() at db_stack_trace+0xf4 > > > > pc = 0xc2038b34 lr = 0xc20384a4 (db_command+0x270) > > > > sp = 0xfb0445f0 fp = 0xfb044690 > > > > r4 = 0x00000000 r5 = 0x00000000 > > > > r6 = 0x00000072 > > > > db_command() at db_command+0x270 > > > > pc = 0xc20384a4 lr = 0xc2038208 (db_command_loop+0x60) > > > > sp = 0xfb044698 fp = 0xfb0446a8 > > > > r4 = 0xc241ebff r5 = 0xc24384c8 > > > > r6 = 0xc259f8b8 r7 = 0xfb044878 > > > > r8 = 0x00000000 r9 = 0xc24e8e38 > > > > r10 = 0xc253d7f4 > > > > db_command_loop() at db_command_loop+0x60 > > > > pc = 0xc2038208 lr = 0xc203ace4 (db_trap+0xd8) > > > > sp = 0xfb0446b0 fp = 0xfb0447d0 > > > > --More-- > > > > r4 = 0x00000000 r5 = 0xc259f8c4 > > > > r6 = 0xc253d818 > > > > db_trap() at db_trap+0xd8 > > > > pc = 0xc203ace4 lr = 0xc21abb38 (kdb_trap+0x15c) > > > > sp = 0xfb0447d8 fp = 0xfb0447f8 > > > > r4 = 0x00000000 r5 = 0x00000001 > > > > r6 = 0xc253d818 r7 = 0xfb044878 > > > > kdb_trap() at kdb_trap+0x15c > > > > pc = 0xc21abb38 lr = 0xc23eebc4 (undefinedinstruction+0x2c4) > > > > sp = 0xfb044800 fp = 0xfb044870 > > > > r4 = 0x00000000 r5 = 0x00000000 > > > > r6 = 0xc23ee850 r7 = 0xe7ffffff > > > > r8 = 0xc82ed000 r9 = 0xc21ab2a4 > > > > r10 = 0xfb044878 > > > > undefinedinstruction() at undefinedinstruction+0x2c4 > > > > pc = 0xc23eebc4 lr = 0xc23d78f0 (exception_exit) > > > > sp = 0xfb044878 fp = 0xfb0448d0 > > > > r4 = 0xc243851d r5 = 0x00000001 > > > > r6 = 0xc2460f8a r7 = 0xc252e478 > > > > r8 = 0xfb04490c r9 = 0xc25aefa4 > > > > --More-- > > > > r10 = 0xc82ed000 > > > > exception_exit() at exception_exit > > > > pc = 0xc23d78f0 lr = 0xc21ab298 (kdb_enter+0x40) > > > > sp = 0xfb0448c8 fp = 0xfb0448d0 > > > > r0 = 0xc253d804 r1 = 0x00000000 > > > > r2 = 0xc243d424 r3 = 0x000000aa > > > > r4 = 0xc243851d r5 = 0x00000001 > > > > r6 = 0xc2460f8a r7 = 0xc252e478 > > > > r8 = 0xfb04490c r9 = 0xc25aefa4 > > > > r10 = 0xc82ed000 r12 = 0x00000000 > > > > $a() at $a > > > > pc = 0xc21ab2a8 lr = 0xc216dd84 (vpanic+0x130) > > > > sp = 0xfb0448d8 fp = 0xfb0448f8 > > > > r4 = 0x00000100 > > > > vpanic() at vpanic+0x130 > > > > pc = 0xc216dd84 lr = 0xc216ddfc (kproc_shutdown) > > > > sp = 0xfb044900 fp = 0xfb044904 > > > > r4 = 0xc77fe700 r5 = 0xe778c000 > > > > r6 = 0x00820901 r7 = 0xa0020020 > > > > r8 = 0xfb044948 r9 = 0xc80cf900 > > > > --More-- > > > > r10 = 0xe1bb6af0 > > > > kproc_shutdown() at kproc_shutdown > > > > pc = 0xc216ddfc lr = 0xa0020020 (-0x5ffdffe0) > > > > sp = 0xfb04490c fp = 0xfb044978 > > > > r4 = 0xc216ddfc r5 = 0xfb04490c > > > > Unable to unwind into user mode > > > > db> where 422 > > > > Tracing pid 422 tid 100063 td 0xc7844370 > > > > cpu_switch() at cpu_switch+0x18 > > > > pc = 0xc23ed174 lr = 0xc2197774 (sched_switch+0x44c) > > > > sp = 0xfa902998 fp = 0xfa9029c8 > > > > Unwind failure (no registers changed) > > > > db> where 47411 > > > > Tracing pid 47411 tid 100075 td 0xc78f0370 > > > > savectx() at savectx+0x14 > > > > pc = 0xc23ed368 lr = 0xc23db518 ($a+0xe0) > > > > sp = 0xfab4fdb0 fp = 0xfab4fdf0 > > > > Unwind failure (no registers changed) > > > > db> where 5 > > > > Tracing pid 5 tid 100042 td 0xc76b5370 > > > > savectx() at savectx+0x14 > > > > pc = 0xc23ed368 lr = 0xc23db518 ($a+0xe0) > > > > sp = 0xc6a45b40 fp = 0xc6a45b80 > > > > Unwind failure (no registers changed) > > > > db> where > > > > Tracing pid 47412 tid 100206 td 0xc82ed000 > > > > db_trace_self() at db_trace_self > > > > pc = 0xc23d5b18 lr = 0xc2038b34 (db_stack_trace+0xf4) > > > > sp = 0xfb0445d0 fp = 0xfb0445e8 > > > > r10 = 0xc259f8cc > > > > db_stack_trace() at db_stack_trace+0xf4 > > > > pc = 0xc2038b34 lr = 0xc20384a4 (db_command+0x270) > > > > sp = 0xfb0445f0 fp = 0xfb044690 > > > > r4 = 0x00000000 r5 = 0x00000000 > > > > r6 = 0x00000072 > > > > db_command() at db_command+0x270 > > > > pc = 0xc20384a4 lr = 0xc2038208 (db_command_loop+0x60) > > > > sp = 0xfb044698 fp = 0xfb0446a8 > > > > r4 = 0xc241ebff r5 = 0xc24384c8 > > > > r6 = 0xc259f8b8 r7 = 0xfb044878 > > > > r8 = 0x00000000 r9 = 0xc24e8e38 > > > > r10 = 0xc253d7f4 > > > > db_command_loop() at db_command_loop+0x60 > > > > pc = 0xc2038208 lr = 0xc203ace4 (db_trap+0xd8) > > > > sp = 0xfb0446b0 fp = 0xfb0447d0 > > > > --More-- > > > > r4 = 0x00000000 r5 = 0xc259f8c4 > > > > r6 = 0xc253d818 > > > > db_trap() at db_trap+0xd8 > > > > pc = 0xc203ace4 lr = 0xc21abb38 (kdb_trap+0x15c) > > > > sp = 0xfb0447d8 fp = 0xfb0447f8 > > > > r4 = 0x00000000 r5 = 0x00000001 > > > > r6 = 0xc253d818 r7 = 0xfb044878 > > > > kdb_trap() at kdb_trap+0x15c > > > > pc = 0xc21abb38 lr = 0xc23eebc4 (undefinedinstruction+0x2c4) > > > > sp = 0xfb044800 fp = 0xfb044870 > > > > r4 = 0x00000000 r5 = 0x00000000 > > > > r6 = 0xc23ee850 r7 = 0xe7ffffff > > > > r8 = 0xc82ed000 r9 = 0xc21ab2a4 > > > > r10 = 0xfb044878 > > > > undefinedinstruction() at undefinedinstruction+0x2c4 > > > > pc = 0xc23eebc4 lr = 0xc23d78f0 (exception_exit) > > > > sp = 0xfb044878 fp = 0xfb0448d0 > > > > r4 = 0xc243851d r5 = 0x00000001 > > > > r6 = 0xc2460f8a r7 = 0xc252e478 > > > > r8 = 0xfb04490c r9 = 0xc25aefa4 > > > > --More-- > > > > r10 = 0xc82ed000 > > > > exception_exit() at exception_exit > > > > pc = 0xc23d78f0 lr = 0xc21ab298 (kdb_enter+0x40) > > > > sp = 0xfb0448c8 fp = 0xfb0448d0 > > > > r0 = 0xc253d804 r1 = 0x00000000 > > > > r2 = 0xc243d424 r3 = 0x000000aa > > > > r4 = 0xc243851d r5 = 0x00000001 > > > > r6 = 0xc2460f8a r7 = 0xc252e478 > > > > r8 = 0xfb04490c r9 = 0xc25aefa4 > > > > r10 = 0xc82ed000 r12 = 0x00000000 > > > > $a() at $a > > > > pc = 0xc21ab2a8 lr = 0xc216dd84 (vpanic+0x130) > > > > sp = 0xfb0448d8 fp = 0xfb0448f8 > > > > r4 = 0x00000100 > > > > vpanic() at vpanic+0x130 > > > > pc = 0xc216dd84 lr = 0xc216ddfc (kproc_shutdown) > > > > sp = 0xfb044900 fp = 0xfb044904 > > > > r4 = 0xc77fe700 r5 = 0xe778c000 > > > > r6 = 0x00820901 r7 = 0xa0020020 > > > > r8 = 0xfb044948 r9 = 0xc80cf900 > > > > --More-- > > > > r10 = 0xe1bb6af0 > > > > kproc_shutdown() at kproc_shutdown > > > > pc = 0xc216ddfc lr = 0xa0020020 (-0x5ffdffe0) > > > > sp = 0xfb04490c fp = 0xfb044978 > > > > r4 = 0xc216ddfc r5 = 0xfb04490c > > > > Unable to unwind into user mode > > > > db> ps > > > > pid ppid pgrp uid state wmesg wchan cmd > > > > 47515 47513 47512 0 R+ cc > > > > 47514 47503 47502 0 R+ cc > > > > 47513 47512 47512 0 S+ wait 0xc76cb640 cc > > > > 47512 45553 47512 0 S+ wait 0xc7d37640 sh > > > > 47511 47508 47506 0 R+ cc > > > > 47510 47507 47496 0 D+ biord 0xe1bc1830 cc > > > > 47509 47505 47504 0 R+ cc > > > > 47508 47506 47506 0 S+ wait 0xc78e3640 cc > > > > 47507 47501 47496 0 S+ wait 0xc78e3000 cc > > > > 47506 45553 47506 0 S+ wait 0xc8007000 sh > > > > 47505 47504 47504 0 S+ wait 0xc834e320 cc > > > > 47504 45553 47504 0 S+ wait 0xc834e000 sh > > > > 47503 47502 47502 0 S+ wait 0xc783ac80 cc > > > > 47502 45553 47502 0 S+ wait 0xc783a960 sh > > > > 47501 47496 47496 0 S+ wait 0xc8007960 sh > > > > 47500 47499 47498 0 R+ cc > > > > 47499 47498 47498 0 S+ wait 0xc7d37960 cc > > > > 47498 45553 47498 0 S+ wait 0xc8007320 sh > > > > 47496 47165 47496 0 S+ wait 0xc8007640 sh > > > > --More-- > > > > 47492 47491 47490 0 D+ ufs 0xc7ca0db4 cc > > > > 47491 47490 47490 0 S+ wait 0xc7d37000 cc > > > > 47490 46307 47490 0 S+ wait 0xc76cc320 sh > > > > 47485 47366 47363 0 DL+ vnread 0xe1b0b7c0 cc > > > > 47453 47452 47451 0 D+ ufs 0xc7ca0db4 cc > > > > 47452 47451 47451 0 S+ wait 0xc83e7640 cc > > > > 47451 46307 47451 0 S+ wait 0xc82ec640 sh > > > > 47428 47427 47427 0 R+ tblgen > > > > 47427 47393 47427 0 S+ wait 0xc83e7c80 sh > > > > 47412 47393 47412 0 REL+ CPU 1 sh > > > > 47411 47410 47410 0 R+ CPU 2 tblgen > > > > 47410 47393 47410 0 S+ wait 0xc82fd000 sh > > > > 47405 47393 47405 0 RE+ sh > > > > 47393 47391 47391 0 S+ select 0xc7756564 make > > > > 47391 41911 47391 0 S+ wait 0xc82eb960 sh > > > > 47377 47179 47377 0 DE+ getblk 0xe1b2ce40 sh > > > > 47366 47365 47363 0 S+ wait 0xc83e5000 cc > > > > 47365 47363 47363 0 S+ wait 0xc8f05000 sh > > > > 47363 46965 47363 0 S+ wait 0xc8932960 sh > > > > 47298 47296 47296 0 D+ ufs 0xc7ca0db4 make > > > > --More-- > > > > 47296 41911 47296 0 S+ wait 0xc7d36320 sh > > > > 47209 47206 47206 0 D+ ufs 0xc7ca0db4 make > > > > 47206 41911 47206 0 S+ wait 0xc7febc80 sh > > > > 47186 47185 47185 0 D+ ufs 0xc7ca0db4 make > > > > 47185 41911 47185 0 S+ wait 0xc7d37c80 sh > > > > 47179 47176 47176 0 D+ ufs 0xc7ca0db4 make > > > > 47176 41911 47176 0 S+ wait 0xc7f9f000 sh > > > > 47165 47164 47164 0 S+ select 0xc8422aa4 make > > > > 47164 41911 47164 0 S+ wait 0xc82ebc80 sh > > > > 46965 46953 46953 0 S+ select 0xc8501b24 make > > > > 46953 41911 46953 0 S+ wait 0xc78e2000 sh > > > > 46307 42746 42746 0 D+ ufs 0xc7ca0db4 make > > > > 45553 45537 45537 0 R+ make > > > > 45537 45518 45537 0 S+ wait 0xc8f00640 sh > > > > 45518 36706 36706 0 S+ select 0xc77357a4 make > > > > 42746 42715 42746 0 S+ wait 0xc7917640 sh > > > > 42715 36704 36704 0 S+ select 0xc7754e24 make > > > > 41911 41907 41907 0 D+ ufs 0xc7ca0db4 make > > > > 41907 39473 41907 0 S+ wait 0xc8934960 sh > > > > 39473 36707 36707 0 S+ select 0xc80c5f24 make > > > > --More-- > > > > 36707 36691 36707 0 S+ wait 0xc78e3960 sh > > > > 36706 36691 36706 0 S+ wait 0xc8008320 sh > > > > 36704 36691 36704 0 S+ wait 0xc7fe9960 sh > > > > 36691 98664 98664 0 S+ select 0xc80c54e4 make > > > > 31862 31845 31862 0 S+ ttyin 0xcadcc270 csh > > > > 31845 31803 31845 1001 S+ wait 0xc834ec80 su > > > > 31803 31745 31803 1001 Ss+ pause 0xc7fdace8 csh > > > > 31745 31700 31700 1001 S select 0xc7c837a4 sshd > > > > 31700 558 31700 0 Ss select 0xc80c65e4 sshd > > > > 98664 98651 98664 0 S+ wait 0xc8932000 sh > > > > 98651 98650 98650 0 S+ select 0xc8421b24 make > > > > 98650 642 98650 0 S+ wait 0xc83d2960 sh > > > > 642 641 641 0 S+ select 0xc7c83864 make > > > > 641 636 641 0 S+ wait 0xc7918320 sh > > > > 636 608 636 0 S+ select 0xc77556e4 make > > > > 625 624 625 0 S+ ttyin 0xc7743670 csh > > > > 624 622 624 1001 S+ wait 0xc7d38640 su > > > > 622 621 622 1001 Ss+ pause 0xc76cc6a8 csh > > > > 621 618 618 1001 S select 0xc77561a4 sshd > > > > 618 558 618 0 Ss select 0xc7755764 sshd > > > > --More-- > > > > 608 607 608 0 S+ pause 0xc79189c8 csh > > > > 607 1 607 0 Ss+ wait 0xc78e2960 login > > > > 562 1 562 0 Ss nanslp 0xc252f810 cron > > > > 558 1 558 0 Ss select 0xc7755664 sshd > > > > 528 1 528 0 Ss select 0xc7709f64 ntpd > > > > 455 1 455 0 Ss select 0xc73d1ae4 casperd > > > > 454 1 454 0 Ss select 0xc7757264 casperd > > > > 422 1 422 0 Ds biowr 0xe1b43980 syslogd > > > > 279 1 279 0 Ss select 0xc74bf064 devd > > > > 16 0 0 0 DL syncer 0xc259ab8c [syncer] > > > > 15 0 0 0 DL vlruwt 0xc76cbc80 [vnlru] > > > > 9 0 0 0 DL (threaded) [bufdaemon] > > > > 100046 D psleep 0xc259a910 [bufdaemon] > > > > 100055 D sdflush 0xc76c0484 [/ worker] > > > > 8 0 0 0 DL pgzero 0xc259da3c [pagezero] > > > > 7 0 0 0 DL psleep 0xc259d8cc [vmdaemon] > > > > 6 0 0 0 DL psleep 0xc25b2a44 [pagedaemon] > > > > 5 0 0 0 RL CPU 3 [mmcsd1: mmc/sd > card] > > > > 4 0 0 0 DL jobqueue 0xc73b2b80 [mmcsd0: mmc/sd > card] > > > > 3 0 0 0 DL waiting_ 0xc25afd8c [sctp_iterator] > > > > --More-- > > > > 14 0 0 0 DL (threaded) [usb] > > > > 100026 D - 0xc73eaca4 [usbus0] > > > > 100027 D - 0xc73eacd4 [usbus0] > > > > 100028 D - 0xc73ead04 [usbus0] > > > > 100029 D - 0xc73ead34 [usbus0] > > > > 100031 D - 0xc74c5ca4 [usbus1] > > > > 100032 D - 0xc74c5cd4 [usbus1] > > > > 100033 D - 0xc74c5d04 [usbus1] > > > > 100034 D - 0xc74c5d34 [usbus1] > > > > 2 0 0 0 RL (threaded) [cam] > > > > 100020 RunQ [doneq0] > > > > 100040 D - 0xc251e2a8 [scanner] > > > > 13 0 0 0 DL - 0xc252b120 [rand_harvestq] > > > > 12 0 0 0 DL (threaded) [geom] > > > > 100012 D - 0xc25a04e4 [g_event] > > > > 100013 D - 0xc25a04e8 [g_up] > > > > 100014 D - 0xc25a04ec [g_down] > > > > 11 0 0 0 RL (threaded) [intr] > > > > 100006 I [swi3: vm] > > > > 100007 I [swi1: netisr 0] > > > > --More-- > > > > 100008 I [swi4: clock (0)] > > > > 100009 I [swi4: clock (1)] > > > > 100010 I [swi4: clock (2)] > > > > 100011 I [swi4: clock (3)] > > > > 100016 I [swi6: Giant taskq] > > > > 100018 I [swi5: fast taskq] > > > > 100022 I [swi6: task queue] > > > > 100023 I [swi0: uart] > > > > 100024 I [intr150: ffec0] > > > > 100025 I [intr75: ehci0] > > > > 100030 I [intr72: ehci1] > > > > 100035 I [intr54: sdhci_imx0] > > > > 100036 Run CPU 0 [intr56: sdhci_imx1] > > > > 10 0 0 0 RL (threaded) [idle] > > > > 100002 CanRun [idle: cpu0] > > > > 100003 CanRun [idle: cpu1] > > > > 100004 CanRun [idle: cpu2] > > > > 100005 CanRun [idle: cpu3] > > > > 1 0 1 0 SLs wait 0xc730a640 [init] > > > > 0 0 0 0 DLs (threaded) [kernel] > > > > --More-- > > > > 100000 D swapin 0xc25a0508 [swapper] > > > > 100017 D - 0xc73b2380 [thread taskq] > > > > 100019 D - 0xc73b2280 [ffs_trim taskq] > > > > 100021 D - 0xc73b1f00 [kqueue taskq] > > > > 100037 D - 0xc252e6f1 [deadlkres] > > > > 100039 D - 0xc73b2200 [CAM taskq] > > > > db> root@devel:~ # > > > > > > root@devel:~ # > > > > > > Script done on Thu Nov 27 22:23:39 2014 > > # > > It looks like problems with the SD-Card. It is a relative new SanDisk 8 > GB card speed 4. > > I have some of these cards. I never had problems with them. > > > > Regards > > > > Ulrich > > _______________________________________________ > > freebsd-arm@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > From owner-freebsd-arm@FreeBSD.ORG Fri Nov 28 09:44:47 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D8A45441 for ; Fri, 28 Nov 2014 09:44:47 +0000 (UTC) Received: from frontend1.warwick.net (mail.warwick.net [204.255.24.102]) by mx1.freebsd.org (Postfix) with SMTP id 8F083C6E for ; Fri, 28 Nov 2014 09:44:46 +0000 (UTC) Received: (qmail 13079 invoked from network); 28 Nov 2014 09:44:45 -0000 Received: from 70.44.113.83.res-cmts.sefg.ptd.net (HELO 70.44.113.83.res-cmts.sefg.ptd.net) (egunther@warwick.net@70.44.113.83) by frontend1.warwick.net with SMTP (2f3d6606-76e3-11e4-9d09-001e0b616b8e); Fri, 28 Nov 2014 04:44:45 -0500 Message-ID: <1417167767.23507.2.camel@warwick.net> Subject: Re: Raspberry Pi composite video problem From: Eric Gunther To: freebsd-arm@freebsd.org Content-Type: text/plain; charset="UTF-8" Date: Fri, 28 Nov 2014 04:42:47 -0500 Mime-Version: 1.0 X-Mailer: Evolution 3.12.7 Content-Transfer-Encoding: 7bit X-MagicMail-UUID: 2f3d6606-76e3-11e4-9d09-001e0b616b8e X-MagicMail-Authenticated: egunther@warwick.net X-MagicMail-SourceIP: 70.44.113.83 X-MagicMail-EnvelopeFrom: X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Nov 2014 09:44:47 -0000 Hi, On Thu, 27 Nov 2014 08:25:28 -0500 Eric Gunther wrote: > input. I have an old tv with composite input and outputs, I thought I am not able to help you here. So, would the firmware update change the display/console/terminal size? As I had mentioned I tried config.txt which I think is the standard on the Raspberry Pi as far as display configuration. It appears to me that maybe I have to configure the syscons, vt or other driver or facility. This I have investigated although come up empty. vidcontrol -i mode yields one entry repeated multiple times, which is not listed in the man page for vidcontrol, as far as I can tell. > I have enabled sshd, and set the hostname although I cannot seem to > find the RPi on the network while using Ethernet cable (Cat 5e)... Use telnet for the start to make sure that you avoided the simplest problems. You need inetd and /etc/inetd.conf with telnet enabled in there. I have enabled telnet in /etc/inetd.conf and enabled inetd in /etc/rc.conf by adding the entry, ' inetd_enable="YES" ' to the file at the bottom. > This is not surprising because I am novice with networking. I have > also tried telnet, although I saw elsewhere on this list that one has > to enable it. I have not found the place to do that, I looked in > loader.conf and rc.conf. > You have to enable inetd in rc.conf and telnet on /etc/inetd.conf. I have also used bsdconfig to check the services, looks fine. service -e, returns inetd enabled but no telnetd... also sshd which I enabled previously. when I try to run telnetd (service telnetd start) I get that it is not in /etc/rc.d/(telnetd) or that it is not in /usr/local/libexec/ (telnetd). telnetd is in /usr/libexec/,but it appears that something is not looking there for it. Same thing when I try telnetd -debug. Thanks, ---e Erich From owner-freebsd-arm@FreeBSD.ORG Fri Nov 28 09:57:37 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C60B7651; Fri, 28 Nov 2014 09:57:37 +0000 (UTC) Received: from mail-qc0-x235.google.com (mail-qc0-x235.google.com [IPv6:2607:f8b0:400d:c01::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 73AECD6F; Fri, 28 Nov 2014 09:57:37 +0000 (UTC) Received: by mail-qc0-f181.google.com with SMTP id m20so4647473qcx.12 for ; Fri, 28 Nov 2014 01:57:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=urxtfqZllQ/jrAARoHcMejVC0ABXUiDQIOrL3wg3MfY=; b=ZmC0v8EH/iLKzm84AjfJbr717rIbuqxb2imXoJaTQ7mNQBjPSjKwEgptChOVnLsZk2 UeOFx7tK/Y39+xe8g+ZFH6IFwBazRQCqtnJg1LqYAGLtUxaUt+ijiPzYQBHzqofqpP0C qdo5SurZBlqLj73GCs8dnRGQYSBK0ItK/i69h0VD4ehnuxKv7sJ1mm+Fd9ByLIXRy8TL k97RSVDkmi90vEjE7Pl1S/s8VqkNa59JOphzRUIlbBgx/JtKIUOQWpHGCfBqU8XMnrH1 SwF4ukv1sQvW0iSckiOxwKMunqXXmyciu9LgL9nbGfZpcyMmCdpeekJzTvfAesqVRpSr Ll7w== MIME-Version: 1.0 X-Received: by 10.140.94.233 with SMTP id g96mr61043741qge.77.1417168656671; Fri, 28 Nov 2014 01:57:36 -0800 (PST) Received: by 10.140.23.242 with HTTP; Fri, 28 Nov 2014 01:57:36 -0800 (PST) In-Reply-To: References: <20141113125236.b16cd4e5f0e339eac0494cd4@ulrich-grey.de> <20141115143444.5ad037548e06f289d2532fb7@ulrich-grey.de> <20141119225903.81fbbc7809093a0e6e0de9d5@ulrich-grey.de> <20141120151900.a68c6d8316b96a62cb65d17a@ulrich-grey.de> <20141121115941.54d4e36b103341c3adf7eb36@ulrich-grey.de> <20141124132733.4e96b906f0d1ab69969dddd9@ulrich-grey.de> <1416840814.1147.380.camel@revolution.hippie.lan> Date: Fri, 28 Nov 2014 10:57:36 +0100 Message-ID: Subject: Re: Test Run with Alternative pmap Implementation From: Svatopluk Kraus To: Zbigniew Bodek Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-arm@freebsd.org" , Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Nov 2014 09:57:38 -0000 On Mon, Nov 24, 2014 at 4:17 PM, Zbigniew Bodek wrote: > 2014-11-24 15:53 GMT+01:00 Ian Lepore : > > On Mon, 2014-11-24 at 13:27 +0100, Ulrich Grey wrote: > >> Hello, > >> > >> as a starting point I have build an image (crochet, wandboard-quad) with > >> the source tree from here (751adfd(master)): > >> > >> https://github.com/strejda/freebsd > >> > >> Then I build the kernel with new pmap and rebuild the whole systen. > >> The system I used for the test run is entirely build on the > >> wandboard-quad. > >> [...] > > > > I've also been testing those pmap changes this weekend. The only change > > I made was to add options ARM_NEW_PMAP and NKPT2PG=64 to the kernel > > config. In particular, I did not change VM_MEMATTR_UNCACHEABLE (so that > > in effect I'm also testing the recent busdma changes). > > > > I've had two wandboard quads doing builds continuously all weekend. I > > did the builds that have previously been reported as problems here -- > > buildworld -j10, ports libX11, plus a lot of other ports including much > > of the full xorg (until it ran into some x86 device drivers and died), > > some of libreoffice (it had a problem that wasn't related to crashing or > > anything), python, bash, emacs, boost, rsync. > > > > After all that I just set both boards to continuously doing "rm > > -rf /usr/obj/* ; make -j5 buildworld" in a loop, and they're still > > running. One is using an SSD drive and the other is using NFS. > > > > In all that building all weekend the only glitches I've seen are this: > > > > warning: pmap_remove_pages called with non-current pmap > > > > that appeared twice on the board using NFS root. > > > > For anyone else wanting to test, there is currently one conflict when > > applying the patches, in busdma_machdep-v6.c, because some of the > > changes in the patch have already been applied. Just resolve the > > conflict by skipping that file / restoring the original unpatched file. > > > > This stuff is looking really good. It wouldn't hurt at all if some more > > people were testing it, especially on other hardware including rpi and > > beaglebone. > > > > Hello, > > This new pmap implementation looks VERY good indeed. > However I was not able to boot this kernel on Armada XP and currently > I don't have time to debug this. > On the other hand after e-mails with crash reports on Wandbord I did > similar (buildworld, port build) tests on AXP and it didn't crash. > In particular it survived 2 days of buildworld in loop. > I wonder, what is the functional difference between AXP and other that > prevents those crashes. > > Well, if you wonder, maybe if we try to make the new pmap running on Armada XP, then we will known something more about that. Where does the boot stop? Any log? Our contribution is not only about new pmap. There are changes related to cache operation, startup code, AP startup code, and more. Svata > Ian, are you planning to replace the pmap with the new implementation? > > Best regards > zbb > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > From owner-freebsd-arm@FreeBSD.ORG Fri Nov 28 12:05:18 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 06B59B36 for ; Fri, 28 Nov 2014 12:05:18 +0000 (UTC) Received: from nm7-vm8.bullet.mail.ir2.yahoo.com (nm7-vm8.bullet.mail.ir2.yahoo.com [212.82.96.133]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4D448DF7 for ; Fri, 28 Nov 2014 12:05:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.no; s=s2048; t=1417176313; bh=nF8QxBGi3wyTDrKcbXCN8jB9c9R5mjHaf0gpyrzbXVs=; h=Date:From:Reply-To:To:Subject:From:Subject; b=sh9MJx8sNxIWyxWWQP6fdD2Zw3afyFWU7UFv/pRxgUwh1nw1ziLMSiuAyzYI/K9k/SVtCWx3IcWUP0qBFU9LFTLJuGbsVk/5ONOLzu2RBcoMNHrUUV1hxSWD1LCXDyLZayI8djtY9AboJ5QV2gxB0RY7L6QL0s16TOX8hjZ5jKCazBMpoHuAGydG/fr3/FiPirdel3HWbWe7lpiqr5B/XFPVouHfMITHZZOwUMP7bor4mkSZaJw3v1tjcJukDfofNg7cMENsu/CE1S6RViEqGBjcR0nr9Fiq+aLjQA+e7oWn93h23oUv/6MUaigZk0B0qP9wlUOKl9sE9A1i62b8uQ== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=yahoo.no; b=rChaiJ0JVzpKGLgHWXumX2arlK5/LyY09PkGWWpTm2rf2rVCxn98LkYuBmgad9T9WvF1PnEXCVWpdA67xpPTb75N2Ad2jCub7oJ9p27uK5c0XDdKSE+tN+XL2+TdDANbAUSHBuUhk4coaqCZO8S28kIeqcbwtNm97jWLsLZsrTmLkXIYM4GQLWl5FfLN6P9+u9G+ZiZ+qdb/fuhKXegs0wNliTz7MmDgaFy2/oHNl0KUjg1h8h7G0OiB/LBZQDzwbepENfBZ+Bw3YZrTo+TBCNEBrOH73aRon80xAPREw+I++NatHVKxyjAFX94giKm//511Y0o23JnXLMvHAgUk5A==; Received: from [212.82.98.126] by nm7.bullet.mail.ir2.yahoo.com with NNFMP; 28 Nov 2014 12:05:13 -0000 Received: from [212.82.98.84] by tm19.bullet.mail.ir2.yahoo.com with NNFMP; 28 Nov 2014 12:05:13 -0000 Received: from [127.0.0.1] by omp1021.mail.ir2.yahoo.com with NNFMP; 28 Nov 2014 12:05:13 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 726906.55157.bm@omp1021.mail.ir2.yahoo.com X-YMail-OSG: Hig3ZYEVM1l73o6r3Si70g_xY8G54Z62xfJXGSXNiw4fwmDWyeSCbrbLrkC0GJs 6739iuDYNHVm_VK9293QPF45L2NLWagK2AR8TiAdxbFuY8e5SFrvELiKw8qSMFIGOBHHqhnbZFJG ewqXsCC6B5WxnR2Wu5PuTUW7.tR23SO_RVMShkbdOQqkFzkrEs.2RMq31qhGkr3npcUrDcZbwjMM j77TrGqpVwo4QBhx8xaQPeG0NaRPljcM..F3dPTsmvrCCiQ5_nFlBzPqt9dHX7e4UZJO_OLQvW5l depVgoOn60KTiZqDYtFWHeb0t_tiNcSUi5s4EHL0nCkQwznI53FHfouIRzkgW_v0gzU2wwy2N_Vj y4GqXUO8pDMkH9IoX.jfEPnEH9577nrGM7cdkDtvEgO0YyuFUWnkAKlQwCaMr85s8nco3.hZlXjl m_s_BLqmx8x2DtCq_Xu3r5pYUMUYMq.98Q3SHxVuF30ufoMgbsaV87SrOUlLKZKyrCA-- Received: by 212.82.98.117; Fri, 28 Nov 2014 12:05:13 +0000 Date: Fri, 28 Nov 2014 12:05:12 +0000 (UTC) From: Tony Moseby Reply-To: Tony Moseby To: "freebsd-arm@freebsd.org" Message-ID: <103098674.2514784.1417176312748.JavaMail.yahoo@jws11120.mail.ir2.yahoo.com> Subject: VM FAULT MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Nov 2014 12:05:18 -0000 Hello, Now and then my system crashes at boot, sometimes freezes , sometimes=C2=A0= I get following information (see below).I am running FreeBsd 8.2 with a mar= vel ethernet switch, someone who have seen orcan explain this? vm_fault(0xc0bd4914, b82d3000, 1, 0) -> 1Fatal kernel mode data abort: 'Tra= nslation Fault (S)'trapframe: 0xd663edecFSR=3D00000005, FAR=3Db82d37a8, sps= r=3D00000013r0 =3Dc0bd40b8, r1 =3D0001bb40, r2 =3Dfeedfeed, r3 =3D00000040r= 4 =3D0000009c, r5 =3Dc0bd4070, r6 =3Db82d3530, r7 =3Dc4e72c00r8 =3Dc0bd3d2c= , r9 =3Dc0bd3a30, r10=3Dc0bdad60, r11=3Dd663ee64r12=3D7ab16e37, ssp=3Dd663e= e38, slr=3Dc091a844, pc =3Dc0950118 From owner-freebsd-arm@FreeBSD.ORG Fri Nov 28 12:13:03 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 459F1C07 for ; Fri, 28 Nov 2014 12:13:03 +0000 (UTC) Received: from eu1sys200aog105.obsmtp.com (eu1sys200aog105.obsmtp.com [207.126.144.119]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 93EAEEC9 for ; Fri, 28 Nov 2014 12:13:02 +0000 (UTC) Received: from mail-wi0-f181.google.com ([209.85.212.181]) (using TLSv1) by eu1sys200aob105.postini.com ([207.126.147.11]) with SMTP ID DSNKVHhmtntvbPLwoFNAj3m5DwwqqmfLifOC@postini.com; Fri, 28 Nov 2014 12:13:02 UTC Received: by mail-wi0-f181.google.com with SMTP id r20so11043333wiv.14 for ; Fri, 28 Nov 2014 04:12:38 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:message-id:to:subject:reply-to; bh=i8JwxIvlvrG3jKKlp2tCSgIS4+Tk+nGqMBlm63fhza0=; b=QRnpCTLfEqbhrsRAI2GWwNtYRF164gLn8jVYDJd5eY4O5/ZLNcnC84KpUumenbgTBY 0QlHcUUwrzKrVSqp6CXcACq3ETDSyB3/AJvQt5c9IUA2j2/lDWo6Jtwckq2eEm2oXfEQ 400n+pM6gelqYmjdvs1cn7BLrRj1xa6BgjbR03mx1s/IK6Cti3XMp9Fi5ArWLuWJkCRo Z6Mn2AdFZAPbFCSyh/ZJKOyPuV2hgg5WJzk3BJMX5JrjogcK2TRyRXPAPWVYIUrGlW4O SFA9sl8/p5oRcjBE+KzvDdmhYyRWnvBWafRW2g+kFVeKtqKVJt5QdIWCa5yA72MsVccc yHAQ== X-Received: by 10.194.3.45 with SMTP id 13mr65019988wjz.47.1417166819300; Fri, 28 Nov 2014 01:26:59 -0800 (PST) X-Gm-Message-State: ALoCoQkbEEcLdma+kwnZGW4r1CuxinzXFTK6zmu39Y/crv9jPc9Xsx4r7QBNJOOD5kQ1W2QNvgN097N3UhcKPdZnHihpyfj1K3rSsml6MuMxRk1a5OF4hAp2fageBxHYy1E+AJxe+uYoQyRRe5W98LeJtgmb7k3w5A== X-Received: by 10.194.3.45 with SMTP id 13mr65019969wjz.47.1417166819172; Fri, 28 Nov 2014 01:26:59 -0800 (PST) Received: from mech-as221.men.bris.ac.uk (mech-as221.men.bris.ac.uk. [137.222.187.221]) by mx.google.com with ESMTPSA id cq4sm14208934wjc.35.2014.11.28.01.26.58 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 28 Nov 2014 01:26:58 -0800 (PST) Date: Fri, 28 Nov 2014 01:26:58 -0800 (PST) X-Google-Original-Date: Fri, 28 Nov 2014 09:26:56 GMT Received: from mech-as221.men.bris.ac.uk (localhost [127.0.0.1]) by mech-as221.men.bris.ac.uk (8.14.9/8.14.9) with ESMTP id sAS9QvnT097336 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 28 Nov 2014 09:26:57 GMT (envelope-from mexas@mech-as221.men.bris.ac.uk) Received: (from mexas@localhost) by mech-as221.men.bris.ac.uk (8.14.9/8.14.9/Submit) id sAS9QuVB097335; Fri, 28 Nov 2014 09:26:56 GMT (envelope-from mexas) From: Anton Shterenlikht Message-Id: <201411280926.sAS9QuVB097335@mech-as221.men.bris.ac.uk> To: erichsfreebsdlist@alogt.com, freebsd-arm@freebsd.org Subject: RE: built xorg-server, what next? Reply-To: mexas@bris.ac.uk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Nov 2014 12:13:03 -0000 >Hi, > >On Thu, 27 Nov 2014 02:35:53 -0800 (PST) >Anton Shterenlikht wrote: > >> I managed to build xorg-server-1.12.4_9,1 >> on RPI-B 10.1-RELEASE, no build failures >> along the way, just a couple of panics. >> >> I then followed: >> >> http://blog.cochard.me/2013/03/xorg-for-freebsd-on-raspberry-pi.html >> ( Is this guide still valid?) >> >> and built xf86-video-scfb-0.0.4_1 >> >I did the normal builds just like on a x86. > >> On X -configure I got: > >I did not do this. > >I use an xorg.conf with this content: > >Section "Files" > ModulePath "/usr/local/lib/xorg/modules" > FontPath "/usr/local/lib/X11/fonts/misc/" > FontPath "/usr/local/lib/X11/fonts/TTF/" > FontPath "/usr/local/lib/X11/fonts/OTF" > FontPath "/usr/local/lib/X11/fonts/Type1/" > FontPath "/usr/local/lib/X11/fonts/100dpi/" > FontPath "/usr/local/lib/X11/fonts/75dpi/" > FontPath "/usr/local/lib/X11/fonts/dejavu/" > FontPath "/usr/local/lib/X11/fonts/Droid/" > FontPath "/usr/local/lib/X11/fonts/webfonts/" >EndSection >Section "Module" > Load "dbe" > Disable "dri" > Disable "dri2" > Disable "glx" > SubSection "extmod" > Option "omit xfree86-dga" > EndSubSection >EndSection >Section "ServerFlags" > Option "AIGLX" "false" > Option "NoAccel" "True" > Option "NoDRI" "True" > Option "DRI" "False" > Option "DRI2" "False" >EndSection >Section "InputDevice" > Identifier "Keyboard1" > Driver "kbd" >EndSection ># >Section "InputDevice" > Identifier "Mouse1" > Driver "mouse" > Option "Protocol" "auto" > Option "Device" "/dev/sysmouse" >EndSection >Section "Monitor" > Identifier "Monitor" >EndSection > >Section "Device" > Identifier "Generic FB" > Driver "scfb" > Option "NoAccel" "True" >EndSection > >Section "Screen" > Identifier "Screen" > Device "Generic FB" > Monitor "Monitor" > DefaultDepth 16 > SubSection "Display" > Depth 16 > EndSubsection >EndSection > >Section "ServerLayout" > Identifier "layout" > Screen 0 "Screen" 0 0 > InputDevice "Mouse1" "CorePointer" > InputDevice "Keyboard1" "CoreKeyboard" >EndSection > >Please check the output and the log file of startx for errors. I'm trying to use xdm. Ideally I'd like to use this RPI as a dumb graphical terminal, i.e. to connect to X clients via XDMCP. But something is wrong with xdm. The login screen comes up, but when I type the username, the characters appear in the top left corner, instead of in the centre of the screen, where the login prompt is. The password prompt never appears, and if I switch back to the text virtial terminal and again to the graphical terminal, the graphical xdm login prompt is not there at all. Perhaps xdm is not ready to use on RPI? Anyway, building the fonts right now. > >> Is scfb the wrong driver for this board? > >I also use it. ok, thank you for the confirmation. Looking ahead, what is your experience of using X on RPI? Are you able to build any clients? firefox? Thank you Anton From owner-freebsd-arm@FreeBSD.ORG Fri Nov 28 13:57:51 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7C58EA88; Fri, 28 Nov 2014 13:57:51 +0000 (UTC) Received: from nibbler.fubar.geek.nz (nibbler.fubar.geek.nz [199.48.134.198]) by mx1.freebsd.org (Postfix) with ESMTP id 5E2E3CF3; Fri, 28 Nov 2014 13:57:50 +0000 (UTC) Received: from bender.lan (97e078e7.skybroadband.com [151.224.120.231]) by nibbler.fubar.geek.nz (Postfix) with ESMTPSA id CC3FE7328F; Fri, 28 Nov 2014 13:57:42 +0000 (UTC) Date: Fri, 28 Nov 2014 13:57:37 +0000 From: Andrew Turner To: Julien Grall Subject: Re: [RFC v2] Add support for Xen ARM guest on FreeBSD Message-ID: <20141128135737.23a71643@bender.lan> In-Reply-To: <54726138.3090003@linaro.org> References: <54726138.3090003@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Ian Campbell , Stefano Stabellini , "xen-devel@lists.xen.org" , freebsd-xen@freebsd.org, freebsd-arm@freebsd.org, Denis Schneider , gibbs@freebsd.org, roger.pau@citrix.com X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Nov 2014 13:57:51 -0000 On Sun, 23 Nov 2014 22:35:36 +0000 Julien Grall wrote: > Hello all, > > At the beginning of the year, I have sent a first RFC to add support > for FreeBSD on Xen ARM [1]. ... > Major changes in this new version: > * Add Device Tree support via Linux Boot ABI > * Add zImage support > * Netfront support > * Blkfront fixes > * DOM0 support (separate branch see below) > > The former item is very hackish. I was wondering if there is another > way to do it? Or maybe we should support FreeBSD Bootloader in ARM > guest? I think using the loader is the correct way to handle booting in Xen. It allows us to relocate the dtb as required. It look like a zImage then use the Xen console to interact with the user. > > The patch series is divided in X parts: > * #1 - #14: Clean up and bug fixes for Xen. They can be > applied without the rest of the series > * #15 - #19: Update Xen interface to 4.4 and fix > compilation. It's required for ARM. > * #20 - #26: Update Xen code to support ARM > * #27 - #33: Rework the event channel code for supporting > ARM. I will work with Royger to come with a common interface with x86 > * #34 - #36: Add support for ARM in Xen code > * #37 - #46: ARM bug fixes and new features. Some of thoses > patches (#37 - #40) could be applied without the rest of the series > * #47 - #48: Add Xen ARM platform I have committed patches 30 and 40 as they look good. I'm not familiar with the code to review 37 or 38, however from my quick look at 38 I appears _bus_dmamap_load_buffer does take in to account buflen and dmat->maxsegsz when setting sgsize just not dmat->alignment. ... > > TODO: > * Add SMP/PSCI support in FreeBSD. Could be useful other > platform too Adding PSCI support is on my TODO lost for arm64, however I don't expect to get on ti in until early next year. > * Only FreeBSD to load anywhere. Currently there is a 2M > alignment which require a patch in Xen. If you use the loader this will be fixed as the loader can load the kernel at the correct alignment. From owner-freebsd-arm@FreeBSD.ORG Fri Nov 28 14:21:03 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A1D83E00 for ; Fri, 28 Nov 2014 14:21:03 +0000 (UTC) Received: from alogt.com (alogt.com [69.36.191.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 781ADF10 for ; Fri, 28 Nov 2014 14:21:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alogt.com; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=nPZQuYv3Vv4RxLm52X7t7OF2TkJyr2JSSJAo6FOuab4=; b=jzLjVQhIysTNarNcVaY2tq0v7BorGSdOWxp3DPEqVwLiq1l9wXbayjY5ZKI/FRUV4lBYneEgNsQ/TrCG9rMYCqGU11hgrA4I1UsCa+i7c8vO7ffMtSvSxN3BlykN4PTW3eh1j6lBzWv/ETrWsAKbqZu8+Dyq7O6dWXBcMLU+N0k=; Received: from [114.124.3.126] (port=37146 helo=X220.alogt.com) by sl-508-2.slc.westdc.net with esmtpa (Exim 4.84) (envelope-from ) id 1XuMPt-002oCY-9m; Fri, 28 Nov 2014 07:21:02 -0700 Date: Fri, 28 Nov 2014 22:20:55 +0800 From: Erich Dollansky To: Anton Shterenlikht Subject: Re: built xorg-server, what next? Message-ID: <20141128222055.76357f88@X220.alogt.com> In-Reply-To: <201411280926.sAS9QuVB097335@mech-as221.men.bris.ac.uk> References: <201411280926.sAS9QuVB097335@mech-as221.men.bris.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sl-508-2.slc.westdc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - alogt.com X-Get-Message-Sender-Via: sl-508-2.slc.westdc.net: authenticated_id: erichsfreebsdlist@alogt.com X-Source: X-Source-Args: X-Source-Dir: Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Nov 2014 14:21:03 -0000 Hi, On Fri, 28 Nov 2014 01:26:58 -0800 (PST) Anton Shterenlikht wrote: > > I'm trying to use xdm. try to isolate the problems by starting with a setup as simple as possible. > Ideally I'd like to use this RPI as a > dumb graphical terminal, i.e. to connect > to X clients via XDMCP. This should work after you overcame the problems you face at the moment. > But something is wrong with xdm. No. > The login screen comes up, but when I type > the username, the characters appear in the top > left corner, instead of in the centre of the I have had the same problem. Check the log file for errors. Maybe a module is missing. > screen, where the login prompt is. > The password prompt never appears, and if I > switch back to the text virtial terminal and > again to the graphical terminal, the graphical > xdm login prompt is not there at all. > Perhaps xdm is not ready to use on RPI? > No, this sounds like a normal problem with X. I remember that I have had something like this. > Anyway, building the fonts right now. > > > > >> Is scfb the wrong driver for this board? > > > >I also use it. > > ok, thank you for the confirmation. > > Looking ahead, what is your experience of using X on RPI? I first thought I can use the Raspberry as a thin-client but it is too slow for effective work. We plan to use it for something much simpler for which it is even way to fast. > Are you able to build any clients? xterm for sure. Blackbos also as the windows manager. > firefox? I did not get it running as my time did not permit it. Erich From owner-freebsd-arm@FreeBSD.ORG Fri Nov 28 14:31:13 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5EB52F96 for ; Fri, 28 Nov 2014 14:31:13 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2762B2B for ; Fri, 28 Nov 2014 14:31:12 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1XuMZj-0008Aq-Hn; Fri, 28 Nov 2014 14:31:11 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id sASEV924003277; Fri, 28 Nov 2014 07:31:10 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+JewLdPMok6kPZgrSOyDaU X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: Another Test Run with Alternative pmap Implementation From: Ian Lepore To: Svatopluk Kraus In-Reply-To: References: <20141113125236.b16cd4e5f0e339eac0494cd4@ulrich-grey.de> <20141115143444.5ad037548e06f289d2532fb7@ulrich-grey.de> <20141119225903.81fbbc7809093a0e6e0de9d5@ulrich-grey.de> <20141120151900.a68c6d8316b96a62cb65d17a@ulrich-grey.de> <20141121115941.54d4e36b103341c3adf7eb36@ulrich-grey.de> <20141124132733.4e96b906f0d1ab69969dddd9@ulrich-grey.de> <1416840814.1147.380.camel@revolution.hippie.lan> <20141125225451.924a5df4bdb4753db273b8c5@ulrich-grey.de> <20141127234239.e2c40a8fb99ba41f9ec3a7e7@ulrich-grey.de> <20141128001235.6591396b2f6298b861a96b57@ulrich-grey.de> Content-Type: text/plain; charset="us-ascii" Date: Fri, 28 Nov 2014 07:31:09 -0700 Message-ID: <1417185069.1047.4.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Nov 2014 14:31:13 -0000 On Fri, 2014-11-28 at 10:43 +0100, Svatopluk Kraus wrote: > Hmm, IMO, the LOR is well known. The broken pipe likely points to a problem > with SD card where your system is running. So, somehow your SD card stops > working. It could be caused, in the order of likelihood, because of > > (1) bad SD card, > (2) bad driver, > (3) something else. > > Svata We haven't had any reports of trouble with the imx6 sd driver. I would try turning off the DIAGNOSTIC option. It's really more harmful than useful on arm. On armv4 it makes the entire system lock up for seconds at a time as it runs some really expensive loop to verify something, I think it may have been VM data structures. Even on a faster chip such as imx6 this could cause problems like sdcard timeouts, as well as making a 2 hour compile take 7 hours. -- Ian From owner-freebsd-arm@FreeBSD.ORG Fri Nov 28 14:45:45 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EA1A4387 for ; Fri, 28 Nov 2014 14:45:45 +0000 (UTC) Received: from frontend3.warwick.net (mx2.warwick.net [204.255.24.104]) by mx1.freebsd.org (Postfix) with SMTP id 85C24239 for ; Fri, 28 Nov 2014 14:45:44 +0000 (UTC) Received: (qmail 28342 invoked from network); 28 Nov 2014 14:39:02 -0000 Received: from 70.44.113.83.res-cmts.sefg.ptd.net (HELO 70.44.113.83.res-cmts.sefg.ptd.net) (egunther@warwick.net@70.44.113.83) by frontend3.warwick.net with SMTP (4b933d66-770c-11e4-9fe7-0019bb38a71e); Fri, 28 Nov 2014 09:39:02 -0500 Message-ID: <1417185556.3079.1.camel@warwick.net> Subject: Re: Raspberry Pi composite video problem From: Eric Gunther To: Erich Dollansky Date: Fri, 28 Nov 2014 09:39:16 -0500 In-Reply-To: <20141128110527.043a158f@X220.alogt.com> References: <1417094728.2530.1.camel@warwick.net> <20141128110527.043a158f@X220.alogt.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.12.7 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-MagicMail-UUID: 4b933d66-770c-11e4-9fe7-0019bb38a71e X-MagicMail-Authenticated: egunther@warwick.net X-MagicMail-SourceIP: 70.44.113.83 X-MagicMail-EnvelopeFrom: Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Nov 2014 14:45:46 -0000 Just wanted to point out that I am using FreeBSD-10.1-RELEASE-arm-armv6-RPI-B.img as the boot image, unmodified. thanks --e On Fri, 2014-11-28 at 11:05 +0800, Erich Dollansky wrote: > Hi, > > On Thu, 27 Nov 2014 08:25:28 -0500 > Eric Gunther wrote: > > > input. I have an old tv with composite input and outputs, I thought > > I am not able to help you here. > > > I have enabled sshd, and set the hostname although I cannot seem to > > find the RPi on the network while using Ethernet cable (Cat 5e)... > > Use telnet for the start to make sure that you avoided the simplest > problems. You need inetd and /etc/inetd.conf with telnet enabled in > there. > > > This is not surprising because I am novice with networking. I have > > also tried telnet, although I saw elsewhere on this list that one has > > to enable it. I have not found the place to do that, I looked in > > loader.conf and rc.conf. > > > You have to enable inetd in rc.conf and telnet on /etc/inetd.conf. > > Erich From owner-freebsd-arm@FreeBSD.ORG Fri Nov 28 15:12:27 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0463CEC2 for ; Fri, 28 Nov 2014 15:12:27 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CAC719BD for ; Fri, 28 Nov 2014 15:12:26 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1XuNDd-0004R6-Mz; Fri, 28 Nov 2014 15:12:25 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id sASFCO7B003346; Fri, 28 Nov 2014 08:12:24 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+OJm5jJQyjoUcL4wnKPcw1 X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: VM FAULT From: Ian Lepore To: Tony Moseby In-Reply-To: <103098674.2514784.1417176312748.JavaMail.yahoo@jws11120.mail.ir2.yahoo.com> References: <103098674.2514784.1417176312748.JavaMail.yahoo@jws11120.mail.ir2.yahoo.com> Content-Type: multipart/mixed; boundary="=-c0CuVJoStb+q+PCqABL3" Date: Fri, 28 Nov 2014 08:12:23 -0700 Message-ID: <1417187543.1047.9.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Nov 2014 15:12:27 -0000 --=-c0CuVJoStb+q+PCqABL3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Fri, 2014-11-28 at 12:05 +0000, Tony Moseby wrote: > Hello, > Now and then my system crashes at boot, sometimes freezes , sometimes I get following information (see below).I am running FreeBsd 8.2 with a marvel ethernet switch, someone who have seen orcan explain this? > > vm_fault(0xc0bd4914, b82d3000, 1, 0) -> 1Fatal kernel mode data abort: 'Translation Fault (S)'trapframe: 0xd663edecFSR=00000005, FAR=b82d37a8, spsr=00000013r0 =c0bd40b8, r1 =0001bb40, r2 =feedfeed, r3 =00000040r4 =0000009c, r5 =c0bd4070, r6 =b82d3530, r7 =c4e72c00r8 =c0bd3d2c, r9 =c0bd3a30, r10=c0bdad60, r11=d663ee64r12=7ab16e37, ssp=d663ee38, slr=c091a844, pc =c0950118 > There's not really enough info in that panic output to figure out the problem. When it happens again, a backtrace (just enter bt at the debugger prompt) might help. I'm attaching a patch we used at $work when running 8.2 on a marvell-based Dreamplug. Maybe it will help, although the problem it fixed for us was IO corruption on disk and network reads, so it doesn't seem all that related. -- Ian --=-c0CuVJoStb+q+PCqABL3 Content-Disposition: inline; filename="dp_cache_wralloc.diff" Content-Type: text/x-patch; name="dp_cache_wralloc.diff"; charset="us-ascii" Content-Transfer-Encoding: 7bit Do not enable allocating a cache line on write access. Instead, leave that feature in whatever state the bootloader set it to, on the theory that the firmware that comes with the unit knows best. This fixes intermittant cache line corruptions during bulk network data flow. diff -r df572d6d53cd -r a142512ee876 sys/arm/arm/cpufunc.c --- sys/arm/arm/cpufunc.c Thu Nov 22 16:46:06 2012 -0700 +++ sys/arm/arm/cpufunc.c Sat Dec 01 15:38:59 2012 -0700 @@ -1067,13 +1067,13 @@ set_cpufuncs() */ if (cputype == CPU_ID_MV88FR571_VD || cputype == CPU_ID_MV88FR571_41) { - sheeva_control_ext(0xffffffff, - FC_DCACHE_STREAM_EN | FC_WR_ALLOC_EN | + sheeva_control_ext(0xffffffff & ~FC_WR_ALLOC_EN, + FC_DCACHE_STREAM_EN | FC_BRANCH_TARG_BUF_DIS | FC_L2CACHE_EN | FC_L2_PREF_DIS); } else { - sheeva_control_ext(0xffffffff, - FC_DCACHE_STREAM_EN | FC_WR_ALLOC_EN | + sheeva_control_ext(0xffffffff & ~FC_WR_ALLOC_EN, + FC_DCACHE_STREAM_EN | FC_BRANCH_TARG_BUF_DIS | FC_L2CACHE_EN); } --=-c0CuVJoStb+q+PCqABL3-- From owner-freebsd-arm@FreeBSD.ORG Fri Nov 28 16:45:44 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8FD6B270 for ; Fri, 28 Nov 2014 16:45:44 +0000 (UTC) Received: from frontend3.warwick.net (mx2.warwick.net [204.255.24.104]) by mx1.freebsd.org (Postfix) with SMTP id 2C54A6AB for ; Fri, 28 Nov 2014 16:45:43 +0000 (UTC) Received: (qmail 1408 invoked from network); 28 Nov 2014 16:45:42 -0000 Received: from 70.44.113.83.res-cmts.sefg.ptd.net (HELO 70.44.113.83.res-cmts.sefg.ptd.net) (egunther@warwick.net@70.44.113.83) by frontend3.warwick.net with SMTP (fda9b01e-771d-11e4-acaa-0019bb38a71e); Fri, 28 Nov 2014 11:45:42 -0500 Message-ID: <1417193156.3202.1.camel@warwick.net> Subject: Re: Raspberry Pi composite video problem From: Eric Gunther To: freebsd-arm@freebsd.org Date: Fri, 28 Nov 2014 11:45:56 -0500 In-Reply-To: <1417167767.23507.2.camel@warwick.net> References: <1417167767.23507.2.camel@warwick.net> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.12.7 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-MagicMail-UUID: fda9b01e-771d-11e4-acaa-0019bb38a71e X-MagicMail-Authenticated: egunther@warwick.net X-MagicMail-SourceIP: 70.44.113.83 X-MagicMail-EnvelopeFrom: X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Nov 2014 16:45:44 -0000 On Fri, 2014-11-28 at 04:42 -0500, Eric Gunther wrote: > Hi, > > On Thu, 27 Nov 2014 08:25:28 -0500 > Eric Gunther wrote: > > > input. I have an old tv with composite input and outputs, I thought > > I am not able to help you here. > > > So, would the firmware update change the display/console/terminal size? > As I had mentioned I tried config.txt which I think is the standard on > the Raspberry Pi as far as display configuration. It appears to me that > maybe I have to configure the syscons, vt or other driver or facility. > This I have investigated although come up empty. vidcontrol -i mode > yields one entry repeated multiple times, which is not listed in the man > page for vidcontrol, as far as I can tell. > > > > I have enabled sshd, and set the hostname although I cannot seem to > > find the RPi on the network while using Ethernet cable (Cat 5e)... > > Use telnet for the start to make sure that you avoided the simplest > problems. You need inetd and /etc/inetd.conf with telnet enabled in > there. Eureka, I have logged in via ssh. Not sure what is different although the last few things I did where: rechecked /etc/inetd.conf, /etc/rc.conf, /etc/services service sshd enable service sshd reload And plugged in the client computer after the RPi had been connected to the ethernet, worked using IP. telnet was still not functioning. Thank You, --e From owner-freebsd-arm@FreeBSD.ORG Fri Nov 28 17:50:26 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0D6C2F9C; Fri, 28 Nov 2014 17:50:26 +0000 (UTC) Received: from mail-wg0-x236.google.com (mail-wg0-x236.google.com [IPv6:2a00:1450:400c:c00::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 87E7AD8E; Fri, 28 Nov 2014 17:50:25 +0000 (UTC) Received: by mail-wg0-f54.google.com with SMTP id l2so9400381wgh.13 for ; Fri, 28 Nov 2014 09:50:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=eY2jUWlIVxTBwtLXi7yimCFnsJrU9EK4r/bzlXtzAcw=; b=RiVlEZfeBkneEoGwKcCmiLfq0MCUwsXOIYZqyTuAaq148+5DLZDTSIdbkFLUUfpxDn DswS4Oj7SxFgBsxeQTWmNElAmQk6F56wi3vK5R3XS7FSP9kZWmOyhYmf03oJQ/dcN2YH MgwIxjVZ8UK5XhVeOZrHYNUSux/5frjb+3HgU3O6vYcu7+/NCgKCmRvOc0kdVsPjocQS lmhVBt78Td4Fh/biSmfgM+vaaZ89VKW0C4asgyivnRDfCPjzd8AugJp+dEJS7eSGvy1N sgB/VO2K1SOXgZrbeWSPLCVd5d0HR66Lna7x5G+XThEienAwYmcyb88aHKk6PcynS//v 1TEA== MIME-Version: 1.0 X-Received: by 10.194.85.83 with SMTP id f19mr72912013wjz.20.1417197023117; Fri, 28 Nov 2014 09:50:23 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.106.136 with HTTP; Fri, 28 Nov 2014 09:50:22 -0800 (PST) In-Reply-To: References: <20141113125236.b16cd4e5f0e339eac0494cd4@ulrich-grey.de> <20141115143444.5ad037548e06f289d2532fb7@ulrich-grey.de> <20141119225903.81fbbc7809093a0e6e0de9d5@ulrich-grey.de> <20141120151900.a68c6d8316b96a62cb65d17a@ulrich-grey.de> <20141121115941.54d4e36b103341c3adf7eb36@ulrich-grey.de> <20141124132733.4e96b906f0d1ab69969dddd9@ulrich-grey.de> <1416840814.1147.380.camel@revolution.hippie.lan> <20141125225451.924a5df4bdb4753db273b8c5@ulrich-grey.de> <20141126125806.78f2df97328e807d12746ae3@ulrich-grey.de> <519fde5db60e4fc594956a600c6cad4e@e15be-01.zdv.Uni-Mainz.DE> <1417108193.1055.2.camel@revolution.hippie.lan> Date: Fri, 28 Nov 2014 09:50:23 -0800 X-Google-Sender-Auth: qIN8cSh_0f2cif3a5UxytfSXBg4 Message-ID: Subject: Re: Another Test Run with Alternative pmap Implementation From: Adrian Chadd To: Svatopluk Kraus Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-arm@freebsd.org" , Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Nov 2014 17:50:26 -0000 Hi, PCPU_GET()ed things aren't atomic. Unless you're in a critical section, you can be pre-empted at any time and migrated to another CPU. There aren't explicit "migration points" that kernel code can be migrated - it can be pre-empted and migrated to other CPUs whenever something else at a higher priority comes along. So if you're not wrapping your PCPU_GET() and subsequent work inside a critical section - if you're using the PCPU_GET()'ed data outside of the critical section, then you're in for a world of trouble. -adrian On 28 November 2014 at 01:31, Svatopluk Kraus wrote: > I think that the pmap_remove_page warning is very likely due to not atomi= c > PCPU_GET(). Can you please try attached patch. > > Svata > > > > On Thu, Nov 27, 2014 at 6:09 PM, Ian Lepore wrote: > >> On Wed, 2014-11-26 at 22:18 +0000, Wei=C3=9F, Dr. J=C3=BCrgen wrote: >> > I made a testrun with the updated source tree and the patches for >> > the jetson tk1 platform. With >> > >> > options ARM_NEW_PMAP >> > options DEBUG >> > options DIAGNOSTIC >> > options INVARIANTS # Enable calls of extra sanity >> checking >> > options INVARIANT_SUPPORT # Extra sanity checks of >> internal structures, required by INVARIAN >> > >> > and no special sysctl settings. >> > >> > A make -j6 buildworld finishes successfully after 2h15m. There is >> > one kernel message >> > kernel: warning: pmap_remove_pages called with non-current pmap >> > >> > /usr/src and /usr/obj over nfs, /tmp on tmpfs >> > >> > Regards >> >> That's similar to my results. I changed to -j20 to see if that would >> recreate the problems that Ulrich is seeing, but buildworld runs fine >> for me, in about 2 hours. I've never seen the non-current pmap warning >> on the system that uses a usb ssd drive as root, but I've seen it with >> nfs root. >> >> BTW, the DIAGNOSTIC option adds a LOT of performance overhead to an arm >> system without adding a lot of value. I usually leave it off, sometimes >> turn it on when I encounter a problem to see if it generates more info >> (usually it doesn't). >> >> -- Ian >> >> >> > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@FreeBSD.ORG Fri Nov 28 19:32:43 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5A8CFA5E; Fri, 28 Nov 2014 19:32:43 +0000 (UTC) Received: from mail-qa0-x230.google.com (mail-qa0-x230.google.com [IPv6:2607:f8b0:400d:c00::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 07ABCA00; Fri, 28 Nov 2014 19:32:43 +0000 (UTC) Received: by mail-qa0-f48.google.com with SMTP id v10so4798836qac.7 for ; Fri, 28 Nov 2014 11:32:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wd6ai1jBBuoX+UZtgS29F845FtrDxTc0d67F6brZcdM=; b=HLLC6WYLRkDeUR0G3wiwAhEFmXL6NX1RT+3irBLlyTTz6WdpJKLhZFiP6EB092kClv 7FRYiZ6D0256C4Ciyk0nHsByvGUmwQZhAPx6s4dnd9fT8FbauU+pMTa5g9cg+6btGpgV jT/Tyzyx/l7kB1E066ys+6xh0/FWO/H9F5OiEAcRYCELIsiB8ZMSNlaga5P2gxtIm7G2 F5Sl648dOgx+RcrsMNAur0iwOcwxbbRi0O1XekUfHmU/wotnEiOCtEhs+lF24zRIuAZ1 Uln85305m1bspLB/Ee3pXRzQTfB3/vIiAMQHsmytW9WGJK8U+3yN2R0GJCIQDFWt0b/z iGdw== MIME-Version: 1.0 X-Received: by 10.140.39.5 with SMTP id u5mr28745393qgu.28.1417203162154; Fri, 28 Nov 2014 11:32:42 -0800 (PST) Received: by 10.140.23.242 with HTTP; Fri, 28 Nov 2014 11:32:42 -0800 (PST) In-Reply-To: <1417185069.1047.4.camel@revolution.hippie.lan> References: <20141113125236.b16cd4e5f0e339eac0494cd4@ulrich-grey.de> <20141115143444.5ad037548e06f289d2532fb7@ulrich-grey.de> <20141119225903.81fbbc7809093a0e6e0de9d5@ulrich-grey.de> <20141120151900.a68c6d8316b96a62cb65d17a@ulrich-grey.de> <20141121115941.54d4e36b103341c3adf7eb36@ulrich-grey.de> <20141124132733.4e96b906f0d1ab69969dddd9@ulrich-grey.de> <1416840814.1147.380.camel@revolution.hippie.lan> <20141125225451.924a5df4bdb4753db273b8c5@ulrich-grey.de> <20141127234239.e2c40a8fb99ba41f9ec3a7e7@ulrich-grey.de> <20141128001235.6591396b2f6298b861a96b57@ulrich-grey.de> <1417185069.1047.4.camel@revolution.hippie.lan> Date: Fri, 28 Nov 2014 20:32:42 +0100 Message-ID: Subject: Re: Another Test Run with Alternative pmap Implementation From: Svatopluk Kraus To: Ulrich Grey Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-arm@freebsd.org, Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Nov 2014 19:32:43 -0000 On Fri, Nov 28, 2014 at 3:31 PM, Ian Lepore wrote: > On Fri, 2014-11-28 at 10:43 +0100, Svatopluk Kraus wrote: > > Hmm, IMO, the LOR is well known. The broken pipe likely points to a > problem > > with SD card where your system is running. So, somehow your SD card stops > > working. It could be caused, in the order of likelihood, because of > > > > (1) bad SD card, > > (2) bad driver, > > (3) something else. > > > > Svata > > We haven't had any reports of trouble with the imx6 sd driver. > > I would try turning off the DIAGNOSTIC option. It's really more harmful > than useful on arm. On armv4 it makes the entire system lock up for > seconds at a time as it runs some really expensive loop to verify > something, I think it may have been VM data structures. Even on a > faster chip such as imx6 this could cause problems like sdcard timeouts, > as well as making a 2 hour compile take 7 hours. > > -- Ian > I agree with Ian, please do not use DIAGNOSTICS option. I'm sorry that I wanted you to set it. Michal recently told me that he had same experience like Ian has described here. Anyhow, if DIAGNOSTICS is enabled, there is a possibility to avoid the memory check by setting sysctl debug.vmem_check=0. Svata From owner-freebsd-arm@FreeBSD.ORG Fri Nov 28 19:49:17 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B8EB1E11; Fri, 28 Nov 2014 19:49:17 +0000 (UTC) Received: from mail-qa0-x22b.google.com (mail-qa0-x22b.google.com [IPv6:2607:f8b0:400d:c00::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 63339AFE; Fri, 28 Nov 2014 19:49:17 +0000 (UTC) Received: by mail-qa0-f43.google.com with SMTP id bm13so4843797qab.16 for ; Fri, 28 Nov 2014 11:49:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=htsc6HM2v4m+PtP0E8H3oM50C3pzv6Ml9mpldkF9aHI=; b=LBtokl4gT13+bPIqpI7/xrL6t/EdjdfU1fxXOLxxn7ikH8oSHTTrMb0sUg0O9O0M/i LH4Y/fn0vBn8ojT/qAg6tcNgo66W25mHpRRmJerOyop++OnDHfQ5L69KPc9VBULuioQL LiGrgigMvW5b5gXIz6ic8XG2FAAJ9ig7fkCgMvmJkMzflCCTHXCdaBB2NwIKi112qzpJ nwrqHZJZ/0GpKx1TEnyMNcSciQ62R9KjZGj8DEM5bqxH+eAYNnHEQADjIPud7bke24Xt JIZysnVplrI5OZQZMbYIxLjD1d2wFJDUUFTuHg9Bh4XB89ZC3uPCqKHpcqtbN5UmzCJR oM4A== MIME-Version: 1.0 X-Received: by 10.224.129.196 with SMTP id p4mr67281377qas.1.1417204156474; Fri, 28 Nov 2014 11:49:16 -0800 (PST) Received: by 10.140.23.242 with HTTP; Fri, 28 Nov 2014 11:49:16 -0800 (PST) In-Reply-To: References: <20141113125236.b16cd4e5f0e339eac0494cd4@ulrich-grey.de> <20141115143444.5ad037548e06f289d2532fb7@ulrich-grey.de> <20141119225903.81fbbc7809093a0e6e0de9d5@ulrich-grey.de> <20141120151900.a68c6d8316b96a62cb65d17a@ulrich-grey.de> <20141121115941.54d4e36b103341c3adf7eb36@ulrich-grey.de> <20141124132733.4e96b906f0d1ab69969dddd9@ulrich-grey.de> <1416840814.1147.380.camel@revolution.hippie.lan> <20141125225451.924a5df4bdb4753db273b8c5@ulrich-grey.de> <20141126125806.78f2df97328e807d12746ae3@ulrich-grey.de> <519fde5db60e4fc594956a600c6cad4e@e15be-01.zdv.Uni-Mainz.DE> <1417108193.1055.2.camel@revolution.hippie.lan> Date: Fri, 28 Nov 2014 20:49:16 +0100 Message-ID: Subject: Re: Another Test Run with Alternative pmap Implementation From: Svatopluk Kraus To: Adrian Chadd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-arm@freebsd.org" , Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Nov 2014 19:49:17 -0000 Thanks for explanation. In this case, however, wrapping by sched_pin() and sched_unpin() calls would be enough. Nevertheless, as our pmap is based on i386 one, I asked Alan Cox for the meaning of this warning and created patch according to his answer. More about PCPU stuff could be found in [1]. ;) Svata [1] http://lists.freebsd.org/pipermail/freebsd-current/2013-February/039858.htm= l On Fri, Nov 28, 2014 at 6:50 PM, Adrian Chadd wrote: > Hi, > > PCPU_GET()ed things aren't atomic. Unless you're in a critical > section, you can be pre-empted at any time and migrated to another > CPU. There aren't explicit "migration points" that kernel code can be > migrated - it can be pre-empted and migrated to other CPUs whenever > something else at a higher priority comes along. > > So if you're not wrapping your PCPU_GET() and subsequent work inside a > critical section - if you're using the PCPU_GET()'ed data outside of > the critical section, then you're in for a world of trouble. > > > > -adrian > > > On 28 November 2014 at 01:31, Svatopluk Kraus wrote: > > I think that the pmap_remove_page warning is very likely due to not > atomic > > PCPU_GET(). Can you please try attached patch. > > > > Svata > > > > > > > > On Thu, Nov 27, 2014 at 6:09 PM, Ian Lepore wrote: > > > >> On Wed, 2014-11-26 at 22:18 +0000, Wei=C3=9F, Dr. J=C3=BCrgen wrote: > >> > I made a testrun with the updated source tree and the patches for > >> > the jetson tk1 platform. With > >> > > >> > options ARM_NEW_PMAP > >> > options DEBUG > >> > options DIAGNOSTIC > >> > options INVARIANTS # Enable calls of extra sani= ty > >> checking > >> > options INVARIANT_SUPPORT # Extra sanity checks of > >> internal structures, required by INVARIAN > >> > > >> > and no special sysctl settings. > >> > > >> > A make -j6 buildworld finishes successfully after 2h15m. There is > >> > one kernel message > >> > kernel: warning: pmap_remove_pages called with non-current pmap > >> > > >> > /usr/src and /usr/obj over nfs, /tmp on tmpfs > >> > > >> > Regards > >> > >> That's similar to my results. I changed to -j20 to see if that would > >> recreate the problems that Ulrich is seeing, but buildworld runs fine > >> for me, in about 2 hours. I've never seen the non-current pmap warnin= g > >> on the system that uses a usb ssd drive as root, but I've seen it with > >> nfs root. > >> > >> BTW, the DIAGNOSTIC option adds a LOT of performance overhead to an ar= m > >> system without adding a lot of value. I usually leave it off, sometim= es > >> turn it on when I encounter a problem to see if it generates more info > >> (usually it doesn't). > >> > >> -- Ian > >> > >> > >> > > > > _______________________________________________ > > freebsd-arm@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > From owner-freebsd-arm@FreeBSD.ORG Fri Nov 28 21:03:45 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9D772AAE; Fri, 28 Nov 2014 21:03:45 +0000 (UTC) Received: from tensor.andric.com (unknown [IPv6:2001:7b8:3a7:1:2d0:b7ff:fea0:8c26]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5907A243; Fri, 28 Nov 2014 21:03:45 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::1d4c:2702:e90a:2efb] (unknown [IPv6:2001:7b8:3a7:0:1d4c:2702:e90a:2efb]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id F267EB80A; Fri, 28 Nov 2014 22:03:40 +0100 (CET) From: Dimitry Andric X-Pgp-Agent: GPGMail 2.5b1 Content-Type: multipart/signed; boundary="Apple-Mail=_FAF32578-E1BE-4097-9213-963BEB422E85"; protocol="application/pgp-signature"; micalg=pgp-sha1 Subject: RFT: Please help testing the llvm/clang 3.5.0 import Date: Fri, 28 Nov 2014 22:03:31 +0100 Message-Id: <8598B1D4-5485-426F-B6D6-22BF26AC5FE1@FreeBSD.org> To: FreeBSD-Current Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) X-Mailer: Apple Mail (2.1993) Cc: FreeBSD ARM , FreeBSD ports X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Nov 2014 21:03:45 -0000 --Apple-Mail=_FAF32578-E1BE-4097-9213-963BEB422E85 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, We're working on updating llvm, clang and lldb to 3.5.0 in head. This is quite a big update again, and any help with testing is appreciated. To try this out, ensure you have good backups or snapshots, then build world and kernel from the projects/clang350-import branch [1]. Please use a Subversion mirror [2], if you are able to. The status of this project branch is as follows: * Since llvm/clang 3.5.0 requires C++11 support, you can only build it when your current installation has both clang (>=3D 3.3) and libc++ installed. E.g., FreeBSD 10.x and later should work out of the box, but for FreeBSD 9.x you should first build libc++ with clang, and install it. Older versions of FreeBSD will not work. * Both the i386 and amd64 arches are expected to work completely, e.g. they should build, install and run without any problems. For some less-used parts of world and kernel, you might encounter warnings that are not fixed yet. To ignore those, you can use NO_WERROR, but please create bug reports for them. * The different ARM builds still need work, any help would be greatly appreciated there. * PowerPC (32 and 64 bit) will most likely not work yet, until we can figure out how to build parts of the tree with clang, other parts with gcc. * Sparc64 might work at least partially, but has not been tested on real hardware. * A ports exp-run has been requested [3]. The tentative goal is to be able to import this new version before the end of the year, hopefully before Christmas. If you encounter issues, please report them in FreeBSD Bugzilla [4], unless you think it is better discussed on one of the appropriate mailing lists. -Dimitry [1] svn://svn.freebsd.org/base/projects/clang350-import [2] = https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/svn.html#svn-mi= rrors [3] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D195480 [4] https://bugs.freebsd.org/submit/ --Apple-Mail=_FAF32578-E1BE-4097-9213-963BEB422E85 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.26 iEYEARECAAYFAlR44ysACgkQsF6jCi4glqPN5ACg3+kmc05zNVksFsq+SstYE22z OLcAoKiIf03iY1s5CZw6J3ZUylkKYGyd =m4oU -----END PGP SIGNATURE----- --Apple-Mail=_FAF32578-E1BE-4097-9213-963BEB422E85-- From owner-freebsd-arm@FreeBSD.ORG Fri Nov 28 22:17:30 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 62DBF176; Fri, 28 Nov 2014 22:17:30 +0000 (UTC) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D8881B4E; Fri, 28 Nov 2014 22:17:29 +0000 (UTC) Received: by mail-wg0-f46.google.com with SMTP id a1so1533712wgh.19 for ; Fri, 28 Nov 2014 14:17:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=ZaBbmxYyzAH/7EhZl4/z188kRwaiFpJYEOkB1trxMgA=; b=sfzuH8JwD5+bBRNaCvigCMa1QX+F4lCtvmy0Di00QB2kEykk4+UiEZmIEbB+sGylUK lepUwDl6kk0iuBIBegNhkC9aUfjxgulGa9jzzFTJxL7pTSWZa5jbhLTu4i4Gsh2ia0yj 9zxE0Y9AlqNLtUUMaO0nkdH3vYV8w6jVFonRn4AwFXFr6X6exD77U0/8zfgpKb5JBEaY P8Ena6/UQJo8CmiH5jzqBhqtaMVW5Dxd3w1x4q/0DTo+4nYjpGgQzcyQj6gdXE0DR/4A WWavXbeUpBNJmmHhYEN9INiwlsTczqBg5UhYR9xX6xM2taXLPsmRUJCfFDEJD51qIAQ+ X+vw== MIME-Version: 1.0 X-Received: by 10.194.85.83 with SMTP id f19mr74549904wjz.20.1417213048175; Fri, 28 Nov 2014 14:17:28 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.106.136 with HTTP; Fri, 28 Nov 2014 14:17:28 -0800 (PST) In-Reply-To: References: <20141113125236.b16cd4e5f0e339eac0494cd4@ulrich-grey.de> <20141115143444.5ad037548e06f289d2532fb7@ulrich-grey.de> <20141119225903.81fbbc7809093a0e6e0de9d5@ulrich-grey.de> <20141120151900.a68c6d8316b96a62cb65d17a@ulrich-grey.de> <20141121115941.54d4e36b103341c3adf7eb36@ulrich-grey.de> <20141124132733.4e96b906f0d1ab69969dddd9@ulrich-grey.de> <1416840814.1147.380.camel@revolution.hippie.lan> <20141125225451.924a5df4bdb4753db273b8c5@ulrich-grey.de> <20141126125806.78f2df97328e807d12746ae3@ulrich-grey.de> <519fde5db60e4fc594956a600c6cad4e@e15be-01.zdv.Uni-Mainz.DE> <1417108193.1055.2.camel@revolution.hippie.lan> Date: Fri, 28 Nov 2014 14:17:28 -0800 X-Google-Sender-Auth: c93i-uztU52XWNLRlHo1Xxu0m8w Message-ID: Subject: Re: Another Test Run with Alternative pmap Implementation From: Adrian Chadd To: Svatopluk Kraus Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-arm@freebsd.org" , Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Nov 2014 22:17:30 -0000 On 28 November 2014 at 11:49, Svatopluk Kraus wrote: > Thanks for explanation. In this case, however, wrapping by sched_pin() an= d > sched_unpin() calls would be enough. Nevertheless, as our pmap is based o= n > i386 one, I asked Alan Cox for the meaning of this warning and created pa= tch > according to his answer. > > More about PCPU stuff could be found in [1]. ;) As long as nothing else can preempt that thread on that CPU that'll mess with your PCPU data, everything is fine. Doing sched_pin() just prevents your thread from migrating to another core whilst it's running; it doesn't prevent something else at a higher priority from preempting you and also trying to get access to the same PCPU data. (I hit this stuff when playing with the flowtable code which makes heavy use of pcpu data..) -a > > Svata > > [1] > http://lists.freebsd.org/pipermail/freebsd-current/2013-February/039858.h= tml > > > > On Fri, Nov 28, 2014 at 6:50 PM, Adrian Chadd wrote: >> >> Hi, >> >> PCPU_GET()ed things aren't atomic. Unless you're in a critical >> section, you can be pre-empted at any time and migrated to another >> CPU. There aren't explicit "migration points" that kernel code can be >> migrated - it can be pre-empted and migrated to other CPUs whenever >> something else at a higher priority comes along. >> >> So if you're not wrapping your PCPU_GET() and subsequent work inside a >> critical section - if you're using the PCPU_GET()'ed data outside of >> the critical section, then you're in for a world of trouble. >> >> >> >> -adrian >> >> >> On 28 November 2014 at 01:31, Svatopluk Kraus wrote: >> > I think that the pmap_remove_page warning is very likely due to not >> > atomic >> > PCPU_GET(). Can you please try attached patch. >> > >> > Svata >> > >> > >> > >> > On Thu, Nov 27, 2014 at 6:09 PM, Ian Lepore wrote: >> > >> >> On Wed, 2014-11-26 at 22:18 +0000, Wei=C3=9F, Dr. J=C3=BCrgen wrote: >> >> > I made a testrun with the updated source tree and the patches for >> >> > the jetson tk1 platform. With >> >> > >> >> > options ARM_NEW_PMAP >> >> > options DEBUG >> >> > options DIAGNOSTIC >> >> > options INVARIANTS # Enable calls of extra >> >> > sanity >> >> checking >> >> > options INVARIANT_SUPPORT # Extra sanity checks of >> >> internal structures, required by INVARIAN >> >> > >> >> > and no special sysctl settings. >> >> > >> >> > A make -j6 buildworld finishes successfully after 2h15m. There is >> >> > one kernel message >> >> > kernel: warning: pmap_remove_pages called with non-current pmap >> >> > >> >> > /usr/src and /usr/obj over nfs, /tmp on tmpfs >> >> > >> >> > Regards >> >> >> >> That's similar to my results. I changed to -j20 to see if that would >> >> recreate the problems that Ulrich is seeing, but buildworld runs fine >> >> for me, in about 2 hours. I've never seen the non-current pmap warni= ng >> >> on the system that uses a usb ssd drive as root, but I've seen it wit= h >> >> nfs root. >> >> >> >> BTW, the DIAGNOSTIC option adds a LOT of performance overhead to an a= rm >> >> system without adding a lot of value. I usually leave it off, >> >> sometimes >> >> turn it on when I encounter a problem to see if it generates more inf= o >> >> (usually it doesn't). >> >> >> >> -- Ian >> >> >> >> >> >> >> > >> > _______________________________________________ >> > freebsd-arm@freebsd.org mailing list >> > http://lists.freebsd.org/mailman/listinfo/freebsd-arm >> > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > > From owner-freebsd-arm@FreeBSD.ORG Fri Nov 28 23:36:41 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 57901E00; Fri, 28 Nov 2014 23:36:41 +0000 (UTC) Received: from mail-qa0-x236.google.com (mail-qa0-x236.google.com [IPv6:2607:f8b0:400d:c00::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F3DBA28D; Fri, 28 Nov 2014 23:36:40 +0000 (UTC) Received: by mail-qa0-f54.google.com with SMTP id i13so5143178qae.27 for ; Fri, 28 Nov 2014 15:36:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=J/r+TrftsMFs8fMExsmANaTCDdfuf1bWUTBHu5tpyJ4=; b=jm0mmu7ovFgxq3HSe3t76zoBdY9sGHYUEDYd0JF19SKztLZ2lf+ifjHOe3jYJHrA1t 4lPU7Mwrs3YAH68cBVX9M/jJd1msvOAwHsMRYaD7LdXRGYL97teCExiFZ5RZWaxT3paf LeOphXoOEr7kf8IPqaxfA9A5bSabcHJgiAxIzUawThApzQY8+iqHMxvuHwYbhtsPzbOL qlWpUEsZDbNFOE62YXSf6UJXRD1QmRw+qqbuQ6Ayuh3wVjhcMAdkPD6ogLFW9zAGV9AZ HPzylsOEdSFlrilDasSDoRzEE3vcCdMY6VVtpTuCYTlvMbm/coq35YqtTP1sRENd7jvM CgYw== MIME-Version: 1.0 X-Received: by 10.224.129.9 with SMTP id m9mr67104541qas.50.1417217800113; Fri, 28 Nov 2014 15:36:40 -0800 (PST) Received: by 10.140.23.242 with HTTP; Fri, 28 Nov 2014 15:36:40 -0800 (PST) In-Reply-To: References: <20141113125236.b16cd4e5f0e339eac0494cd4@ulrich-grey.de> <20141115143444.5ad037548e06f289d2532fb7@ulrich-grey.de> <20141119225903.81fbbc7809093a0e6e0de9d5@ulrich-grey.de> <20141120151900.a68c6d8316b96a62cb65d17a@ulrich-grey.de> <20141121115941.54d4e36b103341c3adf7eb36@ulrich-grey.de> <20141124132733.4e96b906f0d1ab69969dddd9@ulrich-grey.de> <1416840814.1147.380.camel@revolution.hippie.lan> <20141125225451.924a5df4bdb4753db273b8c5@ulrich-grey.de> <20141126125806.78f2df97328e807d12746ae3@ulrich-grey.de> <519fde5db60e4fc594956a600c6cad4e@e15be-01.zdv.Uni-Mainz.DE> <1417108193.1055.2.camel@revolution.hippie.lan> Date: Sat, 29 Nov 2014 00:36:40 +0100 Message-ID: Subject: Re: Another Test Run with Alternative pmap Implementation From: Svatopluk Kraus To: Adrian Chadd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-arm@freebsd.org" , Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Nov 2014 23:36:41 -0000 On Fri, Nov 28, 2014 at 11:17 PM, Adrian Chadd wrote: > On 28 November 2014 at 11:49, Svatopluk Kraus wrote: > > Thanks for explanation. In this case, however, wrapping by sched_pin() > and > > sched_unpin() calls would be enough. Nevertheless, as our pmap is based > on > > i386 one, I asked Alan Cox for the meaning of this warning and created > patch > > according to his answer. > > > > More about PCPU stuff could be found in [1]. ;) > > As long as nothing else can preempt that thread on that CPU that'll > mess with your PCPU data, everything is fine. > > Doing sched_pin() just prevents your thread from migrating to another > core whilst it's running; it doesn't prevent something else at a > higher priority from preempting you and also trying to get access to > the same PCPU data. > > (I hit this stuff when playing with the flowtable code which makes > heavy use of pcpu data..) > > > -a > > Generally, it's correct. However, I said in this case. And in this case, it's about curpmap. And curpmap is always same from curthread. So only thing which must be ensured is that curpmap is read from correct PCPU. In other words, curthread should not migrate between reading of cpu number and getting curpmap from associated PCPU. Thus wrapping it by sched_pin() and sched_unpin() is enough. Svata > > > > Svata > > > > [1] > > > http://lists.freebsd.org/pipermail/freebsd-current/2013-February/039858.h= tml > > > > > > > > On Fri, Nov 28, 2014 at 6:50 PM, Adrian Chadd > wrote: > >> > >> Hi, > >> > >> PCPU_GET()ed things aren't atomic. Unless you're in a critical > >> section, you can be pre-empted at any time and migrated to another > >> CPU. There aren't explicit "migration points" that kernel code can be > >> migrated - it can be pre-empted and migrated to other CPUs whenever > >> something else at a higher priority comes along. > >> > >> So if you're not wrapping your PCPU_GET() and subsequent work inside a > >> critical section - if you're using the PCPU_GET()'ed data outside of > >> the critical section, then you're in for a world of trouble. > >> > >> > >> > >> -adrian > >> > >> > >> On 28 November 2014 at 01:31, Svatopluk Kraus wrote= : > >> > I think that the pmap_remove_page warning is very likely due to not > >> > atomic > >> > PCPU_GET(). Can you please try attached patch. > >> > > >> > Svata > >> > > >> > > >> > > >> > On Thu, Nov 27, 2014 at 6:09 PM, Ian Lepore wrote: > >> > > >> >> On Wed, 2014-11-26 at 22:18 +0000, Wei=C3=9F, Dr. J=C3=BCrgen wrote= : > >> >> > I made a testrun with the updated source tree and the patches for > >> >> > the jetson tk1 platform. With > >> >> > > >> >> > options ARM_NEW_PMAP > >> >> > options DEBUG > >> >> > options DIAGNOSTIC > >> >> > options INVARIANTS # Enable calls of extra > >> >> > sanity > >> >> checking > >> >> > options INVARIANT_SUPPORT # Extra sanity checks of > >> >> internal structures, required by INVARIAN > >> >> > > >> >> > and no special sysctl settings. > >> >> > > >> >> > A make -j6 buildworld finishes successfully after 2h15m. There is > >> >> > one kernel message > >> >> > kernel: warning: pmap_remove_pages called with non-current pmap > >> >> > > >> >> > /usr/src and /usr/obj over nfs, /tmp on tmpfs > >> >> > > >> >> > Regards > >> >> > >> >> That's similar to my results. I changed to -j20 to see if that wou= ld > >> >> recreate the problems that Ulrich is seeing, but buildworld runs fi= ne > >> >> for me, in about 2 hours. I've never seen the non-current pmap > warning > >> >> on the system that uses a usb ssd drive as root, but I've seen it > with > >> >> nfs root. > >> >> > >> >> BTW, the DIAGNOSTIC option adds a LOT of performance overhead to an > arm > >> >> system without adding a lot of value. I usually leave it off, > >> >> sometimes > >> >> turn it on when I encounter a problem to see if it generates more > info > >> >> (usually it doesn't). > >> >> > >> >> -- Ian > >> >> > >> >> > >> >> > >> > > >> > _______________________________________________ > >> > freebsd-arm@freebsd.org mailing list > >> > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > >> > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.or= g > " > > > > > From owner-freebsd-arm@FreeBSD.ORG Sat Nov 29 00:49:08 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 66F85C28 for ; Sat, 29 Nov 2014 00:49:08 +0000 (UTC) Received: from alogt.com (alogt.com [69.36.191.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3E991AF4 for ; Sat, 29 Nov 2014 00:49:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alogt.com; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=b55YQfL8xR4BKDbLvKMKcb++hNE5tJkN2UwLei/9kDs=; b=k5i46PLjxUzKH355bMbT9+mHkXEado6rAScKtbTZzPDd1SfNZz8+SlfLHnasAROwYyquRfy9Sw0Zi3rBIZC4TGonHe/xbKO3Ff5KbYO7VyImg2ubIIi7De13PygLTg/ptJIt9m6DfUxV267bZ0cJL9ClAKdAadifSKxRu3eu+7Y=; Received: from [114.121.160.118] (port=27749 helo=X220.alogt.com) by sl-508-2.slc.westdc.net with esmtpa (Exim 4.84) (envelope-from ) id 1XuWDh-002Enp-JD; Fri, 28 Nov 2014 17:49:06 -0700 Date: Sat, 29 Nov 2014 08:49:00 +0800 From: Erich Dollansky To: Eric Gunther Subject: Re: Raspberry Pi composite video problem Message-ID: <20141129084900.10050d11@X220.alogt.com> In-Reply-To: <1417193156.3202.1.camel@warwick.net> References: <1417167767.23507.2.camel@warwick.net> <1417193156.3202.1.camel@warwick.net> Organization: ALO Green Technologies MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sl-508-2.slc.westdc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - alogt.com X-Get-Message-Sender-Via: sl-508-2.slc.westdc.net: authenticated_id: erich@alogt.com X-Source: X-Source-Args: X-Source-Dir: Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Nov 2014 00:49:08 -0000 Hi, On Fri, 28 Nov 2014 11:45:56 -0500 Eric Gunther wrote: > On Fri, 2014-11-28 at 04:42 -0500, Eric Gunther wrote: > > On Thu, 27 Nov 2014 08:25:28 -0500 > > Eric Gunther wrote: > > > > Use telnet for the start to make sure that you avoided the simplest > > problems. You need inetd and /etc/inetd.conf with telnet enabled in > > there. > > > Eureka, I have logged in via ssh. Not sure what is different although > the last few things I did where: > > rechecked /etc/inetd.conf, /etc/rc.conf, /etc/services > > service sshd enable > service sshd reload > > And plugged in the client computer after the RPi had been connected to > the ethernet, worked using IP. > sshd can run without inetd. > telnet was still not functioning. You would need inetd for this but as you have ssh up and running, you will not need this anymore. Erich From owner-freebsd-arm@FreeBSD.ORG Sat Nov 29 02:46:14 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A8A1E275 for ; Sat, 29 Nov 2014 02:46:14 +0000 (UTC) Received: from frontend3.warwick.net (svm.wvtcvoicemail.wvtc.com [204.255.24.104]) by mx1.freebsd.org (Postfix) with SMTP id 4D1C576C for ; Sat, 29 Nov 2014 02:46:13 +0000 (UTC) Received: (qmail 18489 invoked from network); 29 Nov 2014 02:46:11 -0000 Received: from 70.44.113.83.res-cmts.sefg.ptd.net (HELO 70.44.113.83.res-cmts.sefg.ptd.net) (egunther@warwick.net@70.44.113.83) by frontend3.warwick.net with SMTP (e059db98-7771-11e4-9549-0019bb38a71e); Fri, 28 Nov 2014 21:46:11 -0500 Message-ID: <1417229109.1835.2.camel@warwick.net> Subject: Re: Raspberry Pi composite video problem From: Eric Gunther To: Erich Dollansky In-Reply-To: <20141129084900.10050d11@X220.alogt.com> References: <1417167767.23507.2.camel@warwick.net> <1417193156.3202.1.camel@warwick.net> <20141129084900.10050d11@X220.alogt.com> Content-Type: text/plain; charset="UTF-8" Date: Fri, 28 Nov 2014 21:45:09 -0500 Mime-Version: 1.0 X-Mailer: Evolution 3.12.7 Content-Transfer-Encoding: 7bit X-MagicMail-UUID: e059db98-7771-11e4-9549-0019bb38a71e X-MagicMail-Authenticated: egunther@warwick.net X-MagicMail-SourceIP: 70.44.113.83 X-MagicMail-EnvelopeFrom: Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Nov 2014 02:46:14 -0000 On Sat, 2014-11-29 at 08:49 +0800, Erich Dollansky wrote: > Hi, > > On Fri, 28 Nov 2014 11:45:56 -0500 > Eric Gunther wrote: > . > > > > Eureka, I have logged in via ssh. Not sure what is different although > > the last few things I did where: > > > > rechecked /etc/inetd.conf, /etc/rc.conf, /etc/services > > > > service sshd enable > > service sshd reload > > > > And plugged in the client computer after the RPi had been connected to > > the ethernet, worked using IP. > > > sshd can run without inetd. Thanks for telling me. Funny thing, it stopped working afterward and cannot get it working again (ssh). Getting ssh working was, in a way, beside the point. I would like to figure out how to fix the display issue. If I had a working Ethernet connection to the Pi I could; Download the firmware and put it on, Adjust configuration files easier, and Report dmesg or similar message output to the list as needed. I emphasize that this is to more quickly and efficiently fix the display. I realize that you mentioned that you are not able to help with the composite video. So no thoughts on whether the firmware would help that problem? That is, text off the screen. > > > telnet was still not functioning. > > You would need inetd for this but as you have ssh up and running, you > will not need this anymore. Yes. Thanks, --e > > Erich From owner-freebsd-arm@FreeBSD.ORG Sat Nov 29 02:52:16 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DE30F324 for ; Sat, 29 Nov 2014 02:52:15 +0000 (UTC) Received: from alogt.com (alogt.com [69.36.191.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B526A81E for ; Sat, 29 Nov 2014 02:52:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alogt.com; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=MIlk7Fb4S6sKLnXxKKf13EssvoeaSTkxf5R6vuNRtpI=; b=k87SSR5x5y9czl6RhupAG5B3CZfAQslwoz46gZQUsbxZImjdd07XImK/X6Z4jqi6XTyoTlQiqZM8JVEuImKAV1XGvc2R3s3bPpDfZ1dGM0kaLZTcoQ3wmSEOdRdTvh6q0GlGcDxJsYHk9SyB1HCIZjpsfCr1qDKMPs+W7REAPmk=; Received: from [114.121.160.118] (port=26657 helo=X220.alogt.com) by sl-508-2.slc.westdc.net with esmtpa (Exim 4.84) (envelope-from ) id 1XuY8r-002vCh-UI; Fri, 28 Nov 2014 19:52:14 -0700 Date: Sat, 29 Nov 2014 10:52:10 +0800 From: Erich Dollansky To: Eric Gunther Subject: Re: Raspberry Pi composite video problem Message-ID: <20141129105210.5a72a8ec@X220.alogt.com> In-Reply-To: <1417229109.1835.2.camel@warwick.net> References: <1417167767.23507.2.camel@warwick.net> <1417193156.3202.1.camel@warwick.net> <20141129084900.10050d11@X220.alogt.com> <1417229109.1835.2.camel@warwick.net> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sl-508-2.slc.westdc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - alogt.com X-Get-Message-Sender-Via: sl-508-2.slc.westdc.net: authenticated_id: erichsfreebsdlist@alogt.com X-Source: X-Source-Args: X-Source-Dir: Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Nov 2014 02:52:16 -0000 Hi, On Fri, 28 Nov 2014 21:45:09 -0500 Eric Gunther wrote: > On Sat, 2014-11-29 at 08:49 +0800, Erich Dollansky wrote: > > > On Fri, 28 Nov 2014 11:45:56 -0500 > > Eric Gunther wrote: > > . > > > > > > Eureka, I have logged in via ssh. Not sure what is different > > > although the last few things I did where: > > > > > > rechecked /etc/inetd.conf, /etc/rc.conf, /etc/services > > > > > > service sshd enable > > > service sshd reload > > > > > > And plugged in the client computer after the RPi had been > > > connected to the ethernet, worked using IP. > > > > > sshd can run without inetd. > > Thanks for telling me. Funny thing, it stopped working afterward and > cannot get it working again (ssh). Getting ssh working was, in a way, > beside the point. I would like to figure out how to fix the display > issue. If I had a working Ethernet connection to the Pi I could; > Download the firmware and put it on, Adjust configuration files > easier, and Report dmesg or similar message output to the list as > needed. > just put this into your rc.conf: inetd_enable="YES" inetd_flags="-wW -a whateveraddress" and this ftp stream tcp nowait root /usr/libexec/ftpd ftpd -l ftp stream tcp6 nowait root /usr/libexec/ftpd ftpd -l ssh stream tcp nowait root /usr/sbin/sshd sshd -i -4 ssh stream tcp6 nowait root /usr/sbin/sshd sshd -i -6 telnet stream tcp nowait root /usr/libexec/telnetd telnetd telnet stream tcp6 nowait root /usr/libexec/telnetd telnetd into your inetd.conf. If all other things fail, you should be able to transfer files via ftp then. > I emphasize that this is to more quickly and efficiently fix > the display. I realize that you mentioned that you are not able to > help with the composite video. So no thoughts on whether the > firmware would help that problem? That is, text off the screen. > I have the B+ only. The 10.1 firmware should be able to handle the older model without a problem. Erich From owner-freebsd-arm@FreeBSD.ORG Sat Nov 29 11:49:49 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 271EED55 for ; Sat, 29 Nov 2014 11:49:49 +0000 (UTC) Received: from frontend2.warwick.net (lm-3.warwick.net [204.255.24.103]) by mx1.freebsd.org (Postfix) with SMTP id E05D0CD3 for ; Sat, 29 Nov 2014 11:49:47 +0000 (UTC) Received: (qmail 19337 invoked from network); 29 Nov 2014 11:43:07 -0000 Received: from 70.44.113.83.res-cmts.sefg.ptd.net (HELO 70.44.113.83.res-cmts.sefg.ptd.net) (egunther@warwick.net@70.44.113.83) by frontend2.warwick.net with SMTP (e2b1dd32-77bc-11e4-865f-001f2909bf3e); Sat, 29 Nov 2014 06:43:07 -0500 Message-ID: <1417261402.2448.3.camel@warwick.net> Subject: Re: Raspberry Pi composite video problem From: Eric Gunther To: Erich Dollansky Date: Sat, 29 Nov 2014 06:43:22 -0500 In-Reply-To: <20141129105210.5a72a8ec@X220.alogt.com> References: <1417167767.23507.2.camel@warwick.net> <1417193156.3202.1.camel@warwick.net> <20141129084900.10050d11@X220.alogt.com> <1417229109.1835.2.camel@warwick.net> <20141129105210.5a72a8ec@X220.alogt.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.12.7 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-MagicMail-UUID: e2b1dd32-77bc-11e4-865f-001f2909bf3e X-MagicMail-Authenticated: egunther@warwick.net X-MagicMail-SourceIP: 70.44.113.83 X-MagicMail-EnvelopeFrom: Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Nov 2014 11:49:49 -0000 On Sat, 2014-11-29 at 10:52 +0800, Erich Dollansky wrote: > Hi, > > On Fri, 28 Nov 2014 21:45:09 -0500 > Eric Gunther wrote: > > > On Sat, 2014-11-29 at 08:49 +0800, Erich Dollansky wrote: > > > > > On Fri, 28 Nov 2014 11:45:56 -0500 > > > Eric Gunther wrote: > > > . > > > > > > > > Eureka, I have logged in via ssh. Not sure what is different > > > > although the last few things I did where: > > > > > > > > rechecked /etc/inetd.conf, /etc/rc.conf, /etc/services > > > > > > > > service sshd enable > > > > service sshd reload > > > > > > > > And plugged in the client computer after the RPi had been > > > > connected to the ethernet, worked using IP. > > > > > > > sshd can run without inetd. > > > > Thanks for telling me. Funny thing, it stopped working afterward and > > cannot get it working again (ssh). Getting ssh working was, in a way, > > beside the point. I would like to figure out how to fix the display > > issue. If I had a working Ethernet connection to the Pi I could; > > Download the firmware and put it on, Adjust configuration files > > easier, and Report dmesg or similar message output to the list as > > needed. > > > just put this into your rc.conf: > > inetd_enable="YES" > inetd_flags="-wW -a whateveraddress" > > and this > > ftp stream tcp nowait root /usr/libexec/ftpd ftpd -l > ftp stream tcp6 nowait root /usr/libexec/ftpd ftpd -l > ssh stream tcp nowait root /usr/sbin/sshd sshd -i -4 > ssh stream tcp6 nowait root /usr/sbin/sshd sshd -i -6 > telnet stream tcp nowait root /usr/libexec/telnetd telnetd > telnet stream tcp6 nowait root /usr/libexec/telnetd telnetd > > into your inetd.conf. > > If all other things fail, you should be able to transfer files via ftp > then. > I tried multiple ways of accessing the Pi and have not been able to replicate it (ssh,ftp, or telnet success). I just looked at this post again and saw that you had written a wW (lower case w followed by an uppercase w), which is what I initially thought but in my haste didn't notice on second check. I will respond Monday, after I have had a chance to try again. > > I emphasize that this is to more quickly and efficiently fix > > the display. I realize that you mentioned that you are not able to > > help with the composite video. So no thoughts on whether the > > firmware would help that problem? That is, text off the screen. > > > I have the B+ only. The 10.1 firmware should be able to handle the > older model without a problem. OK, thanks, that is what I expected. Should I start a new thread about the questions I have about the video, considering that I have strayed off the original topic? I will just put my questions below. Thanks, --e > Erich What is the way to adjust the low level video input settings aside from /boot/msdos/config.txt? /boot/msdos/uenv.txt? Do I need to compile a kernel with a console driver, or alternate console driver, to use for the display?