From owner-freebsd-stable@FreeBSD.ORG Sun Aug 10 01:17:50 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E2FFD106567A for ; Sun, 10 Aug 2008 01:17:50 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [192.147.25.65]) by mx1.freebsd.org (Postfix) with ESMTP id ADA6A8FC12 for ; Sun, 10 Aug 2008 01:17:50 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from 76-205-169-61.lightspeed.austtx.sbcglobal.net ([76.205.169.61]:55219 helo=borg) by thebighonker.lerctr.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRzMD-0003gH-G3 for freebsd-stable@freebsd.org; Sat, 09 Aug 2008 20:04:32 -0500 Date: Sat, 9 Aug 2008 20:04:26 -0500 (CDT) From: Larry Rosenman Sender: ler@borg To: freebsd-stable@freebsd.org Message-ID: <20080809195935.F4976@borg> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="3935026275-1715592916-1218330266=:4976" X-Spam-Score: 0.2 (/) X-LERCTR-Spam-Score: 0.2 (/) X-Spam-Report: SpamScore (0.2/5.0) ALL_TRUSTED=-1.8, BAYES_00=-2.599, FM_MULTI_ODD2=1.1, FM_MULTI_ODD3=0.7, TVD_RCVD_IP=1.931, TW_BD=0.077, TW_BF=0.077, TW_BP=0.077, TW_CB=0.077, TW_DR=0.077, TW_KB=0.077, TW_TK=0.077, TW_UH=0.077, TW_VP=0.077, TW_XB=0.077, TW_XC=0.077 X-LERCTR-Spam-Report: SpamScore (0.2/5.0) ALL_TRUSTED=-1.8, BAYES_00=-2.599, FM_MULTI_ODD2=1.1, FM_MULTI_ODD3=0.7, TVD_RCVD_IP=1.931, TW_BD=0.077, TW_BF=0.077, TW_BP=0.077, TW_CB=0.077, TW_DR=0.077, TW_KB=0.077, TW_TK=0.077, TW_UH=0.077, TW_VP=0.077, TW_XB=0.077, TW_XC=0.077 DomainKey-Status: no signature Subject: IPMI Console: No luck once OS is booted X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Aug 2008 01:17:51 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --3935026275-1715592916-1218330266=:4976 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed I have a current RELENG_7 running on: http://www.supermicro.com/products/system/4U/7045/SYS-7045B-TR+.cfm with the -3+ IPMI card. I can interact with the BIOS, etc, but no joy once we get past the loader. Anyone have ideas? Attached is the kernel config, and the /var/run/dmesg.boot file. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 --3935026275-1715592916-1218330266=:4976 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=BORG Content-Transfer-Encoding: BASE64 Content-ID: <20080809200426.C4976@borg> Content-Description: Kernel Config Content-Disposition: attachment; filename=BORG Iw0KIw0KIyBGb3IgbW9yZSBpbmZvcm1hdGlvbiBvbiB0aGlzIGZpbGUsIHBs ZWFzZSByZWFkIHRoZSBoYW5kYm9vayBzZWN0aW9uIG9uDQojIEtlcm5lbCBD b25maWd1cmF0aW9uIEZpbGVzOg0KIw0KIyAgICBodHRwOi8vd3d3LkZyZWVC U0Qub3JnL2RvYy9lbl9VUy5JU084ODU5LTEvYm9va3MvaGFuZGJvb2sva2Vy bmVsY29uZmlnLWNvbmZpZy5odG1sDQojDQojIFRoZSBoYW5kYm9vayBpcyBh bHNvIGF2YWlsYWJsZSBsb2NhbGx5IGluIC91c3Ivc2hhcmUvZG9jL2hhbmRi b29rDQojIGlmIHlvdSd2ZSBpbnN0YWxsZWQgdGhlIGRvYyBkaXN0cmlidXRp b24sIG90aGVyd2lzZSBhbHdheXMgc2VlIHRoZQ0KIyBGcmVlQlNEIFdvcmxk IFdpZGUgV2ViIHNlcnZlciAoaHR0cDovL3d3dy5GcmVlQlNELm9yZy8pIGZv ciB0aGUNCiMgbGF0ZXN0IGluZm9ybWF0aW9uLg0KIw0KIyBBbiBleGhhdXN0 aXZlIGxpc3Qgb2Ygb3B0aW9ucyBhbmQgbW9yZSBkZXRhaWxlZCBleHBsYW5h dGlvbnMgb2YgdGhlDQojIGRldmljZSBsaW5lcyBpcyBhbHNvIHByZXNlbnQg aW4gdGhlIC4uLy4uL2NvbmYvTk9URVMgYW5kIE5PVEVTIGZpbGVzLg0KIyBJ ZiB5b3UgYXJlIGluIGRvdWJ0IGFzIHRvIHRoZSBwdXJwb3NlIG9yIG5lY2Vz c2l0eSBvZiBhIGxpbmUsIGNoZWNrIGZpcnN0DQojIGluIE5PVEVTLg0KIw0K IyAkRnJlZUJTRDogc3JjL3N5cy9hbWQ2NC9jb25mL0dFTkVSSUMsdiAxLjQ3 NSAyMDA3LzA0LzEwIDIxOjQwOjEyIHBqZCBFeHAgJA0KDQpjcHUJCUhBTU1F Ug0KaWRlbnQJCUJPUkcNCg0KIyBUbyBzdGF0aWNhbGx5IGNvbXBpbGUgaW4g ZGV2aWNlIHdpcmluZyBpbnN0ZWFkIG9mIC9ib290L2RldmljZS5oaW50cw0K I2hpbnRzCQkiR0VORVJJQy5oaW50cyIJCSMgRGVmYXVsdCBwbGFjZXMgdG8g bG9vayBmb3IgZGV2aWNlcy4NCg0KbWFrZW9wdGlvbnMJREVCVUc9LWcJCSMg QnVpbGQga2VybmVsIHdpdGggZ2RiKDEpIGRlYnVnIHN5bWJvbHMNCg0KI29w dGlvbnMgCVNDSEVEXzRCU0QJCSMgNEJTRCBzY2hlZHVsZXINCm9wdGlvbnMg CVNDSEVEX1VMRSAJCSMgVUxFIHNjaGVkdWxlcg0Kb3B0aW9ucyAJUFJFRU1Q VElPTgkJIyBFbmFibGUga2VybmVsIHRocmVhZCBwcmVlbXB0aW9uDQpvcHRp b25zIAlJTkVUCQkJIyBJbnRlck5FVHdvcmtpbmcNCm9wdGlvbnMgCUlORVQ2 CQkJIyBJUHY2IGNvbW11bmljYXRpb25zIHByb3RvY29scw0Kb3B0aW9ucyAJ RkZTCQkJIyBCZXJrZWxleSBGYXN0IEZpbGVzeXN0ZW0NCm9wdGlvbnMgCVNP RlRVUERBVEVTCQkjIEVuYWJsZSBGRlMgc29mdCB1cGRhdGVzIHN1cHBvcnQN Cm9wdGlvbnMgCVVGU19BQ0wJCQkjIFN1cHBvcnQgZm9yIGFjY2VzcyBjb250 cm9sIGxpc3RzDQpvcHRpb25zIAlVRlNfRElSSEFTSAkJIyBJbXByb3ZlIHBl cmZvcm1hbmNlIG9uIGJpZyBkaXJlY3Rvcmllcw0Kb3B0aW9ucyAJVUZTX0dK T1VSTkFMCQkjIEVuYWJsZSBnam91cm5hbC1iYXNlZCBVRlMgam91cm5hbGlu Zw0Kb3B0aW9ucyAJTURfUk9PVAkJCSMgTUQgaXMgYSBwb3RlbnRpYWwgcm9v dCBkZXZpY2UNCm9wdGlvbnMgCU5GU0NMSUVOVAkJIyBOZXR3b3JrIEZpbGVz eXN0ZW0gQ2xpZW50DQpvcHRpb25zIAlORlNTRVJWRVIJCSMgTmV0d29yayBG aWxlc3lzdGVtIFNlcnZlcg0Kb3B0aW9ucyAJTkZTX1JPT1QJCSMgTkZTIHVz YWJsZSBhcyAvLCByZXF1aXJlcyBORlNDTElFTlQNCm9wdGlvbnMgCU5URlMJ CQkjIE5UIEZpbGUgU3lzdGVtDQpvcHRpb25zIAlNU0RPU0ZTCQkJIyBNU0RP UyBGaWxlc3lzdGVtDQpvcHRpb25zIAlDRDk2NjAJCQkjIElTTyA5NjYwIEZp bGVzeXN0ZW0NCm9wdGlvbnMgCVBST0NGUwkJCSMgUHJvY2VzcyBmaWxlc3lz dGVtIChyZXF1aXJlcyBQU0VVRE9GUykNCm9wdGlvbnMgCVBTRVVET0ZTCQkj IFBzZXVkby1maWxlc3lzdGVtIGZyYW1ld29yaw0Kb3B0aW9ucyAJR0VPTV9Q QVJUX0dQVAkJIyBHVUlEIFBhcnRpdGlvbiBUYWJsZXMuDQpvcHRpb25zIAlH RU9NX0xBQkVMCQkjIFByb3ZpZGVzIGxhYmVsaXphdGlvbg0Kb3B0aW9ucyAJ Q09NUEFUXzQzVFRZCQkjIEJTRCA0LjMgVFRZIGNvbXBhdCBbS0VFUCBUSElT IV0NCm9wdGlvbnMgCUNPTVBBVF9JQTMyCQkjIENvbXBhdGlibGUgd2l0aCBp Mzg2IGJpbmFyaWVzDQpvcHRpb25zIAlDT01QQVRfRlJFRUJTRDQJCSMgQ29t cGF0aWJsZSB3aXRoIEZyZWVCU0Q0DQpvcHRpb25zIAlDT01QQVRfRlJFRUJT RDUJCSMgQ29tcGF0aWJsZSB3aXRoIEZyZWVCU0Q1DQpvcHRpb25zIAlDT01Q QVRfRlJFRUJTRDYJCSMgQ29tcGF0aWJsZSB3aXRoIEZyZWVCU0Q2DQpvcHRp b25zIAlTQ1NJX0RFTEFZPTUwMDAJCSMgRGVsYXkgKGluIG1zKSBiZWZvcmUg cHJvYmluZyBTQ1NJDQpvcHRpb25zIAlLVFJBQ0UJCQkjIGt0cmFjZSgxKSBz dXBwb3J0DQpvcHRpb25zIAlTWVNWU0hNCQkJIyBTWVNWLXN0eWxlIHNoYXJl ZCBtZW1vcnkNCm9wdGlvbnMgCVNZU1ZNU0cJCQkjIFNZU1Ytc3R5bGUgbWVz c2FnZSBxdWV1ZXMNCm9wdGlvbnMgCVNZU1ZTRU0JCQkjIFNZU1Ytc3R5bGUg c2VtYXBob3Jlcw0Kb3B0aW9ucyAJX0tQT1NJWF9QUklPUklUWV9TQ0hFRFVM SU5HICMgUE9TSVggUDEwMDNfMUIgcmVhbC10aW1lIGV4dGVuc2lvbnMNCm9w dGlvbnMgCUtCRF9JTlNUQUxMX0NERVYJIyBpbnN0YWxsIGEgQ0RFViBlbnRy eSBpbiAvZGV2DQpvcHRpb25zIAlBREFQVElWRV9HSUFOVAkJIyBHaWFudCBt dXRleCBpcyBhZGFwdGl2ZS4NCiNvcHRpb25zIAlTVE9QX05NSQkJIyBTdG9w IENQVVMgdXNpbmcgTk1JIGluc3RlYWQgb2YgSVBJDQpvcHRpb25zCQlBVURJ VA0Kb3B0aW9ucwkJSU5DTFVERV9DT05GSUdfRklMRQ0KDQojIERlYnVnZ2lu ZyBmb3IgdXNlIGluIC1jdXJyZW50DQpvcHRpb25zIAlLREIJCQkjIEVuYWJs ZSBrZXJuZWwgZGVidWdnZXIgc3VwcG9ydC4NCm9wdGlvbnMgCUtEQl9UUkFD RQkJIyBFbmFibGUga2VybmVsIGRlYnVnZ2VyIHN1cHBvcnQuDQpvcHRpb25z IAlLREJfVU5BVFRFTkRFRAkJIyBFbmFibGUga2VybmVsIGRlYnVnZ2VyIHN1 cHBvcnQuDQpvcHRpb25zIAlEREIJCQkjIFN1cHBvcnQgRERCLg0Kb3B0aW9u cyAJR0RCCQkJIyBTdXBwb3J0IHJlbW90ZSBHREIuDQpvcHRpb25zCQlTVEFD Sw0KI29wdGlvbnMgCUlOVkFSSUFOVFMJCSMgRW5hYmxlIGNhbGxzIG9mIGV4 dHJhIHNhbml0eSBjaGVja2luZw0KI29wdGlvbnMgCUlOVkFSSUFOVF9TVVBQ T1JUCSMgRXh0cmEgc2FuaXR5IGNoZWNrcyBvZiBpbnRlcm5hbCBzdHJ1Y3R1 cmVzLCByZXF1aXJlZCBieSBJTlZBUklBTlRTDQojb3B0aW9ucyAJV0lUTkVT UwkJCSMgRW5hYmxlIGNoZWNrcyB0byBkZXRlY3QgZGVhZGxvY2tzIGFuZCBj eWNsZXMNCiNvcHRpb25zIAlXSVRORVNTX1NLSVBTUElOCSMgRG9uJ3QgcnVu IHdpdG5lc3Mgb24gc3BpbmxvY2tzIGZvciBzcGVlZA0KDQojIE1ha2UgYW4g U01QLWNhcGFibGUga2VybmVsIGJ5IGRlZmF1bHQNCm9wdGlvbnMgCVNNUAkJ CSMgU3ltbWV0cmljIE11bHRpUHJvY2Vzc29yIEtlcm5lbA0KDQojIEJ1cyBz dXBwb3J0Lg0KZGV2aWNlCQlhY3BpDQpkZXZpY2UJCXBjaQ0KDQojIEZsb3Bw eSBkcml2ZXMNCmRldmljZQkJZmRjDQoNCiMgQVRBIGFuZCBBVEFQSSBkZXZp Y2VzDQpkZXZpY2UJCWF0YQ0KZGV2aWNlCQlhdGFkaXNrCQkjIEFUQSBkaXNr IGRyaXZlcw0KZGV2aWNlCQlhdGFyYWlkCQkjIEFUQSBSQUlEIGRyaXZlcw0K ZGV2aWNlCQlhdGFwaWNkCQkjIEFUQVBJIENEUk9NIGRyaXZlcw0KZGV2aWNl CQlhdGFwaWZkCQkjIEFUQVBJIGZsb3BweSBkcml2ZXMNCmRldmljZQkJYXRh cGlzdAkJIyBBVEFQSSB0YXBlIGRyaXZlcw0KZGV2aWNlCQlhdGFwaWNhbQkj IEFUQSBDQU0gTGF5ZXINCm9wdGlvbnMgCUFUQV9TVEFUSUNfSUQJIyBTdGF0 aWMgZGV2aWNlIG51bWJlcmluZw0KDQoNCiMgU0NTSSBwZXJpcGhlcmFscw0K ZGV2aWNlCQlzY2J1cwkJIyBTQ1NJIGJ1cyAocmVxdWlyZWQgZm9yIFNDU0kp DQpkZXZpY2UJCWNoCQkjIFNDU0kgbWVkaWEgY2hhbmdlcnMNCmRldmljZQkJ ZGEJCSMgRGlyZWN0IEFjY2VzcyAoZGlza3MpDQpkZXZpY2UJCXNhCQkjIFNl cXVlbnRpYWwgQWNjZXNzICh0YXBlIGV0YykNCmRldmljZQkJY2QJCSMgQ0QN CmRldmljZQkJcGFzcwkJIyBQYXNzdGhyb3VnaCBkZXZpY2UgKGRpcmVjdCBT Q1NJIGFjY2VzcykNCmRldmljZQkJc2VzCQkjIFNDU0kgRW52aXJvbm1lbnRh bCBTZXJ2aWNlcyAoYW5kIFNBRi1URSkNCmRldmljZQkJc2cJCSMgTGludXgg U0cgU3R1ZmYNCg0KDQojIGF0a2JkYzAgY29udHJvbHMgYm90aCB0aGUga2V5 Ym9hcmQgYW5kIHRoZSBQUy8yIG1vdXNlDQpkZXZpY2UJCWF0a2JkYwkJIyBB VCBrZXlib2FyZCBjb250cm9sbGVyDQpkZXZpY2UJCWF0a2JkCQkjIEFUIGtl eWJvYXJkDQpkZXZpY2UJCXBzbQkJIyBQUy8yIG1vdXNlDQoNCmRldmljZQkJ a2JkbXV4CQkjIGtleWJvYXJkIG11bHRpcGxleGVyDQoNCmRldmljZQkJdmdh CQkjIFZHQSB2aWRlbyBjYXJkIGRyaXZlcg0KDQpkZXZpY2UJCXNwbGFzaAkJ IyBTcGxhc2ggc2NyZWVuIGFuZCBzY3JlZW4gc2F2ZXIgc3VwcG9ydA0KDQoj IHN5c2NvbnMgaXMgdGhlIGRlZmF1bHQgY29uc29sZSBkcml2ZXIsIHJlc2Vt YmxpbmcgYW4gU0NPIGNvbnNvbGUNCmRldmljZQkJc2MNCg0KZGV2aWNlCQlh Z3AJCSMgc3VwcG9ydCBzZXZlcmFsIEFHUCBjaGlwc2V0cw0KDQojIFNlcmlh bCAoQ09NKSBwb3J0cw0KI2RldmljZQkJc2lvCQkjIDgyNTAsIDE2WzQ1XTUw IGJhc2VkIHNlcmlhbCBwb3J0cw0KZGV2aWNlCQl1YXJ0CQkjIEdlbmVyaWMg VUFSVCBkcml2ZXINCg0KIyBQYXJhbGxlbCBwb3J0DQpkZXZpY2UJCXBwYw0K ZGV2aWNlCQlwcGJ1cwkJIyBQYXJhbGxlbCBwb3J0IGJ1cyAocmVxdWlyZWQp DQpkZXZpY2UJCWxwdAkJIyBQcmludGVyDQpkZXZpY2UJCXBwaQkJIyBQYXJh bGxlbCBwb3J0IGludGVyZmFjZSBkZXZpY2UNCiNkZXZpY2UJCXZwbwkJIyBS ZXF1aXJlcyBzY2J1cyBhbmQgZGENCg0KIyBJZiB5b3UndmUgZ290IGEgImR1 bWIiIHNlcmlhbCBvciBwYXJhbGxlbCBQQ0kgY2FyZCB0aGF0IGlzDQojIHN1 cHBvcnRlZCBieSB0aGUgcHVjKDQpIGdsdWUgZHJpdmVyLCB1bmNvbW1lbnQg dGhlIGZvbGxvd2luZw0KIyBsaW5lIHRvIGVuYWJsZSBpdCAoY29ubmVjdHMg dG8gc2lvLCB1YXJ0IGFuZC9vciBwcGMgZHJpdmVycyk6DQojZGV2aWNlCQlw dWMNCg0KIyBQQ0kgRXRoZXJuZXQgTklDcy4NCmRldmljZQkJZW0JCSMgSW50 ZWwgUFJPLzEwMDAgYWRhcHRlciBHaWdhYml0IEV0aGVybmV0IENhcmQNCg0K DQojIFdpcmVsZXNzIE5JQyBjYXJkcw0KI2RldmljZQkJd2xhbgkJIyA4MDIu MTEgc3VwcG9ydA0KI2RldmljZQkJd2xhbl93ZXAJIyA4MDIuMTEgV0VQIHN1 cHBvcnQNCiNkZXZpY2UJCXdsYW5fY2NtcAkjIDgwMi4xMSBDQ01QIHN1cHBv cnQNCiNkZXZpY2UJCXdsYW5fdGtpcAkjIDgwMi4xMSBUS0lQIHN1cHBvcnQN CiNkZXZpY2UJCXdsYW5fYW1ycgkjIDgwMi4xMSBBTVJSIHN1cHBvcnQNCg0K IyBQc2V1ZG8gZGV2aWNlcy4NCmRldmljZQkJbG9vcAkJIyBOZXR3b3JrIGxv b3BiYWNrDQpkZXZpY2UJCXJhbmRvbQkJIyBFbnRyb3B5IGRldmljZQ0KZGV2 aWNlCQlldGhlcgkJIyBFdGhlcm5ldCBzdXBwb3J0DQpkZXZpY2UJCXNsCQkj IEtlcm5lbCBTTElQDQpkZXZpY2UJCXBwcAkJIyBLZXJuZWwgUFBQDQpkZXZp Y2UJCXR1bgkJIyBQYWNrZXQgdHVubmVsLg0KZGV2aWNlCQlwdHkJCSMgUHNl dWRvLXR0eXMgKHRlbG5ldCBldGMpDQpkZXZpY2UJCW1kCQkjIE1lbW9yeSAi ZGlza3MiDQpkZXZpY2UJCWdpZgkJIyBJUHY2IGFuZCBJUHY0IHR1bm5lbGlu Zw0KZGV2aWNlCQlmYWl0aAkJIyBJUHY2LXRvLUlQdjQgcmVsYXlpbmcgKHRy YW5zbGF0aW9uKQ0KZGV2aWNlCQlmaXJtd2FyZQkjIGZpcm13YXJlIGFzc2lz dCBtb2R1bGUNCg0KIyBUaGUgYGJwZicgZGV2aWNlIGVuYWJsZXMgdGhlIEJl cmtlbGV5IFBhY2tldCBGaWx0ZXIuDQojIEJlIGF3YXJlIG9mIHRoZSBhZG1p bmlzdHJhdGl2ZSBjb25zZXF1ZW5jZXMgb2YgZW5hYmxpbmcgdGhpcyENCiMg Tm90ZSB0aGF0ICdicGYnIGlzIHJlcXVpcmVkIGZvciBESENQLg0KZGV2aWNl CQlicGYJCSMgQmVya2VsZXkgcGFja2V0IGZpbHRlcg0KDQojIFVTQiBzdXBw b3J0DQpkZXZpY2UJCXVoY2kJCSMgVUhDSSBQQ0ktPlVTQiBpbnRlcmZhY2UN CmRldmljZQkJZWhjaQkJIyBFSENJIFBDSS0+VVNCIGludGVyZmFjZSAoVVNC IDIuMCkNCmRldmljZQkJdXNiCQkjIFVTQiBCdXMgKHJlcXVpcmVkKQ0KZGV2 aWNlCQl1Z2VuCQkjIEdlbmVyaWMNCmRldmljZQkJdWhpZAkJIyAiSHVtYW4g SW50ZXJmYWNlIERldmljZXMiDQpkZXZpY2UJCXVrYmQJCSMgS2V5Ym9hcmQN CmRldmljZQkJdWxwdAkJIyBQcmludGVyDQpkZXZpY2UJCXVtYXNzCQkjIERp c2tzL01hc3Mgc3RvcmFnZSAtIFJlcXVpcmVzIHNjYnVzIGFuZCBkYQ0KZGV2 aWNlCQl1bXMJCSMgTW91c2UNCiNkZXZpY2UJCXVyYWwJCSMgUmFsaW5rIFRl Y2hub2xvZ3kgUlQyNTAwVVNCIHdpcmVsZXNzIE5JQ3MNCmRldmljZQkJdXJp bwkJIyBEaWFtb25kIFJpbyA1MDAgTVAzIHBsYXllcg0KZGV2aWNlCQl1c2Nh bm5lcgkjIFNjYW5uZXJzDQojIyMjIyMjIyMjIyMjDQojIFRoZSBjcHVmcmVx KDQpIGRyaXZlciBwcm92aWRlcyBzdXBwb3J0IGZvciBub24tQUNQSSBDUFUg ZnJlcXVlbmN5IGNvbnRyb2wNCmRldmljZSAgICAgICAgICBjcHVmcmVxDQoN CiMgRGlyZWN0IFJlbmRlcmluZyBtb2R1bGVzIGZvciAzRCBhY2NlbGVyYXRp b24uDQpkZXZpY2UgICAgICAgICAgZHJtICAgICAgICAgICAgICMgRFJNIGNv cmUgbW9kdWxlIHJlcXVpcmVkIGJ5IERSTSBkcml2ZXJzDQpkZXZpY2UgICAg ICAgICAgcmFkZW9uZHJtICAgICAgICMgQVRJIFJhZGVvbg0Kb3B0aW9ucwkJ SFdQTUNfSE9PS1MNCmRldmljZSAgICAgICAgICBzbWJ1cyAgICAgICAgICAg IyBCdXMgc3VwcG9ydCwgcmVxdWlyZWQgZm9yIHNtYiBiZWxvdy4NCg0KZGV2 aWNlICAgICAgICAgIGludHBtDQpkZXZpY2UgICAgICAgICAgaWNoc21iDQoN CmRldmljZSAgICAgICAgICBzbWINCmRldmljZSAgICAgICAgICBpaWNidXMg ICAgICAgICAgIyBCdXMgc3VwcG9ydCwgcmVxdWlyZWQgZm9yIGljL2lpYy9p aWNzbWIgYmVsb3cuDQpkZXZpY2UgICAgICAgICAgaWljYmINCg0KZGV2aWNl ICAgICAgICAgIGljDQpkZXZpY2UgICAgICAgICAgaWljDQpkZXZpY2UgICAg ICAgICAgaWljc21iICAgICAgICAgICMgc21iIG92ZXIgaTJjIGJyaWRnZQ0K ZGV2aWNlICAgICAgICAgIGNyeXB0byAgICAgICAgICAjIGNvcmUgY3J5cHRv IHN1cHBvcnQNCmRldmljZSAgICAgICAgICBjcnlwdG9kZXYgICAgICAgIyAv ZGV2L2NyeXB0byBmb3IgYWNjZXNzIHRvIGgvdw0KDQpkZXZpY2UgICAgICAg ICAgcm5kdGVzdCAgICAgICAgICMgRklQUyAxNDAtMiBlbnRyb3B5IHRlc3Rl cg0KZGV2aWNlCQlpcG1pDQpvcHRpb25zCQlTQ1RQDQpvcHRpb25zCQlCUkVB S19UT19ERUJVR0dFUg0Kb3B0aW9ucwkJQUxUX0JSRUFLX1RPX0RFQlVHR0VS DQoNCmRldmljZQkJY29yZXRlbXAJIyBDb3JlIHRlbXAgKENPUkUgcHJvY3Mg YW5kIG5ld2VyKQ0K --3935026275-1715592916-1218330266=:4976 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=dmesg.boot Content-Transfer-Encoding: BASE64 Content-ID: <20080809200426.U4976@borg> Content-Description: Boot DMESG Content-Disposition: attachment; filename=dmesg.boot Q29weXJpZ2h0IChjKSAxOTkyLTIwMDggVGhlIEZyZWVCU0QgUHJvamVjdC4N CkNvcHlyaWdodCAoYykgMTk3OSwgMTk4MCwgMTk4MywgMTk4NiwgMTk4OCwg MTk4OSwgMTk5MSwgMTk5MiwgMTk5MywgMTk5NA0KCVRoZSBSZWdlbnRzIG9m IHRoZSBVbml2ZXJzaXR5IG9mIENhbGlmb3JuaWEuIEFsbCByaWdodHMgcmVz ZXJ2ZWQuDQpGcmVlQlNEIGlzIGEgcmVnaXN0ZXJlZCB0cmFkZW1hcmsgb2Yg VGhlIEZyZWVCU0QgRm91bmRhdGlvbi4NCkZyZWVCU0QgNy4wLVNUQUJMRSAj MjogRnJpIEF1ZyAgOCAyMjo0MTo0OCBDRFQgMjAwOA0KICAgIHJvb3RAYm9y Zy5sZXJjdHIub3JnOi91c3Ivb2JqL3Vzci9zcmMvc3lzL0JPUkcNClRpbWVj b3VudGVyICJpODI1NCIgZnJlcXVlbmN5IDExOTMxODIgSHogcXVhbGl0eSAw DQpDUFU6IEludGVsKFIpIFhlb24oUikgQ1BVICAgICAgICAgICAgNTEyMCAg QCAxLjg2R0h6ICgxODYyLjAyLU1IeiBLOC1jbGFzcyBDUFUpDQogIE9yaWdp biA9ICJHZW51aW5lSW50ZWwiICBJZCA9IDB4NmY2ICBTdGVwcGluZyA9IDYN CiAgRmVhdHVyZXM9MHhiZmViZmJmZjxGUFUsVk1FLERFLFBTRSxUU0MsTVNS LFBBRSxNQ0UsQ1g4LEFQSUMsU0VQLE1UUlIsUEdFLE1DQSxDTU9WLFBBVCxQ U0UzNixDTEZMVVNILERUUyxBQ1BJLE1NWCxGWFNSLFNTRSxTU0UyLFNTLEhU VCxUTSxQQkU+DQogIEZlYXR1cmVzMj0weDRlM2JkPFNTRTMsUlNWRDIsTU9O LERTX0NQTCxWTVgsRVNULFRNMixTU1NFMyxDWDE2LHhUUFIsUERDTSxEQ0E+ DQogIEFNRCBGZWF0dXJlcz0weDIwMTAwODAwPFNZU0NBTEwsTlgsTE0+DQog IEFNRCBGZWF0dXJlczI9MHgxPExBSEY+DQogIENvcmVzIHBlciBwYWNrYWdl OiAyDQp1c2FibGUgbWVtb3J5ID0gNDI4NDA0NzM2MCAoNDA4NSBNQikNCmF2 YWlsIG1lbW9yeSAgPSA0MTEzNTA2MzA0ICgzOTIyIE1CKQ0KQUNQSSBBUElD IFRhYmxlOiA8UFRMVEQgIAkgQVBJQyAgPg0KRnJlZUJTRC9TTVA6IE11bHRp cHJvY2Vzc29yIFN5c3RlbSBEZXRlY3RlZDogNCBDUFVzDQogY3B1MCAoQlNQ KTogQVBJQyBJRDogIDANCiBjcHUxIChBUCk6IEFQSUMgSUQ6ICAxDQogY3B1 MiAoQVApOiBBUElDIElEOiAgNg0KIGNwdTMgKEFQKTogQVBJQyBJRDogIDcN CmlvYXBpYzAgPFZlcnNpb24gMi4wPiBpcnFzIDAtMjMgb24gbW90aGVyYm9h cmQNCmlvYXBpYzEgPFZlcnNpb24gMi4wPiBpcnFzIDI0LTQ3IG9uIG1vdGhl cmJvYXJkDQprYmQxIGF0IGtiZG11eDANCmNyeXB0b3NvZnQwOiA8c29mdHdh cmUgY3J5cHRvPiBvbiBtb3RoZXJib2FyZA0KYWNwaTA6IDxQVExURCAgIFJT RFQ+IG9uIG1vdGhlcmJvYXJkDQphY3BpMDogW0lUSFJFQURdDQphY3BpMDog UG93ZXIgQnV0dG9uIChmaXhlZCkNClRpbWVjb3VudGVyICJBQ1BJLWZhc3Qi IGZyZXF1ZW5jeSAzNTc5NTQ1IEh6IHF1YWxpdHkgMTAwMA0KYWNwaV90aW1l cjA6IDwyNC1iaXQgdGltZXIgYXQgMy41Nzk1NDVNSHo+IHBvcnQgMHgxMDA4 LTB4MTAwYiBvbiBhY3BpMA0KcGNpYjA6IDxBQ1BJIEhvc3QtUENJIGJyaWRn ZT4gcG9ydCAweGNmOC0weGNmZiBvbiBhY3BpMA0KcGNpMDogPEFDUEkgUENJ IGJ1cz4gb24gcGNpYjANCnBjaWIxOiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4g YXQgZGV2aWNlIDIuMCBvbiBwY2kwDQpwY2kxOiA8QUNQSSBQQ0kgYnVzPiBv biBwY2liMQ0KcGNpYjI6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBpcnEgMTYg YXQgZGV2aWNlIDAuMCBvbiBwY2kxDQpwY2kyOiA8QUNQSSBQQ0kgYnVzPiBv biBwY2liMg0KcGNpYjM6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBpcnEgMTYg YXQgZGV2aWNlIDAuMCBvbiBwY2kyDQpwY2kzOiA8QUNQSSBQQ0kgYnVzPiBv biBwY2liMw0KcGNpYjQ6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZp Y2UgMC4wIG9uIHBjaTMNCnBjaTQ6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWI0 DQpwY2liNTogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGF0IGRldmljZSAwLjIg b24gcGNpMw0KcGNpNTogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjUNCnBjaWI2 OiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gaXJxIDE4IGF0IGRldmljZSAyLjAg b24gcGNpMg0KcGNpNjogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjYNCmVtMDog PEludGVsKFIpIFBSTy8xMDAwIE5ldHdvcmsgQ29ubmVjdGlvbiA2LjkuNT4g cG9ydCAweDIwMDAtMHgyMDFmIG1lbSAweGQ4MDAwMDAwLTB4ZDgwMWZmZmYg aXJxIDE4IGF0IGRldmljZSAwLjAgb24gcGNpNg0KZW0wOiBVc2luZyBNU0kg aW50ZXJydXB0DQplbTA6IFtGSUxURVJdDQplbTA6IEV0aGVybmV0IGFkZHJl c3M6IDAwOjMwOjQ4OjhlOjlmOmYzDQplbTE6IDxJbnRlbChSKSBQUk8vMTAw MCBOZXR3b3JrIENvbm5lY3Rpb24gNi45LjU+IHBvcnQgMHgyMDIwLTB4MjAz ZiBtZW0gMHhkODAyMDAwMC0weGQ4MDNmZmZmIGlycSAxOSBhdCBkZXZpY2Ug MC4xIG9uIHBjaTYNCmVtMTogVXNpbmcgTVNJIGludGVycnVwdA0KZW0xOiBb RklMVEVSXQ0KZW0xOiBFdGhlcm5ldCBhZGRyZXNzOiAwMDozMDo0ODo4ZTo5 ZjpmMg0KcGNpYjc6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2Ug MC4zIG9uIHBjaTENCnBjaTc6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWI3DQpw Y2liODogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGF0IGRldmljZSA0LjAgb24g cGNpMA0KcGNpODogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjgNCnBjaWI5OiA8 QUNQSSBQQ0ktUENJIGJyaWRnZT4gYXQgZGV2aWNlIDYuMCBvbiBwY2kwDQpw Y2k5OiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liOQ0KcGNpMDogPGJhc2UgcGVy aXBoZXJhbD4gYXQgZGV2aWNlIDguMCAobm8gZHJpdmVyIGF0dGFjaGVkKQ0K cGNpYjEwOiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gaXJxIDE3IGF0IGRldmlj ZSAyOC4wIG9uIHBjaTANCnBjaTEwOiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2li MTANCnVoY2kwOiA8SW50ZWwgNjMxWEVTQi82MzJYRVNCLzMxMDAgVVNCIGNv bnRyb2xsZXIgVVNCLTE+IHBvcnQgMHgxODAwLTB4MTgxZiBpcnEgMTcgYXQg ZGV2aWNlIDI5LjAgb24gcGNpMA0KdWhjaTA6IFtHSUFOVC1MT0NLRURdDQp1 aGNpMDogW0lUSFJFQURdDQp1c2IwOiA8SW50ZWwgNjMxWEVTQi82MzJYRVNC LzMxMDAgVVNCIGNvbnRyb2xsZXIgVVNCLTE+IG9uIHVoY2kwDQp1c2IwOiBV U0IgcmV2aXNpb24gMS4wDQp1aHViMDogPEludGVsIFVIQ0kgcm9vdCBodWIs IGNsYXNzIDkvMCwgcmV2IDEuMDAvMS4wMCwgYWRkciAxPiBvbiB1c2IwDQp1 aHViMDogMiBwb3J0cyB3aXRoIDIgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQN CnVoY2kxOiA8SW50ZWwgNjMxWEVTQi82MzJYRVNCLzMxMDAgVVNCIGNvbnRy b2xsZXIgVVNCLTI+IHBvcnQgMHgxODIwLTB4MTgzZiBpcnEgMTkgYXQgZGV2 aWNlIDI5LjEgb24gcGNpMA0KdWhjaTE6IFtHSUFOVC1MT0NLRURdDQp1aGNp MTogW0lUSFJFQURdDQp1c2IxOiA8SW50ZWwgNjMxWEVTQi82MzJYRVNCLzMx MDAgVVNCIGNvbnRyb2xsZXIgVVNCLTI+IG9uIHVoY2kxDQp1c2IxOiBVU0Ig cmV2aXNpb24gMS4wDQp1aHViMTogPEludGVsIFVIQ0kgcm9vdCBodWIsIGNs YXNzIDkvMCwgcmV2IDEuMDAvMS4wMCwgYWRkciAxPiBvbiB1c2IxDQp1aHVi MTogMiBwb3J0cyB3aXRoIDIgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQNCnVo Y2kyOiA8SW50ZWwgNjMxWEVTQi82MzJYRVNCLzMxMDAgVVNCIGNvbnRyb2xs ZXIgVVNCLTM+IHBvcnQgMHgxODQwLTB4MTg1ZiBpcnEgMTggYXQgZGV2aWNl IDI5LjIgb24gcGNpMA0KdWhjaTI6IFtHSUFOVC1MT0NLRURdDQp1aGNpMjog W0lUSFJFQURdDQp1c2IyOiA8SW50ZWwgNjMxWEVTQi82MzJYRVNCLzMxMDAg VVNCIGNvbnRyb2xsZXIgVVNCLTM+IG9uIHVoY2kyDQp1c2IyOiBVU0IgcmV2 aXNpb24gMS4wDQp1aHViMjogPEludGVsIFVIQ0kgcm9vdCBodWIsIGNsYXNz IDkvMCwgcmV2IDEuMDAvMS4wMCwgYWRkciAxPiBvbiB1c2IyDQp1aHViMjog MiBwb3J0cyB3aXRoIDIgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQNCmVoY2kw OiA8SW50ZWwgNjNYWEVTQiBVU0IgMi4wIGNvbnRyb2xsZXI+IG1lbSAweGQ4 NTAwNDAwLTB4ZDg1MDA3ZmYgaXJxIDE3IGF0IGRldmljZSAyOS43IG9uIHBj aTANCmVoY2kwOiBbR0lBTlQtTE9DS0VEXQ0KZWhjaTA6IFtJVEhSRUFEXQ0K dXNiMzogRUhDSSB2ZXJzaW9uIDEuMA0KdXNiMzogY29tcGFuaW9uIGNvbnRy b2xsZXJzLCAyIHBvcnRzIGVhY2g6IHVzYjAgdXNiMSB1c2IyDQp1c2IzOiA8 SW50ZWwgNjNYWEVTQiBVU0IgMi4wIGNvbnRyb2xsZXI+IG9uIGVoY2kwDQp1 c2IzOiBVU0IgcmV2aXNpb24gMi4wDQp1aHViMzogPEludGVsIEVIQ0kgcm9v dCBodWIsIGNsYXNzIDkvMCwgcmV2IDIuMDAvMS4wMCwgYWRkciAxPiBvbiB1 c2IzDQp1aHViMzogNiBwb3J0cyB3aXRoIDYgcmVtb3ZhYmxlLCBzZWxmIHBv d2VyZWQNCnVtYXNzMDogPFBlcHBlcmNvbiBBRyBNdWx0aWRldmljZSwgY2xh c3MgMC8wLCByZXYgMi4wMC8wLjAxLCBhZGRyIDI+IG9uIHVodWIzDQp1bXMw OiA8UGVwcGVyY29uIEFHIE11bHRpZGV2aWNlLCBjbGFzcyAwLzAsIHJldiAy LjAwLzAuMDEsIGFkZHIgMj4gb24gdWh1YjMNCnVtczA6IFggcmVwb3J0IDB4 MDAyMiBub3Qgc3VwcG9ydGVkDQpkZXZpY2VfYXR0YWNoOiB1bXMwIGF0dGFj aCByZXR1cm5lZCA2DQpwY2liMTE6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBh dCBkZXZpY2UgMzAuMCBvbiBwY2kwDQpwY2kxMTogPEFDUEkgUENJIGJ1cz4g b24gcGNpYjExDQp2Z2FwY2kwOiA8VkdBLWNvbXBhdGlibGUgZGlzcGxheT4g cG9ydCAweDMwMDAtMHgzMGZmIG1lbSAweGQwMDAwMDAwLTB4ZDdmZmZmZmYs MHhkODIwMDAwMC0weGQ4MjBmZmZmIGlycSAxOCBhdCBkZXZpY2UgMS4wIG9u IHBjaTExDQpkcm0wOiA8QVRJIEVTMTAwMCBSTjUwPiBvbiB2Z2FwY2kwDQpp bmZvOiBbZHJtXSBJbml0aWFsaXplZCByYWRlb24gMS4yNS4wIDIwMDYwNTI0 DQppc2FiMDogPFBDSS1JU0EgYnJpZGdlPiBhdCBkZXZpY2UgMzEuMCBvbiBw Y2kwDQppc2EwOiA8SVNBIGJ1cz4gb24gaXNhYjANCmF0YXBjaTA6IDxJbnRl bCA2M1hYRVNCMiBVRE1BMTAwIGNvbnRyb2xsZXI+IHBvcnQgMHgxZjAtMHgx ZjcsMHgzZjYsMHgxNzAtMHgxNzcsMHgzNzYsMHgxODYwLTB4MTg2ZiBhdCBk ZXZpY2UgMzEuMSBvbiBwY2kwDQphdGEwOiA8QVRBIGNoYW5uZWwgMD4gb24g YXRhcGNpMA0KYXRhMDogW0lUSFJFQURdDQphdGExOiA8QVRBIGNoYW5uZWwg MT4gb24gYXRhcGNpMA0KYXRhMTogW0lUSFJFQURdDQphdGFwY2kxOiA8SW50 ZWwgQUhDSSBjb250cm9sbGVyPiBwb3J0IDB4MThhMC0weDE4YTcsMHgxODc0 LTB4MTg3NywweDE4NzgtMHgxODdmLDB4MTg3MC0weDE4NzMsMHgxODgwLTB4 MTg5ZiBtZW0gMHhkODUwMDgwMC0weGQ4NTAwYmZmIGlycSAxOSBhdCBkZXZp Y2UgMzEuMiBvbiBwY2kwDQphdGFwY2kxOiBbSVRIUkVBRF0NCmF0YXBjaTE6 IEFIQ0kgVmVyc2lvbiAwMS4xMCBjb250cm9sbGVyIHdpdGggNiBwb3J0cyBk ZXRlY3RlZA0KYXRhMjogPEFUQSBjaGFubmVsIDA+IG9uIGF0YXBjaTENCmF0 YTI6IFtJVEhSRUFEXQ0KYXRhMzogPEFUQSBjaGFubmVsIDE+IG9uIGF0YXBj aTENCmF0YTM6IFtJVEhSRUFEXQ0KYXRhNDogPEFUQSBjaGFubmVsIDI+IG9u IGF0YXBjaTENCmF0YTQ6IFtJVEhSRUFEXQ0KYXRhNTogPEFUQSBjaGFubmVs IDM+IG9uIGF0YXBjaTENCmF0YTU6IFtJVEhSRUFEXQ0KYXRhNjogPEFUQSBj aGFubmVsIDQ+IG9uIGF0YXBjaTENCmF0YTY6IFtJVEhSRUFEXQ0KYXRhNzog PEFUQSBjaGFubmVsIDU+IG9uIGF0YXBjaTENCmF0YTc6IFtJVEhSRUFEXQ0K aWNoc21iMDogPEludGVsIDYzMXhFU0IvNjMyMUVTQiAoRVNCMikgU01CdXMg Y29udHJvbGxlcj4gcG9ydCAweDExMDAtMHgxMTFmIGlycSAxOSBhdCBkZXZp Y2UgMzEuMyBvbiBwY2kwDQppY2hzbWIwOiBbR0lBTlQtTE9DS0VEXQ0KaWNo c21iMDogW0lUSFJFQURdDQpzbWJ1czA6IDxTeXN0ZW0gTWFuYWdlbWVudCBC dXM+IG9uIGljaHNtYjANCnNtYjA6IDxTTUJ1cyBnZW5lcmljIEkvTz4gb24g c21idXMwDQphY3BpX2hwZXQwOiA8SGlnaCBQcmVjaXNpb24gRXZlbnQgVGlt ZXI+IGlvbWVtIDB4ZmVkMDAwMDAtMHhmZWQwMDNmZiBvbiBhY3BpMA0KVGlt ZWNvdW50ZXIgIkhQRVQiIGZyZXF1ZW5jeSAxNDMxODE4MCBIeiBxdWFsaXR5 IDkwMA0KY3B1MDogPEFDUEkgQ1BVPiBvbiBhY3BpMA0KY29yZXRlbXAwOiA8 Q1BVIE9uLURpZSBUaGVybWFsIFNlbnNvcnM+IG9uIGNwdTANCmVzdDA6IDxF bmhhbmNlZCBTcGVlZFN0ZXAgRnJlcXVlbmN5IENvbnRyb2w+IG9uIGNwdTAN CnA0dGNjMDogPENQVSBGcmVxdWVuY3kgVGhlcm1hbCBDb250cm9sPiBvbiBj cHUwDQpjcHUxOiA8QUNQSSBDUFU+IG9uIGFjcGkwDQpjb3JldGVtcDE6IDxD UFUgT24tRGllIFRoZXJtYWwgU2Vuc29ycz4gb24gY3B1MQ0KZXN0MTogPEVu aGFuY2VkIFNwZWVkU3RlcCBGcmVxdWVuY3kgQ29udHJvbD4gb24gY3B1MQ0K cDR0Y2MxOiA8Q1BVIEZyZXF1ZW5jeSBUaGVybWFsIENvbnRyb2w+IG9uIGNw dTENCmNwdTI6IDxBQ1BJIENQVT4gb24gYWNwaTANCmNvcmV0ZW1wMjogPENQ VSBPbi1EaWUgVGhlcm1hbCBTZW5zb3JzPiBvbiBjcHUyDQplc3QyOiA8RW5o YW5jZWQgU3BlZWRTdGVwIEZyZXF1ZW5jeSBDb250cm9sPiBvbiBjcHUyDQpw NHRjYzI6IDxDUFUgRnJlcXVlbmN5IFRoZXJtYWwgQ29udHJvbD4gb24gY3B1 Mg0KY3B1MzogPEFDUEkgQ1BVPiBvbiBhY3BpMA0KY29yZXRlbXAzOiA8Q1BV IE9uLURpZSBUaGVybWFsIFNlbnNvcnM+IG9uIGNwdTMNCmVzdDM6IDxFbmhh bmNlZCBTcGVlZFN0ZXAgRnJlcXVlbmN5IENvbnRyb2w+IG9uIGNwdTMNCnA0 dGNjMzogPENQVSBGcmVxdWVuY3kgVGhlcm1hbCBDb250cm9sPiBvbiBjcHUz DQphY3BpX2J1dHRvbjA6IDxQb3dlciBCdXR0b24+IG9uIGFjcGkwDQphdGti ZGMwOiA8S2V5Ym9hcmQgY29udHJvbGxlciAoaTgwNDIpPiBwb3J0IDB4NjAs MHg2NCBpcnEgMSBvbiBhY3BpMA0KYXRrYmQwOiA8QVQgS2V5Ym9hcmQ+IGly cSAxIG9uIGF0a2JkYzANCmtiZDAgYXQgYXRrYmQwDQphdGtiZDA6IFtHSUFO VC1MT0NLRURdDQphdGtiZDA6IFtJVEhSRUFEXQ0KcHNtMDogPFBTLzIgTW91 c2U+IGlycSAxMiBvbiBhdGtiZGMwDQpwc20wOiBbR0lBTlQtTE9DS0VEXQ0K cHNtMDogW0lUSFJFQURdDQpwc20wOiBtb2RlbCBJbnRlbGxpTW91c2UsIGRl dmljZSBJRCAzDQp1YXJ0MDogPDE2NTUwIG9yIGNvbXBhdGlibGU+IHBvcnQg MHgzZjgtMHgzZmYgaXJxIDQgb24gYWNwaTANCnVhcnQwOiBbRklMVEVSXQ0K dWFydDE6IDwxNjU1MCBvciBjb21wYXRpYmxlPiBwb3J0IDB4MmY4LTB4MmZm IGlycSAzIG9uIGFjcGkwDQp1YXJ0MTogW0ZJTFRFUl0NCmZkYzA6IDxmbG9w cHkgZHJpdmUgY29udHJvbGxlcj4gcG9ydCAweDNmMC0weDNmNSwweDNmNyBp cnEgNiBkcnEgMiBvbiBhY3BpMA0KZmRjMDogW0ZJTFRFUl0NCmZkMDogPDE0 NDAtS0IgMy41IiBkcml2ZT4gb24gZmRjMCBkcml2ZSAwDQpwcGMwOiA8UGFy YWxsZWwgcG9ydD4gcG9ydCAweDM3OC0weDM3ZiwweDc3OC0weDc3ZiBpcnEg NyBkcnEgMyBvbiBhY3BpMA0KcHBjMDogU01DLWxpa2UgY2hpcHNldCAoRUNQ L0VQUC9QUzIvTklCQkxFKSBpbiBDT01QQVRJQkxFIG1vZGUNCnBwYzA6IEZJ Rk8gd2l0aCAxNi8xNi85IGJ5dGVzIHRocmVzaG9sZA0KcHBidXMwOiA8UGFy YWxsZWwgcG9ydCBidXM+IG9uIHBwYzANCnBwYnVzMDogW0lUSFJFQURdDQps cHQwOiA8UHJpbnRlcj4gb24gcHBidXMwDQpscHQwOiBJbnRlcnJ1cHQtZHJp dmVuIHBvcnQNCnBwaTA6IDxQYXJhbGxlbCBJL08+IG9uIHBwYnVzMA0KcHBj MDogW0dJQU5ULUxPQ0tFRF0NCnBwYzA6IFtJVEhSRUFEXQ0KaXBtaTA6IDxJ UE1JIFN5c3RlbSBJbnRlcmZhY2U+IG9uIGlzYTANCmlwbWkwOiBLQ1MgbW9k ZSBmb3VuZCBhdCBpbyAweGNhMiBhbGlnbm1lbnQgMHgxIG9uIGlzYQ0Kb3Jt MDogPElTQSBPcHRpb24gUk9Ncz4gYXQgaW9tZW0gMHhjMDAwMC0weGNhZmZm LDB4Y2IwMDAtMHhjY2ZmZiBvbiBpc2EwDQpzYzA6IDxTeXN0ZW0gY29uc29s ZT4gYXQgZmxhZ3MgMHgxMDAgb24gaXNhMA0Kc2MwOiBWR0EgPDE2IHZpcnR1 YWwgY29uc29sZXMsIGZsYWdzPTB4MzAwPg0KdmdhMDogPEdlbmVyaWMgSVNB IFZHQT4gYXQgcG9ydCAweDNjMC0weDNkZiBpb21lbSAweGEwMDAwLTB4YmZm ZmYgb24gaXNhMA0KV0FSTklORzogWkZTIGlzIGNvbnNpZGVyZWQgdG8gYmUg YW4gZXhwZXJpbWVudGFsIGZlYXR1cmUgaW4gRnJlZUJTRC4NClRpbWVjb3Vu dGVycyB0aWNrIGV2ZXJ5IDEuMDAwIG1zZWMNClpGUyBmaWxlc3lzdGVtIHZl cnNpb24gNg0KWkZTIHN0b3JhZ2UgcG9vbCB2ZXJzaW9uIDYNCmFjZDA6IERN QSBsaW1pdGVkIHRvIFVETUEzMywgY29udHJvbGxlciBmb3VuZCBub24tQVRB NjYgY2FibGUNCmFjZDA6IERWRFIgPE1lbW9yZXggRFZEKy1SQU0gNTEwTCB2 MS9NV1M3PiBhdCBhdGEwLW1hc3RlciBVRE1BMzMNCmFkNDogMzgxNTU0TUIg PFNlYWdhdGUgU1QzNDAwNjIwQVMgMy5BQUo+IGF0IGF0YTItbWFzdGVyIFNB VEEzMDANCmFkNjogMzgxNTU0TUIgPFNlYWdhdGUgU1QzNDAwNjIwQVMgMy5B QUo+IGF0IGF0YTMtbWFzdGVyIFNBVEEzMDANCmFkODogNDc2OTQwTUIgPFNl YWdhdGUgU1QzNTAwNjMwQVMgMy5BQUU+IGF0IGF0YTQtbWFzdGVyIFNBVEEz MDANCmFkMTA6IDM4MTU1NE1CIDxTZWFnYXRlIFNUMzQwMDYyMEFTIDMuQUFK PiBhdCBhdGE1LW1hc3RlciBTQVRBMzAwDQphZDEyOiAzODE1NTRNQiA8U2Vh Z2F0ZSBTVDM0MDA2MjBBUyAzLkFBSj4gYXQgYXRhNi1tYXN0ZXIgU0FUQTMw MA0KYWQxNDogMzgxNTU0TUIgPFNlYWdhdGUgU1QzNDAwNjIwQVMgMy5BQUo+ IGF0IGF0YTctbWFzdGVyIFNBVEEzMDANCmlwbWkwOiBJUE1JIGRldmljZSBy ZXYuIDEsIGZpcm13YXJlIHJldi4gMS4yLCB2ZXJzaW9uIDIuMA0KaXBtaTA6 IE51bWJlciBvZiBjaGFubmVscyA4DQppcG1pMDogQXR0YWNoZWQgd2F0Y2hk b2cNCmFjZDA6IEZBSUxVUkUgLSBJTlFVSVJZIElMTEVHQUwgUkVRVUVTVCBh c2M9MHgyNCBhc2NxPTB4MDAgDQpTTVA6IEFQIENQVSAjMSBMYXVuY2hlZCEN ClNNUDogQVAgQ1BVICMzIExhdW5jaGVkIQ0KU01QOiBBUCBDUFUgIzIgTGF1 bmNoZWQhDQpjZDEgYXQgYXRhMCBidXMgMCB0YXJnZXQgMCBsdW4gMA0KY2Qx OiA8TWVtb3JleCBEVkQrLVJBTSA1MTBMIHYxIE1XUzc+IFJlbW92YWJsZSBD RC1ST00gU0NTSS0wIGRldmljZSANCmNkMTogMzMuMDAwTUIvcyB0cmFuc2Zl cnMNCmNkMTogQXR0ZW1wdCB0byBxdWVyeSBkZXZpY2Ugc2l6ZSBmYWlsZWQ6 IE5PVCBSRUFEWSwgTWVkaXVtIG5vdCBwcmVzZW50DQpjZDAgYXQgdW1hc3Mt c2ltMCBidXMgMCB0YXJnZXQgMCBsdW4gMA0KY2QwOiA8UGVwcGVyQyBWaXJ0 dWFsIERpc2MgMSAwLjAxPiBSZW1vdmFibGUgQ0QtUk9NIFNDU0ktMyBkZXZp Y2UgDQpjZDA6IDQwLjAwME1CL3MgdHJhbnNmZXJzDQpjZDA6IEF0dGVtcHQg dG8gcXVlcnkgZGV2aWNlIHNpemUgZmFpbGVkOiBOT1QgUkVBRFksIE1lZGl1 bSBub3QgcHJlc2VudA0KVHJ5aW5nIHRvIG1vdW50IHJvb3QgZnJvbSB1ZnM6 L2Rldi9hZDRzMWENCmVtMDogbGluayBzdGF0ZSBjaGFuZ2VkIHRvIFVQDQo= --3935026275-1715592916-1218330266=:4976-- From owner-freebsd-stable@FreeBSD.ORG Sun Aug 10 01:42:11 2008 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9D509106567B; Sun, 10 Aug 2008 01:42:11 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 83D458FC08; Sun, 10 Aug 2008 01:42:11 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 7422F1A4D83; Sat, 9 Aug 2008 18:42:11 -0700 (PDT) Date: Sat, 9 Aug 2008 18:42:11 -0700 From: Alfred Perlstein To: Robert Watson Message-ID: <20080810014211.GY16977@elvis.mu.org> References: <20080804020228.GG1663@tnn.dglawrence.com> <20080807060556.GD16977@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: stable@FreeBSD.org Subject: Re: HEADS UP: inpcb/inpcbinfo rwlocking: coming to a 7-STABLE branch near you X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Aug 2008 01:42:11 -0000 Robert, reviews of sorecv_drgram: /* XXXRW: sbwait() may not be as happy without sblock(). */ error = sbwait(&so->so_rcv); Does not need XXX, sbwait waits for data, it's not really related to sblock(). remove comment. The variable orig_resid can be removed, I think the purpose of it is to to restart blocking in the "generic sorecv" case, in your code you only set it, you never reference it. -Alfred * Robert Watson [080806 23:37] wrote: > > On Wed, 6 Aug 2008, Alfred Perlstein wrote: > > >* David G Lawrence [080805 11:37] wrote: > >>>The thrust of this change is to replace the mutexes protecting the inpcb > >>>and inpcbinfo data structures with read-write locks (rwlocks). These > >> > >> That's really cool and directly affects my current work project. I'm > >>developing (have developed, actually) a multi-threaded, 5000+ member > >>VoIP/SIP conferencing server called Nconnect. It a primarily UDP > >>application running on FreeBSD 7. This generates and receives about > >>250,000 UDP packets a second, with 200 byte packets, resulting in about > >>400Mbps of traffic in each direction. The current bottleneck is the > >>kernel UDP processing. It should be possible to scale to 10000+ members > >>if kernel UDP processing had optimal concurrency. > >> Anyway, thumbs up (and not for the middle-eastern meaning :-)) - I'm > >>looking forward to the MFC. > > > >David, one thing I noticed was that it appears that UDP sockets are > >serialized for copyout. > > > >Mainly that the socket is sblock()'d while the uiomove happens. > > > >I was trying to figure out a way to bypass this somehow. Perhaps just > >dequeuing and unlocking, the copyout after dropping the sblock. > > > >If there's some error, then requeue or discard the packet. > > > >I'll have to think about it. > > Or you can use the soreceive_dgram implementation in 8.x, which I will at > some point MFC once I'm comfortable it doesn't contain any serious bugs. > > Robert N M Watson > Computer Laboratory > University of Cambridge -- - Alfred Perlstein From owner-freebsd-stable@FreeBSD.ORG Sun Aug 10 02:54:45 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 728511065676 for ; Sun, 10 Aug 2008 02:54:45 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [192.147.25.65]) by mx1.freebsd.org (Postfix) with ESMTP id 4D1FA8FC14 for ; Sun, 10 Aug 2008 02:54:45 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from 76-205-169-61.lightspeed.austtx.sbcglobal.net ([76.205.169.61]:62726 helo=borg) by thebighonker.lerctr.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KS14t-0004KD-Kn for freebsd-stable@freebsd.org; Sat, 09 Aug 2008 21:54:45 -0500 Date: Sat, 9 Aug 2008 21:54:40 -0500 (CDT) From: Larry Rosenman Sender: ler@borg To: freebsd-stable@freebsd.org In-Reply-To: <20080809195935.F4976@borg> Message-ID: <20080809215249.T5563@borg> References: <20080809195935.F4976@borg> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: -2.5 (--) X-LERCTR-Spam-Score: -2.5 (--) X-Spam-Report: SpamScore (-2.5/5.0) ALL_TRUSTED=-1.8, BAYES_00=-2.599, TVD_RCVD_IP=1.931 X-LERCTR-Spam-Report: SpamScore (-2.5/5.0) ALL_TRUSTED=-1.8, BAYES_00=-2.599, TVD_RCVD_IP=1.931 DomainKey-Status: no signature Subject: Re: IPMI Console: No luck once OS is booted X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Aug 2008 02:54:45 -0000 On Sat, 9 Aug 2008, Larry Rosenman wrote: > I have a current RELENG_7 running on: > http://www.supermicro.com/products/system/4U/7045/SYS-7045B-TR+.cfm > > with the -3+ IPMI card. > > I can interact with the BIOS, etc, but no joy once we get past the loader. > > Anyone have ideas? > > Attached is the kernel config, and the /var/run/dmesg.boot file. I hate it when I post something, and then look at one setting on the card, and fix it myself. There is a key release timeout checkbox on the keyboard/mouse settings tab for the KVM that wasn't checked. Checking it fixed it. Sorry for the noise. :( > > > > -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 From owner-freebsd-stable@FreeBSD.ORG Sun Aug 10 04:34:05 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 989AA106566B; Sun, 10 Aug 2008 04:34:05 +0000 (UTC) (envelope-from shinjii@maydias.com) Received: from mail9.tpgi.com.au (mail9.tpgi.com.au [203.12.160.104]) by mx1.freebsd.org (Postfix) with ESMTP id 1895A8FC08; Sun, 10 Aug 2008 04:34:04 +0000 (UTC) (envelope-from shinjii@maydias.com) X-TPG-Antivirus: Passed Received: from [192.168.1.68] (123-243-239-97.static.tpgi.com.au [123.243.239.97]) by mail9.tpgi.com.au (envelope-from shinjii@maydias.com) (8.14.3/8.14.3) with ESMTP id m7A4XxsF005483; Sun, 10 Aug 2008 14:34:02 +1000 From: Warren Liddell To: freebsd-questions@freebsd.org Date: Sun, 10 Aug 2008 14:33:54 +1000 User-Agent: KMail/1.9.7 References: <200808051748.55133.shinjii@maydias.com> <200808070641.53857.shinjii@maydias.com> <20080807002141.319b3ffd@verizon.net> In-Reply-To: <20080807002141.319b3ffd@verizon.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200808101433.54554.shinjii@maydias.com> Cc: FreeBSD Stable Mailing List , David Gurvich Subject: Wireless net Card X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Aug 2008 04:34:05 -0000 I downloaded the drivers for the chipset my belkin wireless card has, used ndisgen to create the kernel module, which all went aok .. however when trying to load the module it hard hangs the machine to the point of it restarting itself .. is there something i perhaps mybe missing or am i out in the cold in not being able to use this wireless card untill some time a freebsd driver is done ? From owner-freebsd-stable@FreeBSD.ORG Sun Aug 10 05:24:53 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3104E1065679; Sun, 10 Aug 2008 05:24:53 +0000 (UTC) (envelope-from eugen@kuzbass.ru) Received: from www.svzserv.kemerovo.su (www.svzserv.kemerovo.su [213.184.65.80]) by mx1.freebsd.org (Postfix) with ESMTP id 7E54A8FC08; Sun, 10 Aug 2008 05:24:52 +0000 (UTC) (envelope-from eugen@kuzbass.ru) Received: from www.svzserv.kemerovo.su (eugen@localhost [127.0.0.1]) by www.svzserv.kemerovo.su (8.13.8/8.13.8) with ESMTP id m7A5OodO096112; Sun, 10 Aug 2008 13:24:50 +0800 (KRAST) (envelope-from eugen@www.svzserv.kemerovo.su) Received: (from eugen@localhost) by www.svzserv.kemerovo.su (8.13.8/8.13.8/Submit) id m7A5OoHY096111; Sun, 10 Aug 2008 13:24:50 +0800 (KRAST) (envelope-from eugen) Date: Sun, 10 Aug 2008 13:24:50 +0800 From: Eugene Grosbein To: John Baldwin Message-ID: <20080810052450.GA95676@svzserv.kemerovo.su> References: <20080627031233.9DC4945047@ptavv.es.net> <20080809115642.GB1798@roadrunner.spoerlein.net> <20080809130211.GA27931@svzserv.kemerovo.su> <200808091557.21767.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200808091557.21767.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-stable@freebsd.org Subject: Re: Problem with /boot/loader [A new patch] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Aug 2008 05:24:53 -0000 On Sat, Aug 09, 2008 at 03:57:21PM -0400, John Baldwin wrote: > As you are getting BTX faults that is likely a separate issue. You will need > to get a copy of the BTX fault message somehow. I've got a message from BTX only once and cannot reproduce it. However, I get loader hangs almost always while trying to type something in its loader prompt after a character or two entered. This machine is my home desktop and I can do any debugging needed, just ask. I can also use serial console, if needed. Eugene Grosbein From owner-freebsd-stable@FreeBSD.ORG Sun Aug 10 06:27:31 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 039E6106567B; Sun, 10 Aug 2008 06:27:31 +0000 (UTC) (envelope-from eugen@kuzbass.ru) Received: from www.svzserv.kemerovo.su (www.svzserv.kemerovo.su [213.184.65.80]) by mx1.freebsd.org (Postfix) with ESMTP id 4E6878FC1D; Sun, 10 Aug 2008 06:27:29 +0000 (UTC) (envelope-from eugen@kuzbass.ru) Received: from www.svzserv.kemerovo.su (eugen@localhost [127.0.0.1]) by www.svzserv.kemerovo.su (8.13.8/8.13.8) with ESMTP id m7A6RRNH005911; Sun, 10 Aug 2008 14:27:27 +0800 (KRAST) (envelope-from eugen@www.svzserv.kemerovo.su) Received: (from eugen@localhost) by www.svzserv.kemerovo.su (8.13.8/8.13.8/Submit) id m7A6RQo0005909; Sun, 10 Aug 2008 14:27:26 +0800 (KRAST) (envelope-from eugen) Date: Sun, 10 Aug 2008 14:27:26 +0800 From: Eugene Grosbein To: John Baldwin Message-ID: <20080810062726.GA3979@svzserv.kemerovo.su> References: <20080627031233.9DC4945047@ptavv.es.net> <200808081249.28513.jhb@freebsd.org> <20080809092200.GA70050@svzserv.kemerovo.su> <200808091717.31780.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200808091717.31780.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-stable@freebsd.org Subject: Re: Problem with /boot/loader [A new patch] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Aug 2008 06:27:31 -0000 On Sat, Aug 09, 2008 at 05:17:31PM -0400, John Baldwin wrote: > In addition to my earlier message, it would probably be good to narrow down > what breaks the loader for you. For example, does it work ok over serial and > only break on vidconsole? Also, if you just backout sys/boot/i386/btx to > 7.0-release and leave the rest of the sys/boot tree at 7.0-stable, do you get > a working loader? I've just rolled sys/boot/i386/btx back to RELENG_7_0_0_RELEASE leaving rest of src at 7.0-STABLE (plus your patch) and yes, I've got working loader! I'll try to establish serial console and retest with RELENG_7 sources. Eugene Grosbein From owner-freebsd-stable@FreeBSD.ORG Sun Aug 10 06:48:35 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3D33B106564A for ; Sun, 10 Aug 2008 06:48:35 +0000 (UTC) (envelope-from me@che78-3-82-246-30-233.fbx.proxad.net) Received: from smtp7-g19.free.fr (smtp7-g19.free.fr [212.27.42.64]) by mx1.freebsd.org (Postfix) with ESMTP id F28318FC12 for ; Sun, 10 Aug 2008 06:48:34 +0000 (UTC) (envelope-from me@che78-3-82-246-30-233.fbx.proxad.net) Received: from smtp7-g19.free.fr (localhost [127.0.0.1]) by smtp7-g19.free.fr (Postfix) with ESMTP id 7150EB01B2 for ; Sun, 10 Aug 2008 08:48:33 +0200 (CEST) Received: from che78-3-82-246-30-233.fbx.proxad.net (che78-3-82-246-30-233.fbx.proxad.net [82.246.30.233]) by smtp7-g19.free.fr (Postfix) with ESMTP id 55FCFB0180 for ; Sun, 10 Aug 2008 08:48:33 +0200 (CEST) Received: by che78-3-82-246-30-233.fbx.proxad.net (Postfix, from userid 1001) id D2BF7450F6; Sun, 10 Aug 2008 08:54:17 +0200 (CEST) Date: Sun, 10 Aug 2008 08:54:17 +0200 From: Harald Weis To: freebsd-stable@freebsd.org Message-ID: <20080810065417.GA1164@pollux> Mail-Followup-To: freebsd-stable@freebsd.org References: <20080808081330.GA1203@sirius.local.net> <20080809140339.GA1522@sirius.local.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Subject: Re: Audio CD problem on laptop VGN-SZ61MN X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Aug 2008 06:48:35 -0000 On Sat, Aug 09, 2008 at 11:56:23AM -0300, Carlos A. M. dos Santos wrote: > 1. Try to insert the CD and wait until it stops pinning before > starting mplayer. Some drives are a bit lazy on media recognition. > > 2. Run "truss mplayer ..." and look for error messages. > > 3. Attempt to use a different player. Xine and/or one of its alternate > front-ends like GXine or Kaffeine are good choices. I'll be away from keyboard for two weeks or so. I shall reply then as soon as possible. Thanks again, Carlos. Bye Harald From owner-freebsd-stable@FreeBSD.ORG Sun Aug 10 08:15:12 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F21F51065674; Sun, 10 Aug 2008 08:15:12 +0000 (UTC) (envelope-from eugen@kuzbass.ru) Received: from www.svzserv.kemerovo.su (www.svzserv.kemerovo.su [213.184.65.80]) by mx1.freebsd.org (Postfix) with ESMTP id 510648FC39; Sun, 10 Aug 2008 08:15:11 +0000 (UTC) (envelope-from eugen@kuzbass.ru) Received: from www.svzserv.kemerovo.su (eugen@localhost [127.0.0.1]) by www.svzserv.kemerovo.su (8.13.8/8.13.8) with ESMTP id m7A8F91Q021387; Sun, 10 Aug 2008 16:15:09 +0800 (KRAST) (envelope-from eugen@www.svzserv.kemerovo.su) Received: (from eugen@localhost) by www.svzserv.kemerovo.su (8.13.8/8.13.8/Submit) id m7A8F9Cp021386; Sun, 10 Aug 2008 16:15:09 +0800 (KRAST) (envelope-from eugen) Date: Sun, 10 Aug 2008 16:15:09 +0800 From: Eugene Grosbein To: John Baldwin Message-ID: <20080810081509.GA21050@svzserv.kemerovo.su> References: <20080627031233.9DC4945047@ptavv.es.net> <200808081249.28513.jhb@freebsd.org> <20080809092200.GA70050@svzserv.kemerovo.su> <200808091717.31780.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200808091717.31780.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-stable@freebsd.org Subject: Re: Problem with /boot/loader [A new patch] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Aug 2008 08:15:13 -0000 On Sat, Aug 09, 2008 at 05:17:31PM -0400, John Baldwin wrote: > > Sigh, it does not fix my problem described here: > > http://groups.google.ru/group/muc.lists.freebsd.stable/browse_thread/thread > >/538039f40b469e2a > > I've just updated my 7.0-STABLE to latest sources, applied your patch > > using "cd /usr/src; patch -p6 < ~/btx_hang.patch", it has applied cleanly. > > Then I've rebuilt and reinstalled kernel and world and rebooted. > > My problem persists as it was. > > In addition to my earlier message, it would probably be good to narrow down > what breaks the loader for you. For example, does it work ok over serial and > only break on vidconsole? I've established serial console, switched back to 7.0-STABLE sources plus your patch and found that while vidconsole hangs, serial console is not affected and command prompt works without a problem with it. Eugene Grosbein From owner-freebsd-stable@FreeBSD.ORG Sun Aug 10 13:24:50 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 55B851065681 for ; Sun, 10 Aug 2008 13:24:50 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [192.147.25.65]) by mx1.freebsd.org (Postfix) with ESMTP id 3C4008FC1A for ; Sun, 10 Aug 2008 13:24:50 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from 76-205-169-61.lightspeed.austtx.sbcglobal.net ([76.205.169.61]:64561 helo=borg) by thebighonker.lerctr.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KSAue-0009JY-Cn for freebsd-stable@freebsd.org; Sun, 10 Aug 2008 08:24:49 -0500 Date: Sun, 10 Aug 2008 08:24:45 -0500 (CDT) From: Larry Rosenman Sender: ler@borg To: freebsd-stable@freebsd.org In-Reply-To: <20080809215249.T5563@borg> Message-ID: <20080810082410.X1306@borg> References: <20080809195935.F4976@borg> <20080809215249.T5563@borg> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: -2.5 (--) X-LERCTR-Spam-Score: -2.5 (--) X-Spam-Report: SpamScore (-2.5/5.0) ALL_TRUSTED=-1.8, BAYES_00=-2.599, TVD_RCVD_IP=1.931 X-LERCTR-Spam-Report: SpamScore (-2.5/5.0) ALL_TRUSTED=-1.8, BAYES_00=-2.599, TVD_RCVD_IP=1.931 DomainKey-Status: no signature Subject: Re: IPMI Console: No luck once OS is booted X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Aug 2008 13:24:50 -0000 On Sat, 9 Aug 2008, Larry Rosenman wrote: > On Sat, 9 Aug 2008, Larry Rosenman wrote: > >> I have a current RELENG_7 running on: >> http://www.supermicro.com/products/system/4U/7045/SYS-7045B-TR+.cfm >> >> with the -3+ IPMI card. >> >> I can interact with the BIOS, etc, but no joy once we get past the loader. >> >> Anyone have ideas? >> >> Attached is the kernel config, and the /var/run/dmesg.boot file. > > I hate it when I post something, and then look at one setting on the > card, and fix it myself. > > There is a key release timeout checkbox on the keyboard/mouse > settings tab for the KVM that wasn't checked. Checking it > fixed it. > > Sorry for the noise. :( Actually, it worked *ONCE*, and now is not behaving itself. Any ideas from other SuperMicro users? -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 From owner-freebsd-stable@FreeBSD.ORG Sun Aug 10 13:26:37 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B03161065676 for ; Sun, 10 Aug 2008 13:26:37 +0000 (UTC) (envelope-from andrew@modulus.org) Received: from email.octopus.com.au (host-122-100-2-232.octopus.com.au [122.100.2.232]) by mx1.freebsd.org (Postfix) with ESMTP id 78BB08FC12 for ; Sun, 10 Aug 2008 13:26:37 +0000 (UTC) (envelope-from andrew@modulus.org) Received: by email.octopus.com.au (Postfix, from userid 1002) id 4FE5A17D3C; Sun, 10 Aug 2008 23:26:51 +1000 (EST) X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on email.octopus.com.au X-Spam-Level: X-Spam-Status: No, score=-1.4 required=10.0 tests=ALL_TRUSTED autolearn=failed version=3.2.3 Received: from [10.20.30.101] (60.218.233.220.exetel.com.au [220.233.218.60]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: admin@email.octopus.com.au) by email.octopus.com.au (Postfix) with ESMTP id 0573F1725F; Sun, 10 Aug 2008 23:26:46 +1000 (EST) Message-ID: <489EEC85.9070600@modulus.org> Date: Sun, 10 Aug 2008 23:26:29 +1000 From: Andrew Snow User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <20080809195935.F4976@borg> <20080809215249.T5563@borg> <20080810082410.X1306@borg> In-Reply-To: <20080810082410.X1306@borg> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: IPMI Console: No luck once OS is booted X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Aug 2008 13:26:37 -0000 Larry Rosenman wrote: >> There is a key release timeout checkbox on the keyboard/mouse >> settings tab for the KVM that wasn't checked. Checking it >> fixed it. >> >> Sorry for the noise. :( > Actually, it worked *ONCE*, and now is not behaving itself. > > Any ideas from other SuperMicro users? In the IPMI card's web interface, I remember having to fiddle with the "Keyboard/Mouse emulation" option to solve this problem. Try changing to the alternative settings. From owner-freebsd-stable@FreeBSD.ORG Sun Aug 10 14:00:26 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BA0651065679 for ; Sun, 10 Aug 2008 14:00:26 +0000 (UTC) (envelope-from daryl@isletech.net) Received: from camp.isletech.net (camp.isletech.net [64.235.105.9]) by mx1.freebsd.org (Postfix) with ESMTP id 800908FC1C for ; Sun, 10 Aug 2008 14:00:26 +0000 (UTC) (envelope-from daryl@isletech.net) Received: from home.isletech.net ([206.248.171.193]:50940 helo=mac.home.isletech.net) by camp.isletech.net with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from ) id 1KSAzi-0005ls-Eq for freebsd-stable@freebsd.org; Sun, 10 Aug 2008 09:30:05 -0400 Message-Id: From: Daryl Richards To: freebsd-stable@freebsd.org In-Reply-To: <20080810082410.X1306@borg> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Date: Sun, 10 Aug 2008 09:30:02 -0400 References: <20080809195935.F4976@borg> <20080809215249.T5563@borg> <20080810082410.X1306@borg> X-Mailer: Apple Mail (2.926) X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on camp.isletech.net X-Spam-Level: X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-SA-Exim-Version: 4.2.1 (built Thu, 25 Oct 2007 20:25:01 +0000) Subject: Re: IPMI Console: No luck once OS is booted X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Aug 2008 14:00:26 -0000 What NIC does your server use? I'm currently trying to figure out a similar issue with my server, which use bge(4) I have a Sun Fire X2200. I can access the LOM no problem once Linux or Solaris is booted. But, once FreeBSD boots, it's no longer accessible from the NIC. Serial still works fine, it's just access via web or ssh. This happens from a fresh install, and also I've rebuild to -STABLE, and no joy either. These two cases might be related. On 10-Aug-08, at 9:24 AM, Larry Rosenman wrote: > On Sat, 9 Aug 2008, Larry Rosenman wrote: > >> On Sat, 9 Aug 2008, Larry Rosenman wrote: >> >>> I have a current RELENG_7 running on: http://www.supermicro.com/products/system/4U/7045/SYS-7045B-TR+.cfm >>> with the -3+ IPMI card. >>> I can interact with the BIOS, etc, but no joy once we get past the >>> loader. >>> Anyone have ideas? >>> Attached is the kernel config, and the /var/run/dmesg.boot file. >> >> I hate it when I post something, and then look at one setting on the >> card, and fix it myself. >> >> There is a key release timeout checkbox on the keyboard/mouse >> settings tab for the KVM that wasn't checked. Checking it >> fixed it. >> >> Sorry for the noise. :( > Actually, it worked *ONCE*, and now is not behaving itself. > > Any ideas from other SuperMicro users? > > -- > Larry Rosenman http://www.lerctr.org/~ler > Phone: +1 512-248-2683 E-Mail: ler@lerctr.org > US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org > " From owner-freebsd-stable@FreeBSD.ORG Sun Aug 10 15:23:05 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 512AB1065677 for ; Sun, 10 Aug 2008 15:23:05 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [192.147.25.65]) by mx1.freebsd.org (Postfix) with ESMTP id 37BC38FC1B for ; Sun, 10 Aug 2008 15:23:05 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from 76-205-169-61.lightspeed.austtx.sbcglobal.net ([76.205.169.61]:57111 helo=borg) by thebighonker.lerctr.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KSCl4-000A0d-Gl; Sun, 10 Aug 2008 10:23:03 -0500 Date: Sun, 10 Aug 2008 10:22:59 -0500 (CDT) From: Larry Rosenman Sender: ler@borg To: David Duchscher In-Reply-To: <57BE2631-7AED-443A-88E4-62456C048DD4@tamu.edu> Message-ID: <20080810102225.V1945@borg> References: <20080809195935.F4976@borg> <20080809215249.T5563@borg> <20080810082410.X1306@borg> <57BE2631-7AED-443A-88E4-62456C048DD4@tamu.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: -2.5 (--) X-LERCTR-Spam-Score: -2.5 (--) X-Spam-Report: SpamScore (-2.5/5.0) ALL_TRUSTED=-1.8, BAYES_00=-2.599, TVD_RCVD_IP=1.931 X-LERCTR-Spam-Report: SpamScore (-2.5/5.0) ALL_TRUSTED=-1.8, BAYES_00=-2.599, TVD_RCVD_IP=1.931 DomainKey-Status: no signature Cc: freebsd-stable@freebsd.org Subject: Re: IPMI Console: No luck once OS is booted X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Aug 2008 15:23:05 -0000 On Sun, 10 Aug 2008, David Duchscher wrote: > On Aug 10, 2008, at 8:24 AM, Larry Rosenman wrote: > >> On Sat, 9 Aug 2008, Larry Rosenman wrote: >> >>> On Sat, 9 Aug 2008, Larry Rosenman wrote: >>> >>>> I have a current RELENG_7 running on: >>>> http://www.supermicro.com/products/system/4U/7045/SYS-7045B-TR+.cfm >>>> with the -3+ IPMI card. >>>> I can interact with the BIOS, etc, but no joy once we get past the >>>> loader. >>>> Anyone have ideas? >>>> Attached is the kernel config, and the /var/run/dmesg.boot file. >>> >>> I hate it when I post something, and then look at one setting on the >>> card, and fix it myself. >>> >>> There is a key release timeout checkbox on the keyboard/mouse >>> settings tab for the KVM that wasn't checked. Checking it >>> fixed it. >>> >>> Sorry for the noise. :( >> Actually, it worked *ONCE*, and now is not behaving itself. >> >> Any ideas from other SuperMicro users? > > > I don't have that IPMI card but I can say we have other cards of theirs > working. I would make sure the card is at the latest version of firmware. > The AOC-SIMSO(+) card was not detected correctly until we upgraded. I don't > know why the card is going away when freebsd boots since I assume you are on > the dedicated LAN interface with its own IP address. Yes. It's not going away, just doesn't see the key strokes. > > We do have a few issues with Supermiro IPMI and FreeBSD that share the Intel > NIC (em) with the OS. Once the NIC is detected, you can't talk to the IPMI > card until the NIC is configured with ifconfig. Even just an ifconfig up > will wake things back up. We ended up removing the em driver from the kernel > and loading it as a module to reduce this window. > > The other issue is with bridging since the IPMI packets get gobbled up and > never make it too the bridge. > > I do need to file PRs for these one of these days... > -- > DaveD > -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 From owner-freebsd-stable@FreeBSD.ORG Sun Aug 10 15:25:20 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2A7531065676 for ; Sun, 10 Aug 2008 15:25:20 +0000 (UTC) (envelope-from daved@tamu.edu) Received: from sr-6-int.cis.tamu.edu (smtp-relay.tamu.edu [165.91.22.120]) by mx1.freebsd.org (Postfix) with ESMTP id F1C228FC08 for ; Sun, 10 Aug 2008 15:25:19 +0000 (UTC) (envelope-from daved@tamu.edu) Received: from localhost (localhost.tamu.edu [127.0.0.1]) by sr-6-int.cis.tamu.edu (Postfix) with ESMTP id 24A5E2912A0; Sun, 10 Aug 2008 10:10:10 -0500 (CDT) Received: from [10.0.1.197] (pool-71-113-241-177.herntx.dsl-w.verizon.net [71.113.241.177]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by sr-6-int.cis.tamu.edu (Postfix) with ESMTP id E56F2291297; Sun, 10 Aug 2008 10:10:08 -0500 (CDT) Message-Id: <57BE2631-7AED-443A-88E4-62456C048DD4@tamu.edu> From: David Duchscher To: Larry Rosenman In-Reply-To: <20080810082410.X1306@borg> Content-Type: multipart/signed; boundary=Apple-Mail-1--444361535; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v928.1) Date: Sun, 10 Aug 2008 10:10:06 -0500 References: <20080809195935.F4976@borg> <20080809215249.T5563@borg> <20080810082410.X1306@borg> X-Mailer: Apple Mail (2.928.1) X-Virus-Scanned: amavisd-new at tamu.edu X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: IPMI Console: No luck once OS is booted X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Aug 2008 15:25:20 -0000 --Apple-Mail-1--444361535 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Aug 10, 2008, at 8:24 AM, Larry Rosenman wrote: > On Sat, 9 Aug 2008, Larry Rosenman wrote: > >> On Sat, 9 Aug 2008, Larry Rosenman wrote: >> >>> I have a current RELENG_7 running on: http://www.supermicro.com/products/system/4U/7045/SYS-7045B-TR+.cfm >>> with the -3+ IPMI card. >>> I can interact with the BIOS, etc, but no joy once we get past the >>> loader. >>> Anyone have ideas? >>> Attached is the kernel config, and the /var/run/dmesg.boot file. >> >> I hate it when I post something, and then look at one setting on the >> card, and fix it myself. >> >> There is a key release timeout checkbox on the keyboard/mouse >> settings tab for the KVM that wasn't checked. Checking it >> fixed it. >> >> Sorry for the noise. :( > Actually, it worked *ONCE*, and now is not behaving itself. > > Any ideas from other SuperMicro users? I don't have that IPMI card but I can say we have other cards of theirs working. I would make sure the card is at the latest version of firmware. The AOC-SIMSO(+) card was not detected correctly until we upgraded. I don't know why the card is going away when freebsd boots since I assume you are on the dedicated LAN interface with its own IP address. We do have a few issues with Supermiro IPMI and FreeBSD that share the Intel NIC (em) with the OS. Once the NIC is detected, you can't talk to the IPMI card until the NIC is configured with ifconfig. Even just an ifconfig up will wake things back up. We ended up removing the em driver from the kernel and loading it as a module to reduce this window. The other issue is with bridging since the IPMI packets get gobbled up and never make it too the bridge. I do need to file PRs for these one of these days... -- DaveD --Apple-Mail-1--444361535-- From owner-freebsd-stable@FreeBSD.ORG Sun Aug 10 15:53:35 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EBD171065684 for ; Sun, 10 Aug 2008 15:53:35 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [192.147.25.65]) by mx1.freebsd.org (Postfix) with ESMTP id D19288FC16 for ; Sun, 10 Aug 2008 15:53:35 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from 76-205-169-61.lightspeed.austtx.sbcglobal.net ([76.205.169.61]:49395 helo=borg) by thebighonker.lerctr.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KSDEc-000ACt-1p; Sun, 10 Aug 2008 10:53:35 -0500 Date: Sun, 10 Aug 2008 10:53:31 -0500 (CDT) From: Larry Rosenman Sender: ler@borg To: Daryl Richards In-Reply-To: Message-ID: <20080810105252.S2191@borg> References: <20080809195935.F4976@borg> <20080809215249.T5563@borg> <20080810082410.X1306@borg> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: -2.5 (--) X-LERCTR-Spam-Score: -2.5 (--) X-Spam-Report: SpamScore (-2.5/5.0) ALL_TRUSTED=-1.8, BAYES_00=-2.599, TVD_RCVD_IP=1.931 X-LERCTR-Spam-Report: SpamScore (-2.5/5.0) ALL_TRUSTED=-1.8, BAYES_00=-2.599, TVD_RCVD_IP=1.931 DomainKey-Status: no signature Cc: freebsd-stable@freebsd.org Subject: Re: IPMI Console: No luck once OS is booted X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Aug 2008 15:53:36 -0000 On Sun, 10 Aug 2008, Daryl Richards wrote: > What NIC does your server use? I'm currently trying to figure out a similar > issue with my server, which use bge(4) em(4), and the IPMI card has it's own NIC. > > I have a Sun Fire X2200. I can access the LOM no problem once Linux or > Solaris is booted. But, once FreeBSD boots, it's no longer accessible from > the NIC. Serial still works fine, it's just access via web or ssh. > > This happens from a fresh install, and also I've rebuild to -STABLE, and no > joy either. > > These two cases might be related. Hrm. That's interesting. > > On 10-Aug-08, at 9:24 AM, Larry Rosenman wrote: > >> On Sat, 9 Aug 2008, Larry Rosenman wrote: >> >>> On Sat, 9 Aug 2008, Larry Rosenman wrote: >>> >>>> I have a current RELENG_7 running on: >>>> http://www.supermicro.com/products/system/4U/7045/SYS-7045B-TR+.cfm >>>> with the -3+ IPMI card. >>>> I can interact with the BIOS, etc, but no joy once we get past the >>>> loader. >>>> Anyone have ideas? >>>> Attached is the kernel config, and the /var/run/dmesg.boot file. >>> >>> I hate it when I post something, and then look at one setting on the >>> card, and fix it myself. >>> >>> There is a key release timeout checkbox on the keyboard/mouse >>> settings tab for the KVM that wasn't checked. Checking it >>> fixed it. >>> >>> Sorry for the noise. :( >> Actually, it worked *ONCE*, and now is not behaving itself. >> >> Any ideas from other SuperMicro users? >> >> -- >> Larry Rosenman http://www.lerctr.org/~ler >> Phone: +1 512-248-2683 E-Mail: ler@lerctr.org >> US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 From owner-freebsd-stable@FreeBSD.ORG Sun Aug 10 16:26:21 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 94C241065687 for ; Sun, 10 Aug 2008 16:26:21 +0000 (UTC) (envelope-from daved@tamu.edu) Received: from sr-5-int.cis.tamu.edu (smtp-relay.tamu.edu [165.91.22.120]) by mx1.freebsd.org (Postfix) with ESMTP id 68ACE8FC21 for ; Sun, 10 Aug 2008 16:26:21 +0000 (UTC) (envelope-from daved@tamu.edu) Received: from localhost (localhost.tamu.edu [127.0.0.1]) by sr-5-int.cis.tamu.edu (Postfix) with ESMTP id C2BCC113F9; Sun, 10 Aug 2008 11:26:20 -0500 (CDT) Received: from [10.0.1.197] (unknown [172.16.48.15]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by sr-5-int.cis.tamu.edu (Postfix) with ESMTP id 0A74011813; Sun, 10 Aug 2008 11:26:17 -0500 (CDT) Message-Id: From: David Duchscher To: Larry Rosenman In-Reply-To: <20080810102225.V1945@borg> Content-Type: multipart/signed; boundary=Apple-Mail-2--439791843; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v928.1) Date: Sun, 10 Aug 2008 11:26:16 -0500 References: <20080809195935.F4976@borg> <20080809215249.T5563@borg> <20080810082410.X1306@borg> <57BE2631-7AED-443A-88E4-62456C048DD4@tamu.edu> <20080810102225.V1945@borg> X-Mailer: Apple Mail (2.928.1) X-Virus-Scanned: amavisd-new at tamu.edu X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: IPMI Console: No luck once OS is booted X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Aug 2008 16:26:21 -0000 --Apple-Mail-2--439791843 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Aug 10, 2008, at 10:22 AM, Larry Rosenman wrote: >> I don't have that IPMI card but I can say we have other cards of >> theirs working. I would make sure the card is at the latest >> version of firmware. The AOC-SIMSO(+) card was not detected >> correctly until we upgraded. I don't know why the card is going >> away when freebsd boots since I assume you are on the dedicated LAN >> interface with its own IP address. > Yes. It's not going away, just doesn't see the key strokes. Looking through your dmesg file, I don't see a USB keyboard being attached. On my system, the virtual keyboard is a USB keyboard. ukbd0: on uhub3 kbd2 at ukbd0 -- DaveD --Apple-Mail-2--439791843-- From owner-freebsd-stable@FreeBSD.ORG Sun Aug 10 17:03:41 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B42BE1065671 for ; Sun, 10 Aug 2008 17:03:41 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [192.147.25.65]) by mx1.freebsd.org (Postfix) with ESMTP id 9A3DC8FC1C for ; Sun, 10 Aug 2008 17:03:41 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from 76-205-169-61.lightspeed.austtx.sbcglobal.net ([76.205.169.61]:50153 helo=borg) by thebighonker.lerctr.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KSEKR-000Aa8-Iz; Sun, 10 Aug 2008 12:03:41 -0500 Date: Sun, 10 Aug 2008 12:03:31 -0500 (CDT) From: Larry Rosenman Sender: ler@borg To: David Duchscher In-Reply-To: Message-ID: <20080810120156.O1324@borg> References: <20080809195935.F4976@borg> <20080809215249.T5563@borg> <20080810082410.X1306@borg> <57BE2631-7AED-443A-88E4-62456C048DD4@tamu.edu> <20080810102225.V1945@borg> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: -2.4 (--) X-LERCTR-Spam-Score: -2.4 (--) X-Spam-Report: SpamScore (-2.4/5.0) ALL_TRUSTED=-1.8, BAYES_00=-2.599, TVD_RCVD_IP=1.931, TW_KB=0.077 X-LERCTR-Spam-Report: SpamScore (-2.4/5.0) ALL_TRUSTED=-1.8, BAYES_00=-2.599, TVD_RCVD_IP=1.931, TW_KB=0.077 DomainKey-Status: no signature Cc: freebsd-stable@freebsd.org Subject: Re: IPMI Console: No luck once OS is booted X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Aug 2008 17:03:41 -0000 On Sun, 10 Aug 2008, David Duchscher wrote: > On Aug 10, 2008, at 10:22 AM, Larry Rosenman wrote: > >>> I don't have that IPMI card but I can say we have other cards of theirs >>> working. I would make sure the card is at the latest version of firmware. >>> The AOC-SIMSO(+) card was not detected correctly until we upgraded. I >>> don't know why the card is going away when freebsd boots since I assume >>> you are on the dedicated LAN interface with its own IP address. >> Yes. It's not going away, just doesn't see the key strokes. > > Looking through your dmesg file, I don't see a USB keyboard being attached. > On my system, the virtual keyboard is a USB keyboard. > > ukbd0: on uhub3 > kbd2 at ukbd0 Good catch. When I set it to disable USB Mass Storage when no image is loaded, the ukbd came alive, and I'm typing this on the IPMI Console. Thanks! > > -- > DaveD > -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 From owner-freebsd-stable@FreeBSD.ORG Sun Aug 10 19:50:46 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 85B251065680 for ; Sun, 10 Aug 2008 19:50:46 +0000 (UTC) (envelope-from kes-kes@yandex.ru) Received: from webmail25.yandex.ru (webmail25.yandex.ru [213.180.223.152]) by mx1.freebsd.org (Postfix) with ESMTP id 16ABC8FC1E for ; Sun, 10 Aug 2008 19:50:45 +0000 (UTC) (envelope-from kes-kes@yandex.ru) Received: from YAMAIL (webmail25) by mail.yandex.ru id S3686448AbYHJTuh for ; Sun, 10 Aug 2008 23:50:37 +0400 X-Yandex-Spam: 1 Received: from [92.113.12.164] ([92.113.12.164]) by mail.yandex.ru with HTTP; Sun, 10 Aug 2008 23:50:37 +0400 From: KES To: pi@opsec.eu In-Reply-To: <20080809143019.GB3984@home.opsec.eu> References: <358831218288212@webmail24.yandex.ru> <20080809143019.GB3984@home.opsec.eu> MIME-Version: 1.0 Message-Id: <375251218397837@webmail25.yandex.ru> Date: Sun, 10 Aug 2008 23:50:37 +0400 X-Mailer: Yamail [ http://yandex.ru ] 5.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain Cc: freebsd-stable@freebsd.org Subject: Re: IMPORTANT! Network is unreachable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Aug 2008 19:50:46 -0000 09.08.08, 18:30, "Kurt Jaeger" : > Hi! > > So I do not think that problem is with the network mask. Because of even ping 10.11.16.14 > > returns network is unreachable! > > Now when I upgraded to v7 I see trouble described earlier. > > So this is must be counted as BUG of v7 > It might be some issue with ARP timeouts ? 10.11.16.14 is local address tcpdump on the interface with this address shows nothing >The system learns > the other IPs using some indirect way and forgets it as soon > as the arp address times out ? I do not think so. Because of when I ping local address 10.11.16.14 for an our without breaking this ping. So mac address can not die because of timeout. It dissappears from kernel routing table by some other cause. I do not know which cause > > 5min period is seen without routed. > > With routed I get next picture: > > start routed: network is unreachable > > stop routed: network still unreacheable > > start routed: network is reachable > > stop routed: network is reacheable > > start routed: network is unreachable again > > > > The thing which is very interesting is: > > Why period is 5 min? > Why do you run routed ? I want to use RIP > Why don't you just statically assign the routes ? Because of I have two links to same place router1 --- LAN1 --- router2 | / LAN2 LAN3 | / router3 ---------/ router1: 10.0.16.1/24, 10.10.16.8/24 router2: 10.11.16.1/24, 10.0.16.3/24 router3: 10.11.16.14/24, 10.10.16.3/24 LAN1: 10.0.16.0 LAN2: 10.10.16.0 LAN3: 10.11.16.0 router3: rl0: flags=8843 metric 0 mtu 1500 options=8 ether 00:0e:2e:db:4f:d4 inet 10.11.16.14 netmask 0xffffff00 broadcast 10.11.16.255 inet 10.11.16.9 netmask 0xffffff00 broadcast 10.11.16.255 inet 10.10.16.3 netmask 0xfffffff0 broadcast 10.10.16.15 media: Ethernet autoselect (100baseTX ) status: active I add 10.10.16.3 address to rl0 by mistake. It must be on rl1 interface. But when I added it I lose connection to my LAN. I think this behavior is bug so I describe problem in letters earlier From owner-freebsd-stable@FreeBSD.ORG Sun Aug 10 20:03:59 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AA2431065743 for ; Sun, 10 Aug 2008 20:03:59 +0000 (UTC) (envelope-from kes-kes@yandex.ru) Received: from webmail23.yandex.ru (webmail23.yandex.ru [213.180.223.148]) by mx1.freebsd.org (Postfix) with ESMTP id 3B97E8FC0A for ; Sun, 10 Aug 2008 20:03:59 +0000 (UTC) (envelope-from kes-kes@yandex.ru) Received: from YAMAIL (webmail23) by mail.yandex.ru id S7439224AbYHJUDw for ; Mon, 11 Aug 2008 00:03:52 +0400 X-Yandex-Spam: 1 Received: from [92.113.12.164] ([92.113.12.164]) by mail.yandex.ru with HTTP; Mon, 11 Aug 2008 00:03:51 +0400 From: KES To: freebsd-stable@freebsd.org MIME-Version: 1.0 Message-Id: <666661218398631@webmail23.yandex.ru> Date: Mon, 11 Aug 2008 00:03:51 +0400 X-Mailer: Yamail [ http://yandex.ru ] 5.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain Subject: Re: IMPORTANT! Network is unreachable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Aug 2008 20:03:59 -0000 09.08.08, 22:37, "Clifton Royston" : > On Sat, Aug 09, 2008 at 05:23:32PM +0400, KES wrote: > > 09.08.08, 16:22, "Matthew Seaman" : > > > Andrew Snow wrote: > > > > Usually if there is more than IP in a given subnet on an interface, you > > > > give it a /32 netmask. Only the first IP in a subnet should have the > > > > full netmask. > > > > > > > > So your example should look like this: > > > > > > > > inet 10.11.16.14 netmask 0xffffff00 broadcast 10.11.16.255 > > > > inet 10.11.16.9 netmask 0xffffffff broadcast 10.11.16.9 > > > /32 netmasks for 2nd and subsequent IP alias addresses used to be > > > mandatory and are arguably more correct, but nowadays you can use > > > the actual netmask for the network instead. Was fixed a year or > > > two ago. It's a wetware compatibility thing -- other unixoid OSes > > > never had the /32 netmask requirement, and it kept tripping people up > > > when swapping between OSes. > > > Unfortunately I can't say exactly what the problem the OP is experiencing > > > is due to, but the way routes are appearing and disappearing on a 5 > > > minute timescale does suggest dynamic routing problems to me. As a > > > work-around, if the OP wanted to override the information routed gets > > > from the network, then he could use /etc/gateways to have the local > > > routed append some static routes to the routing table -- see routed(8) > > > for the gory details. Losing a route for a directly attached network > > > looks like a bug to me though. > ... > > > > > > inet 10.11.16.14 netmask 0xffffff00 broadcast 10.11.16.255 > > > > inet 10.11.16.9 netmask 0xffffffff broadcast 10.11.16.9 > > /24 mask on each IPs on same interfaces is working fine on FreeBSD 6.3 > > So I do not think that problem is with the network mask. Because of even ping 10.11.16.14 > > returns network is unreachable! > > Now when I upgraded to v7 I see trouble described earlier. > > So this is must be counted as BUG of v7 > I happened to see recently a report of a similar problem with 7.0 on > a private mailing list. Again, there were multiple IP addresses > configured within the main subnet of the interface (this time > configured as /32s on other physical interfaces) and again, after a > while the system lost connectivity to its main subnet and "forgot" how > to ARP for addresses on the interface. An important similarity - the > routing info like yours showed the attached network with the G flag, as > being reachable via the gateway address within the same subnet. > I can't troubleshoot this, no access to the system in question, but I > thought it might help to know that others have run into the same > problem. > > The thing which is very interesting is: > > Why period is 5 min? > Might be something to do with ARP? Not sure. > -- Clifton >I can't troubleshoot this, no access to the system in question You mean you can try to resolve trouble if you get access to machine? I also have tryed /32, but this do not help: gorodok# ifconfig rl0 rl0: flags=8843 metric 0 mtu 1500 options=8 ether 00:0e:2e:db:4f:d4 inet 10.11.16.14 netmask 0xffffff00 broadcast 10.11.16.255 inet 10.11.16.9 netmask 0xffffffff broadcast 10.11.16.9 media: Ethernet autoselect (100baseTX ) status: active gorodok# ifconfig rl0 add 10.10.16.3/28 gorodok# ping 10.10.16.3 PING 10.10.16.3 (10.10.16.3): 56 data bytes ping: sendto: Network is unreachable ping: sendto: Network is unreachable ^C --- 10.10.16.3 ping statistics --- 2 packets transmitted, 0 packets received, 100.0% packet loss gorodok# netstat -nr Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 10.11.16.1 UGS 0 32727 rl0 10.0.0.0/16 10.11.16.2 UG 0 0 rl0 10.10.16.0/28 10.10.16.3 UGC 0 2 rl0 10.11.15.0/24 link#2 UC 0 0 rl1 10.11.16.0/24 link#1 UC 0 0 rl0 10.11.16.1 00:e0:4c:59:50:7e UHLW 2 0 rl0 1193 10.11.16.2 00:03:79:01:9b:d0 UHLW 2 0 rl0 1126 10.11.16.9 10.11.16.9 UH 0 0 rl0 => 10.11.16.9/32 link#1 UC 0 0 rl0 10.11.16.12 00:0c:6e:ff:0b:35 UHLW 1 2472 rl0 1127 10.11.16.14 00:0e:2e:db:4f:d4 UHLW 1 31 lo0 127.0.0.1 127.0.0.1 UH 0 314 lo0 Internet6: Destination Gateway Flags Netif Expire ::1 ::1 UHL lo0 fe80::%lo0/64 fe80::1%lo0 U lo0 fe80::1%lo0 link#4 UHL lo0 ff01:4::/32 fe80::1%lo0 UC lo0 ff02::%lo0/32 fe80::1%lo0 UC lo0 It seems v7 thinks that 10.10.16.3 is not local IP So it add route to 10.10.16.0/28 via gateway 10.10.16.3 I think something in wrong in algorithm of adding IP to system And somebody broke something in right code of FreeBSD 6.3 So I think if you diff file FreeBSD 6.3 and FreeBSD 7.0 that responsible for routing you can find mistake and it may be fixed easily =) From owner-freebsd-stable@FreeBSD.ORG Sun Aug 10 23:01:41 2008 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0B6B8106567C for ; Sun, 10 Aug 2008 23:01:41 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [192.147.25.65]) by mx1.freebsd.org (Postfix) with ESMTP id E17448FC1F for ; Sun, 10 Aug 2008 23:01:40 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from 76-205-169-61.lightspeed.austtx.sbcglobal.net ([76.205.169.61]:63161 helo=borg) by thebighonker.lerctr.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KSJus-000CkU-5P for freebsd-stable@FreeBSD.org; Sun, 10 Aug 2008 18:01:39 -0500 Date: Sun, 10 Aug 2008 18:01:34 -0500 (CDT) From: Larry Rosenman Sender: ler@borg To: freebsd-stable@FreeBSD.org Message-ID: <20080810175934.X2427@borg> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: -2.5 (--) X-LERCTR-Spam-Score: -2.5 (--) X-Spam-Report: SpamScore (-2.5/5.0) ALL_TRUSTED=-1.8, BAYES_00=-2.599, TVD_RCVD_IP=1.931 X-LERCTR-Spam-Report: SpamScore (-2.5/5.0) ALL_TRUSTED=-1.8, BAYES_00=-2.599, TVD_RCVD_IP=1.931 DomainKey-Status: no signature Cc: Subject: ICRC's X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Aug 2008 23:01:41 -0000 I'm getting the following on a zpool scrub: ad8: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=54817587 ad8: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=187521229 ad8: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=187522189 ad8: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=109095258 ad8: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=101327859 ad8: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=172911744 ad8: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=65393370 ad8: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=64741875 ad8: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=262496999 ad8: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=154593293 pool: vault state: ONLINE status: One or more devices has experienced an unrecoverable error. An attempt was made to correct the error. Applications are unaffected. action: Determine if the device needs to be replaced, and clear the errors using 'zpool clear' or replace the device with 'zpool replace'. see: http://www.sun.com/msg/ZFS-8000-9P scrub: scrub completed with 0 errors on Sun Aug 10 16:20:30 2008 config: NAME STATE READ WRITE CKSUM vault ONLINE 0 0 0 raidz1 ONLINE 0 0 0 ad6 ONLINE 0 0 0 ad8 ONLINE 0 0 17 ad10 ONLINE 0 0 0 ad12 ONLINE 0 0 0 ad14 ONLINE 0 0 0 ad4s1f ONLINE 0 0 0 ad4s1e ONLINE 0 0 0 ad4s1d ONLINE 0 0 0 errors: No known data errors I replaced the drive at ad8 because the original one would get an ICRC and then hang the bus. Smart info: smartctl version 5.38 [amd64-portbld-freebsd7.0] Copyright (C) 2002-8 Bruce Allen Home page is http://smartmontools.sourceforge.net/ === START OF INFORMATION SECTION === Model Family: Seagate Barracuda 7200.10 family Device Model: ST3500630AS Serial Number: 9QG19C2Q Firmware Version: 3.AAE User Capacity: 500,107,862,016 bytes Device is: In smartctl database [for details use: -P show] ATA Version is: 7 ATA Standard is: Exact ATA specification draft version not indicated Local Time is: Sun Aug 10 18:01:07 2008 CDT SMART support is: Available - device has SMART capability. SMART support is: Enabled === START OF READ SMART DATA SECTION === SMART overall-health self-assessment test result: PASSED General SMART Values: Offline data collection status: (0x82) Offline data collection activity was completed without error. Auto Offline Data Collection: Enabled. Self-test execution status: ( 0) The previous self-test routine completed without error or no self-test has ever been run. Total time to complete Offline data collection: ( 430) seconds. Offline data collection capabilities: (0x5b) SMART execute Offline immediate. Auto Offline data collection on/off support. Suspend Offline collection upon new command. Offline surface scan supported. Self-test supported. No Conveyance Self-test supported. Selective Self-test supported. SMART capabilities: (0x0003) Saves SMART data before entering power-saving mode. Supports SMART auto save timer. Error logging capability: (0x01) Error logging supported. General Purpose Logging supported. Short self-test routine recommended polling time: ( 1) minutes. Extended self-test routine recommended polling time: ( 163) minutes. SMART Attributes Data Structure revision number: 10 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x000f 105 100 006 Pre-fail Always - 9366477 3 Spin_Up_Time 0x0003 095 095 000 Pre-fail Always - 0 4 Start_Stop_Count 0x0032 100 100 020 Old_age Always - 4 5 Reallocated_Sector_Ct 0x0033 100 100 036 Pre-fail Always - 0 7 Seek_Error_Rate 0x000f 063 060 030 Pre-fail Always - 2364626 9 Power_On_Hours 0x0032 100 100 000 Old_age Always - 41 10 Spin_Retry_Count 0x0013 100 100 097 Pre-fail Always - 0 12 Power_Cycle_Count 0x0032 100 100 020 Old_age Always - 7 187 Reported_Uncorrect 0x0032 100 100 000 Old_age Always - 0 189 High_Fly_Writes 0x003a 100 100 000 Old_age Always - 0 190 Airflow_Temperature_Cel 0x0022 064 061 045 Old_age Always - 36 (Lifetime Min/Max 35/39) 194 Temperature_Celsius 0x0022 036 040 000 Old_age Always - 36 (0 32 0 0) 195 Hardware_ECC_Recovered 0x001a 068 064 000 Old_age Always - 207627383 197 Current_Pending_Sector 0x0012 100 100 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0010 100 100 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 94 200 Multi_Zone_Error_Rate 0x0000 100 253 000 Old_age Offline - 0 202 TA_Increase_Count 0x0032 100 253 000 Old_age Always - 0 SMART Error Log Version: 1 ATA Error Count: 110 (device log contains only the most recent five errors) CR = Command Register [HEX] FR = Features Register [HEX] SC = Sector Count Register [HEX] SN = Sector Number Register [HEX] CL = Cylinder Low Register [HEX] CH = Cylinder High Register [HEX] DH = Device/Head Register [HEX] DC = Device Command Register [HEX] ER = Error register [HEX] ST = Status register [HEX] Powered_Up_Time is measured from power on, and printed as DDd+hh:mm:SS.sss where DD=days, hh=hours, mm=minutes, SS=sec, and sss=millisec. It "wraps" after 49.710 days. Error 110 occurred at disk power-on lifetime: 41 hours (1 days + 17 hours) When the command that caused the error occurred, the device was active or idle. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 84 51 0f fe e7 36 49 Error: ICRC, ABRT 15 sectors at LBA = 0x0936e7fe = 154593278 Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- ---------------- -------------------- c8 00 00 0d e7 36 49 00 01:23:46.872 READ DMA c8 00 00 0d e6 36 49 00 01:23:46.871 READ DMA c8 00 00 0d e5 36 49 00 01:23:46.871 READ DMA c8 00 00 0d e4 36 49 00 01:23:46.870 READ DMA c8 00 00 0d e3 36 49 00 01:23:46.853 READ DMA Error 109 occurred at disk power-on lifetime: 40 hours (1 days + 16 hours) When the command that caused the error occurred, the device was active or idle. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 84 51 5f 88 62 a5 4f Error: ICRC, ABRT 95 sectors at LBA = 0x0fa56288 = 262496904 Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- ---------------- -------------------- c8 00 00 e7 61 a5 4f 00 01:11:12.732 READ DMA c8 00 00 e7 60 a5 4f 00 01:11:12.730 READ DMA c8 00 00 e7 5f a5 4f 00 01:11:12.729 READ DMA c8 00 00 e7 5e a5 4f 00 01:11:12.727 READ DMA c8 00 00 e7 5d a5 4f 00 01:11:12.724 READ DMA Error 108 occurred at disk power-on lifetime: 40 hours (1 days + 16 hours) When the command that caused the error occurred, the device was active or idle. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 84 51 1f d4 e1 db 43 Error: ICRC, ABRT 31 sectors at LBA = 0x03dbe1d4 = 64741844 Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- ---------------- -------------------- c8 00 40 b3 e1 db 43 00 01:10:40.553 READ DMA c8 00 40 73 e1 db 43 00 01:10:40.552 READ DMA c8 00 40 33 e1 db 43 00 01:10:40.487 READ DMA c8 00 00 33 e0 db 43 00 01:10:40.485 READ DMA c8 00 00 33 df db 43 00 01:10:40.484 READ DMA Error 107 occurred at disk power-on lifetime: 40 hours (1 days + 16 hours) When the command that caused the error occurred, the device was active or idle. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 84 51 3f 8e d2 e5 43 Error: ICRC, ABRT 63 sectors at LBA = 0x03e5d28e = 65393294 Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- ---------------- -------------------- c8 00 00 cd d1 e5 43 00 00:52:56.221 READ DMA c8 00 40 5a d1 e5 43 00 00:52:56.218 READ DMA c8 00 00 5a d0 e5 43 00 00:52:56.217 READ DMA c8 00 00 5a cf e5 43 00 00:52:56.216 READ DMA c8 00 c0 67 ce e5 43 00 00:52:56.215 READ DMA Error 106 occurred at disk power-on lifetime: 40 hours (1 days + 16 hours) When the command that caused the error occurred, the device was active or idle. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 84 51 2f 51 6c 4e 4a Error: ICRC, ABRT 47 sectors at LBA = 0x0a4e6c51 = 172911697 Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- ---------------- -------------------- c8 00 80 00 6c 4e 4a 00 00:40:47.156 READ DMA c8 00 80 80 6b 4e 4a 00 00:40:47.156 READ DMA c8 00 80 00 6b 4e 4a 00 00:40:47.155 READ DMA c8 00 80 80 6a 4e 4a 00 00:40:47.155 READ DMA c8 00 80 00 6a 4e 4a 00 00:40:47.155 READ DMA SMART Self-test log structure revision number 1 Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error # 1 Short offline Completed without error 00% 32 - # 2 Short offline Completed without error 00% 10 - SMART Selective self-test log data structure revision number 1 SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS 1 0 0 Not_testing 2 0 0 Not_testing 3 0 0 Not_testing 4 0 0 Not_testing 5 0 0 Not_testing Selective self-test flags (0x0): After scanning selected spans, do NOT read-scan remainder of disk. If Selective self-test is pending on power-up, resume after 0 minute delay. Ideas? This is on a SuperMicro SYS-7045-TR+ -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 From owner-freebsd-stable@FreeBSD.ORG Sun Aug 10 23:41:59 2008 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3D30D1065670 for ; Sun, 10 Aug 2008 23:41:59 +0000 (UTC) (envelope-from jdc@parodius.com) Received: from mx01.sc1.parodius.com (mx01.sc1.parodius.com [72.20.106.3]) by mx1.freebsd.org (Postfix) with ESMTP id 2D5898FC12 for ; Sun, 10 Aug 2008 23:41:59 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id 222E01CC0BB; Sun, 10 Aug 2008 16:41:59 -0700 (PDT) Date: Sun, 10 Aug 2008 16:41:59 -0700 From: Jeremy Chadwick To: Larry Rosenman Message-ID: <20080810234159.GA89742@eos.sc1.parodius.com> References: <20080810175934.X2427@borg> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080810175934.X2427@borg> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-stable@FreeBSD.org Subject: Re: ICRC's X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Aug 2008 23:41:59 -0000 On Sun, Aug 10, 2008 at 06:01:34PM -0500, Larry Rosenman wrote: > I'm getting the following on a zpool scrub: > > ad8: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=54817587 > > I replaced the drive at ad8 because the original one would get an ICRC and then hang the bus. > > Model Family: Seagate Barracuda 7200.10 family > Device Model: ST3500630AS > ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE > 1 Raw_Read_Error_Rate 0x000f 105 100 006 Pre-fail Always - 9366477 > 7 Seek_Error_Rate 0x000f 063 060 030 Pre-fail Always - 2364626 > 9 Power_On_Hours 0x0032 100 100 000 Old_age Always - 41 > 12 Power_Cycle_Count 0x0032 100 100 020 Old_age Always - 7 > 190 Airflow_Temperature_Cel 0x0022 064 061 045 Old_age Always - 36 (Lifetime Min/Max 35/39) > 194 Temperature_Celsius 0x0022 036 040 000 Old_age Always - 36 (0 32 0 0) > 195 Hardware_ECC_Recovered 0x001a 068 064 000 Old_age Always - 207627383 > 199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 94 > > Error 110 occurred at disk power-on lifetime: 41 hours (1 days + 17 hours) > When the command that caused the error occurred, the device was active or idle. > > After command completion occurred, registers were: > ER ST SC SN CL CH DH > -- -- -- -- -- -- -- > 84 51 0f fe e7 36 49 Error: ICRC, ABRT 15 sectors at LBA = 0x0936e7fe = 154593278 > > Commands leading to the command that caused the error were: > CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name > -- -- -- -- -- -- -- -- ---------------- -------------------- > c8 00 00 0d e7 36 49 00 01:23:46.872 READ DMA > c8 00 00 0d e6 36 49 00 01:23:46.871 READ DMA > c8 00 00 0d e5 36 49 00 01:23:46.871 READ DMA > c8 00 00 0d e4 36 49 00 01:23:46.870 READ DMA > c8 00 00 0d e3 36 49 00 01:23:46.853 READ DMA > > Ideas? > > This is on a SuperMicro SYS-7045-TR+ You have one or more of the following: 1. Faulty ATA cable 2. Faulty ATA port 3. Faulty ATA controller (doubtful, unless the errors are specific to one role (e.g. master or slave)) 4. A 2nd disk which is equally as bad (came from the same manufacturing batch, which is very likely if the drive is of the same vendor and model type, and manufacturing date (within a month or two)) The disk's SMART error log even confirms the DMA errors, which proves there is in fact a problem with one of the above. In this particular case, it's not FreeBSD. :-) My recommendation: * Try another disk from a different manufacturer (not Seagate) * If similar errors appear using that disk, the problem is either item 1, 2, or 3. * If no errors appear, it's item 4, in which case send the disk to Seagate for RMA; their SeaTools utility, on a full scan, should definitely return an error code which you can give to Support when filing for the RMA. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Mon Aug 11 00:34:32 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4A0EC1065675 for ; Mon, 11 Aug 2008 00:34:32 +0000 (UTC) (envelope-from alex-goncharov@comcast.net) Received: from QMTA04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by mx1.freebsd.org (Postfix) with ESMTP id E8A3D8FC14 for ; Mon, 11 Aug 2008 00:34:31 +0000 (UTC) (envelope-from alex-goncharov@comcast.net) Received: from OMTA05.westchester.pa.mail.comcast.net ([76.96.62.43]) by QMTA04.westchester.pa.mail.comcast.net with comcast id 0eQL1a0030vyq2s54oaXex; Mon, 11 Aug 2008 00:34:31 +0000 Received: from daland.home ([24.61.21.4]) by OMTA05.westchester.pa.mail.comcast.net with comcast id 0oaX1a00105H7zL3RoaXzg; Mon, 11 Aug 2008 00:34:31 +0000 X-Authority-Analysis: v=1.0 c=1 a=rITDv7nW5hcA:10 a=wFaEK3txAAAA:8 a=DWWbkNoQ0lDxQFEfgYsA:9 a=J4ah-IX0tIqEXMK03N0A:7 a=irNjGHgpdqU9FYZOZYpIRdIFXXgA:4 a=si9q_4b84H0A:10 a=gi0PWCVxevcA:10 Received: from algo by daland.home with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KSLMk-0008kT-PZ for freebsd-stable@FreeBSD.org; Sun, 10 Aug 2008 20:34:30 -0400 From: Alex Goncharov To: freebsd-stable@FreeBSD.org Message-Id: Sender: Alex Goncharov Date: Sun, 10 Aug 2008 20:34:30 -0400 Cc: Subject: Groff in FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Goncharov List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2008 00:34:32 -0000 I am trying to refresh my old groff skills, playing with it for the first time on FreeBSD -- and getting very confused with understanding groff's place and organization here. (I am writing this on FreeBSD 7.0 but I could start an 8.0 system if somebody suggested to take a look there). Let's start with the practical end of it: I wanted to find a good macro package, good by modern standards. In the past, I've tried 'mm', 'ms', 'me' -- and could never decide which one was the most practical one (well, 'mm', perhaps). These days, it seems like 'mom' is a popular package, worth a serious attention. So, I am trying to see if 'mom' is available on my system, and it is not. I do various online searches, and the only thing that comes up is: http://unix.derkeiler.com/Mailing-Lists/FreeBSD/stable/2003-11/0407.html groff macro package 'mom' not installed Date: 11/24/03 (and similar entries) 'mom' is, of course, in the source tree: ls -ld /usr/src/contrib/groff/contrib/mom drwxr-xr-x 4 root wheel 512 Mar 26 19:30 /usr/src/contrib/groff/contrib/mom/ as is 'mm': ls -ld /usr/src/contrib/groff/contrib/mm drwxr-xr-x 4 root wheel 512 Mar 26 19:29 /usr/src/contrib/groff/contrib/mm/ But while the latter has "tmac" files installed: ls /usr/share/tmac/mm* 0.MT 4.MT 5.MT locale mm.tmac mmse.tmac ms.cov se_locale se_ms.cov the former does not: ls /usr/share/tmac/mom* ls: /usr/share/tmac/mom*: No such file or directory So, I try to build something relevant by hand, and nothing good comes out of it. But I notice that the '/usr/src/contrib/groff/contrib/mm' directory is not the only place for 'mm' -- there is also ls -ld /usr/src/gnu/usr.bin/groff/contrib/mm drwxr-xr-x 2 root wheel 512 Aug 10 17:48 /usr/src/gnu/usr.bin/groff/contrib/mm/ which is a built entity. At this point, I begin not care about having 'mom' -- I just want to understand the groff organization in FreeBSD. Things that puzzle me: 1. Under '/usr/obj', there is a 'tmp/legacy' directory, which has an empty 'mm' directory deep down: find tmp/legacy/usr/share/tmac/mm -ls 518462 4 drwxr-xr-x 2 root wheel 512 Aug 9 23:05 tmp/legacy/usr/share/tmac/mm What is this 'tmp/legacy'? 2. There is an odd relationship between "tmac" files under '/usr/src' and '/usr/obj': ---------------------------------------- for cmd in "ls -l" "diff -q"; do for f in pic.tmac doc.tmac; do $cmd /usr/src/contrib/groff/tmac/$f /usr/obj//usr/src/tmp/legacy/usr/share/tmac/$f; done; done -rwxr-xr-x 1 root wheel 117 Apr 17 2001 /usr/obj/i386/x01/freebsd/7.0/usr/src/tmp/legacy/usr/share/tmac/pic.tmac -rw-r--r-- 1 root wheel 117 Apr 17 2001 /usr/src/contrib/groff/tmac/pic.tmac -rwxr-xr-x 1 root wheel 73079 Aug 9 23:05 /usr/obj/i386/x01/freebsd/7.0/usr/src/tmp/legacy/usr/share/tmac/doc.tmac -rw-r--r-- 1 root wheel 148585 Oct 20 2005 /usr/src/contrib/groff/tmac/doc.tmac Files /usr/src/contrib/groff/tmac/doc.tmac and /usr/obj/i386/x01/freebsd/7.0/usr/src/tmp/legacy/usr/share/tmac/doc.tmac differ ---------------------------------------- I.e. some files under '/usr/obj' are regenerated (see "Aug 9" for 'doc.tmac'), and others are not ('pic.mac'). Some files are identical in both places, and others are not. What is the logic and mechanics here? Can anybody shed some light on this? And also, if somebody had a recommendation on the most practical choice of the macro package, it would be highly appreciated. Thank you, -- Alex -- alex-goncharov@comcast.net -- From owner-freebsd-stable@FreeBSD.ORG Mon Aug 11 01:48:24 2008 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B15CF1065671; Mon, 11 Aug 2008 01:48:24 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [192.147.25.65]) by mx1.freebsd.org (Postfix) with ESMTP id 8B5528FC08; Mon, 11 Aug 2008 01:48:24 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from 76-205-169-61.lightspeed.austtx.sbcglobal.net ([76.205.169.61]:55307 helo=borg) by thebighonker.lerctr.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KSMWE-000DjW-Vx; Sun, 10 Aug 2008 20:48:24 -0500 Date: Sun, 10 Aug 2008 20:48:18 -0500 (CDT) From: Larry Rosenman Sender: ler@borg To: Jeremy Chadwick In-Reply-To: <20080810234159.GA89742@eos.sc1.parodius.com> Message-ID: <20080810204709.X4636@borg> References: <20080810175934.X2427@borg> <20080810234159.GA89742@eos.sc1.parodius.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: -2.5 (--) X-LERCTR-Spam-Score: -2.5 (--) X-Spam-Report: SpamScore (-2.5/5.0) ALL_TRUSTED=-1.8, BAYES_00=-2.599, TVD_RCVD_IP=1.931 X-LERCTR-Spam-Report: SpamScore (-2.5/5.0) ALL_TRUSTED=-1.8, BAYES_00=-2.599, TVD_RCVD_IP=1.931 DomainKey-Status: no signature Cc: freebsd-stable@FreeBSD.org Subject: Re: ICRC's X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2008 01:48:24 -0000 On Sun, 10 Aug 2008, Jeremy Chadwick wrote: > On Sun, Aug 10, 2008 at 06:01:34PM -0500, Larry Rosenman wrote: > > You have one or more of the following: > > 1. Faulty ATA cable > 2. Faulty ATA port > 3. Faulty ATA controller (doubtful, unless the errors are specific > to one role (e.g. master or slave)) > 4. A 2nd disk which is equally as bad (came from the same manufacturing > batch, which is very likely if the drive is of the same vendor and > model type, and manufacturing date (within a month or two)) We have a winner. I replaced the cable, and we get a clean scrub: pool: vault state: ONLINE scrub: scrub completed with 0 errors on Sun Aug 10 20:46:37 2008 config: NAME STATE READ WRITE CKSUM vault ONLINE 0 0 0 raidz1 ONLINE 0 0 0 ad6 ONLINE 0 0 0 ad8 ONLINE 0 0 0 ad10 ONLINE 0 0 0 ad12 ONLINE 0 0 0 ad14 ONLINE 0 0 0 ad4s1f ONLINE 0 0 0 ad4s1e ONLINE 0 0 0 ad4s1d ONLINE 0 0 0 errors: No known data errors Much nicer. Thanks, Jeremy! -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 From owner-freebsd-stable@FreeBSD.ORG Mon Aug 11 02:24:27 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 061A91065670 for ; Mon, 11 Aug 2008 02:24:27 +0000 (UTC) (envelope-from kasahara@nc.kyushu-u.ac.jp) Received: from elvenbow.cc.kyushu-u.ac.jp (unknown [IPv6:2001:200:905:1314::80]) by mx1.freebsd.org (Postfix) with ESMTP id 9605F8FC15 for ; Mon, 11 Aug 2008 02:24:26 +0000 (UTC) (envelope-from kasahara@nc.kyushu-u.ac.jp) Received: from localhost (kasahara@localhost [IPv6:::1]) by elvenbow.cc.kyushu-u.ac.jp (8.14.2/8.14.2) with ESMTP id m7B2OP4c019738 for ; Mon, 11 Aug 2008 11:24:25 +0900 (JST) (envelope-from kasahara@nc.kyushu-u.ac.jp) Date: Mon, 11 Aug 2008 11:24:25 +0900 (JST) Message-Id: <20080811.112425.871254896763663867.kasahara@nc.kyushu-u.ac.jp> To: freebsd-stable@freebsd.org From: Yoshiaki Kasahara In-Reply-To: <200808071134.41927.freebsd-stable@dino.sk> References: <1EE0EC59-C48C-4B07-B08E-77BE388BBDE1@develooper.com> <20080807090422.GA19885@eos.sc1.parodius.com> <200808071134.41927.freebsd-stable@dino.sk> X-Fingerprint: CDA2 B6B6 6796 0DD3 9D80 2602 E909 4623 A15E A074 X-URL: http://www.nc.kyushu-u.ac.jp/~kasahara/ X-Mailer: Mew version 6.1.50 on Emacs 23.0.60 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: i386 vs amd64? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2008 02:24:27 -0000 On Thu, 7 Aug 2008 11:34:41 +0200, Milan Obuch said: > Funny observation: "r" is on LEFT keyboard side, "l" is on RIGHT keyboard > side. I for one have problem at times precisely for this reason, but I know > this is an important step and one need to act with great care. I use a different mnemonic: r)eplace and l)eave untouched (I read it in this ML a long time ago). Regards, -- Yoshiaki Kasahara Research Institute for Information Technology, Kyushu University kasahara@nc.kyushu-u.ac.jp From owner-freebsd-stable@FreeBSD.ORG Mon Aug 11 02:31:02 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5CEE0106566B for ; Mon, 11 Aug 2008 02:31:02 +0000 (UTC) (envelope-from kuuse@redantigua.com) Received: from kilimanjaro.scorpionshops.com (kilimanjaro.scorpionshops.com [83.140.32.147]) by mx1.freebsd.org (Postfix) with ESMTP id E3FB68FC21 for ; Mon, 11 Aug 2008 02:31:01 +0000 (UTC) (envelope-from kuuse@redantigua.com) Received: from [192.168.1.128] (144.Red-83-49-238.dynamicIP.rima-tde.net [83.49.238.144]) by kilimanjaro.scorpionshops.com (Postfix) with ESMTP id 270C9FD8011 for ; Mon, 11 Aug 2008 04:01:52 +0200 (CEST) From: Johan Kuuse Organization: Red Antigua To: freebsd-stable@freebsd.org Date: Mon, 11 Aug 2008 04:01:49 +0200 User-Agent: KMail/1.9.7 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200808110401.49953.kuuse@redantigua.com> Subject: kernel panic X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2008 02:31:02 -0000 Hi, I am a kgdb newbie, so please be patient. I suspect (just based on the fact that this is the 4th time I edit text files on my NTFS partition through ntfs-3g, using Emacs, and getting frequent I/O error messages inside Emacs, and then a kernel panic) that this is a ntfs-3g related problem. If you ask me exactly how to reproduce it, I sorry, I can tell you exactly (but see the kgdb output below). Anyway, the kernel seems to panic at /usr/src/sys/kern/vfs_bio.c:1530 Just a suggestion for a patch (without knowing the functionality of /usr/src/sys/kern/vfs_bio.c): The line where the kernel panics: /usr/src/sys/kern/vfs_bio.c: ---------------------------------- VM_OBJECT_LOCK(bp->b_bufobj->bo_object); ... ---------------------------------- Comparing to another file, which does error checking before calling VM_OBJECT_LOCK: /usr/src/sys/kern/vfs_aio.c: ---------------------------------- if (vp->v_object != NULL) { VM_OBJECT_LOCK(vp->v_object); ... ---------------------------------- Perhaps the kernel panic could be avoided with the following patch? /usr/src/sys/kern/vfs_bio.c (suggested patch): ---------------------------------- if ((bp->b_bufobj != NULL) && (bp->b_bufobj->bo_object != NULL)) { VM_OBJECT_LOCK(bp->b_bufobj->bo_object); ... ---------------------------------- Please let me know if you need more information. Regards, Johan Kuuse ----------------------------------------------------------------------------------------------------------- kgdb kernel.debug /var/crash/vmcore.1 [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd". Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x34 fault code = supervisor read, page not present instruction pointer = 0x20:0xc07b6de4 stack pointer = 0x28:0xe79de7c8 frame pointer = 0x28:0xe79de7e8 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 1214 (opera) trap number = 12 panic: page fault cpuid = 0 Uptime: 5h20m30s Physical memory: 2035 MB Dumping 218 MB: 203 187 171 155 139 123 107 91 75 59 43 27 11 #0 doadump () at pcpu.h:195 195 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); (kgdb) list *0xc07b6de4 0xc07b6de4 is in vfs_vmio_release (/usr/src/sys/kern/vfs_bio.c:1530). 1525 vfs_vmio_release(struct buf *bp) 1526 { 1527 int i; 1528 vm_page_t m; 1529 1530 VM_OBJECT_LOCK(bp->b_bufobj->bo_object); 1531 vm_page_lock_queues(); 1532 for (i = 0; i < bp->b_npages; i++) { 1533 m = bp->b_pages[i]; 1534 bp->b_pages[i] = NULL; (kgdb) bt #0 doadump () at pcpu.h:195 #1 0xc0754457 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 #2 0xc0754719 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:563 #3 0xc0a4905c in trap_fatal (frame=0xe79de788, eva=52) at /usr/src/sys/i386/i386/trap.c:899 #4 0xc0a492e0 in trap_pfault (frame=0xe79de788, usermode=0, eva=52) at /usr/src/sys/i386/i386/trap.c:812 #5 0xc0a49c8c in trap (frame=0xe79de788) at /usr/src/sys/i386/i386/trap.c:490 #6 0xc0a2fc0b in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #7 0xc07b6de4 in vfs_vmio_release (bp=0xd927e33c) at /usr/src/sys/kern/vfs_bio.c:1530 #8 0xc07b8a81 in getnewbuf (slpflag=0, slptimeo=0, size=Variable "size" is not available. ) at /usr/src/sys/kern/vfs_bio.c:1847 #9 0xc07ba118 in getblk (vp=0xc8891bb0, blkno=0, size=2048, slpflag=0, slptimeo=0, flags=Variable "flags" is not available. ) at /usr/src/sys/kern/vfs_bio.c:2602 #10 0xc0932815 in ffs_balloc_ufs2 (vp=0xc8891bb0, startoffset=Variable "startoffset" is not available. ) at /usr/src/sys/ufs/ffs/ffs_balloc.c:699 #11 0xc0952a85 in ffs_write (ap=0xe79debc4) at /usr/src/sys/ufs/ffs/ffs_vnops.c:720 #12 0xc0a5efc6 in VOP_WRITE_APV (vop=0xc0b93c60, a=0xe79debc4) at vnode_if.c:691 #13 0xc07dbf37 in vn_write (fp=0xc85f3168, uio=0xe79dec60, active_cred=0xc61c6300, flags=0, td=0xc583fc60) at vnode_if.h:373 #14 0xc07875e7 in dofilewrite (td=0xc583fc60, fd=17, fp=0xc85f3168, auio=0xe79dec60, offset=-1, flags=0) at file.h:254 #15 0xc07878c8 in kern_writev (td=0xc583fc60, fd=17, auio=0xe79dec60) at /usr/src/sys/kern/sys_generic.c:401 #16 0xc078793f in write (td=0xc583fc60, uap=0xe79decfc) at /usr/src/sys/kern/sys_generic.c:317 #17 0xc0a49635 in syscall (frame=0xe79ded38) at /usr/src/sys/i386/i386/trap.c:1035 #18 0xc0a2fc70 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:196 #19 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) ----------------------------------------------------------------------------------------------------------- From owner-freebsd-stable@FreeBSD.ORG Mon Aug 11 07:01:53 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 92ED51065671 for ; Mon, 11 Aug 2008 07:01:53 +0000 (UTC) (envelope-from kasahara@nc.kyushu-u.ac.jp) Received: from elvenbow.cc.kyushu-u.ac.jp (unknown [IPv6:2001:200:905:1314::80]) by mx1.freebsd.org (Postfix) with ESMTP id 344BC8FC16 for ; Mon, 11 Aug 2008 07:01:53 +0000 (UTC) (envelope-from kasahara@nc.kyushu-u.ac.jp) Received: from localhost (kasahara@localhost [IPv6:::1]) by elvenbow.cc.kyushu-u.ac.jp (8.14.2/8.14.2) with ESMTP id m7B6PDA8009160 for ; Mon, 11 Aug 2008 15:25:13 +0900 (JST) (envelope-from kasahara@nc.kyushu-u.ac.jp) Date: Mon, 11 Aug 2008 15:25:13 +0900 (JST) Message-Id: <20080811.152513.183744776023472837.kasahara@nc.kyushu-u.ac.jp> To: freebsd-stable@freebsd.org From: Yoshiaki Kasahara X-Fingerprint: CDA2 B6B6 6796 0DD3 9D80 2602 E909 4623 A15E A074 X-URL: http://www.nc.kyushu-u.ac.jp/~kasahara/ X-Mailer: Mew version 6.1.50 on Emacs 23.0.60 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: lost scroll wheel of Intellimouse Explorer 4.0 on 7.0-STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2008 07:01:53 -0000 Hello, Today I updated my desktop PC from FreeBSD 7.0R to 7-STABLE. After that, the scroll wheel of my Intellimouse Explorer 4.0 (USB wired) stopped working. I searched relevant information and found kern/123224 "[ums] Scroll wheel breakage w/ USB MS Wireless Intellimouse Explorer 2.0". The symptom is quite similar. ums0: on uhub0 ums0: 5 buttons and a TILT dir. Note that there is no "Z dir" detected. No one care about that? It is hard for me to live without the mouse wheel nowadays.... I tried another mouse and Z dir was detected properly, so it might be specific to Microsoft products. ums0: on uhub0 ums0: 3 buttons and Z dir. Environment: FreeBSD elvenbow.cc.kyushu-u.ac.jp 7.0-STABLE FreeBSD 7.0-STABLE #0: Mon Aug 11 14:04:03 JST 2008 root@elvenbow.cc.kyushu-u.ac.jp:/usr/obj/usr/src/sys/ELVENBOW amd64 Regards, -- Yoshiaki Kasahara Research Institute for Information Technology, Kyushu University kasahara@nc.kyushu-u.ac.jp From owner-freebsd-stable@FreeBSD.ORG Mon Aug 11 07:15:39 2008 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D2A25106564A for ; Mon, 11 Aug 2008 07:15:39 +0000 (UTC) (envelope-from tom.hurst@clara.net) Received: from spork.qfe3.net (spork.qfe3.net [212.13.207.101]) by mx1.freebsd.org (Postfix) with ESMTP id 90DF28FC1E for ; Mon, 11 Aug 2008 07:15:39 +0000 (UTC) (envelope-from tom.hurst@clara.net) Received: from [81.104.123.28] (helo=voi.aagh.net) by spork.qfe3.net with esmtp (Exim 4.66 (FreeBSD)) (envelope-from ) id 1KSRME-000Bxs-Po; Mon, 11 Aug 2008 07:58:22 +0100 Received: from freaky by voi.aagh.net with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KSRME-000Lfp-Iq; Mon, 11 Aug 2008 07:58:22 +0100 Date: Mon, 11 Aug 2008 07:58:22 +0100 From: Thomas Hurst To: Larry Rosenman Message-ID: <20080811065822.GA81972@voi.aagh.net> Mail-Followup-To: Larry Rosenman , freebsd-stable@FreeBSD.org References: <20080810175934.X2427@borg> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080810175934.X2427@borg> Organization: Not much. User-Agent: Mutt/1.5.18 (2008-05-17) Sender: Thomas Hurst Cc: freebsd-stable@FreeBSD.org Subject: Re: ICRC's X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2008 07:15:39 -0000 * Larry Rosenman (ler@lerctr.org) wrote: > I'm getting the following on a zpool scrub: > > ad8: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=54817587 > ad8: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=187521229 > ad8: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=187522189 > ad8: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=109095258 > ad8: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=101327859 > ad8: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=172911744 > ad8: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=65393370 > ad8: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=64741875 > ad8: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=262496999 > ad8: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=154593293 > > NAME STATE READ WRITE CKSUM > ad8 ONLINE 0 0 17 Having just experienced NTFS corruption in Windows thanks to a slightly kinked SATA cable (hint: *never* chkdsk/fsck/etc until you're sure the cables are fine), I would *love* to know why this causes a checksum error at ZFS level rather than a read error that any filesystem (or indeed RAID layer) will notice. What's the point in having the connection protected by a CRC if it's just going to let bogus data through anyway? -- Thomas 'Freaky' Hurst http://hur.st/ From owner-freebsd-stable@FreeBSD.ORG Mon Aug 11 07:17:06 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 47CF0106564A for ; Mon, 11 Aug 2008 07:17:06 +0000 (UTC) (envelope-from utisoft@googlemail.com) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.29]) by mx1.freebsd.org (Postfix) with ESMTP id F16938FC0C for ; Mon, 11 Aug 2008 07:17:05 +0000 (UTC) (envelope-from utisoft@googlemail.com) Received: by yx-out-2324.google.com with SMTP id 8so557770yxb.13 for ; Mon, 11 Aug 2008 00:17:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:reply-to :to:subject:cc:mime-version:content-type:content-transfer-encoding :content-disposition; bh=4rL8fuqwHq+CpHdHqDQ916v3tokJZjV+iLxBuzIyvis=; b=WGIMsPkZP60H0ngdmUbBTUG4h1c7F98LM5rckPW2cncXhBog0Nw45+XyJOxoHw1zGi CkjE62Ah06zfkzMGGvjoMQ/142PoWvxCN6PWAMU5xajF5vdNQAD+wxL+t1zicr9KVX/c gJd5Id/jOIW7oFQHHRUqO5KI8w45yhVz1rL7o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:reply-to:to:subject:cc:mime-version :content-type:content-transfer-encoding:content-disposition; b=hEd4/4In/ZN0euCx3XTYB7Nz9A+RDjeUwGMjNSvWmc5G4gGDNBiIVZ2lkTk8Fm607K ce56HEVo+N/KIpLk6ODtkqfIBz6LjkKGShQoZgOSiI8fno67vXzwccHQfI9XoL0HOMty EzC/FSoW0sdpq2Wpt+ud68t8kp52wljGge418= Received: by 10.151.108.20 with SMTP id k20mr11703385ybm.150.1218439025382; Mon, 11 Aug 2008 00:17:05 -0700 (PDT) Received: by 10.150.229.11 with HTTP; Mon, 11 Aug 2008 00:17:05 -0700 (PDT) Message-ID: Date: Mon, 11 Aug 2008 08:17:05 +0100 From: "Chris Rees" To: "Warren Liddell" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: freebsd-stable@freebsd.org Subject: Re: Wireless net Card X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: utisoft@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2008 07:17:06 -0000 > Date: Sun, 10 Aug 2008 14:33:54 +1000 > From: Warren Liddell > I downloaded the drivers for the chipset my belkin wireless card has, used > ndisgen to create the kernel module, which all went aok .. however when > trying to load the module it hard hangs the machine to the point of it > restarting itself .. is there something i perhaps mybe missing or am i out in > the cold in not being able to use this wireless card untill some time a > freebsd driver is done ? > Which Belkin wireless card do you have? Which arch are you running (i386/amd64)? I had horrific trouble with a Belkin on the Realtek chipset, played up with Ubuntu, FreeBSD, Fedora, even Windows! Trouble with Belkin is, you never know what you're getting. You need the revision number of the card, and then find out which chipset it is. Make sure the drivers you downloaded are for that exact revision. Hope you have more luck than I did, I tossed mine and bought a Ralink. Chris From owner-freebsd-stable@FreeBSD.ORG Mon Aug 11 08:13:40 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C62F91065680; Mon, 11 Aug 2008 08:13:40 +0000 (UTC) (envelope-from shinjii@maydias.com) Received: from mail11.tpgi.com.au (mail11.tpgi.com.au [203.12.160.161]) by mx1.freebsd.org (Postfix) with ESMTP id 629428FC21; Mon, 11 Aug 2008 08:13:40 +0000 (UTC) (envelope-from shinjii@maydias.com) X-TPG-Antivirus: Passed Received: from [192.168.1.68] (123-243-239-97.static.tpgi.com.au [123.243.239.97]) by mail11.tpgi.com.au (envelope-from shinjii@maydias.com) (8.14.3/8.14.3) with ESMTP id m7B8DaBF005085; Mon, 11 Aug 2008 18:13:38 +1000 From: Warren Liddell To: utisoft@gmail.com Date: Mon, 11 Aug 2008 18:13:41 +1000 User-Agent: KMail/1.9.7 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200808111813.42060.shinjii@maydias.com> Cc: freebsd-stable@freebsd.org, freebsd-questions@freebsd.org Subject: Re: Wireless net Card X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2008 08:13:40 -0000 > Which Belkin wireless card do you have? Which arch are you running > (i386/amd64)? > > I had horrific trouble with a Belkin on the Realtek chipset, played up > with Ubuntu, FreeBSD, Fedora, even Windows! > > Trouble with Belkin is, you never know what you're getting. You need > the revision number of the card, and then find out which chipset it > is. Make sure the drivers you downloaded are for that exact revision. > > Hope you have more luck than I did, I tossed mine and bought a Ralink. > > Chris AMD64 Arch & ironically it worked beautifully for ages in windows, but i got sick of windows having been used to FreeBSD, so i re-installed FreeBSD an using the onboard LAN card atm, but am wanting to goto wireless. none1@pci0:3:5:0: class=0x020000 card=0x700f1799 chip=0x700f1799 rev=0x20 hdr=0x00 vendor = 'Belkin Research and Development Labs' class = network subclass = ethernet Chipset is RT8185L an i used the ndisgen to create the .ko file, which is just over 572kb in size. ironically the 8180 works fine, but naturally wont do my wireless card. From owner-freebsd-stable@FreeBSD.ORG Mon Aug 11 09:00:38 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 56A5A1065683 for ; Mon, 11 Aug 2008 09:00:38 +0000 (UTC) (envelope-from BORJAMAR@SARENET.ES) Received: from proxypop1.sarenet.es (proxypop1.sarenet.es [194.30.0.99]) by mx1.freebsd.org (Postfix) with ESMTP id 48A1C8FC23 for ; Mon, 11 Aug 2008 09:00:37 +0000 (UTC) (envelope-from BORJAMAR@SARENET.ES) Received: from [127.0.0.1] (matahari.sarenet.es [192.148.167.18]) by proxypop1.sarenet.es (Postfix) with ESMTP id 9F34C5D05 for ; Mon, 11 Aug 2008 10:42:36 +0200 (CEST) Message-Id: <43EC06E9-76B3-4AA1-BC5E-4E1BD64AFC2D@SARENET.ES> From: Borja Marcos To: freebsd-stable@freebsd.org Content-Type: multipart/mixed; boundary=Apple-Mail-6--381199578 Mime-Version: 1.0 (Apple Message framework v928.1) Date: Mon, 11 Aug 2008 10:42:48 +0200 X-Mailer: Apple Mail (2.928.1) X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: umtxn and Apache 2.2 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2008 09:00:38 -0000 --Apple-Mail-6--381199578 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hello, I'm running a server with FreeBSD 7-STABLE as of August 8, Apache 2.2 with mpm/worker and threads support, and PHP 5.2.6. Everything works like a charm, but I see that Apache is leaking processes that get stuck in umtxn state. This graph shows it pretty well (I upgraded the system last Friday). Attaching gdb to one of the stray processes and doing a backtrace of the active thread, I see this: [Switching to Thread 0x8705900 (LWP 100647)] 0x382a8789 in _umtx_op () from /lib/libc.so.7 (gdb) bt #0 0x382a8789 in _umtx_op () from /lib/libc.so.7 #1 0x3825fe0d in __error () from /lib/libthr.so.3 #2 0x084b2b80 in ?? () #3 0x00000005 in ?? () #4 0x00000000 in ?? () #5 0x00000000 in ?? () #6 0x00000000 in ?? () #7 0x38261914 in ?? () from /lib/libthr.so.3 #8 0xbe0e5ca8 in ?? () #9 0x3825b818 in pthread_mutex_getprioceiling () from /lib/libthr.so.3 Previous frame identical to this frame (corrupt stack?) (gdb) and it seems all the threads in the process are stuck here. Any ideas? --Apple-Mail-6--381199578 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit --Apple-Mail-6--381199578-- From owner-freebsd-stable@FreeBSD.ORG Mon Aug 11 09:09:05 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 838CC1065673 for ; Mon, 11 Aug 2008 09:09:05 +0000 (UTC) (envelope-from kvs@binarysolutions.dk) Received: from solow.pil.dk (relay.pil.dk [195.41.47.164]) by mx1.freebsd.org (Postfix) with ESMTP id 41BAA8FC13 for ; Mon, 11 Aug 2008 09:09:05 +0000 (UTC) (envelope-from kvs@binarysolutions.dk) Received: from coruscant.binarysolutions.dk (naboo.binarysolutions.dk [80.196.17.173]) by solow.pil.dk (Postfix) with ESMTP id 15DC91CC0F4; Mon, 11 Aug 2008 10:51:45 +0200 (CEST) Received: by coruscant.binarysolutions.dk (Postfix, from userid 501) id A9112EEBD98; Mon, 11 Aug 2008 10:51:44 +0200 (CEST) To: Daryl Richards References: <20080809195935.F4976@borg> <20080809215249.T5563@borg> <20080810082410.X1306@borg> From: Kenneth Vestergaard Schmidt Organization: Binary Solutions Date: Mon, 11 Aug 2008 10:51:44 +0200 In-Reply-To: (Daryl Richards's message of "Sun\, 10 Aug 2008 09\:30\:02 -0400") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2.50 (darwin) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-stable@freebsd.org Subject: Re: IPMI Console: No luck once OS is booted X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2008 09:09:05 -0000 Daryl Richards writes: > I have a Sun Fire X2200. I can access the LOM no problem once Linux or > Solaris is booted. But, once FreeBSD boots, it's no longer accessible > from the NIC. Serial still works fine, it's just access via web or > ssh. Try setting hw.bge.allow_asf=1 in /boot/loader.conf /Kenneth From owner-freebsd-stable@FreeBSD.ORG Mon Aug 11 10:31:17 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5BFC61065673 for ; Mon, 11 Aug 2008 10:31:17 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id D2DBE8FC27; Mon, 11 Aug 2008 10:31:14 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <48A014EF.2090108@FreeBSD.org> Date: Mon, 11 Aug 2008 12:31:11 +0200 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: Borja Marcos References: <43EC06E9-76B3-4AA1-BC5E-4E1BD64AFC2D@SARENET.ES> In-Reply-To: <43EC06E9-76B3-4AA1-BC5E-4E1BD64AFC2D@SARENET.ES> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: umtxn and Apache 2.2 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2008 10:31:17 -0000 Borja Marcos wrote: > Hello, > > I'm running a server with FreeBSD 7-STABLE as of August 8, Apache 2.2 > with mpm/worker and threads support, and PHP 5.2.6. > > Everything works like a charm, but I see that Apache is leaking > processes that get stuck in umtxn state. > > This graph shows it pretty well (I upgraded the system last Friday). > > Attaching gdb to one of the stray processes and doing a backtrace of the > active thread, I see this: > > [Switching to Thread 0x8705900 (LWP 100647)] > 0x382a8789 in _umtx_op () from /lib/libc.so.7 > (gdb) bt > #0 0x382a8789 in _umtx_op () from /lib/libc.so.7 > #1 0x3825fe0d in __error () from /lib/libthr.so.3 > #2 0x084b2b80 in ?? () > #3 0x00000005 in ?? () > #4 0x00000000 in ?? () > #5 0x00000000 in ?? () > #6 0x00000000 in ?? () > #7 0x38261914 in ?? () from /lib/libthr.so.3 > #8 0xbe0e5ca8 in ?? () > #9 0x3825b818 in pthread_mutex_getprioceiling () from /lib/libthr.so.3 > Previous frame identical to this frame (corrupt stack?) > (gdb) > > and it seems all the threads in the process are stuck here. Any ideas? This trace doesn't show anything really. You need to recompile the binaries with debugging symbols as well. Kris From owner-freebsd-stable@FreeBSD.ORG Mon Aug 11 10:35:42 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6FE311065673 for ; Mon, 11 Aug 2008 10:35:42 +0000 (UTC) (envelope-from BORJAMAR@SARENET.ES) Received: from proxypop1.sarenet.es (proxypop1.sarenet.es [194.30.0.99]) by mx1.freebsd.org (Postfix) with ESMTP id 29FEA8FC19 for ; Mon, 11 Aug 2008 10:35:41 +0000 (UTC) (envelope-from BORJAMAR@SARENET.ES) Received: from [127.0.0.1] (matahari.sarenet.es [192.148.167.18]) by proxypop1.sarenet.es (Postfix) with ESMTP id 883395C9C; Mon, 11 Aug 2008 12:35:40 +0200 (CEST) Message-Id: <3A8A19D6-1507-404F-8D3F-6C207BDBDA57@SARENET.ES> From: Borja Marcos To: Kris Kennaway In-Reply-To: <48A014EF.2090108@FreeBSD.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v928.1) Date: Mon, 11 Aug 2008 12:35:52 +0200 References: <43EC06E9-76B3-4AA1-BC5E-4E1BD64AFC2D@SARENET.ES> <48A014EF.2090108@FreeBSD.org> X-Mailer: Apple Mail (2.928.1) Cc: freebsd-stable@freebsd.org Subject: Re: umtxn and Apache 2.2 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2008 10:35:42 -0000 On Aug 11, 2008, at 12:31 PM, Kris Kennaway wrote: > Borja Marcos wrote: >> Hello, >> I'm running a server with FreeBSD 7-STABLE as of August 8, Apache >> 2.2 with mpm/worker and threads support, and PHP 5.2.6. >> This trace doesn't show anything really. You need to recompile the >> binaries with debugging symbols as well. Thanks, sorry. I was just wondering if someone heard of a bug on libthr, that's why first I emailed to this list, perhaps the umtxn ringed a bell. I'll recompile and keep investigating. And yes, I'm using 7-STABLE because I prefer to give a try to SCHED_ULE. It's working like a charm with MySQL and Apache, except for this problem. :) Borja. From owner-freebsd-stable@FreeBSD.ORG Mon Aug 11 10:55:00 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1B5F6106566B for ; Mon, 11 Aug 2008 10:55:00 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.234]) by mx1.freebsd.org (Postfix) with ESMTP id C463F8FC2A for ; Mon, 11 Aug 2008 10:54:59 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: by wr-out-0506.google.com with SMTP id c8so731714wra.27 for ; Mon, 11 Aug 2008 03:54:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=bWIop7+2gjV8ysRHhTj5e4rzx1JYpbmR8+j3gZbDK7Y=; b=Lk0r0iXf/LIHknQLlhj4hqESxpb4pIIuEV4odh0G3Yz7UBioPN83BQUODQhrPbG2RX LCZtuUwVWMiG/mL8qRJVA7gz1/qfufuURO6uYjW69iVb4VQo7i6TdTKh+H7WERf2FBtM p743D27P83WYKa4dgil6gQZOOwbCv7p7ZCJNQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=l15OOGmAwO7eYPa/+rUXBZv5xOJfOkkhQvUAMgluVvGBWnYIQ1Ir62chLttLX+9tly lRR/PmOGThbnmcVHQar++wD9kOwduk+Hmtu7AZOWv2HseoEyMa2ekFidZ1oDPGLONwq4 4WA1ymyfPEcSqaGZCLOyOPTrWY8pIqP6+fMIE= Received: by 10.90.86.10 with SMTP id j10mr10400314agb.77.1218452098936; Mon, 11 Aug 2008 03:54:58 -0700 (PDT) Received: by 10.90.30.10 with HTTP; Mon, 11 Aug 2008 03:54:58 -0700 (PDT) Message-ID: <790a9fff0808110354i446a7ee1n843ab55e1dcf6e1a@mail.gmail.com> Date: Mon, 11 Aug 2008 05:54:58 -0500 From: "Scot Hetzel" To: "Warren Liddell" In-Reply-To: <200808111813.42060.shinjii@maydias.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200808111813.42060.shinjii@maydias.com> Cc: freebsd-stable@freebsd.org Subject: Re: Wireless net Card X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2008 10:55:00 -0000 On 8/11/08, Warren Liddell wrote: > none1@pci0:3:5:0: class=0x020000 card=0x700f1799 chip=0x700f1799 > rev=0x20 hdr=0x00 > vendor = 'Belkin Research and Development Labs' > class = network > subclass = ethernet > > > Chipset is RT8185L an i used the ndisgen to create the .ko file, which is just > over 572kb in size. > Which Belkin Wireless card is this? (Name/Model) Could you provide a link to the driver you downloaded. When you ran ndisgen to create the kernel module, did you specify the 32bit driver or the 64bit driver? You should be using the 64bit driver on FreeBSD/amd64. When you kldloaded the kernel module, did it indicate any required NDIS functions were missing? Scot From owner-freebsd-stable@FreeBSD.ORG Mon Aug 11 11:35:33 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F00E81065671; Mon, 11 Aug 2008 11:35:33 +0000 (UTC) (envelope-from shinjii@maydias.com) Received: from mail13.tpgi.com.au (mail13.tpgi.com.au [203.12.160.181]) by mx1.freebsd.org (Postfix) with ESMTP id 8DF1C8FC1A; Mon, 11 Aug 2008 11:35:33 +0000 (UTC) (envelope-from shinjii@maydias.com) X-TPG-Antivirus: Passed Received: from [192.168.1.65] (123-243-239-97.static.tpgi.com.au [123.243.239.97]) by mail13.tpgi.com.au (envelope-from shinjii@maydias.com) (8.14.3/8.14.3) with ESMTP id m7BBZCkC028488; Mon, 11 Aug 2008 21:35:31 +1000 From: Warren Liddell To: FreeBSD Stable Mailing List User-Agent: KMail/1.9.7 References: <200808051748.55133.shinjii@maydias.com> <200808101433.54554.shinjii@maydias.com> In-Reply-To: MIME-Version: 1.0 Date: Mon, 11 Aug 2008 21:35:14 +1000 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200808112135.14728.shinjii@maydias.com> Cc: freebsd-questions@freebsd.org Subject: Re: Wireless net Card X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2008 11:35:34 -0000 > Please provide more detailed informatio. Card model, at least, or the > output of > > pciconf -lv > > supposing that you have a real card, either internal or PCMCIA. If it > is a USB model, then use > > usbdevs -v none1@pci0:3:5:0: class=0x020000 card=0x700f1799 chip=0x700f1799 rev=0x20 hdr=0x00 vendor = 'Belkin Research and Development Labs' class = network subclass = ethernet Chipset is RT8185L an i used the ndisgen to create the .ko file, which is just over 572kb in size. ironically the 8180 works fine, but naturally wont do my wireless card. From owner-freebsd-stable@FreeBSD.ORG Mon Aug 11 11:42:13 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DC4501065673 for ; Mon, 11 Aug 2008 11:42:13 +0000 (UTC) (envelope-from shinjii@maydias.com) Received: from mail13.tpgi.com.au (mail13.tpgi.com.au [203.12.160.181]) by mx1.freebsd.org (Postfix) with ESMTP id 7869B8FC08 for ; Mon, 11 Aug 2008 11:42:13 +0000 (UTC) (envelope-from shinjii@maydias.com) X-TPG-Antivirus: Passed Received: from [192.168.1.65] (123-243-239-97.static.tpgi.com.au [123.243.239.97]) by mail13.tpgi.com.au (envelope-from shinjii@maydias.com) (8.14.3/8.14.3) with ESMTP id m7BBfm2q004316; Mon, 11 Aug 2008 21:42:12 +1000 From: Warren Liddell To: "Scot Hetzel" Date: Mon, 11 Aug 2008 21:41:50 +1000 User-Agent: KMail/1.9.7 References: <200808111813.42060.shinjii@maydias.com> <790a9fff0808110354i446a7ee1n843ab55e1dcf6e1a@mail.gmail.com> In-Reply-To: <790a9fff0808110354i446a7ee1n843ab55e1dcf6e1a@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200808112141.50313.shinjii@maydias.com> Cc: freebsd-stable@freebsd.org Subject: Re: Wireless net Card X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2008 11:42:13 -0000 > > Chipset is RT8185L an i used the ndisgen to create the .ko file, which > > is just over 572kb in size. > > Which Belkin Wireless card is this? (Name/Model) No idea what name//Model .. all i know is its Belkin and on the card itself it has RT8185L on the sticker. I dont have any of the original box etc as it was tossed quite some time ago ironically. > > Could you provide a link to the driver you downloaded. The driver i downloaded was directly from the realtek website and it was the 64bit version. below is the link to the site that has the file i d/l http://www.realtek.com.tw/downloads/downloadsView.aspx?Langid=1&PNid=1&PFid=1&Level=6&Conn=5&DownTypeID=3&GetDown=false&Downloads=true#RTL8185L > When you ran ndisgen to create the kernel module, did you specify the > 32bit driver or the 64bit driver? You should be using the 64bit > driver on FreeBSD/amd64. Only downloaded the 64bit version > > When you kldloaded the kernel module, did it indicate any required > NDIS functions were missing? When i did the kldload i instantly lost all functionality of the computer system untill it rebooted itself. From owner-freebsd-stable@FreeBSD.ORG Mon Aug 11 13:03:34 2008 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2C65B1065681 for ; Mon, 11 Aug 2008 13:03:34 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from constantine.ticketswitch.com (constantine.ticketswitch.com [IPv6:2002:57e0:1d4e:1::3]) by mx1.freebsd.org (Postfix) with ESMTP id E31288FC38 for ; Mon, 11 Aug 2008 13:03:33 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from dilbert.rattatosk ([10.64.50.6] helo=dilbert.ticketswitch.com) by constantine.ticketswitch.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KSX3b-0002Kc-IP; Mon, 11 Aug 2008 14:03:31 +0100 Received: from petefrench by dilbert.ticketswitch.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KSX3b-0004H8-H2; Mon, 11 Aug 2008 14:03:31 +0100 To: pyunyh@gmail.com In-Reply-To: <20080808101831.GD38118@cdnetworks.co.kr> Message-Id: From: Pete French Date: Mon, 11 Aug 2008 14:03:31 +0100 Cc: stable@freebsd.org Subject: Re: should looking at an interface with 'ifconfig' trigger a change ? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2008 13:03:34 -0000 Pyun YongHyeon wrote: > Try attached patch and check whether bce(4) correctly reports link > state changes. > > After seeing 'link state changed to UP' message, unplug the cable > and see whether it reports link DOWN. The message should be printed > in a second. Also try replugging cable and you should see link UP > message within several seconds. Since auto-negotation takes more > time you may have to wait for a while. I do not have phsyical access to the machine, so I did this using a sutdown of the interface on the sitch - but yes, it works! This fixes the progem with lagg as well - it now fails over to the other interface properly. Such a simple patch - if this has no ill effects then I will deploy it on al our servers,m and hope for it to be committed soon. All new HP servers appear to come with bce interfaces, so this is an importnat fix for us, and probably a lot of other people too. Thanks. -pete. From owner-freebsd-stable@FreeBSD.ORG Mon Aug 11 13:05:55 2008 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 86A00106566B for ; Mon, 11 Aug 2008 13:05:55 +0000 (UTC) (envelope-from jdc@parodius.com) Received: from mx01.sc1.parodius.com (mx01.sc1.parodius.com [72.20.106.3]) by mx1.freebsd.org (Postfix) with ESMTP id 76AB28FC15 for ; Mon, 11 Aug 2008 13:05:55 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id 6EF361CC0BC; Mon, 11 Aug 2008 06:05:55 -0700 (PDT) Date: Mon, 11 Aug 2008 06:05:55 -0700 From: Jeremy Chadwick To: freebsd-stable@FreeBSD.org Message-ID: <20080811130555.GA25024@eos.sc1.parodius.com> References: <20080810175934.X2427@borg> <20080811065822.GA81972@voi.aagh.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080811065822.GA81972@voi.aagh.net> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Subject: Re: ICRC's X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2008 13:05:55 -0000 On Mon, Aug 11, 2008 at 07:58:22AM +0100, Thomas Hurst wrote: > * Larry Rosenman (ler@lerctr.org) wrote: > > > I'm getting the following on a zpool scrub: > > > > ad8: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=54817587 > > ad8: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=187521229 > > ad8: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=187522189 > > ad8: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=109095258 > > ad8: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=101327859 > > ad8: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=172911744 > > ad8: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=65393370 > > ad8: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=64741875 > > ad8: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=262496999 > > ad8: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=154593293 > > > > NAME STATE READ WRITE CKSUM > > ad8 ONLINE 0 0 17 > > Having just experienced NTFS corruption in Windows thanks to a slightly > kinked SATA cable (hint: *never* chkdsk/fsck/etc until you're sure the > cables are fine), I would *love* to know why this causes a checksum > error at ZFS level rather than a read error that any filesystem (or > indeed RAID layer) will notice. The ad8 errors you're quoting come from the ATA subsystem in FreeBSD. That is lower-level (e.g. closer to the hardware) than ZFS's checksum method is. If Larry was using UFS, he'd also see the above errors from the kernel. FreeBSD reports the CRC errors reported by the ATA device, ZFS reports the said data as corrupted during scrubbing or standard usage (hence the CKSUM field in 'zpool status'), and ZFS also *repairs* the corrupted data. I can't explain how the repair works, but it's one of the many features of the filesystem. I believe journalling filesystems (e.g. ext3fs and gjournal) have this ability, while Standard UFS, UFS2, NTFS, FAT, and many others do not. > What's the point in having the connection protected by a CRC if it's > just going to let bogus data through anyway? A CRC (or checksum) acts as a method of differential detection, e.g. detect corruption between X and Y. CRCs are not the same thing as error correction or retransmittal; they only result in reporting data corruption, and cannot repair it. http://en.wikipedia.org/wiki/Cyclic_redundancy_check -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Mon Aug 11 13:41:06 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 07CE41065671 for ; Mon, 11 Aug 2008 13:41:06 +0000 (UTC) (envelope-from josh@tcbug.org) Received: from cenn-smtp.mc.mpls.visi.com (cenn.mc.mpls.visi.com [208.42.156.9]) by mx1.freebsd.org (Postfix) with ESMTP id CB5A28FC13 for ; Mon, 11 Aug 2008 13:41:05 +0000 (UTC) (envelope-from josh@tcbug.org) Received: from mail.tcbug.org (mail.tcbug.org [208.42.70.163]) by cenn-smtp.mc.mpls.visi.com (Postfix) with ESMTP id CDEA883CE; Mon, 11 Aug 2008 08:20:59 -0500 (CDT) Received: from build64.tcbug.org (unknown [208.42.70.167]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.tcbug.org (Postfix) with ESMTPS id A515055880F; Mon, 11 Aug 2008 08:20:59 -0500 (CDT) From: Josh Paetzel To: freebsd-stable@freebsd.org Date: Mon, 11 Aug 2008 08:19:46 +0000 User-Agent: KMail/1.9.7 References: <489C4129.4090303@vervier.info> <489C88DB.6030000@vervier.info> <2a41acea0808081131m1eddc4caib0963c8a5443afd2@mail.gmail.com> In-Reply-To: <2a41acea0808081131m1eddc4caib0963c8a5443afd2@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart6253508.J8SpS2Yqi1"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200808110819.53914.josh@tcbug.org> Cc: Markus Vervier , Jack Vogel Subject: Re: em(4) on FreeBSD is sometimes annoying X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2008 13:41:06 -0000 --nextPart6253508.J8SpS2Yqi1 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Friday 08 August 2008 06:31:24 pm Jack Vogel wrote: > OK, I just got access to a machine, am going to install and see if I > can repro this > this afternoon. > > Jack =46or what it's worth, I have a T60 that dual boots 6.3-R/amd64 and 7.0-R/i= 386=20 and neither install has this problem. I can cold boot it with the NIC=20 unplugged, plug in a cable, I get a link light and ifconfig em0 goes to=20 active, dhclient em0 gets an IP successfully. =2D-=20 Thanks, Josh Paetzel PGP: 8A48 EF36 5E9F 4EDA 5A8C 11B4 26F9 01F1 27AF AECB --nextPart6253508.J8SpS2Yqi1 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEABECAAYFAkif9ikACgkQJvkB8Sevrss4mwCfW7JP8sbA6rjUUz9/yAj0MaV8 a/gAn2Qdn5nAkzmgSQEjY40ZV/658/hw =eFxk -----END PGP SIGNATURE----- --nextPart6253508.J8SpS2Yqi1-- From owner-freebsd-stable@FreeBSD.ORG Mon Aug 11 14:02:50 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1D8DF1065679 for ; Mon, 11 Aug 2008 14:02:50 +0000 (UTC) (envelope-from jdc@parodius.com) Received: from mx01.sc1.parodius.com (mx01.sc1.parodius.com [72.20.106.3]) by mx1.freebsd.org (Postfix) with ESMTP id 0AB388FC08 for ; Mon, 11 Aug 2008 14:02:49 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id C96F71CC0C0; Mon, 11 Aug 2008 07:02:49 -0700 (PDT) Date: Mon, 11 Aug 2008 07:02:49 -0700 From: Jeremy Chadwick To: Josh Paetzel Message-ID: <20080811140249.GA27379@eos.sc1.parodius.com> References: <489C4129.4090303@vervier.info> <489C88DB.6030000@vervier.info> <2a41acea0808081131m1eddc4caib0963c8a5443afd2@mail.gmail.com> <200808110819.53914.josh@tcbug.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200808110819.53914.josh@tcbug.org> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Markus Vervier , freebsd-stable@freebsd.org, Jack Vogel Subject: Re: em(4) on FreeBSD is sometimes annoying X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2008 14:02:50 -0000 On Mon, Aug 11, 2008 at 08:19:46AM +0000, Josh Paetzel wrote: > On Friday 08 August 2008 06:31:24 pm Jack Vogel wrote: > > OK, I just got access to a machine, am going to install and see if I > > can repro this > > this afternoon. > > > > Jack > > For what it's worth, I have a T60 that dual boots 6.3-R/amd64 and 7.0-R/i386 > and neither install has this problem. I can cold boot it with the NIC > unplugged, plug in a cable, I get a link light and ifconfig em0 goes to > active, dhclient em0 gets an IP successfully. As promised, I tested said issue out on my T60p (widescreen) tonight, using both FreeBSD 7.0-STABLE and 7.0-RELEASE. I wasn't able to reproduce the issue; so my experience was the same as Josh. I can also boot it with the CAT5 inserted, dhclient fetch an IP, no LED oddities -- then yank the cable (LED and link light go off), re-insert the cable, and within a moment or so dhclient again gets an IP. I'm left wondering if maybe there's an EEPROM setting that's doing this (purely speculative on my part), or possibly some odd BIOS quirk. My T60p (widescreen) is running BIOS 1.14. It's worth noting that the non-widescreen T60p uses a different BIOS. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Mon Aug 11 15:44:02 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8A1BF1065679 for ; Mon, 11 Aug 2008 15:44:02 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 2AF578FC31 for ; Mon, 11 Aug 2008 15:44:02 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [IPv6:::1]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m7BFhtSH064616; Mon, 11 Aug 2008 11:43:55 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: Ulrich Spoerlein Date: Mon, 11 Aug 2008 11:28:50 -0400 User-Agent: KMail/1.9.7 References: <20080730113449.GD407@cdnetworks.co.kr> <200808061811.28200.jhb@freebsd.org> <20080809111637.GA1798@roadrunner.spoerlein.net> In-Reply-To: <20080809111637.GA1798@roadrunner.spoerlein.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200808111128.50840.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Mon, 11 Aug 2008 11:43:55 -0400 (EDT) X-Virus-Scanned: ClamAV 0.93.1/8007/Mon Aug 11 09:51:54 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: freebsd-stable@freebsd.org Subject: Re: cpufreq(4) panic on RELENG_7 (was: Re: Call for bfe(4) testers.) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2008 15:44:02 -0000 On Saturday 09 August 2008 07:16:37 am Ulrich Spoerlein wrote: > Hi John, > > I now figured out the "who", the "why" still eludes me. > > So, after your MFC of ichss.c on June 27th the device now attaches at my > laptop. It didn't before, so it could cause no trouble. > > With ichss loaded, the kernel will panic 1-3 minutes after powerd has > been started (if I kill powerd early enough, it seems pretty stable). > > I'm now running a kernel from 2008-08-08 with > hint.ichss.0.disabled="1" Ok. Can you get a crashdump from a crash? -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Mon Aug 11 15:44:08 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E7FA9106566C for ; Mon, 11 Aug 2008 15:44:08 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 882A48FC1B for ; Mon, 11 Aug 2008 15:44:08 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [IPv6:::1]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m7BFhtSI064616; Mon, 11 Aug 2008 11:44:02 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: Eugene Grosbein Date: Mon, 11 Aug 2008 11:31:33 -0400 User-Agent: KMail/1.9.7 References: <20080627031233.9DC4945047@ptavv.es.net> <200808091717.31780.jhb@freebsd.org> <20080810062726.GA3979@svzserv.kemerovo.su> In-Reply-To: <20080810062726.GA3979@svzserv.kemerovo.su> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200808111131.33371.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Mon, 11 Aug 2008 11:44:02 -0400 (EDT) X-Virus-Scanned: ClamAV 0.93.1/8007/Mon Aug 11 09:51:54 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: freebsd-stable@freebsd.org Subject: Re: Problem with /boot/loader [A new patch] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2008 15:44:09 -0000 On Sunday 10 August 2008 02:27:26 am Eugene Grosbein wrote: > On Sat, Aug 09, 2008 at 05:17:31PM -0400, John Baldwin wrote: > > > In addition to my earlier message, it would probably be good to narrow down > > what breaks the loader for you. For example, does it work ok over serial and > > only break on vidconsole? Also, if you just backout sys/boot/i386/btx to > > 7.0-release and leave the rest of the sys/boot tree at 7.0-stable, do you get > > a working loader? > > I've just rolled sys/boot/i386/btx back to RELENG_7_0_0_RELEASE > leaving rest of src at 7.0-STABLE (plus your patch) and yes, I've got > working loader! Err, my patch should have failed (well, the btx.S part) if you had a 7.0-RELEASE sys/boot/i386/btx. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Mon Aug 11 16:28:02 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5EEA81065675 for ; Mon, 11 Aug 2008 16:28:02 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.238]) by mx1.freebsd.org (Postfix) with ESMTP id 133EA8FC12 for ; Mon, 11 Aug 2008 16:28:01 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by wr-out-0506.google.com with SMTP id c8so792790wra.27 for ; Mon, 11 Aug 2008 09:28:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=oqBFVm89W9mkSiMXpDAvbTAol1XI0pQYwavTYfeXLZw=; b=jEXrbr/XXaJnMV5rSTqpFcQ+FL7QiPdVM6+u2C0IhlrRLrs4CYT8IbBGxF/v9BjwwK 2PQYAIdwyvSk1DyGf8+eYnaZPs9VvLjQiq9gsdcFjt2I/wbtoDM4++qWKEgQAa2Uoeib 0snniB25y6uQbwXm+Op0Cd/G4Evhb5LRtVuGo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=vy93AVxx7Fus2K7+s9Rc0dXkNkb/bTzFO0mveRqBdnxAxAHAMK6Q4pVDADRGWqLuH8 ggLkDS1T9nApq4fzbV/jKfpadEzYF2aylDqr7NoaS5cbctz3Q2r1c2foF4H7Nty3ti10 QHJ2EWG+FdRP6z9qD1IYOvTebNJBlCmlQ2UJQ= Received: by 10.90.91.2 with SMTP id o2mr10799778agb.111.1218472081379; Mon, 11 Aug 2008 09:28:01 -0700 (PDT) Received: by 10.100.43.1 with HTTP; Mon, 11 Aug 2008 09:28:01 -0700 (PDT) Message-ID: <2a41acea0808110928h10d54441o7d49b11a60406934@mail.gmail.com> Date: Mon, 11 Aug 2008 09:28:01 -0700 From: "Jack Vogel" To: "Jeremy Chadwick" In-Reply-To: <20080811140249.GA27379@eos.sc1.parodius.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <489C4129.4090303@vervier.info> <489C88DB.6030000@vervier.info> <2a41acea0808081131m1eddc4caib0963c8a5443afd2@mail.gmail.com> <200808110819.53914.josh@tcbug.org> <20080811140249.GA27379@eos.sc1.parodius.com> Cc: Josh Paetzel , Markus Vervier , freebsd-stable@freebsd.org Subject: Re: em(4) on FreeBSD is sometimes annoying X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2008 16:28:02 -0000 On Mon, Aug 11, 2008 at 7:02 AM, Jeremy Chadwick wrote: > On Mon, Aug 11, 2008 at 08:19:46AM +0000, Josh Paetzel wrote: >> On Friday 08 August 2008 06:31:24 pm Jack Vogel wrote: >> > OK, I just got access to a machine, am going to install and see if I >> > can repro this >> > this afternoon. >> > >> > Jack >> >> For what it's worth, I have a T60 that dual boots 6.3-R/amd64 and 7.0-R/i386 >> and neither install has this problem. I can cold boot it with the NIC >> unplugged, plug in a cable, I get a link light and ifconfig em0 goes to >> active, dhclient em0 gets an IP successfully. > > As promised, I tested said issue out on my T60p (widescreen) tonight, > using both FreeBSD 7.0-STABLE and 7.0-RELEASE. > > I wasn't able to reproduce the issue; so my experience was the same as > Josh. I can also boot it with the CAT5 inserted, dhclient fetch an IP, > no LED oddities -- then yank the cable (LED and link light go off), > re-insert the cable, and within a moment or so dhclient again gets an > IP. > > I'm left wondering if maybe there's an EEPROM setting that's doing this > (purely speculative on my part), or possibly some odd BIOS quirk. My > T60p (widescreen) is running BIOS 1.14. It's worth noting that the > non-widescreen T60p uses a different BIOS. Cool, it turned out that the laptop I was told I could use was an X61 and it had an ICH8 NIC rather than 82573 anyway, they were supposed to get me one today but given the two of you have already gone thru this verification I see little point in doing the same. Seems possibly a BIOS thing, if not that bad cable, bad link partner maybe?? Jack From owner-freebsd-stable@FreeBSD.ORG Mon Aug 11 16:35:18 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AA8FB1065671 for ; Mon, 11 Aug 2008 16:35:18 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.225]) by mx1.freebsd.org (Postfix) with ESMTP id 5F3638FC14 for ; Mon, 11 Aug 2008 16:35:18 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: by wr-out-0506.google.com with SMTP id c8so794309wra.27 for ; Mon, 11 Aug 2008 09:35:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=4k849YpGcm9q3Taywwaz6uO4OcUovcmGhy/2ADdxav4=; b=jTzH99sG5WJhcG8Xt9eWO7IDA1Q/UXXoAZE3KNc/uPJpQF6qexISaxB+ZIsOBFAtgB 5Lm4AKW1X7qonAXoXim3n/Yr2MGlQ9O4SUfiyOnhOZyUNIcUaiYoHh337w5Pyk9Whf0b vk2djgSLg0Hp0G8naF/gShJ+BTDFX/Hfq0nUY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=DG9emPENHaUgWmWlkU0kv5rmj207l5WaD7J6jnWj5h0/+MoH2DTgHpBkDTxDskkqHJ hKBWwZ+OlWp/imNV5rI5xoVagcHgOVpRsHvyBu8uYVgkoeG9Ep2In0B6nBNLGqKGutl3 icNA6IHIe3x3XEuvMCbNqp4xXETsYgMYmt1jk= Received: by 10.90.49.8 with SMTP id w8mr5476573agw.104.1218472517330; Mon, 11 Aug 2008 09:35:17 -0700 (PDT) Received: by 10.90.81.10 with HTTP; Mon, 11 Aug 2008 09:35:17 -0700 (PDT) Message-ID: Date: Mon, 11 Aug 2008 20:35:17 +0400 From: pluknet To: "John Baldwin" In-Reply-To: <200808111128.50840.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: base64 Content-Disposition: inline References: <20080730113449.GD407@cdnetworks.co.kr> <200808061811.28200.jhb@freebsd.org> <20080809111637.GA1798@roadrunner.spoerlein.net> <200808111128.50840.jhb@freebsd.org> Cc: freebsd-stable@freebsd.org, Ulrich Spoerlein Subject: Re: cpufreq(4) panic on RELENG_7 (was: Re: Call for bfe(4) testers.) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2008 16:35:18 -0000 MjAwOC84LzExIEpvaG4gQmFsZHdpbiA8amhiQGZyZWVic2Qub3JnPjoKPiBPbiBTYXR1cmRheSAw OSBBdWd1c3QgMjAwOCAwNzoxNjozNyBhbSBVbHJpY2ggU3BvZXJsZWluIHdyb3RlOgo+PiBIaSBK b2huLAo+Pgo+PiBJIG5vdyBmaWd1cmVkIG91dCB0aGUgIndobyIsIHRoZSAid2h5IiBzdGlsbCBl bHVkZXMgbWUuCj4+Cj4+IFNvLCBhZnRlciB5b3VyIE1GQyBvZiBpY2hzcy5jIG9uIEp1bmUgMjd0 aCB0aGUgZGV2aWNlIG5vdyBhdHRhY2hlcyBhdCBteQo+PiBsYXB0b3AuIEl0IGRpZG4ndCBiZWZv cmUsIHNvIGl0IGNvdWxkIGNhdXNlIG5vIHRyb3VibGUuCj4+Cj4+IFdpdGggaWNoc3MgbG9hZGVk LCB0aGUga2VybmVsIHdpbGwgcGFuaWMgMS0zIG1pbnV0ZXMgYWZ0ZXIgcG93ZXJkIGhhcwo+PiBi ZWVuIHN0YXJ0ZWQgKGlmIEkga2lsbCBwb3dlcmQgZWFybHkgZW5vdWdoLCBpdCBzZWVtcyBwcmV0 dHkgc3RhYmxlKS4KPj4KPj4gSSdtIG5vdyBydW5uaW5nIGEga2VybmVsIGZyb20gMjAwOC0wOC0w OCB3aXRoCj4+IGhpbnQuaWNoc3MuMC5kaXNhYmxlZD0iMSIKPgo+IE9rLiAgQ2FuIHlvdSBnZXQg YSBjcmFzaGR1bXAgZnJvbSBhIGNyYXNoPwo+CgplaG0sLiBJIGFtIG5vdCBVbHJpY2ggU3BvZXJs ZWluLCBidXQgSSBjYW4gaGVscCB3aXRoIHRoaXMgaXNzdWUuCgpteSBjcmFzaGR1bXAgZnJvbSBr Z2RiIGFuZCBzb21lIGRlYnVnIGluZm8uCihvdWNoLCBJIGZvcmdvdCB0byBpbmNsdWRlIGl0IGlu IG15IHByZXYuIG1haWwKaHR0cDovL2xpc3RzLmZyZWVic2Qub3JnL3BpcGVybWFpbC9mcmVlYnNk LXN0YWJsZS8yMDA4LUF1Z3VzdC8wNDQxODIuaHRtbCApCgp3YnIsCnBsdWtuZXQKClVucmVhZCBw b3J0aW9uIG9mIHRoZSBrZXJuZWwgbWVzc2FnZSBidWZmZXI6CgoKRmF0YWwgdHJhcCAxMjogcGFn ZSBmYXVsdCB3aGlsZSBpbiBrZXJuZWwgbW9kZQpmYXVsdCB2aXJ0dWFsIGFkZHJlc3MgICA9IDB4 MzgKZmF1bHQgY29kZSAgICAgICAgICAgICAgPSBzdXBlcnZpc29yIHJlYWQsIHBhZ2Ugbm90IHBy ZXNlbnQKaW5zdHJ1Y3Rpb24gcG9pbnRlciAgICAgPSAweDIwOjB4YzA1NmNmNDYKc3RhY2sgcG9p bnRlciAgICAgICAgICAgPSAweDI4OjB4ZTY1OTJhYzgKZnJhbWUgcG9pbnRlciAgICAgICAgICAg PSAweDI4OjB4ZTY1OTJhYzgKY29kZSBzZWdtZW50ICAgICAgICAgICAgPSBiYXNlIDB4MCwgbGlt aXQgMHhmZmZmZiwgdHlwZSAweDFiCiAgICAgICAgICAgICAgICAgICAgICAgID0gRFBMIDAsIHBy ZXMgMSwgZGVmMzIgMSwgZ3JhbiAxCnByb2Nlc3NvciBlZmxhZ3MgICAgICAgID0gaW50ZXJydXB0 IGVuYWJsZWQsIHJlc3VtZSwgSU9QTCA9IDAKY3VycmVudCBwcm9jZXNzICAgICAgICAgPSAyNTA3 IChwb3dlcmQpClBoeXNpY2FsIG1lbW9yeTogMTAxNCBNQgpEdW1waW5nIDEyMCBNQjogMTA1IDg5 IDczIDU3IDQxIDI1IDkKCiMwICBkb2FkdW1wICgpIGF0IHBjcHUuaDoxOTUKMTk1ICAgICBwY3B1 Lmg6IE5vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnkuCiAgICAgICAgaW4gcGNwdS5oCihrZ2RiKSBi dAojMCAgZG9hZHVtcCAoKSBhdCBwY3B1Lmg6MTk1CiMxICAweGMwNDU4Zjg5IGluIGRiX2ZuY2Fs bCAoZHVtbXkxPS0xMDEwMDI3NjQ4LCBkdW1teTI9MCwgZHVtbXkzPTAsCiAgICBkdW1teTQ9MHhl NjU5Mjg2MCAiMKzKwyIpIGF0IC9tZWRpYS9zcmMtNy9zeXMvZGRiL2RiX2NvbW1hbmQuYzo1MTYK IzIgIDB4YzA0NTk1M2EgaW4gZGJfY29tbWFuZCAobGFzdF9jbWRwPTB4YzA3ZGNmMTQsIGNtZF90 YWJsZT0weDAsIGRvcGFnZXI9MSkKICAgIGF0IC9tZWRpYS9zcmMtNy9zeXMvZGRiL2RiX2NvbW1h bmQuYzo0MTMKIzMgIDB4YzA0NTk2NTUgaW4gZGJfY29tbWFuZF9sb29wICgpIGF0IC9tZWRpYS9z cmMtNy9zeXMvZGRiL2RiX2NvbW1hbmQuYzo0NjYKIzQgIDB4YzA0NWIxN2MgaW4gZGJfdHJhcCAo dHlwZT0xMiwgY29kZT0wKQogICAgYXQgL21lZGlhL3NyYy03L3N5cy9kZGIvZGJfbWFpbi5jOjIy OAojNSAgMHhjMDU3NTAyMyBpbiBrZGJfdHJhcCAodHlwZT0xMiwgY29kZT0wLCB0Zj0weGU2NTky YTg4KQogICAgYXQgL21lZGlhL3NyYy03L3N5cy9rZXJuL3N1YnJfa2RiLmM6NTI0CiM2ICAweGMw NzQ2MGJmIGluIHRyYXBfZmF0YWwgKGZyYW1lPTB4ZTY1OTJhODgsIGV2YT01NikKICAgIGF0IC9t ZWRpYS9zcmMtNy9zeXMvaTM4Ni9pMzg2L3RyYXAuYzo4OTAKIzcgIDB4YzA3NDYzNmIgaW4gdHJh cF9wZmF1bHQgKGZyYW1lPTB4ZTY1OTJhODgsIHVzZXJtb2RlPTAsIGV2YT01NikKICAgIGF0IC9t ZWRpYS9zcmMtNy9zeXMvaTM4Ni9pMzg2L3RyYXAuYzo4MTIKIzggIDB4YzA3NDZkMzYgaW4gdHJh cCAoZnJhbWU9MHhlNjU5MmE4OCkKICAgIGF0IC9tZWRpYS9zcmMtNy9zeXMvaTM4Ni9pMzg2L3Ry YXAuYzo0OTAKIzkgIDB4YzA3MmZkNGIgaW4gY2FsbHRyYXAgKCkgYXQgL21lZGlhL3NyYy03L3N5 cy9pMzg2L2kzODYvZXhjZXB0aW9uLnM6MTM5CiMxMCAweGMwNTZjZjQ2IGluIGRldmljZV9pc19h dHRhY2hlZCAoZGV2PTB4MCkKICAgIGF0IC9tZWRpYS9zcmMtNy9zeXMva2Vybi9zdWJyX2J1cy5j OjIyMjgKIzExIDB4YzA1MTJkZTcgaW4gY2Zfc2V0X21ldGhvZCAoZGV2PTB4YzNjOWM4ODAsIGxl dmVsPTB4YzQ1MjVlZjQsCiAgICBwcmlvcml0eT0xMDApIGF0IC9tZWRpYS9zcmMtNy9zeXMva2Vy bi9rZXJuX2NwdS5jOjMzMgojMTIgMHhjMDUxMTQ1MiBpbiBjcHVmcmVxX2N1cnJfc3lzY3RsIChv aWRwPTB4YzNjOGJhYzAsIGFyZzE9MHhjM2JjN2MwMCwKICAgIGFyZzI9MCwgcmVxPTB4ZTY1OTJi YTQpIGF0IGNwdWZyZXFfaWYuaDozMgotLS1UeXBlIDxyZXR1cm4+IHRvIGNvbnRpbnVlLCBvciBx IDxyZXR1cm4+IHRvIHF1aXQtLS0KIzEzIDB4YzA1NTRiNjcgaW4gc3lzY3RsX3Jvb3QgKG9pZHA9 VmFyaWFibGUgIm9pZHAiIGlzIG5vdCBhdmFpbGFibGUuCikKICAgIGF0IC9tZWRpYS9zcmMtNy9z eXMva2Vybi9rZXJuX3N5c2N0bC5jOjEzMDYKIzE0IDB4YzA1NTRjZDEgaW4gdXNlcmxhbmRfc3lz Y3RsICh0ZD0weGM0MjQ1NDQwLCBuYW1lPTB4ZTY1OTJjMTQsIG5hbWVsZW49NCwKICAgIG9sZD0w eDAsIG9sZGxlbnA9MHgwLCBpbmtlcm5lbD0wLCBuZXc9MHhiZmJmZTdjNCwgbmV3bGVuPTQsCiAg ICByZXR2YWw9MHhlNjU5MmMxMCwgZmxhZ3M9MCkgYXQgL21lZGlhL3NyYy03L3N5cy9rZXJuL2tl cm5fc3lzY3RsLmM6MTQwMQojMTUgMHhjMDU1NWE3YyBpbiBfX3N5c2N0bCAodGQ9MHhjNDI0NTQ0 MCwgdWFwPTB4ZTY1OTJjZmMpCiAgICBhdCAvbWVkaWEvc3JjLTcvc3lzL2tlcm4va2Vybl9zeXNj dGwuYzoxMzM2CiMxNiAweGMwNzQ2NmQ1IGluIHN5c2NhbGwgKGZyYW1lPTB4ZTY1OTJkMzgpCiAg ICBhdCAvbWVkaWEvc3JjLTcvc3lzL2kzODYvaTM4Ni90cmFwLmM6MTAzNQojMTcgMHhjMDcyZmRi MCBpbiBYaW50MHg4MF9zeXNjYWxsICgpCiAgICBhdCAvbWVkaWEvc3JjLTcvc3lzL2kzODYvaTM4 Ni9leGNlcHRpb24uczoxOTYKIzE4IDB4MDAwMDAwMzMgaW4gPz8gKCkKUHJldmlvdXMgZnJhbWUg aW5uZXIgdG8gdGhpcyBmcmFtZSAoY29ycnVwdCBzdGFjaz8pCihrZ2RiKSBmIDExCiMxMSAweGMw NTEyZGU3IGluIGNmX3NldF9tZXRob2QgKGRldj0weGMzYzljODgwLCBsZXZlbD0weGM0NTI1ZWY0 LAogICAgcHJpb3JpdHk9MTAwKSBhdCAvbWVkaWEvc3JjLTcvc3lzL2tlcm4va2Vybl9jcHUuYzoz MzIKMzMyICAgICAgICAgICAgICAgICAgICAgaWYgKCFkZXZpY2VfaXNfYXR0YWNoZWQoc2V0LT5k ZXYpKSB7CihrZ2RiKSBsaXN0CjMyNyAgICAgICAgICAgICB9CjMyOAozMjkgICAgICAgICAgICAg LyogTmV4dCwgc2V0IGFueS9hbGwgcmVsYXRpdmUgZnJlcXVlbmNpZXMgdmlhIHRoZWlyIGRyaXZl cnMuICovCjMzMCAgICAgICAgICAgICBmb3IgKGkgPSAwOyBpIDwgbGV2ZWwtPnJlbF9jb3VudDsg aSsrKSB7CjMzMSAgICAgICAgICAgICAgICAgICAgIHNldCA9ICZsZXZlbC0+cmVsX3NldFtpXTsK MzMyICAgICAgICAgICAgICAgICAgICAgaWYgKCFkZXZpY2VfaXNfYXR0YWNoZWQoc2V0LT5kZXYp KSB7CjMzMyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZXJyb3IgPSBFTlhJTzsKMzM0ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBnb3RvIG91dDsKMzM1ICAgICAgICAgICAgICAgICAg ICAgfQozMzYKKGtnZGIpIHAgbGV2ZWwucmVsX2NvdW50CiQxID0gMTk4NjM1NjI3MQooa2dkYikg cCBpCiQyID0gMAooa2dkYikgcCBsZXZlbC5yZWxfc2V0CiQzID0ge3tmcmVxID0gMCwgdm9sdHMg PSAwLCBwb3dlciA9IDAsIGxhdCA9IDAsIGRldiA9IDB4MCwgc3BlYyA9IHswLCAwLCAwLAogICAg ICAwfX0sIHtmcmVxID0gMCwgdm9sdHMgPSAwLCBwb3dlciA9IDAsIGxhdCA9IDAsIGRldiA9IDB4 MCwgc3BlYyA9IHswLCAwLAogICAgICAwLCAwfX0sIHtmcmVxID0gMCwgdm9sdHMgPSAwLCBwb3dl ciA9IDAsIGxhdCA9IDAsIGRldiA9IDB4MCwgc3BlYyA9IHswLAogICAgICAwLCAwLCAwfX0sIHtm cmVxID0gMCwgdm9sdHMgPSAwLCBwb3dlciA9IDAsIGxhdCA9IDAsIGRldiA9IDB4MCwgc3BlYyA9 IHsKICAgICAgMCwgMCwgMCwgMH19LCB7ZnJlcSA9IDAsIHZvbHRzID0gMCwgcG93ZXIgPSAwLCBs YXQgPSAwLCBkZXYgPSAweDAsCiAgICBzcGVjID0gezAsIDAsIDAsIDB9fSwge2ZyZXEgPSAwLCB2 b2x0cyA9IDAsIHBvd2VyID0gMCwgbGF0ID0gMCwKICAgIGRldiA9IDB4NjU2ZTc1NTIsIHNwZWMg PSB7ODI4ODU4NzAxLCAxMTYyNzYwMDE0LCAwLCAxMzQ2MzI0OTJ9fSwgewogICAgZnJlcSA9IDAs IHZvbHRzID0gNTMsIHBvd2VyID0gLTEwMjQsIGxhdCA9IC0xLCBkZXYgPSAweDdmZmZmZmZmLCBz cGVjID0gewotLS0tLSBhbmQgc28gb24tLS0tLQoKQWxzbyB0aGVyZSBhcmUgdmVyeSB1bnVzdWFs IChhbmQgaGlnaCkgbnVtYmVycyBpbiBzeXNjdGwgZGV2LmNwdS4wLmZyZXFfbGV2ZWxzLgo= From owner-freebsd-stable@FreeBSD.ORG Mon Aug 11 17:06:28 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C62DA1065670; Mon, 11 Aug 2008 17:06:28 +0000 (UTC) (envelope-from eugen@kuzbass.ru) Received: from www.svzserv.kemerovo.su (www.svzserv.kemerovo.su [213.184.65.80]) by mx1.freebsd.org (Postfix) with ESMTP id 244F88FC16; Mon, 11 Aug 2008 17:06:26 +0000 (UTC) (envelope-from eugen@kuzbass.ru) Received: from www.svzserv.kemerovo.su (eugen@localhost [127.0.0.1]) by www.svzserv.kemerovo.su (8.13.8/8.13.8) with ESMTP id m7BH6OLZ044125; Tue, 12 Aug 2008 01:06:24 +0800 (KRAST) (envelope-from eugen@www.svzserv.kemerovo.su) Received: (from eugen@localhost) by www.svzserv.kemerovo.su (8.13.8/8.13.8/Submit) id m7BH6NQZ044123; Tue, 12 Aug 2008 01:06:23 +0800 (KRAST) (envelope-from eugen) Date: Tue, 12 Aug 2008 01:06:23 +0800 From: Eugene Grosbein To: John Baldwin Message-ID: <20080811170623.GA43671@svzserv.kemerovo.su> References: <20080627031233.9DC4945047@ptavv.es.net> <200808091717.31780.jhb@freebsd.org> <20080810062726.GA3979@svzserv.kemerovo.su> <200808111131.33371.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200808111131.33371.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-stable@freebsd.org Subject: Re: Problem with /boot/loader [A new patch] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2008 17:06:28 -0000 On Mon, Aug 11, 2008 at 11:31:33AM -0400, John Baldwin wrote: > > I've just rolled sys/boot/i386/btx back to RELENG_7_0_0_RELEASE > > leaving rest of src at 7.0-STABLE (plus your patch) and yes, I've got > > working loader! > > Err, my patch should have failed (well, the btx.S part) if you had a > 7.0-RELEASE sys/boot/i386/btx. I've applied patch first, then replaced sys/boot/i386/btx with 7.0-RELEASE version. Eugene Grosbein From owner-freebsd-stable@FreeBSD.ORG Mon Aug 11 19:16:25 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B22731065671 for ; Mon, 11 Aug 2008 19:16:25 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from sarah.protected-networks.net (sarah.protected-networks.net [IPv6:2001:470:1f07:4e1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 7837B8FC1E for ; Mon, 11 Aug 2008 19:16:25 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from [127.0.0.1] (localhost [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: imb) by sarah.protected-networks.net (Postfix) with ESMTPSA id 79C376136 for ; Mon, 11 Aug 2008 15:16:23 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=protected-networks.net; s=200705; t=1218482183; bh=oVlR8BcapwUgZb PUNeefpD1LSFMoihxhAVGfR17Cw2A=; h=Message-ID:Date:From:MIME-Version: To:Subject:Content-Type:Content-Transfer-Encoding; b=MUH0EaxBgkDfL o6x4iJBo3m0+0v5DWdKya14KYhdCP/PDFSIQZ3J2dGIgn4n8MBr62ewN6YJacUW3LFC rJeC9cqSVy0zAwrEEdky91vhunQfJlMbZE4GNCa4iJ5y+4dX DomainKey-Signature: a=rsa-sha1; s=200509; d=protected-networks.net; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:subject: content-type:content-transfer-encoding; b=PjqxLygJZ2+ciNLXq+Th4yrcTHSrAkrMR2jYzPPO5+ei+J7SSNp899TGxfBm6Fi8v IIGrhnsXk4LwVt7aXDyxEEmczQ2AOL7NpCOuuXCweIcsf+6Grj36slBTJJ5rxoV Message-ID: <48A09000.2000609@protected-networks.net> Date: Mon, 11 Aug 2008 15:16:16 -0400 From: Michael Butler User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: -stable tar complie broken? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2008 19:16:25 -0000 On a box cvsupped today, I get: imb@sarah:/usr/src/usr.bin/tar> sudo make clean depend all rm -f bsdtar bsdtar.o getdate.o matching.o read.o siginfo.o subst.o tree.o util.o write.o bsdtar.1.gz bsdtar.1.cat.gz getdate.c getdate.h yacc -d -o getdate.c /usr/src/usr.bin/tar/getdate.y yacc: 8 shift/reduce conflicts rm -f .depend mkdep -f .depend -a -DBSDTAR_VERSION_STRING=\"2.5.5\" -DPLATFORM_CONFIG_H=\"config_freebsd.h\" -I/usr/src/usr.bin/tar /usr/src/usr.bin/tar/bsdtar.c getdate.c /usr/src/usr.bin/tar/matching.c /usr/src/usr.bin/tar/read.c /usr/src/usr.bin/tar/siginfo.c /usr/src/usr.bin/tar/subst.c /usr/src/usr.bin/tar/tree.c /usr/src/usr.bin/tar/util.c /usr/src/usr.bin/tar/write.c echo bsdtar: /usr/lib/libc.a /usr/lib/libarchive.a /usr/lib/libbz2.a /usr/lib/libz.a >> .depend cc -O2 -fno-strict-aliasing -pipe -march=pentium3 -DBSDTAR_VERSION_STRING=\"2.5.5\" -DPLATFORM_CONFIG_H=\"config_freebsd.h\" -I/usr/src/usr.bin/tar -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wno-pointer-sign -c /usr/src/usr.bin/tar/bsdtar.c /usr/src/usr.bin/tar/bsdtar.c: In function 'main': /usr/src/usr.bin/tar/bsdtar.c:508: error: 'ARCHIVE_EXTRACT_SPARSE' undeclared (first use in this function) /usr/src/usr.bin/tar/bsdtar.c:508: error: (Each undeclared identifier is reported only once /usr/src/usr.bin/tar/bsdtar.c:508: error: for each function it appears in.) *** Error code 1 Michael From owner-freebsd-stable@FreeBSD.ORG Mon Aug 11 20:32:29 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 71C9D106564A for ; Mon, 11 Aug 2008 20:32:29 +0000 (UTC) (envelope-from markus@vervier.info) Received: from mail.system360.de (mail.system360.de [84.254.79.40]) by mx1.freebsd.org (Postfix) with ESMTP id 2A9E88FC13 for ; Mon, 11 Aug 2008 20:32:29 +0000 (UTC) (envelope-from markus@vervier.info) Received: from localhost (mail [84.254.79.40]) by mail.system360.de (Postfix) with ESMTP id DCE0510092C for ; Mon, 11 Aug 2008 22:42:49 +0200 (CEST) X-Virus-Scanned: amavisd-new at system360.de Received: from mail.system360.de ([84.254.79.40]) by localhost (mail.system360.de [84.254.79.40]) (amavisd-new, port 10024) with ESMTP id LDkeyGlCsJPy for ; Mon, 11 Aug 2008 22:42:47 +0200 (CEST) Received: from [192.168.2.15] (p5B39670E.dip.t-dialin.net [91.57.103.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.system360.de (Postfix) with ESMTP id 4D6AA100913 for ; Mon, 11 Aug 2008 22:42:47 +0200 (CEST) Message-ID: <48A0A1D9.8030601@vervier.info> Date: Mon, 11 Aug 2008 22:32:25 +0200 From: Markus Vervier User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <489C4129.4090303@vervier.info> <489C88DB.6030000@vervier.info> <2a41acea0808081131m1eddc4caib0963c8a5443afd2@mail.gmail.com> <200808110819.53914.josh@tcbug.org> <20080811140249.GA27379@eos.sc1.parodius.com> <2a41acea0808110928h10d54441o7d49b11a60406934@mail.gmail.com> In-Reply-To: <2a41acea0808110928h10d54441o7d49b11a60406934@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: em(4) on FreeBSD is sometimes annoying X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2008 20:32:29 -0000 Jack Vogel wrote: > Seems possibly a BIOS thing, if not that bad cable, bad link partner maybe?? > I had the problem with all sorts of switches / cables. How can I dump my EEPROM settings if that helps? -- Markus From owner-freebsd-stable@FreeBSD.ORG Mon Aug 11 20:40:33 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8C5F31065678 for ; Mon, 11 Aug 2008 20:40:33 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.227]) by mx1.freebsd.org (Postfix) with ESMTP id F3C068FC12 for ; Mon, 11 Aug 2008 20:40:32 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by wr-out-0506.google.com with SMTP id c8so847222wra.27 for ; Mon, 11 Aug 2008 13:40:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=lqPDCrQz7cCUjG9lDRYYkozd6zt5ouCuslVICMot0uk=; b=GXVP0kr9omn08fKmPhhN07B7xwahnfuYAeUaO3Gcbwr4EKGOtKpRS9uiX4McBRS5L0 WT+I5DlVzcuJA/kIX4iOY6ejhIs9WYJD1AC3aBdKHK0aC5k+/n9R3JMorTURdleqiLqd JKXUyDbyyVTgm+Bi3PsFsgRsxzSmWVzIjN2ds= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=BfhdfH9LM7C9p2bikKwUPta6ydhnF+QHKvs4criWWYQylwuvNwtVAXfobk+sNBf6eI R89zJYwpn8v35aNwSGDQ9ulq3e8Q29H3IB/9UTQnY77Bi/9Y8v+LRoTYgRdfE6KNxUXd 7U1YqIqBA0ul6cbBEMmD2LDZ+aqXoWATzHuE8= Received: by 10.90.73.17 with SMTP id v17mr11283649aga.7.1218487232182; Mon, 11 Aug 2008 13:40:32 -0700 (PDT) Received: by 10.100.43.1 with HTTP; Mon, 11 Aug 2008 13:40:32 -0700 (PDT) Message-ID: <2a41acea0808111340o7b506804u9e4c95f1af22b95c@mail.gmail.com> Date: Mon, 11 Aug 2008 13:40:32 -0700 From: "Jack Vogel" To: "Markus Vervier" In-Reply-To: <48A0A1D9.8030601@vervier.info> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <489C4129.4090303@vervier.info> <489C88DB.6030000@vervier.info> <2a41acea0808081131m1eddc4caib0963c8a5443afd2@mail.gmail.com> <200808110819.53914.josh@tcbug.org> <20080811140249.GA27379@eos.sc1.parodius.com> <2a41acea0808110928h10d54441o7d49b11a60406934@mail.gmail.com> <48A0A1D9.8030601@vervier.info> Cc: freebsd-stable@freebsd.org Subject: Re: em(4) on FreeBSD is sometimes annoying X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2008 20:40:33 -0000 On Mon, Aug 11, 2008 at 1:32 PM, Markus Vervier wrote: > Jack Vogel wrote: >> >> Seems possibly a BIOS thing, if not that bad cable, bad link partner >> maybe?? >> > > I had the problem with all sorts of switches / cables. How can I dump my > EEPROM settings if that helps? I didn't mean the NIC EEPROM, but the system BIOS, make sure you are running the version that Jeremy said he was, if that matches you might go look at settings in the BIOS that are about management. I thought you told us that when you had a back to back connection that it worked, no?? Jack From owner-freebsd-stable@FreeBSD.ORG Mon Aug 11 21:23:43 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6449310656A3 for ; Mon, 11 Aug 2008 21:23:42 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id C1C078FC08 for ; Mon, 11 Aug 2008 21:23:41 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [IPv6:::1]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m7BLNSRX069839; Mon, 11 Aug 2008 17:23:35 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: pluknet Date: Mon, 11 Aug 2008 13:15:23 -0400 User-Agent: KMail/1.9.7 References: <20080730113449.GD407@cdnetworks.co.kr> <200808111128.50840.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200808111315.23879.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Mon, 11 Aug 2008 17:23:35 -0400 (EDT) X-Virus-Scanned: ClamAV 0.93.1/8009/Mon Aug 11 14:57:09 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.3 required=4.2 tests=AWL,BAYES_00, DATE_IN_PAST_03_06,NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: freebsd-stable@freebsd.org, Ulrich Spoerlein Subject: Re: cpufreq(4) panic on RELENG_7 (was: Re: Call for bfe(4) testers.) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2008 21:23:43 -0000 On Monday 11 August 2008 12:35:17 pm pluknet wrote: > 2008/8/11 John Baldwin : > > On Saturday 09 August 2008 07:16:37 am Ulrich Spoerlein wrote: > >> Hi John, > >> > >> I now figured out the "who", the "why" still eludes me. > >> > >> So, after your MFC of ichss.c on June 27th the device now attaches at = my > >> laptop. It didn't before, so it could cause no trouble. > >> > >> With ichss loaded, the kernel will panic 1-3 minutes after powerd has > >> been started (if I kill powerd early enough, it seems pretty stable). > >> > >> I'm now running a kernel from 2008-08-08 with > >> hint.ichss.0.disabled=3D"1" > > > > Ok. Can you get a crashdump from a crash? > > >=20 > ehm,. I am not Ulrich Spoerlein, but I can help with this issue. >=20 > my crashdump from kgdb and some debug info. > (ouch, I forgot to include it in my prev. mail > http://lists.freebsd.org/pipermail/freebsd-stable/2008-August/044182.html= ) >=20 > wbr, > pluknet >=20 > Unread portion of the kernel message buffer: >=20 >=20 > Fatal trap 12: page fault while in kernel mode > fault virtual address =3D 0x38 > fault code =3D supervisor read, page not present > instruction pointer =3D 0x20:0xc056cf46 > stack pointer =3D 0x28:0xe6592ac8 > frame pointer =3D 0x28:0xe6592ac8 > code segment =3D base 0x0, limit 0xfffff, type 0x1b > =3D DPL 0, pres 1, def32 1, gran 1 > processor eflags =3D interrupt enabled, resume, IOPL =3D 0 > current process =3D 2507 (powerd) > Physical memory: 1014 MB > Dumping 120 MB: 105 89 73 57 41 25 9 >=20 > #0 doadump () at pcpu.h:195 > 195 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) bt > #0 doadump () at pcpu.h:195 > #1 0xc0458f89 in db_fncall (dummy1=3D-1010027648, dummy2=3D0, dummy3=3D0, > dummy4=3D0xe6592860 "0=AC=CA=C3") at /media/src-7/sys/ddb/db_command.= c:516 > #2 0xc045953a in db_command (last_cmdp=3D0xc07dcf14, cmd_table=3D0x0,=20 dopager=3D1) > at /media/src-7/sys/ddb/db_command.c:413 > #3 0xc0459655 in db_command_loop ()=20 at /media/src-7/sys/ddb/db_command.c:466 > #4 0xc045b17c in db_trap (type=3D12, code=3D0) > at /media/src-7/sys/ddb/db_main.c:228 > #5 0xc0575023 in kdb_trap (type=3D12, code=3D0, tf=3D0xe6592a88) > at /media/src-7/sys/kern/subr_kdb.c:524 > #6 0xc07460bf in trap_fatal (frame=3D0xe6592a88, eva=3D56) > at /media/src-7/sys/i386/i386/trap.c:890 > #7 0xc074636b in trap_pfault (frame=3D0xe6592a88, usermode=3D0, eva=3D56) > at /media/src-7/sys/i386/i386/trap.c:812 > #8 0xc0746d36 in trap (frame=3D0xe6592a88) > at /media/src-7/sys/i386/i386/trap.c:490 > #9 0xc072fd4b in calltrap () at /media/src-7/sys/i386/i386/exception.s:1= 39 > #10 0xc056cf46 in device_is_attached (dev=3D0x0) > at /media/src-7/sys/kern/subr_bus.c:2228 > #11 0xc0512de7 in cf_set_method (dev=3D0xc3c9c880, level=3D0xc4525ef4, > priority=3D100) at /media/src-7/sys/kern/kern_cpu.c:332 > #12 0xc0511452 in cpufreq_curr_sysctl (oidp=3D0xc3c8bac0, arg1=3D0xc3bc7c= 00, > arg2=3D0, req=3D0xe6592ba4) at cpufreq_if.h:32 > ---Type to continue, or q to quit--- > #13 0xc0554b67 in sysctl_root (oidp=3DVariable "oidp" is not available. > ) > at /media/src-7/sys/kern/kern_sysctl.c:1306 > #14 0xc0554cd1 in userland_sysctl (td=3D0xc4245440, name=3D0xe6592c14,=20 namelen=3D4, > old=3D0x0, oldlenp=3D0x0, inkernel=3D0, new=3D0xbfbfe7c4, newlen=3D4, > retval=3D0xe6592c10, flags=3D0) at /media/src-7/sys/kern/kern_sysctl.= c:1401 > #15 0xc0555a7c in __sysctl (td=3D0xc4245440, uap=3D0xe6592cfc) > at /media/src-7/sys/kern/kern_sysctl.c:1336 > #16 0xc07466d5 in syscall (frame=3D0xe6592d38) > at /media/src-7/sys/i386/i386/trap.c:1035 > #17 0xc072fdb0 in Xint0x80_syscall () > at /media/src-7/sys/i386/i386/exception.s:196 > #18 0x00000033 in ?? () > Previous frame inner to this frame (corrupt stack?) > (kgdb) f 11 > #11 0xc0512de7 in cf_set_method (dev=3D0xc3c9c880, level=3D0xc4525ef4, > priority=3D100) at /media/src-7/sys/kern/kern_cpu.c:332 > 332 if (!device_is_attached(set->dev)) { > (kgdb) list > 327 } > 328 > 329 /* Next, set any/all relative frequencies via their drive= rs.=20 */ > 330 for (i =3D 0; i < level->rel_count; i++) { > 331 set =3D &level->rel_set[i]; > 332 if (!device_is_attached(set->dev)) { > 333 error =3D ENXIO; > 334 goto out; > 335 } > 336 > (kgdb) p level.rel_count > $1 =3D 1986356271 > (kgdb) p i > $2 =3D 0 > (kgdb) p level.rel_set > $3 =3D {{freq =3D 0, volts =3D 0, power =3D 0, lat =3D 0, dev =3D 0x0, sp= ec =3D {0, 0, 0, > 0}}, {freq =3D 0, volts =3D 0, power =3D 0, lat =3D 0, dev =3D 0x0,= spec =3D {0,=20 0, > 0, 0}}, {freq =3D 0, volts =3D 0, power =3D 0, lat =3D 0, dev =3D 0= x0, spec =3D=20 {0, > 0, 0, 0}}, {freq =3D 0, volts =3D 0, power =3D 0, lat =3D 0, dev = =3D 0x0, spec =3D=20 { > 0, 0, 0, 0}}, {freq =3D 0, volts =3D 0, power =3D 0, lat =3D 0, dev= =3D 0x0, > spec =3D {0, 0, 0, 0}}, {freq =3D 0, volts =3D 0, power =3D 0, lat = =3D 0, > dev =3D 0x656e7552, spec =3D {828858701, 1162760014, 0, 134632492}}, { > freq =3D 0, volts =3D 53, power =3D -1024, lat =3D -1, dev =3D 0x7fff= ffff, spec =3D=20 { > ----- and so on----- >=20 > Also there are very unusual (and high) numbers in sysctl=20 dev.cpu.0.freq_levels. Which cpufreq drivers are you using? Can you narrow down your panics (and= =20 weird frequencies in the sysctl) to being caused by a specific cpufreq=20 driver? =2D-=20 John Baldwin From owner-freebsd-stable@FreeBSD.ORG Mon Aug 11 21:23:48 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DF43D1065751 for ; Mon, 11 Aug 2008 21:23:48 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 7CBC88FC12 for ; Mon, 11 Aug 2008 21:23:48 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [IPv6:::1]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m7BLNSRY069839; Mon, 11 Aug 2008 17:23:42 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: Eugene Grosbein Date: Mon, 11 Aug 2008 14:00:49 -0400 User-Agent: KMail/1.9.7 References: <20080627031233.9DC4945047@ptavv.es.net> <200808111131.33371.jhb@freebsd.org> <20080811170623.GA43671@svzserv.kemerovo.su> In-Reply-To: <20080811170623.GA43671@svzserv.kemerovo.su> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200808111400.49376.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Mon, 11 Aug 2008 17:23:42 -0400 (EDT) X-Virus-Scanned: ClamAV 0.93.1/8009/Mon Aug 11 14:57:09 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.3 required=4.2 tests=AWL,BAYES_00, DATE_IN_PAST_03_06,NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: freebsd-stable@freebsd.org Subject: Re: Problem with /boot/loader [A new patch] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2008 21:23:49 -0000 On Monday 11 August 2008 01:06:23 pm Eugene Grosbein wrote: > On Mon, Aug 11, 2008 at 11:31:33AM -0400, John Baldwin wrote: > > > > I've just rolled sys/boot/i386/btx back to RELENG_7_0_0_RELEASE > > > leaving rest of src at 7.0-STABLE (plus your patch) and yes, I've got > > > working loader! > > > > Err, my patch should have failed (well, the btx.S part) if you had a > > 7.0-RELEASE sys/boot/i386/btx. > > I've applied patch first, then replaced sys/boot/i386/btx with 7.0-RELEASE > version. Ok, I'm at a loss for why the new BTX doesn't work for you. Unfortunately, this sort of thing isn't easy to debug. If you have firewire (and another machine with firewire) then I have some debugging code I used with qemu to save a summary of the last request made by the loader to BTX. That can at least indicate which BIOS call is hanging. From there you can dissassemble your BIOS to try to determine if there are any spin loops and see what it is waiting on. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Mon Aug 11 21:24:11 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 37D4810657B1 for ; Mon, 11 Aug 2008 21:24:11 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id C4BFD8FC0C for ; Mon, 11 Aug 2008 21:24:10 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [IPv6:::1]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m7BLNm73069851; Mon, 11 Aug 2008 17:24:03 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-stable@freebsd.org Date: Mon, 11 Aug 2008 17:04:30 -0400 User-Agent: KMail/1.9.7 References: <200808110401.49953.kuuse@redantigua.com> In-Reply-To: <200808110401.49953.kuuse@redantigua.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200808111704.30604.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Mon, 11 Aug 2008 17:24:04 -0400 (EDT) X-Virus-Scanned: ClamAV 0.93.1/8009/Mon Aug 11 14:57:09 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Johan Kuuse Subject: Re: kernel panic X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2008 21:24:11 -0000 On Sunday 10 August 2008 10:01:49 pm Johan Kuuse wrote: > Hi, > > I am a kgdb newbie, so please be patient. > I suspect (just based on the fact that this is the 4th time I edit text files on my NTFS partition through ntfs-3g, using Emacs, and getting frequent I/O error messages inside Emacs, and then a kernel panic) that this is a ntfs-3g related problem. > If you ask me exactly how to reproduce it, I sorry, I can tell you exactly (but see the kgdb output below). > Anyway, the kernel seems to panic at /usr/src/sys/kern/vfs_bio.c:1530 > > Just a suggestion for a patch (without knowing the functionality of /usr/src/sys/kern/vfs_bio.c): > > The line where the kernel panics: > /usr/src/sys/kern/vfs_bio.c: > ---------------------------------- > VM_OBJECT_LOCK(bp->b_bufobj->bo_object); > ... > ---------------------------------- > > Comparing to another file, which does error checking before calling VM_OBJECT_LOCK: > /usr/src/sys/kern/vfs_aio.c: > ---------------------------------- > if (vp->v_object != NULL) { > VM_OBJECT_LOCK(vp->v_object); > ... > ---------------------------------- > > Perhaps the kernel panic could be avoided with the following patch? > /usr/src/sys/kern/vfs_bio.c (suggested patch): > ---------------------------------- > if ((bp->b_bufobj != NULL) && (bp->b_bufobj->bo_object != NULL)) { > VM_OBJECT_LOCK(bp->b_bufobj->bo_object); > ... > ---------------------------------- > > Please let me know if you need more information. > > Regards, > Johan Kuuse > > ----------------------------------------------------------------------------------------------------------- > kgdb kernel.debug /var/crash/vmcore.1 > [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "i386-marcel-freebsd". > > Unread portion of the kernel message buffer: > > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x34 > fault code = supervisor read, page not present > instruction pointer = 0x20:0xc07b6de4 > stack pointer = 0x28:0xe79de7c8 > frame pointer = 0x28:0xe79de7e8 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 1214 (opera) > trap number = 12 > panic: page fault > cpuid = 0 > Uptime: 5h20m30s > Physical memory: 2035 MB > Dumping 218 MB: 203 187 171 155 139 123 107 91 75 59 43 27 11 > > #0 doadump () at pcpu.h:195 > 195 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); > (kgdb) list *0xc07b6de4 > 0xc07b6de4 is in vfs_vmio_release (/usr/src/sys/kern/vfs_bio.c:1530). > 1525 vfs_vmio_release(struct buf *bp) > 1526 { > 1527 int i; > 1528 vm_page_t m; > 1529 > 1530 VM_OBJECT_LOCK(bp->b_bufobj->bo_object); > 1531 vm_page_lock_queues(); > 1532 for (i = 0; i < bp->b_npages; i++) { > 1533 m = bp->b_pages[i]; > 1534 bp->b_pages[i] = NULL; > (kgdb) bt > #0 doadump () at pcpu.h:195 > #1 0xc0754457 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 > #2 0xc0754719 in panic (fmt=Variable "fmt" is not available. > ) at /usr/src/sys/kern/kern_shutdown.c:563 > #3 0xc0a4905c in trap_fatal (frame=0xe79de788, eva=52) at /usr/src/sys/i386/i386/trap.c:899 > #4 0xc0a492e0 in trap_pfault (frame=0xe79de788, usermode=0, eva=52) at /usr/src/sys/i386/i386/trap.c:812 > #5 0xc0a49c8c in trap (frame=0xe79de788) at /usr/src/sys/i386/i386/trap.c:490 > #6 0xc0a2fc0b in calltrap () at /usr/src/sys/i386/i386/exception.s:139 > #7 0xc07b6de4 in vfs_vmio_release (bp=0xd927e33c) at /usr/src/sys/kern/vfs_bio.c:1530 > #8 0xc07b8a81 in getnewbuf (slpflag=0, slptimeo=0, size=Variable "size" is not available. > ) at /usr/src/sys/kern/vfs_bio.c:1847 > #9 0xc07ba118 in getblk (vp=0xc8891bb0, blkno=0, size=2048, slpflag=0, slptimeo=0, flags=Variable "flags" is not available. > ) at /usr/src/sys/kern/vfs_bio.c:2602 > #10 0xc0932815 in ffs_balloc_ufs2 (vp=0xc8891bb0, startoffset=Variable "startoffset" is not available. > ) at /usr/src/sys/ufs/ffs/ffs_balloc.c:699 > #11 0xc0952a85 in ffs_write (ap=0xe79debc4) at /usr/src/sys/ufs/ffs/ffs_vnops.c:720 > #12 0xc0a5efc6 in VOP_WRITE_APV (vop=0xc0b93c60, a=0xe79debc4) at vnode_if.c:691 > #13 0xc07dbf37 in vn_write (fp=0xc85f3168, uio=0xe79dec60, active_cred=0xc61c6300, flags=0, td=0xc583fc60) at vnode_if.h:373 > #14 0xc07875e7 in dofilewrite (td=0xc583fc60, fd=17, fp=0xc85f3168, auio=0xe79dec60, offset=-1, flags=0) at file.h:254 > #15 0xc07878c8 in kern_writev (td=0xc583fc60, fd=17, auio=0xe79dec60) at /usr/src/sys/kern/sys_generic.c:401 > #16 0xc078793f in write (td=0xc583fc60, uap=0xe79decfc) at /usr/src/sys/kern/sys_generic.c:317 > #17 0xc0a49635 in syscall (frame=0xe79ded38) at /usr/src/sys/i386/i386/trap.c:1035 > #18 0xc0a2fc70 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:196 > #19 0x00000033 in ?? () > Previous frame inner to this frame (corrupt stack?) FYI, you got the panic in ffs/ufs, not fuse. I've seen this at work on 6.x with NFS with no clues on what causes it. You can start by going to frame 7 and doing 'p *bp'. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Mon Aug 11 22:13:09 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AD56E1065675 for ; Mon, 11 Aug 2008 22:13:08 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 63CDE8FC12 for ; Mon, 11 Aug 2008 22:13:08 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1KSfdO-0008FF-I8 for freebsd-stable@freebsd.org; Mon, 11 Aug 2008 22:13:02 +0000 Received: from 78-0-73-142.adsl.net.t-com.hr ([78.0.73.142]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 11 Aug 2008 22:13:02 +0000 Received: from ivoras by 78-0-73-142.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 11 Aug 2008 22:13:02 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Ivan Voras Date: Tue, 12 Aug 2008 00:12:44 +0200 Lines: 34 Message-ID: References: <43EC06E9-76B3-4AA1-BC5E-4E1BD64AFC2D@SARENET.ES> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigB20F3CD8C71F5BCD314DD691" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 78-0-73-142.adsl.net.t-com.hr User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) In-Reply-To: <43EC06E9-76B3-4AA1-BC5E-4E1BD64AFC2D@SARENET.ES> X-Enigmail-Version: 0.95.6 Sender: news Subject: Re: umtxn and Apache 2.2 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2008 22:13:09 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB20F3CD8C71F5BCD314DD691 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Borja Marcos wrote: > Hello, >=20 > I'm running a server with FreeBSD 7-STABLE as of August 8, Apache 2.2=20 > with mpm/worker and threads support, and PHP 5.2.6. >=20 > Everything works like a charm, but I see that Apache is leaking=20 > processes that get stuck in umtxn state. I run Apache 2.2 with worker MPM but without mod_php (I use PHP as=20 FastCGI) on many servers and I don't have such problems. Maybe it's=20 PHP's fault? (I agree you need a trace with debugging symbols). --------------enigB20F3CD8C71F5BCD314DD691 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIoLlildnAQVacBcgRAqZ7AJ4nSQwluFwEhzKHO93BRl4CLpvAMQCfQ5Lv ZMc4vmY9YB96ObKXQmn2NEA= =mSXg -----END PGP SIGNATURE----- --------------enigB20F3CD8C71F5BCD314DD691-- From owner-freebsd-stable@FreeBSD.ORG Mon Aug 11 22:38:10 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8C5901065671 for ; Mon, 11 Aug 2008 22:38:10 +0000 (UTC) (envelope-from ebutusov@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.153]) by mx1.freebsd.org (Postfix) with ESMTP id 18DD28FC08 for ; Mon, 11 Aug 2008 22:38:09 +0000 (UTC) (envelope-from ebutusov@gmail.com) Received: by fg-out-1718.google.com with SMTP id l26so3067336fgb.35 for ; Mon, 11 Aug 2008 15:38:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:content-type :content-transfer-encoding; bh=vHrIMMagssYF28hVyhXQ3ZjIfMAmEcJD4WDdar8T28k=; b=vydIia2MYWLS2QaGimyGIAZu5PtytjRhs6TXNIg+7E0rjZe+9i8jJtZYg8+Fp0dt3D Cr1dRMMrbf2qcj3wM9lyYT0UOx77+8uZqN6rY/uk743dzOQn0wm/i44Wlw9GOtJWEPgv Jvh40JNahEgQQFKYPoPFZfNs+J9fqga3dXpEY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=QBEmYEwL6jwCniLRLKSspqcb59yfbpNfyEcn1nSlI0BKUdFZMSI5i0FJE9vUXDVLRZ B+mzTWDtKZ1pu9NOVX2gd02hsvWPLGsqdngBkjWXDxPZ5l/Si6E62aAJZXTdoe1XkdQT 70nSqEnYAt334Jl5ZjeMGR8PW+AbmWPleWtf8= Received: by 10.102.244.1 with SMTP id r1mr3767147muh.25.1218494288337; Mon, 11 Aug 2008 15:38:08 -0700 (PDT) Received: from ?192.168.0.51? ( [195.136.67.137]) by mx.google.com with ESMTPS id u9sm2181070muf.12.2008.08.11.15.38.06 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 11 Aug 2008 15:38:07 -0700 (PDT) Message-ID: <48A0BF40.2030607@gmail.com> Date: Tue, 12 Aug 2008 00:37:52 +0200 From: Eugene Butusov User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: FreeBSD-STABLE-LIST Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit Subject: Hardware monitoring for Intel Atom D945GCLF. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2008 22:38:10 -0000 Hi, Is there a way to make use of hardware monitoring on Intel 945GCLF (with Atom 230 cpu)? It is relatively new child of Intel, but maybe someone figured it out yet. pciconf -lv shows this: ichsmb0@pci0:0:31:3: class=0x0c0500 card=0x464c8086 chip=0x27da8086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) SMBus Controller' class = serial bus subclass = SMBus Modules ichsmb and smb are loaded, /dev/smb0 is present, but mbon and lmmon don't give any results. lmmon says: IOCTL: Device not configured mbmon prints this: No SMBus HWM available!! InitMBInfo: Unknown error: 0 Best regards, -- _/_/ .. Eugene Butusov _/_/ ... www.devilka.info _/_/ .... ebutusov(at)gmail(dot)com From owner-freebsd-stable@FreeBSD.ORG Mon Aug 11 23:45:47 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CA4F11065673 for ; Mon, 11 Aug 2008 23:45:47 +0000 (UTC) (envelope-from jdc@parodius.com) Received: from mx01.sc1.parodius.com (mx01.sc1.parodius.com [72.20.106.3]) by mx1.freebsd.org (Postfix) with ESMTP id B07FC8FC0A for ; Mon, 11 Aug 2008 23:45:47 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id 9AE9B1CC0BF; Mon, 11 Aug 2008 16:45:47 -0700 (PDT) Date: Mon, 11 Aug 2008 16:45:47 -0700 From: Jeremy Chadwick To: Eugene Butusov Message-ID: <20080811234547.GA67278@eos.sc1.parodius.com> References: <48A0BF40.2030607@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48A0BF40.2030607@gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: FreeBSD-STABLE-LIST Subject: Re: Hardware monitoring for Intel Atom D945GCLF. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2008 23:45:47 -0000 On Tue, Aug 12, 2008 at 12:37:52AM +0200, Eugene Butusov wrote: > Hi, > > Is there a way to make use of hardware monitoring on Intel 945GCLF > (with Atom 230 cpu)? > It is relatively new child of Intel, but maybe someone figured it out > yet. > > pciconf -lv shows this: > > ichsmb0@pci0:0:31:3: class=0x0c0500 card=0x464c8086 chip=0x27da8086 > rev=0x01 hdr=0x00 > vendor = 'Intel Corporation' > device = '82801G (ICH7 Family) SMBus Controller' > class = serial bus > subclass = SMBus > > Modules ichsmb and smb are loaded, /dev/smb0 is present, but mbon and > lmmon don't give any results. The board in question is here: http://www.intel.com/products/desktop/motherboards/D945GCLF/D945GCLF-overview.htm The Technical Product Specification also does not mention any H/W monitoring IC in the Block Diagram (see section 1.1.3): http://download.intel.com/support/motherboards/desktop/d945gclf/sb/e35968001us.pdf Section 1.11 mentions support for Hardware Monitoring via "WfM", and Section 1.11.1 states that such statistics are available via SMBus (which is the more important part). More on that in a moment. Secondly, re: lmmon: no surprise. It's very, very unlikely your Intel board will contain an LMxx IC; lmmon is specifically for older motherboards (read: mid-to-late 90s) which use LMxx series ICs. There are some present-day AMD boards which use dual LMxx ICs, but it's not a common thing. Thirdly, mbmon doesn't particularly use SMBus in the way you think it would, and I'm betting use of -I will either fail, report fake values, or crash your system, since I don't think any of the features are available on the ISA bus (good riddance). See my H/W monitoring project for FreeBSD: http://bsdhwmon.parodius.com/ I'm presently focusing on Supermicro boards. Regarding your board, I found this on Intel's site: http://www.intel.com/support/motherboards/desktop/sb/CS-012552.htm#sdk * Developing Applications to Read Thermal Information Intel does not offer any development kit or API for application development that will allow you to read a board.s thermal values. However, there are 3rd party tools that you may find helpful. I don't need an API, but this kind of statement makes Intel sound like they're not willing to disclose the SMBus offsets for monitoring. I might have to look at lm-sensors from Linux, but that code is very difficult to follow. I'm not sure if Intel gives this sort of information out publicly, but I sure hope so. You might be able to get CPU thermal statistics by looking at sysctl, but I know absolutely nothing about the Atom CPU (if it behaves like a Core2Duo, then the coretemp(4) driver might work with it, or might need to be modified to work with it). -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Mon Aug 11 23:54:56 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 57E0D106567D for ; Mon, 11 Aug 2008 23:54:56 +0000 (UTC) (envelope-from jdc@parodius.com) Received: from mx01.sc1.parodius.com (mx01.sc1.parodius.com [72.20.106.3]) by mx1.freebsd.org (Postfix) with ESMTP id 45BBB8FC18 for ; Mon, 11 Aug 2008 23:54:56 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id 374CD1CC0C0; Mon, 11 Aug 2008 16:54:56 -0700 (PDT) Date: Mon, 11 Aug 2008 16:54:56 -0700 From: Jeremy Chadwick To: Eugene Butusov Message-ID: <20080811235456.GA70635@eos.sc1.parodius.com> References: <48A0BF40.2030607@gmail.com> <20080811234547.GA67278@eos.sc1.parodius.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080811234547.GA67278@eos.sc1.parodius.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: FreeBSD-STABLE-LIST Subject: Re: Hardware monitoring for Intel Atom D945GCLF. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2008 23:54:56 -0000 On Mon, Aug 11, 2008 at 04:45:47PM -0700, Jeremy Chadwick wrote: > I don't need an API, but this kind of statement makes Intel sound like > they're not willing to disclose the SMBus offsets for monitoring. I > might have to look at lm-sensors from Linux, but that code is very > difficult to follow. I'm not sure if Intel gives this sort of > information out publicly, but I sure hope so. There's a web page mentioning this board (note: entirely Japanese) -- http://iktaka.dyndns.org/node/11 The bottom part of the page states that Linux's lm_sensors 3.0.2 can successfully monitor temperatures, voltages, and fan RPMs on that board, very likely via SMBus. Ideally I should be able to track down technical details by looking at that code. I'd feel much more comfortable asking Intel and having them provide necessary registers and offsets, though; I prefer to avoid reverse-engineering things if possible (less mistakes). -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Tue Aug 12 01:04:21 2008 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 49E361065675 for ; Tue, 12 Aug 2008 01:04:21 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.236]) by mx1.freebsd.org (Postfix) with ESMTP id 10F7F8FC20 for ; Tue, 12 Aug 2008 01:04:20 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so3724575rvf.43 for ; Mon, 11 Aug 2008 18:04:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:date:from :to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=bngCZHMWskZ2EpGhPFDS00WThy2DyL5DpUAm15077m4=; b=uC5jOA+HV5i1E43k6NnMfYlCDxtecSIDqj44eC0jstY8Hnmj/vEEhlaWiWMQ1QxyQa NLlTk+FZpL0GRBVzpxIIQrmiqvYz8VQ2NmD+M0Tj9noK5WbEgweTvh1++dn+l988weY8 KNrRnZ8j+AVJY5Yp1BZN/+154kE7nwM9qw6HA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=P6ZoRInPX4IQD9pZVzhxzOnNWg1jtkA0smgy9t0fvfdX+S3gbwMaZSzAFsyvOGVpSs 2ItLfA3vdRAs5+r4kztqES+x1lg6pk581Tfj9+WsTdohnxAwKI/eWNyJ7+fo5DThf8c0 yZiZIF5rdElDGy8fc/KeEE+k6qHle12PyPhR8= Received: by 10.141.88.3 with SMTP id q3mr3953052rvl.94.1218503060762; Mon, 11 Aug 2008 18:04:20 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTPS id g31sm9933269rvb.2.2008.08.11.18.04.17 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 11 Aug 2008 18:04:19 -0700 (PDT) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id m7C1282I054658 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Aug 2008 10:02:08 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id m7C125Xa054657; Tue, 12 Aug 2008 10:02:05 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Tue, 12 Aug 2008 10:02:04 +0900 From: Pyun YongHyeon To: Pete French Message-ID: <20080812010204.GA54362@cdnetworks.co.kr> References: <20080808101831.GD38118@cdnetworks.co.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: stable@freebsd.org Subject: Re: should looking at an interface with 'ifconfig' trigger a change ? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2008 01:04:21 -0000 On Mon, Aug 11, 2008 at 02:03:31PM +0100, Pete French wrote: > Pyun YongHyeon wrote: > > Try attached patch and check whether bce(4) correctly reports link > > state changes. > > > > After seeing 'link state changed to UP' message, unplug the cable > > and see whether it reports link DOWN. The message should be printed > > in a second. Also try replugging cable and you should see link UP > > message within several seconds. Since auto-negotation takes more > > time you may have to wait for a while. > > I do not have phsyical access to the machine, so I did this using > a sutdown of the interface on the sitch - but yes, it works! This fixes > the progem with lagg as well - it now fails over to the other interface > properly. > > Such a simple patch - if this has no ill effects then I will deploy it > on al our servers,m and hope for it to be committed soon. All new HP > servers appear to come with bce interfaces, so this is an importnat fix > for us, and probably a lot of other people too. Thanks. > Thanks for testing! Patch committed to HEAD with svn r181619. > -pete. -- Regards, Pyun YongHyeon From owner-freebsd-stable@FreeBSD.ORG Tue Aug 12 01:27:12 2008 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A720D106566C for ; Tue, 12 Aug 2008 01:27:12 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 6DE448FC13 for ; Tue, 12 Aug 2008 01:27:12 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m7C0xwg5075519; Mon, 11 Aug 2008 20:59:58 -0400 (EDT) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.8/8.13.3) with ESMTP id m7C0xvUH028011 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Aug 2008 20:59:57 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <200808120059.m7C0xvUH028011@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 11 Aug 2008 21:00:05 -0400 To: Robert Watson , stable@freebsd.org From: Mike Tancsa In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: Re: HEADS UP: inpcb/inpcbinfo rwlocking: coming to a 7-STABLE branch near you X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2008 01:27:12 -0000 At 05:21 PM 8/8/2008, Robert Watson wrote: > >http://www.watson.org/~robert/freebsd/netperf/20080808-7stable-rwlock-inpcb.diff > >These incude the inpcb/inpcbinfo read/write locking changes >(although not yet for raw/divert sockets). Any testing, especially >with heavy UDP loads, would be much appreciated -- this are fairly >complex changes, and also quite a complex MFC. Hi Robert, So far so good with the patches. I am running them on a busy sendmail server that also does a lot of DNS locally for itself and a number of other boxes. ---Mike From owner-freebsd-stable@FreeBSD.ORG Tue Aug 12 01:50:19 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5880A106567D; Tue, 12 Aug 2008 01:50:19 +0000 (UTC) (envelope-from eugen@kuzbass.ru) Received: from www.svzserv.kemerovo.su (www.svzserv.kemerovo.su [213.184.65.80]) by mx1.freebsd.org (Postfix) with ESMTP id A3E558FC19; Tue, 12 Aug 2008 01:50:18 +0000 (UTC) (envelope-from eugen@kuzbass.ru) Received: from kuzbass.ru (kost [213.184.65.82]) by www.svzserv.kemerovo.su (8.13.8/8.13.8) with ESMTP id m7C1oFUF023078; Tue, 12 Aug 2008 09:50:15 +0800 (KRAST) (envelope-from eugen@kuzbass.ru) Message-ID: <48A0EC59.16D49C91@kuzbass.ru> Date: Tue, 12 Aug 2008 09:50:17 +0800 From: Eugene Grosbein Organization: SVZServ X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: ru,en MIME-Version: 1.0 To: John Baldwin References: <20080627031233.9DC4945047@ptavv.es.net> <200808111131.33371.jhb@freebsd.org> <20080811170623.GA43671@svzserv.kemerovo.su> <200808111400.49376.jhb@freebsd.org> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: Problem with /boot/loader [A new patch] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2008 01:50:19 -0000 John Baldwin wrote: > Ok, I'm at a loss for why the new BTX doesn't work for you. Unfortunately, > this sort of thing isn't easy to debug. If you have firewire (and another > machine with firewire) then I have some debugging code I used with qemu to > save a summary of the last request made by the loader to BTX. That can at > least indicate which BIOS call is hanging. From there you can dissassemble > your BIOS to try to determine if there are any spin loops and see what it is > waiting on. Thank you very much for the effort. I have firewire here but not another machine with it, but I'll try to find one. I'll contact you again when I'll find it. Eugene Grosbein From owner-freebsd-stable@FreeBSD.ORG Tue Aug 12 04:04:49 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C7BA71065673 for ; Tue, 12 Aug 2008 04:04:49 +0000 (UTC) (envelope-from rmtodd@ichotolot.servalan.com) Received: from mx1.synetsystems.com (mx1.synetsystems.com [76.10.206.14]) by mx1.freebsd.org (Postfix) with ESMTP id 9AB408FC1B for ; Tue, 12 Aug 2008 04:04:49 +0000 (UTC) (envelope-from rmtodd@ichotolot.servalan.com) Received: by mx1.synetsystems.com (Postfix, from userid 66) id 711B6B62; Mon, 11 Aug 2008 23:45:07 -0400 (EDT) Received: from rmtodd by servalan.servalan.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1KSkkb-000J1X-8c; Mon, 11 Aug 2008 22:40:49 -0500 To: Jeremy Chadwick References: <20080810175934.X2427@borg> <20080811065822.GA81972@voi.aagh.net> <20080811130555.GA25024@eos.sc1.parodius.com> From: Richard Todd Date: Mon, 11 Aug 2008 13:53:03 -0500 In-Reply-To: (Jeremy Chadwick's message of "Mon, 11 Aug 2008 06:05:55 -0700") Message-ID: User-Agent: Gnus/5.1008 (Gnus v5.10.8) XEmacs/21.4.21 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-stable@freebsd.org Subject: Re: ICRC's X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2008 04:04:49 -0000 Jeremy Chadwick writes: > If Larry was using UFS, he'd also see the above errors from the kernel. > FreeBSD reports the CRC errors reported by the ATA device, ZFS reports > the said data as corrupted during scrubbing or standard usage (hence the > CKSUM field in 'zpool status'), and ZFS also *repairs* the corrupted > data. I can't explain how the repair works, but it's one of the many > features of the filesystem. I believe journalling filesystems (e.g. Um, not exactly. It's one of the features of the filesystem when you're running on a ZFS pool which is mirrored or raidz. If your ZFS pool is not mirrored or raidz-ed, checksum errors *will* be unrepairable and should show up as read errors to the application. AFAIK, the "repair" is just ZFS either finding a good copy of the block from the other half of the mirror (if mirrored) or reconstructing the missing block thru parity (if raidz-ed) and rewriting it. From owner-freebsd-stable@FreeBSD.ORG Tue Aug 12 06:42:59 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F37DB1065674 for ; Tue, 12 Aug 2008 06:42:58 +0000 (UTC) (envelope-from kuuse@redantigua.com) Received: from kilimanjaro.scorpionshops.com (kilimanjaro.scorpionshops.com [83.140.32.147]) by mx1.freebsd.org (Postfix) with ESMTP id 450008FC1A for ; Tue, 12 Aug 2008 06:42:58 +0000 (UTC) (envelope-from kuuse@redantigua.com) Received: from [192.168.1.128] (144.Red-83-49-238.dynamicIP.rima-tde.net [83.49.238.144]) by kilimanjaro.scorpionshops.com (Postfix) with ESMTP id 8975CD38054; Tue, 12 Aug 2008 08:42:55 +0200 (CEST) From: Johan Kuuse Organization: Red Antigua To: John Baldwin Date: Tue, 12 Aug 2008 08:42:52 +0200 User-Agent: KMail/1.9.7 References: <200808110401.49953.kuuse@redantigua.com> <200808111704.30604.jhb@freebsd.org> In-Reply-To: <200808111704.30604.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200808120842.52899.kuuse@redantigua.com> Cc: freebsd-stable@freebsd.org Subject: Re: kernel panic X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2008 06:42:59 -0000 On Monday 11 August 2008 23:04:30 John Baldwin wrote: > On Sunday 10 August 2008 10:01:49 pm Johan Kuuse wrote: > > Hi, > >=20 > > I am a kgdb newbie, so please be patient. > > I suspect (just based on the fact that this is the 4th time I edit text= =20 > files on my NTFS partition through ntfs-3g, using Emacs, and getting freq= uent=20 > I/O error messages inside Emacs, and then a kernel panic) that this is a= =20 > ntfs-3g related problem. > > If you ask me exactly how to reproduce it, I sorry, I can tell you exac= tly=20 > (but see the kgdb output below). > > Anyway, the kernel seems to panic at /usr/src/sys/kern/vfs_bio.c:1530 > >=20 > > Just a suggestion for a patch (without knowing the functionality=20 > of /usr/src/sys/kern/vfs_bio.c): > >=20 > > The line where the kernel panics: > > /usr/src/sys/kern/vfs_bio.c: > > ---------------------------------- > > VM_OBJECT_LOCK(bp->b_bufobj->bo_object); > > ... > > ---------------------------------- > >=20 > > Comparing to another file, which does error checking before calling=20 > VM_OBJECT_LOCK: > > /usr/src/sys/kern/vfs_aio.c: > > ---------------------------------- > > if (vp->v_object !=3D NULL) { > > VM_OBJECT_LOCK(vp->v_object); > > ... > > ---------------------------------- > >=20 > > Perhaps the kernel panic could be avoided with the following patch? > > /usr/src/sys/kern/vfs_bio.c (suggested patch): > > ---------------------------------- > > if ((bp->b_bufobj !=3D NULL) && (bp->b_bufobj->bo_object !=3D NULL)) { > > VM_OBJECT_LOCK(bp->b_bufobj->bo_object); > > ... > > ---------------------------------- > >=20 > > Please let me know if you need more information. > >=20 > > Regards, > > Johan Kuuse > >=20 > > -----------------------------------------------------------------------= =2D----------------------------------- > > kgdb kernel.debug /var/crash/vmcore.1=20 > > [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db= =2Eso:=20 > Undefined symbol "ps_pglobal_lookup"] > > GNU gdb 6.1.1 [FreeBSD] > > Copyright 2004 Free Software Foundation, Inc. > > GDB is free software, covered by the GNU General Public License, and yo= u are > > welcome to change it and/or distribute copies of it under certain=20 > conditions. > > Type "show copying" to see the conditions. > > There is absolutely no warranty for GDB. Type "show warranty" for deta= ils. > > This GDB was configured as "i386-marcel-freebsd". > >=20 > > Unread portion of the kernel message buffer: > >=20 > >=20 > > Fatal trap 12: page fault while in kernel mode > > cpuid =3D 0; apic id =3D 00 > > fault virtual address =3D 0x34 > > fault code =3D supervisor read, page not present > > instruction pointer =3D 0x20:0xc07b6de4 > > stack pointer =3D 0x28:0xe79de7c8 > > frame pointer =3D 0x28:0xe79de7e8 > > code segment =3D base 0x0, limit 0xfffff, type 0x1b > > =3D DPL 0, pres 1, def32 1, gran 1 > > processor eflags =3D interrupt enabled, resume, IOPL =3D 0 > > current process =3D 1214 (opera) > > trap number =3D 12 > > panic: page fault > > cpuid =3D 0 > > Uptime: 5h20m30s > > Physical memory: 2035 MB > > Dumping 218 MB: 203 187 171 155 139 123 107 91 75 59 43 27 11 > >=20 > > #0 doadump () at pcpu.h:195 > > 195 __asm __volatile("movl %%fs:0,%0" : "=3Dr" (td)); > > (kgdb) list *0xc07b6de4 > > 0xc07b6de4 is in vfs_vmio_release (/usr/src/sys/kern/vfs_bio.c:1530). > > 1525 vfs_vmio_release(struct buf *bp) > > 1526 { > > 1527 int i; > > 1528 vm_page_t m; > > 1529 > > 1530 VM_OBJECT_LOCK(bp->b_bufobj->bo_object); > > 1531 vm_page_lock_queues(); > > 1532 for (i =3D 0; i < bp->b_npages; i++) { > > 1533 m =3D bp->b_pages[i]; > > 1534 bp->b_pages[i] =3D NULL; > > (kgdb) bt > > #0 doadump () at pcpu.h:195 > > #1 0xc0754457 in boot (howto=3D260) at /usr/src/sys/kern/kern_shutdown= =2Ec:409 > > #2 0xc0754719 in panic (fmt=3DVariable "fmt" is not available. > > ) at /usr/src/sys/kern/kern_shutdown.c:563 > > #3 0xc0a4905c in trap_fatal (frame=3D0xe79de788, eva=3D52)=20 > at /usr/src/sys/i386/i386/trap.c:899 > > #4 0xc0a492e0 in trap_pfault (frame=3D0xe79de788, usermode=3D0, eva=3D= 52)=20 > at /usr/src/sys/i386/i386/trap.c:812 > > #5 0xc0a49c8c in trap (frame=3D0xe79de788)=20 > at /usr/src/sys/i386/i386/trap.c:490 > > #6 0xc0a2fc0b in calltrap () at /usr/src/sys/i386/i386/exception.s:139 > > #7 0xc07b6de4 in vfs_vmio_release (bp=3D0xd927e33c)=20 > at /usr/src/sys/kern/vfs_bio.c:1530 > > #8 0xc07b8a81 in getnewbuf (slpflag=3D0, slptimeo=3D0, size=3DVariable= "size" is=20 > not available. > > ) at /usr/src/sys/kern/vfs_bio.c:1847 > > #9 0xc07ba118 in getblk (vp=3D0xc8891bb0, blkno=3D0, size=3D2048, slpf= lag=3D0,=20 > slptimeo=3D0, flags=3DVariable "flags" is not available. > > ) at /usr/src/sys/kern/vfs_bio.c:2602 > > #10 0xc0932815 in ffs_balloc_ufs2 (vp=3D0xc8891bb0,=20 > startoffset=3DVariable "startoffset" is not available. > > ) at /usr/src/sys/ufs/ffs/ffs_balloc.c:699 > > #11 0xc0952a85 in ffs_write (ap=3D0xe79debc4)=20 > at /usr/src/sys/ufs/ffs/ffs_vnops.c:720 > > #12 0xc0a5efc6 in VOP_WRITE_APV (vop=3D0xc0b93c60, a=3D0xe79debc4) at=20 > vnode_if.c:691 > > #13 0xc07dbf37 in vn_write (fp=3D0xc85f3168, uio=3D0xe79dec60,=20 > active_cred=3D0xc61c6300, flags=3D0, td=3D0xc583fc60) at vnode_if.h:373 > > #14 0xc07875e7 in dofilewrite (td=3D0xc583fc60, fd=3D17, fp=3D0xc85f316= 8,=20 > auio=3D0xe79dec60, offset=3D-1, flags=3D0) at file.h:254 > > #15 0xc07878c8 in kern_writev (td=3D0xc583fc60, fd=3D17, auio=3D0xe79de= c60)=20 > at /usr/src/sys/kern/sys_generic.c:401 > > #16 0xc078793f in write (td=3D0xc583fc60, uap=3D0xe79decfc)=20 > at /usr/src/sys/kern/sys_generic.c:317 > > #17 0xc0a49635 in syscall (frame=3D0xe79ded38)=20 > at /usr/src/sys/i386/i386/trap.c:1035 > > #18 0xc0a2fc70 in Xint0x80_syscall ()=20 > at /usr/src/sys/i386/i386/exception.s:196 > > #19 0x00000033 in ?? () > > Previous frame inner to this frame (corrupt stack?) >=20 > FYI, you got the panic in ffs/ufs, not fuse. I've seen this at work on 6= =2Ex=20 > with NFS with no clues on what causes it. You can start by going to fram= e 7=20 > and doing 'p *bp'. >=20 Thanks for the hints. See below for more debug output. I recognize that the bp struct members b_data and b_kvabase both point to a= chunk of memory containing the text of the Opera web page I was reading wh= en the kernel crashed. (This is indicated above: current process =3D 1214 (opera)) But what is most interesting is that b_bufobj =3D 0x0 Obviously, then trying to access bp->b_bufobj->bo_object will cause a crash. So I think it would be a good idea to NULL-check the struct member before t= rying to access it. How should I proceed? Should I post this as a possible bug somewhere else, = to another list? Regards, Johan Kuuse (kgdb) up 7 #7 0xc07b6de4 in vfs_vmio_release (bp=3D0xd927e33c) at /usr/src/sys/kern/v= fs_bio.c:1530 1530 VM_OBJECT_LOCK(bp->b_bufobj->bo_object); (kgdb) p *bp $1 =3D {b_bufobj =3D 0x0, b_bcount =3D 4156, b_caller1 =3D 0x0,=20 b_data =3D 0xe03d9000 "TILL\201=C4MPNING\n- Formulera en fr\201=E5gest\20= 1=E4llning eller arbetsuppgift.\n- L\201=E4s texten noga och lyft ut det so= m du anser \201=E4r ett queert l\201=E4ckage.\n Arbeta med mark\201=F6rer = s\201=E5som genus, sexualitet och makt.\n- F"..., b_error =3D -1, b_iocmd = =3D 2 '\002', b_ioflags =3D 0 '\0', b_iooffset =3D 0, b_resid =3D 1387, b_i= odone =3D 0, b_blkno =3D 0, b_offset =3D 0, b_bobufs =3D {tqe_next =3D 0x0,= tqe_prev =3D 0xc887da54}, b_left =3D 0x0,=20 b_right =3D 0x0, b_vflags =3D 0, b_freelist =3D {tqe_next =3D 0xd9363ea8,= tqe_prev =3D 0xc0be18e8}, b_qindex =3D 0, b_flags =3D 536879648, b_xflags = =3D 0 '\0', b_lock =3D {lk_object =3D {lo_name =3D 0xc0ada5df "bufwait",=20 lo_type =3D 0xc0ada5df "bufwait", lo_flags =3D 70844416, lo_witness_d= ata =3D {lod_list =3D {stqe_next =3D 0x0}, lod_witness =3D 0x0}}, lk_interl= ock =3D 0xc0bda1b8, lk_flags =3D 262144, lk_sharecount =3D 0, lk_waitcount = =3D 0,=20 lk_exclusivecount =3D 1, lk_prio =3D 80, lk_timo =3D 0, lk_lockholder = =3D 0xc583fc60, lk_newlock =3D 0x0}, b_bufsize =3D 4608, b_runningbufspace = =3D 0,=20 b_kvabase =3D 0xe03d9000 "TILL\201=C4MPNING\n- Formulera en fr\201=E5gest= \201=E4llning eller arbetsuppgift.\n- L\201=E4s texten noga och lyft ut det= som du anser \201=E4r ett queert l\201=E4ckage.\n Arbeta med mark\201=F6r= er s\201=E5som genus, sexualitet och makt.\n- F"..., b_kvasize =3D 65536, b= _lblkno =3D 0, b_vp =3D 0x0, b_dirtyoff =3D 0, b_dirtyend =3D 1387, b_rcred= =3D 0x0, b_wcred =3D 0xc61c6300, b_saveaddr =3D 0xe03d9000, b_pager =3D {p= g_reqpage =3D 0}, b_cluster =3D { cluster_head =3D {tqh_first =3D 0xd932fc48, tqh_last =3D 0xd9279a4c}, c= luster_entry =3D {tqe_next =3D 0xd932fc48, tqe_prev =3D 0xd9279a4c}}, b_pag= es =3D {0xc2b53bf8, 0xc2b72090, 0x0 }, b_npages =3D 2, b_= dep =3D { lh_first =3D 0x0}, b_fsprivate1 =3D 0x0, b_fsprivate2 =3D 0x0, b_fspriv= ate3 =3D 0x0, b_pin_count =3D 0} (kgdb) From owner-freebsd-stable@FreeBSD.ORG Tue Aug 12 07:28:46 2008 Return-Path: Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D4289106567F for ; Tue, 12 Aug 2008 07:28:46 +0000 (UTC) (envelope-from unga888@yahoo.com) Received: from web57013.mail.re3.yahoo.com (web57013.mail.re3.yahoo.com [66.196.97.117]) by mx1.freebsd.org (Postfix) with SMTP id 9A1788FC29 for ; Tue, 12 Aug 2008 07:28:46 +0000 (UTC) (envelope-from unga888@yahoo.com) Received: (qmail 81135 invoked by uid 60001); 12 Aug 2008 07:28:46 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Message-ID; b=cc6AhF9pWW7mEB49qGNdj1r21MQV3LH/z/ZJqXefvYq72gy1aKa2HUsTqBrjuy0eRsM4X74RArlLYhNqYsIdgK2rpvgtzu/XGD8YraXCjcetX+DrO7RDAUbmX9V4JJXQEiL6lCZn96knbHXU+aIrehWICoLtBeZEqdeBD3apj1c=; Received: from [220.255.7.207] by web57013.mail.re3.yahoo.com via HTTP; Tue, 12 Aug 2008 00:28:46 PDT X-Mailer: YahooMailWebService/0.7.218 Date: Tue, 12 Aug 2008 00:28:46 -0700 (PDT) From: Unga To: freebsd-stable@FreeBSD.ORG In-Reply-To: <200808081336.m78DaIoV018488@lurza.secnetix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <76940.80951.qm@web57013.mail.re3.yahoo.com> Cc: olli@lurza.secnetix.de Subject: Re: sysinstall compilation issue X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: unga888@yahoo.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2008 07:28:46 -0000 --- On Fri, 8/8/08, Oliver Fromme wrote: > From: Oliver Fromme > Subject: Re: sysinstall compilation issue > To: freebsd-stable@FreeBSD.ORG, unga888@yahoo.com > Date: Friday, August 8, 2008, 9:36 PM > Unga wrote: > > This is i386 RELENG_7. > > > > Following section of the > /usr/src/usr.sbin/sysinstall/Makefile does not generate C > code properly: > > > > makedevs.c: Makefile rtermcap > > echo '#include ' > > makedevs.c > > ${RTERMCAP} ansi | \ > > file2c 'const char termcap_ansi[] > = {' ',0};' \ > > > > makedevs.c > > > > At compile time, above expands to: > > > TERMCAP=/usr/src/usr.sbin/sysinstall/../../share/termcap/termcap.src > ./rtermcap ansi | file2c 'const char termcap_ansi[] = > {' ',0};' >> makedevs.c > > > > Which generates C code as follows: > > const char termcap_ansi[] = { > > > > ,0}; > > > > That is, it generates 3 lines, which results a > compilation error. > > > > I presume, intended generated code should be: > > const char termcap_ansi[] = {' ',0}; > > > > Am I right? > > No, it should generate an array containung a dump of > the "ansi" termcap entry. Please see the > file2c(1) > manpage. > > > What is wrong at my end? > > > > Note, I linked the rtermcap with ncursesw libraries, > can that be the cause? Any ideas? > > Yes, that's the cause. Why did you do that? > > FreeBSD's ncurses port contains a patch so the > tgetent() > function (which is used by rtermcap) returns the actual > termcap entry in the buffer. The original ncurses code > (which is terminfo based) doesn't do that. > > When you linked rtermcap with the wrong library, you > restored the original behaviour of tgetent(), so the > output of rtermcap was empty, so file2c produced invalid > source. > Sorry for my late reply on this. I was not well during weekend, an eye ache due to over work :( Here is the situation at my end, no matter whether I link with ncurses widec libs or non-widec libs, its still return the same code as above I mentioned. Possible causes can be: 1. The way I compile and install ncurses is not correct. 2. OR some essential files required are missing 3. OR there can be an other option I used truss as follows: TERMCAP=/usr/src/usr.sbin/sysinstall/../../share/termcap/termcap.src truss -o truss.log -f ./rtermcap ansi | file2c 'const char termcap_ansi[] = {' ',0};' >> makedevs.c The last few lines of truss.log shows: 9310: stat("/usr/share/misc/terminfo.db",{mode=-rw-r--r-- ,inode=22613331,size= 3170304,blksize=4096}) = 0 (0x0) 9310: open("/usr/share/misc/terminfo.db",O_RDONLY,0644) = 4 (0x4) 9310: fcntl(4,F_SETFD,FD_CLOEXEC) = 0 (0x0) 9310: read(4,"\0\^F\^Ua\0\0\0\^B\0\0\^D\M-R\0"...,260) = 260 (0x104) 9310: __sysctl(0xbfbfd574,0x2,0xbfbfd570,0xbfbfd57c,0x0,0x0) = 0 (0x0) 9310: lseek(4,0x132000,SEEK_SET) = 1253376 (0x132000) 9310: read(4,"\^^\0\M-|\^O\M-T\^O\M-K\^O\M-*"...,4096) = 4096 (0x1000) 9310: lseek(4,0x26b000,SEEK_SET) = 2535424 (0x26b000) 9310: read(4,"\n\0\M-Y\^O\^O\n\0\n\r\^D\^E\^D"...,4096) = 4096 (0x1000) 9310: close(4) = 0 (0x0) 9310: ioctl(2,TIOCGETA,0xbfbfdba4) = 0 (0x0) 9310: ioctl(2,TIOCGETA,0x81020d8) = 0 (0x0) 9310: ioctl(2,TIOCGETA,0xbfbfdb64) = 0 (0x0) 9310: ioctl(2,TIOCGWINSZ,0xbfbfdbc4) = 0 (0x0) 9310: fstat(1,{mode=p--------- ,inode=0,size=0,blksize=4096}) = 0 (0x0) 9310: process exit, rval = 0 Note, above log has no entry to open /usr/src/usr.sbin/sysinstall/../../share/termcap/termcap.src. So what can be the issue, ncurses has not been patched correctly or some essential files missing? If you guys think that ncurses has not been patched correctly, then I'll open another thread to discuss that. Best Regards Unga From owner-freebsd-stable@FreeBSD.ORG Tue Aug 12 08:04:37 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 753BA1065671 for ; Tue, 12 Aug 2008 08:04:37 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id 9B94A8FC0A for ; Tue, 12 Aug 2008 08:04:35 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au ([203.31.81.55]) (authenticated bits=0) by cain.gsoft.com.au (8.13.8/8.13.8) with ESMTP id m7C84WbW006933 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 12 Aug 2008 17:34:32 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-stable@freebsd.org Date: Tue, 12 Aug 2008 17:34:23 +0930 User-Agent: KMail/1.9.7 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1357107.YMVQxVzOJp"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200808121734.30144.doconnor@gsoft.com.au> X-Spam-Score: -3.977 () ALL_TRUSTED,BAYES_00 X-Scanned-By: MIMEDefang 2.63 on 203.31.81.10 Subject: 6.3 (ish) hang on reboot w/ Supermicro C2SBA+ X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2008 08:04:37 -0000 --nextPart1357107.YMVQxVzOJp Content-Type: multipart/mixed; boundary="Boundary-01=_IQUoIA6w8h9eSPc" Content-Transfer-Encoding: 7bit Content-Disposition: inline --Boundary-01=_IQUoIA6w8h9eSPc Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi, I have a 6.3 (RELENG_6 a bit past 6.3 actually) system which hangs when=20 I try and reboot (or shutdown). It has a Supermicro C2SBA+, 2ware=20 9650SE and Core2Duo CPU. It shuts down as normal except after printing the uptime it hangs solid.=20 Numlock does nothing (during the shutdown process & disk sync it=20 toggles OK). The disks are synced OK (comes up clean when I press the=20 reset switch) Waiting (max 60 seconds) for system process 'vnlru' to stop...done Waiting (max 60 seconds) for system process 'bufdaemon' to stop...done Waiting (max 60 seconds) for system process 'syncer' to stop... Syncing disks, vnodes remaining...6 5 2 3 0 1 0 0 0 done All buffers ynced. Swap device da0s1b removed. Uptime: 1m52s I have tried setting hw.acpi.disable_on_reboot and hw.acpi.handle_reboot=20 to no effect. I have attached a verbose dmesg. =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --Boundary-01=_IQUoIA6w8h9eSPc Content-Type: text/x-diff; charset="utf-8"; name="dmesg.boot" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="dmesg.boot" Features2=3D0xe39d AMD Features=3D0x20100800 AMD Features2=3D0x1 Cores per package: 2 real memory =3D 1062666240 (1013 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009cfff, 638976 bytes (156 pages) 0x0000000000bd4000 - 0x000000003d776fff, 1018834944 bytes (248739 pages) avail memory =3D 1013022720 (966 MB) APIC: CPU 0 has ACPI ID 0 MADT: Found IO APIC ID 2, Interrupt 0 at 0xfec00000 ioapic0: Routing external 8259A's -> intpin 0 lapic0: Routing NMI -> LINT1 lapic0: LINT1 trigger: edge lapic0: LINT1 polarity: high lapic1: Routing NMI -> LINT1 lapic1: LINT1 trigger: edge lapic1: LINT1 polarity: high MADT: Interrupt override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 MADT: Interrupt override: source 9, irq 9 ioapic0: intpin 9 trigger: level ioapic0 irqs 0-23 on motherboard cpu0 BSP: ID: 0x00000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00000200 err: 0x00010000 pcm: 0x00010000 ath_rate: version 1.2 wlan: <802.11 Link Layer> null: random: nfslock: pseudo-device kbd: new array size 4 kbd1 at kbdmux0 mem: io: ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) rr232x: RocketRAID 232x controller driver v1.02 (Nov 29 2007 10:59:53) acpi0: on motherboard ioapic0: routing intpin 9 (ISA IRQ 9) to vector 48 acpi0: [MPSAFE] pci_open(1): mode 1 addr port (0x0cf8) is 0x80000090 pci_open(1a): mode1res=3D0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=3D060000] [hdr=3D00] is there (id=3D29c08086) AcpiOsDerivePciId: \\_SB_.PCI0.IGD0.IGDP -> bus 0 dev 2 func 0 AcpiOsDerivePciId: \\_SB_.PCI0.LPC0.PIRX -> bus 0 dev 31 func 0 AcpiOsDerivePciId: \\_SB_.PCI0.LPC0.PIRY -> bus 0 dev 31 func 0 ACPI-0438: *** Error: Looking up [\\_SB_.PCI0.PSKB] in namespace, AE_NO= T_FOUND SearchNode 0xffffff0000c23100 StartNode 0xffffff0000c23100 ReturnNode 0 ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.LPC0.SIO_.KB= C0._STA] (Node 0xffffff0000c23100), AE_NOT_FOUND ACPI-0438: *** Error: Looking up [\\_SB_.PCI0.PSMS] in namespace, AE_NO= T_FOUND SearchNode 0xffffff0000c22d40 StartNode 0xffffff0000c22d40 ReturnNode 0 ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.LPC0.SIO_.MS= E0._STA] (Node 0xffffff0000c22d40), AE_NOT_FOUND acpi0: Power Button (fixed) AcpiOsDerivePciId: \\_SB_.PCI0.REGS -> bus 0 dev 0 func 0 AcpiOsDerivePciId: \\_SB_.PCI0.LPC0.REGS -> bus 0 dev 31 func 0 ACPI-0438: *** Error: Looking up [\\_SB_.PCI0.PSKB] in namespace, AE_NO= T_FOUND SearchNode 0xffffff0000c23100 StartNode 0xffffff0000c23100 ReturnNode 0 ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.LPC0.SIO_.KB= C0._STA] (Node 0xffffff0000c23100), AE_NOT_FOUND ACPI-0438: *** Error: Looking up [\\_SB_.PCI0.PSKB] in namespace, AE_NO= T_FOUND SearchNode 0xffffff0000c23100 StartNode 0xffffff0000c23100 ReturnNode 0 ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.LPC0.SIO_.KB= C0._STA] (Node 0xffffff0000c23100), AE_NOT_FOUND ACPI-0438: *** Error: Looking up [\\_SB_.PCI0.PSKB] in namespace, AE_NO= T_FOUND SearchNode 0xffffff0000c23100 StartNode 0xffffff0000c23100 ReturnNode 0 ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.LPC0.SIO_.KB= C0._STA] (Node 0xffffff0000c23100), AE_NOT_FOUND ACPI-0438: *** Error: Looking up [\\_SB_.PCI0.PSKB] in namespace, AE_NO= T_FOUND SearchNode 0xffffff0000c23100 StartNode 0xffffff0000c23100 ReturnNode 0 ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.LPC0.SIO_.KB= C0._STA] (Node 0xffffff0000c23100), AE_NOT_FOUND ACPI-0438: *** Error: Looking up [\\_SB_.PCI0.PSKB] in namespace, AE_NO= T_FOUND SearchNode 0xffffff0000c23100 StartNode 0xffffff0000c23100 ReturnNode 0 ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.LPC0.SIO_.KB= C0._STA] (Node 0xffffff0000c23100), AE_NOT_FOUND ACPI-0438: *** Error: Looking up [\\_SB_.PCI0.PSMS] in namespace, AE_NO= T_FOUND SearchNode 0xffffff0000c22d40 StartNode 0xffffff0000c22d40 ReturnNode 0 ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.LPC0.SIO_.MS= E0._STA] (Node 0xffffff0000c22d40), AE_NOT_FOUND ACPI-0438: *** Error: Looking up [\\_SB_.PCI0.PSMS] in namespace, AE_NO= T_FOUND SearchNode 0xffffff0000c22d40 StartNode 0xffffff0000c22d40 ReturnNode 0 ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.LPC0.SIO_.MS= E0._STA] (Node 0xffffff0000c22d40), AE_NOT_FOUND ACPI-0438: *** Error: Looking up [\\_SB_.PCI0.PSMS] in namespace, AE_NO= T_FOUND SearchNode 0xffffff0000c22d40 StartNode 0xffffff0000c22d40 ReturnNode 0 ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.LPC0.SIO_.MS= E0._STA] (Node 0xffffff0000c22d40), AE_NOT_FOUND ACPI-0438: *** Error: Looking up [\\_SB_.PCI0.PSMS] in namespace, AE_NO= T_FOUND SearchNode 0xffffff0000c22d40 StartNode 0xffffff0000c22d40 ReturnNode 0 ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.LPC0.SIO_.MS= E0._STA] (Node 0xffffff0000c22d40), AE_NOT_FOUND ACPI-0438: *** Error: Looking up [\\_SB_.PCI0.PSMS] in namespace, AE_NO= T_FOUND SearchNode 0xffffff0000c22d40 StartNode 0xffffff0000c22d40 ReturnNode 0 ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.LPC0.SIO_.MS= E0._STA] (Node 0xffffff0000c22d40), AE_NOT_FOUND ACPI-0438: *** Error: Looking up [\\_SB_.PCI0.PSKB] in namespace, AE_NO= T_FOUND SearchNode 0xffffff0000c23100 StartNode 0xffffff0000c23100 ReturnNode 0 ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.LPC0.SIO_.KB= C0._STA] (Node 0xffffff0000c23100), AE_NOT_FOUND ACPI-0438: *** Error: Looking up [\\_SB_.PCI0.PSKB] in namespace, AE_NO= T_FOUND SearchNode 0xffffff0000c23100 StartNode 0xffffff0000c23100 ReturnNode 0 ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.LPC0.SIO_.KB= C0._STA] (Node 0xffffff0000c23100), AE_NOT_FOUND ACPI-0438: *** Error: Looking up [\\_SB_.PCI0.PSMS] in namespace, AE_NO= T_FOUND SearchNode 0xffffff0000c22d40 StartNode 0xffffff0000c22d40 ReturnNode 0 ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.LPC0.SIO_.MS= E0._STA] (Node 0xffffff0000c22d40), AE_NOT_FOUND ACPI-0438: *** Error: Looking up [\\_SB_.PCI0.PSMS] in namespace, AE_NO= T_FOUND SearchNode 0xffffff0000c22d40 StartNode 0xffffff0000c22d40 ReturnNode 0 ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.LPC0.SIO_.MS= E0._STA] (Node 0xffffff0000c22d40), AE_NOT_FOUND ACPI timer: 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 -> 10 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 pci_link0: Index IRQ Rtd Ref IRQs Initial Probe 0 5 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 5 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link1: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 10 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link2: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 11 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link3: Index IRQ Rtd Ref IRQs Initial Probe 0 12 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 12 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link4: Index IRQ Rtd Ref IRQs Initial Probe 0 5 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 5 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link5: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 255 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link6: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 11 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link7: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 10 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 cpu0: on acpi0 cpu0: switching to generic Cx mode pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: physical bus=3D0 found-> vendor=3D0x8086, dev=3D0x29c0, revid=3D0x02 bus=3D0, slot=3D0, func=3D0 class=3D06-00-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0106, statreg=3D0x2090, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) found-> vendor=3D0x8086, dev=3D0x29c2, revid=3D0x02 bus=3D0, slot=3D2, func=3D0 class=3D03-00-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0007, statreg=3D0x0090, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) intpin=3Da, irq=3D5 powerspec 2 supports D0 D3 current D0 MSI supports 1 message map[10]: type 1, range 32, base d2400000, size 19, enabled map[14]: type 4, range 32, base 00001c60, size 3, enabled map[18]: type 3, range 32, base c0000000, size 28, enabled map[1c]: type 1, range 32, base d2000000, size 20, enabled pcib0: matched entry for 0.2.INTA pcib0: slot 2 INTA hardwired to IRQ 16 found-> vendor=3D0x8086, dev=3D0x10bd, revid=3D0x02 bus=3D0, slot=3D25, func=3D0 class=3D02-00-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0107, statreg=3D0x0010, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) intpin=3Da, irq=3D5 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type 1, range 32, base d2680000, size 17, enabled map[14]: type 1, range 32, base d26a4000, size 12, enabled map[18]: type 4, range 32, base 00001820, size 5, enabled pcib0: matched entry for 0.25.INTA pcib0: slot 25 INTA hardwired to IRQ 16 found-> vendor=3D0x8086, dev=3D0x2937, revid=3D0x02 bus=3D0, slot=3D26, func=3D0 class=3D0c-03-00, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x0005, statreg=3D0x0290, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) intpin=3Da, irq=3D5 map[20]: type 4, range 32, base 00001840, size 5, enabled pcib0: matched entry for 0.26.INTA pcib0: slot 26 INTA hardwired to IRQ 16 found-> vendor=3D0x8086, dev=3D0x2938, revid=3D0x02 bus=3D0, slot=3D26, func=3D1 class=3D0c-03-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0005, statreg=3D0x0290, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) intpin=3Db, irq=3D10 map[20]: type 4, range 32, base 00001860, size 5, enabled pcib0: matched entry for 0.26.INTB pcib0: slot 26 INTB hardwired to IRQ 17 found-> vendor=3D0x8086, dev=3D0x2939, revid=3D0x02 bus=3D0, slot=3D26, func=3D2 class=3D0c-03-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0005, statreg=3D0x0290, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) intpin=3Dc, irq=3D11 map[20]: type 4, range 32, base 00001880, size 5, enabled pcib0: matched entry for 0.26.INTC pcib0: slot 26 INTC hardwired to IRQ 18 found-> vendor=3D0x8086, dev=3D0x293c, revid=3D0x02 bus=3D0, slot=3D26, func=3D7 class=3D0c-03-20, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0106, statreg=3D0x0290, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) intpin=3Dc, irq=3D11 powerspec 2 supports D0 D3 current D0 map[10]: type 1, range 32, base d26a6000, size 10, enabled pcib0: matched entry for 0.26.INTC pcib0: slot 26 INTC hardwired to IRQ 18 found-> vendor=3D0x8086, dev=3D0x293e, revid=3D0x02 bus=3D0, slot=3D27, func=3D0 class=3D04-03-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0106, statreg=3D0x0010, cachelnsz=3D8 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) intpin=3Da, irq=3D10 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type 1, range 64, base d26a0000, size 14, enabled pcib0: matched entry for 0.27.INTA pcib0: slot 27 INTA hardwired to IRQ 16 found-> vendor=3D0x8086, dev=3D0x2940, revid=3D0x02 bus=3D0, slot=3D28, func=3D0 class=3D06-04-00, hdrtype=3D0x01, mfdev=3D1 cmdreg=3D0x0007, statreg=3D0x0010, cachelnsz=3D8 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x04 (1000 ns), maxlat=3D0x00 (0 ns) intpin=3Da, irq=3D5 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTA pcib0: slot 28 INTA hardwired to IRQ 16 found-> vendor=3D0x8086, dev=3D0x2948, revid=3D0x02 bus=3D0, slot=3D28, func=3D4 class=3D06-04-00, hdrtype=3D0x01, mfdev=3D1 cmdreg=3D0x0007, statreg=3D0x0010, cachelnsz=3D8 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x04 (1000 ns), maxlat=3D0x00 (0 ns) intpin=3Da, irq=3D5 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTA pcib0: slot 28 INTA hardwired to IRQ 16 found-> vendor=3D0x8086, dev=3D0x2934, revid=3D0x02 bus=3D0, slot=3D29, func=3D0 class=3D0c-03-00, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x0005, statreg=3D0x0290, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) intpin=3Da, irq=3D10 map[20]: type 4, range 32, base 000018a0, size 5, enabled pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 23 found-> vendor=3D0x8086, dev=3D0x2935, revid=3D0x02 bus=3D0, slot=3D29, func=3D1 class=3D0c-03-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0005, statreg=3D0x0290, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) intpin=3Db, irq=3D11 map[20]: type 4, range 32, base 000018c0, size 5, enabled pcib0: matched entry for 0.29.INTB pcib0: slot 29 INTB hardwired to IRQ 22 found-> vendor=3D0x8086, dev=3D0x2936, revid=3D0x02 bus=3D0, slot=3D29, func=3D2 class=3D0c-03-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0005, statreg=3D0x0290, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) intpin=3Dc, irq=3D11 map[20]: type 4, range 32, base 000018e0, size 5, enabled pcib0: matched entry for 0.29.INTC pcib0: slot 29 INTC hardwired to IRQ 18 found-> vendor=3D0x8086, dev=3D0x293a, revid=3D0x02 bus=3D0, slot=3D29, func=3D7 class=3D0c-03-20, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0106, statreg=3D0x0290, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) intpin=3Da, irq=3D10 powerspec 2 supports D0 D3 current D0 map[10]: type 1, range 32, base d26a6400, size 10, enabled pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 23 found-> vendor=3D0x8086, dev=3D0x244e, revid=3D0x92 bus=3D0, slot=3D30, func=3D0 class=3D06-04-01, hdrtype=3D0x01, mfdev=3D0 cmdreg=3D0x0107, statreg=3D0x0010, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x04 (1000 ns), maxlat=3D0x00 (0 ns) found-> vendor=3D0x8086, dev=3D0x2918, revid=3D0x02 bus=3D0, slot=3D31, func=3D0 class=3D06-01-00, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x0007, statreg=3D0x0210, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) found-> vendor=3D0x8086, dev=3D0x2921, revid=3D0x02 bus=3D0, slot=3D31, func=3D2 class=3D01-01-8f, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0007, statreg=3D0x02b0, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) intpin=3Db, irq=3D10 powerspec 3 supports D0 D3 current D0 map[10]: type 4, range 32, base 00001c78, size 3, enabled map[14]: type 4, range 32, base 00001c6c, size 2, enabled map[18]: type 4, range 32, base 00001c70, size 3, enabled map[1c]: type 4, range 32, base 00001c68, size 2, enabled map[20]: type 4, range 32, base 00001c30, size 4, enabled map[24]: type 4, range 32, base 00001c20, size 4, enabled pcib0: matched entry for 0.31.INTB pcib0: slot 31 INTB hardwired to IRQ 17 found-> vendor=3D0x8086, dev=3D0x2930, revid=3D0x02 bus=3D0, slot=3D31, func=3D3 class=3D0c-05-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0001, statreg=3D0x0280, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) intpin=3Db, irq=3D10 map[10]: type 1, range 64, base d26a6800, size 8, memory disabled map[20]: type 4, range 32, base 00001100, size 5, enabled pcib0: matched entry for 0.31.INTB pcib0: slot 31 INTB hardwired to IRQ 17 found-> vendor=3D0x8086, dev=3D0x2926, revid=3D0x02 bus=3D0, slot=3D31, func=3D5 class=3D01-01-85, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0007, statreg=3D0x02b0, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) intpin=3Dc, irq=3D11 powerspec 3 supports D0 D3 current D0 map[10]: type 4, range 32, base 00001c90, size 3, enabled map[14]: type 4, range 32, base 00001c84, size 2, enabled map[18]: type 4, range 32, base 00001c88, size 3, enabled map[1c]: type 4, range 32, base 00001c80, size 2, enabled map[20]: type 4, range 32, base 00001c50, size 4, enabled map[24]: type 4, range 32, base 00001c40, size 4, enabled pcib0: matched entry for 0.31.INTC pcib0: slot 31 INTC hardwired to IRQ 18 found-> vendor=3D0x8086, dev=3D0x2932, revid=3D0x02 bus=3D0, slot=3D31, func=3D6 class=3D11-80-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0002, statreg=3D0x0010, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) intpin=3Da, irq=3D5 powerspec 3 supports D0 D3 current D0 map[10]: type 1, range 64, base d26a5000, size 12, enabled pcib0: matched entry for 0.31.INTA pcib0: slot 31 INTA hardwired to IRQ 16 pci0: at device 2.0 (no driver attached) em0: port 0x1820-0x1= 83f mem 0xd2680000-0xd269ffff,0xd26a4000-0xd26a4fff irq 16 at device 25.0 o= n pci0 em0: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xd2680000 em0: Reserved 0x1000 bytes for rid 0x14 type 3 at 0xd26a4000 em0: bpf attached em0: Ethernet address: 00:30:48:b0:21:79 ioapic0: routing intpin 16 (PCI IRQ 16) to vector 49 em0: [MPSAFE] uhci0: port 0x1840-0x185f irq 16 at device = 26.0 on pci0 uhci0: Reserved 0x20 bytes for rid 0x20 type 4 at 0x1840 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: port 0x1860-0x187f irq 17 at device = 26.1 on pci0 uhci1: Reserved 0x20 bytes for rid 0x20 type 4 at 0x1860 ioapic0: routing intpin 17 (PCI IRQ 17) to vector 50 uhci1: [GIANT-LOCKED] usb1: on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0x1880-0x189f irq 18 at device = 26.2 on pci0 uhci2: Reserved 0x20 bytes for rid 0x20 type 4 at 0x1880 ioapic0: routing intpin 18 (PCI IRQ 18) to vector 51 uhci2: [GIANT-LOCKED] usb2: on uhci2 usb2: USB revision 1.0 uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered ehci0: mem 0xd26a6000-0xd26a63ff irq 18= at device 26.7 on pci0 ehci0: Reserved 0x400 bytes for rid 0x10 type 3 at 0xd26a6000 ehci0: [GIANT-LOCKED] usb3: EHCI version 1.0 usb3: companion controllers, 2 ports each: usb0 usb1 usb2 usb3: on ehci0 usb3: USB revision 2.0 uhub3: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub3: 6 ports with 6 removable, self powered pci0: at device 27.0 (no driver attached) pcib1: irq 16 at device 28.0 on pci0 pcib1: secondary bus 5 pcib1: subordinate bus 5 pcib1: I/O decode 0x2000-0x2fff pcib1: memory decode 0xd2100000-0xd21fffff pcib1: prefetched decode 0xd0000000-0xd1ffffff pci5: on pcib1 pci5: physical bus=3D5 found-> vendor=3D0x13c1, dev=3D0x1004, revid=3D0x01 bus=3D5, slot=3D0, func=3D0 class=3D01-04-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0107, statreg=3D0x0010, cachelnsz=3D8 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) intpin=3Da, irq=3D12 powerspec 2 supports D0 D1 D2 D3 current D0 MSI supports 32 messages, 64 bit map[10]: type 3, range 64, base d0000000, size 25, enabled pcib1: requested memory range 0xd0000000-0xd1ffffff: good map[18]: type 1, range 64, base d2101000, size 12, enabled pcib1: requested memory range 0xd2101000-0xd2101fff: good map[20]: type 4, range 32, base 00002000, size 8, enabled pcib1: requested I/O range 0x2000-0x20ff: in range pcib1: matched entry for 5.0.INTA pcib1: slot 0 INTA hardwired to IRQ 16 3ware device driver for 9000 series storage controllers, version: 3.60.04.0= 03 twa0: <3ware 9000 series Storage Controller> port 0x2000-0x20ff mem 0xd0000= 000-0xd1ffffff,0xd2101000-0xd2101fff irq 16 at device 0.0 on pci5 twa0: Reserved 0x1000 bytes for rid 0x18 type 3 at 0xd2101000 twa0: [GIANT-LOCKED] twa0: INFO: (0x04: 0x0001): Controller reset occurred: resets=3D3 twa0: INFO: (0x15: 0x1300): Controller details:: Model 9650SE-2LP, 2 ports,= Firmware FE9X 3.08.00.016, BIOS BE9X 3.08.00.004 pcib2: irq 16 at device 28.4 on pci0 pcib2: secondary bus 13 pcib2: subordinate bus 14 pcib2: I/O decode 0xf000-0xfff pcib2: memory decode 0xd2200000-0xd22fffff pcib2: prefetched decode 0xfff00000-0xfffff pci13: on pcib2 pci13: physical bus=3D13 found-> vendor=3D0x10b5, dev=3D0x8111, revid=3D0x21 bus=3D13, slot=3D0, func=3D0 class=3D06-04-00, hdrtype=3D0x01, mfdev=3D0 cmdreg=3D0x0117, statreg=3D0x0010, cachelnsz=3D8 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x04 (1000 ns), maxlat=3D0x00 (0 ns) intpin=3Da, irq=3D5 powerspec 2 supports D0 D1 D3 current D0 MSI supports 1 message, 64 bit pcib2: matched entry for 13.0.INTA pcib2: slot 0 INTA hardwired to IRQ 16 pcib3: irq 16 at device 0.0 on pci13 pcib3: secondary bus 14 pcib3: subordinate bus 14 pcib3: I/O decode 0xf000-0xfff pcib3: memory decode 0xd2200000-0xd22fffff pcib3: prefetched decode 0xfff00000-0xfffff pci14: on pcib3 pci14: physical bus=3D14 found-> vendor=3D0x1033, dev=3D0x00f2, revid=3D0x01 bus=3D14, slot=3D0, func=3D0 class=3D0c-00-10, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0116, statreg=3D0x0290, cachelnsz=3D8 (dwords) lattimer=3D0xa0 (4800 ns), mingnt=3D0x14 (5000 ns), maxlat=3D0x2c (11000 n= s) intpin=3Da, irq=3D5 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base d2200000, size 12, enabled pcib3: requested memory range 0xd2200000-0xd2200fff: good pcib2: requested memory range 0xd2200000-0xd2200fff: good pcib2: matched entry for 13.0.INTA pcib2: slot 0 INTA hardwired to IRQ 16 pcib3: slot 0 INTA is routed to irq 16 fwohci0: mem 0xd2200000-0xd2200fff irq 16 at device 0.0 on p= ci14 fwohci0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xd2200000 fwohci0: [MPSAFE] fwohci0: OHCI version 1.10 (ROM=3D1) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:00:4c:01:00:00:3f:ab fwohci0: Phy 1394a available S400, 3 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:00:4c:00:3f:ab fwe0: bpf attached fwe0: Ethernet address: 02:00:4c:00:3f:ab fwe0: if_start running deferred for Giant sbp0: on firewire0 fwohci0: Initiate bus reset fwohci0: BUS reset fwohci0: node_id=3D0xc800ffc0, gen=3D1, CYCLEMASTER mode firewire0: 1 nodes, maxhop <=3D 0, cable IRM =3D 0 (me) firewire0: bus manager 0 (me) uhci3: port 0x18a0-0x18bf irq 23 at device = 29.0 on pci0 uhci3: Reserved 0x20 bytes for rid 0x20 type 4 at 0x18a0 ioapic0: routing intpin 23 (PCI IRQ 23) to vector 52 uhci3: [GIANT-LOCKED] usb4: on uhci3 usb4: USB revision 1.0 uhub4: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub4: 2 ports with 2 removable, self powered uhci4: port 0x18c0-0x18df irq 22 at device = 29.1 on pci0 uhci4: Reserved 0x20 bytes for rid 0x20 type 4 at 0x18c0 ioapic0: routing intpin 22 (PCI IRQ 22) to vector 53 uhci4: [GIANT-LOCKED] usb5: on uhci4 usb5: USB revision 1.0 uhub5: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub5: 2 ports with 2 removable, self powered uhci5: port 0x18e0-0x18ff irq 18 at device = 29.2 on pci0 uhci5: Reserved 0x20 bytes for rid 0x20 type 4 at 0x18e0 uhci5: [GIANT-LOCKED] usb6: on uhci5 usb6: USB revision 1.0 uhub6: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub6: 2 ports with 2 removable, self powered ehci1: mem 0xd26a6400-0xd26a67ff irq 23= at device 29.7 on pci0 ehci1: Reserved 0x400 bytes for rid 0x10 type 3 at 0xd26a6400 ehci1: [GIANT-LOCKED] usb7: EHCI version 1.0 usb7: companion controllers, 2 ports each: usb4 usb5 usb6 usb7: on ehci1 usb7: USB revision 2.0 uhub7: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub7: 6 ports with 6 removable, self powered pcib4: at device 30.0 on pci0 pcib4: secondary bus 17 pcib4: subordinate bus 17 pcib4: I/O decode 0x3000-0x3fff pcib4: memory decode 0xd2300000-0xd23fffff pcib4: prefetched decode 0xfff00000-0xfffff pcib4: Subtractively decoded bridge. pci17: on pcib4 pci17: physical bus=3D17 found-> vendor=3D0x6666, dev=3D0x0004, revid=3D0x02 bus=3D17, slot=3D0, func=3D0 class=3D07-00-02, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0103, statreg=3D0x0280, cachelnsz=3D8 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) intpin=3Da, irq=3D5 map[10]: type 1, range 32, base d2300000, size 7, enabled pcib4: requested memory range 0xd2300000-0xd230007f: good map[14]: type 4, range 32, base 00003400, size 7, enabled pcib4: requested I/O range 0x3400-0x347f: in range map[1c]: type 4, range 32, base 00003000, size 8, enabled pcib4: requested I/O range 0x3000-0x30ff: in range pcib4: matched entry for 17.0.INTA pcib4: slot 0 INTA hardwired to IRQ 20 found-> vendor=3D0x1283, dev=3D0x8212, revid=3D0x13 bus=3D17, slot=3D4, func=3D0 class=3D01-80-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0007, statreg=3D0x0230, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x08 (2000 ns), maxlat=3D0x08 (2000 ns) intpin=3Da, irq=3D10 powerspec 2 supports D0 D3 current D0 map[10]: type 4, range 32, base 000034a0, size 3, enabled pcib4: requested I/O range 0x34a0-0x34a7: in range map[14]: type 4, range 32, base 00003494, size 2, enabled pcib4: requested I/O range 0x3494-0x3497: in range map[18]: type 4, range 32, base 00003498, size 3, enabled pcib4: requested I/O range 0x3498-0x349f: in range map[1c]: type 4, range 32, base 00003490, size 2, enabled pcib4: requested I/O range 0x3490-0x3493: in range map[20]: type 4, range 32, base 00003480, size 4, enabled pcib4: requested I/O range 0x3480-0x348f: in range pcib4: matched entry for 17.4.INTA pcib4: slot 4 INTA hardwired to IRQ 23 pci17: at device 0.0 (no driver attached) atapci0: port 0x34a0-0x34a7,0x3494-0x3497,= 0x3498-0x349f,0x3490-0x3493,0x3480-0x348f irq 23 at device 4.0 on pci17 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0x3480 atapci0: [MPSAFE] ata2: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x34a0 atapci0: Reserved 0x4 bytes for rid 0x14 type 4 at 0x3494 ata2: reset tp1 mask=3D03 ostat0=3D60 ostat1=3D70 ata2: stat0=3D0x20 err=3D0x20 lsb=3D0x20 msb=3D0x20 ata2: stat1=3D0x30 err=3D0x30 lsb=3D0x30 msb=3D0x30 ata2: reset tp2 stat0=3D20 stat1=3D30 devices=3D0x0 ata2: [MPSAFE] ata3: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0x3498 atapci0: Reserved 0x4 bytes for rid 0x1c type 4 at 0x3490 ata3: reset tp1 mask=3D03 ostat0=3D60 ostat1=3D70 ata3: stat0=3D0x20 err=3D0x20 lsb=3D0x20 msb=3D0x20 ata3: stat1=3D0x30 err=3D0x30 lsb=3D0x30 msb=3D0x30 ata3: reset tp2 stat0=3D20 stat1=3D30 devices=3D0x0 ata3: [MPSAFE] isab0: at device 31.0 on pci0 isa0: on isab0 atapci1: port 0x1c78-0x1c7f,0x1c6c-0x1c6f,0= x1c70-0x1c77,0x1c68-0x1c6b,0x1c30-0x1c3f,0x1c20-0x1c2f irq 17 at device 31.= 2 on pci0 atapci1: Reserved 0x10 bytes for rid 0x20 type 4 at 0x1c30 atapci1: [MPSAFE] ata4: on atapci1 atapci1: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1c78 atapci1: Reserved 0x4 bytes for rid 0x14 type 4 at 0x1c6c ata4: reset tp1 mask=3D03 ostat0=3D7f ostat1=3D7f ata4: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata4: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata4: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata4: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata4: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata4: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata4: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata4: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata4: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata4: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata4: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata4: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata4: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata4: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata4: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata4: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata4: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata4: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata4: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata4: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata4: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata4: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata4: stat1=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata4: reset tp2 stat0=3Dff stat1=3Dff devices=3D0x0 ata4: [MPSAFE] ata5: on atapci1 atapci1: Reserved 0x8 bytes for rid 0x18 type 4 at 0x1c70 atapci1: Reserved 0x4 bytes for rid 0x1c type 4 at 0x1c68 ata5: reset tp1 mask=3D03 ostat0=3D00 ostat1=3D00 ata5: stat0=3D0x00 err=3D0x01 lsb=3D0x14 msb=3D0xeb ata5: stat1=3D0x00 err=3D0x01 lsb=3D0x14 msb=3D0xeb ata5: reset tp2 stat0=3D00 stat1=3D00 devices=3D0xc ata5: [MPSAFE] pci0: at device 31.3 (no driver attached) atapci2: port 0x1c90-0x1c97,0x1c84-0x1c87,0= x1c88-0x1c8f,0x1c80-0x1c83,0x1c50-0x1c5f,0x1c40-0x1c4f irq 18 at device 31.= 5 on pci0 atapci2: Reserved 0x10 bytes for rid 0x20 type 4 at 0x1c50 atapci2: [MPSAFE] ata6: on atapci2 atapci2: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1c90 atapci2: Reserved 0x4 bytes for rid 0x14 type 4 at 0x1c84 ata6: reset tp1 mask=3D03 ostat0=3D7f ostat1=3D7f ata6: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata6: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata6: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata6: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata6: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata6: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata6: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata6: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata6: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata6: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata6: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata6: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata6: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata6: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata6: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata6: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata6: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata6: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata6: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata6: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata6: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata6: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata6: stat1=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata6: reset tp2 stat0=3Dff stat1=3Dff devices=3D0x0 ata6: [MPSAFE] ata7: on atapci2 atapci2: Reserved 0x8 bytes for rid 0x18 type 4 at 0x1c88 atapci2: Reserved 0x4 bytes for rid 0x1c type 4 at 0x1c80 ata7: reset tp1 mask=3D03 ostat0=3D7f ostat1=3D7f ata7: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata7: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata7: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata7: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata7: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata7: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata7: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata7: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata7: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata7: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata7: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata7: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata7: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata7: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata7: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata7: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata7: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata7: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata7: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata7: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata7: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata7: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata7: stat1=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata7: reset tp2 stat0=3Dff stat1=3Dff devices=3D0x0 ata7: [MPSAFE] pci0: at device 31.6 (no driver attached) acpi_button0: on acpi0 ACPI-0438: *** Error: Looking up [\\_SB_.PCI0.PSKB] in namespace, AE_NO= T_FOUND SearchNode 0xffffff0000c23100 StartNode 0xffffff0000c23100 ReturnNode 0 ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.LPC0.SIO_.KB= C0._STA] (Node 0xffffff0000c23100), AE_NOT_FOUND ACPI-0438: *** Error: Looking up [\\_SB_.PCI0.PSKB] in namespace, AE_NO= T_FOUND SearchNode 0xffffff0000c23100 StartNode 0xffffff0000c23100 ReturnNode 0 ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.LPC0.SIO_.KB= C0._STA] (Node 0xffffff0000c23100), AE_NOT_FOUND ACPI-0438: *** Error: Looking up [\\_SB_.PCI0.PSKB] in namespace, AE_NO= T_FOUND SearchNode 0xffffff0000c23100 StartNode 0xffffff0000c23100 ReturnNode 0 ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.LPC0.SIO_.KB= C0._STA] (Node 0xffffff0000c23100), AE_NOT_FOUND ACPI-0438: *** Error: Looking up [\\_SB_.PCI0.PSKB] in namespace, AE_NO= T_FOUND SearchNode 0xffffff0000c23100 StartNode 0xffffff0000c23100 ReturnNode 0 ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.LPC0.SIO_.KB= C0._STA] (Node 0xffffff0000c23100), AE_NOT_FOUND ACPI-0438: *** Error: Looking up [\\_SB_.PCI0.PSKB] in namespace, AE_NO= T_FOUND SearchNode 0xffffff0000c23100 StartNode 0xffffff0000c23100 ReturnNode 0 ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.LPC0.SIO_.KB= C0._STA] (Node 0xffffff0000c23100), AE_NOT_FOUND ACPI-0438: *** Error: Looking up [\\_SB_.PCI0.PSKB] in namespace, AE_NO= T_FOUND SearchNode 0xffffff0000c23100 StartNode 0xffffff0000c23100 ReturnNode 0 ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.LPC0.SIO_.KB= C0._STA] (Node 0xffffff0000c23100), AE_NOT_FOUND ACPI-0438: *** Error: Looking up [\\_SB_.PCI0.PSKB] in namespace, AE_NO= T_FOUND SearchNode 0xffffff0000c23100 StartNode 0xffffff0000c23100 ReturnNode 0 ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.LPC0.SIO_.KB= C0._STA] (Node 0xffffff0000c23100), AE_NOT_FOUND ACPI-0438: *** Error: Looking up [\\_SB_.PCI0.PSKB] in namespace, AE_NO= T_FOUND SearchNode 0xffffff0000c23100 StartNode 0xffffff0000c23100 ReturnNode 0 ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.LPC0.SIO_.KB= C0._STA] (Node 0xffffff0000c23100), AE_NOT_FOUND ACPI-0438: *** Error: Looking up [\\_SB_.PCI0.PSKB] in namespace, AE_NO= T_FOUND SearchNode 0xffffff0000c23100 StartNode 0xffffff0000c23100 ReturnNode 0 ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.LPC0.SIO_.KB= C0._STA] (Node 0xffffff0000c23100), AE_NOT_FOUND ACPI-0438: *** Error: Looking up [\\_SB_.PCI0.PSKB] in namespace, AE_NO= T_FOUND SearchNode 0xffffff0000c23100 StartNode 0xffffff0000c23100 ReturnNode 0 ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.LPC0.SIO_.KB= C0._STA] (Node 0xffffff0000c23100), AE_NOT_FOUND ACPI-0438: *** Error: Looking up [\\_SB_.PCI0.PSKB] in namespace, AE_NO= T_FOUND SearchNode 0xffffff0000c23100 StartNode 0xffffff0000c23100 ReturnNode 0 ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.LPC0.SIO_.KB= C0._STA] (Node 0xffffff0000c23100), AE_NOT_FOUND ACPI-0438: *** Error: Looking up [\\_SB_.PCI0.PSKB] in namespace, AE_NO= T_FOUND SearchNode 0xffffff0000c23100 StartNode 0xffffff0000c23100 ReturnNode 0 ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.LPC0.SIO_.KB= C0._STA] (Node 0xffffff0000c23100), AE_NOT_FOUND ACPI-0438: *** Error: Looking up [\\_SB_.PCI0.PSKB] in namespace, AE_NO= T_FOUND SearchNode 0xffffff0000c23100 StartNode 0xffffff0000c23100 ReturnNode 0 ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.LPC0.SIO_.KB= C0._STA] (Node 0xffffff0000c23100), AE_NOT_FOUND ACPI-0438: *** Error: Looking up [\\_SB_.PCI0.PSKB] in namespace, AE_NO= T_FOUND SearchNode 0xffffff0000c23100 StartNode 0xffffff0000c23100 ReturnNode 0 ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.LPC0.SIO_.KB= C0._STA] (Node 0xffffff0000c23100), AE_NOT_FOUND ACPI-0438: *** Error: Looking up [\\_SB_.PCI0.PSKB] in namespace, AE_NO= T_FOUND SearchNode 0xffffff0000c23100 StartNode 0xffffff0000c23100 ReturnNode 0 ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.LPC0.SIO_.KB= C0._STA] (Node 0xffffff0000c23100), AE_NOT_FOUND ACPI-0438: *** Error: Looking up [\\_SB_.PCI0.PSKB] in namespace, AE_NO= T_FOUND SearchNode 0xffffff0000c23100 StartNode 0xffffff0000c23100 ReturnNode 0 ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.LPC0.SIO_.KB= C0._STA] (Node 0xffffff0000c23100), AE_NOT_FOUND ACPI-0438: *** Error: Looking up [\\_SB_.PCI0.PSKB] in namespace, AE_NO= T_FOUND SearchNode 0xffffff0000c23100 StartNode 0xffffff0000c23100 ReturnNode 0 ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.LPC0.SIO_.KB= C0._STA] (Node 0xffffff0000c23100), AE_NOT_FOUND ACPI-0438: *** Error: Looking up [\\_SB_.PCI0.PSKB] in namespace, AE_NO= T_FOUND SearchNode 0xffffff0000c23100 StartNode 0xffffff0000c23100 ReturnNode 0 ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.LPC0.SIO_.KB= C0._STA] (Node 0xffffff0000c23100), AE_NOT_FOUND ACPI-0438: *** Error: Looking up [\\_SB_.PCI0.PSKB] in namespace, AE_NO= T_FOUND SearchNode 0xffffff0000c23100 StartNode 0xffffff0000c23100 ReturnNode 0 ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.LPC0.SIO_.KB= C0._STA] (Node 0xffffff0000c23100), AE_NOT_FOUND ACPI-0438: *** Error: Looking up [\\_SB_.PCI0.PSKB] in namespace, AE_NO= T_FOUND SearchNode 0xffffff0000c23100 StartNode 0xffffff0000c23100 ReturnNode 0 ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.LPC0.SIO_.KB= C0._STA] (Node 0xffffff0000c23100), AE_NOT_FOUND ACPI-0438: *** Error: Looking up [\\_SB_.PCI0.PSKB] in namespace, AE_NO= T_FOUND SearchNode 0xffffff0000c23100 StartNode 0xffffff0000c23100 ReturnNode 0 ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.LPC0.SIO_.KB= C0._STA] (Node 0xffffff0000c23100), AE_NOT_FOUND ACPI-0438: *** Error: Looking up [\\_SB_.PCI0.PSKB] in namespace, AE_NO= T_FOUND SearchNode 0xffffff0000c23100 StartNode 0xffffff0000c23100 ReturnNode 0 ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.LPC0.SIO_.KB= C0._STA] (Node 0xffffff0000c23100), AE_NOT_FOUND ACPI-0438: *** Error: Looking up [\\_SB_.PCI0.PSKB] in namespace, AE_NO= T_FOUND SearchNode 0xffffff0000c23100 StartNode 0xffffff0000c23100 ReturnNode 0 ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.LPC0.SIO_.KB= C0._STA] (Node 0xffffff0000c23100), AE_NOT_FOUND ACPI-0438: *** Error: Looking up [\\_SB_.PCI0.PSKB] in namespace, AE_NO= T_FOUND SearchNode 0xffffff0000c23100 StartNode 0xffffff0000c23100 ReturnNode 0 ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.LPC0.SIO_.KB= C0._STA] (Node 0xffffff0000c23100), AE_NOT_FOUND ACPI-0438: *** Error: Looking up [\\_SB_.PCI0.PSKB] in namespace, AE_NO= T_FOUND SearchNode 0xffffff0000c23100 StartNode 0xffffff0000c23100 ReturnNode 0 ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.LPC0.SIO_.KB= C0._STA] (Node 0xffffff0000c23100), AE_NOT_FOUND ACPI-0438: *** Error: Looking up [\\_SB_.PCI0.PSKB] in namespace, AE_NO= T_FOUND SearchNode 0xffffff0000c23100 StartNode 0xffffff0000c23100 ReturnNode 0 ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.LPC0.SIO_.KB= C0._STA] (Node 0xffffff0000c23100), AE_NOT_FOUND ACPI-0438: *** Error: Looking up [\\_SB_.PCI0.PSKB] in namespace, AE_NO= T_FOUND SearchNode 0xffffff0000c23100 StartNode 0xffffff0000c23100 ReturnNode 0 ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.LPC0.SIO_.KB= C0._STA] (Node 0xffffff0000c23100), AE_NOT_FOUND ACPI-0438: *** Error: Looking up [\\_SB_.PCI0.PSKB] in namespace, AE_NO= T_FOUND SearchNode 0xffffff0000c23100 StartNode 0xffffff0000c23100 ReturnNode 0 ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.LPC0.SIO_.KB= C0._STA] (Node 0xffffff0000c23100), AE_NOT_FOUND ACPI-0438: *** Error: Looking up [\\_SB_.PCI0.PSKB] in namespace, AE_NO= T_FOUND SearchNode 0xffffff0000c23100 StartNode 0xffffff0000c23100 ReturnNode 0 ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.LPC0.SIO_.KB= C0._STA] (Node 0xffffff0000c23100), AE_NOT_FOUND ACPI-0438: *** Error: Looking up [\\_SB_.PCI0.PSKB] in namespace, AE_NO= T_FOUND SearchNode 0xffffff0000c23100 StartNode 0xffffff0000c23100 ReturnNode 0 ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.LPC0.SIO_.KB= C0._STA] (Node 0xffffff0000c23100), AE_NOT_FOUND atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0067 atkbd: keyboard ID 0x41ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 ioapic0: routing intpin 1 (ISA IRQ 1) to vector 54 atkbd0: [GIANT-LOCKED] psm0: unable to allocate IRQ ACPI-0438: *** Error: Looking up [\\_SB_.PCI0.PSKB] in namespace, AE_NO= T_FOUND SearchNode 0xffffff0000c23100 StartNode 0xffffff0000c23100 ReturnNode 0 ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.LPC0.SIO_.KB= C0._STA] (Node 0xffffff0000c23100), AE_NOT_FOUND ACPI-0438: *** Error: Looking up [\\_SB_.PCI0.PSKB] in namespace, AE_NO= T_FOUND SearchNode 0xffffff0000c23100 StartNode 0xffffff0000c23100 ReturnNode 0 ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.LPC0.SIO_.KB= C0._STA] (Node 0xffffff0000c23100), AE_NOT_FOUND ACPI-0438: *** Error: Looking up [\\_SB_.PCI0.PSMS] in namespace, AE_NO= T_FOUND SearchNode 0xffffff0000c22d40 StartNode 0xffffff0000c22d40 ReturnNode 0 ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.LPC0.SIO_.MS= E0._STA] (Node 0xffffff0000c22d40), AE_NOT_FOUND ACPI-0438: *** Error: Looking up [\\_SB_.PCI0.PSMS] in namespace, AE_NO= T_FOUND SearchNode 0xffffff0000c22d40 StartNode 0xffffff0000c22d40 ReturnNode 0 ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.LPC0.SIO_.MS= E0._STA] (Node 0xffffff0000c22d40), AE_NOT_FOUND ACPI-0438: *** Error: Looking up [\\_SB_.PCI0.PSMS] in namespace, AE_NO= T_FOUND SearchNode 0xffffff0000c22d40 StartNode 0xffffff0000c22d40 ReturnNode 0 ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.LPC0.SIO_.MS= E0._STA] (Node 0xffffff0000c22d40), AE_NOT_FOUND ACPI-0438: *** Error: Looking up [\\_SB_.PCI0.PSMS] in namespace, AE_NO= T_FOUND SearchNode 0xffffff0000c22d40 StartNode 0xffffff0000c22d40 ReturnNode 0 ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.LPC0.SIO_.MS= E0._STA] (Node 0xffffff0000c22d40), AE_NOT_FOUND ACPI-0438: *** Error: Looking up [\\_SB_.PCI0.PSMS] in namespace, AE_NO= T_FOUND SearchNode 0xffffff0000c22d40 StartNode 0xffffff0000c22d40 ReturnNode 0 ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.LPC0.SIO_.MS= E0._STA] (Node 0xffffff0000c22d40), AE_NOT_FOUND ACPI-0438: *** Error: Looking up [\\_SB_.PCI0.PSMS] in namespace, AE_NO= T_FOUND SearchNode 0xffffff0000c22d40 StartNode 0xffffff0000c22d40 ReturnNode 0 ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.LPC0.SIO_.MS= E0._STA] (Node 0xffffff0000c22d40), AE_NOT_FOUND ACPI-0438: *** Error: Looking up [\\_SB_.PCI0.PSMS] in namespace, AE_NO= T_FOUND SearchNode 0xffffff0000c22d40 StartNode 0xffffff0000c22d40 ReturnNode 0 ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.LPC0.SIO_.MS= E0._STA] (Node 0xffffff0000c22d40), AE_NOT_FOUND ACPI-0438: *** Error: Looking up [\\_SB_.PCI0.PSMS] in namespace, AE_NO= T_FOUND SearchNode 0xffffff0000c22d40 StartNode 0xffffff0000c22d40 ReturnNode 0 ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.LPC0.SIO_.MS= E0._STA] (Node 0xffffff0000c22d40), AE_NOT_FOUND ACPI-0438: *** Error: Looking up [\\_SB_.PCI0.PSMS] in namespace, AE_NO= T_FOUND SearchNode 0xffffff0000c22d40 StartNode 0xffffff0000c22d40 ReturnNode 0 ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.LPC0.SIO_.MS= E0._STA] (Node 0xffffff0000c22d40), AE_NOT_FOUND ACPI-0438: *** Error: Looking up [\\_SB_.PCI0.PSMS] in namespace, AE_NO= T_FOUND SearchNode 0xffffff0000c22d40 StartNode 0xffffff0000c22d40 ReturnNode 0 ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.LPC0.SIO_.MS= E0._STA] (Node 0xffffff0000c22d40), AE_NOT_FOUND ACPI-0438: *** Error: Looking up [\\_SB_.PCI0.PSMS] in namespace, AE_NO= T_FOUND SearchNode 0xffffff0000c22d40 StartNode 0xffffff0000c22d40 ReturnNode 0 ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.LPC0.SIO_.MS= E0._STA] (Node 0xffffff0000c22d40), AE_NOT_FOUND ACPI-0438: *** Error: Looking up [\\_SB_.PCI0.PSMS] in namespace, AE_NO= T_FOUND SearchNode 0xffffff0000c22d40 StartNode 0xffffff0000c22d40 ReturnNode 0 ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.LPC0.SIO_.MS= E0._STA] (Node 0xffffff0000c22d40), AE_NOT_FOUND ACPI-0438: *** Error: Looking up [\\_SB_.PCI0.PSMS] in namespace, AE_NO= T_FOUND SearchNode 0xffffff0000c22d40 StartNode 0xffffff0000c22d40 ReturnNode 0 ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.LPC0.SIO_.MS= E0._STA] (Node 0xffffff0000c22d40), AE_NOT_FOUND ACPI-0438: *** Error: Looking up [\\_SB_.PCI0.PSMS] in namespace, AE_NO= T_FOUND SearchNode 0xffffff0000c22d40 StartNode 0xffffff0000c22d40 ReturnNode 0 ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.LPC0.SIO_.MS= E0._STA] (Node 0xffffff0000c22d40), AE_NOT_FOUND ACPI-0438: *** Error: Looking up [\\_SB_.PCI0.PSMS] in namespace, AE_NO= T_FOUND SearchNode 0xffffff0000c22d40 StartNode 0xffffff0000c22d40 ReturnNode 0 ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.LPC0.SIO_.MS= E0._STA] (Node 0xffffff0000c22d40), AE_NOT_FOUND ACPI-0438: *** Error: Looking up [\\_SB_.PCI0.PSMS] in namespace, AE_NO= T_FOUND SearchNode 0xffffff0000c22d40 StartNode 0xffffff0000c22d40 ReturnNode 0 ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.LPC0.SIO_.MS= E0._STA] (Node 0xffffff0000c22d40), AE_NOT_FOUND ACPI-0438: *** Error: Looking up [\\_SB_.PCI0.PSMS] in namespace, AE_NO= T_FOUND SearchNode 0xffffff0000c22d40 StartNode 0xffffff0000c22d40 ReturnNode 0 ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.LPC0.SIO_.MS= E0._STA] (Node 0xffffff0000c22d40), AE_NOT_FOUND ACPI-0438: *** Error: Looking up [\\_SB_.PCI0.PSMS] in namespace, AE_NO= T_FOUND SearchNode 0xffffff0000c22d40 StartNode 0xffffff0000c22d40 ReturnNode 0 ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.LPC0.SIO_.MS= E0._STA] (Node 0xffffff0000c22d40), AE_NOT_FOUND ACPI-0438: *** Error: Looking up [\\_SB_.PCI0.PSMS] in namespace, AE_NO= T_FOUND SearchNode 0xffffff0000c22d40 StartNode 0xffffff0000c22d40 ReturnNode 0 ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.LPC0.SIO_.MS= E0._STA] (Node 0xffffff0000c22d40), AE_NOT_FOUND ACPI-0438: *** Error: Looking up [\\_SB_.PCI0.PSMS] in namespace, AE_NO= T_FOUND SearchNode 0xffffff0000c22d40 StartNode 0xffffff0000c22d40 ReturnNode 0 ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.LPC0.SIO_.MS= E0._STA] (Node 0xffffff0000c22d40), AE_NOT_FOUND ACPI-0438: *** Error: Looking up [\\_SB_.PCI0.PSMS] in namespace, AE_NO= T_FOUND SearchNode 0xffffff0000c22d40 StartNode 0xffffff0000c22d40 ReturnNode 0 ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.LPC0.SIO_.MS= E0._STA] (Node 0xffffff0000c22d40), AE_NOT_FOUND ACPI-0438: *** Error: Looking up [\\_SB_.PCI0.PSMS] in namespace, AE_NO= T_FOUND SearchNode 0xffffff0000c22d40 StartNode 0xffffff0000c22d40 ReturnNode 0 ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.LPC0.SIO_.MS= E0._STA] (Node 0xffffff0000c22d40), AE_NOT_FOUND ACPI-0438: *** Error: Looking up [\\_SB_.PCI0.PSMS] in namespace, AE_NO= T_FOUND SearchNode 0xffffff0000c22d40 StartNode 0xffffff0000c22d40 ReturnNode 0 ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.LPC0.SIO_.MS= E0._STA] (Node 0xffffff0000c22d40), AE_NOT_FOUND ACPI-0438: *** Error: Looking up [\\_SB_.PCI0.PSMS] in namespace, AE_NO= T_FOUND SearchNode 0xffffff0000c22d40 StartNode 0xffffff0000c22d40 ReturnNode 0 ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.LPC0.SIO_.MS= E0._STA] (Node 0xffffff0000c22d40), AE_NOT_FOUND ACPI-0438: *** Error: Looking up [\\_SB_.PCI0.PSMS] in namespace, AE_NO= T_FOUND SearchNode 0xffffff0000c22d40 StartNode 0xffffff0000c22d40 ReturnNode 0 ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.LPC0.SIO_.MS= E0._STA] (Node 0xffffff0000c22d40), AE_NOT_FOUND ACPI-0438: *** Error: Looking up [\\_SB_.PCI0.PSMS] in namespace, AE_NO= T_FOUND SearchNode 0xffffff0000c22d40 StartNode 0xffffff0000c22d40 ReturnNode 0 ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.LPC0.SIO_.MS= E0._STA] (Node 0xffffff0000c22d40), AE_NOT_FOUND ACPI-0438: *** Error: Looking up [\\_SB_.PCI0.PSMS] in namespace, AE_NO= T_FOUND SearchNode 0xffffff0000c22d40 StartNode 0xffffff0000c22d40 ReturnNode 0 ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.LPC0.SIO_.MS= E0._STA] (Node 0xffffff0000c22d40), AE_NOT_FOUND ACPI-0438: *** Error: Looking up [\\_SB_.PCI0.PSMS] in namespace, AE_NO= T_FOUND SearchNode 0xffffff0000c22d40 StartNode 0xffffff0000c22d40 ReturnNode 0 ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.LPC0.SIO_.MS= E0._STA] (Node 0xffffff0000c22d40), AE_NOT_FOUND psmcpnp0: irq 12 on acpi0 psm0: current command byte:0067 psm0: failed to reset the aux device. ACPI-0438: *** Error: Looking up [\\_SB_.PCI0.PSMS] in namespace, AE_NO= T_FOUND SearchNode 0xffffff0000c22d40 StartNode 0xffffff0000c22d40 ReturnNode 0 ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.LPC0.SIO_.MS= E0._STA] (Node 0xffffff0000c22d40), AE_NOT_FOUND ACPI-0438: *** Error: Looking up [\\_SB_.PCI0.PSMS] in namespace, AE_NO= T_FOUND SearchNode 0xffffff0000c22d40 StartNode 0xffffff0000c22d40 ReturnNode 0 ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.LPC0.SIO_.MS= E0._STA] (Node 0xffffff0000c22d40), AE_NOT_FOUND sio0: irq maps: 0x1c21 0x1c31 0x1c21 0x1c21 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acp= i0 sio0: type 16550A ioapic0: routing intpin 4 (ISA IRQ 4) to vector 55 sio1: irq maps: 0x1c21 0x1c29 0x1c21 0x1c21 sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A ioapic0: routing intpin 3 (ISA IRQ 3) to vector 56 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: ic_type 90 part_id 80 ioapic0: routing intpin 6 (ISA IRQ 6) to vector 57 fdc0: [MPSAFE] fdc0: [FAST] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 ppc0: using extended I/O port range ppc0: ECP SPP ECP+EPP SPP ppc0: port 0x378-0x37f,0x778-0x77f irq 7 drq 3 = on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/9 bytes threshold ppbus0: on ppc0 plip0: on ppbus0 plip0: bpf attached lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 ioapic0: routing intpin 7 (ISA IRQ 7) to vector 58 ahc_isa_probe 1: ioport 0x1c00 alloc failed ex_isa_identify() atkbdc: atkbdc0 already exists; skipping it fdc: fdc0 already exists; skipping it ppc: ppc0 already exists; skipping it sio: sio0 already exists; skipping it sio: sio1 already exists; skipping it pnp_identify: Trying Read_Port at 203 pnp_identify: Trying Read_Port at 243 pnp_identify: Trying Read_Port at 283 pnp_identify: Trying Read_Port at 2c3 pnp_identify: Trying Read_Port at 303 pnp_identify: Trying Read_Port at 343 pnp_identify: Trying Read_Port at 383 pnp_identify: Trying Read_Port at 3c3 PNP Identify complete sc: sc0 already exists; skipping it vga: vga0 already exists; skipping it isa_probe_children: disabling PnP devices isa_probe_children: probing non-PnP devices orm0: at iomem 0xcb800-0xcd7ff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=3D0x300> sc0: fb0, kbd1, terminal emulator: sc (syscons terminal) sio2: not probed (disabled) sio3: not probed (disabled) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 isa_probe_children: probing PnP devices Device configuration finished. procfs registered linprocfs registered lapic: Divisor 2, Frequency 99750689 hz Timecounter "TSC" frequency 1995012960 Hz quality 800 Timecounters tick every 1.000 msec Linux ELF exec handler installed lo0: bpf attached rr232x: no controller detected. em0: Link is up 100 Mbps Full Duplex ata5: reiniting channel .. ata5: reset tp1 mask=3D03 ostat0=3D00 ostat1=3D00 ata5: stat0=3D0x00 err=3D0x01 lsb=3D0x14 msb=3D0xeb ata5: stat1=3D0x00 err=3D0x01 lsb=3D0x14 msb=3D0xeb ata5: reset tp2 stat0=3D00 stat1=3D00 devices=3D0xc ata5: reinit done .. ata5: reiniting channel .. ata5: reset tp1 mask=3D03 ostat0=3D00 ostat1=3D00 ata5: stat0=3D0x00 err=3D0x01 lsb=3D0x14 msb=3D0xeb ata5: stat1=3D0x00 err=3D0x01 lsb=3D0x14 msb=3D0xeb ata5: reset tp2 stat0=3D00 stat1=3D00 devices=3D0xc ata5: reinit done .. (probe1:twa0:0:1:0): error 22 (probe1:twa0:0:1:0): Unretryable Error (probe2:twa0:0:2:0): error 22 (probe2:twa0:0:2:0): Unretryable Error (probe3:twa0:0:3:0): error 22 (probe3:twa0:0:3:0): Unretryable Error (probe4:twa0:0:4:0): error 22 (probe4:twa0:0:4:0): Unretryable Error (probe5:twa0:0:5:0): error 22 (probe5:twa0:0:5:0): Unretryable Error (probe6:twa0:0:6:0): error 22 (probe6:twa0:0:6:0): Unretryable Error (probe7:twa0:0:7:0): error 22 (probe7:twa0:0:7:0): Unretryable Error (probe8:twa0:0:8:0): error 22 (probe8:twa0:0:8:0): Unretryable Error (probe9:twa0:0:9:0): error 22 (probe9:twa0:0:9:0): Unretryable Error (probe10:twa0:0:10:0): error 22 (probe10:twa0:0:10:0): Unretryable Error (probe11:twa0:0:11:0): error 22 (probe11:twa0:0:11:0): Unretryable Error (probe12:twa0:0:12:0): error 22 (probe12:twa0:0:12:0): Unretryable Error (probe13:twa0:0:13:0): error 22 (probe13:twa0:0:13:0): Unretryable Error (probe14:twa0:0:14:0): error 22 (probe14:twa0:0:14:0): Unretryable Error (probe15:twa0:0:15:0): error 22 (probe15:twa0:0:15:0): Unretryable Error (probe16:twa0:0:16:0): error 22 (probe16:twa0:0:16:0): Unretryable Error (probe17:twa0:0:17:0): error 22 (probe17:twa0:0:17:0): Unretryable Error (probe18:twa0:0:18:0): error 22 (probe18:twa0:0:18:0): Unretryable Error (probe19:twa0:0:19:0): error 22 (probe19:twa0:0:19:0): Unretryable Error (probe20:twa0:0:20:0): error 22 (probe20:twa0:0:20:0): Unretryable Error (probe21:twa0:0:21:0): error 22 (probe21:twa0:0:21:0): Unretryable Error (probe22:twa0:0:22:0): error 22 (probe22:twa0:0:22:0): Unretryable Error (probe23:twa0:0:23:0): error 22 (probe23:twa0:0:23:0): Unretryable Error (probe24:twa0:0:24:0): error 22 (probe24:twa0:0:24:0): Unretryable Error (probe25:twa0:0:25:0): error 22 (probe25:twa0:0:25:0): Unretryable Error (probe26:twa0:0:26:0): error 22 (probe26:twa0:0:26:0): Unretryable Error (probe27:twa0:0:27:0): error 22 (probe27:twa0:0:27:0): Unretryable Error (probe28:twa0:0:28:0): error 22 (probe28:twa0:0:28:0): Unretryable Error (probe29:twa0:0:29:0): error 22 (probe29:twa0:0:29:0): Unretryable Error (probe30:twa0:0:30:0): error 22 (probe30:twa0:0:30:0): Unretryable Error (probe31:twa0:0:31:0): error 22 (probe31:twa0:0:31:0): Unretryable Error ata5-master: pio=3DPIO4 wdma=3DWDMA2 udma=3DUDMA100 cable=3D40 wire (probe0:twa0:0:0:0): error 22 (probe0:twa0:0:0:0): Unretryable Error (probe0:twa0:0:0:1): error 22 (probe0:twa0:0:0:1): Unretryable Error (probe0:twa0:0:0:2): error 22 (probe0:twa0:0:0:2): Unretryable Error (probe0:twa0:0:0:3): error 22 (probe0:twa0:0:0:3): Unretryable Error (probe0:twa0:0:0:4): error 22 (probe0:twa0:0:0:4): Unretryable Error (probe0:twa0:0:0:5): error 22 (probe0:twa0:0:0:5): Unretryable Error (probe0:twa0:0:0:6): error 22 (probe0:twa0:0:0:6): Unretryable Error (probe0:twa0:0:0:7): error 22 (probe0:twa0:0:0:7): Unretryable Error acd0: DVDR drive at ata5 as master acd0: read 8268KB/s (8268KB/s) write 8269KB/s (8269KB/s), 2048KB buffer, SA= TA150 acd0: Reads: CDR, CDRW, CDDA stream, DVDROM, DVDR, DVDRAM, packet acd0: Writes: CDR, CDRW, DVDR, DVDRAM, test write, burnproof acd0: Audio: play, 256 volume levels acd0: Mechanism: ejectable tray, unlocked acd0: Medium: CD-ROM unknown (probe2:twa0:0:1:0): error 22 (probe2:twa0:0:1:0): Unretryable Error (probe3:twa0:0:2:0): error 22 (probe3:twa0:0:2:0): Unretryable Error (probe4:twa0:0:3:0): error 22 (probe4:twa0:0:3:0): Unretryable Error (probe5:twa0:0:4:0): error 22 (probe5:twa0:0:4:0): Unretryable Error (probe6:twa0:0:5:0): error 22 (probe6:twa0:0:5:0): Unretryable Error (probe7:twa0:0:6:0): error 22 (probe7:twa0:0:6:0): Unretryable Error (probe8:twa0:0:7:0): error 22 (probe8:twa0:0:7:0): Unretryable Error (probe9:twa0:0:8:0): error 22 (probe9:twa0:0:8:0): Unretryable Error (probe10:twa0:0:9:0): error 22 (probe10:twa0:0:9:0): Unretryable Error (probe11:twa0:0:10:0): error 22 (probe11:twa0:0:10:0): Unretryable Error (probe12:twa0:0:11:0): error 22 (probe12:twa0:0:11:0): Unretryable Error (probe13:twa0:0:12:0): error 22 (probe13:twa0:0:12:0): Unretryable Error (probe14:twa0:0:13:0): error 22 (probe14:twa0:0:13:0): Unretryable Error (probe15:twa0:0:14:0): error 22 (probe15:twa0:0:14:0): Unretryable Error (probe16:twa0:0:15:0): error 22 (probe16:twa0:0:15:0): Unretryable Error (probe17:twa0:0:16:0): error 22 (probe17:twa0:0:16:0): Unretryable Error (probe18:twa0:0:17:0): error 22 (probe18:twa0:0:17:0): Unretryable Error (probe19:twa0:0:18:0): error 22 (probe19:twa0:0:18:0): Unretryable Error (probe20:twa0:0:19:0): error 22 (probe20:twa0:0:19:0): Unretryable Error (probe21:twa0:0:20:0): error 22 (probe21:twa0:0:20:0): Unretryable Error (probe22:twa0:0:21:0): error 22 (probe22:twa0:0:21:0): Unretryable Error (probe23:twa0:0:22:0): error 22 (probe23:twa0:0:22:0): Unretryable Error (probe24:twa0:0:23:0): error 22 (probe24:twa0:0:23:0): Unretryable Error (probe25:twa0:0:24:0): error 22 (probe25:twa0:0:24:0): Unretryable Error (probe26:twa0:0:25:0): error 22 (probe26:twa0:0:25:0): Unretryable Error (probe27:twa0:0:26:0): error 22 (probe27:twa0:0:26:0): Unretryable Error (probe28:twa0:0:27:0): error 22 (probe28:twa0:0:27:0): Unretryable Error (probe29:twa0:0:28:0): error 22 (probe29:twa0:0:28:0): Unretryable Error (probe30:twa0:0:29:0): error 22 (probe30:twa0:0:29:0): Unretryable Error (probe31:twa0:0:30:0): error 22 (probe31:twa0:0:30:0): Unretryable Error (probe32:twa0:0:31:0): error 22 (probe32:twa0:0:31:0): Unretryable Error (probe1:twa0:0:0:0): error 22 (probe1:twa0:0:0:0): Unretryable Error (probe1:twa0:0:0:1): error 22 (probe1:twa0:0:0:1): Unretryable Error (probe1:twa0:0:0:2): error 22 (probe1:twa0:0:0:2): Unretryable Error (probe1:twa0:0:0:3): error 22 (probe1:twa0:0:0:3): Unretryable Error (probe1:twa0:0:0:4): error 22 (probe1:twa0:0:0:4): Unretryable Error (probe1:twa0:0:0:5): error 22 (probe1:twa0:0:0:5): Unretryable Error (probe1:twa0:0:0:6): error 22 (probe1:twa0:0:0:6): Unretryable Error (probe1:twa0:0:0:7): error 22 (probe1:twa0:0:0:7): Unretryable Error acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=3D0x24 ascq=3D0x00 sks=3D0x40 0= x00 0x01 (probe0:ata3:0:0:0): error 22 (probe0:ata3:0:0:0): Unretryable Error (probe0:ata3:0:0:0): error 16 (probe0:ata3:0:0:0): Unretryable Error acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=3D0x24 ascq=3D0x00 sks=3D0x40 0= x00 0x01 (probe0:ata3:0:0:0): error 22 (probe0:ata3:0:0:0): Unretryable Error (probe33:sbp0:0:0:0): error 22 (probe33:sbp0:0:0:0): Unretryable Error (probe34:sbp0:0:1:0): error 22 (probe34:sbp0:0:1:0): Unretryable Error (probe35:sbp0:0:2:0): error 22 (probe35:sbp0:0:2:0): Unretryable Error (probe36:sbp0:0:3:0): error 22 (probe36:sbp0:0:3:0): Unretryable Error (probe37:sbp0:0:4:0): error 22 (probe37:sbp0:0:4:0): Unretryable Error (probe38:sbp0:0:5:0): error 22 (probe38:sbp0:0:5:0): Unretryable Error (probe39:sbp0:0:6:0): error 22 (probe39:sbp0:0:6:0): Unretryable Error pass0 at twa0 bus 0 target 0 lun 0 pass0: Fixed Direct Access SCSI-5 device=20 pass0: Serial Number 87725170A1218F00DF9C pass0: 100.000MB/s transfers pass1 at ata3 bus 0 target 0 lun 0 pass1: Removable CD-ROM SCSI-0 device=20 pass1: 3.300MB/s transfers ATA PseudoRAID loaded da0 at twa0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-5 device=20 da0: Serial Number 87725170A1218F00DF9C da0: 100.000MB/s transfers da0: 476827MB (976541696 512 byte sectors: 255H 63S/T 60786C) (cd0:ata3:0:0:0): Retrying Command (cd0:ata3:0:0:0): error 6 (cd0:ata3:0:0:0): Unretryable Error cd0 at ata3 bus 0 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device=20 cd0: 3.300MB/s transfers cd0: Attempt to query device size failed: NOT READY, Medium not present GEOM: new disk cd0 GEOM: new disk da0 (cd0:ata3:0:0:0): error 6 (cd0:ata3:0:0:0): Unretryable Error (cd0:ata3:0:0:0): error 6 (cd0:ata3:0:0:0): Unretryable Error (cd0:ata3:0:0:0): error 6 (cd0:ata3:0:0:0): Unretryable Error Trying to mount root from ufs:/dev/da0s1a start_init: trying /sbin/init ACPI-0438: *** Error: Looking up [\\_SB_.PCI0.PSKB] in namespace, AE_NO= T_FOUND SearchNode 0xffffff0000c23100 StartNode 0xffffff0000c23100 ReturnNode 0 ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.LPC0.SIO_.KB= C0._STA] (Node 0xffffff0000c23100), AE_NOT_FOUND ACPI-0438: *** Error: Looking up [\\_SB_.PCI0.PSKB] in namespace, AE_NO= T_FOUND SearchNode 0xffffff0000c23100 StartNode 0xffffff0000c23100 ReturnNode 0 ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.LPC0.SIO_.KB= C0._STA] (Node 0xffffff0000c23100), AE_NOT_FOUND ACPI-0438: *** Error: Looking up [\\_SB_.PCI0.PSMS] in namespace, AE_NO= T_FOUND SearchNode 0xffffff0000c22d40 StartNode 0xffffff0000c22d40 ReturnNode 0 ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.LPC0.SIO_.MS= E0._STA] (Node 0xffffff0000c22d40), AE_NOT_FOUND ACPI-0438: *** Error: Looking up [\\_SB_.PCI0.PSMS] in namespace, AE_NO= T_FOUND SearchNode 0xffffff0000c22d40 StartNode 0xffffff0000c22d40 ReturnNode 0 ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.LPC0.SIO_.MS= E0._STA] (Node 0xffffff0000c22d40), AE_NOT_FOUND em0: Link is Down em0: Link is up 100 Mbps Full Duplex --Boundary-01=_IQUoIA6w8h9eSPc-- --nextPart1357107.YMVQxVzOJp Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iD8DBQBIoUQO5ZPcIHs/zowRAgpjAJ4ysmlBAZWROZ+1FbZxF/1yhTr/uACeOdoX okUTf+yGIax/JbK10uCXkTo= =MTaq -----END PGP SIGNATURE----- --nextPart1357107.YMVQxVzOJp-- From owner-freebsd-stable@FreeBSD.ORG Tue Aug 12 08:13:21 2008 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8EB061065672 for ; Tue, 12 Aug 2008 08:13:21 +0000 (UTC) (envelope-from mat@FreeBSD.org) Received: from plouf.absolight.net (plouf.absolight.net [79.143.240.136]) by mx1.freebsd.org (Postfix) with ESMTP id 552538FC0A for ; Tue, 12 Aug 2008 08:13:21 +0000 (UTC) (envelope-from mat@FreeBSD.org) Received: from atuin.in.mat.cc (ATuin.in.mat.cc [79.143.241.205]) by plouf.absolight.net (Postfix) with ESMTP id 1EEEC764007 for ; Tue, 12 Aug 2008 09:45:51 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by atuin.in.mat.cc (Postfix) with ESMTP id 82E7472EAE1 for ; Tue, 12 Aug 2008 09:45:50 +0200 (CEST) Date: Tue, 12 Aug 2008 09:45:48 +0200 From: Mathieu Arnold To: stable@freebsd.org Message-ID: <2D4221F0175C7261ECD00191@atuin.in.mat.cc> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========24C7F403A71FEEAD9299==========" Cc: Subject: neighbor discovery problem X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2008 08:13:21 -0000 --==========24C7F403A71FEEAD9299========== Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, Since I added IPv6 to my network, and started really using it, I'm seeing some strange things happening. For instance, I'm on machine 2a01:678:1:443::443, and I do : $ traceroute6 -n 2a01:678:100:2:: traceroute6 to 2a01:678:100:2:: (2a01:678:100:2::) from 2a01:678:1:443::443, 64 hops max, 12 byte packets 1 2a01:678:1:443:: 0.636 ms 0.602 ms 0.525 ms 2 2a01:678:1:443:: 2999.665 ms !A 2999.636 ms !A 2999.680 ms !A 2a01:678:1:443:: is it's default gateway, and is also directly connected to 2a01:678:100:2::, but it does not seem to be able to contact it. If I log onto the gateway, and I : $ ping6 -c 1 2a01:678:100:2:: PING6(56=40+8+8 bytes) 2a01:678:100:: --> 2a01:678:100:2:: 16 bytes from 2a01:678:100:2::, icmp_seq=0 hlim=64 time=1.146 ms --- 2a01:678:100:2:: ping6 statistics --- 1 packets transmitted, 1 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 1.146/1.146/1.146/0.000 ms It works, and now, I can : $ traceroute6 -n 2a01:678:100:2:: traceroute6 to 2a01:678:100:2:: (2a01:678:100:2::) from 2a01:678:1:443::443, 64 hops max, 12 byte packets 1 2a01:678:1:443:: 0.647 ms 0.671 ms 0.417 ms 2 2a01:678:100:2:: 0.852 ms 0.790 ms 0.669 ms Maybe I'm doing something wrong, but, well, I can't seem to find ou what. 2a01:678:1:443::443 is a 7.0 2a01:678:1:443:: is a 6.2 2a01:678:100:2:: is a 6.0 Those are not up to date to the latest thing you can get, but they're production machines, and I'm not really willing to upgrade them unless I really need to :-) -- Mathieu Arnold --==========24C7F403A71FEEAD9299========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAkihP60ACgkQJqR8av5thQ88ZwCgmBVmDbQz5DfXtJQr3EhoQjiO 2q4An1mt0Em7cBfOEueELq7k4WARh6Fl =Z5dv -----END PGP SIGNATURE----- --==========24C7F403A71FEEAD9299==========-- From owner-freebsd-stable@FreeBSD.ORG Tue Aug 12 08:34:03 2008 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E8E79106564A for ; Tue, 12 Aug 2008 08:34:03 +0000 (UTC) (envelope-from jdc@parodius.com) Received: from mx01.sc1.parodius.com (mx01.sc1.parodius.com [72.20.106.3]) by mx1.freebsd.org (Postfix) with ESMTP id D7E6A8FC15 for ; Tue, 12 Aug 2008 08:34:03 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id C3C641CC0C2; Tue, 12 Aug 2008 01:34:03 -0700 (PDT) Date: Tue, 12 Aug 2008 01:34:03 -0700 From: Jeremy Chadwick To: Mathieu Arnold Message-ID: <20080812083403.GA2150@eos.sc1.parodius.com> References: <2D4221F0175C7261ECD00191@atuin.in.mat.cc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2D4221F0175C7261ECD00191@atuin.in.mat.cc> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: stable@freebsd.org Subject: Re: neighbor discovery problem X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2008 08:34:04 -0000 On Tue, Aug 12, 2008 at 09:45:48AM +0200, Mathieu Arnold wrote: > Since I added IPv6 to my network, and started really using it, I'm seeing > some strange things happening. > > For instance, I'm on machine 2a01:678:1:443::443, and I do : > > $ traceroute6 -n 2a01:678:100:2:: > traceroute6 to 2a01:678:100:2:: (2a01:678:100:2::) from > 2a01:678:1:443::443, 64 hops max, 12 byte packets > 1 2a01:678:1:443:: 0.636 ms 0.602 ms 0.525 ms > 2 2a01:678:1:443:: 2999.665 ms !A 2999.636 ms !A 2999.680 ms !A > > 2a01:678:1:443:: is it's default gateway, and is also directly connected to > 2a01:678:100:2::, but it does not seem to be able to contact it. > > If I log onto the gateway, and I : > > $ ping6 -c 1 2a01:678:100:2:: > PING6(56=40+8+8 bytes) 2a01:678:100:: --> 2a01:678:100:2:: > 16 bytes from 2a01:678:100:2::, icmp_seq=0 hlim=64 time=1.146 ms > > --- 2a01:678:100:2:: ping6 statistics --- > 1 packets transmitted, 1 packets received, 0.0% packet loss > round-trip min/avg/max/std-dev = 1.146/1.146/1.146/0.000 ms > > It works, and now, I can : > $ traceroute6 -n 2a01:678:100:2:: > traceroute6 to 2a01:678:100:2:: (2a01:678:100:2::) from > 2a01:678:1:443::443, 64 hops max, 12 byte packets > 1 2a01:678:1:443:: 0.647 ms 0.671 ms 0.417 ms > 2 2a01:678:100:2:: 0.852 ms 0.790 ms 0.669 ms > > Maybe I'm doing something wrong, but, well, I can't seem to find ou what. > > 2a01:678:1:443::443 is a 7.0 > 2a01:678:1:443:: is a 6.2 > 2a01:678:100:2:: is a 6.0 > > Those are not up to date to the latest thing you can get, but they're > production machines, and I'm not really willing to upgrade them unless I > really need to :-) Important note: I know absolutely nothing about IPv6. Do you have ACLs on any of these machines? !A in traceroute commonly means there's an ACL blocking said packets: !A (communication with destination network administratively prohibited) A ping from the other host might cause a stateful firewall to begin allowing said traffic to/from the machine which previously wasn't working. If you use a firewall on these machines (ipfw, pf, etc.), I'd recommend posting your problem to the freebsd-pf list instead. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Tue Aug 12 08:36:30 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B8B021065676 for ; Tue, 12 Aug 2008 08:36:30 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.239]) by mx1.freebsd.org (Postfix) with ESMTP id 6A1908FC17 for ; Tue, 12 Aug 2008 08:36:30 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: by wr-out-0506.google.com with SMTP id c8so958228wra.27 for ; Tue, 12 Aug 2008 01:36:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=wXiHGW5C0grJN0HadFeUpMRHLFXsWZp6tPWirX6PF2s=; b=Dsx/TEdLZ+8qOOUVqk7HWDM1aHvaOZtB97QWc8GtjjQ+wRWZ974h1SUoMdzCPTtGjS Iyf6imO6EF1utNJLH4jrO56v2f1b2JsGjgcw7gO7RNXlFzk6NwBVImeOf9hl551vyb8d byIGZPL6GYoyibSG+HPjrxKHcLW8eIumpbBdg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=MBDzgxYBiTYYj9JQAFLZm1pU5C1WvBMhlT12egS62gHk72FoqzdGU3ymYwKafpF6j2 jzOVAo6HE+zXpD9JSNM/4LR59VHeOmJdyEZfDKTcPnDoHOA4hECHEqs+Z66zWdeAqh56 CNtn1dAdO1xLqX9iysZMDBWMSh6JV3QAhHDbU= Received: by 10.90.102.15 with SMTP id z15mr4733446agb.58.1218530189585; Tue, 12 Aug 2008 01:36:29 -0700 (PDT) Received: by 10.90.81.10 with HTTP; Tue, 12 Aug 2008 01:36:29 -0700 (PDT) Message-ID: Date: Tue, 12 Aug 2008 12:36:29 +0400 From: pluknet To: "John Baldwin" In-Reply-To: <200808111315.23879.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: base64 Content-Disposition: inline References: <20080730113449.GD407@cdnetworks.co.kr> <200808111128.50840.jhb@freebsd.org> <200808111315.23879.jhb@freebsd.org> Cc: freebsd-stable@freebsd.org, Ulrich Spoerlein Subject: Re: cpufreq(4) panic on RELENG_7 (was: Re: Call for bfe(4) testers.) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2008 08:36:30 -0000 MjAwOC84LzExIEpvaG4gQmFsZHdpbiA8amhiQGZyZWVic2Qub3JnPjoKPiBPbiBNb25kYXkgMTEg QXVndXN0IDIwMDggMTI6MzU6MTcgcG0gcGx1a25ldCB3cm90ZToKPj4gMjAwOC84LzExIEpvaG4g QmFsZHdpbiA8amhiQGZyZWVic2Qub3JnPjoKPj4gPiBPbiBTYXR1cmRheSAwOSBBdWd1c3QgMjAw OCAwNzoxNjozNyBhbSBVbHJpY2ggU3BvZXJsZWluIHdyb3RlOgo+PiA+PiBIaSBKb2huLAo+PiA+ Pgo+PiA+PiBJIG5vdyBmaWd1cmVkIG91dCB0aGUgIndobyIsIHRoZSAid2h5IiBzdGlsbCBlbHVk ZXMgbWUuCj4+ID4+Cj4+ID4+IFNvLCBhZnRlciB5b3VyIE1GQyBvZiBpY2hzcy5jIG9uIEp1bmUg Mjd0aCB0aGUgZGV2aWNlIG5vdyBhdHRhY2hlcyBhdCBteQo+PiA+PiBsYXB0b3AuIEl0IGRpZG4n dCBiZWZvcmUsIHNvIGl0IGNvdWxkIGNhdXNlIG5vIHRyb3VibGUuCj4+ID4+Cj4+ID4+IFdpdGgg aWNoc3MgbG9hZGVkLCB0aGUga2VybmVsIHdpbGwgcGFuaWMgMS0zIG1pbnV0ZXMgYWZ0ZXIgcG93 ZXJkIGhhcwo+PiA+PiBiZWVuIHN0YXJ0ZWQgKGlmIEkga2lsbCBwb3dlcmQgZWFybHkgZW5vdWdo LCBpdCBzZWVtcyBwcmV0dHkgc3RhYmxlKS4KPj4gPj4KPj4gPj4gSSdtIG5vdyBydW5uaW5nIGEg a2VybmVsIGZyb20gMjAwOC0wOC0wOCB3aXRoCj4+ID4+IGhpbnQuaWNoc3MuMC5kaXNhYmxlZD0i MSIKPj4gPgo+PiA+IE9rLiAgQ2FuIHlvdSBnZXQgYSBjcmFzaGR1bXAgZnJvbSBhIGNyYXNoPwo+ PiA+Cj4+Cj4+IGVobSwuIEkgYW0gbm90IFVscmljaCBTcG9lcmxlaW4sIGJ1dCBJIGNhbiBoZWxw IHdpdGggdGhpcyBpc3N1ZS4KPj4KPj4gbXkgY3Jhc2hkdW1wIGZyb20ga2dkYiBhbmQgc29tZSBk ZWJ1ZyBpbmZvLgo+PiAob3VjaCwgSSBmb3Jnb3QgdG8gaW5jbHVkZSBpdCBpbiBteSBwcmV2LiBt YWlsCj4+IGh0dHA6Ly9saXN0cy5mcmVlYnNkLm9yZy9waXBlcm1haWwvZnJlZWJzZC1zdGFibGUv MjAwOC1BdWd1c3QvMDQ0MTgyLmh0bWwgKQo+Pgo+PiB3YnIsCj4+IHBsdWtuZXQKPj4KPj4gVW5y ZWFkIHBvcnRpb24gb2YgdGhlIGtlcm5lbCBtZXNzYWdlIGJ1ZmZlcjoKPj4KPj4KPj4gRmF0YWwg dHJhcCAxMjogcGFnZSBmYXVsdCB3aGlsZSBpbiBrZXJuZWwgbW9kZQo+PiBmYXVsdCB2aXJ0dWFs IGFkZHJlc3MgICA9IDB4MzgKPj4gZmF1bHQgY29kZSAgICAgICAgICAgICAgPSBzdXBlcnZpc29y IHJlYWQsIHBhZ2Ugbm90IHByZXNlbnQKPj4gaW5zdHJ1Y3Rpb24gcG9pbnRlciAgICAgPSAweDIw OjB4YzA1NmNmNDYKPj4gc3RhY2sgcG9pbnRlciAgICAgICAgICAgPSAweDI4OjB4ZTY1OTJhYzgK Pj4gZnJhbWUgcG9pbnRlciAgICAgICAgICAgPSAweDI4OjB4ZTY1OTJhYzgKPj4gY29kZSBzZWdt ZW50ICAgICAgICAgICAgPSBiYXNlIDB4MCwgbGltaXQgMHhmZmZmZiwgdHlwZSAweDFiCj4+ICAg ICAgICAgICAgICAgICAgICAgICAgID0gRFBMIDAsIHByZXMgMSwgZGVmMzIgMSwgZ3JhbiAxCj4+ IHByb2Nlc3NvciBlZmxhZ3MgICAgICAgID0gaW50ZXJydXB0IGVuYWJsZWQsIHJlc3VtZSwgSU9Q TCA9IDAKPj4gY3VycmVudCBwcm9jZXNzICAgICAgICAgPSAyNTA3IChwb3dlcmQpCj4+IFBoeXNp Y2FsIG1lbW9yeTogMTAxNCBNQgo+PiBEdW1waW5nIDEyMCBNQjogMTA1IDg5IDczIDU3IDQxIDI1 IDkKPj4KPj4gIzAgIGRvYWR1bXAgKCkgYXQgcGNwdS5oOjE5NQo+PiAxOTUgICAgIHBjcHUuaDog Tm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeS4KPj4gICAgICAgICBpbiBwY3B1LmgKPj4gKGtnZGIp IGJ0Cj4+ICMwICBkb2FkdW1wICgpIGF0IHBjcHUuaDoxOTUKPj4gIzEgIDB4YzA0NThmODkgaW4g ZGJfZm5jYWxsIChkdW1teTE9LTEwMTAwMjc2NDgsIGR1bW15Mj0wLCBkdW1teTM9MCwKPj4gICAg IGR1bW15ND0weGU2NTkyODYwICIwrMrDIikgYXQgL21lZGlhL3NyYy03L3N5cy9kZGIvZGJfY29t bWFuZC5jOjUxNgo+PiAjMiAgMHhjMDQ1OTUzYSBpbiBkYl9jb21tYW5kIChsYXN0X2NtZHA9MHhj MDdkY2YxNCwgY21kX3RhYmxlPTB4MCwKPiBkb3BhZ2VyPTEpCj4+ICAgICBhdCAvbWVkaWEvc3Jj LTcvc3lzL2RkYi9kYl9jb21tYW5kLmM6NDEzCj4+ICMzICAweGMwNDU5NjU1IGluIGRiX2NvbW1h bmRfbG9vcCAoKQo+IGF0IC9tZWRpYS9zcmMtNy9zeXMvZGRiL2RiX2NvbW1hbmQuYzo0NjYKPj4g IzQgIDB4YzA0NWIxN2MgaW4gZGJfdHJhcCAodHlwZT0xMiwgY29kZT0wKQo+PiAgICAgYXQgL21l ZGlhL3NyYy03L3N5cy9kZGIvZGJfbWFpbi5jOjIyOAo+PiAjNSAgMHhjMDU3NTAyMyBpbiBrZGJf dHJhcCAodHlwZT0xMiwgY29kZT0wLCB0Zj0weGU2NTkyYTg4KQo+PiAgICAgYXQgL21lZGlhL3Ny Yy03L3N5cy9rZXJuL3N1YnJfa2RiLmM6NTI0Cj4+ICM2ICAweGMwNzQ2MGJmIGluIHRyYXBfZmF0 YWwgKGZyYW1lPTB4ZTY1OTJhODgsIGV2YT01NikKPj4gICAgIGF0IC9tZWRpYS9zcmMtNy9zeXMv aTM4Ni9pMzg2L3RyYXAuYzo4OTAKPj4gIzcgIDB4YzA3NDYzNmIgaW4gdHJhcF9wZmF1bHQgKGZy YW1lPTB4ZTY1OTJhODgsIHVzZXJtb2RlPTAsIGV2YT01NikKPj4gICAgIGF0IC9tZWRpYS9zcmMt Ny9zeXMvaTM4Ni9pMzg2L3RyYXAuYzo4MTIKPj4gIzggIDB4YzA3NDZkMzYgaW4gdHJhcCAoZnJh bWU9MHhlNjU5MmE4OCkKPj4gICAgIGF0IC9tZWRpYS9zcmMtNy9zeXMvaTM4Ni9pMzg2L3RyYXAu Yzo0OTAKPj4gIzkgIDB4YzA3MmZkNGIgaW4gY2FsbHRyYXAgKCkgYXQgL21lZGlhL3NyYy03L3N5 cy9pMzg2L2kzODYvZXhjZXB0aW9uLnM6MTM5Cj4+ICMxMCAweGMwNTZjZjQ2IGluIGRldmljZV9p c19hdHRhY2hlZCAoZGV2PTB4MCkKPj4gICAgIGF0IC9tZWRpYS9zcmMtNy9zeXMva2Vybi9zdWJy X2J1cy5jOjIyMjgKPj4gIzExIDB4YzA1MTJkZTcgaW4gY2Zfc2V0X21ldGhvZCAoZGV2PTB4YzNj OWM4ODAsIGxldmVsPTB4YzQ1MjVlZjQsCj4+ICAgICBwcmlvcml0eT0xMDApIGF0IC9tZWRpYS9z cmMtNy9zeXMva2Vybi9rZXJuX2NwdS5jOjMzMgo+PiAjMTIgMHhjMDUxMTQ1MiBpbiBjcHVmcmVx X2N1cnJfc3lzY3RsIChvaWRwPTB4YzNjOGJhYzAsIGFyZzE9MHhjM2JjN2MwMCwKPj4gICAgIGFy ZzI9MCwgcmVxPTB4ZTY1OTJiYTQpIGF0IGNwdWZyZXFfaWYuaDozMgo+PiAtLS1UeXBlIDxyZXR1 cm4+IHRvIGNvbnRpbnVlLCBvciBxIDxyZXR1cm4+IHRvIHF1aXQtLS0KPj4gIzEzIDB4YzA1NTRi NjcgaW4gc3lzY3RsX3Jvb3QgKG9pZHA9VmFyaWFibGUgIm9pZHAiIGlzIG5vdCBhdmFpbGFibGUu Cj4+ICkKPj4gICAgIGF0IC9tZWRpYS9zcmMtNy9zeXMva2Vybi9rZXJuX3N5c2N0bC5jOjEzMDYK Pj4gIzE0IDB4YzA1NTRjZDEgaW4gdXNlcmxhbmRfc3lzY3RsICh0ZD0weGM0MjQ1NDQwLCBuYW1l PTB4ZTY1OTJjMTQsCj4gbmFtZWxlbj00LAo+PiAgICAgb2xkPTB4MCwgb2xkbGVucD0weDAsIGlu a2VybmVsPTAsIG5ldz0weGJmYmZlN2M0LCBuZXdsZW49NCwKPj4gICAgIHJldHZhbD0weGU2NTky YzEwLCBmbGFncz0wKSBhdCAvbWVkaWEvc3JjLTcvc3lzL2tlcm4va2Vybl9zeXNjdGwuYzoxNDAx Cj4+ICMxNSAweGMwNTU1YTdjIGluIF9fc3lzY3RsICh0ZD0weGM0MjQ1NDQwLCB1YXA9MHhlNjU5 MmNmYykKPj4gICAgIGF0IC9tZWRpYS9zcmMtNy9zeXMva2Vybi9rZXJuX3N5c2N0bC5jOjEzMzYK Pj4gIzE2IDB4YzA3NDY2ZDUgaW4gc3lzY2FsbCAoZnJhbWU9MHhlNjU5MmQzOCkKPj4gICAgIGF0 IC9tZWRpYS9zcmMtNy9zeXMvaTM4Ni9pMzg2L3RyYXAuYzoxMDM1Cj4+ICMxNyAweGMwNzJmZGIw IGluIFhpbnQweDgwX3N5c2NhbGwgKCkKPj4gICAgIGF0IC9tZWRpYS9zcmMtNy9zeXMvaTM4Ni9p Mzg2L2V4Y2VwdGlvbi5zOjE5Ngo+PiAjMTggMHgwMDAwMDAzMyBpbiA/PyAoKQo+PiBQcmV2aW91 cyBmcmFtZSBpbm5lciB0byB0aGlzIGZyYW1lIChjb3JydXB0IHN0YWNrPykKPj4gKGtnZGIpIGYg MTEKPj4gIzExIDB4YzA1MTJkZTcgaW4gY2Zfc2V0X21ldGhvZCAoZGV2PTB4YzNjOWM4ODAsIGxl dmVsPTB4YzQ1MjVlZjQsCj4+ICAgICBwcmlvcml0eT0xMDApIGF0IC9tZWRpYS9zcmMtNy9zeXMv a2Vybi9rZXJuX2NwdS5jOjMzMgo+PiAzMzIgICAgICAgICAgICAgICAgICAgICBpZiAoIWRldmlj ZV9pc19hdHRhY2hlZChzZXQtPmRldikpIHsKPj4gKGtnZGIpIGxpc3QKPj4gMzI3ICAgICAgICAg ICAgIH0KPj4gMzI4Cj4+IDMyOSAgICAgICAgICAgICAvKiBOZXh0LCBzZXQgYW55L2FsbCByZWxh dGl2ZSBmcmVxdWVuY2llcyB2aWEgdGhlaXIgZHJpdmVycy4KPiAqLwo+PiAzMzAgICAgICAgICAg ICAgZm9yIChpID0gMDsgaSA8IGxldmVsLT5yZWxfY291bnQ7IGkrKykgewo+PiAzMzEgICAgICAg ICAgICAgICAgICAgICBzZXQgPSAmbGV2ZWwtPnJlbF9zZXRbaV07Cj4+IDMzMiAgICAgICAgICAg ICAgICAgICAgIGlmICghZGV2aWNlX2lzX2F0dGFjaGVkKHNldC0+ZGV2KSkgewo+PiAzMzMgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIGVycm9yID0gRU5YSU87Cj4+IDMzNCAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgZ290byBvdXQ7Cj4+IDMzNSAgICAgICAgICAgICAgICAgICAgIH0K Pj4gMzM2Cj4+IChrZ2RiKSBwIGxldmVsLnJlbF9jb3VudAo+PiAkMSA9IDE5ODYzNTYyNzEKPj4g KGtnZGIpIHAgaQo+PiAkMiA9IDAKPj4gKGtnZGIpIHAgbGV2ZWwucmVsX3NldAo+PiAkMyA9IHt7 ZnJlcSA9IDAsIHZvbHRzID0gMCwgcG93ZXIgPSAwLCBsYXQgPSAwLCBkZXYgPSAweDAsIHNwZWMg PSB7MCwgMCwgMCwKPj4gICAgICAgMH19LCB7ZnJlcSA9IDAsIHZvbHRzID0gMCwgcG93ZXIgPSAw LCBsYXQgPSAwLCBkZXYgPSAweDAsIHNwZWMgPSB7MCwKPiAwLAo+PiAgICAgICAwLCAwfX0sIHtm cmVxID0gMCwgdm9sdHMgPSAwLCBwb3dlciA9IDAsIGxhdCA9IDAsIGRldiA9IDB4MCwgc3BlYyA9 Cj4gezAsCj4+ICAgICAgIDAsIDAsIDB9fSwge2ZyZXEgPSAwLCB2b2x0cyA9IDAsIHBvd2VyID0g MCwgbGF0ID0gMCwgZGV2ID0gMHgwLCBzcGVjID0KPiB7Cj4+ICAgICAgIDAsIDAsIDAsIDB9fSwg e2ZyZXEgPSAwLCB2b2x0cyA9IDAsIHBvd2VyID0gMCwgbGF0ID0gMCwgZGV2ID0gMHgwLAo+PiAg ICAgc3BlYyA9IHswLCAwLCAwLCAwfX0sIHtmcmVxID0gMCwgdm9sdHMgPSAwLCBwb3dlciA9IDAs IGxhdCA9IDAsCj4+ICAgICBkZXYgPSAweDY1NmU3NTUyLCBzcGVjID0gezgyODg1ODcwMSwgMTE2 Mjc2MDAxNCwgMCwgMTM0NjMyNDkyfX0sIHsKPj4gICAgIGZyZXEgPSAwLCB2b2x0cyA9IDUzLCBw b3dlciA9IC0xMDI0LCBsYXQgPSAtMSwgZGV2ID0gMHg3ZmZmZmZmZiwgc3BlYyA9Cj4gewo+PiAt LS0tLSBhbmQgc28gb24tLS0tLQo+Pgo+PiBBbHNvIHRoZXJlIGFyZSB2ZXJ5IHVudXN1YWwgKGFu ZCBoaWdoKSBudW1iZXJzIGluIHN5c2N0bAo+IGRldi5jcHUuMC5mcmVxX2xldmVscy4KPgo+IFdo aWNoIGNwdWZyZXEgZHJpdmVycyBhcmUgeW91IHVzaW5nPyAgQ2FuIHlvdSBuYXJyb3cgZG93biB5 b3VyIHBhbmljcyAoYW5kCj4gd2VpcmQgZnJlcXVlbmNpZXMgaW4gdGhlIHN5c2N0bCkgdG8gYmVp bmcgY2F1c2VkIGJ5IGEgc3BlY2lmaWMgY3B1ZnJlcQo+IGRyaXZlcj8KClRoZXkgYXJlIGVzdC9w NHRjYy9pY2hzcy4KaGludC5pY2hzcy4wLmRpc2JsZWQ9IjEiIGhlbHBlZCBtZSB0byBhdm9pZCBw YW5pY3MgYW5kIHRob3NlIHdlaXJlZApmcmVxcyBpbiBkZXYuY3B1LgpOb3cgaXQgc2hvd3M6CmNw dTA6IDxBQ1BJIENQVT4gb24gYWNwaTAKZXN0MDogPEVuaGFuY2VkIFNwZWVkU3RlcCBGcmVxdWVu Y3kgQ29udHJvbD4gb24gY3B1MApwNHRjYzA6IDxDUFUgRnJlcXVlbmN5IFRoZXJtYWwgQ29udHJv bD4gb24gY3B1MAphbmQgZGV2LmNwdS4wLmZyZXFfbGV2ZWxzIGFyZSBhcyBleHBlY3RlZCAoYW5k IGFzIGl0IHdhcyBlYXJsaWVyCmJlZm9yZSB0aGlzIHByb2JsZW0pOgogMTYwMC8tMSAxNDAwLy0x IDEyMjUvLTEgMTIwMC8tMSAxMDUwLy0xIDEwMDAvLTEgODc1Ly0xIDgwMC8tMSA3MDAvLTEKNjAw Ly0xIDUyNS8tMSA0NTAvLTEgMzc1Ly0xIDMwMC8tMSAyMjUvLTEgMTUwLy0xIDc1Ly0xCgp3YnIs CnBsdWtuZXQK From owner-freebsd-stable@FreeBSD.ORG Tue Aug 12 10:16:53 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 475AE1065680 for ; Tue, 12 Aug 2008 10:16:53 +0000 (UTC) (envelope-from BORJAMAR@SARENET.ES) Received: from proxypop2.sarenet.es (proxypop2.sarenet.es [194.30.0.95]) by mx1.freebsd.org (Postfix) with ESMTP id 05C848FC23 for ; Tue, 12 Aug 2008 10:16:52 +0000 (UTC) (envelope-from BORJAMAR@SARENET.ES) Received: from [127.0.0.1] (matahari.sarenet.es [192.148.167.18]) by proxypop2.sarenet.es (Postfix) with ESMTP id 52DA7730C4; Tue, 12 Aug 2008 12:16:50 +0200 (CEST) Message-Id: <0296197A-28ED-4DAA-A31F-C28471E864FB@SARENET.ES> From: Borja Marcos To: Ivan Voras In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v928.1) Date: Tue, 12 Aug 2008 12:17:05 +0200 References: <43EC06E9-76B3-4AA1-BC5E-4E1BD64AFC2D@SARENET.ES> X-Mailer: Apple Mail (2.928.1) Cc: freebsd-stable@freebsd.org Subject: Re: umtxn and Apache 2.2 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2008 10:16:53 -0000 On Aug 12, 2008, at 12:12 AM, Ivan Voras wrote: > Borja Marcos wrote: >> Hello, >> I'm running a server with FreeBSD 7-STABLE as of August 8, Apache >> 2.2 with mpm/worker and threads support, and PHP 5.2.6. >> Everything works like a charm, but I see that Apache is leaking >> processes that get stuck in umtxn state. > > I run Apache 2.2 with worker MPM but without mod_php (I use PHP as > FastCGI) on many servers and I don't have such problems. Maybe it's > PHP's fault? (I agree you need a trace with debugging symbols). May me my fault. It's a system that I didn't use to administrate. I upgraded it from 6.2-REL to 7-STABLE in place, and recompiled packages. But there was a lot of litter. I'm just wondering if that could be a problem. Just in case I've done a thorough cleanup, recompiled needed ports, and included debugging support in Apache. Let's see what happens. And please accept my apologies if this has been a silly false alarm :) Thank you very much, Borja. From owner-freebsd-stable@FreeBSD.ORG Tue Aug 12 10:20:53 2008 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 666281065699 for ; Tue, 12 Aug 2008 10:20:53 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 3E6B78FC40 for ; Tue, 12 Aug 2008 10:20:53 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 63D9646CA3; Tue, 12 Aug 2008 06:20:52 -0400 (EDT) Date: Tue, 12 Aug 2008 11:20:52 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Mike Tancsa In-Reply-To: <200808120059.m7C0xvUH028011@lava.sentex.ca> Message-ID: References: <200808120059.m7C0xvUH028011@lava.sentex.ca> User-Agent: Alpine 1.10 (BSF 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: stable@freebsd.org Subject: Re: HEADS UP: inpcb/inpcbinfo rwlocking: coming to a 7-STABLE branch near you X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2008 10:20:53 -0000 On Mon, 11 Aug 2008, Mike Tancsa wrote: > At 05:21 PM 8/8/2008, Robert Watson wrote: > >> http://www.watson.org/~robert/freebsd/netperf/20080808-7stable-rwlock-inpcb.diff >> >> These incude the inpcb/inpcbinfo read/write locking changes (although not >> yet for raw/divert sockets). Any testing, especially with heavy UDP loads, >> would be much appreciated -- this are fairly complex changes, and also >> quite a complex MFC. > > So far so good with the patches. I am running them on a busy sendmail > server that also does a lot of DNS locally for itself and a number of other > boxes. Excellent news. I have a couple of other reviews and hopefully some more testing coming in, and will commit in a few days if all continues to go well. An updated version of the patch is here: http://www.watson.org/~robert/freebsd/netperf/20080811-7stable-rwlock-inpcb.diff There are no changes from previous versions, but I was asked to regenerate the patch with function names, so have done so. Anyone out there running name servers, NFS over UDP, and other UDP workloads: your testing of this patch prior to commit would be much appreciated. Thanks, Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-stable@FreeBSD.ORG Tue Aug 12 10:28:56 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 31873106564A; Tue, 12 Aug 2008 10:28:56 +0000 (UTC) (envelope-from jdc@parodius.com) Received: from mx01.sc1.parodius.com (mx01.sc1.parodius.com [72.20.106.3]) by mx1.freebsd.org (Postfix) with ESMTP id 21FA28FC0A; Tue, 12 Aug 2008 10:28:56 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id 0B3411CC096; Tue, 12 Aug 2008 03:28:56 -0700 (PDT) Date: Tue, 12 Aug 2008 03:28:56 -0700 From: Jeremy Chadwick To: Borja Marcos Message-ID: <20080812102856.GA6735@eos.sc1.parodius.com> References: <43EC06E9-76B3-4AA1-BC5E-4E1BD64AFC2D@SARENET.ES> <0296197A-28ED-4DAA-A31F-C28471E864FB@SARENET.ES> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0296197A-28ED-4DAA-A31F-C28471E864FB@SARENET.ES> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-stable@freebsd.org, Ivan Voras Subject: Re: umtxn and Apache 2.2 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2008 10:28:56 -0000 On Tue, Aug 12, 2008 at 12:17:05PM +0200, Borja Marcos wrote: > > On Aug 12, 2008, at 12:12 AM, Ivan Voras wrote: > >> Borja Marcos wrote: >>> Hello, >>> I'm running a server with FreeBSD 7-STABLE as of August 8, Apache >>> 2.2 with mpm/worker and threads support, and PHP 5.2.6. >>> Everything works like a charm, but I see that Apache is leaking >>> processes that get stuck in umtxn state. >> >> I run Apache 2.2 with worker MPM but without mod_php (I use PHP as >> FastCGI) on many servers and I don't have such problems. Maybe it's >> PHP's fault? (I agree you need a trace with debugging symbols). > > May me my fault. It's a system that I didn't use to administrate. I > upgraded it from 6.2-REL to 7-STABLE in place, and recompiled packages. > But there was a lot of litter. I'm just wondering if that could be a > problem. > > Just in case I've done a thorough cleanup, recompiled needed ports, and > included debugging support in Apache. Let's see what happens. > > And please accept my apologies if this has been a silly false alarm :) Please be sure to report back with the outcome (in a few days, or whenever suits you) -- I've seen a report of similar oddities (threads locking up) on the suPHP mailing list, when using Apache with the worker MPM. No one stated what state the process is in (re: umtxn), so I'm not sure if it's the same issue as what you've seen. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Tue Aug 12 10:52:35 2008 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2A51C106564A for ; Tue, 12 Aug 2008 10:52:35 +0000 (UTC) (envelope-from mh@kernel32.de) Received: from crivens.kernel32.de (crivens.terrorteam.de [81.169.171.191]) by mx1.freebsd.org (Postfix) with ESMTP id E86C98FC08 for ; Tue, 12 Aug 2008 10:52:34 +0000 (UTC) (envelope-from mh@kernel32.de) Received: from www.terrorteam.de (localhost [127.0.0.1]) by crivens.kernel32.de (Postfix) with ESMTP id CBE78B0297 for ; Tue, 12 Aug 2008 12:37:15 +0200 (CEST) MIME-Version: 1.0 Date: Tue, 12 Aug 2008 12:37:15 +0200 From: Marian Hettwer To: stable@freebsd.org Message-ID: X-Sender: mh@kernel32.de User-Agent: RoundCube Webmail/0.1-rc2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Cc: Subject: lagg(4) and failover X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2008 10:52:35 -0000 Hi Folks, I'm using lagg(4) on some of our servers and I'm just wondering how the failover is implemented. The manpage isn't quite clear: failover Sends and receives traffic only through the master port. If the master port becomes unavailable, the next active port is used. The first interface added is the master port; any interfaces added after that are used as failover devices. What is meant by "becomes unavailable"? Is it just the physical link which needs to become unavailable to trigger a failover? I do wonder, because there might be other faults where the link is still active, but the port is unusable. Think of a wrong vlan on the switch itself. When using bonding under Linux (yeah, I know, the configuration sucks ;) ), I can configure the device to check for arp respones of it's default gateway. If arp to the default gw becomes unavailable, bonding fails over to the next interface and tries it luck over there. With that kind of configuration, I could cover a misconfigured switch port and still have failover. Long Story short: How is failover in lagg(4) implemented? Thanks for any hints :) Or should I ask the OpenBSD boys, since lagg(4) seems to be a port of trunk(4)?? :) best regards, Marian From owner-freebsd-stable@FreeBSD.ORG Tue Aug 12 10:55:56 2008 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 99653106564A for ; Tue, 12 Aug 2008 10:55:56 +0000 (UTC) (envelope-from eugen@kuzbass.ru) Received: from www.svzserv.kemerovo.su (www.svzserv.kemerovo.su [213.184.65.80]) by mx1.freebsd.org (Postfix) with ESMTP id EFE558FC13 for ; Tue, 12 Aug 2008 10:55:55 +0000 (UTC) (envelope-from eugen@kuzbass.ru) Received: from www.svzserv.kemerovo.su (eugen@localhost [127.0.0.1]) by www.svzserv.kemerovo.su (8.13.8/8.13.8) with ESMTP id m7CAtqn5090007; Tue, 12 Aug 2008 18:55:52 +0800 (KRAST) (envelope-from eugen@www.svzserv.kemerovo.su) Received: (from eugen@localhost) by www.svzserv.kemerovo.su (8.13.8/8.13.8/Submit) id m7CAtqJJ090006; Tue, 12 Aug 2008 18:55:52 +0800 (KRAST) (envelope-from eugen) Date: Tue, 12 Aug 2008 18:55:52 +0800 From: Eugene Grosbein To: Marian Hettwer Message-ID: <20080812105552.GA89695@svzserv.kemerovo.su> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: stable@freebsd.org Subject: Re: lagg(4) and failover X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2008 10:55:56 -0000 On Tue, Aug 12, 2008 at 12:37:15PM +0200, Marian Hettwer wrote: > I'm using lagg(4) on some of our servers and I'm just wondering how the > failover is implemented. > The manpage isn't quite clear: > > failover Sends and receives traffic only through the master port. > If > the master port becomes unavailable, the next active port > is > used. The first interface added is the master port; any > interfaces added after that are used as failover devices. > > What is meant by "becomes unavailable"? Is it just the physical link which > needs to become unavailable to trigger a failover? Yes. It seems you need lacp protocol described later in the manual. Eugene Grosbein From owner-freebsd-stable@FreeBSD.ORG Tue Aug 12 11:00:50 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E8FF11065671 for ; Tue, 12 Aug 2008 11:00:50 +0000 (UTC) (envelope-from thomas.e.zander@googlemail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.176]) by mx1.freebsd.org (Postfix) with ESMTP id BAB978FC25 for ; Tue, 12 Aug 2008 11:00:50 +0000 (UTC) (envelope-from thomas.e.zander@googlemail.com) Received: by wa-out-1112.google.com with SMTP id j4so229050wah.3 for ; Tue, 12 Aug 2008 04:00:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=hbvB96OcMuHdqyN5cy0Z1OicZ6kJPm1rGu6tdDdEC5A=; b=jTKmSeEKe21chvZyUKpD1AM58WGYtC1fxcMcO8zOv1dCjAXbgEXqfAod8v87AfQQys aby/TBbCC8aEOKaHqz4EQoAWZ/zXP7V2QnsaFPiB7XHbNsnV//csZkVbRefZzcxj3vd6 gQzy2OOsgPsdGe0+4SjcJNWSGZ2eGz5MCjFKw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=RBA5702S3QsPR5/QRUOrqAm2j4zuNmnuQeDXxj5oZPHIGrP5AeABBEjND6IWpcQ+9k 4KrzBbaAUjefv9jBp66s88CmfE76WETv48MTvjEctQ/QPjuzgUQnesS0B0Na/G+DV3hl azr9ZWSqM629gZskj5Em+yTR/kbT0BQJ5WJtA= Received: by 10.114.201.1 with SMTP id y1mr4562968waf.216.1218537293129; Tue, 12 Aug 2008 03:34:53 -0700 (PDT) Received: by 10.114.235.12 with HTTP; Tue, 12 Aug 2008 03:34:53 -0700 (PDT) Message-ID: <786602c60808120334h7edabf0dob804d7593113e7b2@mail.gmail.com> Date: Tue, 12 Aug 2008 18:34:53 +0800 From: "Thomas Zander" To: "Edward Ruggeri" In-Reply-To: <919383240807230637o447d2763gd1802dc5f3dd4973@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <919383240807230637o447d2763gd1802dc5f3dd4973@mail.gmail.com> Cc: freebsd-stable@freebsd.org Subject: Re: Ath driver causes kernel panic (page fault) on 7.0-STABLE during use X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2008 11:00:51 -0000 Hi, On Wed, Jul 23, 2008 at 21:37, Edward Ruggeri wrote: > I recently purchased a Lenovo ThinkPad with a ThinkPad 11a/b/g > Wireless LAN Mini Express Adapter (based on the AR5212 chipset). I > got kernel panics while using the wireless card under 7-STABLE Do you still have this problem or did you find a workaround? Does it look something like this? : http://www.freebsd.org/cgi/query-pr.cgi?pr=126475 I upgraded my notebook from 6.3 to 7-STABLE on the weekend and get reproducible kernel panics ~2 sec of using the ath network card. Riggs From owner-freebsd-stable@FreeBSD.ORG Tue Aug 12 11:02:44 2008 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4C674106564A; Tue, 12 Aug 2008 11:02:44 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from constantine.ticketswitch.com (constantine.ticketswitch.com [IPv6:2002:57e0:1d4e:1::3]) by mx1.freebsd.org (Postfix) with ESMTP id 1292F8FC0C; Tue, 12 Aug 2008 11:02:44 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from dilbert.rattatosk ([10.64.50.6] helo=dilbert.ticketswitch.com) by constantine.ticketswitch.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KSreE-000H0z-Oe; Tue, 12 Aug 2008 12:02:42 +0100 Received: from petefrench by dilbert.ticketswitch.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KSreE-000ATd-NT; Tue, 12 Aug 2008 12:02:42 +0100 To: mat@FreeBSD.org, stable@freebsd.org In-Reply-To: <2D4221F0175C7261ECD00191@atuin.in.mat.cc> Message-Id: From: Pete French Date: Tue, 12 Aug 2008 12:02:42 +0100 Cc: Subject: Re: neighbor discovery problem X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2008 11:02:44 -0000 > Since I added IPv6 to my network, and started really using it, I'm seeing > some strange things happening. > > For instance, I'm on machine 2a01:678:1:443::443, and I do : > > $ traceroute6 -n 2a01:678:100:2:: > traceroute6 to 2a01:678:100:2:: (2a01:678:100:2::) from > 2a01:678:1:443::443, 64 hops max, 12 byte packets > 1 2a01:678:1:443:: 0.636 ms 0.602 ms 0.525 ms > 2 2a01:678:1:443:: 2999.665 ms !A 2999.636 ms !A 2999.680 ms !A > > 2a01:678:1:443:: is it's default gateway, and is also directly connected to > 2a01:678:100:2::, but it does not seem to be able to contact it. What are your prefix lengths on the various interfaces, and does 2a01:678:100:2:: have a route back to 2a01:678:1:443::443 ? If you can show us the config on the interfaces of the three machines then we might be able to get a better idea. I am imagining how you have these three boxes connected in my head, but nothing beats an explanation plus the config :-) > Maybe I'm doing something wrong, but, well, I can't seem to find ou what. > > 2a01:678:1:443::443 is a 7.0 > 2a01:678:1:443:: is a 6.2 > 2a01:678:100:2:: is a 6.0 I've used all of those with IPv6 and they work fine, it's most likely a small config problem. I had a lot of frustrations with IPv6 when I started using it - though now it is working I wouldn't be without it. -pete. From owner-freebsd-stable@FreeBSD.ORG Tue Aug 12 11:02:53 2008 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5EF711065670 for ; Tue, 12 Aug 2008 11:02:53 +0000 (UTC) (envelope-from mh@kernel32.de) Received: from crivens.kernel32.de (crivens.terrorteam.de [81.169.171.191]) by mx1.freebsd.org (Postfix) with ESMTP id 273708FC1B for ; Tue, 12 Aug 2008 11:02:52 +0000 (UTC) (envelope-from mh@kernel32.de) Received: from www.terrorteam.de (localhost [127.0.0.1]) by crivens.kernel32.de (Postfix) with ESMTP id 06E89B0297; Tue, 12 Aug 2008 13:02:52 +0200 (CEST) MIME-Version: 1.0 Date: Tue, 12 Aug 2008 13:02:51 +0200 From: Marian Hettwer To: Eugene Grosbein In-Reply-To: <20080812105552.GA89695@svzserv.kemerovo.su> References: <20080812105552.GA89695@svzserv.kemerovo.su> Message-ID: X-Sender: mh@kernel32.de User-Agent: RoundCube Webmail/0.1-rc2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Cc: stable@freebsd.org Subject: Re: lagg(4) and failover X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2008 11:02:53 -0000 On Tue, 12 Aug 2008 18:55:52 +0800, Eugene Grosbein wrote: > On Tue, Aug 12, 2008 at 12:37:15PM +0200, Marian Hettwer wrote: > >> I'm using lagg(4) on some of our servers and I'm just wondering how the >> failover is implemented. >> The manpage isn't quite clear: >> >> failover Sends and receives traffic only through the master > port. >> If >> the master port becomes unavailable, the next active > port >> is >> used. The first interface added is the master port; > any >> interfaces added after that are used as failover > devices. >> >> What is meant by "becomes unavailable"? Is it just the physical link > which >> needs to become unavailable to trigger a failover? > > Yes. It seems you need lacp protocol described later in the manual. > Thanks for your answer. However, IMO lacp doesn't solve that problem. lacp is used for link aggregation, not failover. If I'm wrong over there, I should have a read about lacp... should do that anyway, I guess. The manpage states "In the event of changes in physical connectivity...". Again, does that mean, the link needs to be physically unavailable? If so, it'll be the same behaviour as in failover mode and doesn't solve my problem of a misconfigured switch... Cheers, Marian From owner-freebsd-stable@FreeBSD.ORG Tue Aug 12 11:18:04 2008 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C620F106566B for ; Tue, 12 Aug 2008 11:18:04 +0000 (UTC) (envelope-from mat@FreeBSD.org) Received: from plouf.absolight.net (plouf.absolight.net [79.143.240.136]) by mx1.freebsd.org (Postfix) with ESMTP id 81C4C8FC1B for ; Tue, 12 Aug 2008 11:18:04 +0000 (UTC) (envelope-from mat@FreeBSD.org) Received: from gw.in.absolight.net (gw.in.absolight.net [79.143.241.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "gw.in.absolight.net", Issuer "CA Cert Signing Authority" (verified OK)) by plouf.absolight.net (Postfix) with ESMTP id DF57376401C; Tue, 12 Aug 2008 13:17:31 +0200 (CEST) Received: from andromede.in.absolight.net (andromede.in.absolight.net [79.143.241.226]) by gw.in.absolight.net (Postfix) with ESMTP id 024456123; Tue, 12 Aug 2008 13:17:30 +0200 (CEST) Received: from localhost.in.absolight.net (localhost.in.absolight.net [127.0.0.1]) by andromede.in.absolight.net (8.14.2/8.14.2) with ESMTP id m7CBHUWG061893; Tue, 12 Aug 2008 13:17:30 +0200 (CEST) (envelope-from mat@FreeBSD.org) Date: Tue, 12 Aug 2008 13:17:27 +0200 From: Mathieu Arnold To: Jeremy Chadwick , Mathieu Arnold Message-ID: <65391406E135A0EC389574BA@andromede.in.absolight.net> In-Reply-To: <20080812083403.GA2150@eos.sc1.parodius.com> References: <2D4221F0175C7261ECD00191@atuin.in.mat.cc> <20080812083403.GA2150@eos.sc1.parodius.com> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========07098EC736949372F54D==========" Cc: stable@FreeBSD.org Subject: Re: neighbor discovery problem X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2008 11:18:04 -0000 --==========07098EC736949372F54D========== Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline +-le 12.08.2008 01:34:03 -0700, Jeremy Chadwick a dit : | Important note: I know absolutely nothing about IPv6. | | Do you have ACLs on any of these machines? !A in traceroute commonly | means there's an ACL blocking said packets: | | !A (communication with destination network administratively prohibited) | | A ping from the other host might cause a stateful firewall to begin | allowing said traffic to/from the machine which previously wasn't | working. | | If you use a firewall on these machines (ipfw, pf, etc.), I'd recommend | posting your problem to the freebsd-pf list instead. Hum, no, I've verified it already, there is pf enabled on the gateway, which is also a firewall, but only on the external interface which does not come in play here. -- Mathieu Arnold --==========07098EC736949372F54D========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkihcUoACgkQJqR8av5thQ9newCg2Uw+SeKEIx4FwZfNePWrxdS3 x9MAn0cAAN6mEISK0XZl+Z3ToXawOqUF =z5Vl -----END PGP SIGNATURE----- --==========07098EC736949372F54D==========-- From owner-freebsd-stable@FreeBSD.ORG Tue Aug 12 11:24:40 2008 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E18C51065673 for ; Tue, 12 Aug 2008 11:24:40 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail35.syd.optusnet.com.au (mail35.syd.optusnet.com.au [211.29.133.51]) by mx1.freebsd.org (Postfix) with ESMTP id 78F818FC20 for ; Tue, 12 Aug 2008 11:24:40 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from server.vk2pj.dyndns.org (c122-106-215-175.belrs3.nsw.optusnet.com.au [122.106.215.175]) by mail35.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id m7CBOUFv002896 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Aug 2008 21:24:32 +1000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.2/8.14.2) with ESMTP id m7CBOUCc009825; Tue, 12 Aug 2008 21:24:30 +1000 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.2/8.14.2/Submit) id m7CBOU6G009824; Tue, 12 Aug 2008 21:24:30 +1000 (EST) (envelope-from peter) Date: Tue, 12 Aug 2008 21:24:30 +1000 From: Peter Jeremy To: Eugene Grosbein Message-ID: <20080812112430.GC64458@server.vk2pj.dyndns.org> References: <20080812105552.GA89695@svzserv.kemerovo.su> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OQhbRXNHSL5w/5po" Content-Disposition: inline In-Reply-To: <20080812105552.GA89695@svzserv.kemerovo.su> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.18 (2008-05-17) Cc: stable@freebsd.org, Marian Hettwer Subject: Re: lagg(4) and failover X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2008 11:24:41 -0000 --OQhbRXNHSL5w/5po Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2008-Aug-12 18:55:52 +0800, Eugene Grosbein wrote: >On Tue, Aug 12, 2008 at 12:37:15PM +0200, Marian Hettwer wrote: > >> I'm using lagg(4) on some of our servers and I'm just wondering how the >> failover is implemented. As far as I can tell, not especially well :-(. It doesn't seem to detect much short of layer 1 failure. In particular, shutting down the switch port will not trigger a failover. >> The manpage isn't quite clear: >>=20 >> failover Sends and receives traffic only through the master por= t.=20 >> If >> the master port becomes unavailable, the next active p= ort >> is >> used. The first interface added is the master port; a= ny >> interfaces added after that are used as failover devic= es. >>=20 >> What is meant by "becomes unavailable"? Is it just the physical link whi= ch >> needs to become unavailable to trigger a failover? It seems to be, >Yes. It seems you need lacp protocol described later in the manual. Actually, lacp and failover are used differently: lacp is primarily used to increase the bandwidth between the host and the switch whilst failover is used for redundancy. With lacp, all the physical interfaces must be connected to a single switch. With failover, the physical interfaces will normally be connected to different switches (so a failure in one switch will not cause the loss of all connectivity. --=20 Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. --OQhbRXNHSL5w/5po Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkihcu4ACgkQ/opHv/APuIcNXgCeJPEp9QTb83+iPyesHUaIwCYR Z+AAn1gGYSRZTEUDA+R6czO86QOEt4kk =HvEk -----END PGP SIGNATURE----- --OQhbRXNHSL5w/5po-- From owner-freebsd-stable@FreeBSD.ORG Tue Aug 12 11:30:14 2008 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 543BF1065681 for ; Tue, 12 Aug 2008 11:30:14 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from constantine.ticketswitch.com (constantine.ticketswitch.com [IPv6:2002:57e0:1d4e:1::3]) by mx1.freebsd.org (Postfix) with ESMTP id 1C6008FC16 for ; Tue, 12 Aug 2008 11:30:14 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from dilbert.rattatosk ([10.64.50.6] helo=dilbert.ticketswitch.com) by constantine.ticketswitch.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KSs4q-000HFz-5z; Tue, 12 Aug 2008 12:30:12 +0100 Received: from petefrench by dilbert.ticketswitch.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KSs4q-000AVN-4d; Tue, 12 Aug 2008 12:30:12 +0100 To: eugen@kuzbass.ru, mh@kernel32.de In-Reply-To: Message-Id: From: Pete French Date: Tue, 12 Aug 2008 12:30:12 +0100 Cc: stable@freebsd.org Subject: Re: lagg(4) and failover X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2008 11:30:14 -0000 > However, IMO lacp doesn't solve that problem. lacp is used for link > aggregation, not failover. It does both - if one of the links becomes unavailable then it will stop using it. We use this for failover and it works fine, the only caveat being that your LACP device at the far end needs to look like a single phsyical device (the nicer Cisco switches do this quite happily) > The manpage states "In the event of changes in physical connectivity...". > Again, does that mean, the link needs to be physically unavailable? If so, > it'll be the same behaviour as in failover mode and doesn't solve my > problem of a misconfigured switch... lagg is to handle failover at the physical layer for when one of your ether ports fails, or someone unplugs a cable. If I understand you correctly you are looking for something at the next layer up, to handle a problem where the ports work fine, but are not going to their expected destinations. lagg won't do this. -pete. From owner-freebsd-stable@FreeBSD.ORG Tue Aug 12 11:31:24 2008 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 12B40106567B; Tue, 12 Aug 2008 11:31:24 +0000 (UTC) (envelope-from jdc@parodius.com) Received: from mx01.sc1.parodius.com (mx01.sc1.parodius.com [72.20.106.3]) by mx1.freebsd.org (Postfix) with ESMTP id 048ED8FC18; Tue, 12 Aug 2008 11:31:24 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id E48171CC0C0; Tue, 12 Aug 2008 04:31:23 -0700 (PDT) Date: Tue, 12 Aug 2008 04:31:23 -0700 From: Jeremy Chadwick To: Mathieu Arnold Message-ID: <20080812113123.GA9694@eos.sc1.parodius.com> References: <2D4221F0175C7261ECD00191@atuin.in.mat.cc> <20080812083403.GA2150@eos.sc1.parodius.com> <65391406E135A0EC389574BA@andromede.in.absolight.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <65391406E135A0EC389574BA@andromede.in.absolight.net> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: stable@FreeBSD.org Subject: Re: neighbor discovery problem X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2008 11:31:24 -0000 On Tue, Aug 12, 2008 at 01:17:27PM +0200, Mathieu Arnold wrote: > +-le 12.08.2008 01:34:03 -0700, Jeremy Chadwick a dit : > | Important note: I know absolutely nothing about IPv6. > | > | Do you have ACLs on any of these machines? !A in traceroute commonly > | means there's an ACL blocking said packets: > | > | !A (communication with destination network administratively prohibited) > | > | A ping from the other host might cause a stateful firewall to begin > | allowing said traffic to/from the machine which previously wasn't > | working. > | > | If you use a firewall on these machines (ipfw, pf, etc.), I'd recommend > | posting your problem to the freebsd-pf list instead. > > Hum, no, I've verified it already, there is pf enabled on the gateway, which > is also a firewall, but only on the external interface which does not come in > play here. That depends. Are you using "set skip" on non-external interfaces, or are you using pass rules to explicitly pass all traffic? Sorry if it sounds like I'm doubting you, but !A really looks like an ACL thing. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Tue Aug 12 11:35:08 2008 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 95ABD1065679; Tue, 12 Aug 2008 11:35:08 +0000 (UTC) (envelope-from mat@FreeBSD.org) Received: from plouf.absolight.net (plouf.absolight.net [79.143.240.136]) by mx1.freebsd.org (Postfix) with ESMTP id 51DCF8FC08; Tue, 12 Aug 2008 11:35:08 +0000 (UTC) (envelope-from mat@FreeBSD.org) Received: from gw.in.absolight.net (gw.in.absolight.net [79.143.241.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "gw.in.absolight.net", Issuer "CA Cert Signing Authority" (verified OK)) by plouf.absolight.net (Postfix) with ESMTP id 106A876401C; Tue, 12 Aug 2008 13:34:37 +0200 (CEST) Received: from andromede.in.absolight.net (andromede.in.absolight.net [79.143.241.226]) by gw.in.absolight.net (Postfix) with ESMTP id 2E9F76123; Tue, 12 Aug 2008 13:34:36 +0200 (CEST) Received: from localhost.in.absolight.net (localhost.in.absolight.net [127.0.0.1]) by andromede.in.absolight.net (8.14.2/8.14.2) with ESMTP id m7CBYZLR065722; Tue, 12 Aug 2008 13:34:36 +0200 (CEST) (envelope-from mat@FreeBSD.org) Date: Tue, 12 Aug 2008 13:34:35 +0200 From: Mathieu Arnold To: Jeremy Chadwick Message-ID: <7AFCCB24A4B9B391813EBBFF@andromede.in.absolight.net> In-Reply-To: <65391406E135A0EC389574BA@andromede.in.absolight.net> References: <2D4221F0175C7261ECD00191@atuin.in.mat.cc> <20080812083403.GA2150@eos.sc1.parodius.com> <65391406E135A0EC389574BA@andromede.in.absolight.net> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========2012AF48C9F10E9AF351==========" Cc: stable@FreeBSD.org Subject: Re: neighbor discovery problem X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2008 11:35:08 -0000 --==========2012AF48C9F10E9AF351========== Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline +-le 12.08.2008 13:17:27 +0200, Mathieu Arnold a dit : | +-le 12.08.2008 01:34:03 -0700, Jeremy Chadwick a dit : || Important note: I know absolutely nothing about IPv6. || || Do you have ACLs on any of these machines? !A in traceroute commonly || means there's an ACL blocking said packets: || || !A (communication with destination network administratively prohibited) || || A ping from the other host might cause a stateful firewall to begin || allowing said traffic to/from the machine which previously wasn't || working. || || If you use a firewall on these machines (ipfw, pf, etc.), I'd recommend || posting your problem to the freebsd-pf list instead. | | Hum, no, I've verified it already, there is pf enabled on the gateway, which | is also a firewall, but only on the external interface which does not come | in play here. There's a pass and not a skip, but all my block rules have log, and no packets show up in pflog, which tends to make me believe that, well, it's not a firewall problem. -- Mathieu Arnold --==========2012AF48C9F10E9AF351========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkihdUsACgkQJqR8av5thQ88AACgyBcJicv1lKpL7P2MaNgrkF3X AcAAn1det956uKh2ma3A9hJQ8ND+XLB1 =oklv -----END PGP SIGNATURE----- --==========2012AF48C9F10E9AF351==========-- From owner-freebsd-stable@FreeBSD.ORG Tue Aug 12 11:36:07 2008 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3B4E9106566B for ; Tue, 12 Aug 2008 11:36:07 +0000 (UTC) (envelope-from mat@FreeBSD.org) Received: from plouf.absolight.net (plouf.absolight.net [79.143.240.136]) by mx1.freebsd.org (Postfix) with ESMTP id C96888FC13 for ; Tue, 12 Aug 2008 11:36:06 +0000 (UTC) (envelope-from mat@FreeBSD.org) Received: from gw.in.absolight.net (gw.in.absolight.net [79.143.241.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "gw.in.absolight.net", Issuer "CA Cert Signing Authority" (verified OK)) by plouf.absolight.net (Postfix) with ESMTP id 8E407764017; Tue, 12 Aug 2008 13:35:35 +0200 (CEST) Received: from andromede.in.absolight.net (andromede.in.absolight.net [79.143.241.226]) by gw.in.absolight.net (Postfix) with ESMTP id BC2566123; Tue, 12 Aug 2008 13:35:34 +0200 (CEST) Received: from localhost.in.absolight.net (localhost.in.absolight.net [127.0.0.1]) by andromede.in.absolight.net (8.14.2/8.14.2) with ESMTP id m7CBZY0i065939; Tue, 12 Aug 2008 13:35:34 +0200 (CEST) (envelope-from mat@FreeBSD.org) Date: Tue, 12 Aug 2008 13:35:33 +0200 From: Mathieu Arnold To: Pete French , stable@FreeBSD.org Message-ID: <6C5A5164866ACB760C1B37CA@andromede.in.absolight.net> In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========F538679DBEB126E44D1B==========" Cc: Subject: Re: neighbor discovery problem X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2008 11:36:07 -0000 --==========F538679DBEB126E44D1B========== Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline +-le 12.08.2008 12:02:42 +0100, Pete French a dit : |> Since I added IPv6 to my network, and started really using it, I'm seeing |> some strange things happening. |> |> For instance, I'm on machine 2a01:678:1:443::443, and I do : |> |> $ traceroute6 -n 2a01:678:100:2:: |> traceroute6 to 2a01:678:100:2:: (2a01:678:100:2::) from |> 2a01:678:1:443::443, 64 hops max, 12 byte packets |> 1 2a01:678:1:443:: 0.636 ms 0.602 ms 0.525 ms |> 2 2a01:678:1:443:: 2999.665 ms !A 2999.636 ms !A 2999.680 ms !A |> |> 2a01:678:1:443:: is it's default gateway, and is also directly connected to |> 2a01:678:100:2::, but it does not seem to be able to contact it. | | What are your prefix lengths on the various interfaces, and does | 2a01:678:100:2:: have a route back to 2a01:678:1:443::443 ? If you | can show us the config on the interfaces of the three machines then | we might be able to get a better idea. I am imagining how you have these | three boxes connected in my head, but nothing beats an explanation plus | the config :-) Hum, 2a01:678:1:443::443 is a /64, and 2a01:678:100:2:: is on a /48, both have the "same" gateway, that is, the same box, which has : inet6 2a01:678:1:443:: prefixlen 64 inet6 2a01:678:100:: prefixlen 48 The problem I'm seeing is that before I ping the machine from the gateway, all ndp -a says about this machine is : 2a01:678:100:2:: (incomplete) em0 1s I 3 when I ping it from the first host, I see : 2a01:678:1:443::443 > 2a01:678:100:2::: ICMP6, echo request, seq 0, length 16 fe80::207:e9ff:fe0e:dead > ff02::1:ff00:0: ICMP6, neighbor solicitation, who has 2a01:678:100:2::, length 32 fe80::207:e9ff:fe0e:dead > 2a01:678:1:443::443: ICMP6, redirect, 2a01:678:100:2:: to 2a01:678:100:2::, length 104 fe80::2b0:d0ff:fee1:c05f > fe80::207:e9ff:fe0e:dead: ICMP6, neighbor advertisement, tgt is 2a01:678:100:2::, length 32 fe80::207:e9ff:fe0e:dead > ff02::1:ffe1:c05f: ICMP6, neighbor solicitation, who has fe80::2b0:d0ff:fee1:c05f, length 32 fe80::2b0:d0ff:fee1:c05f > fe80::207:e9ff:fe0e:dead: ICMP6, neighbor advertisement, tgt is fe80::2b0:d0ff:fee1:c05f, length 32 and when I ping it from the gateway, I see : 2a01:678:100:25:: > 2a01:678:100::: ICMP6, neighbor solicitation, who has 2a01:678:100::, length 32 2a01:678:100:: > 2a01:678:100:25::: ICMP6, neighbor advertisement, tgt is 2a01:678:100::, length 24 2a01:678:100:: > ff02::1:ff00:0: ICMP6, neighbor solicitation, who has 2a01:678:100:2::, length 32 2a01:678:100:2:: > 2a01:678:100::: ICMP6, neighbor advertisement, tgt is 2a01:678:100:2::, length 32 And I don't understand why there's a difference, and why when the packets don't come from the gateway, the neighbor solicitation goes up wrong and does not work. |> Maybe I'm doing something wrong, but, well, I can't seem to find ou what. |> |> 2a01:678:1:443::443 is a 7.0 |> 2a01:678:1:443:: is a 6.2 |> 2a01:678:100:2:: is a 6.0 | | I've used all of those with IPv6 and they work fine, it's most likely | a small config problem. I had a lot of frustrations with IPv6 when I | started using it - though now it is working I wouldn't be without it. Well, I'm certain it must be some stupid configuration problem, but, well, I can't seem to find it :-) -- Mathieu Arnold --==========F538679DBEB126E44D1B========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkihdYYACgkQJqR8av5thQ/utgCgx4hC3BxOFh6qew5POsytEV8C zR8AoOhHpvebm19Ha3n+UQQCLlx5aPWL =bvo/ -----END PGP SIGNATURE----- --==========F538679DBEB126E44D1B==========-- From owner-freebsd-stable@FreeBSD.ORG Tue Aug 12 11:36:57 2008 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C615B1065681; Tue, 12 Aug 2008 11:36:57 +0000 (UTC) (envelope-from jdc@parodius.com) Received: from mx01.sc1.parodius.com (mx01.sc1.parodius.com [72.20.106.3]) by mx1.freebsd.org (Postfix) with ESMTP id B7A3E8FC1E; Tue, 12 Aug 2008 11:36:57 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id A18361CC0C0; Tue, 12 Aug 2008 04:36:57 -0700 (PDT) Date: Tue, 12 Aug 2008 04:36:57 -0700 From: Jeremy Chadwick To: Mathieu Arnold Message-ID: <20080812113657.GB9694@eos.sc1.parodius.com> References: <2D4221F0175C7261ECD00191@atuin.in.mat.cc> <20080812083403.GA2150@eos.sc1.parodius.com> <65391406E135A0EC389574BA@andromede.in.absolight.net> <7AFCCB24A4B9B391813EBBFF@andromede.in.absolight.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7AFCCB24A4B9B391813EBBFF@andromede.in.absolight.net> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: stable@FreeBSD.org Subject: Re: neighbor discovery problem X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2008 11:36:57 -0000 On Tue, Aug 12, 2008 at 01:34:35PM +0200, Mathieu Arnold wrote: > > > +-le 12.08.2008 13:17:27 +0200, Mathieu Arnold a dit : > | +-le 12.08.2008 01:34:03 -0700, Jeremy Chadwick a dit : > || Important note: I know absolutely nothing about IPv6. > || > || Do you have ACLs on any of these machines? !A in traceroute commonly > || means there's an ACL blocking said packets: > || > || !A (communication with destination network administratively prohibited) > || > || A ping from the other host might cause a stateful firewall to begin > || allowing said traffic to/from the machine which previously wasn't > || working. > || > || If you use a firewall on these machines (ipfw, pf, etc.), I'd recommend > || posting your problem to the freebsd-pf list instead. > | > | Hum, no, I've verified it already, there is pf enabled on the gateway, which > | is also a firewall, but only on the external interface which does not come > | in play here. > > There's a pass and not a skip, but all my block rules have log, and no > packets show up in pflog, which tends to make me believe that, well, it's not > a firewall problem. A pass on RELENG_7 will still cause state to be kept (keep state is implicit on RELENG_7). Do you see state mismatches? pfctl -s info. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Tue Aug 12 11:40:13 2008 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3C6181065677 for ; Tue, 12 Aug 2008 11:40:13 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from constantine.ticketswitch.com (constantine.ticketswitch.com [IPv6:2002:57e0:1d4e:1::3]) by mx1.freebsd.org (Postfix) with ESMTP id 02A068FC1E for ; Tue, 12 Aug 2008 11:40:13 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from dilbert.rattatosk ([10.64.50.6] helo=dilbert.ticketswitch.com) by constantine.ticketswitch.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KSsEK-000HNQ-Ks; Tue, 12 Aug 2008 12:40:00 +0100 Received: from petefrench by dilbert.ticketswitch.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KSsEK-000AWQ-JL; Tue, 12 Aug 2008 12:40:00 +0100 To: eugen@kuzbass.ru, peterjeremy@optushome.com.au In-Reply-To: <20080812112430.GC64458@server.vk2pj.dyndns.org> Message-Id: From: Pete French Date: Tue, 12 Aug 2008 12:40:00 +0100 Cc: stable@freebsd.org, mh@kernel32.de Subject: Re: lagg(4) and failover X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2008 11:40:13 -0000 > As far as I can tell, not especially well :-(. It doesn't seem to detect > much short of layer 1 failure. In particular, shutting down the switch > port will not trigger a failover. Are you using bce devices as your phsyical interfaces ? Take a look at the thread from last week about ifconfig - with the patch posted a port shutdown now *does* trigger a failover quite happily. If you are using e devices then I suggest you try it. > With lacp, all the physical interfaces must be connected to a single > switch. With failover, the physical interfaces will normally be > connected to different switches (so a failure in one switch will not > cause the loss of all connectivity. This is true - with the caveat that certain pairs of switches can be made to appear as a single phsyical device for the purposes of LACP, in which case it works fine for failover. We have two farms here - an old one using a pair of Cisco 3560s and a new one using a pair of 3750-Es. The 3750s will act as a single device and we use LACP on the machines connected to those, but the 3560s appear as a pair of devices, so for those we use failover mode. LACP failover always worked fine, and with the bce patch from last week the normal failover now also works. Nore that you can enable LACP on the 3560,s and it does appear to negotiate and work, but the switches keep changing their idea of which port to use every few seconds. So the connection works, but with high rates of packet loss as a few go missing every time the switch pair flip-flops. -pete. From owner-freebsd-stable@FreeBSD.ORG Tue Aug 12 11:40:27 2008 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 987AC10656CC; Tue, 12 Aug 2008 11:40:27 +0000 (UTC) (envelope-from mat@FreeBSD.org) Received: from plouf.absolight.net (plouf.absolight.net [79.143.240.136]) by mx1.freebsd.org (Postfix) with ESMTP id 57ABE8FC0A; Tue, 12 Aug 2008 11:40:27 +0000 (UTC) (envelope-from mat@FreeBSD.org) Received: from gw.in.absolight.net (gw.in.absolight.net [79.143.241.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "gw.in.absolight.net", Issuer "CA Cert Signing Authority" (verified OK)) by plouf.absolight.net (Postfix) with ESMTP id 41BA5764016; Tue, 12 Aug 2008 13:39:56 +0200 (CEST) Received: from andromede.in.absolight.net (andromede.in.absolight.net [79.143.241.226]) by gw.in.absolight.net (Postfix) with ESMTP id 62DF26123; Tue, 12 Aug 2008 13:39:55 +0200 (CEST) Received: from localhost.in.absolight.net (localhost.in.absolight.net [127.0.0.1]) by andromede.in.absolight.net (8.14.2/8.14.2) with ESMTP id m7CBdtHu066906; Tue, 12 Aug 2008 13:39:55 +0200 (CEST) (envelope-from mat@FreeBSD.org) Date: Tue, 12 Aug 2008 13:39:54 +0200 From: Mathieu Arnold To: Jeremy Chadwick Message-ID: <10126CF1B8A265298216C20A@andromede.in.absolight.net> In-Reply-To: <20080812113123.GA9694@eos.sc1.parodius.com> References: <2D4221F0175C7261ECD00191@atuin.in.mat.cc> <20080812083403.GA2150@eos.sc1.parodius.com> <65391406E135A0EC389574BA@andromede.in.absolight.net> <20080812113123.GA9694@eos.sc1.parodius.com> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========C777D8C89620DA25B277==========" Cc: stable@FreeBSD.org Subject: Re: neighbor discovery problem X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2008 11:40:27 -0000 --==========C777D8C89620DA25B277========== Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline +-le 12.08.2008 04:31:23 -0700, Jeremy Chadwick a dit : | Sorry if it sounds like I'm doubting you, but !A really looks like an | ACL thing. Oh, and in traceroute(8), !A is "!A (communication with destination network administratively prohibited", which is just right from your point of view, but, in traceroute6(8), !A is "Destination Unreachable - Address Unreachable" Though, in traceroute6(8), !P is "Destination Unreachable - Administratively Prohibited" whereas in traceroute(8), !P is "protocol unreachable" Yes, I know, much much confusing :-) -- Mathieu Arnold --==========C777D8C89620DA25B277========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkihdooACgkQJqR8av5thQ89RQCcC/4f8DA6vYjxhkTkvJGNMg80 mZwAoORGxWeugT3/IBqoT++0PxoZ5aQ6 =4IVF -----END PGP SIGNATURE----- --==========C777D8C89620DA25B277==========-- From owner-freebsd-stable@FreeBSD.ORG Tue Aug 12 11:43:31 2008 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 454C01065671 for ; Tue, 12 Aug 2008 11:43:31 +0000 (UTC) (envelope-from mh@kernel32.de) Received: from crivens.kernel32.de (crivens.terrorteam.de [81.169.171.191]) by mx1.freebsd.org (Postfix) with ESMTP id 0E6228FC18 for ; Tue, 12 Aug 2008 11:43:31 +0000 (UTC) (envelope-from mh@kernel32.de) Received: from www.terrorteam.de (localhost [127.0.0.1]) by crivens.kernel32.de (Postfix) with ESMTP id DCDA1B0297; Tue, 12 Aug 2008 13:43:29 +0200 (CEST) MIME-Version: 1.0 Date: Tue, 12 Aug 2008 13:43:29 +0200 From: Marian Hettwer To: Pete French In-Reply-To: References: Message-ID: X-Sender: mh@kernel32.de User-Agent: RoundCube Webmail/0.1-rc2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Cc: stable@freebsd.org, eugen@kuzbass.ru Subject: Re: lagg(4) and failover X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2008 11:43:31 -0000 Hi Pete, On Tue, 12 Aug 2008 12:30:12 +0100, Pete French wrote: >> However, IMO lacp doesn't solve that problem. lacp is used for link >> aggregation, not failover. > > It does both - if one of the links becomes unavailable then it will > stop using it. We use this for failover and it works fine, the only > caveat being that your LACP device at the far end needs to look like > a single phsyical device (the nicer Cisco switches do this quite happily) > thanks for that info. >> The manpage states "In the event of changes in physical > connectivity...". >> Again, does that mean, the link needs to be physically unavailable? If > so, >> it'll be the same behaviour as in failover mode and doesn't solve my >> problem of a misconfigured switch... > > lagg is to handle failover at the physical layer for when one of your > ether ports fails, or someone unplugs a cable. If I understand you > correctly you are looking for something at the next layer up, to handle > a problem where the ports work fine, but are not going to their expected > destinations. lagg won't do this. > Thats unfortunate... bonding in Linux is capable of doing this and solaris too. Well then. At least everythings clear now. And in the end, clarifing things was the reason for that mail thread :) Cheers, Marian From owner-freebsd-stable@FreeBSD.ORG Tue Aug 12 11:45:48 2008 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9D97E1065672; Tue, 12 Aug 2008 11:45:48 +0000 (UTC) (envelope-from mat@FreeBSD.org) Received: from plouf.absolight.net (plouf.absolight.net [79.143.240.136]) by mx1.freebsd.org (Postfix) with ESMTP id 5C4F18FC1E; Tue, 12 Aug 2008 11:45:48 +0000 (UTC) (envelope-from mat@FreeBSD.org) Received: from gw.in.absolight.net (gw.in.absolight.net [79.143.241.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "gw.in.absolight.net", Issuer "CA Cert Signing Authority" (verified OK)) by plouf.absolight.net (Postfix) with ESMTP id 5651C76403B; Tue, 12 Aug 2008 13:45:17 +0200 (CEST) Received: from andromede.in.absolight.net (andromede.in.absolight.net [79.143.241.226]) by gw.in.absolight.net (Postfix) with ESMTP id 622C96123; Tue, 12 Aug 2008 13:45:16 +0200 (CEST) Received: from localhost.in.absolight.net (localhost.in.absolight.net [127.0.0.1]) by andromede.in.absolight.net (8.14.2/8.14.2) with ESMTP id m7CBjGck068087; Tue, 12 Aug 2008 13:45:16 +0200 (CEST) (envelope-from mat@FreeBSD.org) Date: Tue, 12 Aug 2008 13:45:15 +0200 From: Mathieu Arnold To: Jeremy Chadwick Message-ID: <5DD9A523E986C374C55BE804@andromede.in.absolight.net> In-Reply-To: <20080812113657.GB9694@eos.sc1.parodius.com> References: <2D4221F0175C7261ECD00191@atuin.in.mat.cc> <20080812083403.GA2150@eos.sc1.parodius.com> <65391406E135A0EC389574BA@andromede.in.absolight.net> <7AFCCB24A4B9B391813EBBFF@andromede.in.absolight.net> <20080812113657.GB9694@eos.sc1.parodius.com> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========844DFDD7E65911709B49==========" Cc: stable@FreeBSD.org Subject: Re: neighbor discovery problem X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2008 11:45:48 -0000 --==========844DFDD7E65911709B49========== Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline +-le 12.08.2008 04:36:57 -0700, Jeremy Chadwick a dit : | A pass on RELENG_7 will still cause state to be kept (keep state is | implicit on RELENG_7). the gateway is a 6.2 ;-) | Do you see state mismatches? pfctl -s info. There are some, but, hum searches 408816380699 11471.5/s state-mismatch 8655467 0.2/s the box has been up more than 400 days, and the number has not been going up while I was trying my things. I bet it goes up when something goes wrong in my network, which happens :-) -- Mathieu Arnold --==========844DFDD7E65911709B49========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkihd8sACgkQJqR8av5thQ8pBgCgkFpgO01QWiVPzxlo9M2y8bG3 czYAn2w9HwRQYbUgelYNWfpbscwzNTxU =tB2C -----END PGP SIGNATURE----- --==========844DFDD7E65911709B49==========-- From owner-freebsd-stable@FreeBSD.ORG Tue Aug 12 11:49:21 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A54051065675 for ; Tue, 12 Aug 2008 11:49:21 +0000 (UTC) (envelope-from nakal@web.de) Received: from fmmailgate04.web.de (fmmailgate04.web.de [217.72.192.242]) by mx1.freebsd.org (Postfix) with ESMTP id 6AFC88FC16 for ; Tue, 12 Aug 2008 11:49:21 +0000 (UTC) (envelope-from nakal@web.de) Received: from web.de by fmmailgate04.web.de (Postfix) with SMTP id B93975E5EA25; Tue, 12 Aug 2008 13:49:19 +0200 (CEST) Received: from [77.190.50.140] by freemailng0304.web.de with HTTP; Tue, 12 Aug 2008 13:49:18 +0200 Date: Tue, 12 Aug 2008 13:49:18 +0200 Message-Id: <1267889400@web.de> MIME-Version: 1.0 From: Martin Sugioarto To: freebsd-stable@freebsd.org, Josh Paetzel Precedence: fm-user Organization: http://freemail.web.de/ X-Provags-Id: V01U2FsdGVkX18bY0CQAbm+XV+BuiOCQk6qvqyUGX844sUtHKM4JREky5Q6x QRtb70tsaJKqK7H1i+g6o9w/KttV9slQT6Owa76ZLsuuxMJlmk= Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: quoted-printable Cc: Markus Vervier , Jack Vogel Subject: Re: em(4) on FreeBSD is sometimes annoying X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2008 11:49:21 -0000 > For what it's worth, I have a T60 that dual boots 6.3-R/amd64 and 7.0-R/= i386=20 > and neither install has this problem. I can cold boot it with the NIC=20 > unplugged, plug in a cable, I get a link light and ifconfig em0 goes to=20 > active, dhclient em0 gets an IP successfully. >=20 Did you try to run /etc/rc.d/netif start after you've booted your laptop u= nplugged=3F Try to do that, THEN connect the cable. The problem appears ONLY in this situation. And it's quite common, because= you often use your laptop with wireless network and suddenly you decide to connect i= t to wired network without having to switch the laptop off. My NIC is in such a state that I am forced to switch it off, or else I don= 't get link signal. I don't think it's a BIOS firmware problem (I have tried every update). I can remember that Linux had this issues, too a while ago. It works there= now, but FreeBSD is still the same. Please read the steps how I cause this situ= ation. It appears ONLY when you do it like I described it. I've seen that people first boot with plugged in cable and start to play w= ith dhclient. Both is wrong. Correct steps to reproduce is: You have to start with unhooked interface AND the line ifconfig=5Fre0=3D"DHCP"= in /etc/rc.conf. Then wait until you can login and try to attach the cable. -- Martin =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F EINE F=DCR ALLE: die kostenlose WEB.DE-Plattform f=FCr Freunde und Deine Homepage mit eigenem Namen. Jetzt starten! http://unddu.de/=3Fkid=3Dkid@mf2 From owner-freebsd-stable@FreeBSD.ORG Tue Aug 12 11:50:36 2008 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B0F851065671; Tue, 12 Aug 2008 11:50:36 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from constantine.ticketswitch.com (constantine.ticketswitch.com [IPv6:2002:57e0:1d4e:1::3]) by mx1.freebsd.org (Postfix) with ESMTP id 794B68FC1D; Tue, 12 Aug 2008 11:50:36 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from dilbert.rattatosk ([10.64.50.6] helo=dilbert.ticketswitch.com) by constantine.ticketswitch.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KSsOZ-000HVJ-Ec; Tue, 12 Aug 2008 12:50:35 +0100 Received: from petefrench by dilbert.ticketswitch.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KSsOZ-000AY8-DE; Tue, 12 Aug 2008 12:50:35 +0100 To: mat@FreeBSD.org, stable@FreeBSD.org In-Reply-To: <6C5A5164866ACB760C1B37CA@andromede.in.absolight.net> Message-Id: From: Pete French Date: Tue, 12 Aug 2008 12:50:35 +0100 Cc: Subject: Re: neighbor discovery problem X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2008 11:50:36 -0000 > Hum, 2a01:678:1:443::443 is a /64, and 2a01:678:100:2:: is on a /48, both > have the "same" gateway, that is, the same box, which has : > inet6 2a01:678:1:443:: prefixlen 64 > inet6 2a01:678:100:: prefixlen 48 O.K., that should work. My best advice here is to do what I did - which is to disable 'pf' entirely and see if it works then. When it does you know the IPv6 config is correct and can then work out which rule in 'pf' is stopping it working when enabled. Sorry, but I van't think of anything else right now, and I guess that may not be an option on a production machine. -pete. From owner-freebsd-stable@FreeBSD.ORG Tue Aug 12 12:00:25 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E74C810657AC for ; Tue, 12 Aug 2008 12:00:25 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by mx1.freebsd.org (Postfix) with ESMTP id 7BCBB8FC16 for ; Tue, 12 Aug 2008 12:00:25 +0000 (UTC) (envelope-from max@love2party.net) Received: from vampire.homelinux.org (dslb-088-066-034-213.pools.arcor-ip.net [88.66.34.213]) by mrelayeu.kundenserver.de (node=mrelayeu8) with ESMTP (Nemesis) id 0ML31I-1KSsY02Amn-0006qW; Tue, 12 Aug 2008 14:00:23 +0200 Received: (qmail 36845 invoked from network); 12 Aug 2008 12:00:18 -0000 Received: from fbsd8.laiers.local (192.168.4.151) by laiers.local with SMTP; 12 Aug 2008 12:00:18 -0000 From: Max Laier Organization: FreeBSD To: freebsd-stable@freebsd.org, eugen@kuzbass.ru Date: Tue, 12 Aug 2008 14:00:18 +0200 User-Agent: KMail/1.10.0 (FreeBSD/8.0-CURRENT; KDE/4.1.0; i386; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200808121400.18440.max@love2party.net> X-Provags-ID: V01U2FsdGVkX19PRxNHiCxG7B0L7ZHsHIPk5DWEownFajsXBHQ 8oYHevQmJ+D73tndzYiiW0QwBUcPo7DDKcKMhQmibKQzugwEF9 y/WHWXKzgNdu1j5NWdoag== Cc: Pete French , Marian Hettwer Subject: Re: lagg(4) and failover X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2008 12:00:26 -0000 On Tuesday 12 August 2008 13:43:29 Marian Hettwer wrote: > Hi Pete, > > On Tue, 12 Aug 2008 12:30:12 +0100, Pete French > > wrote: > >> However, IMO lacp doesn't solve that problem. lacp is used for link > >> aggregation, not failover. > > > > It does both - if one of the links becomes unavailable then it will > > stop using it. We use this for failover and it works fine, the only > > caveat being that your LACP device at the far end needs to look like > > a single phsyical device (the nicer Cisco switches do this quite happily) > > thanks for that info. > > >> The manpage states "In the event of changes in physical > > > > connectivity...". > > > >> Again, does that mean, the link needs to be physically unavailable? If > > > > so, > > > >> it'll be the same behaviour as in failover mode and doesn't solve my > >> problem of a misconfigured switch... > > > > lagg is to handle failover at the physical layer for when one of your > > ether ports fails, or someone unplugs a cable. If I understand you > > correctly you are looking for something at the next layer up, to handle > > a problem where the ports work fine, but are not going to their expected > > destinations. lagg won't do this. > > Thats unfortunate... > bonding in Linux is capable of doing this and solaris too. > Well then. At least everythings clear now. And in the end, clarifing things > was the reason for that mail thread :) You are looking for net/ifstated -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News From owner-freebsd-stable@FreeBSD.ORG Tue Aug 12 12:02:19 2008 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A82E0106568B; Tue, 12 Aug 2008 12:02:19 +0000 (UTC) (envelope-from mat@FreeBSD.org) Received: from plouf.absolight.net (plouf.absolight.net [79.143.240.136]) by mx1.freebsd.org (Postfix) with ESMTP id 66ED18FC17; Tue, 12 Aug 2008 12:02:19 +0000 (UTC) (envelope-from mat@FreeBSD.org) Received: from gw.in.absolight.net (gw.in.absolight.net [79.143.241.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "gw.in.absolight.net", Issuer "CA Cert Signing Authority" (verified OK)) by plouf.absolight.net (Postfix) with ESMTP id B1579764017; Tue, 12 Aug 2008 14:01:46 +0200 (CEST) Received: from andromede.in.absolight.net (andromede.in.absolight.net [79.143.241.226]) by gw.in.absolight.net (Postfix) with ESMTP id 8E5246123; Tue, 12 Aug 2008 14:01:45 +0200 (CEST) Received: from localhost.in.absolight.net (localhost.in.absolight.net [127.0.0.1]) by andromede.in.absolight.net (8.14.2/8.14.2) with ESMTP id m7CC1j39071650; Tue, 12 Aug 2008 14:01:45 +0200 (CEST) (envelope-from mat@FreeBSD.org) Date: Tue, 12 Aug 2008 14:01:45 +0200 From: Mathieu Arnold To: Jeremy Chadwick Message-ID: In-Reply-To: <20080812113657.GB9694@eos.sc1.parodius.com> References: <2D4221F0175C7261ECD00191@atuin.in.mat.cc> <20080812083403.GA2150@eos.sc1.parodius.com> <65391406E135A0EC389574BA@andromede.in.absolight.net> <7AFCCB24A4B9B391813EBBFF@andromede.in.absolight.net> <20080812113657.GB9694@eos.sc1.parodius.com> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========2F9FD39758CF5260BB37==========" Cc: stable@FreeBSD.org Subject: Re: neighbor discovery problem X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2008 12:02:19 -0000 --==========2F9FD39758CF5260BB37========== Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline +-le 12.08.2008 04:36:57 -0700, Jeremy Chadwick a dit : | A pass on RELENG_7 will still cause state to be kept (keep state is | implicit on RELENG_7). I've just tried doing pfctl -d, and not help, I *really* don't believe that it's a pf problem ;-) -- Mathieu Arnold --==========2F9FD39758CF5260BB37========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkihe6kACgkQJqR8av5thQ8D9QCg1x7FfoJ1HznGyZjxZ1nq7nLV PNAAni+O65JoE75uq75cNL6PBBJkEuIH =j5yq -----END PGP SIGNATURE----- --==========2F9FD39758CF5260BB37==========-- From owner-freebsd-stable@FreeBSD.ORG Tue Aug 12 12:03:14 2008 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BD588106568A for ; Tue, 12 Aug 2008 12:03:14 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail16.syd.optusnet.com.au (mail16.syd.optusnet.com.au [211.29.132.197]) by mx1.freebsd.org (Postfix) with ESMTP id 558898FC34 for ; Tue, 12 Aug 2008 12:03:14 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from server.vk2pj.dyndns.org (c122-106-215-175.belrs3.nsw.optusnet.com.au [122.106.215.175]) by mail16.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id m7CC38ii004772 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Aug 2008 22:03:10 +1000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.2/8.14.2) with ESMTP id m7CC3850009990; Tue, 12 Aug 2008 22:03:08 +1000 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.2/8.14.2/Submit) id m7CC377l009989; Tue, 12 Aug 2008 22:03:07 +1000 (EST) (envelope-from peter) Date: Tue, 12 Aug 2008 22:03:07 +1000 From: Peter Jeremy To: Marian Hettwer Message-ID: <20080812120307.GD64458@server.vk2pj.dyndns.org> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GOzekVbrLdOLv44p" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.18 (2008-05-17) Cc: stable@freebsd.org, eugen@kuzbass.ru, Pete French Subject: Re: lagg(4) and failover X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2008 12:03:14 -0000 --GOzekVbrLdOLv44p Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2008-Aug-12 13:43:29 +0200, Marian Hettwer wrote: >> lagg is to handle failover at the physical layer for when one of your >> ether ports fails, or someone unplugs a cable. If I understand you >> >Thats unfortunate... I tend to agree. >bonding in Linux is capable of doing this and solaris too. It shouldn't be too difficult to create something that behaves functionally similarly to Slowaris ipmpd (and with marginally more effort, you could create something that could be configured to behave sensibly). --=20 Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. --GOzekVbrLdOLv44p Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkihe/sACgkQ/opHv/APuIdftwCeODoFTYnXDvG6Hh85GI2mvgjC Uk0An0DZ9ujY1ECAAOX/QBQweYa18UR9 =cbi2 -----END PGP SIGNATURE----- --GOzekVbrLdOLv44p-- From owner-freebsd-stable@FreeBSD.ORG Tue Aug 12 12:10:06 2008 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3A0E8106567E; Tue, 12 Aug 2008 12:10:06 +0000 (UTC) (envelope-from jdc@parodius.com) Received: from mx01.sc1.parodius.com (mx01.sc1.parodius.com [72.20.106.3]) by mx1.freebsd.org (Postfix) with ESMTP id 2AE428FC0A; Tue, 12 Aug 2008 12:10:06 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id E8E7B1CC0C0; Tue, 12 Aug 2008 05:10:05 -0700 (PDT) Date: Tue, 12 Aug 2008 05:10:05 -0700 From: Jeremy Chadwick To: Mathieu Arnold Message-ID: <20080812121005.GA11194@eos.sc1.parodius.com> References: <2D4221F0175C7261ECD00191@atuin.in.mat.cc> <20080812083403.GA2150@eos.sc1.parodius.com> <65391406E135A0EC389574BA@andromede.in.absolight.net> <7AFCCB24A4B9B391813EBBFF@andromede.in.absolight.net> <20080812113657.GB9694@eos.sc1.parodius.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: stable@FreeBSD.org Subject: Re: neighbor discovery problem X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2008 12:10:06 -0000 On Tue, Aug 12, 2008 at 02:01:45PM +0200, Mathieu Arnold wrote: > +-le 12.08.2008 04:36:57 -0700, Jeremy Chadwick a dit : > | A pass on RELENG_7 will still cause state to be kept (keep state is > | implicit on RELENG_7). > > I've just tried doing pfctl -d, and not help, I *really* don't believe that > it's a pf problem ;-) Cool -- just covering all the bases! :-) P.S. -- The high number of state-mismatches you have may be the result of PR 125261, which has been fixed (in RELENG_7 and HEAD). It's unrelated to your issue, but I thought I'd mention it anyways. http://www.freebsd.org/cgi/query-pr.cgi?pr=125261 -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Tue Aug 12 12:11:43 2008 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 61DCA1065671 for ; Tue, 12 Aug 2008 12:11:43 +0000 (UTC) (envelope-from mat@FreeBSD.org) Received: from plouf.absolight.net (plouf.absolight.net [79.143.240.136]) by mx1.freebsd.org (Postfix) with ESMTP id 24C548FC1D for ; Tue, 12 Aug 2008 12:11:43 +0000 (UTC) (envelope-from mat@FreeBSD.org) Received: from gw.in.absolight.net (gw.in.absolight.net [79.143.241.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "gw.in.absolight.net", Issuer "CA Cert Signing Authority" (verified OK)) by plouf.absolight.net (Postfix) with ESMTP id 0A57376401B; Tue, 12 Aug 2008 14:11:12 +0200 (CEST) Received: from andromede.in.absolight.net (andromede.in.absolight.net [79.143.241.226]) by gw.in.absolight.net (Postfix) with ESMTP id C29AF6123; Tue, 12 Aug 2008 14:11:10 +0200 (CEST) Received: from localhost.in.absolight.net (localhost.in.absolight.net [127.0.0.1]) by andromede.in.absolight.net (8.14.2/8.14.2) with ESMTP id m7CCBASj073734; Tue, 12 Aug 2008 14:11:10 +0200 (CEST) (envelope-from mat@FreeBSD.org) Date: Tue, 12 Aug 2008 14:11:10 +0200 From: Mathieu Arnold To: Pete French Message-ID: <6338C16505B9465ED4A9CA76@andromede.in.absolight.net> In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========150136CBDB2B990184B3==========" Cc: stable@FreeBSD.org Subject: Re: neighbor discovery problem X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2008 12:11:43 -0000 --==========150136CBDB2B990184B3========== Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline +-le 12.08.2008 12:50:35 +0100, Pete French a dit : |> Hum, 2a01:678:1:443::443 is a /64, and 2a01:678:100:2:: is on a /48, both |> have the "same" gateway, that is, the same box, which has : |> inet6 2a01:678:1:443:: prefixlen 64 |> inet6 2a01:678:100:: prefixlen 48 | | O.K., that should work. My best advice here is to do what I did - which is | to disable 'pf' entirely and see if it works then. When it does you know | the IPv6 config is correct and can then work out which rule in 'pf' is | stopping it working when enabled. Sorry, but I van't think of anything else | right now, and I guess that may not be an option on a production machine. Well, stopping the firewall a few seconds can't do really bad things, and, well, pfctl -d, wait a bit, try again, still no luck... The network is pretty simple, gateway : em0: flags=8843 mtu 1500 options=b inet6 fe80::207:e9ff:fe0e:dead%em0 prefixlen 64 scopeid 0x1 inet6 2a01:678:1:443:: prefixlen 64 inet6 2a01:678:100:: prefixlen 48 first machine : bridge0: flags=8843 metric 0 mtu 1500 inet6 fe80::2d0:dead:beef:cafe%bridge0 prefixlen 64 scopeid 0x4 inet6 2a01:678:1:443::443 prefixlen 64 destination machine : fxp0: flags=8843 mtu 1500 options=8 inet6 fe80::2b0:d0ff:fee1:c05f%fxp0 prefixlen 64 scopeid 0x1 inet6 2a01:678:100:2:: prefixlen 48 All three ports on a switch. I don't believe it's a problem in if_bridge(4) because it's the same if I try from outside my network. -- Mathieu Arnold --==========150136CBDB2B990184B3========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEUEARECAAYFAkihfd4ACgkQJqR8av5thQ95eQCXfNSt9BUdm72ndB5PkWN75bUh YwCfXjQomi94vcBGbVDBJ/RxlmGuF4E= =LsX4 -----END PGP SIGNATURE----- --==========150136CBDB2B990184B3==========-- From owner-freebsd-stable@FreeBSD.ORG Tue Aug 12 12:13:42 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 030A11065670 for ; Tue, 12 Aug 2008 12:13:42 +0000 (UTC) (envelope-from mh@kernel32.de) Received: from crivens.kernel32.de (crivens.terrorteam.de [81.169.171.191]) by mx1.freebsd.org (Postfix) with ESMTP id C11168FC22 for ; Tue, 12 Aug 2008 12:13:41 +0000 (UTC) (envelope-from mh@kernel32.de) Received: from www.terrorteam.de (localhost [127.0.0.1]) by crivens.kernel32.de (Postfix) with ESMTP id ED30AB0297; Tue, 12 Aug 2008 14:13:39 +0200 (CEST) MIME-Version: 1.0 Date: Tue, 12 Aug 2008 14:13:39 +0200 From: Marian Hettwer To: Max Laier In-Reply-To: <200808121400.18440.max@love2party.net> References: <200808121400.18440.max@love2party.net> Message-ID: <055c079fcd23c6e88e98ef0108a8fcf0@localhost> X-Sender: mh@kernel32.de User-Agent: RoundCube Webmail/0.1-rc2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Cc: eugen@kuzbass.ru, freebsd-stable@freebsd.org, Pete French Subject: Re: lagg(4) and failover X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2008 12:13:42 -0000 Hi Max, On Tue, 12 Aug 2008 14:00:18 +0200, Max Laier wrote: >> Thats unfortunate... >> bonding in Linux is capable of doing this and solaris too. >> Well then. At least everythings clear now. And in the end, clarifing > things >> was the reason for that mail thread :) > > You are looking for net/ifstated > at a first glance into pkg-descr. Yeah, seems like I'm looking for ifstated. Thanks for the heads up :-) Cheers, Marian From owner-freebsd-stable@FreeBSD.ORG Tue Aug 12 12:13:55 2008 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 56BAE10656E7; Tue, 12 Aug 2008 12:13:55 +0000 (UTC) (envelope-from mat@FreeBSD.org) Received: from plouf.absolight.net (plouf.absolight.net [79.143.240.136]) by mx1.freebsd.org (Postfix) with ESMTP id 14C448FC31; Tue, 12 Aug 2008 12:13:55 +0000 (UTC) (envelope-from mat@FreeBSD.org) Received: from gw.in.absolight.net (gw.in.absolight.net [79.143.241.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "gw.in.absolight.net", Issuer "CA Cert Signing Authority" (verified OK)) by plouf.absolight.net (Postfix) with ESMTP id 1DAFC76401B; Tue, 12 Aug 2008 14:13:24 +0200 (CEST) Received: from andromede.in.absolight.net (andromede.in.absolight.net [79.143.241.226]) by gw.in.absolight.net (Postfix) with ESMTP id 3A4356123; Tue, 12 Aug 2008 14:13:23 +0200 (CEST) Received: from localhost.in.absolight.net (localhost.in.absolight.net [127.0.0.1]) by andromede.in.absolight.net (8.14.2/8.14.2) with ESMTP id m7CCDMqw074198; Tue, 12 Aug 2008 14:13:23 +0200 (CEST) (envelope-from mat@FreeBSD.org) Date: Tue, 12 Aug 2008 14:13:22 +0200 From: Mathieu Arnold To: Jeremy Chadwick Message-ID: In-Reply-To: <20080812121005.GA11194@eos.sc1.parodius.com> References: <2D4221F0175C7261ECD00191@atuin.in.mat.cc> <20080812083403.GA2150@eos.sc1.parodius.com> <65391406E135A0EC389574BA@andromede.in.absolight.net> <7AFCCB24A4B9B391813EBBFF@andromede.in.absolight.net> <20080812113657.GB9694@eos.sc1.parodius.com> <20080812121005.GA11194@eos.sc1.parodius.com> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========E0F7367FEC24041F43C8==========" Cc: stable@FreeBSD.org Subject: Re: neighbor discovery problem X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2008 12:13:55 -0000 --==========E0F7367FEC24041F43C8========== Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline +-le 12.08.2008 05:10:05 -0700, Jeremy Chadwick a dit : | On Tue, Aug 12, 2008 at 02:01:45PM +0200, Mathieu Arnold wrote: |> +-le 12.08.2008 04:36:57 -0700, Jeremy Chadwick a dit : |> | A pass on RELENG_7 will still cause state to be kept (keep state is |> | implicit on RELENG_7). |> |> I've just tried doing pfctl -d, and not help, I *really* don't believe that |> it's a pf problem ;-) | | Cool -- just covering all the bases! :-) Well, could have been, I'm getting crazy with this problem. | P.S. -- The high number of state-mismatches you have may be the result | of PR 125261, which has been fixed (in RELENG_7 and HEAD). It's | unrelated to your issue, but I thought I'd mention it anyways. | | http://www.freebsd.org/cgi/query-pr.cgi?pr=125261 I have plans to upgrade the gateway to RELENG_7, but, I'm supposed to be on vacation right now, so, it'll wait until I get back. -- Mathieu Arnold --==========E0F7367FEC24041F43C8========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkihfmIACgkQJqR8av5thQ+zvQCgr4pii07qGsq6rlzSPlO9pp7J 0JkAoOJLBydYqQLUC/PD+AV5N8AT5VfJ =7hsu -----END PGP SIGNATURE----- --==========E0F7367FEC24041F43C8==========-- From owner-freebsd-stable@FreeBSD.ORG Tue Aug 12 12:14:58 2008 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4F0E21065670 for ; Tue, 12 Aug 2008 12:14:58 +0000 (UTC) (envelope-from mh@kernel32.de) Received: from crivens.kernel32.de (crivens.terrorteam.de [81.169.171.191]) by mx1.freebsd.org (Postfix) with ESMTP id 18A138FC18 for ; Tue, 12 Aug 2008 12:14:58 +0000 (UTC) (envelope-from mh@kernel32.de) Received: from www.terrorteam.de (localhost [127.0.0.1]) by crivens.kernel32.de (Postfix) with ESMTP id 60990B0297; Tue, 12 Aug 2008 14:14:57 +0200 (CEST) MIME-Version: 1.0 Date: Tue, 12 Aug 2008 14:14:57 +0200 From: Marian Hettwer To: Peter Jeremy In-Reply-To: <20080812120307.GD64458@server.vk2pj.dyndns.org> References: <20080812120307.GD64458@server.vk2pj.dyndns.org> Message-ID: X-Sender: mh@kernel32.de User-Agent: RoundCube Webmail/0.1-rc2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Cc: stable@freebsd.org, eugen@kuzbass.ru, Pete French Subject: Re: lagg(4) and failover X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2008 12:14:58 -0000 Hi Peter, On Tue, 12 Aug 2008 22:03:07 +1000, Peter Jeremy wrote: > On 2008-Aug-12 13:43:29 +0200, Marian Hettwer wrote: >>> lagg is to handle failover at the physical layer for when one of your >>> ether ports fails, or someone unplugs a cable. If I understand you >>> >>Thats unfortunate... > > I tend to agree. > >>bonding in Linux is capable of doing this and solaris too. > > It shouldn't be too difficult to create something that behaves > functionally similarly to Slowaris ipmpd (and with marginally more > effort, you could create something that could be configured to behave > sensibly). > har har. Yeah, you're right. But as Max pointed out, theres net/ifstated. I'll have a look into that tiny daemon :) Cheers, Marian From owner-freebsd-stable@FreeBSD.ORG Tue Aug 12 12:26:02 2008 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 456D41065689; Tue, 12 Aug 2008 12:26:02 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from constantine.ticketswitch.com (constantine.ticketswitch.com [IPv6:2002:57e0:1d4e:1::3]) by mx1.freebsd.org (Postfix) with ESMTP id 0EE5B8FC18; Tue, 12 Aug 2008 12:26:01 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from dilbert.rattatosk ([10.64.50.6] helo=dilbert.ticketswitch.com) by constantine.ticketswitch.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KSswq-000Hwe-DD; Tue, 12 Aug 2008 13:26:00 +0100 Received: from petefrench by dilbert.ticketswitch.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KSswq-000AcK-Bz; Tue, 12 Aug 2008 13:26:00 +0100 To: mat@FreeBSD.org In-Reply-To: <6338C16505B9465ED4A9CA76@andromede.in.absolight.net> Message-Id: From: Pete French Date: Tue, 12 Aug 2008 13:26:00 +0100 Cc: stable@FreeBSD.org Subject: Re: neighbor discovery problem X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2008 12:26:02 -0000 > The network is pretty simple, > > gateway : > em0: flags=8843 mtu 1500 > options=b > inet6 fe80::207:e9ff:fe0e:dead%em0 prefixlen 64 scopeid 0x1 > inet6 2a01:678:1:443:: prefixlen 64 > inet6 2a01:678:100:: prefixlen 48 Hmmm, are machine numbers of all zeroes legal in IPv6 ? I would configure those as '2a01:678:1:443::1' and '2a01:678:100::1' if I were you. All zeroes as a machine number is certainly a no-no in IPv4, and I wouldn't use it in IPv6 either. I have no idea if it's actually a problem, but it gives me a bad feeling.... -pete. From owner-freebsd-stable@FreeBSD.ORG Tue Aug 12 12:27:08 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 35898106566B for ; Tue, 12 Aug 2008 12:27:08 +0000 (UTC) (envelope-from smallhand@crawblog.com) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.170]) by mx1.freebsd.org (Postfix) with ESMTP id 1B0768FC19 for ; Tue, 12 Aug 2008 12:27:08 +0000 (UTC) (envelope-from smallhand@crawblog.com) Received: by wf-out-1314.google.com with SMTP id 24so2110579wfg.7 for ; Tue, 12 Aug 2008 05:27:07 -0700 (PDT) Received: by 10.142.171.6 with SMTP id t6mr2664245wfe.229.1218544027654; Tue, 12 Aug 2008 05:27:07 -0700 (PDT) Received: by 10.142.194.9 with HTTP; Tue, 12 Aug 2008 05:27:07 -0700 (PDT) Message-ID: <919383240808120527o5b8fcff7x1be5995a5df0abc8@mail.gmail.com> Date: Tue, 12 Aug 2008 07:27:07 -0500 From: "Edward Ruggeri" To: "Thomas Zander" In-Reply-To: <786602c60808120334h7edabf0dob804d7593113e7b2@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <919383240807230637o447d2763gd1802dc5f3dd4973@mail.gmail.com> <786602c60808120334h7edabf0dob804d7593113e7b2@mail.gmail.com> Cc: freebsd-stable@freebsd.org Subject: Re: Ath driver causes kernel panic (page fault) on 7.0-STABLE during use X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2008 12:27:08 -0000 On Tue, Aug 12, 2008 at 5:34 AM, Thomas Zander wrote: > Hi, > > On Wed, Jul 23, 2008 at 21:37, Edward Ruggeri wrote: > >> I recently purchased a Lenovo ThinkPad with a ThinkPad 11a/b/g >> Wireless LAN Mini Express Adapter (based on the AR5212 chipset). I >> got kernel panics while using the wireless card under 7-STABLE > > Do you still have this problem or did you find a workaround? > Does it look something like this? : > http://www.freebsd.org/cgi/query-pr.cgi?pr=126475 > > I upgraded my notebook from 6.3 to 7-STABLE on the weekend and get > reproducible kernel panics ~2 sec of using the ath network card. I never really got an answer about this bug. I'm sorry someone else has it. The bug went away when I updated world and rebuilt the kernel maybe two weeks ago. There didn't seem to be a recent change to the ath driver at the time, so maybe it was something outside it that caused the problem. It's hard to say... I am no longer on the freebsd-stable list, so if there's anything else I can do, please feel free to write me directly. Sincerely, -- Ned Ruggeri From owner-freebsd-stable@FreeBSD.ORG Tue Aug 12 12:53:29 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 56BA21065686 for ; Tue, 12 Aug 2008 12:53:29 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by mx1.freebsd.org (Postfix) with ESMTP id 04F838FC21 for ; Tue, 12 Aug 2008 12:53:28 +0000 (UTC) (envelope-from max@love2party.net) Received: from vampire.homelinux.org (dslb-088-066-034-213.pools.arcor-ip.net [88.66.34.213]) by mrelayeu.kundenserver.de (node=mrelayeu7) with ESMTP (Nemesis) id 0ML2xA-1KStNM3nE4-0003Lu; Tue, 12 Aug 2008 14:53:28 +0200 Received: (qmail 37733 invoked from network); 12 Aug 2008 12:53:24 -0000 Received: from fbsd8.laiers.local (192.168.4.151) by ns1.laiers.local with SMTP; 12 Aug 2008 12:53:24 -0000 From: Max Laier Organization: FreeBSD To: freebsd-stable@freebsd.org Date: Tue, 12 Aug 2008 14:53:24 +0200 User-Agent: KMail/1.10.0 (FreeBSD/8.0-CURRENT; KDE/4.1.0; i386; ; ) References: <6C5A5164866ACB760C1B37CA@andromede.in.absolight.net> In-Reply-To: <6C5A5164866ACB760C1B37CA@andromede.in.absolight.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200808121453.24383.max@love2party.net> X-Provags-ID: V01U2FsdGVkX18etFerlef5mM5E/rndTqDyN0x8iOFISWZiEcH KuKimeHRH5xkrXqHb0bZW+WmRf6nF7rEL8fTL4smwObl+ZfiCF jf1h/7GCiGrUEVX4XPsAw== Cc: Mathieu Arnold , Pete French Subject: Re: neighbor discovery problem X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2008 12:53:29 -0000 On Tuesday 12 August 2008 13:35:33 Mathieu Arnold wrote: > +-le 12.08.2008 12:02:42 +0100, Pete French a dit : > |> Since I added IPv6 to my network, and started really using it, I'm > |> seeing some strange things happening. > |> > |> For instance, I'm on machine 2a01:678:1:443::443, and I do : > |> > |> $ traceroute6 -n 2a01:678:100:2:: > |> traceroute6 to 2a01:678:100:2:: (2a01:678:100:2::) from > |> 2a01:678:1:443::443, 64 hops max, 12 byte packets > |> 1 2a01:678:1:443:: 0.636 ms 0.602 ms 0.525 ms > |> 2 2a01:678:1:443:: 2999.665 ms !A 2999.636 ms !A 2999.680 ms !A > |> > |> 2a01:678:1:443:: is it's default gateway, and is also directly connected > |> to 2a01:678:100:2::, but it does not seem to be able to contact it. > | > | What are your prefix lengths on the various interfaces, and does > | 2a01:678:100:2:: have a route back to 2a01:678:1:443::443 ? If you > | can show us the config on the interfaces of the three machines then > | we might be able to get a better idea. I am imagining how you have these > | three boxes connected in my head, but nothing beats an explanation plus > | the config :-) > > Hum, 2a01:678:1:443::443 is a /64, and 2a01:678:100:2:: is on a /48, both > have the "same" gateway, that is, the same box, which has : > inet6 2a01:678:1:443:: prefixlen 64 > inet6 2a01:678:100:: prefixlen 48 > > The problem I'm seeing is that before I ping the machine from the gateway, > all ndp -a says about this machine is : > > 2a01:678:100:2:: (incomplete) em0 1s I > 3 > > when I ping it from the first host, I see : > > 2a01:678:1:443::443 > 2a01:678:100:2::: ICMP6, echo request, seq 0, length > 16 fe80::207:e9ff:fe0e:dead > ff02::1:ff00:0: ICMP6, neighbor solicitation, > who has 2a01:678:100:2::, length 32 > fe80::207:e9ff:fe0e:dead > 2a01:678:1:443::443: ICMP6, redirect, ^------^ There is your problem. You have all three hosts connected to the same broadcast domain? Disable redirects or separate the domains using VLAN or similar - otherwise the gateway will get smart and try to avoid work. > 2a01:678:100:2:: to 2a01:678:100:2::, length 104 > fe80::2b0:d0ff:fee1:c05f > fe80::207:e9ff:fe0e:dead: ICMP6, neighbor > advertisement, tgt is 2a01:678:100:2::, length 32 > fe80::207:e9ff:fe0e:dead > ff02::1:ffe1:c05f: ICMP6, neighbor solicitation, > who has fe80::2b0:d0ff:fee1:c05f, length 32 > fe80::2b0:d0ff:fee1:c05f > fe80::207:e9ff:fe0e:dead: ICMP6, neighbor > advertisement, tgt is fe80::2b0:d0ff:fee1:c05f, length 32 > > and when I ping it from the gateway, I see : > > 2a01:678:100:25:: > 2a01:678:100::: ICMP6, neighbor solicitation, who has > 2a01:678:100::, length 32 > 2a01:678:100:: > 2a01:678:100:25::: ICMP6, neighbor advertisement, tgt is > 2a01:678:100::, length 24 > 2a01:678:100:: > ff02::1:ff00:0: ICMP6, neighbor solicitation, who has > 2a01:678:100:2::, length 32 > 2a01:678:100:2:: > 2a01:678:100::: ICMP6, neighbor advertisement, tgt is > 2a01:678:100:2::, length 32 > > And I don't understand why there's a difference, and why when the packets > don't come from the gateway, the neighbor solicitation goes up wrong and > does not work. > > |> Maybe I'm doing something wrong, but, well, I can't seem to find ou > |> what. > |> > |> 2a01:678:1:443::443 is a 7.0 > |> 2a01:678:1:443:: is a 6.2 > |> 2a01:678:100:2:: is a 6.0 > | > | I've used all of those with IPv6 and they work fine, it's most likely > | a small config problem. I had a lot of frustrations with IPv6 when I > | started using it - though now it is working I wouldn't be without it. > > Well, I'm certain it must be some stupid configuration problem, but, well, > I can't seem to find it :-) -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News From owner-freebsd-stable@FreeBSD.ORG Tue Aug 12 12:53:34 2008 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F0B63106567A for ; Tue, 12 Aug 2008 12:53:34 +0000 (UTC) (envelope-from mat@FreeBSD.org) Received: from plouf.absolight.net (plouf.absolight.net [79.143.240.136]) by mx1.freebsd.org (Postfix) with ESMTP id B1BC68FC27 for ; Tue, 12 Aug 2008 12:53:34 +0000 (UTC) (envelope-from mat@FreeBSD.org) Received: from gw.in.absolight.net (gw.in.absolight.net [79.143.241.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "gw.in.absolight.net", Issuer "CA Cert Signing Authority" (verified OK)) by plouf.absolight.net (Postfix) with ESMTP id 0816E764017; Tue, 12 Aug 2008 14:53:03 +0200 (CEST) Received: from andromede.in.absolight.net (andromede.in.absolight.net [79.143.241.226]) by gw.in.absolight.net (Postfix) with ESMTP id 717D56123; Tue, 12 Aug 2008 14:53:01 +0200 (CEST) Received: from localhost.in.absolight.net (localhost.in.absolight.net [127.0.0.1]) by andromede.in.absolight.net (8.14.2/8.14.2) with ESMTP id m7CCr0Uw082944; Tue, 12 Aug 2008 14:53:01 +0200 (CEST) (envelope-from mat@FreeBSD.org) Date: Tue, 12 Aug 2008 14:53:00 +0200 From: Mathieu Arnold To: Pete French Message-ID: <6BF9B03A4005DB29256F6F4A@andromede.in.absolight.net> In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========3674126C94FE99998E55==========" Cc: stable@FreeBSD.org Subject: Re: neighbor discovery problem X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2008 12:53:35 -0000 --==========3674126C94FE99998E55========== Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline +-le 12.08.2008 13:26:00 +0100, Pete French a dit : |> The network is pretty simple, |> |> gateway : |> em0: flags=8843 mtu 1500 |> options=b |> inet6 fe80::207:e9ff:fe0e:dead%em0 prefixlen 64 scopeid 0x1 |> inet6 2a01:678:1:443:: prefixlen 64 |> inet6 2a01:678:100:: prefixlen 48 | | Hmmm, are machine numbers of all zeroes legal in IPv6 ? I would | configure those as '2a01:678:1:443::1' and '2a01:678:100::1' if | I were you. All zeroes as a machine number is certainly a no-no in | IPv4, and I wouldn't use it in IPv6 either. I have no idea if it's | actually a problem, but it gives me a bad feeling.... Well, hum, I'm pretty sure there's no network and broadcast addresses in IPv6. Routing works, ping works, only neighbor discovery does strange things, from time to time. I'm a bit reluctant to change all that the eve of my going on vacation. I just discovered that I can't ping6 ff02::1%em0 on the gateway, well, I can, there are answers comming back, but, hum, they don't seem to sink in, and ping6 don't say anything. I'll investigate. -- Mathieu Arnold --==========3674126C94FE99998E55========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkihh6wACgkQJqR8av5thQ8aTACfVB7QFAyRDF2t1Ih6h0jTyXD6 MtEAn0NpdAJQVnqVJpxVduA4uebcDCeW =mgEE -----END PGP SIGNATURE----- --==========3674126C94FE99998E55==========-- From owner-freebsd-stable@FreeBSD.ORG Tue Aug 12 13:08:33 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BC4BF106564A for ; Tue, 12 Aug 2008 13:08:33 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 2FAE28FC14 for ; Tue, 12 Aug 2008 13:08:33 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from zion.baldwin.cx (zion.baldwin.cx [IPv6:2001:470:1f11:75:2a0:d2ff:fe18:8b38]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m7CD866E078642; Tue, 12 Aug 2008 09:08:26 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-stable@freebsd.org Date: Tue, 12 Aug 2008 09:05:48 -0400 User-Agent: KMail/1.9.7 References: <200808110401.49953.kuuse@redantigua.com> <200808111704.30604.jhb@freebsd.org> <200808120842.52899.kuuse@redantigua.com> In-Reply-To: <200808120842.52899.kuuse@redantigua.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200808120905.48528.jhb@freebsd.org> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:2001:470:1f11:75::1]); Tue, 12 Aug 2008 09:08:26 -0400 (EDT) X-Virus-Scanned: ClamAV 0.93.1/8018/Tue Aug 12 04:36:31 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Johan Kuuse Subject: Re: kernel panic X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2008 13:08:33 -0000 On Tuesday 12 August 2008 02:42:52 am Johan Kuuse wrote: > On Monday 11 August 2008 23:04:30 John Baldwin wrote: > > On Sunday 10 August 2008 10:01:49 pm Johan Kuuse wrote: > > > Hi, > > > > > > I am a kgdb newbie, so please be patient. > > > I suspect (just based on the fact that this is the 4th time I edit text > > > > files on my NTFS partition through ntfs-3g, using Emacs, and getting > > frequent I/O error messages inside Emacs, and then a kernel panic) that > > this is a ntfs-3g related problem. > > > > > If you ask me exactly how to reproduce it, I sorry, I can tell you > > > exactly > > > > (but see the kgdb output below). > > > > > Anyway, the kernel seems to panic at /usr/src/sys/kern/vfs_bio.c:1530 > > > > > > Just a suggestion for a patch (without knowing the functionality > > > > of /usr/src/sys/kern/vfs_bio.c): > > > The line where the kernel panics: > > > /usr/src/sys/kern/vfs_bio.c: > > > ---------------------------------- > > > VM_OBJECT_LOCK(bp->b_bufobj->bo_object); > > > ... > > > ---------------------------------- > > > > > > Comparing to another file, which does error checking before calling > > > > VM_OBJECT_LOCK: > > > /usr/src/sys/kern/vfs_aio.c: > > > ---------------------------------- > > > if (vp->v_object != NULL) { > > > VM_OBJECT_LOCK(vp->v_object); > > > ... > > > ---------------------------------- > > > > > > Perhaps the kernel panic could be avoided with the following patch? > > > /usr/src/sys/kern/vfs_bio.c (suggested patch): > > > ---------------------------------- > > > if ((bp->b_bufobj != NULL) && (bp->b_bufobj->bo_object != NULL)) { > > > VM_OBJECT_LOCK(bp->b_bufobj->bo_object); > > > ... > > > ---------------------------------- > > > > > > Please let me know if you need more information. > > > > > > Regards, > > > Johan Kuuse > > > > > > ----------------------------------------------------------------------- > > >------------------------------------ kgdb kernel.debug > > > /var/crash/vmcore.1 > > > [GDB will not be able to debug user-mode threads: > > > /usr/lib/libthread_db.so: > > > > Undefined symbol "ps_pglobal_lookup"] > > > > > GNU gdb 6.1.1 [FreeBSD] > > > Copyright 2004 Free Software Foundation, Inc. > > > GDB is free software, covered by the GNU General Public License, and > > > you are welcome to change it and/or distribute copies of it under > > > certain > > > > conditions. > > > > > Type "show copying" to see the conditions. > > > There is absolutely no warranty for GDB. Type "show warranty" for > > > details. This GDB was configured as "i386-marcel-freebsd". > > > > > > Unread portion of the kernel message buffer: > > > > > > > > > Fatal trap 12: page fault while in kernel mode > > > cpuid = 0; apic id = 00 > > > fault virtual address = 0x34 > > > fault code = supervisor read, page not present > > > instruction pointer = 0x20:0xc07b6de4 > > > stack pointer = 0x28:0xe79de7c8 > > > frame pointer = 0x28:0xe79de7e8 > > > code segment = base 0x0, limit 0xfffff, type 0x1b > > > = DPL 0, pres 1, def32 1, gran 1 > > > processor eflags = interrupt enabled, resume, IOPL = 0 > > > current process = 1214 (opera) > > > trap number = 12 > > > panic: page fault > > > cpuid = 0 > > > Uptime: 5h20m30s > > > Physical memory: 2035 MB > > > Dumping 218 MB: 203 187 171 155 139 123 107 91 75 59 43 27 11 > > > > > > #0 doadump () at pcpu.h:195 > > > 195 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); > > > (kgdb) list *0xc07b6de4 > > > 0xc07b6de4 is in vfs_vmio_release (/usr/src/sys/kern/vfs_bio.c:1530). > > > 1525 vfs_vmio_release(struct buf *bp) > > > 1526 { > > > 1527 int i; > > > 1528 vm_page_t m; > > > 1529 > > > 1530 VM_OBJECT_LOCK(bp->b_bufobj->bo_object); > > > 1531 vm_page_lock_queues(); > > > 1532 for (i = 0; i < bp->b_npages; i++) { > > > 1533 m = bp->b_pages[i]; > > > 1534 bp->b_pages[i] = NULL; > > > (kgdb) bt > > > #0 doadump () at pcpu.h:195 > > > #1 0xc0754457 in boot (howto=260) at > > > /usr/src/sys/kern/kern_shutdown.c:409 #2 0xc0754719 in panic > > > (fmt=Variable "fmt" is not available. > > > ) at /usr/src/sys/kern/kern_shutdown.c:563 > > > #3 0xc0a4905c in trap_fatal (frame=0xe79de788, eva=52) > > > > at /usr/src/sys/i386/i386/trap.c:899 > > > > > #4 0xc0a492e0 in trap_pfault (frame=0xe79de788, usermode=0, eva=52) > > > > at /usr/src/sys/i386/i386/trap.c:812 > > > > > #5 0xc0a49c8c in trap (frame=0xe79de788) > > > > at /usr/src/sys/i386/i386/trap.c:490 > > > > > #6 0xc0a2fc0b in calltrap () at /usr/src/sys/i386/i386/exception.s:139 > > > #7 0xc07b6de4 in vfs_vmio_release (bp=0xd927e33c) > > > > at /usr/src/sys/kern/vfs_bio.c:1530 > > > > > #8 0xc07b8a81 in getnewbuf (slpflag=0, slptimeo=0, size=Variable > > > "size" is > > > > not available. > > > > > ) at /usr/src/sys/kern/vfs_bio.c:1847 > > > #9 0xc07ba118 in getblk (vp=0xc8891bb0, blkno=0, size=2048, slpflag=0, > > > > slptimeo=0, flags=Variable "flags" is not available. > > > > > ) at /usr/src/sys/kern/vfs_bio.c:2602 > > > #10 0xc0932815 in ffs_balloc_ufs2 (vp=0xc8891bb0, > > > > startoffset=Variable "startoffset" is not available. > > > > > ) at /usr/src/sys/ufs/ffs/ffs_balloc.c:699 > > > #11 0xc0952a85 in ffs_write (ap=0xe79debc4) > > > > at /usr/src/sys/ufs/ffs/ffs_vnops.c:720 > > > > > #12 0xc0a5efc6 in VOP_WRITE_APV (vop=0xc0b93c60, a=0xe79debc4) at > > > > vnode_if.c:691 > > > > > #13 0xc07dbf37 in vn_write (fp=0xc85f3168, uio=0xe79dec60, > > > > active_cred=0xc61c6300, flags=0, td=0xc583fc60) at vnode_if.h:373 > > > > > #14 0xc07875e7 in dofilewrite (td=0xc583fc60, fd=17, fp=0xc85f3168, > > > > auio=0xe79dec60, offset=-1, flags=0) at file.h:254 > > > > > #15 0xc07878c8 in kern_writev (td=0xc583fc60, fd=17, auio=0xe79dec60) > > > > at /usr/src/sys/kern/sys_generic.c:401 > > > > > #16 0xc078793f in write (td=0xc583fc60, uap=0xe79decfc) > > > > at /usr/src/sys/kern/sys_generic.c:317 > > > > > #17 0xc0a49635 in syscall (frame=0xe79ded38) > > > > at /usr/src/sys/i386/i386/trap.c:1035 > > > > > #18 0xc0a2fc70 in Xint0x80_syscall () > > > > at /usr/src/sys/i386/i386/exception.s:196 > > > > > #19 0x00000033 in ?? () > > > Previous frame inner to this frame (corrupt stack?) > > > > FYI, you got the panic in ffs/ufs, not fuse. I've seen this at work on > > 6.x with NFS with no clues on what causes it. You can start by going to > > frame 7 and doing 'p *bp'. > > Thanks for the hints. > See below for more debug output. > I recognize that the bp struct members b_data and b_kvabase both point to a > chunk of memory containing the text of the Opera web page I was reading > when the kernel crashed. (This is indicated above: current process > = 1214 (opera)) > > But what is most interesting is that b_bufobj = 0x0 > Obviously, then trying to access bp->b_bufobj->bo_object will cause a > crash. So I think it would be a good idea to NULL-check the struct member > before trying to access it. How should I proceed? Should I post this as a > possible bug somewhere else, to another list? Unfortunately, it is a worse problem that b_bufobj is NULL. That means there is a bug elsewhere. I'll look at this some more. Hmm, can you reproduce this at all? If so, can you try the patch below. Hopefully it panics here which might help: Index: vfs_subr.c =================================================================== --- vfs_subr.c (revision 181629) +++ vfs_subr.c (working copy) @@ -1546,6 +1546,9 @@ CTR3(KTR_BUF, "brelvp(%p) vp %p flags %X", bp, bp->b_vp, bp->b_flags); KASSERT(bp->b_vp != NULL, ("brelvp: NULL")); + if (bp->flags & B_VMIO) + panic("brelvp of B_VMIO buffer"); + /* * Delete from old vnode list, if on one. */ -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Tue Aug 12 13:24:31 2008 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 68B72106566C; Tue, 12 Aug 2008 13:24:31 +0000 (UTC) (envelope-from mat@FreeBSD.org) Received: from plouf.absolight.net (mx3.absolight.net [IPv6:2a01:678:100:1::25]) by mx1.freebsd.org (Postfix) with ESMTP id 2F0B78FC20; Tue, 12 Aug 2008 13:24:31 +0000 (UTC) (envelope-from mat@FreeBSD.org) Received: from gw.in.absolight.net (gw.in.absolight.net [79.143.241.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "gw.in.absolight.net", Issuer "CA Cert Signing Authority" (verified OK)) by plouf.absolight.net (Postfix) with ESMTP id 96F7F764017; Tue, 12 Aug 2008 15:24:28 +0200 (CEST) Received: from andromede.in.absolight.net (andromede.in.absolight.net [79.143.241.226]) by gw.in.absolight.net (Postfix) with ESMTP id AE4316123; Tue, 12 Aug 2008 15:24:27 +0200 (CEST) Received: from localhost.in.absolight.net (localhost.in.absolight.net [127.0.0.1]) by andromede.in.absolight.net (8.14.2/8.14.2) with ESMTP id m7CDORa5089753; Tue, 12 Aug 2008 15:24:27 +0200 (CEST) (envelope-from mat@FreeBSD.org) Date: Tue, 12 Aug 2008 15:24:27 +0200 From: Mathieu Arnold To: Mathieu Arnold Message-ID: In-Reply-To: <6BF9B03A4005DB29256F6F4A@andromede.in.absolight.net> References: <6BF9B03A4005DB29256F6F4A@andromede.in.absolight.net> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========CA8E1EE7A4510F64BC7F==========" Cc: stable@FreeBSD.org Subject: Re: neighbor discovery problem X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2008 13:24:31 -0000 --==========CA8E1EE7A4510F64BC7F========== Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline +-le 12.08.2008 14:53:00 +0200, Mathieu Arnold a dit : | I'll investigate. Ok, I rebooted the gateway, and now, it works just as it should... Maybe once upon a time, I did something strange, which borked everything... Anyway, thanks all :-) -- Mathieu Arnold --==========CA8E1EE7A4510F64BC7F========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkihjwsACgkQJqR8av5thQ8IDQCgqEYbST1i1Xgt3IvINm/a3rDK CHsAoPO2DIW6kdP1ICeauw8NxO5oaln5 =rtvk -----END PGP SIGNATURE----- --==========CA8E1EE7A4510F64BC7F==========-- From owner-freebsd-stable@FreeBSD.ORG Tue Aug 12 13:30:08 2008 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B405F1065674 for ; Tue, 12 Aug 2008 13:30:08 +0000 (UTC) (envelope-from mat@FreeBSD.org) Received: from plouf.absolight.net (mx3.absolight.net [IPv6:2a01:678:100:1::25]) by mx1.freebsd.org (Postfix) with ESMTP id 79C978FC1A for ; Tue, 12 Aug 2008 13:30:08 +0000 (UTC) (envelope-from mat@FreeBSD.org) Received: from gw.in.absolight.net (gw.in.absolight.net [79.143.241.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "gw.in.absolight.net", Issuer "CA Cert Signing Authority" (verified OK)) by plouf.absolight.net (Postfix) with ESMTP id 5CF50764008; Tue, 12 Aug 2008 15:30:07 +0200 (CEST) Received: from andromede.in.absolight.net (andromede.in.absolight.net [79.143.241.226]) by gw.in.absolight.net (Postfix) with ESMTP id 6DF466123; Tue, 12 Aug 2008 15:30:06 +0200 (CEST) Received: from localhost.in.absolight.net (localhost.in.absolight.net [127.0.0.1]) by andromede.in.absolight.net (8.14.2/8.14.2) with ESMTP id m7CDU3GZ090955; Tue, 12 Aug 2008 15:30:06 +0200 (CEST) (envelope-from mat@FreeBSD.org) Date: Tue, 12 Aug 2008 15:30:03 +0200 From: Mathieu Arnold To: Max Laier Message-ID: <9844F31DF77772473EAA9E2C@andromede.in.absolight.net> In-Reply-To: <200808121453.24383.max@love2party.net> References: <6C5A5164866ACB760C1B37CA@andromede.in.absolight.net> <200808121453.24383.max@love2party.net> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========D16DD878328D26CF0DCB==========" Cc: freebsd-stable@FreeBSD.org Subject: Re: neighbor discovery problem X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2008 13:30:08 -0000 --==========D16DD878328D26CF0DCB========== Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline +-le 12.08.2008 14:53:24 +0200, Max Laier a dit : |> 2a01:678:1:443::443 > 2a01:678:100:2::: ICMP6, echo request, seq 0, length |> 16 fe80::207:e9ff:fe0e:dead > ff02::1:ff00:0: ICMP6, neighbor solicitation, |> who has 2a01:678:100:2::, length 32 |> fe80::207:e9ff:fe0e:dead > 2a01:678:1:443::443: ICMP6, redirect, | ^------^ | | There is your problem. You have all three hosts connected to the same | broadcast domain? Disable redirects or separate the domains using VLAN or | similar - otherwise the gateway will get smart and try to avoid work. Hum, yes, the same domain, but it must not have been the problem, now, it works, and I still have : fe80::207:e9ff:fe0e:dead > ff02::1:ff00:0: ICMP6, neighbor solicitation, who has 2a01:678:100:2::, length 32 fe80::207:e9ff:fe0e:dead > 2a01:678:1:443::443: ICMP6, redirect, 2a01:678:100:2:: to 2a01:678:100:2::, length 104 fe80::2b0:d0ff:fee1:c05f > fe80::207:e9ff:fe0e:dead: ICMP6, neighbor advertisement, tgt is 2a01:678:100:2::, length 32 but it works. -- Mathieu Arnold --==========D16DD878328D26CF0DCB========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkihkFsACgkQJqR8av5thQ+p5QCg1LzKwF9p6vHndtijpXvaDH4m 5wwAnju+LpGZgInXcKCD4K81IwEEBfsR =AYq1 -----END PGP SIGNATURE----- --==========D16DD878328D26CF0DCB==========-- From owner-freebsd-stable@FreeBSD.ORG Tue Aug 12 15:15:27 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E9CA61065677 for ; Tue, 12 Aug 2008 15:15:27 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 671758FC20 for ; Tue, 12 Aug 2008 15:15:27 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [IPv6:::1]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m7CFFIbG079614; Tue, 12 Aug 2008 11:15:20 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: pluknet Date: Tue, 12 Aug 2008 11:11:36 -0400 User-Agent: KMail/1.9.7 References: <20080730113449.GD407@cdnetworks.co.kr> <200808111315.23879.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200808121111.37427.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Tue, 12 Aug 2008 11:15:20 -0400 (EDT) X-Virus-Scanned: ClamAV 0.93.1/8018/Tue Aug 12 04:36:31 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: freebsd-stable@freebsd.org, Ulrich Spoerlein Subject: Re: cpufreq(4) panic on RELENG_7 (was: Re: Call for bfe(4) testers.) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2008 15:15:28 -0000 On Tuesday 12 August 2008 04:36:29 am pluknet wrote: > 2008/8/11 John Baldwin : > > On Monday 11 August 2008 12:35:17 pm pluknet wrote: > >> 2008/8/11 John Baldwin : > >> > On Saturday 09 August 2008 07:16:37 am Ulrich Spoerlein wrote: > >> >> Hi John, > >> >> > >> >> I now figured out the "who", the "why" still eludes me. > >> >> > >> >> So, after your MFC of ichss.c on June 27th the device now attaches = at=20 my > >> >> laptop. It didn't before, so it could cause no trouble. > >> >> > >> >> With ichss loaded, the kernel will panic 1-3 minutes after powerd h= as > >> >> been started (if I kill powerd early enough, it seems pretty stable= ). > >> >> > >> >> I'm now running a kernel from 2008-08-08 with > >> >> hint.ichss.0.disabled=3D"1" > >> > > >> > Ok. Can you get a crashdump from a crash? > >> > > >> > >> ehm,. I am not Ulrich Spoerlein, but I can help with this issue. > >> > >> my crashdump from kgdb and some debug info. > >> (ouch, I forgot to include it in my prev. mail > >>=20 http://lists.freebsd.org/pipermail/freebsd-stable/2008-August/044182.html ) > >> > >> wbr, > >> pluknet > >> > >> Unread portion of the kernel message buffer: > >> > >> > >> Fatal trap 12: page fault while in kernel mode > >> fault virtual address =3D 0x38 > >> fault code =3D supervisor read, page not present > >> instruction pointer =3D 0x20:0xc056cf46 > >> stack pointer =3D 0x28:0xe6592ac8 > >> frame pointer =3D 0x28:0xe6592ac8 > >> code segment =3D base 0x0, limit 0xfffff, type 0x1b > >> =3D DPL 0, pres 1, def32 1, gran 1 > >> processor eflags =3D interrupt enabled, resume, IOPL =3D 0 > >> current process =3D 2507 (powerd) > >> Physical memory: 1014 MB > >> Dumping 120 MB: 105 89 73 57 41 25 9 > >> > >> #0 doadump () at pcpu.h:195 > >> 195 pcpu.h: No such file or directory. > >> in pcpu.h > >> (kgdb) bt > >> #0 doadump () at pcpu.h:195 > >> #1 0xc0458f89 in db_fncall (dummy1=3D-1010027648, dummy2=3D0, dummy3= =3D0, > >> dummy4=3D0xe6592860 "0=AC=CA=C3") at /media/src-7/sys/ddb/db_comma= nd.c:516 > >> #2 0xc045953a in db_command (last_cmdp=3D0xc07dcf14, cmd_table=3D0x0, > > dopager=3D1) > >> at /media/src-7/sys/ddb/db_command.c:413 > >> #3 0xc0459655 in db_command_loop () > > at /media/src-7/sys/ddb/db_command.c:466 > >> #4 0xc045b17c in db_trap (type=3D12, code=3D0) > >> at /media/src-7/sys/ddb/db_main.c:228 > >> #5 0xc0575023 in kdb_trap (type=3D12, code=3D0, tf=3D0xe6592a88) > >> at /media/src-7/sys/kern/subr_kdb.c:524 > >> #6 0xc07460bf in trap_fatal (frame=3D0xe6592a88, eva=3D56) > >> at /media/src-7/sys/i386/i386/trap.c:890 > >> #7 0xc074636b in trap_pfault (frame=3D0xe6592a88, usermode=3D0, eva= =3D56) > >> at /media/src-7/sys/i386/i386/trap.c:812 > >> #8 0xc0746d36 in trap (frame=3D0xe6592a88) > >> at /media/src-7/sys/i386/i386/trap.c:490 > >> #9 0xc072fd4b in calltrap ()=20 at /media/src-7/sys/i386/i386/exception.s:139 > >> #10 0xc056cf46 in device_is_attached (dev=3D0x0) > >> at /media/src-7/sys/kern/subr_bus.c:2228 > >> #11 0xc0512de7 in cf_set_method (dev=3D0xc3c9c880, level=3D0xc4525ef4, > >> priority=3D100) at /media/src-7/sys/kern/kern_cpu.c:332 > >> #12 0xc0511452 in cpufreq_curr_sysctl (oidp=3D0xc3c8bac0, arg1=3D0xc3b= c7c00, > >> arg2=3D0, req=3D0xe6592ba4) at cpufreq_if.h:32 > >> ---Type to continue, or q to quit--- > >> #13 0xc0554b67 in sysctl_root (oidp=3DVariable "oidp" is not available. > >> ) > >> at /media/src-7/sys/kern/kern_sysctl.c:1306 > >> #14 0xc0554cd1 in userland_sysctl (td=3D0xc4245440, name=3D0xe6592c14, > > namelen=3D4, > >> old=3D0x0, oldlenp=3D0x0, inkernel=3D0, new=3D0xbfbfe7c4, newlen= =3D4, > >> retval=3D0xe6592c10, flags=3D0)=20 at /media/src-7/sys/kern/kern_sysctl.c:1401 > >> #15 0xc0555a7c in __sysctl (td=3D0xc4245440, uap=3D0xe6592cfc) > >> at /media/src-7/sys/kern/kern_sysctl.c:1336 > >> #16 0xc07466d5 in syscall (frame=3D0xe6592d38) > >> at /media/src-7/sys/i386/i386/trap.c:1035 > >> #17 0xc072fdb0 in Xint0x80_syscall () > >> at /media/src-7/sys/i386/i386/exception.s:196 > >> #18 0x00000033 in ?? () > >> Previous frame inner to this frame (corrupt stack?) > >> (kgdb) f 11 > >> #11 0xc0512de7 in cf_set_method (dev=3D0xc3c9c880, level=3D0xc4525ef4, > >> priority=3D100) at /media/src-7/sys/kern/kern_cpu.c:332 > >> 332 if (!device_is_attached(set->dev)) { > >> (kgdb) list > >> 327 } > >> 328 > >> 329 /* Next, set any/all relative frequencies via their=20 drivers. > > */ > >> 330 for (i =3D 0; i < level->rel_count; i++) { > >> 331 set =3D &level->rel_set[i]; > >> 332 if (!device_is_attached(set->dev)) { > >> 333 error =3D ENXIO; > >> 334 goto out; > >> 335 } > >> 336 > >> (kgdb) p level.rel_count > >> $1 =3D 1986356271 > >> (kgdb) p i > >> $2 =3D 0 > >> (kgdb) p level.rel_set > >> $3 =3D {{freq =3D 0, volts =3D 0, power =3D 0, lat =3D 0, dev =3D 0x0,= spec =3D {0, 0,=20 0, > >> 0}}, {freq =3D 0, volts =3D 0, power =3D 0, lat =3D 0, dev =3D 0= x0, spec =3D=20 {0, > > 0, > >> 0, 0}}, {freq =3D 0, volts =3D 0, power =3D 0, lat =3D 0, dev = =3D 0x0, spec =3D > > {0, > >> 0, 0, 0}}, {freq =3D 0, volts =3D 0, power =3D 0, lat =3D 0, dev= =3D 0x0,=20 spec =3D > > { > >> 0, 0, 0, 0}}, {freq =3D 0, volts =3D 0, power =3D 0, lat =3D 0, = dev =3D 0x0, > >> spec =3D {0, 0, 0, 0}}, {freq =3D 0, volts =3D 0, power =3D 0, lat= =3D 0, > >> dev =3D 0x656e7552, spec =3D {828858701, 1162760014, 0, 134632492}= }, { > >> freq =3D 0, volts =3D 53, power =3D -1024, lat =3D -1, dev =3D 0x7= fffffff, spec=20 =3D > > { > >> ----- and so on----- > >> > >> Also there are very unusual (and high) numbers in sysctl > > dev.cpu.0.freq_levels. > > > > Which cpufreq drivers are you using? Can you narrow down your panics (= and > > weird frequencies in the sysctl) to being caused by a specific cpufreq > > driver? >=20 > They are est/p4tcc/ichss. > hint.ichss.0.disbled=3D"1" helped me to avoid panics and those weired > freqs in dev.cpu. > Now it shows: > cpu0: on acpi0 > est0: on cpu0 > p4tcc0: on cpu0 > and dev.cpu.0.freq_levels are as expected (and as it was earlier > before this problem): > 1600/-1 1400/-1 1225/-1 1200/-1 1050/-1 1000/-1 875/-1 800/-1 700/-1 > 600/-1 525/-1 450/-1 375/-1 300/-1 225/-1 150/-1 75/-1 Try http://www.freebsd.org/~jhb/patches/cpufreq_order.patch ichss0 is only= =20 supposed to be used if you don't have est0, and this patch fixes that. I'm= =20 curious if you get panics if you have disable est0 and leave ichss0 enabled= =20 or if that works ok? =2D-=20 John Baldwin From owner-freebsd-stable@FreeBSD.ORG Tue Aug 12 15:46:36 2008 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D745C106564A for ; Tue, 12 Aug 2008 15:46:36 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from pele.citylink.co.nz (pele.citylink.co.nz [202.8.44.226]) by mx1.freebsd.org (Postfix) with ESMTP id 98DAF8FC1B for ; Tue, 12 Aug 2008 15:46:36 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) by pele.citylink.co.nz (Postfix) with ESMTP id 715F52BDAC; Wed, 13 Aug 2008 03:46:34 +1200 (NZST) X-Virus-Scanned: Debian amavisd-new at citylink.co.nz Received: from pele.citylink.co.nz ([127.0.0.1]) by localhost (pele.citylink.co.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T1NFg+noGFuP; Wed, 13 Aug 2008 03:46:29 +1200 (NZST) Received: from citylink.fud.org.nz (unknown [202.8.44.45]) by pele.citylink.co.nz (Postfix) with ESMTP; Wed, 13 Aug 2008 03:46:29 +1200 (NZST) Received: by citylink.fud.org.nz (Postfix, from userid 1001) id CAB861142D; Wed, 13 Aug 2008 03:46:28 +1200 (NZST) Date: Tue, 12 Aug 2008 08:46:28 -0700 From: Andrew Thompson To: Marian Hettwer Message-ID: <20080812154628.GA45850@citylink.fud.org.nz> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Cc: stable@freebsd.org Subject: Re: lagg(4) and failover X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2008 15:46:36 -0000 On Tue, Aug 12, 2008 at 12:37:15PM +0200, Marian Hettwer wrote: > Hi Folks, > > I'm using lagg(4) on some of our servers and I'm just wondering how the > failover is implemented. > The manpage isn't quite clear: > > failover Sends and receives traffic only through the master port. > If > the master port becomes unavailable, the next active port > is > used. The first interface added is the master port; any > interfaces added after that are used as failover devices. > > What is meant by "becomes unavailable"? Is it just the physical link which > needs to become unavailable to trigger a failover? > > I do wonder, because there might be other faults where the link is still > active, but the port is unusable. Think of a wrong vlan on the switch > itself. > > When using bonding under Linux (yeah, I know, the configuration sucks ;) ), > I can configure the device to check for arp respones of it's default > gateway. If arp to the default gw becomes unavailable, bonding fails over > to the next interface and tries it luck over there. > With that kind of configuration, I could cover a misconfigured switch port > and still have failover. > > Long Story short: How is failover in lagg(4) implemented? It is simply performed on the physical link state, nothing more. Adding smarter methods of detecting the link such as what Linux does are very welcome. You may want to also look at LACP mode where heatbeat frames are exchanged with the peer. Andrew From owner-freebsd-stable@FreeBSD.ORG Tue Aug 12 15:50:21 2008 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E9A141065674 for ; Tue, 12 Aug 2008 15:50:21 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from pele.citylink.co.nz (pele.citylink.co.nz [202.8.44.226]) by mx1.freebsd.org (Postfix) with ESMTP id AE49D8FC13 for ; Tue, 12 Aug 2008 15:50:21 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) by pele.citylink.co.nz (Postfix) with ESMTP id 899AA2BDAC; Wed, 13 Aug 2008 03:50:20 +1200 (NZST) X-Virus-Scanned: Debian amavisd-new at citylink.co.nz Received: from pele.citylink.co.nz ([127.0.0.1]) by localhost (pele.citylink.co.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J6+-SLHECK5N; Wed, 13 Aug 2008 03:50:16 +1200 (NZST) Received: from citylink.fud.org.nz (unknown [202.8.44.45]) by pele.citylink.co.nz (Postfix) with ESMTP; Wed, 13 Aug 2008 03:50:16 +1200 (NZST) Received: by citylink.fud.org.nz (Postfix, from userid 1001) id 60A441142C; Wed, 13 Aug 2008 03:50:16 +1200 (NZST) Date: Tue, 12 Aug 2008 08:50:16 -0700 From: Andrew Thompson To: Peter Jeremy Message-ID: <20080812155016.GB45850@citylink.fud.org.nz> References: <20080812105552.GA89695@svzserv.kemerovo.su> <20080812112430.GC64458@server.vk2pj.dyndns.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080812112430.GC64458@server.vk2pj.dyndns.org> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: stable@freebsd.org, Eugene Grosbein , Marian Hettwer Subject: Re: lagg(4) and failover X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2008 15:50:22 -0000 On Tue, Aug 12, 2008 at 09:24:30PM +1000, Peter Jeremy wrote: > On 2008-Aug-12 18:55:52 +0800, Eugene Grosbein wrote: > >On Tue, Aug 12, 2008 at 12:37:15PM +0200, Marian Hettwer wrote: > > > >> I'm using lagg(4) on some of our servers and I'm just wondering how the > >> failover is implemented. > > As far as I can tell, not especially well :-(. It doesn't seem to detect > much short of layer 1 failure. In particular, shutting down the switch > port will not trigger a failover. > > >> The manpage isn't quite clear: > >> > >> failover Sends and receives traffic only through the master port. > >> If > >> the master port becomes unavailable, the next active port > >> is > >> used. The first interface added is the master port; any > >> interfaces added after that are used as failover devices. > >> > >> What is meant by "becomes unavailable"? Is it just the physical link which > >> needs to become unavailable to trigger a failover? > > It seems to be, > > >Yes. It seems you need lacp protocol described later in the manual. > > Actually, lacp and failover are used differently: lacp is primarily > used to increase the bandwidth between the host and the switch whilst > failover is used for redundancy. > > With lacp, all the physical interfaces must be connected to a single > switch. With failover, the physical interfaces will normally be > connected to different switches (so a failure in one switch will not > cause the loss of all connectivity. Actually you can use lacp in failover mode by connecting interfaces to different switches. It will only bundle an aggregation to one switch at a time but if that becomes unavailable then it will automatically choose the next switch. Andrew From owner-freebsd-stable@FreeBSD.ORG Tue Aug 12 16:45:43 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 28BAC106567D for ; Tue, 12 Aug 2008 16:45:43 +0000 (UTC) (envelope-from wahjava@gmail.com) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.187]) by mx1.freebsd.org (Postfix) with ESMTP id 913848FC12 for ; Tue, 12 Aug 2008 16:45:42 +0000 (UTC) (envelope-from wahjava@gmail.com) Received: by ti-out-0910.google.com with SMTP id d27so1278970tid.3 for ; Tue, 12 Aug 2008 09:45:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:subject :message-id:mail-followup-to:references:mime-version:content-type :content-disposition:in-reply-to:x-face:x-attribution:x-os-kernel :x-os-version:x-os-architecture:x-uptime:x-url:x-mail-morse :x-openpgp-fingerprint:x-openpgp-id:face:organization:user-agent :sender; bh=sGIWs2sMss+NT12nM8dzINMAJbpu6o79tTecZS+YSCY=; b=LC1YJA/187XHuQiN4WBhmUu86QqWh1X0sZe5OwJAwSLcBLCSm4MFQ0e7lwl+dmoKHg EeRzh73YHS6rdNDBksX7en6oDF5acp6dFWi/mEEH4TNQtvM5kGzm13EXbC2wWO+vw3Px xDgpy/Vx6YhbO5OgXuX/gIqWG48rP+Tfe6Qzw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:subject:message-id:mail-followup-to:references :mime-version:content-type:content-disposition:in-reply-to:x-face :x-attribution:x-os-kernel:x-os-version:x-os-architecture:x-uptime :x-url:x-mail-morse:x-openpgp-fingerprint:x-openpgp-id:face :organization:user-agent:sender; b=apaA0Viy+CEZ+N8rk70bDTNcHVc8QD3SlI94wwE2Hz0xcfq7Mc3EdZZpY4Q93QK5aT 77C8TSiTdRakqJzJQQtGQZXtJhNqpVroTtRWiXuZoCrpfWI0RTjEAj3hUgq27bMX8eqi Nq/peh+TdeyFMMhHvWw3xM7imqJ9uxD9JgHuQ= Received: by 10.110.95.15 with SMTP id s15mr11328445tib.40.1218558014580; Tue, 12 Aug 2008 09:20:14 -0700 (PDT) Received: from chateau.d.lf ( [122.162.250.50]) by mx.google.com with ESMTPS id w12sm102957tib.1.2008.08.12.09.20.11 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 12 Aug 2008 09:20:13 -0700 (PDT) Date: Tue, 12 Aug 2008 21:51:34 +0530 From: =?unknown-8bit?B?4KSG4KS24KWA4KS3IOCktuClgeCkleCljeCk?= =?unknown-8bit?Q?=B2?= Ashish Shukla To: freebsd-stable@freebsd.org Message-ID: <20080812162134.GA2652@chateau.d.lf> Mail-Followup-To: freebsd-stable@freebsd.org References: <6338C16505B9465ED4A9CA76@andromede.in.absolight.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3MwIy2ne0vdjdPXF" Content-Disposition: inline In-Reply-To: X-Face: )vGQ9yK7Y$Flebu1C>(B\gYBm)[$zfKM+p&TT[[JWl6:]S>cc$%-z7-`46Zf0B*syL.C ]oCq[upTG~zuS0.$"_%)|Q@$hA=9{3l{%u^h3jJ^Zl;t7 X-Attribution: =?unknown-8bit?B?4KSG4KS24KWA4KS3?= X-OS-Kernel: Linux X-OS-Version: 2.6.25-gentoo-r7 X-OS-Architecture: x86_64 X-Uptime: 21:21:27 up 3:02, 1 user, load average: 0.00, 0.05, 0.07 X-URL: http://wahjava.wordpress.com/ X-Mail-Morse: .-- .- .... .--- .- ...- .- .--.-. --. -- .- .. .-.. .-.-.- -.-. --- -- X-OpenPGP-Fingerprint: 1E00 4679 77E4 F8EE 2E4B 56F2 1F2F 8410 762E 5E74 X-OpenPGP-ID: 762E5E74 Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAMFBMVEWpqambm5uHh4d7e3 ttbW1jY2Pe3t4dHR28vLygoKCenp6SkpJOTk7////9/f35+flcgqXsAAACiUlEQVQ4jX XTz0sUURwA8NlOrkS5ZqIzUO6sCTaBMKuYrVCsM7cgyJ066EUMC5KVgnoEHlY7uJTYbn loBilH6TBvL40a5goZqexl/gWHjl72O+hh8dJub1ydH5t9L4/5fvjOe9/H+1J7/wnqZD UBKnYAQNEHYJWeUPLHsUq5BqzSeWTHnQk/QGlhctKw42fZC6Y1jgxDkiTDKHQBeKBUsN N2FJ6Xi0UXDo1dSagCugIeGCd5Esfw0gXT6pGkhC0JaRhN/nH2MI92SH4lygtiYhihid MK0zyMsTqm6jNrIqlAPxyA8TjGmbp06pwgigV0zwFr5heNM+l0OiiIkg/Wh6pArZLdCx 7oHcJVUMjxjC4HKndjWhXkb6TPLbeiJxxSMoGvqSA9Lw6yVx04QGFlyb5zGc8LGysdDu yjF9o6Qr1IUZeHci0N7q+mHza81tmNL3p26daHVJvb4Myrtjc0GsnjrKq/D9x0r+Txs7 5gDgUWZczk2bcP3IpHnJ4JyhRFyY3hzqduHzCbyNalyGVR2VWe3066sMDRVch18/x3cE +13IkpAqn6iBDbfOcCTF2nszLZIxARoh3gwt5IH8PkNTmY3eyO3va8Kzjgd+IaxgoOtf dveWG/J65jEprafu2TB8ySOJCnbWGiaxe8T7RyY3BAVwg08pfmvGA1FXZ3WzFWV7kmH8 Aoy3YeF+Qv+8D8neAUTWMiHG5M+sfgvoJVJsLroRbffABM6yEmEuVa6c++iTJhlGcjAk erarJmBg/JU+dJk83Fk4QznFPdA2HS+lwtQOVIitE4l6wFMrfDcVpZLP8De1b/dp5uhj NgdlvXLp7mvXDUHm4tnwFQGRubcPIeINMAYDpffwFxLwHEb6QJ2wAAAABJRU5ErkJggg == Organization: /\/0/\/3 User-Agent: Mutt/1.5.16 (2007-06-09) Sender: =?UTF-8?B?4KSG4KS24KWA4KS3IOCktuClgeCkleCljeCksiBBc2hpc2ggU2h1a2xh?= Subject: Re: neighbor discovery problem X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2008 16:45:43 -0000 --3MwIy2ne0vdjdPXF Content-Type: text/plain; charset=unknown-8bit; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In , Pete French wrote: >> The network is pretty simple, >> >> gateway : >> em0: flags=3D8843 mtu 1500 >> options=3Db >> inet6 fe80::207:e9ff:fe0e:dead%em0 prefixlen 64 scopeid 0x1=20 >> inet6 2a01:678:1:443:: prefixlen 64=20 >> inet6 2a01:678:100:: prefixlen 48=20 > >Hmmm, are machine numbers of all zeroes legal in IPv6 ? I would >configure those as '2a01:678:1:443::1' and '2a01:678:100::1' if >I were you. All zeroes as a machine number is certainly a no-no in >IPv4, and I wouldn't use it in IPv6 either. I have no idea if it's >actually a problem, but it gives me a bad feeling.... Yes, it is legal, and such address, with subnet prefix + all zeroes in the= =20 host identifier (or interface identifier) is known as subnet-router anycast= =20 address. For further information, check out RFC 4291, Section 2.6.1[1]. References: [1] - http://tools.ietf.org/html/rfc4291#section-2.6.1 Ashish Shukla --=20 =B7-- =B7- =B7=B7=B7=B7 =B7--- =B7- =B7=B7=B7- =B7- =B7--=B7-=B7 --=B7 -- = =B7- =B7=B7 =B7-=B7=B7 =B7-=B7-=B7- -=B7-=B7 --- -- --3MwIy2ne0vdjdPXF Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkihuI4ACgkQHy+EEHYuXnRSzwCeMKaqabepIVh8ndktFkKD5/gC C4oAoOxqiZ2YbqZndt7qA92sNdR+BfbC =uJ35 -----END PGP SIGNATURE----- --3MwIy2ne0vdjdPXF-- From owner-freebsd-stable@FreeBSD.ORG Tue Aug 12 18:00:09 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 532811065685 for ; Tue, 12 Aug 2008 18:00:09 +0000 (UTC) (envelope-from kes-kes@yandex.ru) Received: from webmail6.yandex.ru (webmail6.yandex.ru [77.88.61.50]) by mx1.freebsd.org (Postfix) with ESMTP id CFE7F8FC1A for ; Tue, 12 Aug 2008 18:00:08 +0000 (UTC) (envelope-from kes-kes@yandex.ru) Received: from YAMAIL (webmail6) by mail.yandex.ru id S15925509AbYHLSAC for ; Tue, 12 Aug 2008 22:00:02 +0400 X-Yandex-Spam: 1 Received: from [92.113.78.209] ([92.113.78.209]) by mail.yandex.ru with HTTP; Tue, 12 Aug 2008 22:00:02 +0400 From: KES To: freebsd-stable@freebsd.org MIME-Version: 1.0 Message-Id: <69921218564002@webmail6.yandex.ru> Date: Tue, 12 Aug 2008 22:00:02 +0400 X-Mailer: Yamail [ http://yandex.ru ] 5.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=KOI8-R Subject: command not found: problem with dash in filenames X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2008 18:00:09 -0000 NOTICE: when I run purepw it is located and runned, but when I run pure-pw (NOTICE: dash in name) I get: Command not found kes# env |grep PATH PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/root/bin kes# env | grep PATH PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/root/bin kes# ls -l /usr/local/bin/pure* -r-xr-xr-x 1 root wheel 24052 12 Á×Ç 06:24 /usr/local/bin/pure-pw -r-xr-xr-x 1 root wheel 4432 12 Á×Ç 06:24 /usr/local/bin/pure-pwconvert -r-xr-xr-x 1 root wheel 6016 12 Á×Ç 06:24 /usr/local/bin/pure-statsdecode kes# pure-pw pure-pw: Command not found kes# /usr/local/bin/pure-pw Usage : pure-pw useradd [-f ] -u [-g ] -D/-d [-c ] [-t ] [-T ] ......... kes# cp pure-pw purepw kes# purepw Usage : pure-pw useradd [-f ] -u [-g ] -D/-d [-c ] [-t ] [-T ] ........ From owner-freebsd-stable@FreeBSD.ORG Tue Aug 12 18:23:33 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 07CC21065684; Tue, 12 Aug 2008 18:23:33 +0000 (UTC) (envelope-from kuuse@redantigua.com) Received: from kilimanjaro.scorpionshops.com (kilimanjaro.scorpionshops.com [83.140.32.147]) by mx1.freebsd.org (Postfix) with ESMTP id 7A7EE8FC18; Tue, 12 Aug 2008 18:23:32 +0000 (UTC) (envelope-from kuuse@redantigua.com) Received: from webmail.bilbomedia.com (unknown [83.140.32.148]) by kilimanjaro.scorpionshops.com (Postfix) with ESMTP id 3DFF7D38024; Tue, 12 Aug 2008 20:23:30 +0200 (CEST) Received: from 83.49.238.144 (Gatekeeper authenticated user kuuse) by webmail.bilbomedia.com with HTTP; Tue, 12 Aug 2008 20:23:30 +0200 (CEST) Message-ID: <1179.83.49.238.144.1218565410.frodo@webmail.bilbomedia.com> Date: Tue, 12 Aug 2008 20:23:30 +0200 (CEST) From: "Johan Kuuse" To: "John Baldwin" User-Agent: BilbomediaMail ver. 1 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: freebsd-stable@freebsd.org Subject: Re: kernel panic X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2008 18:23:33 -0000 > On Tuesday 12 August 2008 02:42:52 am Johan Kuuse wrote: >> On Monday 11 August 2008 23:04:30 John Baldwin wrote: >> > On Sunday 10 August 2008 10:01:49 pm Johan Kuuse wrote: >> > > Hi, >> > > >> > > I am a kgdb newbie, so please be patient. >> > > I suspect (just based on the fact that this is the 4th time I edit text >> > >> > files on my NTFS partition through ntfs-3g, using Emacs, and getting >> > frequent I/O error messages inside Emacs, and then a kernel panic) that >> > this is a ntfs-3g related problem. >> > >> > > If you ask me exactly how to reproduce it, I sorry, I can tell you >> > > exactly >> > >> > (but see the kgdb output below). >> > >> > > Anyway, the kernel seems to panic at /usr/src/sys/kern/vfs_bio.c:1530 >> > > >> > > Just a suggestion for a patch (without knowing the functionality >> > >> > of /usr/src/sys/kern/vfs_bio.c): >> > > The line where the kernel panics: >> > > /usr/src/sys/kern/vfs_bio.c: >> > > ---------------------------------- >> > > VM_OBJECT_LOCK(bp->b_bufobj->bo_object); >> > > ... >> > > ---------------------------------- >> > > >> > > Comparing to another file, which does error checking before calling >> > >> > VM_OBJECT_LOCK: >> > > /usr/src/sys/kern/vfs_aio.c: >> > > ---------------------------------- >> > > if (vp->v_object != NULL) { >> > > VM_OBJECT_LOCK(vp->v_object); >> > > ... >> > > ---------------------------------- >> > > >> > > Perhaps the kernel panic could be avoided with the following patch? >> > > /usr/src/sys/kern/vfs_bio.c (suggested patch): >> > > ---------------------------------- >> > > if ((bp->b_bufobj != NULL) && (bp->b_bufobj->bo_object != NULL)) { >> > > VM_OBJECT_LOCK(bp->b_bufobj->bo_object); >> > > ... >> > > ---------------------------------- >> > > >> > > Please let me know if you need more information. >> > > >> > > Regards, >> > > Johan Kuuse >> > > >> > > ----------------------------------------------------------------------- >> > >------------------------------------ kgdb kernel.debug >> > > /var/crash/vmcore.1 >> > > [GDB will not be able to debug user-mode threads: >> > > /usr/lib/libthread_db.so: >> > >> > Undefined symbol "ps_pglobal_lookup"] >> > >> > > GNU gdb 6.1.1 [FreeBSD] >> > > Copyright 2004 Free Software Foundation, Inc. >> > > GDB is free software, covered by the GNU General Public License, and >> > > you are welcome to change it and/or distribute copies of it under >> > > certain >> > >> > conditions. >> > >> > > Type "show copying" to see the conditions. >> > > There is absolutely no warranty for GDB. Type "show warranty" for >> > > details. This GDB was configured as "i386-marcel-freebsd". >> > > >> > > Unread portion of the kernel message buffer: >> > > >> > > >> > > Fatal trap 12: page fault while in kernel mode >> > > cpuid = 0; apic id = 00 >> > > fault virtual address = 0x34 >> > > fault code = supervisor read, page not present >> > > instruction pointer = 0x20:0xc07b6de4 >> > > stack pointer = 0x28:0xe79de7c8 >> > > frame pointer = 0x28:0xe79de7e8 >> > > code segment = base 0x0, limit 0xfffff, type 0x1b >> > > = DPL 0, pres 1, def32 1, gran 1 >> > > processor eflags = interrupt enabled, resume, IOPL = 0 >> > > current process = 1214 (opera) >> > > trap number = 12 >> > > panic: page fault >> > > cpuid = 0 >> > > Uptime: 5h20m30s >> > > Physical memory: 2035 MB >> > > Dumping 218 MB: 203 187 171 155 139 123 107 91 75 59 43 27 11 >> > > >> > > #0 doadump () at pcpu.h:195 >> > > 195 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); >> > > (kgdb) list *0xc07b6de4 >> > > 0xc07b6de4 is in vfs_vmio_release (/usr/src/sys/kern/vfs_bio.c:1530). >> > > 1525 vfs_vmio_release(struct buf *bp) >> > > 1526 { >> > > 1527 int i; >> > > 1528 vm_page_t m; >> > > 1529 >> > > 1530 VM_OBJECT_LOCK(bp->b_bufobj->bo_object); >> > > 1531 vm_page_lock_queues(); >> > > 1532 for (i = 0; i < bp->b_npages; i++) { >> > > 1533 m = bp->b_pages[i]; >> > > 1534 bp->b_pages[i] = NULL; >> > > (kgdb) bt >> > > #0 doadump () at pcpu.h:195 >> > > #1 0xc0754457 in boot (howto=260) at >> > > /usr/src/sys/kern/kern_shutdown.c:409 #2 0xc0754719 in panic >> > > (fmt=Variable "fmt" is not available. >> > > ) at /usr/src/sys/kern/kern_shutdown.c:563 >> > > #3 0xc0a4905c in trap_fatal (frame=0xe79de788, eva=52) >> > >> > at /usr/src/sys/i386/i386/trap.c:899 >> > >> > > #4 0xc0a492e0 in trap_pfault (frame=0xe79de788, usermode=0, eva=52) >> > >> > at /usr/src/sys/i386/i386/trap.c:812 >> > >> > > #5 0xc0a49c8c in trap (frame=0xe79de788) >> > >> > at /usr/src/sys/i386/i386/trap.c:490 >> > >> > > #6 0xc0a2fc0b in calltrap () at /usr/src/sys/i386/i386/exception.s:139 >> > > #7 0xc07b6de4 in vfs_vmio_release (bp=0xd927e33c) >> > >> > at /usr/src/sys/kern/vfs_bio.c:1530 >> > >> > > #8 0xc07b8a81 in getnewbuf (slpflag=0, slptimeo=0, size=Variable >> > > "size" is >> > >> > not available. >> > >> > > ) at /usr/src/sys/kern/vfs_bio.c:1847 >> > > #9 0xc07ba118 in getblk (vp=0xc8891bb0, blkno=0, size=2048, slpflag=0, >> > >> > slptimeo=0, flags=Variable "flags" is not available. >> > >> > > ) at /usr/src/sys/kern/vfs_bio.c:2602 >> > > #10 0xc0932815 in ffs_balloc_ufs2 (vp=0xc8891bb0, >> > >> > startoffset=Variable "startoffset" is not available. >> > >> > > ) at /usr/src/sys/ufs/ffs/ffs_balloc.c:699 >> > > #11 0xc0952a85 in ffs_write (ap=0xe79debc4) >> > >> > at /usr/src/sys/ufs/ffs/ffs_vnops.c:720 >> > >> > > #12 0xc0a5efc6 in VOP_WRITE_APV (vop=0xc0b93c60, a=0xe79debc4) at >> > >> > vnode_if.c:691 >> > >> > > #13 0xc07dbf37 in vn_write (fp=0xc85f3168, uio=0xe79dec60, >> > >> > active_cred=0xc61c6300, flags=0, td=0xc583fc60) at vnode_if.h:373 >> > >> > > #14 0xc07875e7 in dofilewrite (td=0xc583fc60, fd=17, fp=0xc85f3168, >> > >> > auio=0xe79dec60, offset=-1, flags=0) at file.h:254 >> > >> > > #15 0xc07878c8 in kern_writev (td=0xc583fc60, fd=17, auio=0xe79dec60) >> > >> > at /usr/src/sys/kern/sys_generic.c:401 >> > >> > > #16 0xc078793f in write (td=0xc583fc60, uap=0xe79decfc) >> > >> > at /usr/src/sys/kern/sys_generic.c:317 >> > >> > > #17 0xc0a49635 in syscall (frame=0xe79ded38) >> > >> > at /usr/src/sys/i386/i386/trap.c:1035 >> > >> > > #18 0xc0a2fc70 in Xint0x80_syscall () >> > >> > at /usr/src/sys/i386/i386/exception.s:196 >> > >> > > #19 0x00000033 in ?? () >> > > Previous frame inner to this frame (corrupt stack?) >> > >> > FYI, you got the panic in ffs/ufs, not fuse. I've seen this at work on >> > 6.x with NFS with no clues on what causes it. You can start by going to >> > frame 7 and doing 'p *bp'. >> >> Thanks for the hints. >> See below for more debug output. >> I recognize that the bp struct members b_data and b_kvabase both point to a >> chunk of memory containing the text of the Opera web page I was reading >> when the kernel crashed. (This is indicated above: current process >> = 1214 (opera)) >> >> But what is most interesting is that b_bufobj = 0x0 >> Obviously, then trying to access bp->b_bufobj->bo_object will cause a >> crash. So I think it would be a good idea to NULL-check the struct member >> before trying to access it. How should I proceed? Should I post this as a >> possible bug somewhere else, to another list? > > Unfortunately, it is a worse problem that b_bufobj is NULL. That means there > is a bug elsewhere. I'll look at this some more. > > Hmm, can you reproduce this at all? If so, can you try the patch below. > Hopefully it panics here which might help: > > Index: vfs_subr.c > =================================================================== > --- vfs_subr.c (revision 181629) > +++ vfs_subr.c (working copy) > @@ -1546,6 +1546,9 @@ > CTR3(KTR_BUF, "brelvp(%p) vp %p flags %X", bp, bp->b_vp, bp->b_flags); > KASSERT(bp->b_vp != NULL, ("brelvp: NULL")); > > + if (bp->flags & B_VMIO) > + panic("brelvp of B_VMIO buffer"); > + > /* > * Delete from old vnode list, if on one. > */ > > -- > John Baldwin > Sorry, at the moment I don't know how to reproduce the crash. I mentioned ntfs-ng/fuse as I got the impression that they caused a heavy load on my box, but in the end, it was Opera which caused the crash (also causing a heavy load, however). What I can do is to apply your patch and play around with CPU-consuming apps to try if I can reproduce the crash during heavy load. Currently I'm running 7.-0-RELEASE. Do you recommend me to upgrade to STABLE before applying the patch? Regards, Johan Kuuse From owner-freebsd-stable@FreeBSD.ORG Tue Aug 12 18:41:05 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 783F21065673 for ; Tue, 12 Aug 2008 18:41:05 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 022C58FC14 for ; Tue, 12 Aug 2008 18:41:04 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [IPv6:::1]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m7CIe1i6081296; Tue, 12 Aug 2008 14:40:57 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: "Johan Kuuse" Date: Tue, 12 Aug 2008 14:39:47 -0400 User-Agent: KMail/1.9.7 References: <1179.83.49.238.144.1218565410.frodo@webmail.bilbomedia.com> In-Reply-To: <1179.83.49.238.144.1218565410.frodo@webmail.bilbomedia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200808121439.48158.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Tue, 12 Aug 2008 14:40:58 -0400 (EDT) X-Virus-Scanned: ClamAV 0.93.1/8019/Tue Aug 12 13:40:24 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: freebsd-stable@freebsd.org Subject: Re: kernel panic X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2008 18:41:05 -0000 On Tuesday 12 August 2008 02:23:30 pm Johan Kuuse wrote: > > On Tuesday 12 August 2008 02:42:52 am Johan Kuuse wrote: > >> On Monday 11 August 2008 23:04:30 John Baldwin wrote: > >> > On Sunday 10 August 2008 10:01:49 pm Johan Kuuse wrote: > >> > > Hi, > >> > > > >> > > I am a kgdb newbie, so please be patient. > >> > > I suspect (just based on the fact that this is the 4th time I edit text > >> > > >> > files on my NTFS partition through ntfs-3g, using Emacs, and getting > >> > frequent I/O error messages inside Emacs, and then a kernel panic) that > >> > this is a ntfs-3g related problem. > >> > > >> > > If you ask me exactly how to reproduce it, I sorry, I can tell you > >> > > exactly > >> > > >> > (but see the kgdb output below). > >> > > >> > > Anyway, the kernel seems to panic at /usr/src/sys/kern/vfs_bio.c:1530 > >> > > > >> > > Just a suggestion for a patch (without knowing the functionality > >> > > >> > of /usr/src/sys/kern/vfs_bio.c): > >> > > The line where the kernel panics: > >> > > /usr/src/sys/kern/vfs_bio.c: > >> > > ---------------------------------- > >> > > VM_OBJECT_LOCK(bp->b_bufobj->bo_object); > >> > > ... > >> > > ---------------------------------- > >> > > > >> > > Comparing to another file, which does error checking before calling > >> > > >> > VM_OBJECT_LOCK: > >> > > /usr/src/sys/kern/vfs_aio.c: > >> > > ---------------------------------- > >> > > if (vp->v_object != NULL) { > >> > > VM_OBJECT_LOCK(vp->v_object); > >> > > ... > >> > > ---------------------------------- > >> > > > >> > > Perhaps the kernel panic could be avoided with the following patch? > >> > > /usr/src/sys/kern/vfs_bio.c (suggested patch): > >> > > ---------------------------------- > >> > > if ((bp->b_bufobj != NULL) && (bp->b_bufobj->bo_object != NULL)) { > >> > > VM_OBJECT_LOCK(bp->b_bufobj->bo_object); > >> > > ... > >> > > ---------------------------------- > >> > > > >> > > Please let me know if you need more information. > >> > > > >> > > Regards, > >> > > Johan Kuuse > >> > > > >> > > ----------------------------------------------------------------------- > >> > >------------------------------------ kgdb kernel.debug > >> > > /var/crash/vmcore.1 > >> > > [GDB will not be able to debug user-mode threads: > >> > > /usr/lib/libthread_db.so: > >> > > >> > Undefined symbol "ps_pglobal_lookup"] > >> > > >> > > GNU gdb 6.1.1 [FreeBSD] > >> > > Copyright 2004 Free Software Foundation, Inc. > >> > > GDB is free software, covered by the GNU General Public License, and > >> > > you are welcome to change it and/or distribute copies of it under > >> > > certain > >> > > >> > conditions. > >> > > >> > > Type "show copying" to see the conditions. > >> > > There is absolutely no warranty for GDB. Type "show warranty" for > >> > > details. This GDB was configured as "i386-marcel-freebsd". > >> > > > >> > > Unread portion of the kernel message buffer: > >> > > > >> > > > >> > > Fatal trap 12: page fault while in kernel mode > >> > > cpuid = 0; apic id = 00 > >> > > fault virtual address = 0x34 > >> > > fault code = supervisor read, page not present > >> > > instruction pointer = 0x20:0xc07b6de4 > >> > > stack pointer = 0x28:0xe79de7c8 > >> > > frame pointer = 0x28:0xe79de7e8 > >> > > code segment = base 0x0, limit 0xfffff, type 0x1b > >> > > = DPL 0, pres 1, def32 1, gran 1 > >> > > processor eflags = interrupt enabled, resume, IOPL = 0 > >> > > current process = 1214 (opera) > >> > > trap number = 12 > >> > > panic: page fault > >> > > cpuid = 0 > >> > > Uptime: 5h20m30s > >> > > Physical memory: 2035 MB > >> > > Dumping 218 MB: 203 187 171 155 139 123 107 91 75 59 43 27 11 > >> > > > >> > > #0 doadump () at pcpu.h:195 > >> > > 195 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); > >> > > (kgdb) list *0xc07b6de4 > >> > > 0xc07b6de4 is in vfs_vmio_release (/usr/src/sys/kern/vfs_bio.c:1530). > >> > > 1525 vfs_vmio_release(struct buf *bp) > >> > > 1526 { > >> > > 1527 int i; > >> > > 1528 vm_page_t m; > >> > > 1529 > >> > > 1530 VM_OBJECT_LOCK(bp->b_bufobj->bo_object); > >> > > 1531 vm_page_lock_queues(); > >> > > 1532 for (i = 0; i < bp->b_npages; i++) { > >> > > 1533 m = bp->b_pages[i]; > >> > > 1534 bp->b_pages[i] = NULL; > >> > > (kgdb) bt > >> > > #0 doadump () at pcpu.h:195 > >> > > #1 0xc0754457 in boot (howto=260) at > >> > > /usr/src/sys/kern/kern_shutdown.c:409 #2 0xc0754719 in panic > >> > > (fmt=Variable "fmt" is not available. > >> > > ) at /usr/src/sys/kern/kern_shutdown.c:563 > >> > > #3 0xc0a4905c in trap_fatal (frame=0xe79de788, eva=52) > >> > > >> > at /usr/src/sys/i386/i386/trap.c:899 > >> > > >> > > #4 0xc0a492e0 in trap_pfault (frame=0xe79de788, usermode=0, eva=52) > >> > > >> > at /usr/src/sys/i386/i386/trap.c:812 > >> > > >> > > #5 0xc0a49c8c in trap (frame=0xe79de788) > >> > > >> > at /usr/src/sys/i386/i386/trap.c:490 > >> > > >> > > #6 0xc0a2fc0b in calltrap () at /usr/src/sys/i386/i386/exception.s:139 > >> > > #7 0xc07b6de4 in vfs_vmio_release (bp=0xd927e33c) > >> > > >> > at /usr/src/sys/kern/vfs_bio.c:1530 > >> > > >> > > #8 0xc07b8a81 in getnewbuf (slpflag=0, slptimeo=0, size=Variable > >> > > "size" is > >> > > >> > not available. > >> > > >> > > ) at /usr/src/sys/kern/vfs_bio.c:1847 > >> > > #9 0xc07ba118 in getblk (vp=0xc8891bb0, blkno=0, size=2048, slpflag=0, > >> > > >> > slptimeo=0, flags=Variable "flags" is not available. > >> > > >> > > ) at /usr/src/sys/kern/vfs_bio.c:2602 > >> > > #10 0xc0932815 in ffs_balloc_ufs2 (vp=0xc8891bb0, > >> > > >> > startoffset=Variable "startoffset" is not available. > >> > > >> > > ) at /usr/src/sys/ufs/ffs/ffs_balloc.c:699 > >> > > #11 0xc0952a85 in ffs_write (ap=0xe79debc4) > >> > > >> > at /usr/src/sys/ufs/ffs/ffs_vnops.c:720 > >> > > >> > > #12 0xc0a5efc6 in VOP_WRITE_APV (vop=0xc0b93c60, a=0xe79debc4) at > >> > > >> > vnode_if.c:691 > >> > > >> > > #13 0xc07dbf37 in vn_write (fp=0xc85f3168, uio=0xe79dec60, > >> > > >> > active_cred=0xc61c6300, flags=0, td=0xc583fc60) at vnode_if.h:373 > >> > > >> > > #14 0xc07875e7 in dofilewrite (td=0xc583fc60, fd=17, fp=0xc85f3168, > >> > > >> > auio=0xe79dec60, offset=-1, flags=0) at file.h:254 > >> > > >> > > #15 0xc07878c8 in kern_writev (td=0xc583fc60, fd=17, auio=0xe79dec60) > >> > > >> > at /usr/src/sys/kern/sys_generic.c:401 > >> > > >> > > #16 0xc078793f in write (td=0xc583fc60, uap=0xe79decfc) > >> > > >> > at /usr/src/sys/kern/sys_generic.c:317 > >> > > >> > > #17 0xc0a49635 in syscall (frame=0xe79ded38) > >> > > >> > at /usr/src/sys/i386/i386/trap.c:1035 > >> > > >> > > #18 0xc0a2fc70 in Xint0x80_syscall () > >> > > >> > at /usr/src/sys/i386/i386/exception.s:196 > >> > > >> > > #19 0x00000033 in ?? () > >> > > Previous frame inner to this frame (corrupt stack?) > >> > > >> > FYI, you got the panic in ffs/ufs, not fuse. I've seen this at work on > >> > 6.x with NFS with no clues on what causes it. You can start by going to > >> > frame 7 and doing 'p *bp'. > >> > >> Thanks for the hints. > >> See below for more debug output. > >> I recognize that the bp struct members b_data and b_kvabase both point to a > >> chunk of memory containing the text of the Opera web page I was reading > >> when the kernel crashed. (This is indicated above: current process > >> = 1214 (opera)) > >> > >> But what is most interesting is that b_bufobj = 0x0 > >> Obviously, then trying to access bp->b_bufobj->bo_object will cause a > >> crash. So I think it would be a good idea to NULL-check the struct member > >> before trying to access it. How should I proceed? Should I post this as a > >> possible bug somewhere else, to another list? > > > > Unfortunately, it is a worse problem that b_bufobj is NULL. That means there > > is a bug elsewhere. I'll look at this some more. > > > > Hmm, can you reproduce this at all? If so, can you try the patch below. > > Hopefully it panics here which might help: > > > > Index: vfs_subr.c > > =================================================================== > > --- vfs_subr.c (revision 181629) > > +++ vfs_subr.c (working copy) > > @@ -1546,6 +1546,9 @@ > > CTR3(KTR_BUF, "brelvp(%p) vp %p flags %X", bp, bp->b_vp, bp->b_flags); > > KASSERT(bp->b_vp != NULL, ("brelvp: NULL")); > > > > + if (bp->flags & B_VMIO) > > + panic("brelvp of B_VMIO buffer"); > > + > > /* > > * Delete from old vnode list, if on one. > > */ > > > > -- > > John Baldwin > > > > Sorry, at the moment I don't know how to reproduce the crash. > I mentioned ntfs-ng/fuse as I got the impression that they caused a heavy load > on my box, but in the end, it was Opera which caused the crash (also causing a > heavy load, however). > What I can do is to apply your patch and play around with CPU-consuming apps to > try if I can reproduce the crash during heavy load. Ok. > Currently I'm running 7.-0-RELEASE. > Do you recommend me to upgrade to STABLE before applying the patch? No, you can just leave it as it is. At work I've seen this occasionally on 6.x, so it's probably an older bug. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Tue Aug 12 19:26:44 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 787B81065678 for ; Tue, 12 Aug 2008 19:26:44 +0000 (UTC) (envelope-from mgowda82@gmail.com) Received: from rn-out-0910.google.com (rn-out-0910.google.com [64.233.170.185]) by mx1.freebsd.org (Postfix) with ESMTP id 3ABB88FC18 for ; Tue, 12 Aug 2008 19:26:44 +0000 (UTC) (envelope-from mgowda82@gmail.com) Received: by rn-out-0910.google.com with SMTP id j71so41946rne.12 for ; Tue, 12 Aug 2008 12:26:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=Yf04pkYkNutfj3q03yQjkYjyDrhcBqFQz02fiSrkp88=; b=fftPygCBIqb+KVmJF3bssZ9WnLAmKH5kTLTEqQGCW2LPvWRPYACEgKPQMDC38tv5bp svj48dPMbeBNm+W4bEuomVatpK6UzrHLAolWYf4AGX/qHi8HFTz2Uf1sAsVWrUa17UFm YLPcTS714xK6hxQtvi/sYNCtyNVqLR0ubC4xk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=ESucjv51vXEAJ9atYOa2G6NyHuouPAbhRupjktb++9SkmwJ13jgWXF38BEYgxwmoCy 17zqOLsojzm3+onYtl+qjJwYTcF2vTCQpeOkXMja9nxrU6Gcnfo1f+TMMnyxGAdDgeJZ OPE0DW9RtRei3HV4YCYZfn/vNtIdYPcqFx8b8= Received: by 10.142.53.19 with SMTP id b19mr2873740wfa.167.1218569202710; Tue, 12 Aug 2008 12:26:42 -0700 (PDT) Received: by 10.142.162.20 with HTTP; Tue, 12 Aug 2008 12:26:42 -0700 (PDT) Message-ID: Date: Tue, 12 Aug 2008 12:26:42 -0700 From: "Manjunath Ranganathaiah" To: "Daniel O'Connor" In-Reply-To: <200808121734.30144.doconnor@gsoft.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200808121734.30144.doconnor@gsoft.com.au> Cc: freebsd-stable@freebsd.org Subject: Re: 6.3 (ish) hang on reboot w/ Supermicro C2SBA+ X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2008 19:26:44 -0000 On Tue, Aug 12, 2008 at 1:04 AM, Daniel O'Connor wrote: > Hi, > I have a 6.3 (RELENG_6 a bit past 6.3 actually) system which hangs when > I try and reboot (or shutdown). It has a Supermicro C2SBA+, 2ware > 9650SE and Core2Duo CPU. > > It shuts down as normal except after printing the uptime it hangs solid. > Numlock does nothing (during the shutdown process & disk sync it > toggles OK). The disks are synced OK (comes up clean when I press the > reset switch) > > Waiting (max 60 seconds) for system process 'vnlru' to stop...done > Waiting (max 60 seconds) for system process 'bufdaemon' to stop...done > Waiting (max 60 seconds) for system process 'syncer' to stop... > Syncing disks, vnodes remaining...6 5 2 3 0 1 0 0 0 done > All buffers ynced. > Swap device da0s1b removed. > Uptime: 1m52s > > > I have tried setting hw.acpi.disable_on_reboot and hw.acpi.handle_reboot > to no effect. > > I have attached a verbose dmesg. > > -- > Daniel O'Connor software and network engineer > for Genesis Software - http://www.gsoft.com.au > "The nice thing about standards is that there > are so many of them to choose from." > -- Andrew Tanenbaum > GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C can you try with debug.acpi.disabled="cpu timer" ? or booting with acpi disabled -Manjunath From owner-freebsd-stable@FreeBSD.ORG Tue Aug 12 19:36:01 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B53531065673 for ; Tue, 12 Aug 2008 19:36:01 +0000 (UTC) (envelope-from brix@FreeBSD.org) Received: from solow.pil.dk (relay.pil.dk [195.41.47.164]) by mx1.freebsd.org (Postfix) with ESMTP id 812E68FC22 for ; Tue, 12 Aug 2008 19:36:01 +0000 (UTC) (envelope-from brix@FreeBSD.org) Received: from tirith.brixandersen.dk (0x55534f5f.adsl.cybercity.dk [85.83.79.95]) by solow.pil.dk (Postfix) with ESMTP id E96F21CC121 for ; Tue, 12 Aug 2008 21:35:59 +0200 (CEST) Received: by tirith.brixandersen.dk (Postfix, from userid 1001) id DABA311436; Tue, 12 Aug 2008 21:35:58 +0200 (CEST) Date: Tue, 12 Aug 2008 21:35:58 +0200 From: Henrik Brix Andersen To: freebsd-stable@freebsd.org Message-ID: <20080812193558.GA38269@tirith.brixandersen.dk> References: <69921218564002@webmail6.yandex.ru> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ikeVEW9yuYc//A+q" Content-Disposition: inline In-Reply-To: <69921218564002@webmail6.yandex.ru> X-PGP-Key: http://www.brixandersen.dk/files/HenrikBrixAndersen.asc User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: command not found: problem with dash in filenames X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2008 19:36:01 -0000 --ikeVEW9yuYc//A+q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 12, 2008 at 10:00:02PM +0400, KES wrote: > NOTICE:=20 > when I run purepw it is located and runned, but=20 > when I run pure-pw (NOTICE: dash in name) I get: Command not found Did you by any chance just install this binary? Have you tried running 'rehash' and trying again? Brix --=20 Henrik Brix Andersen --ikeVEW9yuYc//A+q Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) Comment: GnuPG signed iEYEARECAAYFAkih5h0ACgkQv+Q4flTiePgrgACfWZQDuGXkAGF/q5hP+gtVDAK/ rdAAnRkFIYJ0jPiYXn4lB1hz6UmLloWA =y1Oh -----END PGP SIGNATURE----- --ikeVEW9yuYc//A+q-- From owner-freebsd-stable@FreeBSD.ORG Tue Aug 12 20:38:34 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B6B711065671 for ; Tue, 12 Aug 2008 20:38:34 +0000 (UTC) (envelope-from ebutusov@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.184]) by mx1.freebsd.org (Postfix) with ESMTP id 121988FC1A for ; Tue, 12 Aug 2008 20:38:33 +0000 (UTC) (envelope-from ebutusov@gmail.com) Received: by nf-out-0910.google.com with SMTP id h3so1276769nfh.33 for ; Tue, 12 Aug 2008 13:38:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=Xw66iN5Ry+wFS6D0B8TmNe/I/nCzXe+o5/VAtZYcAKY=; b=h2sk8CUQlyxQo+e9IRpzryfKBp4ujxpKx+I+9zUgtY0f1eg1Ljt+10VcE1u6eLmHbd M9H5MLkOZlTY1+KQuTHxoVRu7Q7ZBxBhLinDO1UkuPJpaNL5+Ctor78Y6oobApZm8Reb p4fhXtwAwuH1j9It7Lt28ycKj3NOAhthcx5yc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=ahOyUBTD2MSrCN+WXvIzbupBk44RXxhYanbxGDSbZC6A0HmQmrKRJXO36wTsWwnkds 2kk8+B0yUfwUAiuZ09LHGwyKl2eUIq8D4CBk9zYzQlV+s5w/A5rBttc5cFS67p0LJMj/ e0A18ogELHdoJRZTxT4oWpmLHq5UzX+Jjnceo= Received: by 10.103.222.1 with SMTP id z1mr7418407muq.71.1218573511529; Tue, 12 Aug 2008 13:38:31 -0700 (PDT) Received: from ?192.168.0.51? ( [195.136.67.137]) by mx.google.com with ESMTPS id u26sm933187mug.4.2008.08.12.13.38.29 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 12 Aug 2008 13:38:30 -0700 (PDT) Message-ID: <48A1F4B3.3050205@gmail.com> Date: Tue, 12 Aug 2008 22:38:11 +0200 From: Eugene Butusov User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Jeremy Chadwick References: <48A0BF40.2030607@gmail.com> <20080811234547.GA67278@eos.sc1.parodius.com> <20080811235456.GA70635@eos.sc1.parodius.com> In-Reply-To: <20080811235456.GA70635@eos.sc1.parodius.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD-STABLE-LIST Subject: Re: Hardware monitoring for Intel Atom D945GCLF. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2008 20:38:34 -0000 Jeremy Chadwick pisze: > On Mon, Aug 11, 2008 at 04:45:47PM -0700, Jeremy Chadwick wrote: >> I don't need an API, but this kind of statement makes Intel sound like >> they're not willing to disclose the SMBus offsets for monitoring. I >> might have to look at lm-sensors from Linux, but that code is very >> difficult to follow. I'm not sure if Intel gives this sort of >> information out publicly, but I sure hope so. > > There's a web page mentioning this board (note: entirely Japanese) -- > > http://iktaka.dyndns.org/node/11 > > The bottom part of the page states that Linux's lm_sensors 3.0.2 can > successfully monitor temperatures, voltages, and fan RPMs on that board, > very likely via SMBus. > > Ideally I should be able to track down technical details by looking at > that code. I'd feel much more comfortable asking Intel and having them > provide necessary registers and offsets, though; I prefer to avoid > reverse-engineering things if possible (less mistakes). > Thanks for the reply. Looks like there is no tool for FreeBSD which supports ICH7 currently. mbmon has support for ICH6, but I'm not sure is it still alive. What about your project, are you planing to release it to the public in nearest future? Best regards, -- _/_/ .. Eugene Butusov _/_/ ... www.devilka.info _/_/ .... ebutusov(at)gmail(dot)com From owner-freebsd-stable@FreeBSD.ORG Tue Aug 12 21:57:23 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 67D321065674 for ; Tue, 12 Aug 2008 21:57:23 +0000 (UTC) (envelope-from jdc@parodius.com) Received: from mx01.sc1.parodius.com (mx01.sc1.parodius.com [72.20.106.3]) by mx1.freebsd.org (Postfix) with ESMTP id 4F8448FC0C for ; Tue, 12 Aug 2008 21:57:23 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id 3A9C91CC0C0; Tue, 12 Aug 2008 14:57:23 -0700 (PDT) Date: Tue, 12 Aug 2008 14:57:23 -0700 From: Jeremy Chadwick To: Eugene Butusov Message-ID: <20080812215723.GA39839@eos.sc1.parodius.com> References: <48A0BF40.2030607@gmail.com> <20080811234547.GA67278@eos.sc1.parodius.com> <20080811235456.GA70635@eos.sc1.parodius.com> <48A1F4B3.3050205@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48A1F4B3.3050205@gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: FreeBSD-STABLE-LIST Subject: Re: Hardware monitoring for Intel Atom D945GCLF. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2008 21:57:23 -0000 On Tue, Aug 12, 2008 at 10:38:11PM +0200, Eugene Butusov wrote: > Jeremy Chadwick pisze: >> On Mon, Aug 11, 2008 at 04:45:47PM -0700, Jeremy Chadwick wrote: >>> I don't need an API, but this kind of statement makes Intel sound like >>> they're not willing to disclose the SMBus offsets for monitoring. I >>> might have to look at lm-sensors from Linux, but that code is very >>> difficult to follow. I'm not sure if Intel gives this sort of >>> information out publicly, but I sure hope so. >> >> There's a web page mentioning this board (note: entirely Japanese) -- >> >> http://iktaka.dyndns.org/node/11 >> >> The bottom part of the page states that Linux's lm_sensors 3.0.2 can >> successfully monitor temperatures, voltages, and fan RPMs on that board, >> very likely via SMBus. >> >> Ideally I should be able to track down technical details by looking at >> that code. I'd feel much more comfortable asking Intel and having them >> provide necessary registers and offsets, though; I prefer to avoid >> reverse-engineering things if possible (less mistakes). >> > > Thanks for the reply. Looks like there is no tool for FreeBSD which > supports ICH7 currently. mbmon has support for ICH6, but I'm not sure is > it still alive. You have to understand, it's hard for a program to say it "supports a chipset" unless that specific chipset is doing the H/W monitoring. For example, lots of Supermicro boards use Winbond H/W monitoring ICs, but you can interface with the chip via SMBus. The chipsets on those boards are Intel ICHx (ICH7 through 9), but the ICHx doesn't do the monitoring. I'm not sure the ICHx chips can actually do monitoring natively; I haven't looked at the specifications. If they do, that may be what mbmon is talking about -- otherwise, it might just be a vague description that more or less says "works with Intel ICHx chipsets that support SMBus". Hard to explain really... > What about your project, are you planing to release it to the public > in nearest future? Once I get a couple more Supermicro boards added, yep. The code is rock solid at this point in time[1], but there's still a lot to be done before I consider it worthy of public release. Remaining items on my TODO list for bsdhwmon: * Poke individuals testing software for further updates (many have been quiet since the last tarball) * Write manpage * Update README, and INSTALL (if necessary) * Update Makefile to be FreeBSD ports-friendly, and general cleanup * Make a FreeBSD port for the software These are things I myself have to do. I'm sorry I don't have an ETR for you -- I really wish I did. [1]: No crashes/segfaults, and compiles cleanly with -Werror -Wall -Wunused -Waggregate-return -Wbad-function-cast -Wcast-align -Wdeclaration-after-statement -Wdisabled-optimization -Wfloat-equal -Winline -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wold-style-definition -Wpacked -Wpointer-arith -Wredundant-decls -Wsign-compare -Wstrict-prototypes -Wunreachable-code -Wwrite-strings I'm one of those "warnings should be taken seriously" individuals. :-) -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Tue Aug 12 21:58:16 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 165EA106564A for ; Tue, 12 Aug 2008 21:58:16 +0000 (UTC) (envelope-from jdc@parodius.com) Received: from mx01.sc1.parodius.com (mx01.sc1.parodius.com [72.20.106.3]) by mx1.freebsd.org (Postfix) with ESMTP id 0D7968FC15 for ; Tue, 12 Aug 2008 21:58:15 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id E41A11CC0B8; Tue, 12 Aug 2008 14:58:15 -0700 (PDT) Date: Tue, 12 Aug 2008 14:58:15 -0700 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20080812215815.GA40223@eos.sc1.parodius.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Fwd: Re: command not found: problem with dash in filenames X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2008 21:58:16 -0000 ----- Forwarded message from KES ----- > From: KES > To: koitsu@freebsd.org > Date: Tue, 12 Aug 2008 23:40:08 +0400 > Subject: Re: command not found: problem with dash in filenames > > > > 12.08.08, 22:25, "Jeremy Chadwick" : > > > On Tue, Aug 12, 2008 at 10:00:02PM +0400, KES wrote: > > > NOTICE: > > > when I run purepw it is located and runned, but > > > when I run pure-pw (NOTICE: dash in name) I get: Command not found > > > kes# env |grep PATH > > > PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/root/bin > > > kes# env | grep PATH > > > PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/root/bin > > > kes# ls -l /usr/local/bin/pure* > > > -r-xr-xr-x 1 root wheel 24052 12 ??? 06:24 /usr/local/bin/pure-pw > > > -r-xr-xr-x 1 root wheel 4432 12 ??? 06:24 /usr/local/bin/pure-pwconvert > > > -r-xr-xr-x 1 root wheel 6016 12 ??? 06:24 /usr/local/bin/pure-statsdecode > > > kes# pure-pw > > > pure-pw: Command not found > > > kes# /usr/local/bin/pure-pw > > > > > > Usage : > > > > > > pure-pw useradd [-f ] -u [-g ] > > > -D/-d [-c ] > > > [-t ] [-T ] > > > ......... > > > kes# cp pure-pw purepw > > > kes# purepw > > > > > > Usage : > > > > > > pure-pw useradd [-f ] -u [-g ] > > > -D/-d [-c ] > > > [-t ] [-T ] > > > ........ > > Looks like you're using csh/tcsh. Try using "rehash" and see if it > > fixes the problem for you. > > thank you very mach > problem was resolved > ----- End forwarded message ----- Individual replied to me off-list; "refresh" was indeed the answer. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Wed Aug 13 04:46:18 2008 Return-Path: Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 57B7D1065676 for ; Wed, 13 Aug 2008 04:46:18 +0000 (UTC) (envelope-from unga888@yahoo.com) Received: from web57009.mail.re3.yahoo.com (web57009.mail.re3.yahoo.com [66.196.97.113]) by mx1.freebsd.org (Postfix) with SMTP id E93B28FC0C for ; Wed, 13 Aug 2008 04:46:17 +0000 (UTC) (envelope-from unga888@yahoo.com) Received: (qmail 22907 invoked by uid 60001); 13 Aug 2008 04:46:17 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Message-ID; b=Rc8ZrQV5kHPMvQAnQZvShstOiy+anrgiCkx0a1D+odBV8hXAf4oEUZG6YpF0gWcYoFvnyaFMr/yusOAusDjS1Pwbjj3csXY6YBOxvtiY47bnyXPUtc53KW8jvGlxbvnH9FeXZO+yV2WRQbuuTEYVoR04a1PvWEUDIHCQiqLF2rM=; Received: from [220.255.7.213] by web57009.mail.re3.yahoo.com via HTTP; Tue, 12 Aug 2008 21:46:17 PDT X-Mailer: YahooMailWebService/0.7.218 Date: Tue, 12 Aug 2008 21:46:17 -0700 (PDT) From: Unga To: freebsd-stable@FreeBSD.ORG In-Reply-To: <76940.80951.qm@web57013.mail.re3.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <268893.22415.qm@web57009.mail.re3.yahoo.com> Cc: olli@lurza.secnetix.de Subject: Re: sysinstall compilation issue X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: unga888@yahoo.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2008 04:46:18 -0000 --- On Tue, 8/12/08, Unga wrote: > From: Unga > Subject: Re: sysinstall compilation issue > To: freebsd-stable@FreeBSD.ORG > Cc: olli@lurza.secnetix.de > Date: Tuesday, August 12, 2008, 3:28 PM > --- On Fri, 8/8/08, Oliver Fromme > wrote: > > > From: Oliver Fromme > > Subject: Re: sysinstall compilation issue > > To: freebsd-stable@FreeBSD.ORG, unga888@yahoo.com > > Date: Friday, August 8, 2008, 9:36 PM > > Unga wrote: > > > This is i386 RELENG_7. > > > > > > Following section of the > > /usr/src/usr.sbin/sysinstall/Makefile does not > generate C > > code properly: > > > > > > makedevs.c: Makefile rtermcap > > > echo '#include > ' > > > makedevs.c > > > ${RTERMCAP} ansi | \ > > > file2c 'const char > termcap_ansi[] > > = {' ',0};' \ > > > > > makedevs.c > > > > > > At compile time, above expands to: > > > > > > TERMCAP=/usr/src/usr.sbin/sysinstall/../../share/termcap/termcap.src > > ./rtermcap ansi | file2c 'const char > termcap_ansi[] = > > {' ',0};' >> makedevs.c > > > > > > Which generates C code as follows: > > > const char termcap_ansi[] = { > > > > > > ,0}; > > > > > > That is, it generates 3 lines, which results a > > compilation error. > > > > > > I presume, intended generated code should be: > > > const char termcap_ansi[] = {' ',0}; > > > > > > Am I right? > > > > No, it should generate an array containung a dump of > > the "ansi" termcap entry. Please see the > > file2c(1) > > manpage. > > > > > What is wrong at my end? > > > > > > Note, I linked the rtermcap with ncursesw > libraries, > > can that be the cause? Any ideas? > > > > Yes, that's the cause. Why did you do that? > > > > FreeBSD's ncurses port contains a patch so the > > tgetent() > > function (which is used by rtermcap) returns the > actual > > termcap entry in the buffer. The original ncurses > code > > (which is terminfo based) doesn't do that. > > > > When you linked rtermcap with the wrong library, you > > restored the original behaviour of tgetent(), so the > > output of rtermcap was empty, so file2c produced > invalid > > source. > > > > Sorry for my late reply on this. I was not well during > weekend, an eye ache due to over work :( > > Here is the situation at my end, no matter whether I link > with ncurses widec libs or non-widec libs, its still return > the same code as above I mentioned. > > Possible causes can be: > 1. The way I compile and install ncurses is not correct. > 2. OR some essential files required are missing > 3. OR there can be an other option > > I used truss as follows: > TERMCAP=/usr/src/usr.sbin/sysinstall/../../share/termcap/termcap.src > truss -o truss.log -f ./rtermcap ansi | file2c 'const > char termcap_ansi[] = {' ',0};' >> > makedevs.c > > The last few lines of truss.log shows: > 9310: > stat("/usr/share/misc/terminfo.db",{mode=-rw-r--r-- > ,inode=22613331,size= > 3170304,blksize=4096}) = 0 (0x0) > 9310: > open("/usr/share/misc/terminfo.db",O_RDONLY,0644) > = 4 (0x4) > 9310: fcntl(4,F_SETFD,FD_CLOEXEC) = 0 (0x0) > 9310: > read(4,"\0\^F\^Ua\0\0\0\^B\0\0\^D\M-R\0"...,260) > = 260 (0x104) > 9310: > __sysctl(0xbfbfd574,0x2,0xbfbfd570,0xbfbfd57c,0x0,0x0) = 0 > (0x0) > 9310: lseek(4,0x132000,SEEK_SET) = 1253376 > (0x132000) > 9310: > read(4,"\^^\0\M-|\^O\M-T\^O\M-K\^O\M-*"...,4096) > = 4096 (0x1000) > 9310: lseek(4,0x26b000,SEEK_SET) = 2535424 > (0x26b000) > 9310: > read(4,"\n\0\M-Y\^O\^O\n\0\n\r\^D\^E\^D"...,4096) > = 4096 (0x1000) > 9310: close(4) = 0 (0x0) > 9310: ioctl(2,TIOCGETA,0xbfbfdba4) = 0 (0x0) > 9310: ioctl(2,TIOCGETA,0x81020d8) = 0 (0x0) > 9310: ioctl(2,TIOCGETA,0xbfbfdb64) = 0 (0x0) > 9310: ioctl(2,TIOCGWINSZ,0xbfbfdbc4) = 0 (0x0) > 9310: fstat(1,{mode=p--------- > ,inode=0,size=0,blksize=4096}) = 0 (0x0) > 9310: process exit, rval = 0 > > Note, above log has no entry to open > /usr/src/usr.sbin/sysinstall/../../share/termcap/termcap.src. > > So what can be the issue, ncurses has not been patched > correctly or some essential files missing? If you guys think > that ncurses has not been patched correctly, then I'll > open another thread to discuss that. > There is another update. I have tested it with ncurses and ncurses-devel ports. It seems they don't work as the ncurses in the base system. The test is as follows: cc -o rtermcap /usr/src/usr.sbin/sysinstall/rtermcap.c /usr/ports/devel/ncurses/work/ncurses-5.6/build.nowidec/lib/libncurses.so.5.6 /usr/ports/devel/ncurses/work/ncurses-5.6/build.nowidec/lib/libtinfo.so.5.6 export LD_LIBRARY_PATH=/usr/ports/devel/ncurses/work/ncurses-5.6/build.nowidec/lib cp -v mypath/terminfo.db /usr/local/share/misc/ TERMCAP=/usr/src/usr.sbin/sysinstall/../../share/termcap/termcap.src ./rtermcap ansi | file2c 'const char termcap_ansi[] = {' ',0};' >> makedevs.c cat makedevs.c const char termcap_ansi[] = { ,0}; Please note above mypath/terminfo.db is from my build. Another observation is ncurses in the base system does not look for terminfo.db, where as ncurses and ncurses-devel ports look for terminfo.db. So the question is, do ncurses and ncurses-devel ports do the same thing as ncurses in base system for the following statement? TERMCAP=/usr/src/usr.sbin/sysinstall/../../share/termcap/termcap.src ./rtermcap ansi | file2c 'const char termcap_ansi[] = {' ',0};' >> makedevs.c Any ideas? Best Regrds Unga From owner-freebsd-stable@FreeBSD.ORG Wed Aug 13 07:33:46 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AB813106567C for ; Wed, 13 Aug 2008 07:33:46 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.235]) by mx1.freebsd.org (Postfix) with ESMTP id 4D0658FC15 for ; Wed, 13 Aug 2008 07:33:46 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: by wr-out-0506.google.com with SMTP id c8so1205873wra.27 for ; Wed, 13 Aug 2008 00:33:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=8EMcxaPaepK61Sga08Lw+BJkv3bMhNwCSz5ezs+XI4U=; b=K8Y4rUPNNERUayaW+4bp7Rb/HO2NBPla/OS6zIFa3Sw8OsWxO7BwN5hAeD8nL0tMSo b3LApzGOEcgip1c0Jae9KubKXuchBQwXC0REPW6qg/dmWY2HsCuUQZm8uSCVqHyZoISr +PDFMKcgk/x5sV/9NUKbvKcfgQ7p7w4WXP4kY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=MXFvsWjmmr7NKTVpXfRMrK4lHzf93lxFEXnTH/rjFQhJ+iidXMjainqBQj5eIafcGm dTwxqan08t2Z/KYzsZ5cHcpgTK48C6SFjaG+MYqLhc7H19xTyXP1p2UQgNijd828PyVu o96HSNCLN/acR0HswOa9ptnNXRU3nnh3Sy39k= Received: by 10.90.55.20 with SMTP id d20mr8646289aga.65.1218612825411; Wed, 13 Aug 2008 00:33:45 -0700 (PDT) Received: by 10.90.81.10 with HTTP; Wed, 13 Aug 2008 00:33:45 -0700 (PDT) Message-ID: Date: Wed, 13 Aug 2008 11:33:45 +0400 From: pluknet To: "John Baldwin" In-Reply-To: <200808121111.37427.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: base64 Content-Disposition: inline References: <20080730113449.GD407@cdnetworks.co.kr> <200808111315.23879.jhb@freebsd.org> <200808121111.37427.jhb@freebsd.org> Cc: freebsd-stable@freebsd.org, Ulrich Spoerlein Subject: Re: cpufreq(4) panic on RELENG_7 (was: Re: Call for bfe(4) testers.) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2008 07:33:46 -0000 MjAwOC84LzEyIEpvaG4gQmFsZHdpbiA8amhiQGZyZWVic2Qub3JnPjoKPiBPbiBUdWVzZGF5IDEy IEF1Z3VzdCAyMDA4IDA0OjM2OjI5IGFtIHBsdWtuZXQgd3JvdGU6Cj4+IDIwMDgvOC8xMSBKb2hu IEJhbGR3aW4gPGpoYkBmcmVlYnNkLm9yZz46Cj4+ID4gT24gTW9uZGF5IDExIEF1Z3VzdCAyMDA4 IDEyOjM1OjE3IHBtIHBsdWtuZXQgd3JvdGU6Cj4+ID4+IDIwMDgvOC8xMSBKb2huIEJhbGR3aW4g PGpoYkBmcmVlYnNkLm9yZz46Cj4+ID4+ID4gT24gU2F0dXJkYXkgMDkgQXVndXN0IDIwMDggMDc6 MTY6MzcgYW0gVWxyaWNoIFNwb2VybGVpbiB3cm90ZToKPj4gPj4gPj4gSGkgSm9obiwKPj4gPj4g Pj4KPj4gPj4gPj4gSSBub3cgZmlndXJlZCBvdXQgdGhlICJ3aG8iLCB0aGUgIndoeSIgc3RpbGwg ZWx1ZGVzIG1lLgo+PiA+PiA+Pgo+PiA+PiA+PiBTbywgYWZ0ZXIgeW91ciBNRkMgb2YgaWNoc3Mu YyBvbiBKdW5lIDI3dGggdGhlIGRldmljZSBub3cgYXR0YWNoZXMgYXQKPiBteQo+PiA+PiA+PiBs YXB0b3AuIEl0IGRpZG4ndCBiZWZvcmUsIHNvIGl0IGNvdWxkIGNhdXNlIG5vIHRyb3VibGUuCj4+ ID4+ID4+Cj4+ID4+ID4+IFdpdGggaWNoc3MgbG9hZGVkLCB0aGUga2VybmVsIHdpbGwgcGFuaWMg MS0zIG1pbnV0ZXMgYWZ0ZXIgcG93ZXJkIGhhcwo+PiA+PiA+PiBiZWVuIHN0YXJ0ZWQgKGlmIEkg a2lsbCBwb3dlcmQgZWFybHkgZW5vdWdoLCBpdCBzZWVtcyBwcmV0dHkgc3RhYmxlKS4KPj4gPj4g Pj4KPj4gPj4gPj4gSSdtIG5vdyBydW5uaW5nIGEga2VybmVsIGZyb20gMjAwOC0wOC0wOCB3aXRo Cj4+ID4+ID4+IGhpbnQuaWNoc3MuMC5kaXNhYmxlZD0iMSIKPj4gPj4gPgo+PiA+PiA+IE9rLiAg Q2FuIHlvdSBnZXQgYSBjcmFzaGR1bXAgZnJvbSBhIGNyYXNoPwo+PiA+PiA+Cj4+ID4+Cj4+ID4+ IGVobSwuIEkgYW0gbm90IFVscmljaCBTcG9lcmxlaW4sIGJ1dCBJIGNhbiBoZWxwIHdpdGggdGhp cyBpc3N1ZS4KPj4gPj4KPj4gPj4gbXkgY3Jhc2hkdW1wIGZyb20ga2dkYiBhbmQgc29tZSBkZWJ1 ZyBpbmZvLgo+PiA+PiAob3VjaCwgSSBmb3Jnb3QgdG8gaW5jbHVkZSBpdCBpbiBteSBwcmV2LiBt YWlsCj4+ID4+Cj4gaHR0cDovL2xpc3RzLmZyZWVic2Qub3JnL3BpcGVybWFpbC9mcmVlYnNkLXN0 YWJsZS8yMDA4LUF1Z3VzdC8wNDQxODIuaHRtbCApCj4+ID4+Cj4+ID4+IHdiciwKPj4gPj4gcGx1 a25ldAo+PiA+Pgo+PiA+PiBVbnJlYWQgcG9ydGlvbiBvZiB0aGUga2VybmVsIG1lc3NhZ2UgYnVm ZmVyOgo+PiA+Pgo+PiA+Pgo+PiA+PiBGYXRhbCB0cmFwIDEyOiBwYWdlIGZhdWx0IHdoaWxlIGlu IGtlcm5lbCBtb2RlCj4+ID4+IGZhdWx0IHZpcnR1YWwgYWRkcmVzcyAgID0gMHgzOAo+PiA+PiBm YXVsdCBjb2RlICAgICAgICAgICAgICA9IHN1cGVydmlzb3IgcmVhZCwgcGFnZSBub3QgcHJlc2Vu dAo+PiA+PiBpbnN0cnVjdGlvbiBwb2ludGVyICAgICA9IDB4MjA6MHhjMDU2Y2Y0Ngo+PiA+PiBz dGFjayBwb2ludGVyICAgICAgICAgICA9IDB4Mjg6MHhlNjU5MmFjOAo+PiA+PiBmcmFtZSBwb2lu dGVyICAgICAgICAgICA9IDB4Mjg6MHhlNjU5MmFjOAo+PiA+PiBjb2RlIHNlZ21lbnQgICAgICAg ICAgICA9IGJhc2UgMHgwLCBsaW1pdCAweGZmZmZmLCB0eXBlIDB4MWIKPj4gPj4gICAgICAgICAg ICAgICAgICAgICAgICAgPSBEUEwgMCwgcHJlcyAxLCBkZWYzMiAxLCBncmFuIDEKPj4gPj4gcHJv Y2Vzc29yIGVmbGFncyAgICAgICAgPSBpbnRlcnJ1cHQgZW5hYmxlZCwgcmVzdW1lLCBJT1BMID0g MAo+PiA+PiBjdXJyZW50IHByb2Nlc3MgICAgICAgICA9IDI1MDcgKHBvd2VyZCkKPj4gPj4gUGh5 c2ljYWwgbWVtb3J5OiAxMDE0IE1CCj4+ID4+IER1bXBpbmcgMTIwIE1COiAxMDUgODkgNzMgNTcg NDEgMjUgOQo+PiA+Pgo+PiA+PiAjMCAgZG9hZHVtcCAoKSBhdCBwY3B1Lmg6MTk1Cj4+ID4+IDE5 NSAgICAgcGNwdS5oOiBObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5Lgo+PiA+PiAgICAgICAgIGlu IHBjcHUuaAo+PiA+PiAoa2dkYikgYnQKPj4gPj4gIzAgIGRvYWR1bXAgKCkgYXQgcGNwdS5oOjE5 NQo+PiA+PiAjMSAgMHhjMDQ1OGY4OSBpbiBkYl9mbmNhbGwgKGR1bW15MT0tMTAxMDAyNzY0OCwg ZHVtbXkyPTAsIGR1bW15Mz0wLAo+PiA+PiAgICAgZHVtbXk0PTB4ZTY1OTI4NjAgIjCsysMiKSBh dCAvbWVkaWEvc3JjLTcvc3lzL2RkYi9kYl9jb21tYW5kLmM6NTE2Cj4+ID4+ICMyICAweGMwNDU5 NTNhIGluIGRiX2NvbW1hbmQgKGxhc3RfY21kcD0weGMwN2RjZjE0LCBjbWRfdGFibGU9MHgwLAo+ PiA+IGRvcGFnZXI9MSkKPj4gPj4gICAgIGF0IC9tZWRpYS9zcmMtNy9zeXMvZGRiL2RiX2NvbW1h bmQuYzo0MTMKPj4gPj4gIzMgIDB4YzA0NTk2NTUgaW4gZGJfY29tbWFuZF9sb29wICgpCj4+ID4g YXQgL21lZGlhL3NyYy03L3N5cy9kZGIvZGJfY29tbWFuZC5jOjQ2Ngo+PiA+PiAjNCAgMHhjMDQ1 YjE3YyBpbiBkYl90cmFwICh0eXBlPTEyLCBjb2RlPTApCj4+ID4+ICAgICBhdCAvbWVkaWEvc3Jj LTcvc3lzL2RkYi9kYl9tYWluLmM6MjI4Cj4+ID4+ICM1ICAweGMwNTc1MDIzIGluIGtkYl90cmFw ICh0eXBlPTEyLCBjb2RlPTAsIHRmPTB4ZTY1OTJhODgpCj4+ID4+ICAgICBhdCAvbWVkaWEvc3Jj LTcvc3lzL2tlcm4vc3Vicl9rZGIuYzo1MjQKPj4gPj4gIzYgIDB4YzA3NDYwYmYgaW4gdHJhcF9m YXRhbCAoZnJhbWU9MHhlNjU5MmE4OCwgZXZhPTU2KQo+PiA+PiAgICAgYXQgL21lZGlhL3NyYy03 L3N5cy9pMzg2L2kzODYvdHJhcC5jOjg5MAo+PiA+PiAjNyAgMHhjMDc0NjM2YiBpbiB0cmFwX3Bm YXVsdCAoZnJhbWU9MHhlNjU5MmE4OCwgdXNlcm1vZGU9MCwgZXZhPTU2KQo+PiA+PiAgICAgYXQg L21lZGlhL3NyYy03L3N5cy9pMzg2L2kzODYvdHJhcC5jOjgxMgo+PiA+PiAjOCAgMHhjMDc0NmQz NiBpbiB0cmFwIChmcmFtZT0weGU2NTkyYTg4KQo+PiA+PiAgICAgYXQgL21lZGlhL3NyYy03L3N5 cy9pMzg2L2kzODYvdHJhcC5jOjQ5MAo+PiA+PiAjOSAgMHhjMDcyZmQ0YiBpbiBjYWxsdHJhcCAo KQo+IGF0IC9tZWRpYS9zcmMtNy9zeXMvaTM4Ni9pMzg2L2V4Y2VwdGlvbi5zOjEzOQo+PiA+PiAj MTAgMHhjMDU2Y2Y0NiBpbiBkZXZpY2VfaXNfYXR0YWNoZWQgKGRldj0weDApCj4+ID4+ICAgICBh dCAvbWVkaWEvc3JjLTcvc3lzL2tlcm4vc3Vicl9idXMuYzoyMjI4Cj4+ID4+ICMxMSAweGMwNTEy ZGU3IGluIGNmX3NldF9tZXRob2QgKGRldj0weGMzYzljODgwLCBsZXZlbD0weGM0NTI1ZWY0LAo+ PiA+PiAgICAgcHJpb3JpdHk9MTAwKSBhdCAvbWVkaWEvc3JjLTcvc3lzL2tlcm4va2Vybl9jcHUu YzozMzIKPj4gPj4gIzEyIDB4YzA1MTE0NTIgaW4gY3B1ZnJlcV9jdXJyX3N5c2N0bCAob2lkcD0w eGMzYzhiYWMwLCBhcmcxPTB4YzNiYzdjMDAsCj4+ID4+ICAgICBhcmcyPTAsIHJlcT0weGU2NTky YmE0KSBhdCBjcHVmcmVxX2lmLmg6MzIKPj4gPj4gLS0tVHlwZSA8cmV0dXJuPiB0byBjb250aW51 ZSwgb3IgcSA8cmV0dXJuPiB0byBxdWl0LS0tCj4+ID4+ICMxMyAweGMwNTU0YjY3IGluIHN5c2N0 bF9yb290IChvaWRwPVZhcmlhYmxlICJvaWRwIiBpcyBub3QgYXZhaWxhYmxlLgo+PiA+PiApCj4+ ID4+ICAgICBhdCAvbWVkaWEvc3JjLTcvc3lzL2tlcm4va2Vybl9zeXNjdGwuYzoxMzA2Cj4+ID4+ ICMxNCAweGMwNTU0Y2QxIGluIHVzZXJsYW5kX3N5c2N0bCAodGQ9MHhjNDI0NTQ0MCwgbmFtZT0w eGU2NTkyYzE0LAo+PiA+IG5hbWVsZW49NCwKPj4gPj4gICAgIG9sZD0weDAsIG9sZGxlbnA9MHgw LCBpbmtlcm5lbD0wLCBuZXc9MHhiZmJmZTdjNCwgbmV3bGVuPTQsCj4+ID4+ICAgICByZXR2YWw9 MHhlNjU5MmMxMCwgZmxhZ3M9MCkKPiBhdCAvbWVkaWEvc3JjLTcvc3lzL2tlcm4va2Vybl9zeXNj dGwuYzoxNDAxCj4+ID4+ICMxNSAweGMwNTU1YTdjIGluIF9fc3lzY3RsICh0ZD0weGM0MjQ1NDQw LCB1YXA9MHhlNjU5MmNmYykKPj4gPj4gICAgIGF0IC9tZWRpYS9zcmMtNy9zeXMva2Vybi9rZXJu X3N5c2N0bC5jOjEzMzYKPj4gPj4gIzE2IDB4YzA3NDY2ZDUgaW4gc3lzY2FsbCAoZnJhbWU9MHhl NjU5MmQzOCkKPj4gPj4gICAgIGF0IC9tZWRpYS9zcmMtNy9zeXMvaTM4Ni9pMzg2L3RyYXAuYzox MDM1Cj4+ID4+ICMxNyAweGMwNzJmZGIwIGluIFhpbnQweDgwX3N5c2NhbGwgKCkKPj4gPj4gICAg IGF0IC9tZWRpYS9zcmMtNy9zeXMvaTM4Ni9pMzg2L2V4Y2VwdGlvbi5zOjE5Ngo+PiA+PiAjMTgg MHgwMDAwMDAzMyBpbiA/PyAoKQo+PiA+PiBQcmV2aW91cyBmcmFtZSBpbm5lciB0byB0aGlzIGZy YW1lIChjb3JydXB0IHN0YWNrPykKPj4gPj4gKGtnZGIpIGYgMTEKPj4gPj4gIzExIDB4YzA1MTJk ZTcgaW4gY2Zfc2V0X21ldGhvZCAoZGV2PTB4YzNjOWM4ODAsIGxldmVsPTB4YzQ1MjVlZjQsCj4+ ID4+ICAgICBwcmlvcml0eT0xMDApIGF0IC9tZWRpYS9zcmMtNy9zeXMva2Vybi9rZXJuX2NwdS5j OjMzMgo+PiA+PiAzMzIgICAgICAgICAgICAgICAgICAgICBpZiAoIWRldmljZV9pc19hdHRhY2hl ZChzZXQtPmRldikpIHsKPj4gPj4gKGtnZGIpIGxpc3QKPj4gPj4gMzI3ICAgICAgICAgICAgIH0K Pj4gPj4gMzI4Cj4+ID4+IDMyOSAgICAgICAgICAgICAvKiBOZXh0LCBzZXQgYW55L2FsbCByZWxh dGl2ZSBmcmVxdWVuY2llcyB2aWEgdGhlaXIKPiBkcml2ZXJzLgo+PiA+ICovCj4+ID4+IDMzMCAg ICAgICAgICAgICBmb3IgKGkgPSAwOyBpIDwgbGV2ZWwtPnJlbF9jb3VudDsgaSsrKSB7Cj4+ID4+ IDMzMSAgICAgICAgICAgICAgICAgICAgIHNldCA9ICZsZXZlbC0+cmVsX3NldFtpXTsKPj4gPj4g MzMyICAgICAgICAgICAgICAgICAgICAgaWYgKCFkZXZpY2VfaXNfYXR0YWNoZWQoc2V0LT5kZXYp KSB7Cj4+ID4+IDMzMyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZXJyb3IgPSBFTlhJTzsK Pj4gPj4gMzM0ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBnb3RvIG91dDsKPj4gPj4gMzM1 ICAgICAgICAgICAgICAgICAgICAgfQo+PiA+PiAzMzYKPj4gPj4gKGtnZGIpIHAgbGV2ZWwucmVs X2NvdW50Cj4+ID4+ICQxID0gMTk4NjM1NjI3MQo+PiA+PiAoa2dkYikgcCBpCj4+ID4+ICQyID0g MAo+PiA+PiAoa2dkYikgcCBsZXZlbC5yZWxfc2V0Cj4+ID4+ICQzID0ge3tmcmVxID0gMCwgdm9s dHMgPSAwLCBwb3dlciA9IDAsIGxhdCA9IDAsIGRldiA9IDB4MCwgc3BlYyA9IHswLCAwLAo+IDAs Cj4+ID4+ICAgICAgIDB9fSwge2ZyZXEgPSAwLCB2b2x0cyA9IDAsIHBvd2VyID0gMCwgbGF0ID0g MCwgZGV2ID0gMHgwLCBzcGVjID0KPiB7MCwKPj4gPiAwLAo+PiA+PiAgICAgICAwLCAwfX0sIHtm cmVxID0gMCwgdm9sdHMgPSAwLCBwb3dlciA9IDAsIGxhdCA9IDAsIGRldiA9IDB4MCwgc3BlYyA9 Cj4+ID4gezAsCj4+ID4+ICAgICAgIDAsIDAsIDB9fSwge2ZyZXEgPSAwLCB2b2x0cyA9IDAsIHBv d2VyID0gMCwgbGF0ID0gMCwgZGV2ID0gMHgwLAo+IHNwZWMgPQo+PiA+IHsKPj4gPj4gICAgICAg MCwgMCwgMCwgMH19LCB7ZnJlcSA9IDAsIHZvbHRzID0gMCwgcG93ZXIgPSAwLCBsYXQgPSAwLCBk ZXYgPSAweDAsCj4+ID4+ICAgICBzcGVjID0gezAsIDAsIDAsIDB9fSwge2ZyZXEgPSAwLCB2b2x0 cyA9IDAsIHBvd2VyID0gMCwgbGF0ID0gMCwKPj4gPj4gICAgIGRldiA9IDB4NjU2ZTc1NTIsIHNw ZWMgPSB7ODI4ODU4NzAxLCAxMTYyNzYwMDE0LCAwLCAxMzQ2MzI0OTJ9fSwgewo+PiA+PiAgICAg ZnJlcSA9IDAsIHZvbHRzID0gNTMsIHBvd2VyID0gLTEwMjQsIGxhdCA9IC0xLCBkZXYgPSAweDdm ZmZmZmZmLCBzcGVjCj4gPQo+PiA+IHsKPj4gPj4gLS0tLS0gYW5kIHNvIG9uLS0tLS0KPj4gPj4K Pj4gPj4gQWxzbyB0aGVyZSBhcmUgdmVyeSB1bnVzdWFsIChhbmQgaGlnaCkgbnVtYmVycyBpbiBz eXNjdGwKPj4gPiBkZXYuY3B1LjAuZnJlcV9sZXZlbHMuCj4+ID4KPj4gPiBXaGljaCBjcHVmcmVx IGRyaXZlcnMgYXJlIHlvdSB1c2luZz8gIENhbiB5b3UgbmFycm93IGRvd24geW91ciBwYW5pY3Mg KGFuZAo+PiA+IHdlaXJkIGZyZXF1ZW5jaWVzIGluIHRoZSBzeXNjdGwpIHRvIGJlaW5nIGNhdXNl ZCBieSBhIHNwZWNpZmljIGNwdWZyZXEKPj4gPiBkcml2ZXI/Cj4+Cj4+IFRoZXkgYXJlIGVzdC9w NHRjYy9pY2hzcy4KPj4gaGludC5pY2hzcy4wLmRpc2JsZWQ9IjEiIGhlbHBlZCBtZSB0byBhdm9p ZCBwYW5pY3MgYW5kIHRob3NlIHdlaXJlZAo+PiBmcmVxcyBpbiBkZXYuY3B1Lgo+PiBOb3cgaXQg c2hvd3M6Cj4+IGNwdTA6IDxBQ1BJIENQVT4gb24gYWNwaTAKPj4gZXN0MDogPEVuaGFuY2VkIFNw ZWVkU3RlcCBGcmVxdWVuY3kgQ29udHJvbD4gb24gY3B1MAo+PiBwNHRjYzA6IDxDUFUgRnJlcXVl bmN5IFRoZXJtYWwgQ29udHJvbD4gb24gY3B1MAo+PiBhbmQgZGV2LmNwdS4wLmZyZXFfbGV2ZWxz IGFyZSBhcyBleHBlY3RlZCAoYW5kIGFzIGl0IHdhcyBlYXJsaWVyCj4+IGJlZm9yZSB0aGlzIHBy b2JsZW0pOgo+PiAgMTYwMC8tMSAxNDAwLy0xIDEyMjUvLTEgMTIwMC8tMSAxMDUwLy0xIDEwMDAv LTEgODc1Ly0xIDgwMC8tMSA3MDAvLTEKPj4gNjAwLy0xIDUyNS8tMSA0NTAvLTEgMzc1Ly0xIDMw MC8tMSAyMjUvLTEgMTUwLy0xIDc1Ly0xCltzb3JyeSwgd2FzIGZhciBhZmtdCgo+Cj4gVHJ5IGh0 dHA6Ly93d3cuZnJlZWJzZC5vcmcvfmpoYi9wYXRjaGVzL2NwdWZyZXFfb3JkZXIucGF0Y2ggIGlj aHNzMCBpcyBvbmx5Cj4gc3VwcG9zZWQgdG8gYmUgdXNlZCBpZiB5b3UgZG9uJ3QgaGF2ZSBlc3Qw LCBhbmQgdGhpcyBwYXRjaCBmaXhlcyB0aGF0LiAgSSdtCgpXb3JrcyBub3cgYXMgaXQgc2hvdWxk IChpLmUuIGljaHNzMCBkb2VzIG5vdCBhdHRhY2gpLgoKPiBjdXJpb3VzIGlmIHlvdSBnZXQgcGFu aWNzIGlmIHlvdSBoYXZlIGRpc2FibGUgZXN0MCBhbmQgbGVhdmUgaWNoc3MwIGVuYWJsZWQKPiBv ciBpZiB0aGF0IHdvcmtzIG9rPwoKWWVzLCBpdCB3b3JrcyBvayB3aXRoIGhpbnQuZXN0LjAuZGlz YWJsZWQ9IjEiICh3aXRoIHNvbWV3aGF0IGRpZmZlcmVudApmcmVxJ3MgKGFuZCBzdWJqZWN0aXZl bHkgYSBiaXQgc2xvd2VyIGV2ZW4gd2l0aCBtYXggZnJlcSkpOgoKY3B1MDogPEFDUEkgQ1BVPiBv biBhY3BpMAppY2hzczA6IDxTcGVlZFN0ZXAgSUNIPiBvbiBjcHUwCmljaHNzMDogZW5hYmxpbmcg U3BlZWRTdGVwIHN1cHBvcnQKcDR0Y2MwOiA8Q1BVIEZyZXF1ZW5jeSBUaGVybWFsIENvbnRyb2w+ IG9uIGNwdTAKYWNwaV9hY2FkMDogPEFDIEFkYXB0ZXI+IG9uIGFjcGkwCgokIHN5c2N0bCBkZXYu Y3B1CmRldi5jcHUuMC4lZGVzYzogQUNQSSBDUFUKZGV2LmNwdS4wLiVkcml2ZXI6IGNwdQpkZXYu Y3B1LjAuJWxvY2F0aW9uOiBoYW5kbGU9XF9QUl8uQ1BVMApkZXYuY3B1LjAuJXBucGluZm86IF9I SUQ9bm9uZSBfVUlEPTAKZGV2LmNwdS4wLiVwYXJlbnQ6IGFjcGkwCmRldi5jcHUuMC5mcmVxOiA3 OTUKZGV2LmNwdS4wLmZyZXFfbGV2ZWxzOiAxNTkwLy0xIDEzOTEvLTEgMTE5Mi8tMSA5OTMvLTEg Nzk1Ly0xIDU5Ni8tMQozOTcvLTEgMTk4Ly0xCmRldi5jcHUuMC5jeF9zdXBwb3J0ZWQ6IEMxLzEg QzIvMSBDMy84NSBDNC8xODUKZGV2LmNwdS4wLmN4X2xvd2VzdDogQzEKZGV2LmNwdS4wLmN4X3Vz YWdlOiAxMDAuMDAlIDAuMDAlIDAuMDAlIDAuMDAlCgpUaGFua3MsCnBsdWtuZXQK From owner-freebsd-stable@FreeBSD.ORG Wed Aug 13 09:28:54 2008 Return-Path: Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7B558106566B for ; Wed, 13 Aug 2008 09:28:54 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [212.17.241.230]) by mx1.freebsd.org (Postfix) with ESMTP id CF50C8FC26 for ; Wed, 13 Aug 2008 09:28:53 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.1/8.14.1) with ESMTP id m7D9SQff027550; Wed, 13 Aug 2008 11:28:39 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.1/8.14.1/Submit) id m7D9SPmG027548; Wed, 13 Aug 2008 11:28:25 +0200 (CEST) (envelope-from olli) From: Oliver Fromme Message-Id: <200808130928.m7D9SPmG027548@lurza.secnetix.de> To: unga888@yahoo.com Date: Wed, 13 Aug 2008 11:28:25 +0200 (CEST) In-Reply-To: <268893.22415.qm@web57009.mail.re3.yahoo.com> X-Mailer: ELM [version 2.5 PL8] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Wed, 13 Aug 2008 11:28:39 +0200 (CEST) Cc: freebsd-stable@FreeBSD.ORG Subject: Re: sysinstall compilation issue X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2008 09:28:54 -0000 Hello, Unga wrote: > > Oliver Fromme wrote: > > > Unga wrote: > > > > [...] > > > > What is wrong at my end? > > > > > > > > Note, I linked the rtermcap with ncursesw > > > > libraries, can that be the cause? Any ideas? > > > > > > Yes, that's the cause. Why did you do that? > > > > > > FreeBSD's ncurses port contains a patch so the > > > tgetent() function (which is used by rtermcap) > > > returns the actual termcap entry in the buffer. > > > The original ncurses code (which is terminfo- > > > based) doesn't do that. > > > > > > When you linked rtermcap with the wrong library, > > > you restored the original behaviour of tgetent(), > > > so the output of rtermcap was empty, so file2c > > > produced invalid source. > > > > Sorry for my late reply on this. I was not well during > > weekend, an eye ache due to over work :( Sorry to hear that. I hope you're better now. > > Here is the situation at my end, no matter whether I link > > with ncurses widec libs or non-widec libs, its still return > > the same code as above I mentioned. > > > > Possible causes can be: > > 1. The way I compile and install ncurses is not correct. > > 2. OR some essential files required are missing > > 3. OR there can be an other option Maybe my first response wasn't clear enough. So let me explain it again: To compile sysinstall correctly you must use the standard ncurses library from the base system. Anything else WILL NOT WORK. I already explained the reason for that in detail in my previous response (quoted above). > So the question is, do ncurses and ncurses-devel ports > do the same thing as ncurses in base system for the > following statement? > TERMCAP=/usr/src/usr.sbin/sysinstall/../../share/termcap/termcap.src ./rtermcap ansi | file2c 'const char termcap_ansi[] = {' ',0};' >> makedevs.c No, they don't do the same thing. You could have saved yourself some time if you had read my first response more carefully. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd $ dd if=/dev/urandom of=test.pl count=1 $ file test.pl test.pl: perl script text executable From owner-freebsd-stable@FreeBSD.ORG Wed Aug 13 10:05:02 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 438A2106566B for ; Wed, 13 Aug 2008 10:05:02 +0000 (UTC) (envelope-from markus@vervier.info) Received: from mail.system360.de (mail.system360.de [84.254.79.40]) by mx1.freebsd.org (Postfix) with ESMTP id EF23B8FC15 for ; Wed, 13 Aug 2008 10:05:01 +0000 (UTC) (envelope-from markus@vervier.info) Received: from localhost (mail [84.254.79.40]) by mail.system360.de (Postfix) with ESMTP id 4DCD5BEA4D; Wed, 13 Aug 2008 12:15:21 +0200 (CEST) X-Virus-Scanned: amavisd-new at system360.de Received: from mail.system360.de ([84.254.79.40]) by localhost (mail.system360.de [84.254.79.40]) (amavisd-new, port 10024) with ESMTP id MhGSyev0rZkE; Wed, 13 Aug 2008 12:15:19 +0200 (CEST) Received: from [192.168.2.15] (p5B3963E9.dip.t-dialin.net [91.57.99.233]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.system360.de (Postfix) with ESMTP id D78BBBEA36; Wed, 13 Aug 2008 12:15:18 +0200 (CEST) Message-ID: <48A2B1CB.7060303@vervier.info> Date: Wed, 13 Aug 2008 12:04:59 +0200 From: Markus Vervier User-Agent: Thunderbird 2.0.0.14 (X11/20080421) MIME-Version: 1.0 To: Jack Vogel References: <489C4129.4090303@vervier.info> <489C88DB.6030000@vervier.info> <2a41acea0808081131m1eddc4caib0963c8a5443afd2@mail.gmail.com> <200808110819.53914.josh@tcbug.org> <20080811140249.GA27379@eos.sc1.parodius.com> <2a41acea0808110928h10d54441o7d49b11a60406934@mail.gmail.com> <48A0A1D9.8030601@vervier.info> <2a41acea0808111340o7b506804u9e4c95f1af22b95c@mail.gmail.com> In-Reply-To: <2a41acea0808111340o7b506804u9e4c95f1af22b95c@mail.gmail.com> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: em(4) on FreeBSD is sometimes annoying X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2008 10:05:02 -0000 Jack Vogel wrote: > > I didn't mean the NIC EEPROM, but the system BIOS, make sure you are > running the version that Jeremy said he was, if that matches you might go > look at settings in the BIOS that are about management. > I'm now running the latest BIOS for my X60 version 2.22 with the same results. Jeremy runs version 1.15 but on a T60. > I thought you told us that when you had a back to back connection that it > worked, no?? Sorry, it does not work when having a b2b connection, never said that. But I noticed another thing: It is important that the device was up without a cable connected: 1. power off completely 2. boot freebsd without a cable connected 3. in a rootshell do ifconfig em0 up 4. connect the cable 5. no link -- Markus From owner-freebsd-stable@FreeBSD.ORG Wed Aug 13 10:31:25 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AF7D61065695; Wed, 13 Aug 2008 10:31:25 +0000 (UTC) (envelope-from BORJAMAR@SARENET.ES) Received: from proxypop2.sarenet.es (proxypop2.sarenet.es [194.30.0.95]) by mx1.freebsd.org (Postfix) with ESMTP id B76EF8FC23; Wed, 13 Aug 2008 10:31:24 +0000 (UTC) (envelope-from BORJAMAR@SARENET.ES) Received: from [127.0.0.1] (matahari.sarenet.es [192.148.167.18]) by proxypop2.sarenet.es (Postfix) with ESMTP id 9754A730EB; Wed, 13 Aug 2008 12:31:21 +0200 (CEST) Message-Id: <659A017B-5D6F-4B74-A85D-4A9A040CA442@SARENET.ES> From: Borja Marcos To: Jeremy Chadwick In-Reply-To: <20080812102856.GA6735@eos.sc1.parodius.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v928.1) Date: Wed, 13 Aug 2008 12:31:37 +0200 References: <43EC06E9-76B3-4AA1-BC5E-4E1BD64AFC2D@SARENET.ES> <0296197A-28ED-4DAA-A31F-C28471E864FB@SARENET.ES> <20080812102856.GA6735@eos.sc1.parodius.com> X-Mailer: Apple Mail (2.928.1) Cc: freebsd-stable@freebsd.org, Ivan Voras Subject: Re: umtxn and Apache 2.2 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2008 10:31:25 -0000 On Aug 12, 2008, at 12:28 PM, Jeremy Chadwick wrote: > Please be sure to report back with the outcome (in a few days, or > whenever suits you) -- I've seen a report of similar oddities (threads > locking up) on the suPHP mailing list, when using Apache with the > worker > MPM. No one stated what state the process is in (re: umtxn), so I'm > not > sure if it's the same issue as what you've seen. I've recompiled Apache with the debug options. Just to see if there was a difference I've tried the apr from the ports, but it's the same. However, the incidence of this problem seems to be lower. %ldd /usr/local/sbin/httpd /usr/local/sbin/httpd: libm.so.5 => /lib/libm.so.5 (0x380e1000) libaprutil-1.so.3 => /usr/local/lib/libaprutil-1.so.3 (0x380f6000) libexpat.so.6 => /usr/local/lib/libexpat.so.6 (0x38111000) libiconv.so.3 => /usr/local/lib/libiconv.so.3 (0x3813d000) libapr-1.so.3 => /usr/local/lib/libapr-1.so.3 (0x38231000) libcrypt.so.4 => /lib/libcrypt.so.4 (0x38255000) libthr.so.3 => /lib/libthr.so.3 (0x3826e000) libc.so.7 => /lib/libc.so.7 (0x38281000) And I've hooked gdb to one of the stuck processes, %gdb -p 51845 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd". Attaching to process 51845 /usr/src/gnu/usr.bin/gdb/libgdb/../../../../contrib/gdb/gdb/solib- svr4.c:1443: internal-error: legacy_fetch_link_map_offsets called without legacy link_map support enabled. A problem internal to GDB has been detected, further debugging may prove unreliable. Quit this debugging session? (y or n) n /usr/src/gnu/usr.bin/gdb/libgdb/../../../../contrib/gdb/gdb/solib- svr4.c:1443: internal-error: legacy_fetch_link_map_offsets called without legacy link_map support enabled. A problem internal to GDB has been detected, further debugging may prove unreliable. Create a core file of GDB? (y or n) n Strange, it seems gdb is having problems with this? Anyway I go ahead. The stack seems to be corrupted. I've observed that the incidence of this problem is much lower if I lower the MaxRequestsPerChild parameter in Apache. Other than this, it's working very well, and performance is decent. I include a link to the system statistics generated with Devilator/Orca. Please don't load this link a lot, it's behind a household 384 Kbps outbound DSL :) http://212.81.200.214/orca/o_macuarium-hourly.html http://212.81.200.214/orca/o_macuarium-daily.html http://212.81.200.214/orca/o_macuarium-weekly.html ((Sorry for the long dump)) (gdb) bt #0 0x3827cfe7 in __error () from /lib/libthr.so.3 #1 0x3827cd4a in __error () from /lib/libthr.so.3 #2 0x08702120 in ?? () #3 0x00000008 in ?? () #4 0x00000001 in ?? () #5 0x08702100 in ?? () #6 0x00000000 in ?? () #7 0x3827e914 in ?? () from /lib/libthr.so.3 #8 0xbdfe4ea8 in ?? () #9 0x3827b4fe in pthread_cond_init () from /lib/libthr.so.3 Previous frame identical to this frame (corrupt stack?) (gdb) thread 2 [Switching to thread 2 (Thread 0x8705900 (LWP 100279))]#0 0x382c578b in _umtx_op () from /lib/libc.so.7 (gdb) bt #0 0x382c578b in _umtx_op () from /lib/libc.so.7 #1 0x3827ce0d in __error () from /lib/libthr.so.3 #2 0x08642140 in ?? () #3 0x00000005 in ?? () #4 0x00000000 in ?? () #5 0x00000000 in ?? () #6 0x00000000 in ?? () #7 0x3827e914 in ?? () from /lib/libthr.so.3 #8 0xbe0e5c18 in ?? () #9 0x38278818 in pthread_mutex_getprioceiling () from /lib/libthr.so.3 Previous frame identical to this frame (corrupt stack?) (gdb) thread 3 [Switching to thread 3 (Thread 0x8705800 (LWP 100275))]#0 0x382c578b in _umtx_op () from /lib/libc.so.7 (gdb) bt #0 0x382c578b in _umtx_op () from /lib/libc.so.7 #1 0x3827ce0d in __error () from /lib/libthr.so.3 #2 0x08642140 in ?? () #3 0x00000005 in ?? () #4 0x00000000 in ?? () #5 0x00000000 in ?? () #6 0x00000000 in ?? () #7 0x3827e914 in ?? () from /lib/libthr.so.3 #8 0xbe1e6c18 in ?? () #9 0x38278818 in pthread_mutex_getprioceiling () from /lib/libthr.so.3 Previous frame identical to this frame (corrupt stack?) (gdb) thread 4 [Switching to thread 4 (Thread 0x8705700 (LWP 100273))]#0 0x382c578b in _umtx_op () from /lib/libc.so.7 (gdb) bt #0 0x382c578b in _umtx_op () from /lib/libc.so.7 #1 0x3827ce0d in __error () from /lib/libthr.so.3 #2 0x08642140 in ?? () #3 0x00000005 in ?? () #4 0x00000000 in ?? () #5 0x00000000 in ?? () #6 0x00000000 in ?? () #7 0x3827e914 in ?? () from /lib/libthr.so.3 #8 0xbe2e7c18 in ?? () #9 0x38278818 in pthread_mutex_getprioceiling () from /lib/libthr.so.3 Previous frame identical to this frame (corrupt stack?) (gdb) thread 5 [Switching to thread 5 (Thread 0x8705600 (LWP 100266))]#0 0x382c578b in _umtx_op () from /lib/libc.so.7 (gdb) bt #0 0x382c578b in _umtx_op () from /lib/libc.so.7 #1 0x3827ce0d in __error () from /lib/libthr.so.3 #2 0x08642140 in ?? () #3 0x00000005 in ?? () #4 0x00000000 in ?? () #5 0x00000000 in ?? () #6 0x00000000 in ?? () #7 0x3827e914 in ?? () from /lib/libthr.so.3 #8 0xbe3e8c18 in ?? () #9 0x38278818 in pthread_mutex_getprioceiling () from /lib/libthr.so.3 Previous frame identical to this frame (corrupt stack?) (gdb) thread 6 [Switching to thread 6 (Thread 0x8705500 (LWP 100262))]#0 0x382c578b in _umtx_op () from /lib/libc.so.7 (gdb) bt #0 0x382c578b in _umtx_op () from /lib/libc.so.7 #1 0x3827ce0d in __error () from /lib/libthr.so.3 #2 0x08642140 in ?? () #3 0x00000005 in ?? () #4 0x00000000 in ?? () #5 0x00000000 in ?? () #6 0x00000000 in ?? () #7 0x3827e914 in ?? () from /lib/libthr.so.3 #8 0xbe4e9c18 in ?? () #9 0x38278818 in pthread_mutex_getprioceiling () from /lib/libthr.so.3 Previous frame identical to this frame (corrupt stack?) (gdb) thread 7 [Switching to thread 7 (Thread 0x8705400 (LWP 100258))]#0 0x382c578b in _umtx_op () from /lib/libc.so.7 (gdb) bt #0 0x382c578b in _umtx_op () from /lib/libc.so.7 #1 0x3827ce0d in __error () from /lib/libthr.so.3 #2 0x08642140 in ?? () #3 0x00000005 in ?? () #4 0x00000000 in ?? () #5 0x00000000 in ?? () #6 0x00000000 in ?? () #7 0x3827e914 in ?? () from /lib/libthr.so.3 #8 0xbe5eac18 in ?? () #9 0x38278818 in pthread_mutex_getprioceiling () from /lib/libthr.so.3 Previous frame identical to this frame (corrupt stack?) (gdb) thread 8 [Switching to thread 8 (Thread 0x8705300 (LWP 100256))]#0 0x382c578b in _umtx_op () from /lib/libc.so.7 (gdb) bt #0 0x382c578b in _umtx_op () from /lib/libc.so.7 #1 0x3827ce0d in __error () from /lib/libthr.so.3 #2 0x08642140 in ?? () #3 0x00000005 in ?? () #4 0x00000000 in ?? () #5 0x00000000 in ?? () #6 0x00000000 in ?? () #7 0x3827e914 in ?? () from /lib/libthr.so.3 #8 0xbe6ebc18 in ?? () #9 0x38278818 in pthread_mutex_getprioceiling () from /lib/libthr.so.3 Previous frame identical to this frame (corrupt stack?) (gdb) thread 9 [Switching to thread 9 (Thread 0x8705200 (LWP 100255))]#0 0x382c578b in _umtx_op () from /lib/libc.so.7 (gdb) bt #0 0x382c578b in _umtx_op () from /lib/libc.so.7 #1 0x3827ce0d in __error () from /lib/libthr.so.3 #2 0x08642100 in ?? () #3 0x00000005 in ?? () #4 0x00000000 in ?? () #5 0x00000000 in ?? () #6 0x00000000 in ?? () #7 0x3827e914 in ?? () from /lib/libthr.so.3 #8 0xbe7ec5c8 in ?? () #9 0x38278818 in pthread_mutex_getprioceiling () from /lib/libthr.so.3 Previous frame identical to this frame (corrupt stack?) (gdb) thread 10 [Switching to thread 10 (Thread 0x8705100 (LWP 100253))]#0 0x382c578b in _umtx_op () from /lib/libc.so.7 (gdb) bt #0 0x382c578b in _umtx_op () from /lib/libc.so.7 #1 0x3827ce0d in __error () from /lib/libthr.so.3 #2 0x08642140 in ?? () #3 0x00000005 in ?? () #4 0x00000000 in ?? () #5 0x00000000 in ?? () #6 0x00000000 in ?? () #7 0x3827e914 in ?? () from /lib/libthr.so.3 #8 0xbe8edc18 in ?? () #9 0x38278818 in pthread_mutex_getprioceiling () from /lib/libthr.so.3 Previous frame identical to this frame (corrupt stack?) (gdb) thread 11 [Switching to thread 11 (Thread 0x8705000 (LWP 100252))]#0 0x382c578b in _umtx_op () from /lib/libc.so.7 (gdb) bt #0 0x382c578b in _umtx_op () from /lib/libc.so.7 #1 0x3827ce0d in __error () from /lib/libthr.so.3 #2 0x08642140 in ?? () #3 0x00000005 in ?? () #4 0x00000000 in ?? () #5 0x00000000 in ?? () #6 0x00000000 in ?? () #7 0x3827e914 in ?? () from /lib/libthr.so.3 #8 0xbe9eec18 in ?? () #9 0x38278818 in pthread_mutex_getprioceiling () from /lib/libthr.so.3 Previous frame identical to this frame (corrupt stack?) (gdb) thread 12 [Switching to thread 12 (Thread 0x8704f00 (LWP 100244))]#0 0x382c578b in _umtx_op () from /lib/libc.so.7 (gdb) bt #0 0x382c578b in _umtx_op () from /lib/libc.so.7 #1 0x3827ce0d in __error () from /lib/libthr.so.3 #2 0x08642140 in ?? () #3 0x00000005 in ?? () #4 0x00000000 in ?? () #5 0x00000000 in ?? () #6 0x00000000 in ?? () #7 0x3827e914 in ?? () from /lib/libthr.so.3 #8 0xbeaefc18 in ?? () #9 0x38278818 in pthread_mutex_getprioceiling () from /lib/libthr.so.3 Previous frame identical to this frame (corrupt stack?) (gdb) thread 13 [Switching to thread 13 (Thread 0x8704e00 (LWP 100243))]#0 0x382c578b in _umtx_op () from /lib/libc.so.7 (gdb) bt #0 0x382c578b in _umtx_op () from /lib/libc.so.7 #1 0x3827ce0d in __error () from /lib/libthr.so.3 #2 0x08642140 in ?? () #3 0x00000005 in ?? () #4 0x00000000 in ?? () #5 0x00000000 in ?? () #6 0x00000000 in ?? () #7 0x3827e914 in ?? () from /lib/libthr.so.3 #8 0xbebf0c18 in ?? () #9 0x38278818 in pthread_mutex_getprioceiling () from /lib/libthr.so.3 Previous frame identical to this frame (corrupt stack?) (gdb) thread 14 [Switching to thread 14 (Thread 0x8704d00 (LWP 100241))]#0 0x382c578b in _umtx_op () from /lib/libc.so.7 (gdb) bt #0 0x382c578b in _umtx_op () from /lib/libc.so.7 #1 0x3827ce0d in __error () from /lib/libthr.so.3 #2 0x08642140 in ?? () #3 0x00000005 in ?? () #4 0x00000000 in ?? () #5 0x00000000 in ?? () #6 0x00000000 in ?? () #7 0x3827e914 in ?? () from /lib/libthr.so.3 #8 0xbecf1c18 in ?? () #9 0x38278818 in pthread_mutex_getprioceiling () from /lib/libthr.so.3 Previous frame identical to this frame (corrupt stack?) (gdb) yjread 15 Undefined command: "yjread". Try "help". (gdb) bt #0 0x382c578b in _umtx_op () from /lib/libc.so.7 #1 0x3827ce0d in __error () from /lib/libthr.so.3 #2 0x08642140 in ?? () #3 0x00000005 in ?? () #4 0x00000000 in ?? () #5 0x00000000 in ?? () #6 0x00000000 in ?? () #7 0x3827e914 in ?? () from /lib/libthr.so.3 #8 0xbecf1c18 in ?? () #9 0x38278818 in pthread_mutex_getprioceiling () from /lib/libthr.so.3 (gdb) thread 15 [Switching to thread 15 (Thread 0x8704c00 (LWP 100239))]#0 0x382c578b in _umtx_op () from /lib/libc.so.7 (gdb) bt #0 0x382c578b in _umtx_op () from /lib/libc.so.7 #1 0x3827ce0d in __error () from /lib/libthr.so.3 #2 0x08642140 in ?? () #3 0x00000005 in ?? () #4 0x00000000 in ?? () #5 0x00000000 in ?? () #6 0x00000000 in ?? () #7 0x3827e914 in ?? () from /lib/libthr.so.3 #8 0xbedf2c18 in ?? () #9 0x38278818 in pthread_mutex_getprioceiling () from /lib/libthr.so.3 Previous frame identical to this frame (corrupt stack?) (gdb) thread 16 [Switching to thread 16 (Thread 0x8704b00 (LWP 100238))]#0 0x382c578b in _umtx_op () from /lib/libc.so.7 (gdb) bt #0 0x382c578b in _umtx_op () from /lib/libc.so.7 #1 0x3827ce0d in __error () from /lib/libthr.so.3 #2 0x08642140 in ?? () #3 0x00000005 in ?? () #4 0x00000000 in ?? () #5 0x00000000 in ?? () #6 0x00000000 in ?? () #7 0x3827e914 in ?? () from /lib/libthr.so.3 #8 0xbeef3c18 in ?? () #9 0x38278818 in pthread_mutex_getprioceiling () from /lib/libthr.so.3 Previous frame identical to this frame (corrupt stack?) (gdb) thread 17 [Switching to thread 17 (Thread 0x8704a00 (LWP 100237))]#0 0x382c578b in _umtx_op () from /lib/libc.so.7 (gdb) bt #0 0x382c578b in _umtx_op () from /lib/libc.so.7 #1 0x3827ce0d in __error () from /lib/libthr.so.3 #2 0x08642140 in ?? () #3 0x00000005 in ?? () #4 0x00000000 in ?? () #5 0x00000000 in ?? () #6 0x00000000 in ?? () #7 0x3827e914 in ?? () from /lib/libthr.so.3 #8 0xbeff4c18 in ?? () #9 0x38278818 in pthread_mutex_getprioceiling () from /lib/libthr.so.3 Previous frame identical to this frame (corrupt stack?) (gdb) thread 18 [Switching to thread 18 (Thread 0x8704900 (LWP 100236))]#0 0x382c578b in _umtx_op () from /lib/libc.so.7 (gdb) bt #0 0x382c578b in _umtx_op () from /lib/libc.so.7 #1 0x3827ce0d in __error () from /lib/libthr.so.3 #2 0x08642140 in ?? () #3 0x00000005 in ?? () #4 0x00000000 in ?? () #5 0x00000000 in ?? () #6 0x00000000 in ?? () #7 0x3827e914 in ?? () from /lib/libthr.so.3 #8 0xbf0f5c18 in ?? () #9 0x38278818 in pthread_mutex_getprioceiling () from /lib/libthr.so.3 Previous frame identical to this frame (corrupt stack?) (gdb) thread 19 [Switching to thread 19 (Thread 0x8704800 (LWP 100226))]#0 0x382c578b in _umtx_op () from /lib/libc.so.7 (gdb) bt #0 0x382c578b in _umtx_op () from /lib/libc.so.7 #1 0x3827ce0d in __error () from /lib/libthr.so.3 #2 0x08642140 in ?? () #3 0x00000005 in ?? () #4 0x00000000 in ?? () #5 0x00000000 in ?? () #6 0x00000000 in ?? () #7 0x3827e914 in ?? () from /lib/libthr.so.3 #8 0xbf1f6c18 in ?? () #9 0x38278818 in pthread_mutex_getprioceiling () from /lib/libthr.so.3 Previous frame identical to this frame (corrupt stack?) (gdb) thread 20 [Switching to thread 20 (Thread 0x8704700 (LWP 100223))]#0 0x382c578b in _umtx_op () from /lib/libc.so.7 (gdb) bt #0 0x382c578b in _umtx_op () from /lib/libc.so.7 #1 0x3827ce0d in __error () from /lib/libthr.so.3 #2 0x08642140 in ?? () #3 0x00000005 in ?? () #4 0x00000000 in ?? () #5 0x00000000 in ?? () #6 0x00000000 in ?? () #7 0x3827e914 in ?? () from /lib/libthr.so.3 #8 0xbf2f7c18 in ?? () #9 0x38278818 in pthread_mutex_getprioceiling () from /lib/libthr.so.3 Previous frame identical to this frame (corrupt stack?) (gdb) thread 21 [Switching to thread 21 (Thread 0x8704600 (LWP 100222))]#0 0x382c578b in _umtx_op () from /lib/libc.so.7 (gdb) bt #0 0x382c578b in _umtx_op () from /lib/libc.so.7 #1 0x3827ce0d in __error () from /lib/libthr.so.3 #2 0x08642140 in ?? () #3 0x00000005 in ?? () #4 0x00000000 in ?? () #5 0x00000000 in ?? () #6 0x00000000 in ?? () #7 0x3827e914 in ?? () from /lib/libthr.so.3 #8 0xbf3f8c18 in ?? () #9 0x38278818 in pthread_mutex_getprioceiling () from /lib/libthr.so.3 Previous frame identical to this frame (corrupt stack?) (gdb) thread 22 [Switching to thread 22 (Thread 0x8704500 (LWP 100205))]#0 0x382c578b in _umtx_op () from /lib/libc.so.7 (gdb) bt #0 0x382c578b in _umtx_op () from /lib/libc.so.7 #1 0x3827ce0d in __error () from /lib/libthr.so.3 #2 0x08642140 in ?? () #3 0x00000005 in ?? () #4 0x00000000 in ?? () #5 0x00000000 in ?? () #6 0x00000000 in ?? () #7 0x3827e914 in ?? () from /lib/libthr.so.3 #8 0xbf4f9c18 in ?? () #9 0x38278818 in pthread_mutex_getprioceiling () from /lib/libthr.so.3 Previous frame identical to this frame (corrupt stack?) (gdb) thread 23 [Switching to thread 23 (Thread 0x8704400 (LWP 100204))]#0 0x382c578b in _umtx_op () from /lib/libc.so.7 (gdb) bt #0 0x382c578b in _umtx_op () from /lib/libc.so.7 #1 0x3827ce0d in __error () from /lib/libthr.so.3 #2 0x08642140 in ?? () #3 0x00000005 in ?? () #4 0x00000000 in ?? () #5 0x00000000 in ?? () #6 0x00000000 in ?? () #7 0x3827e914 in ?? () from /lib/libthr.so.3 #8 0xbf5fac18 in ?? () #9 0x38278818 in pthread_mutex_getprioceiling () from /lib/libthr.so.3 Previous frame identical to this frame (corrupt stack?) (gdb) thread 24 [Switching to thread 24 (Thread 0x8704300 (LWP 100202))]#0 0x382c578b in _umtx_op () from /lib/libc.so.7 (gdb) bt #0 0x382c578b in _umtx_op () from /lib/libc.so.7 #1 0x3827ce0d in __error () from /lib/libthr.so.3 #2 0x08642140 in ?? () #3 0x00000005 in ?? () #4 0x00000000 in ?? () #5 0x00000000 in ?? () #6 0x00000000 in ?? () #7 0x3827e914 in ?? () from /lib/libthr.so.3 #8 0xbf6fbb68 in ?? () #9 0x38278818 in pthread_mutex_getprioceiling () from /lib/libthr.so.3 Previous frame identical to this frame (corrupt stack?) (gdb) thread 25 [Switching to thread 25 (Thread 0x8704200 (LWP 100192))]#0 0x382c578b in _umtx_op () from /lib/libc.so.7 (gdb) bt #0 0x382c578b in _umtx_op () from /lib/libc.so.7 #1 0x3827ce0d in __error () from /lib/libthr.so.3 #2 0x08642140 in ?? () #3 0x00000005 in ?? () #4 0x00000000 in ?? () #5 0x00000000 in ?? () #6 0x00000000 in ?? () #7 0x3827e914 in ?? () from /lib/libthr.so.3 #8 0xbf7fcc18 in ?? () #9 0x38278818 in pthread_mutex_getprioceiling () from /lib/libthr.so.3 Previous frame identical to this frame (corrupt stack?) (gdb) thread 26 [Switching to thread 26 (Thread 0x8704100 (LWP 100190))]#0 0x382c578b in _umtx_op () from /lib/libc.so.7 (gdb) bt #0 0x382c578b in _umtx_op () from /lib/libc.so.7 #1 0x3827ce0d in __error () from /lib/libthr.so.3 #2 0x08642140 in ?? () #3 0x00000005 in ?? () #4 0x00000000 in ?? () #5 0x00000000 in ?? () #6 0x00000000 in ?? () #7 0x3827e914 in ?? () from /lib/libthr.so.3 #8 0xbf8fdc18 in ?? () #9 0x38278818 in pthread_mutex_getprioceiling () from /lib/libthr.so.3 Previous frame identical to this frame (corrupt stack?) (gdb) thread 27 [Switching to thread 27 (Thread 0x8102100 (LWP 100390))]#0 0x3835c6a3 in read () from /lib/libc.so.7 (gdb) bt #0 0x3835c6a3 in read () from /lib/libc.so.7 #1 0x382736e2 in read () from /lib/libthr.so.3 #2 0x08095944 in ap_mpm_pod_check (pod=0x8289f18) at pod.c:54 #3 0x080932ab in child_main (child_num_arg=0) at worker.c:1258 #4 0x0809345e in make_child (s=0x8110f10, slot=0) at worker.c:1341 #5 0x08093981 in perform_idle_server_maintenance () at worker.c:1543 #6 0x08093bb8 in server_main_loop (remaining_children_to_start=0) at worker.c:1646 #7 0x08093f14 in ap_mpm_run (_pconf=0x810f018, plog=0x813d018, s=0x8110f10) at worker.c:1748 #8 0x08064289 in main (argc=Error accessing memory address 0x0: Bad address. ) at main.c:730 (gdb) The program is running. Quit anyway (and detach it)? (y or n) y Detaching from program: /usr/local/sbin/httpd, process 51845 From owner-freebsd-stable@FreeBSD.ORG Wed Aug 13 11:26:02 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DE84C1065675 for ; Wed, 13 Aug 2008 11:26:02 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id 563028FC0A for ; Wed, 13 Aug 2008 11:26:02 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (ppp121-45-88-193.lns10.adl6.internode.on.net [121.45.88.193]) (authenticated bits=0) by cain.gsoft.com.au (8.13.8/8.13.8) with ESMTP id m7DBPxsH073828 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 13 Aug 2008 20:55:59 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: "Manjunath Ranganathaiah" Date: Wed, 13 Aug 2008 20:55:43 +0930 User-Agent: KMail/1.9.7 References: <200808121734.30144.doconnor@gsoft.com.au> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1471918.rZr3fxPlrO"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200808132055.56039.doconnor@gsoft.com.au> X-Spam-Score: -2.212 () BAYES_00,RDNS_DYNAMIC X-Scanned-By: MIMEDefang 2.63 on 203.31.81.10 Cc: freebsd-stable@freebsd.org Subject: Re: 6.3 (ish) hang on reboot w/ Supermicro C2SBA+ X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2008 11:26:02 -0000 --nextPart1471918.rZr3fxPlrO Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wed, 13 Aug 2008, Manjunath Ranganathaiah wrote: > can you try with debug.acpi.disabled=3D"cpu timer" ? or booting with > acpi disabled I tried the former (put it in loader.conf right?) and it made no=20 difference. I'll try disabling ACPI tomorrow (I tried it remotely so=20 it's hung now :) =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart1471918.rZr3fxPlrO Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iD8DBQBIosTD5ZPcIHs/zowRAuHAAJ4tg8tgFo52JsLcJo9ZSm321UIiFgCeOdft fIgfvE+2Neo3Sc3EYso6h+c= =ca1t -----END PGP SIGNATURE----- --nextPart1471918.rZr3fxPlrO-- From owner-freebsd-stable@FreeBSD.ORG Wed Aug 13 13:10:48 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D0952106567A for ; Wed, 13 Aug 2008 13:10:48 +0000 (UTC) (envelope-from sebster@sebster.com) Received: from mail.servoy.com (mail.servoy.com [87.233.173.130]) by mx1.freebsd.org (Postfix) with SMTP id 14C418FC3C for ; Wed, 13 Aug 2008 13:10:47 +0000 (UTC) (envelope-from sebster@sebster.com) Received: (qmail 87287 invoked from network); 13 Aug 2008 13:10:47 -0000 Received: from unknown (HELO ?10.1.0.6?) (sebster@85.147.225.232) by mail.servoy.com with SMTP; 13 Aug 2008 13:10:46 -0000 Message-ID: <48A2DD60.7090702@sebster.com> Date: Wed, 13 Aug 2008 15:10:56 +0200 From: Sebastiaan van Erk User-Agent: Thunderbird 2.0.0.16 (X11/20080724) MIME-Version: 1.0 To: Jeremy Chadwick References: <48982B58.4000406@sebster.com> <48992532.9080503@yandex.ru> <489970CC.4000103@sebster.com> <20080806095748.GA52551@eos.sc1.parodius.com> <20080806101941.GA52952@eos.sc1.parodius.com> In-Reply-To: <20080806101941.GA52952@eos.sc1.parodius.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020804090908070702060709" Cc: freebsd-stable@freebsd.org Subject: Re: Stable SATA pci card for FreeBSD 6.x/7.0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2008 13:10:48 -0000 This is a cryptographically signed message in MIME format. --------------ms020804090908070702060709 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, Just an update on this issue. Quick summary: I fixed the BIOS issues, the hardware monitor issues, and the rl0/rl1 watchdog timeout issues (it seems). However I'm still having problems with my SATA drives (or at least one of them). More info below. BIOS: I flashed my BIOS to the latest version about a year ago, and never noticed that there was any problem, but it turns out there was. I never reset the BIOS to default factory settings after the upgrade, and it seems the settings were corrupt. After having reset the BIOS to the "default optimized factory settings" it stopped crashing when I go into the H/W monitor and also when using healthd -d (output below): Temp.= 40.0, 36.0, 66.0; Rot.= 0, 0, 0 Vcore = 1.44, 3.12; Volt. = 3.34, 5.00, 1.95, -0.11, -1.54 Temp.= 40.0, 36.0, 66.0; Rot.= 0, 0, 0 Vcore = 1.44, 3.14; Volt. = 3.33, 4.97, 1.95, -0.11, -1.54 Temp.= 40.0, 36.0, 66.0; Rot.= 0, 0, 0 Vcore = 1.44, 3.12; Volt. = 3.34, 4.97, 1.95, -0.11, -1.54 Temp.= 40.0, 36.0, 66.0; Rot.= 0, 0, 0 Vcore = 1.44, 3.12; Volt. = 3.34, 5.00, 1.95, -0.11, -1.54 Temp.= 40.0, 36.0, 66.0; Rot.= 0, 0, 0 Vcore = 1.44, 3.12; Volt. = 3.34, 5.00, 1.95, -0.11, -1.54 This also seems to have fixed the rl0 watchdog timeout problems. I no longer see those in my logs. SATA DRIVES: I'm still having problems with the SATA drives. I tried connecting the 1TB Samsung drives to my mainboard, but then the box hangs when booting with the "Detecting IDE drives" message. The regular (PATA) IDE drives are detected first, and then it repeats the "Detecting IDE drives" message to detect the sata drives, and hangs. When I connect my 250GB SATA drives to my mainboard they detect fine, and the box boots normally. I did another rsync of my old mirror (the 250GB disks) to the new mirror (1TB disks), but again one of the disks got detached. This time there are no other messages in the log, the only thing I see is the following: Aug 13 14:35:27 piglet su: sebster to root on /dev/ttyp5 Aug 13 14:55:38 piglet kernel: ad6: FAILURE - device detached Aug 13 14:55:38 piglet kernel: subdisk6: detached Aug 13 14:55:38 piglet kernel: ad6: detached Aug 13 14:55:38 piglet kernel: GEOM_MIRROR: Device gm1: provider ad6 disconnected. Aug 13 15:00:00 piglet newsyslog[1800]: logfile turned over due to size>100K (unfortunate that the log file just got rotated, but in the new log file there is nothing execpt the one expected line: Aug 13 15:00:00 piglet newsyslog[1800]: logfile turned over due to size>100K So, nothing after the disconnect... The questions I have now is: 1) Could an upgrade to FreeBSD 7-STABLE fix the issue (it's a LOT of work for me, but I'll do it if there are SATA driver issues fixed). 2) What is the next step? Should I repeat the tests to see if it's always the same drive that disconnects? 3) Is there any way to get more info about what is causing the disconnect? Regards, Sebastiaan Jeremy Chadwick wrote: > On Wed, Aug 06, 2008 at 02:57:48AM -0700, Jeremy Chadwick wrote: >> vmstat -i output should help clear that up, or dmesg output. > > Sebastiaan has included vmstat -i output in another part of this thread, > as well as dmesg output for the ATA disks and controllers: > > atapci0: port 0xd200-0xd207,0xd300-0xd303,0xd400-0xd407,0xd500-0xd503,0xd600-0xd60f mem 0xf6081000-0xf60811ff irq 18 at device 10.0 on pci0 > ata2: on atapci0 > ata3: on atapci0 > atapci1: port 0xd700-0xd707,0xd800-0xd803,0xd900-0xd907,0xda00-0xda03,0xdb00-0xdb0f,0xdc00-0xdcff irq 20 at device 15.0 on pci0 > ata4: on atapci1 > ata5: on atapci1 > atapci2: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xdd00-0xdd0f at device 15.1 on pci0 > ata0: on atapci2 > ata1: on atapci2 > ad0: 286188MB at ata0-master UDMA133 > ad1: 239372MB at ata0-slave UDMA133 > acd0: DVDR at ata1-master UDMA33 > ad4: 953869MB at ata2-master SATA150 > ad6: 953869MB at ata3-master SATA150 > ad8: 239372MB at ata4-master SATA150 > ad10: 239372MB at ata5-master SATA150 > > interrupt total rate > irq6: fdc0 10 0 > irq14: ata0 645057 7 > irq15: ata1 58 0 > irq16: rl0 7168276 82 > irq17: rl1 914667 10 > irq18: atapci0 30072876 347 > irq20: atapci1 1126099 12 > irq21: uhci0 uhci* 308 0 > irq23: vr0 3265771 37 > cpu0: timer 173289011 1999 > Total 216482133 2498 > > Here's a breakdown, so no one gets confused: > > ad0 = 300GB Maxtor disk, attached to on-board VIA IDE controller > ad1 = 250GB Maxtor disk, attached to on-board VIA IDE controller > ad4 = 1TB Samsung disk, attached to Silicon Image SATA controller > ad6 = 1TB Samsung disk, attached to Silicon Image SATA controller > ad8 = 250GB Maxtor disk, attached to on-board VIA SATA controller > ad10 = 250GB Maxtor disk, attached to on-board VIA SATA controller > > IRQ 14 -- atapci2 = On-board VIA IDE controller (primary) > IRQ 15 -- atapci2 = On-board VIA IDE controller (slave) > IRQ 16 -- rl0 = Realtek NIC > IRQ 17 -- rl1 = Realtek NIC > IRQ 18 -- atapci0 = Silicon Image SATA controller > IRQ 20 -- atapci1 = On-board VIA SATA controller > > An APIC is obviously in use here. > > The problem reported is with disks ad4 and ad6, residing on the Silicon > Image controller. When the problem happens, rl1 emits watchdog > timeouts, and disks ad4 and ad6 fall off the bus. > > SMART statistics on both ad4 and ad6 show no signs of the disks being > power-cycled, sector errors, or anything that would indicate either disk > is bad. > > His PSU is 450W, brand unknown. > > Sebastiaan, do you know if the BIOS on this system has a Health monitor, > showing voltages and temperatures of things? If so, can you reboot the > system, go into that part of the BIOS, and write down (or take a photo) > of the voltages/temperatures? > > I'm wondering if maybe one of the voltages is too low or high, or > fluxuates severely with so many devices. It could be enough to cause > some of the ASICs to malfunction, possibly multiples... > > I cleared the possibility of this being a PSU problem, but that was > before I knew you were seeing watchdog timeouts on one of your NICs at > the *exact same time* as disks off the Silicon Image controller. > --------------ms020804090908070702060709 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJUTCC AwMwggJsoAMCAQICEFN8DarMNuuKJDEtfs0UaqUwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDYzMDEzNTE1N1oX DTA5MDYzMDEzNTE1N1owaDEQMA4GA1UEBBMHdmFuIEVyazETMBEGA1UEKhMKU2ViYXN0aWFh bjEbMBkGA1UEAxMSU2ViYXN0aWFhbiB2YW4gRXJrMSIwIAYJKoZIhvcNAQkBFhNzZWJzdGVy QHNlYnN0ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsJDDAeYHVmH/ GVxi+bhFx27dmg++9BdhPJfk8k041sqEqq7oXnR2GT54quY3Ac7A1BuOM2JvoICraGmjud4y b3EanRnqGIK6iH+VAhhTlV/Owrb2Qm1e13DLxwLp1SocSQl4IrEbF9Y5H3ASdIrE0iFqkpju nPiiHeNhz3LaI5ipjiluKYoH+F6gPx8njHoaDxPePCkSLg4r0IA0afLM74LVZxCRBZEfyRZS J6VVUJefKlz91dWSzR/3xSw/rO4u9Ds/Zh7VBUKy3K+YFryHxRpUek0gSepE1b70Q39L9Sqd M/NZqMvFpwrqgW2Zh2Nh8nqRge90maR4ypBzz3GzLwIDAQABozAwLjAeBgNVHREEFzAVgRNz ZWJzdGVyQHNlYnN0ZXIuY29tMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEFBQADgYEAS1Sk NMgDVzb0ktO9tPPacV0KdKhTYOHcICVmuDEe2sFHOkjLAI1iAKp640pqJEVqvRnfRcCFJ9hK koPjjVZ+ui2rVmJWBG6FSloLRS/YYED4tUAw6DQhK61UOpjkpQxjCdm+5bHG/2ZgJAda1j0x uiN822+xFkcaW/5PQgxSRxcwggMDMIICbKADAgECAhBTfA2qzDbriiQxLX7NFGqlMA0GCSqG SIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QTAeFw0wODA2MzAxMzUxNTdaFw0wOTA2MzAxMzUxNTdaMGgxEDAOBgNVBAQTB3ZhbiBFcmsx EzARBgNVBCoTClNlYmFzdGlhYW4xGzAZBgNVBAMTElNlYmFzdGlhYW4gdmFuIEVyazEiMCAG CSqGSIb3DQEJARYTc2Vic3RlckBzZWJzdGVyLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBALCQwwHmB1Zh/xlcYvm4Rcdu3ZoPvvQXYTyX5PJNONbKhKqu6F50dhk+eKrm NwHOwNQbjjNib6CAq2hpo7neMm9xGp0Z6hiCuoh/lQIYU5VfzsK29kJtXtdwy8cC6dUqHEkJ eCKxGxfWOR9wEnSKxNIhapKY7pz4oh3jYc9y2iOYqY4pbimKB/heoD8fJ4x6Gg8T3jwpEi4O K9CANGnyzO+C1WcQkQWRH8kWUielVVCXnypc/dXVks0f98UsP6zuLvQ7P2Ye1QVCstyvmBa8 h8UaVHpNIEnqRNW+9EN/S/UqnTPzWajLxacK6oFtmYdjYfJ6kYHvdJmkeMqQc89xsy8CAwEA AaMwMC4wHgYDVR0RBBcwFYETc2Vic3RlckBzZWJzdGVyLmNvbTAMBgNVHRMBAf8EAjAAMA0G CSqGSIb3DQEBBQUAA4GBAEtUpDTIA1c29JLTvbTz2nFdCnSoU2Dh3CAlZrgxHtrBRzpIywCN YgCqeuNKaiRFar0Z30XAhSfYSpKD441Wfrotq1ZiVgRuhUpaC0Uv2GBA+LVAMOg0ISutVDqY 5KUMYwnZvuWxxv9mYCQHWtY9MbojfNtvsRZHGlv+T0IMUkcXMIIDPzCCAqigAwIBAgIBDTAN BgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTES MBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UE CxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0 aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GN ADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAK MNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTX p6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYB Af8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBl cnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYD VQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2as Zw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSe JVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHT HUb/XV9lTzGCA2QwggNgAgEBMHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBD b25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBJc3N1aW5nIENBAhBTfA2qzDbriiQxLX7NFGqlMAkGBSsOAwIaBQCgggHDMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA4MDgxMzEzMTA1NlowIwYJKoZI hvcNAQkEMRYEFD/4HkoNK6KjyVNVhoJMdy4yaTSqMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3 DQMCAgEoMIGFBgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3 dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQQIQU3wNqsw264okMS1+zRRqpTCBhwYLKoZIhvcNAQkQAgsxeKB2 MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQu MSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQU3wNqsw2 64okMS1+zRRqpTANBgkqhkiG9w0BAQEFAASCAQCpY5tLtUY+Sg7ZQ9NEHylrcH4TgaDtariD v++aMg8UJ0yM/4UV3lMcFZ4GaQvabkQdSo3g7FlRjtyYVYmzmqz5t5lDROUQAoqVgstJq0jG G5MZisAGB7sI4VavGJwzLFLt4MJjllrHNooaIqxsteBorXR2kcsDwgE91sBCkxdaI8VZTMyt QVIAFOVP+u680Pz4Qjcrxxs2L3trK+i3WPB2teLaXV/Hfvn+0Eyhf18LDVq6NKmaKqYKpw/U mcuytmMm+VBXOYG7fM+28DzRM9Wr7Q8T87+mWUAjVXaluRWZPvTTPom+R8OiICxOfR1KrJZF JvWa5OA6rHmUjYtIx5RcAAAAAAAA --------------ms020804090908070702060709-- From owner-freebsd-stable@FreeBSD.ORG Wed Aug 13 13:18:48 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AF7AB1065676; Wed, 13 Aug 2008 13:18:48 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 5FFCA8FC18; Wed, 13 Aug 2008 13:18:46 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <48A2DF31.4050907@FreeBSD.org> Date: Wed, 13 Aug 2008 15:18:41 +0200 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: Borja Marcos References: <43EC06E9-76B3-4AA1-BC5E-4E1BD64AFC2D@SARENET.ES> <0296197A-28ED-4DAA-A31F-C28471E864FB@SARENET.ES> <20080812102856.GA6735@eos.sc1.parodius.com> <659A017B-5D6F-4B74-A85D-4A9A040CA442@SARENET.ES> In-Reply-To: <659A017B-5D6F-4B74-A85D-4A9A040CA442@SARENET.ES> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Jeremy Chadwick , freebsd-stable@freebsd.org, Ivan Voras Subject: Re: umtxn and Apache 2.2 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2008 13:18:48 -0000 Borja Marcos wrote: > ((Sorry for the long dump)) > (gdb) bt > #0 0x3827cfe7 in __error () from /lib/libthr.so.3 > #1 0x3827cd4a in __error () from /lib/libthr.so.3 > #2 0x08702120 in ?? () As you can see the debugging symbols are still not available. Refer to the developers handbook if you need more assistance doing this. Also, it is worth carefully checking your php configuration. For example, php is notoriously sensitive to the order in which modules are defined, and will crash or misbehave without giving any other warnings if you don't meet its expectations. That may or may not be relevant in your situation. Kris From owner-freebsd-stable@FreeBSD.ORG Wed Aug 13 13:28:31 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 20F2B106567E; Wed, 13 Aug 2008 13:28:31 +0000 (UTC) (envelope-from BORJAMAR@SARENET.ES) Received: from proxypop2.sarenet.es (proxypop2.sarenet.es [194.30.0.95]) by mx1.freebsd.org (Postfix) with ESMTP id D7E288FC26; Wed, 13 Aug 2008 13:28:30 +0000 (UTC) (envelope-from BORJAMAR@SARENET.ES) Received: from [127.0.0.1] (matahari.sarenet.es [192.148.167.18]) by proxypop2.sarenet.es (Postfix) with ESMTP id 8FA13730F0; Wed, 13 Aug 2008 15:28:26 +0200 (CEST) Message-Id: From: Borja Marcos To: Kris Kennaway In-Reply-To: <48A2DF31.4050907@FreeBSD.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v928.1) Date: Wed, 13 Aug 2008 15:28:43 +0200 References: <43EC06E9-76B3-4AA1-BC5E-4E1BD64AFC2D@SARENET.ES> <0296197A-28ED-4DAA-A31F-C28471E864FB@SARENET.ES> <20080812102856.GA6735@eos.sc1.parodius.com> <659A017B-5D6F-4B74-A85D-4A9A040CA442@SARENET.ES> <48A2DF31.4050907@FreeBSD.org> X-Mailer: Apple Mail (2.928.1) Cc: Jeremy Chadwick , freebsd-stable@freebsd.org, Ivan Voras Subject: Re: umtxn and Apache 2.2 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2008 13:28:31 -0000 On Aug 13, 2008, at 3:18 PM, Kris Kennaway wrote: > Borja Marcos wrote: >> ((Sorry for the long dump)) >> (gdb) bt >> #0 0x3827cfe7 in __error () from /lib/libthr.so.3 >> #1 0x3827cd4a in __error () from /lib/libthr.so.3 >> #2 0x08702120 in ?? () > > As you can see the debugging symbols are still not available. Refer > to the developers handbook if you need more assistance doing this. Hmm. Weird. I compiled the port having WITH_DEBUG defined (as I saw in the Makefile) and indeed the gcc invocations has the -g flag set. What is strange is the error gdb issued, offering a coredump, etc. > Also, it is worth carefully checking your php configuration. For > example, php is notoriously sensitive to the order in which modules > are defined, and will crash or misbehave without giving any other > warnings if you don't meet its expectations. That may or may not be > relevant in your situation. Just in case I didn't change the order of the modules. I'll keep looking at it. Borja. From owner-freebsd-stable@FreeBSD.ORG Wed Aug 13 13:33:40 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BD2E71065676; Wed, 13 Aug 2008 13:33:40 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 106388FC0C; Wed, 13 Aug 2008 13:33:37 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <48A2E2AD.8060607@FreeBSD.org> Date: Wed, 13 Aug 2008 15:33:33 +0200 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: Borja Marcos References: <43EC06E9-76B3-4AA1-BC5E-4E1BD64AFC2D@SARENET.ES> <0296197A-28ED-4DAA-A31F-C28471E864FB@SARENET.ES> <20080812102856.GA6735@eos.sc1.parodius.com> <659A017B-5D6F-4B74-A85D-4A9A040CA442@SARENET.ES> <48A2DF31.4050907@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Jeremy Chadwick , freebsd-stable@freebsd.org, Ivan Voras Subject: Re: umtxn and Apache 2.2 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2008 13:33:40 -0000 Borja Marcos wrote: > > On Aug 13, 2008, at 3:18 PM, Kris Kennaway wrote: > >> Borja Marcos wrote: >>> ((Sorry for the long dump)) >>> (gdb) bt >>> #0 0x3827cfe7 in __error () from /lib/libthr.so.3 >>> #1 0x3827cd4a in __error () from /lib/libthr.so.3 >>> #2 0x08702120 in ?? () >> >> As you can see the debugging symbols are still not available. Refer >> to the developers handbook if you need more assistance doing this. > > Hmm. Weird. I compiled the port having WITH_DEBUG defined (as I saw in > the Makefile) and indeed the gcc invocations has the -g flag set. What > is strange is the error gdb issued, offering a coredump, etc. It is likely that the binaries are stripped on install then. You can try to run gdb against the compiled versions in the port work/ directory. >> Also, it is worth carefully checking your php configuration. For >> example, php is notoriously sensitive to the order in which modules >> are defined, and will crash or misbehave without giving any other >> warnings if you don't meet its expectations. That may or may not be >> relevant in your situation. > > Just in case I didn't change the order of the modules. I'll keep looking > at it. This could be why :) Some people report that previously working configurations stopped working after an upgrade until the ordering was changed. Kris From owner-freebsd-stable@FreeBSD.ORG Wed Aug 13 13:42:19 2008 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6F7931065684; Wed, 13 Aug 2008 13:42:19 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (skuns.zoral.com.ua [91.193.166.194]) by mx1.freebsd.org (Postfix) with ESMTP id 2D85A8FC25; Wed, 13 Aug 2008 13:42:17 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m7DDgAjI072280 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Aug 2008 16:42:10 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m7DDgA1J047986; Wed, 13 Aug 2008 16:42:10 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2/Submit) id m7DDgAIs047985; Wed, 13 Aug 2008 16:42:10 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 13 Aug 2008 16:42:10 +0300 From: Kostik Belousov To: amd64@freebsd.org, stable@freebsd.org Message-ID: <20080813134210.GG1803@deviant.kiev.zoral.com.ua> References: <200808130022.m7D0MCaK082721@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="nhYGnrYv1PEJ5gA2" Content-Disposition: inline In-Reply-To: <200808130022.m7D0MCaK082721@freefall.freebsd.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: peter@freebsd.org Subject: Re: Pending MFC Reminder [cvs commit: src/sys/amd64/amd64 cpu_switch.S genassym.c src/sys/amd64/ia32 ia32_signal.c src/sys/amd64/include pcb.h src/sys/amd64/linux32 linux32_machdep.c] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2008 13:42:19 -0000 --nhYGnrYv1PEJ5gA2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 13, 2008 at 12:22:12AM +0000, MFC Notification Service wrote: > Dear Konstantin Belousov, >=20 > As you have requested, I would like to notify you that you have > committed a change that may be MFC'ed now, as a testing period > specified at the time of that commit is over. >=20 > For reference purposes following is a copy of your original > commit message. >=20 > Regards, >=20 > Maxim "MFC Reminder" Sobolev > P.S. Please contact Maxim Sobolev if you > believe that you received this message due to an error. >=20 > kib 2008-07-30 11:30:55 UTC >=20 > FreeBSD src repository >=20 > Modified files: > sys/amd64/amd64 cpu_switch.S genassym.c=20 > sys/amd64/ia32 ia32_signal.c=20 > sys/amd64/include pcb.h=20 > sys/amd64/linux32 linux32_machdep.c=20 > Log: > SVN rev 180992 on 2008-07-30 11:30:55Z by kib > =20 > Bring back the save/restore of the %ds, %es, %fs and %gs registers for > the 32bit images on amd64. > =20 > Change the semantic of the PCB_32BIT pcb flag to request the context > switch code to operate on the segment registers. Its previous meaning > of saving or restoring the %gs base offset is assigned to the new > PCB_GS32BIT flag. > =20 > FreeBSD 32bit image activator sets the PCB_32BIT flag, while Linux 32bit > emulation sets PCB_32BIT | PCB_GS32BIT. > =20 > Reviewed by: peter > MFC after: 2 weeks > =20 > Revision Changes Path > 1.162 +29 -18 src/sys/amd64/amd64/cpu_switch.S > 1.169 +1 -0 src/sys/amd64/amd64/genassym.c > 1.18 +1 -1 src/sys/amd64/ia32/ia32_signal.c > 1.65 +1 -0 src/sys/amd64/include/pcb.h > 1.47 +1 -1 src/sys/amd64/linux32/linux32_machdep.c This appeared to be a not quite trivial MFC to perform. The reason for complication is that the HEAD code for amd64 context switch was changed, in particular by the r177535 by peter@. The r177535 formally requires r177533 for the definition of the TDP_KTHREAD symbol for asm. The definition is needed for optimization of the context switch to the "pure kernel thread", introduced in r173004 that is not MFCed either, and possibly never be. I do not want to backport the code to the old context switch, that would mean a rewrite from scratch. Instead, I merged the r177535 (optimization of context switch by peter@), and commented out corresponding test in the cpu_switch.S for the TDP_KTHREAD. I would be glad to get an opinions on the approach taken, and especially for the wider testing on the RELENG_7/amd64. The problem better be solved for 7.1. The patch: http://people.freebsd.org/~kib/misc/amd64_ctx.releng_7.4.patch --nhYGnrYv1PEJ5gA2 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkii5LEACgkQC3+MBN1Mb4gbPQCfYKTAF9jBX5BHrdZe65HL9gSV Zm8AoJfu5kJDSYWG0vv/TH6aIty/1N4C =9zso -----END PGP SIGNATURE----- --nhYGnrYv1PEJ5gA2-- From owner-freebsd-stable@FreeBSD.ORG Wed Aug 13 14:56:15 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3EA34106566C; Wed, 13 Aug 2008 14:56:15 +0000 (UTC) (envelope-from BORJAMAR@SARENET.ES) Received: from proxypop2.sarenet.es (proxypop2.sarenet.es [194.30.0.95]) by mx1.freebsd.org (Postfix) with ESMTP id DBC308FC20; Wed, 13 Aug 2008 14:56:14 +0000 (UTC) (envelope-from BORJAMAR@SARENET.ES) Received: from [127.0.0.1] (matahari.sarenet.es [192.148.167.18]) by proxypop2.sarenet.es (Postfix) with ESMTP id 2687673126; Wed, 13 Aug 2008 16:56:11 +0200 (CEST) Message-Id: <0545482D-1E3F-4615-B3EB-04ABB838FF71@SARENET.ES> From: Borja Marcos To: Kris Kennaway In-Reply-To: <48A2E2AD.8060607@FreeBSD.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v928.1) Date: Wed, 13 Aug 2008 16:56:28 +0200 References: <43EC06E9-76B3-4AA1-BC5E-4E1BD64AFC2D@SARENET.ES> <0296197A-28ED-4DAA-A31F-C28471E864FB@SARENET.ES> <20080812102856.GA6735@eos.sc1.parodius.com> <659A017B-5D6F-4B74-A85D-4A9A040CA442@SARENET.ES> <48A2DF31.4050907@FreeBSD.org> <48A2E2AD.8060607@FreeBSD.org> X-Mailer: Apple Mail (2.928.1) Cc: Jeremy Chadwick , freebsd-stable@freebsd.org, Ivan Voras Subject: Re: umtxn and Apache 2.2 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2008 14:56:15 -0000 On Aug 13, 2008, at 3:33 PM, Kris Kennaway wrote: >> Hmm. Weird. I compiled the port having WITH_DEBUG defined (as I saw >> in the Makefile) and indeed the gcc invocations has the -g flag >> set. What is strange is the error gdb issued, offering a coredump, >> etc. > > It is likely that the binaries are stripped on install then. You > can try to run gdb against the compiled versions in the port work/ > directory. Doesn't seem stripped to me... %file /usr/local/sbin/httpd /usr/local/sbin/httpd: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), for FreeBSD 7.0 (700110), dynamically linked (uses shared libs), FreeBSD-style, not stripped %gdb /usr/local/sbin/httpd GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd"... (gdb) r Starting program: /usr/local/sbin/httpd [New LWP 100152] [New Thread 0x8102100 (LWP 100152)] (48)Address already in use: make_sock: could not bind to address 0.0.0.0:80 no listening sockets available, shutting down Unable to open logs Program exited with code 01. Any know bug affecting gdb on FreeBSD 7-STABLE/i386? "devilator" is mine, it's indeed compiled in debug mode, and gdb has problems to attach to it. It does it, but complains offering a core dump as well :/ %ps ax|fgrep devila 44336 p0- S 1:11.79 /usr/local/bin/devilator 67511 p0 R+ 0:00.00 fgrep devila %cd ~borjam/src/devilator-1.0a2/ %gdb -p 44336 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd". Attaching to process 44336 /usr/src/gnu/usr.bin/gdb/libgdb/../../../../contrib/gdb/gdb/solib- svr4.c:1443: internal-error: legacy_fetch_link_map_offsets called without legacy link_map support enabled. A problem internal to GDB has been detected, further debugging may prove unreliable. Quit this debugging session? (y or n) n /usr/src/gnu/usr.bin/gdb/libgdb/../../../../contrib/gdb/gdb/solib- svr4.c:1443: internal-error: legacy_fetch_link_map_offsets called without legacy link_map support enabled. A problem internal to GDB has been detected, further debugging may prove unreliable. Create a core file of GDB? (y or n) n Reading symbols from /usr/local/bin/devilator...done. Reading symbols from /lib/libkvm.so.4...done. Loaded symbols for /lib/libkvm.so.4 Reading symbols from /lib/libgeom.so.4...done. Loaded symbols for /lib/libgeom.so.4 Reading symbols from /lib/libdevstat.so.6...done. Loaded symbols for /lib/libdevstat.so.6 Reading symbols from /lib/libc.so.7...done. Loaded symbols for /lib/libc.so.7 Reading symbols from /lib/libbsdxml.so.3...done. Loaded symbols for /lib/libbsdxml.so.3 Reading symbols from /lib/libsbuf.so.4...done. Loaded symbols for /lib/libsbuf.so.4 Reading symbols from /libexec/ld-elf.so.1...done. Loaded symbols for /libexec/ld-elf.so.1 0x381510af in nanosleep () from /lib/libc.so.7 (gdb) bt #0 0x381510af in nanosleep () from /lib/libc.so.7 #1 0x3811f40a in sleep () from /lib/libc.so.7 #2 0x08048f4b in main () at devilator.c:47 (gdb) The program is running. Quit anyway (and detach it)? (y or n) y Detaching from program: /usr/local/bin/devilator, process 44336 >>> >>> Also, it is worth carefully checking your php configuration. For >>> example, php is notoriously sensitive to the order in which >>> modules are defined, and will crash or misbehave without giving >>> any other warnings if you don't meet its expectations. That may >>> or may not be relevant in your situation. >> Just in case I didn't change the order of the modules. I'll keep >> looking at it. > > This could be why :) Some people report that previously working > configurations stopped working after an upgrade until the ordering > was changed. Hmm. I see, I will check then. Thank you, Borja. From owner-freebsd-stable@FreeBSD.ORG Wed Aug 13 15:22:38 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4599E1065675 for ; Wed, 13 Aug 2008 15:22:38 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.234]) by mx1.freebsd.org (Postfix) with ESMTP id 031968FC14 for ; Wed, 13 Aug 2008 15:22:37 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by wx-out-0506.google.com with SMTP id h27so23996wxd.7 for ; Wed, 13 Aug 2008 08:22:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=P3nGh8VXDkrlrGIdw1TI3Ay6vVQU21ltHp+RYds41WA=; b=D4uCXDnFQm5N426ukhM9urTpjCvwEjiO5dvsYnDLUGFKdVJi0zudt3t8L5KGXYrWZE CLA7SPbRP5+zuzcpMXHpL38CqEpyucQ+SSKAzdk0YbRptYO0xJ2/uky1dPgdP7qUzHPA 8QdpxM74CwgYXR85G/+MTf5jZ8JpOXEKTOvY8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=Nii2Q5iCh0bml51YFZ2bsKxarkmeuqPbZsQU+nhzSBlyqtBofHCHyN/TwXREA1aVlD 6EfWGJxD7YgyuoFDUNiiJmB9Mlhm/c7PsFhXAoQGwx1X/TVfsfJF9X/uJKlhZp5w8C6j puEznb2UcFmA5T2d8X77t4m/eUeVS/99dOITs= Received: by 10.90.84.2 with SMTP id h2mr33855agb.10.1218640956427; Wed, 13 Aug 2008 08:22:36 -0700 (PDT) Received: by 10.100.43.1 with HTTP; Wed, 13 Aug 2008 08:22:36 -0700 (PDT) Message-ID: <2a41acea0808130822i5f336b1ci15099f27a3a7c13d@mail.gmail.com> Date: Wed, 13 Aug 2008 08:22:36 -0700 From: "Jack Vogel" To: "Markus Vervier" In-Reply-To: <48A2B1CB.7060303@vervier.info> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <489C4129.4090303@vervier.info> <489C88DB.6030000@vervier.info> <2a41acea0808081131m1eddc4caib0963c8a5443afd2@mail.gmail.com> <200808110819.53914.josh@tcbug.org> <20080811140249.GA27379@eos.sc1.parodius.com> <2a41acea0808110928h10d54441o7d49b11a60406934@mail.gmail.com> <48A0A1D9.8030601@vervier.info> <2a41acea0808111340o7b506804u9e4c95f1af22b95c@mail.gmail.com> <48A2B1CB.7060303@vervier.info> Cc: freebsd-stable@freebsd.org Subject: Re: em(4) on FreeBSD is sometimes annoying X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2008 15:22:38 -0000 On Wed, Aug 13, 2008 at 3:04 AM, Markus Vervier wrote: > Jack Vogel wrote: >> >> I didn't mean the NIC EEPROM, but the system BIOS, make sure you are >> running the version that Jeremy said he was, if that matches you might go >> look at settings in the BIOS that are about management. >> > I'm now running the latest BIOS for my X60 version 2.22 with the same > results. Jeremy runs version 1.15 but on a T60. >> >> I thought you told us that when you had a back to back connection that it >> worked, no?? > > Sorry, it does not work when having a b2b connection, never said that. But I > noticed another thing: > > It is important that the device was up without a cable connected: > > 1. power off completely > 2. boot freebsd without a cable connected > 3. in a rootshell do ifconfig em0 up > 4. connect the cable > 5. no link Hmmm, well let me see if I can get ahold of an X60. Jack From owner-freebsd-stable@FreeBSD.ORG Wed Aug 13 15:50:34 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A54341065677 for ; Wed, 13 Aug 2008 15:50:34 +0000 (UTC) (envelope-from tevans.uk@googlemail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.189]) by mx1.freebsd.org (Postfix) with ESMTP id 38B7E8FC14 for ; Wed, 13 Aug 2008 15:50:34 +0000 (UTC) (envelope-from tevans.uk@googlemail.com) Received: by nf-out-0910.google.com with SMTP id h3so26563nfh.33 for ; Wed, 13 Aug 2008 08:50:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:cc :in-reply-to:references:content-type:date:message-id:mime-version :x-mailer; bh=sN5aBbwy4nB6j5pUb5atXBZs2ivis/tB6s/QhS5nWpk=; b=wB8QMk7nvbI0xL6/KiOmEhAN5X3DvOq/T/DX/0mQfIKIc3ce/uVBMaQ56f/YkTDVA9 w/RcBzaHk59YE4GtQgN9Ojlrj/Gep//xkSFa8lvkghMP0vnkLmrMxAo8ES5YTXwh+RAi ZZnebOAAoQG8h6z+OBjlAl9K0GZ89NE/dpixk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:x-mailer; b=qdMpGt41Vo8XHDYeHcchRsWcPy9cThlqOo43v0n7d1vnqlezwe7tZhFzvH+wWpfJAy JZ0S9+R67pdQZHhZaBEY2q63uBqHpxTyIIs+bxAjDMRlwAHYnVJj5Um/bcUm7kuGdLnH UbHLyJw78Y6G4P8CCizJQTUPE6tqgTA8baLVk= Received: by 10.210.16.17 with SMTP id 17mr12027932ebp.127.1218641052407; Wed, 13 Aug 2008 08:24:12 -0700 (PDT) Received: from ?127.0.0.1? ( [217.206.187.80]) by mx.google.com with ESMTPS id i6sm612197gve.2.2008.08.13.08.24.10 (version=SSLv3 cipher=RC4-MD5); Wed, 13 Aug 2008 08:24:11 -0700 (PDT) From: Tom Evans To: Borja Marcos In-Reply-To: <0545482D-1E3F-4615-B3EB-04ABB838FF71@SARENET.ES> References: <43EC06E9-76B3-4AA1-BC5E-4E1BD64AFC2D@SARENET.ES> <0296197A-28ED-4DAA-A31F-C28471E864FB@SARENET.ES> <20080812102856.GA6735@eos.sc1.parodius.com> <659A017B-5D6F-4B74-A85D-4A9A040CA442@SARENET.ES> <48A2DF31.4050907@FreeBSD.org> <48A2E2AD.8060607@FreeBSD.org> <0545482D-1E3F-4615-B3EB-04ABB838FF71@SARENET.ES> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-hVU7Kr1Mr51z513io9sa" Date: Wed, 13 Aug 2008 16:24:06 +0100 Message-Id: <1218641046.70002.6.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 FreeBSD GNOME Team Port Cc: Kris Kennaway , freebsd-stable@freebsd.org, Jeremy Chadwick , Ivan Voras Subject: Re: umtxn and Apache 2.2 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2008 15:50:34 -0000 --=-hVU7Kr1Mr51z513io9sa Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2008-08-13 at 16:56 +0200, Borja Marcos wrote: >=20 > Doesn't seem stripped to me... >=20 > %file /usr/local/sbin/httpd > /usr/local/sbin/httpd: ELF 32-bit LSB executable, Intel 80386, version =20 > 1 (FreeBSD), for FreeBSD 7.0 (700110), dynamically linked (uses shared =20 > libs), FreeBSD-style, not stripped Ok, so thats the httpd binary - what about libapr, libapr-util, PHP and all your PHP extensions - are they compiled with debug and not stripped? :) Personally, I find PHP far too troublesome to run threaded. These days, I use an event MPM based front-end apache 2.2, which reverse proxies to either a prefork MPM apache 2.2 with mod_, or directly connect to a fastcgi instance. Serve all your static content from the front-end, and it's all quite fast - plus you can scale out much much more simply. Cheers Tom --=-hVU7Kr1Mr51z513io9sa Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEABECAAYFAkii/JIACgkQlcRvFfyds/fbCgCfYJboFBpK2R0ytZVtzjAjG+hc xkEAoJ4qBv9YVwZI2hCLAmukGX9XzQGK =GmPJ -----END PGP SIGNATURE----- --=-hVU7Kr1Mr51z513io9sa-- From owner-freebsd-stable@FreeBSD.ORG Wed Aug 13 17:21:30 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C08C31065673 for ; Wed, 13 Aug 2008 17:21:30 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 4D8DB8FC08 for ; Wed, 13 Aug 2008 17:21:30 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [IPv6:::1]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m7DHLNUh094237; Wed, 13 Aug 2008 13:21:24 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: pluknet Date: Wed, 13 Aug 2008 12:10:21 -0400 User-Agent: KMail/1.9.7 References: <20080730113449.GD407@cdnetworks.co.kr> <200808121111.37427.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200808131210.21755.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Wed, 13 Aug 2008 13:21:24 -0400 (EDT) X-Virus-Scanned: ClamAV 0.93.1/8026/Wed Aug 13 09:03:11 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: freebsd-stable@freebsd.org, Ulrich Spoerlein Subject: Re: cpufreq(4) panic on RELENG_7 (was: Re: Call for bfe(4) testers.) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2008 17:21:30 -0000 On Wednesday 13 August 2008 03:33:45 am pluknet wrote: > 2008/8/12 John Baldwin : > > Try http://www.freebsd.org/~jhb/patches/cpufreq_order.patch ichss0 is only > > supposed to be used if you don't have est0, and this patch fixes that. I'm > > Works now as it should (i.e. ichss0 does not attach). Ok, committed then thanks. > > curious if you get panics if you have disable est0 and leave ichss0 enabled > > or if that works ok? > > Yes, it works ok with hint.est.0.disabled="1" (with somewhat different > freq's (and subjectively a bit slower even with max freq)): > > cpu0: on acpi0 > ichss0: on cpu0 > ichss0: enabling SpeedStep support > p4tcc0: on cpu0 > acpi_acad0: on acpi0 > > $ sysctl dev.cpu > dev.cpu.0.%desc: ACPI CPU > dev.cpu.0.%driver: cpu > dev.cpu.0.%location: handle=\_PR_.CPU0 > dev.cpu.0.%pnpinfo: _HID=none _UID=0 > dev.cpu.0.%parent: acpi0 > dev.cpu.0.freq: 795 > dev.cpu.0.freq_levels: 1590/-1 1391/-1 1192/-1 993/-1 795/-1 596/-1 > 397/-1 198/-1 > dev.cpu.0.cx_supported: C1/1 C2/1 C3/85 C4/185 > dev.cpu.0.cx_lowest: C1 > dev.cpu.0.cx_usage: 100.00% 0.00% 0.00% 0.00% > > Thanks, > pluknet > -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Wed Aug 13 19:10:39 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 42404106567D for ; Wed, 13 Aug 2008 19:10:39 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.231]) by mx1.freebsd.org (Postfix) with ESMTP id 002428FC13 for ; Wed, 13 Aug 2008 19:10:38 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by wr-out-0506.google.com with SMTP id c8so59466wra.27 for ; Wed, 13 Aug 2008 12:10:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=fQ2Ne4q7e/GDdRjDRhXR0qa2horG4LJW21XrEJCx6QQ=; b=hNwu5c6bdMyCxeEgvdONeacmxL462h3H7DJz62W58N1auGjjlm1an0cv43+zw3TKl7 bQCm62iHIooZibRpAj4Lt8rZu6hWmS3x+8rx4AMB0JAnYUXAzJPDpbTk62lvoNkvRw25 tYgipTie6T9RHzun9lxCiAxFp+/zwqy31eDww= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=FDZGPRBCIgB7+yDCUE3aU5K2bDvYA5y1BBkV3/Sh2sGcWD6xUc3TDF7NKfG/PjohTL zCw6u5/gb0Tz7F8JCEfCYfXwNxDL9j0p5uE7dCGKW1xwpJu6LT/JTKzGb57/s8WmdfP0 90qFvsDPJob4MQaSQQJpFbud8p65p1r1PgqwU= Received: by 10.90.31.8 with SMTP id e8mr267307age.1.1218654638068; Wed, 13 Aug 2008 12:10:38 -0700 (PDT) Received: by 10.100.43.1 with HTTP; Wed, 13 Aug 2008 12:10:37 -0700 (PDT) Message-ID: <2a41acea0808131210r6371b532i93f1ae6963d1f1b9@mail.gmail.com> Date: Wed, 13 Aug 2008 12:10:37 -0700 From: "Jack Vogel" To: "Markus Vervier" In-Reply-To: <2a41acea0808130822i5f336b1ci15099f27a3a7c13d@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <489C4129.4090303@vervier.info> <489C88DB.6030000@vervier.info> <2a41acea0808081131m1eddc4caib0963c8a5443afd2@mail.gmail.com> <200808110819.53914.josh@tcbug.org> <20080811140249.GA27379@eos.sc1.parodius.com> <2a41acea0808110928h10d54441o7d49b11a60406934@mail.gmail.com> <48A0A1D9.8030601@vervier.info> <2a41acea0808111340o7b506804u9e4c95f1af22b95c@mail.gmail.com> <48A2B1CB.7060303@vervier.info> <2a41acea0808130822i5f336b1ci15099f27a3a7c13d@mail.gmail.com> Cc: freebsd-stable@freebsd.org Subject: Re: em(4) on FreeBSD is sometimes annoying X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2008 19:10:39 -0000 On Wed, Aug 13, 2008 at 8:22 AM, Jack Vogel wrote: > On Wed, Aug 13, 2008 at 3:04 AM, Markus Vervier wrote: >> Jack Vogel wrote: >>> >>> I didn't mean the NIC EEPROM, but the system BIOS, make sure you are >>> running the version that Jeremy said he was, if that matches you might go >>> look at settings in the BIOS that are about management. >>> >> I'm now running the latest BIOS for my X60 version 2.22 with the same >> results. Jeremy runs version 1.15 but on a T60. >>> >>> I thought you told us that when you had a back to back connection that it >>> worked, no?? >> >> Sorry, it does not work when having a b2b connection, never said that. But I >> noticed another thing: >> >> It is important that the device was up without a cable connected: >> >> 1. power off completely >> 2. boot freebsd without a cable connected >> 3. in a rootshell do ifconfig em0 up >> 4. connect the cable >> 5. no link > > Hmmm, well let me see if I can get ahold of an X60. > > Jack > Markus, I have reproduced the problem, you are correct. Thank you for persisting thru my doubts :) There is a flip side to the problem, once the interface is up and active, if you remove the cable it never shows inactive :( It must be some interrupt handling/media status issue, I'll be looking into a fix this afternoon. OH, I should note that as long as you put in a cable before you ifconfig up its fine so its not that hard to work around the issue. Stay tuned.... Jack From owner-freebsd-stable@FreeBSD.ORG Wed Aug 13 19:12:31 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7C8311065675 for ; Wed, 13 Aug 2008 19:12:31 +0000 (UTC) (envelope-from mgowda82@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.228]) by mx1.freebsd.org (Postfix) with ESMTP id 5A5FF8FC1C for ; Wed, 13 Aug 2008 19:12:31 +0000 (UTC) (envelope-from mgowda82@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so186968rvf.43 for ; Wed, 13 Aug 2008 12:12:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=uiaBmLGtO+M7z7VJ5bxMEBvCBwXdcHJEzHggGcC1A1Y=; b=juq9MfS/LHNJvE6bM2xO8d0EMB9gGaoNNOzXv1XNll+mJt50OssZzGdd8XXKN2RBAp Ma4ISiBrfaa+lvpXhft/tB8fed7wOTnKtBxqeBRPI1Ptp3laEb7W0sYxYaDtS4wV0+e0 Co/MRjOQRfOTTAK6LgMyJ+GXU6wOKoFz+Ps9s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=SxBKY7husdMriFEQkqGDW2YCXBtxT4XYFUaHgB+jFA76+imL/9GnwLzHVCuh+ulPVa bd4AhOARe159qh3ZCM2GEHq6gCteysN7zZKweuEzryXHh9Jarh6TIaNZs0/1HDEhB3yk +w2Hjnj8+DWLqvkSa2Qc9e7srLAxumXbXRTQM= Received: by 10.141.194.11 with SMTP id w11mr149038rvp.228.1218654751042; Wed, 13 Aug 2008 12:12:31 -0700 (PDT) Received: by 10.141.145.12 with HTTP; Wed, 13 Aug 2008 12:12:31 -0700 (PDT) Message-ID: Date: Wed, 13 Aug 2008 12:12:31 -0700 From: "Manjunath Ranganathaiah" To: "Daniel O'Connor" In-Reply-To: <200808132055.56039.doconnor@gsoft.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200808121734.30144.doconnor@gsoft.com.au> <200808132055.56039.doconnor@gsoft.com.au> Cc: freebsd-stable@freebsd.org Subject: Re: 6.3 (ish) hang on reboot w/ Supermicro C2SBA+ X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2008 19:12:31 -0000 > I tried the former (put it in loader.conf right?) and it made no > difference. I'll try disabling ACPI tomorrow (I tried it remotely so > it's hung now :) Yes, look at acpi man page for details. -Manjunath From owner-freebsd-stable@FreeBSD.ORG Wed Aug 13 19:43:45 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 12F181065670 for ; Wed, 13 Aug 2008 19:43:45 +0000 (UTC) (envelope-from jdc@parodius.com) Received: from mx01.sc1.parodius.com (mx01.sc1.parodius.com [72.20.106.3]) by mx1.freebsd.org (Postfix) with ESMTP id 0A0988FC25 for ; Wed, 13 Aug 2008 19:43:45 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id E68811CC0BC; Wed, 13 Aug 2008 12:43:44 -0700 (PDT) Date: Wed, 13 Aug 2008 12:43:44 -0700 From: Jeremy Chadwick To: Markus Vervier Message-ID: <20080813194344.GA16905@eos.sc1.parodius.com> References: <489C4129.4090303@vervier.info> <489C88DB.6030000@vervier.info> <2a41acea0808081131m1eddc4caib0963c8a5443afd2@mail.gmail.com> <200808110819.53914.josh@tcbug.org> <20080811140249.GA27379@eos.sc1.parodius.com> <2a41acea0808110928h10d54441o7d49b11a60406934@mail.gmail.com> <48A0A1D9.8030601@vervier.info> <2a41acea0808111340o7b506804u9e4c95f1af22b95c@mail.gmail.com> <48A2B1CB.7060303@vervier.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48A2B1CB.7060303@vervier.info> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-stable@freebsd.org, Jack Vogel Subject: Re: em(4) on FreeBSD is sometimes annoying X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2008 19:43:45 -0000 On Wed, Aug 13, 2008 at 12:04:59PM +0200, Markus Vervier wrote: > Jack Vogel wrote: >> >> I didn't mean the NIC EEPROM, but the system BIOS, make sure you are >> running the version that Jeremy said he was, if that matches you might go >> look at settings in the BIOS that are about management. >> > I'm now running the latest BIOS for my X60 version 2.22 with the same > results. Jeremy runs version 1.15 but on a T60. >> I thought you told us that when you had a back to back connection that it >> worked, no?? > Sorry, it does not work when having a b2b connection, never said that. > But I noticed another thing: > > It is important that the device was up without a cable connected: > > 1. power off completely > 2. boot freebsd without a cable connected > 3. in a rootshell do ifconfig em0 up > 4. connect the cable > 5. no link This wasn't the procedure I was following when I did testing on my T60p widescreen -- I was booting with the cable connected. I'll have to try the above procedure tonight, although it may be wasted effort as Jack was able to repro it on an X60. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Wed Aug 13 20:26:13 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9D313106566C; Wed, 13 Aug 2008 20:26:13 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 336398FC12; Wed, 13 Aug 2008 20:26:13 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [IPv6:::1]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m7DKQ4wX096034; Wed, 13 Aug 2008 16:26:04 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-stable@freebsd.org Date: Wed, 13 Aug 2008 15:48:37 -0400 User-Agent: KMail/1.9.7 References: <200808130022.m7D0MCaK082721@freefall.freebsd.org> <20080813134210.GG1803@deviant.kiev.zoral.com.ua> In-Reply-To: <20080813134210.GG1803@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200808131548.37571.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Wed, 13 Aug 2008 16:26:04 -0400 (EDT) X-Virus-Scanned: ClamAV 0.93.1/8027/Wed Aug 13 14:31:07 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Kostik Belousov , amd64@freebsd.org, stable@freebsd.org, peter@freebsd.org Subject: Re: Pending MFC Reminder [cvs commit: src/sys/amd64/amd64 cpu_switch.S genassym.c src/sys/amd64/ia32 ia32_signal.c src/sys/amd64/include pcb.h src/sys/amd64/linux32 linux32_machdep.c] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2008 20:26:13 -0000 On Wednesday 13 August 2008 09:42:10 am Kostik Belousov wrote: > On Wed, Aug 13, 2008 at 12:22:12AM +0000, MFC Notification Service wrote: > > Dear Konstantin Belousov, > > > > As you have requested, I would like to notify you that you have > > committed a change that may be MFC'ed now, as a testing period > > specified at the time of that commit is over. > > > > For reference purposes following is a copy of your original > > commit message. > > > > Regards, > > > > Maxim "MFC Reminder" Sobolev > > P.S. Please contact Maxim Sobolev if you > > believe that you received this message due to an error. > > > > kib 2008-07-30 11:30:55 UTC > > > > FreeBSD src repository > > > > Modified files: > > sys/amd64/amd64 cpu_switch.S genassym.c > > sys/amd64/ia32 ia32_signal.c > > sys/amd64/include pcb.h > > sys/amd64/linux32 linux32_machdep.c > > Log: > > SVN rev 180992 on 2008-07-30 11:30:55Z by kib > > > > Bring back the save/restore of the %ds, %es, %fs and %gs registers for > > the 32bit images on amd64. > > > > Change the semantic of the PCB_32BIT pcb flag to request the context > > switch code to operate on the segment registers. Its previous meaning > > of saving or restoring the %gs base offset is assigned to the new > > PCB_GS32BIT flag. > > > > FreeBSD 32bit image activator sets the PCB_32BIT flag, while Linux 32bit > > emulation sets PCB_32BIT | PCB_GS32BIT. > > > > Reviewed by: peter > > MFC after: 2 weeks > > > > Revision Changes Path > > 1.162 +29 -18 src/sys/amd64/amd64/cpu_switch.S > > 1.169 +1 -0 src/sys/amd64/amd64/genassym.c > > 1.18 +1 -1 src/sys/amd64/ia32/ia32_signal.c > > 1.65 +1 -0 src/sys/amd64/include/pcb.h > > 1.47 +1 -1 src/sys/amd64/linux32/linux32_machdep.c > > This appeared to be a not quite trivial MFC to perform. The reason for > complication is that the HEAD code for amd64 context switch was changed, > in particular by the r177535 by peter@. > > The r177535 formally requires r177533 for the definition of the > TDP_KTHREAD symbol for asm. The definition is needed for optimization > of the context switch to the "pure kernel thread", introduced in > r173004 that is not MFCed either, and possibly never be. > > I do not want to backport the code to the old context switch, that would > mean a rewrite from scratch. Instead, I merged the r177535 (optimization > of context switch by peter@), and commented out corresponding test in > the cpu_switch.S for the TDP_KTHREAD. > > I would be glad to get an opinions on the approach taken, and especially > for the wider testing on the RELENG_7/amd64. The problem better be > solved for 7.1. > > The patch: > http://people.freebsd.org/~kib/misc/amd64_ctx.releng_7.4.patch FYI, in 6.x and 7.x there is P_KTHREAD in p_flags that is what TDP_KTHREAD replaced. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Wed Aug 13 20:26:13 2008 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9D313106566C; Wed, 13 Aug 2008 20:26:13 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 336398FC12; Wed, 13 Aug 2008 20:26:13 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [IPv6:::1]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m7DKQ4wX096034; Wed, 13 Aug 2008 16:26:04 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-stable@freebsd.org Date: Wed, 13 Aug 2008 15:48:37 -0400 User-Agent: KMail/1.9.7 References: <200808130022.m7D0MCaK082721@freefall.freebsd.org> <20080813134210.GG1803@deviant.kiev.zoral.com.ua> In-Reply-To: <20080813134210.GG1803@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200808131548.37571.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Wed, 13 Aug 2008 16:26:04 -0400 (EDT) X-Virus-Scanned: ClamAV 0.93.1/8027/Wed Aug 13 14:31:07 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Kostik Belousov , amd64@freebsd.org, stable@freebsd.org, peter@freebsd.org Subject: Re: Pending MFC Reminder [cvs commit: src/sys/amd64/amd64 cpu_switch.S genassym.c src/sys/amd64/ia32 ia32_signal.c src/sys/amd64/include pcb.h src/sys/amd64/linux32 linux32_machdep.c] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2008 20:26:13 -0000 On Wednesday 13 August 2008 09:42:10 am Kostik Belousov wrote: > On Wed, Aug 13, 2008 at 12:22:12AM +0000, MFC Notification Service wrote: > > Dear Konstantin Belousov, > > > > As you have requested, I would like to notify you that you have > > committed a change that may be MFC'ed now, as a testing period > > specified at the time of that commit is over. > > > > For reference purposes following is a copy of your original > > commit message. > > > > Regards, > > > > Maxim "MFC Reminder" Sobolev > > P.S. Please contact Maxim Sobolev if you > > believe that you received this message due to an error. > > > > kib 2008-07-30 11:30:55 UTC > > > > FreeBSD src repository > > > > Modified files: > > sys/amd64/amd64 cpu_switch.S genassym.c > > sys/amd64/ia32 ia32_signal.c > > sys/amd64/include pcb.h > > sys/amd64/linux32 linux32_machdep.c > > Log: > > SVN rev 180992 on 2008-07-30 11:30:55Z by kib > > > > Bring back the save/restore of the %ds, %es, %fs and %gs registers for > > the 32bit images on amd64. > > > > Change the semantic of the PCB_32BIT pcb flag to request the context > > switch code to operate on the segment registers. Its previous meaning > > of saving or restoring the %gs base offset is assigned to the new > > PCB_GS32BIT flag. > > > > FreeBSD 32bit image activator sets the PCB_32BIT flag, while Linux 32bit > > emulation sets PCB_32BIT | PCB_GS32BIT. > > > > Reviewed by: peter > > MFC after: 2 weeks > > > > Revision Changes Path > > 1.162 +29 -18 src/sys/amd64/amd64/cpu_switch.S > > 1.169 +1 -0 src/sys/amd64/amd64/genassym.c > > 1.18 +1 -1 src/sys/amd64/ia32/ia32_signal.c > > 1.65 +1 -0 src/sys/amd64/include/pcb.h > > 1.47 +1 -1 src/sys/amd64/linux32/linux32_machdep.c > > This appeared to be a not quite trivial MFC to perform. The reason for > complication is that the HEAD code for amd64 context switch was changed, > in particular by the r177535 by peter@. > > The r177535 formally requires r177533 for the definition of the > TDP_KTHREAD symbol for asm. The definition is needed for optimization > of the context switch to the "pure kernel thread", introduced in > r173004 that is not MFCed either, and possibly never be. > > I do not want to backport the code to the old context switch, that would > mean a rewrite from scratch. Instead, I merged the r177535 (optimization > of context switch by peter@), and commented out corresponding test in > the cpu_switch.S for the TDP_KTHREAD. > > I would be glad to get an opinions on the approach taken, and especially > for the wider testing on the RELENG_7/amd64. The problem better be > solved for 7.1. > > The patch: > http://people.freebsd.org/~kib/misc/amd64_ctx.releng_7.4.patch FYI, in 6.x and 7.x there is P_KTHREAD in p_flags that is what TDP_KTHREAD replaced. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Wed Aug 13 20:34:11 2008 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0A1E6106567C; Wed, 13 Aug 2008 20:34:11 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id AF7228FC14; Wed, 13 Aug 2008 20:34:10 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m7DKY8Nm040893; Wed, 13 Aug 2008 16:34:08 -0400 (EDT) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.8/8.13.3) with ESMTP id m7DKY7wm038972 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Aug 2008 16:34:07 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <200808132034.m7DKY7wm038972@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 13 Aug 2008 16:34:00 -0400 To: Robert Watson From: Mike Tancsa In-Reply-To: References: <200808120059.m7C0xvUH028011@lava.sentex.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: stable@FreeBSD.org Subject: Re: HEADS UP: inpcb/inpcbinfo rwlocking: coming to a 7-STABLE branch near you X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2008 20:34:11 -0000 At 06:20 AM 8/12/2008, Robert Watson wrote: >Anyone out there running name servers, NFS over UDP, and other UDP >workloads: your testing of this patch prior to commit would be much >appreciated. Not sure if this is related or not, but I am seeing a 'boatload' of strange proxy arp issues. Odd thing is that I dont have proxy arp enabled anywhere, at least not knowingly. 0[smtp2]# sysctl -a | grep prox net.link.ether.inet.proxyall: 0 0[smtp2]# 0[smtp2]# arp -na | wc 27665 227053 1669734 0[smtp2]# ? (199.212.134.1) at (incomplete) on em0 [ethernet] ? (199.212.134.1) at (incomplete) on em0 [ethernet] ? (199.212.134.1) at (incomplete) on em0 [ethernet] ? (199.212.134.1) at (incomplete) on em0 [ethernet] ? (199.212.134.1) at (incomplete) on em0 [ethernet] ? (199.212.134.1) at (incomplete) on em0 [ethernet] ? (199.212.134.1) at (incomplete) on em0 [ethernet] ? (199.212.134.1) at (incomplete) on em0 [ethernet] ? (199.212.134.1) at (incomplete) on em0 [ethernet] ? (199.212.134.1) at (incomplete) on em0 [ethernet] ? (199.212.134.1) at (incomplete) on em0 [ethernet] ? (199.212.134.1) at (incomplete) on em0 published (proxy only) [ethernet] ? (199.212.134.2) at 00:30:48:8f:3e:8a on em0 [ethernet] ? (199.212.134.2) at (incomplete) on em0 [ethernet] ? (199.212.134.2) at (incomplete) on em0 [ethernet] ? (199.212.134.2) at (incomplete) on em0 [ethernet] ? (199.212.134.2) at (incomplete) on em0 [ethernet] ? (199.212.134.2) at (incomplete) on em0 [ethernet] ? (199.212.134.2) at (incomplete) on em0 [ethernet] ? (199.212.134.2) at (incomplete) on em0 [ethernet] ? (199.212.134.2) at (incomplete) on em0 published (proxy only) [ethernet] ? (199.212.134.2) at (incomplete) on em0 published (proxy only) [ethernet] ? (199.212.134.2) at (incomplete) on em0 [ethernet] ? (199.212.134.2) at (incomplete) on em0 published (proxy only) [ethernet] ? (199.212.134.2) at (incomplete) on em0 [ethernet] ? (199.212.134.2) at (incomplete) on em0 [ethernet] ? (199.212.134.2) at (incomplete) on em0 [ethernet] From owner-freebsd-stable@FreeBSD.ORG Wed Aug 13 20:41:04 2008 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ADAB1106567A for ; Wed, 13 Aug 2008 20:41:04 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 84CA28FC2C for ; Wed, 13 Aug 2008 20:41:04 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id CE99346C2B; Wed, 13 Aug 2008 16:41:03 -0400 (EDT) Date: Wed, 13 Aug 2008 21:41:03 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Mike Tancsa In-Reply-To: <200808132034.m7DKY7wm038972@lava.sentex.ca> Message-ID: References: <200808120059.m7C0xvUH028011@lava.sentex.ca> <200808132034.m7DKY7wm038972@lava.sentex.ca> User-Agent: Alpine 1.10 (BSF 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: stable@FreeBSD.org Subject: Re: HEADS UP: inpcb/inpcbinfo rwlocking: coming to a 7-STABLE branch near you X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2008 20:41:04 -0000 On Wed, 13 Aug 2008, Mike Tancsa wrote: > At 06:20 AM 8/12/2008, Robert Watson wrote: > >> Anyone out there running name servers, NFS over UDP, and other UDP >> workloads: your testing of this patch prior to commit would be much >> appreciated. > > Not sure if this is related or not, but I am seeing a 'boatload' of strange > proxy arp issues. Odd thing is that I dont have proxy arp enabled anywhere, > at least not knowingly. Dear Mike: Well, it shouldn't be related, but sometimes things get tricky with locking if it turns out that extra locking at one layer was masking a lack of locking at another. Let's try to diagnose this one a bit more before concluding that is the case, though. I take that the same problems don't happen if you boot a vanilla version of the same rev of the kernel? What command did you use to generate the list at the bottom of your e-mail? Robert N M Watson Computer Laboratory University of Cambridge > > 0[smtp2]# sysctl -a | grep prox > net.link.ether.inet.proxyall: 0 > 0[smtp2]# > > > 0[smtp2]# arp -na | wc > 27665 227053 1669734 > 0[smtp2]# > > ? (199.212.134.1) at (incomplete) on em0 [ethernet] > ? (199.212.134.1) at (incomplete) on em0 [ethernet] > ? (199.212.134.1) at (incomplete) on em0 [ethernet] > ? (199.212.134.1) at (incomplete) on em0 [ethernet] > ? (199.212.134.1) at (incomplete) on em0 [ethernet] > ? (199.212.134.1) at (incomplete) on em0 [ethernet] > ? (199.212.134.1) at (incomplete) on em0 [ethernet] > ? (199.212.134.1) at (incomplete) on em0 [ethernet] > ? (199.212.134.1) at (incomplete) on em0 [ethernet] > ? (199.212.134.1) at (incomplete) on em0 [ethernet] > ? (199.212.134.1) at (incomplete) on em0 [ethernet] > ? (199.212.134.1) at (incomplete) on em0 published (proxy only) [ethernet] > ? (199.212.134.2) at 00:30:48:8f:3e:8a on em0 [ethernet] > ? (199.212.134.2) at (incomplete) on em0 [ethernet] > ? (199.212.134.2) at (incomplete) on em0 [ethernet] > ? (199.212.134.2) at (incomplete) on em0 [ethernet] > ? (199.212.134.2) at (incomplete) on em0 [ethernet] > ? (199.212.134.2) at (incomplete) on em0 [ethernet] > ? (199.212.134.2) at (incomplete) on em0 [ethernet] > ? (199.212.134.2) at (incomplete) on em0 [ethernet] > ? (199.212.134.2) at (incomplete) on em0 published (proxy only) [ethernet] > ? (199.212.134.2) at (incomplete) on em0 published (proxy only) [ethernet] > ? (199.212.134.2) at (incomplete) on em0 [ethernet] > ? (199.212.134.2) at (incomplete) on em0 published (proxy only) [ethernet] > ? (199.212.134.2) at (incomplete) on em0 [ethernet] > ? (199.212.134.2) at (incomplete) on em0 [ethernet] > ? (199.212.134.2) at (incomplete) on em0 [ethernet] > From owner-freebsd-stable@FreeBSD.ORG Wed Aug 13 20:46:40 2008 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 683471065672; Wed, 13 Aug 2008 20:46:40 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 41D3C8FC1C; Wed, 13 Aug 2008 20:46:40 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m7DKkcK0043138; Wed, 13 Aug 2008 16:46:38 -0400 (EDT) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.8/8.13.3) with ESMTP id m7DKkb47039033 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Aug 2008 16:46:37 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <200808132046.m7DKkb47039033@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 13 Aug 2008 16:46:30 -0400 To: Robert Watson From: Mike Tancsa In-Reply-To: References: <200808120059.m7C0xvUH028011@lava.sentex.ca> <200808132034.m7DKY7wm038972@lava.sentex.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: stable@FreeBSD.org Subject: Re: HEADS UP: inpcb/inpcbinfo rwlocking: coming to a 7-STABLE branch near you X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2008 20:46:40 -0000 At 04:41 PM 8/13/2008, Robert Watson wrote: >Well, it shouldn't be related, but sometimes things get tricky with >locking if it turns out that extra locking at one layer was masking >a lack of locking at another. Let's try to diagnose this one a bit >more before concluding that is the case, though. I take that the >same problems don't happen if you boot a vanilla version of the same >rev of the kernel? What command did you use to generate the list at >the bottom of your e-mail? Hi Robert, the arp messages were a snippet from just arp -na. All of those IP addresses are local to the box. I am just doing a cvsup to the same point in time and am rebuilding the kernel. Also odd, is that if I do a arp -nda it seems to want to delete more than it should. Here is a snippet 199.212.134.2 (199.212.134.2) deleted delete: cannot locate 199.212.134.2 delete: cannot locate 199.212.134.2 delete: cannot locate 199.212.134.2 delete: cannot locate 199.212.134.2 delete: cannot locate 199.212.134.2 delete: cannot locate 199.212.134.2 delete: cannot locate 199.212.134.2 delete: cannot locate 199.212.134.2 delete: cannot locate 199.212.134.2 delete: cannot locate 199.212.134.2 delete: cannot locate 199.212.134.2 delete: cannot locate 199.212.134.2 delete: cannot locate 199.212.134.2 delete: cannot locate 199.212.134.2 After doing arp -nda, I am back to a very large arp cache again right away 0[smtp2]# arp -na | wc 27818 228335 1679120 0[smtp2]# 0[smtp2]# netstat -na | wc 762 4920 59057 0[smtp2]# netstat -nr | wc 27853 167097 1893894 0[smtp2]# >Robert N M Watson >Computer Laboratory >University of Cambridge > >> >>0[smtp2]# sysctl -a | grep prox >>net.link.ether.inet.proxyall: 0 >>0[smtp2]# >> >> >>0[smtp2]# arp -na | wc >> 27665 227053 1669734 >>0[smtp2]# >> >>? (199.212.134.1) at (incomplete) on em0 [ethernet] >>? (199.212.134.1) at (incomplete) on em0 [ethernet] >>? (199.212.134.1) at (incomplete) on em0 [ethernet] >>? (199.212.134.1) at (incomplete) on em0 [ethernet] >>? (199.212.134.1) at (incomplete) on em0 [ethernet] >>? (199.212.134.1) at (incomplete) on em0 [ethernet] >>? (199.212.134.1) at (incomplete) on em0 [ethernet] >>? (199.212.134.1) at (incomplete) on em0 [ethernet] >>? (199.212.134.1) at (incomplete) on em0 [ethernet] >>? (199.212.134.1) at (incomplete) on em0 [ethernet] >>? (199.212.134.1) at (incomplete) on em0 [ethernet] >>? (199.212.134.1) at (incomplete) on em0 published (proxy only) [ethernet] >>? (199.212.134.2) at 00:30:48:8f:3e:8a on em0 [ethernet] >>? (199.212.134.2) at (incomplete) on em0 [ethernet] >>? (199.212.134.2) at (incomplete) on em0 [ethernet] >>? (199.212.134.2) at (incomplete) on em0 [ethernet] >>? (199.212.134.2) at (incomplete) on em0 [ethernet] >>? (199.212.134.2) at (incomplete) on em0 [ethernet] >>? (199.212.134.2) at (incomplete) on em0 [ethernet] >>? (199.212.134.2) at (incomplete) on em0 [ethernet] >>? (199.212.134.2) at (incomplete) on em0 published (proxy only) [ethernet] >>? (199.212.134.2) at (incomplete) on em0 published (proxy only) [ethernet] >>? (199.212.134.2) at (incomplete) on em0 [ethernet] >>? (199.212.134.2) at (incomplete) on em0 published (proxy only) [ethernet] >>? (199.212.134.2) at (incomplete) on em0 [ethernet] >>? (199.212.134.2) at (incomplete) on em0 [ethernet] >>? (199.212.134.2) at (incomplete) on em0 [ethernet] From owner-freebsd-stable@FreeBSD.ORG Wed Aug 13 21:12:19 2008 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4268A106566B for ; Wed, 13 Aug 2008 21:12:19 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id F067C8FC16 for ; Wed, 13 Aug 2008 21:12:18 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 834A846C0B; Wed, 13 Aug 2008 17:12:18 -0400 (EDT) Date: Wed, 13 Aug 2008 22:12:18 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Mike Tancsa In-Reply-To: <200808132046.m7DKkb47039033@lava.sentex.ca> Message-ID: References: <200808120059.m7C0xvUH028011@lava.sentex.ca> <200808132034.m7DKY7wm038972@lava.sentex.ca> <200808132046.m7DKkb47039033@lava.sentex.ca> User-Agent: Alpine 1.10 (BSF 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: stable@FreeBSD.org Subject: Re: HEADS UP: inpcb/inpcbinfo rwlocking: coming to a 7-STABLE branch near you X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2008 21:12:19 -0000 On Wed, 13 Aug 2008, Mike Tancsa wrote: > At 04:41 PM 8/13/2008, Robert Watson wrote: > >> Well, it shouldn't be related, but sometimes things get tricky with locking >> if it turns out that extra locking at one layer was masking a lack of >> locking at another. Let's try to diagnose this one a bit more before >> concluding that is the case, though. I take that the same problems don't >> happen if you boot a vanilla version of the same rev of the kernel? What >> command did you use to generate the list at the bottom of your e-mail? > > the arp messages were a snippet from just arp -na. All of those IP > addresses are local to the box. I am just doing a cvsup to the same point > in time and am rebuilding the kernel. > > Also odd, is that if I do a arp -nda it seems to want to delete more than it > should. Here is a snippet It's concerning also that there is more than one entry for any particular IP address. I'll have to go reread the ARP code. Confirming that this doesn't happen with vanilla head is definitely the next step. I'll be fairly busy for the next few days with things in Cambridge; if we can't rule out the inpcb patches as the source of the problem, I'll defer committing them until next week when I have a chance to work through this more. Robert N M Watson Computer Laboratory University of Cambridge > > > 199.212.134.2 (199.212.134.2) deleted > delete: cannot locate 199.212.134.2 > delete: cannot locate 199.212.134.2 > delete: cannot locate 199.212.134.2 > delete: cannot locate 199.212.134.2 > delete: cannot locate 199.212.134.2 > delete: cannot locate 199.212.134.2 > delete: cannot locate 199.212.134.2 > delete: cannot locate 199.212.134.2 > delete: cannot locate 199.212.134.2 > delete: cannot locate 199.212.134.2 > delete: cannot locate 199.212.134.2 > delete: cannot locate 199.212.134.2 > delete: cannot locate 199.212.134.2 > delete: cannot locate 199.212.134.2 > > > After doing arp -nda, I am back to a very large arp cache again right away > > 0[smtp2]# arp -na | wc > 27818 228335 1679120 > 0[smtp2]# > > 0[smtp2]# netstat -na | wc > 762 4920 59057 > 0[smtp2]# netstat -nr | wc > 27853 167097 1893894 > 0[smtp2]# > > > > > >> Robert N M Watson >> Computer Laboratory >> University of Cambridge >> >>> >>> 0[smtp2]# sysctl -a | grep prox >>> net.link.ether.inet.proxyall: 0 >>> 0[smtp2]# >>> >>> >>> 0[smtp2]# arp -na | wc >>> 27665 227053 1669734 >>> 0[smtp2]# >>> >>> ? (199.212.134.1) at (incomplete) on em0 [ethernet] >>> ? (199.212.134.1) at (incomplete) on em0 [ethernet] >>> ? (199.212.134.1) at (incomplete) on em0 [ethernet] >>> ? (199.212.134.1) at (incomplete) on em0 [ethernet] >>> ? (199.212.134.1) at (incomplete) on em0 [ethernet] >>> ? (199.212.134.1) at (incomplete) on em0 [ethernet] >>> ? (199.212.134.1) at (incomplete) on em0 [ethernet] >>> ? (199.212.134.1) at (incomplete) on em0 [ethernet] >>> ? (199.212.134.1) at (incomplete) on em0 [ethernet] >>> ? (199.212.134.1) at (incomplete) on em0 [ethernet] >>> ? (199.212.134.1) at (incomplete) on em0 [ethernet] >>> ? (199.212.134.1) at (incomplete) on em0 published (proxy only) [ethernet] >>> ? (199.212.134.2) at 00:30:48:8f:3e:8a on em0 [ethernet] >>> ? (199.212.134.2) at (incomplete) on em0 [ethernet] >>> ? (199.212.134.2) at (incomplete) on em0 [ethernet] >>> ? (199.212.134.2) at (incomplete) on em0 [ethernet] >>> ? (199.212.134.2) at (incomplete) on em0 [ethernet] >>> ? (199.212.134.2) at (incomplete) on em0 [ethernet] >>> ? (199.212.134.2) at (incomplete) on em0 [ethernet] >>> ? (199.212.134.2) at (incomplete) on em0 [ethernet] >>> ? (199.212.134.2) at (incomplete) on em0 published (proxy only) [ethernet] >>> ? (199.212.134.2) at (incomplete) on em0 published (proxy only) [ethernet] >>> ? (199.212.134.2) at (incomplete) on em0 [ethernet] >>> ? (199.212.134.2) at (incomplete) on em0 published (proxy only) [ethernet] >>> ? (199.212.134.2) at (incomplete) on em0 [ethernet] >>> ? (199.212.134.2) at (incomplete) on em0 [ethernet] >>> ? (199.212.134.2) at (incomplete) on em0 [ethernet] > > From owner-freebsd-stable@FreeBSD.ORG Wed Aug 13 21:16:37 2008 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9F363106567E; Wed, 13 Aug 2008 21:16:37 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 6D82A8FC12; Wed, 13 Aug 2008 21:16:37 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m7DLGZHe047047; Wed, 13 Aug 2008 17:16:35 -0400 (EDT) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.8/8.13.3) with ESMTP id m7DLGY1f039165 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Aug 2008 17:16:34 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <200808132116.m7DLGY1f039165@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 13 Aug 2008 17:16:27 -0400 To: Robert Watson From: Mike Tancsa In-Reply-To: <7.1.0.9.0.20080813164157.161ba2e8@sentex.net> References: <200808120059.m7C0xvUH028011@lava.sentex.ca> <200808132034.m7DKY7wm038972@lava.sentex.ca> <7.1.0.9.0.20080813164157.161ba2e8@sentex.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: stable@FreeBSD.org Subject: Re: HEADS UP: inpcb/inpcbinfo rwlocking: coming to a 7-STABLE branch near you X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2008 21:16:37 -0000 At 04:46 PM 8/13/2008, Mike Tancsa wrote: >At 04:41 PM 8/13/2008, Robert Watson wrote: >>Well, it shouldn't be related, but sometimes things get tricky with >>locking if it turns out that extra locking at one layer was masking >>a lack of locking at another. Let's try to diagnose this one a bit >>more before concluding that is the case, though. I take that the >>same problems don't happen if you boot a vanilla version of the >>same rev of the kernel? What command did you use to generate the >>list at the bottom of your e-mail? > > >Hi Robert, > the arp messages were a snippet from just arp -na. All of > those IP addresses are local to the box. I am just doing a cvsup > to the same point in time and am rebuilding the kernel. Actually, it looks like its unrelated to your changes. I just did a full cvsup, and am getting that strange proxy arp stuff and again, the incomplete arp messages.... % arp -na| grep inc ? (64.7.153.9) at (incomplete) on em1 [ethernet] ? (64.7.153.9) at (incomplete) on em1 [ethernet] ? (64.7.153.9) at (incomplete) on em1 [ethernet] ? (64.7.153.19) at (incomplete) on em1 [ethernet] ? (64.7.153.19) at (incomplete) on em1 [ethernet] ? (64.7.153.19) at (incomplete) on em1 [ethernet] ? (64.7.153.19) at (incomplete) on em1 [ethernet] ? (64.7.153.19) at (incomplete) on em1 [ethernet] ? (64.7.153.19) at (incomplete) on em1 [ethernet] ? (64.7.153.19) at (incomplete) on em1 [ethernet] ? (64.7.153.19) at (incomplete) on em1 [ethernet] ? (64.7.153.19) at (incomplete) on em1 published (proxy only) [ethernet] ? (64.7.153.19) at (incomplete) on em1 published (proxy only) [ethernet] ? (64.7.153.19) at (incomplete) on em1 published (proxy only) [ethernet] ? (64.7.153.19) at (incomplete) on em1 published (proxy only) [ethernet] ? (64.7.153.19) at (incomplete) on em1 [ethernet] ? (64.7.153.19) at (incomplete) on em1 [ethernet] ? (64.7.153.19) at (incomplete) on em1 [ethernet] ? (64.7.153.19) at (incomplete) on em1 [ethernet] ? (64.7.153.19) at (incomplete) on em1 [ethernet] ? (64.7.153.19) at (incomplete) on em1 [ethernet] ? (64.7.153.19) at (incomplete) on em1 [ethernet] ? (64.7.153.19) at (incomplete) on em1 [ethernet] ? (64.7.153.19) at (incomplete) on em1 [ethernet] ? (64.7.153.19) at (incomplete) on em1 [ethernet] ? (64.7.153.20) at (incomplete) on em1 [ethernet] ? (64.7.153.20) at (incomplete) on em1 [ethernet] ? (64.7.153.20) at (incomplete) on em1 [ethernet] ? (64.7.153.20) at (incomplete) on em1 [ethernet] ? (64.7.153.20) at (incomplete) on em1 [ethernet] ? (64.7.153.21) at (incomplete) on em1 [ethernet] ? (64.7.153.21) at (incomplete) on em1 [ethernet] ? (64.7.153.21) at (incomplete) on em1 [ethernet] ? (64.7.153.21) at (incomplete) on em1 [ethernet] ? (64.7.153.21) at (incomplete) on em1 [ethernet] ? (64.7.153.21) at (incomplete) on em1 [ethernet] ? (64.7.153.21) at (incomplete) on em1 [ethernet] ? (64.7.153.24) at (incomplete) on em1 [ethernet] ? (64.7.153.25) at (incomplete) on em1 published (proxy only) [ethernet] ? (64.7.153.25) at (incomplete) on em1 [ethernet] ? (64.7.153.25) at (incomplete) on em1 [ethernet] ? (64.7.153.25) at (incomplete) on em1 [ethernet] ? (64.7.153.25) at (incomplete) on em1 [ethernet] ? (64.7.153.26) at (incomplete) on em1 [ethernet] ? (64.7.153.26) at (incomplete) on em1 [ethernet] ? (64.7.153.26) at (incomplete) on em1 [ethernet] ? (64.7.153.26) at (incomplete) on em1 published (proxy only) [ethernet] ? (64.7.153.26) at (incomplete) on em1 [ethernet] ? (64.7.153.26) at (incomplete) on em1 [ethernet] ? (64.7.153.26) at (incomplete) on em1 [ethernet] ? (64.7.153.27) at (incomplete) on em1 [ethernet] ? (64.7.153.27) at (incomplete) on em1 [ethernet] ? (64.7.153.27) at (incomplete) on em1 [ethernet] ? (64.7.153.27) at (incomplete) on em1 [ethernet] ? (64.7.153.27) at (incomplete) on em1 [ethernet] ? (64.7.153.27) at (incomplete) on em1 [ethernet] ? (64.7.153.27) at (incomplete) on em1 [ethernet] ? (64.7.153.27) at (incomplete) on em1 [ethernet] ? (199.212.134.1) at (incomplete) on em0 [ethernet] ? (199.212.134.1) at (incomplete) on em0 [ethernet] ? (199.212.134.1) at (incomplete) on em0 [ethernet] ? (199.212.134.1) at (incomplete) on em0 [ethernet] ? (199.212.134.1) at (incomplete) on em0 [ethernet] ? (199.212.134.1) at (incomplete) on em0 published (proxy only) [ethernet] ? (199.212.134.1) at (incomplete) on em0 published (proxy only) [ethernet] ? (199.212.134.1) at (incomplete) on em0 [ethernet] ? (199.212.134.1) at (incomplete) on em0 [ethernet] ? (199.212.134.1) at (incomplete) on em0 published (proxy only) [ethernet] ? (199.212.134.1) at (incomplete) on em0 [ethernet] ? (199.212.134.1) at (incomplete) on em0 [ethernet] ? (199.212.134.1) at (incomplete) on em0 [ethernet] ? (199.212.134.1) at (incomplete) on em0 [ethernet] ? (199.212.134.1) at (incomplete) on em0 [ethernet] ? (199.212.134.1) at (incomplete) on em0 published (proxy only) [ethernet] ? (199.212.134.1) at (incomplete) on em0 [ethernet] ? (199.212.134.1) at (incomplete) on em0 [ethernet] ? (199.212.134.1) at (incomplete) on em0 [ethernet] ? (199.212.134.1) at (incomplete) on em0 published (proxy only) [ethernet] ? (199.212.134.1) at (incomplete) on em0 [ethernet] ? (199.212.134.1) at (incomplete) on em0 published (proxy only) [ethernet] ? (199.212.134.1) at (incomplete) on em0 [ethernet] ? (199.212.134.1) at (incomplete) on em0 [ethernet] ? (199.212.134.1) at (incomplete) on em0 [ethernet] ? (199.212.134.1) at (incomplete) on em0 published (proxy only) [ethernet] ? (199.212.134.1) at (incomplete) on em0 published (proxy only) [ethernet] ? (199.212.134.1) at (incomplete) on em0 published (proxy only) [ethernet] ? (199.212.134.1) at (incomplete) on em0 published (proxy only) [ethernet] ? (199.212.134.1) at (incomplete) on em0 [ethernet] ? (199.212.134.1) at (incomplete) on em0 [ethernet] ? (199.212.134.1) at (incomplete) on em0 [ethernet] ? (199.212.134.1) at (incomplete) on em0 published (proxy only) [ethernet] ? (199.212.134.1) at (incomplete) on em0 [ethernet] ? (199.212.134.1) at (incomplete) on em0 [ethernet] ? (199.212.134.1) at (incomplete) on em0 [ethernet] ? (199.212.134.1) at (incomplete) on em0 [ethernet] ? (199.212.134.1) at (incomplete) on em0 [ethernet] ? (199.212.134.1) at (incomplete) on em0 [ethernet] ? (199.212.134.1) at (incomplete) on em0 [ethernet] ? (199.212.134.1) at (incomplete) on em0 [ethernet] ? (199.212.134.1) at (incomplete) on em0 [ethernet] ? (199.212.134.1) at (incomplete) on em0 [ethernet] ? (199.212.134.1) at (incomplete) on em0 [ethernet] ? (199.212.134.1) at (incomplete) on em0 [ethernet] I will try a kernel before the em changes, as thats the only other thing I can think of off the top of my head. ---Mike From owner-freebsd-stable@FreeBSD.ORG Wed Aug 13 21:25:44 2008 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 65AE61065670; Wed, 13 Aug 2008 21:25:44 +0000 (UTC) (envelope-from jdc@parodius.com) Received: from mx01.sc1.parodius.com (mx01.sc1.parodius.com [72.20.106.3]) by mx1.freebsd.org (Postfix) with ESMTP id 4B3A98FC21; Wed, 13 Aug 2008 21:25:44 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id 2BD171CC0AC; Wed, 13 Aug 2008 14:25:44 -0700 (PDT) Date: Wed, 13 Aug 2008 14:25:44 -0700 From: Jeremy Chadwick To: Mike Tancsa Message-ID: <20080813212544.GA25915@eos.sc1.parodius.com> References: <200808120059.m7C0xvUH028011@lava.sentex.ca> <200808132034.m7DKY7wm038972@lava.sentex.ca> <7.1.0.9.0.20080813164157.161ba2e8@sentex.net> <200808132116.m7DLGY1f039165@lava.sentex.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200808132116.m7DLGY1f039165@lava.sentex.ca> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: stable@FreeBSD.org, Robert Watson , Jack Vogel Subject: Re: HEADS UP: inpcb/inpcbinfo rwlocking: coming to a 7-STABLE branch near you X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2008 21:25:44 -0000 On Wed, Aug 13, 2008 at 05:16:27PM -0400, Mike Tancsa wrote: > At 04:46 PM 8/13/2008, Mike Tancsa wrote: >> At 04:41 PM 8/13/2008, Robert Watson wrote: >>> Well, it shouldn't be related, but sometimes things get tricky with >>> locking if it turns out that extra locking at one layer was masking >>> a lack of locking at another. Let's try to diagnose this one a bit >>> more before concluding that is the case, though. I take that the >>> same problems don't happen if you boot a vanilla version of the same >>> rev of the kernel? What command did you use to generate the list at >>> the bottom of your e-mail? >> >> >> Hi Robert, >> the arp messages were a snippet from just arp -na. All of >> those IP addresses are local to the box. I am just doing a cvsup to >> the same point in time and am rebuilding the kernel. > > Actually, it looks like its unrelated to your changes. I just did a full > cvsup, and am getting that strange proxy arp stuff and again, the > incomplete arp messages.... > > > % arp -na| grep inc > ? (64.7.153.9) at (incomplete) on em1 [ethernet] > ? (64.7.153.9) at (incomplete) on em1 [ethernet] > ? (64.7.153.9) at (incomplete) on em1 [ethernet] > ? (64.7.153.19) at (incomplete) on em1 [ethernet] > ? (64.7.153.19) at (incomplete) on em1 [ethernet] > ? (64.7.153.19) at (incomplete) on em1 [ethernet] > ? (64.7.153.19) at (incomplete) on em1 [ethernet] > ? (64.7.153.19) at (incomplete) on em1 [ethernet] > ? (64.7.153.19) at (incomplete) on em1 [ethernet] > ? (64.7.153.19) at (incomplete) on em1 [ethernet] > ? (64.7.153.19) at (incomplete) on em1 [ethernet] > ? (64.7.153.19) at (incomplete) on em1 published (proxy only) [ethernet] > ? (64.7.153.19) at (incomplete) on em1 published (proxy only) [ethernet] > ? (64.7.153.19) at (incomplete) on em1 published (proxy only) [ethernet] > ? (64.7.153.19) at (incomplete) on em1 published (proxy only) [ethernet] > ? (64.7.153.19) at (incomplete) on em1 [ethernet] > ? (64.7.153.19) at (incomplete) on em1 [ethernet] > ? (64.7.153.19) at (incomplete) on em1 [ethernet] > ? (64.7.153.19) at (incomplete) on em1 [ethernet] > ? (64.7.153.19) at (incomplete) on em1 [ethernet] > ? (64.7.153.19) at (incomplete) on em1 [ethernet] > ? (64.7.153.19) at (incomplete) on em1 [ethernet] > ? (64.7.153.19) at (incomplete) on em1 [ethernet] > ? (64.7.153.19) at (incomplete) on em1 [ethernet] > ? (64.7.153.19) at (incomplete) on em1 [ethernet] > ? (64.7.153.20) at (incomplete) on em1 [ethernet] > ? (64.7.153.20) at (incomplete) on em1 [ethernet] > ? (64.7.153.20) at (incomplete) on em1 [ethernet] > ? (64.7.153.20) at (incomplete) on em1 [ethernet] > ? (64.7.153.20) at (incomplete) on em1 [ethernet] > ? (64.7.153.21) at (incomplete) on em1 [ethernet] > ? (64.7.153.21) at (incomplete) on em1 [ethernet] > ? (64.7.153.21) at (incomplete) on em1 [ethernet] > ? (64.7.153.21) at (incomplete) on em1 [ethernet] > ? (64.7.153.21) at (incomplete) on em1 [ethernet] > ? (64.7.153.21) at (incomplete) on em1 [ethernet] > ? (64.7.153.21) at (incomplete) on em1 [ethernet] > ? (64.7.153.24) at (incomplete) on em1 [ethernet] > ? (64.7.153.25) at (incomplete) on em1 published (proxy only) [ethernet] > ? (64.7.153.25) at (incomplete) on em1 [ethernet] > ? (64.7.153.25) at (incomplete) on em1 [ethernet] > ? (64.7.153.25) at (incomplete) on em1 [ethernet] > ? (64.7.153.25) at (incomplete) on em1 [ethernet] > ? (64.7.153.26) at (incomplete) on em1 [ethernet] > ? (64.7.153.26) at (incomplete) on em1 [ethernet] > ? (64.7.153.26) at (incomplete) on em1 [ethernet] > ? (64.7.153.26) at (incomplete) on em1 published (proxy only) [ethernet] > ? (64.7.153.26) at (incomplete) on em1 [ethernet] > ? (64.7.153.26) at (incomplete) on em1 [ethernet] > ? (64.7.153.26) at (incomplete) on em1 [ethernet] > ? (64.7.153.27) at (incomplete) on em1 [ethernet] > ? (64.7.153.27) at (incomplete) on em1 [ethernet] > ? (64.7.153.27) at (incomplete) on em1 [ethernet] > ? (64.7.153.27) at (incomplete) on em1 [ethernet] > ? (64.7.153.27) at (incomplete) on em1 [ethernet] > ? (64.7.153.27) at (incomplete) on em1 [ethernet] > ? (64.7.153.27) at (incomplete) on em1 [ethernet] > ? (64.7.153.27) at (incomplete) on em1 [ethernet] > ? (199.212.134.1) at (incomplete) on em0 [ethernet] > ? (199.212.134.1) at (incomplete) on em0 [ethernet] > ? (199.212.134.1) at (incomplete) on em0 [ethernet] > ? (199.212.134.1) at (incomplete) on em0 [ethernet] > ? (199.212.134.1) at (incomplete) on em0 [ethernet] > ? (199.212.134.1) at (incomplete) on em0 published (proxy only) [ethernet] > ? (199.212.134.1) at (incomplete) on em0 published (proxy only) [ethernet] > ? (199.212.134.1) at (incomplete) on em0 [ethernet] > ? (199.212.134.1) at (incomplete) on em0 [ethernet] > ? (199.212.134.1) at (incomplete) on em0 published (proxy only) [ethernet] > ? (199.212.134.1) at (incomplete) on em0 [ethernet] > ? (199.212.134.1) at (incomplete) on em0 [ethernet] > ? (199.212.134.1) at (incomplete) on em0 [ethernet] > ? (199.212.134.1) at (incomplete) on em0 [ethernet] > ? (199.212.134.1) at (incomplete) on em0 [ethernet] > ? (199.212.134.1) at (incomplete) on em0 published (proxy only) [ethernet] > ? (199.212.134.1) at (incomplete) on em0 [ethernet] > ? (199.212.134.1) at (incomplete) on em0 [ethernet] > ? (199.212.134.1) at (incomplete) on em0 [ethernet] > ? (199.212.134.1) at (incomplete) on em0 published (proxy only) [ethernet] > ? (199.212.134.1) at (incomplete) on em0 [ethernet] > ? (199.212.134.1) at (incomplete) on em0 published (proxy only) [ethernet] > ? (199.212.134.1) at (incomplete) on em0 [ethernet] > ? (199.212.134.1) at (incomplete) on em0 [ethernet] > ? (199.212.134.1) at (incomplete) on em0 [ethernet] > ? (199.212.134.1) at (incomplete) on em0 published (proxy only) [ethernet] > ? (199.212.134.1) at (incomplete) on em0 published (proxy only) [ethernet] > ? (199.212.134.1) at (incomplete) on em0 published (proxy only) [ethernet] > ? (199.212.134.1) at (incomplete) on em0 published (proxy only) [ethernet] > ? (199.212.134.1) at (incomplete) on em0 [ethernet] > ? (199.212.134.1) at (incomplete) on em0 [ethernet] > ? (199.212.134.1) at (incomplete) on em0 [ethernet] > ? (199.212.134.1) at (incomplete) on em0 published (proxy only) [ethernet] > ? (199.212.134.1) at (incomplete) on em0 [ethernet] > ? (199.212.134.1) at (incomplete) on em0 [ethernet] > ? (199.212.134.1) at (incomplete) on em0 [ethernet] > ? (199.212.134.1) at (incomplete) on em0 [ethernet] > ? (199.212.134.1) at (incomplete) on em0 [ethernet] > ? (199.212.134.1) at (incomplete) on em0 [ethernet] > ? (199.212.134.1) at (incomplete) on em0 [ethernet] > ? (199.212.134.1) at (incomplete) on em0 [ethernet] > ? (199.212.134.1) at (incomplete) on em0 [ethernet] > ? (199.212.134.1) at (incomplete) on em0 [ethernet] > ? (199.212.134.1) at (incomplete) on em0 [ethernet] > ? (199.212.134.1) at (incomplete) on em0 [ethernet] > > I will try a kernel before the em changes, as thats the only other thing > I can think of off the top of my head. That almost looks like some kind of ARP storm, sans repetitive entries (that definitely looks odd). Does tcpdump on em1 show a particular machine or router demanding MACs for 64.7.153.0/24 (or whatever the block is)? Adding Jack Vogel to this, since it could be em(4)-related. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Wed Aug 13 21:35:32 2008 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 428B41065672; Wed, 13 Aug 2008 21:35:32 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id E27958FC1D; Wed, 13 Aug 2008 21:35:31 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m7DLZTMP048890; Wed, 13 Aug 2008 17:35:29 -0400 (EDT) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.8/8.13.3) with ESMTP id m7DLZTeK039233 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Aug 2008 17:35:29 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <200808132135.m7DLZTeK039233@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 13 Aug 2008 17:35:21 -0400 To: Jeremy Chadwick From: Mike Tancsa In-Reply-To: <20080813212544.GA25915@eos.sc1.parodius.com> References: <200808120059.m7C0xvUH028011@lava.sentex.ca> <200808132034.m7DKY7wm038972@lava.sentex.ca> <7.1.0.9.0.20080813164157.161ba2e8@sentex.net> <200808132116.m7DLGY1f039165@lava.sentex.ca> <20080813212544.GA25915@eos.sc1.parodius.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: stable@FreeBSD.org, Robert Watson , Jack Vogel Subject: Re: HEADS UP: inpcb/inpcbinfo rwlocking: coming to a 7-STABLE branch near you X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2008 21:35:32 -0000 At 05:25 PM 8/13/2008, Jeremy Chadwick wrote: > > > > I will try a kernel before the em changes, as thats the only other thing > > I can think of off the top of my head. I commented out em from the kernel and loaded up a previous version via kld, but still the same thing, although not nearly as much 0[smtp2]# arp -na | wc 89 680 5081 0[smtp2]# em0@pci0:0:4:0: class=0x020000 card=0x387010f1 chip=0x10768086 rev=0x05 hdr=0x00 vendor = 'Intel Corporation' device = '82541EI Gigabit Ethernet Controller' class = network subclass = ethernet cap 01[dc] = powerspec 2 supports D0 D3 current D0 cap 07[e4] = PCI-X supports 2048 burst read, 1 split transaction em1@pci0:0:5:0: class=0x020000 card=0x387010f1 chip=0x10768086 rev=0x05 hdr=0x00 vendor = 'Intel Corporation' device = '82541EI Gigabit Ethernet Controller' class = network subclass = ethernet cap 01[dc] = powerspec 2 supports D0 D3 current D0 cap 07[e4] = PCI-X supports 2048 burst read, 1 split transaction >That almost looks like some kind of ARP storm, sans repetitive entries >(that definitely looks odd). Does tcpdump on em1 show a particular >machine or router demanding MACs for 64.7.153.0/24 (or whatever the >block is)? No, its very, very quiet. All the other machines on the 2 networks are just fine. Any suggestions on what kernel to go back to start from ? ---Mike From owner-freebsd-stable@FreeBSD.ORG Wed Aug 13 21:43:07 2008 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 00EF4106566C; Wed, 13 Aug 2008 21:43:07 +0000 (UTC) (envelope-from jdc@parodius.com) Received: from mx01.sc1.parodius.com (mx01.sc1.parodius.com [72.20.106.3]) by mx1.freebsd.org (Postfix) with ESMTP id E10D78FC17; Wed, 13 Aug 2008 21:43:06 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id B7E331CC0B9; Wed, 13 Aug 2008 14:43:06 -0700 (PDT) Date: Wed, 13 Aug 2008 14:43:06 -0700 From: Jeremy Chadwick To: Mike Tancsa Message-ID: <20080813214306.GA28953@eos.sc1.parodius.com> References: <200808120059.m7C0xvUH028011@lava.sentex.ca> <200808132034.m7DKY7wm038972@lava.sentex.ca> <7.1.0.9.0.20080813164157.161ba2e8@sentex.net> <200808132116.m7DLGY1f039165@lava.sentex.ca> <20080813212544.GA25915@eos.sc1.parodius.com> <200808132135.m7DLZTeK039233@lava.sentex.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200808132135.m7DLZTeK039233@lava.sentex.ca> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: stable@FreeBSD.org, Robert Watson , Jack Vogel Subject: Re: HEADS UP: inpcb/inpcbinfo rwlocking: coming to a 7-STABLE branch near you X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2008 21:43:07 -0000 On Wed, Aug 13, 2008 at 05:35:21PM -0400, Mike Tancsa wrote: > At 05:25 PM 8/13/2008, Jeremy Chadwick wrote: >> > >> > I will try a kernel before the em changes, as thats the only other thing >> > I can think of off the top of my head. > > I commented out em from the kernel and loaded up a previous version via > kld, but still the same thing, although not nearly as much > > 0[smtp2]# arp -na | wc > 89 680 5081 > 0[smtp2]# > > em0@pci0:0:4:0: class=0x020000 card=0x387010f1 chip=0x10768086 rev=0x05 > hdr=0x00 > vendor = 'Intel Corporation' > device = '82541EI Gigabit Ethernet Controller' > class = network > subclass = ethernet > cap 01[dc] = powerspec 2 supports D0 D3 current D0 > cap 07[e4] = PCI-X supports 2048 burst read, 1 split transaction > em1@pci0:0:5:0: class=0x020000 card=0x387010f1 chip=0x10768086 rev=0x05 > hdr=0x00 > vendor = 'Intel Corporation' > device = '82541EI Gigabit Ethernet Controller' > class = network > subclass = ethernet > cap 01[dc] = powerspec 2 supports D0 D3 current D0 > cap 07[e4] = PCI-X supports 2048 burst read, 1 split transaction > >> That almost looks like some kind of ARP storm, sans repetitive entries >> (that definitely looks odd). Does tcpdump on em1 show a particular >> machine or router demanding MACs for 64.7.153.0/24 (or whatever the >> block is)? > > No, its very, very quiet. All the other machines on the 2 networks are > just fine. > > Any suggestions on what kernel to go back to start from ? Seems relevant, and might give you some dates/revisions to roll back to for testing. Robert will have to confirm if some of the below commits could wreck havok -- I'm not familiar with the code, I just pay semi-close attention to the commits... :-) http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/if_ether.c -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Wed Aug 13 22:02:40 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9B79F106566B for ; Wed, 13 Aug 2008 22:02:40 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from hs-out-0708.google.com (hs-out-0708.google.com [64.233.178.251]) by mx1.freebsd.org (Postfix) with ESMTP id 53EAE8FC0C for ; Wed, 13 Aug 2008 22:02:40 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by hs-out-0708.google.com with SMTP id h53so198370hsh.11 for ; Wed, 13 Aug 2008 15:02:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type:content-transfer-encoding :content-disposition; bh=UfbT4E1kXNaIWvtZ/3IR4pL4S7DGEbFx7umg9OuPxQE=; b=XNztHBR8EoL6WJ1FOHE9MmJ2N8XQQ9a66vzck2ao/vFuZJFr85bEG3FKT68nw9F7go 00p/gMHOLMDz5jrlmhnMD5ev0sceRPRXu30LDUTYOAb/9Mp4RGdXSi1htpFGQGFsQyXm y5oNp+H9vNqf7krVhYJxcWQIc0e113dowEaVc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition; b=fH+CYDfri140wMYlsKFN9EaGUuPoXcFtcaIbqqOa3+bBY4E/GkQ/VrXOm4ZukmJMKt DrS8kbunmq42Whjn0b2X2vDbK2L1lBEE//YO6me88kLZFPth5IhrJToAn8v5QzNwXRnv I4jOUABBP01i11Po3WmqJcPzz2AxV8ZlzROBk= Received: by 10.90.94.12 with SMTP id r12mr521135agb.108.1218664943825; Wed, 13 Aug 2008 15:02:23 -0700 (PDT) Received: by 10.100.43.1 with HTTP; Wed, 13 Aug 2008 15:02:23 -0700 (PDT) Message-ID: <2a41acea0808131502y39879a22u39c472bd0b810fc2@mail.gmail.com> Date: Wed, 13 Aug 2008 15:02:23 -0700 From: "Jack Vogel" To: "FreeBSD Stable List" , "freebsd-net@freebsd.org" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Subject: HEADS UP: E1000 networking changes in STABLE/7.1 RELEASE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2008 22:02:40 -0000 There is a change that has been in the STABLE tree for a few months, but many might have missed it, its an important change to note and possibly for some prepare for with the 7.1 RELEASE. There is a new E1000 network driver, igb, which supports two family of adapters so far: the 82575 and the new 82576. In FreeBSD 7 the support for 82575 was in the em driver, however due to support issues across all the OS's we do drivers for, the decision was made to split the newer drivers off from those before. There are big differences in the register set, and in things like the descriptor format that made this expedient. I made the support for the 82575 available very early in FreeBSD, earlier even than Linux so that certain vendors could have a working driver early. At first I thought to avoid splitting the driver, but support issues are going to make that impractical. So there is a split, its been in HEAD since Febuary, and now 7.1 will release with this change. What this means is that if you have 82575 adapters in a system they are going to change from being 'emX' to being 'igbX', in the RELEASE the install kernel will have both drivers in it, but on an upgrade path, or using a set of scripts that get postinstalled you need to be ready to make this change. How can you tell if you have such a device: Simple, use pciconf, there are only 3 ID's that are effected: 0x10A7, 0x10A9, and 0x10D6. If you have questions feel free to email me. Cheers, Jack Vogel Intel Lan Access Division From owner-freebsd-stable@FreeBSD.ORG Wed Aug 13 22:22:40 2008 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9FB3E106567D; Wed, 13 Aug 2008 22:22:40 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 67E078FC0A; Wed, 13 Aug 2008 22:22:40 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id D745146BB1; Wed, 13 Aug 2008 18:22:39 -0400 (EDT) Date: Wed, 13 Aug 2008 23:22:39 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Mike Tancsa In-Reply-To: <200808132135.m7DLZTeK039233@lava.sentex.ca> Message-ID: References: <200808120059.m7C0xvUH028011@lava.sentex.ca> <200808132034.m7DKY7wm038972@lava.sentex.ca> <7.1.0.9.0.20080813164157.161ba2e8@sentex.net> <200808132116.m7DLGY1f039165@lava.sentex.ca> <20080813212544.GA25915@eos.sc1.parodius.com> <200808132135.m7DLZTeK039233@lava.sentex.ca> User-Agent: Alpine 1.10 (BSF 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Jeremy Chadwick , stable@FreeBSD.org, Jack Vogel Subject: Re: HEADS UP: inpcb/inpcbinfo rwlocking: coming to a 7-STABLE branch near you X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2008 22:22:40 -0000 On Wed, 13 Aug 2008, Mike Tancsa wrote: > At 05:25 PM 8/13/2008, Jeremy Chadwick wrote: >> > >> > I will try a kernel before the em changes, as thats the only other thing >> > I can think of off the top of my head. > > I commented out em from the kernel and loaded up a previous version via kld, > but still the same thing, although not nearly as much .... > No, its very, very quiet. All the other machines on the 2 networks are just > fine. > > Any suggestions on what kernel to go back to start from ? I'm concerned by the presence of multiple ARP entries for a single IP -- I'll need to reread the ARP code to refresh my memory, but in general I would expect to see at most one in-progress or complete ARP entry for any particular IP address at a time. To me, this suggests a bug -- perhaps a race condition or just a general logic bug. If rolling back fixes it, that is definitely interesting, but we can also debug this in the normal ways and see where it leads us. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-stable@FreeBSD.ORG Wed Aug 13 22:29:55 2008 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 825EF106567C; Wed, 13 Aug 2008 22:29:55 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 45CF48FC08; Wed, 13 Aug 2008 22:29:55 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m7DMTrHZ052544; Wed, 13 Aug 2008 18:29:53 -0400 (EDT) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.8/8.13.3) with ESMTP id m7DMTqUU039429 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Aug 2008 18:29:52 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <200808132229.m7DMTqUU039429@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 13 Aug 2008 18:29:45 -0400 To: Robert Watson From: Mike Tancsa In-Reply-To: References: <200808120059.m7C0xvUH028011@lava.sentex.ca> <200808132034.m7DKY7wm038972@lava.sentex.ca> <7.1.0.9.0.20080813164157.161ba2e8@sentex.net> <200808132116.m7DLGY1f039165@lava.sentex.ca> <20080813212544.GA25915@eos.sc1.parodius.com> <200808132135.m7DLZTeK039233@lava.sentex.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Jeremy Chadwick , stable@FreeBSD.org, Jack Vogel Subject: Re: HEADS UP: inpcb/inpcbinfo rwlocking: coming to a 7-STABLE branch near you X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2008 22:29:55 -0000 At 06:22 PM 8/13/2008, Robert Watson wrote: >>Any suggestions on what kernel to go back to start from ? > >I'm concerned by the presence of multiple ARP entries for a single >IP -- I'll need to reread the ARP code to refresh my memory, but in >general I would expect to see at most one in-progress or complete >ARP entry for any particular IP address at a time. To me, this >suggests a bug -- perhaps a race condition or just a general logic >bug. If rolling back fixes it, that is definitely interesting, but >we can also debug this in the normal ways and see where it leads us. I am just doing a full buildworld/buildkernel after doing an rm -R /usr/obj to make sure a stable from today is indeed the issue, and then I will jump back a month or so ? What can I do to track down the issue ? The incomplete addresses correspond to hosts where most traffic is directed. ---Mike From owner-freebsd-stable@FreeBSD.ORG Thu Aug 14 02:04:10 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BE316106568D for ; Thu, 14 Aug 2008 02:04:10 +0000 (UTC) (envelope-from spomerg@cwu.EDU) Received: from scylla.cts.cwu.edu (scylla.cts.cwu.edu [198.104.67.151]) by mx1.freebsd.org (Postfix) with ESMTP id 892538FC15 for ; Thu, 14 Aug 2008 02:04:10 +0000 (UTC) (envelope-from spomerg@cwu.EDU) Received: from CONVERSION-CWU-DAEMON.SCYLLA.CTS.CWU.EDU by SCYLLA.CTS.CWU.EDU (PMDF V6.4 #31640) id <01MYBGUQHELS0006A6@SCYLLA.CTS.CWU.EDU> for freebsd-stable@freebsd.org; Wed, 13 Aug 2008 17:35:37 -0700 (PDT) Received: from hermes.cwu.edu (hermes.cwu.edu [172.16.21.28]) by SCYLLA.CTS.CWU.EDU (PMDF V6.4 #31640) with ESMTP id <01MYBGUNV8HC0005L1@SCYLLA.CTS.CWU.EDU> for freebsd-stable@freebsd.org; Wed, 13 Aug 2008 17:35:34 -0700 (PDT) Received: from cwugate1-MTA by hermes.cwu.edu with Novell_GroupWise; Wed, 13 Aug 2008 17:35:33 -0700 Date: Wed, 13 Aug 2008 17:35:29 -0700 From: Gavin Spomer To: freebsd-stable@freebsd.org Message-id: <48A31B61020000900001C109@hermes.cwu.edu> MIME-version: 1.0 X-Mailer: Novell GroupWise Internet Agent 7.0.3 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable Content-disposition: inline Subject: ssh-keygen between SuSE and FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2008 02:04:10 -0000 I hope this isn't an invalid topic for this list. I'm on so many lists and = I hate to join another one just to get help on one thing. Apologies if = it's not. I am able to use ssh-keygen to generate keys so that I can ssh from my Mac = to any of my SuSE systems or ssh from my Mac to any of my FreeBSD systems, = without having to enter my password. When I try the same thing from a SuSE = system to a FreeBSD system, (I.E. I run "ssh-keygen -t rsa" on the SuSE = system, then copy the id_rsa.pub to my ~/.ssh/authorized_keys file on the = FreeBSD system) I get the following message when ssh-ing to the FreeBSD = system: Enter passphrase for key '/home/myusername/.ssh/id_rsa': ... and I have to enter my password. I've Googled, but can't seem to find = the answer to my dilemma. Is it generally kind of a pain to do this = between platforms? I'm finally very comfortable on FreeBSD and am starting = to really get annoyed with SuSE. :( - Gavin From owner-freebsd-stable@FreeBSD.ORG Thu Aug 14 02:10:23 2008 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 45068106567F; Thu, 14 Aug 2008 02:10:23 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 086778FC1A; Thu, 14 Aug 2008 02:10:22 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m7E2AKtL068231; Wed, 13 Aug 2008 22:10:20 -0400 (EDT) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.8/8.13.3) with ESMTP id m7E2AK1V040232 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Aug 2008 22:10:20 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <200808140210.m7E2AK1V040232@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 13 Aug 2008 22:10:09 -0400 To: Robert Watson From: Mike Tancsa In-Reply-To: References: <200808120059.m7C0xvUH028011@lava.sentex.ca> <200808132034.m7DKY7wm038972@lava.sentex.ca> <7.1.0.9.0.20080813164157.161ba2e8@sentex.net> <200808132116.m7DLGY1f039165@lava.sentex.ca> <20080813212544.GA25915@eos.sc1.parodius.com> <200808132135.m7DLZTeK039233@lava.sentex.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Jeremy Chadwick , stable@FreeBSD.org Subject: Re: HEADS UP: inpcb/inpcbinfo rwlocking: coming to a 7-STABLE branch near you X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2008 02:10:23 -0000 At 06:22 PM 8/13/2008, Robert Watson wrote: >I'm concerned by the presence of multiple ARP entries for a single >IP -- I'll need to reread the ARP code to refresh my memory, but in >general I would expect to see at most one in-progress or complete >ARP entry for any particular IP address at a time. To me, this >suggests a bug -- perhaps a race condition or just a general logic >bug. If rolling back fixes it, that is definitely interesting, but >we can also debug this in the normal ways and see where it leads us. I blew away /usr/src and /usr/obj and did a full buildworld, buildkernel with date=2008.07.01.00.00.00 in my cvsup file 2008-07-01, all OK 2008-07-13, all OK 2008-07-25, all OK 2008-08-01, 'blammo' So sometime between the 25th and aug1. Just going to try and narrow it down some more. ---Mike From owner-freebsd-stable@FreeBSD.ORG Thu Aug 14 02:31:01 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1A8E11065670 for ; Thu, 14 Aug 2008 02:31:01 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id 84FFA8FC0A for ; Thu, 14 Aug 2008 02:31:00 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (inchoate.gsoft.com.au [203.31.81.30]) (authenticated bits=0) by cain.gsoft.com.au (8.13.8/8.13.8) with ESMTP id m7E2UwJm024714 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 14 Aug 2008 12:00:59 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: "Manjunath Ranganathaiah" Date: Thu, 14 Aug 2008 12:00:49 +0930 User-Agent: KMail/1.9.7 References: <200808121734.30144.doconnor@gsoft.com.au> <200808132055.56039.doconnor@gsoft.com.au> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3167185.cvn0rAETE8"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200808141200.56643.doconnor@gsoft.com.au> X-Spam-Score: -3.977 () ALL_TRUSTED,BAYES_00 X-Scanned-By: MIMEDefang 2.63 on 203.31.81.10 Cc: freebsd-stable@freebsd.org Subject: Re: 6.3 (ish) hang on reboot w/ Supermicro C2SBA+ X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2008 02:31:01 -0000 --nextPart3167185.cvn0rAETE8 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thu, 14 Aug 2008, Manjunath Ranganathaiah wrote: > > I tried the former (put it in loader.conf right?) and it made no > > difference. I'll try disabling ACPI tomorrow (I tried it remotely > > so it's hung now :) > > Yes, look at acpi man page for details. Yup, just double checking.. Actually there is one thing different.. It printed.. Uptime: 6m27s 1 I tried disabling ACPI altogether but the system doesn't boot :( I get a lot of.. interrupt storm detected on "irq5:"; throttling interrupt source It is interspersed with twa controller resets. =46WIW I can reset it by calling cpu_reset() from withing a KLD. =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart3167185.cvn0rAETE8 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iD8DBQBIo5jg5ZPcIHs/zowRAsL8AJ9/CNdatHOABL5iCpcZVbN1VjlqswCeMhBS gooF3Ty1WPIDFNtsguuvD+A= =QZnf -----END PGP SIGNATURE----- --nextPart3167185.cvn0rAETE8-- From owner-freebsd-stable@FreeBSD.ORG Thu Aug 14 02:42:18 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D9C49106566B for ; Thu, 14 Aug 2008 02:42:18 +0000 (UTC) (envelope-from pschmehl_lists@tx.rr.com) Received: from cdptpa-omtalb.mail.rr.com (cdptpa-omtalb.mail.rr.com [75.180.132.122]) by mx1.freebsd.org (Postfix) with ESMTP id A28828FC0A for ; Thu, 14 Aug 2008 02:42:18 +0000 (UTC) (envelope-from pschmehl_lists@tx.rr.com) Received: from [192.168.2.102] (really [24.175.90.48]) by cdptpa-omta04.mail.rr.com with ESMTP id <20080814021759.BLYL13299.cdptpa-omta04.mail.rr.com@[192.168.2.102]>; Thu, 14 Aug 2008 02:17:59 +0000 Date: Wed, 13 Aug 2008 21:17:58 -0500 From: Paul Schmehl To: Gavin Spomer , freebsd-stable@freebsd.org Message-ID: In-Reply-To: <48A31B61020000900001C109@hermes.cwu.edu> References: <48A31B61020000900001C109@hermes.cwu.edu> X-Mailer: Mulberry/4.0.8 (Mac OS X) X-Munged-Reply-To: To reply - figure it out MIME-Version: 1.0 Content-Type: multipart/signed; micalg=sha1; protocol="application/pkcs7-signature"; boundary="==========90999CB7B16A01AA3C3E==========" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: ssh-keygen between SuSE and FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Paul Schmehl List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2008 02:42:18 -0000 --==========90999CB7B16A01AA3C3E========== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline --On August 13, 2008 5:35:29 PM -0700 Gavin Spomer = wrote: > I hope this isn't an invalid topic for this list. I'm on so many lists > and I hate to join another one just to get help on one thing. Apologies > if it's not. > > I am able to use ssh-keygen to generate keys so that I can ssh from my > Mac to any of my SuSE systems or ssh from my Mac to any of my FreeBSD > systems, without having to enter my password. When I try the same thing > from a SuSE system to a FreeBSD system, (I.E. I run "ssh-keygen -t rsa" > on the SuSE system, then copy the id_rsa.pub to my > ~/.ssh/authorized_keys file on the FreeBSD system) I get the following > message when ssh-ing to the FreeBSD system: > > Enter passphrase for key '/home/myusername/.ssh/id_rsa': > > ... and I have to enter my password. I've Googled, but can't seem to > find the answer to my dilemma. Is it generally kind of a pain to do this > between platforms? I'm finally very comfortable on FreeBSD and am > starting to really get annoyed with SuSE. :( > Just to be clear....you're saying that your key pass*phrase* doesn't work=20 and you have to type your pass*word* in instead? Or did you make all your = previous keys passphrase-less and add a passphrase to this one? Paul Schmehl, If it isn't already obvious, my opinions are my own and not those of my employer. ****************************************** WARNING: Check the headers before replying --==========90999CB7B16A01AA3C3E==========-- From owner-freebsd-stable@FreeBSD.ORG Thu Aug 14 02:47:09 2008 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3FA23106567A; Thu, 14 Aug 2008 02:47:09 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 081E08FC17; Thu, 14 Aug 2008 02:47:08 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m7E2l6BI070961; Wed, 13 Aug 2008 22:47:06 -0400 (EDT) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.8/8.13.3) with ESMTP id m7E2l5ft040358 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Aug 2008 22:47:05 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <200808140247.m7E2l5ft040358@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 13 Aug 2008 22:46:58 -0400 To: Robert Watson From: Mike Tancsa In-Reply-To: References: <200808120059.m7C0xvUH028011@lava.sentex.ca> <200808132034.m7DKY7wm038972@lava.sentex.ca> <7.1.0.9.0.20080813164157.161ba2e8@sentex.net> <200808132116.m7DLGY1f039165@lava.sentex.ca> <20080813212544.GA25915@eos.sc1.parodius.com> <200808132135.m7DLZTeK039233@lava.sentex.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Jeremy Chadwick , stable@freebsd.org, Jack Vogel Subject: Re: HEADS UP: inpcb/inpcbinfo rwlocking: coming to a 7-STABLE branch near you X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2008 02:47:09 -0000 At 06:22 PM 8/13/2008, Robert Watson wrote: >I'm concerned by the presence of multiple ARP entries for a single >IP -- I'll need to reread the ARP code to refresh my memory, but in >general I would expect to see at most one in-progress or complete >ARP entry for any particular IP address at a time. To me, this >suggests a bug -- perhaps a race condition or just a general logic >bug. If rolling back fixes it, that is definitely interesting, but >we can also debug this in the normal ways and see where it leads us. It seems to be on the 31st and one of the commits below that causes the problem. I am bcc'ing the people below. Original problem description at http://lists.freebsd.org/pipermail/freebsd-stable/2008-August/044373.html I originally thought it to be an issue with Robert's patch, but it appears instead to be related to one of the commits below. Updating collection src-all/cvs Edit src/sys/conf/files Add delta 1.1243.2.32 2008.07.30.20.35.41 kmacy Edit src/sys/contrib/rdma/core_priv.h Add delta 1.1.2.1 2008.07.30.00.27.48 kmacy Edit src/sys/contrib/rdma/ib_addr.h Add delta 1.1.2.1 2008.07.30.00.27.48 kmacy Edit src/sys/contrib/rdma/ib_cache.h Add delta 1.1.2.1 2008.07.30.00.27.48 kmacy Edit src/sys/contrib/rdma/ib_cm.h Add delta 1.1.2.1 2008.07.30.00.27.48 kmacy Edit src/sys/contrib/rdma/ib_fmr_pool.h Add delta 1.1.2.1 2008.07.30.00.27.48 kmacy Edit src/sys/contrib/rdma/ib_mad.h Add delta 1.1.2.1 2008.07.30.00.27.48 kmacy Edit src/sys/contrib/rdma/ib_marshall.h Add delta 1.1.2.1 2008.07.30.00.27.48 kmacy Edit src/sys/contrib/rdma/ib_pack.h Add delta 1.1.2.1 2008.07.30.00.27.48 kmacy Edit src/sys/contrib/rdma/ib_sa.h Add delta 1.1.2.1 2008.07.30.00.27.48 kmacy Edit src/sys/contrib/rdma/ib_smi.h Add delta 1.1.2.1 2008.07.30.00.27.48 kmacy Edit src/sys/contrib/rdma/ib_umem.h Add delta 1.1.2.1 2008.07.30.00.27.48 kmacy Edit src/sys/contrib/rdma/ib_user_cm.h Add delta 1.1.2.1 2008.07.30.00.27.48 kmacy Edit src/sys/contrib/rdma/ib_user_mad.h Add delta 1.1.2.1 2008.07.30.00.27.48 kmacy Edit src/sys/contrib/rdma/ib_user_sa.h Add delta 1.1.2.1 2008.07.30.00.27.48 kmacy Edit src/sys/contrib/rdma/ib_user_verbs.h Add delta 1.1.2.1 2008.07.30.00.27.48 kmacy Edit src/sys/contrib/rdma/ib_verbs.h Add delta 1.1.2.1 2008.07.30.00.27.48 kmacy Edit src/sys/contrib/rdma/iw_cm.h Add delta 1.1.2.1 2008.07.30.00.27.48 kmacy Edit src/sys/contrib/rdma/krping/getopt.c Add delta 1.1.2.1 2008.07.30.00.27.48 kmacy Edit src/sys/contrib/rdma/krping/getopt.h Add delta 1.1.2.1 2008.07.30.00.27.48 kmacy Edit src/sys/contrib/rdma/krping/krping.c Add delta 1.2.2.1 2008.07.30.00.27.48 kmacy Edit src/sys/contrib/rdma/krping/krping.h Add delta 1.1.2.1 2008.07.30.00.27.48 kmacy Edit src/sys/contrib/rdma/krping/krping_dev.c Add delta 1.1.2.1 2008.07.30.00.27.48 kmacy Edit src/sys/contrib/rdma/rdma_addr.c Add delta 1.1.2.1 2008.07.30.00.27.48 kmacy Edit src/sys/contrib/rdma/rdma_cache.c Add delta 1.1.2.1 2008.07.30.00.27.48 kmacy Edit src/sys/contrib/rdma/rdma_cm.h Add delta 1.1.2.1 2008.07.30.00.27.48 kmacy Edit src/sys/contrib/rdma/rdma_cm_ib.h Add delta 1.1.2.1 2008.07.30.00.27.48 kmacy Edit src/sys/contrib/rdma/rdma_cma.c Add delta 1.1.2.1 2008.07.30.00.27.48 kmacy Edit src/sys/contrib/rdma/rdma_device.c Add delta 1.1.2.1 2008.07.30.00.27.48 kmacy Edit src/sys/contrib/rdma/rdma_iwcm.c Add delta 1.1.2.1 2008.07.30.00.27.48 kmacy Edit src/sys/contrib/rdma/rdma_user_cm.h Add delta 1.1.2.1 2008.07.30.00.27.48 kmacy Edit src/sys/contrib/rdma/rdma_verbs.c Add delta 1.1.2.1 2008.07.30.00.27.48 kmacy Edit src/sys/contrib/rdma/types.h Add delta 1.2.2.1 2008.07.30.00.27.48 kmacy Checkout src/sys/dev/e1000/LICENSE Checkout src/sys/dev/e1000/README Checkout src/sys/dev/e1000/e1000_80003es2lan.c Checkout src/sys/dev/e1000/e1000_80003es2lan.h Checkout src/sys/dev/e1000/e1000_82540.c Checkout src/sys/dev/e1000/e1000_82541.c Checkout src/sys/dev/e1000/e1000_82541.h Checkout src/sys/dev/e1000/e1000_82542.c Checkout src/sys/dev/e1000/e1000_82543.c Checkout src/sys/dev/e1000/e1000_82543.h Checkout src/sys/dev/e1000/e1000_82571.c Checkout src/sys/dev/e1000/e1000_82571.h Checkout src/sys/dev/e1000/e1000_82575.c Checkout src/sys/dev/e1000/e1000_82575.h Checkout src/sys/dev/e1000/e1000_api.c Checkout src/sys/dev/e1000/e1000_api.h Checkout src/sys/dev/e1000/e1000_defines.h Checkout src/sys/dev/e1000/e1000_hw.h Checkout src/sys/dev/e1000/e1000_ich8lan.c Checkout src/sys/dev/e1000/e1000_ich8lan.h Checkout src/sys/dev/e1000/e1000_mac.c Checkout src/sys/dev/e1000/e1000_mac.h Checkout src/sys/dev/e1000/e1000_manage.c Checkout src/sys/dev/e1000/e1000_manage.h Checkout src/sys/dev/e1000/e1000_nvm.c Checkout src/sys/dev/e1000/e1000_nvm.h Checkout src/sys/dev/e1000/e1000_osdep.c Checkout src/sys/dev/e1000/e1000_osdep.h Checkout src/sys/dev/e1000/e1000_phy.c Checkout src/sys/dev/e1000/e1000_phy.h Checkout src/sys/dev/e1000/e1000_regs.h Checkout src/sys/dev/e1000/if_em.c Checkout src/sys/dev/e1000/if_em.h Checkout src/sys/dev/e1000/if_igb.h Edit src/sys/kern/kern_fork.c Add delta 1.282.2.5 2008.07.30.09.44.40 kib Edit src/sys/kern/kern_synch.c Add delta 1.302.2.3 2008.07.30.18.28.09 rwatson Edit src/sys/kern/sys_process.c Add delta 1.145.2.1 2008.07.30.19.49.10 jhb Edit src/sys/kern/vfs_aio.c Add delta 1.233.2.2 2008.07.30.13.19.50 rwatson Edit src/sys/net/bpf.c Add delta 1.181.2.7 2008.07.30.14.04.01 rwatson Edit src/sys/net/if.c Add delta 1.273.2.4 2008.07.30.17.27.10 rwatson Edit src/sys/net/if.h Add delta 1.108.2.3 2008.07.30.00.17.40 kmacy Edit src/sys/net/if_ethersubr.c Add delta 1.236.2.4 2008.07.30.17.27.10 rwatson Edit src/sys/netinet/in_pcb.h Add delta 1.100.2.3 2008.07.30.00.18.32 kmacy Edit src/sys/netinet/tcp_offload.c Add delta 1.4.2.1 2008.07.30.00.09.15 kmacy Edit src/sys/netinet/tcp_offload.h Add delta 1.5.2.1 2008.07.30.00.09.15 kmacy Edit src/sys/netinet/tcp_subr.c Add delta 1.300.2.4 2008.07.30.20.35.41 kmacy Edit src/sys/netinet/tcp_syncache.c Add delta 1.130.2.9 2008.07.30.20.35.41 kmacy Add delta 1.130.2.10 2008.07.30.20.51.20 kmacy Edit src/sys/netinet/tcp_syncache.h Add delta 1.1.2.1 2008.07.30.20.35.41 kmacy Edit src/sys/netinet/tcp_usrreq.c Add delta 1.163.2.4 2008.07.30.20.35.41 kmacy Edit src/sys/netinet/tcp_var.h Add delta 1.157.2.4 2008.07.30.00.20.04 kmacy Edit src/sys/netinet/toedev.h Add delta 1.5.2.1 2008.07.30.00.16.37 kmacy Edit src/sys/netinet/udp_usrreq.c Add delta 1.218.2.1 2008.07.30.21.23.21 bz Edit src/sys/netinet6/ip6_input.c Add delta 1.95.2.1 2008.07.30.21.23.21 bz Edit src/sys/netinet6/ip6_var.h Add delta 1.39.2.2 2008.07.30.21.23.21 bz Edit src/sys/sys/socket.h Add delta 1.95.2.3 2008.07.30.19.35.40 kmacy Edit src/sys/ufs/ufs/ufs_lookup.c Add delta 1.83.2.2 2008.07.30.21.43.42 jhb Edit src/sys/vm/vm_object.c Add delta 1.385.2.2 2008.07.30.21.43.42 jhb Edit src/sys/vm/vm_object.h Add delta 1.114.2.1 2008.07.30.21.43.42 jhb Edit src/sys/vm/vnode_pager.c Add delta 1.236.2.2 2008.07.30.21.43.42 jhb Edit src/usr.bin/ldd/ldd.c Add delta 1.33.24.2 2008.07.30.03.33.49 edwin From owner-freebsd-stable@FreeBSD.ORG Thu Aug 14 02:55:25 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BD89C106567B for ; Thu, 14 Aug 2008 02:55:25 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id 330B68FC18 for ; Thu, 14 Aug 2008 02:55:24 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (inchoate.gsoft.com.au [203.31.81.30]) (authenticated bits=0) by cain.gsoft.com.au (8.13.8/8.13.8) with ESMTP id m7E2tNsn025395 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 14 Aug 2008 12:25:23 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: "Manjunath Ranganathaiah" Date: Thu, 14 Aug 2008 12:25:08 +0930 User-Agent: KMail/1.9.7 References: <200808121734.30144.doconnor@gsoft.com.au> <200808141200.56643.doconnor@gsoft.com.au> In-Reply-To: <200808141200.56643.doconnor@gsoft.com.au> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart11618063.TGKuq18kiy"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200808141225.21321.doconnor@gsoft.com.au> X-Spam-Score: -3.977 () ALL_TRUSTED,BAYES_00 X-Scanned-By: MIMEDefang 2.63 on 203.31.81.10 Cc: freebsd-stable@freebsd.org Subject: Re: 6.3 (ish) hang on reboot w/ Supermicro C2SBA+ (fixed) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2008 02:55:25 -0000 --nextPart11618063.TGKuq18kiy Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thu, 14 Aug 2008, Daniel O'Connor wrote: > On Thu, 14 Aug 2008, Manjunath Ranganathaiah wrote: > > > I tried the former (put it in loader.conf right?) and it made no > > > difference. I'll try disabling ACPI tomorrow (I tried it remotely > > > so it's hung now :) > > > > Yes, look at acpi man page for details. > > Yup, just double checking.. > > Actually there is one thing different.. It printed.. > > Uptime: 6m27s > 1 > > I tried disabling ACPI altogether but the system doesn't boot :( > I get a lot of.. > interrupt storm detected on "irq5:"; throttling interrupt source I found that there was a recent BIOS update and that appears to have=20 fixed the problem (as well as the ACPI spam I was getting during module=20 probes). Thanks. =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart11618063.TGKuq18kiy Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iD8DBQBIo56Y5ZPcIHs/zowRAv5xAJ9rZqR57U1Gtgs8qYsIemYgrae8MQCgkR3o 5Fp+IWanX/gSqYaYcpi9XZc= =SXOV -----END PGP SIGNATURE----- --nextPart11618063.TGKuq18kiy-- From owner-freebsd-stable@FreeBSD.ORG Thu Aug 14 03:40:51 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EF498106564A for ; Thu, 14 Aug 2008 03:40:51 +0000 (UTC) (envelope-from oberman@es.net) Received: from postal1.es.net (postal4.es.net [198.124.252.66]) by mx1.freebsd.org (Postfix) with ESMTP id A04288FC0A for ; Thu, 14 Aug 2008 03:40:51 +0000 (UTC) (envelope-from oberman@es.net) Received: from ptavv.es.net (ptavv.es.net [198.128.4.29]) by postal4.es.net (Postal Node 4) with ESMTP (SSL) id ULC88050; Wed, 13 Aug 2008 20:40:50 -0700 Received: from ptavv.es.net (ptavv.es.net [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id CC8304500F; Wed, 13 Aug 2008 20:40:49 -0700 (PDT) To: Gavin Spomer In-Reply-To: Your message of "Wed, 13 Aug 2008 17:35:29 PDT." <48A31B61020000900001C109@hermes.cwu.edu> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_1218685249_34728P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Wed, 13 Aug 2008 20:40:49 -0700 From: "Kevin Oberman" Message-Id: <20080814034049.CC8304500F@ptavv.es.net> Cc: freebsd-stable@freebsd.org Subject: Re: ssh-keygen between SuSE and FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2008 03:40:52 -0000 --==_Exmh_1218685249_34728P Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Format recovered. A newline every 72-75 characters would be more polite. > Date: Wed, 13 Aug 2008 17:35:29 -0700 > From: Gavin Spomer > Sender: owner-freebsd-stable@freebsd.org > > I hope this isn't an invalid topic for this list. I'm on so many lists > and I hate to join another one just to get help on one > thing. Apologies if it's not. > > I am able to use ssh-keygen to generate keys so that I can ssh from my > Mac to any of my SuSE systems or ssh from my Mac to any of my FreeBSD > systems, without having to enter my password. When I try the same > thing from a SuSE system to a FreeBSD system, (I.E. I run "ssh-keygen > -t rsa" on the SuSE system, then copy the id_rsa.pub to my > ~/.ssh/authorized_keys file on the FreeBSD system) I get the following > message when ssh-ing to the FreeBSD system: > > Enter passphrase for key '/home/myusername/.ssh/id_rsa': > > ... and I have to enter my password. I've Googled, but can't seem to > find the answer to my dilemma. Is it generally kind of a pain to do > this between platforms? I'm finally very comfortable on FreeBSD and am > starting to really get annoyed with SuSE. :( It's not asking for your password. It's asking for your passphrase to decrypt your private key. Are you running an ssh-agent on the Suse system? If this does not point you in the right direction, try running ssh -v. This MAY give us an idea of the problem, though the debug data from the server would be better. MacOS X uses the FreeBSD user environment, so it should work the same under FreeBSD as it does on the Mac. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 --==_Exmh_1218685249_34728P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) Comment: Exmh version 2.5 06/03/2002 iD8DBQFIo6lBkn3rs5h7N1ERAoPmAJ98h+LTv0LDFZbehueghQG1XhValgCfdzEo 4+cXmwhLfzEJOXBOPbjrVQI= =tmpn -----END PGP SIGNATURE----- --==_Exmh_1218685249_34728P-- From owner-freebsd-stable@FreeBSD.ORG Thu Aug 14 04:35:45 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4BC3C1065676 for ; Thu, 14 Aug 2008 04:35:45 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from hs-out-0708.google.com (hs-out-0708.google.com [64.233.178.242]) by mx1.freebsd.org (Postfix) with ESMTP id 012928FC12 for ; Thu, 14 Aug 2008 04:35:44 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by hs-out-0708.google.com with SMTP id h53so379484hsh.11 for ; Wed, 13 Aug 2008 21:35:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=10D+RdUaxPgTGfF/B8pCJkjUkk4L1pAcYrEwZgv/VHc=; b=d9gX0bwpMfPvETaQbfTfNkK2K2Ma6hPEaVfSIuMlUHwGz5xIaqDGo0s31h3ABhfcx8 BBMbA75DgFhuy+eUso4z5pcbpGKWFx69mwKOsbYaj4SvQKE2CHeiFsT6U8ZrXh4Xt8fy OtrsHJ2BJc2UXnaPCWiAyEfPTLlltl7gXCk6A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=PgEUVwT39P6qVVa2ISi/BSi9A76ouctfYsHI2siE48F/6nZzcrTOWqbJWT20te8HLT 9xtNVWFrB1gApYbgaIFabUPZ2VHdBvMFXrBDAJhEnkxuncWfkS3+A4jOkBBidImANljj 42ptGwmEF0/cZN6N8R2R3/3IYCfNbO1FWyg4k= Received: by 10.90.92.14 with SMTP id p14mr1076466agb.84.1218688544256; Wed, 13 Aug 2008 21:35:44 -0700 (PDT) Received: by 10.100.43.1 with HTTP; Wed, 13 Aug 2008 21:35:44 -0700 (PDT) Message-ID: <2a41acea0808132135oe9ebc6bk9423ac19f2e9f77a@mail.gmail.com> Date: Wed, 13 Aug 2008 21:35:44 -0700 From: "Jack Vogel" To: Paul In-Reply-To: <48A3A2DA.8030404@gtcomm.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <2a41acea0808131502y39879a22u39c472bd0b810fc2@mail.gmail.com> <48A3A2DA.8030404@gtcomm.net> Cc: "freebsd-net@freebsd.org" , FreeBSD Stable List Subject: Re: HEADS UP: E1000 networking changes in STABLE/7.1 RELEASE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2008 04:35:45 -0000 On Wed, Aug 13, 2008 at 8:13 PM, Paul wrote: > Hi Jack. Will the em driver ever support the multiple hardware queues of > the 82571 or are we just stuck with the standard em driver? > Has there been any significant change in the em driver itself ? > I have a feeling that the 82571 should be in the igb driver but for some > reason it isn't. I am curious because we have a LOT of 4 port 82571 PCI-E > cards and they are not cheap. :] Hey Paul, You are right, quad port cards aren't cheap, Intel has sold them even back in a PCI-X based system. And the one you are talking about was released since I have been in this job, so pretty new :) However, they will never support multiple queues, the reason being that in order to do this you need multple MSI vectors, in other words, MSIX. Still, they are very handy, they do support MSI, but just one per interface. Oh, and I debated about where to make the cutoff line on the em/igb split and decided the best thing to do was to follow Linux. The biggest difference between the two drivers is that those in the igb use a different descriptor format, called 'advanced descriptors'. The split does NOT mean that em is now fixed. Quite the contrary, the em driver that was just MFC'd into STABLE has support for what I think is going to be the coolest new consumer adapter out there, called 82574, code name Hartwell, and also for ICH10. Both these two new interfaces have IEEE 1588 Precision Time Protocol support, something that is becoming important for networked multimedia applications. Oh, and Hartwell is the first adapter in the em driver that actually does multiqueue, although in a limited fashion, it does MSIX. This adapter is made at a lower cost point, but it has really nice features. I only wish the new motherboard that I bought had them rather than ICH9 but oh well :) I predict they are going to be selling like hotcakes before the end of year. I will continue to share fixes between the em and igb drivers as they are applicable. I still think a real legacy driver for the oldest adapters would be a good idea, just so they don't get broken by new development, with as many as we support regression testing is already not being done adequately. I just have not had time to think about this yet, it may be coming, it would probably be for everything that was not PCI Express. Hope the info was helpful, I'm always happy to answer questions, Jack From owner-freebsd-stable@FreeBSD.ORG Thu Aug 14 06:47:03 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4F8821065682 for ; Thu, 14 Aug 2008 06:47:03 +0000 (UTC) (envelope-from gerrit@pmp.uni-hannover.de) Received: from mrelay1.uni-hannover.de (mrelay1.uni-hannover.de [130.75.2.106]) by mx1.freebsd.org (Postfix) with ESMTP id B3C918FC1C for ; Thu, 14 Aug 2008 06:47:02 +0000 (UTC) (envelope-from gerrit@pmp.uni-hannover.de) Received: from www.pmp.uni-hannover.de (www.pmp.uni-hannover.de [130.75.117.2]) by mrelay1.uni-hannover.de (8.14.2/8.14.2) with ESMTP id m7E6kbMA009966; Thu, 14 Aug 2008 08:46:39 +0200 Received: from pmp.uni-hannover.de (arc.pmp.uni-hannover.de [130.75.117.1]) by www.pmp.uni-hannover.de (Postfix) with SMTP id 244054F; Thu, 14 Aug 2008 08:46:37 +0200 (CEST) Date: Thu, 14 Aug 2008 08:46:37 +0200 From: Gerrit =?ISO-8859-1?Q?K=FChn?= To: d@delphij.net Message-Id: <20080814084637.97997c02.gerrit@pmp.uni-hannover.de> In-Reply-To: <489B7D62.4080606@delphij.net> References: <20080807132947.061d24eb.gerrit@pmp.uni-hannover.de> <489B7D62.4080606@delphij.net> Organization: Albert-Einstein-Institut (MPI =?ISO-8859-1?Q?f=FCr?= Gravitationsphysik & IGP =?ISO-8859-1?Q?Universit=E4t?= Hannover) X-Mailer: Sylpheed 2.4.8 (GTK+ 2.12.11; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-PMX-Version: 5.4.1.325704, Antispam-Engine: 2.6.0.325393, Antispam-Data: 2008.8.14.63118 Cc: freebsd-stable@freebsd.org Subject: Re: Regression 7.0R -> 7-stable? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2008 06:47:03 -0000 On Thu, 07 Aug 2008 15:55:30 -0700 Xin LI wrote about Re: Regression 7.0R -> 7-stable?: XL> Could you please try disabling ACPI and boot? Additionally a 'boot - XL> v' may reveal some useful information as well. Just some random XL> thoughts. Disabling ACPI does not help, either (forgot to mention that earlier, sorry). I will post a boot -v log as soon as I have a working 7.0R on the system again. cu Gerrit From owner-freebsd-stable@FreeBSD.ORG Thu Aug 14 07:30:06 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 80C531065677 for ; Thu, 14 Aug 2008 07:30:06 +0000 (UTC) (envelope-from css@alkar.net) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id E672F8FC0A for ; Thu, 14 Aug 2008 07:30:05 +0000 (UTC) (envelope-from css@alkar.net) Received: from while.alkar.net (account css@alkar.net [212.86.226.7] verified) by cmail.optima.ua (CommuniGate Pro SMTP 5.1.14) with ESMTPA id 194503375 for freebsd-stable@freebsd.org; Thu, 14 Aug 2008 09:30:01 +0300 Date: Thu, 14 Aug 2008 09:30:00 +0300 From: Sergey Chumakov To: freebsd-stable@freebsd.org Message-ID: <20080814093000.4842b37c@while.alkar.net> Organization: Optima Telecom ISP X-Mailer: Claws Mail 3.5.0 (GTK+ 2.12.11; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Process size. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2008 07:30:06 -0000 Hello, FreeBSD 7.0-RELEASE-p3 #3 $top ... PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 36032 root 2838 44 0 1917M 1493M ucond 0 406:39 3.03% CGServer ... $cat /boot/loader.conf.local ... kern.maxdsiz="1073741824" kern.maxssiz="134217728" kern.dfldsiz="1073741824" $limits Resource limits (current): ... datasize 1048576 kB stacksize 131072 kB How and why is it possible for process to grow up to 1493M and even more? I suppose, it will be able to eat all available system memory (was killed). Thank you for answers. -- Sincerely, Sergey Chumakov From owner-freebsd-stable@FreeBSD.ORG Thu Aug 14 07:34:30 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D3B981065742 for ; Thu, 14 Aug 2008 07:34:30 +0000 (UTC) (envelope-from eugen@kuzbass.ru) Received: from www.svzserv.kemerovo.su (www.svzserv.kemerovo.su [213.184.65.80]) by mx1.freebsd.org (Postfix) with ESMTP id 148168FC0A for ; Thu, 14 Aug 2008 07:34:29 +0000 (UTC) (envelope-from eugen@kuzbass.ru) Received: from www.svzserv.kemerovo.su (eugen@localhost [127.0.0.1]) by www.svzserv.kemerovo.su (8.13.8/8.13.8) with ESMTP id m7E7Xvok085811; Thu, 14 Aug 2008 15:33:57 +0800 (KRAST) (envelope-from eugen@www.svzserv.kemerovo.su) Received: (from eugen@localhost) by www.svzserv.kemerovo.su (8.13.8/8.13.8/Submit) id m7E7XvrU085810; Thu, 14 Aug 2008 15:33:57 +0800 (KRAST) (envelope-from eugen) Date: Thu, 14 Aug 2008 15:33:57 +0800 From: Eugene Grosbein To: Sergey Chumakov Message-ID: <20080814073357.GA85637@svzserv.kemerovo.su> References: <20080814093000.4842b37c@while.alkar.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080814093000.4842b37c@while.alkar.net> User-Agent: Mutt/1.4.2.3i Cc: freebsd-stable@freebsd.org Subject: Re: Process size. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2008 07:34:30 -0000 On Thu, Aug 14, 2008 at 09:30:00AM +0300, Sergey Chumakov wrote: > $limits > Resource limits (current): > ... > datasize 1048576 kB > stacksize 131072 kB > > How and why is it possible for process to grow up to 1493M and even > more? I suppose, it will be able to eat all available system memory (was > killed). Try to eslablish 'vmemoryuse' limit also. Eugene Grosbein From owner-freebsd-stable@FreeBSD.ORG Thu Aug 14 07:44:31 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 32A131065692 for ; Thu, 14 Aug 2008 07:44:31 +0000 (UTC) (envelope-from jdc@parodius.com) Received: from mx01.sc1.parodius.com (mx01.sc1.parodius.com [72.20.106.3]) by mx1.freebsd.org (Postfix) with ESMTP id 2062D8FC49 for ; Thu, 14 Aug 2008 07:44:31 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id EF6EC1CC0C1; Thu, 14 Aug 2008 00:44:30 -0700 (PDT) Date: Thu, 14 Aug 2008 00:44:30 -0700 From: Jeremy Chadwick To: Sergey Chumakov Message-ID: <20080814074430.GA4096@eos.sc1.parodius.com> References: <20080814093000.4842b37c@while.alkar.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080814093000.4842b37c@while.alkar.net> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-stable@freebsd.org Subject: Re: Process size. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2008 07:44:31 -0000 On Thu, Aug 14, 2008 at 09:30:00AM +0300, Sergey Chumakov wrote: > Hello, > > FreeBSD 7.0-RELEASE-p3 #3 > > $top > ... > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND > 36032 root 2838 44 0 1917M 1493M ucond 0 406:39 3.03% CGServer > ... > > $cat /boot/loader.conf.local > ... > kern.maxdsiz="1073741824" > kern.maxssiz="134217728" > kern.dfldsiz="1073741824" > > $limits > Resource limits (current): > ... > datasize 1048576 kB > stacksize 131072 kB > > How and why is it possible for process to grow up to 1493M and even > more? I suppose, it will be able to eat all available system memory (was > killed). Do resource limits apply to root? I wonder if it's an issue of calculation in top; top might be including page sizes and other VM-related things, while limits datasize and stacksize may only be specific to those allocated amounts. If this machine was running RELENG_7 (STABLE), it would have procstat, which could help discern where the "extra" memory is. Also: is this i386 or amd64? -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Thu Aug 14 08:00:25 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8BFB7106567A for ; Thu, 14 Aug 2008 08:00:25 +0000 (UTC) (envelope-from css@alkar.net) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id 092288FC08 for ; Thu, 14 Aug 2008 08:00:24 +0000 (UTC) (envelope-from css@alkar.net) Received: from while.alkar.net (account css@alkar.net [212.86.226.7] verified) by cmail.optima.ua (CommuniGate Pro SMTP 5.1.14) with ESMTPA id 194583007; Thu, 14 Aug 2008 11:00:23 +0300 Date: Thu, 14 Aug 2008 11:00:22 +0300 From: Sergey Chumakov To: Jeremy Chadwick Message-ID: <20080814110022.053d117d@while.alkar.net> In-Reply-To: <20080814074430.GA4096@eos.sc1.parodius.com> References: <20080814093000.4842b37c@while.alkar.net> <20080814074430.GA4096@eos.sc1.parodius.com> Organization: Optima Telecom ISP X-Mailer: Claws Mail 3.5.0 (GTK+ 2.12.11; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit Cc: freebsd-stable@freebsd.org Subject: Re: Process size. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2008 08:00:25 -0000 îÁ Thu, 14 Aug 2008 00:44:30 -0700 Jeremy Chadwick ÚÁÐÉÓÁÎÏ: > On Thu, Aug 14, 2008 at 09:30:00AM +0300, Sergey Chumakov wrote: > > Hello, > > > > FreeBSD 7.0-RELEASE-p3 #3 > > > > $top > > ... > > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND > > 36032 root 2838 44 0 1917M 1493M ucond 0 406:39 3.03% CGServer > > ... > > > > $cat /boot/loader.conf.local > > ... > > kern.maxdsiz="1073741824" > > kern.maxssiz="134217728" > > kern.dfldsiz="1073741824" > > > > $limits > > Resource limits (current): > > ... > > datasize 1048576 kB > > stacksize 131072 kB > > > > How and why is it possible for process to grow up to 1493M and even > > more? I suppose, it will be able to eat all available system memory (was > > killed). > > Do resource limits apply to root? Yes, of course. > > I wonder if it's an issue of calculation in top; top might be including > page sizes and other VM-related things, while limits datasize and stacksize > may only be specific to those allocated amounts. > > If this machine was running RELENG_7 (STABLE), it would have procstat, > which could help discern where the "extra" memory is. > > Also: is this i386 or amd64? > i386 -- Sincerely, Sergey Chumakov From owner-freebsd-stable@FreeBSD.ORG Thu Aug 14 08:06:30 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A80811065675 for ; Thu, 14 Aug 2008 08:06:30 +0000 (UTC) (envelope-from freebsd-stable@pp.dyndns.biz) Received: from proxy3.bredband.net (proxy3.bredband.net [195.54.101.73]) by mx1.freebsd.org (Postfix) with ESMTP id 61DAE8FC1E for ; Thu, 14 Aug 2008 08:06:30 +0000 (UTC) (envelope-from freebsd-stable@pp.dyndns.biz) Received: from ironport.bredband.com (195.54.101.120) by proxy3.bredband.net (7.3.127) id 481183EA01B777DD for freebsd-stable@freebsd.org; Thu, 14 Aug 2008 09:45:48 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmAvABCAo0hV4joaPGdsb2JhbACBYJAOAQEBAS2kC4FV Received: from c-1a3ae255.107-1-64736c10.cust.bredbandsbolaget.se (HELO gatekeeper.pp.dyndns.biz) ([85.226.58.26]) by ironport1.bredband.com with ESMTP; 14 Aug 2008 09:45:36 +0200 Received: from [192.168.69.67] (phobos [192.168.69.67]) by gatekeeper.pp.dyndns.biz (8.14.2/8.14.2) with ESMTP id m7E7jXFJ062083 for ; Thu, 14 Aug 2008 09:45:34 +0200 (CEST) (envelope-from freebsd-stable@pp.dyndns.biz) Message-ID: <48A3E29D.3090504@pp.dyndns.biz> Date: Thu, 14 Aug 2008 09:45:33 +0200 From: =?ISO-8859-1?Q?Morgan_Wesstr=F6m?= User-Agent: Thunderbird 2.0.0.16 (X11/20080805) MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Removing /usr/lib32 on AMD64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2008 08:06:30 -0000 Hi. Looking through man src.conf I found the knob WITHOUT_LIB32 and recompiled my world with it since I have no use for 32-bit compatibility on my AMD64. After installworld I realized that /usr/lib32 was still there and still populated. Searching for information I found this bugreport: http://www.freebsd.org/cgi/query-pr.cgi?pr=117191&cat= Judging from that report and the fact that the dates on the files in /usr/lib32 wasn't updated I figured it was ok to simply remove them. I just want to make sure there's nothing else I have to do to cleanly remove 32-bit compatibility? I can see during boot that there is still some reference to 32-bit compatibility. The following message flashes by on the screen: ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib /usr/local/lib/mysql 32-bit compatibility ldconfig path: I can track the last row to /etc/rc.d/ldconfig but can't figure out if that script can take any options in /etc/rc.conf to stop looking for 32-bit libraries. There are no error messages what I can see so everything is probably ok, just want to make absolutely sure. Anyone who can share some insight on this? Regards Morgan Wesström From owner-freebsd-stable@FreeBSD.ORG Thu Aug 14 08:13:09 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CA2BF1065670 for ; Thu, 14 Aug 2008 08:13:09 +0000 (UTC) (envelope-from jdc@parodius.com) Received: from mx01.sc1.parodius.com (mx01.sc1.parodius.com [72.20.106.3]) by mx1.freebsd.org (Postfix) with ESMTP id B678A8FC2D for ; Thu, 14 Aug 2008 08:13:09 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id A458B1CC0BD; Thu, 14 Aug 2008 01:13:09 -0700 (PDT) Date: Thu, 14 Aug 2008 01:13:09 -0700 From: Jeremy Chadwick To: Morgan =?iso-8859-1?Q?Wesstr=F6m?= Message-ID: <20080814081309.GA8249@eos.sc1.parodius.com> References: <48A3E29D.3090504@pp.dyndns.biz> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <48A3E29D.3090504@pp.dyndns.biz> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-stable@freebsd.org Subject: Re: Removing /usr/lib32 on AMD64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2008 08:13:09 -0000 On Thu, Aug 14, 2008 at 09:45:33AM +0200, Morgan Wesström wrote: > Hi. > > Looking through man src.conf I found the knob WITHOUT_LIB32 and > recompiled my world with it since I have no use for 32-bit compatibility > on my AMD64. After installworld I realized that /usr/lib32 was still > there and still populated. Searching for information I found this > bugreport: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=117191&cat= > > Judging from that report and the fact that the dates on the files in > /usr/lib32 wasn't updated I figured it was ok to simply remove them. I > just want to make sure there's nothing else I have to do to cleanly > remove 32-bit compatibility? I can see during boot that there is still > some reference to 32-bit compatibility. The following message flashes by > on the screen: > > ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib > /usr/local/lib/mysql > 32-bit compatibility ldconfig path: > > I can track the last row to /etc/rc.d/ldconfig but can't figure out if > that script can take any options in /etc/rc.conf to stop looking for > 32-bit libraries. There are no error messages what I can see so > everything is probably ok, just want to make absolutely sure. Anyone who > can share some insight on this? What you've documented above is the Correct Way(tm) to remove lib32 support. Though I advocate people not install it in the first place, unless they absolutely need it. The message from /etc/rc.d/ldconfig you see there about 32-bit compatibility ldconfig path is fine -- it shows an empty path, which is correct. Nothing to worry about there. My systems, which have never had lib32 ever, show the same: ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib /usr/local/lib/mysql 32-bit compatibility ldconfig path: -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Thu Aug 14 08:34:30 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A896E106564A for ; Thu, 14 Aug 2008 08:34:30 +0000 (UTC) (envelope-from freebsd-stable@pp.dyndns.biz) Received: from proxy3.bredband.net (proxy3.bredband.net [195.54.101.73]) by mx1.freebsd.org (Postfix) with ESMTP id 609358FC21 for ; Thu, 14 Aug 2008 08:34:30 +0000 (UTC) (envelope-from freebsd-stable@pp.dyndns.biz) Received: from ironport.bredband.com (195.54.101.120) by proxy3.bredband.net (7.3.127) id 481183EA01B7B23F for freebsd-stable@freebsd.org; Thu, 14 Aug 2008 10:34:28 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvcvAJ2Ko0hV4joaPGdsb2JhbACBYoZmiSgBAQEBLaQCgVU Received: from c-1a3ae255.107-1-64736c10.cust.bredbandsbolaget.se (HELO gatekeeper.pp.dyndns.biz) ([85.226.58.26]) by ironport1.bredband.com with ESMTP; 14 Aug 2008 10:34:28 +0200 Received: from [192.168.69.67] (phobos [192.168.69.67]) by gatekeeper.pp.dyndns.biz (8.14.2/8.14.2) with ESMTP id m7E8YQ9r062696 for ; Thu, 14 Aug 2008 10:34:27 +0200 (CEST) (envelope-from freebsd-stable@pp.dyndns.biz) Message-ID: <48A3EE12.7060302@pp.dyndns.biz> Date: Thu, 14 Aug 2008 10:34:26 +0200 From: =?ISO-8859-1?Q?Morgan_Wesstr=F6m?= User-Agent: Thunderbird 2.0.0.16 (X11/20080805) MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <48A3E29D.3090504@pp.dyndns.biz> <20080814081309.GA8249@eos.sc1.parodius.com> In-Reply-To: <20080814081309.GA8249@eos.sc1.parodius.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Removing /usr/lib32 on AMD64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2008 08:34:30 -0000 Thanks for your answer Jeremy :-) > What you've documented above is the Correct Way(tm) to remove lib32 > support. Though I advocate people not install it in the first place, > unless they absolutely need it. I'm not sure I was ever given the option to deselect it during sysinstall. I don't rememeber any obvious question at least and /etc/src.conf did not exist efter install. > The message from /etc/rc.d/ldconfig you see there about 32-bit > compatibility ldconfig path is fine -- it shows an empty path, which is > correct. Nothing to worry about there. There are references in ldconfig to a couple of options I find in /etc/defaults/rc.conf ldconfig32_paths="/usr/lib32" # 32-bit compatibility shared library ldconfig_local32_dirs="/usr/local/libdata/ldconfig32" Should I blank those? /usr/local/libdata/ldconfig32 is an empty folder here. There's also a /libexec/ld-elf32.so.1 left, with the same old date as the libs, and a symlink from /usr/libexec/ld-elf32.so.1 pointing to it. Should I leave them or remove them? They were not mentioned in the diff in the bugreport. /Morgan From owner-freebsd-stable@FreeBSD.ORG Thu Aug 14 08:51:25 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 58C861065679 for ; Thu, 14 Aug 2008 08:51:25 +0000 (UTC) (envelope-from jdc@parodius.com) Received: from mx01.sc1.parodius.com (mx01.sc1.parodius.com [72.20.106.3]) by mx1.freebsd.org (Postfix) with ESMTP id 439C68FC17 for ; Thu, 14 Aug 2008 08:51:25 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id 2B4B41CC0BE; Thu, 14 Aug 2008 01:51:25 -0700 (PDT) Date: Thu, 14 Aug 2008 01:51:25 -0700 From: Jeremy Chadwick To: Morgan =?iso-8859-1?Q?Wesstr=F6m?= Message-ID: <20080814085125.GA12129@eos.sc1.parodius.com> References: <48A3E29D.3090504@pp.dyndns.biz> <20080814081309.GA8249@eos.sc1.parodius.com> <48A3EE12.7060302@pp.dyndns.biz> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <48A3EE12.7060302@pp.dyndns.biz> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-stable@freebsd.org Subject: Re: Removing /usr/lib32 on AMD64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2008 08:51:25 -0000 On Thu, Aug 14, 2008 at 10:34:26AM +0200, Morgan Wesström wrote: > Thanks for your answer Jeremy :-) > >> What you've documented above is the Correct Way(tm) to remove lib32 >> support. Though I advocate people not install it in the first place, >> unless they absolutely need it. > > I'm not sure I was ever given the option to deselect it during > sysinstall. I don't remember if 7.0-RELEASE sysinstall lists it, but I know 7.0-STABLE does. > I don't rememeber any obvious question at least and > /etc/src.conf did not exist efter install. What relevancy does this have to sysinstall? Nothing during sysinstall touches src.conf. Every FreeBSD system will be missing /etc/src.conf after an install; the same goes for /etc/make.conf. It's normal. >> The message from /etc/rc.d/ldconfig you see there about 32-bit >> compatibility ldconfig path is fine -- it shows an empty path, which is >> correct. Nothing to worry about there. > > There are references in ldconfig to a couple of options I find in > /etc/defaults/rc.conf > > ldconfig32_paths="/usr/lib32" # 32-bit compatibility shared library > ldconfig_local32_dirs="/usr/local/libdata/ldconfig32" > > Should I blank those? /usr/local/libdata/ldconfig32 is an empty folder here. No, do not blank them; they will not be used, as was shown to you by /etc/rc.d/ldconfig's output not utilising any 32-bit paths. There's no point in blanking something that won't get used, it'll just confuse someone who looks at the system or lead them astray. > There's also a /libexec/ld-elf32.so.1 left, with the same old date as > the libs, and a symlink from /usr/libexec/ld-elf32.so.1 pointing to it. > Should I leave them or remove them? They were not mentioned in the diff > in the bugreport. You should safely be able to remove those as well, assuming you have rebuilt/reinstalled world, and rebuilt all of your ports. Otherwise upon removal, programs utilising ld-elf32.so.1, won't have a valid ld.so loader, and will fail immediately. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Thu Aug 14 09:09:27 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 188A11065676 for ; Thu, 14 Aug 2008 09:09:27 +0000 (UTC) (envelope-from freebsd-stable@pp.dyndns.biz) Received: from proxy2.bredband.net (proxy2.bredband.net [195.54.101.72]) by mx1.freebsd.org (Postfix) with ESMTP id C31CB8FC1A for ; Thu, 14 Aug 2008 09:09:26 +0000 (UTC) (envelope-from freebsd-stable@pp.dyndns.biz) Received: from ironport.bredband.com (195.54.101.120) by proxy2.bredband.net (7.3.127) id 4811833301B8D682 for freebsd-stable@freebsd.org; Thu, 14 Aug 2008 11:09:25 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvcvAM+So0hV4joaPGdsb2JhbACBYoZmiSgBAQEBLaQLgVU Received: from c-1a3ae255.107-1-64736c10.cust.bredbandsbolaget.se (HELO gatekeeper.pp.dyndns.biz) ([85.226.58.26]) by ironport1.bredband.com with ESMTP; 14 Aug 2008 11:09:24 +0200 Received: from [192.168.69.67] (phobos [192.168.69.67]) by gatekeeper.pp.dyndns.biz (8.14.2/8.14.2) with ESMTP id m7E99N2R063136 for ; Thu, 14 Aug 2008 11:09:24 +0200 (CEST) (envelope-from freebsd-stable@pp.dyndns.biz) Message-ID: <48A3F643.80508@pp.dyndns.biz> Date: Thu, 14 Aug 2008 11:09:23 +0200 From: =?ISO-8859-1?Q?Morgan_Wesstr=F6m?= User-Agent: Thunderbird 2.0.0.16 (X11/20080805) MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <48A3E29D.3090504@pp.dyndns.biz> <20080814081309.GA8249@eos.sc1.parodius.com> <48A3EE12.7060302@pp.dyndns.biz> <20080814085125.GA12129@eos.sc1.parodius.com> In-Reply-To: <20080814085125.GA12129@eos.sc1.parodius.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Removing /usr/lib32 on AMD64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2008 09:09:27 -0000 Jeremy Chadwick wrote: > I don't remember if 7.0-RELEASE sysinstall lists it, but I know > 7.0-STABLE does. Oh, that explains it. I installed RELEASE and am still on RELEASE tbh. Sorry for being on the wrong list... :-/ >> I don't rememeber any obvious question at least and >> /etc/src.conf did not exist efter install. > > What relevancy does this have to sysinstall? Nothing during sysinstall > touches src.conf. Every FreeBSD system will be missing /etc/src.conf > after an install; the same goes for /etc/make.conf. It's normal. WITHOUT_LIB32 is supposed to be in src.conf. If it's missing on STABLE, wouldn't that mean 32-bit compatibility would be added to STABLE at next world rebuild or is there another mechanism preventing this from happen? >> There are references in ldconfig to a couple of options I find in >> /etc/defaults/rc.conf >> Should I blank those? /usr/local/libdata/ldconfig32 is an empty folder here. > > No, do not blank them; they will not be used, as was shown to you by > /etc/rc.d/ldconfig's output not utilising any 32-bit paths. There's no > point in blanking something that won't get used, it'll just confuse > someone who looks at the system or lead them astray. Message received and understood. Leaving them alone. :-) >> There's also a /libexec/ld-elf32.so.1 left, with the same old date as >> the libs, and a symlink from /usr/libexec/ld-elf32.so.1 pointing to it. >> Should I leave them or remove them? They were not mentioned in the diff >> in the bugreport. > > You should safely be able to remove those as well, assuming you have > rebuilt/reinstalled world, and rebuilt all of your ports. Otherwise > upon removal, programs utilising ld-elf32.so.1, won't have a valid > ld.so loader, and will fail immediately. World is rebuilt but I haven't rebuilt my ports but they shouldn't have been built against the 32-bit libraries in the first place, should they? 64-bit libraries are the default choice I assume or am I missing something vital here? I'll remove them and see what happens when I reboot. It will be an exciting start of the day ;-) Thanks again for your help, It's highly appreciated. /Morgan From owner-freebsd-stable@FreeBSD.ORG Thu Aug 14 09:38:02 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 897DB1065670 for ; Thu, 14 Aug 2008 09:38:02 +0000 (UTC) (envelope-from sebster@sebster.com) Received: from mail.servoy.com (mail.servoy.com [87.233.173.130]) by mx1.freebsd.org (Postfix) with SMTP id 662BD8FC1B for ; Thu, 14 Aug 2008 09:38:01 +0000 (UTC) (envelope-from sebster@sebster.com) Received: (qmail 33118 invoked from network); 14 Aug 2008 09:38:00 -0000 Received: from unknown (HELO ?10.1.0.6?) (sebster@85.147.225.232) by mail.servoy.com with SMTP; 14 Aug 2008 09:38:00 -0000 Message-ID: <48A3FCF7.9030905@sebster.com> Date: Thu, 14 Aug 2008 11:37:59 +0200 From: Sebastiaan van Erk User-Agent: Thunderbird 2.0.0.16 (X11/20080724) MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <48982B58.4000406@sebster.com> <48992532.9080503@yandex.ru> <489970CC.4000103@sebster.com> <20080806095748.GA52551@eos.sc1.parodius.com> <20080806101941.GA52952@eos.sc1.parodius.com> <48A2DD60.7090702@sebster.com> <20080814090521.GB27942@groll.co.za> In-Reply-To: <20080814090521.GB27942@groll.co.za> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000605050701090102090507" Cc: Jonathan Groll Subject: Re: Stable SATA pci card for FreeBSD 6.x/7.0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2008 09:38:02 -0000 This is a cryptographically signed message in MIME format. --------------ms000605050701090102090507 Content-Type: multipart/mixed; boundary="------------060800040706000500050308" This is a multi-part message in MIME format. --------------060800040706000500050308 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Thanks Jonathan, I'm starting to expect it has to be the controller as well. About 20 minutes after I posted this message yesterday (and thus 20 minutes after ad6 got disconnected - atacontrol list showed "no device present" for it) the machine crashed while writing to the remaining ad4 drive (kernel panic). I attached the logs below. I also ran the long smart self test on both drives, and no errors were found on either drive (logs also attached). Unfortunately I could not attach the new disks to my mainboard SATA because my mainboard SATA somehow hangs trying to detect them. So I cannot test if *not* using the controller is going to solve the problems, though I'm it seems logical at the moment it has to be the controller, especially if other people have had similar issues. I guess I'll be buying another controller. Regards, Sebastiaan Jonathan Groll wrote: > On Wed, Aug 13, 2008 at 03:10:56PM +0200, Sebastiaan van Erk wrote: >> Hi, >> >> Just an update on this issue. >> >> Quick summary: I fixed the BIOS issues, the hardware monitor issues, and >> the rl0/rl1 watchdog timeout issues (it seems). However I'm still having >> problems with my SATA drives (or at least one of them). More info below. >> >> BIOS: >> I flashed my BIOS to the latest version about a year ago, and never >> noticed that there was any problem, but it turns out there was. I never >> reset the BIOS to default factory settings after the upgrade, and it >> seems the settings were corrupt. After having reset the BIOS to the >> "default optimized factory settings" it stopped crashing when I go into >> the H/W monitor and also when using healthd -d (output below): >> >> Temp.= 40.0, 36.0, 66.0; Rot.= 0, 0, 0 >> Vcore = 1.44, 3.12; Volt. = 3.34, 5.00, 1.95, -0.11, -1.54 >> Temp.= 40.0, 36.0, 66.0; Rot.= 0, 0, 0 >> Vcore = 1.44, 3.14; Volt. = 3.33, 4.97, 1.95, -0.11, -1.54 >> Temp.= 40.0, 36.0, 66.0; Rot.= 0, 0, 0 >> Vcore = 1.44, 3.12; Volt. = 3.34, 4.97, 1.95, -0.11, -1.54 >> Temp.= 40.0, 36.0, 66.0; Rot.= 0, 0, 0 >> Vcore = 1.44, 3.12; Volt. = 3.34, 5.00, 1.95, -0.11, -1.54 >> Temp.= 40.0, 36.0, 66.0; Rot.= 0, 0, 0 >> Vcore = 1.44, 3.12; Volt. = 3.34, 5.00, 1.95, -0.11, -1.54 >> >> This also seems to have fixed the rl0 watchdog timeout problems. I no >> longer see those in my logs. >> >> SATA DRIVES: >> >> I'm still having problems with the SATA drives. >> >> I tried connecting the 1TB Samsung drives to my mainboard, but then the >> box hangs when booting with the "Detecting IDE drives" message. The >> regular (PATA) IDE drives are detected first, and then it repeats the >> "Detecting IDE drives" message to detect the sata drives, and hangs. >> When I connect my 250GB SATA drives to my mainboard they detect fine, >> and the box boots normally. >> >> I did another rsync of my old mirror (the 250GB disks) to the new mirror >> (1TB disks), but again one of the disks got detached. This time there >> are no other messages in the log, the only thing I see is the following: >> >> Aug 13 14:35:27 piglet su: sebster to root on /dev/ttyp5 >> Aug 13 14:55:38 piglet kernel: ad6: FAILURE - device detached >> Aug 13 14:55:38 piglet kernel: subdisk6: detached >> Aug 13 14:55:38 piglet kernel: ad6: detached >> Aug 13 14:55:38 piglet kernel: GEOM_MIRROR: Device gm1: provider ad6 >> disconnected. >> Aug 13 15:00:00 piglet newsyslog[1800]: logfile turned over due to size>100K >> >> (unfortunate that the log file just got rotated, but in the new log file >> there is nothing execpt the one expected line: >> >> Aug 13 15:00:00 piglet newsyslog[1800]: logfile turned over due to size>100K >> >> So, nothing after the disconnect... >> >> The questions I have now is: >> 1) Could an upgrade to FreeBSD 7-STABLE fix the issue (it's a LOT of >> work for me, but I'll do it if there are SATA driver issues fixed). > > I suspect the problem may be the SiI driver in Freebsd. As a reference > point, I've had a similar problem, even on 7-STABLE, but with sparc64 > hardware (see earlier post in this thread). > > It'll probably be simplest for you to just buy another controller of > another brand. On the other hand, it'll be worth knowing exactly what > is wrong with the SiI driver... > > Cheers, > Jonathan --------------060800040706000500050308 Content-Type: text/plain; name="messages.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="messages.txt" Aug 13 15:00:00 piglet newsyslog[1800]: logfile turned over due to size>100K Aug 13 15:11:26 piglet su: sebster to root on /dev/ttyp4 Aug 13 15:34:55 piglet kernel: mirror/gm1s1e[WRITE(offset=875450693632, length=2048)]error = 6 Aug 13 15:34:55 piglet kernel: g_vfs_done():mirror/gm1s1e[WRITE(offset=875450695680, length=2048)]error = 6 [snip 335750 similar lines] Aug 13 15:36:30 piglet kernel: g_vfs_done():mirror/gm1s1e[WRITE(offset=875450931200, length=2048)]error = 6 Aug 13 15:36:30 piglet kernel: g_vfs_done():mirror/gm1s1e[WRITE(offset=875450933248, length=2048)]error = 6 Aug 13 15:36:30 piglet kernel: g_vfs_done():mirror/gm1s1e[WRITE(offset=875450935296, length=2048)]error = 6 Aug 13 15:36:30 piglet kernel: g_vfs_done():mirror/gm1s1e[WRITE(offset=875450937344, length=2048)]error = 6 Aug 13 15:36:30 piglet kernel: g_vfs_done():mirror/gm1s1e[WRITE(offset=875450939392, length=2048)]error = 6 Aug 13 15:36:30 piglet kernel: g_vfs_done():mirror/gm1s1e[WRITE(offset=875450941440, length=2048)]error = 6 Aug 13 15:36:30 piglet kernel: g_vfs_done():mirror/gm1s1e[WRITE(offset=875450943488, length=2048)]error = 6 Aug 13 15:36:30 piglet kernel: g_vfs_done():mirror/gm1s1e[WRITE(offset=875450945536, length=2048)]error = 6 Aug 13 15:36:30 piglet kernel: g_vfs_done():mirror/gm1s1e[WRITE(offset=875450947584, length=2048)]error = 6 Aug 13 15:36:30 piglet kernel: g_vfs_done():mirror/gm1s1e[WRITE(offset=875450949632, length=2048)]error = 6 Aug 13 15:36:30 piglet kernel: g_vfs_done():mirror/gm1s1e[WRITE(offset=875450951680, length=2048)]error = 6 Aug 13 15:36:30 piglet kernel: g_vfs_done():mirror/gm1s1e[WRITE(offset=875450953728, length=2048)]error = 6 Aug 13 15:36:30 piglet kernel: g_vfs_done():mirror/gm1s1e[WRITE(offset=875450955776, length=2048)]error = 6 Aug 13 15:36:30 piglet kernel: g_vfs_done():mirror/gm1s1e[WRITE(offset=875450957824, length=2048)]error = 6 Aug 13 15:36:30 piglet kernel: g_vfs_done():mirror/gm1s1e[WRITE(offset=875450959872, length=2048)]error = 6 Aug 13 15:36:30 piglet kernel: g_vfs_done():mirror/gm1s1e[WRITE(offset=875450961920, length=2048)]error = 6 Aug 13 15:36:30 piglet kernel: g_vfs_done():mirror/gm1s1e[WRITE(offset=875450963968, length=2048)]error = 6 Aug 13 15:36:30 piglet kernel: g_vfs_done():mirror/gm1s1e[WRITE(offset=875450966016, length=2048)]error = 6 Aug 13 15:36:30 piglet kernel: g_vfs_done():mirror/gm1s1e[WRITE(offset=875450968064, length=2048)]error = 6 Aug 13 15:36:30 piglet kernel: g_vfs_done():mirror/gm1s1e[WRITE(offset=875450970112, length=2048)]error = 6 Aug 13 15:36:30 piglet kernel: g_vfs_done():mirror/gm1s1e[WRITE(offset=875450972160, length=2048)]error = 6 Aug 13 15:36:30 piglet kernel: g_vfs_done():mirror/gm1s1e[WRITE(offset=875450974208, length=2048)]error = 6 Aug 13 15:42:23 piglet syslogd: kernel boot file is /boot/kernel/kernel Aug 13 15:42:23 piglet kernel: Copyright (c) 1992-2008 The FreeBSD Project. --------------060800040706000500050308 Content-Type: text/plain; name="ad4.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ad4.txt" smartctl version 5.38 [i386-portbld-freebsd6.3] Copyright (C) 2002-8 Bruce Allen Home page is http://smartmontools.sourceforge.net/ === START OF INFORMATION SECTION === Device Model: SAMSUNG HD103UJ Serial Number: S13PJ1BQ606865 Firmware Version: 1AA01112 User Capacity: 1,000,204,886,016 bytes Device is: In smartctl database [for details use: -P show] ATA Version is: 8 ATA Standard is: ATA-8-ACS revision 3b Local Time is: Thu Aug 14 11:28:13 2008 CEST ==> WARNING: May need -F samsung or -F samsung2 enabled; see manual for details. SMART support is: Available - device has SMART capability. SMART support is: Enabled === START OF READ SMART DATA SECTION === SMART overall-health self-assessment test result: PASSED General SMART Values: Offline data collection status: (0x02) Offline data collection activity was completed without error. Auto Offline Data Collection: Disabled. Self-test execution status: ( 0) The previous self-test routine completed without error or no self-test has ever been run. Total time to complete Offline data collection: (11811) seconds. Offline data collection capabilities: (0x7b) SMART execute Offline immediate. Auto Offline data collection on/off support. Suspend Offline collection upon new command. Offline surface scan supported. Self-test supported. Conveyance Self-test supported. Selective Self-test supported. SMART capabilities: (0x0003) Saves SMART data before entering power-saving mode. Supports SMART auto save timer. Error logging capability: (0x01) Error logging supported. General Purpose Logging supported. Short self-test routine recommended polling time: ( 2) minutes. Extended self-test routine recommended polling time: ( 198) minutes. Conveyance self-test routine recommended polling time: ( 21) minutes. SCT capabilities: (0x003f) SCT Status supported. SCT Feature Control supported. SCT Data Table supported. SMART Attributes Data Structure revision number: 16 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x000f 100 100 051 Pre-fail Always - 0 3 Spin_Up_Time 0x0007 076 076 011 Pre-fail Always - 8010 4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 8 5 Reallocated_Sector_Ct 0x0033 100 100 010 Pre-fail Always - 0 7 Seek_Error_Rate 0x000f 253 253 051 Pre-fail Always - 0 8 Seek_Time_Performance 0x0025 100 100 015 Pre-fail Offline - 10255 9 Power_On_Hours 0x0032 100 100 000 Old_age Always - 272 10 Spin_Retry_Count 0x0033 100 100 051 Pre-fail Always - 0 11 Calibration_Retry_Count 0x0012 100 100 000 Old_age Always - 0 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 8 13 Read_Soft_Error_Rate 0x000e 100 100 000 Old_age Always - 0 183 Unknown_Attribute 0x0032 100 100 000 Old_age Always - 0 184 Unknown_Attribute 0x0033 100 100 099 Pre-fail Always - 0 187 Reported_Uncorrect 0x0032 100 100 000 Old_age Always - 0 188 Unknown_Attribute 0x0032 100 100 000 Old_age Always - 0 190 Airflow_Temperature_Cel 0x0022 057 052 000 Old_age Always - 43 (Lifetime Min/Max 43/48) 194 Temperature_Celsius 0x0022 056 050 000 Old_age Always - 44 (Lifetime Min/Max 43/50) 195 Hardware_ECC_Recovered 0x001a 100 100 000 Old_age Always - 195799724 196 Reallocated_Event_Count 0x0032 100 100 000 Old_age Always - 0 197 Current_Pending_Sector 0x0012 100 100 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0030 100 100 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x003e 100 100 000 Old_age Always - 0 200 Multi_Zone_Error_Rate 0x000a 100 100 000 Old_age Always - 0 201 Soft_Read_Error_Rate 0x000a 100 100 000 Old_age Always - 0 SMART Error Log Version: 1 No Errors Logged SMART Self-test log structure revision number 0 Warning: ATA Specification requires self-test log structure revision number = 1 Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error # 1 Offline Completed without error 00% 261 - # 2 Offline Aborted by host 40% 251 - # 3 Short offline Aborted by host 00% 250 - SMART Selective Self-Test Log Data Structure Revision Number (0) should be 1 SMART Selective self-test log data structure revision number 0 Warning: ATA Specification requires selective self-test log data structure revision number = 1 SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS 1 0 0 Not_testing 2 0 0 Not_testing 3 0 0 Not_testing 4 0 0 Not_testing 5 0 0 Not_testing Selective self-test flags (0x0): After scanning selected spans, do NOT read-scan remainder of disk. If Selective self-test is pending on power-up, resume after 0 minute delay. --------------060800040706000500050308 Content-Type: text/plain; name="ad6.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ad6.txt" smartctl version 5.38 [i386-portbld-freebsd6.3] Copyright (C) 2002-8 Bruce Allen Home page is http://smartmontools.sourceforge.net/ === START OF INFORMATION SECTION === Device Model: SAMSUNG HD103UJ Serial Number: S13PJ1BQ607102 Firmware Version: 1AA01112 User Capacity: 1,000,204,886,016 bytes Device is: In smartctl database [for details use: -P show] ATA Version is: 8 ATA Standard is: ATA-8-ACS revision 3b Local Time is: Thu Aug 14 11:28:39 2008 CEST ==> WARNING: May need -F samsung or -F samsung2 enabled; see manual for details. SMART support is: Available - device has SMART capability. SMART support is: Enabled === START OF READ SMART DATA SECTION === SMART overall-health self-assessment test result: PASSED General SMART Values: Offline data collection status: (0x02) Offline data collection activity was completed without error. Auto Offline Data Collection: Disabled. Self-test execution status: ( 0) The previous self-test routine completed without error or no self-test has ever been run. Total time to complete Offline data collection: (12131) seconds. Offline data collection capabilities: (0x7b) SMART execute Offline immediate. Auto Offline data collection on/off support. Suspend Offline collection upon new command. Offline surface scan supported. Self-test supported. Conveyance Self-test supported. Selective Self-test supported. SMART capabilities: (0x0003) Saves SMART data before entering power-saving mode. Supports SMART auto save timer. Error logging capability: (0x01) Error logging supported. General Purpose Logging supported. Short self-test routine recommended polling time: ( 2) minutes. Extended self-test routine recommended polling time: ( 203) minutes. Conveyance self-test routine recommended polling time: ( 22) minutes. SCT capabilities: (0x003f) SCT Status supported. SCT Feature Control supported. SCT Data Table supported. SMART Attributes Data Structure revision number: 16 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x000f 100 100 051 Pre-fail Always - 0 3 Spin_Up_Time 0x0007 077 077 011 Pre-fail Always - 7810 4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 10 5 Reallocated_Sector_Ct 0x0033 100 100 010 Pre-fail Always - 0 7 Seek_Error_Rate 0x000f 253 253 051 Pre-fail Always - 0 8 Seek_Time_Performance 0x0025 100 100 015 Pre-fail Offline - 9978 9 Power_On_Hours 0x0032 100 100 000 Old_age Always - 272 10 Spin_Retry_Count 0x0033 100 100 051 Pre-fail Always - 0 11 Calibration_Retry_Count 0x0012 100 100 000 Old_age Always - 0 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 10 13 Read_Soft_Error_Rate 0x000e 100 100 000 Old_age Always - 0 183 Unknown_Attribute 0x0032 100 100 000 Old_age Always - 0 184 Unknown_Attribute 0x0033 100 100 099 Pre-fail Always - 0 187 Reported_Uncorrect 0x0032 100 100 000 Old_age Always - 0 188 Unknown_Attribute 0x0032 100 100 000 Old_age Always - 0 190 Airflow_Temperature_Cel 0x0022 059 054 000 Old_age Always - 41 (Lifetime Min/Max 41/46) 194 Temperature_Celsius 0x0022 058 053 000 Old_age Always - 42 (Lifetime Min/Max 41/47) 195 Hardware_ECC_Recovered 0x001a 100 100 000 Old_age Always - 31616 196 Reallocated_Event_Count 0x0032 100 100 000 Old_age Always - 0 197 Current_Pending_Sector 0x0012 100 100 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0030 100 100 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x003e 100 100 000 Old_age Always - 0 200 Multi_Zone_Error_Rate 0x000a 100 100 000 Old_age Always - 0 201 Soft_Read_Error_Rate 0x000a 100 100 000 Old_age Always - 0 SMART Error Log Version: 1 No Errors Logged SMART Self-test log structure revision number 0 Warning: ATA Specification requires self-test log structure revision number = 1 Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error # 1 Offline Completed without error 00% 261 - # 2 Offline Aborted by host 40% 251 - # 3 Short offline Aborted by host 00% 250 - SMART Selective Self-Test Log Data Structure Revision Number (0) should be 1 SMART Selective self-test log data structure revision number 0 Warning: ATA Specification requires selective self-test log data structure revision number = 1 SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS 1 0 0 Not_testing 2 0 0 Not_testing 3 0 0 Not_testing 4 0 0 Not_testing 5 0 0 Not_testing Selective self-test flags (0x0): After scanning selected spans, do NOT read-scan remainder of disk. If Selective self-test is pending on power-up, resume after 0 minute delay. --------------060800040706000500050308-- --------------ms000605050701090102090507 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJUTCC AwMwggJsoAMCAQICEFN8DarMNuuKJDEtfs0UaqUwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDYzMDEzNTE1N1oX DTA5MDYzMDEzNTE1N1owaDEQMA4GA1UEBBMHdmFuIEVyazETMBEGA1UEKhMKU2ViYXN0aWFh bjEbMBkGA1UEAxMSU2ViYXN0aWFhbiB2YW4gRXJrMSIwIAYJKoZIhvcNAQkBFhNzZWJzdGVy QHNlYnN0ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsJDDAeYHVmH/ GVxi+bhFx27dmg++9BdhPJfk8k041sqEqq7oXnR2GT54quY3Ac7A1BuOM2JvoICraGmjud4y b3EanRnqGIK6iH+VAhhTlV/Owrb2Qm1e13DLxwLp1SocSQl4IrEbF9Y5H3ASdIrE0iFqkpju nPiiHeNhz3LaI5ipjiluKYoH+F6gPx8njHoaDxPePCkSLg4r0IA0afLM74LVZxCRBZEfyRZS J6VVUJefKlz91dWSzR/3xSw/rO4u9Ds/Zh7VBUKy3K+YFryHxRpUek0gSepE1b70Q39L9Sqd M/NZqMvFpwrqgW2Zh2Nh8nqRge90maR4ypBzz3GzLwIDAQABozAwLjAeBgNVHREEFzAVgRNz ZWJzdGVyQHNlYnN0ZXIuY29tMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEFBQADgYEAS1Sk NMgDVzb0ktO9tPPacV0KdKhTYOHcICVmuDEe2sFHOkjLAI1iAKp640pqJEVqvRnfRcCFJ9hK koPjjVZ+ui2rVmJWBG6FSloLRS/YYED4tUAw6DQhK61UOpjkpQxjCdm+5bHG/2ZgJAda1j0x uiN822+xFkcaW/5PQgxSRxcwggMDMIICbKADAgECAhBTfA2qzDbriiQxLX7NFGqlMA0GCSqG SIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QTAeFw0wODA2MzAxMzUxNTdaFw0wOTA2MzAxMzUxNTdaMGgxEDAOBgNVBAQTB3ZhbiBFcmsx EzARBgNVBCoTClNlYmFzdGlhYW4xGzAZBgNVBAMTElNlYmFzdGlhYW4gdmFuIEVyazEiMCAG CSqGSIb3DQEJARYTc2Vic3RlckBzZWJzdGVyLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBALCQwwHmB1Zh/xlcYvm4Rcdu3ZoPvvQXYTyX5PJNONbKhKqu6F50dhk+eKrm NwHOwNQbjjNib6CAq2hpo7neMm9xGp0Z6hiCuoh/lQIYU5VfzsK29kJtXtdwy8cC6dUqHEkJ eCKxGxfWOR9wEnSKxNIhapKY7pz4oh3jYc9y2iOYqY4pbimKB/heoD8fJ4x6Gg8T3jwpEi4O K9CANGnyzO+C1WcQkQWRH8kWUielVVCXnypc/dXVks0f98UsP6zuLvQ7P2Ye1QVCstyvmBa8 h8UaVHpNIEnqRNW+9EN/S/UqnTPzWajLxacK6oFtmYdjYfJ6kYHvdJmkeMqQc89xsy8CAwEA AaMwMC4wHgYDVR0RBBcwFYETc2Vic3RlckBzZWJzdGVyLmNvbTAMBgNVHRMBAf8EAjAAMA0G CSqGSIb3DQEBBQUAA4GBAEtUpDTIA1c29JLTvbTz2nFdCnSoU2Dh3CAlZrgxHtrBRzpIywCN YgCqeuNKaiRFar0Z30XAhSfYSpKD441Wfrotq1ZiVgRuhUpaC0Uv2GBA+LVAMOg0ISutVDqY 5KUMYwnZvuWxxv9mYCQHWtY9MbojfNtvsRZHGlv+T0IMUkcXMIIDPzCCAqigAwIBAgIBDTAN BgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTES MBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UE CxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0 aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GN ADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAK MNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTX p6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYB Af8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBl cnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYD VQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2as Zw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSe JVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHT HUb/XV9lTzGCA2QwggNgAgEBMHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBD b25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBJc3N1aW5nIENBAhBTfA2qzDbriiQxLX7NFGqlMAkGBSsOAwIaBQCgggHDMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA4MDgxNDA5Mzc1OVowIwYJKoZI hvcNAQkEMRYEFGLJcCIoHW5n6ycdwBhjku60JMDPMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3 DQMCAgEoMIGFBgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3 dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQQIQU3wNqsw264okMS1+zRRqpTCBhwYLKoZIhvcNAQkQAgsxeKB2 MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQu MSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQU3wNqsw2 64okMS1+zRRqpTANBgkqhkiG9w0BAQEFAASCAQCcb4yIdWMBrrnTR6tNgd+JSehhQxxnRXo3 mpc7+Q51vgkhKQTJNUKhjy0PkglXBi1nkEIyP1LdzKI4w/svLr33rK2I9NAyBlnw6xWKMEmJ ZSqby4PXML/Z4+/Fix99iGi7ledb+TMAFTu1XDuy6KOYnE2NUHXEDnnVbLm6v6C+g3xrXGpI FXfprC0eEcHb2wuK+t67Ma32VW0MSO6iHfg1Gxy/7APWvIc85SF5TAdW6yPXRQiPuH21l+8H As+/ffssQOg5H4Fcr5pY7igUBXdjLrFM+4CaV03nHTciXK3UuFiji9XEkUpqI2XQXAnlQjq1 O2KvBFFzqP3Ip+44n0iqAAAAAAAA --------------ms000605050701090102090507-- From owner-freebsd-stable@FreeBSD.ORG Thu Aug 14 09:56:02 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 188C21065690 for ; Thu, 14 Aug 2008 09:56:00 +0000 (UTC) (envelope-from jdc@parodius.com) Received: from mx01.sc1.parodius.com (mx01.sc1.parodius.com [72.20.106.3]) by mx1.freebsd.org (Postfix) with ESMTP id 022988FC1A for ; Thu, 14 Aug 2008 09:55:59 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id AEC9D1CC0BA; Thu, 14 Aug 2008 02:55:59 -0700 (PDT) Date: Thu, 14 Aug 2008 02:55:59 -0700 From: Jeremy Chadwick To: Morgan =?iso-8859-1?Q?Wesstr=F6m?= Message-ID: <20080814095559.GA15612@eos.sc1.parodius.com> References: <48A3E29D.3090504@pp.dyndns.biz> <20080814081309.GA8249@eos.sc1.parodius.com> <48A3EE12.7060302@pp.dyndns.biz> <20080814085125.GA12129@eos.sc1.parodius.com> <48A3F643.80508@pp.dyndns.biz> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <48A3F643.80508@pp.dyndns.biz> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-stable@freebsd.org Subject: Re: Removing /usr/lib32 on AMD64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2008 09:56:02 -0000 On Thu, Aug 14, 2008 at 11:09:23AM +0200, Morgan Wesström wrote: > Jeremy Chadwick wrote: >> I don't remember if 7.0-RELEASE sysinstall lists it, but I know >> 7.0-STABLE does. > > Oh, that explains it. I installed RELEASE and am still on RELEASE tbh. > Sorry for being on the wrong list... :-/ You're on the right list. You just need to know the difference between RELEASE and STABLE. RELEASE is more or less the "first time FreeBSD version x.y has been released to the world", and STABLE are all further updates to that version going forward. >>> I don't rememeber any obvious question at least and /etc/src.conf >>> did not exist efter install. >> >> What relevancy does this have to sysinstall? Nothing during sysinstall >> touches src.conf. Every FreeBSD system will be missing /etc/src.conf >> after an install; the same goes for /etc/make.conf. It's normal. > > WITHOUT_LIB32 is supposed to be in src.conf. If it's missing on STABLE, > wouldn't that mean 32-bit compatibility would be added to STABLE at next > world rebuild Correct. If a person unselects lib32 during sysinstall, they will need to remember to also add WITHOUT_LIB32=true to /etc/src.conf, otherwise lib32 stuff will get installed during the next world build and install. sysinstall manipulating src.conf would be a Really Nice Feature(tm), and would probably save some folks from the exact situation you're describing. > ... or is there another mechanism preventing this from happen? Nope, src.conf is the right place. >>> There's also a /libexec/ld-elf32.so.1 left, with the same old date as >>> the libs, and a symlink from /usr/libexec/ld-elf32.so.1 pointing to >>> it. Should I leave them or remove them? They were not mentioned in >>> the diff in the bugreport. >> >> You should safely be able to remove those as well, assuming you have >> rebuilt/reinstalled world, and rebuilt all of your ports. Otherwise >> upon removal, programs utilising ld-elf32.so.1, won't have a valid >> ld.so loader, and will fail immediately. > > World is rebuilt but I haven't rebuilt my ports but they shouldn't have > been built against the 32-bit libraries in the first place, should they? That depends on if the port chooses to utilise such. ldd(1) will answer that question. It can be a tedious process to go through all the binaries on one's system to see which are linked with what, however. > 64-bit libraries are the default choice I assume or am I missing > something vital here? I'll remove them and see what happens when I > reboot. It will be an exciting start of the day ;-) Chances are nothing uses them, but then again I have no idea what ports or packages you've installed -- there are some which do not work on amd64 and are explicitly for i386. > Thanks again for your help, It's highly appreciated. No problem! -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Thu Aug 14 10:15:23 2008 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 17DC11065671 for ; Thu, 14 Aug 2008 10:15:23 +0000 (UTC) (envelope-from viper@perm.raid.ru) Received: from smtp.ertelecom.ru (smtp.ertelecom.ru [212.33.232.210]) by mx1.freebsd.org (Postfix) with ESMTP id BE0A68FC1E for ; Thu, 14 Aug 2008 10:15:22 +0000 (UTC) (envelope-from viper@perm.raid.ru) Received: from mail.raid.ru ([212.33.232.8]:12106) by smtp.ertelecom.ru with esmtp (Exim) id 1KTYBF-000MWb-M0 for ; Thu, 14 Aug 2008 14:27:37 +0600 Received: from 212.33.232.121 (SquirrelMail authenticated user viper) by mail.raid.ru with HTTP; Thu, 14 Aug 2008 14:27:37 +0600 (YEKST) Message-ID: <31986.212.33.232.121.1218702457.squirrel@mail.raid.ru> Date: Thu, 14 Aug 2008 14:27:37 +0600 (YEKST) From: "Vladimir Korkodinov" To: stable@FreeBSD.org User-Agent: SquirrelMail/1.4.8 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: Subject: Re: HEADS UP: inpcb/inpcbinfo rwlocking: coming to a 7-STABLE branch near you X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: viper@perm.raid.ru List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2008 10:15:23 -0000 Same thing. http://lists.freebsd.org/pipermail/freebsd-net/2008-August/019220.html -- Best regards Vladimir Korkodinov From owner-freebsd-stable@FreeBSD.ORG Thu Aug 14 11:00:12 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7C2101065677; Thu, 14 Aug 2008 11:00:12 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.terabit.net.ua (mail.terabit.net.ua [195.137.202.147]) by mx1.freebsd.org (Postfix) with ESMTP id EE4E48FC0C; Thu, 14 Aug 2008 11:00:11 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from skuns.zoral.com.ua ([91.193.166.194] helo=mail.zoral.com.ua) by mail.terabit.net.ua with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1KTaDd-0004Nr-Ln; Thu, 14 Aug 2008 13:38:13 +0300 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m7EAcAvJ028764 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 Aug 2008 13:38:10 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m7EAcAU1076427; Thu, 14 Aug 2008 13:38:10 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2/Submit) id m7EAc9J5076426; Thu, 14 Aug 2008 13:38:09 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 14 Aug 2008 13:38:09 +0300 From: Kostik Belousov To: John Baldwin Message-ID: <20080814103809.GK1803@deviant.kiev.zoral.com.ua> References: <200808130022.m7D0MCaK082721@freefall.freebsd.org> <20080813134210.GG1803@deviant.kiev.zoral.com.ua> <200808131548.37571.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="enGqbSaueFq5omEL" Content-Disposition: inline In-Reply-To: <200808131548.37571.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua X-Virus-Scanned: mail.terabit.net.ua 1KTaDd-0004Nr-Ln eaa0e42a1505bc85c3fafe971ace7f4d X-Terabit: YES Cc: amd64@freebsd.org, stable@freebsd.org, freebsd-stable@freebsd.org, peter@freebsd.org Subject: Re: Pending MFC Reminder [cvs commit: src/sys/amd64/amd64 cpu_switch.S genassym.c src/sys/amd64/ia32 ia32_signal.c src/sys/amd64/include pcb.h src/sys/amd64/linux32 linux32_machdep.c] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2008 11:00:12 -0000 --enGqbSaueFq5omEL Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 13, 2008 at 03:48:37PM -0400, John Baldwin wrote: > On Wednesday 13 August 2008 09:42:10 am Kostik Belousov wrote: > > On Wed, Aug 13, 2008 at 12:22:12AM +0000, MFC Notification Service wrot= e: > > > Dear Konstantin Belousov, > > >=20 > > > As you have requested, I would like to notify you that you have > > > committed a change that may be MFC'ed now, as a testing period > > > specified at the time of that commit is over. > > >=20 > > > For reference purposes following is a copy of your original > > > commit message. > > >=20 > > > Regards, > > >=20 > > > Maxim "MFC Reminder" Sobolev > > > P.S. Please contact Maxim Sobolev if you > > > believe that you received this message due to an error. > > >=20 > > > kib 2008-07-30 11:30:55 UTC > > >=20 > > > FreeBSD src repository > > >=20 > > > Modified files: > > > sys/amd64/amd64 cpu_switch.S genassym.c=20 > > > sys/amd64/ia32 ia32_signal.c=20 > > > sys/amd64/include pcb.h=20 > > > sys/amd64/linux32 linux32_machdep.c=20 > > > Log: > > > SVN rev 180992 on 2008-07-30 11:30:55Z by kib > > > =20 > > > Bring back the save/restore of the %ds, %es, %fs and %gs registers = for > > > the 32bit images on amd64. > > > =20 > > > Change the semantic of the PCB_32BIT pcb flag to request the context > > > switch code to operate on the segment registers. Its previous meani= ng > > > of saving or restoring the %gs base offset is assigned to the new > > > PCB_GS32BIT flag. > > > =20 > > > FreeBSD 32bit image activator sets the PCB_32BIT flag, while Linux = 32bit > > > emulation sets PCB_32BIT | PCB_GS32BIT. > > > =20 > > > Reviewed by: peter > > > MFC after: 2 weeks > > > =20 > > > Revision Changes Path > > > 1.162 +29 -18 src/sys/amd64/amd64/cpu_switch.S > > > 1.169 +1 -0 src/sys/amd64/amd64/genassym.c > > > 1.18 +1 -1 src/sys/amd64/ia32/ia32_signal.c > > > 1.65 +1 -0 src/sys/amd64/include/pcb.h > > > 1.47 +1 -1 src/sys/amd64/linux32/linux32_machdep.c > >=20 > > This appeared to be a not quite trivial MFC to perform. The reason for > > complication is that the HEAD code for amd64 context switch was changed, > > in particular by the r177535 by peter@. > >=20 > > The r177535 formally requires r177533 for the definition of the > > TDP_KTHREAD symbol for asm. The definition is needed for optimization > > of the context switch to the "pure kernel thread", introduced in > > r173004 that is not MFCed either, and possibly never be. > >=20 > > I do not want to backport the code to the old context switch, that would > > mean a rewrite from scratch. Instead, I merged the r177535 (optimization > > of context switch by peter@), and commented out corresponding test in > > the cpu_switch.S for the TDP_KTHREAD. > >=20 > > I would be glad to get an opinions on the approach taken, and especially > > for the wider testing on the RELENG_7/amd64. The problem better be > > solved for 7.1. > >=20 > > The patch: > > http://people.freebsd.org/~kib/misc/amd64_ctx.releng_7.4.patch >=20 > FYI, in 6.x and 7.x there is P_KTHREAD in p_flags that is what TDP_KTHREA= D=20 > replaced. Thank you for note. I updated the patch to use P_KTHREAD. http://people.freebsd.org/~kib/misc/amd64_ctx.releng_7.5.patch --enGqbSaueFq5omEL Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkikCxEACgkQC3+MBN1Mb4ikqwCfa0Bd1s5TCfwDD49RcriySSfm 2zEAnAttpLx4EQZltMzlr3mHZCrlYuAv =sON8 -----END PGP SIGNATURE----- --enGqbSaueFq5omEL-- From owner-freebsd-stable@FreeBSD.ORG Thu Aug 14 11:00:12 2008 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7C2101065677; Thu, 14 Aug 2008 11:00:12 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.terabit.net.ua (mail.terabit.net.ua [195.137.202.147]) by mx1.freebsd.org (Postfix) with ESMTP id EE4E48FC0C; Thu, 14 Aug 2008 11:00:11 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from skuns.zoral.com.ua ([91.193.166.194] helo=mail.zoral.com.ua) by mail.terabit.net.ua with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1KTaDd-0004Nr-Ln; Thu, 14 Aug 2008 13:38:13 +0300 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m7EAcAvJ028764 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 Aug 2008 13:38:10 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m7EAcAU1076427; Thu, 14 Aug 2008 13:38:10 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2/Submit) id m7EAc9J5076426; Thu, 14 Aug 2008 13:38:09 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 14 Aug 2008 13:38:09 +0300 From: Kostik Belousov To: John Baldwin Message-ID: <20080814103809.GK1803@deviant.kiev.zoral.com.ua> References: <200808130022.m7D0MCaK082721@freefall.freebsd.org> <20080813134210.GG1803@deviant.kiev.zoral.com.ua> <200808131548.37571.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="enGqbSaueFq5omEL" Content-Disposition: inline In-Reply-To: <200808131548.37571.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua X-Virus-Scanned: mail.terabit.net.ua 1KTaDd-0004Nr-Ln eaa0e42a1505bc85c3fafe971ace7f4d X-Terabit: YES Cc: amd64@freebsd.org, stable@freebsd.org, freebsd-stable@freebsd.org, peter@freebsd.org Subject: Re: Pending MFC Reminder [cvs commit: src/sys/amd64/amd64 cpu_switch.S genassym.c src/sys/amd64/ia32 ia32_signal.c src/sys/amd64/include pcb.h src/sys/amd64/linux32 linux32_machdep.c] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2008 11:00:12 -0000 --enGqbSaueFq5omEL Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 13, 2008 at 03:48:37PM -0400, John Baldwin wrote: > On Wednesday 13 August 2008 09:42:10 am Kostik Belousov wrote: > > On Wed, Aug 13, 2008 at 12:22:12AM +0000, MFC Notification Service wrot= e: > > > Dear Konstantin Belousov, > > >=20 > > > As you have requested, I would like to notify you that you have > > > committed a change that may be MFC'ed now, as a testing period > > > specified at the time of that commit is over. > > >=20 > > > For reference purposes following is a copy of your original > > > commit message. > > >=20 > > > Regards, > > >=20 > > > Maxim "MFC Reminder" Sobolev > > > P.S. Please contact Maxim Sobolev if you > > > believe that you received this message due to an error. > > >=20 > > > kib 2008-07-30 11:30:55 UTC > > >=20 > > > FreeBSD src repository > > >=20 > > > Modified files: > > > sys/amd64/amd64 cpu_switch.S genassym.c=20 > > > sys/amd64/ia32 ia32_signal.c=20 > > > sys/amd64/include pcb.h=20 > > > sys/amd64/linux32 linux32_machdep.c=20 > > > Log: > > > SVN rev 180992 on 2008-07-30 11:30:55Z by kib > > > =20 > > > Bring back the save/restore of the %ds, %es, %fs and %gs registers = for > > > the 32bit images on amd64. > > > =20 > > > Change the semantic of the PCB_32BIT pcb flag to request the context > > > switch code to operate on the segment registers. Its previous meani= ng > > > of saving or restoring the %gs base offset is assigned to the new > > > PCB_GS32BIT flag. > > > =20 > > > FreeBSD 32bit image activator sets the PCB_32BIT flag, while Linux = 32bit > > > emulation sets PCB_32BIT | PCB_GS32BIT. > > > =20 > > > Reviewed by: peter > > > MFC after: 2 weeks > > > =20 > > > Revision Changes Path > > > 1.162 +29 -18 src/sys/amd64/amd64/cpu_switch.S > > > 1.169 +1 -0 src/sys/amd64/amd64/genassym.c > > > 1.18 +1 -1 src/sys/amd64/ia32/ia32_signal.c > > > 1.65 +1 -0 src/sys/amd64/include/pcb.h > > > 1.47 +1 -1 src/sys/amd64/linux32/linux32_machdep.c > >=20 > > This appeared to be a not quite trivial MFC to perform. The reason for > > complication is that the HEAD code for amd64 context switch was changed, > > in particular by the r177535 by peter@. > >=20 > > The r177535 formally requires r177533 for the definition of the > > TDP_KTHREAD symbol for asm. The definition is needed for optimization > > of the context switch to the "pure kernel thread", introduced in > > r173004 that is not MFCed either, and possibly never be. > >=20 > > I do not want to backport the code to the old context switch, that would > > mean a rewrite from scratch. Instead, I merged the r177535 (optimization > > of context switch by peter@), and commented out corresponding test in > > the cpu_switch.S for the TDP_KTHREAD. > >=20 > > I would be glad to get an opinions on the approach taken, and especially > > for the wider testing on the RELENG_7/amd64. The problem better be > > solved for 7.1. > >=20 > > The patch: > > http://people.freebsd.org/~kib/misc/amd64_ctx.releng_7.4.patch >=20 > FYI, in 6.x and 7.x there is P_KTHREAD in p_flags that is what TDP_KTHREA= D=20 > replaced. Thank you for note. I updated the patch to use P_KTHREAD. http://people.freebsd.org/~kib/misc/amd64_ctx.releng_7.5.patch --enGqbSaueFq5omEL Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkikCxEACgkQC3+MBN1Mb4ikqwCfa0Bd1s5TCfwDD49RcriySSfm 2zEAnAttpLx4EQZltMzlr3mHZCrlYuAv =sON8 -----END PGP SIGNATURE----- --enGqbSaueFq5omEL-- From owner-freebsd-stable@FreeBSD.ORG Thu Aug 14 11:33:47 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 06E9B1065675 for ; Thu, 14 Aug 2008 11:33:47 +0000 (UTC) (envelope-from markus@vervier.info) Received: from mail.system360.de (mail.system360.de [84.254.79.40]) by mx1.freebsd.org (Postfix) with ESMTP id AD43E8FC18 for ; Thu, 14 Aug 2008 11:33:46 +0000 (UTC) (envelope-from markus@vervier.info) Received: from localhost (mail [84.254.79.40]) by mail.system360.de (Postfix) with ESMTP id 977BC10085E for ; Thu, 14 Aug 2008 13:44:04 +0200 (CEST) X-Virus-Scanned: amavisd-new at system360.de Received: from mail.system360.de ([84.254.79.40]) by localhost (mail.system360.de [84.254.79.40]) (amavisd-new, port 10024) with ESMTP id YAbYSMM-qeFf for ; Thu, 14 Aug 2008 13:43:59 +0200 (CEST) Received: from [192.168.2.15] (p5B395266.dip.t-dialin.net [91.57.82.102]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.system360.de (Postfix) with ESMTP id 51F9D100849 for ; Thu, 14 Aug 2008 13:43:59 +0200 (CEST) Message-ID: <48A41816.3040904@vervier.info> Date: Thu, 14 Aug 2008 13:33:42 +0200 From: Markus Vervier User-Agent: Thunderbird 2.0.0.14 (X11/20080421) MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <489C4129.4090303@vervier.info> <489C88DB.6030000@vervier.info> <2a41acea0808081131m1eddc4caib0963c8a5443afd2@mail.gmail.com> <200808110819.53914.josh@tcbug.org> <20080811140249.GA27379@eos.sc1.parodius.com> <2a41acea0808110928h10d54441o7d49b11a60406934@mail.gmail.com> <48A0A1D9.8030601@vervier.info> <2a41acea0808111340o7b506804u9e4c95f1af22b95c@mail.gmail.com> <48A2B1CB.7060303@vervier.info> <2a41acea0808130822i5f336b1ci15099f27a3a7c13d@mail.gmail.com> <2a41acea0808131210r6371b532i93f1ae6963d1f1b9@mail.gmail.com> In-Reply-To: <2a41acea0808131210r6371b532i93f1ae6963d1f1b9@mail.gmail.com> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: em(4) on FreeBSD is sometimes annoying X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2008 11:33:47 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jack Vogel wrote: | I have reproduced the problem, you are correct. Thank you for | persisting thru my doubts :) Always persisting to help improving FreeBSD. Another odd thing I noticed today: When dual-booting Windows on the same machine and doing a warm-reboot from Windows to FreeBSD, you _do_ get a link with the procedure I described yesterday.. So there seems to be some setting which is lost after cold-boot or some EEPROM setting which is changed somehow. | OH, I should note that as long as you put in a cable before you | ifconfig up its fine so | its not that hard to work around the issue. I completly forgot about the issue until now, after I noticed it some time ago when being overworked. :-( The situation just does not occur very often in times of wireless LAN / Docking Stations. :-) - -- Markus -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkikGBMACgkQFhK2gHeM2QOLpACfdX4IyNSivy+TgAJBhKgZUwP2 iiIAoNrPUTE0veViP7Zklm7jD25m7Aad =DrBs -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Thu Aug 14 12:54:47 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C3F55106566C for ; Thu, 14 Aug 2008 12:54:47 +0000 (UTC) (envelope-from caelian@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.155]) by mx1.freebsd.org (Postfix) with ESMTP id 4AAC58FC08 for ; Thu, 14 Aug 2008 12:54:47 +0000 (UTC) (envelope-from caelian@gmail.com) Received: by fg-out-1718.google.com with SMTP id l26so768304fgb.35 for ; Thu, 14 Aug 2008 05:54:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:subject :message-id:in-reply-to:references:x-mailer:mime-version :content-type:content-transfer-encoding; bh=QC+noCOl1OHN2nCUi3yZ3APHQtQTqVVuCJmeDmdQmKw=; b=FJXCPTYXV3/SCxQn4INN64nyJlTtFW0hHY2TCiO7gcznJwOeRyds/RVm3DdO7Ew5DT ECR99uKqTlcp9jfCNFZSjNhKKDDmOQhcd+COp9xCwwF9yBk/6IXkKtrycRZebpiomoSx GqZnPXvU49aC5OyNSoWcjEAAn2SWmqyqN2OJw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type:content-transfer-encoding; b=pPk2KcS0tzKbZ3NDi6lmrsD675KYuyY2U4dZCizTETXt3N+Yet3Q2qoZSeF6+BGDjv 5GXlY7XWJm/1mf/t7xKJD2kGK1PYS1yC3aHsE4lJBBoIY6ZoAAMw5DTSB3Ao6kjXWloz LtttPOamHCmDOd2rAI9yi408/a3RH7wYNETYQ= Received: by 10.86.70.3 with SMTP id s3mr287575fga.51.1218718482790; Thu, 14 Aug 2008 05:54:42 -0700 (PDT) Received: from nebuchadnezzar ( [84.129.193.103]) by mx.google.com with ESMTPS id 12sm4492267fgg.0.2008.08.14.05.54.42 (version=SSLv3 cipher=RC4-MD5); Thu, 14 Aug 2008 05:54:42 -0700 (PDT) Date: Thu, 14 Aug 2008 14:54:41 +0200 From: Pascal Hofstee To: freebsd-stable@freebsd.org Message-ID: <20080814145441.0e6130d7@nebuchadnezzar> In-Reply-To: <20080814143546.5e1a6a16@nebuchadnezzar> References: <20080814143546.5e1a6a16@nebuchadnezzar> X-Mailer: Claws Mail 3.3.1 (GTK+ 2.12.9; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: CPUTYPE weirdness X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2008 12:54:47 -0000 On Thu, 14 Aug 2008 14:35:46 +0200 Pascal Hofstee wrote: > I just installed a fresh FreeBSD/amd64 7.0-RELEASE and trying to > update to RELENG_7_0. > > I added CPUTYPE ?= core2 to my /etc/src.conf and every call to make > in /usr/src now gives me the error > > "/usr/src/Makefile.inc1", line 142: CPUTYPE global should be set > with ?=. > *** Error code 1 > > Anyone has any idea what i am doing wrong here ... this same mechanism > has worked flawlessly on several other systems (although they were not > RELENG_7_0) ? Ok ... minor follow up. I found one way to "resolve" this problem, which consists of besides /etc/src.conf also creating an /etc/make.conf that contains a single "CPUTYPE ?= core2". Why this seems to be necessary i don't quite understand yet though. -- Pascal Hofstee From owner-freebsd-stable@FreeBSD.ORG Thu Aug 14 13:00:47 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AEB44106564A for ; Thu, 14 Aug 2008 13:00:47 +0000 (UTC) (envelope-from caelian@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.156]) by mx1.freebsd.org (Postfix) with ESMTP id 3CDB38FC17 for ; Thu, 14 Aug 2008 13:00:46 +0000 (UTC) (envelope-from caelian@gmail.com) Received: by fg-out-1718.google.com with SMTP id l26so771357fgb.35 for ; Thu, 14 Aug 2008 06:00:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:subject :message-id:x-mailer:mime-version:content-type :content-transfer-encoding; bh=cX+kCPqZ4ldaSdvF2muVkqQU4o7aT2ETikYNNdyumlI=; b=wFe0jnAdHWvpRpcCNSYeKZFf/g3kN2o57antVvQbW5Zh22S/YCuzXh2X4HAupkZpQO F35uWW6f9Wo6x5BIMobuC4urlaKGlQ0HzOeay18MytxeP4AVGTAdertP8KqmMGvu5Frj cijcLuH/ICT9lvqJsDRiejNYuyFB1dXdhyA54= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:subject:message-id:x-mailer:mime-version:content-type :content-transfer-encoding; b=GjVV1/4YfYNHK5qmYhU2b++s8tbIX67NilHAh8h9DejwLz0I/Aump5B4kBwQdraXwK 71QdXXFbVJQK5jPUA1begtlXRUosbguIkqJkN7KiBqCJRxt5MmCft5+6kPrBZxgNKnP0 2VtCkTwtTyf6UEAmqwYtdqJYLwRaagND+cWIw= Received: by 10.180.227.4 with SMTP id z4mr656525bkg.63.1218717350069; Thu, 14 Aug 2008 05:35:50 -0700 (PDT) Received: from nebuchadnezzar ( [84.129.193.103]) by mx.google.com with ESMTPS id l19sm4438388fgb.7.2008.08.14.05.35.49 (version=SSLv3 cipher=RC4-MD5); Thu, 14 Aug 2008 05:35:49 -0700 (PDT) Date: Thu, 14 Aug 2008 14:35:46 +0200 From: Pascal Hofstee To: freebsd-stable@freebsd.org Message-ID: <20080814143546.5e1a6a16@nebuchadnezzar> X-Mailer: Claws Mail 3.3.1 (GTK+ 2.12.9; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: CPUTYPE weirdness X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2008 13:00:47 -0000 Hi, I just installed a fresh FreeBSD/amd64 7.0-RELEASE and trying to update to RELENG_7_0. I added CPUTYPE ?= core2 to my /etc/src.conf and every call to make in /usr/src now gives me the error "/usr/src/Makefile.inc1", line 142: CPUTYPE global should be set with ?=. *** Error code 1 Anyone has any idea what i am doing wrong here ... this same mechanism has worked flawlessly on several other systems (although they were not RELENG_7_0) ? -- Pascal Hofstee From owner-freebsd-stable@FreeBSD.ORG Thu Aug 14 13:09:55 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 23622106568F for ; Thu, 14 Aug 2008 13:09:55 +0000 (UTC) (envelope-from jdc@parodius.com) Received: from mx01.sc1.parodius.com (mx01.sc1.parodius.com [72.20.106.3]) by mx1.freebsd.org (Postfix) with ESMTP id 11C448FC17 for ; Thu, 14 Aug 2008 13:09:55 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id F11EA1CC0BB; Thu, 14 Aug 2008 06:09:54 -0700 (PDT) Date: Thu, 14 Aug 2008 06:09:54 -0700 From: Jeremy Chadwick To: Pascal Hofstee Message-ID: <20080814130954.GA25304@eos.sc1.parodius.com> References: <20080814143546.5e1a6a16@nebuchadnezzar> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080814143546.5e1a6a16@nebuchadnezzar> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-stable@freebsd.org Subject: Re: CPUTYPE weirdness X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2008 13:09:55 -0000 On Thu, Aug 14, 2008 at 02:35:46PM +0200, Pascal Hofstee wrote: > I just installed a fresh FreeBSD/amd64 7.0-RELEASE and trying to update > to RELENG_7_0. > > I added CPUTYPE ?= core2 to my /etc/src.conf and every call to make > in /usr/src now gives me the error > > "/usr/src/Makefile.inc1", line 142: CPUTYPE global should be set > with ?=. > *** Error code 1 > > Anyone has any idea what i am doing wrong here ... this same mechanism > has worked flawlessly on several other systems (although they were not > RELENG_7_0) ? 1) Remove the space after the word "CPUTYPE", e.g.: CPUTYPE?=core2 You can put a tab after the "=" if you want, e.g.: CPUTYPE?= core2 2) According to some very old mail I have (will dig it up if you want), Core2Duo users should be using CPUTYPE?=nocona. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Thu Aug 14 13:10:57 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 29BED1065678 for ; Thu, 14 Aug 2008 13:10:57 +0000 (UTC) (envelope-from jdc@parodius.com) Received: from mx01.sc1.parodius.com (mx01.sc1.parodius.com [72.20.106.3]) by mx1.freebsd.org (Postfix) with ESMTP id 177B98FC15 for ; Thu, 14 Aug 2008 13:10:57 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id EEDE41CC0BD; Thu, 14 Aug 2008 06:10:56 -0700 (PDT) Date: Thu, 14 Aug 2008 06:10:56 -0700 From: Jeremy Chadwick To: Pascal Hofstee Message-ID: <20080814131056.GB25304@eos.sc1.parodius.com> References: <20080814143546.5e1a6a16@nebuchadnezzar> <20080814145441.0e6130d7@nebuchadnezzar> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080814145441.0e6130d7@nebuchadnezzar> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-stable@freebsd.org Subject: Re: CPUTYPE weirdness X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2008 13:10:57 -0000 On Thu, Aug 14, 2008 at 02:54:41PM +0200, Pascal Hofstee wrote: > On Thu, 14 Aug 2008 14:35:46 +0200 > Pascal Hofstee wrote: > > > I just installed a fresh FreeBSD/amd64 7.0-RELEASE and trying to > > update to RELENG_7_0. > > > > I added CPUTYPE ?= core2 to my /etc/src.conf and every call to make > > in /usr/src now gives me the error > > > > "/usr/src/Makefile.inc1", line 142: CPUTYPE global should be set > > with ?=. > > *** Error code 1 > > > > Anyone has any idea what i am doing wrong here ... this same mechanism > > has worked flawlessly on several other systems (although they were not > > RELENG_7_0) ? > > Ok ... minor follow up. > I found one way to "resolve" this problem, which consists of > besides /etc/src.conf also creating an /etc/make.conf that contains a > single "CPUTYPE ?= core2". Another mistake: You do not declare CPUTYPE in src.conf; you put it in make.conf. Please read the src.conf(5) and make.conf(5) manpages to distinguish the difference in functionality. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Thu Aug 14 13:23:24 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AA272106566B; Thu, 14 Aug 2008 13:23:24 +0000 (UTC) (envelope-from stefan.lambrev@moneybookers.com) Received: from blah.sun-fish.com (blah.sun-fish.com [217.18.249.150]) by mx1.freebsd.org (Postfix) with ESMTP id 5B4818FC14; Thu, 14 Aug 2008 13:23:24 +0000 (UTC) (envelope-from stefan.lambrev@moneybookers.com) Received: by blah.sun-fish.com (Postfix, from userid 1002) id 9F2961B10EFE; Thu, 14 Aug 2008 15:23:22 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on malcho.cmotd.com X-Spam-Level: X-Spam-Status: No, score=-10.6 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.2.4 Received: from hater.haters.org (hater.cmotd.com [192.168.3.125]) by blah.sun-fish.com (Postfix) with ESMTP id 1B98D1B10CAA; Thu, 14 Aug 2008 15:23:19 +0200 (CEST) Message-ID: <48A431C6.1050401@moneybookers.com> Date: Thu, 14 Aug 2008 16:23:18 +0300 From: Stefan Lambrev User-Agent: Thunderbird 2.0.0.16 (X11/20080813) MIME-Version: 1.0 To: Jeremy Chadwick References: <20080814143546.5e1a6a16@nebuchadnezzar> <20080814130954.GA25304@eos.sc1.parodius.com> In-Reply-To: <20080814130954.GA25304@eos.sc1.parodius.com> Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.93.3/8035/Thu Aug 14 06:07:53 2008 on blah.cmotd.com X-Virus-Status: Clean Cc: freebsd-stable@freebsd.org, Pascal Hofstee Subject: Re: CPUTYPE weirdness X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2008 13:23:24 -0000 Jeremy Chadwick wrote: > On Thu, Aug 14, 2008 at 02:35:46PM +0200, Pascal Hofstee wrote: > >> I just installed a fresh FreeBSD/amd64 7.0-RELEASE and trying to update >> to RELENG_7_0. >> >> I added CPUTYPE ?= core2 to my /etc/src.conf and every call to make >> in /usr/src now gives me the error >> >> "/usr/src/Makefile.inc1", line 142: CPUTYPE global should be set >> with ?=. >> *** Error code 1 >> >> Anyone has any idea what i am doing wrong here ... this same mechanism >> has worked flawlessly on several other systems (although they were not >> RELENG_7_0) ? >> > > 1) Remove the space after the word "CPUTYPE", e.g.: > > CPUTYPE?=core2 > > You can put a tab after the "=" if you want, e.g.: > > CPUTYPE?= core2 > > 2) According to some very old mail I have (will dig it up if you want), > Core2Duo users should be using CPUTYPE?=nocona. > This should be fixed long time ago. core2 is alias for nocona but the idea is users to be ready when additional optimization for core2 are added. -- Best Wishes, Stefan Lambrev ICQ# 24134177 From owner-freebsd-stable@FreeBSD.ORG Thu Aug 14 13:38:12 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8B9C5106568D for ; Thu, 14 Aug 2008 13:38:12 +0000 (UTC) (envelope-from k@kevinkevin.com) Received: from mail-gx0-f17.google.com (mail-gx0-f17.google.com [209.85.217.17]) by mx1.freebsd.org (Postfix) with ESMTP id 4B75A8FC0C for ; Thu, 14 Aug 2008 13:38:12 +0000 (UTC) (envelope-from k@kevinkevin.com) Received: by gxk10 with SMTP id 10so2401040gxk.19 for ; Thu, 14 Aug 2008 06:38:11 -0700 (PDT) Received: by 10.151.111.15 with SMTP id o15mr1822638ybm.7.1218721091312; Thu, 14 Aug 2008 06:38:11 -0700 (PDT) Received: from kevin ( [76.10.166.187]) by mx.google.com with ESMTPS id s27sm4675532qbs.12.2008.08.14.06.38.09 (version=SSLv3 cipher=RC4-MD5); Thu, 14 Aug 2008 06:38:09 -0700 (PDT) From: "Kevin" To: Date: Thu, 14 Aug 2008 09:37:49 -0400 Message-ID: <004c01c8fe12$f2386df0$d6a949d0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 thread-index: Acj+EvCbUrkQ+irrRtaXNX4PTx0F2w== Content-Language: en-us Subject: RTL8187 drivers for FreeBSD (usb wlan device) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2008 13:38:12 -0000 I'm curious about getting my RTL8187 WLAN Usb device to work under freebsd. Has anyone got a rtl8187 based wlan stick working with freebsd? As far I know ndisgen won't work because it does not support usb devices. When I install the windows drivers via ndisgen , there are kernel error messages reported. FreeBSD detects the device when I initially plug it in, but nothing more becomes of that. There are debian / linux drivers available for this device, however I know nothing about porting linux drivers to FreeBSD, nor do I really want to wipe my laptop and put debian on it ;) Any advice regarding these drivers being already available or ported somewhere, or perhaps any advice for someone to help facilitate the driver being ported would be greatly appreciated! Thanks , Kevin K. From owner-freebsd-stable@FreeBSD.ORG Thu Aug 14 14:29:23 2008 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D2929106569F; Thu, 14 Aug 2008 14:29:23 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id A3E8B8FC22; Thu, 14 Aug 2008 14:29:23 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m7EETGpk028489; Thu, 14 Aug 2008 10:29:16 -0400 (EDT) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.8/8.13.3) with ESMTP id m7EETFMd043323 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 Aug 2008 10:29:16 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <200808141429.m7EETFMd043323@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 14 Aug 2008 10:29:09 -0400 To: viper@perm.raid.ru, stable@freebsd.org From: Mike Tancsa In-Reply-To: <31986.212.33.232.121.1218702457.squirrel@mail.raid.ru> References: <31986.212.33.232.121.1218702457.squirrel@mail.raid.ru> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: Re: broken routing / arp (was HEADS UP: inpcb/inpcbinfo rwlocking: coming to a 7-STABLE branch near you) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2008 14:29:23 -0000 At 04:27 AM 8/14/2008, Vladimir Korkodinov wrote: >Same thing. > >http://lists.freebsd.org/pipermail/freebsd-net/2008-August/019220.html > Well, that narrows it down a bit since you are not running with Intel nics. It seems to be in the commits below between date=2008.07.30.18.00.00 and date=2008.07.31.00.00.00 Updating collection src-all/cvs Edit src/sys/conf/files Add delta 1.1243.2.32 2008.07.30.20.35.41 kmacy Checkout src/sys/dev/e1000/LICENSE Checkout src/sys/dev/e1000/README Checkout src/sys/dev/e1000/e1000_80003es2lan.c Checkout src/sys/dev/e1000/e1000_80003es2lan.h Checkout src/sys/dev/e1000/e1000_82540.c Checkout src/sys/dev/e1000/e1000_82541.c Checkout src/sys/dev/e1000/e1000_82541.h Checkout src/sys/dev/e1000/e1000_82542.c Checkout src/sys/dev/e1000/e1000_82543.c Checkout src/sys/dev/e1000/e1000_82543.h Checkout src/sys/dev/e1000/e1000_82571.c Checkout src/sys/dev/e1000/e1000_82571.h Checkout src/sys/dev/e1000/e1000_82575.c Checkout src/sys/dev/e1000/e1000_82575.h Checkout src/sys/dev/e1000/e1000_api.c Checkout src/sys/dev/e1000/e1000_api.h Checkout src/sys/dev/e1000/e1000_defines.h Checkout src/sys/dev/e1000/e1000_hw.h Checkout src/sys/dev/e1000/e1000_ich8lan.c Checkout src/sys/dev/e1000/e1000_ich8lan.h Checkout src/sys/dev/e1000/e1000_mac.c Checkout src/sys/dev/e1000/e1000_mac.h Checkout src/sys/dev/e1000/e1000_manage.c Checkout src/sys/dev/e1000/e1000_manage.h Checkout src/sys/dev/e1000/e1000_nvm.c Checkout src/sys/dev/e1000/e1000_nvm.h Checkout src/sys/dev/e1000/e1000_osdep.c Checkout src/sys/dev/e1000/e1000_osdep.h Checkout src/sys/dev/e1000/e1000_phy.c Checkout src/sys/dev/e1000/e1000_phy.h Checkout src/sys/dev/e1000/e1000_regs.h Checkout src/sys/dev/e1000/if_em.c Checkout src/sys/dev/e1000/if_em.h Checkout src/sys/dev/e1000/if_igb.h Edit src/sys/kern/kern_synch.c Add delta 1.302.2.3 2008.07.30.18.28.09 rwatson Edit src/sys/kern/sys_process.c Add delta 1.145.2.1 2008.07.30.19.49.10 jhb Edit src/sys/netinet/tcp_subr.c Add delta 1.300.2.4 2008.07.30.20.35.41 kmacy Edit src/sys/netinet/tcp_syncache.c Add delta 1.130.2.9 2008.07.30.20.35.41 kmacy Add delta 1.130.2.10 2008.07.30.20.51.20 kmacy Edit src/sys/netinet/tcp_syncache.h Add delta 1.1.2.1 2008.07.30.20.35.41 kmacy Edit src/sys/netinet/tcp_usrreq.c Add delta 1.163.2.4 2008.07.30.20.35.41 kmacy Edit src/sys/netinet/udp_usrreq.c Add delta 1.218.2.1 2008.07.30.21.23.21 bz Edit src/sys/netinet6/ip6_input.c Add delta 1.95.2.1 2008.07.30.21.23.21 bz Edit src/sys/netinet6/ip6_var.h Add delta 1.39.2.2 2008.07.30.21.23.21 bz Edit src/sys/sys/socket.h Add delta 1.95.2.3 2008.07.30.19.35.40 kmacy Edit src/sys/ufs/ufs/ufs_lookup.c Add delta 1.83.2.2 2008.07.30.21.43.42 jhb Edit src/sys/vm/vm_object.c Add delta 1.385.2.2 2008.07.30.21.43.42 jhb Edit src/sys/vm/vm_object.h Add delta 1.114.2.1 2008.07.30.21.43.42 jhb Edit src/sys/vm/vnode_pager.c Add delta 1.236.2.2 2008.07.30.21.43.42 jhb >-- >Best regards >Vladimir Korkodinov > >_______________________________________________ >freebsd-stable@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-stable >To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Thu Aug 14 14:30:22 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1F28C1065699 for ; Thu, 14 Aug 2008 14:30:22 +0000 (UTC) (envelope-from Johan@double-l.nl) Received: from smtp-vbr1.xs4all.nl (smtp-vbr1.xs4all.nl [194.109.24.21]) by mx1.freebsd.org (Postfix) with ESMTP id AEFA28FC27 for ; Thu, 14 Aug 2008 14:30:21 +0000 (UTC) (envelope-from Johan@double-l.nl) Received: from w2003s01.double-l.local (dpm.xs4all.nl [80.126.205.144]) by smtp-vbr1.xs4all.nl (8.13.8/8.13.8) with ESMTP id m7EEDoSd088715 for ; Thu, 14 Aug 2008 16:13:50 +0200 (CEST) (envelope-from Johan@double-l.nl) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 14 Aug 2008 16:13:51 +0200 Message-ID: <57200BF94E69E54880C9BB1AF714BBCB5DE086@w2003s01.double-l.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: CPUTYPE weirdness Thread-Index: Acj+EWMyg6ffnmYwR5qzC2Va9a9ndwABh4og References: <20080814143546.5e1a6a16@nebuchadnezzar><20080814130954.GA25304@eos.sc1.parodius.com> <48A431C6.1050401@moneybookers.com> From: "Johan Hendriks" To: X-Virus-Scanned: by XS4ALL Virus Scanner Subject: RE: CPUTYPE weirdness X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2008 14:30:22 -0000 >Jeremy Chadwick wrote: >> On Thu, Aug 14, 2008 at 02:35:46PM +0200, Pascal Hofstee wrote: >> =20 >>> I just installed a fresh FreeBSD/amd64 7.0-RELEASE and trying to = update >>> to RELENG_7_0. >>> >>> I added CPUTYPE ?=3D core2 to my /etc/src.conf and every call to = make >>> in /usr/src now gives me the error >>> >>> "/usr/src/Makefile.inc1", line 142: CPUTYPE global should be set >>> with ?=3D. >>> *** Error code 1 >>> >>> Anyone has any idea what i am doing wrong here ... this same = mechanism >>> has worked flawlessly on several other systems (although they were = not >>> RELENG_7_0) ? >>> =20 >> >> 1) Remove the space after the word "CPUTYPE", e.g.: >> >> CPUTYPE?=3Dcore2 >> >> You can put a tab after the "=3D" if you want, e.g.: >> >> CPUTYPE?=3D core2 >> >> 2) According to some very old mail I have (will dig it up if you = want), >> Core2Duo users should be using CPUTYPE?=3Dnocona. >> =20 >This should be fixed long time ago. core2 is alias for nocona but the=20 >idea is users to >be ready when additional optimization for core2 are added. If you install amd64 then you need nocona if you install i386 you will = need presscot. Or use core2 and FreeBSD itself looks at the arch and use nocona or = presscot. That=92s what I understand from what I read on the net Regards, Johan No virus found in this outgoing message. Checked by AVG - http://www.avg.com=20 Version: 8.0.138 / Virus Database: 270.6.3/1611 - Release Date: = 14-8-2008 6:20 From owner-freebsd-stable@FreeBSD.ORG Thu Aug 14 14:34:36 2008 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7A86C1065676 for ; Thu, 14 Aug 2008 14:34:36 +0000 (UTC) (envelope-from jdc@parodius.com) Received: from mx01.sc1.parodius.com (mx01.sc1.parodius.com [72.20.106.3]) by mx1.freebsd.org (Postfix) with ESMTP id 670DE8FC1F for ; Thu, 14 Aug 2008 14:34:36 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id EA2001CC0BE; Thu, 14 Aug 2008 07:34:35 -0700 (PDT) Date: Thu, 14 Aug 2008 07:34:35 -0700 From: Jeremy Chadwick To: Mike Tancsa Message-ID: <20080814143435.GA28316@eos.sc1.parodius.com> References: <31986.212.33.232.121.1218702457.squirrel@mail.raid.ru> <200808141429.m7EETFMd043323@lava.sentex.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200808141429.m7EETFMd043323@lava.sentex.ca> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: stable@freebsd.org, viper@perm.raid.ru Subject: Re: broken routing / arp (was HEADS UP: inpcb/inpcbinfo rwlocking: coming to a 7-STABLE branch near you) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2008 14:34:36 -0000 On Thu, Aug 14, 2008 at 10:29:09AM -0400, Mike Tancsa wrote: > At 04:27 AM 8/14/2008, Vladimir Korkodinov wrote: >> Same thing. >> >> http://lists.freebsd.org/pipermail/freebsd-net/2008-August/019220.html >> > > Well, that narrows it down a bit since you are not running with Intel > nics. It seems to be in the commits below between > date=2008.07.30.18.00.00 > and > date=2008.07.31.00.00.00 You can ignore the src/sys/dev/e1000 commits, since those are specific to Intel NICs -- specifically splitting up em(4) and igb(4). -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Thu Aug 14 14:36:48 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 33651106568C for ; Thu, 14 Aug 2008 14:36:48 +0000 (UTC) (envelope-from jdc@parodius.com) Received: from mx01.sc1.parodius.com (mx01.sc1.parodius.com [72.20.106.3]) by mx1.freebsd.org (Postfix) with ESMTP id 2153C8FC25 for ; Thu, 14 Aug 2008 14:36:48 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id 0AADD1CC0BB; Thu, 14 Aug 2008 07:36:48 -0700 (PDT) Date: Thu, 14 Aug 2008 07:36:48 -0700 From: Jeremy Chadwick To: Johan Hendriks Message-ID: <20080814143648.GB28316@eos.sc1.parodius.com> References: <48A431C6.1050401@moneybookers.com> <57200BF94E69E54880C9BB1AF714BBCB5DE086@w2003s01.double-l.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <57200BF94E69E54880C9BB1AF714BBCB5DE086@w2003s01.double-l.local> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-stable@freebsd.org Subject: Re: CPUTYPE weirdness X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2008 14:36:48 -0000 On Thu, Aug 14, 2008 at 04:13:51PM +0200, Johan Hendriks wrote: > >Jeremy Chadwick wrote: > >> On Thu, Aug 14, 2008 at 02:35:46PM +0200, Pascal Hofstee wrote: > >> > >>> I just installed a fresh FreeBSD/amd64 7.0-RELEASE and trying to update > >>> to RELENG_7_0. > >>> > >>> I added CPUTYPE ?= core2 to my /etc/src.conf and every call to make > >>> in /usr/src now gives me the error > >>> > >>> "/usr/src/Makefile.inc1", line 142: CPUTYPE global should be set > >>> with ?=. > >>> *** Error code 1 > >>> > >>> Anyone has any idea what i am doing wrong here ... this same mechanism > >>> has worked flawlessly on several other systems (although they were not > >>> RELENG_7_0) ? > >>> > >> > >> 1) Remove the space after the word "CPUTYPE", e.g.: > >> > >> CPUTYPE?=core2 > >> > >> You can put a tab after the "=" if you want, e.g.: > >> > >> CPUTYPE?= core2 > >> > >> 2) According to some very old mail I have (will dig it up if you want), > >> Core2Duo users should be using CPUTYPE?=nocona. > >> > >This should be fixed long time ago. core2 is alias for nocona but the > >idea is users to > >be ready when additional optimization for core2 are added. > > If you install amd64 then you need nocona if you install i386 you will need presscot. > Or use core2 and FreeBSD itself looks at the arch and use nocona or presscot. > > That?s what I understand from what I read on the net 1) It's prescott, not presscot. 2) You can use nocona on both i386 and amd64 -- I speak from experience. I'm referring to RELENG_7 by the way; I don't think nocona is recognised by the base system gcc on RELENG_6. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Thu Aug 14 14:40:13 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 31F83106566C for ; Thu, 14 Aug 2008 14:40:13 +0000 (UTC) (envelope-from jdc@parodius.com) Received: from mx01.sc1.parodius.com (mx01.sc1.parodius.com [72.20.106.3]) by mx1.freebsd.org (Postfix) with ESMTP id 1FBA38FC24 for ; Thu, 14 Aug 2008 14:40:13 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id 065301CC0BE; Thu, 14 Aug 2008 07:40:13 -0700 (PDT) Date: Thu, 14 Aug 2008 07:40:12 -0700 From: Jeremy Chadwick To: Johan Hendriks Message-ID: <20080814144012.GA28665@eos.sc1.parodius.com> References: <48A431C6.1050401@moneybookers.com> <57200BF94E69E54880C9BB1AF714BBCB5DE086@w2003s01.double-l.local> <20080814143648.GB28316@eos.sc1.parodius.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080814143648.GB28316@eos.sc1.parodius.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-stable@freebsd.org Subject: Re: CPUTYPE weirdness X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2008 14:40:13 -0000 On Thu, Aug 14, 2008 at 07:36:48AM -0700, Jeremy Chadwick wrote: > 2) You can use nocona on both i386 and amd64 -- I speak from > experience. I'm referring to RELENG_7 by the way; I don't think > nocona is recognised by the base system gcc on RELENG_6. I stand corrected -- you can use it on RELENG_6 as well: $ egrep 'KERNCONF|CPUTYPE' /etc/make.conf KERNCONF=PDSMI_PLUS_i386 CPUTYPE?=nocona $ uname -a FreeBSD anubis.sc1.parodius.com 6.3-PRERELEASE FreeBSD 6.3-PRERELEASE #0: Thu Jan 17 02:09:20 PST 2008 root@anubis.sc1.parodius.com:/usr/obj/usr/src/sys/ANUBIS i386 $ gcc -v Using built-in specs. Configured with: FreeBSD/i386 system compiler Thread model: posix gcc version 3.4.6 [FreeBSD] 20060305 -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Thu Aug 14 15:00:18 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 366221065678 for ; Thu, 14 Aug 2008 15:00:18 +0000 (UTC) (envelope-from k@kevinkevin.com) Received: from mail-gx0-f17.google.com (mail-gx0-f17.google.com [209.85.217.17]) by mx1.freebsd.org (Postfix) with ESMTP id F07198FC19 for ; Thu, 14 Aug 2008 15:00:17 +0000 (UTC) (envelope-from k@kevinkevin.com) Received: by gxk10 with SMTP id 10so2551816gxk.19 for ; Thu, 14 Aug 2008 08:00:17 -0700 (PDT) Received: by 10.151.109.11 with SMTP id l11mr1937465ybm.204.1218726017087; Thu, 14 Aug 2008 08:00:17 -0700 (PDT) Received: from kevin ( [76.10.166.187]) by mx.google.com with ESMTPS id 25sm216058qbw.1.2008.08.14.08.00.15 (version=SSLv3 cipher=RC4-MD5); Thu, 14 Aug 2008 08:00:15 -0700 (PDT) From: "Kevin" To: Date: Thu, 14 Aug 2008 10:59:55 -0400 Message-ID: <005201c8fe1e$6a515c10$3ef41430$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 thread-index: Acj+EvCbUrkQ+irrRtaXNX4PTx0F2wAC3KAA Content-Language: en-us Subject: RTL8187 drivers for FreeBSD (usb wlan device) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2008 15:00:18 -0000 I'm curious about getting my RTL8187 WLAN Usb device to work under freebsd. Has anyone got a rtl8187 based wlan stick working with freebsd? As far I know ndisgen won't work because it does not support usb devices. When I install the windows drivers via ndisgen , there are kernel error messages reported. FreeBSD detects the device when I initially plug it in, but nothing more becomes of that. There are debian / linux drivers available for this device, however I know nothing about porting linux drivers to FreeBSD, nor do I really want to wipe my laptop and put debian on it ;) Any advice regarding these drivers being already available or ported somewhere, or perhaps any advice for someone to help facilitate the driver being ported would be greatly appreciated! Thanks , Kevin K. From owner-freebsd-stable@FreeBSD.ORG Thu Aug 14 15:01:47 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 67E791065692 for ; Thu, 14 Aug 2008 15:01:47 +0000 (UTC) (envelope-from gavin.atkinson@ury.york.ac.uk) Received: from mail-gw1.york.ac.uk (mail-gw1.york.ac.uk [144.32.128.246]) by mx1.freebsd.org (Postfix) with ESMTP id F2E498FC14 for ; Thu, 14 Aug 2008 15:01:46 +0000 (UTC) (envelope-from gavin.atkinson@ury.york.ac.uk) Received: from mail-gw7.york.ac.uk (mail-gw7.york.ac.uk [144.32.129.30]) by mail-gw1.york.ac.uk (8.13.6/8.13.6) with ESMTP id m7EF1gsY001860; Thu, 14 Aug 2008 16:01:42 +0100 (BST) Received: from ury.york.ac.uk ([144.32.108.81]) by mail-gw7.york.ac.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1KTeKc-0007l0-Nd; Thu, 14 Aug 2008 16:01:42 +0100 Received: from ury.york.ac.uk (localhost.york.ac.uk [127.0.0.1]) by ury.york.ac.uk (8.14.2/8.14.2) with ESMTP id m7EF1ggQ072598; Thu, 14 Aug 2008 16:01:42 +0100 (BST) (envelope-from gavin.atkinson@ury.york.ac.uk) Received: from localhost (gavin@localhost) by ury.york.ac.uk (8.14.2/8.14.2/Submit) with ESMTP id m7EF1gH4072595; Thu, 14 Aug 2008 16:01:42 +0100 (BST) (envelope-from gavin.atkinson@ury.york.ac.uk) X-Authentication-Warning: ury.york.ac.uk: gavin owned process doing -bs Date: Thu, 14 Aug 2008 16:01:42 +0100 (BST) From: Gavin Atkinson X-X-Sender: gavin@ury.york.ac.uk To: Kevin In-Reply-To: <004c01c8fe12$f2386df0$d6a949d0$@com> Message-ID: <20080814155037.A29502@ury.york.ac.uk> References: <004c01c8fe12$f2386df0$d6a949d0$@com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-York-MailScanner: Found to be clean X-York-MailScanner-From: gavin.atkinson@ury.york.ac.uk Cc: freebsd-stable@freebsd.org Subject: Re: RTL8187 drivers for FreeBSD (usb wlan device) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2008 15:01:47 -0000 On Thu, 14 Aug 2008, Kevin wrote: > I'm curious about getting my RTL8187 WLAN Usb device to work under freebsd. > Has anyone got a rtl8187 based wlan stick working with freebsd? Be aware that the RTL8187, RTL8187B and RTL8187L are all different chipsets. I believe Linux has two drivers for them, one driver covers two chips. > As far I know ndisgen won't work because it does not support usb devices. > When I install the windows drivers via ndisgen , there are kernel error > messages reported. FreeBSD detects the device when I initially plug it in, > but nothing more becomes of that. Some work on supporting USB under NDIS has been done, it might be worth investigating just how far from completion it is. > There are debian / linux drivers available for this device, however I know > nothing about porting linux drivers to FreeBSD, nor do I really want to wipe > my laptop and put debian on it ;) Linux drivers are often hard to port, purely because they are badly documented and often use "magic" values which may need to be different under FreeBSD. I looked at the code a little while starting my own RTL8087B driver, but ended up preferring to monitor how Windows talked to the device. Note, however, that my driver is nowhere near finished (doesn't even have code to send/receive yet), so there's no point me sending it to you... Gavin From owner-freebsd-stable@FreeBSD.ORG Thu Aug 14 15:03:09 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F48D1065672; Thu, 14 Aug 2008 15:03:09 +0000 (UTC) (envelope-from bazerka@beardz.net) Received: from mail.btshosting.co.uk (mail.btshosting.co.uk [213.228.232.37]) by mx1.freebsd.org (Postfix) with ESMTP id BE8BF8FC3A; Thu, 14 Aug 2008 15:03:08 +0000 (UTC) (envelope-from bazerka@beardz.net) Received: from [192.168.1.65] (host86-148-119-122.range86-148.btcentralplus.com [86.148.119.122]) (authenticated bits=0) by mail.btshosting.co.uk (8.13.8/8.13.8) with ESMTP id m7EEfrJ9018975; Thu, 14 Aug 2008 15:41:53 +0100 Message-ID: <48A4442D.7060203@beardz.net> Date: Thu, 14 Aug 2008 15:41:49 +0100 From: Jase Thew User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Jeremy Chadwick References: <48A431C6.1050401@moneybookers.com> <57200BF94E69E54880C9BB1AF714BBCB5DE086@w2003s01.double-l.local> <20080814143648.GB28316@eos.sc1.parodius.com> In-Reply-To: <20080814143648.GB28316@eos.sc1.parodius.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on 87.117.208.49 X-Virus-Status: Clean Cc: Johan Hendriks , freebsd-stable@freebsd.org Subject: Re: CPUTYPE weirdness X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bazerka@beardz.net List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2008 15:03:09 -0000 Jeremy Chadwick wrote: > On Thu, Aug 14, 2008 at 04:13:51PM +0200, Johan Hendriks wrote: >>> Jeremy Chadwick wrote: >>>> On Thu, Aug 14, 2008 at 02:35:46PM +0200, Pascal Hofstee wrote: >>>> >>>>> I just installed a fresh FreeBSD/amd64 7.0-RELEASE and trying to update >>>>> to RELENG_7_0. >>>>> >>>>> I added CPUTYPE ?= core2 to my /etc/src.conf and every call to make >>>>> in /usr/src now gives me the error >>>>> >>>>> "/usr/src/Makefile.inc1", line 142: CPUTYPE global should be set >>>>> with ?=. >>>>> *** Error code 1 >>>>> >>>>> Anyone has any idea what i am doing wrong here ... this same mechanism >>>>> has worked flawlessly on several other systems (although they were not >>>>> RELENG_7_0) ? >>>>> >>>> 1) Remove the space after the word "CPUTYPE", e.g.: >>>> >>>> CPUTYPE?=core2 >>>> >>>> You can put a tab after the "=" if you want, e.g.: >>>> >>>> CPUTYPE?= core2 >>>> >>>> 2) According to some very old mail I have (will dig it up if you want), >>>> Core2Duo users should be using CPUTYPE?=nocona. >>>> >>> This should be fixed long time ago. core2 is alias for nocona but the >>> idea is users to >>> be ready when additional optimization for core2 are added. >> If you install amd64 then you need nocona if you install i386 you will need presscot. >> Or use core2 and FreeBSD itself looks at the arch and use nocona or presscot. >> >> That?s what I understand from what I read on the net > > 1) It's prescott, not presscot. > > 2) You can use nocona on both i386 and amd64 -- I speak from > experience. I'm referring to RELENG_7 by the way; I don't think > nocona is recognised by the base system gcc on RELENG_6. > nocona is definitely supported by base gcc in RELENG_6_3 and is listed in the gcc manpage : nocona Improved version of Intel Pentium4 CPU with 64-bit extensions, MMX, SSE, SSE2 and SSE3 instruction set support. I have it in my /etc/make.conf for 6.3-REL/amd64 and it works a charm. Regards, Jase. From owner-freebsd-stable@FreeBSD.ORG Thu Aug 14 15:08:06 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2202B1065679 for ; Thu, 14 Aug 2008 15:08:06 +0000 (UTC) (envelope-from k@kevinkevin.com) Received: from mail-gx0-f17.google.com (mail-gx0-f17.google.com [209.85.217.17]) by mx1.freebsd.org (Postfix) with ESMTP id D80B68FC20 for ; Thu, 14 Aug 2008 15:08:05 +0000 (UTC) (envelope-from k@kevinkevin.com) Received: by gxk10 with SMTP id 10so2566215gxk.19 for ; Thu, 14 Aug 2008 08:08:04 -0700 (PDT) Received: by 10.150.182.16 with SMTP id e16mr1949652ybf.180.1218726484413; Thu, 14 Aug 2008 08:08:04 -0700 (PDT) Received: from kevin ( [76.10.166.187]) by mx.google.com with ESMTPS id s27sm4913853qbs.12.2008.08.14.08.08.02 (version=SSLv3 cipher=RC4-MD5); Thu, 14 Aug 2008 08:08:03 -0700 (PDT) From: "Kevin" To: "'Gavin Atkinson'" References: <004c01c8fe12$f2386df0$d6a949d0$@com> <20080814155037.A29502@ury.york.ac.uk> In-Reply-To: <20080814155037.A29502@ury.york.ac.uk> Date: Thu, 14 Aug 2008 11:07:41 -0400 Message-ID: <005501c8fe1f$80f350d0$82d9f270$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 thread-index: Acj+Hq3lflrTN6PaQhWf4vYIBfIAFAAABsEg Content-Language: en-us Cc: freebsd-stable@freebsd.org Subject: RE: RTL8187 drivers for FreeBSD (usb wlan device) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2008 15:08:06 -0000 > Be aware that the RTL8187, RTL8187B and RTL8187L are all different > chipsets. I believe Linux has two drivers for them, one driver covers > two > chips. I believe it is the RTL8187L chipset. The actual device is an Alfa Network "AWUS036H" , product information is http://dplanet.biz/alfa.com/product_info.php?products_id=342 . > Some work on supporting USB under NDIS has been done, it might be worth > investigating just how far from completion it is. I'll look into this -- I believe ndisgen is built into freebsd by default, however I'm not sure. > Linux drivers are often hard to port, purely because they are badly > documented and often use "magic" values which may need to be different > under FreeBSD. I looked at the code a little while starting my own > RTL8087B driver, but ended up preferring to monitor how Windows talked > to > the device. Note, however, that my driver is nowhere near finished > (doesn't even have code to send/receive yet), so there's no point me > sending it to you... Ideally I'd like to utilize a stable port/driver. /usr/ports/devel/linux-kmod-compat was recommended to me (http://info.iet.unipi.it/~luigi/FreeBSD/linux_bsd_kld.html) , however I don't believe this to be a viable option since it was primarily developed to "wrap" drivers for usb webcams. Thanks for your suggestions, I will look into the ndisgen progress in any case. Hopefully USB support is more defined, or will be more defined in the near future. From owner-freebsd-stable@FreeBSD.ORG Thu Aug 14 15:21:30 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6E2371065685 for ; Thu, 14 Aug 2008 15:21:30 +0000 (UTC) (envelope-from ip@doom.ctinet.ru) Received: from hosting.ctinet.ru (hosting.ctinet.ru [213.159.69.2]) by mx1.freebsd.org (Postfix) with ESMTP id EA8718FC34 for ; Thu, 14 Aug 2008 15:21:29 +0000 (UTC) (envelope-from ip@doom.ctinet.ru) Received: from doom.ctinet.ru (doom.ctinet.ru [213.159.64.57]) (authenticated bits=0) by hosting.ctinet.ru (8.14.2/8.14.2) with ESMTP id m7EFAnsL026740 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 Aug 2008 19:10:50 +0400 (MSD) (envelope-from ip@doom.ctinet.ru) Received: from doom.ctinet.ru (localhost [127.0.0.1]) by doom.ctinet.ru (8.14.3/8.14.3) with ESMTP id m7EFAniK032469; Thu, 14 Aug 2008 19:10:49 +0400 (MSD) (envelope-from ip@doom.ctinet.ru) Received: (from ip@localhost) by doom.ctinet.ru (8.14.3/8.14.3/Submit) id m7EFAm6p032468; Thu, 14 Aug 2008 19:10:48 +0400 (MSD) (envelope-from ip) Date: Thu, 14 Aug 2008 19:10:48 +0400 From: Igor Pokrovsky To: Gavin Spomer Message-ID: <20080814151047.GA32430@doom.ctinet.ru> References: <48A31B61020000900001C109@hermes.cwu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48A31B61020000900001C109@hermes.cwu.edu> User-Agent: Mutt/1.4.2.3i Cc: freebsd-stable@freebsd.org Subject: Re: ssh-keygen between SuSE and FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2008 15:21:30 -0000 On Wed, Aug 13, 2008 at 05:35:29PM -0700, Gavin Spomer wrote: > I hope this isn't an invalid topic for this list. I'm on so many lists and I hate to join another one just to get help on one thing. Apologies if it's not. > > I am able to use ssh-keygen to generate keys so that I can ssh from my Mac to any of my SuSE systems or ssh from my Mac to any of my FreeBSD systems, without having to enter my password. When I try the same thing from a SuSE system to a FreeBSD system, (I.E. I run "ssh-keygen -t rsa" on the SuSE system, then copy the id_rsa.pub to my ~/.ssh/authorized_keys file on the FreeBSD system) I get the following message when ssh-ing to the FreeBSD system: > > Enter passphrase for key '/home/myusername/.ssh/id_rsa': > > ... and I have to enter my password. I've Googled, but can't seem to find the answer to my dilemma. Is it generally kind of a pain to do this between platforms? I'm finally very comfortable on FreeBSD and am starting to really get annoyed with SuSE. :( You can generate keys with empty pass phrase, so it won't be asked ;-) -ip From owner-freebsd-stable@FreeBSD.ORG Thu Aug 14 15:29:35 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 366F61065685 for ; Thu, 14 Aug 2008 15:29:35 +0000 (UTC) (envelope-from spomerg@cwu.EDU) Received: from charybdis.cts.cwu.edu (charybdis.cts.cwu.edu [198.104.67.152]) by mx1.freebsd.org (Postfix) with ESMTP id 1F23E8FC23 for ; Thu, 14 Aug 2008 15:29:35 +0000 (UTC) (envelope-from spomerg@cwu.EDU) Received: from CONVERSION-CWU-DAEMON.CHARYBDIS.CTS.CWU.EDU by CHARYBDIS.CTS.CWU.EDU (PMDF V6.4 #31640) id <01MYCC32AQDS000ODA@CHARYBDIS.CTS.CWU.EDU> for freebsd-stable@freebsd.org; Thu, 14 Aug 2008 08:29:34 -0700 (PDT) Received: from hermes.cwu.edu (hermes.cwu.edu [172.16.21.28]) by CHARYBDIS.CTS.CWU.EDU (PMDF V6.4 #31640) with ESMTP id <01MYCC321WZO000N1Z@CHARYBDIS.CTS.CWU.EDU> for freebsd-stable@freebsd.org; Thu, 14 Aug 2008 08:29:34 -0700 (PDT) Received: from cwugate1-MTA by hermes.cwu.edu with Novell_GroupWise; Thu, 14 Aug 2008 08:29:34 -0700 Date: Thu, 14 Aug 2008 08:29:27 -0700 From: Gavin Spomer To: freebsd-stable@freebsd.org Message-id: <48A3ECE7020000900001C150@hermes.cwu.edu> MIME-version: 1.0 X-Mailer: Novell GroupWise Internet Agent 7.0.3 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable Content-disposition: inline Subject: Re: ssh-keygen between SuSE and FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2008 15:29:35 -0000 >>> Lyndon Nerenberg 08/13/08 7:10 PM >>> > You need to start an ssh-agent on the machine you're connecting from = and=20 > populate it with your keychain: >=20 > eval `ssh-agent` > ssh-add >=20 > Add the above to your .profile, or check the Linux PAM implementation = to=20 > see if it has ssh session support. >=20 > --lyndon Thanks. That made it possible for me to ssh from SuSE server to FreeBSD server, = but now when I ssh from my Mac to SuSE server it wants a password now: Enter passphrase for /home/myusername/.ssh/id_rsa: I read the FreeBSD handbook section "14.11.7 ssh-agent and ssh-add" and = don't have anything much more intelligent to say but "I don't understand". = ;) Questions: 1. If the ssh-agent and ssh-add utilities load the keys into memory, = they'd be wiped if I rebooted? 2. Is #1 why I'd add it to my ~/.profile? 3. How am I able to ssh (without a password) from my Mac to SuSE server = or Mac to FreeBSD server when I don't have "eval `ssh-agent`" and "ssh-add" in my .profile on my Mac? From owner-freebsd-stable@FreeBSD.ORG Thu Aug 14 15:30:51 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0E3C0106567D for ; Thu, 14 Aug 2008 15:30:51 +0000 (UTC) (envelope-from spomerg@cwu.EDU) Received: from donald.cts.cwu.edu (donald.cts.cwu.edu [198.104.67.147]) by mx1.freebsd.org (Postfix) with ESMTP id B9CEE8FC1F for ; Thu, 14 Aug 2008 15:30:50 +0000 (UTC) (envelope-from spomerg@cwu.EDU) Received: from CONVERSION-CWU-DAEMON.DONALD.CTS.CWU.EDU by DONALD.CTS.CWU.EDU (PMDF V6.4 #31640) id <01MYCC4MMOEO000S07@DONALD.CTS.CWU.EDU> for freebsd-stable@freebsd.org; Thu, 14 Aug 2008 08:30:50 -0700 (PDT) Received: from hermes.cwu.edu (hermes.cwu.edu [172.16.21.28]) by DONALD.CTS.CWU.EDU (PMDF V6.4 #31640) with ESMTP id <01MYCC4MEFPU000S09@DONALD.CTS.CWU.EDU> for freebsd-stable@freebsd.org; Thu, 14 Aug 2008 08:30:50 -0700 (PDT) Received: from cwugate1-MTA by hermes.cwu.edu with Novell_GroupWise; Thu, 14 Aug 2008 08:30:49 -0700 Date: Thu, 14 Aug 2008 08:30:47 -0700 From: Gavin Spomer To: freebsd-stable@freebsd.org Message-id: <48A3ED37020000900001C154@hermes.cwu.edu> MIME-version: 1.0 X-Mailer: Novell GroupWise Internet Agent 7.0.3 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable Content-disposition: inline Subject: Re: ssh-keygen between SuSE and FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2008 15:30:51 -0000 >=20 >>> Paul Schmehl 08/13/08 7:18 PM >>> > --On August 13, 2008 5:35:29 PM -0700 Gavin Spomer = wrote: > > I am able to use ssh-keygen to generate keys so that I can ssh from my > > Mac to any of my SuSE systems or ssh from my Mac to any of my FreeBSD > > systems, without having to enter my password. When I try the same = thing > > from a SuSE system to a FreeBSD system, (I.E. I run "ssh-keygen -t = rsa" > > on the SuSE system, then copy the id_rsa.pub to my > > ~/.ssh/authorized_keys file on the FreeBSD system) I get the following > > message when ssh-ing to the FreeBSD system: > > > > Enter passphrase for key '/home/myusername/.ssh/id_rsa': >=20 > Just to be clear....you're saying that your key pass*phrase* doesn't = work=20 > and you have to type your pass*word* in instead? Or did you make all = your=20 > previous keys passphrase-less and add a passphrase to this one? >=20 > Paul Schmehl Uh, not sure. Head spinning now. ;) 1. I have a Mac, SuSE server and a FreeBSD server. 2. I can ssh from my Mac to SuSE server without having to type in my = password. 3. I can ssh from my Mac to FreeBSD server without having to type in my = password. 4. I can do #2 and #3 above because I ran "ssh-keygen -t rsa" on my Mac = and copied the id_rsa.pub to my ~/.ssh/authorized_keys files on the SuSE = and FreeBSD servers. 5. I ran the same "ssh-keygen -t rsa" on the SuSE server and copied the = id_rsa.pub to the FreeBSD. 6. I canNOT ssh from the SuSE server to the FreeBSD server withOUT typing = in my password. 7. When I ssh from SuSE server to FreeBSD server, I get prompted: Enter passphrase for key '/home/myusername/.ssh/id_rsa': 8. I want to be able to ssh from SuSE server to FreeBSD server because I = want to run scp via a cron job. I noticed you made a distinction between password and passphrase. Could = you please explain the difference? - Gavin From owner-freebsd-stable@FreeBSD.ORG Thu Aug 14 15:43:02 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 54006106564A for ; Thu, 14 Aug 2008 15:43:02 +0000 (UTC) (envelope-from spomerg@cwu.EDU) Received: from donald.cts.cwu.edu (donald.cts.cwu.edu [198.104.67.147]) by mx1.freebsd.org (Postfix) with ESMTP id C596C8FC1E for ; Thu, 14 Aug 2008 15:43:00 +0000 (UTC) (envelope-from spomerg@cwu.EDU) Received: from CONVERSION-CWU-DAEMON.DONALD.CTS.CWU.EDU by DONALD.CTS.CWU.EDU (PMDF V6.4 #31640) id <01MYCCJPU87K000S07@DONALD.CTS.CWU.EDU> for freebsd-stable@freebsd.org; Thu, 14 Aug 2008 08:43:00 -0700 (PDT) Received: from hermes.cwu.edu (hermes.cwu.edu [172.16.21.28]) by DONALD.CTS.CWU.EDU (PMDF V6.4 #31640) with ESMTP id <01MYCCJPG99U000SSF@DONALD.CTS.CWU.EDU> for freebsd-stable@freebsd.org; Thu, 14 Aug 2008 08:42:59 -0700 (PDT) Received: from cwugate1-MTA by hermes.cwu.edu with Novell_GroupWise; Thu, 14 Aug 2008 08:42:59 -0700 Date: Thu, 14 Aug 2008 08:42:57 -0700 From: Gavin Spomer To: freebsd-stable@freebsd.org Message-id: <48A3F011020000900001C162@hermes.cwu.edu> MIME-version: 1.0 X-Mailer: Novell GroupWise Internet Agent 7.0.3 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable Content-disposition: inline Subject: Re: ssh-keygen between SuSE and FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2008 15:43:02 -0000 > It's not asking for your password. It's asking for your passphrase to > decrypt your private key. Are you running an ssh-agent on the Suse > system?=20 > --=20 > R. Kevin Oberman Aha! Thanks, Kevin. Things are clicking in my brain and I grok now. I just = remembered that when I did ssh-keygen on my mac and then ssh'd to my = servers, it stored the passPHRASE (right?) in my Mac's Keychain too. Thanks everyone. For further reference, can anyone clearly define what topics are valid for = this list? - Gavin From owner-freebsd-stable@FreeBSD.ORG Thu Aug 14 15:44:41 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 39B031065670 for ; Thu, 14 Aug 2008 15:44:41 +0000 (UTC) (envelope-from spomerg@cwu.EDU) Received: from charybdis.cts.cwu.edu (charybdis.cts.cwu.edu [198.104.67.152]) by mx1.freebsd.org (Postfix) with ESMTP id 246E48FC15 for ; Thu, 14 Aug 2008 15:44:41 +0000 (UTC) (envelope-from spomerg@cwu.EDU) Received: from CONVERSION-CWU-DAEMON.CHARYBDIS.CTS.CWU.EDU by CHARYBDIS.CTS.CWU.EDU (PMDF V6.4 #31640) id <01MYCCLSOHHC000ODA@CHARYBDIS.CTS.CWU.EDU> for freebsd-stable@freebsd.org; Thu, 14 Aug 2008 08:44:40 -0700 (PDT) Received: from hermes.cwu.edu (hermes.cwu.edu [172.16.21.28]) by CHARYBDIS.CTS.CWU.EDU (PMDF V6.4 #31640) with ESMTP id <01MYCCLSHI0K000PMV@CHARYBDIS.CTS.CWU.EDU> for freebsd-stable@freebsd.org; Thu, 14 Aug 2008 08:44:40 -0700 (PDT) Received: from cwugate1-MTA by hermes.cwu.edu with Novell_GroupWise; Thu, 14 Aug 2008 08:44:40 -0700 Date: Thu, 14 Aug 2008 08:44:38 -0700 From: Gavin Spomer To: freebsd-stable@freebsd.org Message-id: <48A3F076020000900001C166@hermes.cwu.edu> MIME-version: 1.0 X-Mailer: Novell GroupWise Internet Agent 7.0.3 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable Content-disposition: inline Subject: Re: ssh-keygen between SuSE and FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2008 15:44:41 -0000 >=20 >>> Igor Pokrovsky 08/14/08 8:22 AM >>> > > ... and I have to enter my password. I've Googled, but can't seem to = find the answer to my dilemma. Is it generally kind of a pain to do this = between platforms? I'm finally very comfortable on FreeBSD and am starting = to really get annoyed with SuSE. :( >=20 > You can generate keys with empty pass phrase, so it won't be asked ;-) >=20 > -ip Yes, this works. Any security concerns with doing this? - Gavin From owner-freebsd-stable@FreeBSD.ORG Thu Aug 14 16:32:19 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A0A89106566C for ; Thu, 14 Aug 2008 16:32:19 +0000 (UTC) (envelope-from lists-fbsdstable@shadypond.com) Received: from mailout.easydns.com (mailout.easydns.com [205.210.42.66]) by mx1.freebsd.org (Postfix) with ESMTP id 7318A8FC0C for ; Thu, 14 Aug 2008 16:32:19 +0000 (UTC) (envelope-from lists-fbsdstable@shadypond.com) Received: from guardian.shadypond.com (69-12-173-117.static.humboldt1.com [69.12.173.117]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout.easydns.com (Postfix) with ESMTP id 95D4D4859E for ; Thu, 14 Aug 2008 11:59:52 -0400 (EDT) Received: from slider.shadypond.com (slider.shadypond.com [192.168.1.11]) by guardian.shadypond.com (Postfix) with ESMTPSA id D4B56F1F6 for ; Thu, 14 Aug 2008 16:00:15 +0000 (UTC) From: Pollywog To: freebsd-stable@freebsd.org Date: Thu, 14 Aug 2008 15:59:48 +0000 References: <48A3ECE7020000900001C150@hermes.cwu.edu> In-Reply-To: <48A3ECE7020000900001C150@hermes.cwu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200808141559.49973.lists-fbsdstable@shadypond.com> Subject: Re: ssh-keygen between SuSE and FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2008 16:32:19 -0000 On Thursday 14 August 2008 15:29:27 Gavin Spomer wrote: > >>> Lyndon Nerenberg 08/13/08 7:10 PM >>> > > > > You need to start an ssh-agent on the machine you're connecting from and > > populate it with your keychain: > > > > eval `ssh-agent` > > ssh-add > > > > Add the above to your .profile, or check the Linux PAM implementation to > > see if it has ssh session support. > > > > --lyndon > > Thanks. > > That made it possible for me to ssh from SuSE server to FreeBSD server, but > now when I ssh from my Mac to SuSE server it wants a password now: > > Enter passphrase for /home/myusername/.ssh/id_rsa: > > I read the FreeBSD handbook section "14.11.7 ssh-agent and ssh-add" and > don't have anything much more intelligent to say but "I don't understand". > ;) > > Questions: > > 1. If the ssh-agent and ssh-add utilities load the keys into memory, > they'd be wiped if I rebooted? Yes, rebooting will take the keys out of memory and you would need to use 'ssh-add' on the command line to put the keys and passphrase in memory. The 'ssh-add -D' command removes the keys when you are done but are not logging out. > > 2. Is #1 why I'd add it to my ~/.profile? This is so that ssh-agent is set when you login at a console. I don't know about Mac but some Linux distributions have session scripts so that this is done for you when you start a KDE session. I don't believe ~/.profile will be read unless you login at a console or xterm or similar. When you add stuff to your ~/.profile, I recommend doing it on a separate account first. I once added those lines on a Linux system and was locked out on that account but I was able to get in with another account, su to root, and remove the lines in the affected user ~/.profile and then I was no longer locked out. > > 3. How am I able to ssh (without a password) from my Mac to SuSE server > or Mac to FreeBSD server when I don't have "eval `ssh-agent`" and "ssh-add" > in my .profile on my Mac? You can do 'ssh-agent bash' followed by 'ssh-add' but this will not work until you have generated your SSH keys with: ssh-keygen -t rsa -b 1024 or ssh-keygen -t dsa -b 1024 or similar. Until you do that, you have to use your login password and cannot use a passphrase since you have not set one. Setting the passphrase is part of the process of generating your SSH keys. BTW I do not know if you are using the "keychain" utility. Be very careful with it. It can be confusing. I found it inconvenient to use and no longer use it. There are some fine SSH tutorials online, I believe "OnLamp" has some. Just make sure they are not more than about 3 yrs old. From owner-freebsd-stable@FreeBSD.ORG Thu Aug 14 16:43:30 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E341A1065674 for ; Thu, 14 Aug 2008 16:43:30 +0000 (UTC) (envelope-from mh@kernel32.de) Received: from crivens.kernel32.de (crivens.terrorteam.de [81.169.171.191]) by mx1.freebsd.org (Postfix) with ESMTP id B36B58FC23 for ; Thu, 14 Aug 2008 16:43:30 +0000 (UTC) (envelope-from mh@kernel32.de) Received: from kernel32.de (localhost [127.0.0.1]) by crivens.kernel32.de (Postfix) with ESMTP id 8AF60B0297; Thu, 14 Aug 2008 18:43:28 +0200 (CEST) MIME-Version: 1.0 Date: Thu, 14 Aug 2008 18:43:28 +0200 From: Marian Hettwer To: Gavin Spomer In-Reply-To: <48A3ED37020000900001C154@hermes.cwu.edu> References: <48A3ED37020000900001C154@hermes.cwu.edu> Message-ID: X-Sender: mh@kernel32.de User-Agent: RoundCube Webmail/0.1-rc2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Cc: freebsd-stable@freebsd.org Subject: Re: ssh-keygen between SuSE and FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2008 16:43:31 -0000 Hi Gavin, On Thu, 14 Aug 2008 08:30:47 -0700, Gavin Spomer wrote: >> > > Uh, not sure. Head spinning now. ;) > > 1. I have a Mac, SuSE server and a FreeBSD server. > 2. I can ssh from my Mac to SuSE server without having to type in my > password. > 3. I can ssh from my Mac to FreeBSD server without having to type in my > password. > 4. I can do #2 and #3 above because I ran "ssh-keygen -t rsa" on my Mac > and copied the id_rsa.pub to my ~/.ssh/authorized_keys files on the SuSE > and FreeBSD servers. > 5. I ran the same "ssh-keygen -t rsa" on the SuSE server and copied the > id_rsa.pub to the FreeBSD. > 6. I canNOT ssh from the SuSE server to the FreeBSD server withOUT typing > in my password. > 7. When I ssh from SuSE server to FreeBSD server, I get prompted: > Enter passphrase for key '/home/myusername/.ssh/id_rsa': >From your Suse, try to run the ssh commando with "-v" or even -vv or -vvv to get debugging output. If you can't figure out what the debugging output wants to tell you, send it to the list. But complete, copy 'n' paste please :) I'm not quite sure right now why you're using rsa keys. I'm always using dsa keys (ssh-keygen -t dsa). It comes to my mind, that rsa keys are for ssh version 1, while dsa keys are for ssh version 2. But I could be wrong here ;) No man ssh handy right now, sorry. > 8. I want to be able to ssh from SuSE server to FreeBSD server because I > want to run scp via a cron job. > understood. > I noticed you made a distinction between password and passphrase. Could > you please explain the difference? > Well, when you generate a rsa or dsa key, you get asked to enter a passphrase for that key. So a passphrase is basically the password to your ssh key. While the password is the real password of the local user you're trying to be. Like ssh foo@bar, the password would be the password of the user foo at host bar. And since everybody likes to know wether someone is talking about the "password" of a ssh key or the password of a local user, you say passphrase to keys and password to local users. That's how I would explain it :)) Cheers, Marian From owner-freebsd-stable@FreeBSD.ORG Thu Aug 14 16:53:10 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 75871106567C for ; Thu, 14 Aug 2008 16:53:10 +0000 (UTC) (envelope-from purchasing@itcomware1.com) Received: from mail.itcomware1.com (65-118-201-154.dia.static.qwest.net [65.118.201.154]) by mx1.freebsd.org (Postfix) with ESMTP id EA9928FC22 for ; Thu, 14 Aug 2008 16:53:09 +0000 (UTC) (envelope-from purchasing@itcomware1.com) Received: from itemail ([192.168.1.1]) by mail.itcomware.net (IceWarp 9.1.0) with SMTP id SDR98453 for ; Tue, 12 Aug 2008 17:57:53 -0400 From: "purchasing" To: Date: Tue, 12 Aug 2008 17:56:25 -0400 Message-ID: <8a2b01c8fcc6$78c80e00$6501a8c0@itemail> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acj8xhsb2X+ytEDIR2ClemFt22A0fw== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Attn:Reseller-Intergrator&Channel Sales Partner. Unspent Budget For Surplus Cisco Purchase. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2008 16:53:10 -0000 I need to buy this used gear today. Give me a call if you have this or any other decommissioned Cisco, Nortel, Avaya, Lucent, 3Com, HP, IBM or Sun Microsystems equipment for sale. 18 Units- Used Cisco - WS-X6148-45AF - Will Pay Today At $1100.00 Ea 175 Units- Surplus Cisco - PVDM2-64 Module Will Buy Today At $225.00 Ea 13 Units- Decommissioned Cisco - PA-A6-OC3SMI - Will Buy Today At $4250.00 Ea 135 Units- Idle Cisco - VWIC-2MFT-E1-DI - Will Buy Today At $525.00 Ea 22 Units- Excess Cisco - AIM-CUE - Will Buy Today At $525.00 Ea 7 Units- Trade-In Cisco - WS-X6724-SFP - Will Buy Today At $3050.00 Ea 225 Units- Open Box Cisco - 2811 Router - Will Buy Today At $650.00 Ea 162 Units- Off Lease Cisco 1841 Router - Will Buy Today At - $300.00 Ea 38 Units- Overstock Cisco 2821 Router - Will Buy Today At $1100.00 Ea 17 Units- Excess Cisco WS-C3560G-48PS-S - Will Buy Today At $3100.00 Ea 105 Units- Under Utilized Cisco WS-C3550-24PWR-SMI Will Buy Today At $300.00 Ea Jim Pazz I.T.comWare, Inc. 73 Defco Park Road North Haven, CT 06473 866.739.6291 - toll free 203.234.7248 AIM itcomwarejp Skype joe.cisco Largest Refurbished Cisco End Of Life Inventory In The World! Largest Refurbished Cisco Spares Inventory In The World! Purchasing@itcomware1.com To be taken of this list, please forward this email purchasing@itcomware1.com From owner-freebsd-stable@FreeBSD.ORG Thu Aug 14 16:59:22 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 590111065672 for ; Thu, 14 Aug 2008 16:59:22 +0000 (UTC) (envelope-from purchasing@itcomware1.com) Received: from mail.itcomware1.com (65-118-201-154.dia.static.qwest.net [65.118.201.154]) by mx1.freebsd.org (Postfix) with ESMTP id 1F4D98FC0C for ; Thu, 14 Aug 2008 16:59:22 +0000 (UTC) (envelope-from purchasing@itcomware1.com) Received: from itemail ([192.168.1.1]) by mail.itcomware.net (IceWarp 9.1.0) with SMTP id TVC82745 for ; Wed, 13 Aug 2008 09:15:45 -0400 From: "purchasing" To: Date: Wed, 13 Aug 2008 09:13:31 -0400 Message-ID: <1359201c8fd46$b22f6e10$6501a8c0@itemail> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acj9RhNDislLvdXERJGKQDDG7HwdYg== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Attn:Reseller-Intergrator&Channel Sales Partner. Unspent Budget For Surplus Cisco Purchase. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2008 16:59:22 -0000 I need to buy this used gear today. Give me a call if you have this or any other decommissioned Cisco, Nortel, Avaya, Lucent, 3Com, HP, IBM or Sun Microsystems equipment for sale. 18 Units- Used Cisco - WS-X6148-45AF - Will Pay Today At $1100.00 Ea 175 Units- Surplus Cisco - PVDM2-64 Module Will Buy Today At $225.00 Ea 13 Units- Decommissioned Cisco - PA-A6-OC3SMI - Will Buy Today At $4250.00 Ea 135 Units- Idle Cisco - VWIC-2MFT-E1-DI - Will Buy Today At $525.00 Ea 22 Units- Excess Cisco - AIM-CUE - Will Buy Today At $525.00 Ea 7 Units- Trade-In Cisco - WS-X6724-SFP - Will Buy Today At $3050.00 Ea 225 Units- Open Box Cisco - 2811 Router - Will Buy Today At $650.00 Ea 162 Units- Off Lease Cisco 1841 Router - Will Buy Today At - $300.00 Ea 38 Units- Overstock Cisco 2821 Router - Will Buy Today At $1100.00 Ea 17 Units- Excess Cisco WS-C3560G-48PS-S - Will Buy Today At $3100.00 Ea 105 Units- Under Utilized Cisco WS-C3550-24PWR-SMI Will Buy Today At $300.00 Ea Jim Pazz I.T.comWare, Inc. 73 Defco Park Road North Haven, CT 06473 866.739.6291 - toll free 203.234.7248 AIM itcomwarejp Skype joe.cisco Largest Refurbished Cisco End Of Life Inventory In The World! Largest Refurbished Cisco Spares Inventory In The World! Purchasing@itcomware1.com To be taken of this list, please forward this email purchasing@itcomware1.com From owner-freebsd-stable@FreeBSD.ORG Thu Aug 14 17:02:14 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8BDE9106564A for ; Thu, 14 Aug 2008 17:02:14 +0000 (UTC) (envelope-from spomerg@cwu.EDU) Received: from scylla.cts.cwu.edu (scylla.cts.cwu.edu [198.104.67.151]) by mx1.freebsd.org (Postfix) with ESMTP id 7E9D18FC1B for ; Thu, 14 Aug 2008 17:02:14 +0000 (UTC) (envelope-from spomerg@cwu.EDU) Received: from CONVERSION-CWU-DAEMON.SCYLLA.CTS.CWU.EDU by SCYLLA.CTS.CWU.EDU (PMDF V6.4 #31640) id <01MYCFAYLMF40002WN@SCYLLA.CTS.CWU.EDU> for freebsd-stable@freebsd.org; Thu, 14 Aug 2008 10:02:14 -0700 (PDT) Received: from hermes.cwu.edu (hermes.cwu.edu [172.16.21.28]) by SCYLLA.CTS.CWU.EDU (PMDF V6.4 #31640) with ESMTP id <01MYCFAYDTR40009UL@SCYLLA.CTS.CWU.EDU> for freebsd-stable@freebsd.org; Thu, 14 Aug 2008 10:02:13 -0700 (PDT) Received: from cwugate1-MTA by hermes.cwu.edu with Novell_GroupWise; Thu, 14 Aug 2008 10:02:13 -0700 Date: Thu, 14 Aug 2008 10:02:11 -0700 From: Gavin Spomer To: freebsd-stable@freebsd.org Message-id: <48A402A3020000900001C178@hermes.cwu.edu> MIME-version: 1.0 X-Mailer: Novell GroupWise Internet Agent 7.0.3 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable Content-disposition: inline Subject: Re: ssh-keygen between SuSE and FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2008 17:02:14 -0000 >=20 >>> Pollywog 08/14/08 9:32 AM >>> > On Thursday 14 August 2008 15:29:27 Gavin Spomer wrote: > > >>> Lyndon Nerenberg 08/13/08 7:10 PM >>> > > > > > > You need to start an ssh-agent on the machine you're connecting from = and > > > populate it with your keychain: > > > > > > eval `ssh-agent` > > > ssh-add > > > > > > Add the above to your .profile, or check the Linux PAM implementation= to > > > see if it has ssh session support. > > > > > > --lyndon > > > > Thanks. > > > > That made it possible for me to ssh from SuSE server to FreeBSD = server, but > > now when I ssh from my Mac to SuSE server it wants a password now: > > > > Enter passphrase for /home/myusername/.ssh/id_rsa: > > > > I read the FreeBSD handbook section "14.11.7 ssh-agent and ssh-add" = and > > don't have anything much more intelligent to say but "I don't = understand". > > ;) > > > > Questions: > > > > 1. If the ssh-agent and ssh-add utilities load the keys into = memory, > > they'd be wiped if I rebooted? >=20 > Yes, rebooting will take the keys out of memory and you would need to=20 > use 'ssh-add' on the command line to put the keys and passphrase in = memory. > The 'ssh-add -D' command removes the keys when you are done but are = not=20 > logging out. >=20 > > > > 2. Is #1 why I'd add it to my ~/.profile? >=20 > This is so that ssh-agent is set when you login at a console. I don't = know=20 > about Mac but some Linux distributions have session scripts so that this = is=20 > done for you when you start a KDE session. I don't believe ~/.profile = will=20 > be read unless you login at a console or xterm or similar. >=20 > When you add stuff to your ~/.profile, I recommend doing it on a = separate=20 > account first. I once added those lines on a Linux system and was = locked out=20 > on that account but I was able to get in with another account, su to = root,=20 > and remove the lines in the affected user ~/.profile and then I was no = longer=20 > locked out. > > > > 3. How am I able to ssh (without a password) from my Mac to SuSE = server > > or Mac to FreeBSD server when I don't have "eval `ssh-agent`" and = "ssh-add" > > in my .profile on my Mac? >=20 > You can do 'ssh-agent bash' followed by 'ssh-add' but this will not work = until=20 > you have generated your SSH keys with: >=20 > ssh-keygen -t rsa -b 1024 > or > ssh-keygen -t dsa -b 1024 >=20 > or similar. Until you do that, you have to use your login password and = cannot=20 > use a passphrase since you have not set one. Setting the passphrase is = part=20 > of the process of generating your SSH keys. >=20 > BTW I do not know if you are using the "keychain" utility. Be very = careful=20 > with it. It can be confusing. I found it inconvenient to use and no = longer=20 > use it. >=20 > There are some fine SSH tutorials online, I believe "OnLamp" has some. = Just=20 > make sure they are not more than about 3 yrs old. All good information. Thanks. I will save this for future reference. :) From owner-freebsd-stable@FreeBSD.ORG Thu Aug 14 17:04:10 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 05ADB106567F for ; Thu, 14 Aug 2008 17:04:10 +0000 (UTC) (envelope-from spomerg@cwu.EDU) Received: from donald.cts.cwu.edu (donald.cts.cwu.edu [198.104.67.147]) by mx1.freebsd.org (Postfix) with ESMTP id ED78C8FC1F for ; Thu, 14 Aug 2008 17:04:09 +0000 (UTC) (envelope-from spomerg@cwu.EDU) Received: from CONVERSION-CWU-DAEMON.DONALD.CTS.CWU.EDU by DONALD.CTS.CWU.EDU (PMDF V6.4 #31640) id <01MYCFDCE7DS000S07@DONALD.CTS.CWU.EDU> for freebsd-stable@freebsd.org; Thu, 14 Aug 2008 10:04:09 -0700 (PDT) Received: from hermes.cwu.edu (hermes.cwu.edu [172.16.21.28]) by DONALD.CTS.CWU.EDU (PMDF V6.4 #31640) with ESMTP id <01MYCFDC1KH4000KD9@DONALD.CTS.CWU.EDU> for freebsd-stable@freebsd.org; Thu, 14 Aug 2008 10:04:08 -0700 (PDT) Received: from cwugate1-MTA by hermes.cwu.edu with Novell_GroupWise; Thu, 14 Aug 2008 10:04:08 -0700 Date: Thu, 14 Aug 2008 10:04:03 -0700 From: Gavin Spomer To: freebsd-stable@freebsd.org Message-id: <48A40313020000900001C17C@hermes.cwu.edu> MIME-version: 1.0 X-Mailer: Novell GroupWise Internet Agent 7.0.3 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable Content-disposition: inline Subject: Re: ssh-keygen between SuSE and FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2008 17:04:10 -0000 >=20 >>> Paul Saab 08/14/08 9:41 AM >>> > look at your permissions in ~/.ssh on the freebsd box. Make sure your = home > directory does not have insecure permissions and .ssh + all the files in > there are not writable by anyone else. No worries there. Thanks.=20 From owner-freebsd-stable@FreeBSD.ORG Thu Aug 14 17:16:56 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 907E61065672 for ; Thu, 14 Aug 2008 17:16:56 +0000 (UTC) (envelope-from lyndon@orthanc.ca) Received: from orthanc.ca (gandalf.orthanc.ca [216.40.124.68]) by mx1.freebsd.org (Postfix) with ESMTP id 5F0D78FC0A for ; Thu, 14 Aug 2008 17:16:56 +0000 (UTC) (envelope-from lyndon@orthanc.ca) Received: from peregrin.orthanc.ca (peregrin.orthanc.ca [216.40.124.67]) by orthanc.ca (8.14.2/8.14.2) with ESMTP id m7EGlUqX008592 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 Aug 2008 09:47:30 -0700 (PDT) (envelope-from lyndon@orthanc.ca) Date: Thu, 14 Aug 2008 09:47:26 -0700 (PDT) From: Lyndon Nerenberg To: Gavin Spomer In-Reply-To: <48A3ECE7020000900001C150@hermes.cwu.edu> Message-ID: References: <48A3ECE7020000900001C150@hermes.cwu.edu> Organization: The Frobozz Magic Homing Pigeon Company MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@freebsd.org Subject: Re: ssh-keygen between SuSE and FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2008 17:16:56 -0000 > That made it possible for me to ssh from SuSE server to FreeBSD server, > but now when I ssh from my Mac to SuSE server it wants a password now: ssh-agent holds your keys in memory for you, and provides them to remote systems when needed. You need to run it on each system you log in to. If you have a single workstation you normally use, start ssh-agent there and set your ssh client to forward keys to remote systems. DOn't you have a local IT helpdesk? This is pretty basic stuff that they should have documentation for. From owner-freebsd-stable@FreeBSD.ORG Thu Aug 14 17:25:16 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D30E21065677 for ; Thu, 14 Aug 2008 17:25:16 +0000 (UTC) (envelope-from spomerg@cwu.EDU) Received: from donald.cts.cwu.edu (donald.cts.cwu.edu [198.104.67.147]) by mx1.freebsd.org (Postfix) with ESMTP id C7C748FC15 for ; Thu, 14 Aug 2008 17:25:16 +0000 (UTC) (envelope-from spomerg@cwu.EDU) Received: from CONVERSION-CWU-DAEMON.DONALD.CTS.CWU.EDU by DONALD.CTS.CWU.EDU (PMDF V6.4 #31640) id <01MYCG4I5W1S000S07@DONALD.CTS.CWU.EDU> for freebsd-stable@freebsd.org; Thu, 14 Aug 2008 10:25:16 -0700 (PDT) Received: from hermes.cwu.edu (hermes.cwu.edu [172.16.21.28]) by DONALD.CTS.CWU.EDU (PMDF V6.4 #31640) with ESMTP id <01MYCG4HQUI4000TD2@DONALD.CTS.CWU.EDU> for freebsd-stable@freebsd.org; Thu, 14 Aug 2008 10:25:15 -0700 (PDT) Received: from cwugate1-MTA by hermes.cwu.edu with Novell_GroupWise; Thu, 14 Aug 2008 10:25:15 -0700 Date: Thu, 14 Aug 2008 10:25:09 -0700 From: Gavin Spomer To: freebsd-stable@freebsd.org Message-id: <48A40805020000900001C185@hermes.cwu.edu> MIME-version: 1.0 X-Mailer: Novell GroupWise Internet Agent 7.0.3 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable Content-disposition: inline Subject: Re: ssh-keygen between SuSE and FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2008 17:25:16 -0000 >=20 >>> Marian Hettwer 08/14/08 9:43 AM >>> > Hi Gavin, > From your Suse, try to run the ssh commando with "-v" or even -vv or = -vvv > to get debugging output. > If you can't figure out what the debugging output wants to tell you, = send > it to the list. > But complete, copy 'n' paste please :) Sure, no problem: (edited) myusername@suseserver:~> ssh -v myusername@freebsdserver OpenSSH_4.2p1, OpenSSL 0.9.8a 11 Oct 2005 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug1: Connecting to freebsdserver [xxx.xxx.xxx.xxx] port 22. debug1: Connection established. debug1: identity file /home/myusername/.ssh/id_rsa type -1 debug1: identity file /home/myusername/.ssh/id_dsa type -1 debug1: Remote protocol version 2.0, remote software version OpenSSH_4.5p1 = FreeBSD-20061110 debug1: match: OpenSSH_4.5p1 FreeBSD-20061110 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_4.2 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client aes128-cbc hmac-md5 none debug1: kex: client->server aes128-cbc hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug1: Host 'freebsdserver' is known and matches the DSA host key. debug1: Found key in /home/myusername/.ssh/known_hosts:6 debug1: ssh_dss_verify: signature correct debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: SSH2_MSG_SERVICE_REQUEST sent debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey,keyboard-interactive debug1: Next authentication method: publickey debug1: Trying private key: /home/myusername/.ssh/id_rsa debug1: Trying private key: /home/myusername/.ssh/id_dsa debug1: Next authentication method: keyboard-interactive Password: debug1: Authentication succeeded (keyboard-interactive). debug1: channel 0: new [client-session] debug1: Entering interactive session. debug1: Sending environment. debug1: Sending env LANG =3D en_US.UTF-8 Last login: Thu Aug 14 10:08:12 2008 from suseserver . [snip] . Welcome to FreeBSD! . [snip] . [myusername@freebsdserver ~]$ > I'm not quite sure right now why you're using rsa keys. I'm always using > dsa keys (ssh-keygen -t dsa). It comes to my mind, that rsa keys are for > ssh version 1, while dsa keys are for ssh version 2. > But I could be wrong here ;) > No man ssh handy right now, sorry. If that's true, then I believe I will start using the dsa ones! I think I = chose rsa because the FreeBSD manual indicated I could use either and I = could only find settings for enabling rsa in sshd_config on the remote = servers, but I'll look again... > > I noticed you made a distinction between password and passphrase. = Could > > you please explain the difference? > > > Well, when you generate a rsa or dsa key, you get asked to enter a > passphrase for that key. > So a passphrase is basically the password to your ssh key. > While the password is the real password of the local user you're trying = to > be. Like ssh foo@bar, the password would be the password of the user foo = at > host bar. > And since everybody likes to know wether someone is talking about the > "password" of a ssh key or the password of a local user, you say = passphrase > to keys and password to local users. > That's how I would explain it :)) Good explanation. I grok, I grok. :D > Cheers, > Marian From owner-freebsd-stable@FreeBSD.ORG Thu Aug 14 17:31:17 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0DAC51065678 for ; Thu, 14 Aug 2008 17:31:17 +0000 (UTC) (envelope-from spomerg@cwu.EDU) Received: from donald.cts.cwu.edu (donald.cts.cwu.edu [198.104.67.147]) by mx1.freebsd.org (Postfix) with ESMTP id 0376B8FC17 for ; Thu, 14 Aug 2008 17:31:16 +0000 (UTC) (envelope-from spomerg@cwu.EDU) Received: from CONVERSION-CWU-DAEMON.DONALD.CTS.CWU.EDU by DONALD.CTS.CWU.EDU (PMDF V6.4 #31640) id <01MYCGBY0EJK000S07@DONALD.CTS.CWU.EDU> for freebsd-stable@freebsd.org; Thu, 14 Aug 2008 10:31:16 -0700 (PDT) Received: from hermes.cwu.edu (hermes.cwu.edu [172.16.21.28]) by DONALD.CTS.CWU.EDU (PMDF V6.4 #31640) with ESMTP id <01MYCGBXQ782000S53@DONALD.CTS.CWU.EDU> for freebsd-stable@freebsd.org; Thu, 14 Aug 2008 10:31:15 -0700 (PDT) Received: from cwugate1-MTA by hermes.cwu.edu with Novell_GroupWise; Thu, 14 Aug 2008 10:31:15 -0700 Date: Thu, 14 Aug 2008 10:31:12 -0700 From: Gavin Spomer To: freebsd-stable@freebsd.org Message-id: <48A40970020000900001C18E@hermes.cwu.edu> MIME-version: 1.0 X-Mailer: Novell GroupWise Internet Agent 7.0.3 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable Content-disposition: inline Subject: Re: ssh-keygen between SuSE and FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2008 17:31:17 -0000 >=20 >>> Lyndon Nerenberg 08/14/08 9:47 AM >>> > DOn't you have a local IT helpdesk? This is pretty basic stuff that = they=20 > should have documentation for. Well, I admit I still have more things to learn, even though I've been the = admin of "my" own Linux servers for 3 years and FreeBSD for... can't = remember, but not quite as long, but I'm not gonna pester my colleagues = for something like this, about my own servers! ;) My background is more in programming as I have a CS degree in software = design. Still learning in that area too! We are all, always learning. = (hopefully) Genuine thanks for the suggestion though. - Gavin From owner-freebsd-stable@FreeBSD.ORG Thu Aug 14 17:34:04 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1D2B71065693 for ; Thu, 14 Aug 2008 17:34:04 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from smtp-out2.tiscali.nl (smtp-out2.tiscali.nl [195.241.79.177]) by mx1.freebsd.org (Postfix) with ESMTP id E6DA58FC12 for ; Thu, 14 Aug 2008 17:34:03 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from [212.123.145.58] (helo=guido.klop.ws) by smtp-out2.tiscali.nl with smtp id 1KTgi2-0007Pr-EL for ; Thu, 14 Aug 2008 19:34:02 +0200 Received: (qmail 13999 invoked from network); 14 Aug 2008 17:34:01 -0000 Received: from localhost (HELO 82-170-177-25.ip.telfort.nl) (127.0.0.1) by localhost with SMTP; 14 Aug 2008 17:34:01 -0000 Date: Thu, 14 Aug 2008 19:34:00 +0200 To: "Gavin Spomer" , freebsd-stable@freebsd.org From: "Ronald Klop" Content-Type: text/plain; format=flowed; delsp=yes; charset=us-ascii MIME-Version: 1.0 References: <48A40805020000900001C185@hermes.cwu.edu> Content-Transfer-Encoding: 7bit Message-ID: In-Reply-To: <48A40805020000900001C185@hermes.cwu.edu> User-Agent: Opera Mail/9.51 (FreeBSD) Cc: Subject: Re: ssh-keygen between SuSE and FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2008 17:34:04 -0000 On Thu, 14 Aug 2008 19:25:09 +0200, Gavin Spomer wrote: [snip] >> I'm not quite sure right now why you're using rsa keys. I'm always using >> dsa keys (ssh-keygen -t dsa). It comes to my mind, that rsa keys are for >> ssh version 1, while dsa keys are for ssh version 2. >> But I could be wrong here ;) >> No man ssh handy right now, sorry. > > If that's true, then I believe I will start using the dsa ones! I think > I chose rsa because the FreeBSD manual indicated I could use either and > I could only find settings for enabling rsa in sshd_config on the remote > servers, but I'll look again... This story about rsa and dsa is not true. Rsa wasn't free (patents or something else) until a few years ago. So everybody used dsa. But since quite some time it doesn't matter what you use. I don't know about advantages of one above the other. In daily use they are the same. Ronald. From owner-freebsd-stable@FreeBSD.ORG Thu Aug 14 17:36:44 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 38E50106564A for ; Thu, 14 Aug 2008 17:36:44 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from smtp-out3.tiscali.nl (smtp-out3.tiscali.nl [195.241.79.178]) by mx1.freebsd.org (Postfix) with ESMTP id 0EBB38FC1B for ; Thu, 14 Aug 2008 17:36:44 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from [212.123.145.58] (helo=guido.klop.ws) by smtp-out3.tiscali.nl with smtp id 1KTgkc-0000ML-MX for ; Thu, 14 Aug 2008 19:36:42 +0200 Received: (qmail 14014 invoked from network); 14 Aug 2008 17:36:41 -0000 Received: from localhost (HELO 82-170-177-25.ip.telfort.nl) (127.0.0.1) by localhost with SMTP; 14 Aug 2008 17:36:41 -0000 Date: Thu, 14 Aug 2008 19:36:40 +0200 To: "Gavin Spomer" , freebsd-stable@freebsd.org From: "Ronald Klop" Content-Type: text/plain; format=flowed; delsp=yes; charset=us-ascii MIME-Version: 1.0 References: <48A40970020000900001C18E@hermes.cwu.edu> Content-Transfer-Encoding: 7bit Message-ID: In-Reply-To: <48A40970020000900001C18E@hermes.cwu.edu> User-Agent: Opera Mail/9.51 (FreeBSD) Cc: Subject: Re: ssh-keygen between SuSE and FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2008 17:36:44 -0000 On Thu, 14 Aug 2008 19:31:12 +0200, Gavin Spomer wrote: >> >>>> Lyndon Nerenberg 08/14/08 9:47 AM >>> >> DOn't you have a local IT helpdesk? This is pretty basic stuff that they >> should have documentation for. > > Well, I admit I still have more things to learn, even though I've been > the admin of "my" own Linux servers for 3 years and FreeBSD for... can't > remember, but not quite as long, but I'm not gonna pester my colleagues > for something like this, about my own servers! ;) > > My background is more in programming as I have a CS degree in software > design. Still learning in that area too! We are all, always learning. > (hopefully) > > Genuine thanks for the suggestion though. > > - Gavin Funny, you don't 'pester' your colleagues but do e-mail a couple of thousand people on this mailinglist. Communication is a weird thing. :-) Ronald. From owner-freebsd-stable@FreeBSD.ORG Thu Aug 14 17:41:21 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5D627106566C for ; Thu, 14 Aug 2008 17:41:21 +0000 (UTC) (envelope-from spomerg@cwu.EDU) Received: from scylla.cts.cwu.edu (scylla.cts.cwu.edu [198.104.67.151]) by mx1.freebsd.org (Postfix) with ESMTP id 541758FC19 for ; Thu, 14 Aug 2008 17:41:21 +0000 (UTC) (envelope-from spomerg@cwu.EDU) Received: from CONVERSION-CWU-DAEMON.SCYLLA.CTS.CWU.EDU by SCYLLA.CTS.CWU.EDU (PMDF V6.4 #31640) id <01MYCGOG1Y80000A1O@SCYLLA.CTS.CWU.EDU> for freebsd-stable@freebsd.org; Thu, 14 Aug 2008 10:41:20 -0700 (PDT) Received: from hermes.cwu.edu (hermes.cwu.edu [172.16.21.28]) by SCYLLA.CTS.CWU.EDU (PMDF V6.4 #31640) with ESMTP id <01MYCGOFU4MM0009JQ@SCYLLA.CTS.CWU.EDU> for freebsd-stable@freebsd.org; Thu, 14 Aug 2008 10:41:20 -0700 (PDT) Received: from cwugate1-MTA by hermes.cwu.edu with Novell_GroupWise; Thu, 14 Aug 2008 10:41:20 -0700 Date: Thu, 14 Aug 2008 10:41:18 -0700 From: Gavin Spomer To: freebsd-stable@freebsd.org Message-id: <48A40BCE020000900001C192@hermes.cwu.edu> MIME-version: 1.0 X-Mailer: Novell GroupWise Internet Agent 7.0.3 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable Content-disposition: inline Subject: Re: ssh-keygen between SuSE and FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2008 17:41:21 -0000 >=20 >>> Ronald Klop 08/14/08 10:34 AM >>> > >> I'm not quite sure right now why you're using rsa keys. I'm always = using > >> dsa keys (ssh-keygen -t dsa). It comes to my mind, that rsa keys are = for > >> ssh version 1, while dsa keys are for ssh version 2. > >> But I could be wrong here ;) > >> No man ssh handy right now, sorry. > > > > If that's true, then I believe I will start using the dsa ones! I = think =20 > > I chose rsa because the FreeBSD manual indicated I could use either = and =20 > > I could only find settings for enabling rsa in sshd_config on the = remote =20 > > servers, but I'll look again... >=20 > This story about rsa and dsa is not true. > Rsa wasn't free (patents or something else) until a few years ago. So = =20 > everybody used dsa. But since quite some time it doesn't matter what you = =20 > use. I don't know about advantages of one above the other. In daily use = =20 > they are the same. >=20 > Ronald. Thanks for more info. Maybe some people think that because of the = following lines in sshd.config? # HostKey for protocol version 1 #HostKey /etc/ssh/ssh_host_key # HostKeys for protocol version 2 #HostKey /etc/ssh/ssh_host_dsa_key Although the 2nd line *doesn't* read "#HostKey /etc/ssh/ssh_host_rsa_key", = maybe people are associating dsa with protocol 2 because of the 3rd and = 4th lines? From owner-freebsd-stable@FreeBSD.ORG Thu Aug 14 17:45:03 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0C495106566B for ; Thu, 14 Aug 2008 17:45:03 +0000 (UTC) (envelope-from spomerg@cwu.EDU) Received: from donald.cts.cwu.edu (donald.cts.cwu.edu [198.104.67.147]) by mx1.freebsd.org (Postfix) with ESMTP id 02EC88FC0A for ; Thu, 14 Aug 2008 17:45:02 +0000 (UTC) (envelope-from spomerg@cwu.EDU) Received: from CONVERSION-CWU-DAEMON.DONALD.CTS.CWU.EDU by DONALD.CTS.CWU.EDU (PMDF V6.4 #31640) id <01MYCGT0VNLC000TFA@DONALD.CTS.CWU.EDU> for freebsd-stable@freebsd.org; Thu, 14 Aug 2008 10:45:02 -0700 (PDT) Received: from hermes.cwu.edu (hermes.cwu.edu [172.16.21.28]) by DONALD.CTS.CWU.EDU (PMDF V6.4 #31640) with ESMTP id <01MYCGT0DX0S000UER@DONALD.CTS.CWU.EDU> for freebsd-stable@freebsd.org; Thu, 14 Aug 2008 10:45:01 -0700 (PDT) Received: from cwugate1-MTA by hermes.cwu.edu with Novell_GroupWise; Thu, 14 Aug 2008 10:45:01 -0700 Date: Thu, 14 Aug 2008 10:44:58 -0700 From: Gavin Spomer To: freebsd-stable@freebsd.org Message-id: <48A40CAA020000900001C19B@hermes.cwu.edu> MIME-version: 1.0 X-Mailer: Novell GroupWise Internet Agent 7.0.3 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable Content-disposition: inline Subject: Re: ssh-keygen between SuSE and FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2008 17:45:03 -0000 >=20 >>> Ronald Klop 08/14/08 10:36 AM >>> > > Well, I admit I still have more things to learn, even though I've been = =20 > > the admin of "my" own Linux servers for 3 years and FreeBSD for... = can't =20 > > remember, but not quite as long, but I'm not gonna pester my colleagues= =20 > > for something like this, about my own servers! ;) > > > > My background is more in programming as I have a CS degree in software = =20 > > design. Still learning in that area too! We are all, always learning. = =20 > > (hopefully) > > > > Genuine thanks for the suggestion though. > > > > - Gavin >=20 > Funny, you don't 'pester' your colleagues but do e-mail a couple of =20 > thousand people on this mailinglist. Communication is a weird thing. :-) >=20 > Ronald. LOL! Okay, fair enough. I concede, you got me there. :) (I LOVE pestering y'all though!) From owner-freebsd-stable@FreeBSD.ORG Thu Aug 14 18:26:13 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 994581065684 for ; Thu, 14 Aug 2008 18:26:13 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from proxy.meer.net (proxy.meer.net [64.13.141.13]) by mx1.freebsd.org (Postfix) with ESMTP id 8A16B8FC18 for ; Thu, 14 Aug 2008 18:26:13 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from mail.meer.net (mail.meer.net [64.13.141.3]) by proxy.meer.net (8.14.2/8.14.2) with ESMTP id m7EHpu2D098843; Thu, 14 Aug 2008 10:51:58 -0700 (PDT) (envelope-from gnn@neville-neil.com) Received: from mail2.meer.net (mail2.meer.net [64.13.141.16]) by mail.meer.net (8.13.3/8.13.3/meer) with ESMTP id m7EHptKx026262; Thu, 14 Aug 2008 10:51:55 -0700 (PDT) (envelope-from gnn@neville-neil.com) Received: from minion.local.neville-neil.com (209.249.190.254.available.above.net [209.249.190.254] (may be forged)) (authenticated bits=0) by mail2.meer.net (8.14.1/8.14.1) with ESMTP id m7EHps5m008209; Thu, 14 Aug 2008 10:51:54 -0700 (PDT) (envelope-from gnn@neville-neil.com) Date: Thu, 14 Aug 2008 13:51:54 -0400 Message-ID: From: gnn@freebsd.org To: "Jack Vogel" In-Reply-To: <2a41acea0808131502y39879a22u39c472bd0b810fc2@mail.gmail.com> References: <2a41acea0808131502y39879a22u39c472bd0b810fc2@mail.gmail.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.7 Emacs/22.2.50 (i386-apple-darwin9.4.0) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Canit-CHI2: 0.50 X-Bayes-Prob: 0.5 (Score 0, tokens from: ) X-Spam-Score: 0.10 () [Tag at 5.00] COMBINED_FROM X-CanItPRO-Stream: default X-Canit-Stats-ID: 1239928 - d63185b3a2b4 X-Scanned-By: CanIt (www . roaringpenguin . com) on 64.13.141.13 Cc: "freebsd-net@freebsd.org" , FreeBSD Stable List Subject: Re: HEADS UP: E1000 networking changes in STABLE/7.1 RELEASE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2008 18:26:13 -0000 Hi Jack, Thanks for this and for the concise pciconf line. We use em (soon to be igb) interfaces extensively at work. Best, George From owner-freebsd-stable@FreeBSD.ORG Fri Aug 15 00:44:21 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F9A71065671 for ; Fri, 15 Aug 2008 00:44:21 +0000 (UTC) (envelope-from cian@cia.nhugh.es) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.173]) by mx1.freebsd.org (Postfix) with ESMTP id F32148FC16 for ; Fri, 15 Aug 2008 00:44:19 +0000 (UTC) (envelope-from cian@cia.nhugh.es) Received: by ug-out-1314.google.com with SMTP id q7so101773uge.13 for ; Thu, 14 Aug 2008 17:44:18 -0700 (PDT) Received: by 10.66.221.19 with SMTP id t19mr176637ugg.69.1218759558077; Thu, 14 Aug 2008 17:19:18 -0700 (PDT) Received: from mbp.cian.ws ( [87.192.36.98]) by mx.google.com with ESMTPS id 32sm485381ugf.51.2008.08.14.17.19.15 (version=SSLv3 cipher=RC4-MD5); Thu, 14 Aug 2008 17:19:16 -0700 (PDT) Message-Id: <8B25287C-7336-492C-B62E-CB319B8B5DBB@nHugh.es> From: Cian Hughes To: Sebastiaan van Erk In-Reply-To: <48A3FCF7.9030905@sebster.com> Mime-Version: 1.0 (Apple Message framework v928.1) Date: Fri, 15 Aug 2008 01:19:13 +0100 References: <48982B58.4000406@sebster.com> <48992532.9080503@yandex.ru> <489970CC.4000103@sebster.com> <20080806095748.GA52551@eos.sc1.parodius.com> <20080806101941.GA52952@eos.sc1.parodius.com> <48A2DD60.7090702@sebster.com> <20080814090521.GB27942@groll.co.za> <48A3FCF7.9030905@sebster.com> X-Mailer: Apple Mail (2.928.1) Sender: Cian Hughes Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: Stable SATA pci card for FreeBSD 6.x/7.0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Aug 2008 00:44:21 -0000 Sebastiaan, Have you tried connecting your 250GB drives to the troublesome controller? If so, does "stressing" them cause the system to panic? ~Cian Hughes -- University of Bristol Medical School On 14 Aug 2008, at 10:37, Sebastiaan van Erk wrote: > Thanks Jonathan, > > I'm starting to expect it has to be the controller as well. About 20 > minutes after I posted this message yesterday (and thus 20 minutes > after ad6 got disconnected - atacontrol list showed "no device > present" for it) the machine crashed while writing to the remaining > ad4 drive (kernel panic). I attached the logs below. I also ran the > long smart self test on both drives, and no errors were found on > either drive (logs also attached). > > Unfortunately I could not attach the new disks to my mainboard SATA > because my mainboard SATA somehow hangs trying to detect them. So I > cannot test if *not* using the controller is going to solve the > problems, though I'm it seems logical at the moment it has to be the > controller, especially if other people have had similar issues. > > I guess I'll be buying another controller. > > Regards, > Sebastiaan > > Jonathan Groll wrote: >> On Wed, Aug 13, 2008 at 03:10:56PM +0200, Sebastiaan van Erk wrote: >>> Hi, >>> >>> Just an update on this issue. >>> >>> Quick summary: I fixed the BIOS issues, the hardware monitor >>> issues, and the rl0/rl1 watchdog timeout issues (it seems). >>> However I'm still having problems with my SATA drives (or at least >>> one of them). More info below. >>> >>> BIOS: >>> I flashed my BIOS to the latest version about a year ago, and >>> never noticed that there was any problem, but it turns out there >>> was. I never reset the BIOS to default factory settings after the >>> upgrade, and it seems the settings were corrupt. After having >>> reset the BIOS to the "default optimized factory settings" it >>> stopped crashing when I go into the H/W monitor and also when >>> using healthd -d (output below): >>> >>> Temp.= 40.0, 36.0, 66.0; Rot.= 0, 0, 0 >>> Vcore = 1.44, 3.12; Volt. = 3.34, 5.00, 1.95, -0.11, -1.54 >>> Temp.= 40.0, 36.0, 66.0; Rot.= 0, 0, 0 >>> Vcore = 1.44, 3.14; Volt. = 3.33, 4.97, 1.95, -0.11, -1.54 >>> Temp.= 40.0, 36.0, 66.0; Rot.= 0, 0, 0 >>> Vcore = 1.44, 3.12; Volt. = 3.34, 4.97, 1.95, -0.11, -1.54 >>> Temp.= 40.0, 36.0, 66.0; Rot.= 0, 0, 0 >>> Vcore = 1.44, 3.12; Volt. = 3.34, 5.00, 1.95, -0.11, -1.54 >>> Temp.= 40.0, 36.0, 66.0; Rot.= 0, 0, 0 >>> Vcore = 1.44, 3.12; Volt. = 3.34, 5.00, 1.95, -0.11, -1.54 >>> >>> This also seems to have fixed the rl0 watchdog timeout problems. I >>> no longer see those in my logs. >>> >>> SATA DRIVES: >>> >>> I'm still having problems with the SATA drives. >>> >>> I tried connecting the 1TB Samsung drives to my mainboard, but >>> then the box hangs when booting with the "Detecting IDE drives" >>> message. The regular (PATA) IDE drives are detected first, and >>> then it repeats the "Detecting IDE drives" message to detect the >>> sata drives, and hangs. When I connect my 250GB SATA drives to my >>> mainboard they detect fine, and the box boots normally. >>> >>> I did another rsync of my old mirror (the 250GB disks) to the new >>> mirror (1TB disks), but again one of the disks got detached. This >>> time there are no other messages in the log, the only thing I see >>> is the following: >>> >>> Aug 13 14:35:27 piglet su: sebster to root on /dev/ttyp5 >>> Aug 13 14:55:38 piglet kernel: ad6: FAILURE - device detached >>> Aug 13 14:55:38 piglet kernel: subdisk6: detached >>> Aug 13 14:55:38 piglet kernel: ad6: detached >>> Aug 13 14:55:38 piglet kernel: GEOM_MIRROR: Device gm1: provider >>> ad6 disconnected. >>> Aug 13 15:00:00 piglet newsyslog[1800]: logfile turned over due to >>> size>100K >>> >>> (unfortunate that the log file just got rotated, but in the new >>> log file there is nothing execpt the one expected line: >>> >>> Aug 13 15:00:00 piglet newsyslog[1800]: logfile turned over due to >>> size>100K >>> >>> So, nothing after the disconnect... >>> >>> The questions I have now is: >>> 1) Could an upgrade to FreeBSD 7-STABLE fix the issue (it's a LOT >>> of work for me, but I'll do it if there are SATA driver issues >>> fixed). >> I suspect the problem may be the SiI driver in Freebsd. As a >> reference >> point, I've had a similar problem, even on 7-STABLE, but with sparc64 >> hardware (see earlier post in this thread). >> It'll probably be simplest for you to just buy another controller of >> another brand. On the other hand, it'll be worth knowing exactly what >> is wrong with the SiI driver... >> Cheers, >> Jonathan > Aug 13 15:00:00 piglet newsyslog[1800]: logfile turned over due to > size>100K > Aug 13 15:11:26 piglet su: sebster to root on /dev/ttyp4 > Aug 13 15:34:55 piglet kernel: mirror/ > gm1s1e[WRITE(offset=875450693632, length=2048)]error = 6 > Aug 13 15:34:55 piglet kernel: g_vfs_done():mirror/ > gm1s1e[WRITE(offset=875450695680, length=2048)]error = 6 > > [snip 335750 similar lines] > > Aug 13 15:36:30 piglet kernel: g_vfs_done():mirror/ > gm1s1e[WRITE(offset=875450931200, length=2048)]error = 6 > Aug 13 15:36:30 piglet kernel: g_vfs_done():mirror/ > gm1s1e[WRITE(offset=875450933248, length=2048)]error = 6 > Aug 13 15:36:30 piglet kernel: g_vfs_done():mirror/ > gm1s1e[WRITE(offset=875450935296, length=2048)]error = 6 > Aug 13 15:36:30 piglet kernel: g_vfs_done():mirror/ > gm1s1e[WRITE(offset=875450937344, length=2048)]error = 6 > Aug 13 15:36:30 piglet kernel: g_vfs_done():mirror/ > gm1s1e[WRITE(offset=875450939392, length=2048)]error = 6 > Aug 13 15:36:30 piglet kernel: g_vfs_done():mirror/ > gm1s1e[WRITE(offset=875450941440, length=2048)]error = 6 > Aug 13 15:36:30 piglet kernel: g_vfs_done():mirror/ > gm1s1e[WRITE(offset=875450943488, length=2048)]error = 6 > Aug 13 15:36:30 piglet kernel: g_vfs_done():mirror/ > gm1s1e[WRITE(offset=875450945536, length=2048)]error = 6 > Aug 13 15:36:30 piglet kernel: g_vfs_done():mirror/ > gm1s1e[WRITE(offset=875450947584, length=2048)]error = 6 > Aug 13 15:36:30 piglet kernel: g_vfs_done():mirror/ > gm1s1e[WRITE(offset=875450949632, length=2048)]error = 6 > Aug 13 15:36:30 piglet kernel: g_vfs_done():mirror/ > gm1s1e[WRITE(offset=875450951680, length=2048)]error = 6 > Aug 13 15:36:30 piglet kernel: g_vfs_done():mirror/ > gm1s1e[WRITE(offset=875450953728, length=2048)]error = 6 > Aug 13 15:36:30 piglet kernel: g_vfs_done():mirror/ > gm1s1e[WRITE(offset=875450955776, length=2048)]error = 6 > Aug 13 15:36:30 piglet kernel: g_vfs_done():mirror/ > gm1s1e[WRITE(offset=875450957824, length=2048)]error = 6 > Aug 13 15:36:30 piglet kernel: g_vfs_done():mirror/ > gm1s1e[WRITE(offset=875450959872, length=2048)]error = 6 > Aug 13 15:36:30 piglet kernel: g_vfs_done():mirror/ > gm1s1e[WRITE(offset=875450961920, length=2048)]error = 6 > Aug 13 15:36:30 piglet kernel: g_vfs_done():mirror/ > gm1s1e[WRITE(offset=875450963968, length=2048)]error = 6 > Aug 13 15:36:30 piglet kernel: g_vfs_done():mirror/ > gm1s1e[WRITE(offset=875450966016, length=2048)]error = 6 > Aug 13 15:36:30 piglet kernel: g_vfs_done():mirror/ > gm1s1e[WRITE(offset=875450968064, length=2048)]error = 6 > Aug 13 15:36:30 piglet kernel: g_vfs_done():mirror/ > gm1s1e[WRITE(offset=875450970112, length=2048)]error = 6 > Aug 13 15:36:30 piglet kernel: g_vfs_done():mirror/ > gm1s1e[WRITE(offset=875450972160, length=2048)]error = 6 > Aug 13 15:36:30 piglet kernel: g_vfs_done():mirror/ > gm1s1e[WRITE(offset=875450974208, length=2048)]error = 6 > Aug 13 15:42:23 piglet syslogd: kernel boot file is /boot/kernel/ > kernel > Aug 13 15:42:23 piglet kernel: Copyright (c) 1992-2008 The FreeBSD > Project. > smartctl version 5.38 [i386-portbld-freebsd6.3] Copyright (C) 2002-8 > Bruce Allen > Home page is http://smartmontools.sourceforge.net/ > > === START OF INFORMATION SECTION === > Device Model: SAMSUNG HD103UJ > Serial Number: S13PJ1BQ606865 > Firmware Version: 1AA01112 > User Capacity: 1,000,204,886,016 bytes > Device is: In smartctl database [for details use: -P show] > ATA Version is: 8 > ATA Standard is: ATA-8-ACS revision 3b > Local Time is: Thu Aug 14 11:28:13 2008 CEST > > ==> WARNING: May need -F samsung or -F samsung2 enabled; see manual > for details. > > SMART support is: Available - device has SMART capability. > SMART support is: Enabled > > === START OF READ SMART DATA SECTION === > SMART overall-health self-assessment test result: PASSED > > General SMART Values: > Offline data collection status: (0x02) Offline data collection > activity > was completed without error. > Auto Offline Data Collection: Disabled. > Self-test execution status: ( 0) The previous self-test > routine completed > without error or no self-test has ever > been run. > Total time to complete Offline > data collection: (11811) seconds. > Offline data collection > capabilities: (0x7b) SMART execute Offline immediate. > Auto Offline data collection on/off support. > Suspend Offline collection upon new > command. > Offline surface scan supported. > Self-test supported. > Conveyance Self-test supported. > Selective Self-test supported. > SMART capabilities: (0x0003) Saves SMART data before > entering > power-saving mode. > Supports SMART auto save timer. > Error logging capability: (0x01) Error logging supported. > General Purpose Logging supported. > Short self-test routine > recommended polling time: ( 2) minutes. > Extended self-test routine > recommended polling time: ( 198) minutes. > Conveyance self-test routine > recommended polling time: ( 21) minutes. > SCT capabilities: (0x003f) SCT Status supported. > SCT Feature Control supported. > SCT Data Table supported. > > SMART Attributes Data Structure revision number: 16 > Vendor Specific SMART Attributes with Thresholds: > ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE > UPDATED WHEN_FAILED RAW_VALUE > 1 Raw_Read_Error_Rate 0x000f 100 100 051 Pre-fail > Always - 0 > 3 Spin_Up_Time 0x0007 076 076 011 Pre-fail > Always - 8010 > 4 Start_Stop_Count 0x0032 100 100 000 Old_age > Always - 8 > 5 Reallocated_Sector_Ct 0x0033 100 100 010 Pre-fail > Always - 0 > 7 Seek_Error_Rate 0x000f 253 253 051 Pre-fail > Always - 0 > 8 Seek_Time_Performance 0x0025 100 100 015 Pre-fail > Offline - 10255 > 9 Power_On_Hours 0x0032 100 100 000 Old_age > Always - 272 > 10 Spin_Retry_Count 0x0033 100 100 051 Pre-fail > Always - 0 > 11 Calibration_Retry_Count 0x0012 100 100 000 Old_age > Always - 0 > 12 Power_Cycle_Count 0x0032 100 100 000 Old_age > Always - 8 > 13 Read_Soft_Error_Rate 0x000e 100 100 000 Old_age > Always - 0 > 183 Unknown_Attribute 0x0032 100 100 000 Old_age > Always - 0 > 184 Unknown_Attribute 0x0033 100 100 099 Pre-fail > Always - 0 > 187 Reported_Uncorrect 0x0032 100 100 000 Old_age > Always - 0 > 188 Unknown_Attribute 0x0032 100 100 000 Old_age > Always - 0 > 190 Airflow_Temperature_Cel 0x0022 057 052 000 Old_age > Always - 43 (Lifetime Min/Max 43/48) > 194 Temperature_Celsius 0x0022 056 050 000 Old_age > Always - 44 (Lifetime Min/Max 43/50) > 195 Hardware_ECC_Recovered 0x001a 100 100 000 Old_age > Always - 195799724 > 196 Reallocated_Event_Count 0x0032 100 100 000 Old_age > Always - 0 > 197 Current_Pending_Sector 0x0012 100 100 000 Old_age > Always - 0 > 198 Offline_Uncorrectable 0x0030 100 100 000 Old_age > Offline - 0 > 199 UDMA_CRC_Error_Count 0x003e 100 100 000 Old_age > Always - 0 > 200 Multi_Zone_Error_Rate 0x000a 100 100 000 Old_age > Always - 0 > 201 Soft_Read_Error_Rate 0x000a 100 100 000 Old_age > Always - 0 > > SMART Error Log Version: 1 > No Errors Logged > > SMART Self-test log structure revision number 0 > Warning: ATA Specification requires self-test log structure revision > number = 1 > Num Test_Description Status Remaining > LifeTime(hours) LBA_of_first_error > # 1 Offline Completed without error 00% > 261 - > # 2 Offline Aborted by host 40% > 251 - > # 3 Short offline Aborted by host 00% > 250 - > > SMART Selective Self-Test Log Data Structure Revision Number (0) > should be 1 > SMART Selective self-test log data structure revision number 0 > Warning: ATA Specification requires selective self-test log data > structure revision number = 1 > SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS > 1 0 0 Not_testing > 2 0 0 Not_testing > 3 0 0 Not_testing > 4 0 0 Not_testing > 5 0 0 Not_testing > Selective self-test flags (0x0): > After scanning selected spans, do NOT read-scan remainder of disk. > If Selective self-test is pending on power-up, resume after 0 minute > delay. > > smartctl version 5.38 [i386-portbld-freebsd6.3] Copyright (C) 2002-8 > Bruce Allen > Home page is http://smartmontools.sourceforge.net/ > > === START OF INFORMATION SECTION === > Device Model: SAMSUNG HD103UJ > Serial Number: S13PJ1BQ607102 > Firmware Version: 1AA01112 > User Capacity: 1,000,204,886,016 bytes > Device is: In smartctl database [for details use: -P show] > ATA Version is: 8 > ATA Standard is: ATA-8-ACS revision 3b > Local Time is: Thu Aug 14 11:28:39 2008 CEST > > ==> WARNING: May need -F samsung or -F samsung2 enabled; see manual > for details. > > SMART support is: Available - device has SMART capability. > SMART support is: Enabled > > === START OF READ SMART DATA SECTION === > SMART overall-health self-assessment test result: PASSED > > General SMART Values: > Offline data collection status: (0x02) Offline data collection > activity > was completed without error. > Auto Offline Data Collection: Disabled. > Self-test execution status: ( 0) The previous self-test > routine completed > without error or no self-test has ever > been run. > Total time to complete Offline > data collection: (12131) seconds. > Offline data collection > capabilities: (0x7b) SMART execute Offline immediate. > Auto Offline data collection on/off support. > Suspend Offline collection upon new > command. > Offline surface scan supported. > Self-test supported. > Conveyance Self-test supported. > Selective Self-test supported. > SMART capabilities: (0x0003) Saves SMART data before > entering > power-saving mode. > Supports SMART auto save timer. > Error logging capability: (0x01) Error logging supported. > General Purpose Logging supported. > Short self-test routine > recommended polling time: ( 2) minutes. > Extended self-test routine > recommended polling time: ( 203) minutes. > Conveyance self-test routine > recommended polling time: ( 22) minutes. > SCT capabilities: (0x003f) SCT Status supported. > SCT Feature Control supported. > SCT Data Table supported. > > SMART Attributes Data Structure revision number: 16 > Vendor Specific SMART Attributes with Thresholds: > ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE > UPDATED WHEN_FAILED RAW_VALUE > 1 Raw_Read_Error_Rate 0x000f 100 100 051 Pre-fail > Always - 0 > 3 Spin_Up_Time 0x0007 077 077 011 Pre-fail > Always - 7810 > 4 Start_Stop_Count 0x0032 100 100 000 Old_age > Always - 10 > 5 Reallocated_Sector_Ct 0x0033 100 100 010 Pre-fail > Always - 0 > 7 Seek_Error_Rate 0x000f 253 253 051 Pre-fail > Always - 0 > 8 Seek_Time_Performance 0x0025 100 100 015 Pre-fail > Offline - 9978 > 9 Power_On_Hours 0x0032 100 100 000 Old_age > Always - 272 > 10 Spin_Retry_Count 0x0033 100 100 051 Pre-fail > Always - 0 > 11 Calibration_Retry_Count 0x0012 100 100 000 Old_age > Always - 0 > 12 Power_Cycle_Count 0x0032 100 100 000 Old_age > Always - 10 > 13 Read_Soft_Error_Rate 0x000e 100 100 000 Old_age > Always - 0 > 183 Unknown_Attribute 0x0032 100 100 000 Old_age > Always - 0 > 184 Unknown_Attribute 0x0033 100 100 099 Pre-fail > Always - 0 > 187 Reported_Uncorrect 0x0032 100 100 000 Old_age > Always - 0 > 188 Unknown_Attribute 0x0032 100 100 000 Old_age > Always - 0 > 190 Airflow_Temperature_Cel 0x0022 059 054 000 Old_age > Always - 41 (Lifetime Min/Max 41/46) > 194 Temperature_Celsius 0x0022 058 053 000 Old_age > Always - 42 (Lifetime Min/Max 41/47) > 195 Hardware_ECC_Recovered 0x001a 100 100 000 Old_age > Always - 31616 > 196 Reallocated_Event_Count 0x0032 100 100 000 Old_age > Always - 0 > 197 Current_Pending_Sector 0x0012 100 100 000 Old_age > Always - 0 > 198 Offline_Uncorrectable 0x0030 100 100 000 Old_age > Offline - 0 > 199 UDMA_CRC_Error_Count 0x003e 100 100 000 Old_age > Always - 0 > 200 Multi_Zone_Error_Rate 0x000a 100 100 000 Old_age > Always - 0 > 201 Soft_Read_Error_Rate 0x000a 100 100 000 Old_age > Always - 0 > > SMART Error Log Version: 1 > No Errors Logged > > SMART Self-test log structure revision number 0 > Warning: ATA Specification requires self-test log structure revision > number = 1 > Num Test_Description Status Remaining > LifeTime(hours) LBA_of_first_error > # 1 Offline Completed without error 00% > 261 - > # 2 Offline Aborted by host 40% > 251 - > # 3 Short offline Aborted by host 00% > 250 - > > SMART Selective Self-Test Log Data Structure Revision Number (0) > should be 1 > SMART Selective self-test log data structure revision number 0 > Warning: ATA Specification requires selective self-test log data > structure revision number = 1 > SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS > 1 0 0 Not_testing > 2 0 0 Not_testing > 3 0 0 Not_testing > 4 0 0 Not_testing > 5 0 0 Not_testing > Selective self-test flags (0x0): > After scanning selected spans, do NOT read-scan remainder of disk. > If Selective self-test is pending on power-up, resume after 0 minute > delay. > From owner-freebsd-stable@FreeBSD.ORG Fri Aug 15 03:02:18 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C4FD71065682 for ; Fri, 15 Aug 2008 03:02:18 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-gx0-f17.google.com (mail-gx0-f17.google.com [209.85.217.17]) by mx1.freebsd.org (Postfix) with ESMTP id 62E788FC0A for ; Fri, 15 Aug 2008 03:02:17 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by gxk10 with SMTP id 10so3431715gxk.19 for ; Thu, 14 Aug 2008 20:02:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=C/SvZAgFwuNHL23UFgn/BCTOHy0EcP72Q9MA6ZK9/mE=; b=reHWMWWsT7ktP4CS7vFQpFGQ6c+wz2i0OF53iQltyn/4QDC2VnoDxEc1IBoxquhrg6 CdvmsI5bfxh4WRaFG6m4QL+p23VA0dGXORGywcYVXKqG72dYniEA2z+WF1xBLtW7Hpxt jZt2bBdPX0AWPX/DNVOakMe5nK9krxkTUW8n8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=o5XimOtfxqibx2WRSeMSuQXOJzC2LtSsmHGbQEx4/+rBGjR8ntpdFMQYLjxQKSwDpX Gf2ubk8wK2SB01r7nPgEBQiGAAaevlSpu1xoARJ9QyjjB40KrxCEXkhVChuc4A2K2ZSN VoDuer0oEoriDOs60DGuGDeYdSAYGRg275ffU= Received: by 10.150.12.10 with SMTP id 10mr1488473ybl.214.1218769337014; Thu, 14 Aug 2008 20:02:17 -0700 (PDT) Received: by 10.150.49.4 with HTTP; Thu, 14 Aug 2008 20:02:16 -0700 (PDT) Message-ID: <2a41acea0808142002l44541708gf917e65901611231@mail.gmail.com> Date: Thu, 14 Aug 2008 20:02:16 -0700 From: "Jack Vogel" To: "Markus Vervier" In-Reply-To: <48A41816.3040904@vervier.info> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <489C4129.4090303@vervier.info> <200808110819.53914.josh@tcbug.org> <20080811140249.GA27379@eos.sc1.parodius.com> <2a41acea0808110928h10d54441o7d49b11a60406934@mail.gmail.com> <48A0A1D9.8030601@vervier.info> <2a41acea0808111340o7b506804u9e4c95f1af22b95c@mail.gmail.com> <48A2B1CB.7060303@vervier.info> <2a41acea0808130822i5f336b1ci15099f27a3a7c13d@mail.gmail.com> <2a41acea0808131210r6371b532i93f1ae6963d1f1b9@mail.gmail.com> <48A41816.3040904@vervier.info> Cc: freebsd-stable@freebsd.org Subject: Re: em(4) on FreeBSD is sometimes annoying X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Aug 2008 03:02:19 -0000 I fought with this issue all day today, trying to root cause it, and while I don't have a solution I do have a better understanding of it. I was wrong about it being the interrupt handler, at least if there's any issue with it its not the primary cause. I actually found out using a Fedora Live CD that Linux seems to have the same issue, but its symptoms are slightly different due to driver architecture differences. If you boot Linux with no cable in, and then modprobe the e1000 driver you get no errors, however, when you follow that with an 'ifconfig eth0' it will fail saying that it cannot find the device!! Do the same with the cable in and it all works. The same 82573 NIC on a standalone adapter has NONE of these problems, it all works fine. So, right now my theory is the power system of the laptop is putting the phy into a sleep state due to having no link and neither our driver or the Linux driver has a way to bring it back out of that state. Until this gets worked out all I can tell you is "keep that cable IN" :) Jack On Thu, Aug 14, 2008 at 4:33 AM, Markus Vervier wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Jack Vogel wrote: > | I have reproduced the problem, you are correct. Thank you for > | persisting thru my doubts :) > Always persisting to help improving FreeBSD. Another odd thing I noticed > today: > When dual-booting Windows on the same machine and doing a warm-reboot from > Windows to FreeBSD, > you _do_ get a link with the procedure I described yesterday.. So there > seems to be some setting which is lost > after cold-boot or some EEPROM setting which is changed somehow. > > | OH, I should note that as long as you put in a cable before you > | ifconfig up its fine so > | its not that hard to work around the issue. > I completly forgot about the issue until now, after I noticed it some time > ago when being overworked. :-( > The situation just does not occur very often in times of wireless LAN / > Docking Stations. :-) > > - -- > Markus > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.9 (FreeBSD) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkikGBMACgkQFhK2gHeM2QOLpACfdX4IyNSivy+TgAJBhKgZUwP2 > iiIAoNrPUTE0veViP7Zklm7jD25m7Aad > =DrBs > -----END PGP SIGNATURE----- > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Fri Aug 15 21:55:26 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9E45C106564A for ; Fri, 15 Aug 2008 21:55:26 +0000 (UTC) (envelope-from torfinn.ingolfsen@broadpark.no) Received: from osl1smout1.broadpark.no (osl1smout1.broadpark.no [80.202.4.58]) by mx1.freebsd.org (Postfix) with ESMTP id 6B2638FC18 for ; Fri, 15 Aug 2008 21:55:26 +0000 (UTC) (envelope-from torfinn.ingolfsen@broadpark.no) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII Received: from osl1sminn1.broadpark.no ([80.202.4.59]) by osl1smout1.broadpark.no (Sun Java(tm) System Messaging Server 6.3-3.01 (built Jul 12 2007; 32bit)) with ESMTP id <0K5N0021HWWCLZ90@osl1smout1.broadpark.no> for freebsd-stable@freebsd.org; Fri, 15 Aug 2008 23:55:24 +0200 (CEST) Received: from kg-work.kg4.no ([80.202.72.251]) by osl1sminn1.broadpark.no (Sun Java(tm) System Messaging Server 6.3-3.01 (built Jul 12 2007; 32bit)) with SMTP id <0K5N001B5WWBSV60@osl1sminn1.broadpark.no> for freebsd-stable@freebsd.org; Fri, 15 Aug 2008 23:55:24 +0200 (CEST) Date: Fri, 15 Aug 2008 23:55:23 +0200 From: Torfinn Ingolfsen To: freebsd-stable@freebsd.org Message-id: <20080815235523.5b019915.torfinn.ingolfsen@broadpark.no> X-Mailer: Sylpheed 2.5.0 (GTK+ 2.12.11; i386-portbld-freebsd6.3) X-Face: "t9w2,-X@O^I`jVW\sonI3.,36KBLZE*AL[y9lL[PyFD*r_S:dIL9c[8Y>V42R0"!"yb_zN,f#%.[PYYNq; m"_0v; ~rUM2Yy!zmkh)3&U|u!=T(zyv,MHJv"nDH>OJ`t(@mil461d_B'Uo|'nMwlKe0Mv=kvV?Nh@>Hb<3s_z2jYgZhPb@?Wi^x1a~Hplz1.zH Subject: trying to mount a write prptected zip disk panics the machine (unless the -r flag is used) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Aug 2008 21:55:26 -0000 Hello, Do you remember the zip[1] disks? The original 100 Mbyte ones? well recently, I got a scsi zip drive (internal) with a scsi card (Adaptec ava-2904) and some zip-100 disks, and a request to try to copy the data from those disks. I found a cable, installed the card and zip drive in a machine[2] running FreeBSd 7.0-stable, and luckily the zip disks could be read. But during this process I discovered one thing; if I try to mount a write protected zip disk without using the '-r' flag to the mount command, my machine will panic a few seconds later. As there is no visual indication to tell you that a zip disk is write protected, it is quite easy to forget mounting it read only. Note: using zip disks that aren't write protected works fine. Details: root@music1# uname -a FreeBSD music1.kg4.no 7.0-STABLE FreeBSD 7.0-STABLE #0: Fri Aug 15 12:56:35 CEST 2008 root@music1.kg4.no:/usr/obj/usr/src/sys/GENERIC i386 root@music1# dmesg | grep ahc ahc0: port 0x1400-0x14ff mem 0x5c100000-0x5c100fff irq 10 at device 15.0 on pci0 ahc0: Host Adapter Bios disabled. Using default SCSI device parameters ahc0: [ITHREAD] da0 at ahc0 bus 0 target 5 lun 0 root@music1# dmesg | grep aic aic7850: Single Channel A, SCSI Id=7, 3/253 SCBs root@music1# dmesg | grep da0 da0 at ahc0 bus 0 target 5 lun 0 da0: Removable Direct Access SCSI-2 device da0: 3.300MB/s transfers da0: 96MB (196608 512 byte sectors: 64H 32S/T 96C) This is what I got on the console (and in /var/log/messages) when I tried to mount the disk: Aug 15 20:14:33 music1 kernel: (da0:ahc0:0:5:0): WRITE(06). CDB: a 0 0 21 8 0 Aug 15 20:14:33 music1 kernel: (da0:ahc0:0:5:0): CAM Status: SCSI Status Error Aug 15 20:14:33 music1 kernel: (da0:ahc0:0:5:0): SCSI Status: Check Condition Aug 15 20:14:33 music1 kernel: (da0:ahc0:0:5:0): DATA PROTECT asc:27,0 Aug 15 20:14:33 music1 kernel: (da0:ahc0:0:5:0): Write protected Aug 15 20:14:33 music1 kernel: (da0:ahc0:0:5:0): Unretryable error Aug 15 20:14:33 music1 kernel: g_vfs_done():da0s4[WRITE(offset=512, length=4096)]error = 13 Aug 15 20:14:33 music1 kernel: (da0:ahc0:0:5:0): WRITE(06). CDB: a 0 0 21 8 0 Aug 15 20:14:33 music1 kernel: (da0:ahc0:0:5:0): CAM Status: SCSI Status Error Aug 15 20:14:33 music1 kernel: (da0:ahc0:0:5:0): SCSI Status: Check Condition Aug 15 20:14:33 music1 kernel: (da0:ahc0:0:5:0): DATA PROTECT asc:27,0 Aug 15 20:14:33 music1 kernel: (da0:ahc0:0:5:0): Write protected Aug 15 20:14:33 music1 kernel: (da0:ahc0:0:5:0): Unretryable error Aug 15 20:14:33 music1 kernel: g_vfs_done():da0s4[WRITE(offset=512, length=4096)]error = 13 Aug 15 20:14:33 music1 kernel: fsync: giving up on dirty Aug 15 20:14:33 music1 kernel: 0xc2988114: tag devfs, type VCHR Aug 15 20:14:33 music1 kernel: usecount 1, writecount 0, refcount 27 mountedhere 0xc2617700 Aug 15 20:14:33 music1 kernel: flags () Aug 15 20:14:33 music1 kernel: v_object 0xc299707c ref 0 pages 25 Aug 15 20:14:33 music1 kernel: Aug 15 20:14:33 music1 kernel: dev da0s4 Aug 15 20:14:34 music1 kernel: GEOM_LABEL: Label for provider da0s4 is msdosfs/DIPLOM. A few seconds went by, and then the machine panic'ed with apage fault: root@music1# more /var/crash/info.0 Dump header from device /dev/ad0s1b Architecture: i386 Architecture Version: 2 Dump Length: 60837888B (58 MB) Blocksize: 512 Dumptime: Fri Aug 15 20:15:03 2008 Hostname: music1.kg4.no Magic: FreeBSD Kernel Dump Version String: FreeBSD 7.0-STABLE #0: Fri Aug 15 12:56:35 CEST 2008 root@music1.kg4.no:/usr/obj/usr/src/sys/GENERIC Panic String: page fault Dump Parity: 2682527093 Bounds: 0 Dump Status: good (crash dump, 58 Mbyte, available on request). Is this how it is supposed to be, or should I file a PR? References: 1) http://en.wikipedia.org/wiki/Zip_drive 2) http://tingox.googlepages.com/dp-ep-c400_freebsd -- Regards, Torfinn Ingolfsen, Norway From owner-freebsd-stable@FreeBSD.ORG Sat Aug 16 00:13:03 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 27FFF106564A; Sat, 16 Aug 2008 00:13:03 +0000 (UTC) (envelope-from freebsd@hub.org) Received: from hub.org (hub.org [200.46.204.220]) by mx1.freebsd.org (Postfix) with ESMTP id 0E4608FC1F; Sat, 16 Aug 2008 00:13:02 +0000 (UTC) (envelope-from freebsd@hub.org) Received: from localhost (unknown [200.46.204.183]) by hub.org (Postfix) with ESMTP id 8D886168AEB8; Fri, 15 Aug 2008 20:55:47 -0300 (ADT) Received: from hub.org ([200.46.204.220]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 11249-08; Fri, 15 Aug 2008 20:55:42 -0300 (ADT) Received: from localhost (wm.hub.org [200.46.204.128]) by hub.org (Postfix) with ESMTP id 2C2391689704; Fri, 15 Aug 2008 20:55:47 -0300 (ADT) Received: from blk-222-93-114.eastlink.ca (blk-222-93-114.eastlink.ca [24.222.93.114]) by webmail.hub.org (Horde Framework) with HTTP; Fri, 15 Aug 2008 23:55:46 +0000 Message-ID: <20080815235546.65415dg5hblf1oxu@webmail.hub.org> Date: Fri, 15 Aug 2008 23:55:46 +0000 From: freebsd@hub.org To: "Kris Kennaway" References: <20080301073329.GA1081@Alex1.kruijff.org> <47C93FD2.1010902@FreeBSD.org> In-Reply-To: <47C93FD2.1010902@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.2) / FreeBSD-6.3 Cc: freebsd-stable@freebsd.org Subject: Re: Very large kernel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Aug 2008 00:13:03 -0000 Quoting "Kris Kennaway" : > Alex de Kruijff wrote: >> I noticed that the kernel directory was very large compaired to 6.1. Is >> this for debugging and can I safely remove the symbols files I want to >> save some space? > > Yes but if you encounter a panic and need to submit a bug report > then you will need at least the kernel.debug and whatever modules > you are using. Two questions for this ... a. can I move these to a larger partition temporarily, and if I have a crash, move them back to do debugging? b. is there some setting I can use in make.conf to have it auto-install the symbols files to a seperate directory on 'installkernel'? From owner-freebsd-stable@FreeBSD.ORG Sat Aug 16 12:53:11 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7F2D91065673 for ; Sat, 16 Aug 2008 12:53:11 +0000 (UTC) (envelope-from alson+ml@alm.flutnet.org) Received: from hatert.nijmegen.internl.net (mailrelay1.nijmegen.internl.net [217.149.192.44]) by mx1.freebsd.org (Postfix) with ESMTP id 26F858FC13 for ; Sat, 16 Aug 2008 12:53:10 +0000 (UTC) (envelope-from alson+ml@alm.flutnet.org) Received: from smtp20.nijmegen.internl.net by hatert.nijmegen.internl.net via smtp20.nijmegen.internl.net [217.149.192.18] with ESMTP for id m7GCHM4w007678 (8.13.6/2.04); Sat, 16 Aug 2008 14:17:22 +0200 (MEST) Received: from tafi.alm.flutnet.org (tafi.dsl.alm.flutnet.org [145.99.245.99]) by smtp20.nijmegen.internl.net (8.13.8/2.04) with ESMTP id m7GCHJ7R019615 for ; Sat, 16 Aug 2008 14:17:20 +0200 (CEST) Received: from localhost (localhost.alm.flutnet.org [127.0.0.1]) by tafi.alm.flutnet.org (Postfix) with ESMTP id C4C6B2844B for ; Sat, 16 Aug 2008 14:17:19 +0200 (CEST) X-Virus-Scanned: amavisd-new at alm.flutnet.org Received: from tafi.alm.flutnet.org ([127.0.0.1]) by localhost (tafi.alm.flutnet.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1NYxH48YgwoX for ; Sat, 16 Aug 2008 14:17:07 +0200 (CEST) Received: by tafi.alm.flutnet.org (Postfix, from userid 1000) id 000022844A; Sat, 16 Aug 2008 14:17:06 +0200 (CEST) Date: Sat, 16 Aug 2008 14:17:06 +0200 From: Alson van der Meulen To: freebsd-stable@freebsd.org Message-ID: <20080816121706.GA3040@waalsdorp.nl> Mail-Followup-To: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Panic in nfs/ffs after upgrade from 6.2 to 6.3-RELEASE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Aug 2008 12:53:11 -0000 Hello, This file server was upgraded from 6.2-RELEASE-p$something to 6.3-RELEASE-p3 (current RELENG_6_3 sources via csup) on August, 11 and rebooted to the new kernel on August, 12. The school is closed due to holidays. The only load is mail delivery to Maildirs via NFS from another server (just 50 mailboxes or so, none of them very busy) and nightly backups. I went there on August, 13 to perform some maintenance on unrelated systems. Performed a Windows installation (+ assorted desktop software) that fetched the installation files from Samba running on this server. This procedure downloads a total of ~5G in bursts via a 100mbit link. After most of this was over (I think it wast just installing patches at that point), the file server crashed. The crash: [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so:= Undefined symbol "ps_pglobal_lookup"] GNU gdb 6.1.1 [FreeBSD] [...] Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode cpuid =3D 0; apic id =3D 00 fault virtual address =3D 0x1c fault code =3D supervisor write, page not present instruction pointer =3D 0x20:0xc06fd937 stack pointer =3D 0x28:0xe78e78ec frame pointer =3D 0x28:0xe78e7914 code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, def32 1, gran 1 processor eflags =3D interrupt enabled, resume, IOPL =3D 0 current process =3D 847 (nfsd) trap number =3D 12 panic: page fault cpuid =3D 1 KDB: stack backtrace: kdb_backtrace(100,c532f900,28,e78e78ac,c,...) at kdb_backtrace+0x29 panic(c0976f0c,c09cfe95,0,fffff,c532e49b,...) at panic+0x114 trap_fatal(e78e78ac,1c,c532f900,0,c,...) at trap_fatal+0x2ce trap_pfault(e78e78ac,0,1c) at trap_pfault+0x1f7 trap(e78e0008,c06a0028,e78e0028,200012,d9156118,...) at trap+0x325 calltrap() at calltrap+0x5 --- trap 0xc, eip =3D 0xc06fd937, esp =3D 0xe78e78ec, ebp =3D 0xe78e7914 --- getnewbuf(0,0,4000,4000) at getnewbuf+0x1bb getblk(c5964cc0,0,0,4000,0,...) at getblk+0x360 cluster_read(c5964cc0,46e5,0,0,0,...) at cluster_read+0xde ffs_read(e78e7b08) at ffs_read+0x25f VOP_READ_APV(c0a65560,e78e7b08) at VOP_READ_APV+0x38 nfsrv_read(c69b3800,c520d900,c532f900,e78e7c98,0,...) at nfsrv_read+0xb16 nfssvc_nfsd(c532f900) at nfssvc_nfsd+0x435 nfssvc(c532f900,e78e7d04) at nfssvc+0x1c0 syscall(3b,3b,3b,1,0,...) at syscall+0x2bf Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (155, FreeBSD ELF32, nfssvc), eip =3D 0x280bdf17, esp =3D 0xbfb= feb0c, ebp =3D 0xbfbfeb28 --- Uptime: 12h24m16s Dumping 1023 MB (2 chunks) chunk 0: 1MB (159 pages) ... ok chunk 1: 1023MB (261840 pages) 1007 991 975 959 943 927 911 895 879 863 8= 47 831 815 799 783 767 751 735 719 703 687 671 655 639 623 607 591 575 559 = 543 527 511 495 479 463 447 431 415 399 383 367 351 335 319 303 287 271 255= 239 223 207 191 175 159 143 127 111 95 79 63 47 31 15 #0 doadump () at pcpu.h:165 165 __asm __volatile("movl %%fs:0,%0" : "=3Dr" (td)); (kgdb) list *0xc06fd937 0xc06fd937 is in getnewbuf (atomic.h:149). 144 static __inline int 145 atomic_cmpset_int(volatile u_int *dst, u_int exp, u_int src) 146 { 147 int res =3D exp; 148=09 149 __asm __volatile ( 150 " " __XSTRING(MPLOCKED) " " 151 " cmpxchgl %2,%1 ; " 152 " setz %%al ; " 153 " movzbl %%al,%0 ; " (kgdb) bt #0 doadump () at pcpu.h:165 #1 0xc06b25fe in boot (howto=3D260) at /usr/src/sys/kern/kern_shutdown.c:4= 09 #2 0xc06b2955 in panic (fmt=3D0xc0976f0c "%s") at /usr/src/sys/kern/kern_s= hutdown.c:565 #3 0xc0924c86 in trap_fatal (frame=3D0xe78e78ac, eva=3D28) at /usr/src/sys= /i386/i386/trap.c:838 #4 0xc092498f in trap_pfault (frame=3D0xe78e78ac, usermode=3D0, eva=3D28) = at /usr/src/sys/i386/i386/trap.c:745 #5 0xc0924585 in trap (frame=3D {tf_fs =3D -410124280, tf_es =3D -1066794968, tf_ds =3D -410124248, t= f_edi =3D 2097170, tf_esi =3D -652910312, tf_ebp =3D -410093292, tf_isp =3D= -410093352, tf_ebx =3D 0, tf_edx =3D -1062624684, tf_ecx =3D -986515200, t= f_eax =3D 4, tf_trapno =3D 12, tf_err =3D 2, tf_eip =3D -1066411721, tf_cs = =3D 32, tf_eflags =3D 66182, tf_esp =3D 1, tf_ss =3D 4}) at /usr/src/sys/i3= 86/i386/trap.c:435 #6 0xc090ec9a in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #7 0xc06fd937 in getnewbuf (slpflag=3D0, slptimeo=3D0, size=3D16384, maxsi= ze=3D16384) at atomic.h:149 #8 0xc06fefdc in getblk (vp=3D0xc5964cc0, blkno=3D0, size=3D16384, slpflag= =3D0, slptimeo=3D0, flags=3D0) at /usr/src/sys/kern/vfs_bio.c:2516 #9 0xc0702a8a in cluster_read (vp=3D0xc5964cc0, filesize=3D18149, lblkno= =3D0, size=3D16384, cred=3D0x0, totread=3D8192, seqcount=3D5,=20 bpp=3D0x4) at /usr/src/sys/kern/vfs_cluster.c:118 #10 0xc081213b in ffs_read (ap=3D0x4) at /usr/src/sys/ufs/ffs/ffs_vnops.c:5= 03 #11 0xc09368a0 in VOP_READ_APV (vop=3D0x4, a=3D0xc0a9a254) at vnode_if.c:643 #12 0xc07ad086 in nfsrv_read (nfsd=3D0xc69b3800, slp=3D0xc520d900, td=3D0xc= 532f900, mrq=3D0xe78e7c98) at vnode_if.h:343 #13 0xc07bd329 in nfssvc_nfsd (td=3D0x4) at /usr/src/sys/nfsserver/nfs_sysc= alls.c:474 #14 0xc07bcb08 in nfssvc (td=3D0xc532f900, uap=3D0xe78e7d04) at /usr/src/sy= s/nfsserver/nfs_syscalls.c:181 #15 0xc0924fcb in syscall (frame=3D {tf_fs =3D 59, tf_es =3D 59, tf_ds =3D 59, tf_edi =3D 1, tf_esi =3D 0= , tf_ebp =3D -1077941464, tf_isp =3D -410092188, tf_ebx =3D 4, tf_edx =3D 6= 72460376, tf_ecx =3D 25, tf_eax =3D 155, tf_trapno =3D 12, tf_err =3D 2, tf= _eip =3D 671866647, tf_cs =3D 51, tf_eflags =3D 662, tf_esp =3D -1077941492= , tf_ss =3D 59}) at /usr/src/sys/i386/i386/trap.c:984 #16 0xc090ecef in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s= :200 #17 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) I have the crash dump and kernel build files still available, so let me know if I can provide any other useful output from the dump. The crash is in the NFS server part of the kernel, which is funny because NFS is only used for mail delivery. Between 0am and 11.59pm, 40 mails very delivered from the mailserver to maildirs on NFS. There were also a few clients checking their mailboxes via IMAP. The server booted again at 15.25, these are the imapd logs from around that time: Aug 13 15:22:48 eraser imapd-ssl: LOGIN, user=3DXXX, ip=3D[::ffff:x.x.x.x],= port=3D[63802], protocol=3DIMAP Aug 13 15:22:48 eraser imapd-ssl: LOGIN, user=3DXXX, ip=3D[::ffff:x.x.x.x],= port=3D[63803], protocol=3DIMAP Aug 13 15:22:49 eraser imapd-ssl: LOGOUT, user=3DXXX, ip=3D[::ffff:x.x.x.x]= , headers=3D0, body=3D0, rcvd=3D96, sent=3D470, time=3D1, starttls=3D1 Aug 13 15:22:49 eraser imapd-ssl: LOGOUT, user=3DXXX, ip=3D[::ffff:x.x.x.x]= , headers=3D0, body=3D0, rcvd=3D252, sent=3D944, time=3D1, starttls=3D1 Aug 13 15:22:49 eraser imapd-ssl: LOGIN, user=3DXXX, ip=3D[::ffff:x.x.x.x],= port=3D[63806], protocol=3DIMAP Aug 13 15:22:49 eraser imapd-ssl: LOGOUT, user=3DXXX, ip=3D[::ffff:x.x.x.x]= , headers=3D0, body=3D0, rcvd=3D38, sent=3D273, time=3D0, starttls=3D1 Aug 13 15:22:52 eraser imapd-ssl: LOGIN, user=3DXXX, ip=3D[::ffff:x.x.x.x],= port=3D[63808], protocol=3DIMAP Aug 13 15:22:52 eraser imapd-ssl: LOGOUT, user=3DXXX, ip=3D[::ffff:x.x.x.x]= , headers=3D0, body=3D0, rcvd=3D38, sent=3D273, time=3D0, starttls=3D1 Aug 13 15:22:53 eraser imapd-ssl: LOGIN, user=3DXXX, ip=3D[::ffff:x.x.x.x],= port=3D[63811], protocol=3DIMAP Aug 13 15:22:53 eraser imapd-ssl: LOGOUT, user=3DXXX, ip=3D[::ffff:x.x.x.x]= , headers=3D0, body=3D0, rcvd=3D106, sent=3D392, time=3D0, starttls=3D1 Aug 13 15:22:54 eraser imapd-ssl: LOGIN, user=3DXXX, ip=3D[::ffff:x.x.x.x],= port=3D[63812], protocol=3DIMAP Aug 13 15:26:35 eraser imapd-ssl: LOGIN, user=3DYYY, ip=3D[::ffff:x.x.x.x],= port=3D[64582], protocol=3DIMAP Aug 13 15:26:35 eraser imapd-ssl: LOGOUT, user=3DYYY, ip=3D[::ffff:x.x.x.x]= , headers=3D0, body=3D0, rcvd=3D106, sent=3D394, time=3D0, starttls=3D1 Aug 13 15:26:50 eraser imapd-ssl: DISCONNECTED, user=3DXXX, ip=3D[::ffff:x.= x.x.x], headers=3D0, body=3D0, rcvd=3D135, sent=3D10825, time=3D236, startt= ls=3D1 Aug 13 15:27:55 eraser imapd-ssl: LOGIN, user=3DXXX, ip=3D[::ffff:x.x.x.x],= port=3D[64975], protocol=3DIMAP Aug 13 15:27:55 eraser imapd-ssl: LOGOUT, user=3DXXX, ip=3D[::ffff:x.x.x.x]= , headers=3D0, body=3D0, rcvd=3D106, sent=3D392, time=3D1, starttls=3D1 The six almost simultaneous logins from user XXX look suspicious and =66rom the timestamp seem to be just prior to the crash, but shouldn't lead to the crash of the nfs server. The lack of logout after the 15:22:54 one suggests that this was the point that the file server went offline. The only directory that was mounted at that time was in /export (/dev/mirror/gm1a): alson@damaged:~$ gmirror status Name Status Components mirror/gm0 DEGRADED ad4s1 mirror/gm1 COMPLETE ad8s1 ad10s1 The server had been up for about 250 days with similar (and usually significantly heavier) load with 6.2-STABLE before the upgrade. The evening after the crash, I received the following message from smartmontools (not sure if it's related): Aug 13 21:19:30 damaged smartd[881]: Device: /dev/ad10, 4 Currently unreada= ble (pending) sectors Aug 13 21:19:30 damaged smartd[881]: Device: /dev/ad10, 4 Offline uncorrect= able sectors ad10 is part of the mirror, but I don't think this should be a problem since (a) the disk should have corrected it and (b) gmirror should have dropped the disk and try to read from ad8 if it had returned a read error. The server has been stable since, but hasn't seen much usage either. I have no idea if I can reproduce it. My first thought was disk corruption, but this doesn't appear to be the cas= e: # fsck -f=20 [...] ** /dev/mirror/gm1a ** Last Mounted on /export ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups FREE BLK COUNT(S) WRONG IN SUPERBLK SALVAGE? [yn] y 953252 files, 47080232 used, 44658220 free (159804 frags, 5562302 blocks, 0= =2E2% fragmentation) ***** FILE SYSTEM MARKED CLEAN ***** ***** FILE SYSTEM WAS MODIFIED ***** dmesg is attached below. regards, Alson Copyright (c) 1992-2008 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 6.3-RELEASE-p3 #10: Mon Aug 11 22:01:47 CEST 2008 root@damaged.example.com:/usr/obj/usr/src/sys/DAMAGED Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) 4 CPU 3.00GHz (3000.12-MHz 686-class CPU) Origin =3D "GenuineIntel" Id =3D 0xf43 Stepping =3D 3 Features=3D0xbfebfbff Features2=3D0x649d AMD Features=3D0x20000000 Logical CPUs per core: 2 real memory =3D 1073545216 (1023 MB) avail memory =3D 1037168640 (989 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) hptrr: HPT RocketRAID controller driver v1.1 (Aug 11 2008 22:01:29) acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 cpu0: on acpi0 acpi_throttle0: on cpu0 cpu1: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 16 at device 28.0 on pci0 pci4: on pcib1 pcib2: irq 16 at device 28.4 on pci0 pci3: on pcib2 bge0: mem 0xfeaf0000-0xfeafffff irq= 16 at device 0.0 on pci3 miibus0: on bge0 brgphy0: on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000ba= seT-FDX, auto bge0: Ethernet address: 00:18:f3:2a:e0:cf pcib3: irq 17 at device 28.5 on pci0 pci2: on pcib3 bge1: mem 0xfe9f0000-0xfe9fffff irq= 17 at device 0.0 on pci2 miibus1: on bge1 brgphy1: on miibus1 brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000ba= seT-FDX, auto bge1: Ethernet address: 00:18:f3:2a:e0:58 uhci0: port 0xd880-0xd89f irq 16 at device = 29.0 on pci0 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xdc00-0xdc1f irq 17 at device = 29.1 on pci0 uhci1: [GIANT-LOCKED] usb1: on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0xe000-0xe01f irq 18 at device = 29.2 on pci0 uhci2: [GIANT-LOCKED] usb2: on uhci2 usb2: USB revision 1.0 uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered uhci3: port 0xe080-0xe09f irq 19 at device = 29.3 on pci0 uhci3: [GIANT-LOCKED] usb3: on uhci3 usb3: USB revision 1.0 uhub3: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub3: 2 ports with 2 removable, self powered ehci0: mem 0xfebff800-0xfebffbf= f irq 16 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] usb4: EHCI version 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: on ehci0 usb4: USB revision 2.0 uhub4: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub4: 8 ports with 8 removable, self powered pcib4: at device 30.0 on pci0 pci1: on pcib4 puc0: port 0xcc00-0xcc1f,0xc880-0xc887,0xc800-0x= c807 irq 20 at device 1.0 on pci1 sio4: on puc0 sio4: type 16550A sio4: unable to activate interrupt in fast mode - using normal mode sio5: on puc0 sio5: type 16550A sio5: unable to activate interrupt in fast mode - using normal mode pci1: at device 2.0 (no driver attached) isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177= ,0x376,0xffa0-0xffaf at device 31.1 on pci0 ata0: on atapci0 ata1: on atapci0 atapci1: port 0xec00-0xec07,0xe880-0xe883,0xe800-0x= e807,0xe480-0xe483,0xe400-0xe41f mem 0xfebffc00-0xfebfffff irq 19 at device= 31.2 on pci0 atapci1: AHCI Version 01.10 controller with 4 ports detected ata2: on atapci1 ata3: on atapci1 ata4: on atapci1 ata5: on atapci1 ichsmb0: port 0x400-0x41f at device= 31.3 on pci0 ichsmb0: [GIANT-LOCKED] smbus0: on ichsmb0 smb0: on smbus0 acpi_button0: on acpi0 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on= acpi0 fdc0: [FAST] ppc0: port 0x378-0x37f irq 7 on acpi0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppbus0: on ppc0 plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acp= i0 sio0: type 16550A, console pmtimer0 on isa0 orm0: at iomem 0xc0000-0xc7fff on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=3D0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounters tick every 1.000 msec hptrr: no controller detected. acd0: CDROM at ata0-master PIO4 ad4: 35304MB at ata2-master SATA150 ad8: 190782MB at ata4-master SATA150 GEOM_MIRROR: Device gm0 created (id=3D1495539501). GEOM_MIRROR: Device gm0: provider ad4s1 detected. ad10: 190782MB at ata5-master SATA150 GEOM_MIRROR: Device gm1 created (id=3D1615731132). GEOM_MIRROR: Device gm1: provider ad8s1 detected. SMP: AP CPU #1 Launched! GEOM_MIRROR: Device gm1: provider ad10s1 detected. GEOM_MIRROR: Device gm1: provider ad8s1 activated. GEOM_MIRROR: Device gm1: provider mirror/gm1 launched. GEOM_MIRROR: Device gm1: rebuilding provider ad10s1. Root mount waiting for: GMIRROR Root mount waiting for: GMIRROR Root mount waiting for: GMIRROR Root mount waiting for: GMIRROR GEOM_MIRROR: Force device gm0 start due to timeout. GEOM_MIRROR: Device gm0: provider ad4s1 activated. GEOM_MIRROR: Device gm0: provider mirror/gm0 launched. Trying to mount root from ufs:/dev/mirror/gm0a vlan2: link state changed to UP vlan1: link state changed to UP bge1: link state changed to UP GEOM_MIRROR: Device gm1: rebuilding provider ad10s1 finished. GEOM_MIRROR: Device gm1: provider ad10s1 activated. From owner-freebsd-stable@FreeBSD.ORG Sat Aug 16 15:47:16 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 11A671065677 for ; Sat, 16 Aug 2008 15:47:16 +0000 (UTC) (envelope-from utisoft@googlemail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.31]) by mx1.freebsd.org (Postfix) with ESMTP id B7FAC8FC1C for ; Sat, 16 Aug 2008 15:47:15 +0000 (UTC) (envelope-from utisoft@googlemail.com) Received: by yw-out-2324.google.com with SMTP id 9so145188ywe.13 for ; Sat, 16 Aug 2008 08:47:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:reply-to :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=PLUlmxr/Zc2qRcnf7tyd3goQmCZstgq1/cDpx/DRq6o=; b=ADoTaR+6zGaVU+9ur35tiYWTtUQdgaFOW1NQc9PSxPXV0YbhDPVjmRvNWZ7vndvQtS mFtx9jpNpdT0nsoMJB+0iKSkjlF4E++U2GbxA7IF37YE+/ZFsG3g00oz5T+rKvqnqGEE qqkPa3g3mX49HC3xxbV/yBPTPbT/9LL1cAaVA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:reply-to:to:subject:cc:in-reply-to :mime-version:content-type:content-transfer-encoding :content-disposition:references; b=hubLo2uQX7rZz817KqNMwxlvoQ/KymnK1Tmie/0ymiXKYkJi5Em0ggZgIIX5DXTQSJ YAb19P4VLmHS6dOacJbVKr8Yw0oFayLk/rU0XeQO8a8FVQe3hW5ig5v/D+Om6RjSA+l0 A2ghzdsd0mYk7fPI8rACHCBhXCJ06BwithE0w= Received: by 10.150.192.7 with SMTP id p7mr6068741ybf.91.1218901634892; Sat, 16 Aug 2008 08:47:14 -0700 (PDT) Received: by 10.150.229.11 with HTTP; Sat, 16 Aug 2008 08:47:14 -0700 (PDT) Message-ID: Date: Sat, 16 Aug 2008 16:47:14 +0100 From: "Chris Rees" To: "Warren Liddell" In-Reply-To: <200808111813.42060.shinjii@maydias.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200808111813.42060.shinjii@maydias.com> Cc: freebsd-stable@freebsd.org Subject: Re: Wireless net Card X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: utisoft@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Aug 2008 15:47:16 -0000 2008/8/11 Warren Liddell : >> Which Belkin wireless card do you have? Which arch are you running >> (i386/amd64)? >> >> I had horrific trouble with a Belkin on the Realtek chipset, played up >> with Ubuntu, FreeBSD, Fedora, even Windows! >> >> Trouble with Belkin is, you never know what you're getting. You need >> the revision number of the card, and then find out which chipset it >> is. Make sure the drivers you downloaded are for that exact revision. >> >> Hope you have more luck than I did, I tossed mine and bought a Ralink. >> >> Chris > > AMD64 Arch & ironically it worked beautifully for ages in windows, but i got > sick of windows having been used to FreeBSD, so i re-installed FreeBSD an > using the onboard LAN card atm, but am wanting to goto wireless. > > > none1@pci0:3:5:0: class=0x020000 card=0x700f1799 chip=0x700f1799 > rev=0x20 hdr=0x00 > vendor = 'Belkin Research and Development Labs' > class = network > subclass = ethernet > > > Chipset is RT8185L an i used the ndisgen to create the .ko file, which is just > over 572kb in size. > > ironically the 8180 works fine, but naturally wont do my wireless card. > This card I have also had problems with. It appears to be an 8185, but nothing works with it. Even in Windows, unless you have the Belkin drivers, it won't work properly. I couldn't load the Windows driver with ndisgen either, and ndiswrapper in Linux doesn't work either, nor does the Realtek Linux driver. -- R< $&h ! > $- ! $+ $@ $2 < @ $1 .UUCP. > (sendmail.cf)